ADMtutorial_admtf05-05-01.ppt
Upcoming SlideShare
Loading in...5
×
 

ADMtutorial_admtf05-05-01.ppt

on

  • 906 views

 

Statistics

Views

Total Views
906
Views on SlideShare
905
Embed Views
1

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Conceptual entities Project A project is an abstraction of a complete or partial software system from which data has been extracted and placed into a KLOCwork inSight database. Views of the project data are presented using the KLOCwork inSight client tools. Projects are “built” by the KLOCwork Architecture Compiler. Models All projects have a system view model. They may also have a process view model and any additional models or “views” that your administrator creates to provide meaningful interpretations of your software system, for example, a packaging view. Diagrams The KLOCwork architecture models consist of package diagrams and object diagrams. Package diagrams The KLOCwork Suite provides graphical representations of your software system both as a hierarchical tree diagram and as a block diagram that shows one level of the hierarchy at a time. You can navigate through the system hierarchy in both types of diagrams. Object diagrams Object diagrams are containers for language-level symbols (for example, procedures, variables, types, macros, etc.) Architectural packages or “blocks” Blocks are containers for software entities that share a common purpose or are closely related . They may be entirely conceptual (exist only in the model), or they may be based on actual entities in the source code. You can double click on a block to go inside it. You can navigate down the levels of the hierarchy until you reach file-level blocks. You can view the symbols within file-level blocks on object diagrams or directly the source code, using flowcharts. Dependency lines Lines represent dependencies between blocks, or between blocks and the software system’s environment. The numbers beside the lines represent the number of relationships that exist between two blocks. The KLOCwork Suite lets you see lists of details about the relationships and interfaces between blocks.

