- 소프트웨어 개발순서

컨스트럭션 : 세부셜계, 코딩/디버깅, 단위테스트

소프트웨어 개발

1. 문제 정의
2. 요구 분석
3. 구현 계획
4. 기본 설계 (아키텍처)
* 주요 결정에 대한 동기 기술할 것

    프로그램 구조 (주요모듈)
    변경전략
    구입 對 개발 결정
    주요 데이터 구조
    키 알고리즘
    주요 객체
    일반적 가능성 (사용자 인터페이스, 입력/출력, 메모리관리, 문자열 기억장소)
    에러처리
    견고성 (오버 엔지니어링, Assertion, 오류방지 능력)
    성능

5. 상세 설계
6. 코딩/디버깅
7. 통합
8. 단위 테스트
9. 시스템 테스트
10. 유지보수
11. 기능강화


설계순서
    1. 서브시스템 분할
    2. 모듈로 분할
    3. 루틴으로 분할
    4. 내부루틴 설계


------------------------------------------
Code Complete , Steve McConnell저
Microsoft press 1995

프로그래밍 완전정복 김준호, 나윤석, 배상수 공역
높이깊이 1997
------------------------------------------ 





Posted by linuxism
,

객체 지향 분석/설계용의 모델링 언어. 기존의 객체 지향 방법론과 함께 제안되어 모델링 언어 표기법의 표준화를 목적으로 한 것이다. 주로 미국의 래셔널 소프트웨어(Rational Software)사에서 방법론의 통일과 표준화 작업에 전념한 결과 1997년 11월에 UML 1.1이 객체 관리 그룹(OMG)에 의해 표준으로 채택되었다. UML은 방법론이 아닌 소프트웨어 개발에 사용되는 다이어그램을 정의하는 것으로, 소프트웨어 개발 시 산출물들을 비주얼하게 제공함으로써 개발자와 고객 또는 개발자 상호 간의 의사 소통을 원활하게 할 수 있으며, 산업계 표준으로 채택되었기 때문에 UML을 적용한 시스템은 신뢰성이 있다 



UML (Unified Modeling Language, 통합 모델링 언어) 는 시스템을 시각화하거나 시스템의 사양이나 설계를 문서화하기 위한 표현방법입니다. UML은 주로 객체 지향 프로그램의 구조를 나타내는데 사용되며, 클래스 다이어그램 (Class Diagram), 시퀀스 다이어그램 (Sequence Diagram) 등이 존재합니다.

1. 클래스 다이어그램

클래스 다이어그램은 클래스나 인스턴스, 인터페이스 등의 정적인 관계를 표현합니다.  

<클래스 다이어그램의 예>

 
각각의 클래스는 위 그림과 같이 표현할 수 있으며, 표현하는데 필요한 몇 가지 기호들이 존재합니다.

<클래스의 표현>


클래스는 직사각형으로 표현합니다. 직사각형은 수평선으로 세개의 칸으로 분할됩니다. 첫번째 칸에는 클래스의 이름두번째 칸에는 필드의 이름을 쓰고 마지막 세번째 칸에는 메소드의 이름을 적습니다.

각각의 칸에는 이름 뿐 아니라 부가적인 정보를 적기도 합니다.

추상 클래스와 추상 메소드의 경우에는 이탤릭체를 사용합니다. static 필드와 static 메소드의 경우에는 밑줄을 사용합니다.

<상속 표현>


클래스간의 상속은 실선 화살표를 이용해 표시합니다. 화살표의 방향은 자식 클래스에서 부모 클래스로 향합니다.

<인터페이스, 집약의 표현>

 
점선 화살표는 인터페이스의 구현을 의미합니다. 화살표의 방향은 구현 클래스에서 인터페이스 방향으로 향합니다. 인터페이스를 표현하는 경우 <<interface>>와 같이 표현합니다.

마름모가 붙은 선은 집약 (aggregation) 을 의미합니다. 인스턴스를 갖고 있는 경우에는 두 클래스간의 관계는 집약입니다.

클래스 다이어그램에서 엑세스를 표현할 수도 있습니다.
  • +가 붙은 경우 : public
  • -가 붙은 경우 : private
  • #이 붙은 경우 : protect
  • ~이 붙은 경우 : 동일한 패키지 내에서만 사용할 수 있습니다.

2. 시퀀스 다이어그램

<시퀀스 다이어그램>


시퀀스 다이어그램은 프로그램이 작동될 때 어떤 순서로 실행되는지를 나타냅니다.

시퀀스 다이어그램의 가장 위에 있는 직사각형 안에는 인스턴스의 이름이 들어갑니다. 콜론 (:) 뒤에는 클래스의 이름을 표기하고 그 앞에는 인스턴스의 이름을 표기합니다. 만약 인스턴스의 이름을 따로 표기할 필요가 없을 경우에는 표기하지 않아도 상관없습니다.

인스턴스에서 아래로 뻗어있는 점선은 라이프 라인 (Life Line) 입니다. 시퀀스 다이어그램에서 시간은 위에서 아래 방향으로 흐릅니다. 라이프 라인 중간의 직사각형은 객체가 활동중임을 의미합니다.

각 객체 사이의 실선 화살표는 메소드의 호출점선 화살표는 메소드에서 리턴되었음을 의미합니다.


출처 - http://mutablearray.tistory.com/222

==============================================================================================

통합 모델링 언어(UML, 영어: Unified Modeling Language)는 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어이다. 이 표준은 UML을 고안한 객체 관리 그룹에서 관리하고 있다.

UML은 소프트웨어 집약 시스템의 시각적 모델을 만들기 위한 도안 표기법을 포함한다.

