Uml unified modeling language
Download
1 / 63

UML1 - PowerPoint PPT Presentation


  • 319 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 'UML1' - 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 l.jpg

UML Unified Modeling Language

© Wolfgang Pelz 2000-04


Chapter one introduction l.jpg

Chapter OneIntroduction

© Wolfgang Pelz 2000-04


Slide3 l.jpg

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 l.jpg
Engineering and Blueprints

  • standard notation

  • communication tool

© Wolfgang Pelz 2000-04


History l.jpg
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 l.jpg
History

  • Booch: Booch Method

  • Rumbaugh: OMT (object modeling tech.)

  • Jacobson: OOSE (OO software engrg.)

  • Three amigos: UML

© Wolfgang Pelz 2000-04


History7 l.jpg
History

  • UML: an open standard controlled by OMG

  • UML 1.0 (1997)

  • UML 2.0 (2004)

© Wolfgang Pelz 2000-04


Meta model l.jpg
Meta-Model

  • a diagram that defines the notation to be used in the modeling language

© Wolfgang Pelz 2000-04


Uml supported diagrams l.jpg

class

object

component

package

deployment

use case

interaction

communication

sequence

collaboration

timing

activity

state/statechart

UML supported diagrams

© Wolfgang Pelz 2000-04


Brief overview l.jpg
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 l.jpg
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 l.jpg
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 l.jpg

domain expert

use case

activity

interaction

system designer

class

component

deployment

state

package

Organization of Diagrams

© Wolfgang Pelz 2000-04


Another organization l.jpg

static

class

component

package

deployment

dynamic

use case

interaction

state

activity

Another Organization

© Wolfgang Pelz 2000-04


Another organization15 l.jpg
Another Organization

© Wolfgang Pelz 2000-04


Model terminology l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Chapter ThreeClass Diagram

© Wolfgang Pelz 2000-04


Class diagram l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Notation

© Wolfgang Pelz 2000-04


More notation l.jpg
More Notation

© Wolfgang Pelz 2000-04


Aggregation composition l.jpg
Aggregation/Composition

© Wolfgang Pelz 2000-04


Example l.jpg
Example

© Wolfgang Pelz 2000-04


Levels of abstraction l.jpg
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 l.jpg
Another Example

© Wolfgang Pelz 2000-04


Associations l.jpg
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 l.jpg
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 l.jpg
Operation Signatures

visibilityname(parameters) : return type

optional optional

+ public

# protected

- private

  • Example:

    + getData (pos : Position) : Data

© Wolfgang Pelz 2000-04


Operations methods l.jpg
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 l.jpg
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 l.jpg
Another Example

© Wolfgang Pelz 2000-04


Cautions l.jpg
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 l.jpg
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 l.jpg

Example revisited

© Wolfgang Pelz 2000-04


Slide45 l.jpg

Example with Dependency

© Wolfgang Pelz 2000-04


Slide46 l.jpg

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

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

ExamplesFigures in UML Distilled.

© Wolfgang Pelz 2000-04


Slide49 l.jpg

Chapter 6

Object Diagrams

© Wolfgang Pelz 2000-04


Object diagrams l.jpg
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 l.jpg
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 l.jpg
Chapter 9Use Case Diagram

© Wolfgang Pelz 2000-04


Use case diagram l.jpg
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 l.jpg
Notation

© Wolfgang Pelz 2000-04


An example uml 1 3 l.jpg
An Example (UML 1.3)

© Wolfgang Pelz 2000-04


Another example uml 1 1 l.jpg
Another Example (UML 1.1)

© Wolfgang Pelz 2000-04


Common uses58 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Exercise

  • Produce a use case diagram for an ATM

© Wolfgang Pelz 2000-04


ad