lec17 - uml
-
Upload
abhishek-singh -
Category
Documents
-
view
122 -
download
0
Transcript of lec17 - uml
Introduction to UML 1
Background
What are object-oriented (OO) methods?
OO methods provide a set of techniques for analyzing, decomposing, and
modularizing software system architectures
In general, OO methods are characterized by structuring the system
architecture on the basis of its objects (and classes of objects) rather than
the actions it performs
What are the benefits of OO?
OO enhances key software quality factors of a system and its constituent
components
What is the rationale for using OO?
In general, systems evolve and functionality changes, but objects and classes
tend to remain stable over time
Introduction to UML 2
Background
Software Quality Factors
Object-oriented techniques enhance key external and internal software quality factors, e.g.,
1. External (visible to end-users)
(a) Correctness
(b) Robustness and reliability
(c) Performance
2. Internal (visible to developers)
(a) Modularity
(b) Flexibility/Extensibility
(c) Reusability
(d) Compatibility (via standard/uniform interfaces)
Introduction to UML 3
Background
OOA, OOD, and OOP
Object-oriented methods may be applied to different phases in the
software life-cycle
e.g., analysis, design, implementation, etc.
OO analysis (OOA) is a process of discovery
Where a development team models and under-stands the
requirements of the system
OO design (OOD) is a process of invention and adaptation
Where the development team creates the abstractions and
mechanisms necessary to meet the system's behavioral
requirements determined during analysis
Introduction to UML 4
Modeling
Modeling is a way of thinking about the problems using models
organized around the real world ideas.
A modeling method comprises a language and also a procedure for
using the language to construct models.
modeling is the only way to visualize your design and check it against
requirements before your crew starts to code.
Refernces http://www.omg.org/gettingstarted/what_is_uml.htm http://www.inconcept.com/JCM/April1998/halpin.html
Introduction to UML 5
Introduction
What is UML?
• Is a language. It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication.
• Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge.
• It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools).
Refernces www.sqae.com/UML.ppt
Introduction to UML 6
The UML is a graphical language for specifying
visualizing
constructing
documenting
the artifacts of software systems
Added to the list of OMG adopted technologies in November 1997 as UML 1.1
Most recent minor revision is UML 1.3, adopted in November 1999
Quick Tour
Introduction to UML 7
3.1 The Unified Process
In Perspective:
Most of the world is NOT object oriented and doesn‘t use the process we‘re presenting here.
However, in practice, they do something very similar that works for them.
In 1999, Booch, Jacobson, and Rumbaugh published a complete object-oriented analysis and design methodology that unified their three separate methodologies. Called the Unified Process.
The Unified Process is an adaptable methodology
It has to be modified for the specific software product to be developed
Introduction to UML 8
The Unified Process (contd)
UML is graphical
A picture is worth a thousand words
UML diagrams enable software engineers to communicate quickly and accurately
The Unified Process is a modeling technique
A model is a set of UML diagrams that represent various aspects of the software product we want to develop
UML stands for unified modeling language
UML is the tool that we use to represent (model) the target software product
The object-oriented paradigm is iterative and incremental in nature
There is no alternative to repeated iteration and incrementation until the UML diagrams are satisfactory
Introduction to UML 9
Define an easy-to-learn but semantically rich visual modeling language
Unify the Booch, OMT, and Objectory modeling languages
Include ideas from other modeling languages Incorporate industry best practices Address contemporary software development
issues scale, distribution, concurrency, executability, etc.
Provide flexibility for applying different processes
Enable model interchange and define repository interfaces
UML Goals
Introduction to UML 10
OMG UML Contributors
Aonix
Colorado State University
Computer Associates
Concept Five
Data Access
EDS
Enea Data
Hewlett-Packard
IBM
I-Logix
InLine Software
Intellicorp
Kabira Technologies
Klasse Objecten
Lockheed Martin
Microsoft
ObjecTime
Oracle
Ptech
OAO Technology Solutions
Rational Software
Reich
SAP
Softeam
Sterling Software
Sun
Taskon
Telelogic
Unisys
…
Introduction to UML 11
The basic building blocks of UML are:
model elements (classes, interfaces, components, use cases, etc.)
relationships (associations, generalization, dependencies, etc.)
diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)
Building Blocks
Introduction to UML 12
Well-Formedness Rules Well-formed: indicates that a model or model
fragment adheres to all semantic and syntactic rules that apply to it.
UML specifies rules for: naming
scoping
visibility
integrity
execution (limited)
However, during iterative, incremental development it is expected that models will be incomplete and inconsistent.
Introduction to UML 13
Unifying Concepts
classifier-instance dichotomy e.g., an object is an instance of a class OR
a class is the classifier of an object
specification-realization dichotomy e.g., an interface is a specification of a
class OR a class is a realization of an interface
analysis-time vs. design-time vs. run-time modeling phases (―process creep‖)
usage guidelines suggested, not enforced
Introduction to UML 14
What is structural modeling?
Structural model: a view of an system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations.
Introduction to UML 15
UML Concepts-The 4+1 view
Use Case view
Understandability
Logical View
Functionality
Process View
Performance
Scalable
Throughput
Implementation View
Software management
Deployment View
System topology
Delivery
Installation
Introduction to UML 16
UML Diagrams
UML includes diagrams for
use cases
static structures (class and object diagrams)
behavior (state-chart, activity, sequence and collaboration
diagrams)
implementation (component and deployment diagrams).
For data modeling purposes UML uses class diagrams, to
which constraints in a textual language may be added
Introduction to UML 17
The UML process
There are four kinds of things in the UML.
1. Structural Things.
2. Behavioral Things.
3. Grouping Things.
4. Annotational Things.
Introduction to UML 18
Structural Things Annotational Things Grouping Things Behavioral Things
1. Class
2. Interface
3. Collaboration
4. Use Case
5. Active Class
6. Components
7. Nodes
2. State Mechanism
1. Interaction 1. Packages 1. Notes
Things in UML
Introduction to UML 19
Diagrams in UML
A Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of things and relationships. UML includes 9 such diagrams.
1. Class Diagram.
2. Object Diagram.
3. Use Case Diagram.
4. Sequence Diagram.
5. Collaboration Diagram.
6. State Chart Diagram.
7. Activity Diagram.
9. Deployment Diagram.
Introduction to UML 20
Class Diagrams
Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves. These diagrams contain the following elements.
• Classes, which represent entities with common characteristics or features. These features include attributes, operations and associations.
• Associations, which represent relationships that relate two or more other classes where the relationships have common characteristics or features. These attributes and operations.
Introduction to UML 21
Object Diagrams
Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object diagrams contain the following elements:
• Objects, which represent particular entities. These are instances of classes.
• Links, which represent particular relationships between objects. These are instances of associations.
.
Introduction to UML 22
Sequence Diagrams
Sequence Diagrams describe interactions among classes. These interactions are modeled as exchange of messages. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams are a type of interaction diagrams. Sequence diagrams contain the following elements:
• Class roles, which represent roles that objects may play within the interaction.
• Lifelines, which represent the existence of an object over a period of time.
• Activations, which represent the time during which an object is performing an operation.
• Messages, which represent communication between objects.
Introduction to UML 23
Sequence Diagrams A sequence diagram displays object
interactions arranged in a time sequence
: Student registration
form registration manager
math 101
1: fill in info
2: submit
3: add course(joe, math 01)
4: are you open?
5: are you open?
6: add (joe) 7: add (joe)
math 101 section 1
Introduction to UML 24
Collaboration Diagrams
Collaboration Diagrams describe interactions among classes and associations. These interactions are modeled as exchanges of messages between classes through their associations. Collaboration diagrams are a type of interaction diagram. Collaboration diagrams contain the following elements.
• Class roles, which represent roles that objects may play within the interaction.
• Association roles, which represent roles that links may play within the interaction.
• Message flows, which represent messages sent between objects via links. Links transport or implement the delivery of the message.
Introduction to UML 25
Collaboration Diagrams
Dynamic behavior of objects can, in addition to sequence diagrams, also be represented by collaboration diagrams.
The transformation from a sequence diagram into a collaboration diagram is a bi-directional function.
The difference between sequence diagrams and collaboration diagrams is that collaboration diagrams emphasize more the structure than the sequence of interactions.
Within sequence diagrams the order of interactions is established by vertical positioning whereas in collaboration diagrams the sequence is given by numbering the interactions.
Introduction to UML 26
Collaboration Diagrams
Introduction to UML 27
Statechart Diagrams
Statechart (or state) diagrams describe the states and responses of a class. Statechart diagrams describe the behavior of a class in response to external stimuli. These diagrams contain the following elements:
• States, which represent the situations during the life of an object in which it satisfies some condition, performs some activity, or waits for some occurrence.
• Transitions, which represent relationships between the different states of an object.
Introduction to UML 28
Activity Diagrams
Activity diagrams describe the activities of a class. These diagrams are similar to statechart diagrams and use similar conventions, but activity diagrams describe the behavior of a class in response to internal processing rather than external events as in statechart diagram.
• Swimlanes, which represent responsibilities of one or more objects for actions within an overall activity; that is, they divide the activity states into groups and assign these groups to objects that must perform the activities.
• Action States, which represent atomic, or noninterruptible, actions of entities or steps in the execution of an algorithm.
• Action flows, which represent relationships between the different action states of an entity.
Introduction to UML 29
Activity Diagrams (Cont...)
• Object flows, which represent the utilization of objects by action states and the influence of action states on objects.
Introduction to UML 30
Activity Diagram
Introduction to UML 31
Activity Diagram
They are flow charts that are used to show the workflow of a system; that is, they show the flow of control from activity to activity in the system, what activities can be done in parallel, and any alternate paths through the flow.
Use when you have multiple activities going on at the same time.
There are two primary processes in an activity diagram, the fork and the join.
The fork splits one transition into multiple copies of itself.
The join takes multiple parallel transitions and releases one, only after all of the coming transitions have completed.
Swim lanes can be used to more clearly illustrate who is performing each activity, by labeling a section of the diagram.
Introduction to UML 32
Component Diagrams
Component diagrams describe the organization of and dependencies among software implementation components. These diagrams contain components, which represent distributable physical units, including source code, object code, and executable code.
Introduction to UML 33
Deployment Diagrams
Deployment diagrams describe the configuration of processing resource elements and the mapping of software implementation components onto them. These diagrams contain components and nodes, which represent processing or computational resources, including computers, printers, etc.
Introduction to UML 34
Swimlanes
A swimlane specifies a locus of activities
To partition the activity states on an
activity diagram into groups
each group representing the business
organization responsible for those activities
each group is called a swimlane
Each swimlane is divided from its
neighbor by a vertical solid line
Introduction to UML 35
Swimlanes
Each swimlane has a name unique
within its diagram
Each swimlane may represent some
real-world entity
Each swimlane may be implemented by
one or more classes
Every activity belongs to exactly one
swimlane, but transitions may cross
lanes
Introduction to UML 36
Swimlane Diagrams
Swimlane diagram show process in lanes to…
Depict tasks that occur concurrently
Illustrate who does what, and when
Also known as process maps, business process maps,LOV (line of visibility) charts, and process responsibility maps
Show the interdependencies of tasks
To design workflow as it will be supported by a workflow system, you may want to use a swimlane diagram
Show all roles and all tasks, as they relate to each other, which is critical in UCS
You can still use flowcharts to illustrate where you can simplify tasks
Introduction to UML 37
Construct Description Syntax
class a description of a set of objects that share the same attributes, operations, methods, relationships and semantics.
interface a named set of operations that characterize the behavior of an element.
component a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces.
node a run-time physical object that represents a computational resource.
«interface»
Structural Modeling: Core Elements
Introduction to UML 38
Structural Modeling: Core Elements (cont‘d)
Construct Description Syntax
constraint¹ a semantic condition or restriction.
{constraint}
¹ An extension mechanism useful for specifying structural elements.
Introduction to UML 39
Construct Description Syntax
association a relationship between two or more classifiers that involves connections among their instances.
aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.
generalization a taxonomic relationship between a more general and a more specific element.
dependency a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).
Structural Modeling: Core Relationships
Introduction to UML 40
Show the static structure of the model the entities that exist (e.g., classes, interfaces,
components, nodes) internal structure relationship to other entities
Do not show temporal information
Kinds static structural diagrams
class diagram object diagram
implementation diagrams component diagram deployment diagram
Structural Diagram Tour
Introduction to UML 41
Static Structural Diagrams
Shows a graph of classifier elements connected by static relationships.
kinds
class diagram: classifier view
object diagram: instance view
Introduction to UML 42
Implementation Diagrams
Show aspects of model implementation, including source code structure and run-time implementation structure
Kinds
component diagram
deployment diagram
Introduction to UML 43
Shows the organizations and dependencies among software components
Components include
source code components
binary code components
executable components
Component Diagram
Introduction to UML 44
Deployment Diagram
Shows the configuration of run-time processing elements and the software components, processes and objects that live on them
Deployment diagrams may be used to show which components may run on which nodes
Introduction to UML 45
When to model structure
Adopt an opportunistic top-down+bottom-up approach to modeling structure Specify the top-level structure using ―architecturally significant‖
classifiers and model management constructs (packages, models, subsystems; )
Specify lower-level structure as you discover detail re classifiers and relationships
If you understand your domain well you can frequently start with structural modeling; otherwise If you start with use case modeling (as with a use-case driven
method) make sure that your structural model is consistent with your use cases
If you start with role modeling (as with a collaboration-driven method) make sure that your structural model is consistent with your collaborations
Introduction to UML 46
Structural Modeling Tips
Define a ―skeleton‖ (or ―backbone‖) that can be extended and refined as you learn more about your domain.
Focus on using basic constructs well; add advanced constructs and/or notation only as required.
Defer implementation concerns until late in the modeling process.
Structural diagrams should emphasize a particular aspect of the structural model
contain classifiers at the same level of abstraction
Large numbers of classifiers should be organized into packages
Introduction to UML 47
What is use case modeling?
use case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‗use cases‘) that are meaningful to users (‗actors‘).
Introduction to UML 48
Use Case Modeling: Core Elements
Construct Description Syntax
use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.
actor A coherent set of roles that users of use cases play when interacting with these use cases.
system boundary
Represents the boundary between the physical system and the actors who interact with the physical system.
UseCaseName
ActorName
Introduction to UML 49
Construct Description Syntax
association The participation of an actor in a usecase. i.e., instance of an actor andinstances of a use case communicatewith each other.
extend A relationship from an extension usecase to a base use case, specifyinghow the behavior for the extensionuse case can be inserted into thebehavior defined for the base usecase.
generalization A taxonomic relationship between amore general use case and a morespecific use case.
Use Case Modeling: Core Relationships
<<extend>>
Introduction to UML 50
Shows use cases, actor and their relationships
Use case internals can be specified by text and/or interaction diagrams
Kinds use case diagram use case description
Use Case Diagram Tour
Introduction to UML 51
Fig. 3-44, UML Notation Guide
Customer
Supervisor
SalespersonPlace
Establishcredit
Check
Telephone Catalog
Fill orders
Shipping Clerk
status
order
Use Case Diagram
Introduction to UML 52
UML Notation Guide
Use Case Relationships
additional requests :
OrderProduct
SupplyArrange
«include»«include»«include»
RequestCatalog
«extend»Extension points
PaymentCustomer Data
after creation of the order
Place Order
1 * the salesperson asks forthe catalog
Introduction to UML 53
UML Notation Guide
Actor Relationships
EstablishCredit
Place
Order
Salesperson
Supervisor
1 *
1 *
Introduction to UML 54
Use Case Description: Change Flight
Actors: traveler, client account db, airline reservation system
Preconditions:
Traveler has logged on to the system and selected ‘change flight itinerary’ option
Basic course System retrieves traveler’s account and flight itinerary from client
account database
System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment.
System asks traveler for new departure and destination information; traveler provides information.
If flights are available then
…
System displays transaction summary.
Alternative courses
If no flights are available then …
Introduction to UML 55
Classes: compartments with names
UML Notation Guide
bill no-shows
Reservation
operations
guarantee()cancel ()change (newDate: Date)
responsibilities
match to available rooms
exceptions
invalid credit card
Introduction to UML 56
Fig. 3-84, UML Notation Guide
Components
DictionarySpell-check
Synonyms
mymailer: Mailer
+Mailbox+RoutingList
-MailQueue
Introduction to UML 57
Fig. 3-81, UML Notation Guide
Component Diagram
Planner
Scheduler
GUI
Reservations
Update
Introduction to UML 58
When to model use cases
Model user requirements with use cases.
Model test scenarios with use cases.
If you are using a use-case driven method start with use cases and derive your
structural and behavioral models from it.
If you are not using a use-case driven method make sure that your use cases are consistent
with your structural and behavioral models.
Introduction to UML 59
Use Case Modeling Tips
Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers
When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams
Factor out common usages that are required by multiple use cases If the usage is required use <<include>>
If the base use case is complete and the usage may be optional, consider use <<extend>>
A use case diagram should contain only use cases at the same level of abstraction
include only actors who are required
Large numbers of use cases should be organized into packages
Introduction to UML 60
Example: Online HR System
Online HR System
Locate
Employees
Update
Employee
Profile
Update Benefits
Access Travel
System
Access Pay
Records
Employee
Manager
Healthcare Plan System
{if currentMonth = Oct.}
{readOnly}
Insurance Plan System
Introduction to UML 61
Online HR System: Use Case Relationships
Update Medical
Plan
Update Dental
Plan
Update Benefits______________
Extension points
benefit options:
after required enrollments
Update
Insurance Plan
Employee
<<include>> <<include>> <<include>>
Elect
Reimbursement
for Healthcare
Elect Stock
Purchase
<<extend>>
employee requests
stock purchase option
<<extend>>
employee requests
reimbursement option
extension
condition
extension point
name and
location
Introduction to UML 62
All Use Cases Involving Customer as
Actor (Figure 7-4)
Introduction to UML 63
Online HR System: Update Benefits Use Case
Actors: employee, employee account db, healthcare plan system, insurance plan system
Preconditions:
Employee has logged on to the system and selected ‘update benefits’ option
Basic course System retrieves employee account from employee account db
System asks employee to select medical plan type; include Update Medical Plan.
System asks employee to select dental plan type; include Update Dental Plan.
…
Alternative courses
If health plan is not available in the employee’s area the employee is informed and asked to select another plan...
Introduction to UML 64
UML is effective for modeling large, complex software systems
It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects
It can specify systems in an implementation-independent manner
10-20% of the constructs are used 80-90% of the time
Structural modeling specifies a skeleton that can be refined and extended with additional structure and behavior
Use case modeling specifies the functional requirements of system in an object-oriented manner
Ideas to Take Away
Introduction to UML 65
Activity Diagrams
Used to document workflow of business process activities for each use case or scenario
Standard UML 2.0 diagram as seen in Chapter 4
Can support any level of use case description; a supplement to use case descriptions
Helpful in developing system sequence diagrams
Introduction to UML 66
Activity Diagram— Telephone Order Scenario (Figure 7-12)
Introduction to UML 67
Activity Diagram— Web Order Scenario (Figure 7-13)
Introduction to UML 68
Identifying Inputs and Outputs— The System Sequence Diagram
System sequence diagram (SSD) is type of UML 2.0 interaction diagram
Used to model input and output messaging requirements for a use case or scenario
Shows actor interacting with system
Shows sequence of interactions as messages during flow of activities
System is shown as one object: a ―black box‖
Introduction to UML 69
System Sequence Diagram (SSD)
Notation (Figure 7-14)
Introduction to UML 70
SSD Notation
Actor represented by a stick figure – a person (or role) that interacts with system by entering input data and receiving output data
Object is a rectangle with name of object underlined – shows individual object and not class of all similar objects ( :System for SSD )
Lifeline or object lifeline is a vertical line under object or actor to show passage of time for object
Message is labeled on arrows to show messages sent to or received by actor or system
Introduction to UML 71
SSD Lifelines
Vertical line under object or actor
Shows passage of time
If vertical line dashed
Creation and destruction of thing is not important for scenario
Long narrow rectangles
Activation lifelines emphasize that object is active only during part of scenario
Introduction to UML 72
SSD Messages
Internal events identified by the flow of objects in a scenario
Requests from one actor or object to another to do some action
Invoke a particular method
Introduction to UML 73
Repeating Message (Figure 7-15)
Introduction to UML 74
Developing a System Sequence Diagram
Begin with detailed description of use case from fully developed form or activity diagram
Identify input messages
Describe message from external actor to system using message notation
Identify and add any special conditions on input message, including iteration and true/false conditions
Identify and add output return messages
Introduction to UML 75
Developing a System Sequence Diagram
Begin with detailed description of use case from fully developed form or activity diagram
Identify input messages
Describe message from external actor to system using message notation
Identify and add any special conditions on input message, including iteration and true/false conditions
Identify and add output return messages
Introduction to UML 76
Activity Diagram and Resulting SSD for Telephone Order Scenario (Figures
7-16 and 7-17)