B. J. Cox, Planning the software industrial revolution, IEEE Software 7 (1990) 25--33.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....are cooperative, persistent, and aware [1] as well as autonomous (independent) These characteristics make agent oriented software systems an ideal mechanism for handling the ever growing distributed environment of today. A radical shift in our present methodologies for software engineering is due [2]. Previous software engineering methods in which software was developed for an independent closed system will not apply in the world of the Internet. Software needs to be able to handle the unexpected; in a closed or isolated system, circumstances can be mimicked and the boundaries of the expected ....

Cox, Brad J.: Planning the Software Industrial Revolution. IEEE Software, (Nov. 1990) 25--33.

....mechanism for creating different but consistent views on a complex system. Ideas for concrete tool support based on the Object Constraint Language (OCL) are sketched. 1 Introduction Building software from pre fabricated components has been discussed since a long time (e.g. McIlroy68, Cox90] as the ultimate breakthrough towards industrial production of software. It took until the end of the 90s that a number of technologies have appeared, mainly based on object oriented principles, which make the component based construction of complex software practically viable. A good overview of ....

B. Cox, Planning the software industrial revolution. IEEE Software (7)6, November 1990.

....Assemblies Figure 9. Mechanical and electronic assemblies have dependencies upon parts and connectors that have the proper directionality in stability and abstractness. Several years ago software components were hailed as the integrated circuits of the software engineering profession [9]. Component technology has justifiably displaced object technology as the sharpest tool in the programmer s toolbox, but components have not achieved their promise as parts on a shelf waiting for assembly. There are many reasons, but one is that connecting software components is far more complex ....

Cox, B. Planning the Software Industrial Revolution, IEEE Software, 1990.

....a natural step into maturity for software engineering, in the same way as it was for other engineering disciplines. Through the years a number of software development techniques aiming to component software have been proposed, examples are modular programming [16] and object oriented programming [17], but they failed to reach the full potential of component software. The last few year, the success of component based technologies like ActiveX controls [18] JavaBeans [19] and Enterprise JavaBeans [20] combined with the emergence of distributed object frameworks like CORBA [9] and COM [21, 22] ....

B.J. Cox, "Planning the software industrial revolution", IEEE Software, vol. 7, no. 6, November 1990.

....in the small one. For effective software reuse, we need an inthe large concept which makes it possible to put modules into a library, find the ones we need and put them together effectively. Such modules should have standardized interfaces by which they easily fit together like LEGO bricks [Co90]. At least two interfaces are indispensible: a downward one for accepting lower level services, and an upward one for providing higher level services. Hidden in its body, the module should have correctly implemented the latter on top of the former. Often, it is necessary to have more than ....

Cox,B.J.: Planning the Software Industrial Revolution. IEEE Software, vol 7, no 6, 1990, 25-33 13

....especially, we argue for an alternative, yet compatible, interpretation of architecture that places the individual user in a central role. The need to consider individual users is partly evidenced by the following fact. Software exists as a hybrid of two imperatives: intangibility and tangibility [2]. The intangibility imperative views software as an abstract idea similar to mathematics. The tangibility imperative concerns more immediate, accessible, and physical concepts. The main observation is that intangibles are best addressed and understood at the level of individuals, not committees. ....

B. J. Cox. Planning the software industrial revolution. IEEE Software, 7(6):25--33, November 1990.

.... In a more extreme view, it has been suggested that object technology has the 6 potential to bring about an industrial revolution in the way software is constructed, by transforming the current custom development process into one characterized by assembly of previously developed components (Cox 1990). Nevertheless, OOPLs are widely viewed as being particularly difficult to adopt and assimilate, chiefly because of the radical changes they impose on would be adopters (Fichman and Kemerer 1992; Booch 1994) As one recent commentator recently put it: object oriented technology is so radically ....

Cox, B. J., "Planning the Software Industrial Revolution," IEEE Software, November (1990), 25-33.

.... are nearing the boundaries of present system engineering methodologies and seemingly insurmountable limitations to current generation intelligent systems are being observed [48, 59, 70] These limitations have caused a fundamental rethink of the paradigms used to tackle large applications [22, 72]. Some researchers have advocated the building of systems which embody vast amounts of common sense knowledge [31] others propose that developing sharable and reusable libraries of problem solving components is the way forward [5, 57] a third group suggest that developing systems which tackle ....

