Chapter 8

Chapter 8

Analysis Modeling

CHAPTER OVERVIEW AND COMMENTS

The intent of this chapter is to provide the reader with an understanding of the mechanics of analysis modeling. The analysis model is organized into four elements—scenario-based, flow-oriented, class-based, and behavioral.

In this 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: This is a lengthy chapter. Plan to spend a number of lecture periods covering the material presented here.

8.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 8.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.

8.2    Analysis Modeling Concepts and Approaches

This section presents a brief overview 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.

8.3    Data Modeling

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.

8.4    Object-Oriented Concepts

This section has been included for those who may not have a background in OO. There are three key definitions students need to learn (class, instance, and inheritance). Students should understand the differences between the terms class (data type) and instance (variable) with regard to objects. Students should be encouraged to think of objects as abstract data types with private data members (attributes) and public operators (methods).  Messages are similar to function calls in imperative programming languages. If your students have not programmed in a language that supports objects, you may need to spend some time explaining why encapsulation, inheritance, and polymorphism are supported better by objects than without them. Presenting some examples showing code reuse via inheritance may be helpful. Students will struggle with the concept of polymorphism, if they have not seen it prior to this course.

8.5    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 formal use-case template presented in Chapter 7 should be revisited and then compared to the less formal use-case presentation in this body section. The formal use-case template is presented in the sidebar contained here.

Section 8.5.2 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 8.5.3) 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.

8.6    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.

8.7    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.

8.8    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.