An evolutionary approach to application development with object technology
TL;DR: Acacia Technologies has studied the problem and has adopted a strategy aimed at easing the transition from procedural to OOP languages by using a phased approach, starting with encapsulation of AS/400 RPG/400TM functions, continued through relocation of modules where appropriate into a multitiered client/server architecture, with a final target of object-oriented modules communicating in a networked environment.
Abstract: Although object-oriented programming (OOP) is not new, it has only recently begun to gain acceptance among independent software vendors. Reasons for this acceptance vary, from a need for basic data encapsulation, to the promise of code reuse, through problem abstraction as a way of dealing with complexity. Despite the advantages inherent in OOP, obstacles to integration with or replacement of existing systems are significant. This is especially true for Application System/400TM (AS/400TM) application vendors, because of a tradition begun with the System/38TM of customers demanding source code. Each independent software vendor (ISV) must determine how to make the transition from procedural to OOP languages in a cost-effective way. This must be done for both ISVs and customers, who have often invested heavily in enhancing and modifying source code to meet their business needs. Acacia Technologies has studied the problem and has adopted a strategy aimed at easing the transition by using a phased approach, starting with encapsulation of AS/400 RPG/400TM functions, continued through relocation of modules where appropriate into a multitiered client/server architecture, with a final target of object-oriented modules communicating in a networked environment. This paper will discuss our approach and the part the San FranciscoTM project is expected to play in its implementation.
Citations
More filters
TL;DR: Assessment of the current status of OO technology assimilation in IS organizations and the factors influencing such assimilation from a software process innovation perspective indicates that, among the innovation characteristics, perceived complexity and perceived maturity of technology have been found to have positive relationships with organizational assimilation of O O technology.
Abstract: Object-oriented (OO) technology was expected to rapidly replace traditional functional software technology due to its productivity and quality improvement potential in software development. Still, OO technology is not yet fully understood and utilized by information systems (IS) organizations. Despite the growing interest and attention of the IS researchers and practitioners, empirical research on the assimilation process of OO technology has been limited. The present study assesses the current status of OO technology assimilation in IS organizations and identifies the factors influencing such assimilation from a software process innovation perspective. Innovation attributes and organizational characteristics were tested as determinants of the organizational OO technology assimilation based on a survey of 220 organizations. Logistic regression analysis was used to assess the relationships of innovation and organizational variables with the level of OO technology assimilation. The findings indicate that, among the innovation characteristics, perceived complexity and perceived maturity of technology have been found to have positive relationships with organizational assimilation of OO technology.Among the organizational characteristics, intensity of new technology education was positively related to organizational assimilation of OO technology, and satisfaction with existing technology was negatively related to organizational assimilation of OO technology.
75 citations
Cites background from "An evolutionary approach to applica..."
...One of the major reasons for slow acceptance of 0 0 technology is the resistance to the paradigm shift [27, 45, 51, 54]....
[...]
Dissertation•
18 Oct 2005TL;DR: The object is in other words an entity that is clearly delimited from its environment, although objects of course have contact with the environment, and at runtime an object-oriented information system can usually be seen as a network of communicating objects, which cooperate to achieve the overall functionality of the information system.
Abstract: ion is when a client of a module doesn’t need to know more than what is in the interface. The object is in other words an entity that is clearly delimited from its environment, although objects of course have contact with the environment (Taylor, 1992, p. 47). One main difference between an object and a module is that an object rarely operates in isolation, and at runtime an object-oriented information system can usually be seen as a network of communicating objects, which cooperate to achieve the overall functionality of the information system (Mikhajlov, 1999, p. 32). Note that although objects and classes are different things the concept of an ‘object’ is often, in reality, used to mean the class description itself; as a result there are, for example, ‘object models’ meaning class descriptions and ‘account objects’ meaning instances of an “Account” class (Cockburn, 1998, p. 5). An object can also consist of other objects; objects that contain other objects are called composite objects. However, in many systems composite objects have reference variables to other objects, so they do not actually ‘consist’ of other objects. (Taylor, 1992, p. 44) Composite objects can have objects that are also composite, and this type of nesting can go on (Taylor, 1992, p. 47). An object is defined in several ways in Webster’s Encyclopaedic Unabridged Dictionary of the English Language: One definition (quotation): Anything that is visible or tangible and is stable in form. Another definition (quotation): Anything that might be apprehended intellectually. A third definition (quotation): A thing, person, or matter to which thought or action is directed. Martin & Odell (1992, p. 16) define an object in the following way (quotation): An object is any thing, real or abstract, about which we store data and those methods that manipulate the data.
10 citations
01 Jan 2009
TL;DR: This chapter provides a comprehensive starting point for researchers, practitioners, and students to gain understanding of the Language-action perspective as a theoretical guidance to analyze and resolve Web service problems.
Abstract: The Language-action perspective (LAP) provides an alternative foundation for analyzing and designing effective information systems. The fundamental principle of the LAP approach is people perform actions through communication; therefore, the role of information systems is to support such communications among people to achieve business goals. Basing on linguistic and communicative theories, the LAP approach provides guidance for researchers to gain understanding on how people use communication to coordinate their activities to achieve common goal. Web services, a leading technology to develop information systems, aims to support communication among services to achieve business goals. The close match between fundamental principles of Web services and the LAP approach suggests that researchers can use the LAP approach as a theoretical guidance to analyze and resolve Web service problems. This chapter provides a comprehensive starting point for researchers, practitioners, and students to gain understanding of the LAP approach.
6 citations
Cites background from "An evolutionary approach to applica..."
...The object-oriented paradigm provides inadequate support for implementing applications over the Internet because object-oriented applications are rigid and hard to evolve (Henders, 1998)....
[...]
01 Jan 2009
5 citations
TL;DR: Two years ago, the IBM Systems Journal published an issue containing papers on the content and use of the IBM SanFranciscoTM product, and this essay provides a brief review of some of these changes and introduces the papers in this issue related to the San Francisco theme.
Abstract: Two years ago, the IBM Systems Journal published an issue containing papers on the content and use of the IBM SanFranciscoTM product. Since that time we have seen changes: in the product, in how customers are using the product, and in the marketplace in general. This essay provides a brief review of some of these changes and introduces the papers in this issue related to the SanFrancisco theme.
References
More filters
Book•
01 May 1991
TL;DR: A text on industrial system development using object- oriented techniques, rather than a book on object-oriented programming, will be useful to systems developers and those seeking a deeper understanding of object orientation as it relates to the development process.
Abstract: A text on industrial system development using object- oriented techniques, rather than a book on object-oriented programming. Will be useful to systems developers and those seeking a deeper understanding of object orientation as it relates to the development process.
1,474 citations
Book•
01 Feb 1995
TL;DR: This guide looks at the development cycle of OOP, bringing its snares and shortcomings into focus to help achieve successful design and implementation.
Abstract: This guide looks at the development cycle of OOP, bringing its snares and shortcomings into focus to help achieve successful design and implementation. It clarifies the differences and similarities between OOP and classic software engineering and provides strategies for avoiding the pitfalls.
129 citations
Book•
06 Nov 1991
TL;DR: In this article, the authors address the issues facing the growth of object technology and provide a glimpse into the future of this evolving paradigm, and present a survey of the current state of the art.
Abstract: This book addresses the issues facing the growth of object technology and to provide a glimpse into the future of this evolving paradigm.
107 citations
TL;DR: This paper examines empirical data from several commercial products developed using object-oriented methods and model and simulate the impact of the software task-completion incentives and deadlines on the productivity that might be expected from a technology with high-performance potential.
Abstract: Unless the business model that governs software production adjusts to new technology, it is unlikely that an investment in the technology will result in real productivity benefits. Commercial development always takes place in the context of a business model, and in that context an understanding of how business constraints influence commercial software development is imperative. As software markets become more competitive and business pressures shorten software development cycles, improved software development productivity continues to be a major concern in the software industry. Many believe that new software technology, such as object-oriented development, provides a breakthrough solution to this problem. Unfortunately, there is little quantitative evidence for this belief. In this paper we explore the relationship between the business model and the productivity that a software development methodology can achieve in a commercial environment under that model. We first examine empirical data from several commercial products developed using object-oriented methods. The results indicate that object-oriented development may not perform any better than “procedural” development in environments that lack incentives for early completion of intermediate project tasks. We then model and simulate the impact of the software task-completion incentives and deadlines on the productivity that might be expected from a technology with high-performance potential. We show how and why some common business practices might lower project productivity and project completion probability. We also discuss to what extent poor software process control and (im)maturity of the technology compounds the problem.
30 citations
TL;DR: Development tool strategies are presented that encourage a more evolutionary approach, easing the transition between the traditional and object worlds, and masking the complexities of object technology by exploiting higher-level rapid application development techniques.
Abstract: Object technology is a well-known advance for developing software that is receiving a great deal of attention. Unfortunately, the educational investment required and the additional complexity introduced by most tools that support this technology have dampened its rate of adoption by many enterprise developers. To bridge this skills and technology gap, development tool strategies are presented that encourage a more evolutionary approach, easing the transition. Rather than requiring totally new skills and tools, these strategies take advantage of the strengths and familiarity of traditional facilities—they hide much of the raw technological complexities and yet exploit the strengths of object technology by supporting the creation of transitional applications. The strategies described fall into two categories: bridging between the traditional and object worlds, and masking the complexities of object technology by exploiting higher-level rapid application development techniques.
12 citations