The Plan

Identify the “Things” in the problem domain

Entity-Relationship Diagrams
Domain Model Class Diagrams
State Machine Diagrams
Overview of Activities
More Analysis Activities:
◦ ER Diagrams
◦ Domain Model Class Diagrams
◦ State Machine Diagrams
◦ Use Case Descriptions
◦ Activity Diagrams (DFDs)
◦ System Sequence Diagrams
Design Activities (after the break)
 Analysis Models Design Models Programming Models

Info about Problem domain Design

things class diagram class diagram

Object-Oriented
Use case Communications
program classes
Descriptions Diagrams
with methods
Info about
process flow System Sequence Sequence
Diagrams Diagrams

Activity CRC Cards

Diagrams
Early Analysis activities
Analysis:
◦ User Stories
◦ Use Cases
◦ User Goal Technique
◦ Event Decomposition technique
◦ Use these as inputs for next phases
Techniques for identifying “things”
Brainstorming Technique
Noun Technique
Brainstorm Technique
Ask users to name all the things they work with
Types of thing:
◦ Tangible
◦ Roles
◦ Organizational Units
◦ Devices
◦ Sites/Locations
◦ Incidents, events, interactions
How to effectively brainstorm
Start with listing as many as you can
Consult with users
Look at use cases
◦ what are affected by them?
Brainstorm Technique
Steps to Identify “Things”
1. Pick a user and some use cases or user stories
2. Brainstorm with user to find all the things involved with use cases
3. Use the types (list of types to prompt) to ask questions about
potential things
4. Continue with other types of user
5. Merge results, eliminate duplicates
Noun Technique
A noun is a person, place, or thing
List all nouns users mention
Look for nouns in documentation
Have discussions with stakeholders, and capture nouns
Noun Technique
Steps to Identify “Things”
1. Use use cases and actors to identify all the nouns
2. Use information from: procedures, documentation to add to the
list (items or categories)
3. Refine the list
1. inclusion
2. exclusion
3. research
Refining the List
Inclusion: Include if
◦ it is unique
◦ it is within the scope of the system
◦ the system needs more than one of them
Exclusion: exclude if
◦ it is a synonym for something already included
◦ it is an output of the system (product of other information)
◦ it is an input that results in other information being identified
Research: undetermined if:
◦ it may be an attribute of another thing
◦ it may not be needed if assumptions change
Identified Noun Notes
Accounting There’s only one, we don’t need to store it.
Back order A kind or order? A value of an order status?
Back-order information Output produced with other info.
Bank Only one, we don’t need to store.
Catalog Different ones for different seasons.
Catalog activity reports Output produced from other info:
Catalog details Same as catalog? Same as product items in catalog?
Change request Input resulting in changes to an order.
Charge adjustment Input resulting in a transaction.
Color a piece of info about a product:
Confirmation Output produces from other info.
Credit card info Part of an order? Part of customer info?
Customer A key thing with lots of details:
Customer account Maybe needed if RMO payment plan is included.
Identified Noun Notes
Accounting There’s only one, we don’t need to store it. Exclude
Back order A kind or order? A value of an order status? Research
Back-order information Output produced with other info. Exclude
Bank Only one, we don’t need to store. Exclude
Catalog Different ones for different seasons. Include
Catalog activity reports Output produced from other info: Exclude
Catalog details Same as catalog? Same as product items in catalog? Research
Change request Input resulting in changes to an order. Exclude
Charge adjustment Input resulting in a transaction. Exclude
Color a piece of info about a product: Exclude
Confirmation Output produces from other info. Exclude
Credit card info Part of an order? Part of customer info? research
Customer A key thing with lots of details: Include
Customer account Maybe needed if RMO payment plan is included. Research
Attributes of Things
Even simple objects have information
◦ what makes them unique
◦ name
◦ phone number
Need to identify them too
Special attributes:
◦ identifier or key
◦ compound attributes
RMO example
What are some possible attributes of:
◦ Customer?
◦ Catalog?
Associations Among Things
Definition: An association, in UML, is a naturally occurring
relationship between specific things
Definition: A relationship, in db management, describes a naturally
occurring association between specific things
RMO Example
What are some associations that a Customer has?
Associations Between Things
Associations have:
◦ direction
◦ cardinality/multiplicity
Cardinality/Multiplicity
Definition: Cardinality, in db management, is a measure of the
number of links in a relationship between one thing, and one or
more other things

