UNIVERSITETET I OSLO Side 1 Det matematisk-naturvitenskapelige fakultet Eksamen i: INF5120, Modellbasert Systemutvikling Eksamensdag: torsdag 1. juni, 2006 Tid for eksamen: 0900-1200 Oppgavesettet er på 2 sider Vedlegg: 8 sider Tillatte hjelpemidler: Alle trykte og håndskrevne Kontroller at oppgavesettet er komplett før du begynner å besvare spørsmålene. Innledning I denne oppgaven skal vi lage en plattformuavhgengig arkitekturmodell for interaksjon mellom et ERP (Enterprise Resource Planning) og CRM (Customer Relationship Management) system, for et scenario med Mobil telefon ettersalg/service tjenester. Interaksjonen mellom systemene vil over tid kunne realaliseres på flere måter, og med ulike teknologier. Det er antatt at vi i fremtiden vil gjøre dette gjennom bruk av Web services, men systemet skal i første omgang realiseres med bruk av CORBA, som er en liknende teknologi, men som ikke bruker internett-teknologi som basis. En beskrivelse av problem scenario, samt kort beskrivelse av CORBA med grammatikk/syntaks for CORBA IDL er gitt på engelsk som vedlegg til oppgaven. Oppgave 1) (30% - 60 minutter, COMET) Ta utgangspunkt i den vedlagte problembeskrivelsen, og lag en plattformuavhengig (PIM) arkitekturmodell som viser interaksjonen mellom ERP system og CRM system. Bruk gjerne COMET arkitekturmodell, eller begrunn valg for en egen variant. (60 minutter) INF5120 Side 1 av 9
Oppgave 2) (50 % - 90 minutter, MDA Transformasjon) Kommunikasjonen mellom de to systemene vil i framtiden gjøres ved for eksempel bruk av Web Services, eller kanskje ett meldings-basert system, men skal i første omgang realiseres ved bruk av CORBA (Common Object Request Broker Architecture) teknologi, se vedlegg. Vi vil derfor benytte en MDA tilnærming, for lettere å kunne flytte til andre liknende plattformer i fremtiden. a) Beskriv og illustrer hvordan man kan definere metamodeller for source og target modell, og gjør dette for den aktuelle PIM (Arkitekturmodell) (fra oppgave 1) og for CORBA (PSM), se grammatikk/syntaks og eksempel på CORBA IDL i vedlegg. b) Beskriv og illustrer hvordan man kan definere transformasjonsregler med ATL (eller evt. XMF:Mosaic, eller MOFScript) for å definere en relasjon/mapping fra den plattformuavhengige (PIM) UML arkitekturmodellen til en plattformspesifikk (PSM) UML modell for CORBA med generering av IDL (Se prinsipiell beskrivelse av syntaks for IDL med lite eksempel i vedlegg.) Oppgave 3) (20 % - 30 minutter, Systemstøtte for metodikk) Diskuter hvordan man kan gå frem for å lage systemstøtte for utviklingsprosesser, som COMET, på en slik måte at prosessen enkelt kan tilpasses den enkelte organisasjon og anvendelses type Kontakt under eksamen: Arne-Jørgen Berre (Tlf: 22 06 74 52) VEDLEGG 8 sider INF5120 Side 2 av 9
Problem Example Mobile phone after-sale services The problem example is based on a real life situation involving system interactions between ERP and CRM applications, in the context of a Telco Company selling telephone related products through two kinds of distributors, franchisees and dealers. The goal in this exam is to create a platform independent architecture model showing the necessary interfaces between the involved ERP system and CRM systems in the dealer situation for the postsales service phase described below. The organisation of the Telco Company is the following The main branch of the Telco Company (called franchisor in the following) owns several ESA (Enterprise Software Applications, such as (ERP, CRM, WMS, etc.)) to manage its activities and centralise data about end-customers, products, warehouses, etc. In order to distribute its products and services the franchisor has set up a network of distributors playing the role of front end for end customers. Two kinds of distributors exist mainly: franchisees and dealers. The franchisees are distributors with an exclusivity contract with the franchisor: they can only propose products and services related to the Telco Company to end-customers. In order to manage their activities, the franchisor provides the franchisees with ESA (Retail system, CRM, etc. but with limited functionalities) compatible with the ones of itself. The problem is then to define interoperability between the applications especially between the local versions of the CRM and Retail System and the franchisor s ERP and CRM. The dealers are distributors which can contract with other companies than Telco. They may have their specific ESA, and therefore, the problem is to define the interoperability needs and make the dealers applications interoperable with the ones of the franchisor within a heterogeneous context. Franchisor ERP CRM WMS Other INTRANET Retail CRM System Lim. Franchisee (Store) Retail CRM System Lim. Franchisee (Store) Specific Retail Specific System CRM Dealer (Store) Customers Figure 1 Interactions between Franchisor and Franchisee/Dealers In this exam we will focus on a subset of the interactions between these systems, in particular on the Franchisor (ERP/CRM) and Dealer interactions (CRM) for after-sales.as shown below. INF5120 Side 3 av 9
Figure 2 Main focus: After sales process between Franchisor and Dealer In After Sales services we have the following electronic interactions: Create Customer Record into the CRM on Franchisor side Receive Customer data from Retail/Franchisor system Transfer electronically the repair request to the Franchisor Transfer the dealer invoice In general, the interoperability needs are described as follows: The after sales service deals mostly with customer service requests and repairs. Regarding repairs, their handling is mostly performed from the CRM application due to the fact that the procedure is executed from front-end personnel (e.g. Employees in a department store, etc.), who use the CRM application. Interoperability needs cover the following: Update CRM with customer transactions: This information is useful because it provides input to the CRM users about the customer s behaviour to the enterprise. For example, in order to define a Service Level Agreement, the company needs to know how active the customer was in terms of sales, support, etc. so it can define its support strategy. This kind of information will also be helpful to the sales personnel in terms of definition of a sales campaign, promotion strategy, etc. INF5120 Side 4 av 9
Creation of ERP documentation from CRM: CRM needs to send the appropriate set of data to the back office application (ERP) in order to produce the necessary documentation (Packaging slips, invoices, etc.). Update CRM with customer transactions, as described above. Figure 3 Enlarged version of figure 2 - for enhanced readability of the interface INF5120 Side 5 av 9
M e a s u r e m e n t u n i t W a r e h o u s e 1.. * C u r r e n c y p r i m a r y U o M p r o d u c t c u r r e n c y s e c o n d a r y U o M 1.. * P r o d u c t p r o d u c t c o d e p r o d u c t c l a s s i f i c a t i o n c o n v e r s i o n c o e f f s u p p l y t y p e V A T c o d e a c c o u n t o f g e n e r a l a c c o u n t i n g 1.. 1 1.. * P r o d u c t p r i c e l i s t p r o d u c t c o d e p r o d u c t p r i c e 1.. * C o m m e r c i a l a c t o r t y p e s 0.. * P r i c e l i s t p r i c e l i s t c o d e d e s c r i p t i o n c o m m e r c i a l v a r s t a r t d a t e e n d d a t e C u s t o m e r c o d e n a m e a d d r e s s C C I A f i s c a l c o d e p h o n e 1.. 1 f a x R I B A a u t h R I D a u t h V A T n u m b e r 0.. * O r d e r B a n k V A T c o d e s P a y m e n t c o n d i t i o n s P a y m e n t m e t h o d s Figure 4 Customer and Product Information model The information model above shows some of the typical information handled by the ERP and CRM systems, related to products (such as phones and services) and to the customer, and which will be subject to transfer of information between the systems. OMG CORBA _- Common Object Request Broker Architecture The interactions between two or more systems and services can be supported through the CORBA architecture, which supports the description of the interfaces of these through the OMG IDL (Interface Definition Language). INF5120 Side 6 av 9
Application Objects Vertical COR B A F acilities Horizontal COR B A F acilities Object R equest B roker (COR B A) Interfaces described in COR B A S ervices CORBA IDL (Interface Definition Language) The CORBA IDL works similar to the Web Services WSDL, by describing the interfaces of the available applications and services. We can view the ERP and CRM systems as two interacting application objects in this case. IDL EXAMPLE //OMG IDL example File //Object Management Group, Inc. // // //Example IDL syntax interface definitions // interface B { attribute A mya; // Will support a get_mya and a set_mya operation }; interface TestInterface { struct TestStruct { string Member1; }; attribute string MyStringAttr; attribute TestStruct MyStructAttr; // attribute is a virtual attribute, representing corresponding get/set operations }; void MyOp1( in string str, inout TestStruct t); boolean MyOp2( inout TestStruct t); interface PrettyPrint { string print(); }; OMG IDL (Interface Definition Language) Syntax Simplified BNF grammar specification > INF5120 Side 7 av 9
(1) <specification> ::= <import>* <definition>+ (2) <definition> ::= <type_dcl> ; <interface> ; (4) <interface> ::= <interface_dcl> (5) <interface_dcl> ::= <interface_header> { <interface_body> } (7) <interface_header> ::= [ abstract local ] interface <identifier> [ <interface_inheritance_spec> ] (8) <interface_body> ::= <export>* (9) <export> ::= <type_dcl> ; <attr_dcl> ; <op_dcl> ; (10)<interface_inheritance_spec>::= : <interface_name> {, <interface_name> }* (42) <type_dcl> ::= typedef <type_declarator> <struct_type> <union_type> <enum_type> native <simple_declarator> <constr_forward_decl> (43) <type_declarator> ::= <type_spec> <declarators> (44) <type_spec> ::= <simple_type_spec> <constr_type_spec> (45) <simple_type_spec> ::= <base_type_spec> <template_type_spec> <scoped_name> (46) <base_type_spec> ::= <floating_pt_type> <integer_type> <char_type> // similar for all basic types (deleted here) (48) <constr_type_spec> ::= <struct_type> <union_type> <enum_type> (49) <declarators> ::= <declarator> {, <declarator> } (50) <declarator> ::= <simple_declarator> <complex_declarator> (51) <simple_declarator> ::= <identifier> (52) <complex_declarator> ::= <array_declarator> (53) <floating_pt_type> ::= float double long double (54) <integer_type> ::= <signed_int> <unsigned_int> ///.. and similar for all basic types..(deleted here) (80) <sequence_type> ::= sequence < <simple_type_spec>, <positive_int_const> > sequence < <simple_type_spec> > (81) <string_type> ::= string < <positive_int_const> > string (82) <wide_string_type> ::= wstring < <positive_int_const> > INF5120 Side 8 av 9
wstring (83) <array_declarator> ::= <identifier> <fixed_array_size>+ (84) <fixed_array_size> ::= [ <positive_int_const> ] (85) <attr_dcl> ::= <readonly_attr_spec> <attr_spec> (87) <op_dcl> ::= [ <op_attribute> ] <op_type_spec> <identifier> <parameter_dcls> (88) <op_attribute> ::= oneway (89) <op_type_spec> ::= <param_type_spec> void (90) <parameter_dcls> ::= ( <param_dcl> {, <param_dcl> } ) ( ) (91) <param_dcl> ::= <param_attribute> <param_type_spec> <simple_declarator> (92) <param_attribute> ::= in out inout (95) <param_type_spec> ::= <base_type_spec> <string_type> <wide_string_type> <scoped_name> (98) <value_base_type> ::= ValueBase (99) <constr_forward_decl> ::= struct <identifier> union <identifier> (104) <readonly_attr_spec> ::= readonly attribute <param_type_spec> <readonly_attr_declarator> (105)<readonly_attr_declarator >::= <simple_declarator> <raises_expr> <simple_declarator> {, <simple_declarator> }* (106) <attr_spec> ::= attribute <param_type_spec> <attr_declarator> INF5120 Side 9 av 9