ECE750-Topic11: Component-Based Software Systems

Transcription

1 ECE750-Topic11: Component-Based Software Systems Component-Based Development Process Ladan Tahvildari, PEng Associate Professor Software Technologies Applied Research (STAR) Group Dept. of Elect. & Comp. Eng. University of Waterloo

2 Software Development Process Typical Phases Requirements analysis and specifications System and architecture design Implementation and unit testing System integration Verification and validation Operation and maintenance/evolution Two general models Sequential: Top-down and bottom-up Evolutionary: Iterative, incremental, agile, RUP ECE750-Topic 11 2

3 The Sequential/Waterfall Model Analysis Development Design Implementation Integration Test ECE750-Topic 11 3

4 The Evolutionary Development Develop a system gradually in many repetitive stages: Increasing the knowledge of the system requirements and system functionality in each stage exposing the results to user comments This can be achieved by using: The Iterative Model The Incremental Model The Prototyping Model The Rational Unified Process (RUP) Model Agile Model ECE750-Topic 11 4

5 The Iterative Model Analysis Development Design Implementation Integration Test ECE750-Topic 11 5

6 The Incremental Model Increment n Analysis Development Design Implementation Integration Test ECE750-Topic 11 6

7 The Prototyping Model Test prototype Analysis Development Design Implementation Develop prototype Integration Test ECE750-Topic 11 7

8 The Rational Unified Process A modern process model derived from the work on the UML and associated process. Normally described from 3 perspectives A dynamic perspective that shows phases over time A static perspective that shows process activities A proactive perspective that suggests good practice ECE750-Topic 11 8

9 RUP Phase Model Inception: Establish the business case for the system Elaboration: Develop an understanding of the problem domain and the system architecture Construction: System design, programming and testing Transition: Deploy the system in its operating environment ECE750-Topic 11 9

10 Unified Process Illustrated Phases Inception Elaboration Construction Transition Requirements Analysis An iteration in the elaboration phase Design Implementation Test Iter #1 Iter # Iter #n Iterations ECE750-Topic 11 10

11 Reusability The main tenet of CBSE What to reuse Requirements specifications and analysis Design: generic or domain-specific design spec, design patterns, and architectural styles Implementations: open/closed source component Test data Two general types of reuse Vertical Reuse reusing domain-specific assets (e.g., visualization components) Horizontal Reuse reusing generic assets, mostly as extensions of programming languages (e.g., C++ STL) ECE750-Topic 11 11

12 Design with and for Reuse How to reuse Design for reuse, often called Domain Engineering Design with reuse, often called Application Engineering Different assets from domain can be reused Domain Model Domain Design Implemented Components ECE750-Topic 11 12

13 Component-Based Development (CBD) In CBD, the two phases of design for and with reuse, is normally called: Component Development producing reusable components Some concerns Business goals Licensing Maintenance and support policy Open-closed source (also called white-box and black-box reuse) System Development consuming components to compose and integrate systems Based on end-user and stakeholders requirements Some concerns Change propagation for provided and required interfaces How do the available components fit into the requirements specifications ECE750-Topic 11 13

14 System Development Design with Reuse Our goal if to have a development process Based on successful conventional processes Customized for component-based development Some new steps are added Finding the candidates Evaluating and selecting the most suitable candidates Adapting and composing components ECE750-Topic 11 14

15 System Development Process Find Analysis Select Design Development Evaluation Adapt Integrate Implementation Integration Test Test Component evaluation System Development Matching component evaluation with system development ECE750-Topic 11 15

16 Simplified Process (I) Define the requirements Design the system Find & Select Adapt Compose/ Integrate Test & Deploy Operation & Maintenance ECE750-Topic 11 16

17 Simplified Process (II) Define the requirements Capture system requirements from stakeholders Specify functional and non-functional requirements Design the system High-level architecture Specify main subsystems and components Find and select the candidates Collect information about appropriate components Code repositories likes sourceforge, Google, Apache, IBM developerworks, ECE750-Topic 11 17

18 Simplified Process (III) Find and select the candidates (cont d) Evaluation and selection based on the following criteria: Trust: dependability and security factors It can be handled with software certifications (e.g., similar to the warning messages given by Microsoft Windows when installing an uncertified application) Requirements: How does a candidate meet the requirement spec? Integration Effort: How hard is it to integrate the component with other components? Do we need glue code? Support: Are your issues going to be fixed? Can you ask for help? Pay for help? Alternatives: What happens if you cannot use the selected component? Is there any other alternative? Verification: Can you test the component? ECE750-Topic 11 18

