fields@hpcea.CE.HP.COM (Wendell Fields) (07/25/89)
Some time ago I noticed a posting requesting information about
integrating structured analysis with object oriented systems. This
NTU (National Technological University) confernce will address this
issue in part.
NTU Live Satellite Broadcast
Integrating Data Analysis/Design and
Structured Analysis/Design
SPEAKERS:
The conference will consist of four speakers and one panel. The
speakers are: Stephen Mellor of Project Technology, Inc., Samuel
Holcman of Computer & Engineering Consultants, LTD., Dr. Paul Ward of
Software Development Concepts, and Don Watt of Hewlett-Packard. The
panel discussion will be moderated by Dr. Mary Loomis from HP and will
allow the speakers to address specific questions about the integration
of Data Analysis/Design and Structured Analysis/Design that the
audience may have.
OBJECTIVES:
This teleconference is designed to create a clearer understanding of
the issues and problems involved in relating data analysis and design
and process analysis and design. Those attending will gain a deeper
understanding of software engineering as a whole and will be able to
apply that knowledge to their own work.
DESCRIPTION:
Data analysis and design are used to model data while structured
analysis and design are used to model process. In the future, it may be
the case that neither of these techniques, alone, will completely meet
the needs of software engineers. Many CASE tool developers have already
recognized the need to provide both techniques in their products. Tools
such as those produced by SystemOID Inc., Index Technology, Hewlett-
Packard, Nastec Corp. and others have the ability to do both
techniques.
In addition, as object oriented programming techniques become more
widely accepted, there is potential for the distinctions between these
two techniques to be ignored. It is important that the issues
surrounding these two techniques be made clear and movement towards a
blending of the two begun. For more detail on this please refer to the
March IEEE Software publication where Paul T. Ward writes on
integrating object oriented programming with structured analysis and
design.
Topics to be covered in this conference include: driving data analysis
from structured analysis, verifying the results of each technique from
the results of the of the other technique, discovering and documenting
business requirements through the use of data and process modeling
techniques, applying data and process analysis techniques to object-
oriented analysis, and applying data and process design techniques to
object-oriented development.
INTENDED AUDIENCE:
The intended audience for this teleconference includes software
engineers and managers who are concerned with data and/or process
abstraction within the analysis and design phases of the software
lifecycle.
SCHEDULE:
One 6-hour live session:
Wednesday, September 6, 1989
11:00 AM - 5:00 PM, Eastern Time
REGISTRATION:
This conference is presented by NTU. Registration will be through your
site coordinator or you may call NTU at (303) 484-0565.eberard@ajpo.sei.cmu.edu (Edward Berard) (07/30/89)
In article <6100001@hpcea.CE.HP.COM>, fields@hpcea.CE.HP.COM (Wendell Fields) writes: > Some time ago I noticed a posting requesting information about > integrating structured analysis with object oriented systems. This > NTU (National Technological University) confernce will address this > issue in part. > > NTU Live Satellite Broadcast > > Integrating Data Analysis/Design and > Structured Analysis/Design > [List of Speakers -- deleted] > > OBJECTIVES: > > This teleconference is designed to create a clearer understanding of > the issues and problems involved in relating data analysis and design > and process analysis and design. Those attending will gain a deeper > understanding of software engineering as a whole and will be able to > apply that knowledge to their own work. > > DESCRIPTION: > > Data analysis and design are used to model data while structured > analysis and design are used to model process. In the future, it may be > the case that neither of these techniques, alone, will completely meet > the needs of software engineers. Many CASE tool developers have already > recognized the need to provide both techniques in their products. Tools > such as those produced by SystemOID Inc., Index Technology, Hewlett- > Packard, Nastec Corp. and others have the ability to do both > techniques. > > In addition, as object oriented programming techniques become more > widely accepted, there is potential for the distinctions between these > two techniques to be ignored. It is important that the issues > surrounding these two techniques be made clear and movement towards a > blending of the two begun. For more detail on this please refer to the > March IEEE Software publication where Paul T. Ward writes on > integrating object oriented programming with structured analysis and > design. > > Topics to be covered in this conference include: driving data analysis > from structured analysis, verifying the results of each technique from > the results of the of the other technique, discovering and documenting > business requirements through the use of data and process modeling > techniques, applying data and process analysis techniques to object- > oriented analysis, and applying data and process design techniques to > object-oriented development. > This posting brings up a number of problems. However, I must first define, or at least reference, some terms. Structured analysis and structured design were attempts to formalize the pre-coding parts of the traditional, functional decomposition life-cycle. The original work on "structured design" was published in the IBM System Journal in 1974, and was co-authored by L.L. Constantine, Glen Myers, and Wayne Stevens. Constantine had begun work on what was to become structured design almost 10 years earlier. In 1978, Tom DeMarco formalized "structured analysis," although this work had also been in progress for a number of years. Almost immediately, alternative approaches to structured analysis and design began to appear, e.g., Gane and Sarson, and Victor Weinberg. However, major changes did not begin to emerge until the early 1980s. These changes were driven, in large part, by the inadequacies in the "traditional structured techniques" when it came to real-time programming. Paul Ward and Steve Mellor gave us "Structured Development for Real-Time Systems." There were also the "Boeing-Hatley" variation, and H. Gomma's "Design and Analysis for Real-Time Systems." 1n 1974, J.D. Warnier formalized an approach for designing modules based in the structure of their input data and their output data, i.e., "the logical construction of programs." A year later, Michael Jackson (the British computer scientist) came out with his variation on the same theme. Later, in the U.S., Ken Orr advanced the work of Warnier, and developed his own technique, i.e., "data structure system design." The contributions of these, and other, pioneers in formalizing the functional decomposition and data structure approaches to software engineering are indeed important. There are, however, other software engineering paradigms, e.g., the so-called "formal" or mathematical approaches (e.g., Vienna Development Method, OBJ, and Z), rapid prototyping (see, for example, Barry Boehm's discussions on the subject), modeling approaches (e.g., Jackson System Development, circa 1983), and, of course, object-oriented approaches. [It is very unfortunate that very few software engineers have had a course on comparative software engineering paradigms. Each paradigm offers at least one thing (and sometimes many) which is still useful.] There are many hard won lessons in the establishment of the object-oriented approach. One of the most fundamental is that functional approaches localize information around functions, and object-oriented approaches localize information around objects. It is this difference in localization which brings about much of the incompatibility between the two approaches. Those used to the functional decomposition approach often seem confused when presented with an object-oriented approach. They offer some strange observations, e.g.: - "I see nothing wrong with using data flow diagrams, if they help me to understand the problem." (The problem is that DFDs do very little to help you understand the problem in an object-oriented way.) - "Let's be reasonable. There must be some way that we can use the two approaches together." (Who would want to argue with this Solomon-like line of thought? Unfortunately the disastrous results will not become known until test and integration time.) It is human nature to approach a new problem with the tools at hand. However, it is usually prudent to study the problem first to see if the tools at hand are appropriate. Since this newsgroup is not the place to launch into a full discussion of object-oriented technology, I will try to present a few pertinent facts. 1. An "object" is a thing, an item, or a characteristic. Objects are complete abstractions, i.e., they faithfully represent their "real world" counterparts. (In many object-oriented approaches, one may not separate objects which will eventually become code from other objects until late in the process. Specifically, the software engineer may not differentiate (early on) among "code objects," "hardware objects," and "human objects.") 2. Objects are black boxes, i.e., the internal structure (underlying implementation) is hidden. All interactions with an object take place via that object's well-defined interface. Users of an object have no knowledge of such things as the details of the algorithms used, the layout of any data, and any underlying layers of abstraction. 3. Objects encapsulate: - knowledge of state information - operations (and their corresponding methods) - other objects (composite objects may be either heterogeneous or homogeneous) - exceptions - constants - concepts 4. Objects may be passive or active. Passive objects do not (and cannot) change their state spontaneously. Active objects (sometimes referred to as "objects with life") are capable of changing their own state spontaneously. That is, they change their state without any external interaction. Objects are not data and data are not objects. Sometimes people think that objects are merely the data in the system. This is incorrect. Sometimes people say objects are a combination of data and functions. While this is "heading in the right direction," it is at best an incomplete description. Although object-oriented programming has been around (formally) for almost twenty years, its practitioners unfortunately spent most of their time focusing on coding and programming language issues. Until the early 1980s very little work was done in the area of life-cycle methodologies. Hence, we see the structured methodologists now migrating to an object-oriented approach and bringing their largely inappropriate methods, tools, and graphics with them. -- Edward V. Berard Berard Software Engineering, Inc. 18620 Mateney Road Germantown, Maryland 20874 E-Mail: eberard@ajpo.sei.cmu.edu Phone: (301) 353-9652