1 / 46

Theme UML Extending UML to treat aspects

Theme UML Extending 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.

achadwick
Télécharger la présentation

Theme UML Extending UML to treat aspects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Theme UMLExtending UML to treat aspects Presented by Moran Birenbaum

  2. 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.

  3. UML – A quick Review • 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

  4. מקרא: מודל סטטי מודל דינמי מודל ניהולי ארכיטקטורת מערכת דרישות מערכת שחקנים, תרחישים, אופני פעולה ישויות, קשרים, יחסים Use Case Model Class Diagram “חבילות עבודה” Package Diagram Activity Diagram פריסת התוכנה על גבי החומרה State Chart לוגיקה, זרימה התנהגות ארכיטקטורת התוכנה פונקציונליות, אינטראקציה Sequence Diagram Component Diagram Deployment Diagram

  5. Design and 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. Why is UML not ‘good enough’ for aspects?

  6. 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.

  7. 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.

  8. 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 actionsare 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.

  9. 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.

  10. 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

  11. 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.

  12. 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.

  13. 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.

  14. 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.

  15. Design Subjects By Features

  16. Design Subjects By Crosscutting Requirements Synchronization

  17. 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.

  18. Types Of Composition Relationship Override Integration • 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.

  19. Example

  20. Types Of Composition Relationship Merge 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.

  21. 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.

  22. Example

  23. Merging Corresponding Operations Merge Integration • 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.

  24. Example Input

  25. Output

  26. 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.

  27. 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.

  28. Example

  29. Synchronize Library

  30. 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.

  31. 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.

  32. Composable Elements

  33. 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.

  34. 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 .

  35. 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

More Related