Software Architecture Session2

SOFTWARE ARCHITECTURE

Session - 2

What is Software Architecture?

• Quite often shown as box-and-arrow diagrams.

Control Process

(CP)

Figure 2.1

01:43 PM 2SEPS ZG651 Software Architectures

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!


Definition Again

• The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, an the relationships between them.

• We see the elements (CP, MODP, MODR, MODN), but what properties do they or their relationships have?


Externally Visible Properties

• The assumptions that other elements can make of an element, such as:– its provided services, – performance characteristics, – fault handling, – shared resource usage, – etc.


Definition Implications

1 - architecture defines software elements.2 - systems can and do comprise more than one

structure, all are part of the architecture.3 - every computing system with software has an

architecture.4 - the behavior of each element is part of the

architecture as far as its behavior can be observed or discerned from the point of view of another element.

5 - the definition doesn’t judge goodness or badness.

01:43 PM SEPS ZG651 Software Architectures 6

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

ArchitecturalPattern

ReferenceArchitecture

Software Architecture

Figure 2.2

Source : Bass, Clements, and Kazman. Software Architecture in Practice,

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,

• the client-server pattern has 2 element types (?); • their relationship is a protocol that the server uses to

communicate with each of its clients, the clients don’t communicate directly. Functionality is excluded.


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.

• Often the architect’s first major design decision.• Also referred to as architectural styles.


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.– For example, the standard parts of a compiler or

database management system & how they work together.


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.

• The mapping may be 1-1, but an element may implement a part of a function or several functions.


Why is Architecture Important?

• Three fundamental reasons from a technical perspective:– Communication among stakeholders

• a basis for mutual understanding, negotiation, & consensus

– Early design decisions• earliest point at which decisions can be analyzed

– Transferable abstraction of a system• can promote large-scale reuse


Early design decisions

• The architecture:– defines constraints on implementation– dictates organizational structure– inhibits or enables a system’s quality attributes

• some details on next slide, more on p. 30– studying it can predict system qualities– easier to reason about and manage change– helps in evolutionary prototyping– enables more accurate cost & schedule estimates


Quality Attributes

High performance Manage the time-based behavior of elements; the frequency & volume of inter-element communication

Scalability Carefully localize the use of resources to facilitate the introduction of high-capacity replacements

Deliver incremental subsets Carefully manage inter-component usage

Re-usable elements Restrict inter-element couplings so an extraction doesn’t have too many environment attachments to be useful


Architecture: a Transferable, Reusable Model• The earlier in the lifecycle re-use is applied, the

greater the benefit.– Software Product Lines share a common architecture.– Composing with large, externally developed elements.– Restrict the vocabulary of design alternatives: patterns.– Architecture permits template-based development.– Used as the basis for training.


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.


Groups of Architectural Structures

• Module structures– units of implementation with assigned areas of

functionality - usually static

• Component-and-connector structures– runtime components (principal units of computation) and

connectors (communication vehicles)

• Allocation structures– show relationships between software elements &

external environments (creation or execution)


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


Figure 2-3



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.


Value of Structures

• Each structure provides the architect with a different view into the system & a different leverage point for design.

• Table 2.1 on page 39-40 should be useful in your class project...



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.


Choosing Structures

• Kruchten’s Four + One Views:– Logical - elements are “key abstractions” that are objects

or classes in OO. This is a module view.– Process - addresses concurrency & distribution of

functionality. This is a C&C view.– Development - shows organization of software modules,

libraries, subsystems, and units of development. This is an allocation view.

– Physical - maps other elements onto processing & communication nodes, also an allocation view, but usually referred to specifically as the deployment view.


Quick Exercise

• Read “Architecture Deja Vu” on pages 43-45.• What do you think? Do you agree or disagree?

Why?


Summary