Definition: Multiplicity, in UML, is a measure of the number of links

in an association between a thing, and one or more other things

Definition: Multiplicity constraint is an actual numeric count of the

constraints on things in the association
Examples
Customers and orders
◦ how many orders can a customer have?
◦ how many customers can a particular order have?
◦ how many items can an order contain?
◦ how many orders can an item be on?
Kinds of Association
Binary associations
◦ between two different kinds of thing
unary associations
◦ between two of the same kind of thing
ternary associations
◦ between three different kinds of thing
n-ary associations
◦ between n different kinds of thing
Kinds of Association
What are some examples of:
◦ Binary associations
◦ unary associations
◦ ternary associations
◦ n-ary associations
Drawing pictures of associations
Associations can be easily shared using images:
◦ ER Diagrams
◦ UML Diagrams
Entity-Relationship (ER) Diagrams
Data Entities (things)
Relationships (associations)
Cardinality
Attributes (of entities)
from wikipedia

example of crow’s foot notation

an artist may have 0 or many songs
a song must have exactly one artist
Cardinality
Expanded ERD
Can also include attributes in the entities
Try it...
Build an ERD for the following:
A student has zero or more courses, and a course has 1 or more
students
An instructor teaches zero or more courses, and a course has exactly
one instructor
A course has one or more sections, a section has exactly one course
A student fills exactly one seat, a seat is assigned to exactly one
student
Domain Model Class Diagrams
Class:
◦ a way to classify a set of things
Domain Class:
◦ a class that describes a thing in the problem domain
Class Diagram:
◦ classes and their associations among classes
Domain Class Diagram:
◦ only includes classes from the problem domain
Example
Multiplicity in Class Diagrams
0..1 *
◦ zero or 1 ◦ zero or many
1 1..*
◦ exactly 1 ◦ one or many
1..1
◦ exactly 1
0..*
◦ zero or many
Try it...
Build domain class diagram for the following:
A student has zero or more courses, and a course has 1 or more
students
An instructor teaches zero or more courses, and a course has exactly
one instructor
A course has one or more sections, a section has exactly one course
A student fills exactly one seat, a seat is assigned to exactly one
student
Consider...
Consider...
Association Classes
Definition: An association class is an association that is also treated
as a class. It is often required in order to capture attributes for the
association
Try it
We will build a class diagram for the following:
A band, its members, and their concerts/performances
1) figure out the associations
2) what are the multiplicities?
3) what attributes are useful?
Other Considerations
Generalization/Specialization Relationships
◦ classes can be subsets of other classes
◦ inheritance hierarchy used to structure or rank objects
◦ Superclass
◦ a more general class
◦ Subclass
◦ a more subordinate class

Abstract and Concrete Classes

