First, the domain modeling of business requirements
1. Gather information Applications
- Focus on functional requirements - also consider other requirements and documentation
2. Brainstorm
- sets out the essential concepts applications - listed their properties / property - lists the relationships between them
3. The concept of business classification
- Class - attribute / attribute values - Relationship
4. association, inheritance, polymerization
It describes the UML class diagrams to document the results of
Second, the top ten domain modeling method
1. Watch the real world (problem areas) object.
When you create a domain model, be sure to focus on problem areas together with the actual object. Try to organize around real-world software architecture. The real world is often less demand than software changes. The following figure shows two different types of symbol classes. For complete details on the class diagram, using the left version, its attributes and operations. However, the initial modeling art, these classes of premature dispensing portion. Preferably using simple symbols shown on the right. This version displays the name of the class of the field only.
2. Generalization (is-a) and polymerization (has-a) to show how the relationship between objects associated with each other.
Over time, new areas will be used to identify the domain model classes. Notice contact (or association) between them - for example, book reviews books belong, PO (purchase order) and credit cards (credit card) are two, because they are the type of payment.
The first relationship (a book review book belongs) is referred to as polymerization (has-a, because there will be a book, a book review). The second relationship (purchase orders and credit card payments are type) is called generalization (is-a, because the purchase order is the payment type). Figure 2-3 shows a description of these concepts.
These so-called general relationship between the domain model is the most important relationship. Class relationships can use aggregation and generalization modeling model in ninety-five percent. Do not use as much as possible "association", from left to right and from top to bottom so that the domain model reading, just as plain text. This will improve the readability of the chart.
3. The initial domain modeling work is limited to a few hours.
A domain modeling started to do may be the most important two hours spent on the project! During the two hours of the outbreak of the mind, you may find 80% of the class domain. If 80% of the field names can be lexical disambiguation, then spend two hours.
4. around problem areas "critical abstraction" to organize classes.
Around problem areas of "critical abstract" organization category it is usually a good practice. Remember, the domain model is an advanced class diagram, form the basis for software architecture. This makes the model more flexible to face change. Abstract around real-world organizational structure makes the model more resilient in the face of changing demand, because demand often changes more frequently than the real world.
5. Do not be mistaken for the domain model data model.
Even these figures may be similar, but remember that good practices data model in the class diagram may not be good practice (and vice versa). Class is small, the table is relatively large. Relational database tables typically involves many things. Conversely, if it is a relatively small data and behavior (methods) package, the design would be better to use the class.
In the class diagram, there may be a database management class table, may show some categories of conventional polymerization TableManager domain class. The purpose of this type of class is TableManager details from the rest of the code base hidden database management system (DBMS) is.
6. Do not an object (representing a single instance) database table (which contains the set of things) confusion.
An object represents a single thing. Database table represents a collection of things. You do not have to like the character in the world of enterprise JavaBeans (EJB), as an entity bean typically represents a single row in the table. FIELD class is similar. If you call a field of books, it does not mean that the book table (database which did not), but a book. Database table columns are typically mapped to the attribute class.
However, database tables typically comprise more than the column that contains properties (typically with the foreign key table as one example), and therefore may not be a direct line between the tables and objects: 1 mapping.
7. Use the domain model as a project glossary.
If the fuzzy requirements (ambiguous) has become your enemy, then the field model is the first line of defense. "Projects in the area subject matter experts" to the ambiguity of naming names and use is very common but it is very harmful (there are different names for the same vocabulary). Domain model should be the project glossary, help to ensure consistent use of terminology in describing the problem space. Use the domain model as a project glossary model is the first step to eliminate ambiguity. In each Jumpstart teaching professor Doug, he found at least two to three areas were class, which students use ambiguous names (such as "shopping cart shopping cart," "," shopping basket shopping basket "or" shopping cart shopping trolley ").
8. Before written cases, do some initial domain model, use the name to avoid ambiguity.
Domain model to eliminate the use of an abstract problem areas, the use of the term does not expressly written domain class described embodiment is foolish. Therefore, before you write use cases, please spend two hours working on the domain model. Write domain model with no cases tied together all the contents stored a lot of problems for later use
9. Do not expect the final match exactly the domain model class diagram, but there should be some similarities between them.
As the design class diagram model is more detailed than the domain; domain mode deliberately kept fairly simple. In the design (using the sequence diagram), the detailed design configurations (e.g., GUI Helper class factory class and infrastructure) to add to the class diagram, FIG domain model can be almost divided into several classes detailed in FIG. However, most classes can still be traced back to an equivalent field of class.
1. Do not place the screen (screens) and other GUI-specific classes on the domain model.
Doing so would open a Pandora's box and lead to a crowded field model, which contains many specific implementation details. Performance Optimization category, aides etc. should also be retained beyond the domain model. Domain model should only focus on problem areas.
Third, my final engineering practice Modeling Diagram
Engineering Practice Description: Using 3D modeling software for modeling the head in the input video stream, capturing the head of the implementation of the action and expression changes, data and video streams in real-time animation redirection allows showing a virtual human even the image of
