Software Reuse SEII - Lecture 28

Software ReuseSEII-Lecture 28Dr. Muzafar KhanAssistant ProfessorDepartment of Computer ScienceCIIT, Islamabad.RecapRestructuringCode restructuring, data restructuringForward engineeringClient-server architectures, object-oriented architecturesEconomics of reengineeringCost benefit analysisSoftware reuseBenefits of reuse2Problems with ReuseIncreased maintenance costsIf source code is not available of reused componentIncapability with system changesLack of tool supportNo support for development with reuse componentDifficult/impossible to integrate such toolsParticularly true for embedded system engineeringNot-invented-here syndromeSome rewrites component to improve itTrust in themselves3Problems with ReuseCreating, maintaining, and using a component libraryPopulating a reusable component library can be expensiveUse of the library can be expensiveFinding, understanding, and adapting reusable componentsSome components need to be discoveredUnderstanding and adaptionDevelopers must be confident4The Reuse LandscapeMany techniques for software reuse in last 20 yearsSystems in same domain may be reusedDifferent levels of reuseArchitectural patternsStandard software architecturesDesign patternsGeneric abstractionsComponent-based developmentIntegration of componentsComponent-model standards5The Reuse LandscapeApplication frameworksCollection of abstract and concrete classesLegacy system wrappingWrapped by new user interfacesService-oriented systemsLinking by shared servicesSoftware product linesGeneralized architecture to be customized for different customersCOTS product reuseConfiguring and integrating existing application systems6The Reuse LandscapeERP systemsLarge scale systems with generic business functionality and rulesConfigurable vertical applicationsGeneric systems are designedConfigured for specific needsProgram librariesClass and function librariesModel-driven engineeringSoftware as domain modelsProgram generatorsDomain specific systemsAspect-oriented software developmentShared components are woven at different places7Key Factors for ReuseDevelopment scheduleOff-the-shelf systems rather than componentsExpected software lifetimeLong-lifetime systems, maintenance effortBackground, skills, and experience of development teamReuse technologies are fairly complexCriticality of software and its non-functional requirementsDependability case for the systemApplication domainSystem platform8Application FrameworksObject-oriented paradigm for reuseObjects are too smallReimplementation is preferredA generic structureClasses, objects, and componentsCollaboration to provide a reuseSupport for generic featuresExample: user interface frameworkInterface event handlingSet of widgets to construct displaySpecific functionality may be added9Application FrameworksProgramming language-specificFramework can incorporate other frameworksThree classes of frameworksSystem infrastructure frameworksUser interfaces, communications, and compilersMiddleware integration frameworksSet of standards and associated objects classesSupport for communication and information exchangeExamples: Microsoft .NET and enterprise Java Beans (EJB)10Application FrameworksEnterprise application frameworksSpecific application domainsExamples: telecommunication and financial systemsSupport development of end user applicationsWeb application frameworksRecent type, very importantSupport for construction of dynamic websitesModel-View-Controller patternSecurity, dynamic web pages, database support, session management, user interaction11Software Product LinesOne of the most effective approachesSPL is a set of applications with a common architecture and shared componentsEach application specialized to reflect different requirementsThe core system is designed to be configuredApplication experience is often transferable from one system to other systemReduced development time12Software Product LinesSPLs emerge from existing applicationsChange tends to corrupt application structureConsequently, design of a generic product lineIdentification of common functionalitiesA base application is structured to simplify reuse and reconfigurationApplication frameworks and SPL have commonalities13Software Product LinesKey differencesApplication frameworks rely on object-oriented approach Application frameworks are focused on providing technical details rather than domain-specific supportSPL are often control applications for equipmentSPL are made up of a family of related applications, owned by the same organization14Software Product LinesVarious types of specializationPlatform specializationEnvironment specializationFunctional specializationProcess specializationArchitecture of SPL reflects general, application-specific architectural style or pattern15Example: Architecture of Resource Allocation System16Figure source: Software Engineering, I. Sommerville, 9th ed., p. 437Example: Product Line Architecture of Vehicle Dispatcher System17Figure source: Software Engineering, I. Sommerville, 9th ed., p. 437Steps to extend SPL to Create a New ApplicationElicit stakeholders requirementsSelect the existing system that is closest fit to the requirementsRenegotiate requirementsAdapt existing systemDeliver new family memberReconfigurationDesign-time reconfigurationDeployment-time reconfiguration18Steps to extend SPL to Create a New ApplicationDeployment-time reconfigurationComponent selectionWorkflow and rule definitionParameter definition19SummaryProblems with reuseIncreased maintenance costs; lack of tool support; not-invented-here syndrome; creating, maintaining, and using a component libraryThe reuse landscapeApplication frameworks, legacy system wrapping, service-oriented systems, software product lines, COTS product reuseKey factors for reuseDevelopment schedule, expected software lifetime, background, skills, and experience of development team, criticality of software and its non-functional requirements, application domain, system platformApplication frameworksSoftware Product lines20