introduction to uml part 1 structural modeling use case modeling
Post on 20-Dec-2015
229 Views
Preview:
TRANSCRIPT
Introduction to UML
Part 1
Structural Modeling
Use case modeling
Overview
UML – background Quick tour of a subset of UML Structural modeling – Class Diagrams
Essentials More advanced features
Use case modeling - Use Case Diagrams Behavioral Modeling - Event Diagrams, State Diagrams.
Tijuana “shantytown”: http://www.macalester.edu/~jschatz/residential.html
The Challenge
Fallingwater: http://www.adelaide.net.au/~jpolias/FLW/Images/FallingWater.jpeg
The Vision
The UML is a graphical language for specifying visualizing constructing documenting
the artifacts of software systemsAdded to the list of OMG adopted technologies in November 1997 as UML 1.1Most recent minor revision is UML 1.3 (November 1999)
Quick Tour
Define an easy-to-learn but semantically rich visual modeling languageUnify the Booch, OMT, and Objectory modeling languagesInclude ideas from other modeling languagesIncorporate industry best practicesAddress contemporary software development issues scale, distribution, concurrency, executability, etc.
Provide flexibility for applying different processesEnable model interchange and define repository interfaces
UML Goals
OMG UML Contributors
AonixColorado State UniversityComputer AssociatesConcept FiveData AccessEDSEnea DataHewlett-Packard IBMI-LogixInline SoftwareIntellicorpKlasse ObjectenLockheed Martin
MicrosoftObjecTimeOraclePtech OAO Technology SolutionsRational SoftwareReichSAPSofteamSterling SoftwareSunTaskonTelelogicUnisys…
Contributors = Original Submitters + RTF1 + RTF2 + …
The basic building blocks of UML are: model elements (classes, objects, components, use cases, etc.) relationships (associations, generalization, dependencies, etc.)Depicted via diagrams:
class, object diagrams use case diagrams sequence (event) diagram activity diagrams collaboration diagram package diagram deployment diagram
UML
Structural, Use case and Behavioral modeling
Structural model: shows the static structure of the model the entities that exist (e.g., classes, interfaces, components,
nodes), their internal structure and relationship to other entities
does not include temporal informationClass&Object Diagrams (Analysis and Design)Component and Deployment Diagrams (Design and Implem.)
does not include interaction (message connections)Use case model -specifies system requirements in OO manner
Use case diagram and description
Behavioral/interaction model Sequence (event) diagram, Activity diagram State diagram
Class Diagram and Object Diagram
Shows static structure of concepts Concepts and Classes, Types (interfaces to
software components) Relations between them
Can be shown on various levels of granularity (example on the next slide)
Example: Class specification, 3 levels
Window
display ()
size: Areavisibility: Boolean
hide ()
Window
Window
+default-size: Rectangle#maximum-size: Rectangle
+create ()
+display ()
+size: Area = (100,100)#visibility: Boolean = invisible
+hide ()
-xptr: XWindow*
-attachXWindow(xwin:Xwindow*)
{abstract,author=Joe,status=tested}
Classes: method body
report ()
BurglarAlarm
isTripped: Boolean = false
PoliceStation
1 station
*
{ if isTrippedthen station.alert(self)}
alert ()
Generalization
Shape
SplineEllipsePolygon
Shape
SplineEllipsePolygon
Shared Target Style
Separate Target Style
. . .
. . .
GeneralizationVehicle
WindPoweredVehicle
MotorPoweredVehicle
LandVehicle
WaterVehicle
venue
venuepowerpower
SailboatTruck
{overlapping} {overlapping}
Associations (a.k.a. Instance Connections) and Association Classes
PersonJob
Companyemployeeemployer
Jobsalary
Notice: Multiplicity labels are placed in reverse-order of Coad-Yourdon OOA
Associations can be labeled and directed.
Job – is an association class. Implies One Job per each Person-Company association.
Aggregation and Composition
Polygon PointContains
{ordered}
3..1
GraphicsBundle
colortexturedensity
1
1
-bundle
+points
Both represent whole-part relationship, but are defined differently by different people
•Aggregation (white diamond) •Composition (black diamond) is a stronger notion:
• parts do not exists outside of whole, •each part belongs to a single whole.
Navigability
Polygon PointContains
{ordered}
3..1
GraphicsBundle
colortexturedensity
1
1
-bundle
+points
Note directionality (a.k.a. Navigability) of the connection and label.
Many ways of depicting Composition
Window
scrollbar [2]: Slidertitle: Headerbody: Panel
Window
scrollbar title body
Header Panel
2 1 1
Slider
111
Composition
Fig. 3-36, UML Notation Guide
scrollbar:Slider
Window
2
title:Header1
body:Panel1
Advanced Concepts
•Qualified associations•Parameterized classes (a.k.a templates)•Types and Implementation Classes•Interfaces
Qualified Associations
Bank
Person
0..1
Account #
• Account# is the qualifier of Bank-Person association means
Unique instance of Account # per each Bank-Person association.
Thus, all access to Person in connection to a Bank requires the value of Account #.
Parameterized Classes a.k.a. Templates
Example: class Set – represents a collection of objects of a class. That class becomes a parameter to the parameterized class e.g. set of coins, set of students, set of <T>
Set
Insert(T)Remove(T)
T T
ParameterParameterized
Class
StudentSet“bind”
T to Student
Unlike with specialization, Class StudentSet cannot add Attributes nor Services
Types and Implementation Classes
Type – specifies the behavioral model
Implementation Classes defines the implementing data structure and
methods for the stereotype
<<type>>Set
Insert(T)Remove(T)InSet?(T)
T T
<<implementatuibClass>>HashTableSet
Insert(T)
Remove(T)InSet?(T)SetTableSize(size)
T
HashTable1
realization
Interface Classes
Interface – a named set of operations that characterize the behavior of an elementInterface Classes – similar idea to purely Abstract Classes (no instances), but have no Attributes.Interfaces are realized by implementing them classes
Structural Modeling: Summary of Notation
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: Summary of Notation
Construct Description Syntax
constraint¹ a semantic condition or restriction.
{constra in t}
¹ An extension mechanism useful for specifying structural elements.
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:Relationships
Construct Description Syntax
realization a relationship between a specification and its implementation.
Structural Modeling: Relationships
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
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; see Tutorial 3)
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
Use Case Modeling
What is use case modeling?
Core concepts
Diagram tour
When to model use cases
Modeling tips
Example: Online HR System
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’).
Actors are people or other systems
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.
UseCaseNam e
ActorNam e
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>>
Construct Description Syntax
include An relationship from a base use caseto an inclusion use case, specifyinghow the behavior for the inclusion usecase is inserted into the behaviordefined for the base use case.
Use Case Modeling: Core Relationships (cont’d)
<<include>>
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
Fig. 3-44, UML Notation Guide
Customer
Supervisor
SalespersonPlace
Establishcredit
Check
Telephone Catalog
F ill orde rs
Shipping Clerk
status
order
Use Case Diagram
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
Fig. 3-46, UML Notation Guide
Actor Relationships
EstablishCredit
PlaceOrder
Salesperson
Supervisor
1 *
1 *
Use Case Description:Change Flight Itinerary
Actors: traveler, client account db, airline reservation systemPreconditions:
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 …
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.
Use Case Modeling TipsMake sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmersWhen defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams (see Lecture 2)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 (see Lecture 3)
Example: Online HR System
Online HR System
LocateEm ployees
UpdateEm ployee
Profile
Update Benefits
Access TravelSystem
Access PayRecords
Em ployee
M anager
Healthcare P lan System
{if currentMonth = O ct.}
{readOnly}
Insurance P lan System
Online HR System:Use Case Relationships
Update M edicalP lan
Update DentalP lan
Update Benefits______________Extension pointsbenefit options:
after required enrollm ents
UpdateInsurance P lan
Em ployee
<<include>> <<include>> <<include>>
ElectReim bursem entfor Healthcare
Elect StockPurchase
<<extend>>em ployee requestsstock purchase option
<<extend>>em ployee requestsreim bursem ent option
extensioncondition
extension pointname andlocation
Online HR System: Update Benefits Use Case
Actors: employee, employee account db, healthcare plan system, insurance plan systemPreconditions:
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...
UML is effective for modeling large, complex software systemsIt is simple to learn for most developers, but provides advanced features for expert analysts, designers and architectsIt can specify systems in an implementation-independent manner10-20% of the constructs are used 80-90% of the timeStructural modeling specifies a skeleton that can be refined and extended with additional structure and behaviorUse case modeling specifies the functional requirements of system in an object-oriented manner
Ideas to Take Away
ReferencesOMG UML Specification v. 1.3, OMG doc# ad/06-08-99
available from many urls, including
http://www.jeckle.de/files/omg-uml-1.3.pdf
[Kobryn 00] UML 2001: A Standardization Odyssey,
Communications of the ACM, Oct. 1999.
[Kobryn 99] Object Modeling with UML: Introduction to
UML, Tutorial, available from
http://cgi.omg.org/cgi-bin/doc?omg/99-11-04
[Fowler (with Scott)] UML Distilled, Addison-Wesley
top related