Architecture Ecosystem SIG by HC12061613317

VIEWS: 4 PAGES: 21

									Architecture Ecosystem
Foundation (AEF) RFP
         aesig/10-05-01

      Draft RFP Presentation
             June 2010
        Presentation Goals
• Describe the status of the Architecture
  Ecosystem Foundation RFP
• Introduce the problem statement and
  value proposition
• Summarize requirements for addressing
  the problem statement
• Show that the result is achievable
• Work to be done
Architecture Ecosystem Foundation
         (AEF) RFP Status
• Substantial discussions within the Architecture Ecosystem SIG have
  identified the need for an improved foundation for modeling
    – one that better enables a “whole systems perspective” (but this term is
      still under discussion) based on models, from multiple sources,
      representing multiple perspectives and defined in multiple languages
• This is the first public draft and discussion of the RFP for an
  “Architecture Ecosystem Foundation” which we propose be issued
  by ADTF
• Given community refinement and consensus this RFP could be
  issued at the Cambridge Meeting
• Discussion takes place on the architecture-ecosystem mail list, the
  wiki (http://www.omgwiki.org/architecture-ecosystem/) and the
  AESIG meeting Thursday AM
           Summary Of Objectives
•   The full value of modeling and architecture is achieved by understanding
    and defining systems from many perspectives
     – We call this the “whole systems perspective”, also called “macro modeling”
     – “Systems” are inclusive of the enterprise, business architectures, information
       systems architectures, software, processes, rules, services and information.
•   Systems are not insular, they are composed of and interact with other
    systems
•   Today's models typically represent one perspective of one system and are
    difficult to combine with other perspectives so the whole system of systems
    can be understood
•   These different perspectives come from different stakeholders using
    different tools and different languages – but they all talk about the same
    systems and express overlapping information

•   Our objective is to enable the whole systems perspective using model and
    language integration expressed using multiple viewpoints
•   This must be done in an open environment that can leverage a broad
    community
Semantically Federating Multiple
  Viewpoints and Standards
                Problem Statements
•   OMG “Meta muddle” problem
     – Multiple redundant and unconnected standards that redefine rather than reuse
       concepts, creating meta-stovepipes
     – A tendency for each stovepipe to grow to cover everything
•   Difficulty for users to make connections between models in different OMG
    and non-OMG languages
•   UML Futures RFI that called for an improved capability to express UML and
    connect it with other languages with support for viewpoints
•   Business architecture white paper – identified a need for connecting
    business and technical viewpoints
•   UPDM – had difficulty in integrating OMG languages (some MOF, some
    UML profiles) for their needs
•   Weak semantics in language definition
•   Inability to achieve greater value - to support an evolution in architecture
    where whole systems are modeled from multiple, interconnected and
    mutually supportive viewpoints. Viewpoints are dynamically defined by
    architects to tailor the modeling capability to their needs.
 The Model Integration Problem
• The enterprise typically has many models for different parts of the
  enterprise expressing different areas of concern
• While the concerns may be different, the concepts being modeled
  are cross-cutting
• Stakeholders need to be able share model information with others,
  who may have different concerns and perspectives, to make better
  business and technical decisions
• We need to be able to connect and reason about independently
  conceived models so that elements and relations can cross those
  models regardless of source, perspective or language
• To do this we need to “connect the dots” between models
• Example: A process in BPMN may satisfy a requirement in BMM
    The Language Integration Problem
•   Languages are a means of expressing and communicating views
•   Languages are inclusive of textual and diagrammatic representations of
    information
•   Different languages express overlapping concepts and concerns in different
    ways that are difficult to connect
•   By better understanding the common semantics of languages we can better
    understand the common elements of models
•   We need better capabilities to express the semantic relationships between
    languages and the common semantics of languages
•   Information about a system should be able to be projected onto multiple
    languages (textual or graphical), as is suited for a particular purpose
•   This will simplify our set of languages as well as support the definition of
    whole systems perspectives that utilize multiple languages
•   Example: A service defined in SoaML may be implemented by a BPMN
    process and transfer data defined in OWL. These elements should be able
    to be used as if they were defined in the “local” language
        The Need for Viewpoints
• While we want to understand the whole system, we need to enable
  stakeholders to see it in their terms
• Viewpoints provide a lens into the whole system tuned to the needs
  of particular stakeholders
• Viewpoints combine particular parts of the system model and using
  particular languages to create views of the system suitable for a
  stakeholder
• Viewpoints may subset the information in the whole system, may
  specialize vocabulary and use specific notations and syntaxes
• Viewpoint separation: Separating different aspects of a system
• Viewpoint integration: Integrating consistent aspects of a system
• Note: viewpoints and the need for them need to be clarified.
• Example: A security viewpoint deals with roles, processes, data and
  rights using particular diagrams and tables
         The Need for Semantics
• In current meta-models semantics is mixed with syntax and often
  poorly defined, yet over specified
• The same and related concepts are re-invented without any
  connection between them
• Semantics grounds the languages in what they mean
• We have a need for a better semantics foundation to represent the
  concepts we are modeling (in use models and in languages)
• Semantic models need to be able to be layered and modular, not
  requiring a “universal model”
• While we want to enable a semantic foundation, not all language
  concepts should have to be semantically grounded
• Example: The concept of classification by types is almost universal,
  yet UML classifier has no relation to the well defined concept outside
  of UML that may be similar but different
       Notional Architecture
                                     Viewpoint
Viewpoint                                                    Viewpoint

                                   BPMN Notations
                                       BPMN
                                     (Languages)
                                    Languages
UML Notations
   UML
 (Languages)                                Projection         Other Viewpoints
Languages                                                        Other Languages
                                                             Terminology, Structure
                Projection                                         & Notation
                                      Mapping
                                                               Projection
                               Grounding

        Grounding
                                                         Grounding
                                Modular & Layered
                                 Semantic Models
                             Shared & Linking Concepts                 Language
                                                                       Definition
                                                                       & Linking
                                                                       Language
                                                                        (UML+)
                  Requirements (1-4)
1. [Core Semantic Model] The ecosystem foundation shall specify or utilize an abstract
   syntax and formal semantics for those concepts required to define, federate and
   integrate multiple languages and models in multiple languages in support of federated
   domain models that utilize multiple languages. The choice of approach and/or logic
   for specifying semantics shall be explicit. Languages in this context shall include
   modeling languages, business architecture languages, software development
   languages and logical languages.
2. [Concept Relationships] The ecosystem foundation abstract syntax and semantics
   shall include capabilities to semantically relate identical and similar concepts that
   have been independently conceived and represented in the same or different models
   using the same or different languages. This shall include differences in name,
   structure, representation, property sets and underlying theories.
3. [Relationship to MOF] The concepts defined for the ecosystem foundation (6.5.1)
   shall be a superset of the concepts defined in MOF unless specific justification can be
   made for retiring a MOF concept or meeting the same requirements in some other
   way.
4. [Reusable and Layered Modules] The ecosystem foundation shall provide for
   reusable and layered model specification modules and the semantics and
   mechanisms for defining the relationships between these modules. The ecosystem
   foundation must support modules that are overlapping and/or conflicting as well as
   modules representing modeling capabilities that can be combined to form a
   consistent theory. Model specification modules must be usable for the specification of
   languages and may be usable for the specification of domain models.
                  Requirements (5-8)
5. [Core Shall Define Reusable Modules] The concepts that are defined in the
   abstract syntax and semantics for the ecosystem foundation (6.5.1) shall be defined
   using reusable language specification modules. Reusability of these modules for
   other purposes will be a factor in evaluating the quality of the approach but proof of
   generality will not be required.
6. [Exchange Syntax] The ecosystem foundation shall define or utilize a distinguished
   concrete syntax for the exchange of models and model fragments that are instances
   of the foundation abstract syntax and formal semantics. If different from OMG-XMI a
   lossless transform shall be specified between OMG-XMI and the ecosystem
   exchange format.
7. [Language for Language Definition] The ecosystem foundation shall define one or
   more concrete syntaxes that represent the user viewpoint for specifying and
   integrating languages. One of these concrete syntaxes shall be specified as a profile
   of UML that is a superset of the subset of UML that is currently used to specify OMG
   languages
8. [Language for Model Linking] The ecosystem foundation shall define one or more
   concrete syntaxes that represent the user viewpoint for integrating and federating
   user domain models with semantic relationships. This viewpoint shall support the
   integration and federation of arbitrary models expressed in ecosystem languages
                Requirements (9-11)
9. [Projection] The ecosystem shall support the projection of models defined using the
    ecosystem abstract syntax and semantics to syntaxes that may or may not have
    been defined within the context of the OMG
10. [Semantic Grounding] The ecosystem shall support semantic grounding of model
    concepts but shall not require that all concepts are grounded. Where there are
    informal but accepted common concepts the ecosystem shall allow utilization of those
    informal concepts and definitions. Domain models, languages & viewpoints may have
    their own “private” concepts that have no grounding at all.
11. [Shared Concepts] The ecosystem shall support the definition and use of well
    defined representations of shared concepts found in modeling languages (e.g.,
    processes, sub processes, activities, classes, properties, associations, integrity rules,
    derivation rules, events, exceptions and such) and domain models (e.g., an
    accounting, marketing or simulation model). It is only required to define shared
    concepts for concepts that are to be shared as connections between viewpoints may
    be done through such a shared and well defined concept. Well defined does not
    necessarily mean FOL or even logic, but the level of precision needed for the domain.
             Requirements (12-15)
12. [Viewpoints] The ecosystem shall define and provide for a concept of
    “viewpoints” where a viewpoint represents a particular configuration of
    models presented to the user in a particular vocabulary, structure and
    syntax including but not limited to diagrams and/or text. The ecosystem
    shall provide for the same information to be related and synchronized
    across viewpoints that share the same underlying model(s). Viewpoints
    shall be able to be dynamically created by ecosystem architects by
    assembling the models appropriate to a category of stakeholders.
13. [Models as Web Resources] The ecosystem shall provide for modeling
    concepts and model content to be web addressable resources, have a
    unique web identity and be dereferenceable based on that identity.
14. [Query] The ecosystem shall specify or utilize a mechanism to query
    across a defined set of models or viewpoints [potentially] as web resources.
15. [Examples] The ecosystem foundation shall be explicitly validated by a
    representative set of domain models which also are validated by a
    representative set of examples
                                 Definitions
•   What do we mean by “language”?
     – We mean structured languages, not natural languages.
     – Structured languages provide a means to model systems, where systems can
       be:
          • An enterprise, an I.T. system, a physical assembly (like an automobile), information, a
            military unit, etc.
     – Languages defined by OMG:
          • UML, BPMN, BMM, SoaML, SysML, SBVR, UPDM…
     – Structured languages defined externally:
          • SQL, XSD, OWL, RDF, Common Logic, Java, C#, Cobol…
•   What is a system?
     – A system is a set of parts and the relationships between them that, from some
       perspective, can be treated as or act as a whole
     – Some systems interact with their environment, others are closed systems
•   What is a viewpoint?
     – A viewpoint is a lens on the model(s) relative to a system for a particular
       stakeholders needs expressed using an appropriate set of languages
                       Next Steps
•   Review the draft RFP
•   Refine and resolve issues
•   Meet Thursday AM to discuss
•   Ongoing discussion on AESIG mail list

• Goal: Issue at next meeting
                     Issues to discuss
•   Kinds of models
     –   Languages (Meta models)
     –   Generic models (e.g. Patterns)
     –   Domain models (Domain specific part of the “T BOX”)
     –   Instance models (“A BOX”)
•   Goal: Languages that can range over the union of all kinds of models
•   “Alignments” as first class models including shared and linking concepts
•   Implications of the term “whole systems perspective”, may want another
    term
•   Define “system”
•   Reducing RFP size
•   Are viewpoints additive such that they could be done later? Are viewpoints
    and languages the same thing? Are viewpoints, languages and models 3
    terms for 2 concepts?
     – Packaging
     – Closing the world
•   Must exchange syntax have angle brackets?
                                Use Cases
•   “Systems Architect”
     –   Define a model and supporting viewpoints
     –   Extend an existing model, and extend or define new viewpoints on that model
     –   Create a new model and viewpoints that integrate, bridge or link to concepts represented by
         elements of other models and viewpoints
     –   Provide the model and viewpoints to the open Web where they can be exchanged and linked
         to other information in order to drive business value
     –   Extend and specialize modeling languages for their purpose, making new “domain specific”
         modeling languages based on existing languages
     –   Make semantic connections between modeling languages that can either constrain or assist
         the modeling process
•   “Language & Methodology Designer”
     –   Define language semantics, syntax and notations
     –   Use pre-existing language concepts and specialize them for use in a specific language
     –   Define new language concept modules that may or may not be used in other languages
     –   Make semantic relationships between language concepts
     –   Relate the syntax, vocabulary and notation of a modeling language to pre-existing language
         definitions or language specific concepts
     –   Relate a language model to pre-existing exchange formats and meta models.
                               Goals
• Enable
   –   Model definition and integration
   –   Modeling language definition and integration
   –   Support for viewpoints
   –   Support for an open world
   –   Semantic linking between viewpoints and languages [clarify]
   –   Improved model semantics
   –   Improved Domain & Language Model Modularity
   –   Improved Reuse of Model & Language Concepts
   –   Support for Internet protocols exposing model Information
   –   Integration of Current Models & Languages
   –   A vibrant community!
• Provide
   – A Language Definition & Integration Viewpoint
   – A Model Integration Viewpoint
         Optional Requirements
• Non normative integration or refactoring of existing OMG languages
• Open reference implementation (s)
• Test cases

								
To top