|
Modifications
1) PathName Problem:
The Dresden grammar accepts strings like
T::S::Set(H)::R.
This clearly doesn't makes sense.
Modifications to grammar:
The production corresponding to PathTypeName
has been modified to disallow such strings.
2) FeatureCall Vs Feature
The older grammar accepted strings like
cab.allow()@pre.
This should not be allowed ie, method calls in time expressions should
not be allowed.
Modifications to grammar:
The FeatureCall non-terminal has been
modified. In the new grammar FeatureCall has been replaced by Feature.
3) Operators with same precedence
The Dresden grammar cannot handle expressions
containing two or more operators that are at the same precedence level.
Modifications to grammar:
We have changed OclBody, Expression,
LogicalExpression,
RelationalExpression, AdditiveExpression
and MultpilcativeExpression.
4)Literal
The earlier grammar allowed strings like
3.x()
as a valid logical expression.
Modifications to grammar:
PrimaryExpression and PostfixExpression.
New Things added
1) Qualified Aggregates
Aggregates are used to denote attribute
values of an object.
e.g. Person'(name => 'Ankur', age =>'20'
) denotes a Person object with attributes name (with value 'Ankur') and
age (with value 20).
Though the specification says that attribute
names in aggregate are optional but the current implementation requires
that the attribute names be present. Therefore, Person'(name=>'Ankur',age=>'20')
is acceptable but Person'('Ankur',20) is NOT acceptable. This has
been done so as to keep the grammar LALR(1).
Another problem with aggregates is that
we can't check for their "completeness" ie, in the running example, we
can't check whether name and age are the only attributes.
This is because of the limited support from ModelFacade.
The qualifying type of an aggregate is
optional but recommended.
2) Shorthand notation for denotation
of representive objects:
Example:
Person((name => 'Ankur', age =>20))
is equivalent to Person.allInstances->select(c ¦ c.all =(name =>
'Ankur', age =>'20')) ->any(true)
The tool handles such shorthands.
3) Exception Handling
Example:
Sends: ActorX::{Notification;ReturningCall_r
throws
ExceptionA_e, InsufficientNumStock}
.
.
.
Exceptions:
insufficientNumStock( i:item ,
quantityLeft: Natural) handlesBy
sender.events->includes(OutofStock_e((itemid
=> i.id))) &
warehouse.events->includes(OrderItem((id
=> i.id))
Exceptions are handled by the tool.
4) Sent as a shorthand
Example:
sender.sent(e) is equivalent
to sender.events->includes(e)
5) Aliases
Aliases are pure name substitutions. They are useful in defining concurrent
operations.
Example:
alias old : Money is
2 + x.y
or
old : Money is 2 + x.y
Aliases are declared in the Declared clause.
6) Shared Clause
Shared Clause declares all shared items.
Example:
Shared: Owns ; self.val ;
7) Time Expression
TimeExpression has been modified to accommodate
@preAu, @postAU and @rd (which is in addition the existing @pre and @post).
These are used for defining concurrent operations.
8) Rely Blocks
Rely blocks are helpful in a concurrent environment where a group of
effects relies on a certain condition that must remain true during
its execution.
Example:
rely x.y = 2 then
sender.events->include(
x)
fail
sender.events->exclude(x)
endre;
9) Functions and Predicates
Example:
Predicate: pred(a:Integer) ;
Body: a = 2;
Function: fun(a:Integer) : Boolean;
Function Body: fun(a:Integer) :
Boolean;
Declares: x : Integer ::= a * 2;
Post:
result =
a * x = 10;
Although the original specification doesn't
contains the Post: before result but this has been added in the
current implementation to avoid conflicts. Also the specification says
that functions and predicates are declared after the operation schema but
the current implementation requires functions and predicates to be defined
before the operation schema. This has been done to avoid multiple passes
over the AST.
Modifications to XMIParser
The XmiParser class had to be modified
in a number of ways to make it suitable for accepting Rose 2001 generated
XMI files (The earlier tool accepted Rose 98 generated XMI files). These
modifications, and some associated problems, are as follows:
1) Associations:
Rose 2001 uses a different approach (as
compared to Rose 98) for handling associations. The new approach, uses
the tag Foundation.Core.Association
for
identifying associations multiplicity is represented with Foundation.Data_Types.MultiplicityRange.upper
and Foundation.Data_Types.MultiplicityRange.lower
attributes
(the upper value of -1 is equivalent to * ). Whether
an association end is ordered or not depends on the value of the attribute
Foundation.Core.AssociationEnd.ordering
which
can be either ordered, unordered
or
sorted.Rose also suffixes Association
names with an intenal number within curly brackets. While storing associations
in the model care has to be taken to remove the suffix.
To incorporate these changes, handleAssociation,
parseAssociation
and parseAssociationEnd methods of XMIParser were modified.
2) Stereotypes:
Rose 2001 has changed its approach for
handling stereotypes. Now, the class definition does not contain
what its stereotype is. A new element of type Foundation.Extension_Mechanisms.Stereotype
is
used to describe stereotypes. This element has Foundation.Extension_Mechanisms.Stereotype.extendedElement
as an attribute. The attribute stores as children all classes that have
the given element (which is a stereotype) as their stereotype.
This required modifications to handleStereotype
method of XMIParser.
3) Inheriting attributes from all parent
classes
Rose 2001 stores all the direct parent
classes of a given class in the class itself as an attribute named Foundation.Core.Namespace.ownedElement.
To
accomodate this parseClass method of XMIParser was modified. |
