'개발'에 해당되는 글 188건

  1. 2008.10.14 RED5
  2. 2008.10.14 REST [ representational state transfer ]
  3. 2008.10.08 BPR (Business Process Re-engineering)
  4. 2008.10.08 관리기법1
  5. 2008.10.02 TortoiseSVN 설치 및 사용방법
  6. 2008.10.01 엑셀함수활용콘사이스145.rar
  7. 2008.10.01 JUnit 을 이용한 단위 테스트
  8. 2008.10.01 클래스 다이어그램 3
  9. 2008.10.01 유스케이스(Usecase) 다이어그램 1
  10. 2008.10.01 UML의 구성
2008. 10. 14. 16:50

RED5




(주)웹호스트 http://www.webhost.co.kr

이 문서는 rhel4에서 테스트되었다.

1. red5란 무엇인가?

flash player 중간스트리밍이 가능하도록
리눅스서버에 설치하는 스트리밍 프로그램이다.

2. 설치과정

Installing Red5, version 0.4.1 takes 4 steps
  1. Installing the Java 1.5 JDK
  2. Installing Apache Ant.
  3. Setting the wright Path Variables
  4. Installing Red 5


First of all, you will need to be logged in as root. Were using bash as shell


Step 1. Installing the Java 1.5 JDK

jdk-1_5_0_14-linux-i586.bin

최신버전을 받는다. 리눅스용중에서 rpm자동설치버전을 받아라.

./jdk-1_5_0_14-linux-i586-rpm.bin
자동설치된다.

주의) 설치전
rpm -qa|grep jdk
rpm -qa|grep java
등 해서 모두 제거한다.

기본설치가 되면, rpm 으로 설치된다.

jdk-1.5.0_14-fcs

/usr/java/jdk1.5.0_14


#vi /etc/profile


맨 밑에

JAVA_HOME=/usr/java/jdk1.5.0_14  #자바가 설치된 위치입니다.
export JAVA_HOME
PATH=$PATH:$JAVA_HOME/bin
CLASSPATH=$CLASSPATH:$JAVA_HOME/lib


이런식으로 저장

#source /etc/profile

설치 끝
텔넷사용시, 로그아웃하고나서 다시로그인할 것
java -version
으로 버전확인할 것


Now let's check the Java version:

[root@hostname ~]# java -version
It should read something like this:
java version "1.5.0_14"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)

Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
OK 설치성공

That was step 1. Still here? let's go to step 2

Step 2. Installing Apache Ant.

드디어, 2장으로 돌입한다.

[root@hostname ~]# cd /usr/local/
wget wget http://archive.apache.org/dist/ant/binaries/apache-ant-1.6.2-bin.tar.gz


[root@hostname ~]# tar xvzf apache-ant-1.6.2-bin.tar.gz
rename the dir to ant
[root@hostname ~]# ln -s apache-ant-1.6.2 ant














압축풀고, 이름바꾼후에 /usr/local/ant 로 링크시킨다.

1.7.0 에 문제가 있는 것 같음. ant는 버전을 테스트해보고 설치할 것.


















ant의 문제는 ant server & 로 할경우 데먼이 올라오지만,
ant 만 실행하면 에러가 남. 1.7.x대역은 데먼이 제대로 실행안됨.
이 부분은 좀 더 연구해 봐야 할 문제













Step 3. Setting the wright Path Variables.





3장 진입


If you'll be running Red5 as root (which you shouldn't) you can add the paths to /root/.bash_profile
otherwise you can add them to /etc/profile add these two lines:

 
즉,
vi /etc/profile
한 다음,

export ANT_HOME=/usr/local/ant
export PATH=$ANT_HOME/bin:$PATH


이렇게 2줄 추가하고
저장한 후
#source /etc/profile





ant 설치 끝





 






Step 4. Installing Red5.




red5 설치하기  http://osflash.org/red5 -> wget http://dl.fancycode.com/red5/0.6.3/src/red5-0.6.3.tar.gz







download Red5




[root@hostname ~]# adduser red5

새 사용자 계정을 만든다. 예를들어 red5라고 하자. 이 아이디로는 flv동영상을 올리게 된다.
cd ~red5
[root@hostname ~]# tar zxf ~/red5/red5-0.6.3.tar.gz

이제 최신버전 다운로드한 것을 푼다.


red5-0.6.3
[root@www red5]#

[root@www red5-0.6.3]# ls
build.properties  doc            ivy.xml      Makefile        red5_debug.sh      red5-shutdown.bat  swf
build.xml         dumps          lib          red5.bat        red5-highperf.bat  red5-shutdown.sh   test
conf              ivyconfig.xml  license.txt  red5_debug.bat  red5.sh            src                webapps
[root@www red5-0.6.3]#




이제 설치하자

ant server &

이 명령으로 red5가 있는 위치를 기본으로 설치가 시작됨
약 15분간 진행됨.


/etc/rc.d/init.d/red5 스크립트 작성

#! /bin/sh
#
# Author: Jake Hilton <red5@jakehilton.com>
# /etc/init.d/red5
#
# Check for missing file
RED5_DIR=/home/red5/red5-0.6.3/
test -x $RED5_DIR/red5.sh || exit 5


case "$1" in
    start)
        echo -n "Starting Red5 Service"
        echo -n " "
        cd $RED5_DIR
        su -s /bin/bash -c "$RED5_DIR/red5.sh &" root
        sleep 2
        ;;
    stop)
        echo -n "Shutting down red5"
        echo -n " "
        su -s /bin/bash -c "killall -q -u red5 java" root
        sleep 2
        ;;
    restart)
        ## Stop the service and regardless of whether it was
        ## running or not, start it again.
        $0 stop
        $0 start
        ;;
esac

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

굵은 부분은 중요하니 알아서 수정할 것



스크립트 구동

/etc/rc.d/init.d/red5 stop
/etc/rc.d/init.d/red5 start





테스트해보기


[root@www red5-0.6.3]# telnet localhost 1935
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
[WARN] 39168 mina-1:( org.red5.server.net.rtmp.RTMPMinaIoHandler.sessionOpened ) Is tcp delay enabled: false

접속성공함

^] 키보드 Ctrl+] 입력
telnet> quit
Connection closed.
[root@www red5-0.6.3]# [DEBUG] 64717 mina-4:( org.red5.server.BaseConnection.close ) Close, not connected nothing to do.


[root@www red5-0.6.3]#

[root@www red5-0.6.3]# ps -ax|grep red5
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.3/FAQ
18535 pts/0    Sl     0:01 /usr/bin/java -cp red5.jar:conf: org.red5.server.Standalone
18596 pts/0    S+     0:00 grep red5
[root@www red5-0.6.3]#

[root@www red5-0.6.3]# netstat -an|more
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State     
tcp        0      0 0.0.0.0:8001                0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:995                 0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:110                 0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:1935                0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:21                  0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:5080                0.0.0.0:*                   LISTEN     
tcp        0      0 0.0.0.0:8088                0.0.0.0:*                   LISTEN     
tcp        0    104 116.197.138.27:22           211.187.59.252:4231         ESTABLISHED
tcp        0      0 127.0.0.1:35137             127.0.0.1:5080              FIN_WAIT2  
tcp        0      0 127.0.0.1:5080              127.0.0.1:35137             CLOSE_WAIT 



1935포트가 정상적으로 LISTEN중이다.







이제 플레이어를 설치하자.


flash_media_player.zip 첨부한 파일 참고

파일을 풀어서 서버에 올림


drwxrwxrwx  2 root root   4096 Jul 30 18:48 extras
-rwxrwxrwx  1 root root  20920 Apr  8  2005 image.jpg
-rwxr-xr-x  1 root root    754 Jan  5 04:08 mediaplayer.html
-rw-r--r--  1 root root  35041 Dec 18 06:56 mediaplayer.swf
-rwxrwxrwx  1 root root  81222 Dec 27  2006 movie.swf
-rwxrwxrwx  1 root root    343 Jan  5 04:35 playlist.xml
-rwxrwxrwx  1 root root  10055 Feb 10  2007 preview.jpg
drwxrwxrwx  2 root root   4096 Apr 18  2007 readme
-rwxrwxrwx  1 root root  47024 Aug 11  2005 song.mp3
drwxrwxrwx  3 root root   4096 Dec 18 06:58 source
-rwxrwxrwx  1 root root   6880 Mar  1  2007 swfobject.js
-rw-r--r--  1 root root    305 Jan  5 04:37 test.html
-rwxrwxrwx  1 root root 282797 Aug 11  2005 video.flv
[root@www public_html]# pwd
/home/red5/public_html
[root@www public_html]#


/home/red5/public_html 이라고 가정함.

풀어서 올린결과

이 플레이어는 rtmp://를 지원한다.

mv mediaplayer.html index.html


아파치 virtual 셋팅
<VirtualHost *:80>
    DocumentRoot /home/red5/public_html
    ServerName red5.도메인.com
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /home/red5/red5-0.6.3
    ServerName red5rtmp.도메인.com
</VirtualHost>


2개를 동시에 만든다.

왜냐? 해당폴더에 접근이 가능해야 하기때문이다.
아래것은 rtmp://도메인명:1935/oflaDemo/file.flv 형태로 접근하기 위한 것



vi index.html 수정

------------------------------------------
<html>
<head>



<script type="text/javascript" src="swfobject.js"></script>



</head>
<body>



<h3>single file, with preview image:</h3>



<p id="player2"><a href="http://www.macromedia.com/go/getflashplayer">Get the Flash Player</a> to see this player.</p>
<script type="text/javascript">
        var s2 = new SWFObject("mediaplayer.swf","playlist","640","480","1");
        s2.addParam("allowfullscreen","true");
        s2.addVariable("file","playlist.xml");
        s2.addVariable("displayheight","380");
        s2.addVariable("backcolor","0x000000");
        s2.addVariable("frontcolor","0xCCCCCC");
        s2.addVariable("lightcolor","0x996600");
        s2.addVariable("width","640");
        s2.addVariable("height","480");
        s2.write("player2");
</script>




</body>
</html>
-----------------------------------------------------------



