Section 21.8. RELATED WORK


21.8. RELATED WORK

In this section, we consider approaches to modeling at the early stages of the software lifecycle. Early stage activities, such as requirements specification and architectural design, are of particular interest because these are activities whose primary purpose is to introduce concerns into a development project. We consider two sets of modeling approaches: "traditional," non-aspect oriented modeling approaches, and new aspect-oriented modeling approaches.

21.8.1. Traditional (Non-Aspect Oriented) Modeling

Here, we describe some representative modeling approaches in which concerns are identified in the form of requirements or design elements but in which concerns, as such, are not first-class entities. The lack of consideration for concerns as first-class entities is one of the principal motivations for Cosmos.

21.8.1.1 Requirements Engineering: i* and Tropos

i* is a framework for modeling organizations in terms of actors, goals, and dependencies. Tropos is a methodology that applies this to early requirements and provides a basis for extending early requirements to late requirements, architectural design, and detailed design [7, 42].

Tropos emphasizes the need to identify organizational concerns, separate them from implementation concerns, and give them first-class treatment. Toward this end, Tropos posits five main classes of concern: actors, resources, goals, soft goals, and tasks. A particular requirements model contains multiple instances of each of these classes. Properties are not represented directly in the Tropos schema but may be captured in hard or soft goals (e.g., "increase friendliness of customer service"). Tropos and i* incorporate several types of concern relationships, including decomposition, means-ends, and dependency relationships.

21.8.1.2 Requirements Engineering: KAOS

KAOS [5], like i*, offers a goal-dependency model of requirements and takes a view of concerns that is appropriate to requirements and separated from implementation. KAOS also provides some downstream continuity, from requirements to architectural refinement.

In contrast to Tropos, KAOS adopts a more explicitly multi-dimensional perspective on requirements. Conceptually, requirements in the abstract and elements in a model can be associated with different "aspects" (in their terms) such as "why," "who," "when,"and "what." Requirements also have a dual linguistic dimension, including both an "outer" semantic net for general types and semantic relationships and an "inner" assertion language for detailed temporal and logical semantics. Goals can be further classified according to their domain, such as robustness, safety, efficiency, and privacy. Goals are also subject to disjunctive and conjunctive refinement. The KAOS system also supports multiple views of the requirements, including refinement, operationalization, entity-relationship, and agent.

As in Tropos, properties per se are not a first class construct in KAOS but are represented indirectly by other constructs such as goals and constraints. In addition to refinement, KAOS relationships also include operationalization and responsibility.

21.8.1.3 Architectural Design: ABAS

ABAS are "attribute-based architectural styles" [23]. These styles address specific quality attributes and can be analyzed in terms of these attributes.

ABAS modeling is explicitly multi-dimensional. It incorporates a number of classifications, including classification of architectural attribute information (in terms of external stimuli, architectural decisions, and responses), classification of architectural elements (in terms of components, connectors, and properties), classification of ABAS specification elements (such as problem description and stimulus/response attribute measures), and classification by property. Additionally, parameters in each of the categories of information are subject to multiple simultaneous classifications. For example, stimuli are classified with respect to mode, source, and regularity, and responses are classified with respect to latency, throughput, and precedence.

ABAS, in contrast to the requirements methods described previously, treat properties explicitly and prominently. All architectural styles are classified with respect to the properties of performance, modifiability, and availability. These crosscut the information categories so that the kinds of information used to describe stimuli, architectural decisions, and responses for performance are different from those used for modifiability. For example, performance responses can be described in terms of latency and throughput, and modifiability responses can be described in terms of extent of impact and effort of change.

The sorts of relationships that are emphasized in the requirements modeling approaches (dependency, responsibility) are not highlighted in ABAS. Of course, ABAS describe kinds of physical relationships (connections) among components that observe various architectural styles. Additionally, ABAS include potentially detailed and quantitative analytical models that describe how specific property measures relate to architectural elements and changes to those elements.

21.8.1.4 Architectural Design: DSSAs

Domain-specific software architectures (DSSAs) make (repeated) use of a domain model, reference requirements, and reference architectures common to a family of applications [39]. The domain model usually includes a lexicon, ontology, and taxonomy of terms and entities belonging to the domain. The domain may be characterized in terms of objects, relationships, products, behaviors, and so on. The architecture, depending on the style and representation, typically comprises elements such as components, connectors, constraints, dependencies, responsibilities, and capabilities. The reference requirements are typically expressed in terms of the domain model and linked to elements in the reference architecture.

All the elements of a DSSAdomain model, requirements, and architectureexpress concerns of some sort. The domain model defines a domain of concern (or a domain of concerns) but in a way that is abstract from the motivations and objectives of any particular project (i.e., from the things that make a "matter of interest" interesting). Requirements express concerns in the form of specific needs and goals relating to applications in the domain. Architecture begins to introduce concerns about how those needs and goals are to be addressed.

21.8.1.5 Observations on Non-Aspect Oriented Modeling Approaches

