Metoda BORM

Vojtěch Merunka
Metoda BORM
BORM – Business and Object Relation Modeling
BORM information engineering process
Práce na BORMu začaly na počátku 90. let ve výzkumném projektu
VAPPIENS Britské rady (Know-How Fund of the British Council).
Metoda je od roku 1996 vyvíjena s podporou firmy Deloitte,
kde se také používá.
Podrobný popis BORMu lze nalézt v knize Carda, Merunka, Polák:
Umění systémového návrhu - objektově orientovaná tvorba
informačních systémů pomocí původní metody BORM, Grada 2003.
Pro BORM se doposud používal CASE nástroj Metaedit® finské firmy
Metacase Ltd nebo MS Visio. Craft.CASE se používá od roku 2005.
Publikace o BORMu
Umění systémového návrhu – Objektově orientovaná tvorba informačních systémů
pomocí původní metody BORM, Grada, Praha 2003
knihy
Management of the Object-Oriented Development Process, Akron Publishing, Virgin Island 2005
Accounting Information Systems, South-Western Publishing, Mason-Ohio 2004
Využití metod umělé inteligence ve vodním hospodářství,
nakladatelství Akademie věd ČR, Praha 2004
a dalších cca 5 vysokoškolských skript
The BORM methodology: a third-generation fully object-oriented methodology,
Knowledge-Based Systems 3(10) 2003, Elsevier Science Publishing, New York.
ččasopisy
asopisy
… a další 4 články v českých vědeckých časopisech
Process Modeling for Object Oriented Analysis using BORM Object Behavioral Analysis,
in Proceedings of Fourth International Conference on Requirements Engineering,
ΙΕΕΕ Computer Society, Chicago 2000.
… a dalších cca 20 příspěvků na konferencích doma i v zahraničí
konference
BORM - kontext celé metody
business
business map
map
konceptu
ální
konceptuální
model
model
modely
ů
modely subjekt
subjektů
analýza
ávrh
analýza aa nnávrh
business
business struktur
struktur
řřešení
ešení IS
IS
aa jejich
ání
jejich chov
chování
zadání
pro IS
Filosofie BORMu:
business
business
in
ženýrství
inženýrství
softwarový
softwarový
model
model
implementace
implementace
nnávrhu
ávrhu
návrh
řešení
tvorba informačního systému pomocí
postupné transformace modelů
softwarov
é in
ženýrství
softwarové
inženýrství
((tvorba
tvorba softwaru
ání kk řřešení)
ešení)
softwaru od
od zad
zadání
řešení
BORM and MDA Approach
business engineering area
business models
participant
software engineering area
conceptual models
(platform-independent)
software models
(platform-dependent)
object
object
object
collection
collection
collection
class
class
class
activity (job positions, perf. measures, devices)
method
method
communication
message
participant
(modeling card)
states & transitions
real
world
problem
function, scenario
(CSF, goals, targets,
issues)
message
object
oriented
solution
delegation
association
(relationship
tables)
relation
is-a hierarchy
BORM
interviews
BORM
process
diagrams
data flows
message parameters & return values
has-a
has-a
composing
dependency
dependency
dependency
type hierachy
polymorphism
polymorphism
inheritance
inheritance
UML-based models
Transformation Techniques
OBJECT
OBJECT
NORMALIZATION
NORMALIZATION
DESIGN
DESIGN PATTERNS
PATTERNS
1st,
1st, 2nd,
2nd, 3rd
3rd ONF
ONF
structural
,
structural patterns
patterns,
behavioral
behavioral patterns
patterns
BEHAVIORAL
BEHAVIORAL
CONSTRAINTS
CONSTRAINTS
dependencies
dependencies
between
between successors
successors
and
and predecessors
predecessors
OBJECT
OBJECT
EVOLUTION
EVOLUTION
from
from participants
participants to
to
object
,
object classes
classes,
collections
, …
collections,
…
HIERARCHY
HIERARCHY
EVOLUTION
EVOLUTION
from
-A through
from IS
IS-A
through
type
type hierarchy
hierarchy to
to
inheritance
inheritance
RELATIONSHIP
RELATIONSHIP
EVOLUTION
EVOLUTION
from
from associations
associations to
to
composition
,
composition,
aggregations
, …
aggregations,
…
Transformation Techniques - Behavioral Constraints
object relationship
(from A to B)
behavioral
constraints
B is
dynamicaly
accessible
from A
normal
aggregation
A needs B to perform
anything
Yes
Yes
Yes
A needs to pass data
to B
Yes
Yes
A needs to get data
from B
Yes
B shares the same
behaviour as A
inheritance
B is
an instance
of a class A
No
No
No
Yes
Yes
No
No
No
Yes
Yes
Yes
No
No
No
No
No
No
No
Yes
Yes
No
No
B uses the
methods of A
No
No
No
No
Yes
No
No
values of A
have influence to
values or behav. of B
No
No
No
No
No
Yes
No
behav. (methods) of A
have influence to
values or behav. of B
No
No
No
No
Yes
No
No
values or behav. of B
have influence to
values or behav. ofA
No
No
Yes
No
No
No
No
HAS-A hierarchy
IS-A hierarchy
poly-morphism
B is
dependent
on A
Transformation Techniques - Hierarchy Evolution
Motto: do not start system modeling with software-oriented concepts.
IS-A HIERARCHY
(business objects)
POLYMORPHISM
(conceptual objects)
Collection
INHERITANCE
(software objects)
Collection
Collection
IS-A
IS-A
type
type
Dictionary
type
Bag
Set
String
Set
IS-A
Array
Array
Array
IS-A
type
IS-A
ByteArray
IS-A
type
type
Set
Bag
ByteArray
String
Bag
Dictionary
Dictionary
ByteArray
String
Business Map
Business Map
„business analysis and design method based on combination of object-oriented
approach and process modeling“
business
business
improvement
improvement
organization
organization
consulting
consulting
as
-is
&t
o -b
em
od
els
business
business map
map
ub r
s
ted avio
n
e
h
um d be
c
d o s an
t
jec
modely
ů
modely subjekt
subjektů
business
business struktur
struktur
aa jejich
ání
jejich chov
chování
software
software
engineering
engineering
req
u
nts
e
m
ire
ca
ptu
r
ed
inf
o
rm
ati
o
n
knowledge
knowledge
management
management
BORM - Business Map - framework
3.
relationships
subjects
2.
structure
components
hierarchies of
participants
participant
roles
behavior
1.
concept
functions
hierarchies
of scenarios
content of
scenarios
explanation:
4.
processes
diagrams
5.
verification
modeling
cards
simulation
& testing
phase
phase
thread
thread
task
Funkce, Scénáře, Participanti a Modelové karty
Users request new functionality
Derived from: Admin and Maintenance
Initiation:
User requests new functionality.
Action:
IT Support evaluates the requests and accumulates relevant information for future development.
Result:
Developer periodically receives requests for upgrades (accumulated, not one-by-one).
Developer
IT Support
Developer
CVDB User IT
Support
New version release
×
×
System error
×
×
User
Users request for change
×
×
Users request new
functionality
×
×
Procesní diagram
Ka
ždý objekt,
Každý
objekt,
který
který vv procesu
procesu
participuje,
á
participuje, m
má
svoje
ase
svoje vv ččase
prom
ěnlivé chov
ání
proměnlivé
chování
aa komunikuje
komunikuje ss
druhými
druhými objekty.
objekty.
Výsledný
Výsledný proces
proces je
je
ddán
án sledem
álostí
sledem ud
událostí
vyvol
ávaných
vyvolávaných
komunikacemi
komunikacemi aa
datovými
datovými toky
toky mezi
mezi
objekty.
objekty.
role objektů
tvoří proces
Transition
from Business Engineering
to Software Engineering
Conceptual Model Creation
Define software system boundary, select objects within the system
from all business objects modeled.
Document behavior of business objects outside the system boundary.
OBJECT EVOLUTION:
Decide for implementation of object types as classes or as collections.
HIERARCHY EVOLUTION:
Define object types and assemble type hierarchy.
RELATIONSHIP EVOLUTION:
Transform object associations to more concrete relations like object
composing, object dependency, polymorphism or object delegation.
Conceptual Diagrams
Object
Object A
A
BORM uses UML notation,
but has following differences:
Extra symbol for method.
Object
Object B
B
message
parameter
method A
message
method B
message
return
Extra symbol for message among methods.
collection
collection name
name
collection
collection type
type
Extra symbol for collection of objects.
NAME
attributes
Extra symbol for class object.
operations
Extra symbols for relations known from pure object languages such as
delegation, dependence, polymorphism independent in inheritance, etc.
In each modeling phase, only limited set of concepts is used.
For better expression of some modeling details, it is allowed to put together
data, behavioral and history related concepts in one diagram.
http://www.craftcase.com
Projekt Craft.CASE
je původní český modelovací a analytický CASE nástroj
podporující metodu BORM®, která je založena na kombinaci objektově
orientovaného přístupu a procesního modelování.
Nástroj vzniká ve firmě e-Fractal s.r.o.
Zadání vychází ze dvou potřeb:
1) Jednoduše ovladatelný a na prostředky počítače nenáročný.
2) Modelovací nástroj přesně šitý na míru metodě BORM, který
je částečně konfigurovatelný, dokáže procesy simulovat
a generuje výstupní dokumentaci.
Program je vyvíjen v prostředí VisualWorks/Smalltalk a je určen pro
použití ve Windows 2000 a XP.
http://www.craftcase.com
Shrnutí - projektování pomocí Craft.CASE
spole
čná datab
áze
společná
databáze
konceptu
ální model
konceptuální
model
business
business diagramy
diagramy
simul
átor
simulátor
y
zb
va
modelov
ání zad
ání pro
modelování
zadání
pro IS
IS
aa jeho
ředí
jeho prost
prostředí
transformace
pomocn
é hierarchie
pomocné
hierarchie
konceptu
ální diagramy
konceptuální
diagramy
gener
átor kkódu
ódu
generátor
va
zb
y
business
business model
model
analýza
ávrh IS
analýza aa nnávrh
IS
Business Map - Simulační záznam
D
íky simulac
ím lze
ě analyzovat
ů nebo
Díky
simulacím
lze podrobn
podrobně
analyzovat role
role jednotlivých
jednotlivých objekt
objektů
nebo skupin
skupin
objekt
ů vv modelovan
ém procesu.
objektů
modelovaném
procesu.
Business Map - Procesní diagram - Simulace
Ka
ždý objekt,
Každý
objekt,
který
který vv procesu
procesu
participuje,
á
participuje, m
má
svoje
ase
svoje vv ččase
prom
ěnlivé chov
ání
proměnlivé
chování
aa komunikuje
komunikuje ss
druhými
druhými objekty.
objekty.
Výsledný
Výsledný proces
proces je
je
ddán
án sledem
álostí
sledem ud
událostí
vyvol
ávaných
vyvolávaných
komunikacemi
komunikacemi aa
datovými
datovými toky
toky mezi
mezi
objekty.
objekty.
Business Map - Dokumentace
Prvky
Prvky všech
všech modelů
modelů jsou
jsou ukládány
ukládány do
do databáze,
databáze, se
se kterou
kterou lze
lze přímo
přímo
pracovat.
pracovat. Ve
Ve většině
většině případů
případů se
se prvky
prvky musí
musí do
do databáze
databáze předem
předem
vložit
vložit aa teprve
teprve potom
potom lze
lze ss nimi
nimi pracovat
pracovat vv diagramech.
diagramech.
Výstupní
Výstupní dokumentace
dokumentace je
je tvořena
tvořena hypertexty
hypertexty
ve
ve formátu
formátu HTML
HTML aa také
také PDF
PDF aa obsahuje:
obsahuje:
1.
1.
2.
2.
3.
3.
4.
4.
seznamy
seznamy prvků
prvků zz databáze
databáze
diagramy
diagramy
simulační
simulační záznamy
záznamy
modelové
modelové karty
karty
(=
(= tabulky
tabulky ss křížovými
křížovými referencemi)
referencemi)
MCDrive
Scénáře
Modelové karty
APPENDIX - A
Car Fleet I.S.
Participant Relationships
Process Diagram
Move to Conceptual Diagram
Conceptual Diagram
Software Diagram
- Client Side
Software Diagram
- Server Side
SW Components
SW
Implementation
relational data model
(Oracle converted via ODBC into
MS Acess)
object structure - client data model (visual modeling in VisualWorks/Smalltalk)
Car Fleet - VisualWorks/Smalltalk implementation
program
launcher
borrowed car
archive
R.P.Knott, V. Merunka, J. Polak
list of cars and
garages
database
of car users
workflow of car request from car user perspective
create
new request
request after
chief’s
evaluation
cancel
request
requests waiting
at car assign
workflow of car request from car user perspective - continued
request after car
assign
request cancel
car borrow
borrowed cars
car borrow must be
completed by physical
car return to garage. this
is why here is no button
car assign
workflow of car request
from chief perspective
request to have
assigned some car
requests to be
evaluated
car is returned
car state
(reserved, in service, ...)
request cancel
APPENDIX - B
BORM and ICT Management
BORM in the ICT Lifecycle
market conditions,
vision&mission statements
1.
1. business
business needs
needs &
&
business
business strategy
strategy
business requirements
legacy situation
(e.g. system architecture,
architecture,
bussiness processes,
processes,
applications&data)
applications&data)
(ideally all aspects of business incl.
incl. measures;
measures; usually in
description of future business processes)
processes)
2.
2. ICT
ICT strategy
strategy
-- ICT
ICT assessment
assessment
-- ICT
ICT strategic
strategic plan
plan
-- ICT
ICT implementation/tactical
implementation/tactical plan
plan
feedback
changes in legacy situation
(2(2-5 years need to update the
whole ICT strategy)
strategy)
required target ICT architecture,
architecture,
ICT organization
existing ICT systems,
user requirements
(e.g. toto-be processes including
material flows & data flows),
flows),
ICTArchitecture
3.
3. project
project initiation
initiation
-- ICT
ICT project
project goals
goals &
& objectives
objectives
-- gap
gap analysis
analysis to-be
to-be vs.
vs. as-is(processes/ICT)
as-is(processes/ICT)
-- business
business case
case (cost&benefit
(cost&benefit analysis)
analysis)
-- decision
decision on
on package
package or
or in-house
in-house devel.
devel.
project charter
(project sponsor,
sponsor, manager,
team, schedule,
schedule, budget, ...)
4.
4. in-house
in-house development
development
-- analysis
analysis &
& design
design &
& implementation
implementation
-- tests
tests
-- roll-out
roll-out
5.
5. using
using packages
packages
-- configuration
configuration
-- test
test
-- roll-out
roll-out
new or updated ICT
systems,
systems,
new or updated user
behavior
6.
6. maintenance
maintenance &
& support
support
-- user
user help
help desk
desk
-- configuration
configuration management
management
-- risk
risk management
management &
& security
security
feedback
(maintainance changes,
changes,
requests for new
features)
features)
BORM Software Development Process – inspired by
Ambler’s Approach
project
project initiation
initiation
INITIATE
INITIATE
•• well
well define
define user
user
requirements
requirements
in-house
in-house development
development
using
using packages
packages
maintenance
maintenance &
&
support
support
CONSTRUCT
CONSTRUCT
•• well
well end
end efficient
efficient
performed
analysis
performed analysis
DELIVER
DELIVER
•• start
start system
system use
use
seamless
and
efectively
seamless and efectively
MAINTAIN
MAINTAIN &
& SUPORT
SUPORT
•• to
to have
have satisfied
satisfied users
users
•• repair
repair defects
defects
•• select
select
optimal
optimal solution
solution
•• prepare
prepare all
all required
required
for
for project
project start
start success
success
.. .. ..
•• best
best system
system
assembling
assembling and
and
testing
testing
•• to
to have
have good
good
documentation
documentation
.. .. ..
development
development platform
platform
•• well
well prepare
prepare users
users
of
of the
the system
system
.. .. ..
•• to
to have
have good
good
knowledge
knowledge base
base for
for
possible
possible new
new version
version
start
start
.. .. ..
operation
operation platform
platform
Each phase has associate its key performance issues, corresponding roles, activities etc.
BORM Software Development Process – detail
project
project initiation
initiation
INITIATE
INITIATE
in-house
in-house development
development
using
using packages
packages
maintenance
maintenance &
&
support
support
CONSTRUCT
CONSTRUCT
JUSTIFY
JUSTIFY
DEFINE
DEFINE
REQUIREREQUIRE
REQUIREMENTS
MENTS
DEFINE
DEFINE
MGMT
MGMT
DOCUMENTS
DOCUMENTS
DEFINE
DEFINE
INFRAINFRA
INFRASTRUCTURE
STRUCTURE
zahajovac
zahajovacíí tým
tým
DELIVER
DELIVER
MAINTAIN
MAINTAIN &
& SUPPORT
SUPPORT
MODEL
MODEL
TESTS
TESTS
IN
IN
THE
SMALL
THE SMALL
TESTS
TESTS
IN
IN
THE
LARGE
THE LARGE
RELEASE
RELEASE
SUPPORT
SUPPORT
GENERALIZE
GENERALIZE
PROGRAM
PROGRAM
REWORK
REWORK
ASSESS
ASSESS
IDENTIFY
IDENTIFY
DEFECTS
DEFECTS
pracovn
pracovníí tým
tým
podpora
é kancel
áře
podpora týmem
týmem projektov
projektové
kanceláře
spolupr
áce zzástupců
ástupců budouc
ích uuživatelů
živatelů
spolupráce
budoucích
provozn
provozníí tým
tým
podpora
podpora týmem
týmem
„„help
help desk
“
desk“
spolupr
áce vvšech
šech budouc
ích uuživatelů
živatelů
spolupráce
budoucích
PODP
ŮRNÉ PROCESY
PODPŮRNÉ
PROCESY
zaji
štění kvality,
zajištění
kvality, people
people management,
management, risc
risc management,
management, reuse
reuse management,
management,
pr
ávní zabezpe
čení, bezpe
čnost, řřízení
ízení infrastruktury,
právní
zabezpečení,
bezpečnost,
infrastruktury, ...
...
BORM Software Development Process – Support Processes
QUALITY
QUALITY
ASSURANCE
ASSURANCE
FOLLOW
FOLLOW
ISO
ISO
STANDARDS
STANDARDS
REUSE
REUSE
MANAGEMENT
MANAGEMENT
COLLECT
COLLECT
REUSABLE
REUSABLE
ITEMS
ITEMS
RISK
RISK MANAGEMENT
MANAGEMENT
TRAINING
TRAINING &
& EDUCATION
EDUCATION
IDENTIFY
IDENTIFY
A
A RISK
RISK
ASSESS
ASSESS
THE
THE RISK
RISK
DEVELOP
DEVELOP
MITIGATION
MITIGATION
STRATEGIES
STRATEGIES
DEVELOP
DEVELOP
A
A RISK
RISK
MANAGEMENT
MANAGEMENT
PLAN
PLAN
MITIGATE
MITIGATE
THE
THE RISK
RISK
REPORT
REPORT
RISK
RISK
METRICS
METRICS
MANAGEMENT
MANAGEMENT
DEVELOP
DEVELOP
METRICS
METRICS
PLAN
PLAN
PERFORM
PERFORM
AND
AND
DISCUSS
DISCUSS
PERFORM
PERFORM
INTRO
INTRO
TRAININGS
TRAININGS
DELIVERABLES
DELIVERABLES
MANAGEMENT
MANAGEMENT
MANAGE
MANAGE
SOFTWARE
SOFTWARE
CONFI
CONFIGURATION
GURATION
PERFORM
PERFORM
DETAILED
DETAILED
TRAININGS
TRAININGS
DEVELOP
DEVELOP
A
A TRAINING
TRAINING
PLAN
PLAN
INFRA
INFRA-STRUCTURE
STRUCTURE
MANAGEMENT
MANAGEMENT
APPLY
APPLY
CMM,
CMM, …
…
TECHNIQUES
TECHNIQUES
Nasazení rolí v jednotlivých fázích je odlišné
…
model
program
generaliz
e
test in
the small
…
…
…
development
engineer
modeler
project
manager
subject matter
expert / user
technical
writer
…
INITIATE
INITIATE
CONSTRUCT
CONSTRUCT
DELIVER
DELIVER
MAINTAIN
MAINTAIN &
& SUPPORT
SUPPORT
Struktura ASDM
This is determining what needs to be built. Initial requirements are a foundation from
which modeling can begin.
allocated
maintenance
changes
DEFINE AND VALIDATE INITIAL REQUIREMENTS
from maintain & support phase
INITIATE PHASE
The main goal is to lay the foundation
for a successful project. This is hard
due to pressures by senior management
and developers to start “real work” as
soon as possible.
define
defineand
and
validate
validate
REQUIREREQUIREMENTS
MENTS
JUSTIFY
JUSTIFY
define
define
initial
initial
management
management
DOCUMENTS
DOCUMENTS
define
define
INFRAINFRAST
RUCTURE
STRUCTURE
management documents
initial req uirement
project infrastructure
project fund ing
project charter
vision
commit ment
reasib ility study
existing applications
mainten ance changes
potential roles during this phase:
project manager
standards specialist
analyst
tools specialist
subject matter expert
project sponsor
quality assurance
engineer
estimator / planner
JAD / meeting facilitator
process specialist
technical writer
infrastructure engineer
DEFINE
DEFINE
SYSTEM
SYSTEM
FUNCTIONS
FUNCTIONS
DEFINE
DEFINE
SYSTEM
SYSTEM
SCENARIOS
SCENARIOS
DRAW
DRAW
PROCES
PROCES
MAPS
MAPS
HOLD
HOLD
SESSIONS
SESSIONS
CREATE
CREATE
MODELING
MODELING
CARDS
CARDS
PRIORITIZE
PRIORITIZE
REQUIREREQUIREMENTS
MENTS
INTERVIEW
INTERVIEW
USERS
USERS
SIMULATE
SIMULATE
SCENARIOS
SCENARIOS
WALK
WALK
THROUGH
THROUGH
PROT
PROTOTYPES
OTYPES
INITIATE
entranc e c onditions checklis t
senior management support exists to initiate a new project
maintenance changes pertaining to previous version (if any) are identified
infrastructure is available
INITIATE
to be pe rformed c hec klist
the initial requirements have been defined and validated
the initial management documents have been defined
the project has been technically, economically and operationally justified
required project infrastructure has been defined
potential reusable artifacts have been identified
project team has been identified and trained where appropriate
requirement
documentation
(forms, tables, diagrams, ...)
project scop e
CONSTRUCT/model - ukázka nastavení procesu v T-Mobile
PM User / CIF
PM - IT
Business Analyst /
Vendor
Expert User
appoint business
model team
wait for
modeling finish
PM Vendor
receive
acceptance
receive
business
model and
participate in
workshop
receive
conceptual
model
accept
vendor
product
IT Project Office
provide reuse
info
gather metrics
develop business
model and provide
reuse info
wait for
business model
receive business
model and reuse
information
participate in
business
model
workshop
after business
model
workshop
model not
approved
request
for
business
model
revision
wait for
conceptual
model
receive
conceptual
model and reuse
info
has conceptual
models
conduct conceptual
model workshop
receive reuse
info
after
concept.
model
workshop
model
approved
finished
business model
consultations
participate in
business model
workshop
present
business
model
conduct business
model workshop
after
business
model
workshop
model not
approved
request
conceptual
model
revision
consult business
model
finished
business model
consultations
business
model
has business
models
model
approved
appoint
conceptual
modelling
team
consult
business
modelling
finished
business model
after business
model is
finished
after business
model
workshop
develop conc.
model and
provide reuse
info
finished
conceptual
model
present
conceptual
model
conceptual
model
start
modelling
Environment
Specialist &
Programmer & IT
Architect
consult
conceptual
model
finished
conceptual
model
consultations
participate in
conceptual
model
workshop
consult
conceptual
model
finished
conceptual
model
consultations
participate in
conceptual
model
workshop
Technical
Document Writer
gather
underlying
material and
update
models