OOAD

Object-Oriented Programming

Object-Oriented

A more formal definition of object

• An object is an entity with a well-defined boundary and identity that encapsulates state and behavior.
• Object are useful only when they can collaborate to solve a problem.
  • They interact through messages.

Object-Oriented Principles

Abstraction(Modeling)

• Any model that includes the most important, essential or distinguishing aspects of something while suppressiong or ignoring less important, imaterial, or diversionary details. The result of removing distinctions emphasize commonalities. (Dictionary of Object Technology, Firesmith, Eykholt, 1995)

  Encapsulation

• Design, produce and describe software so that it can be easily used without knowing the details of how it works.

  Inheritance

  Polymorphism

• The ability to hide many different implementation behind a single interface.

  Composition

• Defined dynamically at runtime
• Does not break encapsulation

Object-Oriented Development

SASD(Structured Analysis and Structured Design)

• Used by Procedural Programming
• Top-Down, Divide and Conquer
  

OOAD(Object-Oriented Analysis and Design)

• OOA
  • Discover the domain concepts
  • Identify requirements
• OOD
  • Define softare objects(static model)
  • Define how they collaborate(dynamic model)

Software Process Model

• Waterfall Model
• Iterative Model(Agile)
  • Individual over processes and tools
  • Working software over documentation
  • Customer collaboration over contract negotiation
  • Responding to change over follow a plan
• RUP(Rational Unified Process)
  • Iterative
  • Small waterfall cycle
  • Industry standard for OO software

UML

Use Case Diagram

Use Cases

• Use cases are text stories
• Use case is not a diagram, but a text
• 3 levels: brief -> casual -> fully dressed
• Use case equals to Functional Requirement in RUP

  Use Case Diagram

• a summary of all use cases
• Primary Actor: Located on the left
• Supporting Actor: Located on the right
• Other systems can be actors.

  3 Formats of Use Cases

• Brief: main scenario
• Casual: various scenario. In OOA step.
• Fully Dressed: Add preconditions, Main success scenario, Extensions. In OOD step.

  Guideline

• Write in an Essential Style
  • UI-free style
  • (ex) Administrator enter ID and PW in dialog box
• Write Black-Box Use Cases
  • Don’t describe the internal working(Implementation)
  • (ex) The system generates a SQL INSERT statement for the sale

Class Diagram

UML Class Diagrams

• Domain model(OOA)
• Design Class Diagram(OOD)
  
• Object Diagram
  • Describe objects and their relationships at a specific moment in time
  • No need operations(All objects share it)
• Attribute Syntax
  • Derived Attribute
    
  • In/Out Parameters
    
• Operations and Methods
  • Operation is term used in the design stage
  • Method is term used in the implementation stage
• Types of Class Relationship
  

If Target changes, then Source may be affected.
Target is ignorant of Source, hence the change of Source is not propagated.

이런식으로 디펜던시를 수치화할수도 있다 SE

• Association Lines for attribute
  

• Active Class(Thread)
  

• Implement Interfacer
  

• Shared Aggregation
  

Sequence Diagram

Sequence Diagram vs Communication Diagram

What is the relationship between interaction and Class Diagram?

• Use case diagram -> Sequence diagram -> Class diagram
  

Statechart Diagram

Transition

Orthogonal State(AND State)

Submachine State

History State

• Shallow history state [ H ]
  • restores the state that is on the same level of the composite state
• Deep history state [ H* ]
  • restores the last active substate over the entire nesting depth

Activity Diagram vs Statechart Diagram

Component Diagram

Delagation and Assembly Connectors

OOAD

Object-Oriented Analysis and Design

Example - Dice Game

Unified Process(UP)

Software Development Process and the UP

• Iterative with fixed-length(3 weeks)
• Inspired from Agile
• industry standard for OO software

  Risk-Driven and Client-Driven Iterative Planning

• Architecture risk / Client risk

  The UP Phases

  1. Inception: approximate vision, business case, scope, vague cost estimates
  2. Elaboration: refine vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates
  3. Construction: iterative implementation of the remaining lower risk and easier elements and preparation for deployment
  4. Transition: beta tests, deployment
     

The relationship of UP Artifacts in one iteration

• Small waterfall
  

The UP Practices

• High-risk and high-value issues in early(Risk-driven, Client-driven)
• Continuously evaluation and feedback(Client-driven)
• Architecture-centric
• Test early(each iteration)

  You know you didn’t understand iterative development or the UP when…

• You think that inception = requirements, elaboration = design and contruction = implementation
• You think that the purpose of elaboration is to fully and carefully define models
• You believe that a suitable iteration length is three months

Inception Phase

What is Inception?

• What is the vision?
• Feasible?
• Buy or build?
• Rough unreliable range of cost
• Should we proceed or stop?

  Evolutionary Requirements

  

Elaboration - OOA

What happened in Inception?

• A short requirements workshop
• Most use cases written in brief format
• Most influential and risky requirements identified

  On to Elaboration

• The core, risky software architecture is programmed and tested.
• Most requirements are discovered and stabilized.
• The major risks are mitigated or retired

  Implement Requirements incrementally

  

UP Artifacts start in elaboration

• Domain Model(OOA)
  • no operation
  • associations between conceptual classes(no composition, no shared aggregation)
  • for making lower representation gap between models and real
  • UP domain model is not of software objects. Just for understanding the domain
• Design Model(OOD)
• Mini waterfall

  The relationship of UP Artifacts in one iteration

  

System Sequence Diagram(SSD)

• Use case diagram + Sequence diagram
  

Operation Contracts(Optional)

• contracts of high-level system operations
• (ex) Preconditions
  • describe changes in the state of objects

Elaboration - OOD

Software Architecture

• The selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements
• The composition of these structural and behavioral elements into progressively larger subsystems
• The architectural style

  Logical Architecture

• Large-scale organization of the software classes into packages, subsystems and layers
• Layer
  • A very coarse-grained grouping of classes, packages or subsystems
• Physical Architecture -> deploy diagram
  

On to Object Design

Designing Objects: Static vs Dynamic

• Static models(Class diagram)
• Dynamic models(Sequence diagram)
• Important equivalently
• Fundamental object design required knowledge of
  • GRASP
  • Design patterns

Elaboration - OOI

Designing for Visibility(Important!)

• The receiver must be visible to the sender
• Visibility is the ability of an object to see or have a reference to another object

  Visibility

  1. Attribute visibility
• Permanent visibility
• Has a reference
  1. Parameter visibility
• It is common to transform parameter visibility into attribute visibility(Constructor)
  1. Local visibility
• Create a new local instance
• Use returning object from a method
  1. Global visibility
• Singleton

  Mapping Designs to Code

• Class diagram -> Skeleton code -> Sequence diagram -> Method body
• Order of Implementation
  • From least-coupled to most-coupled