NOTES CHAPTER 17 OBJECT-ORIENTED DESIGN SOFTWARE LIFE CYCLE - activities that take place between program conception and retirement - starts: customer willing to pay to get problem solved - Department of Defense pioneer of formalized development - identify and describe different phases - how to carry out phases - when to move between phases - common phases - analysis - decide what the program is supposed to accomplish - output: requirements document: - describe functionality in complete detail - may include user manual - performance criteria - how it will perform - what it will require to do so - design - develop plan for how to implement - discover underlying structures: object oriented: choose classes and methods - output: - description of classes and methods - diagrams of relationships among classes - implementation - write and compile code to implement classes and methods - output: completed program - testing - run tests to verify program - output: report of tests and results - deployment: users install and use - waterfall model - phases are sequential - didn't work well - difficult to come up with perfect specification - design phase often revealed - inconsistent requirements - minor changes that would improve the product or process - implementation often revealed design not good enough: speed, concurrency - many bugs best fixed by reimplementation or even redesign - customers not happy with end product: don't know own requirements! - deal with errors from previous phase: levels of iteration - spiral model - Barry Boehm - 1988 - early phases construct prototypes - small system that shows some aspects of the final system - do not need to withstand customer abuse - implemented quickly - user interface prototype - common - let customers become familiar enough to suggest improvements before finish analysis - other purposes - validate interfaces with external systems - test performance - lessons learned applied to next iteration - can take longer - believe there is always another iteration - don't do the best possible on this one - Rational Unified Process - inventors of UML - complex - multiple iterations - Extreme Programming - Kent Beck - cut out formality, replace with practices - realistic planning - customers make business decisions - programmers make technical decisions - update if conflicts w/ reality - small releases - get useful system out quickly - release small updates rapidly - metaphor: all programmers have some idea of what the system's supposed to be - simplicity over preparing for future complexity - testing - tests written by customers and programmers - occurs continuously - refactoring - improve code, eliminate duplication - continually restructure system - pair programming: two programmers code together on a single computer - collective ownership: any programmer can change any code - continuous integration: every time finish subtask, build and test whole system - 40 hour week: realistic schedules - on-site customer: constant availability of end user - coding standards: self-documenting code - programmer productivity - variation in performance of 5 to 10 times - skills: - good judgment - experience - broad knowledge - attention to detail, - superior planning - man month - how many months it would take one programmer to do it - can't trade programmers for time linearly: lose time - ramping up - communicating - waiting on dependences - no alternative to teamwork DEVELOPMENT PROCESS FOR BEGINNNING PROGRAMMERS - gather requirements - use CRC cards to find classes, responsibilities, and collaborators - use UML diagrams to record class relationships - use javadoc to document method behavior - implement your program - more advanced design methods for larger, more complex projects - atypical to come up with perfect design on first try - seldom one best design - systematic approach - reduces cost of design flaws - allows reorganization in design phase DISCOVERING CLASSES - design phase: discover structures that make it possible to implement a set of tasks - discover classes - determine responsibility of each class - describe relationship between classes - class represents some useful concept - concrete entities - abstract concepts - find classes - look for nouns in the task description - keep a list of candidate classes: add all brainstorm ideas - not all nouns should be classes - principals to keep in mind - class represents set of objects w/ same behavior - entities with multiple occurrences are good candidates - determine commonality - design classes to capture commonalities - specification may contain examples; distinguish these (instances) from classes which represent their commonality - some nouns should probably be fields of another class, not their own class - entity as object or primitive? - depends on task - if need to analyze entity, good candidate for class - if only used literally, primitive probably fine - balance limitation and excessive generality - not all will be discovered in analysis - most need classes for tactical purposes - helper/component classes - tester classes - some necessary classes may already exist - standard library - previous program - use inheritance to extend existing classes - things that are computed and not stored don't need classes - define behavior for each class - what methods object needs - look for verbs in task description and match to objects - CRC (classes, responsibilities, collaborators) card method - end result: index card for each class - make a list of major tasks - repeat: - pick a nontrivial, intuitive task - ask yourself how it can actually be done - decide which class is responsible - make index card for class you think shold be responsible - write responsibility (task) on this class' card - if needs help from other objects, make CRC cards for those classes - record other classes needed to fulfill task (collaborators) - look up collaborator cards - add method to perform collaborative role if not already present - cross out, move, split, and merge responsibilities as necessary - done when - mapped all major tasks - convinced they can all be solved with listed classes and responsibilities - high level responsibilities: may actually require multiple methods - informal - event-based programs and state diagrams RELATIONSHIPS BETWEEN CLASSES - encapsulate common behavior into superclass - assign different programmers to implement unrelated classes (reduce waiting) - dependency relationship - class depends on another if it uses an object of the other class - UML: dashed line with open arrow pointing to dependent class - inheritance - important - not the only useful relationship - can be overused - between more general class (superclass) and more specialized (subclass) - is-a relationship - UML: solid line, triangle tip - aggregation - has-a relationship - use instance field - one class aggregates another if its objects have objects of the other - strong form of dependency, but not the only one (e.g. local variables, parameter types also dependencies, but not necessarily aggregates) - generally needed if must remember object between method calls - UML: solid line with diamond-shaped symbol next to aggregating class - interface UML: dotted arryow, triangle tip - make a class diagram - add inheritance - is-a - one class is a specialization of another - many designs won't use extensively - use collaborators column from CRC to draw usage arrows - aggregation arrow: if locates collaborator via stored referenc - dependency arrow: if collaborator method parameter or return value - indicate attributes and methods in class diagram - attribute - externally observable property that objects of a class have - usually correspond to instance variables - divide class rectangle into three parts - top: class name - middle: attributes - bottom: methods - don't have to list all - don't list aggregates as attributes DOCUMENTATION - write java source file for each class - write method headers - leave method bodies blank - comment methods - easily share documentation with others - format is immediately useful for implemenation - ensure have comments for key methods IMPLEMENTATION - have method signatures nad comments from documentation step - add instance fields - use UML diagram - come from aggregated classes - use an array or ArrayList to store multiple items of the same type - implement methods: should be straightforward - add constructors - go back and match up final program with CRC cards and UML diagram