Architecture des Systèmes d'Information. Qui suis je?
Preview:
Citation preview
- Page 1
- Architecture des Systmes d'Information
- Page 2
- Qui suis je?
- Page 3
- 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
- Page 66
- FunctionActionProcess ActivityAct Operation ScenarioDecision
Procedure Represented by UOB Verb-based Label Node #IDEF Ref #
Processes
- Page 67
- 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