Theme UMLExtending UML to treat aspects

Presented by Moran Birenbaum

Design and Aspects

The analysis and design of a system are at least as important as the implementation itself.

As with systems in any programming paradigm, aspect-oriented systems need to be designed with good software engineering practices in mind.

Aspect-oriented design has similar benefits for design as aspect-oriented code has for code.

UML is a standard language for object oriented analysis and design specifications.

UML is composed of 3 models:– Structural Diagrams– Behavior Diagrams– Model Management Diagrams

UML – A quick Review

פריסתהתוכנהעל גביהחומרה

PackagePackageDiagramDiagram

“חבילות עבודה”

:מקרא

מודלסטטי

מודלדינמי

מודלניהולי

SequenceSequenceDiagramDiagram

פונקציונליות,אינטראקציה

ActivityActivityDiagramDiagram

לוגיקה,זרימה

ComponentComponentDiagramDiagram

ארכיטקטורתהתוכנה

StateStateChartChart

התנהגות

ישויות,קשרים,ClassClassיחסים

DiagramDiagramUse CaseUse Case

ModelModel

שחקנים,תרחישים,

אופניפעולה

דרישות מערכתדרישות מערכת

DeploymentDeploymentDiagramDiagram

ארכיטקטורת מערכתארכיטקטורת מערכת

Design and aspectsWhy is UML not ‘good enough’ for aspects?

• UML was not designed to provide constructs to describe aspects.

• Trying to design aspects using object-oriented modeling proved as problematic as trying to

implement aspects using objects.

• We need special support for designing aspects.

Theme

Provides support for how to both identify aspects in a set of requirements, and how to model them in UML style designs.

Themes are more general than aspects. We view each piece of functionality, or requirement, or aspect or concern a developer might have as a separate theme to be catered for in the system.

Themes may be related to each other, in the same way as requirements or features or aspects are related to other parts of the system. Such relationships may cause overlaps in the themes.

Theme

The Theme approach is made up of two portions:

Theme/Doc - Which is a set of heuristics for visualization and analysis of software requirements documentation.

Theme/UML - Which is a way to write aspects as UML.

Theme/Doc

Theme/Doc provides support for identifying crosscutting behavior from descriptions in a requirements document.

First step: Identify Actions and Entities– Identifying a set of "sensible" key-actions in a requirements document.

Second step: Classify Actions– Simplifies the view by deciding which actions are major or minor.

Third Step:Associate Requirements with Crosscutting Actions– Examines the linkages between the major actions. – Examines the shared requirement to determine whether it highlights a

crosscutting relationship between the actions.

Theme/DOC

Forth Step: Look at Themes– After themes have been identified and refined, they can

be viewed using the theme view.– translating the Theme/Doc views into Theme/UML.

Fifth Step: Augment Themes– Theme views are augmented to add in design decisions. – In order to give the developer a chance to consider

whether the decisions were appropriate.

Theme/UML - Motivation

Problem - There is a well documented problem in the software engineering field relating to a structural mismatch between the specification of requirements for the software systems and the specification of object oriented software system.

Causes - This mismatch happens because the interest during the requirements phase is different from the interest during object oriented design and implementation.

Result – A single requirement being scattered across the design units and a single design unit supporting multiple requirements (tangling).

Solution: Theme/UML

Theme/UML

Designing system based on the object oriented model, but extending this model by adding new decomposition capabilities.

Each model contains a design of an individual requirements.

Composition of design models are specified in composition relationship, by identifying overlapping concepts in different models and specifying how models should be integrated.

Library Management System - LMS

The system handles addition, removal, ordering and search for books and periodicals (resources).

The system handles borrowing and returning resources. The system can impose fines for a late return. Technical requirements:

– management services are available concurrently.– Changing entities services should only run one at a time and lock

query services.– Multiple query services should be allowed to run concurrently.

The Model

Design for each requirement a different package.

Within each individual package use object oriented techniques – All UML design models may be included.

The decomposition encapsulates Requirements so scattering is removed.

Tangling is also removed since each requirements are separated into different models.

Decomposing Design Models

