Architect: n. 1. one qualified to design and supervise construction of buildings. 2.
contriver.
[Collins Compact, 1984]
The architecture of a computer system can be defined as its functional appearance to
its immediate users
[Amdahl, 1964, in [Goor89]]
Architecture in the hardware world is the high-level design of a machine. One speaks of a RISC architecture and pipelined architectures on CPUs. This sense is different yet similar to the usual definition of architecture. Similar: because we can examine schools of thought; broad categories within architecture and note similarities and differences between them. Different: because the computer architecture definition mentions only technical issues.
Hardware architecture can be analyzed on several metrics: by consistency, by orthogonality, by completeness and so on. CPU architectures are classifiable, for example, by whether they use address registers or not, or whether they are super-scalar, scalar or non-scalar.
Software has internal structure and external interfaces; decisions must be made as to who is responsible for what. Software architecture focuses on the high-level ideas of modules and technologies while design focuses on hierarchy and decomposition. Blum discusses these ideas in more detail in ch.1.
There is much in common between hardware and software architecture: both have heuristics for problem solving and aesthetics of solutions; there are similar approaches to analyzing problems, and so on.
Good architectures (and good designs) have a unity of concept that helps the architect or designer make choices among competing alternatives. This unity-of-concept principle is important for design quality. [Goor89]
Lane uses the idea of a design space to analyze and classify software architectures. Applications (particular instances of architectures) are points in the multi-dimensional design space. It is useful to study why applications are located at particular places in such a space, since the architecture was chosen with particular trade-offs in mind. This study is the software equivalent to the classification studies of hardware architectures.
For example: applications can be analyzed along dimensions of 'module cohesion', 'user customizability' and 'uniformity of module interfaces'. By comparing several applications along these and other dimensions, an application architect can begin to understand what trade-offs are important, and what architectures work better in particular domains.
Both architecture and design are creative endeavors. No matter how finely specified, the specification document will always lack information required for the implementation of the specification, otherwise the two would be identical. [Blum92] There are two key differences:
Architecture decisions have long term impact - an application's architecture remains unchanged over its lifetime. Individual components may be redesigned and reimplemented, but the architecture is unchanged. Changing the architecture changes the design and creates a new application. Choosing an architecture is a meta-design choice.
When approaching a new problem a design must be chosen that solves the problem. However, there may be many potential designs - choosing one requires analysis of the trade-offs involved in each. Architectures allow us to encapsulate these trade-off analyses.
For example: choosing an object-oriented architecture for the new Axess system will lead to a different design than a procedural architecture would. An event-driven architecture versus a prompting (i.e. scheduled) system leads to different trade-offs. Notice that these dimensions are orthogonal, and choices made along one do not have to influence the other. Hence we can implement the new Axess using an event-driven C program or have an event-driven Smalltalk system.
Many of the tools used to create a design are also applicable to creating or selecting a software architecture. There exist few tools specifically for software architecture. This is where I think this course has a lot to offer. It allows many architectures to be reviewed and compared. Lane discusses the lack of training software engineers receive in choosing between these kind of design alternative. Blum talks of how we generate designs to solve problems, and discusses of several approaches to problem solving (section 1.3), but concludes that it is ultimately something that just 'happens'. "There is no cookbook and it is impossible to write one."
The key is that there needs to be a basis for comparison and contrasting architectures. Since architecture is a characteristic of larger systems rather than small systems, it is not often encountered in academia, where students tend to work on smaller problems.
Kapor's design manifesto says we need to deal with this lack: software design needs to be recognized as a profession in its own right, a disciplinary peer to computer science and software engineering... In Kapor's view, designers should be trained more like architects, using design studio exercises and broad exposure to topics within computer science, without having to become expert in each area. Architects study fundamental techniques and principles of drawing, construction and engineering. Similarly, software designers need a grounding in computer science and engineering, but train to build whole, useful artifacts.
A dimensional analysis of some of the architectures presented in class reveals:
MegaModules
Andersen's Business Object Model architecture, where business logic is located in a BOM, while independent components communicate with the BOM to perform their functions.
Both architectures place in roughly the same area along the four dimensions chosen. Their characteristics may differ in other respects - e.g. they probably have different reuse features.
So why should we choose one over the other? What is the advantage in using an object-oriented design in favor of a procedural decomposition? And most importantly: what are appropriate uses of each architecture and how well do they hold up to changes in that use? Currently there are no courses that try to answer these sorts of questions.
Choosing an architecture is a trade-off, and rarely is there a 'right' answer. The larger the problem, the more difficult the decisions become, because there is so much more to understand. To quote from DeGrace and Stahl (p. 193):
"The only known algorithm known to successfully decompose very large projects into doable projects was practiced in secret by the Druids. Most IS managers depend on miracles."
The primary tool of a designer is knowledge about a system. The better understood a problem, the more informed, and thus better the design for the solution will be. The more the designer knows about the context in which a design will exist, the better the design can be. Hence much of design is about discovering context. In the waterfall model this means understanding the requirements and specification documents.
Other approaches involve discovering the design issues through experiment - this is the basis for prototyping methods and the 'all-at-once' method described by DeGrace and Stahl. A common thread here is that analysis and design are not separable into distinct phases - one influences the other. Similarly design and architecture can influence one another: as a problem becomes better understood, the architecture may be seen as unsuitable, thus leading to a new design. The all-at-once approach is quite good at dealing with this sort of problem, while the spiral model tends to resist radical changes to the design once an iteration is over.
Once a problem has been understood, a solution must be generated that fits within the chosen architecture. Since architecture choices affect the design in many ways, Brooks' advice to breed good designers also holds for architects.
The difference between an architecture and a design is one of scale. Each influences the other. Design occurs within the paradigm of an architecture.
Architecture involves choosing among many possible solutions, as with selecting a design. Learning to select good solutions requires exposure to many potential solutions and an understanding of the principles behind each trade-off analysis.
The book is quite thorough in its coverage of each method it presents. You could build a course around just the contents of this book - it is what I had as an undergraduate. If anything, the biggest problem is that there is so much covered in the book that it becomes hard to see the wood for the trees. The 'holistic view' mentioned on the cover does not stand out in the meat of the book, being left to a discussion in the epilog.
The epilog discusses the coming paradigm shift (as Blum sees it) away from product-oriented development, focusing on implementation, and over to problem-oriented solutions, focusing on a solution design. Whether or not this is true, the implications of a design-oriented paradigm are interesting. For one thing: what happens to programmers in this paradigm? Programmers appear to become rule-builders and knowledge engineers instead.
Blum is quite even handed in his discussion of various methods for building models. He discusses their advantages and disadvantages but never quite covers their appropriateness. It would be very useful to know when an E-R diagram is appropriate and when it is not. Knowing that DFDs are easily misinterpreted is good to know, but the reason why this is the case is not covered.
Blum has a lot of practical advice to analysts and designers about how they can do their job. He gives the reader a comprehensive set of tools for working on design problems. The book is worth studying for that alone, depending on how broadly you define software-engineering.
What would have been interesting to see is a discussion of how analysis methods in turn influence design. A JSD model with entity-life histories makes an object oriented, event driven design fairly easy to generate. A Structured Analysis model tends to lead to a procedural design, and so on. Blum appears to view analysis and design as separate activities. At least, his traditional view of software engineering does. His new paradigm does not appear to make the distinction. His new book should be quite interesting in this respect.
The Software Engineering book is a thorough investigation of current practice. Parts of it should definitely be covered in a software engineering class. It is more thorough than the DeGrace and Stahl work, but less readable. Unfortunately the most interesting parts of the book, dealing with the new paradigm, are not covered in as great depth as the other material. It looks as if we have to wait till next year to find out more about the new paradigm.
The key to developing useful software is the application of many rules and heuristics. It also involves knowing and understanding the users of the system. Borenstein spends a large part of the book on this problem. Users know what they want, unfortunately they often can't tell us exactly what that is. Sometimes the users believe they want something, while the real need is for something else.
Borenstein claims that user interfaces are different from the rest of the code, because it is so highly visible to the user. The consequence is that the code for the user interface changes more often and accumulates more and more 'cruft' in the form of poorly written hacks on the original code. The suggested solution to this is an iterative prototyping method of development that he presents in the last part of the book.
There may be some truth to the claim that user interfaces are more volatile than other parts of a program, but the problem remains the same: dealing with changing requirements.
Borenstein has one important lesson for last: applying all the principles and rules and suggestions he has in his book will not make you a better designer. You will still make mistakes. However, next time you will be better placed to understand why you made a mistake. The users are the final judge. The best approach to dealing with your users and their continual requests is a Zen-like acceptance of the inevitable: all of your work will be replaced eventually. Humility lets us accept our faults and move on to the next problem.
Borenstein's book is quite amusing, since he is quite willing to reveal his own mistakes. The book also has the advantage of being quite brief and easily read. This book might fit better with a HCI course than with a software engineering course, but on the other hand, software engineers need to be more familiar with user interface concerns and techniques.
The All-at-Once model involves gathering a team of professionals from many areas, committing them to a particular goal and leaving the team alone to achieve it. The team's commitment and cohesiveness leads to a very open development process where many approaches are tried, there is no overall team leader over the entire project and the team will often try to exceed the goal if possible. There are dangers with this approach, such as overcommitting the team, breakdowns caused by personality clashes, and so on.
They also discuss the lack of professionalism among software engineers and designers. This ties in with their breakdown of problems into 'Wicked' and 'Righteous'. A righteous problem is one we understand well and can engineer a solution to. Wicked problems are not well understood and have poorly defined boundaries. A professional can distinguish wicked problems from solvable problems, and treat them appropriately. Amateurs treat both kinds of problems identically, and end up as horror stories in software engineering textbooks.
The mark of a professional is a holistic view, a concern for the long term consequences of his designs. In DeGrace's view, programmers are still craftsmen. Engineering is more of an aspiration than a reality.
This is a broad book - it packs a lot into its 200 pages. It should definitely be on a suggested reading list for this course. It covers more ground than Blum, is more interesting, and has lots of practical advice on how real-life software is or should be 'engineered'.
System design (as opposed to module design) is a large scale problem. A designer is someone who has a foot in both worlds: one in computer systems, one in the world of people. Kapor claims that the system designer is mostly ignored at work and in schools today, and that a new curriculum is needed to teach design.
"In computer programs, the selection of the various components and elements of the application must be driven by an appreciation of the overall conditions of use and user needs through a process of intelligent and conscientious design."
Design must be taught as a separate profession, with a special set of skills. Designers must not be ignorant of implementation issues, but must not become bogged down in specifics. They must have a broad understanding of the issues involved in implementing software, so that they can communicate with the programmers on an equal footing.
However, design is learned best through practice. Design studios involve directed projects to design parts of actual programs using the tools and techniques of their trade.
A relevant article for a software engineering course to discuss. The course should aspire to do more than just teach how to engineer software.
I would also like to plug the ASD: Association for Software Design, where the topic of this paper was discussed. The ASD is a result of Kapor's call for action.
This analysis eventually leads to the generation of heuristics and rules for approaching a system design. Rules may focus on a particular dimension ("High user customization requirements favor external notations for user-interface behavior") or on the interaction between two dimensions ("The choice of application interface abstraction level influences the choice of nation for user interface behavior").
Architects can then pick particular places along several dimensions and apply the rules to make sure their architecture is consistent. It does not provide the unity-of-concept mentioned in [Goor89], but helps the architect avoid a choice that leads to unacceptable design trade-offs later in the project.
Lane describes how this process can be automated to some extent. The architecture expert system knows about design rules and design dimensions with particular domains. It helps the architect evaluate particular choices.