A brief introduction to domain analysis
Guillermo Arango · 1994
domain.Others, considering that the domain is modelled to increase the efficiency of software construction through reuse, argue that there should be at least three parts to the model: a language, a set of components, and a mapping between statements in the language and component configurations.The distinction is between a model that describes a domain and a model that describes how to build applications in a domain.The interesting question is not who is right (both are!) but to understand what is it that each type of model delivers.The language-as-model perspective is purely descriptive; developers can produce specifications that are "legal" and can determine whether a given specification is irt the domain or is not in the domain as defined by the language.The language÷mapping+component type of model is a superset of the previous one, and has the potential to answer questions about what is irnplementable, how, and what implementation trade offs are available.Developing this kind of model is sometimes called domain engineering.Instead of pursuing these distinctions, we wilt examine the main goals and steps of a specific task, the reuse of software components.From the goals and constraints of that task we derive requirements for what should be in a model of a domain so that we increase the