Contexte, motivation, objectifs
Motivation
After reviewing previous work on the collaboration between software engineering and semantic web, we found a lack of research focused on leveraging semantic web technology for the business layer of applications This gap prompted us to pursue a methodology that utilizes an ontology for sharing executable descriptions of the business layer in typical applications within a specific domain Given that many individuals face similar challenges in a particular area, developing a methodology that enables the sharing of executable solution logic among users is essential.
When a person reuses a shared executable business layer, they only need to customize the model to fit their specific needs and data The advantage of reusing the design of a business layer is that it reduces both the cost and development time of software This approach can transform how people share experiences; instead of relying solely on written or oral communication, they can share experiences in an executable format This perspective inspired us to undertake this work.
Figure 1.2: Objectif de notre travaux
Objectifs
La figure 1.2 est l’esquisse de notre objectif pour laquelle nous proposons deux parties principales dans nos recherche.
The initial section offers a tool designed to assist experts and individuals in sharing their experiences related to typical application development It outlines a declarative layer pattern model, which consists of two main components: the process of
Questions de recherche
Business processes outline the execution logic of an application, while business rules define the constraints applied to specific instances of these processes OntoApp software must ensure that there are no structural errors within the business processes and that conflicts do not arise among the various business rules Additionally, the tool should feature functionality to verify the compliance of a business process with its corresponding set of business rules.
The second part focuses on providing a tool that enables users to download a business process template for customization and reuse within their system This tool allows for the personalization of both business process templates and business rule templates to align with individual requirements Additionally, a key feature of this tool is its ability to adapt the user's data source to the customized business process.
A partir de l’objectif de notre recherche, nous avons divisé notre travail en questions de recherche majeures suivantes :
The research question focuses on how to construct an "executable" business layer model for a typical application within a specific domain This includes developing both the business process model and the business rules model while ensuring their accuracy.
Research Question 2: How can one automatically verify the compliance of a business process with a predefined set of business rules, and ensure that customized business processes adhere to personalized business rules?
Research Question 3: How can users be empowered to customize a business layer template of an application to meet their specific requirements without encountering structural or semantic errors?
6 Chapitre 1 Introduction comment intégrer la source de données d’un utilisateur à un patron de pro- cessus de métier et le rendre exécutable sur le système de l’utilisateur ?
Méthodologie de recherche
Figure 1.3 illustrates the research methodology, beginning with a review of requirements for contextual surveys This step facilitated the planning of advancements in business process approvals We established a hypothetical premise, proposed a response, and executed it within models Although the arrangements do not comprehensively address all aspects of the preliminary examination of the prototype, they focus on specific viewpoints Utilizing the created models, we assessed our responses based on data from applications, which may lead to an additional cycle of advancement and usage, especially if the generated ideas do not cover all relevant angles or provide adequate arrangements The evaluation of the created arrangements may also result in a new agreement that necessitates adjustments.
Contributions
Couche de métier exécutable basée sur l’ontologie
Cette contribution répond à la question de recherche 1 et à la question de recherche
2 Nous divisons cette contribution en trois sous contributions comme suit :
• Patron de processus de métier fondée sur l’ontologie
We utilize Colored Petri Nets (CPN) to model a business process, which is subsequently represented by an ontology known as the Business Process Ontology (BPO) This ontology includes a set of concepts to depict the CPN graph (business process), along with instances of business processes and constraints employed by a reasoner to automatically verify the coherence of these processes The key contribution of this section is to provide a method for representing and verifying a business process model using ontology and reasoning, which will be discussed in further detail in Chapter IV.
• Définition de règle de métier fondée sur l’ontologie
The second key component of a business layer is the business rule We propose a method to translate the Semantics of Business Vocabulary and Business Rules (SBVR) into OWL, enabling users to define business rules When a set of business rules is defined by SBVR, the terminology, verb, and phrase are converted into an ontology known as the "Business Rule Ontology (BRO)." When a new business rule is added, a reasoner will check the knowledge base of business rules to detect any potential conflicts This contribution will be analyzed in more detail in Chapter V.
• Vérification de la conformité aux processus de métiers fondée sur l’ontologie
This contribution presents an ontology-based approach for verifying business process compliance When a business process is created, it must adhere to predefined business rules Our solution involves aligning concepts within Business Process Outsourcing (BPO) and Business Rule Optimization (BRO); following the mapping, the rule is established.
1.4 Contributions 9 dans BRO sera appliquée à l’instance de processus de métier dans BPO Cette contribution sera discutée plus en détail au chapitre V.
On a theoretical level, we proposed an extension of CPN called CPN-BP to model business processes in software engineering CPN-BP is a CPN graph that includes two new definitions.
Internal tokens and external tokens are defined to facilitate transitions in a CPN graph, allowing it to interact with external events or objects This topic will be elaborated upon in Chapter IV.
Réutilisation d’une couche de métier
In the previous section, we presented a declarative approach for modeling a business layer using ontology The OntoApp software can be utilized to define an application pattern tailored for a specific domain, which is a significant advantage of our approach as this application pattern can be reused by the community Additionally, we need to address research question 3 and research question 4.
Our work provides a significant contribution by addressing key research questions through a user-centric approach for customizing application models to align with individual information systems We present a method that enables the personalization of business process templates while preventing structural errors during modifications Additionally, we introduce a recommendation approach for a set of queries based on the data sources utilized within the user's information system A customized business process model is essentially a modified version tailored to fit an existing user information system, which involves adapting business processes, data, terminology, and business rules Each adaptation will be addressed through our proposed contributions.
We offer a range of change operations that enable users to customize a business process template Additionally, we provide restrictions on user modifications to ensure effective management.
10 Chapitre 1 Introduction pas mettre en conflit le processus modifié avec un patron de règles de processus de métier prédéfini.
We offer a method for integrating user data sources with an ontology By creating alignments, we define queries within a business process model, which will then be translated into a recommended query for the user's data source.
Each user possesses a unique information system, including their specific data sources To ensure that customized business processes are readily available, we recommend a query method that aligns with the user's data source system through ontology matching.
Publications
1 Tuan Anh Pham and Nhan Le Thanh Ontology-based business pro- cess compliance International Journal of Research in Engineering and Sci- ence(IJRES), 2017 (Accepted).
2 Tuan Anh Pham and Nhan Le Thanh Checking the compliance of busi- ness process in business process life cycle In Proceedings of the RuleML
2016 Challenge, and Industry Track hosted by the 10th International Web Rule Symposium, RuleML 2016, New York, USA, July 6-9, 2016.
Tuan Anh Pham and Nhan Le Thanh presented an ontology-based method for verifying business process compliance Their research was featured in the proceedings of the 10th International Conference on Ubiquitous Information Management and Communication (IMCOM 2016), held in Danang, Vietnam, from January 4 to 6, 2016.
4 Tuan Anh Pham and Nhan Le Thanh A rule-based language for in- tegrating business process and business rules In Proceedings of the
RuleML 2015 Challenge, the Special Track on Rule-based Recommender Sys- tems for the Web of Data, the Special Industry Track hosted by the 9th In-
Structure de thèse
ternational Web Rule Symposium (RuleML 2015), Berlin, Germany, August 2-5, 2015.
5 Tuan Anh Pham and Nhan Le Thanh Ontology-based business logic layer In Poster session of the 9th International Web Rule Symposium (RuleML 2015), Berlin, Germany,August 2-5,2015.
6 Tuan Anh Pham and Nhan Le Thanh Checking the compliance of busi- ness processes and business rules using OWL 2 ontology and SWRL.
In Proceedings of the Second International Afro-European Conference for In- dustrial Advancement, AECIA 2015, Villejuif (Paris-sud), France,pages 11-20, 2015.
Tuan Anh Pham, Thi-Hoa-Hue Nguyen, and Nhan Le Thanh presented their research on ontology-based workflow validation at the 2015 IEEE RIVF International Conference, held in Can Tho, Vietnam, from January 25-28 Their work, documented in pages 41-46 of the conference proceedings, explores innovative approaches to enhance workflow validation through ontology integration.
8 Tuan Anh Pham Ontology-based business logic layer In Poster session of The 10th Reasoning Web Summer School, Athens, Greece, Sept 8-13, 2014.
This document is structured into four sections and nine chapters Part I introduces the ontology-based business layer, comprising Chapters IV and V Part II focuses on the reuse of the business layer, which includes Chapter VI Part III discusses the implementation and evaluation of our research The final part concludes our work The chapters are organized accordingly.
• Chapitre 1 : dans ce chapitre, nous présentons les questions de recherche, notre méthode de recherche Nous clarifions également les principales contri- butions et notre motivation.
• Chapitre 2 : ce chapitre présente quelques antécédents théoriques qui ont été utilisés pour déployer notre approche: CPN comme théorie de vérification
12 Chapitre 1 Introduction de modèle, Ontologie, langage OWL.
• Chapitre 3 : l’état de l’art sur la collaboration entre ingénierie logicielle et web sémantique est présenté Nous énumérons et analysons les travaux précédents sur cette direction.
Chapter 4 addresses Research Questions 1 and 2 by presenting our ontology-based approach for representing and verifying business processes We classify business process deadlocks and establish rules to prevent them.
Chapter 5 presents an ontology-based approach for representing business rules This ontology is utilized to ensure the consistency of the business rule set before its implementation in a system.
Ce chapitre fournit également la solution pour la vérification de la conformité des processus de métier.
• Chapitre 6 : ce chapitre présente notre approche pour l’intégration de la source de données et la personnalisation de la couche de métier avant de créer une démonstration pour une application.
• Chapitre 7 : ce chapitre présente la mise en œuvre d’un prototype, les principales caractéristiques de ce prototype.
• Chapitre 8 : ce chapitre présente l’évaluation du prototype réalisé Il est nécessaire de vérifier notre solution dans cette thèse.
• Chapitre 9 : ce chapitre fournit les conclusions de notre travail Il fournit également des perspectives et des travaux futurs de le prolongement de cette thèse.
Théorie des vérifications de modèles
Réseaux de Pétri
2.2.1 Logique de description 16 2.2.2 OWL 18 2.2.3 SWRL 19 2.2.4 Raisonneur 19 2.3 Génie logiciel 22
2.3.1 Activités SDLC 22 2.3.2 Modèle à trois couches 25 2.4 SBVR 25
2.1 Théorie des vérifications de modèles
A Petri net (PN) is a specific type of directed graph consisting of various elements, including places, transitions, directed arcs, and tokens The directed arcs connect places to transitions or transitions back to places A transition becomes activated when all the places in its precondition are filled.
Définition 1 : un graphe de réseaux de Pétri (ou structure de réseaux de Pétri) est un graphe bipartite (P, T, A, w) Où :
• P est l’ensemble fini de places (un type de nœud dans le graphe)
• T est l’ensemble fini de transitions (l’autre type de nœud dans le graphe)
• A ⊆(P×T)∪(T×P) est l’ensemble des arcs des places aux transitions et des transitions aux places du graphe.
• w:A→1,2,3, est la fonction de poids sur les arcs
Exemple 2.1 : La figure 2.1 présente un graphe de réseaux de Pétri avec les ensembles suivants:
Figure 2.1: un graphe de réseaux de Pétri Source: wikipedia
A Petri net can be represented by a transition with an input place and an output place Tokens are a special concept in Petri nets, where the presence or absence of a token in a place indicates whether a condition is true or false The state of the net is determined by the movement of tokens, which is triggered by the firing of a transition Firing represents the occurrence of an event or an action taken, and it is contingent upon the entry conditions, indicated by the availability of tokens.
A Petri net lacks types and modules, featuring only one type of token and a flat structure In contrast, colored Petri nets (CPN) allow for the use of data types and complex data manipulation.
2.1 Théorie des vérifications de modèles 15
• Chaque jeton a attaché une valeur de données appelée couleur jeton.
• Les couleurs symboliques peuvent être étudiées et modifiées par les transitions apparentes.
Avec les CPN, il est possible de faire des descriptions hiérarchiques:
• Un grand modèle peut être obtenu en combinant un ensemble de sous-modèles.
• Interfaces bien définies entre les sous-modèles.
• Sémantique bien définie du modèle combiné.
• Les sous-modèles peuvent être réutilisés.
CPNs are an extension compatible with the foundational concept of Petri nets They retain the useful properties of Petri nets while expanding the original formalism to allow for the distinction between tokens.
Définition 2 : Réseaux de Pétri coloré (Color Petri Net) est un ensemble N (P, T, A, Sigma, C, N, E, G, I) ó :
• P est un ensemble de places
• T est un ensemble de transitions
• A est un ensemble de arcs
• Σ est un ensemble de couleurs définies dans le modèle CPN Cet ensemble contient toutes les couleurs possibles, les opérations et les fonctions utilisées dans CPN.
• C est une fonction de couleurs Il aligne les places dans P en couleurs dansΣ.
• N est une fonction de nœuds Il aligne A en (P×T) S (T× P).
E is an arc expression function that aligns each arc a ∈ A within the expression e The input and output types of arc expressions must match the types of the nodes to which the arc is connected By utilizing both the node function and the arc expression function, multiple arcs can connect the same pair of nodes with different arc expressions.
• G est une fonction de garde Il correspond à chaque transition t ∈ T dans l’expression de garde g La sortie de l’expression de garde doit évaluer la valeur booléenne vrai ou faux.
• I est une fonction d’initialisation Il mappe chaque emplacement p dans une expression d’initialisation i L’expression d’initialisation doit être évaluée à un ensemble de jetons avec une couleur correspondante à la couleur de l’endroitC(p)
Web sémantique
Logique de description
Description Logics (DL) are a family of formal languages used for knowledge representation They encompass concepts, roles, individuals, and their relationships within a specific domain A fundamental modeling concept in DL is the axiom, which is a logical statement that connects roles and/or concepts.
There are various types of description logic, and an informal naming convention exists The expressiveness is encoded in the label for a logic that begins with one of the following basic logics.
• AL, c’est la langue de base qui permet:
Négation atomique (négation des noms de concepts qui n’apparaissent pas sur le côté gauche des axiomes)
Restrictions existentielles (de quantification complète existentielle)
Suivi par l’une des extensions suivantes :
• F propriétés fonctionnelles, un cas particulier de quantification unique.
• F propriétés fonctionnelles, un cas particulier de quantification unique.
• E qualification complète existentielle (restrictions existentielles qui ont des charges autres que>).
• Hhiérarchie des rôles (subproperties - rdfs:subPropertyOf)
• R axiomes complexes d’inclusion de rôle complexes; La réflexivité et l’irréflexivité ; disjonction de rôle.
• O Les nominales (classes énumérées de restrictions de valeur d’objet - owl:oneOf, owl:hasValue).
• N restrictions de cardinalité (owl:cardinality, owl:maxCardinality)
• Qrestrictions de cardinalité qualifiées (disponibles dans OWL 2, restrictions de cardinalité qui ont des charges autres que>).
• (D)utilisation de propriétés de type de données, valeurs de données ou types de données
Certains DL qui ne correspondent pas exactement à cette convention sont:
• S une abréviation pour ALC avec des rôles transitifs.
• F L − une sous-langue deF L, qui est obtenue en refusant la restriction de rôle. Cela équivaut àAL sans négation atomique.
• F L o une sous-langue de F L − , qui est obtenue en refusant une quantification existentielle limitée.
Exemple 2.2: OWL 2 fournit l’expressivité deSROIQ ( D ) , OWL-DL est basé sur SHOIN ( D ) et pour OWL-Lite estSHIF ( D )
OWL
Figure 2.2: OWL et logique de description Source:[DL]
Figure 2.2 illustrates the equivalence between OWL syntax and description logic (DL) syntax, along with their semantics The OWL language is a proposed framework based on description logic, making it one of the key tools for semantic web applications.
2.2 Web sémantique 19 langages populaire du web sémantique Il est utilisé pour la représentation de con- cepts et de propriétés, en tant qu’exemples de concepts et de propriétés (atomiques) de base L’ensemble de ces concepts pour un domaine est la boợte terminologique(TBox) d’une ontologie Les assertions impliquant des concepts et des propriétés des individus forment la boợte d’assertion (ABox) de l’ontologie Le raisonnement est appliqué sur les deux, les définitions TBox et les assertions ABox.
SWRL
The Semantic Web Rule Language (SWRL) is a semantic web language designed for representing rules and logic As a subset of the Rule Markup Language, SWRL structures rules in the format: antecedent ⇒ consequent.
Les antécédents et conséquences sont des conjonctions d’atomes écrit a 1 ∧ ∧ a n Les variables sont indiquées en utilisant la convention standard de préfixation avec un point d’interrogation (par exemple, ?x).
Exemple 2.3: en utilisant cette syntaxe, une règle affirmant que la composition des propriétés parent etfrère implique la propriété de l’oncle serait écrite: parent(?x,?y) ∧ frère(?y,?z) ⇒ oncle(?x,?z)
Dans cette syntaxe, les relations intégrées fonctionnelles peuvent être écrites en notation fonctionnelle, c’est-à-dire, op: numeric-add (?X, 3,?z) peut être écrit plutôt que: x = op: numeric-add (3,?z)
Raisonneur
In this section, we provide a brief introduction to reasoners, which are tools capable of performing reasoning tasks typically based on RDFS, OWL, or rule engines They are utilized to verify the consistency of a knowledge base or to infer new knowledge from it Essentially, reasoners can be categorized into three groups based on their reasoning techniques.
• Dans la première classe de raisonneur DL traditionnels (par exemple, Racer- Pro [Gmb], Pellet [CL]), des algorithmes basés sur des tableaux sont utilisés pour implémenter le calcul d’inférence.
The second alternative involves reusing deductive database techniques by transforming an OWL ontology into a disjunctive data program and utilizing a disjunctive data engine for reasoning implemented in KAON2.
• La dernière classe de raisonneur - y compris Sesame [Adu] et OWLIM [Ont]
Utilize the standard rule engine to reason with OWL, as consequences often manifest when the ontology is loaded However, this process is generally restricted to less expressive fragments of the language.
Sesame [Adu] is an open-source repository designed for storing and querying RDF and RDFS information It efficiently handles OWL ontologies at the RDF graph level and connects to various DBMS, including MySQL, PostgreSQL, and Oracle, through the Storage and Inference Layer (SAIL) Sesame supports RDFS inference and enables querying using SeRQL, RQL, RDQL, and SPARQL Additionally, the SAIL allows for the extension of the system's inference capabilities.
OWLIM [Ont] is a semantic repository and reasoning engine packaged as SAIL for RDF databases It utilizes the TRREE engine for RDFS and OWL DLP reasoning, providing configurable reasoning support and performance In the "standard" version of OWLIM reasoning, known as SwiftOWLIM, query evaluation is conducted in-memory, while a persistence strategy ensures data preservation, consistency, and integrity.
KAON2 [oM] is a free Java reasoner for the SHIQ extension with the DL-safe fragment of SWRL Unlike most currently available DL reasoners, it does not implement tableau computation Instead, reasoning in KAON2 is achieved through innovative algorithms that simplify SHIQ(D) knowledge, enabling the application of well-established deductive database techniques.
HermiT [Gro] is a free reasoner for description logics, currently supporting DL SHIQ, with ongoing development for SHOIQ Its primary inference capability is the calculation of the subsumption hierarchy, and it can also determine the partial order of classes within an ontology HermiT employs a novel reasoning algorithm.
"hypertableau" L’aspect principal de cet algorithme est qu’il est beaucoup moins non déterministe que les algorithmes tableau existants.
The RacerPro system [Gmb] is an optimized tableau reasoner designed for SHIQ(D) that efficiently manages multiple TBoxes and ABoxes while treating individuals under the unique name assumption In addition to fundamental reasoning tasks like satisfiability and subsumption, it provides ABox queries based on nRQL optimizations The system is implemented in the Common Lisp programming language.
Pellet [CL] is a reasoner for SROIQ that utilizes simple data types It implements a decision-making procedure based on tables for general TBoxes, including subsumption, satisfaction, and classification, as well as ABoxes for retrieval and conjunctive query responses Pellet employs various optimizations for standard DL reasoning, similar to other DL reasoners, and directly supports entailment checks and optimized ABox queries through its interface.
Génie logiciel
Activités SDLC
Software Development Life Cycle (SDLC) fournit un ensemble d’étapes à suivre pour concevoir et développer un produit logiciel La figure 2.3 présente un cadre SDLC qui comprend les étapes suivantes :
C’est la première étape ó l’utilisateur effectue la demande d’un produit logiciel attendu Il communique avec le client et essaie de négocier le contrat et le terme.
Il envoie sa demande au client par écrit.
This stage is crucial in the software development process The team must engage in discussions with the client to thoroughly understand their challenges and gather as much information as possible regarding their needs The requirements are then clarified and documented in the user requirements document, which includes system and functional requirements.
After gathering requirements, the team will create a preliminary plan for the software process At this stage, they assess whether they can develop software that meets all user requirements or identify any issues that may enhance the software's utility Various established methods assist developers in evaluating the feasibility of a software product.
The Software Development Life Cycle (SDLC) phase is crucial for developers as they work to create the software model Following a thorough system analysis, the team can identify the strengths and weaknesses of the software product, pinpoint significant issues within the project, and clarify the project's scope Additionally, they must plan the strategy and allocate resources accordingly to ensure successful development.
This phase involves designing software products based on user requirements and analyses The user requirements and information gathered during the needs collection phase are utilized in this step, resulting in two possible outputs: logical design and physical design Engineers create the database, software diagrams, data flow diagrams, and some potential code.
This stage, known as the implementation phase, involves coding the software design in a specific programming language and effectively developing the program.
Before launching a software product, it is essential to thoroughly test all software development processes Errors can hinder the software's functionality or lead to incorrect outputs Early detection and resolution of these errors are crucial for developing high-quality software.
Le logiciel peut avoir besoin d’être intégré au programme externe ou à la source de données Cette étape de SDLC est l’intégration de logiciels avec un objet externe.
This stage involves deploying the software on a real system, ensuring it is configured to the user's environment During deployment, the software is verified for adaptability, and any integration issues are resolved.
Cette phase consiste à confirmer l’exécution du logiciel en termes d’efficacité et sans erreurs Les utilisateurs peuvent être formés, ou peuvent s’entraider avec le guide
2.4 SBVR 25 en utilisant le logiciel et comment maintenir l’exécution du logiciel Le logiciel est maintenu en modifiant le code en fonction des changements qui se produisent dans l’environnement ou de la technologie de l’utilisateur Dans cette phase, il existe des risques liés aux erreurs cachées et aux problèmes du monde réel.
Modèle à trois couches
Le modèle à trois couches pour le développement de logiciels est essentiellement une architecture décomposé à trois couches A savoir :
The presentation layer serves as the application's user interface (UI), typically consisting of an application form and interface, along with the HTML document generated by the web server for the client.
• Couche de Métier : la couche de métier applique la logique de l’application en utilisant le processus de métier (business process) Et la règle métier de la demande.
• Couche de données: la couche de données permet d’accéder à des systèmes externes tels que des bases de données.
SBVR
Using software and ensuring its continuous operation involves modifying the code to adapt to changes in the environment or user technology This phase carries risks associated with hidden errors and real-world issues.
Le modèle à trois couches pour le développement de logiciels est essentiellement une architecture décomposé à trois couches A savoir :
The presentation layer delivers the application's user interface (UI), typically consisting of an application form and interface, along with the HTML document generated from the web server to the client.
• Couche de Métier : la couche de métier applique la logique de l’application en utilisant le processus de métier (business process) Et la règle métier de la demande.
• Couche de données: la couche de données permet d’accéder à des systèmes externes tels que des bases de données.
The Semantics of Business Vocabulary and Business Rules (SBVR) is a meta-model designed for the development of semantic models related to business vocabularies and rules It establishes the vocabulary and guidelines necessary for documenting the semantics of business terms, facts, and rules Rooted in the Business Rules Manifesto, SBVR emphasizes that rules are based on facts, which in turn are grounded in concepts represented by terms Thus, terms convey business concepts, facts assert these concepts, and rules govern and support these assertions SBVR reinforces this framework by providing corresponding noun and verb concepts that align with the notions of terms and facts, as illustrated in its structural organization.
Un concept nominal est un concept signifiant un nom ou une expression nomi- nale, spécialisée par :
1 Types d’objets, qui sont des concepts de noms classifiant les choses en fonction de leurs propriétés communes ;
2 Concepts individuels, qui sont un concept correspondant à un seule type d’objet ;
3 Rôles, qui sont des concepts de noms correspondant à des éléments basés sur leur rôle de modèle, en supposant une fonction ou en étant utilisés dans certaines situations.
Additionally, fact-type roles are defined as roles that specifically characterize instances by their involvement in a given fact type A verb concept, also known as a fact type, signifies a verbal phrase that involves one or more noun concepts, representing unary, binary, or n-ary relationships.
Enfin, une règle SBVR est un élément d’orientation qui introduit une obligation ou une nécessité et distingue deux types généraux :
Ontologie pour l’ingénierie logicielle
Figure 2.5: Semantic of Business Vocabulary and Business Rules
• Rốges de structures : dộcrivant la faỗon dont l’entreprise choisit d’organiser les choses qu’elle traite;
Operational rules govern the conduct of activities by outlining business processes These rules are categorized into two types, which impose restrictions on the types of facts and utilize quantifiers and logical operators Figure 2.4 illustrates the structural organization of these quantifications and logical operations.
SBVR utilizes a linguistic approach to define vocabularies and express operational rules, introducing a Control Natural Language (CNL) known as SBVR Structured English It describes how to mechanically map these CNL expressions to the formal concepts of SBVR.
To facilitate the reader's understanding of this chapter, we will first present several accepted definitions in the realm of software engineering collaboration and semantic web, followed by a more detailed explanation in each subsection.
• Upper Ontology : upper ontology contient des concepts très généraux qui sont utilisés dans tous les domaines Ces domaines partagent des concepts
28 Chapitre 2 Contexte théorique communs d’une ontologie Cette ontologie fournit l’interopérabilité séman- tique à toutes les autres ontologies qui se situent en dessous [UPP],[AVR15].
Software Process Ontology encompasses various software development life cycle models and their associated stages, which are essential for effective software development Each stage is organized by a sequence of tasks, including prominent models such as the Waterfall Model, Prototype Model, Incremental Process Model, Rapid Application Development (RAD) Model, Iterative Enhancement Model, V Model, Spiral Model, and Agile Model.
Domain ontology provides essential knowledge specific to a particular field, such as the medical domain ontology, which encompasses the foundational concepts and relationships necessary for developing software applications within that area It illustrates the connections between various definitions related to the domain, effectively representing real-world relationships among different concepts.
System Behavior Ontology defines the behavior of an application by outlining typical requests made in various scenarios It includes the necessary conditions that must be met prior to executing a task and describes the system's state upon task completion.
Architecture Ontology encompasses the definition of architecture, including application styles, the main module of the application, the properties of that module, and their interrelations.
Pattern Ontology is a framework that models a collection of patterns utilized for application development It encompasses various elements such as design patterns, business process models, web application models, and use case models.
The Software Artifact Ontology defines various artifacts produced during application development, enabling their classification based on type or characteristics.
2.5 Ontologie pour l’ingénierie logicielle 29 formats tels que le code source, le fichier image, les manuels de documentation, etc [AdSdLdS04a], [AGS],[HKST06].
The Object Oriented Source Code Ontology represents key concepts related to Object-Oriented Programming (OOP) This ontology encompasses fundamental OOP principles such as abstraction, inheritance, polymorphism, and encapsulation Additionally, it includes essential elements like classes, interfaces, constants, data, functions, and objects, providing a comprehensive framework for understanding OOP concepts.
Document ontology encompasses the documentation related to the application, including various documents produced throughout different stages of development This includes formal descriptions, state diagrams, and control flow diagrams generated during the requirements analysis and specification phases, as well as flow diagrams and entity-relationship diagrams created during the design phase.
Testing ontology provides essential terminologies for testers, detailing the types of tests conducted, testing environments, and available testing techniques It may also include testing methodologies, encompassing various technical tests such as black-box testing (functional testing) and white-box testing (structural testing).
De nombreux niveaux pour tester le système, comme les tests unitaires, les tests d’intégration et les tests système.
3.1.3 Ontologie pour la réutilisation du logiciel 34
In this chapter, we discuss previous research on the application of ontology in software engineering While our focus is solely on the design phase of the software development lifecycle, we also present work that utilizes ontology in other phases of the software development process This approach aims to provide readers with a broader understanding of the research direction concerning the collaboration between software engineering and the semantic web.
Numerous existing ontologies have been proposed to apply to all phases of the software development life cycle, as detailed in a recent survey document [BKB16] In the following subsections, we will review the ontologies relevant to each phase of the software development life cycle.
Réutilisation du logiciel
Processus d’ingénierie de domaine
Domain engineering involves the collection, organization, and storage of knowledge gained from building systems or components within a specific domain, transforming this knowledge into reusable assets It also includes providing appropriate methods for reusing these assets in the development of new systems.
In the works from the 1980s and 1990s, such as [Nei80], [fAS93], [SCK + 96], [JGJ97], [GFd98], and [KKL + 98], a significant emphasis is placed on domain engineering processes aimed at developing reusable software.
Un exemple de ce travail peut être trouvé dans [Nei80] Dans ce travail,Neigh- borsa proposé la première approche d’ingénierie de domaine, ainsi qu’un prototype
- Draco - basé sur la technologie de transformation Les idées principales intro- duites par Draco comprennent : l’analyse de domaine, les langues spécifiques au
3.1 Réutilisation du logiciel 33 domaine et les composants en tant que séries de transformations Draco soutient l’organisation de la connaissance de la construction de logiciels dans un certain nom- bre de domaines connexes Chaque domaine Draco intègre les besoins, les exigences et les différentes implémentations d’une collection de systèmes similaires.
In 1992, Software Technology for Adaptable, Reliable Systems (STARS) developed the Conceptual Framework for Reuse Processes (CFRP) to facilitate understanding and application of the domain-specific reusable software engineering paradigm The CFRP established a framework for examining software engineering processes related to reuse, exploring their interconnections and integration with non-reuse processes to create lifecycle process models focused on reuse tailored to organizational needs.
Four years after the launch of the STARS project, Mark Simos [SCK + 96] and his team created the Organization Domain Modeling (ODM) method Their goal was to address gaps in domain engineering methods and processes, enabling the effective reuse of expert knowledge.
Three software development experts—Jacobson, Griss, and Jonsson—developed the Reuse-driven Software Engineering Business (RSEB) RSEB is a systematic reuse process that leverages UML notation and usage for effective software development.
La mộthode a ộtộ conỗue pour faciliter à la fois le dộveloppement de logiciels rộutil- isables orientés objet et la réutilisation de logiciels À l’instant duUnified Process
[JBR99], le RSEB est également itératif et axé sur l’utilisation.
Lignes de produits d’application
Until 1998, software reuse processes primarily focused on domain engineering issues However, during this period, a new trend emerged: application product lines Application product lines began to be recognized as one of the most promising advancements for efficient software development An application product line is defined as a set of software-intensive systems that share a common set of managed features, addressing the specific needs of a particular segment or market.
34 Chapitre 3 L’état de l’art mission de marché particulier et qui sont élaborés à partir d’un ensemble commun d’actifs de base de manière prescrite [20001].
The application product line has proven to be systematically reusable across similar products offered by software companies Several authors have discussed the main advantages of adopting application product lines.
Bayer et al proposed the Product Line Software Engineering (PuLSE) methodology, designed for the effective design and deployment of application product lines across various business contexts A key feature of PuLSE is its upward approach, which captures and leverages lessons learned from technology transfer activities with industrial clients According to Atkinson et al., PuLSE has been successfully implemented in diverse contexts for multiple purposes, demonstrating its value in enhancing existing development practices through robust documentation and development techniques.
Ontologie pour la réutilisation du logiciel
Despite extensive discussions on reuse in software engineering over the years among researchers and practitioners, there remains a general dissatisfaction with the current state of practice.
According to Uschold, an ontology can take various forms, but it must include a vocabulary of terms and specific definitions of their meanings This encompasses definitions and methods for explaining concepts that collectively impose a structure on the domain and constrain possible interpretations of interconnected terms Thus, an ontology consists of concepts, relationships, their definitions, properties, and constraints expressed through axioms.
[UJ99] a classé les applications des ontologies dans quatre catégories principales, soulignant qu’une application peut intégrer plus d’une de ces catégories :
• Autorisation neutre : une ontologie est développée en une seule langue, est traduite en différents formats et est utilisée dans plusieurs applications cibles.
Ontologie en ingénierie logicielle
Phase d’analyse des besoins
The first phase of the software development cycle involves gathering client requirements, which are then analyzed to extract key information for decision-making regarding the next development steps Research has focused on applying ontology to software requirements analysis There are two types of requirements: functional and non-functional Functional requirements specify the actions that a system performs, while non-functional requirements describe the quality aspects of the software system.
CK07b and MJ15 introduce two system behavior ontologies that illustrate how a system behaves in typical scenarios This type of ontology helps to clarify the activities a software application will perform in specific situations.
The UML use case diagram illustrates software scenarios, highlighting the interaction between the user and the software It addresses what actions the user will take and how the software responds in each use case In this context, the software is viewed as a "black box." [CK07b] suggests an approach to create a repository of use cases by leveraging the software's behavior and ontology.
36 Chapitre 3 L’état de l’art du domaine d’application.
RK15 proposes a method for reusing software requirements through the use of ontology, suggesting a mechanism to map current requirements in natural language to the axioms of an ontology for new software development WGGM14 presents an approach that treats software as an abstract artifact, separate from its code, utilizing upper ontologies to retrieve general terminologies for defining concepts and rules Numerous existing upper ontologies include IDEAS, WordNet, Bunge-Wand-Weber (BWW), and others, as highlighted by PK15b Requirements must be coherent, unambiguous, and verifiable, with various verification approaches available, such as viewpoint-based and scenario-based methods Domain ontology can play a crucial role in the software development lifecycle, aiding in requirements gathering and ensuring compliance with domain standards BdPL03 argues that ontologies should emerge as by-products of the requirements engineering phase, incorporating a specific subprocess for ontology construction inspired by layered ontology engineering approaches This process involves building a lexicon from relevant source documents and mapping important terms to appropriate ontological constructs used in the study's request.
3.2 Ontologie en ingénierie logicielle 37 l’ontologie partagent même certaines méthodologies communes Par exemple, le cadre d’ingénierie de l’ontologie DOGMA [STM] utilise une approche basée sur les scénarios pour créer des ontologies pour les domaines d’application.
Ontologies continue to play a role in the design phase, particularly through modeling, while requirements engineering employs various methodologies, including goal-oriented approaches, viewpoint-oriented strategies, and scenario-based techniques, or their combinations A critical aspect of this phase is the verification of requirements Existing research has explored the use of ontology-based approaches for requirements verification.
Phase de conception
The article discusses an ontology-based approach for constructing architectural documents, as presented in [dGTLvV12], which utilizes a software ontology within a semantic wiki optimized for architectural documentation This approach has been evaluated and shown to outperform file-based methods Additionally, [AT06] introduces a decision-centric software development approach that captures architecture through an ontology instance, comprising four key components: architectural assets, architectural decisions, stakeholder concerns, and an architectural roadmap Furthermore, [PGH07] proposes an ontological approach for modeling architectural styles using description logic as an abstract modeling tool, addressing the often-overlooked aspect of architectural styles in software architectures A framework for defining and combining styles is introduced [dG15] presents a thesis on representing architectural documents through ontology, comparing it with file-based approaches, while [dGLT + 14] describes a method for constructing an ontology for software architectural documentation Lastly, [AOAN12] focuses on reusing software processes based on software architectures, exploring reuse strategies informed by software architectures and domain ontology.
Chapter 3 discusses the state of the art in software architecture research within virtual community environments, utilizing a semantic search mechanism based on ontology to retrieve both architectural properties and the rationale behind software construction decisions A method described by [TRPR07] identifies key concepts in software architecture, employing semi-automatic techniques to analyze major architectural texts and Wikipedia pages This approach focuses solely on generic architectural knowledge Additionally, [WLS + 07] presents a modeling and verification approach for functionality diagrams using OWL ontologies, accurately capturing interrelations among functionalities OWL reasoning engines like FaCT++ are employed for fully automated checks of feature configuration inconsistencies, as noted in [ZDP09] Furthermore, [ZKDT09] offers a framework that represents, integrates, and validates distributed functionality models using OWL and SWRL.
Phase de développement
Sak06 proposes a model for information exchange between potential system users, including employers and prospective employees The goal of this work is to develop a public web service prototype that provides a simple and comprehensible means for these users to share information effectively.
This subsection presents software artifacts and object-oriented source code ontologies that can be implemented The Software Artifact Ontology characterizes the various artifacts created during the software development phase, allowing for their classification based on type or format, such as audio files or documents Additionally, this ontology can define concepts that include metadata, specifying the delivery stage of a particular artifact and the individual responsible for it.
The project is developed within a specific framework, and according to [ZDMP], once all metadata related to the delivered artifact is collected, both the ontology and the application domain ontology can be utilized for generating documentation.
Phase de test
This subsection discusses quality ontologies and testing ontologies that can be utilized to assess software quality characteristics, enhancing software development Several quality models and benchmarks have been established, such as the Capability Maturity Model (CMM), ISO 9001, and ISO/IEC 9126, which are instrumental in improving programming practices.
Phase de maintenance
The ontology of software maintenance defines key concepts related to maintenance and their interrelations It categorizes types of maintenance, including perfect, adaptive, and corrective maintenance, and outlines the procedures for maintaining software, encompassing maintenance activities Key roles involved in maintenance include maintenance engineers and managers, while relevant procedures encompass methods, techniques, and paradigms Additionally, resources such as human resources and client support are integral to the maintenance process The ontology can also model various maintenance frameworks, including the Iterative Enhancement Model, Reuse-Oriented Model, Boehm’s Model, and Taute Maintenance Model.
Reverse engineering is also performed for maintenance purposes, which involves discovering unknown and hidden information within software systems Utilizing model ontologies, software architecture, and object-oriented design ontologies can aid in uncovering this concealed information, as models often reveal the design style employed in the software system Additionally, semantic web approaches can be leveraged to estimate maintenance costs, with models such as the Belady and Lehman Model being applicable in this context.
The Boehm Model and related approaches aim to estimate software maintenance costs Research has demonstrated that a semantic web maintenance tool can be developed, utilizing a software maintenance ontology This tool captures metadata about software components, including both functional and non-functional requirements documentation, metrics, testing, and interactions between components When changes are made to any software component, it triggers the retrieval of all associated metadata to facilitate understanding and maintenance To achieve this, metadata is encoded in an RDF graph, and SPARQL queries are employed to enhance comprehension and maintenance efforts These SPARQL queries are designed to determine if a new validation of the modified software component is necessary, identifying which test case has failed and the corresponding requirement it relates to.
Conclusion
Research has highlighted the collaboration between software engineering and semantic web, demonstrating improved performance by leveraging semantic web advantages in software engineering An ontology has been integrated throughout all phases of the software development lifecycle, focusing on knowledge sharing and software reuse across various software products Additionally, ontology has been utilized to enhance software engineering techniques through knowledge representation, aiming to semantically depict documents, structures, and all lifecycle phases This approach enables the querying of knowledge to identify inconsistencies and ensure requirement accuracy.
Couche de métier fondée sur l’ontologie
Modélisation de couche de métier fondée sur l’ontologie
Introduction
4.2.1 Vérification des processus de métier 45 4.3 Processus de métier basé sur CPN 46
4.3.1 Construction de routage de base du processus de métier 46 4.3.2 Processus de métier basé sur un CPN 49 4.4 Vérification des processus de métier 54
4.4.1 Exemple d’impasse 54 4.4.2 Classification des impasses 55 4.5 Ontologie des processus de métiers 56
4.5.1 Modèle CPN-BP à l’ontologie OWL 2 56 4.5.2 Règles de vérification de la structure 64 4.6 Conclusion 66
In this chapter, we outline our approach to developing a business layer for an ontology-based application The primary goal is to enable users to design an executable business layer tailored to their needs A business process must utilize the terminologies defined in the business rule ontology, which will be introduced in the next chapter The business layer ensures accuracy during execution.
Chapter 4 discusses the modeling of a business layer based on ontology design, which can be integrated with a data source to simulate application execution This approach represents the business layer of an application in a machine-readable format, specifically using OWL ontology The main structure of the application is verified during both design and execution phases through business process knowledge and ontology reasoning This method significantly reduces application development time We utilize CPN as the control theory model in our work The proposed ontology is called "Business Process Ontology (BPO)" and consists of two main layers.
The meta layer defines all concepts of CPN and their relationships to create a CPN graph within BPO It consists of two main parts: the first part includes a set of concepts and properties that enable users to define a business process, while the second part comprises a set of structural rules to ensure that a business process is created without structural errors.
The individual layer encompasses business process instances, where each instance comprises a collection of CPN concept individuals from the meta layer This layer is governed by the meta layer, ensuring that any business process instance adheres to the concepts and rules established in the meta layer If a business process instance fails to comply with these guidelines, the ontology of the business processes will become incompatible, leading to the invalidation of that particular instance.
Ce chapitre est structuré comme suit :
• Dans la première partie, nous présentons le processus de métier basé sur CPN.
• Dans la deuxième partie, nous présentons notre algorithme pour détecter l’impasse d’un processus de métier afin d’assurer l’exactitude des processus de métier.
• Dans la dernière partie, nous présentons l’ontologie du processus de métier utilisée pour construire le processus de métier d’une application.
Travaux connexes
Vérification des processus de métier
Various verification methods are employed to assess business processes, with Petri nets being a prominent model-checking theory used to analyze distributed frameworks Petri nets feature an intuitive graphical notation along with a mathematical definition of their execution semantics Among the numerous subclasses of Petri nets, Workflow nets (WF) are significant for business process verification Another methodology is the Finite State Machine (FSM), which consists of a coordinated diagram of nodes and edges, where nodes signify system states and edges represent transitions between these states Additionally, generic models like SPIN and nuSMV2 enhance search algorithms to validate any demonstrated framework in model checking languages Temporal logics, including Linear Temporal Logic (LTL) and Computation Tree Logic (CTL), are also integral to the verification process.
GOSC11 initially provides a business process verification software that incorporates FCL logic, followed by an enhanced procedure for this software It features adaptable pockets within a critically determined process to illustrate the variability in design time, utilizing imperatives that yield demand and incorporation data not captured by formal logic Formal frameworks build their decisive details on temporal logic such as LTL and CTL DALV10 employs LTL to define a fully declarative process, while DGG+11 indicates a declarative process using answer set programming (ASP) and dynamic LTL Additionally, PvdA06 utilizes LTL to identify adaptable execution processes.
Various systems require clients to adopt newly proposed or extended specification logics to accurately define correct properties For instance, [PFS10] enhances CTL by differentiating between events and functions, [GMS06] introduces a completely new deontic logic, and [BLA11] presents an alternative temporal process logic.
46 Chapitre 4 Modélisation de couche de métier fondée sur l’ontologie pour permettre des fusions de processus.
Processus de métier basé sur CPN
Construction de routage de base du processus de métier
Figure 4.1: Bloc de base de la structure de routageDans la mesure du processus, les pièces de construction, par exemple, la
4.3 Processus de métier basé sur CPN 47
AND-Split, AND-Join, OR-Split, and OR-Join are essential for creating sequential, conditional, parallel, and iterative flows (WfMC [Coa96]) A business process can guide the direction of cases The next section will introduce four types of directions discussed in CPN: sequential, conditional, parallel, and iterative.
Sequential direction is a crucial management approach used to handle causal connections between tasks For instance, if transition B occurs after the completion of transition A, they are executed in sequence This sequential direction can be illustrated by incorporating places, as shown in Figure 4.2 A business process must have two exceptional points: an initial place (i) and a completion condition (o) These points represent the start state and the end condition of the business process A place models the causal connection between neighboring transitions A and B.
B, c’est-à-dire meti à une condition intérieure pour la place A.
Parallel direction is employed to define transitions that must occur simultaneously To model this parallel direction, two logical construction operators are utilized: (1) AND-Split and (2) AND-Join As illustrated in Figure 4.3, both logical construction operators can be implemented using standard structures.
48 Chapitre 4 Modélisation de couche de métier fondée sur l’ontologie
Conditional direction is utilized to account for varying orientations among cases To illustrate a decision between two alternatives, two logical operators are employed: (1) OR-Split and (2) OR-Join, both of which involve a selected OR An OR-Split is represented by a place with multiple active circular segments, while an OR-Join is depicted by a place featuring several continuous curves.
A trigger is an external action that initiates an activated transition The process for a specific case begins when the transition is triggered However, a transition can only be triggered if the corresponding case is in a state that allows for the transition to occur.
4.3 Processus de métier basé sur CPN 49
Dans cette section, nous distinguons quatre types de transitions.
Automatic triggers initiate transitions at the moment they are activated This type of trigger is utilized for transitions that are activated by an application, eliminating the need for human interaction.
• Client : une transition est déclenchée par un participant humain, c’est-à-dire qu’un utilisateur sélectionne une transition activée à déclencher.
An external event, such as a message, triggers an activated transition Examples of these messages include mobile calls, text messages, emails, and EDI messages.
• Temps: une transition activée est déclenchée par une horloge, c’est-à-dire que la transition est déclenchée à un temps prédéfini Par exemple, la transition
"supprimer le document" est déclenchée si une affaire est piégée dans un état spécifique pendant plus de 15 heures.
Ce n’est que pour la transition automatique que l’activation et le début réel de l’exécution cọncident.
Processus de métier basé sur un CPN
The definition of business processes based on CPN was introduced by W.M.P van der Aalst and has been widely utilized in research related to business process management In our solution, we expand upon van der Aalst's definition to apply it specifically to software engineering processes.
50 Chapitre 4 Modélisation de couche de métier fondée sur l’ontologie
The following definitions are tailored for a specific case in software engineering, highlighting the distinction between business processes in business process management and those in software engineering To adapt the CPN diagram for the software engineering domain, we propose an extension of CPN that incorporates properties enabling a CPN graph to interact with a data source, allowing tokens to be triggered by a query language.
Définition 1 : Un processus de métier basé sur CPN CPN−BP={P,T,F, P ,∆} est un CPN−BP si et seulement si :
• P a deux place spéciales : i et o Place i est un place source: • i=∅ Place o est un place de sortie: o•=∅ ;
• T est un ensemble de transitions ;
• P est un ensemble de couleurs définies dans le modèle CPN Cet ensemble contient toutes les couleurs possibles, les opérations et les fonctions utilisées dans le CPN
• Si nous ajoutons une transition t ∗ à CPN-BP qui relie l’emplacement o avec i, le réseaux de Pétri résultant est fortement connecté ;
• T a trois sous-ensembles: T−Get, T−Post et T−Control
– T−Get est un ensemble de transitions qui reỗoit le jeton pour obtenir les données d’une source spécifique.
– T−Post est un ensemble de transitions qui publie les données du jeton à une cible spécifique.
– T−Control est un ensemble de transitions qui contrôle le chemin d’exécution de l’application.
• ∆T représente une source de données qui sera utilisée pour interagir avec un graphe de CPN.
Lors de l’utilisation de CPN pour définir un processus de métier, les places correspondent à des conditions, les transitions correspondent à des tâches.
4.3 Processus de métier basé sur CPN 51
Définition 2 : Nous définissons deux types de jeton à savoir : external token Ex−Token et internal token In−Token:
• Externe−Token est un ensemble de jetons dont la valeur est remplie par des activités extérieures Nous classons ce type de jeton en deux ensembles :
– Typed Data token : ce type de jeton est la donnée saisie par l’utilisateur.
– Event Token : ce type de jeton est un événement, par exemple : email envoyé,
• Internal−Token est un ensemble de jetons qui a été transféré d’une transition précédemment lancée La valeur de ce jeton est remplie par une activité dans le graphe CPN
Définition 3 : (Firing Query) Chaque type de transition correspond à une Firing Query, le résultat d’une Firing Query est rempli dans un jeton prédéfini La Firing Query est classée comme suit:
• Si une transition est un T−Get, nous appelons la requête de tir Get Firing Query Get(FQ-G):
– GET ALL Color | ORDERBY Property | GROUP BY Property| HAVING Property
| GROUP BY Property| HAVING Property
• Si une transition est unT−Post, nous appelons la firing query Firing Query
– DELETEColor | WHERE Property=’Token Value’
– UPDATE Color SET Property=’External Token Value’ WHERE Property=’Token Value’
– SELECT Color WHEREProperty=’Token Value’
The firing query defined above facilitates interaction between a CPN graph and a relational database In this context, the firing query is represented in SQL format, and it can be substituted with an alternative query.
52 Chapitre 4 Modélisation de couche de métier fondée sur l’ontologie
SPARQL [W3Cc] pour récupérer les informations à partir d’une source de données sémantiques RDF.
Figure 4.6 illustrates a business process based on CPN, demonstrating the behavior of a television broadcasting website While it does not encompass all functionalities of such a site, it serves as a model to showcase our approach.
Exemple 1 : Processus de métier du site web de l’émission de télévision.
T={Load Home Page, New TV Show, Ongoing TV Show, Latest Update,
Login,AND−Join,Bookmark List, Profile, Request TV Show, Select TV Show, Episode, Logout, Change Password, OR−Join, Request Movies Confirmation }
T−Get={New TV Show,Ongoing TV Show,Latest Update,Bookmark
List,Profile,Select TV Show,Episode }
T−Post={Login,Request TV Show,Logout,Change Password }
T−Control={Load Home Page,Login,AND−Join,OR−Join }
P ={TV Show,User,Episode,Bookmark}
FQ-G-1= GET ALL TVShow ORDERBY AddedDate
FQ-G-2= GET ALL Ongoing Movie
FQ-G-3= GET ALL TVShow ORDERBY UpdatedDate
FQ-G-4= GET ALL Bookmark OF User
FQ-G-5= GET ALL Profile OF User
FQ-G-6= GET TVShow WHERE id=’Token Value’
FQ-P-1= SELECT User Where UserName=’Token value’ AND Password=’Token Value’
FQ-P-1= UPDATE User SET Password=’Token value’ Where UserName=’Token Value’
• Place i est l’état de début du processus.
4.3 Processus de métier basé sur CPN 53
Figure 4.6: Processus de métier pour le site web d’émission de télévision
• Transition Load Home Page est une transition AND−Split utilisée pour définir ces trois transitions New TV Show,Ongoing TV Show,Lastest Update doit être exécuté en parallèle.
• Transition Login présente la tâche de connexion du site, une fois que cette transition a été déclenchée, l’utilisateur peut exécuter trois transition
Bookmark List,Profile etRequest TV Shows.
• Transition Bookmark List permet à l’utilisateur de montrer sa liste d’émission de télévision favoris
• Transition Profile permet à l’utilisateur de montrer son profil.
• Transition Request TV Show permet à l’utilisateur de demander ses films préférés.
• Transition New TV Show est utilisé pour obtenir le nouvelle émission de télévision dans la base de données.
54 Chapitre 4 Modélisation de couche de métier fondée sur l’ontologie
• Transition Ongoing TV Show est utilisé pour sélectionner la série en cours dans la base de données.
• Transition Latest update est utilisé pour sélectionner l’émission de télévision mis à jour.