60-322 object-oriented analysis and design feb 25, 2009

33
60-322 Object-Oriented Analysis and Design Feb 25, 2009

Upload: rosa-cole

Post on 03-Jan-2016

222 views

Category:

Documents


7 download

TRANSCRIPT

Page 1: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

60-322 Object-Oriented Analysis and Design

Feb 25, 2009

Page 2: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 2

One of the compartments of the UML class box shows the signatures of operations.

The preferred format of the operation syntax is:visibility name (parameter-list) : return-type {property-string}

Guideline: Operations are usually assumed public if no visibility is shown.

The property string contains arbitrary additional information, such as exceptions that may be raised, if the operation is abstract, and so forth.

Operations and Methods

Page 3: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 3

In addition to the official UML operation syntax, the UML allows the operation signature to be written in any programming language, such as Java, assuming the reader or tool is notified.

For example, both expressions are possible:

+ getPlayer( name : String ) : Player {exception IOException}

public Player getPlayer( String name ) throws IOException

Operations and Methods

Page 4: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 4

An operation is not a method. A UML operation is a declaration, with a name, parameters, return type, exceptions list, and possibly a set of constraints of pre-and post-conditions.

But, it isn't an implementation - rather, methods are implementations.

When we explored operation contracts , in UML terms we were exploring the definition of constraints for UML operations.

Operations and Methods

Page 5: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 5

A UML method is the implementation of an operation; if constraints are defined, the method must satisfy them.

A method may be illustrated several ways, including:– in interaction diagrams, by the details and sequence of

messages– in class diagrams, with a UML note symbol stereotyped

with «method»

Show Methods

Page 6: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 6

When we use a UML note to show a method, we are mixing static and dynamic views in the same diagram.

The method body (which defines dynamic behavior) adds a dynamic element to the static class diagram.

This style is good for book or document diagrams and tool-generated output, but perhaps too fussy or stylized for sketching or tool input.

Tools may provide a popup window to simply enter the code for a method.

Show Methods

Register

...

endSale()enterItem(id, qty)makeNewSale()makePayment( cashTendered)

«method»// pseudo- code or a specific language is OKpublic void enterItem( id, qty )

{ ProductDescription desc = catalog. getProductDescription(id);

sale. makeLineItem(desc, qty);}

Page 7: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 7

The create message in an interaction diagram is normally interpreted as the invocation of the new operator and a constructor call in languages such as Java and C#.

