Software Magic !

올해 내가 공부해서 알게 된 것들..

XML, XML Namespace, Xerces Parser (SAX Model, DOM Model)
RDF(Resource Description Framework), RDF Schema,
UML(Unified Modeling Language),
RSS(RDF Site Summary or Really Simple Syndication),
Web Service Standards
SOAP-Simple Object Access Protocol
WSDL-Web Service Description Language
UDDI-Universal Description, Discovery and Integration
and so on

이것들을 조합해서 어떤 작품들을 만들어 낼 수 있을까 고민을 해봐야 겠다.

XML은 데이터를 표현하기 위한 표준 방법이다. 프로그램을 작성할 때 File 입/출력을 XML 형식으로 하면 Interoperability(호환성)을 확보할 수 있다.

RDF는 원래 Web Resource에 대한 Metadata를 기술하기 위한 것이다. XML 형식으로 표현되며, (Resource, Property, Value)의 Triple이 기본 구성요소이다. RDF는 굳이 Web Resource가 아니더라도 활용할 수 있다. 예를 들어, 내가 작성하는 프로그램에 대한 Metadata를 RDF로 표현할 수도 있다. 그것이 어떻게 활용될지는 잘 모르겠지만 (프로그램도 하나의 Web Resource로 생각할 수도 있겠다. Internet에 공개될 것이므로)

Web Service API는 프로그램이 Web과 소통하는 통로를 열어준다. Web 업체들이 제공하는 Open API를 사용하여 프로그램이 Standalone으로 동작할 뿐만 아니라 Internet과 연동하여 다양한 추가 기능을 제공할 수도 있다. 프로그램이 서버로 동작하여 Open API를 외부에 제공할 수도 있을 것이다. 아니면 프로그램 자체를 Web Service API를 이용하여 작성하는 것도 생각할 수 있다. PC에 Web Service 동작환경(주로 Apache-Tomcat-Axis 조합)을 설치하고, 프로그램의 기능들을 Web Service API로 구현한다. 최종 프로그램은 이러한 Web Service API를 조합하여 사용자 Interface를 제공하게 된다. 마지막 경우에서는 개인 PC에서 제공하는 API와 외부 Internet에서 제공하는 API가 동일한 것으로 취급된다. 즉, 프로그래밍의 영역이 Web 전체가 되는 것이다

1. use case diagram : To model the main functionality of a system and the role of user.

2. class/object diagram : To model static structure of a system.

3. statechart : to model object(system) states and their transitions.

4. activity diagram : to model dynamic behaviour of the model.

5. sequency diagram : to model message passing between entities.

6. collaboration diagrams : to model interaction between objects over time.

7. component diagram : to model concrete software unit and their interrelations.

8. deployment diagram : to model the arrangement of run-time components on run-time resources.

9. package concept : decompose a complex model into simpler sub-models.
(divide and conquer)

** 프로그램을 설계할 때 여러가지 요소들을 동시에 고려하는 것은 어렵다. 따라서 각각의 요소들을 개별적으로 고려하고, 나중에 이러한 요소들을 합치는 것이 효과적인 방법이다. 예를 들어, 어떤 프로그램을 개발할 때 프로그램의 정확성 (correctness), 효율성 (efficiency), 필요성 (necessity)를 한꺼번에 생각한다고 해보자. 보통 사람들은 이렇게 다양한 관점들을 동시에 고려하지 못한다. The separation of concerns 원리는 이러한 관점들을 따로 고민하라는 것이다. 즉, 먼저 필요성을 고민하고, 그 다음 정확성을 그리고 나서 효율성을 고민하라는 것이다.

** Divide and conquer 와 비슷한 뜻인듯

** Software Modeling에서 매우 중요하게 생각하는 원리중의 하나이다.

Origin : From Wikipedia,

The term separation of concerns was probably coined by Edsger W. Dijkstra in his paper On the role of scientific thought.

Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained --on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focussing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.

1. 소프트웨어를 개발하여 출시하고 나면 어떤 현상이 발생하는가?

"네? 4번 메뉴를 클릭하면 프로그램이 죽는다구요?"

"교차로에서 지도 표시가 제대로 안된다고 하는데, 이게 재현이 가능한가요?"

"어제는 잘 돌아갔는데, 오늘은 죽네요."

