Architecture des Systèmes d'Information

Qui suis je? J’ai le plaisir de vous présenter ma thèse intitulé C-Business et Urbanisation d’entreprise effectué au sein du laboratoire LISP à l’INSA de Lyon

Présentation générale Prénom et Nom : Layth SLIMAN Titres et diplômes Doctorat en Informatique.  Mastère en informatique, spécialité Système d’Information. Diplôme d’Ingénieur généraliste en Informatique. Fonctions 2010- présent: Enseignant-chercheur, EFREI- Paris. Jusqu'à 2010: Chercheur, INSA Lyon.

Information system Les données sont la matière première pour le SI. Avant d’obtenir une info. Des données doivent être crées et/ou collectées, stocker puis traitées, analysées, représentées et diffusées. Le système d’information est caractérisé par ces fonctions: « génération, stockage , présentation, échange, interprétation, transformation, des informations. »

Vision du SI centrée sur les applications Les applications sont développées de façon isolée et les fonctionnalités fournisses sont utilisable seulement dans les applications qui les produisent. Les langages, les formats de données et les protocoles ont créé des barrières technologiques difficiles à dépasser. Les entreprises ont perdues leurs flexibilité et agilité vis-à- vis des changements dans le marché. Le SI est devenu un problème plutôt qu’une solution.

Architecture 1/2 “An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”IEEE STD 1471-2000 Elle est utilisée pour: Prendre des décisions d’achat. Aider à choisir les solutions. Analyser les besoins. Guider l’intégration. Développer des nouveaux composants. Construire le système. Comprendre et guider les changements.

Architecture 2/2 Elle focalise sur la création des nouveaux systèmes sensés outiller une entreprise ou un métier. Un rôle clé de l’architecture est d’aider à superviser, et coordonner les développement des composants toute en gardant une vue d’ensemble malgré la complexité du système. En plus, l’architecture aide à guider le changements dans les systèmes existants. Le changement dans un système déjà créé est la plus part du temps plus compliqué que la création d’un nouveau système.

Définition d’un Système d’Information On peut prendre comme point de départ un site web tel que celui de la SNCF, AIRFRANCE. Ces sites web ne sont que la partie visible de l'iceberg. L'iceberg, ici, c'est le : Système d‘Information (SI) Le SI reçoit et centralise des informations provenant de différentes sources (financières, clients, fournisseurs …) les traite, les transforme, les stocke puis il les répartit en fonction des besoins des utilisateurs ou des services.

Systèmes d’information d’entreprise Les Systèmes d’Information d’entreprise offrent un cadre unifié autour duquel s’articulent tous les services de l’entreprise. L’étude de l’architecture d’un SI couvre les aspects suivants: Méthodologiques (architecture, modélisation, alignement métier et stratégique) Opérationnels (gestion de projet, aide à la décision..) Technologiques (gestion des données, intégration, sécurité, qualité de services).

Les couches d'un SI

La couche métier Englobe l'ensemble des problématiques liées à l'exécution des tâches liées au métier que le système d'information est censé outiller. Il s'agit de la définition des « Processus métier » les « Procédures » les « Règles métier » et les « Objets métiers » qui doivent être représentés dans le système d'information Concepts clefs : BPM, Modélisation Opérationnelle…

Conception fonctionnelle Cette couche précise comment accomplir les actes « métier » que le système d'information est sensé exécuter. Elle s’intéresse aux « fonctions » de la solution logicielle et pas à la nature des applications informatiques. Ces fonctions ont encore une sémantique métier identifiable. Concepts clefs : Modélisation fonctionnelle

La couche d'architecture du Système Essaie de comprendre quels composants logiciels peuvent s'assembler pour produire les actes métiers désirés ou attendues. Cette couche considère l'ensemble du système d'information comme une unité qu'il faut décomposer en modules. Ces modules sont des "produits" du marché ou des nouveaux développements qu'il faudra réaliser. Concepts clefs :Conception Logicielle, Intégration, Urbanisation, SOA, Middleware.

