Chapter 3: Envisioning Architecture

Tadele M.
 Software Architecture: Definition
 The software architecture of a program or computing
system is the set of structures of the system, which
comprise software elements, the externally visible
properties of those elements, and the relationships
among them.
 The architectural view of a system is abstract, distilling
away details of implementation, algorithm, and data
representation and concentrating on the behaviour and
interaction of "black box" elements.

2
 Software Architecture: Definition…

 Elements can be: objects, classes, functions, processes,

programs, libraries, databases, etc.
 Relationships between elements: part of, synchronization,
function call, etc.
 The external visible properties as assumptions
that other elements can make of an element, such as:
 its provided services,
 performance characteristics,
 fault handling,
 shared resource usage, …
3
 Definition Implications
 Architecture defines software elements.
 Systems can and do comprise more than one structure, all
are part of the architecture.
 Every computing system with software has an architecture.
 The behavior of each element is part of the architecture as
far as its behavior can be observed or distinguished from the
point of view of another element.
 The definition doesn’t judge goodness or badness.

4
 Definition from IEEE

 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 1471].

5
 The Architecture Business Cycle
 For decades, software designers have been taught to
build systems based exclusively on the technical
requirements.
 Software architecture is a result of technical, business,
and social influences.
 Its existence, in turn, influences these technical,
business, and social environments.
 This cycle of influences from the environment to
the architecture and back to the environment is
6
called the Architecture Business Cycle.
 Where do Architectures Come From?
Architectures are influenced by:
 Stakeholders
 each stakeholder has different concerns & goals, some contradictory
 architect often has to fill in the blanks and mediate the conflicts.
 Development Organization
 immediate business, long-term business, and organizational (staff
skills, schedule, & budget)
 Background & Experience of the Architects
 repeat good results, avoid duplicating disasters
 The Technical Environment
 standard industry practices or common SE techniques
7
 Influence of system stakeholders on the architect

Developing Marketing End User Maintenance

organization stakeholder Stakeholder organization Customer
management stakeholder
stakeholder stakeholder

Low Cost, Neat features, Behaviour, Modifiability Low cost,

Keeping people Short time to Performance,
employed Security , Timely
market, Low Cost
Reliability, delivery,
Usability
not
changed
often
Figure 1.2 Influence of
stakeholders on the architect

8
 Ramifications of Influences
 The properties required by the business and organizational
goals are seldom completely understood.
 Architects need to know & understand the nature, source,
and priority of constraints on the project as early as
possible.
 Architects must identify & actively engage the stakeholders to
solicit their needs & expectations.
 Use architecture reviews & iterative prototyping.
 In addition to technical skills, architects need to be skilled in
diplomacy, negotiation, and communication.
9
 What Do Architectures Influence?
 Architectures affect the factors that influence them, including:
 The structure of the developing organization-Project context
 The goals of developing organization- Business context
 Customer requirements for the next system-Technical context
 The architect’s experience with subsequent systems-
Professional context.
 The software engineering culture.(i.e technical environment)

10
 Influences on the Architecture

11
 Software Processes & the ABC

 Software process is the term given to the organization,

ritualization, and management of software development
activities.
 Many activities are involved in creating software
architecture to realize design and then to implement or
manage the system.

12
 Software Architecture Activities
 Creating the business case for the system
 Understanding the requirements from stakeholders
 Creating or selecting the architecture via conceptual integrity
 Communicating the architecture clearly and unambiguously to
all of the stakeholders
 Analyzing or evaluating the qualities of the architecture
 Implementing the system based on the architecture faithfully
according to the structures and interaction protocols
constrained.
 Ensuring that the implementation conforms to the architecture
13
 What makes a Good Architecture?
 Given the same technical requirements for a system,
two different architects in two different
organizations, will produce different architectures.
 Then how to decide which is the right one ?
 Rules of thumb/observations that should be followed when
designing an architecture.
 These are divided into two clusters:
1. Process recommendations
2. Product(structural) recommendations.

14
 Rules of Thumb: Process recommendations
 The architecture should be product of a single architect or small
group of architects.
 gather both the functional requirements and a well specified,
prioritized list of quality attributes.
 be well documented, with at least one static view and one dynamic
view.
 be reviewed by the system’s stakeholders.
 be analyzed for applicable quantitative measures and formally
evaluated for quality measures.
 develop a “skeletal” system to facilitate incremental implementation.

15
 Rules of Thumb: Product recommendations
 The architecture should feature well-defined modules based on the
principles of information hiding and separation of concerns.
 Each module should have a well-defined interface that hides
changeable aspects.
 Quality attributes should be achieved using well-know architectural
tactics.
 The architecture should be independent of particular versions of
commercial products or tools.
 Modules that produce data should be separate from modules that
consume data for increased modifiability.

