Software Engineering Matters

Functionality and quality attributes are orthogonal. I like this phrase. As the chapter claims, this is a bold statement but at the same time it makes sense. Ensuring that software exhibits all the required functionality does not guarantee that it has any of the quality attributes. It may very well work as intended but it might be abysmally slow and just plain hard to maintain in the future. In fact, it can a big ball of mud with everything built-in.

So, why is it important to understand quality attributes? Software quality attributes help shape the system. As mentioned above, it would be trivial to construct software that meets all the functionalities but fail miserably. No one might want to use it, developers might detest maintaining it and it might probably is not reliable. Understanding quality attributes help shape the architecture of the system by giving priorities to the qualities that must be achieved. By emphasizing the importance of quality from day one, the architecture will be more robust and appeal to developers and stakeholders alike.

This chapter presents three kinds of quality attributes that a "good" system needs to take into consideration: qualities of the system, business qualities and the quality of the architecture itself. The three kinds of qualities influence one another and it is impossible to fulfill one set while completely ignoring the other.

Maintainability, availability and modifiability are some of the qualities of the systems that we usually consider. Qualities of the system are hard to qualify. For instance, maintainability as defined by the Software Engineering Institute (SEI) is: "the ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment". This definition alone does not help developers check if the system at hand possesses that quality. What this chapter proposes is to use quality attribute scenarios to help characterize the qualities that we are seeking. These scenarios will be real cases that the system will encounter and has to react to.

Here is a picture to illustrate what a scenario looks like. The terms used are pretty broad and it is easy to have an idea what they mean.

Basically, we can model a scenario for each quality attribute that we are interested in by identifying the source, the stimulus to the system, which part of the system is affect, the response from the system and the by measuring the response of the system. And we keep a copy of all these models at hand.

While scenarios definitely do not capture everything, having them around gives concrete instance of situations that the system has to handle gracefully. With enough scenarios, we will have a pretty good idea of the requirements that our architecture must fulfill. Consider what would happen instead if we did not have scenarios to model the qualities that we seek. It would be impossible to determine what we mean when we say that we want ensure "portability" in our system. How much "portability" do we mean? What kind of "portability" are we trying to achieve?

However, one point this chapter does not address is how we would make use of those scenarios effectively to ensure that our architecture enforces those qualities. Now that we have all these scenarios, what is the best way to apply them? Should we consider by the attributes they represent or should we tackle them as a whole?

A more interesting kind of quality attribute presented in this chapter is system quality attributes that deal with the architecture itself. Conceptual integrity is mentioned as a desired quality for the architecture. The architecture should do similar things in similar ways. It reminds me of the metaphor that developers strive to achieve in the Extreme Programming software process. Good architectures are supposed to possess this conceptual integrity since it means that everything is operating under the guise of the principle of least surprise: there is a proper place for everything and there is a intuitive way of doing something.

What Software Architecture Is and What It Isn't

The software architecture of a program or computing system is the structure of structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

The definition above fits well with the other definitions that we have seen so far especially the one from Garlan and Shaw's Introduction to Software Architecure. However, there are some subtle yet distinctive points about this particular definitions:

• Systems can consists of more than one structure.
  For large systems, there can be many structures. And not one of them is the software architecture for the system. As we have seen in the 4+1 paper by Krutchen, there can be indeed different views for the same architecture with each view contributing toward a different structure.
• All computing systems have a software architecture
  Even if the architecture is a Big Ball of Mud. It might not be describable, but an architecture definitely exists. And the definition does not discriminate against bad or good architecture.

Three useful terms are defined in the book that will be pivotal to the discussion of software architecture:

• An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used.
  It's interesting to note that this chapter considers client-server as an architectural pattern and not a software architecture. In this book, the term architectural pattern is synonymous with architectural style. I suppose that the patterns describe in Patterns of Enterprise Application Architecture would fit this category. The original 23 design patterns from the Gang of Four might fit in here as well though some of them are pretty low-level and does not address the system as a whole.
• A reference model is a division of functionality together with data flow between the pieces
  A reference model is an abstraction of how the system should function. For me, I think of it as a metaphor for the system. For instance, if I want to represent an XML document, I might conceptually think of it as a tree since all the nodes can be nested within one another. So to actually use an XML document, I will need a reader, writer and some internal representation. That is the conceptual idea I have of a an application that uses XML. I do not have a definite design or implementation for the reader, writer or the internal representation yet.
• A reference architecture is a reference model mapped onto software elements and the data flows between them.
  It simpler terms, it tries to connect the architectural pattern and the reference model. Once you have that mapping (the reference architecture) you are in a better position to actually solve the problem at hand. For instance, to solve a database problem, I can relate my database schema to the Active Record pattern.

