Object-Orientated Analysis, Design and Programming

Slides:



Advertisements
Similar presentations
Inheritance Inheritance Reserved word protected Reserved word super
Advertisements

Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Chapter 15: System Modeling with UML
Essentials of interaction diagrams Lecture Outline Collaborations Interaction on collaboration diagrams Sequence diagrams Messages from an object.
What is UML? A modeling language standardized by the OMG (Object Management Group), and widely used in OO analysis and design A modeling language is a.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
Aalborg Media Lab 23-Jun-15 Inheritance Lecture 10 Chapter 8.
Chapter 13: Object-Oriented Programming
Chapter 10 Classes Continued
Modelling classes Drawing a Class Diagram. Class diagram First pick the classes –Choose relevant nouns, which have attributes and operations. Find the.
Unified Modeling Language
The Unified Modeling Language (UML) Class Diagrams.
Object-Oriented Analysis and Design
Relationships. In the Interaction diagrams, we began to look at how classes communicate with one another. Now, we'll focus on the relationships between.
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Object-Oriented Modeling Chapter 10 CSCI CSCI 1302 – Object-Oriented Modeling2 Outline The Software Development Process Discovering Relationships.
Object-Oriented Software Development F Software Development Process F Analyze Relationships Among Objects F Class Development F Class Design Guidelines.
Lab 04.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Unit 1 INTRODUCTION TO MODELING AND CLASS MODEL Ref : L7-UML.PDF.
Chapter 16 Applying UML and Patterns Craig Larman
1 Class Diagrams: Advanced Concepts. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are the most commonly used diagrams.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Advanced UML Class Diagrams.
12 September, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 11 Class and Object Diagrams.
UML Class Diagrams 1 These lecture slides are copyright (C) Marty Stepp, They may not be rehosted, sold, or modified without expressed permission.
An Introduction to the Unified Modeling Language
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Appendix D UML at a Glance Summary prepared by Kirk Scott 1.
Design Model Lecture p6 T120B pavasario sem.
Object Oriented Analysis and Design Class and Object Diagrams.
Chapter 12 Object-oriented design for more than one class.
CS212: Object Oriented Analysis and Design Lecture 33: Class and Sequence Diagram.
CLASS DIAGRAMS A classy approach to objects. The Basic Class Diagram  Class Name  Attributes (- indicates private each would have properties or accessor/mutator.
Chapter 7 Classes and Methods III: Static Methods and Variables Lecture Slides to Accompany An Introduction to Computer Science Using Java (2nd Edition)
Class Diagram Lecture # 1. Class diagram A Class Diagram is a diagram describing the structure of a system shows the system's classes Attributes operations.
Software Modelling Class Diagram. Class Diagrams The main building block in object oriented modeling They are used both for general conceptual modeling.
2-1 © Prentice Hall, 2004 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Object-Oriented Programming
UNIT-IV Designing Classes – Access Layer ‐ Object Storage ‐ Object Interoperability.
UML Diagrams: Class Diagrams The Static Analysis Model
Unified Modeling Language
Chapter 5: Structural Modeling
Object-Oriented Analysis and Design
Class Diagrams.
Chapter 11 Object-Oriented Design
Analysis and Design with UML: Discovering Classes and Relationships
Chapter 7: Entity-Relationship Model
Reference: COS240 Syllabus
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Object-Orientated Analysis, Design and Programming
Object-Oriented Analysis
UML Class Diagrams: Basic Concepts
Object Oriented Analysis and Design
Software Engineering Lecture #11.
Object Oriented Analysis and Design Using the UML
Module 8 – Database Design Using the E-R Model
Systems Analysis and Design With UML 2
UML Class Diagram.
Analysis models and design models
Business Analysis More on Classes Chris Russell O2.41
Copyright 2007 Oxford Consulting, Ltd
Analysis and Design with UML: Classes and Relationships
Object Oriented Programming in java
Object Oriented System Design Class Diagrams
Information System Design
Chapter 6b: Database Design Using the E-R Model
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Chapter 11: Class Diagram
From Class Diagram to Contract Diagram
Presentation transcript:

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

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…

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

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

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.

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

Types of Visibility Public Protected

Types of Visibility Package (default) Private

Visibility Summary

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

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.

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

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.

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.

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

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

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

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

Class Relationships

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.