1. Software Engineering Fall 2005
Lecture 8 Architectural Design Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman
Software Engineering
Fall 2005

2. Overview
Architectural design represents the structure of the data and program components required to build a computer-based system.
A number of architectural "styles" exist.
Architectural design begins with data design and proceeds to the derivation of one or more representations of the architectural structure of the system. The resulting architectural model encompasses both the data architecture and the program structure.
The architectural model is subjected to software quality review like all other design work products.

3. Architectural Design
Represents the structure of data and program components that are required to build a computer-based system.
It considers the architectural style that the system will take, the structure and properties of the components that constitute the system, and the interrelationships that occur among all architectural components of a system.

4. Who Does It?
The job is often allocated to specialists when large, complex systems are built. Otherwise, a software engineer can design both data and architecture.
The ‘system architect’ selects an appropriate architectural style for the requirements derived during system engineering and software requirements analysis.

5. What are the steps?
Architectural design begins with data design and then proceeds to the derivation of one or more representations of the architectural structure of the system.
Alternative architectural styles or patterns are analysed to derive structure that is best suited to customer requirements and quality attributes.
Once an alternative has been selected, the architecture is elaborated using an architectural design method.

6. What is the work product
An architecture model encompassing data architecture and program structure is created during architectural design.
In addition, component properties and relationships (interactions) are described.

7. 1. Software Architecture?
The architecture is not the operational software. Rather, it is a representation that enables a software engineer to:
(1) analyze the effectiveness of the design in meeting its stated requirements,
(2) consider architectural alternatives at a stage when making design changes is still relatively easy, and
(3) reduce the risks associated with the construction of the software.

8. Importance of Architecture
Architecture highlights early design decisions that will have a profound impact on the ultimate success of the system as an operational entity
The architecture itself constitutes an intellectually manageable model of how the system is structured and how its components work together

9. Software Architecture
The design of software architecture considers two levels of the design pyramid:
- Data design
- Architectural design
Data design enables us to represent the data component of the architecture in conventional systems and class definitions in object-oriented systems.
Architectural design focuses on the representation of the structure of software components, their properties and interactions.

10. 2. Data Design
Translates data objects defined as part of the analysis model into data structures at the software component level and, when necessary, a database architecture at the application level
Existing databases can be used or a database is designed and built specifically for a new system.

11. 2.1. Data Design at the Architectural Level
Design of one or more databases to support the application architecture
Design of methods for ‘mining’ (also called knowledge discovery in databases (KDD) ) the content of multiple databases
navigate through existing databases in an attempt to extract appropriate business-level information
design of a data warehouse - a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business

12. Data Warehouse
A data warehouse is a separate data environment that is not directly integrated with day-to-day applications, but encompasses all data used by a business.
It is a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business.

13. Data Warehouse Challenges for Data Architects
Subject orientation - data warehouse organized by business subjects rather than business processes or functions
Integration - data in the warehouse must exhibit consistent naming conventions, encoding structures, and physical attributes even when inconsistencies exist among application-oriented databases
Time variancy - unlike transaction-oriented databases where data may only be accurate for short time periods, the time horizon for a data warehouse may be several years
Nonvolatility - data remains in the data warehouse once added and old data may only be purged every few years, if at all

14. Data Mining/Warehousing Software Tools
They assist in the identification of significant relationships among attributes that describe a specific data object or set of data objects.
Mining tools accept large data sets as input and allow the user to query the data in an effort to better understand relationships among various data items.
Warehousing tools that are used for design provide entity relationship or other modeling capabilities.

15. 2.2. Data Design at the Component Level
Focus is on the representation of data structures that are directly accessed by one or more software components.
In reality, the design of data begins during the creation of the analysis model.
Steps:
refine data objects and develop a set of data abstractions
implement data object attributes as one or more data structures
review data structures to ensure that appropriate relationships have been established
simplify data structures as required

16. Data Specification Principles I
1. Systematic analysis principles applied to function and behavior should also be applied to data - Representation of data flow and content should also developed and reviewed, data objects should be identified, alternative data organisations should be considered, and the impact of data modeling on software design should be evaluated.
2. All data structures and the operations to be performed on each should be identified. – The design of an efficient data structure must take the operations to be performed on the data structure into account (encapsulation)

