This paper provides an overview of the STATEMATE system, constructed over the past several years by the authors and their colleagues at Ad Cad Ltd., the R&D subsidiary of i-Logix, Inc. STATEMATE is a set of tools, with a heavy graphical orientation, in- tended for the specification, analysis, design, and documentation of large and complex reactive systems, such as real-time embedded sys- tems, control and communication systems, and interactive software or hardware. It enables a user to prepare, analyze, and debug diagram- matic, yet precise, descriptions of the system under development from three interrelated points of view, capturing structure, functionality, and behavior. These views are represented by three graphical languages, the most intricate of which is the language of statecharts [4], used to depict reactive behavior over time. In addition to the use of statecharts, the main novelty of STATEMATE is in the fact that it "understands " the entire descriptions perfectly, to the point of being able to analyze them for crucial dynamic properties, to carry out rigorous ex- ecutions and simulations of the described system, and to create run- ning code automatically. These features are invaluable when it comes to the quality and reliability of the final outcome.

This paper surveys the design of embedded computer systems, which use software running on programmable computers to im-plement system functions. Creating an embedded computer system which meets its performance, cost, and design time goals is a hardware-software co-design problewhe design of the hard-ware and software components influence each other. This paper emphasizes a historical approach to show the relationships be-tween well-understood design problems and the as-yet unsolved problems in co-design. We describe the relationship between hard-ware and sofhvare architecture in the early stages of embedded system design. We describe analysis techniques for hardware and software relevant to the architectural choices required for hard-ware-software co-design. We also describe design and synthesis techniques for co-design and related problems.

Proceedings of the IEEE January 2003 The paper describes a model-integrated approach for embedded software development that is based on domain-specific, multiple view models used in all phases of the development process. Models explicitly represent the embedded software and the environment it operates in, and capture the requirements and the design of the application, simultaneously. Models are descriptive, in the sense that they allow the formal analysis, verification and validation of the embedded system at design time. Models are also generative, in the sense that they carry enough information for automatically generating embedded systems using the techniques of program generators. Because of the widely varying nature of embedded systems, a single modeling language may not be suitable for all domains, thus modeling languages are often domain-specific. To decrease the cost of defining and integrating domain-specific modeling languages and corresponding analysis and synthesis tools, the model-integrated approach is applied in a metamodeling architecture, where formal models of domain-specific modeling languages – called metamodels – play a key role in customizing and connecting components of tool chains. The paper will discuss the principles and techniques of model-integrated embedded software development in detail, as well as the capabilities of the tools supporting the process. Examples in terms of real systems will be given that illustrate how the model-integrated approach addresses the physical nature, the assurance issues, and the dynamic structure of embedded software.

To help us identify and focus on pragmatic and concrete issues related to the role of software architecture in the design and development of large systems, we conducted a survey of a variety of software systems used in industrial applications. Our premise, which guided the examination of these systems, was that software architecture is concerned with capturing the structures of a system and the relationships among the elements both within and between structures. The structures we found fell into several broad categories: conceptual structure, module structure, code structure, and execution structure. These categories address different engineering concerns. The separation of such concerns, combined with specialized implementation techniques, decreased the complexity of implementation, and improved reuse and reconfiguration. We observed that in practice, software architecture played an important role throughout the development process: specification, design, functional decompo...

Abstract not found

This article was triggered by those of Brooks and Parnas. It is not a rebuttal. Indeed, I agree with most of the specific points made in both papers. Instead, the goal of this article is to illuminate the brighter side of the coin, emphasizing developments in the field that were too recent or immature to have influenced Brooks and Parnas when they wrote their manuscripts. The two main aspects of these developments have to do with a carefully wrought "vanilla" approach to system modeling and the emergence of powerful methods to execute and analyze the resulting models. It can be argued that the combined effect of these and other ideas is already showing positive signs and appears to have the potential to provide a truly major improvement in our present abilities -- profoundly affecting the essence of the problem. This might take more than the 10 years Brooks focuses on. It will surely be a long time before reliable software for the likes of the SDI project can be built. Such a system remains an order of magnitude too large and too critical to construct today, mainly because of its first- time-must-work nature. But I also believe that we are on the royal (main) road and that the general impression you get from reading the Brooks and Parnas articles is far too bleak

Automatic control applications are real-time systems which pose stringent requirements on precisely time-triggered synchronized actions and constant end-to-end delays in feedback loops which involve multirate interactions. Motivated by the apparent gap between computer science and automatic control theory, a set of requirements for real-time implementation of control applications is given. A real-time behavioral model for control applications is then presented and exemplified. Important sources and characteristics of time-variations in distributed computer systems are investigated. This illuminates key execution strategies to ensure the required timing behaviour. Implications on design and implementation and directions for further work are discussed.

Editor’s Note: The following article is reprinted from the book Software Requirements Engineering, Second Edition, and is provided for readers who want to read a brief tutorial on requirements engineering. The views expressed in this article are the author’s only and do not

Safety critical computers increasingly a#ect nearly every aspect of our lives. Computers control the planes we #y on, monitor our health in hospitals and do our work in hazardous environments. Computers with software de#ciencies that fail to meet stringent timing constraints have resulted in catastrophic failures. This paper surveys formal methods for specifying, designing and verifying real-time systems, so as to improve their safety and reliability. # To appear in Journal of Systems and Software,Vol. 18, Number 1, pages 33#60, April 1992. Jonathan Ostro# is with the Department of Computer Science, York University 4700 Keele Street, North York, Ontario, Canada, M3J 1P3. This work is supported by the Natural Sciences and Engineering Research Council of Canada. 1 CONTENTS 2 Contents 1 Introduction 3 2 De#ning the terms 6 2.1 Major issues that formal theories must address ::::::: 13 3 Real-Time Programming Languages 14 4 Structured Methods and#or Graphical Languages 15 4.1 Str...

In recent years, UML has become a standard language for modeling software requirements and design. In this paper we investigate the suitability of UML as a semiformal requirements specification language. Using the Teleservices and Remote Medical Care (TRMCS) case study as an example, we identify and demonstrate various problems and deficiencies of UML, particularly concerning use case models and system decomposition. We also investigate whether and how the deficiencies can be overcome and how potential alternatives could look.