modern methods in software engineering system …misha/id2207/2014/lectures/syste… · ·...
TRANSCRIPT
Modern methods in Software Engineering
System Design
www.imit.kth.se/courses/2G1522
1
Literature used
• Text Book Chapters 6 and 7
2
Content Overview of System Design Activities:
1. Design Goals 2. Subsystem Decomposition 3. Other activities Hardware/Software Mapping Persistent Data Management Global Resource Handling and Access Control Software Control Boundary Conditions
3
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
4
Analysis & Design • Analysis: Focuses on the application domain • Design: Focuses on the solution domain
– Design knowledge is a moving target – The reasons for design decisions are changing very
rapidly • Halftime updating knowledge in solution domain: About 3-5
years • Cost of hardware rapidly sinking
• “Design window”: – Time in which design decisions have to be made
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
5
System Design Activities
System design
Object design
object design model
design goals
subsystem decomposition
Analysis
analysis object model
dynamic model
nonfunctional requirements
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
System Design
2. System
Layers/Partitions Cohesion/Coupling
5. Data
1. Design Goals Defi nition
T rade-of fs
4. Hardware/
Special purpose
Software e
Buy or Build Trade-off Allocation Connectivity
3. Concurrency
Data structure
Persistent Objects Databases
Management Access control Security
6. Global Resource Handling
8. Boundary Conditions
Initialization T ermination Failure
Decomposition
Mapping
7. Software Control
Identification of Threads of control
Monolithic Event-Driven Threads Conc. Processes
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
7
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 – Activity 8: Boundary conditions
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
8
Example: Current Desktop Development
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
Single Output Device
Precise Input
Direction where the user looks is
irrelevant
Fixed Network Connection
Location of user does not
matter
Identify Current Technology Constraints
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
Single Output Device
Precise Input
Direction where the user looks is
irrelevant
Fixed Network Connection
Location of user does not
matter
Multiple Output Devices
Vague Input
Direction where the user looks is
relevant
Dynamic Network Connection
Location-based
Generalize Constraints using Technology Enablers
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
Design Goals
• Reliability • 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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
Relationships among Design Goals
Reliability
Low cost Increased Productivity Backward-Compatibility Traceability of requirements Rapid development Flexibility
Client
End User
(Customer,
Portability Good Documentation
Runtime Efficiency
Sponsor)
Developer/ Maintainer
Minimum # of errors Modifiability, Readability Reusability, Adaptability Well-defined interfaces
Functionality User-friendliness Ease of Use Ease of learning Fault tolerant Robustness
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
Design goals grouping • Performance
– Response time – Throughput – Memory
• Dependability – Robustness – Reliability – Availability – Fault tolerance – Security – Safety
• End-user criteria – Utility – Usability
• Cost – Development cost – Deployment cost – Upgrade cost – Maintenance cost – Administration cost
• Maintenance – Extensibility – Modifiability – Adaptability – Portability – Readability – Traceability of requirements
14
Design Trade-offs • Space vs. Speed • Efficiency vs. Portability • Rapid development vs. Functionality • Cost vs. Reusability • Backward Compatibility vs. Readability • Delivery time vs. Quality • Delivery time vs. Functionality • …
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
System Decomposition • Subsystem
– Collection of classes, associations, operations, events and constraints that are interrelated
– Seed for subsystems: UML Use cases, Objects and Classes.
• Service: – Group of operations provided by the subsystem (a set
of related operations that share a common purpose) – 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.
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
Coupling and Cohesion • Goal: Reduction of complexity while change occurs • Coupling measures dependencies between subsystems
– High coupling: Changes to one subsystem will have high impact on the other subsystem (change of model, massive recompilation, etc.)
– Low coupling: A change in one subsystem does not affect any other subsystem
• Cohesion measures the dependence within the system – High cohesion: The classes in the subsystem perform similar tasks
and are related to each other (via associations) – Low cohesion: Lots of miscellaneous and auxiliary classes, no
associations • Subsystems should have as maximum cohesion and
minimum coupling as possible: – How can we achieve high cohesion? – How can we achieve loose coupling?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
Reducing coupling
MapManagement
IncidentManagement
Database
ResourceManagement
Alternative 1: Direct access to the Database subsystem
MapManagement IncidentManagement
Storage
ResourceManagement
Database
Alternative 2: Indirect access to the Database through a Storage subsystem
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
18
Increasing cohesion Alternative
Decision
Criterion
subtasks
* SubTask
ActionItem
DesignProblem
Task
assesses
solvableBy
resolvedBy
based-on
* * *
implementedBy
DecisionSubsystem
Alternative 1
Alternative 2
subtasks
*
assesses
solvableBy resolvedBy
based-on
* * *
implementedBy
RationaleSubsystem
PlanningSubsystem
Criterion Alternative
Decision
DesignProblem
SubTask
ActionItem Task 19
Partitions and Layers Partitioning and layering are techniques to achieve
low coupling. 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 subsystem services to a higher layers (level of abstraction) – A layer can only depend on lower layers – A layer has no knowledge of higher layers
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Subsystem Decomposition into Layers
• Subsystem Decomposition Heuristics: – No more than 7+/-2 subsystems at any layer
• More subsystems increase cohesion but also complexity (more services)
– No more than 7+/-2 layers, use 3 layers (good)
F:SubsystemE:Subsystem G:Subsystem
D:SubsystemC:SubsystemB:Subsystem
A: Subsystem Layer 1
Layer 2
Layer 3
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Closed Architecture (Opaque Layering)
• Any layer can only invoke operations from the immediate layer below
• Design goal: High maintainability, flexibility
VM4
VM3
VM2
VM1 C1
attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
Open Architecture (Transparent Layering)
• Any layer can invoke operations from any layers below
• Design goal: Runtime efficiency
VM4
VM3
VM2
VM1 C1
attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
Layered Architecture Application
Presentation
Session
Transport
Network
DataLink
Physical
Leve
l of a
bstra
ctio
n
• 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.
• Closed software architecture
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
Virtual Machine
VM4
VM3
VM2
VM1 C1 attr opr
C1 attr opr
C1 attr opr
C1 attr opr
C1 attr opr
C1 attr opr
C1 attr opr
C1 attr opr
Problem
Existing System Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
25
Properties of Layered Systems • Layered systems are hierarchical. They are
desirable because hierarchy reduces complexity (by low coupling).
• Closed architectures are more portable. • Open architectures are more efficient. • Layered systems often have a chicken-and egg
problem – Example: Debugger
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
G: Op. System
D: File System A: Debugger
26
Choosing Subsystems • Criteria for subsystem selection: Most of the
interaction should be within subsystems (High cohesion), rather than across subsystem boundaries (Low coupling).
• Primary Question: – What kind of service is provided by the subsystems
(subsystem interface)?
• Secondary Question: – Can the subsystems be hierarchically ordered (layers)?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
27
Heuristics for grouping objects into subsystems
• Assign objects identified in one use case into the same subsystem
• Minimize the number of associations crossing subsystem boundaries
• All objects in the same subsystem should be functionally related
• …
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
Software Architectural Styles
• Subsystem decomposition – Identification of subsystems, services, and their
relationship to each other. • Specification of the system decomposition is critical. • Patterns for software architecture
– Client/Server – Peer-To-Peer – Repository – Model/View/Controller – Pipes and Filters – …
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
29
System as a set of subsystems communicating via a software bus
Authoring
Modeling
Augmented Reality
Workorder Repair
Inspection
Workflow
A Subsystem Interface Object publishes the service (= Set of public methods) provided by the subsystem
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
Repository Architectural Style • 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()
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
Repository Architectural Style
LexicalAnalyzer
SyntacticAnalyzer SemanticAnalyzer
CodeGenerator
Compiler
SyntacticEditor
ParseTree SymbolTable
Repository
SourceLevelDebugger
Optimizer
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
Client/Server Architectural Style • One or many servers provide 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 immediate • Users interact only with the client
Client
Server
service1()service2()
serviceN()…
**
requester provider
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
33
Client/Server Architectural Style • 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)
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
34
Design Goals for Client/Server Architectural Style
• Service Portability – Service can be installed on a variety of machines and operating
systems and functions in a variety of networking environments • Transparency, Location-Transparency
– The server might itself be distributed, 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 should have spare capacity to handle larger number of
clients • Flexibility
– The system should be usable for a variety of user interfaces and end devices (eg. WAP Handy, wearable computer, desktop)
• Reliability – System should survive node or communication link problems
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
35
Peer-to-Peer Architectural Style • Generalization of Client/Server Architecture • Clients can be servers and servers can be clients • More difficult because of possibility of deadlocks
Peer
service1()service2()
serviceN()…
requester
provider
*
*
application1:DBUser
database:DBMS
application2:DBUser
1. updateData
2. changeNotification
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
36
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
• 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
1
*
View
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
37
Sequence of Events (Collaborations)
: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
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
38
Three-tier architectural style.
Interface
Application Logic
Storage
Connection
Form
Query
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
39
Four-tier architectural style.
Presentation Server
Application Logic
Storage
Connection
Form
Query
Presentation Client WebBrowser
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
40
Pipe and filter architectural style.
Pipe input output
output input * 1
* 1 Filter
% ps auxwww | grep dutoit | sort | more
dutoit 19737 0.2 1.6 1908 1500 pts/6 O 15:24:36 0:00 -tcsh dutoit 19858 0.2 0.7 816 580 pts/6 S 15:38:46 0:00 grep dutoit dutoit 19859 0.2 0.6 812 540 pts/6 O 15:38:47 0:00 sort
ps grep sort more
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
Intermediate Summary • 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 Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
42
System Design Activities (continue)
– Hardware/Software Mapping – Persistent Data Management – Global Resource Handling and Access Control – Software Control – Boundary Conditions
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
43
Hardware/Software Mapping • This activity addresses two questions:
– How shall we realize the subsystems: Hardware or Software?
– How is the object model mapped on the chosen hardware & software?
• Mapping Objects onto Reality: Processor, Memory, Input/Output
• Mapping Associations onto Reality: Connectivity
• Much of the difficulty of designing a system comes from meeting externally-imposed hardware and software constraints. – Certain tasks have to be at specific locations
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
44
UML: Component and Deployment diagrams
• Models for physical implementation of the system • Show system components, their structure and dependencies
and how they are deployed on computer nodes • Two kinds of diagrams:
– component diagrams – deployment diagrams
• Component diagrams show structure of components, including their interface and implementation dependencies
• Deployment diagrams show the runtime deployment of the system on computer nodes
45
Component Diagrams (component interface)
<<component>> OnLinePayment
PaymentTransaction
IdentityManagement
<<component>> OnLinePayment
<<interface>> PaymentTransaction
begin() commit() rollback() addLineitem() deleteLineItem() <<interface>>
IdentifyManagement
authenticate()
<<use>>
Adopted from Shaum
46
Component Diagram
<<component>> OnLinePayment
PaymentTransaction
IdentityManagement
<<component>> InsuranceBrokerage
<<component>> MemberManagement
<<component>> EPayDay
Adopted from Shaum
47
Deployment diagrams
Web-Server PC
<<TCP/IP>>
stockholm:PCClient madrid:PCClient dehli:PCClient
boss:PCServer
<<TCP/IP>> <<TCP/IP>> <<TCP/IP>>
Adopted from Shaum
48
Deployment diagrams
:MainServer
:JBossServer :CertifiedClock <<J2EE Container>> <<device>>
Adopted from Shaum
49
Drawing Hardware/Software Mappings in UML
• System design must model static and dynamic structures: – Component Diagrams for static structures
• show the structure at design time or compilation time
– Deployment Diagram for dynamic structures • show the structure of the run-time system
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
Deployment Diagrams (artifact)
• Component
• Artifact
51
Manifestation relationship between artifacts and components
52
Location of Artifacts on the node
53
Data Management • Some objects in the models need to be persistent
• A persistent object can be realized with one of the following – Files
• Cheap, simple, permanent storage • Low level (Read, Write) • Applications must add code to provide suitable level of
abstraction – Database
• Powerful, easy to port • Supports multiple writers and readers
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
54
File or DB? When should you choose flat files? • Voluminous data (e.g., images) • Temporary data (e.g., core file) • Low information density (e.g., archival files, history logs)
When should you choose a relational or an object-oriented database? • Concurrent accesses • Access at finer levels of detail • Multiple platforms or applications for the same data
When should you choose a relational database? • Complex queries over attributes • Large data set
When should you choose an object-oriented database? • Extensive use of associations to retrieve data • Medium-sized data set • Irregular associations among objects
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
55
Global Resource Handling
• Discusses access control • Describes access rights for different classes
of actors • Describes how object guard against
unauthorized access
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
56
Access Matrix Implementations • Global access table: Represents explicitly every cell in the
matrix as a (actor,class, operation) tuple. – Determining if an actor has access to a specific object requires
looking up the corresponding tuple. If no such tuple is found, access is denied.
• Access control list associates a list of (actor, operation) pairs with each class to be accessed. – Every time an object is accessed, its access list is checked for the
corresponding actor and operation. – Example: guest list for a party.
• A capability associates a (class,operation) pair with an actor. – A capability provides an actor to gain control access to an object
of the class described in the capability. – Example: An invitation card for a party.
• Which is the right implementation?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
57
Decide on Software Control
Choose implicit control (non-procedural, declarative languages) – Rule-based systems – Logic programming
Choose explicit control (procedural languages): • Procedure-driven control
– Control resides within program code. Operations wait for input whenever they need data from an actor. Example: Main program calling procedures of subsystems.
– Simple, easy to build, hard to maintain (high recompilation costs) • Event-driven control
– Control resides within a dispatcher calling functions via callbacks. – Very flexible, good for the design of graphical user interfaces, easy
to extend
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
58
Centralized vs. Decentralized Designs
• Should you use a centralized or decentralized design? – Take the sequence diagrams and control objects from the analysis
model – Check the participation of the control objects in the sequence
diagrams • If sequence diagram looks more like a fork: Centralized design • The sequence diagram looks more like a stair: Decentralized design
• Centralized Design – One control object or subsystem ("spider") controls everything
• Pro: Change in the control structure is very easy • Cons: The single control object is a possible performance bottleneck
• Decentralized Design – Not a single object is in control, control is distributed, that means,
there is more than one control object • Cons: The responsibility is spread out – changes are not obvious • Pro: Fits nicely into object-oriented development
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
59
Boundary Condition Questions • Initialization
– How does the system start up? • What data need to be accessed at startup time? • What services have to be 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? Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
60
Modeling Boundary Conditions
• Boundary conditions are best modeled as use cases with actors and objects.
• Actor: often the system administrator • Interesting use cases:
– Start up of a subsystem – Start up of the full system – Termination of a subsystem – Error in a subystem or component, failure of a
subsystem or component
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
61
ManageServer Use Case
PlanningService
ManageDrivers
ManageMaps
ManageServer
Administrator StartServer
ShutdownServer
ConfigureServer
<<include>>
<<include>>
<<include>>
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
62
Summary In this lecture, we reviewed the activities of system design : • Design goals identification • System decomposition • Concurrency identification • Hardware/Software mapping • Persistent data management • Global resource handling • Software control selection • Boundary conditions
Each of these activities revises the subsystem decomposition to address a specific issue. Once these activities are completed, the interface of the subsystems can be defined.
63
Next lecture
• Object design
Chapters 8 & 9
64
Identifying boundary cases
• Configuration • Start-up and shutdown • Exception handling
– Hardware failure – Changes in operating environment – Software failures
65
Why models?
• Reality R: Real Things, People, Processes happening during some time, Relationship between things
• Model M: Abstractions from (really existing or only thought of ) things, people , processes and relationships between these abstractions.
• We use models – To abstract away from details in the reality, so we can
draw complicated conclusions in the reality with simple steps in the model
– To get insights into the past or presence – To make predictions about the future
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
66
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
67
ARENA Subsystem decomposition
Tournament
Component Management
User Management
Tournament Statistics
User Directory
User Interface
Session Management
Advertisement
68
ARENA Subsystem decomposition
Tournament
Component Management
User Management
Tournament Statistics
User Directory
Session Management
For adding games, styles, and expert
rating formulas"
Stores user profiles (contact &
subscriptions)"Stores results of archived
tournaments"Maintains state during matches."
Administers user accounts"
Advertisement
Manages tournaments, applications, promotions."
User Interface Manages advertisement banners and sponsorships."
69
Concurrency • Identify concurrent threads and address
concurrency issues. • Design goal: response time, performance.
• Threads – A thread of control is a path through a set of state
diagrams on which a single object is active at a time. – A thread remains within a state diagram until an object
sends an event to another object and waits for another event
– Thread splitting: Object does a nonblocking send of an event.
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
70
Concurrency Questions
• Which objects of the object model are independent?
• What kinds of threads of control are identifiable? • Does the system provide access to multiple users? • Can a single request to the system be decomposed
into multiple requests? Can these requests be handled in parallel?
71
N
Bedroom2 Master Bedroom
Dining
Hallway
Stairs
Bath
Kitchen Study
Bath
Kitchen
Master Bedroom Dining
Hallway
Stairs
Entrance
door
Master Bedroom
Bedroom2
Dining
Hallway
Stairs
Entrance door
Study
Study
Bath
Kitchen
Bedroom2
Entrance door
Version 1 Version 2
Version 3 72
Nonfunctional Requirements may give a clue for the use of Design Patterns
• Text: “manufacturer independent”, “device independent”, “must support a family of products” – Abstract Factory Pattern
• Text: “must interface with an existing object” – Adapter Pattern
• Text: “must deal with the interface to several systems, some of them to be developed in the future”, “ an early prototype must be demonstrated” – Bridge Pattern
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
73
Textual Clues in Nonfunctional Requirements
• Text: “complex structure”, “must have variable depth and width” – Composite Pattern
• Text: “must interface to an set of existing objects” – Façade Pattern
• Text: “must be location transparent” – Proxy Pattern
• Text: “must be extensible”, “must be scalable” – Observer Pattern
• Text: “must provide a policy independent from the mechanism” – Strategy Pattern
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
74
A 3-layered Architecture
Repair Inspection Authoring
Augmented Reality
Workflow Modeling
75
UML deployment diagram
:WebServer
myMac:Mac :UnixHost
:IExplorer
aPC:PC
:Database
:UnixHost
:Safari
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
76
Sharpen the Design Goals • Location-based input
– Input depends on user location – Input depends on the direction where the user
looks (“egocentric systems”) • Multi-modal input
– The input comes from more than one input device • Dynamic connection
– Contracts are only valid for a limited time • Is there a possibility of further generalizations? • Example: location can be seen as a special case of
context – User preference is part of the context – Interpretation of commands depends on context
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
77
Event-Driven Control Example: MVC
• Model-View-Controller Paradigm (Adele Goldberg, Smalltalk 80)
:Control
:Model :View
:View
:View Model has changed
Update Update
Update
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
78
Quality of design • Correct
– if the analysis model can be mapped to the system design model • Complete
– if every requirement and every system design issue has been addressed
• Consistent – if it does not contain any contradictions
• Realistic – if the corresponding system can be implemented
• Readable – if developers not involved in the system design can
understand the model
79
The Purpose of System Design
• Bridging the gap between desired and existing system in a manageable way
• Use Divide and Conquer – We model the new system to
be developed as a set of subsystems
Problem
Existing System
New System
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
80
Modern methods in Software Engineering
System Design
www.imit.kth.se/courses/2G1522
81
Introduction Content 0. Overview of System Design 1. Design Goals 2. Subsystem Decomposition 3. Concurrency 4. Hardware/Software Mapping 5. Persistent Data Management 6. Global Resource Handling and Access Control 7. Software Control 8. Boundary Conditions
82
System as a set of subsystems communicating via a software bus
Authoring
Modeling
Augmented Reality
Workorder Repair
Inspection
Workflow
A Subsystem Interface Object publishes the service (= Set of public methods) provided by the subsystem
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
83
Client/Server Architectural Style • 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
Client
Server
service1()service2()
serviceN()…
**
requester provider
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
84
Client/Server Architectural Style • 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
Client
Server
service1()service2()
serviceN()…
**
requester provider
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
85
Peer-to-Peer Architectural Style • Generalization of Client/Server Architecture • Clients can be servers and servers can be clients • More difficult because of possibility of deadlocks
Peer
service1()service2()
serviceN()…
requester
provider
*
*
application1:DBUser
database:DBMS
application2:DBUser
1. updateData
2. changeNotification
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
86
Another view to ISO Model Application
Presentation
Session
Transport
Network
DataLink
Physical
Frame
Packet
Bit
Connection
Format
Message
• A closed software architecture
• Each layer is a UML package containing a set of objects
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
87
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.
– Subsystem Interfaces are refined in Object Design – Should be well-defined and small. – Often called API: Application programmer’s interface - this term
should used during implementation, not during System Design
88
Subsystem Decomposition
Class parts
* System Part
*
Subsystem
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
89
Example: Subsystem Decomposition
Is this the right decomposition or is this too much ravioli?
Modeling
Authoring
Workorder Repair
Inspection
Augmented Reality
Workflow
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
90
Subsystem decomposition of MyTrip
PlanningSubsystem
MapDBStoreSubsystem TripFileStoreSubsystem
RoutingSubsystem
CommunicationSubsystem
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
91
File or Database? • When should you choose a file?
– Are the data voluminous (bit maps)? – Do you have lots of raw data (core dump, event trace)? – Do you need to keep the data only for a short time? – Is the information density low (archival files, history logs)?
• When should you choose a database? – Do the data require access at fine levels of details by multiple
users? – Must the data be ported across multiple platforms (heterogeneous
systems)? – Do multiple application programs access the data? – Does the data management require a lot of infrastructure?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
92
Issues To Consider When Selecting a Database
• Storage space – Database require about triple the storage space of actual data
• Response time – Modern databases are I/O or communication bound (distributed
databases). Response time is also affected by CPU time, locking contention and delays from frequent screen displays
• Locking modes – Pessimistic locking: Lock before accessing object and release when object
access is complete – Optimistic locking: Reads and writes may freely occur (high
concurrency!) When activity has been completed, database checks if contention has occurred. If yes, all work has been lost.
• Administration – Large databases require specially trained support staff to set up security
policies, manage the disk space, prepare backups, monitor performance, adjust tuning.
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
93
Data Management Questions • Should the data be distributed? • Should the database be extensible? • How often is the database accessed? • What is the expected request (query) rate? In the worst
case? • What is the size of typical and worst case requests? • Do the data need to be archived? • Does the system design try to hide the location of the
databases (location transparency)? • Is there a need for a single interface to access the data? • What is the query format? • Should the database be relational or object-oriented?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
94
Global Resource Questions • Does the system need authentication? • If yes, what is the authentication scheme?
– User name and password? Access control list – Tickets? Capability-based
• What is the user interface for authentication? • Does the system need a network-wide name
server? • How is a service known to the rest of the system?
– At runtime? At compile time? – By port? – By name?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
95
Allocation subsystems to hardware
RoutingSubsystem.jar PlanningSubsystem.jar
:OnBoardComputer :WebServer
96
General Design Activities
• Identify design goals.
• Design the initial subsystem decomposition.
• Refine the subsystem decomposition to address the design goals.
97
Mapping the Subsystems Associations: Connectivity
• Describe the physical connectivity of the hardware – Often the physical layer in ISO’s OSI Reference Model
• Which associations in the object model are mapped to physical connections?
• Which of the client-supplier relationships in the analysis/design model correspond to physical connections?
• Describe the logical connectivity (subsystem associations) – Identify associations that do not directly map into physical
connections: • How should these associations be implemented?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
98
Logical vs Physical Connectivity
Application Layer Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
Bidirectional associa- tions for each layer"
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
Processor 1! Processor 2!
Logical!Connectivity!Layers!
Physical!Connectivity!
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
99
An Example of Connectivity Drawing DistributedDatabaseArchi tecture Tue, Oct 13 , 1992 12:53 AM
Application Cl ient
Application Cl ient
Application Cl ient
Co mmunication Agent for
Application Clients
Co mmunication Agent for
Application Clients
Co mmunication Agent for Data
Server
Co mmunication Agent for Data
Server
Local Data Server
Global Data Server
Global Data Server
Global Data
Server
OODBMS
RDBMS
Backbone Network
LAN
LAN
LAN
TCP/IP Ethernet
Physical Connectivity
Logical Connectivity
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
100
Deployment specification
Adopted from UML2.0-03-08-02
101
Decomposition for an accident management system
Notification IncidentManagement
FieldOfficerInterface DispatcherInterface
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
102
Hardware/Software Mapping Questions
• What is the connectivity among physical units? – Tree, star, matrix, ring
• What is the appropriate communication protocol between the subsystems? – Function of required bandwidth, latency and desired reliability,
desired quality of service (QoS) • Is certain functionality already available in hardware? • Do certain tasks require specific locations to control the
hardware or to permit concurrent operation? – Often true for embedded systems
• General system performance question: – What is the desired response time?
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
103
Overview of System Design Activities
Describe boundary conditions
Define Define subsystems
Map subsystems to hardware/
Manage
Select a
Define access
design goals
persistent data
control policies
global
Implement subsystems
software platform
control flow
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
104
Deployment Diagram
<<artifact>> Router.jar
:OnBoardComputer
<<artifact>> Planner.jar
:WebServer <<artifact>>
DB.jar
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
105
Defining Access Control
• In multi-user systems different actors have access to different functionality and data. – During analysis we model these different accesses by
associating different use cases with different actors. – During system design we model these different access
by examing the object model by determining which objects are shared among actors.
• Depending on the security requirements of the system, we also define how actors are authenticated to the system and how selected data in the system should be encrypted.
Adopted from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
106
Peer
Client Server
107
Component Diagram (component realization)
<<component>> OnLinePayment
IdentityManagement PaymentTransaction
<<realization>> Payment PaymentItem PaymentController
Payment PaymentItem PaymentController
Adopted from Shaum
108
Component Diagram
Scheduler
Planner
GUI
reservations
update
<<component>>
<<component>>
<<component>>
109
Modern methods in Software Engineering
System Design
www.imit.kth.se/courses/2G1522
110
Literature used
• Text Book Chapters 6 and 7
111
Introduction Content Overview of System Design Activities:
1. Design Goals 2. Subsystem Decomposition 3. Other activities Hardware/Software Mapping Persistent Data Management Global Resource Handling and Access Control Software Control Boundary Conditions
112