Modeling with Objects

1. Modeling with Objects Spring 2001

2. The Object Model • The object model is a common computational model shared by both OO programs and design languages. It characterizes object oriented systems as: • dynamic networks of intercommunicating objects • Objects : Manage part of the system’s data and functionality. • Network : The objects are linked together. • Dynamic : The topology of the network of objects changes as the system evolves. • Intercommunicating : Objects communicate and “work together” to achieve system-wide functionality.

3. Role of the Object Model • The Object Model • gives an abstract view of the run-time properties of object-oriented programs. • is used to explain the meaning of UML’s design notations. It therefore serves as the ‘common ground’ between design and programming languages, and explains the suitability of UML as a language for designing object-oriented programs. The object model is not a specific model within UML. It is a general framework of concepts that are used to explain what ‘object-orientation’ amounts to.

4. A Simple Application • Keeps track of parts in a manufacturing environment and how they are use in constructing assemblies. We’ll use the following terminology: Parts : Individual, physical objects. Assemblies : Complex structures made up out of parts, and possibly structured into subassemblies.

5. A Simple Application (cont’d) • The program could: • maintain catalogue information: what kinds of parts are there? • maintain inventory information: how many are in stock? • record structure of manufactured assemblies. • provide operations on assemblies: – calculating the total cost of parts in an assembly; – print a listing of all the parts in an assembly.

6. Objects • Objects contain part of the system’s data. A major task of object-oriented design is: to decide how system’s data should be split up between different objects. • A frequently applied rule of thumb for the identification of objects is to represent real-world objects from the application domain by the objects in the model

7. Objects (cont’d) • Rule of thumb Consider application domain concepts, such as part, as candidate objects. What data do we need to store about parts? • An identification number • A description • Their price • . . . * Rule of thumb : A method or procedure derived entirely from practice or experience, without any basis in scientific knowledge; a roughly practical method.

8. Objects (cont’d) • As a first step in the design of the stock management system, we are proposing that a ‘part’ class is defined • consider what data should be held by instances of that class • name • number • cost

9. A part class • public class Part { public Part(String nm, long num, double cst) { name = nm; number = num; cost = cst; } public String getName() { return name; } public long getNumber() { return number; } public double getCost() { return cost; } private String name; private long number; private double cost; }

10. Object Creation • In programming languages, classes are defined at the compile-time. Objects are created at run-time, as instances of a class. • New object creation in Java : part myScrew = new Part (“screw”, 28834, 0.02);

11. Object Notation • UML provides the following notation to show individual objects: • rectangular icon • object name and class name (underlined) in upper Compartment • attribute names and values in lower compartment

12. Object Notation (cont’d) • The following elements of this notation are optional: • object and class name (but one must be present) • the attribute compartment • attributes which are not of interest • Conventions • Class names start with upper-case letters • Object names start with lower-case letters

13. Problems If we have 100,000 screws, this design would represent them by 100,000 screw objects, each storing the ID number of the part, its description and its price. There are at least two major problems with this approach: Redundancy : Storing the same data 100,000 times will waste significant amounts of storage. Maintainability : If for example the price of a screw changed, there would be 100,000 updates to perform in order to update the system. As well as being time-consuming, this will make it very hard to ensure that the system’s data is accurate and consistent.

14. Solution Move the shared information out of the part objects into a new object that describes a particular kind of part. These ‘descriptor’ objects do not represent individual parts. Rather, they represent the information associated with a catalogue entry that describes a type of part.

15. Properties of Objects The following terminology is often used in talking about objects: • State : The aggregate of the data values in the object. Shown in the lower part of the object icon. • Behaviour : The operations that the object can perform. Not shown on the object icon. • Identity : A property of the object model. Objects are distinct, even if they have identical state. • Encapsulation : Object state is only accessible through its operations.

16. Links In the object model, objects can be linked together to show some sort of relationship between them. In this case, the relationship is that the catalogue entry describes the part. A relationship between objects is in UML known as a link - Labels are often verbs Object diagram

17. Links (cont’d) • Object Diagrams Show objects and their relationships at a given point in time. • Links store data Links store data “structurally”. The fact that a part is of a particular type is represented by the link between the two objects, not by a data item in the part object.

18. Implementation of Links • Most programming languages do not define a way of directly implementing of links. The simplest approach is usually to represent the link inside the linked objects by providing some way in which an object can know which other objects it is linked to. • Allowing each part to maintain a reference to the catalogue entry that describes it. • The implementation in next slide states that when a part is created, a reference to the appropriate catalogue entry object must be provided.

19. Implementation of Links (cont’d) public class CatalogueEntry { public CatalogueEntry(String nm, long num, double cst) { name = nm; number = num; cost = cst; } public String getName() { return name; } public long getNumber() { return number; } public double getCost() { return cost; } private String name; private long number; private double cost; public class Part { public Part(CatalogueEntry e) { entry = e; } private CatalogueEntry entry; } }

