Ch8BusinessIntelligence.pdf

OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

A popular adage says that software is not written, it is rewritten. In other words, software is not static but rather is updated, modified, or corrected over time. While the saying refers to standard transaction applications, it is even more applicable to the design of DSS. Decision support system applications need to change over time because decision makers change their information needs over time. Similarly, the process of evolutionary design of DSS, which recommends building a DSS in stages so that it better fits the needs of decision makers, requires systems to change over time. Hence, it is apparent that whatever product1 is chosen for the building of a DSS, it must be one that adapts well to change in the databases accessed, the models used and integrated, the way in which mail is used in decision making, and even the user interface. In order to meet decision-making needs, especially in a competitive and dynamic environment, such changes need to be implemented quickly with a minimum of flaws. The question is what kind of tool will best meet those changing needs.

Many demonstrations suggest that object-oriented programming (OOP) tools provide the best groundwork for systems that will need to be changed over time. The evidence suggests, in particular, that it is easier to make needed changes, to prevent unwanted changes, and to program more quickly with OOP tools than with other forms of systems development. While there is insufficient experience in operational systems to test this theory from a long-term perspective, there are some reasons to believe the hypothesis might be true. This chapter will illustrate the strengths of the object-oriented paradigm and how it might be used to design DSS.

!The product may be a programming language or a programming tool. For the purposes of this discussion, no distinction will be made between these two.

OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

KINDS OF DEVELOPMENT TOOLS

The obvious questions are "Why object-oriented tools?" and "Why object-oriented tools nowT The fundamental answer is that these tools provide a platform for faster development and maintenance because of the style of programming and the emphasis on reusability of code. To explore that answer fully, however, we need to cover two issues: (a) why other tools are less appropriate and (b) what makes object-oriented tools appropriate.

Non-Object-Oriented Tools

Programmers select languages and tools that allow them to leverage scarce resources while best meeting the users' needs. In the early days of computing, programmers used machine code, and later assembler code, to leverage the power of the available hardware. In other words, the available computing power was so minimal (in comparison to today's computers) that programmers chose languages that required the computer to do the least amount of interpretation, thereby allowing maximum computing power to be put on the task at hand. However, programming in this way is difficult, especially if the application is the least bit demanding. Later, as computers gained in capability and corporate computing needs focused on accounting, inventory, and other transaction-based programs, programmers selected tools that excelled in repeated operations on numbers; the preferred software technology was procedural, such as that represented by BASIC or COBOL.

Since these tools represent the foundation of the greatest percentage of operational code, they should be considered for DSS design. Using procedural tools, programmers provide a set of instructions the computer must follow each time the program is invoked. The code might provide points for branching, but the fundamental routine of instructions is the same each time the program is run. A good program is one that is structured, because such programs are easily maintained and more likely to work reliably. This means that there is a primary routine through which data must flow each time the program is invoked which calls all other routines. All the routines in the program must follow one of the three basic control structures: sequence, iteration, or alternation. Hence, all users "enter" the program through the same route and all users "exit" the program through the same route. Simple programs are quite easy to write using procedural tools, but more complex programs are quite difficult to write. More important, though, is that sophisticated programs (such as those necessary for DSS) are difficult to maintain.

Procedural programming is in use because it has provided an adequate methodology for accomplishing repetitive and straightforward tasks that do not change substantially over time. For example, such programming tools form a reasonable basis for developing payroll systems because there are certain procedures that must be done each time a pay check is issued. When the tax rules change, some of those procedures change, but even then it is a minor type of change to the system.

Suppose, instead, that we are programming the task of running a major corporation. The task in one meeting might be simple arithmetic while in another meeting it could be assembling project teams. It is easy for humans to see that the concept of "addition" is the same whether we are adding two numbers to get a sum or adding two employees to make a list. However, in a computer routine, it is difficult to substitute "Jawarahal Nehru" and "Pocahontas" for the numbers "three" and "five." The result of the computer operation in the first case is a list including the names Jawarahal Nehru and Pocahontas. The result of the second operation is a number (the sum of eight). To humans, both processes are addition, and it is a minor logical change to process the two examples. For the computer code, on the

KINDS OF DEVELOPMENT TOOLS

other hand, this is a major difference in operation, and we must make substantive changes in coding to accommodate the different processes. In fact, even the minor screen changes to display the differences in information can cause major programming needs.

In addition, programmers develop most procedural applications in a vacuum. Each programming effort begins from scratch, with little or no reliance upon the other systems that have been developed over the years (unless the new code must interface with existing code). Each designer and programmer has peculiarities to their own approach, and so each program provides its own set of problems and own maintenance needs over time. Completed separately, there is no opportunity to fix multiple programs at once and no opportunity to learn from one's past experiences. Maintenance, including correcting earlier mistakes and making enhancements and changes, takes time and money. Most MIS shops are so overwhelmed with application needs that they cannot respond to needs for changes and updates in a timely fashion, and most procedurally written programs are so complex that end users cannot change them. Such an environment does not provide either the reliability needs or the implementation speed necessary to respond to decision-making needs. Furthermore, it contributes to the high cost of systems development and thus of computing costs.

