MODEL: MOdel DrivEn and quaLity

Summary

MODEL
MOdel DrivEn and quaLity

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

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

May 27, 2008

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

Summary

Summary

Target: to show a brief description of Model Driven Engineering,
and Quality-related approaches
MDE:
MDE in general
MDE in Software Engineering
Model Driven Architecture
Quality:
Quality as Performance of a SW
Quality as Reliability of a SW
Quality of a Model
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 assist
focusing on some aspects.
MDE:
everything is a model
systematic use of models as primary engineering artifacts throughout
the engineering lifecycle
Goals:
improve short term productivity (eg, number of features)
improve long term productivity (eg, reducing the rate at which
primary artefacts become obsolete)


Model Driven

MDE Intro

Model in Software Engineering

Goals
to increase developer conﬁdence in the software-to-be
to permit automatic check
to help complexity management
to permit elicitation of hidden requirements (eg. Alloy)
to reduce the software artefacts’ sensitivity for changes:
Personnel: information should be made easy accessible for others
than the initial creators of the software artefact.
Requirements change
Development platforms: models are useful to decouple the lifetime of
a software artefact from the development tool used for its initial
creation.


Model Driven

MDE Intro

MDE in Software Engineering
Developers represent designs using models that conform to an
appropriate metamodel which are then automatically transformed to
implementation by speciﬁc tools


Model Driven

MDE Intro

The Businness Logic - Domain Speciﬁc Languages

it’s a programming language or speciﬁcation language dedicated to a
particular problem domain (e.g queries for database, regular
expression for text search)
it provides a language with notation and concepts geared to the
domain
while models are tend to be designed for describing structures, DSL
are suitable to describe businness logic


Model Driven

MDA Overview

MDA: Model Driven Architecture

it’s a software design approach
first mentioned in 2001 by Object Management Group
provides a set of guidelines for structuring specifications expressed as
models
provides an approach in which systems are specified independently of
the platform that supports it
provides an approach for specifying platforms
viewpoints and Model


Model Driven

MDA Overview

MDA Overview

Viewpoints:
Computation Independent Viewpoint: it focuses on the environment
of the system and on the requirements
Platform Independent Viewpoint: it focuses on operations of the
system showing the part that does not change from one platform to
another.
Platform Speciﬁc Viewpoint: combines PIV with elements related to
a speciﬁc platform.


Model Driven

MDA Overview

MDA Overview

Models:
Computation Independent Model CIM: it’s a view of the system
from the CIV. It does not show details of the structure of the
system, but only its functionalities.
Platform Independent Model PIM: it’s a view of the system from the
platform independent viewpoint. with no implementation detail.
Platform Speciﬁc Model PSM: it’s a view of the system from the
Platform Speciﬁc Viewpoint, and contains technical concepts about
the structure of a platform.


Model Driven

MDA Overview

MDA Overview
Process:
CIM is deﬁned, generally by businness analyst.
CIM is transformed in PIM by an Enterprise Architect
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?

Quality is very difficult to understand
Trascendent view: quality is something that can be perceived but not
defined
Manufacturing view: Quality as conformance to product
specifications
User view: quality as fitnes for the user’s purspose
Value based: ability of the software to generate money
Product view: quality decomposed in several aspect related to the
product
From the point of view of the sw engineering, during the
development phase we can check only internal properties and
application model!



Quality Overview

Quality attributes

Performance
Reliability
Quality of the Model: not a real attribute but it deeply inﬂuences
software quality
Security
Safety
We’ll discuss only the ﬁrst 3 attributes.



Performance Analysis and Prediction

Software Performance

it is aﬀected by every aspect of the design
it is a serious problem that causes delay cost overruns, failures on
deployment
50% of the developers found performance problem at least on the
20% of their projects
Software Engineering needs to ﬁnd a way to analyse and predict
performance in advance, during the early stages of development




Performance Analysis and Prediction - Characteristic

Accuracy
Adaptability: it must tolerate architecture changes
Cost effectiveness: it should be less expensive than a prototype
Compositionary: Software has generally a hierarchical structure, it
should be able to use analysis on lower layers to predict performance
on higher layers
Scalability: it must be adaptable to software grain
Analizability: it have to show flows in architecture design
Universality: it must be adaptable to different technologies




Performance Analysis and Prediction- Approaches

Measurement Based
Model Based (eg, SPE, CB-SPE, PUMA)
Software Architecture Based




Measurement Based

commonest approach to performance evaluation
focus on quantitative evaluation of performance
done at run-time
it can be used only in the late phases of the development process or
when the system is complete
not suitable for projects in early stages
useful to evaluate performance of a middleware, to obtain data to
extend to an upcoming application
the developer/tester needs to deﬁne metrics (e.g, throughput,
response time, etc)




Model Based

