Agile Architecture Method Explained - Chapter 8 - Communicating Your Architecture

From Guidance Share

Revision as of 00:58, 13 December 2008; JD (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

- J.D. Meier , Alex Homer, David Hill, Jason Taylor , Prashant Bansode , Lonnie Wall, Rob Boucher Jr, Akshay Bogawat.


After your architecture design is complete, you must communicate the design to the other stakeholders. These stakeholders will include the development team, system administrators and operators, business owners, and other interested parties. There are several well-known methods for describing architecture to others, including the following:

  • 4+1. This approach uses five views of the complete architecture. Four of the views describe the architecture from different approaches: the logical view (such as the object model), the process view (such as concurrency and synchronization aspects), and the physical view (the map of the software layers and functions onto the distributed hardware infrastructure), and the development view. A fifth view shows the scenarios and use cases for the software. This allows stakeholders to see the specific aspects of the architecture that specifically interest them.
  • ADL. Architecture Description Language (ADL) is used to describe software architecture prior to system implementation. It addresses the following concerns: behavior, protocol, and connector. Behavior corresponds to the types, hierarchies, properties, and rules. Protocol corresponds to the communicating entities and rules. Connector corresponds to the connections, interface, and constraints that exist between components in an object-oriented system. It is designed to be both human- and machine-readable. Therefore, ADL has both the textual form and a formally defined syntactic and semantic form. The main advantage of ADL is that you can analyze the architecture for completeness, consistency, ambiguity, and performance before formally beginning use of the design.
  • Agile Modeling. Agile Modeling follows the concept that "content is more important than representation". This ensures that the models created are simple and easy to understand, sufficiently accurate, detailed, and consistent. Agile model documents target specific customer(s) and fulfill the work efforts of that customer. Each agile model document is designed to fulfill a specific purpose, and the way it is expressed can vary. A class diagram, problem statement, Use Case diagram, sequence flow, and other approaches can be used to express an agile model document. The simplicity in the document ensures that there is active participation of stakeholders in the modeling of the artifact.
  • IEEE (1471). IEEE 1471 is the short name for a standard formally known as ANSI/IEEE 1471-2000, "Recommended Practice for Architecture Description of Software-Intensive Systems". IEEE 1471 enhances the content of an architectural description, in particular giving specific meaning to context, views and viewpoints. Context corresponds to the stakeholders of the system (such as clients and vendors) and their specific concerns (such as reliability and security). The view corresponds to the system concerns and the viewpoint corresponds to conditions on the completeness, well-formedness, and analyzability of views. IEEE 1471 allows the document to be formulated using existing ADLs or from within the framework it provides. IEEE 1471 also allows UML diagrams to be used as viewpoints.
  • UML. Unified Modeling Language (UML) represents three views of a system model. The functional requirements view (functional requirements of the system from the point of view of the user, including use cases); the static structural view (objects, attributes, relationships, and operations including class diagrams; and the dynamic behavior view (collaboration among objects and changes to the internal state of objects, including includes sequence, activity and state diagrams).
Personal tools