KR0175480B1 - 비동기 전달모드 교환 시스템에서의 기능단위 검증방법 - Google Patents

Abstract

본 발명은 비동기 전달모드(ATM) 교환시스템을 구성하는 전체기능이 각각의 세부적인 기능(Function)단위로 설계되어 구현되는 비동기 전달보드 교환 시스템에서의 기능단위 검증방법에 관한 것으로, 검증요구를 접수하면, 요구한 검증정보에 대한 추적을 요구하고, 결과 접수를 위하여 대기하는 제1단계 ; 상기 제1단계 수행 후, 검증결과를 접수하며 접수된 결과를 메시지로 구성하거나 그래픽정보의 출력을 요구한 후 종료하는 제2단계를 포함하는 것을 특징으로 한다.

Description

비동기 전달모드 교환 시스템에서의 기능단위 검증방법

제1도는 본 발명을 설명하기 위한 다른 비동기 전달 모드 교환 시스템에서의 기능단위 검증방법의 개략적인 원리 설명도.

제2도는 본 발명이 적용되는 ATM 교환시스템의 구조도.

제3도는 제2도의 분산된 하드웨어 구조에서의 검증 기능부 구성도.

제4도는 본 발명에 따른 비동기 전달 모드 교환기 시스템에서의 기능단위 검증방법에 대한 일실시예 처리 흐름도.

제5도는 제4도의 검증정보의 등록처리를 위한 상세 흐름도.

제6도는 제4도의 검증보조의 결과를 접수 처리하는 상세 흐름도.

제7도는 제4도의 검증결과의 출력메세지 형태 예시도.

제8도는 본 발명에 따른 검증결과를 출력하는 최종적인 기능을 설명하기 위한 설명도.

본 발명은 비동기 전달모드(ATM)교환시스템을 구성하는 전체기능이 각각의 세부적인 기능(Function) 단위로 설계되어 구현되는 비동기 전달모드 교환 시스템에서의 기능단위 검증방법에 관한 것이다.

현재까지의 기능검증 방법은 설계과정에서 구현과정에 이르기까지 설계문서를 별도로 작성하고 이것을 기준으로 실제기능을 구현하지만 이때 구현된 기능이 설계된 내용과 얼마나 일치하는지를 검증할 수 있는 방법이 기능에서 정의된 입력의 형태로 들어가는 정보와 이에 대한 처리결과로 출력되는 내용을 통한 방법이 있을 뿐이며, 중간단계에서의 처리과정이 전혀 검증할 수 없을 뿐만 아니라 비정상적인 수행에 대한 보완작업에 어려움이 있다.

상기 종래 기술에 대한 문제점을 해결하기 위하여 안출된 본 발명은, ATM 교환시스템에서 정의된 기능(function)단위의 검증에 관한 방법으로써 시스템 설계과정을 거쳐 구현된 기능의 정상적인 동작상테를 설계문서로 부터 직접 추출된 정보를 이용하여 기본적인 동작의 흐름을 파악하기 위한 비동기 전달모드 교환 시스템에서의 기능단위 검증방법을 제공하는 데 그 목적이 있다.

상기 목적을 달성하기 위하여 본 발명은, 검증 기능을 분산된 구조하에 검증제어 기능수단과, 검증관리 기능수단으로 분류하여 구성하고, 상기 검증관리 기능수단을 통하여 데이터 베이스 시스템과 라이브러리 및 운영체계와 연동하여 검증 기능을 수행하는 비동기 전달모드 교환 시스템에 적용되는 기능단위의 검증방법에 있어서, 검증요구를 접수하면, 요구한 검증정보에 대한 추적을 요구하고, 결과접수를 위하여 대기하는 제1단계 ; 검증결과를 접수하며 접수된 결과를 메시지 구성하거나 그래픽정보의 출력을 요구한 후 종료하는 제2단계를 포함한다.

이하, 첨부된 도면을 참조하여 본 발명의 일실시예를 상세히 설명한다.

