INF5120 – Modellering med objekter · 1 Telecom and Informatics 1 INF5120 – Modellering med objekter Quality of Service Support in Software Architecture Forelesning 10 25.03.2004

1

1Telecom and Informatics

INF5120 – Modellering med objekter

Quality of Service Support in Software Architecture

Forelesning 1025.03.2004

Jan Øyvind Aagedal


Agenda

� Quality of Service Support in Software Architecture� Terminology - IEEE� MDA investigated

� Quality of Service Support in Software Architecture � What is Quality of Service (QoS) and why do we need to bother?� Where does QoS fit in the picture?

� Quality of Service Support in Software Architecture� QoS Management

� Quality of Service Support in Software Architecture� Component Quality Modelling Language (CQML)

� Overview and principles� Example

2


Quality of Service Support in Software Architecture� IEEE Std 1471-2000

� Recommended Practice for Architectural Description

� Adopted September 2000� For software-intensive systems

� Architecture has too long been focussed on hardware-related issues - IEEE strikes back!

� Common frame of reference for architectural descriptions� Common terminology

� architecture, architectural description, model, view, viewpoint, system, stakeholder, concern, …


Motivations

� Change ctd.� Changes should have limited effects

� Do not want to have unknown ripple effects

� Should define the envelope of change � What is allowed to change without

major consequences

� Good, old SW engineering principles still apply!

� Loose coupling� High cohesion

� Flexibility as a competitive advantage� AT&T vs Sprint

� Complexity� SW systems become complex� The context becomes complex

� Many usage scenarios

� How to convey� Internal structure?� Applicability in different

contexts?

� Change� Panta rei

� Requirements, underlying platform, competitors, market, ...

� Two major motivations for explicit architecture� Change and Complexity

3


Architecture of what?

Virtual enterprise

Business

Software system

Software component

Software object

Software architecture

Enterprise architecture

Decomposition

Bus1Bus2 Bus3

Bus4

SW syst1Actor1 Actor2

SW syst2

Decomposition

Comp1Comp2 Comp3

Comp4

Decomposition

Decomposition

Object1Object2 Object3

Object4

Datatype1Datatype2 Operation1

Datatype3


Concern

has 1..* identifies

1..*

used to cover

1..*

Viewpoint

Library viewpoint

0..1has source

selects 1..*conforms to

establishes methods for1..*

Model1..*

aggregates1..*consists of

1..*participates in

View

1..*organized by

participates in

Architectural description1..*

identifies

1..*is addressed to

1..*is important to Stakeholder

described byhas1..*

Rationaleprovides

Architecturehas aninfluences

inhabitsEnvironment System

1..*fulfills

Mission

Those interests which pertain the system’s development, operation and other aspects that are critical or otherwise important to one or more stakeholders.

Concern

The expression of a systems architecture with respect to a particular viewpoint. Addresses one or more of the concerns of the system stakeholder.

View

Determines the boundaries that define the scope of the system of interest relative to other systems.

Environment RationaleThe Rationale of the architecture.

Library viewpoint

A viewpoint with definition originated elsewhere than in the architectural description.

Developed using the methods established by its viewpoint, consisting of views expressing an architectural description.

Model

Has interest in, or concerns relative to the system.

Stakeholder

Viewpoint

A specification of the conventions of constructing and using a view. A pattern or template from which to develop individual views.

A collection of products to document an architecture.

Architectural description

A collection of components organized to accomplish a specific function or set of functions.

System Architecture

The fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.

A use or operation for which a system is intended by one or more stakeholders to meet some set of objectives.

Mission

4


described by

identifies

SystemEnvironmentinfluences

inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an

Architectural description

Concern

is important to

has identifies

ViewViewpointused to cover

is addressed to

selects organized by

conforms to

Modelestablishes methods for

participates in

consists of aggregates

participates in

Library viewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

Conceptual Model


described by

identifies


inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an

Architecturaldescription

Concern

is important to

has identifies


is addressed to


conforms to


participates in


participates in

Libraryviewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

IEEE Definitions

� Architecture� The fundamental organisation of a system embodied in its

components, their relationships to each other and to the environment, and the principles guiding its design and evolution.

� Architecture description� A collection of products to document an architecture.

� Concern� Those interests which pertain the system’s development, operation

and other aspects that are critical or otherwise important to one or more stakeholders.

