Chapter Comments
Chapter
8-1
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 objectoriented analysis process begins with the development of usecases (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 objectrelationship 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
8-2
SEPA, 6/e Instructor’s Guide
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 objectoriented 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 (UMLbased 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
Chapter Comments
8-3
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 usecase, activity, and swimlane diagrams. These UML
representations are valuable in both structured and objectoriented 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
8-4
SEPA, 6/e Instructor’s Guide
comfortable with functional modeling. The details of
constructing DFDs are described.
8.7
Class-Based Modeling
This section describes the process of developing an objectoriented 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-ResponsibilityCollaborator (CRC) model. The CRC card is used as the basis for
developing a network of objects that comprise the objectrelationship 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.
Chapter Comments
8-5
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.