Structuring Knowledge for Reuse

After reading this chapter, you should be able to: Explain why structuring and engineering knowledge is important for reuse. Read and draw mind maps for vague information. Define what a glossary is, give examples for using it in software engineering, and explain how it structures knowledge. Explain the relationship between glossaries and domain models. Name and briefly describe well-known informal and semiformal approaches in the area of structuring knowledge for reuse. Formulate knowledge as patterns and explain why patterns are important for representing knowledge.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

3.1 Objectives of this Chapter

After reading this chapter, you should be able to:

• Explain why structuring and engineering knowledge is important for reuse.

• Read and draw mind maps for vague information.

• Define what a glossary is, give examples for using it in software engineering, and explain how it structures knowledge.

• Explain the relationship between glossaries and domain models.

• Name and briefly describe well-known informal and semiformal approaches in the area of structuring knowledge for reuse.

• Formulate knowledge as patterns and explain why patterns are important for representing knowledge.

Many informal and semiformal structuring techniques address elicitation of knowledge and the process of making it reusable. They are concerned with the human and cognitive abilities of humans.

3.1.1 Recommended Reading for Chap. 3

• Cockburn, A., Writing Effective Use Cases. 14th printing. 2005, Reading, MA: Addison-Wesley

• Gamma, E., et al., Design Patterns – Elements of Reusable Object-Oriented Software. 1995, Reading, MA: Addison-Wesley

• Larman, C., Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. 2nd ed. 2002, Upper Saddle River, NJ: Prentice Hall

3.2 The Vision of a Shared Language

The map in Fig. 1.8 showed various interfaces between sources of knowledge and those in demand of knowledge for carrying out a certain task. Creating and transferring knowledge is at the core of knowledge engineering. For explicit knowledge, certain tasks are crucial:

• Logistics of knowledge: how to transfer and route knowledge through a network of people, computers, and repositories. This is mainly a technical task.

• Encoding existing knowledge and experience in a form suitable for storing, transferring, and engineering.

• Engineering knowledge, which means to compare, evaluate, and combine it. Knowledge also needs rephrasing, restructuring, and representing in a way appropriate for users.

Note the emphasis on structuring and presenting knowledge for the user! Structure and representation of knowledge do not need to be optimized for the author, but for the intended readers. This claim holds not only on technical levels but also for content and representation. Matching existing material to new demands is a difficult task. To be successful, one must establish a connection on all three levels: technical, contents, and presentation. Those three levels resemble the three levels of Fig. 3.1: Language and technical connections establish data transfer. Contents and structures use the data connection, but effective information transfer also requires mechanisms for agreeing on contents. An author has managed his part of the knowledge transfer successfully only when the transferred information is presented in a way that allows users to associate their own knowledge and context with it. In Fig. 3.1, the correspondence on each level is emphasized.

Fig. 3.1

Effective knowledge transfer requires appropriate connections on three levels

3.2.1 Example 3.1 (Challenges for effective knowledge transfer)

There are several reasons why such a connection is difficult to establish and to use effectively:

• Some of the “existing” knowledge is tacit and can only be accessed by talking to its owners. For example, a project manager carried out many project estimations but never cared to describe how he performs them.

• The terminology used by the participants is inconsistent. There is often a mutual misunderstanding when requirements analysts talk to developers: Analysts try to use customer terminology, whereas developers prefer to think in terms of solutions. Even the terms they use are different.

• Customer vocabulary is often highly specific to their respective domain. It takes analysts a long time to learn it and to use it correctly. Problems and constraints of a domain need to be expressed in the right vocabulary in order to fully understand them. Using the right vocabulary is also a prerequisite for customers to validate captured requirements. Fischer [42] calls this relationship the “symmetry of ignorance” between those who do not know possible solutions and those who do not really understand the problem.

• Different sources of knowledge use inconsistent terminology, which makes it hard to compare, evaluate, and combine their contributions.

• Users in demand of knowledge use inconsistent terminology: When they make a query or ask for support, their requests cannot be mapped to existing terminology.

• Users in demand of knowledge ask on the wrong level of abstraction. Instead of stating their “problem,” they ask on the solution level, because they are already locked into some solution path.

• A user often needs more than one piece of information or knowledge. It is not sufficient for the knowledge management initiative to deliver one piece per query. Instead, several pieces must be combined in a new way. Different contexts and different problems may be able to reuse knowledge, but rarely just as is.

• Knowledge engineers sometimes prefer a format or presentation that knowledge workers are not interested in. A formula may have a lot of appeal for knowledge engineers, but software engineers working with natural language requirements might not like it (Fig. 3.2).

Fig. 3.2

Overview of challenges in the three-level communication for knowledge transfer

A language common to all stakeholders could help to overcome several of these hurdles. However, developing a common language is a nontrivial problem. Chapter 4 will comment on some endeavors undertaken to establish common languages with a precisely defined vocabulary and logically sound connectors for forming unambiguous sentences, such as and, or, xor. In software engineering, such a vision is still out of reach and may always be.

When we intend to define a common language, we need to consider three aspects:

• Syntax: symbols and well-formed terms compiled from those symbols.

• Semantics: the meaning of well-formed sentences and terms.

• Pragmatics: the way of using the language properly, “as intended.”

Those three aspects are well-known from programming languages. They must also be considered when defining a language for human use. Not all aspects must be fully or formally defined – but if they are not, there is room for interpretation and misunderstanding.

Please keep in mind our goal: We want to cope with the above-mentioned challenges of sharing and transferring knowledge. We propose languages to express knowledge in an appropriate way. Some situations call for sophisticated formalisms, whereas others are better served by rather informal techniques.

Mnemonic 3.1 (Elegance and usefulness)

From a software engineering perspective, we should not fall in love with an elegant formalism but keep the initial goal in mind. Professional software engineers need to balance effort for structuring with improved ability to carry out their knowledge-intensive software engineering tasks.

3.3 Overview and Comparison of Structuring Approaches

In this chapter, different ways of building a common reference will be discussed. A number of representative approaches will be described and related to software engineering. We will start with simple and rather informal techniques, such as glossaries and mind maps. Typical software engineering methods of defining common reference models include use cases, domain models, and metamodels. They cover the middle ground in the following spectrum of formality. More formal techniques based on ontologies or Semantic Web are only starting to be applied to knowledge-intensive software engineering tasks.

Table 3.1 shows a spectrum of approaches. It is roughly ordered by the degree of formality used, although approaches diverge along several dimensions. There are more or less fine-grained structuring mechanisms and techniques. Some support human interaction, whereas others are tuned toward computer-based knowledge engineering. About half of the approaches are specific to software engineering, whereas the others are generally applicable.

