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