• 개요

  스테이트차트 다이어그램은 "하나의 객체를 대상으로 생존기간 동안 가질 수 있는 객체 상태의 변화를 분석한 다이어그램"입니다.

   

  

  스테이트차트 다이어그램은 객체 상태와 함께 객체 상태 변화를 유발하는 이벤트와 동작 (Action/Activity)도 함께 정의합니다. 이러한 요소가 정의된 스테이트차트 다이어그램을 통해 "객체 O는 이벤트 E에 의해 상태 S로 변화하고 그 상태에서 A라는 행위를 한다" 라는 식의 분석을 수행할 수 있습니다.

• 목적

  스테이트차트 다이어그램을 작성하는 목적과 용도는 다음과 같습니다.

  • 객체의 상태변화를 상세히 분석합니다.

    스테이트차트 다이어그램은 객체 하나를 대상으로 생성-소멸기간중에 다양하게 가질 수 있는 상태(State)를 분석하는 목적으로 작성됩니다. 정보시스템에서 많은 객체는 생성되어 소멸될 때까지 간단한 상태를 가지지만 일부는 매우 복잡한 상태로 변화하면서 존재합니다. 스테이트차트 다이어그램은 이렇게 객체의 동적 상태변화를 정의하고 분석하는 목적으로 사용합니다.

  • event에 의한 객체의 반응을 분석합니다.

    스테이트차트 다이어그램은 객체 상태 변화를 유발하는 이벤트를 정의하고 분석하는 목적으로도 작성됩니다. 객체의 상태는 그냥 변하는 것이 아니라 이벤트에 의해 변화합니다. 이러한 객체의 상태변화를 유발하는 이벤트를 식별하고 상세히 정의합니다.

  • 객체의 속성이나 오퍼레이션을 검증합니다.

    스테이트차트 다이어그램은 객체가 가지는 속성과 오퍼레이션을 검증하는 목적으로 작성되기도 합니다. 스테이트차트 다이어그램에서 분석대상인 객체의 상태는 속성의 값으로 정의되고, 이벤트는 대부분 객체의 오퍼레이션으로 정의됩니다. 따라서 클래스 다이어그램 등에서 정의된 클래스의 속성과 오퍼레이션의 적합성을 검증할 수 있습니다.

     

• 구성

  스테이트차트 다이어그램의 구성요소는 다음과 같습니다.
  

  
  
  
  
  
  
  • 시작상태(Initial state), 종료상태(Final State)

    	표기	의미
    시작 상태	시각점은 속이 꽉 채워진 원으로 표기	시작 상태는 객체의 상태변화가 시작되는 곳을 의미합니다. 보통 객체의 생성시점이 시작상태가 됩니다.
    종료 상태	속이 채워진 원에 바깥의 또 다른 원이 둘러싸고 있는 모양으로 표기	종료 상태는 객체 상태변화가 종료하는 곳을 의미합니다. 보통 객체의 소멸시점이 종료상태가 됩니다.

     

  • 상태(State)
    • 상태의 의미
      • 상태란 객체가 가질 수 있는 조건이나 상황입니다.
      • 생명주기 동안 객체의 상태는 변화하며, 상태는 객체의 특정한 속성의 값으로 표현됩니다.
      • 예) 자동차 객체의 상태 : "주차" , "주행" , "정차" , "수리"
    • 표기법

기본형 표기	상세형 표기
- 모서리 둥근 사각형으로 표기 - 상태 명은 심볼 내에 표기	- 수평으로 구분된 모서리 둥근 사각형으로 표기 - 상태 명은 위쪽부분에, 동작과 그 외의 부분은 아랫 부분에 표기

• 진입 동작(Entry Action)

  상태에 들어올 때 수행되는 동작을 정의합니다.

• 탈출 동작(Exit Action)

  상태에 나갈 때 수행되는 동작을 표기합니다.

• 내부전이(Internal Transition)

  현재 상태에서 처리할 수 있는 이벤트가 발생할 경우 상태를 떠나지 않고 해당 사건을 처리하는 경우입니다.

• 활동(Activity/Action)

  현 상태에서 수행할 동작을 표현합니다.

• 지연 사건 (Deferred event)

  현 상태를 빠져 나갈 때 발생한 것처럼 그 효과를 지연시킨 이벤트입니다. 위 예에서 Tracking 상태에서 selfTest 이벤트가 발생하면 이것을 메시지 큐에 저장 했다가, Tracking 상태에서 벗어나는 순간 이벤트가 활성화 됩니다.

   

