MASTER OF COMPUTER SCIENCE

SOFTWARE ARCHITECTURE AND DESIGN

WHY ARCHITECTURE - IMPORTANT?
ADog house has been built

Can you build a sky rise based on

the same structure?
AN ARCHITECTURE IS
"the fundamental organization of a
system embodied in its components,
their relationships to each other, and to
the environment, and the principles
guiding its design and evolution."
(IEEE)
Every system has an architecture, whether or not it is
documented and understood.
ARCHITECTURE….
the architecture of a system describes its
gross structure.
This structure illuminates
the top level design decisions, including
things such as how the system is composed
of interacting parts, where are the main
pathways of interaction, and what are the
key properties of the parts.
DEF: SOFTWARE ARCHITECTURE
• The architecture of a system is the set of
fundamental concepts or properties of
the system in its environment, embodied
in its elements, relationships, and the
principles of its design and evolution
• a system’s elements and relationships,
• its fundamental properties,
• the principles of its design and evolution.
SYSTEM’S ELEMENTS AND RELATIONSHIPS
• Define the structure of the system.
• Two types of structures
• static structure (organization of design-time
elements)
• programs, classes or packages, database stored
procedures, services, or any other self-contained code
unit
• dynamic structure (organization of runtime
elements and their interaction)
• Sending messages, execution of tasks, creation of
objects, deletion of objects, the status of actor
FUNDAMENTAL SYSTEM PROPERTIES
• Two different ways
• Externally visible behavior (what the system does)
• Similar to Dynamic behavior
• Flows of information in/out, responses to external stimuli, API
• Quality properties (how the system does it)
• externally visible, nonfunctional property of a system such as
performance, security, or scalability
• How does the system perform under load? What is the peak
throughput given certain hardware? How is the information in
the system protected from malicious use? How often is it
likely to break? How easy is it to manage, maintain, and
enhance? How easily can it be used by people who are
disabled?
PRINCIPLES OF DESIGN AND EVOLUTION
• To guide implementation
• To minimize conflicts and contradictions
(Consistent within the system)
• allows the system
• to be more easily understood
• encourages extensions to the system to be made
in a consistent and logical way,
• fitting into the overall form of the system without
introducing unnecessary complexity
EXAMPLE: AIRLINE BOOKING SYSTEM
External behavior
(booking a seat,
cancellation), &
Internal behavior
(response time
under a specified
load)
TWO-TIER CLIENT/SERVER ARCHITECTURE
THREE TIER CLIENT/SERVER ARCHITECTURE
WHAT DETERMINES ARCHITECTURAL DESIGN?
• Functional Requirements
• Non-Functional Requirements
• Design Constraints
• Quality Attributes requirements

▪ Architecture is a design blue print that integrates

requirements and the reality
CANDIDATE ARCHITECTURE
• a particular arrangement of static and dynamic structures
that has the potential to exhibit the system’s required
externally visible behaviors and quality properties
• Responses to a transaction
• acceptable response time, throughput, availability, and time to
repair
• able to meet the system’s overall requirements to
process XXX in a timely and efficient manner
• likely to differ in the specific set of quality properties that
each exhibits (easier to maintain but more expensive to
build than another).
ARCHITECTURAL PATTERN/STYLES
• Stylized abstract description of good practice
that has been tested in different systems and
environments.
• Describe system organization that has been
successful in previous systems
• Examples
• Client-server (2, 3, …n tire patterns)
• Layered Architectures
• Model View Controllers (MVC)
SOFTWARE ARCHITECTURE AS A BRIDGE

Requirements Software Architecture

Implementation

Architecture plays a key role as a bridge

