Re: TRI-Ada '94 topics

[cis.ohio-state.edu!news.sei.cmu.edu!lph@ucbvax.Berkeley.EDU (Larry Howar]

In article <CCFDKz.1JA@inmet.camb.inmet.com>, stt@spock.camb.inmet.com
(Tucker Taft) writes:
|> In article <9308261918.AA10006@eight-ball.boeing.com> 
|>   crispen@eight-ball.boeing.com (Bob Crispen) writes:
|> 
|> >Dick Dye asks about hot topics that ought to be considered for
|> >TRI-Ada '94.
|> >
|> >One topic which isn't hot, but which I think should be, is the issue of
|> >architecture.  
|> 
|> [Other good stuff deleted]
|> 
|> A related topic, that is hot in the OO world, is the concept
|> of "reusable frameworks."  As is true in most engineering disciplines, 
|> people originally tried to reuse very small components, and at some point 
|> discovered that the relationships between components are often
|> at least as important as the components themselves.  A reusable
|> framework is essentially a bunch of extensible types/classes/packages that
|> are interrelated, but intentionally incomplete.  
|> 
|> To "reuse" a reusable framework, one extends the various 
|> types/classes/packages in application-specific way, and
|> can quickly get up a nearly fully functional application.
|> 
|> [contrasts with "a reusable library of classes/packages" (and it's
|> apparent he means a library of reusable classes/packages ;')
|> 
|> I agree that many people have trouble understanding exactly
|> what is a "software architecture."  However, when they see
|> a preintegrated reusable framework, there is little doubt 
|> what it is.  Seeing an existing framework also seems to give 
|> people ideas about how they could think of building 
|> their own sets of applications by separating the issues into 
|> the job of designing and building the framework, versus the 
|> job of extending and populating the framework with more specific components.

A technical report entitled "Structural Modeling: An Application Framework and
Development Process for Flight Simulators" (CMU/SEI-93-TR-14) is in the final
stages of approval and will soon be made available through the SEI's normal
distribution channels (e.g., DTIC).

I would point out that application frameworks seem to vary in the degree to
which composition is fixed and the degree of completeness of parts.  Some
address part integration and interoperability in the context of fixed
compositions of parts, making such frameworks close to a commonly embraced
notion of software architecture.  Others address these issues for variable
compositions of instances of part types (abstract or fully deferred classes),
which requires that developers subsequently partition the application into
fixed compositions of instances of the part types and then complete these
instances.  The structural models we have developed for air vehicle
simulations have both fixed and variable part compositions and structural
elements (part types) that vary in degree of completeness.

[please forgive the preceeding Sentences From Hell]

These differences in the generality of application frameworks naturally
affect process.  If partitioning must be performed first, then defining the
application framework, as relationships among particular parts, comes later.
If the application framework is developed first, as relationships among kinds
of parts, then partitioning comes later.  What should be suspect is any
approach that defers defining the relationships among the application's parts
until after they are realized as software... or never ;').







--
Larry Howard
Software Engineering Institute, Carnegie Mellon University
lph@sei.cmu.edu, (412) 268-6397   NeXTmail: vitruvius!lph@eclipse.pgh.pa.us