Talk:Component-based software engineering

untitled

CBSE is a cute new branch in Software engineering and should have its own page in Wikipedia. Better somebody to write the article instead merging it with something that is not appropriate. Check the searches-most people (like me) will search for CBSE, not "software componentry" (who named that?).

I agree with that... Never heard of 'software componentry' before... jytrdfguygkgtuytfjhgfvjhtd

paradigm (yes or no)

For me as a reader and user of the article, I don't know if component oriented programming is a new paradigm that's able to master all programming needs on a higher abstraction layer or if c.o.programming fits the needs of software "evolution" and system independence and other matters of elegance better than the old appoches.

My question now is, can this elementary consideration be taken in the intro of the article. thanks for reading. i surely couldn't make any serious changes to the article, but i'm interested in being informed by all the wikipedia authors.--93.199.221.229 (talk) 17:40, 24 February 2010 (UTC)

The "Some peers[who?] will even talk of modularizing systems as software components as a new programming paradigm." part is true. One example is Adam Martin (see this article as an example: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/) --64.121.110.6 (talk) 19:20, 18 November 2011 (UTC)

Why merge?

CBSE (sometimes known as CBD - component based development) has been around for many years. The current article on CBSE is merely a stub; I cannot see how this article could be fleshed out without repeating stuff that is already in the Software componentry article. The merger question isn't whether CBSE and software componentry are precisely the same concept, but merely whether Wikipedia should have one article covering both concepts, with redirects where necessary. My view in this particular case is that one article would be simpler and clearer than two separate articles. However I agree with the previous comments that the term "software componentry" is relatively unusual, so it may make more sense to merge the software componentry material into the CBSE article rather than the reverse. --RichardVeryard 12:22, 20 April 2007 (UTC)

User:Radagast83 has deleted the merge tags on the grounds that there is no consensus. The original merge tag did not specify the direction, so some people interpreted it as a proposal to merge the CBSE article into the software componentry article, and objected to a merger in this direction, largely on the grounds that CBSE was an important notion and software componentry was a less well-known notion. I think this is a fair objection, but it doesn't represent opposition to a merge in the opposite direction - merging the software componentry article into the CBSE article. Nobody has disagreed with my argument for a merge in this direction. I therefore think it is reasonable to reinstate the merger proposal, but this time being more definite about the direction of the proposed merge. --RichardVeryard 21:03, 8 June 2007 (UTC)

Move software componentry to CBSE [merging as necessary] -- Jonmmorgan 23:41, 12 August 2007 (UTC)

Indeed!

I'm not even convinced this term "software componentry" is really wide used. Looking at the "in other languages" section of the other article, all links are(in the given languages of course) about "Components(Software)", not about "Software componentry"... 200.137.197.12 19:37, 19 May 2007 (UTC)

some review comments

• Although many distributed computing frameworks/middlewares defined their proprietary component models, the distributed computing itself is conceptually orthogonal to CBD. Specifically, many distributed computing frameworks/middlewares in the list are not relevant to CBD. This article sent a misleading defintion of CBD, namely, a distributed computing (or good distibuted computing) framework is automatically a CBD framework or should define its own CBD model. This is not only not necessary true, but also architecturely wrong! A CBD model should better be defined orthogonal to (rather than tying to) a specific distribute model. This allows the same CBD model to work with different distributed computing models/middlewares and vice versa.

• Similarly, interface description languages are also orthogonal to CBD. And many listed IDLs are irrelevant to CBD either.

• I don't see why the generic programming should be mentioned in this CBD article? If GP was CBD, why C library fucntions (for instance, printf()) wasn't CBD? —Preceding unsigned comment added by Kjin101 (talk • contribs) 18:23, 29 November 2007 (UTC)

component

what is a component in a software? whether it is a kind of package or program? —Preceding unsigned comment added by 203.99.197.2 (talk) 06:29, 28 October 2008 (UTC)

