南京大学：《面向对象技术 OOT》课程教学资源（教材电子版）27 Object-oriented analysis.pdf

904 OBJECT-ORIENTED ANALYSIS $27.1 Goals of performing analysis Al.To understand the problem or problems that the eventual software system,if any,should solve. A2.To prompt relevant questions about the problem and the system. A3.To provide a basis for answering questions about specific properties of the problem and system. A4 To decide what the system should do. A5 To decide what the system should not do. A6.To ascertain that the system will satisfy the needs of its users,and define acceptance criteria(especially when the system is developed for an outside customer under a contractual relationship) A7.To provide a basis for the development of the system If analysis is being applied to a non-software system,or independently of a decision to build a software system,Al,A2 and A3 may be the only relevant goals. For a software system,the list assumes that analysis follows a stage of feasibility study which has resulted in a decision to build a system.If,as sometimes happens,the two stages are merged into one(not an absurd proposition,since you may need an in-depth analysis to determine whether a satisfactory result is conceivable),the list needs another item:A0,deciding whether to build a system. Although related,the goals listed are distinct,prompting us in the rest of this chapter to look for a set of complementary techniques;what is good for one of the goals may be irrelevant to another. Goals A2 and A3 are the least well covered in the analysis literature and deserve all the emphasis they can get.One of the primary benefits of an analysis process, independently of any document that it produces in the end,is that it leads you to ask the relevant questions(A2):what is the maximum acceptable temperature?What are the recognized categories ofemployees?How are bonds handled differently from stocks?By providing you with a framework,which you will have to fill using input from people competent in the application domain,an analysis method will help spot and remove obscurities and ambiguities which can be fatal to a development.Nothing is worse than discovering,at the last stage of implementation,that the marketing and engineering departments of the client company have irreconcilable views of what equipment maintenance means,that one of these views was taken by default,and that no one cared to check what the actual order giver had in mind.As to A3,a good analysis document will be the place to which everyone constantly goes back if delicate questions or conflicting interpretations arise during the development process. Requirements The practical requirements on the analysis process and supporting notations follow from the above list of goals:

904 OBJECT-ORIENTED ANALYSIS §27.1 If analysis is being applied to a non-software system, or independently of a decision to build a software system, A1, A2 and A3 may be the only relevant goals. For a software system, the list assumes that analysis follows a stage of feasibility study which has resulted in a decision to build a system. If, as sometimes happens, the two stages are merged into one (not an absurd proposition, since you may need an in-depth analysis to determine whether a satisfactory result is conceivable), the list needs another item: A0, deciding whether to build a system. Although related, the goals listed are distinct, prompting us in the rest of this chapter to look for a set of complementary techniques; what is good for one of the goals may be irrelevant to another. Goals A2 and A3 are the least well covered in the analysis literature and deserve all the emphasis they can get. One of the primary benefits of an analysis process, independently of any document that it produces in the end, is that it leads you to ask the relevant questions (A2): what is the maximum acceptable temperature? What are the recognized categories of employees? How are bonds handled differently from stocks? By providing you with a framework, which you will have to fill using input from people competent in the application domain, an analysis method will help spot and remove obscurities and ambiguities which can be fatal to a development. Nothing is worse than discovering, at the last stage of implementation, that the marketing and engineering departments of the client company have irreconcilable views of what equipment maintenance means, that one of these views was taken by default, and that no one cared to check what the actual order giver had in mind. As to A3, a good analysis document will be the place to which everyone constantly goes back if delicate questions or conflicting interpretations arise during the development process. Requirements The practical requirements on the analysis process and supporting notations follow from the above list of goals: Goals of performing analysis A1 • To understand the problem or problems that the eventual software system, if any, should solve. A2 • To prompt relevant questions about the problem and the system. A3 • To provide a basis for answering questions about specific properties of the problem and system. A4 • To decide what the system should do. A5 • To decide what the system should not do. A6 • To ascertain that the system will satisfy the needs of its users, and define acceptance criteria (especially when the system is developed for an outside customer under a contractual relationship). A7 • To provide a basis for the development of the system

