Object-Oriented Software Development

1. Object-Oriented Software Development Dr. Mao Zheng Department of Computer Science University of Wisconsin-La Crosse

2. Major Topics • Introduction to object-orientation • Procedural Vs OO • OO life cycle • Definitions and Concepts • Objects and Classes • Relationships among classes • Association, Aggregation, Generalization • Distinguishing Features of OO • Encapsulation, Polymorphism • Parameterization and abstraction • Transforming functional requirements to OO design CS 546 - OOSD

3. Major Topics (Contd…) • OOA/OOD notations • UML • UML in detail • Various views and notations in each view • Examples • Object-Oriented Programming • Language Features • Comparison of OO languages • Java, C++, Smalltalk, Eiffel, Visual Basic(?), C# CS 546 - OOSD

4. Major Topics (Contd...) • Advanced topics, if time permits • Object Constraint Language (OCL) • Object-Oriented Program Testing • Object-Oriented Software Metrics • Object-Oriented Databases • CORBA (Common Object Request Broker Architecture) • COM/DCOM CS 546 - OOSD

5. Procedural Approach Vs Object-Oriented Approach

6. Procedural Approach • emphasis on functions/tasks to be performed • global and local data • modular decomposition and composition • execution thread defined in terms of sequences of procedure or function calls CS 546 - OOSD

7. Procedural Approach - Example A grocery store sells a collection of items. Information about the items and prices are kept in a database. A customer purchases a set of items; a bill is produced for the items purchased; the bill also includes taxes (shown separately). For simplicity, it is assumed that the customer pays cash only. The system must display change, if any, after the customer pays. It also needs to update the stock after each purchase. CS 546 - OOSD

8. Procedural Approach – Example (continued) • Tasks to be implemented: • Add an item information to the database • Retrieve an item information while purchasing • Update the stock of the item being purchased • Compute the subtotal and tax, and also the total for a purchase. • Compute the change, if any, after a purchase. CS 546 - OOSD

9. Object-Oriented Approach • emphasis on objects involved • encapsulated functions and (sometimes) global functions • modular decomposition and composition • execution thread defined in terms of messages passed among objects • This is different from simple method calls in procedural paradigm CS 546 - OOSD

10. Object-Oriented Approach for the Example • Objects • Item, Database, Bill, Date, Grocery Store, … • Encapsulated Structure • Item • ID, description, price, quantity, … • Database • Collection of items • Bill • Date, collection of items, subtotal, tax, total, change, … CS 546 - OOSD

11. Object-Oriented Approach – Example (continued) • Encapsulated functions • Item • Change price, change quantity, … • Database • Store an item, retrieve an item, update an item, … • Bill • Compute tax, compute total, compute change, ... CS 546 - OOSD

12. Procedural Vs Object-Oriented • one is the dual of the other • both approaches capture more or less all the essential features of the end product • rigorous proof exists • emphasis and software development processes differ • generally, end users do not see the difference • Was “Windows XP” developed using procedural approach or OO approach? CS 546 - OOSD

13. Why do we use the Object-Oriented Approach? • encapsulated structures and localized behaviors • separation of concerns • easy to change/extend/maintain • promotes reuse – better reusability than the procedural approach • modularization visible CS 546 - OOSD

14. Introductory references on OO • G. Booch, “Object-Oriented Software Development”, IEEE Transactions on Software Engineering, Vol. 12, No. 2, Feb 1986, pp. 211-221. • G. Booch, Object-Oriented Design with Applications, Benjamin Cummings Publications, 1991. (Second edition: OO Analysis and Design with Applications, published in 1994). CS 546 - OOSD

15. Object-Oriented Software Life Cycle

16. Stages in OO life cycle • Requirements engineering • requirements gathering, analysis and specification • inherently procedural because customers describe what the software system is supposed to do • OO Design • architectural design • detailed design • both require the transformation of functional requirements into OO design elements • Implementation or Coding or Programming using OO programming languages and tools CS 546 - OOSD

17. Stages in OO life cycle (continued) • Testing • unit testing; test methods within each object • integration testing; test collaborations between objects • system testing; test the entire system as a collection of objects • acceptance testing; test for standards and customer satisfaction CS 546 - OOSD

