MODEL: MOdel DrivEn and quaLity

Summary

MODELMOdel DrivEn and quaLity

Antonio Troina [708267], Federico Villa [720492]{antonio.troina , federico.villa}@mail.polimi.it

Argomenti Avanzati di Ingegneria del Software - Politecnico di Milanohttp://www.polimi.it

May 27, 2008

MODEL Argomenti Avanzati di Ingegneria del Software - Politecnico di Milano http://www.polimi.it

http://www.polimi.it


Summary

Summary

I Target: to show a brief description of Model Driven Engineering,and Quality-related approaches

I MDE:I MDE in generalI MDE in Software EngineeringI Model Driven Architecture

I Quality:I Quality as Performance of a SWI Quality as Reliability of a SWI Quality of a Model

I Conclusions and References



Model Driven

Part I

Model Driven Engineering



Model Driven

MDE Intro

MDE

Model:Abstract Rappresentation of Reality, that hides some detail to assistfocusing on some aspects.MDE:

I everything is a model

I systematic use of models as primary engineering artifacts throughoutthe engineering lifecycle

I Goals:I improve short term productivity (eg, number of features)I improve long term productivity (eg, reducing the rate at which

primary artefacts become obsolete)



Model Driven

MDE Intro

Model in Software Engineering

Goals

I to increase developer confidence in the software-to-be

I to permit automatic check

I to help complexity management

I to permit elicitation of hidden requirements (eg. Alloy)

I to reduce the software artefacts’ sensitivity for changes:I Personnel: information should be made easy accessible for others

than the initial creators of the software artefact.I Requirements changeI Development platforms: models are useful to decouple the lifetime of

a software artefact from the development tool used for its initialcreation.



Model Driven

MDE Intro

MDE in Software EngineeringDevelopers represent designs using models that conform to anappropriate metamodel which are then automatically transformed toimplementation by specific tools



Model Driven

MDE Intro

The Businness Logic - Domain Specific Languages

I it’s a programming language or specification language dedicated to aparticular problem domain (e.g queries for database, regularexpression for text search)

I it provides a language with notation and concepts geared to thedomain

I while models are tend to be designed for describing structures, DSLare suitable to describe businness logic



Model Driven

MDA Overview

MDA: Model Driven Architecture

I it’s a software design approach

I first mentioned in 2001 by Object Management Group

I provides a set of guidelines for structuring specifications expressed asmodels

I provides an approach in which systems are specified independently ofthe platform that supports it

I provides an approach for specifying platforms

I viewpoints and Model



Model Driven

MDA Overview

MDA Overview

Viewpoints:

I Computation Independent Viewpoint: it focuses on the environmentof the system and on the requirements

I Platform Independent Viewpoint: it focuses on operations of thesystem showing the part that does not change from one platform toanother.

I Platform Specific Viewpoint: combines PIV with elements related toa specific platform.



Model Driven

MDA Overview

MDA Overview

Models:

I Computation Independent Model CIM: it’s a view of the systemfrom the CIV. It does not show details of the structure of thesystem, but only its functionalities.

I Platform Independent Model PIM: it’s a view of the system from theplatform independent viewpoint. with no implementation detail.

I Platform Specific Model PSM: it’s a view of the system from thePlatform Specific Viewpoint, and contains technical concepts aboutthe structure of a platform.



Model Driven

MDA Overview

MDA OverviewProcess:

I CIM is defined, generally by businness analyst.I CIM is transformed in PIM by an Enterprise ArchitectI PIM is transformed in a PSM by a platform specialist



Quality Sofware Performace Sofware Reliability Model Quality

Part II

Quality




Quality Overview

What is Software Quality?

I Quality is very difficult to understandI Trascendent view: quality is something that can be perceived but not

definedI Manufacturing view: Quality as conformance to product

specificationsI User view: quality as fitnes for the user’s pursposeI Value based: ability of the software to generate moneyI Product view: quality decomposed in several aspect related to the

product

I From the point of view of the sw engineering, during thedevelopment phase we can check only internal properties andapplication model!




Quality Overview

Quality attributes

I Performance

