1 / 50

Introducing Asset Oriented Modeling and KLEEN

bdaum industrial communications What is AOM? Advantages of AOM The KLEEN modeler Current status and outlook. Introducing Asset Oriented Modeling and KLEEN. Asset Oriented Modeling. Rationale Concepts that differentiate AOM from ERM Higher order relationships

meadow
Download Presentation

Introducing Asset Oriented Modeling and KLEEN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. bdaum industrial communications What is AOM? Advantages of AOM The KLEEN modeler Current status and outlook Introducing Asset Oriented Modeling and KLEEN

  2. Asset Oriented Modeling • Rationale • Concepts that differentiate AOM from ERM • Higher order relationships • Regular sets and regular grammars • Keys • Inheritance • Pluggable Model Components • Namespaces • Summary

  3. Rationale • Entity-Relationship Modeling is too clumsy for todays complex data models (XML, SQL1999). There is always a design dilemma (what is an entity, what a relationship). • UML leans towards a specific data model (object-oriented) and is far too complex for conceptual modeling. Okay for OO-implementation models but lacks essential concepts (keys) for database modeling.

  4. Binary relationships • Binary relationships are the most common type of relationship. orders Customer Product

  5. N-ary relationships • Generally n-ary relationships cannot be replaced by binary relationships. Tutor teaches Student Course

  6. Unary relationships • Unary relationships are usually used to describe a containment. Order Orderline

  7. 0-ary relationships • 0-ary relationship = entity Order

  8. Assets • Assets are generalized relationships • They serve as both entity and relationship

  9. Arcs and Clusters • Arcs provide the necessary connectors for relationship assets. Clusters describe alternatives

  10. Level 2 Structures • L2S may be used to group assets • L2S act only as named boundaries • Much weaker construct than assets • Each L2S is identified by a mandatory identifying asset.

  11. Applying AOM Real World AOM Model Scenario L2S Business Object Asset asset

  12. AOM Container Hierarchy • Models may include other models • Level2 containers may be nested • Assets cannot be nested • Properties may be nested Model Level2 Asset Property

  13. The model

  14. Grammars • Assets, clusters and arcs constitute a grammar • Asset names act as non-terminal symbols • Asset labels act as terminal symbols and determine the names of asset instances

  15. Abstract Assets • Assets without label have instances with the same name as the asset. • Assets with grayed-out labels are abstract and don't have instances. • Abstract assets are typically used for type declarations or as super-assets.

  16. Properties • Repetitionsaccount*, phone-no[1..4], address+ • Properties can be nested: name(first,middle?,last)‏ • Sequences, bags, alternativesmeeting(time&location)order(product|service)‏ • Recursionslabel{part(id,description,label*)}

  17. Properties vs. Assets • Assets are first class citizens • Assets may specify a namespace – properties not • Assets may specify keys – properties not • Assets may specify operations – properties not

  18. Keys • Each asset may have one or several primary keys. Keys may be named. • Each key is constituted from one or several key fields. • Simple key fields refer to asset properties. Delegated key fields refer to key names in related assets.

  19. Inheritance • Assets may inherit features (properties, keys, constraints, operations, annotations) from other assets.

  20. Simple types • Pluggable type systems • Multi type system models • Type systems are declared on model level and identified via a prefix

  21. Complex types • Assets can serve as type definitions

  22. Complex type expressions • Complex type expressions: union, sequence, repetition.

  23. Constraints • Pluggable constraint languages • Possibility to define abstract constraints

  24. Operations • Operations are always abstract. Can be constrained by a user defined vocabulary. Can be guarded by pre- and postcondititions (contracts) using a declared constraint language.

  25. Namespaces • Each model is identified by its default namespace. Multi-namespace models are possible by declaring namespace prefixes. Assets are assigned to namespaces by prefixing the asset name. L2S belong to the namespace of their identifying asset. Model merging is namespace controlled. Namespace also identify type systems, constraint languages, and vocabularies.

  26. Namespaces and Properties • Properties are namespace neutral. They are identified via their asset. • Consequence: Inherited properties blend into the namespace of the inheriting asset (chameleon).

  27. Implementation notes • Annotations can be used to provide hints for the implementation of the model. Annotations can be externalized into a separate annotation script. Scripts are connected to models via the models default namespace. External scripts allow for implementation neutral models and for implementation variants.

  28. Summary • “Everything is a relationship” • Fits tightly with relational model • Flexible models (model evolution)‏ • Grammar based (HRG)‏ • Fits tightly with XML schema languages • Advanced model validation • Model transformation (refactoring)‏ • Powerful inheritance constructs • Compact and consistent models • Genuine key concept • Allows to generate highly efficient access code • Namespaces • Distributed model development, extensions

  29. KLEEN • Diagram Editor • Validation • Generators • Current status • What next?

  30. Diagram Editor

  31. Diagram Editor - Features • Automatic layout and arc routing • Views for item features, inheritance, dependencies • In-line editors for item features • Syntax checking • Property expressions, constraints, annotations, etc. • Assistance (automatic completion)‏ • Property expressions, constraints, annotations, etc. • Export as PNG and SVG

  32. Diagram Editor - Transformation • Explode asset • Implode asset • Resolve inheritance • Revert arc • Extract annotation script Implosion Inheritance resolution

  33. Model merging • Composite models include other models • Nesting is possible • Included models are “alive”

  34. Auditing • Systematic check for • Completeness • Consistency • Redundancy

  35. Model validation • Detects structural problems • Orphans • Arc and type cycles • Contradicting constraints • Warns on best practice violation • Non PNF key usage • Offers quick fixes • A click on an error marker proposes a fix for most urgent problem

  36. Implementation validation • Pluggable validators for different implementation targets. • Java, XML Schema, UML-XMI • Detects features not supported by the target environment. • e.g. Type sequences or liberal use of bags for XML Schema targets.

  37. XML Schema Generator • Generates standard XML Schema • Code generation can be controlled via scripting: • Attribute/Element/Any/Ignore • Default and fixed values • Mixed content • Documentation <?xml version="1.0" encoding="UTF-8"?> <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.corp.com" xmlns="http://www.corp.com/orders" xmlns:c="http://www.corp.com" xmlns:jag="http://www.aomodeling.org/KLEEN/JavaGenerator" xmlns:uml="http://www.aomodeling.org/KLEEN/XmiGenerator" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsg="http://www.aomodeling.org/KLEEN/XSDgenerator"> <!--Schema created by KLEEN XSD generator version 0.4.0--> <xs:import namespace="http://www.corp.com/orders" schemaLocation="www_corp_com_orders_TYPELIB.xsd"/> <xs:include schemaLocation="www_corp_com_TYPELIB.xsd"/> <!--Asset c:customer--> <xs:element name="customer"> <xs:complexType> <xs:choice> <xs:sequence> <xs:element name="name"/> <xs:element name="customerID" type="xs:NMTOKEN"/> </xs:sequence> <xs:sequence> <xs:element name="name"> <xs:complexType> <xs:sequence> <xs:element name="first"/> <xs:element minOccurs="0" name="middle"/> <xs:element name="last"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="birthDate" type="xs:date"/> <xs:element name="customerID" type="xs:NMTOKEN"/> </xs:sequence> </xs:choice> </xs:complexType> <xs:key name="pk__c_customer_customerID"> <xs:selector xpath="."/> <xs:field xpath="c:customerID"/> </xs:key> </xs:element> </xs:schema>

  38. XMI Generator • Generates standard XMI 1.0 • Generated code can be fed into UML modelers. <Foundation.Core.ModelElement.name>customer</Foundation.Core.ModelElement.name> <Foundation.Core.ModelElement.visibility xmi.value="public"/> <Foundation.Core.ModelElement.isSpecification xmi.value="false"/> <Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/> <Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/> <Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/> <Foundation.Core.Namespace.ownedElement> <Foundation.Core.Class xmi.id="xmi.17" xmi.uuid="uuid-1b8119a-f4c6e35f47-75b2d4280b36b135d9e254f3b2e61b7f"> <Foundation.Core.ModelElement.name>c__customer</Foundation.Core.ModelElement.name> <Foundation.Core.ModelElement.visibility xmi.value="public"/> <Foundation.Core.ModelElement.isSpecification xmi.value="false"/> <Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/> <Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/> <Foundation.Core.GeneralizableElement.isAbstract xmi.value="true"/> <Foundation.Core.Class.isActive xmi.value="false"/> <Foundation.Core.ModelElement.namespace> <Foundation.Core.Namespace xmi.idref="xmi.15"/> </Foundation.Core.ModelElement.namespace> <Foundation.Core.Classifier.feature/> <Foundation.Core.GeneralizableElement.specialization> <Foundation.Core.Generalization xmi.idref="xmi.21"/> <Foundation.Core.Generalization xmi.idref="xmi.32"/> </Foundation.Core.GeneralizableElement.specialization> </Foundation.Core.Class>

  39. Java Generator • Generates a class hierarchy mirroring the model structure. • Produces code for marshalling/unmarshalling Java objects to/from XML. • Compiles constraint expressions into Java. • Generates a framework for adding business logic (AOM meets AOP!)‏ • Scripts can control code generation: • Array/List/Map/Set • No events / Simple events / Bubbled events • Accessor methods vs. public fields • Documentation

  40. Asset code • Classes represent asset types. • Subclasses extend those types and represent assets (operations, arcs, etc.). • Inner classes implement complex properties. • Interfaces combine asset variants (clustered inheritance!)‏ package www.corp.com; import com.bdaum.aoModeling.runtime.*; /** *GeneratedwithKLEENJavaGeneratorV.0.4.5 */ publicinterface C_customer_type extends AomValueChangedNotifier { /** *MethodsetCustomerID.SetvalueofpropertycustomerID * *@paramvaluenewelementvalue */ publicvoid setCustomerID(String _value); /** *MethodgetCustomerID.GetvalueofpropertycustomerID * *@returnvalueoffieldcustomerID */ public String getCustomerID(); /** *performconstraintvalidation */ publicvoid validate() throws ConstraintException; } package www.corp.com.customer; import com.bdaum.aoModeling.runtime.*; import www.corp.com.C_customer_type; /** *GeneratedwithKLEENJavaGeneratorV.0.4.5 */ publicinterface C_customer extends C_customer_type { /** *performconstraintvalidation */ publicvoid validate() throws ConstraintException; }

  41. Type checks • Generates code for type checks into access methods. /** *MethodsetProductNo.SetvalueofpropertyproductNo * *@paramvaluenewfieldvalue */ publicvoid setProductNo(String _value) { if (_value == null)‏ thrownew IllegalArgumentException( ModelMessages.getString("Argument.not_null", "productNo")); if (!TypeCheck.isString(_value))‏ thrownew IllegalArgumentException( ModelMessages.getString("Argument.nonXML_characters","productNo")); if (!TypeCheck.isNMTOKEN(_value))‏ thrownew IllegalArgumentException( ModelMessages.getString("Argument.invalid_type_pattern","productNo","NMTOKEN")); productNo = _value; }

  42. Constraints and Contracts • Explicit constraints are checked on demand. /***ConstraintvalidateConstraint1:amount>=0*@throwscom.bdaum.aoModeling.runtime.ConstraintException*/publicvoid validateConstraint1() throws ConstraintException {if (!(getAmount() >= 0))thrownew ConstraintException( ModelMessages.getString("Constraint.violated", "amount >= 0"));} • Contracts are checked before and after operations. /***Operationdeliver.*@param_sender-thesenderinstanceofthismessage*/publicvoid deliver(AomObject _sender) {assert getClient().getMerchandise().containsKey(getProduct().getProductId()) :"Product = client/merchandise"; performOperation(OP_deliver, _sender);}

  43. Events • Three types of event notification: • none • simple • bubbled /** *MethodsetAmount.Setvalueofpropertyamount * *@paramvaluenewfieldvalue */ publicvoid setAmount(int _value) { if (_value == amount)‏ return; int oldStockedWith_amount = amount; amount = _value; fireIfValueChanged(this,oldStockedWith_amount,_value,PackageInterface.StockedWith_amount); }

  44. Marshalling • Instances of generated Java classes can be saved as XML documents. • Documents comply with XSD schemata generated by the XSD generator. publicvoid toXML(XmlSerializer out, String encoding, Boolean standalone) throws IOException, IllegalArgumentException, IllegalStateException { out.startDocument(encoding, standalone); out.setPrefix("", PackageInterface._DEFAULT_NAMESPACE); out.setPrefix("xsi", PackageInterface._XSI_NAMESPACE); out.startTag(null, "Shop"); out.attribute(PackageInterface._XSI_NAMESPACE, "schemaLocation", PackageInterface._DEFAULT_NAMESPACE + " Shop.xsd"); toXML(out); out.endTag(null, "Shop"); out.flush(); }

  45. Unmarshalling • XML documents can be parsed to create new Java objects. • Pull parser interface allows parsing from InputStream, DOM-tree, SAX event stream, etc. • Parser resolves links across documents. public AomObject parseXmlDocument(XmlPullParser xpp) throws XmlPullParserException, IOException { if (xpp.getEventType() != XmlPullParser.START_DOCUMENT)‏ thrownew XmlPullParserException(ModelMessages.getString(ErrorMessages.START_DOCUMENT_EXPECTED)); xpp.next(); ParserUtilities.verifyStartTag(xpp, "Shop", PackageInterface._DEFAULT_NAMESPACE, true); Shop instance = new Shop(); this.parser = xpp; instance.parseAsset(this); parser = null; ParserUtilities.consumeEndTag(xpp); if (xpp.getEventType() != XmlPullParser.END_DOCUMENT)thrownew XmlPullParserException(ModelMessages.getString(ErrorMessages.END_DOCUMENT_EXPECTED, String.valueOf(xpp.getLineNumber()))); return instance; }

  46. Instrumentation • Aspects can be dynamically connected to asset classes. • A Main class with default instrumentation is generated. /*--com.bdaum.aoModeling.generator.java/instrumentation operation */ publicstaticvoid attachMainOperationInstrumentation() { Aspect _aspect; /****Createandregistermainoperationaspects****/ /*--com.bdaum.aoModeling.generator.java/aspect Shop_mainOperationAspect */ _aspect = new Shop_mainOperationAspect(); //--com.bdaum.aoModeling.generator.java/point OP_$init; Shop.attachInstrumentation(Shop.OP_$init, _aspect); //--com.bdaum.aoModeling.generator.java/point OP_processOrders; Shop.attachInstrumentation(Shop.OP_processOrders, _aspect); //--com.bdaum.aoModeling.generator.java/point OP_$dispose; Shop.attachInstrumentation(Shop.OP_$dispose, _aspect); //--com.bdaum.aoModeling.generator.java/point;

  47. Aspects • Four types of standard aspects are currently generated: • Operation (Custom Business logic)‏ • Logging (for debugging purposes)‏ • XML (for xs:any elements)‏ • Constraint (for abstract constraints)‏ publicclass Shop_mainOperationAspect extends OperationAspect { publicboolean isStatic() { returntrue; } publicboolean run(int point,int mode,Object extension,AomObject receiver,AomObject sender) { final Shop aShop = (Shop) receiver; switch (point) { //--com.bdaum.aoModeling.generator.java/point OP_$init; case Shop.OP_$init : //TODO Implement operation Shop.OP_$init break; //--com.bdaum.aoModeling.generator.java/point OP_processOrders; case Shop.OP_processOrders : //TODO Implement operation Shop.OP_processOrders break; //--com.bdaum.aoModeling.generator.java/point OP_$dispose; case Shop.OP_$dispose : //TODO Implement operation Shop.OP_$dispose break; //--com.bdaum.aoModeling.generator.java/point; } returntrue; } }

  48. Current status of KLEEN • All essentials of the core diagram editor are implemented. • Validators for core model, Java, SQL, XML Schema and XMI. • Generators for Java, SQL, XML Schema and XMI. Generated applications ready to execute. • XPath constraint language. • Java, XML Schema, SQL type systems – cross compiled to target environment. • Design patterns, usage and authoring.

  49. What next? • Generators for JPA, WebServices and GUIs • Other constraint languages (OCL?, XPath 2.0?)‏ • Better integration into RCP-framework • And then: Process modeling?

  50. Thank you www.aoModeling.org

More Related