1. UML Unified Modelling Language
JIIT 128
CLASS DIAGRAM
USE CASE DIAGRAM

2. What Is a Model?
A model is “a complete description of a system from a particular perspective.” A model is a simplification of reality.
According to Grady Booch, IBM Fellow, a model provides the blueprints of a system. Models may encompass detailed plans, as well as more general plans that give a 30,000-foot view of the system under construction. A good model includes those elements that are not relevant to the given level of abstraction. Every system may be described from different aspects using different models, and each model is therefore a semantically closed abstraction of the system. A model may be structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.

3. Why Model? Modeling achieves four aims:
Helps you to visualize a system as you want it to be.
Permits you to specify the structure or behavior of a system.
Gives you a template that guides you in constructing a system.
Documents the decisions you have made.
You build models of complex systems because you cannot comprehend such a system in its entirety.
You build models to better understand the system you are developing.

4. Importance of Modeling
Applications approaching like building paper airplanes
Start coding from project requirements
Work longer hours and create more code
Lacks any planned architecture
Doomed to failure
Modeling is a common thread to successful projects
Less Important
More Important

5. Four Principles of Modeling
The model you choose influences how the problem is attacked.
Every model may be expressed at different levels of precision.
The best models are connected to reality.
No single model is sufficient.
Deployment Model
Process Model
Design Model
Modeling has a rich history in all the engineering disciplines.
The four basic principles of modeling are derived from this history.
The models you create profoundly influence how a problem is attacked and how a solution is shaped.
Every model may be expressed at different levels of precision.
The best models are connected to reality.
No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models.

6. Object Oriented Modeling

7. What Is the UML? The UML is a language for
Visualizing
Specifying
Constructing
Documenting
the artifacts of a software-intensive system.
The Unified Modelling Language (UML) is an industry standard for object oriented design notation, supported by the Object Management Group (OMG).
The software systems that you develop today are more complex than the human mind can comprehend. This is why you model systems. Your model selection profoundly influences how you attack the problem and shape the solution.
No single model is sufficient. Every complex system is best approached through a small set of nearly independent models.
Therefore, to increase comprehension, a common language like the Unified Modeling Language (UML) is used to express models.
A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modeling language like the UML is a standard language for software blueprints.

8. UML Diagrams in Software Architecture
Structural Diagrams
Class
Diagrams
user interactions with the system
Use-Case
Diagrams
Composite
Structure
Diagrams
Sequence
Diagrams
logical structure
Model
Communication
Diagrams
Component
Diagrams
Visual models of a system require many different diagrams to represent different views of the system for different project stakeholders. The UML provides a rich notation for visualizing models, including the following key diagrams:
Use-Case diagrams to illustrate user interactions with the system
Class diagrams to illustrate logical structure
Composite Structure diagrams to show the internal structure of a class or component at runtime
Component diagrams to illustrate the organization and dependencies among modular parts of the system
Deployment diagrams to show the mapping of software to hardware configurations
Activity diagrams to illustrate flows of events
State Machine diagrams to illustrate the series of states an object can have
Communication diagrams to illustrate behavior in terms of how objects interact
Sequence diagrams to illustrate behavior in terms of the sequence of interactions between objects
State Machine
Diagrams
Deployment
Diagrams
Activity
Diagrams
Behavioral Diagrams

9. Key Diagrams in UML Requirements System Structure System Behaviour
Use Case Diagrams
Class Diagrams
Collaboration Diagrams
Interaction Diagrams
Activity Diagrams
State Charts

10. Different diagrams of system for different people
Class Diagrams
Object Diagrams
Sequence
Collaboration
Statechart
Activity
Deployment Diagrams
Component Diagrams
Process View
Deployment View
Logical View
Use-Case View
Implementation View
End-user
Functionality
Programmers
Software management
Performance, scalability, throughput
System integrators
System topology, delivery,
installation, communication
System engineering
Analysts/Designers
Structure

11. UML Tools

13. Class Diagrams
Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application. So a collection of class diagrams represent the whole system.
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.
The last two compartments may be omitted to simplify the class diagrams

14. Cont..
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations in separate, designated compartments.
Account_Name
- Custom_Name
- Balance
+AddFunds( )
+WithDraw( )
+Transfer( )
Name
Attributes
Operations

