Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process

1. An Introduction toObject-Oriented Systems Analysis and Design with UML and the Unified ProcessMcGraw-Hill, 2004Stephen R. Schachsrs@vuse.vanderbilt.edu

2. CHAPTER 8 — Unit A THE OBJECT-ORIENTED DESIGN WORKFLOW

3. Chapter Overview • The Design Workflow • Traditional versus Object-Oriented Design • Formats of the Attributes • Allocation of Operations to Classes • Allocation of Operations: Osbert Oglesby Case Study • CRC Cards

4. The Design Workflow • The input to the design workflow is the set of analysis workflow artifacts • These artifacts are iterated and incremented until they can be used by the programmers • A major aspect of this iteration and incrementation is • The identification of operations, and • Their allocation to the appropriate classes

5. The Design Workflow (contd) • Many other decisions have to be made as part of the design workflow, including • Choice of programming language • Deciding how much of existing information systems to reuse in the new information system • Level of portability • The allocation of each software component to its hardware component

6. The Design Workflow (contd) • The case studies in this book are small-scale information systems • Under 5,000 lines of Java or C++ code in length • The Unified Process was designed for developing large-scale information systems • 500,000 lines of code or more • These information systems are at least 100 times larger than the case studies presented in this book • Therefore, many aspects of the Unified Process are inapplicable to the two case studies in this book

7. The Design Workflow (contd) • During the analysis workflow, a large information system is partitioned into analysis packages • Each analysis package consists of a set of related classes that can be implemented as a single unit • Example: • Accounts payable, accounts receivable, and general ledger are typical analysis packages • The concept underlying analysis packages is: • It is easier to develop smaller information systems than larger information systems • A large information system will be easier to develop if it can be decomposed into independent packages

8. The Design Workflow (contd) • The idea of decomposing a large workflow into independent smaller workflows is carried forward to the design workflow • The objective is to break up the upcoming implementation workflow into manageable pieces • Subsystems • It does not make sense to break up the two case studies into subsystems—they are just too small

9. The Design Workflow (contd) • Reasons why subsystems are utilized • It is easier to implement a number of smaller subsystems than one large system • If the subsystems are independent, they can be implemented by programming teams working in parallel • The information system as a whole can then be delivered sooner

10. The Design Workflow (contd) • The architecture of an information system includes • The various component modules • How they fit together • The allocation of components to subsystems • The task of designing the architecture is specialized • It is performed by an information system architect

11. The Design Workflow (contd) • The architect needs to make trade-offs • Every information system must satisfy its functional requirements (the use cases) • It also must satisfy its nonfunctional requirements, including • Portability, reliability, robustness, maintainability, and security • It must do all these things within budget and within the time constraint • The architect must assist the client by laying out the trade-offs

12. The Design Workflow (contd) • It is usually impossible to satisfy all the requirements, functional and nonfunctional, within the cost and time constraints • Some sort of compromises have to be made • The client has to • Relax some of the requirements; • Increase the budget; and/or • Move the delivery deadline

13. The Design Workflow (contd) • The architecture of an information system is critical • The requirements workflow can be fixed during the analysis workflow • The analysis workflow can be fixed during the design workflow • The design workflow can be fixed during the implementation workflow • But there is no way to recover from suboptimal architecture • The architecture must immediately be redesigned

14. Traditional versus Object-Oriented Design • In the traditional paradigm, the design phase consists of • Architectural design • The information system is decomposed into modules followed by • Detailed design • Algorithms and data structures are designed for each module

15. Traditional versus Object-Oriented Design (contd) • Classes are modules • Much of traditional architectural design is performed as part of class extraction in the object-oriented analysis workflow

16. The Design Workflow (contd) • Much of object-oriented design requires knowledge of programming • Programming knowledge is not a prerequisite for this book • In this chapter a description is therefore given of just one design artifact, the complete class diagram

17. Formats of the Attributes • As part of the design workflow, the exact format of each attribute of the class diagram must be specified • Example: A date is usually represented by 10 characters • For instance, December 3, 1947 is represented as • 12/03/1947 in the United States (MM/DD/YYYY format), and • 03/12/1947 in Europe (DD/MM/YYYY format) • For both date conventions, 10 characters are needed

18. Formats of the Attributes (contd) • The formats could be determined during the analysis workflow • However, the object-oriented paradigm is iterative • Information is added to models as late as possible • Adding an item too early will make the next iteration unnecessarily burdensome • Formats are therefore added during the design workflow

19. Formats of Attributes of Osbert Oglesby • Class diagram with the formats of attributes added

