Defining the Context of OCL Expressions

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

doi:10.1007/3-540-46852-8_27

Cited by 9 publications

(5 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Q r and Q clauses that are not included default to true and an omitted Tp r clause defaults to the operation's context, which is the system. The 9rpyh r clause allows all declarations to be made in a separate and single place, which is in line with the proposal of Cook et al [7], in contrast to standard use of the let construct in OCL, which form part of the expression. A more detailed description of the grammar and usage of Operation Schemas can be found in [27][34].…”

Section: Shudwlrq 6fkhpdv Dqg 2and/supporting

confidence: 53%

Using OCL and UML to Specify System Behavior

Sendall

Strohmeier

2002

Lecture Notes in Computer Science

View full text Add to dashboard Cite

$%675$&7 Use cases are an excellent tool for capturing behavioral requirements of software systems, but they are not an ideal work product for driving design activities. We believe that there is value from complementing use case descriptions with pre-and postcondition descriptions, not only to better support reasoning about system properties and a basis for testing and debugging, but also to better support a predictable decomposition level on which one can base a systematic transition to design. Nevertheless, we recognize that pre-and postcondition descriptions are not widely used in practice. We believe this is in part due to the formalism used. Either the formalism is too heavy to learn and use, or the formalism does not offer sufficient abstraction from the vocabulary of implementation.Via an example, the paper highlights our approach for specifying system behavior, which uses the Unified Modeling Language (UML) and its Object Constraint Language (OCL). We focus the paper on pre-and postconditions descriptions and in particular propose a number of enhancements and interpretations to OCL that we made while refining our approach. In particular, we describe a number of issues that cover areas such as the frame problem, incremental descriptions, structuring schemas, and events and exceptions. .(<:25'6 Unified Modeling Language, Object Constraint Language, Pre-and Postcondition Assertions, Software Specification, Requirements Analysis. ,QWURGXFWLRQSoftware development projects are subject to many factors, software and non-software related. It is a balancing act to get the right combination for a given project and its context-there are always trade-offs to make, according to priorities. For example, timeto-delivery and budget typically have a higher priority than rigor of development and quality assurance for most web-based systems [9], where the inverse is normally the case for systems that are human-life critical. There are more and more projects that are somewhere inbetween safety-critical at the one end and non-critical at the other end. We believe that there is an increasing need for approaches that can provide a reasonable level of quality assurance and rigor in development but still must obey a restrained schedule and budget. For example, at the mid-to-upper range there are many e-business applications, which are "24-7" and mission-critical. Our goal is to produce an approach for specifying reactive system behavior that can be used in the development of systems that lie in the mid-to-upper range. As a consequence, we have developed a software development method called Fondue [33] that covers the whole software development cycle, uses the UML notations, and is based on the Fusion process [6]. In this paper, we cover an important part of the analysis phase of Fondue.

show abstract

Section: Shudwlrq 6fkhpdv Dqg 2and/supporting

confidence: 53%

Using OCL and UML to Specify System Behavior

Sendall

Strohmeier

2002

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…If an OCL constraint is associated with a model element on level Mi then it refers the instances of this model element on level Mi−1 -in OCL, the 'context' ( [13]) of an invariant is an instance of the associated model element. In order to check a M1 level OCL constraint, either M0 level instances must be simulated as proposed in [31], or the OCL constraint must be translated into M0 level source code which evaluates the constraint at runtime as suggested in [18].…”

Section: Cocons Can Be Verified Already At the Same Meta-levelmentioning

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

“…Furthermore there is no mechanism for defining the context for OCL expressions in extensions to UML. In a separate paper [Cook99a] the context of OCL expressions is defined and a precise and flexible mechanisms for how to specify this context is proposed.…”

Section: Enhance the Abilities To Define Context Of Ocl Specificationsmentioning

confidence: 99%

The Amsterdam Manifesto on OCL

Cook¹,

Kleppe²,

Mitchell

et al. 2002

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

Abstract. In November 1998 the authors participated in a two-day workshop on the Object Constraint Language (OCL) in Amsterdam. The focus was to clarify issues about the semantics and the use of OCL, and to discuss useful and necessary extensions of OCL. Various topics have been raised and clarified. This manifesto contains the results of that workshop and the following work on these topics. Overview of OCL.

show abstract

Defining the Context of OCL Expressions

Cited by 9 publications

References 0 publications

Using OCL and UML to Specify System Behavior

Using OCL and UML to Specify System Behavior

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

The Amsterdam Manifesto on OCL

Contact Info

Product

Resources

About