MDA experiment in Telecom Industry Bertrand NICOLAS bertrand.nicolas@francetelecom.com

MDA experiment in Telecom IndustryBertrand NICOLASbertrand.nicolas@francetelecom.com

Outline • MetYs ® and its processes • Mainsprings for MetYs processes definition • MetYs processes • MetYs process description • MetYs ® for IN telecom services modelling • Domain analysis • System analysis • Design • Conclusion and future works MetYs is a France Telecom trademark.

Mainsprings for MetYs ® Process Definition • To split up modelling into functional and technical features • To allow reuse of business models • To allow reuse of technical studies for systems based on similar technical infrastructures • To split up modelling into 3 areas: Enterprise, Domain, Software application or telecom service • These 3 areas cover the complete company modelling • Splits up studies and encourages model reuse • To define one modelling process for each (area, functional-technical feature) • To define MetYs processes according to the ISO/SPICE recommendation for software process assessment

MetYs® Processes Functional Technical Enterprise Process Analysis Global Architecture Domain Domain Analysis Domain Architecture System Analysis System Architecture Software Application Design Coding et Testing

To study and model business processes of the enterprise • This MetYs process addresses all the business processes: manual, automatic and semi-automatic Process Analysis MetYs® Processes Functional Enterprise Order and delivery process for telecom services …

To study and model reusable elements within a specific domain • This process addresses only software application features • To encourage model reuse among software applications within a domain Domain Analysis MetYs® Processes Functional Domain Vocal service element, …

To study and model a specific software application • Model functional and non-functional requirements • Reuse models elaborated by Domain Analysis process • These models are Platform Independent (PIM) System Analysis MetYs® Processes Functional Software Application Virtual private network service, Integrated mail service, …

To study technical elements that may be involved in the global enterprise computing system • To achieve the technical coherence of the global information system (compatibility, interoperability, etc.) Global Architecture MetYs® Processes Technical Enterprise Working stations, VoiceXML Platforms, …

To study a specific technical architecture used in one or several business domains • To specify best practices for this technical architecture (Performance, resource optimisation, reliability, etc.) Domain Architecture MetYs® Processes Technical Domaine A CORBA Platform, A VoiceXML Platform, …

To study a technical architecture for a specific software application • Reuse of Domain Architecture process work products • Go deeply in Domain Architecture studies according to the needs of this software application • To decide on the way of using this technical architecture for this software application System Architecture MetYs® Processes Technical Software Application An integrated mail service on a VoiceXML platform, …

To elaborate the design model by merging models from functional and technical studies made for one specific software application • Transformation may be partial or full automatic • To build a complete design model for the next coding phase Design MetYs® Processes Functional & Technical Software Application An integrated mail service on a VoiceXML platform, …

To make the software application code by transformation of the design model • The code can be directly deduced from the design model • This transformation can be automatic by using a generic tool • To validate the software application Coding and Testing An integrated mail service on a VoiceXML platform, … MetYs® Processes Functional & Technical Software Application

What does a MetYs® Process Definition Consist on ? • A purpose and a goal • A meta-model • The concepts with their relationships and their semantics • Input and output work products • Involved actors • Tasks and steps • Quality criteria (SPICE) • One or several UML profile • Mapping between concepts / work products, and UML concepts / diagrams • Organisation of model elements in UML tools • Model validation rules • Presentation rules (UML diagrams, documents, etc.)

MetYs® for IN Telecom Services Modelling • Context: • An IN telecom service is specified by using components called Service Elements • A ServiceElement (SE) • Is a set of operations and data • has a behaviour • Needs: • A method for modelling telecom services: • using UML • component oriented • with a direct link between analysis and design processes • Automatic model generation from UML to SDL models for: • Behaviour simulation • Test generation

MetYs® for IN Telecom Services Modelling Functional Technical Enterprise Process Analysis Global Architecture Domain Domain Analysis Domain Architecture System Analysis System Architecture Software Application Design Coding et Testing