19 Simplified Process (IV) Adapt Configuring for the current system Providing configuration file or rebuilding Providing the adaptation code Adjusting provided and required interfaces With wrapper or adaptor Could be different for white-box and black-box reuse Compose and Integrate Emergent properties Composition of components may show unpredicted properties Example: deadlock (an example will be discussed later) Different types of composition ECE750-Topic 11 19

20 Basic Types of Composition Sequential Composition where the composed components are executed in sequence. This involves composing the provided interfaces of each component. Hierarchical Composition where one component calls on the services of another. The provided interface of one component is composed with the required interface of another. Additive Composition where the interfaces of two components are put together to create a new component. ECE750-Topic 11 20

21 Basic Types of Composition ECE750-Topic 11 21

22 Interface Incompatibility Parameter Incompatibility where operations have the same name but are of different types Operation Incompatibility where the names of operations in the composed interfaces are different Operation Incompleteness where the provided interface of one component is a subset of the required interface of another ECE750-Topic 11 22

23 Incompatible Components phonedatabase (string command) addressfinder string location(string pn) string owner (string pn) string property Type (string pn) mapdb (string command) mapper displaymap (string postcode, scale) printmap (string postcode, scale) ECE750-Topic 11 23

24 Adaptor Components Address the problem of component incompatibility by reconciling the interfaces of the components that are composed Different types of adaptor are required depending on the type of composition An addressfinder and a mapper component may be composed through an adaptor that strips the postal code from an address and passes this to the mapper component ECE750-Topic 11 24

25 Composition through an Adaptor The component postcodestripper is the adaptor that facilitates the sequential composition of addressfinder and mapper component address = addressfinder.location (phonenumber) ; postcode = postcodestripper.getpostcode (address) ; mapper.displaymap(postcode, 10000) ECE750-Topic 11 25

26 Simplified Process (I) Define the requirements Design the system Find & Select Adapt Compose/ Integrate Test & Deploy Operation & Maintenance ECE750-Topic 11 26

27 Simplified Process (V) Test and deploy Unit testing and integration testing May discover that your selected components do not fit together Operation and Maintenance/Evolution Operation management Reconfiguring and resource management Maintenance/Evolution Upgrading, patching or replacing components Disposal of components normally missed in the development process ECE750-Topic 11 27

28 Component Disposal Generally takes place due to two different factors: Dissatisfaction initiated by consumers when they conclude that: The component no longer provides the support of the system it was intended to provide or The system no longer needs the component Obsolescence is likely to occur when: A new, more effective component with the same, similar or extended functionality is found Poor portability to new platforms/operating systems The producer is not able to continue with support or maintenance The component needs obsolete components ECE750-Topic 11 28

29 A More Realistic Process Based on V process ECE750-Topic 11 29

30 A More Realistic Process Operation & Maintenance may include Adding new components Replacing components The find/select, adapt, and test will be repeated ECE750-Topic 11 30

31 Composition and Integration In theory We connect required and provided interfaces Integration is mostly based on interfaces and description of operations Component models help integration Business interfaces in EJB In practice It is not as simple as expected More details and contracts need to be known ECE750-Topic 11 31

32 Composition/Integration: 1 st Example Example adopted from: D. Garlan, R. Allen and J. Ockerbloom. Architectural Mismatch: Why Reuse is So Hard, IEEE Software, 12(6):17-26, November The system: AESOP Generates development environments tailored to development of systems in particular architectural styles Constituent components Object-oriented database (OBST) GUI toolkit (Interview) Event-based tool integrations (HP SoftBench) RPC mechanism (MACH RPC Interface Integration - MIG) All of the components are implemented using C and C++ Source code were available ECE750-Topic 11 32

33 AESOP Environment ECE750-Topic 11 33

34 Problems Effort Estimate: six months (one person-year) Reality: two years (five person-year) Excessive code Poor performance Overhead of connecting tools and database Need to modify external packages Modifying client-loop event in SoftBench Reinventing existing functions Hierarchical nested view management in Interview, because it didn t allow direct access to nested view ECE750-Topic 11 34