"DB 연결 모듈에서 오류가 발생하는 것 같은데요? 네? DB 연결 모듈은 아무 이상 없다고요?"

"BF존에서 캐릭터가 자주 다운된다는데, 회사 서버에서는 재현이 안되요."

...

2. 에러의 원인이 무엇인지 자동으로 알 수는 없을까?

--> 어떤 S/W component가 오류를 발생시키는가?
--> 해당 S/W component의 어느 부분이 오류를 발생시키는가?
(오류 Localization 문제)

오류 정보를 Data Mining하여 발생한 오류와 동작중인 S/W 모듈들의 연관관계를 파악하면
도움이 될 것 같다.

예를 들어, A라는 소프트웨어에서 계속해서 "비정상 종료" 보고가 올라오는데, 이 경우, 항상
B라는 DLL이 같이 동작하고 있다면, A S/W와 B DLL 사이의 충돌이 있을 가능성이 매우 높다.


3. 프로그램을 개발하면서 자주 접하는 버그들
1. memory leakage
- 메모리를 Heap에서 할당한 후, 해제하지 않아 계속해서 메모리 사용량이 증가하는 문제
프로그램 실행 직후에는 잘 감지되지 않고, 시간이 좀 지나야 문제를 발생시킴. 예를 들어
1시간에 4MB memory leak이 발생한다면, 4GB 메모리를 가진 시스템에서는 1000시간 후에
메모리 부족 문제가 발생하게 됨.

2. dangling pointer
- 포인터가 이미 삭제된 데이터 오브젝트를 가리키는 경우. 오브젝트가 사용하던 메모리
영역이 재사용되지 않고 유지되는 경우에는 포인터로 데이터를 사용해도 별 문제가 발생
하지 않음 (물론 이렇게 하는 것 자체가 잘못된 것임) 하지만, 재사용되는 경우에는 illegal
memory access 문제가 발생함. memory leakage와 마찬가지로 찾아내기 힘든 버그임.

3. array bound violation (배열 영역 벗어나는 경우)
- 배열을 선언하고, 사용하는 과정에서 배열의 index 범위를 벗어나는 경우에 발생하는 문제
이다. 다행이도 최근 컴파일러나 디버거는 이러한 문제들을 미리 검사하여 경고를 해준다.
하지만, 배열이 동적으로 할당되는 경우(Heap에서)에는 걸러지지 않는다. 배열 접근 시
index의 범위를 항상 검사하여 안전성을 확보하는 것이 좋다.

4. endless loop (무한 루프)
- For 혹은 While 같은 제어문의 조건식이 항상 참이 되는 경우이다. 이 경우 프로그램은
종료되지 않고, 같은 코드를 무한히 반복 수행한다. Endless loop 때문에 앞에서 말한
Memory leakage 문제나 array bound violation 문제가 발생할 수도 있다.

블로그 > 바람의 칭칭
http://blog.naver.com/jsham76/100027058657

UML은 Unified Modeling Language의 약자입니다. 그럼 UML에 대하여 구체적으로 살펴볼까요? UML은 Unified 체계입니다. Unified란 단어는 기존의 여러 방법론에서 사용되어 오던 표기법들을 통합한 것이라는 의미로 사용되었습니다. UML은 새롭게 창조되어 생소하고 검증이 덜 된 체계가 아니라, 기존에 사용되던 안정되고 검증된 표기체계들을 이어받고 통합한 것입니다. 물론 기존에 사용되던 체계 그대로가 아니라 많은 부분을 발전적으로 수정하고 보완한 완성도 높은 체계입니다. UML은 Modeling Language입니다. UML은 복잡한 방법론(Methodology)이 아닙니다. 방법론은 SW개발과정 중에 따라야 할 절차와 기법과 도구를 제시하는 것이지만, 모델링을 위한 표기체계, 즉 언어(Language)라고 합니다. 그리고 언어이기에 구성요소와 룰과 원칙(문법)이 존재하지만 그 적용분야가 제한되지 않습니다. 이러한 이유로 UML은 여러 다양한 방법론에서 응용할 수 있는 범용성 높은 모델링 언어이고, SW 분야뿐 아니라 모델링이 필요한 모든 분야에 적용이 가능한 것입니다.