ADMtutorial_admtf05-05-01.ppt Presentation Transcript

  • 1. Architecture Driven Modernization Tutorial © Copyright 2005 Software Revolution, Inc & Klocwork, All Rights Reserved
    • Architecture Driven Modernization
    • Tutorial
    • Athens, Greece
    • Wednesday, April 13, 2005
    Philip Newcomb Chief Executive Officer The Software Revolution, Inc. (TSRI) 11410 NE 122 nd Way Kirkland, Washington 98034 Phone: 425-284-2770 [email_address] www.softwarerevolution.com Nick Mansurov Chief Scientist & Architect Klocwork 1 Chrysalis Way Ottawa, ON Canada K2G6P9 Phone 1-613-2277 ext 204 [email_address] www.klocwork.com
  • 2. Tutorial Outline
    • ADM Introduction        9:00 – 9:50 Mansurov & Newcomb         - ADM Mission         - ADM Roadmap         - ADM Scenarios         KDM                             10:00 – 10:50 Mansurov         - KDM RFP Status         - KDM Vision         - KDM Business Significance         - KDM Relationships with Other OMG Stds         - KDM Meta Model         - KDM Related Technologies         ASTM                           11:00 – 11:50 Newcomb         - ASTM RFP Status         - ASTM Vision         - ASTM Business Significance         - ASTM Relationships with Other OMG stds         - ASTM Meta Model         - ASTM Related Technologies
    •   ADM Wrap-up Discussion  12:00 – 12:30 Mansurov & Newcomb
  • 3. What is the ADM and its Mission?
    • The OMG chartered the Architecture Driven Modernization Task Force in 2003 to extend MDA practices and standards to existing systems.
    • The task force cochairs are
      • Djenana Campara (Klocwork)
      • Bill Ulrich (Tactical Strategy Group)
    • The OMG Architecture Driven Modernization Task Force (ADM TF) has defined the following 4 goals:
      • The ultimate goal - Revitalization of Existing Applications
      • Make existing applications more agile
      • Leverage existing OMG modeling standards and the MDA initiative
      • Consolidate best practices leading to successful modernization
    • ( http:// adm . omg .org/ )
  • 4. How does ADM support MDA?
    • MDA is a top-down model-driven process for new system development.
      • Architectural models provide portability, interoperability and reusability through architectural separation of concerns
      • Architectural models direct the course of understanding, design, construction, deployment, operation, maintenance and modification.
    • ADM incorporates bottom-up extraction of architectural models followed by top down reuse in MDA processes and scenarios for legacy systems modernization.
  • 5. Why does MDA need ADM?
    • ADM closes the gap between methodologies
    • tools available for new and old software
      • “ We are addressing a big gap between methodologies and tools that are available for developing new software — for example, the OMG MDA — and the total lack of tools and methodologies that help you to be successful with your existing code.”
    • (William Ulrich, 2003)
  • 6. How do ADM Tools fit into the MDA?
    • ADM tools must adhere to the standards for software modeling, as defined by the Object Management Group (OMG).
      • Technically no ADM tools exist yet … because the OMG has not yet approved any ADM Task Force Platform Committee standards.
      • To be compliant with OMG MDA principles, ADM tools must be compliant with the OMG MOF
    Meta Object Facility Amen
  • 7. What is the ADM Roadmap? Data Structure Behavior Action Semantics (OMG) RFP 1 Abstract Syntax Trees (RFP 2) Analysis (RFP 3) Metrics (RFP 4) Visualization (RFP 5) Refactoring (RFP 6) Target Mapping & Transformation (RFP 7) Knowledge Discovery (RFP 1) User Interface RFP 2 RFP 7 RFP 6 RFP5 RFP 4 RFP 3 To structure its work the ADM PTF platform task force is defining seven interrelated standards, starting with the KDM followed by the ASTM.
  • 8.
    • RFP I KDM
      • Submitters
        • Klocwork & ASG with Tactical Strategy Group
        • IBM and Flashline
        • EDS
        • Distributed Systems Technology Centre (Australia)
      • Voting List
        • Klocwork
        • Tactical Strategy Group
        • ASG (Allen Systems Group)
        • EDS
        • Distributed Systems Technology Centre
        • IBM
        • Flashline
        • ArtInSoft
        • BluePhoenix
        • TSRi (The Software Revolution)
        • TMGi (Trinity Millennium Group)
        • Transoft
    Who is the ADM Platform Task Force?
    • RFP II ASTM
      • Submitters
        • The Software Revolution
        • Klocwork
        • IBM
        • EDS
        • TCS America
        • Interactive Objects Software GmbH
        • ASG
      • Voting List
        • ASG
        • DSTC
        • Data Access
        • EDS
        • Fujitsu
        • Interactive Objects Software
        • IBM
        • Lockheed Martin
        • Rockwell Collins
        • TCS America
        • Thales
        • The Software Revolution
        • Klocwork
    Anybody can join, but you have to pay your dues !
  • 9. What is the relationship between the KDM and ASTM?
    • The ASTM and KDM are complementary elements of the ADM Roadmap
    ASTM RFP #2 Abstract Syntax Tree Meta-model Programming Language Constructs ASTM is information source for KDM Below Procedural Level They are complementary but individually useful standalone standards . KDM RFP #1 The Knowledge Discovery Meta-model Comprehensive high-level view… Behavior Structure Data Above Procedural Level
  • 10.
    • From KDM perspective:
      • The ASTM is one means of populating the KDM.
      • The ASTM extends the KDM to support comprehensive and detailed modeling of systems.
    How are the KDM and ASTM independent?
    • From ASTM perspective:
      • The KDM as well as the ADM Roadmap are several MDA MOF models the ASTM populates from its highly detailed and precise models of systems.
      • The KDM is one source for information about systems which can guide large-grained analysis, metrics, visualization, model mapping, transformations & refactoring which the ASTM supports .
      • The ASTM does not directly depend upon or intersect with the KDM for any part of its meta-model definition.
      • Together the ASTM and the KDM provide high fidelity support for ADM scenarios when effectively combined.
  • 11. Transformation Perspectives of KDM and ASTM?
    • From KDM perspective:
    • Transformation is an augmentation strategy that includes:
      • Understanding application data, structure and behavior and architecture
      • Making legacy systems more reliable and adaptable
      • Extracting and rationalizing data definitions, data and business rules
      • Redesigning and reusing legacy rules and data within the context of strategic enterprise architecture.
    • From ASTM Perspective:
    • Transformation is a direct strategy that includes :
      • Model driven mapping of data, structure and behavior between language feature sets (language translation).
      • Model driven restructuring of language feature sets with replacement of undesirable features with reliable and adaptable features (application refactoring)
      • Model driven rationalizing of data definitions, data and business rules by abstraction to MDA data views (models) that support model-driven regeneration of specific language features.
      • Model driven rearchitecting of systems by abstracting design patterns and applying generation, transformation and refactoring to regenerate redesigned and rearchitected enterprise applications.
  • 12. ADM Roadmap
    • 1. Knowledge Discovery Meta-Model Package (KDM) – (adopt ’05)
      • establishes an initial meta-model
      • allows modernization tools to exchange application meta-data across applications, languages, platforms and environments
      • provides a comprehensive (inventory) view of application structure and data, but does not represent software below the procedure level
    • 2. Abstract Syntax Tree Meta-Model Package (ASTM) – (adopt ’06)
      • adds representation of software below the procedural level
      • allows full representation of applications and facilitates the exchange of granular meta-data at the translation level across multiple languages
      • Unifies all syntactical language models into a common abstract syntax meta model.
    • 3. Analysis Package (AP) – (initiate ‘05)
      • facilitates the examination of structural meta-data with the intent of deriving detailed behavioral and structural meta-data about systems
      • may take the form of design patterns, business rules or other aspects of a system that are not an apparent part of the structure of the system, but are rather semantic derivations of that structure and the data
    • 4. Metrics Package (MP) – (initiate ‘06)
      • derive numeric metrics that describes measurable technical, functional and architectural properties from the structural and the behavioral aspects of the applications of interest and its data.
      • supports planning and estimating, ROI analysis and the ability of the enterprise to maintain application and data quality
  • 13.
    • 5 . Visualization Package (VP) – (initiate ‘07)
      • – builds on KDM, ASTM, AP and MP
      • focuses on ways to depict application meta-data stored within ADM models.
      • May include any variety of views appropriate or useful for planning and managing modernization initiatives
      • Examples include the use of graphs or charts, metric summaries or standardized development models
    • 6. Refactoring Package – (initiate ‘08)
      • – builds on KDM, ASTM, AP, MP and VP
      • defines ways in which the ADM models be used to re-architect applications
      • Includes structuring, rationalizing, modularizing and in other ways improving existing applications without redesigning those systems or otherwise deriving model-driven views of those systems
    • 7. Target Mapping & Transformation (TMT) Package – (initiate ‘09)
      • – builds on KDM, ASTM, AP, MP, VP and RP
      • Defines mappings between the ADM models and target models to enable transformation
      • Development paradigms may vary, but will include MDA as a target
      • completes the ADM task force efforts in providing a transformational bridge between existing systems and target architectures
    ADM Roadmap (cont.)
  • 14. Why define ADM Scenarios?
    • Helps envision all potential ADM applications.
    • Helps a user determine the tasks, tools and use of the ADM.
    • Provides templates for crafting project objectives, plans and related deliverables.
    • Defines tasks necessary to complete a given modernization initiative and omits unnecessary tasks that would not apply to such a scenario.
    • Allows a user to pinpoint the types of tools necessary to perform these tasks.
    • Identifies the universe of modernization scenarios and tasks and provides a guide as to the role of the ADM within modernization in general.
    • Bill Ulrich, ADM Scenarios White Paper 04-09-04
  • 15. How do you use Modernization Scenarios?
    • Use Scenarios to define approach to various application improvement, migration and redesign initiatives that an organization may pursue.
    • Use Scenarios to pinpoint the types of tools necessary to perform these tasks.
    • Mixed and Match Scenarios based upon the organization’s Modernization goals.
    • Language-to-language conversion might be coupled with a platform migration for example.
    • Other scenarios may be added to this list from time to time…
    • Bill Ulrich, ADM Scenarios White Paper 04-09-04
  • 16. Modernization Scenarios Matrix
    • MODERNIZATION GOAL:___________________________________________
    See Handout Bill Ulrich, ADM Scenarios White Paper 04-09-04 . XI. Reusable Software Assets / Component Reuse XII. Model-Driven Architecture Transformation X. Application Package Selection & Deployment IX. Data Warehouse Deployment VIII. Application & Data Architecture Consolidation VII. Data Architecture Migration VI. Services Oriented Architecture Transformation V. Non-Invasive Application Integration IV. Platform Migration III. Language-to-Language Conversion II. Application Improvement I. Application Portfolio Management Check Box Modernization Scenario
  • 17. Modernization Resources On The Web Instructor’s Web Sites TSRI www.softwarerevolution.com Klocwork www.klocwork.com Case Study Sites By Language and Market Military www.adamodernization.com Business www.cobolmodernization.com Scientific www.fortranmodernization.com Aerospace www.jovialmodernization.com Informational Web Sites General/Historical www.legacysystemmodernization.com Technical www. automatedsoftwaremodernization .com Perspectives www. modeldriventransformation .com ADM Vs. COTS www.cotssolutions.com
  • 18. KDM            10:00 – 10:50 Mansurov
    • KDM RFP Status
      • - KDM Vision
      • - KDM Business Significance
      • - KDM Relationships with Other OMG Stds
      • - KDM Meta Model
      • - KDM Related Technologies
  • 19. Dr. Nikolai Mansurov Chief Scientist & Architect Knowledge Discovery Meta-model: Tutorial 13-04-2005 Athens
  • 20. Business case for KDM Existing software: complex, multiple technologies; multiple vendors; Need to extract knowledge in order to: understand, maintain, improve, transform, modernize Need cooperation between vendors – starting with common knowledge representation
  • 21. What is KDM ?
    • The RFP solicits proposals for a Knowledge-Discovery Meta-model (KDM) for exchanging information related to transformation of existing software assets. Specifically, the proposal seeks a common repository structure for representing information about existing software assets and its operating environments.
    • KDM represents the structure of the existing software and its related artifacts. It provides the ability to document existing systems, discover reusable components in existing software, support transformations to other languages and MDA, or enable other potential transformations.
    • The meta-models will enable exchange of information about existing software artifacts among different tools. This will enable vendors that specialize on certain languages, platforms or types of transformations to deliver customer solutions in conjunction with other vendors.
    1 Meta-model for representing information about existing software assets Exchange of information between tool vendors 3 Includes software and its operating environment 2
  • 22. What exactly is KDM ?
    • KDM represents the principal artifacts of existing software as entities (the structural elements, the “things”), their relationships and attributes
    • KDM spans multiple levels of abstraction:
      • Implementation
      • Design
      • Architecture
      • Business rules
    • KDM provides traceability to artifacts
    • KDM is independent of implementation language and platform
    • KDM can represent multiple heterogeneous systems
    • KDM is extensible
    7 Focuses on structure of existing software to provide context for modernizations 4 Represents existing software as Entities, Relationships and Attributes 5 Language-independent yet extensible 6 Spans multiple abstractions yet traceable back to artifacts
  • 23. Eroded software resists comprehension Not enough abstraction
  • 24. Managed architecture gives context for modernization
  • 25. Focus on structure of existing software at higher levels of abstraction …
  • 26. .. to capture knowledge User input Validation Buffer Buffer Input procesing Feature code
  • 27. Knowledge “dimensions” in KDM UI “things” Data “things” Structural “things” Behavior “things” Code “things” Conceptual architecture Domain model Requirements, Features, Use Cases Approximates modeling world from the ground up Based on Architecture Views
  • 28.
    • ASTM and KDM
  • 29. Example source code
  • 30. Abstract Syntax Tree Func_decl Sys_fcntl var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) Expr_stmt = Var_decl err Cmpd_stmt Security_op call_decl do_fcntl Func_decl Do_fcntl Expr_stmt = Var_decl err Call_stmt Fcntl_setlk(fd) Func_decl Fcntl_setlk var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) cmpd_stmt Use filp
  • 31. AST and Control Flow (intraprocedural) Func_decl Sys_fcntl var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) Expr_stmt = Var_decl err Cmpd_stmt Security_op call_decl do_fcntl Func_decl Do_fcntl Expr_stmt = Var_decl err Call_stmt Fcntl_setlk(fd) Func_decl Fcntl_setlk var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) cmpd_stmt Use filp
  • 32. AST and Control Flow (interprocedural) Func_decl Sys_fcntl var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) Expr_stmt = Var_decl err Cmpd_stmt Security_op call_decl do_fcntl Func_decl Do_fcntl Expr_stmt = Var_decl err Call_stmt Fcntl_setlk(fd) Func_decl Fcntl_setlk var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) cmpd_stmt Use filp
  • 33. AST and Def-Use Func_decl Sys_fcntl var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) Expr_stmt = Var_decl err Cmpd_stmt Security_op call_decl do_fcntl Func_decl Do_fcntl Expr_stmt = Var_decl err Call_stmt Fcntl_setlk(fd) Func_decl Fcntl_setlk var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) cmpd_stmt Use filp
  • 34. AST and Data Flow Func_decl Sys_fcntl var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) Expr_stmt = Var_decl err Cmpd_stmt Security_op call_decl do_fcntl Func_decl Do_fcntl Expr_stmt = Var_decl err Call_stmt Fcntl_setlk(fd) Func_decl Fcntl_setlk var_decl Struct file *filp Expr_stmt = Var_decl filp call_decl Fget(fd) cmpd_stmt Use filp
  • 35. Entity-Relationship model Func_decl Sys_fcntl Func_decl Do_fcntl Func_decl Fcntl_setlk Func_decl fcntl Struct_decl security_ops calls calls calls reads
  • 36.
    • KDM scenarios
  • 37. KDM as tool interchange format Tool 1 Tool 2 Tool 4 Tool 3
  • 38. KDM as tool interchange format Tool 1 Tool 2 Tool 4 Tool 3 KDM-compliant XMI
  • 39. Language-independent KDM repository Java extension extends C++ extension extends Cobol extension extends C++ extension extends Language-aware KDM Tool reads uses KDM Constraints are defined in Core KDM package: All language-specific extensions are uniform integrates Cobol KDM Tool 1 uses Cobol KDM Tool 2 uses C++ KDM Tool uses Java KDM Tool uses Transformation Tool Language-independent KDM Tool analyst modifies
  • 40. Where KDM adds value?
    • Architectural context for
      • Understanding software
      • Modularization, untangling “hairballs”
      • Discovering reusable components
      • Inventory, estimations of effort
      • Modernization
    • Architecture management
      • Before modernization
      • After modernization
    • Application Portfolio Management
    • Information exchange between vendors
  • 41. Modernization Scenarios Matrix XI. Reusable Software Assets / Component Reuse XII. Model-Driven Architecture Transformation X. Application Package Selection & Deployment IX. Data Warehouse Deployment VIII. Application & Data Architecture Consolidation VII. Data Architecture Migration VI. Services Oriented Architecture Transformation V. Non-Invasive Application Integration IV. Platform Migration III. Language-to-Language Conversion II. Application Improvement I. Application Portfolio Management Check Box Modernization Scenario
  • 42.
    • KDM status
  • 43. KDM status DSTC Joint submitters (2 nd revised submission published 3-04-2005): Supporters:
  • 44.
    • KDM packages
  • 45. How KDM is designed ?
    • KDM is partitioned into several models (packages)
    • Each package represents software artifacts as entities and relations
      • Code, Data and Action entities
      • Logical entities
      • Build entities
      • RunTime entities
      • Storage entities
      • UI entities
      • Conceptual entities
      • Scenario entities
      • Environment entities
    • Since KDM focuses on representing structures, most KDM entities are containers for other entities
    • KDM can represent multiple container hierarchies
    • Uniform mechanism of derived relations bottom-up through container hierarchies to address scalability of abstractions
  • 46. Structure of KDM packages Core SourceBundle Data Code Actions Logical RunTime UI Build Conceptual Scenario Environment SourceRef Storage
  • 47. System
    • System is a collection of various models
    • System is an entry point to various facets of knowledge
  • 48. Logical Model
    • LogicalModel describes components of existing software
    • It represents structural “elements”:
      • Package
      • Subsystem
      • Layer
      • LogicalGroup which allows composition
    • Module is the container for code, data and actions
    • Relationships between components are derived from Modules
  • 49. Conceptual Model
    • Concept is a set of CodeEntities
    • ConceptGroup allows composition
    • Relationships are derived from CodeEntities
  • 50. Scenario Model
    • Scenario is a directed graph of Actions
    • ScenarioGroup allows composition
    • Relationships are derived from Actions
  • 51. Environment Model
    • EnvironmentEntity represents “things” in the operational environment of the system
    • Relationships are derived from UI
  • 52. UI Model - main
    • UIEntity represents user interface “things”:
      • Display
      • Trigger
    • UIGroup allows composition
    • This model defines specific relations
  • 53. UI Model - layout
    • DisplayUnit represents “things” that can be displayed in a UI
    • Specific relations:
      • To Resource
      • To Data
  • 54. UI Model - relations
    • Specific UI relations:
      • From CallableUnit to Display
      • From one Display to another
      • From multiple displays to a single Layout
  • 55. UI Model - triggers
    • Triggers represent external events
    • Specific relations:
      • To Display
      • To CallableUnit
  • 56. Build Model - main
    • Build model represents physical “things”:
    • BuildGroup allows composition
    • BuildComponent contains Modules
    • Module is the container for code, data and actions
    • BuildComponent contains Files
    • This model defines specific relations
  • 57. Build Model – build relations
    • Specific build relations:
      • File generates file
      • File imports file
      • Files depends on file
      • SymbolicLink points to File
  • 58. RunTime Model
    • RunTime model represents dynamic “things”:
      • Applicaiton
      • Executable
      • Process
      • Thread
    • RunTime model also represents dynamic communication:
      • Communication object
      • Shared data
    • RunTimeEntity contains Modules
  • 59. RunTime model - Entities
    • LogicalGroup allows composition
    • Module is the container for code, data and actions
    • Relationships are derived from Data
    • This model defines some specific relations
  • 60.
    • Code, Data and Action – the source of derived relations
  • 61. Code package - main
    • Module is the container for code, data and actions
    • CodeGroup allows composition
  • 62. Code package – Code Entities
    • CodeEntities are implementation “things” in source files:
      • CallableUnit
      • ClassUnit
      • DataUnit
      • MacroUnit
      • DeclarationUnit
      • DataTypeUnit
    • This models defines some specific relations
  • 63. Code package – callable unit
    • CallableUnit contains LocalData and ParameterData
  • 64. Code package – class Unit
    • ClassUnit contains MethodData and MemberData
    • ClassUnit can subclass other ClassUnits
  • 65. Code package - declarations
    • DeclarationUnit defines some specific relations
  • 66. Code package - Macros
    • MacroUnit defines some specific relations
  • 67. Data package - main
    • DataModel defines data “things”
    • DataInterface is required to define actions on data, like read, write, update, etc.
    • DataGroup allows composition
  • 68. Data package – typing
    • Each DataUnit has relation to corresponding DataTypeUnit
  • 69. Data package – data types
    • DataModel defines some specific DataTypeUnits
  • 70. Data package – persistent data
    • Persistent data
  • 71. Action package – Action Entities
    • ActionEntity represents behavior “things”, like statements, features, business rules, etc.
    • ActionGroup allows composition
    • ActionEntities are endpoints for some specific relations
  • 72. Action package – action flow
    • There is ControlFlow relation between ActionEntities
  • 73. Action package – action relationships
    • ActionEntities are endpoints for some specific relations
  • 74. Action package – data relationships
    • ActionEntities are endpoints for some specific relations to Data via DataInterface
  • 75.
    • Core KDM package
  • 76. Core KDM package
    • Core package is used by all other KDM packages
    • Core package defines key KDM concepts and constraints
      • KDMEntity
      • KDMRelationship
      • KDMContainer
      • KDMModel
    • Core package defines KDM light-weight extension mechanism
      • Stereotype
      • TagValue
  • 77. Light-weight extension example
    • <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
    • <null:System xmi:version=&quot;2.0&quot; xmlns:xmi=&quot;http://www.omg.org/XMI&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:null=&quot;null&quot;>
    • <Executable name=&quot;AMilanProgram&quot; extension=&quot;//@stereotype.0&quot; >
    • <TaggedValue tag=&quot;reenterable&quot; value=&quot;false&quot;/>
    • </Executable>
    • <CallableUnit name=&quot;aFunc&quot; parent=&quot;//@Executable.0&quot;/>
    • <Data name=&quot;aLocalVar1&quot; extension=&quot;//@MetaEntity.11&quot; parent=&quot;//@CallableUnit.0&quot;
    • extension=&quot;//@stereotype.4&quot;/>
    • <Data name=&quot;aParam1&quot; kind=&quot;//@MetaEntity.12&quot; parent=&quot;//@CallableUnit.0&quot;
    • extension=&quot;//@stereotype.5&quot;/>
    • <Data name=&quot;aParam2&quot; kind=&quot;//@MetaEntity.12&quot; parent=&quot;//@CallableUnit.0&quot;
    • extension=&quot;//@stereotype.5&quot;/>
    • <DataType name=&quot;int&quot; kind=&quot;//@MetaEntity.8&quot; parent=&quot;//@Executable.0&quot;
    • extension=&quot;//@stereotype.2&quot;/>
    • <Data name=&quot;aVar&quot; kind=&quot;//@MetaEntity.7&quot; parent=&quot;//@Executable.0&quot;
    • extension=&quot;//@stereotype.1&quot;/>
    • <stereotype baseClass=&quot;Executable&quot; name=&quot;MilanProgram&quot; family=&quot;Milan&quot;>
    • <TaggedValue tag=&quot;reenterable&quot; type=&quot;Boolean&quot;/>
    • </stereotype>
    • <stereotype name=&quot;MilanVariable&quot; baseClass=&quot;Global&quot; family=&quot;Milan&quot; />
    • <stereotype name=&quot;MilanType&quot; baseClass=&quot;DataType&quot; family=&quot;Milan&quot;/>
    • <stereotype name=&quot;MilanFunction&quot; baseClass=&quot;CallableUnit&quot; family=&quot;Milan&quot;/>
    • <stereotype name=&quot;MilanLocal&quot; baseClass=&quot;LocalData&quot; family=&quot;Milan&quot;/>
    • <stereotype name=&quot;MilanParam&quot; baseClass=&quot;ParamData&quot; family=&quot;Milan&quot;/>
    • <stereotype name=&quot;UsesType&quot; baseClass=&quot;HasType&quot; family=&quot;Milan&quot;/>
    • </null:System>
  • 78.
    • Traceability
  • 79. SourceRef package
    • Build model represents physical “things”:
      • Package
      • Subsystem
      • Layer
    • LogicalGroup allows composition
    • Each logical entity defines an interface
    • Module is the container for code, data and actions
    • Relationships are derived
  • 80.
    • Derived Relations
  • 81. Composition principle
    • For any given “entity” type, one should be able to take a collection of entities and group them together into a typed container
    • Such containers represent more abstract entities and approximate entities used during analysis and design
    • Dealing with containers rather than individual entities helps reduce complexity of existing systems
    • One of the mechanisms supporting composition is abstraction of relations – this derives relations between containers from relations between contained entities
    • Containers and abstracted relationships maintain links to contained entities and relations
    • This allows refactoring of containers later by moving entities between containers and automatically recalculating derived relations between containers
  • 82. Derived relationships Container Diagram AB Derived relation between containers Derived relation between a container and its environment 100 15 3 number of relations from B to A 25 15 50 25 3 collection of represents Relation from B to A represents relations from B1, B3 and B4 to A 100=25+25+50 Container A Container B Container B1 Container B3 Container B2 Container B4 Container A Container C
  • 83. Questions ?!
  • 84. ASTM     11:00 – 11:50 Newcomb
    •   Abstract Syntax Tree Metamodel
    • - ASTM RFP Status         - ASTM Vision         - ASTM Business Significance         - ASTM Relationships with Other OMG stds         - ASTM Meta Model         - ASTM Related Technologies
  • 85. What is the status of the ASTM RFP?     Inconsistency corrected between 6.10 RFP Timetable and page 1 of the RFP Duration Event or Activity Actual Date   Preparation of RFP by TF 3 February 2005   RFP placed on OMG document server 3 February 2005   Approval of RFP by Architecture Board Review by TC 3 February 2005 0 TC votes to issue RFP 3 February 2005 60 LOI to submit to RFP due 3 April 2005 117 Initial Submissions due and placed on OMG document server (“Three week rule”) 30 May 2005 133 Voter registration closes 15 June 2005 139 141 Initial Submission presentations 21 June 2005   Preliminary evaluation by TF 23 June 2005 240 Revised Submissions due and placed on OMG document server (“Three week rule”) 14 November 2005 261 Revised Submission presentations December 2005   Final evaluation and selection by TF Recommendation to AB and TC December 2005   Approval by Architecture Board Review by TC December 2005 330 TC votes to recommend specification December 2005 360 BoD votes to adopt specification January 2006
  • 86. What is an Abstract Syntax Tree?
    • AN AST IS…
      • A formal representation of software syntactical structure of software
      • More amenable to formal analysis than concrete syntax or surface syntax ( the way the code looks )
      • A more precise formalism for detailed knowledge discovery than less formal knowledge collectors (e.g. scanners, tokenizers, visual inspection)
    • AN AST MAY …
      • Be an invertible representation that allows reconstruction of the “surface syntax” of the legacy system from the “abstract syntax” ( surface syntax  abstract syntax )
      • Be augmented with constraint analysis , data-flow analysis , control-flow analysis , axiomatic analysis and denotational analysis and other views (conceptual, scenario, interaction, collaboration, build, etc)
      • Be used to derive software engineering metrics and documentation
      • Be mapped or transformed into other abstract syntax models using rewrite rules .
      • Be queried and manipulated using query and model manipulation languages (such as OMG’s QVT™ and TSRI’s JTGEN™ and JRGen™)
    • An AST IS ALSO…
      • A well-formed MOF Model , Meta-Model or Meta-Meta-Model
  • 87. What are Language Theory ASTs?
    • In programming language parsing theory the Abstract Syntax of a programming language is distinct from the Abstract Syntax Tree of an application.
      • Abstract Syntax is a model consisting of the language constructs from which a language is composed.
      • Abstract Syntax Tree is a directed acyclic graph (DAG) consisting of instances of Abstract Syntax language constructs.
      • A well-formed BNF or EBNF (or grammar specification) is often used to define the Abstract Syntax of a programming language.
      • A parser generator is often used to generate a parser which generates the Abstract Syntax Tree by parsing an application in the language defined by the EBNF.
  • 88. What are Meta Object Facility (MOF) ASTs?
    • In the OMG Meta Object Facility (MOF) Abstract Syntaxes are nested meta-modeling levels.
      • M3 is the Abstract Syntax of M2 Abstract Syntax Trees
      • M2 is the Abstract Syntax of M1 Abstract Syntax Trees
      • M1 is the Abstract Syntax of M0 Abstract Syntax Trees.
    • MOF uses UML Class diagrams to define Abstract Syntax!
    • MOF platform independence comes from its use of generators that produce software for managing models that conform to meta-models.
      • Many perfectly acceptable MOF Abstract Syntax models would be considered malformed by many grammar specification constraint checkers.
      • Most well-formed Grammar specifications acceptable to compiler or parser generators should be MOF compatible.
  • 89. ADM Relationship to MOF AST model instances of source code of real application KDM Data models instance of data base or data files. Objects and data, I.e. instances of M1 model constructs Instances (examples) M0 AS Model of COBOL language. KDM Data Model Models consisting of instances of M2 metamodel constructs Model M1 KDM UML profiles GASTM UML profile SASMT UML profile Metamodels, consisting of instances of MOF constructs Metamodel M2 MOF Class, MOF Attribute, MOF Association, etc MOF, I.e. the set of constructs used to define metamodels Meta-metamodel M3 ADM Examples Description Layer
  • 90. Why Marry MOF and Parsing Technology ASTs
    • 1. Combining MOF and the Language Parsing Approaches to Abstract Syntax and ASTs is highly powerful!
      • Abstract Syntaxes defined for Language Parsers can usually be modeled as MOF Models using MOF Tools.
      • Once the MOF Models for language models exist, MOF has generators to create XML, Java, and CORBA API support for these models.
        • This allows the model instances (ASTs) of software application to be modeled and interchanged via MOF Repository technology.
        • This allows the exchange of AS (metadata) and ASTs (I.e enterprise applications treated as data) with full machine automation.
      • Without MOF, the manipulation of applications in Abstract Syntax form will remain proprietary with limited penetration.
      • With MOF, the manipulation of programs as data (ASTs) will become universal and many hard software problems will be solved efficiently and economically.
  • 91. How is the ASTM structured ?
    • 2. It extends MOF modeling to encompass several existing families of languages in a uniform way.
      • A generic set of language modeling elements common across numerous languages establishes a common core for language modeling, called the Generic Abstract Syntax Trees (GAST)
      • Language specific Specific Abstract Syntax Trees (SAST) for particular languages such as Ada, C, Fortran, Java, etc must be modeled in MOF or MOF compatible forms.
      • SAST  GAST must be demonstrated without loss of meaning even though their abstract syntax model change during transformation between languages.
    • Separation of concerns dictates the SASTM  GASTM separation.
      • ASTM reduces the O (S * T) transformation problem to an O(S+T+G), where S is the number of source languages (or models) and T is the number of target languages (or models) + G the GASTM (G).
  • 92. How does ASTM improve MDA?
    • It establishes a standard bottom-most language modeling level for many MDA tools to generate to and derive from.
    • It allows AST models to be sharable among multiple tools from different vendors accurately support analysis, visualization, re-factoring, target mapping and transformations.
    • Provides high levels of automation for tasks which are highly manual today, such as application rehosting, platform retargeting, legacy system replacement, database upgrade
    • It provides a GAST with sufficient precision and generality and fineness of granularity to allow its language modeling elements to be used as a common basis for application analysis, metrics, visualization translation, and refactoring.
  • 93. How does the ASTM support OMG standards?
    • The GAST will used to support other OMG modeling standards by providing a generic set of language modeling elements as the basis of OMG model (AST) derivation and as the basis for OMG language generation.
    • The GASTM is effectively an Ultra Wide Spectrum Intermediate Language Model which spans 2GLs, 3GLs, 4GLs and 5GL languages.
      • Existing OMG generators for MOF models are limited to Java or C++ for behavior support, and XML Schema and DTDs for structure support.
      • Retargeting OMG MOF generators into the GASTM will extend MDA support to a much broad spectrum of target languages than is currently supported by MOF technology.
    • Application Models and Meta-Models (AST and AS) Will Be …
      • sharable among multiple tools from different vendors with much more uniform support for analysis, visualization, re-factoring, target mapping and transformations across multiple languages.
  • 94. What is the ASTM Business Value?
    • Standardizing the format of AST structures, representation and interchange of AST models will …
      • Complement the KDM by completing a comprehensive model for the exchange of application models between application modernization tools.
      • Enable vendors to develop specialized modernization tools.
      • Insure that the aggregate of vendor tools provides a comprehensive modernization capability.
    • A standard KDM complemented by a standard ASTM will enable a user of the technology to bring together a variety of best-of-breed products to analyze, visualize, re-factor and transform legacy applications.
  • 95. ADM RFP Package Relationships Single Platform Independent View Multiple Platform Dependent Views RFP2: ASTM = GASTM + { SASTM } 0..n } } Structure RFP 1: KDM Composition Behavior Build Runtime } RFP5, RFP4, RFP3, RFP6, RFP7 Enterprise Logical UI Transformation Refactoring Metrics APPs Visualization GASTM Analysis SASTM Scenarios Core Data Source Conceptual Code System
  • 96. RFP1 + RFP2: KDM + ASTM Multiple Dimensional Single Platform Independent View + Multiple Platform Specific Views Single Platform Independent View Multiple Platform Specific Views 1 C++ COBOL FORTRAN PL/1 … 1 2GLs 3GLs 4GLs Python VisualBasic Java/J2EE Natural SQL BAL UYK20 SNX360 C BASIC Pascal … … Structure Composition Behavior Scenarios Logical Build Container Data Conceptual GASTM Structure Composition Behavior Scenarios Logical Build Container Data Conceptual SASTM Structure Composition Behavior Scenarios Logical Build Container Data Conceptual SASTM Structure Composition Behavior Scenarios Logical Build Container Data Conceptual SASTM Structure Composition Behavior Scenarios Logical Build Container Data Conceptual SASTM Structure Composition Behavior Structure Composition Behavior
  • 97. Model Driven Architecture ASTM = GASTM + SASTM Source (PSMPlatform Specific Model) Neutral (PIM) Platform Independent Model GASTM Target SASTM Source SASTM 3GL C++, Java, VB, J# Ada, C, COBOL, FORTRAN, Refine, Specware, DSL Natural, Power Builder Refine, Specware, DSL MSIL, JBC 4GL 5GL 2GL BAL, YUK C Generic Abstract Syntax Tree Specific Abstract Syntax Tree Specific Abstract Syntax Tree Target (PSM) Platform Specific Model
  • 98. Integration of the ASTM & KDM SASTM ASTM Program Subroutine Body System Statement Identifier Software GASTM Program Subroutine Body System Statement Identifier KDM Core Source DataTypes Code Data Actions RunTime Build UI Logical Scenario Conceptual System ROADMAP OTHER OMG STANDARDS Line Column File Directory Analysis Metrics Visualization Refactoring Mapping & Transformation UML AS CWM ITPM RAS MOF/QVT
  • 99. Generic Abstract Syntax Tree (GAST)
    • A GAST may be derived from:
      • Rewrite rules applied to a Specific Abstract Syntax Tree (SAST)
            • - OR -
      • Refinement rules applied to UML class diagrams
    • - OR -
  • 100. ASTM Transformation Cycle Solid arrows in the figure below shows a use of a GASTM with a COBOL to Java transformation example. Integrating the GASTM with the KDM will facilitate completing the dotted arrows and filling the gap.
  • 101. ASTM Scenario for 3GL to 4GL Transformation For Detailed Case Studies visit: www.legacysystemmodernization.com
  • 102. ASTM Scenario for 5GL to 4GL Transformation ! JRGEN is derived from Refine™
    • TSRI Tool Framework Employs Three 5GL Domain Specific Languages. During a TSRI Developer’s Daily Build :
      • JRGEN™ (TSRI’s Janus 5GL Wide Spectrum Language)
        • Transforms Refine 5GL Specifications into C++
      • JPGEN™ (TSRI’s 5GL Janus Parser Generator)
        • Transforms EBNF Specifications for 20 languages into Lexers, Parser, Printers in C++
      • JTGEN™ (TSRI’s 5GL Janus Transformation Generator)
        • Transforms 50 Transformation Rule Sets into C++
      • 175,000 lines of specification in three 5GL languages are transformed into 800,000 of C++ source in 10 minutes
      • Parallel compilation of the 100% generated C++ occurs on 20 2.4 Gz processors in 3 to 5 minutes
  • 103. ASTM Scenario for 3GL to 2GL Transformation Replatform applications in legacy languages by compiling from the GASTM directly to the .NET Framework: CTS, CLR, FCL, MSIL. Legacy Applications Assembler FORTRAN CMS-2 ADA C +Others COBOL JOVIAL 2GL GASTM Windows Common Language Runtime Common Type System .NET Framework 3GL GASTM MS Intermediate Language .NET Framework Class Library 2GL SASTM
  • 104. A Multi-Scenario Transformation ADM Framework TSRI Architecture Driven Modernization Framework For details visit: www.softwarerevolution.com Source (PSM) Platform Specific Model Neutral (PIM) Platform Independent Model GASTM Target SASTM Source SASTM 3GL C++, Java, VB, J# Ada, C, COBOL, FORTRAN, Refine, Specware, DSL Natural, Power Builder Refine, Specware, DSL MSIL, JBC 4GL 5GL 2GL BAL, YUK C Generic Abstract Syntax Tree Specific Abstract Syntax Tree Specific Abstract Syntax Tree Target (PSM) Platform Specific Model XI. Reusable Software Assets / Component Reuse XII. Model-Driven Architecture Transformation X. Application Package Selection & Deployment IX. Data Warehouse Deployment VIII. Application & Data Architecture Consolidation VII. Data Architecture Migration VI. Services Oriented Architecture Transformation V. Non-Invasive Application Integration IV. Platform Migration III. Language-to-Language Conversion II. Application Improvement I. Application Portfolio Management Check Box Modernization Scenarios
  • 105. What’s the Relationship of ASTM to Other OMG Specs? MOF 2.0 (ptc/04-10-15) Facilitates ASTM definition and exchange formats (XMI, etc.) Action Semantics as a part of UML 2.0 – superstructure 2.0 finalization (ptc/2003-08-02) The ASTM is concerned with syntax, while action semantics is concerned with one form of semantics. IT Portfolio Management (ptc/04-11-03) IT Portfolio Mgmt. establishes the universe of non-software aspects of the enterprise, whereas the AST defines the software assets of the enterprise. UML (ptc/03-08-02; ptc/03-09-15; ptc/03-10-14) A subsequent ADM roadmap RFP will support the derivation of UML models of software artifacts from the ASTM. CWM (formal/2003-03-02) The ASTM provides a language agnostic view of syntactical data declarations while the CWM data model does not. EAI (includes detailed metamodels for programming languages calls, including COBOL) (ptc/02-02-02) EAI is concerned with interfaces while the ASTM defines the syntactic structure of the software artifact. Reusable Asset Specification (RAS) (ptc/04-06-06) Reusable Asset Specification provides a way to define reusable asset packages for a domain of interest. The software asset modeled by an AST could be a RAS asset. ASTM could be used to populate information in a RAS asset. MOF/QVT model transformation (ad/2002-04-10) A subsequent ADM roadmap RFP will support the utilization of MOF/QVT for transformation of ASTM software artifacts.
  • 106. What are the ASTM 10 Mandatory Requirements? ( 1) Include a meta-model compatible current MOF. (2) Use UML to represent ASTM diagrams (3) Define a single unified terminology by complementing the KDM with a low-level detailed discovery model (4.1) Define a set of common concepts that exist in multiple languages (4.2) Define a set of language independent concepts, to be called the generic abstract syntax tree meta-model (GASTM). (5) Specify the means to specialize, differentiate or extend GASTM language independent concepts to represent language dependent constructs, to be called the specialized abstract syntax tree meta-model (SASTM).
  • 107. What are the ASTM Mandatory Requirements? (cont.) (6) Provide a list of the languages and platforms that the submitters ASTM proposal is claimed to support. (7) Demonstrate that it is possible to construct a mapping between languages and the ASTM. (8) Represent the original language constructs with sufficient precision to assure preservation of semantic equivalence. (9) Include information on how the ASTM relates to other non-OMG standards pertaining to abstract syntax trees. (10) Define programming constructs used to construct abstract syntax trees to a level of precision and with sufficient detail to allow the regeneration of the code (or surface syntax) from the model.
  • 108. What are the ASTM Evaluation Criteria? (1) Demonstrate the capability to map the existing software artifacts in a common implementation language, such as C, or C++ or Java or Ada or COBOL into a MOF repository that can be described by the proposed ASTM . (2) Demonstrate the ability of the proposed ASTM to support ASTs for programs in more than one implementation language. (3) Demonstrate the usability of the proposed ASTM for the purpose of representing information about the existing system. (4) Demonstrate the capability of the ASTM to represent a broad range of languages and language types including 2GL, 3GL, 4GL and 5GL languages such as Ada, Assembler, C, C#, COBOL, FORTRAN, Java, Natural, Power Builder, Refine, SQL, etc.
  • 109. OMG ADM Task Force Industry Participation http://adm.omg.org/