통상적으로 데이터베이스 어플리케이션을 구현하는 과정은 ERD(Entity Relationship Diagram)와 프로세스 모델을 산출하는 분석 과정을 거쳐 코딩, 테스팅 (testing)으로 프로젝트를 완성한다. 이 과정에서 가장 정형화되지 못한 부분이 분석과정으로 (1) 고객이 자신이 원하는 시스템의 세부 사항까지 알지 못한다; (2) 고객의 비즈니스 (business) 로직을 개발자가 이해하기 어렵다; (3) 분석 산출물인 ERD와 프로세스 모델을 고객이 이해하기 어렵다 등의 이유 때문이다. 본 논문은 분석 과정을 효과적으로 수행하기 위하여 가장 중요한 분석 산출물인 ERD (Entity Relationship Diagram)를 고객이 이해하기 쉬운 폼 형태로 제시할 것을 제안한다. 이 폼들은 데이터를 입력할 수 있게 하여 고객이 입체적으로 모델을 평가할 수 있어야 하며 분석 과정에서 발견되는 비즈니스 로직을 즉각 구현하여 고객이 이 폼들을 실행하면서 구현되는 로직을 평가, 이해하여 비즈니스 로직을 세부적으로 제공할 수 있게 하여야 한다. 이 목적을 위하여 고객이 제공하는 비즈니스 로직을 폼과 폼끼리의 참조를 포함하는 데이터 플로우(data flow) 형태로 우리의 폼 시스템에서 구현할 수 있어야 한다. 고객은 추상적인 ERD 대신에 데이터를 포함하고, 데이터 플로우 로직이 구현되어 있는 폼들을 실행 시켜 보면서 자신이 제공한 비즈니스 로직을 검토할 수 있으며 새로운 로직을 발견할 수 있다. 이러한 과정을 반복적으로 수행하면서 고객과 개발자는 충분히 세부적이고 모순이 없는 분석 과정을 성공적으로 수행할 수 있게 된다.
통상적으로 데이터베이스 어플리케이션을 구현하는 과정은 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 ...
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.
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.
J. Christian, W. Annette, and X. Jurgen, "Generating User Interfaces from Data Models and Dialogue Net Specification," INTECHI, pp.24-29, 1993(4).
H. Balzert, "From OOA to GUIs: The Janus System," IEEE Software, Vol.8, pp.43-47, 1996(2).
F. Bodart, S.-M. Hennebert, J. M. Leheureux, I. Provot, and J. vVanderdonckt, "A Model-based Approach to Presentation: A Continuum form Task Analysis to Prototype," Proceedings of Eurographics Workshop on Design, Specification, Verification of Interactive Systems, Carra, Italy, Focus on Computer Graphics, Springer-Verlag, Berlin, pp.77-94, 1994(6).
M. Elkoutbi, I. Khriss, and R. K. Keller, "Generating User Interface Prototypes from Scenarios," Proceedings of IEEE International Symposium on Requirement Engineering, pp.150-158, 1999.
R. P. Angel, E. Henrik, H. G. Jhon, and A. M. Mark, "Beyond Data Models for Automated User Interface Generation," Proceedings of British HCI. 1994.
김정옥, 유철중, 장옥배, "사용성 중심설계를 지원 하기 위한 사용자 인터페이스 프로토타입의 생성기법", 제31권, 제1호, 정보과학회논문지 2004(1).
D. Harei, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, a. Shtull-Trauring, and M. Takhtembrot, "STATEMATE: A Working Environment for the Development of Complex Reactive Systems," IEEE Transactions on Software Engineering, Vol.16, No.4, pp.403-414, 1990(4).
C. Heitmeyer, J. Kirby, B. Labaw, and R. Bharadwaj, "SCR*: A Toolset for Specifying and Analyzing Software Requirements," Proc. of the 10th. Annual Conference on Computer Aided Verification, (CAV'98), Vancouver, Canada, pp.526-531, 1998.
H. Tauqeer and M. A. Mian, "An Effort-based Approach to Measure Completeness of an Entity-Relationship Model," Seventh IEEE/ACIS Int. Conf. on Computer and Information Science, pp.463-468, 2008.
G. Marcela, P. Geert, and P. Mario, "Defining and Validating Metrics for Assessing the Understandibility of Entity-Relationship Diagrams," Data and Knowledge Engineering Vol.64, pp.534-557, 2008.
D. Hanbi, L. Ee-Peng, W. L. Handy, and P. Hweehwa, "Visual Analytics for Supporting Entity Relationship Discover on Text Data," ISI 2008 Workshops, LNCS 5075, pp.183-194, 2008.
F. Mathias, H. Philip, and L. Stefan, "Model-driven Instrumentation of Graphical User Interfaces," Second Int. Conf.. on Advances in Computer-Human Interactions, pp.19-25, 2009.
H. Shu-qiang and Z. Huan-Ming, "Research in Improved MVC Design Patterns Based on Struts and XSL," Proc. of the 2008 International Symposium on Information Science and Engineering," Vol.1, pp.451-455, 2008.
E. F. Mohamed, "Introduction to the Computing Surveys' Electronic Symposium on Object-Oriented Application Framework," ACM Computing Surveys (CSUR), Vol.32, No.1, 2000(3).
AI-Helper
※ AI-Helper는 부적절한 답변을 할 수 있습니다.