03. Object-Oriented Development

OOP/OOAD/UML에 대해 알아보자

Posted Mar 8, 2025

CKA

21 min read

03. Object-Oriented Development

1.3 Object-Oriented Development

1.3.1 Software Development

Software Development는 컴퓨터에서 동작하는 스프트웨어로 푸는 것을 말함
실제 환경의 문제를 정의 후 컴퓨터 언어로 바꾸고 동작가능한 프로그램으로 구현하는 것까지를 Software Development라고 말한다
- 실제 환경의 문제 정의(Oral로 설명) 후, => 1단계(현실세계 문제 관찰),
- 이를 Programming Language로 Solution을 작성하며 객체지향/절차지향 2가지 방법이 있음 => 2단계(Solutions in computer),
- Computer System에서 동작가능한 프로그램으로 작성
- + Programming Language에선 절차지향(C언어)/객체지향(C++) 2가지가 존재하고, 이에 따라 SASD(Structured Analysis & Structured Design, 구조적 분석 설계 방법론), OOAD(Objected Oriented Analysis & Design, 객체지향 분석 방법론) 방법론으로 나눠진다

	절차지향	객체지향
특징	1. 절차지향적, 프로그램을 여러 절차 or 함수로 작성하여, 데이터는 함수간 전달 2.모듈화, 프로그램을 여러 함수로 분리하여 코드 재사용성 높임 3. Direct Memory Access 가능 4. 빠르고 효율적임(하드웨어에 매우 가까운 저수준 언어로 높은 성능을 제공)	1. 객체지향적, 데이터와 함수를 하나의 단위인 객체로 묶고 이를 클래스를 통해 인스턴스화 하여 사용함 2. 캡슐화, 객체의 데이터와 그 데이터를 처리하는 메서드를 묶음. 3. 상속, 기존 클래스를 기반으로 새로운 클래스를 생성할수 있어 코드 재사용성이 높음. 4. 다형성, 같은 이름의 메서드를 여러 클래스에서 다르게 구현할수 있음
장점	1.단순함, 절차지향적이라 논리적 흐림 파악이 쉬움 2.고성능, 저수준 언어라 속도가 빠름. 3. 메모리 사용량이 적음	1. 유지보수가 용이함. 2.확장성이 좋음, 클래스 기반으로 나눠져 있어 최소한의 코드 수정이 가능 3.재사용성이 높음, 클래스와 객체를 기반으로 작성되어 있기때문임 4.추상화와 다형성, 코드의 유연성이 증가하여, 다양한 상황에 맞춰 다르게 동작할수 있음
단점	1.유지보수가 어려움, 코드가 복잡해지면 함수안의 의존성이 커지고 유지보수가 어려워짐. 2. 확장성이 부족함, 프로그램 구조가 커지면 기능 추가가 복잡해지고 구조적 한계에 부딪히기 쉬움. 3. 재사용성 부족, 객체지향 방식에 비해 코드 재사용성이 떨어짐	1. 복잡성이 증가함(상송/다형성/Composition등 개념이해 필요) 2.메모리와 성능 비용이 증가, 객체 지향특성으로 인해 클래스 인스턴스를 생성하고 관리하는데 자원이 소모됨. 3. 초기 학습 곡선(진입장벽이 있음)

1.3.2 Procedural Programming (SASD)

절차 지향적으로 구성된 프로그램을 말하며, 객체지향이랑 다르게 절차(Procedure)가 가장 중요
Procedure = Statement (변수값)을 변경하는 Function
variables values의 상태를 statements로 값 변경하는 Function 단위 포커싱이 절차지향 프로그래밍이다
- 절차상 어떤 배치 순서(callback, for, 조건문 등)로 values를 셋팅하는지가 중요함
values값 조작으로 문제를 풀기 위해 알고리즘, 자료구조가 중요함!
format과 타이밍만 맞으면 어디서든 자료구조를 가져다 쓸수 있수 있는 단점이 있음(객체 지향은 encapsulation을 통해 information hiding을 수행함으로 message passing을 통해 바인딩된 특정 객체만 데이터 접근이 가능함)

