Object Oriented Requirements Analysis

The ability to correctly identify system requirements is seen by most Information Systems (IS) researchers and practitioners as essential to the design and development of effective information systems (Yadav, Bravoco et al. 1988; Vessey 1994). Requirements are used to drive all subsequent stages of systems development and are critical to system validation. Incorrect requirements or poorly specified requirements usually produce systems that require major revisions or are abandoned entirely (Pressman 1996). Recently, many new techniques and methodologies have been introduced to assist analysts and users in efforts to identify and specify system requirements (Coad, North et al. 1995) (Pancake 1995). One of the newest approaches to be used in this effort to improve requirements analysis is the application of object oriented analysis (OOA).

Challenges and Issues to Consider When Upgrading Legacy Applications

This chapter will focus on the challenges and issues an organization faces when trying to integrate or migrate their legacy applications with more advanced client/server information systems. These applications present a challenge when an organization attempts to integrate its legacy applications with newer technologies due to the rigid binding of the client to the legacy application server. FAIME, is an object oriented methodology that provides the tools to address application interoperation and plug-and-play. These tools open closed legacy applications through legacy applications decomposition and produce executable objects that bridge different operating systems, communication infrastructures, and databases. To convert a COBOL legacy application to an object-oriented application, a complete restructuring of the legacy program is needed. Objects and their inheritance structure must be identified, data usage and data flow must be analyzed, and instructions must be allocated to objects. Dynamic Object Oriented Programming allows parts of an application design that are represented by objects, to be modified dynamically. Integrating or migrating legacy applications with newer more advanced client/server architectures can be a very expensive and time-consuming undertaking.

Object Oriented Testing in Software Development

Object oriented technology is still growing and has not yet matured. Many articles have been written on object oriented software development processes, particularly in the area of testing. Most of the publications seem to agree with the fact that object oriented testing is a challenging aspect of the software development process. The main reason for this view seems to revolve around the fact that the objects and the code are inseparable and also, the idea of inheritance. Despite these views, the publications all seem to agree on one aspect, that object oriented when successfully tested leaves a better-maintained product compared to the traditional non-object oriented software. Object oriented software makes better maintainable software; it also has an added advantage over traditional software development because in the final analysis, it will cost less by shortening the development time as well as cutting down the cost of maintenance.

Building on Structured Design Techniques in the Object Oriented Environment

The term structured methods refers to a philosophy of software development which emphasizes an adherence to a set of consistent rules or methods throughout a project (Yourdon, 1989). These methods include broad programs such as Systems Development Lifecycles and Methods and Information Engineering as well as individual techniques such as structured programming, data flow diagramming, data modeling, and Object Oriented methodologies. Perhaps the newest, most visible, but least understood of these methodologies are the Object Oriented methods. The specific set of rules or methods that organizations use can come from a variety of sources. Organizations often implement their own methodologies for software development, using tools and techniques borrowed from a variety of formalized methodologies. Commercially produced methodologies are also widely used, usually obtained from software vendors and consultants. The primary objectives of traditional structured methodologies can be summarized as follows: (Martin and McClure, 1988) • Achieve high-quality programs of predictable behavior • Achieve programs that are easily modifiable (maintainable) • Simplify the development process • Control the development process • Speed up system development • Lower the cost of system development

What Are the Actual Industry Expectations and Needs with Regard to Object Oriented Technology?

This chapter is a review of journals and printed articles published during the last two years. It will give you an idea of the current needs in the industry due to object oriented technologies. It also analyzes factors like the lack of mainstream products and object standards influencing the development of skilled professionals in working with object databases. It will show industry trends and needs and make recommendations for training approaches in order to develop skilled professionals who will satisfy these needs. It will tell you what you need to know to make yourself more marketable in an ever-changing industry.

Reuse in Object Oriented Modeling

Object Oriented (OO) technology and software reuse are widely believed to be key ingredients to improving systems development productivity and quality (Meyer 1989; Cox 1990). Software reuse is broadly defined as the application of existing systems development artifacts to new development projects. OO technology supports reuse in a number of ways. For example, at the programming level, reuse is supported through built-in components (classes) and specialization of the class hierarchy. At the analysis and design levels, OO pattern handbooks provide reusable solution templates to known modeling and design problems (Gamma et al. 1995; Fowler 1996). The systematic use of these and other artifacts can, at least in theory, reduce the time taken to develop new systems by leveraging the knowledge gained from prior projects.

