La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Architecture des Systèmes d'Information. Qui suis je?

Présentations similaires


Présentation au sujet: "Architecture des Systèmes d'Information. Qui suis je?"— Transcription de la présentation:

1 Architecture des Systèmes d'Information

2 Qui suis je?

3 3 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 dInformation. Diplôme dIngénieur généraliste en Informatique. Fonctions présent: Enseignant-chercheur, EFREI- Paris. Jusqu'à 2010: Chercheur, INSA Lyon.

4 Information system Les données sont la matière première pour le SI. Avant dobtenir 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 dinformation est caractérisé par ces fonctions: « génération, stockage, présentation, échange, interprétation, transformation, des informations. »

5 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 quune solution.

6 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 Elle est utilisée pour: Prendre des décisions dachat. Aider à choisir les solutions. Analyser les besoins. Guider lintégration. Développer des nouveaux composants. Construire le système. Comprendre et guider les changements.

7 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 larchitecture est daider à superviser, et coordonner les développement des composants toute en gardant une vue densemble malgré la complexité du système. En plus, larchitecture 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 dun nouveau système.

8 Définition dun Système dInformation 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 dInformation (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.

9 Systèmes dinformation dentreprise Les Systèmes dInformation dentreprise offrent un cadre unifié autour duquel sarticulent tous les services de lentreprise. Létude de larchitecture dun 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).

10 Les couches d'un SI

11 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…

12 Conception fonctionnelle Cette couche précise comment accomplir les actes « métier » que le système d'information est sensé exécuter. Elle sinté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

13 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.

14 Architectes des SI? Il sont des « technologues » ayant une bonne connaissance du métier de lentreprise dun 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 linté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.

15 Le rôle du SI Collecte: cest 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 lensemble. 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.

16 Compétences requises Modélisation des Systèmes dInformation 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 daccès

17 Les qualités de larchitecte SI Polyvalence (Métier, Technique, Technologique..etc.) Esprit danalyse et de synthèse Grande curiosité Rigueur Savoir communiquer, argumenter…

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 DODAF Products

26

27

28

29 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

30 AV-1 & AV-2

31 OV-2 – Operational Node Connectivity Description

32 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)

33 OV-5 – Operational Activity Model

34 SV-1 – System Interface Description

35 TV-1 – Technical Standards Profile

36 References DoDAF elements of this presentation are obtained from: DoD Architecture Framework Overview, Alessio Mosto,

37 Thank you for your attention!

38 IS Architecture and IS Modelling

39 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?

40 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.

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

42 Framework Components Architecture Framework Architecture Description Architecture represents documents Model View * 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

43 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

44 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

45

46 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.

47

48

49 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).

50

51

52

53 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.

54

55

56

57 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.)

58 IDEF3 System Behavior Modeling

59 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.

60 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

61 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.

62 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.

63 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.

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

65 Basic Elements of the Process Diagram Processes Links Junctions

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

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

68 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

69 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.

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

71 2 Fan-in junction Fan-out junction J1 J2 Junctions IDEF3 junctions show convergence or divergence of multiple process flows and their timing.

72 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

73 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 & J Junctions Example

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

75 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)

76 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

77 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

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

79 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).

80 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 latelier 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.

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

82 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.

83 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.

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

85 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.

86 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

87 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

88 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

89 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).

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

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

92 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

93 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)

94 IDEF0 vs. IDEF3

95 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.

96 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

97 IDEF0 vs. IDEF3

98 Documenting the Process Flow Process Elaboration Objects Referents Other Documentation

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

100 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

101 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

102 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.

103 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

104 ... simply point the reader to some other aspect of the model that needs to be considered. & 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

105 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.


Télécharger ppt "Architecture des Systèmes d'Information. Qui suis je?"

Présentations similaires


Annonces Google