목차

  [숨기기

[편집]개요

통합 모델링 언어는 객체 지향 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용한다.[1] UML은 아래와 같은 사항을 포함하여 시스템의 구조적 청사진을 시각화 하는 표준안을 제공한다:

UML은 데이터 모델링(개체-관계 다이어그램)과 비즈니스 모델링(업무 흐름), 객체 모델링, 부품 모델링의 최선의 기술을 조합한다. UML은소프트웨어 개발 공정뿐만 아니라 다른 구현 기술의 모든 공정에서 사용될 수 있다. UML은 Booch 방법론의 객체 모델링 기법(OMT)와 객체 지향 소프트웨어 공학(OOSE)을 광범위하게 사용할 수 있는 단일한 공통 모델링 언어로 통합한다. UML의 목표는 동시적 분산 시스템을 모델링 하는 표준 언어다. UML은 산업의 실질적 표준으로서, 객체 관리 그룹(OMG)에 의해 개선되고 있다. 초기에 OMG가 엄격한 소프트웨어 모델링 언어를 만들기 위해 객체 지향 방법론적인 통지를 요청했고, 많은 산업 선구자가 UML 표준 제작을 돕기위해 진지하게 응답하였다.[1]

UML 모델은 객체 관리 그룹이 지원하는 QVT와 같은 변환 언어 등을 이용해 다른 표현(예를 들면 자바)으로 자동적으로 변환된다. UML은 확장할 수 있으며 커스터마이제이션을 위한 메커니즘인 프로파일 (UML)스테레오타입 (UML)을 제공한다. 프로파일을 이용한 확장의 의미는 UML 2.0에서 개선되었다.

[편집]역사

UML은 그래디 부치(Grady Booch)제임스 럼버(James Rumbaugh)이바 야콥슨(Ivar Jacobson)의 머리에서 태어났다. 최근 “쓰리 아미고(Three Amigos-3인방)”이라고 불리는 이 세 사람은 80년대 전반 부터 90년대 초반까지 객체지향 분석 설계 분야에서 각자의 영역에서 방법론을 연구해 왔었다. 그들이 발표한 방법론은 동일한 분야의 다른 경쟁자들보다 항상 탁월한 위치에 있었으며, 세 사람은 90년대 중반에 이르러 각자의 아이디어를 교환하기 시작하였고, 결국 각자의 방법을 하나로 모아 합치기에 이른다.

1994년, 럼버는 부치가 세운 래셔널 소프트웨어(Rational Software Corporation)에 영입 되었고, 야콥슨은 그로부터 1년 후에 래셔널 사에 들어가게 된다.

나머지는 그들이 말하듯이, 역사(History)라고 말할 수 있다. UML의 초안(draft) 버전은 소프트웨어 업계를 뒤흔들기 시작했고, 그 결과로 돌아온 피드백은 바로 변경점에 반영되었다. “UML은 우리들의 전략에 딱 맞는다”라고 인식해 가는 회사가 늘어남에 따라 그 결과로 UML 컨소시엄도 발족하게 되었다. UML 컨소시엄의 멤버로는 디지털(DEC)휴렛-팩커드(Hewlett-Packard)인텔리캅(Intellicorp)마이크로소프트(Microsoft)오라클(Oracle)텍사스 인스트루먼트(Texas Instruments), 래셔널 소프트웨어 등이 있었다. 1997년 UML 컨소시엄은 UML 버전 1.0을 만들어 내었고, 오브젝트 매니지먼트 그룹(OMG:Object Management Group)이 표준 모델링 언어의 제안서를 내라는 요구에 맞추어 이것을 제출 하였다.

UML 컨소시엄은 계속 발전하였으며, OMG에 다시 상정된 UML 1.1d은 1997년 말에 표준 모델링 언어로 채택되었다. OMG는 UML의 관리 기법을 받아들여 1998년에 새로운 수정안을 발표하였다. UML은 소프트 웨어의 업계 명실 상부한 표준이 되었으며, 계속 수정 보안되고 있다. 버전 1.3과 1.4 그리고 1.5가 나와 있고, 최근에는 버전 2.0이 OMG에 의해 승인된 상태이다. 이전 버전들, 즉 버전 1.X는 현존하는 대부분의 모델 및 UML 모델링 책의 기본이 되어 왔다.[3]

[편집]UML 구성요소

[편집]소프트웨어 개발 방법론

UML 그 자체는 개발 방법이 아니지만[4] 그 당시 주도적이었던 객체 지향 소프트웨어 개발 방법론(예를 들면 Booch 방법론객체 모델링 기법Objectory)과 잘 어울리도록 설계되었다. UML 발전해 감에 따라서 UML의 장점을 취하기 위해 몇몇 다른 방법론(예를 들면 객체 모델링 기법)이 개선되었다. 또 UML을 기반으로 한 새 방법론이 만들어지기도 했는데 IBM 래셔널 통합 프로세스(RUP)가 가장 유명하다. 이 외에도 추상 방법론(Abstraction Method), 동적 시스템 개발 방법론 등 더 특수한 해결책이나 다른 목적을 달성하기 위해 설계된 UML 기반의 방법론이 많이 있다.

[편집]모델

모델은 이학 및 공학 분야에서 상당히 유용하게 쓰이는 개념으로서 가장 일반적인 의미로 말하면, "모델은 만들다"는 것은 잘 모르고 있는 것을 이해하는데 도움이 될 것으로 추측되는 어떤 것을 사용한다는 뜻이다. 어떤 분야에서는 이 모델의 일련의 수식(방정식)의 집합으로 정의되기도 하며, 다른 분야에서는 컴퓨터 시뮬레이션을 모델로 삼기도 한다.

UML의 여러가지 그래픽 요소는 하나의 큰 그림, 즉 다이어그램을 그리는데 사용된다. UML은 언어이기 때문에, 이들 그래픽 요소들을 맞추는 데에는 규칙이 필요하다. 다이어그램의 목적은 시스템을 여러가지 시각에서 볼 수 있는 뷰(View)를 제공하는 것이며, 이러한 뷰의 집합을 모델(Model)이라고 한다. 시스템의 UML 모델은 건물을 짓는 건축가의 스케일 모델과도 비슷하다고 말할 수 있다. UML 모델은 시스템 자체의 “목적 행동”을 설명하는 언어이다. UML 모델은 시스템의 “구현 방법을 설명하는 수단”이 아니다.

[편집]클래스 다이어그램

대부분의 사물은 자기만의 속성과 일정한 행동 수단을 지니고 있다. 이러한 행동을 오퍼레이션(Operation)의 집합으로 생각할 수 있다. UML에서는 두단어 이상으로 이루어진 클래스 이름은 단어 사이의 공백을 없애고, 각 단어의 처음 문자를 모두 대문자로 한다(예:Wikipedia). 속성과 행동의 이름 또한 마찬가지이지만, 가장 앞 단어의 처음 문자는 소문자로 한다(예:edit()).

[편집]비판

[편집]같이 보기

Umbrello UML Modeller 스크린샷.

============================================================================================

통합 모델링 언어 (통합 모델링 언어 UML , 영어 : Unified Modeling Language)은 소프트웨어 공학 의 객체 모델링 을 위해 표준화 했다 명세 언어 이며, 그래픽 기술로 추상화 하여 시스템 의 모델 (UML 모델) 생성하는 일반 모델링 언어 이다.

최초 기의 버전은 합리적 에서 그라 디 · 부찌 , 이바노 야콥손 , 제임스 람보 3 명이 책정했다. 이 3 명은 쓰리 아미고스 라고있다. 현재 OMG(Object Management Group)가 관리하고있다. 소프트웨어 개발에서 소프트웨어를 이용하는 범용 모델링 언어로서 현재 가장 많이 보급되어있다. 2008 년 현재 최신 버전은 UML 2.1.1이며, ISO / IEC 19501:2005으로 UML 1.4을 표준화하고있다.

UML 2.0 이상에서는 13 종류의 그림 (다이어그램)을 필요에 따라書き分ける. 자주 사용하는 그림으로, 상태 다이어그램 시퀀스 다이어그램이있다. 특정 언어로 개발이 결정된 시점에서 클래스 다이어그램 과 유스 케이스 다이어그램 을 사용하는 경우가있다.

UML 2.0 다이어그램 체계 ( 클래스 다이어그램 으로 표현)

목차

  [ 숨기기 ] 

개요 편집 ]

