'2016/01/21'에 해당되는 글 8건

  1. 2016.01.21 c# using 키워드
  2. 2016.01.21 JSON 이란?
  3. 2016.01.21 MY SQL 데이터 타입
  4. 2016.01.21 redis란?
  5. 2016.01.21 스테레오 타입(Stereotype)
  6. 2016.01.21 시퀀스 다이어그램(Sequence Diagram) (1)
  7. 2016.01.21 클래스 다이어그램(Class Diagram)
  8. 2016.01.21 SP란? Stored Procedure [수정필요] (1)

원문 : http://csharpschool.github.io/2015/05/05/using-keyword-and-idisposable.html



C#에서는 가비지 컬렉터를 지원하므로, 메모리의 해제를 자동으로 해주지만 

우리가 사용하는 리소스가 메모리만 있는 것이 아니다. 메모리와 별개로 최대한 열 수 있는 파일 개수에 제한이 존재한다.

(이 제한에 도달하면 메모리가 남아도 파일을 열 수 없다.) 따라서 사용하지 않는 파일을 수동으로 닫아줘야한다.


즉..

var reader = new StreamReader("file.txt");

var content = reader.ReadToEnd();

reader.Close();


이렇게 닫아주면 끝일 것 같지만, Close가 실행되기 전 ReadToEnd에서 예외가 발생할 경우.. close가 불리지 않고 넘어가는 경우가 발생한다.

이를 방지하기 위해서 finally 블록을 사용해야하는데..


var reader = new StreamReader("file.txt");

try

{

    var content = reader.ReadToEnd();

}

finally

{

reader.Close();

}


이 처럼하게되면 어떤 상황에도 작동하는 finally 에 의해서 파일은 닫힐 것이다. 하지만 이런 과정은 불편하기 때문에..

C#은 using이라는 '키워드'를 제공한다.


using을 사용하면..


using(var reader = new StreamReader("file.txt"))

{

var content = reader.ReadToEnd();

}


이렇게 하면 위의 동일한 효과를 얻을 수 있다.


C#이 각 리소스를 해제하는 방법이 다 다를텐데, 어떻게 해제하는 것일까?

NET에 이런 목적으로 존재하는 인터페이스가 IDisposable 이며, Dispose 메소드를 정의하고 있는데,

IDisposable을 구현한 클래스가 using 블록을 빠져나갈 때, C#이 자동적으로 Dispose 메소드를 호출한다.


명시적인 리소스 해제가 필요한 클래스가 모두 IDisposable 인터페이스를 구현하고 있기 때문에

이런 클래스를 사용할 때는 되도록 using을 사용하자.


또 우리가 만드는 클래스도 명시적인 리소스 해제가 필요할 경우 IDisposable을 구현하는 것이 좋은 습관.



'프로그래밍 > C++++ (C#)' 카테고리의 다른 글

도구 상자가 보이지 않는다!!!  (0) 2016.02.26
C#의 where  (0) 2016.01.22
delegate  (0) 2016.01.22
typeof  (0) 2016.01.22
c# using 키워드  (0) 2016.01.21
Posted by GENESIS8

댓글을 달아 주세요

JSON 이란?

프로그래밍 2016. 1. 21. 15:51


출처 위키백과


JSON(제이슨[1]JavaScript Object Notation)은 속성-값 쌍으로 이루어진 데이터 오브젝트를 전달하기 위해 인간이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷이다. 비동기 브라우저/서버 통신 (AJAJ)을 위해, 넓게는 XML(AJAX가 사용)을 대체하는 주요 데이터 포맷이다. 특히, 인터넷에서 자료를 주고 받을 때 그 자료를 표현하는 방법으로 알려져 있다. 자료의 종류에 큰 제한은 없으며, 특히 컴퓨터 프로그램의 변수값을 표현하는 데 적합하다.

본래는 자바스크립트 언어로부터 파생되어 자바스크립트의 구문 형식을 따르지만 언어 독립형 데이터 포맷이다. 즉, 프로그래밍 언어 플랫폼에 독립적이므로, 구문 분석 및 JSON 데이터 생성을 위한 코드는 C, C++, C#, 자바, 자바스크립트, , 파이썬 등 수많은 프로그래밍 언어에서 쉽게 이용할 수 있다.

JSON 포맷은 본래 더글라스 크록포드가 규정하였다. RFC 7159와 ECMA-404라는 두 개의 경쟁 표준에 의해 기술되고 있다. ECMA 표준은 문법만 정의할 정도로 최소한으로만 정의되어 있는 반면 RFC는 시맨틱, 보안적 고려 사항을 일부 제공하기도 한다.[2] JSON의 공식 인터넷 미디어 타입은 application/json이며, JSON의 파일 확장자는 .json이다.

기본 자료형[편집]

JSON의 기본 자료형은 다음과 같다:

수(Number)[편집]

기본 자료형의 수는 다음과 같이 표현된다. C나 자바에서의 8진수와 16진수를 표현하는 방법은 지원되지 않는다.

  • 정수
42
1974
750
-114
-273
3.14
-2.718
1e4
2.5e12
3.4e+4
4.56e-8
5.67E+10
6.78E-5

문자열(String)[편집]

항상 큰 따옴표(")로 묶어야 하며, 그 안에는 유니코드 문자들이 나열된다. 유니코드 중 역슬래시(\)와 큰따옴표(")는 바로 사용할 수 없다. 역슬래시는 제어문자를 표현하기 위해 사용되며 다음과 같은 의미를 지닌다.

\b 백스페이스
\f 폼 피드
\n 개행
\r 캐리지 리턴
\t 탭
\" 따옴표
\/ 슬래시
\\ 역슬래시
\uHHHH 16진수 네자리로되어 있는 유니코드 문자
"1234"
"Love"
"O-matic"
"한글"
"\"JSON\""

배열(Array)[편집]

배열은 대괄호[]로 나타낸다. 배열의 각 요소는 기본 자료형이거나 배열, 객체이다. 각 요소들은 쉼표(,)로 구별된다. 각 요소가 나타나는 순서에 의미가 있다.

 [10, {"v": 20}, [30, "마흔"]]

객체(Object)[편집]

객체는 이름/값 쌍의 집합으로, 중괄호{}를 사용한다. 이름은 문자열이기 때문에 반드시 따옴표를 하며, 값은 기본 자료형이거나 배열, 객체이다. 각 쌍들은 쉼표(,)로 구별된다. 각 쌍이 나오는 순서는 의미가 없다.

 {"name2": 50, "name3": "값3", "name1": true}

JSON 메시지 단위는 배열이나 객체이다. 위의 두 예는 JSON 메시지가 될 수 있다.

예제[편집]

다음은 한 사람에 관한 정보를 갖는 JSON 객체이다.

 {
    "이름": "테스트",
    "나이": 25,
    "성별": "여",
    "주소": "서울특별시 양천구 목동",
    "특기": ["농구", "도술"],
    "가족관계": {"#": 2, "아버지": "홍판서", "어머니": "춘섬"},
    "회사": "경기 안양시 만안구 안양7동"
 }


음, 감이 잘 안온다. 아래의 주소에서 더 쉽게 설명된 느낌이다.

http://blog.naver.com/musecje/10126963299



