Professional Documents
Culture Documents
-1-
-2-
3/27/2013
Modeling Languages
Modeling is the process of model creation. In the context of software development, a typical modeling language provides the (mainly graphical) notation elements and their semantic to develop models that express the product of analysis and design of the system. A modeling language is not a programming language. A modeling language may be less precise on purpose because additional detail may be irrelevant.
-3-
-4-
3/27/2013
Model Types
Models may also be classified according to many criteria such as: The underlying Technology:
Structured Analysis Modelling Object Oriented Modelling
Notation
Textual Graphical Formal
Abstraction
High Level Low Level
5
Context Models
Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. Architectural models show the system and its relationship with other systems. This model as shown on the following slide is not UML. How to represent it using UML? Answer this question after you finish reading this tutorial.
3/27/2013
Securit y s ys tem Branch accoun t in g s ys tem Aut o -t el l er s ys tem Branch coun ter s ys tem Main tenance s ys tem Us age dat ab as e Acco un t da t abas e
Structure Diagram
Diagram Behavior Diagram
Object Diagram Package Diagram Activity Diagram Use Case Diagram State Machine Diagram Interaction Diagram
-8-
3/27/2013
-9-
- 10 -
3/27/2013
- 11 -
Class Notation
Operations
- 12 -
3/27/2013
Operations
- 13 -
- 14 -
3/27/2013
An attribute describes a piece of information that an object owns or knows about itself.
A class may have any number of attributes or no attributes at all. Every object of a class will have a specific value/values for its class attributes. Attribute names typically begin with a lowercase letter with capitalized first letter of every word.
- 15 -
(cont.)
Where: Visibility defines how the attribute can be seen and used by other classes [an attribute may be public (+) or private (-)]. Name is an identifier string that represents the name of the attribute. Multiplicity is a specification of the range of allowable cardinalities that a set may assume.
- 16 -
3/27/2013
(cont.)
- 17 -
- 18 -
3/27/2013
- 19 -
- 20 -
10
3/27/2013
Relationships Introduction
Represents the basic relational building blocks of the UML that associate (connects) things together. Includes the following main types: Association, Generalization, Inheritance, Realization, and Interfaces
- 21 -
Relationships Association
An association describes discrete connections among classes in a system. An association describes a set of links. Link: An instance of an association.
association name Student name direction
Register
Course
ahmed
- 22 -
data structure
11
3/27/2013
Relationships Association
Navigation Across Association
Bidirectional, unless otherwise specified. Can be explicitly represented by an arrowhead pointing to the direction of traversal.
Student
Register
Course
association navigation
- 23 -
Relationships Association
Role
The named specific behavior of a classifier participating in an association.
Person
employee
Works for
employer
Department
role name
- 24 -
12
3/27/2013
Relationships Association
Multiplicity
How many objects may be connected across a link? Expression that evaluates to a range of values.
Explicit value:
1..*
Works for
Person
employee
- 25 -
* employer
Department
Relationships Association
Constraints
Express constraints on the association relationships. Constraints may appear on both ends, either ends, or neither end of the association.
Thomas A. Pender. UML Weekend Crash Course, Wiley Publishing, Inc., 2002
- 26 -
13
3/27/2013
Relationships Association
Association Class
An association class encapsulates information about an association. Association classes add attributes, operations, and other features to associations.
Thomas A. Pender. UML Weekend Crash Course, Wiley Publishing, Inc., 2002
- 27 -
Relationships Association
Aggregation
A special form of association. Specifies a whole-part relationship between the aggregate (whole) and a component part.
Product
whole 1 aggregation
part
1..*
Component
- 28 -
14
3/27/2013
Relationships Association
Composition
Composition is used for aggregations where the life span of the part
depends on the life span of the aggregate.
- 29 -
Relationships Association
Composition (cont.)
Car
1 composition
Tire
- 30 -
15
3/27/2013
Relationships Generalization
It is a relationship between a general thing (superclass or parent) and a more specific kind of that thing (subclass or child). It is-a-kind-of relationship, one thing is-a-kind-of a more general thing. A subclass inherits all the properties of its superclass. A subclass may have its own properties in addition to the ones inherited from its superclass.
- 31 -
- 32 -
16
3/27/2013
Thomas A. Pender. UML Weekend Crash Course, Wiley Publishing, Inc., 2002
- 33 -
Relationships Inheritance
Inheritance is the mechanism by which more specific elements incorporate structure and behavior of more general elements related by behavior. A class may have one or more superclasses. A class that has no superclass and one or more subclasses is called a root class. A class that has no sublasses is called a leaf class.
- 34 -
17
3/27/2013
- 35 -
- 36 -
18
3/27/2013
Single inheritance
- 37 -
Multiple inheritance
- 38 -
19
3/27/2013
Package Diagram
- 39 -
Packages
A package is a grouping of model elements. It is a general purpose mechanism for organizing modeling elements into groups. Packages are extremely useful on larger-scale systems. They help in getting a picture of the dependencies between major elements of a system. Package name may be a simple name or a path name.
- 40 -
20
3/27/2013
Packages
Simple name is the name alone without any path information. A path name is the package name prefixed by the name of the package in which that package lives, if any. Packages themselves may be nested within other packages A package may contain subordinate packages as well as other kinds of model elements All kinds of UML model elements can be organized into packages
simple name
- 41 -
Packages (cont.)
- 42 -
21
3/27/2013
Packages (cont.)
- 43 -
Functional View
Use Case Diagram Activity Diagram
- 44 -
22
3/27/2013
- 45 -
- 46 -
23
3/27/2013
- 48 -
24
3/27/2013
- 49 -
- 50 -
25
3/27/2013
The user in the three scenarios share the same goal: to buy a product.
- 51 -
52
26
3/27/2013
System Response
3. Determine item price, adds item information to running sales transaction 5. Calculates the total
System Response
3. Determine item price, adds item information to running sales transaction 5. Calculates the total
27
3/27/2013
System Response
3. Determine item price, adds item information to running sales transaction 5. Calculates the total
Thomas A. Pender. UML Weekend Crash Course, Wiley Publishing, Inc., 2002
- 56 -
28
3/27/2013
System: Sets the boundary of the system in relation to the actors who uses it (outside the system) and the features it must provide (inside the system).
Use Case: A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. Each Use Case:
Identifies a key feature of the system needed to fulfill the user/actor requirements Expresses a goal that the system must achieve
- 57 -
- 58 -
29
3/27/2013
- 59 -
Problem: Developers tend to complicate use case diagrams and spend too
much time in it.
Solution: Identify the set of Use Case that describes only those features
visible and meaningful to the actors who use the system.
Keeping this in mind will help avoiding functional decomposition (the breaking down of procedures and tasks into smaller and smaller processes until describing all the internal workings of the system).
- 60 -
30
3/27/2013
- 61 -
(cont.)
For bidirectional associations, either an arrowhead is placed on both ends of the association line, or simply no arrowheads are shown at all.
Thomas A. Pender. UML Weekend Crash Course, Wiley Publishing, Inc., 2002
- 62 -
31
3/27/2013
- 63 -
- 64 -
32
3/27/2013
- 65 -
- 66 -
33
3/27/2013
- 67 -
Activity Diagram
- 68 -
34
3/27/2013
It shows.
The flow of control from activity to activity in the process, What activities can be done in parallel. Alternate paths through the flow.
They are very well understood without any computer knowledge, so are an excellent means for user communication
70
35
3/27/2013
[lowPriority] Open Incident [fire & highPriority] [not fire & highPriority] Notify Fire Chief Notify Police Chief Allocate Resources
71
Splitting
Allocate Resources Open Incident Coordinate Resources Document Incident
Synchronization
Archive Incident
72
36
3/27/2013
Dispatcher
73
Start
Browse Course Catalog Select Course Info
Activity
Enter Personal Data
Guard
Confirm Registration
Branch
[data correct]
End
[else] Send Email Print Bill
Update Course
74
37
3/27/2013
(cont.)
Billing System
Swimlane
Fork
Send Email Update Course Print Bill
Join
75
38
3/27/2013
Dynamic View
Sequence Diagram
- 77 -
Sequence Diagram
- 78 -
39
3/27/2013
- 79 -
- 80 -
40
3/27/2013
- 81 -
1. Object lifeline 2. Message/Stimulus 3. Iteration 4. Self-reference 5. Return 6. Anonymous object 7. Object name 8. Sequence number 9. Condition 10. Basic comment
Thomas A. Pender. UML Weekend Crash Course, Wiley Publishing, Inc., 2002
- 82 -
41
3/27/2013
Meaning
Invokes an operation on an object; an object may send a message to itself, resulting in the local invocation of an operation Returns a value to the caller Sends a signal to an object Creates an object Destroys an object; an object may commit suicide by destroying itself
- 83 -
- 84 -
42
3/27/2013
- 85 -
43
3/27/2013
88
44
3/27/2013
State Trigger
Ready
Transition
stop /ctr := 0
Final state
Done
Action
stop
89
threshold
time
90
45
3/27/2013
Handle Request
Terminate Object
91
Terminate Object
stop
92
46
3/27/2013
LampOn
entry/lamp.on(); exit/lamp.off();
e2
e1
93
off/printf(to off);
LampOff
entry/lamp.off(); exit/printf(exiting);
47
3/27/2013
do activity Error
entry/printf(error!) do/while (true) alarm.ring();
95
Guards
Conditional execution of transitions
Happy
Unhappy
96
48
3/27/2013
Conditional Branching
Choice pseudostate: guards are evaluated at the instant when the decision point is reached Selling Happy
Unhappy
97
flash/
on/ on/
98
49
3/27/2013
Statechart Example
Course Offering The CourseOffering object can be in one of the following states: Initialization (prior to registration, no students added) Open (able to accept students) Closed (max number of students registered for it) Cancelled (no longer offered)
99
Statechart Example
Course Offering
100
50
3/27/2013
- 101 -
- 102 -
51
3/27/2013
Implementation Diagrams
- 103 -
Implementation Diagrams
After completing the logical design of the system, the next step is to define the physical implementation of the design. The physical implementation addresses three problems: the software, the hardware, and the integration of the two.
UML defines two types of diagrams for describing the implementation of the system:
Component diagram: models the physical implementation of the software. Deployment diagram: models the physical architecture of the hardware.
Combined, they model the distribution of the application software across the hardware implementation.
- 104 -
52
3/27/2013
- 105 -
ComponentName
UML 2 removed that icon but allows the annotation of a class box with a similar-looking icon. Alternatively, the component keyword can be used in a class box.
<<component>>
ComponentName ComponentName
- 106 -
53
3/27/2013
- 107 -
- 108 -
54
3/27/2013
- 109 -
- 110 -
55
3/27/2013
- 111 -
56