Chapter 3 – Conceptual Design: An Overview of Methodologies, Models and Notations

CHAPTER OBJECTIVES (YOU SHOULD BE ABLE TO):

1. Define and describe a methodology.
2. Define and describe traditional, structured analysis & design, information modeling, and object-oriented methodology classifications.
3. Define and describe a Data Flow Diagram (DFD) and an Entity-Relationship Diagram (ERD).
4. Define and describe attributes, operations and relationships in an object-oriented methodology.
5. Define and describe the foundational characteristics of an object-oriented methodology.
6. Describe two classic information systems development challenges and their potential resolution.
7. Discuss Classification Theory and its relationship with object-oriented methodologies.
8. Describe Rational Corporation's Unified Software Development Process.
9. Define parallelism, substitution and omission.
10. Describe the Unified Modeling Language (UML) and describe Use Case, Class Diagram and Interaction Diagram.
11. Describe a simplistic object-oriented methodology for applying and using the UML.
12. Describe the foundational characteristics of the UML’s Class Diagram

DESIGN

A generic systems development life cycle (SDLC) was presented in an earlier chapter. You may recall that the purpose for this version of a SDLC was to give you a simplified way of sequentially studying the activities that are utilized to produce software-intensive information systems. In reality the SDLC for such systems is as diverse and variable as the organizations that create these systems. What is common is that all organizations follow some SDLC for the creation, maintenance and evolution of their software-intensive information systems. As you read through this book remember that most of the activities of an SDLC are done iteratively and that several activities may be performed in parallel with others. The SDLC that was presented earlier consists of six (6) activities: 1. Information Systems Planning – both enterprise-level and project-level planning – and Feasibility Study 2. Analysis – Requirements Determination 3. DESIGN – Conceptual and Physical 4. Construction (Purchase) and Testing 5. Implementation including Training and Conversion 6. Evolution – Maintenance and Enhancement

This chapter's focus is on Activity #3 – Design. Rigorous methodologies and automated software development tools support software-intensive information systems development in the 21st Century; therefore this chapter will provide an introduction and overview of the design concept leaving the details of design to several chapters that follow. At some point during Analysis and Requirements Determination the systems analyst needs to begin to create models of the identified behavior, data and functionality of the proposed information system. Although the point at which the systems analyst does this fluctuates with every project, this model creation and refinement activity is design. Some of the models represent and illustrate conceptual design while others represent physical design. The difference in general is that conceptual design models are void of technology details whereas physical design models generally include technology- and programming-specific details. The following chapters will elaborate and illustrate more specifically about the conceptual and physical design models. Now let's look more closely at methodologies, models and notations.

METHODOLOGIES

