1. CONCEPTUAL DESIGN: UML CLASS DIAGRAM RELATIONSHIPS

2. What is UML?
A standardized, graphical “modeling language” for communicating software design.
Allows implementation-independent specification of:
user/system interactions (required behaviors)
partitioning of responsibility (OO)
integration with larger or existing systems
data flow and dependency
operation orderings (algorithms)
concurrent operations
Pretty pictures.
UML is not “process”. (That is, it doesn’t tell you how to do things, only what you should do.)

3. Motivations for UML
UML is a fusion of ideas from several precursor modeling languages.
We need a modeling language to:
help develop efficient, effective and correct designs, particularly Object Oriented designs.
communicate clearly with project stakeholders (concerned parties: developers, customer, etc).
give us the “big picture” view of the project.

4. Types of UML diagrams
There are different types of UML diagram, each with slightly different syntax rules:
use cases.
class diagrams.
sequence diagrams.
package diagrams.
state diagrams
activity diagrams
deployment diagrams.

5. Identify the information system’s purpose
A Simplified Object-Oriented
Systems Analysis & Conceptual Design Methodology
Activities
Identify the information system’s purpose
Identify the information system’s actors and features
Identify Use Cases and create a Use Case Diagram
Identify Objects and their Classes and create a Class Diagram
Create Interaction/Scenario Diagrams
Create Detail Logic for Operations
Repeat activities 1-6 as required to refine the “blueprints”

6. Objects Objects have three responsibilities:
What they know about themselves – (e.g., Attributes)
What they do – (e.g., Operations)
What they know about other objects – (e.g., Relationships)

7. Defining Class Class Objects
A CLASS is a template (specification, blueprint)
for a collection of objects that share a common
set of attributes and operations.
HealthClubMember
Class
Objects
attributes
operations

8. Relationships Generalization (Class-to-Class) (Superclass/Subclass)
A RELATIONSHIP is what a class or an object knows about another class or object.
Generalization (Class-to-Class) (Superclass/Subclass)
Inheritance
Ex: Person - FacultyPerson, StudentPerson, Staff...
Ex: ModesOfTravel - Airplane, Train, Auto, Cycle, Boat...
[Object] Associations
FacultyInformation - CourseInformation
StudentInformation - CourseInformation
[Object] Aggregations & Composition (Whole-Part)
Assembly - Parts
Group - Members
Container - Contents
F o u r T y p e s

9. Relationships
Exist to:
1) show relationships 2) enforce integrity 3) help produce results
In this example:
Removal of a University Course should also remove Students that are in the Course but not Student Information.
Removal of a Student should also remove the Courses that the Student is in but not the University Course.
Removal of a Student in a Course should not affect either University Course or Student Information.
UniversityCourse
StudentInformation 1
0,m 1
StudentInCourse
0,m

10. { UML Class Diagram Notation 1 of 2 Class attributes operations Member
memberNumber
firstName
lastName
telephone
address
city
etc...
checkOutVideo
checkInVideo
buyItem
attributes
operations {
Expanded view of a
Class into its three
sections:
Top: Class Name
Middle: attributes
Bottom: operations

11. UML Class Diagram Notation
2 of 2
Class
Generalization
Relationship
Object
Aggregation
Association
0..*
1..*
Object Composition
Association
0..* 1
Object Association n
Will always be “1”

12. Class Diagram Relationships
Generalization
Object
Association
Aggregation
Composition

13. Generalization (Class-to-Class) (superclass – subclass; supertype – subtype)
A Generalization follows a “is a” or “is a kind of” heuristic from a specialization class to the generalization class. (e.g., student “is a” person, video “is a kind of” inventory).
Common attributes, operations and relationships are located in the generalization class and are inherited by the specialization classes

14. Unique attributes, operations and relationships are located in the specialization classes.
Inherited attributes and operations may be overridden or enhanced in the specialization class depending on programming language support.

15. <<abstract>>
Generalization Example
Others:
Transactions
Things
Places
Etc...
<<abstract>>
Role
attributes
operations
Staff
Faculty
Student
Visitor
attributes
attributes
attributes
attributes
operations
operations
operations
operations
Note: <<abstract>> = no objects

16. Poor Generalization Example
(violates the “is a” or “is a kind of” heuristic)
Person
attributes
operations
Head
Arm
Leg
attributes
attributes
attributes
operations
operations
operations

17. Generalization Inheritance
One-Way
Inheritance
from the
Generalization
to the
Specialization
Common o1 o2 o3
Specialization a1 a2 a3 a4 a5 a6
Specialization a4 a5 a6
Unique o1 o2 o3 o4 o5 o6 o4 o5 o6
(a = attribute; o = operation)

18. Generalization - Multiple Inheritance
Specialization a6 a7 a8 a1
a2 (which one?) a3 a4 a5
inherited attributes o6 o7 o8 o1 o2 o3 o4 o5
(which one?)
inherited operations

19. UML Generalization Notation
Note
Supertype
Useful text
discriminator
Subtype 1
Subtype 2
Note: Supertype = Superclass; Subtype = Subclass

20. <<abstract>>
Generalization - Multiple Classification
Discriminator
Doctor
Female
role
<<abstract>>
Person
Nurse
Gender
{complete}
Male
patient
Physical-
therapist #1
Patient #3 #2

21. Associations Relationships between instances (objects) of classes
Conceptual:
associations can have two roles (bi-directional):
source --> target
target --> source
roles have multiplicity (e.g., cardinality, constraints)
To restrict navigation to one direction only, an arrowhead is used to indicate the navigation direction
No inheritance as in generalizations

22. Object Association Relationship Patterns
b) Object
Aggregation
Associations
Whole
attributes
operations
Class A
attributes
operations x x x x x x x
Part1
attributes
operations
Part2
attributes
operations
PartN
attributes
operations x
Class B
attributes
operations
c) Object
Composition
Associations
(y may not be “1”)
Whole
attributes
operations
Class A
attributes
operations x
Class B
attributes
operations 1 1 x 1 y y y
a) Object Associations
Part1
attributes
operations
Part2
attributes
operations
PartN
attributes
operations