I Reliability

I Quality of the Model: not a real attribute but it deeply influencessoftware quality

I Security

I Safety

We’ll discuss only the first 3 attributes.




Performance Analysis and Prediction

Software Performance

I it is affected by every aspect of the design

I it is a serious problem that causes delay cost overruns, failures ondeployment

I 50% of the developers found performance problem at least on the20% of their projects

I Software Engineering needs to find a way to analyse and predictperformance in advance, during the early stages of development





Performance Analysis and Prediction - Characteristic

I Accuracy

I Adaptability: it must tolerate architecture changes

I Cost effectiveness: it should be less expensive than a prototype

I Compositionary: Software has generally a hierarchical structure, itshould be able to use analysis on lower layers to predict performanceon higher layers

I Scalability: it must be adaptable to software grain

I Analizability: it have to show flows in architecture design

I Universality: it must be adaptable to different technologies





Performance Analysis and Prediction- Approaches

I Measurement Based

I Model Based (eg, SPE, CB-SPE, PUMA)

I Software Architecture Based





Measurement Based

I commonest approach to performance evaluation

I focus on quantitative evaluation of performance

I done at run-time

I it can be used only in the late phases of the development process orwhen the system is complete

I not suitable for projects in early stages

I useful to evaluate performance of a middleware, to obtain data toextend to an upcoming application

I the developer/tester needs to define metrics (e.g, throughput,response time, etc)





Model Based

I the Design Model is annotated with performace specification in theearly stages of developement

I the system (or a part) can be emulated using Petri Nets or FSA

I quantitative results from this model are used to predict performanceof the real system

I it can be used in all the development stages. An already developedcomponent can replace a previously emulated one.

I ArgoSPE is a tool for the performance evaluation of softwaresystems in the rst stages of the life-cycle





Software Performance Engineering

I introduced for the first time in 1990 by Smith and continuoslydeveloped

I highly disciplined approach necessary to evaluate system performance

I represents the entire collection of software engineering activities andrelated analysis using during the software development cycle whichare directed to meeting performace requirements.

I using SPE, software Architect can predict the performance of thesystem without knowing the application details.





SPE - Domain and process

I System operations, described using UML diagrams, reportingperformance requirements and workloads

I Behaviours, described using Scenarios in UML diagrams

I Workloads, defining the frequency of initiation of different systemoperations

I System Structure, the software components

I Hardware and Software resources





SPE - Activities

I Identify system operations and resources

I Define and analize requirements, including throughput requirements,using UML diagrams to describe system behaviours

I Predict performance from scenarios, architecture and detaileddesign, modeling the interaction of the system with the resources(generally using petri-net or FSA)

I Performance Testing on the already developed part of the system

I Maintenance and Evolution: predict the effect of potential changesand additions





MB Approach - PUMA

I it’s a toolset architecture able to translate UML and UML2 in anintermediate model called Core Scenario Model

I a CSM uses resources that can be active or passive, includessoftware components

I then CSM is translated to Layered Queueing Models or Petri Net

I LQN and PN are then analyzed by common tools and a feedbackwith design advice is provided.





PUMA - Flow





Component Based Software Engineering

I Systems are composition of components

I A Component Developer creates a component and declares itsproperties

I A System Assembler puts components together to obtain the wholesystem

I individual components are released once and for all with documentedproperties

I properties of the assembled system can be obtained in acompositional way





MB Approaches - CB-SPE

I developed by Bertolino and Mirandola

I it consists of two layers:I Component Layer: a Component Developer creates a component

and declares the component predicted performance properties,validated in isolation

I Application Layer: a System Assembler identifies Use Cases andchoose among the available components those who better fulfill thesettled performance requirements. Then, he can proceed with thesystem annotation following RT-UML (RealTime-UML).





CB- SPE





CB-SPE Tool - Steps

I UML editing is done using Argo-UML

I The Model is transformed in XMI and processed by the Best-WorstCase Analyzer that computes the bounds

I XMI is now processed by the Model Generator that providesExecution Graph (standalone performance model) and QueueingNetwork Model (contention based)