vi playlist.xml수정
------------------------------------------
<?xml version="1.0" encoding="utf-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
        <trackList>


                <track>
                        <title>FLV Test 2</title>
                        <creator>Postman</creator>
                        <location>rtmp://red5rtmp.도메인.com:1935/oflaDemo/</location>
<identifier>Transformers.flv</identifier>
<meta rel="type">rtmp</meta>
                </track>


        </trackList>
</playlist>
------------------------------------------------

여기가 중요함


[root@www streams]# ll
total 19980
-rw-r--r--  1 root root 4546420 Sep 11 14:31 IronMan.flv
-rw-r--r--  1 root root 8446642 Mar 15  2007 on2_flash8_w_audio.flv
-rw-r--r--  1 root root 7405850 May 19  2007 Transformers.flv
[root@www streams]# pwd
/home/red5/red5-0.6.3/webapps/oflaDemo/streams
[root@www streams]#


이 속에 존재하는 파일중에 연결한다.


rtmp://주소는 oflaDemo/폴더까지만 적어준다.



이제 테스트해보자

http://red5.도메인.com

했을때, 플레이가 되면 끝남





(주)웹호스트 작성 http://www.webhost.co.kr

작성 : 2008년 1월4일

2008. 10. 14. 14:28

REST [ representational state transfer ]




확장성 생성 언어(XML) 파일로 된 웹 페이지를 읽어 원하는 정보를 수집하는 기능. 웹 페이지를 만드는 사람은 주기적으로 내용을 개정하고 사용자는 그 페이지의 URL만 알면 웹 브라우저로 읽어 정보를 얻을 수 있다. 하이퍼텍스트 전송 규약(HTTP)과 XML을 포함한 웹 기술 및 프로토콜을 사용하는 구조적 형태로서 단순 객체 접근 프로토콜(SOAP)보다 사용이 간편하고, 사이트 내용을 기술하는 RSS(RDF Site Summary)의 정보 편집 기능과 유사하다. RSS는 자원 기술 개념(RDF)을 사용한다.
2008. 10. 8. 14:23

BPR (Business Process Re-engineering)




BPR[비피알]은 1990년대 초 미국에서 제창한 개념으로서, 사업활동을 영위하는 조직의 측면에 있어, 작업을 개선하고 자원의 사용을 보다 효율적으로 만들기 위하여, 하나의 목적으로 처음부터 다시 근본적인 변화를 만드는 것을 의미한다. BPR은 업무 프로세스의 근본적인 재고(再考)가 수반되며, 원가, 서비스품질, 직원들의 활력 등과 같은 중대한 지표들이나 또는 그 모두를 강화하기 위한 업무활동의 재설계로 이어진다. 일반적으로 BPR의 개념에는 데이터를 조직화하고, 방향을 설정하기 위하여 컴퓨터정보기술을 사용하는 것이 포함된다.

2008. 10. 8. 11:52

관리기법1





관리기법/1

 

(1) 개요 

관리기법/1 시스템 개발의 단계 , 계획수립에서 분석 설계, 설치 운용까지를 지원하는 시스템개발방법론이며 시스템 개발 운용 관리, 품질보증활동 등을 지원하는 프로젝트관리 방법론이다. 

 

 

(2) 구성체계

 

관리기법/1 개발경로, 작업 오브젝트, 기법 3개의 주요 구성요소로 이루어 진다.

 

1) 개발경로

 

개발 경로는 다음과 같이 정의된다.

·         일련의 시스템 개발 또는 유지관리와 관련된 활동으로

·         이러한 활동 태스크는 다음과 같다.

-        특정한 목적을 갖는다.

-        작업을 완료할 생성, 검토, 또는 갱신할 작업 오브젝트 또는 전달물을 지시한다.

-        전형적으로 작업을 수행할 직능 유형을 정의한다.

 

이러한 정의에 따라 관리기법/1에서는 프로젝트의 규모, 기술적 범위,  업무절차를 고려하여 주요 개발경로로 정보계획수립, 클라이언트/서버 시스템 개발, 호스트 시스템 개발, 패키지 시스템 개발, 소규모 프로젝트 개발, 고속개발로 나눈다.

 

·         정보 수립계획전략적 업무 필요 기술 요건을 파악하고 정의한다.  또한 개별적인 프로젝트 수준에서 계획수립을 다룬다.

·         클라이언트/서버 개발클라이언트/서버 환경에서 분산되고 협동적인 처리를 요구하는 정보 시스템을 위한 것이다. 경로에서는 새로운 구성요소를 생성하는 방법과 필요한 경우 기존의 시스템을 통합하는 방법을 제공한다.

·         호스트 개발기존의 호스트 환경에서 전통적인 온라인 처리를 요구하는 정보 시스템을 위한 것이다.

·         패키지 시스템 개발시중의 소프트웨어로 충족될 있는 업무 그리고 정보 요구를 위한 것이다.  가용한 소프트웨어 패키지를 평가하고 선정하며 필요한 경우 표준 또는 요구사항을 충족시키도록 사용자화하여 설치하는 절차들이 포함된다.

·         소규모 프로젝트 개발클라이언트/서버 개발과 호스트 개발 경로의 부분 집합이다.  경로의 범위는 넓은 방법론(클라이언트/서버와 호스트 개발 경로와 같은) 소규모의 고속 개발 접근방법 사이에 있다.

·         고속 개발소규모 프로젝트 팀으로 3개월에서 6개월의 기간 동안에 고품질의 응용 시스템을 구축하는 것이다.  팀은 JAD(joint application development), 타임박스, 프로토타이핑과 같은 특정한 기법을 적용하여고속으로 수행한다.

·         시스템 운용 관리사용자에게 최소한의 혼란으로 시스템 수정이 효과적으로 관리되고 구현되는 것을 보장한다.

 

또한 관리기법/1에서는 이러한 개발경로와 관련되어 프로젝트 관리, 기반구조 관리를 제공한다. 

·         프로젝트 관리수행중에 있는 업무의 계획이나 관리, 기술이나 경험을 적절하게 섞어서 결합하는 , 업무의 진행과 질을 감시하는 등과 같이 핵심적인 프로젝트 기능을 규정한다.

·         기반구조 관리 - 응용개발 환경과 아키텍쳐를 지원하는 방법론을 제공한다.

 

 

2) 개발기법

 

관리기법/1에서는 개발경로에서 진행되는 분석, 설계, 프로젝트 관리, 품질, 기반구조 관리를 지원하기 위하여 개발기법을 제공한다.

 

 

3) 작업 오브젝트

 

작업 오브젝트란 방법론에서 어떤 작업을 완수하기 위해 작성하고 참조하며 관리하게 되는 전달물이며 시스템에 관한 지식의 집합이다. 작업 오브젝트는 다음 태스크에 필요한 입력사항이 되며 프로젝트 팀간에 활용을 위하여 리포지터리에 저장되어 관리되는 것이 바람직 하다. 

 

관리기법/1에서는 개발자가 표준양식에 따라 작성하는 전달물로써 작업 오브젝트에 대한 샘플을 제공한다.

(3) 구조

 

관리기법/1 개발경로들로 나뉘어 지는데, 개발경로들은 단계와 세그먼트 태스크의 가지 유형의 항목으로 구성된다. 개발경로들은 프로젝트의 업무 범위와 기술적 요소, 자원 요소에 의해 정의된다. 단계 관리기법/1에서 최고 수준의 항목이다. 단계는 방법론 계층에서 다음 수준의 세부사항을 나타내는 세그먼트 나뉘어진다. 세그먼트는 태스크 나뉘어 진다.  태스크는 계층에서 최하위 수준이다.

세그먼트와 태스크가 작업 오브젝트와 전달물을 만드는 실제 활동들이다.


관리기법/1

 

   관리기법/1에서 제공하는 단계중 클라이언트/서버 개발 단계가 대규모 프로젝트를 기준으로 전체 경로들을 포함하고 있으므로, 클라이언트/서버 개발 단계를 보고서의 분석에 이용한다.

 

   클라이언트/서버 개발경로에서는 새로운 시스템의 요건을 계통적으로 조직화하고 이러한 요건에 맞도록 시스템을 설계하고 시스템을 구축, 시험, 전개하는 세그먼트들을 포함한다. 여기에는 아키텍쳐(개발, 실행, 운용) 설계하고 구축, 시험하며 전환하는 세그먼트도 포함된다.

 

 

 

관리기법/1 클라이언트/서버 개발경로 세그먼트 분석

 

 

   클라이언트/서버 개발경로 분석 설계, 개발, 설치 단계에 해당되는 세그먼트들은 다음과 같다.

 

1) 사용자 요구사항

 

사용자가 필요로 하는 요구사항과 새로운 시스템이 운용될 새로운 전반적인 업무 흐름 조직을 이해하고 문서화한다. 또한 프로젝트팀은 사용자의 요구사항과 아울러 기존 시스템과 새로운 시스템의 차이를 찾아 새로운 시스템의 관점에서 필요한 변경사항과 변경되지 않을 구성요소들을 식별한다.

 

개발기법 - JAD, 면담

 

2) 품질요건

 

시스템이 기능을 얼마나 성공적으로 수행해낼 있을 것인가를 기술한다. 일반적으로 성능, 신뢰성, 사용성, 유연성 등의 품질요건을 분석하여 측정 방법과 목표치를 정한다. 또한 품질요건들 간에 상충되는 사항이 있는 경우에는 예산, 구현일정 등을 고려하여 품질요건의 순위를 정한다.

 

3) 요구사항 분석

 

사용자요구사항 세그먼트에서 분석된 사항들을 사용자와 프로젝트팀 모두가 이해하고 확인할 있도록 업무프로세스의 프로토타입을 작성하고 이벤트 모델, 데이터 모델, 프로세스 모델을 통하여 요구사항 모델을 공식화 한다.  

 

4) 업무절차 설계

 

사용자 관점에서 신규 시스템의 모습을 정의하는 세그먼트로 주요 활동은 대화설계, 윈도우와 기타 입출력 설계, 상세한 작업 흐름을 정의한다.

 

5) 기술설계

 