17. Data Specification Principles II
3. Data dictionary should be established and used to define both data and program design. – Class diagrams define the data items (attributes) contained within a class and the processing (operations) that are applied to these data items.
4. Low level design processes should be deferred until late in the design process. – Overall data organisation may be defined during requirements analysis, refined during data design work, and specified in detail during component-level design.

18. Data Specification Principles III
5. Representations of data structure should be known only to those modules that must make direct use of the data contained within in the data structure. – Information hiding and coupling provide insight into the quality of a software design.
6. A library of useful data structures and operations should be developed. – A class library achieves this.
7. A software design and its implementation language should support the specification and realization of abstract data types.

19. 3. Architectural Styles and Patterns
An architectural style is a transformation that is imposed on the design of an entire system. The intent is to establish a structure for all components of the system.
An architectural pattern, like an architectural style, imposes a transformation on the design of an architecture.

20. Comparing Architectural Styles and Patterns
Both impose transformations on the design of an entire system
Scope of architectural pattern is less broad
Patterns impose rules on the architecture describing how the software will deliver some aspect of its functionality at the infrastructure level

21. 3.1. Architectural Style Elements
Set of components – that perform a function required by a system (e.g. database, computational modules)
Set of connections - that enable communication, coordination, and cooperation among components
Constraints - defining how components can be integrated to form the system
Semantic models - that enable designers to understand the overall system properties by analyzing properties of its constituent parts

22. 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

23. Data-centered Architecture
A data store (e.g. a file or database) resides at the centre of this architecture and is accessed frequently by other components that update, add, delete or otherwise modify data within the store.
Promotes integrability – existing components can be changed and new client components added to the architecture without concern about other clients (clients operate independently). Also, data can be passed among clients using the blackboard mechanism (i.e.. The blackboard component serves to coordinate the transfer of information between clients).

24. Data-centered Architecture
Next figure:
Client software accesses a central repository. In some cases the data repository is passive. That is, client software accesses the data independent on any changes to the data or the actions of other client software.
A variation of this approach transforms the repository into a ‘blackboard’ that sends notifications to client software when data of interest to the client changes.

25. Data-Centered Architecture

26. Data-flow architecture
This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data.
A pipe and filter structure has a set of components, called filters, connected by pipes that transmits data from one component to the next.
Each filter works independently of those components upstream and downstream; is designed to expect data input of a certain form; and produces data output (to the next filter) of a specified form.
The filter does not require knowledge of the workings of its neighbouring filters.
Batch sequential - if the data flow degenerate into a single line of transform. This structure accepts a batch of data and then applies a series of sequential components (filters) to transform it.

27. Data Flow Architecture

28. Call and Return Architecture
It enables a software designer to achieve a program structure that is relatively easy to modify and scale
Two substyles:
Main program/subprogram architecture – decomposes function into a control hierarchy where a ‘main’ program invokes a number of program components, which in turn may invoke still other components.
Remote procedure call architecture – the components of main program/subprogram architecture are distributed across multiple computers on a network.

29. Call and Return Architecture

30. Object-oriented architecture
The components of a system encapsulate data and the operations that must be applied to manipulate the data
Communication and coordination between components is accomplished by message passing

31. Layered Architecture
A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.
At the outer layer, components service user interface operations.
At the inner layer, components perform operating system interfacing.
Intermediate layers provide utility services and application software functions.

32. Layered Architecture

33. Choosing an Architectural Style
More than one style might be appropriate
Alternatives might be designed and evaluated
For example, a layered style (appropriate for most systems) can be combined with a data-centred architecture in many database applications.

34. 3.2. Architectural Patterns
Architectural patterns for software define a specific approach for handling some behavioral characteristic of the system.
A software architecture may have a number of architectural patterns that address issues such as concurrency, persistence, and distribution.

35. Concurrency
Many applications must handle multiple tasks in a manner that simulates parallelism
The way in which an application can handle concurrency can be presented by a different architectural pattern:
operating system process management pattern – that provides built-in OS features that allow components to execute concurrently. Also incorporates OS functionality that manages communication between processes, scheduling and other capabilities required to achieve concurrency.
task scheduler pattern – contains a set of active objects that each contain a tick() operation. The scheduler periodically invokes tick() for each object, which then performs the functions it must perform before returning control back to the scheduler, which then invokes the tick() operation for the next concurrent object.

