A Comparison of Six UML-Based Languages for Software

8/3/2019 A Comparison of Six UML-Based Languages for Software

http://slidepdf.com/reader/full/a-comparison-of-six-uml-based-languages-for-software 1/25

A Comparison of Six UML-Based

Languages for Software Process

Modeling Alexandru Cojocaru, group 248

Adriana Pop, group 248



Software process

• Software process = “the set of partially orderedprocess steps, with sets of related artifacts,human and computerized resources,organizational structures and constraints,intended to produce and maintain the requested

software deliverables” • Large number of factors => need for processmodeling



Software Process Modeling Languages(SPMLs)• Used to model software processes• First-generation – complexity, inflexibility,

multiplicity = > need for standardization• UML as a process modeling language• Different approaches:

▫ SPEM (OMG standard)

▫ PROMENADE▫ Di Nitto approach▫ Chou’s approach ▫ UML4SPM



Suitability of UML for softwaremodeling• Workflow patterns = generic, recurring

constructs used to evaluate business processlanguages

Workflow patterns perspectives Patterns representableusing UML 2.0

Control-flow (split, merge, etc.) 16 out of 20

Data patterns (data visibility, interaction, etc.) 18 out of 40

Resource patterns (work allocation, work status, etc.) 6 out of 43



UML weaknesses

• Executability

▫ Objective: to be able to test, execute and debugUML diagrams

▫ Progress:

Executable UML Foundation

UML4SPM (for SPMLs)

• Lack of formality

▫ Activity diagrams, used in SPMLs, have a formaldefinition



Process modeling languagerequirementsRequirement What is evaluated

Semantic richness Ability to express what is performed

during a development processConformity to the UML standard Degree of reuse of the UML

standard

Graphical representations Modeling clarity and support of multiple perspectives/views

Executability Support for model executionModularity Ability to combine different chunks

of processes

Formality Approaches used for verification, validation and analysis

Tooling support Tools that support the SPML



SPEM 1.1 - description

• OMG standard for software process modeling

• Replace by SPEM 2.0



SPEM 1.1 - evaluationRequirement Relation to SPEM 1.1

Semantic richness Could be improved

Conformity to UML Extension of a subset of UML 1.4Graphical representations

Customized Class, Activity and Use Case diagrams

Executability Out of scope

Modularity Supported ( Process Components), but manual unification

procedure is necessary

Formality Addressed by applying constraints to the UMLmetamodel

Tooling support Rational Process Workbench, IRIS Suite, SPEM Profile



SPEM 1.1 - discussion

• Advantages

▫ Based upon UML

• Disadvantages

▫ Many ambiguities

▫ Contemplative models (no execution support)



SPEM 2.0 - description

• OMG standard

• Evolution of SPEM 1.1

• Separates the aspects, contents and materials(Definitions) from their possible instantiations(Uses) in a particular model

• Provides 3 compliance points for tool providers



SPEM 2.0 - evaluationRequirement Relation to SPEM 2.0

Semantic richness Some improvements from SPEM 1.1

Conformity to UML Reuses UML 2.0 Infrastructure and Diagram Interchangespecifications

Graphical representations

Does not use UML diagrams. Proposes a behavioralmodel for describing the process workflow.

Executability Not addressed directly. Possible by mapping models to

other execution formalisms. Modularity Supported: Activity’s “Activity Use Kind” property,

Variability Element, Process Component

Formality Model-checking is possible

Tooling support Eclipse Process Framework, Rational Method Composer,

PRO3



SPEM 2.0 - discussion

• Advantages

▫ Clear separation between the contents of a methodand its possible uses

▫ Powerful mechanisms for extending processmodels and methods

• Disadvantages▫ Complex and hard to understand specification

▫ Weak support for executability



Di Nitto et al. Approach - description

• Aims at assessing the possibility of using asubset of UML as an executable PML.

• Comprises 2 main steps:

1st describing processes using UML diagrams

2nd translate UML diagrams into code



Di Nitto et al. Approach - evaluation

Requirement Relation to Di Nitto et al. Approach

Semantic richness UML 1.3 diagrams are used as a high level modelinglanguage.