제1도는 본 발명에 따른 개발 기능의 흐름도로서, 기능의 구성이 명령어를 접수한는 운용자 정합 기능과 장치의 상태를 관리하는 기능 및 장치의 상태를 제어기능으로 구성되어 있는 경우이다.

먼저, 기능개발자 또는 운용자로 부터 상태출력을 요구하면 운용자 정합기능에서는 접수된 명령어를 분석하여(1) 상태관리 기능부(2)로 시그널을 통해 전달한다(4).

본 발명에서 시그널이란 분산된 독립된 기능들간의 상호 정보 교환을 위하여 정해진 데이터의 구성형태에 다라 사전에 약속된 규약을 말한다.

상태관리 기능(2)에서는 출력을 요구한 UNI링크의 형상정보를 점검하기 위하여 데이터베이스로 구성된 정보를 읽어 확인하는 절차를 수행한다(5).

확인결과 실장된 링크이면 상태정보를 얻기 위하여 상태제어 기능(3)으로 시그널을 통해 정보를 전달하며(5), 상태제어 기능에서는 라이브러리를 통해(7) 읽은 결과정보를 상태관리 기능으로 전달하고(8), 상태관리 기능에서는 출력을 위한 형태로 구성하여 운용자 정합기능으로 출력을 요구함으로써(9) 하나의 기능이 완료되는 과정을 설명한 것이다.

이 흐름도는 모든 기능의 수행을 나타내는 것으로써 표현되며 구성요소는 시그널을 통한 정보전달, 데이터베이스를 통한 릴레이션 정보의 공유와 라이브러리를 통한 공통정보의 공유형태로 이루어진다.

여기서, 릴레이션은 데이터베이스관리 시스템이 관리하는 상로 관련되는 데이터의 구성 단위을 나타내며, 라이브러리는 서브루틴 형태로 프로그램을 구성하여 기능들간의 데이터나 처리과정을 공유하기 위한 방법을 나타낸다.

그리고, 검증정보의 추출은 제1도에서 설명한 기능 흐름도에서 나타난 대상으로 실제적으로 기능수행 상태를 확인하기 위한 정보를 추출하게 된다.

이때 추출된 정보는 데이터베이스로 구성되어 시스템에 적재되며 기능개발자 또는 운용자 요구 및 필요에 따라 해당기능의 확인 요구가 있을 시 이 내용이 시그널 추적, 데이터베이스추적 및 라이브러리 추적기능으로 등록되고, 기능이 동작되는 시점에서 추적된 종류에 따라 발생된 정보의 내용이 검증기능으로 전달되어 일정한 형태의 정보르 구성되어 출력된다.

도면에서, MMCDiSLkSts는 링크 상태 출력 명령어(Man-Machine Command for Disply Link Status), R_UNI_LINK_CONF은 UNI 링크 형상 릴레이션(Relation for UNI Link Configuration), DisLKStsReq)는 링크 상태 출력요구(Display Link Status Request) pd_UniLKStsRpt는 링크 상태 출력 명령어 보고(Man-Machine Command for Display Link Status Report)이다.

기능별 시그널 정보 구성

표 1은 개발 흐름도에서 해당 기능을 수행하는 과정에서 전달된는 시그널에 대한 정보를 기능단위로 구성한 것이다. 각 기능은 기능번호를 통해 구분되며 기능단위로 저장된는 시그널 정보는 시그널 고유의 번호로써 저장되고 해당 사항이 없을 경우에는 h'ffff 로 채워진다. 그리고, 처리과정이 다소 복잡한 기능도 최대 20개미만의 시그널을 통한 정보전달로 표현될 수 있다는 전제하에 구성한 것이다. 그리고 시그널 개수가 그 이상이 되는 경우에는 데이타 구조를 확장하여 사용할 수있다.