Domain Analysis Meta-Model (part of) AS Functionality • Abstract Service (AS) • AS Functionality • Service Element (SE) • SE Functionality • Domain Resource • Domain Role • Domain Resource Category • AS Functionality Category • … Category includes includes 0..* 0..* 1..* 1..* 1..* 1..* interacts with AS 0..* 0..* offers AS Functionality 0..* 0..* uses 0..* 0..* 0..* 0..* products 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 1..* 1..* extends Domain Domain Resource gathers Domain Role extends Resource Category includes 1..* 1..* 1..* 1..* includes 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* products 0..* 0..* uses SE Functionality 0..* 0..* SE offers 0..* 0..* interacts with 1..* 1..* 0..* 0..* extends

Example of Concept: Abstract System (AS) • Definition • Captures the common behaviour of a set of services • This common behaviour corresponds to a set of domain roles interacting with this service family, and a set of common functionalities for this service family • The decomposition of common functionalities may involve a set of service elements (SE) • Its execution environment is modelled by The abstract service context • Its functionalities are modelled by The functional model of abstract system • UML Representation (i.e. Part of MetYs / Domain Analysis profile ) • A package with a <<AS>> stereotype and the name of AS. This package is included in the Abstract Service Repository. • A class with <<AS>> stereotype and AS name. This class is included in the previous package.

Example of Work Product: The abstract service context • Definition • Captures the AS within its environment • Characterizes AS boundary to avoid ambiguity about its functionalities • Shows all domain roles (person and others systems) which interact with the AS. These interaction definitions may be completed by data or event • UML Representation (i.e. Part of MetYs – Domain Analysis profile ) • A class diagram. This diagram is stored in the associated package with <<AS>> stereotype.

Tasks and Steps • Macro-Task A : ABSTRACT SERVICE ANALYSIS • Task 1 : Context specification and main AS functionalitiesidentification • Identify all users who interact with the AS (i.e. domain role [, business roles]). • Identify others systems interacting with the AS (i.e. domain role [, business roles]). • Specify The abstract service context. • Identify one or several AS from which the current AS may inherit. • Identify main functionalities offered by the current AS to each trigger role. • Verify coherence between AS context and its super-AS context(s). • Verify coherence between AS functionalities and its super-AS functionalities. • Describe domain roles according to the Domain role description guide. • Describe the AS according to the Abstract servicedescription guide. • Task 2 : Definition of the main AS functionalities • Task 3 : Definition of all domain resources used by the AS • Task 4 : Validation of work products • Macro-Task B : SERVICE ELEMENT ANALYSIS • . . .

Example of Abstract Service: Customized Service • The AS context (part of) Subscriber switchesOn customizes switchesOff <<SA>> subscribesService performs Customisable Service unsubscribesService Service User Trader activatesService cancelsService Service Administrator

Example of Abstract Service: Customized Service • The functional model (part of) <<ASfonctionality>> ServiceCustomisation customizes performs SwitchesOn <<ASfonctionality>> <<ASfonctionality>> Subscriber Service User ServiceOn ServiceExecution switchesOff <<ASfonctionality>> ServiceOff

<<SE>> Transfer <<SE>> Transfer subscribesTransfer() activatesTransfer() . . . Example of Service Element: Transfer Trader Subscriber • The functional model Service Administrator <<SEfonctionality>> <<SEfonctionality>> TransferSubscription TransferUnsubscription <<SEfonctionality>> TransferCustomisation subscribesTransfer unsubscribesTransfer activatesTransfer customizesTransfer <<DomainRole>> <<SEfonctionality>> Service switchesOnTransfer TransferActivation <<SEfonctionality>> TransferOn cancelsTransfer switchesOffTransfer performsTransfer <<SEfonctionality>> TransferCancellation <<SEfonctionality>> TransferOff Service User <<SEfonctionality>> TransferExecution

<<DomainResourceCategory>> DRC_Transfer <<SEFunctionnality>> <<SEfonctionality>> <<DomainResource>> TransferSubscribtion TransferActivation TransferDescription Example of Service Element: Transfer • Domain resources used by Transfer SE isAssociatedTo +father 0..1 0..1 +son 0..* 0..* <<DomainResource>> <<DomainResource>> TransferDescription isTransferedTo Entity on : Boolean condition : TransferCondition id : EntityId transferTo : Number 0..* 0..* • Use and creation links between domain resources and SE functionalities <<create>> <<use>>

