se300 software engineering practicesmercury.pr.erau.edu/~siewerts/se300/documents/... · strength...

February 10, 2015 Sam Siewert

SE300

Software Engineering Practices

Lecture 6, Putting Process, Analysis

and Design into Practice

Outline for Practice – Second Half

Assignment #3 – Last Individual Work Outside Class First Half Outcome – Essentials of SWE Process, Specification, Analysis and Architecture (High Level Design) Second Half Learning Objectives – Detailed Design, Validation and Verification, Working on Teams, Code Construction, Delivery and Design Communication Form Groups of 4 for Assignment #4, #5, #6 – 4 TOTAL GROUPS Agile Process Using Scrums and Sprints 1. Scrum Master – Focus on Planning and Backlog of Tasks 2. Architect – Focus on Requirements Specification, Use Cases and

Domain Model 3. SQA – Focus on Validation and Verification (Plans, Walk-throughs,

and Final Testing) 4. PoC/Prototype Construction – Focus on Early Coding, Mock-up, or

Evaluation of Code for Re-use

Sam Siewert 2

Scrum Process 3 Sprints – Assignment #4, #5, #6

Must Take on a Different Roles Each Sprint– Scrum Leader

for Sprint #3 Must Have Been Scrum Leader in Prior Sprint

Turn in Your Artifacts for Your Role

Turn in Team Analysis, Design, PoC/Prototype Work

Present Status to Class in 15 Minutes with Walkthrough,

Brainstorming to Get Help, Demonstration and Test Results,

Options and Decision

Sam Siewert 3

Role Sprint #1 (A4) Sprint #2 (A5) Sprint #3 (A6)

Scrum Leader Engineer-A Engineer-B A or B

Architect/Designer Engineer-B Engineer-A A or B

SQA Engineer-C Engineer-D C or D

PoC/Re-Use Engineer-D Engineer-C C or D

Final Exam

Second Mid-Term, No Final Exam

Instead, Final Team Presentation, Teams of 4

30 minutes per Group, 4 Teams

Design Walkthrough, Demonstration of Prototype(s), Assessment of Successes and Failures, Next Steps – 5 Minutes – Scrum Status, Scrum Leader

– 5 Minutes – Major Requirements, Past Scrum Leader

– 10 Minutes – Architecture Level Walkthrough (By SQA)

– 10 Minutes – Design and/or PoC Code Walkthrough (by PoC/Re-Use)

3 Status Checks – 15 Minute Stand-Up Scrum Status for Sprint #1, #2, #3 (Scrum Leader + Team)

Sam Siewert 4

Assignment #3

Practice – Learning to Work with “Git” for Code CMVC

– Code Construction

– Software Quality Assurance – Validation, Verification, Integration

and Test

Propose Application or Software System of Your Interest

– Requirements Draft Specification

– Analysis

– Architecture

Potential Definition of Project for Second Half - #4 - #6

– Requirements & Analysis - Validation and Verification

– Detailed Design to Target Construction

– PoC Construction, Testing and CVMC

Sam Siewert 5

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

6-6

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

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)

http://alleg.sourceforge.net/

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

Activity – Select 1 of 4 Architectures

Summary of Architectures of Interest – Last Time

On a Paper Select 1 of 4 Architectures

– Interactive – Cmd Line, GUI, Visualization/Graphics, Games

– Event Driven – Detection, Tracking, Digital Control

– Transformational – Image Proc, Comp Vision, Numerical

– Transaction – DBMS, Client/Server

Propose Application or Software System of Your Interest

– Requirements Draft Specification

– Analysis

– Architecture

Potential Definition of Project for Second Half

Sam Siewert 11

Assignment #4 - #6

Analyze, Design, Construct PoC or Mock-Up

3 Scrum Sprints

3 Status Presentations (15 Minutes)

1 Final Presentation (30 Minutes)

Teamwork! Individual Effort (Contributions Must be

Clear)

Sam Siewert 12

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

Provide Code Re-Use Candidates and PoC

Sam Siewert 13

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



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

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

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



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



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



Information Hiding module

controlled

interface

"secret"

• algorithm

• data structure

• details of external interface

• resource allocation policy

clients

a specific design decision



Why Information Hiding?

reduces the likelihood of “side effects”

limits the global impact of local design

decisions

emphasizes communication through

controlled interfaces

discourages the use of global data

leads to encapsulation—an attribute of

high quality design

results in higher quality software



Functional Independence Functional independence is achieved by developing

modules with "single-minded" function and an "aversion" to excessive interaction with other modules.

Cohesion is an indication of the relative functional strength of a module. A cohesive module performs a single task, requiring little

interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing.

Coupling is an indication of the relative interdependence among modules. Coupling depends on the interface complexity between

modules, the point at which entry or reference is made to a module, and what data pass across the interface.



Aspects

Consider two requirements, A and B.

Requirement A crosscuts requirement B “if a

software decomposition [refinement] has been

chosen in which B cannot be satisfied without

taking A into account. [Ros04]

An aspect is a representation of a cross-cutting

concern.



Aspects—An Example

Consider two requirements for the SafeHomeAssured.com WebApp. Requirement A is described via the use-case Access camera surveillance via the Internet. A design refinement would focus on those modules that would enable a registered user to access video from cameras placed throughout a space. Requirement B is a generic security requirement that states that a registered user must be validated prior to using SafeHomeAssured.com. This requirement is applicable for all functions that are available to registered SafeHome users. As design refinement occurs, A* is a design representation for requirement A and B* is a design representation for requirement B. Therefore, A* and B* are representations of concerns, and B* cross-cuts A*.

