Figure 1 Middleware.
[ Summary | Objectives & Results | Work Packages | Deliverables | Partners | EC Projects | Re-Engineering Links ]
Since the development of large and qualitative software systems should be carried out using a development method, different models have been proposed to describe the development process; the most common being the Waterfall model with iterative variants, and the Spiral model.
Traditional development methods, or function/data methods, enforce separation between functions, or system behaviour, and data, which are treated as completely separate. Such an approach often leads to problems, especially during maintenance, because functions must share data structures, and maintainers must think in terms of data structures and their relationships; hence, the resulting function/data structure is sensitive to change.
Object-oriented (OO) development methods differ from function/data (F/D) methods by their means of expression. While F/D methods commence by considering the system's behaviour and/or data separately, OO methods combine them and regard them as an integrated entity; they do not separate functions and data, but view them as an integrated whole. Once system requirements specifications exist in some form, from an OO point of view, the different system development phases are:
Object-oriented analysis is the heart of an OO development approach, and aims to understand the system being developed and builds a logical model of the system. This model is based on objects, found naturally in the problem domain. The objects hold data and have behaviour in terms of which the entire system behaviour can be expressed. Since objects in the problem domain will be stable, the overall structure of the system will normally be quite stable. Changes will occur but, since changes often come from the domain, it is hoped that these changes should be local and affect as few objects as possible.
The design and implementation of the analysis model is straightforward. OO aims to keep the logical structure of the analysis model in the final system, in order to guarantee traceability. For example, an object identified during analysis should be found in the code so that the system easily maintained. From the testing point of view, there are no big differences with other kinds of systems, since while inheritance often leads to less code, it does not lead to less testing, at least if exhaustive testing (on all descendant classes) is required.
There are several OO development methods around. Some are given generous attention in textbooks, while others have only been described in articles, or have been used as in-house development methods. The number of in-house methods is expected to increase, owing to the interest in OO techniques. A quick survey of major techniques, without any comparison, follows:
Within this manyfolded scenario, Booch and Rumbaugh started working together in 1994, under the auspices of Rational to unify OOD and OMT. During this collaboration, the first working product of the Unified Method for Object Oriented Development was released. Jacobson joined Rational to work with Booch and Rumbaugh to unify the OOD, OMT, and OOSE methods. In September 1996, this led to the documentation set, The Unified Modeling Language for Object Oriented Development (UML), v0.9, whose aim is not to propose a unified method, but to propose a unified notation for expressing models of different kinds for different purposes. The plan is to present v1.0 of the UML in December 1996, and to submit it to a Request for Proposal issued by the Object Management Group (OMG) to provide basic common facilities for object analysis and design. If UML is accepted by the OMG as a standard, it will be used as the notation in the OOD, OMT, and OOSE methods, and it is expected that tools vendors will provide facilities for the UML.
In order to design large systems, a systematic approach should be adopted. Traditional approaches, namely function/data methods, often fail in providing adequate support for system maintenance. They are closely related to data structures, and it is often the case that systems developed using such methods become unstable, since a slight modification may generate major consequences. The Object-oriented paradigm structures the system according to the items which exist in the problem domain, which is more natural. These items are normally very stable and change rarely, and very little. The occurring changes normally affect only one or a few such items, which means that the changes made are usually localised.
From this perspective, OO development enforces understandability and maintainability of the system to be developed, which are key issues for evolving a system. Thus, if reverse engineering is used to rebuild a system which we are able to cope with, OO methods should be used to re-organize the abstracted knowledge of the system, in order to increase future understanding and to facilitate maintenance and domain-reuse.
There are many CASE products available on the market to fully or partially provide support for OO concepts and the paradigm. We do not intend to describe and compare them, cite a number of commercial products: Rose from Rational Software Corporation, which provides support to OOD (Booch) and OMT (Rumbaugh), and which will support also UML; Objectory from Rational too, which provides support for OOSE (Jacobson); HoodNICE from Intecs Sistemi s.p.a, which provides full support for HOOD; System Architect from Popkin Software & Systems Inc., which both support OOD, OMT, and OOSE.
Coad, P. and Yourdon, E., "Object Oriented Analysis", Prentice-Hall, 1990.
Booch, G., "Object Oriented Design with Applications, Second Edition", Benjamin/Cummings, 1994.
HOOD Technical Group, "HOOD Reference Manual, release 4.0", HOOD Users's Group, September 1995.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W., "Object-Oriented Modeling and Design", Prentice-Hall, 1991.
Jacobson, I., Christerson, M., Jonsson P., and Övergaard, G., "Object-Oriented Software Engineering: A Use Case Driven Approach", Addison-Wesley, 1992.
Booch, G. and Rumbaugh, J., "Unified method for object oriented development, version 0.8", Technical Report, Rational Software Corp., October 1995.
Booch, G., Jacobson, I. and Rumbaugh, J. "The Unified Modeling language for object-oriented development, version 0.91 addendum", Technical Report, September 1996.
Wieringa, R., "Advanced Object-Oriented Requirement Specification Methods", Tutorial, November 1996.
OMG WWW page http://www.omg.org
Popkins Software & Systems WWW page http://www.popkin.com
Rational WWW page http://rational.com
Intecs WWW page http://www.pisa.intecs.it
Competing globally, reducing the cost of doing business, and rapidly developing new services and products are the requirements of today's business market, including the software market. Enterprises try to address these new requirements by constantly reconsidering and restructuring the way they do business. This involves changing their information systems and applications to support these evolving business processes. Workflow technology which can support, control and improve structured work facilitates change by providing a methodology and supporting software for both process support and control. This allows for process improvement as well as ensuring the quality of execution of existing business processes.
The aim of the workflow paradigm is to increase efficiency by concentrating on the routine aspects of work activities. Workflows separate work activities into well-defined tasks, roles, rules, and procedures which regulate most of the work both in manufacturing and the office, and provide a formal description of the knowledge necessary to perform such activity. In this sense, they formalize the current skill in doing the business, and, even if this is affected by all the cognitive-science-already-known problems of eliciting and structuring the knowledge, they provide a good basis from which to start to think aloud about the process. From this perspective, the worflowed process (a market-centered description of an organization's activity, including the software development process, which is a part of the overall business process) can be deeply investigated and simulations can be studied, in order to enforce, improve, or even redesign the process itself. The field addressed by workflow technology comprises reengineering and automating business processes.
Workflows Management Systems (WFMSs) provide support to workflow technology, and, even if WFMS systems are usually produced as a single physical package, the following logical components can be distinguished:
A definition tool to create the process description (a definition language, an object relationship model, or in simple systems a set of routing commands to transfer documents or forms among users).
An engine tool, which interprets the process description, controls the instanciation of processing and sequencing of activities, adding work items to the user work lists and invoking tools as necessary.
A worklist handler, responsible for progressing work requiring user attention, which interacts with the engine via the worklist (i.e. a desktop).
A handler for tool invocation.
A mechanism to control the transfer of case data between users and applications, or to provide a means of shared access to such data.
The workflow models most WFMSs support are activity-based, and consist of elements similar to the following: workflow (a partial or total ordering of a set of tasks), task (a partial or total order of operations, descriptions for human actions, or other tasks), manipulated objects (documents, data records, images, phones, fax machines, printers, etc.), role (a place holder for a human skill or an information system service required to perform a particular task), agent (humans or information systems that fill roles, perform tasks, and interact during workflow execution). Nesting of tasks is usually supported, with the aim of providing different levels of abstraction.
WFMSs, which enhance group communication, information sharing, and work process automation in a structured way, consist, mainly, of two kinds of applications: form routing and shared database workflow. While form routing involves automatic routing of documents from one person to another in order to take an action, in shared database workflow users consult a tracking database to check the status of a document and ensure the effectiveness of the workflow in the work process.
From the technical point of view, workflow products are typically client-server software products in which the work is performed within defined timescales. Even if the technology for supporting the workflow paradigm is quite mature, workflows suffer from a lack of standards (a standards body called Workflow Management Coalition, formed in 1993, is currently working in this direction), and WFMSs suffer from a number of limitations, mainly including:
A lack of interoperability among WFMSs.
A lack of support for correctness and reliability.
Weak tool support for analysing, testing and debugging workflows.
The Workflow concept is closely related to reengineering and automating business and information processes within an organization, which are the keys for improving processes and evolution. Two possibilities for using Workflow technology in RENAISSANCE are:
There are many workflow software products available on the market. We do not intend to describe and compare them; the remainder of this section simply provides a summary of the features and capabilities currently supported by commercial WFMSs .
Workflow model. All WFMSs provide both activity-based, and communication-based workflow models for specifying workflows.
Specification language. All WFMSs of which we are aware provide graphical workflow specification languages. Many provide also rule-based or constrained workflow specification languages.
Testing, Analysis, and Monitoring tools. Commercial WFMSs provide testing tools to simulate a workflow by allowing input of sample data and triggering events.
System Architecture and interoperability. Most of WFMSs have open client-server architectures and complete application programming languages (API). All of them support exchange of information among users or systems via e-mail or a shared (usually WFMS vendor proprietary) database. Only limited interoperability among office applications is usually supported, and just a limited number of WFMSs provides such support.
Correctness and Reliability. Data consistency on objects accessed by a workflow execution must be granted. Concurrency control, recovery, and transaction coordination should be necessary, but commercial WFMSs currently provide limited capabilities to deal with these problems.
Among the numerous WFMSs on the market, we can cite the following: LotusNotes from Lotus Development Corporation, ProcessWeaver from CAP Gemini Innovation, OPEN/Workflow from Wang Laboratories, ProcessWise from ICL Ltd., and FORO from SEMA Group.
RENAISSANCE Consortium, "Technology Briefing Report on Process Support", 1996.
Abbott, K. and Sarin, S., "Experiences with Workflow Management: Issues for the Next Generation". Proceedings of CSCW 1994.
Bair, J., "Methods for Success with new workflow systems". Proc. Groupware 1992.
Hsu, M. and Howard, M., "Work-flow and Legacy Systems". Byte, 1994.
Medina-Mora, R., Winograd, T., Flores, R., and Flores, F., "The Action Workflow Approach to Workflow Management Technology", Proc. of CSCW 1992.
Ramage, M., "Engineering a smooth flow? A study of workflow software and its connections with business process reengineering", School of Cognitive & Computing Sciences, University of Sussex, 1994.
D. Georgakopoulos, M. Hornick, A. Sheth, "An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure", Distributed and Parallel Databases, 3, 119-153, 1995
Miller, J.A., Sheth, A.P., Kochut, K.J., and Wang, X., "CORBA-Based Run-Time Architectures for Workflow Management Systems".
The Workflow Management Coalition, "The Workflow Reference Model", Document Number SC001-1003, 1994.
Wakeman, L. and Jowett, J., "PCTE: The standard for open repositories", Prentice Hall, 1993.
Componentware is a relatively new technology which aims to support application development using off-the-shelf components. Many software developers believe that componentware is long overdue. Tom Buxton of Microsoft points out:
"If you look at engineering overall, the idea of creating parts is a core process. Whether it is cars, integrated circuit designs, etc., it has been dramatically advanced by a mechanism of creating, manufacturing, and distributing entire subsystems of components. Yet software is the most backward engineering discipline in that it is the only one not doing it up until now."
Reuse is of course, not a new idea - subprograms and more recently classes and objects, have often been considered units of reuse. One of the expectations of object-oriented technology was that it would realise substantial gains in reuse. The reality however, has proven disappointing. One factor which contributed to this failing is that object-oriented programming languages lack the means to package and distribute objects in binary form. Binary code generated from multiple C++ compilers for example, are rarely compatible.
Although not designed as an open standard for component software, VBX (Visual Basic eXtension) components proved to be very successful reusable components. VBX controls were introduced to add functionality to applications developed in Visual Basic. Third-party VBX components rapidly emerged. The success of VBX components is not only exhibited by the interest from third-party vendors, but by Windows-based 4GLs, such as SQLWindows, allowing their applications to integrate VBX components. Further, Windows-based C++ environments reverse-engineered Visual Basic, enabling C++ programmers to reuse VBX components. The success of VBX components is primarily due to the ability to package them in binary form.
True componentware should embody the following attributes:
The VBX model is thus a flawed component architecture. Moreover, none of the above criteria are fully satisfied by any one component architecture of today. There exists however, a number of open component architectures which are bound to particular frameworks, platforms and languages. Dominant component architectures include: OLE, CORBA and OpenDoc.
In addition to the clear benefit of using componentware to achieve RAD (Rapid Application Development), and thus to realise reduced development costs, other benefits of componentware include:
Componentware builds on the strengths of the Object model. Components thus encapsulate their state and communicate through some form of message passing. These properties make components well suited to distributed systems. There is of course some overlap between Componentware and Distributed Object technology. Section 3.10 focuses on distribution issues.
In addition to the remaining technical hurdles for Componentware, business considerations regarding licensing, packaging and deployment of components need to be addressed before a component market can thrive.
Componentware is a new technology which is currently the subject of much commercial interest. The componentware market is already competitive, with infrastructure support and components emerging. Componentware is thus an interesting technology for RENAISSANCE, with possibilities for incorporating components into both 3 and 4GL applications during evolution.
All RENAISSANCE applications are expected to evolve towards a Client/Server-based architecture. Componentware will be highly relevant to work package 3.1, Client/Server Migration. Components are natural units of composition for multi-tiered Client/Server systems. As the technology matures, and support for distribution emerges, Componentware will a serious candidate for distributed Client/Server applications.
In work package 3.2, Architectural Modeling, the construction of component meta-models will expose the structure and composition of components, and reveal how this technology may be integrated with other technologies, for example 4GLs and Internet technology.
Elements of legacy systems can be extracted and reused within a revised application where componentware is used as a new implementation technology. A risk with many evolution projects is losing business knowledge encapsulated in legacy system code. By wrapping legacy system code in components, a better engineered software architecture is the result, without loss of legacy system knowledge. Using components as wrappers also supports an incremental style of evolution, where changes to the internal workings of particular components can be made once the system has undergone architectural change.
Given the new possibilities which Componentware introduces for system evolution, the RENAISSANCE method will react to the capabilities of component technology. The method will recognise for example, that Componentware facilitates incremental evolution, wrapping legacy code, and integration possibilities with other technologies.
For Componentware to provide true off-the-shelf components from which applications can be composed very rapidly, an infrastructure is required which governs component naming and interaction. The infrastructure is essentially an open bus which components may be plugged into. Componentware infrastructures include Microsoft's OLE model, CI Labs' OpenDoc and the OMG's CORBA. CORBA has been designed explicitly as a distributed component standard, and is presented in Section 3.10, Distributed Object Technology.
OLE's roots are in compound document technology. OLE 1.0 allows a document from one application to be embedded or linked in/to a document from another application. For example, a Microsoft Excel document could be embedded in a Microsoft Word document. Selecting the spreadsheet document from Word would automatically invoke the Excel application. OLE 2.0 enhances this support for compound documents, in addition to providing for a more general component architecture.
OLE 2.0 provides 2 features of particular interest to a component infrastructure:
1. Automation. Programmatic access to components from a high level programming or scripting language. An OLE-compliant database application could for example send a set of values to an OLE-compliant spreadsheet and direct the spreadsheet application to process the values.
2. Controls (OCXes). Fine grained components which can be integrated with OLE-enabled applications. OCXes are similar in function to VBXes, but are based on an open component architecture. OCX communication is based on OLE 2.0 automation.
OLE 2.0 is not only a Componentware standard, but it is supported by Windows operating systems. Unlike other infrastructure standards, OLE 2.0 is thus a component model which can be used today. It has had the opportunity to gain support from other Windows software vendors (several 4GLs including Borland Delphi and Microsoft Visual Fox Pro). However, OLE 2.0 is not a distributed technology, and its complexity incurs a steep learning curve. Distributed OLE is expected to be released in the near future, but it will still be constrained to Windows operating systems.
OpenDoc is an alternative infrastructure which is technically superior to OLE 2.0. OpenDoc is CORBA compliant, and thus has been designed as a general Componentware infrastructure from the outset. As such, it is platform independent. OpenDoc also supports OLE 2.0. Despite its technical superiority over OLE 2.0, implementations of OpenDoc are scarce, and it suffers from a lack of support, which OLE has exploited given its relative maturity.
OLE 2.0 is well supported by applications from Windows-based vendors, and components, often developed and marketed by third-parties. Given OpenDoc's relative immaturity to OLE 2.0, it seems too premature to see OpenDoc components being marketed. According to our recent survey, available OLE 2.0 components can be loosely organised in the following (not exhaustive) categories:
User interface controls. User interface abstractions such as custom widgets (for example, buttons, data presentation, and slide bars).
Database applications and tools. Generic databases, for example a contacts database which enables a company to store information about other companies. Tools such report generators and ODBC middleware are also available as Componentware.
Utilities. Entities like email integration components and text editors with varying degrees of sophistication have emerged as components which may be plugged into applications.
Development tools. Pretty printers, debuggers and code analysers have been developed as components for visual development environments.
Communications. Components to support the development of distributed applications with protocols such as TCP/IP are available. Another communication component is one which enables a FAX machine to be integrated with an application.
Multimedia. Sound, graphical, and video components have been marketed which allow applications to be enhanced with multimedia capabilities.
Internet. Integration of WWW browsers with applications to facilitate greater accessibility of an organisations data are provided by Internet components.
In addition to conventional media used to market products, OLE components are available from component catalogues stored on CDs where each components may be unlocked with a password. WWW brokers also exist which manage selling components to customers on behalf of vendors. Such brokers are commission-based. Costs for OLE 2.0 components range from free (for shareware controls) to approximately $3000.
RENAISSANCE Consortium, "Technology Briefing Report on RAD", 1996.
RENAISSANCE Consortium, "Technology Briefing Report on Distributed Object Technology", 1996.
RENAISSANCE Consortium, "Overview of Terminology in the Componentware Domain", 1996.
Componentware WWW page http://www.componentware.com
Component Source WWW page http://www.componentsource.co.uk
OLE Broker WWW page http://www.olebroker.com
Visual Components WWW page http://www.visualcomp.com
Middleware is the common
name of the software found in the middle of a client/server
application. Some people even like to call middleware the slash
between client/server. Whenever a client sends a request to a
server or to an application to download data from a database,
some form of middleware is involved: mediating the client/server
link and smoothing out the potential incompatibilities between
communication protocols, database query languages, application
logic, and operating systems (See figure below).
Today's existing middleware can be divided into seven different categories depending on the services they provide:
Middleware has two important roles in today's software engineering community. It eases the work for the implementers of new systems by hiding complex protocols and differences between platforms. Further, middleware helps the migration of legacy systems to client/server architectures by providing gateways between new and old software components.
Various forms of middleware technologies will be needed by the Renaissance partners to help:
The middleware tools will be introduced during the implementation phase, but the needs and the existence of them should be regarded in earlier phases (planning, analysis, and design).
Middleware technologies will ease the step-by-step process of migrating from a centralised legacy system to a Client/Server system by offering tools to help an incremental evolution process. Using middleware to bind new modules to existing modules (i.e. by using a 3-tier client/server architecture), small parts of the system can be re-engineered and rewritten without affecting the rest of the system.
Middleware offers the possibility to develop/implement the client application(s) in a Client/Server environment independent from the server application(s). This way, one can avoid critical downtime of systems during the development of new client applications. Applying middleware helps in the development of loosely coupled applications.
Using middleware allows client and server applications to be sited on different hardware and software platforms. This means that old hardware and software can be reused and combined with new technologies.
As an example: Most of the Renaissance applications need to transform their existing legacy databases to newer relational databases. This can be done by using middleware providing data management services as gateways or bridges between legacy and relational databases.
There is a wide range of tool support for the seven categories of middleware services:
ODBC (Open DataBase Connectivity) is a middleware standard which allows an application to submit SQL statements to a database, indirectly through ODBC. The form of SQL used must conform to the ODBC standard. ODBC translates ODBC SQL statements to the flavour understood by a particular database.
Most existing data management middleware supports high level programming languages and desktop utilities to help the development process.
2. Middleware supporting communication services can be divided into two different groups: RPC and messaging systems.
RPCs provide facilities for synchronous procedure calls on remote systems as if they were local. The tools supporting RPCs includes an Interface Definition Language (IDL), a compiler, a Universal Unique Identifier (UUID) generator, and a RPC runtime library. RPC supports connectionless and connection-oriented transport protocols. The IDL and its compiler describes the RPC's interface. The compiled code (the object code) is in two main parts - one for the client side, and one for the server side. The RPC runtime library consists of a set of routines, linked with both the client and server sides of an application, which implements the communication between them.
Messaging middleware enables distributed applications to send and receive messages asynchronously using a set of APIs. The messaging middleware relieves the applications of message routing, queuing, and session establishment and termination. Good messaging middleware also is platform.
3. The distribution services can be divided into three categories: location services, security services, and time services. Tools supporting location services provide a directory and naming service. The directory service allows a client to access a remote file, a remote table, or a remote process without having to know where that object is physically located on the network. The tools supporting location services ease the connection to servers by hiding network details and providing naming services. Using the Internet and/or an intranet infers a security problem. Security middleware is aimed at protecting the internal systems. The security middleware is installed between the server, the application and remote users, and provides secure transactions independent of client and server applications.
4. Tools supporting object management services use Object Request Brokers (ORBs) to provide transparent communications between objects sited on different locations in a network. OMG's CORBA and Microsoft's OLE technology are examples of this technology - discussed in Sections 3.3 (Componentware) and 3.10 (Distributed Object Technology).
5. Tools supporting application co-operation services are providing support for a large number of concurrent users that access transactions programs and services (i.e. databases, security, workflow), local and distributed load balancing to optimise performance, and efficiently synchronising data updates to multiple databases during a single transaction using standard protocols. The advantage by using TP monitors are their ability to manage several thousands of users, concurrent database accesses, and large volumes of data.
We also have workflow service which allows the developer to control scripts to manage the execution of sequences of operations that relate to particular business processes. The workflow service makes distributed applications serve the business process which avoids modifying the application if the business process changes as is seen with managing document workflow. Workflow services using transaction monitor services, is called transaction workflow.
6. Tools supporting presentation services provide features for mapping GUIs and transparent printing. These services are often included in other tools. But there exists dedicated tools for mapping character based UIs into GUIs.
7. Tools supporting system management services should provide configuration management, change management, operations management, problem management, and performance management. These services, although not fully available, enable applications and system functions to be continuously monitored to ensure that a corporation's business requirements can realise an optimum quality of service from the distributed application environment.
As mentioned, all existing middleware does not fall into these seven categories of middleware. Most tools provide two or more kinds of services. For example, tools supporting data management services often also support security services, location services, and time services.
RENAISSANCE Consortium, "Technology Briefing Report on Middleware", 1996.
RENAISSANCE Consortium, "Technology Briefing Report on Distributed Object Technology", 1996.
Schreiber, R. of The Lewis Group, "A View of Middleware", Insights on the NII, http://www.niit.org/insight/white/mdlware.html, April 1996.
Rama Rao, B. of Integrated Solutions Inc., "Making the Most of Middleware", http://www.data.com/Tutorials/Middleware.html, September 1995.
Mullich, J. "The Riddle in the Middle", Open Computing Cover Story, August 1995.
Bernstein, P.A., "Middleware: A Model for Distributed System Services", Communications of the ACM, February 1996, Vol 39, No. 2, pages 86-98.
Brodie, M. L., and Stonebraker, M., "Migrating Legacy Systems", Morgan Kaufmann Publishers, Inc., San Francisco, California, 1995.
Ganti, N. and Brayman, W., "The Transition of Legacy Systems to a Distributed Architecture", John Wiley & Sons, Inc., 1995.
Otte, R., Patrick, P. and Roy, M. "Understanding CORBA", Prentice Hall PTR, 1996.
RAD (Rapid Application Development) is the union of tools, techniques and methods which enable organizations to increase productivity during software development and evolution. Increases in productivity yield a shorter time-to-market and reduced software costs.
Tool support for RAD is provided by the following technology areas:
RAD however, is more than a collection of tools. Effective use of RAD tools must be governed by a RAD process model. Such a process model (method) offers techniques to manage RAD projects. A RAD project must satisfy 3 conditions:
Typical techniques proposed by RAD process models include:
4GLs have evolved since the early 1980s from centralised character-based interpreted development environments to (distributed) client/server event-driven systems. 4GLs are a rapidly changing technology. 4GLs can be classified as suited to either small-to-medium scale application development, or enterprise-size application development. However, the 4GL market is competitive, and 4GLs which were once classified as small-to-medium are now offering the functionality which make them candidates to build large-scale applications. The majority of current 4GLs provide:
Large-scale 4GLs extend the above capabilities with:
RAD and 4GL technology are highly relevant to the RENAISSANCE project with respect to the selected applications, and more generally, to the RENAISSANCE method. We view RAD and 4GL technology as a key growth area, and so, to add value and longevity to the RENAISSANCE method, these technologies should form part of the method.
Engineering's' BIMER application and Telesoft's GSTM application operate in dynamic and competitive environments. For both applications, time-to-market is a crucial factor in determining their success, and ultimately, their survival. RAD and its supporting technology areas are thus of much interest to these and similar applications where the first organisation to market its product yields great commercial advantage.
All RENAISSANCE applications, except ISmed are currently implemented according to centralised architectures. There is much interest in transforming these applications to Client/Server systems, where 4GLs play a big role. 4GLs contribute to the Client/Server solution, ranging from providing GUI clients, to a distributed Client/Server architecture. 4GLs will thus be a core part of work package 3.1, Client/Server Migration.
Work package 3.2, Architectural Modeling will also devote much attention to 4GL technology. The structure of 4GLs is poorly understood; effort will be made to resolve this issue. A generic model of 4GL applications will prove useful in describing how 4GLs can be integrated with other technologies, for example, Componentware and Middleware. Modeling of Client/Server architectures (2-tier, 3-tier and n-tier) will take account of 4GL technology.
Given the value of RAD where a short time-to-market is critical, work package 3.3, Evolution Planning, will recognise RAD as part of project management. Where RAD support technologies are used, a process model should react to the advantages in terms of effort savings gained. Of equal importance, any evolution planning method should identify inappropriate use of RAD, and resist presenting it as a Silver Bullet.
4GLs raise further issues which must be tackled in work package 4, the RENAISSANCE method. For example, having built a generic model of 4GLs in WP3.2, configuration management problems, such as identifying configuration management units can be addressed. Sufficient information will be available to liase with tool vendors regarding tool support for 4GL applications.
A standard for a RAD process, known as DSDM (Dynamic Systems Development Method) has been formed by a UK consortium of mainly industrial partners. DSDM defines critical success factors for RAD projects, and introduces RAD techniques for use in the development process, for personnel management, for project management, and for quality assurance. Some of these techniques have been described above. The initial standard is currently being reviewed to include amongst other issues, evolution.
| Centura SQLWindows | Microsoft Visual Basic | Borland dBASE V |
| Compuware Uniface | Microsoft Access | Visual Age |
| Magic Software Enterprise Magic | Microsoft Visual Fox Pro | PowerSoft PowerBuilder |
| Seer Technologies Seer*HPS | Borland Delphi | |
4GL technology is very well supported by tools. A representative sample is shown in Table 1. The tools in the first column are documented in Section 4 of this document. Of the tools selected for RENAISSANCE, all are large-scale 4GLs with the exception of SQLWindows. SQLWindows has much in common with other similar Windows-based products. Uniface, Magic, and Seer*HPS all support technology independence and distributing applications according to Client/Server models.
Magic is noticeably different from the other tools in Table 2. Magic is described as a second generation 4GL. The fundamental difference between Magic and conventional 4GLs is that Magic fulfills the promise of zero lines of code, frequently made by 4GL vendors. Development of a Magic application is realised through filling-in forms rather than writing code in a very high level language. In this respect, Magic is similar to an application generator.
RENAISSANCE Consortium, "Technology Briefing Report on RAD", 1996.
DSDM Consortium Secretariat, The Coach House, Church Hill, Kingsnorth, Ashford, Kent, TN23 EGK, UK.
A legacy system is an entity, consisting of a combination of software, hardware and manual procedures created, at some time in the past, to ease or support some business process. Because hardware and software technologies are continually improving it becomes desirable, at some stage, to integrate some aspect of them into a legacy system. The process of changing a legacy system to include new technologies is known as system evolution. More specifically, system evolution can involve changes to the software, the hardware, the manual procedures or any combination of the three. Management issues concerned with system evolution will depend largely on the legacy system itself and the type of change to be performed.
This section of the report deals with system evolution issues and the managing of them and is structured as follows:
Identify evolution candidate
Assess evolution alternatives
Choose alternative
Plan project
Execute plan
Develop changes
Install new system
Run live
Legacy system evolution is generally stimulated by business process change. A candidate legacy system is identified through an investigation which determines and documents where the system fails to perform the function for which it was created and/or where it could be improved to perform the function more effectively. The investigation pulls together the opinions of management, technicians and, most importantly, end users. Whether or not the system is an evolution candidate depends on an objective summary of these results.
The criteria for assessing whether a legacy system is a candidate for evolution include such things as: compliance with legal requirements (e.g. health and safety), security considerations (e.g. hacking resilience), age of system, size of system and proportion actually in use, quality of hardware (metrics?), quality of software (metrics? may need reverse engineering or restructuring), quality of documentation, quality of underlying business processes.
Identifying an evolution candidate may involve a certain amount of software reengineering [1] and business process reengineering [2])
For any identified candidate system, there may be several evolution strategies that is, ways of improving it. The Renaissance Project Objectives refer to evolution strategies broadly as being 'reengineering', 'restructuring', 'refurbishing' or 'recycling'. In practice, a hybrid approach may be the most appropriate [3-5]. In view of this, more fine grained terms for these strategies must be defined in terms of changes to all or part of the hardware/software/manual procedures as follows
1. Upgrade parts of the hardware only (e.g. a faster disk storage device, client/server technology) - may force a software upgrade see 3 and 4.
2. Upgrade all hardware (e.g. a new machine) - definitely force software upgrade 3 and 4.
3. Upgrade parts of the software by:
a. Improving the selected software, on the same software platform, without changing the basic functionality (reengineer/refurbish).
b. Improving the selected software, on the same software platform, while at the same time improving/changing its functionality (redevelop/refurbish).
c. Transferring the selected software from one software platform to another without changing the basic functionality (reengineer/recycle).
d. Transferring the selected software from one software platform to another while at the same time improving/changing the functionality (redevelop/refurbish).
4. Upgrade the whole of the software by:
a. Redeveloping all from scratch on the same software platform (redevelop).
b. Redeveloping from scratch but salvaging some aspects of the legacy system for incorporation into the new system on the same software platform (redevelop/recycle).
c. Redeveloping from scratch on a different software platform (redevelop). Salvaging some aspects of the legacy system for incorporation into the new system on a different software platform (redevelop/recycle/refurbish).
5. Combinations of 1 and 2 and 3 and 4.
6. Must not forget manual procedures
Each alternative will bring with it a benefit which it may be possible to weight for use in a later cost benefit exercise. For example, if the hardware has broken and cannot be replaced, no matter how good the system is, it must be evolved.
Having identified an evolution candidate and determined a number of evolution strategies, the question 'to evolve or not to evolve' must be answered. Many factors will affect this decision but the overriding factor will be that of cost. A cost benefit analysis for each evolution strategy identified above will be performed in order to compare the costs of implementing it with the savings expected to be gained from using it [6].
Costing an evolution alternative will involve calculating costs for:
Planning the evolution project and
Executing the plan - Developing, Installing, Maintaining and running the evolved system for its predicted lifetime.
Costing consists of first estimating size and hence effort and resources and then evaluating these financially. There are many approaches to estimating and it is generally accepted that at least two methods should be used in order to validate the result. An automated tool, of which there are many [7, 8], should be used during the costing exercise. As well as assisting the cost benefit exercise for any one evolution strategy, this tool will allow for comparison of costs amongst the various strategies.
Various other factors, including the weightings associated with each strategy (Section 3.6.1.2), affect the cost benefit analysis. These factors can be represented in the cost benefit analysis as risk associated cost drivers. Risk management is perhaps the most significant factor which will determine project success [7, 9]. Risk associated cost drivers include items such as:
Contractual position - is the company tied to a given supplier:
Simple change of supplier.
Change from proprietary to open system.
Full or partial upgrade.
Availability of necessary information.
Purchase of hardware/software - availability and lead times.
Infrastructure: 'space' requirements for new hardware and software and for possibly two sets during evolution.
Commitment of affected personnel - acceptance of new working practices.
Training - both S/E and users: is the personnel base up to doing it.
Conversion of current electronic information and integration into new practices.
Testing considerations: straight reengineering involves using copies of 'live' data to prove pre/post upgrade functional equivalence. Retesting and reintegrating components creates the largest proportion of costs and is a major deterrent to reengineering as these costs must be offset by correspondingly high benefits from the new system.
The cost benefit analysis may result in a decision to perform pilot studies/benchmark exercises in order to determine the best of several evolution strategies.
Effective management requires thorough planning [6, 10]. The project plan should be consistent with the organisation's policies and goals. It should embody constraint identification, effort estimation, risk management, scheduling and monitoring. The costing exercise above involved identifying risks and estimating effort and resources for which an automated tool was used; estimating effort and resources involved a certain amount of hypothetical planning and scheduling so a by product of the costing exercise was an embryonic evolution plan stored on disk. The project plan will be an elaboration of this and becomes the baseline for the monitoring of actual costs and work progress.
To be workable, the plan must take into consideration the iterative nature of system development, all factors identified during the choice of alternative, include contingency measures to cover identified risks and be ratified by senior management. Planning considerations include such items as:
Choice, purchase and appropriateness of new H/W, S/W, Tools, Utilities, testing facilities.
Availability and cost of Consultancy and Training packages
Ability of organisation and relevant personnel to cope with complexity of strategy.
Administration - scheduling of meetings, information gathering, recording and organising
Overheads for any additional development tasks.
Infrastructure requirements.
Data conversion and integration with current live data.
Once the evolution plan is created and accepted by senior management it can be executed. Plan execution covers initial project set up, the development work, the installation of the new system and the ongoing support and maintenance over its life time. The last three items are handled in the following three sections.
The care and efficiency with which the project is initially set up will determine how smoothly the remaining evolution tasks will run. These initial stages involve creating the test environment in which the development work will be completed, the user test environment for user training and acceptance testing and the final production environment for the new system. It will encompass such things as purchase and installation of necessary hardware/software, supply of resources, consulting/staffing/technical training and tool support.
During execution, actual effort and resources are monitored and progress assessed by comparison of actual figures with those estimated and recorded in the project plan. Also, during execution, the plan should evolve to take into account refined information as it becomes available.
To reach the development stage Sneed [6] estimates at least six months of investigation and planning will be required for a system of any significant size. Development is performed by technicians using the test environment and encompasses any additional systems analysis/design, amending/creating software, unit, link and stress testing and creating/amending all necessary technical and user documentation.
With the advent of RADs and 4GLs end user interaction during this phase is highly likely.
Involves the migration of the new system from the test environment to the user test environment for user training and acceptance testing. During this exercise the system can be parallel run and the interfaces with non legacy systems verified.
On acceptance, the system and all associated documentation become fixed and enter a version management system.
Initially involves the migration of the new system from the user test environment to the production environment where live data from the new system will be integrated with data from non legacy systems.
Subsequently involves the ongoing support and maintenance with, hopefully, lower maintenance costs
Legacy system evolution involves first assessing a legacy system and then changing it in some way. Documentation of various kinds will be handled during each of these activities. Documentation management is all about locating, creating, filing and tracking documents and the information they contain. These documents can apply to the legacy system itself or to the evolved system and can exist in hardcopy forms or electronic forms.
Clearly, evolution management is a critical element of the RENAISSANCE project as it is a fundamental part of the method and is one of the planned deliverables.
Evolution management covers a wide range of activities such as costing and scheduling, code restructuring, reverse engineering, business process reengineering and version management. These are supported, in various degrees, by CASE tools. In his treatment of risk management, Jones [7] suggests that several risks could be reduced through the use of tools. The problem is thus not a lack of tools, but managers' reluctance first, to employ costing and scheduling techniques; and second, to exploit the wealth of tool support which exists. Jones reports on a 1993 study which showed that 50 estimating tools and 70 scheduling tools were available as commercial products. Perhaps further work in work package 5 (evaluation) could be directed towards an analysis of tool capabilities to determine their ease of use and usefulness.
Assuming the availability of useful CASE tools, conceptual support is necessary to give any value to the tools. Conceptual support includes historical data to guide selection of algorithmic tool parameter values, and methods to help with cost and risk estimation when using new technologies. Productivity figures for 4GL and componentware development are lacking, given the immaturity of these technologies relative to 3GL development. Verner [11] reports on his experience with effort and schedule estimation using 4GL technology, and proposes the use of function points and a refined COCOMO model. The business project planning system Microsoft Project is currently in use throughout the consortium.
Documentation management covers the management of both hardcopy and electronic documents. Automated tool support will apply only to the electronic aspect. Almost any tool designed for any purpose will support the creation of a document. Scheduling tools will support the creation of schedules supported by management charts, Spreadsheets will produce tables and graphs, 4GLS will produce documents ranging from database tables to screen maps and source listings, Wordprocessors and groupware products produce formatted text reports with facilities for tables and pictures. Tool support for documentation is, therefore, virtually limitless. The consortium uses Word wordprocessor for producing reports.
To define the Internet in more concrete terms, we will now consider all software which is used within a simple Internet/Web system, and describe them briefly.
An internet browser sits on a client machine and gives its user access to the Web. A browser can either be an independent software package that can sit on top of various operating systems, or it can be embedded into an operating system. Similarly, a browser can either be an all-purpose browser or it can be specialised in one internet protocol. Thus, until recently, Netscape's Navigator was usually considered a Web (HTML) browser while Eudora was generally considered an e-mail browser. From release 2.0 Netscape's Navigator provides support for all the popular Internet protocols. The most popular browser is Netscape's Navigator product, which supposedly has over an 85% share of the market. Microsoft is working very hard to establish its own browser, Internet Explorer. At the beginning of the year 1996, the OMG emitted the desire that Netscape would provide stubs for CORBA and support for OpenDoc in its Web browsers and servers, and we suspect Netscape will comply.
The Internet offers so much that an individual can quickly become overwhelmed. A number of vendors have developed indexes or search engines that make easy-to-find things on the internet or on an intranet. Some are incorporated in the browsers. This will be an interesting area and companies which provided search engines in the past have usually built a bridge with the internet.
A corporate Internet/Intranet site needs software to manage the flow of messages from users or employees to this site. This is the role of the server software. Lots of different vendors offer server software and both Netscape and Microsoft are rushing into this arena. Microsoft will clearly build server software into the NT operating system within a year or two. There will be allot of competition in this niche and predictably, within a few years, only a few large companies will remain. The RENAISSANCE project should avoid using server software which proposes features not normalised or supported by only a few server products.
A number of companies are offering specialised utilities to facilitate internet site management and communications, for example: companies focusing on facilitating credit card or money transfers via the internet; companies offering encryption services and tools that transmit voice over the internet; and others offering automatic translation services. There are a lots of companies involved in lots of different niches.
This includes software tools for developing web sites and for managing the sites once they are up and running. It includes simple tools for developing a few static Web pages, tools linking Web pages to new databases in order to make them more dynamic, and languages for embedding small applications (applets) into web sites. These products could be used for new RENAISSANCE applications, where they can be tested.
If you link items on a Web page to a database, you can use the database to update the web page. There are three main means to do that and so we will detail each now.
CGI, Server API
The HTTP server provides a method for running external programs from within an HTML document. This method is called the Common Gateway Interface (CGI). The server can pass information to the CGI program (if needed) and get back any results returned by the program. This method allows a user to enter information needed by the CGI program, then simply push a button to activate the program. The program processes the information, performs any other necessary functions, and returns results either in HTML format or in straight text. The HTTP server accepts the results and processes them as needed. The CGI method of program interaction lends itself particularly well to the task of getting information from a database. Database vendors provide many different methods of accessing their products. Such methods include a programming API, a command-line interface, or a menu-driven interface. Server's API offer the same kind of facilities, it allows you to add kind of pre and post processor when the server treats a demand. These kinds of pre and post processor are usually written in C language and are dynamically linked to the server. They provide faster access.
Proprietary Server
Database vendors were offering proprietary solutions with sometimes a specific web server. If this solution still exists, this is not a standard one and most of the main database vendors are now offering more open solution based on the two other solutions described here.
Java / JDBC
JavaSoft has developed a standard database access interface, the JDBC API. This API provides Java programmers with a uniform interface to a wide range of relational databases, and provides a common base on which higher level tools and interfaces can be built. Leading database, connectivity, and tools vendors have already endorsed the JDBC API and are developing products using JDBC. JDBC drivers are currently available from a number of these vendors, providing Java connectivity to a wide variety of DBMSes.
The JDBC API defines Java classes to represent database connections, SQL statements, result sets, database metadata, etc. It allows a Java programmer to issue SQL statements and process the results. JDBC is the primary API for database access in Java.
The press has focused a lot of attention on Java, a language that can facilitate downloading of applets on client machines that are equipped with Java interpreters. More visionary individuals have proposed that companies can maintain a single copy of a program like Microsoft Word and that each employee, when they want to use a text processor, will simply erase word from Ram by exiting the browser (it will provide many advantages: employees may have access to only the programs they need and they will always access the latest version because they download it from a central point which will manage updates).
In a similar way, a company could arrange for employees to access existing legacy applications via browsers. In effect, an employee would access the corporate accounting application by going to the "accounting Web site". They are mainly two means to develop such a connection and of course they are quite similar to those used to connect to databases.
CGI / API
The same principles as described above for database connection. Some tools use this approach to link CGI to legacy applications by directly offering language connections like COBOL, C and C++. However, you must have an API for your application which is available on the server platform. Some other tools provide gateways between usual Web servers (Unix and NT) and legacy systems (IBM mainly).
Middleware connection
Microsoft Explorer and Netscape Navigator already provide middleware connection through respectively Active X and Java + CORBA (IIOP). Tools exist that already use this approach or plan to use it to connect to legacy applications and databases, but most of the tools which are available now are using their own middleware components. However the tools which integrate the state of the art at the moment are Netscape One form Netscape and Normandy from Microsoft. Normamdy from Microsoft provides a proprietary solution whereas Netscape provides an open solution! This new class of applications, called network-centric applications, combines the advantages of central control and administration with the power and flexibility of distributed applications. In contrast to client-server applications that build static connections between a client and its server, network-centric applications accommodate collections of co-operating applications and network services. Applications are created by building new services (either client- or server-side) that transparently integrate and customise the services offered by intranets and the Internet. When requested by a user or program, the platform-independent client part of the application is downloaded from the application server and executes on the Netscape Navigator (or any other open-standards-compatible) client. The client then uses the open Internet protocols to interact with the server-based parts of the application as well as the standard services of the intranet and Internet.
The Web is attractive as an application platform because it eliminates the time and cost associated with application deployment. In the Web environment, deployment is instantaneous because the application resides on the server rather than the client. From the server, the application can be accessed from anywhere in the world. For system managers, this eliminates much of the headache involved in maintenance upgrades and in the administration involved in managing multiple platforms across multiple offices. For business managers, global access of server-side applications provide a compelling new channel for reaching new customers with products and services. The Web also introduces a natural three-tier architecture that provides a foundation for scalability.
| Client Browser Software | Medium |
| Internet Search Engines | Low |
| Server Software | Low |
| Web Sites Utilities | Low |
| Web Site Development Software | High |
| Linking Company Databases | High |
| CGI, Server API | High |
| Proprietary Server | Low |
| Java / JDBC | High |
| Linking Corporate Applications | High |
| CGI, Server API | High |
| Middleware connection | High |
A lot of tools and language libraries are available for database connection - the following URL identifies and discusses most of them:
http://cscsun1.larc.nasa.gov/~beowulf/db/all_products.html.
It identifies products to access databases, but some of these tools also provide legacy application connection.
For connection to legacy applications, tools like Amazon, NetDynamics, Active Software, Java development environment (including JOE), ActiveX tools and of course Netscape One and Normandy should be used. The more powerful solution for integrating ODBC database on NT servers seems to be Cold Fusion.
"Object Oriented Strategies `The monthly newsletter for manager & developers of object oriented systems'"
Netscape, "THE NETSCAPE ONE DEVELOPMENT ENVIRONMENT VISION AND PRODUCT ROADMAP", http://home.netscape.com/comprod/one/white_paper.html.
Microsoft, "The Microsoft Active X Control Pad".
System modelling is a technique to express, visualise, analyse and transform the architecture of a system. Here, a system may consist of software components, hardware components, or both; and the connections between these components. A system model is thus a skeletal model of the system.
System modelling is intended to assist in developing and maintaining large systems with emphasis on the construction phase. The idea is to encapsulate complex or changeable aspects of a design inside separate components with well-defined interfaces indicating how each component interacts with its environment. Complete systems are then developed by composing these components. System modelling can increase reliability and reduce development cost by making it easier to build systems, to reuse previously built components within new systems, to change systems to suit changing requirements such as functional enhancement and platform changes, and to understand systems. In this way, a system model can satisfy different requirements such as documenting the system, providing a notation for tools such as consistency checkers, and can also be used in the design stage of system development.
System modelling is used to ensure that a developing piece of software evolves in a consistent manner and that the task of integrating software components is simplified.
For system modelling, we need a conceptual framework and a system modelling language, textual and/or diagrammatic. Besides textual notations like tables or prose, diagrammatic notations like graphs are common today. Within these diagrams, there are symbols representing the parts of objects, and other symbols visualising the connections between these parts. The number of symbols for each purpose differs noticeably between notations.
During the past decades four main conceptual frameworks have evolved:
Design methods consist of a concept, a language, and a design process. The concept defines which parts of the program are to be represented by the components of the system model. The language is used to describe the system model. To carry out the design of the system according to the software lifecycle or a part of it, a step-by-step process is given to be followed by the designer.
Design methods use both textual and diagrammatic notations.
When modelling a system with a modular design method, program modules are used as the components from which the system is composed. Modules include related functions of a specific program language and may keep the data used by these functions. Further, a module offers an interface with the functions that may be used from this module.
An interrelationship between two modules is established by a function contained in one module calling a function contained in an other. Thus, this modelling method describes systems in terms of function calls and composition of modules containing functions.
Object-oriented design methods, on the other hand, do not focus on the functional aspect. An object component includes data and functions. These functions constitute an external interface, and represent the only possibility to manipulate and/or access the data within an object. Another type of components are classes, which serve as templates from which objects can be instantiated, i.e. derived. Most OO design methods allow an object to have several roles and a system can be looked upon in different views.
The connections between the objects of a system model are manifold, e.g. instantiation of an object from a class, composition, and use. Interacting objects often are not viewed as calling each other's functions, but requesting each other via messages to perform a desired action on their data. An object is responsible for hiding its representation from other objects. Thus, the object-oriented modelling method adds behaviour over a mere structural solution.
Creating program modules and connecting them to form large systems are different design efforts. Module interconnection languages (MILs) are means to support the connection effort of large systems.
A MIL is separate and distinct from an implementation language. Its purpose is to formally express the system designer's intent regarding system structure. In the absence of a MIL, this information is buried within the implementation language modules, linker commands and informal documentation; thus, the information is scattered, unreliable and doesn't enforce connectivity.
The main features of MILs are:
Both design methods and module interconnection languages force the system designer to use a relatively low level of abstraction. System decomposition is described in terms of modules, objects, or procedures, i.e. in terms of implementation-language items. With increasing size and complexity, the specification and design of the overall system structure become more important than the choice of algorithms and data structures. To meet these requirements, software architectures are being developed.
There exist some different definitions on what the term 'software architecture' should include besides (computational) components and their interrelationships. Some developers include the possibility to describe constraints on the relationships, others focus on different connections between components, yet others develop rationales which demonstrate that the components, connections, and constraints define a system that satisfies the given requirements.
The notations used to describe and visualise software architectures range from textual notations to informal diagrams and graphical notations provided by ADLs and their supporting tools.
Compared to the three conceptual frameworks discussed so far, design patterns are the most theoretical approach to model a system and its behaviour.
Design patterns were introduced by the architect Christopher Alexander for the design of buildings and cities at the end of the Seventies. Since the beginning of the Nineties, software engineering researchers have become more and more interested in design patterns. Most research effort has been put into finding object-oriented design patterns, but the use of design patterns is by no means restricted to object-oriented software development.
Patterns are applicable in fields where certain problems occur over and over again and describe the core of the solution to those problems. To reuse a pattern, knowledge about the decisions and trade-offs that led to the particular solution are important. Design patterns are, thus, described in a textual notation, either informal (i.e. prose) or formal (i.e. a particular formalism or implementation language), often accompanied by a graphical notation (i.e. sketches or diagrams).
Designing a database involves describing the structure of an information system, or in other words: specifying relevant objects and their connections. The relational model was an important step in providing a simple, easy to use data model for this purpose with its easy to understand table structure, the relation. In a relational database the information on objects is kept in relations. But the relational model had some problems describing object connections. These problems lead to the development of object-oriented (semantic) data models, like the Entity-Relationship (ER) model or one of its extension like, for instance, the Extended ER (EER) model. The ER model allows users to describe their database directly in terms of objects and object connections.
Conceptual, logical and physical design refers to the three main phases of database design. The conceptual schema produced by the conceptual modelling is a concise description of the data types, relationships, and constraints expressed using high-level data models. The logical schema produced by logical design is a database schema in the implementation data model of the DBMS. The physical design produces the internal storage structures and file organisations for the database. The transition between the three schemas are more or less automated by supporting data modelling tools.
In addition to providing support for the three modelling phases, the tools should support division of diagrams into sub-diagrams, ODBC, modelling and maintenance of stored procedures, version control, and report generation. In today's often large teams, support for multi-user environments may be desirable, that is, support for several source models, merging, team management, etc.
A growing number of database designers and modelling tools have gone from using ER modelling techniques to object role modelling (ORM) techniques. ORM uses English sentences to express how objects relate to one another, and what constraints and business rules apply to these relationships. InfoModeler by Asymetrix Corp. was the first tool that supported ORM. One of the main advantages with ORM is that it makes it easier to communicate with non-technical clients because it expresses design details using English sentences. ORM is a conceptual modelling method that views the application world in terms of objects that plays roles.
ORM reflects the trend in data modelling; the models is being distanced from the implementation. New methods and tools provides conceptual modelling methods that do not commit the designer to any particular implementation structure (ER commits the designer to a relational database structure).
For Renaissance partners system modelling is needed to help:
System modelling tools will be used through the whole life cycle of a project. Such tools can be used to analyse and design an application.
For many legacy systems there is often no actual or updated documentation of the system's architecture. To retrieve information about its structure, the legacy systems will have to be reverse engineered to be documented. This information will be used to build a model of the system's architecture. Whether it is possible to build this system model automatically or if this has to be done manually from the data of the reverse engineering process, depends on the tools available.
Such a model of a centralised system can be transformed, step by step, into one describing a more and more decentralised system exploiting a Client/Server architecture. Using a method with a diagrammatic notation will help the developer to better understand the system, i.e. which changes are more appropriate to transform the old system, and how changes of one component of the system may affect other components.
There may be several ways to visualise and transform an existing system. The developer will have to use his experience to decide on the most promising method here.
Database technology is crucial in the re-engineering/evolution process. Migrating from one database platform to another can be a hard and non-trivial task. Database modelling techniques and tools are developed to ease database design and re-design. Such tools and techniques can be used to reverse-engineer existing databases and/or to design and model the revised database. A conceptual database diagram is often also a very good documentation of the database. Many existing data modelling tools also provide modelling of user interfaces and stored procedures, in addition to relations between entities.
Data modelling tools combined with 4GLs can be used to rapidly produce prototypes and/or in connection with rapid application development (RAD).
Many decide to invest in a database modelling tool only after they discover that their architecture has become hopelessly unwieldy. The existing database modelling techniques and tools will ease the step by step process of migrating existing databases into new platforms and/or re-engineer them. Also, as mentioned, the existing database modelling techniques and tools can be used to reverse-engineer databases and provide a textual and graphical presentation of the existing database.
The available support differs significantly between the four conceptual frameworks of system modelling approaches explained in the Overview section.
Design methods are very well supported by literature and tools. For every major system modelling language there exists at least one book by the developers, describing the method and the process associated with it.
A design method on the verge of object-oriented design is MD++ (ProMod-PLUS), mainly MD with an object-oriented extension. Other methods focus on a particular implementation language, e.g. HOOD (Hierarchical Object-Oriented Design) is used to develop systems with the Ada implementation language. Today's widely used object-oriented methods supported by tools include the Object Modelling Technique (OMT) by Rumbaugh, the Object-Oriented Design and Analysis (OODA) by Booch, the Object-Oriented Design LanguagE (OODLE) by Shlaer, and Object-Oriented Role Analysis and Modelling (OOram) by Reenskaug. Unified Method Language (UML) by Booch, Rumbaugh and Jacobson is the most recent OO-design method. Tool support for UML is under development.
If a tool vendor claims to support a certain method, this does not mean that the tool supports the entire process or all the concepts of that method. Nonetheless, there are a lot of tools supporting a method entirely.
The tool support for Module Interconnection Languages is rather poor.
The development of tools to support Architecture Description Languages is in progress but there exists almost no industrial use besides in project of the U.S. Department of Defense.
As design patterns are not meant to be executed by computers, there will be no tools for this purpose. But a lot of effort is used to find object-oriented patterns. So patterns may be used in object-oriented design methods and tools in the future.
An ideal database modelling tool will let you focus on your efforts on database design. It should support reverse-engineering, enforce database integrity, and automatically generate database schemas.
Data modelling tools let you focus on the conceptual design by isolating it from aspects of the implementation that are specific to a particular physical back-end. One important demand to such modelling tools, is that their models are independent of underlying databases and hardware. This facilitates easy migration between different database implementations.
ER diagramming tools represent the database in the abstract by treating table as entities, columns as attributes, user types as domains, etc. Though the semantics differ among different design methodologies, the concepts are similar. The tools presents the diagrams graphically and using boxes as entities and lines between the boxes as relationships. The lines are decorated with special symbol(s) at the end of the line, visualising cardinality (one-to-one, one-to-many, many-to-many, etc.). Also relationships and entities can be described using words somehow attached to them. In addition the tools should support modelling and maintenance of stored procedures.
Most new data modelling tools support reverse-engineering of a database schema. There are mainly two ways of doing reverse-engineering of databases. One is by using a direct database connection (i.e. through ODBC) or we can to use a SQL Data Definition Language (DDL) script file.
After designing a conceptual model, the tool should be able to generate the code needed for the database schema. That includes tables, indexes, triggers, and stored procedures. They should also provide support for modifying existing databases.
Examples of database modelling tools are: EasyER (Evergreen), ERWin/ERX(Logic Works), S-Designor(PowerSoft), Info-Modeler(Asymetrix), Systemator(SysDeco), ER/1(Embarcadero), and ProMod Plus (debis).
RENAISSANCE Consortium, "Technology Briefing Report On System Modelling", 1996.
RENAISSANCE Consortium, Technology Briefing Report On Databases, August 1996.
Borison, E., "System Description Languages - An Analytic Survey", Technical report (draft), Insitute for Computer Systems, University of Trondheim, 1985.
Brodie, M.L., and Stonebraker, M., "Migrating Legacy Systems", Morgan Kaufmann Publishers, Inc., 1995.
Yourdon, E., and Constantine, L. L., "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design". Prentice-Hall, Inc,. Englewood Cliffs, 1979.
Derr, K. W., "Applying OMT". SIGS Books, 1995.
Hutt, A. T., (ed.). "Object Analysis and Design - Description of Methods", John Wiley & Sons, Inc., 1994.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W., "Object-Oriented Modeling and Design", Prentice Hall, Ince., Englewood Cliffs, 1991.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J., "Design Patterns - Elements of Reusable Object-Oriented Software", Addison-Wesley Publishing Company, Reading, MA, 1995.
ProMod-PLUS V3.2S Manuals. debis Systemhaus, 1994.
Reenskaug, T., Wold, P., and Lehne, O. A., "Working with objects, The OOram Software Engineering Method", TASKON WorkEnvironments 29 March 1995.
Dillon, T., and Tan, P. L., "Object-oriented Conceptual Modelling", Prentice Hall of Australia Pty. Ltd. 1993.
Shaw, M., and Garlan, D. "Software Architecture, Perspectives on an emerging discipline", Prentice-Hall. Inc. 1996.
Elmasri, R. and Navathe, S. B., "Fundamentals of Database Systems", Addison-Wesley 1994.
Halpin, T., "Conceptual Schema & Relational Database Design", Prentice Hall 1995.
Markowitz, V. M., Makowsky, J. A., "Identifying Extended Entity-Relationship Object Structures in Relational Schemas", IEEE Transactions on Software Engineering, Vol. 16, No. 8, August 1990.
Frank, M., DBMS Interview - September 1995: Using Object Role Modelling to Design Relational Databases, DBMS Online, http://www.dbmsmag.com/int9509.html.
Although no standard definition exists, reverse engineering has traditionally been defined as a two-step process of information extraction followed by information abstraction.
The first step analyzes the subject system to identify its components and their inter-relationships. The second step creates representations of the system in another form or at a higher abstraction level.
Recently, a new approach to reverse engineering was advocated [Til95] that refines this traditional two-step approach of information extraction and abstraction. The new three-step approach is as follows:
Model Construct domain-specific models of the application using conceptual modeling techniques.
Extract Gather the raw data from the subject system using the appropriate extraction mechanisms.
Abstract Create abstractions that facilitate program understanding and permit the navigation, analysis, and presentation of the resultant information structures.
It is this definition where reverse engineering is seen as an activity which does not change the subject system; it is a process of examination, not a process of alteration. It can facilitate the understanding process through the identification of artifacts, the discovery of their relationships, and the generation of abstractions. This process is dependent on one's cognitive abilities and preferences, on one's familiarity with the application domain, and on the set of support facilities provided by the reverse engineering environment.
Reverse engineering may be performed at any abstraction level. It has been used primarily in transforming source code to higher-level representations, such as control-flow and data-flow diagrams, interconnection models, and virtual subsystems [MOTU93]. However, it can also be used at a lower abstraction level, for example to transform binary programs into source code [CG95].
Three of the most important types of reverse engineering are redocumentation, structural redocumentation, and design recovery.
Redocumentation is one of the oldest forms of reverse engineering [Sne84]. It is the process of retroactively providing documentation for an existing software system.
Structural redocumentation consists of using reverse engineering to reconstruct the architectural aspects of software.
Design recovery is a sub-area of reverse engineering that uses domain knowledge, external and/or informal information, and heuristics, in addition to traditional source-level analyses, to aid program understanding [Bigg89]. Its goal is to reproduce all the information needed for someone to fully understand the subject system.
From this, the central role of reverse engineering as a means to enable and guide the adoption of a specific evolution approach emerges. In particular, reverse engineering allows us to achieve a sufficient level of understanding of a software system, to determine the particular reengineering strategy to be adopted [Til96].
It requires analysis, considering alternatives, and making engineering tradeoffs. Such a technical engineering analysis consists of two major components: choosing the degree of legacy leverage (what can be taken over and what has to be newly created), and choosing the approach for migrating to the desired system, (how to introduce the changes into the system). Rarely is any single approach appropriate by itself, but engineering tradeoffs need to be considered.
The ability to utilize as much as possible of the existing system in the process of evolving to the desired system may be termed legacy leverage. Both the existing and the desired system can be described in terms of a collection of models. For the legacy system, code exists. Other models may have to be derived from the code or other information sources. Certain abstractions may not exist in the legacy system or may reflect undesirable properties. The goal is to eliminate undesirable properties while at the same time introducing desirable properties.
Choices have to be made as to which legacy system models to ignore, which ones to transform, and which ones to leave intact. This is illustrated in Figure 2.
The choices are driven by the understanding of the legacy system and desired system properties as well as their reflection in the different models. Consequently, we can conclude that reverse engineering technology is relevant to the following software evolution tasks:
Examples of commercially available technologies supporting reverse engineering activities are:
CG95. Cifuentes, C. and Gough, K. J., "Decompilation of binary programs", Software-Practice and Experience, 25(7):811-829, July 1995.
MOTU93. Müller, H. A., Orgun, M. A., Tilley, S. R., and Uhl, J. S., "A reverse engineering approach to subsystem structure identification", Journal of Software Maintenance: Research and Practice, 5(4):181-204, December 1993.
Sne84. Sneed, H. M., "Software renewal: A case study. IEEE Software", 1(3):56-63, July 1984.
Til95. Tilley, S. R.,. "Domain-Retargetable Reverse Engineering". PhD thesis, Department of Computer Science, University of Victoria, January 1995. Available as technical report DCS-234-IR.
Til96. Tilley, S. R., "Perspectives on Legacy System Reengineering (Draft Version 3)", SEI Reengineering Center Publication, Summer 1996.
Developing distributed applications whose components collaborate efficiently, reliably, transparently, and are scaleable is a complex task. Much of this complexity arises from limitations with conventional tools and techniques used to develop distributed application software. Many standard network programming mechanisms are based on complex and low level libraries. Another source of development complexity arises from the widespread use of functional decomposition. Many distributed applications are based on function-oriented design and implementation techniques that result in non-extensible system architectures.
The object-oriented technology provides distributed computing with many of the same benefits (such as encapsulation, reuse, portability, and extensibility) as it does for non-distributed computing. In fact, it is often more natural to utilise object-oriented techniques in the domain of distributed computing than it is for non-distributed computing. Distributed applications interoperate by passing messages. There are many variations on this message passing theme (e.g., RPC, remote event queues, byte stream communication, etc.). However, it doesn't require much of a stretch of the imagination to recognise that message passing in distributed computing is very similar to method invocation on an object in object-oriented programming. With these observations in mind, let's discuss two of the key distributed object technologies: CORBA and OLE.
The Object Management Group's central mission is to establish an architecture and a set of specifications, to enable distributed integrated applications. The Object Management Architecture (OMA) provides a framework which defines the functions supported by the component technology specifications within the OMG. The four major parts of the OMA are:
The Object Request Broker (ORB) provides the mechanisms by which objects transparently make requests and receive responses. The ORB provides interoperability between applications on different machines in heterogeneous distributed environments. The ORB is responsible for all mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. The interface the client sees is completely independent of where the object is located, what programming language it is implemented in, or any other aspect which is not reflected in the object's interface.
Object Services is a collection of services (interfaces and objects) that support basic functions for using and implementing objects. An Object Service defines the interfaces and sequencing semantics that are widely available and are most commonly used to support building well-formed applications in a distributed object environment. Operations provided by Object Services are expected to serve as building blocks for Common Facilities or Application Objects. The operations provided by Object Services are made available through the ORB. Many Object Services are identified but only a subset of them are completely specified.
Common Facilities is a collection of services that provides general purpose capabilities useful in many applications. Common Facilities comprise facilities that are useful in many application domains and which are made available through OMA-compliant object interfaces. Unlike Object Services, which will be supported on all platforms, Common Facilities is optional. For end-users, Common facilities provides uniform semantics that are shared across applications, making OMA-compliant applications easier to use.
Application Objects are objects specific to particular end-user applications.
The Common ORB Architecture and Specification (CORBA) defines a framework for different ORB implementations to provide common ORB services and interfaces to support portable clients and implementations of objects. The CORBA specification is mainly composed of the following parts:
An Object Request Broker (ORB).
An Interface Definition Language (IDL). CORBA's IDL is an object-oriented interface definition language used only to specify interfaces containing methods and attributes. It supports interface inheritance and it is designed to map onto multiple programming languages: C, C++, Smalltalk, Ada, and Java. It supports the following features: modules, interfaces, methods, attributes, inheritance, arrays, sequences, structs, enums, unions, typedefs, consts, and exceptions. A CORBA IDL compiler is used to generate clients stubs and server skeletons. Stubs and skeletons automate the networking activities in conjunction with the ORB.
A Dynamic Invocation Interface (DII). This interface allows the dynamic construction of object invocations, rather than calling a sub routine that is specific to a particular operation on a particular object: a client may specify, at runtime, the object to be invoked, the operation to be performed, and the set of parameters and their types for the operation through a call or sequence of calls.
OLE is a set of object services commercialised by Microsoft. OLE 2.0 sits on top of Microsoft's Component Object Model(COM), which defines Microsoft's underlying concept of an object. OLE is an alternative to OMG. We only speak about version 2.0 of OLE, the first one having been very limited - if, for example, a Powerpoint object was inserted into a Word application, clicking on the object automatically invoked the PowerPoint application. Added functionality in OLE 2.0 increases the integration between applications. Thus, in the previous example, the word processing application temporarily becomes the graphical application that generated the graphical element. The menu is thus transformed to add needed functionality to edit a graphical element.
OLE is implemented upon the DDE (Dynamic Data Exchange) mechanisms of Microsoft. Objects that are written to support the COM are called, in the Microsoft vocabulary, component objects. The major characteristics of OLE are:
Developing distributed applications whose components collaborate efficiently, reliably, and transparently is a complex task. However, the evolution of an application often involves migration from a centralised legacy system to a distributed Client/Server system. This kind of evolution offers some interesting features:
Migration may be done incrementally, using wrappers to encapsulate some legacy components.
It forces the definition of clear interfaces between distributed components, which simplifies subsequent evolution.
Partitioning of the application and its distribution on different platforms allows developers to adapt resources and performance to the needs of the application (load balancing).
Simplified reuse of components and potential for service composition.
This is an incomplete list of different implementations of CORBA:
Orbix provided by IONA Technologies.
NEO provided by SUN - presented in Section 4.1.1.
PowerBroker provided by Expersoft Corporation
Object Broker provided by Digital.
DSOM provided by IBM.
ORBplus provided by Hewlet Packard.
Note all these implementations are announced to be compliant with CORBA 2.0: one important aspect of the CORBA 2.0 specification is that it enables objects developed using ORBs from different vendors to interoperate transparently (by using the Internet Interoperability Protocol (IIOP)). Moreover, most of these implementations offer a mapping to Java.
OLE2 is available on Windows and Windows NT, as well as for Macintosh. Microsoft claims that ActiveX/OLE will eventually work within Apple and Unix architectures, but it has not released any specific dates.
Schmidt, D., and Vinoski, S., "Introduction to Distributed Object Computing", SIGS, Vol. 7, No. 1, January 1995.
OMG, "The Common Object Request Broker: Architecture and Specification", Revision 1.1. OMG Document 91-12-1.
OMG, "The Common Object Request Broker: Architecture and Specification", Revision 1.2. OMG Document 93-12-43.
OMG, "Common Object Services Specification", Volume 2.
OMG, "Object Services Architecture".
OMG, "Object Management Architecture Guide", OMG Document 90.9.1.
Microsoft, "OLE Programmer's Reference Volume I, OLE Guide to Programming".
Microsoft, "OLE Programmer's Reference Volume
II, Creating Programmable Applications with OLE Automation".