1. Object Oriented Modelling Class & Object Models

2. Analysis V. Design There is no significant distinction between the techniques used during Analysis and those used during Design. The techniques are equally valid during both stages. The principle difference is the level of objects you model with. The term “Object Modelling” is sometimes used instead of “Object Analysis” and Object Design”.

3. Analysis (logical model) Object-Oriented Analysis (OOA) aims to model the problem domain, the problem we want to solve by developing an OO system. Analysis level objects –Customers, accounts, suppliers, accidents, invoices –Protocols, motors, sensors, engines, traffic

4. Design (Physical Model) Object-Oriented Design (OOD) is an activity where we are looking for logical solutions to solve a problem. Design level objects –User interface (dialogue and presentation objects) –Objects to manage relationships, concurrency, –referential integrity, transactions, etc...

5. Unified Modelling Language (UML) UML is a non-proprietary specification language for object modeling. UML is a general-purpose modeling language that includes a standardized graphical notation used to create an abstract model of a system, referred to as a UML model. UML is not a method by itself; however, it was designed to be compatible with the leading object-oriented software development methods of its time. –Most well known method using UML is Rational Unified Process (RUP).

6. UML Model Types Static/Structural behaviour –Functional Model Showcases the functionality of the system from the user's Point of View. Includes Use case diagrams. –Object Model Showcases the structure and substructure of the system using objects, attributes, operations, and associations. Includes Class Diagrams. Dynamic Behaviour –Dynamic Model Showcases the internal behavior of the system. Includes Sequence Diagrams, Activity Diagrams and State Machine Diagrams. There are three prominent parts of a system's model covering two aspects of system behaviour:

7. UML Views Use-Case View: User perception of functionality in domain or system. Logical View: Internal representation showing both static structure and time- dependent dynamic behaviour. Component View: Showing how a complete system is composed of discrete units. Concurrency View: Division of system into separate execution threads - shows communication. Deployment View: Represents physical deployment of the various parts (components) of the overall system. Views provide high level representations of a domain or system. There are several:

8. UML Models Structure Diagrams emphasize what things must be in the system being modeled: –Class diagram –Component diagram –Composite structure diagram –Deployment diagram –Object diagram –Package diagram Behavior Diagrams emphasize what must happen in the system being modeled: –Activity diagram –State Machine diagram –Use case diagram Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled: –Collaboration / Communication diagram –Interaction overview diagram –Sequence diagram –UML Timing Diagram

9. Class Diagram A class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. (wikipedia)

10. Class Diagram A class is represented by a box –the name of the class in box. –a compartment below the class name can show the class's attributes (i.e. its properties). Data Behaviour (methods).

11. Classes and Objects Classname Class Name Data Attributes Methods/ functions/ behaviour OR Objectname: Classname Objectname: Classname Data Attributes Methods/ functions/ behaviour OR A class is a specification that an object implements

12. Identifying Classes A useful link: http://www.agilemodeling.com/artifacts/classDiagram.htm

13. Identifying Classes Natural language - Origins from Abbott 1983 CRC Cards - Beck 1989 - Wirfs-Brock 1990

14. Natural Language Nouns may indicate candidate classes –Some nouns are actually sub-assemblies or aggregates of classes. –Some nouns suggest merely attributes of a class When sufficient significance can be assigned to an attribute it may be promoted to a full class. Verb phrases suggest class associations or operations –Often operations are tied to relationships Adjectives suggest attributes of a class Proper nouns suggest objects of a class type –Try not to have too many classes for which there is only ever one instance created. Original concept from Abbott 1983

15. Critique of Natural Language Analysis Needs a full and accurate statement of the requirements –Often the lack of clearly defined requirements is the reason why an OO approach may be being used. Nouns and Verbs tend only to help identify tangible things. –Much of design requires thinking about less tangible concepts - abstractions –Therefore natural language may contribute little to the design process. –Nevertheless, useful starting point for some analysis work. see Goldberg and Rubin 1995

16. Natural Language - Example A manager is responsible for a department and must review the staff in that department each year. The manager is also responsible for ordering new equipment (such as PCs) and furniture (such as desks and chairs) as required. From time to time John (one of the managers) must also recruit additional staff. This involves placing advertisements and keeping track of all applicants up to the closing date. A short-list of suitable candidates for interview is then composed.

