Based on material developed in ATHENA (IST-507849) and INTEROP (IST-508011) 5-4. Method Engineering,

Based on material developed in ATHENA (IST-507849) and INTEROP (IST-508011)

5-4. Method Engineering

<Presenter>

<Company>, <Country><E-mail>

2Based on material developed in ATHENA (IST-507849) and INTEROP (IST-508011)

ATHENA Model-Driven Interoperability (MDI) Framework

MDA & Interoperability

Metamodelling

UML Profiles & DSLs

Model Transformations

Method Engineering

Reusable MDI Assets

• Method chunks• Tools and services

• Models and metamodels• Model transformations• DSLs and UML profiles

• Reference examples


Objective

• The objective of this part of the course is to:– Understand what method engineering is.– Learn about method engineering standards and

technologies.– Be able to develop your first method chunk in the

Eclipse Process Framework (EPF) [optional exercise]


Outline

• Method engineering• Standards and technologies

– Software Process Engineering Metamodel (SPEM)– Eclipse Process Framework (EPF)

• Software architecture• ATHENA baseline methodology for software

development and integration• References


Method engineering


Methodology definition (1/2)

• Method– Systematic process, technique or mode of inquiry that is used to

aid in the creation of a satisfactory software product. [Blum94]– Use a method to produce models

• Technique– A specific construct supporting a method

• Process– A sequence of actions leading to some result

• Method include technique and process– CRC method includes CRC technique and CRC process

• Methodology– Body of methods– Meant to support all software development phases


Methodology definition (2/2)

Methodological

processMethod 1

...

Underlying concepts (paradigm)

Process

Method 2

Method n

Techn.

ProcessTechn.

ProcessTechn.

E.g. service-oriented software development


Role of the software process

Product

People Technology

Process

Environment

Environm

entEnv

iron

men

t

The software process ties people and technology together to develop software products in a specific environment.


9 principals for modern software development

1. Architecture-centric– Service-oriented architecture

2. Iterative and incremental process3. Service- and component-orientation4. Manage a highly dynamic environment

– Process: Iterative and incremental– Software system: Easy to change

5. Model-based6. “Round-trip” engineering7. Divide and conquer8. Quality check9. Configurable process


Different process for different type of project

• Process depends on type of system– Brand new system (very rare)– Reengineering (old system exist)– Modification (fixing a major problem)– Adding a new module (functionality)


Some popular methodologies

• UP (RUP)– (Unified Process, Rational unified process)

• KOBRA• Catalysis• Select Perspective• OOram

– Object Oriented Role Analysis and Modelling

• Lightweight methodologies– XP– Adaptive Software Development (ASD)– SCRUM– Crystal Clear


Method

• From the engineering perspective, a method is made up of a set of product models and a set of corresponding process models.

• A product model represents the concepts that are used in the method, relationships between these concepts as well as constraints that they have to satisfy.

• A process model represents the way to accomplish the development of the corresponding product.

Process Model Product Model

1..* 1..*

Relates to11..*

Method


Method engineering process

ModularMethod Description

C1.1 C1.2

C1.3

C1.4 C1.5

C1.1 C1.2

C1.3

C1.4 C1.5

Method chunksRepository

C6.3C6.3C1.1C1.1

CN.5CN.5C4.3C4.3

C1.3C1.3

C4.3

Situational Method

C1.2

CN.3

C2.5

C6.2

C4.1

C1.2

CN.3

C2.5

C6.2

C4.1

Method reengineeringguidelines

Method chunks selection

and assembly guidelines

I. Reengineeringof methods into method chunks

Storage of the method chunks in a method chunks repository

II. Assembly-based Situation-specific Method Construction

Existing MethodNew domain

Experience …


Method chunk

A method chunk is an autonomous and coherent part of a method supporting the realisation of some specific system development or management activity. Such a modular view of methods favours their adaptation, configuration and extension. Moreover, this view permits to reuse chunks of a given method in the construction of new ones.


ATHENA MPCE modelling and executionplatform for method engineering

Use-CaseUsers

Use-Case Developers

Method-ChunkManager

Method-ChunkDeveloper

Use-CaseRepository (UCR)