Architectes des SI? Il sont des « technologues » ayant une bonne connaissance du métier de l’entreprise d’un coté, et une connaissance structurelle et approfondie de l'offre en matière de solutions et de composants de solutions. Leur rôle est multiple : Spécifier les besoins liés à un métier ou une entreprise. Rechercher et/ou concevoir des produits "candidats" à la réalisation de chaque partie de la solution. Vérifier l’ adéquation aux besoins des produits retenus. Superviser l’intégration de ces produits, ceci veut dire : Garantir que les informations peuvent circuler entre les différents produits. Garantir que les traitements peuvent être déclenchés de façon cohérente dans les différentes parties de la solution vis-à-vis la logique métier. Enfin, proposer un pilotage globale de toutes ses parties.

Le rôle du SI Collecte: c’est l'ensemble des tâches consistant à détecter, sélectionner, acheminer, extraire et filtrer les données brutes issues des sources multiples et potentiellement hétérogènes. Déclenchement et supervision: déclencher les fonctions du système en se basant sur les données collectées et en suivant la logique métier tout en garantissant le bon fonctionnement de l’ensemble. Intégration: concentrer les données collectées dans un espace unifié, homogène, normalisée et fiable. Diffusion: met les données à la disposition des utilisateurs et des applications, selon le profil, le métier et les besoins. Aide à la décision : transforme les données en conclusions fiables sur les faits actuels et sur les prévisions futures en appliquant des techniques d'analyse sophistiquées.

Compétences requises Modélisation des Systèmes d’Information Gestion de projet Outils et techniques de: Intégration, Interopérabilité, Collaboration Ingénierie Logicielle et Qualité Technologies des SI Bases De Données avancées Gestion des risques Sécurité et Control d’accès

Les qualités de l’architecte SI Polyvalence (Métier, Technique, Technologique..etc.) Esprit d’analyse et de synthèse Grande curiosité Rigueur Savoir communiquer, argumenter…

Les cadres d’architecture Qu’est ce que c’est un cadre d’architecture (Architecture Framework)? “A framework which guides the representation of the information system via views of models.” IEEE

Architecture Framework “An architecture framework is a tool… It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.” [TOGAF 8, OpenGroup]

Exemples de deux cadre d’architecture Zachman is a conceptual description of IS: MOTIVATION (Why) TIME (When) PEOPLE (Who) NETWORK (Where) FUNCTION (How) DATA (What) Abstractions Perspectives Objective/ Scope (Contextual) Enterprise Model (Conceptual) System (Logical) Technology (Physical) Detailed Model (Out of Context) Planner Owner Designer Builder Subcontractor Functioning Enterprise

Zachman Framework John A. Zachman, Zachman International FUNCTION DATA Implementation What FUNCTION How NETWORK Where e.g. Data Definition Entity = Field Rel. = Address e.g., Physical Data Model Entity = Tables/Segments/etc. Rel. = Key/Pointer/etc. e.g., Logical Data Model Entity = Data Entity Rel. = Data Relationship e.g., Semantic Model Entity = Business Entity Rel. = Business Relationship List of Things - Important to the Business Entity = Class of Business Thing List of Processes - the Business Performs Function = Class of Business Process e.g., Application Architecture Process.= Application Function I/O = User Views e.g., System Design Process= Computer Function I/O =Data Elements/Sets e.g. Program Process= Language Statement I/O = Control Block e.g., Business Process Model Process = Business Process I/O = Business Resources List of Locations - in which the Business Operates Node = Major Business Location e.g., Logistics Network Node = Business Location Link = Business Linkage e.g., Distributed System Architecture Node = IS Function Link = Line Characteristics e.g., Technical Architecture Node = Hardware/System Software Link = Line Specifications e.g. Network Architecture Node = Addresses Link = Protocols MOTIVATION Why TIME When PEOPLE Who e.g. Rule Specification End = Sub-condition Means = Step e.g., Rule Design End = Condition Means = Action e.g., Business Rule Model End = Structural Assertion Means =Action Assertion End = Business Objective Means = Business Strategy List of Business Goals and Strategies Ends/Means=Major Business Goal/Critical Success Factor List of Events - Significant to the Business Time = Major Business Event e.g., Processing Structure Time = System Event Cycle = Processing Cycle e.g., Control Structure Time = Execute Cycle = Component Cycle e.g. Timing Definition Time = Interrupt Cycle = Machine Cycle SCHEDULE e.g., Master Schedule Time = Business Event Cycle = Business Cycle List of Organizations - People = Class of People and Major Organizations e.g., Work Flow Model People = Organization Unit Work = Work Product e.g., Human Interface People = Role Work = Deliverable e.g., Presentation Architecture People = User Work = Screen/Device Format e.g. Security Architecture People = Identity Work = Job ORGANIZATION STRATEGY e.g., Business Plan SCOPE Planner SYSTEM MODEL Designer TECHNOLOGY CONSTRAINED Builder DETAILED REPRESEN- TATIONS Subcontractor ENTERPRISE Owner contextual conceptual logical physical out-of-context FUNCTIONING perspectives abstractions

DoDAF An Integrated Architecture with Three Views Information Flow Operational Elements Activities/ Tasks Identifies What Needs To Be Done And Who Does It View Systems Data Flow Communications X Y Z Relates Systems and Characteristics to Operational Needs View Prescribes Standards and Conventions Standards Rules Technical Standards View

DODAF Products DoDAF describes a set of 26 work products to ensure uniformity and standardization in the documentation and communication of architecture The 26 DODAF views are designed to document the entire architecture, from requirements to implementation

DODAF Products - Views The list of products is refined into four views: All Views (AV): is the overarching information describing the architecture plans, scope, and definitions Operational View (OV): focuses on the behaviours and functions describing the enterprise mission aspects System View (SV): describes the system and applications supporting the mission functions Technical Standards View (TV): describes the policies, standards and constraints

DODAF Products

DODAF Products

DODAF Products

DODAF Products - Essential The current DODAF version indicates a subset of work products that should be developed at a minimum (essential) AV-1: Overview and Summary Information AV-2: Integrated Dictionary OV-2: Operational Node Connectivity Description OV-3: Operational Information Exchange Matrix OV-5: Operational Activity Model SV-1: System Interface Description TV-1: Technical Standards Profile

AV-1 & AV-2

OV-2 – Operational Node Connectivity Description

OV-3 – Operational Information Exchange Matrix Table Headers Specified in Framework: Name of Operational Needline Supported (from OV-2) Name of Information Exchange Nature of Transaction (Mission/Scenario, Language, Content, Size/Units, Media, Collaborative or One-Way?) Purpose or Triggering Event Information Source (ID of Producing Node Element, Owning Organization of Node, Name of Producing Activity, UJTL ID) Information Destination (ID of Receiving Node Element, Owning Organization of Node, Name of Receiving Activity, UJTL ID) Performance Requirements (Frequency, Timeliness, Throughput, Other) Information Assurance Attributes (Classification Restrictions, Criticality/Priority, Integrity Checks Required, Assured Authorization to Send/Receive) Threats (Physical, Electronic, Political/Economic) Operational Environment (Weather, Terrain, Policy/Doctrine Constraints)

OV-5 – Operational Activity Model

SV-1 – System Interface Description

TV-1 – Technical Standards Profile

