Harmony: An Approach and Tool for
Combining Semi-formal and Formal
Notations in Software Specification
CS 791z Topics on Software Engineering
Instructor’s Research
April 19, 2004
1 / 28
Outline




2 / 28
Context
A Procedural Frame
The Harmony Tool
Conclusions
Context: The Harmony Project


Proposal of an approach for specifying timeconstrained systems (TCS) based on the
combined use of UML (graphical, semi-formal
notation) and Z++ (formal notation)
Topic placed at the confluence of three
paradigms:

object-orientation
formal specification

visual representation

3 / 28
Context: Why Integrate?

Combine benefits
 Graphical
notations easy to use
 Formal methods precise


4 / 28
Different aspects of the system need
different ways of description
Provide choices
Context: Research Space and Location
non OO
OO
non
RT
Z
RT
OOZ
formal
formal
UML
5 / 28
Topic location:
* formal, employing an OOZ variant
* OO development, UML-based
* RT modelling capability
Strategies for Integration

Integration of notations:
 Semi-formal/Formal
 Semi-formal/Semi-formal
 Formal/Formal

Types of semi-formal/formal integrations:
Derivation or (simple) formalization
 Complementary formalization
 Tight integration, involving two-way translations

6 / 28
Related Work

Similar approaches:
Jia’s AML
 Noe and Hartrum’s extension of Rational Rose
 France et al.’s blending of Octopus and Z
 Headway System’s RoZeLink
 Kim and Carrington’s UML/Object-Z combination


7 / 28
Our approach is distinct from all the above in at
least one major aspect: variant of Z involved,
provisions for dealing with RTS, tight integration
of notations, or type of supporting environment
Notations: UML






8 / 28
“Graphical language for visualizing, specifying,
constructing, and documenting the artifacts of softwareintensive systems” [G. Booch]
OMG standard notation for object modeling
Includes structural & behavioral model elements
Extension mechanisms: stereotypes, tagged values,
constraints
Support for RTS: events, signals, active classes, finitestate machines, timing marks and expressions
However, for rigorous development supplementary
formalization is necessary
Notations: UML - Example of Class Diagram
1
1
Pos itionDe te ctor
Alar m Sys te m
1
1
Ele vator
1
Door
1
1
*
CarButton
1
1
1
*
Spe cialCarButton
Gr oupIndicator
1
*
serves
1
Button
0..1
1
0..1
1
Floor
FloorButton
1
9 / 28
Indicator
Notations: UML - Example of State Diagram
movingUp
when(target_reached and
down_to_go)
entry: moveUp()
activity: goToTarget()
exit: stop()
when(target_reached
and up_to_go)
when(other_level_request
and up_to_go)
when(up_target)
stoppedToUp
when(no_requests)
entry: door.open()
activity: updateRequests()
exit: door.close()
when(level_request and up_to_go)
idle
activity: updateRequests()
when(level_request and down_to_go)
when(no_requests)
stoppedToDown
entry: door.open()
activity: updateRequests()
exit: door.close()
when(other_level_request
and down_to_go)
when(down_target)
when(target_reached
and down_to_go)
movingDown
10 / 28
entry: moveDown()
activity: goToTarget()
exit: stop()
when(target_reached
and up_to_go)
Notations: Z++




11 / 28
Created by Lano and Haughton
Essentially, extends Z with the class construct
Closer to implementation than other formal languages
Support for dealing with time in the HISTORY clause:
Temporal Logic or Real-Time Logic (RTL) formulae
Notations: Z++ Class
ZPP_Class ::=
12 / 28
CLASS Identifier [TypeParams]
[EXTENDS
Ancestors]
[TYPES
TypeDefs]
[FUNCTIONS AxiomaticDefs]
[OWNS
Locals]
[RETURNS
OpTypes]
[OPERATIONS OpTypes]
[INVARIANT Predicate]
[ACTIONS
Actions]
[HISTORY
History]
END CLASS
Translations UML/Z++: Overview




Formalization = UML to Z++ translation
Deformalization = Z++ to UML translation
Algorithms for automated translations have been
proposed
Formalization of both structure and behavior
Rules and principles for translating class diagrams
(algorithm AFCD)
 Rules and principles for translating state diagrams
(AFSD)


13 / 28
Principles for reverse translation (ADF)
A Procedural Frame



Series of activities in which model artifacts are
produced
Subset of UML used (“2+1 views”)
Artifacts:
UML elements: use case diagrams, scenarios,
sequence diagrams, class diagrams, and class
compounds
 Z++ specifications: Z++ classes and statements


