January 26, 2015 Sam Siewert
SE310
Analysis and Design of Software
Systems
Lecture 4 – Architectural Design
Architecture and Design Patterns
Focus on What is Being Designed and Built
OO Has Goal of Design and Software Re-Use
– Encapsulation of Data and Operations
– Class Hierarchy and Object Instances
– Well Understand Use Cases
– Well Understand Interaction Between Objects
Study 4 Key System Types
1. Interactive – E.g. GUI, CLI
2. Event Driven – E.g. Anit-lock Breaking System Software
3. Transformational – E.g. Image Processing, Encode/Decode
[MPEG Digital Video, RAID]
4. Transaction Oriented – E.g. DBMS
Sam Siewert 2
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-3
Four Common Types of Systems
(a) Interactive subsystem
a
b
c
c
z
y x
a
a/x
b/y c/z
b
(b) Event-driven subsystem
(c) Transformational subsystem (d) Database subsystem
Architectural Design
Transition from Requirements, Supports Requirements Analysis, Supports Design Activity
Focus on Domain Analysis, Use Cases and Higher Levels of System Rather than Details
UML – Use Cases
– Interaction Diagrams
– Class Diagrams
– Basic Class Hierarchy (Draft of Class Definitions)
SA/SD – Dataflow, ER/EER Diagrams, High Level State Machines (Flowcharts are Typically Too Detailed)
Sam Siewert 4
Traditional SA/SD – Useful, But Not OO
Data Flow Diagrams – Data [Messages] Between Processes and is Transformed
Entity Relationship Diagrams – Lacks Operations, but Defines Entities [Objects] and Relationships
State Machines [in Common, but Typically for Each Process in DFD]
Flow-Charts – Detailed Procedural Design [Interaction, Logic]
Sam Siewert 5
Stores, Flows, Processes, External Entities
http://en.wikipedia.org/wiki/Finite-state_machine
http://en.wikipedia.org/wiki/Data_flow_diagram
http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
http://en.wikipedia.org/wiki/Flowchart
Domain Models with UML - CASE UML is Universal Modeling Language
Use to Support Requirements Analysis
Sam Siewert 6
Start Here!
https://www.modelio.org/
http://argouml.tigris.org/
Helpful Validation and Verification Features for
Design
• Integrated Models
• Checklists – Completeness
• CPP and Java Code Generation
Tool-Based Activities
Bring Up Modelio and Start Entering ATM Design – Use
Case and Class Diagram, Compare to UML Reference
Versions of UML – 2.4.1 Current
Minute Paper #2 – Do Design Tools Really Assist with
Software Quality Assurance?
Sam Siewert 7
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-8
Key Takeaway Points
• Domain modeling is a conceptualization
process to help the development team
understand the application domain.
• Five easy steps: collecting information about
the application domain; brainstorming;
classifying brainstorming results; visualizing
the domain model using a UML class diagram;
and performing inspection and review.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-9
Acquiring Requirements
(Domain Modeling)
Software architecture
Domain Modeling in the Methodology Context
Deriving Use Cases from Requirements
Allocating Use Cases & Subsystems to Iterations
Business goals & needs
Current situation
Preliminary requirements
Abstract & high level use cases, use case diagrams
Use case-iteration allocation matrix
(a) Planning Phase
control flow data flow control flow & data flow
(b) Iterative Phase – activities during each iteration
Actor-System Interaction Modeling
Domain Modeling
Accommodating Requirements Change
Behavior Modeling & Responsibility Assignment
Deriving Design Class Diagram
Test Driven Development, Integration, & Deployment
Customer feedback
Iteration use cases
Domain model
Expanded use cases & UI design
Behavior models
Design class diagram
Domain model
Use case-iteration allocation matrix
Producing an Architecture Design
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-10
feedback
Architectural Design Process
Review
the
Architectur
al Design
Specify Subsystem
Functions,
Interfaces &
Interaction Behavior
Determine
Design
Objectives
Determine
Type of
System
Apply an
Architectur
al Style
Perform
Custom
Architectural
Design
Types of
System &
Characteristic
s
Architectura
l Styles
Repository
design
objectives
[architectural
style
available]
[architectural
style not
available]
partial design
partial design
Assignment #2 – Domain Models
Learning Objectives – Value of UML for Requirements
Analysis
– Completeness
– Design Walk-throughs
– Validation [Are We Building the Right Thing?]
– Verification [Are We Building it Right?]
New Design, Client-Server [Cloud] Architectural Pattern
Storage-as-a-Service
– The Competition, E.g. Drop-Box, Amazon S3, Google Cloud
Storage
– The Concept – Archive for Unstructured Files (Photos,
Documents, Bits…), Not Code, Not DBMS
Sam Siewert 11
The Requirements – Capabilities Focus 1. Store Any Number of Files (name space) Up to N
Gbytes in an Archive, Browse on Web or Windows,
Mac, Linux File Explorer
2. Protect with RAID Against Single Erasure (Covered in
CS317, SE420)
3. Submit and Retrieve Any File by Name, Time and Date
Archived (In Case of Duplicate Names)
Sam Siewert 12
Assignment #2 Goals
Consistent and Complete UML Design – Domain Model
Focus -Ready for Validation and Verification
Walkthrough
Ideally Capable of C++ or Java Class Code Generation
We Will Walk-through Design for Assignment #3
More In Depth Use of Modelio or ArgoUML
Better Understanding of UML 2.4 – Use Case,
Component, Class, Interaction Diagrams [2 From
Behavior Side, 2 From Structure Side of UML] Sam Siewert 13
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-14
Domain Modeling Steps
3. Classifying
brainstorming
result
1.Collecting application
domain information
2. Brainstorming
4. Visualizing the
domain model 5. Reviewing the
domain model.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-15
Tip for Domain Modeling
4) Have a member or
two to convert the result
to a UML class diagram.
6) Modify the diagram
to reflect corrections
and comments.
Do not do brainstorming and drawing at the
same time. The result could be very poor.
1) Team brainstorming:
List the concepts, and
then classify them on a
whiteboard.
2) Take a picture(s) of
the whiteboard using a
digital camera.
3) Email the
digital images to
team members.
5) Email the UML
class diagram to all
members to review.
RAID Archive Systems - Multiple Disk
Drives
Disk Drives Fail – Like a Light-bulb
– MTBF of 100’s of Thousands of Hours [3 to 5 Years at Duty
Cycle]
– Difficult to Determine When Failure Might Occur
– The Larger the Population, the More Often Failures will be Seen
Disk Drives Have Low Random Access [100 to 200 I/Os
per Second]
Idea – Write to them in Parallel and Mirror Data to
Protect Against HDD Failures (Erasures)
Sam Siewert 16
RAID-10
Sam Siewert 17
A1 A1 A2 A2 A3 A3
A4 A4 A5 A5 A6 A6
RAID-1 Mirror RAID-1 Mirror RAID-1 Mirror
RAID-0 Striping Over RAID-1 Mirrors
A7 A7 A8 A8 A9 A9
A10 A10 A11 A11 A12 A12
A1,A2,A3, … A12
RAID Operates on LBAs/Sectors
(Sometimes Files)
SAN/DAS RAID
NAS – Filesystem on top of RAID
RAID-10, RAID-50, RAID-60
– Stripe Over Mirror Sets
– Stripe Over RAID-5 XOR Parity Sets
– Stripe Over RAID-6 Reed-Soloman or Double-Parity Encoded
Sets
EVEN/ODD
Row Diagonal Parity
Minimum Density Codes (Liberation)
Reed-Solomon Codes
Sam Siewert 18
RAID5,6 XOR Parity Encoding
MDS Encoding, Can Achieve High Storage Efficiency
with N+1: N/(N+1) and N+2: N/(N+2)
Sam Siewert 19
0.0%
10.0%
20.0%
30.0%
40.0%
50.0%
60.0%
70.0%
80.0%
90.0%
100.0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Sto
rag
e E
ffic
ien
cy
Number of Data Devices for 1 XOR or 2 P,Q Encoded Devices
RAID6
RAID5
RAID-50
Sam Siewert 20
A1
RAID-5 Set RAID-5 Set
B1 C1 D1 P(ABCD)
E1 F1 G1 H1 P(EFGH)
I1 J1 P(IJKL) K1 L1
M1 P(MNOP) N1 P1 O1
P(QRST) Q1 R1 S1 T1
A2 B2 C2 D2 P(ABCD)
E2 F2 G2 H2 P(EFGH)
I2 J2 P(IJKL) K2 L2
M2 P(MNOP) N2 P2 O2
P(QRST) Q2 R2 S2 T2
RAID-0 Striping Over RAID-5 Sets
A1,B1,C1,D1,A2,B2,C2,D2,E1,F1,G1,H1,…,
Q2,R2,S2,T2
RAID is an Erasure Code
RAID-1 is an MDS EC (James Plank, U. of Tennessee)
Sam Siewert 21
Read, Modify Write Penalty
Any Update that is Less than the Full RAID5 or RAID6 Set, Requires 1. Read Old Data and Parity – 2 Reads
2. Compute New Parity (From Old & New Data)
3. Write New Parity and New Data – 2 Writes
Only Way to Remove Penalty is a Write-Back Cache to Coalesce Updates and Perform Full-Set Writes Always
Sam Siewert 22
A1
RAID-5 Set
B1 C1 D1 P(ABCD)
E1 F1 G1 H1 P(EFGH)
I1 J1 P(IJKL) K1 L1
M1 P(MNOP) N1 P1 O1
P(QRST) Q1 R1 S1 T1
Write A1 P(ABCD)new=A1new xor A1
xor P(ABCD)
A1 B1 C1 D1 P(ABCD)
0 0 0 0 0
0 0 0 1 1
0 0 1 0 1
0 0 1 1 0
0 1 0 0 1
0 1 0 1 0
0 1 1 0 0
…
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-23
What Is a Model?
• A conceptual representation of something.
• A schematic description of a system, theory, or
phenomenon that accounts for its known or
inferred properties and may be used for further
study of its characteristics. (Dictionary
Definition)
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-24
An ancient Chinese story.
How four blind men perceive
an elephant.
Why Do We Need Model?
We perceive the world differently due to differences
in backgrounds and viewpoints. Modeling facilitate
collective understand of the application.
Elephant
is like a
wall.
No,
elephant is
like a rope.
No, I think
elephant is a
cylinder.
No, you are all
wrong. Elephant
is like a fan.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-25
Represent Domain Model as UML Class Diagram
• UML class diagram is a structural diagram.
• It shows the classes, their attributes and
operations, and relationships between the
classes.
• Domain model is represented by a class
diagram without showing the operations.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-26
SSN: char*
checkin(time:float):void
name: char*
checkout(time:float):void
Employee
Representing Type in UML
general syntax name : type
attribute name
function name parameter name parameter type
return type
attribute type
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-27
Features (i.e., attributes and operations) defined
for the super-class are automatically defined for the subclasses.
Example: Inheritance
A staff is a user, a student is a user.
User id: char*
login(id, password) name: char*
logout()
Staff Student
applyOnline() processApplication()
superclass, it is
more general
subclass,
more specific
triangle pointing to
the super-class.
subclass
may have
dditional
features
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-28
Two Tests for Inheritance
Engine
model#
horse
power
manufactur
er
start() stop()
Car
drive()
• IS-A test: every instance
of a subclass is also an
instance of the superclass.
• Conformance test:
relationships of a
superclass are also
relationships of subclasses.
Professor
name
phone
teach(...)
Visiting
Professor
signContract
()
Retirement
Plan
enroll
Visiting professors
cannot enroll in a
retirement plan at
the host
university.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-29
Aggregation Relationship
• It expresses the fact
that one object is part
of another object.
• Example: engine is
part of a car.
• It is also called part-of
relationship.
Car
model#
horse
power
manufactur
er
start() stop()
Engine
model#
horse
power
manufactur
er
start() stop()
part-of relationshi
p
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-30
Association Relationship
• It expresses a general relationship other than
inheritance and aggregation.
• These can be application specific relationships
between two concepts.
• Example: "instructor teach course," "user has
account."
Professor
name
phone
teach(...)
Retirement
Plan
enroll
Enroll is not an inheritance or aggregation relationship.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-31
Student Course enroll 8
student course
5 teach
course
instructor
Faculty
Faculty teaches Course
Student enrolls in Course
Role and Association Direction
association
name
association
direction
role name
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-32
Role and Multiplicity
Employee
supervise
supervisor
worker
*
Employee supervises other
employees.
Another employee is the
worker.
An employee is the
supervisor.
A supervisor supervises
zero or more employees.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
5-33
User
Staff User
+ Name
+ Address
+ Phone No
+ e - mail ID
+ User Name
+ Password
+ Privilege
Search
+ Program Type
+ Acedamic Subject
+ Region
+ Country
+ Language
Program
+ Program Type
+ Academic Subject
+ Term of Study
+ Language of Instruction
+ Country
+ Region
+ Application Deadline
+ Fees
+ Scholarships & Financial aid
Administrator
Manages 1 ..*
0 ..*
Performs 1 ..*
0 ..* Online Application
+ Program Name
+ Student Name
+ Student ID
+ Address
+ Course
Submits 1
1 ..*
- Application
- Student
Feedback
+ Description
Submits
- Student
- Feedback
1 ..*
1
* For 0 ..*
1
Manages
1
1 ..*
For 0 ..*
1
On
0 ..*
0 ..*
Sample Domain Model
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-34
Key Takeaway Points
• The software architecture of a system or
subsystem refers to the style of design of the
structure of the system including the
interfacing and interaction among its
subsystems and components.
• Different types of systems require different
design methods and architectural styles.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-35
Acquiring Requirements
Software architecture
Architectural Design in Methodology Context
Deriving Use Cases from Requirements
Allocating Use Cases & Subsystems to Iterations
Business goals & needs
Current situation
Preliminary requirements
Abstract & high level use cases, use case diagrams
Use case-iteration allocation matrix
(a) Planning Phase
control flow data flow control flow & data flow
(b) Iterative Phase – activities during each iteration
Actor-System Interaction Modeling
Domain Modeling
Accommodating Requirements Change
Behavior Modeling & Responsibility Assignment
Deriving Design Class Diagram
Test Driven Development, Integration, & Deployment
Customer feedback
Iteration use cases
Domain model
Expanded use cases & UI design
Behavior models
Design class diagram
Domain model
Use case-iteration allocation matrix
Producing an Architectural Design
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-36
What Is Software Architectural Design
• The software architecture of a system or
subsystem refers to the style of design of the
structure of the system including the
interfacing and interaction among its major
components.
• Software architectural design is a decision-
making process to determine the software
architecture for the system under development.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-37
Characteristics of Interactive Systems
• The interaction between system and actor consists of a relatively fixed sequence of actor requests and system responses.
• The system has to process and respond to each request.
• Often, the system interacts with only one actor during the process of a use case.
• The actor is often a human being although it can also be a device or another subsystem.
• The interaction begins and ends with the actor.
• The actor and the system exhibit a “client-server” relationship.
• System state reflects the progress of the business process represented by the use case.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-38
Characteristics of Event-Driven Systems
• It receives events from, and controls external entities.
• It does not have a fixed sequence of incoming requests; requests arrive at the system randomly.
• It does not need to respond to every incoming event. Its response is state dependent—the same event may result in different responses depending on system state.
• It interacts with more than one external entity at the same time.
• External entities are often hardware devices or software components rather than human beings.
• Its state may not reflect the progress of a computation.
• It may need to meet timing constraints, temporal constraints, and timed temporal constraints.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-39
Characteristics of Transformational Systems
• Transformational systems consist of a network of information-processing activities, transforming activity input to activity output.
• Activities may involve control flows that exhibit sequencing, conditional branching, parallel threads, synchronous and asynchronous behavior.
• During the transformation of the input into the output, there is little or no interaction between system and actor—it is a batch process.
• Transformational systems are usually stateless.
• Transformational systems may perform number crunching or computation intensive algorithms.
• The actors can be human beings, devices, or other systems.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-40
Characteristics of Object-Persistence Systems
• It provides object storage and retrieval
capabilities to other subsystems.
• It hides the implementation from the rest of the
system.
• It is responsible only for storing and retrieving
objects, and does little or no business
processing except performance considerations.
• It is capable of efficient storage, retrieval, and
updating of a huge amount of structured and
complex data.