How do you change the oil in your car? How do you bake a cake? How do you study for a test? No doubt you have an answer for all of these questions. Assuming you were going to do one of these three tasks (baking the cake sounds best—yum!), you probably have "a way" of doing it. Is your way the correct way? Is your way the only way? Is your way the best way? If you answered, "yes" to all three of these questions, you are in trouble! Why? Because you may be suffering from a severe case of a big ego! Someone once said, "Systems analysts with huge egos to satisfy should be extinct." I tend to agree with this statement. Don't get me wrong. There's nothing wrong with having confidence in "your way" of doing things, but maturity and professionalism as a systems analyst demand that you recognize and acknowledge that there are other ways to accomplish the same task. The way something is done in systems analysis and design is usually called a methodology. When talking about methodologies, some people refer to them as the strategy, process, steps, directions, or actions they choose to do or think about something. Several software development authors refer to methodologies in software development as a software development process or simply a software process [Ambler, 1999]. Methodologies can be (1) obtained or purchased from another business (you purchase a methodology for baking a cake when you buy the cake mix—it's on the box), (2) created by your own business or team (you may have created your own way to study for a test), or (3) a combination of the two. For example, you may use the cake mix methodology generally but take shortcuts (like not using measuring cups and spoons), or do things a little differently along the way (like putting the eggs in the bowl before the cake mix even though the methodology says to put the cake mix in the bowl first). Making changes to an existing methodology creates a new one—your own—and is often referred to as a hybrid methodology because of the changes that were made. There are literally thousands of methodologies for developing information systems because most businesses prefer to create their own hybrid methodology in order to maximize the methodology's utility to their own organizational culture. Dating back to the beginning of information systems development, four general methodology classifications have evolved—traditional, structured analysis & design, information (data) modeling, and object-oriented. Figure 3.1 presents a brief summary of each of these by highlighting some of the more commonly associated techniques and tools used as part of each methodology. Some information systems development colleagues believe that prototyping should be thought of as yet a fifth general methodology classification. On the other hand, prototyping and its myriad of variations can often be introduced as part of any of the four general methodology classifications presented here. Therefore, prototyping will be considered a technique used as part of a methodology and will be presented as such in this book. Many systems analysis and design projects incorporate some aspect of prototyping since there are many benefits associated with prototyping. These benefits are discussed in the prototyping section of the book.

The Traditional Methodology

Today classifying one's methodology as being traditional is often a "politically correct" way of saying that you have no methodology at all or, at best, an unstructured, unrepeatable, un-measurable, ad hoc way of doing something. Can you develop an information system using a traditional methodology? Of course! Someone does it every day! A team consisting of exactly one member (you developing a system for yourself) probably could use and get away very nicely with using this methodology. The traditional methodology becomes much less effective as the size of the team grows or as the complexity of the information system grows. For reference purposes, some tools used in conjunction with a traditional methodology are system flowcharts and hierarchical input-process-output charts (HIPO). The implication being made here with respect to a traditional methodology is that this methodology has serious problems in most information systems development situations; however, the tools used to support it have applicability in certain development situations.

Structured Analysis and Design Methodology

The structured analysis and design methodology classification, also referred to as the data flow modeling methodology, emerged in the mid-1970s to complement structured programming, and today is one of the dominant methodologies being utilized for business-oriented information systems development, such as is done in management information systems (MIS) departments within businesses and governmental agencies. In this methodology, the real world is described by the flow of data through an information system and the transformations of the data into information as the data move from input to storage to output. A structured analysis and design methodology, as its name implies, adds dimensions that allow it to be rigorous (formalized), repeatable, and measurable. In addition, a new dimension was added starting in the early 1980s—it can be enhanced by automated support called computer-aided software engineering (CASE). The CASE acronym has evolved more recently into newer terms such as integrated/software development environment (IDE or SDE). Terms such as these continue to evolve in the hopes of maintaining relevance (and marketing hype) so that in a few years there may be other terms used to refer to this classification of automated software development tool suite. In the first edition of this text I referred to this type of software tool suite exclusively as CASE. In this edition I will mostly refer to this type of software tool suite as IDE or SDE (although a few carry-over CASE terms may still show up). The predominant focus of the structured analysis and design methodology is to do the analysis and design utilizing a functional perspective (approach). In other words, the systems analyst uses a "What does the system have to do?" problem-solving approach. With the introduction of CASE/IDE tools around 1984, computerized software support has emerged to provide assistance for drawing the methodology notations, validating and verifying the methodology models that the notations represent, and allowing management to monitor the progress of a project via computerized project management support.

For reference purposes, names such as Constantine, DeMarco, Gane, Hatley, Myers, Orr, Paige-Jones, Palmer, Sarson, Stevens, Ward, Warnier (warn-yea), Yourdon, and others have made significant and documented contributions to the structured analysis and design methodology classification. Tools such as data flow diagrams (DFDs), structure charts, Warnier-Orr diagrams, Petri nets, and data dictionaries are often used in conjunction with the structured analysis and design methodology. Remember, conceptually there are only two dominant generic structured analysis and design methodologies (Yourdon, and Gane and Sarson), but businesses have in most cases created their own hybrid versions of the generic ones. Figure 3.2 illustrates a sample DFD that is the dominant model used in structured analysis and design.

Information Modeling Methodology

The information modeling methodology classification also referred to as the data modeling methodology or information engineering methodology, emerged in the early 1980s as businesses began to embrace database management systems. Today it too is a popular methodology used to assist in the development of business-oriented information systems. An information modeling methodology subscribes to the notion that good engineering is simple engineering. It approaches the development of information systems predominantly from an information perspective rather than a functional perspective, as does the structured analysis and design methodology. The real world is described by its data and the data's attributes and their relationships to each other. As with the structured analysis and design methodology, information modeling adds dimensions that allow it, too, to be rigorous (formalized), repeatable, measurable and automated. The predominant focus of this methodology is to do the analysis and design from an information perspective. In other words, the systems analyst uses a "What information does the system have to be able to provide the user?" problem-solving approach. Today there are only a handful of purchasable IDE technology products that fully support an information modeling methodology. For reference purposes, names such as Peter Chen, James Martin, and Ian Palmer among others have made significant and documented contributions to the information modeling methodology classification. Tools and techniques such as an entity-relationship diagram (see Figure 3.3), business area analysis (BAA), and information models are often used in conjunction with the information modeling methodology.

Summary Comment on the Structured Analysis & Design and Information Modeling Methodologies

In my opinion, the fundamental or key difference between these two methodologies—which by the way are often utilized or blended together—is the primary problem-solving strategy picked by the systems analysts. The fact is that each of these methodologies must address both function and information (data) in order to successfully and completely address information systems needs. As I have already stated, it's really a matter of the primary problem-solving strategy used to address the functions and information. Does a systems analyst begin with functions or information? The structured analysis and design methodology advocates would say "functions." The information modeling methodology advocates would say "information." Both sides would agree that they need both functions and information (data), but they would disagree with the fundamental (primary) problem-solving strategy used to discover the functions first and data second or the data first and the functions second.

Object-Oriented Methodology

The object-oriented systems analysis and design methodology classification emerged in the mid- to late 1980s as businesses began to seriously consider object-oriented-programming languages for developing and implementing systems. Even though Simula, circa 1966, is credited as being the first object-oriented language, popular object-oriented (or object-enabled/enhanced) languages such as Smalltalk, C++, Objective C, and Eiffel came into their own in the 1980s and Java was introduced by Sun Microsystems in mid-1995. A few other object-enhanced products made their way to the marketplace in the 1990s – perhaps most notably Visual Basic, Delphi and PowerBuilder. All of these object-oriented languages approach programming from a significantly different paradigm than previous programming languages. Rather than follow the structured, deterministic, and sequential programming paradigm associated with languages such as COBOL, Fortran, C, Basic, PL/I, Ada, Algol and others, these languages follow the approach pioneered by Simula based on objects, attributes, responsibilities, and messages. Often history repeats itself. Such is the case with object-oriented analysis and design. Just as structured analysis and design emerged as a complement to structured programming in the 1970s, object-oriented analysis and design emerged as a complement to object-oriented programming in the 1980s. The problem-solving strategy inherent in object-oriented programming is to approach the problem from an object (e.g., person, place, thing or concept) perspective rather than the functional perspective of traditional and structured methodologies or the information perspective of an information engineering methodology. Because of this, object-oriented programming began to capture mind- and market-share as a dominant programming paradigm mostly in computer science, software engineering and scientific programming environments while business-oriented programming remained somewhat skeptical of its value to them. With the increased emphasis on graphical user interfaces (GUI) and software that runs on distributed and heterogeneous, client-server (multi-tier) computer hardware platforms across the Internet even business-oriented programming is shifting to object-orientation. Since object-oriented programming's problem-solving strategy is unique, the need for an object-oriented systems analysis and design approach leading up to the programming task makes sense. The older, more mature methodologies have limitations in representing a model of the information system that can readily be implemented using an object-oriented programming language primarily due to their focus on functions or data, not objects. This is not a statement that the older methodologies are inferior. Rather, they are just different and were well suited for the job they were intended for. Object-oriented analysis and design has good and bad news associated with it. The bad news is that there is yet another new methodology in the marketplace. The good news is that much can be borrowed from the other pervading methodologies and applied to the object-oriented methodology, which some believe makes it more evolutionary than revolutionary. In other words, experienced systems analysts need not throw out all their knowledge and experience acquired using the other methodologies, which would tend to demoralize the veterans in the field. Rather than the object-oriented analysis and design methodology being revolutionary, it is evolutionary in the "borrowing from what we already know" sense. The methodology notations and subsequent models it represents are new, yet similar to other notations. The most difficult aspect of learning an object-oriented methodology and notation for experienced systems analysts is the transition from a functional or information (data) centered problem-solving strategy to that of an object problem-solving strategy. Moving from a "function think" or "data think" problem-solving strategy to an "object think" strategy is not an easy one. For example, just think of the difficulty you would have retraining yourself to type using a Divorak keyboard layout, which is significantly different from the standard Qwerty keyboard layout that we are all familiar with! Study, practice, experience, and time will all be important for experienced systems analysts to make a successful transition in their thinking about the problem domain and then determining requirements and documenting them using an object-oriented notation and methodology. The use of the object-oriented methodology (or any other for that matter) for the novice systems analyst or trainee should be less difficult due to the limited experience he or she has with other methodologies. In other words, novices have less experience and habits to retrain. Someone who does not know how to type using a keyboard has little or no keyboarding memory and habits to retrain and could likely learn the Divorak keyboard with little difficulty. For reference purposes, names such as Booch, Coad, Cox, Firesmith, Henderson-Sellers, Jacobson, Mellor, Meyer, Odell, Rumbaugh, Shlaer, Wirfs-Brock, and Yourdon among others have made significant and documented contributions to the object-oriented methodology classification. Tools and the techniques that support them such as dynamic and static object-oriented models, sequence, collaboration and state diagrams, and use cases are the basis for object-oriented modeling. In November 1997 the Unified Modeling Language (UML) became a universally recognized standard of the Object Management Group (OMG). The UML is a set of models and notations that give software developers a standard way to visualize, specify, construct, document and communicate the artifacts of an information system. The UML will be used later in this book for object-oriented modeling. As we move through time the UML continues to evolve and be refined. Rational Corporation (www.rational.com) – a major contributor to the UML – promotes an object-oriented methodology called the Rational Unified Process (RUP) as the process that best compliments the UML. RUP version 5 is illustrated in Figure 3.4, and it is becoming very popular and may someday become the basis for an OMG-sponsored object-oriented methodology.
FOUNDATIONAL CHARACTERISTICS OF AN OBJECT-ORIENTED METHODOLOGY

As discussed in Chapter 1, systems analysis and design is a complex process. Accommodating this complex process requires systems analysts to exploit commonly understood characteristics or principles for managing complexity. As cited earlier, today's information systems are complex and involve tens of thousands, hundreds of thousands, or millions of lines of programming code. For example, some knowledgeable software developers have estimated that Microsoft's popular Windows Operating System has more than 35 million lines of programming source code—Wow! That's a lot! In fact the systems being developed today are far more sophisticated than those of just five years ago. A personal computer word processor was "feature poor" back then compared to the ones currently available for purchase. Shrink-wrap software has moved into the competitive arena of hundreds of thousands or even millions of units in commercial sales. As a result, each new version or release of the software must exceed the features and benefits of the older version. Not only that, new releases often must exceed the capability of their strongest software competitor's currently selling software version. Some common characteristics for managing complexity during systems analysis and design are available for systems analysts to use to one degree or another regardless of the SDLC used to develop the information system. At least eight characteristics or principles for managing complexity are also considered foundational and are generally accepted characteristics of object-oriented analysis, design, and programming. Each of these common characteristics is presented here for your consideration. You may already be familiar with many of them because they often have a much broader applicability to your own personal life, not just to software development. They are: 1. Common methods of organization 2. Abstraction 3. Encapsulation or information hiding 4. Inheritance 5. Polymorphism 6. Message communication 7. Associations 8. Reuse

Not all object-oriented books discuss all eight of these characteristics. However, because I believe they are important, I have included them here. These eight concepts are not necessarily new to object-oriented systems development as other older methodologies incorporate one or more of them in some way. However, together all eight form the fundamental building blocks for object-oriented technologies. Each is discussed next.

1. Common methods of organization assist with organizing an information systems model as well as the software that is ultimately written. The common methods of organization that are applicable here are: a. Objects and attributes or characteristics. For example, you could be the object and your name, address, height, weight, color of eyes, date of birth, and so on are some of your attributes or characteristics. b. Wholes and parts. For example, your television set is the "whole" and the individual parts that make up the television set are the "parts." A personal computer system—the whole—usually consists of a box with all kinds of hardware in it, a printer, a monitor, a keyboard, and a mouse—the parts. c. Groups and members. Conceptually this is similar to wholes and parts, but its examples are often different and do not seem to fit neatly into a "wholes and parts" classification. For example, a computer club would be a group and the individual members of the computer club would be the members. Your Systems Analysis and Design course would be the group and the students in the course would be the members. People in general are quite familiar and comfortable with the above common methods of organization; therefore they will be able to related to our Systems Analysis and Design models that take advantage of these concepts.
2. Abstraction is the principle of ignoring those aspects of a problem domain that are not relevant to the current purpose in order to concentrate more fully on those that are. Abstraction is a concept that you use every day. It has to do with the amount of detail you care to get involved in. In systems analysis and design, this is called levels of abstraction. Let's say that your friend decides to bake a cake. He offers you the choices of both helping him bake the cake and then helping him eat it or just helping him eat it. If you choose the first option, you are demonstrating a detailed level of abstraction because you have chosen to get involved with the details of making a cake. If you choose the second option, you are demonstrating a generalized level of abstraction because you chose not to deal with the details of baking the cake, only eating it. Telling your father that you love him is abstract, or generalized, while telling him one or more of the reasons why you love him is specific and thus a more detailed level of abstraction. In systems analysis and design, abstraction is used to identify essential information system requirements while simultaneously postponing or eliminating non-essential aspects. An abstraction intentionally ignores some qualities, attributes, or functions of an information system in order to focus attention on others. An abstraction is also a summary, covering the highlights and leaving out the details. It also omits the pieces of the system that are not necessary for understanding the system at a given level of detail. Maps typically represent a good example of abstraction. You can get maps of the United States, individual states, counties, cities, zip codes, and so on. Each map cited here in succession is less abstract and hence more detailed than the prior one. In addition, a city map intentionally leaves off the details of the surrounding county, state, and country that it is a part of in order to allow you to focus on the details of the city. Another example of abstraction would be to view an aerial picture of your entire university campus. Such a picture would not have detailed information regarding a specific office on a specific floor within a specific building on the campus. Abstraction has been a common characteristic in all of the prevailing information systems analysis and design methodologies. Therefore, experienced systems analysts can continue to utilize this system-building characteristic as they transition to an object-oriented methodology.
3. Encapsulation or information hiding is the notion that a software component (module, subroutine, operation, method, and so on) should isolate or hide a single design decision. This notion is based on the work of David Pamas dating back to the early 1970s. An example of programming encapsulation may illustrate this notion best. The creation and subsequent use of a single software component to look up student account numbers in a student database isolates this lookup feature from the rest of the software that makes up the information system. Each time the information system needs to look up a student account number, this routine is used, since the logic to look up student account numbers has been encapsulated within this one routine. If a new lookup routine is created, tested, and used each time there is a new requirement to look up a student account in the database, two potentially negative things happen. First, prior work—software construction and testing as a minimum—is replicated. Second, additional maintenance activity will be required for the information system should it ever be necessary to alter the student lookup routine(s). In systems analysis and design, systems analysts decompose the problem domain into small, encapsulated units. These analysis and design decisions eventually become software modules. Encapsulation helps to localize their volatility when changes and maintenance are required after they have become software modules. A further elaboration of encapsulation or information hiding is any mechanism that allows certain portions of the information system to be "hidden." This can be useful in at least two different situations: a. When it is important that people only use or have access to a certain subset of the complete information system. For example, while an information system is being developed, development team members may be assigned to work on a certain part of the system and not allowed access to other parts of the system being worked on by other team members. Once the information system is operational, certain users may only be allowed to use a few of the features of the information system while other users may have access to many more features. b. To purposely prevent other components of the information system from being aware of or unable to take advantage of certain other components in the system. This situation addresses another aspect of encapsulation—assignment of responsibilities. Just as in real life you have certain responsibilities, a specific component of an information system has its responsibility, say dispensing cash in an ATM, while other components of the same system have their responsibilities, which exclude the dispensing of cash since that function is done by another component. Another way to think about encapsulation is from a programming perspective, which has long since advocated the creation and use of small blocks of function-specific code (e.g., procedure, subroutine, paragraph, and so on) that can be assembled into a working computer program in a modular fashion, much like the plug-compatible stereo components in homes today. Each of these blocks has encapsulated within it one or a few design functions. For example, each of the following functions could be represented by a small block of computer programming code and then bundled together to perform a higher-level function, such as registering for courses for this coming school year — "get student identification (Id) number," "validate student Id number," "check student Id number for outstanding fines," "get course Id to add to student's schedule," "determine if a seat is available for this course Id," "determine student Id number's eligibility to take this course Id," and so on. Finally, encapsulation has been a common characteristic in all of the prevailing information systems methodologies. Therefore, experienced systems analysts can continue to utilize this system-building characteristic as they transition to an object-oriented methodology. There is one subtle difference. With the older, more mature methodologies, encapsulation was usually limited to encapsulation of functions separately from encapsulation of data. With the object-oriented methodology, encapsulation incorporates both functions and data together into objects. This notion will be discussed in more detail later in the book.
4. Inheritance is a mechanism for expressing similarity. Just as you inherited certain physical features from your mother and certain ones from your father, so also can information system components inherit certain things from related components. For example, Figure 3.5 shows that a hierarchical or parent-child relationship exists between a group called Person and groups of Faculty, Administrator, and Student. We purposely are using the singular for each of these words in keeping with the notation that is used throughout the book, but keep in mind that Administrator means one or more administrators, as does student and faculty. A sibling relationship exists between Faculty, Administrator, and Student. There are certain characteristics that can be associated with Person and thus inherited by all the children in the hierarchy—Faculty, Administrator, and Student—such as name, address, phone number, and date of birth to name a few. Other characteristics may be unique to a single sibling. For example, office hours may only be applicable to Faculty, job title may only be applicable to Administrator, and grade point average may only be applicable to Student. These characteristics would be associated with the specific child node in the hierarchy. Similarly, there are certain things that a Person can do that would be common to Faculty, Administrator, and Student, such as eating at the cafeteria and walking on campus. Likewise, there are certain things that are unique to each of the children nodes. For example, a Faculty person may assign grades and add students to the class, whereas an Administrator person may manage people and key in administrative data to the computer, while a Student person could register for courses and take an exam. These actions would be associated with the specific child node that each belongs to. As is usually the case in real life, inheritance in systems development is a one-way street—down the hierarchy—from the "parent" node to each of the "children" (siblings) nodes. However, as you view Figure 3.5 you observe three arrows—each pointing upwards toward the "parent." The explanation for this is that each of Faculty, Administrator and Student "extends from" or "is an extension of" or "is a specialization of" or "inherits from" the Person—hence the upward-pointing arrows.

5. Polymorphism in the general sense is the ability to take on different forms. For example H2O can take on three forms—water, steam, or ice. In a sense, you could say that you are polymorphic with respect to your behavior when approaching a traffic signal in your car. You respond differently depending on the status of the signal light. In software, for example, the print operation associated with textual characters and numbers can print textual characters and numbers "because it knows how to do this". The print operation associated with graphic symbols and images can print graphic symbols and images "because it knows how to do this". Each of the print operations just described will print something on a printer in the abstract sense; however, at the detail level each of these print operations does its job a little differently because what is being printed is of a different type—textual characters and numbers, graphic symbols, and images. Because of the differences at the detail level, the print operation is considered polymorphic. Polymorphism in computer programming isn't new, but its use during object-oriented analysis and design by systems analysts probably is.
6. Message communication is the way objects in an object-oriented methodology communicate with each other. It is similar to a subroutine call with parameters or a paragraph or procedure call in some other conventional programming languages such as Fortran, COBOL, C, or Pascal. This concept is widely understood by practicing systems analysts so it, too, can be directly transferred into an object-oriented methodology by them.
7. Associations are useful to assist with relating things in an information system to each other. Things that happen at the same time could be associated as well as things that happen under similar conditions. For example, VISA, MasterCard, Discover, and other credit card companies send out periodic statements showing us our balance owing. These companies often take this opportunity to insert a number of advertisements along with the statement, since the postage is often the same with or without the advertisements. Also, Figure 3.5's hierarchy is an example of association.
8. Reuse. Everywhere you look in your world you see reuse in one form or another. The same power cord can often be used for your computer, your monitor, or your printer. Apartment windows often come in standard sizes, and dozens of a certain size window are used in a large apartment complex. The can of orange juice you bought last time probably looks just like the one you bought today. How many shirts or blouses do you have that reuse the same type of button? How often do you reuse a textbook that was used by some other student before you? Have you ever reused a videocassette to record over some other event that you recorded at a previous time? Reuse is a much talked about concept in systems analysis and design, but one which is still struggling to make a significant contribution to the development process due primarily to two factors. The first factor is the retraining of the mind-set of the analysts and programmers who are accustomed to creating their own systems models and code. This translates to the "not invented here" mentality held by some systems analysts and programmers. In other words, they want to create and debug their own "whatever" rather than use someone else's "whatever" that does the same thing (and is already debugged I might add!). Management can address and overcome this problem given proper amounts of time, retraining, and other motivators for the systems analysts and programmers who are resistant to reuse. The second factor relates to the administrative factors that must be established for setting up a library of reusable models and code. This is no easy task for a variety of reasons including strategy to accomplish, personal, organizational, cultural, and legal aspects. As used in our everyday world, reuse can take one of three forms: (1) sharing, (2) copying or cloning, or (3) adjusting. Each is discussed here. An example of sharing is when you use a textbook and then sell it back to the bookstore, which in turn resells it to another student. Or everyone living in or visiting your apartment or home shares (reuses) the telephone you have. In software development, a subroutine, module, paragraph, procedure, service, or file definition are all potentially reusable. A small procedure could be created that only looks up student identification numbers in a student database and then responds with valid or invalid. Such a procedure could be used over and over again, intact, within an information system. An example of copying or cloning is what is done every day in the manufacturing industry. An automobile model is prototyped and then moved into production to produce thousands of that model. In software development, we could have a paragraph of a COBOL program that we copy and put into another COBOL program, giving two paragraphs that are identical. An example of adjusting is a variation on the copying or cloning. Using the automobile example, as a certain model moves down the manufacturing assembly line, standard features for this automobile are assembled (copying) as well as different combinations of options are assembled such as air conditioner, CD player, spoiler, tinted glass, and so on (adjusting). Granted that these options are standard reusable components just assembled in different combinations in the particular automobile. However, the final product, the automobile, is a variation on the standard make and model. A variation of the adjusting type of reuse is the situation in which the standard item is actually changed and then used in some other application. For example, a computer modem cable can have two of its wires physically swapped within the cable housing, and then this cable becomes a different kind of modem cable called a null modem cable—an adjustment to the standard cable. An example of adjusting in systems analysis and design is when a programmer locates a subroutine, module, or paragraph, and so on from a library of reusable components. The subroutine becomes the programmer's beginning point for creating a new subroutine, somewhat similar to the original library version. Then the programmer begins making adjustments to the subroutine, such as removing some of the code in the subroutine, changing other parts of the code, and adding new code to this new subroutine to meet a specific purpose. The end result is a new subroutine. The eight characteristics described above play pivotal parts in the object-oriented systems analysis and design methodology. This is indeed good news because most people—software developers and users of computers—are already familiar with most of them.

THREE CLASSIC CHALLENGES IN INFORMATION SYSTEMS DEVELOPMENT

Three of the most significant challenges that have continuously been associated with the pervading analysis and design methodologies appear to be resolved or at least significantly reduced with an object-oriented analysis and design notation and methodology. The first of the three challenges is that most other methodologies construct separate models for the functional and information views of the proposed information system as shown in Figure 3.6a as Challenge "A". In addition, a third component—behavior or user-interaction—is becoming more important in today's information systems and needs to be modeled as well. The popularity of interactive, graphical user interfaces and object-oriented operating systems, such as Windows, Macintosh and others has shifted programming from a deterministic approach to an event-driven approach. This introduces the need for a third view of the system—a behavioral view, and this view is rapidly becoming quite important. The function and data multiple models have value in that each depicts some portion of the same information system. The difficulty lies in the fact that neither systems analysts nor IDE software tools have been able to completely validate and verify the consistency and accuracy of the integration of the two models simply because they each represent a different perspective of the information system. In object-oriented systems analysis and design several integrated models are used to represent all three views—function, information, and behavior. This is a very significant move forward because more rigorous validation and verification of the integrated set of models is now possible.

The second challenge that has continuously plagued information systems development is the proverbial transition from analysis to design as illustrated in Figure 3.6b as Challenge "B". Once again, in most of the older methodologies one or more analysis models are created and then a completely new model or set of models is drawn during design that communicates more specifically to the programmers for the impending programming effort. Analysis models have historically been a communication tool between the systems analyst and the user. The design models have historically been a communication tool between the systems analyst and the programmer. With the object-oriented analysis and design notation and methodology there is no transition to design. What happens instead is a progressive expansion of the analysis models as they progress through design to include additional refinement details that address the programming task that is approaching. So systems analysts, users, and programmers deal with one model of the information system from analysis all the way through design, coding, testing, and implementation. The resulting information system can be validated back to the original analysis model because it is still the most valid model of the system even after the system is implemented.

The third information systems development challenge is depicted in Figure 3.6c as Challenge "C". Software developers have historically had two common mindsets: 1) I write better code than any other programmer, and 2) When I need to make a programming change I go directly to the source code and figure out where to make the change, regardless of documentation availability. The first of these two mindsets is probably a bit distorted and fosters a "start from scratch" software development philosophy rather than one that thinks, "Let's try to reuse someone else's code as much as possible before writing my own code." The second mindset simply can consume large amounts of development time as one looks through hundreds if not thousands of lines of source code to make a change. Often, a programmer in the midst of making a software change decides to rewrite portions of the code because it is sub-standard (called "spaghetti code" in some software development circles). The notion of reuse is becoming more and more "fashionable" (and economically [time and money] necessary). In addition, modification of models is proving to be less time-consuming than modifying source code assuming an IDE software development tool is being used to maintain the models and automatically generate source code for the software developers. Object technology enabled via an object-oriented methodology coupled with object-oriented models of the proposed information system significantly assists in overcoming these three historical information systems development challenges as illustrated in Figure 3.6d. The object-oriented approach to developing information systems combines a robust set of inter-related object-oriented models that are more favorably integrated with each other starting with the static and dynamic models created during the early activities of the development lifecycle and culminating with the deployment models that could be created near the end of the lifecycle. Object-oriented approach proponents argue that there is no transition from analysis to design or need to redraw analysis models to reflect physical design models as in the older methodologies. In my opinion, for now, the object-oriented approach is the best the software development industry has to offer until something better comes along—and something better eventually will come along.

