1 Telecom and Informatics INF5120 ”Modellbasert Systemutvikling” ”Modelbased System development” Oppsummering 19.05.2005 Arne-Jørgen Berre
1Telecom and Informatics
INF5120”Modellbasert Systemutvikling”
”Modelbased System development”
Oppsummering 19.05.2005
Arne-Jørgen Berre
2Telecom and Informatics
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
3Telecom and Informatics
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]
4Telecom and Informatics
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)
5Telecom and Informatics
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)
6Telecom and Informatics
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)
7Telecom and Informatics
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
8Telecom and Informatics
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
9Telecom and Informatics
Eksamen
Case-basert oppgave (ref. tidligere eksamen) Alle skriftlige hjelpemidler er tillatt
09-12 (3 timer) – Mandag 6 . juni, 2005
10Telecom and Informatics
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, ...
11Telecom and Informatics
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
12Telecom and Informatics
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
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
13Telecom and Informatics
OMG Model-Driven Architecture (MDA)
www.omg.org/mda
14Telecom and Informatics
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
15Telecom and Informatics
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
16Telecom and Informatics
Architecture agility – ref. McGovern/Stevens pentagon and
Metis POPS*
EnterpriseArchitecture
Organisational
Business Goals
Qualities
Processes
Practices
- systems
17Telecom and Informatics
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)
18Telecom and Informatics
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
19Telecom and Informatics
Data
User Interface
Business Service
User Service
Legacy
Com
ponent InfrastructureService
Entity
DataService
Service
Entity
Ente
rpris
eIn
fost
ruct
ure
Model world Real world
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
20Telecom and Informatics
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)
21Telecom and Informatics
EUP Lifecycle
22Telecom and Informatics
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,-)
23Telecom and Informatics
UML 2.0 (F6)
Ref. Forelesning av Øystein Haugen, Birger Møller-Pedersen om UML 2.0 nyheter
24Telecom and Informatics
INF5120Modellbasert systemutvikling
COMET Introduksjon COMET Business Modelling
Forelesning 03.02.2005Brian Elvesæter
25Telecom and Informatics
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.
26Telecom and Informatics
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
27Telecom and Informatics
PlatformModel
Component implementationmodel
Bus
ines
s D
omai
nSy
stem
Dom
ain
Model world Real world
Concepts& Artifacts
Processes
Actors
Business (Context)Model Goal Model
ComponentModel
Visionfor change
Context statement
Risk analysis
Business Process & RoleModel -> WARM
Business Resource Model
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 structure
Interface and interaction specification
Busines domain to system domainmapping
•Work element analysis•Use case refinement and BCE
Work Element Analysis Model
Use case model
RequirementsModel
Use case Scenario Model
PrototypeSystem Boundary
*BCE Model
COMET
28Telecom and Informatics
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.
29Telecom and Informatics
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.
30Telecom and Informatics
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.
31Telecom and Informatics
Platform specificmodel
UMT Config model
Component implementationmodel
Bus
ines
s D
omai
nSy
stem
Dom
ain
Model world Real world
Concepts& Artifacts
Processes
Actors
Businessmodel Goal Model
Architecturemodel
Requirementsmodel
Use case Scenario Model
Otherrequirements
Prototype
Visionfor change
Context statement
Risk analysis
Business Process & RoleModelWARM
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
System Boundary
*
***
Deployment
User ServiceTierUser ResourceService Tier
LS
Legacy
BusinessServiceTier
ResourceServiceTier
Presentation Tier
User Dialog Tier
Com
ponent Infrastructure &W
orkflow Engine (
Microw
orkflow)
User
ServiceD
omain
Business Service
Dom
ain
UserInterfaceTier
RARA
LA
Workflow Service Domain
Component structureand internal design
Interface and interaction specification
Busines domain to system domainmapping
•Subsystem grouping and BCE (Combine Ref Arch)
•BM analysis
Work Element Analysis Model
BCE Model
32Telecom and Informatics
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.
33Telecom and Informatics
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
34Telecom and Informatics
Use case Scenario Model
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
35Telecom and Informatics
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).
36Telecom and Informatics
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
37Telecom and Informatics
38Telecom and Informatics
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.
39Telecom and Informatics
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.
40Telecom and Informatics
Component Model Structure
41Telecom and Informatics
SurveyBooking Model Structure
42Telecom and Informatics
Model Structure in RSM
43Telecom and Informatics
Reference Architecture Analysis
44Telecom and Informatics
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.
45Telecom and Informatics
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.
46Telecom and Informatics
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.
47Telecom and Informatics
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.
48Telecom and Informatics
PIM data types
49Telecom and Informatics
INF5120Modellbasert systemutvikling
Arkitektur, MDA, model transformations, QVT
Forelesning 10.03.2005Jan Øyvind Aagedal
50Telecom and Informatics
OMG Model-Driven Architecture (MDA)
www.omg.org/mda
51Telecom and Informatics
Model transformation
PIM
PSM
Transformation
Platformmodel
Target metamode
l
Source metamode
l
52Telecom and Informatics
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
53Telecom and Informatics
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
54Telecom and Informatics
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
55Telecom and Informatics
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.
56Telecom and Informatics
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+
*
Created with Poseidon for UML Community Edition. Not for Commercial Use.
The Simple JavaClassMetamodel
A Simple Example : Two metamodels
57Telecom and Informatics
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]
58Telecom and Informatics
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';
59Telecom and Informatics
17. marsStore aud
Moderne systemuviklingsmetoderAgile/Smidige metoder
Kjetil Jørgensen-Dahl, Objectnet og
Arne-Jørgen Berre, SINTEF, UiO
60Telecom and Informatics
MDA andModel Transformation
in Practice
Jon Oldevik, SINTEFjon.oldevik at sintef.no
61Telecom and Informatics
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.
62Telecom and Informatics
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+
*
Created with Poseidon for UML Community Edition. Not for Commercial Use.
The Simple JavaClassMetamodel
A Simple Example : Two metamodels
63Telecom and Informatics
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]
64Telecom and Informatics
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';
65Telecom and Informatics
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 (
… )}
66Telecom and Informatics
Model to Text tool – “MOFScript”
Model to Text TransformationMeeting WP5 requirements
Jon Oldevik, SINTEF
67Telecom and Informatics
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
68Telecom and Informatics
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()}
69Telecom and Informatics
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
70Telecom and Informatics
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
71Telecom and Informatics
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
72Telecom and Informatics
Simplify with OCL
Flight Airplane
CargoFlightPassengerFlight
PassengerPlane CargoPlane11
0..*0..* 11
0..*0..*
0..*0..*11flights
73Telecom and Informatics
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
74Telecom and Informatics
OCL has a great number of predefined operations on the collections types.
Syntax:
collection->operation
Collection operations
75Telecom and Informatics
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
76Telecom and Informatics
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
77Telecom and Informatics
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
78Telecom and Informatics
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.
79Telecom and Informatics
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.
80Telecom and Informatics
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
81Telecom and Informatics
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?
82Telecom and Informatics
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>>
83Telecom and Informatics
QoS characteristics
re liability
fault-tolerance
availabi lity
connection-availabili ty processing-availability
<<QoSDimension>>theAvailability
0..1
1
<<QoSDimension>>theFT
0..1
0..1
84Telecom and Informatics
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()
85Telecom and Informatics
QoS value
<<QoSValue>>Availability_of_remote_server:processing-availability
time-between-failures=10time-to-repair=1
86Telecom and Informatics
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
87Telecom and Informatics
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)
88Telecom and Informatics
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
89Telecom and Informatics
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
91Telecom and Informatics
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
92Telecom and Informatics
UML Profile for Enterprise Distributed Object Computing Specification
http://www.omg.org/technology/documents/formal/edoc.htm
93Telecom and Informatics
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."
94Telecom and Informatics
UML Extensions & Profiles
Data services &Legacy systems
Shared BusinessServices
User services(application/process)
Interaction/Presservices
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, ...
95Telecom and Informatics
Java 2 Enterprise Edition (J2EE)
UML Profile for EJB
96Telecom and Informatics
97Telecom and Informatics
Service-Oriented Architecture
98Telecom and Informatics
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]
99Telecom and Informatics
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.
100Telecom and Informatics
Presentation Tier Architecture (kap.9)
Key presentation tier components General design recommendations Design guidelines for interface components
101Telecom and Informatics
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
Abstract Technology Model
102Telecom and Informatics
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).
103Telecom and Informatics
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
104Telecom and Informatics
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)
105Telecom and Informatics
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;
106Telecom and Informatics
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.
107Telecom and Informatics
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
108Telecom and Informatics
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
109Telecom and Informatics
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
110Telecom and Informatics
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
111Telecom and Informatics
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
112Telecom and Informatics
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
113Telecom and Informatics
INF5120 – Modellbasert Systemutvikling
F15-1: Software Product Lines & UML
Forelesning 12.05.2005Arne-Jørgen Berre
114Telecom and Informatics
115Telecom and Informatics
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
116Telecom and Informatics
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
117Telecom and Informatics
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)
118Telecom and Informatics
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
119Telecom and Informatics
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
120Telecom and Informatics
Software Factories:Assembling Applications with Patterns, Models, Frameworks and Tools
Steve CookSoftware ArchitectVisual Studio Enterprise ToolsMicrosoft Corporation
121Telecom and Informatics
.asmx Files .asmx Code Behinds
Other Code Config Files
Projects and Templates
Assemblies?
Raising The Level Of Abstraction
122Telecom and Informatics
Raising The Level Of Abstraction
Application Connection Model
Projects and Templates
Assemblies
.asmx Files .asmx Code Behinds
Other Code Config Files
123Telecom and Informatics
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
124Telecom and Informatics
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
125Telecom and Informatics
Process for using the DSL tools
126Telecom and Informatics
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