세그먼트는 응용 아키텍쳐의 정의 작업부터 시작된다. 요구사항을 기술적 아키텍쳐의 구성요소에 대응시키는 작업과 시스템의 상세한 구성요소를 설계하는 필요한 표준과 지침을 마련하는 전반적인 설계 결정이 포함된다. 다음 단계로 데이터와 프로세스를 네트워크 전체에 분산시키고, 프로그램을 모듈단위로 구분하고, 프로그램간과 모듈간의 메세지를 설계 외부시스템과의 인터페이스 설계를 한다. 데이터 모델은 일단 논리 데이터베이스로 변환시킨 물리 데이터베이스 설계로 변환시킨다. 마지막으로 IS운용 필요사항이 고려된다.

 

6) 품질검증

 

사용자와 기술 담당자가 모든 기능 요건이 설계 내용에 모두 포함되어 있으며 목표로 하는 품질요건을 충족시킬 있을 지에 대해 검증한다. 세그먼트에서는 프로토타이핑되거나 시험될 있는 품질속성인 사용성과 성능에 특히 주의를 두어야 한다. 

 

7) 전환설계

 

시스템을 운용하는데 필요한 활동 , 사용자 교육, 데이터베이스 변환, 시험 전개 등에 관한 활동들을 계획 한다.

 

8) 아키텍쳐 설계 프로토타입

 

세그먼트의 초점은 아키텍쳐 설계이다. 아키텍쳐에 대한 개념 설계를 검증, 갱신하고 공급업체 제품을 재검토한 권고안을 작성한다. 실질적인 프로토타이핑 시험에서는 응용에서 요구하는 모든 요건들을 아키텍쳐가 충족시키는지를 확인한다.

 

9) 아키텍쳐 구축 시험 

 

프로젝트 팀은 아키텍쳐 구성요소를 구축하고 시험한다. 아키텍쳐 개발 프로세스는 아키텍쳐 개발자들과 공동으로 아키텍쳐 구성요소, 도구, 표준 등의 베타 테스트를 수행함으로써 시스템 개발환경이 성능에 대한 요구사항을 모두 만족시키고 있는지를 확인한다.

 

10) 상세 설계

 

이전 세그먼트에서 시작되었던 설계 작업을 완료하고, 작업 단위에 대한 상세한 문서를 작성한다. 또한 프로그래밍 작업단위의 논리 데이터 뷰와 물리 데이터베이스를 작성하고 설계검토를 실시한다. 마지막으로 컴파일 단위를 시험하는 사용할 있는 공통 시험데이터를 마련한다.

 

11) 사용자 절차 교육

 

프로젝트 팀은 시스템을 지원하는 성능, 보안, 제어, 컴퓨터 운용 기능들에 대해 사용자 절차를 작성한다. 아울러 입력문서, 출력양식 등에 대한 설계를 마무리 짖고 사용자절차, 보안절차, 제어절차에 대한 상세한 내용을 묶어 사용자 설명서를 작성한다. 또한 프로젝트팀은 사용자 설명서 절차로부터 필요한 교육용 자료와 강사용 자료를 작성한다. 프로젝트 팀은 교육에 대해 파일럿 시험이나 검토회를 하는 절차를 수행하여 교육이 효율적으로 구성되어 있는지를 확인한다. 

 

12) 시스템 시험 전개 계획 수립

 

프로젝트 팀은 새로운 시스템을 사용자에게 어떤 방식으로 전개 실시할 것인지에 대한 방안을 마련한다. 이와 같은 작업에 따른 복잡도와 작업에 의해 발생되는 필요 자원 인원 등은 시스템이 어떤 방식으로 분산되어져 있는지와 변환 작업을 여러 사이트에서 반복해서 실시해야 하는지의 여부에 따라 좌우된다. 아울러 프로젝트 팀에서는 시스템이 당초 원했던 바대로 작동하는 지를 시험하기 위한 시스템 시험계획과 시스템이 정상적으로 작동하는 지를 확인하기 위한 시험데이터와 예상 결과를 포함하고 있는 시스템 시험모델도 마련한다. 

 

13) 프로그래밍

 

코딩이란 프로그래밍 작업 단위를 컴퓨터가 실행할 있는 형태로 변환하는 작업을 의미한다. 프로그래밍 언어를 이용하여 코드를 작성하고, 코드제너레이터 도구에 입력되는 규격을 작성하며, 업무 제어문을 작성하는 등이 여기에 포함된다. 다음에는 결과를 점검하고 문법상의 오류를 제거한다. 코드를 작성했던 프로그래머와 프로그래밍 업무 단위를 설계했던 분석 담당자, 그리고 가능하다면 명의 추가 프로그래머가 코드를 재검토한다.

 

프로그래머는 주로상세 설계세그먼트에서 개발된 공통 시험 데이터에 따라 완벽하게 시험하기에 충분한 시험 데이터를 준비하고 단위 시험을 통해 코드에 오류가 없는지 확인한다. 프로그래머는 시험 결과를 예상 결과와 비교 점검하고 에러를 수정한다.

프로젝트팀 구성원들이 프로그램을 완전히 시험하고 났을 , 같은 스트링(string)내에 있는 접속 프로그램들과 부분 시험을 실시한다.  이는 프로그램간의 통신을 검증하고시스템 시험세그먼트의 통합 시험으로 이어진다. 세그먼트에서, 프로젝트팀은 프로그래밍을 지휘, 통제하고, 시험을 조정함으로써 코딩 작업을 지원한다.

 

14) 시스템 시험

 

프로젝트팀은 시스템 운용으로 가기 전에 시스템 시험 기간 동안 신규 시스템을 시험할 책임이 있다.  프로그래밍으로부터 이루어진 구성을 시험하고 결과를 재검토한다.  그런 , 통합 시험을 실시하고 시스템의 성능을 확인하여 필요하다면 변경을 수행한다. 또한 결과를 조사하여 결함이 있다면 수정해 준다. 마지막으로, “품질 보증검토를 포함한 사용자 시험을 실시하여 시스템이 사용자가 기대한 대로 성능을 수행하는지 확인한다.

 

15) 전개준비

 

프로젝트팀에서는 신규 시스템을 전개하기 전에 필요한 모든 작업을 완료한다.  교육팀에서는 시스템을 사용할 요원을 교육하고 교육 결과에 대한 피드백을 받아 교육 프로그램에 반영한다. 프로젝트팀은 구축에 따른 비용 산정, 구축 완료 일정 책임/의무조항, 하드웨어 소프트웨어 전달을 포함하여 신규 사이트에 필요한 모든 조치를 취해야 한다. 마지막으로, 프로젝트팀은 기존 데이터베이스와 소스들에 들어 있는 데이터를 변환시켜 준다.

 

16) 시스템 전개

 

성공적인 전개를 위해서는 신규 프로그램이나 절차를 사용하는 이상의 것이 관련된다.  작업 환경은 신규 시스템만을 반영해야 한다.  시스템의 나머지는 반드시 제거해야 한다.  프로젝트팀은 시스템을 재검토하고 분석하여 설계서에 명시된 기능을 수행하는지 검증한다.  마지막으로, 프로젝트 팀은 신규 시스템이 사용자와 업무상의 요구사항과 작업요건에 더욱 적합하게 하기 위해 시스템의 운용 초기에 행한 변경사항이나 향상된 점을 문서화하여 향후 재구현시 반영할 있도록 해야 한다.

 

  


 

 



 

세그먼트

태스크

산출물

전개 준비

인원교육 훈련

교육 자료

필수

필수

필수

장소 준비

네트워크 환경 설명,

하드웨어 환경 설명

필수

필수

선택

변환화일 작성

변환 계획, 변환절차

필수

필수

선택

시스템 전개

 

준비시험 실시

시험 접근 방법

필수

필수

필수

장소변환

유지관리 지침서

필수

필수

필수

운용감독

변경요청, 성능 모델,

요구사항 설명

필수

필수

필수

개선사항 문서화

변경요청

필수

필수

필수


(2) 시스템 유형별

 

다음은 순수 S/W개발과 SI사업인 경우의 비교 이다.

 

세그먼트

태스크

세부 산출물

S/W

SI

사용자

요구사항

작업흐름 조직확인

엔티티관계도, 작업 흐름도, 조직도,

조직별 프로세스

필수

필수

사용자 요구사항 파악

면담 비망록, 요구사항 설명,

현행 시스템 설명

필수

필수

현행설계 복구

관계유형 설명, 엔티티 유형설명,

속성유형설명, 요구사항 설명

필수

필수

품질요건

품질요건 파악

품질속성 설명, 품질지침 기준

필수

필수

척도 목표구축

품질속성 설명

필수

필수

요건분석

 

업무절차 프로토 타입

업무처리 프로토타입, 쟁점 및 미결사항

필수

필수

이벤트 모델작성

이벤트별엔티티 매트릭스

엔티티 순기도, 이벤트-자극-반응 설명

필수

필수

프로세스 모델작성

업무기능 분해, 데이터흐름도,

기본절차 설명

필수

필수

데이터 모델작성

속성유형설명, 영역설명,

엔티티유형설명, 엔티티관계도,

관계유형 설명

필수

필수

업무절차 설계

다이얼로그 설계완료

다이얼로그 흐름도, 윈도우 설명,

프로젝트 표준

필수

필수

윈도우 화면설계

다이얼로그 흐름도, 아이콘설명,

리스트 상자설명, 메뉴항목 설명,

푸쉬버튼설명, 윈도우설명

필수

필수

보고서 문서설계

보고서 설명, 서식설명

필수

필수

작업흐름 정의

사용자 문서 윤곽, 작업 흐름도

필수

필수

기술설계

응용아키텍쳐 정의

응용구조, 응용흐름, 쟁점 미결사항,

프로젝트 표준,

시스템 아키텍쳐 보고서,

필수

필수

네트워크를 통한

데이터및 프로세스

분산

작업/프로세스별 엔티티,

위치 유형별 엔티티,

위치유형별작업/프로세스,

프로젝트 표준

필수

필수


 

세그먼트

태스크

산출물

S/W

SI

기술설계

메시지 프로세스 흐름정의

응용흐름, 화일설명,

실행프로그램 설명, 메시지 설명,

서버설명,

필수

필수

논리데이타베이스

설계

데이터 요소설명, 화일설명,

외부키 설명, 논리데이타베이스 다이어그램, 일차키 설명, 레코드 설명,