System Analysis Meta-Model (part of) Functionality Resource • Domain Analysis concepts : AS, SE, AS/SE Functionnality … • System • Functionality • Scenario • Resource • Role • Non-Functional Requirement • Resource Category • Role Category • NF Requirement Category Category Category includes Scenario describes includes 0..* 0..* 1 1 0..* 0..* 0..* includes 2..* 2..* Functionality 0..* 0..* 0..* uses 0..* 0..* Resource 0..* 0..* 0..* extends 0..* 0..* products 0..* 0..* 0..* 0..* 0..* 1..* 1..* inherits 0..* 0..* offers Non-Functional System interacts with Role Requirement 0..* 0..* 0..* 0..* 0..1 0..1 includes 1..* 1..* inherits Non-Functional Requirement Category

Example of Service: Virtual Private Network (VPN) <<AS>> • The service context • The functional model (part of) CustomisableService (from ASrepository) <<DomainRole>> <<Service>> sendsTicketTo Ticket Center VPN (from DomainRoleRepository) <<Fonctionality>> performsVPNserviceUsingFTcard <<Fonctionality>> <<ASfonctionality>> performsVPNservice performs <<Fonctionality>> performsVPNserviceUsingPABX (from CustomizedService)

Example of Service: VPN . . . <<include>> <<SEfonctionality>> • The detailed functional model (part of) FraudAdding <<include>> (from Fraud) <<Fonctionality>> <<include>> ServiceAccesUsingFTCard <<include>> <<SEfonctionality>> FraudControl . . . <<Fonctionality>> (from Fraud) performsVPNserviceUsingFTcard . . . <<Fonctionality>> CallNumberProcessing <<include>> <<include>> <<SEfonctionality>> TransferActivation <<include>> (from Transfer) <<Fonctionality>> CallManagement <<SEfonctionality>> TransferExecution Decomposition of service functionalities until using ES functionalities (from Transfer) . . .

Example of Service: VPN • Used SE diagram << SE >> << SE >> Credit CallEstablishment (from SErepository) (from SErepository) << SE >> << SE >> Authentication Dial (from SErepository) (from SErepository) <<Service>> VPN (from ServiceRepository) << SE >> << SE >> Transfer Right (from SErepository) (from SErepository) << SE >> << SE >> Fraud Linking (from SErepository) (from SErepository)

From System Analysis and System Architecture Processes to Design Process (1/3) • Selection of mapping rules between System Analysis and SDL meta-models according to architecture processes results

Selection of transformation results format • SDL 96 language files (.pr) • A model based on the SDL-UML profile (ITU Z.109 recommendation) • A model based on the SDL-UML profile (ITU Z.109 recommendation) From System Analysis and System Architecture Processes to Design Process (2/3) • Selection of mapping rules between System Analysis and SDL meta-models according to architecture processes results

Some Transformation Rules SDL Meta-Model MetYs Meta-Model • Service • SDL block type • UML Class <<block>> • SE • SDL process type • UML Package • UML Class <<process>> • SE Functionality • SDL exported procedure type of the processtype • Operation of the UML <<process>> Class • UML <<procedure>> class with {remote} tagged value For remote procedure call • UML <<procedure>> class with {virtual} tagged value Inheritance (to take care of existing code) • Resource Category and Resources • SDL Package gathering SDL new types • UML Package • UML <<import>> dependency with using packages • UML <<value>> class

Selection of the transformation results format • SDL 96 language files (.pr) • Model based on the SDL-UML profile (ITU Z.109 recommandation) • Model based on the SDL-UML profile (ITU Z.109 recommendation) • Specification of the model transformation tool architecture • MetYs - UML work products: Rose or Objecteering UML tools • SDL work products: ObjectGeode SDL tool From System Analysis and System Architecture Processes to Design Process (3/3) • Selection of mapping rules between System Analysis and SDL meta-models according to architecture processes results

Transformation Rules MetYs Conformity MOF Repository (Univers@lis) MetYs Profile Transformation module MOF Repository (Univers@lis) SDL Profile SDL 96 Pretty printer tool SDL files ( .pr) SYSTEM myService ... PROCSES TYPE mySE ... Model Transformation Tool Architecture SDL Profile MetYs Profile UML Tool (Rose/Objecteering) Z.109 (LDS 2000) SDL Tool (ObjectGeode) Model Transformation Tool (From MetYs Profile to SDL Profile) XMI XMI

