초록 close

실시간 시스템이 복잡해짐에 따라 이를 개발하는 과정에서 객체 지향 설계 방법론과 이를 지원하는 CASE 도구들이 널리 사용되고 있다. 그러나 이런 객체 지향 CASE 도구를 사용할 경우, 설계자들은 별도의 과정으로 객체 중심으로 설계된 모델을 실제 수행되는 주체인 태스크로 변환시켜야 한다. 불행하게도 객체 모델과 태스크는 특성이 근본적으로 다르고, 스케줄 가능성을 분석하기가 어렵기 때문에 이러한 과정을 자동화하기는 매우 어렵다. 이 문제를 해결하기 위하여 많은 CASE 도구에서는 개발자가 직접 수동으로 객체를 태스크로 변환시키도록 요구하고 있다. 결과적으로 개발자들은 자신의 경험을 바탕으로 하여 임시 변통적인 방법에 의존하여 태스크를 유도하고 있다. 유도된 태스크 집합은 결과 시스템의 스케줄 가능성에 직접적으로 중요한 영향을 미친다.본 논문에서는 실시간 객체 지향 설계 모델을 스케줄 가능성을 고려해 다중 스레드 구현으로 자동적으로 변환하는 방법을 제안한다. 본 논문에서 태스크는 다른 주기와 종료시한을 갖는 상호 배타적인 트랜잭션들로 이루어진다. 이러한 새로운 태스크 모델에 대하여 스케줄 가능성 분석 알고리즘을 제시한다. 또한 제안된 방법을 지원하기 위하여 런 타임 시스템과 코드 생성이 어떻게 지원되어야 하는지에 대하여 설명한다. 사례 연구는 단일 태스크 매핑의 부적절성을 보여줌과 함께, 다중 태스크를 수동으로 유도하는 것이 매우 어렵고, 제안된 방법이 실질적으로 유용하다는 것을 명백하게 보여준다.


The object-oriented design methods and their CASE tools are widely used in practice by many real-time software developers. However, object-oriented CASE tools require an additional step of identifying tasks from a given design model. Unfortunately, it is difficult to automate this step for a couple of reasons: (1) there are inherent discrepancies between objects and tasks; and (2) it is hard to derive tasks while maximizing real-time schedulability since this problem makes a non-trivial optimization problem. As a result, in practical object-oriented CASE tools, task identification is usually performed in an ad-hoc manner using hints provided by human designers. In this paper, we present a systematic, schedulability-aware approach that can help mapping real-time object-oriented models to multi-threaded implementations.In our approach, a task contains a group of mutually exclusive transactions that may possess different periods and deadline. For this new task model, we provide a new schedulability analysis algorithm. We also show how the run-time system is implemented and how executable code is generated in our frame work. We have performed a case study. It shows the difficulty of task derivation problem and the utility of the automated synthesis of implementations as well as the inappropriateness of the single-threaded implementations.