5


described by

identifies


inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an


Concern

is important to

has identifies


is addressed to


conforms to


participates in


participates in

Libraryviewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

IEEE Definitions

� Environment� Determines the boundaries that define the scope of the system of

interest relative to other systems.

� Library viewpoint� A viewpoint with definition originated elsewhere than in the

architectural description.

� Mission� A use or operation for which a system is intended by one or more

stakeholders to meet some set of objectives.


described by

identifies


inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an


Concern

is important to

has identifies


is addressed to


conforms to


participates in


participates in

Libraryviewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

IEEE Definitions

� Model� Developed using the methods established by its viewpoint,

consisting of views expressing an architectural description.

� Rationale� The Rationale of the architecture.

� Stakeholder� Has interest in, or concerns relative to the system.

6


described by

identifies


inhabits

Mission

Stakeholder

has

fulfills

Architecturehas an


Concern

is important to

has identifies


is addressed to


conforms to


participates in


participates in

Libraryviewpoint

has source

Rationaleprovides

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..*

0..1

1..*

1..*

1..*

1..*

IEEE Definitions

� System� A collection of components organized to accomplish a specific

function or set of functions.

� View� The expression of a systems architecture with respect to a

particular viewpoint. Addresses one or more of the concerns of the system stakeholder.

� Viewpoint� A specification of the conventions of constructing and using a

view. A pattern or template from which to develop individual views.


Defines Evolutionary Envelope� Anticipates likely system changes

� Other changes than the anticipated ones are often very expensive and uncertain

� D’Souza & Wills: “Architecture - The set of design decisions about any system (or smaller component) that keeps its implementors and maintainers from exercising needless creativity.”

� What matters in your system?� You may want to apply relevant patterns to support your

concerns

Built for speed:

Built for extensibility: Mediator

7


From Bran Selic at Summer School on Software

Architecture, Turku, Finland, August 2001

Architectural Description


Arkitekturer og meta-nivå� Architecture

� The fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.

8


Model Driven Architecture Framework


MDA: Models

� Model = a representation of part of the function, structure, and/or behaviour of the system

� Platform = technological and engineering details that are irrelevant to the fundamental functionality of a software component

9


MDA: Viewpoints

� View = a representation of the whole system from the perspective of a related set of concerns

� Viewpoint = a specification of the conventions for constructing and using a view

� Abstraction = description that omits details that are not relevant to the purpose of abstraction


Refinement

� Refinement = a more detailed description that conforms to another (its abstraction)

� Refinement relation = described using a model, defining abstraction observations in terms of realization observations while maintaining certain guarantees of the abstraction

***

10


MDA: Model transformation

� Model transformation = the process of converting one model into another model of the same system

� Mapping = a set of rules and techniques used for this modification


MDA: Transformation

***

*

11


MDA: Mapping


MDA: Refinement != transformation

� Refinement relation� criteria for when a model is a realization of another model

� Transformation� the process of constructing one model from another model

� Mapping� rules and techniques to be used in a transformation process

� Refinement pattern� special case of mapping, defined in accordance with refinement

relation

12


MDA: “Model driven” - a definition

� A system development process is model driven if� the development is mainly carried out using conceptual models at

different levels of abstraction and using various viewpoints� it distinguishes clearly between platform independent and platform

specific models� models play a fundamental role, not only in the initial development

phase, but also in maintenance, reuse and further development� models document the relations between various models, thereby

providing a precise foundation for refinement as well as transformation


Metamodels

� Metamodels are specifications� models are valid if no false statements according to metamodel

(i.e., well-formed)

� Metametamodel� model of metamodels� reflexive metamodel, i.e., expressed using itself

� ref. Kurt Gödel

� minimal reflexive metamodel� can be used to express any statement about a model

13


Meta levels in OMG

� M0 – what is to be modelled (Das Ding an sich)� M1 – Models (Das Ding für mich)

� May contain both class/type and instance models

� M2 – Metamodels� M3 – The metametamodel

� Interpretation (not instantiation!) crosses meta-layers, theories reside in one layer (e.g., instance models can be deduced from class models)


Classification

Dog

Collie

Animal

LivingBeing Four Legged

Object

Celebrity

MovieStar

Lassie

14


Classification Dimensions

Collie

Celebrity

Four LeggedObject

Animal

Dog

Movie Star

Model Element