<<SE>> Transfer <<SE>> Transfer subscribeTransfer () activateTransfer () . . . SE Transformation (1/3) MetYs Profile • Transfer SE (part of) <<SEfonctionality>> <<SEfonctionality>> TransferSubscription TransferUnsubscription performTransfer ( in entityNumberCharstring, in condition TransferCondition ) <<SEfonctionality>> ParametrageTransfer subscribeTransfer unsubscribeTransfer activateTransfer customizeTransfer <<DomainRole>> <<SEfonctionality>> Service activateTransfer performTransfer TransferActivation <<SEfonctionality>> TransferActivation cancelTransfer switchOffTransfer switchOnTransfer <<SEfonctionality>> TransferCancellation <<SEfonctionality>> TransferOff <<SEfonctionality>> TransferOn

DR_Transfer SE Transformation (2/3) • Transfer SE (part of) SDL Profile Transfer <<process>> Transfer::Transfer <<procedure>> Transfer::performTransfer {virtual} Transfer() performTransfer( in entityNumber : Charstring, in condition : TransferCondition) . . . <<import>> performTransfer( in entityNumber : Charstring, in condition : TransferCondition) <<procedure>> Transfer:: performTransfer {remote} . . . performTransfer( in entityNumber : Charstring, in condition : TransferCondition) . . .

SE Transformation (3/3) SDL-96 Model • Transfer SE (part of) USE SE_Transfer_squeleton ; PACKAGE SE_Transfer; PROCSES TYPE Transfer INHERITS Transfer _squeleton ; REDEFINED PROCEDURE performTransfer ; START REDEFINED; TASK ’ HERE Define the new transition...'; STOP; … ENDPROCSES TYPE Transfer ; ENDPACKAGE Transfer ; USE ServiceElement; USE RD_Transfer; PACKAGE SE_Transfer_squeleton ; PROCSES TYPE Transfer_squeleton INHERITS ServiceElement; VIRTUAL EXPORTED PROCEDURE performTransfer ; FPAR IN entityNumberCharstring, IN condition TransferCondition ; START VIRTUAL; TASK 'Transition to redefine...'; RETURN; ENDPROCEDURE; ... ENDPROCSES TYPE; ... REMOTE PROCEDURE performTransfer nodelay; FPAR IN Charstring, IN TransferCondition ; ... ENDPACKAGE; Fichier SE_Transfer.prex Fichier SE_Transfer_squeleton .pr

Design • SDL Models coherence is guaranteed by UML models • All model modifications must be done in UML models • SDL Models/code must be generated from UML models • Detail behaviour is designed in SDL language • UML and SDL models are platform independent models (PIM) • SDL services models are used in connection with the SDL Intelligent Network architecture model (CAS/CT or CAS-CAA + API Parlay) to: • Simulate service behaviour • Generate conformity tests • The IN architecture model may be connected to an hardware platform (Alcatel)

Outline • MetYs ® and its processes • Mainsprings for MetYs processes definition • MetYs processes • MetYs process description • MetYs ® for IN telecom services modelling • Domain analysis • System analysis • Design • Conclusion and future work MetYs is a France Telecom trademark.

Conclusion and Future Works • MetYs® is a model driven method • Uses Platform Independent Models (Process Analysis, Domain Analysis, System Analysis) • Offers flexibility to characterize PIM-PSM boundary • The SDL Design model is PIM • It becomes PSM when it is linked to a network model • MetYs® promotes model reuse (especially by using PIM models) • MetYs® uses ISO/SPICE for software process assessment • Current work • Adaptation of MetYs® processes to model VoiceXML services • Use the MTRANS transformation rules definition language to specify meta-models mappings • Future work • Extend of the MetYs® / Process analysis method to capture process scalability features, and use MDA principles to build a model for a simulation tool (SES/Workbench)

MDA experiment in Telecom Industry Bertrand NICOLAS bertrand.nicolas@francetelecom.com