Software Solution for Engineers and Scientist Episode 10 pot

the abstract class ConicSection, which is also a subclass of GeometricalFigure. Observe that the interface, which is the Draw() method, is defined in the abstract classes (GeometricalFigure and ConicSection) and implemented in the concrete classes. We have used the C++ convention of equating the function to zero to indi - cate that the methods in the abstract classes are pure virtual functions and that no implementation is provided. Also note that virtual functions in the abstract and concrete classes are in italics. Figure 28.6 Classification of a Graphics Toolkit Since the concrete classes can be instantiated, we can create objects of Line, Rectangle, Circle, Ellipse, and Parabola. There can clearly be no object of the ab - stract classes ConicSection or GeometricalFigure since there can be no possible instantiation of these concepts. For these reasons abstract classes have no attrib - utes. We can now proceed to draw on the video display using objects. For exam - ple: 784 Chapter 28 GeometricalFigure ConicSection Line Rectangle Circle Ellipse Parabola x_start y_start x_end y_end thickness x_top_left y_top-left x_bottom_right y_bottom_right line_thickness x_coordinate y_coordinatet radius line_thickness x_coordinate y_coordinate x_semiaxis y_semiaxis line_thickness x_coordinate y_coordinate focus line_thickness Draw() Draw() Draw() Draw() Draw() Draw() = 0 Draw() = 0 Object: Attributes Line_A x_start = 10 y_start = 5 x_end = 40 y_end = 20 thickness = 0.005 Rectangle_A x_top_left = 5 y_top_left = 20 x_bottom_right = 25 y_bottom_right = 30 line_thickness = 0.010 Rectangle_B x_top_left = 30 y_top_left = 5 x_bottom_right = 45 y_bottom_right = 10 line_thickness = 0.030 Circle_A x_coordinate = 40 y_coordinate = 30 radius = 5 line_thickness = 20 Figure 28.7 represents these objects on the video display. Note that each object is identified by its name and preserved by its attributes. Also that there are two objects of the class Rectangle, one is designated as Rectangle_A and the other one as Rect- angle_B. The fact that there are no objects of the class Ellipse or Parabola means only that these classes have not been instantiated. Figure 28.7 Objects Displayed Using the Graphics Toolkit The Object-Oriented Approach 785 Line_A Rectangle_B Rectangle_A Circle_A x y 10 10 20 20 30 30 4 0 In Figure 28.5 we notice that there is a type of conic curve, the hyperbola, that is not defined in the toolkit. The class structure in the object-oriented paradigm allows to later implement this subclass without introducing modifications to the existing code. The mechanics of how a library can be dynamically extended are discussed later in the book. 28.6 When to Use Object Orientation The fact that this book’s title includes C++ as a programming language does not mean that we assume that every programming project will benefit from an ob - ject-oriented approach. One advantage of hybrid languages, such as C++, is that they make object-orientation optional. Furthermore, in a hybrid language environ - ment we have the possibility of adopting some features of an object-oriented system while not others. For instance, we can design a program that uses classes and ob - jects without inheritance, or one that uses inheritance but not run-time polymor - phism. Or we may use some forms of inheritance and not others. In other words, the systems designer is free to decide how much object-orientation, if any, is suitable for a particular project. This is often a crucial and significant decision which may determine a project’s success or failure. 28.6.1 Operational Guidelines Object-oriented methods have permeated programming activities to such depth that sometimes we forget that its fundamental objective is to provide a model of the problem domain. In Figure 28.1 we showed programming as a bridge from a real-world problem-set to a machine-coded solution-set. In this representation of programming we see that the object-oriented paradigm emphasizes modeling the problem domain while structured programming models the solution domain. Modeling the solution domain facilitates the coding phase (which it approximates). Modeling the problem domain facilitates analysis. In one case we concentrate on the tail-end of the process and in the other one we concentrate on its start. By emphasizing the problem domain in the analysis phase we are able to achieve two undisputable benefits: first, we are able to analyze more complicated problems; second, the analyst can communicate better with the domain experts since many technical elements are removed from the model. However, these bene - fits are considerably dimished if the object-oriented model that results from the analysis has to be translated into the code of a non-object-oriented programming language. In spite of the claims made by some hard-core defenders of object-ori - entation, this approach is of doubtful advantage when it does not permeate the en - tire development process. Therefore, it is usually undesirable to perform object-oriented analysis and design of a project to be coded in a non-object-ori - ented language. Mixing models and development tools is usually a bad idea. Although in recent years the programming community appears to be favoring object-oriented methods, it is sometimes difficult to clearly ascertain the advan - tages of object-orientation over conventional structured programming for a par - ticular project. In order to make a valid judgment we would have to follow through a host of major software projects developed using both methods, mea - 786 Chapter 28 sure and keep track of the development effort, and critically evaluate the results. Even then, many subjective considerations would muddle our conclusions. In any case, we must not forget that the advantages of object orientation come at a high price in programming complications. Few will argue that object-oriented languages are more difficult to master and use, and that object-oriented analysis and design techniques are elaborate and complicated. The decision whether to use or not to use an object-oriented approach should be given careful consideration by the analyst. The following elements favor the use of object-oriented methods: 1. Projects in which modeling the problem domain is a major issue 2. Projects in which communication with domain experts can be expected to be a diffi - cult and critical part of the development activity 3. Volatile projects in which changes can be anticipated or in which frequent updates will be required 4. Projects with many elements with potential for reuse 5. Toolkits and frameworks are often good candidates fortheobject-orientedapproach On the other hand there are elements that often advise against object-orientation: 1. If the data structures and processing operations resulting from object-orientation are not compatible with existing data bases. In other words, it may be a bad idea to de- velop an object-oriented database management system if the newsystemforcesthere- design or restructuring of the existing databases. 2. If the project, or a substantial part thereof, must be developed in a non-object-oriented programming language. Thus, object-oriented methods may be of doubtful use in de- veloping a short, low-level device driver for a hardware accessory. 3. If the problem domain model is already well defined in non-object-oriented terms. 4. If the problem-domain is better expressed using a conventional, non-object-oriented model. Projects in which software elements are the subjects to be modeled sometimes fall into this category. In general, major business and industrial applications are suitable for object ori - entation, while small, technical, or support utilities are not. The Object-Oriented Approach 787 Chapter 29 Object-Oriented Analysis Chapter Summary Object-oriented programming is mostly a software design methodology. In this chap- ter we discuss the elements of object-oriented analysis which is the first and most im- portant step in the design of an object-oriented application. The topics include modelling the problem domain, decomposition into classes and objects, testing object validity, systems and sub-systems, attributes, services, instance and message connec- tions. 29.0 Elements of Object-Oriented Analysis It has been observed by several authors that both major software engineering para - digms (structured programming and object orientation) started with programming languages, were later extended to software design, and finally to analysis. This implies that the advent of a system analysis methodology marks the maturity of a particular paradigm. Regarding object-oriented systems we have seen that full-featured pro - gramming languages were already available in the late seventies and early eighties. System design discussions started at about that time, while the object-oriented analy - sis methodologies are a product of the late eighties and early nineties. Observe that the object-oriented approach to analysis does not attempt to replace every technique and tool of conventional system analysis. The feasibility study, risk analysis, and cost-benefit analysis can be performed independently of whether the project is modeled using structured programming or an object-oriented approach. Object-oriented analysis provides a practical methodology for project modeling dur - ing the analysis phase. Its purpose is to complement, not to replace. We mentioned in Section 3.6 that the analyst should critically evaluate if a project will gain from using an object-oriented approach. Also that the greatest benefits of the object-oriented paradigm result when the methodology permeates the entire de - velopment process. In most cases, our decision to use object-oriented analysis im - 789 plies that we will also follow object orientation in the design phase and that the program will be coded in an object-oriented programming language. Paradigm mixing is theoretically possible, and sometimes recommended by hard-core de - fenders of object orientation. However, regarding the smaller project, the compli - cations brought about by simultaneously using more than one model far outweigh the uncertain advantages. In particular regarding the smaller development pro - ject, it is our opinion that the decision to proceed with object-oriented analysis should presuppose that object orientation will also be used during the design and coding phases of development. In this chapter we follow Coad and Yourdon, although not very strictly. These authors are a principal force in the field of object-oriented analysis. In addition, their approach is elegant and simple. The Coad and Yourdon notation was de - scribed in Section 28.4. 29.0.1 Modeling the Problem-Domain One of object orientation’s principal characteristics, as well as its main justifica - tion, is that it provides a reasonable way of modeling the problem-domain. Other ad- vantages often mentioned are that it makes modeling complex systems possible, facilitates building systems that are more flexible and adaptable, and promotes re- usability. Object-oriented analysis is most useful in problem-set modeling. One of the predicaments of software development is that the programmer must become an expert in the domain field. Thus, someone contracted to develop an air-traffic control system has to learn about radar, about air-to-ground communications, about emergency response systems, about flight scheduling, and about a multi- tude of other technical and business topics related to the activity at hand. How much knowledge must the analyst acquire, and to what technical level must this knowledge extend, is difficult to determine beforehand. Many projects have failed because the developers did not grasp important details of the problem set. The urge to “get on with the coding” often works against us during this stage. Because the analyst needs to quickly understand the problem-domain, any tool that facilitates this stage of the process is indeed valuable. Once the analyst has grasped the necessary knowledge, then this information has to be transmitted to other members of the development team. Here again, any tool that assists in com - municating the knowledge is greatly appreciated. Finally, the model of the pro - posed solution-set must be presented to the clients or users for their validation, and to obtain feedback. A model that facilitates this communication between cli - ents and developers is an additional asset. 29.0.2 Defining System Responsibilities In addition to providing a model of the problem-domain, object-oriented analysis must define the system’s responsibilities. For example, the analysis of an air-traffic control system includes determining what functions and operations are within the system’s burden. Does the air-traffic control system have the obligation of inform - ing commercial airlines of delays in arrivals or departures of aircraft? How does the 790 Chapter 29 air-traffic control system interface with the emergency response system at the air - port? At what point does the tracking of an aircraft become the responsibility of a par - ticular air-traffic control system and when does this responsibility cease? A system’s responsibilities refer to what a system should do. Answering this question is one of the fundamental tasks of object-oriented analysis. Questions related to how a system op - erates are left for the design and coding phases. 29.0.3 Managing Complexity Analysis is necessary because natural systems are often so elaborate and complicated that they are difficult to understand or manage. Object-oriented analysis provides a toolset for managing complexity. This toolset is based on abstraction, encapsulation, inheritance, and message passing. Abstraction Abstraction consists of eliminating what is superfluous or trivial and concentrating on what is fundamental. Any definition is an exercise in abstraction. We can state that a fountain pen is a hand-held writing instrument that uses liquid ink, an ink discharge mechanism, and a fine tracing point. This description attempts to gather the funda- mental attributes of a fountain pen that distinguish it from a typewriter, a ball-point pen, and a pencil. However, it ignores the less important features such as the pen’s color, the color of the ink, the instrument’s exact dimensions, and its design or style. In the context of object-oriented analysis, abstraction refers to the class mecha- nism which simultaneously provides procedural and data abstraction. In other words, the object-oriented notion of a class is an abstraction that represents both processing and data elements of the problem set. Encapsulation Encapsulation is one of the fundamental notions of object orientation. In the ob - ject-oriented approach encapsulation is related to the notion of data and functions (at - tributes and methods) being packaged together by means of the class construct. Those methods visible outside the class are its interface. The principal purpose of en - capsulation is hiding the implementation details while stressing the interface. Inheritance In the object-oriented paradigm inheritance refers to the possibility of one class ac - cessing the public and protected members of its parent class. Class inheritance pro - motes the highest level of abstraction, reduces code size, and simplifies programming. The result is a class hierarchy that goes from the most general to the most specific. Typically, a derived class incorporates all the features of its parent classes and adds some unique ones of its own. Message Passing Object-oriented systems access processing functions by means of a mechanism called message passing. One of the disadvantages of hard-coded program structures such as jump tables, cascaded if statements, or case constructs, is that they must be updated with every program modification or change. The message passing mechanism, on the Object-Oriented Analysis 791 other hand, automatically directs execution to the appropriate member function. This functionality brings about two major advantages: first, we avoid introducing new defects into code that have already been tested and debugged. Second, a system can be expanded by supplying relatively small modules that contain the new func - tions. 29.1 Class and Object Decomposition The first discipline of object-oriented analysis is learning to think in terms of classes and objects. At this stage we must free our minds of concerns regarding algorithms, programming structures, or any other implementation issues. Our task during analy - sis is to model the problem-domain and to define the system’s responsibilities. Both of these purposes are accomplished by means of class and object decomposition. In this sense an object can be considered an abstraction of a discrete element in the problem domain. The object-oriented encapsulation is a matter of defining at - tributes and methods. An object is characterized by the possibility of its identity be - ing preserved by the system. Therefore each object must have a uniqueness that allows its identification. Every object belongs to a class of objects. A class is a description of a set of unique attributes and methods associated with an object type. An object is an in- stance of a class. An abstract class is a description of an interface which lacks im- plementation. Its fundamental purpose is to define an inheritance path. It is not possible to instantiate objects from an abstract class. Do we start modeling by thinking of objects or of classes? It is a matter of seman- tics, but, strictly speaking, an object is a run-time construct while a class is an ab- straction that groups common attributes and methods for an object type. Therefore it appears that we should think of object types or classes, rather than of possible instantiations. On the other hand, the mental concept of a class of objects requires that we visualize a typical object. For example, suppose we are attempting to model a system which uses a viewport window to display a text message. In order to de - fine the text message window type we must first imagine what the object would look like. Figure 29.1 shows what may be our initial visualization of a text window object. From the object’s visualization we can deduce the attributes and methods of the object itself and the class that represents it. For example, the screen location and the object size are defined by the start and end coordinates. The object also has a border thickness and a color. Its text attributes are the window’s title and its text. A control button on the top left corner of the object allows the user to erase the text message window. There are three methods associated with this object: one to dis - play the window, one to report its current status, and one to erase it. Using class di - agrams we can now represent the object type TextWindow to any desired degree of detail. The left-hand diagram in Figure 29.2 merely states that there is an object class named TextWindow, while its attributes and methods are yet undefined. The diagram on the right shows the specific attributes and methods. 792 Chapter 29 Figure 29.1 Visualization of a Text Window Object Figure 29.2 Class Diagrams for a TextWindow Object During classification it is common practice to make the class name a singular noun or an adjective followed by a noun. It is also a good idea to use the client’s standard vocabulary when naming classes. Suppose we are modeling a home alarm Object-Oriented Analysis 793 x y 10 10 20 20 30 30 4 0 Window title Text message close window button start point coordinates end point coordinates thickness color TextWindow TextWindow start_x start_y end_x end_y color thickness window_title text_message status DrawWindow() ReturnStatus() EraseWindow() [...]... a second site in South Dakota receives this raw data and reformats it into specific image files, which are then transmitted to a third site in California which distributes the image files to the system clients In this case the New Mexico, South Dakota, and California sites perform different functions and could therefore be considered as candidates for classification Another example: the quality control... warnings that sound when a security breach is detected, switches for enabling and disabling the system, and input/output hardware such as a keypad for entering passwords and displays for echoing input and reporting system status In this case the devices and mechanisms that are within the system’s responsibilities are all candidates for classification In the case of the burglar alarm Object-Oriented Analysis... various subsystems 2 A layer for each subsystem indicating inheritance in the form Gen-Spec and Whole-Part structures 3 A layer showing attributes and services for each class 4 A layer depicting instance and message connection for each object In addition to the class and object diagrams, other documents are usually associated with the analysis phase, namely: 1 A description of class and object specifications... 29 system with a rather elaborate video display and command control For historical reasons the client calls the video display and command control a “push-button panel.” During analysis we may be tempted to rename this element so that its designation describes its actual functionality more exactly Clearly the term “command console” would be more forceful and descriptive than “push-button panel.” However,... make it a standard practice to request a detailed document from the client This document should identify the system and its purpose to the greatest possible detail 29.1.2 Neat and Dirty Classes In some contexts classification is a clear and neat process, but not in others When conceptual objects correspond to real-world objects the classification process is often simple and straightforward For example,... unsatisfactory, and the classes themselves will be untidy and unreal What happens is that this is probably one of those cases, mentioned in Section 3.6, that is best handled outside of object orientation 29.2 Finding Classes and Objects The skills of an object-oriented analyst include the individual’s ability to locate objects and to derive valid and useful classifications In this respect there is no substitute for. .. 29 .10 Compound Structure 29.2.2 Looking at Mechanisms and Devices Another element of the search for classes and objects is the location of mechanisms and devices within the problem domain For example, in modeling a burglar alarm system we may notice that it includes devices such as sensors to be placed in possible entry points, audible warnings that sound when a security breach is detected, switches for. .. system should not be searching for air-traffic control objects Instead, the first step should be an attempt to understand the system’s fundamental characteristics It is futile to attempt to identify objects and classes in a technology that is unfamiliar The following are the main sources of information about the problem domain: 1 Published materials and the Internet 2 First hand observation 3 Consultation... Organizational Units Organizations are divided into units that perform different tasks and assume distinct responsibilities within the system At modeling time these organizational units are also strong candidates for classification For example, a manufacturing division includes departments called engineering, production, quality control, and shipping These organizational units should be considered as... Once we have developed a basic classification scheme for the problem at hand it is a good idea to challenge its validity and soundness There are certain requirements usually associated with objects which can serve to test their legitimacy and significance In challenging proposed classes and objects the following questions are pertinent: 1 Is there information that the system needs to remember regarding . breach is detected, switches for enabling and disabling the system, and input/output hardware such as a keypad for entering passwords and displays for echoing input and reporting sys - tem status can deduce the attributes and methods of the object itself and the class that represents it. For example, the screen location and the object size are defined by the start and end coordinates. The. point coordinates thickness color TextWindow TextWindow start_x start_y end_x end_y color thickness window_title text_message status DrawWindow() ReturnStatus() EraseWindow() system with a rather elaborate video display and command control. For historical reasons the client calls the video display and command control a “push-button panel.” During analysis we