UserAccessAdmin.

Method ChunkRepository (MCR)

Configurable MCservices and UC solutions

MC adaptation,integration and

validation

Authentication&

Authorization

MC meta-modelsand services

Services Layer

Workplaces


Problems and opportunities

Problems• there exist no authoritative compilations of

method chunks that can be assembled to fit particular project contexts, and such that deliverables of applying one method chunk, can be mapped to inputs of another method chunk

• method chunks are rarely presented as elements that are separated from the problems solved with them, or from the cases used to illustrate their application;

• there is no agreed taxonomy of method chunks;

• methods are in the heads of people, and not yet in the services of systems;

• there are no services to assess which methods to use in a given situation, given the bounded rationality of the engineer, often, sub-optimal methods are selected, making projects expensive and crippling system development

Opportunities• there exists a near-

consensus in the Method Engineering community, on the requirements for a method-chunk repository;

• there exists a wealth of architectural styles (service oriented, agents,...) that can assist the development of an MCR.

• platforms such as ATHENA’s MPCE are offering infrastructural services, needs-awareness and proto-communities that are conducive for the MCR development and test.


Software Process Engineering Metamodel (SPEM)


SPEM (1/3)

• SPEM: Software Process Engineering Metamodel

• Metamodel and UML profile to describe software engineering processes– Identifies the typical concepts of a process (process,

phase, role, model, etc.)– Defines them using UML extensions (stereotypes

applied to various elements: class, use cases, operations, etc.)

– Assigns a characteristic icon to each new item.


SPEM (2/3)

Process Role

Process RoleProcess Role

<<ProcessRole>>

ActivityActivity

Phase Phase<<Phase>>Phase

Activity<<Activity>>

Process

Process<<Process>>

Process


SPEM (3/3)

Work product

Work product<<WorkProduct>>

Work product

UML model

UML model

UML model<<UMLModel>>

Methodology/Guidelines/Patterns

Methodology/Guidelines/Patterns<<Guidance>>

Methodology/Guidelines/Patterns


Eclipse Process Framework (EPF)http://www.eclipse.org/epf/


Eclipse Process Framework

Eclipse Process Framework (EPF) presents a process management tool platform and conceptual framework for authoring, tailoring and deploying development processes.

• First release version 1.0 planned for September 2006


• No common language or terminology between processes – redundancy and inconsistencies.

• Knowledge cannot easily be customized for different projects or new best practices

• No central community or communication framework to facilitate convergence of best practices across domains.

What development teams are facing today


A better approach


Project goals

• Provide an extensible framework and exemplary tools and content for software process engineering– Extensible framework

• Metamodel based on OMG SPEM• Core extensible process tooling framework

– Exemplary and extensible tools• Method and Process authoring• Library management and content extensibility• Configuring and publishing

– Exemplary and extensible process content• Range of software development and management processes

supporting– iterative, agile, and incremental development– applicable to a broad set of development platforms and

applications


High-level architecture


Some tools and services

• Method Authoring– Best practices can be captured as a set of reusable method building blocks as defined in the

meta-model; roles, work products, tasks, and guidance, such as templates, guidelines, examples, and check lists.

– A rich-text editor allows you to document method elements, and graphical views present diagrams showing relevant relationships.

– Reuse is facilitated by allowing you to create a method element as a derivative of another method element through various inheritance-type of relationships.

• Process Authoring– Reusable process building blocks can be organized into processes along a lifecycle

dimension by defining e.g. Work Breakdown Structures (WBSs), and when in the lifecycle to produce what work products in which state.

– The tool allows you to construct reusable chunks of processes through so called capability patterns.

– A capability pattern may for example define how to define, design, implement and test a scenario or a user story, and this pattern can now be reused in a variety of processes.

• Library Management and Content Extensibility– An XMI-based library enables persistency and flexible configuration management as well as

content interchange for distributed client-server implementations.– Method and process content can be packaged into content plug-ins and content packages

allowing simple distribution, management and extensibility of content.• Configuring and Publishing

– A process configuration can be created by selecting a set of content plug-ins and content packages.

– Optionally, an exemplary process configuration can be used as a starting point, and content plug-ins and content packages added or removed from this exemplary configuration.


