architecture des systèmes d'information. qui suis je?

Architecture des Systmes d'Information

Qui suis je?

3 Prsentation gnrale Prnom et Nom : Layth SLIMAN Titres et diplmes Doctorat en Informatique. Mastre en informatique, spcialit Systme dInformation. Diplme dIngnieur gnraliste en Informatique. Fonctions 2010- prsent: Enseignant-chercheur, EFREI- Paris. Jusqu' 2010: Chercheur, INSA Lyon.

Information system Les donnes sont la matire premire pour le SI. Avant dobtenir une info. Des donnes doivent tre cres et/ou collectes, stocker puis traites, analyses, reprsentes et diffuses. Le systme dinformation est caractris par ces fonctions: gnration, stockage, prsentation, change, interprtation, transformation, des informations.

Vision du SI centre sur les applications Les applications sont dveloppes de faon isole et les fonctionnalits fournisses sont utilisable seulement dans les applications qui les produisent. Les langages, les formats de donnes et les protocoles ont cr des barrires technologiques difficiles dpasser. Les entreprises ont perdues leurs flexibilit et agilit vis-- vis des changements dans le march. Le SI est devenu un problme plutt quune 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 utilise pour: Prendre des dcisions dachat. Aider choisir les solutions. Analyser les besoins. Guider lintgration. Dvelopper des nouveaux composants. Construire le systme. Comprendre et guider les changements.

Architecture 2/2 Elle focalise sur la cration des nouveaux systmes senss outiller une entreprise ou un mtier. Un rle cl de larchitecture est daider superviser, et coordonner les dveloppement des composants toute en gardant une vue densemble malgr la complexit du systme. En plus, larchitecture aide guider le changements dans les systmes existants. Le changement dans un systme dj cr est la plus part du temps plus compliqu que la cration dun nouveau systme.

Dfinition dun Systme dInformation On peut prendre comme point de dpart 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 : Systme dInformation (SI) Le SI reoit et centralise des informations provenant de diffrentes sources (financires, clients, fournisseurs ) les traite, les transforme, les stocke puis il les rpartit en fonction des besoins des utilisateurs ou des services.

Systmes dinformation dentreprise Les Systmes dInformation dentreprise offrent un cadre unifi autour duquel sarticulent tous les services de lentreprise. Ltude de larchitecture dun SI couvre les aspects suivants: Mthodologiques (architecture, modlisation, alignement mtier et stratgique) Oprationnels (gestion de projet, aide la dcision..) Technologiques (gestion des donnes, intgration, scurit, qualit de services).

Les couches d'un SI

La couche mtier Englobe l'ensemble des problmatiques lies l'excution des tches lies au mtier que le systme d'information est cens outiller. Il s'agit de la dfinition des Processus mtier les Procdures les Rgles mtier et les Objets mtiers qui doivent tre reprsents dans le systme d'information Concepts clefs : BPM, Modlisation Oprationnelle

Conception fonctionnelle Cette couche prcise comment accomplir les actes mtier que le systme d'information est sens excuter. Elle sintresse aux fonctions de la solution logicielle et pas la nature des applications informatiques. Ces fonctions ont encore une smantique mtier identifiable. Concepts clefs : Modlisation fonctionnelle

La couche d'architecture du Systme Essaie de comprendre quels composants logiciels peuvent s'assembler pour produire les actes mtiers dsirs ou attendues. Cette couche considre l'ensemble du systme d'information comme une unit qu'il faut dcomposer en modules. Ces modules sont des "produits" du march ou des nouveaux dveloppements qu'il faudra raliser. Concepts clefs :Conception Logicielle, Intgration, Urbanisation, SOA, Middleware.

Architectes des SI? Il sont des technologues ayant une bonne connaissance du mtier de lentreprise dun cot, et une connaissance structurelle et approfondie de l'offre en matire de solutions et de composants de solutions. Leur rle est multiple : Spcifier les besoins lis un mtier ou une entreprise. Rechercher et/ou concevoir des produits "candidats" la ralisation de chaque partie de la solution. Vrifier l adquation aux besoins des produits retenus. Superviser lintgration de ces produits, ceci veut dire : Garantir que les informations peuvent circuler entre les diffrents produits. Garantir que les traitements peuvent tre dclenchs de faon cohrente dans les diffrentes parties de la solution vis--vis la logique mtier. Enfin, proposer un pilotage globale de toutes ses parties.

