• Save
Architecture As Language
Upcoming SlideShare
Loading in...5
×
 

Architecture As Language

on

  • 1,575 views

Software Architecture is often either imprecise and hard to grasp or technology specific. What you really want is a succinct, precise, technology-independent and tool-processable description of an ...

Software Architecture is often either imprecise and hard to grasp or technology specific. What you really want is a succinct, precise, technology-independent and tool-processable description of an architecture. In this tutorial we illustrate how textual DSLs can be used to this end. The core idea is to actually develop an architecture language as you understand the architecture, formalizing the growing intuitive understanding into a formal language. This removes ambiguity from the discussion, requires answers to arising questions and results in a more consistent and (re-)usable architecture. The tutorial has three parts: we start with a role play where we showcase how an architecture DSL is developed as part of a discussion about a system's architecture. We actually build an example DSL in real time. In part two we look at some of the concepts, rationales and benefits of the approach, and briefly point to tools that can be used to build languages and associated tooling. The third part looks at how to use the approach for product lines: how to express variability in the architectural descriptions, and how to integrate the DSL with feature-modeling based variability management. The tutorial is for practitioners, by practitioners. It is guaranteed to contain only practice-oriented material.

Statistics

Views

Total Views
1,575
Views on SlideShare
1,572
Embed Views
3

Actions

Likes
5
Downloads
0
Comments
1

1 Embed 3

