New version page

From Use Cases to System Implementation

Upgrade to remove ads

This preview shows page 1-2-3 out of 10 pages.

Save
View Full Document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience

Upgrade to remove ads
Unformatted text preview:

From Use Cases to System Implementation: Statechart Based Co-designLuís Gomes, Anikó Costa Universidade Nova de Lisboa, Faculdade de Ciências e Tecnologia, Dep. of Elect. Eng. & UNINOVA, Centro de Robótica Inteligente 2825 Monte de Caparica, Portugal {lugo, akc}@uninova.pt Abstract This paper proposes a methodology for embedded systems co-design, based on statechart models. The process starts with grabbing the system functionalities through use cases. A set of procedures addressing the implementation of Statechart models is presented. The main goal of this set of procedures is to lift the structuring mechanisms presented in statecharts to the top level. In this sense, the complexity of statechart implementation will be similar to the complexity of communicating concurrent state machines and the platforms selected to support implementation will not need to have specific capabilities to directly support the structuring mechanisms of Harel’s statecharts. As a consequence, full direct implementation of statecharts is possible considering different types of implementation platforms, ranging from hardware-centric or software-centric to hardware-software partitioning through co-design techniques. 1. Introduction The concurrent design of hardware and software proved to be effective to improve cost-performance relation in the design of embedded systems when compared with the traditional way of separated design flows associated with hardware and software components. Many computational models have been referred in the literature to specify embedded systems, accommodating co-design techniques. In the present paper, we may roughly characterise an embedded system through the following equation: Embedded system = Reactive system + Real-time constraints + Data processing capabilities (1) In this sense, the selection of a model of computation should consider the reactive nature of the embedded system, without forgotten real-time and data processing constraints. From the point of view of the reactive system, ideally, a model of computation should include capabilities to represent concurrency and sequential behaviours, and to assure communication and synchronisation among concurrent components. Also, accommodating hierarchical model structuring mechanisms is a key convenience, from the engineering point of view, in order to enable a compact representation of the system model using different levels of abstraction. In the present paper, we propose a development methodology applicable for embedded system co-design, starting from high-level requirements, characterised in a very informal way, and ending-up with the implementation code, that is adequate to be used in different platforms, ranging from software-centric to hardware-oriented components. The paper starts with a brief description of the proposed methodology and characterisation of the statechart formalism. In the following section, an example is introduced in order to allow illustration of the referred procedures. Co-design specificities come into action in the next sections through the analysis of the model partitioning and statechart implementation issues, considering either hardware, software or mixed based implementation platforms. At the end, final remarks regarding the example is produced and conclusions are presented. 2. Methodology overview According to [1], the specification of a system should accommodate several views, namely: - Functional view; this view is responsible to capture “what” should be implemented, in terms of inputs and outputs, functionalities and activities; - Behavioural view; this view is responsible to capture “when” should the system exhibit some specific behaviour or take some specific action; it is responsible to model the dynamics of the system, in terms of the control point of view and from the time dependency of events; aspects like concurrency and synchronisation should also find a way to be represented; Proceedings of the First ACM and IEEE International Conference on Formal Methods and Models for Co-Design (MEMOCODE’03) ISBN 0-7695-1923-7/03 $17.00 © 2003 IEEE Authorized licensed use limited to: West Virginia University. Downloaded on October 8, 2008 at 15:27 from IEEE Xplore. Restrictions apply.- Structural view; this view is responsible to capture “how” should the system be composed in terms of the components and interconnections between them. Also, according to [2], non-trivial systems should be modelled through a small set of independent sub-models. The referred roots allow us to propose a design methodology described by Figure 1. The system’ initial requirements are kept using UML use cases [2]. In this sense, capture of complex and also primitive functionalities are obtained in an informal way, constructing a set of use cases, which can be afterwards validated by users at the very beginning of the design process. In this process, different levels of perception of the system’s functionalities are possible, using hierarchical structuring mechanisms common in UML techniques. The different actors that interact with the system are identified, and their interrelations as well. Use case diagramSequence diagramsStatechartComponent partitioningAllocation of componentsto hardware or softwareAllocation to specificplatformsDefinition ofassociated structureFigure 1. Methodology overview. The next step is to produce a model of the system that can be used both for specification and for implementation. From the goals characterised in the introductory section, statecharts [3] [4] were selected to be the specification formalism to accommodate behavioural modelling. We can benefit from the fact that the same model that we use to produce a specification model can be also used as the basis for the implementation. In this sense, we need a way to produce the system model starting from the use cases description. Two ways are foreseen: - Directly translate each use case into a statechart (or a state diagram); - Translate each use case into a sequence diagram, which is in turn amenable to be represented by a statechart [5]. From our experience till the moment, we only used direct translation. However, for some applications, it is understood that sequence diagram usage seems to be very valuable. Procedures enabling the translation of sequence diagrams into statecharts are known from the literature and can be applied for this task. The system model will be built based on the


Download From Use Cases to System Implementation
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view From Use Cases to System Implementation and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view From Use Cases to System Implementation 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?