Domain Model Refinement

DOMAIN MODEL REFINEMENT
DEFINITION
A domain model, or Domain Object Model (DOM) in problem solving and software engineering can be thought of as a conceptual model of a domain of interest (often referred to as a problem domain) which describes the various entities, their attributes and relationships, plus the constraints that govern the integrity of the model elements comprising that problem domain.

 A detailed software development plan, containing:
 An updated risk assessment,
 A management plan,
 A staffing plan,
 A phase plan showing the number and contents of the iteration
 An iterative plan, detailing the next iteration
 The development environment and other tools required
 A test plan
 A baseline vision, in the form of a set of evaluation criteria for the final product
 Objective, measurable evaluation criteria for assessing the results of the initial iterations of the construction phase
 A domain analysis model (80% complete), sufficient to be able to call the corresponding architecture 'complete'.
 A software architecture description (stating constraints and limitations)
 An executable architectural baseline.

REFINEMENT An application domain model describes a class of related applications. As a particular application is read and understood, the application domain model should be refined (specialized and instantiated) to reflect its specific characteristics.

GUIDELINES * Particularly in situations where older programming languages are used, begin by looking for the occurrence of modern control structures implemented by more primitive constructs (representation) * Likewise, look for the use of primitive data structures to represent unavailable ones (representation) * It may sometimes be necessary to reconfigure the control flow of the program to increase structure (representation) * Look for special cases; that is, look for similar sections of code that differ only in a small number of ways. Replace these by the parameterized use of a more abstract construct (generalization) * If the language does not support modularization, look for code that should be grouped together and separated from the rest of the program by an abstract interface (composition, encapsulation) * In contrast, sometimes a programmer intentionally interleaves the accomplishment of two goals within the same section of code. To understand the code, it becomes necessary to segregate the two functions and annotate them separately (interleaving) * If a collection of data items are used together to implement an unavailable construct, annotate that fact (composition) * Make sure that variables are only used for one purpose. Replace dual-use variables by two separate variables (interleaving)

ANNOTATIONS
SR Refinement process is driven by code reading .That is, as constructs are detected in the source code, they are explicitly mapped to domain concepts. Hence, collected annotations can feed refinements and annotations can be updated with the corresponding application concepts.

EXPECTATION GENERATION
Not only does code reading inform the domain refinement process but domain refinement drives code reading .That is, a domain description provides expectations for constructs that should be found somewhere in the code.

ARCHITECTURE KNOWLEDGE
The overall structure of a program is called its software architecture. Architectures are the means by which non-functional requirements(such as performance and security) get reflected in program structure. Programs in a specific domain often use the same architectural approach or architectural style (eg: server-client). Reader knowledge of styles can help generate expectations.

SUMMARY * Design decision recognition can guide the program abstraction process to answer what questions * Domain analysis can generate expectations to help answer why questions * Captured understanding is expressed with annotations * These two refinement activities work together to manage the program reading process