• 전이(Transition)

  전이란 하나의 상태에서 다른 상태로 변화하는 것이며 상태 간의 관계를 의미합니다.

  • 표기법
    • 전이는 상태와 상태 사이에 화살표가 달린 실선으로 표기합니다.
    • 선 위에는 촉발사건(Event Trigger), 조건(Condition), 동작(Action)이 차례로 표기됩니다.
    • 위 세 가지 표기내용은 각각 생략될 수 있습니다.

       

      

       

       

  • 원래 상태(Source State)

    전이가 실행되기 전의 객체 상태

  • 촉발 사건(Event Trigger)

    전이를 촉발시키는 사건

  • 전이 조건(Condition)

    전이 촉발 시에 검토되는 Boolean 식 (참일 경우에만 전이가 수행됨)

  • 동작(Action)

    전이 도중 실행되는 행위 또는 오퍼레이션

  • 목표 상태(Target State)

    전이가 완료된 후의 객체 상태

   

• 주의사항
  • 객체 하나에 대한 상태 변화를 표현합니다.

    스테이트차트 다이어그램의 작성 중에 상태에 집중하다 보면 객체라는 한계를 벗어나는 경우가 종종 있습니다. 객체 하나의 상태변화와 여기에 관계된 이벤트들을 모델링하다는 본질에서 벗어나면 안됩니다.

  • 블랙홀 상태(State)를 주의합니다.

    스테이트차트 다이어그램에 표현된 상태는 들어오는 전이와 나가는 전이가 모두 정의되어야 합니다. 만약 들어오는 전이만 있고, 나가는 전이가 없을 경우, 그 상태는 블랙홀이 됩니다. 이런 실수를 하면 객체가 종료 상태에 이르지 못하고 무한 루프를 수행하는 오류를 범하게 됩니다. 항상 모델을 끝내면 이런 실수가 있지 않나 검증해야 합니다.

  • 클래스 다이어그램 및 시퀀스 다이어그램과의 일관성에 유의합니다.

    스테이트차트 다이어그램을 작성 완료한 후 새롭게 정의된 오퍼레이션과 속성은 클래스 다이어그램와 시퀀스 다이어그램에 반영되어 일관성을 유지해야 합니다. 그런 작업을 하지 않을 경우, 모델들을 전체적으로 신뢰할 수 없게 됩니다.

1. 개요

   디플로이먼트 다이어그램은 "시스템을 구성하는HW 자원 간의 연결 관계를 표현하고, HW 자원에 대한SW 컴포넌트의 배치 상태를 표현한 다이어그램." 입니다.

   그리고 디플로이먼트 다이어그램은 시스템의 설계 단계의 마지막에 작성합니다. 즉, 모든 설계가 거의 마무리되어 SW 컴포넌트가 정의되고, 시스템의 HW 사양도 확정된 후 디플로이먼트 다이어그램이 작성될 수 있습니다. (항상 그런 것은 아니고 상황에 따라 변경이 됩니다.)

    

2. 목적

   디플로이언트 다이어그램 작성하는 목적은 다음과 같습니다.

   1. SW시스템이 배치, 실행될 HW자원들을 정의합니다.

      디플로이먼트 다이어그램은 다른 UML 다이어그램들과는 달리 HW자원들을 명시적으로 정의하는 용도로 작성됩니다. 그러나 이렇게 HW를 정의하는 목적이 HW 자체의 사양을 정의하고 설명하기 위한 것은 아닙니다. 오히려 SW 시스템이 탑재되어 동작하는 매개체로서, HW자원을 정의한다라는 관점에서 정의합니다.

       

   2. SW 컴포넌트가 어떤 HW 자원에 탑재되어 실행될지 정의합니다.

      디플로이먼트 다이어그램은 실행모듈(컴포넌트)을 분산된 HW자원에 적절히 배치하여 원하는 성능과 효율을 낼지를 정의하는 목적으로 작성됩니다. 따라서 디플로이먼트 다이어그램에는 SW자원과 HW자원이 동시에 표현됩니다.

       

   3. HW 자원의 물리적인 구성을 정의합니다.

      SW컴포넌트가 탑재된 HW자원들은 적절한 성능을 내기 위해 물리적인 연결을 가지고 있어야 합니다. 디플로이먼트 다이어그램은 어떤 HW자원간에 연결이 있는지, 그 연결은 어떠한 성능을 가진 연결인지를 정의합니다.

       