17. Natural Language Example Examine the Model and think about what each of the Symbols mean

18. CRC Cards Brainstorming tool used to design OO software. Used when first determining required classes and how they interact. CRC cards are usually created from index cards on which are written: –The class name. –The responsibilities of the class. –The names of other classes that the class will collaborate with to fulfill its responsibilities.

19. CRC Cards Class Name: MANAGER Responsibilities Collaborators Beck & Cunningham 1989 Departmental reviews Staff salary reviews Ordering Equipment Staff recruitment Department Employee Applicant Class, Responsibility and Collaboration

20. CRC Cards l Write Class name on a 4” x 6” index card l Write Responsibilities on card uResponsibilities identify the problems which the class must solve. uGroup responsibilities into contracts. l Identify Collaborator classes on the card uCollaborator classes are classes which send messages to, or receive messages from, the class in question. uDIscard classes without collaborations. Beck & Cunningham 1989

21. Class Description l End up with a class description, either in textual prose or some more structured form. For example using a company Manager: Manager - A company employee and departmental controller. A manager is responsible for one or more employees. A manager can: Review staff salaries, order equipment and recruit staff. These activities may all be part of periodic departmental reviews.

22. Structured Description Class name: MANAGER Description: Details of a company MANAGER - a person Superclass: PERSON Name: Grade Description: Details of salary grading Type: Integer (range 1-5) Cardinality: One Name: Manages Description: Details of employees managed Type: Employee Cardinality: Many

23. Structured Description Public methods: Name: Review Department Parameters: New Budget Description: Used to carry out periodic reviews. Private methods: Name: Recruit Staff Parameters: Number of staff, type of staff Description: Initiated by a Manager as a consequence of various factors and as a result of a request to Review Department.

24. Object Relationships Most OOA&D methods (including UML) model 3 basic kinds of relationship: l Association l Aggregation (part_of) l Inheritance (is_a)

25. Object and Class Associations Links and Associations uLink - A physical or conceptual connection between two objects (instances) uAssociation - A group of links with a common structure. Associations occur between classes of objects. Links represent object interactions (dynamic considerations) while associations depict static, structural issues.

26. Links and Associations Lecturer Course takes An Association George: Lecturer takes M.Sc: Course A Link Class diagram Object diagram lecture examine

27. Participation or Cardinality While participation is shown on class diagrams it relates to the number of instances of one class that are associated with an instance of the other class. Class 1 Class 2 association name Class Exactly one Many (zero or more) Optional (zero or one) One or more Numerically specified 1..* 2 0..1 0..* 1 role

28. Example 1 Lecturer Course Takes Joe Bloggs: Lecturer B.Sc: Course M.Sc: Course lecture examine 0..* 1..* Is taken by

29. Association Constraints You can document any constraints on the association. For example, a person may only drive a car if they have a valid licence: Person Car drives 0..* {person.licence_status = valid)

30. Handling Link Attributes via an Association Class A class may be attached to an association rather than directly to another class. Such a class is called an Association Class. It can have data attributes and behaviour just like any other class Used to hold information on each occurrence of a relationship Supplier Part Supplies Date Contract

31. Instances of the Association Class B&Q Texas Budget aHammer aSaw 21/12/92 14/2/93 27/4/91 12/5/93 5/9/93

32. Associations There can be more than one association between the same two classes –Person hires car –Person owns car –Person drives car Suggests 3 distinct relationships between a Person and a Car –May have different cardinalities Person hires many Cars A Car may be hired by many Persons (Over Time)

33. Example 2 Person Car hires owns 10..*

34. Time Dimension Time presents an interesting dimension when applied to associations. It often transforms a one:one into a one:many or a many:many. –For example, a Car can only be hired by one person at a time (Rule). But it may be hired by many people over a period of time. –The Rules must be identified by the analyst, so the designer can create the appropriate association participation.

35. Time Dimension If an Information System is required to track only details of who currently has a vehicle on hire, then the Car can be modelled in a One:One association with a Person. However, if the system must provide a historical log of all customers who hired a particular Car then a Many:Many association will be required.

36. Time Dimension A Person may Drive a Car for much shorter periods of time. Is a record of all driving periods required? –Perhaps for a haulage firm with a legal requirement to maintain a driving log for each Driver. –In another situation it may only be necessary to record information about who is currently driving a particular Car.