구조적 분석 설계 방법론은 50-60년도에 부터 사용된 전통적인 개발 방법론임
전체의 입력-출력을 다 찾아 낸 후 한번에 다 개발하는 것이 어려우니 top-down 형식으로 입출력을 쪼개가면서 개발을 수행함( Divide and Conquer)
DFD(Data Flow Diagram) 방식을 사용(프로시져를 통해 데이터를 인풋-아웃풋으로 주는 형태임으로 DFD가 보이기 좋음)
싸이클 방식의 task 처리하고 나가고 방식을 처리하다 보니 Data flow 방식을 그림
- 데이터가 들어와서 프로세승을 해서 넘겨주고, 이후 저장하는 방식이라 데이터가 흘러들어와 나가는데 포커싱을 둔 것을 위 그림에서 확인할수 있으며 이런 형태의 그림이 Level3의 DFD이다
- 실선 - data node / 점선 - control 노드로 표현함

입출력(I/O) 관계를 유지하면서 top-down 형식으로 데이터 처리를 어떻게 해나갈지 정리를 함
- SA(Structured Analysis) : 데이터를 읽어서 그다음에 나가는 형식을 표현하여 DFD를 그려 데이터 흐름 파악에 포커싱
- SD(Structured Design) : 실질적인 데이터 읽기/출력은 해당 function을 call하하여 읽고 Actuator를 두어 출력할수 있도록 해야함. 따라서 SD 단계에서는 Structed Chart로 이러한 과정을 보다 디테일 하게 작성하여 구현할수 있도록 함. ex. 어느 데이터 흐름을 만들기 위해 어떤 Actuator를 콜하는지에 대한 관계를 Structed Chart 로 확인

정리

SA : Structured Flow을 그려서 데이터가 어떻게 들어오고 나가는지 입출력 관계를 보임
SD : Structured Chart을 통해 구현 단계까지 고려하여 실질적으로 어떻게 데이터를 읽고 출력하는지 보여주어야함

1.3.3 Object-Oriented Programming

C++/Java/Ada(인공위성/항공쪽에서 많이 쓰이는 안정한 프로그래밍 Language)와 같은 프로그래밍 언어가 객체 지향 프로그래밍 언어이며,
절차지향헤언 절차(Function)이 중심이 되었던 것 처럼 객체지향에선 객체가 중심이 됨
- 객체에 state/behavior(data/operation)을 두어 구성을 하고,
- object colaboration을 통해 객체간 데이터 조작을 할수 있도록 operation을 제공해야함(object들 끼리 효과적으로 Communicaion을 수행하여 시스템에서 제공해야할 기능을 효과적으로 제공해야함)
- OOAD에선 데이터가 흘러들어와서 어떻게 나가는지 관계가 표시가 되지 않음
- Object(객체)가 특정 시나리오에서 목표 달성을 위해,
- 어떻게 message passing/object colaboration을 통해 시스템이 어떠한 서비스를 제공하는지 Sequence Diagram에 포커싱을 맞춘다

OOA - 우리가 어떤 object/class를 사용할지 object identification을 수행
- 해당 시스템에서 어떠한 concepts/obejct들을 가질지를 찾아내야어 class로 만들며,
- 해당 클래스를 통해 요구사항을 만족할지 분석함
OOD - 오브젝을 더 정확하게 정의해야하며(Attribute/operation), 각 object들 간에 어떠한 관계와 역할을 가질지 디자인해야함
- 관계의 디자인은 Class Diagram을 통해서 해당 관계들을 보여줌
  - class diagram - object들 간에 어떻게 커뮤니케이션을 보여주며,
- object간의 관계(5가지) - dependency, association, aggregation, composition, inheritance link -+ multiplicity, relationships(one-to-one one-to-many many-to-many), role

정리

