Briefly Explain Object Models
An object-oriented approach to the whole software development process is now commonly used, particularly for interactive systems development. This means expressing the systems requirements using an object model, designing using objects, and developing the system in an object-oriented programming language such as Java
or C++, Object models that you develop during requirements analysis may be used to represent both system data and its processing, In this respect, they combine some of the uses of data-flow and semantic data models. They are also useful for showing how entities in the system may be classified and composed of other entities.
For some classes of system, object models are natural ways of reflecting the real-world entities that are manipulated by the system. This is particularly true when the system processes information about tangible entities, such as cars, aircraft, or books, which have clearly identifiable attributes. More abstract, higher-level entities, such as the concept of a library, a medical record system, or a word processor, are harder to model as object classes. They do not necessarily have a simple interface consisting of independent attributes and operations.
Developing object models during requirements analysis usually simplifies the transition to object-oriented design and programming. However, I have found that end-users of a system often find object models unnatural and difficult to understand.
They may prefer to adopt a more functional, data-processing view. Therefore, it is sometimes helpful to supplement object models with data-flow models that show the end-to-end data processing in the system.
An object class is an abstraction over a set of objects that identifies common attributes (as in a semantic data model)”and the services or operations that are provided by each object… Objects are executable entities with the attributes and services of the object class. Objects are instantiations of the object class, and many objects may be created from a class. Generally, the models developed using analysis focus on object classes and their relationships.
In object-oriented requirements analysis, you should model real-world entities using object classes. You should not include details of the individual objects (instantiations of the class) in the system. You may create different types of object
models, showing how object classes are related to each other, how objects are aggregated to form other objects, how objects interact with other objects, and so on. These each present unique information about the system that is being specified. The analysis process for identifying objects and object classes is recognized as one of the most difficult areas of object-oriented development. Object identification is basically the same for analysis and design.
I concentrate here on some of the object models that might be generated during the analysis process. Various methods of object-oriented analysis were proposed in the 1990s (Coad and Yourdon, 1990: Rumbaugh, et al., 1991; Jacobsen, et al., 1993; Booch, 1994). These methods had a great deal in common, and three of the key developers (Booch. Rumbaugh, and Jacobsen) decided to integrate their approaches to produce a unified method (Rumbaugh et al., 1999b). The Unified Modeling Language (UML) used in this unified method has become a standard for object modeling. The UML includes notations for different types of system models.
An object class in UML is represented as a vertically oriented rectangle with three sections:
The name of the object class is in the top section.
The class attributes are in the middle section.
The operations associated with the object class are in the lower section of the rectangle.
I don’t have space to cover all of the UML, so I focus here on object models that show how objects can be classified and can inherit attributes and operations from other objects, aggregation models that show how objects are composed, and simple behavioral models, which show object interactions.