Unit - 3 OBJECT ORIENTED DESIGN PROCESS AND AXIOMS

Design Analysis- What needs to be done Objects discovered serve as the framework for design Identified objects, attributes, methods, associations must be designed for implementation as a data type expressed in the implementation language Emphasis from application domain to implementation and computer concepts (user interface, access layer) Good design simplifies the implementation and maintenance of a project Axiomatic approach is to formalize the design process and assist in establishing a scientific foundation for the OOD process

THE OOD PROCESS The classes are viewed in the implementation point of view. New classes and attributes can be added if required The following activities are followed Apply design axioms to design classes, their attributes, methods, associations, structures and protocols 1.1 Refine and complete the static UML class diagram 1.1.1 Refine attributes. 1.1.2 Design methods and protocols using UML activity diagram 1.1.3 Refine the associations 1.1.4 Refine class hierarchy and design with inheritance 1.2 Iterate and refine again

Design the access layer 2.1 Create mirror classes for the access layer as business layer 2.2 Identify access layer class relationship 2.3 Simplify classes and their relationships 2.3.1 Avoid redundant classes 2.3.2 Delete classes that have only 1 or 2 methods. Try to add in other classes 2.4 Iterate and refine again

Design the view layer 3.1 Design the macro level user interface, identifying view layer objects 3.2 Design the micro level user interface, which includes the following activities 3.2.1 Design the view layer objects by applying the design axioms and corollaries 3.2.2 Build the prototype of the view layer 3.3 Test usability and user satisfaction 3.4 Iterate and refine Iterate and refine the whole design. Reapply the design axioms and repeat the preceding steps.

OOD Axioms Axiom is a fundamental truth that is always observed to be valid and for which there is no counterexample or exception. They cannot be proven or derived. A theorem is a preposition that may not be self evident but can be proven by accepted axioms. It is a law or principle. Theorem is valid if its referent axioms and deductive steps are valid.

There are two axioms followed. Axiom 1: The independence Axiom. (relationships between components) Maintain the independence of components Axiom 2: The Information Axiom. ( complexity of design) Minimize the information content of the design

Axiom 1: The independence Axiom This Axiom states that, during the design process, as we go from requirements to a system component, each component must satisfy that requirement without affecting other requirements E.g.., designing a refrigerator door with two requirements: Door should provide access to the food Minimal loss of energy on opening and closing it (opening the door is independent of loss of energy) Requirements are coupled Vertical door – coupled This can be designed by providing horizontally as like chest-type freezers. Which satisfies both the requirements, without violating the first axiom

Axiom 2: The Information Axiom. This Axiom is concerned with simplicity Each fact should be with a minimum amount of complexity and maximum simplicity and straightforwardness. Minimal complexity produces the most easily maintained and enhance application OOS- to use inheritance, system’s built in classes to minimize complexity

COROLLARIES A Corollary is a proposition that follows from an axiom or another proposition that has been proven Can be valid or invalid as theorems They are also called as design rules. Derived from design axioms Useful in making design decisions , since they are applied to actual situations more easily than original axioms

From the two axioms, the following corollaries are formed Uncoupled design with less information content Highly cohesive objects can improve coupling because only a minimal amount of information need to be passed between objects Single purpose Each Class must have a single, clearly defined purpose Large number of simple classes Allows reusability Strong mapping Strong association between the analysis object and design object Standardization Promote standardization by designing interchangeable components and reusing existing classes or components Design with inheritance

Corollary 1: Uncoupled design with less information content The main goal here is to maximize objects cohesiveness among objects and software components in-order to improve coupling Coupling This is the measure of strength of association established by a connection from one object or software component to another Change to one component of the system should have minimal impact on the other system.

Strong coupling among the objects complicates the system. The degree of coupling is a function of How complicated the connection is Whether the connection refers to the object itself or something inside it What is being sent or received OOD – Interaction and Inheritance coupling Interaction Coupling involves the amount and complexity of the messages between the components Hence its better to keep the messages simple Also reduce the number of messages sent & received by an object (infrequent as possible) Inheritance coupling: coupling between super and sub classes A subclass is coupled with its super class in terms of attributes and methods High inheritance coupling is desirable If the sub class is overriding all of the methods (low inheritance coupling)

Types of coupling among different objects or components Content coupling – degree is very high Common coupling – degree is high Control coupling – degree is medium Stamp coupling – degree is low Data coupling – degree is very low

Refers to the “single-purposeness” of an object Cohesion This is the measure of strength of interaction within a single object or a software component Refers to the “single-purposeness” of an object Highly cohesive object have minimal coupling, because it needs only minimum amount of messages to be passed between others. Types of cohesion Method cohesion Method should carry only one function Multiple functions is undesirable Class cohesion Class’s methods and attributes must be highly cohesive Used by internal methods or derived classes Inheritance cohesion How interrelated are the classes? Does specialization portray or arbitrary?

Corollary 2: Single purpose Each class must have a purpose During documentation, it should be possible to write the purpose of the class within one or two sentence If it’s not possible, then think such that, responsibilities can be divided into different classes. Method must provide only one service Keep the classes simple

Corollary 3: Large number of simple classes The classes created should be simple and more general This is useful for reusing the classes for the future If the class is complex, try to divide the class, such that there are large number of small classes Focus on reusability (higher productivity)

Corollary 4: Strong Mapping This is used to link the classes analyzed during the analysis phase and the classes designed during the design phase

Corollary 5: Standardization The class libraries used in several object oriented programming must in a standard form to enable reusability. Store it in repository Provide easy search through the repository

Corollary 6: Designing with inheritance When a class is implemented, it is necessary to determine its ancestors. What attribute it will have, and what messages it will understand. Inheritance is used in-order to minimize the amount of coding in the program