Skip to content Skip to navigation

Connexions

You are here: Home » Content » Software Architecture Documentation

Navigation

Recently Viewed

This feature requires Javascript to be enabled.
 

Software Architecture Documentation

Module by: Guilherme Germoglio. E-mail the author

Summary: The objective of this chapter is to teach the reader how to document software architectures.

Note: You are viewing an old version of this document. The latest version is available here.

!!!! PLACEHOLDER FOR A CHAPTER ON SOFTWARE ARCHITECTURE DOCUMENTATION !!!!!

Objectives

By the end of this chapter, the reader must be able to:

  • Identify what architectural decisions are;
  • Categorize architectural decisions;
  • Understand that architectural decisions relate to each other and how they relate to each other;
  • Understand what architectural views are;
  • Understand the benefits of exhibiting a software architecture many views;
  • Understand what architectural viewpoints are;
  • Identify basic architectural viewpoints;
  • Categorize architectural views according to architectural viewpoints;
  • Relate the stakeholders' interests to architectural views;
  • Understand what architectural patterns are and what are their benefits;
  • Understand the relation between fulfilling non-functional requirements and applying architectural patterns;
  • Recognize fundamental architectural patterns; and
  • Apply architectural patterns in order to fulfill basic non-functional requirements.

After understanding the core concepts on software architecture, the reader is ready to learn how to document it. Concepts of views and viewtypes are introduced. This chapter may be notation agnostic, since languages come and go. However, examples using current languages may be wanted. The chapter's messages are:

  1. Each piece of information placed on an architecture is an architectural decision [4], [3].
  2. An architectural decision can be an existence decision.
  3. An architectural decision can be a property decision.
  4. An architectural decision can be an executive decision.
  5. An architectural decision can constrain another decision.
  6. An architectural decision can forbid another decision.
  7. An architectural decision can enable another decision.
  8. An architectural decision can subsume another decision.
  9. An architectural decision can conflict with another decision.
  10. An architectural decision can override another decision.
  11. An architectural decision can comprise another decision.
  12. An architectural decision can be and alternative to another decision.
  13. An architectural decision can be bound to another decision.
  14. An architectural decision can depend on another decision.
  15. A single diagram may not suffice the amount of information intended to be shown by an architect. So, it is essential the use of multiple views of the information [5], [2].
  16. There are three basic viewtypes: modules, component-and-connectors, and allocation, each of which with their own elements, relations, and styles [1].
  17. Modules viewtype is used for construction, since it can be considered the blueprint for the source code.
  18. Modules viewtype is used for analysis, specifically for requirement traceability and for impact analysis.
  19. Modules viewtype is used for communication, since it explains functionality by its parts.
  20. Component-and-connectors viewtype is used for reasoning about runtime system quality attributes.
  21. Allocation viewtype is used for analysis of performance, reliability, security and cost estimation.

References

  1. Clements, Paul and Bachmann, Felix and Bass, Len and Garlan, David and Ivers, James and Little, Reed and Nord, Robert and Stafford, Judith. (2002, September). Documenting Software Architectures: Views and Beyond. Addison-Wesley Professional.
  2. IEEE, and ISO/IEC,. (2007, July). Systems and Software Engineering - Recommended Practice for Architectural Description of Software-Intensive Systems. ISO/IEC 42010 IEEE Std 1471-2000 First edition 2007-07-15, c1–24.
  3. Kruchten, Philippe and Lago, Patricia and van Vliet, Hans. (2006). Building Up and Reasoning About Architectural Knowledge. In Quality of Software Architectures. (p. 43–58).
  4. Kruchten, Philippe and Lago, Patricia and van Vliet, Hans and Wolf, Timo. (2005). Building up and Exploiting Architectural Knowledge. In WICSA '05: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). (p. 291–292). Washington, DC, USA: IEEE Computer Society.
  5. Kruchten, P. B. (1995). The 4+1 View Model of architecture. Software, IEEE, 12(6), 42–50.

Content actions

Download module as:

PDF | More downloads ...

Add module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks