• Journal of the military operations research society of Korea
• /
• v.31 no.2
• /
• pp.105-115
• /
• 2005

To ensure interoperability among TADILs, we need inter-operational system of tactical data link that allows sharing of specific, planned information among different TADILs. In this paper, we have proposed the design of a conceptual software architecture of inter-operational system. For developing of a conceptual software architecture, we analyze the actual condition of ADSI used in the US military and identify functions and quality-attributes. Based on these factors, we design the conceptual software architecture for inter-operational system of tactical data link using Attribute-Driven Design(ADD) method. ADD is consist of three phases - choose the module to decompose, refine the module, repeat the steps for every module that needs further decomposition. To evaluate of ADD results, we apply the Software Architecture Analysis Method(SAAM) which is consist of making evaluation scenarios, choosing indirect scenarios, evaluation scenarios' interaction, and creating an overall evaluation. Through the evaluation, we verify the conceptual software architecture of inter-operational system.

• The Journal of Society for e-Business Studies
• /
• v.5 no.1
• /
• pp.123-134
• /
• 2000

Over the past several decades, several architectural approaches have been applied to develop Information Systems, The software architectural model has been recognized as one of the most important methods for improving productivity. Most conceptual models are difficult to understand and interpret at various system models. As a consequence, conceptual models of many Information Systems fail to represent, exploit, and apply to various aspects, which is needed for reducing development step of the architecture. In this paper, we will explain the architectural model as the 4＋1 View of UML. This model integrates the Knowledge Management System into five views： the Logical View, the Process View, the Deployment View, Implementation View, and the Use-Case View. Moreover, this paper will not only provide information on the application of the software architectural model by stakeholders, but also ultimately improve productivity.

• Journal of Information Technology Applications and Management
• /
• v.20 no.2
• /
• pp.69-87
• /
• 2013

The expanded spiral model in this paper consists of five processes of architecture design, architectural construction, architectural maintenance, operation, and architectural management. The former four processes are executed alternatively, while the latter architectural management process is executed continuously interacting with the other processes during the whole life cycle of the system. The expanded spiral model provides a conceptual framework to sort discussions of architectural degeneration into those of product-oriented processes and those of management processes, making it possible to incorporate the models and body of knowledge about project and program management especially those of Project Management Institute, into discussions of architectural degeneration. A good architecture decomposes the software-intensive system into components mutually interacting in a well-formed structure. The architecture design process and the architectural construction process together create the object system with well-designed architecture. The architectural maintenance process prevents the implemented architecture deviate from the designed architecture. The architectural management process monitors the changes of requirements including architecturally significant requirements, supports the other processes to be executed reflecting various perspectives of stake-holders, and creates and documents the reasons of architectural decisions, which is considered as a key element of the architecture.

• International Journal of Computer Science & Network Security
• /
• v.21 no.12
• /
• pp.9-20
• /
• 2021

Abstraction applied in computer networking hides network details behind a well-defined representation by building a model that captures an essential aspect of the network system. Two current methods of representation are available, one based on graph theory, where a network node is reduced to a point in a graph, and the other the use of non-methodological iconic depictions such as human heads, walls, towers or computer racks. In this paper, we adopt an abstract representation methodology, the thinging machine (TM), proposed in software engineering to model computer networks. TM defines a single coherent network architecture and topology that is constituted from only five generic actions with two types of arrows. Without loss of generality, this paper applies TM to model the area of network monitoring in packet-mode transmission. Complex network documents are difficult to maintain and are not guaranteed to mirror actual situations. Network monitoring is constant monitoring for and alerting of malfunctions, failures, stoppages or suspicious activities in a network system. Current monitoring systems are built on ad hoc descriptions that lack systemization. The TM model of monitoring presents a theoretical foundation integrated with events and behavior descriptions. To investigate TM modeling's feasibility, we apply it to an existing computer network in a Kuwaiti enterprise to create an integrated network system that includes hardware, software and communication facilities. The final specifications point to TM modeling's viability in the computer networking field.

• Magazine of the Korean Society of Agricultural Engineers
• /
• v.43 no.4
• /
• pp.79-88
• /
• 2001

Agricultural facilities can be designed by conceptual preliminary primary and detailed design stages. because each stage has a different objective, it must be applied to dissimilar design and analysis level. Engineers have to judge from evaluation that is estimated agricultural resources in the conceptual design stage. Methods of computer aided design are achieved to individual functions however it is inefficient to perform entire processes of design and hard to systematically accumulate results o design. Study on the integrated structural design system has been continued. but those system have adopted “closed architecture”which is known to inflexible method for developing applications. In this study the design platform is an environment that can support to integrated design system independently and an design platform is proposed by analyzing design processes using object oriented method. The concepts of software platform have resulted from several practical ideas, OOA/OOP and related some points. This paper aims at developing the software platform of a software environment to support the design phases of the agricultural facilities.

• The Journal of Society for e-Business Studies
• /
• v.5 no.2
• /
• pp.81-99
• /
• 2000

Nowadays, many commercial ERP products, such as Oracle, SAP, and Baan, etc, are designed based on large-scaled companies. It is difficult for small and medium-size companies with weakness in budgets and resources(e.g., human, organization, technique, and so on) to use them as it was. So, new ERP system need to be provided for small and medium-size companies. In this paper, we model and provide a conceptual ERP model for small and medium-size companies by using "4＋1 View" architecture model of Unified Modeling Language(UML). The conceptual ERP model consists of five subsystems： Manufacturing, Sales, HumanResource and Payroll, Accounting, and Trading. Especially, we describe the conceptual ERP model focusing on "Manufacturing" subsystem by using several diagrams of UML. By using the conceptual ERP model, the ERP system′s developers of small and medium-size companies can obtain many benefits： improving the efficiency of software developing process and helping user requirements gathering and description of ERP system′s nonfunctional aspect as well as functional aspect.

• Journal of Information Technology Services
• /
• v.1 no.1
• /
• pp.141-148
• /
• 2002

As an optimun alternatives for the solution of recent software crisis, we have to develop component technologies so as to develop and propagate business components for various domains to industries. For the sake of development of business components, a conceptual architecture which defines a model for component assembly should be prescribed first, and a systematic specification method based on this model be defined, so we can build a system environments for making specifications and development of each component by the consistent scheme. In this study, we propose a domain architecture model for implementing the pUblic component bank as a project supported by the ministry of information and communication, discuss the conceptual model of specification for developing components of storing component bank, specification steps, specification approach for application of business domains and the development results of them.

• Proceedings of the Korea Database Society Conference
• /
• 1998.09a
• /
• pp.525-543
• /
• 1998

This paper proposes a conceptual taxonomy of architectures far workflow management systems. The systematic classification work is based on a framework for workflow architectures. The framework, consisting of generic-level, conceptual-level and implementation-level architectures, provides common architectural principles for designing a workflow management system. We define the taxonomy by considering the possibilities for centralization or distribution of data, control, and execution. That is, we take into account three criteria. How are the major components of a workflow model and system, like activities, roles, actors, and workcases, concretized in workflow architecture？ Which of the components is represented as software modules of the workflow architecture？ And how are they configured and operating in the architecture？ The workflow components might be embodied, as active (processes or threads) modules or as passive (data) modules, in the software architecture of a workflow management system. One or combinations of the components might become software modules in the software architecture. Finally, they might be centralized or distributed. The distribution of the components should be broken into three: Vertically, Horizontally and Fully distributed. Through the combination of these aspects, we can conceptually generate about 64 software Architectures for a workflow management system. That is, it should be possible to comprehend and characterize all kinds of software architectures for workflow management systems including the current existing systems as well as future systems. We believe that this taxonomy is a significant contribution because it adds clarity, completeness, and "global perspective" to workflow architectural discussions. The vocabulary suggested here includes workflow levels and aspects, allowing very different architectures to be discussed, compared, and contrasted. Added clarity is obtained because similar architectures from different vendors that used different terminology and techniques can now be seen to be identical at the higher level. Much of the complexity can be removed by thinking of workflow systems. Therefore, it is used to categorize existing workflow architectures and suggest a plethora of new workflow architectures. Finally, the taxonomy can be used for sorting out gems and stones amongst the architectures possibly generated. Thus, it might be a guideline not only for characterizing the existing workflow management systems, but also for solving the long-term and short-term architectural research issues, such as dynamic changes in workflow, transactional workflow, dynamically evolving workflow, large-scale workflow, etc., that have been proposed in the literature.

• The Journal of Information Technology and Database
• /
• v.5 no.1
• /
• pp.97-108
• /
• 1998

This paper proposes a conceptual taxonomy of architectures for workflow management systems. The systematic classification work is based on a framework for workflow architectures. The framework, consisting of generic-level, conceptual-level and implementation-level architectures, provides common architectural principles for designing a workflow management system. We define the taxonomy by considering the possibilities for centralization or distribution of data, control, and execution. That is, we take into account three criteria. How are the major components of a workflow model and system, like activities, roles, actors, and workcases, concretized in workflow architecture. Which of the components is represented as software modules of the workflow architecture\ulcorner And how are they configured and operating in the architecture\ulcorner The workflow components might be embodied, as active (processes or threads) modules or as passive (data) modules, in the software architecture of a workflow management system. One or combinations of the components might become software modules in the software architecture. Finally, they might be centralized or distributed. The distribution of the components should be broken into three: Vertically, Horizontally and Fully distributed. Through the combination of these aspects, we can conceptually generate about 64 software Architectures for a workflow management system. That is, it should be possible to comprehend and characterize all kinds of software architectures for workflow management systems including the current existing systems as well as future systems. We believe that this taxonomy is a significant contribution because it adds clarity, completeness, and global perspective to workflow architectural discussions. The vocabulary suggested here includes workflow levels and aspects, allowing very different architectures to be discussed, compared, and contrasted. Added clarity is obtained because similar architectures from different vendors that used different terminology and techniques can now be seen to be identical at the higher level. Much of the complexity can be removed by thinking of workflow systems. Therefore, it is used to categorize existing workflow architectures and suggest a plethora of new workflow architectures. Finally, the taxonomy can be used for sorting out gems and stones amongst the architectures possibly generated. Thus, it might be a guideline not only for characterizing the existing workflow management systems, but also for solving the long-term and short-term architectural research issues, such as dynamic changes in workflow, transactional workflow, dynamically evolving workflow, large-scale workflow, etc., that have been proposed in the literature.

• The KIPS Transactions:PartD
• /
• v.8D no.6
• /
• pp.761-770
• /
• 2001

As software industry is rapidly evolving, IT business enterprises have been meeting with cutthroat competition in developing software. As software reusability, time to market, and maintainability are considered as a competitive edge, software component techniques have lately attracted considerable attention. Currently, although there are some supporting tools for developing software components, they do not have tight connections among component developing processes such as component identification, component modeling, detailed design, code generation, deployment, and testing. And it is restrictive for users to construct various scales of components on component platform architecture. In this paper, we provide an implementation and a design of a supporting tool for constructing platform-independent software components, which covers all development lifecycles of components. In the phase of component modeling, platform independent, conceptual components are identified from domain model information in the view of system partitioning. Detailed design and implementation of a component are performed on the J2EE platform architecture. And the changes on the design model and source codes are consistently managed by using round-trip techniques.