References DoDAF elements of this presentation are obtained from: DoD Architecture Framework Overview, Alessio Mosto, 2004 La première réponse historique à la rationalisation du SI est la démarche dite l’urbanisation . L’urbanisation des SI travaille sur : Processus métiers Communications inter applicative Sur la mise en place d’un référentiel transverses Resulat : Le système d’information d’une entreprise est représenté selon quatre niveaux d’architecture: L’architecture métier : processus métier de l’entreprise L’architecture fonctionnelle : blocs fonctionnels et flux d’information supports à la réalisation des processus métier, indépendamment des technologies mises en œuvre, L’architecture applicative : blocs applicatifs et échanges, supports à la réalisation des blocs fonctionnels et des flux. L’architecture technique : infrastructure sur laquelle sont implémentées et exécutés les blocs fonctionnels . Objectif est d’avoir une vue d’ensemble du SI 36 36

Thank you for your attention!

IS Architecture and IS Modelling

What is Modelling? Modelling is a way of simplifying the real world to enable us to solve problems. We do it all the time and so easily that we don’t even notice we are doing it. For example, a city map is a model of a city, a program is a model of how a task is achieved, and even a calendar is a model of a month. People use these models to solve problems, such as ‘What is the shortest route?’ ‘How long until my birthday?’

Modelling and Architecture Relation to Architecture? Architecture is a definition of a specific information system via models. How does this relate to an information system implementation? The model guides the implementation. The models describe parts or aspects of a system. A set of models that together define the essentials of a system is called the architecture of the system.

It all begins with the framework Conceptual Model It all begins with the framework Architecture Framework Enterprise Stakeholder Mission 1 1..* defines Requirement scopes holds Architecture Description Information System fulfills guides Architecture represents documents implements Model View specifies describes System Description Artifacts comprise contains The model documents the architecture

Framework Components A logical structure for classifying and organizing the models of an enterprise Architecture Framework Architecture Description Architecture represents documents Model View 1 1..* specifies describes Artifacts comprise A formal definition of an enterprise system Contains the views that are used to describe the architecture One or more abstractions e.g., Planner, Owner, Designer, Builder, Subcontractor The basic elements Representations of the Data, Function, Network, People, Time, and Motivation

Conceptual Description of: MOTIVATION (Why) TIME (When) PEOPLE (Who) NETWORK (Where) FUNCTION (How) DATA (What) Abstractions Perspectives Objective/ Scope (Contextual) Enterprise Model (Conceptual) System (Logical) Technology (Physical) Detailed Model (Out of Context) Planner Owner Designer Builder Subcontractor Functioning Enterprise

Modelling Approaches DoDAF CIMOSA, PERA GRAI, IDEF3, BPMN IDEF0 Architecture Framework: Guiding architecture CIMOSA, PERA Architecture Integration: integration of the different enterprise views. GRAI, IDEF3, BPMN Process Modelling: behavioural aspects, Decisional System. IDEF0 Functional Modelling: high-level activities of process. . UML,IDEF4, IDEF1, IDEF1X IT Oriented: information and application modelling.

Enterprise Modeling Using IDEF0 IDEF stands for Integration Definition for Process Modelling, a methodology used to model businesses and their processes so they can be understood and improved it aims at: Create description of enterprise for the purpose of gaining understanding, and of being able to answer questions about the enterprise. Used to describe enterprise and its environment prior to, or in conjunction with, defining requirements. Used to precisely define boundaries of system (i.e., what is in and out of scope for the project under consideration). Model the enterprise from a particular "viewpoint", or perspective, so as to keep the activity focused on the goal of effort and on pertinent characteristics of interest in enterprise. Create a description of the enterprise with a single subject, single purpose (exemplified by questions to be answered about the enterprise), and single viewpoint. Note that, during Project “scoping” activity, the viewpoint is most likely that of looking at the enterprise from the standpoint of the client-server application to be deployed in the enterprise.

IDEF0 Notations Input objects (can be transformed or modified by the activity) like data or raw material. Control inputs (procedures, rules or constraints) used to define how the activity will be executed. These inputs cannot be modified by the activity. Output objects (data or materials) are the physical or informational objects produced or modified by the activity. Mechanisms: represent the necessary means to support the execution of the activity (human resources, machines or applications).

