1

Introduction to Software Architectures

Lecture - 3

2

References

• Chapter – 1: The Architectural Business Cycle from Software Architecture in Practice.

• Chapter – 2: What is Software Architecture from Software Architecture in Practice.

3

What are Software Architectures?• Software architectures address issues related

to the development of large software systems.

• A software architecture is an abstract view of a system that distills away details of implementa-tion, algorithms and data structures.

• A software architecture concentrates on the behaviour and interaction of blackbox components.

• An architecture is developed as a first step towards designing a system with a collection of desired properties.

4

Definition

The software architecture of a program or a computing system is the structure or structures of the system which comprise software components, external visible properties of these components and the relationships among these components.

5

Elaboration of Definition• Externally Visible Properties

– Assumptions other components can make of a particular component.

– Should be sufficient information to be a basis for analysis, decision making and risk reduction.

• Components and Relationships– Interaction between components.– Public artifacts of components are manipulated.– Private artifacts define internal implementation and

are not of architectural significance.

6

Elaboration of Definition (Contd.)

• Representation Through Multiple Structures– Indicates presence of

• Multiple different kinds components• Multiple different kinds of interactions• Different contexts

• Behaviour of each component is a part of the architecture.– Behaviour defines component interaction.– Behaviour and performance of every component

must be documented to the extent that it explains how component behaviour influences the system.

7

Impact of Software Architectures

• Describes the earliest artifacts in development that allow the priorities among competing concerns to be analysed.

• Typically influenced by– Customers and end users.– Developing organisation.– Background and expertise of architects.– Technical environment.

8

Impact of Software Architectures (Contd.)

• An architectural exercise affects the factors influencing it. It affects, – Structure of developing organisation and project

teams.– Enterprise goals of the developing organisation.– Customer’s requirements for the next system.– Architect’s experience for subsequent systems via

the process of construction.– Technical environment.

9

Architecture-Based Process Steps

• Create a business case for the system.

• Understand requirements.

• Create or select an architecture.

• Represent and communicate the architecture.

• Analyse and evaluate the architecture.

• Implement the system based on the architecture.

• Ensure that the implementation conforms to the architecture.

10

Architecture Development Heuristics

• Process Recommendations– A small team of architects with a leader.– The team should have technical requirements and a

prioritised list of qualitative properties of the system.– Architecture should be documented using an

agreed notation understandable to all stakeholders.– The architecture should be well circulated.– The architecture should be analysed for applicable

quantitative measures and formally reviewed for qualitative properties.

11

Architecture Development Heuristics (Contd.)

• Process Recommendations (Contd.)

– The architecture should lend itself to implementation via a skeletal system with minimal functionality.

– The architecture should result in a specific set of resource contention areas, resolution of which should be clearly specified, circulated and maintained.

12

Architecture Development Heuristics (Contd.)

• Product/Structural Recommendations– Based on well-defined modules envisaged on

information hiding and separation of concerns.– Allow concurrent and incremental development.– Encapsulation to facilitate change.– Independence from specific commercial

products.– Producer consumer separation at module level.

13

Architecture Development Heuristics (Contd.)

• Product/Structural Recommendations (Contd.)

– Well defined tasks for concurrent systems not typically mirroring modular structure.

– Tasks assignment to processors should be changeable possibly at runtime.

– The architecture should feature a small set of simple interaction patterns.

14

“If a project has not achieved a system architecture, including its rationale, the project should not proceed to full scale system development.

Specifying the architecture as a deliverable enables its use throughout the development and maintenance process.”

Boehm[95]

15

Architectural Styles

• High-level description of component types, a pattern of their runtime control and data transfer.

• A set of constraints on components and their patterns of interaction thereby defining a set or family of architectures satisfying them, e.g., client server style.

• An architectural style is not architecture.

16

Architectural Reference Model

• A division of functionality together with data flow between components.

• A standard decomposition of a known problem into functional parts cooperatively solving the problem.

• These are characteristics of mature domains and are often obtained through domain analysis

17

Reference Architecture

