Chapter 7 Functions ‘To determine the system’s information processing ca- pabilities. Purpose Function: A facility for making a model useful for ac- tors. Concept Principles Identify all functions. Specify only complex functions. Check consistency with use cases and the model. . Results . A complete list of functions with specification of com- plex functions. Functions focus on what the system can do to assist actors in their work. When determining requirements for the functions, we ask the following question: What is the system going to do? In the usage activity, our question focused more on how the system would be used. Given that it is difficult to analyze “what” without analyzing “how,” the usage and function activities are closely connected. 7.1 System Functions Traditionally, a function is regarded as a computation, where input data is transformed to output data. This is the basic philosophy of many early in- formation systems. The first payroll systems, for example, had this input- output structure: input data included pay rates and number of hours, and from this, the system calculated each employee’s pay. It is easy to under- stand what such a system does. It calculates pay. More advanced systems are difficult to understand from a purely func- tional point of view. We can, for example, look at a system for controlling a power plant. The control system performs several tasks. To facilitate moni- 139140 Functions toring, the system must provide plant operators with immediate and reli- able information on plant conditions. This information can be maintained in the system’s model component. For the system to be useful, it must con- tain functions that let operators read the model’s state, including valve po- sitions and turbine speeds. For the model to display reliable information about the power plant's state, it must have functions that provide it with this information. The operator may also wish to actively intervene in the plant's operation, as opposed to simply monitoring it. The control system therefore must include functions for opening and closing valves. Clearly, the functionality of this system involves not just one function, but many di- verse functions that the user applies in various ways. From an analytical point of view, the elegance of functions is that they express, in a simple way, the intent of a system. More precisely, we define a function as follows. Function: A facility for making a model useful for actors. A function is activated, executed, and provides a result. Function execution can change a model component’s state or create a reaction in the applica- tion or problem domains. A function is a requirement; it is an abstract prop- erty of the system. Functions are realized through program operations, as we describe in Chapter 13. Function Types As an aid to our analysis, we will discuss different types of functions. Each function type expresses a relation between the model and the system's con- text and has characteristics that help us when we define functions. We have identified four types of functions: Update functions are activated by a problem-domain event and result in a change in the model’s state. Signal functions are activated by a change in the model’s state and re- sult in a reaction in the context; this reaction might be a display to the actors in the application domain, or a direct intervention in the problem domain. Read functions are activated by a need for information in an actor’s work task and result in the system displaying relevant parts of the model. Compute functions are activated by a need for information in an actor’s work task and consist of a computation involving information provid- ed by the actor or the model; the result is a display of the computa- tion’s result.System Functions 141 Asystem’s specific functions are rarely “pure”; they seldom fit perfectly into one of the four types. Functions are mixtures. The primary function in an air traffic control system will involve update, signal, read, and compute. However, it is still useful to categorize the functions. To do so increases our understanding of their character, and lets us use the function types as tools in our application-domain analysis. Analyzing Functions The purpose of this activity is to determine the system’s information pro- cessing capabilities by constructing a complete list of functions, as well as a detailed specification of the complex parts. Describing functions is not par- ticularly difficult; the greater challenge is to choose which functions to in- clude. System definition complex functions, Function list and specifications Use cases Figure 7.1: Subactivities in function analysis The central criterion for system-functionality analysis is that analysis ends with a list of functions that is both complete and consistent with the use cases. This is expressed in the following principle: Principle: Identify all functions. To create an overview, we describe the set of functions in a list. This makes it easy to work with the relations between functions and discover overlaps and holes in their coverage of the total functionality. For some functions, you must describe their content in detail to understand what they do. How- ever, you should give detailed descriptions for only the most complex and incomprehensible functions. The second principle for the function-analysis activity is: Principle: Specify only complex functions.142. FunctionsFind Functions 143 with a customer about the delivery Sones gee eeoemy of goods. The event would be regis- Functions g The difference between events, use terse ae oe Pens ie cee and ancien te etl ier desertion ae nod 7 ; ed because they pose different sys- i action and they are connected, el ‘e wh ae mnt they” belong) to: separate 00-595 = a ated ai dift-rent para of tbe mains. For example, “create order” 4 : = system, and it must be handled in could be a function, a part of the Ph ee irset anne system that updates the model. ae es “Enter order” could be a use case in The ee cane deecaptagn NSS AE seat . valuable information for this. The the application domain, where a Gude ieee ave clerk interacts with a system. “Cre- todele thie F t i i ate order” could be one of the fune- FV) the ovelt. Finally, thevove, tions that supports this use case. et he atie y eee “Ordering” could be a problem-do- teenie main event that represents the es- ah pe ae Ss Ee Sener tablishment of a legal agreement _** SPetified by the function. The functions must be consistent with the other analysis results. In partic- ular, functions must support the use cases, and all parts of the model should be used by some function. This is expressed in the third principle: Principle: Check consistency with use cases and the model. Function analysis consists of three subactivities: find functions, specify complex functions, and evaluate critically. The relations between subactivi- ties, preconditions, and results are shown in Figure 7.1. 7.2 Find Functions When finding the functions, there are two essential aspects that you should keep in mind. First, consider the sources for identifying functions. Where do the system’s function requirements come from? Second, consider the level of detail. How detailed should you be in function descriptions? How general or specific should you be in defining individual functions? The sources for identifying functions are partly the problem-domain de- scription, as expressed by its classes and events, and partly the application- domain description, as expressed by its use cases. Classes typically give rise to read and update functions. Events lead to requirements for update func- tions. Use cases give rise to all types of functions.144 Functions You must describe functions in enough detail to provide both an over- view of the total functionality and a basis for agreement between users and developers. Given this, the level of detail required depends on the experi- ence of the users and developers. Inexperienced developers and users re- quire greater detail to ensure that they share an understanding of the func- tions. In any case, each function must have an appropriate level of detail. Functions specified at a very general level yield uncertainty. Functions specified at a very specific level render the analysis inefficient. For exam- ple, describing read and update functions for all attributes is too much de- tail. A function like “calculate pay for all employees,” is, on the other hand, too general. “Calculate basic pay,” “calculate health insurance,” and “calcu- late tax,” is typically an appropriate level of detail for users and developers familiar with the application and problem domains. Section 7.3 describes in more detail how to specify complex functions. A good way to start identifying functions is to systematically ask ques- tions related to the four function types. Each of the four function types give rise to several questions that lead to the required functions. We will now ex- amine the analytical questions for each of the function types. Questions for each event * How is the event observed, and how is it registered? In which use cases does this happen? * How should the use cases be supported by update functions? * Which objects, attributes, and object structures are affected by the event, and what requirements does this impose on the update functions? Figure 7.2: Analysis of update functions Update functions are connected to events. The fact that an event is included in the model expresses that it is sufficiently important to warrant registra- tion in the system. Each event triggers a state update for model objects that are involved in the event. Figure 7.2 shows the relevant questions about the event. An update function often covers more than one event. Read functions are related to information needs expressed in use cases, but they are also related to the model’s content. The fact that a class with events, attributes, and structures has been defined often reflects a direct need for information in the application domain. Figure 7.3 shows the rele- vant questions for uncovering information needs. Compute functions are related to more complex information needs that cannot be immediately met by reading the model. Compute functions must be identified from the use cases. An important question is how to delimit the individual compute function. Again, the use cases hold the answer. AFind Functions 145 Questions about information needs * Given the work of the actors, what do the actors need to know about the state of the model? What read functions does this give rise to? * Given the model, which objects and structures will the actors need information about? What read functions does this give rise to? Figure 7.3: Analysis of read functions computational sequence that cannot be interrupted by the actor should be supported by one function. If the computational sequence consists of several alternative parts, you must consider using more than one function. On the other hand, you should avoid cluttering the list of functions with insignifi- cant variations in the computations of a basic function. Figure 7.4 shows the questions for analyzing compute functions. Questions about needs for computation * Which computations (not necessarily based on the model) do the actors need to have carried out? * Does the computational basis come from the actors, the model, or both? * Which computations form complete wholes in the use cases? Figure 7.4: Analysis of compute functions At times, you might be uncertain whether a given function is a read func- tion or a compute function. This confusion is not reserved only for complex functions, which can be combinations of several function types. The doubt can also be related to simple functions. For example, it is not immediately obvious whether a function that provides an account balance is a reading or a computation. If the balance exists as an attribute that is updated at every transaction event, you can make do with a read function. But if the balance does not exist as an attribute, you need a compute function. This decision does not, however, belong in the analysis activity. Having defined the need for account-balance information, you have determined the requirement and concluded the analysis. How the requirement will be technically realized is a design question, and not one you should settle during function analysis for two reasons: it does not interest the user, and it requires further consid- erations of what the technical platform can efficiently execute. Signal functions are connected to critical states in the model. A critical model state is a state in a collection of objects that requires a reaction in the context. Examples of critical states include a customer overdrawing his ac-146 Functions Questions about critical states * What are the critical states for the model? * What is the significance of these critical states? What are the consequences when they occur? * How does a signal function register that the model has entered a critical state? © What signals does each critical state give rise to? How reli- able and strong do the signals have to be? Figure 7.5: Analysis of signal functions count, a customer qualifying for an extra bonus, or a power plant’s tempera- ture level exceeding defined limits. Users often focus intensely on signal functions, as they can increase quality and efficiency in the application do- main. The need for signal functions is thus easy to identify; users will sure- ly help. It is more difficult to ensure that the model includes adequate infor- mation for signal-function performance. Figure 7.5 shows some questions that can help with this. The result of the function-analysis activity is a list of functional re- quirements for the system. The list must be complete and express the col- lective needs of customers and actors and meet the application-domain’s de- mands for computer support. Figure 7.6 shows an example of a list of func- tions for the Hair Salon System (Chapter 20). At the top is the total func- tionality as described in the system definition; we then list the name, complexity, and type of each individual function. Complexity is an assessment of how complicated it will be to develop the function. In this case, we used a simple four-point scale with the values simple, medium, complex, and very complex. Assessing function complexity is a part of customer negotiations and offers an estimate of the development effort ahead. You can also use these assessments later, during develop- ment, as a basis for negotiations about changes to system requirements. 7.3 Specify Complex Functions You might need a detailed specification to understand a function sufficient- ly and to realistically assess its complexity. In most cases, however, such specifications are unnecessary during analysis. The basic rule is that you should describe functions briefly and informally in a list. Detailed specifica- tions are for special cases. You can construct a detailed specifications in several ways. « A mathematical expression where the relation between input data and output data is specified as o = fi)Specify Complex Functions 47 Planning Make schedule Very complex Update Calculate schedule consequences Complex Signal Find working hours from previous period Medium Read Enter contents into schedule Complex Update Erase schedule Simple Update Query earlier schedules Medium Read Make appointment Medium Update Cancellation Simple Update Query possible appointments Complex Read Register treatment Simple Update Create customer Simple Update Query customer information Medium Read Employment Simple Update Retirement Simple Update Update apprentice information Simple Update Figure 7.6: An example of a function list * An algorithm, which is typically sketched in a simple structured lan- guage with a few, simple control structures (also called pseudo code). Figure 7.7 shows an example of this. Query possible reservations: given time or date or employee-name search objects in time period-available and select those who belong to employee-name, if known have date, if known cover point in time, if known result objects of time period-available that fulfill the criteria Figure 7.7: Example of an algorithmic specification of a function ° A further functional partitioning of a function in the function list, showing the complete functional hierarchy directly in the list, as Fig- ure 7.8 shows. A hierarchical function list often gives a better over- view than an equivalent data-flow description.148 Functions Planning Make schedule Very complex Update * Create six-week period * Simple * Create standard distribu- ¢ Medium tion for an employee Use standard distribution * Simple for an employee Adjust the distribution of | * Medium employees in a week Figure 7.8: An example of a partitioning of functional requirements No matter what form you choose, we recommend that you specify functions as briefly as possible during the analysis. The primary purpose is to identi- fy the function. 7.4 Evaluate Systematically The function list expresses the target system’s functionality. You must en- sure that the required functionality is consistent with the list of functions, that the functions are mutually consistent, and that each function express- es an appropriate level of abstraction. In principle, there are three ways to ensure that your function list is complete. First, the users can review the list and agree that it shows exact- ly the functions they want. You can further support this by experiments with the users and function prototypes, or by comparing the functions and use cases. Second, for each function type, you can ensure the possibilities are exhausted by returning to the questions in Section 7.2, and using them to review your function list. Third, you can compare the function list with the system definition and the model. The general definition of the system functionality in the system defini- tion should be in accordance with your final list of functions. If the system definition says it is a payroll system, then no invoicing functions should be included. Differences between the general definition and the list of func- tions may give rise to a revision of both the system definition and the func- tions. Finally, you must compare the function list with the model. The model must include precisely that information about the objects that the functions need; no more, no less. That is, if the model contains objects, structures, or events that are never used by any of the functions, then either the model contains too much or some functions are missing.Principles 149 7.5 Principles We can summarize this chapter in three principles for describing functions in object-oriented analysis. Identify all functions. One of the main purposes of the analysis is to de- termine the level of ambition for the target system. The complete list of functions is an important element in achieving this. Specify only complex functions. We recommend that you describe the functions briefly and informally in a list. However, it may sometimes be necessary to specify certain functions in detail in order to under- stand them and assess their complexity. Check consistency with use cases and the model. The list of functions must be consistent with the list of use cases and the model's classes and events. Checking this can reveal insufficient analysis. 7.6 Exercises Review Questions What is a function in a computerized system? What is the difference between a function and a use case? What are the four different function types? What are the function types used for? Which sources are used to identify functions? How are functional requirements specified? How can the functional requirements be evaluated? TP ON ae ce bo et Eoblents Consider the Conference Planning System described in Chapter 19. How are events, use cases, and functions related? Start out from se- lected functions and identify those events and use cases that relate to each of the functions. 9. Consider the computerized systems you use. Identify, for each system, examples of each of the four types of functions (if possible). 10. Some object-oriented methods do not include functions. How are func- tional requirements understood and described in those methods? Dis- cuss the issue by examining selected methods. Discuss general strengths and weaknesses of including functions in object-oriented analysis and design. 11. Video rental store. Continue your considerations of the system for150 Functions managing customers and their rentals in a video rental store (see Ex- ercise 3.13). Develop a complete list of functional requirements by sys- tematically examining the model and use cases. 12. Mobile phone. Continue your considerations of the system for a simple mobile phone (see Exercise 3.14). Develop a complete list of functional requirements by systematically examining the model and use cases. 13. Teaching administration. Continue your considerations of the system for monitoring student activities in a university department (see Exer- cise 3.15). Develop a complete list of functional requirements by sys- tematically examining the model and use cases. 14. Elevator control. Continue your considerations of the system to control elevator movement in a building (see Exercise 3.16). Develop a com- plete list of functional requirements by systematically examining the model and use cases. 7.7 Literature Most object-oriented methods do not have an independent concept of func- tion. Jacobson et al. (1999) rely on use cases to carry the information about functional requirements. In keeping with Coad & Yourdon (1991a), many authors describe functions as operations on the individual model classes. This approach creates three problems. First, the concept of operations is re- lated to design rather than analysis. Second, this use of operations implies a mix of model and function. Third, it is not easy to connect all functions to a class. The idea of separating model and function and using this distinction to structure the analysis activity come from the classic method by Jackson (1983). Rumbaugh et al. (1991) is the only classic object-oriented method that emphasizes functions. In their method, the description of functions is one of three fundamental models. They use data-flow diagrams from structured analysis to describe functions. The problem with this approach is that the description of the functions is not related to the object-oriented model. Sys- tem developers with experience using the Rumbaugh method also point out that constructing the functional model is rarely worth while. The central reference to function-oriented analysis is Yourdon (1989). In his method, descriptions of data flows begin by identifying events in the application domain. Two different techniques are used for finding func- tions. First, you construct a context diagram to identify system actors and the data they exchange with the system. Next, you construct a list of events by brainstorming with the context diagram in mind. From an object-orient- ed viewpoint, Yourdon’s approach can be criticized on two accounts. First, finding this kind of event is no easier than finding the associated functions,Literature 151 which in this method perceives as data processes. Second, data-flow dia- grams are often perceived as descriptions of work tasks, which they are not. They are descriptions of data processing. The data-flow concept is a techni- cal metaphor, which describes what goes on in a computer—computation— and it is typically a very poor description of work tasks.