[Software Engineering General Review] Chapter 9 Object-Oriented Methodology (20%~25%)

1. Object-oriented definition

Object-oriented is to decompose things into individual objects, and then divide and cooperate between objects. Object-oriented is to divide problems by object functions, not steps. In the idea of ​​object-oriented program development, each object is a functional center with a clear division of labor.

2. Definition of object-oriented methodology

Object-oriented methodology is a method that takes data or information as the main line and combines data and processing, that is, treats objects as a unity composed of data and operations that can be applied to these data.

The object-oriented approach can be summarized by the following equation:

OO = object（对象）+classes（类）+inheritance（继承）+communication with messages

3. Key points of object-oriented methodology

object

1. An object-oriented software system is composed of objects, any element in the software is an object, and complex software objects are composed of relatively simple objects.
2. The traditional method of functional decomposition is replaced by object decomposition. The object is abstracted from the entity of the objective world and is not fixed.

kind

1. Divide all objects into various object classes, and each object class defines a set of data and a set of methods.
2. Data is used to represent the static properties of the object, which is the state information of the object.
3. The method defined in the class is the operation that is allowed to be applied to the object of the class, and is shared by all objects of the class, and does not need to copy the code of the operation for each object.

Inheritance

According to the relationship between the subclass and the parent class, several object classes are formed into a hierarchical system. Subclasses automatically have the same data and methods as the upper-level parent class, and the lower-level features will shield the higher-level features with the same name.

1. In C++, subclasses can inherit parent classes, and there are three ways of inheritance: public, private, and protect.
2. Subclass members will shield members of the parent class with the same name. In this case, we call it hiding or redefinition.

encapsulation

1. Objects can communicate with each other only by passing messages.
2. The object is the subject of processing, and it must send a message to request it to perform some operation and process its private data, but cannot directly operate on its private data from the outside world.
3. All private information local to the object is encapsulated in the definition of the object class, just like being contained in an opaque black box, which is invisible to the outside world and cannot be used directly.

① Think that the objective world is composed of various objects, everything is an object, and complex objects can be composed of simpler objects in a certain way. The object-oriented approach replaces the functional decomposition of the traditional approach with object decomposition.
② Divide all objects into various object classes, and each class defines a set of data and a set of methods.
③According to the relationship between the subclass (or called the source class) and the parent class (or called the base class), several object classes are formed into a hierarchical system (also called class hierarchy).
④ Objects can only communicate with each other by passing messages.

4. Advantages of object-oriented methodology

1. Consistent with human habitual way of thinking

1.1 The object-oriented software technology takes the object as the core, and the software system developed with this technology is composed of objects.
1.2. An object is a unity formed by encapsulating the data that describes the internal state and represents the static properties, and the operations that can be applied to these data (the dynamic behavior of the object).
1.3. The basic principle of the object-oriented design method is to use the concepts of the real world to think about problems abstractly so as to solve problems naturally.
1.4 The basic principle of object-oriented methodology is to establish a model of the problem domain according to the thinking method of human habits, and develop a software system that expresses the solution method as intuitively and naturally as possible.
1.5 Objects used in object-oriented software systems are abstractions of entities in the objective world.

2. good stability

2.1 The structure of the object-oriented software system is established based on the model of the problem domain, rather than based on the functional decomposition of the system. Therefore, when the functional requirements of the system change, it will not cause the overall change of the software structure, often Only some local modifications are required.
2.2 Since the entities in the real world are relatively stable, the software system constructed centered on objects is also relatively stable.

3. good reusability

3.1 The inherent encapsulation and information hiding mechanism of the object makes the internal implementation of the object isolated from the outside world, and has strong independence.
3.2 Objects are ideal modules and reusable software components.
3.3 Object-oriented software technology has great flexibility when using reusable software components to construct new software systems.
3.4 There are two ways to reuse an object class: one is to create an instance of the class and use it directly; the other is to derive a new class from it that meets current needs.

4. Easier to develop large software products

When developing software with object-oriented methodology, each object that builds the software system is like a micro-program, with its own data, operations, functions, and uses. Therefore, a large-scale software product can be decomposed into a series of small, essentially independent It not only reduces the technical difficulty of development, but also makes the management of development work easier.

5. Good maintainability

Object-oriented software is more stable. Object-oriented software is easier to understand. Easy to test and debug.