UML의 공식적인 정의는 Object Management Group (OMG)이 Meta-Object Facility (MOF)의 메타 모델을 사용하고있다. 다른 MOF 기반의 사양뿐만 아니라 UML 메타 모델과 UML 모델은 XMI 로 직렬화있다. UML은 소프트웨어 를 중심으로하는 시스템의 사양을 작성하고, 구상하고, 구축하고 문서화하기 위해 설계되었다.

UML은 소프트웨어 모델링뿐만 이용하는 것은 아니다. 비즈니스 프로세스 모델링 및 시스템 공학 모델링에 사용되고, 조직의 구조도를 표현하는데도 사용할 수있다. Systems Modeling Language (SysML)은 UML 2.0 프로파일로 정의된 시스템 공학을위한 도메인 특정 모델링 언어이다.

UML은 모델 기반 설계 (MDE) 및 모델 기반 아키텍처 (MDA) 같은 모델 기반의 기술이 발전하는 계기가되었다. 클래스, 구성 요소 일반화 집계 같은 개념의 시각적 표기법에 대해 업계의 합의를 얻게 된 것으로, 소프트웨어 개발자는 설계 및 구조 (아키텍처)에 집중할 수있게되었다.

UML 모델은 OMG 가 해당 QVT 같은 변환 언어를 사용하여 다른 표현 ( Java )에 자동으로 변환할 수있는 경우가있다.

UML은 확장성이 있고 프로파일과 스테레오 타입과 같은기구로 지정있다. 프로토 타입의 확장 의미론 은 UML 2.0에서 개선하고있다.

역사 편집 ]

1994 년 합리 은 제너럴 일렉트릭 에서 제임스 람보 를 고용했다. 그 회사는 오늘 두 객체 지향 모델링 기법을 창출하게되었다. 그것은 랭보의 객체 모델링 기법 ( 객체 지향 분석 (OOA)의 일종)와 그라 디 · 부찌 의 Booch 법 ( 객체 지향 설계 (OOD)의 일종)이다. 랭보와 부찌 공동으로 그들의 기술을 통합하는 작업을 시작했다.

곧 이바노 야콥손 이 더해졌다. 객체 지향 소프트웨어 공학 (OOSE)의 개발자이다. 야콥손는 1995 년 자신의 회사인 Objectory AB 가 인수함으로써 합리에 합류했다. 이 3 명의 방법 주의자를 쓰리 아미고스 라고 부른다.

1996 년 합리적인 너무 다양한 모델링 언어가 존재하고 있다고 객체 기술의 채용이 지연될 것으로 판단하고 그들의 통합 작업을 개방형 통합 모델링 언어 개발에 방향 전환했다. OOPSLA '96에서 객체 기술 설계 경쟁 업체가 모여 이에 관한 토론이 진행되며 람보 OMT 표기법으로 사용되고 있던 사각형 클래스를 나타내는 기법이 부찌 구름 클래스를 나타내는 기법을 이겼다. 이 승리를 기념하여 람보가 조니 미첼 의 "Clouds"를 아카펠라 로 불렀다는 필요 출처 ] .

쓰리 아미고스 기술 지도력하에 UML Partners는 국제 컨소시엄이 1996 년에 결성되어 통합 모델링 언어 (Unified Modeling Language, UML) 사양이 완성되고, OMG RFP에 대한 응답으로 제안되었다. UML Partners의 UML 1.0 스펙 초안이 OMG에 제시된 것은 1997 년 1 월이었다.같은 달 UML Partners는 Semantics Task Force를 결성 사양의 의미 론적 측면의 마무리와 다른 표준화 작업과의 정합 작업을했다. 그 결과는 UML 1.1로 OMG 1997 년 8 월에 제출되어 1997 년 11 월 채택되었다 [1] .

모델링 기법으로는 OMT 기법이 거의 답습되었다 (예를 들어, 클래스와 객체를 구형으로 나타내는 등). 부찌의 "구름"문법은 제외되었지만, 부찌 법에 특유한 저수준 설계 세부 정보를 설명하는 기능이 채용되고있다. 야콥손의 Objectory 에서 유스 케이스 다이어그램 이 채용되어 부찌의 구성 요소 그림 도 채용되었다. 하지만 의미 론적 통합이라는 관점에서 UML 1.1은 약하고, 그 점이 크게 개선된 것은 UML 2.0였다.

다른 객체 지향 기술의 개념을 UML 완만하게 통합하여 거의 모든 객체 지향 기법에 대응하는 것으로되어있다. 예를 들어, CRC 카드 (1989 년경, 켄트 벡 과 워드 커닝햄 이 고안) 및 Object Oriented Role Analysis Method (OORam)이 고려되고있다. 이외에도 당시의 다양한 객체 지향 기법이 기여하고있다. Tony Wasserman과 Peter Pircher의 "Object-Oriented Structured Design (OOSD)"기법, Ray Buhr의 "Systems Design with Ada"Archie Bowen 사례 및 타이밍 분석, Paul Ward 데이터 분석, David Harel의 "Statecharts"등 이다. 이 때, 그들은 실시간 시스템 영역을 커버하기 위하여려고하고 있었다. 결과적으로 UML은 단일 프로세스 응용 프로그램에서 분산 시스템에 이르기까지 다양한 공학적인 문제에 사용할 수있는 도구가 거대한 사양을 안게되었다.

통합 모델링 언어는 국제 표준 규격 이다. ISO / IEC 19501:2005 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2로 규격화하고있다.