Here is a picture to make things clearer.

So why do we need software architecture? Krutchen already discuss how it gives a representation of the state of the software to the stakeholders. And in Chapter 1, we saw how an architecture helps stakeholders make decisions about the future stage of the software development.

Furthermore, software architecture is also important because it's the earlier manifestation of the design decisions that go into the software. With this software architecture, developers have a better sense on how to organize the structure of software, how to handle changes and how to proceed in the next iteration. Though at the early stage, this manifestation is most probably incomplete and even inadequate, the software architecture serves as an early model for which to base future cost and schedule estimation.

Another importance of software architecture as given by the book is the fact that it is a transferable abstraction of the system. While this is definitely possible, I would argue that architectural patterns (defined above) are more transferable than software architecture because in a software architecture the parts are more detailed and concrete already. As can be seen from figure 1 above, software architecture is the product of the reference architecture stage. As you recall, the reference architecture stage provides the mapping between the abstract architectural patterns and the reference model. Therefore, I believe that some level of abstraction has been lost. Instead, I think that the software architecture might provide a good example of the use of the architectural pattern. But the architectural pattern is the high-level description that should be shared amongst developers.

This chapter also proposes some alternative views for representing software architecture in contrast to Kruchen's 4+1 view. These forms of representations become increasingly important as systems grow more complex. It is no longer possible to represent the entire architecture with just one diagram. By using multiple diagrams, each structure of the software architecture becomes clearer. It becomes easier to identify the important elements for each structure.

The next reading assignments come from the book Software Architecture in Practice (SAIP). Whenever future posts are based on this book, I shall prepend the acronym SAIP to the title.

The Swedish Ship Vasa (p. 4 of SAIP):

Faced with an impossible task, Hybertsson had the good sense to die about a year before the ship was finished.

One interesting (maybe even fairly obvious) point is that project requirements alone do not determine the architecture of the system. Think of it. Given the same set of requirements, no two developers would go out and develop with the same architecture in mind. And yet many software projects fail simply because all focus has been placed solely on the requirements. By placing all faith on the requirements alone, all other aspects tend to be neglected.

Instead, this book proposes that a software architecture is the result of technical, business and social influences. Moreover, just as these three factors influence the software architecture, the software architecture also affects the technical, business and social environments. This chapter of the book has not yet defined architecture, but we may just use the definitions that we have covered in my previous posts.

For instance, the architect has to take into consideration the resources that his organization can provide. The organization might have a limited pool of programmers to spare for the project. Therefore, the architect might have to choose a particular tool, programming language and architecture that the programmers are familiar with.

Moreover, the experience of the architect himself also plays a great role in determining the architecture of the system. If the architect suffered from a bad experience with some particular approach, he would be wary of using that approach on a future project.

As aforementioned, not only does the technical, business and social influences affect the decisions of the architect but the architect will also affect those factors. An example of this would be when the architect produces a prototype for evaluation. With a prototype, the customer would be able to evaluate the feasibility of this piece of software. The customer might then decide to add or remove features to suit their own needs. Adding or removing features has an effect on how the architect should proceed for the next stage.

The book itself has a lot more examples of the interaction between the stakeholders and the architect. Most of these might seem like common sense but the authors have done a good job by actually expressing the more general cases on paper.

Toward the end of the chapter, the book provides some rules of thumbs on what is a good architecturea. A more mature methodology for evaluation would be based on the Tradeoff Analysis Method that is presented in chapter 12 of the book.

One would think that the interaction between software architects and the stakeholders is something that people in the software business should know about. And yet, most software projects do not go as plan simply because the customers throws down a set of requirements for the developers, with some budget and a timeline and expects the developers to produce something by the deadline. Great architecture seldom (if ever) come out as a sequential series of steps. Instead it requires iterative steps that refine trouble spots in the software architecture as both the requirements, stakeholders and architect themselves mature in the life of the software.

Hopefully, with more agile development methods such as XP, there is a trend toward making software development more iterative.

There is a difference between architecture, design and implementation. Without knowing any better, when asked what architecture means for me during the first class session, I shouted out design. Obviously, I now realize that architecture is more than just design and that the two terms are not synonymous.

In Architecture, Design, Implementation the authors hope to disambiguate the different terminologies so that communication amongst developers might be simplified. And also, I think, to curb the haphazard abuse of those terms for marketing purposes. For instance, there is no need to market UML as an architectural design language when it completely does not fit the profile.

To get the most out of this paper, one must understand the table and definition that follows:

architecture	intensional	non-local
design	intensional	non-local
implementation	extensional	local

