소프트웨어 개발과정
OOSD Process(객체 지향 소프트웨어 개발 과정)
OOSD Process의 workflow는 7단계로 이뤄진다.
요구사항 수집
비즈니스 오너와 시스템 사용자들과의 인터뷰를 통해서 시스템의 요구 사항을 결정 짓는 단계
- 기능적 요구사항
- 비기능적 요구사항
- 누가 사용할 것인지
- 시스템이 지원해야 하는 행동
요구사항 분석
시스템 요구 사항을 분석, 정제, 모델링 하는 단계
- 정교한 use case diagram의 내용
- problem domain안에서 무엇을 key abstraction할 것인지
- 유스 케이스 시나리오 분석
- 유스케이스 검증
- crc 분석을 통해 key abstraction 결정
- key abstraction들의 관계 표현
- domain model을 검증
아키텍처 수립
시스템의 high-level 구조를 모델링하여 프로젝트의 리스크를 진단하고 그것을 줄일 수 있는 방법을 강구하는 단계
- 소프트웨어 솔루션의 최상위 레벨 구조를 개발
- 아키텍처 모델을 지원할 기술 선정
- 비기능적 요구 사항을 만족시키기 위한 아키텍처 패턴을 가지고 정밀한 아키텍처 구축
- 시스템을 위한 아키텍처 타입 선택
- development diagram 생성
- 비기능적 요구 사항을 만족하도록 아키텍처 모델 보강
디자인
- 유스케이스를 위한 디자인 모델 생성
- 솔루션 모델 생성
- 도메인 모델 보강
- 솔루션 모델과 도메인에 디자인 패턴 적용
- 복잡한 객체 상태를 모델
시스템 구축
- 소프트웨어 구현
- 테스트 수행
- 도메인 모델 보강
- 생산 환경속으로 소프트웨어 배치
UML(The Unified Modeling Language)
UML은 프로젝트에 참여하는 모든 사람들이 이해할 수 있는 방법으로 개발 과정을 조직화 하는 수단이다. 시스템 개발에서도 참가자 전원이 이해 가능한 표현 수단이다.
UML의 요소는 Things(사물)과 Relationships(관계)로 나눌 수 있다. UML의 요소는 아래와 같다
- Actor: 시스템 사용자나 다른 시스템
- use case: 시스템의 기능
- class: 객체 지향 프로그램의 단위
- object: 프로그램 수행시의 구체적인 메모리 정보
- components: 독립적으로 재사용 가능한 모듈
- state: 프로그램이나 구성 요소들의 상태
- Activities: 프로그램의 동적 행위
- dependencies: 의존도
- Associations: 연관성
- Generalizations: 상속
- Realizations: 구현
UML Diagram의 종류
Use Case Diagram
use case는 사용자의 입장에서 본 시스템의 행동이다. 시스템의 기능적 요소를 표현한 것이다. Actor와 use case를 사용해 완성된다. Actor는 사람과 시스템, 시간 모두 될 수 있다.
Class Diagram
class는 객체 지향 프로그램의 단위이다. class는 method(함수)와 attributes(변수)로 이루어진다.
Object Diagram
시스템이 수행 시 클래스를 통한 구체적 정보를 메모리에 저장해 두고 사용하는데 그 메모리 정보를 얻을 수 있다. 하나의 클래스를 통해서 다양한 객체가 생길 수 있다.
Collaboration Diagram
객체들간의 상관관계 또는 협력 작업을 그림으로 표현해 놓은 것을 말한다. 객체들 간의 관계는 실선으로 표현하며 화살표가 관계의 방향성을 지정한다. 화살표의 숫자는 시간상의 흐름을 표현하고 선의 이름으로 관계를 명확하게 설명할 수 있다.
Sequence Diagram
객체들끼리 주고받는 메세지의 순서를 시간의 흐름에 따라 표현하는 것이다.
Activity Diagram
기능 수행을 위해 어떤 동작이 일어나는지, 동작에 따라 시스템의 상태가 어떻게 바뀌는지에 대해 그림으로 표현한 것이다.
Component Diagram
Component는 독립적으로 재사용 가능한 모듈이다. 객체지향 기술은 컴포넌트 기반으로 개발할 수 있다. 여러 컴포넌트를 통해 하나의 시스템을 이루는 그림이다.
Deployment Diagram
컴퓨터를 기반으로 하는 시스템의 물리적인 구조를 나타낸 그림이다.
Package Diagram
다이어그램들은 연관성 있는 단위들로 그룹화해서 묶어 관리하면 훨씬 유용하게된다.
Statechart Diagram
객체는 시간에 따라 다른 상태에 놓일 수 있다. 어떤 시스템에서 활동하고 있는 객체가 상황에 따라 자신의 상태를 변경할 수 있다면 이를 그림으로 표현하는 것이다.
소프트웨어 개발 방법론
개발 과정에서 가장 기본이 되는 구조를 소프트웨어 방법론이라고 한다. 구조는 네 가지로 이뤄져 있으며, phases, workflow, activities, artifacts이다.
Waterfall
폭포수 모델은 가장 오래된 개발 방법론 중 하나이다. 모든 프로세스가 직렬로 되어 있으며 반복하지 않는다. 한번 진행된 워크플로우는 다시 진행되지 않는다. 요구사항이 변경되어도 수정이 불가능한 단점이 있다.
클라이언트의 요구사항 변경이 예상되는 경우 적합하지 않다. 리스크가 낮은 프로젝트인 경우 한번에 성공 시킬 수 있는 경우 적합한 방법론이다.
Unified software development process
USDP는 UP 라고 불리기도 한다.
UP 방법론은 네 가지로 구성되어 있다.
Inception(도입)
소프트웨어의 비전을 생성하는 단계로 비즈니스 유형을 이해하는데 중점을 둔다. 프로젝트의 위험 요소를 제시하게 되고 전개 단계의 계획이 짜여진다.
Elaboration(전개)
시스템 아키텍처가 수립되고 대부분의 기능이 정의 되는 단계다. 프로젝트 위험 부담 감소가 목적이며, 프로젝트 매니저가 구현과 전이에 대한 정보를 가지고 있어야 한다.
Construction(구축)
소프트웨어를 구축하는 단계로 여러번의 반복으로 use case가 추가되고 소프트웨어는 확대된다. 이 단계에서 시스템은 베타 버전을 발표하게 된다.
Transition(전이)
시스템 가동을 위한 준비를 한다. 테스트, 디버깅, 트레이닝, 빌딩을 포함하는 프로젝트가 배치되는 단계이다.
Rational Unified Process(RUP)
UP의 상용버전으로 각 단계에서 진행되는 워크플로우를 지원하고 산출물들이 쉽게 도출되도록 돕는다.
SunTone Architecture Methodology
sun에서 개발한 방법론으로 up의 프로세스를 따른다. 엔터프라이즈 어플리케이션의 아키텍처를 강조한다는 특징이 있다. 시스템의 비기능적 요구사항을 지원하는데 중점을 두어 시스템의 질을 높이고 위험 요소를 줄일 수 있다.
3D 큐브를 통해 가시화 한다. 가로는 수평적 tier 구조를 나타내고 높이는 수직적인 layer구조, 새로는 각 계발 단계를 명시한다.
extreme Programming(XP)
애자일 개발 방법론 중 하나로 단순성, 소통, 피드백 등의 원칙에 기반해 고객에게 최고의 가치를 빠르게 전달하도록 하는 경량화된 개발 방법론이다.
XP 개발 방법론의 특징은 짝(pair) 프로그래밍, 테스팅, 리팩토링, 단순화가 있다. 짝 프로그래밍으로 서로 코드를 짜고 리뷰를 하는 방식으로 더 좋은 코드를 생산해 낸다. 테스트는 코딩하기 이전 단계에서 테스트 프로그램을 먼저 만든다. 리팩토링은 짝 프로그래밍을 하는 동안 이뤄진다.
XP 개발 방법론은 전통적인 회사보단 실험적인 회사에서 적용하기 적합하다.