Defining software architecture
Post date: Jan 29, 2019 8:36:15 PM
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.
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.
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
May impact choice of tools/ technologies/ solution (time to market, budget…)
Tradeoff: time to market, non functional requirements
Avoid as much as possible
Tradeoff between time to market and lock-in
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
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:
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
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:
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.
[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:
[adapted from: C. Hofmeister et al. Applied Software Architecture]
It talks about following views points
It also talks about 9 views:
Use case view
Non functional requirement view
User experience view
[Source: https://slideplayer.com/slide/5793448/ ]
[Adapted from: D. Norris. Communicating Complex Architectures with UML and the Rational ADS]
Component and connector 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.
(Views and beyond SEI CMU Template for SAD)
(Comparison of Views & beyond template and ANSI-IEEE 1471-2000)
(Documenting Software Architecture in an Agile world)
(Architecture frameworks table listing various frameworks)
Blown out TOGAF 7 diagram
To corelate where does Software Engineering Diagrams fit in to EA as per TOGAF please see this url:
To learn examples for Togaf modeling this site has interesting stuff:
Togaf diagrams at visual paradigm: