February 15, 2015 Sam Siewert

SE300

Software Engineering Practices

Lecture - REVIEW 1

Pressman 1-10, 12 & 13

Assignment #1, #2

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

6-2

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

Architecture Patterns

No Pattern is Perfect Fit and Real Applications May Have Aspects (and Requirements) from Multiple Patterns

Hybrid Architectures Combine Capabilities

Classify First Based on Primary Use and Capabilities and Refine Through Agile XP, Scrum or Spiral Process

1. Transformational – E.g. Image Processing

2. Interactive – E.g. User Interface

3. Service Oriented Architectures – Transactional – E.g. Database Services

– Client/Server – E.g. Web Browser, Disk Drives (Storage), File Systems

4. Event Driven – E.g. Robotics, E-mail, Digital Control – Hard Real-Time Event Driven – E.g. Anti-lock Braking System (Digital

Control with Specific Deadlines for Response to Events)

– Soft Real-Time Event Driven – E.g. Digital Video for Cable or Netflix

– Best Effort Event Driven – E-mail Reminder System

Sam Siewert 3

Canny Edge Finder – Threshold Control Consider a Transformation – Continuous Image

Processing with a Simple Control Added

Sam Siewert 4

Activity – Canny Interactive Demo

Slider – What is Going on? – Think, Pair, Share

1. Is this Transformational?

2. Is this Interactive?

3. Is this Something Else?

4. What are Key Capabilities and Requirements?

5. What Sorts of Applications Could We Use Canny For?

Sam Siewert 5

License Plate or Sign OCR MATLAB Example – Reading a Sign

Canny is Fundamental Step – Transformational Capability in a

Larger Application (OCR)

Correct Threshold for Intensity Gradient to Segment Image

Sam Siewert 6

Interactive Example(s) OpenCV PoC – Interactive Edge Finder, OCR

C/C++ Allegro Games - http://alleg.sourceforge.net/

Also Transformational (Ok to be Hybrid)

Display + Slider = Interactive

Sam Siewert 7

Interactive Control(s)

Visual Feedback (Interactive)

Event Driven Example(s) C Prototype – Bright Target Tracker, Robotic Steering,

PID Controller(s)

Also Transformational (Ok to be Hybrid)

Sam Siewert 8

Periodic + Event Driven Control

Track, Find, Acquire Targets – E.g. Industrial Automation, Process Control

Transformational Example(s) Very Common Engineering Architecture

OpenCV PoC – Hough Linear or Circular Transform

C code PoC – Image Enhancement, Sharpen, Brighten/Contrast, Encrypt/Decrypt, Compress/Decompress

Batch or Continuous Real-Time

Sam Siewert 9

Digital Media Security & Transport

Computer Vision

Transaction Example(s) – DBMS,

Client/Server PRClab MySQL Installation – MySQL Workbench

C Code - TCP/IP – Command/Response, RAID Archive

Sam Siewert 10

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e