CLASSIFICATION THEORY

Object-oriented methodologies and programming are based on classification theory, a fundamental concept most of us learned prior to or during our first few years of elementary school. The "common methods of organization" characteristic discussed earlier in this chapter is really about Classification Theory. Classification theory simply states that people constantly and consistently use three methods of organization to help clarify their thinking about something. The three methods are: 1. The differentiation of experience into particular objects and their characteristics—objects and their characteristics. An example is being able to distinguish between a tree and its size or spatial relationship to other things in our world, such as a rock, flower, bush, bicycle, and so on. 2. The distinction between whole objects and their component parts—wholes and parts. For example, a tree is made up of leaves, branches, and roots, while a bicycle is made up of wheels, rims, spokes, pedals, seat, and handlebars. 3. The formation of and the distinction between different classes of objects—classes or groups of objects. Examples include grouping trees (maple, elm, palm, eucalyptus) into a tree class; grouping buildings (homes, apartments, offices, churches, schools) into a building class. People's common understanding and use of classification theory is one strong reason why an object-oriented perspective is a viable approach to analyzing, designing, and building information systems. People are already familiar with it. Learning something totally new is not required.

THE UNIFIED MODELING LANGUAGE (UML) AND AN OBJECT-ORIENTED METHODOLOGY

Since their beginning in the late 1980s, several methodologists, researchers, practitioners and authors have put forth specific object-oriented notations and methodologies (refer to an earlier section of this chapter for some names; also refer to the end of chapter references). In one-way or another many of these people contributed and collaborated to help shape the UML into the worldwide standard that it is today. Formally adopted in November 1997, the UML includes a set of nine models and notations for each of the models along with a metamodel—that is, a model of the constructs in UML. The complete set of UML models and notations is extensive; therefore, for the purpose of this text, a subset of the UML models and notation will be presented, discussed and used. It is one thing for a group of professionals to create a worldwide uniform set of object-oriented models and notations (the UML). Many other disciplines, such as industrial architecture and electrical engineering, have had standard model and notation sets for many, many years. It is an entirely different—and far more challenging—thing to arrive at a worldwide object-oriented methodology standard. Remember our earlier discussion about generic methodologies—traditional, structured analysis & design, information modeling and object-oriented—and that most organizations tailor these generic ones to create customized versions? Although we in the software development industry overwhelmingly want to create standardized models utilizing standardized notations, we want to create and manipulate these notations and models in different ways—hence, different methodologies. For the purpose of this text a simple object-oriented methodology will be presented, discussed and used. This simple methodology is based on aspects of a proposed standardized "unified process" and other methodologies. This book is not intended to be the definitive work on the UML nor the methodology to apply it. Interested readers are directed to the Booch, Jacobson, and Rumbaugh references at the end of the chapter for more definitive works. Part of the rationale for using a simple methodology in this book is that more than likely any software development organization you (go to) work for will train you in its own unique object-oriented methodology. The simplified object-oriented methodology is presented here before giving an overview of the UML. Remember, the methodology is the way in which we will create and manipulate (use) the UML's models and notations. The methodology consists of seven (7) activities as follows: 1. Identify the purpose of the information system. 2. Identify the primary actors and features of the information system. 3. Identify Use Cases and create a Use Case Diagram for the features. 4. Identify Objects and their Classes and create a Class Diagram. 5. Create Interaction/Scenario Diagrams. 6. Create detail logic for Operations. 7. Repeat activities 1-6 as necessary refining and fine-tuning the various diagrams.