EPF Concepts to Create Process Frameworks

Process FrameworkResponsible for creating

and modifying work products

Input or output of performing roles

Assigned to a role in a creation of modification

of a work product

Used to define processes, can relate to

other activities to create work flows

Complete process template for a specific

type of project

Express process knowledge for a key

area of interest


EPF Composer

• EPF Composer is a tool platform for process engineers, project leads, project and program managers who are responsible for mainteining and implementing processes for development organizations or individual projects

• Aims to:– provide for development practitioners a knowledge base of

intelectual capital that allows them to browse, manage and deploy content.

– provide process engineering capabilities by supporting processe engineers and project managers in selecting, tailoring, and rapidly assembling processes for their concrete development process.


EPF Composer – capabilities

• Redesigned tools for authoring, configuring, viewing, and publishing development processes.

• Just-in-time generation of publication previews • Management of method content using simple form-based

user interfaces. • Intuitive rich text editors for content description• Processes with:

– breakdown structure editors– workflow diagrams

• Support for many alternative lifecycle models.• Improved reuse and extensibility capabilities. • Reusable dynamically-linked process patterns


EMF Composer – techniques and processes

• Method content– allows structuring of method contents through schemas– method content represented as constructs of roles – input from:

• best practices

• Books or publications

• Standards or regulations

• Homegrown methods

• Processes– Represented as workflows or breakdown structures– Based on different:

• Development approaches

• Development cultures

• Development process representation


Software architecture



• IEEE Std 1471-2000– Recommended Practice for Architectural Description

• Adopted September 2000• For software-intensive systems

– Architecture has too long been focussed on hardware-related issues - IEEE strikes back!

• Common frame of reference for architectural descriptions– Common terminology

• architecture, architectural description, model, view, viewpoint, system, stakeholder, concern, …


Motivations

• Change ctd.– Changes should have limited effects

• Do not want to have unknown ripple effects

– Should define the envelope of change • What is allowed to change without major

consequences

– Good, old SW engineering principles still apply!

• Loose coupling• High cohesion

– Flexibility as a competitive advantage• AT&T vs Sprint

• Complexity– SW systems become complex

– The context becomes complex• Many usage scenarios

– How to convey• Internal structure?• Applicability in different contexts?

• Change– Panta rei

• Requirements, underlying platform, competitors, market, ...

• Two major motivations for explicit architecture– Change and Complexity


Architecture of what?

Virtual enterprise

Business

Software system

Software component

Software object


Enterprise architecture

Decomposition

Bus1Bus2 Bus3

Bus4

SW syst1Actor1 Actor2

SW syst2

Decomposition

Comp1Comp2 Comp3

Comp4

Decomposition

Decomposition

Object1Object2 Object3

Object4

Datatype1Datatype2 Operation1

Datatype3


Concern

has 1..* identifies

1..*

used to cover

1..*

Viewpoint

Library viewpoint

0..1has source

selects 1..*conforms to

establishes methods for1..*

Model1..*

aggregates1..*consists of

1..*participates in

View

1..*organized by

participates in

Architectural description1..*

identifies

1..*is addressed to

1..*is important to Stakeholder

described byhas1..*

Rationaleprovides

Architecturehas aninfluences

inhabitsEnvironment System

1..*fulfills

Mission

Those interests which pertain the system’s development, operation and other aspects that are critical or otherwise important to one or more stakeholders.

Concern

The expression of a systems architecture with respect to a particular viewpoint. Addresses one or more of the concerns of the system stakeholder.

View

Determines the boundaries that define the scope of the system of interest relative to other systems.

Environment RationaleThe Rationale of the architecture.

Library viewpoint

A viewpoint with definition originated elsewhere than in the architectural description.

Developed using the methods established by its viewpoint, consisting of views expressing an architectural description.

Model

Has interest in, or concerns relative to the system.

Stakeholder

Viewpoint

A specification of the conventions of constructing and using a view. A pattern or template from which to develop individual views.

A collection of products to document an architecture.

Architectural description

A collection of components organized to accomplish a specific function or set of functions.

System Architecture

The fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.

A use or operation for which a system is intended by one or more stakeholders to meet some set of objectives.

