System Design -- Part 1

Analysis vs Design

Analysis

• Recall that analysis activities focus on understanding the application domain
• Analysis activities will produce:
  • use case model (functional requirements)
  • a set of non-functional requirements and constraints
  • an object model (describing participating objects/entities)
  • a sequence diagram for each use case, describing interactions between objects
• Analysis model -- describes everything from the actors' point of view
  • This serves as the basis of communication between client and developers

Design

• Design activities focus on the solution domain
  • internal structure of the system, how will it be realized?
• System design will produce:
  • design goals -- what qualities of the system should developers optimize? These are often derived from the non-functional requirements
  • subsystem decomposition -- overall architecture, subsystem responsibilities, mapping to hardware, etc
  • boundary use cases -- configuration, startup, shutdown, etc
• Using top-down techniques (divide and conquer), the overall system is usually modeled as a set of subsystems

System Design Concepts

Subsystems

• subsystem -- a smaller, simpler part of a larger system
  • a subsystem is made of a number of solution domain classes
  • often one developer or development team is responsible for one subsystem
• service -- a set of related operations that share a common purpose
• subsystem interface -- a set of operations of a subsystem available to other subsystems.
  • One subsystem provides services to others, specified through its interface
  • Application Programmer Interface (API) -- refinement of general subsystem interface
• subsystem decomposition -- the activity of identifying subsystems, their services, and their relationships to each other

Coupling and Cohesion

• coupling -- the strength of dependencies between two subsystems
  • strongly coupled == changes to one subsystem likely to affect the other
  • loosely coupled == relatively independent (as long as the interface doesn't change)
  • Goal: Strive for loose couplings. Don't share attributes; use operations and a well-specified interface
• cohesion / coherence -- strength of dependencies within a subsystem
  • High cohesion: subsystem contains related objects performing similar tasks
  • Low cohesion: subsystem contains a number of unrelated objects
  • Goal: Strive for high cohesion

Subsystems -- Layering and Partitioning

• Subsystems can related to each other in more than one way. Two common ways: layering and partitioning
• Partitioning - dividing a system into independent peer subsystems
  • subsystems provide services to each other on same level of abstraction
  • each subsystem responsible for a different class of services
• Layering - a more hierarchical decomposition
  • A layer is a grouping of subsystems providing related services to a higher level of abstraction
  • a layer depends on lower layers
  • a layer has no knowledge of higher layers
  • Closed architecture -- a layer depends only one the one immediately below it
  • Open architecture -- a layer can access the one immediately below, as well as deeper layers
• A common example of layers -- web applications through TCP/IP
  • Application layer - interface to the user (web browser, SSH client, etc)
  • Transport layer - Client/server programs’ communication through sockets. Focus on communication betweem programs.
  • Internet (network) layer - routing of individual packets from machine to machine
  • Physical and DataLink layer (Ehternet and physical wire) - sending chunks of data over the physical medium
• Subsystem decomposition often involves both partitioning and layering

Architectural styles

• A software architecture includes specification of
  • system decomposition
  • global control flow
  • handling of boundary conditions (startup, shutdown, failures, etc)
  • communication between subsystems
• There are many architectural styles. Here are some common ones (not a comprehensive list, just examples) that can be used as a basis for the architecture of some systems
  • Repository
  • Model/View/Controller
  • Client/Server
  • Peer-to-peer
  • Pipes and Filters
  • Three-tier and four-tier

Repository Architecture

• There's a single data structure called the central repository
• Subsystems all access and modify data from this repository
• Subsystems are mostly independent
• Examples:
  • Database management systems
  • Compilers -- different subsystems (compiler, linker, debugger, etc) access and update central parse tree and symbol table
• Pro: Well suited for changing data processing tasks
  • New services can be added simply by building a new subsystem
• Con: Repository can become a bottleneck
  • Performance -- speed of access
  • Modifiability of repository -- high coupling with each subsystem

Model/View/Controller (MVC) Architecture

• Has three types of subsystems:
  • Model - responsible for domain data, information
  • View - responsible for displaying information to user
  • Controller - Manage interactions with user
• Special case of repository architecture
  • a model subsystem acts as repository. Doesn'’t depend on other subsystems.
  • Controller subsystems dictate the control flow
• Rationale: user interfaces (view, control) more likely to change than domain knowledge
  • Similar to idea of entity, boundary, and control objects
• Well-suited for interactive systems, especially if multiple views of the same model are needed
• Con: Can have same performance bottleneck as repository systems

Client/Server Architecture

• One or many servers provide services to instances of other subsystems, called clients.
  • Generalization of repository architecture
  • But not restricted to a single server (e.g. WWW)
• Client calls on the server, which performs some service and returns the result
  • Client knows the interface of the server (its service)
  • Server does not need to know the interface of the client
  • Request for services usually done with remote procedure call mechanism or common protocols (like HTTP)
• Users interact only with the client
• Well suited for distributed systems that manage large amounts of data
• Example: information systems with a central database:
  • Client: customized user interface, front-end data processing, intiation of remote procedure calls to server across network
  • Server: central data management, data integrity, database consistency, security, concurrency (multiple user access)
  • This example is a special case of repository architecture, where the repository is managed by the server process
• Other common client/server examples: HTTP, SSH, FTP, Telnet, etc

Peer-to-peer Architecture

• Generalization of Client/Server Architecture
• Subsystems can act as both clients and servers
  • Each subsystem can request and provide services
• More difficult to design
  • Greater possibility of deadlocks
  • More complicated control flow
• Example: Database receives queries from application but also sends notifications to application when data have changed
• More well-known examples: File sharing applications
  • Napster: Started as a sort of peer-to-peer architecture, mixed with a little client/server. Central servers kept lists of peers, then file transfers were done peer-to-peer
  • Later networks were more true peer-to-peer (FastTrack, Limewire, eDonkey)

Three-tier and Four-tier Architectures

• Three-tier: Subsystems organized into three layers
  • interface layer -- includes all boundary objects that deal with the user
  • application logic layer -- includes control and entity objects. Main processing, rule checking, etc
  • storage layer -- storage, retrieval, and query of persistent objects
• Four-tier: Same as three-tier, except interface layer is decomposed into:
  • Presentation client layer -- located on user machines
  • Presentation server layer -- located on one or more servers
• Four-tier is kind of a mix between three-tier and client/server
  • allows for different presentation clients
  • allows reuse of presentation objects (from the server) across clients
  • Example: A banking system's clients -- ATM, web interface (internet banking), application client for bank employees -- can all provide same services, defined in the presentation server layer

Pipe and Filter Architecture

• Filters: the subsystems
  • Process data received through inputs
  • Send results to outputs (to other subsystems)
• Pipes: the associations between subsystems
  • Connects output of a filter to input of another
• Filters don’t know about each other. They only know about the format of data received on input pipes
• Good for systems that apply transformations to streams of data
• Not so good for systems with complex user interaction, or interaction between components
• Example: Unix shell