델파이 목차와 공부 계획

30일 밖에 시간이 없다!!(트라이얼 버전은 30일 밖에 못씀)

그럴려면 목차를 보고 공부 기간을 설정하는 것이 좋다.

델파이 Begin... End 의 목차를 보니

크게는 파트 1,2,3 로 나누어져 있고

파트1은 델파이의 기본이고
파트2는 데이터베이스 관련이고
파트3는 웹프로그래밍 이다.

기본적인 공부는 하루에 1장 씩이다.

파트2 까지가 14장이다.

주말을 뺀다면....(나도 좀 놀자) 파트2까지는 한달안에 할 수 있을 듯하다.

파트3는 웹인데........ 웹은 거의다 jsp니깐 패스닷.(오오미 현실적인)

자 이제 2파트까지만 하기로 정했다. 각 장의 제목을 보자.

파트 1

1장 델파이로 프로젝트 시작하기
2장 폼의 특성과 띄우기
3장 컴포넌트와 친해지기
4장 컴포넌트 라이브러리와 패키지
5장 디버가 사용하기

파트 2
6장 데이터베이스 프로그래밍 개요
7장 BDE를 사용한 데이터베이스 프로그래밍
8장 필드 에디터
9장 예외(Exception)처리
10장 보고서 작성하기
11장 DLL 작성과 호출
12장 DBExpress를 사용한 데이터베이스 프로그래밍
13장 ADO를 이용한 데이터베이스 프로그래밍
14장 분산처리(DateSnap)

이다. 총 14장 기간은 30일. 흠... 기간이 남으면 파트3을 할 수도 있겠다 ㅎㅎ;

파트3

15장 웹 브로커를 이용한 웹 프로그래밍
16장 DataSnap 웹
17장 DataSnap REST
18장 인트라웹을 이용한 웹 프로그래밍
19장 컴포넌트 작성
20장 인디 컴포넌트를 이용한 프로그래밍
21장 쓰레드


이 글은 결코 아직도 설치가 완료 안되서 쓴 건 아니다..........

델파이를 배워보자~!

어제(10일)에 자격증 시험이 끝났다(실기가 남았음 ㅡ.ㅡ)
오늘 가답안 체크해보니 널널하게 합격~! (잇힝)

오늘부터는 델파이를 공부해보려고 한다.

델파이가 뭐당가??

솔직히 나도 회사가서 처음 본 언어다.

하이레벨과 로우레벨을 넘나드는 언어인것 같다.

로우레벨은 나중에 내가 아두이노 가지고 놀 때 해볼 계획이고

일단은 델파이를 해보고자 한다.

어차피 공부하면서 공부한 내용을 복습차원에서 올리는 것이기에

허접할 수도 있다.(나만 이해하면 돼-0-)

일단 델파이를 깔아보자.

http://www.embarcadero.com/downloads

여기에서 RAD Studio XE3 를 설치하면 된다.

다운을 받으려면 일단 회원가입을 해야한다. 어차피 배울꺼니 가입하자(무료다)

다운은 빠르지만 설치는 무지하게 오래걸린다
(지금 이 글을 쓰는 이 순간에도 설지 안됐음 ㅡㅡ)

그런데 30일밖에 못쓰기 때문에 빠르게 후딱 배워야 한다.

개인적으로는 차라리 툴을 공짜로 배포해야 델파이가 많이 활성화 될 꺼 같다는 느낌이..
자바가 왜 그리 확산 되었는지 보면 알 수 있다.

30일 내로 배워야 하는 나로써도 x줄이 탄다. ㄷㄷㄷ

과감하게 배워보자쿠나~

델파이는 기본적으로 책이 별로 없다.

델파이 기본 문법책
http://www.yes24.com/24/goods/3359533?scode=032&OzSrank=2

델파이 응용책
http://www.yes24.com/24/goods/5325972?scode=032&OzSrank=1

기본 문법은 어차피 비슷하니 나 같은 경우는 바로 응용책으로 넘어갔다.