- JSON이란 무엇인가?

  1. 어떻게 읽으면 되나?

    제이선이라고 읽으면 되겠다.


  2. 무엇을 줄인 말이냐?

    JavaScript Object Notation이라는 이름에서 알 수 있듯이 자바스크립트를 위한 것이고 객체 형식으로 자료를 표현하는 것이다.

    
  3. 이거 프로그래밍 언어냐?

    사방팔방에 JSON이라는게 등장하고 각종 사용방법이 나오고 어려워 보이지만 JSON 자체는 정말 별거 아니다. JSON 그자체 는 단순히 데이터 포맷일 뿐이다. 어떠한 통신 방법도, 프로그래밍 문법도 아닌 단순히 데이터를 표시하는 표현 방법일 뿐이다.
    간단한 데이터를 xml보다 좀 더 간단하게 표현하기 위해 만든 것이다. XML보다 기능이 적기 때문에 파싱도 빠르고 간단하기 때문에 클라이언트 사이드에서, 특히 모 바일에서 더욱 유용하겠다. 사실 서버 입장에서도 더 유용하기 때문에 많은 서비스들이 XML보다는 JSON을 권장한다.

    다시 말하지만 이건 프로그래밍 언어가 아니다.


  4. 이거 공식 사이트 없냐?

    네이버에서 JSON으로 검색하면 시덥잖은 네이버 자체 컨텐츠들(블로그, 카페, 지식인)만 뜨는데 JSON 공식 사이트는 멀쩡히 있고, 한국어도 지원된다.
      http://json.org/json-ko.html
    여기 들어가면 좀 당황스러울 수도 있다. 뭔 놈의 공식사이트가 내용이 진짜 간단하고 별 거 없기 때문이다.
    위키피디아를 보면 더 잘 설명이 되어 있다.
      http://ko.wikipedia.org/wiki/JSON


  5. 이거 왜 쓰냐?

    단순히 데이터를 받아서 객체나 변수로 할당해서 사용하기 위한 것이다.


  6. AJAX와는 다른가?

    AJAX와는 별개의 개념이지만 AJAX가 없다면 JSON이라는 개념은 필요 없을 것이다. AJAX를 사용해 데이터를 주고 받을 때 그 데이터 포맷으로 JSON을 사용하는 것이다.


  7. 이거 쓰려면 따로 라이브러리 같은 걸 써야 하냐?

    JSON 자 체는 이미 자바스크립트 표준으로 채택되어 자바스크립트에서 기본적으로 지원하고 있기 때문에 별도의 라이브러리가 필요하거나 하지는 않 다. 그냥 eval()이라는 함수 하나로 해결되는 게 JSON이다. 하지만 JSON의 한계로 인해 라이브러리를 따로 사용하는 경우가 많다.그리고 자바스크립트 이외의 환경에서도 JSON을 간단히 사용 하기 위한 라이브러리들이 존재한다. JSON 공식 사이트 내용의 대부분이 바로 그것이다.


  8. JSON 단점이나 문제점은 뭐냐?

    AJAX 는 단순히 데이터만이 아니라 javascript 그 자체도 전달할 수 있다. 무슨 말이냐면 json데이터라고 해서 받았는데 그게 단 순 데이터가 아니라 자바스크립트가 될 수도 있고, 그게 실행 될 수 있다는 것이다. 데이터인 줄 알고 받았는데 악성 스크립트더 라 뭐 그럴 수 있다는 것이다.
    JSON 관련 라이브러리를 따로 사용하는 이유가 이것이다. 받은 내용에서 순수하게 데이터만 추출하기 위한 라이브러리이다.


  9. JSON으로 아무 데이터나 불러갈 수 있냐?

    JSON의 한계는 JSON으로 가져올 수 있는 데이터는 해당 자바스크립트가 로드된 서버의 데이터에 한정된다는 것이다.
    예를 들어서 http://kwz.kr/json.js에서 불러올 수 있는 데이터는 kwz.kr 서버에 존재하는 것만 가능하다는 것이다. 구글 데이터를 불러온다거나 네이버 데이터를 불러온다거나 할 수 없다.
    JSON은 단순히 데이터 포맷일 뿐이고 그 데이터를 불러오기 위해선 XMLHttpRequest()라는 자바스크립트 함수를 사용해야 하는데 이 함수가 동일 서버에 대한 것만 지원하기 때문이다.


  10. 어? 다른 서버의 데이터도 가져가서 보여주던데??

    궁하면 통한다고 방법이야 만들면 나오는 거다. 그래서 나온 게 일종의 프락시 역할을 하는 서버쪽 스크립트 파일과 JSONP이다.


  11. JSONP는 뭐냐????

    JSON with Padding을 줄인 말이다. 다른 서버의 데이터를 가져오기 위한 방법이다.
    이건 해당 서버에서 JSONP의 방식을 지원해 줘야지만 가능하다. 이것이 불가능하면 역시 프락시를 써야 한다.



'프로그래밍' 카테고리의 다른 글

JSON 이란?  (0) 2016.01.21
가변인자(Variable Arguments) 함수  (0) 2015.03.31
Posted by GENESIS8

댓글을 달아 주세요

원본 출처 

http://ra2kstar.tistory.com/82



MySQL 데이터 타입



MySQL 에서 사용하는 데이터 타입에 대해서 알아본다. 


  CHAR 데이터 타입

CHAR와 VARCHAR(VARiable length CHARacter string)은 모두 텍스트 문자열을 허용하고, 필드의 크기를 제한한다. 두 타입의 차이점은 CHAR 필드의 모든 문자열은 크기가 정해진다는 것. 즉 더 작은 문자열을 입력하면 공백으로 채워진다. 반면 VARCHAR의 경우, 텍스트를 채우지 않으며, 입력한 텍스트 크기에 맞게 가변적으로 크기를 가진다. 그러나, VARCHAR는 각 값의 크기를 추적할 수 있는 약간의 오버헤드가 필요하기 때문에 모든 데이터의 크기가 비슷하다면, CHAR가 더 효율적이다.


TYPE  

사용되는 바이트 

예제 

CHAR(n) 

정확히 n (<=255) 

CHAR(5) 'Hello'는 5바이트 사용

CHAR(50) 'Hello'는 50바이트 사용 

 VARCHAR(n)

최대 n 까지(<=65535) 

VARCHAR(100)'Hello'는 5바이트 사용

VARCHAR(5) 'Hello'는 5바이트 사용



  BINARY 데이터 타입 

BINARY 데이터 타입은 관련된 문자 세트가 없는 문자의 전체 바이트를 저장하는데 사용된다. 예를 들면 GIF 이미지를 저장하는데 사용할 수 있다. 


TYPE  

사용되는 바이트 

예제 

BINARY(n) 혹은 BYTE(n) 

정확히 n (<=255) 

CHAR이지만 바이너리 데이터를 가짐 

 VARBINARY(n)

최대 n 까지(<=65535) 

VARCHAR이지만 바이너리 데이터를 가짐



  TEXT와 VARCHAR 데이터 타입

TEXT와 VARCHAR에는 작은 차이점이 있다. 


TEXT 필드는 기본 값을 가질 수 없다. 

MySQL은 TEXT 열의 처음 n 개의 문자만 인덱싱 할 수 있다. 


이것은, 만약 전체 내용을 검색할 때는 VARCHAR이 더 알맞고, 빠르다는 것이다.


 TYPE

사용되는 바이트 

속성 

 TINYTEXT(n)

최대 n (<=255)

문자열로 취급

 TEXT(n)

최대 n (<=65535)

문자열로 취급

 MEDIUMTEXT(n)

최대 n (<=16777215)

문자열로 취급

 LONGTEXT(n)

최대 n (<=4294967295)

문자열로 취급



  BLOB 데이터 타입

BLOB(Binary Large OBject)는 65535 바이트를 넘는 바이너리 데이터에 유용하며, 기본 값을 가질 수 없다. 


 TYPE

