Systems Analysis and Design in a
Changing World, Tuesday, Feb 27
Today’s Schedule




2
Domain Model Class Diagram
Hierarchies in OO Classes
Class Diagram Notation
For Thursday, March 1
Try out ERDs & Class Diagrams in Visual Paradigm
Recall … Where We Are Headed
3
Event Table:
Catalog of Information about Each Use Case
How do the “events” in Activity Diagram fit?
4
“Things” in Problem Domain

Define system requirements by understanding
system information that needs to be stored

Store information about things in the problem
domain that people deal with when they do their
work

Analysts identify these types of things by considering
each use case in the event table
–
5
What things does the system need to know about and store
information about?
Data Entities Compared to Objects
6
Entity Relationship Diagram
7
The Class Diagram


Unified Modeling Language (UML) diagram
Domain model class diagram
–
–

Design class diagram
–
–
–
8
Models things in the users’ work domain
Used to define requirements for OO (very similar
to entities in ERD)
Models software classes
Adds methods as behaviors
Used in the design activity
UML Class Symbol
9
Domain Model Class Diagram

No methods shown in domain model
–

10
Domain classes are not software classes
Very similar to ERD in Figure 5-25
–
UML and domain model can be used in place of ERD in traditional approach
UML Multiplicity of Associations
11
UML Domain Class Model
12
More Complex Class Concepts

Generalization/specialization hierarchies
–
–
13
General superclasses to specialized subclasses
Inheritance allows subclasses to share
characteristics of their superclasses
A Generalization/Specialization
Class Hierarchy for Motor Vehicles
14
Whole-part hierarchies

Object and its parts
–
–
Aggregation – parts can exist separately
Composition – parts can’t exist separately

15
Hand has fingers and thumb
RMO
Domain
Model
Class
Diagram
16
Design Class Diagram Notation:
Software Classes with Methods
17
Course Enrollment Design Class
Diagram
18
Summary – Modeling for Requirements



Analysis phase – defines system
requirements
Models created to further learning process,
reduce complexity, communicate with team
members, and document requirements
Many types of models used
–
19
Mathematical, descriptive, graphical
Summary – Use Events and Things

Key early step in modeling is to identify and
list
–
–

20
Events that require a use case in the system
Things users deal with in work environment
Use cases (activities) are identified from user
goals and business events that trigger
elementary business processes
Summary – Identifying Events

Business events occur at a specific time and
place
–

Event table records event, trigger, source,
use case, response, and destination
–
21
External events, temporal events, and state events
A catalog of information about each use case
Summary – Using Things



“Things” are what user deals with and system
remembers, such as customer placing an order
Traditional approach uses entity-relationship
diagrams (ERD) for data entities, attributes of
data entities, and relationships between entities
Object-oriented approach uses UML class
diagrams for classes, attributes, methods of
class, and associations among classes
–
–
22
Domain model class diagram (requirements activity)
Design class diagram (design activity)
Now you try it …

Page 193, #15, Computer Lab
–
–
–
23
#15 What are the “things” and relationships?
(skip ERD)
#16 Draw a Class Diagram
Now draw it in Visual Paradigm!
For Thursday, March 1



24
Be ready to do Case Study Real Estate
Multiple Listing Service System (p. 195)
ERDs & Class Diagrams in Visual Paradigm
Assignment #7, Due Sunday, March 4