반응형
소프트웨어 개발 방법론 (SW 개발 방법론)
소프트웨어를 개발한다는 것은 단순히 코드를 작성하는 것이 아니라, 컴퓨터에서 동작하는 프로그램을 통해 실제 문제를 해결하는 일이다. 이를 위해 다양한 소프트웨어 개발 방법론이 존재하며, 문제의 성격과 규모에 따라 적절한 방법론을 선택하는 것이 중요하다.
절차적 프로그래밍 (Procedural Programming)
절차적 프로그래밍은 전통적인 프로그래밍 패러다임 중 하나로, 프로그램을 일련의 절차(또는 순서)에 따라 구성하는 방식이다. 주요 특징은 다음과 같다:
- **프로그램의 기본 구성 요소는 절차(Procedure) 혹은 함수(Function)**이다.
- 자료구조, 알고리즘, 그리고 순차적인 흐름에 중점을 둔다.
- 프로그램은 위에서 아래로 차례대로 실행되며, 각 절차는 특정 작업을 수행한다.
이러한 절차적 방식은 이해하기 쉽고, 구조화된 논리적 흐름을 구성하는 데 적합하다.
절차적 프로그래밍을 위한 SASD
SASD는 Structural Analysis and Structured Design의 약자로, 우리말로는 "구조적 분석 및 구조적 설계"라 한다. 이는 절차적 프로그래밍에 기반한 전통적인 소프트웨어 개발 방법론으로, 다음과 같은 특징이 있다
- 복잡한 문제를 작고 단순한 단위로 분해(분할정복)하여 해결한다.
- 기능 중심적 접근 방식을 사용하며, 전체 시스템을 기능의 흐름으로 바라본다.
- DFD(Data Flow Diagram)를 활용하여 시스템 내의 데이터 흐름과 처리 과정을 시각적으로 표현한다.
- 시스템의 기능적 관점에서 분석 및 설계가 이루어지며, 특히 실시간 제어나 내장형 시스템에 적합하다.
예시로는 RVC 제어가 있다.
RVC(Robot Vacuum Cleaner, 로봇청소기)의 제어 소프트웨어는 SASD 기반의 절차적 프로그래밍 접근이 잘 드러나는 사례이다.
- RVC 제어 소프트웨어는 로봇청소기 내부에 내장되어 있으며, 청소기의 작동 전반을 통제한다.
- 사용자가 직접 조작하지 않아도, 제어 소프트웨어가 센서와 알고리즘을 활용해 자율적으로 동작하도록 한다.
- 이러한 시스템은 미리 정의된 절차에 따라 동작하므로, 절차적 프로그래밍과 구조적 설계 방법론의 전형적인 활용 사례라고 볼 수 있다.
http://dslab.konkuk.ac.kr/class/2020/20SE/Projects/A/SRS/[T4][%EA%B9%80%EC%84%B8%EC%98%81]SRS.pdf
객체지향 프로그래밍 (Object-Oriented Programming, OOP)
객체지향 프로그래밍은 프로그램을 "객체(Object)"들의 모임으로 구성하고, 객체 간의 메시지(통신)를 통해 시스템의 기능을 수행하는 방식이다. 현실 세계의 사물과 그 관계를 모델링하기에 적합하며, 코드의 재사용성, 확장성, 유지보수성을 크게 향상시킬 수 있다.
객체(Object)란?
- 데이터(Data, 속성)와 그 데이터를 처리하는 연산(Operation, 메서드)의 집합
- 객체는 고유한 상태(state)를 가지며, 외부와의 메시지 교환(함수 호출)을 통해 상호작용한다.
객체 간 통신
- 한 객체는 다른 객체의 메서드(연산)를 호출함으로써 기능을 수행한다.
- 객체들 사이의 데이터 흐름은 직접적으로 보이지 않고, 통신의 순서와 흐름만이 강조된다.
- 따라서 전체 시스템은 객체들 간의 관계와 상호작용을 중심으로 설계된다.
객체지향 분석 및 설계 (Object-Oriented Analysis and Design, OOAD)
OOAD는 객체지향 개념을 바탕으로 시스템을 분석하고 설계하는 소프트웨어 개발 방법론이다.
OOA (Object-Oriented Analysis)
- 도메인 모델(Domain Model)을 중심으로 분석
- 시스템에 필요한 개체, 그들의 속성, 관계를 추출
- 현실 세계의 구조를 반영하여 문제를 명확히 이해하는 데 중점
OOD (Object-Oriented Design)
OOA 결과를 바탕으로 구체적인 소프트웨어 구조를 설계한다. 주요 모델은 다음과 같다
정적 모델 (Static Model)
- 대표적으로 클래스 다이어그램(Class Diagram)을 사용
- 클래스 간의 관계(상속, 연관, 집합 등)를 표현
- 동적 모델 (Dynamic Model):
- 시퀀스 다이어그램(Sequence Diagram) 등을 통해 객체 간 메시지 교환의 흐름을 시각화
- 시간 순서에 따라 어떤 객체가 어떤 메서드를 호출하는지를 나타냄
| 절차적 프로그래밍 | 객체지향 프로그래 | |
| 중심 개념 | 절차(순차적 흐름) | 객체와 메시지 교환 |
| 단위 구성 | 함수, 알고리즘 | 객체(속성과 메서드 포함) |
| 설계 도구 | DFD 등 기능 중심 도구 | 클래스 다이어그램, 시퀀스 다이어그램 등 |
| 예시 | RVC 제어 소프트웨어 | Dice Game |
OOAD예시로는 Dice Game이 있음
- 플레이어가 주사위를 굴려 점수를 얻고, 점수가 높은 사람이 이기는 간단한 게임
- 주요 객체: Player, Dice, Game
- Player는 Dice의 roll() 메서드를 호출해 점수를 얻음
- Game은 플레이어들의 점수를 비교해 승자를 판단
시스템 모델링 (System Modeling)
시스템 모델링은 시스템을 추상화하여 시각적으로 표현하는 과정으로, 다양한 **관점(Viewpoint)**에서 시스템을 이해하고 설명할 수 있게 해준다.
- 시스템의 구조, 동작, 상호작용 등을 시각화
- 분석가와 고객 간 소통, 그리고 설계자 간 협업에 핵심적인 도구
- **UML (Unified Modeling Language)**과 같은 표준 그래픽 표기법을 사용
시스템 모델링의 목적
- 분석가가 시스템을 명확히 이해하고 고객 및 이해관계자와 효과적으로 소통할 수 있도록 지원
- 시스템의 구조와 기능을 시각화하여 설계 및 구현의 기초 제공
- 요구 사항을 식별, 명세, 검토하는 데 활용
기존 시스템 모델 vs 새로운 시스템 모델
| 목적 | 관점 | 활용 | |
| 기존 시스템 모델 | 현재 시스템이 무엇을 어떻게 수행하는지 명확히 함 | 요구 사항 분석 초기 | - 시스템 강점/약점 파악 - 새로운 시스템 요구 도출 |
| 새로운 시스템 모델 | 제안된 시스템의 구조와 동작을 설명 | 요구 사항 정의 및 설계 단계 | - 이해관계자에게 설명 - 설계 제안, 구현 문서화에 활용 |
시스템 모델의 활용: 모델 기반 엔지니어링(Model-Based Engineering)
- 시스템 모델은 전체 또는 부분 시스템의 구현을 자동 생성할 수 있는 기반으로 사용됨
- 설계의 일관성 확보, 오류 감소, 반복 가능한 개발 프로세스에 유리
시스템 관점 (Viewpoints)
시스템은 다양한 관점에서 모델링될 수 있으며, 각 관점은 특정 목적을 가진다:
| 외부 관점 | 시스템이 외부 환경과 어떤 관계를 맺고 있는지를 모델링 (ex. 시스템 경계, 입력/출력) |
| 상호작용 관점 | 시스템 구성 요소 간 또는 시스템과 환경 간의 상호작용 흐름을 모델링 |
| 구조적 관점 | 시스템의 내부 구성요소 또는 데이터 구조를 모델링 |
| 행동적 관점 | 시스템이 시간의 흐름에 따라 어떻게 동작하고 이벤트에 어떻게 반응하는지를 모델링 |
UML 다이어그램 종류 및 사용 목적
| 활동 다이어그램 (Activity Diagram) | 작업 흐름이나 프로세스의 활동 단계를 표현 |
| 사용 사례 다이어그램 (Use Case Diagram) | 시스템과 사용자(또는 외부 시스템) 간의 기능적 상호작용 모델링 |
| 시퀀스 다이어그램 (Sequence Diagram) | 시간 순서에 따라 객체 또는 액터 간의 메시지 흐름 표현 |
| 클래스 다이어그램 (Class Diagram) | 객체 지향 시스템의 클래스와 그들 간의 관계 표현 |
| 상태 다이어그램 (State Diagram) | 객체나 시스템이 이벤트에 반응하여 상태가 어떻게 변하는지를 표현 |
그래픽 모델의 활용 목적
- 모델은 토론을 자극하고 초점을 맞추는 도구
- 개발자, 설계자, 고객 간 논의 촉진
- 완전하지 않아도 괜찮지만, 논리적 일관성과 전달력은 중요
- 모델은 시스템의 핵심 개념을 명확히 표현할 수 있어야 함
모델의 정확성과 완전성 기준
| 완전성 | 정확성 | |
| 기존 시스템 문서화 | 완전하지 않아도 됨 | 반드시 정확해야 함 |
| 시스템 구현 기반 | 완전하고 정밀해야 함 | 반드시 정확해야 함 |
시스템 모델링의 세부 유형
시스템 모델링에서는 시스템이 외부 환경과 어떻게 관계를 맺고, 어떻게 동작하며, 어떤 방식으로 활용되는지를 시각적으로 표현한다. 대표적인 모델 유형은 아래,.,,
1. Context Models (컨텍스트 모델)
- 시스템의 운영 환경(컨텍스트)을 시각화하는 모델
- **외부적 관점(View)**에서 시스템을 바라보며, 시스템의 경계(Boundary) 외부에 무엇이 존재하고 연결되는지를 보여준다.
- 시스템이 어떤 외부 시스템, 사용자, 장비 등과 데이터를 주고받는지를 표현
주요 특징
- 시스템이 어떻게 동작하는지는 다루지 않음
- 무엇이 시스템 외부에 있는지, 시스템 경계 밖과 어떤 상호작용을 하는지를 보여줌
- 분석 초기 단계에서 유용하며, 요구사항 도출에 도움을 줌
2. Architecture Models (아키텍처 모델)
- 시스템의 고수준 구조를 보여주는 모델
- 시스템이 다른 시스템이나 하위 시스템들과 어떻게 연결되고 구성되는지를 시각화함
주요 특징
- 시스템 구성요소 간 구조적 관계에 초점
- 시스템 전체의 분해 구조, 모듈 간 연결, 외부 시스템과의 연동 구조 등을 표현
- 개발자 간 설계 논의와 기술적 결정에 유용
3. Process Models (프로세스 모델)
- 시스템이 비즈니스 프로세스 내에서 어떻게 사용되는지를 설명
- 사용자의 행위, 시스템의 반응, 업무 흐름 등을 순차적으로 표현
주요 특징
- 컨텍스트 모델이 "무엇이 연결되어 있는가"에 초점을 둔다면,
**프로세스 모델은 "어떻게 사용되는가"**에 중점을 둔다 - 시스템이 업무 절차나 작업 흐름 속에서 어떤 역할을 수행하는지 시각화
UML Activity Diagram
- 프로세스 모델링에 대표적으로 사용됨
- 비즈니스 로직이나 작업 흐름을 순서대로 표현
- 조건 분기, 반복, 병렬 흐름 등도 표현 가능
비교
| 모델 | 설명 | 중점 | 사용도구 |
| Context Model | 시스템의 외부 환경과의 관계 표현 | 외부 요소와의 연결, 시스템 경계 | UML Use Case, DFD 등 |
| Architecture Model | 시스템 내부 구조 및 외부 시스템과의 연결 | 시스템 구성 요소 간 관계 | 컴포넌트 다이어그램 등 |
| Process Model | 시스템이 실제 업무 흐름에서 어떻게 사용되는지 표현 | 순서, 흐름, 절차 | UML Activity Diagram |
Interaction Models (상호작용 모델)
시스템의 구성요소나 사용자 간의 상호작용을 모델링하는 방식. 시스템 요구사항을 이해하고, 성능과 통신 이슈를 파악하는 데 중요하다.
상호작용 모델의 세 가지 관점
관점설명목적
| 사용자 상호작용 모델링 | 시스템과 사용자의 인터랙션을 모델링 | 사용자 요구사항 도출에 도움 |
| 시스템-시스템 상호작용 | 시스템 간의 데이터 교환, 통신 흐름 표현 | 통신 지연, 오류 등 문제 예측 |
| 컴포넌트 간 상호작용 | 내부 구성요소들 간의 메시지 흐름 모델링 | 시스템 구조가 성능/의존성 요구를 충족하는지 분석 |
사용되는 UML 도구
- Use-Case Diagram: 사용자와 시스템 간의 기능적 요구 표현
- Sequence Diagram: 특정 유스케이스 내에서 시간 순서에 따른 객체 간 상호작용을 표현
Sequence Diagrams (시퀀스 다이어그램)
- 특정 Use Case 시나리오의 상호작용 흐름을 시각적으로 표현
- 상단에 Actor와 Object를 나열
- 수직 점선(Lifeline)을 기준으로 시간의 흐름을 표현
- 화살표(Message)로 객체 간의 호출이나 응답을 나타냄
주요 목적:
- 시스템의 동적 동작 이해
- 컴포넌트 간 메시지 흐름 분석 및 검증
Structural Models (구조 모델)
시스템을 구성하는 요소들과 그들 간의 관계를 중심으로 시스템의 조직 구조를 표현하는 모델
구조 모델의 유형
모델설명사용 UML
| 정적 모델 | 시스템 설계 시의 구조적 측면 표현 | UML Class Diagram |
| 동적 모델 | 시스템 실행 중 구성 요소의 동작 표현 | UML Object Diagram, Component Diagram, Composite Structure Diagram |
구조 모델은 시스템 아키텍처 설계 단계에서 작성되며, 시스템의 정확한 구성과 의존 관계 파악에 필수적임
Class Diagrams (클래스 다이어그램)
- 시스템을 구성하는 클래스와 그 관계(Association)를 표현
- 각 클래스는 객체의 청사진으로서, 속성(attribute)과 기능(operation)을 포함
- 클래스 간 관계는 연관(Association), 일반화(Generalization), 집합(Aggregation) 등으로 표현
Generalization (일반화)
- 공통된 속성이나 기능을 상위 클래스에 추출하여, 하위 클래스가 이를 상속받는 구조
- 객체지향 언어에서 inheritance(상속)으로 구현됨
- 하위 클래스는 상위 클래스의 특성을 물려받고, 자신만의 특성(속성/메서드)를 추가할 수 있음
- 복잡성 관리에 효과적이며, 코드 재사용성 향상
Aggregation (집합)
- 여러 클래스가 모여 하나의 큰 클래스를 구성하는 관계
- 부분(Part)과 전체(Whole)의 관계
예: 부서는 여러 직원을 포함함
일반화가 "is-a" 관계, 집합은 "has-a" 관계
| 모델 | 목적 | 주요 UML 도구 |
| Interaction Models | 시스템 간/사용자 간 상호작용 표현 | Use Case Diagram, Sequence Diagram |
| Structural Models | 시스템 구성 요소와 관계 표현 | Class Diagram, Object Diagram 등 |
| Sequence Diagram | 시간 순서에 따른 메시지 흐름 표현 | Actor/Object 간 상호작용 표시 |
| Class Diagram | 시스템 구조 및 클래스 간 관계 표현 | 속성, 연산, 관계 표현 |
| Generalization | 상속을 통한 구조화 | 공통 요소 추상화 |
| Aggregation | 파트-전체 관계 표현 | 복합 객체 구성 |
Behavioral Models (행동 모델)
행동 모델은 시스템이 실행 중에 어떻게 동작하는지를 시각화하는 모델로, 시스템이 외부 자극(이벤트, 데이터 등)에 어떻게 반응하는지를 표현한다.
- 정적인 구조가 아닌, 동적인 동작과 변화를 다룸
- 시스템의 반응성, 처리 흐름, 상태 변화 등을 파악할 수 있음
시스템의 동작 자극 요소
| 유형 | 설명 |
| Data (데이터) | 외부에서 데이터가 도착하면, 시스템은 해당 데이터를 받아들여 처리 |
| Event (이벤트) | 외부 또는 내부 이벤트가 발생하면, 시스템은 해당 이벤트에 반응해 동작 |
- 이벤트에는 데이터가 포함될 수도 있음
Behavioral Model 유형
1. Data-driven Models (데이터 중심 모델)
- 시스템의 데이터 처리 흐름에 중점을 둔 모델
- 시스템이 처음 입력을 받아서 처리하고 출력하는 전체 흐름을 순차적으로 표현
- 주로 비즈니스 시스템에서 사용
특징
- 요구사항 분석 단계에서 유용
- 전체 처리과정 및 흐름을 시각적으로 표현
- 시스템이 데이터 중심으로 어떻게 동작하는지 이해 가능
사용 도구
- DFD (Data Flow Diagram)
- UML Activity Diagram
2. Event-driven Models (이벤트 중심 모델)
- 시스템이 외부 또는 내부 이벤트에 따라 어떻게 반응하는지를 표현
- 주로 실시간 시스템, 제어 시스템에 사용
- 시스템은 유한한 상태(Finite States)를 가지며, 이벤트에 따라 상태가 전이됨
특징
- 상태 기반 시스템 설계에 적합
- 상태 간의 전이(transition)를 통해 시스템 동작을 표현
- 이벤트 중심으로 동작하는 반응형 시스템 모델링에 유용
사용 도구
- FSM (Finite State Machine)
- UML State Machine Diagram
3. State Machine Models (상태 기계 모델)
- 시스템이 특정 상태(state)에 있고, 이벤트에 따라 다른 상태로 전이되는 동작을 표현
- 자극 → 반응 구조를 명확하게 표현
구성 요소
요소설명
| State | 시스템의 현재 상태 (노드로 표현) |
| Event | 상태를 전이시키는 자극 (화살표의 트리거) |
| Transition | 이벤트에 의해 한 상태에서 다른 상태로 이동 |
사용 도구
- UML State Machine Diagram
| 모델 | 중점 | 사용 시점 | 대표 diagram |
| Data-driven Model | 입력 → 처리 → 출력의 흐름 | 요구사항 분석, 업무 시스템 | DFD, Activity Diagram |
| Event-driven Model | 이벤트에 대한 시스템의 반응 | 실시간 시스템, 상태 기반 제어 | FSM |
| State Machine Model | 상태 변화에 대한 반응 모델링 | 시스템 동작 설계 | UML State Machine Diagram |
- 비즈니스 로직 중심 시스템: Data-driven 모델로 전체 처리 흐름 파악
- 반응형 시스템, 제어 시스템: Event-driven & State Machine 모델로 상태 기반 흐름 설계
- 복잡한 행동 흐름 파악: 시각적 다이어그램(UML)으로 협업과 소통 강화
반응형