KR19990071993A - 통신시스템용 시스템 플랫폼 - Google Patents

통신시스템용 시스템 플랫폼 Download PDF

Info

Publication number
KR19990071993A
KR19990071993A KR1019980704284A KR19980704284A KR19990071993A KR 19990071993 A KR19990071993 A KR 19990071993A KR 1019980704284 A KR1019980704284 A KR 1019980704284A KR 19980704284 A KR19980704284 A KR 19980704284A KR 19990071993 A KR19990071993 A KR 19990071993A
Authority
KR
South Korea
Prior art keywords
extension
base
platform
communication system
execution
Prior art date
Application number
KR1019980704284A
Other languages
English (en)
Inventor
자리타파니 코이스티겐
이나 웬미어
정의숙
Original Assignee
에를링 블로메, 조한 환트
텔레폰아크티에볼라게트 엘엠 에릭슨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 에를링 블로메, 조한 환트, 텔레폰아크티에볼라게트 엘엠 에릭슨 filed Critical 에를링 블로메, 조한 환트
Publication of KR19990071993A publication Critical patent/KR19990071993A/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/54—Object oriented software
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13502—Indexing scheme relating to selecting arrangements in general and for multiplex systems primitives - inc. service-independent building blocks [SIBBs]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13503—Indexing scheme relating to selecting arrangements in general and for multiplex systems object-oriented systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13535—Indexing scheme relating to selecting arrangements in general and for multiplex systems distributed systems - also domains in service creation

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Stored Programmes (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Devices For Executing Special Programs (AREA)
  • Radar Systems Or Details Thereof (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

가입자 서비스를 제공하는 통신시스템용 객체 지향 시스템 플랫폼은 기본 및 보조 서비스를 제공하는 기본기능과 보조기능 형태의 어플리케이션을 갖는 상부층을 구비한다. 이 상부층은 기본객체(202) 및 확장객체(204, 206, 208)로써 실행된다. 상기 기본객체는 장래에 확장될 필요있는 기능을 실행하는 객체인데, 각 객체의 형태는 다른 기본객체와 최소의 조정을 통하여 실행될 수 있다. 상기 확장객체는 상기 기본기능으로 확장을 행하는 확장기능 실행하는 객체형태이며, 신규 서비스를 부과하고 이미 실행되고 제공된 소프트웨어를 변경하지 않고 현존하는 서비스를 수정 및 확장이 가능하게 만들었다.

Description

통신시스템용 시스템 플랫폼
보조 서비스들은 기본 서비스를 제공하는 시스템이 이미 개발되어 제공되었을 때 행하여진다. 상기 시스템을 갱신하는 종래의 방법은 시스템에 새로운 보조 기능을 제공하기 위하여 편집하고 다시 편집한 다음, 새로운 확장기능과 현존하는 확장기능 사이의 조정을 행한다.
미국 특허 제5,057,996호 및 제5,136,712호에는 하드웨어 층과, 오퍼레이팅 시스템 기능을 가진 층과, 소프트웨어 층을 갖춘 객체 지향 동작시스템이 기술되어 있다. 특정 객체로 액세스하는 것은 상기 시스템의 자원들을 이용하기 위하여 필요시 된다. 상기 객체들은 각 객체형태의 동작을 정의하는 일정한 데이터 구조 및 일정한 방법을 가지고 있다.
상기 시스템은 상기 동작시스템의 코어를 수정하지 않고 새로운 객체 형태를 발생하는 루틴(routines)을 허용한다.
미국 특허 제5,421,015호는 객체 형태의 확장 가능한 세트와 객체 관리자의 해당 세트를 갖는 객체 지향 데이터 처리 시스템이 기술된다.
본원은 가입자 서비스를 제공하는 통신시스템에 통상적으로 이용하는 객체 지향 시스템 플랫폼에 관한 것이다. 상기 플랫폼은 하부층에 동작시스템과, 이 시스템 상에 위치되고 자원객체(resource objects) 형태의 양호한 통신 추상화(telecommunication abstractions)를 포함하는 어플리케이션 플랫폼과, 이 플랫폼 상에 기본서비스와 보조서비스를 제공하는 기본기능 및 보조기능의 형태로 원하는 어플리케이션을 행하는 상부 층을 일반적으로 구비하고 있다.
통신시스템에 제공된 가입자 서비스는 각각의 상기 시스템에 기본기능과 보조기능을 제공함으로써 기본서비스와 보조서비스를 할 수 있다.
시스템의 보조기능들은 선택적이고 시장에 의존하며, 기본서비스를 제공하는 시스템이 제공된 후에야 고객에게 제공될 수 있다. 후자는 통화중일 때 호출대기(call waiting) 및 착신호 전환(call forwarding)같은 가입자 서비스를 제공하는 경우이다.
도 1은 가입자 서비스를 제공할 수 있는 통신시스템에 대한 시스템 플랫폼의 개략도.
도 2는 본원에 확장 개념으로 이용된 개념들 사이에 결합관계를 도시하는 화상도.
도 3은 오버 뷰(over view)의 확장 개념도.
도 4 내지 도 6은 기본객체의 설명서, 실체, 및 확장뷰를 각각 도시하는 예시도.
도 7 내지 도 9는 확장객체의 설명서, 실체, 및 확장뷰를 각각 도시하는 예시도.
도 10은 기본객체 개념, 확장객체와 확장뷰 사이의 관계, 및 객체 형태 설명서, 객체 형태 실체와 객체 형태 실행 사이의 관계를 통합한 오버뷰를 제공하는 뷰 도시도.
도 11은 무조건의 확장 케이스도.
도 12는 조건의 확장 케이스도.
도 13은 이벤트(event) 확장을 암시하는 케이스도.
도 14는 동일한 확장점에서 몇가지 확장을 하는 케이스도.
본원의 주목적은 통신시스템에 있어서 기본 서비스를 제공하는 시스템이 제공된 후에 선택적이고 시장에 의존하거나 소비자에게 제공되는 시스템의 일부분, 즉, 시스템의 보조기능의 관리를 보다 효율적으로 하기 위한 것이다.
본원의 보다 확실한 목적은 이미 실행되고 제공된 기능의 소프트웨어를 변경할 필요 없이 시스템에 의하여 제공된 서비스의 수정 및 확장을 행함으로써 효율을 높이는 것이다.
본원의 다른 목적은 특허청구범위의 특징부에 의하여 달성된다.
도입부에 정의된 것과 같은 종류의 시스템 플랫폼에 있어서, 상부 층은 기본객체와 확장객체들로 실행된다. 상기 기본객체들은 본원에 포함된 한가지 이상의 방법으로 미래에 확장되는데 필요할 수도 있는 기본기능을 실행하는 객체 형태이고, 상기 확장객체는 본원에 포함된 한가지 이상의 방법으로 확장될 확장기능을 기본 기능으로 실행하는 객체 형태이다. 각각의 기본객체 형태는 특별한 임무를 위하여 설계되는데, 이것을 다른 기본객체들과의 조정을 최소화 하여도 실행될 수 있게 설계된다.
상기 확장객체들은 이미 실행되고 공급된 서비스의 소프트웨어를 변경하지 않고 신규 서비스를 부가하거나 현재 서비스를 수정하고 확장할 수 있게 설계된다. 또한, 상기 확장객체들은 확장기능으로 확장기능을 실행하는 객체 형태와, 상호 작용 수작업 확장기능(interaction handling extension functions)을 실행하는 객체 형태를 포함하는데, 이것은 보조 서비스간에 상호작용을 조정한다.
상기 확장객체들은 수정될 기본객체에 동적으로 꼭 동작할시에 시스템의 확장을 유도할 수 있다.
이러한 확장은 구성 가능하다. 즉, 설계자가 확장의 활성/비활성 특성을 갖게 하기 위해 코드를 설계할 필요 없이 일반적인 방법으로 실행 시간안에 시스템의 수정을 부가하거나 제거할 수 있는데, 이것은 플랫폼에 의해 조정된다.
상기 포함된 객체 형태의 목적을 이루는 작용은 유한 상태 기계(finite state machine)같이 본원 방법들의 기능을 기술함으로써 설명된다. 상기 유한 상태 기계는 상기 방법의 코드를 실행하는 유한개의 상태와 이러한 상태간의 변화로 이루어진다.
상기 확장은 상기 상태에 부가되고, 실행제어를 접수한 다음, 실행을 종료한 후에 동일한 확장지점 또는 다른 확장지점으로 실행제어를 복귀시킨다.
상기 기본객체 형태와 확장객체 형태는 현재 실행하고 있는 상기 시스템을 변경하지 않고서도 상기 시스템을 수정하고 확장할 수 있는 확장 개념을 제공한다. 더욱 특히, 이것은 상기 시스템 안에 확장의 정의(definitions)만을 로딩하는 것에 의해 달성되는데, 이것은 특별히 미리 정한 확장지점에 실행제어를 접속함으로써 시스템의 기능을 간접적으로 수정할 수 있다.
확장객체에 대해서 명세서는 확장객체안의 어떤 확장지점에 상기 제어를 접속하고 어떤 확장지점에서 상기 제어를 복귀시킬수 있는 것을 설명한다.
확장객체가 상기 제어에 접속하는 경우, 미리 정해진 확장방법은 실행을 시작한다.
실행시간 시스템은, 확장객체의 생성 및 상기 언급된 확장점에서 그 확장방법의 호출을 처리한다.
확장객체는 확장 제어를 접속하여 기본객체 또는 확장객체의 속성과 방법으로 액세스한다. 이러한 속성과 방법들은 액세스될 수 있는 객체 형태 명세서에서 선언되는 것만 포함할 수 있다.
또한, 객체 형태의 명세서에서는 명세서에 있는 속성과 방법의 특정 서브세트(subset)만이 일정한 확장점으로 상기 제어를 접속하는 확장에 유용하다는 제한에 의해 각 확장점에 대한 액세스 제한을 제한한다.
확장가능 객체에 대한 객체 형태의 명세서는 확장기능 객체의 확장을 확인하고 이용할 수 있는 정보량을 정한 인터페이스처럼 작동한다. 확장 개념에 이용되는 인터페이스 층은 뷰(view)를 이용하는 확장에 의해 액세스될 수 있는 확장 가능 객체의 명세서에 있는 정보의 서브세트를 각각 정의한 확장뷰에 의해 정의된다.
다른 한편, 기본객체(base object)에 대하여 명세서는 확장에 이용할 수 있는 상태, 속성, 및 방법을 도시하는 인터페이스 설명서 역할을 하고, 또한 기본객체의 실예를 만들 필요성이 있는 클라이언트 객체 쪽으로의 인터페이스를 정의한다. 상기 인터페이스는 기본객체 형태의 방법으로 정의되는데, 이것은 새로운 실 예를 만들때 이용될 수 있는 매개변수를 결정한다.
상기 명세서는 상기 객체 형태의 기능을 이해하는데 필요없는 실행의 세부항목을 종료하는 동안에 기본객체 형태의 작용을 수준 높게 설명한다.
기본객체에 의해 이용되는 객체논리로 생성되는 추상층(abstraction layer) 및, 상기 객체 논리도 이용하는 기본객체의 세부방법은 고 추상레벨(high abstraction level)에 기여한다.
명세서의 합리적인 추상레벨은 상기 명세서에 기본객체의 대기 상태(wait state) 및 상기 기본객체의 기능을 이해하는데 기본적인 몇몇의 비대기 상태(non-wait states)를 도시함으로써 얻어진다.
상기 도시된 상태들의 실행에 필요한 코드는 선언한 국부로 설명되었지만, 상기 명세서에는 특별한 작용을 필요로 하지 않는다.
상기 명세서에 도시될 상태의 판단은 객체 형태의 어느 부분이 장래에 확장으로 노출될 수 있는지를 고려해야 할 것이다.
모든 상태, 즉, 대기상태와 비대기 상태 및 명확히 우월한 확장점은 상기 방법 명세서에 도시된다. 실행 코드(Action code)는 국부적인 방법으로 상태전이에 이용된다. 만약 이러한 작용에서 어떤 부분이 확장될 필요가 없는 경우, 명세서 또는 실현(realization)에 정의되어 있는 국부방법, 또는 실행 레벨에 그대로 유도된다.
상기 객체 형태 실현은 확장할 필요가 없거나 할 수 없고, 수준 높은 묘사를 위하여 명세서에 도시될 필요가 없지만, 직접 실행 언어를 이용하는 대신에 보다 적합한 기본객체의 일부분에 이용된다.
이러한 객체 형태 실현으로 실행 코드를 도입하는 세부방법의 정의가 명확히 도입되고, 상기 명세서에 포함된 기능 정의를 무시하는 동안, 실현시 상기 명세서에 제공되는 기능 명세서의 정련(refining)을 의미하는 매우 상세한 기능 정의가 제공된다..
본원의 상기 확장 개념은 많은 가치있는 특성을 가지고 있다. 이것은 전체 방법을 무시할 필요없이 수정을 행하는 세밀한 방법이며, 대부분의 객체 지향 형식에서 이용할 수 있는 메커니즘이다. 즉, 상기 방법의 무시는 상기 방법안에 있는 확실한 확장점에서 실행될 수 있다. 이러한 확장 개념은 이미 개발 공급된 시스템 안에 많은 보조 기능을 도입함으로써 복잡해진 시스템의 효율을 위하여 프레임워크(frame work)를 형성한다.
이것은 개별 확장으로 발생된 수정사항을 기술하는 것이 가능한데, 이러한 확장은 필요시 차례로 배열될 수 있다. 이러한 보조 기능간의 조정은 보조 기능으로 확장하는 것과 같은 경우에 개별확장으로도 표현될 수 있다.
도 1에 도시된 바와 같이, 통신시스템용 시스템 플랫폼은 많은 기능 또는 층들을 가지고 있다. 이러한 층들은 하부층(102)에 오퍼레이팅 시스템과, 이 시스템 상에 설치되고 자원 객체의 형태로 통신 추상화를 적절히 포함하는 어플리케이션 플랫폼(104), 및 이 플랫폼 상에 기본서비스와 보조서비스를 제공하는 기본 기능과 보조 기능의 형태의 바람직한 어플리케이션을 갖는 층(106)으로 일반적으로 기술된다.
나아가서, "카테고리(category)"의 개념은 상기 층(106)에 포함된 다른 형태의 객체를 정의하는데 이용될 것이다. 특히, "카테고리"는 문장에서 한 객체를 특성화 하지만, 또한 시스템 아키텍쳐의 위치와 기능을 특성화한다. 다음에 기술하겠지만 2개의 범주로 명명된 기본(BASE) 및 확장(EXTENSION)의 객체 형태는 상기 층(106)의 실행으로 구비된다. 이러한 객체들의 실예는 기본객체 및 확장객체로 아래서 각각 명명될 것이다.
또한, "이벤트(events)"의 감시를 요청하고, 그 결과를 기다린다. 이벤트는 객체의 형태를 설명함으로써 "이벤트" 섹션으로 선언된다. 상기 층(106)의 기능은 이벤트에 의해 실행된다. 즉, 상기 객체들은 비동기 메시지의 수신 작용을 한다. 가끔, 이벤트는 객체가 실행하는 프로세스에서 프로세스 사이의 통신링크에 도달하는 메시지의 결과로 발생된다. 여기서, 프로세스는 프로그램이 실행되는 것을 의미한다. 명명한 실행 스레드(thread)는 한 프로세스에서 실행경로에 이용될 것이다.
각각의 실행 스레드는 자체의 스택(stack)과 프로그램 카운터를 가지고 있지만, 동일한 프로세스에서 모든 스레드는 동일한 프로세스 데이터(히프)(heap)의 몫이다.
각각의 기본객체 형태는 전화기 시스템에서 호출 시작을 관리하는 것과 같이 특별한 임무를 수행하기 위해 설계된다. 이러한 임무를 수행할 때 기본객체 형태의 실예는 만들어진다. 다음에, 이러한 객체는 임무를 수행하는 방법을 제어할 것이다. 임무를 수행하기 위하여 자원 조종을 어떻게 하였는지와 같은 낮은 레벨의 세부사항은 방법 호출을 다른 카테고리, 예컨데, 카테고리 이벤트 발생기(EVENTGENERATOR)의 객체로 보내는 상기 기본객체에 의해 조정된다. 이러한 카테고리의 객체 형태는 이벤트가 발생하는 것에 의해 호출되고 사용자에 알리는 기본서비스 또는 자원을 나타낸다.
기본객체 형태는 각각의 임무가 상기 시스템에서 진행하고 있는 다른 임무와의 조정을 최소화하고, 즉, 기본객체사이에 조정을 최소화함으로써 실행될 수 있도록 설계된다. 이것은 기본 카테고리와 확장 카테고리의 특성에 반하는 것이다. 즉, 각각의 기본객체는 기본객체와 확장객체 어느 것도 외부로부터 호출할 수 없고 어떠한 이벤트를 발생할 수도 없는 반 병렬(Semi-parallel) 실행 스레드로 실행된다. 이러한 특성은 다음에 더욱 설명될 것이다.
기본 카테고리와 확장 카테고리의 다른 중요한 특성은 상기 시스템의 기능이 현재 실행하고 있는 시스템을 변경할 필요없이 수정 및 확장이 가능한 확장 개념을 제공하는 것이다.
대신, 상기 기능의 수정 및 확장은 상기 시스템의 확장만을 로딩함으로써 달성된다. 이러한 확장 개념에 의해서 이것은 특별히 정해진 확장점에서 실행제어를 행함으로써 시스템의 기능을 간접적으로 수정할 것이다.
상기 기본 카테고리는 장래에 확장될 필요성이 있는 기본 기능, 이른바 기본 기능을 실행하는 객체 형태에 이용될 수 있다. 상기 확장 카테고리는 이러한 기본 기능의 확장, 소위 확장기능을 실행하는 객체 모텔링을 위해 특별한 설계어(design language)를 이용하여 유한 상태 기계(finite state machine)가 가지고 있는 각 방법의 기능을 설명함으로써 정의된다. 상기 유한 상태 기계는 제한된 수의 상태와 이 상태들간의 전이로 구성하는데, 코드는 전이 작용으로 실행된다. 따라서, 확장한 본래 지점, 즉, 확장점은 상기 상태이다. 확장은 확장지점으로 실행제어를 하고, 동일한 방법으로 다른 확장지점 또는 동일한 확장지점으로 복귀한다. 다음 이러한 상태와 상태전이는 상기 상태 기계에 현존하는 상태 전이를 수정한다.
한가지 방법으로써 모든 상태는 확장지점으로 항상 이용될 수 있는 반면, 또한, 새로운 상태로 도입하지 않는 확장지점, 즉 명백히 명명된 확장지점을 확실하게 지정할 수 있다.
확장지점들(Extension points)은 이 지점으로부터 확장하거나 이 지점에서 확장을 종료할 것인지, 또는 그들이 양쪽 목적에 부합하여 이용될 수 있는지에 따라서 분류된다.
이러한 지점에서 다음의 명칭들은 계속 이용될 것이다.
- 접속점(Take Over Points)(TOP). TOP는 확장객체의 확장방법으로 실행제어를 전송할 수 있는 확장점
- 연속점(Continuation Points)(COP). COP는 확장방법으로부터 확장제어를 재 전송되게 할 수 있는 확장점.
- 접속 및 연속점(Take Over and Continuation Points)(TOP COP). TOP COP는 접속점과 연속점 모두에 이용될 수 있는 확장점.
처음부터 객체의 모든 상태는 접속 및 연속점이다. 그러나, 이것은 모든 확장을 유지해야 하는 기능이 필요한 경우 객체 형태 명세서를 변경할 수 있다. 또한, 동일한 종류의 확장은 확장뷰(extension views)로 만들어질 수 있는데, 그 개념은 이하에서 더욱 상세히 설명될 것이다.
또한, 상기 확장 개념은 확장으로 확장의 정의를 한다. 실제로, 확장은 체인을 생성하는 것에 의해 임의 개수의 레벨, 또는 확장층으로 정의된다.
따라서, 확장 체인의 "최상의(uppermost)" 확장과 확장의 전체 체인 사이를 다르게 할 수 있도록 어휘를 정의하는 것이 필요하다.
상기 "기본객체(base object)"의 개념은 최초의 확장안된 기본 기능을 갖는 객체를 지시하는데 이용된다. 이러한 개념을 오해할 우려가 있다면, 명칭 "최초의 기본객체(original base object)"를 이용한다.
확장은 "확장객체(extension objects)"로 언급된다.
인접 베이스(immediate base)라는 개념은 확장을 개시하는 기본객체 또는 확장객체에 관한 것이다. 즉, 확장은 인접 베이스에 접속한다.
더욱 일반적인 명칭 베이스는 최초의 기본객체를 포함하여 전체의 확장체인을 의미하는데 이용될 것이며, 어떠한 확장객체는 확장을 형성한다. 이러한 명칭을 오해할 우려가 있는 경우에는 "전체 베이스(entire base)"를 사용한다.
상기 언급된 바와 같이 객체(202), 즉 "기본객체(Base Object)"가 최초의 기본객체라는 것이 도 2에 도시된다. 상기 기본객체(202)로 확장객체(204 및 206), "확장객체1(Extension Object1)" 및 "확장객체2(Extension Object2)"는 연결될 수 있다. 상기 확장객체(206)는 다른 확장객체(208), 즉 (확장객체21) 중간 베이스이다. 상기 기본객체(202) 및 확장객체(206)는 상기 확장객체(208)의 베이스를 형성한다.
확장객체에 대한 명세서는 확장이 상기 제어를 접속하여 이루어지고 확장객체가 제어를 복귀시키는 확장객체의 확장점을 정의한다.
확장객체가 제어될 때 실행을 개시하는 소정의 확장방법(EXTENSION METHOD)이다. 상기 실행시간 시스템은 주어진 확장점에 확장객체를 생성하고 그들의 확장방법을 실행한다.
상기 언급된 바와 같이, 또한 확장객체는 차례로 확장할 수 있다. 따라서, 확장방법은 기본 방법 또는 다른 확장방법으로 항상 명백히 호출된다.
확장객체는 확장을 제어하는 확장한 객체, 즉, 기본객체 또는 확장객체의 속성과 방법으로 액세스 한다. 그러나, 이러한 액세스를 제어하는 몇가지 방법이 있다. 첫째, 객체 형태 명세서에 있는 속성과 방법뿐 인데, 이것은 액세스될 수 있다. 실현(realization)으로만 된 속성과 방법들은 확장에 이용할 수 없다. 또한, 상기 명세서에 있는 속성과 방법의 어떤 서브세트만이 어떤 확장지점에 제어를 하여 확장에 이용할 수 있게 정의함으로써 각 확장점에 대한 액세스 제한을 정의하는 것이 가능하다.
따라서, 확장 가능한 객체에 대한 객체 형태 명세서는 이러한 기본객체의 확장에 시각적이고 이용가능한 정보량을 제한하는 인터페이스로써의 기능을 한다.
그러나, 확장 개념에 이용되는 여분의 인터페이스 층이 있고, 이것은 확장뷰에 의해서 정의되는 인터페이스이다. 확장뷰는 뷰를 이용한 확장에 의하여 액세스 될 수 있는 확장 가능한 객체 명세서안에 정보의 서브세트를 정의한다.
도 3은 확장의 원리를 도시한다. 도 3에서, 블록(302)은 기본객체의 명세서를 나타내고, 블록(304)은 확장객체의 명세서를 나타낸다. 상기 명세서(302)는 4개의 상태를 가진 유한 상태 기계(308)가 가리키는 블록(306)에 도시된 바디법(body method) "BODY"를 포함한다. 이러한 상태는 2개의 확장점(s1 및 s2)을 포함한다.블럭(310)에 의해 지시된 확장점에 있어서,상기 확장점(s1 및 s2)은 접속점과 연속점으로 선언되는데, 이것은 각각 "TOP s1" 및 "COP s2"로 지시된다.
블록(312)은 5개의 상태를 갖는 유한 상태 기계에 의하여 기본객체의 명세서에 다른 방법 "Method ml"을 나타낸다.
상기 확장객체의 명세서(304)는 확장방법 "EXTENSION METHOD ext1"를 포함하고 있는데, 이 방법에는 개시상태(start state)(t) 및 종료상태(end state)(S2)를 포함한 3개 상태의 유한 상태 기계가 블록(314)에 도시되어 있다. 또한, 확장방법 "METHOD ext2"는 4개의 상태를 포함하여 블록(316)에 도시되어 있다.
상기 확장점(s1 및 s2)은 확장객체로부터 확장뷰(310)를 통하여 볼수 있다. 기본객체의 방법(308)이 상태(s1)에 도달할 경우, 상기 실행제어는 확장방법(ext1)을 거쳐 접속되는데, 이것은 화살표(318)로 나타냈다.
상기 확장방법(ext1)은 프로그램의 원점(t)상태에서 실행을 개시한다.
상기 실행이 확장으로 상태(s2)에 최종적으로 도달하는 경우, 상기 제어는 상기 상태(s2)로부터 실행을 지속하는 상기 베이스로 화살표(320)를 따라 복귀 접속한다.
이것은 실행시간 시스템에 의해 실행된다. 즉, 상기 확장의 설계자는 확장 선언(declaration)이외에 그의 코드로 이것을 명료하게 관리할 필요성은 없다.
앞서 언급된 바와 같이, 상기 카테고리 BASE는 차후에 확장될 수 있는 기본 기능들을 모델링하는데 이용된 객체형 카테고리이다. 상기 기본객체는 몇가지 특별한 특성을 가지고 있다.
한가지 중요한 특성은 기본객체의 실행이 반 병렬 스레드(semi-parallel thread)로 반드시 실행된다는 것이다. 이것은 당연하다. 왜냐하면, 상기 기본객체의 객체는 다른 시스템과 병렬로 처리될 수 있는 다른 임무를 독립적으로 위치시키는 임무를 수행하기 때문이다. 실행하는 동안, 상기 객체는 상기 실행을 한층더 중지시키고 다른 스레드로 제어를 전달하는 상태인 대기상태로 들어간다. 상기 실행은 대기상태에서 대기하는 이벤트를 받을 때까지 계속된다.
사용자의 관점에서, 이러한 특성은 현재의 실행 스레드안에 새로운 기본객체 실예를 만들고 새로운 스레드에서 차후의 실행에 대비하여 이러한 기본객체의 실예인 바디방법 "BODY"을 미리 예정 시킴으로써 달성될 수 있다. 스레드 스위칭은 제1의 현행 스레드가 대기 상태로 들어갈때 실행된다. 이러한 단계에서, 신규로 생성된 스레드는 실행을 개시할 기회를 얻는다. 그러나, 실행을 준비하고 있는 프로세서의 다른 스레드가 될 수도 있다. 결과적으로, 상기 신규 스레드가 어떤 순간에 정확히 실행을 개시할 것이라고 보장하지 못한다. 단지, 조만간에 실행을 개시할 것이라는 것은 보장한다.
상기 신규 스레드의 생성과 관련하여 새롭게 생성된 객체에 관한 참조문은 복귀된다. 이러한 참조문은 스레드 종료시 반드시 나타나는 이벤트를 대기시킴으로써 상기 생성된 스레드의 종료를 동기시키기 위하여 차후에 이용할 수 있다. 또한, 상기 참조문은 반박문으로써 이용되거나 한 속성에 기억될 수 있지만, 어떤 다른 목적으로 이용될 수 없다.
기본객체의 다른 중요한 특성은 그것의 속성과 방법이 확장객체 이외의 모든 다른 객체에 대하여 숨겨져 있다는 것이다.
기본객체에 대한 명세서와 실현 설명, 즉, 설계 언어를 이용하여 기능을 설명할 수 있다는 것이다. 상기 명세서의 객체는 상기 기본객체의 인터페이스 설명과 같이 주로 작용한다.
상기 명세서와 관련한 기본객체에 다른 종류의 클라이언트가 있다.
첫째, 상기 기본객체의 기능을 확장하는 확장객체이다.
이에 대하여, 상기 명세서는 확장에 이용가능한 상태, 속성 및 방법을 보여주는 인터페이스 설명과 같이 작용한다. 또한, 액세스 제한은 그것이 사용하는 확장에 의해서 확장에 도입될 수 있지만, 상기 기본객체에 대하여 명세서에 도시된 것 이상으로 결코 액세스될 수 없다.
둘째, 상기 명세서는 상기 기본객체의 실예를 생성하는데 필요로 하는 클라이언트 객체 쪽으로 인터페이스를 명확히 한정한다.
이러한 인터페이스는 기본객체형 방법에 의해서 정의된다. 이들은 새로운 실행 스레드가 상기 기술된 바에 의하여 생성될 수 있을 때 새로운 실예의 생성에 이용될 수 있는 매개변수를 결정한다.
상기 명세서의 다른 객체는 기본객체 형태의 기능을 고 레벨 설명을 제공한 반면, 상기 객체 형태의 기능을 이해하는데 필요없는 실행의 세부사항은 생략하였다. 상기 고 추상레벨은 기본객체에 이용되는 객체 논리로 생성한 추상층에 의해 부분적으로 제공되지만, 객체 논리를 사용하는 기본객체의 국부적인 방법을 통하여도 제공된다. 명세서의 명백한 추상레벨은 상기 명세서의 기본객체에 대한 대기 상태를 나타낼 수 있고, 아마도, 상기 기본객체의 기능을 이해하는데 근거가 되는 비대기 상태를 나타낼 수도 있을 것이다. 상기 도시된 상태간의 실행 코드는 명백한 국부방법으로 도입될 수 있지만, 상기 명세서에서 필수적으로 지정한 기능은 아니다.
상기 명세서에 무엇을 도시하고 도시하지 않아야 될지를 결정할 경우에는 객체의 어느 부분이 미래에 확장으로 노출될 수 있는지 알아야 한다. 바디방법의 명세서에 있어서, 가장 확장 가능한 명세서 기법은 대기상태와 비대기 상태와 같은 모든 상태, 및 모두 명백히 명명된 확장점을 도시하고, 국부방법으로 상태전이에 이용되는 실행코드를 단지 통합화(encapsulate)하는 것이다. 다른 한편, 상기 기능의 어떤 부분이 확장될 필요없다면, 이 부분은 국부적인 방법으로 완전하게 안내된다. 이러한 국부방법들은 상기 명세서 또는 실현으로 정의되거나, 실행레벨상에서 정의 될 수 있다. 만약 이것이 명세서로부터 호출된다면, 명세서에서 선언되어야 한다.
객체 형태 실현의 목적은 확장할 필요가 없거나 확장될 수 없는 일부 기본객체 및 고 레벨 설명서를 만들기 위하여 명세서에 도시할 필요성이 없는 일부 기본객체가 아니라, 실행 언어를 직접 이용하는 대신에 설계 언어가 가지고 있는 정의를 이용하는 것이 적합한 일부 기본객체를 이용하는 것이다.
실행 코드를 통합한 국부적인 방법의 정의는 여기에서 내려질 것이다. 또한 상기 명세서에 포함된 작용의 정의를 생략하고, 더욱 상세한 정의를 설명하는 것이 가능하다. 이렇게 새롭게 정의된 기능 정의는 상기 명세서에 주어진 기능 명세서를 세밀히 다듬어야 한다.
실현시에 정의되거나 선언되는 방법, 속성 또는 상태는 이러한 객체 형태의 확장에 이용되지 않는다는 것을 강조해야 한다. 상기 객체 형태 명세서의 정보는 확장으로만 볼 수 있다.
또한, 명세서만을 이용하는 전체 기본객체를 상기 설계어로 특정화하는 것은 가능하며, 이 언어로 실현하는 것은 불가능하다. 이러한 경우에, 상기 실행어는 상기 명세서의 몇가지 작용방법을 정의하는데 적합하게 이용될 수 있다. 그러나, 이벤트의 모니터링 "MONITOR" 및 모니터링 중지 "STOP MONITOR"는 명세서 또는 실행 중 한가지는 설계어로 실행될 수 있다. 만약 객체의 "생성/제거"가 설계어로 실행되는 경우, 동일한 객체에 대한 메시지 "제거/신생(new)"은 명세서에서 또는 실행중에 설계어로 실행되어야 한다.
이와 반대로, 만약 생성/제거가 실행어로 실행된다면, 또한 해당 메시지의 제거/신생은 실행어로 실행되어야 한다.
상기 객체의 바디방법(BODY)에 있어서, 이러한 정의가 매우 간단하게 될 수있고 실행시 무시될지라도, 상기 명세서에서 설계어로 기능정의를 당연히 하여야 한다. 상기 기본객체의 다른 방법들은 언급한 바와 같이 선택적으로 설계어를 이용한다.
도 4 및 도 5는 기본객체 형태의 객체 "the Base"에 대하여 명세서와 실행의 예를 각각 도시한 예시도이다.
도 4에 도시된 명세서에 있어서 바디방법 "BODY methodl", "method2", 및 "CONSTRUCTOR"은 7번째 줄에만 선언되어 있다.
구조(CONSTRUCTOR)는 객체 형태의 실예를 생성시에 실행되는 방법이다.
도 5의 2번째 줄에는 "CONSTRUCTOR", "method1" 및 "method2"와 같은 방법들의 실행시에 나타나는 작용을 정의한다. 상기 바디방법은 명세서에 바디방법과 같이 되도록 언급된다(22번째 줄).
앞에서 언급한 바와 같이, 기본객체 형태의 명세서는 클라이언트에 대한 인터페이스 설명같이 설명한다. 클라이언트는 확장을 위하여 확장 가능한 액세스를 더욱 제한하는데 이용된다.
여분의 인터페이스 층을 갖는 목적은 어떤 확장이 확실한 객체를 만들 수 있는지를 감시하는 것이다. 다른 확장뷰는 다른 목적으로 생성될 수 있다. 예컨데, 만약 어떤 뷰가 지불기능과 통계기능을 할 수 있게 설치된다면, 상기 확장된 객체의 상태와 속성에 있는 작은 서브세트만 보여주면 충분할 것이다.
다른 사용법은 다른 기능을 위하여 정의한다. 그 결과, 어떤 뷰의 확장에 사용하는 것은 확장된 객체의 어떤 기능이 수정되는 것을 의미한다. 이와 비슷한 정보는 새로운 확장기능이 시스템에 안내될 때 실행에 필요시 될 수 있는 확장기능사이의 조정을 검사할 때의 값이 될 수 있다.
따라서, 기본객체는 몇 개의 다른 확장뷰를 가질 수 있다.
그러나, 각각의 확장객체는 특정 확장뷰를 위하여 설계된다. 확장뷰들은 다른 것을 분석할 목적으로 설계위상 동안에만 이용되고, 실행시간 환경에서 각 장치와 같이 존재하지 않는다.
도 6에서는 도 4에 있는 기본객체 형태의 객체(the Base)에 대한 확장뷰의 일예를 무시한다.
확장뷰는 확장 가능한 객체의 명세서에 대해 제한된 뷰를 생성하는데 이용된다. 상기 확장뷰는 상기 기본객체에서 이미 이용할 수 없는 어떠한 정보도 정의할 수 없다. 상기 뷰들은 또다른 제한을 부과하고 이미 기본객체에서 본 정보를 숨길 수 있다. 이미 상기 기본객체에서 특정한 제한은 무시될 수 있다.
상기 확장뷰에 있어서, 도 6의 3 내지 6라인상에 확장을 통하여 얻을 수 있는 기본객체의 방법과 속성에 대한 목록이 우선적으로 주어져 있다. 이 목록은 상기 기본객체에 현존하는 속성과 방법의 서브세트를 정의한다. 이 위에는 확장에 이용될 수 있는 확장점이 목록된다. 상기 뷰안의 각 확장점에 대하여 다음과 같이 정보가 특정화된다.
도 6의 7, 11, 15, 및 18라인의 확장점 이름은 TOP WAIT STATE, TOP COP STATE, TOP STATE 및 COP STATE이다. 상태가 되는 확장점에 대한 키워드(key words) STATE 및 WAIT STATE는 그 이름으로 주어진다. 명백히 명명된 확장점에 대하여 상기 정보는 제공되지 않는다. 또한, 상기 명칭은 확장점의 형태를 포함한다.즉, 접속점(TOP), 연속점 (COP) 또는 접속 및 연속점(TOP COP)과 같이 언급된다. 앞서 언급한 바와 같이, 상기 기본객체의 모든 확장점은 접속 및 연속점 형태이다. 여기서, 확장점은 접속점 또는 연속점으로만 이용할 수 있게 제한될 수 있다.
만약 이런 기본 설정이 이용될 수 있다면, 키워드(TOP COP)는 제공되어야 한다.
- 각 접속점에 대하여는 도 6의 9, 12 내지 13, 및 16라인에 상기 특정 접속점에서 개시하여 확장방법에 이용될 기본객체의 속성과 방법의 목록이 있다. 이러한 목록은 확장뷰의 초기에 목록된 속성과 방법의 서브세트이다.
- 각 접속점에 대한 연속점(COPs)의 목록이 도 6의 8라인에 제공된다. 이러한 정보는 어느 확장점이 현재의 접속점에 제어를 접속하여 확장이 연속적으로 일어나는지를 결정하는데 이용된다.
- 접속점에 대하여 기본객체의 상태로 나누는데 이용된 표현식의 형태가 지시된다. 이것은 비대기 상태에만 관련있다.
확장뷰안에 기본객체의 방법에 나타나는 국부 변화를 언급하는 것이 불가능하다.
또한 확장 개념이 확장으로 확장을 허용하기 때문에, 확장뷰는 기본객체와 확장객체 모두를 생성할 수 있다. 확장객체에 대한 동일한 제한은 기본객체에 대하여도 허용된다. 그들 구성원들은 확장이외에 어떤 다른 객체에 의해 액세스될 수 없다.
또한, 확장객체에 대한 명세서와 실현은 제공될 수 있다. 이러한 정의가 매우 간단할 지라도 확장객체의 확장방법은 가능 정의를 명세서의 설계어로 당연히 해야 하고, 이것은 상기 실현으로 무시될 수 없다. 확장객체의 다른 방법에 있어서, 설계어의 사용은 선택적이다.
도 7, 도 8 및 도 9에는 확장 형태 "theExtobj"에 대한 객체의 명세서, 동일한 객체의 실현, 및 의문시 객체의 확장뷰에 대한 일예들이 도시된다.
확장은 카테고리 확장의 객체로 통합된다. 도 7을 참조하면, 확장객체의 명세서는 확장객체에 의해 이용된 뷰(참조 8라인), 및 상기 실행 방법에 대한 우선권 그룹을 정의한다. 몇 개의 다른 확장객체는 기본객체의 동일한 뷰에 이용할 수 있다. 또한, 다수의 확장은 동일한 객체의 동일 확장점으로부터 개시할 수 있다.
확장객체의 방법은 기본객체와 동일한 스레드에서 반드시 실행된다. 또한, 상기 기본객체에서 실행된 이벤트의 모든 모니터링은 상기 확장방법으로 확실하게 된다. 다르게 말해서, 이벤트 발생기가 뷰를 거쳐 확장방법에 이용할 수 있게 일치한다면, 상기 확장방법은 상기 기본객체에서 모니터링되는 이벤트를 수신할 수 있다.
확장방법(EXTENSION METHODS)에 대한 명세서의 상태는 기본객체의 BODY에 대한 명세서의 상대와 동일한 방법으로 접속점 및 연속점으로서 이용될 수 있다. 상기 확장방법의 실현(참조 도 8)은 동일한 방법으로 몇가지 상태를 부과할 수 있지만(참조 2 및 8라인), 다시 다른 확장에 이용할 수 없다.
또한, 확장객체(theExtobj)로의 확장은 도 9의 확장뷰로 지시된 확장에 따라서 프레임의 형태로만 이루어 질 수 있다.
도 10은 상기 개념의 기본객체, 확장객체와 확장뷰 사이의 관계뿐만 아니라 객체 형태 명세서, 실현 및 실행의 개요를 요약하여 제공한다.
도 10에 있어서, 스택블럭(1002)은 명세서(1004)와 실현(1006), 및 타켓 언어의 실행(1008)을 설계어로 지시한다.
동일한 방법으로 블록(1010)은 설계어로 명세서(1012)와 실현(1014), 및 타켓언어로 실행(1016)을 지시한다.
상기 기본객체의 명세서(1004)는 상기 객체 형태의 기능을 전체적으로 이해하는데 이용될 수 있는 적당한 추상레벨상의 명세서이다. 상기 명세서는 속성과 방법기호 선언 및 방법의 기능 명세서(서브세트)를 포함한다. BODY방법의 기능 명세서에 도시된 모든 상태는 확장에 의하여 이용될 수 있다.
상기 기본객체의 실현(1006)은 상기 객체 형태의 작용을 더욱 상세히 설명한다. 객체 형태 명세서에서는 방법의 작용정의를 무시할 수 있다. 또한, 이러한 작용은 아니다. 상기 실현에 국부적인 새로운 속성과 방법은 부과될 수 있다. 이러한 실현에 부과된 정보는 확장에 이용할 수 없다. 명세서는 한 개 이상 실현할 수 있다.
타켓 언어로 기본객체 형태의 실현(1008)은 객체 형태를 완전하게 실행한다. 이것은 타켓언어(C++)에 대하여 발생되고 선택적으로 손으로 쓴 소오스 코드를 구성한다. 이렇게 발생된 부분은 객체 형태 명세서에 따라 확장하기 위하여 실행을 준비하는 것을 보증한다. 이 실행 코드는 객체 형태 명세서를 이용하고, 설계어로 객체 형태의 한 개 이상 실현을 선택적으로 이용함으로써 발생된다.
도면번호(1018 및 1020)에는 기본객체 형태 명세서의 확장뷰가 지시된다. 동일한 객체 형태 명세서의 몇가지 뷰가 될 수 있지만, 각 뷰는 반드시 정확하게 객체 형태 명세서에 설계된다. 새로운 뷰들은 기본객체 명세서, 실현 또는 실행에 영향없이 생성될 수 있다. 상기 기본객체 형태 명세서(1004) 및 그 뷰(1018 및 1020)는 확장객체 형태를 설계할 때 이용된다.
상기 확장객체 형태의 명세서(1012)는 기본객체 형태의 명세서와 동일한 고 추상레벨상에 확장객체를 특정한다. 또한, 상기 확장객체 형태의 실현(1014) 및 실행(1016)은 기본객체 형태와 동일한 방법으로 나타난다.
상기 확장객체 형태에 대한 각 명세서는 한 개의 확장뷰(1022)를 정확하게 이용함으로써 향상 설계된다. 기본객체 형태에 대한 케이스와 유사하게 한 개 이상의 확장뷰는 한 개의 확장객체 형태를 위하여 정의될 수 있다.
코드 발생에 관하여 다음과 같이 언급될 수 있다.
타켓 언어(C++)의 코드는 객체 형태 명세서와 실현때문에 발생된다. CONSTRUCTOR, BODY를 포함한 모든 방법 및 명세서의 추상 방법은 실현이 반복되어야 한다. 기본객체 형태의 각 실현 및 확장객체 형태의 각 실현은 다음과 같은 규칙에 따라 이루어져야 한다.
- 상기 명세서에 지시되어 있는 각 방법 서명(themethodname dom_FormalArguments[RETURNSdom_Type] part)은 상기 실현에 반드시 존재해야 한다. 이러한 요건은 다음에 기술될 방법중에 한가지로 채워질 수 있다.
서명(signature)의 개념은 그것의 명칭을 개시하는 것에 의한 질문의 요소, 여기서는 방법. 즉, 논증 형태 및 복귀값 형태를 확인하는 것을 의미한다.
- 방법의 서명만을 상기 명세서에서 연구하는 경우, 상기 BODY방법은 실현시 생략하거나 개시될 수 있다. (thedom_BehaviourBody, 즉, the is BEGIN...END part).
상기 BODY방법이 실현시 생략되는 경우, 상기 방법의 핵심만이 타켓 언어로 실현된다.
- 만약 BODY방법이 실현시 개시되면 완전한 완료부호는 타켓 언어로 발생된다.
- 만약 상기 명세서에 이미 BODY방법이 있으면, 명세서 같은 키워드는 실현시 BODY 방법이 명세서와 정확히 동일한지를 지시하는 실현에 이용될 수 있다. 완료 타켓 언어 부호는 이러한 경우에 발생될 것이다. 이 코드는 매뉴얼을 변경하거나 부과하는 것으로 이용되지 않을 것이다.
- 상기 명세서와 실현이 동일한 방법을 위하여 BODY방법을 정의한다면, 완료부호는 실현시 개시된 BODY방법으로 발생된다. 이것은 실현시 정의된 기능이 명세서에서 언급한 작용을 항상 무시하는 것을 의미한다.
상기 명세서에서 언급한 속성은 실현시 반복되지 않는다.
상기 실현시 언급한 방법 정의가 명세서의 해당 정의를 완전히 무시한다는 사실때문에, 또한 명세서에서 언급한 국부 변수는 실현시 반복되어야 한다.
따라서, 확장 매커니즘의 사용을 도시하는 몇가지 일예들이 도 11 내지 도 14를 참조로 기술된다.
조건없는 확장의 일예는 도 11에 도시되어 있다. 이러한 일예들은 기본객체 및 확장객체의 명세서들이 상기 도면에 도시된 바와 같은 상태로 된다는 가정에서 시작한다. 또한, 도시되어 있지않은 확장뷰에 있어서는 TOP같은 상태분석(1102) 및 COP같은 호출상태(1104)로 된다.
일반적으로 모든 확장객체들은 실행이 TOP 같은 상태에 도달할 때 점검된다. 만약 현재의 TOP 상태로부터 개시하는 실행방법이 존재하면, 상기 실행 방법은 호출된다. 상기 실행시간 시스템은 해당 확장객체가 확장객체의 확장방법을 처음 호출하기 이전에 생성되어 있다는 것을 확인할 것이다. 만약 기본의 실행동안에 호출한 것이 처음이 아니라면, 상기 확장방법은 호출되고, 상기 확장객체의 구 사례는 다시 이용될 수 있다.
따라서, 이러한 객체는 동일한 기본의 실행 동안에 확장방법의 호출 사이의 상태로 복귀할 것이다. 확장객체 형태의 사례는 각 기본객체에 대하여 만들어진다. 즉, 확장객체는 2개의 베이스에 의해 공유되지 않는다.
도 11에 도시된 일예에 있어서 전이는 베이스의 실행이 상태분석(1102)에 도달하는 매 시간마다 무조건적으로 확장방법에 항상 형성된다. 이것은 화살표(1108)로 표시된다.
확장방법의 실행을 끝내는 다른 방법이 있다. 첫째, EXIT는 전체 실행 스레드의 실행을 종료하는데 이용될 수 있다. 둘째, 확장으로부터 제어를 받은 베이스로 제어를 복귀시키는 것을 지시하는데 이용되는 BACK(기본로)(특별히 가능함)이 있다. 셋째, 보통 종료 상태는 이용될 수 있지만 특별한 의미를 가진 확장방법에 이용된다. 이 경우에 COP상태는 확장방법의 종료 상태와 동일한 명칭을 갖는 베이스에서 우월해야 한다.
확장이 이러한 종료상태에 도달할 때, 상기 확장방법의 실행은 중단될 것이고, 상기 베이스의 COP상태로 계속진행 할 것이다.
확장을 개시한 기본의 상태로 EXIT 와 BACK 사이의 차이는 한 개 이상의 실행을 동일한 TOP에 접속하는 경우에 일어날 것들이다. BACK을 이용할 때 다음 실행은 차례로 실행될 것이다. 가장 높은 우선권 그룹의 확장은 항상 처음 실행되고, 만약 동일한 우선권 그룹에서 한 개 이상의 실행이 존재하면 임의의 순서대로 정상 실행된다. 그러나, 확장간에 실행순서가 정해져 있는 간접실행 엔티티(entity)가 있다면, 그 순서대로 실행된다.
만약 EXIT가 실행을 개시한 베이스에서 TOP상태로 실행된다면, 상기 기본의 TOP상태는 유사하게 다시 실행되는 모든 접속 확장으로 다시 실행될 것이다.
조건 확장(condition extention)의 일예는 도 12에 도시된다.
조건 확장은 어떤 조건을 만족시키는 경우에만 실행한다. 이 경우는 확장방법의 최초상태와 관련있는 CASE표현식에 의하여 열거된다.
상기 예는 확장객체 및 기본객체의 명세서가 도면에 도시되어 있는 것과 같이 표시한다는 가정에서 시작한다.
또한 도시않된 확장뷰에 있어서 상태분석은 TOP와 같은 상태로 되고, a와 b는 기본객체의 속성이다.
상기 기본객체가 상대분석(1202)에 도달할 때, TOP점으로부터 개시하는 확장이 존재한다. 다음에 상기 확장방법은 확장방법의 초기 상태와 관련있는 CASE 표현식에 의해 그 실행을 개시할 것이다(1204). 이러한 표현식의 값은 위와 같은 흐름의 분기(branch)를 나누는데 이용된다.
이 경우에 상기 베이스의 CASE표현식 값으로 간단한 RESULT기준을 문의하는데, 이것은 도면번호 1206에 도시된다.
상기 표현식(a+b)은 계산된다. 만약 이 값이 3이면, 이 3이라는 값에 의해 지시된 분기(bronch)가 선택되고(1208), 실행은 확장을 계속한다. 다른 방법으로, 상기 DEFAULT분기가 선택되고(1210), 실행제어는 기본으로 복귀된다. 다음에, 상기 기본은 CASE표현식을 재평가하고, 그 평가에 따라 적합한 분기를 계속한다.
상기 확장방법의 최초 상태와 관련있는 CASE표현식은 매우 간단하지만, 스칼라(scalar)형태의 임의의 표현식이 될 수 있다.
RESULT는 상기 베이스의 비대기 상태시 CASE 표현식의 결과를 베이스로 확장을 할 수 있게 하는데 이용된 키워드이다.
RESULT는 각 표현식에 이용될 수 있지만, 그 값은 전체 확장방법을 실행하는 동안 변경될 수 없다. 만약, 적당한 분기나 DEFAULT분기가 없다면 에러이다. 만약 상기 실행방법이 상기 베이스와 동일한 값을 갖는 분기를 가지면, 상기 확장법은 베이스를 무시한다.
만약 상기 확장이 베이스의 대기 상태에서 개시하면, 상기 확장법의 최초상태는 대기한 이벤트를 지정하는 대기 상태와 같게 되어야 한다. 대기 상태시 모든 확장방법에 대하여 기대된 상태는 간단한 WAIT-FOR-EVENT시 상기 지점에서 수집된다.
도 13은 이벤트 확장이 일예를 제공하고, 기본객체 및 확장객체의 명세서가 상기 도면과 같다는 가정에서 시작한다.
또한, 상기 Ring-B는 도시않된 확장뷰의 TOP같이 열거한다.
기본객체가 상태 Ring-B에 도달할 때(1302), 상기 TOP점에서 개시하는 확장이다. 상기 실행시간 시스템은 모니터되어야 할 이벤트에 관하여 확장객체로부터 정보를 수집한 다음, 이 정보를 상기 기본객체의 대기 상태 정보와 합친다. 이러한 방법으로, 복합 대기 상태는 만들어지고 안내된다. 다음에 나타나는 이벤트에 의존해서 상기 확장 또는 베이스중 하나는 실행될 것이다. Block-EV(1304)이 확장시 지정되면, 상기 확장법은 실행된다. 상기 베이스는 실행되고, off-hook인 경우 베이스에 지정되고(1306) 수신된다.
2개의 확장은 동일한 이벤트, 또한 상기 베이스같은 동일한 이벤트를 기다릴 수 있다. 상기 최고의 우선권을 가진 확장은 다음에 실행될 것이다.
확장 및 대기 상태는 BACK을 실행할 수 없고, 이들은 베이스 또는 EXIT에 COP상태로 진행할 것이다. 상기 실행법의 실행이 상기 실행법의 최초 상태로 돌아가면(예, 상기예의 "개시") 상기 확장법은 다시 실행되지만, 이 시간에는 상기 확장법으로 지정된 이벤트만이 대기된다. 만약 "전체(the whole)" 대기 상태가 다시 도입되면, 상기 대기 상태는 상기 기본의 TOP COP상태는 확장법으로 상태가 이루어져야 한다.
또한, 상기 기본객체는 특정 우선권 순위로 편제되고, 실행은 이러한 우선권 순위에 따라 실행된다. 즉, 최고 우선권을 가진 확장객체는 첫 번째로 실행된다.
만약 이러한 실행이 그것의 실행제어를 베어스로 복귀시키면, 다음에 최고 우선권을 가진 확장객체가 실행된다. 만약 모든 확장이 실행제어를 돌려보내면, 또한 베이스가 실행될 것이다.
만약 확장법이 상기 베이스에 연속점으로 지속하면, 더 이상 확장법은 관리될 수 없다. 상기 실행은 상기 베이스에서 아주 간단하게 지속할 것이다. 물론, 상태 "연속"은 확장할 수 있다. 만약 이것이 위와 같은 경우이면, 모든 것은 새롭게 시작한다.
도 14에는 3개의 확장법 제2, 제3 및 제4(1402, 1404, 및 1406), 그리고 TOP COP(1412)같이 선언되는 확장점 R(1410)을 가진 베이스(1408)가 도시된다..
상기 제1확장은 베이스(1414)에서 "연속" TOP COP을 실행한다. 상기 2개의 다른 확장은 TOP COP상태(1410)로부터의 접속(1416 및 1418)으로 각각 흐른다. 상기 확장법(m3)은 BACK을 이용하여 실행제어를 베이스로 복귀시킨다. 만약 m3가 m4보다 높은 우선권을 가지면, m3가 실행제어를 복귀시킨다는 조건하에서, m3가 먼저 실행되고, 다음에 m4가 실행된다.
만약 m4가 m3보다 높은 우선권을 가지면, m4만이 실행된다. 이 경우에, m4는 m4가 결코 베이스로 복귀하지 않는다는 사실에 기인하여 실행될 가능성은 없다.
또한, 보조 기능들 간에 상호작용을 관리하는 상호작용 관리 확장기능을 실행할 객체 형태가 될 수 있다. 보조 기능들의 상호 작용에 대한 이용은 초기의 스웨덴 특허출원 제93-02024-6호 및 제94-00209-4호에 기술되어 있다. 따라서, 기본 기능에 의해 실행되는 것 같이, 선 출원에 포함된 도면 15a/15b를 참조로 후 출원에서 설명한 방법들은 상호작용 확장객체에 의하여 실행될 수 있다. 그러한 인과 관계 속에서, 한 개로 많은 확장 접속을 하고 기본객체에 있는 동일한 TOP점에 관하여 도 14를 참조하여 앞서 기술한 개념을 이용할 수 있다.
따라서, 대화 관리 확장객체는 2개의 대화 확장기능을 각각 하나씩 나타내는 2개의 확장객체 같이 기본객체에 있는 동일한 TOP점에 접속될 수 있다. 대화 문제점을 해결하기 위하여 스웨덴 특허출원을 이미 참조하였다.

Claims (25)

  1. 가입자 서비스를 제공하고, 다수의 기능층, 즉,오페레이팅 시스템 기능을 갖는 한 개의 층(102)과, 상기 층위에 위치되고 자원객체(resource objects )의 형태로 통신 추상화를 갖는 어플리케이션 플랫폼과, 상기 플랫폼상에 위치되고 기본 서비스와 보조 서비스를 제공하는 기본기능과 보조기능 형태의 바람직한 어플리케이션을 갖는 최상층(106)을 포함하는 통신시스템용 객체 지향 시스템 플랫폼에 있어서,
    상기 최상층은 기본객체(202)와 확장객체(204, 206, 208)로 실행되는 것을 특징으로 하는데,
    상기 기본객체는 장래에 확장될 필요성이 있는 기본 기능을 실행하고, 다른 기본객체와 최소의 조정으로 실행될 수 있는 특정 임무를 위하여 각각 설계되는 객체의 형태이며,
    상기 확장객체는 상기 기본 기능으로 확장하고, 신규 서비스의 부과 및 이미 실행되고 제공되는 시스템의 소프트웨어를 변경하지 않고 현존 서비스를 수정하고 확장할 수 있는 확장기능을 실행하는 객체 형태인 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  2. 제1항에 있어서,
    상기 확장객체는
    확장기능(208)을 실행하고 이 확장기능으로 확장을 형성하는 객체 형태를 포함하는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  3. 제1항 또는 제2항에 있어서,
    상기 확장객체는
    보조 서비스들 간의 상호작용을 관리하는 상호작용 관리 확장기능을 실행하는 객체 형태를 포함하는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  4. 제1항 내지 제3항중 어느 한 항에 있어서,
    상기 확장객체는
    수정될 수 있는 기본객체를 동적으로 수정해야 하는 동작시에 시스템안으로 확장을 유도할 수 있게 설계되어 있는 것을 특징으로 하는 통신시스템용 객체지향 플랫폼.
  5. 제4항에 있어서,
    상기 확장은
    실행시간 안에 각 확장을 활성/비활성하기 위하여 특별히 제공한 프로그램 없이 일반적인 방법으로 시스템의 수정을 부과하고 제거할 수 있게 설계되어 있는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  6. 제5항에 있어서,
    기본객체와 확장객체 형태의 작용은
    유한 갯수의 상태 및 이러한 상태간의 전이(transition)로 구성하는 유한 상태 기계(finite state machine)의 방법을 각각 포함한 방법의 작용을 기술함으로써 정의되는데, 상기 전이 작용으로 상기 코드가 실행되고, 상기 확장은 상기 실행제어를 확장점에 접속하고 동일한 방법으로 다른 확장점 또는 동일한 확장점으로 상기 제어를 복귀시키기 위하여 상기 상태에 부가되는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  7. 제1항 내지 제6항중 어느 한 항에 있어서,
    상기 기본객체 및 확장객체 형태는
    특별히 미리 정한 확장점으로 상기 실행제어를 접속하는 것에 의해 상기 시스템의 작용을 간접적으로 수정하는 상기 시스템에 확장 정의만 로딩(loading)시킴으로써 시스템의 현재 실행을 변경하기 위하여 필요시되는 확장개념없이 시스템의 수정 및 확장을 할 수 있는 확장개념을 제공하는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  8. 제1항 내지 제7항중 어느 한 항에 있어서,
    상기 확장객체의 명세서는
    상기 확장객체의 어느 확장점에서 상기 확장이 상기 제어를 접속하고, 어느 확장점이 상기 제어를 복귀시킬 수 있는지를 정의하는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  9. 제8항에 있어서,
    상기 확장객체가 상기 제어를 접속할 때, 소정의 확장방법이 실행을 개시하는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  10. 제8항 또는 제9항에 있어서,
    상기 실행시간은
    상기 상태의 확장점에서 확장객체의 생성 및 그 확장방법의 호출을 조정하는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  11. 제1항 내지 제12항중 어느 한 항에 있어서,
    상기 확장객체는
    상기 확장을 제어에 접속하는 확장객체 또는 기본객체의 속성과 방법으로 액세스하는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  12. 제11항에 있어서,
    상기 속성과 방법은
    액세스될 수 있는 객체 형태 명세서에 선언되어 있는 그러한 것만 포함하는 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  13. 제8항 내지 제12항중 어느 한 항에 있어서,
    상기 객체 형태 명세서에는
    상기 명세서의 속성과 방법의 특정 서브세트(subset)만이 어떤 확장점에 제어를 접속하는 확장에 이용할 수 있다는 것을 정의 함으로써, 각 확장점에 대한 액세스 제한을 정의한 것을 특징으로 하는 통신시스템용 객체 지향 플랫폼.
  14. 제7항 내지 제13항에 있어서,
    상기 확장가능한 객체에 대한 객체 형태 명세서는
    상기 확장가능 객체를 보거나 이용할 수 있는 정보량을 정한 인터페이스와 같이 작용하는 것을 특징으로 하는 통신시스템용 플랫폼.
  15. 제14항에 있어서,
    상기 인터페이스 층은
    상기 확장개념에 함께 이용되고, 뷰를 이용하는 확장에 의하여 액세스될 수 있는 확장가능한 객체의 명세서안에 정보의 서브세트를 각각 정의하는 확장뷰에 의해서 정의되는 것을 특징으로 하는 통신시스템용 플랫폼.
  16. 제1항 내지 제15항중 어느 한 항에 있어서,
    상기 기본객체에 대하여 확장에 이용가능한 상태, 속성 및 방법을 확인하는 인터페이스같이 작용하고, 신규 사례를 만들 때 이용될 수 있는 모든 변수를 결정하는 상기 기본객체의 사례를 만들 필요성이 있는 클라이언트 객체 쪽으로 인터페이스를 정의할 수 있는데, 상기 인터페이스는 상기 기본객체 형태의 방법에 의해 정의되는 것을 특징으로 하는 통신시스템용 플랫폼.
  17. 제16항에 있어서,
    상기 명세서는
    상기 객체 형태의 기능을 이해할 필요성이 없는 실행의 세부사항을 제거하는 동안 기본객체의 작용을 수준 높게 설명하는 것을 특징으로 하는 통신시스템용 플랫폼.
  18. 제17항에 있어서,
    추상화 층은 상기 기본객체에 의해 이용되는 근본적인 객체논리 및 상기 기본객체의 이용, 즉 고 추상화 레벨로의 기여를 포함하는 기본객체의 국부적인 방법에 의해 생성되는 것을 특징으로 하는 통신시스템용 플랫폼.
  19. 제18항에 있어서,
    상기 명세서의 합리적인 추상화 레벌은
    상기 명세서에 기본객체의 대기상태 및 상기 기본객체의 기능을 이해하는데 근본이되고 가능하게 선택된 몇가지의 비 대기상태를 확인함으로써 얻어지는데, 상기 도시된 상태사이의 실행을 위한 코드는 상기 명세서에서 선언은 되었지만, 필수적으로 작용이 열거될 필요성이 없는 국부적인 방법으로 유도되는 것을 특징으로 하는 통신시스템용 플랫폼.
  20. 제19항에 있어서,
    상기 명세서에 도시되도록 하는 것의 판단은
    장래에 노출될 수 있는 모든 객체의 일부분을 고려하는 것을 특징으로 하는 통신시스템용 플랫폼.
  21. 제20항에 있어서,
    모든 상태, 즉,대기상태와 비 대기상태 및 명백히 명명된 확장점은 상기 방법 명세서에 도시되어 있는데, 실행코드는 국부적인 방법으로 상태전이에 이용되는 것을 특징으로 하는 통신시스템용 플랫폼.
  22. 제20항에 있어서,
    만약 어떤 부분의 작용이 확장될 필요성이 없다면, 상기 명세서 또는 실현으로 정의되는 국부적인 방법으로 그대로 안내되거나 실행레벨상에 안내되는 것을 특징으로 하는 통신시스템용 플랫폼.
  23. 제22항에 있어서,
    상기 객체 형태 실현은
    필요성이 없거나 확장될 수 없고, 수준 높게 설명하기 위하여 상기 명세서에 도시할 필요성은 없지만, 실행어를 직접 이용하는 대신에 한 정의가 보다 적절한 일부 기본객체에 이용되는 것을 특징으로 하는 통신시스템용 플랫폼.
  24. 제23항에 있어서,
    상기 실현시에 실행코드를 안내하는 국부적인 방법의 정의가 도입되는 것을 특징으로 하는 통신시스템용 플랫폼.
  25. 제23항 또는 제24항에 있어서,
    보다 상세한 작용정의는
    상기 명세서에 포함된 작용정의를 무시하는 동안 명세서에서 제공되고 실현시에 제공되는 상기 작용 명세서의 세정을 암시하는 것을 특징으로 하는 통신시스템용 플랫폼.
KR1019980704284A 1995-12-08 1996-11-27 통신시스템용 시스템 플랫폼 KR19990071993A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SE9504392A SE517033C2 (sv) 1995-12-08 1995-12-08 Systemplattform för kommunikationssystem
SE9504392-3 1995-12-08
PCT/SE1996/001553 WO1997022197A1 (en) 1995-12-08 1996-11-27 A system platform for a communication system

Publications (1)

Publication Number Publication Date
KR19990071993A true KR19990071993A (ko) 1999-09-27

Family

ID=20400517

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1019980704284A KR19990071993A (ko) 1995-12-08 1996-11-27 통신시스템용 시스템 플랫폼

Country Status (11)

Country Link
US (1) US6601113B1 (ko)
EP (1) EP0865704A1 (ko)
JP (1) JP2000501865A (ko)
KR (1) KR19990071993A (ko)
CN (1) CN1207847A (ko)
AU (1) AU722262B2 (ko)
BR (1) BR9611920A (ko)
CA (1) CA2239885A1 (ko)
NO (1) NO982598L (ko)
SE (1) SE517033C2 (ko)
WO (1) WO1997022197A1 (ko)

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4196310B2 (ja) * 1998-10-26 2008-12-17 富士通株式会社 情報管理システムのメッセージ制御方法
FI109167B (fi) * 2000-03-14 2002-05-31 Sonera Oyj Palvelunkehitysympäristö
US20030093471A1 (en) * 2001-10-18 2003-05-15 Mitch Upton System and method using asynchronous messaging for application integration
US7552222B2 (en) 2001-10-18 2009-06-23 Bea Systems, Inc. Single system user identity
US7516447B2 (en) 2002-02-22 2009-04-07 Bea Systems, Inc. Methods and apparatus for building, customizing and using software abstractions of external entities
US7424717B2 (en) 2002-05-01 2008-09-09 Bea Systems, Inc. Systems and methods for business process plug-in development
US20040078440A1 (en) * 2002-05-01 2004-04-22 Tim Potter High availability event topic
US8135772B2 (en) * 2002-05-01 2012-03-13 Oracle International Corporation Single servlets for B2B message routing
US7257645B2 (en) 2002-05-01 2007-08-14 Bea Systems, Inc. System and method for storing large messages
US7155438B2 (en) * 2002-05-01 2006-12-26 Bea Systems, Inc. High availability for event forwarding
US7526519B2 (en) 2002-05-01 2009-04-28 Bea Systems, Inc. High availability application view deployment
US7493628B2 (en) 2002-05-02 2009-02-17 Bea Systems, Inc. Shared common connection factory
US7484224B2 (en) * 2002-05-02 2009-01-27 Bae Systems, Inc. Adapter deployment without recycle
US7676538B2 (en) * 2002-05-02 2010-03-09 Bea Systems, Inc. Systems and methods for application view transactions
US7222148B2 (en) * 2002-05-02 2007-05-22 Bea Systems, Inc. System and method for providing highly available processing of asynchronous service requests
US7584474B2 (en) 2003-02-25 2009-09-01 Bea Systems, Inc. Systems and methods for transaction chaining
US7293038B2 (en) * 2003-02-25 2007-11-06 Bea Systems, Inc. Systems and methods for client-side filtering of subscribed messages
US20040167915A1 (en) * 2003-02-25 2004-08-26 Bea Systems, Inc. Systems and methods for declaratively transforming data objects between disparate representations
US20050022164A1 (en) * 2003-02-25 2005-01-27 Bea Systems, Inc. Systems and methods utilizing a workflow definition language
US7774697B2 (en) * 2003-02-25 2010-08-10 Bea Systems, Inc. System and method for structuring distributed applications
US7650276B2 (en) 2003-02-26 2010-01-19 Bea Systems, Inc. System and method for dynamic data binding in distributed applications
US7539985B2 (en) * 2003-02-26 2009-05-26 Bea Systems, Inc. Systems and methods for dynamic component versioning
US8032860B2 (en) * 2003-02-26 2011-10-04 Oracle International Corporation Methods for type-independent source code editing
US7707564B2 (en) 2003-02-26 2010-04-27 Bea Systems, Inc. Systems and methods for creating network-based software services using source code annotations
US7076772B2 (en) 2003-02-26 2006-07-11 Bea Systems, Inc. System and method for multi-language extensible compiler framework
US20040230955A1 (en) * 2003-02-26 2004-11-18 Bea Systems, Inc. System for multi-language debugging
US7636722B2 (en) * 2003-02-28 2009-12-22 Bea Systems, Inc. System and method for describing application extensions in XML
US7444620B2 (en) * 2003-02-28 2008-10-28 Bea Systems, Inc. Systems and methods for a common runtime container framework
US7650592B2 (en) 2003-03-01 2010-01-19 Bea Systems, Inc. Systems and methods for multi-view debugging environment
US7270884B2 (en) * 2003-04-07 2007-09-18 Infineon Technologies Ag Adhesion layer for Pt on SiO2
US8539497B2 (en) * 2006-03-30 2013-09-17 Microsoft Corporation Method for organizing software so the set of extensions for an extendable application can be run securely
KR101369981B1 (ko) * 2011-10-06 2014-03-24 김용진 호 처리 부가 서비스 제공 단말장치 및 그 동작 방법
US9311054B2 (en) * 2013-08-30 2016-04-12 Sap Se Method and system for specifying and enforcing extensibility of software applications
CN104360870B (zh) * 2014-12-03 2018-07-17 北京和利时系统工程有限公司 一种实现对象建模的方法和装置
CN106059796B (zh) * 2016-05-17 2019-05-24 中国建设银行股份有限公司 一种业务扩展系统及方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5206951A (en) 1987-08-21 1993-04-27 Wang Laboratories, Inc. Integration of data between typed objects by mutual, direct invocation between object managers corresponding to object types
US5136712A (en) 1989-06-29 1992-08-04 Digital Equipment Corporation Temporary object handling system and method in an object based computer operating system
US5057996A (en) 1989-06-29 1991-10-15 Digital Equipment Corporation Waitable object creation system and method in an object based computer operating system
SE502733C2 (sv) 1993-06-11 1995-12-18 Ellemtel Utvecklings Ab Sätt att undvika ej önskvärd interferens mellan tjänster i ett telekommunikationssystem
SE502275C2 (sv) 1994-01-25 1995-09-25 Ellemtel Utvecklings Ab Sätt att optimera kapaciteten i ett telekomsystem
US6467085B2 (en) * 1995-10-17 2002-10-15 Telefonaktiebolaget L M Ericsson (Publ) System and method for reducing coupling in an object-oriented programming environment
US6119125A (en) * 1998-04-03 2000-09-12 Johnson Controls Technology Company Software components for a building automation system based on a standard object superclass

Also Published As

Publication number Publication date
WO1997022197A1 (en) 1997-06-19
CN1207847A (zh) 1999-02-10
NO982598D0 (no) 1998-06-05
CA2239885A1 (en) 1997-06-19
SE9504392D0 (sv) 1995-12-08
EP0865704A1 (en) 1998-09-23
NO982598L (no) 1998-08-07
BR9611920A (pt) 1999-03-30
JP2000501865A (ja) 2000-02-15
SE517033C2 (sv) 2002-04-02
MX9804495A (es) 1998-10-31
SE9504392L (sv) 1997-06-09
AU722262B2 (en) 2000-07-27
AU1045997A (en) 1997-07-03
US6601113B1 (en) 2003-07-29

Similar Documents

Publication Publication Date Title
KR19990071993A (ko) 통신시스템용 시스템 플랫폼
US6981266B1 (en) Network management system and method
Bruneton et al. Recursive and dynamic software composition with sharing
US7401331B2 (en) Method to add new software features without modifying existing code
US6490255B1 (en) Network management system
US7000220B1 (en) Networked software development environment allowing simultaneous clients with combined run mode and design mode
US6973638B1 (en) Execution of extended activity diagrams by code generation
Lumpe A [pi]-calculus Based Approach for Software Composition
JP2001524709A (ja) 通信環境におけるモジュール間のカップリングを低減するためのシステムおよび方法
JP2004505333A (ja) 通信サービスのプロビジョニング方法及び装置、及びプロビジョニング・モデルを開発するためのオブジェクト・プログラミング言語
JP2002334194A (ja) ワークフロー管理システムにおいて選択的コマンド制御を提供する方法、システム、プログラム
US20040117333A1 (en) Method and apparatus for building algorithms
US20040049765A1 (en) Method and system for implementing virtual functions of an interface
US8650568B2 (en) Method and system for transforming orders for executing them in standard workflow engines
US20090285376A1 (en) Method and tooling for the development of telecom services
Samaan et al. Task models and interaction models in a multiple user interfaces generation process
Viehstaedt et al. Interaction in really graphical user interfaces
US20030153998A1 (en) Feature modeling application
Kath Towards executable models: Transforming EDOC behavior models to CORBA and BPEL
CA2396104A1 (en) Method and system for implementing virtual functions of an interface
Bonsangue et al. Developing object-based distributed systems
Nierstrasz et al. Supporting compositional styles for software evolution
Große-Rhode Integrating Semantics for Object—Oriented System Models
DeLine et al. Lessons on converting batch systems to support interaction: Experience report
MXPA98004495A (en) A system platform for a communication system

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application