1. 요구 사항 확인

1. 요구사항 확인
05. 요구사항 정의
10. UML- 관계 
11. UML- 다이어그램
14. 클래스 다이어그램
18. 패키지 다이어그램
22. 비용 산정 기법 - 상향식

 

---

05. 요구사항 정의

1. 요구사항: 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건이다. 

2. 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다.

3. 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다.

4. 요구 사항의 유형 (이 4가지 유형도 암기해야 함)

- 기능 요구 사항

- 비기능 요구 사항

- 사용자 요구 사항: 사용자 관점에서 본 시스템이 제공해야 할 요구사항. 사용자를 위한 것. 친숙한 표현

- 시스템 요구 사항: 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구 사항. 전문적, 기술적 용어로 표현되며 소프트웨어 요구 사항이라고도 한다.

-> 크게 기능과 비기능으로 구분할 수 있다.

 

4-1. 기능 요구사항

- 시스템이 무엇을 하는지, 어떤 기능을 하는 지 등의 기능이나 수행과 관련된 요구사항

- 사용자는 회원 ID와 비밀번호를 입력하여 로그인 할 수 있다와 같이 말 그대로 기능에 관한 요구 사항

 

4-2. 비기능 요구 사항

- 품질이나 제약 사항과 관련된 요구 사항

- 시스템 장비 구성, 성능, 인터페이스, 데이터 구축하기 위해 필요한 요구 사항, 테스트, 보안 등

- 시스템은 1년 365일 하루 24시간 운용이 가능해야 한다와 같이 대부분 품딜과 제약 사항과 관련이 있다.

 

---

10. UML

1. UML: 시스템 분석, 설계 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

2. OMT, Booch, Jacobson 등의 객체지향방법론의 장점을 통합

3. OMG(object management group)에서 표준으로 지정하였다.

4. UML의 구성 요소: 사물, 관계 다이어그램

많은 사람들이 모여 작업을 수행하다 보면 같은 대상물을 보고도 서로 다르게 표현하여 의사소통에 문제가 생기는 경우가 있다. 이런 문제를 해결하는 가장 좋은 방법은 공통된 표현법을 만들어 사용하는 것.

UML은 공통된 표현법을 사용해 개발할 대상물을 다이어그램으로 표현하는 도구이다. 소프트웨어 개발 참여자들은 UML로 표현된 다이어그램으로 개발에 관한 의견을 서로 교환한다.

 

 

5. 사물(things)

- 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다.

- 모델을 구성하는 가장 중요한 기본 요소

- 사물의 종류

1. 구조 사물: 시스템의 개념적, 물리적 요소를 표현, 클래스(class), 유스케이스(use case), 컴포넌트(component), 인터페이스(interface), 노드(node) 등

2. 행동 사물: 시간과 공간에 따른 요소들의 행위를 표현, 상호작용(interaction), 상태 머신(state machine) 등

3. 그룹 사물: 요소들을 그룹으로 묶어서 표현, 패키지(package)

4. 주해 사물: 부가적이니 설명이나 제약 조건 등을 표현, 노트(note)

사물들은 이름을 통해 그 역할을 유추할 수 있으니 사물들의 종류만 기억할 것.
- component: 문서, 소스코드, 파일, 라이브러리 등과 같은 모듈화된 자원으로, 재사용이 가능하다.
- interface: 클래스나 컴포넌트의 전체 또는 일부분의 동작을 모아 놓은 것, 클래스가 외부적으로 가시화되는 행동을 표현한다. 

사물, 즉 객체는 유스케이스, 클래스, 컴포넌트와 같이 별도의 표현 형태가 있는 경우를 제외하고는 기본적으로 사각형으로 표현한다.

 

 

6. 관계 (relationships)

- 사물과 사물 사이의 연관성을 표현하는 것

- 관계의 종류: 연관, 집합, 포함, 일반화, 의존, 실체화 (뒤에 다  관계 붙임)

 

- 연관 관계

1. 연관 관계는 2개 이상의 사물이 서로 관련되어있는 관계

2. 사물 사이를 실선으로 연결하여 표현

3. 방향성은 화살표로 표현한다.

4. 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결한다.

5. 다중도를 선 위에 표기한다. (다중도: 연관에 참여하는 객체의 개수를 의미)