Instance

Object

Ontological classification(domain types)

Linguistic classification(representation form)


Kinds of metamodels

� Two kinds of information of a set of models are modelledin metamodels� Form (linguistic aspects)

� OMG is predominantly occupied with this

� Content (ontological aspects)

15


Linguistic metamodelling

LassieCollie

Class Object

Class

represents represents

linguistic ”instance-of” linguistic ”instance-of”

linguistic ”instance-of” linguistic ”instance-of”

instance-of

ontological instance-of

ontological instance-of

L0 (called M0 in OMG)





Ontological metamodelling

Lassie

Collie Class

Breed

represents linguistic instance-ofO0

O1

O2

O3

Object

Biological rank

ontological ”instance-of”

linguistic instance-of

linguistic instance-ofontological”instance-of”



L1 L2

16


UML profiles

� Define the meaning of modelling elements� interpretation, i.e., relate stereotyped classifiers to real world

concepts such as memory, process, resource

� Mostly content (ontological), but must relate to form (linguistic)

� Poor expressional power – stereotypes� no relations between O 0/1/2 concepts� cast as form, but is really content

Breed

Class


Resource model as a UML profile

<<ResourceInstance>>0xFFFF:LocalCache

ResourceInstance

Class

Resource

represents

ontological”instance-of”

linguisticinstance-of

00

O1

Object

linguisticinstance-of

Memoryrepresents

ontological”instance-of”

L2

<<Memory>>LocalCache

L1

17


Architecture Description Techniques� ADLs (Architecture Description Languages)

� Rapide, UniCon, Wright, Aesop, ArTek, SADL, Meta-H, C-2, ...� Lexical, research-oriented (not widely used)

� Lessons learned from the ADL community� Connectors, Interfaces� Multiple representations

� Refinement, PIM/PSM

� Styles� Domain-specific vocabulary� Impose topology constraints

� Visualisation� Domain-specific visual conventions

� UML (Unified Modeling Language)� Graphical� Standard, widely used� No agreed set of diagrams to specify system architectures


Seven Principles of Sound Documentation (from Paul Clements, SEI, CMU)

� Certain principles apply to all documentation, not just documentation for software architectures.

� 1. Write from the point of view of the reader.

� 2. Avoid unnecessary repetition.

� 3. Avoid ambiguity.

� 4. Use a standard organization.

� 5. Record rationale.

� 6. Keep documentation current but not too current.

� 7. Review documentation for fitness of purpose.

18


1. Write from the point of viewof the reader.

� What will the reader want to know when reading a document?� Make information easy to find!

� Your reader will appreciate your effortand be more likely to read yourdocument.

� Signs of documentation written for the writer’s convenience:� stream of consciousness: the order is that in which things occurred

to the writer

� stream of execution: the order is that in which things occur in the computer


2. Avoid unnecessary repetition.

� Each kind of information should be recorded in exactly one place.

� This makes documents easier to use and easier to change.

� Repetition often confuses, because the information is repeated in slightly different ways. Which is correct?

� Question: When is repetition OK?

19


3. Avoid ambiguity.

� Documentation is for communicating information and ideas. If the reader misunderstands, the documentation has failed.

� Precisely-defined notations/languages help avoid whole classes of ambiguity.

� If your documentation uses a graphical language� always include a key � either point to the language’s formal definition or give the meaning

of each symbol. Don’t forget the lines!


3. Avoid ambiguity (cont’d.)

� Box-and-line diagrams are a verycommon form of architectural notation.

� But what do they mean?

� These do not show an� architecture, but only the beginning of one.

� If you use one, always define precisely what the boxes are and what the lines are.

� If you see one, ask the owner what it means. The result is usually very entertaining.

20


4. Use a standard organization.

� Establish it, make sure your documents follow it, and make sure that readers know what it is.

� A standard organization� helps the reader navigate and find information

� helps the writer place information and measure work left to be done

� embodies completeness rules, and helps check for validation


4. Use a standard organization (cont’d.)

� Corollaries:

� Organize the documentation for ease of reference.� A document may be read once, if at all.� A successful document will be referred to hundreds or thousands of

times.� Make information easy to find. � Question: How?

� Don’t leave incomplete sections blank; mark them “to be determined”� Question: Why?

21


5. Record rationale.

� Why did you make certain design decisions the way you did?

