1. Introduction
The business complexity of a company is increasing with the advancement in IT technology [1], and its success is also related to the well-made information system. Performance would differ depending on how much complex business is involved in the information system. Many studies have been conducted to develop information systems successfully [2,3]. In addition, a fast, accurate information system should ideally be made as the development speed becomes faster and the development cycle is shortened in the present compared to the past. Many studies have been done on the design and implementation by architecture from the enterprise perspective in an effort to meet client requirements [4,5], as a result, various development methodologies have emerged. A lot of technological advancements have been made as well from the application’s point of view of the enterprise-wide architecture domains, and various development methodologies have been studied and applied to actual projects according to the development's characteristics and requirements [6,7]. Nevertheless, there are some difficulties in designing the application. From an enterprise perspective, the design method should lead to an application, and the database architecture is designed based on the business it is derived from. From the enterprise perspective, the design is done for each architecture domain, and existing business analysis procedures have been analyzed in relation to the application; note, however, that there is an inclusive part in the conversion process of the design for each architecture domain, with a part requiring the designer’s experience-based design in the application design as well. Various knowledgebased designers and developers are involved in developing an application, and the experience-based design may cause difficulties in communication between designers or between designers and developers. In addition, the experience-based design elements pose many difficulties to persons who lack experience in developing applications in carrying out the design. To solve these problems, this study would like to define the application’s operations based on the business derived through business analysis as a procedure for designing the application as well as design screens displaying the state of application where the defined process is completed.
2. Related Studies
2.1 Data Flow Diagram
The data flow diagram (DFD) is a tool primarily used in the structured analysis technique, which focuses on data to express changes applied by the information entered between components configuring a system and the result in the form of a network. The DFD is a top-down method which draws from large processes to small ones and the control and order, etc., of data are represented from a different point of view because it focuses on the data [8,9]. The DFD consists of four components: external objects, processes, arrows, and repositories. The external object is responsible for the input and output of data at the boundary of a DFD, representing the start and end of data generation in the process handling procedure. The process plays the role of a converter that converts input data into the desired data to output it in a system, which is represented by describing a process name or an actor performing the process in a circle. The flow of data represents the interface between the components of a DFD, and it is indicated by an arrow. The data repository is a file or a database system that stores data, and it performs data storage or access requests. The DFD uses four components to express in detail what users require from a higher level to a lower level and to derive the structure of the system. In the structural analysis technique, the DFD represents the overall appearance of the system from a data perspective.
2.2 Use Case Scenario
Object-oriented analysis techniques have been proposed and developed due to the fact that they can accurately reflect real-world structures and increase productivity through reuse. When analyzing the client's requirements to design with an object-oriented analysis technique, the system’s actors and use cases they perform are derived to draw a use case diagram, and a use case scenario is created for each use case [10-12]. A use case scenario shows the flow and process of events for each use case by the information exchanged between the system and the actors or generated between the use cases. The use case scenario specifies the role performed by the relevant use case in the system and the details and includes the related use cases needed to perform the event. In addition, the details of event processing where the use case is executed are classified into basic flow items to separate and describe the procedures to be processed. In a use case, other situations except those represented by the basic flow are classified into an alternative flow, and the flow performed to handle the error, etc. generated in the system is classified into an exception flow to draw it [13,14]. Object-oriented analysis techniques visually present to the user through a use case and describe the details through a use case scenario. Because the use case scenario expresses the content of the actions performed by each use case, the flow of data is expressed through different procedures, and many procedures must be performed.
2.3 User Story
The agile development technique has been studied in order to be flexible in responding to changes in requirements and to pursue the development process's efficiency [15,16]. In order to express the client’s requirements or software functions instead of documenting them in accordance with the efficiency pursued by the agile technique, a brief user story of one or two sentences is prepared. A user story is focused on a short developmental life cycle for the purpose of activating communication rather than detailed specifications, so a small number of persons implement and test it within a short time. By carrying out short, small-size development, it continues to reflect the client's requirements to pursue development. User stories perform analysis and development in small to large units due to the development characteristics. Because it reflects the changing requirements, all of the derived businesses are not transformed. In addition, there are difficulties in larger projects particularly grasping the overall flow of the system.
A use case scenario and a user story express the flow executed by a system in writing, so there may be difficulties in communication depending on the developer’s extent of understanding. This study would like to visualize the overall flow of a system to achieve communication more clearly.
3. Business-Based Application Screen Design
This study would like to present a screen design procedure that converts business and element processes derived under the condition of assuming that the business and element processes are divided for derivation by applying four actions needed for an application, such as C (create), R (read), U (update), and D (delete) into screens based on the “product order system” [17] as a business defined from the enterprise perspective to develop information systems [18]. The screen design procedure consists of two major steps and designs the screens used by users and the DFD showing the overall data flow for each business.
3.1 Screen Design
In the screen design, the aim is to make a prototype which is the completed form of an application to check whether the client’s requirement is exactly reflected to reduce the cost required to modify it during or after development and communicate effectively with designers and developers possessing various kinds of know-how in visual information. The screen is designed by composing one or more business and element processes to reflect what is used in the actual environment and for convenient use by users. It is also composed of screens for users to use services and windows such as address search and warning for convenience in executing applications. For the design of screens, it first designs the information management business necessary to execute applications, and then the screen of the business actually executed using the constructed information [19,20].
In this study, we would like to describe the process of transforming the business process designed for employee registration into a screen design. Table 1 shows the employee registration process designed in process design.
The screen design represents the state of the screen where the relevant process is performed, and it is divided into three parts: data entered as information delivered on the relevant screen, events indicating the screen's operation, and data displayed on the screen.
Fig. 1 shows the employee registration screen of the employee’s information management screens in the “product order system.” For the screen's appearance, which component is used to represent information is pre-set, the information of the relevant component such as position and size is a visual representation, and one or more data sets are displayed on a screen. Thus, the data set information represented in the relevant component is displayed together.
Employee registration process in business process
Screen for employee registration.
As information displayed on the screen, data input is shown when the screen starts or new data is displayed when an event occurs. The screen’s input data is divided into internal and external, the internal input data refers to the data displayed after internally calculating when accessing a database to import data or a specific event occurs, or the data to be entered by users; external data refers to the data when receiving data after opening another screen or window or temporarily moving from the screen currently in progress to another screen or window to undergo a series of processes. For the input, the entered information is specified with an “in” symbol. In the creation process of the information management process needed for the application’s operation as in Fig. 2, there is no input value when initially executing the screen because users make an empty input. In this case, it enters “none”, which means that there is no input data when the screen is initially operated; if input is made several times, “in” is appended with a number to indicate several inputs. When there is an input, it should be expressed for the relevant input information, and the information entered by users is expressed by an “I (input)” symbol after the entered data. In addition, more than two pieces of information are connoted into a data set to express because the relevant input information is continuously used in the future. It also details which types of information initially construct the connoted information. The detailed information about the data set specifies first which columns make it up as indicated by double curly brackets if a result of more than two rows is required at a time separates the information that requires input in connection with the data architecture, or gets stored as data but not displayed on the screen; for the data accessed by the database to import for the source of the relevant data, a query such as the database’s table and condition to import the relevant data is specified.
Input on the employee registration screen.
The action means a process procedure generated by an event on the screen and represents a processing procedure to be performed in detail. The event is generated by a component or an input device such as mouse and keyboard, etc., an action could be performed internally, and the data is transferred and moved to another window or screen.
Since the action represents a procedure necessary for actually performing business, it includes various processing procedures, and multiple actions may be performed complexly to be represented. The action represents the processing with a “>” symbol when the relevant event occurs and with a “>>” symbol when the window displayed on the current user’s screen or the screen is closed and data gets delivered and moved.
Event on the employee registration screen.
Fig. 3 shows the actions on the “employee registration screen” they are represented by a “[]” symbol when clicking a component to generate an event; data transfer or internal function call is also indicated, and data is connoted into a set unit to express. For a function, its function name and parameters are briefly indicated like data, representing a definition of the function on the first use. Since performing an action expresses complex business, it is also represented if performed in accordance with various conditions, and the condition for an action is separated with “c()?” if it corresponds to the condition, it is divided into “true” and “false” to execute according to the command after the “?” if true and write a command to be executed if false by separating with a “:” symbol after the true command if false. If there is no execution when false, it is represented by omission, and the condition of the database is expressed with “w().”
Data expressed on the employee registration screen.
The data of the screen is represented by linking the database's information in terms of data expressed on the screen considering the relation with the data architecture from the enterprise perspective. Fig. 4 shows the “employee view information 1” information represented on the screen. The data name, size, type, etc. are created the same as the physical database’s information, and the condition or format representing the data is separated with the “f()” symbol to indicate together. The data of the screen is divided into two types the data whose value is entered by users and the data received from the database or another window or screen and the information entered by users is specified with a “Keyin” after the data information. If the relevant data is not the user’s data, it indicates the source of the relevant data.
3.2 DFD Design
The DFD shows the overall flow of a screen for each business, which expresses the screen design contents for each business in contracted form. The DFD shows the order of executing business and element processes of the relevant business on the screen for each business unit and briefly indicates the data transferred when moving between screens and the data displayed on the screen.
A rounded rectangle is divided by a line to enter the screen name at the top and indicate the screen contents displayed on the screen at the bottom; if there are many screen contents, they are contracted for entry. In addition, a color is added to express the figure if only the administrator is allowed to access the screen. A rectangle means an internal function, and the internal function name is entered. When expressing an internal function, the function name and the passed transfer value are entered together. A double rectangle is a system function indicating a case wherein the system creates and changes data on its own. When accessing a database to import or record data, the database is represented by a magnetic disk model. For database access, the database query statement is briefly expressed with a pseudo-code for developers’ easy understanding later. The movement of information or screens caused by an event is expressed by an arrow, and the object generating the data or event is indicated on the arrow (Table 2).
Representation of objects in DFD
Comprehensive DFD of employee management.
Fig. 5 shows the overall data flow of the business and element processes derived from the “employee information management” business, which expresses a comprehensive data flow if displaying all the data on a screen is difficult; the lower data flow is expressed as Fig. 6.
Employee registration DFD of employee management.
4. Comparison with Other Studies
In this chapter, other methods that have been studied to design an application successfully are compared with the method proposed in this study. The comparison component compared the elements that should be expressed for application design (Table 3).
Comparison with other studies
5. Conclusion
Developing an information system successfully requires designing and developing it from the enterprise perspective as well as being able to express fully the business in the application architecture based on the derived business.
This study derived the process procedure for applications to perform the business based on the defined business, presented the prototyped screens based on such, and proposed how the process defined through data representation and transfer on the screen is converted. The use of this method is expected to reduce the cost required for redevelopment in advance by reviewing the client's requirements and minimize possible problems through efficient communication between designers and developers with diverse experiences. In addition, persons who lack design experiences could also carry out the application design effectively.
In the future, a study should be done on the class design that derives objects for application development based on the screen design presented by this study.
Acknowledgement
This work was supported by a Research Grant of Pukyong National University (2017 year).