Additional Topics Related to Abstraction


We end this chapter by discussing several topics that may expand readers perspective on the concept of abstraction. Specifically, the following topics are discussed: the human aspects of software architecture, architecture versus design, quality attribute workshops, metaphors in science and philosophy, and abstraction in computer science and software engineering education.

The Human Aspects of Software Architecture

Software architecture is becoming a ubiquitous part of computing. It has nearly the same characteristics as design, although many of its practitioners often use Software Architect on their business cards, the same way Software Engineer appeared on the business cards of an earlier generation.

There is a functional side to software architecture. This side is well understood and easy to work with. It usually drives the shape of the software. There is another side, which the Software Engineering Institute (SEI) calls the quality attributes. These are characteristics like usability, modifiability, safety, and similar ilities. These are usually what the human user of an architecture cares about and are a subject of this section [Bass03]. We will also discuss the use of a metaphor and its contribution to architecture.

Tasks  
  1. What is a quality attribute?

  2. How are quality attributes found?

  3. How is a metaphor used to derive architecture?

Architecture is becoming an increasingly popular way to describe the shape of software. This shape frames development strategies. Since it involves the user, it is basic to software engineering.

Architecture versus Design

We have seen that designing is one of the verbs in the paradigm of software development. The activities associated with developing an architecture, as well as a design, are subsumed here. So, is there a difference between architecture and design? There is, just as there is a difference between high-level design and detailed design, again, both subsumed in the verb designing. Detailed design shows how certain functionality is implemented, so it is closer to coding. High-level design is the last chance to put the requirements of the specifying step out for validation. Therefore, it is closer to specifying.

Software architecture is a way of expressing high-level design that accounts for the quality attributes as well as the functionality of the software. People try to find architectures because if they can define a good one, later changes to the software will not cause a change in the architecture. This is a reason for prototyping, captured in building architecture by models and in Computer-Aided Designs (CAD). Building architects are adamant about prototyping because they can only erase defects is with jackhammers, or they can live with them, both expensive propositions .

Designs are fairly idiosyncratic; they do not carry the generalization of architecture. An architecture often hearkens back to the form of a successful high-level design. For example, in the architecture of buildings , the form of gothic has proven to be successful as part of a church , and many churches are in the gothic style, or have some gothic themes. In software, pipe-and-filter, blackboard, publish-and-subscribe , and other architectures provide a basis for detailed design. One way they do this is by identifying components and by incorporating quality attributes [Garlan and Shaw96].

Software architecture is a way of describing the entire detailed design. How are parts of the architecture found? One way is to identify quality attributes and prioritize them. The Unified Process (UP) claims that it is architecture-centric [Jacobsen99]. Agile processes, although they make no such claim, do almost the same. The well-known white board with the design written on it is a common part of agile workplaces [Beck00].

Quality Attribute Workshops

Many people think that agilism ignores architecture. There is no explicit architectural step, so it seems as if the architecture falls out in the flurry of coding. Actually, XP has at least four practices that contribute to an architecture. It has at least one major value that contributes to capturing the architecture. The SEI has at least four architecture evaluation methods that can apply to XP or agile methods in general.

The four XP practices that help engineers build the architecture are Customer On-Site, the Metaphor, Simple Design, and Refactoring [Beck00]. The customer is expected to not only provide the requirements, but to prioritize them (see Chapter 13). Each cycle of coding (about two weeks long) provides business value if produced according to the correct priorities. The difficulty lies in choosing these priorities. An experienced customer has an almost intuitive grasp of this. Others would benefit from a Quality Attribute Workshop (QAW) [Barbacci03]. This workshop would help customers prioritize requirements along the lines of their business needs, and would help identify the stories.