3. 구성요소

   디플로이먼트 다이어그램의 구성요소는 다음과 같습니다.

   1. Things 혹은 심볼 : 노드(Node), 컴포넌트(Component)
   2. Relationships : Connection, Dependency

    

   
   1. 노드
      
      노드는 직육면체로 표기하며, 노드 명은 심볼 내에 표기합니다.

      노드는 SW 컴포넌트가 탑재되어 처리되는데 관련된 HW 자원을 의미합니다. 주로 연산능력(computing power)이 있는 HW 즉, SW를 탑재하여 운용할 수 있는 능력을 가진 하드웨어가 표현됩니다. 그러나 표현할 수 있는 HW 자원의 종류가 제한된 것은 아니고, 아래와 같은 다양한 장비들이 노드로 정의될 수 있습니다.

      [HW 장비들의 예]

      Sensor, Printers ,Card readers, Communication devices, Mechanical processing resources

      [노드의 예]

      Web Server, DB Server

       

   2. 컴포넌트
      
      컴포넌트는 탭이 달린 직사각형으로 표기하며, 컴포넌트 명은 심볼 내에 표기합니다.

      컴포넌트는 독립적으로 배포되고 교체되며 재사용될 수 있는 SW조각를 의미합니다. 보통의 경우 실행모듈을 말하지만, 실제 통용되는 컴포넌트라는 용어는 항상 실행모듈만을 가리키지는 않습니다. 컴포넌트가 가끔은 아주 광의로 사용되어서 소스코드나 UI(User Interface), 분석, 설계 산출물들을 포함한 것을 의미하기도 합니다. 컴포넌트라는 용어의 의미는 문맥에서 말하는 사람의 의도를 생각해서 받아 들여야 합니다.

      [컴포넌트의 예]

      결재 시스템에서 결재, 사원 등, 전자 상거래 시스템에서 우편번호 검색, 신용카드 결재 등

       

   3. 연결

      Connection의 표기
      

      
      노드를 연결하는 실선으로 표기하며, 연결의 물리적 특성을 Stereo type으로 표기할 수 있습니다.

       

      Connection의 정의

      두 노드 사이의 물리적인 연결을 의미합니다. 두 노드 사이의 물리적인 연결 특성을 설명합니다.

       

   4. 의존관계

      Dependency의 표기

      
      점선 화살표로 표현하고 필요에 따라 선 위에 설명을 붙이기도 합니다.

       

      Dependency의 정의

      객체나 컴포넌트가 다른 객체나 컴포넌트의 실행을 요청하는 경우, 즉 사물간의 실행 혹은 참조관계를 표현합니다.

      Class와 Class, Package와 package, Component와 Component에 주로 사용되는 관계이고, 때로는 Class-Package-Component 상호 간에도 사용되는 관계입니다.

       

4. 주의사항
   1. 목적을 전달할 수 있는 명확한 의미의 명칭을 부여해야 합니다.
   2. 노드 명과 스테레오 타입으로 정의하는 하드웨어 특성등은 표현 방식에 기준이 없습니다. 하지만 시스템과 관련없는 제 3 자가 보더라도 그 의미를 이해 할 수 있게 쉽고, 명확한 용어를 사용하여 명칭을 정의하야 합니다. 모호한 명칭으로 정의하면 혼란만 야기 시키는 결과가 됩니다.
   3. 문제 영역의 H/W에 대한 명쾌한 추상 개념을 제공하도록 작성합니다.
   4. SW 자원이 탑재되어 운영되는 보조적인 용도 뿐 아니라, 디플로이먼트 다이어그램은 시스템의 하드웨어 구성을 개념적으로 보여주는 훌륭한 도구가 됩니다. 이러한 용도를 살려 HW 자원의 구성에 대한 좋은 모델이 되도록 정의합니다.
   5. Model을 만든 목적을 전달하기에 필요한 수준까지만 분해되어 있습니다.
   6. 디플로이먼트 다이어그램에 모든 HW 장비가 나타날 필요는 없습니다. 오히려 이러한 시도는 다이어그램을 장황하고 복잡하게 만들어서 의미를 파악하기 힘들게 합니다. 목적과 용도에 부합하는 요소들만 정의하면 충분합니다.

1. 정의

   유즈케이스 정의서는 "유즈케이스 다이어그램의 각 유즈케이스에 대해 처리 흐름을 상세히 정의한 문서"입니다. 이 문서는 통상 자연어로 기술됩니다. 그러나 자연어로 기술하라는 것이 정해진 것은 아닙니다. 문서의 내용이 유즈케이스의 처리 흐름을 정의한 것이기 때문에 그 목적을 만족하는 것이라면 형태에 구애 받지는 않습니다.

   즉, 수학적인 표식이어도 되고, 처리 흐름을 알 수 있는 도표로 표현되어도 됩니다. 단, 혼자만 알 수 있는 표현이면 안 되고, 모든 사람, 특히 전산지식이 없는 사람도 쉽게 이해할 수 있는 표현이어야 하고, 표준화가 전제되어야 합니다.
   
   유즈케이스 정의서는 UML을 적용하는 대부분의 현장에서 작성하고 있으며, 이 산출물을 작성하는 것을 당연한 것으로 생각하고 있습니다.