사용되는 바이트 

속성 

TINYBLOB(n)

최대 n (<=255)

바이너리 데이터로 취급

 BLOB(n)

최대 n (<=65535)

바이너리 데이터로 취급

 MEDIUMBLOB(n)

최대 n (<=16777215)

바이너리 데이터로 취급

 LONGBLOB(n)

최대 n (<=4294967295)

바이너리 데이터로 취급



  숫자형 데이터 타입


 TYPE

사용되는 바이트 

최소 값

(signed/unsigned) 

대 값

(signed/unsigned) 

TINYINT

-128

127
255 

SMALLINT 

-32768

32767
65535 

MEDIUMINT

-8388608

8388607
16777215 

INT or INTEGER

-2147483648

2147483647
4294967295 

BIGINT

-9223372036854775808

9223372036854775807

18446744073709551615

FLOAT

-3.40E+45
(no unsigned) 

3.40E+45

(no unsigned) 

DUBLE or REAL

-1.7976E+320
(no unsigned)   

1.7976E+320
(no unsigned)   







'프로그래밍 > MySQL' 카테고리의 다른 글

MySql DB 작성해보기  (1) 2016.03.13
MySQL 저장 프로시져 내에서 발생한 에러 처리 (Error Handling)  (0) 2016.02.23
MySql 설치하기  (0) 2016.02.21
Auto Increment란  (0) 2016.02.05
MySql 주석을 달자  (0) 2016.02.01
MY SQL 데이터 타입  (0) 2016.01.21
Posted by GENESIS8

댓글을 달아 주세요

출처 : 

http://www.sqler.com/266239

http://blog.likead.co.kr/?p=72




redis란 무엇일까?

redis란 No SQL의 일종이라고 한다.



NO SQL? 

위키 : 

NoSQL 데이터베이스는 단순 검색 및 추가 작업을 위한 매우 최적화된 키 값 저장 공간으로, 레이턴시와 스루풋과 관련하여 상당한 성능 이익을 내는 것이 목적이다. NoSQL 데이터베이스는 빅데이터와 실시간 웹 애플리케이션의 상업적 이용에 널리 쓰인다.


NO SQL은 Not only SQL의 줄임말로 NoSQL 시스템은 SQL 계열 쿼리 언어를 사용할 수 있다는 사실을 강조한다는 면에서 "Not only SQL(SQL 뿐만이 아니고)"로 불리기도 한다.




redis 자체도 약어라고 하는데

REmote DIctionary Server의 약어라고한다.


Redis는 자주 Memcached와 비교되는 in memory 저장소 이다.


Memcached의 기본적인 특징.

1. 처리 속도가 빠르다.

   - 당연히 데이터가 메모리에만 저장되므로 빠르다. 즉, 속도가 느린 Disk를 거치지 않는다.

2. 데이터가 메모리에만 저장된다.

   - 당연히 프로세스가 죽거나 장비가 Shutdown되면 데이터가 사라진다.

3. 만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다.

   - 이름에서도 느껴지듯이 Cache이다

4. 저장소 메모리 재사용

   - 만료가 되지 않았더라도  더이상 데이터를 넣을 메모리가 없으면 LRU(Least recently used) 알고리즘에 의해 데이터가 사라진다.


그래서, 보통 대형 포털들에서 Static page, 또는 검색 결과 등을 캐쉬하는데 많이 사용한다.


그런데!!!!


왜!!!!! REDIS가 자꾸 Memchche와 비교되는가?


눈치들 채셨겠지만 거의 98%이상 Memchche와 동일한 기능을 제공한다.(비슷 하니까 비교 하겠지~~~)


그럼 다른 2%는 뭐냐?


이제부터 설명 들어간다..


 Memcached REDIS

처리 속도가 빠르다.

   - 당연히 데이터가 메모리에만 저장되므로 빠르다. 즉, 속도가 느린 Disk를 거치지 않는다.

처리 속도가 빠르다.

   - 당연히 데이터가 메모리+Disk에 저장된다. 그러나, 속도는 Memcached와 큰 차이가 없다.

데이터가 메모리에만 저장된다.

   - 당연히 프로세스가 죽거나 장비가 Shutdown되면 데이터가 사라진다.

데이터가 메모리+Disk에 저장된다.

   - 프로세스가 죽거나 장비가 Shutdown되더라도 Data의 복구가 가능하다.

만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다.

   - 이름에서도 느껴지듯이 Cache이다

만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다.

   - 동일한 기능을 지원한다.

저장소 메모리 재사용

   - 만료가 되지 않았더라도  더이상 데이터를 넣을 메모리가 없으면LRU(Least recently used) 알고리즘에 의해 데이터가 사라진다.

저장소 메모리 재사용 하지 않는다.

   - 명시적으로만 데이터를 제거할 수 있다.
 문자열만 지원
문자열, Set, Sorted Set, Hash, List등의 다양한 Data Type을 지원.




[Redis 의 장점]


1. 리스트, 배열 형식의 데이터 처리에 특화됨


– value 값으로 문자열, 리스트, set, sorted set, hash 형 등 여러 데이터 형식을 지원함

리스트 형 데이터의 입력과 삭제가 MySQL에 비하여 10배 정도 빠르다.


2. 여러 프로세스에서 동시에 같은 key에 대한 갱신을 요청할 경우 Atomic처리로 데이터 부정합 방지 Atomic 처리 함수를 제공


3. 메모리를 활용하면서 영속적인 데이터 보존

– 명령어로 명시적으로 삭제하거나 expires를 설정하지 않으면 데이터를 삭제하지 않는다.

– 스냅샷(기억 장치) 기능을 제공하여 메모리의 내용을 *.rdb 파일로 저장하여 해당 시점으로로 복구할 수 있다.


4. 여러 대의 서버 구성


– Consistent hashing 혹은 master-slave 형식으로 구성 가능함

Redis에는 5가지의 데이터 타입이 존재한다. (Strings, Lists, Sets, Sorted sets, Hashes)

Strings (일반적인 key-value)


– String이라고 해서 문자열만 저장할 수 있는게 아니라, 이진 데이터도 저장 가능 (정수, 실수형이 따로 없다.)


– key에 넣을 수 있는 데이터의 최대 크기는 512MB 이다.

Lists (Array 형태로 key 1개에 n개의 값을 가짐, 중복 값 가능)


– 배열이라고 생각해도 된다.

– 한 key에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다.

– 데이터 형의 값은 설정파일에서 정해준 조건보다 큰 경우 linkedlist 아니면 ziplist로 encoding 된다.


Sets (Group 형태로 key 1개에 n개의 중복되지 않는 값을 가짐)

– 정렬되지 않은 집합형으로 key에 중복된 데이터는 존재하지 않는다.

– 추가, 제거 및 존재 체크 시 소모되는 시간이, sets에 포함된 요소의 수와 관계없이 일정하다.

– 한 key에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다.

– 데이터 형의 값은 설정파일에 정해준 조건보다 큰 경우 hashtable 아니면 intset으로 encoding 된다.

Sorted sets (Group 형태이나 각 member에 score 값을 가짐, key-member-score)

– Sorted sets는 가장 진보한 Redis 데이터 형이라고 한다.


– 요소의 추가, 제거, 업데이트는 매우 빠른 방법으로 진행되는데 이는 “요소의 개수의 로그”에 비례하는 시간이 사용된다.

– 랭킹 시스템 등에서 사용되기 좋다.

– sets의 각 요소마다 score라는 실수 값을 가지고 있는 형태로 score 값으로 오름차순 정렬된다.

