SDL-2000: A Language with a Formal Semantics

2002

State Machines (ASMs) have been used to describe and validate a wide variety of computing systems [9]. Numerous introductions to ASMs have been written (see for example [20, 10, 21, 36]). In addition, many ASM papers include brief overviews for the casual reader. In this paper we attempt to provide a gentler introduction, focusing more on the use of the technique than on formal definitions. 1 Our target audience is a senior-level undergraduate class in software engineering, but we hope that this work proves helpful to other readers as well. While there are references to "software" throughout, the reader should be aware that ASMs are relevant to other kinds of system development as well. For simplicity, our focus is on ASMs with only a single agent; distributed ASMs may be considered in a later paper. We were sitting in a coffee shop when Questor, a bright undergraduate student, stopped by. He mentioned that he was studying ASMs in his software engineering course. Curious, we asked him to sit with us and tell us about his progress. Questor: It's a little rough. I can follow the basic definitions [21], but I'm finding it difficult to use those definitions to actually write an ASM. How did you learn? Author: Well, I suppose it was through a sort of apprenticeship process. Fortunately for us, we had the originator of ASMs as our mentor. We started by looking at ASMs that he and others had created; then we tried making our own. Through an iterative process of criticism and revision, we honed our ASM-writing skills. We've also tried out our ASMs by executing them, using the many tools available [4, 38, 3, 2]. Q: It seems like there ought to be a way to pass some of your experience on to new ASM writers like me. A: Let's give it a try. ASMs and the Software Process Q: So how do you go about using the ASM method? A: In some ways, it's not all that different from other methods you may have used in developing software. Q: But I thought that this was supposed to be a totally new and different technique. If the process isn't all that different, why bother with it? A: Maybe you have an exaggerated view of what ASMs are all about. First of all, let's make it clear what the ASM method isn't. It doesn't define the entire software process; it doesn't tell you the steps to take * Financial support for this work has been provided by Microsoft Research. to develop a product. You still need to solve the same old problems: how to find out what your customer wants, how to design the product carefully, how to check that what you're producing is what the customer wants. Many people have proposed so-called process models, that give you guidelines on how to attack these problems. The ASM method isn't a process model. Q: I've heard of some process models, like the waterfall model [33] and Extreme Programming [5]. So if the ASM method isn't a process model, what is it? A: At its core, it is simply a method for documenting software at various stages of the development process. The goal is software documentation that is clear and precise. Of course, the ASM method doesn't guarantee clarity or precision; that's still up to you. Q: So this is a new way of documenting software. What's so exciting about software documentation? A: When we think of "documentation", we tend to think of those thousand-page reference manuals that no one ever reads. But documentation doesn't have to be like that. It can be succinct, elegant, and informative. And it ought to be. Documentation is the medium through which different players in the development process communicate with one another. If the documentation is inaccurate or unintelligible, the software process breaks down. Q: So why is ASM better than other means of documentation? For instance, what's wrong with nicely commented C or Java code? A: Nothing at all; well-commented code is a wonderful thing. And certainly your software will eventually be expressed as a program in a language like C or Java. In fact, you can view an ASM as a program, though the language of ASMs is different from traditional programming languages in many ways. The most important difference between an ASM and a "conventional" program is that an ASM can represent software at a much higher level of abstraction. Q: Why would I care about such a description? A: You can produce this high-level description at a much earlier point in your design process, before all the details of the design have been decided. When writing a program in a traditional programming language, you are often forced to make design decisions that may be premature. Q: So once I decide on all the details, I can forget about ASMs and just use my favorite programming language? A: Even then, such a description might be too detailed for most people to understand. Suppose you've never written in programming language L before. Notice that a compiler for L is in essence a complete description of L; it defines how instructions in L should be interpreted and executed. But would you want to learn how to write programs in L by studying the source code for the compiler? Q: No-it would be way too complicated. A: Too much detail can obscure what's important. Through abstraction, you can produce a view of your software that omits those details you don't want to see at a given time. Q: Let's go back a bit. Earlier you said that you can write an ASM before all the details of your design have been finalized. If you're not sure about all the details of a design, why not just describe the design using a diagram, or good old-fashioned natural language? A: The ASM method isn't meant to replace these approaches. But as we all know, diagrams and natural language can be vague or ambiguous. This is good in art and literature; we can find many "meanings" in a painting by Picasso or a sonnet by Shakespeare. And everyone's favorite humor form-the pun-would be impossible without the ambiguity of natural language. But in a description of a software system, ambiguity can be a very bad thing [26], particularly when the description is shared among many people. Unlike natural language, the ASM method has precise semantics; there's never any doubt about the meaning of an ASM. Q: It seems like abstraction is an important benefit of the ASM method; I suppose that's why the word "abstract" is in the name. Are there other advantages? A: Certainly. ASMs can be executed directly using various tools; this makes the transitions from designing to coding, and from designing to testing, much easier. In our opinion, the notation used to write an ASM involves minimal overhead and is easier to learn and use than those of other methodologies. There are other benefits as well. Q: OK. So we'll see them along the way. I guess I can trust you for now. A: Why the suspicion? View publication stats View publication stats