Search

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.

The authors' development method focuses on a systematic process using precise specification of system components to create application-independent architectures with a high degree of automation-achieved through large-scale code generation-and broad applicability, focusing on real-time systems.

The object-oriented paradigm still faces an open challenge: Delivering huge software systems routinely and cost effectively. To quote Ed Yourdon: “A system composed of 100,000 lines of C++ is not be sneezed at, but we don't have that much trouble developing 100,000 lines of COBOL today. The real test of OOP will come when systems of 1 to 10 million lines of code are developed.” Although the object-oriented community has an opening flirtation with exploratory programming and rapid prototyping by exploiting reuse via inheritance, there is for now, in my opinion, no hope that huge systems can be developed without giving due attention to what a target system is supposed to do. Which should produce an (electronic) (graphical) (Pseudo-formal) document, the requirements, that a customer can initially sign off. We believe as well that for huge systems a programming language independent design activity, that bridges the requirements and the actual programming effort, is mandatory. It goes without saying that we do not suggest that these activities constitute a waterfall sequence. Consequently, the object-oriented community needs to address the question whether well established analysis techniques, like Structured Analysis, Jackson's JSD, etc. can be reused for object-oriented system development or whether a dedicated object-oriented analysis (and design) method is called for. The panel members have been asked to consider the following of question: What is the relationship between Structured Analysis (SA) and Object Oriented Analysis (OOA)? More specifically: Can SA be used effectively to produce the requirements for a system that will be designed and implemented in an OO fashion? If not, is it possible to adjust SA, what needs to be added? If SA cannot be used at all, what is the key obstacle? In case SA and OOA have different applicability ranges, how do we circumscribe — positively and negatively - these ranges? Any overlap? We appreciate that the organizing committee of this conference has selected this crucial topic.

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?

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.