0. 객체지향개발론 개요

OO Approach(객체지향적 사고 접근법)

객체지향설계에서는 각 객체가 수행해야 할 책임이 명확하게 정의되어 있다.

 

OOA - 객체 지향 분석

OOD - 객체 지향 설계

OOP - 객체 지향 프로그래밍

 

성공적인 소프트웨어는 이해관계자(stakeholder)의 requirements를 충족시켜야 한다.

또, 시간과 예산(budget) 내에 개발되어야 하고, 변화에 대한 탄력성(resilient to change)을 가져야 한다.

 

software crisis는 컴퓨터의 발전과 계산 능력의 증가로 인해 소프트웨어의 복잡성, 요구사항, 오류가 증가하며 발생한 문제이다. 

 

development process는 누가-who 어떤 일을-what 언제-when 어떻게-how 특정 목표를 달성하는지를 정의한다.

 

software engineering은 제품을 구축하거나 기존 제품을 개선하는 것이다. 이 과정은 새로운/변경된 요구사항으로 시작해서 소프트웨어 개발 프로세스를 거쳐 새로운/변경된 시스템으로 이어진다.

 

소프트웨어 개발 프로세스 기본 작업 흐름

분석(Analysis): 도메인 분석, 소프트웨어의 기능적/비기능적 요구 사항 결정, 요구사항 수집.분석.명세 작성 등

설계(Design): 분석에서 도출된 요구사항을 기반으로 로직 설계. 시스템 아키텍처, 내부설계, 사용자 인터페이스 설계 등

구현(Implementation): 설계 단계에서 도출된 로직에 따라 코드 작성

테스팅(testing): 개발된 소프트웨어가 올바르게 작동하는지 테스트

 

 

waterfall 모델

Requirements Specification(Analysis) => Design => Implementation => Integration(통합) => Maintenance(유지보수) => Changed requirements(요구사항 변경) => 처음으로

 

문제점

- 긴 지연

- 높은 개발 비용

- 높은 취소율

- 낮은 품질(신뢰성-reliability, 확장성-extensibility, 유지관리성-maintainability 등)

- 높은 유지 관리 비용

 

- 요구 사항은 정확하지 않다. 프로젝트가 커질 수록 요구 사항 취소율은 상승한다.

- 요구 사항은 안정적이지 않다. 시장과 기술은 지속적으로 변화하고, 이해당사자(stakeholder)의 목표나 우선순위가 변경될 수 있다.

    이러한 요구사항이 변경되는 문제를 moving target problem이라 한다.

- design은 implementation 단계 전에 항상 완료될 순 없다. 

 

최근에는 waterfall 방식 대신 iterative lifecycle로 바꾸는 것을 추천한다.

 

Iterative and Incremental development proces는 변화를 포용한다.

Small steps, feedback, refinement(세부 조정), adaptation(적응)

Iterative(반복적), incremental(점진적) Time-boxed(시간제한) - evolutionary / spiral(나선형) 이라고도 함.

 

위 방법의 장점은 다음과 같다.

Early mitigation(조기 완화) of high risks.

Early visiable progress

Early feedback, user engagement(사용자 참여), adaptation(적응)

복잡성 관리 : 팀이 analysis paralysis(분석 마비) 또는 매우 긴 복잡한 단계로 인해 overwhelmed(압도)되지 않음.

 

 

위 그림은 The Unified Process라는 Interative Process이다.

Inception(개시): 프로세스의 목표와 범위를 정의, 기본 요구사항과 아키텍처 결정

Elaboration(상세화): 대부분의 요구사항을 발견 및 분석, 기본 아키텍처 설계

Construction(구축): 소프트웨어를 개발하고 테스트

Transition(전환): 소프트웨어를 배포 준비하고 사용자에게 전달

전체 프로세스는 반복적으로 수행되고, 각 반복은 여러 활동을 포함한다.

 

전략적으로 합리적인 시스템(Strategic rational system) 개발 계획은 시스템의 전체 비용에 기반하며, 단순히 개발 비용만을 고려하지 않는다.

평균적으로 비즈니스 규칙은 월 8%의 속도로 변경된다.

 

객체 기술(OT)의 진정한 힘과 장점은, 복잡한 시스템을 처리할 수 있는 능력과 쉽게 적응 가능한 시스템을 지원하여 변경의 비용과 시간을 줄일 수 있는 능력에 있다.

객체 기술을 채택하는데 있어 우선순위가 높은 이유 중 하나는 복잡성을 우아하게 처리, 쉽게 적응할 수 있는 시스템 생성할 수 있다.

그러나 객체 수준에서 재사용(reuse)은 대체로 달성되지 않거나 가치있지 않다.

중점을 둬야할 부분은 프레임워크를 생성하고 사용에 대한 문화와 아키텍처와 분석, 디자인 패턴의 재사용이다.

 

 

디자인패턴은 특정 문맥(certain context)에서 문제와 해결책을 설명(description)하는 것이다.

디자인패턴의 예시는 다음과 같다.

Name: Adapter

Also known as: Wrapper

Context: 클라이언트 객체가 공급자(Supplier) 객체의 메서드 호출

Problem: 클라이언트 객체는 공급자가 제공하는 것과 다른 인터페이스를 기대

Solution: 한 인터페이스를 다른 인터페이스에 적응시키는 어댑터 객체 사용

 

Solution alternatives:

Class adapter: C++나 Eiffel처럼 다중 상속에 의존하거나, Java처럼 인터페이스에 의존한다.

Object adapter: 단일 상속과 위임(delegation)에 의존한다.

 

Object adapter solution

Client: 요청을 시작하는 객체

Target: Client가 호출하려는 메서드를 포함하는 인터페이스

