106 TOWARDS OBJECT TECHNOLOGY $5.2 Structure of a Employee Information simple payroll Produce Paychecks Paychecks program Hours Worked The system takes some inputs (such as record of hours worked and employee information)and produces some outputs(paychecks and so on).This is a simple enough functional specification,in the strict sense of the word functional:it defines the program as a mechanism to perform one function-pay the employees.The top-down functional method is meant precisely for such well-defined problems,where the task is to perform a single function一the“top”of the system to be built. Assume,however,that the development of our payroll program is a success:the program does the requisite job.Most likely,the development will not stop there.Good systems have the detestable habit of giving their users plenty of ideas about all the other things they could do.As the system's developer,you may initially have been told that all you had to do was to generate paychecks and a few auxiliary outputs.But now the requests for extensions start landing on your desk:Could the program gather some statistics on the side?I did tell you that next quarter we are going to start paying some employees monthly and others biweekly,did I not?And,by the way,I need a summary every month for management,and one every quarter for the shareholders.The accountants want their own output for tax preparation purposes.Also,you are keeping all this salary information, right?It would be really nifty to let Personnel access it interactively.I cannot imagine why that would be a difficult functionality to add. This phenomenon of having to add unanticipated functions to successful systems occurs in all application areas.A nuclear code that initially just applied some algorithm to produce tables of numbers from batch input will be extended to handle graphical input and output or to maintain a database of previous results.A compiler that just translated valid source into object code will after a while double up as a syntax verifier,a static analyzer, a pretty-printer,even a programming environment. This change process is often incremental.The new requirements evolve from the initial ones in a continuous way.The new system is still,in many respects,"the same system"as the old one:still a payroll system,a nuclear code,a compiler.But the original "main function",which may have seemed so important at first,often becomes just one of many functions;sometimes,it just vanishes,having outlived its usefulness. If analysis and design have used a decomposition method based on the function,the system structure will follow from the designers'original understanding of the system's main function.As the system evolves,the designers may feel sorry (or its maintainers,if different people,may feel angry)about that original assessment.Each addition of a new function, however incremental it seems to the customer,risks invalidating the entire structure. It is crucial to find,as a criterion for decomposition,properties less volatile than the system's main function
106 TOWARDS OBJECT TECHNOLOGY §5.2 The system takes some inputs (such as record of hours worked and employee information) and produces some outputs (paychecks and so on). This is a simple enough functional specification, in the strict sense of the word functional: it defines the program as a mechanism to perform one function — pay the employees. The top-down functional method is meant precisely for such well-defined problems, where the task is to perform a single function — the “top” of the system to be built. Assume, however, that the development of our payroll program is a success: the program does the requisite job. Most likely, the development will not stop there. Good systems have the detestable habit of giving their users plenty of ideas about all the other things they could do. As the system’s developer, you may initially have been told that all you had to do was to generate paychecks and a few auxiliary outputs. But now the requests for extensions start landing on your desk: Could the program gather some statistics on the side? I did tell you that next quarter we are going to start paying some employees monthly and others biweekly, did I not? And, by the way, I need a summary every month for management, and one every quarter for the shareholders. The accountants want their own output for tax preparation purposes. Also, you are keeping all this salary information, right? It would be really nifty to let Personnel access it interactively. I cannot imagine why that would be a difficult functionality to add. This phenomenon of having to add unanticipated functions to successful systems occurs in all application areas. A nuclear code that initially just applied some algorithm to produce tables of numbers from batch input will be extended to handle graphical input and output or to maintain a database of previous results. A compiler that just translated valid source into object code will after a while double up as a syntax verifier, a static analyzer, a pretty-printer, even a programming environment. This change process is often incremental. The new requirements evolve from the initial ones in a continuous way. The new system is still, in many respects, “the same system” as the old one: still a payroll system, a nuclear code, a compiler. But the original “main function”, which may have seemed so important at first, often becomes just one of many functions; sometimes, it just vanishes, having outlived its usefulness. If analysis and design have used a decomposition method based on the function, the system structure will follow from the designers’ original understanding of the system’s main function. As the system evolves, the designers may feel sorry (or its maintainers, if different people, may feel angry) about that original assessment. Each addition of a new function, however incremental it seems to the customer, risks invalidating the entire structure. It is crucial to find, as a criterion for decomposition, properties less volatile than the system’s main function. Employee Hours Paychecks Produce Paychecks Information Worked Structure of a simple payroll program
$5.2 FUNCTIONAL DECOMPOSITION 107 Finding the top Top-down methods assume that every system is characterized,at the most abstract level, by its main function.Although it is indeed easy to specify textbook examples of algorithmic problems-the Tower of Hanoi,the Eight Queens and the like-through their functional "tops",a more useful description of practical software systems considers each of them as offering a number of services.Defining such a system by a single function is usually possible,but yields a rather artificial view. Take an operating system.It is best understood as a system that provides certain services:allocating CPU time,managing memory,handling input and output devices, decoding and carrying out users'commands.The modules of a well-structured OS will tend to organize themselves around these groups of functions.But this is not the architecture that you will get from top-down functional decomposition;the method forces you,as the designer,to answer the artificial question"what is the topmost function?",and then to use the successive refinements of the answer as a basis for the structure.If hard pressed you could probably come up with an initial answer of the form "Process all user requests" which you could then refine into something like from boot until halted or crashed loop "Read in a user's request and put it into input queue" “Get a requestrfrom input queue” “Process r" "Put result into output queue" “Get a result o from output queue'” “Output o to its recipient'” end Refinements can go on.From such premises,however,it is unlikely that anyone can ever develop a reasonably structured operating system. Even systems which may at first seem to belong to the "one input,one abstract function,one output"category reveal,on closer examination,a more diverse picture. Consider the earlier example of a compiler.Reduced to its bare essentials,or to the view of older textbooks,a compiler is the implementation of one input-to-output function: transforming source text in some programming language into machine code for a certain platform.But that is not a sufficient view of a modern compiler.Among its many services, a compiler will perform error detection,program formating,some configuration management,logging,report generation
§5.2 FUNCTIONAL DECOMPOSITION 107 Finding the top Top-down methods assume that every system is characterized, at the most abstract level, by its main function. Although it is indeed easy to specify textbook examples of algorithmic problems — the Tower of Hanoi, the Eight Queens and the like — through their functional “tops”, a more useful description of practical software systems considers each of them as offering a number of services. Defining such a system by a single function is usually possible, but yields a rather artificial view. Take an operating system. It is best understood as a system that provides certain services: allocating CPU time, managing memory, handling input and output devices, decoding and carrying out users’ commands. The modules of a well-structured OS will tend to organize themselves around these groups of functions. But this is not the architecture that you will get from top-down functional decomposition; the method forces you, as the designer, to answer the artificial question “what is the topmost function?”, and then to use the successive refinements of the answer as a basis for the structure. If hard pressed you could probably come up with an initial answer of the form “Process all user requests” which you could then refine into something like from boot until halted or crashed loop “Read in a user’s request and put it into input queue” “Get a request r from input queue” “Process r” “Put result into output queue” “Get a result o from output queue” “Output o to its recipient” end Refinements can go on. From such premises, however, it is unlikely that anyone can ever develop a reasonably structured operating system. Even systems which may at first seem to belong to the “one input, one abstract function, one output” category reveal, on closer examination, a more diverse picture. Consider the earlier example of a compiler. Reduced to its bare essentials, or to the view of older textbooks, a compiler is the implementation of one input-to-output function: transforming source text in some programming language into machine code for a certain platform. But that is not a sufficient view of a modern compiler. Among its many services, a compiler will perform error detection, program formating, some configuration management, logging, report generation