36. Persistence
Data persists if it survives past the execution of the process that created it.
Persistent data are stored in a database or file and may be read or modified by other processes at a later time.
Two patterns are common:
a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture
an application level persistence pattern that builds persistence features into the application architecture

37. Distribution
The distribution problem addresses the manner in which systems or components within systems communicate with one another in a distributed environment
Two elements to this problem:
- the way in which entities connect to one another;
- the nature of the communication that occurs
A broker acts as a ‘middle-man’ between the client component and a server component. The client sends a message to the broker, and the broker completes the connection. CORBA is an example of a broker architecture.

38. 4. 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

39. 4.1. Representing the System in Context
Use the architectural context diagram (ACD) to model the manner in which the system interacts with external entities

40. Representing the System in Context
Systems that interoperate with the target system (the system for which an architectural design is to be developed) 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

41. ACD for the SafeHome Security Function
Figure on the next slide:
The SafeHome product controller and the Internet-based system – superordinate to the security function
The surveillance function - peer system
The homeowner and control panels – actors
Sensors, used by the security software – subordinate system

42. Architectural Context

43. Architectural Context Diagram
As part of architectural design:
- Interfaces must be defined
- All the data that flow into or out of the target system must be identified

44. 4.2. Defining Archetypes
An archetype is a class or pattern that represents a core abstraction that is critical to the design of an architecture for the target system.
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

45. Archetypes SafeHome security function archetypes:
Node – a cohesive collection of input and output elements (E.g. various sensors, alarm (output) indicators)
Detector – an abstraction that encompasses all sensing equipment that feeds information into the target system.
Indicator – all mechanisms (e.g. alarm siren, flashing lights, bell) for indicating that an alarm condition is occurring
Controller – the mechanism that allows the arming or disarming of a node. If they reside on a network, they have the ability to communicate with one another.

46. Archetypes

47. 4.3. Refining Architecture into Components
Process begins with an examination of the analysis classes for entities from the business domain that must be addressed in the software architecture. Hence, the application domain is one source for the derivation and refinement of components.
Another source is the infrastructure domain. – The architecture must accommodate many infrastructure components that enable application components, but have no business connection to the application domain. (E.g. – memory management components, communication components, database components and task management components)
The interfaces depicted in the architecture context diagram may imply 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

48. Refining Architecture into Components
SafeHome...We might define the set of top-level components that address the following functionality:
External communication management – coordinates communication of the security function with external entities
Control panel processing – manages all control panel functionality
Detector management – coordinates access to all detectors attached to the system
Alarm processing – verifies and acts on all alarm conditions

49. Refining Architecture into Components
Each of the top-level components would have to be elaborated iteratively and then positioned within the overall architecture.
Design classes would be defined for each
The design details of all attributes and operations would not be specified until component-level design.

50. Component Structure
Transactions are acquired by External communication management as they move in from components that process the SafeHome GUI and the Internet interface. This information is managed by a SafeHome executive component that selects the appropriate product function .
The control panel processing component interacts with the homeowner to arm/disarm the security function.
The detector management component polls sensors to detect an alarm condition
The alarm processing component produces output when an alarm is detected.

51. 4.4.Instantiation of the System
Instantiation of the system – the architecture is applied to a specific problem with the intent of demonstrating that the structure of components is appropriate.
Components of the SafeHome architecture for the security system are further refined to show additional details (the figure on the next slide). For example: The detector management component interact with a scheduler infrastructure component that implements ‘concurrent’ polling of each sensor object used by the security system. F

52. Refined Component Structure

