This Document Contains Chapters 1 to 11 Chapter 1 Software and Software Engineering CHAPTER OVERVIEW AND COMMENTS The goal of this chapter is to introduce software and software engineering. Software is a “product” designed and built by software engineers. Software is important because it has an impact of virtually every aspect of our lives. Software engineers have a moral and ethical responsibility to ensure that the software they build does no serious harm and meets the needs of the people who request it and those who use it. Software engineers tend to be concerned with the technical elegance of their software products. Customers tend to be concerned only with whether or not a software product meets their needs and is easy to use. 1.1 The Nature of Software The main point of this section is that software is an information transformer. Software is used to produce, manage, acquire, modify, display, and transmit information anywhere in the world. The days of the lone programmer are gone. Modern software is developed by teams of software specialists. Yet, the software developer's concerns have remained the same. Why does software take so long to complete? Why does it cost so much to produce? Why can't all errors be found and removed before software is delivered to the customer? Many instructors choose to address software engineering ethics at this point. If you do this, have your students read and discuss Section 32.4 at the end of the book. Ask your students: What makes software so important? And then have them list the ways that software impacts their lives. Have them list five non-computer related businesses where software has a significant, if ‘behind the scenes’ impact. Select a book like Toffler’s PowerShift and note where he was right and wrong in predicting the “future.” Discuss the current state of the “programmer” in your country. Spend some time talking about the questions posed at the end of this section. Software is not like the artifacts produced in most other engineering disciplines. Software is developed it is not manufactured in the classical sense. Building a software product is more like constructing a design prototype. Opportunities for replication without customization are not very common. Software may become deteriorate, but it does not wear out. The chief reason for software deterioration is that many changes are made to a software product over its lifetime. As changes are made, defects may be inadvertently introduced to other portions of the software that interact with the portion that was changed. Spend some time talking about the three major characteristics noted in this section. The “wear” discussion is critical—be sure your students understand it. Discuss why component-based development has benefit, but also discuss why it hasn’t worked as well as many believe it should. 1.3 The Unique Nature of WebApps Some SEPA adopters argue that there really isn’t very much that is unique about WebApps when contrasted with “conventional” software, but I disagree. Spend some time going through the attributes discussed in this section, indicating how WebApps different from conventional software in both subtle and distinct ways. 1.3 Software Engineering Recognize that any attempt to develop an all-encompassing definition of software engineering is an exercise in frustration. The point here is to emphasize that software engineering is a “layered” technology. If you have the time and the inclination, you might want to introduce your students to SWEBOK (http://www.swebok.org/) as another source of software engineering information. 1.4 Software Engineering Process Even though it might seem to be a simple idea, many students struggle with the concept of a process, confusing process with methods and tools. Spend some time discussing the meaning of a process framework and the basic framework activities introduced here. 1.5 Software Engineering Practice Polya’s work is pivotal to basic understanding of the software engineering approach. Spend time discussing his seminal ideas along with the questions that he posed at each step along the way. 1.6 Software Myths The myths presented in this section provide a good source of material for class discussion. Ask “why” people believe these myths and whether there are grains of truth in each (there are). Ask you students to think of one or two software myths of their own. 1.7 How It All Starts SafeHome is a useful case study that you’ll encounter throughout the book. It’s worth spending some time discussing how projects start in the real world. Based on the sidebar, ask students to develop a list of 10 questions that they would need answered about SafeHome. Part 1 The Software Process Chapter 2 Process Models CHAPTER OVERVIEW AND COMMENTS This intent of this chapter is to present a generic software process model that can be used as a template for all other process models presented in this book. A process framework, encompassing five activities— communication, planning, modeling, construction, and deployment—is presented. In addition, the CMMI, process patterns, and personal and team oriented process models are discussed. 2.1 A Generic Process Model Because so many process models are in existence, it’s a good idea to provide a common way of looking at them. The generic process model presented here is a simple, yet effective tool for considering more complex models discussed in this and other chapters. It’s important to note that my selection of the five framework activities, although representative, is not “industry standard” (there is no such thing). Therefore, you can, if you choose, select other terminology. Regardless, it’s very important to emphasize this section. 2.2 Process Assessment and Improvement Software process assessment and improvement are important issues but a detailed discuss have been delayed until Chapter 30. I foreshadow the topic here for completeness. You can choose to expand upon it by using content from Chapter 30 now. If your enrollment is mostly industry professionals, this section can be discussed in detail at this point. If, however, your students are undergrads with little real-world experience, you should note that process “standards” do exist, and that the CMMI is an important one. Also note, that the success in building large software-based systems correlates with an organization’s capability level. 2.3 Prescriptive Process Models Many people (and not a few professors) believe that prescriptive models are “old school”—ponderous, bureaucratic document-producing machines. Disabuse your students of this notion. Every prescriptive process presented in this chapter can be streamlined (made agile). Note that “prescriptive” simply means that the process model identifies a set of process elements—framework activities, software engineering actions, tasks, work products, quality assurance and change control mechanisms—for each project. It is easy for students to become so lost in the details of the various process models that they fail to see the features the models have in common with each other. Refer back to Section 2.1 to emphasize generic similarities. Another difficulty students have is their belief that each activity within the process is performed completely independently of the other activities. The reality is that there tends to be lots overlap among these activities. 2.3.1 The Waterfall Model Many people dismiss the waterfall as obsolete and it certainly does have problems. But this model can still be used in some situations. Be certain your students understand where it can and cannot be used and why. 2.3.2 Incremental Process Models The process models in this category tend to be among the most widely used (and effective) in the industry. Be certain your students understand the conditions under which such models should be used and what an “increment” means in terms of project work and delivery. Have them take a look at a popular software package and describe how they would plan increments over the production cycle. 2.3.3 Evolutionary Process Models Be sure your students understand the subtle difference between an evolutionary model and an incremental model and that fact that an evolutionary process flow can still implement an incremental delivery. Discuss the pros and cons of prototyping and how it differs from the spiral. Note that the spiral I present here is somewhat different than Boehm’s original work, which emphasized a risk-driven process to an even greater extent. It’s also important to note that as workflow moves outward along the spiral (Figure 2.7), the software moves closer to completion. In the extreme, the spiral flow can be applied across the entire lifecycle, from product inception to maintenance. 2.4 Specialized Process Models Be certain your students understand that the component-based development (CBD) model incorporates many of the iterative characteristics of the spiral model. The main difference is that in CBD the emphasis is on composing solutions from prepackaged software components or classes. This CBD emphasizes software reusability. Further discussion of CBD can be found in Chapter 10. At this stage, you may choose not to consider the FM and AOSD models, postponing any discussion until Chapter 21 (if you choose to consider the topics at all). 2.5 The Unified Process I’ve included the UP in this chapter for completeness and because I use UML as a modeling notation throughout this book. The phased approach noted can be mapped nicely into the generic framework introduced in earlier in this chapter. If you consider the UP, you should discuss what use-cases are (this is covered in detail in later chapters) and why a “use-case driven process” has merit. 2.6 Personal and Team Software Process Two important process models (PSP and TSP) are discussed in this section. Your students may find it helpful for you to provide examples of the kinds of how development might proceed under each model. The PSP model is good from the perspective that an individual software engineer can use it to improve his or her personal productivity and work product quality. Both models are largely iterative or evolutionary in their approach to software development. PSP and TSP are interesting, but are not pivotal to an understanding of process issues. If time permits and your students (or you) have an interest, a discussion is worthwhile. The key point to emphasize is that individuals and teams should measure their work and the errors they make and act to improve their approach so that the causes of errors are eliminated. 2.7 Process Technology Acquire a process technology tool and demonstrate its capabilities. Emphasize that the key to success is a process that is tuned to the people, the project and the product. Tools help. But they are not a panacea. 2.8 Product and Process I really enjoyed Davis’ piece when I first read it years ago. She nails many of the issues associated with “the duality of product and process.” Also note Benjamin Cardozo’s (a famous Supreme Court justice) quote. He’s talking about the legal code, but I thought his comments were a nice metaphor for process descriptions. Chapter 3 Agile Development CHAPTER OVERVIEW AND COMMENTS This intent of this chapter is to discuss the “agile” philosophy and to present a variety of agile process models and methodologies. The overriding theme of this chapter is that everyone wants an agile process—the only debate is on how to achieve one and the level of discipline that is incorporated into such process models. Most students love the agile approach for the wrong reasons. They interpret it as glorified hacking. Be certain that you emphasize that engineering discipline and agility are NOT mutually exclusive. 3.1 What is Agility? The main point of this section is to introduce agility in the context of software development. Agility is more than change management. Agility means that customers and developers need to work together as collaborators on the development team and try to build products that can be adapted to a rapidly changing market place. Part of this adaptation is learning when and how to streamline the production of work products and focus on the development of incremental operational prototypes. Spend some time talking about the ramifications of the manifesto (noted in the chapter introduction and then note that none of this implies that discipline is discarded. Software engineering emphasizes each element noted in the manifesto. Also note that the agile philosophy is seductive, but must be tempered by the demands of real systems in the real world. On the positive side, note that many of the ideas espoused as part of the agile approach are excellent and worth considering regardless of the process model a team adopts. 3.2 Agility and the Cost of Change Spend some time discussing the ramifications of Figure 3.1. The key here is to emphasize why agile approaches tend to flatten the cost of change curve. Ask the students to come up with real life examples (outside the software world) that illustrate the impact of cost of change. 3.3 What is an Agile Process? This section continues to refine the notion of applying agility to software process models. All agile processes are adaptable to manage unpredictable changes that take place during software development projects. Agile processes rely heavily on customer feedback generated by their evaluation of operational prototypes. The focus of agile processes is on the delivery of software increments in relatively short timeframes. It is important for students to be exposed to the arguments for agile development (product is more important than documentation) and against agile development (rapidly produced prototypes do not always scale up to enterprise-wide software applications). The idea of tradeoffs is an important point to emphasize here. A third part of this section deals with human factors and group dynamics of agile teams. Students should not underestimate the potential problems that can result if teams do not function well. Each of the agility principles presented in Section 4.2.1 should be discussed at length. Ask your students how they would achieve each. One of the best debates about agile development appeared in the June 2003 issue of IEEE Computer. You might want to assign it as additional reading if you’re emphasizing agility. Agile Process Models Several agile process models are discussed in Sections 3.4 and 3.5. Your students may have some misconceptions about some of these models from experiences prior to this course. For example, extreme programming does not mean writing code without documentation or testing. Many of these process models make references to chapters later in the text. Your students may need additional background to appreciate some of the points made about this process models. The point of these sections is to expose students to the philosophies and activities associated with these agile process models. They should be encouraged to look for the common elements found in each. For the most part students will not be able to apply these process models to their own projects at this point in the course. They should have enough background to apply these models are reading the text chapters on analysis modeling, object-oriented analysis, and testing strategies. 3.4 Extreme Programming There is little debate that XP is the most dominant of all agile models (at this point in time), and yet, the other models presented in the Section 3.5 have characteristics that are worth noting (e.g., the Scrum stand-up meeting). It’s unlikely that you’ll have time to cover each of the models presented. Therefore, I suggest presenting XP and emphasizing user stories, pair-programming, refactoring, and continuous integration as important XP concepts and then supplementing with elements of the other models that you consider to be noteworthy. The terms “collaboration” and “self-organizing teams” are used repeatedly when agile development is presented. You might discuss the meaning of these terms with your students. When you discuss XP, be sure to emphasize user stories, pair-programming, refactoring, and continuous integration, incremental delivery. 3.5 Other Agile Process Models The following characteristics are notable for each of the agile models discussed: XP—ASD—adaptive cycle planning, time-boxing, risk-driven planning, collaborative learning, self-organizing teams DSDM—operationalized prototyping Scrum—backlog, sprints, scrum meetings Crystal— a set of example agile processes, useful principles FDD—plan, design, and build by feature AM—modeling principles (applicable throughout this book) Part 2 Modeling Chapter 4 Principles that Guide Practice CHAPTER OVERVIEW AND COMMENTS This intent of this chapter is to present the concepts and principles that serve as a foundation for software engineering practice. The concepts and principle presented in this chapter are applicable regardless of the specific process that is used, methods that are chosen or tools that are applied. Note: In many cases, the concepts and principles discussed here should be revisited as each software engineering activity is presented during the course. For example, design concepts and principles can be revisited when the chapters on software design are covered. 4.1 Software Engineering Knowledge Although software engineering continues to evolved (sometimes quite rapidly) we have established a core set of principles and concepts that have stabilized over the years. That’s a good thing and your students should understand that no matter where the technology goes, the core remains reasonably constant. 4.2 Core Principles Emphasize that these principles are simply common sense for all engineering disciplines, but that many modern software engineers choose to disregard them and do so at their peril. Be certain that you explain the difference between process and practice. These two terms are sometime confusing for students. The core principles are important, and KISS is the most important of them all. Emphasize that software engineering helps to achieve simplicity by providing a focused approach to problem solving. Also note that software engineering never retards creativity and can, if properly applied, enhance agility. 4.3 Principles that Guide Each Framework Activity I think it’s important to present this material before you delve into the details of each of the activities, but some professors choose to delay a discussion until they come to the appropriate topic. Either approach is acceptable and depends on your style. 4.3.1 Communication Principles Most students have had relatively little experience in this area—emphasize these principles with discussion and examples. If you have time, classroom role playing is a good idea. Be sure to indicate that communication failures can be fatal even if very smart people apply superior technology. Students need to be aware that effective communication includes getting a response from the message recipient that indicates the correct message was received. You might think about using communications exercises with your students to help them appreciate the importance of this topic. For example, have group of students pass a message to each other by whispering the message to the student on his or her right. For another activity you might divide students into a groups and have a representative from each group carry detailed verbal instructions on completing some task from you to their group. In both cases, the message is likely to be distorted and misinterpreted by the message recipients. Ask your students whether communication and negotiation are the same thing. Note the similarities. overlap, and differences. Spend time on the communication task set with particular emphasis on how it might be modified for very small projects, very large project with many stakeholders, etc. 4.3.2 Planning Principles Planning is described as the management and technical activities needed to define a roadmap to complete a software project. There will be two entire chapters devoted to project planning later in the text. Students might benefit from activities in which they try to develop user scenarios for hypothetical software projects. Discuss project scope—a concept that may be hazy in the minds of many students. As them to write a statement of scope for some well known software product; then note how the various statements differ from one another. If there is interest in agile development, discuss how different process models treat planning (either emphasizing or deemphasizing it). Also discuss the fact that even the best plan is developed iteratively and note the reasons why. Spend time on the planning task set with particular emphasis on how it might be modified for very small projects, very large project with many stakeholders, etc. 4.3.3 Modeling Principles Modeling the the set of actions that lead to the development of analysis and design models. The emphasis is on describing how to gather the information needed to build reasonable models, but no specific modeling notations are presented in this chapter. UML and other modeling notations are described in detail later in the text. Students should be reminded that analysis and design are not often conducted a separate activities. Discuss the overall purpose of analysis and design models and how they different. Keep the conversation non-technical at this stage. The principles for both analysis and design introduce concepts that you can choose to postpone until you cover these subjects in more detail. However, it’s not a bad idea to present each briefly, foreshadowing the material to be presented later in the course. Emphasize that the agile modeling principles presented here are applicable to all software engineering modeling and represent best practice across the board. I would not consider the task set for analysis and design modeling at this stage. Simply note them and indicate that each will be discussed during coverage of the topic later in the course. 4.3.4 Construction Principles In this text “construction” is defined as being composed of both coding and testing. The coding principles should be a view of material students saw in their previous programming courses. Many students do not receive much information on systematic testing in their programming courses. The most important point in this section is that testing must be linked to the customer requirements. A second key point is that the purpose of testing is to uncover defects. Exhaustive testing is not possible so processing a few test cases successfully does not guarantee that you have bug free program. Unit testing of components and integration testing will be discussed in greater later in the text along with software quality assurance activities. The only place that coding is discussed within SEPA is in section 4.3.4. [For those who object to this slight, I can only say that large systems rarely fail because developers are poor coders. Misunderstood or ambiguous requirements, poor design, and inadequate testing are the real culprits.] It’s worth spending some time addressing preparation principles, coding principles, and validation principles. Although testing has received increased attention over the past decade, I still consider it the weakest part of software engineering practice for most organizations. Therefore, it’s worth considering these principles now, and again when you cover Part 3 of this book (specifically Chapters 17 - 20. I would not consider the task set for testing at this stage. Simply note it and indicate that it will be discussed during coverage of the topic later in the course. 4.3.5 Deployment Principles This section makes some important points about software delivery. Some of them will seem silly to your students (like removing known bugs before delivering products). Some of them will not be intuitively obvious to your students (like planning for user instruction and feedback mechanisms as part of the delivery package). Managing customer expectations and controlling feature creep are also mentioned in this section. It is important to make sure your students understand that software is not delivered and abandoned. Support and maintenance of software and documentation based on customer feedback is an ongoing process. This is especially true for agile software processes. These concepts will be discussed later in the text in the chapters dealing with software quality assurance and configuration management. The vast majority of software engineering courses (and textbooks) spend relatively little time (or pages) discussing what happens after software is built. SEPA does discuss deployment here and considers maintenance and support issues in Chapters 1 and 29. Spend some class time discussing the principles discussed here, emphasizing that support and maintenance of software continues long after the team that built the system has moved on to other things. The people who do this support and maintenance work need the information contained in work products produced during the software process. In essence, these work products are a legacy left to those that follow. Spend time on the deployment task set with particular emphasis on the meaning of the tasks noted. Chapter 5 Understanding Requirements CHAPTER OVERVIEW AND COMMENTS The intent of this chapter is to emphasize the need to understand customer requirements before you do other software engineering work. Hence, it presents requirements engineering tasks and basic requirements analysis concepts and principles. Students must understand that customer communication and requirements elicitation are pivot activities in the software process. Even the best technology will fail if you don’t understand what the customer wants. Regardless of the process model used by software engineers, requirements engineering is an essential part of a successful software development project. The focus of this chapter is gathering the information needed to build the information, function, and behavioral portions of the analysis model. Creation of use-cases is described. Several UML diagrams useful to analysis modeling are discussed but will be presented in much greater detail in Chapters 6 and 7. In this chapter six requirements engineering tasks are considered—inception, elicitation, elaboration, negotiation, specification, and validation. 5.1 Requirements Engineering A good way for you to introduce these tasks is to create a scenario in which your students must address what they’d do to accomplish each for a hypothetical project you pose. For example, assume you work for a music company and want to develop a system that will distribute .mp3 files for very low prices. What things will happen during inception, elicitation, elaboration, negotiation, specification, and validation? Students need to experience the process of working with a customer to develop the requirements for a software product before they graduate. It is hard for students to do this in a one-semester software engineering course, but they should do this as part of a senior design project. Trying to understand customers' needs and negotiating changing requirements is part of every software development project. Students also need to experience the opportunity to judge the feasibility of solutions and steering the customer toward options that can be completed with the resources available. Spend a few moments going over the requirement validation checklist presented in the sidebar. 5.2 Establishing the Groundwork In this section, requirements engineering is described as a bridge between communication and analysis modeling and design and construction. It is important to point out to your students that even though the requirements engineering activities may be abbreviated, they cannot be eliminated. Like all software engineering neophytes (and quite a few seasoned pros), your students will want to jump right in to the project by doing a bit of cursory design and then coding their hearts out. A bad mistake! The term “stakeholder” is used throughout SEPA. It’s very important that your students understand its meaning and just who is a stakeholder. Be sure you emphasize this. Spend some time discussing how you reconcile multiple viewpoints (and conflicting requirements). Also discuss how collaboration is best achieved on a software project. Two elicitation techniques are discussed (the use of context free questions in structured customer interviews and collaborative requirement gathering. Having students use these techniques to work with real customers or role-play working with simulated customers is a worthwhile task. If there is not enough time to do this in a one-semester course, if should be done in the senior projects course. The series of context-free questions listed in section 5.2.4 should help the students gain a rudimentary understanding of the type of dialog needed between developers and customers when begin a software development project. 5.3 Eliciting Requirements This section discusses two techniques for involving all stakeholders in gathering of system requirements. The first technique is called collaborative requirements gathering. In this approach the stakeholders collaborate under the supervision of a neutral facilitator to determine the problem scope and define an initial set of requirements. The second technique is called quality function deployment. In this technique the customer is asked to prioritize the requirements based on their relative value to the users of the proposed system. Use-cases are mentioned briefly in this section and discussed in greater detail in section 7.5. Basic requirement elicitation is presented for SafeHome. It would be worthwhile to cover this in lecture. 5.4 Developing Use-Cases Use-cases are a pivotal topic throughout SEPA. Be certain that you emphasize and re-emphasize their importance as a requirements gathering tool. Go though each of the questions that use-cases ask and answer. Students often have difficulty understanding what an “actor” is. Be sure you explain the concept to them. Note: If you’re a purist, then you’ll insist that students develop use-cases by following the template suggested in this section. However, you can be a bit more relaxed and have students develop a more narrative and informal “preliminary use-case.” The idea is to have them start thinking in scenarios—in my opinion, the form the scenario takes is secondary. Spend a bit of time discussing the syntax and semantics of UML use-case diagrams. Your students may need some help in thinking about people and devices as actors. Object-oriented analysis does not always come easily (even if your students are good object-oriented programmers). Functional decomposition may seem more natural to them in the beginning. 5.5 Building the Requirements Model This section discusses analysis modeling. The elements of the analysis model (scenario-based, class-based, behavioral, and flow-oriented) are introduced. Several UML diagrams (use-case, activity, class, state) are described. It may be helpful to show your students additional examples of these diagrams. Dataflow diagrams are introduced briefly here and will be discussed in more detail in the next chapter. The template for an analysis pattern is presented. The analysis model is considered in detail in Chapters 6 and 7. At this point, you should focus on defining the four major elements of the model: scenario-based elements (use-cases), class-based elements, behavioral elements, and flow-oriented elements. A few simple examples can serve to foreshadow the content of Chapters 6 and 7, but there’s no need to go into detail at this point. Analysis patterns are considered in Section 5.5.2. If time permits, you might want to present one or two actual analysis patterns. As important, be certain to emphasize how these can help a software engineer as requirement management activities are conducted. 5.6 Negotiating Requirements Most students have very little experience in the art of negotiation. The key point is to remind students to avoid an “us versus them” mentality when they become software developers. The negotiation guidelines included in this section should be helpful to your students in this regard. If time permits, discuss how the negotiation process works and point out tricks of the trade. You’ll provide students with information that will serve them well. 5.7 Validating Requirements The purpose of requirements validation is to make sure that the customer and developer agree on details of the software requirements (or prototype) before beginning the major design work. This implies that both the customer and developer need to be present during the validation process. The list of review questions should provide a good guidance for conducted reviews of analysis models. If time permits, your students may benefit from actually reviewing the analysis model for a software product by role-playing using these questions. Chapter 6 Requirements Modeling: Scenarios, Information, and Analysis Classes CHAPTER OVERVIEW AND COMMENTS Chapters 6 and 7 present the broad spectrum of topics that should be considered to develop a complete view of requirements modeling. The intent of this chapter is to provide the reader with an understanding of the mechanics for developing user scenarios, modeling information, and creating analysis classes. In this and the previous edition of SEPA, conventional and object-oriented representations of the analysis model are merged. The object-oriented analysis process begins with the development of use-cases (usage scenarios) and a Class-Responsibility-Collaborator (CRC) card model. The CRC card is used as the basis for developing a network of objects that comprise the object-relationship model (UML class diagrams). UML activity diagrams and UML swim lane diagrams are used to model the activity sequences for the use-cases. The event sequences implied by the use-cases provide the basis for the state transition diagram that is used to define the object-behavior model. Dataflow diagram are also used in OOA modeling. Students should work thought the process of building a set of CRC cards and use these cards to build a complete OOA model for their own projects. Note: Both Chapters 6 and 7 are lengthy chapters. Plan to spend a number of lecture periods covering the material presented here and in the following chapter. 6.1 Requirements Analysis Be certain to emphasize the objectives of requirements analysis: (1) to describe what the customer requires, (2) to establish a basis for the creation of a software design, and (3) to define a set of requirements that can be validated once the software is built. Also, emphasize the “rules of thumb” presented in Section 6.1.2. Domain analysis is discussed in this section as an umbrella activity in which a set of reusable classes is defined following the examination of application area. Students may benefit from examining at a case study in which a library of reusable software components is assembled over time. Students might also benefit from an assignment in which they are required to devise a plan for building a new software application out of an existing set of reusable objects. 6.2 Scenario-Based Modeling The degree to which you emphasize this section will depend on how much time you’ve already spent on use-cases in your discussion of system engineering and requirement engineering. The informal use-case template presented in Chapter 5 should be revisited and then compared to the more formal use-case presentation in this body section. The formal use-case template is presented in the sidebar contained here. 6.3 UML Models that Supplement the Use Case This section presents UML activity diagrams, a mechanism for representing procedural scenarios. It is important to emphasize that the activity diagram is not used to “write the program” at this stage. Rather they are intended to represent topic level procedural scenarios. The key point to emphasize when discussing UML swimlane diagrams (section 6.3.2) is that they are a variation of activity diagrams that “connect” procedural flow to major analysis classes. Students may benefit from trying to represent the usage scenarios from familiar software applications using UML use-case, activity, and swimlane diagrams. These UML representations are valuable in both structured and object-oriented analysis modeling. 6.4 Data Modeling Concepts This section discusses data objects, attributes and relationships— the key elements of a data model. It also considers cardinality and modality. The Entity Relationship Diagram (ERD) is deemphasized in this edition of SEPA (UML-based diagrams can achieve most, if not all, of it representational objectives). However, you might consider supplementing SEPA’s presentation with additional material if ERDs are important in your context. 6.5 Class-Based Modeling This section describes the process of developing an object-oriented analysis (OOA) model. The generic process described begins with guidelines for identifying potential analysis classes, suggestions for defining attributes and operations for those classes, and a discussion of the Class-Responsibility-Collaborator (CRC) model. The CRC card is used as the basis for developing a network of objects that comprise the object-relationship model. CRC modeling has significant value and should be emphasized here. Students need to experience the process of developing a set of CRC cards for one of their own systems (preferably one that they have written usage scenarios for). They also need to experience the process of conducting walkthroughs of their usage scenarios using their CRC card sets. The process of building a class hierarchy from their debugged CRC system would also be good student assignment. UML diagrams associated with the class-based modeling element are relatively simple, but can still pose a challenge for many students. I recommend supplementing SEPA with additional UML materials so that your students have a solid understanding of class diagrams, associations, aggregations, dependencies, multiplicity. packages, and the like. Chapter 7 Requirements Modeling: Flow, Behavior, Patterns, and WebApps CHAPTER OVERVIEW AND COMMENTS This chapter is a continuation of Chapter 6 and presents other elements of a requirements model that I have organized into four elements—scenario-based, flow-oriented, class-based, and behavioral. 7.1 Requirements Modeling Strategies This section presents a brief discussion of structured analysis (the “old school” approach to analysis modeling) and object-oriented analysis (the approach that dominates the discussion in this chapter). You should emphasize that both modeling approaches focus on the same things, but their overall viewpoint and philosophy differ. You should also note that structured analysis has merit and can represent things in ways that object-oriented modeling cannot. Finally, you might note that a software engineer borrows the best from each to create effective analysis (and design) models. 7.2 Flow-Oriented Modeling This section describes the use of data flow data diagrams (DFDs) as one means of representing the functional model of a software product. Students may have difficulty understanding that DFDs do not represent program logic like activity diagrams do. The construction of control flow diagrams from DFDs is described as one method of modeling real-time systems. Students will need to go through the process of constructing (and refining) at least one DFD on their own to begin to feel comfortable with functional modeling. The details of constructing DFDs are described. Because some professors view this approach as outdated, you can choose to skip this topic. However, just as many professors continue to emphasize the topic and may choose the supplement this section with additional material. 7.3 Creating a Behavioral Model This section describes the use of UML state diagrams (SDs) as one means of representing a software behavioral model. Students may have seen state diagrams in their theory of computation or discrete mathematics classes. If they have not, you may need to show students some more examples. Students often tend to omit state transitions to handle erroneous inputs when building their first SD. Students will need to construct at least one SD on their own before they begin to feel comfortable with behavioral modeling. The UML sequence diagram is another form of behavioral model that indicate how events cause transitions from object to object. To build the object-behavior model, students will need to return to the use-cases and identify the sequences of events. Events occur whenever an actor (person, device, or system) and the OO system exchange information. Students should be encouraged to markup their own use-cases to determine the events. The events trigger transitions between system states. Sequences of events can be used to build a state diagram that represents the object-behavioral model. 7.4 Requirements Patterns Most software engineering courses emphasize design patterns (see Chapter 12) and spend relatively little time considering requirements level patterns. I think that’s a mistake. In order to understand problem requirements, a good analyst looks for patterns that are repeatedly encountered and have demonstrably effective solutions. In this section, I present a brief discuss of requirements patterns in general and a specific example that illustrates them. If you have the time, it would be a good idea to have your students identify requirements patterns from other engineering disciplines, e.g., automotive patterns or telephony patterns. 7.5 Requirements Modeling for WebApps The discussion that addresses “how much analysis is enough” applies to all software and might be worth emphasizing in class. If you have the time, requirements model input and output (Sections 7.5.2 and 7.5.3) can be expanded with specific examples from real world WebApps. As a minimum, you can have your students develop a data tree (Figure 7.10) for content objects represented at a website of their choosing. Chapter 8 Design Concepts CHAPTER OVERVIEW AND COMMENTS This intent of this chapter is to provide an introduction to the design process and to describe fundamental design concepts that are essential to an understanding of any software design method. Basic concepts are introduced and a fundamental design model is discussed. The design model consists of the data design, architectural design, interface design, and component-level design. Although many of the design concepts discussed in this chapter may have been presented in earlier courses, it is important to re-emphasize each concept so that all students have a consistent understanding of them. Students should be encouraged to use the design document template form the SEPA web site as a basis for the design documents they write for their own software projects. 8.1 Design within the Context of Software Engineering It is important for students to understand the mapping from analysis model to the design model. Spend some time discussing Figure 8.1 to establish the relationships. Students should be reminded that all design work products must be traceable to software requirements and that all design work products must be reviewed for quality. 8.2 The Design Process Be sure your students understand that software quality begins with solid design. The first part of this section addresses the elements of software quality. Be certain to emphasize these. Make the point that software design is an iterative process that is traceable to software requirements analysis. Students need to be reminded that many software projects iterate through the analysis and design phases several times. Pure separation of analysis and design may not always be possible or desirable. Having your students discuss the generic design guidelines as a class may be a worthwhile activity. It may be a bit early to discuss the task set presented in the sidebar of Section 8.2.2. Use it as a TOC for topics to be presented in this and the following chapters. 8.3 Design Concepts This section discusses many significant design concepts (abstraction, refinement, modularity, architecture, patterns, refactoring, functional independence, information hiding, refactoring, and OO design concepts). For some of these concepts, a simple definition will be sufficient. For others (e.g. functional independence) presenting additional examples may be helpful. Be absolutely certain that your students understand each. 8.4 The Design Model Students should be told that the details required to develop a complete design model appear in Chapters 9 - 13). Students should be reminded that design changes are inevitable and that delaying component level design can reduce the impact of these changes. Cover each of the design “elements” presented in this section to foreshadow content to be discussed in detail in later chapters. The use of UML notation in design models is described and several examples are given. Students should be encouraged to create some of these diagrams as part of the process of building a design model for a familiar software application. A document template appears on the SEPA web site. It is important to get students in the habit of using diagrams to represent design information whenever it is feasible. Students should be reminded that design changes are inevitable and that delaying component level design can reduce the impact of these changes. Chapter 9 Architectural Design CHAPTER OVERVIEW AND COMMENTS The intent of this chapter is to provide a systematic approach for the derivation of the architectural design. Architectural design encompasses both the data architecture and the program structure layers of the design model. A general introduction to software architecture is presented. Examples are presented to illustrate the use of transform mapping and transaction mapping as means of building the architectural model using structured design approach. Students should be reminded that quality reviews need to be conducted for the architectural model work products. 9.1 Software Architecture This section defines the term “software architecture” as a framework made up of the system structures that comprise the software components, their properties, and the relationships among these components. The goal of the architectural model is to allow the software engineer to view and evaluate the system as a whole before moving to component design. To get a discussion of software architecture started, ask your students what the architect of a building does and why it’s important. Draw parallels to software. 9.2 Architectural Genres Your students should understand that different software categories (genres) may demand customized architectures to meet their specific needs. It would be worthwhile to present a completed Architectural Decision Description Template (sidebar) to help your students understand the issues that are addressed as a designer or a design team selects the appropriate architectural design. If time permits, you should visit Grady Booch’s evolving website and spend some time delving into the topics presented their. 9.3 Architectural Styles Be sure that your students understand that an architectural style is a transformation that is imposed on the design of an entire system. The intent is to establish a structure for all components of the system. A pattern also imposes a transformation on the design of an architecture but differs from a style as described in the introduction of this section. Patterns can be used in conjunction with an architectural style the shape the overall structure of a system. A taxonomy of architectural styles is described in Section 9.3.1. With the exception of object-oriented architectures, the architecture modeling technique discussed in this chapter is generally applicable to each of these architectural styles. However, the derivation of the call and return architecture is emphasized. Students should be encouraged to use the questions dealing with control and data issues as basis for assessing the quality of the initial architectural framework before doing more detailed analyses of the proposed software architecture. Architectural patterns (Section 9.3.2) are relatively obvious for a house or some other physical object, but they are more abstract for software. Spend some time discussing the patterns noted in this section. 9.4 Architectural Design The architectural design process begins by representing the system in context. Spend some time discussing the ACD presented in Figures 9.5 and 9.6. Be sure that your students understand the meaning on an “archetype” (Section 9.4.2) and how it fits into the notion of the architectural design. The derivation of components that populate the architecture sometime seems like a slight of hand. Be sure you provide examples of how this is done. Both good examples and bad examples might help their understanding. 9.5 Analyzing Alternative Architectural Designs This section provides students with an iterative method for performing trade-off analyses of alternative architectural designs for the same software system. Students should find enough information in this section to be able to apply this technique to their own architectural designs. The second approach presented in this section applies pseudo quantitative techniques as a means of assessing the quality of an architectural design. Students might appreciate seeing an example of this approach applied to real system. 9.6 Mapping Data Flow into Software Architecture This section describes the general process of mapping requirements into software architectures during the structured design process. The technique described in this chapter is based on analysis of the data flow diagram discussed briefly in Chapter 8. The key point to get across to students is the difference between transform flow and transaction flow. Transform flow is largely sequential and has very little divergence along the action path. Transaction flow can follow many action paths and the processing of a single data item often triggers path selection. The process of mapping a data flow diagram with transform characteristics into a specific architectural style is illustrated in Section 9.6.1. Students should be reminded to strive for DFD bubbles that exhibit high cohesion. Students should be told that both transform and transaction flows may occur in the same DFD. Each subflow should be classified and mapped using the appropriate technique (transform or transaction). Students may need to see more than one example of transform mapping before they attempt to do it on their own. Transaction mapping has been deleted from this edition of SEPA (for space reasons). If you choose, you can present the topic, emphasizing that transform mapping is similar to transform, but focuses on transaction (not transform) centers. In transaction mapping, the first level factoring results in the derivation of the control hierarchy. The second level factoring distributes the low-level modules among the appropriate controller. Refining the architectural model involves writing a fair amount of documentation (e.g. process narratives, interface descriptions, limitations, etc.) and reviewing work products for quality. Student projects need to be subjected to the refinement process before detailed design work is undertaken. It may be worthwhile to have the students look over the design document template from the SEPA web site to see where they need to go next with their design work. Chapter 10 Component-Level Design CHAPTER OVERVIEW AND COMMENTS This chapter discusses the portion of the software development process in which the design is elaborated and the individual data elements and operations are designed in detail. First, different views of a “component” are introduced. Guidelines for the design of object-oriented and traditional (conventional) program components are presented. In this edition, I have integrated a discussion of component-based software development into this chapter. Note: This is as close as SEPA gets to a discussion of coding. If you want to have your students implement software so that it is executable, the discussion of component-level design can be extended to show how the design is implemented in a programming language. 10.1 What is a Component? This section defines the term component and discusses the differences between object-oriented, traditional, and process related views of component-level design. UML defines a component as “… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” You should parse this definition for your students, discussion each important phrase within the context of component-level design. Be certain that your students understand the rather fundamental difference between the object-oriented and conventional (traditional) view of a software component. In addition, the idea of different categories of components (e.g., control, problem domain, infrastructure) should be discussed. Finally, the process (CBSE) view of a component should be presented. Middleware components should be discussed, but there is no need to emphasize them if time is short. 10.2 Designing Class-Based Components Spend some time on the basic design principles presented in Section 10.2.1. It would be a good idea to provide additional examples to help your students understand each. The guidelines presented in Section 10.2.2 are worthy of classroom discussion. Again additional examples will enhance understanding. The concepts of cohesion and coupling are very important. Be certain that your students (1) understand what they are in this context and (2) know how to create component designs that achieve them. The sidebars presented in Sections 10.2.3 and 10.2.4 can be discussed in class to help cement student understanding. 10.3 Conducting Component-Level Design The steps discussed in this section provide a reasonable task set for designing a component. You should emphasize that (1) design classes in the problem domain are usually custom-designed, however, if an organization has encouraged design for reuse, there may be an existing component that fits the bill; (2) design classes corresponding to the infrastructure domain can sometimes be often from existing class libraries; (3) a UML collaboration diagram provides an indication of message passing between components. The printing system example presented in this section can be elaborated to provide your students with a more in-depth view of the component design process. The quote by Blaise Pascal (margin) deserves mention in the classroom. Too often, there is a tendency to develop complex designs for relatively simple functions. Stress simplicity! Discuss refactoring as a design tactic and provide a few simple examples using source code or PDL. 10.4 Component-Level Design for WebApps The key here is to emphasize the notion of a “component” in the context of web-based system and applications and the design issues that come into play when you consider different types of WebApp components. 10.5 Designing Traditional Components This section reviews the elements of the structured programming and a number of representation techniques for procedural design. Students may need to see examples of representing algorithms using flowcharts, if they are not familiar with them from earlier course work. Be sure to note that UML activity diagrams can be used in lieu of flowcharts. Decision tables are discussed as an example of a tabular tool for representing the connections between conditions and actions. Students will benefit from the experience of developing decision tables for their own projects. Program design language (PDL) is discussed in detail in this section. The hardest part about getting students to express their designs using a PDL is getting them to stop trying to write directly in their favorite programming language (C++, Java, etc.). Students often fail to distinguish between low level design and implementation. Requiring students to include pseudocode representations of their algorithms as part of the module design documentation seems to help them understand some of the differences between the two. 10.6 Component-Based Development This section describes component-based development (CBD) (a.k.a. component-based software engineering, CBSE) as a process that emphasizes the design and construction of systems with reusable software components. CBD has two parallel engineering activities, domain engineering (discussed earlier in the text) and component-based software development. The important point to emphasize to students is that custom software components are only created when existing components cannot be modified for reuse in the system under development. It is also important to remind students that formal technical reviews and testing are still used to ensure the quality of the final product. The advantage, of course, is that less time is spent designing and coding, so software can be produced less expensively. Students would benefit from having access to a library of commercial off-the-shelf components or at least a locally developed component library. 10.6.1 Domain Engineering Students should make sure they understand the three major domain engineering activities (analysis, construction, and dissemination). It is important for students to remember is that the purpose of conducting domain analysis is to identify reusable software components. Structural modeling is an important pattern-based domain engineering approach. Students may benefit from trying to conduct their own domain analysis. Alternatively, they may benefit from discussing a real world case study that includes domain analysis. A useful exercise is to have students identify domain classes (or functions) for a domain such as “retailing” or “health care.” 10.6.2 Component Qualification, Adaptation, and Composition The point of emphasis for this section is that components reside in a library and that before they can be used, they must be qualified, adapted and or aggregated as required. If you class is composed of industry professionals, you might consider the economic and schedule costs of doing this, as opposed to creation from scratch. You might also consider the project costs associated with the creation of reusable components. 10.6.3 Analysis and Design for Reuse This section presents a brief overview of a reasonably complex topic. You might choose to reintroduce the design concepts presented in Chapter 8 and discuss how they may or may not lead to DFR. 10.6.4 Classifying and Retrieving Components This section discusses the issues associated with indexing and retrieving software components from a reuse library. It also describes the necessary features for a component reuse environment. The material is presented at a fairly general level. If your students are familiar with multimedia databases and client-server computing, you might explore some of the implementation concerns that need to be addressed to construct a reuse repository by examining a real life example of one. Chapter 11 User Interface Design CHAPTER OVERVIEW AND COMMENTS Virtually all modern computer-based systems (and many legacy systems that are reengineered) have some type of interactive user interface, and most require reasonably sophisticated interface designs. It is easy for programmers to focus on splashy new technologies and ignore the fact that functionality and usability (not innovation) is what users are most concerned about. This chapter outlines the design processes for software user interfaces. One key point to get across to students is that understanding the user’s task goals and preferred methods of reaching them is essential to good interface design. A second important point is that the user interface should be designed early in the software development process (and not as an after thought). Having students formally evaluate each other’s interfaces using the usability checklist from the SEPA web site is a worthwhile course activity. 11.1 The Golden Rules This section discusses three principles of user interface design that students should be encouraged to follow as they build their own software projects. The first is to place the user in control (which means have the computer interface support the user’s understanding of a task and do not force the user to follow the computer's way of doing things). The second (reduce the user’s memory load) means place all necessary information in the screen at the same time. The third is consistency of form and behavior. It is sometimes good to bring in commercial software and try to see how well the interface designers seem to have followed these guidelines. 11.2 User Interface Analysis and Design This section presents the notion that user interface design is really the process of reconciling different models (the user model, a design model, a mental model, and an implementation model) of the user interface. The point to get across to students is that the overall goal of the interface design process is to understand the user and the user’s task so well that the implementation model will match the user’s perception of the of the system. This will make the system easy to learn and easy to use. If your course is more than one semester in length, having students build user interfaces for real customers can be a very instructive activity for them. 11.3 Interface Analysis In order to understand the user’s perception of the interface, a variety of different information sources are noted. Each of these (Section 11.3.1) should be discussed so that the student understand how each is used and how they differ from one another. The questions noted in this section should be asked of every user type that will interact with the software via the interface. Section 11.3.2 consider task analysis and modeling. The questions noted at the beginning of this section are answered as part of this task. This is an important section and you should dedicate lecture time to each of the techniques noted here—use-cases, task elaboration, object elaboration, workflow analysis, and hierarchical representation. Use-cases provide worthwhile input for task analysis. If time permits, have your students write a set of use-cases that describe how they would like to interact with a futuristic car that drives itself. Don’t get hung up on the technology that accomplishes this—assume it exists. Just address how to be interact with the car when it is standing still and moving. Elaboration (Section 11.3.2) is pivotal for many software engineering activities. Discuss task and object elaboration for a user interface and elaborate on the tasks for the futuristic car example. Do the same for the workflow. 11.4 Interface Design Steps Regardless of the technique used to create the user task model, a model describing the users' actions using the operators (keys pressed, mouse operations, menu selections, icon manipulations, commands typed) available in the proposed computer system should be built for each usage scenario. Students will find it very instructive to story board prototypes for task scenarios using the operators from familiar user interfaces. These paper prototypes can be “tested” quickly and inexpensively. A number of UI design patterns are discussed in Section 11.4.2. Have your student visit www.hcipatterns.org to explore the design patterns available for user interfaces. Also, have them find actual interfaces that exhibit the patterns provided as examples in this section. You should dedicate some lecture time to the design issues noted in Section 11.4.3. In many cases features like help facilities, accessibility, internationalization, and error handling are design afterthoughts. Be sure your students understand that these features can be as important as other UI functionality. 11.5 WebApp Interface Design Tognozzi’s design principles for WebApps apply equally well to most aspects of interface design for any type of software. Be sure to cover them. 11.6 Design Evaluation Two interface design evaluation techniques are mentioned in this section, usability questionnaires and usability testing. Having the students use a usability questionnaire similar to the one on the SEPA web site to evaluate software user interfaces is fairly easy to do. The process of learning how to design good user interfaces often begins with learning to identify the weaknesses in existing products. Usability testing involves more statistics and research design knowledge than is typically found in undergraduate computing students. It is important to remind students, that beginning to evaluate user interface prototypes early in the design phase reduces the risk of building an interface not acceptable to the customer. Instructor Manual for Software Engineering: A Practitioner's Approach Roger S. Pressman 9780071267823, 9789355325044
Download
Close
Close