Table 3.1 Spectrum of selected approaches for semiformal knowledge structuring

Because there is no one single, agreed-upon formalism for representing knowledge, professional software engineers need to know several options. When they face a concrete problem in a project or software organization, they should be able to choose from a collection of alternatives. This chapter is supposed to present an overview of rather diverse options. They may all be relevant to daily software engineering work.

Using Table 3.1: When choosing an approach for a software engineering task, one should consider goals and constraints:

• Will the output match the demanded format and contents for the task at hand? There is no need to speculate about advanced properties of a given formalism if it cannot possibly provide the required outputs.

• Will participants be able and willing to provide all required inputs?

• Will participants be able to handle the approach in terms of formalism, previous knowledge (concerning software engineering concepts), and representation of the output?

• Is it economically feasible to teach those participants who do not know the formalism yet or does the approach work even when the technique is not fully mastered?

• What degree of formalism and granularity, hence effort, is required to identify and present a desired subset of existing knowledge? Is that effort in balance with expected gains?

3.3.1 Example 3.2 (Use case terms)

Use cases do not offer mechanisms for consistent terminology. But use cases are fairly well accepted by customers and software engineers as a common language. Although the inputs should be easy to provide, use cases must not be considered a potential approach for deriving consistent vocabulary.

3.3.1.1 Example 3.3 (UML domain model)

A UML domain model may serve that purpose but will not be appropriate in many other situations: If intended participants do not know UML, many of the well-known advantages of UML do not count.

3.3.1.2 Example 3.4 (Generating code)

Along the same line, generating code from metamodels may be a valuable approach in many environments – but only if there are skilled people to provide models in short time. A sophisticated technique like code generation may require a long learning process. This can be a psychological and economical reason for avoiding such a technique, although it could be useful in the long run.

3.4 Structuring Vague Information: Mind Maps

In many software engineering activities, the expertise and knowledge of several experts need to be combined. Examples include early requirements phases, project planning, or software process improvement. Sometimes, creativity techniques will be applied to elicit vague and tacit knowledge from stakeholders or engineers. From the viewpoint of structuring knowledge, there are a number of techniques to support stakeholders in externalizing and structuring unrelated pieces of knowledge.

3.4.1 Example 3.5 (Brainstorming and mind maps)

Imagine a team developing administrative shrink-wrap software for personal tax declarations. Some of the features in their next release have been defined through earlier announcement or triggered by customer requests. However, the team wants to add a few unique selling points to the software. For that purpose, the project leader schedules a meeting with marketing, developers, and a quality specialist. After the introduction, there is a brainstorming session. Brainstorming is a general creativity technique with defined rules:

• There is a clear topic, announced by the moderator.

• Participants are invited to associate freely and contribute whatever they want. There is no criticizing or discussion during the brainstorming session.

• The session is up to 20 minutes long.

• Participants are encouraged to refer to earlier contributions, so that combined associations transcend individual ideas.

The team ends up with a blackboard full of words and short phrases (Fig. 3.3). There are several suggestions for new features, but also the name of a low-cost supermarket (PennyWise) as a role model for marketing the software successfully. Someone suggested starting a PR campaign. From the feature of “automated tax calculation,” someone was inspired to add “one-click tax wizard.” This idea caused a lot of laughter and sparked several new ideas – although no developer could imagine exactly what a “one-click tax wizard” would do or how it could be implemented.

Fig. 3.3

Blackboard with brainstorming results about “unique selling points” for tax software

Brainstorming is a good way to open the mind for unexpected relationships and associations. In our terminology, brainstorming can be a first step toward externalization or map-building. However, brainstorming results usually require interpretation, structuring, and critical reflection. Whereas criticism and discussion are not allowed during the brainstorming session itself, there is even more demand afterward. In the above example, the one-click tax wizard may be unrealistic, but it can be a vision for packaging a set of new features. Some surfaced ideas might be interesting but too expensive to implement.

Therefore, there needs to be a structuring step in which the brainstorming results are reviewed, explained, and sorted out. Mind maps are close to vague and tacit knowledge. Although they have even been used to take notes during brainstorming, brainstorming purists will not use mind maps for brainstorming: Mind maps impose structures on the contributions, which they consider too much undesired guidance.

There are numerous other occasions during a software engineering project when a group of people needs to organize and structure their ideas about a certain topic. Initially, there were several similar approaches that are now often summarized as “mind maps.”

Common principles of mind mapping are as follows:

• Words or short sentences are written on a commonly visible surface (blackboard, whiteboard, or computer projection). Participants build on the contributions of one another and develop a common understanding of their topic.

• Unlike pure brainstorming, terms and ideas are related through lines or arrows, indicating relationships. This structure provides additional information on top of otherwise unrelated chunks of ideas.

• A central concept is often put in the center of a mind map, with related concepts placed around it. All concepts shown are directly or indirectly connected to the central concept.

• Hierarchical refinement is the major mechanism for relating concepts in a mind map. The central concept is refined by all labels or terms directly connected to it by lines. Each of them can be further refined, thus spanning a conceptual hierarchy of terms or concepts.

• In most variants of mind maps, there are additional mechanisms for cross-cutting relationships on top of refinement. There may be different markers or attachments, such as documents.

Conceptually, mind maps can be drawn manually on a whiteboard (Fig. 3.4).

Fig. 3.4

Mind map on a whiteboard

There are now several tools for creating and managing mind maps on a computer. Some tools are available as open source [104], whereas others are commercial products, like MindManager [74]. Fig. 3.5 shows a mind map drawn with MindManager. The central concept (Unique Selling Points in version 7.0) is depicted as the box in the middle of the diagram. Next-level refinements are indicated by direct lines to the central concept. Many refining terms or ideas are refined again. This hierarchical structure is at the core of a mind map. A flag indicates a certain status of a planned item or a concept; in Fig. 3.5, a green flag and priority one (circle) indicates a preference to implement this feature. More concise questions also have a “starter flag” but are not as urgent: priority is set to three. A free comment indicates that this branch was not considered very innovative. Curved lines around the “spider” of hierarchically refined concepts indicate further links: Automated tax declaration is not only a new feature but also a contribution to faster tax declaration. There are several more options, links to calendars, attached files, and symbols to highlight certain aspects.

Fig. 3.5

Mind map in the MindManager tool, showing the tax software example

Individuals can use mind-mapping tools to present a concept and related ideas. Because the mind map does not imply an order of refining items, the structure conveyed by a mind map is intentionally rather weak. The desire not to define an order or further structures is characteristic of early phases, vague concepts, and draft documents that are just starting to represent information explicitly.

