비주얼 스튜디오에서 관리해야 되는 파일이 많아지면 많아 질 수록 원하는 파일을 찾는게 어려워진다.


작업을 하다가 [F12] 정의로 이동으로 이동을 자주 하게 되는데 이럴때에 솔루션 탐색기가 해당 파일의 위치를 찾을 때 


곤혹을 치를 때가 있는데 이럴때 ( 도구 -> 옵션 -> 프로젝트 및 솔루션 -> 일반 )  


< 솔루션 탐색기에서 활성 항목 추적  > 옵션을 키게 되면 내가 편집하는 파일을 솔루션 탐색기에서 


자동으로 위치를 추적하게 되면서 작업의 효율성을 높이게 된다.

저작자표시 비영리

하나의 운영환경으로부터 더 나은 운영환경으로 옮아가는 과정을 뜻하는 정보통신 용어

윈도95에서 윈도98로 업그레이드하거나, 윈도NT 서버에서 윈도2000 서버로 옮아가는 것과 같이 하나의 운영체계로부터 더 나은 다른 운영체계로 옮아가는 과정을 말한다. 크게는 윈도NT에서 유닉스를 기반으로 하는 운영체계로 옮아가는 과정이나 그 반대 과정, 새로운 하드웨어나 소프트웨어 또는 둘 다 바뀌는 환경으로 이주하는 것, 데이터를 하나의 저장장치에서 다른 저장장치로 옮기는 과정 등을 포함한다.

이전의 운영체계에서 설정된 프로그램을 바꿀 필요 없이 현재의 응용프로그램을 새로운 환경에서도 계속 운영할 수 있고, 새로운 운영체계만이 가지고 있는 특성들을 이용할 수 있을 때 흔히 행해진다. 단일 시스템에서 다른 단일 시스템으로 옮아가는 소규모 마이그레이션에서부터 많은 시스템들이 새로운 응용프로그램이나 네트워크로 옮아가는 대규모 마이그레이션에 이르기까지 규모나 형식도 다양하다.

그러나 데이터베이스의 경우 새로운 데이터베이스가 이전의 데이터베이스와 구성 요소가 다를 수도 있기 때문에 실행 파일들을 처리할 수 있는 프로그램이 필요한 경우도 있다. 따라서 이전의 데이터베이스를 마이그레이션할 때는 새로운 데이터베이스와 공통된 형식으로 데이터를 변환하는 작업이 필요하다

출처: http://yeonorang99.tistory.com/entry/마이그레이션이란 [Park's test]

저작자표시 비영리

안녕하세요 푸민입니다.

 

UML 기호를 정리합니다~

 

1. Class

- 클래스를 나타냅니다.

 

- 기호

 

- 소스

class ClassName {

public Object Attribute1;

protected int Attribute2;

private String Attribute3;

 

public void Operation1(){

...

}

protected int Operation2(){

...

}

private String Operation3(String str){

...

}

}

 

 

2. Generalization - 일반화, 상속

- 상속을 받은 객체를 표시한다.

 

- 기호

 

 

- 소스

class Parents{

...

}

class Child extends Parents{

...

}

 

 

3. Realization - 실체화, 구현

- 인터페이스를 구현한다.

 

- 기호

 

- 소스

interface Interface{

...

}

class Class implements Interface{

...

}

 

 

4. Dependency - 의존, 파라미터, 리턴 값 등

- 의존적인 성격을 가지고 있는 파라미터, 리턴값 등에 사용할 경우 표시한다. Contract에서 변화가 생기면 Phone에서 코드의 변화를 줘야한다.

 

- 기호

 

- 소스

class Contact{

...

}

class Phone{

public void call(Contact contact){

...

}

}

 

 

5. Association - 연관

- 관계를 나타낼때 사용

 

- 기호

 

- 소스

class AssociationClass{

public void test(){

Constant.STR;

}

}

 

 

6. Directed Association - 직접 연관

- 직접적으로 해당 클래스를 변수로서 사용함, person 객체가 있어도 되고 없어도 된다.

 

- 기호

 

- 소스

class Person{

...

}

class Car{

private Person person;

}

 

 

7. Aggregation - 집합, 집합 연관

- 해당 클래스를 직접 생성하지는 않고 인스턴스를 받아서 사용한다.

 

- 기호

 

- 소스

class Fuel{

...

}

class Car{

private Fuel fuel;

 

public Car(Fuel fuel){

this.fuel = fuel;

}

}

 

 

8. Composition - 합성, 합성 연관

- 클래스를 직접 인스턴스로 생성하여 사용한다.

 

- 기호

 

- 소스

class Engine{

...

}

class Car{

private Engine mEngine;

public Car(){

mEngine = new Engine();

}

}

 

 

9. InnerClass - 이너 클래스

- 클래스 내부에 클래스를 정의한다.

 

- 기호

- 소스

class Phone{

...

class Contact{

...

}

} 



출처: http://fumin.tistory.com/45 [푸민의 블로그]

저작자표시 비영리



Unity - 앱스토어, 플레이스토어 링크 및 웹 페이지 열기


[iOS 앱 스토어 링크 열기]


* 앱 스토어 앱으로 열기


   Application.OpenURL("itms-apps://itunes.apple.com/app/id1234567890")




[Android 플레이 스토어 링크 열기]

* 마켓 앱으로 열기


   Application.OpenURL("market://details?id=com.Company.Project");


* 일반 웹 브라우져로 열기


   Application.OpenURL("https://play.google.com/store/apps/details?id=com.Company.Project");



[일반 웹 페이지 열기]


* 일반 웹 브라우져로 열기

 - 일부 Adroid 기기에서는 "http:"를 생략하면 링크가 열리지 않는 현상이 있음


   Application.OpenURL("http://lge.cn/")


[출처] http://lgecn.tistory.com/29

저작자표시 비영리



출처 : http://www.nextree.co.kr/p6753/



본글은 위 출처에서 퍼온 자료임을 알려드립니다.



불과 몇 년 되지 않은 학생 시절… 처음으로 UML을 접했고, UML의 기초적인 그리는 법과 사용법을 배웠습니다. 개인적으로 쉽지 않은 수업이었는데 그 중 가장 많이 사용되는 클래스 다이어그램에서 클래스간의 relationship(관계)가 제일 어려웠습니다.Generalization(일반화)과 Realization(실체화)은 명확하기 때문에 이해하는데 어려움이 없었고 Dependency(의존) 부터 조금 어려워 지더니 Association(연관)과 Aggregation(집합), Composition(합성) 3종 세트에 가서는 머리가 복잡해졌습니다. 특히 Aggregation과 Composition이 논리적으로 약하고 강한 집합이라는 차이는 알겠지만 ‘그래서 어떤 명확한 차이점이 발생하는 거지? 저걸 코드로 만들 때는 어떻게 만들어야 하는 거지?’라는 생각과 함께 잘 와 닿지 않았습니다.

