Re: OOA?

From: Brian S. Smith (sales_at_leapse.com)
Date: 02/03/04 

Date: 3 Feb 2004 13:50:49 -0800

Responding to Lahman:

"H. S. Lahman" <h.lahman@verizon.net> wrote in message news:<a4BTb.6901$IF1.2514@nwrdny03.gnilink.net>...
> Responding to Smith...
>
> >>
> >>My question is: Do you see yourself as a Requirements Analyst or an OO
> >>Analyst?
> >>
> >>My second question is: Is what you produce in UML or is it a <precise as
> >>possible> natural language specification (e.g., use cases, etc.)?
> >
> >
> > Good questions! (1) I am a Systems Engineer (or Analyst), perhaps more
> > precisely, a Systems Software Engineer. A friend of mine once remarked
> > several years ago that the systems engineer of tomorrow (today) really
> > needs to have one leg in the systems world, and another in the
> > software camp. This couldn't be more true given the evolution of our
> > information infrastructure. What was once the exclusive domain of
> > electrical engineers (switches, relatys, PBXs, etc.) has become highly
> > computerized and protocol-driven. What good is a systems engineer if
> > he/she can't make requirements palpable for software consumption?
> > Specifically for software design? So perhaps "systems software
> > engineer" is the most accurate description. I also teach Systems
> > Analysis and Design, BTW. Regarding requirements engineering and OO
> > analysis, both are tasks for the
> > jack-of-all-trades-business-problem-solver, the systems analyst.
>
> This sounds very much like your job title is firmly on the software
> development side of things rather than the requirements specification side.
>
> >
> > As for question (2), what Leap SE produces is a directory of (C++)
> > header files. Now these header files are not intended be used for
> > actual software development--they comprise a logical OO model of the
> > system as expressed by the domain-specific SRS requirements. They are
> > in OO form, with public and private sections, as well as reference and
> > pointer attributes to convey composition and association,
> > respectively. Inheritance is also supported.
>
> Leap SE is a hybrid of requirements analysis and OO analysis.

This is an accurate statement.

As soon
> as you produce C++ header files you are doing OOA and defining a
> specific solution.

Insofar as an OO vs. a structured solution, e.g., yes. But see my
comments below. No design-level solution is being 'mandated' by this
high-level OOA. It is not unusual for the design and detailed design
phases of a program's SDLC to deviate (sometimes sharply) from the
original OOA performed. But by the same token, the design phases are
indebted to the OOA phase for enabling them to understand what needs
to be built, specifically the relationships and expected behavior, to
produce an effective design and subsequent implementation.

It is a fait accompli. How does the software
> developer determine when classes should be abstracted differently than
> the Leap SE view?

This is their job. Quite frankly, I would not hire them if they did
have these rudimentary abilities. Each phase of the SDLC requires some
work. Leap SE is intended to get the map on the table early for
further evaluation. A important point is how this evaluation can feed
back into the requirements definition process.

The only way that is possible is if the developer
> knows something about the requirements that Leap SE doesn't.

I disagree. At this point, it is not a question of requirements. The
output of Leap SE is deterministic, and I would expect the consumers
of the material (software designer) to understood this fact.

>
> >
> >>My critique of the SRS provided by the OP was basically that it
> >>specified a solution (How to do it) rather than requirements (What
> >>should be done). IOW, it was an SRS written by an OO Analyst.
> >>
> >>IMO, it is a very slippery slope to think about requirements as OO.
> >>That because the Object-Oriented adjective was coined to describe a
> >>particular approach to developing software solutions.
> >
> >
> > Bingo. I couldn't agree more that OO is an approach for developing a
> > software solution. No argument here. And certainly, it is a "slippery
> > slope" to think of requirements in terms of OO. Point is, it's a
> > challenge, and largely an uncharted area (I know, I've spent 3 years
> > dedicated to putting sand on the slippery slope!) When you consider
> > that very, very few RAD tools attempt to speed up the Systems
> > Development Life-cycle (SDLC) from such a fundamental level, and how
> > MUCH time is typically spent on systems analysis, turning to face the
> > SRS is worth it. Fortunately, English lends itself to OO/UML
> > principles (nouns=entities, verbs=methods, etc.) moreso than a
> > structured approach to OOA. Of course, deriving a sound, accurate, and
> > consistent OO logial model from English "shall" statements is a
> > whole-lot more involved. A colleague of mine once remarked that Leap
> > SE is essentially a "data-relationship extraction" tool, and he's
> > right. In an upcoming release, not only will an OO model be produced,
> > but a relational data model, as well, in the form of SQL statements
> > for ready-generation of a logical schema. Generating the SQL is
> > significantly easier than the OO model, which includes methods...over
> > and out. -Brian
>
> My problem is that expressing requirements in the UML notation
> necessarily blurs the line between requirements and solution because the
> notation is a solution notation.

Actually, using header files (which you seem to be focused on just a
bit), is mostly a convenience, and a sensible choice for output. The
underlying methodology (Deterministic Phraseology) could very well be
implementation independent. Header files were chosen as the output for
two fundamental reasons: (1) it's a fine way to communicate with
software designers and developers; (2) header files are readily
imported into reverse-engineering tools such as Rational Analyzer to
produce class diagrams.

Leap SE is a rapid application development tool, after all. It is
intended to speed up the migration to a solution.

