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 system Programs are components of a software system Modules are components of a program Lower 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 of software system organizing principles high level structure design issues logical models of major processing components with data flows logical process models --> logical modules --> functions, classes --> physical modules physical modules --> physical programs --> physical system logical behavioral model of software system decomposition in application domain Re composition in 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-Spec On 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 manner PSpec matches a DFD process PSpec contains a HIPO (hierarchical input, processing, output) section which becomes the prologue for the corresponding module which implements it

Data Flow Diagram Example TOP Executive 1 getUniqueFileName 2 displayHeader 3 displayFile 4 file pattern filename file handle, parameters filename, commands filename file handle, number of lines header line file text filename patterns, commands error message file handle processCL 5 filename Pspec 2 derived requirement: shall find names of files in default directory that match a given filename pattern Pspec 1 shall accept a sequence of filename patterns and commands Pspec 3 shall display name of each file processed Pspec 4 shall display first few lines of file text Pspec 5 shall recognize -n command, set number of lines to n, otherwise set number of lines to 5

B-Specification Structure

B-Level Specification Example Duplicates B-Spec On 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