23. Associations role B Class A Class B role A Example: Employee Company
Person
Employer

24. Multiplicities 1 Class exactly one 0..* many (zero or more) Class 0..1
optional
(zero or one)
Class
m..n
numerically
specified
Class
Example:
0..*
Course
CourseOffering 1

25. Aggregation & Composition
Aggregation (shared aggregation):
is a specialized form of ASSOCIATION in which a whole is related to its part(s).
is known as a “part of” or containment relationship and follows the “has a” heuristic
three ways to think about aggregations:
whole-parts
container-contents
group-members
Composition (composite aggregation):
is a stronger version of AGGREGATION
the “part(s)” may belong to only ONE whole
the part(s) are usually expected to “live” and “die” with the whole (“cascading delete”)
Aggregation vs. Composition vs. Association???

26. Aggregation Composition
Faculty
SalesOrder
1..* 1
(team-teaching is possible)
0..*
1..*
CourseTeaching
SalesOrderLineItem
(another: assembly --> part)
(another: hand --> finger)

27. Association, Aggregation and Composition
Template/Pattern
Example w 1
Whole w 2
Whole w 3 w 4
0..* p 6 p 5
0..* p 4 p 3 p 2
Part p 1
Part
(association, aggregation & composition look the same)

28. Multiplicity Example #1
Whole 3 1 5 2
Part1
PartN
One Whole is associated with 5 Part1
One Part1 is associated with 1 Whole
One Whole is associated with 2 PartN
One PartN is associated with 3 Whole
One remote control may control multiple devices! Each device may have multiple controllers. W P W P W P W P P W W

29. Multiplicity Example #2
Class1
max.
2..5 1
min.
1..n
0..*
Class2
Class3
2..5 C1
1..n 1 * C3 C2 C1 C1 C3 C2 C3 C1 C2 C1 C3 C1 C2 C1 C3 C2 C1 C3 C2
etc...
etc...

30. Multiplicity Example #3
FacultyInformation
StudentInformation 1
0..* 1 1 1
1..*
0..*
0..*
DegreeHeld
CommitteeAssign
CourseCompleted
0..*
0..*
CourseTeach
ClubMember

31. “many-to-many” multiplicity
StudentInformation
CourseInformation
0..*
attributes
attributes
operations
0..*
operations
Becomes either
StudentInformation
CourseInformation
StudentInformation
CourseInformation
0..*
attributes
attributes
attributes
attributes
0..*
operations
operations
operations
operations 1 1
A difference between UML 1.0 and 2.0
0..*
0..*
StudentCourseInformation
Attributes that represent the “union” of the two classes are located in this “association” class.
StudentCourseInformation
SemesterTaken
GradeEarned
SemesterTaken
GradeEarned
operations
operations

32. Reflexive Association Relationships
Objects within the same class have a
relationship with each other.
Course
0..*
is pre-requisite for
0..*
has pre-requisite of

33. Video Store – UML Class Diagram1 1
Inventory
SaleItem
RentalItem
Video
Game
ConcessionItem
VCR
0..*
0..*
Transaction
Employee
StoreLocation 1 1
SaleTransaction
RentalTransaction
Suplier
0..* 1 1
0..* 1 1
0..1
0..*
Member
PurchaseOrder
1..*
1..* 1
1..*
SaleRentalLineItem
0..*
0..*
PurchaseOrderLineItem

36. Each purchase order is destined for one supplier
Each purchase order is destined for one supplier. There is at least one item but can be more items.

37. Example: myView->setText(“Help”)

38. A stereotype is one of three types of extensibility mechanisms in the Unified Modeling Language (UML). They allow designers to extend the vocabulary of UML in order to create new model elements, derived from existing ones, but that have specific properties that are suitable for a particular problem domain or otherwise specialized usage. The nomenclature is derived from the original meaning of stereotype, used in printing. For example, when modeling a network you might need to have symbols for representing routers and hubs. By using stereotyped nodes you can make these things appear as primitive building blocks.
Graphically, a stereotype is rendered as a name enclosed by guillemets (« » or, if guillemets proper are unavailable, << >>) and placed above the name of another element.