UML은 UML 1.1 이후에도 계속 진화하고있다. 몇 가지 사소한 버전 (UML 1.3, 1.4, 1.5) 버그 및 문제점을 수정한 것이지만, UML 2.0에서 크게 진화했다. 이것이 현재의 OMG 표준이다.

UML 2.0의 첫 번째 부분은 새 다이어그램 및 모델링 요소를 설명했다 고차 구조 (슈퍼 구조)이며, 2004 년 10 월 OMG가 채택했다. 다른 부분은 인프라라고, Object Constraint Language (OCL)와 그림의 관계를 나타낸 것이며, 순차적으로 채용되어 2005 년 11 월에 완성했다.UML 2.0 specification 최종 버전이 사용 가능하다고 선언, OMG의 형식 사양 라이브러리에 추가되고있다. UML 사양의 다른 부분으로UML 2.0 infrastructure , UML 2.0 Diagram Interchange , UML 2.0 OCL 을 채용하고있다.

2007 년 8 월 현재 버전은 2.1.1, UML 2.1 버전의 XMI 2.1 버전의 형태로 사용 가능하다. 그 XMI 2.1 파일은 OMG에서 구할 수있다. 2.2 버전은 현재 개발 중.

잘 알려진 UML 도구의 대부분은 UML 2.0의 대부분을 지원하고있다. 일부 그다지 사용되지 않는 기능을 구현하지 않을 수있다.

방법론 편집 ]

UML 자체는 방법 (방법론) 대신 당시 주류였던 객체 지향 소프트웨어 개발 방법론 군 ( OMT , Booch 법 , OOSE / Objectory )와 호환되도록 설계하고있다. 다음 UML이 보급됨에 따라 그 기술을 새로운 그림을 이용하도록 변경하고있다. 또한 UML 기반의 새로운 수법도 등장하고있다. 잘 알려진 예로는 합리적인 통합 프로세스 (RUP)가있다. 이외에도 Abstraction Method, DSDM 등이 있으며, 각각 다른 목적을 전문하는 경향이있다.

UML 다이어그램 편집 ]

UML 다이어그램은 시스템의 정적인 구조를 나타내는 구조도 및 시스템 동작을 나타내는 동작 ​​그림 으로 분류된다. 동작 다이어그램에서 개체 간의 메시지 교환에 주목한 것을 특히 상호 작용 다이어그램 이라고 부른다.

구조도 편집 ]

KP-UML-Generalization-20060325.svg

KP-UML-Aggregation-20060325.svg

클래스 다이어그램 에 따르면일반화 관계 및 one to many 연관 (복합성)의 표현

구조 다이어그램은 시스템의 정적 구조를 모델로 표현한다.

클래스 다이어그램
시스템을 구성하는 클래스 (개념)과 그들 사이에 존재하는 관련 구조를 표현한다. 사용자 관점에서 시스템을 구성하는 물건이나 개념을 나타낸다.
복합 구조 다이어그램
컴포넌트 다이어그램
물리적 구성 요소 ( 파일 , 헤더, 라이브러리 , 모듈 실행 파일이나 패키지 등) 시스템의 구조를 표현한다.
배치도
하드웨어와 응용 프로그램의 관계를 나타낸 것.
객체 다이어그램
클래스를 구체화하여 생성된 개체 간의 관계를 표현한다.
패키지 다이어그램
패키지 간의 의존 관계를 그리는 방식으로 논리적 그룹핑을위한 다이어그램에서 클래스 다이어그램의 일부이다. 패키지는 관례적으로 디렉터리 구조과 같이 나타낼 수있다. 패키지 그림은 시스템을 논리적인 계층 구조로 분해하는 데 도움이된다.

동작 그림 편집 ]

상태 차트 예제

동작 그림은 시스템의 동작을 모델로 표현한다.

활동 다이어그램
시스템과 같은 흐름을 기술하는 표기법 순서도의 일종이다. UML에서는 표기 흐름은 확인되지 않으며 사용자 측에 가까운 업무 흐름이나 완성에 가까운 함수의 흐름을 보여줄 수있다.
유스 케이스 다이어그램
시스템에 요구되는 기능을 사용자의 관점에서 보여줍니다. 유스 케이스 다이어그램을 활용하여 시스템의 전체 상을 개발자와 사용자가 함께 평가되기 쉽다. 이것은 완성된 시스템이 사용자의 요구에 맞지 않는다는 문제를 완화할 수있다.
상태 차트 ( 상태 다이어그램 , 스테이트 머신 다이어그램, 상태 기계 그림)
한 객체의 상태 (상태)에 착안하여 그 변화를 표현한 것.

상호 작용 다이어그램 편집 ]

상호 작용 다이어그램은 동작 그림의 일종이며, 객체 사이의 데이터 (메시지)를 전달 모델.

시퀀스 다이어그램
객체 간의 메시지 흐름을 시계열 로 나타낸다. 그림 속에 시간의 흐름이 존재하기 때문에 이벤트 발생 순서와 개체 사이의 생존 시간을 기술할 수있다.
통신 다이어그램 ( 공동 작업 그림 )
객체 간의 메시지 교환을 보여준다. 시퀀스 다이어그램은 달리 개체를 중심으로 기술한다.
UML2.x에서 일부 표기 변경과 함께 협업 다이어그램 에서 통신 다이어그램 로 명칭이 변경되었다.
상호 작용 개요도
타이밍 다이어그램

비판 편집 ]

UML은 모델링 표준으로 널리 알려져 사용되고 있지만, 다음과 같은 문제점을 잘 지적된다.

  • 언어 비대 . UML은 불필요하게 커질 복잡 해지고 있다고 비판하는 경우가 많다 [2] . 많은 그림과 구성 요소로 이루어져있어 일부는 거의 사용되지 않고, 게다가 중복이다. 특히 UML 2.0이되고 나서위원회적인 해결책이 많아진 것으로, 이러한 비판이 늘고있다.
  • 학습 및 채용에 관한 문제 . 에 대한 비판도 관계하지만, UML 학습과 채용은 어려워지고있다 [3] .
  • 코드와 동기화 문제 . UML 모델링 자체의 아름다움보다 실제로 실행하는 시스템의 모델이 아니면한다. Jack Reeves 이것을 간결하게 "코드는 디자인이다"라고 나타내고있다 [4] . 이 개념을 추진, 소프트웨어 작성의 개선이 필요로하는 것이다. UML은 거기에서 소스 코드 및 실행 코드를 생성하는 도구도있다. 하지만 UML 2.0의 Action Semantics가 튜링 완전 여부는 분명하지 않기 때문에 충분하다고는 말할 수 없다.
  • 임피던스 부정합 . UML 다른 표기법과 비교해도 간결하고 효율적으로 시스템을 표현할 수있다. 따라서 개발자는 UML과 프로그래밍 언어 모두로 기술 가능한 솔루션을 중시하는 경향이 생긴다. 그러나 언어가 정통 객체 지향 언어가 아닌 경우, UML과 언어 사이에 공통점이 적기 때문에이 문제가 특히 커진다.
  • 외형의 일관성 느낌 . 임기응변으로 다양한 그림이 통합되어 있기 때문에 일관성이 없다는 비판도있다.
  • 팔방 미인 . UML은 범용 모델링 언어이며 다양한 구현 언어와 호환성을 달성하려고하고있다. 개별 프로젝트는 목표 달성을위한 설계 팀이 UML 사용 가능한 기능을 구별할 필요가있다. 한층 더 말하면, UML의 범위를 특정 영역으로 제한하는 방법은 완전히 공식화되지 않고, 그것도 비판의 대상이되고있다.