Le rle du SI Collecte: cest l'ensemble des tches consistant dtecter, slectionner, acheminer, extraire et filtrer les donnes brutes issues des sources multiples et potentiellement htrognes. Dclenchement et supervision: dclencher les fonctions du systme en se basant sur les donnes collectes et en suivant la logique mtier tout en garantissant le bon fonctionnement de lensemble. Intgration: concentrer les donnes collectes dans un espace unifi, homogne, normalise et fiable. Diffusion: met les donnes la disposition des utilisateurs et des applications, selon le profil, le mtier et les besoins. Aide la dcision : transforme les donnes en conclusions fiables sur les faits actuels et sur les prvisions futures en appliquant des techniques d'analyse sophistiques.

Comptences requises Modlisation des Systmes dInformation Gestion de projet Outils et techniques de: Intgration, Interoprabilit, Collaboration Ingnierie Logicielle et Qualit Technologies des SI Bases De Donnes avances Gestion des risques Scurit et Control daccs

Les qualits de larchitecte SI Polyvalence (Mtier, Technique, Technologique..etc.) Esprit danalyse et de synthse Grande curiosit Rigueur Savoir communiquer, argumenter

Les cadres darchitecture Quest ce que cest un cadre darchitecture (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]TOGAF 8, OpenGroup

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

Zachman Framework John A. Zachman, Zachman International DATA Implementation DATA 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 FUNCTION Implementation 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 NETWORK Implementation 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 Implementation e.g., Master Schedule Time = Business Event Cycle = Business Cycle List of Organizations - Important to the Business People = Class of People and Major Organizations e.g., Work Flow Model People = Organization Unit Work = Work Product e.g., Human Interface Architecture People = Role Work = Deliverable e.g., Presentation Architecture People = User Work = Screen/Device Format e.g. Security Architecture People = Identity Work = Job ORGANIZATION Implementation STRATEGY Implementation e.g., Business Plan SCOPE Planner SYSTEM MODEL Designer TECHNOLOGY CONSTRAINED MODEL Builder DETAILED REPRESEN- TATIONS Subcontractor ENTERPRISE MODEL Owner contextual conceptual logical physical out-of-context FUNCTIONING ENTERPRISE perspectives abstractions

Prescribes Standards and Conventions StandardsRules Conventions Technical Standards View DoDAF An Integrated Architecture with Three Views Information Flow Operational Elements Activities/ Tasks Identifies What Needs To Be Done And Who Does It Operational View Systems Data Flow Communications X Y X Z X Y Y Relates Systems and Characteristics to Operational Needs Systems 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 - 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 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 dont 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.

Conceptual Model The model documents the architecture It all begins with the framework

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

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

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

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 diagramThe 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 diagramAn 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 treesTree-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.)

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 companys 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

FunctionActionProcess ActivityAct Operation ScenarioDecision Procedure Represented by UOB Verb-based Label Node #IDEF Ref # Processes

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

You have to turn on the computer before you can login. 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

There is an object (Part) that is common to both processes. Paint Part 1 2 Dry Part 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.

Commonly used relational (dashed) link relations: BeforeMeetsStartsTriggers DuringOverlapsCauses AfterFinishesEnables (a) 11 2 2 Relational Link (user-defined links ) Activity B 2 Activity A 1

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

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 X Exclusive Or Exactly one of the preceding (or following) will complete (or start). Junctions

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

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

Junction Type Meaning 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. Asynchronous AND Synchronous AND Asynchronous OR Synchronous OR XOR O X O & & Fan-in Junction Semantics Fan-out (Divergence)

Junction TypeMeaning 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. Asynchronous AND Synchronous AND Asynchronous OR Synchronous OR XOR O X O & & Fan-in (Convergence) Fan-out Junction Semantics

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

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 Pices entrent dans latelier de penture. Nous appliquons une trs lourde couche de peinture une temprature trs leve. La pice peinture est un four pour schage, en suite le test de couverture de peinture est effectu. Si le test rvle que la peinture qui a t pulvris sur la surface de la pice il ne suffit pas, la pice est r-achemine travers l'atelier. Si la pice passe l'inspection sans problme, il est achemin vers l'tape suivante du processus.

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

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.

Syntactically, a decomposition is just another IDEF3 process flow diagram. 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.

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.

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

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 Customer Places Order 1.1 Supplier Processes Order 2.1 Del. Svc. Transports Materials 3.1 Customer Rec./Dis. Materials 4.1 Purchase Order Example

Numbering 7 Receive purchase requisition 8.1 Approve request 9 Deny request 11 Approve partially X J4 Give for approval 8 Complete proposal Prepare proposal Evaluate request 8.1.44 8.1.458.1. 468.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).

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

Transition Arcs Object State Entry Conditions State Description Exit Conditions In the Object State Elaboration

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

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

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 Elaboration Form Process Label: Process Reference Number: Objects: Facts: Constraints: Description: Process Label Process #

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

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

Referents Referents draw the readers 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

... 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 Receive request for purchase Identify Supplier Referents

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

architecture des systèmes d'information. qui suis je?

Documents