53. Software Tools
Architectural design tools model the overall software structure by representing component interfaces, dependencies and relationships and interactions
Adalon ( – web-based component architecture
ObjectIF ( – UML-based design tool
Rational Rose ( – UML-based design tool

54. 5. Assessing Alternative Architectural Design
Ideally, design results in a number of architectural alternatives that are each assessed to determine which is the most appropriate for the problem to be solved.

55. 5.1. Architecture Trade-off Analysis Method I
Architecture trade-off analysis method (ATAM) - establishes an
iterative evaluation process for software architecture:
1. Collect scenarios
2. Elicit requirements, constraints, and environmental description - to be sure that all stakeholder concerns have been addressed.
3. Describe architectural styles/patterns chosen to address scenarios and requirements (module view, process view, data flow view)
4. Evaluate quality attributes independently - reliability, performance, security, maintainability, flexibility, testability, portability, reusability and interoperability.

56. Architecture Trade-off Analysis Method II
5. Identify sensitivity points for architecture (any attributes significantly affected by variation – small changes - in the architecture)
6. Critique candidate architectures (from step 3) using the sensitivity analysis (conducted in step 5)
After finding sensitivity points – identify architectural elements to which multiple attributes are sensitive. For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases). The number of servers, then , is the trade-off point with respect to this architecture.
Based on the results of steps 5 and 6:
- some architecture alternatives may be eliminated,
- one or more of the remaining architectures may be modified and represented in more detail,
- and, then the ATAM steps are reapplied.

57. 5.2. Architectural Complexity
Similar to coupling
Three types of dependencies between components:
- Sharing dependencies - represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers
- Flow dependencies - represent dependence relationships between producers and consumers of resources
- Constrained dependencies - represent constraints on the relative flow among a set of components

58. 5.3. Architectural Description Language (ADL)
Provides syntax and semantics for describing software architecture
Provides designers with ability to decompose components, combine components, and define interfaces

59. Architectural Description Languages
Rapide (poset.standford.edu/rapide) – builds on the notion of partial ordered sets.
UniCon ( – defines software architecture in terms of abstractions that designers find useful.
UML ( – includes many of the artifacts needed for architectural descriptions, but is not as complete as other ADLs.

60. 6. Mapping Data Flow into a Software Architecture
To illustrate one approach to architectural mapping, a mapping technique for the call and return is discussed.
This mapping technique – structured design – enables a designer to derive fairly complex call and return architectures from data flow diagrams.
Structured design is often characterised as a data-flow oriented design method because it provides a convenient transition from a data flow diagram to software architecture.

61. Structured Design
Objective: to derive a program architecture that is partitioned
Approach:
the DFD is mapped into a program architecture
the PSPEC and STD are used to indicate the content of each module
Notation: structure chart

62. Mapping Requirements to Software Architecture in Structured Design
Establish type of information flow (transform or transaction)
Flow boundaries indicated
DFD is mapped into program structure
Control hierarchy defined
Resultant structure refined using design measures and heuristics
Architectural description refined and elaborated

63. General Mapping Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center
working from the boundary outward, map
DFD transforms into corresponding modules
add control modules as required
refine the resultant program structure
using effective modularity concepts

64. Transform Flow
Information must enter and exit software in an ‘external world’ form
Information enters the system along paths (incoming flow ) that transforms external data into an internal form.
At the kernel of the software, a transition occurs. Incoming data are passed through a transform centre and begin to move along paths that now lead ‘out’ out of the software. Data moving along these paths are called outgoing flow.
Overall data flow is sequential and flows along one or a small number of straight line paths

65. Transaction Flow
A single data item - transaction - triggers information flow along one of many paths
Characterised by data moving along an incoming path that converts external world information into a transaction.
The transaction is evaluated and, based on its value, flow along one of many action paths is initiated.
The hub of information flow from which many action paths emanate is called a transaction centre.

66. Transaction Flow
incoming flow
action path T

67. Flow Characteristics
Both transform and transaction flows may occur in the same DFD (Data Flow Diagram).
Each subflow should be classified and mapped using the appropriate technique (transform or transaction).
The difference between transform flow and transaction flow:
Transform flow is largely sequential and has very little divergence along the action path. Transaction flow can follow many action paths and the processing of a single data item often triggers path selection.

68. Flow Characteristics
Transform flow
Transaction
flow

69. Transform Mapping Steps I
Transform Mapping - set of design steps that allows a DFD with
transform flow characteristics to be mapped into a specific architectural
style.
1. Review fundamental system model - Level 0 model
2. Review and refine data flow diagrams for the software - Information obtained from the analysis model is refined to produce greater detail.
3. Determine whether the DFD has transform or transaction characteristics - In general, information flow within a system can always be represented as transform. When an obvious transaction characteristic is encountered, a different design mapping is recommended. In this step, the designer selects global flow characteristics based on the prevailing nature of the DFD. In addition, local regions of transform or transaction flow are isolated. These subflows can be used to refine program architecture derived from a global characteristic described previously.
4. Isolate the transform center by specifying incoming and outgoing flow boundaries. – Different designers may select slightly different points in the flow as boundary locations. In fact, alternative design solutions can be derived by varying the placement of flow boundaries, but a variance of one bubble along a flow path will generally have little impact on the final program structure.

70. Transform Mapping "Transform" mapping data flow model a b c d e f g hj x1 x2 x3 x4

71. Transform Mapping Steps II
5. Perform ‘first-level factoring’ – The program architecture derived using this mapping results in a top-down distribution of control.
Factoring results in a program structure in which top-level components perform decision-making, low-level components perform most input, computation and output work, middle-level components perform some control and do moderate amounts of work.
When transform flow is encountered, a DFD is mapped to a specific structure (a call and return architecture) that provides control for incoming, transform, and outgoing information processing.

72. Factoring

73. First Level Factoring main program controller output input processing

74. Transform Mapping Steps III
6. Perform ‘second-level factoring’ - Second level factoring is accomplished by mapping individual transforms (bubbles) of a DFD into appropriate modules within the architecture. Beginning at the transform centre boundary and moving outward along incoming and then outgoing paths, transforms are mapped into subordinate levels of the software structure.
Two or even three bubbles can be combined and represented as one component, or a single bubble may be expanded to two or more components.
Second-level factoring for incoming flow is also accomplished by moving outward from the transform centre boundary on the incoming flow side.
A brief processing narrative (adapted from the PSPEC created during analysis modeling) should be written for each mapped component.

75. Second Level Mapping

76. Transform Mapping Steps IV
7. Refine the first iteration architecture using design heuristics for improved software quality – A first-iteration architecture can always be refined by applying concepts of functional independence.
Components are exploded or imploded to produce sensible factoring, good cohesion, minimal coupling, and a structure that can be implemented without difficulty, tested without confusion and maintained without grief.
Software requirements coupled with human judgement is a final arbiter for refinements.

77. Transform vs Transaction Mapping
Transaction mapping – design steps used to map transaction flow into a software architecture.
The process of performing transaction mapping is similar to transform mapping, but focusing on transaction (not transform) centers. A major difference lies in the mapping of DFD to software structure.
In transaction mapping, the first level factoring results in the derivation of the control hierarchy. The second level factoring distributes the low-level modules among the appropriate controller.

78. Transaction Mapping Steps I
1. Review fundamental system model
2. Review and refine data flow diagrams for the software
3. Determine whether the DFD has transform or transaction characteristics
4. Identify the transaction center and flow characteristics along each action path – The location of the transaction centre can be immediately discerned from the DFD. The transaction centre lies at the origin of a number of action paths that flow radially from it. The incoming path (i.e. the flow path along which a transaction is received) and all action paths must also be isolated. Each action path must be evaluated for its individual characteristic.

79. Transaction Mapping

80. Transaction Mapping Steps II
5. Map the DFD to a program structure amenable to transaction processing – Transaction flow is mapped into an architecture that contains an incoming branch and a dispatch branch. The structure of the incoming branch is developed in the same way as transform mapping. Starting at the transaction centre, bubbles along the incoming path are mapped into modules. The structure of the dispatch branch contains a dispatcher module that controls all subordinate action modules.
Each action flow path of the DFD is mapped to a structure that corresponds to its specific flow characteristics.

81. Transaction Mapping Steps III
6. Factor and refine the transaction structure and the structure of each action path
7. Refine the first iteration architecture using design heuristics for improved software quality

82. Refining Architectural Design
Processing narrative developed for each module
Interface description provided for each module
Local and global data structures are defined
Design restrictions/limitations noted
Design reviews conducted
Refinement considered if required and justified

83. Summary I
Software architecture provides a holistic view of the system to be built. It depicts the structure and organisation of software components, their properties and the connections between them.
Software components include program modules and the various data representations that are manipulated by the program

84. Summary II
Architectural design is generally accomplished using four distinct steps:
1. The system must be represented in context – i.e. the designer should define external entities that the software interacts with, and the nature of the interaction.
2. Once context has been specified, the designer should identify a set of top-level abstractions, called archetypes, that represent pivotal elements of the system’s behavior or function.
3. After abstractions have been defined, the design begins to move closer to the implementation domain. Components are identified and represented within the context of an architecture that supports them.
4. Finally, specific instantiations of the architecture are developed to ‘prove’ the design in ‘real’ world context.

85. 2005F Instructor John D Lin - johndlin@hotlinemail.com Lectures
Tues & Thurs 10:00-11:30 RM. 100, Lower Block