Software Design

1. Software Design Structured Design Techniques Object-Oriented Design Techniques

2. April 2007 IF1483 - RPL 2 Agenda Design Feedback Software Design Lecture Structured Design Techniques Object-Oriented Design Techniques Schedule Reorganization Prototype due date

3. April 2007 IF1483 - RPL 3 Structured Design Data Flow-oriented Design Steps Establish type of information flow Determine information flow boundaries Map DFD into program structure Define control hierarchy by factoring Refine model using design measures and heuristics

4. April 2007 IF1483 - RPL 4 Beginning the Design Process Review the fundamental system model Level 0 diagram SRS Review and refine data flow diagrams for the software Determine whether DFD exhibits transform or transaction characteristics

5. April 2007 IF1483 - RPL 5 Transform vs. Transaction Flow Transform Flow Incoming Flow Transform Center Outgoing Flow Transaction Flow Transaction Center

6. April 2007 IF1483 - RPL 6 Transform Mapping Isolate the transform center by specifying incoming and outgoing flow boundaries Perform �first-level� factoring Top-level modules: decision making Middle-level modules: some control and some work Low-level modules: perform most input, computational, and output work Perform �second-level� factoring Mapping individual transforms of a DFD into appropriate modules Refine the first iteration program structure using design heuristics Deign Heuristics: Sensible factoing Good Cohesion Minimal Coupling Structure: �implemented without difficulty, tested without confusion, and maintained without grief�Deign Heuristics: Sensible factoing Good Cohesion Minimal Coupling Structure: �implemented without difficulty, tested without confusion, and maintained without grief�

7. April 2007 IF1483 - RPL 7 Transform Analysis Example

8. April 2007 IF1483 - RPL 8 Transform Analysis Example

9. April 2007 IF1483 - RPL 9 First Level Factoring

10. April 2007 IF1483 - RPL 10 Transaction Mapping Identify the transaction center and the flow characteristics along each action path Find transaction center Identify incoming path and isolate action paths Evaluate each action path for transform vs. transaction characteristics Map the DFD in a program structure amenable to transaction processing Factor and refine the transaction structure and the structure of each action path Refine the first iteration program using design heuristics

11. April 2007 IF1483 - RPL 11 Transaction Analysis Example

12. April 2007 IF1483 - RPL 12 Transaction Analysis Example

13. April 2007 IF1483 - RPL 13 Object Modeling Steps Identify objects and classes Prepare a data dictionary Identify associations between objects Identify attributes of objects and links Organize and simplify object classes using inheritance Verify that access paths exist for likely queries Iterate and refine the model Group classes into modules Identify Object Classes Prepare a data dictionary Isolated words have too many meanings Precise paragraph describing - scope of class, assumptions/restrictions on membership or use; associations, attributes and operations Identify associations (including aggregations) between objects Identify attributes of objects and links Organize and simplify object classes using inheritance Verify that access paths exist for likely queries Trace paths to see if they yield reasonable results (I.e, unique value - path with unique result, multiplicity - way to select unique values when needed) Are there useful questions that cannot be answered? - missing info Simple real world, but complex model - may be missing something Iterate and refine the model Group classes into modules Tightly coupled classes should be grouped together Module - set of classes that captures some logical subset of entire model Look for cut points (sole connection between two parts) - forms bridge module Star pattern - single core module, surrounded by more specialized modulesIdentify Object Classes Prepare a data dictionary Isolated words have too many meanings Precise paragraph describing - scope of class, assumptions/restrictions on membership or use; associations, attributes and operations Identify associations (including aggregations) between objects Identify attributes of objects and links Organize and simplify object classes using inheritance Verify that access paths exist for likely queries Trace paths to see if they yield reasonable results (I.e, unique value - path with unique result, multiplicity - way to select unique values when needed) Are there useful questions that cannot be answered? - missing info Simple real world, but complex model - may be missing something Iterate and refine the model Group classes into modules Tightly coupled classes should be grouped together Module - set of classes that captures some logical subset of entire model Look for cut points (sole connection between two parts) - forms bridge module Star pattern - single core module, surrounded by more specialized modules

14. April 2007 IF1483 - RPL 14 Object Oriented Design Exercise

