COTS Definition. Rationale for Using COTS Products. Related Terms. Component-Based Software Engineering

Transcription

1 -Based Software Engineering ECE493-Topic 5 Winter 2007 Lecture 30 COTS-Based Applications (Part A) Ladan Tahvildari Assistant Professor Dept. of Elect. & Comp. Eng. University of Waterloo COTS Definition Commercial Off the Shelf Software Commercial Software Products sold, leased, licensed at advertised prices Source Code Unavailable generally an application program interface (API) Usually periodic releases with feature growth, obsolescence 2 Related Terms COTS: Commercial Off the Shelf Black Box: modifications to code internal to COTS product not allowed White Box: some modifications to code internal to COTS product permitted Rationale for Using COTS Products Significant change in s/w development practice over past 25 years USC e-services project data shows from 28% in 1997 to 70% in 2002 GFE: Government Furnished Equipment GOTS: Government Off the Shelf NDI: Non-Developmental Item/Not Developed Inhouse % CBA Growth Trend Year 3 4

2 COTS Advantages and Disadvantages When are COTS Products the Right Solution? Advantages Available now;earlier payback Avoids expensive development & maintenance Predictable license costs & performance Rich in functionality Broadly used, mature technology Frequent upgrades often anticipate organization s needs Dedicated support organization Hardware/software independence Tracks technology trends Disadvantages Licensing and intellectual property procurement delays Up front license fees Recurring maintenance fees Reliability often unknown/ inadequate; scale often difficult to change Unnecessary features compromise usability, performance No control over upgrades/maintenance Dependency on vendor Integration not always trivial; incompatibilities among vendors Synchronizing multiple-vendor upgrades When they lie at the intersection of the three determinants of feasibility, and do so demonstrably better than could original code: Technical ability to supply the desired functionality at the required level of reliability Economic ability to be incorporated and maintained in the new system within the available budget and schedule Strategic ability to meet needs of the system operating environment, including technical, political, and legal considerations 5 6 Case Study: When it Works Case Study: When it Works Hubble Space Telescope Control Center Software was redone This restructuring began in 1995 and it was the so-called Vision 2000 project to extend the life of the Hubble telescope VERY Data-Intensive They had a goal of not interrupting ongoing data-collection Goals: Use COTS to save money Extend life of HST until 2010 Mission-critical software High performance requirements High security requirements Final Product Integration of 30+ COTS/GOTS components with 1M lines of legacy code using.5m lines of glue code Results Replaced 3M lines of source code Proof of concept delivered in 3 months Live system delivered in 1 year Brand new architecture delivers greater functionality Very encouraging 7 8

3 CBSD: Perils Trustworthiness - how can a component with no available source code be trusted? Certification - who will certify the quality of components? Emergent Property Prediction - how can the emergent properties of component compositions be predicted? Requirements Trade-offs - how do we do trade-off analysis between the features of one component and another? COTS Activities COTS Assessment is the activity whereby COTS products are evaluated and selected as viable components for a user application COTS Tailoring is the activity whereby COTS software products are configured for use in a specific context COTS Glue Code development and integration is the activity whereby code is designed, developed, and used to ensure that COTS products satisfactorily interoperate in support of the user application 9 10 COTS Assessment COTS Assessment Process Divides up into three stages Trade Study: A quick and dirty filtering of a large number of components Hands-on Evaluation: A more thorough analysis of the remaining components Final Selection: Selection based on the results of previous stages 11 12

4 Trade Study s Requirements Matrix Break down your requirements These will form the basis for questions on a questionnaire Requirements should be of similar granularities Send questionnaire to vendors and current users Requirements Matrix s that receive less than half of the total points, don t move on When no COTS move on, this is the time to consider Reviewing your requirements Developing custom code 13 Weight requirements are based on a 0-10 scale where 10 is better Based on responses from questionnaires, give 0,.5, or 1 to each category 0 is not fulfilling requirement.5 is partial satisfaction 1 is total satisfaction 14 Hands-On Evaluation Hands-On Evaluation You must actually have access to the components Necessary if component represents a significant investment Use components as the basis for tests Scenario-Based Tests Examining Specific Criteria 15 16

5 Criticism of this Technique This technique is primarily requirements-driven Tends to select best-in-breed components Should be tailored to reflect internal requirements Assumes clean division of requirements Full assessment not always cost effective Selection: Revised The previous technique selecting components was fundamentally requirements-based Now you will see a technique for selecting components that is architecture-based Goal: Avoid the problems encountered in Mismatch Low level interoperability Program languages Platform dependencies Data base schemas Different trade-offs in non-functional terms When using COTS, you accept their architectural restrictions selection and architecture definition are intertwined Here we ll use a simple case study to exemplify the points Case study come from Mancebo2005 Has four steps iterative process Here we will select components for a multimedia presentation application Think PowerPoint 3D 19 20

6 Possible architectures are modeled as a decisions space Examples: 1. Should graphics object know how to render themselves (KAD 1a ), or should they be decoupled from rendering (KAD 1b )? 2. Should objects keep track of time individually (KAD 2a ), or should their be master synchronization object (KAD 2b )? 3. Should presentations be stored in ML format (KAD 3a ) or as serialized objects (KAD 3b )? Perform analysis of available components Create matrices reflecting the assumptions a capabilities of components Requirements Fulfillment Dependency Assumptions Requirements Fulfillment Matrix Dependency Matrix Ogre Direct OpenGL OpenAL OGLFT QT Graphics API MFC OpenGL Graphics API Ogre Audio Direct 3d Text OGLFT GUI Widgets The axis is the potential components would be considered using The Y axis lists user s requirements An represents that that particular component fulfils a particular requirement 23 GLTT The Y axis is the potential components The axis is things on which those components depend. An represents that that particular component fulfils a particular dependency 24

7 Assumptions Matrix KAD 1 KAD 3 KAD 2 Ogre 1a Direct To determine the feasible selections Enumerate the architectural approaches Of the form: AA = KAD 1 xkad 2 LKAD n Example: AA = 1 ex KAD a Should graphics object know how to render themselves (KAD1a), or should they be decoupled from rendering (KAD1b)? Should objects keep track of time individually (KAD2a), or should their be master synchronization object (KAD2b)? Should presentations be stored in ML format (KAD3a) or as serialized objects (KAD3b)? NOTE: Only one is constrained by one component. So we can eliminate decisions 2 and 3 from our matrix. This is a good thing. Usually what will happen is that in examining potential components on the market, we will find new architectural decisions that we must choose between. This is why this process must be iterated. Ogre assumes decision 1a that graphics objects must know how to render themselves. 25 Enumerate implementation approaches Of the form: IA = ( AA, C) Example: IA ex = ( AA,{ Direct, Ogre, Qt}) ex 26 IA ex = ( AA,{ Direct, Ogre, MFC}) ex After all of these, several feasible permutations will come up. Under the constraints of these set of components: Covers all rows in the requirements matrix Satisfies all component dependencies Is consistent with These permutations are evaluated on the basis of Architecture and together. Example: Portability is a high priority so you lean towards implementations that don t require Direct or MFC