As you can see, the methodology is listed sequentially above, primarily to illustrate the different activities that are performed during systems analysis. What are not shown in this sequential list are the notions of parallelism, substitution, and omission. Parallelism gives the project manager license to perform activities in parallel when a systems development situation permits. Substitution gives the project manager license to substitute activities out of the standard order presented in the above list when a systems development situation permits. Likewise, omission gives the project manager license to omit one or more detail activities shown in the list when the situation permits. A simple explanation of each of the methodology activities is presented here since each one is elaborated on in the following chapters. Activity 1: Identify the purpose of the information system. This activity needs to be done prior to doing any object modeling of the problem domain. In fact, this activity should be done before any type of modeling is done. The user and the systems analyst need to identify, understand, and document the system's intended purpose. For example, a university course registration system purpose could be stated as, "The information system will allow authorized students to add, change, and delete their own course seat reservation." Sometimes, the purpose of the information system can also seem like a feature—see Activity 2 below. When this seems to be the case, the system's purpose is usually broader in scope than any single feature. This activity combined with activity 2 below is analogous to identifying the information system's goals and objectives as discussed in Chapter 2. Activity 2: Identify the primary actors and features of the information system. Working and interacting with the user(s), the systems analyst should identify all of the significant (primary) actors and features associated with this new or changing information system. Often, this activity translates into identifying a list of just a few features (for example, less than a dozen) in a small-scale information system or a small-scale one that is undergoing a few changes, and dozens of features for a medium to large-scale information system or a medium to large-scale one that is undergoing significant revision. This activity combined with activity 1 above is analogous to identifying the information system's goals and objectives as discussed in Chapter 2. A couple of features for a university course registration information system would be "register for course" and "drop a course." Actors represent roles that people or other information systems play with respect to this information system. A couple of actors for a university course registration information system would be "student", "faculty", and "registrar". Features most often answer the following question, "What can actors do with the information system?" The emphasis is on functionality—what the system will do—rather than technology that addresses how the system will do it. Activity 3: Identify Use Cases and create a Use Case Diagram for the features. Use cases parallel features—one for each feature. The individual use cases are grouped together to create a Use Case Diagram. This is the beginning point for using the UML and an object-oriented methodology. As mentioned before, activities 1 and 2 above should be done regardless of modeling, notation or methodology. Figure 3.7 illustrates a simple Use Case Diagram showing four use cases that could be part of a university course registration information system. Activity 4: Identify Objects and their Classes and create a Class Diagram. Objects represent real-world persons, places, things or concepts (e.g., an airline flight from Los Angeles to New York). A Class represents a group of objects that have similar characteristics. For example, there are about 30,000 student "objects" attending our university this semester; we could group them all together and call them the Student class. A Class Diagram shows the collection of all classes in the information system. Figure 3.10 near the end of this chapter illustrates a class diagram for a Video Store information system. Activity 5: Create Interaction/Scenario Diagrams. Each Use Case (Figure 3.7) in a Use Case diagram is expanded to reveal the details of what it really takes to accomplish "register for a course", "manage the curriculum", etc. (for example). This elaboration is called a scenario and it represents a "start-to-finish" series of actions (steps) necessary to accomplish the use case. One of two types of Interaction Diagrams is used for this elaboration—a Sequence Diagram or a Collaboration Diagram. Each of these diagrams is "dynamic" in nature in the sense that if you follow the diagram you will be able to envision "what it takes" to perform the feature that it is describing—registering for a course, for example. Figure 3.8 illustrates a portion of a Sequence Diagram for the "registering for a course" use case. Activity 6: Create detail logic for Operations. Operations are the transformations and actions that an object or class is responsible for. Operations usually contain the business rules, policies, procedures, logic, and algorithms that are necessary for an information system to be useful. Operations are usually identified as part of identifying objects and classes (Activity 4) or as part of creating the interaction diagrams (Activity 5) or a combination of both. In Figure 3.8 observe the names above the arrows on the sequence diagram. Each of these names represents operations—the detail actions that the class directly above the arrow's "tip" is responsible for taking care of. Most of these operations need detail logic within them in order to do what their name implies they do, and this logic is entered during activity 6.