그래서 2013년 9월에 진행 됐던 ’2013 넥스트리 신입사원 인큐베이션 세미나’에서 발표 주제를 UML 클래스 다이어그램으로 정하고 그 동안 배운 것들과 추가로 공부를 더한 것들로 발표를 했고, 많은 도움이 됐던 시간이었습니다. 세미나 발표 후 몇가지 내용에 대한 아쉬움이 있었는데, 이번 기회에 그 아쉬움과 부족했던 부분을 보완하여 글로 정리하게 되었습니다. UML 클래스 다이어그램의 기본적인 요소들과 클래스간의 관계, 그리고 제가 제일 어려웠던 이 관계들을 어떻게 코드로 나타내어야 할지에 대해서 썼으며 언어는 Java 기준으로 하였습니다. ’2013 신입사원 인큐베이션 세미나’에 대한 글도 Nextree 홈블로그에서 보실 수 있습니다.

 

1. UML

UML이란 Unified Modeling Language의 약자로 1997년 OMG(Object Management Group)에서 표준으로 채택한 통합모델링언어 입니다. 즉, 모델을 만드는 표준언어인 것입니다. 모델이란 것은 어떤 것을 실제로 만들 때 이렇게 만들면 잘 작동할지 미리 검증해 보는 것이며 실제 물건을 만드는 비용보다 비용이 훨씬 적을 경우에 모델을 만들어 설계를 검사합니다.

소프트웨어에서의 모델은 건축, 항공 등의 모델과는 좀 다른 면이 있습니다. 건물을 짓고, 항공기를 만드는 것과 설계를 그리고 만드는 것은 비용의 엄청난 차이가 있습니다. 하지만 UML 다이어그램을 그리며 모델을 만드는 일은 개발보다 비용이 적긴 하지만 훨씬 적게 드는 것이 아니며 때로는 오히려 개발보다 비용이 더 많이 들 수도 있습니다. 그래서 UML은 시험해 볼 구체적인 것이 있고, 그것을 코드로 시험해 보는 것보다 UML로 시험해 보는 쪽이 비용이 덜 들 때 주로 사용합니다. 이러한 목적으로 UML을 사용하는 유형에는 다음 3가지 정도가 있습니다.

  • 다른 사람들과의 의사소통 또는 설계 논의
  • 전체 시스템의 구조 및 클래스의 의존성 파악
  • 유지보수를 위한 설계의 back-end 문서

UML을 그리는데 가장 좋은 도구는 종이와 펜이라는 말이 있듯이 습관적으로 만드는 게 아니라 필요에 의해 만드는 것이 가장 좋은 것 같습니다.

 

2. Class Diagram (클래스 다이어그램)

[그림 1] UML 다이어그램의 종류 출처: www.ask.com/wiki/Unified_Modeling_Language#UML_2.x

[그림 1] UML 다이어그램의 종류
출처: www.ask.com/wiki/Unified_Modeling_Language#UML_2.x

UML은 구조 다이어그램 7개, 행위 다이어그램 7개로 총 14종류의 다이어그램이 있습니다. 구조 다이어그램은 시스템의 개념, 관계 등의 측면에서 요소들을 나타내고 각 요소들의 정적인 면을 보기 위한 것이고 행위 다이어그램은 각 요소들 혹은 요소들간의 변화나 흐름, 주고받는 데이터 등의 동작을 보기 위한 것으로, 클래스 다이어그램은 구조 다이어그램에 해당합니다. 클래스 다이어그램은 클래스 내부의 정적인 내용이나 클래스 사이의 관계를 표기하는 다이어그램으로 시스템의 일부 또는 전체의 구조를 나타낼 수 있습니다. 클래스 다이어그램은 의존 관계를 명확히 보게 해주며, 순환 의존이 발생하는 지점을 찾아내서 어떻게 이 순환 고리를 깨는 것이 가장 좋은지 결정할 수 있게 해줍니다.

[그림 2] 목적 별 클래스 다이어그램

[그림 2] 목적 별 클래스 다이어그램

UML은 목적에 따라 다르게 사용되는데, 크게 3가지로 개념, 명세, 구현의 차원들 입니다.먼저 개념 차원의 UML은 문제 도메인의 구조를 나타내며 사람이 풀고자 하는 문제 도메인 안에 있는 개념과 추상적 개념을 기술하기 위한 것입니다. 이것은 소스코드와 관계가 그렇게 깊지 않으며 오히려 사람의 자연언어와 더 관련이 있습니다. 또한 의미론적(언어의 뜻을 규정하는) 규칙에 그다지 얽매이지 않으며, 따라서 의미하는 바도 모호하거나 해석에 따라 달라질 수 있는 부분이 존재합니다.

반면, 명세와 구현 차원의 UML은 소프트웨어의 설계 혹은 완성된 소프트웨어의 구현 설명 목적 등으로 사용하며 설계를 해서 소스코드로 바꾸거나 구현 된 소스코드를 설명하려고 사용하기 때문에 소스코드와 관계가 깊습니다. 이 두 차원의 클래스 다이어그램은 제약이 많아서 반드시 일정한 규칙과 의미론을 지켜야 합니다. 또한 모호성이 거의 없도록 하고 형식도 최대한 맞춰야 합니다.

앞으로 나올 내용들은 구조 다이어그램 중 하나인 클래스 다이어그램이며 그 중에서도 개념 차원은 배제하고 소스코드와 관계가 깊은 명세, 구현 차원에 해당하는 클래스 다이어그램만으로 한정 지어 소스코드와 어떻게 연관 되는지 이해해 보도록 하겠습니다. 따라서 개념 차원의 클래스 다이어그램과는 조금 다른 부분이 있을 수 있습니다.

 

3. 클래스 다이어그램의 요소(Element)

Class (클래스)

클래스는 보통 3개의 compartment(구획)으로 나누어 클래스의 이름, 속성, 기능을 표기합니다. 속성과 기능은 옵션으로 생략이 가능하지만 이름은 필수로 명시해야 합니다.

[그림 3] 클래스

[그림 3] 클래스