2. 목적

   유즈케이스 다이어그램은 SW 시스템의 외부환경과 SW 시스템간의 교류를 표현하는 다이어그램입니다. 유즈케이스 다이어그램은 사용자의 관점으로 작성하고, SW 지식이 깊지 않은 사용자라도 이해해야 하기 때문에 그 형식과 내용이 매우 간결하게 표현됩니다. 이런 점 때문에 유즈케이스 다이어그램이 전달하고자 하는 내용은 부족한 점이 많습니다. 유즈케이스 다이어그램에서는 단지 교류가 있음을 나타내고 있을 뿐 시스템 내·외부간 교류의 세부적인 사항은 유즈케이스 다이어그램에서는 정의되지 않습니다. 따라서 보다 정확한 시스템의 이해를 위해서는 유즈케이스 다이어그램을 보완하여 내부의 자세한 처리 내용을 기술하여 정의하는 것이 필요합니다. 바로 유즈케이스 정의서는 이러한 필요성에 따라 유즈케이스의 처리 흐름을 상세하게 정의하는 문서인 것입니다.

    

1. 구성
   1. 목차

      유스케이스를 정의하는 기본 목차는 다음과 같다.

       

      Use Case 명 : 유즈케이스 정의서 개요

       

      이벤트흐름 : 기본흐름, 선택흐름

      사전 조건 : 유스케이스를 진행하기 전에 이미 실행, 정의되어야 하는 조건

      사후 조건: 유스케이스가 끝나고나서 실행, 정의되는 조건

      참조 요구사항 : 유스케이스를 그리기 위해 참조한 요구사항을 기술

       

       

   2. 양식

      유즈케이스 정의서의 표준 양식은 없다고 할 수 있습니다. UML의 사양을 정의한 공식문서인 "OMG Unified Modeling Language Specification"에는 유즈케이스 정의서(Use case Specification)에 대한 표준은 언급하고 있지 않기 때문입니다

1. 구성 내용
   1. Use Case 명

      유즈케이스 정의서의 제목 부분에 해당합니다. 유즈케이스 정의서는 유즈케이스 하나마다 작성됩니다. 따라서 유즈케이스 정의서가 어떤 유즈케이스에 대한 것인지를 명시합니다. 이 내용 후에는 유즈케이스가 하는 일에 대한 간략한 개요를 기술합니다.

   2. 이벤트 흐름

      유즈케이스는 액터의 이벤트로 그 동작을 개시합니다. 이벤트란 응답을 유발하는 사건을 의미합니다. 예를 들면, "상품정보 요청" 이벤트는 시스템으로부터 상품정보를 제공하는 응답을 유발합니다. 이렇게 SW시스템 외부의 이벤트와 그 이벤트에 대한 시스템의 응답을 알면 시스템이 하는 일을 알 수 있습니다. 이렇게 이벤트 흐름(Flow of events)부분은 액터와 유즈케이스 사이의 이벤트 흐름, 즉 처리 흐름을 상세하게 정의하는 부분입니다.

       

      기본흐름(Basic flow)

      이 유즈케이스가 실행되면 반드시 발생하는 기본적 처리 흐름을 기술합니다. 즉, 경우에 따라서 조건에 따라서 실행되는 처리 흐름이 아닌 무조건적으로 실행하는 처리 흐름이 기술되어야 합니다. 또한 처리 흐름 중에 반드시 하나를 선택해야 할 경우에는 대표적인 선택과 그에 따른 처리 흐름을 기술합니다. 이벤트 흐름이므로 기술되는 방식은 외부 이벤트글, 그에 대한 유즈케이스의 응답이 쌍으로 기술되도록 합니다.

       

      선택흐름(Alternative flow)

      기본 흐름과는 달리 조건과 상황에 따라 추가적으로 혹은 달리 실행되는 처리 흐름에 대하여 기술하는 부분입니다. 유즈케이스가 액터의 선택 결과에 따라 다른 처리 흐름으로 진행해야 할 경우가 있을 때 기술합니다. 선택 흐름은 기본 흐름에서 가지 쳐 나온 처리 흐름입니다.

1. 사전 조건

   유즈케이스가 실행되기 위한 전제 조건을 명시하는 부분입니다. 이 사전 조건을 만족하지 못하는 한 유즈케이스는 실행될 수 없습니다. 사전 조건은 다른 유즈케이스가 행된 후에 만족하는 경우가 많습니다. 이 부분도 자연어로 기술되고 사전 조건이 여러 개인 경우 번호를 붙여 나열합니다

