MY BOOK REVIEW

OBJECT ORIENTED ANALYSIS and DESIGN

Book

Edward Yourdon and Carl Argila

Author

QA 76.64 Y68 1996

Reference no.

CHAPTER 2

The path up and down is one and the same

                                                                                                                          - Heraclitus

The “analysis” of a system takes place within an application domain context-this context is not a bias in the usual sense, but rather a constraint to which all analyses must conform

.

System requirements may be determined by subjected factors, such as the scope and scale of the system as seen by the user. In other word, system requirements are always established within the context of a user environment.

In this chapter there is a version of a functional specification for the two case studies application these will be discussed throughout the reminder of the book if either of the cases studies were “real-word” projects. The written specification might be much longer   and the requirement might be much more detailed. On the other hand they might not be written at all especially in the case of the second application small bytes and the systems analysis would have to determined the true user requirements through a combination of question discussion and prototypes.

The text each case study specification will be used as the basis for a series of analysis and design models in subsequent chapter. However, we will also discuss some of the implication and relevant issues of each case study in the chapter.

Process-oriented analysis describes systems as a network of interacting processes. It includes descriptions of data used by processes, which are recorded in a data dictionary. This approach often steers the analyst away from studying system components and their interrelationships towards studying how the system might be designed and implemented. It is also difficult for process-oriented analysis to map concepts between a network of processes and objects existing in a real-world system.

As opposed to process-oriented analysis, object-oriented analysis modularizes an analysis document along the same object boundaries that exist in a real-world system. In addition, this approach also organizes all knowledge about each system object in a single logical location in the analysis document. Thus, information about a system object is easier to locate in object-oriented analysis than in other analysis methods. The object-oriented approach also encourages analysts to concentrate on "what" rather than "how", which reduces the temptation to skip prematurely to design. To make it easier to understand

information about objects, object-oriented techniques provide forms of abstraction including aggregation, generalization and classification.

Paradigm contamination occurs where methods from different system development (SD) paradigms are integrated or combined. We investigate the OO and structural SD approaches and concern ourselves with the question of how paradigm contaminations are avoided when both approaches are taught at tertiary level. By comparing the techniques associated with specific SD approaches, an outline of the particular differences and commonalities that regularly cause paradigm contamination is given. Guidelines to avoid contamination traps are also provided. This is significant to instructors enabling them to make students aware of the possible contamination pitfalls as well as how to avoid them, and as a result enable them to reap the intended benefits of the chosen SD method. As more challenging applications are automated, cooperative problem solving will be an important paradigm for the next generation of industrial intelligent systems. One of the key problems to use it in engineering domain is development of a structured design method. In this paper, an evolutionary, seamless, non-domain-specific object-oriented analysis (OOA) method is derived that starts at the definition of a software system and integrated knowledge engineering needs in a new manner, especially when following a deep knowledge approach. Based on this method, an expert-supported OOA tool environment (ESA) is presented that supports an analyst starting at the collection of the requirements through the analysis of any software system. And an example of simulative transformer substation system (STSS) is introduced to present some key problems and techniques of OOA up to a preliminary high-level design.