(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 11

Analysis Model -> Design Model

Analysis Model

use-cases - text

use-case diagrams activity diagrams

swim lane diagrams

data flow diagrams

control-flow diagrams processing narratives

f l ow- or i e nt e d

e l e me nt s

be ha v i or a le l e me nt s

c l a ss- ba se d

e l e me nt s

sc e na r i o- ba se d

e l e me nt s

class diagrams analysis packages

CRC models collaboration diagrams

state diagrams

sequence diagramsD a t a / Cla ss D e sign

A rc h it e c t u ra l D e sign

In t e rf a c e D e sig n

Com po ne n t -

Le v e l D e sign

Design Model

Domain Models – Use Case Details Complete a Design (Details)

Provide Code Re-Use Candidates and PoC

Sam Siewert 12

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

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 13

SPIRAL

XP - Extreme

WATERFALL

feedback

SWE Pattern – Anti-Pattern Pattern Anti-Pattern

Process Spiral Model (Risk, Effort,

Resource Control)

Mythical Man Month

Planning, Metrics, Re-

planning

Death March

Agile with XP (Extreme

Programming)

Silos

Concurrent Engineering

(HW/SW, Test/Dev)

Missed Market

Opportunity

Specification Formal, Validated Incomplete, Informal

Architecture Pattern Transformation (SIMD,

MIMD, Map-Reduce)

Sequential Processing

Design Patterns UML (Use, Behavior,

Information, States,

Interfaces) or SA/SD

Ad-hoc, pseudo-code,

Long natural language

paragraphs

Code Feature Engineering Lava Code

Structured Programming Goto, Arithmetic if

Test Regression Test Suite,

Unit Tests

Regression

Sam Siewert 14

Software Crisis – Anti-Patterns

The Anti-Patterns for Process and Architecture Were

Noted in first 20 years of Computing (Between 1948 and

1968)

NATO Conference in 1968 – “Software Crisis”

The Idea of Engineering Software Was First Proposed at

this Conference

Similar Session on Embedded Software Systems - 2006,

Austin Texas, http://varma.ece.cmu.edu/cps/, focus on

position papers (similar to 1968 NATO Software Crisis

Conference)

Sam Siewert 15

Infamous System Software Defects

Infamous & Famous Field Defects

1. Toyota ABS Software Recall, 2010

2. Windows Genuine Advantage Outage, 2006

3. Mars Climate Orbiter Units Interoperability, Loss, 1999

4. Mars Pathfinder Priority Inversion, Recovered, 1997

5. Ariane-5 501 Cluster Launch Software Failure, 1996

6. Pentium FPU Bug – Software Acceleration Co-Processor Recall, 1994

7. ATT 4ESS Upgrade, Outage, 1990

8. Therac-25 Radiation Therapy Patient Overdosing, 1985-86

9. NORAD False Alarms, User Error for Test Mode, Device Failures, 1979/1980

10. Apollo 11 Guidance Computer Overload, 1969 - Recovered

Sam Siewert 16

http://en.wikipedia.org/wiki/Software_bug

RCA, Patch, Test, Fix!

http://history.nasa.gov/SP-350/ch-11-4.html

Rear Admiral Grace Hopper

SEI Capability and Maturity Model Test Coverage Criteria, Bug Open/Close Rate Metrics, Pass/Fail Statistics Provide Quantitative Management [Level 4]

Automation is a Step Toward Optimization – Necessary, but Not Sufficient (Metrics for Feedback Process Improvement)

Sam Siewert 17

Ad Hoc, “Code & Fix” – Driven by

Individual Styles, Un-coordinated,

More of an Art than Practice

Clear Phases with Key

Deliverables – Analysis,

Design, Units, Test Plans

E.g. Boehm’s “V” and

Spiral Model, Applied to

All Projects - Repeatable

Entry/Exit Criteria for

Phases, Metrics Drive

Decisions in Process [Gates]

Feedback Used to

Improve Process with

Automation and Innovation

SEI CMM Levels

http://www.tutorialspoint.com/cmmi/cmmi-maturity-levels.htm

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 18

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

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

5-19

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

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

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

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

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

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

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

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

UML – Use Cases Class Structure (Data and Operations on that Data)

Use Cases and Corresponding Interaction Diagrams

– Actors in Use Case

– Behavior Shown by Interaction Diagrams

Sam Siewert 27

UML Class Diagram Much Like ER / EER if you Have Had CS 317

Shows Class Relationships and Hierarchy

Sam Siewert 28

Transaction Abstract Class

Defines Specific (Refined)

Transaction Types

One ATM Instance Supports

Many Transactions (Abstract)

One ATM Instance Supports

Many Sessions Over Time

[Each Requires Card Read]

Arrows – Dashed Uses/Dependencies

and Solid Relationships with

Cardinality

UML Interaction Diagrams

Behavior – Object Interactions over Time

Sam Siewert 29

Dashed Lines:

Messages

Solid Lines:

Operations that

Start Execution

Sequences

Wide Vertical Lines:

Active Process

Started by Operation

With Messaging

X:

End of Interaction

(E.g. Specific Session)

Detailed Design

Class Public and Private Data

Class Operations on Data

Constructors and Destructors for Instantiation of Object

Sam Siewert 30

Operations and State – State Charts Operational Input Changes State of Objects [Output]

At Any Time, Object is in One Well-known State

Sam Siewert 31

Input / Output

On Transitions

Start State

State:

Object Instance

Needs Specific Data,

Waits on Next Input

Termination State:

End of Instance

CRC – Class Responsibility

Collaborator Create a Set of Index

Cards with Proposed

Classes, Responsbilities

for the Class and

Collaborators (has an

Association

Useful Step Prior to

Class Diagram and

Class Definitions

Not Officially Part of

UML, but Useful

Supporting Method

Sam Siewert 32

http://www.uml.org.cn/umlapplication/pdf/crcmodeling.pdf

Supplements to Chapter 9 in Pressman

Use Cases are Critical

What’s in the System, What’s Not

Who are the Actors – Scenarios Start and End with an

Actor

Precursor to Activity Diagrams (We’ll Defer Discussion

for Later Date)

Behavioral Side (Compared to Classes and Class

Diagrams)

Sam Siewert 33

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

7-34

Simplify with Use of Inheritance

Login

Logout

SAMS/Search Program

SAMS

End User

SAMS

Admin

SAMS

Staff

This is OK. Login

Logout

SAMS/Search Program

SAMS

End User SAMS

Admin SAMS

Staff Better

Study-Abroad Management

System

P. 179, Example 7.4

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

7-35

Use Case Diagram

Log In

Log Out

Start Up

SAMS

SAMS

End User

SAMS

Staff User SAMS

Admin

Add Program

Delete Program

Edit Program

Create User

Delete User

Update User

Search for Programs

Display Program

Detail

Apply Online

Shutdown

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

7-36

Create User

Delete User

Update User

SAMS/User Mgmt

SAMS

Admin

Add Program

Delete Program

Edit Program

SAMS/Program Mgmt

SAMS

Staff

Search for Programs

Display Program

Detail

Apply Online

SAMS/End User

SAMS

End User

Start Up

Shutdown

Login

Logout

SAMS/Authentication

SAMS

End User SAMS

Admin SAMS

Staff

Software engineering

principle applied:

• separation of

concerns

• divide and conquer

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

7-37

What Should Be In and Out?

Add Program

Delete Program

Edit Program

SAMS/Program Mgmt

SAMS

Staff

Login

Login

Add Program

Delete Program

Edit Program

SAMS/Program Mgmt

SAMS

Staff

Login

Login

Add Program

Delete Program

Edit Program

SAMS/Program Mgmt

SAMS

Staff

Login

Login

DB

Add Program

Delete Program

Edit Program

SAMS/Program Mgmt

SAMS

Staff

Login

Login

Hacker

Only use cases and

their relationships

are allowed in the

boundary.

Tying Use Case Back to Requirements

Create Traceability – Rn is Described by Use-Casen

Prioritize Requirements (Shall, Must, Should, …)

Sam Siewert 38

Help Distinguish Requirement

Priority Based on Use and Use

Case Based on Requirements

Weight

Drive Next Steps and Focus for

Walk-throughs and Inspections

based on Highest Column Scores

or Perhaps Adjust Weightings

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e

(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 39

Modularity: Trade-offs What is the "right" number of modules

for a specific software design?

optimal number

of modules

cost of

software

number of modules

module integration

cost

module development cost

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e

(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 40

Information Hiding module

controlled

interface

"secret"

• algorithm

• data structure

• details of external interface

• resource allocation policy

clients

a specific design decision