Adapter: Target 인터페이스와 Supplier 인터페이스 사이를 중재. 

Supplier: 특정한 요청을 처리하는 메서드를 포함

 

 

프레임워크는 클래스 라이브러리와 유사하지만, 일반 툴킷보다 더 많은 것을 제공한다.

An integrated set of cooperating classes(통합된 협력 클래스 세트)

- semi-complete application : 프레임워크 내의 추상적인 클래스들이 애플리케이션 내에서 특수화되어 사용된다.

 

Inversion of control(제어 역전 현상) : 프레임워크가 우리가 작성한 코드를 불러옴

- main event loop: 메인 이벤트 루프는 애플리케이션이 아닌 프레임워크 내부에 위치한다. 이는 프레임워크가 이벤트의 처리와 반응을 주도하고 애플리케이션은 필요한 로직 및 기능에 집중할 수 있게 한다.

- dynamic binding: 동적바인딩을 통해 애플리케이션 내의 코드를 호출ㄹ할 수 있다. 추상클래스나 인터페이스를 통해 정의된 메서드가 애플리케이션 내에서 실제로 구현될 때 실행된다.

 

 

Hollywood principle 원칙(나를 부르지말고, 내가 너를 부르겠다.)에 따르면, 클래스 라이브러리 아키텍처와 프레임워크 아키텍처는 다음과 같다.

클래스 라이브러리의 구성요소는 특정 기능(수학 연산 등)을 수행하고 특정 기능을 처리하기 위해 여러 구성 요소를 함께 사용한다.

프레임워크 아키텍처는 클래스 라이브러리를 기반으로 하되, 특정 애플리케이션 또는 문제 도메인에 특화된 기능과 제어의 역전 원칙을 적용하여 애플리케이션 개발을 보다 간소화한다. 이 아키텍처는 주요 이벤트 루프와 콜백 매커니즘을 포함한다.

 

프레임워크의 이점은 다음과 같다.

1. 디자인 및 코드 재사용

2. 빠른 애플리케이션 개발

3. 강력한 매개변수화(parameterization) 매커니즘

 

프레임워크의 예시는 다음과 같다.

MVC : Smalltalk GUI를 위해 만들어짐.

MacAPP : mac application을 위해 만들어짐. 상업적으로 성공한 첫번째 프레임워크임.

MFC : window application 위한 C++ 라이브러리

Choices Operating system framework : 운영체제의 구조와 디자인을 위한 -

Unidraw Graphical editors - 그래픽 에디터를 위한 -

Android : 스마트폰과 태블릿 애플리케이션을 위한 -

 

유연하고 재사용 가능한 시스템을 얻으려면 작업(action)보다는 개체(object)에 소프트웨어 구조를 기반으로 하는 것이 좋다.

일반적으로 데이터 객체, 인터페이스 및 구성 요소 간의 관계는 시간이 지나도 상대적으로 안정적이기에 대규모 시스템 및 자주 변경되는 시스템에 객체지향방식을 사용하는 것이 좋다.

 

복잡한 소프트웨어 시스템을 점점 더 작은 부분으로 분해하는 것이 중요하고, 각 부분은 독립적으로 개선될 수 있다.

객체지향에선 객체 단위로 Divide and Conquer을 수행한다.

 

구조적 패러다임(Structured Paradigm)은 프로시저나 함수를 기반으로 시스템을 구성한다. 함수는 데이터에 직접 액세스하고 조작한다.

 

객체 지향 패러다임(Object-Oriented Paradigm)은 객체를 중심으로 시스템을 구성한다. 객체는 데이터와 그 데이터를 조작하는 방법을 모두 포함한다. 외부에서 메인 객체의 데이터에 접근하기 위해 메서드에 액세스하려면 메시지를 보내야 한다.

 

 

구조적 분해(Structed Decomposition)

- 시스템을 프로시저나 함수를 중심으로 구성

- 프로그램은 Algorithm(logic, ..) + Data Structure 조합으로 구성

- SA/SD/SP와 같은 구조적 방법론에 따라 개발됨

 

객체 지향 분해(Object-Oriented Decomposition)

- 시스템을 객체 중심으로 구성

- 객체는 Algorithm(method, action..)과 Data Structre 조합으로 구성

- OOA/OOD/OOP와 같은 객체 지향 방법론에 따라 개발됨

 

 

서브프로그램을 기반으로 한 디자인 구조를 만들 수 있다.

Global data는 여러 Subprograms 간에 공유된다. 이 구조에서 각 Subprograms는 Global data에 액세스하며, 이러한 데이터 액세스는 Subprograms간의 결합도를 높일 수 있다.

 

소규모 다이어그램에서는 내부에 쌓여있는 레이어들을 포함한 사각형으로 여러 객체들을 볼 수 있다.

이 쌓인 레이어들은 각 객체 내의 데이터와 메서드의 캡슐화를 상징한다.

객체들 사이에는 화살표로 연결되어 있어, 객체 간의 상호작용 및 종속성을 나타낸다.이는 객체간의 메시지 전달, 메서드 호출, 데이터 교환을 나타낸다.

 

대규모 다이어그램은 여러 연결된 객체들로 구성된 더 복잡한 시스템을 보여준다.

이 객체들은 서브시스템이라는 점선 사각형 내에 그룹화돼있다. 이는 여러 객체들이 더 큰 기능적 모듈의 일부로 함께 작동한다는 것을 의미한다.

소규모 설계에서 볼 수 있는 것과 유사한 객체 구조를 포함하지만, 서브시스템 아래에서 그룹화하여 모듈성과 확장성을 강조한다.

객체간의 상호작용과 종속성은 개별 서브시스템을 넘어서 확장되고, 시스템의 다른 부분들이 서로 어떻게 통신하는지 보여준다.