Using Smalltalk as a Reflective Executable Meta-Language

Object-oriented meta-languages such as MOF or EMOF are often used to specify domain specific languages. However, these meta-languages lack the ability to describe behavior or operational semantics. Several approaches used a subset of Java mixed with OCL as executable meta-languages. In this paper, we report our experience of using Smalltalk as an executable and integrated meta-language. We validated this approach in incrementally building over the last decade, Moose, a meta-described reengineering environment. The reflective capabilities of Smalltalk support a uniform way of letting the base developer focus on his tasks while at the same time allowing him to meta-describe his domain model. The advantage of our this approach is that the developer uses the same tools and environment

Meta-Environment and Executable Meta-Language using Smalltalk: an Experience Report

Object-oriented modelling languages such as EMOF are often used to specify domain specific meta-models. However, these modelling languages lack the ability to describe behavior or operational semantics. Several approaches have used a subset of Java mixed with OCL as executable meta-languages. In this experience report we show how we use Smalltalk as an executable meta-language in the context of the Moose reengineering environment. We present how we implemented EMOF and its behavioral aspects. Over the last decade we validated this approach through incrementally building a meta-described reengineering environment. Such an approach bridges the gap between a code-oriented view and a meta-model driven one. It avoids the creation of yet another language and reuses the infrastructure and run-time of the underlying implementation language. It offers an uniform way of letting developers focus on their tasks while at the same time allowing them to meta-describe their domain model. The advantage of our approach is that developers use the same tools and environment they use for their regular tasks. Still the approach is not Smalltalk specific but can be applied to language offering an introspective API such as Ruby, Python, CLOS, Java and C#.

Total-body digital X-ray in trauma. An experience report on the first operational full body scanner in Europe and its possible role in ATLS

When patients enter our emergency room with suspected multiple injuries, Statscan provides a full body anterior and lateral image for initial diagnosis, and then zooms in on specific smaller areas for a more detailed evaluation. In order to examine the possible role of Statscan in the management of multiply injured patients we implemented a modified ATLS((R)) algorithm, where X-ray of C-spine, chest and pelvis have been replaced by single-total a.p./lat. body radiograph. Between 15 October 2006 and 1 February 2007 143 trauma patients (mean ISS 15+/-14 (3-75)) were included. We compared the time in resuscitation room to 650 patients (mean ISS 14+/-14 (3-75)) which were treated between 1 January 2002 and 1 January 2004 according to conventional ATLS protocol. The total-body scanning time was 3.5 min (3-6 min) compared to 25.7 (8-48 min) for conventional X-rays, The total ER time was unchanged 28.7 min (13-58 min) compared to 29.1 min (15-65 min) using conventional plain radiography. In 116/143 patients additional CT scans were necessary. In 98/116 full body trauma CT scans were performed. In 18/116 patients selective CT scans were ordered based on Statscan findings. In 43/143 additional conventional X-rays had to be performed, mainly due to inadequate a.p. views of fractured bones. All radiographs were transmitted over the hospital network (Picture Archiving and Communication System, PACS) for immediate simultaneous viewing at different places. The rapid availability of images for interpretation because of their digital nature and the reduced need for repeat exposures because of faulty radiography are also felt to be strengths.