$27.1 THE GOALS OF ANALYSIS 905 There must be a way to let non-software people contribute input to the analysis, exam ine the results and discuss them (A1,A2). The analysis must also have a form that is directly usable by software developers(A7) The approach must scale up (A1). The analysis notation must be able to express precise properties unambiguously(A3). It must enable readers to get a quick glimpse of the overall organization of a system or subsystem (A1,A7) Scaling up(the third point)means catering to systems that are complex,large or both -the ones for which you most need analysis.The method should enable you to describe the high-level structure of the problem or system,and to organize the description over several layers of abstraction,so that you can at any time focus on as big or as small a part of the system as you wish,while retaining the overall picture.Here,of course,the structuring and abstracting facilities of object technology will be precious. Scaling up also means that the criteria of extendibility and reusability,which have guided much of our earlier discussions,are just as applicable to analysis as they are to software design and implementation.Systems change,requiring their descriptions to follow;and systems are similar to previous systems,prompting us to use libraries of specification elements to build their specifications,just as we use libraries of software components to build their implementations. The clouds and the precipice It is not easy to reconcile the last two requirements of the above list.The conflict,already discussed in the context of abstract data types,has plagued analysis methods and specification languages as long as they have existed.How do you "express precise properties unambiguously"without saying too much?How do you provide readable broad-brush structural descriptions without risking vagueness? The analyst walks on a mountain path.On your left is the mountain top,deep ensconced in clouds;this is the realm of the fuzzy.But you must also stay away,on your right,from the precipice of overspecification,to which you might be perilously drawn if your attempts to be precise tempt you to say too much,especially by giving out implementation details instead of external properties of the system. The risk of overspecification is ever present in the minds of people interested in analysis.(It is said that,to gain the upper hand in a debate in this field,you should try "Approach X is nice,but isn't it a tad implementation-oriented?"The poor author of reputation lost,career shattered,will not dare show up in a software gathering for the next twenty years.)To avoid this pitfall,analysis methods have tended to err on the side of the clouds,relying on formalisms that do a good job of capturing overall structures, often through cloud-like graphical notations,but are quite limited when it comes to expressing the semantic properties of systems as required to address goal A2(answering precise questions)

§27.1 THE GOALS OF ANALYSIS 905 • There must be a way to let non-software people contribute input to the analysis, examine the results and discuss them (A1, A2). • The analysis must also have a form that is directly usable by software developers (A7). • The approach must scale up (A1). • The analysis notation must be able to express precise properties unambiguously (A3). • It must enable readers to get a quick glimpse of the overall organization of a system or subsystem (A1, A7) Scaling up (the third point) means catering to systems that are complex, large or both — the ones for which you most need analysis. The method should enable you to describe the high-level structure of the problem or system, and to organize the description over several layers of abstraction, so that you can at any time focus on as big or as small a part of the system as you wish, while retaining the overall picture. Here, of course, the structuring and abstracting facilities of object technology will be precious. Scaling up also means that the criteria of extendibility and reusability, which have guided much of our earlier discussions, are just as applicable to analysis as they are to software design and implementation. Systems change, requiring their descriptions to follow; and systems are similar to previous systems, prompting us to use libraries of specification elements to build their specifications, just as we use libraries of software components to build their implementations. The clouds and the precipice It is not easy to reconcile the last two requirements of the above list. The conflict, already discussed in the context of abstract data types, has plagued analysis methods and specification languages as long as they have existed. How do you “express precise properties unambiguously” without saying too much? How do you provide readable broad-brush structural descriptions without risking vagueness? The analyst walks on a mountain path. On your left is the mountain top, deep ensconced in clouds; this is the realm of the fuzzy. But you must also stay away, on your right, from the precipice of overspecification, to which you might be perilously drawn if your attempts to be precise tempt you to say too much, especially by giving out implementation details instead of external properties of the system. The risk of overspecification is ever present in the minds of people interested in analysis. (It is said that, to gain the upper hand in a debate in this field, you should try “Approach X is nice, but isn’t it a tad implementation-oriented ?” The poor author of X, reputation lost, career shattered, will not dare show up in a software gathering for the next twenty years.) To avoid this pitfall, analysis methods have tended to err on the side of the clouds, relying on formalisms that do a good job of capturing overall structures, often through cloud-like graphical notations, but are quite limited when it comes to expressing the semantic properties of systems as required to address goal A2 (answering precise questions)

