자동 생성 폼과 SQL을 이용한 ERD 표현

Abstract

통상적으로 데이터베이스 어플리케이션을 구현하는 과정은 ERD(Entity Relationship Diagram)와 프로세스 모델을 산출하는 분석 과정을 거쳐 코딩, 테스팅 (testing)으로 프로젝트를 완성한다. 이 과정에서 가장 정형화되지 못한 부분이 분석과정으로 (1) 고객이 자신이 원하는 시스템의 세부 사항까지 알지 못한다; (2) 고객의 비즈니스 (business) 로직을 개발자가 이해하기 어렵다; (3) 분석 산출물인 ERD와 프로세스 모델을 고객이 이해하기 어렵다 등의 이유 때문이다. 본 논문은 분석 과정을 효과적으로 수행하기 위하여 가장 중요한 분석 산출물인 ERD (Entity Relationship Diagram)를 고객이 이해하기 쉬운 폼 형태로 제시할 것을 제안한다. 이 폼들은 데이터를 입력할 수 있게 하여 고객이 입체적으로 모델을 평가할 수 있어야 하며 분석 과정에서 발견되는 비즈니스 로직을 즉각 구현하여 고객이 이 폼들을 실행하면서 구현되는 로직을 평가, 이해하여 비즈니스 로직을 세부적으로 제공할 수 있게 하여야 한다. 이 목적을 위하여 고객이 제공하는 비즈니스 로직을 폼과 폼끼리의 참조를 포함하는 데이터 플로우(data flow) 형태로 우리의 폼 시스템에서 구현할 수 있어야 한다. 고객은 추상적인 ERD 대신에 데이터를 포함하고, 데이터 플로우 로직이 구현되어 있는 폼들을 실행 시켜 보면서 자신이 제공한 비즈니스 로직을 검토할 수 있으며 새로운 로직을 발견할 수 있다. 이러한 과정을 반복적으로 수행하면서 고객과 개발자는 충분히 세부적이고 모순이 없는 분석 과정을 성공적으로 수행할 수 있게 된다. Generally, the development of the database application includes the requirement analysis phase of creating ERD (Entity Relationship Diagram) and process models, coding, and testing. From the above phases, the analysis phase is not most formalized. It is usually hard task because (1) customers don't know the details of the desired system; (2) developers can't with ease understand the business logic of the customers; (3) the outcomes of the analysis, which are ERD and process models, are not easy to understand to the customers. This paper propose that the executional forms, which are better to understand the systems, should be presented to the customers instead of the ERD. These forms should accept the data input so that customers can review the various aspects of the outcome models. The developers should be able to instantly implement the business logic and also should be able to visually demonstrate the logic in order to get the details of it. For this goal, the customer supplied business logic should be able to be implemented by the references between forms, actions, constraints from the perspective of the data flow. The customers try to execute the forms implementing the business logic and review their supplied logic find new necessary business logic of their own. Iterating these processes for the requirement analysis would result in the success of the analysis which is sufficiently detailed without conflicts.