60-322 Object-Oriented Analysis and Design

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

2. Operations and Methods • 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.

3. Operations and Methods • 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

4. Operations and Methods • 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.

5. Show Methods • 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»

6. Register «method» // pseudo - code or a specific language is OK ... public void enterItem ( id , qty ) endSale () { enterItem ( id , qty ) ProductDescription desc = catalog . getProductDescription ( id ) ; makeNewSale () sale . makeLineItem ( desc , qty ) ; makePayment ( cashTendered ) } Show Methods • 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.

7. Operation Issues- The Create Operation • 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++, …).

8. Operation Issues- Operations to Access Attributes • 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.

9. Keywords • 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>'.

10. Keywords • 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.

11. Keywords

12. UML Properties and Property String • 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}.

13. Generalization, Abstract Classes, Abstract Operations • 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.

14. Generalization, Abstract Classes, Abstract Operations • 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.

15. Dependency • 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.

16. Dependency • 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 :

17. Dependency • 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

18. Dependency • 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.

19. Dependency • 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:

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

21. Dependency

22. Dependency • 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

23. Dependency 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:

24. Clock B Window «call» A «create» getTime () ... ... a dependency that A objects create B objects a dependency on calling on operations of the operations of a Clock Dependency

25. Interface • 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

26. socket line notation Timer Window 1 uses the Timer dependency line notation Window 1 interface Window 2 has a dependency on the required interface it has a Timer interface when it collaborates with a Clock 2 object «interface» Clock 2 Timer ... Window 2 Timer getTime () getTime () ... Clock 1 implements and provides the Clock 3 Timer interface ... Timer Clock 1 Window 3 getTime () ... ... getTime () socket line notation ... lollipop notation indicates Clock 3 implements and provides the Timer interface to clients Window 3 has a dependency on the Timer interface when it collaborates provided interface Timer is a with a Clock 3 object Interface

27. Constraints • 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.

28. Qualified Association • 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,

29. Association Class • 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.

30. Singleton Class

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

32. the Relationship Between Interaction and Class Diagrams • 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.

33. the Relationship Between Interaction and Class Diagrams • 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.