Tools like MindManager are optimized for use in interactive workshop situations. The two most frequently used operations on mind maps are (1) refining a given concept and (2) adding another item on the same level of refinement. Each requires only a single keystroke. By adding comments and status information and by attaching files, computer-based mind maps can grow into sizeable knowledge repositories. Skilled software engineers can create, arrange, and manipulate mind maps in a computer much faster than on a whiteboard. Storing, printing, and managing mind maps are also much easier when they reside in a computer.

Compared with a blackboard or whiteboard sketch, computer-based mind maps tend to have longer descriptions. Some of the items in Fig. 3.5 extend over several lines. Single terms are rarely used or defined. A mind map is supposed to structure ideas and concepts rather than define terms. Note that the most “funny” remarks from the brainstorming session will hardly make it into a mind map (e.g., comics, butler, avatars). Mind maps look more professional and more orderly than manual sketches. They tend to contain rather serious contributions – while not capturing spontaneous ideas, as in brainstorming.

Summary: We can summarize the characteristics of mind maps:

• Mind maps are generic tools that can be applied to some software engineering tasks, too. There is no specific support for software engineering.

• Mind maps facilitate creating spider-like diagrams of terms or concepts that are refined by other terms or concepts. Mind maps have no access to the meaning or semantics of the items. Items are simply treated as strings with attached information (i.e., links, comments, etc.). Mind maps define and support structures but not the meaning of related terms.

• Mind maps are two-dimensional representations of an information or knowledge space. A mind map does not enforce strictly ordering items. This encourages participants to see a variety of relationships while at the same time deferring decisions that cannot be made yet. Maybe, a different order will facilitate a solution? In software engineering, it is often better to avoid making a premature decision. Sometimes, more information is needed to make an informed decision or other specialists need to bring their expertise to the table.

• Mind maps can be created when there is vague, tacit knowledge spread over several people. A joint session may help to externalize and to relate that information and to build common ground.

• Typically, mind maps are sketchy diagrams with little attention paid to spelling or grammar. Therefore, mind maps are not ideal starting points for building consistent vocabularies. They are rather meant to distill a backbone structure from a previously ill-defined area of discussion. As such, mind maps play an important role in early knowledge management.

• There are several situations from requirements engineering via planning and process improvement that benefit from mind maps. Whenever several people need to externalize vague ideas, mind maps should be considered.

Obviously, a reference model can benefit from deriving some of the relationships from a mind map. Precise definition of terms and semantics should not be expected from this technique.

3.5 Semiformal Approaches in Software Engineering

Brainstorming notes and mind maps are informal representations of knowledge and ideas. Words and terms are not precisely defined. There may be typos or undefined synonyms. Informal representations arise in human interactions. They are often a first step toward externalization. In mind maps, relationships are typed: There is a defined meaning of a refinement relationship. Markers and links may be typed, too.

In this section, semiformal approaches will be discussed. Like informal representations, use cases and glossaries were used long before knowledge management was an issue in software engineering. They facilitate the transition from vague, individual knowledge in someone’s brain to explicit, approachable items of knowledge that can be managed. Semiformal approaches bridge the gap between process- and product-oriented knowledge management.

In a formal representation, semantics are encoded in form. Mathematical formulas are written in a mathematical notation others can read and understand. Therefore, the entire meaning of a formula is expressed in its form. Manipulation of contents can be replaced by ritualized manipulation of formulas. In a semiformal representation, not all aspects are completely encoded in forms. Others are described in free text or diagrams that cannot be automatically analyzed or synthesized. There is a tension between formal and informal parts of semiformal approaches. In practice, semiformal approaches are among the most useful techniques in software engineering.

3.5.1 Use Cases

Use cases were introduced into software engineering practice in the 1990 s [4, 68]. A use case represents a set of functional requirements that arise in an interaction between users and a computer system or among cooperating computer systems.

3.5.1.1 Example 3.6 (Typical use case: Withdrawing money at an ATM)

For example, withdrawing money from a bank account makes a good use case. The account holder is the human user who has a clear goal: to get money from her account. The use case is a structured description of the typical and desired interaction between that user and “the system” (i.e., an ATM plus the system behind the ATM). The interaction may be initiated by the user inserting her banking card into a card reader. The system should respond by asking for the personal identification number (PIN). The user will provide it, which will allow her to make further selections; given the provided PIN is valid. At the end of the main scenario, the user should have reached her goal (i.e., received the money). Errors or exceptions are treated in a separate category of the use case. The main scenario assumes desirable process steps without any problems or exceptions.

Note that neither acronym (ATM, PIN) is necessarily defined in the use case. There is a clear actor for each step. Combined steps (as in 5) must have the same actor. The focus of a use case is the interaction needed to reach a goal of the primary actor. In Fig. 3.6, the primary actor seems to be a customer who wants to print the account balance.

Fig. 3.6

Core of a use case: sequence of steps for printing the account balance at an Automatic Teller Machine (ATM)

There are several variants of use-case formats known in the literature and used in companies. They all share the principal idea of describing an important scenario that can occur when a user interacts with the software or the system.

However, use cases are slightly more generic than concrete stories:

• There may be more than one user involved, but a primary user is the reference defining the goals pursued in the use case.

• A scenario will describe actions but should not go into any details about user interface design or interaction with a menu. A use case models the process in terms of interaction, not implementation details.

• A scenario is a typical procedure, not a concrete example including names, specific input values, or desired output reactions. Use cases are more abstract than examples. Each use case represents a whole family of concrete examples.

• Finally, secondary scenarios may be included in a use-case description. Exceptions or unusual variants of a procedure can be denoted in a similar style but in a separate part of a use case. This separation is meant to keep the main scenario simple. Branches and loops are usually prohibited in a scenario; each scenario describes exactly the one path considered “typical and desirable.”

The simplest form to write a use case consists of a title and a short abstract of text that tries to capture the above-mentioned information (Fig. 3.7).

Fig. 3.7

Very short variant of a textual use case (“narrative”)

This basic format encourages people to express requirements in terms of entire interactions, not just isolated features: Requirements are less fragmented and add up to more useful requirements when they are rooted in goal-driven scenarios. Use cases at this level are mainly a mental tool to remember value-adding procedures during requirements elicitation.

The requirements engineering literature has embraced use cases as an easy-to-use, semiformal technique for eliciting and documenting functional requirements. For that purpose, more sophisticated templates for use cases have been developed. Cockburn’s “fully-dressed” style of use cases is widely used in companies [24]. It offers a table with several slots that must be completed for each use case. The meaning of those slots is described in Fig. 3.8.

