home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr6 / proceedings / ascii / gomaa.ascii < prev    next >
Text File  |  1993-10-19  |  10KB  |  236 lines
  1.  
  2.  
  3.  
  4.  
  5. Metho ds  and  Tools  for  Domain  Specific  Software Architectures
  6.  
  7.  
  8.  
  9.                                                 Hassan Gomaa
  10.  
  11.  
  12.  
  13.                Department of Information and Software Systems Engineering
  14.  
  15.                                          George Mason University
  16.  
  17.                                       Fairfax, Virginia, 22030-4444
  18.  
  19.                                              Tel:  (703) 993-1652
  20.  
  21.                                       Email: hgomaa@isse.gmu.edu
  22.  
  23.  
  24.  
  25.                                                     Abstract
  26.  
  27.  
  28.       At George Mason University,a pro ject isunderway to support software engineering lifecycles,
  29.   methods, and environments to support software reuse at the requirements and design phases of
  30.   the software lifecycle, in addition to the coding phase. A reuse-oriented software lifecycle, the
  31.   Evolutionary Domain Lifecycle [1, 2 ], has been proposed, which is a highly iterative lifecycle
  32.   that takes an application domain perspective allowing the development of families of systems.
  33.   Current emphasis is on the domain analysis and specification phase of the EDLC for developing
  34.   an application domain model, which captures the similarities and variations of the domain.
  35.  
  36.  
  37.   Keywords: domain specific software architectures, evolutionary domain lifecycle,system fam-
  38.   ilies.
  39.  
  40.  
  41.   Workshop Goals:  To understand how others are approaching the domain specific software
  42.   architecture development problem.
  43.  
  44.  
  45.   Working Groups: reuse process models, domain analysis/engineering.
  46.  
  47.  
  48.  
  49.                                                     Gomaa- 1
  50.  
  51.  
  52. 1      Position
  53.  
  54.  
  55.  
  56. 1.1     The Evolutionary Domain Life Cycle
  57.  
  58.  
  59.  
  60. The Evolutionary Domain Life Cycle (EDLC) Model is a software life cycle model that eliminates
  61. the traditional distinction between software development and maintenance. Instead, systems evolve
  62. through  several  iterations.  Furthermore, because  new  software  systems  are  often  outgrowths  of
  63. existing ones, the EDLC model takes an application domain perspectiveallowing the development
  64. of families of systems. The EDLC model incorporates two related sub-life cycles, domain mo deling
  65. and target system generation. Domain modeling deals with developing the reusable requirements
  66. and domain specific software architecture for a family of systems, while target system generation
  67. deals with generating target systems from the domain model.
  68.  
  69.  
  70. A Domain Model is a problem-oriented architecture for the application domain that reflects the
  71. similarities and variations of the members of thedomain.  Given a domain model of an application
  72. domain, an individual target system (one of the members of the family) is created by tailoring the
  73. domain model given the requirements of the individual system.
  74.  
  75.  
  76.  
  77. 1.2     Domain Mo deling
  78.  
  79.  
  80.  
  81. In a domain model, an application domain is represented by means of multiple views, such that each
  82. view presents a different aspect of the domain [3]. The different views are developed iteratively.
  83.  
  84.  
  85.  
  86.     1. Aggregation Hierarchy. The Aggregation Hierarchy is used to decompose complex aggregate
  87.        ob jecttypes into less complex object types eventually leading to simple object types at the
  88.        leaves of the hierarchy. Objects types are either kernel, i.e., required in every targetsystem,
  89.        or optional, i.e., only required in some target systems. The Aggregation Hierarchy supports
  90.        the IS-PART- OF relationship.
  91.  
  92.  
  93.     2. Ob jectcommunication diagrams. Ob jects in the real world are modelled as concurrent tasks,
  94.        which communicate with each other using messages. Dynamic relationships between objects,
  95.        in the form of messages passed between objects, are shown by means of object communication
  96.        diagrams.
  97.  
  98.  
  99.     3. State transition diagrams.  Since each ob ject is modeled as a sequential task, an object may
  100.        be defined by means of a state transition diagram, whose execution is by definition strictly
  101.        sequential.
  102.  
  103.  
  104.     4. Generalization  /  Specialization  Hierarchy.  As  the  requirements  of  a  given  ob ject type  are
  105.        changed to meet the specific needs of a target system, the object type may be specialized by
  106.        adding, modifying or suppressing operations.  In domain modeling, the variants of a domain
  107.        ob jecttype are stored in a Generalization / Specialization Hierarchy (GSH), which supports
  108.        the IS-A relationship.
  109.  
  110.  
  111.     5. Feature / Object dependencies.  This view relates the end-user'sp erspective of the domain,
  112.        namely the features supported by the domain, to the object types in the domain model.  It
  113.        shows for each feature (domain requirement) the object types required to support the feature.
  114.        Also defined are any prerequisite features required and any mutually exclusive features.  This
  115.        view is particularly important for optional features, since it is the selection of the optional
  116.  
  117.  
  118.  
  119.                                                          Gomaa- 2
  120.  
  121.  
  122.        features,  and the ob ject types requiredto supp ortthem,  that determine the nature ofthe
  123.        desired target system.
  124.  
  125.  
  126.  
  127. 1.3     Generation of Target System Specification
  128.  
  129.  
  130.  
  131. A Target System Specification is a problem-oriented architecture for an individual target system,
  132. i.e., a  member  of  the  family  of  systems  that  constitute  the  domain.  It  is  a  tailored  instance  of
  133. the  Domain  Model.  Requirements  are  reused  by  selecting  those  features  required  in  the target
  134. system and then tailoring the domain model, subject to the appropriate feature object dependency
  135. constraints, to generate the target system specification.
  136.  
  137.  
  138.  
  139. 1.4     Domain Modelling Environment
  140.  
  141.  
  142.  
  143. A proof-of-concept experiment has also been carried out to develop a prototyp e domain mo deling
  144. environment [Gomaa91b], which consists of an integrated set of software tools that support domain
  145. modeling and target system requirements elicitation. The environment uses commercial-of-the-shelf
  146. software as well as custom develop ed software.  The graphical editors supported by the Software
  147. Through Pictures CASE tool are used to representthe multiple views of the domain model, namely
  148. the Aggregation Hierarchy, the Ob jectCommunication Diagrams, the Generalization / Specializa-
  149. tion Hierarchies and the State Transition Diagrams.  However, the multiple views are semantically
  150. interpreted  according  to  the  domain  modeling  method.  The  information  in  the  multiple  views
  151. is extracted, checked for consistency, and mapped to an object repository. The feature / ob ject
  152. dependencies are defined using a Feature / Object Editor.
  153.  
  154.  
  155. A knowledge based tool is used to assist with target system requirements elicitation and generation
  156. of the target system specification [4].  The tool,  implemented in NASA's CLIPS shell,  conducts
  157. a dialog with the human target system requirementsengineer,  prompting the engineer for target
  158. system specific information. The output of this tool is used to adapt the domain model to generate
  159. the multiple views of the target system specification.
  160.  
  161.  
  162. The prototype environment is a domain independentenvironment.  Thus it may be used to support
  163. the development of a domain model for any application domain that has been analyzed,  and to
  164. generate target system specifications from it.
  165.  
  166.  
  167.  
  168. 1.5     Current Status
  169.  
  170.  
  171.  
  172. A major issue in the domain modeling approach to developing domain specific software architectures
  173. concerns how effectively it addresses scaleup. The problem is not so much the size of the domain
  174. (which is a "common" software engineering problem) but the degree of variability and volatility
  175. in  the  domain.  A  relatively  stable  well  understood  application  domain  is  likely  to  be  the  best
  176. candidate for domain modeling.  The method has been applied to a real-world problem,  NASA's
  177. Payload Operations Control Center (POCC) domain.
  178.  
  179.  
  180. There  is  likely  to  be  some  tradeoff  between  scaleup and  the  amount  of  variation  allowed  in  a
  181. domain model. Too much variation is liable to lead to acombinatorial explosion.  We are currently
  182. exploring the concept of feature packages as an approach to scaleup, where features are grouped
  183. and treated as one super feature.  The current approach is oriented towards concurrent systems,
  184.  
  185.  
  186.  
  187.                                                          Gomaa- 3
  188.  
  189.  
  190. including real-time and distributed systems.  We are also adding an information modeling view,
  191. to address more information intensive applications.  Also under investigation are the design and
  192. implementation phases of the EDLC [5].
  193.  
  194.  
  195.  
  196. 1.6     Acknowledgements
  197.  
  198.  
  199.  
  200. The author is indebted to his research colleagues and students L. Kerschberg, R. Fairley, C.Bosch,
  201. E. O'Hara-Schettino,  V. Sugumaran,  and I. Tavakoli,  for their invaluable assistance throughout.
  202. This work was sponsored in part by NASA Goddard Space Flight Center and the Virginia Center
  203. of Innovative Technology.  The Software Through Pictures CASE tool was donated to GMU by
  204. Interactive Development Environments.
  205.  
  206.  
  207.  
  208. References
  209.  
  210.  
  211.  
  212. [1]  H. Gomaa, R. Fairley, and L. Kerschberg, "Towards an evolutionary domain life cycle model,"
  213.      in OOPSLA'89,New Orleans, Oct. 1989.
  214.  
  215.  
  216. [2]  G. H. and L. Kerschberg, "An evolutionary domain life cycle model for domain modeling and
  217.      target systemgeneration,"  in Proceedings of the Workshop on DomainModeling for Software
  218.      Engineering, International Conference on Software Engineering, Austin, TX, May 1991.
  219.  
  220.  
  221. [3]  H. Gomaa, "An object-oriented domain analysis and modeling method for software reuse," in
  222.      Proceedings of the Hawaii International Conference on System Sciences, Jan. 1992.
  223.  
  224.  
  225. [4]  L.  Gomaa  H., Kerschberg  and  V.  Sugumaran,  "A knowledge-based  approach  for  generating
  226.      target systemsp ecifications from a domain model," in Proceedings of the IFIP World Computer
  227.      Congress, Madrid, Spain, Sept. 1992.
  228.  
  229.  
  230. [5]  H. Gomaa,"A reuse-oriented approach for structuring and configuring distributed applications,"
  231.      Software Engineering Journal, Mar. 1993.
  232.  
  233.  
  234.  
  235.                                                          Gomaa- 4
  236.