Domain Modelling and Implementation Canonical modelling approach Simon Cox Research Scientist Sydney...

Domain Modelling and Implementation Canonical modelling approach

Simon Cox

Research Scientist

Sydney - December, 3rd 2010

CSIRO. Masterclass: Domain Modelling and Implementation - Sydney 03/12/2010

Overview

• UML, Modeling basics• Hollow-World: the ISO HM, SWE and O&M• Standard stereotypes• Tagged values• Modeling practices


Unified Modeling Language


Unified Modelling Language (UML)

• OMG’s ‘Platform Independent’ modelling environment• Object-oriented• 13 types of diagrams

• Structure• Package, class, object, component, deployment …

• Behaviour• Use-case, activity, state

• Interactions• Sequence, communication …


Classes


Class diagrams

• Show information objects, their properties and relationships

}Class attributes

}Class constraints

Not shown – class operations

Additional parent not shown

Specialization

Association

Class stereotype

Attribute stereotype

Association-end role name

Class


Relationships


• Class attributes & navigable association-ends• Navigable end

owned by source class

• Composite association ≈ attribute

Properties


UML Constraints

•Rules that can’t be captured in boxes and lines• Text, or OCL


Diagrams are selective

• The diagrams are not the model• Each diagram is a ’projection’ or ‘view’ of part of the model,

to communicate a key point• Fight the A0 plotter syndrome!


Lots of diagrams are a Good Thing

• Especially in packages containing many classes


Other diagrams used in data modeling


pkg GeoSciML package dependencies

«Application Schema»GeoSciML-Core

«Application Schema»CGI_Utilities

«Application Schema»PhysicalProperties

«Application Schema»Borehole

«Application Schema»LaboratoryAnalysis-Specimen

«Application Schema»GeologicTimescale

«Application Schema»TemporalReferenceSystem

ISO 19108:2006 Temporal Schema

(from ISO 19108 Temporal schema)

ISO DIS 19156:2010 Observ ations and Measurements

(from ISO 19156 Observations and Measurements)

SensorML v 1.0

(from Sensor Web Enablement 1.0)

ISO 19107:2003 Spatial Schema

(from ISO 19107 Spatial Schema)

ISO 19115:2006 Metadata (Corrigendum)

(from ISO 19115-All Metadata)

ISO 19103:2005 Schema Language

(from ISO 19103 Conceptual Schema Language)

«Application Schema»EarthMaterial

Need to update to SWE v2 when available

«import»

«import»

«import»

«import»

«import»

«import» «import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»

Name:Package:Version:Author:

GeoSciML package dependenciesGeoSciML3.0.0CGI Interoperability Working Group

Package diagrams

• Dependencies & maintenance arrangements


Object diagrams

• … can get busy very fast

“Accidents in Legoland”

Mostly useful in the analysis phase


Summary of UML structure diagrams

• Package • ownership (governance arrangements) • dependencies

• Class • the data model

• Objects • examples in action


HollowWorld


Hollow World template

• A template for designing application schemas in UML

• Contains key standards components• ISO 19100 Harmonized Model• OGC SWE Model• ISO 19136 stereotypes and tagged values

• Optimized for Sparx Enterprise Architect …


ISO Harmonized Model

• Key packages used for Application Schema design:

• 19103 – primitive types • 19107 – geometry • 19108 – temporal • 19111 – coords • 19115 – metadata • 19123 – coverages• 19136 – GML • 19156 – O&M

• (go to EA live to explore)


Standard components: OGC Sensor Web

• Key packages used for Application Schema design:

• SensorML• Observations & Measurements• SWE Common• SOS, SPS ...



Elements from external standards

• The standard components are loaded by EA from remote SVNs• They are locked against modification by unauthorized users

(i.e. mere application-schema designers!)• i.e. the tool enforces the governance arrangements

• Package domain model separately


Hollow World UI

Access to standard/utility componentsAccess to standard stereotypes


UML extensibility points


UML extensions

• Stereotypes• Extend the meta-model: • To create an additional class-of- [classes, associations, attributes]


UML Stereotypes

«FeatureType» standard properties & behaviour

~multiple inheritance


class Context Diagram : BoreholeDetails

