INF5120 ”Modellbasert Systemutvikling” ”Modelbased System ... · INF5120 Modellbasert Systemutvikling 26.01.2006 3 Telecom and Informatics 5 Undervisning Forelesninger Dekker

INF5120 Modellbasert Systemutvikling 26.01.2006

1

1Telecom and Informatics

INF5120”Modellbasert Systemutvikling”

”Modelbased System development”

Forelesning 26.01.2006Arne-Jørgen Berre


Velkommen til INF5120 “ModellbasertSystemutvikling”

Modellbasert SystemutviklingTidligere: Modellering med objekter

http://www.uio.no/studier/emner/matnat/ifi/INF5120/v05/

Forelesere:Arne-Jørgen BerreBrian Elvesæterm.fl.Email: [email protected]

Øvingsansvarlige:Unni Løland, Anne-Marte KrogsrudEmail: [email protected]


2


Forelesning 1 - Introduksjon

Introduction to the lectures and exercisesModeller og modellering – Modellbasert SystemutviklingArchitecture (Systems, Enterprises, Software, ….)Principles of object orientationSystems Architecture and System modelingEnterprise Architecture - overviewUML – notasjon – Strukturell modelleringUML – notasjon – OppførselsmodelleringRUP – (Rational) Unified Process -> COMET/MODIAMDA – Model Driven ArchitectureSOA – Service Oriented Architecture

Diskusjoner...


Målsetning med fagetModellbasert Systemutvikling- gjennom ”modellering med objekter”2 roller:1) Utvikler av en tilpasset utviklingsomgivelse (Software Factory)2) Utvikler av ett system som skal integreres med eksisterende system, (bruker av en tilpasset utviklingsomgivelse).

Objektorientert -> Komponentbasert -> Tjenestebasert utviklingGjenbruk

Lære teknikkerUnified Modeling Language (UML 2.0) – for arkitektur m.m.Meta Modellering og modelltransformering *MDA – Modell drevet arkitektur – med modelltransformasjonerSOA – Service (Tjeneste) orienterte arkitekturer


3


Undervisning

ForelesningerDekker utvalgte deler av teorien i bok og kompendiumHovedboken gir en oversikt som kurset detaljerer videre gjennom forelesninger og øvingerRevidert rekkefølge i innhold 2006:

Først teori om modellering og metamodellering med transformasjonerDeretter anvendelse av dette for en utviklingsomgivelse for å bygge interoperable systemer

ØvingerBruke forelest stoff i praksisCase-oppgave på eksamen

Eksempler i forelesninger og øvingstimer


Praktisk

Forelesninger m/øvinger torsdager 14.15 - 17.00 (Store aud.)

10 studiepoeng, skriftlig, åpen bok eksamenFørst en individuell obligatorisk oppgave i tre deler rundt metamodellering og transformasjoner og bruk av verktøy (13/3)Deretter en obligatorisk gruppeoppgave, med gruppe-presentasjon og innlevering. (2/5)

Papirkopier av foiler på forelesningOppdatert web før neste forelesning (2/2)


4


Revidert rekkefølge i innhold 2006

Kurset vil lære studentene om bruk av meta modellering for å bygge domenespesifikke språk, UML profiler og prosjekt tilpassede utviklingsomgivelser for modellbasert systemutvikling. Del 1 av kurset vil fokusere på teori-basis for, og praktisk anvendelse av, metamodellering. Først rundt boka ”Applied metamodelling” og det tilhørende verktøyet XMF:Mosaic, deretter praktisk rundt OMG standarder for MDA, med bruk av Eclipse og IBM Rational Software Modeler/Architect med modelltransformasjoner med ATL/QVT og MOFScript/MOF2Text. Til slutt sammenliknet med Microsoft Visual Studio DSL (Domain Specific Language) tools

I del 2 av kurset blir dette så benyttet for å lage og deretter anvende en utviklingsomgivelse for Interoperable/Samvirkende systemer, basert på en SOA arkitektur.


INF5120 - Forelesninger - 2006 / Kalender m/ansvarAJB: ArneAJB: Arne--JJøørgenrgen Berre, Berre, BRE: Brian ElvesBRE: Brian Elvesææterter

TNE: Tor TNE: Tor NepleNeple, CH: Christian , CH: Christian HahnHahn , , ØØH: H: ØØystein Haugen, RG: Roy ystein Haugen, RG: Roy GrGrøønmonmo

1: 26/1: Introduction to MBSU, OO and modeling - (AJB)2: 2/2: Introduction to UML 2.0 - (ØH)3: 9/2: Metamodels and UML profiles - D1-4 , A1-4 - (AJB)4: 16/2: Model transformations –, D5-D7 , A5-8 (BRE)5: 23/2: MDD and SOI Patterns – P1-6, ATL, MOFScript (BRE)6: 2/3: MODIA Interoperability Framework, -integration pattern 2 (AJB)7: 9/3: MDD and SOI RSM/RSA Implementation – P7-10 (BRE)8: 16/3: MODIA Enterprise Modeling (Meta model and UML profile), POP* (BRE)9: 23/3: SODIUM example - (CIM->PIM mapping) (RG)10: 30/3: MODIA Architecture Modeling – PIM4SOA (BRE)11: 6/4: PSMs and mappings for SOA/WSDL (TN) D812: 20/4: PSMs and mappings for Agents (CH)13: 27/4: MDI and PIM to PIM mappings (AJB)14: 4/5: MDD Future - MS SF/DSL, Troux tools , UML VM (guests) D9, D1315: 11/5: Method Engineering, MDA Process (BRE) D10-D1216: 18/5: Course Summary (AJB)

Eksamen: Torsdag 1. juni 2006 (tentativt)(minus 13/4: Påske)

Note: OMG: BPM with SOA and MDA (Tuesday 14/3)


5


Pensum litteratur

D – “MDA Distilled”

A – “Applied metamodelling”

P - ”Patterns: MDD using IBM RSA”

ATL - http://www.eclipse.org/gmt/atl/

MOFScript - see http://www.eclipse.org/gmt/mofscript/og http://www.modelbased.net/

MODIA - “MODIA – Model Driven Interoperability and Architecture methodology” – eget kompendium, Mars 2006


INF5120 - Øvinger - 2006 / Kalender

1: 26/1: Introduksjon – Individuelle og gruppe- oppgaver2: 2/2: Modellerings eksempel, RSM verktøy3: 9/2: Modellering UML 2.0 eks. – RSM og XMF:Mosaic verktøy4: 16/2: Lage metamodell i XMF - eksempel5: 23/2: XMF Transformere mellom modeller, XOCL6: 2/3: RSM – Eclipse og bruk av ATL (Enkelt eksempel)7: 9/3: RSM – Eclipse og bruk av MOFScript (Enkelt eksempel)

: 13/3: Levering av Oblig 1 – individuell oppgave 8: 16/3: Lag RSM iht til IBM boka – eksempel + Oblig 1Start gruppe Oblig for eksempel:9: 23/3: Lag MODIA Enterprise Model (meta model, profile)10: 30/3: Lag MODIA Enterprise Model (meta model, profile)11: 6/4: Lag Architecture Model (meta model, profile)12: 20/4: Lag PSM model (UML profil) - lag PIM til PSM mapping (WSDL)13: 27/4: Lag PSM til kode mapping (WSDL)

: 2/5: Levering av Oblig 2 - gruppeoppgave14: 4/5 : Gjennomgang Oblig 2 + eks.oppgaver15: 11/5: Gjennomgang Oblig 2 + eks.oppgaver16: 18/5:– Eks.oppgaver


6


MDA Distilled1. Introduction to Modeling2. MDA Terms and Concepts.3. Building Models.

4. Building Metamodels.

5. Building Mappings.

6. Building Marking Models. 7. Building Languages. 8. Elaborating Models.

9. Building Executable Models.

10. Agile MDA11. Building an MDA Process.12. Executing an MDA Process.

13. The Future of MDA.


Applied Metamodelling

Language-Driven DevelopmentMetamodellingA Metamodelling FacilityAbstract Syntax

Concrete SyntaxSemanticsExecutable MetamodellingMappings

ReuseCases 1 (Aspects), 2 (Telecom), 3 (XAction)


7


Patterns: Model-Driven Developmentusing IBM Rational Software Architect

Overview and concepts of MDDScenario overview (EA, IA, Patterns, Automation)MDD approachMDD project planningMDD solution life cycleMDD in contextDesign patterns for the scenario

Applying MDD with RSA/RSMExtending RSAConclusion- Web material


Krav og forutsetninger

Ingen formelle krav (student ved UiO)Kunnskaper tilsvarende INF-31(41)20, og INF5040 vil være en fordelEgeninnsats til lesing om UML notasjon (ref. ogsåINF2120)(UML undervises nå i fag på lavere grad) – se egnestøttebøker (Vi har en forelesning om nyheter i UML 2.0)


8


MODIA – Model driven development methodology for Interoperable Systems (Berre/Elvesæter/…) – kompendium*ny versjon mars 2006 vil oppgraderes til UML 2.0 og UML profil for bruk av IBM Software Modeler tool + generic/specific part

1: Introduction to MODIA (COMET) – overview/motivation/nutshell2: An introduction to Interoperable Systems and Enterprise Architecture3: An introduction to the sample application4: Business Modeling and Enterprise Architecture5: Requirements (Actors and use cases, User Experience )6: Architecture7. Components and Design8: Extra-functional requirements, Quality of Service9: Implementation10: Phases: Inception, Elaboration, Construction, Transition11: Additional. Topics: Testing, Repository, Tool environmentA: Profiles and stereotypes, B. MDA environment & tools/UMT ++X: Web Structure support COMET


UML 2.0

UML 2.0 og SysML Background and Reference materialSee www.uml-forum.com/specs.htm

Også hos OMG:http://www.omg.org/uml/ (UML)http://www.omg.org/mda/ (MDA)http://www.omg.org/cwm/ (MOF, XMI, CWM)


9


UML 2.0 støttebok:The Unified Modeling Language ReferenceManual, Second edition (ISBN 0-321-24562-8)(J. Rumbaugh, Booch, Jacobsson)

1: UML overview2: The Nature and Purpose of Models3: UML Walkthrough4: Static View5: Design View6: Use Case View7: State Machine View8: Activity View9: Interaction View10: Deployment View11: Model Management View12: Profiles13: UML EnvironmentX: Reference Alphabetical definitions/examples, page 129-685


Anbefalt UML bok

UML 2 and the Unified Process : Practical Object-Oriented Analysis and Design (2nd Edition) (Addison-Wesley Object Technology Series) (Paperback)

by Jim Arlow, Ila Neustadt


10


other UML reference books

UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition covering UML 2.0)by Martin Fowler, Kendall Scott

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (3rd Edition)by Craig Larman

Object-Oriented Modeling and Design with UML (2nd Edition) , J. Rumbaugh et. al., 2005, ISBN: 0130159204

Aspect-Oriented Software Development with Use Cases (Addison-Wesley Object Technology Series)by Ivar Jacobson, Pan-Wei Ng, 2005


Støtte-bok: Software Factories, Assemblingapplications with patterns, models, frameworks and tools J. Greenfield & al (Microsoft), J. Wiley, ISBN: 0-471-20284-3, 630 pages

Introduction (Example=Construction Tools Incorporated)Dealing with Complexity, Dealing with Change, Paradigm Shift, Software Factories

Models and patterns – Programming with models (MDD-I)Language Autonomy – Families of languages (MDD-II)Systematic Reuse - Software Product Lines (Reuse/Families)Platform Based Abstractions – Components and services (Assembly/Orchestration)Mappings and Transformations – Generating Implementations (Generative Programming)

A Software Factory Example - FAQ

www.softwarefactories.com Nesten valgt som pensumbok, men littfor Microsoft-orientert


11


Eksamen

Case-basert oppgave (ref. tidligere eksamen)Alle skriftlige hjelpemidler er tillatt

09-12 (3 timer) – tentativt, torsdag 1 . juni, 2006


Modeller og modellering


12


Dealing with Complexity – and Change

Working at the right level of abstraction

OO dealing with complexityobjects -> components -> services *SOADesign by contract, role compositionAspect-oriented programmingUse of patternsVisual Modeling (MDA)Arkitektur


Diskusjon

Modellbasert Systemutvikling

Sett dere sammen i grupper a 2-3 og diskuter begrepet:

Modellbasert systemutvikling (5 min)


13


Objektorientert Modellering


PhaseClass

TraditionalSA/SD/ERA

SA-based OO

ERA-based OO

Hybrid SA/ER-based OO

SA - Yordon SD - Page Jones

ERA - Chen ER-Rel.db - 3NF

OO RT SA - Wards

OOA/OOD - Coad/Yordon

OMT - Rumbaugh et. al

Fusion - HP

OOAD - Booch (93 w/C++)

HOOD - ESAOOSD - Wasserman

SD-basert OO

OO-based

RDOOD - Wirfs-Brock et. al

CRC-cards - Cunningham

OOram - Reenskaug et. al

ANALYSIS DESIGN DETAILED DESIGN

OOAD - Martin/Odell

OSDL-92 - CCITT/Bræk et. alOOSE/ObjectOry - Jacobson

Ada(C++)-based

SDL-based OO

UML (96)Booch/OMT/ObjectOry

OOAD metoderOOAD metoder

Catalysis, Syntropy, SOMA, OBA, BHS, ...


14


Evolution of the UMLEvolution of the UML

Booch ´91

Booch ´93

Unified Method 0.8

UML 1.0

OMT - 2

OMT - 1 OOSE

UML 0.9 & 0.91

OOPSLA ´95

June ´96 & Oct ´96

Submission of UML 1.1 to OMGfor adoption, Sept ´97

Other methods

publicfeedback UML Partners’

Expertise

UML 1.1 (Sept. 1997)

Taskon,SINTEF

UML 1.4UML 2.0

(2004)


Hvorfor UML: Systemkompleksitet

SubsystemSubsystem

Enhet

System

Enhet

Omgivelse


15


aRealWorldPhenomena

Mental modelSystem

Manifest Model

ObjectsA model is created for a purposeA model is never completeWe think in multiple modelsThe world is rarely hierarchical

Hvorfor UML: Felles beskrivelse


Evolution of methodologies

UML1.0

UML1.1

UML1.2

UML1.3

UML1.4

OMT

Objectory

Booch

UML Components

Catalysis

OOram

KobrA

COMET

UML4EDOC

UML2

Pulse

UP

RUP

Notation

Process 2002

2001

1995-1999

2000


16


Objektorientering, Begreper og konsepter

Basis tankerObjekt ModelleringBasis konsepterKlassifisering / Typer / skaping av “individer”InnkapslingDeling og ArvPolymorfi og dynamisk bindingCRC kort


Historisk fokusHistorisk fokus

Kvalitet og Produktivitet

Modellering(mdlg)

Abstraksjon ogModularisering

Gjenbruk ogVedlikehold

Funksjonell mdlg ( -55 -> )Data mdlg (-60 ->)Simula 1967 +

mdlg av “individer”mdlg av individers

oppgave ( -70 ->)“Oppgave-behandlere”/

“saksbehandlere”

[Oppgavefokus]

SW Engineering +komplekse systemer

fra velprøvete delerAbstrakte Data Typer1965-KlassifiseringFerdiglagete deler /

komponenter av gitt“type”

[Eksterne egenskaper]

Biblioteker ( -55 -> )Komponenter og

rammeverk ( -80 -> )Patterns (-90 -> )

Vedlikehold kostbartØkende kompleksitet /

størelse.

[modulbygging]

“Splitt og hersk”: store, komplekse problemer deles opp i et settav små, selvstendige og enkle problemer. (i ett eller flere trinn!)


17


“Skandinavisk” Modellerings-perspektiv“Skandinavisk” Modellerings-perspektiv

A program execution is regarded as a physical model, simulating the behaviour of either a real or imaginary part of the world.A physical model consists of objects, each object is characterized by attributes and a sequence of actions. Objects organize the substance aspect of phenomena, and transformations on substance are reflected by objects executing actions.Objects may have part-objects. An attribute may be a reference to a part object or to a separate object. Some attributes represent measurable properties of the object.The state of an object at a given moment is expressed by its substance, its measurable properties and the actions going on then. The state of the model is the states of the objects in the model.

(Fra Simula)


Basis for OO TeknologiBasis for OO Teknologi

Kvalitet og Produktivitet

Modellering Abstraksjon ogModularisering

Gjenbruk ogVedlikehold

Objekt Modell

Klassifisering/Instansiering Innkapsling Deling

Arv Polymorfisme


18


Objektorientert ModellObjektorientert Modell

En objektorientert modell er en (simulerings) modell som består avsamspillende objekter i interaksjon med hverandre.

En parallell i “virkeligheten”: en bil. Den består av et settdeler / komponenter som samvirker i et gitt mønster.( ikke alle påvirker alle andre direkte; interaksjonene/samspilleter diktert av oppgaver og hensikt)


OO - SYN PÅ VERDENOO - SYN PÅ VERDENSAMSPILLENDE OBJEKTER. Hvert Objekt:

har klart ansvarvet om samarbeis partnereneer robust

Ingen vet om det hele!

Data storage

Internalstorage

Disc

”Monolitisk”


19


System and objectsSystem and objectsA system is a part of the real world which we choose to regard as a whole, separated from the rest of the world during some period of consideration.

A whole that we choose to consider as a collection of objects, each object being characterized by attributes and by actionswhich may involve itself and other objects.

Mental modell

Manifest ModelReal-Worldphenomenon


Object oriented modelingObject oriented modelingaRealWorld-Phenomena roleModels anImplemented

SystemanObjectModel

Manifest ModelReal-Worldphenomenon

Mental modelEnvironmentModel environment

System model


20


Noen ord om Objekt-Orientering

En “filosofi”; en måte å betrakte verden påEn måte å spesifisere systemer påEn måte å designe systemer påEn måte å programmere systemer på

“Alt” er objekterDet som skjer, hender ved at objekter agerer i samspillPeker mot oppdeling, distribusjon og delegering


OO Programming TerminologyOO Programming Terminology

EncapsulationObjectMessageMethodClassInstanceInheritancePolymorphismDynamic (Late) Binding


21


CRC Method, class, responsibilities, and collaborators

Method to learn the most basic OO concepts plus OO “thinking”

“The most effective way of teaching the idiomatic way of thinkingwith objects is to immerse the learner in the "object-ness" of the material. To do this we must remove as much familiar material aspossible, expecting that details such as syntax and programming environment operation will be picked up quickly enough once the fundamentals have been thoroughly understood.”

Technique also very useful during informal and creative analysis and designCreated by Kent Beck and Ward Cunningham,Textronix, 1989


The CRC-Cardan object of paper personalizing the object

Class (Name):

Responsibility: Collaborators:


22


Class, responsibilities, and collaborators

ClassThe class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We urge learners (and spend considerable time ourselves while designing) to find just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment. Responsibilities Responsibilities identify problems to be solved. The solutions will exist in many versions and refinements. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise the design. Again, searching for just the right words is a valuable use of time while designing. CollaboratorsObjects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. For example in Smalltalk, View and Controller operate as near equals while OrderedCollection offers a service with little regard or even awareness of its client.


CRC is Not distinguishing between Object Instance and Class

It is not needed because the CRC-methods physical aspects where each class description becomes an individual physical object, a filing card.This enables the double role of class and object in discussion and analysis with no confusions.

It gives an benefitthe number of concepts to be handled and mastered are kept to a minimum!!


23


Card Playing Rules - Notation

Every card represents possibly several objects at the same time (if needed)Overlapping cards implies close collaborationPositioned above a cardimplies that the object is controlled by this cardA stack of cards implies hierarchical detailing of abstractions - the most abstract card is placed on top and represents the rest of the hierarchy


Card Playing Rules - Process

Regard the cards as objectsStart with the known, evolve towards the unknownEvolve design by 'playing' through scenarios(simulate execution)

pick up the object which is executing and identify yourself with itcreate new objects or responsibilities founded on requirements / needs emerging during simulation. (not for some hypothetical future needs)