In a DCD this create message will usually be mapped to a constructor definition, using the rules of the language - such as the constructor name equal to the class name (Java, C#, C++, …).

Operation Issues- The Create Operation

Page 8: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 8

Accessing operations retrieve or set attributes, such as getPrice and setPrice.

These operations are often excluded (or filtered) from the class diagram because of the high noise-to-value ratio they generate;

for n attributes, there may be 2n uninteresting getter and setter operations. Most UML tools support filtering their display, and it's especially common to ignore them while wall sketching.

Operation Issues- Operations to Access Attributes

Page 9: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 9

A UML keyword is a textual adornment to categorize a model element.– For example, the keyword to categorize that a classifier

box is an interface is «interface».– The «actor» keyword was used in use case diagram to

replace the human stick-figure actor icon with a class box to model computer-system or robotic actors.

Guideline: When sketching UML-when we want speed, ease, and creative flow-modelers often simplify keywords to something like '<interface>' or '<I>'.

Keywords

Page 10: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 10

Most keywords are shown in guillemet (« ») but some are shown in curly braces, such as {abstract}, which is a constraint containing the abstract keyword.

In general, when a UML element says it can have a "property string“ - such as a UML operation and UML association end have-some of the property string terms will be keywords (and some may be user defined terms) used in the curly brace format.

Keywords

Page 11: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 11

Keywords

Page 12: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 12

In the UML, a property is "a named value denoting a characteristic of an element.

Some properties are predefined in the UML, such as visibility - a property of an operation. Others can be user-defined.

Properties of elements may be presented in many ways, but a textual approach is to use the UML property string

– {name1=value1, name2=value2} format, such as {abstract, visibility=public}.

– Some properties are shown without a value, such as {abstract}; this usually implies a boolean property, shorthand for {abstract=true}.

UML Properties and Property String

Page 13: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 13

Generalization in the UML is shown with a solid line and fat triangular arrow from the subclass to superclass. (See Figure 16.1)

What does it mean? Is this the same as OO programming language (OOPL) inheritance? It depends…

In a domain model conceptual-perspective class diagram, the answer is no. Rather, it implies the superclass is a superset and the subclass is a subset.

Generalization, Abstract Classes, Abstract Operations

Page 14: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 14

On the other hand, in a DCD software-perspective class diagram, it implies OOPL inheritance from the superclass to subclass.

Abstract classes and operations can be shown either with an {abstract} tag (useful when sketching UML) or by italicizing the name (easy to support in a UML tool).

The opposite case, final classes and operations that can't be overridden in subclasses, are shown with the {leaf} tag.

Generalization, Abstract Classes, Abstract Operations

Page 15: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 15

Dependency lines may be used on any diagram, but are especially common on class and package diagrams.

The UML includes a general dependency relationship that indicates that a client element (of any kind, including classes, packages, use cases, and so on) has knowledge of another supplier element and that a change in the supplier could affect the client.

Dependency

Page 16: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 16

Dependency is illustrated with a dashed arrow line from the client to supplier.

Dependency can be viewed as another version of coupling, a traditional term in software development when an element is coupled to or depends on another.

There are many kinds of dependency; here are some common types in terms of objects and class diagrams :

Dependency

Page 17: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 17

– having an attribute of the supplier type

– sending a message to a supplier; the visibility to the supplier could be:

an attribute, a parameter variable, a local variable, a global variable, or class visibility (invoking static or class methods)

– receiving a parameter of the supplier type

– the supplier is a superclass or interface

Dependency

Page 18: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 18

All of these could be shown with a dependency line in the UML, but some of these types already have special lines that suggest the dependency. – For example, there's a special UML line to show the

super class, one to show implementation of an interface, and one for attributes (the attribute-as-association line).

So, for those cases, it is not useful to use the dependency line.

– For example, a Sale has some kind of dependency on SalesLineItems by virtue of the association line. Since there's already an association line between these two elements, adding a second dashed arrow dependency line is redundant.

Dependency

Page 19: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 19

when to show a dependency? Guideline: In class diagrams use the dependency

line to depict global, parameter variable, local variable, and static-method (when a call is made to a static method of another class) dependency between objects.

For example, the following Java code shows an updatePriceFor method in the Sale class:

Dependency

Page 20: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 20

public class Sale {public void updatePriceFor( ProductDescription description )

{

Money basePrice = description.getPrice();

//…

} // …

} The updatePriceFor method receives a ProductDescription parameter object and then sends it a getPrice message. Therefore, the Sale object has parameter visibility to the ProductDescription, and message-sending coupling, and thus a dependency on the ProductDescription. If the latter class changed, the Sale class could be affected. This dependency can be shown in a class diagram

Dependency

Page 21: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 21

Dependency

SalesLineItem

...

...

ProductDescription

...

...

1..*lineItems

Sale

...

updatePriceFor( ProductDescription )...

the Sale has parameter visibility to a ProductDescription, and thus some kind of dependency

Page 22: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 22

Another example: The following Java code shows a doX method in the Foo class:

public class Foo {

public void doX() {

System.runFinalization();

//…

}

// …

} The doX method invokes a static method on the System class. Therefore, the Foo object has a static-method dependency on the System class. This dependency can be shown in a class diagram

Dependency

Page 23: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 23

To show the type of dependency, or to help a tool with code generation, the dependency line can be labeled with keywords or stereotypes, for example:

Dependency

System

...

runFinalization()...

Foo

...

doX()...

the doX method invokes the runFinalization static method, and thus has a dependency on the System class

Page 24: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 24

Dependency

«call»Window

a dependency on calling on operations of the operations of a Clock

Clock

getTime()...

«create»A

a dependency that A objects create B objects

B

...

Page 25: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 25

The UML provides several ways to show – interface implementation, – providing an interface to clients, and – interface dependency (a required interface).

In the UML, interface implementation is formally called interface realization

Interface

Page 26: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 26

Interface

«interface»Timer

getTime()

Clock1

...

getTime()... lollipop notation indicates Clock3 implements

and provides the Timer interface to clients

Timer is a provided interface

Timer

Clock3

...

getTime()...

Window2

Window3

dependency line notation

Window2 has a dependency on the Timer interface when it collaborates with a Clock2 object

socket line notation

Window3 has a dependency on the Timer interface when it collaborates with a Clock3 object

Window1 Timer

socket line notation

Window1 uses the Timer interface

it has a required interface

Clock2

...

getTime()...

Clock1 implements and provides the Timer interface

Timer

Page 27: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 27

Constraints may be used on most UML diagrams, but are especially common on class diagrams.

A UML constraint is a restriction or condition on a UML element. It is visualized in text between braces; for example: { size >= 0 }. The text may be natural language or anything else.

Constraints

Stack

size : Integer { size >= 0 }

push( element )pop() : Object

three ways to show UML constraints

{ post condition: new size = old size + 1 }

{ post condition: new size = old size – 1 }

Page 28: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 28

A qualified association has a qualifier that is used to select an object (or objects) from a larger set of related objects, based upon the qualifier key.

Informally, in a software perspective, it suggests looking things up by a key, such as objects in a HashMap. For example, if a ProductCatalog contains many ProductDescriptions, and each one can be selected by an itemID,

Qualified Association

ProductCatalog

ProductDescription

itemID Contains

ProductCatalog

ProductDescription

Contains

1..*

multiplicity reduced to 1

(a)

(b)

qualifier

1

11

Page 29: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 29

An association class allows you treat an association itself as a class, and model it with attributes, operations, and other features.

For example, if a Company employs many Persons, modeled with an Employs association, you can model the association itself as the Employment class, with attributes such as startDate.

In the UML, it is illustrated with a dashed line from the association to the association class.

Association Class

salarystartDate

Employment

EmploysCompany Person**

a person may have employment with several companies

Page 30: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 30

Singleton Class

1ServicesFactory

instance : ServicesFactory

accountingAdapter : IAccountingAdapterinventoryAdapter : IInventoryAdaptertaxCalculatorAdapter : ITaxCalculatorAdapter

getInstance() : ServicesFactory

getAccountingAdapter() : IAccountingAdaptergetInventoryAdapter() : IInventoryAdaptergetTaxCalculatorAdapter() : ITaxCalculatorAdapter...

UML notation: in a class box, an underlined attribute or method indicates a static (class level) member, rather than an instance member

UML notation: this '1' can optionally be used to indicate that only one instance will be created (a singleton)

Page 31: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 31

In addition to common predefined compartments class compartments such as name, attributes, and operations, user-defined compartments can be added to a class box.

User-Defined Compartments

DataAccessObject

id : Int...

doX()...

exceptions thrownDatabaseExceptionIOException

responsibilitiesserialize and write objectsread and deserialize objects...

Page 32: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 32

When we draw interaction diagrams, a set of classes and their methods emerge from the creative design process of dynamic object modeling.

– For example, if we started with the (trivial for explanation) makePayment sequence diagram, we see that a Register and Sale class definition in a class diagram can be obviously derived.

the Relationship Between Interaction and Class Diagrams

Page 33: 60-322 Object-Oriented Analysis and Design Feb 25, 2009

Feb 11, 2009 33

Thus, from interaction diagrams the definitions of class diagrams can be generated.

This suggests a linear ordering of drawing interaction diagrams before class diagrams,

but in practice, especially when following the agile modeling practice of models in parallel, these complementary dynamic and static views are drawn concurrently.

the Relationship Between Interaction and Class Diagrams