15. April 2007 IF1483 - RPL 15 Tentative Object Classes Suggested in Class ATM, Customer, Cashier, Account, Card Reader, Bank, UI, Receipt, Transaction, Cash Card, Security, Records, Station, Consortium Other possibilities (good and bad) Software, Banking Network, Bank computer, Cashier Station, Account data, Transaction data, Central computer, User, Cash, System, Record keeping provision, Access, Cost, Communications line, Transaction log Suggested in Class ATM, Customer, Cashier, Account, Card Reader, Bank, UI, Receipt, Transaction, Cash Card, Security, Records, Station, Consortium Other possibilities (good and bad) Software, Banking Network, Bank computer, Cashier Station, Account data, Transaction data, Central computer, User, Cash, System, Record keeping provision, Access, Cost, Communications line, Transaction log Good Classes: Account, ATM Bank, Bank Computer, Cash Card, Cashier, Cashier Station, Central Computer, Consortium, Customer, TransactionSuggested in Class ATM, Customer, Cashier, Account, Card Reader, Bank, UI, Receipt, Transaction, Cash Card, Security, Records, Station, Consortium Other possibilities (good and bad) Software, Banking Network, Bank computer, Cashier Station, Account data, Transaction data, Central computer, User, Cash, System, Record keeping provision, Access, Cost, Communications line, Transaction log Good Classes: Account, ATM Bank, Bank Computer, Cash Card, Cashier, Cashier Station, Central Computer, Consortium, Customer, Transaction

16. April 2007 IF1483 - RPL 16 Keeping the Right Classes Remove/Rename/Reorganize Redundant classes Irrelevant classes Vague classes Attributes Operations Roles Implementation Constructs Redundant - two classes express the same info, keep the most descriptive name Example: User Irrelevant - little or nothing to do with problem - eliminate; out of context Example: Cost Vague - class should be specific, watch for ill-defined boundaries, broad scope Examples: System, Security Provision, Record Keeping Provision, Banking Network Attribute - names that describe individual objects Example: Account Data, Receipt, Cash, Transaction Data Operations - operation applied to object and not manipulated in its own right Roles - name should reflect intrinsic nature, not role it plays in an association Implementation - remove constructs extraneous to the real world, can be added during design Examples: Transaction Log, Access, Software, Communications LineRedundant - two classes express the same info, keep the most descriptive name Example: User Irrelevant - little or nothing to do with problem - eliminate; out of context Example: Cost Vague - class should be specific, watch for ill-defined boundaries, broad scope Examples: System, Security Provision, Record Keeping Provision, Banking Network Attribute - names that describe individual objects Example: Account Data, Receipt, Cash, Transaction Data Operations - operation applied to object and not manipulated in its own right Roles - name should reflect intrinsic nature, not role it plays in an association Implementation - remove constructs extraneous to the real world, can be added during design Examples: Transaction Log, Access, Software, Communications Line

17. April 2007 IF1483 - RPL 17 Tentative Associations Verb Phrases Banking network includes cashiers and ATMs Consortium shares ATMs Bank provides bank computer Bank computer maintains accounts Bank computer processes transaction against account Bank owns cashier station Cashier station communicates with bank computer Cashier enters transaction for account ATMs communicate with central computer about transaction Central computer clears transaction with bank ATM accepts cash card ATM interacts with user ATM dispenses cash ATM prints receipts System handles concurrent access Banks provide software Cost apportioned to banks Implicit/Problem Domain Consortium consists of banks Bank holds account Consortium owns central computer System provided record keeping System provides security Customers have cash cards Cash card accesses accounts Verb Phrases: Banking network includes cashiers and ATMs Consortium shares ATMs Bank provides bank computer Bank computer maintains accounts Bank computer processes transaction against account Bank owns cashier station Cashier station communicates with bank computer Cashier enters transaction for account ATMs communicate with central computer about transaction Central computer clears transaction with bank ATM accepts cash card ATM interacts with user ATM dispenses cash ATM prints receipts System handles concurrent access Banks provide software Cost apportioned to banks Implicit/Problem Domain: Consortium consists of banks Bank holds account Consortium owns central computer System provided record keeping System provides security Customers have cash cards Cash card accesses accounts Bank employs cashiersVerb Phrases: Banking network includes cashiers and ATMs Consortium shares ATMs Bank provides bank computer Bank computer maintains accounts Bank computer processes transaction against account Bank owns cashier station Cashier station communicates with bank computer Cashier enters transaction for account ATMs communicate with central computer about transaction Central computer clears transaction with bank ATM accepts cash card ATM interacts with user ATM dispenses cash ATM prints receipts System handles concurrent access Banks provide software Cost apportioned to banks Implicit/Problem Domain: Consortium consists of banks Bank holds account Consortium owns central computer System provided record keeping System provides security Customers have cash cards Cash card accesses accounts Bank employs cashiers

18. April 2007 IF1483 - RPL 18 Keeping the Right Associations Remove/Rename/Reorganize Associations between eliminated classes Irrelevant or implementation associations Actions Ternary associations Derived associations Misnamed associations Qualified associations Multiplicity Missing associations Eliminated classes - if one of classes is gone, remove or restate with real class Examples: Banking network includes cashiers and ATMs, Cost apportioned to banks, ATM prints receipts, ATM dispenses cash, System provided record keeping, System provides security, Banks provide software Irrelevant/Implementation - outside domain or implementation constructs Examples: System handles concurrent access Actions - describe structural property not a transient event Examples: ATM accepts cash card, ATM interacts with user Ternary Associations - decompose into binary or qualified associations Examples: Cashier enters transaction for account -> Cashier enters transaction & Transaction concerns account; Bank computer processes transaction against account; ATMs communicate with central computer about transaction -> ATMs communicate with central computer & Transaction entered on ATM Derived Associations - associations defined in terms of other associations Examples: Consortium shares ATMs = Consortium owns central computer + Central computer communicates with ATMs Misnamed - don�t say how or why situation came about, say what it is Role names - add role names when appropriate Example: person manages person -> boss manages worker Qualified associations - name identifies an object within a context, context + name = unique identifier Multiplicity - specify (unique, many, etc.) Missing - add missing associations Examples: Transaction entered on cashier station, customers have accounts, transaction authorized by cash card, Cashier authorized on cashier stationEliminated classes - if one of classes is gone, remove or restate with real class Examples: Banking network includes cashiers and ATMs, Cost apportioned to banks, ATM prints receipts, ATM dispenses cash, System provided record keeping, System provides security, Banks provide software Irrelevant/Implementation - outside domain or implementation constructs Examples: System handles concurrent access Actions - describe structural property not a transient event Examples: ATM accepts cash card, ATM interacts with user Ternary Associations - decompose into binary or qualified associations Examples: Cashier enters transaction for account -> Cashier enters transaction & Transaction concerns account; Bank computer processes transaction against account; ATMs communicate with central computer about transaction -> ATMs communicate with central computer & Transaction entered on ATM Derived Associations - associations defined in terms of other associations Examples: Consortium shares ATMs = Consortium owns central computer + Central computer communicates with ATMs Misnamed - don�t say how or why situation came about, say what it is Role names - add role names when appropriate Example: person manages person -> boss manages worker Qualified associations - name identifies an object within a context, context + name = unique identifier Multiplicity - specify (unique, many, etc.) Missing - add missing associations Examples: Transaction entered on cashier station, customers have accounts, transaction authorized by cash card, Cashier authorized on cashier station

19. April 2007 IF1483 - RPL 19 Initial Object Diagram

20. April 2007 IF1483 - RPL 20 Tentative Attributes Possibilities (good and bad) Consortium - Bank code Bank - Name, card code, account code, employee code, station code Account - Balance, credit limit, type Customer - name, address Central Computer - station code, bank code Bank Computer - station code Cashier - Name Cashier transaction - kind, date-time, amount ATM - cash on hand, dispensed Remote transaction - kind, date-time, amount Cash card - password

21. April 2007 IF1483 - RPL 21 Keeping the Right Attributes Remove/Rename/Reorganize Objects Qualifiers Names Identifiers Link attributes Internal values Fine detail Discordant attributes Objects - is independent existence important, not just value? Yes - object, no - attribute Qualifiers - if value depends on context, consider making it qualifier of association Names - often better modeled as qualifiers rather than attributes (Does it select among objects in a set? Can an object have more than one name?) Identifiers - object identifiers for unique reference to an object, do not model - they are implicit Link attributes - if property depends on existence of link, then property is link attribute not object attribute Internal values - eliminate if it describes internal state, invisible to outside Fine detail - omit minor attributes that unlikely to affect most operations Discordant attributes - may indicate need to split class into two classesObjects - is independent existence important, not just value? Yes - object, no - attribute Qualifiers - if value depends on context, consider making it qualifier of association Names - often better modeled as qualifiers rather than attributes (Does it select among objects in a set? Can an object have more than one name?) Identifiers - object identifiers for unique reference to an object, do not model - they are implicit Link attributes - if property depends on existence of link, then property is link attribute not object attribute Internal values - eliminate if it describes internal state, invisible to outside Fine detail - omit minor attributes that unlikely to affect most operations Discordant attributes - may indicate need to split class into two classes

