Vojtěch Merunka Metoda BORM
BORM Business and Object Relation Modeling B O R M i n f o r m a t i o n e n g i n e e r i n g p r o c e s s 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 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 map konceptuální softwarový y subjektů business struktur a jejich chování zadání pro IS analýza a návrh n řešení ení IS návrh řešení implementace návrhu řešení Filosofie BORMu: business inženýrství tvorba informačního systému pomocí postupné transformace ů softwarové inženýrství (tvorba softwaru od zadání k řešení) ení)
BORM and MDA Approach business engineering area software engineering area business s conceptual s (platform-independent) software s (platform-dependent) participant participant (ing card) object object object collection collection collection class class class states & transitions real world problem function, scenario (CSF, goals, targets, issues) activity (job positions, perf. measures, devices) communication message method message delegation method object oriented solution association (relationship tables) data flows has-a message parameters & return values has-a composing relation dependency dependency dependency is-a hierarchy type hierachy polymorphism polymorphism inheritance inheritance BORM interviews BORM process diagrams UML-based s
Transformation Techniques OBJECT NORMALIZATION 1st, 2nd, 3rd ONF DESIGN PATTERNS structural patterns, behavioral patterns BEHAVIORAL CONSTRAINTS dependencies between successors and predecessors OBJECT EVOLUTION from participants to object classes, collections, HIERARCHY EVOLUTION from IS-A through type hierarchy to inheritance RELATIONSHIP EVOLUTION from associations to composition, aggregations,
Transformation Techniques - Behavioral Constraints object relationship (from A to B) behavioral constraints B is dynamicaly accessible from A HAS-A hierarchy normal aggregation IS-A hierarchy poly- -morphism inheritance B is an instance of a class A B is dependent on A A needs B to perform anything Yes Yes Yes Yes A needs to pass data to B Yes Yes Yes Yes A needs to get data from B Yes Yes Yes B shares the same behaviour as A Yes Yes B uses the methods of A Yes values of A have influence to values or behav. of B Yes behav. (methods) of A have influence to values or behav. of B Yes values or behav. of B have influence to values or behav. ofa Yes
Transformation Techniques - Hierarchy Evolution Motto: do not start system ing with software-oriented concepts. IS-A A HIERARCHY (business objects) POLYMORPHISM (conceptual objects) INHERITANCE (software objects) Collection Collection Collection IS-A Dictionary IS-A type type type Bag Set IS-A Set Array String Array ByteArray Array IS-A IS-A IS-A Set type type type Bag Dictionary ByteArray String Bag Dictionary ByteArray String
Business Map
Business Map business analysis and design method based on combination of object-oriented approach and process ing business improvement organization consulting as-is & to-be s business map documented subjects and behavior y subjektů business struktur a jejich chování software engineering requirements captured information knowledge management
BORM - Business Map - framework 1. concept 2. structure 3. relationships 4. processes 5. verification behavior subjects components functions hierarchies of participants hierarchies of scenarios participant roles content of scenarios diagrams ing cards simulation & testing explanation: phase thread task
Funkce, Scénáře, Participanti a Modelové karty Users request new functionality Initiation: User requests new functionality. Derived from: Admin and Maintenance 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 User Developer CVDB IT Support New version release System error User Users request for change Users request new functionality
Procesní diagram Každý objekt, který v procesu participuje, mám svoje v čase proměnlivé chování a komunikuje s druhými objekty. role objektů tvoří proces Výsledný proces je dán n sledem událostí vyvolávaných vaných komunikacemi a datovými toky mezi objekty.
Transition from Business Engineering to Software Engineering
Conceptual Model Creation Define software system boundary, select objects within the system from all business objects ed. 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.
BORM uses UML notation, but has following differences: Extra symbol for method. Conceptual Diagrams method A Object A message message parameter Object B method B Extra symbol for message among methods. Extra symbol for collection of objects. Extra symbol for class object. collection name collection type message return NAME attributes operations Extra symbols for relations known from pure object languages such as delegation, dependence, polymorphism independent in inheritance, etc. In each ing phase, only limited set of concepts is used. For better expression of some ing details, it is allowed to put together data, behavioral and history related concepts in one diagram.
http://www.craftcase craftcase.comcom
Projekt Craft.CASE je původní český ovací a analytický CASE nástroj podporující metodu BORM, která je založena na kombinaci objektově orientovaného přístupu a procesního ová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 craftcase.comcom
Shrnutí - projektování pomocí Craft.CASE společná databáze business konceptuální business diagramy transformace konceptuální diagramy simulátor vazby pomocné hierarchie vazby generátor kódu k ování zadání pro IS a jeho prostředí analýza a návrh n IS
Business Map - Simulační záznam Díky simulacím m lze podrobně analyzovat role jednotlivých objektů nebo skupin objektů v ovaném m procesu.
Business Map - Procesní diagram - Simulace Každý objekt, který v procesu participuje, mám svoje v čase proměnlivé chování a komunikuje s druhými objekty. Výsledný proces je dán n sledem událostí vyvolávaných vaných komunikacemi a datovými toky mezi objekty.
Business Map - Dokumentace Prvky všech ů jsou ukládány do databáze, se kterou lze přímo pracovat. Ve většině případů se prvky musí do databáze předem vložit a teprve potom lze s nimi pracovat v diagramech. Výstupní dokumentace je tvořena hypertexty ve formátu HTML a také PDF a obsahuje: 1. seznamy prvků z databáze 2. diagramy 3. simulační záznamy 4. ové karty (= tabulky s křížovými referencemi)
MCDrive
Scénáře
Modelové karty
Car Fleet I.S. APPENDIX - A
Participant Relationships
Process Diagram
Move to Conceptual Diagram
Conceptual Diagram
Software Diagram - Client Side
Software Diagram - Server Side
SW Components
SW Implementation relational data (Oracle converted via ODBC into MS Acess) object structure - client data (visual ing in VisualWorks/Smalltalk)
Car Fleet - VisualWorks/Smalltalk implementation R.P.Knott, V. Merunka, J. Polak program borrowed car launcher archive 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 borrowed cars request cancel car borrow car borrow must be completed by physical car return to garage. this is why here is no button
workflow of car request from chief perspective car assign 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. business needs & business strategy ICTArchitecture legacy situation (e.g. system architecture, bussiness processes, applications&data) existing ICT systems, user requirements (e.g. to-be processes including material flows & data flows), 2. ICT strategy - ICT assessment - ICT strategic plan - ICT implementation/tactical plan 3. project initiation business requirements - ICT project goals & objectives - gap analysis to-be vs. as-is(processes/ict) - business case (cost&benefit analysis) - decision on package or in-house devel. project charter (project sponsor,, manager, team, schedule,, budget,...) (ideally all aspects of business incl. measures; usually in description of future business processes) required target ICT architecture, ICT organization feedback changes in legacy situation (2-5 years need to update the whole ICT strategy) feedback (maintainance changes, requests for new features) 4. in-house development - analysis & design & implementation - tests - roll-out new or updated ICT systems, new or updated user behavior 5. using packages - configuration - test - roll-out 6. maintenance & support - user help desk - configuration management - risk management & security
BORM Software Development Process inspired by Ambler s Approach project initiation in-house development using packages maintenance & support INITIATE CONSTRUCT DELIVER MAINTAIN & SUPORT well define user requirements select optimal solution prepare all required for project start success... well end efficient performed analysis best system assembling and testing to have good documentation... start system use seamless and efectively well prepare users of the system... to have satisfied users repair defects to have good knowledge base for possible new version start... development platform operation platform Each phase has associate its key performance issues, corresponding roles, activities etc.
BORM Software Development Process detail project initiation in-house development using packages maintenance & support INITIATE CONSTRUCT DELIVER MAINTAIN & SUPPORT JUSTIFY DEFINE REQUIRE- MENTS MODEL TESTS IN THE SMALL TESTS IN THE LARGE RELEASE SUPPORT DEFINE MGMT DOCUMENTS DEFINE INFRA- STRUCTURE GENERALIZE PROGRAM REWORK ASSESS IDENTIFY DEFECTS zahajovací tým pracovní tým provozní tým podpora týmem projektové kanceláře podpora týmem help desk spolupráce zástupců budoucích ch uživatelů spolupráce všech v budoucích ch uživatelů PODPŮRNÉ PROCESY zajištění kvality, people management, risc management, reuse management, právní zabezpečení, ení,, bezpečnost, řízení infrastruktury,...
BORM Software Development Process Support Processes QUALITY ASSURANCE IDENTIFY A RISK RISK MANAGEMENT ASSESS THE RISK DEVELOP MITIGATION STRATEGIES TRAINING & EDUCATION PERFORM INTRO TRAININGS PERFORM DETAILED TRAININGS FOLLOW ISO STANDARDS DEVELOP A RISK MANAGEMENT PLAN MITIGATE THE RISK REPORT RISK DEVELOP A TRAINING PLAN REUSE MANAGEMENT METRICS MANAGEMENT DELIVERABLES MANAGEMENT INFRA- STRUCTURE MANAGEMENT COLLECT REUSABLE ITEMS DEVELOP METRICS PLAN PERFORM AND DISCUSS MANAGE SOFTWARE CONFI- GURATION APPLY CMM, TECHNIQUES
Nasazení rolí v jednotlivých fázích je odlišné program generaliz e test in the small development engineer er project manager subject matter expert / user technical writer INITIATE CONSTRUCT DELIVER MAINTAIN & SUPPORT
Struktura ASDM This is determining what needs to be built. Initial requirements are a foundation from which ing can begin. 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. potential roles during this phase: project manager allocated maintenance changes JUSTIFY define initial management DOCUMENTS standards specialist PRIORITIZE REQUIRE- MENTS define and validate REQUIRE- MENTS define INFRA- STRUCTURE from maintain & support phase management documents initial requirement project infrastructure project funding project charter vision commitment reasibility study existing applications maintenance changes DEFINE AND VALIDATE INITIAL REQUIREMENTS DEFINE SYSTEM FUNCTIONS HOLD SESSIONS INTERVIEW USERS DEFINE SYSTEM SCENARIOS CREATE MODELING CARDS SIMULATE SCENARIOS DRAW PROCES MAPS WALK THROUGH PROTOTYPES requirement documentation (forms, tables, diagrams,...) project scope analyst subject matter expert quality assurance engineer estimator / planner process specialist tools specialist project sponsor JAD / meeting facilitator technical writer infrastructure engineer INITIATE entrance conditions checklist 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 performed checklist 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
CONSTRUCT/ - ukázka nastavení procesu v T-Mobile PM User / CIF start ling PM - IT appoint business team wait for business Business Analyst / Vendor develop business and provide reuse info Expert User consult business ling Environment Specialist & Programmer & IT Architect consult business PM Vendor receive acceptance wait for ing finish receive business and participate in workshop receive conceptual accept vendor product IT Project Office provide reuse info gather metrics receive reuse info receive business and reuse information has business s conduct business workshop after business workshop not approved approved appoint conceptual ling team wait for conceptual request for business revision receive conceptual and reuse info has conceptual s conduct conceptual workshop after concept. workshop approved request conceptual revision business not approved finished business present business after business workshop develop conc. and provide reuse info finished conceptual present conceptual conceptual finished business consultations participate in business workshop after business workshop consult conceptual finished conceptual consultations participate in conceptual workshop finished business consultations participate in business workshop after business is finished consult conceptual finished conceptual consultations participate in conceptual workshop Technical Document Writer gather underlying material and update s