MODEL-BASED SOFTWARE ARCHITECTURES

Models of software are used in an increasing number of projects to handle the complexity of application domains.

By applying models for the specification of software application domain specific knowledge is separated from technological specific knowledge.

While models can be applied in different phases of a software development process, research projects in the Model-based software architectures group are looking at the following application of models:

Generative approaches for tackling problems in the research area of software product lines

Interpreting approaches to enable software architectures for Mobile Grid (and Cloud) Computing

MODEL-BASED SOFTWARE ARCHITECTURES

An architecture is the software system design. The ultimate goal of the engineering stage is to converge

on a stable architecture baseline. An architecture baseline is not a paper document, it is a

collection of information across all the engineering sets. Architectures are described by extracting the essential

information from the design models. Software architecture is the central design problem of a

complex software system. However, like a architecture of a large building, the

critical performance attributes and features of a complex software system cannot be described through stable laws of physics.

Lacking established theory, software architects must rely on some form of experimentation in formulating software architectures.

This is one of the main reasons for transitioning to an iterative process, in which early activities emphasize and promote architecture evolution through prototyping and demonstration.

In today’s complex software systems, we have evolved to multiple, distinct models and views to exploit the advantages of modern technologies.

A model is a relatively independent abstraction of a system.

A view is a subset of a model that abstracts a specific, relevant perspective.

Architecture: A Management Perspective

Architecture includes the infrastructure, control, and data interfaces that permit software components to cooperate as a system and software designers to cooperate efficiently.

If a software development team is to be successful, the interproject communication, as captured in the software architecture, must be both accurate and precise.

From a management perspective, there are three different aspects of an architecture:

1. An architecture (the intangible design concept) is the design of a software system, as opposed to the design of a component.

2. An architecture baseline (the tangible artifacts) is a slice of information across the engineering artifact sets sufficient to satisfy all stakeholders that the vision can be achieved within the parameters of the business case.

3. An architecture description is an organized subset of information extracted from the design set model(s).

The number of views and the level of detail in each view can vary widely.

Similarly, the architecture of the software for an air traffic control system is very different from the software architecture of a small development tool.

The Importance of s/w architecture and its close linkage with modern s/w development processes

•Achieving a stable s/w architecture represents a significant project milestone at which the critical make/buy decisions should have been resolved.

•Architecture representations provide a basis for balancing the trade-offs between the problem space and the solution space.

•The architecture and process encapsulate many of the important communications among individuals, teams, organizations, and stakeholders.

•Poor architectures and immature processes are often given as reasons for project failures.

•A mature process, an understanding of the primary requirements, and a demonstrable architecture are important prerequisites for predictable planning.

•Architecture development and process definition are the intellectual steps that map the problem to a solution without violating the constraints, they require human innovation and cannot be automated.

Architecture: A technical Perspective (Krutchen, 1995)

Software architecture encompasses the structure of software systems, their behavior, and the patterns that guide these elements, their collaboration, and their composition.

The context of s/w architecture structure, behavior, and patterns must include functionality, performance, resilience, comprehensibility, economic trade-offs, technology constraints and aesthetic concerns.

An architecture framework is defined in terms of views that are abstractions of the UML models in the design set.

An architecture view is an abstraction of the design model; it contains only the architecturally significant information.

FOUR VIEWS

Design: Describes architecturally significant structures and functions of the design model.

Process: Describes concurrency and control thread relationships among the design, component, and deployment views.

Component: Describes the structure of the implementation set.

Deployment: Describes the structure of the deployment set.

Architecture, an organized and abstracted view into the design models

DVUCV PV CV Depl

V

DMUVM PM CM Depl

M

REQ DES IMPL DEPL

Depending on its complexity, a system may require several models or partitions of a single model

An architecture is described through several views, which are extracts of design models that capture the significant structures, collaborations, & behaviors

The requirements set may include UML models describing the problem space

The design set includes all UML design models describing the solution space.

The design, process, and use case models provide for visualization of the logical and behavioral aspects of the design.

The component model provides for visualization of the implementation set.

The deployment model provides for visualization of the deployment set.

Architecture Description Document

Design View, Process View, Use Case View

Component View, Deployment View

Other views (optional)

Other material:

Rationale, constraints

Generally, an architecture baseline should include the following:

Requirements: critical use cases, system-level quality objectives, and priority relationships among features and qualities

Design: Names, attributes, structures, behaviors, groupings, and relationships of significant classes and components

Implementation: Source components inventory and bill of materials of all primitive components

Deployment: Executable components sufficient to demonstrate the critical use cases and the risk associated with achieving the system qualities.

An architecture baseline is defined as a balanced subset of information across all sets, whereas an architecture description is completely encapsulated within the design set.

The architecture description will take a wide range of forms, from a simple, direct subset of UML diagrams to a complex set of models with a variety of distinct views that capture and compartmentalize the concerns of a sophisticated system.