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.


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.


[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]

  • 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 view

  • Domain view

  • Test view


[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

https://www.nasa.gov/pdf/637608main_day_2-david_garlan.pdf

https://biking.michael-simons.eu/docs/index.html

https://github.com/arc42

https://docs.arc42.org/home/

https://arc42.org/overview/

https://arc42.org/download

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/

http://www.iso-architecture.org/42010/templates/

https://resources.sei.cmu.edu/asset_files/TechnicalNote/2005_004_001_14498.pdf

(Comparison of Views & beyond template and ANSI-IEEE 1471-2000)

https://resources.sei.cmu.edu/asset_files/TechnicalNote/2003_004_001_14171.pdf

(Documenting Software Architecture in an Agile world)

http://www.iso-architecture.org/42010/cm/

(Conceptual model))

http://www.iso-architecture.org/42010/afs/

http://www.iso-architecture.org/42010/afs/frameworks-table.html

(Architecture frameworks table listing various frameworks)

Blown out TOGAF 7 diagram

https://i0.wp.com/tephramiriamcommunications.com/wp-content/uploads/2016/01/blowout.gif?ssl=1

https://slideplayer.com/slide/4267592/


To corelate where does Software Engineering Diagrams fit in to EA as per TOGAF please see this url:

https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap31.html

To learn examples for Togaf modeling this site has interesting stuff:

https://www.togaf-modeling.org/

Togaf diagrams at visual paradigm:

https://circle.visual-paradigm.com/docs/togaf-adm-guide-through/phase-c-information-systems-architectures/how-to-develop-architecture-definition-document/

http://metasun.blogspot.com/2018/02/togaf-diagram-examples.html