반응형

안드로이드는 out-of-memory 상황이 되면 종료되어야 할 Process를 결정하게 된다.

이 때 사용되는 값이 oom_adj(Out Of Memory Adjustment)이다.

 

Process에 적용되는 oom ad 값은 아래와 같으며, 값이 클수록 리소스가 부족할 때 가장 먼저 종료가 된다.

-FOREGROUND_APP_ADJ 0 : 현재 실행되어 있고 User가 Control하고 보여지고 있는 Process

-VISIBLE_APP_ADJ 1 : 문자입력기 같이 단독으로 수행이 되지 않지만 보일 가능성이 있는 Process

-SECONDARY_SERVER_ADJ 2 : 현재 수행되어 지는 Wdiget 이나 Service

-HIDDEN_APP_MIN_ADJ 7 : Background App으로 종료하지 않고 빠져나온 App들이 해당

-CONTENT_PROVIDER_ADJ 14 : Content Provider

-EMPTY_APP_ADJ 15 : 캐시로 존재하는 App으로 퍼포먼스를 위해 Memory에 상주시켜놓은 App

* SYSTEM_ADJ -16 : 시스템을 위한 Process, 가장 작은 음수 값을 가지고 있는 것을 볼 수 있다.

 

Property 값 셋팅 (/etc/init.rc)

 

oom adj 확인

$cat /proc/[확인하고 싶은 프로세스 번호:PID]/oom-score

 

oom adj변경

#echo [변경하고자 하는 값] > /proc/[변경하고 싶은 프로세스 번호:PID]/oom_adj

반응형

'SW개발' 카테고리의 다른 글

[QXDM] [로그 저장하고 불러오기]  (2) 2012.08.24
[리눅스 쉘(Shell) 스크립트]  (5) 2012.08.17
[Linux와 Shell]  (0) 2012.08.14
[VI 글자 색상 바꾸기]  (2) 2012.08.13
[Android]서비스의 라이프 사이클  (0) 2012.08.10
[Linux][VIM설정]  (0) 2012.07.31
[Linux][Screen]  (1) 2012.07.31
[Linux][alias 사용]  (1) 2012.07.31
[UML Diagram과 StarUML]  (0) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
반응형

Linux에서 파일 편집을 위해 주로 vi Editor를 많이 사용한다.

VI Edit의 설정을 내 입맛에 맞게 바꾸어서 사용하기 위해서는 사용자 디렉토리에 있는 ".vimrc"파일을 수정하여야 한다.

만약 ".vimrc" 파일이 없다면 생성을 하여서 안에 아래와 같은 명령어들을 셋팅 해 주면 된다.

 

VIM 설정 옵션들

set number "줄 번호를 표시한다.

set nonumber "줄 번호를 표시를 해제한다.

set tabstop=2  "탭 간격을 2 칸 으로 지정한다 

set expandtab " 탭 문자를 공백문자로 변환한다. 

set softtabstop=2 "탭 간격을 공백문자로 변환하면 두 칸 단위로 삭제한다 

set visualbell " 사용자 실수 경고시 비프음 대산 화면을 한 번 반짝인다. 

set nobackup "백업 파일을 생성하지 않는다 

set cindent "C 언어 스타일의 들여쓰기를 사용합니다. 

set autoindent "자동 들여쓰기를 사용합니다. 

set enc=euc-kr "인코딩을 한글로 지정합니다. 

set incsearch"키워드 입력시 검색하는 점진 검색을 사용합니다. 

syntax on "구문 강조기능을 사용합니다 

filetype on "파일 종류에 따라 구문을 강조합니다. 

set background=dark "배경색을 어두운 색으로 설정합니다. 

colorscheme evening "VI 색상 테마를 evening  으로 설정합니다 

set backspace=eol,start,indent "줄의 끝, 시작, 들여쓰기서 백스페이스 사용시 이전 줄과 연결 

set history=1000 " VI  편집 기록을 1000개 까지 저장합니다. 

set hlsearch "검색어 강조 기능을 사용합니다. 

set ignorecase "검색, 편집, 치환시 대소문자를 구분하지 않습니다. 

set showmatch "() 과 {} 에서 한 괄호만 입력해도 일치하는 괄호를 보여줍니다


반응형

'SW개발' 카테고리의 다른 글

[리눅스 쉘(Shell) 스크립트]  (5) 2012.08.17
[Linux와 Shell]  (0) 2012.08.14
[VI 글자 색상 바꾸기]  (2) 2012.08.13
[Android]서비스의 라이프 사이클  (0) 2012.08.10
[Android][OOM(Out Of Memory) Adjustment]  (0) 2012.08.02
[Linux][Screen]  (1) 2012.07.31
[Linux][alias 사용]  (1) 2012.07.31
[UML Diagram과 StarUML]  (0) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
반응형

Linux 서버를 사용하는 주된 이유 중에 하나가 컴파일과 같은 고성능 서버의 CPU에서 장기간 명령을 수행할 때이다.

Terminal로 Server에 접속하여 작업을 하다가 Network의 이상이나 내 컴퓨터의 문제로 인해 서버와의 연결이 끊어지기도 하는데,

이 때 서버에서 수행하던 작업도 같이 종료가 되어 버리곤 한다.

 

이러한 문제를 해결할 수 있는 방법 중에 하나가 "screen"을 이용하는 것이다.

Screen은 불의의 사고로 서버와의 연결이 끊어지더라도 수행하던 작업을 계속 진행하며, 사용자가 서버에 재 접속하여 다시 이전에 하던 작업을 계속해서 진행할 수 있게 해준다.

 

● Screen 사용예

1, "build" 라는 이름으로 socket생성

$screen –S build

2. 작업 수행(compile, git sync등)

3. Network 끊어짐

or

(Ctrl+a, d)를 이용하여 socket이 detach

4. 서버에 재 접속하여 socket list를 확인

$screen –list

5. 이전에 수행하던 socket 연결

$screen –r build

6. 이전에 작업 계속

7. 작업 완료 후 socket 종료

$exit

 

 

Screen socket 만들기

$screen –S 세션명 : 세션명으로 socket을 하나 생성

$screen : default로 socket을 하나 생성

 

▶socket을 종료하지 않고 원래 sh로 이동

Ctrl+a -> d

 

▶실행 중인 socket 확인

$screen –list

 

▶Detached socket 에 연결

$screen –r [host.tty] : 해당 host.tty에 연결

$screen –r : Detached socket이 하나일 경우에는 "screen –r" 만 사용하여도 연결

 

▶screen 종료

$exit

 

▶기본적인 command 옵션들

$screen --help

 

▶Ctrl+a 를 이용한 옵션들

* Ctrl+a, esc 를 누르고 방향키를 이용해서 이전에 나왔던 출력화면을 확인 할 수 있다.



반응형

'SW개발' 카테고리의 다른 글

[Linux와 Shell]  (0) 2012.08.14
[VI 글자 색상 바꾸기]  (2) 2012.08.13
[Android]서비스의 라이프 사이클  (0) 2012.08.10
[Android][OOM(Out Of Memory) Adjustment]  (0) 2012.08.02
[Linux][VIM설정]  (0) 2012.07.31
[Linux][alias 사용]  (1) 2012.07.31
[UML Diagram과 StarUML]  (0) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[GIT]  (0) 2011.11.21
반응형

리눅스 콘솔창을 사용할 때 "ls" 대신 "ll"이라는 명령어를 자주 사용한다.

이렇게 "ll"이라는 명령어를 사용할 수 있게 해주는 것이 바로 alias이다.

사용자의 Home 디렉토리에는 각 사용자를 위한 .bashrc라는 파일이 있다. ('.'으로 시작하는 파일은 숨겨진 파일이다.)

우리가 "ll"명령어를 사용할 수 있는 부분이 아래와 같이 .bashrc파일에 작성되어 있다.

 

●유용한 alias 사용 예

## ls

alias ls="ls -hF --color"

alias l="ls -l"

alias lh="ls -lh .[a-zA-Z0-9]*"

alias ll="ls -lh | more"

alias lla="ls -lha"

alias lx='ls -lXB' # 확장자별 정렬

alias lk='ls -lSr' # 크기별

alias la='ls -Al' # hidden file view

alias lr='ls -lR' # 재귀적 ls

alias lt='ls -ltr' # 날짜별 정렬

alias tree='tree -Cs' # 'ls'

 

## aliases for Tape-ARchive(tar)

alias tart='tar tvzf'

alias tarc='tar cvzf'

alias tarx='tar xvzf'

 

## aliases to excute specific applications

alias man='man -a'

alias pu='\ps u'

alias ps='\ps -afl'

alias pl='ps -L'

alias cls="clear"

alias cp="cp -i"

alias du="du -h"

alias df="df -kh"

alias h="history"

alias j='jobs -l'

alias logs="tail -f /var/log/messages /var/log/*log"

alias mkdir="mkdir -p"

alias mlog="tail -100f /var/log/mail.log"

alias mv="mv -i"

alias path="env | grep PATH"

alias ps="ps aux"

alias rm="rm -i"

alias tc="tar cfvz"

alias tx="tar xfvz"

alias vi="vim"


반응형

'SW개발' 카테고리의 다른 글

[VI 글자 색상 바꾸기]  (2) 2012.08.13
[Android]서비스의 라이프 사이클  (0) 2012.08.10
[Android][OOM(Out Of Memory) Adjustment]  (0) 2012.08.02
[Linux][VIM설정]  (0) 2012.07.31
[Linux][Screen]  (1) 2012.07.31
[UML Diagram과 StarUML]  (0) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[GIT]  (0) 2011.11.21
[Linux 기본 명령어]  (0) 2011.10.19
반응형

 

UML에서는 많은 Diagram들을 지원하는데, UML에서 사용하는 전체적인 다이어그램(Diagram)은 아래와 같다.

 

 

1. Structure Diagram들은 System의 구조를 나타내며, 무엇이 있어야 하는지(what things must be)를 강조한다.

대표적인 Structure Diagram은 Class Diagram이 있다.

 

Class Diagram은 Class를 Diagram으로 표기한 것으로 아래와 같이 작성이 되어진다.

 

2. Behavior Diagram들은 System의 동작을 나타내며, 무엇이 행해져야 하는지(what must happen)를 강조한다.

대표적인 Behavior Diagram은 Use Case Diagram, Sequence Diagram이 있다.

 

Use Case Diagram은 Actor의 행위를 중심으로 이루어진 Diagram으로 아래와 같이 그려질 수 있다.

 

3. UML의 Diagram을 그리기 위해서는 여러가지 SW가 있다.

그 중 대표적인 것이 Rational Rose사의 UML, MS사의 Visio, StarUML 등이 있는데, 세 개의 프로그램에서 StarUML을 빼고는 유료이다.

StarUML이 무료 툴이지만 Simple한 화면과 편리한 사용성을 바탕으로 많은 개발자들이 사용을 하고 있다.

StarUML의 전체적인 소개 내용은 아래와 같다.

 

StarUML로 Diagram을 작성한 예.

 

StarUML다운로드 링크 : http://downloads.sourceforge.net/project/staruml/staruml/5.0/staruml-5.0-with-cm.exe?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fstaruml%2Ffiles%2Fstaruml%2Fjava%2F&ts=1343698607&use_mirror=cdnetworks-kr-2

반응형

'SW개발' 카테고리의 다른 글

[Android]서비스의 라이프 사이클  (0) 2012.08.10
[Android][OOM(Out Of Memory) Adjustment]  (0) 2012.08.02
[Linux][VIM설정]  (0) 2012.07.31
[Linux][Screen]  (1) 2012.07.31
[Linux][alias 사용]  (1) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[GIT]  (0) 2011.11.21
[Linux 기본 명령어]  (0) 2011.10.19
[안드로이드 버전 정보]  (0) 2011.10.10
반응형

안드로이드(Android) 의 APK의 구성은 아래와 같다.    

 

APK가 생성되는 절차는 아래와 같다.

 

 

 

 

 

반응형

'SW개발' 카테고리의 다른 글

[Android][OOM(Out Of Memory) Adjustment]  (0) 2012.08.02
[Linux][VIM설정]  (0) 2012.07.31
[Linux][Screen]  (1) 2012.07.31
[Linux][alias 사용]  (1) 2012.07.31
[UML Diagram과 StarUML]  (0) 2012.07.31
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[GIT]  (0) 2011.11.21
[Linux 기본 명령어]  (0) 2011.10.19
[안드로이드 버전 정보]  (0) 2011.10.10
[Jar파일에서 Class쉽게 찾기]  (0) 2011.09.27
반응형

객체지향 프로그램을 개발에서는 Class간의 관계나 상속 관계를 잘 알고 있어야 한다.

하지만 개발을 하기에도 부족한 시간에 문서를 만들기란 쉽지 않다.

 

"Doxygen"을 이용하여 Document를 만들어 보자!

 

<<Doxygen 주요 기능들>>

-Class Diagram 생성

-Collaboration Diagram 생성

-Method, Member Index 생성

-Class Hierarchy 생성

-Etc

 

"Doxygen"이라는 오픈 프로그램은 MSDN이나 Java Doc 과 같은 페이지를 자동으로 생성하여 주는 고마운 무료 프로그램 중에 하나이다.

<<생성한 Document 예>>

 

설치 및 기본적인 사용 방법은 아래와 같다.

1."Doxygen"을 아래의 링크를 클릭하여 PC의 OS에 맞게 설치파일을 Download 하여 설치한다.

Doxygen Download

 

2. Diagram들을 그리기 위해서는 graphviz를 같이 설치를 해야 한다. 아래의 링크에서 PC의 OS에 맞게 설치파일을 Download하여 설치한다.

Graphviz Download

 

3. 두 개의 Program을 설치를 하였으면, Doxygen에서 몇 가지 설정을 한다. (Windows XP기준)

(1) Doxygen이 실행하여 생성할 파일들의 Working 폴더를 지정

(2) Wizard Tab에서 Project를 선택

(3) 생성 할Document의 이름을 지정

(4) 생성 할 Document의 Version을 지정

(5) 생성 할 Document Page의 상단에 넣을 이미지를 선택

(6) Source 가 위치한 폴더를 선택

(7) Source가 위치한 폴더의 하위 폴더도 포함할 수 있도록 "Scan recursively"를 체크

(8) Working 디렉토리 기준으로 생성 할 Document가 위치하게 될 경로 지정

(9) Mode 선택

(10) C++, C, PHP, Fortran, Java, C#등을 지원한다.

내가 만들 문서는 Java 소스를 이용하기 때문에 Java를 선택

(11) Output을 선택

(12) plain HTML 선택

(13) "Change color…"을 클릭하면 문서 페이지의 색상을 바꿀 수 있다.

(14) Diagrams를 선택

(15) GraphViz를 이용하기 위해 "Use dot tool from the GraphViz package"를 선택하고 원하는 Diagrams을 체크

(16) Expert 탭을 클릭(Wizard에서 설정한 기본적인 셋팅에 세부적인 셋팅을 추가 할 수 있다.)

(17) Project를 클릭

(18) 한글로 인코딩하기 위해 "EUC-KR"을 입력

(19) Output Language로 "Korean-en"을 선택

(20) Build 를 클릭

(21) 모든 소스들이 빠지지 않도록 필요한 항목들을 체크

(22) Dot을 클릭

(23) UML_LOOK을 선택

(24) Diagram을 생성한 파일의 포맷을 지정. jpg선택

(25) 설치한 Graphviz의 폴더의 하위에 위치한 bin 폴더를 선택

(26) Run을 Click

(27) "Run doxygen" 버튼을 클릭하게 되면, 이제 까지 설정한 값들을 이용하여 문서를 생성을 한다.

(28) "Doxygen has finished" 메시지를 확인 한 후, "Show HTML output"을 클릭하면 생성한 문서의 index.html을 브라우저로 Open을 한다.

 

이상으로 HTML Format의 Document를 생성을 해보았다.

마지막으로 한가지 더 해주어야 할 부분이 있는데, 위에서 설정한 값들을 저장을 해두지 않으면 다음에 Doxygen을 실행하고 번거롭게 모든 셋팅을 다시 하여야 한다.

프로그램의 상위의 "File->Save"를 선택하여 현재 Settings을 꼭! 저장을 하여, 다음에 문서를 생성할 때는 "File->Open"이나 "File->Open Recent"를 이용하여 이전의 셋팅 값들을 읽어들이자.

반응형

'SW개발' 카테고리의 다른 글

[Linux][VIM설정]  (0) 2012.07.31
[Linux][Screen]  (1) 2012.07.31
[Linux][alias 사용]  (1) 2012.07.31
[UML Diagram과 StarUML]  (0) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[GIT]  (0) 2011.11.21
[Linux 기본 명령어]  (0) 2011.10.19
[안드로이드 버전 정보]  (0) 2011.10.10
[Jar파일에서 Class쉽게 찾기]  (0) 2011.09.27
[안드로이드]SQLite Client Tool  (2) 2011.09.16
반응형

안드로이드 소스는 주로 GIT이라는 파일형상화 툴을 이용합니다. (App개발이 아닌, Framework개발)

 

●GIT 사용자 설명서(한글)

: http://goo.gl/aMvtY

 

●GIT Download, 설명: Git Community Book (maintained by Scott Chacon)

: http://book.git-scm.com/

●Android 개발환경

:http://source.android.com/source/initializing.html

  

●리누즈토발즈 GIT(깃) 소개 동영상

●기본적인 명령어

git --version

현재 git의 버전을 확인합니다.

 

git init

현재 디렉토리에 git 저장소를 생성합니다.

 

git add 파일명

git add는 2가지를 하는데 untracked files의 파일들을 git가 추적하도록 하거나 파일은 수정했지만 아직 스테이징 영역에 올라가지 않은(Changed but not updated) 파일들을 스테이징 영역에 올립니다. -i 옵션을 주면 대화형모드가 시작되며 파일의 일부분만 선택해서 스테이징하는 것이 가능합니다. -p 옵션을 사용하면 -i 대화형모드없이 바로 패치모드를 사용할 수 있습니다.

 

git commit -m "커밋메시지"

스테이징 영역에 올라가 있는 파일들을 커밋합니다. -m 은 커밋메시지를 주는 옵션으로 여러 줄의 커밋메시지를 쓸 경우 -m 을 여러개 사용할 수 있습니다. -a 옵션을 사용하면 스테이징에 올리는 작업과 커밋을 동시에 할 수 있습니다.(추적되지 않는 파일은 추가하지 않습니다.) -m을 사용하지 않을때 -v옵션을 사용하면 편집기에 커밋하려는 변경사항의 다른점을 보여줍니다. 특정파일만 커밋하려면 마지막에 파일명을 추가해주면 됩니다.

 

git commit -C HEAD -a --amend

지정한 커밋의 로그메시지를 다시 사용하여 기존커밋을 수정합니다. -c를 사용하면 기존메시지를 수정할 수 있는 편집기를 실행해 줍니다.

 

git status

커밋되지 않은 변경사항을 조회합니다.

 

git diff

스테이징영역과 현재 작업트리의 차이점을 보여줍니다. --cached 옵션을 추가하면 스테이징영역과 저장소의 차이점을 볼 수 있다. git diff HEAD를 입력하면 저장소, 스테이징영역, 작업트리의 차이점을 모두 볼 수 있다. 파라미터로 log와 동일하게 범위를 지정할 수 있으며 --stat를 추가하면 변경사항에 대한 통계를 볼 수 있습니다.

 

git mv 파일명 새파일명

기존에 존재하는 파일을 새파일로 이동합니다. 변경이력은 그대로 유지합니다.

 

git checkout -- 파일명

아직 스테이징이나 커밋을 하지 않은 파일의 변경내용을 취소하고 이전 커밋상태로 돌립니다. svn에서 revert와 동일합니다.

 

 

 

 

●Branch와 Tag

git branch

현재 존재하는 브랜치를 조회합니다. -r 옵션을 사용하면 원격저장소의 브랜치를 확인할 수 있습니다.

 

git branch 브랜치명B 브랜치명A

브랜치명A에서 새로운 브랜치 브랜치명B를 만듭니다. (git에서 기본 브랜치는 master라는 이름을 사용합니다.)

 

git branch 브랜치명

브랜치명의 새로운 브랜치를 만듭니다.(체크아웃은 하지 않습니다.)

 

git branch -d 브랜치명

브랜치를 삭제합니다.

 

git branch -m 존재하는브랜치명 새로운브랜치명

존재하는 브랜치를 새로운브랜치로 변경합니다. 이미 존재하는 브랜치명이 있을 경우에는 에러가 나는데 -M 옵션을 사용하면 이미 있는 브랜치의 경우에도 덮어씁니다.

 

git tag 태그명 브랜치명

브랜치명의 현재시점에 태그명으로 된 태그를 붙힙니다. git tag만 입력하면 현재 존재하는 태그 목록을 볼 수 있습니다.

 

git checkout 브랜치명/태그명

해당 브랜치나 태그로 작업트리를 변경합니다.

 

git checkout -b 브랜치명B 브랜치명A

브랜치명A에서 브랜치명B라는 새로운 브랜치를 만들면서 체크아웃을 합니다.

 

git rebase 브랜치명

브랜치명의 변경사항을 현재 브랜치에 적용합니다.

 

git merge 브랜치명

브랜치명의 브랜치를 현재 브랜치로 합칩니다. --squash 옵션을 주면 브랜치명의 모든 커밋을 하나의 커밋으로 만듭니다.

 

git cherry-pick 커밋명

커밋명의 특정 커밋만을 선택해서 현재 브랜치에 커밋으로 만듭니다. -n 옵션을 주면 작업트리에 합치지만 커밋은 하지 않기 때문에 여러개의 커밋을 합쳐서 커밋할 수 있습니다.

 

 

 

 

●로그 관리

git log

커밋로그들을 볼 수 있으면 -1나 -2같은 옵션을 주어 출력할 커밋로그의 갯수를 지정할 수 있습니다. --pretty=oneline 옵션을 주면 한줄로 간단히 보여주고 --pretty=format:"%h %s"처럼 형식을 정해줄 수 있습니다. -p 옵션을 사용하면 변경된 내용을 같이 보여줍니다. --since="5 hours" 이나 --before="5 hours"같은 옵션도 사용가능합니다.

 

git log 커밋명

해당 커밋명의 로그를 볼 수 있습니다. 커밋명A..커밋명B (마침표2개)와 같이 입력하면 커밋명A이후부터 커밋명B까지의 로그를 볼 수 있습니다. ^은 -1과 동일해서 HEAD^라고 하면 최신바로 이전 커밋이고 HEAD^^^와 같이 쓸 수 있으며 HEAD~3을 하면 HEAD의 3개 이전의 커밋을 뜻합니다.

 

git blame 파일명

갈 줄 앞에 커밋명과 커밋한 사람등의 정보를 볼 수 있습니다.

 

git blame -L 10,15 파일명

-L 옵션을 사용하면 10줄부터 15줄로 범위를 지정해서 볼수 있고 15대신 +5와 같이 사용할 수 있습니다. 숫자의 범위 대신 정규식도 사용이 가능합니다.

 

git blame -M 파일명

-M 옵션을 사용하면 반복되는 패턴을 찾아서 복사하거나 이동된 내용을 찾아줍니다. -C -C 옵션을 사용하면 파일간의 복사한 경우를 찾아줍니다. -C -C는 git log에서도 사용가능하며 내용의 복사를 찾을때는 git log에서 -p옵션을 사용합니다.

 

git revert 커밋명

기존의 커밋에서 변경한 내용을 취소해서 새로운 커밋을 만듭니다. -n옵션을 사용하면 바로 커밋하지 않기 때문에 revert를 여러번한 다음에 커밋할 수 있습니다.(항상 최신의 커밋부터 revert해야 합니다.)

 

git reset 커밋명

이전 커밋을 수정하기 위해서 사용합니다. --soft 옵션을 사용하면 이전 커밋을 스테이징하고 커밋은 하지 않으며 --hard옵션은 저장소와 작업트리에서 커밋을 제거합니다.

 

git rebase -i 커밋범위

-i옵션으로 대화형모드로 커밋 순서를 변경하거나 합치는 등의 작업을 할 수 있습니다.

 

 

●원격저장소

git clone 저장소주소 폴더명

원격저장소를 복제하여 저장소를 생성합니다. 폴더명을 생략가능합니다.

 

git fetch

원격저장소의 변경사항 가져와서 원격브랜치를 갱신합니다.

 

git pull

git fetch에서 하는 원격저장소의 변경사항을 가져와서 지역브랙치에 합치는 작업을 한꺼번에 합니다. 파라미터로 풀링할 원격저장소와 반영할 지역브랜치를 줄 수 있습니다.

 

git push

파라미터를 주지 않으면 origin 저장소에 푸싱하며 현재 지역브랜치와 같은 이름의 브랜치에 푸싱합니다. --dry-run 옵션을 사용하면 푸싱된 변경사항을 확인할 수 있습니다. 로컬에서 tag를 달았을 경우에 기본적으로 푸싱하지 않기 때문에 git push origin 태그명이나 모든 태그를 올리기 위해서 git push origin --tags를 사용해야 합니다.

 

git remote add 이름 저장소주소

새로운 원격 저장소를 추가합니다.

 

git remote

추가한 원격저장소의 목록을 확인할 수 있습니다.

 

git remote show 이름

해당 원격저장소의 정보를 볼 수 있습니다.

 

git remote rm 이름

원격저장소를 제거합니다.

 

 

●서브모듈

git submodule

연관된 하위모듈을 확인할 수 있습니다.

 

git submodule add 저장소주소 서브모듈경로

새로운 하위모듈을 해당경로에 추가합니다. 추가만하고 초기화 하지는 않으며 커밋해쉬앞에 마이나스(-) 표시가 나타납니다.

 

git submodule init 서브모듈경로

서브모듈을 초기화 합니다.

 

git submodule update 서브모듈경로

서브모듈의 변경사항을 적용합니다.(저장소의 최신커밋을 추적하지 않습니다.)

 

 

●기타 명령어

git archive --format=tar --prefix=폴더명/ 브랜치혹은태그 | gzip > 파일명.tar.gz

git archive --format=zip --prefix=폴더명/ 브랜치혹은태그 > 파일명.zip

해당 브랜치나 태그를 압축파일로 만듭니다. --prefix를 주면 압축하일이 해당폴더 안에 생성되도록 할 수 있습니다.

 

git mergetool

설정에 merge.tool의 값에 있는 머지툴을 찾아서 실행합니다.

 

git gc

저장소의 로그를 최적화 합니다. 로그가 변경되지는 않고 저장하는 방식만 최적화 합니다. --aggressive 옵션을 주면 더 자세하게 최적화합니다.

 

git rev-parse --show-toplevel

git 저장소내에서 입력하면 루트디렉토리를 알려줍니다.

반응형

'SW개발' 카테고리의 다른 글

[Linux][Screen]  (1) 2012.07.31
[Linux][alias 사용]  (1) 2012.07.31
[UML Diagram과 StarUML]  (0) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[Linux 기본 명령어]  (0) 2011.10.19
[안드로이드 버전 정보]  (0) 2011.10.10
[Jar파일에서 Class쉽게 찾기]  (0) 2011.09.27
[안드로이드]SQLite Client Tool  (2) 2011.09.16
[안드로이드 로그 보는 툴]  (0) 2011.09.02
반응형

리눅스 기본 명령어들 입니다.

which

환경변수 Path내에 설정되어 있는 경로내에서, 해당 명령어의 경로를 확인 하는 명령어.

#which ls

/bin/ls

 

●date

서버의 시스템 날짜와 시간을 확인하는 명령어.

#date

2011. 10. 19. (수) 10:25:48 KST

 

●cal

간단하게 달력을 표시해주는 명령어.

#cal

 

●hwclock

하드웨어 시간 확인을 하거나, 시스템시간과 하드웨어 시간을 동기화하는 명령어.

