Oracle Designer Handbook, 2^nd Edition - Introduction

© 1999 The McGraw-Hill Companies

12-Step Program for Traditional System Development

1. Come up with a cool acronym and figure out a mission-critical system that fits the acronym.
2. Get a bunch of money to build the system and divert the money to other over-budget projects.
3. Use junior developers because everyone else is too busy.
4. Hire inexperienced consultants because they give you the best rate.
5. Don't bother with system requirements because you already know what the users want.
6. Fire the consultants. They were too slow. Hire a new team from a big expensive consulting firm.
7. Have each developer design their own portion of the database because they know exactly what tables they need.
8. Do your prototypes in MS Access even though you will be deploying with Developer Web Forms.
9. Just start coding, because the project is way behind schedule.
10. Don't bother with system or user documentation, since no one reads that stuff anyway.
11. Have the developers do user acceptance testing because they are the only ones who really understand how the system should work.
12. Write vague and misleading status reports to give the illusion of progress. Then write a system work request to propose what you actually accomplished. Backdate it and declare victory.

The process of designing and building automated information systems is greatly influenced by the software tools used to assist in the process. Systems analysts, designers, and developers turn to Computer-Aided Software Engineering (CASE) programs to capture information about business requirements, create a design for the data structures to fulfill these requirements, and generate front-end and server program code. Since CASE tools automate much of the manual, repetitive, and error-prone work needed for system development, they can, when properly used, greatly increase the productivity of those who produce the systems They can also greatly increase the accuracy of the design and robustness of the implementation. These tools become such an important part of the mechanics of creating systems that it is impossible to separate the process from the tools.

Oracle Designer, Oracle Corporation's CASE product now at Version 2.1 (formerly called Designer/2000), represents an unparalleled achievement in Oracle's ability to support all phases of traditional, as well as alternative, System Development Life Cycle methods. One such method is presented in Richard Barker's Oracle CASE books, which serve as excellent overviews. Unfortunately, these books are often misused by developers who follow them dogmatically, or mistakenly believe that the books, together with the Oracle Designer product, form a complete development methodology. These books were never intended to serve as complete methodology guides, as each step in the development life cycle really deserves its own book.

The Approach of This Book

This book represents a revision of the first development method fully integrated with Oracle's Oracle Designer product. Its purpose is to show the practical steps and methodological phases of producing software, in addition to specific ways in which the Oracle Designer tool can support them. Our work here has two objectives. The first is to revise and expand on the CASE method. We have gone into more detail than have the original CASE books, added more deliverables, and restructured the whole process in addition to discussing the features of Oracle Designer v. 2.1. The second objective is to describe how Oracle Designer can best be used to support our revised CASE method.

We call this revised method the CASE Application Development Method (CADM). This book represents a serious departure from traditional books about the System Development Life Cycle and traditional books about software products. It is an integration of these two distinct types of books. Rather than saying, "this is a book on how to build systems" or "this is a book about how to use Oracle Designer," we say "this is a book about how to build systems using Oracle Designer." We have combined the best industry practices for system development with the best integrated CASE tool on the market-Oracle Designer.

One of the main goals of this book is to present a development process that tracks the path of a business requirement from its original source, typically gathered during Analysis, to its eventual implementation in the system. We wanted to formulate a process that would guard against encountering the scenario in which a user shows up at the end of a project with interview notes gathered six months earlier, points to a paragraph, and says, "We wanted this in our system and it's not here. You signed off on this. Where is it?" In order to avoid this frightening scenario, our entire development process is driven by business requirements. This book discusses the methodology itself-what you need to think about, talk about, and do as you progress through the System Development Life Cycle.

Another goal of this book is to include a very strong quality assurance component with virtually every aspect of every phase of the development process. It doesn't matter that you have a great application development method if the developers don't follow it carefully. The key to the success of CADM is making sure that each phase is correctly completed prior to moving on to the next.

While this book presents an expanded variation of the traditional "waterfall" life cycle, the authors recognize that there are many other valid methodologies used successfully. They find, however, that these alternative methods have many of the same features, and even in some cases, the same phases as this waterfall approach, although these phases may be expanded or collapsed. Therefore, the techniques presented in this somewhat traditional, but arguably, complete approach should be portable to other methods.

The exciting part of this is that Oracle Designer supports these alternative methods as well as the CADM described in this book. The way it is both compartmentalized and integrated hides many of the complexities involved with how it can support these different methods. The foundation for all system development work you do is in intelligent use of a well-structured, central repository of information about the system you are creating or maintaining. This is where Oracle Designer excels and this is what makes it a perfect tool for every design and development environment.

