mayoff@cs.utexas.edu (Robert Mayoff) (03/30/91)
WORKSHOP ON
DOMAIN MODELING FOR SOFTWARE ENGINEERING
MAY 13, 1990
Austin, Texas (in conjunction with ICSE)
* DATE CHANGE *
Due to the delay in the mailing of the ICSE program, the POSITION
PAPER DEADLINE HAS BEEN EXTENDED TO APRIL 15, 1990
The workshop will provide a forum to present views, exchange ideas, and
clarify issues in domain modeling. Due to space limitations,
attendance will be limited.
(LONG) DESCRIPTION FOLLOWS:
This one day workshop is for researchers active in the area of creating
or using domain models for software engineering purposes. Domain
models are representations of application domains that can be used for
a variety of operational goals in support of specific software
engineering tasks or processes.
Although a variety of domain modeling approaches exists, it is
difficult to compare models and modeling techniques without an
understanding of the operational goals of a particular model.
Operational goals of domain models include:
% Requirements & Specifications -- Eliciting, verifying, and
formalizing software requirements and specifications.
% Automated Program Generation -- Generating code from a system
specification.
% Reverse Engineering -- Identifying the semantics of existing code.
% Explanation & Communication -- Capturing and communicating system
content as with an executive information or CSCW system
% Decision Modeling -- Understanding and resolving design decisions and
rationales.
Operational goals are always implicit in the construction of a domain
model and are essential to understanding the form and content of that
model. Unlike generalized knowledge representation projects like Cyc
[10] that attempt to provide a basis for modeling encyclopedic
knowledge, domain modeling explicitly acknowledges the commonly held
view [1] that representations are designed for particular purposes.
These purposesQthe operational goalsQinherently bias any particular
solution and dictate the final form of the model.
Previous Workshops
Researchers have been working in related areas for a number of years.
Two years ago there was sufficient interest to begin holding
specialized workshops in domain modeling.
Workshop on Domain Analysis - 1988
In conjunction with the 1988 OOPSLA conference in September 1988, a
workshop on domain analysis was held in San Diego [7]. The workshop
concluded that without an operational goal, the analysis of
application domains is at best an art, and at worst an exercise
overlaid with the baggage of competing commercial methodologies.
Furthermore, the representation of the target model depends on
operational goals. Consequently, a workshop on domain modeling was
organized in 1989 around operational goals and their resultant domain
models and modeling methodologies.
Workshop on Domain Modeling - 1989
The first workshop on domain modeling [8] was held in October 1989 in
New Orleans during the OOPSLA '89 conference. The major outcome of
this workshop was to verify the importance of generalized meta-models
and their use in instantiating domain knowledge into application domain
models.
Meta-Modeling & Model Instantiation
An application domain model is a specific representation of certain
aspects of an application domain. A meta-model is a generalized form
of the representation of a set of domain models.
An application domain model is an instantiation of a meta-model with
knowledge from a real world application area. This process takes place
within the context of a modeling methodology. A meta-model:
% is a formal structure or language,
% is computationally tractable,
% allows for reasoning and inference to support the operational goals.
Formality and computational tractability are requirements because
models and meta-models are designed to be used by computers.
Research Questions
The purpose of this workshop is to examine domain modeling approaches
from the viewpoint of their operational goals. Progress in this field
will only be made through the creation of meta-models that are actually
instantiated into application domain models. These concrete instances
can be used as a laboratory for conducting research about domain
modeling. Within this context, some of the research questions are:
Representation
% what are the necessary or sufficient conceptual primitives of a
particular representation (e.g. objects, relationships, constraints,
and behaviors)?
% how is the representation used to meet specific operational goals?
% what are limitations of the meta-model?
% is the meta-model sound? how does it prevent inconsistencies from
being expressed?
% what constraints of the operational goals led to limitations in the
meta-model (e.g. compiler technology, editors, model scale, type and
scope)?
Domain Classification and Analysis
% what types of domains can be modeled using the constructs of a
particular meta-model?
% is there a characterization of the coverage or degree of
completeness of the meta-model with respect to a class of application
domains?
% what terms can and should be used to compare and classify domains?
are domains ever disjoint? are domains ever orthogonal? are there
domain equivalence classes?
% what are the various dimensions by which application domains can be
classified (e.g. by specific application area, by generic application
area, software engineering phase, level of knowledge, and so on)?
Model Development, Instantiation, Evolution and Validation:
% what are the processes or methodologies for instantiation?
% what tools exist to facilitate the development and use of the
domain model?
% how are objects chosen for inclusion (or exclusion) in the model?
% does a methodology exist for validating the model?
% what standards of completeness (if any) can be applied to domain
models?
% what are the methods (if any) for evolving or combining domain
models?
Knowledge Structuring and Inference:
% what issues have arisen for structuring domain knowledge?
% what inference mechanisms are used in the meta-model? what
mechanisms are used in the instantiated domain model?
% how are temporal concepts handled in the model?
% can the model infer previously unknown or unrealized domain specific
structures and behaviors?
This workshop will provide a forum to present views, exchange ideas,
and clarify issues in domain modeling. Due to space limitations,
attendance will be limited.
*********************
Workshop Organizers
Neil Iscoe
EDS Research, Austin Lab
Austin, TX 78701
Gerald B. Williams
Andersen Consulting, CSTaR
Chicago, IL 60606
Guillermo Arango
Schlumberger Laboratory for Computer Science
Austin, TX 78720
******************************
POSITION PAPER DEADLINE APRIL 15, 1991
To submit a position paper, send 4 paper copies of a 3 to 5 page
abstract outlining your operational goals and domain modeling approach
to:
Neil Iscoe
EDS Research, Austin Lab
Austin, TX 78701
iscoe@austin.eds.com
workshop91@austin.eds.com
(512) 477-1892
If you miss the deadline, (or the workshop), but still want information
about what happened, send mail to:
workshop91@austin.eds.com
********************************************
References
See ([7], [8], [12]) for collections of relevant papers. References
([2], [3], [5], [6], [9], [11], [13], [14]) represent a selection of a
variety of approaches towards domain modeling. This list is intended
only as a starting point for those interested in the subject and should
not be considered complete.
[1] S. Amarel, ROn Representations of Problems of Reasoning About
Actions,S in Machine Intelligence 3, D. Michie, Ed., American Elsevier,
New York, 1968, pp. 131-171
[2] G. Arango, RDomain Analysis: From Art Form to Engineering
Discipline,S Proceedings of the Fifth International Workshop on
Software Specification and Design, Pittsburgh, PA, pp. 152-159, May
1989.
[3] D. Barstow, RDomain-Specific Automatic Programming,S IEEE
Transactions on Software Engineering, vol. SE-11, no. 11, pp.
1321-1336, November 1985.
[4] B. Curtis, H. Krasner, N. Iscoe, RA Field Study of the Software
Design Process for Large Systems,S Communications of the ACM, vol. 31,
no. 11, pp. 1268-1287, November 1988.
[5] P.T. Devanbu, R.J. Brachman, P.G. Selfridge, B.W. Ballard,
RLaSSIEQa Knowledge-Based Software Information System,S Proceedings of
the 12th International Conference on Software Engineering, IEEE
Computer Society Press, Los Alamitos, CA, pp. 249-261.
[6] N. Iscoe, Domain-Specific Programming: An Object-Oriented and
Knowledge- Based Approach to Specification and Generation. Ph.D.
Thesis, The University of Texas, May 1990.
[7] N. Iscoe, Ed., Proceedings of the Workshop on Domain Analysis, San
Diego, CA, September 1988.
[8] N. Iscoe, G. Williams, Eds., Proceedings of the Workshop on Domain
Modeling for Software Engineering, New Orleans, LA, October 1989.
[9] K. Kang, S. Kohen, J. Hess, W. Novak, A. Peterson,
RFeature-Oriented Domain Analysis: Feasibility Study,S Technical
Report, CMU/SEI-90-TR-21, Carnegie-Mellon University, November 1990.
[10] D.B. Lenat, R.V. Guha, K. Pittman, D. Pratt, M. Shepherd, RCyc:
Toward Programs with Common Sense,S CACM, vol. 33, no. 8, pp. 30-49,
August 1990.
[11] M. Lubars, The IDeA Design Environment,S Proceedings of the
Eleventh International Conference on Software Engineering, Pittsburgh,
PA, pp. 23-32, May 1989.
[12] R. Prieto-Diaz, G. Arango, Tutorial: Domain Analysis and
Software Systems Modeling, IEEE Computer Society Press, Los Alamitos,
CA, 1991.
[13] H.B. Reubenstein and R.C. Waters, RThe Requirements Apprentice:
An Initial Scenario,S Proceedings of the Fifth International Workshop
on Software Specification and Design, Pittsburgh, PA, pp. 211-218, May
1989.
[14] W. Robinson, RIntegrating Multiple Specifications Using Domain
Goals,S Proceedings of the Fifth International Workshop on Software
Specification and Design, Pittsburgh, PA, pp. 219-226, May 1989.
--
/_ rob <mayoff@cs.utexas.edu>
/_ Fun things to do with UNIX (#2 in a series):
/ echo "rsh `hostname` -n source eat.cpu &" > eat.cpu; source eat.cpu