Software architectural model: Difference between revisions

Revision as of 10:40, 31 July 2024

Latest revision as of 01:13, 28 May 2025

(9 intermediate revisions by 4 users not shown)

Line 2:

{{Multiple issues|

{{tone|date=November 2011}}

{{nomore footnotes needed|date=April 2009}}

{{UnreferencedMore citations needed|date=JuneFebruary 20222025}}

}}

An '''architectural model''' (in [[software]]) contains several diagrams representing static properties or dynamic (behavioral) properties of the software under design.<ref>{{Citation |last=Hasselbring |first=Wilhelm |title=Software Architecture: Past, Present, Future |date=2018 |work=The Essence of Software Engineering |pages=169–184 |url=https://doi.org/10.1007/978-3-319-73897-0_10 |access-date=2025-02-10 |place=Cham |publisher=Springer International Publishing |doi=10.1007/978-3-319-73897-0_10 |isbn=978-3-319-73896-3|url-access=subscription }}</ref><ref>{{Cite web |title=About the Unified Modeling Language Specification Version 2.5.1 |url=https://www.omg.org/spec/UML/2.5.1/About-UML |access-date=2025-02-10 |website=www.omg.org}}</ref><ref>{{Cite book |last1=Hilliard |first1=Rich |last2=Malavolta |first2=Ivano |last3=Muccini |first3=Henry |last4=Pelliccione |first4=Patrizio |chapter=On the Composition and Reuse of Viewpoints across Architecture Frameworks |date=August 2012 |title=2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture |chapter-url=https://doi.org/10.1109/wicsa-ecsa.212.21 |publisher=IEEE |pages=131–140 |doi=10.1109/wicsa-ecsa.212.21|isbn=978-1-4673-2809-8 }}</ref> The diagrams represent different [[4+1 architectural view model|viewpoints]] of the system at the appropriate scope of analysis. The diagrams are created by using available standards in which the primary aim is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. [[Software architect]]s utilize architectural models to facilitate communication and obtain peer feedback.

An '''architectural model''' (in [[software]]) is a diagram created by using available standards in which the primary aim is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. [[Software architect]]s utilize architectural models to facilitate communication and obtain peer feedback.

Some key elements in a software architectural model include:

Line 16:

* '''Primary Concern''': It is easy to be too detailed by including many different needs in a single diagram. This should be avoided. It is better to draw multiple diagrams, one for each viewpoint, than to draw a 'mega diagram' that is extremely rich in content. Remember this: when building houses, the architect delivers many different diagrams. Each is used differently. Frequently the final package of plans will include diagrams with the floor plan many times: framing plan, electrical plan, heating plan, plumbing, etc. They ensure that the information provided is only what is needed. For example, a plumbing subcontractor does not need the details that an electrician would need to know.

* '''Illustrate''': The idea behind creating a model is to communicate and seek valuable feedback. The goal of the diagram should be to answer a specific question and to share that answer with others to:

* a)# see if they agree

* b)# guide their work.
* '''Rule of thumb:''' know what it is you want to say, and whose work you intend to influence with it.

* '''Specific Set of Tradeoffs''': The [[architecture tradeoff analysis method]] (ATAM) methodology describes a process whereby software architecture can be peer-reviewed for appropriateness. ATAM does this by starting with a basic notion: there is no such thing as a design for all occasions. People can create a generic design, but then they need to alter it to specific situations based on the business requirements. In effect, people make tradeoffs. The diagram should make those specific tradeoffs visible. Therefore, before an architect creates a diagram, they should be prepared to describe, in words, which tradeoffs they are attempting to illustrate in this model.

* '''Tradeoffs Inherent in the Structure and Design''': A component is not a tradeoff. Tradeoffs rarely translate into an image on the diagram. Tradeoffs are the first principles that produce the design models. When an architect wishes to describe or defend a particular tradeoff, the diagram can be used to defend the position.

Line 36 ⟶ 37:

[[Category:Software design patterns]]

[[Category:Software development]]

{{software-eng-stub}}