1. Metadata Driven Aspect Specification Ricardo Ferreira, Ricardo Raminhos Uninova, Portugal Ana Moreira Universidade Nova de Lisboa, Portugal 7th International Workshop on Aspect-Oriented Modeling

2. Metadata Repository Metadata offers the basis to describe the content, quality and structure of data The repository stores information needed to support navigation over stored data for reuse, versioning control and traceability, through meta-relations Proposal:  Structuring Information (templates)  Representation with XML Schema  Metadata Repository structure  Client Applications

3. Our vision Normalize the representation of concerns Enable the reuse of system components Develop a multi-user open platform that enables consult, addition and refinement of systems Intuitive navigation between concerns in a system and concerns in different systems, from different development activities Propose a set of applications for automatic documentation and validation of systems

4. Making “vision” come true Suggest generic templates to represent systems & concerns Concretise the template through an open format (non proprietary) that can be handled by external applications Develop an architecture based in metadata that enables the support (e.g. storage, querying and management) of information previously formatted Develop a set of client applications that make use of metadata, offering functionalities for editing, visualization and validation.

5. Early Aspects versus Implementation Aspects What approach should be followed?  Early Aspects? Identified in the early (requirements) phase of software lifecycle Offers a set of candidate concerns to aspects Can be further refined by implementation aspects or architectural aspects in later phases  Implementation Aspects? Aspects are only considered in the implementation phase Their identification happens during the implementation process, requiring code refactoring Followed “Early Aspects” approach as it offers a more generic solution and because it also gathers “Implementation Aspects”

6. Two main structures needed A template for systems and another for concerns  offer a clear presentation for the system in terms of the context in which it is applicable and,  define the consequences resulting from its usage

7. System Template Field Name#Description Name1System’s name AliasNAdditional names that also identify the system VersionNChronological register of all previous versions of the system Context1Description of the environment in which the problem and solution occur and for which the solution is desirable MotivationsNDescription of problematic situations intended to motivate the use of the system ConcernsNList of concerns involved in the problem modelling Similar Systems NOther systems similar to the current one Known Uses NDescribes known occurrences and application of the system

8. Concern Template (1) Field Name#Description Concern Name1Concern name SourceNInformation source (e.g. Domain, stakeholders, business process, documents and catalogues) StakeholdersNUsers that need the concern in order to accomplish their job Description1Short description of the intended behaviour of the concern ResponsibilitiesNList of what the concern must perform; knowledge of properties the concern must offer ContributionsNList of concerns that contribute or affect this concern. Contribution can be positive or negative Stakeholder Priorities NExpresses the importance of the concern for a given stakeholder.

9. Concern Template (2) Field Name#Description Priority1Expresses the importance of the concern within the system Required Concerns NList of other concerns needed or requested by the concern being described Outcome1The outcome result for this concern at implementation level Similar Concerns NOther concerns similar to this one Refinement Concerns NImplementation or architectural concerns that can be used to refine the current concern Extensions0...NAdditional extensions to the definition of the concern

10. How to represent the information? Templates  Documental information  Structured XML  Widely used standard (W3C)  Enables the representation of any type of data XML Schema  Widely used standard (W3C)  Enables the definition of a structure for a XML document  Enables the validation of structure and data types Proposal  Use XML Schema for the definition of generic structure (Templates)  Use XML for each of the system and concern instances

11. XML Schemas

12. System Complex Type (1)

13. System Complex Type (2)

14. Concern ComplexType (1)

15. Concern ComplexType (2)

16. Metadata Repository (1) Implements an architecture for storage, access and management of system and concern instances compliant with the proposed templates All instances are XML files, validated by XML Schemas previously defined Support of concepts (Stakeholders, Concerns, ImplementationAspects, ArchitecturalAspects, Systems) and relations between them A database (relational or XML native) will support the infrastructure Offers a set of services to external clients for metadata handling

17. Metadata Repository (2)

18. Future Applications (1) Editor  Management of information stored in the repository: systems, concerns, stakeholders, refinement aspects and versioning  Works as a specialized editor of XML instances  Hides from the user the way how data is stored (XML)

19. Future Applications (2) Visualizer:  Complete system visualization and respective concerns  Navigation: Between systems and concerns Traceability for the decisions made along the software lifecycle (from requirements to implementation)  Offers a set of visualizations (outputs) necessary for documentation and validation purposes

20. Future Applications (3) (Visualizer) VisualizationDescription UML Use CasesUse cases diagram where the concerns and stakeholders are mapped to use cases and actors respectively Match Points Table Identifies a set of Match Points resulting from the composition of concerns Match Points vs. Stakeholders Table Identifies which are the stakeholders involved in the Match Points for the resolution of possible conflicts Composition Rules Set of rules (one per Match Point) that define a sequential composition of required concerns.

21. Future Applications (4) Validator:  Using the visualization offered by the Visualizer, this application enables an interactive process (requires user feedback) of validation  If a violation is detected, it shall be possible to automatically execute the Editor to solve the conflicting information

22. Thank you