Concern coverage in base station development: an empirical investigation

Abstract

Contemporary model driven development tools only partially support the abstractions occurring in complex embedded systems development. This article presents an interpretive case study in which architectural concerns important to seven engineers in a large product developing organization were compared to the views actually provided by the organization's models. The paper's main finding is an empirically grounded catalogue of architectural concerns for a large, complex embedded systems project, and an assessment of the degree to which the studied organization has managed to realize support for these concerns within economical and organizational constraints. In the studied case, 114 different architectural concerns were found to be important to the interviewed engineers. Of this sample, 75% were documented in models, structured text, or informal documentation, whereas 47% of all documented concerns were modeled. The paper's conclusion is that current modeling languages and methods inadequately address the full set of concerns that are important to engineers in base station development.

Comparing and contrasting model-driven engineering at three large companies

“…They also report on the lack of organizational maturity in terms of which processes to use in combination with MDE, the difficulties in adapting existing skills to the new challenges of MDE and the unwillingness of the organization to change in order to make the most out of the transition into MDE. A previous study conducted at Radio can be found in [13]. Here the emphasis is on MDE in relation to architectural concerns (deployment, algorithms, performance etc.)…”

A Systematic Mapping of Architectures for Embedded Software

“…Pareto et al [19] presents a catalogue of concerns related to embedded systems architecture that contains 114 variations of architecture. These variations were identified through an experimental study with seven systems engineers and the architecture variations were catalogued like models and/or text documents.…”

Ontology‐based model‐driven development of a destination management portal: Experience and lessons learned

“…Indeed, some practitioners did see productivity gains for product lines/families , where the generative tools and the bulk of the source models are reused across many applications . However, others have pointed out that the cost of modeling can outweight the benefits to be gained (eg, see the work of Pareto et al). The generated code tends to lack elegance and efficiency because it is not/cannot be “locally optimized.” In some cases, this had led practitioners to manually edit the generated code for performance‐criticial functions (see for example the works of Mohagheghi et al and Hutchinson et al).…”

“…Indeed, some practitioners did see productivity gains for product lines/families, where the generative tools and the bulk of the source models are reused across many applications. [6][7][8] However, others have pointed out that the cost of modeling can outweight the benefits to be gained (eg, see the work of Pareto et al 23 ).…”