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

This article mainly shows you the "sample analysis of UML basic knowledge points in C#", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and learn the article "sample analysis of UML basic knowledge points in C#".

C#UML Foundation

Object-oriented programming methodology is the guiding ideology of C # programming. The step of C # programming is to use object modeling technology (ObjectModelingTechnique,OMT) to analyze the target problem, abstract the commonness of related objects, classify them, analyze the relationship between different classes, and then use classes to describe the same kind of objects and sum up the relationships between classes. Coad and Yourdon designed a set of object-oriented methods based on object modeling technology, object-oriented programming and knowledge base system, which are divided into object-oriented analysis (Object-OrientedAnalysis,OOA) and object-oriented design (Object-OrientedDesign,OOD). Object modeling technology, object-oriented analysis and object-oriented design together constitute the process of system design, as shown in figure 6-1. This is the basis for writing code.

System design flow

In the process of object modeling, object-oriented analysis and design, we need to use modeling language to describe the process and results of analysis. Unified Modeling language (UnifiedModelingLanguage,UML) is a standard and universal design language designed for this goal. Anyone who wants to really understand the idea of object-oriented programming needs to have some knowledge of UML.

In the foundation of C#UML, UML is not a methodology, but a description language. It provides many types of model description diagrams (diagram). When these diagrams are used in a given methodology, it is easier for people to understand and communicate design ideas. UML diagrams can be divided into the following three types.

Static diagram (staticdiagram): describes the logical structure of software elements that do not change, depicting classes, objects, data structures, and the relationships between them.

-dynamic diagram (dynamicdiagram): shows the changes of software entities during operation, and describes the execution process and the way in which the entities change their state.

Physical diagram (physicaldiagram): shows the constant physical structure of software entities, depicts library files, byte files, data files, etc., and the relationships that exist between them.

Use case diagram

The use case diagram in the C#UML foundation describes a functional unit provided by the system. The main purpose of the use case diagram is to help the development team understand the functional requirements of the system in a visual way, including the relationship between "roles" based on the basic process, as well as the relationship between use cases within the system. Use case diagrams are typically used to represent the organizational relationship of use cases, either for all use cases of the entire system, or to complete a set of use cases that are functional (for example, all security management related use cases).

Usecase refers to the function of the system, which is the collection of all the actions performed by a function of the system. Use cases are described from a user's point of view. The user tells the system to do something specific. A use case captures a visual sequence of events that are the system's response to a single user's stimulus.

The actor represents the role that the user of the system can play. These users may be people, other computers, some hardware, or even other software systems. The requirement for use cases is that they must be outside the system part of the use case description, and they must be able to stimulate the system part and receive returns.

The use case describes the system activity when one of the actors gives a specific stimulus to the system. These activities are described in text. It describes the nature of the stimulus that triggers the use case, input and output to other actors, and activities from input to output. The use case text usually also describes the possible errors in each activity and the remedial actions that the system should take.

In the use case diagram, the use case is represented by an ellipse and the name of the use case is placed in the center of the ellipse or in the middle below the ellipse. Humanoid symbols are used to represent roles (users). The relationship between the role and the use case is described by a simple line segment, indicating that the role can manipulate the use case.

In the use case diagram, a box is used to represent the boundaries of the system. All system use cases are placed in the box, and all actors are outside the box. The actor and the use case are connected in a straight line. Everything in the box is part of the system, and everything outside the box is external to the system. Use case diagrams can also represent the relationships between system use cases within the box, the most common being "usage relationships", represented by straight lines with arrows pointing to the use cases being used. Another kind of relationship is the extension relationship, which is used to represent inheritance.

Sequence diagram

The sequence diagram in the C#UML foundation shows the detailed flow of a specific use case (or part of a use case). It is almost self-describing and shows the interactions between different objects in the process, as well as various calls to different objects in great detail.

A sequence diagram has two dimensions: the vertical dimension displays the sequence of messages / calls in the chronological order in which they occur, and the horizontal dimension shows the interaction between object instances.

Interactions between objects include:

-call: one object calls the method of another object (or itself).

Return (return): returns a value as the result of the method call.

-send: an object sends a message asynchronously to another object (or itself).

-create (create): one object instantiates another.

-destroy: one object destroys another object (or itself).

The drawing of sequence diagrams is very simple. The box at the top of the figure represents an instance (object) of the class. In the box, the class instance name and class name are separated by spaces / colons / spaces (for example, gen:ReportGenerator). If a class instance sends a message to another class instance, draw a connection with an open arrow pointing to the receiving class instance, and place the name of the message / method on the connection. For some particularly important messages, you can draw a dashed line with an open arrow pointing to the instance of the originating class, marking the return value on the dotted line. Including the dotted line of the return value, which is helpful to the reading of the sequence diagram.

Reading sequence diagrams is also very easy. Start with the "driver" class instance of the startup sequence in the upper-left corner, and then read down each message.

The above is all the contents of the article "sample Analysis of UML basic knowledge points in C#". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, 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.