1

Architectural Descriptions

Lecture 6

2

References

• Chapter 12: Architectural Description Languages from Software Architectures in Practice.

• IEEE Recommended Practice for Architectural Description of Software Intensive Systems.

• Architectural Blueprints-The 4+1 View Model of Software Architecture by Philippe Kruchten. Available from www.rational.com/media/whitepapers/Pbk4p1.pdf

3

Classical Architectural Descriptions

• Largely represented by box and line drawings.

• Nature of components, their properties, semantics of connections and overall behavior of the systems is reflected poorly.

• Offer an intuitive view of system’s constructions but fail to identify,– Components, their behavior and their associations

with other components.– Differentiation between runtime and compile time

abstractions.– Nature of connections.

4

Architectural Description Languages (ADLs)

• A linguistic approach to formal representation of architectures.

• Address the shortcomings of informal representations.

• Sophisticated ADLs allow for early analysis and feasibility testing of architectural design decisions.

5

Advantages of ADL

• Architectures allow– Mutual Communication.– Embodiment of early design decisions suitable for

analysis.– Transferable abstractions of a system.

• These issues are better served if a standard notation for describing and representing architectures exists.

6

Advantages of ADL (Contd…)

• Standardized and formal architectural description languages allow:– Enhanced communication between architect and

other stakeholders. – Analysis of early design decisions.– Enable tools to be built to assist in development.– Construction of artifacts that are transferable to

subsequent systems.

7

What are ADLs

• ADLs differ from requirement languages because ADLs describe solution space.

• ADLs differ from programming languages as latter bind all architectural abstractions to specific point solutions.

• ADLs differ from modeling languages as latter are more concerned with the behavior of the whole rather than of the parts.

• ADLs provide abstractions, structures and analysis capabilities that are clearly architectural in nature.

8

Minimal Requirements for ADL

• Suitability to communicate architecture to all stake holders.

• Support for representation of static and dynamic structures.

• Support for representation of components and connectors.

• Support for creation, refinement and validation of architecture. This should include mechanisms to test completeness and consistency of the architecture.

9

Minimal Requirements for ADL (Contd…)

• Support for the representation of most common architectural styles.

• Support for structures that express architectural information while suppressing implementation or non-architectural information.

• Support for further development by adding information to ADL specification to enable the final system specification to be derived from ADL.

10

Minimal Requirements for ADL (Contd…)

• If the language can express implementation level information it must contain capabilities for matching more than one implementation to the architectural level structures of the system.

• Support for either an analytical capability based on architectural level information or a capability for quickly generating prototype implementations.

11

Using the Object Oriented Notation for Architectural Description

• Advantages:– Familiarity to developers.– Close mapping to implementation. – Commercial tool support.

• Considerations in using an object oriented notation for an architectural notation.– A graphical language for visualizing,

constructing,specifying and documenting the artifacts of a software intensive system.

– Support for multiple structural and behavioral views of the system.

12

Using the Object Oriented Notation for Architectural Description (Contd…)

• Considerations in using an object oriented notation for an architectural notation (Contd…)

– Support for stylistic constraints.– Support for connectors and interfaces as first class

entities.– Support for hierarchical structures.

13

IEEE-1471

• IEEE Recommended Practice for Architectural Description of Software Intensive Systems.

• Scope of the recommendation includes architectural descriptions allowing– Expression of the system and its evolution.– Communication among stake holders.– Evaluation and comparison of architectures in a

consistent manner.– Planning, managing and executing the activities of

system development.

14

IEEE- 1471 (Contd…)

• Scope of the recommendation includes architectural descriptions allowing (Contd…),– Expression of the persistent characteristics and

supporting principles of a system to guide acceptable change.

– Verification of a system implementation’s compliance with an architectural description.

– Recording contributions to the body of knowledge of software intensive systems architecture.

15

Architectural Description as Specified in IEEE-1471

• Every system has an architecture.

• An architecture can be recorded by an architectural description.