Mission


described by

identifies

SystemEnvironmentinfluences

inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an

Architecturaldescription

Concern

is important to

has identifies

ViewViewpointused to cover

is addressed to

selects organized by

conforms to

Modelestablishes methods for

participates in

consists of aggregates

participates in

Libraryviewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

IEEE definitions

• Architecture– The fundamental organisation of a system embodied in

its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.

• Architecture description– A collection of products to document an architecture.

• Concern– Those interests which pertain the system’s

development, operation and other aspects that are critical or otherwise important to one or more stakeholders.


described by

identifies


inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an


Concern

is important to

has identifies


is addressed to


conforms to


participates in


participates in

Libraryviewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

IEEE definitions

• Environment– Determines the boundaries that define the scope of the

system of interest relative to other systems.

• Library viewpoint– A viewpoint with definition originated elsewhere than in

the architectural description.

• Mission– A use or operation for which a system is intended by

one or more stakeholders to meet some set of objectives.


described by

identifies


inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an


Concern

is important to

has identifies


is addressed to


conforms to


participates in


participates in

Libraryviewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

IEEE definitions

• Model– Developed using the methods established by its

viewpoint, consisting of views expressing an architectural description.

• Rationale– The Rationale of the architecture.

• Stakeholder– Has interest in, or concerns relative to the system.


described by

identifies


inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an


Concern

is important to

has identifies


is addressed to


conforms to


participates in


participates in

Libraryviewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

IEEE definitions

• System– A collection of components organized to accomplish a

specific function or set of functions.

• View– The expression of a systems architecture with respect

to a particular viewpoint. Addresses one or more of the concerns of the system stakeholder.

• Viewpoint– A specification of the conventions of constructing and

using a view. A pattern or template from which to develop individual views.


Defines evolutionary envelope

• Anticipates likely system changes– Other changes than the anticipated ones are often very expensive and

uncertain

• D’Souza & Wills: “Architecture - The set of design decisions about any system (or smaller component) that keeps its implementers and maintainers from exercising needless creativity.”

• What matters in your system?– You may want to apply relevant patterns to support your concerns

Built for speed:

Built for extensibility: Mediator


From Bran Selic at Summer School on Software

Architecture, Turku, Finland, August 2001

Architectural description


SW architecture, what is it?

• All software has an architecture• The architecture may be hidden or might be even unknown. Its final

(and only) complete instance is the compiled binary file running on its dedicated HW.

• A person cannot understand the architecture from the binary file or by investigating the runtime instance of it. Abstraction is required.

• Abstraction requires human intuition, it is difficult (nearly impossible) to be automated effectively. – The designer is the best person to present an abstraction of his/her

design. – An expert is the best person to present an abstraction of the area of

his/her expertise.– SW developer has to often stretch to the both roles.– How to make a distinction between important and unimportant details?

• Experience, practices• Try not to mix different levels of abstraction, if possible

From Teemu Vaskivuo, VTT Electronics


Abstraction

• A piece of software is a collection of abstract structures. The amount of structures is practically infinite (since there are no limits for performing abstraction)

– It depends on the person creating the abstraction, how many structures he wants to represent.

– It depends on the application, how many structures are needed for a comprehensive design.

• Different structures:– data structures– structures of timely behavior– interaction structures– concurrency structures– transaction structures– component structure– ….

• None of the structures is THE Architecture. They all try to represent a different view on it.

• Run-time structures are not present until the software is executed, and they usually exceed human understanding at lower levels, even in information processing sense

From Teemu Vaskivuo, VTT Electronics


Refinement

• Refinement = a more detailed description that conforms to another (its abstraction)

• Refinement relation = described using a model, defining abstraction observations in terms of realization observations while maintaining certain guarantees of the abstraction

***


Architectures and meta-levels

• Architecture– The fundamental organisation of a system embodied in its components, their

relationships to each other and to the environment, and the principles guiding its design and evolution.


ATHENA baseline methodology for software development and integration


System aspects and integration dimensions

Integration dimensions• System abstraction• Generality• Viewpoint• Composition• Time• Model abstraction

System aspects• Information• Service• Process• Non-functional

