Professional Documents
Culture Documents
• OOD
– Emphasizes a conceptual solution that fulfills the requirements
and define s/w objects, their responsibilities and how they
collaborate to fulfill the requirement.
– The products of object-oriented design can then be used as
blueprints for completely implementing a system using object-
oriented programming methods.
– detailed (or objects) OOD: provides the complete definition of
classes and associations to be implemented, as well as the data
structures and the algorithm of methods that implement class
operations
– OOD model, which adds the technical details of the
hardware/software solution that defines how the software has to
be implemented
Intro…
• System design, object design, and implementation constitute the
construction of the system.
• During these three activities, developers bridge the gap between the
requirements specification, produced during requirements elicitation
and analysis, and the system that is delivered to the users.
• System design is the first step in this process and focuses on
decomposing the system into manageable parts.
• During requirements elicitation and analysis, we concentrated on the
purpose and the functionality of the system.
• During system design, we focus on the processes, data structures,
and software and hardware components necessary to implement it.
• The challenge of system design is that many conflicting criteria and
constraints must be met when decomposing the system.
Overview of System Design
• Analysis: Focuses on the application domain
• Design: Focuses on the solution domain
• System Design
– Reduces the gap between requirements and the (virtual) machine
– Decomposes the overall system into manageable parts
• Design Goals Definition
– Describes and prioritizes the qualities that are important for the
system
– Defines the value system against which options are evaluated
• Subsystem Decomposition
– Results into a set of loosely dependent parts which
make up the system
– Use Divide and Conquer
• We model the new system to be developed as a set of subsystems
Cont’d
• System design is the transformation of an analysis model
into a system design model.
• During system design, developers define the design goals
of the project and decompose the system into smaller
subsystems that can be realized by individual teams.
• Developers also select strategies for building the system,
such as the hardware/software strategy, the persistent data
management strategy, the global control flow, the access control
policy, and the handling of boundary conditions.
• The result of system design is a model that includes a
subsystem decomposition and a clear description of each of
these strategies.
System Design
1. Design Goals
Definition
8. Boundary
Trade-offs
Conditions
Initialization
T ermination
Failure
2. System
Decomposition
Layers/Partitions 7. Software
Cohesion/Coupling
Control
Monolithic
Event-Driven
3. Concurrency Threads
Identification of 4. Hardware/ 6. Global Conc. Processes
Threads Software 5. Data Resource Handling
Mapping Management
Access control
Special purpose Persistent Objects Security
Buy or Build Trade-off Files
Databases
Allocation Data structure
Connectivity
How to use the results from the Requirements
Analysis for System Design
• Nonfunctional requirements => Activity 1: Design Goals Definition
• Functional model =>
– Activity 2: System decomposition (Selection of subsystems
based on functional requirements, cohesion, and coupling)
• Object model =>
– Activity 4: Hardware/software mapping
– Activity 5: Persistent data management
• Dynamic model =>
– Activity 3: Concurrency
– Activity 6: Global resource handling
– Activity 7: Software control
• Subsystem Decomposition
– Activity 8: Boundary conditions
From Analysis to System Design
Nonfunctional Functional Model
Requirements
8. Boundary
1. Design Goals Conditions
Definition Initialization
Trade-offs Termination
Functional Model Failure
2. System Decomposition Dynamic
Layers vs Partitions Model
Coherence/Coupling 7. Software
Control
Monolithic
Dynamic Object Model Event-Driven
Model Conc. Processes
4. Hardware/ 5. Data
6. Global Resource
3. Concurrency Software Mapping Management
Handlung
Special Purpose Systems Persistent Objects
Identification of
Threads
Buy vs Build Filesystem vs Database Access Control List
Allocation of Resources vs Capabilities
Connectivity Security
• System design is decomposed into several activities,
each addressing part of the overall problem of
decomposing the system:
– Identify design goals. Developers identify and prioritize the
qualities of the system that they should optimize.
– Design the initial subsystem decomposition. Developers
decompose the system into smaller parts based on the use case
and analysis models. Developers use standard architectural
styles as a starting point during this activity.
– Refine the subsystem decomposition to address the design
goals. The initial decomposition usually does not satisfy all design
goals. Developers refine it until all goals are satisfied.
Overview of System Design
• Layer relationship
– Layer A “Calls” Layer B (runtime)
– Layer A “Depends on” Layer B (“make” dependency,
compile time)
• Partition relationship
– The subsystem have mutual but not deep knowledge
about each other
– Partition A “Calls” partition B and partition B “Calls”
partition A
Software Architectural Styles
* *
Client
requester provider service1()
service2()
…
serviceN()
• The request for a service is usually done via a remote procedure
call mechanism or a common object broker (e.g., CORBA, Java
RMI, or HTTP). Control flow in the clients and the servers is
independent except for synchronization to manage requests or to
receive results.
• Clients request services from one or more Servers. The Server
has no knowledge of the Client.
• An information system with a central database is an example of a
client/server architectural style.
• The clients are responsible for receiving inputs from the user,
performing range checks, and initiating database transactions
when all necessary data are collected.
• The server is then responsible for performing the transaction and
guaranteeing the integrity of the data.
The Web as an instance of the client/server architectural style (UML
deployment diagram).
service1()
service2() *
…
provider
serviceN()
1. updateData
application1:DBUser
database:DBMS
application2:DBUser
2. changeNotification
Repository Architectural Style
SemanticAnalyzer
SyntacticAnalyzer
Optimizer
LexicalAnalyzer CodeGenerator
understanding system
(“Blackboard architecture”) ParseTree SymbolTable
• Database Management
Systems
• Modern Compilers SourceLevelDebugger SyntacticEditor
Model/View/Controller Architectural Style
• Subsystems are classified into 3 different types
– Model subsystem: Responsible for application domain knowledge
– View subsystem: Responsible for displaying application domain
objects to the user
– Controller subsystem: Responsible for managing sequence of
interactions with the user and notifying views of changes in the
model.
• MVC is a special case of a repository architecture:
– Model subsystem implements the central datastructure, the
Controller subsystem explicitly dictate the control flow
initiator
Controller
* 1 repository
Model
1 notifier
subscriber
View
*
• The Controller gathers input from the user and sends
messages to the Model.
• The Model maintains the central data structure.
• The Views display the Model and are notified (via a
subscribe/notify protocol) whenever the Model is changed.
• MVC is well suited for interactive systems, especially when
multiple views of the same model are needed.
• MVC can be used for maintaining consistency across
distributed data
Pipe and Filter Architectural Style
• Component Diagram
– A graph of components connected by dependency
relationships.
– Shows the dependencies among software components
• source code, linkable libraries, executables
• Dependencies are shown as dashed arrows from the client
component to the supplier component.
– The kinds of dependencies are implementation language
specific.
• A component diagram may also be used to show
dependencies on a façade:
– Use dashed arrow the corresponding UML interface.
Component Diagram Example
Scheduler reservations
UML Component
UML Interface
Planner update
GUI
Deployment Diagram
<<include>>
StartServer
PlanningService
Administrator <<include>>
ManageServer ShutdownServer
<<include>>
ConfigureServer
Boundary Condition Questions
• Initialization
– How does the system start up?
• What data need to be accessed at startup time?
• What services have to registered?
– What does the user interface do at start up time?
• How does it present itself to the user?
• Termination
– Are single subsystems allowed to terminate?
– Are other subsystems notified if a single subsystem terminates?
– How are local updates communicated to the database?
• Failure
– How does the system behave when a node or communication link
fails? Are there backup communication links?
– How does the system recover from failure? Is this different from
initialization?
Modeling Boundary Conditions