Lecture 06.pptxLecture 06.pptxLecture 06.pptx
- 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 ClassA 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!!