Python design mode-UML-Class diagram (class Diagram)

Brief introduction

Class diagram is the core of object-oriented analysis and design, which is used to describe the relationship between class and class, interface and interface, class and interface in each module of the system, as well as the properties and operation of each class, which are generally implemented in the detailed design process.

The class diagram itself is the abstract of the real world, is to model the various concepts in the system, and to depict the relationship between them, so the object of class diagram is the relationship between elements and elements.

Class Diagram Modeling steps

-Abstract out-of-class entities

-Identify the main properties of a class

-Draw a relationship between classes

-Analyze, comb, and design the various classes

Elements of a class diagram

The class diagram contains the following model elements: classes, interfaces, relationships, collaborations, annotations, constraints, Packages .

• Class

In the graphical representation of UML, the representation of a class is a rectangle, which is composed of three squares, namely, class name, class attribute and class operation. Class names and abstract methods in abstract classes are represented in italics.

-Class Name: Capitalize first letter

-Class Properties: Format for Visibility property name: Type = default value , such as-name:string

There are four types of visibility:

+ Public

-Private

# protected

* Package

Property Name: single attribute name lowercase; multi-word attribute names The first letter of the remaining words

-Class Action: The format is a visibility action name (parameter): Returns a value type , such as +getname (): String

• Interface

In the graphical representation of UML, the representation of the interface is divided into two kinds: circular representation and constructive representation method.

The interface consists of two columns, the first column at the top is the interface name, and the second column is the interface method. Interface No attribute contains only operations, and there are no externally visible associations.

　　　　　　-Circular notation

　　　　　　-Stereotype notation

• Relationship

There are generalization, dependency, association, aggregation, and composition relationships between classes and classes in class diagrams; There is an inheritance relationship between interfaces and interfaces, and there is an implementation relationship between classes and interfaces. These relationships themselves are elements of a class diagram, represented by different lines.

　　　　　　-Generalization relationship

　　　　　　-Dependency Relationship

　　　　　　-related relationships

　　　　　　-Aggregation relationship

　　　　　　-Combined relationship

　　　　　　-Implementing relationships

The relationships in the class diagram are more complex and are detailed below.

• Collaboration

Collaboration refers to some classes, interfaces, relationships, and other elements provide interactive behavior, can assist other elements to perform activities, to implement functional auxiliary classes.

• Comments

Comment on some classes and interfaces.

• Constraints

Specifies one or more rules to satisfy for some classes and interfaces, using free-text identifiers enclosed in curly braces in UML.

• Package

Packages in UML correspond directly to packages in Java to represent hierarchies and organizational content.

Relationship of Class diagram

There are four types of relationships between classes and classes, interfaces and interfaces, and classes and interfaces in class Diagrams: Dependency, association, generalization, implementation, where there are aggregations and combinations of two special cases.

• Depend on

Dependency is a one-way use relationship, and if a class implements a function, uses other classes as arguments, or calls methods of other classes, there is a dependency between the two classes.

A dependency behaves in one class using another class as a local variable or a method parameter, and a call to another class static method.

There are also five types of dependency relationships: binding dependency, implementation (realization) dependency, usage dependency, abstract (abstraction) dependency, Authorization (Permission) dependency

Binding dependency

Bind <<bind>>: Specify values as template parameters to generate a new model element

Keywords <<bind>> apply to higher-level dependencies for binding templates to create new model elements, arrows pointing to bound templates

Implementing dependencies

Implement <<realize>>: is actually a contract between two classes/interfaces, which means that one class/interface only defines the behavior of the abstract, and the other class defines the specific structure and behavior.

Use dependent

Using a dependency indicates that the client uses the services provided by the provider to help implement its own functionality, usually in the following specific applications:

-Use <<USE>>: a broad concept that indicates that the behavior or implementation of one class can affect the behavior of another class or implement

-Call <<call>>: Invoke the operation of another class in a method of a class

-Parameter <<parameter>>: A class as a method parameter of another class

-Send <<send>>: Send a signal to another class with a method in one class

-Instantiate <<instantiate>>: Creates an instance of another class with a method of one class

　　　　　　　　

Authorization dependency

Authorization dependency represents the permission and ability for a package/class/element to access another package/class/element, including access, import, friend, and other dependencies:

-Access to <<ACCESS>>: Allow one package/class to access the contents of another Package/class

-Import <<import>>: Allow one package/class to access the contents of another Package/class

-Friend <<friend>>: Allows one element to access another element

Abstract dependency

Abstract dependencies represent the relationships between the client and the provider at different levels of abstraction, including dependencies such as tracking, refinement, and export:

-Tracking <<trace>>: Non-strongly related connections between different model elements

-Refinement of <<refine>>: Decomposition of more explicit and finer subclasses by the basic class

-Export <<derive>>: one instance can be exported from another instance

　　　　　　　　

