Unit-4 OBJECT ORIENTED DESIGN WORKFLOW

Unit-4 OBJECT ORIENTED DESIGN WORKFLOW SYLLABUS: Design workflow-format of the attributes- allocation of operations- Osbert Oglesby case study- Workflows of the unified process-phases of the unified process- class diagrams-use case diagrams- Interaction diagrams-state charts-package diagrams-deployment diagrams. 4.1 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 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 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 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: o 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 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 1

It does not make sense to break up the two case studies into subsystems they are just too small 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 o The information system as a whole can then be delivered sooner 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 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 o 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 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 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 4.2 FORMAT 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 o 12/03/1947 in the United States (MM/DD/YYYY format), and o 03/12/1947 in Europe (DD/MM/YYYY format) For both date conventions, 10 characters are needed 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 2

Adding an item too early will make the next iteration unnecessarily burdensome Formats are therefore added during the design workflow Examples: First name of an artist is up to 20 characters in length, optionally followed by? if there is uncertainty o firstnameofartist : 21 chars Title is up to 40 characters in length, optionally with? o title : 41 chars Height and width are measured in centimeters o height, width : 4 digits (up to 9999 centimeters, or 99.99 meters) Prices o targetsellingprice, actualsellingprice, maxpurchaseprice : 8 digits (up to $99,999,999) Dates o dateofpurchase, dateofsale, auctiondate : 10 chars Fashionability coefficient This could be a large number or a small number 3

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) For safety, coefficient is of type 4 + 4 digits Range is High: 9999.9999 Low: 0.0001 Class diagram with the formats of attributes added Example: An asset number consists of 12 characters o assetnumber : 12 digits Annual operating expenses are up to $999,999,999.99 o estimatedannualoperatingexpenses : 9 + 2 digits 4.3 ALLOCATION OF OPERATIONS 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 4

Only then can the operations be allocated to the classes 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 Third iteration of the initial MSG class diagram 4.3.1 RESPONSIBILITY-DRIVEN DESIGN The principle of responsibility-driven design o 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 Responsibility-Driven Design: MSG Case Study 5

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 o 3: Request estimated return on investments for week 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 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 Allocation of getannualreturnoninvestment 6

4.3.2 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 Convention in an object-oriented information system Associated with each attribute of a class are operations o setattribute, used to assign a particular value to that attribute; and o 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 o Operation setassetnumber is used to assign the number of the asset to the object that represents that asset o Operation getassetnumber is used to obtain the asset number of the asset represented by that object 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 o setinvestmentnumber o setmortgagenumber Two separate functions are needed because the traditional paradigm does not support inheritance In the object-oriented paradigm Consider the MSG inheritance hierarchy 7

Asset Class has attribute assetnumber Inherited by Investment Class and Mortgage Class Thus o Every instance of class Investment Class, and o 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 o Every instance of class Investment Class, and o Every instance of class Mortgage Class Allocation of setassetnumber, getassetnumber Operation setassetnumber can then be applied to instances of Class Investment Class or Class Mortgage Class Allocation of Operations: Osbert Oglesby Fifth iteration of the initial class diagram 8

4.4 OSBERT OGLESBY CASE STUDY 4.4.1 RESPONSIBILITY-DRIVEN DESIGN: OSBERT OGLESBY CASE STUDY Consider operation getauctionprice Irrespective of the source of the message requesting an auction price o Operation getauctionprice must be allocated to Auctioned Painting Class Allocation of getauctionprice 9

4.4.2 INHERITANCE: OSBERT OGLESBY CASE STUDY Consider operations o settitle and o gettitle Example: Osbert prints a list of all his paintings o Each object in the information system in turn is examined o A message is sent to operation gettitle to obtain the title of the painting represented by that object To which class must operations o settitle and o gettitle be allocated? First consider operation settitle In the traditional paradigm, there would have to be three different versions of settitle, one for each type of painting o set_masterpiece_title o set_masterwork_title o set_other_painting_title That is because the traditional paradigm does not support inheritance In the object-oriented paradigm, consider the Painting Class inheritance hierarchy Painting Class has attribute title o This attribute is inherited by instances of its 5 subclasses Gallery Painting Class Auctioned Painting Class Masterpiece Class Masterwork Class Other Painting Class Thus, operation settitle must be allocated to Painting Class so that it can be inherited (and used) by instances of all five subclasses This applies to all operations, including gettitle Allocation of operations settitle and gettitle 10