버트런드 메이어 와 에드워드 요돈 가 American Programmer 잡지에 쓴 'UML : The Positive Spin'라는 기사는 UML을 패러디 형식 (UML을 테마로 그 장점을 써야하지 않는 학생들이 쓴 논문이라는 모양)에서 엄격하게 비판이다. Eiffel Software 아카이브 사이트의 [2] .

관련 항목 편집 ]

각주 편집 ]

도움말 ]
  1. UML Specification v 1.1 (OMG document ad/97-08-11)
  2. b Bertrand Meyer : UML : The Positive Spin , in American Programmer , 1997.
  3. ACM 기사 "Death by UML Fever" 는 이러한 종류의 문제를 논하고있다.
  4. The Code is The Design Slashdot Code as Design : Three Essays by Jack W. Reeves

참고 문헌 편집 ]

외부 링크 편집 ]

UML 도구 편집 ]




 


'Development > UML' 카테고리의 다른 글

이클립스 UML 종류  (0) 2012.03.12
UML의 기초  (0) 2012.03.12
UML은 무엇을 위해 있는 것일까?  (0) 2012.03.07
StarUML 소개2  (1) 2010.12.07
StarUML 소개1  (0) 2010.12.07
Posted by linuxism
,

Font(글꼴)

Development/Common 2012. 3. 6. 12:19

폰트는 인쇄하거나 또는 화면에 보여질 수 있도록 특별한 스타일과 크기로 되어 있는 서식 문자들을 말한다. 폰트의 유형별 디자인은 디자인 서체들이 변화되어진 것이다. 따라서 "헬베티카"라고 하면 서체군(群)을 의미하며 "헬베티카 이탤릭"은 하나의 서체를, 그리고 "헬베티카 이탤릭 10 포인트"라고 하면 비로소 그게 바로 하나의 "폰트"을 의미하는 것이다. 그렇지만, 실제로 "폰트"라는 용어와 "서체"라는 용어에 대해 그렇게까지 엄격하게 의미를 따지지 않고, 가끔은 서로 혼용해서 사용하는 경우도 있다.

외곽선 폰트는 다양한 크기로 만들어질 수 있는 소프트웨어 서체이며, 비트맵 폰트는 이미 크기가 고정되어 있거나 크기가 제한된 폰트를 디지털 방식으로 표시하는 것을 말한다. 요즈음 컴퓨터에서 가장 보편적으로 쓰이고 있는 외곽선 폰트로는 "트루타입"과 "어도비 Type 1"을 들 수 있다. 트루타입 폰트는 윈도우와 매킨토시 운영체계에 모두 쓰인다. 그러나 "Type 1"은 ISO 9541에 규정되어 있는 표준 외곽선 폰트이다. 트루타입과 Type 1 폰트 모두 어도비의 포스트스크립트 프린터에서 사용될 수 있다. 독자적인 개발자들과 그래픽 디자이너들은 계속해서 트루타입과 Type 1을 위한 새로운 서체를 만들어 내고 있다. 어도비사의 말에 따르면 이미 3만 개가 넘는 Type 1 폰트가 존재한다고 한다.

대개 윈도우95나 윈도우98과 같은 운영체계나 또는 마이크로소프트 오피스 같은 제품을 설치하면 기본적으로 딸려오는 폰트들이 있지만, 이외에 더 다양한 폰트를 사용하려면 개별적으로 서체군이나 서체 모음집을 구입한 다음, 자신의 PC에 추가로 설치하여야 한다.

출처 - terms.co.kr


① 활자꼴을 기록, 표시, 인쇄 등의 구체적인 표현에 이용될 수 있도록, 같은 크기의 글자의 형상 표현의 집합으로서 기억 모체에 기록한 정보. 원래 이 말은 영문자 인쇄를 위한 알파벳숫자기호 등의 같은 활자꼴, 같은 크기의 활자 한 벌을 ‘폰트’ 라고 하였다. 곧 폰트는 활자꼴을 구체적인 기록, 표시, 인쇄에 이용할 수 있도록 한 것으로, 그 활자꼴의 정보 형태에 따라 사진식자판 등의 아날로그 폰트와 점이나 윤곽선 등의 디지털 데이터로 된 디지털 폰트로 나뉘나, 오늘날에는 주로 디지털 폰트를 가리키는 의미로 쓰이고 있다. 이 말은 본래 ‘foundry(활자주조소)’ 의 ‘found(녹이다. 주조하다)’ 에서 유래되었다.

② 컴퓨터를 통해 모니터나 프린터 등의 출력장치에 출력되는 글자의 모양. 혹은 미리 디자인된 여러 가지 스타일과 크기의 글자를 보관해 놓은 일종의 문자 라이브러리(Library) 또는 글리프(glyph)의 라이브러리로, 컴퓨터에서 사용되는 모든 문자의 모양과 크기에 대한 정보를 총칭한다. 폰트의 정보에는 글자의 모습을 정의하는 활자의 서체(typeface)와 글자의 크기, 그리고 위첨자(ascent), 아래첨자(decent), 강조(Bold) 등과 같은 속성 등이 포함되며, 그 구성 방법에 따라 크게 비트맵 폰트와 윤곽선
 폰트로 나뉘어진다. 이 용어는 종종 서체(typeface)나 폰트 군을 가리키는 것으로 잘못 사용된다. 