Software Reuse and Object Technology

Companies are increasingly requiring that new information systems development projects employ object oriented (OO) analysis, design and programming approaches. The hottest new Web tools and languages have object capabilities built into them. Much of the movement toward the OO paradigm for systems development is based on claims of pioneers and vendors that adoption will lead to better and faster designs, more maintainable systems, and most audibly, reusable software. A typical set of attributions appears in CACM: “OO technology promotes a better understanding of requirements and results in more modifiable and maintainable applications, providing other benefits such as reusability, extensibility, robustness, reliability, and scalability. OO technology promotes better teamwork, good communication among team members, and a way to engineer reliable software systems and applications” (Fayad and Tsai, 1995).

Technical and Market Viability of Object Database Technology

Despite its decade long history, object database technology has never entered mainstream system development. In this work, I look at the background of the slow adoption, and the possible future outlook of this technology based on my personal experience and the published literature. Object databases represent a revolutionary new technology and provide superior storage facility for complex data structures and types. They also enable close language binding and a unified development process. It is a mature technology with advanced database management and development features and has several proven and robust deployment examples. Besides its current technical excellence, this technology is also demonstrating future potential through such emerging technologies as Java, Application servers, and XML. The past failure of object databases to proliferate the market was mainly due to unawareness, lack of skills, and the overwhelming existing investment in relational systems. As these factors are changing by the end of this century and new technology adoption is accelerating, object databases are looking forward to a slow but sure take off.

Distributed Object Business Engineering

Tomorrow’s business environment will make it increasingly difficult for businesses to operate efficiently. To gain the needed edge, in the global economy, many businesses are looking towards information technology. By utilizing technology as a conduit, companies are able to leverage their greatest asset: their internal knowledge base. This chapter presents a framework for architecting enterprise-wide object based information systems. These next-generation systems maximize information value throughout the enterprise, while reducing development time and effort throughout the system lifetime. By presenting a complex concept in a pragmatic fashion this chapter should provide benefit for both information architects and business managers.

Understanding Distributed Object Oriented Systems

Distributed objects, as applied to the term distributed object oriented systems, can be defined as those objects that have many locations on a system (network), but stemming from the way they interact with one another, appear to be coming from just one location (Taylor, 1996, p. 263). Obviously, this presents distributed-object oriented systems with design complexities because the hardware and software are not located in one place but, to the user, must look as though they are. These complexities can be well appreciated by looking at the literature. Montlick (1999) uses the very term complex in a chapter heading related to distributed object oriented systems. He attributes this building complexity to the fact that object oriented technology is in its infancy. Given that distributed object oriented systems are complex and in their infancy, it is hard to decipher a clear definition of distributed object oriented systems and the client/server (frontline computer/back-line computer) model or environment. Some such as Berson (1996) say that client/server computing is a form of distributed computing, while others such as Taylor (1996) say that client/server computing is different from distributed computing. Understanding the client/server environment adds to the complexity of understanding distributed object oriented systems. The purpose of this chapter, then, is to provide an understanding of what distributed object oriented systems are, no matter how complex they may appear to be. To provide a foundation for this understanding, the “building block” evolutionary process leading to the development of distributed object oriented systems will be given first. To foster an understanding of the systems themselves, it will be shown that no matter how complex, for a system to be distributed object oriented, basically several key ingredients must be in place. Accordingly, it will be shown that, fundamentally, distributed object oriented systems must have two object oriented properties or characteristics: encapsulation (the ability to hide code from the user) and messages (the way objects communicate). Additionally, it will be shown that software components (objects) of the distributed object oriented systems must have certain inherent features. Aside from the two object oriented properties and the certain inherent features, any critical system must have the ability to keep its data in a consistent state. This is particularly important when concurrent (at the same time) transactions (a unit of work) are executed. It was determined that because distributed object oriented systems are complex and in their infancy, in order to produce a basic definition and understanding of what they are, it would be necessary to analyze a cross-section of the current literature: i.e., information found in books, articles, journals, and Internet sources as well as information obtained from interviews with an IT expert.