Component Based Architecture

1. Component Based Architecture

2. Objectives • Introduce notions of Software Component • Discuss Pros and Cons

3. Introduction • Component-based Architecture used to • Divide a problem into sub-problems • Each sub-problem is associated with a component • Interface plays an important role • Motivation • Components are highly reusable • A component encapsulates the functionality and behaviors of a software element into a reusable and self-deployable binary. • Use of COTS or developed in-house components • Increases overall reliability • Can greatly reduce development cost

4. Components • Important points • A component is a deployable software package that can provide services to its client • It may require services from other components • It remains self-contained and substitutable as long as it interface is unchanged.

5. Components Vs. OO design • A component-oriented represents a higher level of abstraction than an equivalent OO design • The component-oriented design defines components and connections between them instead of classes and connections between classes • In component-oriented design • First identify all components and their interfaces • Advantages over OO design • Reduced time in market • Lower development costs by reuse of the existing components, and • increased reliability with reuse of the existing components

6. Component Examples • Many standard component frameworks • COM/DCOM • JavaBean • EJB • CORBA • .Net • Web Services • Grid Services

7. What is Component • A component is a modular (cohesive), deployable (portable), replaceable (plug-and –play), and reusable set of well-defined functionalities that encapsulates its implementation and exports it as a higher-level interface. • It is called as provided port • Services the component provides • Supported Interface • It is called as required port • Services the component requires • Supported Interface Ports may be connected synchronously or asynchronously or via I/O streams

8. Example • A UML component can be mapped to any target technology component • Examples: • EBJ Component (.jar file) • Java Web Component (.war file) • What about MS .Net Component? • .dll file

9. Why use components? • Reusability • Productivity • Composability • Adaptibility • Scalability • Reliability and many others

10. Component Implementation • Usually consists of a set of class files • Abstract Interface • Concrete Implementation Classes • Note: • Some IDE tools support visualization of components, e.g., VS Studio .Net Toolset • However, it does not mean that each component should have such a visual representation

11. Java Example: Java Counter package counter; interface Counter { public void setCount(int c); public intgetCount(); public void inc(); }

12. Java Example: Implementation File import counter.*; class CouterImpl implements Counter { private int count; public void setCount(int c){ count = c;} public intgetCount(){ return count;} public void inc() { count ++; } }

13. Why Interface & Implementation? • Separation of Interface and Implementation allows changeability! • Example 1: CounterImpl1 myCounter = new CounterImpl1(); myCounter.inc(); • Example 2: CounterImpl2 myCounter = new CounterImpl2();

14. Principles of Component-Based Architecture • Figure out semantics of connections • Communication semantics important • Local: relatively easy • Remote: pay attention! many different call semantics • Think about INTERFACE, not the implementation

15. Component Level Design • Before the design phase, we have • Use case modeling • Business concept modeling • Use case diagrams • Describes user interactions with the system which indicate all necessary operations of the component • We can map use case diagram to the provided service interfaces of the first-cut component specification

16. Component Level Design • A collaboration diagram • is an identifiable slice of functionality that describes a meaningful service involving several concepts. • A collaboration diagram the implementation of a use case • For each use case U, there will be a collaboration diagram “encapsulated” in a component C.

17. Component Level Design • Use case component implementation

18. Component Level Design • Business concept diagram • Depicts the relationships of the business process entities in the domain • Extract business process entities that can exist independently without any associated dependency on other entities. • Recognize and discover these independent entities as new components.

19. Component Level Design • Starts from Use Case Diagram • May also need business concept diagram • Mapping • Use case  interface provider • conceptual classes  modules of components • If necessary, big components can be further decomposed

20. Example: Doctor Appt. System • A clinic has dozen family doctors • Each doctor has a schedule with slots of 15 minutes • patients can make appointment • patients can change and cancel appointment • New patients are welcome • doctor can mark off slots • patients and doctors can display schedules on computer at any time

21. Use Case Diagram

22. Business Concepts Diagram Domain entities and business concept

23. Identification of Components and Types Assume no class diagram available Derived, so cannot exist independently Doctor and patients can exist alone without any dependency A schedule belongs to doctor and is derived from appointments The UML notation for interface or core type is << >> The core type can exist independently Daily appointments are derived from doctor-patient schedule Each core type has management interface

24. Component Design

25. Summary - CBA • Applicable domain • Suitable for where the interface contracts between sub-systems are clear. • Suitable for 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

26. Summary - CBA • Benefits: • Reusability of components: • System maintenance and evolution: • Independency and flexible connectivity of components • Productivity • Many OO design tools available • Limitations: • Sometime it is difficult to find suitable components to reuse. • Adaptation of components is always an issue.