se310 analysis and design of software...

30
January 21, 2015 Sam Siewert SE310 Analysis and Design of Software Systems Lecture 3 Systems Requirements

Upload: others

Post on 23-Mar-2020

2 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

January 21, 2015 Sam Siewert

SE310

Analysis and Design of Software

Systems

Lecture 3 – Systems Requirements

Page 2: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

Sam Siewert 2

SPIRAL

XP - Extreme

WATERFALL

feedback

Page 3: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

2-3

CH2 - Rational Unified Process (RUP)

• 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.

Page 4: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

2-4

CH2 - Rational Unified Process (RUP)

Page 5: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

2-5

Agile Process Models

phases in a

n ite

ration

Iterations

Page 6: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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 6

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

Page 7: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

Domain Models with UML - CASE UML is Universal Modeling Language

Use to Support Requirements Analysis

Sam Siewert 7

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

WARNING: ArgoUML has bugs, so use only

to review Argo design examples

USE Modelio as your DESIGN TOOL

Page 8: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

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 8

Page 9: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

2-9

Software Paradigm

• A software paradigm is a style of software

development that constitutes a way of viewing

the reality.

• Examples:

– procedural paradigm

– OO paradigm, and

– data-oriented paradigm

Page 10: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

2-10

Three Paradigms in History

• 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

Page 11: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

2-11

Structured Design

Object-Oriented Analysis Structured Analysis

Object-Oriented Design

Data-Oriented Analysis

Procedural Paradigm OO Paradigm

Structured

Programming Object-Oriented

Programming

Data-Oriented Paradigm

Data-Oriented Design

Programming

in

4GL (e.g.,

SQL)

Paradigm and Methodology

Process

Orders

Books

Customers

orders

invoices

(w/books) credit status

Customer

Top Manager

BE

B E

A

CF

Top Decider

DG

G C F D

H

Class - 1 attrib 1 attrib 2

Class - 2 attrib 1 attrib 2

Class - 3 attrib 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

Page 12: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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 12

Page 13: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

2-13

Methodology Overview – Planning Phase

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

Page 14: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

2-14

Accommodating

Requirements Change

Methodology Overview – Iterative Phase

Deriving Design Class Diagram

Actor-System Interaction Modeling

& UI Design

Domain Modeling

Behavioral Design

TDD, 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

Page 15: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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 15

Page 16: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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 16

Page 17: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

Assignment #2 Goals

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 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 17

Page 18: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

3-18

Key Takeaway Points

• System engineering is a multidisciplinary

approach to systems development.

• System engineering defines the system

requirements and constraints, allocates the

requirements to the hardware, software, and

human subsystems, and integrates these

subsystems to form the system.

• Software engineering is a part of system

engineering.

Page 19: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

3-19

System Architectural Design

• 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.

Page 20: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

3-20

Requirements Allocation

Page 21: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

3-21

Architectural Design Diagrams

• Block diagram

• UML component diagram

• SysML diagrams

• Data flow diagram

• and more ...

Page 22: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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 22

Page 23: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

RAID-10

Sam Siewert 23

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

Page 24: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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 24

Page 25: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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 25

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

Page 26: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

RAID-50

Sam Siewert 26

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

Page 27: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

RAID is an Erasure Code

RAID-1 is an MDS EC (James Plank, U. of Tennessee)

Sam Siewert 27

Page 28: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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 28

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

Page 29: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

3-29

UML Component Diagram

<<subsystem>>

air link

instructions High-Power

Transceivers

Controller

Hardware

<<subsystem>>

Base Station <<subsystem>>

Mobile Units

Base Station

Antenna Account

Management Controller

Software

Mobile

Hardware

Mobile

Software

events

events

instructions

call

data

<<subsystem>>

<<subsystem>>

<<subsystem>>

<<subsystem>>

<<subsystem>>

<<subsystem>>

port Legend: component <<subsystem>> stereotype for introducing new modeling constructs

Page 30: SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/Lectures/... · 2015-01-28 · January 21, 2015 Sam Siewert SE310 Analysis and Design of

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

3-30

Data Flow Diagram with Material Flows

Receiving

Dock

valid

shipmen

t slip Verify

Shipment

Content

Purchasin

g

1 shipmen

t slip Classify

Publication

s Received

Catalogin

g

2

Handle

Documents

Check-

In/Out

Circulatio

n

3 new

titles

available

Catalogin

g Room

Book

Shelves raw

shipment publications publications

w/call

numbers

Legend:

material flow

information

flow Functio

n Subsyste

m

ID External

Entity

Internal

Entity

Publishe

r