slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
UML Artifacts (Part 2) PowerPoint Presentation
Download Presentation
UML Artifacts (Part 2)

Loading in 2 Seconds...

play fullscreen
1 / 35

UML Artifacts (Part 2) - PowerPoint PPT Presentation


  • 250 Views
  • Uploaded on

UML Artifacts (Part 2). Contents. Collaboration Diagrams State Transition Diagrams Visibility Review. Collaboration Diagrams. For each system operation identified in the Use Case Diagrams, and described in a contract Design a system of interacting objects to perform the operation.

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 Artifacts (Part 2)' - omer


Download Now 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
slide1

UML Artifacts (Part 2)

Contents

  • Collaboration Diagrams
  • State Transition Diagrams
  • Visibility
  • Review
slide2

Collaboration Diagrams

For each system operation

identified in the Use Case Diagrams, and

described in a contract

Design a system of interacting objects to perform the operation.

The collaboration diagram will indicate the objects participating in the collaboration, and

The sequence of messages {message(parameters), sender, receiver} exchanged to achieve the task involved.

slide3

Actor

System

System Op

SystemOp

:ClassA

Operation:xxx

Precondition:..

1: message1()

:ClassB

Use Case Diagram

Contract

Collaboration Diagram

Collaboration Diagrams

+

slide4

Alternatively (or perhaps primarily) Sequence Diagrams can be used instead of Collaboration Diagrams

slide5

Actor

System

:ClassA

:ClassB

System Op

SystemOp

message1()

Operation:xxx

Precondition:..

Use Case Diagram

Contract

Collaboration Diagram

Sequence Diagrams

+

slide6

John:Student

Student

:Student

Collaboration Diagrams

Notation

class

instance

named instance

The Collaboration diagram should consist of illustrations of the messages sent to objects of the classes identified in the creates/destroys, reads, changes sections of the contract. The system operation will be directed to one of the objects in this group that will act as the controller for executing this task.

slide7

sysOp()

optional

1: tot := total():integer

:Sale

:POST

Collaboration Diagrams

Illustrating links

UML standard syntax for messages

return := message(parameter : parameterType) : returnType

sender

receiver

slide8

SystemOp( )

CS335:ClassList

:Grader

Sequence number followed by a * indicates iteration

Iteration clause is optional

Collaboration Diagrams

Illustrating Iteration

1*: [i:=0..9] str : getName(): String

receiver

sender

slide9

1: message( )

:ClassA

Collaboration Diagrams

Illustrating Iteration

In the example described on the previous slide, we assumed that the target object contained a sequence of names (simple strings) as an attribute. More generally the ClassList may be considered a collection of StudentRec objects, and messages may be directed to the collection. The depiction of a message to a multiobject – a group of objects stored in a collection – is indicated on the next slide.

Representation of a collection (multiobject)

slide10

1: inx := find(name: String): integer

v: vector

1: inx := find(name: String): integer

:StudentRecord

Collaboration Diagrams

Given: A vector of StudentRecord

Version 1 – message to a collection (but vector is NOT a concept in the problem domain)

Version 2 – (preferred) Emphasizes the objects in the collection, not (the solution domain) container.

slide11

:ClassB

:ClassA

guard – if true send msg

:ClassD

:ClassC

Collaboration Diagrams

Conditional Paths – mutually exclusive messages

msg1( )

1a: [test] msg2( )

1b: [not test] msg4( )

1a.1: msg3( )

1b.1: msg5( )

slide12

New

m:MenuItem

1: create( )

c: Controller

2: add(m)

:MenuItem

Collaboration Diagrams

Creating a new instance during implementation of the system operation

Create a new MenuItem, m, and add it to the Menu

slide13

:ClassB

:ClassA

msg1( )

msg2( )

Focus of control is illustrated with an activation box

msg3( )

Sequence Diagrams

Sequence diagrams offer an alternate way of expressing the exchange of messages that occur between objects in an object-based system.

The notation for objects and collections is the same as used in collaboration diagrams. Time ordering is from top to bottom.

Each message between objects is represented with a message expression on an arrowed line between the objects

slide14

:ClassB

:ClassA

msg1( )

:ClassC

create( )

msg2( )

msg4( )

msg3( )

time

Sequence Diagrams

Additional Notation

Object creation -- let the classB object create an instance of a classC object.

Newly created class is placed in a column starting at the level (time) of creation.

slide15

:ClassC

:ClassB

:ClassA

msg1( )

[flag = true] msg2( )

[flag = false] msg3( )

Sequence Diagrams

Conditional message – has guard to specify the condition

Mutually exclusive conditional message

slide16

:ClassC

:ClassB

:ClassA

msg1( )

*[i = 1..N] msg2( )

msg3( )

msg4( )

*[k = 1..M]

msg5( )

Sequence Diagrams

Iteration for a single message

Iteration for a sequence of messages

Enclose the repeated sequence in a box, and indicate the multiplicity

slide17

Refining the Class Diagram

  • For every class, examine each collaboration diagram and identify
  • Every message received by an instance of that class – (these will be the methods for that class)
  • Each object (class) to which an instance of this class sends a message – (these may require reference attributes within the class, depending upon the visibility)
slide18

Classes to which messages are sent

Messages received

Refining the Class Diagram

Class name

Data attributes

Link attributes

methods

Class Description

slide19

State Transition Diagrams

State transition diagrams are a useful tool for constructing the individual classes. Specifically, they aid in two important ways in “fleshing out” the structure of the class:

  • method development -- State transition diagrams provide the “blueprints” for developing the algorithms that implement methods in the class
  • attribute identification – Attributes contain the state information needed for regulating the behaviors of the instances of the class