� Next week, next year, or next decade, how will you remember? How will the next designer know?

� Recording rationale requires discipline, but saves enormous time in the long run.

� Record rejected alternatives as well.


6. Keep documentation current but not too current.

� Keep it current:� Documentation that is incomplete, out of date, does not reflect

truth, and does not obey its own rules for form is not used.� Documentation that is kept current is used.� With current documentation, questions are most efficiently

answered by referring the questioner to the documentation.� If a question cannot be answered with a document, fix the

document and then refer the questioner to it.� This sends a powerful message.

22


6. Keep documentation current but not too current (cont’d.)

� Don’t keep it too current� During the design process, decisions are considered and re-

considered with great frequency.� Revising the documentation every five minutes will result in

unnecessary expense.� Choose points in the development plan when documentation is

brought up to date� Follow a release strategy that makes sense for your project.,


7. Review documentation for fitness of purpose

� Only the intended users of a document can tell you if it� contains the right information� presents the information in a useful way� satisfies their needs

� Plan to review your documents with representatives of the groups for whom it was created.

� Active design reviews are a good technique.

23


Quality of Service Support in Software Architecture� Architecture defines evolutionary envelope within which

acceptable quality is maintained� But what kind of qualities are affected?

� Qualities define the “goodness” of the system (or its architecture)

� Heaps of -ilities� Subjective vs. objective quality� Design-time vs. run-time qualities


effectiveness productivity safety

quality in use

satisfaction

ISO 9126 - Software Product Quality

� Quality in use - related to a specific context of use � effectiveness – the capability of the software product to enable users

to achieve specified goals with accuracy and completeness in a specified context of use.

� productivity – the capability of the software product to enable users to expend appropriate amounts of resources in relation to the effectiveness achieved in the specified context of use.

� safety – the capability of the software product to achieve acceptable levels of risk of harm to people, business, software, property or the environment in a specified context of use.

� satisfaction – the capability of the software product to satisfy users in a specified context of use.

24


ISO 9126 - External and Internal Quality Metrics� Irrespective of

context of use

functionality reliability usability efficiency maintainability

external and internal quality

portability

suitabilityaccuracyinteroperabilitysecurity

functionality compliance

maturityfault tolerancerecoverability

reliabilitycompliance

understandabilitylearnabilityoperabilityattractiveness

usability compliance

time behaviourresource utilisation

efficiency compliance

analysabilitychangeabilitystabilitytestability

maintainability compliance

adaptabilityinstallabilityco-existencereplaceability

portabilitycompliance


Functionality

� Suitability� The capability of the software

product to provide an appropriate set of functions for specified tasks and user objectives.

� Accuracy� The capability of the software

product to provide the right or agreed results or effects with the needed degree of precision.

� Interoperability� The capability of the software

product to interact with one or more specified systems.

� Security� The capability of the software

product to protect information and data so that unauthorised persons or systems cannot read or modify them and authorised persons or systems are not denied access to them

� Functionality compliance� The capability of the software

product to adhere to standards, conventions or regulations in laws and similar prescriptions relating to functionality.

� The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions.

25


Reliability

� Maturity� The capability of the software

product to avoid failure as a result of faults in the software.

� Fault tolerance� The capability of the software

product to maintain a specified level of performance in cases of software faults or of infringement of its specified interface.

� Recoverability� The capability of the software

product to re-establish a specified level of performance and recover the data directly affected in the case of a failure.

� Reliability compliance� The capability of the software

product to adhere to standards, conventions or regulations relating to reliability.

� The capability of the software product to maintain specified level of performance when used under specified conditions.


Usability

� Understandability� The capability of the software

product to enable the user to understand whether the software is suitable, and how it can be used for particular tasks and conditions of use.

� Learnability� The capability of the software

product to enable the user to learn its application.

� Operability� The capability of the software

product to enable the user to operate and control it.

� Attractiveness� The capability of the software

product to be attractive to the user.

� Usability compliance� The capability of the software

product to adhere to standards, conventions, style guides or regulations relating to usability.

� The capability of the software product to be understood, learned, used and attractive to the user, when used under specified conditions.

26


Efficiency

� Time behaviour� The capability of the software

product to provide appropriate response and processing times and throughput rates when performing its function, under stated conditions.

� Resource utilisation� The capability of the software

