Transforming Pattern-Oriented Models into

1 downloads 0 Views 127KB Size Report
Pattern-Oriented Analysis and Design (POAD) methodology together with the ERT domain analysis patterns are .... classes defined as the pattern interfaces are.
The First Malaysian Software Engineering Conference (MySEC’05)

Transforming Pattern-Oriented Models into Component-Based Models for Embedded Real-Time Software Development Dayang Norhayati Abang Jawawi, Radziah Mohamad, Safaai Deris Department of Software Engineering Faculty of Computer Science and Information System, Universiti Teknologi Malaysia 81310 UTM, Skudai, Malaysia [email protected]

Rosbi Mamat Department of Mechatronics and Robotics Engineering Faculty of Electrical Engineering, Universiti Teknologi Malaysia 81310 UTM, Skudai, Malaysia

ABSTRACT An approach to software reuse using pattern-oriented models and component-based models in Embedded Real-Time (ERT) domain is proposed in this paper. A pattern oriented-modeling methodology called Pattern-Oriented Analysis and Design (POAD) methodology together with the ERT domain analysis patterns are used for software analysis and early design, while an ERT component model called PErvasive COmponent Systems (PECOS)is used for modeling of the detail design using component-based technique. The transformation of the pattern-oriented model into the component-based model is required to convert the diagrams in the early design phase represented by POAD model into the diagrams represented by PECOS model at design phase. The issues in transforming the pattern-oriented models into the componentbased models for ERT software development are discussed and illustrated. The transformation process is accomplished by mapping the POAD meta-model to the PECOS meta-model. The transformation process is illustrated using a software design case study and verified experimentally through implementation on an Autonomous Mobile Robot (AMR) system. The results of the case study reflect the advantage of combining the POAD and PECOS models as it enables high-level reuse software in ERT systems without sacrificing the non-functional requirements such as timeliness, predictability and constrained resources.

KEYWORDS Pattern-oriented analysis, component-based design, reuse software, embedded real-time systems This work promotes software reuse at analysis and design level using software analysis pattern and component-based design. Software analysis pattern is a means to facilitate software knowledge reuse at analysis phase. In component-based design, a component model specifies the standards and conventions imposed on developers of components. In this work the Pattern-Oriented Analysis and Design (POAD) methodology for the deployment of the analysis pattern and the PErvasive COmponent Systems (PECOS) component model for modeling of the detail design using components.

1. Introduction Software reuse has becoming a popular approach to increase software productivity, improve software quality, consistency and reliability, and at the same time decrease the costs of software development. The need to reuse software components in Embedded Real-Time (ERT) systems poses a significant challenge to industrial software processes due to the code size and real-time constraints of the systems. The question in ERT reuse is how to get the benefits of reuse without sacrificing the non-functional requirements of ERT systems such as timeliness, predictability, safety-critical and constrained resources.

Pattern-Oriented Analysis and Design (POAD) methodology is an approach to design software applications using software patterns and produce pattern-oriented analysis and design [2]. The POAD methodology is selected due to its capability to glue patterns at high-level using Unified Modeling Language (UML). The main features of PECOS component model are the data-flow-oriented programming style and the explicit incorporation of non-functional requirements [3]. For details design PECOS model is selected since it offers an ultra-light

The reuse approaches include reuse architecture, framework, patterns, code or library components. For ERT software the most problematic reuse has been attempted at the code level, but reuse is more effective and safe by going back to an earlier development phase because it allows engineering teams to tailor reused components and designs to fit their needs rather than requiring them to fit their needs to a particular piece of code [1].

18

The First Malaysian Software Engineering Conference (MySEC’05)

Red (IR) proximity sensors and a distance sensor.

weight model which enable optimization of code size and can explicitly describes the real-time behavior of a component.

The embedded software must support the intelligence aspect of the robot in order to response to the conditions in the environment in achieving the goal. The intelligence of AMR is supported by a behavior-based control using subsumption architecture [2]. To support multitasking requirements of the software, a preemptive Real-Time Operating System (RTOS) is used in the robot software. The embedded controller also communicates with human through Liquid Crystal Display (LCD) and switches.

