component-based software architecture Overview Divides the problem into sub-problems each associated with component partitions. The interfaces of the components play important roles in the component-based design. The main motivation behind component-based design is component reusability; a component encapsulates functionality and behaviours of a software element into a reusable and self- deployable binary unit.

Objectives  Introduce concepts of the software components  Discuss UML notations for component- based architectures  Introduce principles of component-based design  Introduce quality attributes of component- based design

Designs can make use of existing reusable components commercial off the shelf (COTS) or in house-developed, and they may produce reusable components for future reuse. This increases overall system reliability since the reliability of each individual component enhances the reliability of the whole system via reuse.

There are many standard component frameworks such as COM/DCOM, JavaBean, EJB, CORBA,.NET, Web services, and Grid services. These target component technologies are widely adopted in local desktop GUI application design such as graphic JavabBean components, MS ActiveX components, and COM components which you can reuse them by simply drag and drop.

Many components are invisible, especially those distributed in enterprise business applications and Internet Web applications such as Enterprise JavaBean (EJB),.NET components, and CORBA components. The combination of service-oriented and component technologies is getting more attention today; these include of course Web and Grid services.

A component is a deployable software package that can provide services to its clients; it may also itself require services from other components, and son on. A component should be self-contained and substitutable as long as its interface is unchanged.

A component-oriented design is at a higher level of abstraction than an equivalent object- oriented design; the former defines components and connections between them instead of classes and connections between classes. A component is a higher-level concept, usually incorporating more than one class. Thus, in component-oriented design we identify all components and their interfaces first instead of identifying classes and their relationships.

Component-oriented software architectural and design has many advantages over the traditional object-oriented counterpart: Reduced time in market and the development cost by reuse of existing components. Increased reliability with the reuse of the existing components.

What is a Component A component is a modular (i.e., cohesive), deployable (i.e., portable), replaceable (e.g., plug-and-play), and reusable set of well-defined functionality that encapsulates its implementation and exporting it as a higher-level interface. Szyperski defines that a software component is a unit of composition with a contractually specified interface and explicit context dependencies only.

That is, a software component can be deployed independently and is subject to composition by third parties. In the generic model in Figure 11.1, a component is represented by a box the inside of which is its implementation, the dark boxes on the boundary represent the exported interface elements, and the “ plugs ” sticking out represent required explicit context (usually plagued into another component ’ s interface).

To the right of the figure we shod how a (larger) component is implemented by interconnecting other components; this larger component can in turn be connected to other component etc. In this way, a “ system ” built out of a network of components is itself a component.

// Class CounterImpl1 is a possible implementation of interface Counter: import counter.*; class CouterImpl1 implements Counter { private int count; public void setCount(int c){ count = c;} public int getCount(){ return count;} public void inc() { count ++; } }

The interface exposes all the operations of the component while the class implements this interface. A client can use this component as follows: CounterImpl1 myCounter = new CounterImpl1(); myCounter.inc();

The first line can be replaced by using another implementation component ConterImpl2 without any change to the rest of code if both CounterImpl1 and ConterImpl2 implement the same interface Counter. CounterImpl2 myCounter = new CounterImpl2(); The interface separates the implementation of a component from its clients.

We can easily convert a Counter implementation class to a JavaBean by following the JavaBean convention, compile the source code for JavaBean, and generate file CounterImp1.class. We know a Java Bean is a deployed component of a java class just like the MS DLL components. We need to create a manifest file to specify this Java class as a bean. The manifest file becomes part of the Java component JAR file.

At this time we can use any bean development tools such as Bean Builder or NetBean Visual Studio to load this bean into the tool library and reuse it. You can also place the deployed component in any directory as long as it is on the classpath.

The following screen shot shows the composition of a button component and a counter component, whereby counter is able to display the counts that the button has been pressed. This is a simple form of composition of two components. This composition can be implemented by many Java IDE tools listed above.

We can also build the Counter component using CORBA technology, and deploy it on any CORBA compatible server and access it by remote clients. A CORBA component can work together with other components. Here is a CORBA interface definition of the Counter component module Counter { interface Count { attribute long count; long inc(); }

This IDL interface definition can be mapped into a Java package and interface and implemented by Java classes or mapped to other language implementation so that clients can use this component. package counter; public interface CountOperations { int count(); void count(int newCount); int inc(); }

Principles of Component-Based Design The software system is decomposed into reusable, cohesive and encapsulated component units. Each component has its own interface that specifies the required ports and provided ports; each component hides its detailed implementation. In other words, each component can be seen as a black box building block grouping functionalities and data cohesively as a module (package)

Connectors connected components, specifying and ruling the interaction among components. Components interaction can take the form of method invocations, asynchronous invocations such as event listener and registrations, broadcasting, message driven interactions, data stream communications, and other protocol specific interactions. The interaction type is specified by the interfaces of the components.

Figure 11.4 shows a component-based software architecture. The manager component gets service support from a single component (requests) and a combined service component sub-system (Service 1 and Service n), and the latter gets data access service from a database. The whole software system is a set of components connected by their interfaces. Each component may be replaced or updated without any changes of the other part of the system.

Component-Level Design Guidelines We can map Use Case diagrams to the provided service interfaces of the first-cut component specification. The business concept diagram depicts the relationships of the business process entities in the domain, we can extract these business process entities that can exist independently without any associated dependency on other entities.

We can recognize and discover these independent entities as new components. The current component needs these provided services from these new discovered components. In this way, we can also map the business concept diagrams to the required service interfaces of the first-cut component specification.

A collaboration is any identifiable slice of functionality that describes a meaningful service, involving, in general, several concepts. A collaboration can be seen as the implementation of a use case! Thus, for each use case U there will be a collaboration diagram “ encapsulated ” in a component C (one or more sequence diagrams will be drawn to exercise the use case through scenarios). Figure 11.5 illustrates the component implementation of Use Case U (that happens to lay in between two other use cases).

Applicable domain of component-based architecture: Suitable for applications where the interface contracts between sub-systems are clear. Suitable for applications that require loose coupling between the components and many reusable components are available Suitable for the class library system organization..NET class library and Java API themselves are built in component architecture.

Benefits: Reusability of components: System maintenance and evolution: easy to change and update the implementation without affecting the rest of the system. Independency and flexible connectivity of components Independent development of components by different group in parallel Productivity for the software development and future software development Many OO design tools can also be used for Component-Based Software Development.

Limitations: Sometime it is difficult to find suitable available components to reuse. Adaptation of components is always an issue. Not many component-oriented dedicated design tools are available.