Abstract
A software pattern describes the core of the solution to a problem that tends to (re-)occur in a particular environment. Such patterns are commonly used as a means to facilitate the creation of an architectural design satisfying the desired quality goals. In this chapter, the practical challenges of efficient usage of patterns in domain-specific software development are presented. The specific domain considered here is the mobile domain, for which is given a sample collection of potentially useful patterns. After that, a novel generic architectural model approach for organizing patterns is presented. In this approach, the identification of relevant patterns is considered as the process of reducing the set of candidate patterns by domain-implied constraints. These constraints can be incorporated in a domain-specific generic architectural model that reflects the commonalities in the solutions of the particular domain. This approach has been validated with a real company application development case.
TopBackground
Patterns are now widely used method for documenting and sharing verified design knowledge in the software engineering discipline. Their essential elements include (Gamma et al., 1995): the pattern name, the description of the design problem and its context, the solution describing elements, their responsibilities and collaborations, and the consequences of applying the patterns, e.g., the benefits and trade-offs. There is exhaustive number of patterns available from different sources, in varying quality. These sources include:
- •
Widely known pattern catalogs published as books. These patterns can be expected to have gone through the review process, as the published patterns above, and/or their authors are known experts in the field. Usually, these patterns are widely acknowledged and used, and, hence, can be useful for documentation and knowledge transfer.
- •
Patterns and pattern catalogs published in journals, conferences, or workshops. These patterns have been shepherded and then peer-reviewed by others.
- •
Patterns from free resources (e.g., self-published articles on the Internet). No review process can be assumed for these patterns.
Key Terms in this Chapter
Pattern Catalog: Pattern catalog is a means of systematically collecting patterns, whereby patterns are organized according to certain characteristics, and relationships between them are described. The catalogs usually contain the patterns addressing the most common design problems. One of the most known domain-independent pattern catalogs is the GoF catalog ( Gamma et al., 1995 ); an example of a domain-specific catalog is the Core J2EE Pattern Catalog ( Alur et al., 2001 ).
Pattern: In general, a pattern presents a solution to a problem in a context. In software engineering, it has been defined by Gamma, Helm, Johnson, and Vlissides (1995) as a description of communicating objects and classes that are customized to solve a general design problem in a particular context.
Mobile Domain: The mobile application domain (as a part of the real world) includes the business needs, constraints, and related technical issues imposed by mobile applications. Respectively, the mobile technology domain (as an area of knowledge) represents the class of technical solutions addressing the problems common in the mobile application domain.
Domain-Specific Patterns: Patterns tailored to specific areas of applications, such as embedded software patterns ( Noble & Weir, 2000 ), or the patterns tailored to specific development tools or platforms, e.g., core J2EE patterns ( Alur, Crupi, & Malks, 2001 ; Fowler, 2003 ).
System Design Process: Top-down system design process generally includes the conceptual architecture design phase , where the components to satisfy the stated requirements are identified, and the concrete architecture design phase , where these components and interactions between them are refined ( Matinlassi et al., 2002 ). In practice, the top-down design is combined with the bottom-up design approach, wherein available general solutions – in a form of components, frameworks, platforms, programming languages, personal expertise, etc. – are applied to a range of problems.
Architecture: In the case of a software-based system, its architecture is represented by the logical arrangement of the system’s components, along with their functional characteristics and interrelationships.
Domain: In general, a domain can be seen as a part of the real world or as an area of knowledge bounded by a certain set of constraints. Examples of different types of domains are: business domains, problem domains, application/solution domains, and technology domains.