18. Procedural and OO paradigms CS 546 - OOSD

19. Maintenance • fixing bugs, enhancements, adapting to changing environment • all the three activities require that some objects to be changed; easy to trace those objects • add developed classes to library of classes, if appropriate • generalization • (possibly) create patterns and frameworks • reuse CS 546 - OOSD

20. Spiral Life Cycle Model • a prototyping model used for OO software development • develop an initial set of objects (from the requirements document) • evaluate these objects against feasibility, risk, cost effectiveness, quality, etc. • modify the objects based on the evaluation • iterate the process until the product is finalized CS 546 - OOSD

21. References for spiral model • B. Boehm, “A spiral model for software development and enhancement”, IEEEComputer, May 1988, p. 61-72. • Pankaj Jalote, An Integrated Approach to Software Engineering (Second edition), Springer-Verlag, 1997. CS 546 - OOSD

22. Definitions and Concepts

23. Object • models of real-world entities • TV, VCR, Stereo system, … • may also represent program entities • array, queue, stack, linked list, … • may also be used to model fictitious entities • seminar, dream, … CS 546 - OOSD

24. Object (continued) • has structure and behavior • structure is identified by one or more data components • each data component is defined as a <name,type> pair • examples • A TV has a screen, connections, model, … • A stack has a sequence of items • A dream has a theme, duration, … CS 546 - OOSD

25. Object (continued) • behavior • operation that can be exercised on the object • switch the TV on – exercised on a TV object • Give/start the seminar - exercised on a seminar object • task performed by the object • display - performed by a TV object • count time - performed by a seminar object CS 546 - OOSD

26. Object (Continued) • objects can be composed to form a composite object • a TV object is composed of several component objects such as screen, connections, display unit, etc. • several seminar objects can be composed to form a course object • objects can interact with each other • a TV object can send a signal to a VCR object • a user object interacts with a seminar object to change the contents of the seminar CS 546 - OOSD

27. Object (Continued) • objects can be specialized • a TV object can be specialized into a projection TV object • a seminar object can be specialized into a colloquium object • objects can be generalized • TV objects, VCR objects and stereo system objects can be generalized into electronic system objects CS 546 - OOSD

28. Object (Continued) • objects are generally concrete and well defined • TV object, VCR object, seminar object, … • sometimes objects can be vague (with incomplete structure and/or behavior) • an object that corresponds to an understandable seminar or a seminar on a totally new topic • an object that corresponds to the internet CS 546 - OOSD

29. Question? • What characterizes an “object”? In other words, how do we identify an object from a problem description? • an object should possess at least a structure or a set of behaviors, preferably both • an object can be primitive and well-understood • an integer • an object can be complex and hard to understand/define • The internet CS 546 - OOSD

30. Object - Exercise 1 • Identify the objects in the following problem • A ticket counter in an unmanned parking lot issues tickets to the vehicles when they enter. It displays the time and charge when the ticket is inserted back into the machine while leaving. The machine also accepts bills and coins and returns change, if any. CS 546 - OOSD

31. Object – Exercise 2 • Identify the objects in the following problem • The Computer Science department wants to create a home page. This home page should provide links to all the faculty members’ home pages, to a list of course descriptions, to a list of job vacancies in the department, to the University home page and to the email address of the secretary, if someone wishes to contact the department. CS 546 - OOSD

32. Class TV Stack Seminar Objects Sony TV, Hitachi TV Stack of integers, stack of reals Kasi’s Seminar, Bill’s seminar Class and Objects A class represents a collection of objects who share similar structure and behavior CS 546 - OOSD

33. templates created/defined by programmers can be abstract one class represents a collection of objects actual structures with values (concrete) created by run-time system cannot be abstract each object belongs to exactly one class (traditional definition) Class Vs Object CS 546 - OOSD

34. class name serves as an identity (to be discussed later) static; serves as a source of definitions; possibly never be destroyed possesses an internal identity, generated by the run-time system dynamic; created and destroyed during execution; some objects may persist even after termination of execution Class Vs Object (continued) CS 546 - OOSD