The transformation of the pattern-oriented model into the component-based model is required to convert the diagrams in the early design phase represented by POAD model into the diagrams represented by PECOS model at design phase. The structural construct of the ERT software at component level is the main interest here. The transformation process is accomplished by mapping the POAD meta-model to the PECOS meta-model. A clear mapping of the two models will enable CASE tools to be developed based on the two models. This transformation process is illustrated using an ERT software case study, and the technical choices made in the mapping process are discussed.

2.1 POAD Model for Analysis and Early Design In analysis phase, suitable candidates from AMR analysis pattern components [4] that could capture the main requirements of the problem are identified. By matching the AMR software requirements as modeled in use-case diagram in Figure 1, with the context and problem elements available in AMR analysis patterns, a mapping of the application requirements and the AMR analysis patterns is obtained. From this mapping, a POAD Pattern-Level Diagram which specifies the AMR pattern instances and their relationships for this case study is developed as shown in Figure 2.

The layout of this paper is as follows. In Section 2 the transformation between pattern oriented model and component based model is illustrated using an ERT case study. Section 3 shows the mapping of the POAD meta-model to the PECOS meta-model and discusses technical choices made in the mapping process. Finally, the conclusion is presented in Section 4.

2. Component-Based Development using POAD and PECOS Pattern-oriented model and component-based model used in this work are to support Component-Based Software Engineering (CBSE) approach for ERT software development of Autonomous Mobile Robot (AMR). To illustrate the transformation process of POAD to PECOS models, a step by step modeling of an AMR software case study in component-based development is illustrated in this section. The modeling will only consider structural modeling and real-time behavior modeling in order to illustrate the component level modeling.

Configure

Operator

Display Battery Status

Display Robot Status

Display Robot Mode



Control Robot Movement

Control Motor

Detect Obstacle Occurence

Obstacle

Measure Object Distance Monitor Environment

The AMR considered in this case study is a wheeled AMR, capable of traversing in a structured environment, which is surrounded by walls. The goal of the robot software is to navigate the robot intelligently in finding a passage and exiting through the passage while avoiding obstacles during its motion. The AMR consists of a body and a pair of wheels. Each drive wheel is actuated by a Direct-Current (DC) motor. The speeds of the motors are sensed using shaft encoders and fed back to the on-board embedded controller for computation of control signal to the DC motors every 50 milliseconds using the Proportional-Integral (PI) control algorithm. The embedded controller also monitors the robot environment using four Infra

Wall

Detect Wall Existance

Figure 1: The AMR use case diagram The POAD methodology suggests these pattern instances creation is performed at the design phase, but we performed this creation at analysis phase in order to visualize the mapping process of the use case diagram and the analysis patterns selected. The initial composition at this stage can also capture the main requirements of the AMR problems and model the problem using the analysis pattern.

19

The First Malaysian Software Engineering Conference (MySEC’05)

Switches

The relationship between patterns instances in Figure 2 can be further detailed out to a design relationship using interfaces in Pattern-Level with Interface diagram. For example, Figure 3 shows a section of the Pattern-Level with Interface diagram relating the four packages involved in the AMR intelligence behavior: Switches, IR Distance Sensor, IR Proximity Sensor, and Subsumption Architecture.

Operator

IR Proximity Sensor

Obstacle

Send new control signal

Update distance reading

Update current motor value

Encoder Left

< < S en so r> > IR D ista n ce S e n so r

Avoid

S u b su m ption A rch ite ctu re follo w w all b e ha vio r

IR Proximity Sensor

Figure 4: Detail internal classes representation for AMR intelligence behavior Motor Left

2.2 PECOS Model for Detail Design PECOS model supports component integration with static structure and execution model. The static structure of the model is specified using component, ports and connectors. Figure 5 shows the static structure integration of components to design the AMR software. The integration consists of ten active components with period and its priority specified at the upper right corner, and four passive components. In PECOS, active component is a component with its own thread of control; passive component is a component without its own thread of control; and events component is a component that is triggered by events.

Encoder Right

Motor Right

a ctu a to r actio n a vo id b eh a vior

