You are on page 1of 25

Software Architecture and Design

Sudhakar Chavali Aspiring Architect

Software Architecture

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
The system should be able to adapt to the changing customer needs and addition of new functionality.

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

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

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).

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 Quality Scenarios Variability (Current Flexibility and future Evolution) Current Flexibility: Local client side simplified services are possible until reconnection is possible. Impact of Factor Risk/Difficulty( Risk/Difficulty( H- High,MHigh,MMedium,LMedium,LLow)


Reliability: Recovery from Remote Service Failure

When a remote service fails, reestablish connectivity with it within 1 minute of its detected rereavailability, under normal store load in a production environment.

High impact on the large scale system.


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.

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.

Information Expert: Assign responsibility to the class that has the
information needed to fulfill it.

class A.
– – – –

Assign class B the responsibility to create an instance of

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.

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.

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.

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

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.

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.

Applying UML and Patterns: An
introduction to Object-oriented Analysis and Design and Iterative Development