Concepts:Chapter six begins with the usual Tina and David play that I have been ignoring. It is best to look at these as comedic skits put on by staff who understand something about the chapter, but nothing about comedy. We might want to look at this section of each chapter last, to see if we can get a laugh out of it. Moving ahead to page 226, the text tells us that another modeling methodology is 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 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 text gives 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 (e.g. 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 concepts by describing object classes that are not enlightening. The example of a Dog object (page 228) is clearer if you understand that the green template represents the characteristics of a class called Dog, and Buddy, Annie, and Megan are examples of instances (individual cases) of Dog objects. Again, this is less clear because it has nothing to do with an IT project, unless you are working on SimCity. Consider the fitness center example in figure 6-8. This could be clearer. If we consider the the instructor and student object templates, the attributes are no different from what we might use as columns in tables in a relational database. The difference in this case is that each of these table definitions also holds a list of methods. The methods are programs that an actual system user of each type might want to access as they use the club's IT system. The text spends several pages elaborating on methods and messages. The example in figure 6-15 is meant to show a feature called polymorphism (many forms). The example is poor, but the intent is good. 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. I wonder what color the sky is in their world. 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, busses, and other specific types? 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. To avoid the problem, think as globally as possible when designing these templates. 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 class characteristics its parents and of all of its ancestors, in addition to what it might be given individually. Chapter 7 begins by telling us it is the last one in the analysis phase. This chapter 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 to 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.
|