[정보처리기사] 요구사항 확인 (2)

[2] UML

1. UML의 개념

• UML은 객체지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어이다.

2. UML의 특징

특징	설명
가시화 언어	- 개념 모델 작성 시 오류가 적고 의사소통이 용이
구축언어	- 다양한 프로그래밍 언어로 실핼 시스템의 예측 가능 - UML을 소스 코드로 변환하여 구축 가능, 역 변환하여 역공학 가능
명세화 언어	정확한 모델 제시, 완전한 모델 작성 가능
문서화 언어	시스템에 대한 평가 및 의사소통의 문서

3. UML 구성요소

구성요소	내용
사물	- 추상적인 개념으로, 주제를 나타내는 요소
관계	- 사물의 의미를 확장하고 명확히 하는 요소 - 사물과 사물을 연결하여 관계를 표현하는 요소 - 단어 관점에서 형용사 또는 부사를 의미
다이어그램	- 사물과 관계를 모아 그림으로 표현한 형태 - 형식과 목적에 따라 9가지로 정의

4. UML 다이어그램

- UML 다이어그램은 구분에 따라 구조적(정적) 다이어그램, 행위적(동적) 다이어그램으로 구분된다

- 컴포넌트, 배치 다이어그램은 구현 단계에서 사용되는 다이어그램이다

구분	다이어그램	설명
구조적 다이어그램(Structural Diagram) / 정적 다이어그램 (Static Diagram)	클래스 (Class)	-시스템 내 클래스의 정적 구조를 표현 - 속성 (Attribute)과 동작 (Behavior)으로 구성 - 시스템의 구조를 파악하고 구조상의 문제점 도출 가능
	객체 (Object)	- 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현 - 객체 인스턴스를 나타내는 대신 실제 클래스를 사용 - 연관된 모든 인스턴스를 표현
	컴포넌트 (Component)	- 코드 컴포넌트 기반의 물리적 구조 표현 - 실질적 프로그래밍 작업에 사용
	배치 (Deployment)	- 컴포넌트 사이의 종속성을 표현 - 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
	복합체 구조 (Composite Structure)	- 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
	패키지 (Package)	- 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

구분	다이어그램	설명
행위적 다이어그램 (Behavioral Diagram) / 동적 다이어그램 (Dynamic Diagram)	유스케이스 (Usecase)	- 사용자 관점에서 시스템의 활동을 표현 - 유스케이스는 시스템의 기능적 요구 정의에 활용
	시퀀스 (Sequence)	- 객체 간 상호작용을 메시지 흐름으로 표현 - 객체 사이 메시지를 보내는 시간을 표현
	커뮤니케이션 (Communication)	- 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고 받는 메시지를 표현하는데 메시지 뿐만 아니라 객체 간의 연관까지 표현
	상태 (State)	- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지 표현 - 모든 가능한 상태와 전이를 표현 - 진입 조건, 탈출 조건, 상태 전이 등 기술
	활동 (Activity)	- 시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름으로 순서대로 표현 - 활동의 순서대로 흐름을 표현
	타이밍 (Timing)	- 객체 상태 변화와 시간 제약을 명시적으로 표현

5. UML 상세

1. 클래스 다이어그램

1) 클래스 다이어그램 개녕

- 클래스 다이어그램은 객체지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현한 다이어그램이다.

 

2) 클래스 다이어그램 구성요소

- 클래스 다이어그램의 구성요소로는 클래스 이름, 속성, 연산, 접근 제어자(접근 제한자)가 있다.

• 클래스 이름: 클래스의 이름
• 속성: 클래스의 특징에 이름을 부여
• 연산: 객체에 요청하여 행동에 영향을 줄 수 있는 서비스
• 접근 제어자: 클래스에 접근 할 수 있는 정도를 표현
  - : 클래스 내부 접근만 허용 (private)
  + : 클래스 외부접근을 허용 (public)
  # : 동일 패키지ㅡ 파생 클래스에서 접근 가능 (protected)
  ~ : 동일 패키지 클래스에서 접근 가능 (default)