When constructing state transition diagrams, take care to ensure that the post-conditions stipulated in the contracts are enforced.

slide20

Transitions are labeled with the triggering event and the output if any

Some events do not trigger a change in state

State 2

State 1

States are represented with an oval and label

State transitions are represented with a directed arc or line

State Transition Diagrams

Notation

event|output

start

final state

slide21

event|output

State

State

Guard condition – transition occurs only if condition is true

State Transition Diagrams

Additional Notation

[boolean condition]

slide22

off hook|dial tone

[valid subscriber]

idle

talking

on hook

playing dial tone

do: hang up

answered

digit

complete|ringing

dialing

connecting

digit

State Transition Diagrams

Example – Nested States in Telephone Call

active

The state labeled active has substates

slide23

arrival

arrival

Size0

Size1

size2

departure

departure

arrival | balk

State Transition Diagrams

Second Example – A Queue of Capacity Two

The queue has three states that indicate its number of occupants. When the queue is full, new arrivals cannot enter, and must leave the system.

slide24

State

State transitions

Description of Class Queue

class Queue {

private:

int capacity, size;

public:

Queue(int cap);

void enqueue(Object obj);

//precondition: queue not full

//post condition: if (queue not full)

// size = size + 1

// else no change

Object dequeue();

//precondition: queue not empty

//post-condition: size = size-1

}

slide25

Visibility

For an object A to send a message to object B, B must be visible to A.

In determining the visibility of one object to another, we must decide during the design whether the link between objects A and B is:

permanent or transient

exclusive or shared

fixed or variable

slide26

Clock

Counter

*

modulus count

3

Visibility

Example 1. permanent, exclusive , and fixed

Consider a clock composed of three Counters (hours, mins, secs)

  • The Counters have the same lifetime as the Clock – They are created with the clock and dissolved when the clock is out of scope.
  • The Counters are bound exclusively to the Clock – They cannot be referenced by any other object in the system
slide27

Visibility

Implementation of the association between Clock and Counters

class Clock {

private:

Counter hours, mins, secs;

public:

Counter( ) : hours(24), mins(60), secs(60) {};

//other methods

}

C++ header file

slide28

Computer

ProductSpec

*

describes

Visibility

Example 2. permanent, shared, fixed

The ProductSpec exists before an instance of the product is created. That product (computer) will have a permanent association with its ProductSpec that it will share access to with other computers of the same model.

slide29

The reference variable ps must be initialized in an initialization list, and cannot be reassigned during the life of the object.

Visibility

(Partial) Specification of class Computer

class Computer {

private: ProductSpec & ps; public:

Computer (ProductSpec & theMod) : ps(theMod) {};

//other methods

}

slide30

permanent and exclusive; lifetime of the counter is bounded by the lifetime of the object itself.

Can be non-permanent, variable, and shared

Permanent and fixed, but not necessarily exclusive; lifetime of the ProductSpec will exceed that of object

Visibility

Attribute visibility -- an association that must be remembered is implemented as attribute visibility. We have just seen a couple of examples of attribute associativity. In C++ attribute associativity is provided via three forms of the declaration

Counter c;

Stack * s;

ProductSpec & ps;

slide31

Parameter visibility – object C is passed from A to B

:Sale

:POST

:ProductCatalog

Visibility

Transient visibility is not remembered, but persists only during the execution of a single method. It is implemented in one of two ways.

1: [new sale] create()

3: makeLineItem(spec, qty)

2: spec:= specification(upc)

A ProductSpec object is passed to the Sale object for use by its makeLineItem method

slide32

Visibility

Transient associations may also be implemented with locally declared visibility. Consider a method breadfirstSearch that uses an auxiliary Queue to perform a breadth first traversal of a binary tree. The lifetime of the Queue object will be within the scope of the method, and the reference need not exist outside of this method.

slide33

Review

In designing and constructing an object-oriented system one must:

  • From a statement of the requirements and from the use cases identify the objects (concepts) that occur in the “problem domain”
  • Construct a Concept Diagram showing the static relationship (long-term associations) between concepts
  • Identify the concepts that are outside of the system to be built (Actors) and use Sequence Diagrams to identify the events (system operations) that they generate
  • For each system operation construct a contract that stipulates the state of the system before and after the operation (pre- and post- conditions) and identifies the concepts that collaborate in performing the operation
  • Elaboration – Review your models for lack of clarity and inconsistency and add or modify as necessary.
slide34

Review (continued)

  • Enhance the Concept model by exploring the associations in greater detail (roles, aggregation, generalization, link attributes, etc) and iteratively add design concepts from the solution domain (programming concepts)
  • Construct Sequence Diagrams or Collaboration diagrams (for each system operation) to detail the sequence of messages that must be exchanged to implement the task
  • For each relevant object (or collection of aggregates) use a State Chart Diagram (state transition diagram) to detail the states of the system and the sequence of transitions that can occur during its operation
  • Continue elaboration of the models until the system is well understood and class specifications (In C++, header files) can be constructed.
  • Test design and specification for completeness and consistency, then develop test plans and begin (or continue) implementing the classes. (an on-going process during many phases of the project)
slide35

Postscript

I have been one acquainted with the night.

I have walked out in rain – and back in rain.

I have outwalked the furthest city light.

I have looked down the saddest city lane.

I have passed by the watchman on his beat

And dropped my eyes, unwilling to explain.

I have stood still and stopped the sound of feet

When far away an interrupted cry

Came over houses from another street,

But not to call me back or say good-bye;

And further still at an unearthly height,

One luminary clock against the sky

Proclaimed the time was neither wrong nor right.

I have been one acquainted with the night.

Robert Frost