비트맵(Bitmap)
2차원적인 사각 평면을 작은 격자로 나누고 그 위에 이미지가 표현된다고 했을 때, 비트맵은 0과 1로 된 격자(grid)이다. 이 격자를 컴퓨터가 픽셀로 변환시켜 표현하는 것으로, 컴퓨터 그래픽에서 글자 혹은 이미지를 표현하는 픽셀(pixel)의 집합이라고도 할 수 있다. 각 픽셀은 컴퓨터 메모리에서 비트(bit)에 대응한다. 각 비트에 대응되는 이미지에 대한 정보의 상태가 0과 1로 표현된 것이고, 비트들이 온(on), 오프(off)가 되면서 여러 개의 점들이 조합되어 정보가 표현된다. 색채와 명암을 표현하려면 많은 정보가 필요하며, 여러 개의 점들로 표현되기 때문에 화면에서 이미지나 글자를 확대했을 때 매끄럽지 못한 모습을 보게 되는 것이다. 일반적으로 대부분의 컴퓨터가 비트맵 방식으로 이미지를 저장하고 관리하며, 대표적인 비트맵 파일로는 그래픽 이미지 저장 형식인 GIF와 JPG가 있다. 글자의 모양을 비트맵의 형태로 저장하고 관리하기도 하는데 이를 비트맵 글꼴이라고 한다. 


윤곽선 글꼴 
글자의 윤곽을 여러 부분으로 나누고, 점이 아닌 직선, 원호, 자유곡선 등으로 표현한 다음, 출력할 때에 안쪽을 채워서 재현하는 글꼴. 윤곽선 글꼴은 하나의 크기에 대한 글자 데이터만 가지고, 수식 계산에 따라 자유롭게 임의의 글자 크기나 기울임, 각도 등을 처리하므로 기억 용량이 매우 감소하며, 글자의 크기를 확대해도 글자의 모습이 매끄럽게 나타난다. 이러한 글꼴의 변형은 사진 식자기에서 렌즈가 처리해주는 부분까지 모두 가능하지만, 획의 굵기 변화 등 글꼴 모양 자체의 변화까지는 처리할 수 없다. 
출력 글자를 생성할 때는 일단 출력하는 크기에 맞추어 윤곽선의 직선이나 곡선부분을 좌표로 계산하고 그 내부를 채우는 과정이 필요하므로 속도가 느려진다. 이러한 계산 과정 때문에 70년대까지는 실용화되지 못하다가 80년대 중반 이후컴퓨터 프로세서의 발달로 고가의 레이저 프린터 등에서 사용이 시작되었다. 90년대에는 컴퓨터의 속도 향상이 더욱 가속되어 현재에는 출력기에는 물론이고 우리가 늘 접하는 윈도우나 인터넷 등의 화면에서도 대부분 윤곽선 글꼴의 글자를 실시간으로 출력하여 보여준다. 윤곽선 글꼴은 벡터 글꼴이라고도 하며, 많이 사용되는 윤곽선 글꼴 형식으로는 포스트스크립트 타이프 1(Type 1)과 트루타이프(TrueType)가 있다. 


윤곽선 글꼴

윤곽선 글꼴











출처 - 네이버  


폰트란 본래 인쇄 관계의 용어이며, 동일 사이즈, 동일 서체로 디자인된 한 조의 활자 세트를 의미하는 것이지만, 정보 처리 분야에서는 인쇄에 있어서 활자와 CRT 디스플레이 상에서 자체, 서체, 폰트라고 번역되는 경우가 많다. 활자에서는 고딕체, 명조체, 교과서체 등이 있으며 문장의 느낌과 책의 종류에 따라서 분리하여 사용된다. 또 CRT 디스플레이 상에서는 각 문자(character)는 도트를 모아 표현함으로써 구성된다. 이 도트의 빛나는 부분, 빛나지 않은 부분의 조합을 바꿈으로써 자체를 변경할 수 있다. 일반 표준적인 단말기(terminal)의 도트의 포인트 수는 세로 8도트, 가로 8도트로 되어 있으므로 각 문자마다 특징이 있으며, 보기 쉽도록 되어 있다. 또한 프린터 등에서의 자체는 인쇄된 것을 광학 문자 인식 등에 이용하기 쉽도록 각 문자는 각각 특징을 갖도록 되어 있다.

출처 - 네이버 


==============================================================================================


1.FreeType이란

.소개

FreeType은 폰트에 대한 정보를 추출하는 폰트 엔진이다. 폰트는 텍스트 출력에 사용되는 글꼴에 관련된 정보의 집합이다. 굉장히 많은 정보가 복잡한 구조로 직접되어 있어서 내부 구조가 굉장히 복잡하다. 포맷이 문서화되어 있기는 하지만 직접 분석해서 원하는 정보를 얻기는 상당히 어렵다. 이럴 때 폰트 엔진이 필요하다.

문자열을 출력하려면 원하는 글꼴을 만든 후 TextOut이나 DrawString으로 뿌리면 그만이다. 어차피 폰트는 문자열을 출력하기 위한 수단이며 이런 목적으로 쓸 수 있는 고수준의 함수들은 운영체제가 제공한다. 그러나 단순한 출력 이상의 뭔가를 하고 싶을 때는 폰트의 정보를 직접 읽어서 가공해야 한다. 예를 들자면 다음과 같은 경우가 해당된다.

 

■ 운영체제에 설치되지 않은 폰트를 사용하고 싶을 때는 폰트를 직접 읽어야 한다. 예를 들어 문서에 내장된 폰트라든가 네트워크를 통해 공유된 폰트를 사용해야 할 때 등의 경우가 이에 해당한다.

■ 워드 아트처럼 글자의 모양을 마음대로 변형하고 싶을 때. 운영체제는 글꼴을 아주 정상적인 모양으로 출력하는 기능만 제공하므로 변형하려면 외곽선을 직접 조작해야 한다.

■ 글자의 스타일을 다양하게 주고 싶을 때. 굵게, 이탤릭 정도는 되지만 이중 외곽선이나 글자 색상과 다른 특이한 밑줄 같은 것은 줄 수 없다. 직접 그려야 한다.

■ 플랫폼에 독립적인 응용 프로그램을 만들 때도 폰트 엔진을 사용해야 한다. 운영체제가 제공하는 고수준 함수는 쓰기는 편하지만 포맷에 종속적이다.

 

이 외에도 폰트 엔진이 필요한 경우는 많다. 하옇든 운영체제가 제공하는 문자열 출력 기능이 뭔가 부족할 때 직접 폰트를 다루어야 한다. 폰트 엔진은 폰트를 떡 주무르듯이 주무를 수 있게 해 주며 부족한 2%를 넉넉하게 채워줄 수 있다. 폰트 엔진은 여러 가지가 있지만 현재 가장 범용적이고 기능적으로 앞선 라이브러리가 바로 FreeType이다.

