Although the use of multiple views is a virtual holy grail of software and systems engineering, its status appears less secure in the field known as Software Architecture. Yet, practicing architects need views to manage the inherent complexity of the large, software-intensive systems they specify and build. This paper begins with a brief survey of the topic from its historical origins through current usage and issues, and ends with an overview of an approach to treating views as first-class entities within architectural description with respect to their usage in architectural specification, analysis and evolution. Keywords: architectural description, multiple views, viewpoints 1 Introduction The notion of multiple views has a long history in software engineering and related fields (such as requirements engineering, data engineering and systems engineering), where views are introduced to separate concerns and therefore to control descriptive complexity. Despite these precursors, thei...

. In some phases of system development state-based methods are adequate; in others event-based methods are adequate. Petri nets provide a system model which supports both methods and thus allow a smooth transition between the different phases of system development. Most temporal logics for Petri nets, however, do not support both methods. In this paper we introduce a temporal logic for Petri nets which allows to argue on states as well as on events. This way, specifications in the early phases can be event based and verification in later phases can be state-based within a single formalism. Keywords: Temporal logic; events; states; Petri nets; system development; specification; verification. Introduction Most formal methods employed for the specification and development of distributed systems are either event-based or state-based. The event-based methods highlight the events and their relation; the state-based methods emphasize the states and the state changes. Both approach...

ion. Requirements may be distinguished based on the abstraction level of their description. A requirement may be further defined by add new details defined in more specialized subrequirements. Through specialization of abstract requirements, or generalization of detailed requirement, a requirement abstraction hierarchy can be defined. . Development p roperties . Requirements may be distinguished based on their development properties. For example, a requirement may have just been proposed. Late r, it may be accepted or rejected. . Representational properties. Requirements may be distinguished based on their representation. A requirement may begin as an informal sketch, then become a natural language sentence (e.g., "The system shall ..."). Finall y, more formal representations, such as UML, Z, or predicate cal- Requirements Interaction Management - Definition and scope 6 1999 William N. Robinson Requirements Interaction Management GSU CIS 99-7 culus, may be used to express a requir...

The use of lexical afftnities to help a human requirements analyst find abstractions in problem descriptions is explored. It is hoped that a lexical athnities tinding tool can be used as part of an environment to help organize the sentences and phrases of a natural language problem description to aid the requirements analyst in the extraction of requirements. An experiment to confirm its effectiveness is described. 1.

Today, the syntax of visual specification languages such as UML is typically defined using metamodeling techniques. However, this kind of syntax definition has drawbacks. In particular, graphic metamodels are not powerful enough, so they must be augmented by a constraint language. In this report, we present a text-based technique for the syntax definition of a graphic specification language. We exploit the fact that in a graphic specification language, most syntactic features are independent of the layout of the graph. So we map the graphic elements to textual ones and define the context-free syntax of this textual language in EBNF. Using our mapping, this grammar also defines the syntax of the graphic language. Simple spatial and context-sensitive constraints are then added by attributing the context-free grammar. Finally, for handling complex structural and dynamic information in the syntax, we give a set of operational rules that work on the attributed EBNF. We explain our syntax definition technique by applying it to the modeling language ADORA which is being developed in our research group. We also briefly discuss the application of our technique to the syntax definition of UML.

During the last years, a number of formal specification languages for knowledge-based systems (kbs) have been developed. Characteristics of such systems are a complex knowledge base and an inference engine which uses this knowledge to solve a given problem. Languages for kbs have to cover both these aspects. They have to provide a means to specify a complex and large amount of knowledge and they have to provide a means to specify the dynamic reasoning behavior of a kbs. Nevertheless, kbs are just a specific type of software system. Therefore it seems quite natural to compare formal languages for specifying kbs with formal languages which were developed by the software engineering community for specifying software systems. That is the subject of this paper. Introduction Over the last few years a number of semiformal, formal, and executable specification languages 1 have been developed for describing knowledge-based systems (kbs). These specification languages can be used to ...

The TARA Project conducted research into the provision of tool assistance for requirements analysis techniques. In particular it concentrated on automated support for three specific areas: active method guidance, requirements animation and the reuse of specification fragments. In this article we discuss the aims and status of TARA and the application of CASE technology within a method framework. In addition, we outline work on specification and method integration which is based on some of the approaches developed within TARA. 1 Introduction Requirements analysis is one of the most critical tasks in information systems development. Unrecognised errors made early in the development process may have widespread repercussions in the later phases. As a consequence, the cost of correcting such errors is high (Boehm 1982). Support for requirements analysis is therefore crucial. The main focus of our work was the large class of systems which can be classed as "real-time information systems"; t...

Early Requirements Engineering is the phase of the software development process that is concerned with understanding the organizational context of a system, and the goals and social dependencies of its stakeholders. Formal Methods techniques have a great potential as a powerful means for specification, early debugging and certification of software. So far, however, their application to early requirements modeling and analysis has been limited by a mismatch between the concepts used for describing early requirements and the constructs offered by formal specification languages. This thesis

Formal methods can be neatly woven in with less formal, but more widely-used, industrial-strength methods. We show how to integrate the Larch two-tiered specification method [GHW85a] with two used in the waterfall model of software development: Structured Analysis [Ros77] and Structure Charts [YC79]. We use Larch traits to define data elements in a data dictionary and the functionality of basic activities in Structured Analysis data-flow diagrams; Larch interfaces and traits to define the behavior of modules in Structure Charts. We also show how to integrate loosely formal specification in a prototyping model by discussing ways of refining Larch specifications as code evolves. To provide some realism to our ideas, we draw our examples from a non-trivial Larch specification of the graphical editor for the Miro visual languages [HMT + 90]. The companion technical report, CMU-CS-91-111, contains the entire specification. This research was sponsored by the Avionics Lab, Wright Research a...

Developing requirements from a group of analysts and system users is a difficult task. In addition to the usual problems of individual requirements acquisition, group requirements acquisition entails conflict detection, resolution generation, and resolution choice. In essence, requirements must be negotiated. In this paper, we summarize our model for requirements negotiation and its automated support. The model calls for the independent representation of user requirements followed by their negotiation. The model centers around three themes: user participation, resolution generation, and negotiation records. To support these themes, we have built a tool, called Oz, which provides: (1) automated methods for conflict detection and resolution generation, (2) an interactive resolution choice procedure, and (3) records of the negotiation process. This paper overviews our negotiation method and tool support. 1 Introduction Requirements negotiation is a common and difficult problem...