Home‎ > ‎Architecture‎ > ‎Defining‎ > ‎

Defining software architecture

posted Jan 29, 2019, 12:36 PM by Jageshwar Tripathi   [ updated Jun 29, 2020, 9:03 AM ]
Following basic principles are applied to define software architecture:
1. Identify drivers
The drivers can be functional requirements, quality requirements, constraints (e.g. expected schedule)
2. Define the strategy
Approach to structure software is identified. Use of architectural styles and patterns helps structuring the architecture.
3. Tradeoff analysis
Identify how the quality attributes will be achieved with use of strategies. Tradeoff analysis should be performed to prioritize quality attributes. 

Architect's priorities

There are various aspects an architect has to consider and find architecture fulfilling drivers and satisfying various aspects. There may be completing requirements and others drivers due to which an architect may have to prioritize them to take his decisions. Sometimes available solutions, products or services may support need of one driver but may not fulfill other and in this case an architect should consider following order to define the solution or select a solution. 

Functional requirements

Build versus buy decisions 

(may be impacted by constraints like time to market)

Choice of product, tools and technology

Non functional requirements

QoS, Compliance etc

Trade-off

Constraints

May impact choice of tools/ technologies/ solution (time to market, budget…)

Cost optimization

Tradeoff: time to market, non functional requirements

Vendor lock-in 

Avoid as much as possible

Tradeoff between time to market and lock-in 


Architectural decisions

To define the architecture, an architect has to take several decisions to achieve what is defined in drivers (functional and non functional requirements/quality keeping in mind any constraints to address). These decisions may help defining the strategy. There may be several options available and an architect may have to chose/decide one among them. Similarly there may be competing requirements and an architect may have to take decision using trade off analysis. Various methods of architecture define how to take those decisions. Some focus on quality attributes and tactics to achieve those quality attributes, some other model focuses on drivers and defining various views to achieve/define those drivers. 

Attribute Driven Design (ADD) [ SEI CMU ]

This method focuses on applying tactics and patters to find out solution of problem (requirement), There requirements are captured as quality attributes. 

Quality attributes>Tactics & Patterns

Siemens’ 4 Views (S4V) 

  • Drivers: functional requirements, desired system qualities, organizational constraints, and technical constraints
  • Derive views from analysis of above
  • Views: conceptual, execution, module, and code

RUP

  • Drivers: architecturally significant use cases, nonfunctional requirements, and risks
  • Derive technical decisions to achieve above
  • Technical decisions are architecture

Documenting software architecture

There can be different ways to define software architecture and one of the way is to use view point model. View point models consider different stakeholders and their concerns or perspectives and suggest to describe software architecture through various views. 
There are couple of models, few of them are listed bellow:
  • C4 Model
  • 4+1 Model (initially published by Philippe Kruchten)
  • Siemens Four View model
  • Software Engineering Institute (SEI) set of views
  • ISO Reference Model of Open Distributed Processing (RM-O)
  • Rational Architecture Description Specification

C4 Model

It starts with person (stakeholder) who has interest in the system. Then models Context level system. After that zoom-in to Container level mode following by Component and Code level. 
Following are the levels:

Context

Containers

Components

Code


4+1 Model


It talks about five main views. One this to keep in mind is that the notation proposed at the time of its publication was not UML. Booch notations were used to describe different elements.  
4+1 View

[Adapted from: P. Kruchten. Architectural Blueprints - The “4+1”View Model of Software Architecture]

The logical view

Objects of the system. (if an object-oriented design method is adopted)

The process view

Considers how concurrency and synchronization will be taken care.

The physical view

How software will be deployed to the hardware and reflects its distributed aspect.

The development view

How software looks like in development.  How developers see various parts of the software while developing it. Primary stakeholders of this view are developers. 

Siemens Four View model

It talks about following views:

Siemens 4 views
[adapted from: 
C. Hofmeister et al. Applied Software Architecture]

Conceptual view

Code view

Execution view

Module view

Rational ADS

It talks about following views points

Requirements viewpoint

Design viewpoint

Realization viewpoint

Verification viewpoint

It also talks about 9 views:

Use case view

Logical view

Process view

Implementation view

Deployment view

Non functional requirement view

User experience viewpoint

Domain view

Test view

Rational ADS
[Source: https://slideplayer.com/slide/5793448/ ]
[Adapted from: D. Norris. Communicating Complex Architectures with UML and the Rational ADS]

SEI Views

Module view

Component and connector views

Allocation view

4+2 views

Along with 4+1 views, it considers another view which is called control case view. This is a way of modeling non functional requirements. 

Design view (Vocabulary functionality)

Implementation view (System assembly, configuration management)

Process view (Concurrency, synchronization)

Deployment view (Distribution, delivery, installation, system topology)

Use case view (Behavior)

Control case view (Quality constraints)

Use case view operates under certain operating conditions. operating conditions are controlled by a control case. 

Interesting resources

A Survey of Software Architecture Viewpoint Models:
A general model of software architecture design derived from five industrial approaches:
https://www.dimap.ufrn.br/~thais/MES20072/SoftwareArchitecturalGeneralModel.pdf
https://www.nasa.gov/pdf/637608main_day_2-david_garlan.pdf
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=513862
(Views and beyond SEI CMU Template for SAD)
http://www.iso-architecture.org/42010/
(Comparison of Views & beyond template and ANSI-IEEE 1471-2000)
(Documenting Software Architecture in an Agile world)
(Conceptual model))
(Architecture frameworks table listing various frameworks)
Book documenting software views and beyond
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.460.7189&rep=rep1&type=pdf

Comments