The QAW also has as a product some test cases to exercise the requirements developed. These can overcome one of the problems of customer involvement in XP. It is expected that customers develop user stories for requirements and then work on acceptance test cases for the end of development. Many customers do not know how to build these test cases. The QAW gives them clues and encourages them to build the cases. Moreover, building test cases fits in with the XP practice of test-first or build for the test philosophy, sometimes called test-driven development, since test cases are available to test whether the code implements the requirements from early in the development ( acceptance tests ). These test cases can be built as code is being built, so the product of the software development team can be checked at the end.

In addition, the QAW method has as its main focus the development of scenarios. These can be used to derive stories and as input to other SEI methods of revealing quality attributes.

The XP practice that affects software architecture the most is the Metaphor. The Metaphor is intended as a bridge between the technically oriented developers and the nontechnical customers. It is also to be used among developers. In both cases, it is intended to fulfill the value of communication. The Metaphor is meant to be a natural language description of the product. It is also meant to inspire the architecture [Beck00]. Metaphors are popular in philosophic thought, but are hardly limited to philosophy. Science and, now, software engineering make use of metaphors. They make much of abstract thinking achievable [Lakoff99].

The use of a metaphor in agile programming, especially XP, has two purposes: it is a start on the architecture of the system, and it is a means of communicating about the system with the user. For example, the first XP team visualized a payroll system as an assembly line. Both clients and developers could discuss an assembly line, especially since they worked for an automobile manufacturer. Stations became functions. The metaphor sounded like it fit the pipe and filter architecture, of which the developers were aware (see Figure 11.1).

click to expand
Figure 11.1: A pipe-and-filter architecture.

Both groups could discuss the assembly line metaphor. The technical team could use the architecture as they wanted, and keep the details from the user.

It seems that the metaphor, despite its success on the automobile company s payroll project, is clearly the least used of the XP practices [Herbsleb03]. Many more detailed descriptions of XP ignore it all together or replace it with Stand-Up Meetings, a practice from Scrum (another agile method) [Anderson04]. At one point in 2002, Kent Beck himself (the originator of XP) said he was going to take an informal poll whether developers were using metaphors at that year s object conference. He said he would never speak of metaphors again, and would drop metaphors from XP if a majority was not using them.

Our research, documented in [Herbsleb03] and [Tomayko03], first aimed at finding some quantifiable reason to eliminate metaphors. We found that metaphors, even na ve ones, are rarely used. (A na ve metaphor is one in which it is close to the actual description of the software, as in controllers for stations on an assembly line and an assembly line.) The traditional poor communication about the structure of the software persists between client and developer. In the continuation of this chapter, we add a short section about metaphors in science and philosophy.

Another evaluation method that fits early in an iteration is the Cost/Benefit Analysis Method (CBAM) [Kazman02]. This method can help establish priorities for an Architectural Tradeoff Analysis Method (ATAM). [2] Since the ATAM is done to ensure that priorities are being met, the SAAM (an older method described in Software Architecture in Practice [Bass98]), or a CBAM and a QAW early on are sufficient. However, if an ATAM is used, then it is be factored into the end of first cycle, before the second cycle begins. The software architecture is pretty well set in XP by then. If the XP customer on site practice is being followed, most of the stakeholders (required to be present in SEI methods) are again easy to find to participate. An ATAM at this time would reveal if the results of the QAW were still being followed, as well as if the nascent architecture embodied other priorities. If not, it is early enough for inexpensive and easier prioritizing of stories and refactoring.

Now we consider the question of documentation. Many believe that XP rejects documentation. This is not true. The Agile Manifesto [Martin02] says that Agilists favor human interaction over extensive documentation. In short, documentation is not ignored; it is put off until the documented item is stable, with few changes expected. The documentation for the architecture in XP, then, is most often on a white board during the cycles. At the end of development, an XP team can document the architecture, using [Clements02] as a guide. If the team is to disband and another takes over, documentation is doubly important. The best guideline for the product is that the code bears the burden of most documentation. Any additional documentation is to assist in understanding the code. This is a good time to see if the product could meet product line guidelines as established in [Clements01]. If so, some refactoring should be done to provide interfaces.

Task  