IDEF0 diagrams IDEF0 typically includes: Context diagram—The topmost diagram in an IDEF0 model. It delineates the boundaries of the portion of the enterprise under consideration, and is defined for the viewpoint. Parent/child diagram—An IDEF0 decomposition hierarchy using parent/child relationships. Node numbers: means for identifying and tracking individual activities in the model. Provides a means for associating activity boxes in a parent diagram with the diagram and activity components of children (e.g., EPR/A12, indicates EPR project, activity 1, sub-activity 2 of the decomposed top-level diagram). Node trees—Tree-like structures of nodes rooted at a chosen node and used to represent a full IDEF0 decomposition in a single diagram.

IDEF0 Drawback The abstraction away from timing, sequencing and decision logic leads to comprehension difficulties for the people outside the domain. Solution is IDEF3: captures the behavioral aspects of an existing or proposed system.” (temporal information, including precedence and causality relationships associated with enterprise processes.)

System Behavior Modeling IDEF3 System Behavior Modeling

Importance of Process It is not the products, but the processes that create products, bring companies long- term success. Process: Ordered sequence of activities triggered by events. Business Process: Ordered sequence activities involving people, materials, energy, and equipment that is designed to achieve a defined business outcome.

Motivation for Process Modeling “Underlying the operations of every company--working like its spine-- is its Value Delivery System. A company’s performance is the direct result of how effectively this system is structured and managed.” — George Stalk, Jr. & Thomas M. Hout From BPR Literature

What is a Process Model? “Simply, the Process Model is the way that the work is divided in a value delivery system.” — James B. Swartz A representation of a process and its related components presented in a time-dependent fashion. It also represents the decision logic that exists within the system.

Benefits of Process Modeling Document current processes for standardization. Provide guidelines for new process members to reduce the learning curve. Capture and analyze AS-IS processes. Design / redesign process for TO-BE scenarios. Test the design (Simulation) of a new process before committing to an expensive development project.

What is IDEF3? The Process Description Capture Method. The Object State Transition Description Method. Supports descriptions at any desired level of detail through Decompositions. Employs the concepts of Scenarios to simplify the structure of complex process flow descriptions. Supports the capture of multiple viewpoints.

IDEF3 Overview Section 1: Basic Elements of the Process Diagram Section 2: Documenting the Process Flow Section 3: Enhancing the Process Description

Basic Elements of the Process Diagram Processes Links Junctions

Processes Function Action Process Activity Act Operation Scenario Decision Procedure Represented by UOB Verb-based Label Node # IDEF Ref #

Links Purpose Types of Links Describe temporal, logical, conventional, or natural constraints between processes Types of Links Simple Precedence Object Flow Relation

Precedence Link Express simple temporal precedence between instances of one process type and another. Each instance of the source process will complete before the paired instance of the destination process can begin. 1 2 Turn on computer Login You have to turn on the computer before you can login.

Object Flow Link Has the same temporal semantics as a precedence link. Indicates the participation of an object in two process instances. Lack of an Object Flow link does not preclude the existence of an object participation between two processes. Paint Part 1 2 Dry Part There is an object (Part) that is common to both processes.

Relational Link (user-defined links ) Commonly used relational (dashed) link relations: Before Meets Starts Triggers During Overlaps Causes After Finishes Enables Activity B 2 Activity A 1 (a) 1 1 2 2

Junctions IDEF3 junctions show convergence or divergence of multiple process flows and their timing. 2 Fan-in junction 4 3 5 6 1 Fan-out junction J1 J2

Junctions Asynchronous And — All preceding (or following) actions must complete (or start). Synchronous And — All preceding (or following) actions must complete (or start) simultaneously. & & Asynchronous Or — One or more of the preceding (or following) will complete (or start). Synchronous Or — One or more of the preceding (or following) will complete (or start) simultaneously. O O Exclusive Or — Exactly one of the preceding (or following) will complete (or start). X