Model abstraction

M0 M1 M2 M3

Time

State

Evolution

Composition

(Virtual)Enterprise

Service

Component

Object

System abstraction

Code

PSM

PIM

CIM

Generality

System, Product

Product-line, Framework, Pattern

Viewpoint

Realisation Viewpoint

Specification Viewpoint

Business Viewpoint

Enterprise Viewpoint

Service

Aspects

Information

Aspects

ProcessAspects

Non-

Functio

nal

Aspects


BusinessViewpoint

ComponentViewpoint

View

Architecture descriptionof system under

consideration

View

SecurityConcern

BusinessSecurity Model

BusinessStakeholder

IT ArchitectStakeholder

Component ModelBusiness Model

ComponentSecurity Model

SecurityConcern

Integration using viewpoints


BusinessAnalyst

Bu

sin

ess

Vie

w

ARCADE data

FOFAS bør kunne oppdatere ARCADE

: COP

Actual and planned

draft TASKORG : Frequency requirements

verified list : Frequencies

From Div 6, FO/I, KA mobile avd, LV

final TASKORG : Frequency requirements

temp verified list : Frequencies

Receive ARCADE data

Generate Frequency list

Receive frequency requirements from lower level

Receive COP

Establish/maintain frequency pool

temporary list : Frequencies

Verify security level

Distribute Frequency list

Verify Frequency list

new operationnew campaign

list : Frequencies

new operationDistribute temporary

Frequency list

new campaign

Joint LevelLower Echelon UnitCOPdistributorARCADE system

e.g. BusinessProcess Model

SystemArchitect

Sp

ecif

icat

ion

Vie

w

Deployed Unit #1

InformationService #1Command Center

iProcess

InformationService #2

Deployed Unit #2

iNotification iPublishNotificationService

ProcessingService

Ethernet

Satelite

Radio

InformationInformation

e.g. Service &Interface Model

SoftwareDeveloper

cryptoKeys

Frequencies

Subnet

- nettId- nettType- name- frequency- frequencyChangeTime- newFrequency- frequencyFMprai- frequencyDigPray- areaCode- KVTid- KVTchangeTime

Main frequencies

- emitterType- frequency- emissionType- area(polygon, circle)- class of station(mobile, point-point, ground-air)

Frequency requirements

- emitterType- emissoinType- area- class of station[mobile, point-point, ground-air]- timerange- usage[send, receive,...]- securityLabel[(NATO) unclassified, restricted, confidential, secret]

Decoding list

Telephone DirectoryAddressee

SOICOP

op1

op2e.g.Interaction

&Data

Model

Rea

lisat

ion

Vie

w

NetworkedEnterprise

SoftwareSystem

Legend

BusinessViewpoint

SpecificationViewpoint

RealisationViewpoint

Applicative integration: Three basic viewpoints


Virtual Enterprise

BusinessAnalyst

Business View(e.g. Business Process Models)

ARCADE data

FOFAS bør kunne oppdatere ARCADE

: COP

Actual and planned

draft TASKORG : Frequency requirements

verified list : Frequencies

From Div 6, FO/I, KA mobile avd, LV

final TASKORG : Frequency requirements

temp verified list : Frequencies

Receive ARCADE data

Generate Frequency list

Receive frequency requirements from lower level

Receive COP

Establish/maintain frequency pool

temporary list : Frequencies

Verify security level

Distribute Frequency list

Verify Frequency list

new operationnew campaign

list : Frequencies

new operationDistribute temporary

Frequency list

new campaign

Joint LevelLower Echelon UnitCOPdistributorARCADE system

ProductDeveloper

Product View(e.g. Product structure models)

SoftwareDeveloper

Extending the basic viewpoints

cryptoKeys

Frequencies

Subnet

- nettId- nettType- name- frequency- frequencyChangeTime- newFrequency- frequencyFMprai- frequencyDigPray- areaCode- KVTid- KVTchangeTime

Main frequencies

- emitterType- frequency- emissionType- area(polygon, circle)- class of station(mobile, point-point, ground-air)

Frequency requirements

- emitterType- emissoinType- area- class of station[mobile, point-point, ground-air]- timerange- usage[send, receive,...]- securityLabel[(NATO) unclassified, restricted, confidential, secret]

