Presentation is loading. Please wait.

Presentation is loading. Please wait.

November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Evaluating Quality Properties of Component-based Software Architectures Egor BondarevMichel.

Similar presentations


Presentation on theme: "November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Evaluating Quality Properties of Component-based Software Architectures Egor BondarevMichel."— Presentation transcript:

1 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Evaluating Quality Properties of Component-based Software Architectures Egor BondarevMichel Chaudron System Architecture & Networking Group Peter de With (TUE & LogicaCMG) Video Coding & Architectures Group Technische Universiteit Eindhoven, The Netherlands

2 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Outline Introduction & Context Problem statement Approach scenario-based predictable assembly Conclusion

3 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Context Robocop/Space4U projects high volume embedded systems mobile phones (Nokia), DVD players (Philips) multimedia processing and control systems Open component-based framework for resource constrained systems Open at run-time: software components may come and go Requirements: Robustness, Upgrading/extension, and Trading

4 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Problem Statements (2)How can we ensure that a system will continue to provide the XFQs while third-party software components are added and removed? (1) Can we design a system using third-party software components that provides the required extra-functional quality (XFQ) properties? design time run time Third party software components are black-box i.e. no access to internals/code. For reasons of efficiency of reuse or protection of IP

5 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Does the system (continue to) behave properly? Can the system execute tasks in a timely manner? Is there sufficient CPU power? Does the system have sufficient memory for the tasks? Is there no malicious use of resources? Typical system quality attributes: Performance (timeliness, throughput) Resource use (processor, memory, bus) Reliability Cost Required eXtra-Functional Qualities

6 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Predictable Assembly Can we predict the quality attributes of a system based on the properties of its components? Candidate Quality Properties: Efficiency, Footprint, Responsiveness, Scalability, Schedulability, Timeliness, CPU utilization, Latency, Throughput, Concurrency, Accuracy, Accountability, Testability, Traceability, Analyzability, Distributeability, Availability, Confidentiality, Integrity, Reliability, Safety, Security, Affordability, Extensibility, Tailorability What do we need to specify per component in order to be able to predict system properties?

7 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Problem Instance: Cost Derive cost of a system from cost of its parts. C1C1 C2C2 17 C1C1 C2C2 S 25 42 More complicated: real-time / timeliness properties Other example: static memory use

8 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Problem Instance: Timeliness Derive timing of a system from timing of its parts. C1C1 C2C2 17 sec C1C1 C2C2 S 25 sec ? way of connecting components (seq, parallel) shared resources (and their scheduling) synchronization It depends …

9 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Characteristics of Target Systems Systems may be event-triggered and time-triggered SW components may be active or passive System support multi-threaded applications System supports dynamic resource (CPU, memory) allocation There may be dependencies between tasks control- and data-dependencies synchronization constraints: task precedence, rendezvous, mutexed operations System are designed by composing black box software- and hardware-components

10 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Requirements on the analysis method Method should allow low modelling effort a trade-off between modeling effort and accuracy resource-efficient analysis (for run-time analysis) Nice to have: compatibility with Unified Modelling Language (UML (2.0)) IEEE Stnd. 1471 Recommended Practice for Architectural Description of Software-Intensive Systems

11 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Solution Approach 1.Models for both software- and hardware components. 2.Scenarios-based evaluation The designer can focus on critical aspects of system behaviour. 3.Simulation of scenarios Based on the following concepts

12 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Proposed Solution 1.Software component models and hardware component models are available at system design time. 2.Resource usage (execution time, bus load) of each component operation is defined by a model. 3.The architect is able to identify a set of critical execution scenarios for an architecture. Major assumptions:

13 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Example Problem: Car Navigation System (CNS) MMI = Man-Machine Interface RAD = Radio controller NAV = Navigation Software Logical ViewEnvironment

14 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With CNS: Architectural Alternatives Optimal alternatives in terms of: Resource usage + Performance + Reliability + Cost + … 22 MIPS MMI_Inst 113 MIPS 11 MIPS 72 kbps (A) NAV_InstRAD_Inst 22 MIPS MMI_Inst 113 MIPS 11 MIPS 72 kbps (B) NAV_InstRAD_Inst 57 kbps 22 MIPS MMI_Inst 260 MIPS 72 kbps (C) NAV_Inst RAD_Inst 130 MIPS MMI_Inst 113 MIPS 72 kbps (D) NAV_Inst RAD_Inst 260 MIPS MMI_Inst RAD_Inst NAV_Inst (E)

15 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Robocop Component Model A Component is a set of models Provided by the supplier Executable Components have Services Services have provides and requires interfaces Interfaces have operations

16 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Component behaviour model service c2 requires I2 requires I3 provides I1{ operation f uses I2.g uses I3.h behaviour operation f calls: I2.g* I3.h } Behaviour is modeled per operation Variable & data-dependent call sequences can be modelled Service is run-time unit of structuring ? Behaviour forms a partial call graph I2 c2