B. J. Cox, Planning the Software Industrial Revolution, IEEE Software, Nov., (1990) 25-33.

....on component reuse with the last of these being perhaps the most crucial. The image of developers assembling applications from existing components rather than building them from scratch has been a central part of the OO vision since it first emerged as a commercially viable technology [1]. Besides the potential productivity and cycle time benefits, reuse of proven components (especially black box reuse) should reduce the maintenance burden, and should lead to more reliable and efficient systems [2] Although adopting a new software process technology is rarely easy, prior theory ....

Cox, B.J., "Planning the Software Industrial Revolution," IEEE Software, Vol. 7, No. 11, 1990, pp. 25-33.

....theoretic methods possible to operate on that particular data object. In ANDECS, this early binding approach is not pursued, however. Rather, the database support of ADTs and CDOs is exploited by a versatile modules concept which is based on the concept of late binding as advocated by Cox [13]. This allows an evolutionary development and set up of rather complex computational chains and loops. This is dealt with next. 3.2 Support for Widget, Tool and Package Integration In CACE computational experimentation, rather complex systems of interactively controlled computational chains and ....

Cox, B. J. (1990). Planning the Software Industrial Revolution. IEEE Software Magazine, Nov. 1990, pp. 25-33.

....do not explicitly address the design of reusable frameworks. Not only the languages and tools, but the economics, methods and culture of software development must ultimately adapt to a new evolutionary software life cycle if we are to realize the benefits of large scale software reuse [2][17] In Communications of the ACM, Vol. 35, No. 9, special issue on Analysis and Modelling in Software Development, Sept. 1992, pp. 160 165. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial ....

B.J. Cox, "Planning the Software Industrial Revolution," IEEE Software, vol. 7, no. 6, Nov. 1990, pp. 25-33.

....languages are still largely perceived as a programming technology rather than as a software component production technology. This, in turn, is because we still largely approach software development as a labour intensive craft rather than as a capital intensive engineering discipline [5][22] 26] Rather than expending all our effort and creativity on developing individual applications, we should be investing more effort and 1. In Proceedings, Esprit 1991 Conference, Kluwer Academic Publishers, 1991, pp. 534 552. 2. Authors address: Centre Universitaire d Informatique, 12 rue du ....

....Top down strategies for requirements analysis, specification and design are unlikely to arrive at any reusable components at the implementation stage. 2. Object oriented languages typically provide a very limited binding technology for composing software at the level of expressions and statements [5]. In order to compose existing objects one must program some new objects. 3. Software composition is made more difficult by the ability to define rich interfaces to objects. The most successful examples of reusable components rely on the existence of fairly simple, standard interfaces [27] The ....

B.J. Cox, "Planning the Software Industrial Revolution," IEEE Software, vol. 7, no. 6, pp. 25-33, Nov. 1990.

....bag of tools. However, software reuse has been hitherto limited to procedure libraries, that are suitable for specific tasks such as mathematical subroutine libraries. More general application frameworks are just becoming available. If the kind of software industrial revolution envisaged by Cox[3] is to take place, more general and reliable software components must become widely available. We assert that this process is just beginning to take place, with the recent announcements of high quality class libraries such as the Borland Application Frameworks, the Microsoft Foundation Classes, ....

....Old methods die hard, especially when the software tools available to support the new approaches are either not sufficiently mature or are far to complex (from a user interface point of view) to be useful in an introductory setting. Here, an analogy to the industrial revolution may be appropriate [3]. It took over a hundred years for industries to make the transition to standardized components and manufacturing assemblies. The software industrial revolution is being compressed into a much smaller time frame, with a large impetus from the software industry. We must do our part in academia to ....

B.J. Cox. Planning the software industrial revolution. IEEE Software, 7(6):25--33, Nov. 1990.

....our plans for applying it in the future. Section 6 offers conclusions. 2 Context and Motivation The state of the practice in software reuse is still far from the visionary goal of a software industry based on interchangeable standard parts, comparable to the hardware integrated circuit industry [Cox90] This is, in part, because reuse involves more than just reusing existing code modules. It involves organizing and encapsulating knowledge and experience and establishing the mechanisms and organizational structures to make them available for reuse. Fortunately, there have been a number of ....

