[객체지향개발론] Motivation for OO Modeling

successful software product 의 조건

• stakeholder(이해관계자)의 requirements(요구)를 satisfy, 만족해야한다.

  • requirements 는 functional, non-functional 로 분류된다. functional 은 기능적인 부분, non-functional 은 퍼포먼스 부분을 뜻한다.

• 제시간에 (On time), 예산에 맞게 (On budget) 개발해야 한다.

• 변화(change)에 탄력이 있어야(resilient) 한다. → 요구 변화에 대한 탄력적인 수용이 필요하다.

📌 소프트웨어 크기가 커지면서 생긴 문제 : with development process

Software systems were like cathedrals; first we build them and then we pray - S. Redwine

• 작은 사이즈일 때 프로그램이 잘 작동하더라도, 사이즈가 커질수록 그것을 만족시키지 못하게 될 수도 있다.
• 1960년대, size와 complexity가 커지면서 충분한 price, time 없이는 높은 퀄리티의 소프트웨어를 만들 수 없게 되었다. → software crisis → 이 때문에 software engineering 이라는 단어가 탄생하게 됨.

  Software engineering

• 이는 마치 다리를 건설하는 것과 같다. (그만큼 설계적)
• 소프트웨어 생산의 모든 측면에 관련된 engineering discipline이다.

Development process

• Development process란 who is doing what, when and how to reach a certain(누가 무엇을, 언제 어떻게해서 특정한 것에 도달하는지)를 정의하는 것을 말한다.
• software engineering 측면에서 goal 은 소프트웨어 프로덕트를 만들거나, 기존의 프로덕트를 향상시키는 것이다.

Basic workflows

• Analysis, Design, Implementation, Testing

Conventional Waterfall Model

• 이론 : 아주 심플해보여서 좋아보임. (unknown factor 가 적을 때)

• 실제 : 엄청난 backtracking 이 일어난다.

• waterfall model 을 적용했을 때, 프로젝트 성공 확률이 16.2% 밖에 되지 않았다. 따라서 문제점을 살펴보았다.

  • Long delays
  • High development cost
  • High cancellation rate
  • Low quality (in reliability, extensibility, maintainability etc.)
  • High maintenance cost

• 또한 잘못된 가정을 살펴보자.

  1. Requirements can be Fairly Accurate, 요구사항이 정확하다.
     → 요구사항은 언제나 변화한다.
  2. Requirements are Stable, 요구사항은 안정적이다.
     → 시장(market)과 기술은 계속 변화한다. 또한 stakeholders 의 목표 또한 계속 변화한다.
     ⇒ moving target problem (requirement 는 개발 중에도, 그리고 후에도 계속 변한다.)
  3. Design can be Done, before Programming, 프로그래밍 전에 설계를 끝낼 수 있다.
     → 요구사항은 incomplete & changing 하고, 많은 변수이 존재한다. 또한 완전한 명세서는 코드만큼 상세해야 한다. → 따라서 어려움...

Iterative & Incremental Process

• 따라서 다른 방안을 선택! waterfall 을 iterative lifecycole 로 대체한다. (aka. evolutionary or spiral)

• Iterative

  • 전체 시스템을 한 번에 구축하는 대신, 여러 개의 빌드를 갖는다.
  • 빌드는 전체 기능의 하위 집합만 포함한다.

• Incremental

  • 소프트웨어는 이전 빌드 위에 개발된다.
  • 각 반복(Iterative)에서 작지만 눈에 띄게 개선한다.

• Small steps & feedback & refinement & adaptation

• Time-boxed (고정된 최대 시간 단위)

• Iterative Development 의 장점

  • high risk(technical, requirements) 를 빨리 알아차리고, 대응할 수 있다.
  • Early visible 한 진행
  • Early feedback, user engagement(참여) and adaptation(적응)
  • Managed complexity ; 매우 길고 복잡한 과정에 압도당하지 않음.
  • 반복에 의해 프로세스 자체를 개선 가능.

• Popular Iterative Process : The Unified Process(UP)
  

📌 앞선 문제를 프로그램 근본적으로 해결하는 방법 : paradigm 변화

• 앞서 개발 프로세스를 바꾸어서 문제를 해결해보고자 하였다. 하지만 개발 비용에서 가장 큰 비중을 차지하는 것은 Revise & Maintain. 즉, 유지보수와 관련된 부분이기 때문에 Amdahl's law 처럼 다른 부분을 아무리 줄여도, 유지보수 비용 때문에 일정수준 이상으로 cost 가 좋아지지 않는다는 것이다.

