Object-Oriented Systems Analysis & DesignInstructor’s Manual
Preface.
A textbook is not a self-study guide. A textbook needs a teacher and the teacher needs tools to bring the textbook to life. A printed book serves abstract teachers and abstract students, but the teachers and the students are never abstract: Teachers have different approaches and styles — all equally valid — and students have different backgrounds, goals and attitudes.
All instructors’ manuals share familiar features: Chapter overviews, objectives and outlines, answers to review questions, discussion notes, exercises and case studies. In this manual, our goal it to provide something more to enable the teacher to tailor the course to concrete preferences and needs. As a result, certain familiar topics require some clarification:
Review Questions.
Review questions echo the “short answer” questions for the test bank. We have done this on purpose.The review questions cannot be answered by memorizing the text, but by understanding and exploring the concepts that the text puts forward. Therefore, we suggest that, after completing a chapter, students participate in a discussion session on review questions. (The teacher, of course, decides which questions are best suited for the class and how to conduct the discussion thread.) When students try to explain a difficult concept to each other, they would understand it better themselves.
To encourage the students to participate in the discussion and give it their bests, the instructor may inform them that some of the review questions would be included in the tests. (This, usually, concentrates many minds, even those that might not have paid much attention to the chapter itself.)
Case Studies.
Introducing new case studies for each chapter in the midstream of teaching a course on systems analysis and design is not an advisable tactic. A case study for IS development is more like a mini-series than a sitcom: you cannot make good sense of it if you start it in the middle. Continuity is essential, both for learning how to develop a system and actually developing it.
With this in mind, we have presented four ongoing cases that appear at the end of each “hands-on” chapter. (Cases start from chapter four as the first three chapters lay the conceptual foundations for the rest of the book.) Exercises for each chapter build on the results of those in the preceding chapters and, collectively, they provide a context for understanding the theories presented by the book.
We have, of course, provided solutions for case studies, but our solutions are not what the exercises are all about. Even seasoned systems analysts and designers would not approach the same problem the same way, and would not produce analysis or design artifacts that look the same. In other words, there is no one definitive or one correct solution to any of the cases. (This observation includes our solutions as well.)
This may appear as a problem for teaching the course. Students want definitive solutions (or so the theory goes). In fact, it is the opposite. It is an opportunity, not a problem. When the students, individually or as study groups, put their solutions to the review of the class, they will find out that sponsors of different solutions can be as justified in their conclusions and assumptions as they believe they themselves are. In essence, they would grasp the book’s methodology by practicing it.
Many of the exercises need modeling tools. We have (often but not always) used Rational Rose, the modeling tools created by the framers of UML and now owned by IBM. There are, however, many good and adequate free modeling tools that the students can download from the Web. It is up to the instructor to decide whether the students can use different modeling tools or must use the one selected by the instructor.
Please note that solutions to case studies are found under a different folder than the rest of Instructor’s Manual. The folder is “Solutions for Case Studies.”
Research Projects & Teamwork.
This repeating topic encourages students to use both online and printed materials. We have provided guidelines for managing teams and encouraging students to build their analytical and teamwork skills. The frameworks for research projects are much looser and wider than those in case studies. Whereas in case studies the students must apply their learning to concrete examples, in most research projects they must find how others have applied the same concepts to other problems.
Again, none of the projects have one definitive answer and the assignments should be evaluated on a “comparable basis.” For example, which group has done a more comprehensible research.
Discussion Notes.
Discussion notes supply the teacher with “war stories.”In some chapters, they provide the history of a concept;in others, they provide the rationale for what the text argues. In all cases, they try to present highly abstract ideas in terms that are more familiar to everyday experience.
Examples.
Like most textbook authors, we wish we could have included more examples in the printed book. We could not, but they are here and the instructor can select them for presentation as he or she sees fit.
The examples include use cases that we developed for our main ongoing case, WaldenHospital. Though the printed book presents the basic template for use cases, effective use of the template requires examples that, we hope, these additional examples would provide.
Table of Contents
Chapter 1. Information Systems.
Overview...... 8
Objectives...... 8
Outline...... 8
Review Questions & Answers...... 11
Research Projects & Teamwork...... 12
Discussion Notes...... 13
Next: The Concept of Object Orientation...... 13
Chapter 2. The Concept of Object Orientation.
Overview...... 15
Objectives...... 15
Outline...... 15
Review Questions & Answers...... 17
Research Projects & Teamwork...... 19
Discussion Notes...... 19
Next: Methodology...... 21
Chapter 3. Methodology.
Overview...... 23
Objectives...... 23
Outline...... 23
Review Questions & Answers...... 26
Research Projects & Teamwork...... 30
Discussion Notes...... 30
Next: Gathering Requirements...... 31
Chapter 4. Gathering Requirements.
Overview...... 32
Objectives...... 32
Outline...... 32
Review Questions & Answers...... 34
Research Projects & Teamwork...... 36
Discussion Notes...... 36
Examples...... 38
Next: Domain Analysis...... 43
Chapter 5. Domain Analysis.
Overview...... 44
Objectives...... 44
Outline...... 44
Review Questions & Answers...... 45
Research Projects & Teamwork...... 47
Discussion Notes...... 47
Examples...... 53
Next: Behavioral Modeling II – Use Cases: The Basics...... 56
Chapter 6. Behavioral Modeling I – Use Cases: The Basics.
Overview...... 58
Objectives...... 58
Outline...... 58
Review Questions & Answers...... 59
Research Projects & Teamwork...... 61
Discussion Notes...... 61
Next: Behavioral Modeling II – Developing Use Cases...... 65
Chapter 7. Behavioral Modeling II – Developing Use Cases.
Overview...... 67
Objectives...... 67
Outline...... 67
Review Questions & Answers...... 69
Research Projects & Teamwork...... 71
Discussion Notes...... 71
Examples...... 72
Next: Structural Modeling...... 79
Chapter 8. Structural Modeling.
Overview...... 80
Objectives...... 80
Outline...... 80
Review Questions & Answers...... 82
Research Projects & Teamwork...... 85
Discussion Notes...... 85
Examples...... 88
Next: Dynamic Modeling...... 92
Chapter 9. Dynamic Modeling.
Overview...... 93
Objectives...... 93
Outline...... 93
Review Questions & Answers...... 96
Research Projects & Teamwork...... 99
Discussion Notes...... 99
Next: The Design Challenge...... 101
Chapter 10. The Design Challenge.
Overview...... 102
Objectives...... 102
Outline...... 102
Review Questions & Answers...... 104
Research Projects & Teamwork...... 104
Discussion Notes...... 106
Next: Application Design I: Flow & Control...... 107
Chapter 11. Application Design I: Flow & Control.
Overview...... 109
Objectives...... 109
Outline...... 109
Review Questions & Answers...... 111
Research Projects & Teamwork...... 114
Discussion Notes...... 114
Examples...... 114
Next: Application Design II: The User Interface...... 117
Chapter 12. Application Design II: The User Interface.
Overview...... 118
Objectives...... 118
Outline...... 118
Review Questions & Answers...... 119
Research Projects & Teamwork...... 121
Next: Application Design III: Database & Persistence...... 121
Chapter 13. Application Design III: Database & Persistence.
Overview...... 122
Objectives...... 122
Outline...... 122
Review Questions & Answers...... 124
Research Projects & Teamwork...... 127
Discussion Notes...... 127
Examples...... 128
Next: Patterns...... 130
Chapter 14. Patterns.
Overview...... 131
Objectives...... 131
Outline...... 131
Review Questions & Answers...... 132
Research Projects & Teamwork...... 133
Discussion Notes...... 133
Next: Components & Reuse...... 134
Chapter 15. Components & Reuse.
Overview...... 135
Objectives...... 135
Outline...... 135
Review Questions & Answers...... 137
Research Projects & Teamwork...... 139
Next: Architecture...... 139
Chapter 16. Architecture.
Overview...... 140
Objectives...... 140
Outline...... 140
Review Questions & Answers...... 144
Research Projects & Teamwork...... 147
Discussion Notes...... 147
Next: Implementation...... 148
Chapter 17. Implementation.
Overview...... 149
Objectives...... 149
Outline...... 149
Review Questions & Answers...... 151
1.INFORMATION SYSTEMS
I.Overview
Information systems are systems that process data into information. An information system can be viewed from various perspectives: its goals, its processes or its components, i.e., applications, information technology, people and procedures.
Information systems are also products and, like other products, they must satisfy their consumers and must be developed by following a methodology that assures the best possible quality and the best possible use of resources.
II.Chapter Objectives
- Define information, system, information systems, and information technology.
- Learn about the building blocks of information technology.
- Understand the difference between information systems and software applications.
- Learn about the business of making information systems.
- Describe information systems as infrastructure.
- Learn about the enterprise of making information systems.
III.Chapter Outline
Information & its components
Information is a set of data organized in a way that conveys knowledge or enables its recipient to execute a set of actions to reach an objective. Information has three main constituents: data, goal and logic. If any of one these elements are missing, then data does not become information.
The relationship between data and information is hierarchical: what is information at one level can become data at a higher level that strives for a larger meaning.
System & its components
A system is an assembly of interrelated elements or components that together make the system a distinct “whole.” The components of a system must have a formalstructure and the system as a whole must have a recognizable identity. Therefore, a monolithic entity is not a system; neither is an entity without a distinct identity.
A system may consist of other systems or it may be a subsystem of a larger system. As a result, the relationship between systems can become hierarchical.
Information systems
Information systems consist of applications, information technology, people, processes and procedures. An information system is an opensystem that processes data into information according to a set of clear and unambiguous logical assumptions.
Features that an information system inherits from information and systems constrain each other. An archive stores data systematically, but it does not produce information; therefore an archive is not an information system by itself (even though it is very likely to be a part of information technology).
Information technology
Information is virtual and, consequently, needs a medium with physical presence to make it tangible. This vehicle is provided by information technology, a collection of methods, tools, material and know-how that support an information system.
Information technology is not one entity, but a set of interrelated components:
- Know-how is the knowledge and the skill required to do something correctly. Without know-how, other components of technology are wasted.
- Method is a systematic way of reaching an objective. Methods function as guideline to people with know-how to accomplish a task. In turn, new experiences must refine existing methods.
- Materials are frequently seen as the only components of technology, perhaps because they are tangible whereas know-how and methods are not. But even though no technological revolution is possible without them (consider paper and printing), they constitute only one side of the technology triangle. (Consider, again, paper and printing: paper, lead and wine press were available to Europeans long before Johannes Gutenberg invented moveable type printing in the 15th century.)
The building blocks of information technology
Information technology is composed of one or more processing units and three systems:
- The Processing Unit
- The Communication System.
- The Data Management System.
- The Control System.
Information automation, largely the gift of computer technology, is the application of information logic by a device that executes a program.
Information systems & applications
An application is a set of one or more programs that performs a specific task. At the early stages of the software revolution, when automation requirements were modest, applications were seen as independent entities and were created as monoliths. As the complexity of software products has become overwhelming, however, applications must be viewed and developed as integral parts of information systems. Fortunately, the technology to build systems instead of monoliths is now mostly mature.
Information systems as products
The increasing complexity of information systems is driving software development out of in-house shops and into companies that specialize in the various fields of software development. As a result, to be successful, software must be conceived as a product, designed as a product and marketed as a product.
At the same time, information systems are turning from tools of business, trade and administration into an integral part of the enterprise. Today, information is becoming an asset equal in importance to others such as expertise, organization, equipment, property, labor, and capital. Information, like other assets, must be managed, stored, bought and sold (and is, sometimes, stolen). Managing information systems has evolved to a level of complexity that it now requires a functional division of its own within most organizations.
The business of making information systems
Production of information systems and/or their components is increasingly becoming a business in its own right. Today, we can distinguish several sectors in the software industry:
- System Software: operating systems, utilities and other basic components of information technologies.
- Software Components: parts that are assembled and combined by their buyers to create complete systems and applications.
- Software Contractors: build custom software for enterprises that need very specialized solutions.
- ERP:Enterprise Resource Planning software products aim at satisfying the enterprise-wide information needs of a corporation within a unified system.
- Mass Market Software: general-purpose products that are targeted at end-users.
Information systems as infrastructure
Infrastructural information systems are a set of systems and applications that support the basic functions of an enterprise. They can be classified into several broad categories including:
- Transaction Processing Systems (TPS): record and process data about the routine activities of an enterprise.
- Business-to-Business (B2B) Systems: allow businesses to conduct transactions or exchange of information online.
- Business-to-Consumer (B2C) Systems: allow consumers to buy products and services directly from businesses online. Both B2B and B2C are often called e-commerce.
- Business Intelligence (BI) Systems: a set of subsystems and applications that allow the management to analyze operational and market data, create models, make forecasts and test business decisions virtually. Whereas previous systems provide tactical advantages, BI must provide a strategic view.
- Artificial Intelligence (AI) & Robotics: enable machines to automatically perform tasks that otherwise would require human intelligence, solve complex problems by using non-mathematical algorithms, simulate real or imaginary environments, and provide expert opinion by using available information, heuristic, and inference. AI is used in a vast and expanding array of products: robotics, forecasting, virtual reality (games and simulations) and expert systems.
The enterprise of making information systems
Software is a product and software development must follow the discipline of product development. Products are not developed in the exact same manner, but certain general guidelines apply to all.
The first is to identify requirements. Requirements describe the objectives of the product. But they are not the same as product specifications. A finished product has two sets of features: one set satisfies business requirements, while the second set make the first set possible. A bicycle must have two wheels and be light (requirements), but the wheels must be sturdy enough not to bend. By using spokes (a solution feature) the requirements are met, but spokes are not part of requirements.
Product development must follow a methodology, a set of practices, procedures, rules and techniques. Methodology results from abstracting and organizing experience within a theoretical framework. In simpler times, when demands on software were modest, methodology did not play a role. The ever-increasing complexity of information systems, however, makes methodology indispensable.
The development of any product by a team under time and financial constraints is in need of project management: planning, monitoring and controlling the course of the development process and the resources used by that process. Project management has general principles, practices and guidelines, but must be adapted tothe goal of the project, tothe resources available to a specific project, and tothe methodology used to achieve the goal.
In product development, it is prudent to distinguish between problem space and solution space. Problem space is the source of requirements; it is the environment in which the final product must work and solve problems. The solution space, on the other hand, contains issues that are related to the product (solution) itself, not the problems addressed by the product. In problems space, we analyze business problems and their related concepts; in solution space we design the product. The two spaces, however, overlap and affect each other.
IV. Review Questions
1.Explain the difference between data and information. Give two examples for each.
Data is any fact or assumption that is combined with other data to constitute a meaningful message – information. The patterns, associations, or relationships among all this data can provide information. For example, analysis of retail point of sale transaction data can yield information on which products are selling and when. Examples of information are:
- The year-end balance sheet of a company.
- A business report.
- A bank statement.
Data are the building blocks of information. Data are any facts, numbers, or text that can be processed by a computer. Today, organizations are accumulating vast and growing amounts of data in different formats and different databases. This includes: