Role of the object model
The object model is at the focus of every modeling effort in the development process.
The object model is the source for code generation and the target of reverse engineering. To fulfill this role, it has to capture all the information obtained using the other models. Once we create our initial draft of the object model in this phase, we will begin a process of enhancement and refinement using the other diagrams as tools to discover and clarify new information about the problem domain and eventually about our planned solution.
The intent of object-oriented analysis (OOA) is to define all classes, the relationships and behaviors associated with them, that are relevant to the problem to be solved. To do this, a number of tasks must occur:
- basic user requirements must be communicated between the customer and the software engineer;
- classes (attributes and methods) must be identified;
- a class hierarchy is defined;
- object-to-object relationships should be represented;
- object behavior must be modeled;
- above tasks are applied iteratively until the model is complete.
Structured Analysis versus Object-Oriented Analysis
There exist many methodologies for doing analysis. A well-known methodology is structured analysis, the characteristic model being the data flow diagram to illustrate how data is passed between different processes in a system.
In other words, the system's data is stored in one place, and functions (operations) are essentially separated by the data. Structured analysis views the software system as a collection of data that can be processed by a number of functions external to the data.
This kind of methodology is often used for relational databases. Although there are similarities between the notation used in object-oriented and structured methodologies, the object-oriented analysis methods are based on a completely different understanding of the basic structure of software systems.
The object-oriented analysis believes that most operations in real-world use only a small fraction of the total data of the system, and most pieces of data will be accessed by a small number of operations.
The motivation of object-oriented approaches was a need to split the data repository and integrate pieces of data with the operations that directly manipulate those data. Let us illustrate a comparison between the structured and object-oriented approaches by a
real-life example. In a structured world, scanners and printers are placed in the same location and it is the programmer's responsibility to choose the operations he needs to do.
In an object-oriented world, scanners and printers are in separate rooms, as they provide different operations.
Compared with structured approaches, in the object-oriented approaches the operations are localized together with the data that they affect,
instead of being part of a large and global structure. In the structured approach, each operation has the responsibility of choosing the necessary data from the central repository (i.e., a global place where the data is stored).