product to use appropriate amounts and types of resources when the software performs its function under stated conditions.

� Efficiency compliance� The capability of the software

product to adhere to standards or conventions relating to efficiency.

� The capability of the software product to provide appropriate performance, relative to the amount of resources used, under stated conditions.


Maintainability

� Analysability� The capability of the software

product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified.

� Changeability� The capability of the software

product to enable a specified modification to be implemented.

� Stability� The capability of the software

product to avoid unexpected effects from modifications of the software.

� Testability� The capability of the software

product to enable modified software to be validated.

� Maintainability compliance� The capability of the software

product to adhere to standards or conventions relating to usability.

� The capability of the software product to be modified. Modifications may include corrections, improvements or adaptation of the software to changes in environment, and in requirements and functional specifications.

27


Portability

� Adaptability� The capability of the software

product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered.

� Installability� The capability of the software

product to be installed in a specified environment.

� Co-existence� The capability of the software

product to co-exist with other independent software in a common environment sharing common resources.

� Replaceability� The capability of the software

product to be used in place of another specified software product for the same purpose in the same environment.

� Portability compliance� The capability of the software

product to adhere to standards or conventions relating to portability.

� The capability of the software product to be transferred from one environment to another.


Development-time qualities (from Catalysis)

� Affected by architecture:� Modifiability- Can the system be modified efficiently?

� E.g., low coupling and high cohesion

� Reusability - Are there units in the system that can are candidates for use elsewhere? � E.g., does the system use standards?

� Portability - The ability to change platform� E.g., layering

� Buildability - Is it easy to implement?� E.g., use existing frameworks

� Testability - Can one easily define test scenarios?� E.g., precise requirement specifications

28


Runtime qualities (from Catalysis)

� Affected by architecture: � Functionality - does the system assist users in their tasks?� Usability - is it intuitive to use for all users?� Performance - does it perform adequately when running?

� E.g., response time, transaction volume, ...

� Security - does it prevent unauthorised access?� Reliability and availability - is it available and correct over time?� Scalability - can it cater for increased volume?� Upgradability - can it be upgraded at runtime?

� Single key quality: Conceptual integrity of an architecture


Quality of Service (QoS)

� QoS is a general term that covers system performance, rather than system operation (i.e., functionality)

� Extra-functional properties� degrees of satisfaction as opposed to satisfied / not satisfied

� Examples:� availability, reliability, precision, fault-tolerance, capacity,

throughput, delay, …

� Most common for multimedia, command and control, simulations, distributed systems, …

� Less common for information systems� there are needs! (transaction-based, security aware, etc.)

29


Different Abstractions

Hardware

Operatingsystem

Applicationinterface

Applicationsubsystem

Transportsubsystem

Networkingsystem

User User QoS

Application QoS

Transport QoS

Network QoS

System QoS

Hardware QoS

� Peer-to-peer vs. layers� QoS concepts on

different layers are different, but related� QoS mapping


Quality of Service Support in Software Architecture � Some is already available

� Networks and protocols (IPv6, RSVP, ATM, …)� Real time operating systems (Chorus, VxWorks, …)� Middleware (CORBA implementations such as COOL, ACE, …)

� Unified and comprehensive QoS architecture is still a hot research topic

� Several stakeholders� End users, system operators, network providers, resource owners,

...

� From a software engineering perspective, a unified computational model is needed

30


QoS Management� The activities needed to support monitoring, control and

maintenance of QoS� Spectrum from static to dynamic management

� Static� Designed and configured into the system� QoS are not monitored or controlled

� Dynamic� Adapts to changes� Monitoring, resource allocation, adaptation of applications (e.g.,

caching), re-routing, ...

� Best-effort QoS� Threshold or compulsory

� Guaranteed QoS� Statistical variations


Managing a Distributed Application

� Multimedia Presentation Application� App-Server gets multimedia data from MMDBMS and Web-Server� Multimedia data is ”combined” and presented to the client

Client App-Server

MMDBMS

Web-Server

Net1

Net2

LocalQoS Mgr

LocalQoS Mgr

LocalQoS Mgr

LocalQoS Mgr

LocalQoS Mgr

LocalQoS Mgr

StrategicQoS Mgr

� Use a ”local” QoS manager for each app component

� Use a hierarchy of dynamically-configured, ”strategic” QoS managers for end-to-end management