4.5 WORKFLOWS OF THE UNIFIED PROCESS There are five core workflows Requirements workflow Analysis workflow Design workflow Implementation workflow Test workflow In each increment, part of each of these five workflows is carried out In addition to the five core workflows, the Unified Process includes other workflows Management Planning The Requirements Workflow The aim of the requirements workflow To ensure that the developers build the right information system The analysis workflow The aim of the analysis workflow To analyze and refine the requirements Why not do this during the requirements workflow? The requirements artifacts must be totally comprehensible by the client The artifacts of the requirements workflow must therefore be expressed in a natural (human) language All natural languages are imprecise Example from a manufacturing information system: A part record and a plant record are read from the database. If it contains the letter A directly followed by the letter Q, then calculate the cost of transporting that part to that plant 11

To what does the it refer? The part record? The plant record? Or the database? Two separate workflows are needed The requirements artifacts must be expressed in the language of the client The analysis artifacts must be precise, and complete enough for the designers The Design Workflow The aim of the design workflow is to refine the analysis workflow until the material is in a form that can be implemented by the programmers Many nonfunctional requirements need to be finalized at this time, including» Choice of programming language» Reuse issues» Portability issues The Implementation Workflow The aim of the implementation workflow is to implement the target information system in the selected implementation language A large information system is partitioned into subsystems The subsystems consist of components or code artifacts The Test Workflow The test workflow is the responsibility of the quality assurance group Each component is tested as it has been implemented o Unit testing At the end of each iteration, the completed components are compiled and linked together (integrated) and tested o Integration testing When the product appears to be complete, it is tested as a whole o Product testing Once the completed product has been installed on the client s computer, the client tests it o Acceptance testing 4.6 PHASES OF THE UNIFIED PROCESS In the figure, the increments are identified as phases 12

The four increments are labeled o Inception phase o Elaboration phase o Construction phase o Transition phase The phases of the Unified Process are the increments In theory, there could be any number of increments o In practice, development seems to consist of four increments Every step performed in the Unified Process falls into o One of the five core workflows and also o One of the four phases Why does each step have to be considered twice? Workflow o Presented in a technical context Phase o Presented in a business context 4.6.1 The Inception Phase The aim of the inception phase is to determine whether the proposed information system is economically viable 1. Gain an understanding of the domain 2. Build the business model 3. Delimit the scope of the proposed project o Focus on the subset of the business model that is covered /by the proposed information system 4. Begin to make the initial business case The Inception Phase : The Initial Business Case Questions that need to be answered include: o Is the proposed information system cost effective? o How long will it take to obtain a return on investment? o Alternatively, what will be the cost if the company decides not to develop the proposed information system? o If the information system is to be sold in the marketplace, have the necessary marketing studies been performed? o Can the proposed information system be delivered in time? o If the information system is to be developed to support the client organization s own activities, what will be the impact if the proposed information system is delivered late? What are the risks involved in developing the information system, and How can these risks be mitigated? o Does the team who will develop the proposed information system have the necessary experience? o Is new hardware needed for this information system 13

