You are on page 1of 26

Domain Engineering

Domain Analysis

Domain Design

Domain Implementation

Domain:
several ways to define domain. Berard gives two characterizations: collection of current and future (software) applications that share a set of common characteristics. A well-defined set of characteristics that accurately, narrowly, and completely describe a family of problems for which computer application solutions are being,and will be sought. an area of knowledge that uses common concepts for describing phenomena, requirements, problems, capabilities, and solutions

Definitions:
process of reusing domain knowledge in the production of new software systems. process for creating a family of programs. Process of analysis, specification and implementation of software in a domain which is used in the development of multiple software products. to achieve a significant increase in software productivity within the chosen domain. to create application generators(or program generators) tools for creating user interfaces, database systems, application frameworks, and wizards of all kinds.

Parts:
Domain Analysis

Domain Implementation

Domain Engineering:
a key concept in systematic software reuse. A key idea in systematic software reuse is the application domain a software area that contains systems sharing commonalities. Most organizations work in only a few domains. They repeatedly build similar systems within a given domain with variations to meet different customer needs.

Domain Analysis:
identifying domains, bounding them, and discovering commonalities and variabilities among the systems in the domain. for determining the terminology, boundaries, commonalities and variabilities of a domain. A definition of domain analysis formulated by Prieto-Diaz elucidates its purpose as: a process by which information used in developing software systems is identified, captured, and organized with the purpose of making it reusable when creating new systems.

Uses:
define the domain

collect information about the domain

produce a domain model.

identify the common points in a domain and the varying points in the domain. the development of configurable requirements and architectures, rather than static configurations which would be produced by a traditional application engineering approach, is possible

Domain analysis is derived primarily from artifacts produced past experience in the domain. Existing systems, their artifacts (such as design documents, requirement documents and user manuals), standards, and customers are all potential sources of domain analysis input.However, unlike requirements engineering, domain analysis does not solely consist of collection and formalization of information; a creative component exists as well. During the domain analysis process, engineers aim to extend knowledge of the domain beyond what is already known and to categorize the domain into similarities and differences to enhance reconfigurability

Domain analysis primarily produces a domain model, representing the common and varying properties of systems within the domain. The domain model assists with the creation of architectures and components in a configurable manner by acting as a foundation upon which to design these components. An effective domain model not only includes the varying and consistent features in a domain, but also defines the vocabulary used in the domain and defines concepts, ideas and phenomena, within the system. Feature models decompose concepts into their required and optional features to produce a fully-formalized set of

Domain analysis techniques:

Several domain analysis techniques have been identified, proposed. developed due to the diversity of goals, domains, and involved processes. Some of them are as follows: DARE: Domain Analysis and Reuse Environment. Feature-Oriented Domain Analysis (FODA). IDEF0 for Domain Analysis.

Models:
The scope of a domain investigation can vary widelyThis information is captured in models that are used in the domain implementation phase to create artifacts such as reusable components,a domain-specific language or application generators that can be used to build new systems in the domain

Arango and Prieto-Diaz present a model of domain analysis summarized in the following SADT diagram.

Figure:

domain analysis as an activity that takes multiple sources of input produces many different kinds of output heavily parameterized.
For example:one parameter is the development paradigm(e.g., SA,Jackson,OO).Raw domain knowledge from any relevant source is taken as input.Participants in the process can be, among others, domain experts and analysts.Outputs are (semi)formalized concepts, domain processes,standards, logical architectures, etc. Subsequent activities produce generic design fragments, frameworks, etc.

Requirements Domain Analysis:


y

When there is enough confidence that a stream of products can be produced, one may want to factor out the commonalities in the multiple analyses that must be done for each product. Thus one may want to do a conceptual domain analysis that yields common ground for each specific analysis. OO analysis notions lend themselves for capturing generic concepts at multiple levels of granularity. Ensembles, subensembles, classes, and generic relationships are all candidates