Decoding list

Telephone DirectoryAddressee

SOICOP

Component View(e.g. Design & Implementation Models)

op1

op2

SystemArchitect

System View(e.g. System Interface Models)

Deployed Unit #1

InformationService #1Command Center

iProcess

InformationService #2

Deployed Unit #2

iNotification iPublishNotificationService

ProcessingService

Ethernet

Satelite

Radio

InformationInformation

Rea

lisat

ion

View

poin

t

(Pla

tform

Spe

cific

)

Specification V

iewpoint

(Platform

Independent)

Con

text

Vie

wpo

int

(Com

puta

tion

Inde

pend

ent)

Product Viewpoint


SOA methodology (overview)

SemanticSpace

Service-OrientedArchitecture Model

Web ServiceExecution Artefacts

AgentExecution Artefacts

BPELExecution Artefacts

P2PExecution Artefacts

Web ServiceSpecification Model

Agent SpecificationModel

BPEL SpecificationModel

P2P SpecificationModel

Model Transformation

UML Profile for Web Services

UML Profile for Agents

UML Profile for BPEL

UML Profile for P2P

Model Transformation

Architecture Specification

A5 & A6 IntegratedExecution Infrastructure

RegistryRepository

Service Wrappers (Enterprise A)

Evaluation & Negotiation of Available Functionality

Enhanced Service Interconnection Bus

Cross-org.

Intra-org.

Existing Enterprise Applications

PublicInfrastructure Services

Service Wrappers(Enterprise X)

Service Wrappers(Enterprise Y)

InternalInfrastructure Services

Process Execution Platform(BPEL)

Goal-orientedAdaptive ExecutionPlatform(Agents)

Goal-orientedAdaptive ExecutionPlatform(Agents)

ActiveModel Platform(AKMii)

ActiveModel Platform(AKMii)

Legend

Message-OrientedPlatform(MQSeries)

Message-OrientedPlatform(MQSeries)

Server-side Component Platform(.NET, J2EE)

Server-side Component Platform(.NET, J2EE)

ComposedWebServicePlatform(WebServices)

Business Process/Agent

Active (Business) Model

Web/Server Component

Middleware Process/Agent

Middleware Component

Adaptive Distributed Resource Mgt Platform (P2P)

Deployment

UML Profile for SOA• Information• Service• Process• QoSR

efer

ence

On

tolo

gy

annotated with

Model to Model Transformation

Model to TextTransformation

OWLOntology

annotatedwith

annotatedwith

EnterpriseModel

UML Profile for POP*• Process• Organisation• Product• …

Model to ModelTransformation

Business Requirements

Analysis

annotated with


SOA methodology (detailed)

Method chunks for SOA andWeb Service Interoperability

ReferenceOntology

annotatedwith

WSDLDocument

OWL-SDocument

BPELDocument

BDIPlan

XSDDocument

WS-?Document

ATHENA A5Web ServiceExecutionInfrastructure

Model Registry (A6)

Oth

er C

om

pan

y

Internal Service Interconnection Bus

Wrappers

Leg

acy A

pp

licatio

ns

Execution

Service

Service

Composition

Neh

em

iah

(A

2)

JA

CK

Mediation

AR

ES

(A

3)

Evaluation

ServiceModels

PlatformModels

ContractModels

Compo-sition

Models

Neg

otiatio

n

ExternalRegistry

Pu

blish

in

gIn

teractio

n

...

Brokering

Bro

kerin

g T

oo

l (A

5)

OWLOntology

annotatedwith

UML Profile for POP*• Process• Organisation• Product• …E

nte

rpri

seM

od

el

ProcessView

OrganisationView

ProductView

…View

1

1


Business Requirements

AnalysisS

OA

Mo

del

InformationView

ServiceView

ProcessView

QoSView

UML Profile for SOA• Information• Service• Process• QoS

annotatedwith

XMLMessage

ServiceDescription

ProcessExecution

QoSDescriptionW

eb S

erv

ice

Mo

del

UML Profile for Web Services• XML Message (XSD)• Service Description (WSDL)• Process Execution (BPEL)• QoS


