Aspect-Oriented Design Needs Concern Modeling Stanley M. Sutton Jr.
Peri Tarr
NFA 5 Maple Avenue Chappaqua, New York 10514 USA
IBM T. J. Watson Research Center 30 Saw Mill River Road Hawthorne, New York 10532 USA
[email protected]
[email protected] [12]. Another is “a matter that relates to or affects one” [5]. The IEEE defines the concerns for a system as “... those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders.” [9, p. 4]. As in [17], we regard a concern generally to be any matter of interest in a software system.1 In the design of a software cache component [10], we identified concerns including kinds (and instances) of functionality, behavior, state, and properties; properties, for instance, included generality, configurability, performance, correctness, consistency, transparency, persistence, recoverability, and concurrency [15].
ABSTRACT Concern modeling is the modeling of concerns and their interrelationships as independent, first-class entities apart from their representations in other development work products such as design specifications. Concern modeling is a natural complement to aspect-oriented design and facilitates many objectives in aspect-oriented software development, including (among others) analysis, understanding, evolution, and reuse.
1
INTRODUCTION
Separation of concerns is important throughout the software life cycle. Separation of concerns during design is no less important than at other stages of development. As stated in the Call for Participation for the Aspect Oriented Design Workshop [2] at the First International Conference on Aspect-Oriented Software Development [3], “Without proper attention to concerns during the design of the system, it will be hard to manage complexity, readability, the evolution and composition of the system.” A number of other problem areas may be added to this list, including verification of requirements, management of consistency in designs, and reuse of designs and code.
In contrast, the artifacts in or otherwise contributing to the development of a software system are concrete constructions. They are generally motivated by concerns and they may serve (intentionally or otherwise) to identify, represent, define, describe, model, implement, affect, reflect, or embody those (and other) concerns. Artifacts themselves may be matters of interest, and artifact types and formalisms may introduce dependent concerns and relationships. More fundamentally, though, artifacts are the means by which concerns are “stated or conveyed” (see footnote below) or otherwise addressed.
Despite the importance ascribed to concerns in design, the relationship of concerns to design activities and artifacts is not always well articulated. In this paper we address several aspects of this situation and argue that aspect-oriented design needs to integrate concern modeling and design specification as two separate but coordinated activities. We give some examples of concern modeling with reference to Cosmos [17], a generalpurpose, multidimensional concern-space modeling schema, and address potential applications of concern modeling. Section 2 provides an analysis of the nature and place of concern modeling. Section 3 addresses potential applications in the areas of analysis and understanding, evolution, and reuse. Section 4 briefly addresses some general process-related considerations, and Section 5 summarizes our conclusions. An appendix describing the Cosmos concern-space modeling schema is included after the references.
2
For an example of how concerns and artifacts may be confused, consider that the Call for Participation for this workshop [2] refers to “a tradeoff between simplicity of individual concerns (which improves as you get better separation) and complexity of large numbers of concerns (and numbers increase as you get more separation).” Actually, the number of concerns for a system can be fixed, and those concerns can be seen to have an inherent level of simplicity or complexity that is likewise fixed. However, the artifacts that address these concerns may combine them in smaller or larger numbers, according to our designs. Thus the artifacts may be simpler or more complex, the number of artifacts may be larger or smaller, and there is a tradeoff between the size and complexity of individual artifacts versus the size and complexity of the artifact space as a whole. (A similar analysis applies to the reference to desirable and undesirable interactions of concerns in the workshop themes.)
ANALYSIS
If we consider a concern to be any matter of interest in a software system, then concerns subsume aspects as they are usually defined. The commonly accepted definition of aspect (in this context) is a program property that forces crosscutting in
In this section we argue several points regarding the relationship of concerns and concern modeling to artifacts and artifact development, of which designs and design modeling are an especially important case.
2.1
Concerns Are Not Artifacts
1
There has been a tendency in the past (which continues into the present) to conflate concerns and artifacts. Although artifacts themselves may be of concern, concerns in general are not artifacts. Rather, concerns are essentially conceptual. One dictionary definition of concern is a “matter for consideration”
-1-
“Matter” is an important term in most of these definitions; its relevant senses are “The substance of thought or expression as opposed to the manner in which it is stated or conveyed” [5], “A subject of concern, feeling, or action” [5], and “a subject under consideration” [12].
Once we have separated concerns from software artifacts we can also contemplate relationships between concerns and artifacts. For example, we can note explicitly that particular artifacts relate to particular concerns in particular ways: by representation, definition, implementation, contribution, and so on. It is these sorts of relationships, which are so important for software development, that encourage us to confuse concerns with their embodiments.
the implementation [7]. This definition recognizes the distinction between concerns (specifically properties) and artifacts (specifically implementations), and it calls attention to an important implementation issue. However, it is relatively narrow (focusing on properties and implementations), it categorizes concerns by their effects (rather than by more intrinsic characteristics), and it links the identification of those concerns to artifacts. In our view, a general notion of concern is needed for AOD (and AOSD in general), one that is not dependent on or linked to notions of artifact.
2.2
Finally, since we admit physical artifacts per se as concerns, that is, matters of interest in their own right, not necessarily identical to the other concerns they address, we can also consider relationships among these “physical” concerns. These sorts of relationships might be intrinsic to the artifacts, such as containment, reference, and inheritance, or they might be extrinsic, resulting from some actual or potential use of the artifacts, such as composition or version relationships.
Concerns Are Inherently Separate
As argued above, concerns in the abstract are separate from their representations in various concrete artifacts. In the abstract, concerns are also largely separate from one another. That is, they can usually be identified, understood, and motivated independently. That some concerns may be combined in particular artifacts does not mean that the concerns themselves are inherently combined. In practice, concerns are combined in various ways for widely varying reasons, relating to implementation, language, methodology, legacy issues, reuse potential, and so on.
Relationships on the physical level may be structured quite differently from those on the conceptual level, depending on the mapping of conceptual to physical concerns and on influences on the physical level such as artifact types and formalisms. Various mappings between conceptual and physical levels may occur, for example, given different priorities for concerns at the logical level and different opportunities or constraints for realization on the physical level. In general, there is not a unique refinement relationship between the concern model applicable to design and the design model itself.
In the particular context of object-oriented design and programming, it is virtually necessary to consider functions and behaviors as being associated to methods and methods as being associated to classes. However, in the abstract it is possible to consider alternative distributions of functionality and behavior over methods and alternative distributions of methods over classes. For instance, in the software cache mentioned above, the behavior to purge expired objects from the cache occurs as a side effect of one particular method. In composing alternative versions of the cache [16], we can consider such questions as whether that behavior should be associated with some other method, with multiple methods, or whether it should be made available in a public method of its own. Supporting such separations and alternative compositions should be a major goal of aspect-oriented design.
The Call for Participation and Themes and Goals for this workshop [2] place a strong emphasis on identifying concerns and on identifying relationships among concerns. Both are seen as separable and important activities. We strongly endorse this view, which is especially applicable and appropriate when concerns are seen as separate from artifacts. We believe that the explicit identification, representation, management, and application of concerns and relationships, both among concerns and between concerns and artifacts, are fundamental to the development and success of both aspect-oriented design in particular and aspect-oriented software engineering in general.
The main exception to the inherent separation of concerns in the abstract is that some concern may significantly reference other concerns for definition. For example, properties apply to things and are not very meaningfully or usefully conceived without reference to those things. (What is “configurability” in isolation?) Similarly, functions operate on things and may be difficult do describe without reference to those things. (What is the buffering of a log without a log to buffer?) In such cases, non-separation of concerns, in the abstract, may be essential for the use or existence of at least some of the combined concerns. (In Cosmos [17], a general-purpose concern space modeling language, the “admissions” relationship is used to represent these sorts of conceptual dependencies.)
2.3
Concern Modeling Can Occur Separately from Design Specification
Just as concerns are separate from design (and other) artifacts, so can the modeling of concerns occur separately from the specification of designs. From the perspective of design, this happens already when concerns are identified during requirements specification (and coding, testing, and so on). Additionally, concerns that arise during design can also be modeled separately from the design itself. Requirements (and other non-design artifacts) don’t define or capture all of the concerns relevant to the design of a system, and design-time concerns (that impact the design or other artifacts) may not be treated explicitly or as first class elements in design specifications. Already some design-time concerns are captured in documentation that is separate from design specifications, such as in design rationale documentation.
Concerns in the abstract are also more or less closely related in many other ways. A “pseudo-inherent” linking may be seen between concerns in the abstract if they are inherently linked in a concrete realization. For instance, due to the physical realization of software in computer systems, all functions and behaviors have some performance cost and all software units have some size. Other sorts of relationships among concerns on the conceptual level are less essential and often contextdependent. These may include various kinds of dependency, motivation or rationale, contribution or influence, and so on.
Concerns that arise during design can and should be given a first-class representation apart from design specifications. Even requirements-based concerns that are reflected in design can be abstracted from the design and modeled separately, that is, separately from the design and separately from requirements
-2-
In effect, the independent modeling of concerns helps to achieve a separation of concerns (namely, artifact representations) between stages of the life cycle. Additionally, the relationship of a particular design to a particular requirement is only part of the story about the design. Independently of requirements, the design addresses or reflects certain concerns, those relate to other concerns, and these concerns affect the use (and possible reuse) of the design and its relationship to other artifacts (such as code and test cases).
although related to both of them. Additionally, as described below, this provides a level of indirection between requirements and design, which in turn facilitates evolution and other software engineering objectives.
2.4
Concern Modeling Requires a Formalism
Concerns are modeled explicitly or represented implicitly in all software artifacts. However, many artifact formalisms primarily serve purposes other than concern modeling. Even those that may be considered primarily to address concerns, such as requirements modeling languages, still do not address all concerns (such as concerns that arise at other stages of the life cycle). They also do not comprehensively represent relationships among concerns.
3 3.1
If concerns are to be given first-class status in aspect-oriented design (and across the aspect-oriented software life cycle) then they must have their own first-class representation. Some requirements for a concern-modeling schema are given in [17]. Generally, such a schema should be able to capture concerns and their interrelationships, it should be independent of development artifact types, apply across life-cycle stages, and accommodate a variety of development processes and methods. Additionally, it should be able to reference, if not directly link to, artifacts, resources, and other entities that contribute to or affect a software product and its development process.
Support for Analysis and Understanding
The development of a concern model for a system requires some initial analysis and understanding of the system. Concerns can be understood in the abstract to some extent, but they must also be analyzed and modeled in the context of particular projects, processes, and products. A concern model thus serves as a kind of semantic model or knowledge base about a set of concerns, their interrelationships, and the system and components to which they apply. Once a concern model has been developed, it provides a form of documentation that can be used to convey understanding to subsequent users. A concern model may be passed downstream in the life cycle, such as from requirements to design, or passed to successive users within a given development stage, such as between successive generations of design engineers.
Cosmos [17] is a formalism proposed explicitly to meet the needs of concern modeling. The Cosmos schema is described in an appendix to this paper. In [1] the use of a UML [13] profile for aspect-oriented modeling is proposed. Those authors share our goal of separate modeling for separable concerns. However, their focus seems to be fundamentally on capturing aspectoriented concepts rather than more general concern-modeling concepts, and its application seems to be mainly toward design rather than more general uses. Additionally, the approach of designing a UML profile for Cosmos may not ideal. For example, Cosmos also has different metaclasses and inheritance rules than are found in UML. However, it is quite possible that Cosmos and an aspect-oriented UML profile could be used together in a complementary way.
2.5
APPLICATIONS
The modeling of concerns independently of designs and other artifacts has important advantages. Some are as follows.
A concern model can support additional analyses, depending on the nature of the relationships captured. Consider the Cosmos model of a cache component [15]. This cache has a requirement for robustness that motivates functionality and behavior related to the logging of operations on the cache. Suppose we need a variant of the cache for which robustness is not an issue. We might then be able to drop the logging elements, which would contribute positively to some other concerns, such as performance and size. However, are there other concerns that also depend on or are affected by logging, such as a need for auditing, for which logging should be retained? If we are able to drop logging, are there further concerns that are motivated by or dependent on logging that we can also drop? A rich concern model can support a variety of such analyses.
Concern Modeling Provides Indirection
If we model concerns separately from the artifacts that address those concerns, then we can achieve a useful level of indirection between different work products. As discussed in Section 2.2, artifacts can be related to concerns and concerns to artifacts; additionally, concerns can be related to other concerns. Given these relationships, artifacts need not be directly related to one another. Relationships between artifacts, such as between requirements and, can be traced through intermediary concerns. Thus, a change to requirements may affect concerns based on requirements, but it need not directly affect the design and concerns based on the design. If changes to requirements entail changes to the design (which is the usual case), these changes can be propagated through the concern model. Although the requirements, concerns, relationships, and designs may all be affected, it is not necessary to worry about restructuring direct relationships between requirements and design or restructuring the design based directly on requirements.
Given a formal (or at least structured) representation of concerns and their interrelationships, it also becomes possible to analyze the concern models for correctness, completeness, and consistency. A number of correctness and consistency conditions apply to “categorical” relationships in Cosmos, which relate concerns representing classifications, classes, instances, properties, and topics. For example, a classification should have exactly one root class. Other completeness and consistency conditions apply over the “interpretive” relationships in Cosmos. For example, if one concern motivates a second, that second concern should contribute to the first (but the inverse relationships generally do not hold).
3.2
Support for Evolution
System development is driven by concerns, and system evolution is driven by concern evolution. (Concern evolution is
-3-
important to capture concerns throughout the life cycle and to relate concerns between stages. Concern modeling is thus a crosscutting activity throughout the software life cycle.
driven by external changes, such as organizational and technological change.) Within software development, then, evolution occurs on two levels: that of concerns and that of systems artifacts. The explicit modeling of concerns and their interrelationships supports evolution on both levels.
Typically there are known concerns at the beginning of each life cycle stage or process. At the inception of a development project, the stakeholders have some ideas about the kind of product they want to build, its desired properties, and so on. Traditionally these are first formalized in a requirements specification. When concern modeling is used, a preliminary concern model may be created prior to formal requirements. The concern model may be elaborated as the requirements are elaborated. When design begun, the concerns identified during requirements are available, as are kinds of concerns characteristic of those domains. Additional concerns are identified during design and should be related to previously identified concerns. When coding is begun, the concerns identified during requirements specification and design are available, and so on. The details of how concerns are introduced, adopted, interrelated, and so on are process specific, as are development activities in general.
When concerns are explicit, their evolution can be captured by evolution of the model. Relationships among concerns can help to effect the propagation of changes within the model and to assure that changes are complete, correct, and consistent. When a concern model is related to software artifacts, the model can help to support evolution of the artifacts. It is possible to see which artifacts are directly affected by a change to concerns and which artifacts are indirectly affected through relationships among concerns such as motivations, and contributions. The potential impact of changes can be assessed, desired changes can be planned more systematically in advance, actual changes can be propagated more completely and efficiently, and unwanted or unanticipated effects can be identified and mitigated or avoided. As described in Section 3.1, analysis of the artifacts and associated concern models can help to assure that changes are complete and consistent. If concerns and relationships are modeled across the range of life-cycle artifacts, concern modeling can help to support the coherent evolution of life-cycle-wide “refinements” [4]. Experience in using Cosmos to support the evolution of Java components composed in Hyper/J [8] is described in [16].
3.3
Note that as concerns are identified and incorporated into a concern model, they can be tagged as to their origin, that is, the originating process, stage, activity, author, and so on. Indeed, this has been found very useful in practice [11]. We view such “origination characteristics” as legitimate dimensions of concern in their own right with a potentially valuable role across the extended life cycle and lifetime of a product.
Support for Reuse
The above describes a situation in which concerns are modeled as part of the initial development of a product. It is also possible to “harvest” concerns from, or retrofit concern models to, exist software products. We have done this in analyzing concerns for the GPS cache and in other cases [15, 14]. We have done this by manual analysis of artifacts (e.g., design descriptions and code), by interviewing developers, and by automated analysis of work products. Once a concern model is created for a product or artifact, leverage is afforded for concern-based software engineering (such as concern-based composition with Hyper/J [8] or analysis of concern models in Cosmos). Product-specific concern models can be integrated with larger concern models for product families or enterprise applications as a means for integrating specific “outside” products into a larger development or enterprise context.
Concern models themselves may be candidates for reuse. They will embody important semantic information that may be of persistent value with or without the various artifacts with which the models may be associated in particular projects. Concern models can also support the reuse of artifacts. If a particular artifact is a candidate for reuse, it can be bundled with the associated concern model, to provide a characterization of the concerns it addresses (and does not address). Reuse candidates can be evaluated against reuse contexts in terms of the concerns addressed and required. Requirements or issues related to concerns not addressed can be made explicit. Additional artifacts can be bundled with it, based on association via concerns. In any reuse situation, what is reused is not just software but also concerns. With concern modeling, this can be made explicit.
4
5
Some Process Considerations
SUMMARY AND CONCLUSIONS
There has been a persistent tendency to blur the distinction between concerns with software artifacts. They are not the same: concerns are conceptual, “matters of interest”, whereas software artifacts are concrete software elements that address, embody, or exhibit manifestations of concerns. Concerns are typically separate in the abstract but are necessarily combined in software. Although separate in the abstract, concerns may be highly interrelated among themselves and with artifacts. How concerns should be combined in software and what relationships should apply are fundamental questions of design.
We have argued that concerns should be treated as first-class entities in software development. Likewise, concern modeling should be a first-class activity in software design processes and throughout the life-cycle. Of course, just as there is no single design process or life cycle, there is no single approach by which concern modeling may be applied. Concerns arise all across the life cycle. Thus they arise before, during, and after design activities and from within and outside of design processes. The early stages of the software life cycle (typically requirements analysis and specification) serve mainly to introduce concerns into a nascent product [6, 14]. Similarly, domain modeling may be considered to be primarily about the identification of (domain-specific) concerns. However, additional concerns are introduced at each subsequent stage of development: design, coding, and so on. For this reason, it is
Once concerns and their relationships are seen as independent entities, they can be modeled separately from designs. Concern modeling can be separated from design specification, although in practice they should often be closely coordinated.
-4-
Specialized languages for concern modeling can be used that are separate from languages for design.
[7] Elrad, T., Filman, R. E., and Bader, A. Aspect-Oriented Programming: Introduction. Communications of the ACM, v. 44, n. 10, pp. 29-32. October 2001.
A general-purpose concern-modeling language should support the representation and interrelationship of concerns across the life cycle. It should allow concerns in design to be linked to concerns that arise in other stages. One of the benefits of concern modeling is that it provides a level of indirection between design and the work products of other stages. This allows the removal of direct dependencies between artifacts from different stages, and it facilitates the independence of development and evolution within individual stages.
[8] IBM. Hyperspaces, http://www.research.ibm.com/hyperspace/HyperJ/.
[9] IEEE. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Std. 1471- 2000. Approved 21 September 2000.
[10] Iyengar, A. Design and Performance of a General Purpose Software Cache. In Proceedings of the 18th IEEE International Performance, Computing, and Communications Conference (IPCCC’99), Phoenix/Scottsdale, Arizona, February 1999.
Concern modeling can support many software engineering objectives. For analysis and understanding, concern models reflect prior analyses and support new analyses of concern and application semantics. For evolution, concern modeling supports impact analysis, planning, change propagation, and the evaluation of completeness, correctness, and consistency. For reuse, concern models themselves may be reused as sources of semantic information, and they can further support the selection, analysis, qualification, and adaptation of reusable artifacts both within and between development stages.
[11] Memmert, J. Personal communication. 2001. [12] Merriam-Webster Collegiate Dictionary on line, http://www.m-2.com/
[13] Object Management Group. OMG Unified Modeling Language Specification, version 1.4, Sep. 2001.
[14] Sutton Jr., S. M. Early-Stage Concern Modeling.
We believe that the modeling of concerns should be an independent, first-class activity in design and across the life cycle. For aspect-oriented design, concern modeling is key to capturing what designs are all about and providing a foundation for achieving better concern separation and integration. For aspect-oriented software development, concern modeling is necessary in principle and in practice to achieve the status of aspect-oriented software engineering.
6
Workshop on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design, 1st International Conference on Aspect-Oriented Software Development, Enschede, The Netherlands, April, 2002.
[15] Sutton Jr., S. M. and Rouvellou, I. Concerns in the Design of a Software Cache. Workshop on Advanced Separation of Concerns in Object-Oriented Systems. Conference on Object-Oriented Programming, Systems, Languages, and Applications, Minneapolis, Minnesota, November 2000.
ACKNOWLEDGMENTS
[16] Sutton Jr., S. M. and Rouvellou, I. Advanced Separation of
We thank Isabelle Rouvellou for previous collaborations on Cosmos and concern modeling.
7
Concerns for Component Evolution. Workshop on Engineering Complex Object Oriented Systems for Evolution. Conference on Object-Oriented Programming, Systems, Languages, and Applications, October, 2001.
REFERENCES
[1] Aldawud, O., Elrad, T., and Bader, A. A UML Profile for Aspect Oriented Modeling. Workshop on Advanced Separation of Concerns in Object-Oriented Systems, 2001 Conference on Object-Oriented Programming, Languages, and Systems, Tampa, Florida, October, 2001.
[17] Sutton Jr., S. M. and Rouvellou, I. Modeling of Software Concerns in Cosmos. 1st International Conference on Aspect-Oriented Software Development, Enschede, The Netherlands, April, 2002.
[2] AOD, Aspect Oriented Design (AOD) 2002 Workshop on Identifying, Separating & Verifying Concerns in the Design, AOSD 2002. http://www.iit.edu/~akkawif/ workshops/AOSD2002/AOSD1.html
[3] AOSD, AOSD 2002--1st International Conference AspectOriented Software Development,
http://trese.cs.utwente.nl/aosd2002/ [4] Batory, D. Refinements and Separation of Concerns. Second Workshop on Multi-Dimensional Separation of Concerns, International Conference on Software Engineering, Limerick, Ireland, June, 2000.
[5] Dictionary.com, http://www.dictionary.com/ [6] Early Aspects: Workshop on Aspect-Oriented Requirements Engineering and Architecture Design, AOSD 2002. http://trese.cs.utwente.nl/AOSD-EarlyAspectsWS/
-5-
8
In this appendix we focus mainly on a subset of concerns and relationships, primarily logical concerns and interpretive relationships (explained below). In describing the schema we give brief examples which are taken from an analysis [15] of a general-purpose software cache, the GPS cache [10]. A goal of this cache is to provide a reusable cache that can be configured for a variety of applications. The GPS cache has several "toplevel" concerns. Some, like core functionality and performance, are typical for caches, whereas others, like generality and management of inter-object dependencies, are more unusual. The Cosmos schema is summarized in Table 1.
APPENDIX: COSMOS: A CONCERN-SAPCE MODELING SCHEMA
Cosmos is a general-purpose, multidimensional, concern-space modeling schema. As discussed above, for the sake of generality we consider a concern to be any matter of interest in a software system. We further define a concern space as an organized representation of concerns and their relationships. The Cosmos schema includes three types of elements: concerns, relationships, and predicates. We distinguish between the core schema and extensions to the core schema that may apply to particular installations or applications of the schema.
(The material in this appendix is excerpted from [15].)
Table 1. Outline of the Cosmos concern-space modeling schema Core Concerns
Relationships
Predicates
8.1
Extensions
Logical
Classifications, Classes, Instances, Properties, Topics
Physical
Collections, Instances, Attributes
Categorical
Classification, Generalization, Instantiation, Characterization, Topicality, Membership, Attribution
Interpretive
Significance
Admission, Contribution, LogicalImplementation, LogicalComposition, Motivation
Mapping
Association
Affecting, Description, Modeling, PhysicalImplementation, Representation
Physical
PhysicalRelation
Connection, ConnectionTo, PhysicallyAffecting, PhysicalComposition
subclasses of that class. From a concern modeling perspective, a classification corresponds to a high-level dimension in a concern space. Because concern-spaces are multidimensional, a particular instance may be concurrently classified according to multiple classifications.
Concerns
Cosmos categorizes concerns as logical or physical. Logical concerns represent the concepts in which we are interested regarding a system or artifact, for example, issues, aspects, features, and properties. Physical concerns represent the system elements or software artifacts to which our logical concerns apply. The two are distinguished because logical concerns can be considered independently of physical concerns and physical concerns can be modeled independently of logical concerns. Both are included because the logical motivate our interests in a system or artifact, whereas the physical allow us to model the system or artifacts in which the logical are realized. Ultimately, it is the relationship between the two on which AOSD depends.
8.1.1
In early work [15], we categorized concerns in the GPS cache as internal versus external and functional versus non-functional. External concerns are those seen by users of the system, internal are of concern mainly to developers. Functional concerns include operations and behaviors performed by the system, nonfunctional include properties and state. All identified concerns were categorized according to both of these dimensions. Subsequently, we identified further classifications, for example, classifications of functionality, of properties, of behaviors, of subsets of behaviors (such as configurability or logging behaviors), and so on. Each of these represents a system of classes of particular types of concern.
Logical Concerns
Logical concerns represent the conceptual “matters of interest” in a software system. Examples include functionality, behavior, performance, robustness, state, coupling, configurability, usability, size, cost, and so on. Cosmos does not restrict the domain of logical concerns and leaves it to developers (or other stakeholders) to identify concerns of interest. Cosmos distinguishes five types of logical concern: classifications, classes, instances, properties, and topics.
Some classifications are independent, such as functional versus non-functional and internal versus external. Others are dependent, such as subclassifications of behavior, which apply to concerns that are already classified as behaviors. Classifications are important for organizing the organization of concerns. The ability to explicitly discuss classifications makes it possible to explicitly address alternative approaches to the
Classifications represent systems of classes. They are identified with a root class and transitively include the
-6-
correctness of operation and consistency of cached data. The transparency of aspects of the cache implementation is also a concern for its potential impact on users.
organization and use of concern classes. This is especially important in a multidimensional context, where multiple classifications (and classes) can apply to a given concern and thus where multiple alternative organizations, associations, view points, and access paths for those concerns are possible.
Topics are arbitrary collections of concerns. Topics capture theme-related concerns that may belong to several categories. Topics thus provide a way to organize groups of concerns that cut across other Cosmos categorizations. Whereas classifications contain classes of a particular type, and classes contain (sub)classes and members of a particular type, topics may contain elements of any type.
Classes are concerns that are introduced to categorize other concerns. Classes can include other classes (subclasses) and can be used to classify logical instances, properties, and the various kind of physical concern (all discussed below).2 Classes may be assigned to a classification or may be used apart from any classification.
Configurability is a topic we consider important for the GPS cache. This topic includes classes related to configurability (such as configurability functions and configurable behaviors), instances of these classes (specific functions and behaviors, and configurability-related properties. Another topic important for the GPS cache is algorithms, for example, in the areas of efficient dependency management and garbage collection.
In the GPS cache, some of the classes of functionality identified include core functionality, functionality related to object invalidation, functionality related to inter-object dependency management, and functionality related to cache configuration. Core functionality (to take one example) can be classified into functions to add objects, delete objects, update objects, and so on. Behaviors can be classified into behaviors to implement functions and other behaviors. Behaviors to implement functions can be classified in parallel with the functions implemented. They can also be classified in other ways, for example, according to performance or concurrency characteristics. Other behaviors include subclasses for logging, buffering, and garbage collection, among others. Alternatively, these can be classified according to whether they may be associated with operations or not and, if so, according to the operations with which they may be associated. (Logging, for example, does not implement any operation but is nevertheless associated with operations, whereas garbage collection neither implements nor is associated with any particular operations.)
8.1.2
Cosmos distinguishes three types of physical concern: instances, collections, and attributes. Physical instances represent particular software units, such as .java and .class files. Collections are collections of instances and other (sub)collections, such as packages of code. Attributes are the characteristics of physical instances or collections. (The difference between a physical attribute and a logical property is that the former is a specific characteristic of a specific thing whereas the latter is an abstract concept potentially applicable to many things. For example, performance is a property of interest for the GPS cache, but this general concept is not the same as the specific performance characteristics of specific implementations of the cache.) As physical concerns are not relevant to the examples presented in this paper, they are not discussed further.
Instances are specific concerns that do not classify or characterize other concerns. Instances may be assigned to classes or used independently of any class. Concern instances in the GPS cache represent specific functions, behaviors, state elements, parameters, and so on. These include, for example, functions to add an object, update and object, and add or update an object; specific behaviors such as those involved in supporting specific functions, in logging operations and statistics, in invalidating out-of-date objects, and in maintaining inter-object dependencies; specific state elements including cache state, object meta-data, and dependency information; and specific parameters such as total cache size and maximum object size. Properties are concerns that characterize other (logical) concerns. They can be applied to classifications, classes, and instances. Properties applied to classifications apply transitively to classes in the classifications; properties applied to classes apply transitively to members of the class.
8.1.3
Relationships
Cosmos defines four categories of relationship: categorical, interpretive, mapping, and physical. The Cosmos core schema defines specific types of categorical relationship, while specific types of the other relationships must be defined according to particular installations or applications.
Properties are very important in the GPS cache. The primary goal of the cache is to be general. Toward this end, the cache is highly configurable and richly functional. Of course, performance, persistence, concurrency, and recoverability are concerns for many potential applications of the cache, as are 2
Physical Concerns
Physical concerns represent “real world” elements of a system, potentially including software, hardware, systems, and services. As noted above, physical concerns are represented in Cosmos for two main reasons. First, these are the things, such as software artifacts, to which our (logical) concerns apply and through which our logical concerns are realized. Second, these real-world things are of direct concern themselves, not just as derivative or supportive of logical concerns, but as work products, deliverables, and so on.
8.1.4
Categorical Relationships
Categorical relationships relate concerns based on their categories (Table 1). These relationships reflect the semantics of concern types. There are seven types of categorical relationship: Classification relates a class to a system of classification. Generalization relates classes in an inheritance relationship. Instantiation relates instances to classes to which they belong.
An implementation of the Cosmos schema in Java is under development that allows classes to apply more generally to all kinds of schema elements.
-7-
implementation, which would reflect, for example, that a particular code unit implements a particular function.
Characterization relates properties to the classes or instances to which they apply. Membership relates physical instances to collections to which they belong. Attribution relates attributes to physical instances or collections. Topicality relates concerns of any type to a topic. These relationships are summarized in Table 2.
Table 3. Some examples of contribution relationships for concerns in the GPS cache
Table 2. Cosmos categorical relationships Element Kind (role)
Categorical Relationship
Element Kind (role)
Classification
Classification
Class
Class (superclass)
Generalization
Class (subclass)
Class
Instantiation
Property
Characterization
Topic
Topicality
Collection
Membership
Attribute
Attribution
8.1.5
Domain
Relationship
Range
Configurability Configurability
Contributes-to Contributes-to (variably!) Contributes-to Contributes-to (negatively!) Contributes-to Contributes-to
Generality Performance
Optimization Logging behavior Logging behavior Storage optimization Garbage collection Logging optionality
Logical Instance, Property, Collection, Physical Instance, Attribute (member) Classification, Class, Instance Concern (subject)
Contributes-to Contributes-to
Performance Performance Robustness Optimization Storage optimization Configurability
Table 4. Some examples of motivation relationships for concerns in the GPS cache
Physical Instance (member) Collection, Physical Instance
Interpretive Relationships
Domain
Relationship
Range
Generality Performance
Configurability Configurability
Recoverability Performance
Motivates Motivates Motivates (negatively!) Motivates Motivates
Information hiding
Motivates
Performance
Motivates
Performance
Interpretive relationships reflect interpreted semantic associations among logical concerns. They depend primarily on the context-dependent concern semantics and significance. The Cosmos core schema does not predefine particular interpretive relationship types; these should be added according to concernmodeling needs. In analyzing concerns in the design of the GPS cache, we considered four interpretive relationship types. As indicated in Section 3, relationships such as these are also especially important in early-stage cycle concern modeling. (Indeed, some of these were initially inspired by comparable relationships proposed for requirements engineering.)
Logging Logging Optimization Retrieve objectcopy function Retrieve objectoriginal function
Admission: One concern admits another if one concern makes it sensible to consider another. The introduction of logging admits log buffering. Logging neither requires nor motivates log buffering, but without logging it is meaningless to consider log buffering. Admission reflects the fact that the introduction of some concerns opens the concern space to the consideration of other, semantically dependent concerns.
Contribution: One logical concern contributes-to another if the way in which, or the extent to which, one concern is addressed affects the way in which, or the extent to which, the other concern is addressed. For example, optimization contributes to performance. Contribution is not necessarily positive; for example logging contributes to performance but in a negative way. Contribution is especially important for impact analysis and change propagation. Examples of contribution for concerns in the GPS cache are shown in Table 3.
Some examples of logical implementation and admission relationships for the GPS cache are shown in Table 5. The interpretive relationship types described above serve particular purposes that were relevant to our objectives in modeling concerns for the GPS cache; others may be defined for other purposes. For example, various kinds of dependencies may be defined for rationale capture among concerns.
Motivation: One logical concern motivates another if one concern provides an impetus or justification for the other. For example, performance may motivate configurability and recoverability may motivate logging. (Whether these relationships actually hold depends on the particular case.) Motivation supports rationale capture and impact analysis. Some examples of motivation relationships for concerns in the GPS cache are shown in Table 4.
8.1.6
Mapping Relationships
Mapping relationships relate logical and physical concerns. Physically-implements is an example of a mapping relationship where a physical concern (e.g., a code unit) implements a logical concern (e.g., a function). As with interpretive and physical relationships, the core Cosmos schema defines no particular types of mapping relationships but anticipates that particular types will be defined for particular purposes. Mapping relationships are especially important where logical concerns are used to organize, select, or compose physical concerns (i.e., their corresponding software units) [16].
Logical implementation: One logical concern logically implements another if one concern is introduced relative to the implementation of the other. In the GPS cache, a dependency graph is introduced to for purposes of implement ting object dependency management. This is not the same as physical
-8-
Table 5. Some examples of admission and logical implementation relationships for concerns in the GPS cache Domain
Relationship
Range
Logging
Admits
Garbage collection AND basic functionality
Admits
Cache buffering
Admits
Object dependency graph
Logically-implements
Object invalidation behavior
Logically-implements
Optionality Interaction of garbage collection and basic functionality Cache storage allocation Object dependency management Object dependency management
8.1.7
Physical Relationships
Physical relationships relate physical concerns, for example, reflecting the composition of components into an application. As with interpretive relationships, the core Cosmos schema does not define particular types of physical relationship but allows them to be added according to modeling or analysis needs. The relevance of particular relationships may depend on the kind of physical concerns related, the purpose of the relationship, and on the particular technologies (e.g., development tools) used in working with the physical elements.
-9-