2. 유스케이스 다이어그램

1) 유스케이스 다이어그램 개념

- 유스케이스 다이어그램은 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램

 

2) 유스케이스 다이어그램 구성요소

- 유스케이스 다이어그램 구성요소는 유스케이스, 액터, 시스템이 있다.

• 유스케이스: 시스템이 제공해야하는 서비스, 액터가 시스템을 통해 수행하는 일련의 행위
• 액터: 사용자가 시스템에 대해 수행하는 역할, 시스템과 상호작용하는 사람 또는 사물
• 시스템: 전체 시스템의 영역을 표현

3. 시퀀스 다이어그램

1) 시퀀스 다이어그램 개념

- 시퀀스 다이어그램은 객체 간 상호작용을 메시지 흐름으로 표현한 다이어그램

 

2) 시퀀스 다이어그램 구성요소

- 시퀀스 다이어그램 구성요소는 객체, 생명선, 실행, 메시지가 있다.

• 객체: 객체는 위쪽에 표시되며 아래로 생명선을 가짐, 객체는 사각현 안에 밑줄 친 이름으로 명시
• 생명선: 객체로부터 뻗어 나가는 점서느 실제 시간이 흐름에 따라 객체의 생명주기 동안 발생하는 이벤트를 명시
• 실행: 직사각형은 오퍼레이션(함수) 이 실행되는 시간을 의미, 직사각형이 길어질수록 오퍼레이션 수행기단이 긺
• 메시지: 객체 간의 상호작용은 메시지교환으로 이루어짐, 한 객체에서 다른 객체로의 메시지를 전달하여 전달받은 객체의 오퍼레이션을 수행

 

6. UML의 관계

UML의 관계는 사물과 사물 사이의 연관성을 표현하는 것으로서 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등이 있다.

 

 

연관 관계 예시

 

일반화 관계 예시

 

집합 관계 & 포함 관계 예시

 

연관 관계 & 의존 관계 예시

 

실체화 관계 예시

7. UML 확장 모델의 스테레오 타입 (Stereotype)

- UML의 스테레오 타입은 UML의 기본적 요소 이외의 새로운 요소를 만들어 내기 위한 확장 메커니즘이다.

- 형태는 기존의 UML의 요소를 그대로 사용하지만 내부 의미는 다른 목적으로 사용하도록 확장한다.

- UML의 스테레오 타입은 <<>> (길러멧: Guillemet) 기호를 사용하여 표현한다.

 

1) UML 스테레오 타입 유형

• <<include> : 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계
• <<extend>> : 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고, 그렇지 않을 수도 있는 확장 관계
• <<interface>> : 모든 메소드가 추상 메소드이며, 바로 인스턴스를 만들 수 없는 클래스로 추상 메소드와 상수만으로 구성된 클래스
• <<entity>> : 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스
• <<boundary> : 시스템과 외부 액터와의 상호작용을 담당하는 클래스
• <<control>> : 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스

include 와 extend 예시

 

interface 예시

 

boundary & control & entity 예시

[3] 애자일 (Agile)

1. 애자일 방법론의 개념

- 애자일 방법론은 소프트웨어 개발방법론의 하나로서 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다.

 

2. 애자일 방법론 등장 배경

- 애자일 방법론은 기존 개발방법론의 한계를 극복하기 위해 등장했다.

등장 배경	설명
소프트웨어 개발 환경의 변화	- 소프트웨어 개발 트렌드가 모바일 환경으로 변화 - 시장 적시성과 잦은 배포의 중요성 부각
기존 개발방법론의 한계	- 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어려움 - 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가

3. 애자일 방법론 특징

• 프로젝트의 요구사항은 기능 중심으로 정의한다.
• 절차와 도구보다 개인과 소통을 중요하게 생각한다.
• 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있다.
• 소프트웨어가 잘 실행되는 데 가치를 둔다.
• 고객과의 피드백을 중요하게 생각한다.