[option] :

-r :하드웨어 시간확인

-w :하드웨어 시간을 시스템 시간과 동기화

-s : 시스템시간을 하드웨어 시간과 동기화

#hwclock –r

2011년 10월 19일 (수) 오전 01시 19분 08초 -0.250635 seconds

 

●time

명령어의 수행시간을 확인하는 명령어.

:time [수행명령어]

#time ls –al

real 0m0.057s

user 0m0.000s

sys 0m0.010s

 

●id

사용자의 이름으로 해당 사용자의 uid, gid, 그룹을 표시하는 명령어.

:id [user id]

#id root

uid=0(root) gid=0(root) 그룹들=0(root)

 

●whoami, logname, who am i

시스템에 로그인한 현재 사용자를 표시하는 명령어.

#whoami

root

 

●w, who, users, finger

서버에 접속한 모든 사용자의 접송정보와 작업을 표시하는 명령어.

: # w [option] [user_name]

option : -h(head 정보를 출력하지 않음)

-s(login time, JCPU, PCPU 정보를 생략하고 간단히 출력)

-f(IP 주소정보를 생략 후 출력)

#w

 

●mesg

Write, talk, wall등을 이용하여 메시지를 받을 수 있는데, 수신 가능한지 확인하고 셋팅하는 명령어.

:mesg [n|y]

#mesg

is y

 

●write

콘솔 상에서 다른 사용자에게 메시지를 보내는 명령어.

:write [user_name]

#write testuser

Hihihihi

 

●wall

콘솔 상에서 모든 사용자에게 메시지를 보내는 명령어.

#wall

Test broad cast

 

●sync

명령어의 실행 결과로 변동된 사항을 적용하기 위한 명령어.

 

●hostname

현재 서버의 host name을 확인하기 위한 명령어.

 

●whatis

매뉴얼 페이지에 있는 명령어의 간단한 설명을 표시하는 명령어.

#whatis ls

ls (1) - list directory contents

 

●man

매뉴얼 페이지에 있는 명령어의 자세한 설명을 표시하는 명령어.

: man [option] [섹션] [명령어]

#man ls

 

●manpath

Manual의 위치를 표시하는 명령어.

#manpath

/usr/local/man:/usr/local/share/man:/usr/share/man

 

●sleep

일정시간 대기하고자 할 때 사용하는 명령어, 명령어 사이에 사용.

#sleep 10

10초간 sleep

 

●arch

시스템의 CPU에 대한 정보를 확인하는 명령어.

#arch

x86_64

 

●clear

터미널 화면의 모든 메시지를 비울 때 사용. DOS의 cls명령과 동일

 

●env

사용자의 환명변수를 모두 출력하는 명령어.

 

●source

스크립트나 설정 파일들을 수정한 후에 수정된 값이 적용되도록 하는 명령어.

#source [file_name]

 

●uname

시스템에 대한 정보를 출력하는 명렁어

:option : -a(모든 정보 출력)

-m(하드웨어 타입 출력)

-n(호스트명 출력)

-r(운영체제의 릴리즈 번호를 출력)

-s(운영체제 이름 출력)

-v(운영체제 버전 출력)

#uname -a

Linux server 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux

 

●history

사용자의 홈 디렉터리에는 .bash_history 파일이 있으며 이 파일에는 사용자가 사용했던 명령어들이 기록됨.

이를 확인하는 명령어가 history 이며, 이 명령어를 사용하면 현재까지 사용했던 명령어들의 전체 목록이 출력

:history [숫자] [옵션]

option : -w[파일] (지정한 파일에 history 명령어의 실행 결과를 출력합니다.)

-a(히스토리 파일에 히스토리 행을 추가합니다.)

