Component-Based ERP Design in a Distributed Object Environment

ERP (Enterprise Resource Planning) vendors have seen a dramatic increase in their sales this decade. Even though several vendors are producing great products and making huge profits, there are some problems to be resolved to make ERP applications a continuous success in the next decades. Current ERP applications have the low reusability and interchangeability of various modules among different vendors’ packages. One of the main reasons for these shortfalls is a tight coupling of ERP domain knowledge with the particular implementation tools. Also, efforts in establishing and using the standards in specifications of ERP applications have been inconsequential. In this article, strategic steps to wield a dominant power in the future ERP market are discussed. These steps are as follows: 1. Knowledge Modeling: Abstraction of Domain Knowledge from Tools; 2. Componentization of Domain Knowledge; 3. Implementation of Componentized Domain Knowledge; 4. Marketing Strategies for Domain Knowledge Components.

Extended Spatiotemporal UML

This chapter presents a conceptual modeling language for spatiotemporal applications that offers built-in support for capturing spatially referenced, time-varying information. More specifically, the well-known object-oriented Unified Modeling Language (UML) is extended to capture the semantics of spatiotemporal data. The extension, Extended Spatiotemporal UML, maintains language clarity and simplicity by introducing a small base set of fundamental modeling constructs: spatial, temporal, and thematic. These constructs can then be combined and applied at attribute, attribute group, association, and/or class levels of the object-oriented model; where the attribute group is an additional construct introduced for attributes with the same spatiotemporal properties. A formal functional specification of the semantic modeling constructs and their symbolic combinations is given and an example is used to illustrate the simplicity and flexibility of this approach.

Process Model for Round-trip Engineering with Relational Database

Iterative and incremental development of client/server database systems requires a round-trip engineering support, in particular in a design-implementation cycle. This paper identifies some more difficult round-trip engineering scenarios and defines processes needed to handle those scenarios. The processes conform to the current state-of-the-practice in forward and reverse engineering with relational databases. The paper identifies limitations of a tool-driven round-trip engineering. The limitations can be linked to three reasons: (1) the inability of a CASE/4GL tool to always generate correct incremental code after schema has been changed, (2) the need for a CASE/4GL to understand the reverse-engineered procedural parts written (or modified) in the implementation phase, (3) the requirement that a database content (extension) be re-instated at the end of each design-implementation cycle. Technical limitations introduce a risk that design models and a database implementation become misaligned and the design-implementation cycle cannot be continued for iterative and incremental software production. Project managers need a process model to impose necessary rigour on design and programming teams to alleviate technical restrictions. The paper defines a project management strategy that enforces appropriate automated and manual processes on database development teams.

Architecture and Implementation Issues

Historically the focus is on the theory of how problem-specific systems design tools can be supported by a Computer Aided Method Engineering (CAME) environment based on service object representation. To arrive at an implementation model, the conceptual model of the service object representation must be formalized. This theory is feasible when there is adequate computer support. Many researchers have emphasized strongly that requirement specification languages should have a rigorous formal basis; however, this need for formality has not been generally acknowledged in the field of information systems development. Most organizations and research groups tend to define their own methods using techniques advocated within such methods that often have no formal foundation. Discussions of modeling techniques are based on numerous examples, mostly using diagrams and notational conventions, to provide a popular style for the definition of new concepts and their behavior. In a CAME environment however, which gives the freedom to specify a modeling technique from scratch, it is difficult to avoid deficiencies such as inconsistency, lack of structure, over specification, incompleteness, ambiguity, and redundancy without using a formal approach. In automated support a formal model is used to provide stable specifications for implementation. In fact, an implementation can be seen as another, enormously detailed formal description, usually in an imperative programming language. To implement this sophisticated automated support, formal specifications of the CAME service description with adequate formal reasoning were derived earlier. In this chapter the concentration is on using representation formalism to construct a problem-specific CAME environment. Such an automated support environment must be provided for the information systems design stage in particular for the required UpperCASE tools according to the methods chosen for the problem situations. The vision is that CAME environments must function as a service-based, object-oriented MetaCASE environment that offers the services required for modeling tools, and using a mechanism to interpret the required modeling knowledge and changing the visual representation to the required form using a graphic object binding mechanism. Further, this environment must offer a mechanism for the populations of models specified according to such UpperCASE tools.

Adding Alternative Access Paths to Abstract Data Types