• Architecture of a system is a conceptual entity distinguished from particular descriptions of that architecture.

• Architectural descriptions are considered concrete products or artifacts.

16

Architectural Description as specified in IEEE-1471 (Contd…)

• An architectural description is organized into one or more constituents called views.

• Each view addresses one or more of the concerns of system stakeholders.

• View is used to refer to the expression of a system’s architecture with respect to a particular viewpoint.

17

Architectural Description as specified in IEEE-1471 (Contd…)

• A viewpoint establishes the conventions by which a view is created, depicted and analyzed,– A view conforms to a viewpoint.– The viewpoint determines the languages (including

notations models, or product types ) to be used to describe a view.

– Any associated modeling method or analysis technique to be applied to these representations of the view.

18

Architectural Description as specified in IEEE-1471 (Contd…)

• An architectural description selects one or more viewpoints for use.

• A viewpoint defined else where is referred to as library viewpoint.

• A view may consist of one or more architectural models.

• Each architectural model is developed using the methods established by its associated architectural viewpoints.

• An architectural model may participate in more than one view.

19

20

4+1 View Model of Software Architecture

• Description of a software architecture using several concurrent views each addressing one specific set of concerns.

• Architectures made up of five main view– Logical view: Describes the object model of system.– Process view: Describes the concurrency and

synchronization aspects of the system.– Physical view: Describes the mapping(s) of the software

onto the hardware and reflects its distributed aspects.– Development view: Describes the static organisation of

the software in its development environment.– Scenarios: Functionality illustrated by selected use-

cases.

21

The 4+1 View Model

Logical ViewDevelopment

View

Process View Physical View

Scenarios

End-user Functionality

ProgrammersSoftware Management

IntegratorsPerformanceScalability

System EngineersTopology

Communications

22

The 4+1 View Model(Contd.)

• Perry & Wolfe’s equation applied independently on each view,– Software Architecture = {Elements, Forms,

Rationale/Constraints}

• For each view, a set of elements are to be defined.

• Forms and patterns are described.

23

• Rationale and constraints connecting an architecture to requirements are captured.

• Each view is described by a blueprint in its own particular notation.

• For each view, architects can pick a certain architectural style, allowing the coexistence of multiple styles in one system.

The 4+1 View Model(Contd.)

24

The Logical Architecture

• Primarily supports the functional requirements.

• The system is decomposed into a set of key abstractions taken mostly from the problem domain.

• The abstractions as recorded in the form of objects and object classes.

25

The Logical Architecture(Contd.)

• Key relationships between abstractions are highlighted, i.e., – Encapsulation, – Abstraction,– Inheritance.

• Main guideline – Maintenance of a single coherent object model

across the whole system. – Avoidance of premature specialisation of classes

and mechanisms per site or per processor.

26

The Process Architecture• Takes into account non-functional

requirements, e.g., performance, availability.• Addresses issues of

– Concurrency and distribution,– System’s integrity,– Fault tolerance,– Manner in which main abstractions of logical view fit

within the process architecture.

• Typical styles for the process view– Pipe and filter,– Client server.

27

The Development Architecture• Focuses on the actual software module

organisation on the software development environment.

• The software is packaged into manageable chunks, e.g., program libraries or subsystems, that can be developed by one or a small number of developers.

• A layered style is used for the development model.

• RULE: Not to allow layer bridging to maintain simplicity.

28

The Physical Architecture• Focuses on non-functional requirements, e.g.,

– Availability,– Reliability or fault tolerance,– Performance or throughput,– Scalability.

• Software executes on a network of computers or processing nodes.

• Various elements identified earlier, i.e., objects, processes, etc., are to be mapped onto the various nodes.

29

Scenarios

• Scenarios show the elements of the other four views to work together seamlessly.

• Scenarios are abstractions of most important requirements.

• Design of scenarios is expressed using the object scenario diagrams and object interaction diagrams.

• The view is redundant with other views for– Discovering architectural elements,– Validation, illustration and demonstration.