the Design Model is annotated with performace speciﬁcation in the
early stages of developement
the system (or a part) can be emulated using Petri Nets or FSA
quantitative results from this model are used to predict performance
of the real system
it can be used in all the development stages. An already developed
component can replace a previously emulated one.
ArgoSPE is a tool for the performance evaluation of software
systems in the rst stages of the life-cycle




Software Performance Engineering

introduced for the ﬁrst time in 1990 by Smith and continuosly
developed
highly disciplined approach necessary to evaluate system performance
represents the entire collection of software engineering activities and
related analysis using during the software development cycle which
are directed to meeting performace requirements.
using SPE, software Architect can predict the performance of the
system without knowing the application details.




SPE - Domain and process

System operations, described using UML diagrams, reporting
performance requirements and workloads
Behaviours, described using Scenarios in UML diagrams
Workloads, deﬁning the frequency of initiation of diﬀerent system
operations
System Structure, the software components
Hardware and Software resources




SPE - Activities

Identify system operations and resources
Deﬁne and analize requirements, including throughput requirements,
using UML diagrams to describe system behaviours
Predict performance from scenarios, architecture and detailed
design, modeling the interaction of the system with the resources
(generally using petri-net or FSA)
Performance Testing on the already developed part of the system
Maintenance and Evolution: predict the eﬀect of potential changes
and additions




MB Approach - PUMA

it’s a toolset architecture able to translate UML and UML2 in an
intermediate model called Core Scenario Model
a CSM uses resources that can be active or passive, includes
software components
then CSM is translated to Layered Queueing Models or Petri Net
LQN and PN are then analyzed by common tools and a feedback
with design advice is provided.




PUMA - Flow




Component Based Software Engineering

Systems are composition of components
A Component Developer creates a component and declares its
properties
A System Assembler puts components together to obtain the whole
system
individual components are released once and for all with documented
properties
properties of the assembled system can be obtained in a
compositional way




MB Approaches - CB-SPE

developed by Bertolino and Mirandola
it consists of two layers:
Component Layer: a Component Developer creates a component
and declares the component predicted performance properties,
validated in isolation
Application Layer: a System Assembler identiﬁes Use Cases and
choose among the available components those who better fulﬁll the
settled performance requirements. Then, he can proceed with the
system annotation following RT-UML (RealTime-UML).




CB- SPE




CB-SPE Tool - Steps

UML editing is done using Argo-UML
The Model is transformed in XMI and processed by the Best-Worst
Case Analyzer that computes the bounds
XMI is now processed by the Model Generator that provides
Execution Graph (standalone performance model) and Queueing
Network Model (contention based)
the two models are solved; QN using Rapid Analysis of Queueing
System, and EG with a ad-hoc solver




Software Architecture Based Approach

A SA is the structure of the system, including components,
components interfaces and relationship between them. SA is focused
in the early design phase and represents the ﬁrst mapping from
requirements to computational components.
SA-based approch applies an existing SA analysis method like SAAM
(Software Architecture Analysis Method)




SPE and MDA

it’s necessary to change the goal of MDA from generating code to
generating a Performance Model
it uses Process Engineering Metamodel (SPEM) for annotation and
guidance.
it consists of the following steps:
Computation Independent Model is created and transformed in a
Platform Independent Model
PIM is annotated with performance annotation and Platform Model
guidance and translated in a Platform Speciﬁc Model.
the previous steps are conituously repeated for each platform (in
multi-layered system)
a Performance Model is created




SPE and MDA - Flow



Software Reliability


Ability of a computer program to perform its intended functions and
operations in a system’s environment, without experiencing failure.
it can be studied:
in the late stage of development using traditional Reliability Growth
in the early stage of development, using UML to predict future
reliability




Reliability Growth

it is a well-structured process of ﬁnding reliability problems by
testing, incorporating corrective actions (strategy) and monitoring
the increase of the product’s reliability throughout the test phases.
it deﬁnes Reliability Goals associated to failures
it’s used to determinate, with a managemente strategy:
if the stated Raliability Goal will be reached
when the Realiability Goal will be met
the associated cost to that Goal




Realiability Growth

Basic Reliability Tasks: reliability tests
MTBF: mean time before failure, result of BRT
Potential MTBF: mean time before failure that can be attained with
the current strategy



UML for Reliability

UML provides a common notational ground to represent and
validate software components as well as a complete system.
it’s possible to make the reliability analysis compatible with UML
artifacts using appropriate annotations
Cortellessa, Harshinder and Bojan Cukic propesed probabilistic
annotations for:
Use Case Diagrams (functional description, actors and scenarios)
Sequence Diagrams (interaction between components to complete a
task)
Deployment Diagrams (platform conﬁguration)




UML - UseCase with Annotations

Qn is the probability for user Un to access the system by requesting
certain services
Pu,f si the probabiliy for user Uu to ask for functionalies Ff .
with m the number of user types, the probabily of executing the use
case x is given by




