Creative Construction Conference 2015
A Software Product Line Approach For The Development Of Construction Safety IT Solutions Annie Guerriero*, Alain Vagner Luxembourg Institute of Science and Technology (LIST, 5, avenue des Hauts-Fourneaux, L-4362 Esch/Alzette)
Abstract
The construction safety management deals with multiple contexts and takes place in a national and legal framework that imposes different kinds of documents (e.g. Site Specific Safety Plan, General Safety Plan) depending upon for example the number of workers on site, the area of the building site or the nature and the dangerousness of the construction tasks. When developing tools supporting this activity it seems difficult to consider all this variability of the context (i.e. associated to legal context and the nature of the activity, but also the environmental context, the user, the device) and to provide a large set of products finely adapted to the situation of building site. Based on this observation, we suggest applying a SPL (Software Product Line) approach combined with MDE (Model Driven Engineering) approach for the development of IT solutions. The combination of these two approaches allows us to propose a development method integrating variability models in order to manage the combination of situations and to generate a set of products adapted to specific contexts. The use of different kinds of model (i.e. domain model, context model, feature model, and interaction flow model) contributes to consider the multiple facets of variability representative of the construction safety management in order to develop specific business software services. The present article describes the MD-SPL methodology and the formalization of the variability of the contexts and features most notably for the design of user interfaces. Moreover it will present a case study in the construction safety domain inscribed in the Luxembourgish legal framework and the related variability models. Keywords: Software Product Line, Model Driven Engineering, Construction safety.
1. Introduction The construction sector is one of the most important activity sectors in Luxembourg. In 2012, it represented 10,8% of the total employment (Source: Eures). As the construction activity is comparable to the construction of a prototype on building site, the risk related to person’s security are numerous. The incidents associated to the risk of fall or to the manipulation of dangerous products are the most frequent. In Luxembourg the law (Grand-Ducal Regulation of 27 June 2008) describes the health safety requirements for construction sites in order to limit the accidents and protect workers. This legal framework allows us to identify the multiplicity of the contexts inside which the regulations have to be applied. The Grand-Ducal Regulation specifies
* Corresponding author. Tel.: +352 275 888 -1; Fax: +352 275 885. E-mail.
[email protected]
the required process of construction safety management according to the nature of the construction task to be performed. Certain elements such as the number of workers on site, the area to be built, the risky tasks (e.g. use of explosive, presence of asbestos, etc.) are predominant for determining the obligations related to construction safety management. Based on this observation, we consider that the software dedicated to security and health management on construction sites should reflect the variability of these contexts. We suggest applying a SPL (Software Product Line) approach combined with MDE (Model Driven Engineering) approach for the development of IT solutions. The combination of these two approaches allows us to propose a development method integrating variability models in order to manage the combination of situations and to generate a set of products adapted to specific contexts. The present article describes the MD-SPL methodology and the formalization of the variability of the contexts and features most notably for the design of user interfaces. Moreover it will present a case study in the construction safety domain inscribed in the Luxembourgish legal framework and the related variability models. 2. MD-SPL approach for the design of User Interfaces 2.1. Model-Driven Engineering of User Interfaces MDE is a “Software development methodology, which focuses on creating and exploiting [...] models, that are, abstract representations of the knowledge and activities that govern a particular application domain” †. Our approach relies on MDE for several reasons. In particular, several frameworks and languages have been proposed to structure the way User Interfaces (UI) are generated from models [1, 2]), where these are successively transformed through model transformations until the code of the UI is generated. This provides easier evolutions and reuse [3], dynamic adaptation of the UI to the context of use [4], end-user programming [5], greater quality [6], generation of supportive interfaces [7] among others. Model-driven UI design is a multi-stakeholders process where each model –representing a particular subdomain of UI engineering– is manipulated by specific stakeholders. For instance, the choice of graphical widgets to be used (e.g. radio button, drop-down list, etc.) is done by a graphical designer, sometimes in collaboration with the usability expert and/or the customer. Our model-driven UI design approach relies on a revised version of the CRF framework [8] (See Figure 1). It consists of two base metamodels, the Domain metamodel -representing the domain elements manipulated by the application as provided by classical domain analyst) and the interaction flow model (IFM) [9]. From these models we derive the Concrete User Interface model (CUI) which depicts the application ”pages” and their content (i.e., widgets) as well as the navigation between pages. The CUI metamodel aims at being independent of the final implementation of any graphical elements. Finally, the obtained CUI model is transformed into an Implementation Specific Model (ISM) that takes into account platform details (here platform refers to UI toolkit such as HTML/JQuery, Android GUI, etc.). A last model-to-text transformation generates the code according to the ISM.
Figure 1: Model-driven UI design process
We use this model-driven UI design process to generate the UI variants corresponding to each possible context configuration.
†
http://en.wikipedia.org/wiki/Model-driven engineering
2.2. Software Product Line Engineering To overcome variability issues in software engineering, researchers have proposed to rely on the paradigm of Software Product Lines (SPLs) [10]. The SPL paradigm allows managing variability by producing a family of related product configurations (leading to product variants) for a given domain. Indeed, the SPL paradigm proposes the identification of common and variable sets of features, to foster software reuse in the configuration of new products [11]. According to [12, 13] SPL and MDE are complimentary and can be combined in a unified process that aggregates the advantages of both methods. Moreover, in our previous work, we have shown that the management of UI variability based on MDE & SPL can be done using multiple feature models to express the different dimensions of the variability. Feature models [11] are popular SPL assets to describe both variability and commonalities of a system. They express through some defined operators the decomposition of a product. The selection of features among the feature model is called the configuration process. Bühne et al. [14] have demonstrated that depicting variability in a single feature model leads to feature redundancies due to the tree structure. As a result, separation of variability concerns into multiple feature models seems to be crucial for understanding [15] and manipulating the many different faces of variability. 2.3. Model-Driven Software Product Line engineering Model-driven software product line engineering merges two approaches [12]: - Software product line engineering focusing on the systematic development of products belonging to a common system family, where instances of product are developed based on library of components, - Model-driven software engineering putting strong emphasis on the development of high-level models rather than on the source code. Classical feature model approaches combine different functional features [16]. In the specific context of UI design, we propose to rely on a similar approach for managing variability of each UI design concern. UI variability is thus decomposed into feature models (FM) (Figure 2).
Figure 2: Feature models coverage on our UI modelling framework
Each of these feature models is related either to a model, a metamodel, a mapping or a transformation depending on the nature of the information it conveys: -
Models: Three FMs manage variations at the model level (IFM, Domain and CUI). For example on the domain model, the FM can express alternative descriptions of a same concept. Mappings: The variability of the mapping between IFM and Domain can be managed by a mapping FM. Indeed, UI states can involve different concepts in the domain model Transformations: Variability can be expressed in transformation FMs at the level of two transformations: (1) between IFM, Domain and CUI, (2) between CUI and ISM. For example, a widget described in CUI can be represented differently according to the context in ISM.
By scoping the FM to a specific concern, our approach allows to focus only on the variations related to the underlying concern. In our approach, we consider two feature models: (1) the functional feature model that expresses all possible features in the application and (2) the context feature model that describes all possible parameters related
to the activity, the physical environment, the user, the temporality and the device. These two feature models enable us to configure and filter the IFM and domain models before generating a variant through the MDE process. 3. MD-SPL approach applied to construction safety Different research works have addressed the construction safety topic based on online databases, geographic information system, virtual reality, 4D modeling, etc. [17-20]. Different types of applications exist for supporting the different facets of the construction safety mission (e.g. Winlassie‡, Maîtrisk§ or Safesite**) but it remains difficult to propose a solution really adapted to the variability of the situations of building site. The national legal context is important to qualify the construction site in terms of legal obligations related to security and health. In Luxembourg the law (Grand-Ducal Regulation of 27 June 2008) and documents established by the labour inspection describe the health safety requirements for construction sites. Different variables (such as number of persons present at the same time on the construction site, the area, the duration, dangerous tasks, etc.) are required for qualifying the construction site and determining the obligations of the owner (e.g. site safety manager required or not, specific certification needed (i.e. level A (for small and simple building site) to C (for high and complex building site)), required documents, etc.) as described in the Table 1. Table 1. Variability of the context of construction safety in Luxembourg Very small A
Very small B
Small A
Small B
Medium A
Medium B
Large
Number of firms on site
1
≥2
1
≥2
≥2
≥2
≥2
Architectural particularity
_
_
_
✓
✓
✓
✓
Area (m²)
< 25
< 25
< 250
< 250
> 250
> 250
> 250
Duration
< 15 calendar days
< 15 calendar days
< 30 working days
< 30 working days
< 30 working days
< 30 working days
> 30 working days
Labour (man-days)
_
_
< 500
< 500
< 500
500 < x < 10000
> 500
Dangerous works
✕
✕
✕
Limited risk
Particular risks
Limited risks
All types of risks
Prior notice
✕
✕
✕
✕
✕
✓
✓
SSSP (Site Specific Safety Plan)
✓
✓
✓
✓
✓
✓
✓
GSP (General Safety Plan)
= Only sum of SSSP
= Only sum of SSSP
✓
✓
✓
✓
✓
_
Level A
_
Level A
Level B
Level B
Level C
Variables
Required documents
Safety management Site safety management level required
Our objective is to include these elements of variability in the development of IT services supporting construction safety management and to develop specific solutions fitting the context (e.g. including GSP functionalities only if it is needed, or functionalities related to dangerous works only for concerned projects). The derivation of variants of the software based on the variability of the context and feature modelling is an interesting approach to develop more rapidly dedicated software and to guarantee the adequation to the specificity of the context. So our approach suggests
‡
http://www.winlassie.com http://maitrisk.lu ** https://itunes.apple.com/app/safesite-construction-safety/id892386806?mt=8 §
different kinds of models developed in 4 steps: M1. Domain model for the modeling of concepts that are present in the construction safety domain. M2. Context model for the modeling of all the variability elements of the context of construction safety (i.e. variability of the documents related to the legal context). M3. Feature model for the modeling of the variability of functionalities (i.e. edition, consultation, transfer, etc.). M4. Interaction flow model “designed for expressing the content, user interaction and control behaviour of the front-end of software applications”††. Based on all these models coupled with rules describing for example the legal context in Luxembourg for the construction safety management we can obtain the configuration and generation of multiple variants of the software products. Then the confrontation with experts contributes to select the more relevant solutions to be transferred on the market. The Figure 3 illustrates the different models in the construction safety case study and presents the 3 first types of models required in our method. The extracts of models focus on the GSP (General Safety Plan) consultation functionalities. The domain model describes the relevant concepts related to GSP and their relationships. The GSP is composed of different sections and includes annexes such as the SSSP (Site Specific Safety Plan). The security § health manager is responsible for the writing of this document. For very small building sites (i.e. number of persons of construction firm present at the same time on building site ≤ 2, area < 25 m2, duration < 15 calendar days, no dangerous works), there is no legal obligation for the owner to designate a security § health manager and the required content for GSP is the sum of the SSSP provided by the contractors. Based on this rule, the context model presents only the annex SSSP as mandatory. Then, the feature model suggests that the functionality “Consult SSSP” is the only one that is mandatory. The generated interface for GSP in the case of a very small building site only presents the section SSSP and for the larger ones, it displays all the different sections.
Building site -Duration -Size -Dangerous tasks -Workers number -Labour volume
Architect
As-Built
Manages
is responsible for
Security & Health manager -Level of authorization
transmits
Only access to SSSP
GSP
Is responsible for
Contractor
Is responsible for
is responsible for
Sections
General information Prior notice
Annex
Contractor's obligations § responsabilities
Certificate of GSP approval
receives
Labour inspection
Security & Health journal
is responsible for
designates
Owner
DOMAIN MODEL
is responsible for
Building site preparation ...
SSSP
Access to all sections of GSP
Fire permit
Site Installation plan
Demand of building site access
Identification of dangerous works
CONTEXT MODEL GSP
General information
Contractor's obligations & responsabilities
Powered By Visual Paradigm Community Edition
Building site preparation
Identification of dangerous works
…
Site installation plan
For very small building site
GSP
Number of persons of construction firm present at the same time on building site ≤ 2 Area < 25 m2 Duration < 15 calendar days No dangerous works
functionalities
GSP = sum of SSSP
††
Consult General information
Fire permit
Annex
Certificate of SSSP approval
Demand of building site access
SSSP
FEATURE MODEL
For larger building sites Complete GSP needed
Edit GSP
Consult GSP
Consult Contractor's obligations responsabilities
Transfer GSP
Edit GSP
Consult building site preparation
Consult …
Consult annex
http://www.ifml.org
Legend Consult site installation plan
Figure 3. MD-SPL for construction safety software
Consult fire permit
Consult certificate of SSSP approval
Consult demand of building site access
Consult SSSP
Mandatory Optional
4. Conclusion and prospects In conclusion, this article has described an MD-SPL methodology and the formalization of the variability of the contexts and features for the designing of software products. We can at this stage of this research works highlight the interest of MD-SPL approach for the rapid development of software products dedicated to the variability of contexts of the construction safety management. In this case study, we have demonstrated the interest for considering an MD-SPL approach for taking into account the variability of the legal context, but our approach is larger and can integrate the variability of the environmental context, the user, the device. At this time, we have developed a prototyping tool based on the variability expression of the multiple facets of an information system. As far as variability is concerned, these different facets can lead to an important number of possible variants. We proposed in this article to manage this issue by implementing business rules to limit the number of possible variants and implement a selection of the most interesting variants thanks to business experts. Another option will be to directly configure the solution with a business expert to the needs of the customer. Concerning the technological prospects, we are currently exploring the use of genetic algorithms to optimize user tests in order to limit the number of variants to be tested, based on user satisfaction and the combination of relevant solutions. We can consider now that the innovation process based on the MD-SPL approach will be technologically robust at short term. The real confrontation to business configuration in construction safety management based on the analysis presented in this article will contribute to validate and refine the approach. Acknowledgements This work has been supported by the Luxembourgish FNR MoDEL project (C12/IS/3977071). References [1] Botterweck, G., Multi front-end engineering. Model-Driven Development of Advanced User Interfaces, 2011, 340. [2] Limbourg, Q., et al., Usixml: A language supporting multi-path development of user interfaces. EHCI/DS-VIS, 2004, pp. 200-220. [3] Hamid, B., et al., Designing fault-tolerant component based applications with a model driven approach. Software Technologies for Embedded and Ubiquitous Systems, 2008, 5287. [4] Blumendorf, M., S. Feuerstack, and S. Albayrak, Multimodal user interaction in smart environments: Delivering distributed user interfaces. Constructing Ambient Intelligence, Communications in Computer and Information Science, 2008, 11. [5] Dittmar, A., A. García Frey, and S. Dupuy-Chessa. What can model-based ui design offer to end-user software engineering? in 4th ACM SIGCHI Symposium on Engineering Interactive Computing Systems, EICS’12. 2012, New York. [6] Ammar, L.B., A. Trabelsi, and A. Mahfoudhi, Incorporating usability requirements into model transformation technologies. Requirements Engineering, 2014, pp. 1–15. [7] García Frey, A., et al., Model based self-explanatory UIs for free, but are they valuable? INTERACT, Lecture Notes in Computer Science, 2013. [8] Calvary, G., et al., A unifying reference framework for multi-target user interfaces. Interacting with Computers, 2003, 15(3): p. 289-308. [9] OMG, IFML- interaction flow modeling language, 2013. [10] Clements, P. and L. Northrop, Software product lines, Addison-Wesley Boston, 2002. [11] Pohl, K., G. Bockle, and F. Van Der Linden, Software product line engineering: foundations, principles, and techniques, 2005. [12] Batory, D., M. Azanza, and J. Saraiva, The objects and arrows of computational design. Model Driven Engineering Languages and Systems, 2008. [13] Czarnecki, K., et al., Model-driven software product lines, in Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, 2005. [14] Bühne, S., K. Lauenroth, and K. Pohl, Why is it not sufficient to model requirements variability with feature models, in Workshop on Automotive Requirements Engineering (AURE’04), at RE’04, Japan, 2004. [15] Mannion, M., J. Savolainen, and T. Asikainen, Viewpoint-oriented variability modeling, in COMPSAC’09, Seattle,Washington, 2009. [16] Pleuss, A., et al., User interface engineering for software product lines: the dilemma between automation and usability, EICS, 2012, pp. 2534. [17] Akeem, P. and P. Chan Sik, A construction safety education system based on interactive virtual reality, in CIB W099 Achieving Sustainable Construction Health and Safety, Lund, Sweden, 2014. [18] Godfaurd, A.J. and G. Abdulkadir, Integrating BIM and Health and Safety for onsite Construction. Safety and Health at Work, 2014: p. 1-17. [19] Ding, L. and C. Zhou, Development of web-based system for safety risk early warning in urban metro construction. Automation in Construction, 2013, 34, pp. 45-55. [20] Zhou, W., et al. (2012). "Construction safety and digital design: A review." Automation in Construction, 2012, 22: 102-111.
