Object Oriented Methodology

1. Object Oriented Methodology Part I Concepts

2. Introduction to Object Oriented Concepts • OO is an “approach” to software development which includes : • Requirements • Design • Programming • Testing • Metrics • Heart of OO is representing both problems and solutions in a fairly consistent way via “Objects” • data which characterize the object • methods which characterize the behavior or functions of the object

3. Introductory Example • In traditional programming languages we have data types such as “integer” or “character” provided to us as part of the language. • What do we do when we want to represent and operate on an abstract concept such as “age?” • We normally pick an available or supported data type to represent it. • In this case which data type would you pick ? • Then we assign a name such as “ person_age” to a variable which is in turn designated as of that chosen data type with possibly some limits (e.g. non-negative and probably not more than 300) • The variable, person_age, may be operated with operators (functions) defined for that data type. • Now, consider a more complex entity such as “employee” : ------- what comes to mind?

4. “Employee” Class • How would you describe an employee ? • Values it may take on: just as “integer” can be any negative, zero, or positive integer whose size is limited by the hardware and operating system. “Employee” attributes may include: • age represented by integer • sex represented by character • name represented by a string (or array of characters) • address represented by string (or array of characters) • etc. • What behavior or functions can an employee perform ? : • just as “integer”, can it be operated on with arithmetic operations of add, subtract, etc. ? Or rather - - - something else? • “respond to” employee age or address request • “respond to” number of years to eligible retirement • etc.

5. “Employee” Object • All “employees” for the specific problem and solution of interest will be represented the same way and have same behavior just as all “integers” have the same characteristics and behavior. • But there is an “individual” employee: • John Thompson • Susan Tang • etc. • Each of these individual employee (emp_1) is an Object just as integer variables x, y, or z which are declared as an integer type.

6. Pseudo-Code Example of Class and Object • Class Employee /* defining a class called Employee */ • { • public: /* declaring that the functions or methods are all public */ • method_1( ) /* function to compute and return retirement year */ • private : /* declaring that the employee age is private and protected */ • int age; /* age is a variable of type integer */ • }; /* end of defining the class called Employee */ • main ( ) /* main program which uses the class, Employee */ • { • Employee emp1; /* emp1 is an object of class Employee */ • int ret_age, ret_year; /* two variables of data type, integer */ • ret_year = emp1.method_1(ret_age) ; /* set retirement yearfor emp1 by using method_1 */ • print ret_year ; /* print retirement year */ • };

7. Some OO Characteristics • Identity : • information is organized into “unique” entities called, objects. • Abstraction: (needed for all types of design methodology) • a method where only the “essentials” are described. • ** Classification: • grouping of “common” attributes and behaviors into an entity called, class. • **Encapsulation: • hiding of implementation “details” and showing only the necessary interfaces • ** Inheritance: • providing a structure and mechanism to “share” attributes and functions. • ** Polymorphism: • capability of providing a different behavior of a function with same name based on different classes and/or parameters passed to the function. • Persistence: • capability of a saving the object’s name, state, and functions. • ** these are the more important characteristics of OO

8. OO Concepts (cont.) • Thinking of problems and solutions in terms of “classes” and “objects” may not be natural for some people and very natural for other. • Abstraction is an important methodology that plays a key role here. • In a library system, what may be some classes? (books, people, etc.) We will revisit this one a again later -- in design discussion • Inheritance is a capability that allows us to think in terms of a “family” of classes and perhaps how to “reuse” the higher level classes by the lower level classes • In a library system, what may be a “family” of classes ? • (e.g. intellectual properties - audio - tapes , diskettes, compact disks )

9. OO Concepts (cont.) • Encapsulation is the notion of “hiding.” What we are hiding is the implementation details. Why? • implementation details should not be exposed mainly because of the desire to minimize coupling. If the details are exposed, there may be another component that will become heavily dependent on some implementation specifics --- which can change. • Hiding the implementation details also forces the reverse issue of what should be exposed ----- interface. Clear interfaces should be explicitly designed and maintained. • OO has specific facilities that allow us to differentiate the items we want to hide and those we want to consider as interfaces • private • public

10. OO Concept (cont.) • Polymorphism is the ability to respond to similar requests that are asked of different objects. • Allows the “reuse” of the correct member function or method based on late binding. • Consider the situation where two classes have a similar function. Depending on which class the specific object belongs to, the appropriate method is invoked. Feed ( ) function for Bird class If animal referred to Bird class animal . feed( ); Fee ( ) function for Reptiles class If animal referred to Reptiles class

11. How Much of the OO Characteristics can YOU see ? - Discuss • Class Employee • { • public: • method_1( ) { . . . . } • private : • int age; • }; • main ( ) { • Employee emp1; • int ret_age, ret_year, this_year; • ret_year = emp1.method_1(ret_age) + this_year; • print ret_year ; • };

12. class Cube { protected: // need this to be protected because it will be used by the derived class float length; public: virtual float area( ) {return (length*length);} // compute area of the item, square void set_length(float z){length = z;} // set the passed parameter length void volume( ){cout<< “volume is”<< area( )* length<<‘\n’;}// volume = area * length }; class S_Cylinder : public Cube // S_Cylinder is a special kind of cylinder with h = r { virtual float area( ) {return( 3.14*length*length);} // (override) compute area of circle }; main ( ) float input; Cube c1; S_Cylinder cyl; cout<< ‘\n’<< “key in length of your item:”; cin >> input; c1.set_length(input); // pass the input length field c1.volume( ); // this should give us the volume of the cube cyl.set_length(input); // pass the same input length field cyl.volume( ); // because we declared the function, area, to be virtual, it will give us the cylinder // volume because the area function is not bound in the volume function until later. Example of Virtual Function from C++ (for polymorphism)

13. Object Oriented Methodology Part II Development with OO

14. General - OO Development • Consistency of “terminology” across different phases of software development, but coming up with classes to represent the problem and the solution is the key • class and object • attributes • behaviors and functions • Has 3 perspectives in describing the classes: • Static View: • describes the attributes and behavior of a class and • relationships among classes • Dynamic View: • describes the communications, controls, states, and state changes among classes • Restriction view: • describes the constraints in structure (e.g. limits in attributes) and the behavior

15. General - OO Development (cont.) • Requirements are collected in users’ “language” and within the context of the users’ domain, but the analysis of and the specifications may be performed using OO methodology - utilizing classes. • Design (System Level or High Level) • identify and represent classes and objects (attributes/behavior) • identify the relationships among classes • identify interactions among the classes • identify non-functional attributes such as security, performance, etc. • Design (Program and Module Level) • include specific computational algorithms and features • include class library details • consider non-functional attributes such as security, etc.

16. OO Requirements - using Use Case • A Use Case describes particular functionality that a system is supposed to provide. • It describes a dialogue that a user or an external system will have with the system. • It describes a scenario or a set of interactions between the user or external system and the system. • Capturing all the use cases from all the different perspectives give us the complete system’s requirements. • A Use Case diagram in Unified Modeling Language (UML) notation is made of the following: Use Case 1 Actor Use Case 2 Actor boundary

17. OO Requirements (cont.) - using Use Case • Each Use Case itself may be described in some pseudo language or in English statements: • interactions and functions • the data transferred • any performance, security, etc. non-functional requirements • UI looks • Once the use cases are done, one should review them: • are all the terminology used unambiguous, consistent, and understandable • do the activities match all the perspectives and complete • are the descriptions clear and correct; is there clear start and end to an activity • is there any extraneous information that is not involved with the system

18. OO Design - Classes and Objects • While one may argue that not everything has to be viewed as a class or an object, in OO the methodology a primary activity in design is to transform the Use Cases from requirements to a high level solution composed of Classes. • The definition of classes identify the important components of the solution • Identifying the relationships among the classes provide the “static”structure of the solution. • Identifying the interactions among the classes provide the “dynamic”structure of the solution

19. OO Design - Classes and Objects • Identifying the classes for the solution, which may have started as early as the requirements analysis phase. • There is no formal method to do this • some suggestions include looking at the “nouns” used in expressing the requirements (Think of the Library System, again - what may be the classes ? - books, students, faculty, etc.) • To show the “static structure” of the solution, the relationships of the classes need to be specified. • Associations - Generalization or subtype Lib-Items Check out students books 0…m 0…m books periodicals CD’s ….

20. OO Design - Classes and Objects • In defining a class, one is to think about : • name of the class • attributes of the class • behavior (functions or methods) • After some preliminary identifications of the classes and static relationships, the attributes and the behavior portion of each class may become “clearer” and thus modified. • What are the attributes that make sense for books and not for CD’s ? • Which attributes are inheritable from the “parent” class, Lib-items ?

21. OO Design - Classes and Object • More relationships of classes (Static Structure): • aggregations and compositions: • class A “has a” Class B and a Class or Class B and C are “parts of” class A • provides the design technique of “decomposition” and simplifying the design into parts. • For OO specific, think about inheritance & class composition • What’s the difference between aggregation and composition : very subtle and some people do not bother to differentiate • composition is “made of”; if Class A is made of classes B and C, then objects, y and z, from classes B and C are part of an object x of class A. Pages and cover are “parts of” a book. • aggregation is “has”; if Class A has Class B and Class C, then an object x of Class A has objects y and z from classes B and C. Library “has” shelves, books, CDs and librarians.

22. OO Design - Dynamic Structure • The Dynamic Structure of the Design shows the interactions among the classes : • classes involved in the interaction to accomplish a task • sequence of interactions among the classes • conditions under which the interactions occur • information needed for the interactions • The UML includes several notations for modeling the interactions and the Dynamic Structure of the Design • Sequence diagram • Collaboration diagram • State diagram • Activity diagram

23. OO Design - Dynamic Structure • Depicting the interactions among objects: • Sequence diagram • Collaboration diagram Class A Class B Class C Checkout-item( ) authorize( id ) Class A 1: checkout-item 4: checkout complete 2: authorize () Class B Class C 3: authorized

24. OO Design - Dynamic Structure • State Diagram: depicts the states the object may take on and the events that trigger the transition of sates • Activity diagram: depicts the flow of procedures within a class (object); almost like a flow chart Good status Continue checkout authorizing Give permission Legitimate person Illegitimate person Deny permission End Session Less than 3 trials more than 3 trials Verify id authorize OK? Yes Past due items No

25. OO Design - Other Components • UI : Screens, Reports, Query • use the appropriate tools to actually show the “visual” looks • use the class diagram to depict the attributes (input and display data) and the functions evoked. • Database : • transform the attributes that needs to persist beyond a session into the appropriate form that is storable and accessible through the chosen database (eg columns of tables for Relational DB)

26. OO Measurements • Why do we have measurements ? • Help us understand and assess what should be considered “good” • Help us understand and set goals • Help us evaluate status and assess if goals are met • Help us predict and project the future • Some Metrics: • Lorentz and Kidd • # of scenario scripts • # of classes and class size • Chidamber and Kemerer • wieghted methods in a class • depth of inheritance • lack of cohesion in methods • Li and Henry • message-passing coupling • data abstracting coupling