1. 사후 조건

   유즈케이스가 실행한 후의 시스템 상태가 변화한다면 이를 명시하는 부분입니다. 시스템의 상태가 변화한다는 것은 다른 유즈케이스의 실행에 영향을 주는 변화를 의미합니다. 이러한 사후 조건을 기술하는 유즈케이스는 많지 않습니다

1. 참조 요구사항

   유즈케이스가 실행될 때 기능 외의 특별한 요구사항을 기술하는 부분입니다. 특별 요구사항에 정의될 수 있는 것들은 다음과 같습니다.

   1. 표준에 관한 요구사항(어플리케이션 표준)
   2. 품질과 관련된 요구사항(성능, 신뢰성 등)
   3. 기술관련 요구사항(OS, 호환성, 기타 설계 제한사항) 등

1. 주의사항
   1. 유즈케이스 정의서 작성 시 간결하고 명료한 표현을 사용해야 합니다. 불 필요하게 장황한 설명을 하거나 처리 흐름을 명확하지 않게 표현해서는 안됩니다.
   2. 유즈케이스 정의서는 액터와의 상호작용에 초점을 맞추어 기술해야 합니다. 즉, 액터의 요구(이벤트)와 유즈케이스의 응답의 관점에서 기술합니다.
   3. 물리적인 구현 관점의 용어가 언급되지 않도록 주의해야 합니다. 유즈케이스 정의서는 구현 사양을 기술한 것이 아닙니다. 이후 어떤 구현 환경으로도 구현될 수 있다는 생각으로 정의해야 합니다. 또한 유즈케이스 정의서는 SW 지식이 없는 사람도 이해할 수 있어야 합니다.
   4. 모호한 용어나, 지나치게 추상화된 처리 흐름으로 기술하지 말아야 합니다. 유즈케이스 정의서 작성 도중 유즈케이스 다이어그램을 수정해야 할 경우에는 바로 수정합니다. 단 수정의 결과로 기능의 변경으로 인해 사용자와 합의가 필요한 경우, 합의를 먼저 득한 후 수정합니다.

현재 많은 회사에서 소프트웨어에 대한 전략적인 가치가 증가됨에 따라 산업계에서는 소프트웨어
생산의 자동화, 소프트웨어의 시간과 비용을 절감, 소프트웨어의 질을 향상시킬 수 있는 기술을
모색하고 있다. 이러한 기술들로 현재 부상하고 있는 것이 컴포넌트 기술, 시각적(Visual) 프로그
래밍, 패턴(Pattern)과 프레임워크(Framework) 등이 있다.

업무의 처리과정에서 그 업무의 범위와 규모가 커짐에 따른 시스템의 복잡성을 처리할 필요성을
느끼게 되었다. 특히 물리적인 시스템의 분산, 동시성(Cuncurrency), 반복성(Replication), 보안,

결점보완, 시스템들의 부하에 대한 균등화(Load balancy)와 같은 반복해서 발생하는
구조적 문제 대한 처리가 필요하게 되었다.

추가적으로 웹의 발전에 따라 시스템을 만들기는 쉬워졌으나 이러한 구조적 문제는 더욱 악화되었다.  
UML은 이러한 모든 필요성에 의해 만들어졌다.

UML은 소프트웨어 시스템이나 업무 모델링(Business Modeling) 그리고

기타의 비 소프트웨어 시스템등을 나타내는 가공물(Artifact)을 구체화(Specifying)하고,

시각화(Visualizing)하고, 구축(Construction)하고, 문서화(Documenting)하기 위해 만들어진 언어이다.

UML은 복잡하고 거대한 시스템을 모델링함에 있어 성공적으로 증명된 공학적인 경험들을 포함하고 있다.

UML은 Rational Software와 그의 동료 회사에 의해 개발되었다.

UML은 OMT, Booch, OOSE/Jacobson에서 발견되는 모델링 언어의 장점을 계승하였다.

그리고 대부분의 회사들이 표준으로 제정된 UML을 가지고 그들의 개발 프로세스에 적용하고 있다.

이러한 개발 프로세스들은 업무의 모델링과 요구의 관리, 분석과 디자인, 프로그래밍과 테스트를

모두 포함하고 있다.

▶ 모델링의 중요성.
강력한 소프트웨어 시스템을 만들기 위해 구축(Construction)하고 개선(Renovation)하기에 앞서
모델을 만드는 것이 건물을 만들기 위한 청사진 만드는 것과 같이 핵심적인 요소이다.

잘 만들어진 모델은 프로젝트 팀간의 통신수단으로써 그리고

구조적인 문제를 해결하기 위한 수단으로써 핵심적인 것이다.

