Lecture 06.pptxLecture 06.pptxLecture 06.pptx

Lecture 06.pptx

1. Class Diagrams

2. Introduction This session will cover: Class Diagrams Problem Domain Solution Domain Anatomy of a Class Relationships in Class Diagrams Generalisation (Inheritance) Aggregation Association Finer Points of Class Diagrams Polymorphism Package Diagrams Association Classes

3. Class Diagrams A class diagram in the UML is a static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes The class diagram is the main building block in object oriented modelling They are being used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed As such, class diagrams are a bridge between the problem and solution domains

4. Class Diagrams in the Problem Domain The domain model is created in order to document the key concepts, and the domain-vocabulary of the system being modelled The model identifies the relationships among all major entities within the system, and is often extended to identify their important methods and attributes The domain model provides a structural view of the system that can be complemented by other dynamic views in Use Case models

5. Class Diagrams in the Problem Domain An important benefit of a domain model is that it describes and constrains the system scope The domain model can be effectively used to verify and validate the understanding of the problem domain among stakeholders It is especially helpful as a communication tool and a focusing point between technical and business teams

6. Class Diagrams in the Solution Domain The domain model is extended in the construction phase of the software development cycle since the semantics shown therein can be used in the source code Entities can become classes, while the important methods and attributes can be carried directly to the source code Not all entities become classes, some are purely “domain objects” Methods and attributes are often added to as additional behaviour is required

7. Anatomy of a Class Each class is represented as a box, with three elements The upper part holds the name of the class The middle part contains the attributes of the class The bottom part gives the methods or operations the class can take or undertake NamedClass firstAttribute secondAttribute firstMethod secondMethod Shape area volume getArea getVolume

8. Anatomy of a Class In the domain model, little detail is (initially) included in an individual class As system design progresses, detail is added in terms of typecasting attributes, defining whether methods are public etc Private methods/attributes are preceded by a – Public methods/attributes are preceded by a + Protected methods/attributes are preceded by a # Shape -area : int #volume : double +getArea() #getVolume()

9. Relationships Between Classes The Class Diagram is used to represent many relationships between entities (in the problem domain) and classes (in the solution domain) The three major relationships are: Generalisation Aggregation (including Composition) Association

10. Generalisation (Inheritance) Generalisation is the ability to create a base class and then derive classes from that base class Derived classes “inherit” the attributes and methods of the base class Exceptions are dealt with through overriding Base classes that will never be used to create objects and just allow the creation of a derived class is an abstract class

11. Generalisation (Inheritance) Generalisation relationships are indicated using the same notation as in Use Case Diagrams An open arrow head shows the generalisation Shape area volume getArea() getVolume() Square sideLength setSideLength() Circle circleRadius setRadius getCircumference No “set” methods, this is likely to be an abstract class The Shape class is a generalisation of Circles and Squares

12. Aggregation Aggregation is often referred to as the “whole-part” relationship It can be considered a “has a…” relationship

13. Aggregation The aggregation relationship is indicated by a diamond icon next to the “whole” class Arrowheads are used to indicate directionality of communication No arrowheads indicates that communication is bi-directional Car make model drive() accelerate() Transmission changeGear() Engine increaseFuel() drive() method calls changeGear () method in transmission accelerate() method calls increaseFuel () method in engine

14. Composition Composition is a form of aggregation In UML, composition is depicted as a filled diamond and a solid line It always implies a multiplicity of 1 or 0..1, as no more than one object at a time can have lifetime responsibility for another object Car make model drive() accelerate() Engine increaseFuel()

15. Aggregation & Composition Aggregation differs from composition in that it does not imply ownership In composition, when the owning object is destroyed, so are the contained objects In aggregation, this is not necessarily true

16. Generalisation & Aggregation Both Generalisation and Aggregation can be “layered” to what ever extent is useful Shape Rectangle Square

17. Generalisation & Aggregation Both Generalisation and Aggregation can be “layered” to what ever extent is useful Order totalPrice addLineItem() LineItem numberOfItems totalPrice() Item price

18. Association The association relationship is simply a relationship that means two classes “communicate” Often one class provides a service to another or one class starts a series of events by executing a method of another class Associations are drawn as lines/arrows connecting classes

19. Association The line between classes tells us something about the relationship In this example, there is a uni -directional relationship An object of C lassA can call methods of an object from ClassB , but not vice-versa ClassA methodA() ClassB methodB1() methodB2()

20. Association In this example, there is a bi-directional relationship An object of each class can invoke methods in objects of the other class In UML, bi-directional relationships are not modelled as double-headed arrows but the absence of arrows ClassA methodA() ClassB methodB1() methodB2()

21. Cardinality Association and Aggregation relationships can be further refined by defining the cardinality of the relationship One to many, many to many, mandatory etc The following notation is used in UML 1 No more than one 0..1 Zero or one * Many 0..* Zero or many 1..* One or many

22. Aggregation Example Each order object must have at least one line item object Each line item object must belong to one order Order totalPrice addLineItem() LineItem numberOfItems totalPrice() Item price 1 1..* 1 1..*

23. Association Example A specific object of ClassA must have a relationship with a specific object of ClassB A ClassB object may have a relationship with any number of ClassC objects And vice-versa ClassA methodA() ClassB methodB1() methodB2() 1 1 ClassB methodB1() methodB2() ClassC methodC1() methodC2() 0..* 0..*

24. Polymorphism Polymorphism is the ability for a program to call the same method on objects of different classes Whilst polymorphism isn’t explicitly part of a UML class diagram, it’s presence can be identified in a generalisation relationship

25. Polymorphism Employee name employeeID calculatePay() SalaryEmployee annualSalary calculatePay() HourlyEmployee hourlyRate calculatePay() CommissionEmployee commissionRate totalSales calculatePay() The presence of multiple methods of the same name indicates that we are dealing with polymorphism This is an undefined method, because it is undefined it is known as an abstract method that is defined in derived classes

26. Package Diagrams Most system development projects will involve the development of multiple class diagrams Organising classes into different packages that are determined by the “business logic” can further aid understanding of the problem domain It is the package diagram that is the “real domain model” for complex systems, not the class diagram

27. Example Package Diagram UI Playlist Payment Playback

28. Association Classes Association classes allow you to add attributes, operations, and other features to associations Association classes are not always necessary and often misused – but can be very powerful

29. Association Class Example The data in the Association Class relates specifically to the relationship An alternative approach is to model Employment as a class in it’s own right and adjust the cardinality Employee employeeID calculatePay() Company name 1 1..* Employment startDate : date endDate : date

30. Association Class Example Technically, the use of the Association Class is more “correct” but involves more complex diagramming Employee employeeID calculatePay() Company name 1 1 Employment startDate : date endDate : date 1 1..*

31. Conclusions Class Diagrams are a model of the static structure of a system Most of what we’ve talked about should be revision from P1 and P2!!