✂ � ✂ ✄ ✁ ✄ ☎ ☎ ✁ ✆ ☎ ✂ � Midterm Reminder The midterm is next Tuesday: March 2, 7-9 p.m. Location : Stirling Hall rooms A, B and C CISC 323 By last name (regardless of section): Last Name Room Introduction to Software A-G Stirling A Engineering H-M Stirling B N-Z Stirling C Topic 5: Material : Object-Oriented Design (OOD), Chapter 9 all material up through (and including) Friday. readings for all topics on web site. Monday : review, Q&A CISC 323, Winter 2004, OOD 1 From OOA To OOD Subtopics Remember main points of our high-level process : 5.1: The object-oriented design process in the UA 1. Analyze and model application domain and its requirements 5.2: Attributes of good designs (OOA) 2. Transform this model into design of implementation (OOD) coupling, cohesion, information hiding 3. Then implement it in Java/C++/… (OOP) readability, modifiability, etc 4. Iterate and refine all the time 5.3: Use attributes to guide design and Smooth flow from analysis to design to implementation implementation may… help correctness 2 examples reduce development time ensure requirements are satisfied/addressed in implementation CISC 323, Winter 2004, OOD 3 CISC 323, Winter 2004, OOD 4
5.1: Object-Oriented Design Process in OO Design Process the Unified Approach Check 1. Use quality attributes to guide Design classes, Quality methods, Attributes attributes, and design of classes, their attributes, Refine UML associations class diagrams methods, associations, and protocols 1.1. Refine and complete static UML class diagram OO Design (object model) by adding details to UML class Check diagram by: Design Design classes, User satisfaction quality view/access methods, and usability test attributes 1.1.1. Refine attributes layers and attributes, and based on use cases Refine UML prototype associations 1.1.2. Design methods and protocols by utilizing a UML class diagrams Continuous testing activity diagram to represent method's algorithm 1.1.3. Refine associations between classes 1.1.4. Refine class hierarchy and design with inheritance 1.2. Iterate and refine again CISC 323, Winter 2004, OOD 5 CISC 323, Winter 2004, OOD 6 OO Design Process (Cont’d) OO Design Process (Cont’d) Design view/access Design User satisfaction layers and view/access 2. Design the access layer 3. Design the view layer classes and usability test prototype layers and based on use cases prototype 2.1. Create mirror classes : For every business class 3.1. Design macro level user identified and created, create one access class interface by identifying view layer objects 2.2. Define relationships among access layer classes 3.2. Design micro level user interface , which includes these 2.3. Simplify class relationships : Main goal is to activities: eliminate redundant classes & structures 3.2.1. Design the view layer objects by using quality attributes 3.2.2. Build a prototype of the view layer interface 2.3.1. Redundant classes : Do not keep 2 classes that perform similar translate activities 3.3. Test usability and user satisfaction 2.3.2. Method classes : Revisit classes that consist of only 3.4. Iterate and refine one or two methods to see if they can be eliminated or 4. Iterate and refine preceding steps. Reapply design combined with existing classes 2.4. Iterate and refine again axioms and, if needed, repeat preceding steps CISC 323, Winter 2004, OOD 7 CISC 323, Winter 2004, OOD 8
☛ ✟ ✎ ✎ ✠ ✟ ✠ ✠ ✟ ✠ ✟ ✠ ✏ ✠ ✡ ✞ ✎ ✎ ✞ ✍ ✝ ✌ ☞ ☞ ☛ 5.2: Attributes Of Good Software Attributes Of Good Software Design Design (Cont’d) 1) Realization of requirements: Will code meet 2) Readability: How easy is to requirements? understand the design? Performance: see where particular functionality is realized? Execution time: Does code provide sufficiently fast response locate the source of a problem? time? Throughput? … 3) Modifiability: For a given change, how easy is it Resource use: Does executing program fit within available memory? Disk space? Network latency, bandwidth? for a programmer to Fault-tolerance: How robust to faults will the system be? work out where changes have to be made? Usability : How easy will it be to use the system? what changes have to be made? Implementation Resources: Can design be implemented enact these changes? within available resources? How much of the system is impacted? … CISC 323, Winter 2004, OOD 9 CISC 323, Winter 2004, OOD 10 Attributes Of Good Software Design Attributes Of Good Software Design (Cont’d) (Cont’d) Criteria may be conflicting . Design may involve 4) Reusability: How easy is it to reuse (parts of) the tradeoffs (e.g., reusability versus implementation time) system in other contexts and for other purposes? In order to meet certain requirements, one criterion may Is code sufficiently general to support reuse in many have to take precedence over another contexts w/o change? Examples : Does copied code make any implicit assumptions Commercial document preparation software (e.g., about input data) that old context happens to meet need: high modifiability, high reuse but not the new one? don’t need: high performance Missile control system 5) Maintainability: How easy is it to perform need : high performance, high correctness/reliability maintenance tasks on the system? don’t need: high reuse, high modifiability CISC 323, Winter 2004, OOD 11 CISC 323, Winter 2004, OOD 12
✑ ✑ ✑ More Fundamental Attributes Of Good Fundamental Attribute 1: Coupling Software Design Other, more fundamental criteria exist Measure of how connected components are, 1. Coupling that is, roughly, 2. Cohesion coupling of component C = #components on which C depends 3. Information Hiding “System S has high/strong coupling” : On average, components in S depend on many other components “System S has low/loose coupling” : On average, components in S depend on few other components CISC 323, Winter 2004, OOD 13 CISC 323, Winter 2004, OOD 14 Example Of System With High Example Of System With Low Coupling Coupling CISC 323, Winter 2004, OOD 15 CISC 323, Winter 2004, OOD 16
✗ ✖ ✖ ✕ ✒ ✓ ✕ ✗ ✔ ✕ ✓ ✕ ✔ ✓ ✒ ✗ Coupling: The Bottom Line Fundamental Attribute 2: Cohesion Systems with low coupling tend to have Measure of how clear or unique the purpose of a high readability component is To understand a component, may have to understand “System S has high cohesion” : interfaces of all components on which component depends On average, a component in S serves a single, clearly defined high modifiability purpose Modification to interface of one component may impact all components which depend on modified interface “System S has low cohesion” : and therefore also high maintainability and On average, a component in S serves several, only weakly reusability related purposes Systems with high coupling are more likely to Example : A method doA() is more cohesive than a have low readibility and modifiability, and thus method doAandBandPossiblyC() also low maintainability and reusability CISC 323, Winter 2004, OOD 17 CISC 323, Winter 2004, OOD 18 Example Of High Cohesion Example Of High Cohesion (Cont’d) Purpose of Marks Client User Interface : Implement user interface allowing students to specify course for which they want marks, then retrieve these marks Display information to students Purposes of Marks Client : Connect over network to Marks Server, obtain marks information for specific student, course CISC 323, Winter 2004, OOD 19 CISC 323, Winter 2004, OOD 20
✛ ✚ ✢ ✣ ✜ ✤ ✣ ✤ ✣ ✤ ✤ ✚ ✙ ✚ ✙ ✜ ✜ ✙ ✘ ✣ ✤ Example For Low Cohesion Cohesion: The Bottom Line Two-layered architecture for payroll system : Systems with high cohesion are more likely to have high readability Name Address components are easier to understand Title Owner Data have high modifiability [Selby and Basili, 1991]: Routines with high cohesion can be 20 times less costly to fix than routines with low cohesion Workstation have high reliability • Layer 1: for user interaction, computation, and translation [Card, Church, Agresti, 1986]: Routines with high cohesion • Layer 2: for storage are more than twice as likely to be fault-free CISC 323, Winter 2004, OOD 21 CISC 323, Winter 2004, OOD 22 Fundamental Attribute 3: Information Information Hiding: The Bottom Line Hiding Component makes code that, e.g., Systems with good information hiding are more likely to embodies low-level implementation-oriented design have high readability decisions because independencies are revealed uses very complex data or logic have low coupling because the more information a components hides, the less information is likely to change can other components access and depend upon invisible and inaccessible to the outside have high modifiability [Korson and Vaishnavi, 1986]: Programs with information hiding are up to 4 times easier to modify than programs that don’t because changes less likely to break other code and propagate have high reliability because changes to code with high modifiability are more likely to result in a correctly working system, than changes to code with low modifiability CISC 323, Winter 2004, OOD 23 CISC 323, Winter 2004, OOD 24
Recommend
More recommend