I the two models are solved; QN using Rapid Analysis of QueueingSystem, and EG with a ad-hoc solver





Software Architecture Based Approach

I A SA is the structure of the system, including components,components interfaces and relationship between them. SA is focusedin the early design phase and represents the first mapping fromrequirements to computational components.

I SA-based approch applies an existing SA analysis method like SAAM(Software Architecture Analysis Method)





SPE and MDA

I it’s necessary to change the goal of MDA from generating code togenerating a Performance Model

I it uses Process Engineering Metamodel (SPEM) for annotation andguidance.

I it consists of the following steps:I Computation Independent Model is created and transformed in a

Platform Independent ModelI PIM is annotated with performance annotation and Platform Model

guidance and translated in a Platform Specific Model.I the previous steps are conituously repeated for each platform (in

multi-layered system)I a Performance Model is created





SPE and MDA - Flow




Software Reliability


I Ability of a computer program to perform its intended functions andoperations in a system’s environment, without experiencing failure.

I it can be studied:I in the late stage of development using traditional Reliability GrowthI in the early stage of development, using UML to predict future

reliability





Reliability Growth

I it is a well-structured process of finding reliability problems bytesting, incorporating corrective actions (strategy) and monitoringthe increase of the product’s reliability throughout the test phases.

I it defines Reliability Goals associated to failures

I it’s used to determinate, with a managemente strategy:I if the stated Raliability Goal will be reachedI when the Realiability Goal will be metI the associated cost to that Goal





Realiability Growth

I Basic Reliability Tasks: reliability tests

I MTBF: mean time before failure, result of BRT

I Potential MTBF: mean time before failure that can be attained withthe current strategy





UML for Reliability

I UML provides a common notational ground to represent andvalidate software components as well as a complete system.

I it’s possible to make the reliability analysis compatible with UMLartifacts using appropriate annotations

I Cortellessa, Harshinder and Bojan Cukic propesed probabilisticannotations for:

I Use Case Diagrams (functional description, actors and scenarios)I Sequence Diagrams (interaction between components to complete a

task)I Deployment Diagrams (platform configuration)





UML - UseCase with Annotations

I Qn is the probability for user Un to access the system by requestingcertain services

I Pu,f si the probabiliy for user Uu to ask for functionalies Ff .

I with m the number of user types, the probabily of executing the usecase x is given by





UML - Sequence with Annotations 1

I Cn are components

I BP number of busy periods of the components





UML - Sequence with Annotations 2

I θi,j ; probability of failure of component i in scenario j

I θi : given failure probability for component i

I BPi,j : number of busy periods of the component i in scenario j





UML - Deployment Diagrams

I a way to evaluate reliability of comunication in distribuited software

I ψ; failure probability over the connector





UML - Deployment Diagrams 2

I ψl,m,j : reliability of the communication between l an m in scenario j.

I ψi : failure probability over the connector i.

I | interact(l,m,j) | : the number of interactions between component land m in SD j





Predicted Reliability of the System

I pj: probability of the scenario j

I θi : given failure probability for component i

I ψl.i,j : reliability of the communication between l and i in scenario j.

I BPi,j : number of busy periods of the component i in scenario j

I | interact(l,i,j) | : the number of interactions between component land i in scenario j





Reliability Profile

I proposed by Rodrigues et al in 2005.

I lightweight extensions of UML, defining a set of stereotypes andOCL constraints

I it is consistent with MDA

I it relies on LTSA, Labelled Transition System analyzer, whichprovides scenario-based model synthesis and model checkingcapabilities to support the analysis.

I The UML Profile for Reliability is translated to XMI (XML MetadataIntechange)

I XMI is translated to an XML format compatible with LTSA





Reliability Profile - Steps (1)

the steps are applied to a scenario specification expressed as a collectionof :

I Basic Message Sequence Charts: message exchange betweencomponents

I High Level Message Sequence Charts: sequencial composition ofBSMC





Reliability Profile - Steps (2)

I In the first step, scenarios are annotated with the probability oftransition between scenarios and the reliability of the components(probabilities sum to 1)

