billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (05/06/89)
From garry@batcomputer.tn.cornell.edu (Garry Wiegand as guest): > What, pray tell, is a "software component"? (A library "tool"? A subroutine? > A flowchart? An algorithm? A programmer?) I have not encountered this > term of computer jargon before... In _Software_Components_With_Ada_, Booch defines a software component as "a container for expressing abstractions of data structures and algorithms". A software component is generally expected to be: - cohesive; it should denote a single abstraction. Examples are the stack, queue, list, tree, and graph abstractions. - reuseable; it should provide a sufficiently general and useful service to ensure that it will be used over and over again by many different programmers for many diverse application areas. A primary reason for the existence of software components is that they need only to be written once; once written, the costs of development can be spread over thousands of applications, making the cost to any particular application trivial. This certainly is not the case for the alternative, building the same functionality up from scratch for each new application. - secure; it must perform reliably under any reasonable circumstances. If an insertion into a tree causes memory to be exhausted, it is the responsibility of the component to see to it that there is no change of state (hence, the consequence of the memory being exhausted is simply that the insertion does not occur; the component is left in whatever state it was in prior to the attempted insertion), and to report the failure to the user (e.g., by raising an exception along the lines of Unable_To_Insert_Due_To_Memory_Exhaustion). Also, advanced languages such as Ada make it possible to simultaneously pound a component with arbitrarily large numbers of service requests from many different tasks; the component must service all such requests in a serializable manner, without leading to an inconsistent internal state. A well-written component will, furthermore, satisfy such requests in parallel (i.e., will not just achieve serializability by simply processing requests one at a time, thus causing big delays). Finally, it must be impossible for a user to examine or alter the internal state of a component, unless the user calls a procedure or function designed to provide information regarding the component's state (e.g., the position of the current item in a linked list); this requirement is typically satisfied by language constructs like the Ada "limited private" clause. Intuitively, a software component is analogous to the hardware components (e.g., integrated circuits) which have been used by hardware engineers for a very long time. By adopting their methods, we hope to reduce the costs of software development, improve the quality of our software, and accelerate software production. This will lead to lower financial barriers to software development, and thereby accelerate the use of software systems throughout the economy, with global economic benefits. If you'd like to read more about software components, Booch's _Software_Components_With_Ada_ is a good place to start (ISBN 0-8053-0610-2, Benjamin/Cummings, QA76.73.A35B65). Also, simply keep reading this newsgroup!! :-) Bill Wolfe, wtwolfe@hubcap.clemson.edu