UML - Sequence with Annotations 1

Cn are components
BP number of busy periods of the components




UML - Sequence with Annotations 2

θi,j ; probability of failure of component i in scenario j
θi : given failure probability for component i
BPi,j : number of busy periods of the component i in scenario j




UML - Deployment Diagrams

a way to evaluate reliability of comunication in distribuited software

ψ; failure probability over the connector




UML - Deployment Diagrams 2

ψl,m,j : reliability of the communication between l an m in scenario j.
ψi : failure probability over the connector i.
| interact(l,m,j) | : the number of interactions between component l
and m in SD j




Predicted Reliability of the System

pj: probability of the scenario j
θi : given failure probability for component i
ψl.i,j : reliability of the communication between l and i in scenario j.
BPi,j : number of busy periods of the component i in scenario j
| interact(l,i,j) | : the number of interactions between component l
and i in scenario j




Reliability Profile

proposed by Rodrigues et al in 2005.
lightweight extensions of UML, defining a set of stereotypes and
OCL constraints
it is consistent with MDA
it relies on LTSA, Labelled Transition System analyzer, which
provides scenario-based model synthesis and model checking
capabilities to support the analysis.
The UML Profile for Reliability is translated to XMI (XML Metadata
Intechange)
XMI is translated to an XML format compatible with LTSA




Reliability Proﬁle - Steps (1)

the steps are applied to a scenario speciﬁcation expressed as a collection
of :
Basic Message Sequence Charts: message exchange between
components
High Level Message Sequence Charts: sequencial composition of
BSMC




Reliability Proﬁle - Steps (2)

In the ﬁrst step, scenarios are annotated with the probability of
transition between scenarios and the reliability of the components
(probabilities sum to 1)
In the second step Labeled Transition System is computed from the
annotated scenario.
In the third and forth steps LTS is interpreted as a Markov Model
and reliability is predicted




Implied Scenarios

they are the result of specifying the behaviour of the system from a
global prospective while expecting the behaviour to be provided by
components having only a local system view
the existence of an implied scenario means that the system produces
a trace that reveals a mismatch between behaviour and architecture
with this tecnique, we can ﬁnd all the implied scenarios and promote
them 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 drive
engineering in software development.
We all know that in MDE, models are progressively reﬁned and
transformed into new models, or code.
We can suppose that the quality of the application to be, that usually we
can evaluate after the code generation, depends also on the quality of
models that we used in the ﬁrst phases of our software engineering.



Model Quality

Items determining quality of models

Quality of modeling language(s) used (eg. appropriateness for
domain/complexity)
Quality of tools used for modeling and transformations (eg.
compliance with the modeling languages/capability of combining
informations)
Knowledge of developers of the problem in hand and their
experience of modeling languages and tools in use
Quality of modeling processes used
Quality assurance techniques applied to discover faults or weakness



Empanada

EmpAnADa - Overview

EmpAnADa is a project (by Chaudron and Lange) that aims to develop
techniques to improve the quality of UML models.
Quality model relates primary use of models to purposes, and for
each purpose, the required characteristic(s)
After selecting quality characteristics, a set of measures are
identiﬁed to measure quality characteristics
Some metrics are traditionals OO metrics, other are model-speciﬁc
Metric-based approach, but metrics are mainly on DD level, and
don’t cover all purposes of modeling
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 the
previous figure, and analyze some aspects.
Complexity is defined as the effort required for understanding a model,
and is important for:
Communication
Comprehension
Modification



Empanada

Metrics - Rules: disambiguation

A metric is a mapping from the empirical domain to the numerical
domain, such that the its value reﬂects the level of some property of the
artifact.
Rules can be seen as special cases of metrics: they are mappings to a
binary value, true or false.
Rules are usually deﬁned for elements of artifacts (e.g. ’Abstract class X
must have a subclass’).



Empanada

EmpAnADa - Complexity metrics

For complexity, we have the ﬁve following proposed metrics:
Dynamicity (Complexity of a class’ internal behaviour)
DIT (Depth of Inheritance Tree)
Cohesion (parts of a class needed to perform a single task)
NCU
NUC



Empanada

Figure: Relations between metrics and rules and characteristics



Empanada

EmpAnADa - Issues

Cons:
Relations metrics - quality characteristics are often m2m
Relations often based on judgement (eg. ISO - IEEE hierarchies of
quality attributes)



Empanada

EmpAnADa - Tools to check quality

SAAT: The first tool developed within the EmpAnADa project was
the SAAT tool, that calculates metrics that combine information
from different UML diagram types, hence these metrics are specific
for UML.
Additionally the tool checks consistency and completeness rules to
identify defects in UML models. Currently the tool covers class
diagrams, sequence diagrams, state diagrams and use case diagrams.
MetricViev (Evolution): The goal of MetricView is to give more
insight into UML models by visualizing software metrics that have
been computed by another tool (for example SAAT) directly on top
of the graphical representation of the UML model.



