Overview of Object-Oriented Methods

Dr. Chen xiaoqun

Since the end of 1980s, as object-oriented technology has become a research hotspot, dozens of object-oriented methods supporting software development have emerged. Among them, booch, Coad/Yourdon, OMT, and jacson methods have been widely recognized in the object-oriented software development field. It is particularly worth mentioning that the Unified Modeling Language UML
(Uniied Modeling Language). This method combines booch, OMT, And the Jacob
It unifies the Symbolic System and absorbs many concepts and technologies that have passed practical tests from other methods and engineering practices. The UML method has been developed to version 1.1 since it was proposed last year, and has been submitted to the Object Management Group OMG. The application has become the standard for object-oriented methods.

Object-Oriented Methods support three basic activities: Identifying objects and classes, describing the relationships between objects and classes, and defining the behavior of objects by describing the functions of each class.

To discover objects and classes, developers need to search for nouns and phrases in system requirements and system analysis documents, including perceptible things (automobiles, pressure, sensors ); roles (mothers, teachers, politicians); events (landing, interruptions, requests); InterAction (borrowing, meeting, crossover); personnel; places; Organization; equipment; and locations. Discovering important objects and their responsibilities through browsing and using system scripts is an important technology in the initial stage of object-oriented analysis and design.

After an important object is discovered, a group of correlated models are used to detail the relationship between classes and object behavior. These models represent the software architecture from four different aspects: static logic, dynamic logic, static physical and dynamic physical.