표 2는 개발 기능 흐름도에서 나타난 라이브러리의 겁근을 나타내는 부분에 대한 정보를 저장하는 형태이다. 각 기능은 기능번호를 통해 구분되며 기능단위로는 접근하는 라이브러리의 번호를 저장하게 되며, 해당 사항이 없을 경우에는 h'ff로 채워진다. 라이브러리 번호를 저장하는 이유는 시스템 전체적으로 보았을 때 많은 기능들이 동일한 라이브러리를 접근할 수 있으므로 시스템에 등록된 라이브러리를 특정번호를 부여하여 구분하고 저장형태는 이들 번호로 관리함으로써 저장매체의 크기를 축소할 수 있다.

표 3은 개발 기능 흐름도에서 데이터베이스를 이용하여 해당 기능번호가 수행된되는 과정에서 접근하는 릴레이션에 대한 정보를 저장하는 형태이다. 각 기능은 기능번호(14)를 통해 개발기능에서 동일한 종류의 릴레이션을 한번 이상 접근하더라도 기능별 데이터베이스 정보에는 해당되는 릴레이션 에 대한 하나의 번호만이 저장되는 형태이다. 여기서 기능번호 단위로 기록되는 릴레이션 정보는 해당 릴레이션이 갖는 고유번호를 나타내며, 해당 사항이 없을 경우에는 h'ff 로 채워진다.

이상에서 설명한 데이터 구성요소들은 각 개발기능에 대한 기술문서로부터 직접 추출되어 만들어지는 정보가 되며, 이렇게 함으로써 문서상의 설계 내용과 실현된 기능간의 일치성을 보장할 수 있도록 한다.

제2도는 본 발명에 따른 검증기능이 수행되는 분산된 구조의 ATM 교환시스템의 구조도로써, ATM 중앙교환 서브 시스템(20)과 접속교환 서브 시스템(21, 22)으로 분류되며, 각 서브시스템에는 프로그램을 적제하고 수행을 제어하기 위하여 중앙교환서브시스템에는 운용 및 유지보수기능을 담당하는 프로세서인 OMP(Operation maintenance processor, 23)가 위치하며, 접속교환 서브시스템에는 호 연결제어 프로세서인 CCP(Call Connection Control Processor, 24)로 구성된다.

도면에 기재된 용어는 다음과 같다.

ALS(ATM Local Switching Subsystem)

ACS(ATM Central Switching Subsystem)

ASW(Access Switch)

CSW(Central Switch)

UNI(User- Network Interface)

NNI(Network-Node Interface)

TIM(Trunk Interface Module)

SIM(Subscriber Interface Module)

실제적으로 검증기능이 수행된는 구조는 제3도에 도시한 검증관리기능부(30, 31) 와 검증제어기능부(38)를 위한 기능을 디스크(25)로부터 OMP를 비롯한 CCCP로 적재시키고, 요구한 기능번호에 대한 시그널(표1), 라이브러리(표2), 데이터베이스(표3)로 저장된 정보를 이용하여 해당되는 자원의 번호로 추적시작을 등록한다. 기능이 동작되는 시점에서 추적된 정보들이 검증 제어기능부(38)로 취합되어 일정한 형태로 구성되어 순서적으로 출력한다. 그리고, 수행이 완료되는 시점에서 각 프로세서에 적재된 소프트웨어는 회수되고 그 전 상태로 복귀하게 된다.

제3도는 제2도에서 설명한 분산된 하드웨어 구저에서 검증기능이 수행되기 위한 제어기능과 관리기능의 구성도를 나타낸 것이다.

각 서브시스템에 분산된 검증관리기능부(30, 31)는 직접적으로 데이터베이스 시스템(32, 33)과 라이브러리(34, 35), 운용체계(36,37)를 통해 기능흐름도에서 나타난 추적대상 정보를 등록하고 결과정보의 취합기능을 담당한다.

그리고, 검증제어기능부(38)에서는 운용자 정합기능부(39)로 부터 명령어를 접수하여 요구한 기능의 특성에 따라 분산된 검증관리기능으로 정보를 전달하고 수행상태의 감시 및 제어기능을 수행하는 역할을 한다.

