1 / 17

Component Based Software Engineering

Component Based Software Engineering. Chris Sholar 11/4/2003 CS5667. Domain Engineering. Goal – “identify, construct, catalog and disseminate a set of software components that have applicability to existing and future software in a particular application domain.”

acorrea
Download Presentation

Component Based Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Component Based Software Engineering Chris Sholar 11/4/2003 CS5667

  2. Domain Engineering • Goal – “identify, construct, catalog and disseminate a set of software components that have applicability to existing and future software in a particular application domain.” • Additional – “establish mechanisms that enable software engineers to share these components – to reuse them – during work on existing and new systems.”

  3. Domain Engineering • Three major activities • Analysis • Construction • Dissemination: to scatter abroad, to spread widely.

  4. The Analysis Process • Five Steps • Define the domain to be investigated • Categorize items extracted • Collect a representative sample of applications in the domain • Analyze each sample • Develop an analysis model for the objects

  5. The book claims that domain analysis can be applied to any software engineering methodology and may be applied to conventional and object oriented development. • This is similar to noun extraction for identifying objects and creation of models for representation of the system.

  6. Point Two Expanded • Eight extra steps added… • Select specific functions • Abstract functions • Define taxonomy or classification system • Identify common features • Identify specific relationships • Abstract the relationships • Derive a functional model • Define a domain language

  7. Does this really help? • These steps provide a useful model for domain analysis, but do they help with deciding which components are appropriate for reuse?

  8. Sample questions to ask • How common is the component’s function within the domain? • Is the component hardware dependent? • Does the hardware remain unchanged between implementations? • Is the design optimized enough for the next iteration? • Is reuse through modification feasible? • Can a nonreusable component be decomposed to produce reusable components?

  9. Further Help • Characterization process • Define some generic characterizations for the component. • e.g. • Importance of safety/reliability • Programming language • Concurrency in processing • These characteristics are shared by all software within a domain. • Establish a relevancy scale for the characteristics

  10. Structural Modeling • Includes Structure Points • Basis for component selection and categorization • Software can be characterized by structural models, so components can be categorized by structure points, architectural patterns. • Aircraft avionics has a structural model of architectural style.

  11. Component Based Development • Occurs in parallel with domain engineering • Software team refines an architectural style that is appropriate for analysis model. • The architecture for the system is composed of components that are available from reuse libraries, or engineered to meet the custom needs.

  12. Three Phases • Component Qualification • Ensures that a candidate component will perform the function required, and has the quality characteristics required. • Factors considered • API • Development and integration tools required • Runtime requirements • Security features • And others

  13. Component Adaptation • Ideally domain engineering produces libraries of components that are easily integrated. • Implications • Consistent resource management • Data management exists for all components • Interfaces within architecture and with external environment are consistent

  14. To remove some of the conflicts the previous implications produce, component wrapping is used. • When source code is available, often not with COTS, white box wrapping is used. • Code-level changes to fix conflicts • When the component library provides component extension languages or APIs that allow the conflicts to be masked or removed, this is called gray box wrapping. • Black box wrapping requires the use of pre- and post-processing at the component interface.

  15. Component Composition • Assembles qualified, adapted, and engineered components to fill the architecture with the needed functionality. • Four architectural ingredients needed to create a coherent software package from components: • Data exchange model • Automation • Structured storage • Underlying object model

  16. Data exchange model • Enables users and applications to interact and transfer data • Automation • Tools, macros, scripts implemented to provide for interaction between components • Structured storage • Heterogeneous data should be organized and accessed as a single data structure • Underlying object model • Ensures that components of different programming languages and built on different platforms can be interoperable.

  17. Summary • Domain engineering and component based development occur simultaneously in the CBSE process. • Domain engineering creates software components for reuse • Component based development refines the components chosen for the system. • Economics…

More Related