Component-Based Software Engineering SEII - Lecture 31

Component-Based Software EngineeringSEII-Lecture 31Dr. Muzafar KhanAssistant ProfessorDepartment of Computer ScienceCIIT, Islamabad.RecapComponent-based software engineeringEssentials of CBSEIndependent components, component standards, middleware, development processCharacteristics of componentsStandardized, independent, composable, deployable, documentedElements of component modelInterfaces, usage, deploymentCBSE processesDevelopment for reuse, development with reuseComponent acquisition, management, and certification2CBSE for Reuse [1/2]Process of developing reusable components and making them available for reuseThe vision of early supportersThriving component marketplaceSpecialist component providers and vendorsSoftware developers would buy components or pay for servicesThis vision is not realizedMost likely CBSE for reuse take place within an organizationInternally developed components also need modification to reuse3CBSE for Reuse [2/2]Efforts are required to change application-specific components to more generic oneNeed to decide whether a component is likely to be reused and cost comparison for itTo make the component reusableEither the component implements stable domain abstraction (business objects)Estimate the cost of changes to make it reusable4Possible Changes [1/2]Removing application-specific methodsChanging names to make them more generalAdding methods to provide more complete functional coverageMaking exception handling consistent for all methodsAdding a ‘configuration’ interface to allow the component to be adapted to different situations of useIntegrating required components to increase independence5Possible Changes [2/2]Problem of exception handling is difficultApplications have their exception handling requirementsComponent should define what exceptions can arise and publish these as a part of the interfaceExample: component for stack data management should detect and publish stack overflow and underflow exceptionsPublishing all exceptions lead to difficulty of understanding interfacesOperation of component may depend on local exception handling and changing it may have serious implications6Other Factors [1/2]Ways to estimate cost of making component reusable and the return on investmentBenefits are not simply productivity gainsQuality gainsTime-to-market gainsComponent reuse depends on its application domain and functionalityTrade-off between reusability and usability of a componentPotential source of components is existing legacy systemsObsolete software technologiesNo clearly defined ‘requires’ and ‘provides’ interfacesNeed to develop wrapper7Other Factors [2/2]Once developed and tested a reusable component, manage it for future reuseClassify it to be easily discoveredAvailability of the component in a repositoryMaintaining information about its useTrack of different versionsCarry out some form of component certificationApart from the testingExpensive process8Software Process [1/4]Successful reuse requires a tailored development processDifferences between CBSE with reuse and traditional development processUser requirements are outlined rather than in detailStakeholders are encouraged to be flexibleRigid requirements limit the use of componentsNeed a complete set of requirements (unlike incremental development)9Software Process [2/4]Requirements are refined and modified early in the processComponents availabilityUsers may change their minds for cheaper and quicker system deliveryComponent search and design refinement activityAfter system architecture designComponent model and implementation platformComponents interfacing conflictsDevelopment is a composition processIntegration of components10Software Process [3/4]Identifying candidate components or services is a unique activityComponent searchComponent selectionComponent validation11Software Process [4/4]12Figure source: Software Engineering, I. Sommerville, 9th ed., p. 465Component Composition [1/4]The process of integrating componentsSpecially written ‘glue code’Different ways to integrateSequential compositionCreation of new components by calling two existing components in sequenceComposition of the ‘provides’ interfacesComponent do not call each other‘Glue code’ is required to call components services in right order‘provides’ interface of the composition depends on the combined functionality of both components13Component Composition [2/4]Hierarchical compositionOne component calls directly the other componentThe ‘provides’ interface of called component must be compatible with the ‘requires’ interface of the calling componentNo need of additional code if interfaces matchIt is not used for web servicesAdditive compositionTwo or more components are put together to create a new componentInterfaces of new component is a combination of the corresponding interfaces in already used components Components are called separately through the external interface of the new componentBoth used components are not dependent and do not call each other14Component Composition [3/4]15Figure source: Software Engineering, I. Sommerville, 9th ed., p. 469Component Composition [4/4]Any/all composition forms may be used to create a system‘Glue code’ may be required to link the componentsWhen new components are created for composition, interfaces should be compatible with other components in the systemWhen components are developed independently for reuse, interface incompatibility issue may arise16Components Incompatibility [1/2]Three types of incompatibilityParameter incompatibilityNumber and types of parametersOperational incompatibilityOperation names are different in ‘requires’ and ‘provides’ interfacesOperational incompletenessThe ‘provides’ interface of a component is a subset of the ‘requires’ interface of another component or vice versaIt can be tackled by writing an adaptor17Components Incompatibility [2/2]Component documentation helps to decide whether or not interfaces are compatibleInterface definition includes operation name and parameter typesDocumentation helps to decide about the semantically compatibility18Example – Components Incompatibility19Figure source: Software Engineering, I. Sommerville, 9th ed., p. 471Trade-offsPotential conflicts between functional and nonfunctional requirements Decisions to makeWhat composition of components is most effective for delivering the functional requirements for the system?What composition of the components will make it easier to adapt the composite component when its requirements change?What will be the emergent properties of the composed system? These are properties such as performance and dependability. You can only assess these once the complete system is implemented.20Example – Trade-offs21Figure source: Software Engineering, I. Sommerville, 9th ed., p. 475SummaryCBSE for reusePossible Changes and other factorsSoftware ProcessComponent compositionSequential, hierarchical, and additive compositionComponents incompatibilityParameter and operational incompatibility, operational incompletenessTrade-offs22