Using object-oriented analysis and design over traditional structured analysis and design

International Journal of Business Research, March, 2008 by Kenneth Pefkaros

* Object-oriented analysis. This is concerned with developing an object-oriented model of the problem (application) domain. These identified objects represent entities, and possess relationships and methods that are necessary for the problem to be resolved.

* Object-oriented design. This is concerned with developing an object-oriented model of the system necessary to implement the specified requirements. The analysts and programmers must think in terms of things (objects) rather than processes or functions.

The object model is based on principles including abstraction, encapsulation, modularity, hierarchy, concurrency, and persistence, and follows a repetitive and step by step approach to systems development (Rob, 2004). The major focus of the object model is object decomposition as opposed to functional decomposition, where a complex system is decomposed into several objects. An object-oriented system will consist of these various objects each of which will collaborate and cooperate with other objects to achieve specified tasks. Consequently, object decomposition allows the analyst to break down the problem into separate and more manageable parts. This is described in more detail as follows:

* As opposed to the structured systems development process, object-oriented development follows an iterative and incremental lifecycle. The four phases of the object-oriented lifecycle are inception, elaboration, construction, and transition. Consequently, an information system evolves by going through several iterations, each of which consists of all three primary tasks analysis, design, and construction. Requirements are defined by use cases which are object-oriented tools that describe scenarios of the interactions between the system and its users.

* These scenarios also help to identify objects, which model the data (attributes) and the corresponding processes (methods). Objects that represent the same entities are grouped together to form classes. Classes may be related to each other by different kinds of associations which may include inheritance and aggregation. We document these classes and their various relationships from the problem domain by class diagrams. These diagrams as well as the representations of the relationships among the classes are part of the Unified Modeling Language (UML) which has become the standard for the OOAD methodology (Podeswa, 2005).

* In the design phase these classes are expanded into design classes. In this phase the detailed requirements for each class are defined which includes its attributes and methods. The processes for the system are distributed among the objects as methods or services. Consequently, the objects must collaborate with one another in order to perform the various scenarios described by the use cases. We document these collaborations among the objects through the use of interaction diagrams, described by either sequence diagrams or collaboration diagrams. Then we build the information system by using combinations of classes that have been developed previously (reuse) and are available in a class library in addition to developing new ones using the specifications defined during the design phase. Finally we evaluate the resulting system by testing (Booch, 2005).