다중도 : 1 -> 의미: 1개의 객체가 연관되어 있음
n -> n개의 객체가 연관되어 있음
0..1 -> 연관된 객체가 없거나 1개만 존재함
0..* 또는 * -> 연관된 객체가 없거나 다수일 수 있음
1..* -> 연관된 객체가 적어도 1개 이상임
n..* -> 연관된 객체가 적어도 n개 이상임
n..m -> 연관된 객체가 최소 n개에서 최대 m개임

ex. 선생님 - 학생 or 사람 -> 집

 

 - 집합 관계 Aggregation

1. 하나의 사물이 다른 사물에 포함되어 있는 관계

2. 포함하는 쪽(전체, whole)과 포함되는 쪽(부분, part)은 서로 독립적

3. 포함되는 쪽(part)에서 포함하는 쪽(whole)으로 속이 빈 마름모를 연결하여 표현한다. 

ex. 컴퓨터 <- 프린터

 

- 포함 관계 Composition

1. 집합 관계의 특수 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

2. whole과 part은 서로 독립될 수 없고 생명주기를 함께한다.

3. part에서 whole으로 속이 채워진 마름모를 연결하여 표현한다.

ex. 문 <- 키

 

- 일반화 관계 Generalization

1. 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계

2. 보다 일반적인 개념이 상위(부모), 구체적인 개념이 하위(자식)

3. 하위인 사물에서 사우이인 사물 쪽으로 속이 빈 화살표를 연결하여 표현한다.

ex. 사람은 여자와 남자보다 일반적인 개념이고, 여자와 남자는 사람보다 구체적인 개념이다. 

ex. 아메리카노, 에스프레소 -> 커피

 

- 의존 관계 Dependency

1. 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계 ex. 등급 -> 할인율

2. 하나의 사물과 다른 사물이 소유 관계는 아님. 하지만, 사물의 변화가 다른 사물에도 영향을 미치는 관계

3. 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현

 

- 실체화 관계 Realization

1.  사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계 ex. 비행기, 새 -> 날 수 있다.

2. 사물이 기능쪽으로 속이 빈 점선 화살표를 연결하여 표현한다.

1. 연관: 실선, 필요하면 화살표, 다중도 표기
2. 집합: 속이 빈 마름모
3. 포함: 속이 채워진 마름모
4. 일반화: 속이 빈 화살표
5. 의존: 점선 화살표
6. 실체화: 속이 빈 점선 화살표 

 

---

11. UML- 다이어그램

1. 다이어그램: 사물과 관계를 도형으로 표현한 것.

2. 여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움을 준다.

3. 정적 모델링에서는 주로 구조적 다이어그램을 사용

4. 동적 모델링에서는 주로 행위 다이어그램을 사용

 

- 다이어그램이 무엇인지, 구조적 다이어그램에는 어떤 것이 있고, 행위 다이어그램에는 어떤 것이 있는지

- 어떤 다이어그램을 말하는 지 찾아낼 수 있어야 함, 각 다이어 그램의 개념을 알고 있어야 한다.

 

 

5. 구조적 다이어그램의 종류 (클객컴배복패)

1) 클래스 다이어 그램: 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현

 

2) 객체 다이어 그램:

- 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현함.

- 럼바우(rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용됨.

 

3) 컴포넌트 다이어그램:

- 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현함

- 구현 단계에서 사용됨

 

4) 배치 다이어그램: 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현함, 구현 단계에서 사용됨.

 

5) 복합체 구조 다이어그램(composite structure): 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함.

 

6) 패키지 다이어그램: 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현함.

 

6. 행위 다이어그램의 종류 (유순커상활상타)

1) 유스케이스 다이어그램:

- 사용자의 요구를 분석하는 것. 기능 모델링 작업에 사용. 

- 사용자와 사용 사례로 구성된다. (Actor + Use Case)

 

2) 순차 다이어그램:

- 상호 작용하는 시스템이나 객체들이 주고 받는 메시지를 표현함. 객체들 사이의 메시지 교환을 나타냄.

 

3) 커뮤니케이션 다이어그램: 동작에 참여하는 객체들이 주고 받는 메시지와 객체들 간의 연관관계를 표현함.

 

4) 상태 다이어그램: 

- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지를 표현

- 럼바우(rumbaugh)  객체지향 분석 기법에서 동적 모델링에 활용됨.

 

5) 활동 다이어그램: 시스템이 어떤 기능을 수행하는 지, 객체의 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현함

 

6) 상호작용 개요 다이어그램: 상호작용 다이어그램 간의 제어 흐름을 표현함.

 

7) 타이밍 다이어그램: 객체 상태 변화와 시간 제약을 명시적으로 표현

 

 

7. 스테레오 타입 (stereotype)

1) UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것

2) 길러멧(Guilemet)이라고 부르는 << >> 사이에 표현할 형태를 기술

3) 주로 표현되는 형태

<<include>> : 연결된 다른 UML 요소에 대해 포함 관계에 있는 경우

<<extends>> : 확장 관계에 있는 경우

<<interface>> : 인터페이스 정의하는 경우

<<exception>> : 예외를 정의하는 경우

<<constructor>> 생성자 역할을 수행하는 경우

 

---

14. 클래스 다이어그램

1. 정적 모델링

- 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것.

- 객체들 사이에 어떤 관련이 있는지를 구조적인 관점 (view)에서 표현한다.

- 정적 모델링은 객체(object)들을 클래스(class)로 추상화하여 표현한다.

- UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램이다. 

 

 

2. 클래스 다이어그램

- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것.

- 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램

- 시스템 구성 요소를 문서화하는 데 사용

 

3. 클래스 다이어그램의 구성 요소

1) 클래스

2) 제약 조건

3) 관계

 

 

4. 연관 클래스 

- 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이라 오퍼레이션이 있는 경우 생성하는 클래스

- 두 클래스의 연관관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시한다.

- 연관 클래스의 이름은 연관 관계의 이름을 이용해 지정한다.

 

-> 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 연관 클래스를 생성한다.

연관 클래스의 개념을 기억해야 함!

 

---

18. 패키지 다이어그램

1. 패키지 다이어그램

- 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것

- 패키지는 또 다른 패키지의 요소가 될 수 있다.

- 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용한다.

패키지 다이어그램은 클래스 다이어그램과 같은 정적 모델링의 하나
관련있는 객체들을 하나로 묶어 클래스보다 상위 개념인 패키지로 추상화한 것
시스템의 구조를 간략하게 표현할 수 있고 각 패키지 간의 의존 관계를 명확하게 파악할 수 있어, 불필요한 의존 관계를 제거하거나 간략화함으로써 시스템의 복잡도를 낮추는데 사용할 수 있다.

 

2. 패키지 다이어그램의 구성 요소

 

그림이 짤렸지만, 단순 표기법 예와 그 아래는 확장 표기법 예시이다. 

 

아래 사진이 패키지 다이어 그램의 예시인 것!

 

---

22. 비용 산정 기법 - 상향식

1. 상향식 비용 산정 기법

- 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법

- 주요 상향식 비용 산정 기법: LOC(원시 코드 라인 수) 기법, 개발 단계별 인월수 기법, 수학적 산정 기법

 

2. LOC 원시 코드 라인 수, source line of code 기법

- 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법

비관치: 가장 많이 측정된 코드라인 수 
낙관치: 가장 적게 측정된 코드 라인 수
기대치: 측정된 모든 코드 라인수의 평균

 

- 측정이 용이하고, 이해하기 쉬워 가장 많이 사용된다.

- 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다. 

- 예측치 = (a+4m+b)/6 (단, a: 낙관치, b: 비관치, m: 기대치(중간치))

- 산정 공식

1. 노력 (인월) = 개발 기간 * 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수

2. 개발 지용 = 노력 (인월) * 단위 비용(1인당 월평균 인건비)

3. 개발 기간 = 노력(인월) / 투입 인원

4. 생산성 = LOC / 노력(인월)

 

ex. LOC 기법에 의하여 예측된 총 라인 수가 30,000라인, 개발에 참여할 프로그래머가 5명, 프로그래머들의 평균 생산성이 월간 300라인일 때 개발에 소요되는 기간은?

- 노력(인월) = LOC/1인당 월평균 생산 코드 라인 수 = 30000/300 = 100명

- 개발 기간 = 노력(인월)/투입 인원 = 100/5 = 20개월