Intensional (vs. extensional) specifications are “abstract” in the sense that they can be formally characterized by the use of logic variables that range over an unbounded domain.

Non-local (vs. local) specifications are “abstract” in the sense that they pervade all parts of the system (as opposed to being limited to some part thereof)

To further elaborate on those terms would require much mathematics and mathematical notation is where normal HTMl fall short. Those who are interested should go read the paper.

I do not have any experience reading other papers that try to discriminate between these three terms so I might not be able to give a comprehensive discussion of the merits and faults of the other definitions to date. However, suffice to say, this paper does fulfill the objective of giving proper definitions to the three terms.

At first, I was a bit critical and skeptical of the use of formal mathematics to define these terms. However, after some thought, I realize that without using formal methods, it will be hard to give a qualitative description for each term. This was one of the reasons that compelled the authors to write this paper; previous definitions were based on quantity (the amount of details in each specification).

Even after reading this paper, I remain slightly skeptical of such formal specifications. As mentioned in the paper itself, there is no way to check this formalization for all design patterns since a catalogue of such patterns does not exist. “A direct proof would require a formalization of “all” design patterns and architectural styles.”

Moreover, in most architectural systems, to render the distinction between architecture, design and implementation might not really be that important. The main purpose of architectural documentations (for me, and with my current knowledge) is to ensure that people who read it can get a grasp of the system. At the moment, architectural documents are still read by human beings who are not too troubled by formal or informal definitions.

Still, the existence of this paper does provide for developers who need such degrees of precision when defining these three terms. And it was interesting to see how one would approach software architecture from a mathematical point of view.

Even more interesting is how the developers would react when something that they have always classified as a design criterion gets upgraded to an architectural style! That is exactly the case with the Law of Demeter. The Law of Demeter is usually thought of as a design decision, but in this paper it has been updated to an architectural style. Somehow this really goes against the principle of least surprise.

And Prof. Johnson pointed out something interesting in lecture. Very few architectural styles exist in pristine form. For instance, it is rare for a Pipes and Filters system to be just pipes and filters. Developers are definitely going to modify the architectural style to suit their domain model. However, if they did that, then it would violate the intensional property and nullified their architectural style; demoting it to the status of design!

In a nutshell, one can conclude from the paper that architecture is most abstract (in the sense that its description excludes the details of implementation) and also the most encompassing (in the sense that it pervades the entire system). How one actually use this definitions when dealing with other developers not familiar with these definitions is not entirely clear yet.

If you recall, in my first blog post on software architecture, I mentioned architecture description languages (ADL) as ways to – obviously – describe some software architecture. However, using ADLs is not the only way. In the paper Architectural Blueprints—The “4+1” View Model of Software Archictecure by Phillipe Kruchten¹, he examines how developers can use multiple views to capture the software architecture and how this multiples views are more desirable than a single viewport that try to capture everything. Each view, should ideally, address one specific set of concerns.

For Kruchten, software architecture is the deliberate assembling of various architectural elements to fulfill the requirements of the system. As such, it is possible to describe the architecture using these four views:

• The logical view, which is the object model of the design (when an object-oriented design method is used),
• The process view, which captures the concurrency and synchronization aspects of the design,
• The development view, which describes the static organization of the software in its development environment,
• The physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect.

Each view uses its own specialized set of notations that can convey the main point more succinctly. For the logical view, the class and object diagrams in UML would be an appropriate choice whereas the sequence diagrams in UML might be suitable for the process view.

The fifth view (the +1 view) would be some use cases for the system. And this fifth view ties the other four views and give a more concrete description of the system. It is this concrete description that would be most important in a system since the fifth view explicitly states the scenario that needs to be addressed by the system. Most of the details of the “main” problem might be hidden away in the other views since they present a more abstract view of the system.

Furthermore, this fifth view serves an important role in a iterative approach to refine the architecture. The paper presents a sample iterative cycle that uses a specific scenario as the fifth view to help identify the components in the other four views. As each use case is addressed, the other views are also adapted to accommodate that use case.

Finally, these views can also serve as the basis for other forms of written documentation such as the Software Archictecure Document and the Software Design Guidelines.

Kruchten himself states the generic nature of these 4+1 views and how other notation systems might be used alternatively. In fact, he is not against dropping certain views if there is no need for them in the system. For instance, he argues that if the logical view and development view are so similar, then there is no need for separate descriptions.

Why does this separation of concerns work? There are various requirements that each stakeholder might be interested in but not every stakeholder cares for what the other stakeholders are interested in. For example, the project manager might be interested in the development view but the systems engineer will be more interested in the physical and process views. By separating the concerns, each stakeholder would be able to quickly find out what they need to know about the architecture and, if necessary, provide feedback.

