Applied Software Architecture

Quality attributes, scenarios, tactics

Four Views to Software Architecture

Code view

Many files, many kind of files Object code, binary code Multiple versions

Configuration management

Organisation of these affect the reusability of code and the build time of the system

Four Views to Software Architecture cont

Module view

The design of individual classes or procedures is too fine grained to be considered part of the software architecture design But the decomposition of the system and the partitioning of modules into layers is!

Four Views to Software Architecture cont

Execution view

The dynamic aspect How to map functional components to runtime entities? How to handle communication, coordination and synchronisation among components?

Four Views to Software Architecture cont

Conceptual view

Describes the system in terms of its major design elements and the relation among them Usually tied closely to the application domain Can be used to specify the software architecture of a system with some attributes to guide the mappings of the other views

Conceptual view

Identify the conceptual components and connectors Problems and solutions are viewed primarily in domain terms

But independently of particular software and hardware techniques

Conceptual view cont

Engineering concerns addressed:

How does to system fulfill the requirements? How are COST components integrated and how do they interact with the rest of the system? How is domain-specific hardware and/or software incorporated into the system? How is functionality partitioned into product releases? How does the system incorporate the products prior generations and support future generations? How can the impact of changes in requirements be minimised?

Module view

Conceptual components and connectors are mapped to subsystems and modules The architect addresses how the conceptual solution is realised with todays software platforms and technologies

Module view cont

Engineering concerns addressed:

How is the product mapped on to the software platform? What system support/services does it use and where? How can testing be supported? How can dependencies between modules be minimised? How can reuse of modules and subsystems be maximised? How to insulate the product from changes in COST software, in software platform, standards?

Execution view

Map the modules to the elements of the runtime platform Defines the systems runtime entities including their attributes

Memory usage, hardware assignment,

Flow of control from the point of the runtime platform

Execution view cont

Engineering concerns addressed:

How does the system meet its performance, recovery and reconfiguration requirements? How can one balance resource usage?

Load balancing?

How to achieve concurrency, replication, distribution without too much additional complexity in control? How to minimise the impact of changes in the runtime platform?

Code view

Map the runtime entities from the execution view to deployment components (e.g. executables) Map modules from the module view to source components Determine how the deployment components are produced from source components

Code view cont

Engineering concerns addressed:

How can the time and effort for product apgrades be reduced? How should product versions and releases be managed? How can build time be reduced? What tools are needed to support the development environment? How are integration and testing supported?

Using the views

Gives a systematic way of designing a software architecture Gives guidance in Tracing influencing factors and requirements through the architecture Sequencing design activities Making design trade-offs Supporting system-specific qualities like performance or reliability Supporting general qualities like buildability, portability, testability, reusability Ensuring that no aspects of the architecture are overlooked Producing documentation

Design tasks

Global analysis Central design tasks

Global evaluation task Resource budgeting Interface definition

Final design tasks

Global analysis

Identify the external influencing factors and critical requirements that could affect the architecture Analyse them to come up with strategies for designing the architecture If all cannot be satisfied, decide which has priority, renegotiate a requirement, or change some external factor to come up with workable strategies

Global analysis cont

Influencing factors

Organisational factors

Development schedule, budget Organisational attitudes, software process Available hardware and software technology

Technological factors

Product factors

Performance, depemdability, cost May be different in future versions

Global analysis cont

Many factors affect the entire system

Strategis should address global concerns, but provide guidance for implementing them locally

Occurs throughout the design

New factors, issues or strategies can arise at any time Might be contradictiong Sort out conflicts and resolve them

Consider factors as a group

Global analysis cont

Complements the risk analysis and/or requirements analysis Requirements and risk analyses might give the anlysed factors

Then develop strategies to the design

Provides a systematc wayof identiying, accomodating and describing the affecting factors

Global analysis cont

Analysing factors

Take as input the organisational, technological and product factors

Make them explicit Step 1: Identify and describe the factors Step 2: Characterise the flexibility or the changeability of the factors Step3: Analyse the impact of the factors

Three (3) step procedure

Step 1: Identify and describe the factors

Can the factors influence be localised to one component or not? During which stages of development is the factr important? Does the factor require any new expertise or skills?

Step 2: Characterise the flexibility or the changeability of the factors

Flexibility Is it possible to influence or change the factor so that it makes your task of architecture development easier? In what way can you influence it? To what extent can you influnce it? Changeability In what way could the factor change? How likely will it change during or after development? How often will it change? Will the factor be affected by changes in the other

Step3: Analyse the impact of the factors

If a factor was to change, which of the following would be affected and how:

Other factors Components Modes of operation of the system Other design decisions

Global analysis cont

Develop strategies

Three (3) steps procedure

Step 1: Identify issues and influencing factors Step 2: Develop solutions and specific strategies Step 3: Identify related strategies

Step 1: Identify issues and influencing factors

Idetify a handful of important issues that are influenced by the factor and their chageability

Limitations or constraints imposed by factors

Aggressive developemnt schedule

A need to reduce the impact of changeability of factors

Design for portability High throughput req. may overload CPU Error handling and recovery

Difficulty in satisfying product factors

A common solution to global requirements

Step 2: Develop solutions and specific strategies

For each issue, develop strategies that address the issue and ensure the implementation changeability of the architecture design

Reduce or localise the factors influence Reduce the impact of the factors changeability on the design and other factors Reduce or localise required aread of expertise or skills Reduce overall time and effort

Step 3: Identify related strategies

When a strategy belongs with more than one issue, dont repeat the strategy

Global Analysis Summary

Consider three kinds of influencing factors

Organisational factors

Constrain design choises Embedded or embodied in the product Functional features and qualities of the product

Technological factors

Product factors

Global Analysis Summary cont

At the end of architecture design you will have

Characterised the important influencing factors and Developed strategies for ensuring

Buildability Implementation changeability

IS2000: The Advanced Imaging Solution

IS2000 key marketing features Has a user-friendly operator environment Has a comprehensive catalog of built-in acquisiion procedues The user can define custom acquisition procedues Throughput of image acquisition 50% higher than before Image display as fast as the max. hardware spreed User defined trade-off between speed and image quality Designed for easy upgrade Open platform connectivity Can be connected to prnters, digital images,