1. Reference: COS240 Syllabus
COS240 O-O Languages AUBG, COS dept
Lecture 52
Title:
OO Modeling & OO Design
(to model the application in terms of cooperative objects)
Reference: COS240 Syllabus

2. Motivations
The Java/C# lectures introduced objects, classes, class inheritance, interfaces, polymorphism, EH and EvH, i.e. Java and C# as OOPL.
You learned the concepts of OOP.
This lecture focuses on the analysis and design of software systems using the OO approach.
You will learn class-design guidelines, and the techniques and patterns for designing reusable classes.

3. Lecture contents:
To become familiar with the process of program development.
To learn the relationship types: association, aggregation, composition, dependency, strong inheritance, and weak inheritance.
To discover classes and determine responsibilities of each class.
To declare classes to represent the relationships among them.
To design systems by identifying the classes and discovering the relationships among these classes.
To implement the Rational class and process rational numbers using this class.
To design classes that follow the class-design guidelines.
To introduce design patterns for developing sound software systems.

4. Software Development Process
SDP = SDM = PDM, also
Software Life Cycle
There exist various models of SWLC
Build and Fix model
Waterfall model – see next slide(s).
Rapid Prototyping model
Spiral model

5. Software Development Process

6. Requirement Specification
A formal process that seeks to understand the problem and document in detail what the software system needs to do. This phase involves close interaction between users and designers.
Most of the examples in COS240 are simple, and their requirements are clearly stated. In the real world, however, problems are not well defined. You need to study a problem carefully to identify its requirements.

7. System Analysis
Seeks to analyze the business process in terms of data flow, and to identify the system’s input and output.
Part of the analysis entails modeling the system’s behavior. The model is intended to capture the essential elements of the system and to define services to the system.

8. System Design The process of designing the system’s components.
This phase involves the use of many levels of abstraction to decompose the problem into manageable components, identify classes and interfaces, and establish relationships among the classes and interfaces.

9. Implementation
The process of translating the system design into programs. Separate programs are written for each component and put to work together.
This phase requires the use of a programming language like Java or C#.
The implementation involves coding, testing, and debugging.

10. Testing
Ensures that the code meets the requirements specification and weeds out bugs.
An independent team of software engineers not involved in the design and implementation of the project usually conducts such testing.

11. Deployment Deployment makes the project available for use.
For a Java applet, this means installing it on a Web server; for a Java application, installing it on the client's computer.

12. Maintenance
Maintenance is concerned with changing and improving the product.
A software product must continue to perform and improve in a changing environment. This requires periodic upgrades of the product to fix newly discovered bugs and incorporate changes.

13. Discovering Classes
One popular way for facilitating the discovery process is by creating CRC cards. CRC stands for classes, responsibilities, and collaborators. Use an index card for each class, as shown in the Figure below.

14. Discovering Class Relationships
Association
Aggregation and Composition
Dependency
Inheritance

15. Association

16. Association
Association represents a general binary relationship that describes an activity between two classes.
Association illustrated using a solid line btw two classes.
Examples:
This is pure naked illustration.
No labels, no directions, no multiplicity, no roles
See next slide – the same association illustrated in more informative way.

17. Association
Association represents a general binary relationship that describes an activity between two classes.
Example 1:
“Student taking a course” is an association btw the Student class and the Course class.

18. Association
Association represents a general binary relationship that describes an activity between two classes.
Example 2:
“Faculty member teaching a course” is an association btw the Faculty class and the Course class.

19. Association (Label)
Association represents a general binary relationship that describes an activity between two classes.
Association illustrated using:
An optional label to describe the relationship.
E.g. label Take for Example 1
E.g. label Teach for Example 2

20. Association (Direction)
Association represents a general binary relationship that describes an activity between two classes.
Association illustrated using:
An optional small black triangle to indicate the relationship direction.
Student takes a course as opposed to Course taking a student Or
Faculty teaches a course as opposed to Course teaching faculty.

21. Association (Role) Association illustrated using:
Each class involved in the relationship may have a role name that describes the role played by the class in the relationship. The role name for Faculty class is: Teacher

22. Association (Multiplicity)
Association illustrated using:
Each class involved in association may specify a multiplicity, i.e. number or range interval to specify how many objects of the class are involved in the relation.
* Means unlimited number of objects; + means 1 or more; m..n means a range
Each student may take any number of courses (*).
Each course must have at least 5 and at most 60 students (5..60).
Each course is taught by one only faculty (1).
Each faculty may teach from 0 to 3 courses per semester (0..3).

23. Association
An association is usually represented as a data field in the class.

24. Translation is not Unique
NOTE: If you don’t need to know the courses a student takes or a faculty teaches, the data field
courseList in Student or
courseList in Faculty
can be omitted.

25. Association Btw Same Class
Association may exist between objects of the same class. For example, a person may have a supervisor.
public class Person {
// data fields omitted
private Person supervisor;
// constructor(s) omitted
// method(s) omitted }

26. Association Between Same Class
If a person may have several supervisors, you may use an array to store supervisors.
public class Person {
// data fields omitted
private Person[] supervisors;
// constructor(s) omitted
// method(s) omitted }

27. Aggregation and Composition

28. Aggregation and Composition
Aggregation is a special form of association, which represents an ownership relationship between two classes. Aggregation models the has-a relationship. An object may be owned by several other aggregated objects.
If an object is exclusively owned by an aggregated object, the relationship between the object and its aggregated object is referred to as composition.

29. Aggregation and Composition
Aggregation illustrated: an empty diamond attached to the aggregated object.
“a person has an address” is an aggregation btw Person class and Address class, since the address may be shared by several persons.
Composition illustrated: a filled diamond attached to the aggregated object.
“a person has a name” is a composition btw Person class and Name class, since a name is strictly owned by a person

30. Representing Aggregation in Classes
An aggregation relationship is usually represented as a data field in the aggregated class.

31. Inner Classes Translation
If Name or Address is used in the Person class only, they can be declared as an inner class in Person. For example,
public class Person {
private Name name;
private Address address;
...
class Name { }
class Address {

32. Dependency
A dependency describes a relationship between two classes where one (called client) uses the other (called supplier). In UML, draw a dashed line with an arrow from the client class to the supplier class. For example, the ArrayList class uses Object because you can add objects to an ArrayList. The relationship between ArrayList and Object and the relationship between Calendar and Date can be described using dependency, as shown in Figures below.

33. Dependency vs. Association
Both association and dependency describe one class as depending on another.
Association is stronger than dependency.
In association, the state of the object changes when its associated object changes.
In dependency, the client object and the supplier object are loosely coupled.
The association relationship is implemented using data fields and methods. There is a strong connection between two classes.
The dependency relationship is implemented using methods.

34. Coupling
Dependency, association, aggregation, and composition all describe coupling relationships between two classes. The difference is the degree of coupling with composition being the strongest, followed by aggregation, association, and dependency in this order.

35. Inheritance Inheritance models is-a or is-a-kind-of or
is-an-extension-of relationship between two classes.
Inheritance classified:
Strong is-a relationship describes direct inheritance btw two classes.
Weak is-a relationship describes that a class has certain properties.

36. Strong Inheritance Relationship
Strong is-a relationship can be represented using class inheritance. For example, see below the relation “a faculty member is a person”

37. Weak Inheritance Relationship
A weak is-an-extension-of relationship can be represented using interfaces. For example, the weak is-an-extension-of relationship “students are comparable based on their grades” can be represented by implementing the Comparable interface, as follows:

38. Thank You for Your attention!
Liang, Introduction to Java Programming, Eighth Edition, (c) 2011 Pearson Education, Inc. All rights reserved