Stephen J. Mellor

Methodology standards: help or hindrance?

Over the last 12 months there has been growing interest in the possible “standardization” and/or “convergence” of object-oriented analysis and design methodologies. The key issues discussed by the panellists focus on whether standardization NOW is to be encouraged or resisted whether standards are a help or a hindrance to the further maturation of 00 methodologies. Each panellist has been closely associated with the development of an 00 lifecycle methodology. Some of the issues raised include:

An Action Language for UML: Proposal for a Precise Execution Semantics

This paper explores the requirements for complementing the UML with a compatible, software-platform-independent executable action language that enables mapping into efficient code. This language is henceforth referred to as an action language. The user of the action language will be able to specify the structure of the algorithms for a problem domain precisely without making unnecessary assumptions about the detailed organization of the software. An action language will enable precise specification of the structure of actions on a UML State Chart and the operations on a UML Class Diagram.

How difficult is the transition from OOA to OOD? (panel session)

One of the claimed advantages of object-oriented (OO) development is that developers can use objects in a uniform modeling approach throughout the process. In particular, they can coherently apply the same notation for representing these objects and their relations in both analysis and design. Given this, the claims by many OO methodologists (see, e.g., [1, 5]) that the transition from OO analysis (OOA) to OO design (OOD) is easy and smooth may seem convincing. However, the contrasting view can be found in [2, 4] that it is actually difficult to go from OOA to OOD and, recognizing the differences between what is modeled in the analysis and design phases can lead to a more conscious development approach. In the light of such controversial views, it seems to be necessary to widely discuss this issue. The prospective panelists represent a wide spectrum of related views. So, there is some hope that this panel might more or less resolve this important issue. A consequence of resolving this issue might be a contribution to a better understanding of a paradox in the current software business: software is wanted faster and at the same time with higher quality than ever before. Does the view that the transition from OOA to OOD might be easy promise too much in the direction of quick solutions?

Structured analysis and object oriented analysis (panel session)

He compared the functional object paradigm transition with a religious conversion. He objected to the “in order to see the light-forget everything and start over again with an elementary course in Smalltalk” approach espoused by many. He presented OOA as an “interestingly different” paradigm from the functional paradigm. He reminded us that OOA still has its roots in what it is trying to distinguish itself from.

Translating the Air Traffic Control Model

We took a tour of the key decisions made during translation of an xUML model in the previous chapter. A pycca model script is prepared, and we examine the resulting C code. The subject of this chapter is implementation oriented, and we assume you are familiar with the C language. Space doesn’t permit us to present all of the code here, but if you are interested in reviewing the entire ATC project, including all of the code, feel free to download it from the book’s website.

An Extended Example

We presented the simple ATC application as an extended hello world example to demonstrate the fundamental steps in a pycca translation. That initial application addressed a small portion (workloads and shifts) of an isolated subject matter (air traffic control). It was defined by an integrated set of class, state, and action facets wrapped up in a single executable model package. In this chapter, we begin a new case study that requires coordination of multiple such executable packages which, in Executable UML, are called domains.

The Modeling Landscape

We could begin this book with a litany of the failings and sins of software development. We won’t bother with that. If you are a practicing software developer, you know the problems and have lived through them. Instead, we’ll get straight to the point.

Model Execution Domain

Until now, we have glossed over the operations of the translation’s runtime component. We have described some of its functions, but have not said how it accomplishes anything. No longer! In this chapter, we explain how code for managing model execution works and the important role it plays in generating a running program.

A Simple Executable Model

This chapter describes the main elements that make up an executable model for a sample application. The application is deliberately small so that we can show how to translate the whole model into running code, with no mysterious gaps. We’ll use the same principles later to build larger, more complex applications.

Pycca and Other Platforms

In this chapter, we discuss the design and implementation of the pycca program itself. Pycca is designed as a language processor that reads DSL statements to populate a platform model and generates code by using a template system that queries the populated platform model. It is implemented in the Tcl language.