클래스의 세부사항은 필드와 메서드의 Access modifier(접근제한자), 필드명(메서드명), 데이터타입, parameter(매개변수), 리턴 타입 등을 나타낼 수 있습니다. 클래스의 세부사항들을 상세하게 적는 것이 유용할 때도 있지만, UML 다이어그램은 필드나 메서드를 모두 선언하는 곳이 아니기 때문에 다이어그램을 그리는 목적에 필요한 것만 사용하는 것이 좋습니다. 추가로 보통 3개의 구획(compartment)을 사용 하지만 다른 미리 정의되거나 사용자 정의 된 모델 속성(비즈니스 룰, 책임, 처리 이벤트, 발생된 예외 등)을 나타내기 위한 추가 구획도 사용할 수 있다고 합니다.

 

Stereo Type (스테레오 타입)

스테레오 타입이란 UML에서 제공하는 기본 요소 외에 추가적인 확장요소를 나타내는 것으로 쌍 꺾쇠와 비슷하게 생긴 길러멧(guillemet, « ») 사이에 적습니다. 이 길러멧이란 기호는 쌍 꺾쇠와는 좀 다른 것으로 폰트 크기보다 작습니다. 종이나 화이트보드에 그릴 때는 상관없지만 공식적인 문서라면 이 기호를 구분해서 사용하는 것이 좋을 것 같습니다.

[그림 4] 스테레오 타입

[그림 4] 스테레오 타입

위의 다이어그램은 인터페이스와 유틸리티 클래스를 표현하고 있으며 필드, 메소드 밑의 밑줄은 static(정적)필드 또는 메서드를, {readOnly}는 final 키워드를 사용하는 상수를 의미합니다. 스테레오 타입으로 많이 사용되는 것은 «interface», «utility», «abstract», «enumeration» 등이 있습니다.

 

Abstract Class/Method (추상 클래스 / 메서드)

추상클래스란 1개 이상의 메서드가 구현체가 없고 명세만 존재하는 클래스를 말합니다.

[그림 5] 추상클래스

[그림 5] 추상클래스

추상 클래스의 이름과 메서드는 italic체나, {abstract} 프로퍼티를 사용하여 표기합니다. UML 툴에서는 italic체로 표기하는 것이 많지만 종이나 칠판에 그릴 때는 힘들게 italic체로 기울여서 적는 것 보다는 {abstract} 프로퍼티로 표기하는 것이 쉽고 명확할 것 같습니다.
또한 공식적인 것은 아니지만 스테레오타입을 사용하여 추상 클래스를 표기하기도 합니다.

 

4. 클래스간의 관계

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

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

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

위의 그림은 클래스간의 관계들의 종류와 표기법을 나타낸 것입니다. 이 외에 다른 표기법도 있습니다만 많이 사용된다고 생각하는 것들만 나타냈습니다.

 

Generalization (일반화)

Generalization은 슈퍼(부모)클래스와 서브(자식)클래스간의 Inheritance(상속) 관계를 나타냅니다. 여기서 Generalization이란 서브 클래스가 주체가 되어 서브 클래스를 슈퍼 클래스로 Generalize 하는 것을 말하고 반대의 개념은 슈퍼 클래스를 서브 클래스로 Specialize(구체화) 하는 것입니다. 상속은 슈퍼 클래스의 필드 및 메서드를 사용하며 구체화 하여 필드 및 메서드를 추가 하거나 필요에 따라 메서드를 overriding(오버라이딩) 하여 재정의 합니다. 또는 슈퍼 클래스가 추상 클래스인 경우에는 인터페이스의 메서드 구현과 같이 추상 메서드를 반드시 오버라이딩 하여 구현하여야 합니다.

[그림 7] Generalization

[그림 7] Generalization

위와 같이 표기법은 클래스 사이에 실선을 연결하고 슈퍼 클래스 쪽에 비어 있는 삼각형으로 나타내고 자바에서는 extends 키워드를 사용하여 상속을 구현합니다.

 

Realization (실체화)

Realization은 interface의 spec(명세, 정의)만 있는 메서드를 오버라이딩 하여 실제 기능으로 구현 하는 것을 말합니다.

[그림 8] Realization

[그림 8] Realization

Realization을 나타내는 표기법은 2가지가 있습니다. 첫 번째는 인터페이스를 클래스처럼 표기하고 스테레오 타입 «interface»를 추가합니다. 그리고 인터페이스와 클래스 사이의 Realize 관계는 점선과 인터페이스 쪽의 비어있는 삼각형으로 연결합니다. 두 번째는 인터페이스를 원으로 표기하고 인터페이스의 이름을 명시합니다. 그리고 인터페이스와 클래스 사이의 관계는 실선으로 연결합니다.
자바에서는 위와 같이 implements 키워드를 사용하여 인터페이스를 구현합니다.

 

Dependency (의존)

Dependency는 클래스 다이어그램에서 일반적으로 제일 많이 사용되는 관계로서, 어떤 클래스가 다른 클래스를 참조하는 것을 말합니다.

[그림 9] Dependency

[그림 9] Dependency

위의 그림은 자바에서 참조하는 형태에 대해 코드를 보여주고 있습니다. 참조의 형태는 메서드 내에서 대상 클래스의 객체 생성, 객체 사용, 메서드 호출, 객체 리턴, 매개변수로 해당 객체를 받는 것 등을 말하며 해당 객체의 참조를 계속 유지하지는 않습니다.

[그림 10] Dependency Stereo Type

[그림 10] Dependency Stereo Type

추가로 위와 같이 스테레오 타입으로 어떠한 목적의 Dependency인지 의미를 명확히 명시 할 수도 있는데 Dependency의 목적 또는 형태가 중요할 경우 사용할 수도 있을 것 같습니다.

 

Association (연관), Directed Association(방향성 있는 연관)

클래스 다이어그램에서의 Association은 보통 다른 객체의 참조를 가지는 필드를 의미합니다. 아래 클래스 다이어그램은 두 가지 형태의 Association을 나타내고 있습니다.

[그림 11] Assocication

[그림 11] Assocication

첫 번째 다이어그램은 일반적인 Association으로 단지 실선 하나로 클래스를 연결하여 표기하고 두 번째 다이어그램은 Directed Association으로 클래스를 실선으로 연결 후 실선 끝에 화살표를 추가합니다. Association과 Directed Association의 차이는 화살표가 의미하는 navigability(방향성)인데 이것에 따라 참조 하는 쪽과 참조 당하는 쪽을 구분합니다. 두 번째 다이어그램은 User에서 Address 쪽으로 화살표가 있으므로 User가 Address를 참조하는 것을 의미합니다. Navigability가 없는 Association은 명시되지 않은 것으로 User가 Address를 참조할 수도, Address가 User를 참조할 수도, 또는 둘 다일 수도 있는 것을 의미합니다. 화살표 옆에 있는 –addresses는 roleName(역할명)을 나타내고 Address가 User 클래스에서 참조될 때 어떤 역할을 가지고 있는지를 의미합니다.

