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


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)


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


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

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

http://www.sqae.com/UML.ppt


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


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


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


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


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

…


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


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.


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


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.


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


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


The UML process

There are four kinds of things in the UML.

1. Structural Things.

2. Behavioral Things.

3. Grouping Things.

4. Annotational Things.


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


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.


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.


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.

.


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.


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


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.



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.


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.


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.


Activity Diagrams (Cont...)

• Object flows, which represent the utilization of objects by action states and the influence of action states on objects.


Activity Diagram


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.


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.


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.


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


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


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


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


Structural Modeling: Core Elements (cont‘d)


constraint¹ a semantic condition or restriction.

{constraint}

¹ 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: Core Relationships


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


Static Structural Diagrams

Shows a graph of classifier elements connected by static relationships.

kinds

class diagram: classifier view

object diagram: instance view


Implementation Diagrams

Show aspects of model implementation, including source code structure and run-time implementation structure

Kinds

component diagram

deployment diagram


Shows the organizations and dependencies among software components

Components include

source code components

binary code components

executable components

Component Diagram


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


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


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


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‘).


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.

UseCaseName

ActorName



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


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

Fill orders

Shipping Clerk

status

order

Use Case Diagram


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


UML Notation Guide

Actor Relationships

EstablishCredit

Place

Order

Salesperson

Supervisor

1 *

1 *


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 …


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



Components

DictionarySpell-check

Synonyms

mymailer: Mailer

+Mailbox+RoutingList

-MailQueue



Component Diagram

Planner

Scheduler

GUI

Reservations

Update


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


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


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


All Use Cases Involving Customer as

Actor (Figure 7-4)


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


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


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


Activity Diagram— Telephone Order Scenario (Figure 7-12)


Activity Diagram— Web Order Scenario (Figure 7-13)


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‖


System Sequence Diagram (SSD)

Notation (Figure 7-14)


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


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


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


Repeating Message (Figure 7-15)


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


Activity Diagram and Resulting SSD for Telephone Order Scenario (Figures

7-16 and 7-17)

lec17 - uml

Documents

Transcript of lec17 - uml