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.
Page 4
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.
Page 5
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.
Page 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 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.
Page 7
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.
Page 8
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.
Page 9
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).
Page 10
Les couches d'un SI
Page 11
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
Page 12
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
Page 13
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.
Page 14
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.
Page 15
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.
Page 16
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
Page 17
Les qualits de larchitecte SI Polyvalence (Mtier, Technique,
Technologique..etc.) Esprit danalyse et de synthse Grande curiosit
Rigueur Savoir communiquer, argumenter
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 25
DODAF Products
Page 26
Page 27
Page 28
Page 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
Page 30
AV-1 & AV-2
Page 31
OV-2 Operational Node Connectivity Description
Page 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)
Page 33
OV-5 Operational Activity Model
Page 34
SV-1 System Interface Description
Page 35
TV-1 Technical Standards Profile
Page 36
References DoDAF elements of this presentation are obtained
from: DoD Architecture Framework Overview, Alessio Mosto, 2004
36
Page 37
Thank you for your attention!
Page 38
IS Architecture and IS Modelling
Page 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?
Page 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.
Page 41
Conceptual Model The model documents the architecture It all
begins with the framework
Page 42
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
Page 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
Page 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
Page 45
Page 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.
Page 47
Page 48
Page 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).
Page 50
Page 51
Page 52
Page 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.
Page 54
Page 55
Page 56
Page 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.)
Page 58
IDEF3 System Behavior Modeling
Page 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.
Page 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
Page 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.
Page 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.
Page 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.
Page 64
IDEF3 Overview Section 1:Basic Elements of the Process Diagram
Section 2:Documenting the Process Flow Section 3:Enhancing the
Process Description
Page 65
Basic Elements of the Process Diagram Processes Links
Junctions
Links Purpose Describe temporal, logical, conventional, or
natural constraints between processes Types of Links Simple
Precedence Object Flow Relation
Page 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
Page 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.
Page 70
Commonly used relational (dashed) link relations:
BeforeMeetsStartsTriggers DuringOverlapsCauses AfterFinishesEnables
(a) 11 2 2 Relational Link (user-defined links ) Activity B 2
Activity A 1
Page 71
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.
Page 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
Page 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 & J8 7.1 8.1 11.1 12.1 13.1 14.1 10.1
Junctions Example
Page 74
Taxonomy of Junctions Junctions Fan-inFan-out XOR (X)AND
(&)OR (O) Synchronous Asynchronous X & O & O
Page 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)
Page 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
Page 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
Page 78
Enhancing the Process Descriptions Scenario Scenario Objectives
Decompositions Object State Transmission Networks
Page 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).
Page 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 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.
Page 81
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
Page 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.
Page 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.
Page 84
Decomposition Decompositions allow you to break the process
into pieces which are stand- alone processes.
Page 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.
Page 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
Page 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
Page 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 8.1.44 8.1.458.1.
468.1.47
Page 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).
Page 90
Object State Transition Arc Referents Object State Label
AsynchronousSynchronousReferent Locator Referent Type/ID Locator
Referent Type/ID The IDEF3 OSTN Language
Page 91
Transition Arcs Object State Entry Conditions State Description
Exit Conditions In the Object State Elaboration
Page 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
Page 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)
Page 94
IDEF0 vs. IDEF3
Page 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.
Page 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
Page 97
IDEF0 vs. IDEF3
Page 98
Documenting the Process Flow Process Elaboration Objects
Referents Other Documentation
Page 99
Process Elaboration Elaboration Form Process Label: Process
Reference Number: Objects: Facts: Constraints: Description: Process
Label Process #
Page 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
Page 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
Page 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.
Page 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
Page 104
... 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
Page 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.
http://webs.twsu.edu/enteng/papers/howidef3.pdf