As mentioned earlier, each of the above activities will be discussed and illustrated in much more detail in the following chapters as we learn how to create information system models using the UML. The final section of this chapter presents an overview of a UML Class Diagram for a Video Store Information System. The purpose for doing so is to give you a better appreciation of what one UML diagram looks like as we prepare to move forward into the following chapters.

A UML Class Diagram for a Video Store Information System

If you were asked to draw an office building or a home, could you do it? Probably so! Why could you draw an office building or a home? You could do so for at least two reasons: (1) You have a mental picture of what an office building or home looks like (even though your mental picture may be quite different from someone else's mental picture of an office building or home), and (2) you already know the basic notation needed to draw an office building or home, such as lines, circles, rectangles, triangles, squares, windows, doors, patios, porches, roofs, and so on. Now if you were asked to draw a picture of a payroll information system or even a university course registration information system using the Unified Modeling Language (UML), could you do it? Probably not, unless you (1) have some understanding of how a payroll information system or a university course registration system functions, and (2) know what a the UML looks like—its notation and models—and have some minimal understanding of how to use the UML to draw the models of either of those information systems. What's really required here? At least two things come to mind: (1) familiarity and understanding with a problem domain (e.g., office building, home, payroll system, university course registration system), and (2) familiarity and understanding of specific notation and models. Familiarity with and understanding of a problem domain means that you have knowledge of a specific problem domain ranging from minimal knowledge all the way to being a subject matter expert (SME)—one who knows a great deal about a problem domain. Notation is a set of symbols used to communicate or represent something. An alphabet is a universal example of a notation. Familiarity with a notation implies that you know which notation symbols are available to use, and understanding of a notation implies that you know the "packaging" for integrating and combining the notation symbols into models. As you know, the real value of an alphabet is being able to combine the alphabetical symbols into meaningful words, sentences, paragraphs, etc. Likewise, being able to package the UML notations into the various UML models (diagrams) is its real value. What follows now is a discussion of a simplistic, partially completed UML Class Diagram that represents the user requirements for a Video Store information system. The intent is to show you in advance what an object-oriented UML class diagram for a problem domain looks like so you can see "the big picture" before diving into all the details of the various UML models in the following chapters. A colleague once made the following comment about textbooks. He said, "Textbooks are very good at explaining all of the ingredients of a tossed salad (lettuce, tomatoes, onions, carrots, celery, and so on), but few textbooks actually show you a completed tossed salad." The intent of this section is to show you the completed "tossed salad" allowing for some license with respect to the object-oriented UML class diagram model really being complete. As we walk through the following explanation you may find it helpful to draw upon your subject matter expertise as a customer of your favorite video rental store (assuming you have one). A video sale/rental store information system is used for presenting the object-oriented user requirements UML class diagram model example. The example is incomplete from two perspectives. First, the details of the video store information system problem domain are omitted for simplification purposes. Second, the UML class diagram model that is presented is only showing the basics of the UML class diagram notation. As you might expect, the difficulty of presenting an example at this point in the book is that you need to focus your attention on the object-oriented model's UML notation rather than on the details of the specific video store problem domain being depicted by the model. Hopefully, you have purchased or rented a video from a video store and, by doing so, have at least minimal knowledge of the video store problem domain. Some of you may work at a video store or have done so in the past, making you somewhat of an SME. If you fit into this classification, realize that the model presented here probably does not exactly represent the video store information system you have personal expertise with. This is in keeping with Chapter 1's section on "What makes systems analysis and design such a difficult activity" and the opening comments in this chapter that suggest that there are potentially many different solutions for every problem domain. Since this is a model of a fabricated automated information system, please recognize that there could be many other variations to the way this model is being presented. This video store model (with much more detail) was created by a large team of three-dozen or so "aspiring systems analysts" (undergraduate students) working in the classroom for about two months during a semester. The instructor was serving dual roles acting as the senior systems analyst and simultaneously as the video store owner/manager (user). These requirements may or may not be the same as the ones you would come up with working with a different user in a similar problem domain. Remember, the intent here is not to make you subject matter experts for the video store problem domain, but to expose you to a partially completed UML class diagram model of user requirements so that you will know what one looks like "early in the game". Figure 3.9 illustrates the more commonly used UML class diagram notation symbols that are used in the Video Store class diagram in Figure's3.10, 3.11a, 3.11b and 3.11c. The notation is simplistic in that there are only a few symbols, yet it is sophisticated enough to depict large and complex information systems, ones exhibiting functions, data, and behavior. Referring to Figure 3.9, the symbols in the notation are the Class, Generalization Class relationship, Object association, Object Aggregation association, and Object Composition association. Each of these is briefly discussed as we walk through the class diagram because they will be defined and described in greater detail in later chapters. To assist with the discussion of the Video Store's UML class diagram and its notation, Figure 3.10 will be used. Figure 3.10 is the UML class diagram model for the video store's information system for purchasing, selling, and renting inventory items, such as video movies and games, VCRs, and concession items such as popcorn, sodas and candy. In addition, the information system keeps track of these same inventory items when they need to be ordered so that the store will have enough of them to sell or rent to its customers. The video store's user requirements will be identified and discussed in the next chapter. The intent here is to show you the resulting UML class diagram model based on the user requirements that we assume have already been identified. You may recall that a user requirements model of a video store's mission, goals, objectives, and tactics was presented in Chapter 2. Simply stated, classes represent the things that an information system needs to know about within a specific problem domain. Classes can be any of people, places, things, or concepts, such as employee, vendor, store location, rental transaction, video, VCR, and so on. Some classes will never contain objects—we refer to these as abstract classes—while others will contain objects. Abstract classes are used to communicate Generalization (-Specialization) relationships among classes. All other classes in the class diagram should contain objects although that is not a rule, just a good guideline. Objects are the actual instances of people, places, things, and concepts and are always associated with a class—in other words, o objects can stand alone in a class diagram; they must belong to a class. For example, individual video objects associated with the Video class would be each specific movie video that is available for either rent or sale.

In Figure 3.10 Inventory, Saleltem, Rentalltem, and Transaction are abstract classes because they represent two layers of Generalization class relationships. None of them have (or will ever have) object instances. Video, Game, ConcessionItem, VCR, Employee, StoreLocation, SalesTransaction, RentalTransaction, Vendor, Member, PurchaseOrder, SaleRentalLineltem, and POLineltem are all examples of classes that can have objects and will more than likely have one or more object instances. You might be thinking, "How do you determine what is a class with objects and what is an abstract class?" The determination of classes versus abstract classes often surfaces during user requirements discussions with the users or later on as the systems analyst refines the class diagram. Classes and abstract classes are treated similarly in most situations, since abstract classes are simply classes that are and always will be void of objects. The way to distinguish an abstract class from a class with objects on a UML class diagram is to look for the Generalization notation symbol. The class touching the arrowhead is abstract—but that is not a rule either, just a good guideline. Flexibility in this regard is important. Classes have attributes or characteristics that describe them in more detail. For example, in Figure 3.9, the Member class has attributes memberNumber, firstName, lastName, telephone, address, city, etc. Attributes are discussed in much more detail in a later chapter. Classes have operations that the class is responsible for accomplishing. In Figure 3.9, for example, the Member class has checkOutVideo, checkInVideo, and buyItem as its operations. Operations are discussed in much more detail in a later chapter. The next four UML class diagram notation symbols are the Generalization class relationship, Object association, Object Aggregation association, and Object Composition association. All four of these notation symbols are used to associate classes with other classes in the UML class diagram. All classes have responsibilities. One of their responsibilities answers the question, "Whom do I know?" The Generalization class relationship and the three object associations represent this responsibility in the UML class diagram. Each of these four relationship types is briefly discussed next.

The Generalization class relationship notation symbol is used to associate one generalization class with one or more specialization classes in a hierarchical parent-child pattern type of relationship. For example, a SaleItem class, the generalization portion of the parent-child pattern, may have several specialization classes, such as Video, Game and Concession Item. Refer back to Figure 3.5 for another example of the generalization "parent-child" pattern. Often specializations can be thought of as being a "type" or "kind" of the generalization. For example, a game is a type of sale item as well as a type of rental item. The Generalization relationship is a class relationship—as its name implies—and not a relationship between the objects of each of the classes involved in the relationship. The next three notations are used to relate objects to other objects within classes. The Object association UML notation symbol is used to relate two class symbols with each other, however in reality the relationship is really between objects in each of the classes—hence the name Object association. The Object association relationship is used when two un-related classes in the real-world need to be related in order for an information system to perform its work. Often this type of relationship is considered to be "weak" in the sense that the only reason the two classes are related is for purposes of this information system. For example, both SalesTransaction and RentalTransaction classes in Figure 3.10 are connected to the Member class explicitly because members of the video store perform these two types of transactions. Member object—people like you and me—are very different from SalesTransaction and RentalTransaction objects. Constraints are indicated on all three types of Object associations. For example, referring to the SalesTransaction to Member Object association in Figure 3.10, a specific Member may have zero or more (represented by "*" or "0..*") SalesTransactions and a specific SalesTransaction is related to only one specific Member (represented by "1"). Some members never buy anything in a video store; they only rent and these constraints allow for this condition. The Aggregation Object association (the clear/white diamond symbol) and the Composition Object association (the black diamond symbol) UML notation symbols are used to associate two class symbols in a "Whole-Part" pattern type of relationship. The difference between these two associations will be discussed in a later chapter, and the "whole" object in the association is touching the diamond symbol while the "part" object in the association is touching the end of the line. For now, a generic example of such an association is an Automobile class and an AutomobilePart class. The Automobile class would be the "whole", and it would have several AutomobilePart "part" type classes such as Door, Window, Wheel, Seat, Gauge, and so on associated with it. In Figure 3.10, the PurchaseOrder class represents a "whole" portion of the whole-part pattern and the POLineltem class represents the "part" portion of the pattern. Also the SaleRentalLineltem class is the "part" portion of both the SalesTransaction and the RentalTransaction classes. The constraint notations associated with these symbols in Figures 3.9 and 3.10 will be discussed in detail in a later chapter. Basically, this notation represents constraints placed on the object connection relationship. For example, the "1..*" notation next to the diamond symbol in Figure 3.9's Aggregation Object association notation is to indicate how many "whole" objects are associated with one "part" object. The "0..*" notation at the bottom of the same symbol in Figure 3.9 is to indicate how many "part" objects are associated with one "whole" object. In Figure 3.10 the Vendor class has a relationship with the PurchaseOrder class. Vendor represents businesses or individuals that the video store purchases inventory from. PurchaseOrder represents a business transaction and identifies inventory items that are purchased from a vendor. The Vendor to PurchaseOrder relationship constraints in Figure 3.10 indicate that a specific Vendor may have zero or more (represented by the "*") PurchaseOrders and a specific PurchaseOrder is related to only one specific Vendor (represented by the "1"). Figure 3.10's video store UML class diagram omitted information about attributes and operations simply because I wanted to get the entire class diagram into one figure. Figures 3.11a,b, c expand upon Figure 3.10 by including the attributes and operations. Additional diagram model details become important and necessary at some subjective point during systems analysis. Looking at Figure 3.10, the UML class diagram model has two additional levels of detail: (1) attributes, and (2) operations. Attributes and operations help communicate more about what data (attributes) are associated with the information system, and what functions (operations) are performed by the information system. As you look at Figure's 3.11a,b and c, keep in mind that these three figures are the exact same model as shown in Figure 3.10, just with additional details. Due to the extent of the details, the model was divided into three sections in order to fit on the pages of this book. Using a computer-based IDE tool to draw this UML class diagram, you would have it all connected even though you might only see sections of the diagram at any moment in time on the computer's monitor (screen). As described earlier, attributes are characteristics that describe a class in more detail. Sometimes the name of a class, such as StoreLocation in Figure 3.10, is not sufficient to communicate its intended purpose in the system. Looking at this class's attributes might help communicate its intended purpose. For example, StoreLocation's attributes are storeNumber, storeAddress, storeCity, storeState, storeZipcode, and storePhone. The data values associated with these attributes indicate that the system needs to keep track of the video store's identification information for various reasons. One reason could be to print it on certain reports. Another reason could be the need to consolidate two or more video store's data together in the information system and still be able to electronically separate it into the data belonging to each store.

Are the attributes shown in Figure 3.11a,b,c all of the attributes that this information system will have? Probably not! As the systems analyst progresses through analysis and into design, additional attributes may surface and become important to keep track of and would be added to the information system via a change to the applicable UML models with the user's approval. Attributes are discussed in much more detail in a later chapter. Operations, as described earlier, represent the transformations, actions or functions that a particular class of objects must accomplish in order to help fulfill the overall mission of the information system. An operation is associated with one and only one class, the one in the real world most closely associated with the function to be performed. That is why there are more operations in the Member class than any of the other classes. Keep in mind that a member initiates much of what happens in a video store, and the “motto” of a class (object) is “I do it myself”. Are these all of the operations that this information system will have? Probably not! As the systems analyst progresses through analysis and into design, additional operations may surface and become important and required for the information system to accomplish its mission. These newly discovered operations would be added to the information system via a change to the appropriate UML models, similar to the way attributes are added, with the user's approval. Operations are discussed in much more detail in a later chapter. As you look at the details in Figure 3.11's class diagram, you will notice that several classes have no attributes and operations shown in them. For example, Video, Game, ConcessionItem, and VCR have no attributes and no operations listed in their respective class symbols. This is okay since each of these classes is the Specialization part of a Generalization class relationship. In a Generalization class relationship, all specialization classes inherit all the attributes and all the operations from the generalization. Therefore, ConcessionItem has the same attributes and operations as Inventory and Saleltem combined. VCR has the same attributes and operations as Inventory and RentalItem combined. Finally, Video and Game have the same exact attributes and operations as Inventory, SaleItem, and RentalItem combined.

This concludes the review of the video store UML class diagram model. Remember, Figures 3.10 and 3.11 are object-oriented and represent the very important foundational and static structure (architecture) of the proposed video store’s information system. There are still several other UML models to create that will collectively represent the “blueprints” for the video store’s information system. The next few chapters will explore the simplistic object-oriented methodology activities described earlier in this chapter as it is used to create and refine the UML notations and models for defining and documenting the requirements for an information system.

SUMMARY

This chapter has defined and described a methodology as the way one thinks about or performs an activity in order to complete it successfully. Each of four major methodology classifications was presented and discussed—traditional, structured analysis and design, information engineering, and object oriented. Eight foundational building block concepts—common methods of organization, abstraction, encapsulation, inheritance, polymorphism, message communication, associations, and reuse—for an object-oriented methodology were also presented and discussed. Not all of them are new, which is a good thing. Another fundamental concept of an object-oriented methodology was presented and discussed—Classification Theory. This theory is common to most people, thus making its use within an object-oriented methodology a more natural activity. Following this, a simplistic object-oriented systems analysis and design methodology was presented and briefly discussed. Much more will be discussed and presented regarding this methodology throughout the remainder of the book. Understanding and knowledge of a problem domain along with understanding and experience using a methodology and notation are important for successfully documenting user requirements for an information system. The UML’s Class Diagram notation consists of several symbols including Class, Generalization class relationship, Object Association, Object Aggregate Association, and Object Composite Association. A partially completed UML Class Diagram of a video store information system problem domain was presented to show how the UML Class Diagram notation symbols are combined to depict the user's requirements for an information system using a Class Diagram. Finally, the Class Diagram model was expanded to reveal attributes and operations along with a discussion of these model features

QUESTIONS (note: questions with an asterisk "*" are new in this edition and have not been answered)

3.1 What is a methodology?
3.2 Briefly discuss the different ways of acquiring a methodology.
3.3 How would you best describe the traditional methodology classification?
3.4 Given your answer to the previous question, what is the major disadvantage of this type of methodology?
3.5 Why is the structured analysis and design methodology sometimes called the data flow modeling methodology?
3.6 How has computer-aided software engineering (CASE) or IDE changed the structured methodology?
3.7 What problem-solving approach is at the heart of an information modeling methodology?
3.8 How does an information modeling methodology differ from the approach used in a structured analysis and design methodology?
3.9 How does the approach taken in an object-oriented methodology differ from strategies employed by the information modeling methodology?
3.10 List and describe the eight foundational characteristics of an object-oriented methodology.
3.11 What role does abstraction play in an object-oriented methodology?
3.12 What is another term for encapsulation, and what is its purpose within an information system?
3.13 What is one of the main advantages of reuse within an object-oriented methodology?
3.14 Discuss a few of the roadblocks that are standing in the way of industry acceptance of reuse.
3.15 What significant aspect of an object-oriented methodology resolves problems associated with the older methodologies?
3.16 What are the three concepts within Classification Theory and how do they relate to object-oriented methodology?
3.17 What is meant by reuse? What role does it play in systems analysis and design?
3.18 Name and discuss the different types of reuse that are possible.
3.19* Describe the Unified Modeling Language (UML).
3.20* List and briefly describe the basic UML notation symbols.
3.21 If you wanted to draw a picture of an information system, what would you need, at minimum, to undertake this task?
3.22 Define notation and briefly explain its importance in modeling an information system.
3.23 Define and give a few examples of the class and class-with-objects notations.
3.24 What is the importance of the class and class-with-objects symbol notations within the problem domain component of the object model?
3.25 What are the two additional elements usually found within the class and class-with-objects notations and what is their purpose?
3.26* What is the purpose of the generalization class relationship within the UML?
3.27 Distinguish the whole-part object connection symbol from the generalization-specialization connection symbol.
3.28* What is the main purpose of the "*" and "1" notation in an object association?
3.29 What is the nature of relationships as symbolized by the object association?
3.30* Define parallelism, substitution and omission as they relate to information systems development.
3.31 Why is it sometimes helpful to identify attributes within a class earlier than usually done?
3.32 What distinguishes an operation from an attribute within a class?

REFERENCES

Ambler, S., "Enhancing the Unified Process", Software Development, October 1999, pp. 33-39.

Bahrami, A., Object-Oriented Systems Development Using the Unified Modeling Language, Irwin McGraw-Hill, Boston, MA, 1999.

Booch, G., Rumbaugh, J. and Jacobson, I., The Unified Modeling Language User Guide, Addison-Wesley, Reading, MA, 1999, ISBN # 0-201-57168-4.

Booch, G., Object-Oriented Analysis and Design with Applications (2nd ed). Menlo Park, CA: Benjamin/Cummings, 1994.

"Classification Theory," Encyclopedia Britannica, 1986.

Coad, North, P., D. and Mayfield, M., Object Models: Strategies, Patterns, and Applications. Prentice Hall, Englewood Cliffs, NJ, 1995.

Coad, P., and Yourdon, E., Object-Oriented Analysis (2nd ed.). Englewood Cliffs, NJ: Yourdon Press/Prentice Hall, 1991.

Coad, P., and Yourdon, E., Object-Oriented Design. Englewood Cliffs, NJ: Yourdon Press/ Prentice Hall, 1991.

Cox, B.J., Object-Oriented Programming: An Evolutionary Approach. Reading, MA: Addison- Wesley, 1986.

Dahl, Ole-Johan and Nygaard, Kristen, "Simula, An Algol-Based Simulation Language", Communications of the ACM, Vol. 9, No. 9, September 1966, pp. 671-678.

Eriksson, H. and Penker, M., UML Toolkit, John Wiley & Sons, New York, NY, 1998.

Firesmith, D.G., "Basic Object-Oriented Concepts and Terminology: A Comparison of Methods and Languages," White Paper from Advanced Software Technology Specialists (ASTS), Fort Wayne, IN, January 3, 1994, 37 pages.

Fowler, M., UML Distilled, Addison-Wesley, Reading, Massachusetts, 1997.

Henderson-Sellers, B., A Book of Object-Oriented Knowledge. New York: Prentice-Hall, 1992.

Jacobson, I., Booch, G. and Rumbaugh, J., The Unified Software Development Process, Addison-Wesley, Reading, MA, 1999, ISBN # 0-201-57169-2.

Jacobson, I., CHRISTERSON, M., JONSSON, P. and OVERGAARD, G., Object-Oriented Software Engineering. New York: Addison-Wesley, 1992.

Kay, Alan C., "Microelectronics and the Personal Computer", Scientific American, Vol. 237, No. 3, pp. 230-244.

Larman, C., Applying UML and Patterns, Prentice-Hall, Upper Saddle River, NJ, 1998.

Meyer, B., Object-Oriented Software Construction. Hemel Hempstead, United Kingdom: Prentice Hall, 1988.

Olle, T.W., et al., Information Systems Methodologies: A Framework for Understanding. Wokingham, England: Addison-Wesley, 1988.

Olle, T.W, Sol, H.G. and Tully, C.J. (eds.), Information Systems Design Methodologies: A Feature Analysis. Amsterdam: North-Holland Publishing Co., 1983.

Olle, T.W, Sol, H.G. and VERRUN-STUART, A.A. (eds.), Information Systems Design Methodologies: A Comparative Review. Amsterdam: North-Holland Publishing Co., 1982.

Quatrani, T., Visual Modeling with Rational Rose and UML, Addison-Wesley, Reading, Massachusetts, 1998.

Rumbaugh, J., Jacobson, I. and Booch, G., The Unified Modeling Language Reference Manual, Addison-Wesley, Reading, MA, 1999, ISBN # 0-201-30998-X.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W., Object-Oriented Modeling and Design. New York: Prentice Hall, 1991.

Shlaer, S. and MELLOR, S.J., Object-Oriented Systems Analysis: Modeling the World in Data. Englewood Cliffs, NJ: Yourdon Press/Prentice Hall, 1988.

Wirfs-Brock, R.I., Wilkerson, B. and Wiener, L., Designing Object-Oriented Software. New York: Prentice Hall, 1990.

Yourdon, E., Object-Oriented Systems Design: An Integrated Approach. New York: Prentice Hall 1994.