Talk:Software componentry

Componentized

"Componentized" (apparently misspelled "componetized") is not a word, according to Webster's. I am not quite sure how to re-word the sentence.

Componentized, while not in my OED, is good for me. Georgesawyer 02:47, 5 Mar 2004 (UTC)

Does anyone have any good external links discussing component-based software engineering? Brent Gulanowski 21:11, 30 Oct 2003 (UTC)

A link to McIlroys paper that started it is provided at the bottom of the page. That's a very good start. Nixdorf 15:35, 6 Mar 2004 (UTC)

---

Smalltalk

Smalltalk of Xerox PARC in the 1970's should be mentioned here. Smalltalk was the first language to include objects in programming. Georgesawyer 02:47, 5 Mar 2004 (UTC)

Software componentry is not the same as OOP at all. Is Smalltalk big on software componentry as such? - David Gerard 21:57, Mar 2, 2004 (UTC)

It just seemed that objects were stressed in the first few paragraphs of the article, and objective C was claimed as their source; so, I brought up Smalltalk. Is Smalltalk big on componentry? Not to my knowledge. Georgesawyer 02:47, 5 Mar 2004 (UTC)

Predesign

I have seen components designed in advance to fit. Never have I seen components merely with the correct fit work together correctly without predesign, naturally. Componenture seems to provide access across architectures, not interoperability with strange software. Georgesawyer 02:47, 5 Mar 2004 (UTC)

Unix tools

Software components (tools, IC's, blocks of software) are well exemplared by Unix tools. They interconnect, e.g. by pipes. Georgesawyer 02:47, 5 Mar 2004 (UTC)

Java packages

A Java package with its levels of information hiding is a kind of component, in the article's loose sense equivalent to module. Java programmers can and do divide their software into components, one in each package. Georgesawyer 02:47, 5 Mar 2004 (UTC)

Applications

One type of software that really does act like components is applications. You can swap your word processor and th new word processor can read the old files in many cases. The component article doesn't talk enough about how difficult components really are. Also, there is no criticism about the overwrought analogy to bolts in autos or chips in electronics. Kd4ttc 03:01, 5 Mar 2004 (UTC)

XML-RPC is not an IDL.

It's an RPC mechanism.

There is a system interface that, if used, may optionally return a weak interface description. (no type information!)

LionKimbro

Timeline Needed

To put Software Componentry into proper context a timeline is necessary. My own computer science baccalaureate was earned at a time when structured programming was just beginning to be hailed as THE solution to the software development crisis, which never is overcome whatever new ideas are developed and applied. Structured programming restricts programmers from using jumps, as the hardware is able to do. Instead, programmers must compartmentalize their code into straight-line code, loops, conditionals, and subroutines. Some of the code that I inherited from others implemented subroutines as repetitions of the same code over and over wherever it was needed. This saved a register (I was informed) and was also "more efficient." It was also a bear to maintain, but this was only my concern. As my career advanced, various "new" programming languages were introduced. Industry advanced from assembly language, COBOL, Fortran, and PL/I to C and Smalltalk. Objects became de riguerre. Having now created many successful commercial programs using object-oriented techniques, I seem to have learned enough to find my way around the relevant concepts. I still have trouble deciding how to partition a problem into the best collection of object classes. Not every use of a class can easily be seen as another instance of the IS-A relationship. So base classes and derived classes don't always occur to me. Eventually we get to Frameworks which remind me of Microsoft's Foundation Class (MFC), a framework of some ill repute that made programming Windows desktop applications easier than it was before with plain old Petzold-style programming. What is a Framework, anyway. Can any arrangement whereby what I'm working on must be called by some higher authority be termed a Framework? Must a Framework be documented or is documentation optional? Unix has CORBA and Windows has COM. These two competing component instancing mechanisms seem to be ignorant of each other. Adherents cling to whatever they are familar with. A software component is something that performs a definite set of functions (now termed methods) as part of class instances termed objects. The classes implement interfaces. Interfaces implement methods. An interface specifies only the calling convention. The internal arrangement of objects is completely opaque. On account of this, it is possible to replace one implementation of an interface with a completely different implementation (in a different language, if you like) without impacting the callers as long as both implementations are correct. Callers cannot take advantage of how the methods work internally because such knowledge is (supposedly) impossible for them to acquire. In the real world, methods will at least take on additional responsibilities over time and it may be decided that some methods should have been implemented on different interfaces. Thus comes about the versioning problem. Since software components are meant to act as public agents widely available as a service to many, user A may be written to use the old interface whereas user B may be written to use the new interface. Should user B find itself on a computer where only the old interface is available, it could gracefully degrade its function so as to use the old interface. What a wonderful world! Next, we get into software patterns where experts have identified ways in which objects are arranged to solve common problems. These should be committed to memory or flash cards so that they can be drawn upon as resources in the software development laboratory or to amuse your friends at cocktail parties. Penultimately, we have remote procedure calls and the problems these evoke such as remote object instantiation, proxies, marshaling, object lifetime maintenance, special heaps for use by same and on and on. Finally, we come to the "programming language" XML (no such thing -- but called that by certain marketeers), and anything derived from or loosely associated with SGML like that awful beast HTML which has no discipline at all. The Worldwide Web Consortium is busy making standards and industry is busy ignoring them. When is XSL a good thing? What about Cascading Style Sheets? And the whole point of this rant: how did this history come about, who were the leading players, what were the political aims of the powerful forces who shaped these things, and WHEN did significant changes occur?

Business-oriented components

The article distinguishes between OOP and "componentry" by suggesting that while OOP focuses on "modelling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways", software componentry "makes no such assumptions, and instead states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics."

While this is, I believe, true as far as it goes, there is another vibrant strand of software componentry that sees components as "objects in the large" that map far better than OOP objects can to real-world (business) processes and entities. This strand also focuses on providing middleware that makes life as easy as possible for the designer/programmer.

Some early proponents of this approach called their components "business objects" - which was unfortunate, as the term had many quite different meanings at the time (during the 1990s).

See Peter Herzum and Oliver Sims, "Business Component Factory", Wiley 2000, and also Peter Eeles & Oliver Sims, "Building Business Objects", Wiley 1998. An early (now out of print) book on this strand of software componentry is Oliver Sims, "Business Objects", McGraw-Hill 1994. See also the Newi middleware.

merger proposal

There seems little reason to have an article on Software Componentry as well as an article on Component-based software engineering (CBSE), so I proposed a merger. Some people thought I meant merging from CBSE into here, and objected on the grounds that CBSE is the better-known and better-established term. I am therefore proposing merging from here into CBSE. See also CBSE Talk page --RichardVeryard 21:13, 8 June 2007 (UTC)