UML의 특징은 다음과 같습니다. 가시화 언어("Language for Visualizing", The UML User's Guide) UML은 여러 개의 그래픽 기호로 구성되어 있으며 각 기호들은 정확한 의미를 가지고 있습니다. 그러므로, UML로 모델링한 것은 통일된 의미를 갖기 때문에 UML로 작성된 문서를 보는 사람들은 시스템에 대해 동일한 의미를 공유할 수 있게 됩니다. 명세화 언어("Language for Specifying", The UML User's Guide) 명세화란 정확하고, 명백하며, 완전한 모델을 의미하는데, UML은 분석, 설계, 구현에서의 모든 중요한 결정에 대한 명세서를 다룰 수 있게 합니다. 구축하는 언어("Language for Constructing", The UML User's Guide) UML 언어에서는 프로그래밍 코드를 생성하는 것이 가능하고, 또한 구현된 코드로부터 UML 모델을 다시 생성할 수 있는 역공학(reverse engineering)도 가능합니다. 문서화 언어("Language for Documenting"- The UML User's Guide) UML은 시스템 구조와 그것의 모든 상세 내역에 대한 문서화를 다루며, 요구사항을 표현하고 시스템을 시험하는 언어와 프로젝트 계획과 배포관리 액티비티를 모델링하는 기능을 제공합니다. UML 이전의 모델링 체계 OMT는 James Rumbaugh가 GE 프로젝트들을 수행한 경험을 토대로 개발한 객체지향 모델링 체계입니다. 이것은 1990년 "Object-Oriented Modeling and Design" 출간함으로써 세상에 소개되었으며, 발표 이후 UML에 통합되기 전까지 전 세계에 걸쳐 가장 널리 적용된 객체지향 모델링 체계 중 하나입니다. 그리고 시스템의 표현을 위한 다음과 같은 다양한 모델들을 제공하여 완전한 모델링의 구축을 추구하였습니다. 시스템의 표현을 위한 모델링에 대하여 자세히 살펴봅시다. 객체 모델(Object Model) 시스템의 기능구현을 위해 식별된 모든 클래스와 클래스 간의 정적인 관계를 표현한 모델입니다. 이 모델은 시간과 사건의 개념이 포함되지 않고, 모든 객체가 하나의 평면에 표현되기 때문에 정적모델이라고 하는 이것은 어떻게 정의해야 할까요? 객체모델을 정의하기 위해서는 다음 순서의 일을 수행해야 합니다. ※ 깜박이는 화살표를 클릭하세요. 동적 모델(Dynamic Model) 시스템의 특정 기능에 참여하는 객체들과 객체간 동적 상호관계를 표현한 모델입니다. 이 모델은 시간과 사건에 따른 객체의 순서적 행위를 표현하기 때문에 동적 모델이라고 합니다. 동적 모델에는 객체 자체와 객체의 상태 그리고 기능을 유발하는 사건과 기능을 수행하는 시간개념이 포함됩니다. 기능 모델(Functional Model) 시스템이 어떠한 기능을 수행해야 하는 지를 나타내는 모델입니다. 이 모델은 객체와 객체간 메시지 교환을 통해 기능이 어떤 방식으로 구현될 지에 대해 설명합니다. Grady Booch가 국방, 상업 등 대규모 시스템들에 대한 개발 경험을 기반으로 정립한 모델링 체계입니다. 이것은 90년 초반에 저서 "Object-oriented Analysis and Design with Applications"을 출간함으로써 Booch Method가 소개되었습니다. Booch Method의 특징은 다음과 같습니다. 시스템 아키텍처에 초점 시스템의 구성요소 및 구성요소와 구성요소간 관계와 상호작용을 정의한 아키텍쳐를 중시한 모델링 체계를 제시하였습니다. 시스템을 다양한 관점에서 분석하는 개념을 제시 여러 종류의 모델링 방법을 제시함으로써 시스템을 다양한 관점에서 분석할 수 있게 하였습니다. 이러한 모델링 관점의 다양화는 보다 완전한 모델 구축을 가능하게 합니다. 반복적이고, 점증적인 개발 프로세스 제시 시스템을 개발할 때 과거와 같이 한번에 개발하는 대신, 작은 영역으로 쪼개어 여러 번에 걸쳐 나누어 개발하는 방식을 주창하였습니다. 이 방식은 개발과정에 숨겨져 있는 위험(Risk)들을 조기에 발견하여 대처하게 함으로써 시스템 개발이 실패할 위험을 줄여줍니다. OOSE (Object-Oriented Software Engineering)는 Ivar Jacobson에 의해 제안된 객체지향 개발 방법론입니다. Objectory는 통신, 금융 분야에서의 Ivar Jacobson의 방법론에 기반하여 다양한 시스템에 적용된 방법입니다. OOSE/Objectory 방법론의 특징은 유스케이스 중심 접근법 (Use-Case Driven Approach)으로 대표됩니다. 유스케이스 모델을 간단히 소개하면, 시스템 개발 초기단계에 작성되어 다른 모든 모델을 유도해 내는 기준 모델이라고 합니다. 즉, 유스케이스 모델은 시스템과 상호 작용하는 방식들을 파악하여 시스템의 모든 기능들을 서술하는 것이라고 할 수 있습니다. UML의 탄생과정과 의의 UML은 1997년 표준으로 채택되었지만, 기존 방법론들의 장점들을 취합한 표기체계입니다. UML이전에도 객체지향 기반의 모델링 체계를 포함한 방법론들이 많이 존재했었지만, 너무 많아서 문제가 있었습니다. 많은 개발자들이 모델링 체계가 달라 의사소통에 불편을 느끼게 되었기 때문입니다. 그래서 자연스럽게 하나의 표준 표기체계가 필요하다는 것을 느끼게 되었습니다. 통합되고 표준화된 객체지향 표기체계의 필요성이 대두되던 이 시점에 UML이 등장하게 된 것입니다. 1960년대부터 현재에 이르기까지 UML의 탄생과 발정과정을 아래의 표와 그림으로 살펴봅시다. 1967년 최초의 객체지향 언어 SIMULA 탄생 1980년대와 90년대 초반 다양한 객체지향기반 표기체계 및 방법론(약 50여 가지)이 난립 1995년 Booch의 Booch 방법론과 Rumbaugh의 OMT방법론이 통합 객체지향 학술대회인 OOPSLA('95)에 발표 1996년 Jacobson의 OOSE 방법론이 추가로 통합 대표적인 3대 방법론에서 쓰이던 표기체계가 통합됨 UML(Unified Modeling Language)로 명명되어 v 0.9로 정의 1997년 1월 : UML ver. 1.0 발표 9월 : UML ver. 1.1 발표 객체지향 기술표준 기구인 OMG에 표준화안 상정 11월 : OMG 표준 인증 1999년 UML ver. 1.3 발표 2001년 UML ver. 1.4 발표 2002년 UML ver. 2.0 예정 * OMG : Objec Management Group. "www.omg.org" 1997년 UML은 버전 1.0이 OMG(Objec Management Group."www.omg.org")의 표준인증을 획득하여 객체지향 모델링 체계의 세계 표준이 되었습니다. UML은 다음과 같은 의의를 가집니다. 표기체계의 통합 및 표준화 1980년대에서 90년대에는 50여 가지의 표기체계가 난립하였습니다. UML은 이러한 표기체계를 하나로 통합함으로써 표준화의 대업을 이루었습니다. UML은 개인이나 기업이 아닌 비영리 표준화 단체인 OMG에 의해 사양과 업그레이드가 관리되며, 이것의 등장으로 재사용과 원할한 의사소통 효과를 비롯한 많은 효과를 기대할 수 있게 된 것입니다. 개발 프로세스와 개발언어에 독립적 표기체계 UML은 특정 개발방법론에 얽매이지 않은 개방적인 표기체계를 제시하였습니다. 방법론에 독립적일 뿐 아니라 개발언어의 물리적 제한사항을 수용하는 추상성을 제공하는 표기체계를 채택함으로써 개발언어에도 독립적입니다. 따라서 우리는 UML의 등장으로 개발 방법론과 개발언어에 제한없이 적용될 수 있는 개방적인 모델링 체계를 갖게 된 것입니다. 적용에 제한이 없는 범용적 표기체계 UML은 적용하기 위한 별도의 비용이나 허가가 필요없는 공개된 표준 모델링 체계를 제공합니다. UML을 사용하기 위한 제한된 조건은 없으며, 이것의 등장함으로써 우리는 SW시스템의 개발과정뿐 아니라 비즈니스 영역을 비롯한 적용가능한 모든 분야에서 폭넓게 응용할 수 있는 범용적인 표기체계를 갖게 된 것입니다.