– key에 중복된 데이터는 존재하지 않지만 score 값은 중복 가능하다.

Hashes (Object 형태의 key-field-value)

– list와 비슷한데 “필드명”, “필드값”의 연속으로 이루어져 있다.

– 한 key에 포함할 수 있는 field-value 쌍의 최대 개수는 4,294, 967,295 개이다.

– 데이터 형의 값은 설정파일에서 정해준 조건보다 큰 경우는 hashtable 아니면 zipmap으로 encoding 된다.


redis 의 키 밸류 형태의 데이타베이스 이다.


밸류에 공백이 없다면 ” ” 로 묶지 않어도 된다.







'프로그래밍 > 서버 프로그래밍' 카테고리의 다른 글

WAN과 LAN. MAN  (0) 2016.02.21
쿠키(cookie)와 세션(Session)  (2) 2016.01.29
redis란?  (0) 2016.01.21
Posted by GENESIS8

댓글을 달아 주세요


스테레오타입이라는 말이 자주 나온다. 무슨 의미인가?


사전적 의미:


Stereotype - 고정관념 / 정형화하다 / 상투적인 문구


여전히 이해가 안된다. 구글링을 통해서 찾아보았다.

원본 : http://m.blog.daum.net/iq_jeong/7759137


스테레오타입은 그 정의로써 이해하기에는 다소 마음에 와 닿지 않을 것이므로 먼저 예를 들어보자. 윈도우 기반의 UI를 가지고 있으면서 DB를 다루는 간단한 프로그램을 모델링 한다고 가정하자. 이 때 주로 UML의 클래스(Class)를 사용해서 모델링을 하게 될 것이다. 속성(Attribute)과 연산(Operation)도 넣고 서로 간의 연관(Association) 및 일반화(Generalization)도 사용해서 말이다. 이렇게 모델링을 하고 나면 새로운 욕구가 발생하게 될 것이다. GUI를 구성하는 부분과 DB를 구성하는 테이블, 그리고 기타 프로그램 내부의 순수 로직 부분 모두 다 그냥 단지 클래스(Class)로만 표현되고 있을 뿐이다. 이것들을 그저 GUI, Business Logic, Database로 구분해두고 싶어질 것이다. 이런데 이러 경우는 비단 이러한 예 뿐만 아니라 너무도 많이 발생한다. 즉, 각각의 요소들을 모델러(modeler)의 기준에서 별도의 분류를 두고 싶을 때 스테레오타입(stereotype)을 사용하게 된다.


스테레오타입이 왜 필요한가? 

UML은 매우 범용적이고 일반적인 모델링 언어이다. 따라서, 어떠한 개념이라도 무리 없이 모델링이 가능하지만 반면에 어떠한 개념도 정확하고 명확하게 나타내기는 힘들다. 우리 인간이 사용하는 자연어(한국어, 영어, 일본어)등도 결국 일상 용어 외에 특정 학문 분야에서 사용될 때에는 부족함이 많기 때문에 새로운 용어가 탄생하고 기존의 단어에 새로운 의미가 부여되게 되는 것이다. 일상 용어의 "Thread"와 컴퓨팅 분야의 "Thread"는 단어는 같으나 이해되는 의미는 다르다. UML도 마찬가지로 그러한 태생적인 한계가 있으며 이를 극복하기 위한 방안이 모색되었는데 그것이 바로 UML의 확장 메커니즘(extension mechanism)인 것이다. 


스테레오타입의 사용 

테레오타입(stereotype)은 바로 UML 확장 메커니즘의 한 부분으로써 매우 중요한 역할을 수행하게 된다. 다시 한번 정리하면 "스테레오타입은 UML 모델링 요소들을 모델러의 기준에 따라 새로운 분류를 적용할 수 있도록 허용하는 메커니즘"이다. 따라서, 스테레오타입은 모델러 마음대로 정의해서 적용하면 되는 것이고 특별한 제약이나 규칙은 없다. 그리고 스테레오타입은 각 요소에 "<<" ">>" 사이에 이름을 부여하면 된다. 정확하게는 "<<", ">>"는 꺽쇠 괄호(angle-braket) 두개가 아니라 guillemets라 불리는 하나의 문자('«', '»')이다. 그러나, 통상적으로 이러한 문자를 사용하기가 불편하기 때문에 꺽쇠 괄호 두 개를 써도 무방하다. 스테레오타입은 위의 예에서 처럼 <<GUI>>, <<table>>과 같이 사용해도 되고, 특정한 플랫폼이나 프로그래밍 언어를 나타내기 위해 <<JavaClass>>, <<CORBAInterface>> 처럼 사용해도 된다. 아니면 특정 분야에서 사용되는 용어나 개념으로 표현하는 것도 좋은 예가 될 수 있다. 그러나 가급적 특정 기준을 두고 분류의 용도로 사용하는 것이 바람직하며 무조건적으로 부가적인 데이터들만 기입하는 방식은 좋은 사용의 예가 아닐 것이다. 예를 들어 클래스를 작성한 사람의 이름 <<minho>>, <<younghee>> 혹은 구현될 파일의 이름 <<DBAccess.java>>과 같이 사용하는 것은 그다지 좋은 방법은 아닐 것이다. 

스테레오타입과 아이콘(Icon) 

스테레오타입은 하나의 아이콘으로 표현될 수도 있다. 예를 들어 <<JavaBean>> 클래스를 콩 모양의 아이콘으로 나타내준다면 훨씬 보기에도 좋고 구별하기도 쉬울 것이다. UML은 이러한 확장이 가능하도록 허용하고 있다. 그리고 현대의 여러 툴들에서는 이를 지원하고 있기도 하다. <<table>>은 표 모양의 아이콘을, <<Database>>는 원통 모양의 아이콘을 사용할 수도 있는 것이다. 이렇게 아이콘을 사용할 수 있게 되다 보니 스테레오타입을 표현하는 방식에 몇 가지 선택사항이 생기게 되었다. 간단하게 생각해보더라도 <<JavaBean>>과 같이 텍스트 형식으로 나타내느냐 아니면 아이콘 형식으로 나타내느냐 혹은 둘 다를 나타내느냐 하는 선택을 할 수 있다. UML에서는 총 4가지의 옵션이 존재한다. None : 스테레오타입을 나타내기 않음 Textual : 스테레오타입을 <<JavaBean>>과 같이 텍스트로 나타냄 Iconic : 콩 그림의 아이콘과 같이 아이콘으로 나타냄 Decoration : <<JavaBean>>과 콩 그림의 아이콘을 동시에 나타냄.




'프로그래밍 > 프로그래밍 공부' 카테고리의 다른 글

RDBS,DB모델링,파일시스템 표현 차이  (0) 2016.01.26
연산자  (0) 2016.01.22
스테레오 타입(Stereotype)  (0) 2016.01.21
시퀀스 다이어그램(Sequence Diagram)  (1) 2016.01.21
클래스 다이어그램(Class Diagram)  (0) 2016.01.21
메모리 구조  (1) 2016.01.19
Posted by GENESIS8

댓글을 달아 주세요


시퀀스 다이어그램이란?



http://5dol.tistory.com/128


기초

시퀀스 다이어그램의 주요 목적어떤 결과를 만들어내는 이벤트 시퀀스를 정의하는 것이다. 메시지 보다는 메시지가 발생하는 순서에 초점이 더 맞춰진다. 대부분 시퀀스 다이어그램은 system 객체들 간 어떤 메시지들이 보내지는지, 그리고 어떤 순서로 발생하는지를 나타낸다. 다이어그램은 이 정보를 수직적 측면과 수평적 측면으로 전달한다. 수직 측면에서는 탑다운(top down) 방식으로 메시지/호출이 발생한 시간 순서를 나타내고, 수평 측면에서는 왼쪽에서 오른쪽으로 메시지가 보내진 객체 인스턴스를 보여준다.

 