I In the second step Labeled Transition System is computed from theannotated scenario.

I In the third and forth steps LTS is interpreted as a Markov Modeland reliability is predicted





Implied Scenarios

I they are the result of specifying the behaviour of the system from aglobal prospective while expecting the behaviour to be provided bycomponents having only a local system view

I the existence of an implied scenario means that the system producesa trace that reveals a mismatch between behaviour and architecture

I with this tecnique, we can find all the implied scenarios and promotethem to useful scenarios or to delete them




Model Quality

A short brief

At the very beginning we saw what a model is, and how it can driveengineering in software development.We all know that in MDE, models are progressively refined andtransformed into new models, or code.We can suppose that the quality of the application to be, that usually wecan evaluate after the code generation, depends also on the quality ofmodels that we used in the first phases of our software engineering.




Model Quality

Items determining quality of models

I Quality of modeling language(s) used (eg. appropriateness fordomain/complexity)

I Quality of tools used for modeling and transformations (eg.compliance with the modeling languages/capability of combininginformations)

I Knowledge of developers of the problem in hand and theirexperience of modeling languages and tools in use

I Quality of modeling processes used

I Quality assurance techniques applied to discover faults or weakness




Empanada

EmpAnADa - Overview

EmpAnADa is a project (by Chaudron and Lange) that aims to developtechniques to improve the quality of UML models.

I Quality model relates primary use of models to purposes, and foreach purpose, the required characteristic(s)

I After selecting quality characteristics, a set of measures areidentified to measure quality characteristics

I Some metrics are traditionals OO metrics, other are model-specific

I Metric-based approach, but metrics are mainly on DD level, anddon’t cover all purposes of modeling

I Relations metrics/quality-characteristics are often m2m




Empanada

Figure: Quality Model in EmpAnADa




Empanada

EmpAnADa - Characteristic Example

We can choose, for instance, the Complexity characteristic, from theprevious figure, and analyze some aspects.Complexity is defined as the effort required for understanding a model,and is important for:

I Communication

I Comprehension

I Modification




Empanada

Metrics - Rules: disambiguation

A metric is a mapping from the empirical domain to the numericaldomain, such that the its value reflects the level of some property of theartifact.Rules can be seen as special cases of metrics: they are mappings to abinary value, true or false.Rules are usually defined for elements of artifacts (e.g. ’Abstract class Xmust have a subclass’).




Empanada

EmpAnADa - Complexity metrics

For complexity, we have the five following proposed metrics:

I Dynamicity (Complexity of a class’ internal behaviour)

I DIT (Depth of Inheritance Tree)

I Cohesion (parts of a class needed to perform a single task)

I NCU

I NUC




Empanada

Figure: Relations between metrics and rules and characteristics




Empanada

EmpAnADa - Issues

Cons:

I Relations metrics - quality characteristics are often m2m

I Relations often based on judgement (eg. ISO - IEEE hierarchies ofquality attributes)




Empanada

EmpAnADa - Tools to check quality

I SAAT: The first tool developed within the EmpAnADa project wasthe SAAT tool, that calculates metrics that combine informationfrom different UML diagram types, hence these metrics are specificfor UML.Additionally the tool checks consistency and completeness rules toidentify defects in UML models. Currently the tool covers classdiagrams, sequence diagrams, state diagrams and use case diagrams.

I MetricViev (Evolution): The goal of MetricView is to give moreinsight into UML models by visualizing software metrics that havebeen computed by another tool (for example SAAT) directly on topof the graphical representation of the UML model.




Empanada

EmpAnADa - Tools to check quality

I Export of the software architectures, created with Rational Rose(UML modelling tool), to an interchange file (XMI)

I The Software Architecture Analysis Tool (SAAT ) takes as input theXMI file, and creates an analysis report

I MetricView visualize these metrics (calculated by SAAT) in the UMLmodel (created with Rational Rose)




Empanada

EmpAnADa - SAATThe tool consists of several components working together:

I Parser (extracts the relevant architecture information from theinput file, XMI by Rational Rose)