between requirements and implementation
ARCHITECTURAL ELEMENT
• Components or Modules
• a fundamental piece from which a system can be
considered to be constructed
• Programming libraries, subsystems, deployable software units
(Enterprise Java Beans or .NET assemblies), reusable software
products (database management systems), or entire applications
• Properties
• A clearly defined set of responsibilities
• A clearly defined boundary
• A set of clearly defined interfaces, which define the services that
the element provides to the other elements
STAKEHOLDERS
• the people affected by a software system are not
limited to those who use it
• Understanding the role of the stakeholder is
fundamental to understanding the role of the
architect in the development of a software product
or system
• an individual, team, organization, or classes thereof,
having an interest in the realization of the system
• Architectures are created solely to meet stakeholder
needs.
STAKEHOLDERS “CONCERNS”
• stakeholders have concerns about the system
• a requirement, an objective, a constraint, an
intention, or an aspiration a stakeholder has for
that architecture
• A good architecture is one that successfully
addresses the concerns of its stakeholders
• when those concerns are in conflict, balances
them in a way that is acceptable to the
stakeholders.
ARCHITECTURE DESCRIPTION (AD)
• An architecture of a system is complex
• AD is a set of products that documents an
architecture in a way its stakeholders can understand
and demonstrates that the architecture has met their
concerns.
• (Products) architectural models, scope definition,
constraints, and principles
• Although every system has an architecture, not every
system has an architecture that is effectively
communicated via an architectural description.
AD …..
• A good architectural description is one that
effectively and consistently communicates the
key aspects of the architecture to the
appropriate stakeholders.
• ADL (Architecture Description Language) ….
CORE CONCEPTS AND RELATIONSHIPS
WHAT INFLUENCES ON SA
• Functional/non-functional requirements,
business and social
• Stakeholders,
• Development Organization (Resources available)
• Technical Environment (OO, WWW, thin client,
.NET, …)
• Background and experience (work on the similar
systems in the past, education & training wrt
problem area)
THE ROLES OF ARCHITECTURE?
Roles of architecture in software development can be
further elaborate as follows;
• Understanding:
• Increases comprehensibility of large systems by presenting
them at a level of abstraction making the system’s high-
level design can be easily understood
• Reuse:
• Architectural design supports reuse of large components
and also frameworks into which components can be
integrated.
• Construction:
• An architectural description provides a partial blueprint for
development by indicating the major components and
dependencies between them.
THE ROLES OF ARCHITECTURE CONT…
• Evolution:
• Software architecture can specify and expose the
dimensions along which a system is expected to evolve
• Analysis:
• Architectural descriptions provide new opportunities for
analysis, including system consistency checking,
conformance to constraints, conformance to quality
attributes (or non-functional requirements), dependence
analysis, and domain-specific analyses
• Management:
• Successful projects view achievement of a viable software
architecture as a key milestone in an enterprise software
development process. An evaluation of an architecture leads
to a much clearer understanding of requirements,
implementation strategies, and potential risks
ARCHITECTURE AND STAKEHOLDERS’VIEW
Architecture is a technical description or in other words an engineering
blueprint of a system, but it affects everyone involved with the system.

Customer, user, project manager, coder, tester, etc.—is concerned with

different characteristics of the system that are defined by its
architecture.

• User is concerned that the system is usable, reliable and available

• Customer is concerned that the architecture can be implemented on
schedule and to budget
• Manager is worried (in addition to cost and schedule) that the
architecture will allow development teams to work largely
independently, interacting in disciplined and controlled ways
• Developer is worried about achieving all of those goals through
coding
• Tester wants to prove (or disprove) that these goals will be met
ARCHITECTURE AS COMMUNICATION VEHICLE
• A common abstraction of the system, and so
provide a convenient language that all
stakeholders can speak and understand
• managers, users, customers, testers,
implementers, administrators, operators, etc.

• It is a technical “blueprint” for the system that

is to be built, modified, or analyzed
VIEW OF A SYSTEM

• It is not possible to capture the functional features and quality properties of a

complex system in a single comprehensible model that is understandable by, and
of value to, its stakeholders.
• A complex system is much more effectively described by a set of interrelated views,
which collectively illustrate its functional features and quality properties and
demonstrate that it meets its goals, than by a single overloaded model.
VIEW OF A SYSTEM

• A complex system is much more effectively described by a set of interrelated views,

which collectively illustrate its functional features and quality properties and
demonstrate that it meets its goals, than by a single overloaded model.
ARCHITECTURAL VIEW
• A view is a representation of one or more structural aspects of an architecture that
illustrates how the architecture addresses one or more concerns held by one or
more of its stakeholders
• What is included in a view
• View scope
• Element types
• Audience
• Scope of concerns
• Level of details
VIEWPOINT
• A viewpoint is a collection of patterns,
templates, and conventions for constructing
one type of view.
• It defines the stakeholders whose concerns
are reflected in the viewpoint and the
guidelines, principles, and template models
for constructing its views.
VIEWPOINTS AND VIEWS
• A viewpoint is a collection of patterns, templates and
conventions for constructing one type of view. It
defines the stakeholders whose concerns are reflected
in the viewpoint, and guidelines and principles and
template models for constructing its views.

• A view is a representation of all or part of an

