• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Version : 17/08/07 Ref:
 

Version : 17/08/07 Ref:

on

  • 607 views

 

Statistics

Views

Total Views
607
Views on SlideShare
607
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Animation : passer le temps qu’il faut pour bien faire comprendre le principe du carottage ; s’assurer que ce principe est bien compris ; Les 4 diapositives suivantes sont des applications du principe pour définir des livrables (ou des phases) : on pourra passer rapidement.
  • Commentaire : cette façon d’utiliser l’automate n’est pas correcte, d’un point de vue formel. En effet, les opérations apparaissent derrière le caractère ‘/’  opérations qui réalisent la transition ; Il n’y a pas de déclencheur  cela devrait être interpréter comme des transitions automatiques ! C’est un commodité : les noms des opérations sont plus faciles à associer à la transition, de cette façon (avec l’outil UML).
  • Cette approche n’ayant pas été pratiquée  pas d’exemple tiré du projet « Règlements »
  • Le schéma ci-dessus présente les relations d’inclusion entre les différents niveaux de composants
  • Les noms d’attributs logiques obéissent à des règles de nommage. Il faut au minimum retrouver tous les attributs de la classe dans le type info
  • Classe en extension : correspond à l’ensemble des instances de la classe. La méthode de dérivation prescrit la création d’une ML ensembliste pour chaque classe sémantique. Notion de singleton pour les ML ensemblistes : celles-ci pourraient être connues sous la forme de variables globales.
  • La notion d’incrément s’applique ici au système dans son entier. Elle est redéfinie dans la perspective de l’architecture. Deux façons de définir les incréments : L’incrément fonctionnel : correspond au déploiement d’une fonction ; convient bien à la définition d’un projet de développement applicatif. Pour pouvoir faire tourner le cas d’utilisation, il faut disposer des composants nécessaires  on suit les dépendances documentées par l’architecture logique. L’incrément architectural : plus facile à définir et à intégrer, mais ne correspond pas à un déploiement visible pour l’utilisateur. Ce thème fait l’objet d’un point de méthode : réf. AMW-06a.