One can get away with using a subset
> of OOD UML for OOA because both represent solutions at a high level of
> abstraction. But I don't see that for requirements; it's apples and
> oranges. I see the difference as being even greater that the gap
> between OOD and 3GL implementation.
>
> I think one would be better off with a more rigorous notation for
> requirements specification than natural language and then providing a
> meta-model bridge to map between that notation and UML:
>
> Requirements -------> OO Analysis -------> OO Design ------> OO Code
> meta model meta model meta model meta model
> | | | |
> | | | |
> | | | |
> SRS model -----------> OOA model --------> OOD model ------> OOPL Code
> (???) (UML) (UML) (C++)
>
> The upper row represents meta models that define the semantics of the
> subject matters. A shared underlying mathematics provides a mapping
> between meta models. Each application development stage produce an
> instance of the meta model in an appropriate notation (parenthesized).
> The meta model mappings allow one to systematically migrate through the
> development stages. [The presence of different meta models for OOA and
> OOD despite the same notation captures the idea that the MDA profile for
> OOA is different (subset) than that of OOD, which is methodologically
> important to construction.]
>
> In translation the OOD/P stages are effectively automated because full
> code generation is applied to the OOA model. In specialized niches
> there are tools that provide full code generation directly from the SRS
> (the ATLAS language, IEEE 716).

Thank you for the info. I will look into ATLAS, and may be able to
supply some insightful contrasts in subsequent postings.

>
> What Leap SE seems to be doing is providing incrementally more code
> generation with each release.

I don't see how you link code generation to Leap SE (???). Please
visit www.leapse.com/managers.htm for info on how Leap SE can shorten
the systems analysis phase. There really is no tie-in to code
generation.

 The presence of SQL indicates this in
> particular. That's because SQL is a very low level OOP implementation
> mechanism.

I don't see SQL (which is a tool of the relational world) as directly
related to OOP (???) Not sure about the connection you're trying to
make here...

 (An OOA model should be indifferent to whether data is
> persisted in an RDB, an OODB, flat files, or stone tablets -- much less
> what sort of access mechanisms are used.)

When you refer to "access mechanisms" here, I assume you're
questioning my mentioning of methods. The behavior expressed in an SRS
(verb-based phrases) is critical to understanding system events. To
overlook this information would be folly...and severely compromises
analysis.

The fact that an SRS contains
> SQL scrams that one is not looking at requirements but at a low level of
> solution.
>
> As a translationist I certainly don't have any problem with automatic
> code generation. But I do have a problem with Leap SE being promoted as
> a requirements management tool

Leap SE is not a requirements management tool, and is not purported to
be one. It does serve as a requirements repository in addition to its
use as a RAD tool. However, tools like Agile and DOORS are much
superior when it comes to requirements management. Leap SE's benefit
of being able to serve as a requirements repository is simply an added
benefit. The requirments maintained in Leap SE can be directly
imported into those tools, if desired.

when its main function seems to be to
> automate the migration between requirements and OOA/D/P.
>
> Nor do I have a problem with Leap SE per se. I just think UML is a
> lousy notation for describing requirements.

I strongly differ on this point. English does lend itself to OOA.
However, it is quite difficult to pull off for a RAD tool. Hence the 3
years development invested in producing Leap SE, which largely
involved grammatically analysis.

 If you had a rigorous,
> problem space-based requirements specification language and promoted
> Leap SE as application development automation tool to migrate the
> development stages I would render appropriate applause.

  That's because
> it would be doing for the SRS language what a translation engine does
> now for an OOA model.

That is what it is precisely designed to do.

>
> However, people have been trying to come up with the formal requirements
> specification language that can be validated with the customer for ages.
> Alas, the closest they have come are niche languages like ATLAS or
> formal specification languages that simply aren't usable by typical
> customers. That lack of success bodes ill for attempting to shoe-horn
> an existing solution description notation.
>
> To put it another way, classes may provide a high degree of abstraction
> but identifying them from the problem space is still a highly
> methodological OOA task.

Again, the goal of Leap SE.

 Entire books have been written about
> developing just UML Class Diagrams. In addition, this forum exists in
> no small part to discussions about getting classes and their properties
> right.
>
> Assuming that a tool can do that abstraction properly represents
> substantial hubris.

OK.

Of course, the counter is that the Leap SE classes
> aren't meant to be used literally for development.

Yes. That is true.

 (The Leap SE
> strongly suggests that they are meant for development, BTW.)

At www.leapse.com/general.htm, see the FAQ "Can Leap SE Header Files
be used for Software Development?" The message is that they aren't
intended to be.

But that
> leaves the obvious question: Why bother? If they aren't classes that
> abstract problem space entities that are important to the solution, then
> why identify them rather than the classes that /do/ represent entities
> that are important to the solution?

As to why bother, because it can speed up the SDLC and shave months
off of analysis. Thanks for the great conversation. I'm sure I'll hear
more. :) -Brian
>
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindermda.com
> (888)-OOA-PATH

Relevant Pages

  • Re: OOA?
    ... SRS and your references to Leap SE -- both demonstrate OOA rather than ... That's because SQL is a very low level OOP implementation ...
    (comp.object)
  • Re: Using one design class to manage each use case?
    ... >broad enough to cover design. ... >patterns might be too big a leap, ... will solve them using all the standard design principles and patterns. ...
    (comp.object)
  • Re: Degrees of difficulty in electronic design
    ... I read a rant article on that and the author said that the ... >>80386 was designed first and then the dumbed it down. ... That was a real ivory tower design that ended up with about ... The first time their customers had a leap ...
    (sci.electronics.design)
  • Re: RCC Silver Spark Token #2 Call for designs.
    ... Quantum Grading--the next big leap: ... This coin neither exists in a state of ... make another and would like to get input on design and theme. ...
    (rec.collecting.coins)
  • Chez Watt : Re: James assuary and Archeopteryx
    ... > You then hypothesize that these patterns indicate design and ... > predict that design can be found in everything. ... More like leap, leap, leap...and then a miracle occurs. ...
    (talk.origins)