uml unified modeling language l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
UML Unified Modeling Language PowerPoint Presentation
Download Presentation
UML Unified Modeling Language

Loading in 2 Seconds...

play fullscreen
1 / 63

UML Unified Modeling Language - PowerPoint PPT Presentation


  • 353 Views
  • Uploaded on

UML Unified Modeling Language Chapter One Introduction District Module Semi-Auto Fill Delivery Status Order Requested Order Initiated Order Approved Order Filled Application Server Central-Office Module Database Server Sign-Shop Module Figure 4 Data Flow of Sign Orders

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'UML Unified Modeling Language' - liam


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
uml unified modeling language

UML Unified Modeling Language

© Wolfgang Pelz 2000-04

chapter one introduction

Chapter OneIntroduction

© Wolfgang Pelz 2000-04

slide3

District Module

Semi-Auto Fill

Delivery Status

Order Requested

Order Initiated

Order Approved

Order Filled

Application Server

Central-Office Module

Database Server

Sign-Shop Module

Figure 4 Data Flow of Sign Orders

© Wolfgang Pelz 2000-04

engineering and blueprints
Engineering and Blueprints
  • standard notation
  • communication tool

© Wolfgang Pelz 2000-04

history
History
  • CASE Tools: Automation of Software Development
  • People-to-People
  • People-to-Computer
  • Rational Software (An IBM Company)
  • Rational Rose / MS Visio:

Converting UML-Diagrams-to-Programs

  • OMG: Object Management Group

© Wolfgang Pelz 2000-04

history6
History
  • Booch: Booch Method
  • Rumbaugh: OMT (object modeling tech.)
  • Jacobson: OOSE (OO software engrg.)
  • Three amigos: UML

© Wolfgang Pelz 2000-04

history7
History
  • UML: an open standard controlled by OMG
  • UML 1.0 (1997)
  • UML 2.0 (2004)

© Wolfgang Pelz 2000-04

meta model
Meta-Model
  • a diagram that defines the notation to be used in the modeling language

© Wolfgang Pelz 2000-04

uml supported diagrams
class

object

component

package

deployment

use case

interaction

communication

sequence

collaboration

timing

activity

state/statechart

UML supported diagrams

© Wolfgang Pelz 2000-04

brief overview
Brief Overview
  • class - set of classes, interfaces, collaboration, relationships
  • object - set of objects and their relationships
  • use case - description of functionality provided by system along with actors and their connection to the use case

© Wolfgang Pelz 2000-04

overview cont
Overview (cont.)
  • interaction - set of objects and their relationships including messages
  • state/statechart - a state machine showing states, transitions, events, and activities
  • activity - statechart sequential flow of activities
  • component - physical structure of code in terms of code components

© Wolfgang Pelz 2000-04

overview cont12
Overview (cont.)
  • deployment - physical architecture of hardware and software in the system
  • package - shows packages of classes and dependencies among them
    • grouping mechanism
    • form of class diagram
    • also called subsystem

© Wolfgang Pelz 2000-04

organization of diagrams
domain expert

use case

activity

interaction

system designer

class

component

deployment

state

package

Organization of Diagrams

© Wolfgang Pelz 2000-04

another organization
static

class

component

package

deployment

dynamic

use case

interaction

state

activity

Another Organization

© Wolfgang Pelz 2000-04

another organization15
Another Organization

© Wolfgang Pelz 2000-04

model terminology
Model Terminology
  • user model view - problem and solution from the perspective of the users
  • structural model view - static or structural aspects of a problem and solution
  • behavioral model view - dynamic or behavioral aspects; interactions or collaborations among problem and solution elements

© Wolfgang Pelz 2000-04

model terminology17
Model Terminology
  • implementation model view - structural and behavioral aspects of the solution’s realization
  • environment model view - structural and behavioral aspects of the domain in which a solution must be realized

© Wolfgang Pelz 2000-04

language versus method
Language versus Method
  • A (software engineering) method is composed of a language and a process.
  • UML is a language, not a method, since it has no notion of process
  • process can be:

© Wolfgang Pelz 2000-04

terminology
Terminology
  • inception - a few days’ work to decide if a few months of elaboration is worth it
  • elaboration - risk assessment, about 1/5 of project time; includes planning based on use cases; generates a commitment schedule
  • construction - composed of iterations that include refactoring, frameworks & patterns
  • transition - beta testing, optimizing, training