37. Aggregation Aggregation is the “part-whole” relationship. It relates classes, representing parts (or components) to the whole (or assembly) class.

38. Aggregation A tightly coupled form of association with some extra semantics, namely transitivity (if A is a part of B and B is a part of C then A is a part of C). Properties of the assembly may propagate to the components. For example, the speed and location of a door is obtained from a fuselage which in turn obtains them from a Plane. Rumbaugh 1991

39. UML Aggregation In UML there are three types of aggregation: –Normal Aggregation –Shared Aggregation –Composition aggregation

40. Aggregation l Aggregation is most useful when there are common properties of components that can be attached to the assembly as a whole l Or where operations can propagate from container to contained objects l Parts explosions are the most compelling examples of aggregation l Keywords to identify aggregates are: “consists of”, “contains”, or “is part of”. l Represented by as line with a hollow diamond attached to the ‘wholeside’ end of the line. l If in doubt, use ordinary association!

41. Aggregation Navy Warship Contains 0..*

42. Normal Aggregation - Discussion University Faculty School Lecturer works for Class diagram Course takes * * 11..*

43. Composition Aggregation The ‘whole’ owns the instances of the parts. Those instances cannot belong to any other instance of the whole. Composition Aggregation forms a tree structure. The lifetime of the whole dictates the lifetime of the constituent parts.

44. Composition Aggregation Example Aircraft EngineWing Fuselage Door Landing Gear 2+ 2 1+

45. Alternative Notation Aircraft Engine Wing Fuselage 1+ 2 Door 2+ Landing Gear

46. Shared Aggregation in UML With ‘Shared Aggregation’ the parts can be associated with many wholes - for example several instances of a collection class may act as collectors for a given class. To use the example of staff recruitment, a candidate may be associated with an ‘applicants’ whole and at the same time be part of a ‘short-listed’ whole and eventually an ‘offer-made’ whole. Each of these wholes is acting as a collection class for ‘applicants’. List Applicant * * ‘Shared’ aggregation if mutiplicity > 1. Open diamond symbol for both sharded and ‘normal’ aggregation

47. Shared Aggregation in UML Lifetime of parts is not constrained by the lifetime of the container: –Parts can exist independently from the whole. –Much closer to the idea of a 1-many association. Shared aggregates form a network of parts rather than a tree structure.

48. Association represents the ability of one instance to send a message to another instance. This is typically implemented with a pointer or reference instance variable, although it might also be implemented as a method argument, or the creation of a local variable. In object-oriented analysis and design, an association represents a certain relationship between objects, but all objects have their own lifecycle and there is no ownership among the objects. For example, multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership among the objects and all have their own lifecycle.

49. Aggregation and composition both are specialized form of association. Composition is again specialize form of aggregation. An aggregation represents a whole that comprises various parts; so, a Committee is an aggregate of its Members. At implementation time, this relationship is not containment. (A meeting does not contain a room.) Similarly, the parts of the aggregate might be doing other things elsewhere in the program, so they might be referenced by several objects. In other words, There's no implementation-level difference between aggregation and a simple "uses" relationship (an "association" line with no diamonds on it at all). In both cases an object has references to other objects. Though there's no implementation difference, it's definitely worth capturing the relationship in the UML, both because it helps you understand the domain model better, and because there are subtle implementation issues. I might allow tighter coupling relationships in an aggregation than I would with a simple "uses," for example. Aggregation is the typical whole/part relationship. Same as an association with the exception that instances cannot have cyclic aggregation relationships (i.e. a part cannot contain its whole).

50. A whole cannot be its own part List A List cannot be part of its own list Person Child Parent

51. Composition [...] is exactly like Aggregation except that the lifetime of the 'part' is controlled by the 'whole'. Composition involves even tighter coupling than aggregation, and definitely involves containment. The basic requirement is that, if a class of objects (call it a "container") is composed of other objects (call them the "elements"), then the elements will come into existence and also be destroyed as a side effect of creating or destroying the container. It would be rare for an element not to be declared as private.

52. Aggregation should be used only in cases where there is a compositional relationship between classes, where one class is composed of other classes, where the "parts" are incomplete outside the context of the whole. Consider the case of an Order: it makes no sense to have an order which is "empty" and consists of "nothing". The same is true for all aggregates: Departments must have Employees, Families must have Family Members, and so on. If the classes can have independent identity outside the context provided by other classes, if they are not parts of some greater whole, then the association relationship should be used. In addition, when in doubt, an association is more appropriate; aggregations are generally obvious, and choosing aggregation is only done to help clarify. It is not something that is crucial to the success of the modeling effort.

53. Inheritance l Sometimes called the “is_a” relationship l Provides a way of sharing attributes and methods between subclasses (or child classes) and their superclasses (or parents) l Subclasses can share similarities with common superclasses while preserving their differences l Default types of attributes and logic of methods can be overridden in the subclasses

54. Inheritance – Abstract & Concrete classes An abstract class is designed to be a parent class that can not be instantiated. –Often represents abstract concepts or entities. –Usually has one or more abstract methods that only have a signature and no implementation. –Only used to inherit from.

55. Inheritance – Abstract & Concrete classes It is possible to instantiate a concrete class (i.e. possible to create object from). –must provide implementation for all methods.

56. Inheritance Example Build an inheritance hierarchy using the following items identified from OO Analysis. Student Qualifications Salary Lecturer Name Secretary Lecture

57. Inheritance sample solution Employee Student Qualifications Salary Lecturer Name Secretary Lecture LecturerSecretary Person Student Salary Name Lecture Where does Qualifications go?

58. Multiple Inheritance example Sales Person Manager Director Sales Manager

59. Class hierarchies Generalisation Specialisation

60. Class roles and Inheritance In a previous slide we looked at class roles: Lecturer Course takes Admin 1..* Here, the Person plays the role of a Course Tutor. Often such roles are modelled through inheritance: Lecturer Course Tutor

61. Using Class Hierarchies Generic class hierarchy copy Generic class Application specific class Using via sub-classing Instantiation of a generic class messages Using via delegation Instantiation of an application specific class

62. Don’t confuse Inheritance and Aggregation! Plane Engine Fuselage Wing * Not intuitive, therefore confusing to someone else. (A Plane is not a kind of Wing...)

63. Associations and Inheritance Plane CommercialPrivate Owns Crew Member Pilot Licence is_operated_by 1 1..* 1 0..1 1

64. Aggregation versus Inheritance l Aggregation is not the same thing as inheritance l Aggregation relates to Instances l Inheritance relates to Classes

65. Aggregation and Inheritance Plane Engine Fuselage Wing CommercialPrivate Military 1 1+ 2

66. Candidate Classes for a Library It is important to be aware of the relative stability of the various classes used in your object model. Not all classes will exhibit the same potential stability with respect to future required changes. l Component classes are likely to be more stable than container classes l Subclasses representing roles will be less stable than the more fundamental superclass

67. Fundamental Classes Scroll Bars Menus Cursors Lists Suitable material for inclusion in generic, re-usable class libraries

68. Composite Classes User interface window MenuIcon Window ScrollBarCursor..

69. Managing the bigger picture UML employs the notion of a Package as a mechanism for grouping related model elements. For example, groups of collaborating classes could be called a package. An overall system can then be composed from a number of packages. A UML Notation for a Package

70. UML Component Diagram An overall system may consist of a number of physical ‘components’ for example, where various classes are implemented in different code components. The notation is shown below: Component Name GUI User Room Booking

71. UML Deployment Diagram Different code components can be distributed amongst a number of processors or nodes in a network. The deployment diagram enables the designer to illustrate this distributed nature: Deployment diagram for a Room Booking System GUI: ClientA Booking: BuildingDiary User:UserBase >

72. Developing Static Models l Identify the main Use-cases and write down descriptions of these l Identify the main elements of information which must be stored. l Identify the main actors with which the system must interact. l Identify objects and classes l Identify associations between classes –Creating object model segments for each Use-case. l Identify attributes for classes l Merge the object model segments to create an overall object model for the system l Organise and simplify classes using inheritance l Test the object model and it’s relationships by performing walk- throughs using, for example, UML Sequence diagrams (Dynamic Modelling) l Iterate and refine the models

73. Class Model Summary The Class Model is used to identify classes and their inter-relationships. It provides a static, structural view of a system without any consideration of time sequencing or object interactions.