제4도는 상기 제3도에서 설명한 구조에 적용되는 검증기능의 흐름을 나타낸 전체프름도로서, 검증요구를 접속하면(40), 요구한 검증정보를 읽어(41) 이것에 대한 추적을 요구하고(42), 결과접수를 위한 대기상태(43)를 거친 후 검증결과를 접수하며(44) 접수된 결과를 메시지로 구성하거나 기능흐름도의 그래픽정보의 출력을 요구한 후(45) 종료한다(46).

제5도는 상기 제4도에서 설명한 전체적인 흐름도에서 상기 과정(40 내지 43)의 처리흐름을 상세하게 설명한 흐름이다.

수행요구를 접수하면(50)요구한 기능의 등록여부를 확일하고(51) 미등록 기능이면 이에 대한 메시지를 출력 요구하고(52) 종료하며(53), 등록된 기능이면 시그널 정보를 읽게 된다(54). 읽은 정보에서 시그널 정보가 존재하는 지를 확인하여(55)존재할 경우엔는 시그널 추적요구를 하고(56) 그렇지 않은 경우에는 다음 과정인 라이브러리 정보를 읽게된다(57). 라이브러리 정보에 대한 읽은 결과를 확인하여(58) 존재할 경우에는 라이브러리 추적을 요구하고(59), 존재하지 않을 경우에는 다음 과정인 릴레이션 정보를 읽게 된다(60). 그리고 릴레이션 정보가 존재하는지를 확인한 후 (61) 존재할 경우에는 릴레이션 추적요구를 하고(62) 그렇지 않은 경우에는 바로 결과접수를 위한 대기 상태로 천이한다(63).

제6도는 상기 제4도에서 설명한 전체 흐름도에서 상기 과정(43 내지 45)을 상세히 설명한 흐름도이다.

검증결과 접수대기 상태에서(70)시그널 추적결과를 접수하면(71)결과 메시지를 구성하여(74) 출력을 요구하고(75)검증결과에 대한 접수가 완료되었는지를 확인한후(75)완료되지 않은 상태이면 다음 결과를 접수하기 위한 대기상태로 전환한다(77). 결과접수 대기상태에서 릴레이션 추적에 대한 결과겁수(72)와 라이브러리 추적에 대한 결과접수(73)에 대한 처리도 동일한 과정으로 수행된다.

결과접수가 완료된 상태이면 결과정보를 이용하며 기능흐름도에 대한 정보를 갱신시키고(78) 기능 흐름도에 대한 그래픽정보의 츨력을 요구한 후(79) 종료한다(80).

제7도는 기능검증을 위하여 시그널 추적, 라이브러리 추적, 릴레이션 추적을 요구한 상태에서 접수되는 결과정보를 시스템 외부적으로 메시지를 구성하여 출력하는 정보 형태를 나타낸 것이다.

메시지의 구성을 설명하면 슬로건으로 메시지의 성격을 구분하고(90) 기능번호로써(91) 검증을 요구한 기능을 분류하묘, 메시지 형태로써(92) 추적된 결과를 구분할 수 있도록 하고, 추적된 결과정보의 발생위치를 프로세서로써(93) 구분하도록 한다. 시그널에 대한 추적결과이면 시그널 번호(94), 시그널 명칭(95)으로 구성되고, 릴레이션에 대한 추적결과이면 릴레이션 번호(96), 릴레이션 명칭(97), 릴레이션을 구성하는 각 애트리트에 대한 변경전후의 값(98)들로 구성된다.

라이브러리에 대한 추적결과이면 라이브러리 번호(99), 라이브러리 명칭(100), 입력변수에 대한 값(101), 수행결과에 대한 변수값(102)으로 구성된다.

제8도는 상기 제1도에서 설명한 기능 흐름도에서 검증기능의 수행결과에 대한 최종적인 정보구성을 출력되는 결과메시지를 바탕으로 개발기능 흐름도에서 나타난 구조와 동일한 중간과정에서의 수행중지와 실제 기술문서상에서 나타난 정보가 일치하지 않는 점을 쉽게 파악할 수 있도록 한다.