Documenting Software Architecture (another book to read for this class) does mention a brief note about the “4+1” view at page 380 but the book associates it more with the Rational Unified Process (RUP). So, it would be interesting to see whether this “4+1” is used by developers who are not in favor of RUP.

¹ I did not link to the version on UIUC’s CS server because the paper might still be under copyright.

Software architecture - Wikipedia, the free encyclopedia:

"A software architecture or software systems architecture is a representation of a software system, as well as the process and discipline for effectively implementing the design(s) for such a system. It is a representation because it is used to convey the information content of the related elements comprising a system, the relationships among those elements, and the rules governing those relationships. It is a process because a sequence of steps is prescribed to produce or change the architecture, and/or a design from that architecture, of a system within a set of constraints. It is a discipline because a body of knowledge or a general set of principles of (software) architecture is used to inform practitioners as to the most effective way to design the system within a set of constraints."

Introduction to Software Architecture was a paper written by David Garlan and Mary Shaw in 1994 that still gives its readers a good idea of what software architecture is all about. The excerpt above was taken from Wikipedia's entry on Software Architecture and not much has actually changed from Garlan and Shaw's earlier definition. Garlan and Shaw's definition treats software architecture as a collection of components and the interaction of those components under a set of constraints. To understand a particular software architecture, Garlan and Shaw not only propose identifying the components, their interactions and the constraints that bound them but to also document the specific situation under which that software architecture flourished. Proper documentation was an important part of describing and preserving the nature of the software architecture for future references.

The evolution of software proposed by Garlan and Show goes like this: high-level programming languages -> abstract data types -> software architecture. I agree that as we deal with more complex systems, the underlying hardware has been greatly abstracted. We no longer deal in terms of bits and bytes or even integers. In fact, in software architecture terminology, we might not even be dealing with actual classes (in the Object-oriented sense) anymore. What we deal with is in fact even higher level. We are describing the architecture using common phrases such as "three-tier", "pipeline" and "web services" but each phrase conveys a high-level concept that developers can grasp easily.

Introduction to Software Architecture lists six common architectural styles. All six examples are still listed on the Wikipedia page as well. One common architectural style that was mentioned is Pipes and Filters. Pipes and Filters are pretty commonplace in Unix systems based on the advocacy of Eric Raymond's mantra: "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." What I find interesting is that although pipes work well for most task such as grep, sed and awk for more specific applications there is an added cost of having to reparse at each step because the textual representation might not be what you expect.

Nonetheless as noted in the paper, most of the six common architectural styles do not exists in their pure form in software development. Garlan and Shaw prefer to use the term heterogeneous architectures but I prefer calling them hybrid architectures. To me, heterogeneous means mixing two or more architectural styles together and hope that they work well. For me, the term hybrid is more suited because changes need to be made to each architectural style that you wish to combine for them to work together. The existence of hybrid architectures show that software architecture can borrow ideas from different styles and merge them together. Such evolution means that there will always be new architectural styles to observe and document as developers keep producing software.

I enjoyed this paper a lot because it presents some concrete examples of software problems and different approaches for solving the problem. Each problems can be solved using any one of the six common architectural styles, but a better solution usually exists as a conglomeration of two or more styles. As software complexity increases, there is a demand for different paradigms for solving different problems. There is, most definitely, no single golden hammer for every software challenge out there.

The paper includes a summary that advocates the importance of documenting the different architectures so that other developers might be able to analyze architectural styles that fail and reapply architectural styles that work. It proposes the development of proper notations for describing those architectural design. Wikipedia's entry on software architectural has some examples of architectural description languages that might be employed: Wright, Acme, xADL and Darwin.

While there are indeed many different definitions for software architecture, most parties agree that architecture embodies the organization of the components in the software, the interaction and the compelling forces that constraints that style. All in all, software architecture will remain an important facet of software development. As we move into ultra-large-scale systems, the need for different architectural styles of software development is also at its greatest to sustain the need for continuos development in the future.

This is a sub-blog created to discuss issues with the papers, book, etc that I have read as part of UIUC's CS 527: Advanced Topic in Software Engineering. This blog will only discuss topics concerning software engineering. It might include humorous articles too.

My main blog is at blog.vazexqi.com. It also contains a fair amount of software engineering related materials but you will have to dig for it yourself.

To start things off, here is a picture that most of you will find interesting:

The original post was from Andy Hunt's blog.

This blog is powered by Typo, a Ruby on Rails content management systems what is currently at version 4. Great as it is, Typo does lack proper architectural documentation and would make a great project for CS 527 :)