906 OBJECT-ORIENTED ANALYSIS $27.2 Many of the traditional analysis methods fit this description.Their success comes from their ability to list the components of a system and describe their relations graphically,making them the software equivalent of the block diagrams of other engineering disciplines.But they are not too good at capturing the semantics.For software projects this carries a risk:believing that you have completed a successful analysis when all you have really done is to define the major components and their relations,leaving out many deeper properties of the specification that may turn out to be critical. Later in this chapter we will study ideas for reconciling the goals of structural description and semantic precision. 27.2 THE CHANGING NATURE OF ANALYSIS Although the object-oriented analysis literature hardly mentions this point,the most significant contribution of object technology to analysis is not technical but organizational.Object technology does not just provide new ways of doing analysis;it affects the very nature of the task and its role in the software process. This change follows from the method's emphasis on reusability.If instead of assuming that every new project must start from scratch,considering the customer's requirements as the Gospel,we bring into the picture the presence of a regularly growing repertory of software components,some obtained (or obtainable)from the outside and some developed as a result of in-house projects,the process becomes different:not the execution of an order from above,but a negotiation Customer Requirements analysis as a negotiation Compromise) Developer B The figure suggests this process:the customer starts with a requirement at A;you counter with a proposal at B,covering perhaps only part of the requirements,or a slightly different form of the requirements,but based for a large part on existing reusable components and hence achievable at significantly less cost and sooner.The customer may initially find the sacrifice of functionality too large;this opens a haggling phase which should eventually lead to an acceptable compromise. The haggling has always been there,of course.The customer's requirements were the Gospel only in some descriptions of the "software process"in the software engineering literature,presenting an ideal view for pedagogical purposes,and perhaps in some government contracts.In most normal situations,the developers had some freedom to discuss requirements.But with the advent of object technology this officious phenomenon becomes an official part of the software development process,and gains new prominence with the development of reusable libraries

906 OBJECT-ORIENTED ANALYSIS §27.2 Many of the traditional analysis methods fit this description. Their success comes from their ability to list the components of a system and describe their relations graphically, making them the software equivalent of the block diagrams of other engineering disciplines. But they are not too good at capturing the semantics. For software projects this carries a risk: believing that you have completed a successful analysis when all you have really done is to define the major components and their relations, leaving out many deeper properties of the specification that may turn out to be critical. Later in this chapter we will study ideas for reconciling the goals of structural description and semantic precision. 27.2 THE CHANGING NATURE OF ANALYSIS Although the object-oriented analysis literature hardly mentions this point, the most significant contribution of object technology to analysis is not technical but organizational. Object technology does not just provide new ways of doing analysis; it affects the very nature of the task and its role in the software process. This change follows from the method’s emphasis on reusability. If instead of assuming that every new project must start from scratch, considering the customer’s requirements as the Gospel, we bring into the picture the presence of a regularly growing repertory of software components, some obtained (or obtainable) from the outside and some developed as a result of in-house projects, the process becomes different: not the execution of an order from above, but a negotiation. The figure suggests this process: the customer starts with a requirement at A; you counter with a proposal at B, covering perhaps only part of the requirements, or a slightly different form of the requirements, but based for a large part on existing reusable components and hence achievable at significantly less cost and sooner. The customer may initially find the sacrifice of functionality too large; this opens a haggling phase which should eventually lead to an acceptable compromise. The haggling has always been there, of course. The customer’s requirements were the Gospel only in some descriptions of the “software process” in the software engineering literature, presenting an ideal view for pedagogical purposes, and perhaps in some government contracts. In most normal situations, the developers had some freedom to discuss requirements. But with the advent of object technology this officious phenomenon becomes an official part of the software development process, and gains new prominence with the development of reusable libraries. Requirements analysis as a negotiation Customer Developer A B (Compromise)

