1. Unified Modeling Language (UML)

2. What is a Model? A model is a simplification of reality.
A model may provide
blueprints of a system
Organization of the system
Dynamic of the system

3. Why We Model Model is built to
Communicate the desired structure and behavior of the system
Visualize and control the system’s architecture
Better understand the system that being built
Manage risk
Expose opportunities for simplification and reuse

4. Why We Model
We build models so that we can see and better understand the system we are developing.

5. Importance of Modeling
Models help us
to visualize a system as it is or as we want it to be.
to specify the structure or behavior of a system.
in providing a template that guides us in constructing a system.
in providing documenting the decisions we have made.

6. Objected-Oriented Modeling
Two most common ways in modeling software systems are
Algorithmic
Procedures or functions
Object oriented
Objects or classes

7. What is UML? Stands for Unified Modeling Language
UML is a language for
Visualizing
Specifying
Constructing
Documenting

9. 1. Class Diagram
A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them
A graphical representation of a static view on static elements
A central modeling technique that is based on object-oriented principles

10. Objects and Classes Interpretation in the Real World
Interpretation in the Model
Object
An object is a thing that can be distinctly identified.
An object has an identity, a state, and a behavior.
Class
A class represents a set of objects with similar characteristics and behavior. This objects are called the instances of the class.
A class characterizes the structure of states and behaviors that are shared by all instances.

11. Objects Each of object has a unique identity.
The state of an object is composed of a set of fields (data fields), or attributes.
Each field has a name, a type, and a value.
Behaviors are defined by methods.
Each method has a name, a type, and a value.
Each method may or may not return a value.
Features are a combination of the state and the behavior of the object.

12. Classes
A class defines a template for creating or instantiating its instances or objects.
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.

13. Classes A class defines --
the names and types of all fields
the names, types, implementations of all methods
The values of the fields are not defined or fixed in the class definition.
Each instance of the class has its own state.
Different instances of the class may have different states.
The implementations of methods are defined in the class definition and fixed for a given object.

14. Example Class name: Point class Point { Fields: x, y int x, y;
Method: move public void move
(int dx, int dy){
// implementation }

15. UML Notation for Classes
ClassName
The top compartment shows the class name.
field1 …
fieldn
The middle compartment contains the declarations of the fields of the class.
method1
methodm
The bottom compartment contains the declarations of the methods

16. Field Declaration
The name of the field is required in the field declaration.
Field declaration may include:
[Visibility][Type]Name[[Multiplicity]][=InitialValue]
[Visibility]Name[[Multiplicity]][:Type][=InitialValue]
Visibility or accessibility defines the scope:
Public -- the feature is accessible to any class
Protected -- the feature is accessible to the class itself, all the classes in the same package, and all its subclasses.
Package -- the feature is accessible to the class itself and all classes in the same package.
Private -- the feature is only accessible within the class itself.

17. Visibility syntax in Java and UML
Visibilty
Java Syntax
UML Syntax
public +
protected #
package ~
private -

18. Examples Java Syntax UML Syntax Date birthday Birthday:Date
Public int duration = 100
+duration:int = 100
Private Student students[0..MAX_Size]
-students[0..MAX_Size]:Student

19. Method Declaration
The name of the method is required in the method declaration.
Method declaration may include:
[Visibility][Type]Name([Parameter, ...])
[Visibility]Name([Parameter, ...])[:Type]
Each parameter of a method can be specified by -- Type Name

20. Examples Java Syntax UML Syntax void move(int dx, int dy)
public int getSize()
+int getSize()

21. Example Point private int x private int y
public void move(int dx,int dy)
Point
-x:int
-y:int
+move(dx:int,dy:int)
Point x y
move()

22. UML Notation for Object
ObjectName : ClassName
The top compartment shows the object name and its class.
field1 = value1 …
fieldn = valuen
The bottom compartment contains a list of the fields and their values.
objectName -- objectName whose class is of no interest
:ClassName -- anonymous object of ClassName which can be identify only through its relationship with other object.

23. Examples P1:Point Point p1 = new Point(); x = 0 y = 0 p1.x = 0;
P1.y = 0;
P1:Point
Point p1 = new Point();
x = 24
y = 40
p1.x = 24;
P1.y = 40;

24. Message Passing or Method Invocation
Objects communicate with one another through message passing.
A message represent a command sent to an object -- recipient
A message consists of the receiving object, the method to be invoked and the arguments to method.

25. Example
p1.move(10,20)
Recipient p1
Method
move()
Arguments
(10,20)

26. Modeling Relationships and Structures
A class diagram consists of
A set of nodes that represent classes and interfaces
A set of links represent relationships among classes
Class diagrams can be used to model:
Inheritance -- extension and implementation
Association -- aggregation and compostion
Dependency

27. Inheritance Define a relationship among classes and interfaces
Inheritance model -- the is-a(n) relationship

28. Example

29. Association Association represents binary relationship between classes
* enroll *
Student
Course
advisee * *
teach 1 1
Faculty
adviser

30. Aggregation and Compositon
Aggregation is a special form of association
Has-a or part-whole relationship
Composition is a stronger form of aggregation

31. Example 1 1 1 * * * 1 1 Chairman-of Member-of 1 1..* University
College
Department
Student 1 1
Chairman-of
Member-of 1
1..*
Faculty

32. Dependency
Dependency is a relationship between entities such that the proper operation of one entity depends on the presence of the other entity, and changes in one entity would affect the other entity.

33. Example

34. 2. Sequence diagram
Depict object interaction by highlighting the time ordering of method invocation

35. Example

37. Object
Object naming:
syntax: [instanceName][:className]
Name classes consistently with your class diagram (same classes).
Include instance names when objects are referred to in messages or when several objects of the same type exist in the diagram.
The Life-Line represents the object’s life during the interaction

38. Messages
An interaction between two objects is performed as a message sent from one object to another
A message is represented by an arrow between the life lines of two objects.

39. Return Values
Optionally indicated using a dashed arrow with a label indicating the return value.

40. Object Creation
An object may create another object via a <<create>> message.

41. Object Destruction
An object may destroy another object via a <<destroy>> message.
An object may destroy itself.
Avoid modeling object destruction unless memory management is critical. :A :B
<<destroy>>

42. Control information Condition Iteration
syntax: ‘[‘ expression ’]’ message-label
The message is sent only if the condition is true
example:
Iteration
syntax: * [ ‘[‘ expression ‘]’ ] message-label
The message is sent many times to possibly multiple receiver objects.
[ok] borrow(member)

43. 3. Use Case Diagram
Use cases describes the externally observable behavior of system functions in the form of interactions between the system to be developed and the external entities -- Actors.
Actors may represent roles played by users of the system or other systems.
Consist of a name and scenarios
One of scenarios is the main scenario

44. Use Case Diagram Consist of: Use cases Actors
Relationships among actors and use cases

45. Extension relationships among actors

46. Dependency relationships among use cases

47. Case Study: An E-Bookstore