Brad J. Cox. Planning the Software Industrial Revolution. IEEE Software, 7(6):25-- 33, November 1990.

....the software industry with an assumption that software developed using this paradigm will be more reliable, easier to maintain, and more likely to be reused. Various claims have been made regarding the objectoriented paradigm as being the silver bullet for solving the software crisis [15, 16, 19]. Claims made about the advantages of the object oriented paradigm are based primarily on opinions or anecdotes rather than on rigorous and quantitative studies and metrics to support the claims [9, 17] Software metrics have been proposed for both the procedural and the object oriented paradigms ....

B. J. Cox. Planning the software industrial revolution. IEEE Transactions on Software Engineering, 7(6):25--33, November 1990.

....hierarchy and robustness TTs could then be derived using the TTF. 4.3. 6 Software design: Components Brad Cox describes a software engineering ideal where software development involves constructing programs from pre defined components, similar to conventional engineering s use of nuts and bolts [Cox90]. A software engineering revolution similar to the industrial revolution is discussed which will move software development from a build everything from scratch approach to a build from re usable components where possible approach. Real, hardware components are defined by a specification of ....

B. J. Cox. Planning the software industrial revolution. IEEE Software, 7(6):25--33, November 1990.

....the software. We find that inheritance is used far less frequently than expected. 1 Introduction Object oriented analysis, design and programming appear to be the structured programming of the 1990 s. Proponents assert that object oriented programming is the solution to the software problem [8]. Software developed using object oriented techniques is touted as more reliable, easier to maintain, easier to reuse, etc. The object oriented paradigm may be effective in helping to solve many of the outstanding problems in software engineering. However, the claims of the proponents for ....

B. J. Cox. Planning the software industrial revolution. IEEE Software, 7(6):25--33, November 1990.

....bag of tools. However, software reuse has been hitherto limited to procedure libraries, that are suitable for specific tasks such as mathematical subroutine libraries. More general application frameworks are just becoming available. If the kind of software industrial revolution envisaged by Cox[17] is to take place, more general and reliable software components must A Framework for Object Oriented Software Engineering . 9 become widely available. We assert that this process is just beginning to take place, with the recent announcements of high quality class libraries such as the Borland ....

....Old methods die hard, especially when the software tools available to support the new approaches are either not sufficiently mature or are far to complex (from a user interface point of view) to be useful in an introductory setting. Here, an analogy to the industrial revolution may be appropriate [17]. It took over a hundred years for industries to make the transition to standardized components and manufacturing assemblies. The software industrial revolution is being compressed into a much smaller time frame, with a large impetus from the software industry. We must do our part in academia to ....

B.J. Cox, "Planning the Software Industrial Revolution". IEEE Software, vol. 7, no. 6, Nov. 1990, pp. 25--33.

....of fabricating multi agent systems in which the application developer is forced to con 1. This approach has been advocated by a number of researchers concerned with the inherent difficulties and inefficiencies in the present software engineering development process (see for example (Blum, 1992; Cox, 1990; McDermott, 1990; Neches et al. 1991; Stefik, 1986) General Cooperation Knowledge P 1 Problem specific knowledge Working Multi Agent System Application P 1 Figure 2: PCM Paradigm for Constructing Multi Agent Systems a. PCM APPROACH b. TRADITIONAL APPROACH Working Multi Agent System ....

Cox, B. J., (1990). Planning the Software Industrial Revolution. IEEE Software, Nov., 25-33.

No context found.

B. J. Cox, Planning the software industrial revolution, IEEE Software 7 (1990) 25--33.

No context found.

B. Cox, "Planning the Software Industrial Revolution," IEEE Software, Nov. 1990, pp. 25-33.

No context found.

Cox, B. J. (1990), `Planning the software industrial revolution', IEEE Software .

No context found.

B. J. Cox, "Planning the software industrial revolution," IEEE Software, pp. 25-33, 1990.

No context found.

B. J. Cox. Planning the software industrial revolution. IEEE Software, 7(6):2533, November 1990.

No context found.

B.J. Cox, "Planning the Software Industrial Revolution," IEEE Software, vol. 23, no. 11, Nov. 1990, pp. 25--33.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC