Your SlideShare is downloading. ×
0
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Using Aspects in Architecture Description
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Using Aspects in Architecture Description

251

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
251
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Using Aspectsin Architectural DescriptionRich Hilliardr.hilliard@computer.org13 March 2007 (The 10 minute remix)
  • 2. What the Viewer brings to the Viewed in the Viewing, yields the View. — Douglas T. Ross Creator of plex and SADT (21 December 1929 – 31 January 2007)
  • 3. Questions• Is the aspects metaphor of any use in the Architectural Description of software-intensive systems?• How might this differ from its use in programming?• Should aspects be supported with(in) existing architectural standards and practices?
  • 4. Architecting vs. Programming• Architects routinely practice sophisticated separation of concerns• Non-functional concerns prevail in architecting. (Functionality is easy)• Current architecting practices are based on multiple viewpoints no dominant decomposition in a single language• Is there a role for aspects in this setting?
  • 5. Context• Focus on one portion of architectural practices: Architectural Description• Using the conceptual framework of IEEE Std 1471 (2000), Recommended Practice for Architectural Description of Software-Intensive Systems - Currently undergoing joint revision with ISO as ISO/IEC 42010
  • 6. IEEE 1471 Conceptual Framework Mission fulfills 1..* influences has an Environment System Architecture inhabits has described by 1..* 1 identifies provides Stakeholder Architectural Description Rationale 1..* is important to 1..* is addressed to participates in 1..* selects has organized by 1..* 1..* identifies 1..* 1..* conforms to Concern Viewpoint View used to cover participates in 1..* 1..* has source aggregates 0..1 consists of 1..* 1..* Library Viewpoint Model establishes methods for 1..*
  • 7. Architectural Models• A view consists of one or more architectural models• Architectural models are used to: - facilitate the use of multiple notations (viewpoint languages) within a view ‣ e.g. Kruchten’s 4+1 Logical Viewpoint uses both UML class diagrams and component diagrams - modularize architectural details which apply to more than one view ‣ a model may be shared among views• Viewpoints establish what models may appear in associated view
  • 8. Using Aspects in AD• Definition - An architectural aspect is a shared architectural model addressing exactly one architectural concern• Consequences of Definition - architectural aspects cross-cut architectural views (and their models) - an aspect is the finest-grained solution element expressible
  • 9. Further Consequences of the Definition • There are two kinds of aspects: intra-view aspects (shared within a view) and cross-view aspects (shared among views) • When a model is not shared (i.e, applies in only one place) it is not an aspect—just a constituent of a view • Asymmetric: base remains the views and viewpoint languages
  • 10. Cartoon Example Refers to elements from “base” viewpoint languages —join points Uses elements of “aspect” viewpoint languages
  • 11. Fixing Architectural Models• Models minimally specified in IEEE 1471:2000, no rules applying to them - Can we do better?• Define model ownership, or separate definitions from viewpoints• Enhancing models with provides and requires clauses gives us - Join points - signatures: model types - open question what kind of quantification is needed. type? instance? Hypothesis: “style” in most ADs is universally quantified statements over types• Basis for view integration (which was left open in IEEE 1471:2000)
  • 12. Related Work: several themes• Component & connector-based, single viewpoint (i.e., “ADLs”) - aspects cut across components and connectors (view elements), not across views; e.g., AspectualACME, TranSAT, FuseJ, Fractal Aspect Component, ...Special mention: Katara-Katz• Concern-oriented: the future is better modeling of concerns (Kandé, Sutton- Tarr)• Existing cross-cutting architectural constructs, nicely align with cross-view and intra-view aspects, respectively - Rozanski & Woods’ architectural perspectives - Ran’s architectural textures Workshop on Aspects in Architectural Description http://aosd.net/workshops/aarch/2007/
  • 13. Future Work• Refine an approach to making the provides/requires language(s) more rigorous in the face of an open set of viewpoint languages• Community example using the Health-Watcher case study

×