The static logic model describes the relations such as instantiation (class member relationship), Association, aggregation (overall/partial), and generalization (inheritance. This is called an object model. Generalized relationships indicate the inheritance relationships between attributes and methods. The graphical symbol system that defines the object model is usually exported from the object relationship diagram used for data modeling. Constraints that are very important to the design, such as the base (one-to-one, one-to-many, multiple-to-many), are also expressed in the object model.

The dynamic logical model describes the interaction between objects. Interaction is defined by a group of collaborative objects, ordered sequences of messages between objects, and visibility of objects. The object interaction diagram in the booch method is used to describe important interactions and display the time-ordered messages between participating objects and objects. A visible graph is used to describe the visibility of objects in interaction. Object visibility defines how an object is in the scope of the method for sending messages to it. For example, it can be a method parameter, a local variable, a new object, or a part of the object currently executing the method.

The static physical model describes the code layout through the module. The Dynamic Physical Model describes the process and thread architecture of the software.

In the following sections, we will briefly introduce and compare the above object-oriented methods.

**************************************** *******************************

The booch method includes the following steps:
. Recognize classes and objects at a given Abstraction Level
. Identifies the semantics of these objects and Classes
. Identify the relationships between these classes and objects
. Implementation class and Object

These four activities are not only a simple step sequence, but also an iterative and incremental development process that constantly refines the system's logic and physical views.

Class and object recognition includes identifying key abstractions in the problem space and an important mechanism for generating dynamic behavior. Developers can discover critical abstractions by studying the terminology of problem domains. Semantic recognition mainly establishes the class and object meaning recognized in the previous stage. The developer determines the interaction between the class behavior (that is, the method) and the class and object (that is, the standard description of the behavior ). In this phase, the state transition diagram is used to describe the object state model, and the behavior model is described by the temporal diagram (temporal constraint in the system) and the object graph (interaction between objects.

Describes static and dynamic link models in the Link identification phase. These relationships include usage, instantiation, inheritance, association, and aggregation. The visibility between classes and objects is also determined at this time.

In the implementation phase of classes and objects, we should consider how to implement them in the selected programming language and how to organize classes and objects into modules.

In the object-oriented design method, booch emphasizes the difference between the system logic view based on class and object and the system physical view based on module and process. He also distinguishes static and dynamic models of the system. However, his method tends to be a static description of the system and does not support dynamic description.

Booch's power lies in its rich symbolic system, including:
. Class Diagram (Class Structure-static view)
. Object graph (Object Structure-static view)
. Status transition diagram (Class Structure-dynamic view)
. Temporal chart (Object Structure-dynamic view)
. Module diagram (module Architecture)
Process Diagram (process Architecture)

The Symbolic System Used for class and Object Modeling uses annotations and different icons (such as different arrows) to express detailed information. Booch recommends that you use a subset of the symbolic system at the initial stage of the design, and then add more details. There is also a text form for each symbolic system, which consists of a description template of each major structure. The symbol system is defined by a large number of operators, but its syntax and semantics are not strictly defined.

**************************************** *******************************

Rumbaugh's OMT method describes the system from three perspectives and provides three models, object model, dynamic model, and function model. The object model describes the static structure of objects and their relationships. The main concepts include:
. Class
. Attribute
. Operation
. Inheritance
. Join (relational)
. Aggregation

The dynamic model describes the time-varying aspects of the system. Its main concepts include:
. Status
. Sub-State and super state
. Event
. Action
. Activity

The function model describes the conversion of internal data values of the system. Its main concepts include:
. Processing
. Data Storage
. Data Stream
. Control Flow
. Role (Source/TAN)

This method divides the development process into four stages:
1 Analysis
Build a real-world model based on issues and user requirements. The products of the analysis phase include:
. Problem Description
. Object Model = object graph + Data Dictionary
. Dynamic Model = status chart + global event flow chart
. Function Model = data flow diagram + Constraints

2 System Design
Combine the knowledge of the problem domain and the architecture of the target system (solution domain) to divide the target system into subsystems.

3. Object Design
Complete the System Design Based on the implementation details added to the analysis model and the architecture in the solution domain. Main products include:
. Refined Object Model
. Refined Dynamic Model
. Detailed Functional Model

4. Implementation
Converts a design to a specific programming language or hardware while maintaining traceability, flexibility, and scalability.

**************************************** *******************************

The Coad/Yourdon method strictly distinguishes Object-Oriented Analysis OOA from object-oriented design Ood. This method uses five levels and activities to define and record system behavior, input and output. Activities at these five levels include:
. Found classes and objects. Describes how to discover classes and objects. Identify classes and objects from the application field to form the foundation of the entire application, and then analyze the system's responsibilities accordingly.
. Identify the structure. This stage is divided into two steps. First, identify the General-special structure, which captures the hierarchy of the recognized classes; second, identify the entire-part structure, this structure is used to indicate how an object becomes part of another object and how multiple objects are assembled into larger objects.
. Define the topic. A topic consists of a group of classes and objects. It is used to divide the class and object model into larger units for ease of understanding.
. Define attributes. This includes instance connections between instances (objects) that define classes.
. Define the service. This includes defining message connections between objects.

In the object-oriented analysis stage, after five levels of activity, the result is a problem domain model divided into five levels, it consists of five layers: topic, class, object, structure, attribute, and service, represented by class and object graph. The sequence of five levels of activities is not important.

The object-oriented design model needs to be further divided into the following four parts:
. Problem domain (PDC ). The results of object-oriented analysis are directly included in this section.
. Human-Computer Interaction (HIC ). These activities include user classification, script describing human-computer interaction, command hierarchy design, detailed interaction design, user interface prototype generation, and HIC class definition.
. Task Management (TMC) activities include identifying tasks (processes) the services provided by the task, the priority of the task, whether the process is event-driven or clock-driven, and how the task communicates with other processes and the outside world.
. Data Management (DMC ). This Part depends on the storage technology, whether it is a file system, a relational database management system, or an object-oriented database management system.

**************************************** *******************************

The Jacob son method is different from the three methods mentioned above. It involves the entire software lifecycle, including four stages: requirement analysis, design, implementation, and testing. Requirement analysis and design are closely related. Activities in the demand analysis phase include defining potential roles (roles refer to the software and hardware environments that use the system and interact with the system), and identifying objects and relationships in the problem domain, use case is found based on Requirement Specification instructions and roles, and use case is described in detail. The design phase includes two main activities: discovering design objects from the demand analysis model and adjusting the design model for the implementation environment. The first activity involves discovering design objects from the use case description and describing the attributes, behaviors, and associations of objects. The Use Case action is also assigned to the object here.

In the activity of identifying domain objects and relationships in the requirement analysis stage, developers identify classes, attributes, and relationships. Links include inheritance, familiarity (association), composition (clustering), and Communication Association. Define the use case activity and identify the activity of the design object. The two activities jointly describe the behavior. The Jacobson method also divides objects into semantic objects (domain objects), interface objects (such as user interface objects), and control objects (processing control between interface objects and domain objects ).

A key concept in this method is use case. Use Case refers to the transaction sequence related to behaviors, which will be executed by the user in a dialog with the system. Therefore, each use case is a system approach. When a user gives an input, the user executes an instance of Use Case and triggers a transaction that belongs to the use case. Based on this system view, Jacob associates the use case model with the other five system models:
. Domain object model. The Use Case model is represented by fields.
. Analyze the model. Use Case model is constructed through analysis.
. Design the model. The Use Case model is designed to be specific.
. Implementation Model. The Use Case model is implemented based on the specific design.
. Test the model. Used to test the specific use case model.