Lifelines

시퀀스 다이어그램을 그릴 때 Lifeline 표기법 엘리먼트는 다이어그램 상단에 놓인다. Lifeline은 모델링되는 시퀀스에 개입된 역할 또는 개게 인스턴스들을 나타낸다.

1 Lifeline은 박스의 아래쪽 중심에서 대시(dash)[점선] 라인을 그리며 내려간다. (그림 3). 이 Lifeline의 이름은 박스 내부에 있다


해당 클래스를 통해서 만들어진 객체의 존재 선. 그래서 라이프라인인듯 하다. 




그림 3: 인스턴스 이름이 freshman인 Student 클래스 예제



Lifeline의 UML의 네이밍 표준은 다음 포맷은 따른다.

Instance Name : Class Name

(실제 객체 : 클래스)



그림 3의 예제에서, Lifeline은 Student 클래스의 인스턴스를 나타낸다. 이것의 인스턴스 이름은 freshman이다. Lifeline 이름 밑에 그어진 밑줄에 주목하라. 밑줄이 사용될 때는 Lifeline이 한 시퀀스 다이어그램에서 클래스의 특정 인스턴스를 나타낸다는 것을 의미한다. 특정 종류의 인스턴스(예를 들어, '역할')가 아니다. 구조 모델링에 대해서도 살펴볼 것이다. 지금까지 누가(Bill과 Fred) 그 역할을 수행하는지를 지정하지 않은 시퀀스 다이어그램에는 buyerseller 등의 역할이 포함되어 있다는 것을 알 수 있다. 이런 경우 다이어그램은 다른 정황에서도 재사용된다. 시퀀스 다이어그램에 역할 이름이 아닌 인스턴스 이름에 밑줄을 긋는다.

그림 3의 Lifeline 예제는 네임드 객체이다. 하지만 모든 Lifeline이 네임드 객체를 나타내는 것은 아니다. 대신 익명 또는 이름없는 인스턴스를 나타내는데도 Lifeline이 사용될 수 있다. 시퀀스 다이어그램에 이름없는 인스턴스를 모델링 할 때, Lifeline의 이름은 네임드 인스턴스와 같은 패턴을 따른다. 그러나 인스턴스 이름을 주는 대신에, Lifeline의 이름의 부분이 공백으로 된다. 그림 3을 다시 보자. 만약 이 Lifeline이 Student 클래스의 익명 인스턴스를 나타낸다면, Lifeline은 " Student." 이다. 또한 시퀀스 다이어그램은 프로젝트의 디자인 단계에서 사용되기 때문에 유형이 지정되지 않은 객체를 갖고 있는 것이 맞다. 예를 들어 "freshman."이 바로 그것이다.

 

메시지

시퀀스 다이어그램의 첫 번째 메시지는 언제나 상단에서 시작하고 다이어그램의 왼쪽에 위치한다. 뒤따르는 메시지들은 이전 메시지보다 약간 낮게 다이어그램에 추가된다.

메시지를 또 다른 객체에 보내는 객체(lifeline)를 나타내기 위해서 수신 객체에 실선 화살표(동기식 호출일 경우)를 긋는다. 또는 (비동기식일 경우) 막대 화살표를 긋는다. 메시지/메소드 이름은 화살표 위에 놓인다. 수신 객체로 보내지는 메시지는 수신 객체의 클래스가 구현하는 작동/메소드를 나타낸다. 그림 4의 예제에서, analyst 객체는 ReportingSystem 클래스의 인스턴스인 system 객체를 호출한다. analyst 객체는 system 객체의 getAvailableReports 메소드를 호출한다. system 객체는 secSystem 객체에 userId의 인자와 함께 getSecurityClearance 메소드를 호출한다. 이것이 바로 SecuritySystem 클래스 유형이다.




그림 4: 객체들 간 보내지는 메시지 예제

 

시퀀스 다이어그램에 대한 메시지 호출을 보여주는 것 외에도 그림 4 다이어그램에는 리턴 메시지가 포함되어 있다. 이 리턴 메시지들은 필수요소는 아니다. 리턴 메시지는 원래 lifeline을 향하도록 점선 화살표로 그려지고 그 위에 리턴 값을 배치한다. 그림 4에서, getSecurityClearance 메소드가 호출될 때 secSystem 객체는 system 객체에 userClearance를 리턴한다. 이 system 객체는 getAvailableReports 메소드가 호출되면 availableReports를 리턴한다.

다시 말하지만, 리턴 메시지는 시퀀스 다이어그램의 선택 사항이다. 리턴 메시지의 사용 여부는 모델링되는 것의 상세함 정도에 달려있다. 리턴 메시지는 보다 상세한 것을 원할 때 유용하다. 하지만 호출 메시지로도 충분하다. 개인적으로는 값이 리턴될 때마다 리턴 메시지를 삽입한다.

시퀀스 다이어그램을 모델링 할 때, 객체가 자신에게 메시지를 보내야 할 때가 있다. 언제 객체가 자기자신을 호출할까? 순수주의자들은 객체는 메시지를 객체 자신에게 보내서는 안된다고 주장한다. 하지만 자신에게 메시지를 보내는 객체를 모델링 하는 것도 어떤 경우에는 유용하다. 그림 5는 그림 4를 개선한 것이다. 그림 5는 determineAvailableReports 메소드를 호출하는 system 객체를 보여준다. 그 system 객체에 "determineAvailableReports," 메시지를 보여줌으로써 모델은 이 프로세스가 system 객체에서 발생한다는 사실에 주목할 수 있다.

자기자신을 호출하는 객체를 그리기 위해서는 정상적인 방법으로 메시지를 그리되 또 다른 객체로 연결하는 대신, 메시지를 다시 객체 자신으로 연결한다.



그림 5: determineAvailableReports 메소드를 호출하는 system 객체

 

그림 5의 예제 메시지는 동기식 메시지이다. 하지만 시퀀스 다이어그램에서는 비동기식 메시지도 모델링 할 수 있다. 비동기식 메시지는 동기식 메시지와 비슷하게 그려지지만 메시지 라인은 막대 화살표로 표시된다. (그림 6)




동기는 굵은 화살표로 , 비 동기는 얇은 선 화살표다.


그림 6: instance2로 보내지는 비동기식 메시지를 나타내는 시퀀스 다이어그램

 

가드(guard)

객체 인터랙션(interaction - 상호작용)을 모델링 할 때 객체로 보내지는 메시지 조건이 부합해야 할 때도 있다. 가드(guard)는 흐름을 제어하는 UML 다이어그램에서 쓰인다. UML 1.x 와 UML 2.0 모두 가드를 언급했다. UML 1.x에서 보호는 하나의 메시지에만 할당될 수 있었다. UML 1.x의 시퀀스 다이어그램에 가드를 그리려면 보호되고 있는 메시지 라인 위, 메시지 이름 앞에 guard 엘리먼트를 둔다. 그림 7은 메시지 addStudent 메소드에 대한 가드가 있는 시퀀스 다이어그램이다




그림 7: 가드가 포함된 addStudent 메시지

 

그림 7에서 가드는 텍스트 "[pastDueBalance = 0]" 이다. 이 메시지에 가드가 있기 때문에 addStudent 메시지는 시스템 계정이 [pastDueBalance = 0]을 리턴할 경우에만 보내진다.