Fig. 3.8

Example template for fully dressed use cases showing the ATM example

3.5.1.2 Use Case Aspects in Detail

The template shown in Fig. 3.8 [24] contains an example use case. Each aspect has a defined meaning but will not be described in a formal language.

• ID and name: Each use case needs to be identifiable. A unique ID (mostly a number, 4 in Fig. 3.8) facilitates managing use cases as objects. A use-case name should be an active phrase referring to the goal pursued by the use case. “Withdraw money from bank” indicates the goal not the details of the activity.

• Primary actor: There is one person or actor whose goals are pursued by carrying out the use case. Often, a role name (like Customer) will be provided for the primary actor. In more elaborate use-case templates, there are additional fields for specifying goals, benefit, and their measurement.

• Level of use case: Three levels of use cases are distinguished. Essential use cases describe activities at the level in which a user typically wants to interact with the system. Overview use cases abstract from that level. “Electronic banking” is more abstract and less active than “withdraw money from bank.” Supportive activities refine essential use cases. For example, checking the PIN is not a user goal in itself, but it is required for many essential activities. Supportive activities are below the level typical users think about when they describe value-adding functionality.

• Stakeholders and interest: The primary actor always interacts with the system when a use case is executed. Stakeholders are all people, groups, or systems affected by a use case. “Withdraw money from bank” may affect clerks who are in charge of filling up ATM money. They might want to influence the banknotes paid by the ATM. If the ATM is short on one kind of bills, it may compensate by paying in different bills. The bank itself is obviously affected by a system that allows customers to withdraw money. The bank’s interest may include saving cashier personnel and making transactions more efficient. Customers are both stakeholders and primary actors. They wish safe and fast transactions when they use the ATM. Customers waiting in line are in particular interested in short waiting times.

• Trigger: An event that initiates the use case to be carried out. The trigger will also be the first step in the main scenario.

• Precondition: In contrast with a trigger, a precondition is not an event. A precondition is rather a state or condition that needs to hold at the moment when the trigger tries to activate a use case. Only when the precondition is true can the use case be executed. This is a logical statement, not a piece of execution semantics. When software engineers phrase a use case, they can assume that the precondition holds at the starting point. The use case neither needs to check the precondition nor does it have to cope with violated preconditions. By definition, the author of each use case can assume all preconditions will be fulfilled when it gets executed.

• Success case: In all cases in which the use case is carried out, its postcondition must hold afterward. The implementation of the use case has to fulfill that assertion.

• Guarantee: Extensions (see later) are a mechanism for specifying a problem or exception. This will lead to a branch in execution. However, even when one of the specified exceptions occurs, the guaranteed condition will still hold. Guarantees are far less ambitious than success cases. They just describe indispensable assertions the stakeholders insist on. For example, a transfer of funds must be either complete or completely deleted (transactional). If the transaction of sending money to the receiver fails, it must not take it from the sender either.

• Sequence of steps: There is a numbered sequence of steps, each of which should be phrased in a short, active sentence. It must be clear who does what in each step. Many notations of use cases allow single steps to be refined into lower-level use cases. Usually, this is denoted by the refining use-case name being underlined in the respective step. This sequence is the typical, desired main scenario of interactions, with no alternatives mentioned.

• Extensions: Foreseeable deviations (e.g., exceptions) from the desired sequence of steps are described in the extensions section. Cockburn [24] and other authors [69] emphasize the importance of not using control structures (like if, while, switch) in the main sequence of steps. The main scenario follows a single thread. If an exception or variant may occur at a certain step, this variant is described as an extension. Cockburn uses a different numbering scheme for the steps carried out in an extension. A number “3a” refers to an alternative in step 3. For example, the customer might not take her banking card back. The extension should describe all steps to bring the interaction back to the main scenario. In our example, it may be sufficient not to release the money and to display a warning when the banking card is not taken. If there is more than one alternative branch at a certain step, the letters a, b, c are used to indicate this.

• Technology: In some cases, different technology available will impact some steps or the entire use case. For example, a fingerprint reader may affect authentication in one or more steps.

The template imposes a consistent structure on all use cases. Like a checklist, the list of aspects in the template reminds requirements engineers to ask the right questions about each valuable interaction. This exceeds the simple variant of use cases, which only reminded software engineers to consider value-adding interactions at all. Of course, the above template may be adapted and modified by a company or a project. It is important, however, to stick to a common template once it has been tailored. The advantage of creating a common structure for functional requirements is often a higher priority than is making a template a perfect fit for each and every single use case.

We are interested in structuring knowledge in software engineering. With use-case templates, we have reached middle ground:

• There is a template to be consistently used throughout a set of related use cases. All use cases “inherit” the same structure from the template. If filled out correctly, contents in the slots will also follow a similar style.

• On the other side, there is no attempt to strictly regulate terminology in any of the text entries. Stakeholders, for example, are listed. This list may be cross-checked with other use cases or with other documents referring to stakeholders. That cross-check may detect typos or missing entries. However, the intentions of those stakeholders do not follow any prescribed format. There is no easy way to understand or manage knowledge expressed in those little snippets of text.

Because of this dichotomy, it is fair to call use cases “semiformal” representations. By providing a guiding structure, a use case helps requirements engineers to elicit more consistent and more complete requirements. Lack of formalism for wording entries keeps the threshold low for software engineers: Use cases are close enough to normal language.

Only formalized aspects of use cases can be used for computer-based comparison and resolution. There is only little formalized information in a use case, but some authors have tried to push use cases a little further: By defining a few more rules on use cases, tools can interpret more of the knowledge contained in a use case.

3.5.1.3 Example 3.7 (Formal use cases)

For example, Volhard [112] requests no additional rules to be followed. Volhard requests numbering use-case steps strictly: He interprets those steps as a hint to simulate use-case execution. The process of the interaction is expressed in the order of use-case steps. Steps are numbered by a tool, and extensions (exceptional branches) are also administered automatically. Users will not notice a difference, as steps need to be numbered anyway.

3.5.1.4 Example 3.8 (Deriving other models from use cases)

Diegel pursues an approach to combine use cases into event-driven process chains (EPCs; a process modeling notation). Several related interactions are first described as use cases. Those use cases are then woven into a single process model by identifying preconditions that match the postconditions of other use cases. [30]. Such an approach could use logic calculus or it can stay at the syntactic level. Diegel argues for simply considering cases in which preconditions and postconditions are exactly alike. More powerful reasoning mechanisms may build on a more general basis if a previous use case fulfills the preconditions for subsequent use cases [71].