참 좋은 라이브러리인데 한글로 된 강좌가 없다. 국내에도 사용자가 꽤 많은데 다들 실무에 급급하다 보니 대충 익혀서 쓰기만 할 뿐 간단한 사용기조차도 올리는 사람도 보기 어렵다. 영문으로 된 강좌는 가끔 구할 수 있지만 이마저도 윈도우즈 환경이 아니라 주로 리눅스나 매킨토시 환경으로 되어 있어 국내 사정과는 잘 맞지 않다.

그래서 비록 사용 경험이 일천하지만 아는데까지 강좌를 써 보았다. 상업적으로 출판되는 출판물이 아니고 짧은 시간에 후다닥 쓰다 보니 디테일이 좀 떨어지지만 편하게 읽을 수 있도록 격식없이 썼으니 양해 바란다. 아무리 대충 썼다고는 하나 그래도 16년간 강좌만 써온 강좌의 달인... 퍽! 나가~

이 강좌의 예제들은 비스타 환경에서 한글 비주얼 스튜디오 2008로 작성했다. XP 환경의 VS 2005 컴파일러를 쓰더라도 이 강좌를 읽는데는 큰 문제가 없겠지만 사소하게 틀린 면들이 있을 수는 있으므로 환경이 다르다면 주의해서 읽기 바란다.

.특징

FreeType의 웹 사이트는 FreeType 라이브러리를 다음과 같이 소개하고 있다.

 

small, efficient, highly customizable and portable, producing high-quality output font engine

 

작고 효율적이고 커스터마이징 가능하고 이식성있는 고품질 폰트 엔진이라고 되어 있다. 좋은말 다 붙여 놨는데 과연 어떤 특징이 있는지 정리해 보자. 장점도 있지만 단점도 있다.

 

■ 폰트 파일에 독립적이다. 특정 포맷만 읽는 것이 아니라 다양한 폰트를 일관된 인터페이스로 읽을 수 있다. TypeType, OpenType, Type1, CFF, PFR, BDF 등등 현재 널리 사용되는 거의 모든 폰트를 읽을 수 있다.

■ 확대 가능한(Scalable) 폰트를 지원한다. 외곽선 추출 기능이 있어서 품질 저하없이 미려한 모양으로 얼마든지 크게 출력할 수 있다. 비트맵 폰트도 물론 지원한다.

■ 힌트, 커닝 등의 고급 정보들도 섬세하게 조작할 수 있으며 트루타입 인터프리터까지 내장되어 있어 작은 크기로 출력해도 가독성이 높은 문자열을 출력할 수 있다.

 256 레벨의 안티 알리아싱 기능이 제공되어 고품질의 텍스트를 출력할 수 있다. 윈도우즈 2000 이하의 버전에서 고작 5레벨의 안티 알리아싱을 제공하는데 비해 훨씬 더 품질이 높다.

■ 응용 프로그램에 연결하는 형태가 자유롭다. 컴파일 타임에 정적으로 연결할 수도 있고 DLL로 만들어 실행중에 연결하여 사용할 수도 있다.

■ 라이브러리 내에 쓰기 가능한 전역 변수가 없으며 필요한 모든 메모리를 동적으로 할당한다. 그래서 ROM에서도 바로 실행할 수 있는데 이런 특성으로 인해 모바일 환경에도 충분히 활용할 수 있다. 즉, 영문폰에 한글 문자열을 출력할 수 있다는 뜻이다.

■ 라이브러리 자체는 표준 C언어로 작성되어 있어 함수만 호출하면 바로 사용할 수 있다. 물론 객체 지향적인 라이브러리보다 손이 많은 가기는 하지만 함수 레벨의 라이브러리가 처음 배우기 쉽고 효율도 좋다. C언어만 컴파일할 수 있으면 어떤 컴파일러에서나 사용할 수 있다. 물론 C++ 컴파일러에서도 당연히 사용 가능하다.

■ 특허가 걸린 기술은 일체 사용하지 않는다. 예를 들어 TrueType 관련 기술들은 애플사가 특허를 보유하고 있는데 이런 기술들은 대체 기술을 적용한다. 그래서 소송 걱정없이 사용할 수는 있지만 특정 기능에서는 품질이 조금 떨어질 수도 있다.

 FreeType은 텍스트를 바로 출력하는 고수준의 함수가 아니라 저수준의 서비스이다. 그래서 텍스트 출력, 문자열 정렬, 캐싱 등의 작업은 직접 해야 한다. 또한 폰트를 읽기만 할 뿐 편집하는 기능도 제공되지 않는다. 즉, 아무나 쉽게 쓸 수 있는 먹기 좋은 떡은 아닌 셈이다.

 

FreeType은 다양한 포맷의 폰트를 지원하지만 이 강좌에서는 주로 트루 타입만을 다룬다. 왜냐하면 강좌 자체가 윈도우즈 환경에서 쓰여졌기 때문이다. FreeType은 유닉스나 매킨토시에서도 쓸 수 있지만 이 강좌에서는 다루지 않는다. 유닉스는 조금 알지만 설치할 남는 컴퓨터가 없고 집이 가난해서 매킨토시를 살 돈이 없기 때문이다.

.설치

FreeType은 공개된 라이브러리이다. 떳떳하지 못하게 불법 복사하거나 P2P 사이트에서 남에게 아쉬운 소리해 가며 어렵게 구할 필요없이 다음 사이트에서 언제든지 다운로드받을 수 있다. 로그인이나 회원가입도 필요없다.

 

http://www.freetype.org

 

최신 버전이 나왔는지도 항상 살펴 봐야 하고 자습서나 레퍼런스도 여기서 참조해야 하므로 즐겨찾기에 등록해 두기 바란다. 장사를 하는 사이트가 아니다 보니 디자인이 아주 검소하고 군더더기가 없다. 여러분이 이 강좌를 읽고 있는 WinApi와 거의 동급의 디자인 수준이다(솔직히 말해 WinApi가 조금 더 나아 보인다 ^_^).

여기서 라이브러리와 문서, 예제들을 다운받을 수 있다. FreeType도 나름대로 역사가 있는데 최초 1.0은 트루타입만 지원했으나 2.0부터 지원 포맷이 대폭 늘어 났으며 버전이 높아질수록 기능이 더 많이 추가되었다.

