CSCI 630 Notes

CSCI 630 - Software Engineering

Architectural Design

represents the structure of the data and program components
begins with data design and proceeds to the architectural structure of the system
the architectural model encompasses both the data architecture and the program structure
enables a software engineer to
- analyze the effectiveness of the design in meeting stated requirements
- consider architectural alternatives
- reduce the risk associated with the construction of the software
the model is subjected to software quality review
Data Design
- data design begins during analysis modeling and continues in design
- data specification principles (most can be met by using an object-oriented approach)
  - systematic analysis principles applied to function and behavior should also be applied to data
  - all data structures and the operations to be performed on each should be identified
  - a data dictionary should be established and used to define both data and program design
  - low level design processes should be deferred until late in the design process
  - representations of data structure should be known only to those modules that must make direct use of the data
  - a library of useful data structures and operations should be developed
  - a software design and its implementation language should support the specification and realization of abstract data types
Architectural Style Elements
Canonical Architectural Structures
- Functional structure
  - components represent function or processing entities
  - connectors are interfaces that allow data access
- Implementation structure
  - components are vehicles for packaging functionality (i.e., packages, classes, objects, functions, methods, etc.)
  - connectors include data sharing, control transfer, associations, etc.
- Concurrency structure
  - components are units of concurrency
  - connectors are execution or communications constraints
- Physical structure
  - components are physical hardware that software is deployed on
  - connectors are the hardware interfaces
- Developmental structure
  - components are work products and required information sources
  - connectors are the relationships among the work products
Architectural Styles
- Data centered - data store (e.g., file or database) lies at the center of this architecture and is accessed frequently by other components that modify data
- Data flow - input data is transformed by a series of computational or manipulative components into output data
- Call and return - program structure decomposes function into control hierarchy with main program invokes several subprograms
- Object-oriented - components of system encapsulate data and operations, communication between components is by message passing
- Layered - several layers are defined, each accomplishing operations that progressively become closer to the machine instruction set
Architectural Design
- software to be developed must be put into context (i.e., model external entities and define interfaces)
- identify architectural archetypes (collection of abstractions that must be modeled if the system is to be constructed)
- specify structure of the system by defining and refining the software components needed to implement each archetype
- continue the process iteratively until a complete architectural structure has been derived
- representing the system in context
  - use the architectural context diagram to model the manner in which the system interacts with external entities
  - systems that interoperate with the target system are represented as
    - superordinate systems - using the target system as part of some higher level processing scheme
    - subordinate systems - used by the target system to provide data or processing needed to complete the target system
    - peer level systems - producing or consuming information needed by peers of the target system
    - actors - people or devices that interact with the system to produce or consume information needed for requisite processing
  - interfaces must be defined
  - all the data that flow into or out of the target system must be identified
- defining archetypes
  - may be defined by examining the analysis classes defined in the analysis model
  - determine the stable elements of the architecture that will need to be implemented when the system is built
- refining architecture into components
  - begins with an examination of the analysis classes for entities from the business domain
  - infrastructure components needed to support the business functions
  - specialized components needed to process data that crosses the interfaces
  - look for archetypes that are reoccur in several components and create new components that service each repeating design pattern
- partitioning the architecture
- structured design
  - establish type of information flow
    - transform flow - overall data flow is sequential and flows along a small number of straight line paths
    - transaction flow - a single data item triggers information flow along one of many paths
  - perform a mapping based on flow type
  - mapping transform flow into a "call and return" architecture
    - SafeHome context-level DFD (level 0)
    - level 1 DFD
    - level 2 DFD for "monitor sensors" transform
    - level 3 DFD with flow boundaries identified
    - first level factoring
    - second level factoring
    - first iteration structure
    - refined program structure for "monitor sensors"
  - mapping transaction flow into a "call and return" architecture
    - start off with the same steps as in transform mapping
    - level 2 DFD with flow boundaries for both flow types - note the transaction center
    - the transaction center becomes a "dispatcher" - note branch with transform flow
    - first level factoring
    - first iteration architecture
See the text for information on Architecture Design Assessment
Architectural Model for SafeHome

Notes and figures from:

Software Engineering: A Practitioner's Approach, 6th Edition, by Roger S Pressman, R.S. Pressman & Associates, McGraw-Hill, 2005