StrategicQoS Mgr

StrategicQoS Mgr

31


� Coordinated Global View vs. Component-specific change� Tactical adaptation within a component

� Strategic adaptation strategies

� Parameter adjustment� Increase buffer size by 50%� Increase frequency of checking and

adjusting a video scaling factor

� Service migration� Move a data filtering

component from theserver to the client

� Service replacement� Obtain a media object from a replicated data source in another domain

� Service replication� Create a cached data copy

and migrate some requeststo the cache server

� Algorithm replacement� Use hash-based search in

place of index-based search

Strategic vs Tactical Adaptation


Problem space Solution space InfrastructureQoSreqs.

QoSsupport

Quality of Service Support in Software Architecture

� QoS support in applications requires methodological support during development� How to match requirements and solutions

� QoS is a concern of many stakeholders� Need to include QoS specification into architectural descriptions

� The Big Question: How do changes affect the agreed upon QoS?

32


Overview

Reqs..

Process

UML + CQML

ApplicationC++/Java/...

Services

Middleware

Rep


CQML

� Component Quality Modelling Language� Lexical language for Quality of Service (QoS) specification� QoS specification orthogonal to functional specification

� add QoS specification of existing systems

� UML profile for QoS based on CQML

� QoS specification required for QoS management

33


CQML overview

Componentspecification

Profile_1

Statement_1

Characteristic_1

Characteristic_2

Characteristic_1

Statement_2

Profile_2

Statement_1

Characteristic_1

Characteristic_2

Characteristic_1

Statement_3

Characteristic_1

Statement_4


Orthogonality

UML profile for QoS

Foundation Quality Elements

34


Quality profiles

� Specifies conditional QoS offers� assumption/guarantee

� Related to service provider� A service provider may have many profiles

� offering different qualities to different clients

� Simple or compound profile� adaptation� transition behaviour between “regions”

Classifier(f rom Core ) QoSProfile

0..n1 0..n1 for


QoS contract� Components can provide a service only if the environment

meets certain requirements� A sufficiently hostile environment can always ruin system

performance

� Expectation(component) --> Obligation(component)� If the expectations are met, the component must keep its promise

� Can be used both between peers and between layersClassifier(from Core)

QoSStatementQoSProfile

0..n

1

0..n

1for

11provides

11uses

35


Quality statement

� Restricts QoS characteristics� Boolean expression of such restrictions� Qualified

� best-effort, guaranteed, threshold best-effort, compulsory best-effort

Classifier(f rom Co re)

QoSProfile

0..n

1

0..n

1for

QoSCharacteristic

QoSStatement

11provides

11uses

QoSConstraint1..n1..n


Quality characteristic

� It represents some aspect of the QoS of a system, service or resource that can be identified and quantified

� Represents the domain� numeric, enum, set� ordering (what is “better-than”?)� composition

� values of aggregates along this dimension

36


Conceptual model (virtual meta-model)

CategoryPart

QoSCategory

1..*

0..*

1..*

0..*

QoSCharacteristic

QoSConstraintQoSStatement1..*1..*

Classifier(from Core)

QoSProfile

11

provides

11

uses

1

0..*

1

0..*

for


Example

Enrol in University

{Public lectures may be viewed by all customers}

{Course lectures may only be viewed by students currently registered in the course}

Guest

Register for Course

Notify of Event

View Answer {Student must be enrolled,Prerequisites must be met,

Must be space in course}

GoodLearninglearnability >= good

<<QoSStatement>>

Viewer Find Lecture

Student

View Lecture

<<include>>

Ask Question

<<extend>>

37


Business Process Model

Create MM Lecture

Produce MM Element

Give Lecture LectureContent

Lecturer MM lecture producer

<<QoSConstraint>>Pedagogic

MMelement<<QoSConstraint>>Ordering and synchronymust be preserved

Lecture


CQML in req eng.

quality_characteristic learnability {domain : increasing enum{poor, average, good, excellent};media_quality;pedagogic_quality;

}

View LectureViewer

{learnability >= good}

38


Information and Computational Modelling

Study University

AtLeastISDN<<QoSStatement>>

bandwidth >= ISDN

AtLeastISDN<<QoSStatement>>

bandwidth >= ISDN

GoodLearning<<QoSStatement>>

learnability >= good

Viewer Find Lecture

Retrieve Lecture