4. 애자일 선언문

• 공정과 도구보다 갠인과 상호작용
• 계획을 따르기보다 변화에 대응하기
• 포괄적인 문서보다 동작하는 소프트웨어
• 계약 협상보다 고객과의 협력

5. 애자일 방법론 유형

- 애자일 방법론은 대표적으로 XP, 린(Lean), 스크럼(SCRUM) 등이 있다.

 

1) XP (eXtreme Programming)

- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

- 1~3주의 반속(Iteration) 개발 주기

- 5가지 가치와 12개의 실천항목이 존재

 

* 5가지 가치

가치	설명
용기 (courage)	- 용기를 가지고 자신감 있게 개발(코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리패토링할 수 있는 용기)
단순성 (simplicity)	필요한 것만 하고 그 이상의 것들은 하지 않음
의사소통 (communication)	개발자, 관리자, 고객 간의 원활한 소통
피드백 (feedback)	의사소통에 대한 빠른 피드백
존중 (respect)	팀원 간의 상호 존중

 

* 12가지 기본원리

기본원리	설명
짝 프로그래밍 (pair programming)	- 개발자 둘이서 짝으로 코딩하는 원리
공동 코드 소유 (collective ownership)	- 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
지속적인 통합 (CI: Continuous Integration)	- 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
계획 세우기 (Planning Process)	- 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
작은 릴리즈 (small release)	- 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 한다는 원리
메타포어 (metaphor)	공통적인 이름 체계와 시스템 서술어를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리
간단한 디자인 (simple Design)	- 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
테스트 기반 개발 (TDD: Test Driven Develop)	- 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
리팩토링 (Refactoring)	- 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성 한다는 원리
40 시간 작업 (40-Hour Work)	- 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 않는다는 원리. 개꿀이다
고객 상주 (On Site Customer)	- 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
코드 표준 (Coding standard)	- 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리

2. 스크럼 (SCRUM)

- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

주요 개념	설명
백로그 (Backlog)	- 제품과 프로젝트에 대한 요구사항
스프린트 (Sprint)	- 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상
스크럼 미팅 (Scrum Meeting)	- 매일 15분 정도 미팅으로 To-Do list 계획 수립 - 데일리 미팅이라고 함
스크럼 마스터 (Scrum Master)	- 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
스프린트 회고 (Sprint Retrospective)	- 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록 - 해당 스프린트가 끝난 시점이나 일정 주기로 시행
번 다운 차트 (Burn Down Chart)	- 남아있는 백로그 대비 시간을 그래픽 적으로 표현한 차트 - 백로그는 보통 수직축에 위치하며 시간은 수평축에 위치

3. 린 (LEAN)

- 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비요소를 제거하여 품질을 향상시킨 방법론

- JIT (Just IN Time) , 칸반(Kanban) 보드 사용

- 7가지 원칙: 

• 낭비 제거
• 품질 내재화
• 지식 창출
• 늦은 확정
• 빠른 인도
• 사람 존중
• 전체 최적화

6. 애자일과 전통적 방법론 비교

 

비교 대상	애자일 방법론	전통적 방법론
계획수립	- 유동적 범위 설정	- 확정적 범위 설정
업무수행	- 팀 중심 업무 수행	- 관리자 주도적 명령과 통제 - 개인 단위로 업무 수행
개발/검증	- 반복 주기 단위로 소프트웨어를 개발/ 검증	- 분석, 설계, 구현, 테스트를 순차적으로 수행
팀관리	- 업무 몰입, 팀 평가	- 경쟁, 개별 평가
문서화	- 문서화 보다는 코드를 강조	- 상세한 문서화를 강조
성공요소	- 고객 가치 전달	- 계획.일정 준수
유형	- XP, 스크럼, 린	- 폭포수, 프로토타입, 나선형