Software architectural model: Difference between revisions

Revision as of 15:15, 7 January 2015

Latest revision as of 01:13, 28 May 2025

(32 intermediate revisions by 25 users not shown)

Line 2:

{{Multiple issues|

{{tone|date=November 2011}}

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

{{More citations needed|date=February 2025}}

}}

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 rich and rigorous diagram, created using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem{{Citation needed|date=June 2014}}. [[Software architect]]s use architectural models to communicate with others and seek peer feedback. An architectural model is an expression of a viewpoint in software architecture{{Citation needed|date=June 2014}}.

Some key elements in a software architectural model areinclude:{{Citation needed|date=June 2014}}

*'''richRich''': forFor the viewpoint in question, there should be sufficient information to describe the area in detail. The information should not be lacking or vague. The goal is to minimize misunderstandings, not perpetuate them. See notes below on 'primary concern.'

* '''rigorousRigorous''': theThe architect has applied a specific methodology to create this particular model, and the resulting model 'looks' a particular way. Here's theA test of rigorousness: Ifmay state that if two architects, in different cities, were describing the same thing, the resulting diagrams would be nearly identical (with the possible exception of visual layout, to a point).

* '''diagramDiagram''': inIn general, a model may refer to ''any'' abstraction that simplifies something for the sake of addressing a particular viewpoint. This definition specifically subclasses 'architectural models' to the subset of model descriptions that are represented as diagrams.

*'''standardsStandards''': standardsStandards work when everyone knows them and everyone uses them. This allows a level of communication that cannot be achieved when each diagram is substantially different from another.[[Unified Modeling Language]](UML) is the most often quoted standard.

* '''primaryPrimary concernConcern''': itIt 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 soextremely rich in content that it requires a two-year course of study to understand it. 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 don'tensure just say: it's a floor plan so 100% ofthat the information thatprovided CANis goonly onwhat ais floorneeded. planFor shouldexample, be put there. Thea plumbing subcontractor doesn'tdoes not need the details that thean electrician careswould need to aboutknow.

* '''illustrateIllustrate''': theThe 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, and (b)
*# guide their work.
* '''Rule of thumb:''' know what it is you want to say, and whose work you intend to influence with it.

* '''specificSpecific setSet of tradeoffsTradeoffs''': theThe [[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 'one-size-fits-design for all' designoccasions. WePeople can create a generic design, but then wethey need to alter it to specific situations based on the business requirements. In effect, wepeople make tradeoffs. The diagram should make those specific tradeoffs visible. Therefore, before an architect creates a diagram, he or shethey should be prepared to describe, in words, which tradeoffs they are attempting to illustrate in this model.

* '''tradeoffsTradeoffs inherentInherent in the structureStructure and designDesign''': aA component is not a tradeoff. Tradeoffs rarely translate into an image on the diagram. Tradeoffs are the first principles that producedproduce the design models. When an architect wishes to describe or defend a particular tradeoff, the diagram can be used to defend the position.

* '''systemSystem or ecosystemEcosystem''': modelingModeling in general can be done at different levels of abstraction. It is useful to model the architecture of a specific application, complete with components and interactions. It is also reasonable to model the systems of applications needed to deliver a complete business process (like order-to-cash). It is not commonly useful, however, to view the model of a single component and its classes as software architecture. At that level, the model, while valuable in its own right, illustrates design much more so than architecture.

==See also==

*[[Service-oriented modeling]] framework (SOMF)

==References==

Line 24 ⟶ 31:

==External links==

* [http://www.sei.cmu.edu/architecture/start/definitions.cfm SEI published Software Architecture Definitions] contains a list of definitions of architecture used by classic and modern authors.

* [http://www.csi.uottawa.ca:4321/oose/index.html#architecturalmodel Architectural Model] contains a definition of an architectural model from the University of Ottawa's Object Oriented Software engineeringEngineering database.

* [http://www.sei.cmu.edu/architecture/tools/atam/ Architectural Tradeoff Analysis Method] (ATAM) is a method by which architecture can be evaluated for suitability and fit to requirements.

[[Category:Software architecture|model]]

==See also==

[[Category:Software design patterns]]

*[[Service-oriented modeling]] framework (SOMF)

[[Category:Software development]]

[[Category:Software architecture]]