Does the time involved in doing an SEI method preclude its use in agile approaches to software development?

Metaphors in Science and Philosophy

There is an extensive prior literature on metaphors, since they are frequently used in philosophy and science [Brown03, Jones82, Lakoff99, and Ortony79]. In [Brown03], the author explains how scientists work, the nature of scientific knowledge, and an introduction to metaphors in general. Then he describes in some detail conceptual metaphors. The general notation for metaphors of this type is Target domain is source domain. Take the sentence :

She can stonewall his opinion.

Hence, Argument is construction. This is a conceptual metaphor.

For years , scientific principles were represented as conceptual metaphors (see also [Jones82]). Perhaps the most famous is the atom as a solar system, which lasted until the bewildering variety of subatomic particles were theorized or discovered and shown to have components themselves .

[Lakoff99] refers to primary metaphors. There are a number of examples, like more is up. In other words, increasing quantity is shown by metaphors containing up as in prices are high. This idea develops in childhood. There are neural connections that develop to make this type of metaphor very powerful. For example, the primary metaphor Bad Is Stinky underlies Code Smells, leading us to refactoring. Simple design and Refactoring are frequently found as patterns of code. Ideas for changing these are found in [Gamma95 and Fowler99].

Task  

Develop a metaphor and a resulting architecture for an automatic teller machine (ATM). Is this an example of a na ve metaphor? Why, or why not?

Abstraction in Computer Science and Software Engineering Education

At the Sixteenth Conference of Software Engineering Education and Training , held in 2003 in Madrid, Spain, Jeff Kramer of Imperial College, London, presented his keynote talk: Abstraction ”is it teachable? Or, the devil is in the details. One of his main messages was that abstraction is not a simple concept to teach (or learn!) and that the idea of abstraction should be addressed throughout the entire software-engineering curriculum.

In what follows , we illustrate the central role that abstraction plays in computer science and software engineering programs by describing the recommendations of three committees that suggested structures for computer science and software-engineering undergraduate programs. In 1991 The Computing Curricula 1991 Committee [3] identified the following three concepts as ideas that each computer science curriculum should emphasize : theory, abstraction, and design. This recommendation is explained by the fact that mastery of the discipline includes not only an understanding of basic subject matter, but also an understanding of the aforementioned three points of view that computing professionals employ and students need to appreciate.

In a similar spirit, 10 years later, the 2001 report of the Computing Curricula 2001 Committee [4] explains that one of the principles that guided the work of the committee was the fact that the foundations of computer science are drawn from a wide variety of disciplines, and consequently, undergraduate study of computer science should require students to use concepts from many different fields. Accordingly, computer science students should learn to integrate theory and practice, to recognize the importance of abstraction, and to be able to appreciate the value of good engineering design.

The same orientation is also expressed in the Computing Curriculum ”Software Engineering (CCSE) Public Draft [5] published on July 17, 2003. Its Principles section describes the foundational ideas that guided the development of the CCSE materials. The second principle states that all software-engineering students must learn to integrate theory and practice and to recognize the importance of abstraction and modeling.

As can be observed , the same principle guided the work of all committees. In fact, we tried to convey a similar message in this chapter when we addressed, from the perspective of abstraction, topics that were discussed previously in the book.

[2] For additional information about these concepts, go to the Software Engineering Institute Web site at http://www.sei.cmu.edu.

[3] The ACM/IEEE-CS Joint Curriculum Task Force, Computing Curricula 1991 Report: http://www.computer.org/education/cc1991/eab1.htm1.

[4] Computing Curricula 2001 Report: http://www.computer.org/education/cc2001/final/index.htm

[5] Computing Curriculum ”Software Engineering (Draft of July 17, 2003): http://sites.computer.org/ccse/volume/FirstDraft.pdf




Human Aspects of Software Engineering
Human Aspects of Software Engineering (Charles River Media Computer Engineering)
ISBN: 1584503130
EAN: 2147483647
Year: 2004
Pages: 242

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net