Software Magic !

Review 동기 : 나는 Software Engineering에 대해 관심이 많음에도 불구하고, 현재까지 개발된 Software Engineering 기술에 대해 너무 소홀했다.

Review 목적 : 현재 가장 많이 사용되고 있는 Software Engineering 기법인 UML을 살펴봄으로써 내가 가진 지식의 폭을 넓이고, 생산성을 높일 수 있는 방안을 고민하는 것이다.

UML(Unified Modelling Language)

UML은 S/W Modelling만을 위해 만들어진 언어는 아니다. 일반적인 System을 기술하기 위해서 만들어진 일종의 언어이며, 이것이 S/W Modelling에 적합하기 때문에 많은 S/W Engineer들이 이러한 기법을 사용하고 있다. (IBM Rational이 개발한 Model이다.)

UML은 System의 명세를 기술하기 위한 다양한 Diagram들로 이루어져 있다. 이들 Diagram들을 반드시 다 사용할 필요는 없으며, 필요에 따라 적절한 Diagram을 선택하여 사용하면 된다.

Use-Case Diagram

설계하고자 하는 시스템이 제공할 기능을 전체적으로 도식화한다. Actor(사용자, 혹은 컴퓨터)와 UseCase들로 구성되며, Actor혹은 UseCase간의 관계가 명시된다. (예를 들면, 어떤 UseCase는 다른 UseCase를 사용한다든가 하는). 뿐만 아니라, 각 UseCase들이 만족해야 할 조건들(pre-condition, post-condition, invariants)들을 기술할 수 있으며, 다른 Diagram들과 연관될 수 있다.

(Implementation Diagram, Sequential Diagram and so on)

Sequential Diagram

개별 UseCase들의 작업이 구체적으로 어떻게 수행되는지를 Event Model로 나타낸 것이다. Actor와 시스템을 구성하는 Component들이 서로 어떤 Message를 주고 받으며, 어떤 작업을 수행하는 지를 시간축을 따라 기술된다. 하나의 UseCase에 대해 여러개의 Sequential Diagram이 작성될 수 있다.

Implementation Diagram

UseCase들을 어떻게 구현할 것인지에 대한 문서이다. UseCase를 중심으로, 이 UseCase를 구현하는 Component들은 무엇무엇이며, 이 UseCase는 어떤 Requirement Document에 기반하고 있는지, UseCase의 LookAndFeel은 어떤 식으로 구성되는지에 대한 총괄적인 문서들을 포함한다.

**My Comment: 이러한 Diagram들을 구체적인 Software Architecture나 Code로 변환하는 것은 쉽지 않아 보인다. 왜냐하면, 위에서 설명한 Diagram들은 아직까지 컴퓨터가 이해하기에는 너무 Informal하기 때문이다. 그렇다면, 위의 모델은 S/W 작성의 참조 자료로 사용될 뿐이고, 실제 S/W의 논리적인 구조(Software Architecture)를 기술하는 Standard Diagram이 있을 것이다. 이러한 표준화된 Model은 좀 더 쉽게 (여전히 어렵겠지만) 실제 코드로 변환될 수 있을 것 같다.

The logical model(Class Model)

이 부분은 두 가지 종류로 나눌 수 있다. 하나는 Domain Model이고 다른 하나는 Class Model이 다. 이 중 Class Model은 가장 널리 쓰이는 모델로서 현재 널리 쓰이고 있는 Java/C++에서 찾아볼 수 있는 Object Oriented Programming Model이 바로 이것이다. Class Model은 시스템을 구성하는 객체들을 정적으로 기술한다. Class는 객체들의 특징을 기술하며, 객체는 어떤 class의 instance로 생성된다. class는 attribute(데이터 부분)과 methods(데이터에 대한 각종 작업)로 구성되며, 각 class 구성 요소들은 private, protected, public의 속성을 가질 수 있다. 또한 class간의 상속이 가능하다. 이 모델은 현재 널리 사용되고 있는 OOP 모델과 동일하므로 구체적인 설명은 생략한다.

** Domain Model은 Business Object들을 좀 더 high level에서 기술한 것이라고 하는데, 자세한 설명을 찾을 수가 없었다. 자료가 조사되면 나중에 추가하도록 하겠다. ####

