Concepts:Chapter six begins with another modeling methodology: object-oriented analysis. Object-oriented analysis is strangely abbreviated as just O-O, which tells me that someone is tired of typing. An object is a combination of things that are depicted separately in the modeling methods we have already considered. The text uses a car and its driver as a metaphor for two objects in an information system. In the example, each object can have methods (programs) that are used to do something. One use is to send messages (requests or responses) to another object, such as the driver object sending a message to the car object to clean raindrops off the windshield, which the car object reacts to by activating its method to operate the windshield wipers. It might be a good idea to look at another reference for these concepts. The article on Wikipedia about object-oriented design is a good, concise source.
Objects belong to classes, which are templates for classifying similar objects. The previous version of the text gave us an example of a class called dogs, to which all objects having the common characteristics of dogs would belong. In this sense, each dog object would have common attributes (e.g. hair, eyes, teeth, tongue) and methods (e.g. shedding, stalking, biting. chewing, licking), although the values of those attributes may vary from one dog to another (e.g. long or short hair, chews anything in reach). An actual object that belongs to the dog class can be called an instance of that class (Lassie, Cujo, Duke Bush). Our text says that a class is a group of objects, but that implies that you can manage them as a group, which is not really true. It's not like keeping files in a folder. Think instead of all of the programs that are part of Microsoft Office. They have common interfaces, methods, and can read each other's data. Each one can also do things that the others cannot do. In this case, the applications are like objects that belong to a class, because of their common characteristics, regardless of their individual characteristics. The text complicates the concept of having objects that are based on other kinds of objects by describing object classes that are called parent and child on page 181. The example of each object type is clearer if you understand that the green templates represent the characteristics of a class called Parent and a class called Child, and the purple rectangles to the right of each one represent objects that are instances of each of those classes. If we consider the the Parent and Child object templates, their attributes are no different from what we might use as columns in tables in a relational database. The difference that does exist with objects is that each of these table definitions also holds a list of methods. The methods are programs that are also behaviors that an object of this type might exhibit in a game or simulation of human behavior. The text spends several pages elaborating on methods and messages. The example in figure 6-5 is meant to show a feature called polymorphism (many forms). We are shown three cases of a message (Good Night) being received by three different objects. The text tells us that the message has a different meaning for each receiving object. In the world of the authors, a child is told "Good Night" and the child gets ready for bed. A parent is told "Good Night" (by a child?) and the parent reads a story. Someone tells the dog "Good Night" and the dog succumbs to narcolepsy. Is this what happens at their houses? Let's assume that they are making objects for their own version of SimCity. The text resumes discussing classes to bring up the idea of subclasses. Maybe it does help to think about SimCity. If we have a class called vehicle, why shouldn't we have subclasses for cars, trucks, buses, and other specific types? We should. It saves time by eliminating the need to add the customizations of a car to the vehicle template each time we make one. It would make no sense to have a subclass called Batmobile if we only intend to have one instance of such a thing in the game. (Everyone knows that Batman has extras in the cave, right?) The text also brings up the idea of superclasses. A superclass is a template that can describe the common characteristics of several classes. Why is that needed? It makes sense to have this as a fallback when you discover that your project planning should have begun at a more global level. If you initially think a feature is needed by all objects in a class, and later find out that only objects used in one corporate division need that feature, you will be happy to be able to make a superclass to hold your object and the slightly less capable, but similar object you need for the next division. The text complicates something that is simple: superclasses, classes, subclasses, and objects (in those classes) are in parent-child relationships. In this context, this means that anything that is a child will inherit characteristics from its parent, which also inherits characteristics from its parent, and so on. Inheritance means that a child has the characteristics of all of its parents, in addition to what it might be given individually. Chapter 7 discusses some solution options for system developers, such as in-house development and outsourcing.
The text makes a case for placing our system, whatever it is, on the Internet. It offers a list of concerns that might lead us to choose traditional development, and a list of observations about web-based development. We will discuss some of these in class. The text mentions cloud computing, and admits that the phrase has several definitions. This commercial spot for Microsoft is cute, but what has it got to do with "the cloud"? Couldn't she have just used Photoshop, like everyone else? Whatever she used, the cloud is irrelevant. We may as well proclaim that McDonalds has cloud based hamburgers. They offer Wi-Fi, don't they? How about the people trapped at the airport who access TV programs stored on their home computer? They remotely accessed their PC. Is the Internet "the cloud"? Sounds like smoke and mirrors so far. The only meaning that seems to be relevant is buying or leasing a service that you access across an Internet connection, which avoids your having to own storage, or programs, or some other IT component. The text turns to outsourcing, which can be applied as a concept to system development, ownership, or maintenance. In the context of this text, outsourcing system development makes sense when your staff do not have the skills to do the job. Another kind of outsourcing is buying a service from a company that removes burdens from your company. For example, if you are using Microsoft Office, and using Outlook for your company email, it may make sense for a large organization to pay Microsoft to run the mail servers wherever they choose, and to provide access to them for your employees. Why is this sensible "for a large organization"? A small organization would not be running their own mail servers to begin with, so the savings would not be available. There are other issues that might keep us from considering such a move, such as security, uptime, access to data, and ability to add and remove users. The text discusses offshore outsourcing, but realizes in the discussion that it is no different from domestic outsourcing. The reasons to do either are financial, just as they are for any business decision. The next topic is whether or not to build a system at all. The text begins the discussion with the classic two ideas, build a system in-house or buy an over-the-counter solution. In addition to these ideas, buying a solution and then customizing it for your company is usually an option. Look at figure 7-10 in the text. Six reasons are given for in-house, and another six reasons are given for purchasing a system. Note that the reasons are arranged in a table as though they are points and counterpoints. The reasons given on each of the six lines, however, have nothing ot do with each other. A better way to use the ideas in the table would be to consider which ones match the company's goals and requirements. The text points out that customization may be needed to make over the counter software work well for you. This is possible in most cases, but it is also true that extensive customization may prevent you from updating or patching your system, which becomes either a drawback to customization or a requirement for more extensive work on your system for each upgrade.
|