시스템의 복잡성이 증가함에 따라 좋은 모델링을 하기 위한 기술은 더욱 중요하게 되었다.

성공적인 프로젝트에서의 성공요소는 여러가지가 존재하지만 표준적이고 엄격한 모델링 언어를

가지는 것이 핵심적이다.

▶ 모델링 언어가 반드시 포함하여야 하는 것.
모델 요소(Model elelements) -> 기본적 모델링 개념과 의미
표기(Notation) -> 모델요소의 시각적인 그림
Guideline -> 관용적인 사용방법.
시스템의 복잡성이 증가함에 따라 시각화(Visualization), 모델화(modeling)가 핵심적인 사항이
되어가고 있다. UML은 이러한 필요성에 부응하기 위해 잘 정의되어져 있고 넓은 범위를 수용하도
록 되어있다. 결과적으로 객체지향 시스템과 컴포넌트 기반 시스템을 구축하기 위해 시각적 모델
링 언어를 선택하는 것도 필연적이다.

▶ UML의 목적
UML로 디자인함에 있어서 최우선 목표는 다음과 같다.

사용자에게 즉시 사용가능하고 표현력이 강한 시각적 모델링 언어를 제공함으로써 사용자는 의미
있는 모델들을 개발하고 서로 교환할 수 있다.
핵심적이 개념을 확장할 수 있는 확장성과 특수화 방법을 제공한다.
특정 개발 프로세스와 언어에 종속되지 않는다.
모델링 언어를 이해하기 위한 공식적인 기초를 제공한다.
객체 지향 툴 시장의 성장을 장려한다.
콜레버레이션(Collaboration), 프레임워크(Framework), 패턴(Pattern)과 Component와 같은 고수준
의 개발 개념을 제공한다.

▶ OMG-UML의 범위
UML은 소프트웨어가 중심이 되는 시스템을 나타내는 가공물(Artifact)을 구체화되고 시각화하고,
문서화하기 위한 언어이다. 이러한 특징을 가진 UML의 범위를 다음의 세가지로 요약할 수 있다.
첫째로 UML은 Booch, OMT, OOSE의 개념을 융화 시켜서 만들었기 때문에 그 결과는 사용자나 다른
어떤 방법론에도 일반적이고 유일하며, 넓게 사용될 수 있다.

둘째로 UML은 기존의 방법론들을 가지고 있는 어떠한 작업에도 적합한 방편을 제공한다.

예를 들면 UML 저자들은 동시에 발생하는(Concurrent), 분산된(Distributed) 시스템의 모델링을 UML의 목표로 삼았다.

셋째로 UML은 표준적인 방법론에 역점을 두지 않고 표준적인 모델링 언어에 역점을 두었다.

이와 같이 표준 방법론을 제시하지 않는 이유는 서로 다른 문제 영역에 대해 서로 다른 방법론을 요구하기 때문이다.

그래서 표준적 언어로의 UML은 첫째로 일반적인 메타모델(Metamodell)과 둘째로 일반적인 표기
(Notation)에 노력이 집중되었다. 하지만 UML에서도 사용사례유도(UseCase Driven)의, 구조중심
(Arcitecture-centric)의, 반복적인(Iterative), 점진적인(increment) 개념을 방법론에 적용하도
록 권장하고 있다.

▶ UML의 범위 외부
UML은 모든 것을 포함하는 언어가 아닌, 단순하고 표준화된 모델링의 제공을 목표로 하고 있다.
이러한 점이 산업계 전반에 걸쳐 존재하는 다양한 시스템의 디자인에 UML이 사용될 수 있는 유연
성을 제공한다.

▶ 프로그래밍(Programming) 언어
UML은 비주얼 모델링 언어이지 비주얼 프로그래밍 언어가 아니다. 하지만 UML은 어떤 의미에서는
비주얼 모델링 언어가 제공하는 모든 시각적이고 의미적인 모든 지원을 가지고 있다. UML은 소프
트웨어가 중심이 되는 시스템을 나타내는 가공물(Artifact)을 구체화되고 시각화하고, 문서화하
기 위한 언어이다. 하지만 UML은 실제 코드로의 지향을 위해 사용될 수 있다. 예를 드어 UML은 객
체 언어와 밀접하게 묶여 사용이 가능하고 이것은 최고의 결과를 낼 수 있다.

▶ 툴(Tools)
표준화 된 언어는 툴과 방법론을 위한 기본을 제공한다. OMG RFP(Request For Proposal) 의 목적
은 툴들 상호 운용성(Interoperability)에 목적을 둔다. 이러한 툴 들의 상호 운용성은 UML이 제
공하는 것과 같이 견고한 의미(Semantic)와 표기의 정의에 의존하고 있다. 즉 UML은 툴들의 상호
운용성을 위해 툴인터페이스, 저장방법(Storage), 실행시간 모델(run-time model)등과 같은 방법
을 제공하는 것이 아니라 의미적 메타모델(Metamodel)을 제공한다.

