Thomas J. Wheeler, Ph.D. is an assistant professor at the University of Maine. He received the Ph.D. degree in EE/CS in 1988. He started at the University in the Fall of 1999 after a thirty four year career as a Physicist, Electronic Engineer and Computer Scientist a US Government research laboratory.

Research interests

My research interests are centered around computer system and software design, with a focus on the concepts and technologies involved in the development of multi-domain complex systems by integrative means. This includes the design of subsystems which must interoperate with other, different domain subsystems, the design of boundaries between software subsystems and the design the boundary between humans and computers. In attempting to deepen the understanding and improve of the art of this type of design, I have developed a framework [ref mdl] providing a common organizational pattern for design thoughts, within and across domains. It organizes design thoughts, concerns and concepts into four categories: (1)those within and about a domain (and within its culture), (2)those about the conceptual design of the system, (3)those about structuring the realization of that design, and (4)those about implementation and resource issues. These categories are then organized into a hierarchy of four levels, bridging the fundamental system development-semantic gap, from the domain issues at the top to the implementation issues at the bottom, based on the closer relationship between issues at adjacent levels. It assists designers, within a domain, in categorizing and organizing their thoughts, clarifying whether thoughts are at the same or different levels, highlighting connections among related concepts within a level and across adjacent levels, and providing a framework for communication among designers. Likewise, it assists designers across domains, in surfacing interface issues at each level, separating issues at a level from those at other levels, highlighting the connections within and across levels, and fostering their addressing in the context of corresponding level issues in the other domain. Interface design is based on conceptualizing a boundary in a way that has an intuitive map with the conceptualizations of the domains which bound it. In terms of the model outlined above, designers work within domains, developing explicit conceptual structures of each of the domains with which the system deals. They then work across domains, mapping domain strictures onto more abstract conceptual structures in the interface between the domains, where the actual interaction takes place. A simple example of a way of doing this is to conceive of a boundary as a special case of the concepts with which the bounding domains are conceived, {e.g. a database, exporting a view to be displayed using a spreadsheet using the Unix "pipes and filters" paradigm, will export a sequence of records(a database concept), as a sequence of characters (the (abstract)conceptualization understood by all Unix programs, this is a case of a lowest common denominator conceptualization) through the pipe and the spreadsheet will parse the character sequence with an AWK script into rows of cells(a spreadsheet concept). }

The basis for this approach is the now time tested strategy of separation of concerns along with information hiding by representing the boundary as an abstract interface. The rationale for our approach is that these two principles indicate what to do but do not provide much guidance as to how. There are three parts to our approach. First, we provide guidance by an elaboration of separation of concerns, categorizing and ordering them into conceptual levels, providing prescriptive guidance for designers and support for smoothing the transition in thinking from the usage domain to the implementation. This enables thinking about a system in levels, addressing the interface bridging the boundary level by level, and enabling segues between related concerns in different levels, using different paradigms inside each of the boundaries while merging at the boundary[RefMdl]. Second we provide guidance in making apparent all of the concepts which a designer needs to be cognizant of and to elaborate in the design of an interface, the context in which these concepts need to be placed to fully understand them, and the concepts which need to be used to provide the content of the object defined by the interface[Latour, Wheeler & Frakes]. Third, abstract interfaces provide a (syntactic) mechanism for interaction with a (sub)system, but falls short of providing a basis for accommodating "all of the assumptions" [parn] which the user has to make about the system and its use. We expand upon abstract interfaces by having the abstraction presented by the interface accommodate additional concerns, such as semantics and ordering [wheeler thesis] and by modularizing of the interface, often as layers[wheeler & richardson91], separately addressing the concerns within the interface in separate modules. The main problem, motivating and focussing my research, is the development and evolution of distributed systems constructed from independently developed subsystems. Each subsystem is designed to perform functions in some domain, and must inter-operate with other subsystems, which often are designed relative to other domains. Many of the problems encountered in attempting to integrate systems together have not been solved by the current interface technologies, techniques and methods. Development teams must deal with an unbounded collection of concerns in attempting to inter-operate with the other, existing subsystems in the network. Among these concerns, few of which are explicitly addressed by the network or subsystem documentation, are interface design, semantics and pragmatics of interfaces and its usage, lack of intuition for the "culture" (natural thought patterns) of the developers of the other subsystems, interoperation mechanisms, architectural concerns[garlan], other aspects [kazalis], etc.

A second, complementary, interest is in exploring a different perspective on Software Engineering. It is primarily educational, but has a research aspect to it. In my many years of designing, teaching design, and observing and working with designers, I have found and analyzed evidence which both supports some of, and refutes others of, the currently understood tenets of Software Engineering. In particular, the fundamental technical concepts such as separation of concerns, modularity, abstraction, etc. have proved to be valuable and worth the designer's effort to master them, while other concepts such as life-cycle models, management models, etc. have not. The particularly hard problems of constructing reasonable sized systems out of existing subsystems, which those concepts were meant to solve, have evaded solution by orders of magnitude[garlan], indicating that there is a lot more to be done. Ideas such as multi-discipline, multi-faceted and integrative design thinking have not found there way into the SE culture or curriculum. The project focus of mainstream Software Engineering, moreover, doesn't appear to have a payoff proportional to the amount of effort that has been expended in developing it and teaching it. There are scores of SE books centered on the process and only one or two centered on theory, techniques and principle. In watching the results of SE education on scores of graduates of a SE curriculum, the process orientation appeared to be most useful in producing view graphs for meetings while the principles orientation appeared to be most useful in developing and evaluating higher quality systems. The aim of my work in this area is to develop a discipline of Computer Science and Engineering Thinking and teach it, as well as multi discipline, integrative design to upper level undergraduates, graduate students and CS/SE professionals

[Edit my profile]