Software Architecture and Design

Sudhakar Chavali
Aspiring Architect
Software Architecture

Definition
Software Architecture is defined as the set of
significant decisions about the organization of a
software system, the selection of the structural
elements and their interfaces by which the system is
composed together with their behavior as specified
in the collaborations among those elements into
progressively larger subsystems, and the
architectural style that guides this organization.
 Goals for Software Architecture

Extensibility:
The system should be able to adapt to the changing customer needs and
addition of new functionality.

Maintainability:
This is simplicity and clarity which needs to be traded-off w.r.t.
performance and other non-functional requirements.

Reliability:
This determines whether the system operates in full functionality in all the
conditions.

Scalability:
This determines whether the system accommodates more data and more
number of users.
 Architectural Analysis

It is the identification of factors that influence

the architecture, understanding their variability
and priority and resolving them.

It is the identification and resolution of the
system’s non-functional requirements in the
context of the functional requirements.

The important goal of Architectural Analysis is
to understand the influence of the factors and
their variability (immediate need for flexibility
and future evolution).
Contd..

During Architecture Analysis, quality scenarios

are recommended for defining measurable
responses.

Quantifying some things, such as performance
goals and mean time between failure are well
known practices, but quality scenarios record all
factors as measurable statements.

UP (Unified Process) suggests a Factor Table to
document the quality scenarios.
A sample Factor Table

