inf5120 ”modellbasert systemutvikling” ”modelbased system ... · pdf...

1Telecom and Informatics

INF5120”Modellbasert Systemutvikling”

”Modelbased System development”

Oppsummering 19.05.2005

Arne-Jørgen Berre


INF5120 - Forelesninger - 2005 E: (Enterprise Architecture bok) C: (COMET kompendium)E: (Enterprise Architecture bok) C: (COMET kompendium)

1. Intro to System Modeling, Background: OO and UML, RUP, MDA, SOA 2. Enterprise Architecture - Enterprise Modeling (E1) 3. Business Modeling – COMET methodology (C1) 4. Requirements Modeling – COMET methodology (C2) 5. Enterprise and IT architecture (17. February – DnD Software’2005) 6. UML 2.0 and UML SysML profile (UML 2.0 ref.) 7. Software Architecture – and architecture modeling of services/components (E2) PIM modeling and PSM mappings/transformations (MDA, MOF, QVT) (C3) 8. Model transformation tools & QVT Modelware (JOEA) 9. Agile Methods and Agile Modeling, (17. March) – F8 (E4) 10. Architectural Patterns, Design Patterns and Refactoring (E2-a) 11. Non-functional requirements–OCL and Quality of service (JOEA) 12. Service Oriented Architectures – UML profile, Interoperability and Data

Architectures (E3) (E2-b) 13. Usability and human centered design (E5) 14. Aspect Oriented Computing, Agents, … other PSMs 15. Product Lines – Families, Frameworks, Reuse, RAS, Teamwork (E6) 16. LAST: Summary – preparation for exam


Velkommen til INF5120 “Modellbasert Systemutvikling” Modellbasert Systemutvikling Tidligere: Modellering med objekter

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

Forelesere: Arne-Jørgen Berre Brian Elvesæter Jan Øyvind Aagedal Birger Møller Pedersen, Øystein Haugen Email: [email protected]

Øvingsansvarlige: Audun Strand, Kai Fredriksen Email: [email protected]

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

mailto:[email protected]

mailto:[email protected]


PENSUM

Pensumartikler. Jan Øyvind Aagedal, Summary of IEEE 1471 Alistair Cockburn, Structuring Use Cases with Goals Product Families, MDA4ProductFamilies

Egeninnsats til lesing om UML notasjon (ref. også INF2120)

(UML undervises nå i fag på lavere grad) – se egen støttebok (Ref. forelesning om UML 2.0)

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

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


Book: A Practical Guide to Enterprise Architecture J. McGovern et.al., ISBN 0-13-141275-2, 290 pages, Prentice Hall, 2004 1: Systems Architecture 2: Software Architecture 3: Service Oriented Architecture 4: Software Product Lines 5: Methodology overview 6: Enterprise Unified Process 7: Agile Architecture 8: Agile Modeling 9: Presentation Tier Architecture 10: Usability and User Experience 11: Data Architecture 12: Thought Leadership (ikke pensum)


A Practical Guide to Enterprise Architecture (subject grouping for INF5120)

1: Systems Architecture and Enterprise Architecture (E1) 5: Methodology overview 6: Enterprise Unified Process

2: Software Architecture (E2) 3: Service Oriented Architecture

11: Data Architecture and Interoperability (E3) 7: Agile Architecture (E4)

8: Agile Modeling 9: Presentation Tier Architecture (E5)

10: Usability and User Experience 4: Software Product Lines (and Reuse) (E6) 12: Thought Leadership(ikke pensum)


A Practical Guide to Enterprise Architecture – Annexes (ikke pensum) A: Business case B: Practical Considerations C: The 7 habits of an Agile EA D: Models E: References F: Additional Reading G: Future Books


COMET - MDD for Interoperable Systems (Berre/Elvesæter/…) – kompendium*ny versjon februar 2005 oppgradert til UML 2.0 og UML profil for bruk av IBM Software Modeler tool 1: Introduction to COMET – overview/motivation/nutshell 2: An introduction to Interoperable Systems and Enterprise

Architecture 3: An introduction to the sample application 4: Business Modeling and Enterprise Architecture 5: Requirements (Actors and use cases, User Experience ) 6: Architecture 7. Components and Design 8: Extra-functional requirements, Quality of Service 9: Implementation 10: Phases: Inception, Elaboration, Construction, Transition 11: Additional. Topics: Testing, Repository, Tool environment A: Profiles and stereotypes, B. MDA environment & tools/UMT ++ X: Web Structure support COMET


Eksamen

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

09-12 (3 timer) – Mandag 6 . juni, 2005


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 metoder

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


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. MngmtConf. Mngmt

EnvironmentEnvironment

Supporting Workflows

Disciplines


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


0,1

0,1

Deployment

User ServiceTierUser ResourceService Tier LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

User Dialog Tier Com

ponent Infrastructure &W

orkflow Engine (M

icroworkflow)

User ServiceD

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


OMG Model-Driven Architecture (MDA)

www.omg.org/mda


