Section 21.6. COSMOS: A CONCERN-SPACE MODELING SCHEMA

21.6. COSMOS: A CONCERN-SPACE MODELING SCHEMA

Cosmos is a general-purpose concern-space modeling schema that addresses the requirements outlined in Section 21.5.1. Cosmos models software concern spaces in terms of concerns, relationships, and predicates. We give a concise overview and example of Cosmos in this section (see Table 21-1). A more detailed discussion can be found in [36].

Table 21-1. Cosmos Concern Model Elements: Outline

Concerns Lsogical Classifications Classes Instances Properties Types Physical Collections Instances Attributes Predicates Relationships Groups Predicates // subtypes not elaborated	Relationships Categorical Classification Generalization Instantiation Characterization Topicality Attribution Membership Interpretive Contribution Motivation Admission Logical implementation Logical composition Logical requisition Physical Physical association Physical requisition Mapping Mapping association Physical implementation
Note: Items in normal font are part of the core schema; items in italic font are representative schema extensions used in particular concern models

Cosmos divides concerns into two main categories, logical and physical. Logical concerns represent conceptual concerns, as "matters of interest"issues, problems, "-ilities," and so on. Physical concerns deal with the actual things that constitute our systems, such as specific work products, software units, hardware units, and services. Physical concerns are a way to bring the "real world" (to which our logical concerns apply) into the concern-modeling space. They play a role analogous to that of nodes and artifacts in UML [29].

For completeness, and consistent with a multi-dimensional perspective on concerns, predicates and relationships are also classified as concerns. In other words, a predicate over concerns or a relationship between concerns may itself represent a matter of interest. In many situations, though, it is natural to think of predicates and concerns as top-level elements of the concern space, which is how we discuss them here. There is also a fifth kind of concern, concern groups. These represent the idea that groups of concerns may also be of concern. Concern groups are parameterized by the type of concern they can contain. The element type can be any type in the hierarchy of model elements, so specific concern groups can be made inclusive or exclusive as necessary.

Logical concerns are further categorized as classifications, classes, instances, properties, and topics. Classifications are for modeling systems of classes and allow for multiple classification of concerns [35]. Classes are for categorization of concerns, for example, by functionality, behavior, or state.^[2] Instances represent particular concerns, usually of some class, such as particular functions, behaviors, or states. Properties are characteristics, such as performance, configurability, robustness, that may apply to classes and instances. Topics are groups of concerns of generally different types, typically related to a theme of user interest, such as the classes, instances, and properties that are related to the theme of "logging."

^[2] Classes of concern in Cosmos should not be confused with classes in design notations or programming languages. Cosmos classes serve the purpose of classification of concerns in a taxonomic or ontological sense, which we believe is essential to concern modeling.

Physical concerns comprise instances, collections, and attributes. Physical instances represent particular system elements (such as source files, design documents, workstations). Collections represent groups of these. Attributes are the specific properties of instances or collections, such as the size of a design document or number of files in a directory.

Relationships are divided into four categories: categorical, interpretive, physical, and mapping. Categorical relationships reflect fundamental semantics of the concern categories, such as generalization, which relates (sub)classes to (super)classes, instantiation, which relates instances (both logical and physical) classes, and characterization, which relates properties to kinds and instances.

Interpretive relationships relate logical concerns according to user-assigned semantics. One example is contribution, which indicates that one concern (e.g., logging behavior) contributes in some way to another (e.g., robustness). Another interpretive relationship is motivation, which indicates that one concern (e.g., robustness) motivates another (e.g., logging). Such relationships are especially important in understanding the system-specific semantics of concerns.

Physical relationships associate physical concerns, such as composition relationships that associate Java classes in Hyper/J [16] or connectivity relationships among nodes in a network.

Mapping relationships represent (non-categorical) associations between logical and physical concerns, such as the implementation of a logical function by a Java class. These are important (along with interpretive relationships) for purposes such as dependency analysis, impact assessment, and change propagation. They are also important for assessing component reuse and composition potential.

Predicates represent integrity conditions over various relationships and can be classified accordingly. For example, categorical predicates apply to categorical relationships, and interpretive predicates apply to interpretive relationships. Examples of the former are that no concern can be both a class and an instance and that no class can include both logical and physical instances. An example of the latter is that, if one concern motivates another, then the second should contribute to the first (whereas the converse is not required).