Information Technology Reference
In-Depth Information
confidentiality reasons as explained before) as well as the rationale we used to explain
to Siemens' developers why we understood them as crosscutting concerns that could
influence their current architecture and implementation.
Regarding the mapping of early aspects we are not claiming that there is a direct
mapping from them to code. In [16, 17] is suggested that early aspects mappings can
be of various types such as utility functions, aspects and architectural decisions. In the
case of Table 7 we found that these early aspects represent concerns that are likely to
be implemented using aspects but it does not necessary mean a one-to-one mapping.
Our suggestion was corroborated by Siemens' developers that found these concepts
very relevant and recognized that they hadn't spotted them before.
While we conducted this case study we faced several challenges that we have not
found for example when we conducted the first case study in Sect. 5.1. Some of the
issues we found are as follows:
•
The structure of the requirements was somewhat different than previous
documents used. Each requirements document described specific features of
the system and generally the requirements were logically grouped into sets of
paragraphs or in a whole document section. We had to use our pre-
processing tool support (Sect. 4.1.1) in order to deal with larger parsing units
(e.g., paragraphs and sections) than sentences.
•
Also, another challenge was when different terms were used as the same
concepts in different requirements documents as we mentioned above for
back office and ETBO. It also happened in other documents with OBU and
(on-board equipment) OBE and we were also able to detect it while viewing
the requirements and editing the AORE model.
Another challenge was that since EA-Miner works with documents some
times the input files might be incomplete or badly specified. To resolve this
problem we sometimes had to communicate with the developers of the toll
system prototype to gain a better understanding of the requirements.
All the above challenges are issues that we need to further explore in order to
improve the tool by, for example, improving the pre-processing support in order to
automatically identify larger chunks of text such as paragraphs and sections.
Moreover, automation of “domain synonyms” identification such as ETBO and back
office as well as poorly written and ambiguous requirements can also provide a great
contribution for AORE.
In conclusion, we believe that this case study was an interesting exercise to study
the effectiveness of our approach. The use of real industrial requirements written by
different developers with various writing styles and vocabulary posed a real challenge
to our approach. The EA-Miner analysis was invaluable by finding relevant concerns,
such as the ones in Table 7 that were previously missed by Siemens' developers, but
recognised as relevant. Moreover, the list of concerns found in Table 6 made it
possible for us to verify with the developers that the end result of the EA-Miner-based
analysis was similar to what they already had in mind about the requirements of the
system (except for the missed ones).
The case study demonstrates that output from an EA-Miner-based analysis in an
industrial setting is not only at least as good as the manual analysis by developers who
•
Search WWH ::
Custom Search