오늘은 열심히 깔고 내일부터 본격적인 델파이를 하겠다.

그러고 보니 내일이면 자격증 실기책도 오는데 -_-

둘 다 병행해야 한다니!!

소스코드를 다운 받을 수 있는 곳.
http://tech.devgear.co.kr/devgearbook/2435

헤드퍼스트 OOAD - 10강 - 종합하기

드디어 마지막 강 10강이다. (씹강이다 -_-)

이번 강은 처음부터 끝까지 프로그램을 만드는 과정이 담긴 종합하는 강이다

OOAD 프로젝트의 생명주기를 살펴보자.

특징리스트 -> 유스케이스 다이어그램 -> 문제점 분해하기

-> 요구사항 -> 도메인분석 -> 사전 설계 -> 구현 -> 완성

빨강 부분은 반복적으로 하는 부분이다.

위대한 프로그램을 만들기 위해선 3단계를 거쳐야 했다

3단계를 복습하자면.

1. 여러분의 소프트웨어가 고객이 원하는 기능을 하도록 만드는 것
2. 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 하는 것
3. 유지보수와 재사용이 쉬운 디자인을 위해 노력하는 것

당신이 만약 지하철 노선도를 만드는 프로젝트를 맡았다고 해보자.
위의 생명주기를 토대로 시작해보자.

1. 특징 리스트 작성

• 지하철 노선과 노선의 역들을 표시
• 겹쳐진 노선을 포함하여 다수의 지하철 노선을 저장할 수 있어야 함
• 모든 노선에서는 임의의 두 역 사이의 유요한 경로를 찾을 수 있어야 함
• 일련의 방향 표시로, 두 역 사이의 경로를 출력할 수 있어야 함

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

관리자 - 지하철 노선과 노선들의 역을 표시, 겹쳐진 노선을 포함하여 다수의 지하철 노선을 저장

사용자 - 두 역 사이의 유요한 경로를 찾기, 두 역 사이에 있는 특정 경로의 방향 표시 출력

유스케이스는 사용법을 반영하고, 특징은 기능을 반영한다.

3. 문제점 분해하기

별개의 기능 조각을 분리하는 것이다. 먼저 크게 분리해보자.

지하철, 리더, 프린터, 테스트

로 분리해봤다.
문제점을 분해 하다 보니 이해가 안가는 부분이 있다.
지하철 시스템이 뭐지??
지하철 역과 노선을 저장할 때 관리자가 갖고 있어야할 정보가 뭐지?

요구 사항을 하기 전에 문제를 이해하는 단계가 있어야 한다.
지하철 노선 적재하기에 대한 유스케이스를 작성해 보자.
---------------------------------------------------------------------------------

지하철 노선 적재하기 (유스케이스)

1. 관리자가 역과 노선이 담긴 파일을 공급한다.
2. 시스템은 역의 이름을 읽는다.
3. 시스템은 역이 이미 존재하지 않는지 검증한다.
4. 시스템은 지하철에 새로운 역을 추가한다
5. 시스템은 모든 역이 추가될 때까지 단계 2~4를 반복한다
6. 시스템은 추가할 노선의 이름을 읽는다
7. 시스템은 연결되어 있는 두 역을 읽는다.
8. 시스템은 역들이 존재하는지 검증한다
9. 시스템은 현재 노선의 두 역 사이에, 양방향으로 진행 가능한 새로운 연결을 생성한다
10. 시스템은 노선이 완성될 때까지 단계 7~9를 반복한다.
11. 시스템은 모든 노선이 입력될 때까지 단게 6~10을 반복한다.

---------------------------------------------------------------------------------

4. 도메인 분석 

위의 유스케이스를 기반으로 분석을 하는 것이다. 먼저 명사와 동사를 나누어 적어보자.

명사(클래스 후보) - 관리자, 역, 파일, 시스템, 노선, 연결, 지하철

동사(오퍼레이션 후보) - 파일 제공한다, 역을 검증한다, 반복한다, 읽는다, 역을 추가한다, 연결을 추가한다.

