410 likes | 450 Views
OPCAT eam. OPM-based Collaborative Systems Modeling Dizza Beimel March 2003. Agenda : . Introduction Background Problem Specification OPCATeam Architecture Implementation Summary and future work. Introduction Project goals and objectives:.
E N D
OPCATeam OPM-based Collaborative Systems Modeling Dizza Beimel March 2003
Agenda: • Introduction • Background • Problem Specification • OPCATeam Architecture • Implementation • Summary and future work
IntroductionProject goals and objectives: • Goal:Create specification and implementation for client-based collaborative environment, where teams of modelers collaborate in analysis, design, and implementation of systems using OPM. • Objectives: • Allow one or more modelers to work and develop systems by modeling them with OPM. • Create a collaborative environment that will support services like: concurrency, communication, and security. • Use OPCAT as the basis for OPCATeam.
Introductioncollaborative modeling solutions guidelines • Concurrency: - To work on a shared system at the same time, based on a single consistent model that describes it.- The model should be available to all the members enabling them to get the most up-to-date view. • Communication:-To enable multi-way communication among the team members regardless of their physical whereabouts. • Security: -protecting the model under construction from unauthorized external entities and unauthorized changes by modelers.
BackgroundWhat is Object-Process Methodology (OPM) ? • Object-Process Methodology (OPM) is an integrated approach to the study and development of systems in general and information systems in particular. • OPM unifies the system’s structure and behavior throughout the analysis, design and implementation of the system within one frame of reference using a single diagramming tool - the Object-Process Diagram (OPD) and a corresponding, English-like language - the Object-Process Language (OPL).
BackgroundWhat is Collaboration? • “To work jointly with others or together especially in an intellectual endeavor.” [Webster] • “When a product is designed through the collaborative efforts of many designers”[1] • “The collaboration concept is normally associated to groupware technology, which is designed to facilitate the work of groups.” [2] • IBM Lotus Notes [3] • NetMeeting [4] • SAP [5] • Documentum [6] • CVS [7] • TeamSCOPE [8]
backgroundOPCAT – single user version: • Serves one user at a time. • The user can create and update more than one model. • The data and metadata of each model is saved in an XML file. • The program reads the information from the XML file, while building its internal Data Structures. • The main Data Structure is Hash Table.
backgroundDefinitions of key concepts (1): • Element: A basic building block of any system expressed in OPM, which can be an entity or a link. • Entity: An element, which is not a link, which can be a thing or a state. • Thing: An object or a process. • Object: A thing that can exist for some time physically or logically. • Process: A thing that transforms an object by creating it or consuming it or changing its state (i.e., affecting it).
backgroundDefinitions of key concepts (2): • OPM model: The OPD set that completely specifies a system along with its OPL script, saved in a single XML file. • System Map: A directed hyper graph. Each OPD is a node and each edge is directed from a node to another node in which one of the things is refined. • Consistency: denoting coherence and lack of any specification contradictions across the various OPDs in the OPD set of an OPM model. • Integrity: denoting completeness and lack of dangling elements in the database of the OPM model.
Problem SpecificationOPM interconnectivity: • OPDs in the OPD set are interconnected. • OPDs can share common entities (objects, processes or states), each change in a common entity potentially influences other OPDs.
Modeler A Modeler B SD ? SD1 SD2 Problem SpecificationExample:
Problem Specificationproblem defining • Two conflicting requirements • Enabling independent, parallel work on a distributed OPM model • The model’s integrity must be kept intact. • Collaborative environment – How ? • Project restrictions • OPCAT code reuse • Reasonable project size
OPCATeam ArchitectureOverview (1): • Multi users, Client-Server architecture. • The server holds a single OPM model for each system in a central repository. • Users can simultaneously update the models, through the clients according to their access permissions. • OPCATeam has three access permission levels: workgroup, OPM model, and diagram.
OPCATeam ArchitectureOverview (2): • Three access permission levels: • workgroup, • OPM model, and • diagram. • The diagram permissions • reduce the number of conflicts between concurrent updates • prevent designers from affecting shared elements while allowing them to refine these elements. • Services for groupware environment: • Collaborative session • Version Control • Chat, and • “window presence”.
OPCATeam ArchitectureThe Model Manager: • Handles concurrent development of OPM models • Uses a central repository and a concurrent update mechanism. • Allows simultaneous user updates to a single OPM model, which is shared by one or more authorized users, while its perfection is maintained at all times. • Includes a version control function that logs updates and enables revision control.
OPCATeam ArchitectureAccess control Mechanism (1): • Workgroup access level • Admin • Create OPM model • View workgroup • OPM model access level • Admin • Commit model • View OPM mode • OPD access level • Admin • Edit OPD • Refine OPD • view OPD
OPCATeam ArchitectureAccess Control and conflicts handling: • The access control module helps reduce update conflicts. • The user can create, update or delete OPDs according to his permissions. • In a restricted configuration of OPCATeam, conflicts can be totally prevented, while in other configurations, conflicts may occur, and will be handled by the server.
OPCATeam Architectureconflict handling example (1): User1: request to delete
OPCATeam Architectureconflict handling example (2) : Object deleted ☺
OPCATeam Architectureconflict handling example (3): User2: request to refine
OPCATeam Architectureconflict handling example (4): Server rejects
OPCATeam ArchitectureThe OPCATeam Client: • Inherited from the OPCAT • Visual support in OPM. • logical support in OPM. • designed to meet the collaborative system requirements. • interface to various standard collaboration utilities like server communication, chat, and presence window, • access control mechanism.
Implementation • requirementsand problems • decisions and solution. • Overview • Server modules • Security and Access Control services • Collaboration services • Administration services • Version control services • Client screen shots
Implementationrequirementsand problems: • The OPCATeam client has full functionality as OPCAT. • All OPCAT future features will be included also in the OPCATeam client. • Changes in OPCAT should be as less as possible on its way to fit OPCATeam client. • OPCAT implements strong connections between OPDs. • Almost impossible to encapsulate an OPD as independent entity. • Project’s size restriction
Implementationdecisions andsolution: • Reusing OPCAT code. • The client basic building block is the model. • Creating the session concept. • Building future-supportive infrastructure. • Providing a Merge Utility to allow concurrency modeling. • Providing groupware features: presence window,chat and version control services. • In the future: • OPCAT Redesign to support OPD as the basic building block. • The model will be maintained by the server.
Server ModulesCollaborative Session: • Users can create Collaborative Session on a model according to their permissions. • Users can participate one session at a time. • Users can collaborate by sharing the same session:This is done by giving the needed session permission to the team members that the session creator is interested in. • Each session has a “Token Holder” which is the current model editor. The token can pass between the authorized session’s participants. • The session can be committed only by a team member that holds committing authorization. • The session data and metadata is saved on the server.
Server Modules:Administration • Local administration • Create/Update/Disable workgroups,models,sessions. • Handle the session: login, save, commit , etc. • Global administration • Handled through a web interface. • Disable/Enable/Update/Delete workgroups,user,models and sessions • Provide some kinds of statistic information.
Server modulesVersion Control: • Provide primitive version control functionality: • Get latest version • Check out file • Check in file • Get file status • File can be checked out by one or more users. • Once file had been checked in – it gets new version number. The date and the author will be saved. • The current implementation uses CVS.
Summary: • OPCATeam implementation follows the guidelines: • Concurrent work is achieved through the collaborative session and the merge utility, • Security is achieved through the access control mechanism, • The communication aspects are achieved through the collaborative session, chat room, and presence window.
Future work: • OPCAT Redesign to support OPD as the basic building block. • The maintenance of the OPM model will be done by the server. • Porting the code from JBoss to IBM WebSphere.