o If so, is there a risk that it will not be delivered in time? o If so, is there a way to mitigate that risk, perhaps by ordering back-up hardware from another supplier? o Are software tools (Chapter 11) needed? o Are they currently available? o Do they have all the necessary functionality? Answers are needed by the end of the inception phase so that the initial business case can be made The Inception Phase: Use Cases and Risks The next step: o Identify the use cases o Prioritize them in the order of the risk that they carry There are three major risk categories: o Technical risks o The risk of not getting the requirements right Mitigated by performing the requirements workflow correctly o The risk of not getting the architecture right The architecture may not be sufficiently robust To mitigate all three classes of risks o The use cases need to be prioritized in order of associated risk so that the critical risks are mitigated first This concludes the steps of the inception phase that fall under the requirements workflow The Inception Phase: Analysis, Design Workflows A small amount of the analysis workflow may be performed during the inception phase A few critical use cases are analyzed, so that the design of the architecture can begin Thus, a small amount of the design workflow may be performed, too The Inception Phase: Implementation Workflow Coding is generally not performed during the inception phase Sometimes a proof-of-concept prototype is build to test the feasibility of part of the information system o This is not a rapid prototype constructed to be certain that the requirements have been accurately determined Rapid prototyping is not part of the Unified Process o A proof-of-concept prototype is more like an engineering prototype A scale model constructed to test the feasibility of construction The Inception Phase: Test Workflow The test workflow commences almost at the start of the inception phase o The aim is to ensure that the requirements have been accurately determined 14

The Inception Phase: Planning There is insufficient information at the beginning of the inception phase to plan the entire development o The only planning that is done at the start of the project is the planning for the inception phase itself For the same reason, the only planning that can be done at the end of the inception phase is the plan for just the next phase, the elaboration phase The Inception Phase: Documentation The deliverables of the inception phase include: o The initial version of the domain model o The initial version of the business model o The initial version of the requirements artifact (especially the use cases) o A preliminary version of the analysis artifacts o A preliminary version of the architecture o The initial list of risks o The initial ordering of the use cases o The plan for the elaboration phase The initial version of the business case The Inception Phase: The Initial Business Case Obtaining the initial version of the business case is the overall aim of the inception phase This initial version incorporates o A description of the scope of the information system o Financial details o If the proposed information system is to be marketed, the business case will also include Revenue projections, market estimates, initial cost estimates o If the information system is to be used in-house, the business case will include The initial cost benefit analysis 4.6.2 The Elaboration Phase The aim of the elaboration phase is to refine the initial requirements o Refine the use cases o Refine the architecture o Monitor the risks and refine their priorities o Refine the business case o Produce the project management plan The major activities of the elaboration phase are refinements or elaborations of the previous phase 15

The Tasks of the Elaboration Phase The tasks of the elaboration phase correspond to: o All but completing the requirements workflow o Performing virtually the entire analysis workflow o Starting the design of the architecture The Elaboration Phase: Documentation The deliverables of the elaboration phase include: o The completed domain model o The completed business model o The completed requirements artifacts o The completed analysis artifacts o An updated version of the architecture o An updated list of risks o The project management plan (for the rest of the project) o The completed business case 4.6.3 Construction Phase The aim of the construction phase is to produce the first operational-quality version of the information system o This is sometimes called the beta release The Tasks of the Construction Phase The emphasis in this phase is on o Implementation, and o Testing Unit testing of modules Integration testing of subsystems Product testing of the overall system The Construction Phase: Documentation The deliverables of the construction phase include: o The initial user manual and other manuals, as appropriate o All the artifacts (beta release versions) o The completed architecture o The updated risk list o The project management plan (for the remainder of the project) o If necessary, the updated business case 4.6.4 The Transition Phase The aim of the transition phase is to ensure that the client s requirements have indeed been met 16

o Faults in the information system are corrected o All the manuals are completed o Attempts are made to discover any previously unidentified risks This phase is driven by feedback from the site(s) at which the beta release has been installed The Transition Phase: Documentation The deliverables of the transition phase include: o All the artifacts (final versions) o The completed manuals 4.7 CLASS DIAGRAMS A class diagram depicts classes and their interrelationships Here is the simplest possible class diagram Class diagram showing more details of Bank Account Class Add as many (or as few) details as appropriate for the current iteration and incrementation Class Diagrams: Notation Freedom of notation extends to objects Example: o bank account : Bank Account Class Bank account is an object, an instance of a class Bank Account Class o The underlining denotes an object o The colon denotes an instance of o The bold face and initial upper case letters in Bank Account Class denote that this is a class UML allows a shorter notation when there is no ambiguity 17