관계형 테이블 설명,(View)설명, 

필수

필수

자동화 프로세스

설계

콜 패턴, 실행프로그램 설명,

메시지 설명, 모듈설명, 절차도,

레코드 설명, 서버설명

필수

필수

기술설계

시스템 접속설계

레코드 설명, 메시지 설명, 변경 요청

필수

필수

IS 운용프로세스

설계

 

 

 

물리데이타베이스

설계

화일설명, 색인설명, 레코드 설명,

관계형 테이블 설명,

테이블 스페이스 설명

필수

필수

품질검증

기능완성도 검증

변경 요청, 기능완성도승인

필수

필수

품질속성 시험

검증

변경 요청, 성능모델, 품질요건승인

필수

필수

전환설계

 

교육과목 계획수립

교육과목

필수

필수

시험접근방법 설계

시험 접근 방법

필수

필수

전개구성 설계

응용릴리즈 계획, 응용구조, 변경 요청

필수

필수

데이터변환절차 설계

응용흐름, 변환매핑, 실행프로그램설명, 논리데이타베이스 설명, 레코드 설명, 모듈설명, 서버설명, 변경요청

필수

필수

아키텍쳐 설계 프로토타입

아키텍쳐방향 확인

프로세싱 환경 요약, 프로젝트 표준,

시스템 아키텍쳐 보고서,

선택

필수

H/W 시스템 S/W선정

계약서, 프로젝트 표준, 시스템 아키텍쳐 보고서(네트워크 환경설명, 시스템 소프트웨어 설명, 하드웨어 환경설명)

선택

필수

아키텍쳐설계 프로토타입

시스템 아키텍쳐 보고서(개발아키텍쳐, 실행아키텍쳐, 운용아키텍쳐, 아키텍쳐프로토타입 결과), 프로젝트 표준

선택

필수

세그먼트

태스크

산출물

S/W

SI

아키텍쳐

구축

시험

아키텍쳐구축

시험

응용흐름, 실행프로그램 정의, 예상결과,  프로젝트 표준, 서버설명, 시험조건, 시험주기 통제표, 시험주기 흐름

선택

필수

응용구축 프로세스

시범

프로그램 사양, 프로젝트 표준

선택

필수

성능 벤치마크 실시

벤치마크 보고서

선택

필수

상세설계

기술설계 완료

콜패턴, 대화 흐름 설명,다이얼로그 흐름도, 실행 프로그램 설명,

아이콘 설명, 리스트 박스 설명,

메뉴 항목 설명, 메시지 설명,

모듈설명, 절차도, 푸쉬 버튼 설명,

레코드 설명, 화면 설명, 윈도우 설명

필수

필수

작업단위 설계

프로그램 사양

필수

필수

데이터베이스 설계

완료

화일설명, 색인 설명, 레코드 설명,

관계형 테이블 설명,

테이블 스페이스 설명

필수

필수

설계 검토 실시

설계검토 승인

필수

필수

공통시험 데이터

준비

시험 베이스 내용

필수

필수

사용자 절차 교육

절차 개발

도움말 텍스트 설명, 절차 지침서

필수

필수

사용자 지침서 작성

사용자 문서 윤곽. 절차 지침서

필수

필수

교육자료 작성

교육 과목, 교육 자료

필수

필수

시스템 시험 전개계획 수립

전개 변환계획

완료

변환계획, 변환 맵핑, 설치장소 계획,

설치장소 요건, 설치준비 체크리스트,

소모품 요건, 전개계획

선택

필수

변환절차 개발

변환 맵핑, 변환절차, 절차지침서

필수

필수

시스템 시험 계획

수립

시험 조건, 시험주기 통제표,

시험 접근 방법

필수

필수

시스템 시험 모델 작성

예상 결과, 시험 베이스 내용,

시험 조건, 시험주기 통제표,

시험 작업 스트림

필수

필수

 

 

 

 

세그먼트

태스크

산출물

S/W

SI

프로그래밍

작업단위 생성 코딩

코딩된 작업 단위

필수

필수

시험데이타 준비

예상 결과, 시험 베이스 내용,

시험 조건, 시험주기 통제표

필수

필수

코드검토 실시

코드 검토 체크 리스트

필수

필수

단위 스트링

시험실시

서버설명,시험 베이스 내용,

코딩된 작업 단위

필수

필수

개발지원

작업단위 개발 통제

필수

필수

시스템 시험

구성진척

구성설명

선택

필수

통합시험 실시

통합시험 결과

필수

필수

사용자 시험실시

사용자 시험결과

필수

필수

상세결과 검토

변경요청, 시스템 조사요청

선택

필수

전개 준비

인원교육 훈련

교육 자료

필수

필수

장소 준비

네트워크 환경 설명,

하드웨어 환경 설명

선택

필수

변환화일 작성

변환 계획, 변환절차

필수

필수

시스템 전개

 

준비시험 실시

시험 접근 방법

필수

필수

장소변환

유지관리 지침서

필수

필수

운용감독

변경요청, 성능 모델, 요구사항 설명

필수

필수

개선사항 문서화

변경요청

필수

필수


(3) 고속개발

 

   관리기법/1에서는 고속개발을 위한 세그먼트와 태스크, 산출물을 제시하고 있다. 고속개발은 프로젝트를 짧은 시간대 내에서 구현할 필요가 있는 경우와 다음 특징이 있는 경우에 적용할 만하다.

 

· 반복구축(contruction through iterations) 위한 프로토타이핑과 분할(partitioning) 적용하여 클라이언트/서버 또는 GUI 같은 온라인 시스템을 지원

· 검증된 기술아키텍쳐 플랫폼, 이것이 기술적인 위험의 정도를 줄인다.

· 구축된 개발 환경은 템플릿(template) 개발 시험할 필요를 줄이고, 데이터요소 정의와 같이 재사용할 있는 리포지터리 오브젝트를 제공한다.

· 정규사용자(full-time users) 상세한 요구사항 검증을 지원하는 프로젝트에 할당된다.

 

세그먼트

태스크

산출물

 

분석

 

이벤트 모델작성

엔티티 순기도, 이벤트-자극-반응 설명, 이벤트별 엔티티

사용자 요구사항 파악

면담 비망록, 요구사항 설명,

현재 시스템 설명

척도 및 목표구축

 

업무절차 프로토 타입

업무처리 프로토타입,

쟁점 및 미결사항

프로세스 모델작성

기본절차 설명, 데이터흐름도,

업무기능 분해

데이터 모델작성

관계유형 설명, 엔티티관계도,

엔티티 유형설명,

구축

사용자 인터페이스 설계

다이얼로그 흐름도, 윈도우 설명,

프로젝트 표준,

위치 유형별 작업/ 프로세스

보고서 설명, 서식설명,

네트워크를 통한 데이터및 프로세스 분산

위치 유형별 엔티티, 위치 유형별 작업/프로세스, 작업/프로세스별 엔티티, 프로젝트 표준

메시지 및 프로세스 흐름정의

메시지 설명, 서버설명, 실행프로그램 정의, 응용흐름, 화일설명

 

 

 

세그먼트

태스크

산출물

구축

데이타베이스 설계

관계형 테이블 설명, 논리데이타베이스 설명, 데이터 요소설명, 레코드 설명, (View)설명, 외부키 설명,

일차키 설명, 화일설명

자동화 프로세스 설계

레코드 설명, 화일설명, 메시지 설명,

모듈설명, 서버설명, 실행프로그램 정의, 조직별 프로세스, 절차도, 콜 패턴

시험사례 준비

시험 베이스 내용, 시험 조건,

시험주기 통제표, 예상 결과

작업단위 생성 및 코딩

코드 작업 단위

단위 및 스트링 시험실시

서버설명,시험 베이스 내용,

코드 작업 단위

사용자 시험실시

사용자 시험결과

품질속성시험 및 검증

 

전개

절차작성 및 직원교육

 

통합시험 실시

사용자 시험결과

장소변환

유지관리 지침서

운용감독

변경요청, 성능 모델, 요구사항 설명

 

2008. 10. 2. 09:52

TortoiseSVN 설치 및 사용방법




TortoiseSVNSubversion이라는 버전 트롤 시스템을 위한 윈도우용 클라이언트 프로그램입니다. 여기서 버전 컨트롤 시스템이란 폴더 및 파일의 모든 수정 내역을 효율적으로 기록하고 관리하는 시스템을 의미합니다. 버전 컨트롤 시스템을 사용하면 언제든 예전에 수정하였거나 삭제한 파일을 다시 불러와 확인할 수 있습니다. 또한 여러 사용자가 동시에 파일을 열거나 수정할 경우 발생할 수 있는 모든 문제들도 처리하여 줍니다. TortoiseSVN은 이러한 버전 컨트롤 시스템을 사용자가 쉽게 사용할 수 있도록 윈도우의 쉘과 통합된 형태의 인터페이스를 제공하는 클라이언트 프로그램입니다. 게다가 자체적으로 로컬 서버의 기능도 가지고 있어 따로 Subversion 서버를 설치하지 않고도 사용할 있다는 장점을 가지고 있습니다. Subversion은 새로운 버전 컨트롤 시스템으로서 CVS라는 유명한 버전 컨트롤 시스템의 단점을 개선하여 CVS를 대체하기 위해 만들어진 프로그램입니다. 이 문서는 이러한 버전 컨트롤 시스템을 처음 사용하는 사용자가 TortoiseSVN을 사용하여 파일의 버전을 관리하고 여러 작업을 수행할 수 있도록 그 시작을 도와줍니다.
2008. 10. 1. 17:29

엑셀함수활용콘사이스145.rar

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.
2008. 10. 1. 16:26

JUnit 을 이용한 단위 테스트




유난히도 "버그"를 많이 발생시키는 프로그래밍 패턴때문에, 난 "버그양성소" 역할을 해왔었다. 그동안은 main() 메소드를 통해 클래스와 메소드를 테스트했는데, 그동안의 무식함을 반성하고자 제일 기본적인 JUnit에 대해서 알아보았다.

1. JUnit 이 뭐지?
JUnit 은 테스트 프레임워크 (툴) 이다.
한마디로, 정해진 형식에따라 test 메소드를 작성해 놓으면 자동으로 실행시켜주고 결과도 리턴해주는 놈이다.