5. 사전 설계

주황색으로 표시한 부분을 기반으로 클래스 다이어그램을 작성했다.

6. 구현하기

관리자 부분을 먼저 구현하고 테스트해보고 잘 구동되면

사용자 부분을 구현하고 테스트 해보면서 반복하는 것이다.

이 프로그램은 역의 추가, 삭제, 수정/노선의 추가, 삭제, 수정 이 용의해야하며

관리자 모드와 사용자 모드를 철저히 분리해야한다.

지금 위의 클래스 다이어그램에는 없는 출력 부분도 추가해줘야한다.

해당 소스 코드는 여기에서 다운 받길 바란다.

모든 것을 하나하나 구현할 필요는 없다. 공개 소스가 있다면 재사용하는 것도 프로그래머의  실력인 것이다. 

구현하면서 누구나 코드를 알아볼수 있게 주석과 이름을 잘 짓는 것이 중요하다.

유지보수가 쉽게 만드는 것도 프로그래머의 자질이다.

이로써 기나긴 OOAD에 대한 강좌(누가 본다고?!! ㅠㅠ)가 끝났다.

3월10일에 자격증 시험이 있어서 당분간 연재를 쉬고자 한다.

다음 강좌는 델파이, 자바, 자료구조, tcp/ip, 아이폰 개발 중 하나를 하겠다.

말이 강좌지 내가 공부하면서 까먹을까봐 다시 복습 차원에서 정리해서 올리는 거다 ㅡ.ㅡ;

그럼 그때까지 모두 수고염~~ >.<

헤드퍼스트 OOAD - 9강 -

9강의 내용은 어떤 방식으로 코딩을 할 것인가이다.

앞서 말했듯이 고객은 프로그래밍에 대해 전혀 모른다고 가정하는 것이 좋다.
그리고 눈으로 직접 보여줘야 안심을 할 것이다.
이때 3가지의 방식으로 나뉜다.

특징 주도 개발 - 기능을 위주로 만드는 것이다.

유스케이스 주도 개발 - 큰 시나리오를 토대로 개발하는 것이다.

테스트 주도 개발 - 실수를 없애기 위해 상상 가능한 모든 테스트를 통과해야 다음 단계를 진행하는 개발

스타3를 만든다고 가정을 하자면

특징 주도 개발은 마린의 총쏘는 모습, 이동 속도, 방법, 체력, 방어력을 만들어서 보여주는 것이다.

유스케이스 주도 개발은 스타 에피소드 1을 하나 통짜로 만드는 것이다.

적절한 비유인지는 모르겠으나.... 난 그리 이해했다 ㅡㅡ;;

그리고 또 다른 방법은 테스트 주도 개발이다.

한가지 기능의 테스트 시나리오를 작성하고 , 그 다음에 그 기능에 대한 코드를 작성한다.
그리고 가능한 모든 테스트를 통과할 때까지 소프트웨어를 수정하는 것이다.

책은 훨씬 긴 내용이지만 내가 지금 몹시 졸려서 이정도만 쓸란다 ㅡㅡ;;(어차피 보는 사람도 없는듯 ㅡㅜ)

헤드퍼스트 OOAD -8강-

이번 8강의 제목은 디자인 원리들이다.

프로그래밍 하면서 설계할 때 어떨때 어떤 디자인을 써야하는지 4가지로 분류를 했다.
먼저 디자인 원리란?
코드를 좀 더 유지보수하기 쉽고, 유연하고, 확장하기 쉽게 만들기 위해, 코드의 작성이나 디자인에 적용되는 기본 도구 또는 기법
이라고 괜히 길고 어렵게 써놨다 ㅡㅡ

원리1 개방 - 폐쇄의 원리(Open - Closed Principle, OCP)

OCP는 기존 코드를 변경하지 않으면서 코드의 수정을 허용하는 것 이다.

이게 도대체 뭔소리당가??