We present in this paper a proposal for developing efficient programs in the abstract data type (ADT) programming framework, keeping the modular structure of programs and without violating the information hiding principle. The proposal focuses in the concept of “shortcut” as an efficient way of accessing to data, alternative to the access by means of the primitive operations of the ADT. We develop our approach in a particular ADT, a store of items. We define shortcuts in a formal manner, using algebraic specifications interpreted with initial semantics, and so the result has a well-defined meaning and fits in the ADT framework. Efficiency is assured with an adequate representation of the type, which provides O(1) access to items in the store without penalising the primitive operations of the ADT.

Software Process Models are Software Too

A software process model describes a set of partially-ordered sequences of activities that are carried out in order to accomplish certain goals. While numerous process modeling approaches have been proposed over the years, it seems that none of them have yet addressed the full range of concepts described in this definition. Most focus on activities and activity ordering; few, if any, focus on representing organizational goals and process improvement. Most provide concrete implementation approaches; few, if any, describe the general model(s) upon which these implementations are built. This paper suggests a new approach for developing software process modeling systems. If “Software Processes are Software Too,” as suggested by Osterweil (1987), then so are software process models, and hence there may be processes and models that are used in regular software development that may be useful in the process modeling domain as well. The paper focuses on the domain class model as an example of one type of model that might be produced if an approach such as the Unified Process were used in the process modeling domain. Such a process, and the set of models produced by it, if used, may be helpful in moving the process modeling field forward. While identifying the conceptual needs of process modeling systems, these models leave totally open the choice of how to formalize and implement actual solutions. A domain class model for process models is developed as an example of one of these models.

Understanding the Role of Use Cases in UML

A use case is a description of a sequence of actions constituting a complete task or transaction in an application. Use cases were first proposed by Jacobson (1987) and have since been incorporated as one of the key modeling constructs in UML (Booch, Jacobson, & Rumbaugh, 1999) and the Unified Software Development Process (Jacobson, Booch, & Rumbaugh, 1999). This paper traces the development of use cases, and identifies a number of problems with both their application and theoretical underpinnings. From an application perspective, the use case concept is marked by a high degree of variety in the level of abstraction versus implementation detail advocated by various authors. In addition, use cases are promoted as a primary mechanism for identifying objects in an application, even though they focus on processes rather than objects. Moreover, there is an apparent inconsistency between the so-called naturalness of object models and the commonly held view that use cases should be the primary means of communicating and verifying requirements with users. From a theoretical standpoint, the introduction of implementation issues in use cases can be seen as prematurely anchoring the analysis to particular implementation decisions. In addition, the fragmentation of objects across use cases creates conceptual difficulties in developing a comprehensive class model from a set of use cases. Moreover, the role of categorization in human thinking suggests that class models may serve directly as a good mechanism for communicating and verifying application requirements with users. We conclude by outlining a framework for further empirical research to resolve issues raised in our analysis.

The Future of Software Development

Software development has changed dramatically in the last fifty years and will continue to change. Its future course is of particular interest to developers, in order to gain the correct skills, and to any person faced with a strategic information technology (IT) decision. It is commonly accepted that computers will play an ever-larger role in modern civilisation. There are many unknowns, but the IT decisions made today will affect the competitiveness and preparedness for tomorrow. Awareness of the central issues that will affect the future of software development is the best form of preparation. This chapter presents a view of the future of software development based on the history of software development and the results of two surveys.

Future Directions in CASE Repositories

Today, components and Component Based Development (CBD) is seen as one of the important events in the evolution of information technology. Components and CBD offer the promise of a software marketplace where components may be built, bought, or sold in a manner similar to components in other industries. In the light of the ongoing developments, in the manner and art of developing software systems, it is important to consider how the Computer Aided Systems Engineering (CASE) environment that supports building these systems can be produced on a CBD approach. In spite of the fact that CASE environments have been around since the ’70s, there are still many problems with these environments. Among the problems of CASE environments are the lack of conceptual models to help understand the technology, the poor state of user requirements specification, inflexible method, support and complicated integration facilities, which contribute to the dissatisfaction in CASE users.

Relational Data Modeling for Geographic Information Systems

This chapter addresses data modeling problems inherent in the use of geographic information systems (GIS) that are not adequately covered by traditional modeling techniques. GIS technology has only recently begun to be used for traditional system development by large numbers of organizations and there are few procedures for modeling GIS data and applications in a business context. This circumstance is partially a result of the fact that GIS developers have traditionally been knowledgeable end users or facilitators and they have generally been called on to build standalone systems, often for their own use. This paper discusses geographic systems and proposes relational modeling techniques that document organizational data integrity rules when systems that include spatial data are developed for more widespread use.