While most existing programs are procedural, other kinds of programming tools might be considered for DSS. For example, declarative programming provides a more fundamental approach to programming, but it is also a much more complex programming environment. The programming effort was to develop a logic base for the problem under consideration in environments such as Prolog or LISP. To run the program, a user provides the system all the information known, and then the system attempts to use its logic base to form a conclusion. Clearly these tools could provide solutions to complex problems. However, when introduced, they required specialized machines or were resource intensive and caused problems in conventional media. The hardware available at that time did not support such languages well and most corporations abandoned them to "special projects."

However, some declarative tools evolved into "access tools." In access-oriented pro-gramming, changes in the values of some fields can cause procedures to be invoked. This may mean that some flag or counter has changed value so that expected procedures happen, such as counting the days in a week and issuing paychecks on the last day. Or it may mean that some new information has been made available to the system and that its availability causes programs to run. For example, suppose the system waits to perform a pre-scheduled analysis until data are available from all plants at an organization. Hence, when the data are sent electronically and retrieved by the system, it automatically "knows" to begin running the reports. Finally, it may mean that a value of some variable has changed unexpectedly, triggering specialized procedures that bring this information to the attention of the human decision maker. For example, a DSS designed to trade stocks and bonds might bring a suggestion of action to the decision maker when unusual or unexpected changes happen in the marketplace.

This access programming clearly is different from procedural programming, which requires users to begin at the top and move systematically and predictably through the code. Access programming tools are better suited to DSS needs because they provide exactly the kind of response to changes that managers make and that DSS therefore need to support. Current technologies require such programs to be rewritten each time a new application is created. However, when presented with object-oriented code as hybrid code, access programming provides an excellent medium on which to build a system to provide support for decision making.

To review, there are several problems with using non-object-oriented tools for DSS development. The main ones are that the resulting systems generally take too long to be

352 OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

created, have specialized maintenance needs, and need to be rewritten each time a new application is created. Instead, a good environment is one in which the DSS is created quickly using known, reliable components of code from other systems where appropriate and that provide a seamless interface among applications. These attributes can be achieved through object-oriented tools.

Object-Oriented Tools

Object-oriented programming, as the name suggests, revolves about the definition of ob-jects. Objects, or, as they are sometimes called, classes of objects,2 are components or ingredients that are of importance to the system. They can be identified by naming all the "real-world" things of interest, all the general groups of items, or all the abstract nouns describing items of interest to the system. Objects can represent individual items or groups of items.

Defining Objects. As we have said, we can identify objects by analyzing the char-acteristics of the problem under consideration. In doing this, designers must recognize all relevant tangible objects. In addition, they need to catalog all roles relevant to the decision task (including the operations performed or the roles played by individuals), interactions (in terms of either personal contact or transactions), important events, specifications, and all incidents of importance to the decision task. It is also useful to identify devices with which the system or its users need to interact, locations, and organizational groups.

It is best to begin the identification of classes with the simplest view of the system. For example, in the car-purchasing system discussed earlier in the book, we might define the classes of "consumer," "automobile," and "acquisition strategy." Clearly there are people who will use the system, automobiles that will be described in the system, and strategies for acquisition that will be recommended by the system. In addition, there is a fourth class of importance, the automobile database. While the database itself describes information about the automobiles, the database object describes how the information about cars is maintained, accessed, and updated. Hence, the database needs to be defined as a separate object, with additional attributes in need of identification.

Figure 8.1 illustrates these four basic objects3 and their relationships within the basic car system. In particular, it notes that consumers acquire automobiles, secure acquisition

2 At this time, the terminology is not consistent among authors and among computer package imple-mentations. Some authors and some packages use the terms "object" and "class" interchangeably. However, in some languages, such as C++, class is the description of the entity. For example, the definition of possible attributes of a bicycle being style, manufacturer, number of speeds, color, and so on, is referred to as a class, while a specific example of the class, say Larry's bicycle, is referred to as an object. Hence, authors who use C++ (or a similar language) in their examples (or simply who are most familiar with C++) will use terminology consistent to that language. In other environments, the definition of possible attributes is referred to as a class but a specific example of the class is referred to as an "instance." Similarly, authors using such packages may use the terms in a manner consistent with that usage. Here, we will use the terms interchangeably. However, the reader is encouraged to be cautious when moving to other authors or packages as they may use the terms differently. 3This is meant to be an example of object definition. It is not intended to be an exhaustive search for all relevant objects for the purpose of the system. Similarly, the reader should not assume that the remaining sections on attributes and inheritance provide a complete view of those aspects of objects.

