Course Summary: Review of Software Engineering

Requirements and Architecture

Course Summary: Review of Software Engineering

Requirements and Architecture

Gruia-Catalin Roman and Christopher Gill

CSE 436 Spring 2007Department of Computer Science and Engineering

[ §1 : 2 ]

Costs The cost of correcting an

error grows very rapidly as the project moves along its life-cycle

This observation argues for early error detection and provides the motivation for technical reviews

The highest cost errors are those involving the systems requirements formulation

error correction cost

point of

detection

[ §1 : 3 ]

Response

There is no silver bullet for the very difficult task of requirements definition and management

The state of the art, however, is very much ahead of the state of the practice

What you learn in this course, you can apply with impact A standardized framework can be the conduit for

bridging the gap increased awareness common terminology assimilation of very basic practices

[ §1 : 4 ]

Motivation

Premise of modern software engineering design/planning must consider product’s entire life this is a central and essential assumption

In contrast, a more narrow perspective e.g., development only is likely to lead to failures lacks dependability assurances risks later expenses much > development costs

[ §1 : 5 ]

Waterfall Model of System Lifecycle

Understanding requirements

presupposes a good grasp of the development process as a whole

Waterfall model remains one of the best

abstractions for the entire development process

Requirements definition

System design

Software design

Implementation and unit testing

Integration and testing

Operation and maintenance

[ §1 : 6 ]

Requirements in Context Requirements may vary

in level of abstraction, contents from one context to another

System requirements result from an analysis or discovery

process Software requirements

result from a design process involving requirements allocation

Sometimes there is no distinction between them

Requirements definition

System design

Software design

system requirements

software requirements

constraints

problem needs

[ §1 : 7 ]

Terminology A requirement is a technical objective which is imposed upon

the software, i.e., anything that might affect the kind of software that is produced

A requirement may be imposed by the customer the developer the operating environment

The source, rationale, and nature of the requirement must be documented

Requirements fall into two broad categories functional non-functional

[ §1 : 8 ]

Communication Issues Missing or vague requirements are a recipe for disaster Anything that is not made explicit may not be implemented or

considered Anything that is ambiguous is likely to get implemented in the

least desirable way Standard trade practices may be omitted (in principle!) Cultural settings do affect the way in which requirements are

written and read Multiple views may be required to formulate a reasonably

complete set of requirements

[ §1 : 9 ]

Functional Requirements Functional requirements are concerned with what the software

must do capabilities, services, or operations

Functional requirements are not concerned with how the software does things, i.e., they must be free of design considerations

Functional requirements are incomplete unless they capture all relevant aspects of the software’s environment

they define the interactions between the software and the environment

the environment may consist of users, other systems, support hardware, operating system, etc.

the system/environment boundary must be defined

[ §1 : 10 ]

What Constitutes “Functional”?

Type as input, value as output E.g., towards constructors and initialization methods

Type as input and output E.g., towards allowed polymorphism and type conversions

Value as input and output E.g., towards functions and operators

Value as input, type as output E.g., towards classifiers and type identifiers

… combinations of these kinds of domains/ranges

[ §1 : 11 ]

Non-Functional Requirements Non-functional requirements place restrictions on the

range of acceptable solutions Non-functional requirements cover a broad range of

issues interface constraints performance constraints operating constraints life-cycle constraints economic constraints political constraints manufacturing

[ §1 : 12 ]

What about Time?

Superficially, time seems (and often may be) non-functional E.g., when running faster is “a good thing” but does not change

outcome However, some systems are inherently time-dependent

E.g., human interaction, mechanical control, etc. Making system run too much faster or slower may be harmful In such cases, time must be treated as a functional element

One technique is to transform time into events A timer or other device has a specified setting (e.g., rate) : Τ The device generates events at times governed by that setting : f(Τ)

Functional requirements can be written about Τ and f(Τ) Per a model that represents the relationship between Τ and f(Τ)

[ §1 : 13 ]

Elicitation

Discover and catalogue application needs Identify constraints Identify and prioritize objectives Reconcile conflicting views Define standard terminology Separate concerns Organize the information Pave the way to conceptualization Make technical specifications feasible

[ §1 : 14 ]

Principal Product of Elicitation

Requirements Definition Document (RDD) is still at a relatively high level does not provide yet a baseline for the development

(needs to be refined and extended during specification) does provide the basis for specification is the starting point for a number of specialized preliminary

studies The document must be accessible to a broad range

of readers customers, users, managers, designers

[ §1 : 15 ]

Sample RDD Table of Contents

1. Introduction

- the mind set

2. Definition of terms

- the basis for accurate communication

3. Objectives

- the central issue

4. Overall system organization

- the context

5. External Interfaces

- the environment refined

6. Capabilities

- the outline for a solution

7. Constraints

- the bounds placed on the solution space

8. Additional documentation

- attached or included by reference

[ §1 : 16 ]

Software Requirements Specification (SRS)

Point of origin elicitation and/or allocation

activity