I was confused by this concept and this article too, and I'm a computer scientist! Here's a concrete and typical example: As you are installing a video-game it says it requires DirectX and .NET to run and installs that for you as well. DirectX and .NET can be thought of as high level components of the video-game software. As another example some applications will come with their own specific version of Perl, Java, Apache HTTP Server and MySQL separate from the rest of the system. These examples illustrate that a component can be a package/library (like DirectX and .NET) just as easily as a full program (HTTP Server or MySQL). Designatevoid (talk) 02:52, 5 October 2010 (UTC)

The most important difference between OOP and CB is about interface, reuse and business logic. First, component must have a clear defined interface (input & output). Second, a component should be reusable in other contexts and that's why, third, it shouldn't contain any business logic. —Preceding unsigned comment added by 80.174.16.112 (talk) 11:22, 10 April 2011 (UTC)

Anthropomorphism?

When compared to Object-Oriented Programming, the text says CBD discourages anthropomorphism. If this is a relation to OOP, shouldn't the correct term be 'polymorphism?' Anthropomorphism relates to giving non-human things human-like characteristics, whereas polymorphism refers to inheritance and child types being equivalent to parent types, but not vice-versa. (A square is a rectangle, but a rectangle is not a square.) I'm not an expert, but I figure if you're comparing two things, the term had better relate to one of them!

66.191.95.62 (talk) 14:14, 24 December 2008 (UTC)Programmer

I never heard of it too. This must be a mistake and I am fixing it. Ramiro Pereira de Magalhães (talk) 14:14, 11 January 2009 (UTC)

Software Component

We should replace the article "Component-based software engineering" with "Software Component," or at least reinstate the "Software Component" article as an independent item.

The new "Software Component" article should emphasize the meaning of component as it has now evolved. Specifically, in the context of Web Services and Cloud Computing, we see a specific set of defining characteristings of software modules that make them components, not just classes, modules, or programs. Of course even a method implementation or class is "reusable", a defining characteristic of a Software Component. However, methods and classes are generally used in code that is compiled together. To replace them you must change the client code and recompile (as the primary means of replacement). To make them dynamically configurable requires extra effort and/or frameworks such as Spring, or J2EE xml-based extensions. Also, the java Swing framework actually has a class called Component. Our definition of Software Component does not exclude that "Component" but makes clear the distinction between architecturally configurable Software Components, and other software items that can be called components for other reasons.

Simply stated for the moment, a component is able to be selected and incorporated into a design through well established interface protocols; it is reasonably understandable through such protocol descriptions; it is designed with the intention of replaceability; it may be available through SaaS. The new article should elaborate the several well established protocols and techniques whereby components can be "wired" *without modifying* them. By wired I mean the components interfaces are made to communicate (know about each other) through *configuration* techniques. As a result, applications built largely with software components are collaborations. In this context, software components are provisionable without deep understanding of their internal design, analogous to the way a building architect can select standard-compliant structural members, portals, utilites and part conforming to building codes.

Any thoughts before I go ahead? collaborate? Contact: juan2000@iJSolve.com

Rewrite?

I notice the article has been tagged with "Rewrite" (for a year now!), but there isn't really any discussion going on about it here. So let's fix that. I'd just do it myself, but like Designatevoid up the page a bit, I'm a computer scientist and I can't get my head around this!

My main problem is that I'm muddling through on my own trying to figure out what distinguishes software components from libraries, OO, cross-language bindings, and pretty much every other concept of software reuse and modularity out there. Surely there must be some important, fundamental difference, because if you (for example) use CORBA, you're doing components, but if you write a Python package (or binding to a C library), you're not; XPCOM is a "component model", but the Java standard library is not; et cetera. Yet I keep reading definitions and explanations that say a lot and clarify nothing. Either they're circular...

"What's a Jimbo Wales?"

"Jimbo Wales is a flarglehoffer."

"What's a flarglehoffer?"

"'Flarglehoffer' is a term used in jimbology to describe the practices and characteristics that distinguish Jimbo Wales from non-Jimbos."

...or they tell me lots of things about it that fail to capture or explain what it is.

"Could you explain Jimbo Wales to me?"

"Jimbo Wales likes kittens, getting caught in the rain, and schnitzel with noodles."

"Umm, that didn't help. What is Jimbo Wales?"

"Jimbo Wales is an American male with blue eyes, a close-trimmed beard, and significant Internet fame."

"We're getting somewhere. But what's the difference between Jimbo Wales and Chuck Norris?"

"Supporters of Chuck Norris emphasise building a vocabulary of defining qualities and degrees of excellence, for the use of supporters and of the general public. Proponents of Jimbo Wales make no such assumptions, instead preferring to connect disparate knowledge bases together and allowing the whole to self-select for desirable traits."

"Okay, I think we've gone backwards."

(Seriously, have you read the "Differences from object-oriented programming" section of this article?)

Now, having read and thought about this further, I think I see what some important concepts are; I can't draw a clear line yet, but maybe that's impossible. Anyway, here's what I've got:

• A software component is a set of functions (and data?) that can be used by other software through standard, language-agnostic interfaces. The component might be running in a different process or even on the other side of a network connection.
• A component model is a standard for how interfaces for components should be designed, made available, and used. It might be implemented in multiple languages, but a component that obeys the model will work with systems designed for that model, regardless of language.

Explaining "software components" and "component models" separately is, I think, key to understanding the whole thing. The fact is that "software components" really aren't distinct from other concepts that value software modularity. Any good library that has multiple language bindings could be called a component. So could any standalone program following the Unix philosophy and working well with pipes, or any Internet server that's intended for programs, not humans, to connect to (which I hope is a buzzword-free definition of "Web services"). "Component models" formalise this, defining a common protocol for call and response that can be shared by multiple libraries, or programs, or servers, or even a homogeneous mix of them.

So "component-based software engineering" could actually mean two things, a general and a specific meaning. The general one is "designing software to be modular and reusable to as wide a range of other software as possible", which, yes, overlaps with things like object orientation and shared libraries, and is really not distinct from them. The specific one is "designing software according to a component model in order to accomplish these goals."

Vet that for accuracy, work in lots of concrete examples, and brush it up to encyclopaedic language, and I think we've got an article. -- Perey (talk) 07:07, 16 December 2010 (UTC)

It is the latter. Rp (talk) 11:42, 4 November 2014 (UTC)

The section contrasting OO with CBSE needs to be fleshed out. Its description of OO is naive. Rp (talk) 11:51, 4 November 2014 (UTC)

Wishing to add section on component-based IoT platform MASH

I demonstrated the MASH IoT platform at the 2013 IEEE IoT conference. MASH is component/metamodel based and includes an IDE, Android client and runtime. Metamodel is called SPEARS and supports states, properties, events, actions, rules and services. IDE build sequence is import, create, configure, wire, handle events and then compile/package/deploy. Just a heads up, will follow existing conventions. If I don't hear back in a few days will make the edit. FYI have been in software dev't for 30+ years.

Changes made. --Mikedeanklein (talk) 21:57, 18 January 2014 (UTC)

SDK?

Should a link to Software Development Kits be added to the See Also section or have some kind of mention? Would you consider SDKs to be a type of software component or something utilized to accomplish Component-based software engineering? Gregtheross (talk) 20:51, 16 June 2011 (UTC)

VCL is now from Embarcadero, not Borland

Also, CLX is no longer supported, but there's a new framework called Firemonkey instead. — Preceding unsigned comment added by 200.206.38.2 (talk) 13:35, 22 June 2012 (UTC)

Elaborate on Architecture

The Architecture section is quite thin, and I think expanding on this could clear up a lot of the confusion surrounding the difference between components and other types of objects/modules. A key concept that I see is missing is explaining how all these components fit together in a system. It is explained that each component needs an interface, but if every component is free to define its own unique interface, you don't have a useful architecture. A practical architecture requires that the components be used in the context of a system that allows the components to discover and communicate with each other, which requires that the components all observe a shared protocol for this. For example with CORBA these mechanisms are well-defined. — Preceding unsigned comment added by 67.139.67.178 (talk) 18:52, 5 February 2015 (UTC)

protobufs

should google protocol buffers be on this page? thx and smooches 220.253.249.191 (talk) 07:25, 28 January 2024 (UTC)