검증결과가 정상적으로 수행된 부분은 굵은 선(110)으로 표시된 부분이 되며, 얇은 선(11)으로 표시된 부분은 해당되는 시그널 전달이 접수되지 않은 부분이다.

본 발명은 설계단계에서 기능단위로 추출된 정보를 데이터베이스로 구성하여 시스템에 적재하고, 운영체계 및 데이터베이스시스템과 연동하여 수행을 요구한 기능의 처리과정을 추적요구한 후, 동작상태에서 얻어지는 결과를 이용하여 설계내용과 구현된 기능의 일치성을 파악할 수 있는 방법이다.

동시에 이러한 검증방법의 확장적용을 통해 시스템 전체적인 기능의 상태파악이 가능하게 되고 자동화 할 수 있는 방법이 된다.

교환시스템의 일반적인 개발절차는 시스템 계획 및 개념 모델 정의의 분석을 토대로 시스템을 사용자의 관점에서 명확히 정리한 요구사항 정의가 따르고 이를 바탕으로 시스템 관점에서 제기술하여 개념적으로 일관성이 있고 논리적으로 구현에 관계없이 시스템을 기술하는 개발기능 규격 과정을 거치게 되며, 이것이 시스템에서 구현될 기능들을 추출하여 각 개발기능이 무엇을 행하는가를 나타내는 단위가 된다.

이러한 체계화된 개발절차는 대형시스템의 설계에 있어서는 필수적이며 기능의 개발기간과 신뢰도에 직접적으로 영향을 미칠 수 있는 요소로써 작용한다.

따라서 본 발명에서는 이러한 기능요소를 대상으로 하며 각 기능단위로는 해당 기능을 구현하는데 필요한 운용자 정합을 비롯한 시스템 외부 입력 및 데이테 베이스의 접근, 시스템 라이브러리의 접근 등으로 구성된 시나리오 형태의 기능흐름으로 표현된다.

그리고 이러한 정보는 일정한 표현방법을 통하여 표시됨으로 정보의 추출이 가능하고 이것을 시스템에서 활용할 수 있는 정보의 형태로 구성하여 시스템에서 제공되는 시그널 추적 및 라이브러리, 데이터베이스 추적기능과 연계하여 개발기능 단위의 기능동작을 빠른 시간 내에 전체적으로 시스템 시험에 앞서 검증하고 특히 복잡한 시스템에서 소홀하기 쉬운 기술문서와 개발 결과물 간의 일치성을 유지할 수 있는 방법이다.

상기와 같은 본 발명은, 기능흐름도상에서 표현되는 하나의 기능이 시작하여 완료된는 과정에서 처리하는 정보전달 방법인 시그널, 라이브러리, 데이터베이스를 접근하는 정보를 직접 이용한다.

따라서 다소 복잡한 형태의 기능흐름이더라도 순서에 따라 정확하게 설계가 이루어지면 설계과정에서 정의된 시그널, 라이브러리, 데이터베이스에서 처리하는 릴레이션 정보를 이용하여 기본적인 프로그램 형태를 프로세스 단위로 바로 추출할 수 있는 방법을 쉽게 제공할 수 있으며, 기능 개발자의 노력을 절감할 수 있을 뿐만 아니라 프로그래밍 자동화를 위한 방법이 될 수도 있다.

또한, 본 발명에서는 기능설계 과정에서 필요로 하는 기능흐름도에서 시스템에서 제공되는 주요 전달방법인 시그널, 라이브러리, 데이터베이스를 접근하는 요소들을 기술하도록 하고 이것을 기술문서로부터 직접 추출하여 데이터로 구성하고, 기능단위로 구성된 이러한 정보를 구현된 시스템 상에서 구동시켜 기능의 동작상태를 확인하는 방법이다.

따라서, 이러한 방법은 필요에 따라 그 외의 정보전달 방법이나 시스템 공통데이터를 대상으로 기능을 확장시켜 보다 상세한 기능의 흐름을 파악할 수 있는 방법이 된다.

