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
