Interface Design Abstract interface objects, responses to external events, interface transformations Mapping between navigation and perceptible objects Modelling perceptible objects, implementing chosen metaphors. Describe interface for navigational objects Implementation Running application Those provided by the target environment Performance, completeness Figure 1. Summary of the OOHDM Methodology 1-Domain Analysis In this step a conceptual model of the application domain is built using well known object-oriented modelling principles [Rumbaugh 91] augmented with some primitives such as attribute perspectives and sub-systems. Conceptual classess may be built using aggregation and generalization/specialization hierarchies. There is no concern for the types of users and tasks, only for the application domain semantics. The product of this step is a conceptual schema built out of sub-systems, classes and relationships. 2-Navigational Design Here we describe the navigational structur...

The Zeno Argumentation Framework is a formal model of argumentation based on the informal models of Toulmin and Rittel. Its main feature is a labelling function using arguments to compute heuristic information about the relative quality of the alternative positions proposed as solutions for some practical issue. The Zeno Argumentation Framework was designed to be used in mediation systems, an advanced kind of electronic discussion forum with special support for argumentation, negotiation and other structured forms of group decision-making. 1 Problem Statement The cities of Bonn and Sankt Augustin are planning a residential area and high-technology "park" in an area between the two cities. This area was zoned for agricultural purposes only, so a formal proposal was made to change the zoning ordinance. According to local law, changes of this kind are subject to a formal review procedure. This procedure requires that the plan be made available to the general public for their comments, cr...

A program's object model captures the essence of its design. For some programs, no object model was developed during design; for others, an object model exists but may be out-of-sync with the code. This paper describes a tool that automatically extracts an object model from the classfiles of a Java program. Unlike existing tools, it handles container classes, by inferring the types of elements stored in a container, and eliding the container itself. This feature is crucial for obtaining models that show the structure of the abstract state, and bear some relation to conceptual models. Although the tool performs only a simple, heuristic analysis that is almost entirely local, the resulting object model is surprisingly accurate. The paper explains what object models are and why they are useful; describes the analysis, its assumptions and limitations; evaluates the tool for accuracy, and illustrates its use, on a suite of sample programs. 1 Introduction Womble is a tool that extracts obj...

This paper presents a controlled experiment focusing on the impact of applying quality design principles such as the ones provided by Coad and Yourdon on the maintainability of object-oriented designs.

Abstract not found

Current and future (conventional) notations used in Conceptual Modeling Techniques should have a precise (formal) semantics to provide a well-defined software development process, in order to go from specification to implementation in an automated way. To achieve this objective, the OO-Method approach to InformationSnform Modeling presented in this paper attempts to overcome the conventional (informal)/formal dichotomy by selecting the best ideas from both approaches. The OO-Method makes a clear distinction between the problem space (centered on what the system is) and the solution space (centered on how it is implemented as a software product). It provides a precise, conventional graphical notation to obtain a system description at the problem space level, however this notation is strictly based on a formal OO specification language that determines the conceptual modeling constructs needed to obtain the system specification. An abstract execution model determines how to obtain the software representations corresponding to these conceptual modeling constructs. In this way, the final software product can be obtained in an automated way. r 2001 ElsevierS ien e Ltd. All rights reserved.

In object-oriented conceptual modelling, the Generalisation/Specialisation hierarchy and the Whole/Part relationship are prevalent classification schemes for object types. This paper presents an object-oriented conceptual model where, in the end, object types are classified according to two relationships only: existence dependency and generalisation/specialisation. Existence dependency captures some of the interesting semantics that are usually associated with the concept of aggregation (also called composition or Part Of relation), but in contrast with the latter concept, the semantics of existence dependency are very precise and its use clear cut. The key advantage of classifying object types according to existence dependency are the simplicity of the concept, its absolute unambiguity and the fact that it enables to check conceptual schemes for semantic integrity and consistency. We will

This paper will discuss three examples of use of scenarios in user-centred design. The examples are from projects that the author has been involved with. Common to them are the use of scenarios to support the tensions between reflection and action, between typical and critical situations, and between plus and minus situations. The paper will illustrate how a variety of more specific scenarios emphasising e.g. critical situations, or even caricatures of situations are very useful for helping groups of users and designers being creative in design. Emphasising creativity in design is a very different view on the design process than normally represented in usability work or software/requirement engineering, where generalising users actions are much more important than the, in this paper, suggested richness of and contradiction between actual use situations. In general the paper proposes to attune scenarios to the particular purposes of the situations that they are to be used in, and to be ...

The paper discusses the application of state diagrams in UML to class testing. A set of coverage criteria is proposed based on control and data flow in UML state diagrams and it is shown how to generate test cases satisfying these criteria from UML state diagrams. First, control flow is identified by transforming UML state diagrams into extended finite state machines (EFSMs). The hierarchical and concurrent structure of states is flattened and the broadcast communication is eliminated in the resulting EFSMs. Second, data flow is identified by transforming EFSMs into flow graphs to which conventional data flow analysis techniques can be applied.

Abstract. Software architectures and designs "notations " are typically based on bubble-and-arc diagrams. Embellishing these diagrams may increase their information content but does not make a language. A formal language has syntax, semantics, and inference rules, so that reasoning and automatic manipulation are made possible. We describe LePUS, a formal language for describing and reasoning about object oriented software architectures, designs, and patterns. A LePUS formula imposes constraints on the software at an appropriate level of abstraction but does not unnecessarily restrict the implementation. LePUS is not an ad hoc collection of loosely related concepts but instead originates from an insight on a small number of necessary and sufficient basic "building blocks " that are ubiquitous in object oriented design. A LePUS specification can be expressed as either a formula or a semantically equivalent diagram. We provide examples of LePUS descriptions ranging from simple design patterns, such as FACTORY METHOD, to popular current architectures, such as Enterprise JavaBeans™.