From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,FROM_ADDR_WS autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 27 Aug 93 19:50:21 GMT From: cis.ohio-state.edu!news.sei.cmu.edu!lph@ucbvax.Berkeley.EDU (Larry Howar d) Subject: Re: TRI-Ada '94 topics Message-ID: <1993Aug27.155021.18331@sei.cmu.edu> List-Id: In article , 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