Examples 3.7 and 3.8 illustrate different opportunities to interpret more aspects of a use case in a more formal way. There is obviously a trade-off between rich representation and easy handling of use cases.

Use cases are a technique from requirements engineering. Originally, there was no relationship to knowledge management. However, when a substantial amount of knowledge about functional requirements is captured in the form of use cases, we should consider potential links:

• Use cases structure vague and otherwise incomplete information into defined aspects. Other software engineers know where to look and how to read entries. This constitutes a first structuring step.

• More powerful structuring approaches exploit further details:

  • The list of stakeholders can be compared with the actors in the use-case steps. Actors are either the system or one of the stakeholders.

  • Stakeholders can be compared with other use-case stakeholder lists. Identical stakeholder names can be used to derive associations between use cases.

  • Refining use cases must be represented by their full and correct names. This is yet another opportunity for cross-checking a set of use cases.

  • Tools can derive use-case diagrams. A use-case diagram is a UML diagram depicting an overview of a set of related use cases. By referring to use-case names and stakeholders, use-case diagrams can be created automatically.

  • Even conditions (preconditions, postconditions, and guarantees) can be exploited in order to use semantics. Matching conditions can enrich the knowledge base represented by use cases.

  • Specific approaches may request formalizing more aspects; this leads to a trade-off between computer accessibility and ease of use.

• A semiformal notation like a use case allows software engineers and customers to bridge their language gap. There is a template and a set of rules on how to apply that template. This facilitates the elicitation, explication, and initial structuring of requirements. Requirements are an important subset of knowledge in a software project.

Semiformal notations often do not insist on precise definition of terms. Glossaries are a semiformal concept for defining terms. Glossaries support knowledge engineering by complementing the above-mentioned approaches.

3.5.2 Glossaries

Each domain uses its own vocabulary. Because of their different traditions, a technical domain will use different terms than will a hospital or a financial institution. Different terminologies indicate different challenges, tasks, and different perspectives on software.

A software project needs to use terminology consistently and correctly. It should also be aware of rules, relationships, and traditions that dominate its domain. When software engineers write requirements, develop user interfaces, or write programs, they should use terms familiar to the users of their products. Otherwise, delayed communication and misunderstandings will hamper the project.

Definition 3.1 (Glossary)

A glossary is an ordered collection of entries. Each glossary entry consists of the term to be defined and a short definition or explanation of its meaning.

A software engineer often works in different projects or even in different domains at the same time. Most software engineers will work in different environments during their careers. Nobody can possibly know and remember all “reserved words” or specific terms used in all those environments, let alone all conventions and unspoken rules associated with them. Even experts in a domain sometimes confuse terms. Glossaries are a simple mechanism for collecting defined terms and their meanings. A glossary resembles a dictionary for a specific vocabulary.

In principle, all kinds of terms can be defined in a glossary:

• Domain-specific terms like electroencephalogram (hospital), glossary, or hedge fund (financial), as in Fig. 3.9.

• Technical terms for describing potential or suggested solutions (like framework, model-view-controller, design pattern).

• Everyday words that are used in a special meaning within a certain context (like a requirement “oracle” or a “user”).

• Acronyms or abbreviations: The meaning of an acronym is the full text it represents.

Fig. 3.9

Three glossary entries from different knowledge domains

A glossary entry typically consists of the term itself and a text defining or explaining it. Explanations are usually short (less than half a page) and mostly written in natural language. Formal elements or formal languages are not typically used in glossaries. A glossary is intended to be read and understood by humans, not computers.

There are a number of possible extensions to glossary entries, some shown in Fig. 3.9:

• There may be links to similar or related terms. →SEC is an example.

• Entries are usually sorted in alphabetical order and may be assigned certain attributes. In Fig. 3.9, terms are sorted, but there are no attributes.

• Relationships between terms can be treated as first-order objects (as entries in their own right) or may be treated as annotations or links to other entries. No relationship is defined in Fig. 3.9.

• There can be comments, annotations, examples, or metadata associated with each glossary entry. References to the source of definitions (Wikipedia) are metadata in Fig. 3.9. Metadata describes the entry as such, not the term defined in the entry.

3.5.2.1 Variants of Glossaries

Glossaries are not restricted to software engineering. Within software engineering, glossaries are used for different purposes, and implementations of different glossaries can vary drastically:

• Glossary in a project: Many software projects decide to maintain a glossary of essential terms. This collection will consist of domain terminology, specific project terms, and so forth. A dozen entries in a defined document may be sufficient for a small project in a familiar application domain. Such a glossary requires very little effort to create and to maintain. It may facilitate consistent use of the few terms defined. When software engineers talk to a customer representative, they should use customer terminology and understand tacit associations that come with those terms. A glossary can assist here.

• Glossary beyond a single project: A company or business unit that carries out several projects may find it tedious to start a new glossary with each project. For that reason, a larger long-term glossary for a given domain will be a better solution. It is always a good idea to keep a glossary in a separate document. This is good advice for one-pagers, but it is mandatory for a glossary containing hundreds of terms and several pages. This kind of glossary is copied into several project documents instead of being rewritten from scratch. There may be a few project-specific extensions every time it is used. Knowledge management should be concerned with an orderly process of feeding back corrections and additions to the master copy of the glossary. A rich and well-kept glossary is an asset. However, a glossary must not compete with general-purpose collections, such as Wikipedia. There is no benefit in duplicating generic definitions if they do not have specific meaning or relevance for an organization.

• Glossaries for entire domains: Large companies or domain interest groups maintain voluminous books of precise definitions. A bank, for example, defined about 8,000 terms of specific banking terminology. Effort invested into creating such a large collection of definitions pays back only through extensive use. The bank will insist on using that dictionary throughout all software projects, and also in many other business contexts. For example, training of new employees should encourage use of the glossary. Huge glossaries pose new problems: Each project needs only a fraction of the entries, and no single person has a complete overview of what has been defined. Searching becomes more of an issue. If a project runs into a term that might or might not be defined: How should software engineers find out whether that term already exists in the glossary? What if there are similar terms or synonyms? Full-text search is easy, but searching semantically by contents is a more demanding task.

Creating a glossary is only the first step toward knowledge engineering. The power of a glossary unfolds only when there are procedures and support mechanisms for finding terms, using their definitions, and updating the glossary in case of errors or changes. Creating a glossary forces experts to discuss and agree on exact meanings of terms. They may need to make explicit or to negotiate their opinions and views.

3.5.2.2 Example 3.9 (Using glossary for a software engineering task)

For example, a software engineer writing a specification may encounter a word he does not understand. In that case, looking it up in the glossary is straightforward. However, what if he types a word that is defined – but does not know it is? What can a glossary do to help anyway? Active assistance is a key concept in this area of knowledge management. Existing knowledge should “notice” when it is referenced. An active glossary may compare typed strings with defined terms. But what should be done upon detecting a match? Maybe the software engineer knows about the glossary entry, and a warning is inappropriate. Maybe the software engineer does not know this word to be a defined term; indicating that fact may prevent him from a misunderstanding. A subtle way of indicating the match (like underline or different color) will be appropriate. It should not interrupt the writing process.

Depending on the size and purpose of a glossary, technical implementations may take different forms:

• A simple, short list of explanations can be maintained in a document of a few pages. It will simply be attached to all documents referring to it.

• A longer list could be maintained in a spreadsheet or in a file under version control. Several people will access the list for reading and update. The longer a list, the more users should benefit from using it. Therefore, processes and rules of working with the glossary need to be defined explicitly.

• Databases are obvious candidates for implementing larger glossaries. They can be sorted and filtered, and attributes can be used to select subsets of a glossary.

• Glossaries can also be implemented as blackboards or Wiki webs. Those representations can be modified over the intranet and Internet. Stakeholders receive access rights for reading and/or modifying them interactively.

There is a tension between two desirable properties of a larger glossary:

• It should be flexible enough to be modified and updated easily by all affected personnel. This request refers to concepts and technical support.

• At the same time, well-defined and explained terms should be used consistently. Changing definitions in each project is counterproductive. Consistent usage of terms requires long-term stability of key terms.

• Access rights need to balance the requirements of stability and flexibility.

3.5.2.3 Summary: Strengths and Weaknesses of Different Approaches

Mind maps help to brainstorm and find an initial definition of certain structures but do not result in defined terms. Use cases introduce more detailed structures through their templates. Again, correct and consistent usage of terms is not the focus of use cases. As we have seen in the examples above, simple cross-checks can detect typos, defined terms, or synonyms. However, original use cases lack a glossary mechanism. Glossaries complement structuring approaches: A glossary could add knowledge management capabilities to use cases or mind maps. Today, those semiformal approaches are often maintained separately. This is partly due to the fact that the respective tools are not integrated.

Meaningful requirements must build on well-defined terms. Transferring and applying knowledge requires the knowledge to be comprehensible to the receivers. Misunderstandings need to be avoided. Knowledge engineers will try to use both structures and definitions in order to establish a common language. A definition or explanation is a good starting point. It supports human users who read those definitions and who may use them for more consistent documents. Semiformal approaches do not attempt to encode knowledge in formalized statements. With domain models and ontologies, we will take two more steps toward a computer-accessible convention for a language.

3.5.3 Domain Models

Domain models are a specific software engineering tool for describing domains. The main intention of building a domain model is to capture key concepts of a domain and to show how they are related.

Glossary entries treat terms as the basis of a requirement or a document. Along the same lines, domain models treat concepts as the basis of future software engineering models. Domains can be modeled in different notations or languages. Today, UML domain models are the most common variant. Therefore, this section refers to UML domain models. Several books on UML cover domain models in depth. Larman [69] provides a good introduction to UML and recommends good practices on how to use it well. Following Larman [69] and Fowler [45], we define a domain model.

Definition 3.2 (Domain model)

Visual representation of conceptual classes or real-world objects in a domain of interest.

“Conceptual model” is an older term that has now been replaced by “domain model.” Both terms stand for defined vocabulary. Larman calls domain models a “visual dictionary of abstractions.” As in a glossary, there is a collection of defined concepts, but those concepts are drawn as rectangles on a two-dimensional surface. The placement of symbols will need to take associations into account, and these will affect the readability of the diagram. For example, crossing lines should be avoided. Domain models combine elements for defining concepts, expressing specific relationships, and adding additional information. However, syntax is only one aspect. Because we are interested in knowledge management implications, we need to consider the pragmatic aspect of notations: how they are supposed to be used in practice.

Syntactically, a domain model is a simplified Entity Relationship or UML class model. Like every model, it represents a part of the real world. We will now look at the symbols used in domain models. We will then discuss the relationship of domain models to other formalisms. Elements and their syntax will be explained using the example in Fig. 3.10. They should look familiar to those who know UML class diagrams.

Fig. 3.10

Domain model of a software engineering situation

3.5.3.1 Elements of Domain Models

UML domain models consist of the following elements:

• Domain concept symbol: a rectangle containing class name and attribute names (optional). Concept symbols correspond with class symbols in a UML class diagram, but they refer to real-world concepts instead of program components. Unlike class symbols, domain concepts do not show method or operation names.

• Generalization: A line with a wide arrowhead. An employee is a generalization of a manager and a software engineer. Generalizations in domain models are less frequently used than inheritance in class models.

• Association is depicted by a line between class symbols. An association may link a domain concept with itself, like Employees working with other Employees in Fig. 3.10.

• Comment symbols (document symbols with a folded corner) are often attached to a symbol or an association. They contain free text defining or explaining a concept informally. According to Larman [69], they convey the “intention” of the concept. For instance, the comment on Software Engineer states that instances of that concept need to be able to write Code.

As defined in UML [78], there is a rich choice of details and annotations for UML associations. Those refinements can be applied to domain models, too. They include:

• Role names: Because associations connect concept symbols, the roles of those concepts with respect to the association can be attached as labels. In Fig. 3.10, labels clarify that newFeatures extend legacyCode.

• Reading direction: A black triangle can be added to the association line to indicate reading direction.

• Multiplicities are important aspects of associations. They describe how many instances of a concept can be associated with one concept of the other role. Often, only “none, one, or many” are distinguished and denoted as “0, 1, n, or *.” Ranges of possible values are indicated as:

  • 0…1  zero or one

  • 0…*  from zero to any number

  • 1…*  any number, but not zero

  • Other values, for example, 5…20: from 5 to 20 (including both).

  • Concrete values other than 0 and 1 are rarely used in practice.

  • Note: In Fig. 3.10, a Software Engineer writes at least one Document (1…*), which may be Code (a specific Document, as declared by inheritance) or any other “Document.”

  • A Software Engineer tests from zero to any number of Code (Documents) in Fig. 3.10.

  Table 3.2 Comparing semiformal approaches for structuring information

From the perspective of a common vocabulary, domain models are similar to glossaries combined with mind maps. Table 3.2 gives a concise overview of several aspects relevant for our knowledge management purposes.

