1. Unified Modelling Language (UML)
Kavoshgaran 1

2. Why We Model ? A model is a simplification of reality.
We build models so that we can better understand the system we are developing
Benefits:
Models help us to visualize a system as it is or as we want it to be.
Models permit us to specify the structure or behavior of a system.
Models give us a template that guides us in constructing a system.
Models document the decisions we have made.

3. Principles of Modeling
First: The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped .
Second:  Every model may be expressed at different levels of precision.
Third: The best models are connected to reality.
Fourth: No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models.

4. Introducing the UML The UML is a language for Visualizing Specifying
Constructing
Documenting

5. Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building blocks:  
Things
Relationships
Diagrams

6. Things in the UML Structural things Behavioral things Grouping things
Annotational things

7. Structural Things
Structural things are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. In all, there are seven kinds of structural things.
Includes:
Classes
Interfaces
Collaborations
Use Case
Component
Node

8. Behavioral Things
Behavioral Things Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. In all, there are two primary kinds of behavioral things.
Includes:
interaction
state machine
States

9. Grouping Things
Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing, namely, packages.
Includes:
Packages

10. Annotational Things
Annotational things are the explanatory parts of UML models. These are the comments you may apply to describe, illuminate, and remark about any element in a model.
Includes:
Notes

11. Relationships in the UML
Dependency
Association
Generalization
Realization

12. Dependency?
dependency is a semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing.

13. Association?
association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts.

14. Generalization?
a generalization is a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent).

15. Realization?
a realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.
classifier: A mechanism that describes structural and behavioral features. Classifiers include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.

16. Diagrams in the UML
A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships).
UML includes nine such diagrams:  
Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
Component diagram
Deployment diagram

17. Diagrams in the UML
A class diagram shows a set of classes, interfaces, and collaborations and their relationships. These diagrams are the most common diagram found in modeling object-oriented systems. Class diagrams address the static design view of a system. Class diagrams that include active classes address the static process view of a system.
An object diagram shows a set of objects and their relationships. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases.
A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system.

18. Diagrams in the UML
sequence diagrams and collaboration diagrams are kinds of interaction diagrams. An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them. Interaction diagrams address the dynamic view of a system. A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages; a collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one and transform it into the other.
A statechart diagram shows a state machine, consisting of states, transitions, events, and activities. Statechart diagrams address the dynamic view of a system. They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems.
An activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects.

19. Diagrams in the UML
A component diagram shows the organizations and dependencies among a set of components. Component diagrams address the static implementation view of a system. They are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations.
A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of an architecture. They are related to component diagrams in that a node typically encloses one or more components.

20. Common Mechanisms in the UML
Specifications
Adornments
Common divisions
Extensibility mechanisms
Specifications :behind every part of its graphical notation there is a specification that provides a textual statement of the syntax and semantics of that building block.
Adornments:Most elements in the UML have a unique and direct graphical notation that provides a visual representation of the most important aspects of the element.
Common Divisions: In modeling object-oriented systems, the world often gets divided in at least a couple of ways.

21. Extensibility Mechanisms
Includes:
Stereotypes
Tagged values
Constraints
A stereotype extends the vocabulary of the UML, allowing you to create new kinds of building blocks that are derived from existing ones but that are specific to your problem.
A tagged value extends the properties of a UML building block, allowing you to create new information in that element's specification.
A constraint extends the semantics of a UML building block, allowing you to add new rules or modify existing ones.

22. Extensibility Mechanisms

23. Architecture Architecture is the set of significant decisions about
The organization of a software system
The selection of the structural elements and their interfaces by which the system is composed
Their behavior, as specified in the collaborations among those elements
The composition of these structural and behavioral elements into progressively larger subsystems
The architectural style that guides this organization: the static and dynamic elements and their interfaces, their collaborations, and their composition

24. Modeling a System's Architecture (4+1)

25. Classes