The book also contains information on what processes Oracle Designer can support in each of the CADM phases and how it supports them. It supplies details, not found in other sources, for effective use of the tools, and explains what information is important to gather at each stage. The book also mentions where to find this information for each step of the development process. Interspersed in these discussions, as well as discussions of the methodology itself, are tips and techniques for productive work in the tool.

Comments on the Second Edition

Since writing the first edition of this book, there have been two important changes in our development environment. The first is that Oracle Designer has matured as a product. The quality of the user interface has greatly improved, as has Designer's ability to generate code. Second, over the last few years, we have changed some of our thinking about systems development.

We now recognize that the development phases are not as discrete as we initially believed. Instead, many activities and deliverables refuse to fall neatly into one phase or another, but span the whole systems development life cycle. At some points, we may even break out a portion of a project and carry it through to production in order to validate the development effort. As opposed to "top-down" development (the traditional SDLC model) or "bottom-up" development (a more RAD-oriented approach), this is "middle-out" development and it deserves serious attention as a formal methodology.

Like systems development, this book is also a work in progress. In this edition, because our thinking has changed, we have added some chapters on topics we felt were missing in the first, such as data migration and adapting CADM to a rapid development environment, and reorganized some aspects of the development phases. There are still many things to learn. As we discovered while working on the first book, the tools greatly influence the methodology. This became one of the core principles behind CADM and will doubtless influence our direction again in the next edition.

Despite the substantially increased length of this book, it is still a cursory overview of the topic of how to use Oracle Designer for effective systems development. Many sections deserve to be books in their own right. In fact, this has already been done with Database Design in Oracle Press's Oracle8 Design Using UML Object Modeling (Dr. Paul Dorsey & Joseph Hudicka, 1998) and another Oracle Press book specifically about the Oracle Designer generators. Additional books could easily be written on the topics of Analysis, Testing, Application Design Standards (including GUI and coding standards), Data Migration, and WebServer Generation.

Organization of This Book

This book is divided into four parts. Part I contains an overview of the CADM methodology and of Oracle Designer in Chapters 1 and 2, respectively. Part II (Chapters 3-21) provides details on each phase of the methodology, as well as on the Oracle Designer tools and utilities that support each phase. Each phase is discussed in one or two chapters, although discussions of the Test, Implementation, and Maintenance phases are combined in one chapter. The material on Oracle Designer is woven into this methodology discussion and picks up where the installation process leaves off. There is a chapter following the chapter on each phase discusses the Oracle Designer support for activities in that phase.

The CADM life cycle we present in this book progresses in a linear way from one phase to another. We recognize, however, that system development is not a simple, linear process. The scope of a project can change at any time. New user requirements can be discovered anywhere in the process, even in the Test phase. In addition, quality-control checks can fail. In general, reality always creeps into our theoretically clean process. Therefore, Chapter 21 discusses how to respond to the unexpected.

Part III, new in the second edition, addresses topics that fall beyond the traditional SDLC. Chapter 22 covers a Rapid Application Development (RAD) modification to CADM for small to medium-sized projects. Chapter 23 discusses how to modify the CADM process when you need to "start in the middle" of a previously attempted project. Chapter 24 covers Business Process Reengineering, and Chapter 25 discusses the often overlooked, but critical to the success of a project, topic of Data Migration.

Part IV contains information on several Oracle Designer features that you use throughout the methodology phases. In particular, Chapter 26 outlines application system and repository maintenance, Chapter 27 discusses Oracle Designer's user extensibility options, and Chapter 28 introduces the Application Programmatic Interface. Chapter 29 covers the all-important topic of how information flows within the repository and how element definitions in one phase are copied to definitions in another phase.

Since many Oracle Designer tools and utilities are used in more than one phase, discussion of a particular tool may be spread across more than one chapter. You can refer to the "Oracle Designer Contents at a Glance" following the table of contents if you are interested in where in the book to find the major discussions of a particular tool or utility.

The Sample Data Model

You will find examples throughout the Oracle Designer chapters of this book based on a student registration tracking system called CTA (Computer Training Associates), which is also the name of a fictitious company. These examples do not use a case study approach so the business rules and implementation details are not critical to the discussions. Nevertheless, it is useful to go through a quick explanation of what the CTA system can do.

The CTA system tracks the registration of students in the program; enrollment of students in classes; and grading of students for course work. It manages the assigment of instructors to sections (instantiations of a course). It also stores profile information of the students and instructors and provides the ability to issue invoices based on the enrollment information and grade reports based on the grades of work that the students complete.

Each of the main entities in the system is represented by a table that stores its information: STUDENTS, INSTRUCTORS, COURSES, SECTIONS, ENROLLMENTS, WORK_GRADES. Since the volume of students is quite high, the postal code information is stored in a separate structure ZIPCODES which can be joined to the STUDENTS and INSTRUCTORS tables to look up the city and state part of the address. These principles should help in understanding the examples in this book.

