Modelling classes

1. Modelling classes Drawing a Class Diagram

2. Class diagram • First pick the classes • Choose relevant nouns, which have attributes and operations. • Find the attributes • Any relevant information about the class objects. • Next find the operations • Any behaviour of the class – any behaviour that changes the attribute values of the class. • Next find the associations • Classes are associated if they • Invoke each other’s operations • Have protected access to each other’s attributes.

3. Use Case to Class • The actors are not always persistent classes • The primary tasks in the use case diagram must be the responsibility of a class. • Is it a persistent class? • Which class holds the attributes that the operation adds / amends/ updates / deletes?

4. Class operations • Is it public or private? • Public, if other classes use this operation • Private, if it only called by the owning class. • Does it imply an association? • Yes, if other classes invoke it, or it invokes operations in other classes.

5. Association • When the operation ‘close a claim is invoked • It invokes the ‘getage’ operation in claimant • Which invokes the operation ‘CalculateAge’ in claimant

6. Sub and Super Classes • A super-class is an abstraction of several classes that have mostly common attributes and operations. • A sub-class instance IS A super-class instance. • Some super-classes have no instances themselves - they are merely abstract classes.

7. Generalisation • A super-class is a GENERALISATION of a sub-class. • A sub-class is a SPECIALISATION of a super-class. • Operations and attributes in the super-class are automatically INHERITED by objects in the sub-class. • Operations and attributes in the sub-class can OVERRIDE those in the super-class.

8. Generalisation • Inheritance • Information hiding • Mono and polymorphism • Overriding needed for • extension • restriction • convenience • Optimisation

9. Generalisation examples • A generic ‘person’ class will have • attributes of name, address, e-mail address, phone no, etc. • Operations of • Phone • Mail • E-mail • An employee is a person • A driver isan employee • An assessor isan employee

10. And more… • A radio alarm clock isa clock • A watch isa clock • Is a timer a clock?

11. General rules • An object of a specialised class can be substituted for an object of a more general class in any context which expects a member of the more general class, but not the other way around. • There must be no conceptual gulf between what objects of the two classes do on receipt of the same message.

12. Generalisations • Are denoted as solid paths with a large hollow triangle pointing at the more general element. • Must not be circular -i.e. an element cannot have a generalisation relationship to itself.

13. Sample Generalisations • A School of Computing student is a student. • A school of computing student is an account-holder. • A lecture is a member of academic staff is a member of staff of the school of Computing. • A school of computing lecturer is an account holder. • A frog is a water-based animal. • A frog is a land-based animal. • A fish is a water-based animal. • A rabbit is a land-based animal. • An elephant is a land-based animal.

14. Specialisations • More specific elements. • Specialize more general elements. • Receive all the characteristics (attributes, operations, methods and associations) of the more general elements via the mechanism of inheritance. • May add their own characteristics. • May override inherited methods. • May be substituted for their more general elements.

15. Starting a Class Diagram • Choose your candidate objects from the system description. • For each candidate: • Is there more than one object in this class? • Is this object a system user / location? • Can you describe the type of information you need to know about each member of this group of objects?

16. Starting Class Diagrams • Rather than trying to define the entire class • concentrate on the data that is required for business classes. • set up a data model, that can be converted into a relational database, only without the keys. • later, loosen the structure, to give object-oriented advantages. • add operations on the data.

17. What Is an Attribute? • An attribute is the type of information you need to know about each object in a class. • An attribute is an attribute when:- • it has a finite length • it has a single value for each object • An attribute is not an attribute when:- • it in turn has several attributes • it has multiple values

18. Operations The operations in a class include: • Constructor operations create new objects in the class. • Selector operations get information about and from an object in a class. • Mutator operations set information about and to an object in a class. • Destructor operations destroy objects of the class. • An operation may also send a message to a class that is associated directly with the class to which the operation belongs. It can only send a message – it cannot operate on the other class!

19. Operations • Are named services that may be requested of instances of a classifier. • Are implemented by methods. • May have parentheses containing a comma-separated parameter list that indicates the formal parameters passed to a method. • May have a return list consisting of a comma-separated list of formal parameters passed back from a method.

20. Parameters • May have a kind specified. This value may be ‘in’, ‘out’ or ‘inout’. • May have a colon followed by a type expression that indicates the types of values a parameter may have. • May have an equal sign followed by a default value that is used to set the value for unspecified parameters when the method is invoked.

21. Return parameter • Must have a name or identifier string that represents the name of the parameter. • May have a colon followed by a type expression that indicates the type of values a parameter may have.

22. What is an association? • An association is a relationship between object classes. • An association is used to implement a link between objects – to send messages or instructions from one class to another. • An object from one class can invoke a method on an object from another class, thereby accessing it through its public interface.

23. Associations • Associations correspond to verbs • Express the relationship between classes • Class A and class B are associated if an object of class A • Sends a message to an object of class B • Creates an object of class B • Has an attribute whose values are objects of class B or collections of objects of class B • Receives a message with an object of class B as an argument

24. Multiplicity • Specifies how many objects from the class are involved in each association. • Each class in the association has multiplicity. • It can be. • An exact number e.g. 1. • A range of numbers e.g. 1..10. • An arbitrary, unspecified number, using *.

25. Associations • Associate objects from two classes. • The multiplicity of the association is decided at both ends of the association. • To decide on multiplicity, • Put yourself in the position of a single object from the origin class. • Ask yourself how many objects you are related to in the destination class. • This decides the multiplicity at the destination end of the association.

26. Types of Association • Simple binary associations. • Involve two classes, where each may get information from the other. • Uni-directional associations. • Involve two classes, where one can get information from the other, but not vice-versa. • E.G. Customer and order. Depending on the implementation, this could be uni- or bi-directional.

27. Associations • May be reflexive – i.e. associate a class with itself. • May have a name that represents the name of the association. • May have a name-direction arrow.(Small solid triangle attached to the name, pointing in the direction of application of the name). If omitted, names are read right – left and top-bottom. • May be association classes. • May have an aggregation indicator.

28. Association Classes • Are denoted as class symbols attached by dashed lines to associations. • Are associations with class properties or classes with association properties. • Define a set of characteristics that belong to the relationship. The characteristics are not owned by any of the classes they relate.

29. Aggregation • Indicated by a diamond. • A hollow diamond indicates weak or shared aggregation. • A solid diamond indicates composition – associated class objects must belong to only one component and are deleted if the composite is deleted. • Must not be associated to both ends of an association.

30. Multiple Class Associations • Associations among three or more classes are shown as a diamond with paths from each corner / side. Such an association. • Must not involve aggregation or qualifiers. • May have a single class appear more than once or on multiple paths.

31. Aggregation • Indicated by a diamond. • A hollow diamond indicates weak or shared aggregation. • A solid diamond indicates composition – associated class objects must belong to only one component and are deleted if the composite is deleted. • Must not be associated to both ends of an association.