In this post, I described the component-based software development paradigm and discussed its advantages in relation to the large scale software development. The presented paradigm, in contrast with building from scratch approach, allows to reduce both complexity of the software and cost of development while increasing the developers’ productivity and software’s quality. Contents • • • • • • • • • • • • • • • • • • Component Oriented Programming [ ] Software components is at the moment one of the most popular buzz words in the software engineering community. This chapter surveys component technology, its reuse concepts and characteristics. Then, we will give a short overview of software architecture and its relation to component based development. Finally, we will examine JavaBeans as an example of a component model. The Software Crisis [ ] In the year 1968 on a NATO conference in Garmisch Partenkirchen for the first time the 'software crisis' was mentioned. It was admitted that software development is difficult, even so difficult that it has to be considered as an own engineering discipline. Also, the hope aroused that a way out from the misery could be the formation of a new software component industry and component market. ![]() The state of software development was compared to that of many industries in the early 19th century: the products were hand-crafted, expensive, and error prone. A characteristic of maturing industries is that it fabricates products that are assembled of many small standardized and exchangeable parts. An example is electronic engineering, where small electronic components like diodes, resistors and transistors are not designed for a single application but for numerous and different ones. They can be composed on circuit boards to larger integrated circuits (IC). A single part can simply be replaced by others, provided that it offers the same functionality. Standards like the ISO, ANSI, or DIN guarantee that components are compatible and interchangeable. Characterization of Components [ ] Software development tries to imitate these reuse mechanisms. The idea is to develop software systems by assembling a set of independently developed components off-the-shelf (COTS) in a 'plug and play' manner. The notion of a 'software component' is already quite old, but in recent time it has changed considerably. While in the early days of programming, software components were mostly seen as source code modules like FORTRAN libraries, one has nowadays more requirements to components. Install sogo on centos 6 download. There is no common definition of what a software component actually is. The problems are that the point of view depends much on the background of the author, and that there was in the last years so much discussion about components, that the notion of a component became somewhat fuzzy and ambiguous. Yet, there are a couple of generic properties, one usually associates with software components. A good starting point is a definition made at the ECOOP 96 conference: 'A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.' ![]() Clemens Szyperski, Component Software, ACM Press/Addison-Wesley, England, (1998). Next, we will describe the unfamiliar terms occurring in the definition in more detail. Component Features [ ] Information Hiding [ ] Probably the most important characteristic is that components completely hide their implementation. The importance was stressed already very early by Parnas' information hiding principle: 'Every module hides an important design decision as well as its implementation behind a well-defined interface which does not change when the design decision or the implementation changes' Components are like black boxes: The programmer knows, how the outside looks like, and what the component can provide, but he does not know how it works internally. ![]() ![]() At a first glance, this total encapsulation might seem like a limitation, but we will see that it actually is a help. The application builder profits insofar as he can replace the component by another one, if it supports the same interface and functionality. In addition, he needs not understand the inner working, but only the interface of the component. The component provider, on the other hand, can change the implementation of the component as long as the interface is still satisfied. The interface is a quite important term in CBSD. It is defined by 'a named collection of methods representing one functionality'. An interface serves as a kind of contract between component provider and component user. It should not only mention the services of a component but also its dependencies to its environment. The absence of source code imposes some difficulties that need to be solved. First, it must still be possible to adjust a component to the individual requirements of a user. Adaptation without knowledge about the components implementation is called customization. Further, components must offer a mechanism to get information about the their specification. This self-descriptiveness is achieved by introspection. Context Independence [ ] Components are easily transferable into different application contexts. As a consequence, components need to be self-contained software elements, independent from any other components. The independence is so strict that even implementation inheritance is forbidden, because it makes a component dependent from its superclass, and changing the superclass can break the component. Interface inheritance, which is a mere subsumption of feature specifications, is allowed. Implicit Invocation. [ ] So that components are exchangeable, components may ideally not address one another directly, but through an indirection mechanism. A central registry stores all information about the components and interfaces.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |