SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2020. 1. 21. · Structured Programming - Ada Object-Oriented Programming

January 20, 2020 © Sam Siewert

SE310

Analysis and Design of Software

Systems

Lecture 3 – Systems Requirements

Review Criteria – 7 Key Aspects

Use to assess reviews for all phases

1. Complete – Nothing missing

2. Consistent – No conflicts between requirements,

models

3. Correct – Logically and formally meets goals, objectives

4. Constraints – Timing, resources, schedule, budget

5. Unambiguous – Clear, no potential misunderstanding

6. Quality – “ilities”, such as readability, maintainability,

etc.

7. Efficient – Not more complex than needed

© Sam Siewert 2

Learning Objective

Software Engineering Process? – Lifecycle Phases

Agile – Manifesto that Hosts Spiral, XP, Scrum, Feature-

Driven or any Iterative Process [Waterfall with Feedback]

Requirements? Architecture? – First Phase is Research,

Analysis and Specification© Sam Siewert 3

SPIRAL in Agile XP – Extreme

In Agile

WATERFALL

feedback

http://agilemanifesto.org/

Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.

2-4

Rational Unified Process (RUP)[Software Modeling and Design, Gomaa]

• Inception consists of the first 1-2 iterations. It

produces a simplified use case model, a tentative

architecture, and a project plan.

• Elaboration consists of the next N iterations. It

produces the architectural design and implements the

most critical use cases.

• Construction, during which remaining use cases are

iteratively implemented and integrated into the

system.

• Transition, during which the system is deployed,

users are trained, and defects are corrected.


2-5

Kung - Rational Unified Process (RUP)


2-6

Agile Process Models - Kung

phases in a

n ite

ration

Iterations

ranger.uta.edu/~kung/

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

Covered in SE300

State Machines [in Common, but Typically for Each Process in DFD]

Flow-Charts – Detailed Procedural Design [Interaction, Logic]

© Sam Siewert 7

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/Finite-state_machinehttp://en.wikipedia.org/wiki/Data_flow_diagramhttp://en.wikipedia.org/wiki/Entity%E2%80%93relationship_modelhttp://en.wikipedia.org/wiki/Flowchart

Domain Models – Use Case Details

© Sam Siewert 8

Start Here! https://www.modelio.org/

OMG UML 2.5 Standard

Structural Diagrams

• Start with Class Diagram and CRC

• Then Object Diagram

• Package and Deployment

Behavioral Diagrams

• Start with Use Case Diagram

• Interaction Sequence Diagram after

Class and Object Done

• Add State Machine and Activity

Diagrams for concurrency and

statefulness

Helpful Validation and Verification Features for

Design

• Integrated Models

• Checklists – Completeness

• CPP and Java Code Generation

USE Modelio 3.7 SD as your DESIGN TOOL

UML is Universal Modeling Language [OMG, UML.org]

Use to Support Requirements Analysis

https://www.modelio.org/http://www.omg.org/http://www.uml.org/

Architecture and Design Patterns

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 - Architecture Patterns

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 9

Three Historical Software MethodologiesProgramming Paradigm (Development Strategy)

Procedural, Modules - [Modula-1,2,3, Pascal], Ada83

Data (Relational) - Databases and SQL

OO - [Smalltalk], C++, Python 3.x, Java, C#, Ada95, Ruby– OO Detailed Design Patterns - Gang of Four

– Creational patterns (5): Factory method pattern, Abstract factory pattern, Singleton pattern, Builder pattern, Prototype pattern

– Structural patterns (7): Adapter pattern, Bridge pattern, Composite pattern, Decorator pattern, Facade pattern, Flyweight pattern, Proxy pattern

– Behavioral patterns (11): Chain-of-responsibility pattern, Command pattern, Interpreter pattern, Iterator pattern, Mediator pattern, Memento pattern, Observer pattern, State pattern, Strategy pattern, Template method pattern, Visitor pattern

© Sam Siewert 10

https://en.wikipedia.org/wiki/Creational_patternhttps://en.wikipedia.org/wiki/Factory_method_patternhttps://en.wikipedia.org/wiki/Abstract_factory_patternhttps://en.wikipedia.org/wiki/Singleton_patternhttps://en.wikipedia.org/wiki/Builder_patternhttps://en.wikipedia.org/wiki/Prototype_patternhttps://en.wikipedia.org/wiki/Structural_patternhttps://en.wikipedia.org/wiki/Adapter_patternhttps://en.wikipedia.org/wiki/Bridge_patternhttps://en.wikipedia.org/wiki/Composite_patternhttps://en.wikipedia.org/wiki/Decorator_patternhttps://en.wikipedia.org/wiki/Facade_patternhttps://en.wikipedia.org/wiki/Flyweight_patternhttps://en.wikipedia.org/wiki/Proxy_patternhttps://en.wikipedia.org/wiki/Behavioral_patternhttps://en.wikipedia.org/wiki/Chain-of-responsibility_patternhttps://en.wikipedia.org/wiki/Command_patternhttps://en.wikipedia.org/wiki/Interpreter_patternhttps://en.wikipedia.org/wiki/Iterator_patternhttps://en.wikipedia.org/wiki/Mediator_patternhttps://en.wikipedia.org/wiki/Memento_patternhttps://en.wikipedia.org/wiki/Observer_patternhttps://en.wikipedia.org/wiki/State_patternhttps://en.wikipedia.org/wiki/Strategy_patternhttps://en.wikipedia.org/wiki/Template_method_patternhttps://en.wikipedia.org/wiki/Visitor_pattern


2-11

Three Paradigms in History - Kung

• Procedural paradigm views the world and system as:

– a network of processes

– a process is refined by lower level processes

– basic building blocks and starting point are processes

• OO paradigm views the world and system as:

– interrelated and interacting objects

– basic building blocks are objects

• Data-oriented paradigm views the world and system as:

– interrelated data entities, processed by transactions

– basic building blocks are data entities and relationships

http://ranger.uta.edu/~kung/


2-12

Structured Design - Modules

Object-Oriented AnalysisStructured Analysis - DFD

Object-Oriented Design

Data-Oriented Analysis

Procedural Paradigm OO Paradigm

Structured Programming - Ada Object-Oriented Programming - C++

Data-Oriented Paradigm

Data-Oriented Design

Programming in SQL

Paradigm and Methodology - Kung

Process

Orders

Books

Customers

orders

invoices

(w/books) credit status

Customer

Top Manager

BE

B E

A

CF

Top Decider

DG

GC F D

H

Class - 1attrib 1attrib 2

Class - 2attrib 1attrib 2

Class - 3attrib x

Domain model

Student

Student

enroll

sn

sname

cn

cname

Obj: class b : Bclass

m1 ( ) m2 ( ) m3 ( )

m4 ( )m5 ( )info

m6 ( ) m7 ( ) m8 ( )

m9 ( )m10 ( )

Sequence diagram


Tool-Based Activities

Bring Up Modelio and Start Entering ATM Design – Use

Case and Class Diagram, Compare to UML Reference

Versions of UML – 2.5 Current

Minute Paper #2 – Do Design Tools Really Assist with

Software Quality Assurance?

© Sam Siewert 13

http://www.holub.com/goodies/uml/http://www.uml-diagrams.org/


2-14

Methodology Overview – Planning Phase - Kung

Deriving Use Cases

from Requirements

Allocating Use Cases &

to Iterations

Acquiring Requirements &

Domain Modeling

Business goals & needs

Current situation

Requirements

Abstract & high level use cases,

use case diagrams

Use case-iteration allocation matrix

Producing an

Architecture Design

Software architecture



2-15

Accommodating

Requirements Change

