se310 analysis and design of software...

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




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

https://www.modelio.org/

http://argouml.tigris.org/

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

http://www.holub.com/goodies/uml/

http://www.uml-diagrams.org/


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.


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


Producing an Architecture Design


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

https://www.dropbox.com/



http://aws.amazon.com/s3/

https://cloud.google.com/storage/

https://cloud.google.com/storage/

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


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.


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

…


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)


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.


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.


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


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


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.


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


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.


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


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.


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


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.


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


(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


Producing an Architectural Design


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.


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.


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.


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.


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.