architecture, from the perspective of one or more
concerns which are held by one or more of its
stakeholders.
~ IEEE Standard 1471 – Recommended Practice
for Architectural Description
RELATIONSHIPS VIEWS AND VIEWPOINTS
VIEWPOINTS AND VIEWS ……
• Help to deal with architectural structure
• Decompose architectural description into views
• each view addresses one aspect of the system
• functional view, deployment view, etc.
• Guide development of views via viewpoints
• viewpoint contains proven practice, pitfalls
• each view defined by one viewpoint
• Organize the process and the artifacts
ARCHITECTURAL VIEW MODELS
• RUP/Kruchten “4+1” set (1995)
• RM-ODP set (1995)
• Siemens set (1999)
• Garland and Anthony set (2003)
• Rozanski & Woods set (2005)
• Conceptual basis in IEEE 1471 (2000)
• …………………
ARCHITECTURAL VIEW MODELS – 4+1
• The 4+1 view model was originally introduced by Philippe
Kruchten in 1995
• Each of the five views in the 4+1 view model highlights some
elements of the system, while intentionally suppressing others
• Documents created using the 4+1 view process are easily used
by all members of the development team
• The first four views represent the logical, processing, physical,
and developmental aspects while the fifth view consists of use
cases and scenarios that might further describe or consolidate
the other views
ARCHITECTURAL VIEW MODELS – 4+1 ..
Logical View
• The 4+1's logical view supports behavioral
requirements and shows how the system is
decomposed into a set of abstractions

• Classes and objects are the main elements studied in

this view

• class diagrams, collaboration diagrams, and

sequence diagrams to show the relationship of these
elements from a logical view
LOGICAL VIEW
• Class diagram
• while useful, the class diagram hardly gives a complete picture of the system
• class diagrams are static, so they tell nothing about how the system will react to user
input

• Collaboration diagram
• showing a birds-eye view of collaborating objects in the system
LOGICAL VIEW …..
• Sequence diagram
• provide more detail than collaboration diagrams, but still let study the system from
a distance
• often use sequence diagrams to fine-tune system design
DEVELOPMENT VIEW
• the development view is used to describe the modules of the
system
• modules are bigger building blocks than classes and objects and
vary according to the development environment
• packages, subsystems, and class libraries are all considered
modules
• development view can be used to study the placement of actual
files in the system and development environment
• a good way to view the layers of a system in a layered architecture
• package diagram can be used to describe this view
PROCESS VIEW
• facilitate describing and studying of the system's
processes and how they communicate
• helpful when have multiple, simultaneous processes
or threads
• can be described from several levels of abstraction,
starting from independently executing logical
networks of communicating programs
• takes into account many of the nonfunctional
requirements or quality requirements
• activity diagrams are quite often used to describe
this view
PHYSICAL VIEW
• describes how the application is installed
and how it executes in a network of
computers

• takes into account nonfunctional

requirements like availability, reliability,
performance, and scalability

• deployment diagrams are often used to

describe this view
PLUS-ONE VIEW
• consists of use cases and scenarios that further describe or
consolidate the other views

• use cases are used to explain the functionality and

structures described by the other views

• can be described using use case diagrams

 POTENTIAL PITFALLS / WEAKNESSES
• A perspective is an aimed to a single or set of quality
prosperities
• Conflicts among solutions suggested by perspectives (a
highly evolvable system may be less efficient, and thus less
performant, than a less flexible one)
• The stakeholder concerns and priorities are different
for every system, so the degree to which you should
consider each perspective varies considerably
• Perspectives – general policies but every situation is
different from one to another
RELATIONSHIPS – VIEWS, VIEWPOINTS,
PERSPECTIVES
• View is a representation of all/part of an
architecture
• The complete set of views of an architecture
forms the AD
• A viewpoint guides the process of creating a
particular type of view
• A perspective guides the process of design so
that the system will exhibit one or more
important qualities.
• A view is a representation of all (or part of) an
architecture—that is, a way to document its
architecturally significant features according
to a related set of concerns; a viewpoint
guides the process of creating a particular
type of view; and a perspective guides the
process of designing the architecture so that it
exhibits one or more important qualities.
INTRODUCTION: ROLE OF ARCHITECT
• Architect is also often used as a generic title to
denote a senior technical member of staff
• May not be sometimes a technical specialist
• Architects may specialize in one area, such as
networking, middleware, or database design, to the
exclusion of others;
• Different titles: application architect, data architect, or
even enterprise architect,
• occasionally, the architect may not even have a
system development background at all, having
entered through another route such as business
analysis.
ARCHITECTURE DEFINITION
• Architecture definition is a process by which
stakeholder needs and concerns are captured,
an architecture to meet these needs is
designed, and clearly and unambiguously
described via an architectural description.
GOAL OF ARCHITECTURE DEFINITION
• Capturing stakeholder needs,
• what is important to stakeholders and recording and agreeing
on these needs
• Making a series of architectural design decisions that
result in a candidate architecture
• Assessing the candidate architecture to determine how
well it meets the stakeholder needs
• Refining the architecture until it is adequate
• Capturing the architectural design decisions in some form
of AD appropriate to the environment
OUTCOME
• A good architecture definition process is one that leads to a good architecture,
documented by an effective architectural description, which can be realized in a
way that is time- efficient and cost-effective for the organization.
SDLC
Software architecture is an important
aspect of software development