아울러 시스켐 전체 기능을 체계적인 순서로 구성하였을 경우에는 보다 큰 기능 단위의 검증이 가능하고, 동작방법을 자동화 시켜 기능검증을 효율적이고 계획적으로 수행할 수 있는 이점이 있다.

Claims (5)

1. 검증 기능을 분산된 구조하에 검증 제어기능수단과, 검증관리 기능수단으로 분류하여 구성하고, 상기 검증 관리기능수단을 통하여 데이터 베이스 시스템과 라이브러리 및 운영체계와 연동하여 검증 기능을 수행하는 비동기 전달모드 교환 시스템에 적용되는 기능 단위의 검증 방법에 있어서, 검증요구를 접수하면, 요구한 검증정보에 대한 추적을 요구하고, 결과접수를 위하여 대기하는 제1단계 ; 검증결과를 접수하며 접수된 결과를 메시지로 구성하거나 그래픽정보의 출력을 요구한 후 종료하는 제2단계를 포함하는 것을 특징으로 하는 비동기 전달모드 교환시스템의 기능단위 검증방법.
2. 제1항에 있어서, 상기 제1단계는, 수행 요구를 접수하여 요구한 기능의 등록여부에 따라 시그널 정보, 라이브러리정보, 릴리에션 정보의 존재 여부에 따라 각 정보가 존재하면 정보의 추적을 요구하고 결과를 대기하는 제3단계인 것을 특징으로 한는 비동기 전달모드 교환 시스템에서의 기능단위 검증방법.
3. 제2항에 있어서, 상기 제3단계는, 수행 요구 접수 후, 요구한 기능의 등록 여부를 제4단계 ; 요구한 기능이 미등록 기능하면 미등록 메시지를 출력요구하고 종료하며, 등록된 기능이면 시그널 정보를 읽어 정보의 존재 여부를 판단하는 제5단계 ; 시그널 정보가 존재할 경우에는 시그널 정보 추적요구를 하고 그렇지 않은 경우에는 다음 과정인 라이브러리 정보를 읽어 정보의 존제 여부를 판단하는 제6단계 ; 라이브러리 정보가 존재할 경우에는 라이브러리 정보 추적요구를 하고 그렇지 않은 경우에는 다음 과정인 릴레이션 정보를 읽어 릴레이션 정보의 여부를 판단하는 제7단계 ; 및 릴레이션 정보가 존재할 경우아는 릴레이션 정보 추적요구를 하고 그렇지 않은 경우에는 바로 결과접수를 위한 대기 상태로 천이하는 제8단계를 포함하고 있는 것을 특징으로 하는 비동기 전달모드 교환 시스템에서의 기능단위 검증방법.
4. 제1항에 있어서, 상기 제2단계는, 검증결과 접수대기 상태에서 시그널, 라이브러리, 릴레이션 정보의 추적결과를 접수하여 각 결과 메시지를 구성하여 출력을 요구하고 검증결과에 대한 접수가 완료되었는지를 확인하는 제3단계 ; 완료되지 않은 상태이면 다음 결과를 접수하기 위한 대기상태로 전환하고, 결과 접수가 완료된 상태이면 결과정보를 이용하여 기능흐름에 대한 정보를 갱신시키고 기능 흐름에 대한 그래픽정보의 출력을 요구한 후 종료하는 제4단계를 포함하는 것을 특징으로 하는 비동기 전달모드 교환 시스템에서의 기능단위 검증방법.
5. 제4항에 있어서, 상기 결과 출력 메시지는, 검증 결과를 구분하기 위하여, 슬로건, 기능번호, 결과 형태 구분 메시지 정보, 검출된 프로세서로 구성되고, 시그널에 대한 검증결과 정보, 릴레이션 검증결과 정보, 라이브러리 검증결과 정보를 구분하여 표시하도록 한 것을 특징으로 하는 비동기 전달모드 교환 시스템에서의 기능단위 검증방법.