Empanada

EmpAnADa - Tools to check quality
Export of the software architectures, created with Rational Rose
(UML modelling tool), to an interchange ﬁle (XMI)
The Software Architecture Analysis Tool (SAAT ) takes as input the
XMI ﬁle, and creates an analysis report
MetricView visualize these metrics (calculated by SAAT) in the UML
model (created with Rational Rose)



Empanada

EmpAnADa - SAAT
The tool consists of several components working together:
Parser (extracts the relevant architecture information from the
input file, XMI by Rational Rose)
Database Creator (creates a database and empty tables)
Database Filler (fills the database with the software architecture
information extracted from the .xmi file)
Database Checker (checks the database for incomplete
informations)
Analyser (executes the queries that are the actual architecture
analysis)
Statistic calculator (calculates some statistics on the results of the
analysis)
Statistic Filter (filters the result based on the statistics such that
only the elements with the outlying values remain)
Saat (control component that is used to configure the Software
Architecture)


Empanada



SDMetrics

SDMetrics

SDMetrics analyzes the structural properties of UML designs.
establishes quality benchmarks to identify potential design
problems early on
predicts relevant system qualities such fault-proneness or
maintainability to better focus review and testing efforts
increases system quality and quality assurance effectiveness, find
more faults earlier and save development cost
detect incomplete, incorrect, redundant, or inconsistent design
find style problems such as circular dependencies, violation of
naming conventions



Others Definition and MDE

Unhelkar quality definition

Unhelkar, in a book published in 2005, defines quality in three
dimensions:
Syntactical correctness
Semantic correctness and consistency
Aesthetics




Framework for quality of models and modeling languages

developed by Krogstie (et al.)
Quality goals deﬁned as relations between blocks
Some goals are objectively measured (eg. syntactic quality) - if ML
has a formal semantic
Some goals are not measurable (eg. domain modelers’ knowledge)




Quality aspects in MDE
Without quality assurance, models can become complex, incomplete,
inconsistent with each other, and difficult to maintain. For these
reasons is important to early detect faults in models.
There are two main quality criteria in MDE:
Transformability: models must have ability to be transformed in
models of greater detail, and to executable pieces of code. It can be
decomposed into:
Completeness (correct according to the domain)
Relevance (containing no extra elements)
Precision for transformation
Well-formedness or compliance to the model’s metamodel
Modifiability: changes made to requirement must be propagated and
rendered correctly into the models, and reflected in the code. It can
be decomposed into:
Traceability
Well-designedness (or ”not being too complex”)




Quality aspects in MDE
Finally, we have that quality in MDE covers diﬀerent aspects that can be
grouped as follows:
Technical factors:
Complexity of languages and their metamodels
Transformability of models
Capabilities of tools
Psychological factors:
Learnability
Familiarity with the language
Ease of interpretation
HCI factors
Usability
Aesthetics aspects
Organizational factors
Domain of modeling
Goals of modeling

Conclusion

Part III

Conclusion


Conclusion

Conclusion

Quality is a non-functional requirements difficult to understand, which
can be analyzed form different points of view:
Performance: using UML annotation is possible to evaluate and
predict performance also in early stages of developing, permitting
the change of the design model of the application.
Reliability: using UML annotation and stereotypes, and a bit of
calculus of Probability, is possible to predict reliability issues in early
phases.
Quality of a Model: quality of a model deeply influeces quality of
software. Tools are able to check for model consistency and quality


Conclusion

References - 1
Woodside, Franks, Petriu - The Future of Software Performance
Engineering
Hill, Tambe, Gokhale - Model-driven Engineering for
Development-time QoS Validation of Component-based Software
Systems
Mohagheghi, Aagedal - Evaluating Quality in Model-Driven
Engineering
Becker, Gunske, Mirandola, Overhage - Performance Prediction of
Component-Based Systems
Lange, Chaudron - Managing Model Quality in UML-based Software
Development
Bertolino, Mirandola - Towards Component-Based Software
Performance Engineering


Conclusion

References - 2

Cortellessa, Singh, Cukic - Early reliability assessment of UML based
software models
Rodrigues, Roberts, Emmerich, Skene - Reliability Support for the
Model Driven Architecture
Bertolino, Mirandola - CB-SPE Tool: Putting Component-Based
Performance Engineering into Pratice
Woodside, Petriu et al. - Performance by Uniﬁed Model Analysis


MODEL: MOdel DrivEn and quaLity

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to MODEL: MOdel DrivEn and quaLity

Similar to MODEL: MOdel DrivEn and quaLity (20)

MODEL: MOdel DrivEn and quaLity