While we can use the notions and notations from an OO analysis method for requirements domain analysis, we have to adjust the process dimension. We cannot rely on a system-specific requirements document as input to the process. Instead, we have to take in any relevant features from the documentation that describe the commonality of the products. Experts and customers may be tapped, as suggested in the generic diagram. However, the situation differs from the diagram in that people have to be primed for more specific and detailed information. The output side differs as well because the process stops earlier; no model is to be constructed. Instead, generic classes, relationships, ensembles, etc., are produced. These may be organized into one or more OO frameworks that may be specialized to the needs

Generator Domain Analysis:


y

When a stable domain serves as the basis of a product line or market segment, one may consider constructing a generator for a particular domain. This generator may then be used to automatically build (parts of) any of a series of related products. Relational database systems are an example of a mature, stable domain where it is quite conceivable to perform a generator type domain analysis. The query language, platform, operating system and

The analysis performed for the construction of such a meta-program may be seen as a third version of the notion of domain analysis. One may assume for such an enterprise not only that the domain is stable and well understood, but also that domain specific design and/or code libraries are available. y One may even step one level higher. For example, the Rose system (Reuse Of Software Elements)was an experimental meta-meta-program that assisted in
y

Purpose:
improve the quality of developed software products through reuse of software artifacts. y shows that most developed software systems are not new systems but rather variants of other systems within the same field. As a result, through the use of domain engineering, businesses can maximize profits and reduce time-to-market by using the concepts and implementations from prior software systems and applying them to the target system. The reduction in cost is evident even during the implementation phase. One study showed that the use of domain-specific languages allowed code size, in both number of methods and number of symbols to be reduced by over 50%, and the total number of lines of code to be reduced by nearly 75%.
y

The purpose of domain engineering is to identify, model, construct, catalog, and disseminate artifacts that represent the commonalities and differences within a domain. Nowadays, although having slightly different origins, both domain engineering methods and domain specific languages (DSL) receive special attention from the information systems and software engineering

Domain engineering focuses on capturing knowledge gathered during the software engineering process. By developing reusable artifacts, components can be reused in new software systems at low cost and high quality. Because this applies to all phases of the software development cycle, domain engineering also focuses on the three primary phases: analysis, design, and implementation, paralleling application engineering. This produces not only a set of software implementation

Phases of Domain Engineering:

Domain engineering as compared to application engineering. The outputs of each phase of domain engineering feed into both subsequent phases of domain engineering as well as corresponding phases in application engineering. y Domain engineering, like application engineering, consists of three primary phases: analysis, design, and implementation. However, where software engineering focuses on a single system, domain engineering focuses on a family of systems.A good domain model serves as a reference to resolve ambiguities later in the process, a repository of knowledge about the domain characteristics and definition, and a specification to developers of products which
y

Domain design:
y

Domain design takes the domain model produced during the domain analysis phase and aims to produce a generic architecture to which all systems within the domain can conform. In the same way that application engineering uses the functional and non-functional requirements to produce a design, the domain design phase of domain engineering takes the configurable requirements developed during the domain analysis phase and produces a configurable, standardized solution for the family of systems. Domain design aims to produce architectural patterns which solve a problem common across the systems within the domain, despite differing requirement configurations In addition to the development of patterns during domain design, engineers must also take care to identify the scope of the pattern and the level to which context is relevant to the pattern. Limitation of context is crucial: too much context results in the pattern not being applicable to many systems, and too little context results in the pattern being insufficiently powerful to be useful. A useful pattern must be both frequently recurring and of

The objective of domain design is to satisfy as many domain requirements as possible while retaining the flexibility offered by the developed feature model. The architecture should be sufficiently flexible to satisfy all of the systems within the domain while rigid enough to provide a solid framework upon which to base the solution.

Reuse:
y

Domain analysis is not a one-shot affair. Product definitions evolve continuously. The development of a particular system that exploits previously accumulated domain knowledge can be the source for new insights about the domain that adds to or refines codified domain knowledge. In analogy to the emergence of domainspecific code libraries, we foresee the development of domain-specific analysis concept repositories, linked ultimately to code via domain-specific design repositories. The following diagram

Domain implementation:

Domain implementation is the creation of a process and tools for efficiently generating a customized program in the domain. the creation of a process and tools for efficiently generating a customized program in the domain.

You might also like