The integration in Figure 5 consists of eight leaf components and six composite components shown by blocks with shadow. Composite component contains a number of subcomponents. For example motorctrl_right is a composite component that consists of encoder, PI and motor subcomponents.

u p d ate ()

< < S e n so r> > IR P roxim ity S e n so r

1

update()

stop b e h avio r

fin d w a ll b e h avio r cru ise b e ha vio r

Selector Arbiter

Follow Wall

Figure 2: Pattern-level diagram for the AMR software setva lue ()

Cruise

Find Wall

PI Control Right

Send new control signal

< < IO > > S w itch es

IR Distance Sensor update()

Set desired control value

IR Distance Sensor

Wall

IR Distance Sensor

IR Distance Sensor driver

Set desired control value Subsumption Architecture

Stop

IR Proximity Sensor driver

Update switch status

Update object existence status

Actuator Action

1

PI Control Left

Update behavior

Subsumption Architecture

IR Proximity Sensor

Update current motor value

Robot Status

Digital IO setValue()

Battery Sensor

Update battery level

Switches

IO driver

up d a te ()

Figure 3: Pattern-level with interface diagram for AMR intelligence behavior Once the Pattern-Level with Interface diagrams similar to Figure 3 were obtained, each of the generic analysis patterns in the diagram needs to be renamed, classes in the pattern need to be detailed out according to the specific AMR system, and the tracing of pattern interfaces to internal classes need to be defined. Figure 4 shows the results obtained from Figure 3 following those processes. All function and classes defined as the pattern interfaces are connected directly to show the relationship between the internal classes in each pattern.

The execution model describes actual runtime semantics and how data between components are synchronized. The PECOS synchronization and mutual exclusion are supported with Petri-nets using data places, control places and event places. Petri-net diagram in Figure 6 shows the representation for Avoid component. The synchronization and mutual exclusion between the data places (shown in darker color) using the control places (shown in lighter color). Thus, component integration using PECOS model can explicitly describes the real-time behavior of a component using component types in static structure, and Petri-nets diagram used in execution model provides synchronization models to enable prediction of timing properties.

The detail internal classes of Figure 4 acts as the initial class diagram for static design model of the AMR software. Up to this point, POAD methodology provides logical views to represent AMR application analysis and design as a composition of the patterns using structural elements of UML.

20

The First Malaysian Software Engineering Conference (MySEC’05)

MobileRobot 400ms

Avoid 400

IR Proximity

IP00

OP00

IP01

OP01

[1000 20 0 50]

Subsumption 400ms

OP00

7

IP00

OP01

FollowWall 400

OP02 OP03

DistanceSensor

10 OP00

IP01

OP01

IP02

OP01

IP05

OP02

IP06

OP03

IP08

OP01

5

OP00

IP01

motorctrl_left 50 ms

IP00

IP07

OP00

50 ms

IP00

IP02

IP04

11

IP00

OP00

IP03

FindWall 400

motorctrl_right

IP01

IP00

OP00

1

9

OP00

IP01 OP04

IP09

6

IP02

Cruise

[1000 20 0 50]

400

13 OP00

IP00

OP01

manrobotintf IP00

switches

Stop 400

OP00 OP01

12 OP00

IP00

15

IP01

BatterySensor

IP02 OP00

OP01

OP02

500ms

IP03

Figure 5: Component integration using PECOS model end IR 1

start

synch avoidFlag

IR 2

avoidCommand cs

Avoid

Figure 6: A component in execution model Figure 7: The AMR platform used for software verification

2.3 Implementation Results Following the models previously described in Section 2.1 and 2.2, the AMR software composed as in Figure 5 was implemented and embedded on a real mobile robot shown in Figure 7, consists of a 16-bit AMD188ES microcontroller with 64Kb ROM and 128Kb RAM. The software tools used for the software development are Paradigm C compiler [6] for generating ROMable code and μC/OS-II realtime kernel [7] for multitasking support. The total code size for the resulting application is about 21Kb with RAM usage of about 15Kb. This indicates that, the models proposed can generate application with minimal memories requirements, suitable for other resource constrained embedded systems. The real-time behavior of the AMR system was verified experimentally and the mobile robot was found to be functioning according to the specifications.