OOA : Domain Model을 만들어서 Domain 레벨에서 Object/Class/Concepts를 찾고, UseCase Model을 만들어서 Requirement를 정리하는 것이다 -> 유즈케이스들을 보면서 클래스를 발굴!!!!
OOD : Class Diagram을 통해서 오브젝트를 정의함(Static model을 만들기), 만들어낸 Object들이 어떻게 Communication하는지 dynamic model인 Sequence Diagram을 만든다 => 클래스 정의 후 클래스 다이어그램을 보여줌(ststic model을 보인 후 dynamic mdoel을 보이는거임!!)

주사위 돌리는 게임을 OOAD를 통해 분석 및 디자인 해보는 예시임
앞서 말한 듯 OOA/OOD 단계는 아래와 같음
- OOA : Define Use Caces/Domain Model
- OOD : Class Diagram 정의 / Interaction Diagram을 정의
  - Interaction Diagrams (UML에서 사용하는 용어이며 4가지 Diagram을 통칭해서 말함) : Sequence / Communication / Timing / Interaction Overview
FR(Functional Requirement)가 곧 usecase라고 생각하면 되고, 도메인 모델을 만들어서 object/class를 찾아냄(플레이어/주사위게임/주사위 class가 있고 플레이어-주사위는 1:1 관계이나 주사위게임/주사위 또는 플레이어/주사위는 1:2 관계임을 볼수가 있음)
Obecjt Diagram이 어떻게 동작하는지 보여줌.(도메인 모델에서 정의된 class를 가져오는 거임)

Software Process model에는 2가지 모델이 있음
- waterfall - OOA단계를 다 끝내고 그다음에 OOD를 진행하는 방식
- Iterative - OOA 단계를 다 끝내지 않고 해당 iteration에 진행할 item만 찾아내서 OOD를 진행하고, 다음 iteration에서는 이 과정을 반복하면서 시스템을 완성해 나가는것

1.3.4 Waterfall Model

위 OOAD를 순차적으로 한단계씩 끝나면서 넘어가고 OOI까지 수행하는 것을 말함
폭포가 순차적으로 위에서 아래로 떨어지는 것처럼 Analiysis -> Design .. 단계를 다 끝내고 순차적으로 나가야된다
위 방식의 단점은 Requirement가 Fix 되기가 쉽지 않아서 꼭 Fix를 하고 진행해 나가야함
- 개발단계가 10개월이면 10월 마지막 달은 되어야 동작하는 코드가 나옴
  - why? OOA/OOD 단계를 9개월간 진행해야함으로…ㅎㅎㅎ

1.3.5 Iterative Model (Agile)

OOA/OOD를 작은 iteration 단위로 수행하는 모델
- Iteration 단위는 Incremental/Evolutionary 단계가 있음
- Incremental : 요구사항을 A-Z까지 다 파악하여 개발 수행
- Evolutionary : 요구사항을 한번에 다 파악하기 힘드니 파악할수 있는것 만큼 파악하고 추후 나오는 요구사항들을 다시 들고와서 업데이트 하는 방식
- 요구사항을 작은 단위로 매번 수집 -> 분석/디자인 -> 태스팅/검증 -> 평가를 작은 iteration으로 쪼개서 반복적으로 진행하는 것을 말함
Waterfall model 분석 단점을 보완하기 위해 나온 모델임
- waterfall의 경우 마지막 달은 되어야 개발된 프로세스 확인이 가능한데, 다큐먼트 없이 식속하게 고치면서 이용하는 사람과 같이 긴밀하게 협업하여 시스템 완성도를 놓이는 방식
- 문서 작업이 없이 개발을 진행하다 보니까 요구사항서 설계가 필요하면 Iteration Model 방식은 적절치 않음
Agigle Manifesto(애자일 선언서)을 보면,
- 불필요한 문서 작업은 없이 사용자(Customer)랑 긴밀한 관계를 맺으면서 민첩하게 완성도를 높이는 방식임을 확인 가능함

1.3.6 Rational Unnified Programming(RUP/UP)