16
 What is Software Architecture?
 Quite often shown as box-and-arrow diagrams.

The system consists of four elements. An underwater acoustic simulation

• Three of the elements— Prop Loss Model
(MODP), Reverb Model (MODR), and
Noise Model (MODN)— might have more
in common with each other than with the
fourth—Control Process (CP) because
they are positioned next to each other.
• All of the elements apparently have some
sort of relationship with each other, since
the diagram is fully connected.
17
 What’s Missing?
 What is the nature of the elements?
 What are the responsibilities of the elements?
 What is the significance of the connections?
 What is the significance of the layout?

 Unless we know precisely what the elements are & how they
cooperate to accomplish the purpose of the system, this
diagram is unhelpful!

18
 Useful Concepts
 Three stages that capture characteristics of an architecture, on
the way from box-and-arrow to full software architectures:
 Architectural Patterns
 Reference Models
 Reference Architectures

Reference Model
Reference Software
Architecture Architecture
Architectural
Pattern

19
 Architectural Patterns
 A description of element & relation types together
with a set of constraints on how they may be used.
 These constraints on an architecture define a set or
family of architectures.
 For example, client-server is a common architectural
pattern.
 Client and server are two element types,
and their coordination is described in terms of the protocol
that the server uses to communicate with
each of its clients.

20
 Value of Patterns
 They exhibit known quality attributes, and are a reuse of
experience.
 Some patterns solve performance problems, others apply
to high-security systems, or high-availability goals.
 Choosing an architectural pattern is often the architect’s
first major design decision.
 Also referred to as architectural styles.

21
 Reference Models
 A division of functionality together with data flow between the
pieces.
 A standard decomposition of a known problem into parts that
cooperatively solve the problem.
 They arise from experience, and are thus a characteristic of
mature domains.
 Examples:
 Compilers: lexical analysis, syntactic analysis, semantic analysis,
optimization, code generation
 Networks: the OSI reference model

22
 Reference Architectures
 A reference model mapped onto software elements and the
data flows between them.
 The elements must cooperatively implement the
functionality defined in the reference model.
 A reference model defines a way of decomposing functionalities
 A reference architecture defines a way of mapping a functionalities on
subsystems/architectural components
 The mapping may be 1-1, but an element may implement a
part of a function or several functions.

23
 Structures and Views
 A view is a representation of a coherent set of architectural
elements, consisting of:
 a set of elements
 the relationships among them
 A structure is the set of elements itself, as they exist in
software or hardware.
 Often used interchangeably, text will distinguish.

24
 Why is Architecture Important?
 Three fundamental reasons from a technical perspective:
 Communication among stakeholders: a basis for mutual
understanding, negotiation, & consensus
 User: reliable and available
 Customer: on schedule and to budget;
 Manager: cost and schedule, teams to work largely
independently
 Architect: achieve all of those goals
 Early design decisions: earliest point at which decisions
can be analyzed
 Transferable abstraction of a system: can promote large-scale
25 reuse
 Early design decisions
 The architecture:
 defines constraints on implementation
 dictates organizational structure
 inhibits or enables a system’s quality attributes
 Predicting System Qualities by Studying the Architecture
 easier to reason about and manage change
 helps in evolutionary prototyping
 enables more accurate cost & schedule estimates

26
Architecture as a transferable reusable model
 The earlier in the life cycle re-use is applied, the greater the
benefit that can be achieved.
 Not only code can be re-used but so can the requirements that
led to the architecture in the first place, as well as the
experience of building the re-used architecture.
 When architectural decisions can be re-used across multiple
systems, all of the early decision consequences we just described
are also transferred.

27
 Groups of Architectural Structures
Architectural structures can by and large be divided into three
groups, depending on the broad nature of the elements they
show.
 Module structures: are static structures, in that they focus on the way the
system's functionality is divided up and assigned to implementation teams
 Eg. Decomposition, uses, layered, class
 Component-and-connector structures
 runtime components (principal units of computation) and connectors
(communication vehicles among components)
 Eg. Process (communication), concurrency, shared data (repository), client-
server
 Allocation structures: show relationships between software elements
