Frameworks and Template Packages

Chapter 9, Model Frameworks and Template Packages, describes how frameworks are defined in Catalysis and shows how frameworks provide an enormous degree of extensibility to a modeling language. 

Chapter 9, Model Frameworks and Template Packages, shows how recurring patterns of types, collaborations, and refinement can be captured using the idea of a framework a template package. The resulting model can then be used as a skeletal model that is applied with various specializations to different problems. Frameworks enable you to define new modeling constructs. 

Do not lose sight of the domain terms even in your code. Use refinement to maintain trace-ability even as your code becomes more decoupled and reusable. Wherever possible, recast the problem domain descriptions themselves using these orthogonal and more abstract views remember, you are actively constructing a model of reality and not passively discovering it. Use frameworks (see Chapter 9, Model Frameworks and Template Packages) to explicitly document the mapping from domain terms to terms and roles in the abstract problem descriptions. 

Chapter 10, Components and Connectors, describes the richness of component-based developmemt and explains how it raises the level at which implementation units can be connected to build larger systems. Because there is no single answer to what constitutes useful component and connection mechanisms, we use frameworks (see Chapter 9, Model Frameworks and Template Packages) to define the generic building blocks of different component architectures. 

This list includes all kinds of development work. We have already discussed model frameworks and template packages, which can be valuable to an enterprise. They are white-box assets What you see is what is they offer. By contrast, an executable piece of software, delivered without source code, can perform a useful and well-defined function and yet not be open to internal inspection. Software vendors prefer such black-box components. 

Many of the collaborations will follow stereotypical interaction patterns e.g. an interaction which consists of log in, conduct some transactions, and log out or make a selection, and then operate on that selection. These can be abstracted as frameworks (Chapter 9, Model Frameworks and Template Packages (p.371)), then applied and composed to define the system context collaboration... 

The basic tool for representing and combining frameworks is a generic form of package, called a framework or template package. 

This chapter deals with model frameworks and explains how to build and compose them using template packages. It also discusses how the fundamentals of the entire Catalysis approach are themselves defined as such frameworks and shows how they can form the basis for a modeling language that is truly extensible. 

Some of the same patterns of relationships and constraints crop up frequently in modeling and design. In a package separate from our project-specific models, we can define a generic modeling framework for resource allocation it acts as a macro-like template that can be applied in many places. A template can contain any of the modeling constructs in the form of both diagrams and text. Additionally, any name can be written as a placeholder which will be substituted when it is applied to a model."... 

The vehicle for a framework is a generic, or template, form of package. Inside the template, some types and their features can be defined using placeholder names. Looking at its definition in the library, we find that the Observation template has two type placeholders Subject and Observer we have imported that package, substituting Stock and Meter. The sustituted definition becomes part of the model. In other words, whatever attributes and operations are defined for Subject within the template s definition are now defined for Stock. Other names can be substituted, too. The template uses an attribute called value for the aspect of the Subject that we want observed so we substitute it for the Stock s level. 

---