모든 방식을 다 합친 RUP가 나옴
- Ratioanl 회사를 HBM에서 인수해서 만든 방식이며 RUP라는 프로그램도 있었음
- 간단히 UP라고도 함
- Iterative하지만 Evalutional/Incremental 하게 요구사항을 A-Z 쌓아가나 추후에 발굴되는것들도 다 쌓아서 수집
  - Iteration(요구사항수집)을 무조껀 3주로 짤라서 진행 : 할 분량만큼만 조절하여 분석/디자인을 진행
  - Risk-driven하게 진행됨
    - Risk = Architecture/Clinet 위험요소가 있음
      - Architecture Risk의 경우 100가지 요구사항을 3주씩 10개씩 끊어서 가고 있는데 마지막 주차에 현재까지 구현한 구조로 절대 만족못하는 요구사항이 나와버리면 기존 개발까지 다 엎어쳐야하는 문제가 나올수 있음.
        
        따라서 해당 단계를 Requirement workshop 단계에서 찾아서 초기에 개발작업을 진행해야함
      - Client Risk - 고객의 요구사항에 특별히 중요한 것들이 있음. 해당 기능들도 매 Requirement worshop에서 찾아서 구현을 해야함
Elavoration Phase : 구조적/고객의 요구사항의 위험이 있는 것을 매 3주마다 개발 cycle을 돌려서 프로토 타임을 만들어 내는 단계(위 그림에서 칸 하나당 3주이며, 아키텍쳐 후보군을 3주마다 쌓아가면서 risk를 줄일수 있는 구조를 찾아내야함. mini waterfall을 3주마다 수행하며 Requirement Workshop을 수행하여 아키텍쳐/클라이언트 상에서 올 수 있는 위험 요소들을 제거하기 위해 노력) => 이렇게 할수 있는 이유는 전체 기능중의 10%로만 가져와서 구조상 문제가 될수 있는지 없는 지를 짧게 끊어가며 아키텍쳐/클라이언트들한테 확인 작업을 받아냄
Construction Phase : 구조상 나올수 있는 문제를 최소화한 구조로 개발을 수행하여 전체 요구사항 나머지 90%를 여기서 채워나감
앞으로의 수업에선 UP 기반의 내용을 다룰 예정이며 Chapter3에서 다룰 것이다.
파트3에서 UP 내용에 대해 배울것이며, 현재 OO software 개발 방법론의 표준급이며 UML을 알아야 UP의 방법론에 대해 이해할수 있어 UML도 배울 예정임(notaion이 다 UML로 작성됨)

Answer) 일반적으로는 다 맞는 말이지만, 굳이 하나 고르자면 1번(소프트웨어 개발 방법론은 UP를 말하긴함) Answer) 3 (리스트 드라이븐이라고 해서 아키텍쳐/클라이언트 요구사항을 매번 3주마다 다 받아가면서 서로 다 risky하게 개발을 수행.[후반으로 갈수록 까다로운 요구사항이 들어올 경우 이전에 셋업한 아키텍쳐적인 관점을 싹다 뒤엎어야할수도 있어 매우 risky 함])

4단계[Inception / Eleboration / Consturction / Transition] 단계가 있으며 Eleboration 을 미니 워터폴로 OOA/OOD/OOI를 수행함

핵심 정리

소프트웨어 개발 방법론이 절차지향/객체지향에 따라 2가지 (SASD / OOAD)가 있으며, 설계단계에 OOA/OOD를 활용하여 한 스텝으로 다 가져가면 waterfall, 끊어 빙글 빙글 돌리면 Iterative 이다.

OOA : UseCase를 찾고 Object Define(Domain Model) OOD : Static Model(Class Diagram 정의), Dynamic Model(Sequence Diagram 정의)

Iterative 방식에 Standard가 UP이며 notaion은 UML을 사용함으로 이에 대해 배울 예정이다

OOP_OOAD_UML

This post is licensed under CC BY 4.0 by the author.