Introduction: domain models are the most important and classic models in OO analysis. It describes important concepts in the field. This article will introduce the basic technologies related to Domain Models. Domain Model: it is a visual representation of conceptual classes in the domain or objects in the real world [mo95, fowler96]. Domain models are also called conceptual models, domain object models, and analysis object models. Up defines the domain model as one of the products that can be created in the business modeling subject. To be more accurate, the up domain model is a special feature of the up business on the object model (BOM). It is "dedicated to interpreting important 'thes' and products in the business field" [RUP]. Bom covers the entire business and all its subdomains. Using UML notation, the domain model is described as a group of class diagrams with no operation defined. It provides a conceptual perspective. It can display: 1) associations between domain Classes 2) associations between conceptual Classes 3) attribute Domain Models of conceptual classes are visualized dictionaries, it indicates important abstraction of a domain, vocabulary of a domain, and content information of a domain. Is the domain model a software business object diagram? The up domain model is a visualization of things in the real world field of interest, rather than software objects such as Java or C #, or software objects with responsibilities. Therefore, the following elements do not apply to Domain Models: 1) software products 2) concepts of duties or methods: concepts are thoughts, things, or objects. Concepts can be considered in terms of their symbols, connotations, and extensions. Symbol: indicates the word or graphic connotation of a concept class: Definition extension of a concept class: Is it the same thing for a group of sample domain models and data models applicable to the concept class? The domain model is not a data model. Therefore, in the domain model, it does not exclude classes that do not explicitly require recording of relevant information, nor exclude conceptual classes without attributes. For example, a conceptual class without attributes is valid, or a conceptual class that acts as a pure behavioral role rather than an information role in a domain is also valid. How to Create a domain model 1) find a concept Class 2) Draw it as a class in a UML class diagram 3) add associations and attributes. How to find concept class 1) Reuse and modify existing models: This is the first, best, and simplest method.
2) use the category list
3) Identify nouns and phrases to find concepts
Domain Model is the visualization of important domain concepts and vocabulary. Some of these terms come from use cases. Additional terms originate from other documents or experts' ideas.
Below are several principles
Criterion: Agile modeling-sketch a class chart
Criterion: Agile modeling-whether to use modeling tools to maintain Models
If agile modeling is used, the purpose of creating a domain model is to quickly understand and communicate general key concepts. Perfection is not an end. agile models are often discarded soon after they are created. From this perspective, there is no reason to maintain or update these models, but it does not mean that updating models is wrong.
Criterion: Report object-whether the model should contain "tickets"
Bill is an important term in the POs field. However, it may only be a report of sales and payment data, so it is a duplication of information. The following are some considerations:
1) In general, reports that show other information in the domain model do not make sense, because all their information is derived from or copied to the source of information. This is the reason to exclude it.
2) on the other hand, in terms of business rules, it has a special role: Usually the person holding the ticket has the right to return the goods, which is the reason for expressing it in the model.
Rule: Think like a map painter: Use domain terms
Criterion: how to model a non-real world
Some software systems have almost no similarities with the natural or business fields, such as telecommunications software. However, it is possible to create Domain Models for these domains. In this case, a high degree of abstraction is required to review common non-oo designs and carefully learn the core words and concepts used by experts in the field. Criterion: Common Errors of attributes and Classes
The most common mistake when creating a domain model is to express things that should be conceptual classes as attributes.
If we think that a concept class X is not a number or text in the real world, then X may be a concept class rather than an attribute.
Criterion: when to use "Description" class modeling?
The description class contains information describing other things. For example, productdescription records the price, image, and text description of an item. This type was first named project-description class (item-Descriptor) pattern criterion: When do classes need to be described?
In the following cases, you need to add a description class (for example, productdescription ):
1) A description of the product or service is required, independent of existing instances of any product or service.
2) deleting all the instances that describe things will lead to information loss, which requires maintenance, but is mistakenly associated with the deleted things.
3) reduce redundant or duplicate information associations: associations are relationships between classes, indicating meaningful and noteworthy connections.
In UML, the Association is defined as the "connection between multiple class elements of two styles, involving the connection between these meta instances" association Diagram
Criterion: When indicates Association? Because Domain Models are conceptual, whether to record associations is based on the needs of the real world, rather than the needs of software, although in the implementation process, there will be a lot of associated needs.
The following associations should be considered in the domain model:
1) if there is a relationship that needs to be maintained for a period of time, it is expressed as association.
2) derived association from the common association list
Principle: Why avoid joining a large number of associations?
We should avoid adding too many associations to the domain model. Looking back at the knowledge of discrete mathematics, we can know that there are (N * (n-1)/2 associations between nodes in a graph with n nodes, this may be a very large value. Too many connections will produce "visual interference", making the image messy. Exercise caution when adding associated lines.
Criterion: how to name associations in UML
The Association name is in the format of "class name-verb phrase-Class Name". The verb phrases constitute a readable and meaningful order.
For example, the opposite example of sale paid-by cashpayment should be changed to sale uses cashpayment.
The opposite example of player is-on square. We should assume that player has square
The Association name should be capitalized. In UML, class elements should be capitalized. The following are two common and equivalent valid formats of compound Association names:
Records-current recordscurrent
Apply UML: Role
Each end of the association is called a role. The role has the following options:
1) Multiple Expressions
2) Name
3) Navigation
Application UML: Multiple
Multiple definitions how many instances of Class A can be associated with one instance of Class B. One instance of the store can be "multiple" with the item (* Indicates zero or multiple) instance correlation multiple application UML: Multiple associations between two classes in the UML class diagram, there may be multiple associations between two classes, which is not uncommon. Attribute: it is the logical data value of the object.
Criterion: When to display attributes
When the requirement suggests or implies that the information needs to be remembered, the attribute is introduced.
For example, a ticket in a sales case usually contains a period and time, store name and address, and cashier ID. Therefore, 1) sale requires the datatime attribute.
2) store requires the name and address attributes.
3) Cashier requires the ID attribute in UML. The complete syntax of the attribute is:
Visibility name: Type multiplicity = default {property-string} UML attribute notation
Criterion: which attribute types are appropriate? Common data types include: Boolean, date (or datatime), number, character, string (text), and time: when to define a new data type in the following situations, in the domain model, the data type originally considered as a number or string is represented as a new data type class: 1) consists of different sections. 2) operations related to this, such as parsing or verifying. 3) other attributes. 4) Number of units. 5) one or more types of abstraction rules with the above properties: Any attribute does not indicate that the attributes in the foreign key domain model should not be used to represent the relationship of the concept class. A common violation of this principle is to add a foreign key attribute as in the relational database design to associate two types. Once again, you should use association instead of attribute to associate the type. Domain Model initialization in up: the initial stage will never initiate a domain model, because the goal of the initial stage is not to conduct a strict investigation, but to determine whether the project is worth in-depth investigation and refinement in the refinement stage: domain Models are mainly created in iterations of the Refinement phase. In this case, you need to understand important concepts and map them to software classes through design work. Up Business Object Model and domain model up domain model are the formal variants of Up Business Object Model (BOM) that are rare. Do not confuse with other definitions of BOM. up BOM is an enterprise model that describes the entire business. BOM can be used for business processes or re-engineering without any software application. Conclusion: I read chapter 9 of "UML and model application": This article, written after the domain model, basically summarizes what I think is critical in some books, I hope it will be helpful to my friends who are learning UML like me ....