Methodology Overview – Iterative Phase - Kung

Deriving Design Class Diagram

Actor-System Interaction

Modeling & UI Design

Domain Modeling

Behavioral Design

Integration, & Deployment

Iteration use cases

Domain model

Expanded use cases & UI design

Behavior diagrams

Design class diagram

Domain model

Use case-iteration allocation matrix Software architecture


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 16

https://www.dropbox.com/http://aws.amazon.com/s3/https://cloud.google.com/storage/

The Requirements – Capabilities Focus1. 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 17

Assignment #2 Goals – Next Week

Consistent and Complete UML Design 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

Better Understanding of UML 2.x – Use Case,

Component, Class, Interaction Diagrams [2 From

Behavior Side, 2 From Structure Side of UML]

© Sam Siewert 18

Systems and Software Engineering

Systems Engineering Defines Requirements and

Constraints

Allocation of Functionality to Hardware, Firmware,

Software and Operators (Humans)

Software Engineering is a Necessary Component of

Systems Engineering (Unless zero software - rare)

Apps - May be Mostly Software (Platform)

Systems - Blend of Software, Hardware, Operations

© Sam Siewert 19

System Design Methods

Block Diagrams - Somewhat Standardized

UML Component Diagram - Like Block Diagram

SysML - Extension of UML for Systems

Structured Analysis/Design - DFD/CFD, Flowchart, State

Machine

HDLs - Hardware Design Languages for Digital Design

Schematics, CAD - EE & ME

© Sam Siewert 20


3-21

System Architectural Design - Kung

• Decomposing the system into a hierarchy

of functional cohesive, loosely coupled

subsystems, which partition the system

requirements and facilitate reuse of

COTS components.

• System requirements are assigned to the

subsystems.

Decomposing

the System

Allocating System

Requirements

Visualizing System

Architecture• The system architecture is depicted using

a certain diagramming technique.



3-22

System Requirements Allocation - Kung



3-23

UML Component Diagram - Kung

air link

instructionsHigh-Power

Transceivers

Controller

Hardware

Base Station

Mobile Units

Base Station

AntennaAccount

ManagementController

Software

Mobile

Hardware

Mobile

Software

events

events

instructions

call

data

portLegend: component stereotype for introducing new modeling constructs


RAID 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 24

RAID-10

© Sam Siewert 25

A1 A1A2 A2 A3 A3

A4 A4A5 A5 A6 A6

RAID-1 Mirror RAID-1 Mirror RAID-1 Mirror

RAID-0 Striping Over RAID-1 Mirrors

A7 A7A8 A8 A9 A9

A10 A10A11 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 26

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 27

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 28

A1

RAID-5 Set RAID-5 Set

B1 C1 D1 P(ABCD)

E1 F1 G1 H1P(EFGH)

I1 J1 P(IJKL) K1 L1

M1 P(MNOP) N1 P1O1

P(QRST) Q1 R1 S1 T1

A2 B2 C2 D2 P(ABCD)

E2 F2 G2 H2P(EFGH)

I2 J2 P(IJKL) K2 L2

M2 P(MNOP) N2 P2O2

P(QRST) Q2 R2 S2 T2

RAID-0 Striping Over RAID-5 Sets

Write A1,B1,C1,D1,A2,B2,C2,D2,E1,F1,G1,H1,…,

Q2,R2,S2,T2

Read, Modify Write PenaltyAny Update that is Less than the Full RAID5 or RAID6 Set, Requires1. 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 30

A1

RAID-5 Set

B1 C1 D1 P(ABCD)

E1 F1 G1 H1P(EFGH)

I1 J1 P(IJKL) K1 L1

M1 P(MNOP) N1 P1O1

P(QRST) Q1 R1 S1 T1

Write A1,B1,C1,D1, E1,F1,G1,H1,…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

…

1 1 1 1 0

XOR parity

Indicates

Odd number

Of “1’s”