Purpose provide a baseline for all

software development activities

Focus software/environment

interactions technical reformulation of

constraints

Nature highly technical

Usage design testing technical studies

[ §1 : 17 ]

Sample SRS Table of Contents

1. Introduction (ANSI/IEEE STD-830-1984)2. General description3. Specific requirements

3.1 Functional requirements- input/processing/output

3.2 External interface requirements- interface specification

4. Performance requirements (non-functional)5. Design constraints6. Attributes7. Other requirements

[ §1 : 18 ]

Traceability Objectives, capabilities, and

constraints in the RDD are traceable to the SRS

having to trace the less-technical RDD to design can become counterproductive

one objective may affect everything

Using the RDD only to construct the SRS is feasible for some projects

objectives and rationale should not be lost

RDD

SRS

DESIGN

[ §1 : 19 ]

Traceability Traceability is a property of the software development process

refers to the ability to relate elements of a specification to those design components that ensure their satisfiability

relations that are precise and narrow in scope simplify analysis relations that are diffused often entail complex analysis

Specifications may be functional or non-functional part of the system requirements or the byproduct of design

Traceability is a useful tool, but not a substitute for verification Most traceability chains run through the software architecture

requirements to design design to code

[ §1 : 20 ]

Requirements Verification Requirements verification is an activity directed

towards the discovery of specification errors The ultimate goal is to ensure that the specification

(when considered on its own) is correct consistent complete

The verification must be carried out against a model (formal or informal)

Formal and semi-formal specifications can be checked out by tools

[ §1 : 21 ]

Verification Example: Elevator Door Control Logic

Consider a deterministic finite state representation of the elevator movement logic

Some errors can be detected simply by the nature of the model

invalid initial state missing transitions non-deterministic transitions possible live-lock, etc.

arrived

door open

door closed

departed

floor j

floor sensor input

request from this floor and none for other floors

timeout with no requests

request for some other floor

down movement

down movement

[ §1 : 22 ]

Requirements Validation

Concerned with establishing that specified requirements represent the needs of the customer and/or user

Needs are not reflected by any model or document

Thus, validation cannot be performed in a mechanical way

Good communication is the key to a successful validation

well-defined terminology well-written and simple

specifications formal reviews rapid prototypes simulations

[ §1 : 23 ]

Validation Example: Elevator Movement Policy

Consider an elevator movement policy which takes the elevator up and down, from top to bottom, and

services requests as it goes The policy satisfies the customer stated requirements

every request is eventually serviced there is a defined upper bound on the time it takes for a

request to be serviced Nevertheless

the time it takes to service a request during low demand periods may be unacceptable

unnecessary energy utilization emerges as a new issue the need for a better policy (and ideas about it) may emerge

[ §1 : 24 ]

Requirement Specification & Testing: Requirement Specification & Testing: Domain Specific Scripting Languages Domain Specific Scripting Languages

1.1. aircraft.digital_inputs[FLAPS] = 2;aircraft.digital_inputs[FLAPS] = 2;2.2. threat_environment->addThreat(new threat_environment->addThreat(new

ThreatAircraft(MIG_29, aircraft.altitude, ThreatAircraft(MIG_29, aircraft.altitude, position_offset(aircraft.latitude,aircraft.longitudposition_offset(aircraft.latitude,aircraft.longitude,aircraft.bearing,3*MILES_TO_FEET)));e,aircraft.bearing,3*MILES_TO_FEET)));

1.1. aircraft.extend_flapsaircraft.extend_flaps2.2. create_threat create_threat “MIG29”“MIG29”, :distance => , :distance => 3.miles3.miles

In contrast to…

Readable, approachable language

(Thanks to John Aughey for this slide)

[ §1 : 25 ]

State Machine Models External actions associated

with transitionsDocumentation implications

3. Specific Requirements

3.1 Initial state

Initialization

3.2 State A

3.2.1 Event X

Next State S’

Action A

off ready

heating

cooling

push ——— lock

push ——— unlock

push ——— unlock

low ———

heater on green light

high ———

heater off red light

high ——— yellow

low ——— yellow

[ §1 : 26 ]

Finite State

Controller

system objects

external object

events actions

external object

Object-Oriented Variations

Events may be external or internal (conditions) Actions may be external or internal (operations)

[ §1 : 27 ]

Data Flow Models Dataflow diagram notation

functions—deterministic input/output transformations triggered by the presence of all needed inputs

flows—unbounded queues stores—global system data terminators—interface

models minispecs—semantics of

the lowest level functions

verify customer

update stock

update customer

data

prepare order

inventory

mailing address

customer file

item

item profile

order

phone order

shipping

operator

customers

[ §1 : 28 ]

User Manual

For Applications Involving Human Interfaces

Effective specifications often require the integration of multiple related models

Human/computer interactions are too complex for commonly used requirements techniques

The User Manual can be used as a substitute for (and/or can grow out of) large sections of the SRS

[ §1 : 29 ]

User Interface Navigation