*는 Multiplicity(개수)을 나타내는데 대상 클래스의 가질 수 있는 인스턴스 개수 범위를 의미합니다. 0…1 과 같이 점으로 구분하여 앞에 값은 최소값, 뒤에 값은 최대값을 의미하는데 *은 0…*과 같은 의미로 객체가 없을 수도 있고 또는 수가 정해지지 않은 여러 개일 수도 있다는 것을 의미합니다. 이전에는 Multiplicity가 아닌 Cardinality로 불렸는데 “특정 집합 또는 다른 그룹에 있는 요소의 수”라는 Cardinality의 사전적 의미가 실제 인스턴스의 수가 아닌 가질 수 있는 범위를 지정하는 클래스 다이어그램에서의 의미에 적합하지 않다는 이유로 바뀌었습니다.

세 번째의 다이어그램은 두 번째의 다이어그램과 비슷한 의미를 가지고 있지만 다른 형태인 속성 표기법으로 나타낸 것입니다. 여기서 보는 바와 같이 roleName은 보통 클래스의 필드명이 됩니다. 속성 표기법이 두 번째 클래스 다이어그램과 조금 다른 점은 여러 개의 객체에 대한 Container(컨테이너)가 List라는 것까지 알려주고 있습니다.

그럼 두 번째와 세 번째의 다이어그램이 완전히 동일한 의미를 가지게 하려면 어떻게 해야 할까요?

[그림 12] Association Class

[그림 12] Association Class

위와 같이 Association Class(연관클래스)를 사용하여 어떤 종류의 컨테이너 클래스가 사용되는지 까지 나타낼 수 있습니다. 하지만 사실 특이한 클래스도 아니고 자바에서 기본으로 제공되는 List를 저렇게 표기하는건 조금 귀찮은 일일 수 있을 것 같습니다. 그래서 스테레오 타입으로 표기할 수도 있습니다. 이로써 [그림11] 세 번째 다이어그램의 속성 표기법으로 표현된 것과 모든 의미가 같아졌습니다. 보통은 클래스의 속성이 기본 제공 클래스가 아니거나 중요 또는 강조하고 싶을 때 Association 관계로 나타냅니다. Association Class는 조금 다른 의미로도 사용될 수 있습니다. 예를 들어 학생과 수강과목 클래스가 Association 관계를 가지고 있는데 단순 Association 관계가 아니라 각 관계마다 해당 과목의 학점이라는 속성이 필요하다면 어떻게 나타낼 수 있을까요? 이럴 때도 Association Class를 사용하여 나타낼 수 있습니다.

[그림 13] Association Class

[그림 13] Association Class

물론 grade라는 값을 Subject 클래스 자체의 속성으로 할 수도 있지만 Subject의 속성이라기 보다는 Student와 Subject 사이의 관계에 대한 속성이라는 관점에서 위의 다이어그램처럼 Association Class로 나타낼 수 있습니다.

[그림 14] Association Class Vs Association

[그림 14] Association Class Vs Association

또한 [그림13]의 Association Class를 풀어서 위처럼 Association 관계만으로도 나타낼 수 있습니다. [그림13]은 Student와 Subject의 관계를 나타내고 싶은데 그 관계에 대한 속성값으로 Grade가 있는 것이고 [그림14]는 단순 3개 클래스를 Association 관계로 나타낸 것처럼 의미는 조금 다를 수 있으나 구현되는 코드는 같을 것입니다.

[그림 15] Association Class Code

[그림 15] Association Class Code

 
Aggregation (Shared Aggregation, 집합)

Aggregation은 Shared Aggregation이라고도 하며 Composition(Composite Aggregation)과 함께 Association 관계를 조금 더 특수하게 나타낸 것으로 whole(전체)와 part(부분)의 관계를 나타냅니다. Association은 집합이라는 의미를 내포하고 있지 않지만 Aggregation은 집합이라는 의미를 가지고 있습니다.

[그림 16] Aggregation

[그림 16] Aggregation

표기법은 위와 같이 whole과 part를 실선으로 연결 후 whole쪽에 비어있는 다이아몬드를 표기합니다. Part쪽에는 화살표를 명시하여도 되고 명시하지 않아도 됩니다. Aggregation의 다이아몬드가 이미 navigability의 방향을 표현하고 있기 때문입니다. 그런데 코드를 보시면 위에서 보았던 Association의 코드와 똑같습니다. Association과 Aggregation은 집합이라는 개념적인 차이는 있지만 코드에서는 이 차이를 구분하기 힘듭니다.

[그림 17] UML Aggreagtion

[그림 17] UML Aggreagtion
출처: OMG Unified Modeling Language Superstructure 2.4.1

위와 같이 UML은 집합이라는 개념 외에 명확한 Aggregation의 정의를 제공하지 않습니다. 그래서 여러 프로그래머나 분석가, 설계사가 Aggregation 관계에 대해 자기 나름의 정의를 내렸기 때문에 혼란이 생겼고 Aggregation은 사용하지 않는 것이 좋다고 합니다. 저도 이에 동의 하는 바이지만….. 아직도 논란이 되고 있는 부분이고 정확한 답을 내기는 어려울 것 같습니다.그리고 도서 “The Object Primer: Agile Model-Driven Development with UML 2.0(저자 Scott W. Ambler)”과 “UML 실전에서는 이것만 쓴다(저자 Robert C. Martin)”에 UML 2.0에서는 위의 문제 때문에 Aggregation이 제외 되었다는 말이 있습니다. 그래서 근거를 찾기 위해 이곳 저곳 찾아본 결과 처음엔 제외 되었다가 커뮤니티의 강력한 항의로 다시 들어왔다고 합니다. 실제로도 UML 1.x 버전에 비해 2.x 버전에는 Aggregation에 대한 내용이 많이 사라지긴 했지만 몇 군데 남아 있는 걸 확인했습니다.

[그림 18] Aggregation Dropped

[그림 18] Aggregation Dropped
출처: www.coderanch.com/t/154620/java-Architect-SCEA/certification/Association-Aggregation

 
Composition (Composite Aggregation, 합성)

Composition(또는 Composite Aggregation)도 Aggregation과 비슷하게 whole(전체)와 part(부분)의 집합 관계를 나타내지만 개념적으로 Aggregation보다 더 강한 집합을 의미합니다.

[그림 19] Composition

[그림 19] Composition