** My comment : C++/Java 소스 코드를 입력으로 받아서 class 속성 및 class간의 관계 구조를 그래프로 표시해주는 프로그램들이 다수 존재한다. 반대로 Object들과 그들 사이의 관계 구조를 graphically 기술해주면 그것을 소스 코드(혹은 그냥 framework)으로 변환해주는 프로그램도 있다. 아직까지 Software Synthesis를 만족할 만한 수준으로 자동화한 예는 찾아볼 수 없다. (특정 분야를 제외하고는, ex) Business Application, Speciallized Scientific Application and so on).

Actvitiy Diagram

Sequential Diagram과 같이 동적 모델링을 위한 다이어그램이다. 이 다이어그램은 작업이 시작하여, 어떤 활동들을 거쳐서 종료하는지를 나타냄으로써 시스템이 제공하는 워크플로우를 모델링 한다. 노드들은 작업을 수행하는 데 필요한 동작들을 나타내며, 이 동작들의 수행 순서를 제어하는 조건문들이 존재할 수 있다. (간단하게 플로우챠트와 같은 개념이라고 생각할 수 있다. "동작"이라는 큰 단위가 노드를 구성하므로, 일반적으로 우리가 생각하는 플로우챠트보다는 약간 상위 개념이다.) ** 자동으로 코드로 변환될 수 있을 것 같지는 않다. 하지만, 워크플로우의 순서를 일목요연하게 표현할 수 있고, 병렬로 수행이 가능한 부분들을 파악할 수 있다는 장점이 있다.

State Chart

개별 Object들의 state들이 어떻게 전이(transition)하는 지를 나타낸다. Object 단위이므로 상당히 세부 설계에 해당하는 것 같다.

** Association of all the diagrams **

위에서는 그저 개별 Diagram들의 역할에 대해서만 설명했다. 하지만, Modelling 기법의 강점은 다양한 Diagram들이 서로 연결됨으로써 발휘된다. 그렇다면 UML이 제공하는 Diagram 들이 어떻게 서로 연결될 수 있는 지를 고민해 보자.

S/W를 개발하는데 있어 가장 먼저 하는 것은 아마도, 시스템을 사용하는 시나리오를 작성하는 것일 것이다. 따라서 제일 먼저 작성하는 것은 Use-Case Diagram이 된다. 이 Use-Case Diagram은 시스템의 전체 기능에 대해서 알려주지만, 각각의 Use-Case들이 어떻게 작업을 처리하는지에 대해서는 설명하지 않는다. 각각의 Use-Case에 대해 Sequential Diagram을 연결하여 이 문제를 해결할 수 있다. 즉, Use-Case <--> Sequential Diagram 이다.

Sequential Diagram외에 Activity Diagram을 이용하여 Workflow를 기술할 수도 있다. Activity Diagram은 하나의 Workflow를 좀 더 작은 activity들로 분할하는데 유리하다. Use-Case <--> Activity Diagram. 그렇다면 Activity Diagram과 Sequential Diagram 사이에는 어떤 연관성이 있을까? 일단 Activity는 Use-Case보다는 좀더 세분화된 개념으로 보인다. Use-Case는 그 자체로 하나의 시나리오를 구성할 수 있지만, Activity는 그 자체만으로는 Service Scenario를 구성할 수 없다. 그렇다면 이 activity라는 것은 sequential diagram에서 message에 의해 요청되거나 수행되는 작업을 의미한다고 볼 수 있다. 그렇게 볼 경우, activity diagram은 sequential diagram의 또 다른 형태라고 할 수 있다. sequential diagram이 시간에 따른 message 전달과, 작업의 순서에 초점에 맞추었다면, activity diagram은 작업들 간의 의존성 및 수행조건에 초점을 맞추었다고 볼 수 있다.

Implementation Diagram은 Use-Case를 각각 어떻게 구현할 것인가에 대한 문서이다. 따라서 Use-Case는 Implementation Diagram에 의해 보충된다. 또한 Implementation Diagram에 포함된 각각의 Component들은 다시 Class model이나 Component Model에 의해 상세히 기술될 수 있다. 여기에서 기술되는 Class Model은 바로 코드로 변환될 수 있는 상세 설계 명세이다.

그러면 State Chart의 역할이 여기에서 궁금해지는데, State Chart는 개별 object를 기술하므로, 아무래도 Class Model에 연관되는 것이 자연스럽다. 혹은 Object들이 구성요소로 포함되는 Sequential Diagram에도 연관될 수 있다.

아직 UML Model에 대한 이해가 깊지 않아서 그런지, UML의 잠재적인 능력을 제대로 파악할 수 없는 것 같다. 계속 공부를 해나가면서 이해의 폭이 넓어지면, UML의 장점과 단점들이 서서히 파악될 것 같다.