Software Architecture and Specification

Derived from Dr. Fawcett’s slides

Phil Pratt-Szeliga

Fall 2010

Definitions - Synonyms

A Level Specifications Customer’s Requirement Specification A Spec Engineering Specifications

B Level Specifications Developer’s Requirement Specification B Spec Software Requirements Specification (SRS)

C Level Specifications “As Built” Product Specification C Spec Software Design Document (SDD)

Software Architecture

Architectural Model = Top level structure + organizing principles Top level structure: partitioning system into high level

components (usually resulting in modules) Organizing principles: a few concepts and design

decisions which set the course of implementation The model includes an operational description of

each component and the system as a whole Critical Issues

Architectural Model Purpose: Help focus on dominant design mechanisms Channel design activities toward implementation

Software Architecture

Architectural Model bridges between requirements and implementation

An initial architectural model is: Created for the contract’s proposal Elaborated in requirements analysis Completed during preliminary design

All requirements analyses should result in an architectural model

All designs should begin with a top down phase, guided by the architectural model

Software Architecture

Life Cycle

- Developed during requirements analysis

- Guides top level design and evolves with design

- Should be fairly static during implementation and testing

Software Components

Software Components: Parts of the physical structure of a software systemPrograms are components of a

software systemModules are components of a

programLower level modules, classes and

functions are components of a module

Software Components

The representation of a software component consists of: Logical Model: summary description of its

operation Behaviors: specific operations that a

component performs. Behaviors are characterized by:

• Pre and Post conditions• Invariants

State: values of internal data Logical Models and Behaviors defined in B-

Spec State and Control defined in C-Spec

Decomposition

All but the smallest and simplest software systems need to be decomposed into partitions

Partitioning is based on one or more criteria: Logical – identify important objects and the

processing for each Data Driven – decompose processing to

minimize data coupling. Promotes robustness under change

Requirements Design – Decompose along A-Spec boundaries. Makes qualification easier and boosts customer confidence

Decomposition

Partitioning is based on one or more criteria: Usability – Configure processing for simple,

model driven user interfaces Reuse – Partition into components so that

boundaries match existing software to be reused

Device Independence – Isolate all platform processing

Performance – Minimize data transport, contention for resources, operator intervention and balance workload in distributed systems

Breaking Down

Software Requirements Analysis and preliminary design are processes of decomposition in the application domain Requirements decomposed into processes

and data flows Process – logical model of some activity

necessary to satisfy part of requirements Data flows – represent information

necessary to sustain activities allocated to the process

Breaking Down

Each process is allocated part of application’s requirements model May derive additional requirements to

complete or disambiguate processing model Design Structure

Developed by associating major processes with modules

Public interface of major modules represent associated process and data flow

Each stage of decomposition needs to allocate requirements to its component parts to prove correctness of the design

Building Up

Detailed design and testing Process of recomposition in the solution

domain A logical module becomes a physical

module when its implementation is filled in using functions and private data

Each function and class is tested for conformance to its process model

Modules are populated in order of their dependencies

This process continues until all system requirements are met

Breaking Down, Building Up

A-Specification

Architectural Concept

B-Specification

C-Specification

Integration & Test

Qualification Test

logical behavioral model ofsoftware system

organizing principleshigh level structure

design issues

logical models of major processing

componentswith data flows

logical process models --> logical modules

--> functions, classes --> physical modules

physical modules --> physical programs--> physical system

logical behavioral model ofsoftware system

decompositionin application domain

Re compositionin solution domain

Requirements Specifications

Specification Purpose: Describe the contractual obligations of the

developer to the customer Describe the allowable context –

programming language, platform, testing scope, required reviews, schedule

Specification Goals: Completeness - must describe all processing Unambiguous – must clearly state each

requirement Brief – no redundancy or extraneous

descriptors (no adjectives, no adverbs)

Requirements Specifications

Specification Topics: Requirements should describe the

functioning and performance of a software component but should not describe design

For example: • Good: The swarm computing module shall accept

commands from peers. The commands that it shall accept are create variable, set value of variable and add two variables.

• Bad: The swarm computing module shall have a blocking queue for each peer and then merge the communication from the blocking queue of each peer into another blocking queue.

Information flow is shown in data flow diagrams but not specified because the flow may change

A-Level Requirements Specification Written by the customer often with

significant help from developers Describes requirements from customer’s

point of view Defines what software must do to satisfy

developer’s obligations to the customer Usually accompanied with the required

schedule, reviews and process requirements Each “shall” in the A-Spec represents a

contractually binding requirement which is demonstrated during Qualification Testing

A-Level Requirements Specification A-Level Specification Contains

Logical description of software’s operation A context diagram which shows developed

software as one process with external inputs and outputs shown as rectangles

A function and performance requirements section

Data dictionary which summarizes all information flow into and out of the developed software, only if it is quite complex

A-Level Requirements Specification Example

Duplicates A-SpecOn website – lecture 1

B-Level Requirements Specification Written by the developers, approved by the

customer Describes the software requirements from

developer’s point of view Describes contractual requirements on

software functionality and performance in terms of architectural components

The logical structure and behavior of each component is specified along with the interfaces between each

B-Level Requirements Specification

A B-Level Specification consists of: Architecture Description – logical descriptions for

each software component’s operation Top Level Modules Dataflow diagrams – show the information

transferred between components PSpecs – describe the inputs, processing and

outputs for each process (e.g. public interface)• Processing descriptions contain the requirements• The basis of qualification testing

Data dictionary (next slide) Requirements Traceability Matrix (next slide)

B-Level Requirements Specification

Data dictionary – lists each data flow between components and to/from the environment

Requirement Traceability Matrix – shows the allocation and derivation relationships between A and B spec requirements

B-Level Requirements Specification

DFDs are constructed in a hierarchical mannerPSpec matches a DFD processPSpec contains a HIPO (hierarchical

input, processing, output) section which becomes the prologue for the corresponding module which implements it

Data Flow Diagram Example

TOP Executive1

getUniqueFileName2

displayHeader3

displayFile4

file

patte

rn

filen

ame

file handle,param

eters

filename,

comm

ands

filename

file handle,

number of lines

header line

file te

xt

file text

filename patterns,

comm

ands

error messagefile

hand

le

processCL5

filename

Pspec 2derived requirement:shall find names of files indefault directory that match agiven filename pattern

Pspec 1shall accept a sequenceof filename patterns andcommands

Pspec 3shall display name ofeach file processed

Pspec 4shall display firstfew lines of file text

Pspec 5shall recognize -ncommand, set number oflines to n, otherwise setnumber of lines to 5

B-Specification Structure1. Architecture:

uses, tasks, views, objects, events, interactions

2. Referenced Documents

3. Requirements: Data Flow Diagrams Process Specifications

4. Data Dictionary: Data Flow Names, Descriptions

5. Requirements Tracability Matrix: B-req, A-req or derived, description

6. Notes

B-Level Specification Example

Duplicates B-SpecOn website, lecture 1

B-Specification Hints Specify what the software shall do, not how Make testable requirements. Be complete and unambiguous with shalls Explicitly use the word “shall” for something

that must be done Effective use of Context and DFD

Diagrams: Balance – the outputs of the context diagram

are matched to the inputs of the top level DFD. the inputs to a top level process match up to a diagram of a lower level process

Leveling – creating a hierarchy of data flow diagrams

Numbers on DFD Processes must match PSpecs

DD and RTM must be complete