만약 악기 클래스가 있고 기타 클래스가 있다고 하고 악기 클래스에서 기타 클래스가 상속을 받아서 쓴다고 해보자.

악기클래스에는 악기의 전반적인 메소드가 있고, 기타 클래스는 기타의 특정부분을 가지고 있다. 하지만 악기의 전반적인 메소드를 상속을 받았지만 악기 클래스의 메소드를 변경해야할 때가 있을것이다. 이때 오버라이드를 해서 변경을 한다.

한마디로 이 원리는 상속 + 오버라이드 이다 -_- (끝)


원리 2 반복 금지의 원리 (Don't Repeat Yourself, DRY)

DRY는 공통되는 부분을 추출하여 추상화하고 한 곳에 두어 중복 코드를 피한다
이건 솔직히 원리라기보단 거의 기본에 가까운 것이다 ㅡ.ㅡ
하지만 궃이 정의하자면 하나의 요구 사항은 한 곳에 두어야 한다는 것이다.
중복코드를 피한다는 것은 각 기능과 요구 사항을 한번만 구현하려고 노력하는 것이다.

한마디로 DRY는 시스템의 각 정보와 기능을 말이 되는 하나의 장소에 두는 것을 의미한다.(끝)


원리 3 단일 책임의 원리(Single Responsibility Principle, SRP)

SRP 단일 책임의 원리 - 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나의 책임을 수행하는데 집중되어 있어야 한다.

위의 DRY랑 같은거 아니냐!!! 라고 할수도 있으나 관련은 있지만 좀 다르다.

dry는 하나의 기능을 한 곳에 두자는 것이고, srp는 클래스가 하나의 일만 하자는 것이다.
즉, 기능별로 세세하게 나눠서 놓자는 것이다.
만약 문을 여는 클래스가 있다고 해보자. 그럼 그건 문만 여는 거지 문을 열고 닫고 잠그고 풀고 어쩌구 저쩌구를 다 넣는것이 아닌 문을 여는 기능만 넣자는 것이다.

한 클래스에 있는 메소드가 하나의 일을 하는지 찾아내는 법을 소개한다.

아래와 같은 클래스가 있다고 해보자

Automobile 클래스에 대한 SRP 분석

Automobile 가 자신을 start 한다
Automobile 가 자신을 stop 한다
Automobile 가 자신을 changTires 한다
Automobile 가 자신을 drive 한다
Automobile 가 자신을 wash 한다
Automobile 가 자신을 checkOil 한다
Automobile 가 자신을 getOil 한다

쓰고 말이 되는 것과 안되는 것을 구분한다. 이중에서 말이 되는 것은 냅두고 안되는 것은 따로 빼는 것이다.
위와 같은 경우는 1,2,7번만 말이 된다.
나머지는 따로 빼서 클래스를 만드는 것이다. 그래서 이것도 끝 -_-v

원리 4 리스코프 치환 원리 (LSP)

LSP 의 의미는 자식 타입들은 부모 타입들이 사용되는 곳에 대체 될 수 있어야 한다.

이게 도대체 뭔 x소리냐?? 할 수도 있다.
예를 들어 2d 배경 클래스가 있는데, 이곳에 3d 배경을 하기 위해서 2d 배경 클래스를 상속 받아서 z축만 추가 한다고 해보자.
얼핏 보면 어? 맞는거 같은데? 하겠지만 어차피 2d에서 쓰는 것과 3d에서 쓰는 것은 많은 차이가 있다. 땅속에도 들어가야 하기에 - 값도 들어갈수도 있고 날기도 해야하고 상속을 받으면 3d에서는 필요 없는 부분도 있을 것이다.
그럼 이걸 어찌 하란 말인가?
상속을 하는 것이 아닌 기능을 위임하는 것이다.
위임은 특정 일의 책임을 다른 클래스나 메소드에 맡길 때 지칭하는 것이다.
3d와 2d에서 공통된 부분은 위임해서 2d에서 끌어다 쓰고, 3d 특화된 것은 3d에서 쓰는 거다.
다른 클래스의 기능을 사용해야 하지만 그 기능을 변경하고 싶지 않다면 상속 대신 위임을 사용하자.

또 다른 방법으로는 구성을 사용해서 다른 클래스들의 행동을 조합하는 방법이 있다.

fps 게임의 무기 클래스가 있다고 해보자.
무기 혼자만은 걍 객체일 뿐이다. 유저가 무기를 주워다 사용을 해야 의미가 있는 것이다.
그리고 무기는 기능도 다르고 다양하다. 이것을 연결할 때 구성을 사용하여 행동을 조합하는 것이다. 이건 클래스 다이어그램을 보면 이해가 쉬울 것이다.

구성을 통해 하나의 인터페이스를 구현한 여러 클래스들의 기능을 사용할 수 있고 실행중에 그 클래스를 바꾸어 기능을 변경할 수 있다.

구성에서는 다른 행동들로 구성된 객체는 그 행동을 소유하고 있다. 그 객레가 없어지면 소유하고 있던 모든 행동들도 없어진다. 구성에 참여한 행동들은 그 구성의 외부에서는 존재하지 않는다.

이게 뭔 소리인가 하면 ㅡㅡ
유닛이 무기를 주워다가 열라게 쓰다가 유닛이 죽으면 무기도 없어진다는 것이다.
이야~ 쉽게 설명했다~~~ 퍽퍽

만약 유닛이 죽어도 무기는 그냥 땅에 떨어지고 없어지지 않게 하고 싶다면?
그 때 써야 하는 것이 바로 집합이다.

집합은 유닛과 무기가 관계는 있지만 유닛이 없어진다고 무기도 같이 없어지는 관계는 아닌 것이다.

쓸데없이 4번째 디자인은 4개로 또 나뉘어서 있다 이것을 정리해보겠다.

상속 - 그야말로 부모꺼를 전.부 물려 받는 것
위임 - 전부 물려 받지 많고 필요한 것만 부모에게 시키는 것(호로자식?!)
구성 - 하나 또는 여러개의 클래스들, 특히 비슷한 종류의 여러 클래스들로 부터 행동을 재사용하는 법, 구성으로 연결된 객체는 객체의 외부에 독립적으로 존재할 수 없다
집합 - 구성과 비슷하지만 객체의 행동이 외부에서도 연결 될 수 있다.


이번 강의 좀 길게 썼다. 그만큼 공부하기에도 빡쎘다는 것이다 하악
어차피 복습 차원에서 올리는 것이니 나만 알아봐도 만족이다 ㅡㅡ;;;

그럼 이번 강도 끝!~

헤드퍼스트 OOAD -7강

7강의 주제는 아키텍처다.

아키텍처란??
시스템의 분할, 나뉜 부분들 사이의 연결과 상호 작용 메커니즘, 그리고 시스템의 디자인에 사용된 원리와 결정 사항들을 담고 있는 시스템의 구조

아키텍처가 해야할 일은 수많은 요구사항과 특징들을 잘 정리해서 설계를 하는 것이다.

예를 들어 스타크래프트3를 만든다고 해보자.
수많은 요구사항이 있을 것이다.
그럼 아키텍처는 가장 먼저 해야할일이 뭘까???
아래와 같이 요구사항이 있다고 해보자.
---------------------------------------------------------------------------------
스타크래프트 3
(특징 리스트)

1. 다양한 타입의 지형을 지원한다
2. 공상 과학 소설이나 판타지 소설에 등장하는 가상의 시대를 포함한 다양한 시대를 지원한다
3. 게임의 특성에 맞는 여러 타입의 부대들 또는 유닛들을 지원한다
4. 새로운 작전 수행이나 전쟁 시나리오를 위한 추가 모듈을 지원한다
5. 사각형의 타일들로 구성된 보드를 제공하고 각 타일은 지형 타입을 가지고 있다
6. 기본적인 이동을 관장한다
--------------------------------------------------------------------------------
아키텍처는 위와 같은 요구 사항에서 우선순위를 정하여 프로젝트를 진행해야한다.
그럼 어디서부터 시작을 해야할까?
이렇게 생각하면서 추적을 해야한다.

1. 시스템의 본질이 되는 부분은 무엇인가?
2. 이것은 도대체 무슨 의미인가?
3. 도대체 어떻게 해야하나?

이게 뭔 x소리냐고 한다면 책을 탓해라 ㅡ.ㅡ책에 그리 쓰여있다
위와 같은 요구사항에서는 가장 기본이 되는건 보드다.
보드가 있어야 뭔 유닛을 이동하고 싸우고 난리 부르스를 출 수 있는 것이다.
일단 보드를 만들자(빨리 만들어라 찰싹찰싹)

이번 스타3는 다양한 유닛이 필요하다. 유닛을 살펴보자
마법사, 검사, 저격수, 비행기, 배, 탱크, 벌레, 인부, 벙커, 잠수함 등등

아악 이것을 하나하나 구현하는것은 개발자가 할일이고 아키텍처는 유닛이라는 것을 어찌해놔야 확장성과 재사용성이 좋아지는지 고민해야한다.

1. 공통점은 무엇인가?
2. 차이점은 무엇인가?

먼저 공통점을 생각해보자.
모든 유닛은 각자의 무기가 있다, 즉, 싸울수 있다는 것이다.(심지어 scv도 싸운다)
차이점은 무기의 종류와 거리, 데미지, 방어력, 인구수 등이 다르다

스타3는 최대 8명이서 각자 200개까지의 유닛을 컨트롤하여 싸우는 게임이다
만약 공통점과 차이점을 분리하여 상속을 받아 쓰는 개념으로 만든다면
서버에 꽤 큰 부담을 줄 것이다. 그리고 밸런스 조정할 때도 꽤 힘든 작업이 될 것이다.

그래서 이번 같은 경우는 한 클래스에 전부 때려 박아서 만들 예정이다(뭐라?!!!)

과연 이게 좋은 일인가?? 물론 상속을 이용해서 만들어보고, 속도가 안나오면, 한 클래스로 묶어도 보고 그러면 얼마나 좋겠냐만......
고객과 사장은 결코 그런걸 원하지 않는다.

그럼 아키텍처는 "선택"을 해야한다. 확장성과 효율성을 선택해야하는 것이다.
확장을 하려는 것은 코드를 기능별로 나눠 놓는 것이 좋다.
효율성은 너무 많은 객체를 생성 안하는 것이 좋다.
그것을 결정하는 것은 당신의 몫이다 ( --);; ㅌㅌㅌㅌ

위험 요소를 줄이는 것이 위대한 소프트웨어를 만드는데 도움이 된다.

-핵심 정리(응? 뭘 했다고?)-

• 아키텍처는 모든 다이어그램, 계획, 특징 리스트 들을 잘 정돈된 애플리케이션으로 만드는데  도움을 줍니다
• 프로젝트에 매우 중요한 시스템의 특징들은 아키텍처적으로 중요합니다.
• 시스템의 본질인 특징, 의미가 명확하지 않은 특징, 또는 처음에 어떻게 구현해야할지 명확하지 않은 특징에 초점을 맞추세요
• 프로젝트의 아키텍처 설계 단계에서 하는 모든 일은 프로젝트 실패의 위험을 줄여야합니다.
• 유스케이스의 세부 사항이 필요하지 않을 경우, 소프트웨어가 어떻게 이용될 수 있는지를 설명하는 시나리오를 작성하면 요구사항을 빠르게 수집하는데 도움이 됩니다
• 특징이 무엇인지 확실히 모를 때, 고객에게 묻고, 그런 후 얻은 답을 일반화하여 특징을 잘 이해하도록 합니다
• 공통점 분석을 사용해서 유연한 소프트웨어 솔루션을 만드세요
• 고객은 여러분 생각에 정말 멋지게 자여진 코드에 관심이 있기보다는 그들이 원하는 일을 하고, 시간에 맞게 만들어지는 소프으웨어에 관심이 많습니다.

이번 강도 이렇게 마친다 -_-v
우왕이제 3강 남았다 >.< OOAD가 끝나면 자격증 시험 때문에 당분간 업데이트를 못할 것이다....;;;
OOAD가 끝나면 디자인 패턴, 자료구조, TCP/IP, 리눅스, 델파이 중 하나를 연재할까한다~

헤드퍼스트 OOAD - 6강

이번 강은 큰 프로그램을 만들려면 어찌해야 하는지에 대한 강좌다.

일단 기본적인 것은 같다.

1. 나의 소프트웨어가 고객이 원하는 기능을 하도록
2. 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 만들기
3. 유지보수와 재사용이 쉬운 디자인을 위해 노력하기

큰 프로그램을 만들려면 일단 기능별로 나누어서 각 조각들을 개별적으로 풀어가며 해결한다.

변하는 것을 캡슐화하여 프로그램을 더 유연하고 변경하기 쉽게 만단다.

구현에 맞추어 코딩하는 것보다 인터페이스에 맞추어 코딩하면 소프트웨어 확장이 더 쉽다

변경과 확장이 쉽고 고객이 원하는 일을 한다.
--------------------------------------------------------------------------------
큰 프로그램은 많은 정보가 필요하다.
고객과 많은 미팅을 통해 많은 정보를 얻어내야 한다.
그러기 위해선 특징을 먼저 찾아야 한다.

하지만 고객은 프로그래머가 아니다.
서로 소통을 하기 위해서는 유스케이스 다이어그램을 쓴다.

유스케이스 다이어그램은 특별히 다른 것이 아니다

프로그램을 잘 모르는 사람들에게 프로그램을 설명하기 위한 그림이다.

그림으로 설명하는 것이 글씨로 설명하는 것보다 가독성도 좋고 빠르게 이해되기 때문이다.

그림으로 설명 뒤에는 도메인 분석을 해서 고객이 실제로 이해를 했는지 설명하는 것이다.

이쯤에서 도메인 분석이란?
기존 시스템과 개발 이력, 도메인 전문가들로부터 얻은 지식, 기반 이론, 그리고 도메인에서 새로 등장하는 기술을 기반으로 도메인 관련 정보를 찾아내고, 모으고, 구조화하고, 나타내는 프로세스

라고 한다 ㅡㅡ (뭔 소리여 이게)

고객들은 객체가 어쩌구 클래스가 어쩌구는 뭔소린지 모른다.
그리고 큰 프로그램은 너무 크기에 기능별로 나누어서 설명하는 것이다.

예를 들면 스타크래프트3를 만든다고 하면

유닛, 종족, 기능, 배경, 스토리, 컨트롤, UI 등등으로 나누어서 설명을 한다는 것이다.

스타크래프트3라는 게임이 있고 그 안에 각 특성이 있는 것을 나누어 설명하는 것이다.

이렇게 나누는 것은 프로그래밍을 모르는 디자이너나 영업사원들에게도 설명할 때 유용하다.

MVC 패턴은 유명한 패턴이다.

모델 뷰 컨트롤러를 나누어 구현하는 것인데.

스타크래프트3로 설명하자면.....(아직 나오지도 않은걸??)

뷰는 종족, 배경을 그래픽으로 보여주는 부분이고

모델은 각 유닛의 기능들(마린이 총쏘고, 뮤탈이 변신하는 등등)

컨트롤러는 게임 전체를 제어하고(200개의 유닛이상 못만들게 한다던가, 지도 밖을 못나간게 한다던지....)

해서 각자 자신의 일만 하면 되는 분업이라고 할 수 있겠다.

각자 다른 분야에서 협업하려면 공통된 자료가 있어야 하는데 그것이 바로 아까 말한 도메인 분석이다.


이번 강은 이게 다다 ㅡㅡ;;;(때리지마)

이게 뭐야!!! (미안 ㅌㅌㅌㅌ)