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

This article shares with you about the terms commonly used in UML and pattern applications. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Domain modeling

If the agile modeling method is used, the purpose of creating the domain model is to quickly understand and communicate the general key concepts, but not the purpose.

If we think that a conceptual class X is not a number or text in the real world, then X may be a conceptual class rather than an attribute.

For example, should Store be an attribute of Sale or a separate conceptual class

In the real world, stores are not considered numbers or text. The term refers to legal entities, organizations and things that occupy space, so Store should be a conceptual class.

Most of the associations (relationships) will be implemented in the software as navigation and visibility paths. however, the domain model is not a data model, and associations are added to highlight our general understanding of important relationships, not record objects or data structures.

The verb phrases in the form of "class name-verb phrase-class name" form a readable and meaningful order.

Simple association names such as "own" or "use" are often clumsy because they do not enhance our understanding of the domain.

Generally speaking, most attribute types should be simple data types, such as numbers and Boolean. In general, the type of attribute should not be a complex domain concept.

Relationships between conceptual classes should be represented by associations rather than attributes.

Sequence diagram

The sequence diagram of UML and pattern application should be the main success scenario of each use case, as well as frequent or complex alternative common sequence diagrams.

Before designing in detail how the software application will work, * * investigate and define its behavior as a "black box". The system behavior describes what the system does without explaining how to do it.

System time should be described at the abstract level of intention rather than at the physical input and output device level. For example, enterItem is better than scan, because the former not only captures the intention of the operation, but also retains the abstraction, without involving what kind of interface to capture system events. The name of the system event begins with a verb, which increases clarity because it emphasizes that the event is a command or request.

GRASP

RDD is a general metaphor for thinking about OO software design. Think of a software object as a person with a certain responsibility who collaborates with others to get the job done. RDD makes us think of OO design as a community of responsible objects.

Controller

Under normal circumstances, the controller should delegate the work to be done to other objects. The controller only coordinates or controls these activities and does not do a lot of work itself.

High clustering

The high clustering pattern in UML and pattern application is an analogy to the real world. Obviously, if a person takes on too much irrelevant work, especially the work that should be delegated to others, then that person must not be very efficient.

"Don't talk to strangers."

This constraint limits which objects you should send messages to in the method, requiring that messages should only be sent to the following objects in the method:

This object

Parameters of the method

Properties of this

Elements in the collection as this attributes

Objects created in a method

The intention is to avoid coupling between customers and object connections between indirect objects and objects

The direct object is the acquaintance of the customer and the indirect object is the stranger. The customer should talk to the acquaintance and avoid talking to the stranger.

Architecture analysis

Points of change and evolution

Point of change: changes in current systems or requirements

Point of evolution: a speculative point of change that does not exist in existing requirements, but may occur in the future.

It is the art of architects to decide where to spend energy on the necessary design to prevent possible changes in the future.

Architectural analysis focuses on four aspects:

1) pay special attention to non-inertia requirements, including familiarity with the application's business or market environment. At the same time, functional requirements cannot be ignored; it provides the context to deal with these architectural factors, and further, identifying the variability of functional requirements is also critical to architectural analysis.

2) it involves system-level, large-scale and wide-ranging problems. Solving these problems usually involves large-scale or basic design decisions.

3) tradeoffs of interdependent associations, such as improving security, may affect implementation efficiency and availability, and most of these decisions affect costs.

4) Planning and evaluation of options. A skilled architect can either provide solutions for building new systems or evaluate alternatives in.

Architecture analysis refers to the identification and resolution of non-functional requirements in the context of functional requirements.

Abnormal

Name an exception that describes why the exception was thrown, not the thrower. Doing so makes it easier for programmers to understand the problem and highlights the nature of the similarities of many exceptions

Thank you for reading! This is the end of this article on "what are the commonly used terms in UML and pattern applications?". I hope the above content can be helpful to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.