Why Use Oracle Designer?

Oracle Designer is still the best integrated CASE product on the market. Its capabilities greatly influence the CADM process. Oracle Designer's ability to track data and process information in a single repository makes it an invaluable aid. In addition to its built-in breadth and depth, Oracle Designer offers User Extensibility and the Application Programmatic Interface (API). These features allow you to extend the capabilities of Oracle Designer to support aspects that the Oracle product designers chose not to implement in the core product or that are specific to your working environment.

In general, Oracle Designer promises to make application system development more accurate and flexible, as shown in the following table. This is because Oracle Designer provides a way to capture and manage the often voluminous data associated with a new or current system. The data can be so unmanageable that systems designers end up ignoring or overlooking key business needs or spending too much time developing the system and, along the way, lose sight of the requirements.

Why CASE Projects Fail

CASE tools have historically been viewed as a waste of time and resources because project leaders who bought into the concept could not support the huge learning curve required for their staff. If time was not devoted solely to learning the tools and how they were supposed to work, the project was delayed significantly or failed totally. Due to these early negative experiences, a stigma was attached to the word "CASE," and many companies would not touch it. Oracle (as well as other CASE vendors) has therefore reworked the idea and expunged the word "CASE" from documentation and discussions of the current product. Oracle Designer is, nonetheless, a CASE tool, and while the product is much deeper and easier to use than previous versions, the learning curve is still significant. Ignoring this fact may still cause projects to fail.

Another major reason for the failure of CASE projects was that CASE users who did not understand the software development process relied on the product to lead them through the life cycle, one step at a time. While this is somewhat possible in the current version of Oracle Designer, it was not and still is not possible to expect the CASE tool to do the driving. After all, CASE is "Computer-Aided" not "Computer-Driven" Software Engineering. A CASE tool should not be confused with a methodology. The methodology, rather than the tool, defines our procedures.

Determining the Methodology

When developing a system, care and attention must be given to the development methodology. One of the important influences of a methodology is the tool selected for the task. In particular, CASE tools have the strongest impact on the development method because of their direct influence on all phases of the project. As we just mentioned, the danger is that the CASE tools become the methodology. If the tools perform many of the development tasks, it is easy to assume that they support and drive all development tasks. This tool-driven methodology encourages developers to miss essential steps in the development process because those steps are not explicitly handled by the tool.

We all would like an easy, no-thought-required design process. We would like checklists, detailed deliverables, and precise standards. We would like to give up our responsibility of having to think about what we are doing. In reality, though, this will never work, because every system is different, and developing systems is an intellectual exercise. Developers must ask the following questions:

These are the kinds of questions that must be asked at each phase. Unfortunately, it is far too easy to be blinded by the work plan, the delivery deadline, and the demands for immediate results.

Where Does CADM Fit?

After writing this book, we recognized that, after all, CADM is a traditional System Development Life Cycle (SDLC) approach. Our experience has been that developers and users are more satisfied with the finished product when the analysis and design are carefully done. Most of us have worked on systems where failures have been of biblical proportions. These failures usually happen because shortcuts are taken and the proper methodology is not followed or performed with enough care. Oracle Designer helps us to do better analysis and design by providing a unified repository to store most of the analysis and design information.

While CADM does not emphasize prototyping, this is not to say that prototypes cannot also be developed in order to show proof of concept. In this second edition, a RAD-CADM approach is described in Chapter 22. Prototyping can occur throughout any system's life cycle in order to better communicate the overall vision of the system to users. This gives users useful feedback about how the completed system eventually will look before a significant amount of money is spent building it. In the Pre-Design phase, we suggest that developers produce a prototype so that users can experience the look and feel of the system. By the time the system is ready to be built, the users have helped the system evolve through its life cycle.

At the risk of looking like traditionalists (i.e., non-forward-thinking radicals) who are bucking the trend toward the rapid prototyping environment, we strongly advocate a traditional SDLC, but one that is done better, faster, more efficiently, and with better organization. We believe that Analysis should be done carefully and correctly. When it is, valuable time and money can be saved by not having to redo what should have been done right the first time.

When we first started writing this book, we envisioned a much smaller work. Nevertheless, now that we've finished it, we have to acknowledge that even though it is larger than we originally thought it would be, it is merely an overview of the application development process. Time and time again, we found ourselves wanting to write more about a topic, but the practical limitations of the project prohibited this. Even in this revised and expanded second edition, we do not claim that this book is a complete treatment of how to use Oracle Designer to build systems, as that would take many volumes. However, we do feel that it is a complete overview of our vision of the best way to build systems using Oracle Designer.