Enterprise Architecture and Enterprise Modeling Enterprise Architecture (preface) Systems Architecture (e1, p. 1-16) Canaxia example – ref. Exercise/Oblig (App.A, p.269-271) Methodologies (e5, p111-140, SEI/CMM, Zachman) Architectural Frameworks (C4ISR-AF, RM-ODP, MAF,

TOGAF/DODAF, …. Enterprise Unified Process (e6, p.141-147) Enterprise Modeling Next: COMET Methodology


References

Enterprise Unified Process: http://www.enterpriseunifiedprocess.info/

SEI (CMM) etc: http://www.sei.cmu.edu/sei-home.html

EA: http://www.enterprise-architecture.info/ Software Architecture: www.wwisa.org

http://www.enterpriseunifiedprocess.info/

http://www.sei.cmu.edu/sei-home.html

http://www.enterprise-architecture.info/



http://www.wwisa.org/


Architecture agility – ref. McGovern/Stevens pentagon and

Metis POPS*

EnterpriseArchitecture

Organisational

Business Goals

Qualities

Processes

Practices

- systems


MAF

MAFE MAFIS

MAFIS/C2IS(M2IE)

MAFE/C2(M2EE)MAFE/LOG MAFIS/LOGIS

Modenhetsnivå:

Konsept Utvikling Operasjonelt Planlagt

MAFIIA

MAFIIA/D(Defence)

MAFIIA/H(Healthcare)

MAF: Modelbased Architectural description FrameworkMAFE – for Enterprises

MAFIIA – for Information IntegrationMAFIS – for Information Systems (technical information infrastructures)

MAF*: Example EA approachModelbased Architectural description Framework(utviklet av SINTEF i samarbeid med Forsvaret)


MAF

Principle of conformance

Conceptual Model for Architecture Descriptions

Experience Well Framework

Principle of consistency

Principle of realisation

Principle of specialisation

Terminology

Methodology

Structuring rule

Language mapping

Architecture description framework 1..n1..n

11

11

1..n1..n

1..n1..n

1..n1..n

11

11

1..n1..n

1..n1..nArchitecture description

typology

0..n

Principle

0..n


Data

User Interface

Business Service

User Service

Legacy

Com

ponent InfrastructureService

Entity

DataService

Service

Entity

Ente

rpris

eIn

fost

ruct

ure


Ente

rpris

eAr

chite

ctur

e D

escr

iptio

nIn

fost

ruct

ure

Arch

itect

ure

Des

crip

tion

NameTitle

NameTitle

NameTitle

Infostructures

Processes

OrganisationActors

InformationProcesses

Organisation

Information

RulesPolicies

Software

Information

Databases

Processing

Business

MAFE

COMET


Enterprise Unified Process (EUP)

The Enterprise Unified Process : Extending the Rational Unified Processby Scott W. Ambler, John Nalbone, Michael J. Vizdos

Chapter 6

and book to be published (early 2005)


EUP Lifecycle


DnD Software’ 2005 – torsdag 17. februarHotell Radisson SAS Scandinavia, kl. 1410 – 1700 – Sesjon Virksomhetsarkitektur i praksis

Avslutning17.00

Felles oppsummering/paneldebatt16.10

Integrasjon som konkurransefortrinnBjarne Birkeland, Walenius Wilhelmsen

Virksomhetsarkitektur i Hafslund som motor for forretningsutvikling. Thomas Pettersen, Hafslund og Thorsten Keller, CommITment AS

15.35

Integrasjon ved hjelp av EAI-verktøyDomstolene, NN

Erfaringer med virksomhetsarkitektur i Forsvaret. Ole Øyvind Stenslie, Forsvaret

15.00

Altinn – for sikker innrapporteringHenning Normann, Accenture

Dynamic Enterprise ArchitectureMarlies van Steenbergen

14.10

Integrasjonsarkitektur i praksis Are Torgersen, IBM Certified og Håkan Hallberg, Zystems

Vägen mot ett Enterprise Data WarehouseArne Svedberg, FöreningsSparbanken

13.25

Fra stormaskinarkitektur til integrasjonsarkitekturSigmund Evjen, Rikstrygdeverket og Bjørn Arne Berge, Accenture

DNV Maritime City plan – et EA prosjekt i DNV MaritimeJørgen Kadal, Det Norske Veritas

12.35

EAI Tools - Principles and the tool marketChris Sluman, OpenIT Ltd., UK

12 trinn for å bygge en EAPaul Fosland, Computas AS

10.55

14. IT-arkitektur for integrasjon13. Virksomhetsarkitektur i praksis

Hva er egentlig arkitektur ?Ole Gustavsen, Snøhetta og Bjørn Nordmoen, Western GECO

10.05

Kaffepause09.45

Søkemotorer og Informasjonsforvaltning – Strategiske muligheter både fra virksomhet og IT-arkitektur perspektiver. Bjørn Olstad, FAST Search and Transfer

09.05

Velkommen09.00

For studenter i INF5120 er deltakelse fra kl. 1410 gratis,(- spesialpris for hele dagen kr. 750,- i stedet for kr. 4250,-)


UML 2.0 (F6)

Ref. Forelesning av Øystein Haugen, Birger Møller-Pedersen om UML 2.0 nyheter


INF5120Modellbasert systemutvikling

COMET Introduksjon COMET Business Modelling

Forelesning 03.02.2005Brian Elvesæter


COMET

Model-based models expressed in the Unified Modelling Language (UML 1.x, 2.0)

Architecture the fundamental organisation of a system (...) [IEEE 1471]

description Framework principles and guidelines

for technical InfoStructures technical information systems and information infrastructure

=> A framework for how to describe the architecture of a technical InfoStructure in terms of UML models, more specifically a Business Model; a Requirements Model; a Component Model; and a Platform Model

Architectural Description of theArchitecture of the technical IS.


Annexes, Templates & Profiles COMET Annexes

UML 2.0 revisions to the COMET Business Model COMET_Method_v2-5_Annex1_BM.pdf

UML 2.0 revisions to the COMET Requirements Model COMET_Method_v2-5_Annex2_RM.pdf

UML 2.0 revisions to the COMET (Service) Architecture Model COMET_Method_v2-5_Annex3_SAM.pdf

UML profiles for RSM UML Profile for Business Modelling

COMET Business Profile.epx UML Profile for Requirements Modelling

COMET Requirements Profile.epx UML Profile for (Service) Architecture Modelling

COMET Service Architecture Profile.epx Model templates for RSM

Template for Business Model COMET Business Template.emx

Template for Requirements Model COMET Requirements Template.emx

Template for (Service) Architecture Model COMET Service Architecture Template.emx


PlatformModel


Bus

ines

s D

omai

nSy

stem

Dom

ain


Concepts& Artifacts

Processes

Actors

Business (Context)Model Goal Model

ComponentModel

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel -> WARM


Deployment

User ServiceTierUser ResourceService Tier LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

User Dialog Tier Com


orkflow Engine (M

icroworkflow)

User ServiceD

omain

Business Service

Dom

ainUserInterfaceTier

RARA

LA


Component structure



•Work element analysis•Use case refinement and BCE


Use case model

RequirementsModel


PrototypeSystem Boundary

*BCE Model

COMET


Scoping statements

The context statement, which defines the scope and positions this business model in its context.

Vision for change, which describes what to improve, the motivation (i.e. what is wrong with the current situation), a description or indication of what the improvements might be and a gap analysis.

Risk analysis, which identifies the business and technical risks related to a development project for the proposed Product.

\SINTEFOSLTC_40309. DIVERSEKundeKursUiO-IfiINF5120CombineWeb0101dev_proc_webactivities�mcontext_statement.htm

\SINTEFOSLTC_40309. DIVERSEKundeKursUiO-IfiINF5120CombineWeb0101dev_proc_webactivities�mvision.htm

\SINTEFOSLTC_40309. DIVERSEKundeKursUiO-IfiINF5120CombineWeb0101dev_proc_webactivities�m isk.htm


Context statement

Methods and Techniques The first step in developing any business model is to identify and

record the names of all people who will have an interest in having the Product developed or in its use, the business stakeholders, together with the nature of their interest.

The following are examples of business stakeholders who should be involved: people who will authorise funding for development of the Product; people who are responsible for design and maintenance of the

business processes to be supported by the Product; people who will use the Product; people who will be responsible for the acceptance of the Product; people who will be responsible for managing operation of the Product.


Vision for change

The vision for change document is short and describes what the Product will be and why it is needed. It will consist of some or all of the following elements: General business/product vision and goals, including background

explaining why the Product is needed; Business opportunities and business benefits; Product description and technical business vision – how the

Product might be deployed and used; Presentation material summarising the above.


Platform specificmodel

UMT Config model


Bus

ines

s D

omai

nSy

stem

Dom

ain


Concepts& Artifacts

Processes

Actors

Businessmodel Goal Model

Architecturemodel

Requirementsmodel


Otherrequirements

Prototype

Visionfor change

Context statement

Risk analysis

Business Process & RoleModelWARM


PIM Data Types

Context Businessmodel Goal Model

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel


0,1

0,1

System Boundary

*

***

Deployment

User ServiceTierUser ResourceService Tier

LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

User Dialog Tier

Com


orkflow Engine (

Microw

orkflow)

User

ServiceD

omain

Business Service

Dom

ain

UserInterfaceTier

RARA

LA


Component structureand internal design



•Subsystem grouping and BCE (Combine Ref Arch)

•BM analysis


BCE Model


Use Case Model

The Use Case Model describes the system in terms of Actors use cases scenario descriptions

It is defined a use case template to be used as a vehicle for developing the use case model.

Non functional requirements are part of the use case model as these kinds of requirements are associated with use cases according to the use case template.

General non functional requirements that applies for the whole system are associated with the system boundary which is also included in the use case model.


System Boundary

Goals Identify and describe system boundaries, main services and

actors. Assure a common understanding of the system and its purpose. Identify interactions between the system and its environment.

Deliverables A high-level UML Use case diagram showing the system, the

actors and the actors responsibilities. A detailed UML Use case diagram showing the system boundary,

the actors and their main use cases. Each use case should be numbered for later reference. General extra requirements that applies for the complete system

are associated with the System Boundary



Description The Use Case Scenario Model digs into the identified use cases

and describes these in detail. A use case template is used as a vehicle for this detailing.

Goal Capture and understand the requirements.

Deliverables Detailed UML use case diagram and descriptions in accordance to

Use case template Activities

Fill in Use Case template


RA Analysis

Description The Reference architecture analysis is the first step in modeling the

architecture, representing an intermediate step between Business Domain Models and the architecture design.

The Reference Architecture Analysis is developed using a use case driven approach and provides the basis for the initial development of the Architecture Model.

Goal The Reference Architecture Analysis should provide the link between

analysis and design, in particular the link between the Use Case Model and the Architecture Model.

Deliverables Detailed use case diagram with subsystem grouping. Updated use case descriptions following the use case template. First version of the Component Structure using the bus architecture

pattern (Object Management Architecture pattern).


Prototype

Goals Reduce technical risk Reduce the possibility of user dissatisfaction

Deliverables Prototype

Activities Identify technical uncertainties Develop UI, get feedback from users Test the risky technical solutions

Start prototyping early Useful for the common understanding Best way of communicating with end user? Useful for identifying more user requirements


Architecture Model (1)

The Architecture Model describes the overall architecture of the system and its partitioning into components.The collaborations of components are described in terms of component interactions, component interfaces and protocols.

The Architecture Model describes two aspects of the system; the static (structure) and dynamic (behavior). The structural model describes the components, their dependencies, and

internal component design the dynamic model describes the component interfaces, interactions and

protocols. The Architecture Model is a platform independent system

specification. To keep platform independence there is a need to be able to also specify the data types in a platform independent way.


Architecture Model (2)

Component Structure and Internal Design describes the static aspect of the system. It includes the overall architecture and the partitioning into components as well as the internal design of the components.

Interface and Interaction Specification describes the dynamic aspect of the system. It specifies the interfaces and related protocols as well as defining the interactions between sets of components necessary to provide the required services. The abstract object model provided through an interface are also described

PIM data types contains the platform independent data-types used in the architecture model.

\SINTEFOSLTC_4030�. PROSJEKTERCOMBINEProjectRepositoryWebCombineWeb0101dev_proc_webactivitiesadmpim_datatypes.htm


Component Model Structure


SurveyBooking Model Structure


Model Structure in RSM


Reference Architecture Analysis


RA Analysis: Methods and techniques (1/2) Recall the Reference Architecture with associated tiers and

component types. Analyse the System Boundary part of the Use Case Model with

regards to the Reference Architecture. The System Boundary correspond to the boundaries of the component of concern for the actual project, typically an Application Component.

After the identification of this "main" component the next step is to analyze the System Boundary Model with respect to its set of use cases and actors.

Divide the System Boundary Model into a set of subsystems. Each subsystem will cover a collection of the System Boundary use cases.

the subsystems are non-exclusive, implying that a use case might be part of more than one subsystem. The result of this task is a functional decomposition of the main component, with reiterated versions of the use cases.

\SINTEFOSLTC_40309. DIVERSEKundeKursUiO-IfiINF5120V2005_webarchs_web eference_architecture.htm

\SINTEFOSLTC_40309. DIVERSEKundeKursUiO-IfiINF5120V2005_webdev_proc_webactivities m equirements.htm

\SINTEFOSLTC_40309. DIVERSEKundeKursUiO-IfiINF5120V2005_webdev_proc_webactivities m equirements.htm


Component structure andinternal design (1) Goals

The software (and hardware) architecture represented by the components that comprise the product. A sound system architecture implies that the system is divided into comprehensible units that represent meaningful groupings with respect to some criteria

The dependencies between components (includes provided and required interfaces)

The internal design of each of the components. A component is recursive in its nature, thus a component might comprise new components. E.g an Application Component typically comprise a set of Tool Components, Business Service Components and Resource Service Components.


Component structure andinternal design (2) Methods and techniques

Use the reference architecture to define components. The following factors might be considered when dividing into components:

Functionality and usage Technology. This includes for instance network, component infrastructure, reference architecture, distribution mechanisms, operating system, data storage frameworks and standards that should be followed.

Organization. This might be how the development team is organized or how the end users are organized.

Distribution. This includes distribution of people, equipment and systems; both at build time (development environment) and run time (end user environment).

Use case actors. Grouping of functionality based on the actors of the use cases.

Physical nodes. What nodes are available, and where are the locations. Parallel work. How to subdivide to maximize parallel work, this might be

during in build time and/or run time. Non-functional requirements such as availability, performance, security,

scalability etc.


Interface and interactionspecification Goals

Capture and describe component interface and interactions. The behaviors of the architectural elements should be understood and described, i.e. how components collaborate.

Methods and techniques Inputs are the Business Model the Requirements Model (including

the Reference Architecture Analysis and the work element analysis). In addition the Component Structure and Internal Design defines the component structure and interface dependencies and is obviously an important input to this model.

Vice versa the Interface and Interaction Specification is key input to the Component Structure and Internal design as these models forms different viewpoints of the same part of the full model and thus, have to be fully consistent.


PIM data types


INF5120Modellbasert systemutvikling

Arkitektur, MDA, model transformations, QVT

Forelesning 10.03.2005Jan Øyvind Aagedal


OMG Model-Driven Architecture (MDA)

www.omg.org/mda


Model transformation

PIM

PSM

Transformation

Platformmodel

Target metamode

l

Source metamode

l


MDA: Model transformation

Model transformation = the process of converting one model into another model of the same system

Mapping = a set of rules and techniques used for this modification


Model Transformation

PIM(e.g. UML subset)

<<metamodel>>PIM

(e.g. UML subset)

<<metamodel>>

PIM2PSMScheme

<<transformation >>PIM2PSMScheme

<<transformation >>

<< Model instance >>PIM

<< Model instance >>PIM

implementation

<<source>>

PSM(e.g. EJB UML profile)

<<metamodel>>PSM

(e.g. EJB UML profile)

<<metamodel>>

<<target>>

<<source>> <<target>>

<<generated>>

Transformation(e.g. MOF QVT)

<<metamodel>>Transformation

(e.g. MOF QVT)

<<metamodel>>

<< Model instance >>PSM

Transformation


MOF QVT (Query/View/Transformation)

På et høyt nivå Definisjon av mekanismer for spørring og transformasjon av ”ting”

som er lagret (eller kan lagres) i MOF Det ligger i grunnen i navnet, Query Views Transformations Omtales som en svært viktig del av OMGs MDA visjon

En del av MOF 2.0 spesifikasjonsarbeidet i OMG Pågår enda, forhåpentligvis ferdig i april MOF 2.0 Facility / Object Lifecycle RFP, MOF 2.0 IDL RFP MOF

2.0 Versioning RFP MOF 2.0 Query / View / Transformation RFP, MOF 2.0 Core

Vi fokuserer på T’en i QVT, altså transformasjoner, men de andre delene trengs for dette


ATL

The Atlas Transformation Language (ATL) is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations as described by the MDA™ approach.

It is not QVT, but similar and with the corresponding functionality A transformation model in ATL is expressed as a set of transformation

rules. The recommended style of programming is declarative. OCL is used to expression constraints on rules

Guards (constraints) on the entry point for a rule Different kinds of M3/M2 (meta)metamodel technology supported:

Netbeans MDR and EMF Ecore => Can use either EMF or MDR metamodels as input and output.

Can also be used to produce textual output.


The Simple Class Metamodel

Arg

-name :String

Variable

-name :String-visibility :String-type:String

Method

-name :String-body:String

JavaClass

-name :String+description:String

args+

*attributes+ * methods+

*

type+

Package

+name:Stringclasses+

*

Created with Poseidon for UML Community Edition. Not for Commercial Use.

ModelElement

+name:String

Classifier Attribute Association

ClassPrimitiveDataType

source+

target+

type+

attributes+ *

Model

+name:String

modelElements+

*


The Simple JavaClassMetamodel

A Simple Example : Two metamodels


A Simple Example – A transformationmodule SM2JM;create OUT:JavaModel from IN:ClassModel;rule Model2Package { from inputModel : ClassModel!Model to javaPackage : JavaModel!Package ( name <- inputModel.name, classes <- inputModel.modelElements )}

rule ClassToClass { from inputClass : ClassModel!Class to javaClass : JavaModel!JavaClass ( name <- inputClass.name, description <- 'Java class ' + inputClass.name, variables <- inputClass.attributes )}

[Result of another rule]


Simple example cont.rule Attribute2Variable { from clAttribute : ClassModel!Attribute to javaAttribute : JavaModel!Variable ( name <- clAttribute.name, type <- clAttribute.type.name, visibility <- 'private' )}

helper context ClassModel!Class def : getJavaClassName() : String = self.name + 'Impl';


17. marsStore aud

Moderne systemuviklingsmetoderAgile/Smidige metoder

Kjetil Jørgensen-Dahl, Objectnet og

Arne-Jørgen Berre, SINTEF, UiO


MDA andModel Transformation

in Practice

Jon Oldevik, SINTEFjon.oldevik at sintef.no


Introduction

The Atlas Transformation Language (ATL) is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations as described by the MDA™ approach.

It is not QVT, but similar and with the corresponding functionality A transformation model in ATL is expressed as a set of transformation

rules. The recommended style of programming is declarative. OCL is used to expression constraints on rules

Guards (constraints) on the entry point for a rule Different kinds of M3/M2 (meta)metamodel technology supported:

Netbeans MDR and EMF Ecore => Can use either EMF or MDR metamodels as input and output.

Can also be used to produce textual output.


The Simple Class Metamodel

Arg

-name :String

Variable

-name :String-visibility :String-type:String

Method

-name :String-body:String

JavaClass

-name :String+description:String

args+

*attributes+ * methods+

*

type+

Package

+name:Stringclasses+

*


ModelElement

+name:String

Classifier Attribute Association

ClassPrimitiveDataType

source+

target+

type+

attributes+ *

Model

+name:String

modelElements+

*


The Simple JavaClassMetamodel

A Simple Example : Two metamodels


A Simple Example – A transformationmodule SM2JM;create OUT:JavaModel from IN:ClassModel;rule Model2Package { from inputModel : ClassModel!Model to javaPackage : JavaModel!Package ( name <- inputModel.name, classes <- inputModel.modelElements )}

rule ClassToClass { from inputClass : ClassModel!Class to javaClass : JavaModel!JavaClass ( name <- inputClass.name, description <- 'Java class ' + inputClass.name, variables <- inputClass.attributes )}

[Result of another rule]


Simple example cont.rule Attribute2Variable { from clAttribute : ClassModel!Attribute to javaAttribute : JavaModel!Variable ( name <- clAttribute.name, type <- clAttribute.type.name, visibility <- 'private' )}

helper context ClassModel!Class def : getJavaClassName() : String = self.name + 'Impl';


ATL language structure

ATL File Ends with ’.atl’

ATL module Header Import Rules Helpers

module SM2JM;create OUT:JavaModel from IN:ClassModel;

import strings;

helper context CM!Class def : helperName() : String = … some OCL expression

rule Model2Package { from inputModel : ClassModel!Model to javaPackage : JavaModel!Package (

… )}


Model to Text tool – “MOFScript”

Model to Text TransformationMeeting WP5 requirements

Jon Oldevik, SINTEF

http://www.sintef.no/default.aspx?id=114


MOFScript-tool overview

Eclipse plugin Lexical Editor for MOFScript

Syntax might be changed according to new requirements + OMG Model 2 Text process

Tailored for generating code from models Procedural language

Rules are functions which are called explicitly. Might be integrated with a rule matching mechanism Few control structures – simple language

Execution Engine in Eclipse Interpreted execution Generation of output files based on model input

Supports EMF metamodels and models


Language structure Textmodule

Entrypoint rule

Rules

textmodule UML2Java (in uml:uml2)

uml.Model::main () { self.ownedMember->forEach(p:uml.Package) { p.mapPackage() }}

uml.Package::mapPackage () { self.ownedMember->forEach(c:uml.Class) c.mapClass()}


Language structure

Properties

Files

Iterators

Conditional statementss

Escaped output

c.elements->forEach(e:db:DBTable) { // statements.}

file (c.name + “.java”)<% package %> c.ownerPackage.name <%;%>println (“public class” + c.name);

if (c.name != “Car”) { // statements}

<%public class %> c.name <% extends

Serializable {%>

property packageName = “org.mypackage”var myVariable


General Responsibility Assignment

Software Patterns.

Responsibility assignment.1. knowing (answering)2. or, doing

Guidance and evaluation in mechanistic design.

1. Expert1. Expert2. Creator2. Creator3. Controller3. Controller4. Low Coupling4. Low Coupling5. High Cohesion5. High Cohesion6. Polymorphism6. Polymorphism7. Pure Fabrication7. Pure Fabrication8. Indirection8. Indirection9. Don’t Talk to 9. Don’t Talk to StrangersStrangers


GOF (Gang of Four) 23 Patterns

Creational Patterns (5) Abstract FactoryAbstract Factory, Builder, Factory Method, Prototype,

Singleton Structural Patterns (7) Adapter, Bridge, CompositeComposite, Decorator, Façade,

Flyweight, Proxy Behavioural Patterns (11) Chain of responsibility, Command, Interpreter,

Iterator, Mediator, Memento, ObserverObserver, State, Strategy, Template method, Visitor


Simplify with OCL

Flight Airplane

CargoFlightPassengerFlight

PassengerPlane CargoPlane11

0..*0..* 11

0..*0..*

0..*0..*11flights


Diagram with invariants

context Flightinv: type = #cargo implies airplane.type = #cargoinv: type = #passenger implies airplane.type = #passenger

10..*Flight Airplane

type = enum{cargo, passenger}

type = enum{cargo, passenger}

flights


OCL has a great number of predefined operations on the collections types.

Syntax:

collection->operation

Collection operations


The collect operation

Syntax:collection->collect(elem : T | expr)collection->collect(elem | expr)collection->collect(expr)

Shorthand:collection.expr

The collect operation results in the collection of the values resulting evaluating expr for all elements in the collection


The select operation

Syntax:collection->select(elem : T | expression)collection->select(elem | expression)collection->select(expression)

The select operation results in the subset of all elements for which expression is true


The forAll operation

Syntax:collection->forAll(elem : T | expr)collection->forAll(elem | expr)collection->forAll(expr)

The forAll operation results in true if expr is true for all elements of the collection


The exists operation

Syntax:collection->exists(elem : T | expr)collection->exists(elem | expr)collection->exists(expr)

The exists operation results in true if there is at least one element in the collection for which the expression expr is true.


effectiveness productivity safety

quality in use

satisfaction

ISO 9126 - Software Product Quality

Quality in use - related to a specific context of use effectiveness – the capability of the software product to enable users

to achieve specified goals with accuracy and completeness in a specified context of use.

productivity – the capability of the software product to enable users to expend appropriate amounts of resources in relation to the effectiveness achieved in the specified context of use.

safety – the capability of the software product to achieve acceptable levels of risk of harm to people, business, software, property or the environment in a specified context of use.

satisfaction – the capability of the software product to satisfy users in a specified context of use.


ISO 9126 - External and Internal Quality Metrics Irrespective of

context of usefunctionality reliability usability efficiency maintainability

external and internal quality

portability

suitabilityaccuracyinteroperabilitysecurity

functionality compliance

maturityfault tolerancerecoverability

reliabilitycompliance

understandabilitylearnabilityoperabilityattractiveness

usability compliance

time behaviourresource utilisation

efficiency compliance

analysabilitychangeabilitystabilitytestability

maintainability compliance

adaptabilityinstallabilityco-existencereplaceability

portabilitycompliance


Problem space Solution space InfrastructureQoSreqs. QoS

support

Quality of Service Support in Software Architecture

QoS support in applications requires methodological support during development How to match requirements and solutions

QoS is a concern of many stakeholders Need to include QoS specification into architectural descriptions

The Big Question: How do changes affect the agreed upon QoS?


UML QoS profile

<<metamodel>>

QoSFramework

< < m et aclas s > >: :U M L2 .0 : :Lo g i ca l V i e w ::U M L::C l a s s e s : :K e rn e l : :C l a s s

< < m et ac las s > >: :U M L2 .0 : :Lo g i ca l V i e w ::U M L::C l a s s e s : :K e rn e l : :P a ck a g e

< < m et ac las s > >: :U M L2 .0 : :Lo g i ca l V i e w ::U M L::C l a s s e s : :K e rn e l : :P ro pe rty

< < s t e reo t y p e> >Q o S C h a ra cte r i s t i c

< < s t e reo t y p e> >Q o S C a te g o ry

< < s t e reo t y p e> >Q o S D i m e n s i o n

< < m et ac las s > >: :U M L2 .0 : :Lo g i ca l V i e w ::U M L::C l a s s e s : :K e rn e l : :S tru ctu ra l F e a tu re

in v ar ian t : b o o lean

s t a t is t ica lQ u alif ie r : Q o SSt a t is t ica lA t t r ib u t ed irec t io n : D irec t io n K in du n it : s t r in g

<<Profile>> QoSProfile

<<realize>>

<<referenceMetamodel>>

UML 2.0

<<metamodel>>

<<ModelLibrary>> QoSCatalog

< < Q o SC a t e go r y > >P e r fo r m a c e

< < Q o SC a t e go ry > >F u n c t io n a lit y

< < Q o SC a t e go r y > >D e p e n d a b ilit y

< < Q o SC a t e go ry > >C o h e re n c e

< < Q o SC a t e go r y > >T h ro u gh p u t

< < Q o SC a t e go r y > >L a t e n c y

< < Q o SC a t e go r y > >E f fic ie n c y

< < Q o SC a t e go ry > >I n t e gri t y

< < Q o SC a t e go r y > >Se c u r it y< < Q o SC a t e go ry > >

R e lia b ilit y< < Q o SC a t e go ry > >

A v a ila b ilit y

< < Q o SC a t e go ry > >D e m an d

<<instantiate>>

<<apply>>

QoS-Aware Model <<instantiate>>

<<apply>>

<<use>>


QoS characteristics

re liability

fault-tolerance

availabi lity

connection-availabili ty processing-availability

<<QoSDimension>>theAvailability

0..1

1

<<QoSDimension>>theFT

0..1

0..1


QoS characteristics example

<<QoSCharacteristic>>reliability

<<QoSCharacteristic>>fault-tolerance

<<QoSCharacteristic>>availability

<<QoSCharacteristic>>connection-availability

<<QoSCharacteristic>>processing-availability

<<description>>Approaches to detect and correct latent errors before they become effective.

<<description>>Measure of the ability of a system to keep operating correctly over time.

<<description>>Capability of the software product to be in a state to perform a required function at a given point in time, under stated conditions of use.

<<description>>context availability::availability-valuepost resultOK : result = time-between-failure / (time-between-failures + time-to-repair)

<<QoSDimension>>theAvailability

0..1

1

<<QoSDimension>>theFT 0..10..1

<<QoSDimension>>

{direction(decreasing)}expected-number-service-failures : integer

<<QoSDimension>>operation-semantic : string

<<QoSDimension>>

{direction(increasing),statisticalQualifier(maximum)}

max-number-of-faults : integer

<<QoSDimension>>

{direction(incresing)}+error-procesing : error-procesings

<<QoSDimension>>

{direction(increasing)}fault-treatment : fault-treatments

<<QoSDimension>>

{direction(decreasing),statisticalQualifier(mean)}

time-to-repair : real

<<QoSDimension>>

{direction(increasing),statisticalQualifier(mean)}

time-between-failures : real

<<QoSDimension>>

{direction(increasing),statisticalQualifier(mean)}

availability-value()


QoS value

<<QoSValue>>Availability_of_remote_server:processing-availability

time-between-failures=10time-to-repair=1


QoS contract

M - ACM << Capability >>

CPDLC Request Link GroundClient

M - ACM << Capability >>

CPDLC Request Link GroundClient AirborneClient

<< QoS contract >> << QoS contract >> context reliability inv

self.expected-number-service-failures = 2 and self.theAvailability.time-to-reapir = 100 and

self.theAvailability.time-between-failure = 2000


Interoperability

Interoperability, key to increase competitiveness of enterprises

The cost of non-interoperability

are estimated to 40% of

enterprises IT budget.

System Implementation budget

Integration40%

Imp. Services

20%

Software10%

Hardware10%

Misc.20%

Interoperability (Def) is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” IEEE Standard Computer Dictionary Carnegie Mellon, Software Technology Roadmap, 2004

Enterprise systems and applications need to be interoperable to achieve seamless operational and business interaction, and create networked organizations European Group for Research on Interoperability, 2002

(Source: the Yankee Group 2001)


IDEAS Reference Model

Business

Knowledge

ICT

Business

Knowledge

ICT

Semantics Semantics

Enterprise A Enterprise B

To achieve meaningful interoperability between enterprises, Interoperability must be achieved on all layers:

Business layer: business environment and business processes Knowledge layer: organisational roles, skills and competencies of

employees and knowledge assets ICT layer: Applications, data and communication components Semantic dimension: support mutual understanding on all layers


Framework 1st Level

Framework 2nd Level ONTOLOGY QUALITY ATTRIBUTES

Semantics Security Scalability Evolution

Business Decisional Model

Business Model

Business Processes

Knowledge Organisation Roles

Skills Competencies

QUALITY ATTRIBUTES

E N T E R P R.

M O D E L

Knowledge Assets

Performance Availability Portability

Application Solution Management

Workplace Interaction

Application Logic

Process Logic

Data Product Data

Process Data

Knowledge Data

Commerce Data

A R C H I T E C T

P L A T F O R M

Communication

IDE

AS R

efer

ence

Mod

el

Telecom and Informatics

The Waves of Client/Server Technology

Base Source: Client/Server Survival Guide, 1994 Robert Orfali, Dan Harkey OS/2 Edition, VNR Computer library + AJB update 2003

1982 1986 1990 1994 1998 1999 2000 2001 2002 2003

FileServers

Database Servers

Groupware

TP Monitors

DistributedObjects

FirstWave

SecondWave

ThirdWave

OMG CORBACOM/OLEWeb/InternettJava

J2EE/EJBCOM+Corba Comp

Server-sidecomponentsc

MDA, WebServices, .NetService-orientedArchitecture SOAP, XMLWSDL/WSFL

FourthWave

FifthWave

P2PGrid

Agents,FIPA


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 serviceSecurity service

Workflowservice

Streaming

Integration service

User InterfaceDocument modelWeb interaction

System/Use Mngt

MultiMedia,QoS


UML Profile for Enterprise Distributed Object Computing Specification

http://www.omg.org/technology/documents/formal/edoc.htm










UMLProfile

Common Model Element

UML Meta-Model

UML Profile

<<subset>>

0..*0..*

(Meta)ModelElement1..*1..*

1..*1..*

0..n

1..1

<<instance>>Additional StandardElement0..*0..*

1..*1..*

"A UML Profile is a predefined set of Stereotypes, Tagged Values, Constraints and notation icons that collectively specialize and tailor the UML for a specific domain or process (e.g., Unified Process profile). A profile does not extend UML by adding any new basic concepts. Instead, it provides conventions for applying and specializing standard UML to a particular environment or domain."


UML Extensions & Profiles





Integration service

UML for EDOC Components- Implementation neutral- CORBA- J2EE/EJB- COM+

UML for EAI(Enterprise Application Integration)- MQSeries- Messages, events

UML for Workflow- Workflow processUML for Real Time

- Capsules, extended state machines- - Quality of Service

UML for Databases- Relational- Object-Oriented

UML for Web & User Interfaces- Web, Genova, XML

UML for Business ProcessModeling- Extended Activities

UML for Legacy Systems- Interface Modeling

UML for Prog. Languages- C++, Java, Smalltalk- Visual Basic, ...


Java 2 Enterprise Edition (J2EE)

UML Profile for EJB


Service-Oriented Architecture


What is a Service-Oriented Architecture (SOA)? “A set of components which can be invoked, and whose

interface descriptions can be published, discovered and invoked over a network.” (W3C) [http://www.w3.org/]

“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) [http://www.cbdiforum.com/index.php3]


Web services

Web services are an accurate instantiation of the service-oriented model.

They adhere to the set of roles and operations specified by the service oriented model.

They have also managed to establish a standardized protocol stack.


Presentation Tier Architecture (kap.9)

Key presentation tier components General design recommendations Design guidelines for interface components


DeferredSynch request

Naming service

Persistence service

ServerComponents

Message

Transaction service

Concurrencyservice

XML

Synchron.request

Event - publish & subscribe





Trading serviceSecurity service

Workflowservice

Streaming

Integration service

User InterfaceDocument modelWeb interaction

System/Use Mngt

MultiMedia,QoS

Abstract Technology Model


MVC – Model View Controller

See web site from Prof. Trygve Reenskaug (UiO-Ifi) http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

The original MVCXEROX PARC 1978-79

… This note actually defines four terms; Editor being the fourth. The Editor is an ephemeral component that the View creates on demand as an interface between the View and the input devices such as mouse and keyboard. (I have later preferred to use the term Tool rather then Controller, and this is the term we have used in later implementations).

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html


UML profile(s) for UI modelling language(s) Develop UML profile(s) for the chosen UI modelling

language(s)

To use standard UML tools to work with UI models

To use standard UML tools to store UI models

User interface models

Tool / Domain models

Concrete user interface

Tool / functionalcode


Definition of UsabilityA concept comprising the effectiveness, efficiency and satisfaction with which specified users can achieve specified goals in a particular environment (ISO 9241 v 2.5)

The extent to which a product can be used effectively, efficiently and with satisfaction by specified users, for specified tasks in specified environments (ESPRIT 5429: MUSIC project)

“ a measure of ease with which a system can be learned or used, its safety, effectiveness and efficiency, and attitude of its users towards it” (Preece, 1994, pp 722)


User-centred design implies

early focus on users, tasks and environment; the active involvement of users; an appropriate allocation of function between user and

system; the incorporation of user-derived feedback into system

design; iterative design whereby a prototype is designed, tested

and modified;


Fra brukersentrert teknikk til UML diagram En oppgave i oppgaveanalysen kan brukes for å

identifisere ett use case (systemnivå). COMET kravmodellering. Use casene kan videre analyseres med tanke på bruker-

opplevelse og grafisk brukergrensesnitt.

En oppgave i oppgaveanalysen kan brukes for å identifisere en aktivitet i en prosess (virksomhetsnivå) COMET virksomhetsmodellering. Aktivitetsgrafene analyseres videre for å identifisere krav til

systemet.


Grunnlaget for brukersentrert evaluering Brukergrupper

Motivasjon IT-kompetanse Erfaring med lignende tjenester (behøver ikke være IKT-baserte) Domenekunnskap Evt. redusert funksjonsevne

Kontekst Sosial/organisasjonsmessig Teknisk Fysisk Opplæring

Primæroppgaver I verden – som ikke utføres gjennom brukergrensesnittet

Oppgaver Målsetninger med UI-interaksjon (fra brukerperspektiv) Frekvens og viktighet av oppgave Oppgaveanalyse


the AOP idea

crosscutting is inherent in complex systems crosscutting concerns

have a clear purpose have a natural structure

defined set of methods, module boundary crossings, points of resource utilization, lines of dataflow…

so, let’s capture the structure of crosscutting concerns explicitly... in a modular way with linguistic and tool support

aspects are well-modularized crosscutting concerns

aspect-oriented programming

See AspectJ


A solution: Aspect-Oriented Modeling (AOM) Localize crosscutting features

Eases understanding of features Eases evolution of features Eases replacement of features with alternatives

Crosscutting features can be isolated if distributed elements have common structural and behavioral features Isolated features are described as solution patterns

Aspect-oriented modeling allows developers to conceptualize, describe, analyze, and communicate crosscutting features separately from other treatments


FIPA – Foundation for Intelligent Physical Agents

Standards Organization http://www.fipa.org/

Agent Platform (AP) Infrastructure for agent environment Key agents for management

Agent Communication Language (ACL) Communicative acts KQML

Content Language The contents of the messages Ontologies

Protocols Message patterns Transport level


JADE (Java Agent DEvelopment Framework) JADE – A FIPA-compliant Agent Framework

http://sharon.cselt.it/projects/jade/ Is a software framework

simplifies the implementation of multi-agent systems Attempts to be very efficient Fully implemented in Java

distributed under LGPL


Agent UML

ABC Customer Sales

Manager

CustomerCashierPurchasefulfillmentprocess

Purchasefulfillmentprocess

Aut

horiz

atio

nre

ques

tpr

oces

s

Pur

chas

efu

lfillm

ent

proc

ess

«agent»

UML 2.0 Composite Structure Diagram


INF5120 – Modellbasert Systemutvikling

F15-1: Software Product Lines & UML

Forelesning 12.05.2005Arne-Jørgen Berre


Conceptual model - market view

Feature Relationshiptype : RelationType = Standard

Quality FeaturevalueDomain : ValueDomainSpec

Functional FeatureFeatureRelationType

StandardRequiresConflictingMutexAlternative

<<enumeration>>

Product Line Scoping

ProductLinename : String

Product

0..n

+parts

0..n

0..* 0..10..* 0..1Members

Featurename : Stringdescription : Stringoptional : boolean = false

0..n0..n

1..* +features1..*

1..*

+product

+features

1..*

{derived from}

Product Tailoring

Selects

Customizes


Article: An MDA®-based framework for model-driven product derivation

1. Introduction2. Conceptual Model for model driven product derivation

1. Market view (Product line view)2. System design view (System Family view3. Product derivation

3. Example4. Summary

Øystein HaugenBirger Møller Pedersen

Jon OldevikArnor Solberg

SINTEF and University of Oslo Norway


Introduction Combining System Family engineering and Model Driven

Development using MDA System family

A set of related products, typically with only slight differences in functionality, quality and/or design E.g. Mobile phone domain

Common architecture and common components Model Driven Architecture (MDA)

OMG’s vision of model driven development Core Technologies (Standards, standardization efforts)

UML, MOF (including Q/V/T (model transformation technology)), CWM Common aims and mechanisms

Improve efficiency and quality of process, product specification and product

By means of abstractions, reuse and code generation (model transformation)


Conceptual model Distinguish market view and

technical system design view Product line (market)

A set of related products, typically with only slight differences in functionality, quality and/or design

Defines market segment Not necessarily technically related

System Family (technical design) A set of related products, typically

with only slight differences in functionality, quality and/or design

Common architecture and common components (technically related)

SystemFamily

ProductLine

0..*

1..*

0..*

1..*

/product line

System0..* 0..10..* 0..1

Derived From

Product

0.. * 0..10.. * 0..1

Members

0..*

1..*

0..*

1..*

realizes


Example, product derivation

AlarmWatch inherits Watch

b:Button[3]

a:Alarm[1]

T:Time[1]

c:Clock[1]

alarm/d:Display[1]

ai:Alarmicon[1]

d:Digit[4]

sx:Soundflash[1]

Time/d:Display[1]

24i:24hicon[1]

ic:DSTicon[1]

dt:Digit[6]

icons

digits

alarm

icons

digits

alarm

icons

digits

input

input

buttons

ticks

ticks

buttonevents


Software Factories:Assembling Applications with Patterns, Models, Frameworks and Tools

Steve CookSoftware ArchitectVisual Studio Enterprise ToolsMicrosoft Corporation


.asmx Files .asmx Code Behinds

Other Code Config Files

Projects and Templates

Assemblies?

Raising The Level Of Abstraction


Raising The Level Of Abstraction

Application Connection Model

Projects and Templates

Assemblies

.asmx Files .asmx Code Behinds

Other Code Config Files


XML, Projects,XML, Projects,Configs, Classes, Configs, Classes,

CodeCode

Deployment Deployment UnitsUnits

packaged intopackaged into

Services, Services, Messages, Applications, Messages, Applications,

EndpointsEndpoints

Abstraction/Abstraction/refinementrefinement

Vertical Mapping - Application Design


Domain Specific Language (DSL)

- Either textual or graphical - Specifically for solution - Models designed with software tools - Write specifications of software - Capture developer intent in computational forms


Process for using the DSL tools


Invitasjon – DnD morgenmøte 31/5

Tid: Tirsdag 31. mai kl. 0800 - 1000 Sted: Sentrum Kongress & Scene 2. etg, Arbeidersamfunnets plass 1, Oslo.

Modellbasert Systemutvikling - Visjon eller virkelighet? Program: Modelldrevet Arkitektur standardisering - MDA fra OMG og Open Source MBSU verktøy v/Arne-Jørgen

Berre, SINTEF og Universitetet i Oslo Microsoft: Software Factory og Domene spesifikke språk - nye muligheter i Visual Studio 2005 sett fra

et utviklerperspektiv v/Marek Vokac, Superoffice IBM: Ettter Rational Rose - hva kommer nå? Utviklingen etter overtakelse av IBM, MBSU nyheter i IBM

Software Modeler og Architect v/Sverre Nymo, IBM ESITO: GENOVA - et norsk MBSU produkt basert på Sysdeco Systemator v/Dag Bøyesen, ESITO Diskusjon - MBSU, Visjon eller virkelighet? Fordeler og ulemper ? – Hvilke tema skal vi presentere og

diskutere videre i faggruppa på vårt eForum, og i seminarer/møter framover.

Påmelding: www.dnd.no - under events, Faggruppe Applikasjonsintegrasjon

http://www.dnd.no/

inf5120 ”modellbasert systemutvikling” ”modelbased system ... · pdf...

Documents