26. Class Diagram Content: Common Use: Classes Interfaces Collaborations
Dependency, generalization, and association relationships
Common Use:
To model the vocabulary of a system
To model simple collaborations
To model a logical database schema

27. Class Diagram

28. Modeling Simple Collaborations

29. Modeling a Logical Database Schema

30. Advanced Classes

31. Classifier
A classifier is a mechanism that describes structural and behavioral features. Classifiers include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.

32. Template Class

33. Visibility

34. Advanced Relationships
A dependency is a using relationship, specifying that a change in the specification of one thing (for example, class SetTopController ) may affect another thing that uses it.

35. Forward and Reverse Engineering
public abstract class EventHandler
{  
EventHandler successor;
  private Integer currentEventID;
 private String source;
   EventHandler() {} 
public void handleRequest() {}
  }

36. Abstract, Root, Leaf, and Polymorphic Elements

37. Multiplicity

38. Modeling the Semantics of a Class
Specify the responsibilities of the class
Specify the semantics of the class as a whole
Specify the body of each method
Specify the pre- and postconditions of each operation, plus the invariants of the class as a whole
Specify a state machine for the class
Specify a collaboration that represents the class
Specify the pre- and postconditions of each operation, plus the invariants of the class as a whole, using a formal language such as OCL.

39. Interfaces

40. Roles

41. Modeling the Seams in a System

42. Modeling Static Types

43. Modeling Dynamic Types

44. Packages
package is a general purpose mechanism for organizing modeling elements into groups.

45. Simple and Extended Package

46. Owned Elements

47. Importing and Exporting

48. Generalization Among Packages

49. Modeling Groups of Elements

50. Modeling Architectural Views

51. Interaction Diagrams
An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them.
A sequence diagram is an interaction diagram that emphasizes the time ordering of messages .
A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages.

52. Interaction Diagrams

53. Sequence Diagrams

54. Collaboration Diagrams

55. Modeling Flows of Control by Time Ordering

56. Modeling Flows of Control by Organization

57. Forward and Reverse Engineering
public void register() {
CourseCollection c = getSchedule();
for (int i = 0; i < c.size(); i++)
c.item(i).add(this);
this.registered = true; }

58. Activity Diagrams
Activity diagrams are one of the five diagrams in the UML for modeling the dynamic aspects of systems. An activity diagram is essentially a flowchart, showing flow of control from activity to activity.
Common Use
Modeling a workflow
Modeling an operation.

59. Activity Diagrams

60. Action States
Action states can't be decomposed. Furthermore, action states are atomic, meaning that events may occur, but the work of the action state is not interrupted.

61. Activity States
activity states can be further decomposed, their activity being represented by other activity diagrams.

62. Transitions
When the action or activity of a state completes, flow of control passes immediately to the next action or activity state.

63. Branching
sequential transitions are common, but they aren't the only kind of path you'll need to model a flow of control.

64. Forking and Joining

65. Swimlanes

66. Object Flow

67. Modeling a Workflow

68. Modeling an Operation Point Line::intersection (l : Line) {
if (slope == l.slope) return Point(0,0);
int x = (l.delta - delta) / (slope - l.slope);
int y = (slope * x) + delta;
return Point(x, y); }

69. Events and Signals
An event is the specification of a significant occurrence that has a location in time and space.
A signal, the passing of time, and a change of state are asynchronous events, representing events that can happen at arbitrary times.

70. Signals

71. Call Events

72. Time and Change Events

73. State Machines

74. States

75. Transitions

76. Advanced States and Transitions

77. Substates

78. History States

79. Concurrent Substates

80. Modeling the Lifetime of An Object

81. Components

82. Simple and Extended Components

83. Components and Interfaces

84. Modeling Executables and Libraries

85. Modeling Tables, Files, and Documents

86. Modeling an API

87. Modeling Source Code

88. Node
A node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability.

89. Nodes and Components

90. Connections

91. Processors and Devices

92. Modeling the Distribution of Components

93. Deployment Diagram

94. Modeling a Client/Server System

95. Modeling a Fully Distributed System