Software Architecture and Specification 2 Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga Fall 2009

C-Level Specifications: Overview Written by the developers Customer does not have approval rights Describes the design “as built” Defines how a software product satisfies its requirements. Includes for each component: Design, concept, physical structure, states, control and low-level interface details Translates logical descriptions of B-Spec into: Physical structure, classes, functions and data structures used to implement each component

C-Level Specifications: Contents The C-Specification Contains: Physical description of the software architecture One or more activity diagrams and package diagrams or structure charts showing data and control flow between programs and modules A physical description for each module One or more of the following for each module: Package diagram or structure chart Class diagrams Event trace State transition diagram or control flow graph Manual/Maintenance Pages in the Code with HIPOs A data dictionary describing data flows between components

C-Spec Structure 1.Architecture 1.Referenced Documents 1.Module Specifications 1.Class Declarations 2.Function Definitions 3.Structure Charts 4.State Transitions Diagrams 5.Event Trace Diagrams 2.Data Dictionary Names, Types, Scope and Descriptions of Declared Data 1.Notes 1.[Complete Code Listings]

Activity Diagram (CRC Builder)

Package Diagram Example (VRTS)

Structure Chart Example (Duplicates)

Class Diagram Example (Duplicates) aggregation composition derivation using Key

Event Trace Diagram (Duplicates)

State Transition Diagram (Pattern Matcher) Start (Match)

Specification Goals Legally Complete Requirements Spec – Complete description of what must be done Product Spec – Complete description of how the processing is accomplished in this product Eliminates all ambiguity Definition of what is ambiguous depends on the expertise of development team and customer For example: declared – 5 definitions. We want to formally make known Brief Eliminate all redundancy and extraneous descriptions No adjectives or adverbs Based on architectural components Allows team to work relatively independently on an assigned component Makes orderly integration and test possible

Specification Summary A level spec B level spec C level spec Contractual description of what the product will do, how it behaves. Each “shall” is binding and tested at system test. High level decomposition, description of processing and data flows. Each “shall” is binding and tested at qualification test Physical description of each component, as built. No “shalls”. Eventually contains the source code listings.