그럼 기존 java 애플리케이션 [public static void main(String[] args)] 을 이용한 테스트와는 뭐가 다른가?
정해진 방법대로 작성해 놓으면  테스트 java 애플리케이션 안의 메소드를 호출하지 않아도 자동 실행해주기 때문에, 손이 덜 간다. 그리고, 테스트 Java 애플리케이션이 많을때 이것을 일일이 실행해야 테스트를 해야하는 반면, JUnit은 TestSuit 이라는 개념을 지원해 여러개의 Test 클래스들을 한꺼번에 실행해 볼수 있다.

2. JUnit 을 사용하려면 ?
다운로드 및 참고자료 : http://junit.sourceforge.net/

junit.jar 를 classpath에 추가 하기만 하면 된다.
Eclipse 에는 기본 플러그인으로 설치되어 있어 바로 사용가능하다.

3. 코드 작성법
  1) JUnit의 TestCase 를 상속하여 클래스를 생성한다.
  2) 메소드 실행전 초기화 부분은 setUp() 메소드에, 실행후 초기화는 tearDown() 에 기술한다.
  3) 각각의 테스트할 단위들을 testXXXXX() 로 작성한다.
  4) 각 메소드에 assertXXXX() 메소드를 삽입하여, 테스트의 성공 유무를 판가름한다.
      아래 조건을 만족하지 않으면 실패로 간주
         ex) assertEquals  : 같지 않으면 실패,

assertEquals - 같은지 비교
assertNull - null값을 리턴하는지 비교
assertNotNull - 인자로 넘겨받은 객체가 null인지 판정하고 반대인경우 실패로 처리한다.
assertSame - assertSame 은 expected 와 actual이 같은 객체를 참조하는지 판정하고
                       그렇지 않다면 실패로 처리한다.
assertNotSame - expected 와 actual이 서로 '다른' 객체를 참조하는지 판정하고, 만약
                       같은 객체를 참조한다면 실패로 처리한다.
assertTrue - boolean 조건이 참인지 판정한다. 만약 조건이 거짓이라면 실패로 처리한다.
fail - 테스트를 바로 실패 처리한다.

  
4. 코드샘플과 실행결과
   1) 코드 샘플

import junit.framework.TestCase;
import com.ilikeclick.fw.util.*;

public class testUtilClass extends TestCase
{
    private String testStr1 = null;
    private String testStr2 = null;
      
    public void setUp()
    {
        System.out.println("setUp()");
    }
   
    public void tearDown()
    {
        System.out.println("tearDown()\n");
       
        testStr1 = null;
        testStr2 = null;
    }
   
    public void testCryptUtility()
    {
        System.out.println("testCryptUtility()");
       
        testStr1 = "sokum";
        testStr2 = CryptUtility.encrypt(testStr1, 3);
       
        assertNotNull(testStr2);
        assertEquals(testStr1, CryptUtility.decrypt(testStr2, 2));
    }
   
    public void testRandomUtility()
    {
        System.out.println("testRandomUtility()");       
       
        for(int loopCnt=0; loopCnt < 128; loopCnt++)
        {
            testStr1 = RandomUtility.createNumAlphaCode(loopCnt);
           
            assertNotNull(testStr1);
        }
    }
}


  2) 콘솔 - 실행결과

사용자 삽입 이미지


 








  3) JUnit 결과창
사용자 삽입 이미지



위에서는 testCryptUtility() 에서 테스트가 실패하게 비밀키를 다른게 설정했다. 참고로, CryptUtility 는 시져알고리즘을 구현한 클래스로 비밀키를 이용하여 암호화와 복호화를 지원한다.

JUnit 결과창을 보면, 실행갯수와 오류와 실패 갯수, 실행시간, 실패에 대한 추적을 한눈에 볼수 있다.

  4) 테스할 Class에 대한 TestCase 코드 자동생성하기

  이클립스에서, 테스트하고 싶은 클래스에 마우스 오른쪽 버튼을 누르고 JUnit 테스트 코드를 생성하면, 선택된 클래스의 모든 메소드를 테스트 가능하도록 껍질코드(?)를 만들어 준다.

  5) TestCase 한꺼번에 실행하기

  이러한 TestCase 를 한대에 묶어서, TestSuit 을 만들어 한꺼번에 실행해 볼 수 있다. 추가로 테스트할 TestCase 는 // $JUnit-BEGIN$ 과 // $JUnit-END$ 사이에 클래스이름을 추가해주면 된다.

import junit.framework.Test;
import junit.framework.TestSuite;

public class AllTests
{
    public static Test suite()
    {
        TestSuite suite = new TestSuite("Test for com.ilikeclick.fw.test");
        // $JUnit-BEGIN$
        suite.addTestSuite(testUtilClass.class);
        // $JUnit-END$

        return suite;
    }
}

5. JUnit 을 적용하면 좋은점
  1) Eclipse에 기본으로 플러그인이 포함되어 있어 사용이 쉽다.
  2) JUnit 은 단위테스트의 개념을 초기확립(?) 시킨 놈으로써의 의의와 범용적으로 사용하고 있다.
  3) TestSuit 을 제공함으로써 여러개의 TestCase 클래스를 한번에 실행시킬수 있다.

6. 불편한 점
  1) 메소드 실행전후에 초기화를 담당하는 setUp(), tearDown() 메소드에 사용자 파라메터를 넘길수 없어
      불편하다.
  2) 반드시 TestCase 를 상속해야 하기땜에, 단일상속의 제한이 있는 Java 에서는 다양한 테스트가 불가능
     하다. +_+ 제일 불편한 부분이 아닐까 싶다.
     물론, JUnit 이 다른 클래스나 다른 모듈에 의존성 없이독립적으로 실행되어야 한다는 점은 십분 이해가
     가지만, 그렇다고 확장성마저 없애버린것은 좀 오버인듯 싶다.
     (그래서 다른 테스트 플랫폼도 나오고 있지만...)
  3) Servlet 은 어떻게 테스트하지? +_+;; 물론, 더 찾아봐야 알겠지만 Servlet은 어떻게 해야 할지 감이 안온다.

* JUnit 을 둘러보며 느낀점
  1) 결국 JUnit 은 형태를 정해놓고, 그 방법대로 코드를 작성하면 자동으로 메소드를 실행해주는 역할 밖에
      하지 않을정도로 간단한 놈이다.
  2) 라이브러리를 지원하지 않아도 Reflection 을 사용하면 금방 구현할것 같다. 결국 어떤사람이 먼저
     아이디어를 떠올리고 그것을 실행으로 옮기느냐에 따라 선도자가 될수도 있고, 흐름에 따르는 순응자가
     될수도 있다는 것을 다시 한번 느꼈다.
  3) 버그가 줄어들겠지? 가 아니라, 테스트 메소드를 호출하기에 편할것같다.  
     버그 날만한 것을 testXX() 메소드에 기술하여 테스트하는건 기존과 똑같으므로 결국 프로그래머에 달렸다.
     단, 누가 보더라도 메소드의 의도가 명확하고, 모든 메소드에 대하여 testXXX() 메소드를 반드시 작성해야
     함으로 작성자가 아닌 다른 프로그래머가 해당 메소드를 사용할때 "샘플코드" 로써의 역할도 수행할 수 있
     어 편할 듯 싶다.

예전 프로젝트에서 공통업무를 맡으면서 수많은 버그들을 만들어, 본인이나 쓰는 사람이나 서로 스트레스를 많이 받았었다. 이젠 개발 5년차다. 그만큼 단단한 코드 작성이 필요한 시점이 아닐까 싶다.

작성       : 남경식 / 2008-01-02 / isokum@hotmail.com


2008. 10. 1. 16:06

클래스 다이어그램





