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
. 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.