«DataType»BoreholeDetails

+ coreCustodian: CI_ResponsibleParty+ coredInterval: GM_Envelope [1..*]+ dateOfDrill ing: TM_CalDate+ dril ler: CI_ResponsibleParty+ dril l ingMethod: BoreholeDrill ingMethodCode+ inclinationType: BoreholeInclinationCode+ nominalDiameter: Quantity+ operator: CI_ResponsibleParty+ startPoint: BoreholeStartPointCode

«CodeList»BoreholeStartPointCode

+ from pre-existing hole+ natural ground surface+ open pit floor or wall+ underground

«CodeList»BoreholeInclinationCode

+ horizontal+ inclined down+ inclined up+ vertical

SF_SamplingCurve

«FeatureType»Borehole

TM_TemporalPosition

Temporal Reference System::TM_CalDate

+ calDate: Sequence<Integer>+ calendarEraName: CharacterString

«datatype»Citation and responsible party information::

CI_ResponsibleParty

+ contactInfo: CI_Contact [0..1]+ individualName: CharacterString [0..1]+ organisationName: CharacterString [0..1]+ positionName: CharacterString [0..1]+ role: CI_RoleCode

«CodeList»BoreholeDrillingMethodCode

+ air core+ auger+ cable tool+ diamond core+ direct push+ hand auger+ hydraulic rotary+ RAB+ RC+ unknown+ vibratory

Coordinate geometry::GM_Envelope

{root}

+ lowerCorner: DirectPosition+ upperCorner: DirectPosition

AbstractDataComponent

simpleTypes::Quantity

+ constraint: AllowedValues [0..1]+ quality: Quality [0..*]+ uom: UomIdentifier [0..1]+ value: double [0..1]

+indexData

1


Context Diagram : BoreholeDetails«Application Schema» Borehole3.0.0CGI Interoperability Working Group

Class stereotypes

• «FeatureType»• Domain class,

instances have identity• «Type» or none

• Has identity, but not a feature; e.g. geometry, topology, temporal object, definition

• «DataType»• Just a data structure,

no external identity, always inline

• «Union»• Ad-hoc choice

• «Enumeration»• Closed enumeration

• «Codelist»• Extensible enumeration


Package stereotypes

• «Application Schema»• independently governed package,

separate XML namespace• «Leaf»

• Convenience package, no sub-packages, separate XSD document


UML extensions

• Stereotypes• Tagged values

• Embed information for specific implementation platforms • Doesn’t relate to the conceptual level


UML Tagged values


Tagged values for GML encoding

• Package• xsdDocument• xmlns• targetNamespace

• Class• noPropertyType• byValuePropertyType• asDictionary («codeList» only)• ownedBy (proposed)

• Attribute and association end• sequenceNumber• inlineOrByReference• estimatedProperty (proposed)

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlGmlStereotypesAndTaggedValues



High level usage guidelines


Use of UML

• Informative - sketch or illustrate ideas• Ambler (Agile methodologies …) uses it mostly this way

vs. • Formal & complete

• In order to feed a CASE tool

• For automatic implementation, the model must be complete• Everything required for implementation must be in either

• The model• The rule for converting from model to implementation

• UML == ‘graphical programming language’• Every comma counts, just like real programming


Be aware of the workflow

• Raw observations• E.g. temperature field, flow-rate history, density distribution, colour

distribution (image)• i.e. evidence

• Interpolated/modelled properties• Geophysics, MetOcean• Results of simulations and process models,

conditioned by observations• i.e. predictions, simulations, inversions

• ‘Real-world’ features• E.g. weather system, ore-body, forest, reef• i.e. result of interpretation

• Often useful to segregate these viewpoints into different packages


Be consistent about the abstraction level

• Conceptual - Domain semantics• Terminology as used by practitioners in the discipline

• not an abstraction from data management • ‘Ore-body’, not ‘Table’ or ‘Polygon’ or ‘URI’

• Don’t show identifier, key/keyref in the class model • these are implicit in the relationships

• Implementation • Shows implementation artefacts like ‘string’, ‘id’, ‘index’


More information

• For more detail:• https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlOutline • https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlGmlStereotypesAndTagg

edValues

• https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlGmlTestModels

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlOutline



https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlGmlTestModels


Design strategy


Model is in the markup

• ‘striped’ syntax - UpperCamelCase objects, lowerCamelCase properties• Manually generate Instance examples - Don’t need XSD during design phase

<gsml:Borehole gml:id="gcDD0214"> <gml:name codeSpace="urn:cgi:authority:CGI:GSV“ >gcDD0214</gml:name> <sa:length uom="m">48.3</sa:length> <sa:shape> <gml:LineString gml:id="gcDD0214survey“ > ... </gml:LineString> </sa:shape> <gsml:collarLocation> <gsml:BoreholeCollar gml:id="gcDD0214c"> <gsml:location> <gml:Point gml:id="gcDD0214p"> <gml:pos srsName="urn:ogc:crs:EPSG::4326“ >-31.939 115.832</gml:pos> </gml:Point> </gsml:location> <gsml:elevation srsName=“urn:ogc:crs:EPSG::5711” >34.5</gsml:elevation> </gsml:BoreholeCollar> </gsml:collarLocation> <gsml:indexData> <gsml:BoreholeDetails> ... </gsml:BoreholeDetails> </gsml:indexData> ...</gsml:Borehole>


Design strategy – UML + XML instances

• Iterative design process• test the model with manually generated XML fragments

• Wait to generate an XML Schema until model is substantially complete

• E.g. https://www.seegrid.csiro.au/subversion/GeoSciML/trunk/instances

https://www.seegrid.csiro.au/subversion/GeoSciML/trunk/instances

Contact UsPhone: 1300 363 400 or +61 3 9545 2176

Email: [email protected] Web: www.csiro.au

Thank you

Earth Science & Resource EngineeringSimon CoxResearch Scientist

Phone: 08 6436 8639Email: [email protected]: www.csiro.au


UML vs. other formalizations


• UML = objects, operations• Object associations - graph topology

• XML = elements, attributes – no ops• Element nesting = tree topology

UML vs. XML

A1 C

G

T

M

A3

H


• Use links used to build graphs in XML<document> <Circle id="A1"> <Circle id="C"> <Circle id="T"> <Circle id="H"> </Circle> <link href="#M"/> </Circle> <Circle id="M"> <link href="#T"/> <link href="http://example.org/X"/> </Circle> </Circle> <Circle id="G"> <Circle id="A3"> <link href="#M"/> </Circle> <link href="#C"/> </Circle> </Circle></document>

• In general, link targets are identified by URI• N.B. URI open-world

Links

X

A1 C

G

T

M

A3

H


UML Profile for XML

• XML is not as expressive as UML• restricted profile of UML must be used,

to enable XML serialization following these patterns


UML Structure models vs. RDF/OWL

• Both are based on graphs of resources + relationships• Largely transformable

• Key relationships have special symbols in UML• E.g. subClassOf == Generalization

• RDF one diagram type, two meta-levels: class and individual• Description Logic is based on set-theory, i.e sets and members

• UML many diagram types, separate diagrams for class and object; but UML includes an arbitrary number of meta-levels

• «metaclass» stereotype, --«implements»- relationship• UML does not support “complement” or “not”• UML closed-world

• Strictly cardinality rules, complete model, validity checking• RDF open-world

• Anyone can say anything, never see complete model, inferencing


The model-based method


Information modeling

• [ISO 19103] The following modeling phases are recommended: • Phase 0: Identify scope and context. • Phase 1: Identify basic classes. • Phase 2: Specify relationships, attributes and operations. • Phase 3: Completion of constraints using text/OCL. • Phase 4: Model definition harmonization – with sub-models and

other work items.


Model based design

• Premise: • domain analysis captured in a formal model should precede, and if

possible drive, implementations• Argument:

• Analysis can be done at the right level of abstraction• Applications derived from a conceptual view are more robust

than software developed directly on a specific technology• Platform independent representation supports multiple platforms • Types can be reliably traced between platforms• Revisions flow through automatically to all platforms

• Goal• One normative artefact – the UML model• Software and documentation generated automatically

• Origins in ‘CASE’ tools


Object diagrams


Standard components: GML extensions to HM