In general, updating a glossary entry is an essential operation. Even small glossaries will change, and larger models of any kind will need to be modified. But this is not sufficient. Domain models, for example, are bound to change during the clarification process. As long as a common model (a shared “mental model” [60]) is missing, domain modeling remains difficult and error-prone. Larman [69] and other authors emphasize the importance of an iterative approach for domain modeling. This goes far beyond “a series of changes”: Access rights and version control need to be considered, and changing a defined term may invalidate several documents and pieces of code – those that rely on the outdated definition. Therefore, references to a term need to be updated together with the definition of that term. Is it worthwhile applying a history mechanism or a reference to the source of the definition to a glossary or a use case? In some cases, it definitely is.

Formalizing product knowledge will often not be sufficient. Processes for handling that knowledge will also need to be captured, modeled, and improved. Earl [35] would call these aspects of knowledge management “technocratic,” even though processes are concerned. In this and the subsequent chapter, we focus on defining, structuring, and other “technocratic” contributions to knowledge management. They are essential for dealing with large quantities of fine-grained knowledge.

There are many commercial and open-source graphical editors for UML class diagrams. They can be used to create and modify domain models. StarUML [107] is an easy-to-use UML editor that is available for download. Omondo [79] is another open-source UML graphical editor with some advanced capabilities. Omondo is a little awkward to use in real projects, but it allows producing complex domain models.

Domain models are simple enough to be sketched by hand. This is important for discussing them on a blackboard. Simple knowledge presentation formats like mind maps, glossaries, use cases, or domain models support different subtasks in software engineering. Domain terminology and vocabulary can be captured, structured, and modeled.

Emphasis can be put on

• eliciting tacit knowledge (mind maps);

• providing a reference for all future project activities (glossaries);

• helping to organize statements (use cases); or

• modeling a domain as a system of interrelated concepts (domain models).

Establishing a reference for a common language is a never-ending endeavor. Many terms in a project and its environment can be defined or explained. Not only does the intended product of a software project call for definition and structuring; procedures and processes, rules and activities can be defined in order to establish a common language.

3.5.3.2 Misuse Cases for Security, or “What Must Not Happen”

In the realm of security, many software experts have started to define what must not happen: Undesirable sequences of events or features that must not be accessible to certain people are modeled explicitly. We can construct effective protection mechanisms only when we have a good understanding of situations to avoid. Misuse or abuse cases apply use-case mechanisms and extended use-case diagrams to describe forbidden activities. Fig. 3.11 is an example inspired by Alexander [3] but set in the realm of software engineering.

Fig. 3.11

Example of a misuse case. An attacker wants to misuse online transfer features

In the use-case diagram of Fig. 3.11, white ovals stand for use cases, and black ovals indicate misuse cases. They represent interactions that must not occur. Solid lines indicate which stakeholder participates in what use cases. When there is an include relationship, the included use case (or misuse case) is a mandatory part of the including one. Arrows labeled “threatens” and “mitigates” are specific for misuse cases. They describe how “good” use cases and “bad” misuse cases were developed to respond to each other. Mitigations respond to threats, and new threats try to bypass mitigations.

3.5.3.3 Example 3.10 (Misuse case)

A bank customer has an online account. One of the useful use cases of an online bank account is the transfer of funds. However, there may be “bad” stakeholders involved: The attacker threatens the operation of transferring money online by transferring that money to his own account (see Fig. 3.11). As a reaction to that possibility, online banks have included access control by login and passwords as part of money transfer. If the attacker still wants to misuse the account, he now has to overcome the protection created by the password. Spying out the password is an option. The attacker could mimic the bank interface and try to let the customer enter the password (so-called phishing). The attacker could also try to find the password on the customer computer – many people still store passwords. The attacker could read the keyboard strokes from a distance or try any other way to spy out the password. Fig. 3.11 does not go into any detail about the implementation of spying out passwords. Many online banks respond in a way that mitigates all those threats: They request a six-digit session TAN (transaction access number) that is not reusable. A bank customer receives them via paper mail, which is more difficult to intrude upon.

As this example shows, white and black use cases stimulate each other. There is a competition of threat and mitigation, which is characteristic of security requirements. Knowing what to avoid is an important piece of knowledge in software engineering.

Summary: The semiformal approaches presented in this chapter are easy-to-use techniques, some with dedicated tools. Syntactic consistency is not an issue in glossaries or mind maps, whereas domain models impose a set of UML syntax rules. Many researchers and practitioners have made attempts to extend the power of well-defined languages. Extending capabilities to manipulate knowledge requires additional rules for describing that knowledge. Semiformal techniques are a starting point in that direction, but they are not sufficient. If we want to reason on contents, the semantics of a statement must be defined, too. Ontologies are an important approach to do that. They will be introduced in the next chapter.

3.6 Metamodels and Instantiation

Semiformal structuring mechanisms often define terms on a conceptual level but do not refer to individual instances of those concepts.

3.6.1 Example 3.11 (Instances or classes)

A glossary or a domain model will refer to "SoftwareEngineer" or "CodeModule" but not to a specific person or a particular module. Even use cases use role names for stakeholders and actors rather than individual names: In a use case, one might find "student" or "tester" interacting with "the System" rather than "Peter" or "Mary" as actors.

However, there are situations in which both the conceptual and the individual levels are referenced. We need terms to distinguish those levels. And we need languages to describe knowledge on both levels.

As a software engineer, you are familiar with the concept of classes and objects. Classes are mechanisms for creating objects that follow the structure and pattern described in the class description. Objects or instances are the individuals that can be created in an object-oriented language. The behavior of a program is made up of the numerous interactions of instances. The relationship between a class and each of its instances is called “instantiation.”

Instantiation is different from subclassing:

• A class Employee may have both a subclass Developer and an instance called Dieter Schulz.

• Every instance of Developer, like Jim Jonas, is a Developer.

• Because of the subclass relationship, Jim is also an Employee and has all attributes and features of an Employee.

For the following sections, it is crucial to understand and to clearly distinguish

• inheritance and subclass, as well as

• class and object.

We will see more formal structures that refer to both class and object levels. There is an instantiation relationship between those levels. Subclassing occurs only on the class level. In many tutorials, levels are not clearly separated, which causes a lot of confusion (Fig. 3.12).

Fig. 3.12

Subclassing and inheritance – two different relationships

3.7 Patterns as Experience Representation

Knowledge allows knowledge workers to deal with problems and difficult situations. Facts can be stored in glossaries. Relationships may be expressed in mind maps or domain models. And use cases are one option to describe requirements and knowledge about interactions.