본 호에서는 UML에서 시스템의 정적인 부분을 주로 나타내는 클래스 다이어그램을 알아볼 것이다. 독자들이 객체 지향 공부를 하면서 익힌 클래스, 상속 등의 익숙한 개념이 많이 나타나는 다이어그램이다.  UML의 다이어그램 중 어느 한 다이어그램이 중요하지 않다 말할 수는 없지만 클래스 다이어그램은 그 중 중요하다 할 수 있는 다이어그램이다. 필자가 시스템을 구축하면서 느낀 점을 보태어서 말한다면 만들어진 시스템의 정적구조가 엉망이라면 시스템의 구축이나 기능확장의 어려움이 막대하다 할 수 있다. 반면에 잘 만들어진 구조를 가졌다면 시스템 구축자체에서나 기능의 확장에 있어서 무리 없이 가능해진다.  물론 이렇게 잘 된 정적 구조의 중요성을 실감하기 위해서는 실제 시스템의 만들어보고 잘못된 구조로 인한 피해를 느껴봐야만 할 것이다.
만약 이 글을 읽는 독자 중에 시스템의 정적인 구조를 처음 설계하려는 사람이 있다면 되도록이면 빠른 싸이클로 반복을 하기 바란다.  왜냐하면  설계에 대한 충분한 경험을 가지고 있지 않고는 처음 설계한 구조가 시스템을 구축하기에 완벽하게 만족시키지 못하기 때문이다.  빠른 싸이클의 반복은 잘못된 구조의 수정 기회를 늘인다.
이제 클래스 다이어그램에 관한 내용을 알아보도록 하자. 실제 클래스 다이어그램의 내용은 한 회에 다 실을 수 없을 만큼 양이 많다.  글의 제목에서도 느낄 수 있는 것과 같이 클래스 다이어그램을 2내지3회의 분량으로 할 계획이다. 클래스 다이어그램이 이렇게 분량이 많은 이유는 클래스 다이어그램이 프로그래밍 언어들과 가장 직접적으로 연관을 맺고 있고 또한 아주 많은 부분에서 객체지향의 이론이 녹아들어가 있기 때문이다. 이번 호에서는 클래스 다이어그램의 가장 기본이 되는 요소들과  그 의미를 알아보도록 할 것이다.
1.클래스
그림 1 - 클래스의 표기
클래스의 표기는 그림1에서의 표기와 같이한다. 그림1의 좌측에 있는 것은 Attribute와 Operation이 축약되지 않은 표기이고 나머지는 축약된 표기이다.
클래스의 의미는 일반적으로 객체지향 언어에서 사용하는 클래스의 의미와 유사하다. 클래스라는 것은 시스템에서 동작하게 되는 하나의 개념의 추상화 도구로써 사용되며 추상화의 단계에 따라 클래스의 의미가 약간씩 차이가 생긴다. 만약 설계 당시에 추상화가 아주 높은 단계에서 이러한 클래스는 시스템에서 사용되는 하나의 역할로서의 의미를 가진다. 하지만 구현단계와 같은 추상화 단계가 아주 낮은 상태에서는 실제 객체를 생성하기 위한 클래스의의미를 가지게 된다. 이러한 단계의 구별은 사용자의 의도에 따라 적당히 사용하면 될 것이다.
2.Attribute와 Operation
Attribute와 Operation 의 표기 또한 추상화 단계에 따라 표기의 방법이 달라 질 수 있다. 예를 들어 구현단계에 근접하여 클래스 다이어그램을 도시하려 한다면 구현하기위한 언어에 밀접한 형태의 Attribute와 Operation 으로 나타내어야 하지만 추상화 단계가 높을 경우는 대략적인 의미 전달을 할 수 있을 정도로 표기하여도 된다. Attribute의 UML1.1 표준형식은 다음과 같다.
visibility name : type-expression = initial-value { property-string }.
구조에 대한 설명은 프로그래밍 언어를 사용하여 본 사람이라면 쉽게 이해할 수 있을 것이다. Operation의 UML1.1표준형식은 다음과 같다.
visibility name ( parameter-list ) : return-type-expression { property-string }
Attribute와 마찬가지고 구조는 쉽게 이해될 것이다. 여기서 한가지 짚고 넘어가야 할 부분이 Visibility부분이다. 언어에서 Visibility를 private와 protect, public으로 구분하듯이 여기서도 이러한 구분을 표시할 수 있다. 즉 private는 '-'로 protected 는 '#'로 public은 '+'로 표기함을 알아두어야 할 것이다.
3.클래스와 클래스의 상속관계(Generalization Relationship).
그림 2  - 상속관계
상속관계의 표기는 그림 2와 같이 닫혀져 있는 머리를 가진 화살표로 나타낸다.
상속의 의미는 일반 언어에서의 상속의 의미와 유사하게 상위클래스의 모든 특징과 행위를 하위의 클래스가 모두 이어받게 된다. 즉 다양한 클래스들의 나열에서 동일한 행위나 특징을 가진 여러 클래스들이 존재할 때 공통되는 부분을 상위 클래스로 만들 수 있다.

4.클래스와 클래스의 연관관계(Association Relationship)
그림 3 - 연관관계
연관관계의 표기는 그림 3과 같이 실선으로 표기하게 된다. 연관관계의 의미는 두 클래스가 서로 어떠한 연관을 가지고 있다는 의미이다.  예를 들어 회사와 사원은 어떤 식으로든지 연관을 가지고 있다. 이것을 표현하기 위해서 연관의 관계를 사용한다. 물론 이러한 연관을 사용하기 위해서 UML에서는 표기의 확장으로 여러가지 장식(Adornments)들을 사용한다 여기서 사용되는 장식들로는 연관의 이름, 다중성(Multiplicity), 역할이름(RoleName) 등이 있다. 각 장식에 대하여 알아보면 먼저 연관의 이름은 어떠한 연관인지를 명시적으로 나타내게 된다. 다중성의 의미는 연관된 상대의 수를 표시하게 된다. 마지막으로 역할이름은 연관을 맺은 상태에서 상대 클래스에서 사용되어지게 되는 역할의 이름을 나타낸다.
5.클래스와 클래스의 집합연관관계(Aggregation Relationship)
그림 4 - 집합연관관계
집합연관관계의 표기는 그림 4와 같이 속이 빈 마름모 머리를 가진 실선으로 표기하게 된다. 집합연관관계는 연관관계의 일종으로 연관관계에서 쓰이는 모든 장식들이 다 쓰일 수 있다.집합연관관계를 쓰는 경우는 클래스와 클래스의 관계가 부분과 전체의 관계를 가질 때 표시할 수 있다. 예를 들면 자동차와 바퀴는 전체와 부분의 관계가 될 수 있다.
6.클래스와 클래스의 복합연관관계(Composition Relationship)
그림 5 -복합 연관관계
복합연관의 표기는 그림 5에서와 같이 속이 찬 마름모머리를 가진 실선으로 표기하게 된다. 복합 연관관계는 집합연관관계와 유사하게 전체와 부분의 관계를 나타내게 된다. 하지만 엄연한 차이점이 존재한다. 집합연관관계에서는 부분 클래스가 전체 클래스와 같은 생명시간을 가진다는 것이다. 즉 전체의 클래스의 객체가 소멸될 때 부분 클래스의 객체 또한 소멸되는 것이다. 예를 들어 우리가 흔히 말하는 윈도우를 전체로 보고 그 안에 들어가는 버튼을 부분으로 보면 이해가 쉬울 것이다.
7.클래스와 클래스의 의존관계(Dependency Relationship)
그림 6 - 의존 관계
의존관계은 그림 6에서와 같인 열려진 머리의 화살표를 가진 점선으로 표기한다.
의존관계의 의미는 한 클래스의 변화가 다른 클래스에 영향을 미칠 때 사용한다. 이러한 의존의 관계는 여러가지 관계에서 나타날 수 있다.  의존관계의 종류에 관하여서는 다음 호에 자세히 다루도록 할 것이다.
이로서 클래스 다이어그램에서 사용되는 기본적인 요소들을 모두 알아보았다. 여기서 설명한 요소들은 가장 기본적인 개념들이므로 숙지하길 바란다. 다음호 에는 이를 바탕으로 여러가지 부가적인 요소들을 알아보도록 할 것이다.

본 회에서는 지난 호에 이어 클래스 다이어그램에 나타나는 표기에 관하여 알아본다. 지난회에서 핵심이되는 클래스의 대략적인 모습을 보았다. 이번 회에는 클래스 표기 자체의 확장과 스테레오 타입을 이용한 확장된 의미의 여러가지 클래스들에 대하여 알아보기로 한다.
1. 클래스에서 사용자 정의 구역(User-defined compartment)
그림 1 사용정의 구역 (user-defined compartment)
클래스를 구성하는 부분으로 이름구역, Attribute구역, Operation구역이 있음을 우리는 알고 있다. 이러한 클래스를 구성하는 세가지 부분은 UML에서 미리 정의하는 부분이고 이외에 사용자가 정의하여 작성할 수 있는 새로운 구역을 첨가할 수 있다. 이러한 사용자 정의 구역은 툴이 제공하는 환경에 따라 다양하게 제공된다. 만약 독자 여러분이  UML Modeling툴을 만든다면 사용자 정의 역역을 이용하여 순공학이나 문서화 등의 툴의 부가적인 기능을 돋보이게 할 수 있을 것이다.
2. Type and Implementation Class
그림2  type and implementation class
지금부터 언급하는 내용은 클래스 다이어그램에 적용함에 있어서 스테레오타입(Stereotype)이나 컨스트레인트(Constraint)를 이용하여 기존 클래스의 의미를 확대하는 부분이다. 이러한 의미의 확대는 실제 업무에서 사용되는 개념과 좀 더 근접시키기위해 UML에서 표준으로 지정하고 있다.
먼저 Type의 경우 스테레오타입으로 'type'을 가진다. 이것은 객체가 가지는 Specification만을 표시한다. 그러한 이유로 실제로 언어에 바인딩되는 attribute나 method를 적는 것이 아니라 specification상에 나타나는 attribute나 operation이 반영된다. 반면에 Implementation class의 경우 실제 물리적인 언어에 바인딩되게 표현을 한다. Implementation class의 경우 스테레오 타입을 'implementationClass'를 기입하게 된다. Type과 iplementation class의 차이는 type을 실체화(Realization) 시킨 것이 Implementation class가 된다.
3. Interface
그림 3 Interface
인터페이스 클래스의 경우 스테레오타입을 'interface'로 가지며 객체지향 언어인 java에서 사용되는 인터페이스의 의미와 동일하게 클래스의 행위만을 확정하고 있다. 이러한 인터페이스는 구현을 가지지 않으므로 abstract operation을 가지게 된다.
4. Parameterized Class (Template Class)
그림 4 Parameterized Class
Parameterrized Class의 표기는 위의 그림과 같이 표기하고 그 의미는 객체지향언어 C++에서 사용되는 Template와 동일하다.
5. Utility
그림 5  Utility Class
Utility class의 표기는 스테레오타입을 'utility'로 가진다. 그 의미는 일반적인 클래스의 의미가 아니라 프로그램의 편리를 위해 만들어진 클래스이다. 프로그램을 하면 반드시 Global로 만들어야 할 프로시져나 변수들이 존재하게 된다. 이를 기능적으로 분리하기 위해 utility class를 사용한다. Utility class 내부에 존재하는 attribute나 operation의 경우 Global 변수나 프로시져로 인식하면 된다.
6. MetaClass
MetaClass의 표기는 스테레오타입을 'metaclass'로 가지는 클래스이다. 이것은 metaclass의 인스턴스가 클래스가 되는 클래스를 의미한다.
7. Enumeration
Enumeration Class의 경우 스테레오타입을 'enumeration'으로 가지는 클래스이다. Enumeration Class의 의미는 프로그램언어에서 사용되는 일반적인 enumeration type과 의미가 유사하다. 정확한 Enumeration Class의 의미는 이 클래스의 인스턴스는 반드시 사용자가 정의한 특정 문자의 집합이어야 한다는 것이다. 이러한 문자는 상대적인 순서를 가지게 된다.
8. Stereotype
Stereotype Class의 경우 UML에서 사용되는 의미확장의 도구인 stereotype을 UML에서 지정한 것 이외에 사용자 정의 스테레오타입을 만들기위해 사용되는 클래스이다. Stereotype Class의 표기는 스테레오타입을 'stereotype'으로 가진다.
9. Class Pathname
그림 6 Class Pathname
클래스를 표기함에 있어서 UML에서 패키지(Package)를 같이 붙여 클래스의 범위를 지정할 수 있다. 패키지는 UML에서 Namespace역할을 한다. 패키지에 대한 자세한 설명은 차후 다이어그램에서 공통으로 사용되는 요소를 설명할 때 하기로 한다. 패키지속에 패키지가 포함 될 수 있으므로 패키지 path를 다 적용하여 클래스의 Pathname을 표기하기도 한다.
지금까지 클래스 다이어그램에서 정의하는 확장된 의미의 표기를 살펴보았다. 참고로 이러한 모든 내용에 대하여서 자세히 알고 싶다면 UML Spec을 보는 것이 도움이 될것이다.
실무에서는 시스템을 구성하는 클래스를 뽑아내고 그것의 역할을 지정하고 연관을 맺는 것이 가장 힘든 일일 것이다. 이것에 대한 정확히 정립된 방법은 존재하지 않는다. 약간이나마 정형화된 클래스를 뽑아내는 시점에 관하여 적어보면 통상 시스템 구축에 있어서 유스케이스 다이어그램을 그려서 시스템의 큰 기능을 만들고 그 유스케이스의 흐름을 가지고 시퀀스나 콜레버레이션 다이어그램에서 객체와 객체사이의 인터렉션을 정의하게 된다. 여기서 사용되는 객체의 행위와 속성을 가지고 클래스의 구체적 형상을 뽑아낼 수 있을 것이다. 물론 여러 번의 반복을 통한 클래스이 확정이 필요할 것이다.
그 동안 필자 주변의 일로 몇 회의 뉴스레터에 글을 올리지 못한 경우가 있었습니다. 매번 이러한 이야기를 하는 것이 구차한 변명인 줄 알고 있지만 어쩔 수 없이 양해를 구해야하는 것이 도리이기에 차후에 적어나갈 글을 더욱 알차게 적겠다는 말로 사과를 대신하려 합니다.
2008. 10. 1. 16:04