o bank account The UML notation for modeling the concept of an arbitrary bank account is o : Bank Account Class The colon means an instance of, so o : Bank Account Class means o an instance of class Bank Account Class Class Diagrams: Visibility Prefixes UML visibility prefixes (used for information hiding) o Prefix + indicates that an attribute or operation is public Visible everywhere o Prefix denotes that the attribute or operation is private Visible only in the class in which it is defined o Prefix # denotes that the attribute or operation is protected Visible either within the class in which it is defined or within subclasses of that class Example: o Class diagram with visibility prefixes added o Attribute accountbalance is visible only within the Bank Account Class o Operations deposit and withdraw are accessible from anywhere within the information system 4.7.1 AGGREGATION Example: A car consists of a chassis, an engine, wheels, and seats 18

The open diamonds denote aggregation o Aggregation is the UML term for the part whole relationship The diamond is placed at the whole (car) end, not the part (chassis, engine, wheels, or seats) end of the line connecting a part to the whole 4.7.2 MULTIPLICITY Example: A car consists of one chassis, one engine, 4 or 5 wheels, an optional sun roof, zero or more fuzzy dice hanging from the rear-view mirror, and 2 or more seats The numbers next to the ends of the lines denote multiplicity o The number of times that the one class is associated with the other class Item 1: o The line connecting Chassis Class to Car Class The 1 at the part end of the line denotes that there is one chassis involved The 1 at the whole end denotes that there is one car involved o Each car has one chassis, as required o Similar observations hold for the line connecting Engine Class to Car Class Item 2: o The line connecting Wheels Class to Car Class The 4..5 at the part end together with the 1 at the whole end denotes that each car has from 4 to 5 wheels (the fifth wheel is the spare) o A car has 4 or 5 wheels, as required Instances of classes come in whole numbers only Item 3: o The line connecting Sun Roof Class to Car Class Two dots.. denote a range, so the 0..1 means zero or one, the UML way of denoting optional o A car has an optional sun roof, as required Item 4: 19

o The line connecting Fuzzy Dice Class to Car Class The * by itself means zero or more o Each car has zero or more fuzzy dice hanging from the rear-view mirror, as required Item 5: o The line connecting Seats Class to Car Class An asterisk in a range denotes or more, so the 2..* means 2 or more o A car has two or more seats, as required If the exact multiplicity is known, use it o Example: The 1 that appears in 8 places o If the range is known, use the range notation o Examples: 0..1 or 4..5 o If the number is unspecified, use the asterisk o Example: * o If the range has upper limit unspecified, combine the range notation with the asterisk notation o Example: 2..* 4.7.3 COMPOSITION Aggregation example: Every chess board consists of 64 squares This relationship goes further o It is an instance of composition, a stronger form of aggregation Association o Models the part whole relationship Composition o Also models the part whole relationship o In addition, every part may belong to only one whole o If the whole is deleted, so are the parts Example: A number of different chess boards o Each square belongs to only one board o If a chess board is thrown away, all 64 squares on that board go as well Composition is depicted by a solid diamond 20

4.7.4 GENERALIZATION Inheritance is a required feature of object orientation Inheritance is a special case of generalization o The UML notation for generalization is an open triangle o Sometimes the open triangle is labeled with a discriminator Every instance of Asset Class or its subclasses has an attribute assettype (the discriminator) o This attribute can be used to distinguish between instances of the subclasses 4.7.5 ASSOCIATION The association between the two classes may be modeled as a class o Example: Suppose the radiologist consults the lawyer on a number of occasions, each one for a different length of time Now consults has become a class, Consults Class, which is called an association class o Because it is both an association and a class 21

4.8 USE CASE DIAGRAMS A use case is a model of the interaction between o External users of an information system (actors) and o The information system itself More precisely, an actor is a user playing a specific role A use-case diagram is a set of use cases Generalization of actors is supported o The open triangle points toward the more general case 4.9 INTERACTION DIAGRAMS Interaction diagrams show how objects interact with one another UML supports two types of interaction diagrams o Sequence diagrams o Collaboration diagrams 4.9.1 Sequence Diagrams Example: Dynamic creation followed by destruction of an object 22

