Abstract not found

The duality of objects and relationships is so deeply embedded in our thinking that almost all modelling languages include it as a fundamental distinction. Yet there is evidence that the two are naturally complemented by a third, equally fundamental notion: that of roles. Although definitions of the role concept abound in the literature, we maintain that only few are truly original, and that even fewer acknowledge the intrinsic role of roles as intermediaries between relationships and the objects that engage in them. After discussing the major families of role conceptualizations, we present our own basic definition and demonstrate how it naturally accounts for many modelling issues, including multiple and dynamic classification, object collaboration, polymorphism, and substitutability. <3 2000 Elsevier Science B.V. All rights reserved.

Scenarios have been advocated as a means of improving requirements engineering yet few methods or tools exist to support scenario based RE. The paper reports a method and software assistant tool for scenario-based RE that integrates with use case approaches to object oriented development. The method and operation of the tool are illustrated with a financial system case study. Scenarios are used to represent paths of possible behaviour through a use case and these are investigated to elaborate requirements. The method commences by acquisition and modelling of a use case. The use case is then compared with a library of abstract models that represent different application classes. Each model is associated with a set of generic requirements for its class, hence, by identifying the class(es) to which the use case belongs, generic requirements can be reused. Scenario paths are automatically generated from use cases, then exception types are applied to normal event sequences to suggest possib...

Making an application secure is much harder than just adding a password protected login screen. This paper contains a collection of patterns to be used when dealing with application security. Secure Access Layer provides an interface for applications to use the security of the systems on which they are built. Single Access Point limits entry into the application through one single point. Check Point gives the developer a way to handle an unknown or changing security policy. Groups of users have different Roles that define what they can and cannot do. The global information about the user is distributed throughout the application with a Session. Finally, users are presented with either a Limited View of legal options or are given a Full View With Errors. These seven patterns work together to provide a security framework for building applications. This paper was submitted, accepted and workshopped at PLoP `97 Copyright 1998. All Rights Reserved. Permission granted to copy for the PLoPD...

There has been substantial recent interest in captured design expertise expressed as design patterns. Prevalent descriptions of these design patterns suffer from two demerits. Firstly, they capture specific instances of pattern deployment, rather than the essential pattern itself, thus the spirit of the pattern is often lost in the superfluous details of the specific instances described. Secondly, existing pattern descriptions rely upon relatively informal diagrammatic notations supplemented with natural language annotations. This can result in imprecision and ambiguity. This paper addresses these problems by separating the specification of patterns into three models (role, type, and class). The most abstract (role-centric) model presents patterns in their purest form, capturing their essential spirit without deleterious detail. A role-model is refined by a type-model (adding usuallydomain-specific constraints), which is further refined by a class-model (forming a concrete deployment). We utilise recent advances in visual modelling notation to achieve greater precision without resorting to obtuse mathematical symbols. A set-oriented view of state, operations, and instances is adopted, permitting their abstract presentation in models via this visual notation. This paper utilises these ideas in the unambiguous specification of a selection of prominent design patterns. The expectation is that precise visual pattern specification will firstly enable clear communication between domain experts and pattern writers (and ultimately pattern users), and secondly enable CASE tool support for design patterns, permitting the designer (pattern user) to operate at a higher level of abstraction without ambiguity.

Goal orientation is an increasingly recognized paradigm for eliciting, modeling, specifying and analyzing software requirements. Goals are statements of intent organized in AND/OR refinement structures; they range from high-level, strategic concerns to lowlevel, technical requirements on the software-to-be and assumptions on its environment. The operationalization of system goals into specifications of software services is a core aspect of the requirements elaboration process for which little systematic and constructive support is available. In particular, most formal methods assume such operational specifications to be given and focus on their a posteriori analysis. The paper considers a formal, constructive approach in which operational software specifications are built incrementally from higher-level goal formulations in a way that guarantees their correctness by construction. The operationalization process is based on formal derivation rules that map goal specifications to specifications of software operations; more specifically, these rules map real-time temporal logic specifications to sets of pre-, post- and trigger conditions. The rules define operationalization patterns that may be used for guiding and documenting the operationalization process while hiding all formal reasoning details; the patterns are formally proved correct once and for all. The catalog of operationalization patterns is structured according to a rich taxonomy of goal specification patterns. Our constructive approach to requirements elaboration requires a multiparadigm specification language that supports incremental reasoning about partial models. The paper also provides a formal semantics for goal operationalization and discusses several semantic features of our language that allow for such incremental reasoning.

A requirements specification defines the requirements for the future system at a conceptual level (i.e. class or type level). In contrast, a scenario represents a concrete example of current or future system usage. In early RE phases, scenarios are used to support the definition of high level requirements (goals) to be achieved by the new system. In many cases, those goals can to a large degree be elicited by observing, documenting and analysing scenarios about current system usage, i.e. the new system must often fulfil many of the functional and non-functional goals of the existing system. To support the elicitation and validation of the goals achieved by the existing system and to illustrate problems of the old system we propose to capture current system usage using rich media (e.g. video, speech, pictures etc.) and to interrelate those observations with the goal definitions. Thus, we particularly aim at making the abstraction process which leads to the definition of the conceptual models more transparent and traceable. More precisely, we relate the parts of the observations which have caused the definition of a goal or against which a goal was validated with the corresponding goal. These interrelations provide the basis for

CORE ...........................................................................................................................204 Deep Models .......................................................................................................................................205 Refactoring and Distillation ................................................................................................................205 17. Large-Scale Structure.................................................................................................................206 EVOLVING ORDER .........................................................................................................................208 SYSTEM METAPHOR [BECK 2000] .................................................................................................209 PLUGGABLE COMPONENTS.............................................................................................................210 ABSTRACT DOMAIN FRAMEWORK .................................................................................................212 RESPONSIBILITY LAYERS...............................................................................................................212 Large-Scale Structure, Unification Contexts, and Distillation ............................................................223 Refactoring Toward a Fitting Structure...............................................................................................225 Architecture, Architecture Teams, and Large-Scale Structure ............................................................227 18. Game Plans ..................................................................................................................................230 Looking Forward.....

Frameworks are an object-oriented reuse technique that are widely used in industry but not discussed much by the software engineering research community. They are a way of reusing design that is part of the reason that some object-oriented developers are so productive. This paper compares and contrasts frameworks with other reuse techniques, and describes how to use them, how to evaluate them, and how to develop them. It describe the tradeoffs involved in using frameworks, including the costs and pitfalls, and when frameworks are appropriate.

The Workflow Patterns Initiative was established with the aim of delineating the fundamental requirements that arise during business process modelling on a recurring basis and describe them in an imperative way. The first deliverable of this research project was a set of twenty patterns describing the control-flow perspective of workflow systems. Since their release, these patterns have been widely used by practitioners, vendors and academics alike in the selection, design and development of workflow systems [vdAtHKB03]. This paper presents the first systematic review of the original twenty control-flow patterns and provides a formal description of each of them in the form of a Coloured Petri-Net (CPN) model. It also identifies twenty three new patterns relevant to the control-flow perspective. Detailed context conditions and evaluation criteria are presented for each pattern and their implementation is assessed in fourteen commercial offerings including workflow and case handling systems, business process modelling formalisms and business process execution languages. 1