3. Mapping POAD to PECOS Model The true strength of POAD methodology is the composition approach to glue patterns at highlevel using UML as a means to capture all the models generated from development process. UML meta-model is rich of selection and standardization in supporting Object-oriented (OO) modeling. Figure 8 shows the relation of the primary elements in POAD meta-model that are extended to UML class diagram. Five key elements extended to the UML meta-model that enable pattern-oriented composition using POAD are: (i) Pattern. A constructional pattern whose solution is a set of collaborating classes.

21

The First Malaysian Software Engineering Conference (MySEC’05)

(ii)

(iii)

(iv)

(v)

PatternInterface. A set of classes and operations used to define how the pattern interfaces to other patterns. PatternDependency. It indicates a semantic relationship between two patterns. PatternAssociation. It defines a semantic relationship between the interfaces of two patterns. InterfaceBinder. It is used to connect the PatternInterface to the corresponding internal elements in a pattern. PatternDependency 1

2

(iii)

(iv)

In the mapping process to enable smooth transformation from pattern-oriented model using POAD and component-based model using PECOS, each element of POAD meta-model must provide information that are necessary to create detail design using PECOS model. By mapping the two meta-models, three transformation issues need to be clarified: (1) how to migrate pattern to component ? (2) how interfaces in the two models can be mapped ? and (3) How real-time behavior can be explicitly expressed in the two models?

Pattern

connect

name

InterfaceBinder

PatternInterface

Class

Constraint

Relationship

2 connect

QoS

1

PatternAssociation

Operation

Attribute

procedure that reads and writes data available at its ports is called behavior of a component. Connector. It specifies the data-sharing relationship between the ports. Connectors may only connect ports of compatible type, direction and range. PropertyBundle. A group of properties that are used to characterize aspects of components, such as timing or memory usage.

Real-Time Behavior

Figure 8: Overview of POAD Metamodel In POAD, the functional structure description is given by structural model. However, for a realtime system, using this structural model alone is not enough. A real-time behavior model is required to specify the real-time behavior of realtime components in the software. Therefore, enhancement to POAD is proposed here to enable explicit description for real-time behavior of a component.

Property

Port

Connector

Component PropertyBundle

QoS

name

subComponent

eventinfo

Event

Active

Passive

activeinfo

The Real-TimeBehavior element for class is added into POAD meta-model. The real-time behaviors are categorized in four: passive class, active class, event class, and implementation dependence class. Passive, active and event behaviors are adopted from PECOS model. A passive class is marked with a stereotype “ ” , an active class is marked with a stereotype “ ” and an event class is marked with a stereotype “ ”. An implementation dependence class is a class whose real-time behavior can only be specified or decided during the implementation phase of the pattern depending on the application. This class is not marked with any stereotype. As illustrated in Figure 4, for Subsumption Architecture component, the

Figure 9: Overview of PECOS Metamodel

3.1 Migrating from Pattern to Component Component integration in POAD methodology can only be performed after specification of patterns as design components by providing interfaces. By specifying a pattern as a component as proposed in POAD methodology, the mapping between element Pattern in Figure 8 and element Component in Figure 9 can be performed. However, direct migration between the two components definition is not possible because of a difference in definition between pattern component and PECOS component, and this need to be solved in the transformation process.

Selector Arbiter, Stop, Cruise, Find Wall, Follow Wall and Avoid classes are active classes while the Actuator Action is a passive class.

In POAD, pattern nesting is not allowed in because a pattern cannot be part of another pattern, while in PECOS a composite component that contains a number of subcomponents is allowed. To solve this difference, a solution is proposed by dividing the ERT development into three models as follows: (i) Pattern-oriented analysis model which capture the main requirements of the

Key elements of PECOS component model are illustrated in Figure 8. In PECOS a Component is a computational element with: (i) Three different types: Active components, passive components and event components. (ii) Port. A port represents data that may be shared with other components. The

22

The First Malaysian Software Engineering Conference (MySEC’05)

(ii)

(iii)

