The Architecture Design Process

1
The Architecture Design Process
2
Architecture Design

• Focuses on the decomposition of a system into
  components and the interaction between those
  components to satisfy functional and non
  functional requirements
• A software system can be viewed as a hierarchy of
  design decisions (design rules or contracts)
• Each level of the hierarchy has a set of design
  rules that connects the components at that level

3
The Architectural View

• The first phase is the predesign phase
  concerned with understanding the enterprise
  context in which the application will exist.
• The second phase is the domain analysis phase
  where requirements are analyzed and structured
  with respect to the problem domain.

4
The Architectural View (Contd)

• The third phase is the schematic design phase
  where solution models identify modules of the
  system and design rules that establish the
  boundaries between the modules are established.
• The fourth phase is the design development phase
  where the architecture is refined and possibly
  multiple variations are created.

5
When Are the Architecture Design Activities Done?

• They can be practiced during any phase of the
  development process.
• However, to be of greatest benefit they should be
  done as early as possible.
• These activities can be viewed as a linear set of
  steps that can be repeated whenever missing
  information or hidden assumptions are identified.

6
Basic Steps of the Architecture Design Process

1. Understand the problem
2. Identify design elements and their relationships
3. Evaluate the architecture design
4. Transform the architecture design

7
System Quality Attributes

• The architecture essentially defines "externally
  visible" properties also known as system quality
  attributes for the whole software project, we are
  referring to such properties as its provided
  services, performance characteristics, fault
  handling, shared resource usage, and so on.
• Evaluation of an architecture's properties is
  critical to successful system development.
  However, reasoning about a system's intended
  architecture must be recognized as distinct from
  reasoning about its realized architecture. As
  design and eventually implementation of an
  architecture proceed, faithfulness to the
  principles of the intended architecture is not
  always easy to achieve.

8
Run-Time Quality Attributes

• Performance refers to the responsiveness of the
  system, the 'time required to respond to stimuli
  (events) or the number of events processed in
  some interval of time.
• Performance qualities are often expressed by the
  number of transactions per unit time or by the
  amount of time it takes a transaction with the
  system to complete.
• Since communication usually takes longer than
  computation, performance is often a function of
  how much communication and interaction there is
  between the components of the system-clearly an
  architectural issue.
• Security is a measure of the system's ability to
  resist unauthorized attempts at usage and denial
  of service while still providing its services to
  legitimate users.
• It is categorized in terms of the types of
  threats that might be made to system

9
Run-Time Quality Attributes (Contd)

• Availability measures the proportion of time the
  system is up and running.
• It is measured by the length of time between
  failures as well as by how quickly the system is
  able to resume operation in the event of failure.
  The steady state availability of a system is the
  proportion of time that the system is functioning
  correctly and is typically seen as follows
• time to failure/(time to failure time to
  repair)
• Availability comes from both "time to failure"
  and "time to repair" both are addressed through
  architectural means.

10
Understanding the Problem

• Without a clear understanding of the problem, it
  is not possible to create an effective solution
• When making a design decision, ask yourself what
  problem the design decision solves.
• If the answer is a technical or implementation
  problem, ask the question again until you reach a
  problem that is part of the original business
  problem.
• If you cant get there, its probably not the
  right design decision.

11
Identifying Design Elements and Their
Relationships

• Establish a baseline decomposition that initially
  splits the system based on functional
  requirements.
• The architecture of a software application is
  often represented as a set of interconnected
  modules or subsystems, often called, components.
• The functional decomposition can be modeled using
  blocks and arrows or by using UML package
  diagrams that show dependency associations.

12
Steps in Identifying Design Elements and Their
Relationships

1. Define the system context
2. Identify the modules
3. Describe the components and connectors

13
Defining System Context

• The system context describes the application from
  an external perspective.
• It helps in identifying the external interfaces
  to the system.
• The input to defining the system context is the
  initial requirements list.
• Defining the system context is related to
  understanding the problem domain that the system
  addresses.
• An initial model of the enterprise context of the
  system can be created by diagramming the existing
  business processes, artifacts, people, and
  existing systems.

14
Defining System Context (Contd)

• The new application should fit within this
  context.
• A use case diagram is a common way to depict the
  system context.
• The diagram can be augmented to include
  business-level objects (documents, records,
  reports) that are part of the domain.
• The goal of the model is to communicate the
  purpose and scope of the system it should be
  intuitive and understandable by even the least
  technical stakeholders.

15
Identifying Modules

• Modules are discrete units of software.
• Instantiations of these modules are commonly
  called components and connectors.
• A modular architecture is an application or
  system that is composed of two or more modules,
  each of which can be modified internally without
  affecting the other.

16
Identifying Modules (Contd)

• To achieve a low level of coupling between
  modules, the interface (connector) between the
  modules must be stable and static.
• These interfaces are the result of establishing
  design rules, e.g.,
• A common data format like XML Document Type
  Definition (DTD).
• A procedural interface such as a set of Java
  classes.
• A wire-level protocol like HTTP and HTML.

17
Describing Components and Connectors

• Components typically refer to the runtime
  instance of some unit of software.
• Connectors can refer to a unit of software or
  some communications mechanism (like UNIX pipes)
• Many of the quality attributes of the system are
  embodied in the components and their connectors.

18
Evaluating the Architecture

• This step is determining whether the architecture
  satisfies the requirements of the system.
• Both qualitative and quantitative measures are
  used to evaluate the quality attributes required
  of the system.
• If the it fails to meet these quality attributes,
  the architecture must be redesigned.

19
Evaluating the Architecture (Contd)

• In order to evaluate an architecture design, the
  quality attribute requirements must be clearly
  articulated.
• They must be articulated as specific quality
  attributes and their acceptable values.
• For example, a modifiability requirement may be
  reified as a scenario called a change case which
  might describe that a change is possible without
  requiring rework of more than one module.

20
Transforming the Architecture

• If the architectural design does not full satisfy
  its quality attribute requirements, then it must
  be changed until it does.
• A design is transformed by applying design
  operators, styles, or patterns.
• There are two types of design operators
• Those that affect the modular architecture
• Those that affect the component architecture

21
Modular Operators

1. Splitting a design into two or more modules
2. Substituting one design module for another
3. Augmenting the system by adding a new module
4. Excluding a module from the system
5. Inverting a module to create new interfaces
   (design rules)
6. Porting a module to another system

22
Design Operators

• Decomposition of a system into components
• Replication of components to improve reliability
• Compression of two or more components into a
  single component to improve performance
• Abstraction of a component to improve
  modifiability and adaptability
• Resource sharing, or the sharing of a single
  component instance with other components to
  improve integrability (the ability to integrate
  applications and systems), portability and
  modifiability