• Key elements used in Application Schema design:

• AbstractFeature• Definition, Dictionary• LineString, Polygon



Using HollowWorld


Software and configuration

1. Checkout HollowWorld SVN

2. Make a copy of the HollowWorld template model

3. Checkout any other models that will be used as dependencies of your model

4. Install Enterprise Architect

5. Run EA, load the template, fix the Version Control Settings, load the GML profile

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/ConfiguringUMLToolForHollowWorld

• Create «Application Schema» package• Start modelling …

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/ModelingUsingHollowWorld https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlGmlTestModels

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/%0BConfiguringUMLToolForHollowWorld

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/%0BConfiguringUMLToolForHollowWorld

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/ModelingUsingHollowWorld



Classes

• https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/UmlGmlTestModels

«FeatureType»Sample

+ comment: CharacterString

tagsbyValuePropertyType = falseisCollection = falsenoPropertyType = false

«Union»GeoEntity

+ unit: GeologicUnit+ structure: GeologicStructure+ material: EarthMaterial


sampledFeature


Package: Sample«Leaf» Sample1.0Simon Cox

Test model 08 Test model 19

«FeatureType»Sample

+ comment: CharacterString+ preparationTime: TM_Primitive


«type»Geometry root::

GM_Object{n}

shape 0..1


Sample«Leaf» Sample1.0Simon Cox



Example project


Example project: GGIC Earth Resource model


Main dependencies


Class diagrams

«FeatureType»EarthResource

+ sourceReference: CI_Citation [0..*]

«estimatedProperty»+ dimension: EarthResourceDimension [0..1]+ expression: CGI_TermValue [0..*]+ form: CGI_TermValue [0..*]+ l inearOrientation: CGI_LinearOrientation [0..*]+ planarOrientation: CGI_PlanarOrientation [0..*]+ shape: CGI_TermValue [0..*]

«FeatureType»GeologicFeature::GeologicFeature

+ observationMethod: CGI_TermValue [1..*]+ purpose: DescriptionPurpose = instance

constraints{self.metadata.hierarchyLevel=(feature or dataset or series)}

«DataType»MineralSystem

+ associationType: CGI_TermValue

«FeatureType»MineralOccurrence

«estimatedProperty»+ type: MineralOccurrenceTypeCode

«DataType»OreMeasure

+ calculationMethod: CharacterString+ date: TM_GeometricPrimitive+ dimension: EarthResourceDimension [0..1]+ proposedExtractionMethod: CGI_TermValue [0..1]+ sourceReference: CI_Citation [1..*]

«estimatedProperty»+ ore: CGI_Numeric

«DataType»EarthResourceMaterial

+ earthResourceMaterialRole: ERMaterialRoleCode+ material: EarthMaterial+ proportion: CGI_Value [0..1]

«FeatureType»NonMetallicOccurrence

«DataType»SupergeneProcesses

+ depth: CGI_Numeric [0..1]+ material: EarthMaterial [0..*]+ type: CGI_TermValue [0..1]

«FeatureType»Commodity

+ commodityGroup: ScopedName [0..*]+ commodityName: ScopedName

«estimatedProperty»+ commodityImportance: ImportanceCode [0..1]+ commodityRank: Integer [0..1]

«DataType»MineralDepositModel

«estimatedProperty»+ mineralDepositGroup: ScopedName [1..*]+ mineralDepositType: ScopedName [0..*]

MiningFeature

«FeatureType»Mine::MiningActiv ity

+ activityDuration: TM_Period+ activityType: MiningActivityTypeCode+ oreProcessed: CGI_Numeric [0..1]

child 0..*

parent 0..1

0..*

geneticDescription 0..1

1

oreAmount 0..*

1

composition 0..*

1

supergeneModification

0..*source

1

commodityDescription

1..*

0..*classification

0..1

resourceExtraction 0..*

deposit 1


Context: EarthResource«Leaf» MineralOccurrence1.0Simon Cox

Domain Modelling and Implementation Canonical modelling approach Simon Cox Research Scientist Sydney...

Documents

Transcript of Domain Modelling and Implementation Canonical modelling approach Simon Cox Research Scientist Sydney...