Work in a team. A single person will have difficulties finding all requirements or scenarios.


24


UML og ( R )UP

UnifiedModelingLanguage

Process

Convergence TodayUnification leads to “standards”

Convergencein the futureProcess frameworks through consensus

Two parts of a Harmonized Whole


UML Structural Modeling

Class DiagramObject DiagramComponent Diagram (new in UML 2.0)Package DiagramDeployment diagram


25


UML Behavioral Modelling

Use Case DiagramsInteractions

Sequence diagrams (enhanced in UML 2.0)Timing diagrams (new in UML 2.0)Interaction overview diagrams (new in UML 2.0)Communication diagrams (i.e. collaboration diagram)

State machine diagrams (enhanced in UML 2.0)Activity Diagrams (enhanced in UML 2.0)


Different kind of models

Conceptual models

Specification models

Implementation models


26


Utvikling/Trender for UtviklingsprosesserUtvikling/Trender for Utviklingsprosesser

Source: Software Project Management, A Unified Framework, Walker Royce,Addison-Welsey, 1998

FossefallsmodellFunksjonell design-Skalerings-økonomiEgne verktøy100% skredderAd hoc prosessAlltid: over tid/kost

1960-1979

1980-1999

2000-2019?

Prosess forbedringInnkapslings-basert-Skalerings-økonomiUavhengige verktøy30% komp 70% egetGjentakbare prosessUvisst: til tid / kost

Iterativ utviklingKomponent-basertROIIntegrerte verktøy70% komp 30% egetAdmin/Målt prosess-Oftest: til tid og kost


10 viktige prinsipper for modernesystemutvikling

Arkitektur-orientert tilnærmingIterativ livs-syklus prosessKomponentbasert utviklingEndrings-orientert miljø“Round-trip” engineeringModell-basert notasjonObjektiv kvalitets-kontrollØkende detaljeringsgradKonfigurerbar prosess


27


Project ManagementProcess Configuration

RequirementsAnalysis

ArchitectureLevel

Class Level

Implementation

Test

Design

preliminaryiteration(s)

iter.#1

PhasesProcessComponents

Iterations

Elaboration Construction TransitionInception

SupportingComponents

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

Unified Process Framework

Process Workflows

Business ModelingBusiness ModelingRequirementsRequirements

Analysis Analysis DesignDesign

ImplementationImplementationTestTest

DeploymentDeployment

ManagementManagement

Conf. Conf. MngmtMngmt

EnvironmentEnvironment

Supporting Workflows

Disciplines


Faser i livssyklusen

Inception (Begynnelse/unnfangelse)Elaboration (Utdyping av planer, beskrivelse avegenskaper og basis arkitektur)Construction (Bygging av produktet)Transition (Overgang til brukere)


28


Core development disciplines

Requirements

Test

Analysis

Implementation

.Design


Find actors and use cases

Prioritise use cases

Prototype user interface

Detail a use case

Evaluate test

Plan anddesign test

Structure usecase model

Implementclass/ss -u.test

Implementtest

Design ause case

Architecturalanalysis

Design aclass/package

Analyse aclass/package

Analyse ause case

Perform integration tes

Integratesystem

SA

UCS

A

UCE

CE

UID

TE

SI

IT

STArch.Design

Arch.Impl

Perf.sys.test


29


BusinessmodelScoping statements

Platform specificmodel

UMT Config model

Component implementationmodel

Bus

ines

s D

omai

nSy

stem

Dom

ain

Model world Real world

Concepts& Artifacts

Processes

Actors

Goal Model

Architecturemodel

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel -> WARM

Business Resource Model

PIM Data Types

Context Businessmodel Goal Model

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel

Business Resource Model

0,1

0,1

Deployment

User ServiceTierUser ResourceService Tier LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

UserDialog Tier Com

ponent Infrastructure &W

orkflow Engine (M

icroworkflow)

UserServiceD

omain

Business Service

Dom

ainUserInterfaceTier

RARA

LA

Workflow Service Domain

Component structureand internal design

Interface and interaction specification

Busines domain to system domainmapping

•Work element analysis•Use case refinement and RA analysis

Work Element Analysis Model

Use case model