• Reference model mapped onto software components and the data flows between these components.

• These components cooperatively implement the functionality defined in the reference model.

• There may not be one-to-one correspondence between functionality and components.

18

Note:-

Reference models, architectural styles and reference architectures are not architectures but useful steps towards architectures.

ReferenceModel

ArchitecturalStyles

ReferenceArchitecture

SoftwareArchitecture

19

Application of Software Architecture

• Communication with stakeholders– Architectures provide a common language in

which different concerns can be expressed, negotiated and resolved at a level that is intellectually manageable even for large complex systems.

20

Application of Software Architecture(Contd.)

• Early design decisions– Constraints on implementation.– Dictates organisational structures.– Inhibits or enables a system’s quality attributes.– Predicts system qualities.– Makes it easier to reason about and manage

change.• Local, non-local and architectural changes.

– Helps in evolutionary prototyping.

21

Application of Software Architecture(Contd.)

• Transferable abstractions of a system.– Reuse at architectural level allows reuse of

requirements, design and code.– Sharing of common architecture among product

families (domain specific architectures).– Building systems using large externally developed

components.• Resolution of architectural mismatch a key issue.

– Restricting vocabulary of design alternatives.– Permits template based component development.– Used as a basis for training.

22

Architectural Structures

• Software systems exhibit different structures.

• A single structure to describe an overall system generally results in ambiguity.

• Different structures used to describe system characteristics, e.g.,– Functionality– Physical distribution– Interprocess communication– Synchronisation

23

Structures for Software Architectures

• Module structures

• Conceptual or logical structures

• Process or coordination structures

• Physical structures

• Uses structures

• Calls structures

• Control flow structures

• Class structures

24

Module Structure

• Structural units are work assignments.

• Units linked by is-a-submodule-of relation.

• Used to allocate resources during development and in subsequent support.

• Often results in a hierarchy of modules.

25

Conceptual or Logical Structure

• Structural units are abstractions of system’s functional requirements.

• Links between units specify shares-data-with relationship.

• Useful for understanding the interactions between entities in problem space and their variation.

26

Process Structure or Coordination Structure

• Provides a view that is orthogonal to module and conceptual views.

• Deals with the dynamic aspects of an executing system.

• Structural units are processes or threads.• Links between structural units represent

relations concerning process synchronisation and concurrency.

27

Physical Structure• Provides a view of software mapping onto the

hardware.

• Useful in the development of distributed and parallel systems.

• Structural units are components and hardware entities.

• Links represent communication pathways exhibiting a communicates-with relationship.

• Allows developers to evaluate performance, availability and security.

28

Uses Structure

• Structural units are procedures or modules.

• Links represent assumes-the-correct-presence-of relation.

• Used to engineer systems that can be easily extended such as using an incremental build approach to integration.

29

Calls Structure

• Structural units are procedures and sub-procedures.

• Links represent the call or invocation relation.

• Used to trace flow of execution in program.

30

Data Flow Structure

• Structural units are programs or modules.

• Links represent may-send-data-to relationship.

• Links are labeled with the name of the data transmitted.

• Considered appropriate for requirements traceability.

31

Control Flow Structure

• Structural units are programs, modules or system states.

• Links represent becomes-active-after relationship.

• Useful for verifying the functional behaviour and the timing properties of the system.

• If the only mechanism for transferring control is a program/procedure call, this becomes identical to call structure.

32

Class Structures

• Structural units are objects and classes.

• Links represent the following relationships– Is-a-kind-of– Is-a-part-of– Is-an-instance-of

• Supports reasoning about collection of similar behaviour and parameterised differences between classes.

• Functional enhancements based on object aggregation and composition is supported.

33

Relating Structures

• Different types of structures provide a different perspective and design handle on a system.

• Conceptual and module structures define static properties.

• Process and physical structures define the dynamic or runtime characteristics.

34

Relating Structures(Contd.)

• Although structures provide different perspectives, they are not independent.

• Not all systems warrant multiple architectural structures.

• Multiple structures prove beneficial in managing complexities of large systems.