Junctions Example Receive purchase requisition Approve request Enter into computer Place the order Fill P.O. X J4 & J7 & J8 7.1 8.1 10.1 13.1 15.1 Deny request Assign a P.O.# 9.1 14.1 Partially approve Rework purchase request Goto/Receive purchase requisition 11.1 12.1 7/1

Taxonomy of Junctions Junctions Fan-in Fan-out XOR (X) AND (&) OR (O) Synchronous Asynchronous X & O

Fan-in Junction Semantics Fan-out (Divergence) Junction Type Meaning & — Asynchronous “AND” All succeeding process paths will eventually start. All succeeding process paths will start together. One or more of the following process paths will eventually Start. There will be a synchronized initiation of one or more process paths. Exactly one of the following process paths will be initiated, and only the processes on that path will happen. & — Synchronous “AND” O — Asynchronous “OR” O — Synchronous “OR” X — “XOR”

Fan-out Junction Semantics Fan-in (Convergence) Junction Type Meaning & — Asynchronous “AND” All preceding processes must complete. All preceding processes will complete simultaneously. One or more of the preceding processes will complete. One or more of the preceding processes will complete simultaneously. Exactly one of the preceding processes will complete. — Synchronous “AND” & O — Asynchronous “OR” — Synchronous “OR” O X — “XOR”

Review Process Junctions Links Function Process Verb-based label Activity Operation Action Event Process Verb-based label Process # IDEF Ref # Junction type Asynchronous Junctions Junction type Synchronous Precedence Link Relational Link Object Flow Link Links

Enhancing the Process Descriptions Scenario Scenario Objectives Decompositions Object State Transmission Networks

Scenarios Scenarios are the organizing structure for IDEF3 descriptions. A scenario represents a commonly occurring situation. Business events that we are specifically planning for. Different views can be different scenarios. A base scenario is always needed (objective view).

Scenarios Organizing Structure of a Scenario A scenario can be thought of as a recurring situation, a set of situations that describe a typical class of problems addressed by an organization or system, or the setting within which a process occurs. Example Scenario: Les Pièces entrent dans l’atelier de penture. Nous appliquons une très lourde couche de peinture à une température très élevée. La pièce peinture est un four pour séchage, en suite le test de couverture de peinture est effectué. Si le test révèle que la peinture qui a été pulvérisé sur la surface de la pièce il ne suffit pas, la pièce est ré-acheminée à travers l'atelier. Si la pièce passe l'inspection sans problème, il est acheminé vers l'étape suivante du processus.

Paint Shop Example “Painting a part in the company paint shop.” Go-To/ 1 2 3 X Dry Test coverage Go-To/ Paint part 1/1 4 Route to next stop “Painting a part in the company paint shop.”

Scenario Objectives Viewpoint Determines what can be seen and from what perspective. Purpose Establishes the goal of the communication intended by the description. Defines why the description is being developed, and specifies how it will be used. Context Establishes the subject of a description. Establishes the subject as a part of a larger whole. Creates a boundary within the environment.

Decomposition Purpose Decreases complexity of a diagram. Enables the capture of descriptions at varying levels of abstraction. Provides the ability to model the same process from different knowledge sources or different points of view. Syntactically, a decomposition is just another IDEF3 process flow diagram.

Decomposition Decompositions allow you to break the process into pieces which are stand-alone processes.

Decomposition Types Objective view: Multiple view decompositions may be consolidated into an objective view--the view perceived by a neutral observer. There can be only one objective view. Role view: The view of a process as understood by, or from the perspective of, one individual, role type, or functional organization. There may be more than one role view of a process.

Purchase Order Example Customer Places Order 1.1 Supplier Processes Order 2.1 Del. Svc. Transports Materials 3.1 Customer Rec./Dis. Materials 4.1 Top-level Scenario: Order Process

Purchase Order Example Customer Places Order Supplier Processes Order Del. Svc. Transports Materials Customer Rec./Dis. Materials 1.1 2.1 3.1 4.1 Decomposition: Customer Places Order Sys. Cross Ref. Part # w/Order Details Open Channel/Send File to Target Printer Operator Enters Item Description System Generates Pick Ticket File