-n(히스토리 파일로부터 현재 히스토리 목록으로 아직 읽어 들이지 않는 히스토리 행을 읽어 들입니다. 현재 bash 세션 시작부터 히스토리 파일에

추가한 행을 말합니다.

-r(히스토리 파일의 내용을 읽어 현재 히스토리로 사용합니다.

#history

 

●du

용량을 체크하는 명령어

: du [옵션]... [파일]...

option : -h : 사람이 보기 좋게 용량을 구분

#du -h

#du -h --max-depth=2

#du -h --max-depth=1

#du -sh ./*   -> 현재 위치의 폴더별 사용량 확인

●nohup
서버를 접속한 터미널에서 아래와 같은 간단한 명령을 이용하면, 터미널을 종료해도 Background로 repo sync 같은 작업 가능.
nohup : 터미널을 닫아도 끊지않음 

$nohup repo sync &

●grep
파일내에서 원하는 문자열 검색하여 찾는 명령어
-R : 폴더의 하위 폴더까지 검색 

#grep -e  search_word /home/ -R


●tee
파이프 중간에 사용하여 입력을 출력으로 보내기 전에 파일로 기록하는 명령어
파일에도 기록하고 화면에도 출력됨.
#ls -al /bin | tee test.txt


반응형

'SW개발' 카테고리의 다른 글

[Linux][alias 사용]  (1) 2012.07.31
[UML Diagram과 StarUML]  (0) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[GIT]  (0) 2011.11.21
[안드로이드 버전 정보]  (0) 2011.10.10
[Jar파일에서 Class쉽게 찾기]  (0) 2011.09.27
[안드로이드]SQLite Client Tool  (2) 2011.09.16
[안드로이드 로그 보는 툴]  (0) 2011.09.02
[VI 명령어]  (0) 2011.08.29
반응형

안드로이드에는 플랫폼 버전, API 레벨, 버전 코드명이 있습니다.

사용자들이 주로 알고 있는 것은 Version Code명이며, 이를 기반으로 안드로이드 버전을 이야기합니다.

 

하지만 개발자가 주로 알고 필요로 하는 버전은 Platform Version입니다. 이 버전을 이용하여 다른 사람들과 Communication하곤 합니다.

추가로 API Level도 잘 알고 있어야지 호환성을 표시하거나 알려줄 수 있습니다.

 

현재 아이스크림샌드위치라는 Version Code명으로 차기 플랫폼 개발이 되고 있습니다.

아래의 각 플렛폼 버전 별 API 및 Code표 참고 하시기 바랍니다.

Platform Version

API Level

VERSION_CODE

Android 3.2

13

HONEYCOMB_MR2

Android 3.1.x

12

HONEYCOMB_MR1

Android 3.0.x

11

HONEYCOMB

Android 2.3.4

10

GINGERBREAD_MR1

Android 2.3.3

   

Android 2.3.2

9

GINGERBREAD

Android 2.3.1

   

Android 2.3

   

Android 2.2.x

8

FROYO

Android 2.1.x

7

ECLAIR_MR1

Android 2.0.1

6

ECLAIR_0_1

Android 2.0

5

ECLAIR

Android 1.6

4

DONUT

Android 1.5

3

CUPCAKE

Android 1.1

2

BASE_1_1

Android 1.0

1

BASE

 

▶공식 API정보 링크

- http://developer.android.com/guide/appendix/api-levels.html

반응형

'SW개발' 카테고리의 다른 글

[UML Diagram과 StarUML]  (0) 2012.07.31
[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[GIT]  (0) 2011.11.21
[Linux 기본 명령어]  (0) 2011.10.19
[Jar파일에서 Class쉽게 찾기]  (0) 2011.09.27
[안드로이드]SQLite Client Tool  (2) 2011.09.16
[안드로이드 로그 보는 툴]  (0) 2011.09.02
[VI 명령어]  (0) 2011.08.29
[UML Class Diagram]  (0) 2011.08.26
반응형

안드로이드를 개발하다 보면 Java Project에서 Class를 찾지 못하는 에러가 발생할 수 있다.

이 때는 Class를 포함한 Jar파일을 찾아야 하는데, 도무지 어디에 들어있는지 찾기 어려운 경우가 발생한다.

어려움을 쉽게 해결할 수 있는 Eclipse용 플러그인이 있으므로, 이를 활용하도록 하자.

 

다운로드 : 

 

http://www.alphaworks.ibm.com/tech/jarclassfinder

   

다운받은 jar 파일을 eclipse > plugins 폴더에 넣는다. 그리고 eclipse 재시작한다. 그러면 메뉴쪽 아이콘에 암모나이트 비슷한 것이 추가 된게 보일것이다. 그 아이콘을 클릭하면 Java class Finder 라는 창이 열리며class 에 찾고자 하는  클래스명을, Search Directory 에 application 이 사용하고 있는 lib 폴더 위치를

지정한다. 

찾고자 하는 클래스명을 넣고 옵션을 설정한후 Find 를 클릭하게 되면 검색된 파일들을 표시하기 
위한 리스트 창이 뜬다. 쓰고자 하는 클래스가 없을 때 그게 포함된 jar 를 찾아야 되는데 일일이 다

열어보며 찾을려면 보통일이 아니다. 이 플러그인을 잘 활용하면 많은 수고를 덜수 있을 것이다.

 

찾은 결과에서 마우스 오른쪽을 클릭하면 아래와 같은 메뉴가 나온다.

이들 메뉴를 이용하여 쉽게 해당 class가 포함된 jar를 추가 할 수 있다.

  1. Add to Project Build Path : 프로젝트에 쉽게 jar를 추가
  2. Copy Location : 위치 복사
  3. Open Containing Folder : 폴더 열기
반응형

'SW개발' 카테고리의 다른 글

[Android][APK구성 및 생성 절차]  (0) 2012.07.18
[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[GIT]  (0) 2011.11.21
[Linux 기본 명령어]  (0) 2011.10.19
[안드로이드 버전 정보]  (0) 2011.10.10
[안드로이드]SQLite Client Tool  (2) 2011.09.16
[안드로이드 로그 보는 툴]  (0) 2011.09.02
[VI 명령어]  (0) 2011.08.29
[UML Class Diagram]  (0) 2011.08.26
Unified Modeling Language (UML)  (0) 2011.08.26
반응형

Android의 DB는 SQLite를 사용하며, 이 디비를 확인해봐야 할 경우가 있습니다.

이 때 사용할 수 있는 것이 SQLite 클라이언트 툴들입니다.

이 툴들을 이용해서 DB 테이블의 속성 및 DB에 저장된 내용등을 확인하고 수정할 수 있습니다.

 

기본적으로 장치에서 각각의 APP의 DB의 위치는 아래와 같습니다.

/data/data/APP패키지/databases/data

 

이 DB를 컴퓨터로 ADB를 이용해서 복사합니다.

 

●첫 번째로 소개할 프로그램은 "SQLite Database Browser"입니다.

설치가 필요 없고 Simple합니다. "Simple is the best."라는 말이 있듯이 저는 주로 이 툴을 이용합니다.

-다운로드 : http://sourceforge.net/projects/sqlitebrowser/files/sqlitebrowser/2.0%20beta1/sqlitebrowser_200_b1_win.zip/download

 

 

●두 번째 프로그램은 "SharpPlus Sqlite Developer Lite" 입니다.

설치가 필요하며 GUI가 처음에 소개한 툴보다 화려하며 더 많은 기능을 제공하며, 유료와 무료가 있습니다.

무료로 받으실 때는 아래와 같이 lite버전을 다운 받으면 됩니다.

-SharpPlus Sqlite Developer Lite 3.7.3 (8M) (Freeware)

-다운로드 : http://www.sqlitedeveloper.com/sqlite-developer-sqlite3-database-manager

  sql

어느 것이 좋다라고 할 수 없습니다. 다만 사용자의 목적에 맞게 사용하시면 그 것이 자기의 최고의 툴이 됩니다.


반응형

'SW개발' 카테고리의 다른 글

[“Doxygen”을 이용한 Document생성]  (0) 2012.03.21
[GIT]  (0) 2011.11.21
[Linux 기본 명령어]  (0) 2011.10.19
[안드로이드 버전 정보]  (0) 2011.10.10
[Jar파일에서 Class쉽게 찾기]  (0) 2011.09.27
[안드로이드 로그 보는 툴]  (0) 2011.09.02
[VI 명령어]  (0) 2011.08.29
[UML Class Diagram]  (0) 2011.08.26
Unified Modeling Language (UML)  (0) 2011.08.26
[Source Insight]편하게 주석달기2  (0) 2011.04.27
반응형

 

안드로이드 로그 보는 툴을 찾다가 "LogFilter"를 찾았습니다.

로그에서 검색하거나 Filter 및 북마크 까지 되는 Android log viewer입니다.

내가 찾은 것 중에 가장 괜찮긴 한데, 더 좋은 Vewer 가지고 계신분?

 

개인적으로 개선되었으면 하는 점들.

  • 원하는 단어에 대해 라인 단위로 색깔 선택 기능
  • 북마크 저장 기능
  • 북마크에 캡션 다는 기능

 

다운로드 : http://blog.naver.com/iookill/140122121206

반응형

'SW개발' 카테고리의 다른 글

[GIT]  (0) 2011.11.21
[Linux 기본 명령어]  (0) 2011.10.19
[안드로이드 버전 정보]  (0) 2011.10.10
[Jar파일에서 Class쉽게 찾기]  (0) 2011.09.27
[안드로이드]SQLite Client Tool  (2) 2011.09.16
[VI 명령어]  (0) 2011.08.29
[UML Class Diagram]  (0) 2011.08.26
Unified Modeling Language (UML)  (0) 2011.08.26
[Source Insight]편하게 주석달기2  (0) 2011.04.27
Clear Case 를 Source Insight와 Beyond Compare와 연동하기  (0) 2011.04.26
반응형

유닉스 계열에서 SW개발하려고 할 때 사용하는 VI/VIM 기본 명령어(Command) 입니다.

 

  • VI/VIM Lesson 1 – basic editing (편집)

 

  • VI/VIM Lesson 2 – operators & repetition

 

  • VI/VIM Lesson 3 – yank & paste (복사 & 붙여넣기)

 

  • VI/VIM Lesson 4 – searching(검색)

 

  • VI/VIM Lesson 5 – basic editing

 

  • VI/VIM Lesson 6 – various motions

 

  • VI/VIM Lesson 7 – various commands

● 유용한 명령어

w

오른쪽 한 단어의 끝 부분으로 커서 이동

e

오른쪽 한 단어의 앞 부분으로 커서 이동

b

왼쪽 한 단어의 앞 부분으로 커서 이동

Enter

한 행 아래로 커서 이동

Back space

한 문자 왼쪽으로 커서 이동

Space bar

한 문자 오른쪽으로 커서 이동

^

행의 맨 왼쪽으로 커서 이동

$

행의 맨 오른쪽으로 커서 이동

H

화면의 맨 위로 이동

M

화면의 중간으로 이동

L

화면의 맨 아래로 이동

"숫자"G

"숫자"만큼 지정한 줄로 커서 이동

a (종료 : esc)

커서 오른쪽에 문자 삽입

A (종료 : esc)

커서 오른쪽, 행의 끝에 문자 삽입

i (종료 : esc)

커서 왼쪽에 문자 삽입

(종료 : esc)

커서 왼쪽, 행의 처음에 문자 삽입

o (종료 : esc)

커서 아래에 행 삽입

O (종료 : esc)

커서 위에 행 삽입

cw (종료 : esc)

단어 변경

cc (종료 : esc)

행 변경

(종료 : esc)

커서 오른쪽의 행 변경

s (종료 : esc)

커서가 위치한 문자열 대체

S (종료 : esc)

커서가 위치한 라인의 문자열 대체

r

커서 위치 문자를 다른 문자로 대체

r-Enter

행 분리

J

현재 행과 아래 행 결합

xp

커서 위치 문자와 오른쪽 문자 교환

~

문자형(대, 소문자) 변경

u

이전 명령 취소

U

행 변경 사항 취소

:u

이전의 최종 행 취소

.

이전 최종 명령 반복


x

커서가 있는 문자 삭제

5x

커서가 있는 위치부터 5개의 문자를 삭제

dw

현재 커서가 있는 한 단어 삭제

dd

커서가 있는 라인 삭제

5dd

커서가 있는 라인부터 5개의 라인 삭제

db

커서의 위치에서 거꾸로 한 단어 삭제

D

커서 오른쪽 행 삭제

:5,10d

5-10번째 행 삭제

yy

행 yank 또는 복사

Y

행 yank 또는 복사

P

yank되거나 삭제된 행 현재 행 위에 삽입

p

yank되거나 삭제된 행 현재 행 아래에 삽입

:1,2 co 3

1-2행을 3행 다음으로 복사

:4,5 m 6

4-5행을 6행 위로 이동

:set nu

행 번호 표시

:set nonu

행 번호 숨기기

G

파일의 마지막 행으로 가기

21G

파일의 21번째 행으로 가기

ctrl + G

현재의 filename과 line수를 알려줌

/검색할 문자열/

오른쪽 아래 방향으로 문자열 검색

?검색할 문자열?

왼쪽 위 방향으로 문자열 검색

n

문자열의 다음으로 계속 검색

N

문자열의 이전으로 계속 검색

:g/search-string/s//replace-

각 발생 탐색 후 확인하고 대체

string/gc


:s/str/rep/

현재 행의 str을 rep로 대체

:1,.s/str/rep/

1부터 현재 행의 str을 rep로 대체 파일

:%s/str/rep/g

전체 str을 rep로 전부 대체

:.$/aaa/bbb/

커서의 위치로부터 파일의 끝까지 있는 모든 aaa를 bbb로 대체

:! [file name]

vi열린 상태에서 외부명령어 실행

ctrl + I

불필요한 화면 정리 후 다시 표시

:r [file name]

커서 다음에 파일 삽입

:34 r [file name]

파일을 34번째 행 다음에 삽입

:e [file name]

파일 열기

:w

변경사항 저장

:w [file name]

버퍼를 파일로 보관

:wq

변경사항 보관 후 vi 종료

:ZZ

변경사항 보관 후 vi 종료

:q!

변경사항 보관하지 않고 종료

:q

수정한 파일을 저장하지 않고 vi 종료

:e!

수정한 것을 무시하고 다시 편집상태로

반응형
반응형

글은 Unified Modeling Language(UML)에서 사용되었던 필수 다이어그램에 관한 기술자료 시리즈입니다. 시퀀스 다이어그램에 대해 설명했던 이전 기술자료에서는, UML 1.4 스팩에서OMG Adopted 2.0 Draft Specification of UML (UML 2) 초점을 이동했습니다. 글에서는 UML 2 도입된 새로운 다이어그램 카테고리인 Structure Diagram 대해 설명합니다. 시리즈의 목적은 표기법 요소들과 이들의 의미를 설명하는 것이므로, 글에서는 주로 클래스 다이어그램에 초점을 맞춥니다. 이렇게 하는 이유는 명확해 것입니다. 후속 기술자료에서는 Structure 카테고리에 포함된 기타 다이어그램을 설명합니다.

글을 읽는 독자들에게 다시 한번 당부하고 싶은 것은 UML 표기법 요소들에 관한 것이고, 글은 모델링에 대한 최상의 접근 방식에 대한 가이드나 번째로 모델링 되어야 것을 결정하는 방법에 대해서는 설명하지 않습니다. 글의 목표이자 시리즈의 목표는 표기법 엘리먼트에 대한 기본적인 지식, 신택스와 의미를 설명하는 것입니다. 이러한 지식을 기반으로 여러분은 다이어그램을 읽고 알맞은 표기법 요소들을 사용하여 자신만의 다이어그램을 만들 있습니다.

여러분은 객체 지향 디자인에 대한 기본적인 지식이 있을 것으로 간주하겠습니다. OO 개념에 대한 설명이 필요하다면http://java.sun.com/docs/books/tutorial/java/concepts/에서 객체 지향 프로그래밍을 다룬 Sun 튜토리얼을 보시기 바랍니다. "What Is a Class?"  "What Is Inheritance?" 섹션에서는  글을 읽을 도움이 만한 정보들이 있습니다. 또한 David Taylor Object-Oriented Technologies: A Manager's Guide 역시 객체 지향 디자인을 설명하고 있습니다.

UML 2 음과

UML 2에는 가지 기본적인 다이어그램 카테고리가 있다. 모든 UML 다이어그램은 개의 다이어그램 카테고리들 하나에 속해있다. 구조 다이어그램(structure diagram) 목적은 모델링 되는 시스템의 정적인 구조를 보여주는 것이다. 여기에는 클래스 다이어그램, 컴포넌트 다이어그램, 객체 다이어그램이 포함된다. 작동 다이어그램(Behavioral diagram) 시스템의 객체들 동적인 작동을 보여준다. 여기에는 메소드, 협업, 액티비티 등이 포함된다. 작동 다이어그램 예로는 액티비티 다이어그램, 유스 케이스 다이어그램, 시퀀스 다이어그램 등이 있다.

위로

구조 다이어그램

이미 언급했지만, 구조 다이어그램은 모델링 되는 시스템의 정적인 구조를 보여준다. 시간에 상관 없이 시스템의 요소들에 초점을 맞춘다. 정적 구조는 시스템에 있는 유형들과 이들의 인스턴스를 나타낸다. 시스템 유형과 인스턴스를 보여주는 외에도, 구조 다이어그램은 이러한 요소들 관계를 보여주고 심지어는 내부 구조까지도 보여준다.

구조 다이어그램은 소프트웨어 라이프 사이클 동안 멤버들에게 유용하게 사용된다. 일반적으로, 이러한 다이어그램은 디자인의 유효성 검사와 개인과 팀들 디자인 통신에 사용된다. 예를 들어, 비즈니스 분석가들은 클래스나 객체 다이어그램을 사용하여 계정 대장, 제품, 지리적 계층 같은 비즈니스의 현재 에셋(asset) 리소스를 모델링 있다. 아키텍트는 컴포넌트와 전개 다이어그램을 사용하여 자신들의 디자인이 튼튼하다는 것을 테스트 입증한다. 개발자들은 클래스 다이어그램을 사용하여 시스템의 코딩 (또는 코딩 ) 클래스들을 디자인 문서화 한다.

클래스 다이어그램

UML 2 구조 다이어그램을 하나의 범주로 간주한다. "Structure Diagram"이라고 하는 다이어그램은 없다. 하지만, 클래스 다이어그램은 구조 다이어그램 유형의 대표적인 예이며, 다른 모든 구조 다이어그램들이 사용하는 초기 표기법 요소들을 제공한다. 클래스 다이어그램은 너무나도 중요하기 때문에, 글에서는 클래스 다이어그램의 표기법 세트를 집중적으로 설명하겠다. 글을 읽고 나면 여러분은 UML 2 클래스 다이어그램을 그리는 방법을 이해하고, 다음 기술자료에서 다룰 다른 구조 다이어그램을 더욱 이해하게 것이다.

위로

기초

앞서 언급했던 것처럼, 클래스 다이어그램의 목표는 시스템 내에서 모델링 되는 유형을 보여주는 것이다. 대부분의 UML 모델에서는 다음과 같은 유형들이 있다.

UML 이러한 유형들에 대해 특별한 이름을 사용한다. 바로 "classifier"이다. 일반적으로, 여러분은 classifier 클래스로 생각할 있지만, 기술적으로 classifier 위에 언급한 다른 가지 유형들을 언급하는 보다 포괄적인 용어이다.

클래스 이름

클래스의 UML 표현은 수직적으로 쌓인 개의 부분들을 포함하고 있는 직사각형이다. (그림 1) 부분은 클래스의 이름을 나타낸다. 중간 부분은 클래스의 애트리뷰트이다. 부분은 클래스의 연산이다. 클래스 다이어그램에 클래스 요소를 그릴 , 부분은 반드시 사용해야 하고 밑에 개의 부분은 선택적이다. (밑에 부분은 Classifier 관계만 보여주는 것이 목적일 경우 고급 상세를 설명하는 다이어그램에서는 불필요 하다.) 그림 1 UML 클래스로서 모델링 항공 내역을 보여준다. 이름은 Flight이고, 중간 부분에는 Flight 클래스에 개의 애트리뷰트, flightNumber, departureTime, flightDuration 있다. 부분에서는 Flight 클래스가 개의 연산, delayFlight getArrivalTime 갖고 있다.

그림 1: Flight 클래스에 대한 클래스 다이어그램

클래스 애트리뷰트 리스트

클래스의 애트리뷰트 섹션(중간 부분) 클래스의 애티리뷰트를 라인 별로 나열한다. 애트리뷰트 섹션은 선택적이지만, 이것이 사용된다면 하나의 리스트 포맷으로 디스플레이 클래스의 애트리뷰트가 포함된다. 라인은 다음과 같은 포맷을 사용한다.

name : attribute type 

 

flightNumber : Integer 

 

Flight 클래스 예제에서, 애트리뷰트 유형 정보와 함께 클래스의 애트리뷰트를 기술할 있다. ( 1)

1: 애트리뷰트 유형 정보를 가진 Flight 클래스의 애트리뷰트 이름

 

비즈니스 클래스 다이어그램에서, 애트리뷰트 유형들은 다이어그램의 독자들이 이해할 있는 단위들에도 상응한다. (, (minute), 달러(dollar) ). 하지만, 코드를 생성하기 위해 사용될 클래스 다이어그램은 애트리뷰트 유형이 프로그래밍 언어에서 제공하는 유형 또는 시스템에 구현될 모델에 포함되는 유형으로 제한된 클래스가 필요하다.

가끔, 클래스 다이어그램에 특정 애트리뷰트가 기본 값을 갖고 있음을 보여주는 것도 유용하다. (예를 들어, 은행 계정 애플리케이션에서, 새로운 은행 계정은 잔액 0으로 시작한다.) UML 스팩은 다음과 같은 표기법을 사용함으로써, 애트리뷰트 리스트 섹션에 기본 값을 구분한다.

name : attribute type = default value 

 

예를 들어:

balance : Dollars = 0 

 

애트리뷰트에 대한 기본 값을 보여주는 것은 선택적이다. 그림 2 기본 값이 0, balance라고 하는 애트리뷰트를 가진 Bank Account 클래스를 보여준다.

그림 2: 기본 값이 0 달러인 balance 애트리뷰트의 값을 보여주는 Bank Account 클래스 다이어그램

클래스 연산 리스트

클래스의 연산은 클래스 다이어그램의 번째(가장 밑에 있는) 부분에 나타난다. 이것 역시 선택적이다. 애트리뷰트와 마찬가지로, 클래스의 연산은 리스트 포맷으로 디스플레이 되고, 라인마다 연산이 있다. 연산은 다음과 같은 표기법을 사용하여 문서화 된다.

    name(parameter list) : type of value returned 

 

Flight 클래스의 연산은 아래 2로도 매핑 있다.

2: 그림 2 표로 나타낸 Flight 클래스의 연산

 

그림 3 보면 delayFlight 연산이 Minutes 유형의 인풋 매개변수 numberOfMinutes 갖고 있다는 것을 있다. 하지만 delayFlight 연산에는 리턴 값이 없다.

 1 하나의 연산이 매개변수를 갖고 있을 , 매개변수들은 연산의 괄호 안에 놓이게 된다. 매개변수는 "parameter name : parameter type" 포맷을 사용한다.

그림 3: Flight 클래스 연산 매개변수들에는 "in" 표시가 포함된다.

연산의 매개변수들을 문서화 , 매개변수가 연산의 인풋인지 또는 아웃풋인지를 보여주기 위해 선택적인 인디케이터를 사용할 수도 있다. 이러한 선택적인 인디케이터는 그림 3 연산 부분에 나타난 것처럼 "in" 또는 "out"으로 나타난다. 일반적으로, 이러한 인디케이터는 Fortran 같은 오래된 프로그래밍 언어가 사용되지 않는 불필요하다. 하지만, C++ 자바에서, 모든 매개변수들은 "in" 매개변수들이고, "in" UML 스팩에 따라 매개변수의 기본 유형이기 때문에 대부분의 사람들은 인풋/아웃풋 인디케이터를 생략한다.

상속(Inheritance)

객체 지향 디자인의 가장 중요한 개념인 상속(inheritance) 하나의 클래스(자식 클래스) 다른 클래스(슈퍼 클래스) 동일한 기능을 상속받을 있고 고유의 새로운 기능을 추가할 있다는 것을 의미한다. (기술적인 비유법은 아니지만, 필자는 어머니의 음악적 재능을 물려받았고, 우리 가족 중에서 전자 기타를 연주할 있는 사람은 필자뿐이다.) 클래스 다이어그램에 상속을 모델링 하려면, 속이 투명한 화살표(또는 삼각형) 슈퍼 클래스를 향하도록 하여 자식 클래스(작동을 상속받는 클래스)로부터 직선이 그려진다. Bank Account 유형을 생각해 보자. 그림 4 CheckingAccount SavingsAccount BankAccount 클래스에서 상속을 받는 모습이다.

그림 4: 투명 삼각형 모양의 화살표가 슈퍼 클래스를 가리키면서 직선으로 상속이 표시된다.

그림 4에서, 상속 관계는 하위 클래스 마다 개별 라인으로 그려지는데, 이것은 IBM Rational Rose IBM Rational XDE에서 사용되는 방식이다. 하지만, 트리 표기법(tree notation)으로 상속을 그리는 방법도 있다. 그림 4처럼 이상의 자식 클래스들이 있을 트리 표기법을 사용할 있다. 나무 가지처럼 상속 라인들이 합쳐지는 경우는 예외이다. 그림 5 그림 4 상속을 트리 표기법으로 다시 그린 것이다.

Figure 5: 트리 표기법을 사용한 상속

추상 클래스와 연산 
주의력이 깊은 독자라면 그림 4 5 다이어그램이 BankAccount 클래스 이름과 withdrawal 연산에 이탤릭 체를 사용하고 있음을 알아챘을 것이다. BankAccount 클래스는 추상 클래스이고, withdrawal 메소드는 추상 연산이라는 것을 나타내는 것이다. 다시 말해서, BankAccount 클래스는 withdrawal 추상 연산을 제공하고 CheckingAccount SavingsAccount 개의 자식 클래스들은 각각의 연산 버전을 구현한다.

하지만, 슈퍼 클래스(부모 클래스) 추상 클래스일 필요가 없다. 일반적으로 표준 클래스가 슈퍼 클래스가 된다.

제휴(Association) 
시스템을 모델링 , 특정 객체들은 서로 연관될 것이고, 이러한 관계들이 명확하게 모델링 되어야 한다. 다섯 가지 제휴 유형들이 있다. 섹션에서는 가지 유형-양방향(bi-directional) 제휴와 일방향(uni-directional) 제휴를 설명하고, 나머지 가지 제휴 유형들은 기초를 넘어서 섹션에서 설명하도록 하겠다. 각각의 제휴 유형을 사용할 시기까지는 섹션에서는 설명하지 않겠다. 제휴 유형의 목표에 초점을 맞춰, 클래스 다이어그램에 제휴를 그리는 방법을 설명하도록 하겠다.

양방향 (표준) 제휴 
제휴는 클래스들간 연결이다. 제휴는 언제나 양방향(bi-directional)으로 간주된다. 다시 말해서, 일부 다른 유형으로 수정하지 않는 , 개의 클래스들이 서로를 인식하고 있고 관계를 알고 있다는 의미이다. 그림 6 Flight 클래스와 Plane 클래스 표준 제휴 유형이다.

그림 6: Flight 클래스와 Plane 클래스간 양방향 제휴 예제

양방향 제휴는 클래스들 일직선으로 표시된다. 라인의 끝에 역할과 값을 표시한다. 그림 6 Flight 특정 Plane 연결되어 있고, Flight 클래스는 이러한 관계를 알고 있다는 것을 보여준다. Plane 제휴 관계에서 "assignedPlane" 역할을 담당하고 있다. Plane 클래스 옆에 있는 역할 이름이 이를 말해주고 있다. Plane 옆에 있는 Multiplicity 0..1 Flight 인스턴스가 있을 , Plane 인스턴스가 이것과 연결되었거나, 어떤 Plane 이것과 연결되지 않았다(비행기가 아직 지정되지 않았을 경우) 것을 의미한다. 그림 6에서는 Plane Flight 클래스와의 제휴 관계를 인식하고 있음을 보여준다. 이러한 제휴 관계에서, Flight "assignedFlights" 역할을 맡는다. 그림 6 다이어그램은 Plane 인스턴스가 어떤 비행 스케줄과도 제휴될 없거나(새로운 비행기일 경우) 또는 많은 비행 스케줄( 비행기가 지난 5 동안 사용 중일 경우) 연결될 있다는 것을 나타낸다.

3에는 Multiplicity 값들과 이것의 의미를 정리했다.

3: Multiplicity 값과 인디케이터

 

일방향 제휴 
일방향 제휴에서는, 개의 클래스들은 관련이 있지만, 하나의 클래스만 관계를 인식하고 있다. 그림 7 일방향 제휴의 예제이다.

그림 7: 일방향 제휴 예제: OverdrawnAccountsReport 클래스는 BankAccount 클래스에 대해 알고 있지만, BankAccount 클래스는 제휴 관계에 대해 모른다.

일방향 제휴는 알려진 클래스를 가리키는 개방된 화살표(상속을 나타내는데 사용되었던 닫힌 또는 삼각형 화살표가 아니다.) 있는 직선으로 그려진다. 표준 제휴와 마찬가지로, 일방향 제휴에는 역할 이름과 Multiplicity 값이 포함되지만, 표준 양방향 제휴와는 달리, 일방향 제휴에는 알려진 클래스에만 역할 이름과 Multiplicity 값이 포함된다. 그림 7 예제를 보면, OverdrawnAccountsReport BankAccount 클래스에 대해 알고 있고 BankAccount 클래스는 "overdrawnAccounts" 역할을 수행한다. 하지만, 표준 제휴와는 달리, BankAccount 클래스는 이것이 OverdrawnAccountsReport 제휴되어 있다는 사실을 모른다. 2

패키지 
대형 시스템 또는 비즈니스의 유형을 모델링 한다면, 모델에 다양한 Classifier 있을 것이다. 모든 클래스들을 관리하기란 매우 어렵다. 따라서, UML 패키지(package)라고 하는 요소를 제공한다. 패키지는 모델러가 모델의 Classifier 네임스페이스로 구성할 있도록 하는데, 이는 일종의 파일링 시스템의 폴더와 같은 것이다. 시스템을 다중 패키지들로 나무면 시스템은 더욱 이해하기 쉽고, 특히 패키지가 시스템의 특정 부분을 나타낼 더욱 그렇다.
 3

다이어그램에 패키지들을 그리는 가지 방법이 있다. 어떤 표기법을 사용할 것인지 결정하는 규칙은 없다. 여러분이 그리는 클래스 다이어그램을 가장 쉽게 읽을 있는 방법을 기준으로 삼으면 된다. 가지 방법 모두 직사각형이 있고 좌측 상단 코너 쪽에 작은 직사각형()시작한다. (그림 8) 모델러는 패키지의 멤버쉽이 보여지는 방법을 결정해야 한다.

그림 8: 패키지의 직사각형 바운더리 안에 멤버들을 보여주는 패키지 엘리먼트 예제

그림 9: 연결된 선들을 통해 멤버쉽을 보여주는 패키지 엘리먼트 예제

기초 이해의 중요성

UML 2에서는 클래스 다이어그램의 기초를 이해하는 것이 중요해졌다. 클래스 다이어그램은 컴포넌트나 객체 다이어그램 모든 구조 다이어그램에 대한 기본 구현 블록을 제공하기 때문이다.

위로

기초를 넘어서

지금까지 클래스 다이어그램의 기초를 설명했다. 아직 끝나지 않았으니 계속 읽어주기 바란다. 이어지는 섹션에서는 클래스 다이어그램의 중요한 측면들을 설명하겠다. 인터페이스와, 남아있는 가지 제휴 유형들, 가시성(visibility), UML 2 스팩의 추가 요소들을 설명하겠다.

인터페이스 
초반에, 여러분이 classifiers 단순히 클래스로 간주할 것이라고 말한바 있다. 사실, Classifier 보다 일반적인 개념이고, 여기에는 데이터 유형과 인터페이스가 포함된다.

시스템의 구조 다이어그램에서 데이터 유형과 인터페이스를 효과적으로 사용할 시기와 방법을 설명하는 것은 글의 범위를 벗어난다. 그렇다면, 데이터 유형과 인터페이스를 언급했을까? 가끔은 구조 다이어그램에 이러한 Classifier 유형들을 모델링 해야 때가 있고, 이를 수행할 올바른 표기법을 사용하는 것이 중요하며, 적어도 Classifier 유형들에 대해서는 알고 있어야 한다. 이러한 Classifier들을 부정확하게 그리면 구조 다이어그램을 읽는 사람들이 혼란을 겪을 것이고, 시스템은 요구 사항을 채우지 못하게 된다.

클래스와 인터페이스는 다르다. 클래스는 유형의 실제 인스턴스를 가질 있지만, 인터페이스는 이를 실행할 적어도 개의 클래스를 가져야 한다. UML 2에서, 인터페이스는 클래스 모델링 요소를 특화 것으로 간주한다. 따라서, 인터페이스는 클래스처럼 그려지지만, 직사각형의 부분에는 "«interface»" 라는 텍스트가 붙는다. 그림 10 5

그림 10: Professor Student 클래스들이 Person 인터페이스를 구현하는 클래스 다이어그램 예제

그림 10 다이어그램에서, Professor Student 클래스들은 Person 인터페이스를 구현하는 것이지, Person 인터페이스에서 상속을 받지 않는다. 이렇게 말하는 데는 가지 근거가 있다. 1) Person 객체는 인터페이스로서 정의된다. 객체의 이름 영역에 "«interface»" 텍스트가 있고, Professor Student 객체들이 클래스 객체를 그리는 규칙에 따라 레이블링 되고 있기 때문에 이들이 클래스 객체들이라는 것을 알고 있다. (이름 영역에 추가적인 구분 텍스트가 없다.) 2) 화살표로 이어진 선이 점으로 되어있고 직선이 아니기 때문에 상속이 아니다. 그림 10에서 보듯, 속이 비어있는 폐쇄 화살표가 연결된 점선 구현을 의미한다. 그림 4에서 보듯, 속이 비어있는 폐쇄 화살표로 연결된 직선 상속을 의미한다.

기타 제휴 유형들 
앞서 양방향 제휴와 일방향 제휴를 설명했다. 이제는 나머지 가지 제휴 유형들을 설명하도록 하겠다.

제휴 클래스 
제휴를 모델링 , 관계에 대한 중요한 정보를 포함하고 있기 때문에 다른 클래스를 포함시켜야 때가 있다. 이러한 이유로, 여러분은 기본 제휴에 연결할 제휴 클래스 사용해야 한다. 제휴 클래스는 일반 클래스처럼 표현된다. 차이점은, 기본 클래스들간 제휴 라인은 제휴 클래스로 연결된 점선을 횡단한다. 그림 11 항공 관련 예제의 제휴 클래스 모습이다.

그림 11: 제휴 클래스 MileageCredit 추가하기

그림 11 클래스 다이어그램에서, Flight 클래스와 FrequentFlyer 클래스간 제휴는 MileageCredit라고 하는 제휴 클래스라는 결과를 만들어 낸다. Flight 클래스의 인스턴스가 FrequentFlyer 클래스의 인스턴스와 제휴될 , MileageCredit 클래스의 인스턴스도 생긴다.

애그리게이션(Aggregation) 
애그리게이션은 "전체와 부분들(whole to its parts)" 관계를 모델링 하는데 사용되는 특별한 제휴 유형이다. 기본적인 애그리게이션 관계에서, 부분(part) 클래스의 라이프 사이클은 전체(whole) 클래스의 라이프 사이클과는 무관하다.

예를 들어, Car 전체 엔터티로, Car Wheel 전체 Car 부분으로 생각할 있다. 바퀴는 먼저 만들어 있고 조립하는 동안 자동차에 부착되기 전에 웨어하우스에 놓일 있다. 예제에서, Wheel 클래스의 인스턴스는 Car 클래스의 인스턴스와는 독립적으로 존재한다. 하지만, 부분 클래스의 라이프 사이클이 전체 클래스의 라이프 사이클과 무관하지 않을 때가 있다. 이를 composition aggregation이라고 한다. 회사와 부서 관계를 생각해 보면 된다. 회사와 부서들은 클래스로 모델링 되고, 회사가 존재하기 전에 부서는 존재할 없다. 경우 Department 클래스의 인스턴스는 Company 클래스의 인스턴스에 종속적이다.

기본 애그리게이션과 Composition Aggregation 자세히 살펴보도록 하자.

기본 애그리게이션 
애그리게이션 관계와의 제휴는 하나의 클래스가 다른 클래스의 일부라는 것을 나타낸다. 애그리게이션 관계에서, 자식 클래스 인스턴스는 부모 클래스보다 오래 살아남는다. 애그리게이션 관계를 나타내려면, 부모 클래스에서 부분 클래스로 직선을 그리고, 부모 클래스의 제휴의 끝에 속이 비어있는 다이아몬드 모양을 그린다. 그림 12 Car Wheel 애그리게이션 관계 예제를 나타낸다.

그림 12: 애그리게이션 제휴 예제

Composition aggregation 
Composition Aggregation
관계는 애그리게이션 관계의 형태이지만, 자식 클래스의 인스턴스 라이프 사이클은 부모 클래스의 인스턴스 라이프 사이클에 종속적이다. 그림 13 Company 클래스와 Department 클래스 컴포지션 관계를 보여주는데, 컴포지션 관계는 애그리게이션 관계처럼 그려지지만, 이번에는 다이아몬드 속이 채워졌다.

그림 13: composition 관계 예제

그림 13에서 모델링 관계에서, Company 클래스 인스턴스에는 이상의 Department 클래스 인스턴스가 있다. 관계는 composition 관계이기 때문에, Company 인스턴스가 제거될 , Department 인스턴스도 자동적으로 제거된다. Composition Aggregation 다른 중요한 특징은 부분 클래스는 부모 클래스의 인스턴스와만 연결될 있다는 점이다. (우리 예제의 경우, Company 클래스)

반사 제휴(Reflexive association) 
지금까지, 모든 제휴 유형들에 대해서 살펴보았다. 여러분도 알다시피, 모든 예제들은 개의 다른 클래스들간 관계를 보여주었다. 하지만, 반사 제휴(reflexive association) 사용하여 하나의 클래스가 자체로 제휴될 수도 있다. 언뜻 이해가 되지 않지만, 클래스들이 추상적이라는 것을 기억하라. 그림 14 Employee 클래스가 manager 역할을 통해 스스로 연결되는 방법을 보여주고 있다. 하나의 클래스가 스스로 제휴를 맺을 , 클래스의 인스턴스도 스스로 제휴를 맺는 것이 아닌, 클래스의 인스턴스는 클래스의 다른 인스턴스와 연결된다는 것을 의미한다.

그림 14: 반사 제휴 관계 예제

그림 14 관계도는 Employee 인스턴스가 다른 Employee 인스턴스의 매니저가 있다는 것을 의미한다. 하지만, "manages" 관계 역할이 0..* Multiplicity 가질 있기 때문에 Employee 관리할 다른 Employee 없을 있다.

가시성 
객체 지향 디자인에서, 애트리뷰트와 연산에 대한 가시성 표기법이 있다. UML 가지 가시성 유형을 정의하고 있다: Public, Protected, Private, Package

UML 스팩에서는 클래스 다이어그램에 디스플레이 되는 애트리뷰트와 연산 가시성을 요하지 않지만, 애트리뷰트나 연산에 대해 정의되어야 한다고 정하고 있다. 클래스 다이어그램에 가시성을 디스플레이 하려면, 애트리뷰트 또는 연산의 이름 앞에 가시성 부호를 붙여야 한다. UML 가지 가시성 유형을 정의하지만, 실제 프로그래밍 언어는 추가 가시성들을 추가하거나, UML에서 정의된 가시성은 지원하지 않을 수도 있다. 4 UML에서 지원되는 가시성 유형에 대한 부호를 정리한 것이다.

4: UML 지원 가시성 유형에 대한 부호

이제 애트리뷰트와 연산에 대한 가시성 유형을 보여주는 클래스를 보자. 그림 15에서, 모든 애트리뷰트와 연산들은 Public이고, updateBalance 연산만 예외이다. updateBalance 연산은 Protected이다.

그림 15: 애트리뷰트와 연산의 가시성을 보여주는 BankAccount 클래스

위로

UML 2 추가

지금까지 기본적인 내용과 고급 주제들을 다루었다. 이제 UML 1.x 추가된 새로운 표기법에 대해 알아보자.

인스턴스 
시스템의 구조를 모델링 , 클래스의 예제 인스턴스를 보여주는 것이 가끔 유용하다. 이것을 모델링 하기 위해, UML 2 엘리먼트를 제공하는데, 이것은 시스템의 예시(또는 실제) 인스턴스 사용하여 흥미로운 정보를 보여준다.

인스턴스의 표기법은 클래스와 같지만, 부분에 클래스 이름 대신, 이름에는 밑줄이 생긴다.

Instance Name : Class Name 

 

예를 들어,

Donald : Person 

 

인스턴스를 보여주는 이유가 관심이 있거나 관련이 있는 정보를 보여주는 것이기 때문에, 모델 안에 전체 인스턴스의 애트리뷰트와 연산을 포함시킬 필요는 없다. 대신, 그림 16에서처럼 관심이 있는 애트리뷰트와 값들만 보여주는 것이 좋다.

그림 16: Plane 클래스의 인스턴스 예제 (관심 있는 애트리뷰트 값들만 보인다.)

하지만, 단순히 관계에 대한 설명 없이 가지 인스턴스들만 보여주는 것은 쓸모가 없다. 따라서, UML 2 인스턴스 레벨에서 관계/제휴 모델링을 적용한다. 제휴를 그리는 규칙은 일반 클래스 관계와 같지만, 제휴를 모델링 가지 추가 요구 사항이 있다. 제휴 관계는 클래스 다이어그램의 관계와 매치해야 하고, 제휴의 역할 이름 역시 클래스 다이어그램과 매치되어야 한다. 이것의 예제는 그림 17 나타나 있다. 예제에서, 인스턴스는 그림 6 클래스 다이어그램의 인스턴스 예제이다.

그림 17: 클래스 대신 인스턴스를 사용하는 그림 6 예제

그림 17 Flight 클래스의 개의 인스턴스를 갖고 있다. 클래스 다이어그램이, Plane 클래스와 Flight 클래스간 관계를 zero-to-many라고 명시했기 때문이다. 따라서, 우리 예제에서는 NX0337 Plane 인스턴스가 연관된 개의 Flight 인스턴스를 보여주고 있다.

역할 
클래스의 인스턴스를 모델링 하는 것은 기대 이상으로 상세하다. 가끔, 보다 일반적인 레벨에서 클래스의 관계를 모델링하고 싶을 때가 있다. 같은 경우, 역할(role) 표기법을 사용해야 한다. 역할 표기법은 인스턴스 표기법과 매우 비슷하다. 클래스의 역할을 모델링 하려면, 박스를 그린 다음, 인스턴스 표기법에서처럼 안에 클래스의 역할 이름과 클래스 이름을 놓는다. 하지만, 경우, 단어에 밑줄을 그어서는 안된다. 그림 18 그림 14 다이어그램에서 설명한 Employee 클래스의 역할 예제이다. 그림 18에서, Employee 클래스가 스스로와 연결되었더라도, 관계는 매니저의 역할을 하는 Employee 멤버의 역할을 하는 Employee 관계이다.

그림 18: 각자 다른 역할을 가진 그림 14 클래스를 보여주는 클래스 다이어그램

평범한 클래스 다이어그램에서 클래스의 역할을 모델링 없다. 심지어, 그림 18 가능한 것처럼 보여도 모델링은 불가능하다. 역할 표기법을 사용하려면, Internal Structure 표기법을 사용해야 한다.

Internal Structures 
UML 2
구조 다이어그램의 유용한 기능들 하나는 새로운 Internal Structures 표기법이다. 클래스와 다른 Classifier 내부에서 구성되는 방법을 보여주고 있다. 이것은 UML 1.x에서는 불가능 했다. 표기법 세트는 클래스가 가진 애그리게이션 관계만 보여주기 때문이었다. 이제, UML 2에서 Internal Structures 표기법으로 클래스의 부분들이 서로 어떻게 연관되는지를 명확히 보여줄 있다.

예제를 보자. 그림 18에서는 Plane 클래스가 개의 엔진들과 개의 컨트롤 소프트웨어 객체들로 구성되는 방법을 보여주는 클래스 다이어그램을 보았다. 다이어그램에서 빼먹은 것은 비행기의 부품들이 조립되는 방법에 대한 정보이다. 그림 18 다이어그램에서, 컨트롤 소프트웨어 객체들이 개의 엔진들을 제어하는지, 하나의 컨트롤 소프트웨어 객체가 개의 엔진들을 제어하고 다른 컨트롤 소프트웨어가 하나의 엔진을 제어하는지를 없다.

그림 19: 객체들 관계만 보여주는 클래스 다이어그램

클래스의 내부 구조를 그린다면 상황은 나아질 것이다. 개의 칸을 가진 박스를 그린다. 윗칸에는 클래스 이름이, 아래칸에는 클래스의 내부 구조가 포함되어 있고, 각각의 역할에 부모 클래스의 부분 클래스들을 보여주고 있고, 각각의 특정 클래스가 역할에서 서로서로 연관되는 방법을 보여주고 있다. 그림 19 Plane 클래스의 내부 구조를 보여주고 있다. 내부 구조가 혼란을 어떻게 종식시키는지 주목하라.

그림 20: Plane 클래스의 내부 구조 예제

그림 20에서, Plane 개의 ControlSoftware 객체들을 갖고 잇고, 각각 개의 엔진들을 제어하고 있다. 다이어그램의 왼쪽에 있는 ControlSoftware(control1) 엔진 1 엔진 2 제어한다. 오른쪽에 있는 ControlSoftware(control2) 엔진 3 4 제어한다.

위로

결론

클래스 다이어그램일 이해해야 하는 가지 중요한 이유가 있다. 번째는 시스템에서 Classifier 정적 구보를 보여주는 것이고, 번째 이유는 다이어그램이 UML에서 정한 다른 구조 다이어그램에 대한 기본적인 표기법을 제공하기 때문에다. 개발자들은 클래스 다이어그램이 자신들을 위해 특별히 만들어졌다고 생각할 것이다. 하지만 다른 멤버들 역시 이것을 유용하게 사용할 있다. 비즈니스 분석가들은 클래스 다이어그램을 사용하여 비즈니스 관점에서 시스템을 모델링 있다. 시리즈의 다른 기술자료를 참조하면 알겠지만, 다른 다이어그램들(액티비티, 시퀀스, statechart 다이어그램) 클래스 다이어그램에서 모델링 문서화 클래스들을 참조하고 있다.

다음 시리즈는 "UML 기초:" 컴포넌트 다이어그램이다.

위로

1 delayFlight 리턴 값이 없다. delay 연산이 새로운 도착 시간을 리턴 해야 하고, 이것이 그러한 경우라면, 연산 시그너처는delayFlight(numberOfMinutes : Minutes) : Date 것이다.

2BankAccount 클래스가 OverdrawnAccountsReport 클래스에 대해 모르고 있다는 사실이 이상할 것이다. 모델링은 report 클래스가 자신들이 리포팅 하는 비즈니스 클래스만 있도록 하지만, 비즈니스 클래스는 자신들이 리포팅 되고 있다는 것을 모른다. 이로써, 객체들의 커플링이 느슨해지고, 시스템은 변화에 대한 적응성이 빨라진다.

3 패키지는 모델의 클래스들을 구성하는데 탁월하지만, 클래스 다이어그램은 모델링 되는 시스템에 대한 정보와 쉽게 통신한다. 패키지에 많은 클래스가 있는 경우, 하나의 클래스 다이어그램을 만드는 대신 주제 클래스 다이어그램을 여러 사용하는 것이 낫다.

4필자가 "all those members"라고 말할 , 현재 다이어그램이 보여줄 클래스만 의미한다는 것을 알아야 한다. 콘텐트가 있는 패키지를 보여주는 다이어그램은 모든 콘텐트를 보여줄 필요가 없다. 일정 기준에 따라 포함된 엘리먼트의 일부만 보여줄 있다.

5 클래스 다이어그램을 그릴 , 직사각형의 윗칸에 «class»라고 표기해야 한다. 하지만 UML 스팩에서는 "class" 라는 텍스트를 표기하는 것은 선택 사항이고, «class» 디스플레이 되지 않는 것으로 간주된다.

 

참고자료

UML 기초: Unified Modeling Language 소개 (한글)

UML 기초: Part II: The activity diagram

UML 기초: Part III: The class diagram

필자소개

Donald Bell IBM Global Services IT 전문가이고, 기반 기술 애플리케이션 분야에서 고객을 지원하고 있다. (bellds@us.ibm.com)

 

원문 게재일:  2007 5 22  

출처 : http://www.ibm.com/developerworks/kr/library/sep04/bell/index.html

반응형
반응형

20세기 말을 되돌아보며 --

정확히 1997 Object Management Group (OMG) Unified Modeling Language (UML) 발표했다. UML 목표 하나는 개발 커뮤니티에 안정적이고, 일반적인 디자인 언어를 제공하는 것이었다. UML IT 전문가들이 수년 동안 바라던 통합된 표준 모델링 표기법을 탄생시켰다. UML 사용하여 IT 전문가들은 시스템 구조와 디자인 계획을 읽고 분산시킬 있다. 건축가들이 빌딩의 청사진을 사용하는 것처럼 말이다.

이제 21세기가 되었고 UML 전문성을 확립하게 되었다. 내가 보고 있는 이력서의 75 퍼센트 정도가 UML 알고 있다고 쓰여있다. 하지만 면접을 통해 이야기를 해보면 이들이 진정으로 UML 알지 못하고 있다는 것이 명확해진다. 일반적으로 당시 이슈가 되는 키워드 로서 알고 있거나 표면적인 면만 알고 있는 경우가 대부분이었다. 이것이 바로 내가 글을 이유이다. 글을 읽었다고 해서 이력서에 UML 충분히 알고 있다고 수는 없겠지만, 언어를 보다 심도 깊게 연구할 출발선에는 정도는 것이다.

배경 지식

UML 컴퓨터 애플리케이션을 모델링 있는 통합 언어이다. 주요 작성자들은 Jim Rumbaugh, Ivar Jacobson, Grady Booch이고 이들은 원래 그들만의 괜찮은 방식(OMT, OOSE, Booch) 갖고 있었다. 결국 이들은 힘을 합쳤고 개방형 표준을 만들었다. (어디서 많이 들어본 소리인가? J2EE, SOAP, Linux 비슷한 현상이다.) UML 표준 모델링 언어 가지 이유는 이것이 프로그래밍 언어에 독립적이라는데 있다. (IBM Rational UML 모델링 툴은 .NET 뿐만 아니라 J2EE에서도 사용된다.) 또한 UML 표기법 세트는 언어이지 방법론이 아니다. 언어인 것이 중요한 이유는 방법론과는 반대로 언어는 기업이 비즈니스를 수행하는 방식에 맞는다.

UML 방법론이 아니기 때문에 (IBM Rational Unified Process® lingo "객체(artifacts)" 같은) 어떤 형식적인 작업 생성물들이 필요 없다. 하지만 정해진 방법론 안에서 쓰이면, 애플리케이션을 개발할 애플리케이션을 쉽게 이해할 있도록 도와주는 여러 가지 유형의 다이어그램을 제공한다. 다이어그램은 현재 사용하고 있는 것의 언어와 원리를 소개하고 있다. 사용중인 방법론에서 생긴 작업 생산품들에 표준 UML 다이어그램을 배치하여 UML 능숙한 사람들이 프로젝트에 쉽게 참여하여 생산성을 높일 있도록 한다. 가장 유용한 표준 UML 다이어그램은 사용 케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램, 스테이트 차트 다이어그램, 액티비티 다이어그램, 컴포넌트 다이어그램, 전개 다이어그램 등이 있다.

유형의 다이어그램을 자세히 설명하지는 않겠다. 대신, 다이어그램에 대한 일반적인 개념을 소개하고 자세한 것은 나중에 다루도록 하겠다.


사용 케이스 다이어그램

사용 케이스는 시스템에서 제공한 기능 단위를 설명한다. 사용 케이스 다이어그램의 주요 목적은, 다른 사용 케이스들 관계 뿐만 아니라 주요 프로세스에 대한 "액터(actors)" (시스템과 인터랙팅하는 사람)들과의 관계를 포함하여, 개발 팀들이 시스템의 기능적 요구 사항들을 시각화 하는 있다. 사용 케이스 다이어그램은 사용 케이스 그룹들을 보여준다. 완전한 시스템에 대한 모든 사용 케이스이거나 관련된 기능을 가진 특정 사용 케이스 그룹(예를 들어, 보안 관리에 관련된 사용 케이스 그룹) 사용 케이스일 수도 있다. 사용 케이스 다이어그램에 대한 사용 케이스를 보여주려면 다이어그램 중간에 타원을 그려서, 타원의 중앙 또는 아래에 사용 케이스 이름을 적어놓는다. 사용 케이스 다이어그램에 액터(시스템 사용자) 그리려면 다이어그램의 왼쪽이나 오른쪽에 사람 모양을 그려 넣는다. (얼마나 예쁘게 그리는가는 여러분에게 달려있다.) 액터와 사용 케이스들간 관계는 그림 1 나타나있다.

그림 1: 사용 케이스 다이어그램

사용 케이스 다이어그램은 시스템의 고급 기능과 시스템의 범위를 설명하는데 사용된다. 그림 1 사용 케이스 다이어그램을 통해, 시스템이 제공하는 기능을 쉽게 표현할 있다. 이러한 시스템에서는 밴드 매니저가 밴드가 발매한 CD 대한 판매 통계 리포트와 Billboard 200 보고서를 있다. 또한 레코드 매니저는 특정 CD 대한 판매 통계 보고서와 Billboard 200 보고서를 있다. 다이어그램에서는 Billboard Reporting Service라고 하는 외부 시스템에서 우리 시스템이 Billboard 리포트를 전달하고 있다는 것도 있다.

또한, 다이어그램에 사용 케이스가 없다는 것은 시스템이 수행하지 않은 일을 보여주고 있는 것이다. 예를 들어, 다이어그램은 밴드 매니저가 Billboard 200 다른 앨범들에 수록된 노래를 듣는 방식은 나와있지 않다. Billboard 200에서 Listen to Songs 라는 사용 케이스에 대한 어떤 레퍼런스도 없다. 이것은 중요한 포인트이다. 그와 같은 다이어그램에 제공된 명확하고 간단한 사용 케이스 설명을 통해 프로젝트 스폰서는 시스템에 필요한 기능이 존재하는지 여부를 쉽게 있는 것이다.


클래스 다이어그램

클래스 다이어그램은 다른 엔터티들(사람, 제품, 데이터) 서로 어떻게 관계를 맺고 있는지를 보여준다. 다시 말해서, 이것은 시스템의 정적 구조라고 있다. 클래스 다이어그램은 록밴드, 씨디, 라디오 연주를 논리적 클래스로 나타내는데 사용될 있다. 또는 대출, 주택 저당 대출, 자동차 대출, 이자율을 나타내는데도 쓰일 있겠다. 클래스 다이어그램은 주로 프로그래머들이 다루는 구현 클래스들을 보여주는데 쓰인다. 구현 클래스 다이어그램은 논리적 클래스 다이어그램과 같은 클래스를 보여준다. 하지만 구현 클래스 다이어그램은 같은 애트리뷰트로는 그릴 없다. Vectors HashMaps 같은 것에 대한 레퍼런스를 갖고 있기 때문이다.

그림 2에서는 개의 섹션으로 클래스 다이어그램을 설명하고 있다. 섹션은 클래스의 이름을, 중간 섹션은 클래스의 애트리뷰트를, 가장 아래 섹션은 클래스의 연산("그림 2에서는 개의 섹션으로 클래스 다이어그램을 설명하고 있다. 섹션은 클래스의 이름을, 중간 섹션은 클래스의 애트리뷰트를, 가장 아래 섹션은 클래스의 연산 ("메소드") 보여주고 있다.

그림 2: 클래스 다이어그램의 클래스 객체

경험으로는 거의 모든 개발자들은 다이어그램이 무엇을 하고 있는지를 안다. 하지만 대부분의 프로그래머들은 관계도를 잘못 그리고 있다. 그림 3 같은 클래스 다이어그램의 경우 상속 관계 1 그릴 때에는 화살표 방향을 위로 향하게 하여 수퍼 클래스를 지시하게 하면서 화살표 모양은 완벽한 삼각형 되도록 해야 한다. 상관 관계는 클래스들이 서로를 인식하고 있다면 일직선이 되어야 하고, 클래스의 편만 알고 있는 관계라면 화살표 표시가 되어있는 선을 그어야 한다.

그림 3: 그림 2 클래스 객체가 포함된 클래스 다이어그램

그림 3에서, 상속 관계와 개의 상관 관계를 보았다. CDSalesReport 클래스는 Report 클래스에서 상속을 받고, CDSalesReport 개의 CD 관련이 되어 있지만, CD 클래스는 CDSalesReport 대해 아무것도 모르고 있다. CD Band 클래스는 서로에 대해 알고 있고, 클래스는 서로 연관되어 있다.

클래스 다이어그램에는 보다 많은 개념들을 적용할 있다. 나중에 설명하도록 하겠다.


시퀀스 다이어그램

시퀀스 다이어그램은 특정 사용 케이스에 대한 상세한 흐름이나 심지어는 특정 사용 케이스의 일부분 까지도 보여준다. 대부분이 설명을 포함하고 있다. 시퀀스에서 다른 객체들 간의 호출관계를 보여주고 있고, 다른 객체들로의 다른 호출까지 상세하게 보여줄 있다.

시퀀스 다이어그램은 2차원으로 그려진다. 수직 차원은 발생 시간 순서로 메시지/호출 시퀀스를 보여주고 있다. 수평 차원은 메시지가 전송되는 객체 인스턴스를 나타내고 있다.

시퀀스 다이어그램은 그리기가 매우 간단하다. 다이어그램의 상단에 클래스 인스턴스를 박스 안에 놓아 클래스 인스턴스(객체) 구분한다. (그림 4) 박스 안에 클래스 인스턴스 이름과 클래스 이름을 스페이스/콜론/스페이스 " : " 분리시킨다. (, myReportGenerator : ReportGenerator) 클래스 인스턴스가 메시지를 다른 클래스 인스턴스로 보내면 클래스 인스턴스를 받는 곳을 가리키는 화살표를 긋는다. 라인 위에 메시지/메소드 이름을 적는다. 중요한 메시지의 경우는 원래의 클래스 인스턴스를 다시 향하도록 점선 화살표를 그릴 있다. 점선 위에 리턴 값을 라벨링한다. 개인적으로는 리턴 값을 포함하곤 하는데 상세한 부분을 읽기 쉽기 때문이다.

시퀀스 다이어그램을 읽기는 매우 간단하다. 시퀀스를 시작하는 "드라이버(driver)" 클래스 인스턴스가 있는 왼쪽 상단 코너부터 시작한다. 그런 다음, 다이어그램 아래쪽을 메시지를 따라간다. 그림 4 시퀀스 다이어그램 예제에서 전송 메시지에 대한 리턴 메시지는 선택적인 것임을 기억하라.

그림 4: 시퀀스 다이어그램

그림 4 시퀀스 다이어그램을 읽다 보면 CD Sales Report 어떻게 만들어지는지를 있다. aServlet 객체가 우리의 드라이버 예제이다. aServlet 메시지를 gen이라고 하는 ReportGenerator 클래스 인스턴스로 보낸다. 메시지는 generateCDSalesReport 라는 라벨링이 붙는다. ReportGenerator 객체가 메시지 핸들러를 구현한다는 의미이다. 자세히 보면, generateCDSalesReport 메시지 라벨은 괄호 안에 cdId 있다. gen 인스턴스가 generateCDSalesReport 메시지를 받으면 CDSalesReport 연속 호출을 하고 aCDReport 라고 하는 CDSalesReport 실제 인스턴스가 리턴 된다. gen 인스턴스는 리턴된 aCDReport 인스턴스에 호출하면서 여기에 메시지 호출에 대한 매개변수를 전달한다. 시퀀스의 끝에서 gen 인스턴스는 콜러였던 aServlet aCDReport 리턴한다.

그림 4 시퀀스 다이어그램은 전형적인 시퀀스 다이어그램을 상세히 설명한 것이다. 하지만 충분히 이해할 있을 것이다. 또한 초보 개발자들에게는 레벨 마다 시퀀스를 끊어서 이해하는 것도 좋은 방법이다.


스테이트 차트 다이어그램

스테이트 차트 다이어그램은 클래스가 개입된 다양한 상태(state) 모델링 하고 클래스가 상태간 어떻게 이동하는지를 모델링 한다. 모든 클래스는 상태를 갖고 있지만 각각의 클래스가 스테이트 차트 다이어그램을 가질 없다. "중요한" 상태, 말하자면 시스템 작동 이상의 잠재적 상태가 있는 클래스일 경우만 모델링 되어야 한다.

그림 5에서 보듯, 스테이트챠트 다이어그램에는 다섯 개의 기본 엘리먼트들이 사용된다. 시작점(짙은 ), 스테이트 이동(화살표), 스테이트(모서리가 둥근 직사각형), 결정 포인트(속이 비어있는 ), 이상의 종료점( 내부에 짙은 원이 그려져 있음) 바로 그것이다. 스테이트챠트 다이어그램을 그리려면 시작점과 클래스의 초기 상태를 향하는 화살표로 시작한다. 다이어그램 어디에나 스테이트를 그릴 있고 스테이트 이동 라인을 사용하여 연결한다.

그림 5:시스템 작동 클래스가 실행되는 다양한 상태를 보여주는 스테이트 차트 다이어그램

그림 5 스테이트 차트 다이어그램은 중요한 정보를 보여주고 있다. 예를 들어, 대출 프로세스가 Loan Application 상태에서 출발한다고 말할 있다. 결과에 따라 사전 승인 프로세스가 완료되면 Loan Pre-approved 상태나 Loan Rejected 상태로 옮겨간다. 이동하는 동안 내린 결정은 결정 포인트로 보여진다. 이동 라인 상의 비어있는 원이 바로 그것이다. 예제를 보면 Loan Closing 상태를 거치지 않고는 대출이 Loan Pre-Approved 상태에서 Loan in Maintenance 상태로 없음을 있다. 또한, 모든 대출이 Loan Rejected 상태 또는 Loan in Maintenance 상태에서 끝난다는 것도 있다.


액티비티 다이어그램

액티비티 다이어그램은 액티비티를 처리하는 동안 이상의 클래스 객체들 제어 흐름을 보여준다. 액티비티 다이어그램은 비즈니스 단위 레벨에서 상위 레벨의 비즈니스 프로세스를 모델링 하거나 저수준 내부 클래스 액션을 모델링 하는데 사용된다. 내가 경험한 바로는 액티비티 다이어그램은 기업이 현재 어떻게 비즈니스를 수행하는지, 또는 어떤 것이 비즈니스에 어떤 작용을 하는지 등의 고차원 프로세스를 모델링 가장 적합하다. 액티비티 다이어그램은 언뜻 보기에 시퀀스 다이어그램 보다는 기술적이기 때문에 비즈니스 마인드를 가진 사람들이 빠르게 이해할 있다.

액티비티 다이어그램의 표기법은 스테이트 차트 다이어그램과 비슷하다. 스테이트 차트 다이어그램과 마찬가지로 액티비티 다이어그램은 초기 액티비티에 연결된 실선으로 원에서 시작한다. 액티비티는 모서리가 둥근 직사각형을 그려 안에 액티비티 이름을 적어 넣으면서 모델링 된다. 액티비티들은 이동 라인을 통해 다른 액티비티들에 연결되거나 결정 포인트의 조건에 제약을 받는 다른 액티비티들에 연결하는 결정 포인트로 연결될 있다. 모델링 프로세스를 종료하는 액티비티는 (스테이트 차트 다이어그램에서처럼) 종료 포인트에 연결된다. 액티비티들은 수영 레인으로 그룹핑 있다. 이것은 실제로 액티비티를 수행하는 객체를 나타내는데 사용된다. (그림 6)

그림 6:  개의 객체(밴드 매니저와 리포팅 ) 의한 액티비티 제어를 나타내는 개의 수영 레인으로 되어있다.

그림 5 스테이트 차트 다이어그램은 중요한 정보를 보여주고 있다. 예를 들어, 대출 프로세스가 Loan Application 상태에서 출발한다고 말할 있다. 결과에 따라 사전 승인 프로세스가 완료되면 Loan Pre-approved 상태나 Loan Rejected 상태로 옮겨간다. 이동하는 동안 내린 결정은 결정 포인트로 보여진다. 이동 라인 상의 비어있는 원이 바로 그것이다. 예제를 보면 Loan Closing 상태를 거치지 않고는 대출이 Loan Pre-Approved 상태에서 Loan in Maintenance 상태로 없음을 있다. 또한, 모든 대출이 Loan Rejected 상태 또는 Loan in Maintenance 상태에서 끝난다는 것도 있다.

액티비티 다이어그램 예제는 개의 객체(밴드 매니저와 리포팅 ) 의한 액티비티 제어를 나타내는 개의 수영 레인으로 되어있다. 프로세스는 밴드에 대한 판매 리포트를 보는 밴드 매니저로 시작한다. 리포팅 툴은 사람이 관리하는 모든 밴드들을 검색하여 디스플레이하고 이중 개를 고를 것을 요청한다. 밴드 매니저가 밴드를 선택하면 리포팅 툴은 판매 정보를 검색하여 판매 리포트를 디스플레이 한다.


컴포넌트 다이어그램

컴포넌트 다이어그램은 시스템을 물리적으로 있도록 한다. 이것의 목적은 소프트웨어가 시스템의 다른 소프트웨어 컴포넌트들(예를 들어, 소프트웨어 라이브러리) 대해 소프트웨어가 갖고 있는 종속 관계를 보여주는 것이다. 다이어그램은 매우 고급 레벨에서 있거나 컴포넌트 패키지 레벨에서 있다.  2

컴포넌트 다이어그램의 모델링은 예제에 설명되어 있다. 그림 7 개의 컴포넌트인 Reporting Tool, Billboard Service, Servlet 2.2 API, JDBC API 보여주고 있다. Reporting Tool에서 출발하여 Billboard Service, Servlet 2.2 API, JDBC API 가는 화살표는 Reporting Tool 이들 개의 컴포넌트에 종속되어 있음을 나타낸다.

그림 7: 컴포넌트 다이어그램은 다양한 소프트웨어 컴포넌트들 종속관계를 보여준다.


전개 다이어그램

전개 다이어그램은 하드웨어 환경에 시스템이 물리적으로 어떻게 전개되는지를 보여준다. 목적은 시스템의 다양한 컴포넌트들이 어디에서 실행되고 서로 어떻게 통신하는지를 보여주는 것이다. 다이어그램이 물리적 런타임을 모델링 하기 때문에 시스템 사용자는 다이어그램을 신중하게 사용해야 한다.

전개 다이어그램의 표기법에는 컴포넌트 다이어그램에서 사용되던 표기법 요소들이 포함된다. 이외에 노드 개념을 포함하여 가지 정도 추가되었다. 노드는 물리적 머신 또는 가상 머신 노드(메인프레임 노드) 표현한다. 노드를 모델링 하려면 3차원 큐브를 그려 큐브 상단에 노드 이름을 적는다. 시퀀스 다이어그램에서 사용되던 네이밍 규칙([instance name] : [instance type]) (, "w3reporting.myco.com : Application Server").

그림 8: 전개 다이어그램Reporting Tool 컴포넌트가 WebSphere 내부에서 그려지기 때문에(w3.reporting.myco.com 노드의 내부에서 그려짐), 사용자들은 로컬 머신에서 실행되는 브라우저를 통해 Reporting Tool 액세스 하면서 기업 인트라넷을 통해 HTTP 연결할 있다는 것을 있다.

그림 8 전개 다이어그램은 사용자가 로컬 머신에서 실행되고 기업의 인트라넷에서 HTTP 통해 Reporting Tool 연결되는 브라우저를 사용하여 Reporting Tool 접근하는 것을 보여주고 있다. 툴은 물리적으로 w3reporting.myco.com 이라고 하는 Application Server에서 실행된다. 다이어그램은 IBM WebSphere 내부에서 그려진 Reporting Tool 컴포넌트를 보여준다. 이것은 결과적으로 node w3.reporting.myco.com에서 그려지게 되어있다. Reporting Tool 자바를 사용하여 리포팅 데이터베이스를 IBM DB2 JDBC 인터페이스에 연결하여 원시 DB2 통신을 사용하는 db1.myco.com 서버상에서 실행되는 실제 DB2 데이터베이스와 통신한다. 리포팅 데이터베이스와 통신하는 외에도 Report Tool 컴포넌트는 SOAP over HTTPS 통해 Billboard Service 통신한다.


결론

글은 Unified Modeling Language 대한 간단한 입문서에 불과하지만 여러분이 정보를 실제 프로젝트에 적용하거나 깊게 UML 연구하기를 바란다. UML 다이어그램을 소프트웨어 개발 프로세스에 통합시키는 여러 소프트웨어 툴이 있지만, 자동화된 툴이 없더라도 화이트보드에 마커와 펜을 사용하여 UML 다이어그램을 그려도 좋다.


1 상속과 기타 객체 지향 원리에 대한 기타 자세한 정보는 http://java.sun.com/docs/books/tutorial/java/concepts/inheritance.html 참조하기 바란다.

2 컴포넌트 패키지 레벨은 프로그래밍 언어에 중립적인 방식으로 .NET 네임스페이스(System.Web.UI) 자바의 패키지(java.util) 같은 클래스 컨테이너 레벨을 참조하는 것이다.


참고자료

편집자 note: The Rational Edge.

 

원문 게재일:  2003 11 25

출처 : http://www.ibm.com/developerworks/kr/library/769.html


반응형
반응형

SW개발 하거나 광범위한 소스를 분석하기 좋은 Tool로 소스인사이트를 사용합니다.

 

소스 인사이트에서 Macro를 이용하여 주석을 편하게 달 수 있는 방법을 소개합니다.

 

Block으로 편하게 주석달기

Block으로 편하게 주석을 다는 방법을 설명하겠습니다.

Ex)

// Gongdoo's New Code START [

printf("Hello, World! \n");

return 0;

// Gongdoo's New Code END ]

 

1. Source Insight에서는 기본적으로 Base라는 프로젝트를 가지고 있습니다.

일단 Base Project를 Open 합니다.

 

2. 기본적으로 아래와 같은 macro가 이미 작성되어 있을 것입니다.

 

2. 파일의 제일 아래에 내가 원하는 함수를 다음과 같이 작성하여 저장을 합니다.

일단은 매크로 작성은 완료되었습니다. 저장을 하고 Project를 Close합니다.

 

3. 이제 본인이 사용하는 Project를 열고, Key를 할당할 차례입니다.

Options->Key Assignments 선택하면 아래와 같이 Macro에 위에서 추가한 BlockDoc이 있습니다.

여기에 자기가 원하는 Key를 할당을 합니다. 저는 Ctrl+Shift+9을 할당 했습니다.

 

 

4. 블록 주석을 넣기 원하는 부분을 Drag해서 선택한 다음, Ctrl+Shift+9 를 누르면 다음과 같이 Block 주석이 나오는 것을 볼 수 있습니다.

반응형

'SW개발' 카테고리의 다른 글

[안드로이드]SQLite Client Tool  (2) 2011.09.16
[안드로이드 로그 보는 툴]  (0) 2011.09.02
[VI 명령어]  (0) 2011.08.29
[UML Class Diagram]  (0) 2011.08.26
Unified Modeling Language (UML)  (0) 2011.08.26
Clear Case 를 Source Insight와 Beyond Compare와 연동하기  (0) 2011.04.26
강력한 무료 압축 프로그램 7zip  (0) 2011.04.26
Trace32. Image view  (0) 2011.04.26
Trace32. Spot Break and Log  (0) 2011.04.26
카메라 개발 용어  (0) 2011.04.26
반응형

Clear Case는 IBM Rational에서 나온 소스 형상화 툴입니다.

 

소스 형상화란 소스를 효율적으로 중앙에서 관리할 수 있게 해주는 툴인데요.

장점으로는

  1. 소스 이력 관리
  2. 자동 머지 기능
  3. 문제 Tracking 기능
  4. 매 버전마다의 Source의 용량 최소화

 

이런 장점 때문에 사용자는 Check in, Check out등을 해주어야 하는데요.

이 기능을 Source Insight나 Beyond Compare에서 쉽게 사용할 수 있는 기능을 알려드릴게요.

 

CC에서 제공되는 Command. 이 Command를 이용하여 연동을 할거에요.

Check Out     : "C:\Program Files\Rational\ClearCase\bin\cleardlg.exe" /checkout %f

Undo Check Out     : "C:\Program Files\Rational\ClearCase\bin\cleardlg.exe" /uncheckout %f

Check In         : "C:\Program Files\Rational\ClearCase\bin\cleardlg.exe" /checkin %f

Find Check Out     : "C:\Program Files\Rational\ClearCase\bin\clearfindco.exe"

Version Tree     : "C:\Program Files\Rational\ClearCase\bin\clearvtree.exe" %f

View History     : "C:\Program Files\Rational\ClearCase\bin\clearhistory.exe" %f

ClearCase Explorer     : "C:\Program Files\Rational\ClearCase\bin\clearexplorer.exe"

Add to source control.. : "C:\Program Files\Rational\ClearCase\bin\cleardlg.exe" /addtosrc %f

 

 

Source Insight와 연동

아래의 그림처럼 CC관련 command를 추가해서 편하게 사용할 수 있습니다.

 

아래와 같이 Menu Assign

 

 

Beyond compare와 연동

반응형

'SW개발' 카테고리의 다른 글

[안드로이드 로그 보는 툴]  (0) 2011.09.02
[VI 명령어]  (0) 2011.08.29
[UML Class Diagram]  (0) 2011.08.26
Unified Modeling Language (UML)  (0) 2011.08.26
[Source Insight]편하게 주석달기2  (0) 2011.04.27
강력한 무료 압축 프로그램 7zip  (0) 2011.04.26
Trace32. Image view  (0) 2011.04.26
Trace32. Spot Break and Log  (0) 2011.04.26
카메라 개발 용어  (0) 2011.04.26
아스키 문자셋  (0) 2011.04.25
반응형

 

7zip은 무료 압축 프로그램이면서 압축률이 높고, 알집에 가벼운 프로그램입니다.

기존의 zip형식도 지원을 하며 압축률이 높다 보니 압축시간은 조금 더 소비됩니다.

 

높은 압축률과 Dos command를 이용해서 개발에 아주 유익한 프로그램입니다.

 

예를 들어, 아래의 경우에 Batch파일로 만들어 놓고 사용을 하면 편하게 압축을 할 수 있습니다.

  1. 컴파일이 완료된 파일들에서 소스만 압축
  2. 컴파일이 완료된 파일들에서 Binary만 압축
  3. 컴파일이 완료된 파일들에서 Library만 압축
  4. 특정 파일만 압축

 

Ex) SRC폴더에서 확장자가 *.C파일과 *.H파일을 빼고, 나머지 파일들을 zip형태로 압축하기

7z a –tzip C\ZIPDEST\output c\SRC\* -x!*.c -x!*.h

 

Ex) SRC폴더에서 확장자가 *.o파일과 *.exe파일을 빼고, 나머지 파일들을 zip형태로 압축하기