KINDS OF DEVELOPMENT TOOLS

Search Customer Secures

Automobile database

Acquisition strategy

Automobile

Figure 8.1. The classes and their relationships.

strategies, and search the automobile database. Similarly, it states that automobiles must qualify for particular acquisition strategies and that the automobile database describes possible automobiles. Hence, Figure 8.1 provides a basic understanding of how the system will work. Said differently, this figure provides the basic explanation for the messages that will be sent between pairs of classes.

Complete and accurate object definition is crucial. While it seems simple enough to define all of the tangible aspects of a problem in terms of objects, most individuals think about applications procedurally, not as objects, and so it is difficult to find all the relevant objects. This problem is exacerbated for programmers who are not familiar with the business since, as we saw from the literature reviewed in Chapter 2, the tendency to think procedurally is more pronounced for individuals inexperienced with the task at hand. Of course, the systems developer is likely to be inexperienced with the task for which the system is created, and hence the problem is exacerbated. While he or she may identify the major categories of objects, less obvious objects, as well as systems-based objects such as forms, databases, or approvals, may be overlooked.

It is necessary therefore to think of other rules that facilitate the identification of objects in a system. First, the object definitions must provide a template for classifying and organizing all information about an application. If all objects are defined, and defined properly, then DSS designers should be able to define all operations and procedures specified by the decision maker with the defined objects. Relationships that cannot be specified with the available objects highlight the need for new objects. For example, suppose we had not specified "customer" as an object earlier. If the designer tried to explore relationships between the automobile and the customer's preferences for options, financial limitations or driving history without the customer object, he or she would easily confuse characteristics of a given automobile with characteristics preferred by the customer and hence find the resulting analysis and design impossible. Such situations would cause a designer to seek a new object, in this case, "consumer."

354 OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

Figure 8.2. Sample website.

Second, all items that are similar in nature should be grouped together. If there are too many unrelated objects that seem to have similar characteristics, the DSS designer should look for a new "superclass" that joins together such objects. This concept and its implications will be discussed shortly with regard to "inheritance."

Finally, the designer needs to remember that each part of the system framework is in itself an object. The examples in this book have been written using HTML and Javascript, sometimes accompanied by Cold Fusion. These are object-oriented tools. They have some objects that are built into the tool. For example, when considering a Web page, the window is an object. Similarly, the document that is displayed in the window is a document. A graphic is an object, as is a button, a frame, or a textbox. Each example of those objects is a specific condition of the object itself, referred to as an instance.

So, consider the very simple website shown in Figure 8.2. This consists of a number of objects. First, the window is an object; there is only one window showing, so there is only one instance of the object window. Similarly, the document (usually indicated by the URL) is an object, and there is only one instance of that object as well. A table is also an object. In this case, there are two tables, one across the top with the link information and one in the middle of the page holding the substance of the page. The browser needs to keep track of two instances of this object because they look different (e.g., one has a frame where the other does not); they appear at different places on the screen and include different numbers of cells and different information.

In defining objects, designers use an iterative approach followed by logical system design. When designing becomes difficult, designers return to the stage of object definition. In fact, some object-oriented programming platforms will create objects and their attributes automatically as they are used. The beauty of object-oriented programming, however, is that we can add new objects as needed without changing the available objects or code that has been written.

Attributes and Methods. Each class is a receptacle holding both data and instruc-tions for acting upon the data. The data provide information through which we can gain

KINDS OF DEVELOPMENT TOOLS

a better understanding of the object, its characteristics, and its behavior. Such information helps the designer understand the necessary specifications for the database management system as well as for the user interface and model management systems. The data must be specified so it is possible to enumerate values, define data types, or outline ranges of values they might assume. There are two kinds of information about the objects that must be kept, the attributes and the methods. Attributes represent the characteristics of the object defined in the system, whereas methods define both the messages understood by the object and the action implemented by the object as a result of the message.

For example, Montlick (1995, p. 2) defines a particular object, "Dog." The Dog class defines messages that "the Dog object understands such as 'bark,' 'fetch,' and 'roll-over.'" The method defines the action taken as a result of the message. The method may be stated simply or may include multiple arguments to convey the requisite information. Montlick continues his example with the message "roll-over," which "could contain one argument to say how fast and a second argument to say how many times" (Montlick, 1995, p. 2). Different instances (or actual occurrences) of objects may implement meth-ods differently. For example, one instance, say "Spot," may go to sleep after receiving the message "roll-over," while another instance, say "Atlas," may roll over three times quickly.