35. A bit of Theory • classes are implementations of Abstract Data Types (ADTs) • an Abstract Data Type (ADT) is defined only by its behaviors without committed to any implementation • a TV ADT • a behavior: must display a motion picture • no matter what picture is displayed (color, black/white, sports, kids program, …) • a seminar ADT • a behavior: must have a topic and contents • no matter in what format CS 546 - OOSD

36. A bit of Theory (continued) • classes are implementations of ADTs • Why? a class has a structure, along with its behavior • The integer data type is an ADT • The integer class in OO has a representation and hence a limitation (32 bits, 64 bits etc.) • The stack is an ADT • The stack class has a structure; may use an array for implementation; has a limited size CS 546 - OOSD

37. A bit of Theory (Contd...) • interested more??? read “Object Calculus” by Abadi and Cardelli, 1996, Springer-Verlag. • we discuss a bit of type theory in OO later in this course (of course, only if you are interested!!) CS 546 - OOSD

38. Encapsulation • James Rumbaugh et al., 1991 • a mechanism by which external aspects of a class that are visible to or accessible by other objects are separated from the internal or implementation details of these aspects • Grady Booch, 1994 • a process of compartmentalizing the elements of an abstraction that constitute its structure and behavior • serves to separate the contractual interface of an abstraction and its implementation CS 546 - OOSD

39. Encapsulation- Examples • Class TV • external interface: • structural: size, type, model, price, connections,… • behavioral: display, picture-in-picture, send_signal, … • internal details: • structural: power, heat-dissipation, dimmer, … • behavioral: switch_mode, color_adjust, … CS 546 - OOSD

40. Encapsulation- Examples • Class Seminar • external interface: • structural: theme, contents, duration, … • behavioral: start, end, deliver, … • internal details: • structural: sequence of sentences, heading, … • behavioral: change topic, change contents, sort, … CS 546 - OOSD

41. Encapsulation - Exercises • Give the external interface and internal details of each one of the following classes: • Ticket counter in the Parking lot • Database • Player or parent, in your project CS 546 - OOSD

42. Encapsulation – a question • How to identify/characterize external interface and internal details? • needs application domain information and access restrictions • what seems to be an external interface for one person may be an internal detail for another person • levels of access restrictions • public, private, protected – terms used by C++ and Java • not just these; may be more CS 546 - OOSD

43. Encapsulation Vs Information Hiding • Encapsulation is a concept • Information hiding (how to) is a concretization process of encapsulation (what) • information hiding implements encapsulation • OO analysis deals with encapsulation • OO design and implementation take care of information hiding CS 546 - OOSD

44. Communication between Objects • objects communicate with each other or interact among themselves by message-passing • single thread of control - client-server mode of communication • client sends a message to the server indicating the request and the server sends the response back to the client through another message • requires that the client and server know each other • communication link established statically or dynamically CS 546 - OOSD

45. Communication (continued) • multiple threads of control • each object sends messages to one or more objects and continues to execute its own tasks • information shared through messages • each object should know the other objects with which it communicates • communication link established statically or dynamically CS 546 - OOSD

46. Communication (continued) • pre-defined / static communication links • designer / programmer knows / decides well in advance the links between the objects • explicit in the class definitions • inheritance, aggregation, association (will be discussed shortly) • dynamic communication links • decided at run-time • delegation (will be discussed later) CS 546 - OOSD

47. Communication – Example 1 • objects: a student and a course • communication link: static (association) • scenario 1: • the student object sends a request to the course object to check for availability of seats in that course • because the link is static, this communication must be explicit in the design / code CS 546 - OOSD

48. Communication – Example 1 (continued) • scenario 2: • the course object sends a request to the student object to update its information on the list of courses registered (after a successful registration process) • because the communication link is static, the information about this link must be available in the design / code CS 546 - OOSD

49. Communication – Example 2 • objects: two speaker objects • communication link: dynamic • scenario 1: • one speaker object raises a question and the other speaker object answers to that question • because the communication link is dynamic, the first speaker object does not (need to) know who the other speaker object is • example: teacher and student • example: a speaker in a seminar and a person from the audience CS 546 - OOSD

50. Communication - Exercises • Define a communication scenario between a driver object and a car object. • Define a communication between a file object and an editor object. • Define a communication between a stock object and an investor object. CS 546 - OOSD