• Aucun résultat trouvé

Abstract of the Keynote: Partial Behavior Modeling

N/A
N/A
Protected

Academic year: 2022

Partager "Abstract of the Keynote: Partial Behavior Modeling"

Copied!
1
0
0

Texte intégral

(1)

Abstract of the Keynote: Partial Behavior Modeling

Marsha Chechik

Department of Computer Science University of Toronto chechik@cs.toronto.edu

Although software behavior modeling and analysis has been shown to be successful in uncovering subtle requirements and design errors, adoption by practitioners has been slow. One of the reasons for this is that traditional approaches to behavior models are required to be complete descriptions of the system behavior up to some level of abstraction, i.e., the transition system is assumed to completely describe the system behavior with respect to a fixed alphabet of actions. This completeness assumption is limiting in the context of software development process best prac- tices which include iterative development, adoption of use-case and scenario-based techniques and viewpoint or stakeholder-based analysis; practices which require modeling and analysis in the presence of partial information about system behavior.

We believe that there is much to be gained by shifting the focus in software engi- neering from traditional behavior models to partial behavior models, i.e. operational descriptions that are capable of distinguishing known behavior (both required and proscribed) from unknown behavior that is yet to be elicited. Our overall aim is to develop the foundations, techniques and tools that will enable the automated con- struction of partial behavior models from multiple sources of partial specifications, the provision of early feedback through automated partial behavior model analysis, and the support for incremental, iterative elaboration of behavior models.

In this talk, I highlighted some of the results obtained in this line of research, joint work with Sebastian Uchitel and many students at the University of Toronto, University of Buenos Aires, and Imperial College London.

Références

Documents relatifs

Our position is that validation must be part of all stages of a development conducted with refinement-based formal methods: from the initial specification, to the

 the relative simplicity of the redistribution of resources between local data centres (computing power, data storages, transmission channels), geographically remote from

The purpose of this work is to show some methodological aspects of software engineering, reflecting the departmental view that has developed over the years on issues of

The scheme of the proposed dynamic clustering in the form (2) is shown in figure 1. The input data are extracted from the software repository D. Then data are pre-processed

Keywords: Formalization · Software development process · Software · Productivity · Constant speed · Sufficient condition · The Open-Closed Principle..

In the following sub-sections, we discuss how it is possible to use this sep- aration of the design process, that is dictated by many standards, to (i) define Design Space

We expect that our solution will consist of a traceability process that can be integrated into normal software development processes such as the V-model and aligned with

searchable PDF/A with embedded fonts and records the transformations in the preservation metadata...  Clean