Chapter 10

CREATING AN ARCHITECTURAL
DESIGN
Design has been described as a multistep process in which representations of data and program structure,
interface characteristics and procedural detail are synthesized from information requirements. It can also
be described as

Design is an activity concerned with making major decisions, often of a structural nature. It
shares with programming a concern for abstracting information representation and processing sequences,
but the level of detail is quite different at the extremes. Design builds coherent, well-planned
representations of programs that concentrate on the interrelationships of parts at the higher level and the
logical operations involved at the lower levels.

10.1 SOFTWARE ARCHITECTURE

10.1.1 WHAT IS ARCHITECTURE?

The software architecture of a program or computing system is the structure or structures of the system,
which comprise software components, the externally visible properties of those components, and the
relationships among them.

The architecture is not the operating software. 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. 3.) Reduce the
risks associated with the construction of the software.

10.1.2 WHY IS ARCHITECTURE IMPORTANT?

• Representations of software architecture are an enabler for communication between al parties

interested in the development of a computer-based system.

• The architecture highlights early design decisions that will have a profound impact on all
software engineering work that follows and as important on the ultimate success of the system as
an operational entity.

• Architecture “constitutes a relatively small, intellectually graspable model of how the system is
structured and how its components work together”.
 10.2 DATA DESIGN
The data design action 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.

10.2.1 DATA DESIGN AT THE ARCHITECTURAL LEVEL

Today, businesses large and small are overloaded with data. Many moderately sized business have dozens
of databases serving many applications comprising hundreds of gigabytes of data. The challenge here is
to extract useful information from this data environment, particularly when the information is cross-
functional.

The solution being, data mining technique which is also known as KDD – knowledge
discovery in databases that attempt to extract appropriate business-level information. The degree of detail
contained with the databases, and many other factors make data mining difficult within an existing
database environment. Hence, an alternative solution was provided to overcome this drawback known as
data warehousing.

10.2.2 DATA DESIGN AT THE COMPONENT LEVEL

Data design at the component level focuses on the representation of data structures that are directly
accessed by one or more software components. Actually, the design of data begins during the creation of
the analysis model. Principles for data specification are

1. The systematic analysis principles applied to function and behavior should also be applied to data

2. All data structures and the operations to be performed on each should be identified

3. A mechanism for defining the content of each data object should be established and used to
define both data and the operations applied to it

4. Low-level data design decisions should be deferred until late in the design process

5. The representation of a data structure should be known only to those modules that must make
direct use of the data contained within the structure

6. A library of useful data structures and the operations that may be applied to them should be
developed

7. A software design and programming language should support the specification and realization of
abstract data types.
 10.3 ARCHITECTURAL STYLES AND PATTERNS
The software that is built for computer-based systems also exhibits one of many architectural styles. Each
style describes a system category that best describes the following

1. A set of components (database, computational modules) that perform a function required by a

system

2. A set of connectors that enable “communication, coordination and cooperation” among

components

3. Constraints that define how components can be integrated to form the system

4. Semantic models that enable a designer to understand the overall properties of a system by
analyzing the known properties of its constituent parts.

An architectural pattern like an architectural style imposes a transformation on the design of a

architecture. They differ from a style in following ways

1. The scope of a pattern is less broad, focusing on one aspect of the architecture rather than the
architecture in its entirety.

2. A pattern imposes a rule on the architecture, describing how the software will handle some aspect
of its functionality at the infrastructure level.

3. Architectural patterns tend to address specific behavior issues within the context of the
architecture.

10.3.1 ARCHITECTURAL STYLES

 Data-centered architectures

 Data flow architectures

 Layered architectures

 Call and return architectures

 Object-oriented architectures

A data store resides at the center of this architecture and is accessed frequently by other components that
update, add, delete or otherwise modify data within the store. A client software accesses a central
repository. A data-centered architecture promotes integrality which is, existing components can be
changed and new client components added to the architecture without concern about other clients.
 Data-flow 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 transmit 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 of a specified form. However, the filter does not require
knowledge of the workings of its neighboring filters. If the data flow degenerates into a single line of
transforms, it is termed a batch sequential.
Call and return architectural style enables a software designer to achieve a program structure that is
relatively easy to modify and scale.

• Main program / sub program architecture.

• Remote procedure call architecture.

In layered architecture, a number of different layers are defined, each accomplishing operations that
progressively become closer to the machine instruction set. 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.

10.3.2 ARCHITECTURAL PATTERNS

The architectural patterns for software define a specific approach for handling some behavioral
characteristics of the system such as

• Concurrency

Many applications must handle multiple tasks in a manner that simulates parallelism. There are
several such ways to handle concurrency and each can be presented by a different architectural
pattern.

• Persistence

Persistent data are stored in a database or file and may be read or modified by other processes at a
later time. In an object oriented environment, the idea of persistent object extends the persistence
concept.

• Distribution

The distribution problem addresses the manner in which systems or components within systems
communicate with one another in a distributed environment such as – the way in which entities
connect to one another and another is the nature of the communication that occurs.

10.3.3 ORGANIZATION AND REFINEMENT

As the design process often leaves a software engineer with a number of architectural alternatives, it is
important to establish a set of design criteria that can be used to access an architectural design. Following
are the questions which provide an insight into the architectural style that has been derived.

• Control

How is control managed in the architecture? Does a distinct control hierarchy exist and if so, what is
the role of components within this control hierarchy? How do components transfer control within the
system?

• Data

How are data communicated between components? Is the flow of data continuous, or are data objects
passed to the system sporadically? What is the mode of transfer? Do data components exist and if so,
what is their role? How do functional components interact with data components?
 10.4 ARCHITECTURAL DESIGN
