CIS 518 Case Study 1

Chapter 5

Designing

the Architecture

Shari L. Pfleeger

Joanne M. Atlee

4th Edition

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

Contents

5.1 The Design Process

5.2 Modeling Architectures

5.3 Decomposition and Views

5.4 Architectural Styles and Strategies

5.5 Achieving Quality Attributes

5.6 Collaborative Design

5.7 Architecture Evaluation and Refinement

5.8 Documenting Software Architectures

5.9 Architecture Design Review

5.10 Software Product Lines

5.11 Information System Example

5.12 Real-Time Example

5.13 What this Chapter Means for you

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

Chapter 5 Objectives

• Examine different types of decomposition
• Compare competing designs
• Document the design
• Verify architecture meets the requirements

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.1 The Design Process

• Design is the creative process of figuring out how to implement all of the customer’s requirements; the resulting plan is also called the design
• Early design decisions address the system’s architecture
• Later design decisions address how to implement the individual units

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.1 The Design Process
Design is a Creative Process

• Design is an intellectually challenging task
• Numerous possibilities the system must accommodate
• Nonfunctional design goals (e.g., ease of use, ease to maintain)
• External factors (e.g., standard data formats, government regulations)
• We can improve our design by studying examples of good design
• Most design work is routine design, solve problem by reusing and adapting solutions from similar problems

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.1 The Design Process
Design is a Creative Process (continued)

• Many ways to leverage existing solutions
• Cloning: Borrow design/code in its entirety, with minor adjustments
• Reference models: Generic architecture that suggests how to decompose the system

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.1 The Design Process
Design is a Creative Process (continued)

• Reference model for a compiler

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.1 The Design Process
Design is a Creative Process (continued)

• More typically, a reference model will not exist for the problem
• Software architectures have generic solutions too, referred to as architectural styles
• Focusing on one architectural style can create problems
• Good design is about selecting, adapting, and integrating several architectural design styles to produce the desired result

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.1 The Design Process
Design is a Creative Process (continued)

• Many tools for understanding options and evaluating chosen architecture, including:
• Design patterns: generic solutions for making lower-level design decisions
• Design convention or idiom: collection of design decisions and advice that, taken together, promotes certain design qualities
• Design principles: descriptive characteristics of good design

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.1 The Design Process
Design Process Model

• Designing software system is an iterative process
• The final outcome is the software architecture document (SAD)

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.2 Modeling Architectures

• Collection of models helps to answer whether the proposed architecture meets the specified requirements
• Six ways to use the architectural models:
• to understand the system
• to determine amount of reuse from other systems and the reusability of the system being designed
• to provide blueprint for system construction
• to reason about system evolution
• to analyze dependencies
• to support management decisions and understand risks

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views

• High-level description of system’s key elements
• Creating a hierarchy of information with increasing details

Top

level

First level of

decomposition

Second level of

decomposition

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Popular Design Methods

• Some design problems have no existing solutions
• Designers must decompose to isolate key problems
• Some popular design methods:
• Functional decomposition
• Feature-oriented decomposition
• Object-oriented design

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Popular Design Methods

• Functional decomposition
• partitions functions or requirements into modules
• begins with the functions that are listed in the requirements specification
• lower-level designs divide these functions into subfunctions, which are then assigned to smaller modules
• describes which modules (subfunctions) call each other

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Popular Design Methods

Feature-oriented decomposition

• assigns features to modules
• high-level design describes the system in terms of a service and a collection of features
• lower-level designs describe how each feature augments the service and identifies interactions among features

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Popular Design Methods

Object-oriented decomposition

• assigns objects to modules
• high-level design identifies the system’s object types and explains how objects are related to one another
• lower-level designs detail the objects’ attributes and operations

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Popular Design Methods (continued)

• A design is modular when each activity of the system is performed by exactly one software unit, and when the inputs and outputs of each software unit are well-defined
• A software unit is well-defined if its interface accurately and precisely specifies the unit’s externally visible behavior

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Architectural Views

• Common types of architectural views include:
• Dependencies view
• Generalization view
• Work-assignment view

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Dependencies View

• The dependencies view shows dependencies among software units
• This view is useful in project planning
• Also useful for assessing the impact of making a design change to some software unit

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Generalization View

• The generalization view shows software units that are generalizations or specializations of one another
• This view is useful when designing abstract or extendible software units

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.3 Decomposition and Views
Work-assignment View

• The work-assignment view decomposes the system’s design into work tasks that can be assigned to project teams
• Helps project managers plan and allocate project resources, as well as track each team’s progress

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies

• Pipes-and-Filter
• Client-Server
• Peer-to-Peer
• Publish-Subscribe
• Repositories

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies
Pipes-and-Filter

• The system has
• Streams of data (pipe) for input and output
• Transformation of the data (filter)
• The designer can understand the entire system's effect on input and output as the composition of the filters
• The filters can be reused easily on other systems
• System evolution is simple
• Encourages batch processing
• Not good for handling interactive application

KEY

pipe

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies
Client-Server

• Two types of components:
• Server components offer services
• Clients access them using a request/reply protocol
• Client may send the server an executable function, called a callback
• The server subsequently calls under specific circumstances

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies
Peer-to-Peer (P2P)

• Each component acts as its own process and acts as both a client and a server to other peer components.
• Any component can initiate a request to any other peer component.
• Characteristics
• Scale up well
• Increased system capabilities
• Highly tolerant of failures
• Examples: Napster and Freenet

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies
Publish-Subscribe

• Components interact by broadcasting and reacting to events
• Component expresses interest in an event by subscribing to it
• When another component announces (publishes) that event has taken place, subscribing components are notified
• Implicit invocation is a common form of publish-subscribe architecture
• Registering: subscribing component associates one of its procedures with each event of interest (called the procedure)
• Characteristics
• Strong support for evolution and customization
• Easy to reuse components in other event-driven systems
• Need shared repository for components to share persistent data
• Difficult to test

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies
Repositories

• Two components
• A central data store
• A collection of components that operate on it to store, retrieve, and update information
• The challenge is deciding how the components will interact
• A traditional database: transactions trigger process execution
• A blackboard: the central store controls the triggering process
• Knowledge sources: information about the current state of the system’s execution that triggers the execution of individual data accessors

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies
Repositories (continued)

• Major advantage: openness
• Data representation is made available to various programmers (vendors) so they can build tools to access the repository
• But also a disadvantage: the data format must be acceptable to all components

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies
Combining Architectural Styles