Required to introduce software architecture

methods and activities into the software
development life cycle.
CONTEXT OF ARCHITECTURE DEFINITION

• Architecture definition resolves this tension by

bridging the gap between the problem and
solution spaces
• To balance the needs to identify an acceptable
set of tradeoffs (technical feasibility,
timescales, resources, deployment
environment, costs)
ARCHITECTURE DEFINITION PROCESS
• a process of discovery than of just capture
• Input: hazy ideas of stakeholders expectations of
the system
• Resolve conflicting ideas about how the
system to be built
• Fills the gap between technical knowledge and the
development experience
• Craft the solutions without fully understanding
of problem but based on the technology
• Work with the requirements analysts to
understand the system’s requirements and
their relative importance. For each important
requirement, consider the likely difficulty of
implementing it and feed this back to the
requirements analysts to help them
understand what can and cannot be achieved.
 ARCHITECTURALLY SIGNIFICANT
• A concern, problem, or system element is architecturally significant if it has a wide
impact on the structure of the system or on its important quality properties such as
performance, scalability, security, reliability,or evolvability.
ROLE OF ARCHITECTURE
• The architect is responsible for designing,
documenting, and leading the construction of
a system that meets the needs of all its
stakeholders.
ARCHITECT’S RESPONSIBILITIES
1. To identify and engage the stakeholders
2. To understand and capture the stakeholders’
concerns
3. To create and take ownership of the
definition of an architecture that addresses
these concerns
4. To take a leading role in the realization of the
architecture into a physical product or system
ARCHITECTURAL LEADERSHIP
• Explaining and promoting the architecture to the business and
technology stakeholders, and justifying the principles and
decisions that underpin it
• Providing input to and support for planning and estimating
tasks
• Participating in change control processes
• Taking responsibility for and signing off on the completion of
technical milestones
• Helping to resolve issues that arise during development
• Taking on more specific development roles such as design
authority
• Reviewing documentation and possibly code
BENEFITS OF AN ARCHITECTURE?
• Facilitate building large and complex system
• Integrate different qualities required
• Manage the development
• Increase reuse
• Reduce waste, rework and redundancy
• Increase consistency and integration among
components
• Implement a business strategy
COMMON ISSUES OF SW ARCHITECTURE
• Lack of architectural talent and/or experience
• Insufficient time spent on architectural design and
analysis
• Failure to identify the quality drivers and design for them
• Failure to properly document and communicate the
architecture
• Failure to understand standards are not a substitute for
an architecture
• Failure to ensure that the architecture directs the
implementation
• Failure to evolve the architecture and maintain the
documentation current
WHY SOFTWARE ARCHITECTURE IS DIFFICULT
• Multi-dimensional problem
• Diverse stakeholder community to serve
• Making trade-offs inherent in the process
• Often no one “right” answer
• Little standardization in description
• Difficult to compare and discuss alternatives
• Unclear how to structure architectural activities
• Little sharing of proven practice and known problems and their
solutions
• No framework for handling quality (non-functional
requirements) properties
REFERENCES
• www.viewpoints-and-perspectives.info
• www.ibm.com/developerworks
• www.sei.cmu.edu/architecture
• David Garlan, Software Architecture: a Roadmap, Carnegie
Mellon University
• Rick Kazman, Software Architecture, Carnegie Mellon
University
• Nick Rozanski & Eoin Woods, Applying Viewpoints and
Views to Software Architecture
• Philippe Kruchten, Architectural Blueprints—The “4+1”
View Model of Software Architecture, Rational Software
Corp.