S.No. Factor Measures and Variability Impact of Risk/Difficulty(

Risk/Difficulty(
Quality (Current Factor H- High,M-
High,M-
Scenarios Flexibility and Medium,L-
Medium,L-
future Low)
Evolution)

1 Reliability: When a Current High impact M

Recovery from remote service Flexibility: on the large
Remote fails, Local client
Service reestablish side simplified scale system.
connectivity services are
Failure with it within possible until
1 minute of its reconnection
detected re-
re- is possible.
availability,
under normal
store load in a
production

environment.
Basic Architectural Principles

Cohesion: This is to organize parts of the system into logical groups. This
should always be high.

Coupling: This makes groups independent and thus changes in one logical
group does not affect the other. This should always be low.

Protected Variation: Interfaces, indirection, service lookup, and so forth.

Separation of concerns (Model-View-Controller): By this principle, the

model (domain) objects and view (UI) objects are separated in
responsibilities. At an architecture level, the Model is Domain Layer, the
View is the UI layer, and the Controllers are the workflow objects in the
Application Layer.
Logical Architecture

The Logical Architecture is the large-scale organization

of the software classes into packages, subsystems and
layers.

A layer is a coarse-grained grouping of classes,

packages, or subsystems that has cohesive responsibility
for a major aspect of the system.

UML package diagrams are used to illustrate the logical

architecture of a system. A layer is modeled as a
package.
Agile Modeling

The main objective in Agile modeling is modeling to

understand and communicate rather than to document.

It is a practice in which the drawings are drawn on white

boards during discussions and several models are created
in parallel. These are captured using Digital cameras.

Later on the Agile models captured in cameras can be

documented using a UML CASE tool such as Rational
XDE.
Iterative Architecture

Unified Process recommends four phases in a project

life cycle. These are Inception, Elaboration,
Construction and Transition.

During Inception, if it is unclear whether it is

technically possible to satisfy the architecturally
significant requirements, the project may implement
POC (Proof-of-Concept) to determine feasibility.

During Elaboration, implement the core risky

architectural elements. The majority of the SAD
(Software Architecture Document) should be
completed by the end of this phase.
Contd..

During Transition, SAD will be reviewed and

revised to ensure it accurately describes the final
developed system.

While designing new versions, revisit the

architectural factors and decisions.
Structure of SAD

According to Unified Process, SAD document

typically describes the following

Architectural Representation

Architectural Factors

Architectural Decisions

Logical View

Use case View

Deployment View

Any other view which is relevant to the project.

Architectural View

A view of the system Architecture from a given

perspective.

It focuses primarily on Structure, Modularity,
Essential components, and the main control
flows.

A view does not describe all of the system.

A view describe sonly the outstanding ideas
from that perspective.

The old architectural model of 4+1 views has
been expanded to N+1 views where more views
can be added if required.
 Object Models

The following questions are asked during object design

– What are the responsibilities of the object?
– Who does it collaborate with?
– What design patterns should be applied?

There are two kinds of object models.
– Dynamic Model
– Static Model

Dynamic models are called as UML Interaction Diagrams such
as Sequence Diagrams and Communication Diagrams. These
help design the logic, the behavior of the code or the method
bodies.

Static Models are UML Class Diagrams. These help design the
definition of class names, attributes, and method signatures.
OO design principles

GRASP (General Responsibility Assignment

Software Patterns)

GoF (Gang-of-Four) design patterns

The overall approach to doing the OO design
modeling will be based on the metaphor of
responsibility-driven design (RDD), thinking
about how to assign responsibilities to
collaborating objects.
GRASP

Information Expert: Assign responsibility to the class that has the

information needed to fulfill it.

Creator: Assign class B the responsibility to create an instance of
class A.
– B “contains” or compositely aggregates A.
– B records A.
– B closely uses A.
– B has the initializing data for A.

Controller: Assign responsibility to an object representing
– The overall system, a root object or a use case scenario within which
the system operation occurs.
Contd..

Cohesion: This should be high.

Coupling: This should be low.

Polymorphism: When related alternatives or behaviors
vary by type(class), assign responsibility for the behavior –
using polymorphic operations – to the types for which the
behavior varies.

Pure Fabrication: Assign a highly cohesive set of
responsibilities t an artificial or convenience class that does not
represent a problem domain concept – something made up, to
support high cohesion, low coupling , and reuse.
Contd..

Indirection: Assign the responsibility to an intermediate

object to mediate between other components or services
so that they are not directly coupled.

Protected Variation: Identify points of predicted

variation or instability; assign responsibilities to create a
stable interface around them. This is also known as
‘Information Hiding’.
Dynamic Modeling

Dynamic object modeling is the interaction of objects by

messages using Interaction Diagrams.

They are two common types: Sequence and
Communication Interaction Diagrams.

Sequence diagrams are preferred as they are notationally
rich. They show interactions in a kind of fence format,
in which each new object is added to the right.

Tool support is better and more notation options are
available. Also, it is easier to see call-flow sequence with
Sequence Diagrams.
Contd..

Although the static-view diagrams are indeed

useful, the dynamic-view interaction diagrams
are incredibly valuable.

Spend time in dynamic object modeling because
it gives the concrete details of which messages to
send, and to whom, and in what order which are
true OO design details.

When these diagrams are drawn, a set of classes
and their methods emerge from the creative
design process of object modeling.
Static object Modeling

Static object Modeling deals with classes,

interfaces, and their associations. Class
Diagrams are used to illustrate these.

Sometimes, from interaction diagrams, the
definitions of class diagrams can be generated.
But in practice, when following agile modeling,
both models are drawn in parallel.

Relationships such as Generalization,
Dependency, Association and Aggregation and
Composition are shown in the Class Diagrams.
GoF Design Patterns

There are 23 main GoF (Gang of Four) design patterns and

lot more technology specific patterns created based on
these. Some of the popularly used are

Adapter

Factory

Singleton

Strategy

Façade

Observer

State

Command

Proxy

Composite
Persistence

Use industrial strength frameworks rather than creating

the design for persistence.

Using frameworks solves problems of object-relational
mapping, performance and transaction support. For
example, Hibernate in case of J2EE.

A Persistence Framework is a general purpose, reusable,
and extendable set of types that provides functionality to
support persistent objects.

A set of persistence services are created to do O-R
mapping which translates objects into records in tables
and vice-versa.
Summary

In addition to the UML artifacts of Package

Diagrams, Sequence Diagrams and Class
Diagrams, Software Architecture Document is
an important document.

Architecturally significant requirements are
analyzed initially and a POC may be conducted
to resolve them.

Patterns are incorporated to resolve the technical
problems.
References

Applying UML and Patterns: An

introduction to Object-oriented Analysis and
Design and Iterative Development