Presentation is loading. Please wait.

Presentation is loading. Please wait.

Object-Orientated Analysis, Design and Programming

Similar presentations


Presentation on theme: "Object-Orientated Analysis, Design and Programming"— Presentation transcript:

1 Object-Orientated Analysis, Design and Programming
Presentation by Dr. Phil Legg Senior Lecturer Computer Science 3: Class Relationships Autumn 2016

2 Recap from Last Week I’ve fixed the diagram from last week…
+ and – for public / private (more on that this week)… Well use “name: type” – as defined in IBM UML 2.0 specification (thanks to Clare for this) I’ll aim to be consistent  Recap on class diagram for UWEfilm…

3 Class Diagram A class diagram shows the classes within a model.
It illustrates which classes interact but not what happens when they do. We therefore say that a class diagram provides a static view of the system, defining the static relationships between classes. Initially draw all of these classes on a diagram with simple links between classes to represent collaborations

4 Visibility There are four different types of visibility that can be applied to the elements of a UML model

5 Types of Visibility Public Visibility Protected Visibility
specified using the plus (+) symbol Declare an attribute or operation public if you want it to be accessible directly by any other class. It’s usually best to avoid public attributes except for constants Protected Visibility specified using the hash (#) symbol can be accessed by methods that are part of your class and also by methods that are declared on any class that inherits from your class.

6 Types of Visibility Package Visibility (also called default visibility) specified with a tilde (~) Any class in the same package can directly access attributes or operations declared with package visibility modifier Private visibility most tightly constrained, and is shown by a minus (-) symbol Only the class that contains the private element can see or work with the data stored in a private attribute or make a call to a private operation, Private visibility is most useful if you have an attribute or operation that you want no other part of the system to depend on. If you intend to change an attribute or operation at a later time but don’t want other classes with access to that element to be changed. It’s a commonly accepted rule of thumb that attributes should always be private

7 Types of Visibility Public Protected

8 Types of Visibility Package (default) Private

9 Visibility Summary

10 UML Class State: Attributes
Attributes can be represented on a class diagram either as inline attributes or by association with another class

11 Multiplicity An attribute could represent any number of objects of its type Multiplicity allows you to specify that an attribute represents a collection of objects it can be applied to both inline and attributes by association. A * at the BlogEntry class end of the association indicates that any number of BlogEntry objects will be stored in the entries attribute within the BlogAccount class. The 1 specified at the other end of the association indicates that each BlogEntry object in the entries attribute is associated with one and only one BlogAccount object.

12 Multiplicity Multiplicity should be indicated at each end of an association a Car has 3 or 4 Wheels, but each Wheel belongs to exactly one Car

13 Dependency A dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements. Indicates a situation in which a change to the target element may require a change to the source element in the dependency.

14 Dependency - Example Accessing service to an external system
A dependency will occur when passing an object type as a method argument. In this situation a class (class 1) sends a message to another class (class 2) passing a parameter of third type of class (class 3). This is illustrated in the diagram below. Let's assume that Class3 provides a method called "sumSomeNumbers" that takes two parameters - the numbers to add together. Class2 uses this method to add numbers together. At a later time the Class3 design is changed, now "sumSomeNumbers" takes three parameters, this means that the code in Class2 will now have to be changed. This is a dependency, the change to Class3 meant that Class2 had to be changed.

15 Association has Car Person * 1 Hire Car Person * 1
When any two classes are connected in any way we say they are ‘associated’. For example, a “Student” studies at a “University”. An association is graphically rendered by a solid line connecting the same or different classes on a UML class diagram. Associations between classes represent the rules about what links can exist between instances of those classes. Associations should usually be named to avoid possible ambiguity. (E.g. Person works-for Company and Person is-customer-of Company.) Association can be bi-directional (by default) or uni-directional has Car Person * 1 Hire Car Person * 1

16 Aggregation Used to express the “part-of” or “has-a” relationship
Within the Unified Modelling Language, there are two distinct types of aggregation: Composite and Shared

17 Aggregation - Composite
Represented by the “filled in” diamond at the parent end of the relationship. Aggregation is only appropriate where the parent (or whole) exercises complete lifecycle control over its children (or parts). It creates its children, and when it is destroyed, its children are destroyed with it. Can’t exist independently Is-part-of relationship

18 Aggregation - Shared Represented by the “empty” diamond at the parent end of the relationship. This aggregate relationship is more “loose”, The parent (or whole) does have a strong relationship with its children (or parts), HOWEVER, the child can have a lifecycle which is wider than its parent. Therefore if you destroy the parent, the child is not necessarily destroyed. Has-a relationship

19 Class Relationships

20 In-Class Activity Design a system for managing the operation of a shop, for the shop owner and for the customers. The system should allow the customers to browse the list of books; to put a book in a shopping basket; and to proceed with the purchases. Records of payment need to be stored, but payment of purchase is handled via a third party system. The owner should be able to add new book titles to the system and browse the list of books as well as checking the stock levels in order to decide if he needs to add more copies in the shop. The owner also wants to keep a record of customer details so that he can send information about new titles to customers at the beginning of each month.


Download ppt "Object-Orientated Analysis, Design and Programming"

Similar presentations


Ads by Google