Since its early days, the activity of
defining software architectures has evolved to a common software engineering
practice, whose foundations nowadays rely on widely adopted concepts. The
definition and adoption of these concepts took place over multiple decades, one
of the first serious works about software architecture being published in the
year 1974 by David Parnas.
This article relates the evolution of the software architecture practice since its first days and how today’s commonly used concepts have been defined.
General concepts
In 2000, the IEEE adopted the IEEE
1471-2000 standard for the architectural description of software systems. This
standard is now known as ISO 42010:2007, and has been updated in 2011 to ISO
42010:2011.
The ISO 42010 standard proposes (ISO 42010,
2011, pp. 1-2) widely accepted definitions for various concepts related to the
documentation of software systems architecture.
Definition: Architecture of a systemThe architecture of a system is the set of “fundamental concepts or properties of a system in its environment, embodied in its elements, relationships, and in the principles of its design and evolution.” (ISO 42010, 2011, p. 2)
Bass, Clements, and Kazman (2013) define
the architecture of a software system: “The software architecture of a
system is the set of structures needed to reason about the system, which comprise
software elements, relations among them, and properties of both”
(Bass et al., 2013, p. 4). Compared to
the definition of the standard ISO 42010, this definition emphasizes the
utility of the architecture think globally about the system: documenting software
architecture only makes sense if the documentation is actually used to reason
about the architecture.
Other definitions exist, nevertheless the
definitions provided by the ISO 42010 and Bass et al. (2013) remain valid in
project using agile methods or spiral lifecycle methods, where the expression
of requirements and therefore the definition of the architecture takes place
during the whole lifetime of the project or iteratively.
Definition: Architecture descriptionAn architecture description is the “work product to express an architecture” (ISO 42010, 2011, p. 2).
Generally speaking, an architecture
description is used to express the properties of an architecture: ISO 42010
does not determine the contents of the architecture description.
Definition: Architecture frameworkAn architecture framework is the set of “conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders” (ISO 42010, 2011, p. 2).
According to ISO 42010 (2011, p. 9), an
architecture framework establishes a common practice for the creation, the
interpretation, the analysis and the usage of architecture descriptions in a
specific application domain or by a specific stakeholder community.
The definition process of an architecture framework consists of defining the conventions, principles and practices which will be applied when describing an architecture.
History
It’s in the year 1974 that David Parnas
noted that software systems are composed of many structures, and modelled a
software system as the set of its parts and their inter-relationships (Parnas,
2000).
In 1992, Perry DeWayne and Alexander Wolf
recognize the need for various views
of a system (Perry & Wolf, 1992).
Definition: Architecture viewAn architecture view is a “work product expressing the architecture of a system from the perspective of specific system concerns” (ISO 42010, 2011, p. 2).
In other words, an architectural view
expresses the architecture of a system according to a perspective related to
specific responsibilities of the system. Each architectural view of a system
tries to describe a specific set of issues of the system. The definition given
by ISO 42010 emphasizes the fact that an architectural view describes a
specific set of issues, in contrary to the definition of Clements et al. (2011,
p. 22) who stipulates: “A view is a representation of a set of system elements and
the relationships associated with them”. The fundamental utility
of views relies on the fact that it is very difficult to capture the whole set
of properties of an architecture in its description. The documentation of views
helps focus the effort on the essential features of a system’s architecture.
The concept of architectural view having
been introduced, it becomes important to find out which architectural views are
relevant in the description of a system’s architecture.
In 1995, Philippe Kruchten wrote an article
describing four main views of software systems architecture: logical, process, development, physical. A fifth view links these four
views by showing how they satisfy the key use cases. This 4+1 approach constitutes the fundaments of the well-known Rational
Unified Process (RUP) method (Kruchten 1995).
Note: The logical view represents the functional structures of the system, the process view represents the concurrency and synchronization aspects of the system, the development view represents the modules, sub-systems, layers and issues directly related to the development, and finally the physical view identifies the nodes on which the system will be executed and the relationship of other architectural elements to these nodes (Rozanski & Woods, 2012, pp. 621-622).It’s also in 1995 that Soni, Nord and Hofmeier define the Siemens Four View model for architecture, which contains the views conceptual, module interconnection, execution, code (Bass et al., 2013, p. 24). This model is noteworthy because it presents viewpoints in a precise and concrete manner, with more details than a simple digest of the information that a viewpoint must contain.
The concept of viewpoint has been, since 1995, a fundamental concept in the field software systems architecture descriptions.
In 2000, IEEE 1471-2000 recommends defining the architectural views
which best serve and address the concerns of the stakeholders of the described
system, but does not define a fixed set of architectural views, as such sets are
very specific to the system and its stakeholders.
IEEE 1471-2000 used the concept of
viewpoint, which was kept by the ISO 42010:2007 standard and then later adapted
by the ISO 42010:2011 standard:
Definition: Architectural viewpointA viewpoint is “a work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns” (ISO 42010, 2011, p. 2).
Note: It is Ross who introduced in 1977 the concept of viewpoint as an essential concept for the first time in his article Structured Analysis (SA): a language for communicating ideas, (ISO 42010, 2011, p. 21). It’s only twenty years later that this concept begins to be widely used, to the point of being reused in various standards.
A viewpoint describes the form and type of contents that a view must provide. The description of an architectural view must therefore match the specification given by the corresponding viewpoint. One may think of the architectural viewpoint as the contract which must be fulfilled by the architect when he or she documents an architectural view and which helps stakeholder understand and interpret this view.
In practice, a viewpoint may define a
template which will be used by the architect to describe the corresponding
view.
Various other view sets have been defined
thereafter, amongst which the one defined by Rozanski and Woods (2012), which
suggests to use the viewpoints context,
functional, information, concurrency,
development, deployment, operational
and the use of the main architectural perspectives security, performance and scalability,
availability and resilience, evolution
(amongst other perspectives).
In 2002, the Software Engineering Institute
(SEI) introduces the approach Views and
Beyond. This approach begins by identifying the suitable architectural
styles for the system being designed, followed by their application on the
system, which results in an architectural view for each identified style. This
approach defines three style categories, also name viewtypes: component and
connector, module, allocation. The concept of viewtype matches ISO 42010’s concept of viewpoint. An architectural style
defines how a specific architectural structure must be documented.
In 2005, Rozanski and Woods (2011) have
defined the concept of architectural perspective:
Definition: Architectural perspectiveAn architectural perspective is a collection of architectural activities, tactics and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’s architectural views.” (Rozanski & Woods, 2012, p. 47).
According to Rozanski
and Woods (2012, p. 47), the concept of architectural perspective is
transversal to the concepts of views and viewpoints: the application of a
perspective on the various architectural views ensures that a software system
actually exhibits its desired qualities. The standard ISO 42010 does not define
an equivalent concept to the one of architectural perspective, but proposes to
reuse the models shared by multiple views to express architectural perspectives
(ISO 42010, 2011, p. 14).
The issues addressed
by the architectural perspectives are often called non-functional requirements or cross-cutting
concerns.
The required quality
properties of a system’s architecture are rarely expressed by functional
requirements. For the architect, it is appropriate to determine, with the
stakeholders, which quality properties the system must exhibit. These quality
properties are often influenced by a small amount of requirements, which are
often of non-functional nature.
Note: In practice, it’s easy to develop a feature in many ways, using different concepts and technologies. Yet the desired quality properties of a software system will only be present if its design is appropriate: therein lies the whole problem of software systems architecture.
In 2003, Bass et al. (2013, p. 306) proposed to use a utility tree to
determine the architecturally significant requirements and to determine their
business value as well their impact on the architecture.
Definition: Architecturally significant requirement (ASR)An architecturally significant requirement (ASR) is a requirement that will have a profound effect on the architecture that is, the architecture might well be dramatically different in the absence of such a requirement.” (Rozanski & Woods, 2012, p. 291)
Figure 1: Example of a utility tree. Note that a utility tree may contain
more quality properties whose use really depends on the system being
considered.
At the center of the
utility tree lies the root node Utility.
This node is then detailed, by connecting it to main quality properties (portability, function, reliability, usability, efficiency and maintainability). Each of these nodes is also
connected to more detailed quality properties. Then, each of these quality
properties is connected to the expression of one or more ASRs. Each ASR is
labeled with an indicator of its business value and with its impact on the
architecture.
Conclusion
To me, the key rules
in software architecture documentation are the following
- Architecturally significant requirements (ASRs) must be identified and must always be considered in every step of your design and documentation;
- It is not possible to describe a system completely;
- It is not necessary to describe a system completely.
So it is essential to identify the system's
stakeholders, to identify their needs and to stick to these needs. They should be the only actual drivers in your
software architecture documentation practice.
These needs may be
captured and documented into templates (the viewpoints), which will later be
used to create the views of the system (remember, the viewpoint defines what
must be documented in a view). In a specific environment, the viewpoints almost
remain the same for all systems (obviously, they only change with the
stakeholders and their needs).
If you are interested
in architecture, have a look at the references used to write this article as
well as to the TOGAF framework (http://www.togaf.org), which is an enterprise architecture
framework, but which also clearly depicts the steps to take when building an
architecture capability in an organization, including a software architecture
capability.
References
- Bass, L., Clements, P., & Kazman, R. (2013). Software architecture in practice (3rd ed. ; Software Engineering Institute, Carnegie Mellon, Ed.). Boston, USA : Pearson Education, Inc.
- Clements, P., Bachman, F., Bass, L., Garlan, D., Ivers, J., Little, R., . . . Staffort, J. (2011). Documenting software architectures : views and beyond (2nd ed. ; Software Engineering Institute, Carnegie Mellon, Ed.). Boston, USA: Pearson Education, Inc.
- IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (Norm No IEEE Std 1471-2000). (2000). The Institute of Electrical and Electronics Engineer, Inc., New-York, USA.
- Kruchten, P. B. (1995). The 4+1 view model of architecture. IEEE SOFTWARE, 12, 42–50.
- Parnas, D. L. (2001). Software fundamentals : collected papers by David L. Parnas. In D. M. Hoffman & D. M. Weiss (Eds.), (pp. 139–148). Boston, MA, USA : Addison-Wesley Longman Publishing Co., Inc.
- Rozanski, N., & Woods, E. (2012). Software systems architecture : working with stakeholders using viewpoints and perspectives (2nd ed.). USA : Pearson Education, Inc.
- Systems and software engineering - Architecture description (Norm No ISO/IEC/IEEE 42010). (2011). International Organization for Standardization, Geneva, Switzerland, The Institute of Electrical and Electronics Engineer, Inc., New-York, USA.
- Perry, D. E., & Wolf, A. L. (1992, October). Foundations for the study of software architecture. SIGSOFT Softw. Eng. Notes, 17(4), 40–52. Consulted on http://doi.acm.org/10.1145/141874.141884 doi : 10.1145/141874.141884
Interesting links
- The Open Group Architecture Framework (TOGAF): http://www.togaf.org
- Software Engineering Institute (SEI): http://www.sei.cmu.edu/
- View and Beyond, SEI: http://www.sei.cmu.edu/architecture/tools/document/viewsandbeyond.cfm?location=quaternary-nav&source=651943
- Viewpoints & perspectives: http://www.viewpoints-and-perspectives.info/
- RUP best practices : http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
No comments:
Post a Comment