You have a framework you want to use, but you don’t know its general purpose or if it covers your application domain.
You need to be sure that the framework answers your functional and domain requirements. Not only the general purpose of the framework must be clear but also its reach and the assurance that it covers, if not all, the required problem domain areas and constraints of the application to develop.
How do you learn what is the purpose of the framework and the domain scope it covers?
Learner’s domain knowledge. The easiness of finding where the domain concepts are present, and which areas relate to those domains, strongly depend on the learner’s knowledge about the application domain. Metaphor and technical jargon may be useful to track down and identify hints on component names that might relate to domain concepts.
Expert domain knowledge availability. If such an expert is available for consult, it should nurture and speed up domain knowledge acquisition and promote a domain-driven analysis of the framework.
Documentation. The documentation should give ideas on how the domain is mapped onto the framework. It could contain a brief description of the framework and its main purpose and concepts.
Identify the general purpose of the framework and its application domain by browsing the existing documentation and capture the main domain concepts, how they relate and how the framework addresses them.
A FRAMEWORK OVERVIEW is a good way to do so and GRADED EXAMPLES provide detail on how the main features can be implemented.
Find the framework top components and their metaphor (names and designations) and UNDERSTAND THE ARCHITECTURE of how they are related to cover the domain concepts.
Preserve all the information gathered, adopting a KNOWLEDGE KEEPING strategy.
Broadness. Viewing the framework at this level enables the learner to know the general purpose of the framework and its overall domain applicability.
Shallowness. Without going into more detail it is sometimes difficult, if not impossible, to ascertain if a certain functionality or technology is covered by the framework. As such, one needs to dig deeper and try to UNDERSTAND THE DESIGN INTERNALS in order to understand how some pieces fit in together, because the system requirements need detailed specifications of certain functionalities.
When you know nothing about a framework, usually you try to see what the framework is for. You look for the title, a paragraph, maybe the name of the components. These elements are usually on the documentation that accompanies the framework, whether is a specific document, website or other kind. When trying to find out its purpose, you look for keywords or something that will shed some light about the domain concepts of the framework. It is about graphics? It is about networks? It is general-purpose? What are the concepts it encompasses and how? Only after you’ve acquired this information you start looking for other details.
In [APP04], the process of determining a framework’s suitability to a problem domain starts with the domain analysis activity. This activity has several non-contiguous steps to reach a domain model, where existing documentation (when this documentation is not available for the framework itself, they resort to documentation belonging to exiting application developed using that framework) is reviewed and domain experts are consulted. Also existing standards for the domain are studied. The result of the activity is a domain analysis model containing the requirements of the domain, the domain concepts and the relationships between concepts.