The T&M approach attempts to achieve application orientation in software develop-ment. Application orientation focuses on software development, with respect to the future users, their tasks, and the business processes in which they are involved.
Application-oriented software is thus characterized by high usage quality, in other words, on the characteristics that a system should show when actually used. We can identify some important characteristics of this type of software:
● The system functionality is oriented to the tasks to be solved within the application domain.
● The system is easy to use and manipulate by its designated users.
● The processes and steps defined in the system can be easily adapted to the actual requirements, depending on the individual application domain.
Based on object-oriented design and techniques, this approach combines many different elements, such as a model with design metaphors, application-oriented docu-ments, and an evolutionary development strategy with prototyping. But the T&M approach is not only a collection of best practices. The underlying idea links its differ-ent elemdiffer-ents in a way that makes designing good application software easier. You start by choosing a guiding metaphor and fleshing it out by appropriate design metaphors.
So, for example, you decide to build a software system as an expert workplace for a customer advisor (guiding metaphor) in a bank. You add different form sheets, folders and trays as well as tools like an interest rate calculator or an account finder as equip-ment to an electronic desktop (design metaphors). Constructing the system you look at the patterns like “Interrelation of Tools and Materials” related to the design metaphors. They fit into the proposed model architecture. As you set up your project you will find guidelines and document types that put the application-oriented idea to work.
Building large object-oriented systems is a demanding task. Today, many developers have realized the need for a clear architectural concept for these systems. The central architectural idea behind the T&M approach is that the structures of the application domain and the software system should be similar. This structural similarity means that objects and concepts from the application domain are taken as a basis for the technical software model. The result should be a close correspondence between the application-specific terminology and the software architecture. This is not a new idea as it was the initial spark for Simula, the first object-oriented language. But we took the idea from designing systems from the small ones (e.g., on the GUI level) up to the overall structure of large distributed systems.
Having similar structures for the two worlds, that is, the application domain and the software model, offers two major benefits. First, the application system represents the real-world objects and work-specific terms for the users. This means that these users can organize their work in a familiar way. Second, the developers have a development plan for their system. They get an idea of how to structure the “landscape” of the domain. At a more fine-tuned level they can put software components and application concepts in specific relationships, so that they can be easily identified when the soft-ware needs to be adapted to real-world changes.
To deserve the term “interactive,” an application software has to combine a task-oriented functionality and suitable handling and presentation means. From this per-spective, software development is a design challenge in the original sense: both the form and the contents have to match. This brings up the question of what
“shape” a software product should take and how it should be handled to help com-plete the task. Software developers should be supported in this design challenge.
Within the scope of the T&M approach, this support is provided in the form of a
“guiding metaphor.”
A guiding metaphor for our purposes is a pictorial term that characterizes a unifying view in the software development process. As a familiar term it helps both users and developers to understand and design the application software. This means that it is not used for GUI design but to shape the functional and behavioral characteristics of the entire application.
Currently, our most successful guiding metaphor is the expert workplace.
This metaphor has proven valuable in the large number of software projects we have conducted in the banking and service industries. These industries primarily support office work done by qualified staff, in other words, activities that, in addition to industry-specific knowledge and experience, require some amount of independent work and initiative.
When looking at the expert workplace as a guiding metaphor, the reader should realize some fundamental ideas related to it:
● A workplace is a place where people accomplish their work tasks.
● It is furnished or equipped with the necessary things for doing the job.
● An expert workplace is meant for a person who knows how to cope with the different work tasks of the job.
● The expert is the actor; the workplace simply offers the means to an end.
Other guiding metaphors, such as the functional or back-office workplaces, have also proven to be valuable in different working contexts or domains.
Model and design metaphors
A guiding metaphor should be “granular” to ensure that it can really be under-stood. To achieve this goal, we use a set of matching design metaphors that describe that “leading” metaphor in more detail.
A design metaphor uses an object from the real world to describe a concept or a component of the application system. Such a design metaphor creates a common basis of understanding for developers and users, as it clearly refers to a common background of experience and represents an understandable term.
To match the guiding metaphor of a workplace, we use the following design metaphors: tool, material, automaton, and work environment. Obviously, these metaphors originate from the context of human work. When working, people take intuitive deci-sions between the things that represent their work objects, and things they use to get their jobs done. Accordingly, our definition of the fundamental metaphors, or tools and materials, is as follows:
A tool supports recurring work processes and actions. It is normally useful for a dif-ferent set of tasks and objectives. A tool is handled by its users according to the require-ments of a situation and put aside when it is not needed. It does not dictate fixed work steps or processes. If it is a software tool, it allows users to manipulate work objects interactively.
A material is a work object that is manipulated so that it will eventually become the work result. Materials are manipulated by use of tools. Software materials embody
“pure” domain-specific functionality. They are never used directly and are never active on their own. A software material is normally characterized by its behavior rather than its structure.
In an office environment, there are more than tools and materials. Today, many tedious work routines are done automatically. We thus introduced the automaton as an additional design metaphor:
An automaton completes a task that has been fully specified in advance and pro-duces a defined result in defined variants. Once parameterized, an automaton can run without intervention over a lengthy period of time. A software automaton normally runs in the background. It is initially configured by the user, fed with additional infor-mation upon demand, or stopped in case of emergency. An automaton may have a simple interactive interface.
Tools, automatons, and materials need a place where they can be provided, arranged, and stored. This is the purpose of the work environment metaphor.
A work environment is the place where work is completed and the required work objects and tools are provided. Work environments embody a spatial concept and ordering principle. We distinguish between personal workplaces, allowing privacy and an individual arrangement of things, and generally accessible rooms in a work envi-ronment. In an organization, we can often define meaningful workplace types with a matching set of characteristic equipment.
In the context of office work, and in many other domains as well, it is no longer sufficient to support individual work. Application systems for cooperative work repre-sent new challenges to software developers. Our experiences in this field led to the conclusion that cooperative work can be supported by work tools and objects similar to those for the individual workplace. However, cooperative work involves new resources that address the special character of cooperation. This includes design metaphors like archives, circulation folders, and dockets.
What is a tool?
This expansion of our design metaphors to include cooperative work needs to fit into the context of the selected guiding metaphor. In cooperative work, as in individual work, there are users who have to decide within their work situation whether they handle a predefined standard process, or whether specific changes to the workflow and the work distribution are meaningful. Other workplace types and forms of cooperation represent other requirements for cooperative work support. Based on the cooperation types, we have put together a basic choice of cooperation tools and media.
For developers, application orientation means that they have to understand the tasks they are supposed to support with appropriate software systems. To achieve this goal, they have to gain access to the specialized knowledge and experience of the experts in the application domain. The keyword here is evolutionary system development, because this type of development process is oriented to close cooperation between the developers and the users. However, cooperation needs a foundation. Therefore, we use application-oriented document types and the prototyping concept.
Using application-oriented document types as a necessary basis to understand the concepts and tasks of an application domain is nothing new. What’s important to understand is that these document types describe the application under development in the specialized user language. These document types are considered an expansion and specialization of the UML standard documents. We use the “classic” UML document types for the technical design. In addition, we use the following application-oriented document types:
A scenario is an interpretation of an organization’s business use cases. It describes the current work situation, focusing on the tasks within the application domain and how these tasks will be completed by the use of tools and work objects. Scenarios are formulated by the developers based on interviews with users and other groups involved in the application domain.
A glossary defines and reconstructs the set of terms of the specialized language in the work environment. Glossary entries are written by the developers parallel to the sce-narios. They provide initial ideas about the materials needed in designing the system.
System visions correspond to use cases. They are at the transition point between the analysis of the application domain and the construction of the future system. Based on the scenarios, system visions anticipate the future work situation. They are oriented primarily to the developers and help build a common system vision. They describe the ideas about the domain functionality and how tools, materials, automatons, and other system components should be handled.
A prototype is an executable model of the application domain, representing an important and constructive enhancement of the system visions. A prototype makes the ideas about the system “tangible.” In particular, so-called “functional prototypes” are of central significance not only in the developers’ communication with the users, but also in giving developers the necessary experience and experimental basis for the technical construction of the system. This means that prototyping plays a central role in our approach.
To analyze cooperative work and design that is appropriate to application software, we need to extend the set of document types described above. Scenarios, glossaries, and system visions can be used to describe the different set of tasks and activities from the workplace perspective. What’s missing is an overall view. To solve this problem, we have successfully used so-called cooperation pictures.
Evolutionary
A cooperation picture is an extension of use case diagrams, which are used for group discussion and workshops. Cooperation pictures are essentially based on well-understood pictograms that represent the work objects and information to be exchanged between all participating parties or “actors.”
Once we have defined our guiding and design metaphors, together with document types and prototypes, we have a set of interrelated concepts and techniques on hand to support software development that is focused on the application domain. This means that the developers have all the prerequisites to start working towards the goal set: high usage quality. However, whether or not this goal can really be achieved depends largely on the right implementation of the concepts and the use of tools during the develop-ment process. Therefore, we think that it is mandatory also to prepare a set of instruc-tions for the design of this process for the developers. The basic principle is then to look at software development not as a primarily technical or formal task but as a com-munication and learning process. Learning and communicating are evolutionary processes driven by constant feedback between the participants. This means that we agree with the basic principles of the Unified Process.
This evolutionary process between development and feedback includes basically all documents pertaining to that project. It is not a matter of completing milestone documents sequentially in a defined order, but of linking the analytic, modeling, and evaluation activities as needed. This obviously conflicts with the principles of the clas-sic waterfall or phase models, but it can be harmonized with the core workflows of the Unified Process.
The evolutionary process, in our definition, is realized in the form of so-called author-critic cycles in all our projects.
Our author-critic cycle means switching between analyzing, modeling, and evaluat-ing activities, where the developers are normally the authors. Their work objects are documents and prototypes. The critics are normally all participating parties who have the required specialized or domain knowledge. In the sense of application orientation, these are normally the users. Ideally, the author-critic cycle is iterated quickly and often.
To better understand our approach, it is important to bear in mind that the prob-lems identified in the feedback process determine what activities should follow next and which documents should be prepared. In this sense, there is no predefined sequence of documents and work steps. You could basically prepare any document at any given time. Of course, there is no doubt that the entire set of activities have to be planned and controlled in every project and cannot be subject to individual arbitrari-ness. What we should take home from these definitions is that the basic process itself is determined by application-oriented issues rather than by a technical mechanism.