1

1..*


Web

Ser

vic

eD

ocu

men

ts

1..*

1..*


SOA methodology (Web services)

Method chunks for SOA andWeb Service Interoperability

ReferenceOntology

annotatedwith

WSDLDocument

OWL-SDocument

BPELDocument

BDIPlan

XSDDocument

WS-?Document

ATHENA A5Web ServiceExecutionInfrastructure

Model Registry (A6)

Oth

er C

om

pan

y

Internal Service Interconnection Bus

Wrappers

Leg

acy A

pp

licatio

ns

Execution

Service

Service

Composition

Neh

em

iah

(A

2)

JA

CK

Mediation

AR

ES

(A

3)

Evaluation

ServiceModels

PlatformModels

ContractModels

Compo-sition

Models

Neg

otiatio

n

ExternalRegistry

Pu

blish

in

gIn

teractio

n

...

Brokering

Bro

kerin

g T

oo

l (A

5)

OWLOntology

annotatedwith

SO

AM

od

el

InformationView

ServiceView

ProcessView

QoSView

UML Profile for SOA• Information• Service• Process• QoS

annotatedwith

XMLMessage

ServiceDescription

ProcessExecution

QoSDescriptionW

eb S

ervi

ce M

od

el

UML Profile for Web Services• XML Message (XSD)• Service Description (WSDL)• Process Execution (BPEL)• QoS


1

1..*


Web

Ser

vice

Do

cum

ents

1..*

1..*


References


References (1)

[ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST-507849). http://www.athena-ip.org/

[ATHENA A6 2006] ATHENA A6, "D.A6.3: Model-driven and Adaptable Interoperability Framework", ATHENA IP, Deliverable D.A6.3, 2006.

[ATHENA A6 2006] ATHENA A6, "D.A6.4: Model-driven and Adaptable Interoperability Infrastructure", ATHENA IP, Deliverable D.A6.4, 2006.

[INTEROP] INTEROP, "INTEROP Home Page", INTEROP NoE. http://www.interop-noe.org/

[INTEROP TG6 2005] INTEROP TG6, "State of the Art: Exploration of Methods and Method Engineering Approaches", Deliverable DTG 6.1, 2005.


References (2)

• Ivar Jacobson, Grady Booch, James Rumbaugh, The Unified Software Development Process, Addison-Wesley 1999.

• Trygve Renskaug et al: Working with Objects - The OOram Software Engineering Method 1996, ISBN 0134529308

• Rational: The Rational Development process• Paul Allen, Stuart Frost, Component-Based Development for Enterprise Systems, Applying the

SELECT Perspective, SIGS Book and Multimedia 1998• Desmond D’Souza, Alan Wills: Objects, Components and Frameworks with UML – The Catalysis

approach 1998 (November), Addison-Wesley, ISBN 0-201-31012-0• Watts S.Humphrey, Managing the Software Process (CMM), Addison Wesley 1990.• Martin Fowler. “The New Methodology”. Abridged version published in Software Development

Magazine, December 2000. http://www.martinfowler.com• Dirk Riehle. “A Comparison of the Value Systems of Adaptive Software Development and Extreme

Programming: How Methodologies May Learn from Each Other”. SKYVA International, 2000. http://www.riehle.org

• Jim Highsmith. “Messy, Exciting and Anxiety-Ridden: Adaptive Software Development”. Published in American Programmer Magazine, April 1997. http://www.ksinc.com/articles/CAS.html

• Jim Highsmith. “Adaptive Software Development”. Presented at OOPSLA 2000.• Kent Beck. Extreme Programming Explained: Embrace Change. Addison‑Wesley, 2000.• Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherland. “SCRUM: A Pattern

Language for Hyperproductive Software Development.” In Pattern Languages of Program Design 4. Edited by Neil Harrison, Brian Foote, and Hans Rohnert. Addison‑Wesley, 2000. Page 637-652.

• Alistair Cockburn. Crystal “Clear”. AOL, 2000. http://members.aol.com/acockburn


This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.

Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.

Documents

Based on material developed in ATHENA (IST-507849) and INTEROP (IST-508011) 5-4. Method Engineering,