Micro-Architecture of Software Components/
And
The Need For Good Mental Models of Software Subsystems

Leaders:
Joe Hollingsworth, Indiana University, and
Bruce W. Weide, The Ohio State University
Steve Edwards, The Ohio State University, and
Larry Latour, The University of Maine
Scope:
This group was actually envisioned as two separate groups: one focusing on micro-architecture issues and the other focusing on how software engineers form and express good mental models of their systems.

The task of the micro-architecture group was to focus on the details of both the structure and the behavior of software component interfaces and on the implementations of individual components, sets of components, and how they compose and "interoperate" with each other. The group was asked to consider issues such as certification, plug-compatibility, programming language features, and performance.

The mental models group was interested in how software engineers form internal mental models of the things they interact with in order to understand those interactions. Specifically, they were concerned with the problem of "behavioral rigidity". That is, they were concerned with avoiding avoiding software development approaches that solve particular problems at hand, since such approaches hinder their ability to "see" analogous problem solutions. Conventional programming languages do little to help these programmers develop good mental models of their systems. This is turn is an impediment to helping these same programmers overcome the behavioral rigidness of their designs.

The mental modelers were asked to explore (1) the methods by which humans develop good mental models of generic software subsystems, and (2) how existing programming languages support/hinder these efforts.

Goals of the Micro-Architects:
1. Discuss (and hopefully establish) why software architecture should be split into two sub-areas: micro-architecture and macro-architecture.

2. Discuss some existing practical experiences related to micro-architecture issues.

Goals of the Mental Modelers:
1. To make clear the definition and usefulness of "mental model".

2. To develop examples of how such mental models are developed and how they contribute to reusability.

3. To factor both formal methods and human factors into the development of mental models - "Formal methods help to represent subsystems precisely, but it is humans that develop mental models to understand these same subsystems."

Mutual Goals:
1. To look at micro-architecture concerns both from the knowledge inherent in an architecture and from the perspective of the software engineer as a thinking agent.

2. To agree to disagree, which we did a great deal of the time (both disagreeing and agreeing to disagree that is).

Working Group Final Report