Your SlideShare is downloading. ×
Using UML for 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 UML for architecture description

602
views

Published on

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
602
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
1
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 the UML for Architectural Description Rich Hilliard rh@isis2000.com current email: r.hilliard@computer.org Copyright © 1999 by Rich Hilliard
  • 2. Outline • What is IEEE P1471? • The IEEE P1471 Conceptual Framework • Requirements on Architectural Descriptions • Using the UML in the Context of P1471 • Wrap Up Copyright © 1999 by Rich Hilliard
  • 3. What is IEEE P1471? • IEEE Draft Recommended Practice for Architectural Description • Begun in August 1995 by the IEEE Architecture Working Group – 30+ participants – 150+ international reviewers • Recently completed balloting by IEEE – to be issued by IEEE Computer Society • http://www.pithecanthropus.com/~awg Copyright © 1999 by Rich Hilliard
  • 4. IEEE Goals for P1471 • Focus on the architecture of software-intensive systems • Establish a conceptual framework and vocabulary for talking about architectural issues of systems • Identify and promulgate sound architectural practices • Allow for the evolution of those practices as relevant technologies mature Copyright © 1999 by Rich Hilliard
  • 5. Ingredients of IEEE P1471 • A normative set of definitions for terms like “architecture”, “architectural description”, “architectural view” • A conceptual framework establishing these concepts in the context of use of architectural descriptions for system construction, analysis and evolution • A set of requirements on an architectural description of a system Copyright © 1999 by Rich Hilliard
  • 6. Using P1471 • IEEE P1471 is a recommended practice – One kind of IEEE standard • P1471 applies to Architectural Descriptions – How to describe an architecture – Not a standard architecture, or architectural process, or method • P1471 is written in terms of “shall,” “should” and “may” – ADs may be checked for conformance to the recommended practice – P1471 does not define any conformance of systems, projects, organizations, processes, methods, or tools Copyright © 1999 by Rich Hilliard
  • 7. What is an Architectural Description? • In P1471, an architectural description is a collection of products to document an architecture • P1471 does not specify the format or media for an architectural description – Notation-independent • P1471 does specify certain (minimal) required content of an AD reflecting current practices and consensus Copyright © 1999 by Rich Hilliard
  • 8. The P1471 Conceptual Framework (excerpt) influences has an Environment System Architecture inhabits has 1..* described by 1..* is important to identifies 1..* Architectural Stakeholder Description is addressed to 1..* organized by 1..* has identifies 1..* 1..* selects 1..* Concern Viewpoint View conforms to used to cover 1..* participates in 1..* consists of 1..* 1..* Model establishes methods for 1..* Copyright © 1999 by Rich Hilliard
  • 9. P1471 Requirements:Stakeholders and Concerns • ADs are interest-relative: – An AD identifies the system’s stakeholders and their concerns • Concerns form the basis for completeness: – An AD addresses all stakeholders’ concerns Copyright © 1999 by Rich Hilliard
  • 10. P1471 Requirements:Views • Multiple views: – An AD consists of one or more views – A view is a representation of a whole system from the perspective of a set of concerns • Views are themselves modular: – A view may contain one or more architectural models, allowing a view to utilize multiple notations • Inter-view consistency: – An AD documents any known inconsistencies among the views it contains Copyright © 1999 by Rich Hilliard
  • 11. P1471 Requirements:Viewpoints • Views are well-formed: – Each view corresponds to exactly one viewpoint – A viewpoint is a pattern for constructing views – Viewpoints define the rules on views • No fixed set of viewpoints: – P1471 is “agnostic” about where viewpoints come from • Concerns drive viewpoint selection: – Each concern is addressed by an architectural view • Viewpoints are first-class: – Each viewpoint used in an AD is “declared” before use Copyright © 1999 by Rich Hilliard
  • 12. Declaring a Viewpoint• Each viewpoint is specified by: – Viewpoint name – The stakeholders addressed by the viewpoint – The stakeholder concerns to be addressed by the viewpoint – The viewpoint language, modeling techniques, or analytical methods used – The source, if any, of the viewpoint (e.g., author, literature citation)• A viewpoint may also include: – Any consistency or completeness checks associated with the underlying method to be applied to models within the view – Any evaluation or analysis techniques to be applied to models within the view – Any heuristics, patterns, or other guidelines which aid in the synthesis of an associated view or its models Copyright © 1999 by Rich Hilliard
  • 13. A Viewpoint Example • Viewpoint name: Capability • Stakeholders: – The client, producers, developers and integrators • Concerns: – How is functionality packaged? – How is it fielded? – What interfaces are managed? • Viewpoint language – Components and their dependencies (UML component diagrams) – Interfaces and their attributes (UML class diagrams) • Source: also known as Static, Application, Structural viewpoints Copyright © 1999 by Rich Hilliard
  • 14. Example:Capability View Win95 or Presentation JVM <<client-server>> User Interface <<client-server>> "Raw" <<interface>> Capability Generalized Capability <<client-server>> <<conforms>> <<interface>> Data Access DAI Data Access (XML DTD) Interface <<client-server>> Data Store SQL • The Capability View covers all system functionality for operating on data • Capabilities are fielded using a 5-tier layered organization with interfaces between pairs of layers – Each layer is a capability – Entire stack is a deployable capability • Capabilities can serve other capabilities Copyright © 1999 by Rich Hilliard
  • 15. Library Viewpoints• Viewpoints are not specific to a system; unlike the stakeholders and views• Hence, an architect ought to be able to reuse viewpoint declarations – Equivalently, viewpoints can be included by reference• It would be nice to have a standard way to document viewpoint declarations in UML Copyright © 1999 by Rich Hilliard
  • 16. Example:Viewpoint Name: Structural • Concerns: – What are the computational elements of a system and their organization? – What element comprise the system? – What are their interfaces? – How do they interconnect? – What are the mechanisms for interconnection? • Viewpoint language: – Components, connectors, ports and roles, attributes • Analytic Methods: – Attachment, type consistency Based on: Acme: An Architecture Description Interchange Language, Garlan, Monroe, Wile, Proceedings of CASCON’97, November 1997 Copyright © 1999 by Rich Hilliard
  • 17. “Viewpoint Scale”:P1471 is intended to encompass... 4+1 View Model: design [logical] process implementation [development] deployment [physical] Zachman (36! Views)Implicit Structuralism use case view(point)s(CMU) (Kruchten, Rational) AF Integrated C2 System C4ISR capability, data, distribution, operational security, construction technical system view(point)s (US DOD, Open Group) Copyright © 1999 by Rich Hilliard
  • 18. Approaches to Using the UMLin the Context of P1471 • “Out of the Box” – Pre-existing diagram types are all applicable to architectural description • Lightweight Extensions – Tagged values, stereotypes, constraints are typically used “per viewpoint” – View and viewpoint notions are between extension and profile in their granularity • UML as Integration Framework – View and viewpoint are nascent concepts in UML but not reflected in the metamodel • Outside the UML Ontology – Some concerns architects worry about fall outside UML ontology – Security, Reliability, Commerce, Management, ... Copyright © 1999 by Rich Hilliard
  • 19. Enhanced Metamodel Model View Viewpoint governs uses * * Diagram Diagram Technique guides * ModelElement Copyright © 1999 by Rich Hilliard
  • 20. Wrap Up Copyright © 1999 by Rich Hilliard
  • 21. Fragment of a Big Picture: Internet Engineconcern(s) viewpoint How is data shared? How to build this? How to deliver it? Client How is functionality procured and packaged? Capability Data view Producer IE::Capability IE::Data Can this be built? What to build it with? inter-view relationship (e.g., traceability relations)stakeholder Construction IE::Construction Copyright © 1999 by Rich Hilliard
  • 22. General Issues (Outside of just P1471) • Are components (e.g. ACME) UML components? • Traceability mechanisms between views (within and between viewpoints) • Variation á la product lines v. individual systems • First-class constraints (rather than constraints as annotations) {see ISAW-3 paper} • Finer control over things like Visibility, Inheritance – the built-ins are fine for design, programming level • Declaring new diagram types • Capture of fragments (i.e., patterns and styles) Copyright © 1999 by Rich Hilliard