Unit 5

(net time : 219 min)

Section 1 Object-Oriented Design

What is OOP:

Each object encapsulate program logic + attributes;

a set of object cooperate with messages;

instantiation = create object in execution;

organized at different layers or machines.

OOP models (p297 F10-2)

component diagram for architectural design

              API: set of public methods

enterprise-level system:

client-server vs internet (stateless, browser, webserver): state, client/sever configuration

internet architecture: two layers. CGI(Common gateway interface)+ application server(for embedded language)

design class: domain class + method signatures + elaborated attributes

              stereotype: <<>> entity or persistent (file M), boundary(View), control (C), data access class

class-level: static in java; visibility: public+/private-

abstract/concrete: whether can be instantiated.

qualitative measure:

less coupling: reduce the rippling effect

more cohesion: reduce the rippling effect, increase reusability and readability

              protection from variation->separate static and dynamic into different layers

              object responsibility: knowing + doing (decentralized?)

design steps: (use case driven)

first-cut for navigation visibility (capable to view and interact: attribute/parameter)

CRC cards (class-responsibility-collaboration: class name +responsibility +collaborating classes with return data +attributes on back)

detailed sequence diagram (first-cut -> multilayer)

add method signature and navigation info

partition into packages

use case realization: interaction diagrams elaboration for each use case

Section 2 Use Case Realization

Use case realization: use case taken individually, all classes identified, main integrity of architectural design and complete design class diagram

design pattern: best practices like controller pattern (artifact object, decoupling), 23 from GoF (Gang of Four)

              name, problem, solution, example, benefits and consequences

sequence/communication diagram 5 elements: actor, object (viewer/domain, rather than just system), input, output, lifeline (more than SSD which has only 2)

              start of any detail design

              * [true/false condition] return-value:= message-name (parameter-list)

              first-cut includes problem domain class only, no user interface or database

first-cut sequence diagram 3 steps:

determine internal messages with its objective, source, destination, required info, consequences

              identify complete set of classes

              add iteration, condition, return value, parameter

initial use case realization 3 assumptions: perfect technology, memory and solution (no exception)

multi-layer order: domain -> view -> data access

              separation of responsibilities: separate and focus, modulization

              2 ways to link domain and data access:

construct in domain and collect data from data access

instantiate in data access and return an object to domain

Communication diagram vs sequence diagram: link symbol replaces lifeline symbol, plus sequence number, for small use case

package diagram: dashed arrow for dependency

3-layer responsibility

              view: display forms, reports, data fields; capture input events; accept, edit, evaluate, forward input data; start and shut down system

              domain: create persistent classes; process business rules; prepare for storage

              data access: connect/disconnect database; contain SQL statements; process result sets into domain objects

Adapter: translator, limit changes in adapter

factory: create utility objects, higher cohesion and less coupling, easy to maintain

singleton: ensure one instance via private static constructor.