I Database Creator (creates a database and empty tables)I Database Filler (fills the database with the software architecture

information extracted from the .xmi file)I Database Checker (checks the database for incomplete

informations)I Analyser (executes the queries that are the actual architecture

analysis)I Statistic calculator (calculates some statistics on the results of the

analysis)I Statistic Filter (filters the result based on the statistics such that

only the elements with the outlying values remain)I Saat (control component that is used to configure the Software

Architecture)




Empanada




Empanada




SDMetrics

SDMetrics

SDMetrics analyzes the structural properties of UML designs.

I establishes quality benchmarks to identify potential designproblems early on

I predicts relevant system qualities such fault-proneness ormaintainability to better focus review and testing efforts

I increases system quality and quality assurance effectiveness, findmore faults earlier and save development cost

I detect incomplete, incorrect, redundant, or inconsistent design

I find style problems such as circular dependencies, violation ofnaming conventions




Others Definition and MDE

Unhelkar quality definition

Unhelkar, in a book published in 2005, defines quality in threedimensions:

I Syntactical correctness

I Semantic correctness and consistency

I Aesthetics





Framework for quality of models and modeling languages

developed by Krogstie (et al.)

I Quality goals defined as relations between blocks

I Some goals are objectively measured (eg. syntactic quality) - if MLhas a formal semantic

I Some goals are not measurable (eg. domain modelers’ knowledge)





Quality aspects in MDEWithout quality assurance, models can become complex, incomplete,inconsistent with each other, and difficult to maintain. For thesereasons is important to early detect faults in models.There are two main quality criteria in MDE:

I Transformability: models must have ability to be transformed inmodels of greater detail, and to executable pieces of code. It can bedecomposed into:

I Completeness (correct according to the domain)I Relevance (containing no extra elements)I Precision for transformationI Well-formedness or compliance to the model’s metamodel

I Modifiability: changes made to requirement must be propagated andrendered correctly into the models, and reflected in the code. It canbe decomposed into:

I TraceabilityI Well-designedness (or ”not being too complex”)





Quality aspects in MDEFinally, we have that quality in MDE covers different aspects that can begrouped as follows:

I Technical factors:I Complexity of languages and their metamodelsI Transformability of modelsI Capabilities of tools

I Psychological factors:I LearnabilityI Familiarity with the languageI Ease of interpretation

I HCI factorsI UsabilityI Aesthetics aspects

I Organizational factorsI Domain of modelingI Goals of modeling



Conclusion

Part III

Conclusion



Conclusion

Conclusion

Quality is a non-functional requirements difficult to understand, whichcan be analyzed form different points of view:

I Performance: using UML annotation is possible to evaluate andpredict performance also in early stages of developing, permittingthe change of the design model of the application.

I Reliability: using UML annotation and stereotypes, and a bit ofcalculus of Probability, is possible to predict reliability issues in earlyphases.

I Quality of a Model: quality of a model deeply influeces quality ofsoftware. Tools are able to check for model consistency and quality



Conclusion

References - 1

I Woodside, Franks, Petriu - The Future of Software PerformanceEngineering

I Hill, Tambe, Gokhale - Model-driven Engineering forDevelopment-time QoS Validation of Component-based SoftwareSystems

I Mohagheghi, Aagedal - Evaluating Quality in Model-DrivenEngineering

I Becker, Gunske, Mirandola, Overhage - Performance Prediction ofComponent-Based Systems

I Lange, Chaudron - Managing Model Quality in UML-based SoftwareDevelopment

I Bertolino, Mirandola - Towards Component-Based SoftwarePerformance Engineering



Conclusion

References - 2

I Cortellessa, Singh, Cukic - Early reliability assessment of UML basedsoftware models

I Rodrigues, Roberts, Emmerich, Skene - Reliability Support for theModel Driven Architecture

I Bertolino, Mirandola - CB-SPE Tool: Putting Component-BasedPerformance Engineering into Pratice

I Woodside, Petriu et al. - Performance by Unified Model Analysis



Date post:	19-Jan-2015
Category:	Documents
Upload:	federico-villa
View:	831 times
Download:	2 times

MODEL: MOdel DrivEn and quaLity

Documents