Introduction to UML Part 1 Structural Modeling Use case modeling.

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


constraint¹ a semantic condition or restriction.

{constra in t}

¹ An extension mechanism useful for specifying structural elements.


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


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


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


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>>


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


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


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

Introduction to UML Part 1 Structural Modeling Use case modeling.

Documents

Transcript of Introduction to UML Part 1 Structural Modeling Use case modeling.