Dieses Dokuwiki verwendet ein von Anymorphic Webdesign erstelltes Thema.

Pattern: Selecting a Framework

You are someone (manager, project leader, developer) who is responsible for finding a solution for an application development project in a certain domain. You are about to select a framework that can help you to solve your problem.

Problem

Framework selection consists of deciding whether to reuse or not a framework, after evaluating its appropriateness for an intended application in a specific domain.

What do you need to learn about a framework in order to select it effectively?

Forces

Effort. You don’t want to spend too much time learning what you need to know to effectively decide if a framework is selectable.

Certainty/Sureness. You need to be sure that the framework you’re about to select covers, not only your application domain, but also all of your specific needs.

Documentation. The existing documentation may not give the necessary insight into the applicability of the framework.

Complexity. The more complex a framework is, the harder it is to understand.

Solution

Start by quickly understanding the framework under consideration. Look for a short description of the framework's purpose, the domain covered, and an explanation of its most important features, preferably illustrated with examples.

In order to ascertain if a specific framework covers your domain requirements, you need to UNDERSTAND THE APPLICATION DOMAIN in a clear way, i.e., the domain covered by the framework, and the range of solutions for which the framework was designed and is applicable.

However, knowing the purpose of the framework is not always enough to ensure that all the problems may be met by this framework. It can be important to go deeper to UNDERSTAND THE ARCHITECTURE , U UNDERSTAND THE DESIGN INTERNALS , or UNDERSTAND THE SOURCE CODE , until being sure of the framework’s appropriateness for the problem at hand.

To be more effective, you may consider to DRIVE YOUR LEARNING according to your experience and specific requirements.

Consequences

Cost-effectiveness. You quickly gain insight into the scope of the framework and its coverage of your specific needs. Going into detail gives you more accurate hints on how the framework is built and addresses your problems.

Narrow knowledge. Yes, it solves your specific problems, but that doesn’t give you a whole grasp over what other specific problems it might address. Further investigation might be needed when new contextual-related problems arise.

Rationale

When using frameworks, one of the key decisions that need to be made is whether or not the framework fits the application. Since frameworks can be complex,gaining a deep understanding of the framework to make that decision often requires the time consuming process of actually using the framework. Capturing information about the applicable domain of the framework is a way to ease this decision [FHL00]. Limitations and design trade-offs about the framework can help to show what the framework can and cannot be used for. There will always be degree of uncertainty but that can be mitigated by existing documentation or the potential user will often perform experiments to increase their understanding of the framework and to evaluate its appropriateness to the new application.

See also

In [TW07], Andrew Turner and Chao Wang had to evaluate a set of existing AJAX frameworks and select the most suited for their requirements. Their process relied on ascertaining that all the frameworks could cover their specific domain and high- level requirements. They had to dig deeper into the framework internals and even develop some prototypes to test if the framework could address and solve their specific issues.

In [APP04], Sheick et al. proposed and applied a criterion for ascertaining the suitability of a framework to a specific project. It relied on a set of areas to inspect, starting with the intended domain and evolving into detailed issues like the presence of design patterns and lower-level concerns such as error handling and degree of coupling. They then applied their criteria to characterize an existing framework for a transaction processing system implementation called jPOS ISO 8583, to see if it was suitable for selection.

fudocs/selectingaframework.txt · Last modified: 2015/07/22 20:35 (external edit)
Trace: understandthearchitecture selectingaframework
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0