• Association

An association is a strong dependency between two classes or between a class and an interface. Can be one-way or two-way.

Association relationship generally long-term, ownership relationship, and the relationship between the two sides is generally equal, such as between the school and students, teachers and students. The associated class B appears in the association Class A as an attribute of the class, and the association can be unidirectional or bidirectional.

　　

Association relationships are represented in four forms on the Code:

-One-way association: one-way ownership relationship, only one class knows the properties and methods of another class

-Bidirectional correlation: Two-way ownership relationship, both sides know each other's properties and methods

-Self-correlation: it is relatively rare but useful to associate yourself, such as a linked list

-Multiplicity Association: Represents the number of objects in two classes, the multiplicity of which can be represented by a numeric range on an association line

　　　　　　　　　　Multiplicity: Multiple Sex　　

1 is only 1

* FROM 0 to infinity

0..1 0 or 1

N.. Any number between m [N, M]

　　　　

In UML, a line arrow is used to indicate that the arrow points to the class being associated, from Class A to Class B

One-Way Association

Bidirectional correlation

Self-correlation

Multi-Sex Association

• Polymerization

An aggregation relationship is also a special case of an association relationship. The two classes of the common relational relationship are generally at the same level of equality, while the two classes of the aggregation relationship are at different levels, which is the relationship between the whole and the parts. The whole and part of the aggregation relationship can be separated, and the life cycle is independent of each other, such as between the company and the employee.

Using the Hollow Diamond + solid arrows in UML, the Hollow diamond edge points to the class school (whole), which implements the arrow edge pointing to the partial class student (part)

• Combination

The combinatorial relationship is also a special case of the relationship, belonging to the strong aggregation, which itself also represents the relationship between the whole and the part, but the whole and part of the combined relationship is inseparable, and the whole life cycle ends at the end of the part life cycle. Like people and brains.

Aggregation and combination are all special cases of association, which are the relationship between the whole and the part. The difference is whether the whole and the part can be separated, the aggregated two objects are separable, and have their own life cycle, while the combined two objects tend to represent a relationship of the same life.

Using solid Diamond + solid arrows in UML, solid diamond edges point to class person (whole), solid arrow edge pointing to class brain (partial)

• Generalization

Generalization refers to the process by which a subclass inherits a parent class, or a subinterface inherits the functionality of the parent interface and adds its own new functionality, and is one of the most coupling relationships between the two classes. A parent class is called a base class or a superclass, and a subclass is also known as a derived class. Subclasses can inherit from an abstract class or a generic class.

Use solid + hollow arrows in UML, arrows to parent class, or sub-interface to parent interface

• Realize

Implementing relationships refers to the process by which a class implements one or more interface functions, where the interface is more of a contract or specification. Implementations are one of the most coupling relationships between two classes or between classes and interfaces, where classes implement the actions declared in an interface or interface class.

UML uses dashed + hollow arrows to indicate that an arrow is directed to an interface by an implementation class

Advanced features of class diagrams

　　　　

• Abstract class

Abstract classes are classes that cannot be instantiated directly, and either abstract or abstract methods in UML are represented in italics. Abstract class names and abstract methods can also be identified in a document that is not strictly required, with the generic class plus <<abstract>> prefix.

Because it is a Python design pattern, the method name is used in a more pythonic way.

Standard notation

Construction Notation

　　　

• Template class

The purpose of introducing template classes in UML is to apply generic programming. Classes are defined based on placeholders or parameters at the time of the class template declaration, rather than on the actual type of property, method parameter, method return value. Make new classes/methods/properties available by replacing placeholders or parameters with actual values.

Because Python is a dynamic language, there are no scenarios for generics in Python, and the following Java example illustrates the application of template classes.

• Nested classes

A nested class is a class that is defined in a class, and a class that has nested classes is referred to as an external class. The coupling between the nested class and the outer class is higher and closer to the outer class, which is another representation of composition in UML.

• Active class

An active class is a special class whose objects have at least one process or thread that can control the classes in the activity. The active class is used because some classes are needed in development to control the running state of other classes.

• Association classes

An association class is both an association and a class, which not only connects two classes as an association, but also defines a set of attributes that belong to the association itself.

Class Diagram considerations

-Class diagram design early to focus on, concise and easy to understand, according to changes in demand to stay updated

-The names of the elements in the class diagram should be intuitive, clear, and meaningful, with no homogeneous attribute names being the only one in the full extent

-Avoid circular dependencies when there is a dependency between multiple elements in a class diagram

-Class properties in class diagrams minimize the complexity of the entire graph

-Use annotations appropriately in class diagrams to make the system clearer and easier to understand

-Reduce development and rework time by using sketches for intra-group communication for projects that require frequent changes

Python design mode-UML-Class diagram (class Diagram)