1. Design Tips

2. Becoming Good OO Developers
Developing good OO Software is hard
Takes a lot of time to take advantage of all OO features
Lots of Experience needed to become good designers
Many systems are not leveraging OO advantages
To master OO software design, study experienced developers design
Reuse proven software design
=> Patterns can help

3. Design Tips & Hints (High level Patterns)
Layering
Improves stability, understandability, flexibility
Reduces impact to changes
Restrict dependencies/coupling between packages/subsystems
GUI (Boundary Classes) separated in one layer/package
Allow the User Interface to change without impacting the rest of the system
Package Functionally related Classes
Changes in one Class impact the other Class
Rich Interaction between Classes
Package should be cohesive
Reuse proven software design
=> Patterns can help

4. Design

5. Design Refine the Class Diagram Structure system
Subsystems, Interfaces, Classes
Define subsystems dependencies
Capture major interfaces between subsystems
Assign responsibilities to new design classes
Describe realization of Use Cases
Use Sequence and Collaboration Diagrams
Assign visibility to class attributes
Define Methods signature
Develop State diagram for relevant design classes
Use Interaction Diagram to distribute behavior among classes
Use Design Patterns for parts of the system

6. Design Problems
Rigidity: Every change causes a cascade of subsequent changes in dependent modules
Fragility: Tendency to break in many places every time the software is changed
Immobility: Inability to reuse software from other projects or parts of same projects
Viscosity: Easier to change the software by breaking the architecture rules than by respecting them.

7. Design Principles Open-Closed Concept Design by Contract
Software Entities (Classes, Modules, Functions) should be Open for Extension, but Closed for Modification
(Change the what modules do without modifying their code)
Design by Contract
Use Assertion, Pre-condition, Post-condition, to ensure robustness and corrrectness.
Assertion: property of some of the values of the program entities.
Pre-condition: expresses the properties that must hold whenever the method is called
Post-condition: expresses the properties that the method guarantees when it is called

8. Design Principles (cont.)
Dependency Inversion
Primary mechanism / strategy
Depend upon interfaces or abstract classes rather than upon concrete methods and classes.
Interface segregation
When a class has multiple clients, create specific interfaces for each client.
Packaging principles
Common Closure: Classes that change together, belong together.
Dependencies between packages should not form cycles
Depend in the direction of stability

9. Other Processes
OPEN
Object-oriented Process, Environment, and Notation
Third-generation, public domain, full lifecycle, process-focused, methodological approach
Work Products: components that are developed by the project.
Languages: components used to document most work products.
Producers: components that develop work products.
Work Units: components that model the operations performed by producers when developing work products.
Stages: time intervals that provide a macro organization to the work units.

10. Other Processes (cont.)
Extreme Programming

11. UML Use
OPEN
Web Applications
J2EE Architecture
XML applications