SE300 Software Engineering Practicesmercury.pr.erau.edu/~siewerts/se300/documents/Lectures/... ·...

February 5, 2015 Sam Siewert

SE300

Software Engineering Practices

Lecture 5, Part 2 – Revisiting Use

Cases and Transition from Architecture

to Design

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

http://www.mathworks.com/help/vision/examples/automatically-detect-and-recognize-text-in-natural-images.html

Domain Models – Use Case Details Further Domain Model with Use Case Details

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

https://www.modelio.org/http://argouml.tigris.org/

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 8


7-9

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


7-10

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


7-11

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


7-12

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 13

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

Agile with Use Cases

Create Backlog – Attack Highest

Priority Use Cases First

Schedule Scrums Around Use

Cases

Synchronize with SQA on Use

Case Acceptance Testing

Simple – Easy to Share with

Customer

Sam Siewert 14

Work with Customer – Use Case

Inspection or Walk-through

Team – Walk-throughs and

Division of Labor, Planning and

Backlog

Refinement of Requirements

Frequent Delivery of Small

Increments (Use Case Design,

Construction, Coding)

What the System Includes and

Does not (Boundary)

Minute Paper #3 – Architecture and

Application of YOUR Interest

Think about Architecture Patterns and Applications

Discussed so Far …

Choose an Application that Emphasizes one of the

Architecture Patterns and Describe Why it Interests

You?

Turn in Your Minute Paper

Sam Siewert 15

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

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

Software Engineering Design

Data/Class design – transforms analysis

classes into implementation classes and data

structures

Architectural design – defines relationships

among the major software structural elements

Interface design – defines how software

elements, hardware elements, and end-users

communicate

Component-level design – transforms

structural elements into procedural descriptions

of software components



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 sig n

In t e rf a c e D e sig n

Co m po n e n t -

L e v e l D e sig n

Design Model



Design and Quality

the design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.

the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.

the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.



Quality Guidelines A design should exhibit an architecture that (1) has been created using

recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion

A design should be modular; that is, the software should be logically partitioned into elements or subsystems

A design should contain distinct representations of data, architecture, interfaces, and components.

A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.

A design should lead to components that exhibit independent functional characteristics.

A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.

A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

A design should be represented using a notation that effectively communicates its meaning.



Design Principles

The design process should not suffer from ‘tunnel vision.’

The design should be traceable to the analysis model.

The design should not reinvent the wheel.

The design should “minimize the intellectual distance” [DAV95] between the software and the problem as it exists in the real world.

The design should exhibit uniformity and integration.

The design should be structured to accommodate change.

The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.

Design is not coding, coding is not design.

The design should be assessed for quality as it is being created, not after the fact.

The design should be reviewed to minimize conceptual (semantic) errors.

From Davis [DAV95]



Fundamental Concepts Abstraction—data, procedure, control

Architecture—the overall structure of the software

Patterns—”conveys the essence” of a proven design solution

Separation of concerns—any complex problem can be more easily handled if it is subdivided into pieces

Modularity—compartmentalization of data and function

Hiding—controlled interfaces

Functional independence—single-minded function and low coupling

Refinement—elaboration of detail for all abstractions

Aspects—a mechanism for understanding how global requirements affect design

Refactoring—a reorganization technique that simplifies the design

OO design concepts—Appendix II

Design Classes—provide design detail that will enable analysis classes to be implemented



Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]

Structural properties. This aspect of the architectural design

representation defines the components of a system (e.g., modules,

objects, filters) and the manner in which those components are

packaged and interact with one another. For example, objects are

packaged to encapsulate both data and the processing that manipulates

the data and interact via the invocation of methods

Extra-functional properties. The architectural design description

should address how the design architecture achieves requirements for

performance, capacity, reliability, security, adaptability, and other system

characteristics.

Families of related systems. The architectural design should draw

upon repeatable patterns that are commonly encountered in the design

of families of similar systems. In essence, the design should have the

ability to reuse architectural building blocks.



Patterns Design Pattern Template

Pattern name—describes the essence of the pattern in a short but

expressive name

Intent—describes the pattern and what it does

Also-known-as—lists any synonyms for the pattern

Motivation—provides an example of the problem

Applicability—notes specific design situations in which the pattern is

applicable

Structure—describes the classes that are required to implement the

pattern

Participants—describes the responsibilities of the classes that are

required to implement the pattern

Collaborations—describes how the participants collaborate to carry out

their responsibilities

Consequences—describes the “design forces” that affect the pattern and

the potential trade-offs that must be considered when the pattern is

implemented

Related patterns—cross-references related design patterns

Practical Concern – Management of

the Revisions of Artifacts

Artifacts Include:

– Requirements Text and Analysis

– Architecture Diagrams and Documents

– Design Diagrams and Documents

– Prototype Code and Proof-of-Concept Code

We Need a Project Archive for All Artifacts

Detailed Configuration Management and Version Control

for all Code

Sam Siewert 24

Integration and Test Integrate Software Modules [units] and Hardware Components into Sub-systems – CMVC is Critical at all Phases, but Can’t Live without it During I&T!!

Test Focus on Interfaces [Function, Message, Shared Memory, Hardware], Protocols, and Interoperability of Modules

Sam Siewert 25

GitHub and GitHub Desktop Primer Use CMVC from Now On

– Install GitHub Desktop on Windows or Mac

– Create GitHub Account - https://github.com/

– Code is Public for FREE Use

– Clone from siewertserau or PRClab or Desktop

git clone https://github.com/siewertserau/Examples-RAID-Unit-Test.git

You need my permission to push changes back, but anyone can pull

Sam Siewert 26

https://windows.github.com/https://mac.github.com/https://github.com/https://github.com/https://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.git

University Machines PRClab has Git client for Cloning and CMVC on EE Servers

See Cloning Path on GitHub Desktop / Web – View on GitHub

– Use SSH or HTTPS to Clone [SSH is Preferred]

Sam Siewert 27

Grab clone path here

Clone to Desktop here

Get Archive here

Git RAID Example - Browse

To See What I Changed, Browse

First, 4 New “+” Lines for Includes for Simple file I/O

Next, 2 New Lines to Declare Simple file Descriptors

Sam Siewert 28

SE300 Software Engineering Practicesmercury.pr.erau.edu/~siewerts/se300/documents/Lectures/... ·...

Documents

Transcript of SE300 Software Engineering Practicesmercury.pr.erau.edu/~siewerts/se300/documents/Lectures/... ·...