Let us return to the consideration of a window as an object. Table 8.1 shows the attributes of a window (and its subcomponents) that are built into a browser. The page has a top, height, and width that locate it on the page. It has a location that describes where it is. The document within the window has a URL, a date it was last modified, a page that referred it, and a title. These are all attributes of the window (and docu-ment within the window). When we create a Web page, we are either defining each of those attributes or allowing the individual viewing the page to define those attributes. You could, however, also change any of those attributes via Javascript. For example, suppose your Web page has one link for new customers and another for established customers, such as is shown in Figure 8.2. You could set the status line to change depending on whether the mouse moved over the link "new customers" or "established customers" by taking advantage of the "status" attribute of window (and some methods not yet discussed).

Notice that when we use these attributes we use the form of the object "dot" attribute. So, it is window.status (read, the status of the window) to be clear as to the object the attribute of which is being set.

<A HREF="newcustomer.html" onmouseover= "window.status= 'Welcome to our system!'; return true" onmouseout= "window.status = 'We are glad you stopped by . . .we hope

to make you part of the family!'"> New User</A> or <A HREF="veterancustomer.html"

onMouseOver= "window.status= 'Welcome Back! We appreciate your business'; return true"

onmouseout= "window.status = 'Check out our specials!'"> Experienced User</A>

356 OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

Table 8.1. Properties of the Object "Window" (and Subobjects) available in HTML and XML

closed defaults tatus document

body cookie domain lastModified referrer title URL

history length

length location

hash host hostname href pathname port protocol search

name opener outerHeight outerWidth pageXOffset

pageYOffset

parent personalbar

scrollbars self status statusbar toolbar top

Returns whether or not a window has been closed Sets or returns the default text in the status bar of the window document

Gives direct access to the <body> element Sets or returns all cookies associated with the current document Returns the domain name for the current document Returns the date and time a document was last modified Returns the URL of the document that loaded the current document Returns the title of the current document Returns the URL of the current document

Returns the number of elements in the history list Sets or returns the number of frames in the window

Sets (or returns) the URL from the hash sign (#) Sets (or returns) the host name and port number of the current URL Sets (or returns) the host name of the current URL Sets (or returns) the entire URL Sets (or returns) the path of the current URL Sets (or returns) the port number of the current URL Sets (or returns) the protocol of the current URL Sets (or returns) the URL from the question mark (?) Sets (or returns) the name of the window Returns a reference to the window that created the window Sets (or returns) the outer height of a window Sets (or returns) the outer width of a window Sets (or returns) the X position of the current page in relation to the upper left

corner of a window's display area Sets (or returns) the Y position of the current page in relation to the upper left

corner of a window's display area Returns the parent window Sets whether or not the browser's personal bar (or directories bar) should be

visible Sets whether or not the scrollbars should be visible Returns a reference to the current window Sets the text in the status bar of a window Sets whether or not the browser's status bar should be visible Sets whether or not the browser's tool bar is visible or not Returns the topmost ancestor window

Source: Adapted from W3 Schools, http://www.w3schools.com/htmldom/dom_obj_window.asp. The list is reprinted with permission.

As said previously, in addition to attributes, objects have methods. These are messages to which the object can respond. A set of methods associated with the window and its associated subcomponents is shown in Table 8.2. As you can see from the list, these methods can change the window dynamically. One example that appears in Figure 8.2 is the documentation at the bottom of the page. The location of the Web page and the date of its last update take advantage of the attributes location and lastModified and the method,

KINDS OF DEVELOPMENT TOOLS 357

Table 8.2. Methods of the Object "Window" (and Subobjects) available in HTML and XML

Window Methods alert() blurO clearlntervalO clearTimeout() close() confirmO

createPopupO focus() moveByO moveToO open() print() prompt() resizeByO resizelbO scrollByO scrollTo() setlnterval() setTimeout()

Document Methods open()

close()

getElementByldO getElementsByNameO getElementsByTagNameO

write()

History Methods back() forwardO go()

Displays an alert box with a message and an OK button Removes focus from the current window Cancels a timeout set with setlnterval() Cancels a timeout set with setTimeout() Closes the current window Displays a dialog box with a message and an OK and a cancel

button Creates a pop-up window Sets focus to the current window Moves a window relative to its current position Moves a window to the specified position Opens a new browser window Prints the contents of the current window Displays a dialog box that prompts the user for input Resizes a window by the specified number of pixels Resizes a window to the specified width and height Scrolls the content by the specified number of pixels Scrolls the content to the specified coordinates Evaluates an expression at specified intervals Evaluates an expression after a specified number of milliseconds

Opens a stream to collect the output from any document.write() or document.writeln() methods

Closes an output stream opened with the document.open() method and displays the collected data

Returns a reference to the first object with the specified ID Returns a collection of objects with the specified name Returns a collection of objects with the specified tagname open() Opens a stream to collect the output from any document.write() or

document.writeln() methods Writes HTML expressions or JavaScript code to a document

Loads the previous URL in the history list Loads the next URL in the history list Loads a specific page in the history list

Location Methods assign () reload () replaceO

Loads a new document Reloads the current document Replaces the current document with a new one

Source: Adapted from W3Schools, http://www.w3schools.com/htmldom/dom_obj_window.asp. The list is reprinted here with permission.

358 OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

write. This method causes something to be written on the Web page when it first loads. The code that caused this to appear is as follows:

+ "<br>") // // This automatically updates the location documentation on the page. // document.write("URL: " + document.location) //