[Boolean Test]

 

예를 들어,

[pastDueBalance = 0]

 

Combined fragments (대안, 옵션, 루프)

대부분의 시퀀스 다이어그램에서 UML 1.x "in-line" 가드는 모델링 되는 시퀀스에 필요한 로직을 핸들하기엔 조금 부족했다. 그러한 기능이 부족하다는 점이 UML 1.x에서 문제가 되었다. UML 2는 "in-line" 가드를 없애고, Combined FFragment라고 하는 표기법 엘리먼트를 추가하여 이러한 문제를 다루고 있다. Combined Fragment는 시퀀스 다이어그램에서 조건의 흐름을 보여주기 위해 메시지들을 하나로 그룹핑하는데 사용된다. UML 2 스팩은 Combined Fragment에 11 개의 인터랙션 유형을 정의하고 있다.

 

대안

대안은 두 개 이상의 메시지 시퀀스들간 상호 배타적인 선택을 나타낼 때 사용된다.

대안은 전통적인 "if then else" 직 (만일 내가 세 개의 아이템을 구매하면 구매금액의 20%를 할인 받는다; 그 외에는 10%의 할인을 받는다.)의 모델링이 가능하다.

그림 8에서 보듯, 대안 엘리먼트는 프레임을 사용하여 그려진다. "alt" 라는 단어는 이 프레임의 네임박스 안에 놓인다. 더 큰 직사각형은 피연산함수로 나누어진다.

4피연산 함수는 대시(dash) 라인으로 분리된다. 각 피연산 함수에는 가드가 주어지고 이 가드는 lifeline 상단에 피연산 함수의 왼쪽 상단 부분을 향해 배치된다.

5피연산함수의 가드가 "true,"로 되면 그 피연산함수를 따라야 한다.




그림 8: 대안 Combined Fragment를 포함하고 있는 시퀀스 다이어그램

 

대안이 어떻게 읽혀지는지를 보여주는 예제로서 그림 8은 상단에서 시작하는 시퀀스를 보여준다. check amount와 account의 balance 정보가 있는 bank 객체가 있다. 이 부분에서 대안이 사용된다. 가드 "[balance >= amount]" 때문에 account의 balance이 보다 크거나 같을 때 시퀀스는 addDebitTransaction과 storePhotoOfCheck 메시지를 account 객체로 보내는 bank 객체를 사용하여 시퀀스를 지속시킨다. 하지만 balance가 amount 보다 작을 때 시퀀스는 addInsuffientFundFee와 noteReturnedCheck 메시지를 account 객체로 보내고, returnCheck 메시지를 자기 자신에게 보내는 bank 객체로 처리한다. "[else]" 가드 때문에 balance가 amount 보다 작거나 같을 때 두 번째 시퀀스가 호출된다. 대안을 사용하면 "[else]" 가드가 필요 없다. 하지만 피연산함수가 이것에 대한 명확한 가드를 갖고 있지 않다면 "[else]" 가드가 필요하다.

대안은 "if then else"에만 국한되지 않는다. 필요한 만큼 대안 경로를 취할 수 있다. 더 많은 대안이 필요하면 시퀀스의 가드와 메시지를 포함한 직사각형에 피연산함수를 추가하면 된다.

 

옵션

옵션 Combined Fragment는 특정 상황에서 발생하는 시퀀스를 모델링 할 때 사용된다. 다른 경우, 이 시퀀스는 발생하지 않는다. 이 옵션은 간단한 "if then"문장을 모델링 하는데 쓰인다. (찬장에 5개 미만의 도넛이 있다면 24개 이상의 도넛을 만든다.)

옵션 표기법은 대안과 비슷하다. 단 한 개의 피연산 함수를 가져야 하고, "else" 가드가 전혀 없다는 것을 제외하고는 말이다. 옵션을 그리려면 프레임을 그려야 한다. "opt" 텍스트가 이 프레임의 네임박스 안에 배치되고, 이 프레임의 콘텐트 영역에 옵션의 가드가 lifeline의 상단에, 왼쪽 상단 코너를 향해 배치된다. 그런 다음 옵션의 메시지 시퀀스가 나머지 영역에 배치된다. (그림 9)



그림 9: 옵션 Combined Fragment

 

옵션 Combined Fragment는 읽기 쉽다. 그림 9는 그림 7의 시퀀스 다이어그램을 재구성 한 것이다. 하지만 여기에서는 student의 과거 해당 balance가 0일 경우 보내져야 하는 메시지가 더 많기 때문에 옵션을 사용한다. 그림 9의 시퀀스 다이어그램을 보면, student의 과거 balance가 0 이면 addStudent, getCostOfClass, chargeForClass 메시지들이 보내진다. student의 과거 balance가 0이 아니라면 시퀀스는 어떤 메시지도 보내지 않는다.

그림 9의 시퀀스 다이어그램에는 이 옵션용 가드가 포함되어 있다. 하지만 이 가드는 필수 엘리먼트는 아니다. 추상 시퀀스 다이어그램에서는 이 옵션의 조건을 지정한다. 이것이 옵션 fragment 라는 것을 가리키면 된다.

 

루프(loop)

가끔 반복적인 시퀀스를 모델링 해야 할 때도 있다. UML 2에서 반복되는 시퀀스의 모델에 루프 Combined Fragment를 사용한다.

루프는 외형상 옵션과 매우 흡사하다. 프레임을 그리고 그 프레임의 네임박스에 "loop"라고 쓴다. 프레임의 콘텐트 영역 안에서 루프의 가드는

6 lifeline의 상단에, 왼쪽 상단 코너 쪽을 향하여 놓인다. 그런 다음 루프의 메시지 시퀀스는 프레임의 나머지 콘텐트 영역에 배치된다. 루프에서 가드는 두 가지 특별한 조건을 가질 수 있다. 이 특별 가드 조건들은 "minint = [the number]" ("minint = 1")라고 하는 최소 반복과 and maximum iterations written as "maxint = [the number]" ("maxint = 5")라고 하는 최대 반복이다. 최소 반복 가드를 사용하여, 루프는 지정된 최소한의 수만큼 실행해야 하고 최대 또한 마찬가지이다.



그림 10: loop Combined Fragment

 

그림 10(

크게 보기)에서, 루프는 reportsEnu 객체의 hasAnotherReport 메시지가 false를 리턴할 때까지 실행된다. 이 시퀀스 다이어그램의 루프는 루프 시퀀스가 실행되는지를 확인할 때 부울 테스트를 사용한다. 이 다이어그램은 위에서부터 읽어 내려간다. 루프에 다다르면 hasAnotherReport 값이 true 인지를 확인하기 위해 테스트가 실행된다. HasAnotherReport 값이 true 면 시퀀스는 루프로 간다.

 


여기까지가

http://5dol.tistory.com/128

에서 소개되는 기초 내용이다. 이후의 내용도 저 안에 있다.


Posted by GENESIS8

댓글을 달아 주세요

  1. BBingStory 2018.12.09 16:56 신고  댓글주소  수정/삭제  댓글쓰기

    글을 되게 잘 정리해 놓으셨네요 ㅜㅜ
    기말고사 공부중인데 잘 봤습니다 감사합니다 !!


클래스다이어그램은, 시스템의 정적인 상태인 '논리적인 구조' (클래스)를 표현한다.

간단히 말해서 클래스들간의 관계를 보여주는 Structure Diagram[구조 도표]