20. Formats of Attributes of Osbert Oglesby (contd) • Examples: • First name of an artist is up to 20 characters in length, optionally followed by ? if there is uncertainty • firstNameOfArtist : 21 chars • Title is up to 40 characters in length, optionally with ? • title : 41 chars • Height and width are measured in centimeters • height, width : 4 digits (up to 9999 centimeters, or 99.99 meters) • Prices • targetSellingPrice, actualSellingPrice, maxPurchasePrice : 8 digits (up to $99,999,999) • Dates • dateOfPurchase, dateOfSale, auctionDate : 10 chars

21. Formats of Attributes of Osbert Oglesby (contd) • Fashionability coefficient • This could be a large number or a small number • The range can be determined only by computing coefficients from a sample of Osbert’s sales • High: 985 (Rembrandt van Rijn) • Low: 0.064 (Joey T. Dog)

22. Formats of Attributes of Osbert Oglesby (contd) • For safety, coefficient is of type 4 + 4 digits • Range is • High: 9999.9999 • Low: 0.0001

23. Formats of Attributes of MSG Case Study • Class diagram with the formats of attributes added

24. Formats of Attributes of MSG Case Study (contd) • Example: • An asset number consists of 12 characters • assetNumber : 12 digits • Annual operating expenses are up to $999,999,999.99 • estimatedAnnualOperatingExpenses : 9 + 2 digits

25. Allocation of Operations to Classes • Third iteration of the initial MSG class diagram

26. Allocation of Operations to Classes (contd) • There are empty rectangles at the bottoms of the boxes • The operations of the classes are missing from this class diagram • It is unwise to add an item to a UML diagram before it is strictly necessary to do so • The Unified Process is iterative • The operations are deduced from the interaction diagrams of the realizations of the use cases • These are produced after the class diagram

27. Allocation of Operations to Classes (contd) • First the initial class diagram is determined • Then the interaction diagrams of the realizations of the use cases • These interaction diagrams are used to deduce the operations • Only then can the operations be allocated to the classes

28. Allocation of Operations to Classes (contd) • Identifying the operations to be allocated to the various classes is easy • Determining to which class each operation should be allocated is hard • Three criteria are used • Responsibility-driven design • Inheritance • Polymorphism and dynamic binding (Chapter 20)

29. Responsibility-Driven Design • The principle of responsibility-driven design • If Class A sends a message to Class B telling it to do something, it is the responsibility of Class B to perform the requested operation

30. Responsibility-Driven Design • Example: • MSG Foundation case study

31. Responsibility-Driven Design (contd) • The weekly return on investments is computed by summing the estimated annual return of each investment and dividing by 52 • The sequence diagram includes the message • 3: Requestestimatedreturnoninvestmentsforweek • The MSG Foundation case study must therefore include the operation getAnnualReturnOnInvestment • Thus, for each object of class Investment Class, the estimated annual return on that investment can be determined

32. Responsibility-Driven Design (contd) • It is not important which class sends that message • What is important is that Investment Class has the responsibility of determining the annual return on an investment • Accordingly, operation getAnnualReturnOnInvestment must be allocated to Investment Class

33. Responsibility-Driven Design (contd) • Allocation of getAnnualReturnOnInvestment

34. Inheritance • Suppose an operation is applicable to • An instance of a superclass; and to • Instances of subclasses of that superclass • Allocate that operation to the superclass • Then there is just one version of that operation • It can be used by • Instances of the superclass and by • Instances of all its subclasses

35. Inheritance (contd) • Convention in an object-oriented information system • Associated with each attribute of a class are operations • setAttribute, used to assign a particular value to that attribute; and • getAttribute, which returns the current value of that attribute • Example: In the MSG case study every asset has an asset number • Asset Class has an attribute assetNumber • Operation setAssetNumber is used to assign the number of the asset to the object that represents that asset • Operation getAssetNumber is used to obtain the asset number of the asset represented by that object

36. Inheritance (contd) • To which class should operation setAssetNumber be allocated? • In the traditional paradigm, there would be two different versions of setAssetNumber, one for each of the two types of asset • That is, there would have to be • setInvestmentNumber • setMortgageNumber • Two separate functions are needed because the traditional paradigm does not support inheritance

37. Inheritance (contd) • In the object-oriented paradigm • Consider the MSG inheritance hierarchy

38. Inheritance (contd) • Asset Class has attribute assetNumber • Inherited by Investment Class and Mortgage Class • Thus • Every instance of class Investment Class, and • Every instance of class Mortgage Class has attribute assetNumber that consists of 12 characters • Any operation of class Asset Class that could be applied to attribute assetNumber • Can also be applied to attribute assetNumber of • Every instance of class Investment Class, and • Every instance of class Mortgage Class

39. Inheritance (contd) • Allocation of setAssetNumber, getAssetNumber

40. Inheritance (contd) • Operation setAssetNumber can then be applied to instances of • Class Investment Class or • Class Mortgage Class

41. Allocation of Operations: Osbert Oglesby • Fifth iteration of the initial class diagram

42. Continued in Unit 8B