</script> <br>Page Owner: <a href = "http://www.umsl. edu/~sauter/">Professor Sauter</a> (<a href="mailto:[email protected]">[email protected]</a>)<br>

As with the previous example, the attributes are listed after the object. So, docu-ment.lastModified can be thought of as the date of modification of the document. The methods use similar notation. So document.write means to write on the document. Specif-ically, it is asking the browser to put the documentation of the last modification and the location of the page (with the identifying literals) on the page. If you change the page or change the name of the page, the directory in which it sits, or even the server, the documen-tation will be updated automatically. This can be combined with static HTML as shown, in the example, and the page viewer cannot tell the difference.

One can use these methods to have more impact on the system's behavior as well. Suppose that instead of changing the status line when a veteran user returns that you cause a new window to appear, such as shown in Figure 8.3. To cause this to happen, one needs to substitute the following code for that which was described earlier:

<SCRIPT LANGUAGE="JavaScript"> function windowOpen()

{ height=.5*screen.outerHeight width=.5 * screen.outerWidth startWidth= width+7 myWindow = window.open

("application.html","windowRef","top "width=" + width + ",height=" + height + ",top=0,left=" + startWidth + ",focus=yes");

} //–> </script>

<A HREF="newcustomer.html"

KINDS OF DEVELOPMENT TOOLS 359

onmouseover= "window.status= 'Welcome to our system!'; return true" onmouseout= "window.status = 'We are glad you stopped by … we hope to make you part of the family!'">

New User</A> or <A HREF="veterancustomer.html" onClick="windowOpen();return false">

Experienced User</a>

In this example, the method of the hypertext, "onClick," is used to call a user-defined function. This function, called "windowOpen," first uses the screen attributes "outerHeight" and "outerWidth" to measure the amount of space available on the screen. It then uses the method of window "open" to cause a new window to open. The function uses the various attributes of the window to specify the location and height and width of the window as well as the document that should be loaded in the window. This new document has definitions of what functions should be loaded and in what place.

The data used in the DSS can also be object based. Consider the class "automobile." It would have many attributes, including the manufacturer, model, size, and performance. These are the way that we describe and ultimately compare the automobile. These are shown in Table 8.3. Similarly, Table 8.4 provides the attributes of the class "automobile database." Notice that while some of the characteristics, such as those directly related to the specific automobiles, are the same as in Table 8.3 (the automobile attributes), other

Figure 8.3. Sample of using methods.

OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

Table 8.3. Attributes of the class "automobile"

Manufacturer Model Year Color Locking mechanism Wheels Windshield wiper types Option cost

Cruise control Moon roof Trim types Audio types Power locks Power windows Power outlets

Size Number of doors Trunk/cargo capacity Length Width Height Wheelbase

Performance Engine size Engine type Transmission type Mileage—city Mileage—highway Horsepower

Safety Airbag availability Braking system Stability control Crumple zones Steel body panels Trunk entrapment release

characteristics are unique to the physical repository in which the data actually reside. For example, the database filename and index filename refer to the actual location in which the DSS can find the data, not to the actual automobiles.

The goal is to define all attributes of interest in the system. As with the definition of objects, the DSS designer needs to ensure that all relevant characteristics important in forming relations are identified. If there are problems in addressing important questions, new attributes are needed. One of the advantages of object-oriented programming is that such attributes can be added later as they are needed without affecting the code written to that point.

The automobile database definition shown in Table 8.4 provides a similar example of methods being defined as a part of the class definition. The automobile database object "understands" messages to open, to protect, or to close the database. In addition, it can check for the end of file, advance a record, or append a record. The code needed to implement the message is embedded in the automobile database object. Systems do not need to search through code each time the message is referenced because it exists in a fixed place.

This relationship between methods and objects causes the instructions for what to do and how to do it to be part of the object itself, not separate from the object, as in a procedural language. For example, the code specifies how to search for the data, who has access to the data, and how errors are handled. The object definition reports everything necessary to use the database, including the fields, the type of data represented in the fields, the physical location of the database, and the available operators for the database. Since the operations are part of the definition itself, the object definition specifies how to make changes in the database.

KINDS OF DEVELOPMENT TOOLS 361

Table 8.4. Attributes of the class "automobile database"

Manufacturer Model Year Color Locking mechanism Wheels Windshield wiper types Option availability

Cruise control Moon roof Trim types Audio types Power locks Power windows Power outlets

Size Number of doors Trunk/cargo capacity Length Width Height Wheelbase

Performance Engine size Engine type Transmission type Mileage—city Mileage—highway Horsepower

Safety Airbag availability Braking system Stability control Crumple zones Steel body panels Trunk entrapment release

Database filename Database location Access rules Action rules End-of-file Record number Index file Active Status Error message Default error handling

Inheritance. Sometimes objects consist of major subcategories of instances that share specific attributes or methods not shared among all instances of the object. Consider again the automobile object defined earlier. While there are certain characteristics for all automobiles, such as those defined as attributes of the automobile class, there are other attributes relevant for only some cars. For example, knowing whether the automobile is new or previously owned dictates additional attributes and methods relevant to the object.

Similarly, within the class "acquisition strategy," there are multiple options, including "purchase outright," "purchase with a loan," and "lease." As with the class of automobile, there are some characteristics that join all three of these objects together and other char-acteristics that differentiate them. Finally, within the class "consumer," we can define the objects "first time consumer," "moderately knowledgeable consumer," and "experienced consumer." There is some information which the system will need about all consumers and some operations that will be done on all consumers. As you will see shortly, much of the art of object-oriented programming is in determining the best way to define classes and objects of those classes.

When examples of major subclasses exist, subobjects are defined with their basic definition inherited from the original definition of the object. That is, when the new object is defined, it will contain all attributes and methods from the original object (also known

OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

as a superobject). Programmers may then add additional attributes, additional methods, or both, but they may not change or delete the original, inherited attributes and methods.

Consider again the class of automobile. Table 8.3 outlines some of the attributes that are defined at the class level. All automobiles have those attributes, and so they should be defined when automobiles are defined. However, within the subclasses of "new automobile" and "previously owned automobile," there are additional characteristics that are not relevant in objects in the other subclass. By defining these two categories as subclasses of the object "automobile," they will inherit all attributes of automobile. That is, prior to any other definition, we would know that "new automobiles" and "previously owned automobiles" will both have all of the attributes listed in Table 8.3. If the name of an attribute is changed in, added to, or deleted from the definition of automobile, it will be changed in, added to, or deleted from the definition of new automobiles and the definition of previously owned automobiles automatically.

In addition, by defining these categories as objects, programmers can define other attributes that have meaning to all instances of the particular class. For example, consumers are interested in attributes such as the suggested retail price, the availability of particular options, and the estimated future value of the automobile for new cars only. The character-istics that vary across automobiles should be included. However, anything that is constant across all these cars should not be included. For example, in 1931, heaters and rear-view mirrors were considered options on new cars, and hence the definition of a 1931 new auto-mobile object would include the availability of a heater and the availability of a rear-view mirror as fields. However, heaters and rear-view mirrors have long since been adopted as standard equipment on all cars, and thus these fields should not be identified in today's new automobile object. An example of the kinds of items needed in the definition of the new automobile object is shown in Table 8.5; the shaded regions represent attributes inherited from the original automobile class.

Similarly, we can define attributes that have meaning to all instances of previously owned automobiles.Table 8.6 illustrates the attributes associated with previously owned automobiles, with the shaded regions representing the inherited attributes of automobiles. This object also inherits the attributes of the automobile object defined earlier. The pro-grammer is allowed to define characteristics unique to the condition of being previously owned, such as information about the car's age, its condition, the previous mileage, and other information that might suggest the automobile's condition.

We continue to decompose objects into smaller objects as the application dictates. If designers can gain some generalized information by decomposing an object, then they should do it. For example, suppose there are some major differences among the attributes that are relevant to new automobiles depending upon whether the "make" of the automo-bile is considered "luxury" or "sports" or "conventional." In this case, the designer might decompose the object "new automobile" discussed earlier by defining three subclasses, "new luxury automobile," "new sports-model automobiles," and "new conventional auto-mobiles." Through inheritance, each of these new objects would have all the fields of the original "automobile" object as well as those added when defining the "new automobile" object as well as further relevant fields added to each class.

Inheritance also allows the designers to avail themselves of the advantages of system-defined and system-based functions. For example, the definition of actions of any database is taken from a system-defined database. Hence, if the system were altered to enable new functionality, such as multiple indexing, it need only be defined in the system-level definition of the object database. Specific instances of databases, such as the automobile database, receive this update automatically because they inherit the system definition of

KINDS OF DEVELOPMENT TOOLS 363

Table 8.5. Attributes of the class "new automobile"

methods dynamically. That is, they not only inherit the characteristics available at the time of creation of the instance but also receive all the changes to the definition of the superclass as they are made over time.

Another example can be created by considering "windows" in a system. Suppose for a particular application the designer wants assistance pages that are consistent. However, the designer wants all of the statistical assistance pages to appear with the title "STATIS-TICAL ASSISTANCE" but all of the financial assistance pages to appear with the title "FINANCIAL ASSISTANCE." The designer could create a new object called "Assistance Window." The "Assistance Window" would inherit the characteristics of the system-defined class "Window." Hence, it would have the attributes of being visible or not (without calling it), whether it is sizable, movable, closeable, and so on, and its location and its size. At that level, the designer could specify the size, location, and other characteristics of importance

Manufacturer Model Year Color Locking mechanism Wheels Windshield wiper types Option availability

Cruise control Moon roof Trim types Audio types Power locks Power windows Power outlets

Size Number of doors Trunk/cargo capacity Length Width Height Wheelbase

Performance Engine size Engine type Transmission type Mileage—city Mileage—highway Horsepower

Safety Airbag availability Braking system Stability control Crumple /ones Steel body panels Trunk entrapment release

Standard packages/additional costs Wheels Radio Tires Transmission Safety Rear-window defogger

Option cost Cruise control Moon roof Trim types Audio types Power locks Power windows Power outlets

Purchase Information Suggested retail price Estimated dealer's cost Consumer's target price Destination charge Options cost

Estimated future value Expected resale in 5 years Expected maintenance costs—5 years Expected repair costs—5 years Owner's total cost

364 OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

Table 8.6. Attributes of the class "used automobile"

to the application. After said definition, the designer could create two subclasses, "Statisti-cal Assistance Window" and "Financial Assistance Window." Since these are subclasses of the "Assistance Window" object, they would inherit all the specified attributes and hence both the "Statistical Assistance Window" and the "Financial Assistance Window" would automatically have the size, location, and other attributes desired by the designer. The title, display, and functionality then could be specified differently for each window. If in a revision of the system the designer decided to resize or relocate the assistance windows, the change would only need to be done once, at the "Assistance Window" object level.

Models and model management functions also are identified as objects in an object-oriented DSS. These objects, like all objects, have attributes and methods associated with them and subclasses that inherit the properties of higher level classes. For example, we can use Geoffrion's (1987) structured modeling framework as the kernel of a model management system of a DSS. Designers would define superobjects of "models" and "solvers" that could be placed into libraries for use in a specific DSS. These classes would have attributes such as the five defined by Geoffrion (1987): primitive entity, compound entity, attribute, function, and test. As he defines them, they represent the basic foundation attributes of a model, the specific rules for processing the model, known constants, and ways of testing the models. In addition, the classes could have subclasses that inherit attributes from them. For

Manufacturer Model Year Color Locking mechanism Wheels Windshield wiper types Option Cost

Cruise control Moon roof Trim types Audio types Power locks Power windows Power outlets

Size Number of doors Trunk/cargo capacity

[ Length Width Height Wheel base

Performance Engine size Engine type Transmission type Mileage—city M i leage—h i gh way Horsepower

Safety Airbag availability Braking system Stability control Crumple zones Steel body panels Trunk entrapment release

Age of car Condition of car

Engine Outside appearance Inside appearance

Mileage attained on car Color Expected price Recall history Price

Original price Asking price Current wholesale Average retail

BENEFITS OF OBJECT-ORIENTED TECHNOLOGIES FOR DSS 365

example, we could trace the attributes of a linear programming model to its subclass, the transportation model, and, in turn, to its subclass the assignment model. At each level, the messages necessary for model management and solution simplification would be identified as a part of the object definition.

Facets. The attributes in turn have facets. These facets define the way in which the system should consider the attributes when no additional information has been provided. Of course, the relevant facets are a factor of what attribute of what object is being considered. If the object is a data-oriented object, relevant facets might include (1) the initial value, (2) the default value, (3) the search order for determining the value of the instance, (4) the methods for addressing unknown values, (5) the methods for addressing confidence in the information, (6) the display from which the system queries the user for information, and (7) the information provided when the user requests more information. On the other hand, if the object is a model-oriented object, one might specify the solution procedures or the model initial parameters. These facets allow the designer some control over how information is sought and used in relation to a particular object.

BENEFITS OF OBJECT-ORIENTED TECHNOLOGIES FOR DSS

As we review the tools available for designing and building DSS, it is important to restate the objectives of the process. In this case, there are two primary ones. First, once DSS are identified, they must be built well, but quickly, so that decision makers can glean the greatest strategic advantage from them. Second, once DSS are in place in an organization, they must be able to change quickly in response to changes in the decision makers' perspectives, tasks, and information preference.

The previous section has illustrated some of the benefits of object-oriented tools and some of the liabilities associated with other kinds of design tools. The argument for the object-oriented tools boils down to the potential to reuse code that can facilitate rapid development of systems as well as rapid adaptation of systems in use. Since objects include necessary code for implementation, programmers can reuse already available objects to perform the same functions across multiple applications. For example, Vayda Consulting company, on a project for Siemens Industrial Automation, let "MIS leverage the work of the best specialists" by developing a library of objects that were reused multiple times (Adhikari, 1995, p. 34). Further, object-oriented programming provides a similar but more powerful level of control over procedures. Since object-oriented tools isolate program functions and data characterization, designers and programmers can easily change one function without rewriting multiple aspects of the application. Thus, development and adaptation are made easier and faster. The Zurich Insurance company reduced the amount of time spent on coding and testing by one-half and the amount of time spent of integration of systems by three-quarters. Similarly, at the Federal Reserve, the designers completed an object-oriented project in two months that had previously taken a year using conventional procedural programming (Adhikari, 1995). If the object-oriented technologies can be married to the "access programming" defined earlier, resulting programs can mimic the decision maker's thought process and thus allow greater flexibility in use of the system.

There are, of course, some problems associated with development in object-oriented programming. These include compatibility of platforms and indexing of objects so others can find them. However, by far the biggest problem is for developers to learn to think in

OBJECT-ORIENTED TECHNOLOGIES AND DSS DESIGN

objects. Over time and with enough education and experience, however, these problems can be resolved.

Useful Links That Will Help You Around

Link to new order https://studentsolutionsusa.com/orders/stud/new

link to login page https://studentsolutionsusa.com/orders/login

New user registration link https://studentsolutionsusa.com/orders/register

Forgot Password https://studentsolutionsusa.com/orders/forgot/password

FREQUENTLY ASKED QUESTIONS

Question: How does this work?

Answer: Good Question. We are a group of a freelance board of students and professional essay writers. At our website, you may get help with any type of academic assignments: essay, coursework, term paper, business plan, case study, article review, research paper, presentation, and speech. Top writers can help with complex assignments such as dissertations, thesis papers, etc. All of them are professionals possessing excellent knowledge in their field of expertise, perfect writing skills, quality, and speed. When you place an order on our website, we assign it to the best writer. Once the writer finishes the work, the paper is submitted to our quality assurance desk who go through it and ensure it is unique and plagiarism free and that the instructions were followed to the detail. After this step we upload the paper in your account, we also send a copy to the email that you used to register the account with. we can guarantee you that the paper will be 100% plagiarism free. Besides, our services are 100% private and confidential

Question: How do I place an Order after getting to the order page

Answer: There are three major steps in the ordering process

Step 1 ....................................................paper details In this step, you will fill in the instructions of your paper; you can upload any materials that you feel will make your assignment a success. Besides, you can also email us at [email protected] Remember to specify the correct academic level. Please note that sources mean the number of references.

Step 2...................................................... Price calculation Kindly specify the number of pages, type of spacing and the correct deadline. This step will give you the estimated cost minus discount -- you may add the extra features if you wish.

Step 3 ....................................................discount and payment Use the discount code HAPPY2018 to enjoy up to 30% discount of your total cost After this step, proceed to safe payment; you can checkout using your card or PayPal Please note we will send the complete paper to the email you will provide while registering. A copy will also be uploaded to your account

Question: How will I know when my paper is complete? or How will I get the complete Paper?

Answer: Once we are done with the paper, we will be uploaded to your account. A copy will also be sent to the email you registered with. We can guarantee you the following:- 1. Our service is private and confidential; we don't spam or share your contacts with anyone 2. The final paper will be plagiarism free. We will send a Turnitin Report to the email you registered with 3. At our company, willing to do free unlimited revisions until you are satisfied with your paper

Question:- Am a new client, How can I get the guarantee that the paper will be completed and sent to me before my deadline?

Answer: Thank you for expressing your concerns. We would love to have you as our loyal customer. We are certain if we do good work, you will come back for me. Besides, you will give us referrals to your friends and family. For that reason, we can’t fail to deliver your paper within your specified time frame. We will ensure we submit the paper on time so that you can have enough time to go through it, if you have problems with the paper delivered, you can request a free revision. You are entitled to as many revisions as you would wish until you get a paper that satisfies you

Ch8BusinessIntelligence.pdf

Useful Links That Will Help You Around

FREQUENTLY ASKED QUESTIONS

Question: How does this work?

Question: How do I place an Order after getting to the order page

Question: How will I know when my paper is complete? or How will I get the complete Paper?

Question:- Am a new client, How can I get the guarantee that the paper will be completed and sent to me before my deadline?

Useful Links That Will Help You Around

Contact Us