1. Object Oriented Programming & Design - Abstraction Lecture 2 John Anthony RPI - Adjunct Assistant Professor Department of Engineering and Science

2. Topics What is Abstraction What is Abstraction The Lientz Study The Lientz Study Examples of Abstraction Examples of Abstraction Layered View of an Object Oriented Program Layered View of an Object Oriented Program Other Forms of Abstraction Other Forms of Abstraction Introduction to Abstract Data Types Introduction to Abstract Data Types

3. Abstraction A simplified description or view of something that emphasizes characteristics or purposes relevant to the user, while suppressing details that are immaterial or distracting. A simplified description or view of something that emphasizes characteristics or purposes relevant to the user, while suppressing details that are immaterial or distracting. Translated: focus on the what not the how. http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/glossary.html The most effective weapon that computing scientists have in their fight against complexity is abstraction. What is abstraction?

4. Remember Information Hiding? Certain details can and in many cases should remain hidden from the client… Why is this????

5. Part of the Answer… Bennet P. Lientz and E. Burton Swanson: Software Maintenance Management: a Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations, Addison-Wesley., Readinhg (Mass.), 1980.

6. Examples of Abstraction Abstracts of a research papers Abstracts of a research papers Maps Maps Virtual Memory Virtual Memory The relationship between a registrant for a Race and the Register (Active). The relationship between a registrant for a Race and the Register (Active). Java.lang.String (vs. array of bytes) Java.lang.String (vs. array of bytes) etc. etc.

7. Layered View of an Object Oriented Program Packages Service Classes Operations Decreasing levels of abstraction 1 n 1 n 1 n Program 1 n

8. Layered View - Services Decreasing levels of abstraction Service (Service Oriented Architecture) Services provide network addressable, loosely coupled, and stateless operations to consumers. Network Addressable – bound to a network address (URI) and (often) published to a registry for discovery. Loosely Coupled – services exchange data and are invoked using non-proprietary technologies. Services can also be composed into other services. Stateless – the execution of a Service N does not depend on the execution of Service N-1 or Service N+1. Packages Service Classes Operations 1 n 1 n 1 n Program 1 n

9. Layered View - Programs Decreasing levels of abstraction Program An object oriented program is a “community” of objects that interact in order to achieve a common goal. A program is the implementation of a service. Community of Objects – The interface of a program hides the complexity of the underlying number, types, and relationships between the objects. Application Programming Interface (API) User Interface Common Goal – the program and its underlying model should solve a problem or set of like problems. Packages Service Classes Operations 1 n 1 n 1 n Program 1 n

10. Layered View - Packages Decreasing levels of abstraction Packages Some OOP languages support the grouping of classes into packages. Packages provide a (logical) grouping of classes while providing mechanisms for certain classes and features to be package public and package private. Packages Service Classes Operations 1 n 1 n 1 n Program 1 n Package x Class A Class B Class C Client

11. Layered View - Classes Decreasing levels of abstraction Classes A class is a static representation of the data and behavior of a set of objects. The public interface of a class serves as a contract to the supplier. The interface should abstract the internal implementation details of the supplier from the client. Consider: public, friendly Note: Java supports the notion of inner and anonymous classes which provides yet another level of abstraction at the class level. Class AClass B ClientSupplier Packages Service Classes Operations 1 n 1 n 1 n Program 1 n

12. Layered View - Operations Decreasing levels of abstraction Operations The class level is concerned with what parts of the interface should be exported or made public. Abstraction considerations can be broken down into design-time and compile-time. Compile-time Access modifier (public, protected, private, friendly) Design-time Operation Name Operation Parameters Return Values (also know as functions) Class AClass B ClientSupplier Packages Service Classes Operations 1 n 1 n 1 n Program 1 n

13. Other Forms of Abstraction

14. Encapsulation & Composition Encapsulation - A technique for hiding information within a structure. Encapsulation - A technique for hiding information within a structure. Composition – A technique for building complex structures out of simpler parts. These techniques not only provides abstraction, it also supports interchangeability. Composition – A technique for building complex structures out of simpler parts. These techniques not only provides abstraction, it also supports interchangeability. higher levels of abstraction Computer Memory CPU Bus Control Unit ALU Registers Decoder Full Adder Logical Unit Not Gate And Gate OR Gate Redesigned And Gate

15. Composition Example Regular Expressions - A pattern of characters used to match against the same characters in a search. They usually include special characters, which represent things other than themselves, to refine the search. TextRegular ExpressionResult Catastrophiccatcat (0,3) Catastrophiccat.cata(0.4) Catastrophic[cbz]atcat(0,3) Catastrophic6([a-z]*[^5]\b)no match

16. Composition Example 2 Consider building a GUI in Java. Consider building a GUI in Java. Insert picture of GUI and highlight composition

17. Encapsulation & Composition (con’t) Public Part Secret Part Composition Encapsulation

18. Inheritance The property of objects by which instances of a class can have access to data and method definitions contained in a previously defined class (the ancestor), without the definitions being restated. The property of objects by which instances of a class can have access to data and method definitions contained in a previously defined class (the ancestor), without the definitions being restated. When designing a CPU, you’d like to be able to swap in and out different scheduling algorithms without having to build in special considerations into the CPU. Scheduler Operating System FCFSSJFRR higher levels of abstraction Partial implementation higher levels of specialization