클래스 다이어그램의 주 목적은 클래스간의 관계를 한눈에 쉽게 보고 의존 관계를 파악하는 것에 있습니다. 그렇기 때문에 클래스 다이어그램에서 가장 중요한 것은 클래스간의 관계.

[그림 6] 클래스 관계 종류

[그림 6] 클래스 관계 종류





원문이 있는 곳 : http://5dol.tistory.com/85



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에서와 같인 열려진 머리의 화살표를 가진 점선으로 표기한다.
의존관계의 의미는 한 클래스의 변화가 다른 클래스에 영향을 미칠 때 사용한다. 이러한 의존의 관계는 여러가지 관계에서 나타날 수 있다.  

8. 클래스에서 사용자 정의 구역(User-defined compartment)

그림 7 - 사용정의 구역 (user-defined compartment)
클래스를 구성하는 부분으로 이름구역, Attribute구역, Operation구역이 있음을 우리는 알고 있다. 이러한 클래스를 구성하는 세가지 부분은 UML에서 미리 정의하는 부분이고 이외에 사용자가 정의하여 작성할 수 있는 새로운 구역을 첨가할 수 있다. 이러한 사용자 정의 구역은 툴이 제공하는 환경에 따라 다양하게 제공된다. 만약 독자 여러분이  UML Modeling툴을 만든다면 사용자 정의 역역을 이용하여 순공학이나 문서화 등의 툴의 부가적인 기능을 돋보이게 할 수 있을 것이다.

9. Type and Implementation Class

그림8 - 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가 된다.

10. Interface

그림 9 - Interface
인터페이스 클래스의 경우 스테레오타입을 'interface'로 가지며 객체지향 언어인 java에서 사용되는 인터페이스의 의미와 동일하게 클래스의 행위만을 확정하고 있다. 이러한 인터페이스는 구현을 가지지 않으므로 abstract operation을 가지게 된다. 

11. Parameterized Class (Template Class)
그림 10 - Parameterized Class
Parameterrized Class의 표기는 위의 그림과 같이 표기하고 그 의미는 객체지향언어 C++에서 사용되는 Template와 동일하다.

12. Utility
그림 11 -  Utility Class
Utility class의 표기는 스테레오타입을 'utility'로 가진다. 그 의미는 일반적인 클래스의 의미가 아니라 프로그램의 편리를 위해 만들어진 클래스이다. 프로그램을 하면 반드시 Global로 만들어야 할 프로시져나 변수들이 존재하게 된다. 이를 기능적으로 분리하기 위해 utility class를 사용한다. Utility class 내부에 존재하는 attribute나 operation의 경우 Global 변수나 프로시져로 인식하면 된다.

13. MetaClass
MetaClass의 표기는 스테레오타입을 'metaclass'로 가지는 클래스이다. 이것은 metaclass의 인스턴스가 클래스가 되는 클래스를 의미한다.

14. Enumeration
Enumeration Class의 경우 스테레오타입을 'enumeration'으로 가지는 클래스이다. Enumeration Class의 의미는 프로그램언어에서 사용되는 일반적인 enumeration type과 의미가 유사하다. 정확한 Enumeration Class의 의미는 이 클래스의 인스턴스는 반드시 사용자가 정의한 특정 문자의 집합이어야 한다는 것이다. 이러한 문자는 상대적인 순서를 가지게 된다.

15. Stereotype
Stereotype Class의 경우 UML에서 사용되는 의미확장의 도구인 stereotype을 UML에서 지정한 것 이외에 사용자 정의 스테레오타입을 만들기위해 사용되는 클래스이다. Stereotype Class의 표기는 스테레오타입을 'stereotype'으로 가진다.
 
16. Class Pathname

클래스를 표기함에 있어서 UML에서 패키지(Package)를 같이 붙여 클래스의 범위를 지정할 수 있다. 패키지는 UML에서 Namespace역할을 한다. 패키지에 대한 자세한 설명은 차후 다이어그램에서 공통으로 사용되는 요소를 설명할 때 하기로 한다. 패키지속에 패키지가 포함 될 수 있으므로 패키지 path를 다 적용하여 클래스의 Pathname을 표기하기도 한다.
지금까지 클래스 다이어그램에서 정의하는 확장된 의미의 표기를 살펴보았다. 참고로 이러한 모든 내용에 대하여서 자세히 알고 싶다면 UML Spec을 보는 것이 도움이 될것이다.
실무에서는 시스템을 구성하는 클래스를 뽑아내고 그것의 역할을 지정하고 연관을 맺는 것이 가장 힘든 일일 것이다. 이것에 대한 정확히 정립된 방법은 존재하지 않는다. 약간이나마 정형화된 클래스를 뽑아내는 시점에 관하여 적어보면 통상 시스템 구축에 있어서 유스케이스 다이어그램을 그려서 시스템의 큰 기능을 만들고 그 유스케이스의 흐름을 가지고 시퀀스나 콜레버레이션 다이어그램에서 객체와 객체사이의 인터렉션을 정의하게 된다. 여기서 사용되는 객체의 행위와 속성을 가지고 클래스의 구체적 형상을 뽑아낼 수 있을 것이다. 물론 여러 번의 반복을 통한 클래스이 확정이 필요할 것이다.





http://blog.daum.net/question0921/946

http://hongjinhyeon.tistory.com/25



Posted by GENESIS8

댓글을 달아 주세요


SP란 무엇일까? 

물론 스페셜 포스나 스킬 포인트는 아니다.


SP란 stored procedure의 약자라고 한다.


store - 가게 , 매장 , 상점 이 보통이지만, 여기서의 stroe는

'저장' , '비축' 등의 의미로 쓰인다.


ed

  • 명사 붙어서 「… 있는」 「… 가진  형용사 만듦

설마, 내가 이걸 다시 보고 궁금할 까봐 적어놓는다.
store + ed 라서 stored인 이유는 다음의 링크에 소개되어 있다.
http://www.eec.co.kr/student/tutor?action=knowledge&topArticleNo=3123&page=749&screenState=S&viewCountGubun=Y

결론적으로
stored -> 저장하는.. / 저장 중인.. 과 같이 되겠다.

procedure - 절차 , 처리등을 의미한다.
그렇지만 그냥 프로시저다. 리턴 값이 없는 함수라고 간소하게 생각하자.

저장 프로시저?? 프로시저를 저장해놓는다는 의미일까?

위키의 친절한 설명을 보겠다.
저장 프로시저 또는 스토어드 프로시저(stored procedure)는 일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합이다. 데이터베이스에 대한 일련의 작업을 정리한 절차를 관계형 데이터베이스 관리 시스템에 저장한(지속성) 것으로, 영구저장모듈(Persistent Storage Module)이라고도 불린다.


즉 DB에 대한 작업을 정리한 절차(procedure)를 RDBMS에 저장한 쿼리의 집합이다.

그래도 잘 모르겠다.

http://itability.tistory.com/51

에서 좋은 내용들을 퍼온다.


음.. 일단 간단히 가자면 쿼리문의 함수화 버전이다.

쿼리문을 일일히 쳐야하는 작업이 있다. 근데 그게 여러번 해야하는 작업이라면 SP로 만들어두면 함수 쓰듯이 계속해서 쉽게 처리할 수 있게 된다.


1. SP는 최적화 되고 캐싱 된다.



SP는 최초 실행될 때 최적화된 상태로 컴파일이 되고 이후에 DB에 캐싱되어 저장된다.

캐쉬에 저장되면 최적화와 컴파일 작업을 다시 하지 않는다. 따라서 하나의 SP가 여러 번 쓰

일 때 성능에 향상이 있다.

 