5. Object-Oriented Analysis

In object-oriented analysis, it is mainly composed of object model, dynamic model and function model. The object model is the most basic, most important, and core.

object-oriented analysis process	Object Oriented Design Process	is the current stage
Construct an application domain model that is completely independent of implementation	Gradually add the structure of the solution domain to the model	Compile the structure of the application domain and solution domain into program code and conduct strict test verification

5.1 Object Model

Describe several relationships between system data structure classes: generalization, implementation, association (also divided into general association, aggregation, combination, and dependency)

5.1.1 Class diagram method

5.1.1.1 Concept of class diagram

1. Shows classes, interfaces, and the static structure and relationships between them
2. Used to describe the structural design of the system

5.1.1.2 Elements of class diagrams

1. Class diagrams can also contain annotations and constraints.
2. Class diagrams can also contain packages and subsystems, which are used to group elements.
3. Sometimes instances of a class can be placed in a class diagram.

5.1.1.3 Classes

A class is an abstraction of a group of objects with the same attributes, operations, relationships, and semantics. It is the core of the organizational structure of an object-oriented system, including a name part, an attribute part, and an operation part.

name	student
Attributes	+ name: string
operate	+learn()

Syntax for class attributes

[visibility] attribute name[:type] [=initial value] [{attribute string}]
visibility: public (Public) "+", private (Private) "-", protected (Protected) "#"

The syntax for class operations is

[visibility] operation name [(:parameter list)] [:return type] [{property string}]
visibility

Public (Public) "+", private (Private) "-", protected (Protected) "#", package public (Package) "~"

Parameters Table

Definition

name: type

If there are multiple parameters, separate each parameter with a comma;
the parameter can have a default value;

attribute string

Add some information in addition to the predefined elements in the definition of the operation.

5.1.1.4 Interface

A class can implement one or more interfaces

The difference from the class diagram is mainly that there is a <> display at the top:

《interface》Person
+ eat()

It can also be represented by a hollow circle:

5.1.1.5 Collaboration

Collaboration means that some classes, interfaces, and other elements work together to provide some cooperative behavior, which is not simply obtained by adding elements.

5.1.1.6 Relationships

5.1.2 Class Relationships

5.1.2.1 Generalization relation

Semantics

The relationship between classes and subclasses, the relationship between interfaces and subinterfaces;
a class (called subclass, subinterface) inherits the functions of another class (called parent class, parent interface), and can add its own new functions;

grammar

extends

symbol

An implementation with a hollow triangle arrow, pointing from the subclass to the parent class, or from the subinterface to the parent interface;

5.1.2.2 Implementing relationships

Semantics

The relationship between classes and interfaces;
a class can implement multiple interfaces and realize the functions of all interfaces;
it embodies the principle of separation of specification and implementation;

grammar

implements

symbol

An implementation is represented by a dashed line with a hollow triangular arrow pointing from the class to the implemented interface;

5.1.2.3 Dependencies

Semantics

One class A uses another class B, but this relationship is accidental, temporary, and very weak, but changes in class B will affect class A;

grammar

Class B exists as a parameter (or local variable) of a method of class A;

symbol

An implementation is represented by a dashed line with a hollow triangular arrow pointing from the class to the implemented interface;

5.1.2.4 Relationship

Semantics

Stronger than dependency, inevitable, long-term, and strong;
divided into one-way association (only adding students to the class), two-way association (adding class attributes to students)
divided into one-to-one (students and student ID cards) , one-to-many (classes and students), many-to-many associations (students and courses)
have two classes of associations (customers and orders, orders and commodities), and one class and itself (leaders are also employees)

grammar

Class B is formed in class A as a member variable;

symbol

It is represented by a dotted line with an arrow pointing from class A to class B;
the two-way association can cancel the two arrows;

5.1.2.5 Aggregation relationship

Semantics

A special case of association relationship;
the relationship between the whole and part;
the whole part can be separated, and the life cycle of the whole is different from that of the part; the
relationship between has-a, the relationship between computer and CPU, the relationship between company and employee, the relationship between class and students relation;

grammar

same relationship;

symbol

Hollow rhombus plus solid arrow;

5.1.2.6 Composition relationship

Semantics

A special case of association relationship;
the whole and part relationship, the whole part is inseparable, stronger than aggregation;
the relationship of contains-a;
the life cycle of the whole is the same as the life cycle of the part;
the relationship between people and limbs;