As architectural design begins, the software to be developed must be put into context that is the design
should define the external entities (such as other systems, people, devices) that the software interacts with
and the nature of the interaction.

Once the context is modeled and all external software interfaces have been described, the designer
specifies the structure of the system by defining and refining software components that implement the
architecture.

10.4.1 REPRESENTING THE SYSTEM IN CONTEXT

A system diagram accomplishes the requirement by representing the flow of information into and out of
the system, the user interface and relevant support processing. At the architectural design level, a software
architect uses an architectural context diagram (ACD) to model the manner in which software interacts
with entities external to its boundaries.

From the above figure, systems that interoperate with the target system are represented as following

• Superordinate systems

Those systems that use the target system as part of some higher level processing schems.
 • Subordinate systems

Those systems that are used by the target system and provide data or processing that are necessary to
complete target system functionality.

• Peer-level systems

Those systems that interact on a peer-to-peer basis.

• Actors

Those entities that interact with the target system by producing or consuming information that is
necessary for requisite processing.

10.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. In general, a relatively small set of archetypes is required to design
even relatively complex systems which represent stable elements of the architecture but may be
instantiated in many different ways based on the behavior of the system.

From the above, which is derived from the safehome security function,

• Node
 Represents a cohesive collection of input and output elements of the home security function.

• Detector

An abstraction that encompasses all sensing equipment that feeds information into the target system.

• Indicator

An abstraction that represents all mechanisms for indicating that an alarm condition is occurring.

• Controller

An abstraction that depicts the mechanism that allows the arming or disarming of a node. If
controllers reside on a network, they have the ability to communicate with one another.

10.4.3 REFINING THE ARCHITECTGURE INTO COMPONETS

As the software architecture is refined into components, the structure of the system begins to emerge. The
architectural designer begins with the classes that were described as part of the analysis model. These
analysis classes represent entities within the application domain that must be addressed within 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.

Continuing the SAFEHOME home security function example, we might define the set of top-level
components that address the following functionality

• External communication management

• Control panel processing

• Detector management

• Alarm processing

The overall architectural structure is illustrated in the below diagram. 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 and the alarm processing
component produces output when an alarm is detected.
10.4.4 DESCRIBING INSTANTIATIONS OF THE SYSTEM

The architectural design that has been modeled to this point is still relatively high level. Thought the
context of the system has been represented, archetypes that indicate the important abstractions within the
problem domain have been defined, thought the overall structure of the system is apparent, there will be
further refinement necessary.
 10.5 ASSESSING ALTERNATIVE ARCHITECTURAL DESIGNS

10.5.1 AN ARCHITECTURE TRADE-OFF ANALYSIS METHOD

The design analysis activities that follow are performed iteratively to evaluate process for software
architectures.

1. Collect scenarios.

2. Elicit requirements, constraints, and environment description.

3. Describe the architectural styles / patterns that have been chosen to address the scenarios and
requirements.

4. Evaluate quality attributes by considering each attribute in isolation.

5. Identify the sensitivity of quality attributes to various architectural attributes for a specific
architectural style.

6. Critique candidate architectures using the sensitivity analysis.

These six steps represent the first ATAM iteration. Based on the result 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.

10.5.2 ARCHITECTURAL COMPLEXITY

A useful technique for assessing the overall complexity of a proposed architecture is to consider
dependencies between components within the architecture.

• Sharing dependencies

Represents 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 of control among a set of activities.

10.5.3 ARCHITECTURAL DESCRIPTION LANGUAGES

Architectural description language (ALD) provides a semantics and syntax for describing a software
architecture. ADL should provide the designer with the ability to decompose architectural components,
compose individual components into larger architectural blocks, and represent interfaces between
components.
 10.6 MAPPING DATA FLOW INTO A SOFTWARE ARCHITECTURE
Structured design is often characterized as a data flow-oriented design method because it provides a
convenient transition from a data flow diagram to software architecture. The type of information flow is
the driver for the mapping-approach.

10.6.1 TRANSFORM FLOW

Information must enter and exit software in an “external world” form. Such externalized data must be
converted into an internal form for processing. Information enters the system along paths that transform
external data into an internal form. These paths are defined as incoming flow. At the kernel the
transition occurs. Incoming data are passed through a transform center and begin to move along paths
that now lead out of the software. Data moving along these paths are called out-going flow. The
overall flow of data occurs in a sequential manner and follows one, or only a few straight line paths.
When a segment of data flow diagram exhibits these characteristics, transform flow is present.

10.6.2 TRANSCATION FLOW

Information flow is often characterized by a single data item, called a transaction, which triggers other
data flow along one of many paths.
Transition flow is characterized 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 center.

10.6.3 TRANSFORM MAPPING

Transform mapping is a set of design steps that allows a DFD with transform flow characteristics to be
mapped into a specific architectural style.

Let us consider the SAFEHOME security function. The following design steps are initiated.

Step 1: Review the fundamental system model

Step 2: Review and refine data flow diagrams for the software.

Step 3: Determine whether the DFD has transform or transaction flow characteristics.

Step 4: Isolate the transform center by specifying incoming and outgoing flow boundaries.

Step 5: Perform first-level factoring.

Step 6: Perform second level factoring.

Step 7: Refine the first iteration architecture using design heuristics for improved software quality.

Context level DVD for the SAFEHOME SECURITY FUNCTION

Level 1 DFD for the SAFEHOME SECURITY FUNCTION

Level 2 DFD that refines the monitor sensors transform

Level 3 DFD for monitor sensors with flow boundaries

 First-level factoring for monitor sensors

Second-level factoring for monitor sensors