Of Functionalities and Qualities. Possible History of a Silent Revolution in Software Design.
Throughout its history, software design has undergone a slow transformation that has redefined its meaning and practices and led to an ever-increasing valorization of software architecture.
One of the driving forces behind this change has been the recalibration of the weight given to functional aspects on the one hand, and non-functional or qualitative aspects on the other, both in terms of the role they play in a software system, and the possibilities they offer for description and analysis.
When we talk about functional aspects and quality aspects of a software system, we are guided by what is proposed by ISO 25010. In this, functional suitability is defined as: “the capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions.” Starting with this definition, we simplify by saying that the functional aspect describes what the system does and the quality attributes describe how well the system performs its tasks. In this sense, qualities can be considered attributes of the system, while functionalities express its purposes.
In the 1990s, functional aspects were considered predominant. Planning, analysis, design, implementation, testing, integration and maintenance: the phases of the lifecycle of a software system postulated in the previous decades were closely related to the functionalities that a software system must realize in order to satisfy the business and technical requirements of the customer. Qualitative attributes such as performance, resilience, security, stability, maintainability and testability, although obviously already known for their role played at systemic level, were seen as too vague and, in general, not very systematizable within the practices related to software design.
This was mainly due to the fact that these were qualities that were difficult to test, and their areas of relevance were perceived as partly co-extensive. In addition, they lacked an unambiguous vocabulary universally shared by the various professionals involved.
During the 2000s, the situation began to change, leading to a progressive downsizing of the weight given to functional aspects in architectural design, in favor of quality attributes. In this regard, Len Bass even proposes the abandonment of the term ‘functionality’ in favor of ‘responsibility’: “[For example,] if the function of the software is to control engine behavior, how can the function be correctly implemented without considering timing behavior? Is the ability to control access through requiring a user name/password combination not a function even though it is not the purpose of any system? (…) The achievement of qualities induces responsibility; think of the user name/password example just mentioned. Further, one can identify responsibilities as being associated with a particular set of requirements. So does this mean that the term “functional requirement” shouldn’t be used? People have an understanding of the term, but when precision is desired, we should talk about sets of specific responsibilities instead.” [Bachmann et al., 2010]
This progressive rebalancing is evident in the literature on the topic. Take, for example, the classic: “Software Architecture In Practice”, a scholarly text from SEI (Software Engineering Institute — Carnegie Mellon University), first published in 1998 and now in its third edition. If in its first edition of 1998 it dedicated only one chapter to quality attributes, already in the second edition of 2003 there were two chapters on this subject, to be finally ten in the last edition of 2013. [Bass et al., 2013]
This re-balancing has in turn led to other significant changes, such as the redefinition of software architecture itself. If in 2003 “Software Architecture in Practice” stated that: “The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them” [Bass et Al., 2003], in 2013 software architecture is simply defined as: “the set of structures needed to reason about the system, which comprise software elements, relationships among them, and properties of both.” [Bass et Al., 2003]
In my opinion, the evident disappearance of the expression “externally visible properties” is a clear indicator of the recognized and now unquestionable centrality assigned by the software designers community to the qualitative attributes of the system.
The same can be observed for the definition of behavior of an element. If previously: “the behavior of each element is part of the architecture as far as that behavior can be observed or discerned from the point of view of another element,” [Bass et Al., 2003] in the current edition it is preferred to say that: “The behavior of each element is part of the architecture insofar as that behavior can be used to reason about the system. This behavior embodies how elements interact with each other, which is clearly part of our definition of architecture.” [Bass et Al., 2013]
Browsing through another reference text, “Documenting Software Architectures: Views and Beyond,” we come across another exemplary and perhaps even more radical shift in meaning. It concerns the division of software design into two sub-categories: architectural and non-architectural design, where architectural design is interested in the software system as a whole, with particular attention to its qualitative attributes to be correlated to the responsibilities assumed by the business goals, while non-architectural design focuses instead on the ‘local’ aspects of the software system, which do not affect in a relevant way the qualitative attributes and purposes of the system.
Paul Clements states in this regard: “Architecture is design, but not all design is architectural. The architect draws the boundary between architectural and nonarchitectural design by making those decisions that need to be bound in order for the system to meet its development, behavioral, and quality goals. All other decisions can be left to downstream designers and implementers. Decisions are architectural or not, according to context. If structure is important to achieve your system’s goals, that structure is architectural. But designers of elements, or subsystems, that you assign may have to introduce structure of their own to meet their goals, in which case such structures are architectural: to them but not to you.” [Bass et Al., 2013]
In conclusion, the changes over the past few decades in the way we understand software design have been radical. But it is precisely this radicalness that testifies to the fact that today software design is a vital, necessary and indispensable phase in the professional development of software systems.
[Bass et Al., 1998] Bass, Len & Clements, Paul & Kazman, Rick. (1998). Software Architecture In Practice. First Edition.
[Bass et Al., 2003] Bass, Len & Clements, Paul & Kazman, Rick. (2003). Software Architecture In Practice. Second Edition.
[Bass et Al., 2013] Bass, Len & Clements, Paul & Kazman, Rick. (2013). Software Architecture In Practice. Third Edition.
[Bachmann et al., 2010] Bachmann, Felix & Bass, Len & Clements, Paul & Garlan, David & Ivers, James & Little, M. & Merson, Paulo & Nord, Robert & Stafford, Judith. (2010). Documenting Software Architectures: Views and Beyond. Second Edition.
