wtwolfe@hubcap.clemson.edu (Bill Wolfe) (09/04/89)
Welcome to the comp.sw.components newsgroup!!!
The following is a description of the scope of the newsgroup:
$ This newsgroup will facilitate discussions about software components
$ and their design, implementation, and utilization. It is probable that
$ this will be mainly a group of professional component developers, people
$ who are training to become such a professional, and/or people who have an
$ interest in developing their own components from time to time.
$
$ As a "public service", we are also here to help and advise all component
$ users who need advice, and to provide a forum for reviewing the software
$ components provided by vendors. We are also here to allow the people who
$ developed any products which are criticized to show why perhaps the
$ criticism may not be entirely justified, or to seek ideas regarding how
$ the component(s) could be improved, and to provide a means by which new
$ techniques can be spread throughout the component development community.
$
$ Also, questions such as "How can I handle problem X which arises when I
$ try to implement component Y in language Z?" and "I have a nifty priority
$ queue, and would like a B+ tree; anyone wanna trade?" are encouraged.
> What, pray tell, is a "software component"?
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
scotth@boulder.Colorado.EDU (Scott Henninger) (09/05/89)
|>From: wtwolfe@hubcap.clemson.edu (Bill Wolfe) |Subject: Welcome to comp.sw.components!!! |Date: 3 Sep 89 18:19:37 GMT | | | - 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. This is a narrow viewpoint of software reuse that does no justice to the difficulty of constructing a good software reuse system. If the above statement were true, then the problem was solved years ago with the advent of software libraries. Unfortunately, there are a number of problems with software libraries that make them less than fully useful: 1. Users do not know what components are available. I.e. it is easier to write a component themselves than to try to look for something in the library. This is an information retrieval problem. 2. Users do not know how to use the available components or what they do. Tools are needed to help the users with these tasks. 3. Library components rarely fit a need exactly. No matter how hard a library developer tries to cover all contengencis, someone will eventually need something slightly different than what is offered. Facilities are needed to allow modification so the components can be tailored to meet a specific user's needs. The following article expounds on these viewpoints: "Cognitive View of Reuse and Redesign" G. Fischer, IEEE Software, July 1987, 4(4), pp. 60-72. In addition, I have only addressed the reuse of implementation units. It may be that we can get a much larger return on investment by reusing design artifacts or other work products associated with creating a software system. | 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. Unfortunately, this is a misleading analogy. In a canonical sense, hardware only has to implement one thing - a Von Neumann machine (there are slight adjustments to this architecture, but the point stands). Software is called upon to implement a vastly larger number of abstract machines. A DEC VAX and a IBM 3090 are general purpose computing machines (with different implementations). You can port programs that run on one to the other. A math package and a windowing package perform very different functions. You would not think of porting a logarithms functions to a window system. Because of this fact, certain elements, such as an ALU, are universially necessary in hardware, but do not exist for software. Although one can contrive certain building blocks for software, there are no elements (other than a hardware platform and a compiler/interpreter) that must *necessarily* exist for a software system to work. This makes software and hardware *fundamentally* different, and to use one as an analogy for the other will only lead to the sort of difficulties being experienced by those who believe in this approach. For example, notice that most efforts to create software components systems are criticized for their limited scope of applications. I would argue that this is a direct consequence of the hardware analogy, which is doing more harm than good. -- Scott scotth@boulder.colorado.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (09/05/89)
From scotth@boulder.Colorado.EDU (Scott Henninger): > [a component should provide a generally useful reuseable service] > > This is a narrow viewpoint of software reuse that does no justice to the > difficulty of constructing a good software reuse system. The statement described good characteristics of a software component; it did not and was not intended to address the environment in which the component was embedded. However, the topic has arisen in this newsgroup; in particular, I posted a favorable review some four to six weeks ago of the article "Domain Analysis -- From Art Form to Engineering Discipline" (Proceedings of the Fifth International Workshop on Software Specification and Design, May 19-20, 1989, SEN V14 N3), which views reusers as learning systems and provides a framework for assessing the progress of a reuse system. Around early June, there was a discussion of STARS research which was directed toward constructing an effective Ada software component retrieval system through the use of a knowledge-based librarian. These topics should probably be included in the welcome message, but any implication or inference that these topics have not been covered in this newgroup is simply incorrect. > | 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. [...] > > Unfortunately, this is a misleading analogy. [...] Although one can > contrive certain building blocks for software, [...] most efforts to > create software components systems are criticized for their limited scope > of applications. I would argue that this is a direct consequence of the > hardware analogy, which is doing more harm than good. The presently limited extent to which software components cover the large number of available domains is largely a consequence of the fact that domain analysis (as described in the cited article) is still an embryonic field. IMHO, the hardware analogy is very appropriate. Bill Wolfe, wtwolfe@hubcap.clemson.edu
scotth@boulder.Colorado.EDU (Scott Henninger) (09/05/89)
|>From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) |Date: 4 Sep 89 20:22:57 GMT | |>From scotth@boulder.Colorado.EDU (Scott Henninger): |> [a component should provide a generally useful reuseable service] |> |> This is a narrow viewpoint of software reuse that does no justice to the |> difficulty of constructing a good software reuse system. | | [...] "Domain Analysis -- From Art Form to | Engineering Discipline" (Proceedings of the Fifth International | Workshop on Software Specification and Design, May 19-20, 1989, | SEN V14 N3), which views reusers as learning systems and provides | a framework for assessing the progress of a reuse system. [information | retrieval approaches] This is on the right track. I still argue that there is a significant tools problem that must be solved before reuse becomes a sucessful software engineering strategy. -- Scott scotth@boulder.colorado.edu