1. Designing Architecture

2. Introduction
• We now turn our attention to the design of an
architecture and what you can do as it starts to
come into being. This chapter will cover four
topics:
▫ Architecture in the life cycle
▫ Designing the architecture
▫ Forming the team structure and its relationship to
the architecture
▫ Creating a skeletal system

3. Architecture in the Life Cycle
• Several Software development life-cycle models
exist, but one that puts architecture squarely in
the middle of things is the Evolutionary Delivery
Life Cycle model
• The intent of this model is to get user and
customer feedback and iterate through several
releases before the final release.
• The model also allows the adding of
functionality with each iteration and the delivery
of a limited version once a sufficient set of
features has been developed.

4. Evolutionary Delivery Life Cycle model

5. Architecture in the Life Cycle
• Where can I begin designing?
• Clearly, you cannot begin the design until you have
some idea of the system requirements.
▫ On the other hand, it does not take many requirements in
order for design to begin
• An architecture is "shaped" by some collection of
functional, quality, and business requirements. We call
“architectural drivers”
• To determine the architectural drivers,
▫ identify the highest priority business goals. (not too many)
▫ Turn these business goals into quality scenarios or use
cases.
▫ From this list, choose the ones that will have the most
impact on the architecture.
• Once the architectural drivers are known, the
architectural design can begin.

6. Designing the Architecture
• Attribute-Driven Design (ADD)
▫ a method for designing an architecture to satisfy both
quality requirements and functional requirements
• A set of quality attribute scenarios is input for ADD
• The ADD method can be viewed as an extension to
most other development methods, such as the
Rational Unified Process
• The Rational Unified Process has several steps that
result in the high-level design of an architecture but
then proceeds to detailed design and
implementation

7. Attribute-Driven Design
• ADD is an approach to defining a software architecture that
bases the decomposition process on the quality attributes.
• It is a recursive decomposition process where tactics and
architectural patterns are chosen to satisfy a set of quality
scenarios and then functionality is allocated to instantiate the
module types provided by the pattern.
• ADD is positioned in the life cycle after requirements analysis.
• The output of ADD is the first several levels of a module
decomposition view of an architecture and other views as
appropriate.
• The system is described as a set of containers for
functionality and the interactions among them.
• Nevertheless, it is critical for achieving the desired qualities, it
provides a framework for achieving the functionality.

8. ADD Steps
• The steps performed when designing an architecture using the ADD
method.
▫ Choose the module to decompose (usually start with the whole system). All
required inputs for this module should be available
▫ Refine the module according to these steps:
Choose the architectural drivers from the set of concrete quality scenarios and
functional requirements. This step determines what is important for this
decomposition.
Choose an architectural pattern that satisfies the architectural drivers. Create (or
select) the pattern based on the tactics that can be used to achieve the drivers.
Identify child modules required to implement the tactics.
Instantiate modules and allocate functionality from the use cases and represent
using multiple views.
Define interfaces of the child modules. The decomposition provides modules and
constraints on the types of module interactions. Document this information in the
interface document for each module.
Verify and refine use cases and quality scenarios and make them constraints for the
child modules. This step verifies that nothing important was forgotten and prepares
the child modules for further decomposition or implementation.
▫ Repeat the steps above for every module that needs further decomposition.

9. The garage door opener
• We demonstrate the ADD method by using it to
design a product line architecture for a garage
door opener within a home information system.
• The opener is responsible for raising and
lowering the door via
▫ a switch
▫ remote control
▫ the home information system.
• It is also possible to diagnose problems with the
opener from within the home information
system.

10. Sample Input
• The input to ADD is a set of requirements
• System-specific quality scenarios should be defined to the detail
necessary for the application.
• For our garage door example,
▫ The device and controls for opening and closing the door are different
for the various products in the product line, as already mentioned. They
may include controls from within a home information system. The
product architecture for a specific set of controls should be directly
derivable from the product line architecture.
▫ The processor used in different products will differ. The product
architecture for each specific processor should be directly derivable from
the product line architecture.
▫ If an obstacle (person or object) is detected by the garage door during
descent, it must halt (alternately re-open) within 0.1 second.
▫ The garage door opener should be accessible for diagnosis and
administration from within the home information system using a
product-specific diagnosis protocol. It should be possible to directly
produce an architecture that reflects this protocol.

11. 1.Choose the module to decompose
• The following are all modules:
▫ System
▫ Subsystem
▫ Submodule
• The decomposition typically starts with the
system, which is then decomposed into
subsystems, which are further decomposed into
submodules
• the garage door opener is the system, we
choose to decompose

12. 2a. Choose the architectural drivers
• Architectural drivers are the combination of
functional and quality requirements.
• The drivers will be found among the top-priority
requirements for the module.
• The four scenarios we have shown are architectural
drivers
▫ real-time performance
▫ modifiability to support product lines.
▫ online diagnosis be supported.
• All of these requirements must be addressed in the
initial decomposition of the system.
• We do not treat all of the requirements as equal;
the less important requirements are satisfied within
the constraints of the most important.

