1. TJSS luennot System Design Lecture 1

2. Design
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”
- C.A.R. Hoare
Compared with Requirements Analysis System design is messy.
One of the reasons is that the analysis depends on the application domain. When entering design, we add the implementation domain. We worry about how to map the application domain expressed in the system model (object model, dynamic model, functional model) into the existing hardware.
Unfortunately this is not a well known science. Again only heuristics are known. Unfortunately even these heuristics have a half-life of 2-5 years. One of the problems is that we are still making incredible progress in computer science which is driven by technology
20 years ago we every analysis was mapped on a main frame. It was too expensive to waste cycles.
With the advence of minis and LAN networks, people started talking about client/server architectures and mapped their analysis onto distributed networks of computers
One of the questions a designer faces is performance vs reliability. If a certain design needs to be optimized because the response time is too slow, what should the designer do? Pick a Cray or a network of Sun workstations?

3. Why is Design so Difficult?
Analysis: Focuses on the application domain
Design: Focuses on the implementation domain
Design knowledge is a moving target
The reasons for design decisions are changing very rapidly
Halftime knowledge in software engineering: About 3-5 years
What I teach today will be out of date in 3 years
Cost of hardware rapidly sinking
“Design window”:
Time in which design decisions have to be made

4. The Purpose of System Design
Requirement
Bridging the gap between desired requirements and desired system in a manageable way
Use Divide and Conquer
We model the system to be developed as a set of subsystems
System Design
Desired system

5. System Design System Design 1. Design Goals 8. Boundary Conditions
nition T
rade-of fs
8. Boundary
Conditions
Initialization T
ermination
2. System
Failure
Decomposition
Layers/Partitions
Coherence/Coupling
7. Software
Control
1. Design goals
2. System decomposition
Breaking the system into subsystems, Layers and partitions, System information flow (topology)
3. Identification of concurrency
Threads of control
4. Hardware/software allocation
Estimate hardware requirements, Hardware/software trade-offs, Describe processor allocation, Physical connectivity (existing hardware)
5. Data management
Data structures implemented in memory or secondary storage
6. Global resource handling
Choose access control
7. Software control implementation
Procedure-based, event-based, concurrent systems
8. Boundary conditions
Describe behavior at initialization, termination and failure
9. Feasibility
Discuss design alternatives, Technological constraints that drive the design, What if the constraints change?
Monolithic
Event-Driven
Threads
Conc. Processes
3. Concurrency
6. Global
Identification of
Threads
4. Hardware/
5. Data
Softwar e
Resource Handling
Management
Mapping
Access control
Security
Persistent Objects
Special purpose
Files
Buy or Build Trade-off
Databases
Allocation
Data structure
Connectivity

6. Overview System Design I System Design II (next lecture)
0. Overview of System Design
1. Design Goals
2. Subsystem Decomposition
3. Example: From Objects to Subsystems
System Design II (next lecture)
3. Concurrency
4. Hardware/Software Mapping
5. Persistent Data Management
6. Global Resource Handling and Access Control
7. Software Control
8. Boundary Conditions
Rumbaugh distinguishes two kinds of design: System design and Object design. System design, the topic of this and the next lecture is concerned with the overall aspects of the system. What are the goals it tries to achieve. The main goals are: Low cost, good response time, high reliability. Types (Often listed under Global requirements in Problem Statement). Trade-off priorities
System design is also concerned about the overall structure of the system. How is it broken into pieces? How do these pieces fit together? Must they know about each other? The best system design is one where the interaction between the subsystems is minimal.
Concurrency is another important design issue. The more concurrency we can identify in a system, the better it can perform.
Mapping the subsystem to processors is the moment of truth, and the hardest. While decomposotion and concurrency identification are still independent of technology, subsystem allocation is not. Shall we map them to hardware or can we get by with software (Example: Floating point package).
The management of data is also a design issue. The FRIEN database group is an example: Most of its problems are design specific.
Access methods specify the security of the design. Can a random user or a program gone hay-wire create havoc to the rest of the system?
Control is another important design issue. Who is in control? A main program or a set of harmoniously cooperating processes?
Boundary conditions specify the non-steady state behavior of the system. Usually the designer worries about the steady state (average number of transactions/sec). However, initialization and termination behavior, in particular failure conditions are important design issues. How does the system behave when an error occurs? Does it simply type "Illegal address at PC 0. Abort!" (Famous last words on a screen cockpit filmed by a video camera before the plane, an F-15 fighter, crashed).
For the FRIEND system, database design issues are very important. We will discuss several design goals that are very important for the design of distributed databases

