pressman ch-11-component-level-design
TRANSCRIPT
![Page 1: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/1.jpg)
Software Architecture and Specification
Derived from Dr. Fawcett’s slides
Phil Pratt-Szeliga
Fall 2010
![Page 2: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/2.jpg)
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)
![Page 3: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/3.jpg)
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
![Page 4: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/4.jpg)
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
![Page 5: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/5.jpg)
Software Architecture
Life Cycle
- Developed during requirements analysis
- Guides top level design and evolves with design
- Should be fairly static during implementation and testing
![Page 6: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/6.jpg)
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
![Page 7: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/7.jpg)
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
![Page 8: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/8.jpg)
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
![Page 9: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/9.jpg)
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
![Page 10: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/10.jpg)
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
![Page 11: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/11.jpg)
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
![Page 12: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/12.jpg)
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
![Page 13: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/13.jpg)
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
![Page 14: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/14.jpg)
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)
![Page 15: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/15.jpg)
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
![Page 16: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/16.jpg)
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
![Page 17: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/17.jpg)
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
![Page 18: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/18.jpg)
A-Level Requirements Specification Example
Duplicates A-SpecOn website – lecture 1
![Page 19: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/19.jpg)
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
![Page 20: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/20.jpg)
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)
![Page 21: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/21.jpg)
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
![Page 22: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/22.jpg)
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
![Page 23: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/23.jpg)
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
![Page 24: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/24.jpg)
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
![Page 25: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/25.jpg)
B-Level Specification Example
Duplicates B-SpecOn website, lecture 1
![Page 26: Pressman ch-11-component-level-design](https://reader035.vdocuments.us/reader035/viewer/2022081504/5586db0ad8b42a5c718b469d/html5/thumbnails/26.jpg)
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