13. 2b. Choose an architectural pattern
• Each tactic is designed to realize one or more
quality attributes
• But the patterns in which they are arranged
have an impact on other quality attributes.
• In an architecture design, a composition of
many such tactics is used to achieve a balance
between the required multiple qualities.
• Achievement of the quality and functional
requirements is analyzed during the refinement
step.

14. 2b. Choose an architectural pattern
• The goal of this step is to establish an overall
architectural pattern consisting of module types
• Two main factors guide tactic selection.
▫ The drivers
▫ The side effects that a pattern implementing a tactic
has on other qualities.
• We see performance and modifiability as the critical
quality attributes.
• We choose these as our tactics:
▫ semantic coherence and information hiding
combine them to define virtual machines for the affected
areas
▫ increase computational efficiency
▫ choose scheduling policy

15. 2b. Choose an architectural pattern
• Architectural pattern

16. 2c. Instantiate modules
• Our criterion for allocating functionality is similar to
that used in functionality-based design methods,
such as most object-oriented design methods.
• We allocate the responsibility for managing obstacle
detection and halting the garage door to the
performance-critical section since this functionality
has a deadline
• The management of the normal raising and lowering
of the door has no timing deadline, and so we treat
it as non-performance-critical section
• We also identify several responsibilities of the virtual
machine: communication and sensor reading and
actuator control. This yields two instances of the
virtual machine that are also shown in Figure

17. 2c. Instantiate modules
• The result of this step is a decomposition of a
module.
• The next steps verify how well the
decomposition achieves the required
functionality

18. 2c. Allocate functionality
• Every use case of the parent module must be
representable by a sequence of responsibilities
within the child modules.
• Assigning responsibilities to the children in a
decomposition also leads to the discovery of
necessary information exchange.
• At this point only the information itself and the
producer and consumer roles are of interest.
• These steps should be sufficient to gain
confidence that the system can deliver the
desired functionality.

19. 2c. Represent the architecture with
views
• Dynamic and runtime deployment information is
also required to analyze the achievement of
qualities such as performance, security, and
reliability.
• In our experience with ADD, one view from each
of the three major groups of views have been
sufficient to begin with.
▫ Module decomposition view
▫ Concurrency view
▫ Deployment view.

20. 2c. Module decomposition view
• Module decomposition view show
▫ Module as containers for holding responsibilities
as they are discovered.
▫ Major data flow relationships among the modules
are also identified through this view.

21. 2c. Concurrency view
• In the concurrency view dynamic aspects of a
system such as parallel activities and
synchronization can be modeled.
• This modeling helps to identify resource
contention problems, possible deadlock
situations, data consistency issues, and so forth.
• It can lead to discovery of new modules, such as
a resource manager, in order to solve issues of
concurrent access to a scarce resource and the
like.

22. 2c. Concurrency view
• The concurrency view is one of the component-
and-connector views.
▫ The components are instances of the modules
▫ The connectors are the carriers of virtual threads
▫ A "virtual thread" describes an execution path
through the system or parts of it.
• The connectors in a concurrency view are those
that deal with threads such as "synchronizes
with," "starts," "cancels," and "communicates
with."

23. 2c. Concurrency view
• To understand the concurrency in a system, the
following use cases are illuminating:
▫ Two users doing similar things at the same time.
▫ One user performing multiple activities
simultaneously.
▫ Starting up the system.
▫ Shutting down the system.
• In our example, we can see a point of
synchronization in the sensor/actuator virtual
machine

24. 2c. Deployment view
• Using a deployment view helps to determine
and design a deployment that supports
achieving the desired qualities.
• The deployment view also helps in deciding if
multiple instances of some modules are needed.
• In our example, deployment issues are found in
the division of responsibilities between the door
opener system and the home information
system.

25. 2d. Define interfaces of the child
modules
• An interface of a module shows the services and
properties provided and required.
• It documents what others can use and on what
they can depend.
• During analyzing views, It uncovers the
interaction assumptions for the child modules.
• The module view documents
▫ producers/consumers of information.
▫ patterns of interaction that require modules to
provide services and to use them.

26. 2d. Define interfaces of the child
modules
• The concurrency view documents
▫ interactions among threads that lead to the interface
of a module providing or using a service.
▫ the information that a component is active—for
example, has its own thread running.
▫ the information that a component synchronizes,
sequentializes, and perhaps blocks calls.
• The deployment view documents
▫ the hardware requirements, such as special-purpose
hardware.
▫ some timing requirements, such as that the
computation speed of a processor has to be at least
10 MIPS.
▫ communication requirements, such as that information
should not be updated more than once every second.

27. 2e.Verify and refine
• Verify and Refine Use Cases and Quality
Scenarios as Constraints for the Child Modules
• This decomposition must be verified and the
child modules must be prepared for their own
decomposition
• Verify and Refine
▫ Functional requirements
▫ Constraints
▫ Quality scenarios

28. 2e Functional Requirment
• Each child module has responsibilities that
derive partially from considering decomposition
of the functional requirements
• Those responsibilities can be translated into use
cases for the module.
• Another way of defining use cases is to split and
refine the parent use cases
• This approach has traceability because an
analyst can follow the refinement.