▶ 방법론(Process)
세계 많은 업체들이 그들의 프로젝트 산출물(Artifact)을 위한 일반적인 언어로 UML을 사용할 것
이다. 하지만 이들 업체들은 상이한 방법론에 동일한 UML 다이어그램을 사용하게 될 것이다. 즉
UML은 의도적으로 방법론에 독립적인 언어로 만들어졌고 또한 표준화된 방법론을 정의하는 것이
UML이나 OMG RFP의 목적이 아니다.

▶ UML의 기원과 어떻게 UML이 OMG의 표준이 되었는가
객체지향적 분석과 디자인에 대해 다양한 방면으로 실험적인 접근을 하던 방법론자들에 의해서
1970년 중반부터 1980년대까지 주목할 만하고 다양한 객체지향 모델링 언어가 나타나기 시작했
다. 1989년에서 1994년까지 확연한 모델링 언어가 적게는 10개미만에서 많게는 50개 이상으로 증
가하게 되었다. 객체 지향의 방법론을 사용하는 많은 사용자들이 하나의 모델링 언어에서 완벽하
게 만족을 찾기 위해 많은 논쟁이 있었다.  이를 방법론전쟁(Method War)이라 한다. 1990년대 중
반부터 이러한 방법론들이 새로운 모습으로 나타났고 이러한 방법론들이 서로 다른 방법론의 기술
들을 융합하게 되었다. 그 결과 몇 개의 특출한 방법론들이 드러나게 되었다.

UML의 개발은 1994년 후반에 Grady Booch와 Jim Rumbaugh에 의해 그들의 방법론인 Booch와 OMT의
통합으로 시작되었다. 1995년 가을 Ivar Jachobson이 소속된 회사 Objectory와 Rational과 병합되
면서 통합의 노력이 있었고 이에 Jacobson의 OOSE 방법론이 통합되었다.

Booth, OMT, OOSE의 주요 저자인 Grady Booch, Jim Rumbaugh, Ivar Jacobson는

다음의 세가지 이유로 통합된 모델링 언어를 만들게 되었다.

첫째, 각각의 방법론들이 이미 각자 독립적인 발전하고 있었다.

각자 방법론에서 사용자에게 혼란을 일으킬 불필요한 부분을 제거하여 같이 발전하는 것이 더 이치에 맞았다.

둘째로 완벽한 의미와 표기의 통일로써 안정된 객체지향 시장을 형성할 수 있다.

또한 프로젝트에 완벽한 모델링 언어를 제공하고 툴들에게 더 나은 특징을 제공하게 된다.

셋째로 각자의 방법론이 서로 보완하여 더 나은 발전을 이룰 수 있고 각자의 방법론이 해결
할 수 없는 문제를 해결할 수 있도록 도와준다.

이들 세사람이 통합을 하기 위해 먼저 그들은 다음의 4가지의 목표를 두고 노력을 기울였다.

객체지향 개념을 이용하여 소프트웨어 영역 뿐만 아니라 소프트웨어가 아닌 영역의 시스템도 모델
링 할 수 있게 한다.
실행 가능하거나 개념적인 산출물들을 명확하게 결합할 수 있게 만든다.
복잡하고 프로젝트 성공여부에 민감한 시스템들에 준하는 논점에 역점을 둔다.
인간이나 기계에 모두 유용한 모델링 언어를 만든다.
Booth, Rumbaugh, Jacobson은 1996년 6월에 UML 0.9를 내놓았고 10월에 0.91의 문서를 내놓았다.
1996년내에 UML저작자들은 여러가지 피드백을 받았고 이를 반영하게 되었다.

Rational은 UML을 표준 모델링 언어로의 확정을 위한 노력도 들였다.

1995년 초 Ivar Jacobson(Objectory의 기술담당 대표)과 Richard Soley(OMG의 기술 담당 대표)는

방법론의 시장에 표준으로 정하기 위한 어려운 노력을 시작하였다.

이러한 노력의 결과 1995년 6월에 쟁쟁한 방법론자들이 참석한 OMG의 주요 회의에서

OMG의 비호아래 방법론의 표준으로 제정되었다.

1996년 한 해동안 몇몇 기구에서 그들의 사업에 UML을 전략적인 도구로 보기 시작하였다.