19. Composition vs. Inheritance How do we know when to use which strategy? How do we know when to use which strategy? Apply the “is-a” and the “has-a” test. ComponentComponentStrategy CarEnginehas-a SquarePolygonis-a FCFS Scheduler Queue has-a OR is-a ????

20. Interfaces Interfaces can be separated from the implementation. Interfaces can be separated from the implementation. The interface describes the “what” and the implementation describes the “how”. The interface describes the “what” and the implementation describes the “how”. public interface Stack { public void put(Object o); public Object top(); … } public class ListStack implements Stack public void put(Object o) { list.add(o); } … } Interface Implementation

21. Cohesion and Coupling Cohesion – the degree to which components of a single software system (such as members of a single class) are tied together. Cohesion – the degree to which components of a single software system (such as members of a single class) are tied together. Coupling – the degree to which separate software components are tied together. Coupling – the degree to which separate software components are tied together. Design goal: Systems (objects) should be highly cohesive and loosely coupled.

22. Poor Cohesion public abstract class Policy { private List drivers; …. /** * @return Returns the drivers. */ public List getDrivers() { return drivers; } /** * @param drivers The drivers to set. */ public void setDrivers(List drivers) { this.drivers = drivers; } …………. }

23. History of Abstraction Mechanisms 33372376 35 377376 opcodeOperand1Operand2 Assembly Language integer addition integer subtraction memory locations

24. ADDIA, X SUBI B, X Commandvar1, var2 Assembly Language (with Assembler) integer addition integer subtraction pointers

25. Procedures & Functions First mechanism for reuse and information hiding. However, there were still problems… …. boolean locked = false; void lock() { locked = true; } void unlock() { locked false; }….

26. Modules Modules - divided the name space into public and private areas. Dr. David Parnas – father of modular design. "...it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others." …. private boolean locked = false; public void lock() { locked = true; } publicvoid unlock() { public void unlock() { locked false; }….

27. Abstract Data Types The notion of an ADT was driven by two important goals: The notion of an ADT was driven by two important goals: 1. The need to define new data types (beyond the primitives supported by the language). 2. The need to use the features of an ADT without being exposed to the underlying implementation. An Abstract Data Type (ADT) is an abstract specification that defines the data types and operations independent of the implementation.

28. Abstract Data Types (con’t) Every ADT must contain 4 paragraphs: 1. Types 2. Functions 3. Axioms 4. Preconditions

29. The Stack ADT The Stack class represents a last-in-first-out (LIFO) stack of objects. It extends class Vector with five operations that allow a vector to be treated as a stack. The usual push and pop operations are provided, as well as a method to peek at the top item on the stack, a method to test for whether the stack is empty, and a method to search the stack for an item and discover how far it is from the top.

30. Types The types paragraph lists the types introduced into the specification. The types paragraph lists the types introduced into the specification. This specification is about a single abstract data type Stack, describing stacks of objects of type Object. Stack [Object] Types

31. Functions The functions paragraph lists the operations applicable to instances of the ADT. The functions paragraph lists the operations applicable to instances of the ADT. push: Stack[Object]  Object pop: Stack[Object]  Object peek: Stack[Object]  Object empty: Stack[Object]  boolean Functions

32. The functions paragraph described the signatures of the functions but it did not define the functions. As such, we do not have a Stack (LIFO) yet. Functions (con’t)

33. Axiomatic Definitions Each axiom must hold for all instances s of type Stack and all elements x of type Object. Axioms For any x:Object, s:Stack[Object], A1: peek (push (x) ) = x A2: pop (push (x) ) = s A3: empty (new) A4: not empty (push(s, x)) A1: tells us that the top element of the stack is the last element pushed A2: tells us that removal of the top element returns the stack to the state it had before the last push A3: tells us that a newly created stack is empty A4: tells us that pushing an entity on a stack results in a nonempty stack

34. ??? Are we satisfied with our specification?

35. Preconditions Since ADTs may contain partial functions, preconditions are stated in order to avoid errors. The precondition of an operation is a logical assertion that specifies the assumptions about and the restrictions upon the values of the arguments of the operation. If the precondition of an operation is false, then the operation cannot be safely applied. If any operation is called with its precondition false, then the program is incorrect.

36. Preconditions (con’t) Preconditions pop (s: Stack [Object]) required not empty (s) peak (s: Stack [Object]) required not empty (s)

37. Complete ADT Specification of Stacks Stack [Object] Types push: Stack[Object]  Object pop: Stack[Object]  Object peek: Stack[Object]  Object empty: Stack[Object]  boolean Functions Axioms For any x:Object, s:Stack[Object], A1: peek (push (x) ) = x A2: pop (push (x) ) = s A3: empty (new) A4: not empty (push(s, x)) pop (s: Stack [Object]) required not empty (s) peak (s: Stack [Object]) required not empty (s) Preconditions

38. Implementing an ADT Public Part ADT Specification Secret Part choice of representation implementation of functions Types, Functions, Axioms, and Preconditions Vector public Object pop() { Object x = null; if(! empty()) { x = this.firstElement; this.removeElementAt(0); } else {…} return x; }