Activities organized in stages

14 / 28
‘Regular’ and ‘irregular’ sequences of activities
A
Procedural
Frame
Requirements Set
1 Definition of
Use Cases
UC Collection
2 Elaboration of
Scenarios
SC Collection
3A Construction of
Class Diagrams
3B Specification of
Sequence Diagrams
CD Collection
SQD Collection
4A Elaboration of UML
Class Compounds
4B Elaboration of
Z++ Specification
5A
Formalization
UML Class
Compounds(COMP)
(CLS and CLSTD)
15 / 28
Integrated UML/Z++
Classes Collection
5B
Deformalization
Z++ Specification
(ZSPEC), a set of
Z++ classes (ZPPC)
Stage 1
Regular Flow
of Activities
1
Definition of
Use Cases
2
Elaboration
of Scenarios
Stage 2
Stage 3
Construction of
Class Diagrams
3A
3B
Stage 4
4A
Elaboration of UML
Class Compounds
4B
Stage 5
Elaboration of
Z++
Specification
Formalization
(UML to Z++)
5A
16 / 28
Specification
of Sequence
Diagrams
5B
Deformalization
(Z++ to UML)
Stage 1
Irregular Flow
of Activities
Definition of
Use Cases
1
Stage 2
Elaboration
of Scenarios
2
Stage 3
Construction of
Class Diagrams
3A
3B
Specification of
Sequence
Diagrams
Stage 4
Elaboration of
UMLClass
Compounds
4A
4B
Elaboration of
Z++ Specification
5A
5B
Deformalization
(Z++ to UML)
Stage 5
17 / 28
Formalization
(UML to Z++)
The Harmony Tool: Characteristics







18 / 28
Sustains the development of combined
UML/Z++ models
Operates on specification projects
Monolithic construction
Options for automated translations
Support for class compounds
Tandem mode of operation
Provisions for interfacing with external tools
Harmony: The Browser
19 / 28
Harmony: Project Pane
20 / 28
Harmony: New Element Selector & Legend Pane
21 / 28
Harmony: Toolboxes
22 / 28
Harmony: Project Loaded
23 / 28
Harmony: UML Space (Class Diagram)
1
1
Ele vator
Alar m Sys te m
+audioSignal()
+visualSignal()
#state : ElevatorState
#dir : Direction
#current : unsigned int
#target : unsigned int
#carRequests : unsigned int [ ]
#upFloorRequests : unsigned int [ ]
#dow nFloorRequests : unsigned int [ ]
+updateRequests()
+updateTarget()
+goToTarget()
+moveUp()
1
+moveDow n()
+stop()
1
1
1
*
1*
CarButton
-kind : SpecialCarButtonKind
+getButtonNumber() : unsigned int
+getKind() : SpecialCarButtonKind
#state : DoorState
1
1
+open()
+close()
+getState() : DoorState
1
Gr oupIndicator
serves
-size : unsigned int
1
1
#state : ButtonState
+setIndicator(in ind : unsigned int)
+resetIndicator(in ind : unsigned int)
+resetAll()
*
+press()
+turnOf f()
+getState() : ButtonState
Floor
0..1
1
0..1
1
Floor Button
24 / 28
Door
1
Button
+getKind() : FloorButtonKind
+getCurrentFloor() : unsigned int
+calculateSpeed() : double
Spe cialCarButton
-buttonNumber : unsigned int
-kind : FloorButtonKind
Pos itionDete ctor
-currentFloor : unsigned int
#kind : FloorKind
#floorNumber : unsigned int
#upButton : FloorButton
#dow nButton : FloorButton
+getKind() : FloorKind
+setFloorNumber(in f loorNumber : unsigned int)
+getUpButtonState() : ButtonState
+getDow nButtonState() : ButtonState
1
*
Indicator
#state : IndicatorState
#indicatorNumber : unsigned int
+turnOn()
+turnOf f()
+getState() : IndicatorState
Harmony: Z++ Space (Class Spec)
25 / 28
Harmony: Z++ Space (Timing Constraints)
26 / 28
Conclusions: Summary
Pragmatic semi-formal/formal combination
of notations
 Formalization of UML constructs in Z++
 Rigorous treatment of TCS via RTL
 Detailed design of the Harmony ISE
 Lightweight, rapid modeling process

27 / 28
Conclusions: Future Work (most on Andy )
Enhancement of algorithms
 Refinement of the tool’s functionality
 Implementation of Harmony
 Syntax checker for Z++
 More applications

28 / 28