Version : 17/08/07 Ref: Version : 17/08/07 Ref: Presentation Transcript

  • Finding out Praxeme #1. Quick overview ( V2 reviewed by Oscar Chappel from ILOG Company, 2008-02-25 ) (V1 in English language) http://soa.orchestranetworks.com
  • Preamble
    • Pierre Bonnet is co-author of Praxeme method and member of the Praxeme Institute, non profit organization which handles and publishes Praxeme’s guides
    • Praxeme is a free of charge method, free of use, open source
    • Documents in this presentation rely on public Praxeme’s guides and are written in collaboration with Dominique Vauquier, creator of the method and with the agreement of SMABTP insurance company which is the major contributor of Praxeme through its project of IS overhauling
    • All detailed documents about Praxeme are available on Praxeme’s website: http://www.praxeme.org
    • Other information are available about MDM and SOA on:
      • http://www.orchestranetworks.com
      • http://soa.orchestranetworks.com
  • Objectives Quick view of Praxeme
  • Contents
    • Origin of the method and requirements
    • Praxeme’s topology
    • Insight into Semantic Aspect
    • Insight into Pragmatic Aspect
    • Insight into Logical Aspect
    • Ergonomics and SOA
    • Project packaging and SOA
  • Existing methods
    • Methods that deal with process of delivery
      • UP, RUP, SDM/S, XP (eXtrem Programming )…
    • UML notation (OMG)
      • Reminder : UML is not a method but a notation
    • Several best practices in IT / Business governance landscape
      • COBIT, CMMI, ITIL…
    • Enterprise Architecture Framework (EAF)
      • TOGAF (Open Group) : technical architecture
      • Herzum (deprecated with SOA momentum?), Zachman (in most cases too complex and lack of SOA/MDA principles?)
    • Other disciplines
      • Business Process Management (BPM), object oriented design, SOA (Service Oriented Architecture)…
      • MDA (Model Driven Architecture) specified by OMG
  • Enterprise method Praxeme
    • Relying on the Enterprise System Topology that define a framework with eight Aspects : Semantic (core business objects), Pragmatic (organizational concerns), Geographic, Logical (ex : SOA), Technical, Software, Hardware, Physical
    • Using this topology we are able to
      • Define products to deliver
      • Refine procedures (guidelines) for modeling and derivation rules between aspects (Model Driven Architecture)
      • Encourage collaborative working between Business and IT people
    • Reusing historical methods such as object oriented design, enterprise architecture and integrating new approaches and standards such as SOA and MDA
    • Praxeme is published free of charge (open method) by the “ Praxeme Institute ” ( http://www.praxeme.org ) that is a non-profit organization
  • Praxeme’s inheritance Modeling method Enterprise architecture System architecture Enterprise System Topology Object oriented Levels of abstraction TACT (Logical machine) Urbanization of IS Merise Contract oriented Classe-Relation UML Meyer Zachman Enterprise architecture Les aspects New urbanization approach Guidelines for modeling by aspect SOA n-tiers Component based Herzum Guidelines for derivation of models throughout aspects MDA Praxeme for SOA
    • Logical architecture
    • Logical design
    • Logical/technical negotiation
    “ Urbanization” is a metaphor stands for logical organization of the IS – Kind of IT City Planning and Enterprise Architecture
  • Praxeme Institute – Non profit organization
    • Members that contribute to the method
      • SAGEM (Defense)
      • SMABTP (Insurance)
      • Caisses d’allocations familiales (Public)
      • Calyon (Financial)
      • Armée de terre (Army)
    • Goals : sharing of financial investments
    • Others contributors
      • Celesio Group :
        • Business referential
  • Context of information systems and requirements
    • General context
      • 30 years (at least) of IT innovations
      • Existing systems are in the end-of-life period. These assets were built during the 80s and 90s
      • Retirement of IT specialists that have in most cases built existing systems
    • Requirements
      • Structuring IS around services rather than functional silos so as to compose more quickly new processes
      • Aligning systems with business requirements
      • Taking over business knowledge
      • Setting up a better IT organization including several disciplines such as Architect, Expert, BPM, SOA, Object, Business Rules, Master Data Management, etc.
  • Functional and technical silos Functional silo Functional silo Customer Functional silo Functional silo Technical silo (MVS) Technical silo (AS400) Technical silo (Unix, Java) Functional silo Technical silo (Internet) Contract Claim People Customer Contract Financial Product Contract Product Claim People Permission Permission Permission Permission Permission GUI GUI GUI GUI GUI ? ? ?
    • No end-to-end processes (no seamless processes)
    • Multiple data keying
    • Low data quality
    • Heterogeneous GUI
    • Permission management is not unified
    • Openness to third parties is tricky
  • Functional silos Order entry Updating address Selecting product code Choosing quantity Calculating discount Customer care Updating address Score analysis Sending mail
    • Duplication of “updating address”
      • Different GUI
      • May be data duplication related to address management
    Using Business Objects and SOA, urbanization is enhanced and redundancies can be removed Urbanization with silos generates redundancies
  • Overhaul with SOA Customer Order Product Order entry Updating address Selecting product code Choosing quantity Choosing discount Customer care Score analysis Sending mail ORGANIZATION STRATUM : organizational rules, rights management, integrity of business transaction, customization according to execution contexts, orchestration of services that are located in business stratum. These orchestrations implements processes and uses-cases. BUSINESS STRATUM : reusable services for any organization, Business Objects lifecycles, regulatory rules (core business rules) Semantic aspect Pragmatic aspect
  • Overhaul with SOA Master data and parameters management system MDM Business Rules Management System BRMS System inter-working (ESB - Enterprise Service Bus ) Functional silos Technical services - Printing - Supervision - Running - ../.. Third parties systems IHM – Unified web portal VARIANTS VARIANTS
  • Variants of service IT Business Without variants of service With variants management service service Example : order entry with three variants Retailer 1 Order entry Retailer N ../..
    • Variants are declared according to execution contexts
    • Products
    • Processes
    • Right management
    • Rules
    Not SOA! VARIANTE
  • SOA at a glance
    • SOA ( Service Oriented Architecture )
      • It is not a technology but a style of architecture
      • It bridges the gap between functional urbanization and modeling tasks which are required by projects
  • SOA maturity matrix
    • Cosmetic SOA to expose services in front of existing assets without re-engineering
    • Overhaul SOA to build new systems
    • Extended SOA to reach the objective of agility. With help from MDM, BRMS and BPM (Agility Chain Management System – ACMS)
  • Others characteristics of SOA
    • SOA brings us a general framework to organize IT proficiencies and bridge the gap between business and IT departments => Enterprise System Topology ( Enterprise Architecture Framework )
    • Setting up at the right place urbanization and Business Process Management
    • Making an effort on knowledge management with help from business modeling (Semantic Aspect of Praxeme’s topology)
    • Taking into account the Model Driven Architecture (MDA) standard in order to improve independence towards technologies, so as to obtain a better alignment of IT with business
    • Therefore… we need a proven enterprise method
  • Enterprise method and Topology with eight aspects (*) Praxeme is published in open source by the Praxeme Institute, founded by Dominique Vauquier (creator of the Praxeme method), Philippe Desfray (co-founder of Softeam company) and Pierre Bonnet (co-founder of Orchestra Networks company) - www.praxeme.org
    • SOA is located in the Logical Aspect
    • Services are identified with help from upstream models (Semantic and Pragmatic)
    UML back-bone and MDA Dependency link
  • Praxeme’s topology – Semantic Aspect
    • Business modeling
      • Business information and lifecycles of business objects
      • Without organizational issues and concerns
    • Object oriented
      • Sustainable modeling because these models are not reliant on IT issues
      • Modeling without redundancy
  • Praxeme’s topology – Pragmatic Aspect
    • Organizational modeling
      • Use case – Modeling of interactions between each user and the system – Micro process by actor, one unit of time, short running transaction
      • Organizational view – Modeling of interactions between several users and systems (processes), long running transaction
    • Process modeling and binding with BPM
      • The first version of a process is obtained with help from life-cycle of the Business Object that is related to this process. The Pragmatic Aspect is reliant on the Semantic Aspect
  • Praxeme’s topology – Logical Aspect
    • Logical architecture modeling according to a particular style
      • Example of possible styles: modular, fully object oriented, SOA, extended SOA
      • Extended SOA = SOA + MDM (Master Data Management) + BRMS (Business Rules Management System)
      • Not reliant on technology: this is the PIM of the MDA (Model Driven Architecture)
    • Using a particular terminology: the factory metaphor
    • With help from MDA the first version of logical models are automatically generated from upstream models (semantic and pragmatic)
    PIM : Platform Independent Model
  • Praxeme’s topology – Technical Aspect
    • Selecting IT tools and modeling technical architecture
      • IT guidelines - Modeling of technical components and the framework in order to set up a virtual machine such as the VEP (Virtual Engine for Praxeme). The VEP’s specification is fully available free of charge ( www.praxeme.org and/or http://soa.orchestranetworks.com )
    • Logical – Technical negotiation
      • Some technical issues may impact the style of logical architecture. For example: management of inheritance regarding data (DDL), information flow (Beans), machines (logical components). Other examples: error handling (parameters or exception), service signatures (mono part or multi-parts), etc.
  • Praxeme’s topology – Software Aspect
    • Models are extended with technical UML profile
      • These models are PSM of MDA standard
      • Binding with technical targets: EJB, web service, XSD, etc.
    • Afterwards code can be automatically generated with help from Software Aspect.
    PSM : Platform Specific Model
  • Praxeme’s topology – other Aspects
    • Geographic Aspect
      • Modeling of geographical structure of the enterprise, using generic object such as Site, Geographic Unit, etc.
    • Hardware and Physical Aspects
      • Modeling of IT infrastructures, IT resources, software set up, network configuration, etc.
    Pré-modélisation
  • The pre-modeling
    • Textual specification – Not yet UML modeling but already reuse mindset
      • Using a requirement repository tool to store, retrieve and manage rules. Therefore pre-modeling is not limited to Word specification!
      • Some key points to succeed pre-modeling: taking into consideration the difference between organizational rules (Pragmatic Aspect) and business rules (Semantic Aspect), encouraging reuse at the level of GUI (mashups strategy), setting up a dictionary of terms, etc.
      • GUI prototype
  • Incremental delivery Aspect Perimeter Semantic Pragmatic Logical Technical and Hardware Software and Physical The whole perimeter but not in a deep analysis Detailed analysis only on a sub-area of the system Deriving upstream models to obtain services specification Implementing software
  • Overview of the Semantic Aspect
  • Semantic Aspect
    • Setting up the map regarding domains of business objects
    • Modeling information and operations for each business object
    • Modeling life-cycles of each business object
  • The map of object domains Example from Insurance company
    • Core business
      • Domains of business objects (Product, Reality, Contract, etc.)
      • Information modeling
      • Business objects lifecycles modeling
    Figures - SMABTP Project (overhaul in a context of insurance company) Product Contract Service provided - Five domains of business objects - Overhaul perimeter: - Cosmetic perimeter: - Common Information Model Reality Account Person, customer, expert, company, objects that are insured, address… Insurance claims management Customer care…
  • Ex : Lifecycle of Business Objects
    • State machine for the Claim Insurance Business Object
    • Formal representation (model)
    • To encourage alignment of IT with business
  • Design by contracts (not new…) Modeling relying on state machine = To encourage design by contracts Pre-conditions « service1 » = « State One » + Preconditions01 Post-conditions « service 1 » = « Postconditions01 » + « State Two » State one State two
  • Information modeling
    • This is the core system, the business knowledge
      • Business Object semantics
      • The Insurance Claim Class describes the complete knowledge of this concept
        • Information
        • Transformation (behaviors of the business object)
        • Constrains
        • Relationship with other semantic concepts such as damage, contract, etc.
    Insurance Claim
  • Information modeling
    • Complete UML notation is used to model information: associative class, qualified attribute, inheritance, etc.
  • Overview of the Pragmatic Aspect
  • Pragmatic Aspect
    • Modeling of use cases
      • Interactions of each actor with the system during one unit of time, short running transaction
    • Modeling of processes
      • Interactions between several actors and systems with long running transaction
  • Pragmatic Aspect Process and use case Step Step Step Step Step Actor 1, Tps1 Actor 2, Tps2 Actor 2, Tps3 Actor 5, Tps5 Actor 4, Tps3 Activity Activity Activity Activity Activity Process Micro-process is also named use case Actor 1, Tps1
  • Use cases Use Cases (use case diagram) 1 use case = one unit of time, one unit of action and one user
  • Limit of the analysis phase = redundancy
    • Crossing between use cases and activities
      • Analysis phase shows some redundancies: some activities are integrated more that one time in several use cases or inside a sole use case
    • Example:
    A same activity is located in several use cases Activity Use case Many times in the same use case
  • Optimizing the analysis view of use case Getting ride of redundancies Use case #1
    • Sequence
      • Activity 1
      • Activity 2
      • Activity 3
      • Activity 4
    Use case #2
    • Sequence
      • Activity 1
      • Activity 2
      • Activity 5
      • Activity 6
    Use case #1
    • Sequence
      • Activity 3
      • Activity 4
    Use case #2
    • Sequence
      • Activity 5
      • Activity 6
    Use case #3
    • Sequence
      • Activity 1
      • Activity 2
    include include Results from analysis phase (redundancies) Optimized model without redundancies Towards logical architecture models MDA
  • Use cases from Design phase
    • Crossing between use cases and activities
    • With help from the design phase redundancies are removed
  • Use case and state machine Activities (UML operation). In most cases, these activities come from pre-modeling Functional domain Use- case State machines describe the orchestration of activities inside the use case (sequence)
    • A resumed state diagram for the use case « insurance claim »
    Use case and state machine (example) The actor of the use case Resumed state Outset of the use case End of the use case
  • Use case and state machine (example)
    • The detailed state machine that shows the orchestration of various activities regarding « insurance claim » use case
    Simplified notation
  • With Praxeme Process are reliant on semantic modeling Semantic Aspect State machine Business Process Management
      • Reuse life-cycle of Business Object (Semantic aspect) to automatically obtain the first version of the process: this is the conceptual process!
  • With Praxeme Process are reliant on semantic modeling Lifecycle of Business Object (semantic aspect) First version of the process: conceptual process! Automatic! Organization processes Benchmarking!
  • Processes – UML notation Swim-lanes Catching event Activity Object (instance of a business class) Throwing event Conditional branch Actor (Type of actor, role)
  • Overview of the Logical Aspect
  • Aspects that are involved
    • Logical representation of IS relying on upstream models (Semantic and Pragmatic)
    Logical Semantic Pragmatic
  • Principles of derivation from upstream models
    • Three logical stratums: interaction, organization, business
    • Services are designed by the derivation from upstream models
    • Factory metaphor to name logical components: factory, workshop, machine
    • Mod?le s?mantique
    Semantic models
    • Mod?le pragmatique
    • ?
    • ?
    • Vue de l’utilisation
    • ?
    • ?
    • ?
    • Vue de l’organisation
    • ?
    Pragmatic models
    • Use case
    • Processes
    Interaction stratum Organization stratum Business stratum
  • Logical components (SOA style) Logical Factory Logical Workshop Logical Machine Services The finest grain of the system Set of services deriving from: - Semantic class - Pragmatic class or use-case Semantic proximity or Functional domain - A domain of business objects - An enterprise organization - Transversal utility packages
  • Derivation rules for Semantic Class
    • The derivation of each Semantic Class provides three logical components:
    • A main logical machine
    • An accessor logical machine (CRUD)
    • A complex type
  • Disaster Class (Semantic level) Business logical machine Disaster Business logical machine (accessor) Complex type (pivot language) of Disaster business object Semantic Logical
  • Data structure and logical machine
    • The complex data type
      • Attributes of the Semantic Class are wrapped in a specific data structure (UML data type) belonging to the machine
      • Be aware that data structure is isolated from the machine
        • In order to facilitate the communication of data flow between the stratum and afterwards software layers (Software Aspect)
        • It is no longer fully object oriented. Encapsulation of data inside the instance of object is no longer require
    • The main logical machine
      • It encompasses business operations that come from semantic modeling
      • It has a traceability link to its complex data type
  • Data structure and main logical machine Semantic Aspect Logical Aspect (SOA style)
  • Data structure and main logical machine Naming in logical terms, decision about subtypes, etc.
  • The accessor logical machine
    • The accessor logical machine encompasses CRUD services
      • Create, Read, Update, Delete but also statistical services, smart search services…
        • These services have no equivalence with upstream models (Semantic, Pragmatic). They are not relevant at semantic and pragmatic levels
      • In most cases services that are exposed by this machine are generic in order to limit their galloping inflation
      • These services are involved in the dynamic description of the logical architecture. They are required to define logical algorithms of services.
  • Derivation from the Pragmatic Aspect Logical organization machine Logical services Transaction management Functional domain Use case Sequence Activities Logical organization workshop Context One to One State machine One to One One to One
  • Logical stratums and communication between stratums Page Page Page Pages orchestrations Context management InfoBlocGUI Logical Organizational Machine InfoLOM Logical Business Machine InfoLBM Interaction stratum Organizational stratum Business stratum
    • Communication between strata via data types: messages (SOA style)
    • Be aware that this is not fully oriented objects because messages are not instances! It is one difference between a fully oriented approach and SOA style
    InfoLOM = ∑ InfoLBM i=1 n
  • Example of a theoretical graph of logical architecture LBM LBM LBM LBM LBM LBM LBM Workshop Interface Service of the workshop Unit of deployment (J2EE or others) LOM (this tightly coupled is forbidden) Orchestration at the level of LOM would be better Not used Workshop Interface LOM stands for Logical Organizational Machine LBM stands for Logical Business Machine ou
  • Ergonomics and SOA
  • Ergonomics benefits with SOA
    • In the context of siloed systems
      • Processes are reliant on boundaries between functional and technical silos: multiple data keying, heterogeneous GUI, no seamless processes, etc.
    • With help from SOA
      • Processes are better integrated because they orchestrate services that are not reliant on boundaries of existing systems
      • The same GUI component can be reused in several applications so as to facilitate learning of systems by business users
  • Ergonomics styles
    • Either procedural
      • The more usual around functions of the system
    • Or business folder oriented
      • Users select business objects (contract, customer, disaster, etc.) and afterwards interact with processes
      • In most cases this approach is encouraged with SOA
  • Ergonomics and use cases
    • Gestion des sinistres
    • Déclarer sinistre
    • Décrire sinistre
    • Sélectionner couverture
    • <<include>>
    • Missionner
    • Affecter les intervenants
    • Traiter les présentations
    • <<include>>
    • <<include>>
    • <<include>>
    • Relier les sinistres
    • Répartir les charges sinistre
    • <<include>>
    • <<extend>>
    • Effectuer une présentation
    • Abandonner/Modifier une présentation
    • <<extend>>
    • <<extend>>
    • Payer
    • Encaisser
    • Régulariser sinistre
    • <<include>>
    • <<extend>>
    • <<extend>>
    Main screen Secondary windows Declaration of insurance claim Financial management Relationship with others companies
  • Project packaging and SOA
  • Project packaging and SOA
    • Either by functional increment (usual approach)
    • Or by logical components that compose the graph of logical architecture
    Cautious about testing strategy according to the choice of packaging
    • FLO_SMABTP
    • FLO_SMABTP
    • FL
    • FL
    • FL
    • FL
    • MLM
    • AL
    • AL
    • AL
    • MLM
    • AL
    • AL
    • AL_Thesaurus
    • MLO
    • ALO_GestionSinistre
    • MLO
    • ALO_Organisation
    • Cas d’utilisation
    • FL_Utilitaires
    • Functional increment
    • Architecture increment
    • Stream X
    • Architecture increment
    • Stream Y
    • AL
    • Thanks
    Meaning to actions