Page 1 Kavoshgaran Unified Modelling Language (UML)
-
Upload
caroline-bennett -
Category
Documents
-
view
228 -
download
3
Transcript of Page 1 Kavoshgaran Unified Modelling Language (UML)
![Page 1: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/1.jpg)
Page 1 Kavoshgaran
Unified Modelling Language(UML)
![Page 2: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/2.jpg)
Page 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.
![Page 3: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/3.jpg)
Page 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.
![Page 4: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/4.jpg)
Page 4
Introducing the UML
The UML is a language for
Visualizing
Specifying
Constructing
Documenting
![Page 5: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/5.jpg)
Page 5
•Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building blocks:
– Things – Relationships – Diagrams
![Page 6: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/6.jpg)
Page 6
Things in the UML
Structural things
Behavioral things
Grouping things
Annotational things
![Page 7: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/7.jpg)
Page 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
![Page 8: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/8.jpg)
Page 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
![Page 9: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/9.jpg)
Page 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
![Page 10: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/10.jpg)
Page 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
![Page 11: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/11.jpg)
Page 11
Relationships in the UML Dependency
Association
Generalization
Realization
![Page 12: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/12.jpg)
Page 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.
![Page 13: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/13.jpg)
Page 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.
![Page 14: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/14.jpg)
Page 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).
![Page 15: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/15.jpg)
Page 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.
![Page 16: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/16.jpg)
Page 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
![Page 17: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/17.jpg)
Page 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.
![Page 18: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/18.jpg)
Page 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.
![Page 19: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/19.jpg)
Page 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.
![Page 20: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/20.jpg)
Page 20
Common Mechanisms in the UML Common Mechanisms
– 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.
![Page 21: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/21.jpg)
Page 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.
![Page 22: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/22.jpg)
Page 22
Extensibility Mechanisms
![Page 23: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/23.jpg)
Page 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
![Page 24: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/24.jpg)
Page 24
Modeling a System's Architecture (4+1)
![Page 25: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/25.jpg)
Page 25
Classes
![Page 26: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/26.jpg)
Page 26
Class Diagram
Content:– 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
![Page 27: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/27.jpg)
Page 27
Class Diagram
![Page 28: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/28.jpg)
Page 28
Modeling Simple Collaborations
![Page 29: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/29.jpg)
Page 29
Modeling a Logical Database Schema
![Page 30: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/30.jpg)
Page 30
Advanced Classes
![Page 31: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/31.jpg)
Page 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.
![Page 32: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/32.jpg)
Page 32
Template Class
![Page 33: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/33.jpg)
Page 33
Visibility
![Page 34: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/34.jpg)
Page 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.
![Page 35: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/35.jpg)
Page 35
Forward and Reverse Engineering
public abstract class EventHandler
{
EventHandler successor;
private Integer currentEventID;
private String source;
EventHandler() {}
public void handleRequest() {}
}
![Page 36: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/36.jpg)
Page 36
Abstract, Root, Leaf, and Polymorphic Elements
![Page 37: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/37.jpg)
Page 37
Multiplicity
![Page 38: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/38.jpg)
Page 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.
![Page 39: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/39.jpg)
Page 39
Interfaces
![Page 40: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/40.jpg)
Page 40
Roles
![Page 41: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/41.jpg)
Page 41
Modeling the Seams in a System
![Page 42: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/42.jpg)
Page 42
Modeling Static Types
![Page 43: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/43.jpg)
Page 43
Modeling Dynamic Types
![Page 44: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/44.jpg)
Page 44
Packages
package is a general purpose mechanism for organizing modeling elements into groups.
![Page 45: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/45.jpg)
Page 45
Simple and Extended Package
![Page 46: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/46.jpg)
Page 46
Owned Elements
![Page 47: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/47.jpg)
Page 47
Importing and Exporting
![Page 48: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/48.jpg)
Page 48
Generalization Among Packages
![Page 49: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/49.jpg)
Page 49
Modeling Groups of Elements
![Page 50: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/50.jpg)
Page 50
Modeling Architectural Views
![Page 51: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/51.jpg)
Page 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.
![Page 52: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/52.jpg)
Page 52
Interaction Diagrams
![Page 53: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/53.jpg)
Page 53
Sequence Diagrams
![Page 54: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/54.jpg)
Page 54
Collaboration Diagrams
![Page 55: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/55.jpg)
Page 55
Modeling Flows of Control by Time Ordering
![Page 56: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/56.jpg)
Page 56
Modeling Flows of Control by Organization
![Page 57: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/57.jpg)
Page 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;}
![Page 58: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/58.jpg)
Page 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.
![Page 59: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/59.jpg)
Page 59
Activity Diagrams
![Page 60: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/60.jpg)
Page 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.
![Page 61: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/61.jpg)
Page 61
Activity States
activity states can be further decomposed, their activity being represented by other activity diagrams.
![Page 62: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/62.jpg)
Page 62
Transitions
When the action or activity of a state completes, flow of control passes immediately to the next action or activity state.
![Page 63: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/63.jpg)
Page 63
Branching
sequential transitions are common, but they aren't the only kind of path you'll need to model a flow of control.
![Page 64: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/64.jpg)
Page 64
Forking and Joining
![Page 65: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/65.jpg)
Page 65
Swimlanes
![Page 66: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/66.jpg)
Page 66
Object Flow
![Page 67: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/67.jpg)
Page 67
Modeling a Workflow
![Page 68: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/68.jpg)
Page 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);
}
![Page 69: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/69.jpg)
Page 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.
![Page 70: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/70.jpg)
Page 70
Signals
![Page 71: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/71.jpg)
Page 71
Call Events
![Page 72: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/72.jpg)
Page 72
Time and Change Events
![Page 73: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/73.jpg)
Page 73
State Machines
![Page 74: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/74.jpg)
Page 74
States
![Page 75: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/75.jpg)
Page 75
Transitions
![Page 76: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/76.jpg)
Page 76
Advanced States and Transitions
![Page 77: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/77.jpg)
Page 77
Substates
![Page 78: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/78.jpg)
Page 78
History States
![Page 79: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/79.jpg)
Page 79
Concurrent Substates
![Page 80: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/80.jpg)
Page 80
Modeling the Lifetime of An Object
![Page 81: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/81.jpg)
Page 81
Components
![Page 82: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/82.jpg)
Page 82
Simple and Extended Components
![Page 83: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/83.jpg)
Page 83
Components and Interfaces
![Page 84: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/84.jpg)
Page 84
Modeling Executables and Libraries
![Page 85: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/85.jpg)
Page 85
Modeling Tables, Files, and Documents
![Page 86: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/86.jpg)
Page 86
Modeling an API
![Page 87: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/87.jpg)
Page 87
Modeling Source Code
![Page 88: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/88.jpg)
Page 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.
![Page 89: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/89.jpg)
Page 89
Nodes and Components
![Page 90: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/90.jpg)
Page 90
Connections
![Page 91: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/91.jpg)
Page 91
Processors and Devices
![Page 92: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/92.jpg)
Page 92
Modeling the Distribution of Components
![Page 93: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/93.jpg)
Page 93
Deployment Diagram
![Page 94: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/94.jpg)
Page 94
Modeling a Client/Server System
![Page 95: Page 1 Kavoshgaran Unified Modelling Language (UML)](https://reader030.fdocuments.us/reader030/viewer/2022020800/56649d825503460f94a680fc/html5/thumbnails/95.jpg)
Page 95
Modeling a Fully Distributed System