Composition의 표기법 또한 위와 같이 Aggregation과 비슷하지만 다이아몬드의 내부가 채워져 있다는 점만 다릅니다. 그럼 Composition의 개념과 코드에서는 Aggregation과 어떤 차이가 있는지 보겠습니다. Composition은 Aggregation보다 강한 집합이라고 했습니다. 여기서 강한 집합이란 part가 whole에 종속적이어서 part가 whole의 소유입니다. 반면 Aggregation은 part가 whole에 대해 독립적이어서 whole이 part를 빌려 쓰는 것과 비슷합니다. 이러한 의미 때문에 Aggregation과는 다르게 명확하게 나타나는 점이 있습니다.

  • 첫 번째, part를 가지는 whole 인스턴스가 part 인스턴스의 전체 수명을 책임진다.
  • 두 번째, part에 해당하는 인스턴스는 공유 될 수 없다.

첫 번째의 whole 인스턴스가 part 인스턴스의 전체 수명을 책임진다는 의미는 다음과 같습니다.

  • whole 인스턴스가 part 인스턴스를 생성
  • whole 인스턴스가 소멸되면 part 인스턴스도 함께 소멸
  • whole 인스턴스가 복사되면 part 인스턴스도 함께 복사

두 번째의 part에 해당하는 인스턴스는 공유 될 수 없다는 의미를 먼저 보겠습니다.

[그림 20] Shallow Copy

[그림 20] Shallow Copy

위의 예제는 클래스 다이어그램이 아닌 객체 다이어그램으로 [그림19]를 객체로 표현한 것입니다. 참조변수 userA가 참조하고 있는 user 객체를 clone하여 clonedUser 객체를 만들고 참조변수 userB에서 참조하고 있습니다. user객체는 제대로 복사가 됐지만 user객체 안에서 참조하고 있는 address는 clonedUser 객체도 똑같이 참조하고 있습니다. 이것을 shallow copy(얕은 복사)라고 하며 이 경우에 part에 해당하는 address 객체가 공유 된 것입니다. 또한 첫 번째 조건의 의미 중 whole 인스턴스가 복사되면 part인스턴스도 복사되어야 한다는 조건도 충족시키지 못했습니다.

[그림 21] Deep Copy Object Diagram

[그림 21] Deep Copy Object Diagram

위의 다이어그램에서는 user 객체가 복사되어 clonedUser 객체가 생성될 때 user 객체가 참조하여 가지고 있는 address 객체 또한 같이 복사 되어 clonedUser 객체는 새로운 clonedAddress 객체를 참조하여 가지고 있습니다.

[그림 22] Deep Copy Code

[그림 22] Deep Copy Code

Aggregation 관계와 Composition 관계를 UML 툴에서 그린 후 Code Generation을 하면 똑같은 코드가 생성됩니다. 하지만 Composition에서는 개발자가 구현해야 할 부분이 몇 가지 있습니다. 위에서 본 part에 해당하는 인스턴스가 공유되지 않게 하기 위한 Deep Copy 구현과 part를 가지는 whole 인스턴스가 part 인스턴스의 수명 전체를 책임져야 한다는 것에 따라 whole 클래스의 생성자 또는 기타 메서드 내에서 part 인스턴스를 생성해야 하고 외부에서 part 객체를 생성하지 못하도록 whole 클래스에는 part 인스턴스에 대한 setter가 있으면 안됩니다. 다른 언어에서는 생명주기와 관련된 다른 추가적인 것도 있겠지만 자바에서의 객체 소멸은 Garbage Collector가 수행하므로 part 인스턴스의 소멸은 신경쓰지 않아도 됩니다.

 

5. 마치며

이로써 클래스 다이어그램의 주요 요소들과 관계들이 소스코드와 어떻게 연관되는지를 살펴 봤습니다. 우선 많은 용어들에 대해 영문발음 그대로 한글로 표기하는 것들은 처음에만 영문 표기 후 한글로 표기하였고 영문 용어가 해석에 따라 달라질 수 있는 것들(예: Association->연관)은 최대한 영문 그대로 표기하였습니다.
또한 UML에서 attribute(속성), operation(기능)이라고 부르는 것들이 자바에서는 filed(필드), method(메서드)라 불리우기 때문에 의미는 비슷하지만 사용 관점에 따라 분리하여 사용한 것들도 있으며 초급 개발자로서 UML에 관련된 내용을 쓰려니 혹시 내가 잘못 알고 있는 것은 아닐까 조심스러워서 UML 스펙 문서를 많이 찾아가며 최대한 표준에 맞게 쓰려고 하였습니다.

저는 처음에 클래스 다이어그램을 공부하면서 개념적으로 들었을 때는 이해가 갈듯 말듯 하다가 코드를 보면서 아 이런 거구나 하며 그나마 조금 더 이해가 갔던 기억이 납니다. 설계를 하시는 분들이 아닌 저와 같이 이제 막 개발자의 길로 들어서신 초급 개발자 분들이 설계 다이어그램을 보며 어떤 식으로 이해를 해야 하고 어떻게 코드를 만들어야 할지 조금이라도 도움이 되었으면 합니다.

그리고… 개인적인 내용입니다만 아직 많이 모자라지만 1년동안 많은 도움을 주셨던, 특히나 UML과 설계와 관련된 많은 지식을 전해주신 제 멘토 김현오 선임께 감사하단 말씀을 제대로 못 드린 것 같아 여기서 감사의 말씀을 드리고 싶습니다..^^
감사합니다.

저작자표시 비영리

SonyWWS/LevelEditor · GitHub



Sony LevelEditor


OS: Windows7,32bit or 64bit (SP1 이상)

개발 환경: Microsoft .Net 4.0 , DirectX SDK June 2010., Visual Studio 2010 이후


이 레벨 에디터를 개발에 사용한 것은 PS3『The Last of Us』（Naughty Dog), PS4의『Killzone: Shadow Fall』（Guerrilla Game）등에서 사용된 오픈소스 프레임워크 「Authoring Tools Framework」.

에디터를 사용하려면 Visual Studio 2010에서 빌드할 필요가 있다.



Authoring Tools Framework (ATF)는 Windows 머신 상에서 툴을 만들기 위해 C#/.NET 컴포넌트로 소니의 퍼스트 파티 게임 스튜디오의 대부분에서 많은 커스텀 툴을 만들 때 사용되고 있다.

Naughty Dog 의『The Last of Us』 의 레벨 에디터 및 세이더 에디터, Guerrilla Games 의  KILLZONE 프랜차이즈 (PS4 의 런칭 타이틀『KILLZONE SHADOWFALL』도 포함) 의 시퀸스 에디터 , SCE 산타모니카 스튜디오의 아니메이션 블렌딩 툴, SCE 벤드 스튜디오의 레벨 에디터, Quantic Dream의 비주얼 스테이트 머신 에디터, 사운드 편집 툴 등이 사례이다.