The lifelines in the sequence diagram o An active object is denoted by a thin rectangle (activation box) in place of the dashed line Creation of the : Masterpiece Class object is denoted by the lifeline starting at the point of dynamic creation Destruction of that object after it receives message 9: Destroy object o is denoted by the heavy X A message is optionally followed by a message sent back to the object that sent the original message Even if there is a return, it is not necessary that a specific new message be sent back o Instead, a dashed line ending in an open arrow indicates a return from the original message, as opposed to a new message There is a guard on the message 9: [offer rejected] Destroy object o Only if Osbert s offer is rejected is message 9 sent A guard (condition) is something that is true or false o The message sent only if the guard is true The purpose of a guard o To ensure that the message is sent only if the relevant condition is true Iteration an indeterminate number of times is modeled by an asterisk (Kleene star) Example: Elevator (see next slide) *move up one floor o The message means: move up zero or more floors Sequence diagram for elevator An object can send a message to itself o A self-call 23

Example: o The elevator has arrived at a floor o The elevator doors now open and a timer starts o At the end of the timer period the doors close again o The elevator controller sends a message to itself to start its timer this self-call is shown in the previous UML diagram 4.9.2 Collaboration Diagrams Collaboration diagrams are equivalent to sequence diagrams o All the features of sequence diagrams are equally applicable to collaboration diagrams o Use a sequence diagram when the transfer of information is the focus of attention Use a collaboration diagram when concentrating on the classes 4.10 STATE CHARTS The elevator is in state Elevator Moving o It performs operation Move up one floor o while guard [no message received yet] remains true, until it receives the message Elevator has arrived at floor Receipt of this message (event) causes the guard to be false It also enables a transition to state Stopped at Floor o In this state, activity Open the elevator doors o is performed The most general form of a transition label is event [guard] / action o If event o has taken place and [guard] o is true, the transition occurs, and, while it is occurring, action o is performed Statechart with guards 24

An event also causes transitions between states Example: The receipt of a message Equivalent statement with most general transition The transition label is o Elevator has arrived at floor [a message has been received] / Open the elevator doors o The guard o [a message has been received] o is true when the event o Elevator has arrived at floor o has occurred and the message has been sent The action to be taken is o Open the elevator doors There are two places where an action can be performed in a statechart o When a state is entered Activity o As part of a transition Action An event can be specified in terms of words like when or after Example: o When (cost > 1000) or after (2.5 seconds) 25

Superstates combine related states States A, B, C, and D all have transitions to Next State Combine them into superstate ABCD Combined o Now there is only one transition o The number of arrows is reduced from four to only one States A, B, C, and D all still exist in their own right Example: Four states are unified into MSG Combined 4.11 PACKAGE DIAGRAMS A large information system is decomposed into relatively independent packages UML notation for a package 26

Example showing the contents of My Package 4.12 DEPLOYMENT DIAGRAMS A deployment diagram shows on which hardware component each software component is installed (or deployed) It also shows the communication links between the hardware components Example: 4.13 OTHER UML DIAGRAMS 4.13.1 Component Diagrams A component diagram shows dependencies among software components, including o Source code o Compiled code 27

o Executable load images Example: o Programmers write source code in an object-oriented language C++ or Java o The source code is translated by a compiler into compiled code (The binary code that is the only language a computer understands) o The compiled code for each module is combined with run-time routines to produce an executable load image (that is, a program) Example: 4.13.2 Activity Diagrams Activity diagrams show how various events are coordinated o Used when activities are carried on in parallel Example: o One diner orders chicken, the other fish o The waiter writes down their order, and hands it to the chef o The meal is served only when both dishes have been prepared Example: A fork has o One incoming transition, and 28

o Many outgoing transitions, each of which starts an activity to be executed in parallel with the other activities A join has o Many incoming transitions, each of which lead from an activity executed in parallel with the other activities, and o One outgoing transition that is started when all the parallel activities have been completed Example: A company that assembles computers as specified by the customer The three departments involved o Assembly Department o Order Department o Accounts Receivable Department o are each in their own swimlane 29