Numbering Evaluate request Prepare proposal Complete proposal Give for Receive purchase requisition Approve request X J4 7 8 8.1 Deny request 9 Approve partially 11 Evaluate request Prepare proposal Complete proposal Give for approval 8.1.44 8.1.45 8.1. 46 8.1.47

Analyzing Objects & Object States Objects and their related processes can be studied in an object-centered view by using the Object State Transition Network (OSTN).

The IDEF3 OSTN Language Object State Transition Arc Referents Object Label Object State Transition Arc Referents Locator Referent Type/ID Asynchronous Synchronous Referent Referent

The IDEF3 OSTN Language Transition Arcs Object State In the Object Entry Conditions State Description Exit Conditions In the Object State Elaboration

OSTN Diagram OSTN Referent Object Scenario State II Referent Object State IV UOB Referent Object State I Object State III Allows construction of an object-centered view Summarizes allowable transitions of an object in the domain Used to document data life cycles Cuts across the process flow diagrams Characterizes dynamic behavior of objects

Paint Shop Scenario: Paint OSTN (Focus Object: Paint) covered by new layer Scenario Referent 1 Liquid paint in machine Solid paint on part UOB/Test coverage 3 UOB Dry part 2 Paint covered by polish UOB/Test coverage 3

IDEF0 vs. IDEF3

When To Do IDEFØ Before IDEF3 When definite precedence or flow logic does not appear in the description When the interviewee tells you what she does, not how she does it When there are no clear separations between the activities being described When policy rather than procedure is being described.

When To Do IDEF3 Before IDEFØ When the descriptions are very procedural or detailed in nature Where logical or precedence sequences form a major portion of the acquired description When the domain expert describes the timing and/or logic of a process When the domain expert focuses on objects and their flow or participation in the environment

IDEF0 vs. IDEF3

Documenting the Process Flow Process Elaboration Objects Referents Other Documentation

Process Elaboration Process Label Process # Elaboration Form Process Reference Number: Objects: Facts: Constraints: Description: Process Label Process #

Elaboration Documentation Refers To Elaboration Form UOB Name Objects Facts Each UOB has an elaboration form that provides the defining characterization of the real-world process Constraints Description

Objects Linked to a Process Paint Part Object Types Instances of Object Types Entity Location Resource Queue Transport Paint/Part Paint Booth Operator Part Queue Conveyor

Referents Referents draw the reader’s attention to an important point or note. Referents are often used to: Point to other model elements without showing an explicit process flow. Indicate a “Go-To” or “Call and Wait” location in complex process flows. Specify constraints on junctions. Provide links to Object State Transition Networks.

Referents Referents are an easy way to express ideas or concepts in lieu of junction types, dashed arrows, or constraint language statements. Referents represent objects or information critical to the completion of a scenario or Process Flow diagram. Referents allow you to specify the following in the model: Span multiple pages or loop back in a diagram layout (Go To), Refer to a previously defined Operational Activity without duplication of its definition. This indicates that another instance of this Operational Activity occurs at a specific point in the process (without loop back) (Operational Activity), Emphasize the participation of particular objects or relations in a Operational Activity (Object), Associate special constraint sets to junctions; that is, associate an elaboration with a junction to describe additional facts, constraints, or decision logic which limit how that junction works (Junction), and

Referents . . . simply point the reader to some other aspect of the model that needs to be considered. & 1 2 3 4 5 J1 J2 Object: Pur. Req. Scenario / Ordering Contracted parts Object / Contracted Parts Receive request for purchase Prepare and dispatch purchase order Negotiate price with vendor Identify Supplier

Other Documentation Glossary Textual descriptions of the process elements. Sources Source material used in the construction of the process description. Notes Annotations resulting from the model review process. http://webs.twsu.edu/enteng/papers/howidef3.pdf