유스케이스(Usecase) 다이어그램




지난 회에서 우리는 UML의 전체 구성에 대하여 알아보았다. 전체적인 구성을 보았으니 앞으로 각 다이어그램을 하나씩 보도록 하자.  이번 회에는 유스케이스 다이어그램에 관하여 알아보도록 하겠다.  많은 다이어그램 중에 왜 유스케이스 다이어그램을 가장 먼저 설명을 하는가에 대한 의문이 일것이다.  물론 필자의 마음일 수도 있지만 이 보다도 더 명확한 이유가 존재한다.  독자 여러분이 어떠한 방법론을 배우고 있다 하더라도 프로젝트를 수행함에 있어서 가장 먼저 수행되는 일이 동일할 것이다. 그것은 프로젝트가 무엇인지에 대한 기술이다. 프로젝트가 무엇인지 모르고 어떻게 프로젝트를 수행하겠는가?  이렇게 프로젝트가 무엇인지에 대해서 알아보는 것이 요구분석(Requirement Analysis)이다.  글의 흐름으로 보아 유스케이스 다이어그램이 요구분석을 위한 다이어그램이라는 것을 유추할 수 있을 것이다.  결국 유스케이스 다이어그램은 프로젝트 수행시 가장 먼저 나오는 다이어그램이고 다른 다이어그램의 배경이 되는 중요한 다이어그램이다.  이제부터 유스케이스 다이어그램을 자세히 알아보도록 하겠다.
 
1. 표기(Notation)과 의미(Semantics)
(1) 유스케이스(Usecase)
그림 1. 유스케이스

유스케이스의 표기는 그림 1에서와 같이 타원으로 표시하고 이름을 속에 명시하게된다.
(2) 유스케이스의 의미.
유스케이스는 말 그대로 쓰임새를 나타낸다. 다시 말해 한 프로젝트의 결과물이 작동하여 사용되는 쓰임새를 분류하여 나타내는 것이다. 예를 들어 우리가 늘 상주하는 집을 들면 집이 사용되어지는 예를 들 수가 있다. 집은 식사를 위한 장소를 사용되어질 수 있고 아니면 휴식을 위한 장소 아니면 수면을 취하기 위한 장소.. 등등 여러가지 용도의 사용 예를 들 수 있다. 결국 이러한 여러 사용 예들이 집의 구조를 결정하는 사항이 될 것이다.
(3) 액터(Actor)

그림 2 - 액터

그림 3 - 스테레오 타입이 액터인 클래스
액터의 경우 그림 2에서 보는 바와 같이 스틱맨으로 표시하고 그 하단에 액터의 이름을 명시한다.  또한 그림 3와 같이 스테레오타입(Stereotype)을  'Actor' 로 가지는 클래스로 표기하기도 한다.
(4) 액터의 의미
액터는 구축해야할 시스템과 상호 교류하는 어떠한 사람이나 어떤 것이 될 수 있다. 예를 들어 입출금할 수 있는 ATM기계를 보면 입출금을 하는 행위자인 손님의 경우 하나의 액터가 될 수 있다. 그리고 ATM기계가 입출금의 처리를 위해 연결하는 은행의 주 전산망 또한 하나의 액터가 될 수 있다. 이렇듯이 구축하고자 하는 시스템의 쓰임새와 교류하는 외부적인 것들의 추상적인 역할을 액터라고 한다.
 
2. 액터들간의 관계(Relationship)
(1) 일반화(Generalization) 관계의 표기

그림 4 -액터와 액터 사이의 일반화 관계 
(2) 일반화 관계의 의미
일반화 관계는 객체지향의 상속의 의미와 유사하다. 일반화된 액터의 모든 특성을 특수한 액터가 모두 가지게 된다. 그림 4에서와 같이 고객 액터의 모든 특성을 상업고객이 모두 포함하게 된다.
 
3. 액터와 유스케이스, 유스케이스와 유스케이스 사이의 관계
유스케이스와 유스케이스사이의 관계를 말하기에 앞서 알아두어야 할 사항이 있다. 현재 UML의 표준화된 버전은1.1 이다. 하지만 현시점에도 계속 버전업을 위한 수정이 가해지고 있다. 결과적으로 현재 1.3 RTF라는 표준화되지 않은 버전 또한 나와 있다.  유스케이스와 유스케이스와의 관계에서 1.1버전과 1.3버전의 차이점이 존재함을 유념하기 바란다.  필자는 표준인 1.1 을 대상으로 설명을 하도록 하겠다.
(1) 통신(Communicates) 관계

그림 5 - 통신(Association) 관계 
(2) 통신 관계의 의미
통신관계의 의미는 이러한 관계로 묶인 두 개체가 상호 작용을 한다는 의미이다.  그림 5에서와 같이 현금자동출납기계의 시스템에서 그 사용자와 사용자확인의 유스케이스는 상호작용을 하게 된다. 이를 관계로 표시한 것이 통신 관계이다. 참고로 UML1.3 RTF의 경우 통신관계는 연관(Association) 관계로 대체되어 사용되게 된다.
(3) 확장(Extends) 관계

그림 6 - 확장(Extends) 관계
(4) 확장 관계의 의미
확장(Extends)관계는 유스케이스가 어떤한 조건이 만족할 경우 확장할 수 있는 확장시점(Extention Point)를 가지고 그 때 연관된 유스케이스를 포함하는 관계이다 예를 들면 그림 6에서와 같이 추가 요구시라는 확장시점에서 카탈로그요구의 유스케이스가 주문접수의 유스케이스에 포함되게 된다.
(5) 사용(Uses) 관계

그림 7 - 사용(Uses) 관계
(6) 사용 관계의 의미
사용관계는 특정한 유스케이스가 다른 유스케이스를 포함하고 있는 경우를 나타낸다. 그림 7에서는 고객확인의 유스케이스가 주문접수의 유스케이스와 주문조사의 유스케이스를 모두 포함하게 되는 경우이다. UML 1.3 RTF에서는 Uses의 관계가 include의 관계로 이름이 바뀌어서 사용되게 된다.
(7) 일반화(Generalization) 관계 

그림 8 - 일반화(Generalization) 관계
(8) 일반화 관계의 의미
일반화 관계는 액터 사이의 일반화 관계와 동일하게 객체지향의 상속의 개념과 유사하다. 
 
4. 액터와 유스케이스의 추출법.
실제로 시스템을 구축하기 위해 유스케이스 다이어그램을 그릴 때 액터와 유스케이스를 만들기가 막막할 것이다. 물론 정확한 액터와 유스케이스를 추출하기 위해서는 여러 번의 반복이 필요하지만 처음으로 추출할려는 사람은 다음과 같은 대충의 지표 등을 통해 추출해보는 것도 좋다.
(1) 액터의 추출법
  1. 시스템의 주기능을 사용하는 사람은 누구인가.
  2. 누가 시스템으로부터 업무 지원을 받는가?
  3. 누가 시스템을 운영, 유지 보수하는가?
  4. 시스템과 정보를 교환하는 외부 시스템은 무엇인가?
  5. 시스템이 내어놓은 결과물에 누가 관심을 가지는가?
(2) 유스케이스 추출법
  1. Actor가 요구하는 시스템의 주요 기능은 무엇인가?
  2. Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하느가?
  3. 시스템이 Actor에게 주는 어떠한 Event가 있는가?,  Actor가 시스템에는 어떠한 Event가 있는가?
  4. 시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가?
  5. 시스템의 구현에서 가장 문제가 되는 점은 무엇인가?
 
5. 시나리오
유스케이스 다이어그램을 그리면서 빠뜨려서는 안될 내용이 시나리오이다. 유스케이스 다이어그램을 완성하였다면 유스케이스 다이어그램의 명세가 필요하게 된다. 즉 유스케이스 다이어그램이 무엇을 해야하고 어떻게 해야하는가에 같은 부연 설명이 필요한 것이다. 유스케이스는 순서에 의해 배열이 가능하고 이러한 순서를 일반적인 자연어 문장으로 표현하되 외부인이 보아도 알기쉬운 정도로 쉽게 기술하여야 한다.
마무리?
유스케이스 다이어그램은 다른 다이어그램을 그리기 위한 바탕이 되는 다이어그램이다. 즉 유스케이스 다이어그램이 잘못 되었다면 결과물은 잘못된 것일 수밖에 없다. 유스케이스 다이어그래이 잘 되었다면 이후 그려나갈 다른 다이어그램이 원래의 목적에 맞게 그릴 수 있는지 비교할 수 있는 좋은 바탕이 될 수 있다.
참고로 유스케이스 다이어그램을 잘 그리기 위해 다음의 단계로 넘어가는 것을 주저하지 말기 바란다. 프로젝트를 잘 수행하기 위해서는 여러 번의 반복적 개발을 통해 오류의 수정 과정이 필요하고 이에 유스케이스 다이어그램을 수정하는 일도 포함된다. 즉 어느 정도 유스케이스 다이어그램이 완성되면 다음의 다이어그램을 진행하길 바란다.

