KR100250486B1 - 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법 - Google Patents
소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법 Download PDFInfo
- Publication number
- KR100250486B1 KR100250486B1 KR1019970064797A KR19970064797A KR100250486B1 KR 100250486 B1 KR100250486 B1 KR 100250486B1 KR 1019970064797 A KR1019970064797 A KR 1019970064797A KR 19970064797 A KR19970064797 A KR 19970064797A KR 100250486 B1 KR100250486 B1 KR 100250486B1
- Authority
- KR
- South Korea
- Prior art keywords
- definition language
- software
- subprocess
- converted
- code
- Prior art date
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
본 발명은 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법에 관한 것이다. 소프트웨어 프로세스 모형을 기반으로 하여 프로젝트가 수행되도록 하기 위해서는 모형을 정의할 수 있는 방법이 있어야 하며, 일반적으로는 프로세스 정의 언어를 고안하여 이를 실행시켜 소프트웨어 프로세스를 실행하고 관리한다. 그러나 이 경우에 사용되는 언어는 보통의 프로그램 언어처럼 범용적이지 않기 때문에 처음 사용하는 사람이 어려움을 겪게 되기 쉽다. 따라서 본 발명에서는 소프트웨어 프로세스 모형을 그래픽하게 그리고 이 모형을 소프트웨어 프로세스 정의 언어 형태로 변환해 주기 위한 방법이 제시된다.
Description
본 발명은 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법에 관한 것으로, 특히 여러 페이지에 걸쳐 있는 한 프로젝트에 대한 그래픽 모형들을 하나의 프로세스 정의 언어 파일로 생성하므로써 대형 프로젝트를 수행하기 위한 소프트웨어 개발 모형화 작업에 편의성을 제공할 수 있는 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법에 관한 것이다.
종래에는 소프트웨어 공학 분야의 도구들은 분석, 설계, 검증 등의 각 단위별 작업만을 주관하여 왔다. 그런데 현재는 초고속 통신망을 통한 다양한 멀티미디어 서비스를 제공하기 위하여 크기나 기능이 방대하고 복잡한 소프트웨어의 필요성이 급증하고 있다. 이 소프트웨어들은 다수의 개발자가 참여할 뿐만 아니라 유지 보수 시에도 상당한 비용이 투입되고 있다. 이러한 문제를 극복하고 양질의 프로덕트를 생산하기 위해 소프트웨어 프로세스(Software Process)의 체계적인 정의를 표현한 소프트웨어 프로세스 모형(Software Process Model)과 이 모형의 실행(Enactment)을 지원하는 프로세스 중심 소프트웨어 공학 환경(Process-Centered Software Engineering Environments)을 이용하여 소프트웨어 개발 과정을 관리할 필요성이 제기되었다. 이러한 소프트웨어 공학 환경에서 소프트웨어 프로세스 모형을 기반으로 하여 프로젝트가 수행되도록 하기 위해서는 모형을 정의할 수 있는 방법이 있어야 하며, 일반적으로는 프로세스 정의 언어를 고안하여 이를 실행시켜 소프트웨어 프로세스를 실행하고 관리한다. 그러나 이 경우에 사용되는 언어는 보통의 프로그램 언어처럼 범용적이지 않기 때문에 초보자의 경우 사용하기 어려운 문제점이 있다.
따라서, 본 발명은 초기 인스턴스화 작업, 모형의 해석 및 실행 기능을 수행하는 모형 변환기를 이용하여 여러 페이지에 걸쳐 있는 한 프로젝트에 대한 그래픽 모형들을 하나의 프로세스 정의 언어 파일로 생성하는 프로세스 정의 언어로의 변환 방법을 제공하는데 그 목적이 있다.
이를 위해 사용되는 프로세스는 여러 하위 프로세스로 분해될 수 있고 이를 정의 언어로 차질 없이 표현할 수 있어야 하며 최상위 프로세스는 한 프로젝트에 대한 전역 변수들을 프로세스 정의 언어로 표현할 수 있어야 한다. 또한 모든 부분을 자동적으로 정의 언어로 변환하기는 어려우므로 일부는 텍스트 에디터를 사용할 수 있어야 하며, 프로세스 모형이 완성된 후에는 모형의 실행을 위한 초기 인스턴스 정보를 데이터베이스화 해야 한다.
상술한 목적을 달성하기 위한 본 발명에 따른 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법은 소프트웨어 프로세스 그래픽 모형을 작성하는 단계와, 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스인가 판단하는 단계와, 상기 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스인가 판단한 결과 최상위 프로세스이면 전역 변수를 선언하기 위해 하나의 프로젝트와 관련된 모든 프로세스 파일을 여는 단계와, 정의 언어 코드로 변환하기 위한 편집 창 및 코드를 생성하는 단계와, 정의 언어로의 코드 변환이 완료되면 모든 프로세스들이 통합되기 이전의 일시적인 화일을 생성하는 단계와, 상기 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스인가 판단한 결과 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스가 아닌 경우에는 프로세스가 변환하지 않은 하위 프로세스를 갖는지 판단하는 단계와, 상기 변환하기 않은 하위 프로세스를 갖는지 판단한 결과 변환하지 않은 하위 프로세스가 있는 경우에는 하위 프로세스를 열고 변환하지 않은 하위 프로세스가 있는지를 판단하는 단계로 진행하는 단계와, 상기 변환하지 않은 하위 프로세스를 갖는지 판단한 결과 변환하지 않은 하위 프로세스가 존재하지 않을 경우에는 정의 언어 코드로 변환하기 위한 편집 창 및 코드를 생성하는 단계와, 정의 언어로의 코드 변환이 완료되면 모든 프로세스들이 통합되기 이전의 일시적인 파일을 생성하는 단계와, 모든 프로세스들이 정의 언어로 변환 완료되면 모든 임시 파일을 통합하여 하나의 파일로 생성하는 단계와, 상기 통합된 파일을 정의언어 해석기로 해석하여 컴파일하는 단계와, 프로세스 엔진을 실행하는 단계를 포함하여 이루어지는 것을 특징으로 한다.
도 1은 본 발명이 적용되는 소프트웨어 공학 환경을 설명하기 위한 블록도.
도 2는 모형화 작업시 고려해야할 구성 요소간의 관계를 나타낸 기능 블록도.
도 3은 본 발명에 따른 소프트웨어 프로세스 정의 언어에 대한 그래픽 모형의 예시도.
도 4는 소프트웨어 프로세스 그래픽 노드의 구성 요소를 나타낸 기능 블록도.
도 5는 소프트웨어 프로덕트 그래픽 노드의 구성 요소를 나타낸 기능 블록도.
도 6은 모형 변환기의 사용자 인터페이스를 설명하기 위해 도시한 블록도.
도 7은 모형 변환기의 프로세스 모형 파일의 체계를 설명하기 위해 도시한 기능도.
도 8은 초기 인스턴스 저장 다이얼로그 박스의 일 예를 설명하기 위해 도시한 기능도.
도 9는 본 발명에 따른 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법을 설명하기 위해 도시한 흐름도.
도 10은 본 발명에 적용되는 소프트웨어의 구성도.
<도면의 주요 부분에 대한 부호 설명>
11 : 프로세스 중심 소프트웨어 공학 환경
12 : 개발 기법 지원 도구 13 : 공동 개발 플랫폼
111 : 모형화 지원 도구 112 : 프로세스 엔진
113 : 모니터링 도구 114 : 정보 저장소
115 : 통신 시스템 116 : 공유 작업 공간
이하, 첨부된 도면을 참조하여 본 발명을 상세히 설명하기로 한다.
도 1은 본 발명이 적용되는 소프트웨어 공학 환경을 설명하기 위한 블록도이다.
프로세스 중심 소프트웨어 공학 환경은 소프트웨어 프로덕트를 개발하기 위하여 수행하여야 할 분석, 설계, 구현, 시험, 문서화 등의 개발 행위들을 포함하고 있는 개발 기법 지원 도구(12)와 연결되어 있으며 그 주변에 개발 기법 단위 도구들과 컴퓨터 지원 공동 작업(Computer Support Cooperative Work ;CSCW)을 지원하는 통신 시스템(115) 및 공유 작업 공간(116)이 위치하고 있는 공동 개발 플랫폼(13)과 상호 연결되어 있다. 이 환경을 사용하는 사용자는 자신이 속한 프로젝트가 프로세스 엔진의 제어를 받으므로 프로세스 엔진이 실행되는 대로 그 순서를 밟아나가는데, 필요할 때마다 단위 도구를 이용하기도 하고, 경우에 따라 공동 작업 환경을 이용하기도 한다. 프로세스 중심 소프트웨어 공학 환경은 모형화 지원 도구(111), 프로세스 엔진(112), 모니터링 도구(113) 및 정보 저장소(114)로 이루어진다. 소프트웨어 프로세스 엔진(112)은 정의된 소프트웨어 프로세스 모형을 기반으로 개발이 진행되는 지를 판단하고 제어한다. 프로세스 엔진(112)은 또한 소프트웨어 프로세스 모형에서 정의된 개발 행위를 수행하기 전에 만족해야 하는 사전 조건을 검사하고, 개발 행위 수행 후에는 사후 조건을 검사하여 수행 결과를 확인함으로써 모형에서 정의한 제한 사항과 수행 중인 소프트웨어 프로세스 관련 정보들을 유지 관리한다. 또한, 개발 행위 수행을 지원하는 소프트웨어 프로세스 지원 도구와 연관되어 관련 도구의 사용을 안내하는 기능을 포함한다. 모니터링 도구(113)는 소프트웨어 프로세스 실행 상태를 파악하고 관리하며, 실행 계획을 수립하는 기능을 제공한다. 그리고 소프트웨어 실행 결과를 예측, 평가하는 기능도 제공한다. 정보 저장소(114)는 소프트웨어 프로세스 모형과 프로세스 실행 중에 발생하는 프로세스 인스턴스 자료들을 저장한다. 모형화 지원 도구(111), 프로세스 엔진(112), 모니터링 도구(113) 등이 필요로 하는 정보는 정보 저장소(114)에 저장된다. 모형화 지원 도구(111)는 소프트웨어 프로젝트 개발 과정에 포함되는 각종 개체와 개체간의 관계를 표현할 수 있어야 한다. 개체는 프로젝트 개발 과정에서 취급되는 모든 자료이며, 개체간의 관계는 형상 변화 및 개체간의 연관 정보를 추론하는데 이용된다. 소프트웨어 프로세스 모형은 수정하거나 확장하는 것이 용이해야 하며, 모형의 진화에 따라 실행 중인 소프트웨어 프로세스는 동적으로 변경되어야 한다.
도 2는 모형화 작업시 고려해야할 구성 요소간의 관계를 나타낸 기능 블록도이다.
에이젼트(Agent)는 해당 프로세스 담당자 즉, 과제 책임자, 분석가, 설계자, 프로그래머 등을 나타낸다. 프로세스(Process)는 한 프로젝트의 작업 단위로서 일련의 프로세스가 전부 끝나면 프로젝트가 끝나게 된다. 프로덕트(Product)는 각각의 프로세스가 수행 완료되면 나오게 되는 산출물이다. 세 가지 구성 요소간에 하나의 프로세스는 특정 에이젼트가 수행하여 특정 프로덕트를 산출하게 되는 관계를 갖는다.
도 3은 본 발명에 따른 소프트웨어 프로세스 정의 언어에 대한 그래픽 모형의 예시도로서, 다음과 같이 본 발명에 따른 소프트웨어 프로세스 정의 언어를 바커스 기법(Backus Normal Form ;BNF) 표기 형태로 나타낸 것에 대한 그래픽 모형의 한 예이다.
<processDefinition> ::= process <processName> (<argumentList>) is
<productDeclaration>
<preconditionDeclaration>
<postconditionDeclaration>
<exceptionDeclaration>
<relationDeclaration>
<subprocessDeclaration>
<taskDeclaration>
end <processName>;
......................................................................1
<argumentList> ::= <argumentParameter> [, <argumentList>]
<argumentParameter> ::= in <productName>
| out <productName>
| inout <productName>
......................................................................2
<preconditionDeclaration> ::= precondition <conditionList>
<conditionList> ::= <productName> is <productStatus>;
[AND | OR] [<conditionList>]
......................................................................3
<postconditionDeclaration> ::= postcondition <conditionList>
<conditionList> ::= <productName> is <productStatus>;
[AND | OR] [<conditionList>]
......................................................................4
<exceptionDeclaration> ::= exception <exceptionList>
<exceptionList>::= <eventName> when <productName> is [not] <productStatus>;
[<exceptionList>]
......................................................................5
<subprocessDeclaration> ::= subprocess <processList>
<processList> ::= <processName> (<argumentList>); [<processList>]
......................................................................6
<taskDeclaration> ::= task <taskList>
<taskList> ::= <taskStatement>; [<taskList>]
<taskStatement> ::= <sequentialStmt> | <selectionStmt>
| <parallelStmt> | <iterationStmt>
<sequentialStmt> ::= <processName> [ --> <sequentialStmt> ]
<selectionStmt> ::= if <expression> then <taskList> endif
<parallelStmt> ::= <processName> [ || <parallelStmt> ]
<iterationStmt> ::= while <expression> do <taskList> end
......................................................................7
<productDeclaration> ::= product <productList>
<productList> ::= <productName> is <productStatus>;
[<productList>]
......................................................................8
<relationDeclaration> ::= relation <relationList>
<relationList> ::= <relationName> is source: <productName>;
destination: <productName>;
end <relationName>]
[<relationList>]
......................................................................9
1은 전체적인 문법이고, 2의 <argumentList>는 프로세스의 실행에 필요한 입출력 소프트웨어 프로덕트들이다. <productName>은 입출력 프로덕트를 나타내며 in은 입력을, out은 출력을, inout 은 입출력을 의미한다. 3의 <preconditionDeclaration>은 프로세스가 실행하기전에 만족되어야 하는 선행조건이다. 선행조건에 나타난 프로덕트들의 상태가 주어진 조건에 만족되면 프로세스가 실행된다. <productStatus>는 프로덕트의 상태를 나타낸다. 4의 <postconditionDeclaration>은 프로세스의 실행이 종료될 때 만족해야 하는 사후 조건이다. 사후 조건의 상태가 만족된다면 소프트웨어 프로세스 모형에서 정의한 대로 프로세스가 실행되었음을 알 수 있다. 사후조건의 상태는 다른 프로세스가 실행하기 위한 선행조건으로 사용될 수 있다. 5의 <exceptionDeclaration>은 사후 조건이 만족되지 않았거나 시스템으로부터 특정한 신호가 전달되었을 때 수행되는 예외 상황이다. 예외 상황이 발생하면 해당 예외 상황이 발생했음을 알리는 이벤트(event)를 발생시킨다. 6의 <subprocessDeclaration>은 한 프로세스가 계층적으로 분할되었을 때 나타나는 하위 프로세스를 나타낸다. 7의 <taskDeclaration>은 프로세스 내에 포함된 개발 작업이다. 개발 작업들은 상호간에 순차적, 선택적, 병행적, 반복적 등으로 수행된다. <sequentialStmt> 문장은 순차적인 작업을 나타내며, <selectionStmt>는 선택적인 작업수행을 의미한다. <parallelStmt>와 <iterationStmt>는 각각 병렬적, 반복적 작업을 나타내고자 할 때 이용된다. 8은 프로덕트에 대한 문법이다. 소프트웨어 프로세스에서 사용하는 프로덕트들은 모두 표기되며, 이 프로덕트들의 상태도 함께 선언되어 프로세스 실행과 관련된 상태변화를 표현할 수 있도록 하였다. <productDeclaration>은 <processDefinition>에서 사용하는 프로덕트를 표기한 것이다. 9는 프로덕트 자료 개체간의 연관 관계를 나타내기 위하여 <relationDeclaration>을 이용하여 개체간의 상관관계를 모형 내에 표기할 수 있다.
도 4는 소프트웨어 프로세스를 그래픽 노드로 나타낸 기능 블록도이다.
이 노드는 일반적으로는 도 3에서처럼 둥근 사각형 안의 프로세스 이름으로만 노출되어 있다가 펼치면 이 그림처럼 보인다. BNF 표기 형태로 나타낸 소프트웨어 프로세스 정의 언어에서 정의된 요소 중 <precondition>과 <postcondition>은 이 노드 밖의 다른 그래픽 노드에 의해 정의된다.
도 5는 소프트웨어 프로덕트를 그래픽 노드로 나타낸 기능 블록도이다. 이 노드의 status는 이 프로덕트가 가질 수 있는 상태를 선언하는 부분이고, product는 이 노드가 대표 프로덕트인 경우 이 프로덕트 안에 속하는 세부 프로덕트들을 표시하는 부분이다.
도 6은 모형 변환기의 사용자 인터페이스를 설명하기 위해 도시한 블록도로서, 모형 변환기에서 사용하는 PopUp 메뉴를 나타낸 것이다. PM PopUp은 모형 변환기 어디서나 선택할 수 있다. Product는 프로덕트를 그리기 위하여, Relationship은 프로그램 소스가 컴파일하여 오브젝트 코드를 생성하는 것과 같은 프로덕트 간의 관계를 표시하기 위해, Process는 프로세스를 그리기 위해, Flow는 프로세스의 흐름을 표현하기 위해 존재한다. Flow는 Sequential, Parallel, Feedback 3 가지를 표현할 수 있도록 되어 있다. Process PopUp에는 프로세스 노드를 지울 수도(Delete) 옮길 수도(Move) 있다. 프로세스 노드를 정의 언어로 변환하기 위해서는 Document를 선택한다. Entity PopUp은 Process Popup과 달리 record로써 프로덕트의 인스턴스를 데이타베이스에 저장할 수 있다.
도 7은 모형 변환기의 프로세스 모형 파일의 체계를 설명하기 위해 도시한 기능도이다.
Workspace는 프로젝트마다 하나씩 존재하게 되며 새로 생성하거나 기존의 것을 열 수도 있다. 하나의 프로젝트는 하나의 ERD 파일이 존재하게 된다. 워크스페이스를 열면 맨 처음 ERD 파일이 열린다. ERD 파일은 모형에 사용될 개체와 개체들 간의 관계를 정의하고, 모형화 작업이 끝난 초기 인스턴스들을 저장하기 위해 필요하다. ERD 화일을 작성하고 나면 프로젝트의 대표 프로세스를 작성한다. 대표 프로세스는 프로젝트의 전역 변수들을 정의하기 위해 필요하다. 대표 프로세스는 TopDGM 파일에 저장된다. 대표 프로세스의 작성이 끝나고 나면 세부 프로세스들을 작성하게 되는데, 이와 관련된 그래픽 모형들은 DGM 파일(DGM1 내지 DGMn)에 저장된다. 또한, 세부 프로세스들은 필요에 따라 여러 단계의 하위 프로세스로 분해되어 서로 다른 DGM 파일(DGM11 내지 DGM1n, DGM21 내지 DGM2n, …, DGMn1 내지 DGMnn)에 저장된다.
도 8은 초기 인스턴스 저장 다이얼로그 박스의 일 예를 설명하기 위해 도시한 기능도이다.
바탕에 사각형으로 표시된 부분을 펼치면 StaffID, Idnum, Name 등과 같은 다이얼로그 박스에 나타난 속성(attribute)들이 선언되어져 있고, 이는 데이타베이스 스키마로서 데이타베이스 생성에 사용된다. 데이타베이스 생성이 되고 나면 이 다이얼로그 박스를 이용하여 튜플(인스턴스)들을 입력할 수 있다.
도 9는 본 발명에 따른 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법을 설명하기 위해 도시한 흐름도이다.
그래픽 모형이 작성(901)되면 정의 언어로 변환하는 작업을 수행할 수 있으며 정의 언어로의 변환은 프로세스 별로 변환이 끝난 후 이것을 통합하는 방법으로 이루어진다. 프로세스를 정의 언어로 변환하고자 하면 Process PopUp 메뉴의 Document를 이용한다. Document가 선택되어지면 모형 변환기는 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스인가 판단(902)하여 최상위 프로세스이면 전역 변수를 선언하기 위해 하나의 프로젝트와 관련된 모든 프로세스 파일(DGM)들을 연다(903). 그리고 정의 언어 코드로 변환하기 위한 창을 생성한다(904). 그 다음 코드를 생성(905)하고 필요에 따라 생성된 편집 창을 이용하여 일부 편집할 수 도 있다. 코드 변환이 모두 되고 나면 모든 프로세스들이 통합되기 이전의 일시적인 파일이 생성된다(906). 만약, 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스가 아니라면 프로세스가 하위 프로세스를 갖는지 판단(907)한 후 변환하지 않은 하위 프로세스가 있는 경우에는 하위 프로세스를 열고(908) 변환하지 않은 하위 프로세스가 없을 때까지 반복 판단하여 최하위 프로세스부터 정의 언어로 변환하여 임시 파일로 저장한다. 이후 정의 언어 코드로 변환하기 위한 창을 생성(909)하고 그 다음 코드를 생성(910)한다. 필요에 따라 생성된 편집 창을 이용하여 일부 편집할 수 도 있다. 코드 변환이 모두 되고 나면 모든 프로세스들이 통합되기 이전의 일시적인 파일이 생성된다(911). 이렇게 하여 모든 프로세스들이 정의 언어로 변환 완료되면 모든 임시 파일을 통합하여 하나의 파일로 생성한다(912). 이후 통합된 파일을 정의언어 해석기로 해석하여 디버깅하고 컴파일(913)한 후 프로세스 엔진을 실행한다(914).
도 10은 본 발명에 적용되는 소프트웨어의 구성도이다.
소프트웨어 프로세스 그래픽 에디터를 이용하여 그래픽 모형을 작성하고, 모형 변환기를 이용하여 정의 언어 코드로 변환하여 소프트웨어 프로세스 정의 언어 해석기를 이용하여 컴파일한 후 소프트웨어 프로세스 엔진을 이용 실행한다. 엔진이 실행 상태이면 모니터링 도구는 엔진을 통해 프로세스 진행 상태를 점검하고 프로세스의 흐름을 제어할 수도 있다. 이 소프트웨어들이 사용하는 정보는 모두 정보저장소인 RDBMS에 저장되어 있다.
상술한 바와 같이 본 발명에 따르면 초기 인스턴스화 작업, 모형 해석 및 실행 기능을 수행하는 모형 변환기를 이용하여 모형화 에디터의 그래픽 모형을 소프트웨어 프로세스 정의 언어를 이용하여 프로세스 단위 별로 각각 변환한 후 통합하는 방법을 사용하므로써 프로세스 중심 소프트웨어 공학 환경에서 프로세스 모형화 작업을 용이하게 할 수 있는 탁월한 효과가 있다.
Claims (1)
- 소프트웨어 프로세스 그래픽 모형을 작성하는 단계와,정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스인가 판단하는 단계와,상기 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스인가 판단한 결과 최상위 프로세스이면 전역 변수를 선언하기 위해 하나의 프로젝트와 관련된 모든 프로세스 파일을 여는 단계와,정의 언어 코드로 변환하기 위한 편집 창 및 코드를 생성하는 단계와,정의 언어로의 코드 변환이 완료되면 모든 프로세스들이 통합되기 이전의 일시적인 파일을 생성하는 단계와,상기 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스인가 판단한 결과 정의 언어로 변환하고자 하는 프로세스가 최상위 프로세스가 아닌 경우에는 프로세스가 변환하지 않은 하위 프로세스를 갖는지 판단하는 단계와,상기 변환하기 않은 하위 프로세스를 갖는지 판단한 결과 변환하지 않은 하위 프로세스가 있는 경우에는 하위 프로세스를 열고 변환하지 않은 하위 프로세스가 있는지를 판단하는 단계로 진행하는 단계와,상기 변환하지 않은 하위 프로세스를 갖는지 판단한 결과 변환하지 않은 하위 프로세스가 존재하지 않을 경우에는 정의 언어 코드로 변환하기 위한 편집 창 및 코드를 생성하는 단계와,정의 언어로의 코드 변환이 완료되면 모든 프로세스들이 통합되기 이전의 일시적인 파일을 생성하는 단계와,모든 프로세스들이 정의 언어로 변환 완료되면 모든 임시 파일을 통합하여 하나의 파일로 생성하는 단계와,상기 통합된 파일을 정의언어 해석기로 해석하여 컴파일하는 단계와,프로세스 엔진을 실행하는 단계를 포함하여 이루어지는 것을 특징으로 하는 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1019970064797A KR100250486B1 (ko) | 1997-11-29 | 1997-11-29 | 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1019970064797A KR100250486B1 (ko) | 1997-11-29 | 1997-11-29 | 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR19990043755A KR19990043755A (ko) | 1999-06-15 |
| KR100250486B1 true KR100250486B1 (ko) | 2000-04-01 |
Family
ID=19526093
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1019970064797A KR100250486B1 (ko) | 1997-11-29 | 1997-11-29 | 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법 |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR100250486B1 (ko) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9021430B2 (en) | 2010-12-21 | 2015-04-28 | Samsung Electronics Co., Ltd. | Method of determining multimedia architectural pattern, and apparatus and method for transforming single-core based architecture to multi-core based architecture |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100319776B1 (ko) * | 1999-12-23 | 2002-01-05 | 오길록 | 소프트웨어 프로세스 모형화 장치 및 그 방법 |
-
1997
- 1997-11-29 KR KR1019970064797A patent/KR100250486B1/ko not_active IP Right Cessation
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9021430B2 (en) | 2010-12-21 | 2015-04-28 | Samsung Electronics Co., Ltd. | Method of determining multimedia architectural pattern, and apparatus and method for transforming single-core based architecture to multi-core based architecture |
Also Published As
| Publication number | Publication date |
|---|---|
| KR19990043755A (ko) | 1999-06-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Memon et al. | Hierarchical GUI test case generation using automated planning | |
| KR100314262B1 (ko) | 그래픽언어기술프로세스내다수도구사용대화식컴퓨터프로그램개발방법및그장치 | |
| US20070277163A1 (en) | Method and tool for automatic verification of software protocols | |
| Guermazi et al. | Executable modeling with fuml and alf in papyrus: Tooling and experiments | |
| Rex Hartson et al. | User interface development processes and methodologies | |
| Lourenço et al. | OSTRICH-a type-safe template language for low-code development | |
| Koni-N’Sapu | A scenario based approach for refactoring duplicated code in object oriented systems | |
| Rocha Silva et al. | Ensuring the consistency between user requirements and task models: A behavior-based automated approach | |
| CN115794254A (zh) | 基于云计算的组件研发管理平台和方法 | |
| Van Mierlo | A multi-paradigm modelling approach for engineering model debugging environments | |
| Jácome-Guerrero et al. | Software development tools in model-driven engineering | |
| Beer et al. | IDATG: an open tool for automated testing of interactive software | |
| KR100250486B1 (ko) | 소프트웨어 프로세스 그래픽 모형으로부터 소프트웨어 프로세스 정의 언어로의 변환 방법 | |
| Memon et al. | A planning-based approach to GUI testing | |
| Olsen Jr et al. | Research directions for user interface software tools | |
| Jukks et al. | Transformations debugging transformations | |
| Kerkouche et al. | Uml activity diagrams and maude integrated modeling and analysis approach using graph transformation | |
| Straszak et al. | Automating acceptance testing with tool support | |
| Visic et al. | Developing conceptual modeling tools using a DSL | |
| KR100576941B1 (ko) | 메타모델에 기반한 모델 변환 지원 시스템 | |
| Samara | A practical approach for detecting logical error in object oriented environment | |
| Forte | Tools fair: Out of the lab, onto the shelf | |
| Burghard et al. | Visualizing multi-dimensional state spaces using selective abstraction | |
| Kleyn et al. | Edge-a graph based tool for specifying interaction | |
| Fernandez-y-Fernandez et al. | An IDE to build and check task flow models |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant | ||
| FPAY | Annual fee payment |
Payment date: 20121206 Year of fee payment: 14 |
|
| FPAY | Annual fee payment |
Payment date: 20131209 Year of fee payment: 15 |
|
| LAPS | Lapse due to unpaid annual fee |