Skip to main content
European Commission logo print header

Open Platform and metHodologies for devELopment tools IntegrAtion in a distributed environment

Deliverables

The requirements module supports distributed specification of requirements. Its main functions are: - Adding requirement; - Browsing requirements; - Modifying requirement (with versioning); - Managing folders’ structure; - Changing requirement’s status; - Multiple projects management; - Multiple users management; - Reports generation; - Requirements searching. The module has been developed for the purpose of Ophelia project and is a part of Orpheus solution. However, any other requirements tools implementing the same Ophelia interface could be used instead. The requirements module is implemented as a client-server system. The server has been implemented in Java. The client application is written in PHP scripting language supported by majority of web platforms. The application uses XML and XSLT services extensively to provide effective requirements processing using RMM server XML services. DRES communicates RMM server using XMLRPC interface. The functionality of the module is further extended by other modules of Ophelia. For example, traceability module allows to trace relations of requirements with other artefacts and propagates notifications.
The Orpheus modelling module was developed using ArgoUML an Open Source Java application that supports UML 1.3, XMI 1.0, Object Constraint Language (OCL), partial code generation (Java) and many innovative cognitive support features including design critics. The Modelling module is intended to allow users to retrieve and submit UML models from/to the OPHELIA/Orpheus environment. In return, this allows distributed development teams to share data. The client in the Orpheus solution is the open-source ArgoUML tool, which is suitably enhanced via a plug-in so that it can connect to the Orpheus infrastructure. Within Orpheus, there is a modelling server that handles artefact storage and versioning and mediates on user/system access and authorisation. The server can accommodate offline working and also provides a locking mechanism to prevent �illegal� artefact check-outs and commits.
The Metrics module is intended to collect and present metrics information from the OPHELIA/Orpheus environment. It does this by taking advantage of the traceability and notification mechanisms. Specifically, it listens to other modules and detects changes. Once a change has been detected, it retrieves the relevant data artefact (eg a UML model) from the relevant module and interrogates the artefact to determine what exactly has changed (eg the number of classes has increased). By storing this metric information the module builds up a change history, and can graphically deliver this information to the user via a bespoke metrics client tool built for the Orpheus solution. Users are typically project managers who want a complete and up-to-date picture of the metrics they are interested in. As such, the metrics client provides a configurable interface to view measures relating to requirements, bugs, modelling and general project management. The difference over alternative approaches is that this information is automatically sourced and is updated as soon as a change occurs.
The Portal is the 'Users Entry Point' to the functionalities of OPHELIA. The Portal offers the several workspaces from where the users can access the functionalities of the OPHELIA system. The Portal is implemented as a J2EE servlet application, based on TOMCAT and Jetspeed (Turbine) framework. The Portal offers several frontends to the functionalities of the several OPHELIA-Modules; these frontends are called 'Portlets'. The access to the OPHELIA-Modules is authenticated against the OPHELIA kernel. The connection to the Modules is realized in CORBA technology, where the Portlets can be seen as the CORBA clients. The framework on which the Portal is based on allows the users to personalize and customize the look & feel of the Portal. These frontends are available on the Portal: Personal Agenda Frontend: This is the frontend for the Project Management Module. As well the Team Members as the Project Manager can use this portlet, to assign tasks, to report task- and project progress, and to see the schedule, including "pending changes". Traceability & Notification Frontend: The Notification Frontend supports all known features of the Notification Module to customize the subscriptions and see and manage the Notifications (messages). Also some of the backend-features as the Notification Filters and the email-settings can be set fro here. Modelling Module Frontend: The authenticated user can select a project and retrieve the corresponding UML diagrams (Use Cases, Class Diagrams, ... ) directly in the Internet Browser without the need of having the ArgoUML client installed. The Modelling Module Front-end Portlet makes use of an SVG (Structured Vector Graphic) functionality. Bug Tracking Module Frontend: All registered users can browse and edit the list all bugs, found for a selected project. According to the requirements of the 'Users' of the OPHELIA-project, a collaboration framework has been added to the Portal. Based on the same architecture (TOMCAT, Jetspeed) it is integrated with OPHELIA (security) and allows to Teamwork functions, like Creating Groups for each Project or further interests, User-managed and shared resources like Articles, URLs, The user can arrange appointments and manage their Schedule, and there is a News area, Content Syndication, Chat, Discussion boards, Mailinglists available. OPHELIA-project: http://www.ophelidev.org The Portal: info@gutura.de, http://www.gutura.de/ophelia
Orpheus is an integrator, which works as a sort of reference implementation for the Ophelia technology. To understand its relationship with OPHELIA one can compare it to the web: while OPHELIA is a compilation of many different technologies (html, http), Orpheus is the implementation of a specific web browser. However, Orpheus has a much higher potential. It consists of: - A generic implementation of the kernel tools: The implementation of each interface. Such implementations are required in any Ophelia enabled platform. Some administrative tools allow to look at what happens and to configure each single module. - A set of tools addressing all the steps in the development process. - Integrators and inter-tool applications: These applications benefits from the homogeneous representation of the development environment provided by the Ophelia Technology. The most important samples are presently the Traceability and Knowledge Management module. They could be reused in any Ophelia enabled development platform. - The portal: It provides a customizable personal workspace based on the user and project identification. Additional external tools may also provide user interfaces to some or all of the information available from the Ophelia environment. Orpheus was built to meet the requirements of some large European software houses. It contains some of the “best of breed” development tools in the open source market, that have proven to be valid alternatives to the applications. The tool interchangeability feature of the Ophelia technology makes the replacement of an existing tool with an in home grown one, a straightforward process. It allows, in addition, to have mixed functionalities for a tool (for instance, repository functionalities can be provided by a set of tools, instead of just one). Orpheus is highly modular, being composed by several blocks that can be easily reused elsewhere. Therefore, an existing development platform does not need to re-implement every interface required by Ophelia, it could, for instance, get from Orpheus just the kernel module implementation or some integration applications.
The Knowledge Management in Orpheus is run by means of a set of applications, both server and client, capable to modify/manage documents and to search for information contained in a document or in any other place. It goes beyond the concept of document, using, instead, the more general concept of object in the development environment. This allows identifying the required information even when it is not formalized in an official paper, but it is contained in any class included in a UML model, or in the attachment of a defective description (even if in a format like MS Office), or in a mailing list message. The software development is mostly based on the know-how of the people involved. As a consequence the management of such knowledge is crucial in the development environment of a company. Knowledge Client is the main user interface, capable to access the functionalities of two different modules: knowledge (to search) and repository (to archive). From the user perspective, their functionalities are strictly interrelated. The application is very simple; it doesn’t require professional developers, but only people with some experience on “office automation”. With a group of simple forms, any user is able to browse or to search information in any OPHELIA Environment. Another advantage is the reduced administration: the system is able to update itself whenever an object in the environment is changed. Behind the scene, the knowledge is indexed and administrated by a server. The knowledge server is composed by an engine, which is responsible of the indexing of all the information. It uses extensively the abstraction services from Orpheus for discovering new objects and getting updates. The engine uses two different types of indices, one for full text search, while the other for metadata in XML format. It is customized to work on development objects, like source code and technical documents, but two classes of add-in allow to extend the functionalities of the knowledge module, to include new types of objects: extractors (which allow extracting data from object in a form that can be indexed) and formatters (which will prepare the output in the way that the user required). The engine is also able to act as a meta-search engine. It is able to use the existent document management systems and help systems, providing a uniform access to any information available in a company, using the tool virtualisation concept of Ophelia.
The Ophelia technology is a set of technologies and methodologies composed by: - A set of CORBA interfaces, which define the behavior of the tools in a development environment - 4-layer architecture model. - Kernel delivers basic services for the administration of projects and users, and controls communication between modules. - Tool modules layer provides a uniform representation of a development environment. It defines a set of well defined interfaces into specific discrete tools, using tool virtualisation to permit easy tool interchangeability, e.g. the modelling tool is currently realized by ArgoUML but using the same interface ArgoUML can be replaced by Rational Rose. - Integration layer explicitly provides the mechanisms to support tools inter-operability through the use of integrators independent of the tools realization. An existing tool can be easily integrated inside an Ophelia enabled platform at the cost of writing an adaptor. The adaptor acts similarly to the “device driver” for the hardware of the PC. The tools interfaces are designed in a way to make them simply implemented, while Ophelia takes care of several integration tasks (event desynchronising, firewall traversal, etc.), mainly through the Abstract Tool Services. This integration gives the tools the advantage to use the services provided by the applications located at the integration layer. Significant samples are the Traceability module and the knowledge module. The first one provides explicit relationship tracking between the modules, and the objects they produce, while the Knowledge module manages all the know-how in the development environment.
Project Management Module forms an abstract layer over other project management software and exposes their functionality to the Ophelia platform. PMM extends the wrapped tool with implementation of Ophelia core interfaces, so that other applications can utilize project management artefacts. From user point of view PMM provides services for defining tasks and resources, managing schedules, tracking project progress. The PMM has been implemented in the three-tier architecture. The server is a Java application that provides a storage for schedules, tasks, resources and other project management-related information. The server manages user agendas as well, providing accurate feedback about task’s status and advancements, thus enabling schedule tracking. It exposes a CORBA interface compatible with Ophelia Project Management Module Interface Specification. The interface allows exporting and import data using XML format to provide open data interchange. The server uses Personal Agenda web application for tracking user’s tasks and updating progress and status information. XML Repository is used as a storage facility for the Project Management Server. Microsoft Project, a most commonly used project management tool, has been used as a client tool. Standard edition provides only desktop functionality, lacking centralized data repository and multi user access. As a part of Orpheus instance a plug-in has been developed to extend application’s functionality and enable communication with Ophelia Project Management Server. Microsoft Project gained new functionality: centralized repository for storing and accessing the schedules, schedule versioning, asynchronous schedule updates during application execution (including task status and progress information from user’s web agenda). The Personal Agenda is another client tool that allows access to the Project Management Module (PMM). It provides access to the information and functionalities that are relevant for the developers, system engineers, analysts, project manager, and others - depending on their role in the project. Other clients that provide access to the information and functionalities of the PMM are e.g. the Java-Gantt-Browser and the Traceability Browser (OPHELIA Object Browser).
The Traceability module of Ophelia plays two key roles: it helps in change management and it prevents people from getting lost in the complexity of the project. Traditional change management methods attempt to formalize all activities concerning introduction of changes to the project. Each change must be requested, numbered, accepted, finally implemented and tested to prove it reached its goals. All those activities may be facilitated by specialized document flow tools, yet they still require a human to process the information in each phase. Traceability module in Ophelia defines a completely new, conceptual level of relations existing in the project. Relations are an abstraction of existing links present in software artifact. This network can be specified progressively (and manually) as the project develops, or with support of automated tools, being part of Ophelia architecture. Change management support in Traceability consists of automatic notifications about changes in any part of the project one is interested in. Moreover, one may request information about changes of elements, which are dependent on some other element. The feature of change notification is unique because it encompasses the entire project, not only source code or requirements. Thanks to Ophelia interfaces, one may define relationships and trace changes on any element of the project. The network of relations existing in the project is an excellent source of knowledge. Developers can immediately check which other requirement a given class is realisation of, where the documentation can be found, how deep is the hierarchy of elements depending on this class etc. Project managers easier assess change impact, because they visually observe how many elements of the project a given change would affect. Going from element to element along the network of relations gives project member an opportunity to get a broader vision of what project components are and how they are structured, without time-consuming analysis of design documents.

Searching for OpenAIRE data...

There was an error trying to search data from OpenAIRE

No results available