17 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Resource Model ResourceModel_MPEG4Decoder_Component resource use operation decodeFrame() cpu claim max = 1E7 cycles aver = 1E5 cycles min = 1E4 cycles mem claim = 10 KB mem release = 3 KB ResourceModel_MPEG4Decoder_Component resource use operation decodeFrame() cpu claim max = 1E7 cycles aver = 1E5 cycles min = 1E4 cycles mem claim = 10 KB mem release = 3 KB Different resource models may be supplied for different (classes) of processors (RISC, VLIW, …)

18 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Model Assembly Phase 0: Define Scenarios A scenario is a setting of A set of one or more triggers A specific configuration of a system Trigger t fires every s msec this trigger starts operation f of interface I

19 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With g Model Assembly Phase 1: Structure A call to operation f is started f h j f is provided by s 1 s 1 needs g from I2 and h from I3 I2 (hence g) is provided by s 2 s 2 is done I3 (hence h) is provided by s 3 s 3 needs j from I4 I4 (hence j) is provided by s 4 s 4 is done s1s1 s2s2 s3s3 s4s4 At bind-time, the decision is made which services are composed to provide the implementation of an interface

20 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Combine the behaviour models of the operations used g Model Assembly Phase 2: Logical Behaviour Press button f f h j s1s1 s2s2 s3s3 s4s4 s1s1 gg s2s2 s3s3 h s4s4 jhj operation f calls: S2.g; S2.g; S3.h; S3.h

21 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With g Model Assembly Phase 3: Integrate Resource Claims f h j s1s1 s2s2 s3s3 s4s4 s1s1 gg s2s2 s3s3 h s4s4 j (cl,rl) hj

22 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Model Assembly Phase 4: Define concurrency behaviour s1s1 gg s2s2 s3s3 h s4s4 j (cl,rl) h j T1T1 p T2T2 T3T3 q T4T4 r U1U1 vv U2U2 U3U3 w w Mapping of Logical behaviour onto Tasks xyz

23 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Phase 5: Resource Scheduling s1s1 gg s2s2 s3s3 h s4s4 j (cl,rl) h j T1T1 p T2T2 T3T3 q T4T4 r U1U1 vv U2U2 U3U3 w w Resource Management Policy e.g. scheduler Resource g (cl,rl) p v g q w h r v v h.. etc 17 42 253 e.g. EDF, CBS, …

24 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Scenario Simulation Simulation time Bus load Simulation time Memory usage

25 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With xyz ParserAnalyserInheritance RelatorDB CreatorDB Filler DB Checker AnalyserInheritance RelatorDB CreatorDB Filler resource R claim 100 release 100 1.Composition of System Structure 2.Composition of Logical Behaviour of whole system C1C1 C2C2 3.Composition of Execution Behaviour - tasks - resource mng policies C1C1 C2C2 S platform RM Summary of Recipy for Predictable Assembly system model 4.Analyse 0.Definition of Scenarios

26 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Evaluating Architectural Alternatives 22 MIPS MMI_Inst 113 MIPS 11 MIPS 72 kbps (A) NAV_InstRAD_Inst 22 MIPS MMI_Inst 113 MIPS 11 MIPS 72 kbps (B) NAV_InstRAD_Inst 57 kbps 22 MIPS MMI_Inst 260 MIPS 72 kbps (C) NAV_Inst RAD_Inst 260 MIPS MMI_Inst RAD_Inst NAV_Inst (E) Hardware nodeHardware linkSw Component 130 MIPS MMI_Inst 113 MIPS 72 kbps (D) NAV_Inst RAD_Inst

27 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Graphical Composer

28 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Design Flow

29 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Evaluation of the method Predict XF-Q properties based on black-box components Compositional (supports third-party binding) Method can be used throughout development cycle (design / implementation / run-t) with incremental accuracy The method can be applied to different types of resources Supports dynamic resource management policies The method can support different types of analyses (Worst-Case, Best-Case, …) Scenarios Do not give 100% guarantees as usual in formal methods Do allow incremental accuracy: focus on what is important

30 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Questions?

31 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Task Reconstruction Comp_A Comp_B Operation_B Operation_C Comp_CComp_D Operation_D Operation_F Comp_F Operation_E Task Trigger1 Component Behavior Model: VideoEncode() calls IBufferAccess.getFrame(); IMux.putVFrame() Operation_A Application Scenario Model: TaskTrigger1 triggers IBufferAccess.operationA(); Component Resource Model: Operation_E claims 1E5 100 ms

32 November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Composability Property Classification 1.Directly composable properties. A property of an assembly which is a function of, and only of the same property of the components involved. E.g. cost. 2.Architecture-related properties. A property of an assembly which is a function of the same property of the components and of the software architecture. 3.Derived (emerging) properties. A property of an assembly which depends on several different properties of the components. 4.Usage-depended properties. A property of an assembly which is determined by its usage profile. E.g. CPU load. 5.System context properties. A property which is determined by other properties and by the state of the system environment. E.g. safety. Adapted from Ivica Crnkovic


Download ppt "November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Evaluating Quality Properties of Component-based Software Architectures Egor BondarevMichel."

Similar presentations


Ads by Google