2. 네트워크 트래픽을 감소 시킨다.

SP를 사용하면 SQL문이 서버에 저장된다. SP를 사용하면 수백개의 SQL문이 필요한 일도

서버에서 SP로 처리 하기 때문에 쿼리문 자체를 전달하지 않아도 된다. 이 때 각각의 클라이

언트는 매개변수만 전달한다.


보안측면

SP에서 참조하고 있는 테이블에 접근을 허용하지 않을 수 있다. 내부적으로 Update하는

쿼리를 가진 SP의 경우 민감할 수 있다. 무기, 레벨, 재화 등등의 저장을 SP를 통해서만

하게 하면 외부의 조작으로부터 하나의 보호막을 만들 수 있는 것이다.

 



SP는 CREATE PROCEDURE 쿼리문을 통해 만들 수 있다.

@가 붙어 있는 name은 매개 변수이다. 매개 변수 이름과 타입을 지정해 놓았다.

SET NOCOUNT ON/OFF는 중요하다.

SET NOCOUNT OFF 일 경우 반환하는 값은 SP 내부에서 SELECT, UPDATE 등을 사용한

횟수이다. 따라서 원하는 값을 반환 받기 위해서는 SET NOCOUNT ON으로 설정해주어야 한

다. 여기서는 앞서 맏늘어 놓은 PlayerTable에 전달 받은 @name으로 새로운 Player를

만들고 있다.

 


음 뭔 지는 대충 알겠는데.. 아직 감이 안온다. 겨울이라 그럴지도.
http://egloos.zum.com/decalruma/v/397650
를 참고해보자

데이타 베이스에서 프로시저란 보통 저장 프로시저(stored procedure)
를 말합니다.

그것은 원론적으로 말해서 일반 함수가 하는것과 거의 비슷한 일을 하고
개념도 비슷합니다. 다만 그것은 DB서버측에 위치한다는 것입니다.
DB 서버측에 만들어 두는 함수 정도로 이해하시면 되겠습니다.
(* 리턴값을 넘겨주는 방식에서 함수와는 약간의 차이가 있습니다.)

여기서 중요한 것은 프로시져는 서버측(Server side)에 탑재된다는 것입니다.
그렇다면 클라이언트에서 그냥 함수 만들어서 쓸것이지, 왜 골아프게 저장 프로시져
같은걸 만들어서 DB서버측에 넣어놓나? 하실겁니다.

그 이유는.. DB 서버측에 저장 프로시져로 넣어놓으면 일관성있고.. 관리가 쉬워지며
유지보수가 용이하다는 장점이 있기 때문입니다.
프로시져를 애용하는 어떤 프로그래머들은 대부분의 기능을 클라이언트 어플리케이션에 구현하지 않고 DB서버에다가 프로시져로 만들어놓고 사용한다는(?) 괴설도 들어본적이 있습니다. ㅡ_ㅡ;;

예를들어 사용자가 100만명으로 운용되는 시스템이 있는데, 어떤 기능을 변경해야 한다면... 각 어플리케이션이 새로 접속할때마다 업그레이드를 해주거나 업그레이드 패치를 100만명에게 새로 배포해야 할 것입니다.

그러나 변경해야 할 기능을 프로시져로 만들어 두었다면 DB서버에서 해당 프로시져를 한번 수정해 주는것으로 수정사항이 즉시 모든 사용자들에게 반영이 됩니다.
놀라운 효과죠?...

이런 등등의 이유로 저장 프로시져란 것을 사용하는 것으로 알고 있습니다. 



쿼리문을 함수화 해서 넣어두면
SQL이 자체적으로 컴파일을 해서 씁니다..
만약 쿼리문을 그냥 프로그램안에 둔다면..
요청->실행->응답 이런 순이겠지요..
만약 요청이 5번이라면 실행도 5번이 됩니다.

하지만 프로시져라면
요청->컴파일->실행->응답 이 되구요..
5번이라면 
요청->실행(메모리)->응답이 됩니다.
훨씬 빠른 속도로 수행이 되죠..
게다가 쿼리문을 보호하는 기능도 됩니다.. 


음 대충 느낌이 온다. 이제 위키의 친절한 예제를 보자.

CREATE OR REPLACE PROCEDURE helloworld (str IN VARCHAR2)
  AS
     hw VARCHAR2 (100) : = 'Hello World!';
  BEGIN
     DBMS_OUTPUT. PUT_LINE ( 'Hello World!');
     DBMS_OUTPUT. PUT_LINE ( 'VARIABLE hw ='| | hw);
     DBMS_OUTPUT. PUT_LINE ( 'Parameter str ='| | str);
  END;
  /

데이터베이스 언어 표준 SQL에서는 SQL / PSM 기준으로 책정되어 있다. 벤더(제조사) 각사 모두 정적, 동적 SQL에 커서 처리 및 제어 구문, 예외 처리 등을 포함한 사양의 확장 언어로 절차를 설명할 수 있는 DBMS를 제공하는 경우가 많다. 또한 C 언어로 작성된 컴파일한 외부 모듈(공유 라이브러리) 및 Java 클래스 라이브러리에서 함수나 클래스 메소드를 호출하는 것으로 실현하는 ‘외부 프로시저’ 기능을 구현하는 것도 있다. 저장프로시저를 사용하여 다음과 같은 장점이 있다.

  1. 하나의 요청으로 여러 SQL문을 실행 할 수 있다. (네트워크에 대한 부하를 줄일 수 있다.)
  2. 미리 구문 분석 및 내부 중간 코드로 변환을 끝내야 하므로 처리 시간이 줄어든다.
  3. 데이터베이스 트리거와 결합하여 복잡한 규칙에 의한 데이터의 참조무결성 유지가 가능하게 된다. 간단히 말하면 응용 프로그램 측 로직을 가지지 않고도 데이터베이스의 데이터 앞뒤가 맞게 될 수 있다.
  4. JAVA 등의 호스트 언어와 SQL 문장이 확실하게 분리된 소스 코드의 전망이 좋아지는 것, 또한 웹사이트 등 운용 중에도 저장프로시저의 교체에 의한 수정이 가능하기 때문에 보수성이 뛰어나다.

장점만 있는 줄 알았더니 단점이 있다.

저장프로시저를 많이 사용하면 다음과 같은 단점이 있다.

  1. 데이터베이스 제품에 대해 설명하는 구문 규칙이 SQL / PSM 표준과의 호환성이 낮기 때문에 코드 자산으로의 재사용성이 나쁘다.
  2. 비즈니스 로직의 일부로 사용하는 경우 업무의 사양 변경 시 외부 응용 프로그램과 함께 저장프로시저의 정의를 변경할 필요가 있다. 이때 불필요한 수고와 변경 실수에 의한 장애를 발생시킬 가능성이 있다.



프로시저와 스토어드 프로시저는 다르다는 점

SP가 보안을 강화시킬 수 있다는 점
SP가 속도를 빠르게 할 수있다는 점
Parameter Sniffing을 방지할 수 있다는 점
들에 대해서는 좀 더 구체적인 수집이 필요할듯.. 수정 필요

http://www.sqler.com/392656

ㄴ의 글이 많은 도움이 될 것 같다.



'프로그래밍 > DB' 카테고리의 다른 글

샤딩(Sharding)이란?  (0) 2016.01.25
SP란? Stored Procedure [수정필요]  (1) 2016.01.21
Posted by GENESIS8

댓글을 달아 주세요

  1. 방문자1 2018.01.12 11:12  댓글주소  수정/삭제  댓글쓰기

    링크 클릭이 안되서 당황;;