2006년를 시작으로 소니 월드 와이드 스튜디오 중심으로 툴 그룹에 의해 계속 개발하고 있다.

ATF는 GitHub 에서 공개 되고 있는 오픈 소스 프로젝트이다.

https://github.com/SonyWWS


출처: http://3dnchu.com/archives/sce-leveleditor/

저작자표시 비영리

안녕하세요. 소심비형입니다. Visual Studio Community 2015와 Xamarin을 이용하여 모바일 크로스 플랫폼 환경을 구성하는 방법에 대해서 알아보도록 하겠습니다. 크로스 플랫폼이다보니 Android와 Windows Phone, iOS에 대한 앱 개발 라이센스와 회원 가입이 모두 되어 있어야 하고, 유료 등록이 되어 있어야 합니다. 개발자 라이센스를 등록하지 않았다면 몇가지 제약 사항이 따르게 됩니다.


Xamarin(자마린)이란?

모바일 크로스 플랫폼 환경을 제공하는 상용 3th party 제품으로, 모바일 앱(iOS, Android, Window Mobile)을 C#으로 만들 수 있습니다. MonoTouch 6.0 이후로 자마린으로 이름이 변경되었습니다.


시작...

비주얼 스튜디오 커뮤니티 2015에서 새 프로젝트를 선택합니다. (이전 버전의 경우 탬플릿이 없습니다.)

만약, Visual Studio Community 2015를 설치할 때 커스텀 설치로 "Xamarin (3th Party)"를 선택했다면 같이 설치가 되어 있을겁니다.

이미지 001.png



아직 템플릿이 추가되어 있지 않으므로 이름은 아무렇게나 지어도 됩니다. 저는 MyFirstApp으로 지정했습니다.

이미지 002.png



"Download Xamarin"을 클릭하세요! 아래 링크를 통해 직접 다운로드 후 설치해도 됩니다.

[ 다운로드 ]

이미지 003.png



자마린을 다운로드 하기 위한 기본적인 정보를 입력한 후 "Download Xamarin for Visual Studio" 클릭합니다. (회원 가입 후 로그인하면 다운로드 받을 수 있습니다.)

이미지 004.png



아래와 같이 입력한 후 다운로드를 클릭하세요! (이름과 이메일은 알아서 적당히 적으세요-_-; "소심비형" 적지 마시구요.)

이미지 005.png



다운로드 받은 XamarinInstaller.exe를 실행합니다.

이미지 006.png



현재 운영 체제의 보안이 낮게 설정되어 있다면 이 창은 나타나지 않을수도 있습니다. 실행을 클릭하세요.

이미지 007.png



Continue 클릭!

이미지 008.png



자마린을 설치하기 위해 필요한 필수 구성 요소도 같이 설치된다고 알려줍니다. Next를 클릭하세요.

이미지 009.png



라이센스에 동의하고 Next 클릭!

이미지 010.png



안드로이드 SDK도 같이 설치됩니다. Next를 클릭하세요.

이미지 011.png



Visual Studio가 켜져 있으면 나타나는 화면입니다. 아래 "Forec Visual Studio to quit."를 클릭하여 강제 종료하고 Next를 클릭하세요.

이미지 012.png



요구 사항을 확인하고 Next를 클릭하세요.

이미지 013.png



Java 라이센스에 동의하고 Next 클릭!

이미지 014.png



Android 라이센스에 동의하고 또 Next 클릭!

이미지 015.png



설치가 진행중입니다. 설치가 멈춘듯이 보일지도 모르지만, 계속 기다리다 보면 설치가 이어서 진행됩니다.

이미지 016.png



이제 맥에도 자마린을 설치합니다. 대부분 위의 내용과 동일합니다. 맥에서도 아래와 같이 설치가 진행됩니다.

0010.png


윈도우와 맥에 자마린이 모두 설치가 되었다면, 맥에서 환경 설정을 변경해야 합니다. 먼저, 윈도우에서 맥으로 로그인할 수 있도록 원격 로그인을 허용합니다. Spotlight 검색(Control + Space)에서 시스템 환경설정(system preferences)을 입력하고 검색되는 응용 프로그램을 실행하세요. 아래 그림처럼 공유를 선택하세요.

001.png

원격 로그인에 체크하고, 모든 사용자를 선택합니다.

002.png

맥에 Xcode가 설치되지 않았다면, 아래 링크에서 다운로드 받은 후 설치하세요.

[ 다운로드 ]

003.png

설치가 완료되면 Spotlight 검색(Control + Space)에 Xamarin을 입력하여 Xamarin Studio를 실행하세요.

002.png


상단의 Xamarin Studio > 환경 설정... > SDK 위치 > Apple을 선택합니다. 아래 그림처럼 Apple SDK가 정상적으로 바인딩 되어 있는지 확인하세요. 만약, X표시라면 우측의 찾아보기를 클릭한 후 Xcode.app를 직접 지정하면 됩니다.

※ 간혹, beta가 설치되어 있다면 Xcode-beta.app로 되어 있을 수 있습니다.

001.png


Spotlight 검색(Control + Space)에 Xcode를 입력한 후 실행하세요.

004.png



상단의 Xcode > Preferences... > Downloads로 이동하고, 컴포넌트에서 시뮬레이터를 다운로드 받습니다. 모두 받아도 상관은 없지만, 저의 경우 하드 용량이 부족하여 하나만 설치했습니다-_-;

003.png

만약, 맥북 프로 레티나에서 가상 환경(Parallels, VMware)으로 구성 하였다면 아래와 같이 가상 환경의 설정을 변경해야 합니다. 만약, Windows Phone Emulator 또는 Android AVD를 구동하려면 가상 환경에서 Hyper-V 사용을 선택해야 합니다. 아래 그림과 같이 "중첩 가상화 사용"에 체크하세요.

0099.png

지금은 해결이 되었는지 확인하진 못했지만, 맥북 프로 레티나에서 가상 환경으로 윈도우를 사용하는 경우, iOS 시뮬레이터가 정상 동작하지 않는 문제가 있습니다. 아래 그림처럼 비디오 메모리를 설정하고, "Retina 해상도 활성화"를 사용하지 않아야 합니다.

99.png

이제 모든 설정을 마쳤으므로 윈도우와 맥을 재부팅하세요.

Visual Studio Community 2015를 실행하고, 새 프로젝트를 선택합니다. Visual C# > iOS > iPhone의 "WebView App (iPhone)" 탬플릿을 선택하고 이름은 MyFirstWebApp으로 지정하고 확인을 클릭하세요.

이미지 003.png



