1. Chapter 3 Software Architecture and Specification
CSE784 Software Studio Class Notes
Chapter 3 Software Architecture and Specification
Jim Fawcett copyright ©

2. Definition - Synonyms A-Level Specifications B-Level Specifications
Customer’s Requirements Specification
A Spec
Engineering Specifications
B-Level Specifications
Developer’s Requirements Specification
B Spec
Software Requirements Specification (SRS)
C-Level Specifications
“As Built” Product Specification
C Spec
Software Design Document (SDD)

3. Software Architecture
Architectural Model = top level structure + organizing principles
Top level structure is a partitioning of the system into high level components (usually resulting in modules)
The model includes an operational description of each component and the system as a whole.
Organizing principles are a few concepts and design decisions which set the course of the implementation.
The purpose of an architectural model is to help focus on the dominant design mechanisms, whatever they are, and channel design activities toward their implementation.
The architectural model of a software system is a bridge between its requirements and implementation.
When the architectural model is complete we should be confident that the software system can be constructed with a practical implementation.
An initial architectural model of the system is created for the contract’s proposal, is elaborated in requirements analysis, and is 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.

4. Software Components
Software components are 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 com-ponents of a module
The representation of a software component consists of its:
Logical model: a summary description of its operation
Behaviors: specific operations that the component performs. Behaviors are characterized by:
pre-conditions assumed to hold before operation begins
post-conditions guaranteed to hold at completion if the pre-conditions are satisfied
invariants are assertions which hold throughout the component’s operation
State: values of internal data which may influence and be influenced by the component’s behaviors.
Logical models and behaviors are usually defined in a requirements specification (synonyms: SRS, B level specification).
Component state and control are usually defined in a design document (synonyms: product specifica-tion, C level specification).

5. Decomposition
All but the smallest and simplest software systems need to be decomposed into partitions to ensure correct, reliable, and maintainable implementations.
Partitioning is based on one or more of the criteria:
Logical: identify important objects and the processing required for each.
Data Driven: decompose processing to minimize data coupling between components. Promotes independence and robustness under change.
Requirements driven: decompose along A-Spec boundaries. Makes qualification test easier, builds customer confidence.
Usability: configure processing for simple, model driven user interfaces.
Reuse: partition into components so that boundaries match existing software to be reused. Within new software partition into small, simple, basic components and executives which use basic components to realize application requirements. The basic components can be reused in new applications.
Device Independence: isolate all platform specific processing from rest.
Performance: decompose to maximize performance, e.g., minimize data transport, contention for resources, balance loading in distributed systems, minimize I/O to physical devices, minimize operator intervention.

6. Breaking Down
Software requirements analysis and preliminary design are processes of breaking down or decomposition in the application domain:
Application requirements are decomposed to processes and data flows.
Process is a logical model of some part of the program’s activities necessary to satisfy part of its requirements model.
Data flows represent the information necessary to sustain activities allocated to the process.
Each process is allocated part of the program’s requirements model and may derive additional requirements necessary to complete or disambiguate its processing model.
A design structure is developed by associating major processes with modules.
Each such process and its data flows represents the public interface of its module.
Each stage of the decomposition needs to flow down, or allocate, requirements to its component parts, otherwise there is no basis for deciding the correctness of the design.

7. Building Up
Detailed design and testing is a process of building up or recomposition in the solution domain:
A logical module, e.g. a public interface description of a module, becomes a physical module as it is populated with functions and classes. That is it’s built up of functions and private data elements which implement its logical model.
Function and class development builds a language into which the application’s processing is encoded.
new functions and classes are added to satisfy the process model of the module in which they are embedded
Each function and class is tested for conformance to its process model.
modules are populated in order of their dependencies and used to progressively build system capability
this process continues until all system requirements are met and tested

8. Breaking Down, Building Up
logical behavioral model of
software system
A-Specification
organizing principles
high level structure
design issues
Architectural Concept
decomposition
in application domain
logical models of
major processing
components
with data flows
B-Specification
logical process models
--> logical modules
--> functions, classes
--> physical modules
C-Specification
recomposition
in solution domain
physical modules
--> physical programs
--> physical system
Integration & Test
logical behavioral model of
software system
Qualification Test

9. Requirements Specifications
Specification Purpose:
describe the contractual obligations of the developer to the customer
describe the allowable context, e.g., language, development process, testing scope, required reviews, schedule
Specification Goals:
Completeness: must describe all required processing.
Unambiguous: must clearly state each requirement, eliminating possibility of misinterpretation.
Brief: eliminates all redundancy and extraneous descriptors (no adjectives, no adverbs).
Specification Topics:
Requirements describe the functioning and performance of a software component but should not describe design. Information flow is shown in Data Flow Diagrams, but is not specified as requirements because it may change based on design decisions made later.
Requirements emphasize logical models in the application domain. Design emphasizes physical models in the solution domain.

10. 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 the devel-oper’s obligations to the customer.
The A-level specification describes contractual requirements on software functionality and performance in terms of its external behavior. It is usually accompanied by a statement of work describing the required schedule, reviews, and requirements on the development process.
Each “shall” in the A-Spec represents a contractually binding requirement which is demonstrated in System Test.