Conformity to UML Process Constitutes modeled as UML 1.3 -> classes used by OPSS


Activity Diagrams modeling work flow and Classdiagrams associates process concepts with OPSS engine

Executability All diagrams used to generate code. Modularity Was not addressed

Formality No approach proposed for validating the process model.

Tooling support code generator transforming UML diagrams into Javacode used as input by OPSS



Di Nitto et al. Approach - discussion

• Advantages▫ Process constitutes easily defined by specializing a set

of predefined classed▫ Flow of work given in activity diagrams▫ Lifecycle of each entity defined by state machine

• Disadvantages▫ Activity and class diagrams have no links with each

other▫ Approach does not extends UML language nor itintroduces new concepts

▫ Weak point of executability: how information isdefined in activity diagrams, state machines and classdiagrams.



PROMENADE Approach - description

• PROcess-oriented Modelling and ENacment of software DEvelopment

• Defined in context of ComProLab project and based on UML 1.3

• Follows approach od Di Nitto et al.



PROMENADE Approach - discussion• Advantages

▫ Easy to model a process: specialize set of classes, defineprecedence graph(for tasks)

▫ Precedence rules described using declarative formalism• Disadvantages

▫ Modularity: combine many processes -> make all of sametype and inherit from predefined classes

▫ Avoid name clashes -> rename all classes that represent

same artifact▫ Modify the classes diagram, precedence graph has to bemodified

▫ No mechanism to execute process model provided▫ No tool provided



Chou’s Approach - description

• Proposes software process modeling languageconsisting of UML 1.4 diagrams and low level

language

• UML diagram used for process’s participantsunderstanding

• The process language is used to represent theprocess



Chou’s Approach - evaluationRequirement Relation to SPEM 2.0

Semantic richness Provided in term of UML 1.4 classes

Conformity to UML Language does not extend UML to define new conceptsGraphical representations

Use of P-activity diagrams and P-class diagrams(based onsubset of UML 1.4)

Executability Does not provide automatic generation of processprograms(have to e implemented by developers)

Modularity Was not addressed Formality No approach proposed for validating the process model.

Tooling support No prototype is provided



Chou’s Approach - discussion

• Advantages

▫ Process constitutes represented as instances of the

UML class metaclass

• Disadvantages

▫ Lack of automatic generation of process program



UML4SPM - description

• Developed in the context of the ModelWare andModelPlex European Projects.

• Allows definition of process models which can besimulated and executed without any transformation step.



UML4SPM - evaluationRequirement Relation to UML4SPM

Semantic richness Could be improved

Conformity to UML Comes in form of MOF2.0-compilant meta-model.UML4SPM Process structure package and UML4SPMFoundation package(subset of UML2.0 concepts)


Activity diagrams used to model sequencing of Softwareactivities and WorkProducts exchange between actions.

Executability 1st approach: reusing business process execution engines. 2nd

approach developing an operational semantics with an explicitExecution Model

Modularity CallBehaviourAction allows 2 activities to be interconnected.

Formality Reused UML 2.0 activity diagrams. -> formal semantics forUML 2.0

Tooling support UML4SPM editor and interpreter, both integrated intoEclipse



UML4SPM - discussion

• Advantages

▫ Deals only with Activity Diagrams

▫ Modularity addressed throughCallBehaviourAction

• Disadvantages

▫ UML 2.0 relatively new



Comparative Evaluation

• Rate approach

▫ 0 – requirement not supported

▫ 1 – partially supported

▫ 2 – fully supported



Comparative evaluation Approaches

SPEM 1.1 SPEM 2.0Di Nitto’set al.

PromenadeChou’sapproach

UML4SPM Requirements

Semantic

richness1 1 1 1 1 1

Conformity toUML

2 2 2 2 2 2

Graphicalrepresentations

2 1 2 2 2 1

Executability 0 0 2 0 1 2

Modularity 1 2 0 1 0 1

Formality 1 1 0 0 0 1

Tooling support 2 2 1 0 1 1

A Comparison of Six UML-Based Languages for Software

Documents

Transcript of A Comparison of Six UML-Based Languages for Software