프로젝트가 생성되면 Visual Studio의 도구 > 옵션을 실행하세요. Xamarin > iOS Settings를 선택하고, 아래 그림과 같이 "Find Xamarin Mac Agent"를 클릭합니다.

이미지 004.png



아래 그림의 "Add Mac..."을 클릭합니다.

이미지 005.png



맥의 컴퓨터 이름 또는 아이피를 입력하고 "Add"를 클릭하세요.

이미지 006.png



맥의 계정정보를 입력하고 "Login"을 클릭합니다.

이미지 007.png



아래 그림처럼 맥이 연결됩니다.

이미지 008.png



옵션에 Xamarin Mac Agent가 등록되었습니다.

이미지 009.png



Visual Studio의 상단에 Machine에서 iPhoneSimulator를 선택하세요.

이미지 010.png



에뮬레이터를 선택합니다. 저는 iPhone 6s Plus iOS 9.1을 선택했습니다.

이미지 011.png



만약, 아이폰을 가지고 있고, 맥에 연결되어 있다면 자신의 아이폰에서 테스트 할 수도 있습니다. 자신의 아이폰에서 테스트 하려면 애플 개발자 센터에 등록되어 있어야하고 인증키가 등록되어 있어야 합니다.

이미지 13.png



F5를 눌러서 실행하면 원격으로 연결된 Mac에서 아이폰 에뮬레이터가 실행되고, 윈도우의 Visual Studio 프로젝트가 표시됩니다.

001.png


웹앱은 기본적으로 MVC의 Razor 엔진으로 구성되고, 간단한 모델과 뷰가 포함되어 있습니다.

002.png

안드로이드 가상 환경을 구성하려면 안드로이드용 Visual Studio 에뮬레이터를 설치해야 합니다. 아래 링크를 통해 다운로드 후 설치하세요.

[ 다운로드 ]

이미지 4.png



웹앱 프로젝트를 안드로이드 가상 환경에서 실행한 화면입니다.

이미지 4.png



디자인은 다르지만, iOS와 동작은 같습니다.

이미지 5.png



윈도우폰은 아래처럼 구동됩니다.
이미지 3.png



Android, iOS와 다르게 윈도우폰은 WPF로 되어 있습니다.

이미지 2.png



이렇게 해서 윈도우 환경의 Visual Studio에서 iPhone과 Android, Windows Phone 앱을 개발하기 위한 환경을 구축하는 방법에 대해서 알아보았습니다. 이외에도 여러가지 부가적인 요소가 있지만 기본 구성에 영향을 주지는 않기 때문에 여기에서 다루지는 않았습니다. 사업 영역을 모바일로 확대하려는 회사에서 자마린을 도입했거나, 검토중인 회사들이 많아진듯 보입니다. 솔직히 Objective C와 Android Java를 배워서 개발하는 비용보다 자마린을 도입하는게 더 저렴할수도 있습니다. 그렇더라도 플랫폼에 따른 제약이나 특별한 기능을 구현하기 위해서는 어느정도 각각의 플랫폼에 대한 학습은 병행되어야 합니다. 저도 이제 막 공부를 시작한 입장에서 어떤 방향이 좋다 나쁘다를 말할 처지는 아니구요. 혼자서 모바일 앱을 빠르게 개발하고 배포해야 하기에 자마린을 선택한 것뿐입니다.


개인적인 프로젝트를 진행하면서 틈틈히 관련 내용을 작성할 예정이긴 한데... 항상 시간이 없다는게 문제죠-_-;


다음 시간에...

저작자표시 비영리

델리게이트란 무엇인가?

델리게이트는 사전적 의미로 위임하다라는 뜻입니다. Cocoa Touch에서 델리게이트는 다른 객체를 대신해 특정 작업을 수행하는 클래스를 말합니다. 다시말해 한 오브젝트가 모든 기능을 수행하지 않고, 일부 기능을 다른 객체에게 위임하는 객체 지향 프로그래밍 디자인 패턴을 뜻합니다. 그리고 그 도움을 주는 객체를 델리게이트라고 부릅니다.

Objective-C 프로그래밍에 있어서 델리게이트는 매우 중요한 요소라고 할 수 있습니다. 이 델리게이트가 어플리케이션의 생명주기와도 갚은 연관이 있기 때문인데, 델리게이트가 없다면 생명을 잃어버린 애플리케이션이라고 말 할 수 있습니다.


애플리케이션의 생명주기

어떤 프로그램이든 소스 코드를 통하여 메모리에 적재되고, 실행되는 동안 주어진 역할을 수행하고, 임무를 완수할 경우에는 메모리에서 삭제되는 새명주기 싸이클이 존재합니다. 아이폰의 어플리케이션도 이러한 패턴을 무시할 수 없습니다. 아래의 그림은 아이폰 어플리케이션의 생명주기를 나타낸 것입니다.

어플리케이션의 생명주기는 실행과 종료 사이에 발생하는 순차적인 이벤트들을 만들어냅니다. 사용자는 아이폰의 스크린의 아이콘을 선택하여 어플리케이션을 실행하게 됩니다. 이후에 시스템은 진행상태를 보여주고 어플리케이션의 main함수를 호출합니다. 이때부터 초기화를 위한 작업들이 UIKit으로 넘어오는데, 어플리케이션의 UI를 불러오고 이벤트 루프를 준비하는 작업들이 포함됩니다. 이벤트 루프 과정에서 UIKit은 커스텀 객체로의 이벤트 전달과 어플리케이션에서 발생한 명령들을 처리하는 것을 조절하게 됩니다. 사용자가 프로그램을 종료하는 이벤트를 발생하면, UIKit을 통해서 어플리케이션에 종료명령을 발생하고 종료가 진행됩니다.


어플리케이션 델리게이트

어플리케이션 델리게이트(Application Delegate) 객체의 역할은 어플리케이션의 동작을 모니터링 하는 것입니다. 변수의 경우, 각 변수가 가지고 있는 값들을 어떤 특정한 패턴, 함수에 의해 변형되어, 개발자의 의도대로 결과 값을 얻을 수 있습니다. 이런 특징적인 역할을 하는 함수(모듈, 객체, 메소드 등)들을 특정한 조건이나 의도를 가지고 묶음으로 만들어내어 보다 간편하게 사용하도록 하는 것이 델리게이트를 사용하는 목적이라고 할 수 있습니다. 또 한가지 델리게이트를 사용하는 이유는 UIApplication과 같은 복잡한 객체를 상속하는 것을 피하고, 메소드를 재정의 하지 않음으로써 보다 객체지향적인 프로그래밍을 할 수 있도록 도와주게 됩니다. 아래의 그림은 객체가 델리게이트를 통해 특정 액션을 실행하는 과정을 표현한 것 입니다.