grammar

same relationship;

symbol

Solid rhombus plus solid arrow;

The object model of complex problems (large-scale systems) usually consists of five subordinate layers: subject layer, class and object layer, structure layer, attribute layer, and service layer.

5.2 Dynamic Model

Describe the system control structure

5.2.1 Concept of dynamic model

The dynamic model represents the instantaneous and behavioral system control properties, which stipulates the legal change sequence of the objects in the object model.

5.2.2 Dynamic model modeling

Use the state diagram provided by UML to describe the state of the object, the events that trigger the state transition, and the behavior of the object. The dynamic behavior of each class is described by a state diagram, and the state diagrams of each class are combined by sharing events to form a dynamic model of the system, that is, a dynamic model is a collection of a group of state diagrams that are related to each other based on event sharing.

5.2.2.1 Sequence Diagram/Timing Diagram

four elements

Object Object
Lifeline Lifeline
Message Message
Activation Activation

5.2.2.2 Collaboration Diagram

1. Describe the organizational collaboration relationship between objects, which can also reflect the behavior of system use cases
2. A collaboration diagram consists of basic elements such as actors, objects, connections and messages

5.2.2.3 State diagram

1. The state diagram is mainly used to describe the dynamic behavior of an object during its existence, to represent the state sequence experienced by an object, the events that cause the state transition, and the accompanying actions due to the state transition
2. In general, a state machine can be used to model the life cycle of an object
3. The state diagram is used to display the state machine, focusing on describing the control flow between states

5.2.2.3.1 Comparison of state diagrams and activity diagrams

The focus of the description is different

1. A state diagram describes the state of an object and the transitions between states
2. Activity diagrams describe the flow of control from activity to activity

Different occasions

1. If it is to show the behavior of an object during its life cycle, it is better to use a state diagram
2. If the purpose is to analyze use cases, understand the workflow involving multiple use cases, or use multi-threaded applications, etc., it is better to use activity diagrams

5.3 Functional model

Describe system functionality

5.3.1 Concept of functional model

5.3.1.1 Definition of functional model

The functional model represents the functional properties of the changing system, which specifies what the system should do, and thus more directly reflects the user's needs for the target system.

5.3.1.2 Composition of the functional model

A functional model consists of a set of data flow diagrams

5.3.2 Use case diagram (emphasis)

The use case diagram provided by UML is also a powerful tool for requirement analysis and functional model building. In UML, the system model built with use case diagram is called use case model.

5.3.2.1 Definition of use case diagram

The use-case model describes the functionality of the system as understood by external actors. The establishment of the use case model is the result of repeated discussions between the system developer and the user, and it describes the consensus reached by the developer and the user on the requirement specification.

5.3.2.2 Representation of use case diagrams

5.3.2.2.1 System

definition

The system is seen as a black box that provides use cases, how it works internally, and how the use cases are implemented are not important for building a use case diagram model

express

The system is represented by a box, and its border represents the boundary of the system, which is used to delineate the functional scope of the system and define the functions of the system. Use cases describing the functionality of the system are placed inside the box, actors representing external entities are placed outside the box

5.3.2.2.2 Use Cases

definition

A use case is perceived by actors (participants) and is a complete function of a system. Define a use case in UML as a series of actions completed by the system

express

In UML, an ellipse represents a use case. Use cases are connected to actors (participants) through associations, which indicate which actors (participants) a use case interacts with, and this interaction is bidirectional

feature

1. A use case represents some user-visible functionality that achieves a specific user goal
2. A use case is always initiated by an actor (actor) and provides an identifiable value to the actor (actor)
3. Use case must be complete

Notice

A use case is a class that represents a class of functionality rather than a specific instance that uses that functionality. An example of a use case is an actual use method of the system, and the use case is usually called a script. A script is a specific execution process of the system

5.3.2.2.3 Actors (participants)

definition

Actors (participants) are people or other systems that interact with the system, representing external entities. Anyone or anything that uses a use case and interacts with the system is an actor (participant). An actor (participant) represents a role rather than a specific person or thing.

express

In UML, a lineman represents an actor. In the use case diagram, the actor (participant) and the use case are connected by a straight line, which means that information is exchanged between the two, which is called a communication link. Actors trigger use cases and exchange information with use cases. A single actor can be associated with multiple use cases, and a use case can be associated with multiple actors.