• 따라서 프로그램의 근본을 다시 적용해본다.

  • 프로그래밍 : 현실 세계를 mapping 하여 전산화하는 것.
  • (in procedure paradigm) program = data structure + algorithm

Object paradigm

• 한 달간 약 8% 로 business rules 가 바뀐다고 한다. (우리는 이 변화에 맞춰 개발해야 한다)
• Object paradigm 은 복잡한 시스템을 해결 & 쉽게 적응할 수 있는 시스템을 지원한다.
• 따라서 rules 의 변화로 발생된 변경 비용과 시간을 줄일 수 있게 되는 것이다! (← object paradigm 을 사용해야 하는 이유)
• ) 추가적으로 1. 새로운 OS, tool 을 활용할 수 있도록 돕는다. 2. 우아하게(Elegantly) 복잡성 대처 & 쉬운 적응을 돕는다.

📌 Reuse 에 대해서

• 객체지향 프로그래밍에서 reuse 의 효율성이 있다고들 하지만, 함수로도 충분히 reuse 의 효과를 볼 수 있다.

• reuse 는 Object-level 에서는 가치있지 않다.

• 하지만, group 과 같은 high-level(pattern-level) 에서는 효과가 아주 좋다!

  • framework : 시스템 전체에 관한 structure 일수도 있는 것. (아무튼 큼...) & design + code 의 재사용 (scope 큼)
  • design pattern : 프레임워크보다 microscpoic(범위가 넓지않은)한 object의 structure interaction. & design knowledge 의 재사용 (scope 작음)

Design pattern

• 특정 context(상황)에서의 problem 과 그에 대한 solution 으로 이루어진 pair 로 설명된다.
• 자주 발생하는 문제의 디자인 패턴/검증된 솔루션에 이름을 붙여, 원활한 커뮤니케이션을 가능케한다.

Example : Adapter

• Context : Client object 가 Supplier object 의 메소드를 호출한다.

• Problems : Client object 가 Supplier object 가 제공하는 인터페이스와는 다른 인터페이스를 원하고 있다.

• Solution : 하나의 인터페이스를 다른 인터페이스에 adapts 시키는 Adater object 를 사용한다.

  • Class adapter : multiple inheritance

  • Object adapter : single inheritance
    

    • Class name 폰트
      default	실체가 있다. complete 하다. (new 로 생성 가능)
      italic	실체가 없다. abstract/interface. (new 로 생성 불가능)

    • method 구성
      head	signature, interface
      body	implement

    • abstract 는 head 만 존재한다.

    • Dependency (A --> B)
      : Client(A), Target/Server(B). A 는 B 에 dependent 하다.

    • Inheritance (A -> B)
      : A(자식) 는 B(부모) 를 상속 받는다. & 자식은 부모에게 dependent 하다.

Framework

• 일반적인 library 와는 성격이 다른 class library 이다.

• integrated set of cooperating classes(클래스간의 협력)

• semi-complete application

• Domain-specific

• Inversion of control (제어의 역전현상)

  • Class Library Architecture
    : 작성된 main code 가 주도권(main control)을 지닌다.
  • Framework Architecture
    : 작성된 코드는 프레임워크에 의해, 어느 시점에 호출된다. (틀이 정해져 있고, 살만 붙이면 되기 때문에 생산성이 좋고 빠르다.)

• allow us to reuse design and code
  : Powerfule parameterization mechanism, 변화에 대응하는 것 (subclassing and dynamic binding)

📌 structed paradigm 보다 Object Oriented paradigm 이 가지는 장점

(1) 현실 객체와 소프트웨어 객체 간의 매핑이 쉽다.

• flexible 하고 reusable 한 시스템을 얻기 위해, actions 보다 objects 에 structure 기반을 두는 것이 좋다.

(2) 관계를 유지하며, 기능을 발전시키기 쉽다.

stepwise refinement

• complex 한 소프트웨어 시스템을 각자 independent 하게 decompose 하는 것은 필수적이다.
  

• Structured Decomposition
  

  • procedures/functions 으로 구성
  • Program = (Algorithms + Data Structures)
  • SA/SD/SP

• Object-Oriented Decomposition
  
  

  • objects 로 구성
  • Object = (Algorithms + Data Structures)
  • Program = (Object + Object + ... )
  • OOA/OOD/OOP

📌 Dealing with Changing Requirements

• 가장 큰 차이점은 Shift of Responsibility 이다 !

  • 만약 반장을 추가한다는 상황일 때
    • Structed : type check 추가, 코드 변경
    • O.O : A is a B 관계를 이용해 inheritance 표현 + 기능, 특성 추가