• Actual software architectures rarely based on purely one style
• Architectural styles can be combined in several ways
• Use different styles at different layers (e.g., overall client-server architecture with server component decomposed into layers)
• Use mixture of styles to model different components or types of interaction (e.g., client components interact with one another using publish-subscribe communications
• If architecture is expressed as collection of models, documentation must be created to show relation between models

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.4 Architectural Styles and Strategies
Combination of Publish-Subscribe, Client-Server, and Repository Architecture Styles

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes

• Architectural styles provide general beneficial properties. To support specific quality attribute tactics are utilized:
• Modifiability
• Performance
• Security
• Reliability
• Robustness
• Usability
• Business goals

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Modifiability

• Design must be easy to change
• Two classifications of affected software units:
• Directly affected
• Indirectly affected
• Directly affected units’ responsibilities change to accommodate a system modification
• Indirectly affected units’ responsibilities do not change, but implementations must be revised

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Modifiability (continued)

• Tactics for minimizing the number of software units affected by a change focus on clustering the anticipated changes:
• Anticipate expected changes: Identify design decisions that are most likely to change, and encapsulate each in its own software unit
• Cohesion: Keeping software units highly cohesive increases the chances that a change to the system’s responsibilities is confined to the few units that are assigned those responsibilities
• Generality : The more general the software units, the more likely change can be accommodated by modifying a unit’s inputs rather than modifying the unit itself

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Modifiability (continued)

• Tactics for minimizing the impact on indirectly affected units focus on reducing dependencies
• Coupling: Lowering coupling reduces the likelihood that a change to one unit will ripple to other units
• Interfaces: If a unit interacts with other units only through their interfaces changes to one unit will not spread beyond the unit’s boundary unless its interface changes
• Multiple interfaces: A unit modified to provide new data or services can offer them using a new interface to the unit without changing any of the unit’s existing interfaces

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Performance

• Performance attributes describe constraints on system speed and capacity:
• Response time: How fast does our software respond to requests?
• Throughput: How many requests can it process per minute?
• Load: How many users can it support before response time and throughput start to suffer?

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Performance

• Tactics for improving performance include:
• Improve utilization of resources
• Manage resource allocation more effectively
• First-come/first-served: Requests are processed in the order in which they are received
• Explicit priority: Requests are processed in order of their assigned priorities
• Earliest deadline first: Requests are processed in order of their impending deadlines
• Reduce demand for resources

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Security

• Two key architectural characteristics particularly relevant to security: immunity and resilience
• Immunity: ability to thwart an attempted attack
• The architecture encourages immunity by:
• Ensuring all security features are included in the design
• Minimizing exploitable security weaknesses
• Resilience: ability to recover quickly and easily from an attack
• The architecture encourages resilience by:
• Segmenting functionality to contain attack
• Enabling the system to quickly restore functionality

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Reliability

• A software system is reliable if it correctly performs its required functions under assumed conditions
• Is the software internally free of errors?
• A fault is the result of human error, compared to a failure, which is an observable departure from required behavior
• Software is made more reliable by preventing or tolerating faults

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Robustness

• A system is robust if it includes mechanisms for accommodating or recovering from problems in the environment or in other unit
• Mutual suspicion: each software unit assumes that the other units contain faults
• Robustness tactics differ from reliability tactics
• Recovery tactics are similar:
• Rollback to checkpoint state
• Abort a transaction
• Initiate a backup unit
• Provide reduced service
• Correct symptoms and continue processing
• Trigger an exception

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Usability

• Usability reflects the ease in which a user is able to operate the system
• User interface should reside in its own software unit
• Some user-initiated commands require architectural support
• There are some system-initiated activities for which the system should maintain a model of its environment

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.5 Achieving Quality Attributes
Business Goals

• Business Goals are quality attributes the system is expected to exhibit (e.g., minimizing the cost of development and time to market)
• Buy vs. Build
• Save development time, money
• More reliable
• Existing components create constraints; vulnerable to supplier
• Initial development vs. maintenance costs
• Save money by making system modifiable
• Increased complexity may delay release; lose market to competitors
• New vs. known technologies
• Acquiring expertise costs money, delays product release
• Either learn how to use the new technology or hire new personnel
• Eventually, we must develop the expertise ourselves

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.7 Architecture Evaluation and Refinement

• Design is iterative: we propose design decisions, assess, make adjustments, and propose more decisions
• Many techniques to evaluate the design:
• Measuring design quality
• Safety analysis
• Security analysis
• Trade-off analysis
• Cost-benefit analysis
• Prototyping

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.7 Architecture Evaluation and Refinement
Safety Analysis

• Several techniques during design to identify possible faults
• Fault-tree analysis traces backwards through a design
• Trees then used to determine which faults to correct/avoid/tolerate
• Data-flow graph: depicts the transfer of data from one process to another
• Control-flow graph: depicts possible transfer of control among software units

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.7 Architecture Evaluation and Refinement
Safety Analysis (continued)

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.7 Architecture Evaluation and Refinement
Safety Analysis (continued)

• Once fault tree is constructed we search for weaknesses
• Cut-set tree reveals event combinations can cause failure
• Rules for forming cut-set tree:
• Assign the top node of the cut-set tree to match the logic gate at the top of the fault tree.
• Working from the top down, expand the cut-set tree as follows:
• Expand an or-gate node to have two children, one for each or-gate child
• Expand an and-gate node to have a child composition node listing both of the and-gate children
• Expand a composition node by propagating the node to its children, but expanding one of the gates listed in the node
• Continue until all leaf nodes are basic events or composition nodes of basic events

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.7 Architecture Evaluation and Refinement
Safety Analysis (continued)

• Once fault is found in design:
• Correct the fault
• Add components or conditions to prevent
• Add components that detect fault and recover from damage

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.7 Architecture Evaluation and Refinement
Trade-off Analysis

• Often several alternative designs to consider
• professional duty to explore design alternatives and not simply implement the first design that comes to mind
• different members of design team may promote competing designs
• need a measurement-based method for comparing design alternatives

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.7 Architecture Evaluation and Refinement
Cost-Benefit Analysis

• A cost–benefit analysis is a widely used business tool for estimating and comparing the costs and benefits of a proposed change

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.7 Architecture Evaluation and Refinement
Cost-Benefit Analysis and Computing Benefits

• A cost–benefit analysis is a widely used business tool for estimating and comparing the costs and benefits of a proposed change
• A cost-benefit analysis contrasts financial benefits with financial costs
• Costs are one time capital expense
• Benefits accrue overtime
• Return on Investment (ROI)
• ROI = Benefits/Cost
• Payback period
• the length of time before accumulative benefits recover the costs of implementation

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.8 Documenting Software Architectures

• System's architecture is vital to overall development and serves as the basis on decisions for:
• Design
• Quality assurance
• Project management
• The SAD serves as the repository for design information and includes:
• System overview
• Views
• Software units
• Analysis data and results
• Design rationale
• Definitions, glossary, acronyms

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.9 Architecture Design Review

• Design review is an essential part of engineering practice
• SAD quality is evaluated in two ways:
• Validation: making sure the design satisfies all of the customer’s requirements (i.e., is this the right system?)
• Verification: ensuring the design adheres to good design principles (i.e., are we building the system right?)

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.9 Architecture Design Review
Validation

• Several key people included in review:
• The analyst(s) who helped define the system requirements
• The system architect(s)
• The program designer(s) for this project
• A system tester
• A system maintainer
• A moderator
• A recorder
• Other interested developers not otherwise involved in this project

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.9 Architecture Design Review
Verification

• Judge whether it adheres to good design principles:
• Is the architecture modular, well structured, and easy to understand?
• Can we improve the structure and understandability of the architecture?
• Is the architecture portable to other platforms?
• Are aspects of the architecture reusable?
• Does the architecture support ease of testing?
• Does the architecture maximize performance, where appropriate?
• Does the architecture incorporate appropriate techniques for handling faults and preventing failures?
• Can the architecture accommodate all of the expected design changes and extensions that have been documented?

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.9 Architecture Design Review
Verification (continued)

• Active design review: exercise the design document by using is in ways the developers will use the final document in practice
• Passive review process: reading the documentation and looking for problems

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.10 Software Product Lines

• Organizations can find success by reusing their expertise and software assets across families of related products
• The corporate strategy for designing and developing the related products is based on the reuse of elements of a common product line
• A distinguishing feature of building a product line is the treatment of the derived products as a product family; their simultaneous development is planned from the beginning
• The family’s commonalities are described as a collection of reusable assets (including requirements, designs, code, and test cases), all stored in a core asset base

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.10 Software Product Lines
Core Asset Base

• Candidate elements in a core asset base:
• Requirements
• Software architecture
• Models and analysis results
• Software units
• Testing
• Project planning
• Team organization

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.10 Software Product Lines
Strategic Scoping

• Product lines are based not just on commonalities among products but also on the best way to exploit them
• First, employ strategic business planning to identify the family of products we want to build, using knowledge and good judgment to forecast market trends and predict the demand for various products
• Second, scope the plans, so that the focus is on products that have enough in common to warrant a product-line approach to development. That is, the cost of developing the (common) product line must be more than offset by the savings we expect to accrue from deriving family members from the product line

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.10 Software Product Lines
Sidebar 5.8 Product-line Productivity

• CelsiusTech AB, a Swedish naval defense contractor, motivated by desperation, transitioned from custom to product-line development. In 1985, the company, then Philips Elektronikindustier AB, was awarded two major contracts simultaneously, one for the Swedish Navy and one for the Danish Navy.
• senior managers questioned whether they would be able to meet the demands of both contracts, particularly the promised (and fixed) schedules and budgets, using the company’s current practices and technologies.
• Development of the product line and the first system were initiated at the same time; development of the second system started six months later. The two systems plus the product line were completed using roughly the same amount of time and staff that was needed previously for a single product. Subsequent products had shorter development timelines. On average, 70–80 percent of the seven systems’ software units were product-line units (re)used as is.

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.10 Software Product Lines
Advantages of Product-Line Architecture

• A product lines promotes planned modifiability
• Examples of product-line variability:
• Component replacements
• Component specializations
• Product-line parameters
• Architecture extensions and retractions

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.10 Software Product Lines
Product-Line Evolution

• Key contributor to product-line success is having a product-line mindset
• Company’s primary focus is development and evolution of product-line assets as opposed to individual products
• Changes made to improve capability to derive products
• Backwards capability

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.11 Information System Example
Piccadilly System

• What might be a suitable architecture for the Piccadilly systems?
• Key components
• A repository of information
• Address multiple heterogeneous queries
• A typical reference architecture for an information system
• n-tiered client-server architecture

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.12 Real-Time Example
Ariane-5 Failure

• Inquiry found that the Ariane program had a “culture...of only addressing random hardware failures” and assuming the software was correct
• Hardware failures are independent of one another
• Software faults tend to be logical
• All redundant components will have the same faults
• Redundancy in Ariane-5 is likely to recover only from hardware failures

Pfleeger and Atlee, Software Engineering: Theory and Practice

Chapter 5.*

5.13 What This Chapter Means For You

• Systems need to be designed based on carefully expressed requirements
• Design begins with a high-level architecture, where architectural decisions are based not only on system functionality and required constraints but also on desirable attributes and the long-term intended use of the system (including product lines, reuse, and likely modification)
• Keep in mind several characteristics of good architecture as you go, including appropriate user interfaces, performance, modularity, security, and fault tolerance
• The goal is not to design the ideal software architecture for a system, because such an architecture might not even exist. Rather, the goal is to design an architecture that meets all of the customer’s requirements while staying within the cost and schedule constraints