Upload
truongthuan
View
224
Download
0
Embed Size (px)
Citation preview
Richard Martin
Tinwisle Corporation
Bloomington, Indiana
© Copyright 2010 by R. Martin and E. Robertson
Edward Robertson
Computer Science Program
Indiana University and
Persistent Systems
Science of Enterprise Modeling:
An Informatic Perspective
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective1
General Principles
1. Models are formal artifacts developed and used by people.
2. A complexity tradeoff exists between modeling medium and model instances in that medium.
3. Naming serves as the bridge between the formal and the human.
4. Do not confuse meta-levels - separate model and instance decompositions
5. Dependency is not chronology
6. Don’t hide architecture in methodology.
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective2
Framework Principles
7. Frameworks organize artifacts to facilitate understanding.
8. To improve quality, distinguish structure from connectivity.
9. Separate policy from mechanism.10. Both grid (ordinant) and tree (decomposition)
structures appear in models.11. Scale dimensions include:
abstractness (abstract to concrete), scope (general to special) andrefinement (coarse to fine).
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective3
Framework Principles12. Within a framework, use of components are
driven along one ordered dimension.13. Along this ordered dimension, all prior
context is relevant.14. Refinement is recursive.15. Connections can be of arbitrary arity.16. Views are important in standards and
methodologies.17. Views are used both to “see” contents and to
“create” contents.18. Separate model and instance constraints.
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective4
Meta Process Principles19. Framework are developed by
transformations.20. Transformations include: Projection Instantiation Refinement Specialization Derivation Linking
21. Transformation use depends upon stakeholders, meta-pahse, context,…
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective5
Distinguish structure from connectivity
Sales
Mrktng.
Inside
Cntrcts
Buyer
Outside
Procur. Manuf. Wrhse.
NY Div.
Buyer Line 01
Cell A
Cell B
Cell C
Shpng
Pkgng
Logistic
Rcving
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective6
Two structural aspects
requirements definition
concept definition
implementation description
design specification
domain operation
decommission definition
domain identification
orga
niza
tion
vie
w
reso
urce
vie
w
info
rmat
ion
view
func
tion
vie
w
Ordinant
Decomposition
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective7
Three aspects of scale
• Abstractness, scope, and refinement• Examples of dimensional independence:
– E-R diagrams are abstract but have rich refinement when fully populated.
– 19439 Genericity contains constructs for use along a generalization gradient with a range of phase abstractions.
– Zachman interrogative proto-types are abstract with concrete model contents.
– DoDAF views span operational abstractions with technical refinement.
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective8
Party
Employee
Scope Dimensions
EntityRelationship
Model
space
Data
space
meta-model
model /
meta-data
data/
instance
entityrelationship
works for
Concept
space
Department
IsA
subtype
World
space
real
world
things
JoeManufacturing Dept.
Did DName
35 Accounting
95 ManufacturingPid PName
47 Joe
Did Pid
95 47
abst
ract
ion
abstract
concrete
specialization
special general
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective9
Zachman Framework for Enterprise Architecture
e.g. DATA
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Builder
SCOPE(CONTEXTUAL)
MODEL(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEM
MODEL(LOGICAL)
TECHNOLOGY
MODEL(PHYSICAL)
DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = FieldReln = Address
e.g. Physical Data Model
Ent = Segment/Table/etc.
Reln = Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data Entity
Reln = Data Relationship
e.g. Semantic Model
Ent = Business Entity
Reln = Business Relationship
List of Things Important
to the Business
ENTITY = Class ofBusiness Thing
List of Processes the
Business Performs
Function = Class of
Business Process
e.g. "Application Architecture"
I/O = User ViewsProc .= Application Function
e.g. "System Design"
I/O = Screen/Device Formats
Proc.= Computer Function
e.g. "Program"
I/O = Control BlockProc.= Language Stmt
e.g. FUNCTION
e.g. Business Process Model
Proc. = Business Process
I/O = Business Resources
List of Locations in which the Business Operates
Node = Major BusinessLocation
e.g. Logistics Network
Node = Business Location
Link = Business Linkage
e.g. "Distributed System
Node = I/S Function(Processor, Storage, etc)Link = Line Characteristics
e.g. "System Architecture"
Node = Hardware/SystemSoftware
Link = Line Specifications
e.g. "Network Architecture"
Node = AddressesLink = Protocols
e.g. NETWORK
Architecture"
Planner
Owner
Builder
ENTERPRISEMODEL
(CONCEPTUAL)
Designer
SYSTEMMODEL
(LOGICAL)
TECHNOLOGYCONSTRAINED
MODEL(PHYSICAL)
DETAILEDREPRESEN-
TATIONS (OUT-OF
CONTEXT)
Sub-
Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural AssertionMeans =Action Assertion
End = Business Objective
Means = Business Strategy
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/Critical Success Factor
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing CycleTime = System Event
e.g. Control Structure
Cycle = Component Cycle
Time = Execute
e.g. Timing Definition
Cycle = Machine CycleTime = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations
People = Major Organizations
e.g. Work Flow Model
People = Organization Unit
Work = Work Product
e.g. Human Interface
People = RoleWork = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = IdentityWork = Job
e.g. ORGANIZATION
Planner
Owner
to the BusinessImportant to the Business
What How Where Who When Why
Copyright - John A. Zachman, Zachman International
SCOPE(CONTEXTUAL)
Architecture
e.g. STRATEGYENTERPRISE
e.g. Business Plan
TM
Zachman Institute for Framework Advancement - (810) 231-0531
(used with permission)
Roles
Interrogatives
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective10
Aspects of Formalization• Structure:
– both tree (decomposition) and grid (ordinant)– frames and sub-frames
• Connections:– between frame components– respects purposive order
• Constraints:– model and instance– beyond structure and connection
• Views:– generalizes “view” in existing frameworks– defined on structure– attempts to carry forward connections and constraints
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective11
Zachman meta-meta modelbranch frames: F IC , OC , SF ,
leaf frames: F IC , OC , S
whereIC D
OC D
OC r
IC r
SF : R x I x D F VF
r R( OC r x IC r’)
Types D {SET OF d :d D}
S : D n Types n
D restricted to row r
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective12
Aspects in Zachman model
• Structure:– ordinant: OC, IC
– tree: SF
• Connections:–
• Constraints:– predicates using defined
constructs• Views:
– sets satisfying predicates
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective13
Abbreviations• Bridge from formalism to human use,
providing– familiarity
– uniformity
– structure
• A single name N can abbreviate– a path: N r,I,d r, I, d
– R x I cell coordinates: N r, I, .
– a path template with multiple substitutions: N r, I, . r, I, .
• Use to shorten complicated paths
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective14
Transformations• Projection
– broadly applied math notion• Instantiation
– only applies to abstraction• Refinement
– decomposition may be recursive for complicated objects
• Specialization– adds attributes
• Derivation– domain-specific transforming concept
• Linking– graph-like edges
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective15
Projection
DoCRDIODc
Enterprise A (operational)
(new)
Enterprise B
(new)
Enterprise C
reference catalog R
DoCRDIODc
DoCRDIODc
From the set of architectural models, select a sub-set that is useful to a set of tasks during a life cycle phase.
DoCRDI
Dc
DoCRDI
Dc
DoA DoB
DoR DoA DoC
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective16
Instantiation
transmission
Has subpart
part
subpart
drive train
auto
engine
body
Has subpart
Has subpart
Has subpart
part
part part
subpart
subpart subpartPART PART
PART PART
PART
Instance of
transmission - Q
part
subpart
drive train - 88
Auto – 734M
engine – 88D5
body –c14
Contains
Has subpart
Has subpart
part
part part
subpart
subpart subpartPART PART
PART PART
PART
Contains
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective17
SpecializationLandscape
Sources
Principles
Formalization
Employeeworks
forParty
Department
specialization
special general
Party
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective18
Refinement
• Refine an architectural model by addition of significantly more detail to ensure its use for a task during the life cycle phase.
© Copyright 2010 All Rights Reserved R. Martin and E. Robertson Science of Enterprise Modeling: An Informatic Perspective19
DerivationLandscape
Sources
Principles
Formalization
Did Pid
95 47
Employeeworks
forParty
Department
Did DName
35 Accounting
95 Manufacturing
Pid PName
47 Joe
generalization
special general
Derive