5.3.2.2.4 Use case relationships

extended relationship

Adding some actions to one use case constitutes another use case. The relationship between these two use cases is the extension relationship. The latter inherits some behaviors of the former, and the latter is usually called an extended use case.

use relationship (contains relationship)

When a use case uses another use case, a use relationship (containment relationship) is formed between the two use cases

5.3.2.2.4.1 Similarities and differences in use case relationships

1. Both extract those common behaviors from several use cases and put them into a single use case, which is used (included) or extended by other use cases
2. The purposes of using (containing) and extending are different. Extended relations are used when describing changes in general behavior.
3. When there are duplicate descriptions in two or more use cases and you want to avoid this duplication, use the use relationship (containment relationship)

5.3.2.2.5 Examples

Example 1 Student management system registration

Example 2 Network teaching system (similar to the use of Learning Pass)

Example 3 Borrowing books

The borrowers of the system are students and teachers, and the system provides the borrowers with the services of querying books, borrowing books, and returning books. Students can borrow up to 5 books, and teachers can borrow up to 20 books. When borrowing and returning books, you must first "verify the identity of the borrower". When returning books, if overdue, to pay a fine. If the book that the teacher wants to borrow has been borrowed, the teacher can also reserve the book through the book reservation service. After the reservation, the book can be borrowed first

Example 4 Train ticket ordering system

In the train ticket reservation system, customers can perform four operations: purchase tickets, unsubscribe tickets, check remaining tickets, and check train timetables. No matter buying a ticket or unsubscribing a ticket, the user must first log in to the system. The query of train time mainly includes two ways: query by station and query by train number. If you forget your password during the process of logging into the system, you can also use the function of retrieving your password.

Example 5 Purchase goods

The system has a registration function. Customers can only purchase products in the system by logging in after registration;
customers can browse products through the system, view detailed information of products, and purchase products they like;
customers should pay in a variety of ways, either through the bank's online The payment function can also be paid by remittance;
the system has a product promotion function, and for some products specified by the system or when the amount of the product purchased by the user exceeds a certain amount, the customer will be given a discount when checking out; after the customer logs in, the user
can Use the message function to comment on products or services;
system administrators can use the message function to answer questions raised by customers and manage registered users;
entry staff can update product information, including adding new products and updating existing products Information update;
the system allows multiple people to be online at the same time to browse and purchase products.

Example 6 Online course selection

In the "online course selection module" of the student information management system, students can perform three operations: "view course information", "select course" and "delete selected course". "View course information" mainly includes two ways: "view by course number" and "view by course name".
Administrators can perform the "maintain course information" operation.
All operations of students and administrators need to "log in to the system" before they can be completed. If you forget your password during the "login system" process, you can also use the "retrieve password" function.

Example 7 Chess and Card Hall Management System

In the chess and card hall management system, customers need to check the seat information through the operation of booking seats through the network. Select Process Waiting Queue if there are no free or satisfied seats.
When the customer arrives at the chess and card hall, the waiter at the front desk arranges the seat, and the seat information needs to be checked.
When the customer wants to leave the chess and card hall, the front desk clerk needs to handle the checkout, which supports cash checkout and bank card checkout through the UnionPay POS system.

6. Comparison of three models

1. A dynamic model established for each class that describes the life cycle or runtime of a class instance
2. State transitions drive behaviors that are mapped into processes in data flow diagrams and use cases in use case diagrams, which also correspond to services in class diagrams
3. The processing in the functional model should correspond to the services provided by the classes in the object model
4. The data stores in the dataflow diagram, and the source/destination points of the data, are usually objects in the object model
5. The data flow in the data flow diagram is often the attribute value of the object in the object model, or it may be the entire object
6. Actors in a use case diagram, possibly objects in an object model
7. Processing in the functional model may generate events in the dynamic model
8. The object model describes the data flow, data storage, and data source/destination structure in the data flow diagram

Object-oriented method to develop software, usually need to establish three kinds of models:
object model ---- describe the system data structure.
Dynamic model ---- describes the system control structure.
Functional model----Description of system functions.
These three models all involve concepts such as data, control, and operation, but the emphasis of each model is different.
A typical software system combines these three aspects as it uses data structures (object model), performs operations (dynamic model), and accomplishes changes in data values ​​(functional model).