OMG에 의해 제공된 RFP(Request For Proposall)가 몇몇 기구들에게 그들의 의견을 많이 반영시킬 수 있
도록 촉매제로서 제공되어졌다. 이에 Rational은 몇 개의 기구들과 함께 UML 파트너 협회를 만들
었고 강력한 UML1.0을 만들기 위한 다양한 정보를 제공하게 되었다.

이러한 모든 원조들의 UML1.0에 반영되었다. 이러한 협력업체로는 다음과 같다.

Digital Equipment Corp, HP,  I-Logix, Intellicop, IBM, Icon Computing, MCI Systemhouse,
Microsoft, Oracle, Rational Software, TI, Unisys.

이러한 협력들이 잘 정의되었고 표현력이 강하고 강력하고, 일반적인 언어인 UML1.0를 만들게 되었다.

이것은 결국 1997년 1월에 OMG에 의해 RFP의 응답으로 받아들여지게 되었다.

1997년 1월에 IBM, Objectime, Platinum Technology, Ptech, Taslson, Reich Fechnologies and Softeam은

OMG에 개별적으로 RFP에 대한 응답을 제출했다.

이러한 회사들은 자신들의 의견을 반영하기 위해 UML협회에 참여하게 되었고, 결과적으로 UML은 1.1로 개선되었다.

UML1.1의 중점사항은 UML의 의미적인 무결성을 추구하고 새로이 참여한 회사들의 의견을 반영하는 것에 있었다.

결국 UML1.1은 1997년 가을에 OMG에 제출되었고 표준으로의 인정을 받았다.

▶ UML의 현재와 미래
UML은 한 회사에 독점적이지 않고 모두에게 개방되어 있다. 이것은 일반 사용자나 과학단체의 필
요성을 겨냥하여 나왔고 또한 기존의 주요한 방법론의 경험에 기초하여 만들어졌다.

많은 방법론자들과 협의체, 툴 업체들로 UML을 사용하기에 동의했다.

UML은 Booth, OMT, OOSE와 기타 주요한 방법론들과 유사한 의미론과 표기를 바탕을 만들어졌고

또한 여러 회사들의 폭 넓은 의견을 반영되었기 때문에 매우 직접적이다.

UML에서 목표로 하는 통합(Unified)의 의미로 다음의 두 가지 면을 가지고 있다.

기존의 방법론들의 다양한 모델링 언어들 사이의 사소한 차이를 끝내는 것이다.
여러 종류의 시스템(소프트웨어와 업무) 사이의 관점과 개발 단계(요구 분석, 디자인, 구현) 내부
적인 개념의 통합을 의미한다.
UML은 매우 상세한 언어로 정의 되어 있음에도 불구하고 미래의 모델링 개념으로 발전에 대한 벽
은 존재하지 않는다. 우리는 아주 많은 앞서가는 기술에 관심을 두고있다. 이러한 모든 기술이
UML의 차후 버전에 반영되기를 바랄 것이다. 앞서가는 많은 기술이 UML을 기초로 정의 될 수 있
고 또한 이러한 UML의 확장으로 UML의 핵심이 변화되는 일은 없을 것이다.

현재의 상황으로 보면 UML은 시각적 모델링을 위한, 시뮬레이션을 위한, 개발 환경으로써 많은 툴
들의 기본이 될것으로 기대되어진다. 통합개발 환경이 개발됨에 따라 UML을 기초로한 구현은 점
점 더 많이 늘어날 것이다.

▶ The Meta Object Facility
OMG MOF의 핵심 목적은 CORBA의 인터페이스 집합을 제공하는 것이다.  MOF는 CORBA기반의 분산 개
발 환경구축에 있어서 핵심적인 단위이다.

MOF는 분산 객체의 환경에서의 객체 저장소, 객체 모델링 툴, 메타데이타 등의 영역에서 진행중
인 작업을 통합적으로 표현한 것이다. MOF의 스펙은 UML 표기를 이용한다.  MOF의 인터페이스와
의미들은 실제 상업적인 객체 저장소, 모델링 툴들, 객체의 프레임워크 제품들에 의해 구현된 메
타데이터 관리의 앞서나가는 개념들을 포함하고 있다.

MOF의 스펙은 일반적으로 분산 객체의 환경에서, 특수하게 분산 개발 환경에서 메타데이타의 호환
성(Interoperability)과 메타데이타의 관리적인 측면을 강화하고 있다.

이러한 강화의 초기작업으로 객체분석과 디자인의 영역에서 메타데이타의 호환성을 강화하고 있고

이것은 앞으로 추가적인 영역을 제공하기에 충분할 것으로 기대되어진다.

 OMG는 이러한 추가적인 영역을 담당할 수 있는 새로운 RFP를 기대한고 있다.