concrete problem by using reusable analysis pattern. Pattern component early design model which transforms pattern-oriented analysis model into component by providing interfaces and tracing the interfaces to the internal classes of the pattern. Component-based detail design model which is derived from internal classes within the integrated patterns from early design model. Also some components from early design model will have to be regrouped to create a new component.

schedulability timeliness and memory example of QoS types in ERT systems.

are

The enhancement allows the detail real-time behavior to be modeled directly in PECOS. This is accomplished through: (1) the RealTimeBehavior element introduces in POAD can be transformed directly to relevant component type in PECOS; and (2) QoS models represented by Constraint element in POAD can be translated and detailed into PropertyBundle element in PECOS.

4. Conclusion

At analysis and early design phases, composite components that allow hierarchical composition are not required in pattern component because patterns must encapsulate the details of their internal. Composite component concept at component-based detail design model is required to allow hierarchical composition to support the process of detailing and regrouping of component. Hence, by following these rules migration from patterns from POAD to PECOS’s components can be achieved.

The main objective of using pattern-oriented analysis and component-based design in our work is to support CBSE approach for ERT software development of AMR. Two main approaches used to achieve the objective are POAD methodology and PECOS component model. This paper showed the transformation of the two approaches by mapping the POAD metamodel to the PECOS meta-model. To enable a direct mapping between the two approaches an enhancement was introduced to POAD metamodel. This mapping will enable CASE tools to be developed based on the two approaches. The advantage of combining the two approaches is to enables high-level reuse software in ERT systems without sacrificing the non-functional requirements such as timeliness, predictability and constrained resources.

3.2 Mapping Component Interfaces Difference in OO design used in POAD and data-flow-oriented design used in PECOS is another issue need to be solved during transformation process of POAD model to PECOS model. This will affect the mapping process of the types of component interface. POAD methodology uses class and operation as interface in PatternInterface element, while Port is used as interface component in PECOS model.

5. References [1] Leveson, N. G. and Weiss K. A., “Making embedded software reuse practical and safe”, Proceedings of the 12th ACM SIGSOFT twelfth international symposium on Foundations of software engineering, Newport Beach, 2004, pp. 171 – 178. [2] Yacoub, S. M. and Ammar, H. H., Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems, Addison-Wesley, Boston, 2004. [3] Nierstrasz O., Arévalo G., Ducasse S., Wuyts R., Black A., Müller P., Zeidler C., Genssler T., van den Born R. “A Component Model for Field Devices”, Proceedings First International IFIP/ACM Working Conference on Component Deployment, SpringerVerlag Heidelberg Volume 2370, Berlin, 2002, pp. 200-209. [4] Jawawi, D. N. A., Mamat R. and Deris S.. “Analysis Patterns for Component-Based Development of Autonomous Mobile Robot Software”, The 2nd International Conference on Mechatronics 2005 (ICOM'05). Kuala Lumpur. 2005, pp. 185-192. [5] Brooks, R.A., A Robust Layered Control System for a Mobile Robot, IEEE Journal of Robotics and Automation, vol. RA-2(1), 1986, pp. 14-23. [6] Paradigm Systems, Paradigm C++ Reference Manual Version 5.0, Endwell, 2000. [7] Labrosse J. J., MicroC/OS-II The Real-Time Kernel, 2nd edition, R&D Books, USA, 1999.

The two approaches can be mapped by utilizing InterfaceBinder element offered in POAD. InterfaceBinder is the tracing mechanism that enables the pattern interfaces in terms of interfaces classes or interface operations to be traced to the internal classes of the pattern. This mechanism can be used to trace the data or attribute in the pattern component to be treated as Port in PECOS interface. Even though the type of interface changed in the mapping process, the architecture from analysis and design composition is still maintained in PECOS integration model. This can be observed in Figure 4 and Figure 5.

3.3 Detailing Real-Time Behavior The enhancement of POAD, as proposed early in this section, is important to enable it to explicitly describe real-time behavior of a class at high level. In the meta-model enhancement, the RealTimeBehavior is typically modeled in Constraint element and referred as quality of services (QoS) as illustrated in Figure 8. Performance,

23