CS 2704 Object Oriented Software Design and Construction May 2, 2019 Design Hierarchy Is design important? 75%-80% of system errors are created in the analysis and design phases. Analysis and design phases account for about only 10% of the overall system cost. (Perhaps you get what you pay for.) Only about 25% of software projects result in working systems. The development process culminates in the creation of a system. First we describe the system in terms of components, and describe those components in terms of sub-components, and describe those . . . This process requires applying the concept of abstraction, hiding details of components that are irrelevant to the current design phase. The process of component identification is top-down, decomposing the system into successively smaller, less complex components. This must be followed by a process of integration, which is bottom-up, building the target system by combining small components in useful ways. Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms

CS 2704 Object Oriented Software Design and Construction May 2, 2019 Procedural Paradigm Key thought is to group highly related code into functions, which are limited to a single task or tightly related set of tasks, and limited in length (say to 25-50 statements). Emphasizes operations over data. Apply procedural decomposition: divide the problem into a sequence of simpler sub-problems to be solved independently. The resulting program will consist of a sequence of procedure calls. The designer thinks in terms of tasks and sub-tasks, identifying what must be done to whom. The key idea is to identify simple, constrained tasks which are easy to implement. Traditional procedural languages: COBOL, FORTRAN, Pascal, C Design notations: structure charts, dataflow diagrams Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms

Problems in Procedural Development CS 2704 Object Oriented Software Design and Construction May 2, 2019 Problems in Procedural Development Requires hefty communication (parameters) between functions. Difficult to track changes to data when maintaining or modifying. Creates high dependence between functions. coupling: amount of dependence between sections of code/data storage cohesion: degree of relationship (binding) of internal parts of a function The result is a large program consisting of many small procedures. There is no natural hierarchy organizing those procedures. It is often not clear which procedure does what to what data. Control of which procedures potentially have access to what data is poor. These combine to make it difficult to fix bugs, modify and maintain the system. The natural interdependence of procedures due to data passing (or the use of global data, which is worse) makes it difficult to reuse most procedures in other systems. Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms

Some Software Engineering Goals CS 2704 Object Oriented Software Design and Construction May 2, 2019 Some Software Engineering Goals Reusability is limited in procedural programming by identifier name collisions. Extensibility is limited by the lack of a uniform way to specify the interface to a code "module". The overall organization of procedures is usually not clear; communication issues are scattered throughout the design and implementation. Reusability develop components that can be reused in many systems portable and independent "plug-and-play" programming (libraries) Extensibility support for external plug-ins (e.g., Photoshop) Flexibility design so that change will be easy when data/features are added design so that modifications are less likely to break the system localize effect of changes Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms

CS 2704 Object Oriented Software Design and Construction May 2, 2019 Modular Programming Module – separately compiled unit Access control: public stuff in header, private stuff in implementation file Produces systems with stronger cohesion and looser coupling (vs procedural approach) due to localized organization of functions and related data in modules. Restricts data access to module functions. Hides implementation details from module user. Think about the standard headers, like cmath. This is a relatively simple extension of the purely procedural approach. Data and related procedures are collected in some construct, call it a module. The module provides some support for hiding its contents. In particular, data can only be modified by procedures in the same module. The design process now emphasizes data over procedures. First identify the data elements that will be necessary and then wrap them in modules. Typical languages: Ada 83, Modula Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms

Problems with Modular Programming CS 2704 Object Oriented Software Design and Construction May 2, 2019 Problems with Modular Programming Information hiding: user of module does not know how an operation has been implemented. Encapsulation: access to data is restricted to module by language rules Provides for easy upgrades since implementation can be changed w/o breaking interface. Does not support instantiation (multiple instances) --- consider supplying multiple stacks via a module. Modules do solve most of the (noted) difficulties with procedural programming. Modules do allow information hiding. But, you only have encapsulation if data of type is stored in a module. It is more natural (we claim) to think of the data as the fundamental thing. There are copy issues. . . Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms

Object-Oriented Paradigm CS 2704 Object Oriented Software Design and Construction May 2, 2019 Object-Oriented Paradigm A class is basically an ADT but now (vs modules) access restrictions and instantiation are provided with better support. A class is a generalized object (blueprint, factory). C++ is not a pure OO language, like Smalltalk or Java (so of course it's superior ;). Think of building the system from parts, similar to constructing a machine. Each part is an object which has its own attributes and capabilities and interacts with other parts to solve the problem. Identify classes of objects that can be reused. Think in terms of objects and their interactions. At a high level, think of an object as a thing-in-its-own-right, not of the internal structure needed to make the object work. Typical languages: Smalltalk, C++, Java, Eiffel Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms

CS 2704 Object Oriented Software Design and Construction May 2, 2019 Why Object-Oriented? Objects execute procedures on themselves, rather than having a procedure executed upon them. That reduces interface complexity (class scoped data is not passed to member functions). Identifier names need only be unique within the class, not across a wider scope. Object contents are encapsulated, accessible only via the public interface, and that is enforced at the language level. Tends to localize code changes. Localization of operations results in a loosely coupled, strongly cohesive design. First of all, OO is just another paradigm. Any system that can be designed and implemented using OO can also be designed and implemented in a purely procedural manner. But, OO makes some things easier. During high-level design, it is often more natural to think of the problem to be solved in terms of a collection of interacting things (objects) rather than in terms of data and procedures. OO often makes it easier to understand and forcibly control data access. Objects promote reusability. Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms

CS 2704 Object Oriented Software Design and Construction May 2, 2019 Dirty Secrets Methods are executed by one object sending a message request to another object (in a pure OO system). Request asks the target object to perform some service (execute a operation upon itself). How the request is carried out is unknown to the sending object. OO provides an easy mechanism for defining multiple instances of a class. OO systems are a "dynamic network of interacting objects". Good imperative/procedural programming principles apply to OO methods. . . . . . and to the surrounding procedural code in C++! ----------------------------------------------------- Example: think of a cylinder in an engine Procedurally I have to figure out how to: get the gas to the right place ignite the gas capture the released energy transmit that to the engine's main shaft OO-wise: I have a cylinder, valves, piston, piston rod, connectors, etc… Which is more natural? Objects must interact. Those interactions are achieved via object methods, which are just procedures. Procedural decomposition still applies, but the procedures themselves are more tightly bound to the data. The system (in operation) is still just a sequence of procedure calls. But. . . we think of the system as a collection of interacting objects. Computer Science Dept Va Tech January 2002 ©2000-2002 McQuain WD & Keller BJ Design Paradigms