© Wolfgang Pelz 2000-04

refactoring
Refactoring

the process of changing the internal structure

of a program or system to make it easier to

understand or change while maintaining its

functionality

© Wolfgang Pelz 2000-04

frameworks patterns
Frameworks & Patterns
  • frameworks are reusable designs of all or part of a software system described by a set of abstract classes and the way instances of those classes collaborate
  • patterns are common designs that have repeating themes

© Wolfgang Pelz 2000-04

chapter three class diagram
Chapter ThreeClass Diagram

© Wolfgang Pelz 2000-04

class diagram
Class Diagram
  • static view of a system in terms of classes and relationships among the classes
    • associations
    • subtypes
  • typically done in parallel with interaction diagrams
  • a more graphical alternative to CRC cards

© Wolfgang Pelz 2000-04

important questions finding classes
Important Questions(Finding classes)
  • Is there information to be stored/analyzed?
  • Do external systems exist?
  • Are there patterns, class libraries, components, etc?
  • Must the system handle devices?
  • Are there organizational parts (business model)?
  • Do actors have roles to play in the system?

© Wolfgang Pelz 2000-04

common uses
Common Uses
  • Objective: provide a view of services the system should provide to its end user
  • model the vocabulary of a system
  • model simple collaborations
  • model a logical database schema

© Wolfgang Pelz 2000-04

terminology27
Terminology
  • association: a description of a related set of links between objects of two classes
  • subtype: “is a” or “is a kind of”
  • generalization: relationship between a more general and a more specific element - see subtype

© Wolfgang Pelz 2000-04

terminology cont
Terminology (cont.)
  • dependency: relationship where a change in the independent element affects the dependent element
  • refinement: relationship between two descriptions of the same thing, but at different levels of abstraction

© Wolfgang Pelz 2000-04

terminology cont29
Terminology (cont.)
  • Aggregation: association specifying a whole-part relationship between the aggregate (whole) and a component (part). An aggregation may not have any components and a component may not belong to any aggregation.
  • composition: special form of aggregation (a component must belong to a composition and only to one composition)
    • strong ownership
    • coincident lifetime of parts and whole

© Wolfgang Pelz 2000-04

notation
Notation

© Wolfgang Pelz 2000-04

more notation
More Notation

© Wolfgang Pelz 2000-04

aggregation composition
Aggregation/Composition

© Wolfgang Pelz 2000-04

example
Example

© Wolfgang Pelz 2000-04

levels of abstraction
Levels of Abstraction
  • conceptual model: class name
    • associations are conceptual relationships
  • specification model: above + behavior
    • associations and responsibilities
  • implementation model: above + state
    • probably too low-level for design stage

© Wolfgang Pelz 2000-04

another example
Another Example

© Wolfgang Pelz 2000-04

associations
Associations
  • Describe relations between classes
  • associations have roles (given at the end of the association) which have multiplicities
  • associations have navigability
    • A sends a message to B
    • A creates an instance of B
    • A needs to maintain a connection with B
  • navigability is identified from collaboration diagrams

© Wolfgang Pelz 2000-04

associations cont
Associations (cont.)
  • navigability in one direction is termed uni-directional association and has an arrow
  • two-way navigability is bi-directional association and has no arrow
  • an association with no arrow could also mean that the direction is unknown
  • bidirectional requires inverse relationship

f ( f -1(y)) = y f -1( f (x)) = x

© Wolfgang Pelz 2000-04

operation signatures
Operation Signatures

visibilityname(parameters) : return type

optional optional

+ public

# protected

- private

  • Example:

+ getData (pos : Position) : Data

© Wolfgang Pelz 2000-04

operations methods
Operations & Methods
  • Operation
    • something invoked on an object which in turn is implemented by a method
  • Method (in coding not design method)
    • body of the procedure
  • polymorphism forces a distinction between the two (all siblings have the same operation but different methods)

© Wolfgang Pelz 2000-04

steps to create a class diagram
Steps to create a Class Diagram
  • Identify classes using the interaction diagram and place them in the class diagram
  • get attributes from the conceptual model and the method names from the interaction diagram
  • add type information and associations based on attribute visibility
  • add navigability arrows and dependencies

© Wolfgang Pelz 2000-04

another example41
Another Example

© Wolfgang Pelz 2000-04

