Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of UML object-oriented technology, the content is detailed and easy to understand, the operation is simple and fast, and it has a certain reference value. I believe you will gain something after reading this UML object-oriented technology knowledge point. Let's take a look at it.

I. relationships in UML object-oriented technology

In the process of establishing an abstraction, you will find that classes rarely exist independently, and most classes cooperate with each other in some way. Therefore, when modeling the system, we not only need to abstract classes and objects from the vocabulary of the problem domain, but also need to describe the relationship between these abstractions.

1. Dependency (DependencyRelationship)

Dependencies describe the usage relationships between classes.

If a change in one model element affects another model element (the effect is irreversible), then there is a dependency between the two model elements. For example, there are two elements X and Y, and if changing the definition of element X may cause a change in the definition of element Y, element Y is said to be dependent on element X.

The UML symbolic representation of dependencies is a dashed line with arrows pointing to the dependent model element.

two。 Generic relationship (GeneralizatinRelationship)

The generic relationship describes the relationship between "general" and "special" between classes.

When solving complexity problems, it is usually necessary to abstract elements with common characteristics into categories and further classify them by increasing their connotation. For example, students can be divided into college students, middle school students and primary school students, and trains can be divided into passenger trains and freight trains. In the object-oriented method, the former is called a general element, a base class element, or a parent element, and the latter is a special element or child element. Child elements inherit the structure and behavior of the parent element, usually adding a new structure and behavior, or modifying the behavior of the parent element.

In UML, generic relationships are represented by solid lines with hollow arrows pointing to the parent element.

3. Association relationship (AssociationRelationship)

The association relationship in UML object-oriented technology describes the structural relationship between objects.

The association relationship indicates that there is some semantic connection between the two classes. It is a structural relationship that stipulates that the object of one thing can be connected with the object of another. For example, if an employee works for a company and a company has many departments, it can be considered that there is some semantic relationship between the employee and the company, the company and the department. In the class diagram model, the relationship between class Employee and class Company, class Company and class Department can be established.

The UML symbol representation of the association relationship is a solid line.

4. Implementation relationship (RealizeRelationship)

The implementation relationship is the semantic relationship between classifiers, one classifier specifies the contract, and the other classifier guarantees to realize the contract. In most cases, the implementation relationship north is used to specify the relationship between the interface and the class or component that implements the interface. An interface is a collection of operations that specify the services of a class or component, that is, the contract that a class or component must implement. An interface can be implemented by multiple classes or components, and a class or component can also implement multiple interfaces. The use of interfaces separates the interface of the operation from the implementation of the operation. When a class or component implements an interface, it means that the class or component implements all the operations of the interface, fully complies with the protocols between customers established by the interface, and responds to messages sent by customers using the operations in the interface.

The UML symbolic representation of the implementation relationship is represented by a dashed line with a hollow arrow.

Symbols in UML object-oriented technology

1. Comments (Note)

two。 Participant (Actor)

Participants represent people, hardware devices, or another system that interacts with the system. Although participants can be used in the model, participants are not part of the software system and exist outside the system. A participant can:

Enter information into the system only.

Only receive information from the system.

Can not only input information to the system, but also receive the output information of the system.

3. Use case (UseCase)

The use case defines the behavior of the system or part of the system, which describes the sequence of actions performed by the system and produces an observable result for the executor. That is, the use case is:

A template for system behavior.

The sequence of actions performed by the participant and the system.

Delivery value, etc., to participants.

4. Collaboration (Collabration)

Collaboration names groups of classes, interfaces, and other elements that work together to accomplish a behavior. Collaboration can be used to define the implementation of use cases and operations and to model important mechanisms in microsystem architecture.

There are two aspects of collaboration:

Structure part: the structure section specifies the classes, interfaces, and other elements that cooperate to execute the named collaboration.

Behavior section: the behavior section defines the dynamic aspects of how these elements interact.

5. Class (Class)

In UML object-oriented technology, class is the most basic element in object-oriented system. Class is one of the most important classifiers (Classifier). Classifier is a mechanism to describe structure and behavior characteristics, including classes, interfaces, signals, components, nodes, use cases and subsystems.

A class is a collection of objects that share the same properties, operations, relationships, and semantics. A class is an abstraction of things in the real world. When these things exist in the real world, they are instances of the class and become objects. Class can implement one or more interfaces.

Class describes the Attibute and Behavior of a class of objects. When identifying the class, we should cooperate with the domain experts, analyze the problem domain carefully and deeply, abstract the concept in the problem domain, define its meaning and interrelation, thus abstract the class in the system, and name the class with the terms in the domain.

The UML symbol of a class is a rectangle divided into three squares. The top grid puts the class name, the middle grid puts the properties, the type and value of the property (the initial value of the property), and the grid method, the parameter table of the method, and the return type below.

When the UML representation of a class is given in different views, you can choose to hide all or part of the character or method lattice as needed.

6. Object (Object)

The object represents a specific instance of the class. The object has an identity (Identity) and attribute value (AttributeValues).

Instances and objects are basically synonyms, and they are often used interchangeably. An instance is an abstract concrete representation, a method can act on an instance, and an instance can have a state to store the results of the method.

7. Message (Message)

A message is the communication between objects, it conveys the message that the action is to be performed, and it can trigger the event. Receiving a message is usually thought of as an event. Typically, when one object calls a method in another object, a message delivery is completed.

The UML symbol of the message is a solid line with arrows.

8. Interface (Interface)

In UML object-oriented technology, an interface is a collection of operations used to specify a class or component service. Unlike classes, interfaces do not specify any structure or implementation.

9. Package (Package)

Packages are a general mechanism for grouping model units. You can think of a system as a single, advanced package.

10. Component (Component)

A component represents a software module with a well-defined interface. A component is a physical and replaceable part of the system that follows the interface definition and provides an implementation for the interface. Components are the physical encapsulation of other logical units, which can be classes, interfaces, collaboration, and so on.

The components have the following characteristics:

(1) the component is physical, it exists, not a concept.

(2) components are replaceable.

(3) components are part of the system.

The difference between components and classes in UML object-oriented technology:

(1) classes represent logical abstractions; components are physical and can exist in the real world. That is, a component can exist on a node, but a class cannot.

(2) the component represents the physical encapsulation of other logical units, which is different from the abstraction of the class.

(3) the class itself has properties and operations. Typically, the operation of a component can only be accessed through an interface.

This is the end of the article on "what are the knowledge points of UML object-oriented technology?" Thank you for reading! I believe that everyone has a certain understanding of "what are the knowledge points of UML object-oriented technology". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.