35 Underlying Issues Nature of components Assumption about Infrastructure e.g., all tools have GUI Control model e.g., Where is the main thread of control? Where is the main loop? Data model e.g., the assumptions about the nature of data each component manipulating Nature of connectors Assumption about Interactions e.g., request/reply protocol or event notification Data model e.g., the format of data which us transferred between components ECE750-Topic 11 35

36 Underlying Issues (cont d) Global architecture For example, in this case OO DB component assumes that there us no interaction between components It blocks all tools when one is working with data For solving this problem, the team added another transaction manager Error-prone construction/composition process Dependencies in generated codes by different tools As they built the system, modifications became increasingly costly ECE750-Topic 11 36

37 Proposed Solutions for Composition Make assumptions explicit Having these assumptions leads to find the problem sooner Unfortunately, still there is no notation for documenting architectural assumptions How to say that a component has an event loop? Use orthogonal loosely-couple components in reusable assets Use bridging techniques to resolve interface mismatches Wrapper or adaptor Provide design and composition guidance Generic and domain-specific ECE750-Topic 11 37

38 Composition/Integration: 2 nd Example Example adopted from: P. Inverardi, A.L. Wolf, and D. Yankelevich, Static Checking of System Behaviors Using Derived Component Assumptions, ACM Transactions on Software Engineering, 9(3): , July The main point is that component users Not only need the specifications of component s interactions behavior But also, they need specifications if the assumptions that the component makes about the expected interactions behavoir of other components ECE750-Topic 11 38

39 Composition/Integration: 2 nd Example The authors use a guest analogy Assume H: Host, P: Host s Partner, Y: You At a party: H & Y: greet at door, invite in H & P: introduce Y to P P & Y: take to living room, offer a drink and introduce Y to others Suppose that by any reason H does not introduce you to P You feel uncomfortable with people you don t know It is insufficient only your interaction with environment, and need to also consider intra-environment interactions ECE750-Topic 11 39

40 Compressing Filter: 2 nd Example Now consider this example Adding data compression to a web server The main goal is to improve performance of www browsers over slow networks Assume the web server is the standard CERN HTTP server The web server has a pipe-and-filet architecture style ECE750-Topic 11 40

41 Compressing Filter: 2 nd Example We want to add an external filter to compress data using gzip The external compressing filter communicates with the web server through Unix pipes Read and write data A pseudo filter (adaptor) has been added to work with the external compressing filter ECE750-Topic 11 41

42 Compressing Filter: 2 nd Example Process Component Channel Function call interface UNIX pipe interface Compressing Filter gzip 2 3 Filter 1 Pseudo Filter (Adaptor) 4 Filter ECE750-Topic 11 42

43 Compressing Filter: 2 nd Example HTTP server filters are forced to read when data are pushed at them However, Unix filters choose when to read data So, gzip may block Normal case Adaptor passes the data from upstream filter to gzip, and when the stream us closed, read the data from gzip, and write it to downstream filter Problematic case (Emergent Property) Because gzip has a limited internal buffer, it may attempt to write a portion of compressed data before the adaptor is ready gzip blocks and then adaptor blocked Deadlock! ECE750-Topic 11 43

44 Compressing Filter: 2 nd Example In this example, the solution is not hard Adaptor can handle data incrementally and use unblocking reads and writes However, for composing more complex systems Component developers need to document these assumptions (not straightforward!!) In this article, the authors build models of component and its environment that enables static analysis of deadlock freedom. ECE750-Topic 11 44

45 Suggested Solutions for Component Composition Predictable Assembly for Certified Components (PACC) Component certifications Pre- and post-conditions Mathematical models for reliability Component credential (extra-functional properties) In this example, the solution is not hard Prediction-Enabled Component Technology (PECT) A component model plus the analysis model ECE750-Topic 11 45

46 Prediction-Enabled Component Technology (PECT) Based on two fundamental premises: Component Model PECT Analysis Model The system quality attributes are emergent properties that are associated with patterns of interaction among components not connected specializes influences Component Model interpretation assumptions Analysis Model The software component technology provides a means of enforcing predefined and designed interaction patterns, thus facilitating the achievement of system quality attributes by construction ECE750-Topic 11 46

47 COTS Definition Commercial Off the Shelf Software Commercial Software Products sold, leased, licensed at advertised prices Source Code Unavailable Only application program interface (API) Usually periodic releases with feature growth or obsolescence ECE750-Topic 11 47