Identify the screens/windows Define permitted transitions

among them as a graph Identify the events that

trigger moves from one screen/window to another

Identify interactions common among screens/windows

specific to the user interface paradigm in use

[ §1 : 30 ]

uses

extends

authorization

phone call

charging

Use Case Models Actors

model the environment and the users

initiate activity by providing stimuli

can be primary or secondary Use cases

are complete courses of action initiated by actors (basic or alternative)

can be extended by (interrupt analogy) or use other use cases (call analogy)

[ §1 : 31 ]

Architecture Design Phase

Technical goals Identify the principal components that make up

the system and their (internal and external) interfaces

Ensure compliance with respect to expectations captured in the requirements specification

Understand, assess, and control risks Ensure predictability of the development process

through accurate planning

[ §1 : 32 ]

Software Architecture as Artifact

The architecture of a system is an abstract description of its structure and behavior

The level of abstraction is chosen such that all critical design decisions are apparent and meaningful analysis is feasible

A complete software architecture is usually specified by a combination of design diagrams component specifications

[ §1 : 33 ]

Controller

Timer

Intake Outtake

HeaterTank

HeatController

Water Tank

Hierarchy and Partition

Water tank example

[ §1 : 34 ]

Many Architectural Styles

Composition static

layered controller client/server pipes and filters peer to peer proxy / object-based

dynamic object-oriented software bus service provision

Communication explicit

message passing event propagation

Coordination implicit

blackboard shared tuple space database/futures

Emerging styles new software domains

mobile computing sensor networks

[ §1 : 35 ]

Design Diagrams

An abstraction of the system structure A map of the system organization at a particular

level of abstraction Names of the principal system components and

relations among them Hints at the operational behavior of the system

(constrains what the system can do) May provide implementation directives

[ §1 : 36 ]

Component Specifications

Component specifications supply the details needed to provide a complete system description at this particular level of abstraction interface syntax interface semantics

The structural and behavioral properties captured by the component specifications must be consistent with the design diagram

[ §1 : 37 ]

Alternative Decomposition Approaches

Function-oriented modularity

Synonyms: action, process, transformation

Basic idea: organize the system structure around the kinds of activities it must perform

Rationale: a system is the functionality it supplies to the user

Object-oriented modularity

Synonyms: data record, class

Basic idea: organize the system structure around the kinds of data it must maintain

Rationale: functionality changes more often than the data required to support it

[ §1 : 38 ]

An Example of Component Notation

Passive procedure object

Active task active object

Organizational package

External devices and interfaces

procedure object

taskactive object

package

[ §1 : 39 ]

@ class

method 1method 2method 3

class

@ method 1@ method 2 method 3

Object Level Synchronization

The notation is the same for classes and objects and so are the semantics

Synchronized objects specify mutual exclusion among all methods

Notation and semantics may be adjusted for different settings

Synchronized methods limit mutual exclusion to identified methods

[ §1 : 40 ]

Component

Sample component types

procedure object process (threaded object)

Interface depends on component type and language—but it is real

Behavior reflects the component type but must be abstract

Heater Methods

turn on, turn off failed, heating

State active (T/F) failed (T/F)

Heater

HeatController

h = 1..4

activeinactive

failed

turn on

turn off

[ §1 : 41 ]

Connector

Sample connector types procedure invocation message queue

Connectors are complex specialized components

Heat Controller vs. Heater Possible alternatives

method invocation message passing event notification

Heater

HeatController

h = 1..4

Heater

h = 1..4

Heater

HeatController

h = 1..4

send

get

raise heater on

HeatController

[ §1 : 42 ]

Sample Connectors

water

incident logging

field condition

auto watering

manual watering

ph sprayertimer

sensor field bus

sensor loss

intruder

message queue

[ §1 : 43 ]

Actuator Actuators are events of

a predefined nature that initiate activity

timer interrupt mouse down

Implementation is language specific often complex distributed across the

code Conceptually are

simple to understand easy to analyze

Heat Controller Some methods are time

triggered

Heater

HeatController

h = 1..4

heater duty cycle is at the level of 100

milliseconds

[ §1 : 44 ]

Modular Design

alignment manager

travel manager

door manager

alignment sensor main motor

door assembly

floor sensor

elevator control

[ §1 : 45 ]

Responsive Design

Continuous alignment while at a floor

door manager

alignment manager

travel manager

alignment sensor main motor

door assembly

floor sensor

elevator control

[ §1 : 46 ]

Safe Design

Doors are closed while moving or not at a floor

door manager

travel manager

alignment sensor

main motordoor

assemblyfloor sensor

elevator control

edge up edge downfloordoor floor departur

e request

mandatory check

doors closedstationarylevel at floor

[ §1 : 47 ]

Concluding Remarks

Development of software based systems is complex multiple perspectives different notations significant and sophisticated analysis

Requirements elicitation and specification should focus on communication among people

Requirements must be traceable through the architecture to the code itself (and vice versa)

The design process should focus mainly on fundamentals and on the creative activities