20. Implementation of Links (cont’d) • Showing how to create two objects, a catalogue entry and a corresponding part. • The constructor of the part class ensures that the part object is linked to the catalogue entry object after it is created. CatalogueEntry screw = new CatalogueEntry (“screw”, 28834, 0.02) ; Part screw1 = new Part (screw) ;

21. Navigability This implementation means that a part can access its catalogue entry, but not vice versa. In other words, the link can only be ‘navigated’ in one direction. This can be shown on an object diagram as follows: The name of the data member implementing the link can be shown as a rolename at the end of the link. This shows the connection between the link and its implementation.

22. Messages So data in an object-oriented system is distributed across a network of linked objects. • Some data is held explicitly, as attributes in objects. • Some data is held implicitly, represented by links between objects. How is the data accessed? There is a single basic operation: Send a message to an object For example, to find out the cost of a part, you would send a message to the object representing the part asking for its cost.

23. Notation for messages • Messages can be shown on object diagrams attached to links: Here a client object is sending a message to a Part object, asking for its cost. (Notice that the class of the client is not specified. In general, the same message can be sent by objects of many different classes, and the class of the sender is not important.) • Messages have a name, such as “cost”, and are written in a familiar “function call” notation. • Return values can be shown using the := assignment symbol.

24. Notation for messages (cont’d) • Links as communication channels If two objects are connected by a link then they can send messages to each other, navigability permitting.

25. Sharing responsibility Data is distributed across the network of objects. An object will often get a message asking it to do something, but it doesn’t itself hold all the data necessary to generate a response. For example, how does the part object know its cost? The data is stored in the linked catalogue entry object: it must be retrieved from there by sending a further message.

26. Sharing responsibility (cont’d) An object diagram which includes messages is called a collaboration diagram or an interaction in UML.

27. Implementation of message passing The messages shown above behave in the same way as normal function calls. They correspond to methods in the class receiving the message. Sending a message corresponds to calling such a method. When a part object receives a cost message, it sends a further message to its linked catalogue entry object. This could be implemented like this: public class CatalogueEntry { public double getCost() { return cost; } private double cost; } public class Part { public double cost() { return entry.getCost(); } private CataloueEntry entry; }

28. Assemblies • An assembly is a grouping of individual parts that together make up a structure.

29. Assemblies (cont’d) • All the information about the parts in the assembly is held implicitly, represented by the links connecting part objects to the assembly. • An implementation of the assembly class must contain: 1. a data structure to store references to linked objects 2. “housekeeping” operations to add, test and remove links from this collection

30. Polyporphism • Assemblies can also contain subassemblies, thus forming a hierarchy of subassemblies and parts.

31. Polyporphism (cont’d) This is an example of polymorphism. In order for this to work we must define a new class, which will be called “Component”, which is a generalization or superclass of “Part” and “Assembly”. We can then think of an assembly as containing a number of components, each of which could either be a part or a further assembly.

32. Implementation of polymorphism • In order to achieve polymorphism is object-oriented languages the mechanism of inheritance is used. A components class can be defined, and the part and assembly classes defined to be subclasss of this class : public abstract class Component{ } public class Part extends Component {} public class Assembly extends Component { private Vector components = new Vector(); public void add(Component c) { components.addElement(c); } }

33. Abstract Class No objects of the component class are ever created. It exists only to describe the common features of parts and assemblies, namely • that they can both be stored in assemblies, and • that we can find out the cost of both. Such a class is called an abstract class.

34. Dynamic binding • The same message may give rise to different processing, depending on which object it is sent to.

35. Dynamic binding (cont’d) • When a part object is asked for its cost, it retrieves it from the associated catalogue entry object by sending a single getCost message and returning the result. • When an assembly object is asked for its cost, it sends a cost message to all of its components, adds up the values returned, and then returns the total.

36. Implementation of Late Binding • Programming languages allow superclass to define operations which are implemented in different ways in different subclasses. public class Assembly extends Component { private Vector components = new Vector(); public double cost() { double total = 0.0; Enumeration enum = components.elements(); while(enum.hasMoreElements()) { total += ((component) enum.nextElement()).cost(); } return total; } } public abstract class Component { public abstract double cost(); } public class Part extends Component { public double cost() { return entry.getCost(); } }

37. Implementation of Late Binding (cont’d) The class of the object receiving the message is checked at run-time and the appropriate method called.

38. Class diagram • We’ve seen • UML object and collaboration diagrams showing runtime properties of the system • source code showing compile-time definitions of therelevant classes and objects UML also provides notation for showing the compile-time design:

39. Class diagram (cont’d) • Shows classes that we’ve identified, and their attributes • Shows how instances of those classes can be linked at run-time • Shows subclass relationship

40. Class diagram