15. Class Names The name should be a noun or noun phrase
The name should be singular and description of each object in the class
The name should be meaningful from a problem-domain perspective
“Student” is better than “Student Data” or “S-record” or any other implementation driven name

16. Attributes [visibility] name [multiplicity] [:type] [=initial-value]
Attributes represent characteristics or properties of classes
They are place holders or slots that hold values
The values they hold are other objects (or primitive types)
Syntax :
[visibility] name [multiplicity] [:type] [=initial-value]

17. Cont.. visibility: public “+”, protected “#”, or private “-”
name: capitalize first letter of each word that makes up the name, except for the first
multiplicity: number, range, or sequence of number or ranges.
type: built-in type or any user-defined class
initial-value: any constant and user-defined object
A derived attribute is one that can be computed from other attributes, but doesn’t actually exist. For example, a Person’s age can be computed from his birth date. A derived attribute is designated by a preceding ‘/’ as in:
/ age : Date

18. Operation Syntax [visibility] name [(parameter-list)] [:return-type]
name: verb or verb phase, capitalize first letter of every word, except first
parameter-list: coma separated list of parameters
return-type: primitive type or user-defined type

19. Operations Student Class Section major: String GPA: Real
standing: String
name: String
capacity: Integer
takes>
add(Student)
drop(Student)
checkPrerequisites(Students)
add(Class Section)
drop(Class Section)
<has
Course
Prerequisite

20. Type of Relationships in Class Diagrams
1.Generalization
2.Association
3.Composition
4.Aggregation
5.Realisation
6.Dependency
Relation
Generalization
Association
Dependency
Binary Association
N-ary Association
Aggregation

21. Generalization relationship
Indicates that objects of the specialized class (subclass) are substitutable for objects of the generalized class (super-class).
“is kind of” relationship.
Shape {abstract}
Circle
Super Class
Sub Class
An abstract class
Generalization relationship

22. Generalization A sub-class inherits from its super-class
Attributes
Operations
Relationships
A sub-class may
Add attributes and operations
Add relationships
Refine (override) inherited operation

23. C++ Example for Generalization
class 2DPoint { int x, y; }; class 3DPpoint : 2DPoint { int z; };

24. Associations
A semantic relationship between two or more classes that specifies connections among their instances.
A structural relationship, specifying that objects of one class are connected to objects of a second (possibly the same) class.
Example: “An Employee works for a Company”

25. Associations Connect two classes Have an optional label
Have multiplicities
Are directional
Have optional roles

26. Associations student 1 * University Person 0..1 * teacher employer
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
Role
“A given university groups many people; some act as students, others as teachers. A given student belongs to a single university; a given teacher may or may not be working for the university at a particular time.”

27. is registered for>
Student
Semester
takes>
is held during>
teaches>
Class Section
Instructor
<works for
is instance of>
sponsors>
Department
Course

28. Associations Navigation The navigation of associations can be
uni-directional
bi-directional
unspecified
Navigation is specified by the arrow, not the label
teaches>
Class Section
Instructor
<works for
is instance of>
sponsors>
Department
Course

29. Associations To clarify its meaning, an association may be named.
The name is represented as a label placed midway along the association line.
Usually a verb or a verb phrase.
A role is an end of an association where it connects to a class.
May be named to indicate the role played by the class attached to the end of the association path.
Usually a noun or noun phrase
Mandatory for reflexive associations

30. Associations Multiplicity
The number of instances of the class, next to which the multiplicity expression appears, that are referenced by a single instance of the class that is at the other end of the association path.
Provides a lower and upper bound on the number of instances.

31. C++ Example
Association is typically implemented with a pointer or reference instance variable.
class A {
private:
B* b; }; A B

32. Cont..

34. 1..* 0..* 1 0..8 1..* 1..3 0..6 1..* 1 1 1..* is registered for>
Student
Semester
1..*
0..* 1
takes>
is held during>
0..8
1..*
teaches>
Class Section
Instructor
1..3
0..6
1..*
<works for
is instance of> 1
sponsors> 1
1..*
Department
Course

35. Questions From the previous diagram
How many classes can a student take?
Do you have to be registered in any classes to be a student?
Do I need to teach this class to be an Instructor? Do I need to teach ANY classes?
Can a class have no students? Is that valid?