◦ Abstract classes must be subclassed and can’t exist as they are
◦ Concrete classes can be instantiated
Whole-Part Relationships
◦ one class is part of another
Example
Draw a hierarchical Class Diagram for Animals. Include at least 3
levels of inheritance
Abstract and Concrete Classes
Abstract and Concrete Classes
We can include abstract classes in more complex class diagrams
Let’s add or Sale Class to a diagram
Practice:
Draw an entity-relationship diagram, including minimum and
maximum cardinality, for the following: The system stores
information about two things: cars and owners. A car has attributes
for make, model, and year. The owner has attributes for name and
address. Assume that a car must be owned by one owner and an
owner can own many cars, but an owner might not own any cars
(perhaps she just sold them all, but you still want a record of her in
the system).
Practice:
Draw a class diagram for the cars and owners described in exercise 1,
but include subclasses for sports car, sedan, and minivan, with
appropriate attributes.
Whole-Part Relationships
In some cases it is important to break an object up into component
parts
Consider the parts as objects themselves
Example:
◦ Computer has: cpu, ram, hd, keyboard, motherboard...
◦ Car has: wheels, engine, clutch, ...
Whole-Part Relationships
Two types:
◦ Aggregate
◦ component parts also exist as individual object
◦ Composite
◦ component parts cannot exist as individual objects
Aggregate Relationships
Composite Relationships
Identifying Object Behaviour
Some objects have state that is important to model
◦ On/off
◦ Shipped
◦ Paid for
◦ ...
We need to identify and document which objects have states that
matter
Identifying Object Behaviour
Definition: State is a semi-permanent condition that can be triggered
by an event.
Definition: Transition is the movement from one state to another
Definition: State-machine diagrams are used to model the state of
objects and their transitions
Which Objects Need State Diagrams
Which of these need state?
◦ Sale?
◦ Customer?
◦ Sale Transaction?
 State Diagrams

Arrows: transition
transition-name(parameters) /action-expression[guard condition]
Rounded rectangle: state
Filled circle: pseudo state (in this case a start state)
Concurrency and Concurrent States
An object can be in more than one state at once
◦ For example, a printer can both be:
◦ On
◦ Idle
Concurrency and Concurrent States
How to develop State Machine Diagrams
1. Identify classes that might have states of interest
◦ Pick those with multiple status conditions the system cares about
2. For each class:
◦ List all states you can
◦ Think about the properties of the physical object (if appl.), and activities done to
it
3. Start building fragments of the diagram
◦ Identify transitions that lead to state changes
4. Put fragments together in the right order
◦ Can be recursive process
How to develop State Machine Diagrams
5. Review paths
◦ Look for concurrent paths
◦ Look for independent paths
6. Look for missed transitions
◦ Go through them pair by pair
◦ Check both directions
7. Expand transitions to add:
◦ Message events
◦ Guard conditions
◦ Action-expressions
8. Review and test
Practice:
Let’s build a state diagram for Boil an Electric Kettle
2) List all the conditions you can
◦ List all status conditions
◦ Properties of physical object
◦ Activities done to object
3) build fragments
◦ Identify transitions that lead to state changes
4) Put fragments together
Practice:
Let’s build a state diagram for Boil an Electric Kettle
5) review paths
◦ Independent paths?
◦ Concurrent paths?
6) Missing transitions?
7) Expand transitions:
◦ Message events
◦ Guard conditions
◦ Action-expressions
8) Test
RMO example
Develop the SaleItem State Machine Diagram
◦ Status conditions:
◦ Ready to be shipped
◦ On back order
◦ Shipped
◦ Can an item be partially shipped?
2) List all the conditions you can
• List all status conditions
• Properties of physical
object
• Activities done to object
RMO Example
Identify exit transitions for each status condition
◦ Ready to be shipped: shipItem
◦ On back order: itemArrived
◦ Shipped: no exit transition
◦ Open: saleComplete

Combine the state-transition pairs into fragments and build a state

machine diagram
RMO Example
Look for concurrent paths
Look for additional transitions
◦ Go through states pair by pair:
◦ Shipped/on back order?
◦ Open on back order?
RMO Example
Complete all transitions
◦ Add correct names
◦ Add start/end states
Test it with users
Practice
Draw a SSD for the following:
◦ Customer Fills shopping cart
◦ Search for an item, until they find one they want
◦ Add it to the cart
Summary
In this section we have seen:
◦ Defining requirements
◦ Developed use cases
◦ Identifying objects, attributes, associations/relationships, ...
◦ Modelled use cases:
◦ Entity relationship diagrams
◦ Domain Model Class diagrams (UML)
◦ State machines
Readings
DFD Modeling Pdf (on course page)