Evaluating Quality Properties of Component-based Software Architectures

1
Evaluating Quality Properties of
Component-based Software Architectures

• Egor Bondarev Michel Chaudron
• System Architecture Networking Group
• Peter de With (TUE LogicaCMG)
• Video Coding Architectures Group
• Technische Universiteit Eindhoven, The Netherlands

2
Outline

• Introduction Context
• Problem statement
• Approach
• scenario-based predictable assembly
• Conclusion

3
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
Problem Statements
(1) Can we design a system using third-party
software components that provides the required
extra-functional quality (XFQ) properties?
designtime

• (2) How can we ensure that a system will continue
  to provide the XFQs while third-party software
  components are added and removed?

runtime
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
Required eXtra-Functional Qualities

• 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

6
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
Problem Instance Cost

• Derive cost of a system from cost of its parts.

C1
25
S
42
C1
C2
C2
17
Other example static memory use
More complicated real-time / timeliness
properties
8
Problem Instance Timeliness

• Derive timing of a system from timing of its
  parts.

C1
25 sec
S
?
C1
C2
C2
17 sec
It depends

• way of connecting components (seq, parallel)
• shared resources (and their scheduling)
• synchronization

9
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
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
Solution Approach
Based on the following concepts

• Models for both software- and hardware
  components.
• Scenarios-based evaluation
• The designer can focus on critical aspects of
  system behaviour.
• Simulation of scenarios

12
Proposed Solution
Major assumptions

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.

13
Example Problem Car Navigation System (CNS)
Logical View
Environment
MMI Man-Machine Interface RAD Radio
controller NAV Navigation Software
14
CNS Architectural Alternatives
Optimal alternatives in terms of Resource usage
Performance Reliability Cost
15
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
Component behaviour model
Service is run-time unit of structuring

• 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-dependentcall sequences can be
modelled
17
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
Different resource models may be supplied
fordifferent (classes) of processors (RISC,
VLIW, )
18
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
Model Assembly Phase 1 Structure

• At bind-time, the decision is made which services
  are composed to provide the implementation of an
  interface

• A call to operation f is started

f

• f is provided by s1
• s1 needs g from I2 and h from I3
• I2 (hence g) is provided by s2
• s2 is done
• I3 (hence h) is provided by s3
• s3 needs j from I4
• I4 (hence j) is provided by s4
• s4 is done

s1
g
h
s2
s3
j
s4
20
Model Assembly Phase 2 Logical Behaviour
Combine the behaviour models of the operations
used

• Press button f

operation f calls S2.g S2.g S3.h S3.h
f
s1
s1
g
h
s2
s2
s3
s3
j
s4
s4
21
Model Assembly Phase 3 Integrate Resource Claims
f
s1
s1
g
h
s2
(cl,rl)
(cl,rl)
s2
s3
s3
(cl,rl)
(cl,rl)
j
s4
s4
(cl,rl)
(cl,rl)
22
Model Assembly Phase 4 Define concurrency
behaviour
Mapping of Logical behaviour onto Tasks
U1
v
v
U2
(cl,rl)
(cl,rl)
w
w
U3
(cl,rl)
(cl,rl)
23
Phase 5 Resource Scheduling
Resource Management Policy e.g. scheduler
e.g. EDF, CBS,
v
w
v
v
p
q
r
g
g
h
h
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
(cl,rl)
Resource
.. etc
17
253
42
24
Scenario Simulation
Simulation time
25
Summary of Recipy for Predictable Assembly
0. Definition of Scenarios
C1
C2
1. Composition of System Structure

• Composition of Logical Behaviour
• of whole system

x
y
z
Analyser
Inheritance Relator
DB Creator
DB Filler
resource R claim 100 release 100

• Composition of Execution Behaviour
• - tasks
• - resource mng policies

system model

1. Analyse

26
Evaluating Architectural Alternatives
Hardware node
Hardware link
Sw Component
27
Graphical Composer
28
Design Flow
29
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
Questions?
31
Task Reconstruction
Comp_A
Operation_A
32
Composability Property Classification
Adapted from Ivica Crnkovic

• 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.
• Architecture-related properties. A property of an
  assembly which is a function of the same property
  of the components and of the software
  architecture.
• Derived (emerging) properties. A property of an
  assembly which depends on several different
  properties of the components.
• Usage-depended properties. A property of an
  assembly which is determined by its usage
  profile. E.g. CPU load.
• System context properties. A property which is
  determined by other properties and by the state
  of the system environment.
• E.g. safety.