Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "60-322 Object-Oriented Analysis and Design Feb 25, 2009."— Presentation transcript:

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

2 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

3 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

4 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.operation 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.operation contractsUML operations Operations and Methods

5 Feb 11, 2009 5 A UML method is the implementation of an operation; if constraints are defined, the method must satisfy them.method 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

6 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 OK public void enterItem(id,qty) { ProductDescription desc=catalog.getProductDescription(id); sale.makeLineItem(desc,qty); }

7 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

8 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

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

10 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

11 Feb 11, 2009 11 Keywords

12 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

13 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) Generalization What does it mean? Is this the same as OO programming language (OOPL) inheritance? It depends…inheritance 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

14 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

15 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

16 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. coupling There are many kinds of dependency; here are some common types in terms of objects and class diagrams : Dependency

17 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

18 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

19 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

20 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

21 Feb 11, 2009 21 Dependency

22 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

23 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

24 Feb 11, 2009 24 Dependency «call» Window a dependency on calling on operations of the operations of aClock getTime()... «create» A a dependency that A objects create B objects B...

25 Feb 11, 2009 25 The UML provides several ways to show – interface implementation, interface – providing an interface to clients, and – interface dependency (a required interface). In the UML, interface implementation is formally called interface realization Interface

26 Feb 11, 2009 26 Interface

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

28 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.qualified association 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

29 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

30 Feb 11, 2009 30 Singleton Class

31 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

32 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

33 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


Download ppt "60-322 Object-Oriented Analysis and Design Feb 25, 2009."

Similar presentations


Ads by Google