이 강좌를 쓰는 시점에서 최신 버전은 2.3.7이지만 여러분들이 이글을 읽을 때 쯤에는 아마도 더 최신 버전으로 업데이트되어 있을 것이다. 가급적이면 최신 버전을 받되 버전이 올라가면 기능의 첨삭이 당연히 있을 것이다. 최신 버전 사용자는 어! 강좌랑 다르네 하고 헷갈려하지 말고 눈치껏 강좌를 읽기 바란다.

일단 라이브러리를 받아야 실습을 해 볼 수 있으므로 다운로드부터 받아보자. Downloads의 Stable releases를 클릭하여 링크를 따라 들어가면 다음 페이지가 나타난다. 물론 지금 당장 그렇다는 것이지 장래에는 링크가 어떻게 바뀔지 알 수 없으므로 역시 눈치껏 다운로드받기 바란다.

여기서 라이브러리와 데모, 문서를 다운로드받는다. 문서는 웹 사이트에서도 읽을 수 있으므로 별도로 다운받지 않아도 상관없다. 다운로드받아봐야 어차피 html이라 웹에서 읽는것과 다르지 않다.

도표의 2번째에 있는 freetype2 링크를 클릭하여 ft237.zip을 다운로드 받는다. 압축을 풀면 freetype-2.3.7 폴더가 생기는데 이 폴더를 일단 루트에 복사해 놓자. 물론 원하는 곳에 풀어 놔도 상관없지만 이 강좌와 환경을 맞추려면 가급적 게기지 말고 시키는대로 따라하는 것이 좋다. 만약 최신 버전보다 이 강좌에서 사용하는 버전을 사용하려면 다음 사본을 받기 바란다.

 

ft237.zip

 

압축 파일에는 바로 사용 가능한 바이너리가 포함되어 있지 않다. 다양한 운영체제에서 사용할 수 있으므로 사용 환경에 맞게 빌드해서 써야 한다. 일단 라이브러리부터 빌드하자. 다양한 운영체제별로 메이크 파일이 제공되는데 비주얼 스튜디오의 경우 builds/win32/visualc 폴더안에 솔루션 파일이 제공된다. freetype.sln 파일을 비주얼 스튜디오로 연다.

솔루션 파일은 VS 2005로 작성되어 있지만 VS 2008에서도 변환만 하면 문제없이 열 수 있다. 솔루션을 컴파일한다. 디버깅해 볼 게 아니므로 그냥 Release로 컴파일하면 된다. 경고가 엄청나게 발생하는데 확장자 C인 소스에 왜 //로 된 C++ 주석을 쓰느냐는 잔소리다. 그냥 무시해 버리면 된다. 컴파일이 완료되면 objs 폴더에 freetype237MT.lib라는 845K짜리 라이브러리 파일이 생성된다. 이 파일이 우리가 사용해야 할 라이브러리이며 배포 예제에도 포함되어 있으므로 이 강좌의 예제는 바로 컴파일해 볼 수 있다.

라이브러리의 크기가 부담스럽다면 꼭 필요한 모듈만 포함시켜 크기를 줄일 수도 있는데 커스텀 빌드 방법에 대해서는 배포 문서에 자세히 설명되어 있다. 그러나 굳이 그럴 필요는 없다. 비주얼 C++의 링커는 호출되는 함수만 쏙쏙 골라서 실행 파일에 링크할 정도로 충분히 똑똑하다. 845K가 통째로 실행 파일에 다 들어가는 것은 아니므로 부담없이 사용하면 된다.

다음은 비주얼 스튜디오에게 FreeType 라이브러리의 헤더 파일의 위치를 알려 주어야 한다. 도구/옵션 메뉴로 환경설정창을 열고 VC++ 디렉터리 노드에서 포함 파일 경로를 지정한다.

라이브러리는 프로젝트별로 직접 지정할 것이므로 포함 파일 경로만 가르쳐 주면 된다. 여기까지 작업하면 FreeType을 쓸 준비가 완료되었다. 운영체제나 링크 방식에 따라 조금씩 달라질 수도 있는데 상세한 빌드 방법은 압축 파일내의 문서에 설명되어 있다.

.레퍼런스

어떤 과목을 공부하든지 레퍼런스는 꼭 필요하다. FreeType은 홈 페이지의 Documentation에 레퍼런스가 잘 구비되어 있으므로 도움말이 필요할 때 웹 사이트에서 원하는 정보를 바로 구할 수 있다. Index 링크로 들어가면 FreeType의 모든 함수, 구조체에 대한 정보를 볼 수 있다.

알파벳순으로 정렬되어 있으므로 별 어려움없이 함수나 구조체에 대한 도움말을 육안으로 검색할 수 있을 것이다. 도움말은 모두 링크로 연결되어 있으므로 마우스로 꾹꾹 누르기만 하면 된다. 초기화 함수에 대한 설명을 보자.

인수에 대한 설명, 리턴값에 대한 설명이 잘 기록되어 있으며 주의 사항도 친절하게 설명되어 있다. 구조체에 대한 정보도 아주 상세해서 모든 멤버의 의미를 바로 바로 조사할 수 있도록 되어 있다.

영문이지만 결코 어려운 영어가 아니므로 필요할 때마다 참조하면 된다. 만약 인터넷에 접속할 수 없는 환경이라면, 예를 들어 도서관에서 공부를 해야 한다면 이 도움말 전체를 다운로드받아 가지고 다니며 볼 수도 있다. 우리나라에서는 왠만해서는 인터넷 안되는 곳이 없으므로 그럴 필요가 없을 것이다.

도움말 외에 Typography에 대한 일반론과 Tutorial도 제공된다. 이 문서들은 분량이 얼마 안되지만 굉장히 쉽고 상세하게 쓰여져 있으므로 꼭 읽어 보기 바란다. 나는 이 문서를 인쇄하여 춘천 시립 도서관에 짱박혀서 아주 열심히 탐독했으며 그 결과 이런 강좌까지 쓰게 되었다. 처음부터 영문으로 공부하기 부담스럽다면 이 강좌를 통해 워밍업을 한 후 차근히 읽어 보기 바란다. 


출처 -  http://www.winapi.co.kr/project/library/freetype/ft1.htm 




'Development > Common' 카테고리의 다른 글

main 함수  (0) 2012.03.07
프로그램 소스코드를 공개하는 사이트  (0) 2012.03.07
Freemarker  (0) 2012.02.26
1세대/2세대/3세대/4세대/5세대 언어  (0) 2012.02.24
확장문자 or 특수문자(escape sequence)  (0) 2012.02.18
Posted by linuxism
,