Design Tips

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

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

Design

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

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.

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

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

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.

Other Processes (cont.) Extreme Programming

UML Use OPEN Web Applications J2EE Architecture XML applications