View Lecture

<<include>>

<<include>>


Quantification

� How to measure and quantify quality?� Commonly agreed reference units (objective) versus ordinal

rankings (subjective)

� Main problem: From subjective to objective� Vagueness in classification of observations

� Vagueness is not ambiguity or generality� Sorites paradox (The “slippery-slope” argument)� Vagueness-as-ignorance or gray areas (fuzzy logic)?

� Chosen approach: Stability threshold

39


Timeliness

: Displayer : Lecture Consumer

1: play

2: showDataUnit(unit)

3: stop

4: showDataUnit(null)

5: fastForward

6: showDataUnit(unit)

7: pause

a

b

c

d

e

f

<<QoSConstraint>>{b - a < 1000 ms andd - c < 10 ms andf - e < 100 ms}


profile acceptable for Lecture Consumer {profile good {

uses good(in) and smooth(in);provides good(out) and smooth(out);

}profile ok {

uses good(in);provides good(out);

}transition good->ok: increaseBufferSize();

}

CQML in detailed designLecture Consumer

increaseBufferSize()

Buffer

size : Integerflow : Flow1..*

+in

1..*DataReceiver

putDataUnit(unit : DataUnit)

Displayer

showDataUnit(unit : DataUnit)

out

40


quality smooth(flow : Flow) {jitter(flow) < 10;

}quality_characteristic jitter(flow : Flow) {

domain : decreasing numeric milliseconds;values: (flow.SE->last.time() –(flow.SE->first.time() + flow.chronon*flow.SE->size())).abs;

composition: parallel-and max;parallel-or min;sequential +;

}

Support for QoS Management

� QoS mapping between abstraction levels needs brainwork� Traceability from requirements to solution


CIDLcomponent X {

provides If x;};…...

CQMLprofile Y for X {

provides good(x);;};…...

Repositories

Specifications

CompilationConfiguration/deployment

Running system

Codeclass anX implements X {

int i:=0….;

};…...

instancestemplates

QoS-aware System Development

41


Conclusions

� QoS should be considered during software design� QoS should be specified to support QoS management� QoS specifications should be orthogonal to software

architecture� but may influence it


QoS Profile for components

Operation(from Core)

CompoundProfile

ProfileTransit ion0..*0..*{ordered}

0..*0..*

SimpleProfile1..*1..*

{ordered}1+to11

+from1

QoSStatement1 11 1uses

11

11

provides

QoSAssociation

QoSProfile

BehavioralFeature(from Core)

Association(from Core)

AssociationEndisNavigable : Boolean

2..*

1+connection

2.. *

1Feature

(from Core)

Classifier(f rom Core) *1 *

+type

1* *+specification*

+participant*

*

1

+feature*

{ordered} +owner1

StructuralFeature(from Core)

1+type 1*

42


QoS Statement

SingleQoSStatement

QoSConstraintqualification : QualificationKind

11

{ordered}

Constraintbody : BooleanExpression

ModelElement(from Core)

*

1..*

+constraint*

+constrainedElement1..*

{ordered}

CompoundQoSStatement

Operation(from Core)

QoSStatement2..n2..n

relation0..10..1worth


Parameter(from Core)

0..*+parameter

0..*

1 *

+type

1 *


QoS Characteristic

Numeric<<primitive>>

String(from Data Types)

<<primitive>>

Set

StringSet 1..*1..*1.. *1.. *{ordered}

Enumeration(from Data Types)

DataType(from Core)

StatisticalAttributeKind<<enumeration>>

Domaindirection : DirectionKind


QoSCharacteristicinvariant : BooleanExpressionparallel_and_composition : MappingExpressionparallel_or_composition : MappingExpressionsequential_composition : MappingExpressionvalues : MappingExpression

0..*0..*

11

Parameter(f rom Core)

1*

+type

1*

+parameter

43


QoS Category

QoSProfile

QoSCharacteristic

QoSCategory

CategoryPart

0..*

1..*

0..*

1..*

QoSStatement

Namespace(from Core)


Quality types

QualificationKind<<enumeration>>

DirectionKind<<enumeration>>

StatisticalAttributeKind<<enumeration>>

Documents

INF5120 – Modellering med objekter · 1 Telecom and Informatics 1 INF5120 – Modellering med objekter Quality of Service Support in Software Architecture Forelesning 10 25.03.2004