7. How to use the results from the Requirements Analysis for System Design
Nonfunctional requirements =>
Activity 1: Design Goals Definition
Use Case model =>
Activity 2: System decomposition (Selection of subsystems based on functional requirements, coherence, 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
Activity 8: Boundary conditions
In Requirements analysis we have beautifully built 3 descriptions of the problem, the models. Where do the models go in system design?
If you read Rumbaugh, the above list of system design issues looks a little bit random. But there is a reason behind it:

8. Section 1. Design Goals Reliability Good documentation Modifiability
Maintainability
Understandability
Adaptability
Reusability
Efficiency
Portability
Traceability of requirements
Fault tolerance
Backward-compatibility
Cost-effectiveness
Robustness
High-performance
Good documentation
Well-defined interfaces
User-friendliness
Reuse of components
Rapid development
Minimum # of errors
Readability
Ease of learning
Ease of remembering
Ease of use
Increased productivity
Low-cost
Flexibility

9. Relationship Between Design Goals
End User
Low cost
Increased Productivity
Backward-Compatibility
Traceability of requirements
Rapid development
Flexibility
Functionality
User-friendliness
Ease of Use
Ease of learning
Fault tolerant
Robustness
Runtime
Efficiency
Reliability
Portability
Good Documentation
Client
(Customer,
Sponsor)
Minimum # of errors
Modifiability, Readability
Reusability, Adaptability
Well-defined interfaces
Developer/
Maintainer

10. Typical Design Trade-offs
Functionality vs. Usability
Cost vs. Robustness
Efficiency vs. Portability
Rapid development vs. Functionality
Cost vs. Reusability
Backward Compatibility vs. Readability

11. System Decomposition Subsystem (UML: Package) Service:
Collection of classes, associations, operations, events and constraints that are interrelated
Seed for subsystems: UML Objects and Classes.
Service:
Group of operations provided by the subsystem
Seed for services: Subsystem use cases
Service is specified by Subsystem interface:
Specifies interaction and information flow from/to subsystem boundaries, but not inside the subsystem.
Should be well-defined and small.
Often called API: Application programmer’s interface, but this term should used during implementation, not during System Design
Relation of subsystems to each other is similar to object model
System topology is similar functional model!

12. Services and Subsystem Interfaces
Service: A set of related operations that share a common purpose
Notification subsystem service:
LookupChannel()
SubscribeToChannel()
SendNotice()
UnscubscribeFromChannel()
Services are defined in System Design
Subsystem Interface: Set of fully typed related operations. Also called application programmer interface (API)
Subsystem Interfaces are defined in Object Design

13. Choosing Subsystems
Criteria for subsystem selection: Most of the interaction should be within subsystems, rather than across subsystem boundaries (High coherence).
Does one subsystem always call the other for the service?
Which of the subsystems call each other for service?
Primary Question:
What kind of service is provided by the subsystems (subsystem interface)?
Secondary Question:
Can the subsystems be hierarchically ordered (layers)?
What kind of model is good for describing layers and partitions?

14. Example: STARS Subsystem Decomposition
Authoring
Augmented
Reality
Modeling
Workflow
Inspection
Repair
Workorder

15. Definition: Subsystem Interface Object
A Subsystem Interface Object provides a service
This is the set of public methods provided by the subsystem
The Subsystem interface describes all the methods of the subsystem interface object
Use a Facade pattern for the subsystem interface object

16. STARS as a set of subsystems communicating via a software bus
Authoring
Modeling
Workflow
Augmented
Reality
Inspection
Repair
Workorder
A Subsystem Interface Object publishes the service (= Set of public methods)
provided by the subsystem

17. STARS as a 3-layered Architecture
Repair
Inspection
Authoring
Augmented
Reality
Workflow
Modeling
What is the relationship between Modeling and Authoring?
Are other subsystems needed?

18. Coupling and Coherence
Goal: Reduction of complexity
Coherence measures the dependence among classes
High coherence: The classes in the subsystem perform similar tasks and are related to each other (via associations)
Low coherence: Lots of misc and aux objects, no associations
Coupling measures dependencies between subsystems
High coupling: Modifications to one subsystem will have high impact on the other subsystem (change of model, massive recompilation, etc.)
Subsystems should have as maximum coherence and minimum coupling as possible:
How can we achieve loose coupling?
Which subsystems are highly coupled?

19. Partitions and Layers
A large system is usually decomposed into subsystems using both, layers and partitions.
Partitions vertically divide a system into several independent (or weakly-coupled) subsystems that provide services on the same level of abstraction.
A layer is a subsystem that provides services to a higher level of abstraction
A layer can only depend on lower layers
A layer has no knowledge of higher layers
In an object-oriented design such as JEWEL, each subsystem makes its layer a subclass of the generic layer class provided by the UI subsystem. Each individual subsystem must provide for its own zoom and refresh methods. Ideally the refresh method will be called for every draw operation. The UI subsystem is responsible for knowing when to call for a refresh (but the UI group will not have to implement it itself: it is a callback method implemented by the visualization and GIS group). All the interfaces with UI (such as how UI will provide the other groups with selection information) should be well documented and agreed on by all groups.

20. Subsystem Decomposition into Layers
Subsystem Decomposition Heuristics:
No more than 7+/-2 subsystems
More subsystems increase coherence but also complexity (more services)
No more than 5+/-2 layers

21. Layer and Partition Relationships between Subsystems
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

22. Closed Architecture (Opaque Layering)
VM4
VM3
VM2
VM1 C1
attr op
A virtual machine can only call operations from the layer below
Design goal: High maintainability

23. Open Architecture (Transparent Layering)
A virtual machine can call operations from any layers below
Design goal: Runtime efficiency C1
attr op C1
attr op C1
attr op
VM1 C1
attr op C1
attr op
VM2 C1
attr op C1
attr op
VM3 C1
attr op C1
attr op
VM4

24. Properties of Layered Systems
Layered systems are hierarchical. They are desirable because hierarchy reduces complexity.
Closed architectures are more portable.
Open architectures are more efficient.

25. Software Architecture
As a complexity of systems increases, the specification of software architecture comes more critical
No universal acceptance of software architecture
A software architecture includes the system decomposition, the global control flow, error-handling policies and intersubsystem communication protocols [Shaw&Garlan, 1996]
The structure of the components of a system, their interrelationships, and principles and guidelines governing their design and evolution over time [Garlan, Perry, 1995]
UML 1.3:
Architecture is the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems.
Kruchten and RUP:
Architecture is represented by a number of different architectural views, which in their essence are extracts illustrating the "architecturally significant" elements of the models. Each architectural view addresses some specific set of concerns, specific to stakeholders in the development process: end users, designers, managers, system engineers, maintainers, and so on.
Use case view, Logical view, Implementation view, Process View, Deployment View

26. Architectural Style
An architectural style defines a family of systems in terms of pattern of structural organization. An architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined
Examples from architectural styles:
Client/Server Architecture
Peer-To-Peer Architecture
Repository Architecture
Model/View/Controller
Pipes and Filters Architecture

27. Client/Server Architecture
One or many servers provides services to instances of subsystems, called clients.
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
Response in general immediately
Users interact only with the client

28. Client/Server Architecture
Often used in database systems:
Front-end: User application (client)
Back end: Database access and manipulation (server)
Functions performed by client:
Customized user interface
Front-end processing of data
Initiation of server remote procedure calls
Access to database server across the network
Functions performed by the database server:
Centralized data management
Data integrity and database consistency
Database security
Concurrent operations (multiple user access)
Centralized processing (for example archiving)

29. Design Goals for Client/Server Systems
Portability
Server can be installed on a variety of machines and operating systems and functions in a variety of networking environments
Transparency
The server might itself be distributed (why?), but should provide a single "logical" service to the user
Performance
Client should be customized for interactive display-intensive tasks
Server should provide CPU-intensive operations
Scalability
Server has spare capacity to handle larger number of clients
Flexibility
Should be usable for a variety of user interfaces
Reliability
System should survive individual node and/or communication link problems

30. Problems with Client/Server Architectures
Layered systems do not provide peer-to-peer communication
Peer-to-peer communication is often needed
Example: Database receives queries from application but also sends notifications to application when data have changed

31. Peer-to-Peer Architecture
Generalization of Client/Server Architecture
Clients can be servers and servers can be clients
More difficult because of possibility of deadlocks

32. Example of a Peer-to-Peer Architecture
Application
Presentation
Session
Transport
Network
DataLink
Physical
Frame
Packet
Bit
Connection
Format
Message
Level of abstraction
ISO’s OSI Reference Model
ISO = International Standard Organization
OSI = Open System Interconnection
Reference model defines 7 layers of network protocols and strict methods of communication between the layers.

33. Middleware Allows You To Focus On The Application Layer
Presentation
Session
Transport
Network
DataLink
Physical
Socket
CORBA
TCP/IP
Object
Ethernet
Wire

34. Model/View/Controller
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 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
Controller
Model
subscriber
notifier
initiator *
repository 1
View

35. Example of a File System based on MVC Architecture

36. Sequence of Events 2.User types new filename :Controller
:InfoView
:Model
2.User types new filename
1. Views subscribe to event
3. Request name change in model
4. Notify subscribers
5. Updated views
:FolderView

37. Repository Architecture
Subsystems access and modify data from a single data structure
Subsystems are loosely coupled (interact only through the repository)
Control flow is dictated by central repository (triggers) or by the subsystems (locks, synchronization primitives)
Subsystem
Repository
createData()
setData()
getData()
searchData()

38. Examples of Repository Architecture
Compiler
SemanticAnalyzer
SyntacticAnalyzer
Optimizer
CodeGenerator
LexicalAnalyzer
Repository
Hearsay II speech understanding system (“Blackboard architecture”)
Database Management Systems
Modern Compilers
ParseTree
SymbolTable
SourceLevelDebugger
SyntacticEditor

39. Summary System Design Design Goals Definition Subsystem Decomposition
Reduces the gap between requirements and the computer system
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

40. Example: From Objects to Subsystems
A route planning system for car drivers, MyTrip
Identify design goals from the nonfunctional requirements
Design an initial subsystem decomposition

41. Starting point: analysis model for route planning system
Using MyTrip, a driver can plan a trip from a home computer by contacting a trip planning service on the Web. The trip is saved for later retrieval on the server. The trip planning service must support more than one driver
Use cases: PlanTrip and ExecuteTrip
Object model:

42. PlanTrip Use Case Description
Entry condition 1. The Driver activates her home computer and logs into the trip planning WEB service
Flow of events 2. Upon successful login, the Driver enters constraints for a trip as a
sequence of destinations
3. Based on database and maps, the planning service computes the shortest
way visiting the destinations in the special order. The result is a sequence
of segments binding a series or crossings and a list of directions
4. The Driver can revise the trip by adding or removing destinations
Exit condition 5. The Driver saves the planned trip by name in the planning service data-
base for later retrieval

43. ExecuteTrip Use Case Description
Entry condition 1. The Driver starts her car and logs into the onboard route assistant.
Flow of events 2. Upon successful login, the Driver specifies the planning service and the
name of the trip to be executed
3. The onboard route assistant obtains the list of destinations, directions,
segments, and crossings from the planning service
4. Given the current position, the route assistant provides the driver with
the next set of directions.
Exit condition 5. The Driver arrives to destination and shuts down the route assistant.

44. Data Dictionary
Crossing: A Crossing is a geographical point were a driver can choose between several Segments
Destination: A Destination represents a location where the driver wishes to go
Direction: Given a Crossing and an adjacent Segment, a Direction describes in natural language terms how to steer the car onto the given Segment.
Location: A Location is the position of the car as known by onboard GPS system or the number of turns of the wheels
PlanningService: A PlanningService is a WEB server that can supply a trip, linking a number of destinations in the form of a sequence of crossings and segments
RouteAssistant: A RouteAssistant gives Directions to the driver, given the current Location and upcoming Crossing
Segment: A Segment represents the road between two Crossings
Trip: A Trip is a sequence of Directions between two Destinations

45. Nonfunctional requirements for MyTrip
My Trip is in contact with the PlanningService via a wireless model. It can be assumed that the wireless modem functions properly a the initial destination
Once the trip has been started, MyTrip should give correct directions even if modem fails to maintain a connection with the PlanningService
MyTrip should mimize connection time to reduce operation costs
Replanning is possible only if the connection to the PlanningService is possible
The Planning Service can support at least 50 different drivers and 1000 trips

46. Identifying design goals
Identifies the qualities that our system should focus on
Can be inferred from the nonfunctional requirements or from the application domain, and from client
According to MyTrip nonfunctional requirements, reliability, fault tolerance to connectivity loss, security, modifiability are design goals
Reliability: MyTrip should be reliable (from nonfunctinal req 2)
Fault Tolerance: My Trip should be fault tolerant to loss of connectivity with the routing service (from req 2)
Security: My Trip should be secure, i.e., not allow other frivers or nonauthorized users to access another driver’s trip (from application domain)
Modifiability: MyTrip should be modifiable to use different routing services
(from developers)

47. Identifying subsystems
Initial subsystem decomposition should be derived from functional requirements
In MyTrip, two major groups of objects, those objects that are involved during PlanTrip use case, those that are involved during ExecuteTrip use case.
Trip, Direction, Crossing, Segment, Destination classes are shared between both use cases (tighty goupled with each other)
Two subsystems, PlanningSubsystem and RoutingSubsystem according to coupling and coherence (low coupling, high coherence)

48. Subsystem responsibilities
The PlanningSubsystem is responsible for constructing a Trip connecting a sequence of Destinations. The PlanningSubsystem is also responsible for responding to replan requests from RoutingSubsystems
The RoutingSubsystem is responsible for downloading a Trip from the PlanningService and executing it by giving Directions to the driver base on its Location.

49. Heuristics for grouping objects into subsystems
Heuristic for subsystem identification is to keep funtionally related objects together
Assign object identified in one use case into the same subsystem
Create dedicated subsystem for objects used for moving data among subsystems
Minimize the number of associations crossing subsystem boundaries
All objects in the same subsystem should be functionally related