29. 2e Functional Requirement
• In our examples, the responsibilities are decomposed into the
following functional groups corresponding to the modules.
▫ User interface. Recognize user requests and translate them into
the form expected by the raising/lowering door module.
▫ Raising/lowering door module. Control actuators to raise or lower
the door. Stop the door when it reaches either fully open or fully
closed.
▫ Obstacle detection. Recognize when an obstacle is detected and
either stop the descent of the door or reverse it.
▫ Communication virtual machine. Manage all communication with
the home information system.
▫ Sensor/actuator virtual machine. Manage all interactions with the
sensors and actuators.
▫ Scheduler. Guarantee that the obstacle detector will meet its
deadlines.
▫ Diagnosis. Manage the interactions with the home information
system devoted to diagnosis.

30. 2e Constraints
• Constraints of the parent module can be satisfied in
one of the following ways:
▫ The decomposition satisfies the constraint.
▫ The constraint is satisfied by a single child module.
▫ The constraint is satisfied by multiple child modules.
• In our example, one constraint is that the
communication with the home information system is
maintained. The communication virtual machine will
recognize if this communication is unavailable, so
the constraint is satisfied by a single child.

31. 2e Quality Scenarios
• Quality scenarios also have to be refined and
assigned to the child modules
• A quality scenario may be completely satisfied by
the decomposition without any additional impact. It
can then be marked as satisfied.
• A quality scenario may be satisfied by the current
decomposition with constraints on child modules.
• The decomposition may be neutral with respect to a
quality scenario
• A quality scenario may not be satisfiable with the
current decomposition, the rationale for the
decomposition not supporting this scenario must be
recorded. This is usually the result of a tradeoff with
other, perhaps higher-priority scenarios

32. 2e Quality Scenarios
• In our example
• The devices and controls equipments are different for
different products in the product line. This scenario is
delegated to the user interface module.
• The processor used in different products will differ. This
scenario is delegated to all of the modules. Each module
becomes responsible for not using processor-specific.
• If an obstacle is detected by the garage door during
descent, the door must halt within 0.1 second. This
scenario is delegated to the scheduler and the obstacle
detection module.
• The garage door opener should be accessible for
diagnosis and administration from within the home
information system using a product-specific diagnosis
protocol. This scenario is split between the diagnosis
and communication modules.

33. Forming the Team Structure
• Once the first few levels of the architecture's module
decomposition structure are fairly stable, those modules can
be allocated to development teams.
• The impact of an architecture on the development of
organizational structure is clear.
▫ Once an architecture for the system under construction has been
agreed on, teams are allocated to work on the major modules
and a work breakdown structure is created that reflects those
teams.
▫ Each team then creates its own internal work practices. For large
systems, the teams may belong to different subcontractors.
▫ The work practices may include items such as bulletin boards and
Web pages for communication, naming conventions for files, and
the configuration control system. All of these may be different
from group to group.
▫ Furthermore, quality assurance and testing procedures are set up
for each group, and each group needs to establish liaisons and
coordinate with the other groups.

34. Forming the Team Structure
• Within the team there needs to be high-
bandwidth communications.
• Between teams, low-bandwidth communications
are sufficient.
• This assumes that the system has been
designed with appropriate separation of
concerns.
• Team structure and controlling team interactions
often turn out to be important factors affecting a
large project's success

35. Creating a Skeletal System
• Once an architecture is sufficiently designed and
teams are in place to begin building to it, a
skeletal system can be constructed.
• Classical software engineering practice
recommends "stubbing out" sections of code so
that portions of the system can be added
separately and tested independently.
▫ However, which portions should be stubbed?
▫ By using the architecture as a guide, a sequence
of implementation becomes clear.

36. Creating a Skeletal System
• First, implement the software that deals with the execution and
interaction of architectural components.
▫ This may require producing a scheduler in a real-time system
▫ implementing the rule engine (with a prototype set of rules) to control
rule firing in a rule-based system
▫ implementing process synchronization mechanisms in a multi-process
system
▫ implementing client-server coordination in a client-server system.
• At this point, you will have a running system that essentially sits
there and hums to itself—but a running system nevertheless. This is
the foundation onto which useful functionality can be added.
• You can now choose which of the elements providing functionality
should be added to the system.
▫ The choice may be based on lowering risk by addressing the most
problematic areas first
▫ it may be based on the levels and type of staffing available
▫ it may be based on getting something useful to market as quickly as
possible.

37. Summary
• Architecture design must follow requirements analysis, but it does
not need to be deferred until requirements analysis is completed.
• In fact, architecture design can begin once the critical architectural
drivers have been determined.
• When a sufficient portion of the architecture has been designed
(again, not necessarily completely designed), a skeletal system can
be developed. This skeletal system is the framework on which
iterative development (with its associated ability to deliver at any
point) is performed.
• The quality scenarios and tactics are critical to architecture design.
• ADD is a top-down design process based on using quality
requirements to define an appropriate architectural pattern and on
using functional requirements to instantiate the module types given
by that pattern.
• Architecture determines some level of organizational structure
through determining the necessary communication paths.
• Existing organizational structure influences architecture as well by
providing organizational units with specialized expertise and vested
interests.