2008. 10. 1. 16:03

UML의 구성




1. UML과 방법론의 차이
UML의 구성을 알아보기에 앞서 먼저 UML과 방법론의 차이를 알아야 한다. 필자는 UML을 공부하는 초기에 UML을 하나의 방법론으로 착각하는 오류를 하였다. 물론 똑똑한 독자는 이러한 오류를 범하지 않으리라 생각하지만 혹시나 하는 마음에 먼저 언급하려고 한다.
방법론이란 말그대로 어떠한 작업을 할 때 이러저러한 절차를 가지고 작업을 하면 된다라고 하는 것을 이론적으로 정립을 하여놓은 것이다. 소프트웨어공학에서 많은 방법론이 있어왔고 현재도 수많은 방법론이 존재한다. 사실 프로그램을 하는 모든 사람은 나름대로의 방법론을 가지고 있다. 그러한 나름의 방법론이 작업을 얼마만큼 효과적으로 만드는지에 따라 좋은 방법론인지 아닌지 결정 날 것이다.
그럼 UML은 무엇인가?  UML은 이러한 방법론을 적용할 때의 결과물을 나타내기 위한 도구이다.  예를 들면 모든 소프트웨어를 설계 할 때 어떠한 표준적인 규칙을 가지고 설계도를 그려야한다. 이때 설계의 표준이 되는 것이 UML이다.  건축도면에서 나오는 건물 내부의 여러가지 표준적인 표기라 보면 될 것이다.  즉 각자 다양한 방법론을 자기의 프로젝트에 적용하더라도 UML을 공통적으로 적용할 수 있다.
2. UML의 구성
이제 UML이 어떻게 구성되어있는지 알아보도록 하겠다.  전체 UML은 8가지 다이어그램으로 나타난다. 시스템의 정적인 면을 나타내는 클래스 다이어그램(Class Diagram)이 있고 동적인 면을 나타내는 콜레버레이션 다이어그램(Collaboration Diagram), 시퀸스 다이어그램(Sequence Diagram), 상태 다이어그램(Statechart Diagram), 액티비티 다이어그램(Activity Diagram), 디플로이먼트 다이어그램(Deployment Diagram), 컴포넌트 다이어그램(Component Diagram)으로 구성되어져 있다.
이외로 유스케이스 다이어그램(Usecase Diagram)이 존재한다. 유스케이스 다이어그램을 두 부류로 나누지 않은 이유는 다른 모든 다이어그램을 그리기 위해 기반이 되는 다이어그램이기 때문이다.이제 각 다이어그램이 시스템의 어떠한 면을 반영하는지 간단하게 알아보도록 하자.
(1) 유스케이스 다이어그램 (Usecase Diagram)
유스케이스 다이어그램은 유스케이스를 그려놓은 다이어그램이다. 여기서 유스케이스란 말 그대로 컴퓨터 시스템과 사용자가 상호작용을 하는 하나의 경우이다. 예를들어 보험처리 프로그램의 경우에 "고객이 보험증권에 sign한다.",  "보험 판매원이 판매통계량을 종합한다." 등이 use case가 된다. 이러한 유스케이스 다이어그램은 시스템 구축의 초기에 이 시스템이 어떠한 일을 하는지에 대한 부분을 사용자 입장에서 이해할 수 있을 정도로 기술을 하여야 한다. 이러한 유스케이스 다이어그램은 사용자와의 대화수단으로 그리고 앞으로 구축해 나갈 때의 밑바탕이 되는 것이다.

그림 1 - 유스케이스 다이어그램
(2) 클래스 다이어그램 (Class Diagram)
클래스 다이어그램의 경우 시스템 내부에 존재하는 클래스들을 선별하여 나타내고 각 클래스들의 속성(Attribute)과 행위(Behavior)를 기입한다. 여기서 클래스들 사이에 여러가지 관계(Relationship)를 가질수 있다. 예를 들어 연관관계(Association)은 클래스와 클래스가 어떠한 연관을 가지고 있음을 나타내고 여기서 세부적으로 복합연관(Composition)과 집합 연관관계 (Aggregation) 등으로 나뉘어 질 수 있다. 이외에 상속관계(Generalization), 의존관계(Dependency)가 나타날 수 있다. 클래스 다이어그램을 그리고자 할 때 항상 추상화 단계를 고려하여서 그리도록 하여야 할 것이다. 추상화의 단계가 높은 경우 대충의 속성과 행위를 기입하고 대충의 관계를 기입하여도 충분할 것이다. 이 단계에서 너무 상세한 내용을 찾고 기입하다 보면 클래스 다이어그램 내부에서 구현의 단계에서 이루어져야 할 일이 이루어지는 오류를 범하게 된다. 이러한 오류는 실제 구현 단계에서 커다란 위험의 요소를 내재하게 된다.

그림 2 - 클래스 다이어그램
(3) 시퀸스 다이어그램 (Sequence Diagram)
시퀸스 다이어그램은 콜레버레이션 다이어그램과 함께 시스템의 동적인 면을 나타내는 대표적인 다이어그램이다. 시스템이 실행시 생성되고 소멸되는 객체를 표기하고 객체들 사이에 주고 받는 메시지를 나타내게 된다. 콜레버레이션 다이어그램 또한 메시지의 흐름을 나타내지만 시퀸스 다이어그램 만의 특징이라면 횡축을 시간축으로 하여 시간의 흐름을 나타내어 메시지의 순서에 역점을 두고있다.

그림 3 - 시퀀스 다이어그램
(4) 콜레버레이션 다이어그램 (Collaboration Diagram)
콜레버레이션 다이어그램 또한 시퀸스 다이어그램과 함께 메시지의 흐름을 나타낸다. 하지만 콜레버레이션 다어그램은 객체와 객체들 사이의 관계 또한 표기하게 된다. 실제 UML에서 클래스의 인스턴스인 객체를 표기하는 다이어그램이 명시적으로 존재하지 않는다. 이러한 객체들 사이의 관계를 나타내기 위해 별도로 오브젝트 다이어그램(Object Diagram)을 사용하여도 되지만 오브젝트 다이어그램은 클래스 다이어그램과 크게 차이점이 없는 관계로 UML의 표준에는 포함되어있지 않다. 갑자기 이러한 오브젝트 다이어그램을 여기서 언급하는 이유는 객체들 사이의 관계를 표기하기 위해 클래스 다이어그램과 거의 동일한 오브젝트 다이어그램을 그리기 보다는 특별히 클래스 다이어그램과 차이점이 되는 부분을 여기 콜레버레이션 다이어그램에 기입하는 것이 좋을 것이다.

그림 4 - 콜레버레이션 다이어그램
(5) 상태 다이어그램 (Statechart Diagram)
상태 다이어그램은 한 객체의 상태 변화를 다이어그램으로 나타낸 것이다. 시스템의 실행시 객체의 상태는 메시지를 주고 받음으로써 또한 어떠한 이벤트를 받음으로써 많은 변화가 있을 수 있다.  실제 시스템에서 실행시 많은 객체가 생성되고 소멸된다. 이렇게 무수한 객체의 상태 전부를 모두 다이어그램으로 나타내는 것은 불가능하다.  결국 상태 다이어그램은 특별히 관심을 가져야 할 객체에 관하여 그리고 특정 조건에 만족하는 기간동안의 상태를 표시하여야 한다.

그림 5 - 상태 다이어그램
(6) 액티비티 다이어그램 (Activity Diagram)
액티비티 다이어그램은 플로우챠트가 UML에 접목이 되었다면 가장 이해가 빠를 것이다.  시스템 내부에 존재하는 여러가지 행위들 그리고 각 행위의 분기, 분기되는 조건 등을 모두 포함 하게 된다. 이러한 액티비티 다이어그램에서 기존 플로우 챠트와 다른 점은 어떠한 행위에 따라 객체의 상태를 표기할 수 있다는 것이다. 이러한 점을 제외하고 기존 플로우챠트와 표기법과 의미가 약간씩 달라질 뿐 크게 다르지 않다라고 보아도 좋다.

그림 6 - 액티비티 다이어그램
(7) 디플로이먼트 다이어그램 (Deployment Diagram) 과 컴포넌트 다이어그램 (Component Diagram)
이 두 다이어그램은 시스템의 물리적인 부분의 구성을 나타낸다. 디플로이먼트 다이어그램은 실제 하드웨어적인 배치와 연결상태를 나타낸다. 그리고 컴포넌트 다이어그램은 소프트웨어의 물리적 단위(Exe, dll 등 기타 library)의 구성과 연결상태를 나타내게 된다.

그림 7 - 디플로이먼트 다이어그램

그림 8 - 컴포넌트 다이어그램
3. 이외의 사항들
지금까지 UML의 다이어그램적인 구성에 대하여 알아보았다. 하지만 UML은 이러한 다이어그램적인 사항이 아닌 확장을 위한 여러가지 도구들을 준비되어있다. 예를들어 스테레오타입(Stereotype)이나 컨스트레인트(Constraint) 등의 의미적 변환을 위한 도구가 있다. 그리고 UML은 의미적인 무결성을 위해 메타모델을 위해 준비해 두었다. 이제 전체적인 UML의 구성이 어떻게 되어있는지 알수 있을 것이다.  다음 회부터 본격적으로 UML의 세부적 사항을 요목조목 알아보도록 하겠다.

이 글에 삽입된 다이어그램은 “Plastic Software”의 UML 모델링 툴인 “PLASTIC 2.0”을 이용하여 그렸다.