Diese Präsentation wurde erfolgreich gemeldet.

Guest Talk Vienna



Wird geladen in …3
1 von 66
1 von 66

Weitere Verwandte Inhalte

Guest Talk Vienna

  1. 1. Aspect-Oriented Modeling: Oxymoron or Pleonasm? Jean Bézivin Université de Nantes Faculté des Sciences et Techniques 2, rue de la Houssinière BP 92208 44322 Nantes cedex 3, France Jean.Bezivin@sciences.univ-nantes.fr Guest talk given at AOPDCD'2002, Vienna, July 2nd 2002
  2. 2. AOPDCD'2002, Vienna, July 2nd 2002 Conditions for a Possible Synergy? AOSD MDA [Aspect-Oriented Modeling?]
  3. 3. AOPDCD'2002, Vienna, July 2nd 2002 Main point of the presentation Objects everywhere  How will model engineering help capturing aspect management in software development?  How this could fit in the OMG MDA initiative?  Which kind of aspects could be captured by separate models?  Which kind of operations (separation, weaving, etc.) could be defined on models  How may these different concerns, represented by coordinated non executable abstract models, be operationalized (i.e. mapped on equivalent executable models) Models
  4. 4. AOPDCD'2002, Vienna, July 2nd 2002 Agenda A point of vocabulary Paradigm evolution : from objects & components to models What is the MDA? Models as an explicit specification of aspects Conclusions: AOSP vs MDA/MDE
  5. 5. AOPDCD'2002, Vienna, July 2nd 2002 Oxymoron A rhetorical figure in which an epigrammatic effect is created by the conjunction of incongruous or contradictory terms A rhetorical figure in which incongruous or contradictory terms are combined, as in a deafening silence and a mournful optimist. The American Heritage® Dictionary of the English Language, Fourth Edition A figure in which an epithet of a contrary signification is added to a word - e. g., cruel kindness - laborious idleness. Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc. n : conjoining contradictory terms (as in 'deafening silence') WordNet ® 1.6, © 1997 Princeton University
  6. 6. AOPDCD'2002, Vienna, July 2nd 2002 Oxymora active waiting - acute dullness - Advanced BASIC - almost exactly - alone together - clearly ambiguous - clearly confused - clearly misunderstood - conciliation court - constant variable - dangerously safe - deafening silence - definite maybe - diet ice cream - even odds - exact estimate - extensive briefing - extinct life - fish farm - flexible ethics - found missing - fresh-frozen - friendly fire - genuine imitation - good shit - hells angels - holy war - home office - idiot savant - industrial park - intense apathy - jumbo shrimp - linear curve - liquid gas - little giants - living dead - long sleeved t-shirt - minor crisis - new classic - non- alcoholic wine - non-dairy creamer - non-working mother - old news - only choice - open secret - original copies - paid volunteer - passive aggression - peace offensive - plastic glasses - plastic silverware - pretty ugly - randomly organized - real potential - resident alien - sad clown - scheduled spontaneity - seriously funny - silent scream - sweet sorrow - synthetic natural gas - temporary tax increase - tragic comedy - uncrowned king - vaguely aware - virtual reality - working vacation - etc.
  7. 7. AOPDCD'2002, Vienna, July 2nd 2002 Pleonasms  Pleonasms are the opposites (antonyms) of oxymora. A pleonasm consists of several concepts (usually several words) that are redundant, e.g. "at this moment in time." (presumably these five words mean "now.")  pleonasm PLEE-uh-naz-uhm, noun: 1. The use of more words than are necessary to express an idea - as, "I saw it with my own eyes." 2. An instance or example of pleonasm. 3. A superfluous word or expression.  from Latin pleonasmus, Greek pleonasmós ('more-ness') excess, redundancy]. A traditional term for the use of more words than necessary, either for effect or more usually as a fault of style, and any instance of that use, as in: Could you repeat that again? rather than Could you say that again? or Could you repeat that? - They both got one each rather than They both got one or They got one each - That's a more superior product (superior already denotes 'more') - It's a really new innovation (an innovation is already new). Some common pleonasms attract little comment, such as free gift (gifts are by definition free) and plans for the future (plans cannot be about the present or past).  The Oxford Companion to the English Language, © Tom McArthur 1992
  8. 8. AOPDCD'2002, Vienna, July 2nd 2002 Pleonasms  absolutely essential - a cappella without music - advance warning - affirmative yes - A.M. in the morning - attach together - autobiography of my life - bad evil - classic tradition - classify into groups - climb up - close proximity - cold ice - collaborate together - combined together - dark night - DOS operating system - empty hole - foreign imports - frozen ice - grateful thanks - handwritten manuscript - hot fire - imminent at any moment - individual person - invited guests - join together - joint collaboration - joint cooperation - knowledgeable experts - little baby - long litany - major breakthrough - malignant cancer - may possibly - mental thought - merge together - mutual cooperation - near proximity - new discovery - new innovations - new neophyte - new recruit - nostalgia for the past - old senior citizens - oral conversation - original founder - original source - pair of twins - past history - positive yes - postponed until later - potentially capable - repeat again - round circle - specific examples - top priority - unexpected surprise - wordy and verbose - youthful teenagers
  9. 9. AOPDCD'2002, Vienna, July 2nd 2002 Paradigm evolution  OT (Object Technology) has got to answer many difficult problems since its initial industrial discovery in the 80's.  Generally OT did not succeed very well in finding good internal solutions to these challenges.  As a consequence, the proposed solutions are often ad-hoc, informal, and even baroque. They are are difficult to generalize and hard to combine. They often don't scale up. Object Technology Use cases Aspects Patterns etc.
  10. 10. AOPDCD'2002, Vienna, July 2nd 2002 Paradigm evolution  MT (Model Technology) seems to be in a position to meet some of these challenges to which OT was not able to find an internal solution.  Among these we may quote:  Aspect separation  Homogeneous handling of functional and non-functional attributes  Integration of different paradigms (rules, services, processes, architecture, etc.)  MT seems able to subsume OT and to offer a realistic migration path from present object and component solutions to more ambitious regular and scalable organizations. OT Use cases Aspects Patterns etc. MT QoS Rules Processes Applications Services
  11. 11. AOPDCD'2002, Vienna, July 2nd 2002 MDA: The new OMG vision OMG is in the ideal position to provide the model-based standards that are necessary to extend integration beyond the middleware approach…Now is the time to put this plan into effect. Now is the time for the Model Driven Architecture. Richard Soley and the OMG staff, MDA Whitepaper Draft 3.2 November 27, 2000
  12. 12. AOPDCD'2002, Vienna, July 2nd 2002 The next steps CORBA was a powerful first step, but we have more steps to take. Fred Waskiewicz, OMG Director of Standards
  13. 13. AOPDCD'2002, Vienna, July 2nd 2002 Angry end-users We don't want anymore to pay such a high price for simply moving our information system to a new middleware platform (COM, CORBA, Java, HTML, XML, DotNet, etc.) when our business system stays stable. We are prepared to pay a last price for building the abstract models of our business and services that will guarantee us against technological obsolescence. From there, any platform provider will also have to provide the mapping solutions from standard business models before we buy.
  14. 14. AOPDCD'2002, Vienna, July 2nd 2002 The sequence has no end It's difficult - - in fact, next to impossible - -for a large enterprise to standardize on a single middleware platform. Some enterprises found themselves with more than one because their different departments have different requirements, others because mergers or acquisitions created a mix. Even the lucky enterprise with a single middleware choice still has to use other technologies to interoperate with other enterprises and B2B markets. The middleware environments that are most visible today are CORBA, Enterprise JavaBeans, messageoriented middleware, XML/SOAP, COM+ and .NET. However, over the past decade or so, the middleware landscape has continually shifted. For years we've assumed that a clear winner will emerge and stabilize this state of flux, but it's time to admit what we've all suspected: The sequence has no end! And, in spite of the advantages (sometimes real, sometimes imagined) of the latest middleware platform, migration is expensive and disruptive. (We know an industry standards group that, having migrated their standard infrastructure twice already, is now moving from their latest platform du jour to XML.) from Richard Soley and the OMG staff, MDA Whitepaper Draft 3.2, November 27, 2000
  15. 15. AOPDCD'2002, Vienna, July 2nd 2002 The middleware war is over COM+ DCOM CORBA IIOP Microsoft C# & DotNet XML SOAP Sun's Java EJB HTTP HTM L  There is no clear winner nor loser  The next battlefield will be model transformation  The OMG's Model Driven Architecture (MDA) initiative is aimed at using modeling and meta- modeling to drive the design and implementation of distributed systems. + the next wonderful Middleware platform (~2005) Sun's reaction to C# & DotNet ?
  16. 16. AOPDCD'2002, Vienna, July 2nd 2002 Mapping to multiple and evolutive platforms COM+ DCOM CORBA C# DotNet XML SOAP Java EJB HTTP HTM L  MOF along with UML is a core technology for MDA.  Technology neutral models of systems can be mapped to implementations that use a variety of middleware technologies (easy to say, more difficult to implement) UML and MOF compliant platform independent models
  17. 17. AOPDCD'2002, Vienna, July 2nd 2002 Various platforms CORBA Java/EJB C#/DotNet Web/XML/SOAP PIM etc. Platform-Independent ModelMulti-target code generation + SVG, GML, Delphi, etc.
  18. 18. AOPDCD'2002, Vienna, July 2nd 2002 Manual/Automatic code generation 0% 100% MM Business model Design model Code model MM MM
  19. 19. AOPDCD'2002, Vienna, July 2nd 2002 MDA: PIMs and PSMs MDA models  PIM: Platform Independent Models Formal specification of a system that abstracts away technical detail Example: Billing system expressed in UML  Platform Description Models (PDMs) e.g. of component constructs (CCM), of Eiffel, C#, EJB, …  PSM: Platform Specific Models Expressed in terms of the specification model of the platform Example: Billing system expressed in "UML profile for CORBA"
  20. 20. AOPDCD'2002, Vienna, July 2nd 2002 Basic MDE operations PIM PSM Code 4 2 5 3 1  OMG standards are specified in terms of a PIM and normally one or more PSMs, all in UML or UML profiles or based on any other kind of MOF meta-model.  The MDA defines consistent relationships across these models.  It makes it easier to produce implementations on different platforms while conforming to the same essential and precise structure and behavior of the system. As a consequence, the business model may define business goals and policies in a computation independent manner.
  21. 21. AOPDCD'2002, Vienna, July 2nd 2002 Some of the OMG successes 1. CORBA 2. IDL 3. IIOP 4. UML 5. MOF 6. XMI 7. CWM 8. SPEM yesterday today tomorrow OMA MDA ?
  22. 22. AOPDCD'2002, Vienna, July 2nd 2002 UML 2.0 : not a language, but a family of languages  UML 2.0 Infrastructure RFP - - A UML 2.0 RFP issued September 15, 2000 that is primarily concerned with architectural alignment, restructuring and extension mechanisms.  UML 2.0 Superstructure RFP - - A UML 2.0 RFP issued September 15, 2000 that is primarily concerned with the refinement and extension of UML 1.x semantics and notation.  UML 2.0 OCL RFP - - A UML 2.0 RFP issued September 15, 2000 that is primarily concerned with with defining an OCL metamodel.  UML 2.0 Diagram Interchange RFP - - A UML 2.0 RFP issued March 2, 2001 that is primarily concerned with defining a metamodel for diagram interchange using the XMI facility. from "Will UML 2.0 Be Agile or Awkward?" by Cris Kobryn Main concern is the separation of concerns
  23. 23. AOPDCD'2002, Vienna, July 2nd 2002 UML opened the road, several roads indeed... UML/MOF OMT Merise SA/RT ERD SADT DFD etc. Product and Process models + Model Driven Engineering JSD From Object-Oriented Programming to Model-Driven Software Engineering.
  24. 24. AOPDCD'2002, Vienna, July 2nd 2002 The initial roadmap: separation of artifact and process aspects Procedural ADM OOADM e.g. OMT UML UPM SPEM >2001 07/200111/1997 Network of models + profiles + other MMs + specific processes (RUP, IBM SI, etc.) Method = notation + process + tools Model weaving Unified Method: impossible
  25. 25. AOPDCD'2002, Vienna, July 2nd 2002 Models Everywhere Business modelBusiness processes Business rules Workflow model Test model User model Cost model Development process model Design model Class model Object model Dynamic model UseCase model Interaction model Resource model Agent model etc. Performance model Business objects
  26. 26. AOPDCD'2002, Vienna, July 2nd 2002 The software life cycle is populated with a lot of models  The development software cycle is populated with models  Models are of unequal importance  The model space is structured (composite and atomic models)  Models are related in a complex network of production/consumption separation/weaving, transformation, etc.  The content of each model is defined (constrained) by a corresponding meta- model (ontology)  The model space is constantly broadening starting from the essential models (Domain, Service, Resource)  All models are not of equal importance Requirement model Business Object model Workflow model Business rules model Business process model Design model Deployment model Test model Performance model QoS model Execution model etc. 1 aspect = 1 model
  27. 27. AOPDCD'2002, Vienna, July 2nd 2002 Each model has different characteristics  A Smalltalk coding model only offers single inheritance, but also explicit anonymous metaclasses.  An Eiffel coding model has a different form of inheritance and several extensions (contracts, etc.). It has also specific "client" relations between classes.  A Java (or C#) coding model has two notions of inheritance, corresponding to the class and interface categories.  A C# coding model allows cross-language inheritance  A workflow model is built from basic tasks.  A usage model contains the concepts of actors, use-cases and several relations like specialization of use-cases.  etc.
  28. 28. AOPDCD'2002, Vienna, July 2nd 2002 From contemplative to productive +Applicant() +ApplicantInfo() +MakeApplication() -companyName : CString -experience : CString -reference1 : CString -reference2 : CString -reference3 : CString Applicant +Person() +PersonInfo() -personID : unsigned long -surname : CString -givenName : CString -middleInitial : char -streetAddress : CString -postCode : CString -countryname : CString -eMailAddress : CString Person -is taught by 1 -teaches 0..* +CourseSession() +CourseSessionInfo() -courseSessionID : unsigned long -courseDate : unsigned long -courseID : unsigned long -courseLocation : CString CourseSession +AppStatus() +AppStatusInfo() -statusCode : char -statusName : CString AppStatus +CourseRegistration() +CourseRegistrationInfo() -registrationDate : unsigned long -completionFlag : bool -confirmedDate : unsigned long CourseRegistration +Test() +TestInfo() -testScore : unsigned long Test +Application() +ApplicationInfo() -productNr : unsigned long -certificationLevel : unsigned long -applicationDate : unsigned long Application +PermittedStatusChange() +StatusChangeInfo() -fromStatus : char -toStatus : char PermittedStatusChange +ExamSession() +ExamSessionInfo() -examSession : unsigned long -examlocation : CString -examDate : unsigned long ExamSession -gives0..* -is achieved1 -is made by 1 -makes 0..* -allows change in 0..* -has a 1..* -is taken by1 -takes0..* -is made by a1 -made a1..* -is in1 -is filled by0..* -uses 1 -is used in 0..* -applies to a0..* -is for a1 +Exam() +ExamInfo() -examID : unsigned long -certificationLevel : unsigned long Exam +Employee() +GetCurrentAge() +EmployeeInfo() -jobType : CString -roomNr : unsigned long -department : CString -division : CString -jobTitle : CString -manager : unsigned long -headsDept : CString -headsDivision : CString -mobileNr : CString -birthDate : unsigned long Employee +registrationform() RegistrationForm -uses* * ApplicantApplicantList PersonList findApplicant() ApplicationRegForm Applicant() findPerson() addPerson() addApplication() Application() MakeApplication() ApplicationList class sequence Java code "from human-readable to computer-understandable"
  29. 29. AOPDCD'2002, Vienna, July 2nd 2002 Compare code-centric and model-centric approaches OMA MDA IDL  UML+OCL
  30. 30. AOPDCD'2002, Vienna, July 2nd 2002 Fragments of a UML meta-model UML not 1.4
  31. 31. AOPDCD'2002, Vienna, July 2nd 2002 Three stages in the evolution of modeling techniques at OMG. UML MOF UMLaModel aModel MOF UML UML_FBO aModel PWG Workflow etc. Common Warehouse Metadata Interchange Action language (a) (b) (c)
  32. 32. AOPDCD'2002, Vienna, July 2nd 2002 OMG : the software bus and the knowledge bus. Cobol CORBA, IDL, IIOP,... Java Workflow MOF, UML, XML,... UML UPM CWM C#
  33. 33. AOPDCD'2002, Vienna, July 2nd 2002 Systems and models A model M is a simplified representation of the world, as a matter of fact of only a part S of the world called the system. M S isRepresentedBy M0 (the world) M1 (the modeling space)
  34. 34. AOPDCD'2002, Vienna, July 2nd 2002 Aspect-Oriented Modeling Obviously a given system may have plenty of different models. Each model represents a given aspect of the system. Ma S isRepresentedBy M0 M1 Mb Mc
  35. 35. AOPDCD'2002, Vienna, July 2nd 2002 Limited Substitutability Principle  The purpose of a model is always to be able to answer some questions in place of the system, exactly in the same way the system itself would have answered similar questions.  A model represents certain specific aspects of a system and only these aspects.  But how to make this assumption explicit, automatically checkable, etc?
  36. 36. AOPDCD'2002, Vienna, July 2nd 2002 Various kinds of models  Products and processes  Legacy and components  Static and dynamic  Functional and non-functional aspects  etc.
  37. 37. AOPDCD'2002, Vienna, July 2nd 2002 Systems and models What is exactly this relation? Can we specify this "aspect selection" with precision? How to combine several such relations? How to characterize them? M S isRepresentedBy M0 (the world) M1 (the modeling space)
  38. 38. AOPDCD'2002, Vienna, July 2nd 2002 Solution: Metamodel S M* M The correspondence between a model and a system is explicitly and precisely defined by a metamodel. sem
  39. 39. AOPDCD'2002, Vienna, July 2nd 2002 Ontologies and metamodels For the theorician, this is an ontology For the IS practitioner, this is a metamodel A metamodel is a simple form of an ontology M S isRepresentedBy M0 (the world) M1 (the modeling space)
  40. 40. AOPDCD'2002, Vienna, July 2nd 2002 Ontology: definition Gruber, T.G. A Translation Approach to Portable Ontology Specifications Knowledge Acquisition, V.5, N.2, (1993) "A body of formally represented knowledge is based on a conceptualization: the objects, concepts, and other entities that are presumed to exist in some area of interest and the relationships that holds them. A conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose. An ontology is an explicit specification of a conceptualization. The term is borrowed from philosophy, where an ontology is a systematic account of Existence. For knowledge-based systems, what "exists" is exactly that which can be represented. When the knowledge of a domain is represented in a declarative formalism, the set of objects that can be represented is called the universe of discourse. This set of objects, and the describable relationships among them, are reflected in the representational vocabulary with which a knowledge-based program represents knowledge. Thus, we can define the ontology of a program by defining a set of representational terms. In such an ontology, definitions associate the names of entities in the universe of discourse (e.g. classes, relations, functions or other objects) with human-readable text describing what the names are meant to denote ..."
  41. 41. AOPDCD'2002, Vienna, July 2nd 2002 Meta-models and ontologies  Ontologies bring: Abstraction Consensus and sharing
  42. 42. AOPDCD'2002, Vienna, July 2nd 2002 Ontologies Normative consensus Consensual norms Because sometimes: there are non-normative consensus there are non-consensual norms
  43. 43. AOPDCD'2002, Vienna, July 2nd 2002 Layered ontologies terminological Concepts and Relations e.g. UML diagrams e.g. OCL statementse.g. How to draw a class? presentation issues, etc.
  44. 44. AOPDCD'2002, Vienna, July 2nd 2002 Egyptian architecture metamodel model "the real world" metameta model The MOF (some kind of "top level ontology") The UML metamodel and other MMs Some UML Models and other Ms Various usages of these models M0 M1 M2 M3 [Inspired by IRDS, CDIF, etc.]
  45. 45. AOPDCD'2002, Vienna, July 2nd 2002 MOF : some definitions  The MOF is unique and self- defined.  In principle, the MOF should be minimal.  The MOF factorize all that is common to all meta- models, e.g.:  Generating towards a given middleware (.Net, Corba, Java, etc)  Transporting models and metamodels  Persistent support for models and metamodels (repository) domain-specific domain-independant
  46. 46. AOPDCD'2002, Vienna, July 2nd 2002 Multiple meta-models MOF::Class UML::Class UML::Participant Peter Smith Java::Class Java::Participant Peter Smith
  47. 47. AOPDCD'2002, Vienna, July 2nd 2002 The Three Modeling Layers the MOF MMM the UML MM a UML model m a particular use of m the SPEM MM the CCM MM another UML model m’ another use of m Level M3 Level M2 Level M1 Level M0
  48. 48. AOPDCD'2002, Vienna, July 2nd 2002 The OMG/MOF Meta-Model Stack Université de NANTES M1, M2 & M3 spaces M3 M2 M1 M2 M1 M2 M1 M1M1 - One unique Metametamodel (the MOF) - An important library of compatible Metamodels - Each of the models is defined in the language of its unique metamodel
  49. 49. AOPDCD'2002, Vienna, July 2nd 2002 Direct relations between MMs MOF UML MM CWM MMUSES C2 C2 CWM Model C2 Drawing the global picture
  50. 50. AOPDCD'2002, Vienna, July 2nd 2002 UML profiles  A UML profile is a grouping construct for UML model elements that have been customized for a specific domain or purpose using extension mechanisms such as stereotypes, tagged values and constraints. For example, the UML Profile for CORBA RFP customizes UML for specifying CORBA IDL.  A metamodel defines a domain-specific language. A profile is a variant of a metamodel. It allows to define a dialect of a given language. There are a dozen of UML profiles that are currently being defined.
  51. 51. AOPDCD'2002, Vienna, July 2nd 2002 Abstract Syntax Systems Compared MOF The UML meta-Model A Specific UML Model A Specific phenomenon corresponding to a UML Model EBNF Pascal Language Grammar A specific Pascal Program A specific execution of a Pascal program A XML document A XML DTD Or Schema A XML document A XML DTD or Schema Technology #2 (MOF + OCL) Technology #3 (XML Meta-Language) M3 M2 M1 KIF Theories Upper Level Ontologies Technology #4 (Ontology engineering) [XMI=MOF+XML+OCL] Model serialisation Technology #1 (formal grammars attribute grammars, etc.) +Description Logics +Conceptual Graphs +etc. +Xpath, XSLT +RDF, OIL, DAML +etc. :from contemplative to productive.
  52. 52. AOPDCD'2002, Vienna, July 2nd 2002 Some technical spaces model mm UML/MOF program grammar Java document schema XML DBMS SQL etc KBMS
  53. 53. AOPDCD'2002, Vienna, July 2nd 2002 Ex: Weaving geographical and political aspects in XML <gml:location> <gml:Point> <gml:coord> <gml:X>1.0</gml:X> <gml:Y>1.0</gml:Y> </gml:coord> </gml:Point> </gml:location> <gml:Polygon gid="810"> <gml:outerBounderyIs> <gml:LinearRing> <gml:coordinates>0.0,0.0 100.0,0.0 50.0,100.0 0.0,0.0</gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> <Bureaudevote> <num>810</num> <NbInscrits>870</NbInscrits> <NbVotants>507</NbVotants> <Ayrault%>70.72</Ayrault%> <Harousseau%>20.44</Harousseau%> </Bureaudevote> Geographical map + political results per voting area = political map
  54. 54. AOPDCD'2002, Vienna, July 2nd 2002 Model weaving  XML technology offers tools for document merging (Xlink, Xpointer, etc.)  It is also possible to perform the weaving operation within the model space and then to project to the XML space (SVG, GML, etc.)
  55. 55. AOPDCD'2002, Vienna, July 2nd 2002 T/xslt Ex: Crossing the MOF to XML boundary Ma/xmi Ma Mb/xmi Mb Abstract model space. Concrete model space (XML supported) T
  56. 56. AOPDCD'2002, Vienna, July 2nd 2002 Various kinds of transformations Ma Mb MMab Endogeneous transformation sem sem Ma Mb MMa Exogeneous transformation sem sem MMa Tab Tab
  57. 57. AOPDCD'2002, Vienna, July 2nd 2002 Tooling the MDA : Sample  Adaptive's Framework http://www.adaptive.com/  France-Telecom Universalis http://universalis.elibel.tm.fr/  Codagen Gen-it http://www.codagen.com/  Codigo CodigoXpress http://www.codigoxpress.com/  DSTC dMOF http://www.dstc.edu.au/Products/CORBA/MOF/  Interactive Objects ArcStyler http://www.io-software.com/  Kabira Business Accelerator http://www.kabira.com/  Kennedy Carter iUML and iCCG http://www.kc.com/  Metamatrix MetaBase http://metamatrix.com/  NetBeans Meta Data Repository MDR http://www.netbeans.org/  ONTOS ObjectSpark http://www.objectspark.com/  ObjectRad Java Metadata Server http://www.objectrad.com/  ObjeXion Software Netsilon http://www.netsilon.com/  Project Technology BridgePoint/DesignPoint http://www.projtech.com/  Secant Technologies ModelMethods http://www.modelmethods.com/  Soft-Maint Scriptor & Semantor http://www.sodifrance.fr/  Tata Research Development ADEX http://www.tcs.com/  University of Berne MOOSE http://www.iam.unibe.ch/ and much more…
  58. 58. AOPDCD'2002, Vienna, July 2nd 2002 Part of the C#/DotNet MetaModel Field Constructor Property isReadable : Boolean isWritable : Boolean Member name : String Assembly name : String Method TypedAttribute MethodBase visibility: String isAbstract : Boolean isFinal : Boolean isStatic : Boolean Type qualifiedName : String isAbstract : Boolean visibility: String isSealed : Boolean namespace : String 0..1 0..* owner 0..1 members 0..* 0..* 0..1 content 0..* container 0..1 0..1 0..* super 0..1 type 0..* 0..1 0..* returnType 0..1 0..* 1 0..* type 1 0..* Parameter isIn : Boolean isOut : Boolean name : String position : Integer 0..* 1 parameters 0..* method 1 1 0..* type 1 0..*
  59. 59. AOPDCD'2002, Vienna, July 2nd 2002 The Ycycle : weaving PIMs & PDMs to produce PSMs PIMs (Platform Independent Models) PSMs (Platform Specific Models) M Merging/binding phase PDMs (Platform Description Models) ? binding
  60. 60. AOPDCD'2002, Vienna, July 2nd 2002 MDA: beyond the buzzword  Modern model engineering techniques are ready for prime time in software engineering.They are based on:  A four level architecture (3+1)  A unique metametamodel (MOF),  with transfer and exchange mechanisms  with transformation mechanisms  with standard projection mechanisms on a variety of middlewares (CORBA first, Java and DotNet next, …)  A growing collection of specialized meta-models (evolutive)  Object metamodels (Java/EJB/J2EE, CLR, CCM, etc.)  Legacy metamodels (Relational, CWM)  Enterprise metamodels : Business objects, Healthcare, Transportation, Process & Rules, and much more  Product an process metamodels (e.g. workflow, RUP)  Automatic and semi-automatic generation tools, from high abstraction standardized models to various middleware platforms will progressively appear in the coming years.
  61. 61. AOPDCD'2002, Vienna, July 2nd 2002 Conclusion Model engineering is the future of object technology  As object and classes were seen in the 80's as "first class entities", with libraries of several hundred of classes hierarchically organized, models and metamodels are beginning to be considered alike in the 2000's.  Libraries (lattices) of hundreds of metamodels (ontologies) of high abstraction and low granularity are beginning to appear. Each such metamodel may contains several hundreds of concepts and relations.  Tools will be needed to work with these vast libraries of models and metamodels.  This will have a rapid impact on the daily work of the information engineer.  More research is urgently needed to bring together the people involved in the theory and practice of model engineering (ontologists, methodologists, software practitioners, information system builders, database specialists, etc.).
  62. 62. AOPDCD'2002, Vienna, July 2nd 2002 AOP: the code as unique reference Debugging directives Optimisation directives Synchronization Exceptions Executable code Algorithms Organization code (#include, etc.) preconditions postconditions
  63. 63. AOPDCD'2002, Vienna, July 2nd 2002 The on-line separate models organization (aspect-oriented software engineering) Common BUS (e.g. CORBA or DotNet + UML + MOF + XMI) Execution model Architecture model Deployment model Domain model Design model Test model Usage model (Use Cases) Resource model First-class independent models and metamodels
  64. 64. AOPDCD'2002, Vienna, July 2nd 2002 Where are models coming from?  Essential models (resource, business logic, service)  Other development sources (exception handling, testing, user behaviour, enforcing contracts, performance improvement, deployment, security, authentification, concurrency management, etc.),  Legacy systems,  Derived models,  Executable code extraction (code is a model)  Multiple other sources, like Just in Time Model Production  etc.
  65. 65. AOPDCD'2002, Vienna, July 2nd 2002 Combining the power of meta- modeling and metaprogramming a C# program execution a C# meta-model a C# model read XMI write XMI [This may be the ultimate strategy for modern software maintenance] sem Introspection at workThis is a dynamic model.
  66. 66. AOPDCD'2002, Vienna, July 2nd 2002 AOM: oxymoron or pleonasm?  The central issue in AOSD is knowledge management (aspects + operations)  AOP gives a key role to the code (executable code) for this representation problem.  As a consequence the problem of final mapping to executable code is solved  But the problem of precise definition, capture and maintenance of the various aspects is made more difficult  On the contrary, MDA/MDE starts from the a priori of an independent and homogeneous representation of aspects in non-executable "external spaces"  The conceptual handling of separate aspects and operations on these aspects is considerably simplified  The practical handling of mapping to executable platforms (operationalization) still requires considerable research and development efforts that will go much beyond compiler technology and rewriting systems.  From the point of view of representation systems, AOM is an oxymoron  From the point of view of the problem to be solved (separation of concerns), AOM is a pleonasm.  There seems to be more place for cooperation than competition between both approaches.