7z a –tzip C\ZIPDEST\output c\SRC\* -x!*.o -x!*.exe

 

회사에서 상용 프로그램이 아닌 이런 강력한 Cmd 기반의 압축프로그램의 사용은 옵션이 아니라 필수네요.

 

7zip Download

홈페이지 : http://www.7-zip.org/

  

사용 형식

Usage: 7z <command> [<switches>...] <archive_name> [<file_names>...]

[<@listfiles...>]

 

<Commands>

a: Add files to archive

b: Benchmark

d: Delete files from archive

e: Extract files from archive (without using directory names)

l: List contents of archive

t: Test integrity of archive

u: Update files to archive

x: eXtract files with full paths

<Switches>

-ai[r[-|0]]{@listfile|!wildcard}: Include archives

-ax[r[-|0]]{@listfile|!wildcard}: eXclude archives

-bd: Disable percentage indicator

-i[r[-|0]]{@listfile|!wildcard}: Include filenames

-m{Parameters}: set compression Method

-o{Directory}: set Output directory

-p{Password}: set Password

-r[-|0]: Recurse subdirectories

-scs{UTF-8 | WIN | DOS}: set charset for list files

-sfx[{name}]: Create SFX archive

-si[{name}]: read data from stdin

-slt: show technical information for l (List) command