22. April 2007 IF1483 - RPL 22 Refining with Inheritance Generalizing into super-class Share common features May suggest themselves from real world taxonomy Symmetry Refining into sub-class Apparent from application domain Enumerated sub-cases Multiple Inheritance Generalization - Remote & Cashier transaction - both Transactions Cashier station & ATM - Entry Station Refinement - Account - could be specialized into Checking, Savings, etc.Generalization - Remote & Cashier transaction - both Transactions Cashier station & ATM - Entry Station Refinement - Account - could be specialized into Checking, Savings, etc.

23. April 2007 IF1483 - RPL 23 Iterating Object Modeling Missing objects assymetries disparate attributes & operations on classes difficulty generalizing operation, no target duplicate associations, same name & purpose role shapes class semantics Extra classes lack of attributes, operations & associations Missed Association no operation access paths Extra Associations redundant information lack of operations that traverse association Incorrect Placements Associations: role names are too broad or too narrow for class Attributes: access object by one of its attribute values Missing objects - - assymetries in associations and generalizations - add new classes by analogy - disparate - split class, so each part is coherent - difficulty generalizing cleanly - one class playing two roles, split it up - operation with no good target class - add missing class - duplicate associations - missing super-class that unites them - role substantially shapes semantics of class - may be a separate class, usually associations Extra class - if no actions, attributes, etc. why do you need the class? Missed Associations - missing access paths for operations - add new associations to answer queries Unnecessary Associations - redundant information - remove those that don�t add new info or mark derived - lack of operations that traverse association - if no operations use a path, may the information is not needed Incorrect Placement of Associations - role names are too broad or too narrow - move association up/down in hierarchy Incorrect Placement of Attributes - need to access an object by one of its attribute values - consider a qualified associationMissing objects - - assymetries in associations and generalizations - add new classes by analogy - disparate - split class, so each part is coherent - difficulty generalizing cleanly - one class playing two roles, split it up - operation with no good target class - add missing class - duplicate associations - missing super-class that unites them - role substantially shapes semantics of class - may be a separate class, usually associations Extra class - if no actions, attributes, etc. why do you need the class? Missed Associations - missing access paths for operations - add new associations to answer queries Unnecessary Associations - redundant information - remove those that don�t add new info or mark derived - lack of operations that traverse association - if no operations use a path, may the information is not needed Incorrect Placement of Associations - role names are too broad or too narrow - move association up/down in hierarchy Incorrect Placement of Attributes - need to access an object by one of its attribute values - consider a qualified association

24. April 2007 IF1483 - RPL 24 Revised Object Model Cash card - authorization unit & piece of plastic data, split into Card authorization & Cash card Transaction - not general enough to allow transfer between accounts Distinction between Bank & Bank computer and Consortium & Central computer, does not affect the analysis; merge Bank computer into Bank and Central computer into Consortium Possible Modules: Tellers - cashier, entry station, cashier station, ATM Accounts - account, cash card, card authorization, customer, transaction, update, cashier transaction, remote transaction Banks - consortium, bank Cash card - authorization unit & piece of plastic data, split into Card authorization & Cash card Transaction - not general enough to allow transfer between accounts Distinction between Bank & Bank computer and Consortium & Central computer, does not affect the analysis; merge Bank computer into Bank and Central computer into Consortium Possible Modules: Tellers - cashier, entry station, cashier station, ATM Accounts - account, cash card, card authorization, customer, transaction, update, cashier transaction, remote transaction Banks - consortium, bank

25. April 2007 IF1483 - RPL 25 Coming Up Next... Deliverables Prototype & User Documentation Due Friday, 10 December Lecture: Happy Thanksgiving!