Presentation Transcript

1. Component-Based Software EngineeringModule 1 Part 2Component Moldel Elements

   Dr. Eman M. Saleh Al-Maghary Email: e_saleh@asu.edu.jo – Ext. 1269 SE Department Faculty of Information Technology http://fit.asu.edu.jo – http://OpenCourse.asu.edu.jo
2. Component-Based Software Engineering 1302481 Prerequisite: 1302386 Text Books: “Software Engineering, Ian Sommerville, 9th Ed., 2012. “Building Reliable Component Based Software Systems, IvicaCrnkovic and Magnus Larsson, Artech House, 2002.
3. Lecture Contents Component as a service and Interfaces Components models
4. Chapter 17 Software reuse Component interfaces Provides interface Defines the services that are provided by the component to other components. Requires interface Defines the services that specifies what services must be made available for the component to execute as specified.
5. Component interfaces Note UML notation. Ball and sockets can fit together.
6. Component models A component model is a definition of standards for component implementation, documentation and deployment. Examples of component models implementations EJB model (Enterprise Java Beans) COM+ model (.NET model) Corba Component Model Web srvices Model
7. Component models The theoretical component model is a definition of standards for component implementation, documentation and deployment. Examples of component models implementation: EJB model (Enterprise Java Beans) COM+ model (.NET model) Corba Component Model
8. Sommerville, Chapter 17 Basic elements of a component model
9. Elements of a component model Interfaces The component model specifies how the interfaces should be defined and the elements, such as operation names, parameters and exceptions, which should be included in the interface definition. it defines the language that should be used to define interfaces Examples: WSDL (web services), CIL (.NET) Java language (EJB), OMG IDL (CORBA)
10. Interface definition examples E.g. IDL OLE interface ISimple : IDispatch { [id(1, helpstring("method StringLen")] HRESULT StringLen([in] BSTR str, [out,retval] long* length); };
11. Sommerville, Chapter 17 Basic elements of a component model
12. Elements of a component model Interfaces The component model specifies how the interfaces should be defined and the elements, such as operation names, parameters and exceptions, which should be included in the interface definition. it defines the language that should be used to define interfaces Examples: WSDL ( for web services), CIL (.for .NET), Java language (EJB), OMG IDL ( for CORBA)
13. Elements of a component model Usage: These are information that you need to use the component in a program
14. Naming The global marketplace requires uniquely identifiable components and interfaces. Name clashes have to be avoided (when two different components are assigned the same name) Thus a standardized naming schema is a necessary part of a component model.
15. Naming Schemas Unique IDs:-Unique identifiers are generated by dedicated tools An example of unique IDs are Global Unique IDs (GUIDs), which are used by Microsoft's COM/DCOM/COM+ family Unique URI : Services have Uniform resource Identifier -Hierarchical name spaces-Hierarchical namespaces are guaranteed to be unique if the top-level names are uniquely registered with a global naming authority. Most Java-based component models use hierarchical namespaces (although there is no global naming authority).
16. Sommerville, Chapter 17 Basic elements of a component model
17. Meta Data Meta data is information about the component itself. This information provides the basis for scripting and remote method invocation and is used by composition tools and reflective programs
18. Simplified Component Metadata example <component-metadata name="nested1” load-on-startup="false" "> <description>Sample Nested Do Nothing Component </description> <version-info> <major-version>1</major-version> </component-metadata>
19. More Detailed Component Metadata example <component-metadata name="test"> <description>Test Component</description> <property-list> <property name="testProperty" value="true" description="A simple property" access="readwrite"/> <property name="testDropdown" value="ab" description="A dropdown property" access="readwrite"> </property> <method-list> <method name="getDataObjects" return- description="Retrieve all embedded DBObjects"> <method-arg name="list" /> </method> </method-list>
20. Elements of a component model Deployment The component model includes a specification of how components should be packaged for deployment as independent, executable entities.
21. Middleware support Component models are the basis for middleware that provides support for executing components. Component model implementations provide: Platform services Support services To use services provided by a model, components are deployed in a container. This is a set of interfaces used to access the service implementations.
22. Middleware services defined in a component model
23. Middleware support Component models are the basis for middleware that provides support for executing components. Component model implementations provide: Platform services that allow components written according to the model to communicate; Support services that are application-independent services used by different components. To use services provided by a model, components are deployed in a container. This is a set of interfaces used to access the service implementations.
24. Previous Lectures What is CBSE, its Essentials and goals Component as a service and Interfaces Components models
25. This Lectures Relationship between different component parts and the component model CBSE Processes
26. Component Anatomy Component Other Component Application Interface (Horizontal Channel) Internals (Private Aspects) Middleware Platform Interface (Vertical Channel) Platform (Operating System, Communication Subsystem, and other Hardware Systems) : 28
27. Component Anatomy Component Other Component Application Interface (Horizontal Channel) Internals (Private Aspects) Middleware Platform Interface (Vertical Channel) Platform (Operating System, Communication Subsystem, and other Hardware Systems) : 29
28. Internals (Private Aspects) Internals (Private Aspects) : it represents internal information and structure of a component. It represents the actual functionality (code) of the components as showing by its interface.
29. Component Anatomy Component Other Component Application Interface (Horizontal Channel) Internals (Private Aspects) Middleware Platform Interface (Vertical Channel) Platform (Operating System, Communication Subsystem, and other Hardware Systems) : 31
30. Application Interface Application Interfaces. Direct interaction: Interfaces define the Direct interactions with other components in the same machine. Indirect Interaction: Interfaces define the indirect interactions with Middleware for remote components Such interfaces represent the import or export relationships with other components or the middleware with which the component interacts.
31. Component Anatomy Component Other Component Application Interface (Horizontal Channel) Internals (Private Aspects) Middleware Platform Interface (Vertical Channel) Platform (Operating System, Communication Subsystem, and other Hardware Systems) : 33
32. Platform Interfaces It defines the component interaction with the platform on which it executes. A platform may be characterized by the hardware (specific processor, memory, communication equipments, or other hardware), the operating system; including the runtime environment, access to peripherals, communication subsystems, and so forth. Component developers may generate different components, one for each platform, This type of interfaces is essential for special type of applications (embedded systems for example)
33. For example, assume that we are developing a CORBA object that sorts an array of integers and we are making the source code available as a reusable component. We can identify the model elements as follows: Internals: The sort mechanism is designed and coded in C++, this represents the private aspects of the components. Application Interfaces (Horizontal Channel): The application interface will be the Interface Definition Language IDL. interface specifying the functionality available (sorting) and its signature. The component can then be called through the middleware i.e the ORB. Platform Interfaces (Vertical Channel): To run this component on a Windows environment (for example), a subset of the platform interfaces could be specified by: Compile with : C++ compiler for windows Run on: Windows Platform
34. Component Anatomy Example CORBA C++ Sort Component Component Other Component C++ code IDL Interface Application Interface (Horizontal Channel) Internals (Private Aspects) Compile in C++ Runs On Windowa X.Y Processor –intel 64 bit ORB Middleware Platform Interface (Vertical Channel) Windows OS, Processor X,…. Platform (Operating System, Communication Subsystem, and other Hardware Systems)
35. Now assume that we want to develop the same component in Java. Internals: The sort mechanism is designed and coded in Java. Application Interfaces (Horizontal Channel): The application interface will still be an IDL interface. Platform Interfaces (Vertical Channel): The platform interfaces would include the Java Virtual Machine for that specific platform.
36. SC SC Model Implementation SC Application Interface (Horizontal Channel) Theoretical Model Internals (Private Aspects) CORBA SC Interface SC Naming Platform Interface (Vertical Channel) .NET MetaData . SC JavaBeans SC SC
37. Chapter 17 CBSE processes CBSE processes are software processes that support component-based software engineering. They take into account the possibilities of reuse and the different process activities involved in developing and using reusable components. Development for reuse This process is concerned with developing components or services that will be reused in other applications. It usually involves generalizing existing components. Development with reuse This process is the process of developing new applications using existing components and services.
38. CBSE processes
39. Supporting processes Component acquisition is the process of acquiring components for reuse or development into a reusable component. It may involve accessing locally- developed components or services or finding these components from an external source. Component management is concerned with managing a company’s reusable components, ensuring that they are properly catalogued, stored and made available for reuse. Component certification is the process of checking a component and certifying that it meets its specification.
40. CBSE for reuse CBSE for reuse focuses on component development. Components developed for a specific application usually have to be generalized to make them reusable. A component is most likely to be reusable if it associated with a stable domain abstraction (business object).
41. Chapter 17 Software reuse Component development for reuse Components for reuse may be specially constructed by generalising existing components. Component reusability Should reflect stable domain abstractions; Should hide state representation; Should be as independent as possible; Should publish exceptions through the component interface. There is a trade-off between reusability and usability The more general the interface, the greater the reusability but it is then more complex and hence less usable.
42. Chapter 17 Software reuse Changes for reusability Remove application-specific methods. Change names to make them general. Add methods to broaden coverage. Make exception handling consistent. Add a configuration interface for component adaptation. Integrate required components to reduce dependencies.
43. Exception handling Components should not handle exceptions themselves, because each application will have its own requirements for exception handling. Rather, the component should define what exceptions can arise and should publish these as part of the interface.
44. Exception handling In practice, however, there are two problems with this: Publishing all exceptions leads to bloated interfaces that are harder to understand. This may put off potential users of the component. The operation of the component may depend on local exception handling, and changing this may have serious implications for the functionality of the component.
45. Reusable components The development cost of reusable components may be higher than the cost of specific equivalents. This extra reusability enhancement cost should be an organization rather than a project cost. Generic components may be less space-efficient and may have longer execution times than their specific equivalents.
46. Reusable components There is a trade-off between reusability and usability The more general the interface, the greater the reusability but it is then more complex and hence less usable.
47. Component management Component management involves deciding how to classify the component so that it can be discovered, making the component available either in a repository or as a service, maintaining information about the use of the component and keeping track of different component versions. A company with a reuse program may carry out some form of component certification before the component is made available for reuse. Certification means that someone apart from the developer checks the quality of the component.
48. CBSE with reuse CBSE with reuse process has to find and integrate reusable components. When reusing components, it is essential to make trade-offs between ideal requirements and the services actually provided by available components. This involves: Developing outline requirements; Searching for components then modifying requirements according to available functionality. Searching again to find if there are better components that meet the revised requirements. Composing components to create the system.
49. Sommerville,Chapter 17 CBSE with reuse
50. Chapter 17 Software reuse Thecomponent identification process
51. Chapter 17 Software reuse Component identification issues Trust. You need to be able to trust the supplier of a component. At best, an untrusted component may not operate as advertised; at worst, it can breach your security. Requirements. Different groups of components will satisfy different requirements. Validation. The component specification may not be detailed enough to allow comprehensive tests to be developed. Components may have unwanted functionality. How can you test this will not interfere with your application?
52. Component validation Component validation involves developing a set of test cases for a component (or, possibly, extending test cases supplied with that component) and developing a test harness to run component tests. The major problem with component validation is that the component specification may not be sufficiently detailed to allow you to develop a complete set of component tests. As well as testing that a component for reuse does what you require, you may also have to check that the component does not include any unsuitable code or functionality that you don’t need.
53. Ariane launcher failure – validation failure? In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the launcher went out of control 37 seconds after take off. The problem was due to a reused component from a previous version of the launcher (the Inertial Navigation System) that failed because assumptions made when that component was developed did not hold for Ariane 5. The functionality that failed in this component was not required in Ariane 5.