48 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 GFE: Government Furnished Equipment GOTS: Government Off the Shelf NDI: Non-Developmental Item/Not Developed In-house ECE750-Topic 11 48

49 Using COTS in Software Projects A survey at USC (2002) 28% use in % in 2002 CBA Growth Trend % Year ECE750-Topic 11 49

50 COTS Advantages and Disadvantages 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 ECE750-Topic 11 50

51 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 ECE750-Topic 11 51

52 Case Study: When it Works 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 ECE750-Topic 11 52

53 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 ECE750-Topic 11 53

54 COTS Assessment 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 ECE750-Topic 11 54

55 COTS Assessment Process ECE750-Topic 11 55

56 Trade Study 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 Component Requirements Matrix Components 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 ECE750-Topic 11 56

57 Components Requirements Matrix 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 ECE750-Topic 11 57

58 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 ECE750-Topic 11 58

59 Hands-On Evaluation ECE750-Topic 11 59

60 Criticism of this Technique This technique is primarily requirementsdriven 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 ECE750-Topic 11 60

61 Component 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 Architectural Mismatch Low level interoperability Program languages Platform dependencies Data base schemas Different trade-offs in non-functional terms ECE750-Topic 11 61

62 Architecture-Based COTS Selection When using COTS, you accept their architectural restrictions Component selection and architecture definition are intertwined Here we ll use a simple case study to exemplify the points Case study come from Mancebo2005 ECE750-Topic 11 62

63 Architecture-Based COTS Selection Has four steps iterative process Here we will select components for a multimedia presentation application Think PowerPoint 3D Choose Architectural Decisions Model Component Market List Implementation Approaches Choose Best Implementation Approach ECE750-Topic 11 63

64 Architecture-Based COTS Selection 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 XML format (KAD 3a ) or as serialized objects (KAD 3b )? Choose Architectural Decisions Model Component Market List Implementation Approaches Choose Best Implementation Approach ECE750-Topic 11 64

65 Architecture-Based COTS Selection Perform analysis of available components Create matrices reflecting the assumptions a capabilities of components Requirements Fulfillment Component Dependency Architectural Assumptions Choose Architectural Decisions Model Component Market List Implementation Approaches Choose Best Implementation Approach ECE750-Topic 11 65

66 Requirements Fulfillment Matrix Ogre DirectX OpenGL OpenAL OGLFT QT Graphics API X X Audio X X 3d Text X X GUI Widgets X The X axis is the potential components would be considered using The Y axis lists user s requirements An X represents that that particular component fulfils a particular requirement ECE750-Topic 11 66

67 Component Dependency Matrix Graphics API MFC OpenGL Ogre X DirectX X OGLFT X GLTT X The Y axis is the potential components The X axis is things on which those components depend. An X represents that that particular component fulfils a particular dependency ECE750-Topic 11 67

68 Architectural Assumptions Matrix Ogre DirectX KAD 1 1a KAD 3 KAD 2 Ogre assumes decision 1a that graphics objects must know how to render themselves. 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 XML 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. ECE750-Topic 11 68

69 Architecture-Based COTS Selection To determine the feasible selections Enumerate the architectural approaches Of the form: AA = KAD Example: AAex = KAD 1a Enumerate implementation approaches Of the form: Example: 1 xkad 2 L KAD n IA = ( AA, C) IA ( AA,{ DirectX, Ogre, Qt}) ex = ex Choose Architectural Decisions Model Component Market List Implementation Approaches Choose Best Implementation Approach ECE750-Topic 11 69

70 Architecture-Based COTS Selection IA ex = ( AA,{ DirectX, Ogre, MFC}) ex Choose Architectural Decisions Under the constraints of these set of components: Covers all rows in the requirements matrix Satisfies all component dependencies Is consistent with Architectural Approach Model Component Market List Implementation Approaches Choose Best Implementation Approach ECE750-Topic 11 70

71 Summary Component-based development includes two main phases Component Development (design for reuse) System Development (design with reuse) System Development There is a sequence of finding, selecting, and testing components This sequence may be repeated in the operation and maintenance/evolution as well There may be also custom development ECE750-Topic 11 71

72 Summary Component Development Save time and effort in software projects May bring more predictability of cost and performance Can reuse successful components with appropriate support System composition/integration may confront problems Mainly due to hidden assumptions about Components Connectors Global Architecture Composition Process ECE750-Topic 11 72