Experiences often come in a slightly different format: An observation and an emotion lead to a conclusion. This conclusion may include one or more of the following elements:

• A hypothesis about the reason or trigger for the observed event.

• A hypothesis about the consequences of the observed phenomenon.

• An assumption on how a problem could have been avoided.

In general, an experience often implies a pattern of a problem and a solution. When the same problem is encountered again, the same solution is recommended. Because the observation was made in a certain situation and context, a new situation and problem will never be exactly the same. However, because a pattern abstracts from irrelevant details, chances are good for identifying “similar problems,” which imply trying “similar solutions.” This conclusion is confirmed by each new experience that includes similar situations and consequences. On a more abstract level, they represent similar problems and solutions – confirming the pattern.

Variants of patterns: Definition of terms and relationships were more or less formalized using the above-mentioned approaches. Along the same lines of thought, the description of a pattern as an experience representation can be more or less formal.

• Least formally, a sentence with an IF/THEN clause implies a correspondence between a situation (IF) and a consequence (THEN). Natural language can be used to phrase the conclusion of an experience. In this interpretation, patterns resemble rules.

• A little more formally, a template can be created that highlights the IF and THEN parts. If a form is used at all, it will often contain several classifying attributes. The attributes help to characterize relevant situation properties. This also facilitates matching a given situation with the situation triggering the pattern.

• At DaimlerChrysler, some experience packages (see Chap. 6) were described in 13 facets (Fig. 3.13). Those facets were organized in order to describe more and more details, with the core being a description of problem and solution. This concept was illustrated as “pyramid structure.” Because the domain of those experience patterns was software quality and process improvement, the patterns were named “quality patterns.” If a subset of the facets are formalized (e.g., only certain entries are allowed in a defined grammar), case-based reasoning can run on the patterns [109]. Case-based reasoning is explained in more detail in Chap. 6. All other facets may remain semiformal or informal.

Fig. 3.13

Quality pattern pyramid structure and relationships to other quality patterns [54]

Design patterns are well known in software engineering. Like the above-mentioned informal pattern types, design patterns encode experience. In particular, a design pattern describes a solution to a frequently recurring implementation problem [46]. Because design patterns describe program structures, they represent low-level software design experience. Most patterns are associated with a UML diagram (e.g., composite design pattern in Fig. 3.14). However, Gamma et al. present several pages with about a dozen facets for each pattern. For example, a composite pattern is appropriate IF several types of elements and groups of elements must be treated in the same way. In a graphical editor, a complex group of symbols should be moved, resized, colored, and deleted like a single circle or rectangle. Obviously, a loop is required. However, the pattern says in its THEN part: Provide a common superclass to all elements and the composites (groups). Let this superclass define the interface of common shared operations (move, resize, color, and delete in the example). And implement the iteration within each composite class – not within the users of a composite! Design patterns are technical solutions that come with a profile of their applicability and various related information.

Fig. 3.14

Composite pattern [46]. Printed with permission from: Pearson Education Deutschland GmbH, Martin-Kollar-Str. 10--12, Munich, Germany

Design pattern are close to the code level. Some patterns have been integrated into integrated design environments (IDEs) like Eclipse. However, Gamma et al. view design patterns as slightly more abstract representations of design knowledge (and experience!). In principle, they can be implemented in different languages, with variations and adaptations. The sustained popularity of design patterns has influenced software engineering research. A large number of different patterns have been published [45, 54, 67, 88].

• Within a formal framework of knowledge representation (e.g., an ontology, see next chapter), patterns may be fully formalized. A precise definition includes a precondition as a pattern to match in the knowledge base or formal software engineering model. If this precondition can be matched, the formal pattern needs to formally describe the reaction this will trigger. At least, a notification can be sent (“the inheritance depth of the design exceeds five levels”). In more complex cases, the respective formal model can be modified.

• For example, class hierarchies can be rearranged to avoid excessive inheritance hierarchies. Graph grammars are a formal mechanism for replacing subgraphs based on rules (i.e., patterns). Formal representations of patterns are usually difficult to write and understand for humans. This is an old tension. In the realm of experience management, the opportunity to pin down patterns formally is rare.

3.8 Problems for Chapter 3

Problem 3.8.1: Pattern

What is a “pattern” with respect to knowledge and experience management? What are the core elements of a pattern and what are they used for when describing and reusing software engineering knowledge? Give an example from software testing.

Problem 3.8.2: Defining quality aspects

Finding a common language with the customer is important in software engineering. Assume you are defining quality attributes for a new piece of software with a customer from a medical background. Why is it important to define key terms like “reliability” or “ease of use” explicitly?

Assume you are developing a banking system for teenagers on the Internet. This program is supposed to target young, inexperienced banking customers. They should be offered basic and additional information on the banking products, and each of their interactions should be explained in detail if they wish. Also, teenage customers should not be allowed to overdraw their account. This example is used for the following problems.

Problem 3.8.3: Mind map

In the process of developing the system, innovative ideas and important reminders are collected in a mind map. The intention is to gain an overview of important and “cool and catchy” concepts that should be taken into account in order to make the teenage bank account system a success. Draw a mind map of a teenage bank account with at least four directly related concepts and about two to four comments each. Comments should explain the innovation or importance of each concept.

Problem 3.8.4: Brainstorming versus mind map

When you drew the mind map, you were not performing brainstorming, although some people might call it so. What are the main differences between drawing your mind map and “real” brainstorming?

Problem 3.8.5: Glossary entries

Provide glossary entries for “graphical user interface,” “bank account,” and “ATM card” (no debt allowed for teenagers) with respect to the teenage bank account.

Problem 3.8.6: Typos

Typos (incorrectly spelled words) are more common in mind maps than in glossaries. Why is that so and why is it usually not a problem for mind maps?

Problem 3.8.7: Domain model

What happens when a teenage customer turns legally adult? How can you find out what is supposed to happen then? Write a use case for this operation and highlight two pieces of “domain knowledge” it contains.

Problem 3.8.8: Use case

Describe the use case of “changing the PIN” using the use-case template shown above. Make sure to address the characteristic need of young customers to learn about permitted PIN formats and the implications of changing a PIN (and maybe forgetting it). What happens when they enter incorrect input?

Problem 3.8.9: Writing a pattern

Let us assume the company developing the teenage banking system has gathered experience with many other systems for young people. During those projects, there was a recurring misunderstanding: When young customers were interviewed for requirements, they rarely checked “intuitive interface” as a high priority. Nevertheless, customer satisfaction seemed to depend on ease of use. Structure this observation as a pattern, and describe how the teenage banking project can make use of it.