An aspect is a representation of a cross-cutting concern. Therefore, the design representation, B*, of the requirement, a registered user must be validated prior to using SafeHomeAssured.com, is an aspect of the SafeHome WebApp.



Refactoring

Fowler [FOW99] defines refactoring in the following manner: "Refactoring is the process of changing a software system in

such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.”

When software is refactored, the existing design is examined for redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures or any other design failure that can be corrected to yield a better

design.



OO Design Concepts

Design classes

Entity classes

Boundary classes

Controller classes

Inheritance—all responsibilities of a superclass is

immediately inherited by all subclasses

Messages—stimulate some behavior to occur in the

receiving object

Polymorphism—a characteristic that greatly reduces the

effort required to extend the design

Domain Models – Use Case Details Complete a Design

Provide Code Re-Use Candidates and PoC

Sam Siewert 26

Start Here!



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



Architecture Transition to Design

Use Case, Domain Model (Class Diagram) -> OIM

(Instantiation, Addition of Methods, Interaction)

Refinement of Class Diagram from Domain Model to

Design Class Diagram

– Hierarchical Refinement

– Updates Based on Object Model (static instantiation) and OIM

(dynamic interaction)

– Association and Aggregation Details

Preparation to Define the Body, Implementation of

Methods and the Application Class (or Driver)

Sam Siewert 27



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


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

Why Architecture?

The architecture is not the operational software. Rather, it is a representation that enables a software engineer to:

(1) analyze the effectiveness of the design in meeting its stated requirements,

(2) consider architectural alternatives at a stage when making design changes is still relatively easy, and

(3) reduce the risks associated with the construction of the software.



Why is Architecture Important?

Representations of software architecture are an enabler

for communication between all parties (stakeholders)

interested in the development of a computer-based

system.

The architecture highlights early design decisions that

will have a profound impact on all software engineering

work that follows and, as important, on the ultimate

success of the system as an operational entity.

Architecture “constitutes a relatively small, intellectually

graspable mode of how the system is structured and

how its components work together” [BAS03].



Architectural Descriptions

The IEEE Computer Society has proposed IEEE-Std-1471-2000, Recommended Practice for Architectural Description of Software-Intensive System, [IEE00]

to establish a conceptual framework and vocabulary for use during the design of software architecture,

to provide detailed guidelines for representing an architectural description, and

to encourage sound architectural design practices.

The IEEE Standard defines an architectural description (AD) as a “a collection of products to document an architecture.”

The description itself is represented using multiple views, where each view is “a representation of a whole system from the perspective of a related set of [stakeholder] concerns.”



Architectural Genres

Genre implies a specific category within the

overall software domain.

Within each category, you encounter a number

of subcategories. For example, within the genre of buildings, you would

encounter the following general styles: houses,

condos, apartment buildings, office buildings,

industrial building, warehouses, and so on.

Within each general style, more specific styles might

apply. Each style would have a structure that can be

described using a set of predictable patterns.



Architectural Styles

Data-centered architectures

Data flow architectures

Call and return architectures

Object-oriented architectures

Layered architectures

Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.



Data-Centered Architecture



Data Flow Architecture



Call and Return Architecture



Layered Architecture



Architectural Patterns Concurrency—applications must handle multiple tasks in a

manner that simulates parallelism

operating system process management pattern

task scheduler pattern

Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common:

a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture

an application level persistence pattern that builds persistence features into the application architecture

Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment

A broker acts as a ‘middle-man’ between the client component and a server component.



Architectural Design

The software must be placed into context

the design should define the external entities (other

systems, devices, people) that the software interacts

with and the nature of the interaction

A set of architectural archetypes should be

identified

An archetype is an abstraction (similar to a class)

that represents one element of system behavior

The designer specifies the structure of the

system by defining and refining software

components that implement each archetype



Architectural Context

target system:

Security Functionuses

uses peershomeowner

Safehome

ProductInternet-based

system

surveillance

function

sensors

control

panel

sensors

uses



Archetypes

Figure 10.7 UML relat ionships for SafeHome securit y funct ion archetypes

(adapted f rom [BOS00] )

Cont roller

Node

communicates with

Detector Indicator



Component Structure

SafeHome

Execut ive

Ext ernal

Communicat ion

Management

GUI Int ernet

Int erface

Funct ion

select ion

Securit y Surveillance Home

management

Cont rol

panel

processing

det ect or

management

alarm

processing



Refined Component Structure

sensorsensor

sensorsensor

sensorsensorsensor

sensor

Ext ernal

Communicat ion

Management

GUI Internet

Interface

Security

Cont ro l

panel

processing

det ect or

m anagem ent

alarm

processing

Key pad

processing

CP d isp lay

funct ions

scheduler

sensorsensorsensorsensor

phone

com m unicat ion

alarm

SafeHome

Execut ive



Architectural Considerations

Economy – The best software is uncluttered and relies on abstraction

to reduce unnecessary detail.

Visibility – Architectural decisions and the reasons for them should

be obvious to software engineers who examine the model at a later

time.

Spacing – Separation of concerns in a design without introducing

hidden dependencies.

Symmetry – Architectural symmetry implies that a system is

consistent and balanced in its attributes.

Emergence – Emergent, self-organized behavior and control.

Architectural Decision

Documentation

1. Determine which information items are needed for each

decision.

2. Define links between each decision and appropriate

requirements.

3. Provide mechanisms to change status when alternative

decisions need to be evaluated.

4. Define prerequisite relationships among decisions to

support traceability.

5. Link significant decisions to architectural views resulting

from decisions.

6. Document and communicate all decisions as they are

made.



se300 software engineering practicesmercury.pr.erau.edu/~siewerts/se300/documents/... · strength...

Documents