Scribd
Upload
4 views10 pages

UML NotesPart 1

The document provides notes on UML, detailing its uses such as communication and code generation, and explains various association types like aggregation, composition, and dependency. It covers use cases, actors, and their relationships, as well as guidelines for creating use cases and sequence diagrams. Additionally, it discusses state machines, UML packages, and class diagrams, emphasizing their structure and relationships within object-oriented systems.

Uploaded by

ibrahimsow367
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
4 views10 pages

UML NotesPart 1

The document provides notes on UML, detailing its uses such as communication and code generation, and explains various association types like aggregation, composition, and dependency. It covers use cases, actors, and their relationships, as well as guidelines for creating use cases and sequence diagrams. Additionally, it discusses state machines, UML packages, and class diagrams, emphasizing their structure and relationships within object-oriented systems.

Uploaded by

ibrahimsow367
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

UML Notes:

CLASS NOTES:

19/8/2024:
• Uses for UML:
o To communicate aspects of a system
o Used as a blueprint
o Used, for tools that create code from UML

20/8/2024:
Association types (a usage relationship):

• Aggregation: is part of something


▪ Symbolized by: Clear white diamond
• Composition: is fundamentally part of something / is entirely made of
o This is a stronger connection that aggregation
▪ Symbolized by: Black diamond
• Dependency: is used temporarily
•
Generalization (inheritance) relationships:

• Class: sold line, black arrowhead


• Abstract: solid line, white arrowhead
• Interface: dashed line, white arrowhead

• Hierarchies = drawn top-down


• Arrows = point upward to parent

Associational relationships:

• Multiplicity (how many are used)


• Name
• Navigability
Part 2 Use cases:
• Use case: a unit of functionality (requirement), or a service, in the system. A use case
isn’t a process, program, or function.
o Nothing OO about use cases.
• A use case is (a generic description of) an entire transaction, involving several objects.
• Purpose: define a piece of behavior of an entity without revealing internal structures of
the entity.

• Actors: specifies a role played by a user or any other system that interacts with the
subject
o are external to the system; May or may not be human
o Identified in terms of the roles they play.
o e.g. Time; A system for devising staff work timetables;
• Actors don’t interact with each other, in a use case model.
• Primary actor accomplishes a goal via the use case.
o LHS
• Secondary actor provides a service to the use case.
o RHS
• System boundary: distinguishes the system from the rest of the world.
o Use Cases are inside the box; Actors are outside.
o
• Use cases are represented by ovals ^:
o Name of use case inside ellipse/oval
• Stereotype: when one use case is related to another
o <<includes>> <<uses>> <<extends>>
o <<extends>> is used for part of use case that will sometimes be used and
sometimes not. AKA its use is NOT guaranteed.

• Use case narratives:


o Every case a has a detail description
o Stories of using a system to fulfill a goal
o If can’t describe use-case properly, then look back, rethink whether you have a
use case; ask client for more information.
• Use case scenario: a specific sequence of actions, interactions in a use case.
o A collection of scenario

• Guidelines:
o Use-cases start with a verb
o EBP:
(Part 3 – Sequence diagrams):
28/8/2024 (Part 4 –Activity, State & Package Diagrams):

•
• State machines / state diagrams:
o Shows how an object changes due to external stress over lifetime
o Reactive
o Needs an external diagram
UML Packages:

• Packages group elements


• Used to show the high level organization of a project
• A dashed arrow between packages indicates a dependenc

•
EXTERNAL NOTES:

Recomended resources: https://www.youtube.com/watch?v=WnMQ8HlmeXc

https://www.geeksforgeeks.org/unified-modeling-language-uml-class-diagrams/ d

Overview:
• Class: a blueprint or template for creating objects
• Class Diagram: visually represents the structure and relationships of classes within a
system i.e. used to construct and visualize object-oriented systems.
o Association: represents relations between instances, elements
▪ e.g. ~

• Classes are depicted as boxes, each containing three compartments for the class:
name, attributes, and methods. Lines connecting classes illustrate associations,
showing relationships such as one-to-one or one-to-many.
Association types:

• Aggregation: is part of something


• Composition: is fundamentally part of something
o This is a stronger form of aggregation; indicates more significant ownership.
• Dependency: is used temporarily
The 3 main parameter directionality notations used in class diagrams:

• In (Input):
o An input parameter is a parameter passed from the calling object (client) to
the called object (server) during a method invocation. It is represented by an
arrow pointing towards the receiving class (the class that owns the method).
• Out (Output):
o An output parameter is a parameter passed from the called object (server)
back to the calling object (client) after the method execution. It is
represented by an arrow pointing away from the receiving class.
• InOut (Input and Output):
o An InOut parameter serves as both input and output. It carries information
from the calling object to the called object and vice versa. It is represented
by an arrow pointing towards and away from the receiving class.

You might also like