http://www.slideshare.net 3

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…
  • Muito BOM!!!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Architecture As Language Architecture As Language Presentation Transcript

  • Architecture As Language
    MarkusVoelter
    www.voelter.devoelter@acm.org
  • About
    Markus Voelter
    Independent Consultant
  • About
    Markus Voelter
    Independent Consultant
    Software Architecture
    DSLs & MDSD
    ProductLines
  • About
    Markus Voelter
    Independent Consultant
    http://www.voelter.de
    voelter@acm.org
    skype: schogglad
  • Architecture
  • Architecture
    DSLs/MDSD
  • Architecture
    DSLs/MDSD
    ProductLines
  • Architecture
    DSLs/MDSD
    ProductLines
    This Talk
  • Architecture
    Whatever has to be consistent throughout a system to satisfy
    requirements and -ilities.
    != granularity
    evolves over time
  • DSLs/MDSD
    Modeling
    Language Design
    Code Generation
     UML, SysML or ADLs
    here: Textual
  • ProductLines
    Managing the Variability
    between a family of related,
    but not identical products
  • Based on actualpracticalexperience
  • Currently in usewithfourofmycustomers
  • Benchmarkedby
    suitabilityforuse in today‘sprojects
  • Part 1
    A real-word Story
    1.1 System Background
    1.2 The Starting Point
    1.3 What is a language?
    1.4 Developing the Language

  • Part 2
    TheoryandConcepts
    2.1 What we did in a Nutshell
    2.2 Domain Specific Languages
    2.3 The Importance of Viewpoints
    2.4 Benefits
    2.5 Why Textual?
    2.6 Model Validation
    2.7 Generating Code
    2.8 Architecture Analysis Tools
    2.9 Standards, UML and ADLs

  • Part 2
    TheoryandConcepts
    2.10 Why not use a 3GL?
    2.11 My Notion of Components
    2.12 Component Implementation
    2.13 The Role of Patterns
    2.14 Documentation
    2.15 Expressing Variability
    2.16 PLE – Big Picture
    2.17 Process
    2.18 Underlying Concepts
  • More Reading:
    Thispresentationis not suitableforreadingwithoutmetalking in parallel. Youcan find documentsdescribingthecontentat
    http://www.voelter.de/data/articles/ArchitectureAsLanguage-PDF.pdf
    http://www.voelter.de/data/articles/ArchitectureAsLanguage-Part2-PDF.pdf
  • 1
    A Real-World Story
  • Customer
    Consultant
  • Requirements
    Domain Expertise
    Solution Approach
  • 1.1
    A Real-World Story
    System Background
  • Flight
    Management
    System
  • Monitors
    Website
    Aircraft-Module
    Data Center
  • Distributed
    System
  • A lotofexperiencewithsystemslikethese
  • Evolveover 15 – 20 years
  • Multiple Languages
    Java
    C++
    C#
  • Technology
    Abstraction
  • Cannot update
    everythingatonce
  • Loose coupling
    Versioning
  • Different Installations
    have different features
  • Variants
    ProductLines
  • 1.2
    A Real-World Story
    The Starting Point
  • Backbone:Messaging
    [Good]
  • Technology Evaluated
  • BusinessObject Model
    [Not so good]
  • Problem:Consistence?
    Big Picture?
    Technology Abstraction?
  • Huge & Typical
    Problem
  • Language!
  • Formal
    Language!
  • 1.3
    A Real-World Story
    Whatis a language?
  • INFORMAL
    Set of well-definedterms
  • INFORMAL
    Stakeholders
    agree on meaning
  • FORMAL
    Metamodel
  • FORMAL
    Metamodel
    Grammar
  • FORMAL
    Metamodel
    Grammar
    Notation
  • 1.4
    A Real-World Story
    Developingthe Language
  • Let‘sdefine a formal languagetodescribethesystem‘sarchitecture
  • Components
  • Component:SmallestArchitecturally Relevant Building Block
  • Component:Piece offunctionality
  • Component:Can beinstantiated
  • Initial Components:
    Delay Calculator
    Info Screen
    Aircraft Module
  • componentDelayCalculator{}
    componentInfoScreen {}
    componentAircraftModule {}
  • Language
    ==
    ConceptualArchitecture
  • „Program“
    ==
    Application
    Architecture
  • Conceptual:
    Component
    Application:
    DelayCalculator, InfoScreen, Aircraft Module
  • DelayCalculator
    receivesdatafrom
    Aircraft Module
  • DelayCalculator
    forwardsdata
    to InfoScreens
  • Interfaces
  • componentDelayCalculatorimplementsIDelayCalculator {}
    componentInfoScreenimplementsIInfoScreen {}
    componentAircraftModuleimplementsIAircraftModule {}
    interfaceIDelayCalculator {}
    interfaceIInfoScreen {}
    interfaceIAircraftModule {}
  • But wedon‘t
    express interface
    requirements!
  • Interface provision +
    Interfacerequirement
     Dependencygraph
  • Essentialfor
    understanding
    andtool-based
    Analysis
  • componentDelayCalculator {
    providesIDelayCalculator
    requiresIInfoScreen
    }
    componentInfoScreen {
    providesIInfoScreen
    }
    componentAircraftModule {
    providesIAircraftModule
    requiresIDelayCalculator
    }
    interfaceIDelayCalculator {}
    interfaceIInfoScreen {}
    interfaceIAircraftModule {}
  • Therearemany
    InfoScreens andAircraftModules
  • Components
    needtobeinstantiated
  • Instantiation:
    veryimportant
    conceptwhendefininglanguages
  • componentInfoScreen {
    providesIInfoScreen
    }
    instance screen1: InfoScreen
    instance screen2: InfoScreen

  • Componets (types)
    arealreadycompatible
    viatheirinterfaces.
  • OneDelayCalculatortypicallytalkstomany InfoScreens
  • Ports
  • Port:
    CommunicationEndpoint
  • Port:
    OwnedbyComponent
  • Port:
    Instantiatedalong
    withComponent
  • Port:
    Can havecardinality
  • componentDelayCalculator {
    provides default: IDelayCalculator
    requires screens[0..n]: IInfoScreen
    }
    componentInfoScreen {
    provides default: IInfoScreen
    }
    componentAircraftModule {
    provides default: IAircraftModule
    requires calculator[1]: IDelayCalculator
    }
  • Weshould separate
    portsand interfaces
    byroles!
  • componentDelayCalculator {
    provides aircraft: IAircraftStatus
    providesmanagementConsole: IManagementConsole
    requires screens[0..n]: IInfoScreen
    }
    component Manager {
    requires backend[1]: IManagementConsole
    }
    componentInfoScreen {
    provides default: IInfoScreen
    }
    componentAircraftModule {
    requires calculator[1]: IAircraftStatus
    }
  • Enrichmentof Language
     BetterApplicationArchitecture
  • Howtoactuallyconnectinstances
    andtheirports?
  • Connectors
  • Connector:
    Connectstwoormoreportinstances
  • componentDelayCalculator {
    requires screens[0..n]: IInfoScreen

    }
    componentInfoScreen {
    provides default: IInfoScreen
    }
    instance dc: DelayCalculator
    instance screen1: InfoScreen
    instance screen2: InfoScreen
     
    connectdc.screens
    to (screen1.default, screen2.default)
  • How do westructure/organizetheoverallsystem?
  • Namespaces
  • namespacecom.mycompany {
    namespace datacenter {
    componentDelayCalculator {
    provides aircraft: IAircraftStatus
    providesmanagementConsole: IManagementConsole
    requires screens[0..n]: IInfoScreen
    }
    component Manager {
    requires backend[1]: IManagementConsole
    }
    }
    namespace mobile {
    componentInfoScreen {
    provides default: IInfoScreen
    }
    componentAircraftModule {
    requires calculator[1]: IAircraftStatus
    }
    }
    }
  • Systems are a separate viewpoint
  • namespacecom.mycompany.test {
    systemtestSystem {
    instance dc: DelayCalculator
    instance screen1: InfoScreen
    instance screen2: InfoScreen
    connectdc.screens
    to (screen1.default, screen2.default)
    }
    }
  • Wedon‘tknowthe InfoScreens statically
    whenthesystemisdesigned!
  • Dynamic
    Connectors
  • Dynamic Connector:Discovers target(s) atruntimeusing a naming/trader/registryservice
  • namespacecom.mycompany.production {
    instance dc: DelayCalculator
    // InfoScreen instances are created and
    // started in other configurations
    dynamicconnectdc.screensevery 60 query {
    type = IInfoScreen
    status = active
    }
    }
  • Dynamic Wiring
    does not invalidate
    theoverallapproach
  • Similar Approach
    canbeusedfor redundant connectors
  • Registration
    Properties forinstances
    used in lookup
  • namespacecom.mycompany.datacenter {
    registeredinstance dc1: DelayCalculator {
    parameters {role = primary}
    }
    registeredinstance dc2: DelayCalculator {
    parameters {role = backup}
    }
    }
  • Interfaces aren‘treallydefinedyet
  • Interface:setofrelated
    messages
  • interfaceIInfoScreen {
    messageexpectedAircraftArrivalUpdate (id: ID, time: Time)
    messageflightCancelled(flightID: ID)

    }
  • Data Structures
  • typedef long ID
    struct Time {
    hour: int
    min: int
    seconds: int
    }
  • Different kinds
    ofmessages:
    oneway, req/resp
  • Message Interaction Patterns
  • interfaceIAircraftStatus {
    onewaymessagereportPosition
    (aircraft: ID, pos: Position )
    request-replymessagereportProblem {
    request (aircraft: ID, problem: Problem,
    comment: String)
    reply (repairProcedure: ID)
    }
    }
  • Is itreally
    Messages?
  • ?
  • Status Updates!
    Flight Plans…!
  • WrongAbstraction!
  • Messages aretheimplementation,
    notthearchitecturalintent.
  • Data Replication
  • Data Replication
    Define Data
    Updated byfew, readbymany
    Full update, incremental update,invaldation…
  • New architecturalabstractionisadded
    tothelanguage
  • structFlightInfo {
    from: Airport
    to: Airport
    scheduled: Time
    expected: Time

    }
     
    replicatedsingleton flights {
    flights: FlightInfo[]
    }
     
    componentDelayCalculator {
    publishes flights
    }
     
    componentInfoScreen {
    consumes flights
    }
  • More Concise
  • System derives
    Messages for (full & partial) update, invalidation, etc.
  • More specifics
  • componentDelayCalculator {
    publishes flights { publication = onchange }
    }
     
    componentInfoScreen {
    consumes flights { init = all update = every(60) }
    }
  • We stillneedmessages.
    Semantics?
  • Pre- and Post-
    Conditions
  • interfaceIAircraftStatus {
    onewaymessagereportPosition(aircraft: ID, pos: Position ) {
    pre aircraft != null: “aircraft not specified”
    pre pos != null: “position not specified”
    }
    request-replymessagereportProblem {
    request (aircraft: ID, problem: Problem, comment: String)
    reply (repairProcedure: ID)
    pre aircraft != null: “aircraft not specified”
    pre problem != null: “problem not specified”
    postrepairProcedure != null
    }
    }
  • Common Constraints: Shorter Syntax
  • interfaceIAircraftStatus {
    onewaymessagereportPosition(aircraft: ID!, pos: Position! )
    request-replymessagereportProblem {
    request (aircraft: ID!, problem: Problem!, comment: String!)
    reply (repairProcedure: !ID)
    }
    }
  • Message Sequences:
    Protocol State Machines
  • interfaceIAircraftStatus {
    onewaymessageregisterAircraft(aircraft: ID! )
    onewaymessageunregisterAircraft(aircraft: ID! )
    onewaymessagereportPosition(aircraft: ID!, pos: Position! )
    request-replymessagereportProblem {
    request (aircraft: ID!, problem: Problem!, comment: String!)
    reply (repairProcedure: !ID)
    }
    protocolinitial = new {
    state new {
    registerAircraft => registered
    }
    state registered {
    unregisterAircraft => new
    reportPosition
    reportProblem
    }
    }
    }
  • Invariantsfor Data Structures
  • struct Time {
    hour: int
    min: int
    seconds: int
    inv hour >= 0 && hour <= 23: “hour must be 0-23”
    inv min >= 0 && min <= 59: “min must be 0-59”
    inv seconds >= 0 && seconds <= 59: “seconds must be 0-59”
    }
  • Widelydistributed!Versioning?
  • Mark upversionsofcomponents
    (andotherstuff)
  • componentDelayCalculator {
    publishes flights { publication = onchange }
    }
    newImplOfcomponentDelayCalculator: DelayCalculatorV2
  • componentDelayCalculator {
    publishes flights { publication = onchange }
    }
    newVersionOfcomponentDelayCalculator: DelayCalculatorV3 {
    publishes flights { publication = onchange }
    providessomethingElse: ISomething
    }
  • TheEnd !
    ofthe Story :-)
  • None ofthosethingsisnew
    orunique.
  • But everything
    isexpressedexplicitlyandconsistently, all in oneplace.
  • 2
    TheoryandConcepts
  • 2.1
    TheoryandConcepts
    Whatwedid in a Nutshell
  • As you understand
    anddevelopyour
    Architecture…
  • Develop a languageto express it!
  • Language resemblesarchitecturalconcepts
  • We express theapplication(s) withthelanguage.
  • Architecture
    DSL
  • 2.2
    TheoryandConcepts
    Domain SpecificLanguages
  • Definition
  • A DSL is a focussed, processablelanguagefor describing a specific concernwhen building a system in a specific domain. Theabstractionsandnotationsused are natural/suitablefor the stakeholderswho specify that particular concern.
  • focussed
  • processable
  • language
  • concern/viewpoint
  • domain
  • abstractions
  • notation
  • stakeholders
  • Dimensions
  • internal
    vs.
    external
  • compiled
    vs.
    interpreted
  • customization
    vs.
    configuration
  • graphical
    vs.
    textual
  • 2.3
    TheoryandConcepts
    The ImportanceofViewpoints
  • viewpoint
    A „perspective“ towardsthesystem
  • Based on a slideby Steve Cook and IEEE 1471
  • Type
    Deployment
    Composition
  • 2.4
    TheoryandConcepts
    Benefits
  • Clear Understanding
    frombuildingthelanguage
  • Unambigious
    Vocabulary
  • Conceptsindependent
    from Technology
  • Programming Model canbedefinedbased on ConceptualArcitecture
  • Architecture„executable“
    (i.e. morethanrulesanddocs)
  • 2.4
    TheoryandConcepts
    WhyTextual?
  • 2.4
    TheoryandConcepts
    … or:why not graphical?
  • Languagesand Editors
    areeasiertobuild
  • Languagesand Editors
    areeasiertobuild
    Evolve Language and simple editorasyou understand anddiscussthearchitecture, in real time!
  • Integrateseasilywithcurrentinfrastructure:
    CVS/SVN diff/merge
  • Model evolutionistrivial, youcanalwaysusegrep.
    adaptingexistingmodelsasthe DSL evolves
  • Many Developers
    prefertextualnotations
  • When a graphical
    notation
    isbetter, youcanvisualize.
  • Via M2M
    Read-Only
    Auto-Layout
    Drill-Down
  • Textual DSLs
    vs.
    Graphical
    vs.
    Visualization
  • Graphviz
  • Prefuse
  • I am aware of the usefulness of graphical notations.
    I am exaggerating here a little bit.
    But: We’ve been building software with text only for a long time. We know it works.
  • 2.5
    TheoryandConcepts
    Tooling
  • Severaltoolsavailable.
    Example:oAWXtext
  • SpecifyGrammar
  • AntlrGrammarandParserisgeneratedfromthisspecification
  • Generated Metamodel
  • SpecifyConstraints
  • Generated Editor
  • Generated Editor
    Code Completion
  • Generated Editor
    Syntax Coloring
    Custom KeywordColoring
  • Generated Editor
    RealtimeConstraintValidation
  • Generated Editor
    Customizable
    Outlines
  • Generated Editor
    Code Folding
  • Generated Editor
    Goto Definition
    Find References
    Cross-File References
    Model as EMF
  • Generated Editor
  • XtextOverview
  • GrapVizOverview
  • GrapVizTrafo Code
  • Another Tool…?
    OSLO
  • Another Tool…?
    Jetbrains MPS
  • Another Tool…?
  • 2.6
    TheoryandConcepts
    Model Validation
  • Grammaris not
    expressiveenough
  • More Validation
    Rules Required:Constraints
  • Simple Examples:
    Name-Uniqueness
    Type Checks
    Non-Nullness
  • More ComplexExamples:
    Version Compatibility
    Overall completeness
    Quality of Service
  • context Interface ERROR"interface names must start "+ "with a capital I":
    name.startsWith("I");
    context Component ERROR"Qualified Name "+qualifiedName()+" must be unique" :
    allComponents(). select( c | c.qualifiedName() == qualifiedName() ) .size == 1;
    context Attribute ERROR"no type defined: "+
    type.name:
    visibleInstancesOfType(this, DataType) .contains(type);
    context Connector ERROR"target must be provided port":
    ProvidedPort.isInstance( u);
  • Precondition I:
    AlgorithmforConstraint
  • Precondition II:
    All Data Available
  • 2.7
    TheoryandConcepts
    Generating Code
  • Sincewealready
    have a formal model….
  • Generate API
    MapsArchitecturalConceptsto
    Implementationlanguage (non-trivial!)
  • Implementation
    Implementationonlydepends onthegeneratedprogramming model API
  • Programming Model
    Generated API + Usage Idioms
    Completely Technology-Independent
  • Runtime Infrastructure
    Select based on fit wrt. toarchitectural
    conceptsand non-functionalrequirements
  • Glue Code
    Aka Technology Mapping Code
    Maps API toselectedplatform
  • Glue Code
    ContainsConfiguration Files forPlatform
    Mightrequire „mix in models“
  • SeveralPlatforms
    Different Platforms, not Languages
    Support forScaling (non-functionalreq)
    Testing!
  • Benefits:More EfficientImpl.
    Technology Independent
    Consistence/Quality
    Architecture-Conformance
  • Code Gen Sequence
    1) Generate API
    2) Write Impl Code
    3) Select Platform
    4) GenerateGlue Code
  • Separate Models
    forstuff relevant forthe API
    vs. system/deploymentstuff
  • 2.8
    TheoryandConcepts
    Architecture Analysis Tools
  • SoftwareTomographySonarJ
    Structure 101
    … andthelike
  • How do youdescribe
    Architecture?
  • Constraint-Driven:
    AssemblePackagesinto Components
    Definelayers/columns
    Defineand Check valid Dependencies
  • You do not get a
    waytodefineandexpress architectural
    abstractionsbeyondthose!
  • Dependency Analysis
    Anti Pattern Detection
    Metrics
    [Trend Analysis]
    [Visualization]
  • Police Approach:
    Detect Problems
    After thefact!
  • Anti Pattern Detection
    Metrics
    Usefulformanuallywrittenpartsofthesystem
  • Dependency Analysis
    Usefulformanuallywrittenpartsofthesystem
    Constraintsgenerated
    fromthe model.
  • 2.9
    TheoryandConcepts
    Standards,UML and ADLs
  • FormalArchitecture Description is not new:
    ADLs, UML
  • But allofthoseuseexisting, genericlanguages!
  • Thismissesthepoint!
  • Tryingto express yourspecificarchitecturewithpredefinedabstractionsis not useful!
  • Youwanttobuild a languagetocaptureyourownarchitecturalabstractionsasyourlearnthings.
  • Wherearestandardsuseful?
  • Peoplehavetolearnarchitecturalconcepts anyway.
  • Is UML with a profilestill a standardlanguage?
  • On whichmetaleveldo I wanttostandardize?
    M2 (UML), M3 (MOF)?
  • Isn‘t a DSLbased on MOFas „standard“ as a profilebased on UML?
  • UMLProfilesinstead?
    You‘llthinkmoreabout UML-itiesthanyourownconcepts
  • UMLProfilesinstead?
    Tool integrationissues (repository, diff/merge, versioning)
  • UMLProfilesinstead?
    Tools areoftencomplex, heavyweight, bloated. Acceptance limited.
  • UML Generally Useless?
    No. UML canbeusedfordocu-mentation (sequencediagrams, eg)
  • NB: Youcando all ofthiswith UML!
    However, myexprienceshowsitismuchlessproductiveand agile.
    Ifyouhave a UML-basedorganization, use UML.
  • 2.10
    TheoryandConcepts
    Why not use a 3GL?
  • ArchitecturalAbstractionsarenotfirstclasscitizensin 3GLs
  • Classescanrepresenteverything– especiallywithannotations (metadata)
  • Problems:shoehorningintoclasses; like UML
  • Problems:annotations = stereotypes
  • Problems:limited analyzability(not a model)
  • Problems:mix architecturalandimplementationconcerns
  • 2.11
    TheoryandConcepts
    My Notion of Components
  • DefinitionsAbound:
    A Building Block forsoftwaresystems
  • DefinitionsAbound:
    Something withexplicitcontextdependenciesonly
  • DefinitionsAbound:
    Something thatcontainsbusinesslogicandruns in a container
  • My Understanding:
    Smallestarchitecturally
    relevant building block
  • My Understanding:
    Black Box - Architecturally
  • My Understanding:
    All architecturally relevant aspectsspecifieddeclaratively (model)
  • My Understanding:
    Analyzable, Composablebytools
  • My Understanding:
    Running in container, providestechnicalservicesatcomponentboundary
  • The specificstructureandmetadataof a componentdefinedspecificallyforeachproject/system/ productline
  • Thisiswhatwe do withthe …
    Architecture
    DSL
  • 2.12
    TheoryandConcepts
    ComponentImplementation
  • By Default:
    ManualyProgrammingagainsttheProgMod API
  • Alternatives:
    Generate, based on config
  • Alternatives:
    Generate, based on config
    State Machines
  • Alternatives:
    Generate, based on config
    State Machines
    RuleLanguages + Engines
  • Alternatives:
    Generate, based on config
    State Machines
    RuleLanguages + Engines
    Specific DSL
  • Tointegratebehavior, createspecificabstractionsin thearchitecture DSL.
    ADD THE CASCADING STUGGF HERE
  • Note:
    A lotofimplementationcanbegeneratedautomatically (noconfig) fromthe model
    (persistence, serialization, …)
  • 2.13
    TheoryandConcepts
    The Roleof Patterns
  • Pattern:
    Proven solutions to recurring problems, including their applicability, trade-offs and consequences.
  • Architecture Patterns:
    “Blueprint” for a specific architectural style
  • Architecture Patterns:
    “Blueprint” for a specific architectural style
     Inspires the concepts for architecture DSL
  • Design Patterns:
    More concrete, moreimplementation-relatedthanarch. patterns
  • Design Patterns:
    More concrete, moreimplementation-relatedthanarch. patterns
    Typicallydoes not end up in the DSL, but …
  • Design Pattern:
    More concrete, moreimplementation-relatedthanarch. patterns
    putintothecodegenerator
  • It‘s not thecodegeneratorwhodecidesabouttheimplementationof a pattern – it‘s still the (generator) developer!
    A Pattern ismorethanthesolution UML diagram!
  • 2.14
    TheoryandConcepts
    Documentation
  • The DSL andthe „programs“ aredocumentation.
  • So I don‘thavetowrite…
    … moredocs?
  • Not quite.
  • 1
  • Grammaris a good formal definition, but not a teachingtool.
  • Grammaris a good formal definition, but not a teachingtool.
    Tutorials
  • Tutorials:
    ArchitecturalConcepts (Meta Model)
    Howtousethelanguage
    Howtousetheprogramming model
    (Howtogeneratecode)
    (Howtoaddmanualcode)
  • Tutorials:
    ArchitecturalConcepts (Meta Model)
    Howtousethelanguage
    Howtousetheprogramming model
    (Howtogeneratecode)
    (Howtoaddmanualcode)
    ExampleDriven!
  • 2
  • Grammardescribeswhatthearchitecturelookslike.
  • Grammardescribeswhatthearchitecturelookslike.
    But: Whyisitthatway?
  • Rationales
  • Rationales
    ConceptualArchitecture
    RelatetoGrammar
  • Rationales
    ConceptualArchitecture
    RelatetoGrammar
    Technological Decisions
    Non-Func. Req.
  • 2.15
    TheoryandConcepts
    ExpressingVariability
  • Different Variants
    ofthe System
    for different customers.
  • How do I
    express
    this in themodels?
  • Negative Variability:
    Conditionallytakingsomethingaway
  • Negative Variability:
    Conditionallytakingsomethingaway
    Feature Models
  • componentDelayCalculator {
    provides default: IDelayCalculator
    requires screens[0..n]: IInfoScreen
    providesmon: IMonitoringfeature monitoring
    }
  • componentDelayCalculator {
    provides default: IDelayCalculator
    requires screens[0..n]: IInfoScreen
    providesmon: IMonitoringfeature monitoring
    }
  • namespacemonitoringStufffeature monitoring {
     
    componentMonitoringConsole {
    requires devices:[*]: IMonitor
    }
    instance monitor: MonitoringConsole
    dynamicconnectmonitor.devicesquery {
    type = IMonitor
    }
     
    }
  • Positive Variability:Conditionallyaddingsomethingto a minimal core
  • Positive Variability:Conditionallyaddingsomethingto a minimal core
    Aspects
  • namespacemonitoring {
     
    componentMonitoringConsole …
    instance monitor: …
    dynamicconnectmonitor.devices …
     
    aspect (*) component {
    providesmon: IMonitoring
    }
    }
  • componentDelayCalculator {

    }
    componentAircraftModule {

    }
    componentInfoScreen {

    }
  • componentDelayCalculator {

    }
    componentAircraftModule {

    }
    componentInfoScreen {

    }
    componentDelayCalculator {

    providesmon: IMonitoring
    }
    componentAircraftModule {

    providesmon: IMonitoring
    }
    componentInfoScreen {

    providesmon: IMmonitoring
    }
    aspect (*) component {
    providesmon: IMonitoring
    }
  • Weaver isgeneric:
    workswith all (container)
    model elements
  • aspect (*) <type>
    all instancesoftype
    aspect (tag=bla)<type>
    all instanceswith tag bla
    aspect (name=S*) <type>
    all instanceswhosenamestartswith S
  • AO + Features
    namespacemonitoring feature monitoring {
     
    componentMonitoringConsole …
    instance monitor: …
    dynamicconnectmonitor.devices …
     
    aspect (*) component {
    providesmon: IMonitoring
    }
    }
  • 2.16
    TheoryandConcepts
    PLE – Big Picture
  • Configuration
    vs. Customization
  • Customization
    vs. Configuration
  • Customization
    vs. Configuration
  • MDSD - Thumbnail
  • MD-PLE - Thumbnail
    fewer!
  • MD-PLE: Models
  • MD-PLE – Thumbnail II
    moreoptions
  • Variability in theprocesschain
    Transformation AO (oAW)
  • Variability in theprocesschain
    Generator AO (oAW)
  • 2.17
    TheoryandConcepts
    Process
  • Iterate!
  • Iterate!
    Concepts
  • Iterate!
    Concepts
    GrammarConstraints
  • Iterate!
    Examples
    Concepts
    GrammarConstraints
  • Iterate!
    Generator
    Examples
    Concepts
    GrammarConstraints
  • Iterate!
    Generator
    Code Completion, etc.
    Examples
    Concepts
    GrammarConstraints
  • Reviews
    still necessary!
  • Reviews
    still necessary!
    but simplified, becausearchitectureismore explicit
  • Architect
    (Team)
    ArchitecturalConcepts
    Grammar, Constraints
    Examples
    Programming Model
  • Tool
    Engineer
    Editor Customization
    (API) Code Generator
  • Platform
    Expert
    Glue Code Generator
  • Application
    Developer
    Uses Language
    Generates Code
    Writes Manual Code against gen. API Code
  • New
    language
    foreach
    system?
  • Common
    Base?
  • Reusable
    Language
    Modules?
  • LanguageFamily?PLE?
  • AnotherTalk!
  • 2.18
    TheoryandConcepts
    Underlying Concepts
  • Abstraction
  • Formalize
  • LimitFreedom
  • Declaration
    Implementation
  • Notation
  • Types & Instances
  • Viewpoints
  • Hierarchical
    Decomposition
  • Translate
  • Handle
    Crosscuts
  • Go Meta
  • Reflection
  • Automate
  • Orthogonality
  • Contracts
  • IsolateTechnology
  • Don‘t
    Overspecify
  • Make Explicit
  • Platforms
  • THE END.
    Thankyou.
    Questions?