For object oriented design models, matching the structure of requirements means dividing the design models to separate packages to match the structure.

Those packages are called Design Subjects. Various kinds of requirements can be designed in design

subjects:– Features– Crosscutting requirements – like distribution– And so on…

Advantages: comprehensibility, traceability, evolution and reuse.

Design Subjects By Features

Design Subjects By Crosscutting Requirements

Synchronization

Composing Design Models

After decomposing the designs we will have to compose them in some stage later in order to understand the design of the system as a whole.

Composition relationship – A relation between two design models specifying how those design models are to be composed.

Different kind of composition may be attached to a composition relationship.

Composition of design subjects results in a new design subject containing the integrated elements of the “input” design subjects. The input design subjects remains unchanged.

Types Of Composition Relationship

• This composition relationship is used when an existing design subjects need to be changed.

• A new requirement indicates that the behavior specified in the existing design subject is no longer appropriate.

• An existing design subject is changed by creating a new design subject that contains the design of the appropriate behavior to support the new requirement.

• Then override the existing design subject with the new design subject.

Override Integration

Example

Types Of Composition RelationshipMerge Integration

• This composition relationship is used when different design subjects contain specifications for different requirements of a

computer system.

• This may appear when reusing design subjects from previous versions of the system or from an outside source.

•The full system design is obtained by merging the design of the separate design subjects.

Merge Integration

Merge with reconciliation required

• Explanation by an example:

•In the LMS merging AddResource and RemoveResource.

•A conflict is encountered since AddResource and RemoveResource have different specifications.

•The conflict is solved by giving a precedence to one of the merged designs.

•The precedence determined by the developers.

Example

Merge IntegrationMerging Corresponding Operations

•Merging the specifications of operations in the result implies that all corresponding operations are added to the merged subject.

•Merge integration means that an invocation of one of the corresponding operation results in the invocation of all corresponding operations.

•Where operations have a return type, the default behavior is that the value returned by the last operation run is returned.

•The order of the execution is set arbitrarily, but can be determined by a collaboration indicating the order.

Example

Input

Output

Composition Patterns

Crosscutting requirements has behavior that will affect multiple classes in different design models in a uniform way.

For design models that support crosscutting requirements, composition of those models with other models is likely to follow a pattern.

Example : Synchronization in LMS.

For these kind of requirements, subject oriented design model defines a mechanism called composition pattern.

Composition Patterns

The use of templates as placeholders for elements with which the crosscutting functionality will interact supports the independent design for such functions.

Example: Template – Synchronization

Function - AddResource

The composition patterns model extends standard composition relationship with a bind[] attachment that defines the elements that replace the templates within the composition pattern.

Ordering of the parameters in the bind[] attachment matches the ordering of the templates in the pattern’s template box.

Example

Synchronize Library

UML Metamodel Extensions

UML is defined using a metamodel, which defines the syntax and semantics of the UML and described itself in UML.

Similarly the syntax and semantics of composition relationship is described.

Composable Elements

Design elements that may participate in a composition relationship.

The impact of integration on design elements depends on the kind of elements they are.

Divided into two types:– Primitives – Elements whose full specifications are

composed with other primitives. Example : Attributes, Operations, Associations.

– Composites – Elements that contain other elements and cannot be considered as primitives.

Example : Subjects and Classifiers.

Composable Elements

Composition Relationship

Defined between composable elements.

Elements composed with their corresponding elements.

Elements are said to “correspond” when they “match” the purpose of composition, where correspondence matching specification is a part of the composition relationship.

Composition relationship is a sub class of the Relationship metaclass.

Summary

Standard object oriented design does not align well with requirements causing scattering and tangling.

Subject oriented design is described as a means of achieving alignment between requirements and object oriented design to solve this problem.

We decompose by requirements and than compose them by

composition relationship. Each subject can be designed separately .

References

Theme home page at:http://www.dsg.cs.tcd.ie/index.php?category_id=353

Theme/UML home page at: http://www.dsg.cs.tcd.ie/~sclarke/ThemeUML/

Siobhan Clarke “Extending standard UML with model composition semantics”

http://webcourse.cs.technion.ac.il/234321