UML Lecture

Class Diagram
Classification of UML 2.5 Diagrams

Structure diagrams show the static

structure of the system and its parts
on different abstraction and
implementation levels and how they
are related to each other.

Behavior diagrams show the dynamic

behavior of the objects in a system, which
can be described as a series of changes to
the system over time.
Recap
• UML Use case diagrams represent the “requirements” of the system. They show how
the users (actors) expect to interface with and get a benefit from the system through
use cases (think user stories with more details).
• It can also show external systems (as actors, typically places to the right of the use
cases) that are needed to provide the functionality.
• Show the dynamic behaviour of the objects in a system.
• User Goal Technique
• CRUD Technique
• Event Decomposition Technique
Class Diagram
• Class diagrams show the building blocks (classes) that are needed to
build the software/system.
• Static Analysis and Design
• Provide a conceptual model of the system in terms of entities and
their relationships
• Used for requirement capture, end-user interaction
• Detailed class diagrams are used for developers
Natural Language
Analysis
• We take a piece of text and identify each of these in turns, creating
lists.
- Not everything we identify will be useful or relevant. That is why they
are candidates.
Once we have our lists, we get rid of:
- Duplicates
- Irrelevancies
- Candidates that are out with our project scope
• What we end up with is a ‘first draft’ of a representation of the system.
NLA Example
We need a system that allows us to manage our library. It needs to let us
add, remove and manipulate books, as well as add, remove and manipulate
customer details. It should keep a database of all the books that are
available on the shelves and those that are in the storeroom.
Patrons should be able to view our catalogue through a webpage and place
holds on the books that they wish to reserve.
NLA Example (Extract Nouns)

We need a system that allows us to manage our library. It needs to let us

add, remove and manipulate books, as well as add, remove and manipulate
customer details. It should keep a database of all the books that are
available on the shelves and those that are in the storeroom.
Patrons should be able to view our catalogue through a webpage and place
holds on the books that they wish to reserve.
NLA Example (Extract Verbs)

We need a system that allows us to manage our library. It needs to let us

add, remove and manipulate books, as well as add, remove and
manipulate customer details. It should keep a database of all the books that
are available on the shelves and those that are in the storeroom.
Patrons should be able to view our catalogue through a webpage and place
holds on the books that they wish to reserve.
Candidates
• This gives us an initial list of possible classes and actions:
Candidates

• We then remove those that are synonyms.

- E.g. Customers and Patrons
• We remove those that are too high a level of abstraction.
- E.g. Manipulate the library
• We remove those that are already part of our future design.
- E.g. Keep a database
• We remove those that are outside our scope.
Candidates

• Doing this gives us a smaller, more manageable list of candidates.

• This isn’t the ‘correct’ design - it’s just a starting point.
• We will refine as we go along.
First Draft Class
Diagram

Our first class diagram doesn’t include

a lot of detail. It’s mostly so we can go
back to the client and check we have
the right structure.
• Note here that we don’t include the
web page in our don’t class diagram.
It’s not part of the ‘engine’ of our
system – we will address it later.
• Once we are sure we have the right
structure, we can fill in missing detail.
Constructing a Class
Diagram
• If we have a class that contains only one single piece of data, it is probably
better represented as an attribute in another class.
• Resolving Ambiguity
As an example, look at the functionality we have linked to a book:
- Add books (okay)
- Remove books (okay)
- Manipulate books (ambiguous)
- Perhaps that means ‘edit’ book details, but we’d need to check.
- If it means edit the details, what kinds of details do we need?
Second Draft Class Diagram

• All the class diagram gives us is an ‘at

a glance’ view of how the classes
interrelate, and what their available
functionality is.
• This is part of the static view of the
program.
Implementing Class
Diagrams
Notice in our second draft that we include the data types and parameter lists of
operations. And yet, we don’t know how the methods will work!
• We know (roughly) what kind of information is going to be needed for a method to
function and we function, simply supply that information.
• Though we don’t yet know the details of how, for example, the addBook method will
work, we do know the data it is going to need.
 Implementing Class
Diagrams
• The class diagram lends itself to implementation in any object oriented language.
• The class diagrams gives us the information we need to create the structural connections
between each of the classes.
• Normally, we would wait until we’ve done a few iterative drafts of the design before we start
writing code. That way we don’t waste time on models that are only going to be changed.
• Prototyping is the process of building an early version of the software. It falls into
two categories.
- Throw-away prototyping, where the code is written and then discarded when the
project is implemented ‘for real’.
- Incremental prototyping, where the prototype is continually refined and eventually
evolves into the finished product.
- The former allows for the development of cleaner systems. The latter allows for more
efficiency in development.
Implementing Class
Diagrams
• Each class is represented by a rectangle subdivided into three compartments
Name
Attributes
Operations

• Modifiers are used to indicate visibility of attributes and operations.

‘+’ is used to denote Public visibility (everyone)
‘#’ is used to denote Protected visibility (friends and derived)
‘-’ is used to denote Private visibility (no one)

• By default, attributes are hidden and operations are visible.

Class diagram
Class Name
AccountClass
- Customer_Name
Attributes
- Balance
+addFunds( ) Operations
+withDraw( )
+transfer( )
OO Relationships
• There are two kinds of Relationships
Generalization (parent-child relationship)
Association (student enrolls in course)

• Associations can be further classified as

Aggregation
Composition
OO Relationships: Generalization
Example:
Supertype Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2

-Inheritance is a required feature of object orientation

-Generalization expresses a parent/child relationship among related classes.
-Used for abstracting details in several layers
Class Diagram

Multiplicity
Symbol Meaning
1 One and only one
0..1 Zero or one
M..N From M to N (natural
language)
* From zero to any positive
integer
0..* From zero to any positive
integer
1..* From one to any positive
integer
OO Relationships: Composition

Association
Class W
Whole Class Models the part–whole relationship

Composition
Class P1 Class P2
Also models the part–whole relationship but,
in addition, Every part may belong to only
one whole, and If the whole is deleted, so
Part Classes are the parts
[From Dr.David A. Workman]

Example
Example:
A number of different chess boards: Each
square belongs to only one board. If a chess
board is thrown away, all 64 squares on that
board go as well.

The McGraw-Hill Companies, 2005

OO Relationships: Aggregation
Container Class
Class C

AGGREGATION Aggregation:
Expresses a relationship among instances of related
Class E1 Class E2 classes. It is a specific kind of Container-
Containee relationship.
Containee Classes
Express a more informal relationship than
Example
Bag composition expresses.

Aggregation is appropriate when Container and

Containees have no special access privileges to
Apples Milk
each other.
[From Dr.David A. Workman]
Aggregation vs. Composition

Composition is really a strong form of association

components have only one owner
components cannot exist independent of their owner
components live or die with their owner
e.g. Each car has an engine that can not be shared with other cars.

 Aggregations
may form "part of" the association, but may not be essential to it. They may also
exist independent of the aggregate. e.g. Apples may exist independent of the
bag.
Implementing Class Diagram using
starUML
Implementing Class Diagram using
starUML
Thank you
References

• https://www.uml-diagrams.org/uml-25-diagrams.html
• http://agilemodeling.com/essays/useCaseReuse.htm
• https://www.uml-diagrams.org/use-case-diagrams-examples.html
• Analysis Design and Analysis, Implementation, Topic 3: Object-Oriented
Modelling, NCC Education