어플리케이션이 어떤한 액션을 만

저작자표시 비영리
alloc_text auto_inline bss_seg check_stack
code_seg comment component conform
const_seg data_seg deprecated function
hdrstop include_alias init_seg inline_depth
inline_recursion intrinsic managed message
once optimize pack pointers_to_members
pop_macro push_macro runtime_checks section
setlocale unmanaged vtordisp warning

 

#pragma 다음에 올수 있는  텍스트 구문

 

 

#pragma comment 다음에 올수 있는 문구는 다음과 같다.

compiler 
exestr
lib
linker /DEFAULTLIB 
linker /EXPORT 
linker /INCLUDE 
linker /MERGE 
linker /SECTION 
linker /ENTRY
user

 

사용예
#pragma comment( user, "Compiled on " __DATE__ " at " __TIME__ )

 

 

linker의 경우에 다음에 올수 있는 항목이다.

/ALIGN Specifies the alignment of each section. 

/ALLOWBIND Specifies that a .dll cannot be bound. 

/BASE Sets a base address for the program. 

/DEBUG Creates debugging information. 

/DEBUGTYPE Creates particular formats of debugging information. 

/DEF Passes a module-definition (.def) file to the linker. 

/DEFAULTLIB Searches specified library when resolving external references. 

/DELAY Controls the delayed loading of DLLs. 

/DELAYLOAD Causes the delayed loading of the specified DLL. 

/DLL Builds a DLL. 

/DRIVER Creates a Windows NT kernel mode driver. 

/ENTRY Sets the starting address. 

/EXETYPE Builds a virtual device driver. 

/EXPORT Exports a function. 

/FIXED Creates a program that can be loaded only at its preferred base address. 

/FORCE Forces link to complete in spite of unresolved or multiply defined symbols. 

/GPSIZE Specifies the size of communal variables for MIPS platforms. 

/HEAP Sets the size of the heap in bytes. 

/IMPLIB Overrides the default import library name. 

/INCLUDE Forces symbol references. 

/LARGEADDRESSAWARE Tells the compiler that the application supports addresses larger than two gigabytes. 

/LIBPATH Allows the user to override the environmental library path. 

/LINK50COMPAT Generates import libraries in eMbedded Visual C++ Version 5.0 format. 

/MACHINE Specifies the target platform. 

/MAP Creates a map file. 

/MAPINFO Includes the specified information in the map file. 

/MERGE Combines sections. 

/NODEFAULTLIB Ignores all (or specified) default libraries when resolving external references. 

/NOENTRY Creates a resource-only DLL. 

/NOLOGO Suppresses startup banner. 

/OPT Controls LINK optimizations. 

/ORDER Places COMDATs into the image in a predetermined order. 

/OUT Specifies the output file name. 

/PDB Creates a program database (.pdb) file. 

/PDBSTRIPPED Do not place private symbols in the database (.pdb) file. 

/PDBTYPE Specifies where to store the Program Database (PDB) debug type information. 

/RELEASE Sets the checksum in the .exe header. 

/SECTION Overrides the attributes of a section. 

/STACK Sets the size of the stack in bytes. 

/STUB Attaches an MS-DOS stub program to a Win32 program. 

/SUBSYSTEM Tells the operating system how to run the .exe file. 

/SWAPRUN Tells the operating system to copy the linker output to a swap file before running it. 

/VERBOSE Prints linker progress messages. 

/VERSION Assigns a version number. 

/VXD Creates a virtual device driver (VxD). 

/WARN Specifies warning level. 

/WINDOWSCE Specifies bitmap conversion. 

/WS Aggressively trim process memory.

저작자표시 비영리

#pragma는

- 각각의 컴파일마다 독립적인 기능을 제공하기 위하여 이용(다른 컴파일에서는 처리 안 될 수 있음)
- VC++에서는 많은 pragma directives가 있음(alloc_text, auto_inline, bss_seg, check_stack, code_seg, comment, component, conform, const_seg, data_seg, deprecated, function, hdrstop, include_alias, init_seg, inline_depth, inline_recursion, intrinsic, managed, message, once, optimize, pack, pointers_to_members, pop_macro, push_macro, runtime_checks, section, setlocale, unmanaged, vtordisp, warning)
- 정의 안 된 pragma directives를 사용하면 단순히 경고(warning C4068: unknown pragma)만 output 창에 출력하고, 무시됨
- 많이 사용하는 것 몇 가지만 앞으로 살펴볼 것임
- 이번시간에는 once, warning

1.#pragma once
이는 중복 include하는 것을 막는 것이다.
만일 중복 include가 되면, error C2011: 'CA' : 'class' type redefinition

#ifndef _A_H_
#define _A_H_
class CA {
...
}
#endif
와 

#pragma once
class CA {
...
}
는 동일한 것이다.

VC++에서 자동으로 class를 만들면 
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
라는 코드가 삽입되어 있는데, 이는 #pragma once가 VC++버전이 1000이상인 곳에서만 의미가 있기 때문이다.(Visual C++ 5.0 => 1100, Visual C++ 6.0 => 1200, Visual C++ .NET 2003 => 1310, Visual C++ 2005 => 1400)

2.#pragma warning(disable : 4244; once : 4101; error : 4700)
소스를 컴파일하면 error와 warning이 나타나는데, warning의 경고수준을 결정하는 것임
거의 쓸 일은 없지만, 재미로 한번 살펴보기만 하자.

void main() {
    double f;
    int k1, k2;
    int n=f;
}
이를 컴파일하면 output창에 아래의 warning이 나타난다.
warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
warning C4101: 'k1' : unreferenced local variable
warning C4101: 'k2' : unreferenced local variable
warning C4700: local variable 'f' used without having been initialized
0 error(s), 4 warning(s)

이때 disable은 해당 warning이 output창에 나오지 않도록 무시하라는 지정
once는 동일한 warning에 대해 한번만 나오라는 것
error는 해당 warning을 error로 취급하라는 것이다.

#pragma warning(disable: 4244)
#pragma warning(once: 4101)
#pragma warning(error: 4700)
void main() {
    double f;
    int k1, k2;
    int n=f;
}
을 컴파일하면
warning C4101: 'k1' : unreferenced local variable
error C4700: local variable 'f' used without having been initialized
1 error(s), 1 warning(s)
가 나오는 것을 알 수 있다.

하지만 warning을 소홀히 하는 것은 매우 좋지 않은 습관이다. 
warning도 꼭꼭 해결하고 넘어가도록 하자. 
void main() {
    double f=0.;
    int n=(int)f;
} 


저작자표시 비영리

+ Recent posts

티스토리툴바