Software architecture depends upon a metaphor with building architecture for its definition. Like a building, a software system is composed of many pieces in relation to each other. The architecture is not visible by looking at the individual pieces but only apparent when looking at the complete structure. Likewise, there are many ways to describe what is going on within programs or even small collections of programs (class, inheritance, is-called-by relationships, etc) but they only capture individual details, not the overall impression that is made by the complete assembly.
When trying to convey this point, the language gets difficult. We speak of architectural styles when we refer to a building as international style, or prarie style, gothic, etc. What we mean when we say style is that the structure embodies a set of attributes that together provide a category for the expressive elements of the structure. For example, to say that something is romanesque style immediately suggests that the windows do not have gothic points but are instead semicircular at the top. When we see this style of window, we can look for the other attributes. If it has all or at least most of the stylistic attributes of that category, we can say it is a member of that style.
But while the expressive elements of building architecture are relatively approachable for a lay person, software architecture is less so. For example, the 3 tiered architecture style is very familiar now. When we say that a system is 3 tiered, we immediately expect to find at least one, and usually many clients that communicate with one or more servers via a shared communications channel with the data for the system kept in a back-end database. The deployment of the client, server and database are the expressive elements that define this style. This is far less obvious than the shape of a window but workable as a way of discussing software systems. The student must first make this leap.
Sadly, things can go off the track very quickly here. The work on patterns of the 80s mirrors the idea of style. But the scale at which patterns can be used spans from the grand-architectural to the program level code style. Which of these patterns are architectural? Is a pattern any different than a style? To the second point, I say no, a style and a pattern are essentially the same thing but the context does make a difference.
When we are discussing architectural style, we are looking at the most apparent features of the assembly. This may be worked out more by trial and error than by any great theory. The attributes that make the style useful become the defining elements of the style. The shape of the romanesque and gothic windows were not mere ornamental choices, they were a direct result of the way the stresses of the structure are worked out and arranged to give the structure solidity. Likewise the 3 tiered architecture evolved as a way of making a more scalable system than the monolithic mainframe architectures of the past. In a 3 tiered arrangement, the hardware could be maximized for the task; a Sun server for the Oracle database, Windows servers providing application logic and an assortment of clients to support the machines used by the end user.
The central point made by the authors regarding patterns is that a pattern is a logical response to a recurring problem with a solution that has been used repeatedly and has known attributes. That is to say, if I apply pattern A to the problem, I can be assured that it will exhibit properties X, Y and Z. But if I were to use pattern B for this same problem, it would exhibit properties W, Y and Z. I would know this because of the amount of analysis that has previously been done using those patterns. If the properties W, X, Y and Z are the most important properties of the complete system that are desired by the client, then it is reasonable to call these architectural patterns or styles.
Another point that is confusing to the students is that this is distinctly different that an architectural view. Architecture is complex enough that it is impossible to describe in a single representation. For this discussion to make sense it is first important to realize that EVERY building and EVERY software system can be said to possess AN architecture; architecture is not something that can only exist if it is designed in. While a wigwam may not strike some as architecture in this context it is a valid as a Frank Lloyd Wright prairie style home. The first is an example of an organic or historic style that is done unselfconsciously, the second is considered more of an art form which requires deliberation and conscious effort on the part of a designer who is not the inhabitant. Even the humble wigwam is difficult to depict on a single diagram and a modern skyscraper absolutely impossible.
Historically building architecture has evolved a standardized series of depictions which collectively can be considered the expression of the architecture. There is a of course the scale model which helps the client get an idea of the overall shape and appearance of the intended structure. But that is insufficient for the many detailed decisions that the architect may need to convey to ensure that the project comes out as envisioned. There are framing plans, electrical plans, HVAC plans, plumbing plans, plot maps and a great deal more. Each of these plans is a particular view of the architecture. It represents an abstraction of the information that stakeholder has in the project. That abstraction is a representation that enables that stakeholder to efficiently participate in the project.
Software projects are no different. To achieve some anticipated future modifications, a software designer may provide a particular class hierarchy that, if followed, will make an anticipated change later easy to do. To achieve performance, there may be a great deal of attention given to the particular hardware that the various software modules may be deployed to or even consideration given to other software that may run, or be prevented from running, on that hardware so as to ensure the hardware availability needed to achieve that performance goal. The ways these design decisions are captured into artifacts to be shared with other members of the project team are each specific views of the architecture. No one by itself completely captures the architecture but collectively they do.
Another point that will inevitably come up in this discussion is the extent to which architecture is high level design. The answer must equivocate because, yes architecture is certainly high-level but no, it may not always remain solely high level. For example, to achieve a particular usability goal, the team may actually need to experiment with completely coded UI designs and run human experiments to see how people react. This may not be a production grade system, most likely a prototype. But to be sure the final design will have the usability specified the UI will be worked out to a relatively low level leaving very few decisions for the implementors. This is generally not what people think of when they talk about high level design.
What is required is for the architect to determine which of the many attributes desired by the client will be the most critical to the project success and in particular which attributes will require careful tradeoff because of confounding.
I think if a student can be led through these points, the definition of software architecture is complete.
No comments:
Post a Comment