cautions
Cautions
  • start small
  • perspective should match activity
    • analysis: conceptual model
    • software: specification model
  • don’t go to details too early

© Wolfgang Pelz 2000-04

dependency relationship
Dependency Relationship
  • One element (of any kind, including classes, use cases, etc.) has knowledge of another element
  • if one element changes, the other might have to change as well
  • differs from plain attribute visibility which uses regular association line and a navigability arrow

© Wolfgang Pelz 2000-04

slide44

Example revisited

© Wolfgang Pelz 2000-04

slide45

Example with Dependency

© Wolfgang Pelz 2000-04

slide46

Interface

  • Interface is a class of abstract/pure virtual functions.
  • All functions in the interface are public.
  • Interface cannot be used to instantiate objects.
  • There is no data members in an interface class.
  • UML: use <<interface>> to prefix the class name.

© Wolfgang Pelz 2000-04

slide47

Abstract Class

  • An abstract class has one or more abstract/pure virtual functions.
  • An abstract class cannot be used to instantiate objects.
  • An abstract class can contain data members.
  • UML: use Abstract to prefix the class name.

© Wolfgang Pelz 2000-04

slide48

ExamplesFigures in UML Distilled.

© Wolfgang Pelz 2000-04

slide49
Chapter 6

Object Diagrams

© Wolfgang Pelz 2000-04

object diagrams
Object Diagrams
  • A snapshot of the objects in a system at a point in time.
  • Also called instance diagrams.
  • Useful of showing object connections (not interactions)
  • Can be thought of as collaboration/communication diagram without messages.
  • Naming convention (did not change as sequence diagram did):

© Wolfgang Pelz 2000-04

object diagrams try this example
Object Diagrams (try this example)

class Pet { // define a class

protected: string name; // protected members can be accessed by child classes

public:

Pet() {name = "";} // default constructor

Pet(string nm){name = nm;} // constructor

string getName() {return name;} // to be inherited by child classes

//virtual method, to be overridden

virtual string speak() const { return “’I can't speak.’”; }

};

...

int main() {

vector<Pet *> pets;

pets.push_back(new Dog("Midnight"));

pets.push_back(new Cat("Ginger"));

pets.push_back(new Pet("Dummy"));

}

© Wolfgang Pelz 2000-04

chapter 9 use case diagram
Chapter 9Use Case Diagram

© Wolfgang Pelz 2000-04

use case diagram
Use Case Diagram
  • For capturing the functional requirements of a system.
  • Typical interaction between user and system
    • captures some user-visible function
    • achieves a discrete goal for the user

note the distinction between the user goal and system interaction in which system interaction is the low-level work that ultimately achieves the user goal

© Wolfgang Pelz 2000-04

notation55
Notation

© Wolfgang Pelz 2000-04

an example uml 1 3
An Example (UML 1.3)

© Wolfgang Pelz 2000-04

another example uml 1 1
Another Example (UML 1.1)

© Wolfgang Pelz 2000-04

common uses58
Common Uses
  • to model the context of a system
    • system, actors, and their interactions with it
  • to model the requirements of a system
    • what system should do
    • independent of how it is done
    • point of view outside of system

© Wolfgang Pelz 2000-04

caution
Caution
  • it is easy to get too low-level

A use case is a relatively large end-to-end process description that typically includes many steps or transactions; it is not normally an individual step or activity in a process.

    • Larman [1998] Applying UML and Patterns

© Wolfgang Pelz 2000-04

steps
Steps
  • capture normal case first
  • for every step, ask:

“What can go wrong”

“How might this work differently”

  • each variation is plotted as an extension
  • common behavior can be encapsulated in another use case to be used by other cases

© Wolfgang Pelz 2000-04

steps cont
Steps (cont.)
  • after creating the diagram, write a generic scenario (called a use case description) which is a series of sentences describing each step in the interaction
  • Each step in a use case is an element of the interaction between an actor and the system.
  • use case description can be used to generate specific scenarios and interaction diagrams

© Wolfgang Pelz 2000-04

scenario
Scenario
  • a thread through a use case
  • a sequence of steps describing an interaction between a user and a system.
  • A use case is a set of scenarios tied together by a common user goal.

© Wolfgang Pelz 2000-04

exercise
Exercise
  • Produce a use case diagram for an ATM

© Wolfgang Pelz 2000-04