Define Basic Object Modeling

Modeling is a process of abstracting a concept from one domain into a representation of it in another domain. Object modeling means translating words into class definitions.

Maintain consistency with the vocabulary of the problem domain. Where necessary, clarify the users terminology and use their vocabulary as much as possible. This will prevent the common problem where the analysts and users spend their time reconciling two sets of terminology and arguing over interpretation. When you remain faithful to the vocabulary of the user, you will see the users take ownership of the models more quickly. Your questions will demonstrate your desire to understand the users and their needs. This show of respect draws the users into the project and improves your chances of success dramatically.

One of the problems of trying to standardize on a procedural language within a general-purpose standard like UML is that UML is used in a very wide range of problem domains. This calls into question the advisability of prescribing a single language. The argument against mandating the use of a single language, even within a relatively restricted domain, has been summarized as follows: Instead of promoting the one language that will solve all design problems (which does not and will not ever exist) this course takes the view that different problems demand different languages, and a designer who knows the spectrum of available languages has the advantage over one who is trapped using the wrong language.
If a single language is restrictive for embedded systems designers, it is going to be severely limiting for UML users describing the broader spectrum of applications from business systems to real-time software. The OMG chose instead to standardize not a single language, but the semantics that any compliant language must support. In fact, the UML Action Semantics (RFP) Request for Proposal recognized that a single set of action semantics might not be flexible enough to meet the needs of all UML users. It therefore allowed for the provision of several execution profiles to address different user needs. A profile is an extension to the standard UML that enables the construction of specialized models for specific purposes. For example, UML 1.5 provides an example profile for Business Modeling. The Action Semantics specification allows for specific execution profiles for some of the action packages. For example, request handling behavior may be defined on different platforms by means of a profile defining the given system environment.

A reuse domain is a technically related set of application areas. A body of information is considered to be a problem domain for reuse, if a deep and comprehensive relationship exists among the information items as characterised by patterns of similarity among the development components of the software product. A reuse domain is a shared understanding of some community, characterised by concepts, techniques, and terminologies that show some coherence. Examples of domains are accounting software domain, banking software domain, business software domain, manufacturing automation software domain, and telecommunication software domain.
Just to become familiar with the vocabulary of a domain requires months of interaction with the experts. Often, one needs to be familiar with a network of related domains for successfully carrying out domain analysis^[1]. Domain analysis identifies the objects, operations, and the relationships among them. For example, consider the airline reservation system, the reusable objects can be seats, flights, airports, crew, meal orders, etc. The reusable operations can be scheduling a flight, reserving a seat, assigning crew toflights, etc. We can see that the domain analysis generalises the application domain. A domain model transcends specific applications. The common characteristics or the similarities between systems are generalised. During domain analysis, a specific community of software developers get together to discuss community-wide solutions. Analysis of the application domain is required to identify the reusable components. The actual construction of the reusable components for a domain is called domain engineering.

Earlier, you learned how to find classes by evaluating the nouns in everything you have gathered on the project up to this point:

1. the problem statement,
2. the data dictionary, and
3. the use case model.

Each class was given a name and a purpose. Now place these classes on the class diagram. Begin to group them according to how they are used in the problem statement and use cases.

How do objects of the classes in the diagram relate to one another? Look for verbs in the user vocabulary to uncover these relationships, or associations . Here are some questions to ask to help you find and name associations:

1. What does one object do to the other object(s)?
2. Does one object ask for help from another object(s)?
3. Does one object send messages to, or notify, another object(s)?

Try to state the association using active verbs rather than passive verbs, for example, "holds" versus "is held by." Verb phrases are OK too, for example, "defines the use of". In the course project, a customer selects a seat that he or she is interested in, and the system places that seat on hold for that customer. Name the association to reflect this fact much the same way you would write a sentence. Use the class names and add the verb:

[1] Domain analysis: Domain analysis, or product line analysis, is the process of analyzing related software systems in a domain to find their common and variable parts. It is a model of wider business context for the system.