Modelling Support for Quality of Service Eclipse ECESIS Project - 1 - Modelling Support for Quality of Service Department for Cooperative and Trusted Systems.

Slides:



Advertisements
Similar presentations
Profiles Construction Eclipse ECESIS Project Construction of Complex UML Profiles UPM ETSI Telecomunicación Ciudad Universitaria s/n Madrid 28040,
Advertisements

Ch.21 Software Its Nature and Qualities. Ch.22 Outline Software engineering (SE) is an intellectual activity and thus human-intensive Software is built.
System Integration Verification and Validation
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
TI BISNIS ITG using COBIT &
軟工一 吳彥諄. * Scrum overview * What happened to the software * What is the quality attribute * ACRUM * Q&A.
Software project management (intro) Quality assurance.
The Architecture Design Process
Ensuring Non-Functional Properties. What Is an NFP?  A software system’s non-functional property (NFP) is a constraint on the manner in which the system.
CS 325: Software Engineering March 26, 2015 Software Quality Assurance Software Metrics Defect Injection Software Quality Lifecycle Measuring Progress.
1 FM Overview of Adaptation. 2 FM RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Project Investigators: Philip McKinley, Kurt.
Non-Functional Requirements
Course Instructor: Aisha Azeem
Non-functional requirements
Comparing M2T & M2M Complementary Approaches © 2008 INRIA, University of York & SINTEF Comparing M2T & M2M Complementary Approaches Hugo Bruneliere,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Software Quality SEII-Lecture 15
Software Project Management Fifth Edition
 The software systems must do what they are supposed to do. “do the right things”  They must perform these specific tasks correctly or satisfactorily.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Sept - Dec w1d11 Beyond Accuracy: What Data Quality Means to Data Consumers CMPT 455/826 - Week 1, Day 1 (based on R.Y. Wang & D.M. Strong)
An Introduction to Software Architecture
CSE 303 – Software Design and Architecture
Software Software is omnipresent in the lives of billions of human beings. Software is an important component of the emerging knowledge based service.
Copyright © Jerzy R. Nawrocki ISO 9126 and Non-functional Requirements Requirements.
Alignment of ATL and QVT © 2006 ATLAS Nantes Alignment of ATL and QVT Ivan Kurtev ATLAS group, INRIA & University of Nantes, France
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Composing Adaptive Software Authors Philip K. McKinley, Seyed Masoud Sadjadi, Eric P. Kasten, Betty H.C. Cheng Presented by Ana Rodriguez June 21, 2006.
UML Profiles Eclipse ECESIS Project The UML Profile technology SOFTEAM 144 Ave des Champs Elysées Paris, France
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
Usage of OCL April Usage of OCL for design guidelines of models Christian Hein, Fraunhofer FOKUS April 2006.
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
Other Quality Attributes Other Important Quality attributes Variability: a special form of modifiability. The ability of a system and its supporting artifacts.
ICare Software Architecture Description: Principles, Decisions and Contradictions Team A Aggarwal Ashutosh Alungh Suman Appiah Stella Baddam Bhaskar Baghaie.
Software Quality : The Elusive Target
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
12.1 Introduction Checklists are used as a technique to give status information in a formalized manner about all aspects of the test process. This chapter.
Software Methods Mö/ slide 1 Methods and Techniques of Software Quality Management ICEL Quality Management Systems: Methods and Techniques of Software.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
LESSON 3. Properties of Well-Engineered Software The attributes or properties of a software product are characteristics displayed by the product once.
CSSE Software Engineering Process and Practice Lecture 5 Q UALITY A SSURANCE.
UKTMF 27 th January 2010 Non-Functional Testing1 Non-Functional Testing Non-Functional Testing Why is this so often done badly or not done at all? Can.
CGI3: Current Status Common Goals and Infrastructures CGI3: Infrastructure Jonas Mellin.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Overview of SAIP and LSSA. Software Architecture in Practice Provides a set of techniques, not a prescriptive method for architectural design. Based on.
Science and Technology Norwegian University of NTNU Rolv Bræk, January Introduction to Systems Engineering by Rolv Bræk NTNU.
An Introduction to Metamodelling Eclipse ECESIS Project An Introduction to Metamodelling Principles & Fundamentals Department of Computer Science,
ISQB Software Testing Section Meeting 10 Dec 2012.
TOTAL QUALITY MANAGEMENT
What Do We Mean by Usability?
Non Functional Requirements (NFRs)
Rekayasa Perangkat Lunak
Quality Exercise 2 Instructions
Quality Exercise 2 Instructions
Software Quality Engineering
Rekayasa Perangkat Lunak
UNIT II.
Charakteristiky kvality
and Jose-Norberto Mazón University of Alicante
Software Quality Assurance Lecture 3
An Introduction to Software Architecture
Quality Factors.
ISO/IEC Systems and software Quality Requirements and Evaluation
Tomaž Špeh SURS TF SERV, Luxembourg,
Presentation transcript:

Modelling Support for Quality of Service Eclipse ECESIS Project Modelling Support for Quality of Service Department for Cooperative and Trusted Systems Information and Communication Technology, SINTEF, Forskningsveien 1, N-0314 Oslo, Norway

Modelling Support for Quality of Service Eclipse ECESIS Project Context of this work The present courseware has been elaborated in the context of the MODELWARE European IST FP6 project ( Co-funded by the European Commission, the MODELWARE project involves 19 partners from 8 European countries. MODELWARE aims to improve software productivity by capitalizing on techniques known as Model-Driven Development (MDD). To achieve the goal of large-scale adoption of these MDD techniques, MODELWARE promotes the idea of a collaborative development of courseware dedicated to this domain. The MDD courseware provided here with the status of open source software is produced under the EPL 1.0 license.

Modelling Support for Quality of Service Eclipse ECESIS Project Quality Software architecture defines a 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

Modelling Support for Quality of Service Eclipse ECESIS Project ISO 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.

Modelling Support for Quality of Service Eclipse ECESIS Project ISO External and Internal Quality Metrics Irrespective of context of use functionalityreliabilityusabilityefficiencymaintainability external and internal quality portability suitability accuracy interoperability security functionality compliance maturity fault tolerance recoverability reliability compliance understandability learnability operability attractiveness usability compliance time behaviour resource utilisation efficiency compliance analysability changeability stability testability maintainability compliance adaptability installability co-existence replaceability portability compliance

Modelling Support for Quality of Service Eclipse ECESIS Project 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.

Modelling Support for Quality of Service Eclipse ECESIS Project 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.

Modelling Support for Quality of Service Eclipse ECESIS Project 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.

Modelling Support for Quality of Service Eclipse ECESIS Project 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.

Modelling Support for Quality of Service Eclipse ECESIS Project 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.

Modelling Support for Quality of Service Eclipse ECESIS Project 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.

Modelling Support for Quality of Service Eclipse ECESIS Project 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

Modelling Support for Quality of Service Eclipse ECESIS Project 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

Modelling Support for Quality of Service Eclipse ECESIS Project 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.)

Modelling Support for Quality of Service Eclipse ECESIS Project Different Abstractions Peer-to-peer vs. layers QoS concepts on different layers are different, but related QoS mapping

Modelling Support for Quality of Service Eclipse ECESIS Project Quality of Service Support in Infrastructures 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 As target for model transformations / code generation

Modelling Support for Quality of Service Eclipse ECESIS Project 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

Modelling Support for Quality of Service Eclipse ECESIS Project ProblemspaceSolutionspace Infrastructure QoS reqs. QoS support Quality of Service Specifications to Support QoS management 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 in environment affect the agreed upon QoS? I.e., is adaptation needed?

Modelling Support for Quality of Service Eclipse ECESIS Project 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)? Commonly chosen approach: Stability threshold

Modelling Support for Quality of Service Eclipse ECESIS Project UML Profile for QoS - overview

Modelling Support for Quality of Service Eclipse ECESIS Project UML QoS profile

Modelling Support for Quality of Service Eclipse ECESIS Project QoS characteristics

Modelling Support for Quality of Service Eclipse ECESIS Project QoS value

Modelling Support for Quality of Service Eclipse ECESIS Project QoS contract

Modelling Support for Quality of Service Eclipse ECESIS Project Another contract

Modelling Support for Quality of Service Eclipse ECESIS Project QoS behaviour (adaptation)

Modelling Support for Quality of Service Eclipse ECESIS Project 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