The approaches described previously are advanced techniques for modeling software requirements or architecture. They all represent concerns or enable users to represent concerns in a particular form for a particular purpose. For example, ABAS identify concerns in the form of architectural features and properties that are associated with particular architectural styles but independent of a domain. DSSAs, in contrast, present domain-specific concerns in the form of a domain model, requirements, and architecture. Tropos/i* and KAOS support users in specifying concerns in the form of requirements. Thus, the outcome of these approaches is elements specific to requirements and design, even though the concerns they represent typically cut across activities and artifacts from the whole lifecycle. Cosmos is intended to support a concern-modeling approach that can transcend particular activities and artifacts and span the entire lifecycle.

Each of the modeling approaches discussed previously also reflects some explicit or implicit assertion about how concerns of various types should be represented. However, these approaches typically draw on many of the same modeling techniques, such as enumeration, single and multiple classification, views, templates, relationships and associations, abstraction, properties and attributes, and conditions and constraints. These modeling techniques are thus generic with respect to modeling approaches and domains, and Cosmos likewise makes use of many of them.

21.8.2. Aspect-Oriented Modeling

There has been a flurry of recent work in the areas of aspect-oriented requirements engineering and architectural analysis, as well as in the area of more general concern modeling. In contrast to the modeling approaches reviewed previously, a major goal of these recent approaches, as for Cosmos, is to identify concerns or aspects as such. We discuss some examples here.

21.8.2.1 Aspect-Oriented Requirements Engineering and Architectural Analysis

Aspect-oriented requirements engineering (AORE), like all requirements engineering, aims to capture requirements. However, it explicitly recognizes that at least some requirements represent aspects or concerns that will crosscut both requirements and downstream lifecycle artifacts. Thus, AORE approaches include techniques for explicitly modeling aspects or concerns, at least in the context of requirements specification. For example, Brito and Moriera [6] define a process for separation of concerns in requirements that includes steps for identifying concerns, specifying concerns, identifying crosscutting concerns, and composing concerns. Baniassad and Clarke [2] propose the Theme/Doc approach to identify crosscutting behaviors that represent aspects in requirements documentation. Tekinerdogan [38] argues that explicit mechanisms are needed to identify, specify, and evaluate aspects in architectural design. He proposes ASAAM, an Aspectual Software Architecture Analysis Method that provides a set of heuristic rules to allow architectural aspects to be identified based on usage scenarios. Bass, Klein, and Northrop [3] are developing a method to derive a software architecture from required quality attributes and propose that these attributes often represent architectural aspects that can be carried through detailed design and implementation.

21.8.2.2 Concern Modeling

Concern modeling in a still more general sense is now addressed by several approaches. Wagelaar [41] proposes a concept-based approach called CoCompose for the modeling of early aspects. In CoCompose, the concepts involved in a software system are first modeled independently of any implementation; the conceptual models can then be processed to automatically generate an implementation. Lohmann and Ebert [25] propose a generalization of the hyperspaces [16, 37] approach to concern modeling that replaces orthogonal dimensions of concerns with nonorthogonal clusters of concerns and allows a unit to be assigned to more than one concern in a dimension. Lohmann and Ebert distinguish primary and secondary dimensions of concern in which the primary dimensions are based on artifacts and the secondary dimensions represent user interests that are not derived from corresponding artifacts, although these concerns may still be related to artifacts.

Finally, IBM, in part as a successor to Hyper/J [16], initiated development of the Concern Manipulation Environment (CME), a platform for the development and application of cross-lifecycle aspect-oriented technologies [15, 31]. The CME includes a concern-management component, ConMan, which supports general-purpose, multi-dimensional concern modeling, including concerns, relationships, predicates, and various ways to group and associate these. Concerns may be related to artifacts or independent of them, and concerns may be used to organize artifact composition and extraction, to support querying and analysis, and for other purposes with or without artifacts. The CME is now an Eclipse Open-Source project [10].

21.8.2.3 Observations on Aspect-Oriented Modeling Approaches

The aspect-oriented approaches to requirements and architecture analysis take a step toward generality of concern modeling: they enable particular requirements or architectural elements to be specified, and they recognize that these elements represent more general aspects or concerns that crosscut multiple development stages and artifacts. However, concern modeling in these approaches is still focused mainly on particular activities and on artifact representations appropriate to those activities. Approaches such as those in [25] and [41] take concern modeling a further step toward generality. They provide very general notions for the modeling of concerns, although ties to artifacts are still prominent in these models. ConMan in the CME provides the most general and artifact-neutral approach to concern modeling. ConMan, like Cosmos, is a generalization of the hyperspaces approach, although the basic concepts in Cosmos are at a somewhat higher semantic level than those in ConMan. For instance, ConMan includes a wide variety of constructs for grouping concerns, whereas Cosmos has just a few simple constructs for grouping concerns but also includes constructs for semantically categorizing concerns. In the future, we hope to implement Cosmos concepts on top of ConMan.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net