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

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.

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.

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

Software Development Process

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.

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.

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.

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.

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.

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.

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.

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.

Discovering Class Relationships Association Aggregation and Composition Dependency Inheritance

Association

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.

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.

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.

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

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.

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

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).

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

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.

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 }

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 }

Aggregation and Composition

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.

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

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

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 {

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.

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.

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.

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.

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”

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:

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