11. A-Level Specification
The A-Specification contains:
a logical description of the developed software’s operation.
a context diagram which shows the developed software as one process with external sources providing all information and control inputs required by the software and external sinks which accept all outputs generated by the software.
a section containing functional and performance requirements sections with requirements indicated by “shall”s. These requirements constitute the contract and define system testing.
Data Dictionary summarizes all information flow into and out of the developed software, only if it is quite complex.

12. B-Level Requirements Specification
Written by developers, approved by customer.
Describes the software requirements from developer’s point of view
B-level specification, also called a Software Requirements Specification (SRS), describes contractual requirements on software functionality and performance in terms of its architectural components. The logical structure and behavior of each component is specified along with the interfaces between each.
In large systems there is usually one SRS for each major component. In that case each SRS partitions its software into minor components, specifying the behavior and interfaces of each.
Each “shall” in the B-Spec represents a contractually binding requirement which is demonstrated in software Qualification Test. It is either allocated from an A-Spec requirement or derived to eliminate ambiguity.

13. B-Level Specification
A B-level specification consists of:
Architecture Description logical descriptions for the operation of each software component covered by the B-spec (may not be the whole system) in an architecture section.
dataflow diagrams (DFDs) show processing required of each component, the information transferred between components, and interfaces between the software and its environment (inherited from the A-spec context diagram).
Pspecs describe the inputs, processing, and outputs for each process, e.g., its public interface. Pspec processing descriptions contain the requirements, e.g., “shall”s for all processing of each component. These flow down the A-level “shall”s and derive new “shall”s as needed to complete requirements. Pspecs are the basis for software qualification testing. DFDs are constructed in a hierarchical manner. The Pspec, matching a DFD process, contains a HIPO or hierarchical input, processing, output section which becomes the prologue for the corresponding module which implements it.
Data Dictionary (DD) lists each data flow between components and to and from the environment.
Requirements Traceability Matrix (RTM) shows the allocation and derivation relationships between A and B spec requirements.

14. Data Flow Diagram Example

15. Information Cluster
“An information cluster is a set of [functions] used for every access to data that has a complex structure, sensitive security, or device dependence.” Meilir Page-Jones, The Practical Guide to Structured Systems Design, Yourdon Press, 1988
A major benefit of this organization is that knowledge of specific layout and implementation details is hidden from clients, who have access only through a public interface.
Abstraction: The public interface establishes a component’s logical model by means of the messages it responds to and the syntax and semantics of its public functions.
Modules are information clusters with only one instance.
Class based objects are information clusters with many instances
private data
private functions
public interface functions

16. System Abstraction
A software system’s requirements model is repre-sented, using data flow diagrams, as a network of interconnected public interfaces.
The public interfaces, during design, become popu-lated modules and class based objects.

17. B-Specification Structure

18. C-Level Specifications
Written by the developers. Customer does not have approval rights. The developers are obligated to meet requirements in the A and B specifications. The C specification describes the design, and that is the developer’s business, not the customer’s, although the customer does have access rights to complete information about the design and reviews the C spec.
Describes the design “as built”. The final C Specification delivered to the customer must describe the latest version of the software.
C Specification, also called a Product Specification or Software Design Document (SDD) defines how a software product satisfies its requirements.
C-level specification defines design concept, physical structure, states, control, and low-level interface details of each component.
It translates logical descriptions of the SRS into physical structure, classes, functions and data structures used to implement each software component.

19. C-Level Specification
The C Specification contains:
physical description of the software architecture
One or more activity diagrams and package diagrams or structure charts showing the data and control flow between programs and modules
For each module a physical description and one or more of the following:
package diagram or structure chart for each module showing the data and control flow between functions
class diagrams for each module showing the implementation dependencies between classes
event trace or other object diagrams for each module showing the data and control flow between objects
a state transition diagram or control flow chart showing the control flow within the module
A Manual/Maintenance section in code for each function (in a structured design) and class (in an object oriented design) which describes processing, inputs, outputs and implementation details for that component. These are often call Hierarchical Inputs, Processing, Outputs (HIPO) descriptions.
A data dictionary (DD) describing data flows between components.

20. C-Specification Structure

21. Structure Chart Example COM System

22. Class Diagram Example (a test harness)

23. Activity Diagram Example (CRC Builder)

24. Specification Goals Legally complete Eliminates all ambiguity Brief
Requirements Spec: complete description of what must be done
Product Spec: complete description of how the pro-cessing is accomplished in this product
Eliminates all ambiguity
the definition of what is ambiguous depends on the expertise of the development team and customer
Brief
Eliminate all redundancy and extraneous descriptions
no adjectives or adverbs
Based on architectural components
allows a team to work relatively independently on an assigned component
makes orderly integration and test possible
Contractual description of what the product
will do, how it behaves. Each “shall” is
binding and tested at system test.
A level spec
High level decomposition, description of
processing and data flows. Each “shall”
is binding and tested at qualification test
B level spec
Physical description of each component,
as built. No “shalls”. Eventually contains
the source code listings.
C level spec

25. End of Presentation