& external environments (system's organizational, developmental, installation, and execution)
28
 Eg. Work assignment, deployment, implementation
 Three Types of Structures
 Correspond to the three broad types of decisions that
architectural design involves:
 How is the system to be structured as a set of code units
(modules?)
 How is the system to be structured as a set of elements that
have runtime behavior (components) and interactions
(connectors)?
 How is the system to relate to non-software structures in its
environment (i.e., CPUs, file systems, networks, development
teams, etc. - allocation)?

29
 Common software architecture structures

30
 Non-functional Properties
 Each structure provides a method for reasoning about some of
the relevant quality attributes, for example:
 the uses structure, must be engineered to build a system that
can be easily extended or contracted
 the process structure is engineered to eliminate deadlock and
reduce bottlenecks
 the module decomposition structure is engineered to produce
modifiable systems, etc.
 Each structure provides the architect with a different
view into the system & a different leverage point for
31 design.
 Three Kinds of Structures
Module :
• Decomposition: units are related by “is a sub module of ”, larger modules are
composed of smaller ones
• Uses: relation is “uses” (calls, passes information to, etc).
• Layered: is special case of uses, layer n can only use modules from layers <n
• Class: generalization, relation “inherits from”
Component :
• Process: units are processes, connected by communication or synchronization
• Concurrency: to determine opportunities for parallelism (connector = logical
thread)
• Shared data: shows how data is produced and consumed
• Client-server: cooperating clients and servers
Allocation :
• Deployment: how software is assigned to hardware elements
• Implementation: how software is mapped onto file structures
• Work assignment: who is doing what
32
 Useful module structures

 Decomposition structure:

33
 …Useful module structures

 Uses structure:

34
 …Useful module structures
 Layer structure:

35
 …Useful module structures

 Class (or generalization) structure:

36
 …Useful module structures

 Data model:

37
 …Useful module structures

 Module structures help answer questions:

 What is the primary functional responsibility assigned to each module?
 What other software elements is a module allowed to use?
 What other software does it actually use and depend on?
 What modules are related to other modules by generalization or
specialization (i.e., inheritance) relationships?
 Examining a system's module structures is an excellent way to
reason about a system's modifiability.

38
 Useful C&C structures
 Service structure:
 Units: services, ESB, registry
 Relations: runs concurrently with,
may run concurrently with,
excludes, precedes, etc.
 Used for: scheduling analysis,
performance analysis
 Affected attributes include:
Interoperability, modifiability

39
 …Useful C&C structures

40
 …Useful C&C structures
 C&C structures help answer questions:
 What are the major executing components and how do they interact at runtime?
 What are the major shared data stores?
 Which parts of the system are replicated?
 How does data progress through the system?
 What parts of the system can run in parallel?
 Can the system's structure change as it executes and, if so, how?
 They are crucially important for reasoning about the system's
runtime properties such as performance, security, availability.

41
 Useful allocation structures

 Deployment structure:

42
 …Useful allocation structures

 Implementation structure:
 Units: software elements
(usually modules), file structure
 Relations: stored in
 Used for: configuration control,
integration, test activities
 Affected attributes include:
development efficiency

43
 …Useful allocation structures

 Work assignment structure:

44
 …Useful allocation structures

 Allocation structures help answer questions:

 What processor does each software element execute on?
 In what directories or files is each element stored during development, testing, and
system building?
 What is the assignment of each software element to development teams?

45
 Relationship between structures

 Each of these structures provides a different perspective and design

handle on a system.
 They are not independent. Elements of one structure will be related to
elements of other structures.

46
 Relating Structures to Each Other

 Although the structures give different system perspectives,

they are not independent.
 Elements of one structure are related to elements in another,
and we need to reason about these relationships.
 For example, a module in a decomposition structure may map to one,
part of one, or several, components in a component-and-connector
structure at runtime.
 In general, mappings are many-many.

47
 Choosing Structures

 Kruchten’s Four + One Views:

 Logical View –concerned with the functionality that the system provides to
end-users. UML diagrams used to represent the logical view include, class
diagrams, and state diagrams.
 elements are “key abstractions” that are objects or classes in OO.
 This is a module view.
 Process View–deals with the dynamic aspects of the system, explains the system
processes and how they communicate, and focuses on the runtime behavior of the
system.
 addresses concurrency, distribution, integrators, performance, and scalability, etc.
UML diagrams to represent process view include the activity diagram.
 This is a C&C view.

48
 ... Four + One Views
 Development View – illustrates a system from a programmer's perspective and is
concerned with software management. This view is also known as the implementation
view. It uses the UML Component diagram to describe system components. UML
Diagrams used to represent the development view include the Package diagram
 shows organization of software modules, libraries, subsystems, and units of
development. This is an allocation view.
 Physical View – depicts the system from a system engineer's point of view. It is
concerned with the topology of software components on the physical layer as well as
the physical connections between these components. This view is also known as the
deployment view. UML diagrams used to represent the physical view include the
deployment diagram.
 maps other elements onto processing & communication nodes, also an allocation view,
but usually referred to specifically as the deployment view.

49
 ... Four + One Views
 Scenarios(One view)- The description of an architecture is
illustrated using a small set of use cases, or scenarios, which become
a fifth view.
 The scenarios describe sequences of interactions between objects
and between processes.
 They are used to identify architectural elements and to illustrate and
validate the architecture design. They also serve as a starting point
for tests of an architecture prototype.
 This view is also known as the use case view.

50
 ... 4+1 Architectural View Model

51
... 4+1 Architectural View Model: Example

52