Requirementsmodel

Use case Scenario Model

PrototypeSystem Boundary

*RA Analysis

COMET/MODIAinstantiation


Modellbasert Systemutvikling

OMG MDAMicrosoft DSL

Tidligere case-verktøy (4GL) fokuserte på datamodell-basert systemutvikling, i.e. generering av database og skjermbilder fra ER/NIAM/OR modell.

Nå ny generasjon med mulighet for egenutviklede språk og metamodeller, inkludert bruk av UML


30


OMG Model-Driven Architecture (MDA)

www.omg.org/mda


Linguistic metamodelling

LassieCollie

Class Object

Class

represents represents

linguistic ”instance-of” linguistic ”instance-of”

linguistic ”instance-of” linguistic ”instance-of”

instance-of

ontological instance-of

ontological instance-of

L0 (called M0 in OMG)





31


MDA From 30.000 Feet

Use of platform independent models (PIM) as specificationTransformation into platform specific models (PSM) using tools


MDA From 30.000 Feet

J2EE

.Net

A PIM can be retargeted to different platformsNot the only reason why MDA might be of interest to you…


32


Automation in Software DevelopmentRequirements Requirements Requirements

Implementation

Source in ageneral-purposelanguage, e.g.,

Java or C++

Implementation

(may generatecode in

Java or C++)

Source indomain-specificlanguage (DSL)

Implementation

(may generatecode in

Java or C++)

Source indomain-specificlanguage (DSL)

High-level spec(functional andnonfunctional)

Manuallyimplement

Manuallyimplement

Manuallyimplement

Compile Compile Compile

Compile Compile

Implement withInteractive,automatedsupport


MDA and Agile Development

MDA is appropriate for agile developmentModels are not just additional documentation artifacts, but they are the actual sourceInstant feedback through simulation / rapid code generationModel-based testingDomain-specific modeling languages may simplify communication with your customer


33


The Waves of Client/Server TechnologyThe Waves of Client/Server Technology

Base Source: Client/Server Survival Guide, 1994, 1996Robert Orfali, Dan HarkeyOS/2 Edition, VNR Computer library + AJB update 2004

1982 1986 1990 1994 1998 1999 2000 2001 2002 2004

FileServers

Database Servers

Groupware

TP Monitors

DistributedObjects

FirstWave

SecondWave

ThirdWave

OMG CORBACOM/OLEWeb/InternettJava

J2EE/EJBCOM+Corba Comp

Server-sidecomponentsc

MDA, WebServices, .NetService-orienteArchitectureSOAP, XML

WSDL/WSFL

FourthWave

FifthWave

P2PGridAgents,

FIPA SOA


DeferredSynch request

Naming service

Persistence service

ServerComponents

Message

Transaction service

Concurrencyservice

XML

Synchron.request

Event - publish & subscribe

Data services &Legacy systems

Shared BusinessServices

User services(application/process)

Interaction/Presservices

Trading serviceSecurityservice

Workflowservice

Streaming

Integration service

User InterfaceDocument modelWeb interaction

System/Use Mngt

MultiMedia,QoS

Discovery


34


IIS, ASP+XML/HTML

Web Transactions?

BTS

IntegrationServer, CICS ,..

XML/XSLT

WSDL

Data services &Legacy systems

Shared BusinessServices

User services(application/process)

Interaction/PresservicesSOAP

WS SecuritySAML

UDDI-white

- yellow- greenpages

WebServices

HTTP

BPEL4WS


SOA

ServicesMessagesDynamic discoveryWeb services


35


Service Oriented Architecture (SOA) definition

A set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C).

The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. (CBDI) (www.cbdiforum.com)


Neste forelesning – 2/2 2006

UML 2.0

ved Øystein Haugen UiO/Ifi, (Ansvarlig for sekvensdiagrammer i UML 2.0 standarden)

Deretter starter del 1 av kurset, med vekt påmetamodellering – teori og praksis.

Documents

INF5120 ”Modellbasert Systemutvikling” ”Modelbased System ... · INF5120 Modellbasert Systemutvikling 26.01.2006 3 Telecom and Informatics 5 Undervisning Forelesninger Dekker