$27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY 907 27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY Object technology also affects,of course,the techniques of analysis. Here the most important thing to learn is that we have almost nothing to learn.The framework defined in the preceding chapters has more than enough to get us started with modeling."More than enough"actually means too much:the notation includes an operational part,made of two components which we do not need for analysis: Instructions (assignments,loops,procedure calls,...)and all that goes with them Routine bodies of the do form (but we do need deferred routines to specify operations without giving out their implementation). If we ignore these imperative elements,we have a powerful system modeling method and notation.In particular: Classes will enable us to organize our system descriptions around object types,in the broad sense of the word"object"defined in preceding chapters (covering not just physical objects but also important concepts of the application domain). The ADT approach-the idea of characterizing objects by the applicable operations and their properties-yields clear,abstract,evolutionary specifications. To capture inter-component relations,the two basic mechanisms of "client"and inheritance are appropriate.The client relation,in particular,covers such information modeling concepts as"part of,association and aggregation. As we saw in the discussion of objects,the distinction between reference and expanded clients corresponds to the two basic kinds of modeling association. Inheritance-single,multiple and repeated-addresses classification.Even such seemingly specialized inheritance mechanisms as renaming will be precious to model analysis concepts. Assertions are essential to capture what was called above the semantics of systems: properties other than structural.Design by Contract is a powerful guide to analysis. Libraries of reusable classes will provide us-especially through their higher-level deferred classes-with ready-made specification elements. This does not necessarily mean that the approach seen so far covers all the needs of system analysis (a question that will be discussed further below);but it certainly provides the right basis.The following example will provide some evidence. 27.4 PROGRAMMING A TV STATION Let us see concretely how to apply the O-O concepts that we know to pure modeling The example involves organizing the schedule of a television station.Because it is drawn from a familiar application area,we can start it(although we most likely could not complete it)without the benefit of input from"domain experts",future users etc.;we can just,for the analysis exercise,rely on every layperson's understanding of TV. Although the effort may be the prelude to the construction of a computerized system to manage the station's programming automatically,this possibility is neither certain nor relevant here;we are just interested in modeling

§27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY 907 27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY Object technology also affects, of course, the techniques of analysis. Here the most important thing to learn is that we have almost nothing to learn. The framework defined in the preceding chapters has more than enough to get us started with modeling. “More than enough” actually means too much: the notation includes an operational part, made of two components which we do not need for analysis: • Instructions (assignments, loops, procedure calls, …) and all that goes with them. • Routine bodies of the do form (but we do need deferred routines to specify operations without giving out their implementation). If we ignore these imperative elements, we have a powerful system modeling method and notation. In particular: • Classes will enable us to organize our system descriptions around object types, in the broad sense of the word “object” defined in preceding chapters (covering not just physical objects but also important concepts of the application domain). • The ADT approach — the idea of characterizing objects by the applicable operations and their properties — yields clear, abstract, evolutionary specifications. • To capture inter-component relations, the two basic mechanisms of “client” and inheritance are appropriate. The client relation, in particular, covers such information modeling concepts as “part of”, association and aggregation. • As we saw in the discussion of objects, the distinction between reference and expanded clients corresponds to the two basic kinds of modeling association. • Inheritance — single, multiple and repeated — addresses classification. Even such seemingly specialized inheritance mechanisms as renaming will be precious to model analysis concepts. • Assertions are essential to capture what was called above the semantics of systems: properties other than structural. Design by Contract is a powerful guide to analysis. • Libraries of reusable classes will provide us — especially through their higher-level deferred classes — with ready-made specification elements. This does not necessarily mean that the approach seen so far covers all the needs of system analysis (a question that will be discussed further below); but it certainly provides the right basis. The following example will provide some evidence. 27.4 PROGRAMMING A TV STATION Let us see concretely how to apply the O-O concepts that we know to pure modeling. The example involves organizing the schedule of a television station. Because it is drawn from a familiar application area, we can start it (although we most likely could not complete it) without the benefit of input from “domain experts”, future users etc.; we can just, for the analysis exercise, rely on every layperson’s understanding of TV. Although the effort may be the prelude to the construction of a computerized system to manage the station’s programming automatically, this possibility is neither certain nor relevant here; we are just interested in modeling