-so: write data to stdout

-ssc[-]: set sensitive case mode

-ssw: compress shared files

-t{Type}: Set type of archive

-v{Size}[b|k|m|g]: Create volumes

-u[-][p#][q#][r#][x#][y#][z#][!newArchiveName]: Update options

-w[{path}]: assign Work directory. Empty path means a temporary directory

-x[r[-|0]]]{@listfile|!wildcard}: eXclude filenames

-y: assume Yes on all queries

 

반응형

'SW개발' 카테고리의 다른 글

[VI 명령어]  (0) 2011.08.29
[UML Class Diagram]  (0) 2011.08.26
Unified Modeling Language (UML)  (0) 2011.08.26
[Source Insight]편하게 주석달기2  (0) 2011.04.27
Clear Case 를 Source Insight와 Beyond Compare와 연동하기  (0) 2011.04.26
Trace32. Image view  (0) 2011.04.26
Trace32. Spot Break and Log  (0) 2011.04.26
카메라 개발 용어  (0) 2011.04.26
아스키 문자셋  (0) 2011.04.25
GSM 약어2  (0) 2011.04.25
반응형

T32를 사용하다 보면 Image의 포인터를 이용해서 어떤 Image가 있는지 확인해 보고 싶은 때가 있습니다.

 

아래와 같은 Command를 이용해서 해당 주소의 Image를 T32에서 실시간으로 볼 수 있습니다.

 

data.image 0x12345678 480. 800. /RGB565LE

; 0x12345678 : 이미지의 시작 주소, 포인터 변수로 대체 가능

; 480. : 가로 Size

; 800. : 세로 Size

; /RGB565LE : 이미지 형식, /를 입력하면 사용 가능한 형식을 선택할 수 있음.

반응형

'SW개발' 카테고리의 다른 글

[UML Class Diagram]  (0) 2011.08.26
Unified Modeling Language (UML)  (0) 2011.08.26
[Source Insight]편하게 주석달기2  (0) 2011.04.27
Clear Case 를 Source Insight와 Beyond Compare와 연동하기  (0) 2011.04.26
강력한 무료 압축 프로그램 7zip  (0) 2011.04.26
Trace32. Spot Break and Log  (0) 2011.04.26
카메라 개발 용어  (0) 2011.04.26
아스키 문자셋  (0) 2011.04.25
GSM 약어2  (0) 2011.04.25
GSM약어  (6) 2011.04.25

+ Recent posts