The Amsterdam Manifesto on OCL

Cook, Steve; Kleppe, Anneke; Mitchell, Richard; Rumpe, Bernhard; Warmer, Jos; Wills, Alan

doi:10.1007/3-540-45669-4_7

Cited by 29 publications

(8 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Since b1 implies (b2 implies b3) is equivalent to (b1 and b2) implies b3 [8], such expressions can be restated by replacing all occurrences of the implies operator, except for the last one, by the and operator. Figure 1 shows an example of an "implies chain", excerpted from the UML 2.0 Superstructure Specification [33], that was slightly modified to remove errors present in its original version.…”

Section: Implies Chainmentioning

confidence: 99%

Refactoring object constraint language specifications

Correa

Werner

2006

Softw Syst Model

View full text Add to dashboard Cite

The object constraint language (OCL) plays an important role in the elaboration of precise models. Although OCL was designed to be both formal and simple, OCL specifications may be difficult to understand and evolve, particularly those containing complex or duplicated expressions. In this paper, we discuss how refactoring techniques can be applied in order to improve the understandability and maintainability of OCL specifications. In particular, we present several potentially bad constructions often found in OCL specifications and a collection of refactorings that can be applied to replace such constructions by better ones. We also briefly discuss how refactorings can be automated and how model regression testing can be used to increase our confidence that the semantics of an OCL specification has been preserved after manually performed refactorings.

show abstract

Section: Implies Chainmentioning

confidence: 99%

Refactoring object constraint language specifications

Correa

Werner

2006

Softw Syst Model

View full text Add to dashboard Cite

show abstract

“…The OCL expression given above does not consider composition (or aggregation, or PackagableElement): if the component 'B' in figure 2 does not manage personal data, but 'B' is composed of other components among whom at least one component handles personal data, than 'A' must not invoke an operation of an interface of 'B'. Furthermore, the OCL expression given above does not handle recursion (a solution is described in [12]): 'A' must not invoke an operation of an interface of 'B' if 'B' calls another component 'C' handling personal data in order to execute A's call. Again, some additional OCL expressions are needed which consider composition and recursion.…”

Section: Uml-specific Semantics Of Accessible To Coconsmentioning

confidence: 99%

Keeping track of crosscutting requirements in UML models via context-based constraints

Bübl

2006

Companion to the 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems, Languages, and Applications

View full text Add to dashboard Cite

One crosscutting requirement (also called aspect) affects several parts of a software system. Handling aspects is well understood at source-code level or at runtime. However, only a few aspectoriented approaches handle other software artefact types, like UML models, configuration files, or database schema definitions. Instead of re-writing the same aspect newly for each artefact type, this paper suggests to write down aspects independent of artefact types.But, wait a minute: Where do we weave in an aspect if its pointcut doesn't refer to artefact details? Which places does such an aspect affect? This paper suggests expressing aspects via ContextBased Constraints (CoCons). They select their constrained system elements according to the element's context. For instance, CoCons affect all system elements used in a certain department, workflow, or location. CoCons are easy to grasp for users and customers because they express business requirements without referring to technical details. This paper focuses on how to express crosscutting requirements in UML models via CoCons and compares CoCons to the Object Constraint Language OCL.

show abstract

“…Currently, the Unified Modeling Language (UML) [23] is the standard language in software development. However UML models only provide a good view of the software architecture [16] and they are imprecise because diagram-based notation is not expressive enough [12] . The expressiveness of the modeling technique used (for example the notation, etc.)…”

Section: Introductionmentioning

confidence: 99%