2008/10/16에 해당되는 글 4건
2008.10.16 :: MS-SQL의 특징
2008.10.16 :: 알고리즘 코딩기법 - 1. Introduction
2008.10.16 :: .NET과 .NET Framework
2008.10.16 :: Orientation - MFC 5
2008. 10. 16. 22:00 :: 효과적인 DB설계
Microsoft SQL Server는 분산형 클라이언트 서버 환경을 위해서 틀별히 디자인 된 고성능의 스케일러블 데이터베이스 관리시스템으로 내장된 데이터복제 기능과 강력한 관리 툴 및 개방형 시스템 아키텍쳐는 기업이나 조직의 규모에 맞춰 가장 경제적인 정보솔루션을 구축할 수 있도록 최상의 플랫폼을 제공한다.
MSSQL의 특징
- 통합을
- 표준 대치형 멀티프로세서 하드웨어 지원
- 탁월한 가격대 성능비 및 비용 절감
- 개방형 표준 및 향상된 관리 툴
- 통합과 업계 표준 지원
- 광범위한 개발 툴
- 다수의 서버를 지원하는 트랜잭션의 유연한 관리
- 수백개의 솔루션
- 내/외부와의 탁월한 연결 기능
- 내장된 데이터 복제기능
- 완벽한 인터넷/인트라넷 통합
- 강력한 호스트 연결성
- 우수한 메일 통합 기능
- 통합된 C2/E3 보안 기능
- Windows NT에서의 기업네트워크 규모 조정성
- Windows NT와의 결합으로 NT 서버에서 지원하는 모든 하드웨어 구조에서 완벽하게 지원한다.
- NT상에서는 SQL 서버가 서비스로서 동작하는데, [제어판]-[서비스] 부분을 보면 된다. 윈9x에서는 어플리케이션의 개념으로 동작을 한다. NT에 최적화 되어 있으며 윈98 설치시 게임이나 사운드 카드, 비디오카드와의 충돌 등 많은 문제를 가질 수 있다.
- NT 도구(스케쥴링, 성능 모니터, 이벤트 표시기)와 연동된다.
- SQL서버에서 사용하는 거의 대부분의 프로세스를 윈도우즈NT에서 모니터링이 가능하다. 특히 NT 성능 모니터에서의 모듈인은 아주 섬세한 부분의 모니터링과 튜닝까지의 연계도 가능해진다. 아울러 SQL서버 자체내에 로그 시스템으로 오류를 분석하며 오류의 설정으로 NT 이벤트 로그에도 사용이 가능해진다. SQL서버의 인증방식은 두 가지로 SQL Server and WindowsNT 인증과 Windows NT only 인증이 있다. 기본 세팅은 1번 인증이고, NT 서버의 인증 체계를 그대로 사용이 가능하다.
- 집중화된 서버 관리로 분산된 기업환경에서의 집중된 서버 관리 도구를 제공한다.
- NT는 텔넷 인증이 없다. 그러나 SQL 서버는 Enterprise Manager라는 관리 툴로 원격지의 서버를 등록(Register)후 완전한 관리가 가능하다. 그 외에도 간편한 Linked서버를 이용하는 방식과 OLE-DB를이용해 Open Rowset으로 쉽게 접근이 가능해 진다.
- OLTP(On-Line Transaction Processing)와 OLAP - DSS(Decision Support System)와 같이 다양하게 요구되는 응용프로그램을 지원하도록 설계되었다
OLTP는 특정한 축상에(보통 시간축) 데이터를 일관된 방식으로 저장한다. 문제는 아주 방대한 자료가 동시 접속 유저에 의해 처리된다는점이다. 아울러 OLAP(DSS)는 이러한 OLTP 데이터를 분석하기 위한툴이다.
- DBMS에 의한 데이터 무결성의 지원이다. 트랜젝션 기반으로 완전한 무결성을 구축이 가능하다.
- 서버 데이터베이스의 일관성과 복구를 지원하는 트랜젝션 관리하고, 다양한 트랜젝션 처리방식을지원 한다.
- 여러 단계의 보안 레벨을 지원한다.
- 다양한 분산 데이터 처리기능의 지원한다.
- 정보의 배포를 위한 내장된 복제 기능이 있고, 적시에 정확한 정보를 필요한 사람에게 제공한다. 상당히 범용적인 복제 전략을 구축이 가능해지며, 대용량 데이터베이스를 지원한다.
- 응용 프로그램 개발을 위한 다양한 인터페이스를 제공한다.
- ODBC
- DB - Library
- Open Data Service
2008. 10. 16. 22:00 :: 알고리즘코딩기법
안녕하세요 SSM17.2기 (17-2기 라고 해야 맞는건가요?) 조일룡입니다.
온라인 개인형 맞춥시그 - 가칭 주제없는 시그 - 에서 제가 맡은 주제는 '알고리즘 코딩기법' 입니다.
주제는 뭐 저렇구요.. 코딩 얘기만 하는 것이 아니라 이것 저것 다양한 주제로 포스팅을 해 볼까 합니다.
주로 참고할 레퍼런스로는...
The Art of Computer Programming / Donald E. Knuth (ISBN:9788979144307)
Introduction to Algorithm / Cormen (ISBN:9788979143171)
생각하는 프로그래밍 / Jon Bentley (ISBN:9788995300930)
와 각종 인터넷을 참고하겠습니다.
우선 오늘은 첫 포스팅이니 만큼 가벼운 주제로 시작을 하겠습니다 ^^;
아마 앞으로도 계속 가벼운 주제로 포스팅을 하게 될 것 같습니다.
알고리즘
우선은 알고리즘(algorithm)이라는 단어에 대해서 대충 알아보도록 합시다
"알고리즘(algorithm)"이라는 단어는 그 자체로 상당히 흥미로운데, 언뜻 보면 로가리즘(logarithm)의 처음 네 글자를 뒤섞어놓은 것 같다. 이 단어는 1957년이 되어서야 Webster's New World Dictionary에 올랐다. 그 전까지는 알고리즘의 예전 형태인 algorism밖에 없었다. algorism의 고전적인 의미는 '아라비아 숫자를 이용한 산술'이었다. 중세에는 계산판을 이용해서 계산을 하는 계산판 사용자들과 아라비아 숫자를 이용해서 계산을 하는 알고리스트들이 있었다.
...
algorism의 형태와 의미는 점차 변질되었다. Oxford English Dictionary는 이 단어가 식자들이 arithmetic의 그리스어 어원과 혼동함으로써 "최근의 algorithm을 포함한, 여러 유사어원학적 왜곡을 거쳤다"고 설명한다. 사람들이 이 단어의 기원을 이미 잊었다는 점을 생각한다면, "algorism"이 "algorithm"으로 변한 것이 그리 이해 못할 일은 아니다.
- The Art of Computer Programming
자, 이제 알고리즘의 어원에 대해 알아봤으니 그 특징에 대해 알아봅시다.
위대한 학자 Knuth님 께서는 알고리즘의 중요한 다섯가지 특징을 다음과 같이 정리를 하셨습니다.
1. 유한성: 알고리즘은 단계들을 반드시 유한한 횟수로 거친 후에 종료해야 한다.
2. 명확성: 알고리즘의 각 단계는 반드시 명확하게 정의되어야 한다.
3. 입력: 알고리즘은 0또는 그 이상의 입력들을 가진다.
4. 출력: 알고리즘은 하나나 그 이상의 출력들을 가진다.
5. 효과성: 일반적으로 알고리즘은 효과적(effective)이어야 한다고 간주된다.
알고리즘의 중요성
그렇다면 알고리즘을 왜 공부해야 할까요?
컴퓨터의 성능은 하루가 다르게 발전하고 있고 프로그램은 나날히 거대하고 복잡한 괴물이 되고 있습니다. 공학적 측면에서 따져봤을 때 프로그램의 효율성보다 개발주기를 짧게하고 유지보수를 용이하게 하는 것에 중점을 둬야 하는건 당연한 이치입니다. 하지만 그렇다고 프로그램의 효율성을 완전히 무시할 수 있을까요?
컴퓨터가 무한히 빠르고 메모리는 따로 비용이 들지 않는다고 생각해보자. 그런 경우에도 알고리즘을 공부할 이유가 있을까? 자신이 개발한 알고리즘이 타당한 답을 출력하면서 종료된다는 것만을 보여주고자 하는 경우라면 이 질문에 대한 답은 참일 것이다.
하지만 컴퓨터가 무한히 빠를 경우, 어떤 문제를 해결하는 타당한 알고리즘들 역시 모두 무한히 빠를 것이다. 따라서 자신이 구현한 방법이 훌륭한 소프트웨어 공학의 실현범위 안에 있음을 보이고 싶겠지만 사실 어떤 방법으로 구현하든 차이는 없다.
물론, 컴퓨터가 상당히 빠를수는 있다. 하지만 무한히 빠를 수는 없다. 메모리 역시 매우 값쌀 수는 있지만 비용이 전혀 들지 않을 수는 없다. 결국 계산 시간은 일종의 한정된 자원이며 메모리 공간도 마찬가지다. 이러한 자원들은 효율적으로 사용되어야 하며 시간과 공간의 측면에서 효율적인 알고리즘이 필요하게 된다.
하지만 컴퓨터가 무한히 빠를 경우, 어떤 문제를 해결하는 타당한 알고리즘들 역시 모두 무한히 빠를 것이다. 따라서 자신이 구현한 방법이 훌륭한 소프트웨어 공학의 실현범위 안에 있음을 보이고 싶겠지만 사실 어떤 방법으로 구현하든 차이는 없다.
물론, 컴퓨터가 상당히 빠를수는 있다. 하지만 무한히 빠를 수는 없다. 메모리 역시 매우 값쌀 수는 있지만 비용이 전혀 들지 않을 수는 없다. 결국 계산 시간은 일종의 한정된 자원이며 메모리 공간도 마찬가지다. 이러한 자원들은 효율적으로 사용되어야 하며 시간과 공간의 측면에서 효율적인 알고리즘이 필요하게 된다.
- Introduction to Algorithm
컴퓨터가 빨라지고 있다고는 하지만 무한대로 빠를 수는 없습니다. 메모리도 마찬가지입니다. 알고리즘이 중요한 원인은 바로 여기에 있습니다. 위의 글과 같이 컴퓨터가 무한히 빠르다면 동일한 문제를 푸는데 1000번의 연산을 하든 100만번의 연산을 하든 10억번의 연산을 하든 상관없습니다. 컴퓨터가 무한히 빠르기 때문에 입력과 동시에 답이 나오겠지요. 하지만 현실적으로 엄청나게 빠른 컴퓨터는 있을 수 있지만 무한히 빠른 컴퓨터는 존재하지 않습니다. 엄청나게 빠른 컴퓨터에서 10억번의 연산을 하는 것과 1000번의 연산을 하는 시간차가 무시할 수 있는 수준이라면 당연히 공학적 측면에서 유리한 프로그램을 선택해야 합니다만 10억의 팩토리얼의 연산을 해야하는 알고리즘이라면 어떨까요..
효율성 외에도 잘 정리된 알고리즘을 사용해서 문제를 해결한 프로그램의 경우 테스트를 거치면서 case by case로 버그를 수정하면서 완성된 프로그램보다 훨씬 간결하고 버그나 tricky한 인풋에 대해 훨씬 견고한 특징을 보여줍니다. 물론 알고리즘이 어려워서 후임 개발자가 이해하지 못한다면 유지보수는 어렵게 되겠지만 그것은 어려운 알고리즘보다는 개발자의 능력의 부족합을 탓해야겠지요
무엇보다 중요한 것은 어떤 문제들은 알고리즘을 모르면 풀지 못한다는 것에 있습니다. 이런 문제와 마주쳤다고 했을 때 알고리즘을 안다면 몇 시간만에 해결할 수 있는 것을 모르는 경우 몇 달이 걸려도 해결하지 못할 수도 있습니다. 물론 그런 문제를 여러분의 회사에서 프로그래밍을 하면서 접하게 될 가능성이 매우 희박하겠지요.. ^^
알고리즘의 선택
예를 들어 256개의 원소를 가진 배열을 생각해봅시다.
이 원소들이 정렬이 안되어 있는 상태에서 하나의 원소를 찾으려면 처음부터 끝까지 찾으려는 원소를 발견할 때 까지 하나씩 검사를 해야합니다. 이를 순차검색이라 하고 평균적으로 n/2의 비교를 해야합니다.
반면 우리가 잘 알고있는 바이너리서치의 경우 log n 번만 비교하여 원하는 원소를 찾을 수 있습니다. 하지만 배열이 정렬이 되어있지 않기 때문에 우선 정렬을 해야합니다. 정렬은 n log n 번의 연산이 필요합니다. (비교 정렬의 경우 필요한 비교횟수의 하한이 Ω(n log n) 임이 증명되었습니다.) 그 후 바이너리서치를 해서 원소를 찾을 수 있으므로 총 연산은 n log n + log n 번이 됩니다.
순차검색과 정렬 후 바이너리 서치의 연산횟수를 비교해 보면 n/2 와 n log n + log n 으로 순차검색이 더 유리합니다. 하지만 한 번이 아니라 필요할 때마다 원소를 검색해야한다면 상황이 달라집니다. 가령 10000번의 검색을 해야한다고 하면 순차검색의 경우 10000 * n/2 번의 연산이 필요합니다. 반면 바이너리 서치의 경우 정렬은 한 번만 수행하면 되므로 n log n + 10000 * log n 번 만큼 연산을 해야 합니다.
원소가 256개 이므로 평균횟수는 다음과 같습니다.
효율성 외에도 잘 정리된 알고리즘을 사용해서 문제를 해결한 프로그램의 경우 테스트를 거치면서 case by case로 버그를 수정하면서 완성된 프로그램보다 훨씬 간결하고 버그나 tricky한 인풋에 대해 훨씬 견고한 특징을 보여줍니다. 물론 알고리즘이 어려워서 후임 개발자가 이해하지 못한다면 유지보수는 어렵게 되겠지만 그것은 어려운 알고리즘보다는 개발자의 능력의 부족합을 탓해야겠지요
무엇보다 중요한 것은 어떤 문제들은 알고리즘을 모르면 풀지 못한다는 것에 있습니다. 이런 문제와 마주쳤다고 했을 때 알고리즘을 안다면 몇 시간만에 해결할 수 있는 것을 모르는 경우 몇 달이 걸려도 해결하지 못할 수도 있습니다. 물론 그런 문제를 여러분의 회사에서 프로그래밍을 하면서 접하게 될 가능성이 매우 희박하겠지요.. ^^
알고리즘의 선택
예를 들어 256개의 원소를 가진 배열을 생각해봅시다.
이 원소들이 정렬이 안되어 있는 상태에서 하나의 원소를 찾으려면 처음부터 끝까지 찾으려는 원소를 발견할 때 까지 하나씩 검사를 해야합니다. 이를 순차검색이라 하고 평균적으로 n/2의 비교를 해야합니다.
반면 우리가 잘 알고있는 바이너리서치의 경우 log n 번만 비교하여 원하는 원소를 찾을 수 있습니다. 하지만 배열이 정렬이 되어있지 않기 때문에 우선 정렬을 해야합니다. 정렬은 n log n 번의 연산이 필요합니다. (비교 정렬의 경우 필요한 비교횟수의 하한이 Ω(n log n) 임이 증명되었습니다.) 그 후 바이너리서치를 해서 원소를 찾을 수 있으므로 총 연산은 n log n + log n 번이 됩니다.
순차검색과 정렬 후 바이너리 서치의 연산횟수를 비교해 보면 n/2 와 n log n + log n 으로 순차검색이 더 유리합니다. 하지만 한 번이 아니라 필요할 때마다 원소를 검색해야한다면 상황이 달라집니다. 가령 10000번의 검색을 해야한다고 하면 순차검색의 경우 10000 * n/2 번의 연산이 필요합니다. 반면 바이너리 서치의 경우 정렬은 한 번만 수행하면 되므로 n log n + 10000 * log n 번 만큼 연산을 해야 합니다.
원소가 256개 이므로 평균횟수는 다음과 같습니다.
순차검색: 10000 * 256/2 = 10000 * 128 = 128만
이분검색: 256 * lg 256(정렬) + 10000 * lg 256(검색) = 256 * 8 + 10000 * 8 = 82048
이분검색: 256 * lg 256(정렬) + 10000 * lg 256(검색) = 256 * 8 + 10000 * 8 = 82048
위와 같이 256개의 원소를 만번 검색해야하는 경우 정렬 후 이분검색이 10배 이상 빠르다는 것을 알 수 있습니다. 원소의 수가 더 많거나 검색 횟수가 많아질수록 이분검색이 더욱더 유리해집니다.
위의 예에서 보는바와 같이 효율적인 알고리즘의 선택은 매우 중요합니다. 어떤 경우 모든경우의 수를 다 따져봐야하는 것 처럼 보이는(이런 방법을 Brute Force라고 하고 문제에 따라 n에 대해 시간복잡도가 지수적으로 증가합니다)문제가 알고보면 리니어하게 풀리는 것도 볼 수 있습니다. 이 때에는 두 알고리즘의 속도차가 상상을 초월하게 됩니다.
tug of war라는 유명한 문제가 있습니다. 이 문제를 Brute Force로 풀면 아무리 빠른 컴퓨터라 할지라도 지구가 멸망할 때 까지 답을 구할 수 없습니다. 하지만 Dynamic Programming기법을 도입하여 풀면 0.1초 이내에 답을 구해냅니다.
지금까지 알고리즘의 기본개념과 효율적인 알고리즘의 중요성을 살펴봤습니다.
다음 포스팅은 '알고리즘 코딩기법'이라는 제목에 충실하게 위의 예에서 살펴봤던 바이너리서치를 구현하는 방법에 대해서 이야기하겠습니다.
부디, 작은 것들을 몸소 익히고,
그런 후에 더 큰 것으로 나아가라.
- 에픽테투스 Epictetus (Discourses IV.i)
그런 후에 더 큰 것으로 나아가라.
- 에픽테투스 Epictetus (Discourses IV.i)
2008. 10. 16. 10:00 :: .net Framework
.NET Framework에 대한 포스팅을 앞으로 주욱 써나갈 생각입니다.
우선 .NET Framework란 무엇인지에 대해서 말하기 위해 가장 필요한 것 부터 정리해 나가겠습니다.
.NET Framework 란?
우선 Framework라 함은 프로그래밍을 해보신 분이라면 어디선가 한번씩은 들어본 단어일 것 입니다.
사전적 의미는 뼈대, 골격, 틀, 하부구조, 기반 이란 의미를 지닌 단어죠. 한번쯤 프로그래밍을 해본 사람들이라면
아무리 분야가 달라도 한번쯤 들어봤을 법한 MFC와 같은 것 역시 일반적으로 Framework라고 부르는 걸 보면
아마도 프로그래밍을 좀 더 편하게 하기위해 미리 만들어놓은 골격 구조나 기초 구조와 같은 것들을 의미하는 것이 아닐까요?
Microsoft에선 .NET Framework에 대한 정의를 다음과 같이 이야기 했습니다.
뭔가 매우 복잡한 말인듯 하지만 사실상 주요 키워드만 정리해본다면
즉 통합해서 한마디로 말하자면(물론 위의 첨부 내용도 한마디지만) .NET이라는 목표를 이루기 위해 실질적으로 돌아가는 Window기반의 응용프로그램을 개발하기 위한 기반이 되는 환경이라고 생각하시면 됩니다.
.NET?
물론 종종 일반적으로 개발자들이 .NET과 .NET Framework를 종종 동일한 의미로 사용해서 말하는 경우가 자주 있습니다. 사실 두가지는 틀린 이야기지만 의미론적으로 이해하고 다들 넘어가는게 대부분이라 딱히 구분할 필요가 없다고는 하지만 그래도 처음 시작이니 적어도 그 두가지 의미의 차이를 확실히 집고 넘어가기 위해 정리를 해본다면
공용언어 런타임(Common Language Runtime, CLR)
공용 언어 런타임은 우리가 .NET 언어로 코드를 작성할 때 일반적으로 신경써야 하는 부분들, 예를 들면 메모리 관리, 보안 관리, 오류 처리 등의 작업을 도와주어 프로그래밍을 단순화하는 역할을 할 뿐만 아니라 .NET Framework로 개발된 응용프로그램의 실행 환경을 제공합니다. 그래서 공용 언어 런타임을 코드 관리 환경이라고도 하며 코드 관리 환경에서 실행되는 코드를 관리 코드(Managed Code)라고 합니다.
.NET에서의 핵심이 .NET Framework라면 .NET Framework에서의 핵심은 바로 공용 언어 런타임입니다. 공용 언어 런타임은 .NET 언어의 내부 처리 프로세스와 관계가 깊으므로 .NET에서 PL(Programming Language)과 관련된 부분을 이야기하고자 한다면 이를 이야기 하는 것이라고 봐도 무방할 것입니다.
.NET Framework 클래스 라이브러리(.NET Framework Class Library)
.NET Framework 클래스 라이브러리는 개발자가 질 높은 응용 프로그램을 구현하거나 이미 개발된 응용 프로그램을 신속하게 확장할 수 있도록 도와주는 기능들을 미리 패키지화한 것을 말합니다. 여기에는 크게 네 가지 요소로 구성되어 있습니다.
1. ASP.NET은 웹 구현을 위해 사용되는 기능들을 미리 패키지화한 것이며 이것은 곧 하나의 웹 기술을 의미합니다. 물론, 여기에는 XML 웹 서비스 기술도 함께 포함되어 있습니다.
2. Data and XML이라고 되어 있는 부분은 .NET을 통해 만들어진 응용 프로그램이 데이터 소스(데이터베이스 또는 기타 다른 정보 저장 공간)와 원활히 연결될 수 있도록 도와주는 기능들을 미리 패키지화한 것입니다(ADO.NET).
3. Windows Forms는 Windows응용프로그램 개발을 위해 사용되는 기능들을 미리 패키지화한 것입니다.
4. Base Class Library는 위에서 언급한 .NET Framework의 세 가지 구성 요소(ASP.NET, Windows Forms, Data and XML)와 .NET Framework에서 공통적으로 사용하는 기능들을 패키지화한 것입니다.
Reference Book : 뇌를 자극하는 ASP.NET 2.0 프로그래밍 - 이시환
우선 .NET Framework란 무엇인지에 대해서 말하기 위해 가장 필요한 것 부터 정리해 나가겠습니다.
.NET Framework 란?
우선 Framework라 함은 프로그래밍을 해보신 분이라면 어디선가 한번씩은 들어본 단어일 것 입니다.
사전적 의미는 뼈대, 골격, 틀, 하부구조, 기반 이란 의미를 지닌 단어죠. 한번쯤 프로그래밍을 해본 사람들이라면
아무리 분야가 달라도 한번쯤 들어봤을 법한 MFC와 같은 것 역시 일반적으로 Framework라고 부르는 걸 보면
아마도 프로그래밍을 좀 더 편하게 하기위해 미리 만들어놓은 골격 구조나 기초 구조와 같은 것들을 의미하는 것이 아닐까요?
Microsoft에선 .NET Framework에 대한 정의를 다음과 같이 이야기 했습니다.
.NET Framework는 마이크로소프트 Windows운영체제 제품군의 중요한 새 구성요소로써 보다 쉽게 시스템을 구축 및 배포하고 다른 네트워크 연결 시스템과 통합할 수 있는 차세대 Windows 기반 응용 프로그램의 기초입니다
뭔가 매우 복잡한 말인듯 하지만 사실상 주요 키워드만 정리해본다면
1. Windows운영체제제품군의 중요한 새구성요소
-> Window에 포함된 구성요소 (중요하다고 하니 앞으로 중요한 역할을 차지할 것이라 생각한 것이겠죠?)
2. 보다 쉽게 시스템을 구축 및 배포하고
-> 쉽게 시스템을 만들 수 있다.
3. 다른 네트워크 연결 시스템과 통합할 수 있는
-> 이기종 시스템과의 통합을 위해 좀 더 나은 환경을 제공하겠다는 것이죠.
4. 차세대 Windows 기반 응용 프로그램의 기초입니다.
-> 앞으론 응용 프로그램을 개발하기 위한 기반 환경(.NET)이 되겠다는 것이죠
즉 통합해서 한마디로 말하자면(
.NET?
물론 종종 일반적으로 개발자들이 .NET과 .NET Framework를 종종 동일한 의미로 사용해서 말하는 경우가 자주 있습니다. 사실 두가지는 틀린 이야기지만 의미론적으로 이해하고 다들 넘어가는게 대부분이라 딱히 구분할 필요가 없다고는 하지만 그래도 처음 시작이니 적어도 그 두가지 의미의 차이를 확실히 집고 넘어가기 위해 정리를 해본다면
.NET이란 XML기반의 웹 서비스를 통해 서로 다른 시스템을 통합하기 위한 제반 환경 및 기반(운영체제, .NET Framework, .NET언어, 통합 개발 환경등 모든 것이 포함된 기반)을 의미합니다.
.NET Framework란 이런 .NET의 목적을 실현 시키기 위해 필요한 기술(ASP.NET, Windows 응용 프로그램 구현 기술, 데이터 엑세스 기술 등등)을 함축한 실질적인 프로그램의 기반 또는 환경을 의미합니다.
.NET Framework의 구조
.NET Framework는 여러 부분으로 나뉘어 있지만 크게 보면 다음의 두부분으로 나뉘어져 있다고 할 수 있습니다.
공용언어 런타임(Common Language Runtime)공용 언어 런타임은 .NET Framework의 가장 하위에 있으며 .NET Framework클래스 라이브러리는 .NET Framework에서 공용언어 런타임을 제외한 나머지 요소들을 총체적으로 가리키는 것 입니다.
.NET Framework 클래스 라이브러리(.NET Framework Class Library)
공용언어 런타임(Common Language Runtime, CLR)
공용 언어 런타임은 우리가 .NET 언어로 코드를 작성할 때 일반적으로 신경써야 하는 부분들, 예를 들면 메모리 관리, 보안 관리, 오류 처리 등의 작업을 도와주어 프로그래밍을 단순화하는 역할을 할 뿐만 아니라 .NET Framework로 개발된 응용프로그램의 실행 환경을 제공합니다. 그래서 공용 언어 런타임을 코드 관리 환경이라고도 하며 코드 관리 환경에서 실행되는 코드를 관리 코드(Managed Code)라고 합니다.
.NET에서의 핵심이 .NET Framework라면 .NET Framework에서의 핵심은 바로 공용 언어 런타임입니다. 공용 언어 런타임은 .NET 언어의 내부 처리 프로세스와 관계가 깊으므로 .NET에서 PL(Programming Language)과 관련된 부분을 이야기하고자 한다면 이를 이야기 하는 것이라고 봐도 무방할 것입니다.
.NET Framework 클래스 라이브러리(.NET Framework Class Library)
.NET Framework 클래스 라이브러리는 개발자가 질 높은 응용 프로그램을 구현하거나 이미 개발된 응용 프로그램을 신속하게 확장할 수 있도록 도와주는 기능들을 미리 패키지화한 것을 말합니다. 여기에는 크게 네 가지 요소로 구성되어 있습니다.
1. ASP.NET(XML Web Service & Web Form)
2. Data and XML
3. Windows Forms
4. Base Class Library
1. ASP.NET은 웹 구현을 위해 사용되는 기능들을 미리 패키지화한 것이며 이것은 곧 하나의 웹 기술을 의미합니다. 물론, 여기에는 XML 웹 서비스 기술도 함께 포함되어 있습니다.
2. Data and XML이라고 되어 있는 부분은 .NET을 통해 만들어진 응용 프로그램이 데이터 소스(데이터베이스 또는 기타 다른 정보 저장 공간)와 원활히 연결될 수 있도록 도와주는 기능들을 미리 패키지화한 것입니다(ADO.NET).
3. Windows Forms는 Windows응용프로그램 개발을 위해 사용되는 기능들을 미리 패키지화한 것입니다.
4. Base Class Library는 위에서 언급한 .NET Framework의 세 가지 구성 요소(ASP.NET, Windows Forms, Data and XML)와 .NET Framework에서 공통적으로 사용하는 기능들을 패키지화한 것입니다.
Reference Book : 뇌를 자극하는 ASP.NET 2.0 프로그래밍 - 이시환
2008. 10. 16. 06:24 :: MFC
안녕하세요.
18-1 기 박상용입니다.
MFC... 다들 많이 아시죠? 깊이도 아실테고, 블로깅 할 필요가 없.......다고 생각했지만, 그래도 다들 많이 하시고 깊이 아시니 그만큼 이야기 할 주제도 많다고 생각이 들었습니다. (절대 할 줄 아는게 이거 뿐이라서가 아니라고 굳이 이야.....)
몇 주를 블로깅 할 지는 모르겠지만, 크게 두가지 주제로 블로깅을 할까 합니다.
- MFC 의 구조 및 관련 기술(ATL/RTTI, MFC 9.0)
- 그리고... MFC 에 관한 잡담들(장단점 및 삽질 일기)
그럼 이제 MFC 와 관련된 잡담으로 첫 블로깅을 시작해 볼까 합니다.
"왜 아직도 MFC 인가?"
사람들마다 입맛은 저마다 다른 것 같습니다. 뭐 먹는 것 뿐만 아니라 좋아하는 여배우, 여가수 라던가 좋아하는 색깔, 야구팀, 버스의 자리 등등 말이죠. 개발이라는 것을 할 때 쓰는 도구들도 각각 선호하는 쪽으로 많은 관심 밑 편(?)을 드는 것은 당연하다고 생각합니다. 자신이 선호하는 야구팀을 응원하듯 말이죠. 아직은 공부하는 학생이고 어디 회사에서 꼭 이것을 사용해서 이것을 개발 하라는 명령이 없으니 이러한 선호도는 개개인적으로 더더욱 커지는 것 같습니다(당연히 혼자 생각입니다).
MFC... 이제는 사양될만도 한 구 시대적 유물이 아니냐하는 생각부터 들게 하는 주제가 아니냐고 반기를 들수도 있겠습니다. 더욱, 새로운 것들이 쑴풍쑴풍 나오고 있는 요즘 시대에, 새로운 것을 쓰지않으면 난 뒤쳐진다라는 일종의 무언의 강박관념 때문에 나온지 10년이 넘어 가는 MFC 는 '낡은 기술' 이라는 눈도장이 찍히기 마련이죠.
그럼에도 불구 하고 왜 아직도 많은 개발회사에서는 Visual C++ 6.0 을 사용하고, 그런 가운데서도 MFC 일까요? 무조건 어렵고 코드의 양이 많은 것을 쓰면 프로그래밍 내공이 늘어 나는것도 아니고, 삽질 삽질을 거듭 할 수 없은 MFC 로 아직도 많은 이들이 좋은? 어플리케이션을 만들기 위해 날밤을 새어 삽질을 하고 있습니다(조금은 객관적인 생각입니다).
모든 것에는 이유가 있는 법! 크앙! 그럼 MFC 가 Window Programming 을 하기 좋은점 혹은 당위성?에 대해서 몇가지 이야기 해보겠습니다.
1. 노력하는 객체지향
장점을 찾자! 생각을 하고 시작은 했지만 딱히 생각이 나질 않네요. 그래서 만물박사 "뇌입원" 에게 물어 봤더니 다음 네가지를 이야기 했습니다.
- 효율성
- 안정성
- 재사용성
- 유지보수성
- 이식성
- 안정성
- 재사용성
- 유지보수성
- 이식성
어느 학원의 교재로 쓰일 법한 내용의 장점을 살펴 보니, 객체 지향의 장점과 유사한게 몇가지 있습니다. 그럼 과연 MFC 는 객체지향적 일까요?
그럼 MFC 는 근본적으로 무엇일까요? 그저 대표 이니셜만 때어서 보면 Microsoft Foundation Classes 라고 하는 라이브러리라고 하네요(http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library). 또한 MS 홈페이지에서는 MFC 의 Concept 을 다음과 같이 이야기 하네요(http://msdn.microsoft.com/ko-kr/library/583ya1kc(VS.80).aspx).
The Microsoft Foundation Class Library is an application framework for programming in Microsoft Windows. Written in C++, MFC provides much of the code necessary for managing windows, menus, and dialog boxes; performing basic input/output; storing collections of data objects; and so on.
하나의 언어나 Tool 이 아닌 Application Framework 라고 합니다. 그리고 또한 많은 코드들을 제공하는 "니네 마음데로 가져다 써라, 여기는 공짜? 부페다." 라고 하는거 같습니다. 단순히 UI 를 편하게 뽑아 내기 위해서(솔직히 편하지는 않지만요), 그저 내 코드를 재미없는(?) 커맨드 창 보다는 윈도우 창에 표현하기 위해서 MFC 가 존재 하는 것은 아닙니다. 그야 말로 윈도우 프로그래밍에 유용한 클래스 들의 집합체 일 뿐이죠.
또한 주목해 볼만한 문장은 Written In C++ 이라는 부분이네요. C++ 쓰여졌다는 군요 MFC 는...
그리고 위 섹션 다음에서는 다음과 같이 말하고 있습니다.
Given the nature of C++ class programming, it is easy to extend or override the basic functionality that the MFC framework supplies.
C++ 클래스 프로그래밍이라는, OOP 스타일의 프로그래밍을 하고 있다고 직접 명시 하고 있습니다.(http://en.wikipedia.org/wiki/Class-based_programming)
하지만, MFC는 위의 말데로 완전 C++ 문법으로 Class Base 의 구조로 되어 있는거 같지는 않습니다. 이유는 MFC 대부분이 Win32API 를 Wrapping 한 Class 형식으로 이루어져 있다는 것 입니다.
Greate 한 프로그램 예제
절대 귀찮아서 이런 프로그래ㅁㅁ니ㅏ러뭉ㄹ몰
아무튼 위와 같은 다얄로그를 띄우는 프로그램이 있다고 칩시다. 호출 스택을 살펴 보면 다음과 같습니다.
AfxWinMain 이라는 함수가 보입니다. Afx 를 제외하고는 눈에 익숙한 API 함수임을 알 수 있습니다.
API 에서도 하나의 기본적인 창을 띄우기 위해서는 WinMain 을 사용하고 첫 인자로 현재 Instance 핸들을 받으며 시작한다는 것은 다들 아실 겁니다. (http://msdn.microsoft.com/en-us/library/ms633559(VS.85).aspx)
그렇다면, Win32API 는 무엇으로 이루어 져있나요? extern "C" 에서 알 수 있듯이 API 함수들은 C 로 구성되어져 있습니다. 따라서 MFC 는 Windows API 함수들을 Wrapping 하되, 좀더(완벽히가 아님)OOP 적인 방법으로 구성 되어졌다고 볼 수 있습니다.
블로깅이 늦어 버렸네요 ;;;
내용을 재미 있게 이어 나갈라니 정말 제가 모르는 부분 투성이라 이게 맞는지 아닌지 검증하고 찾아 보는 시간이 더 걸리는거 같습니다 -_-;; 죄송합니다 (__)
꼭 주중에 나머지 부분을 완성하고, 요기 내용도 수정해서 마저 올리겠습니다 -_-;
지혜야 벌금 가져가 ;;
