A consensus protocol for the recovery of mercury methylation genes from metagenomes

Mercury (Hg) methylation genes (hgcAB) mediate the formation of the toxic methylmercury and have been identified from diverse environments, including freshwater and marine ecosystems, Arctic permafrost, forest and paddy soils, coal-ash amended sediments, chlor-alkali plants discharges and geothermal springs. Here we present the first attempt at a standardized protocol for the detection, identification and quantification of hgc genes from metagenomes. Our Hg-cycling microorganisms in aquatic and terrestrial ecosystems (Hg-MATE) database, a catalogue of hgc genes, provides the most accurate information to date on the taxonomic identity and functional/metabolic attributes of microorganisms responsible for Hg methylation in the environment. Furthermore, we introduce "marky-coco", a ready-to-use bioinformatic pipeline based on de novo single-metagenome assembly, for easy and accurate characterization of hgc genes from environmental samples. We compared the recovery of hgc genes from environmental metagenomes using the marky-coco pipeline with an approach based on coassembly of multiple metagenomes. Our data show similar efficiency in both approaches for most environments except those with high diversity (i.e., paddy soils) for which a coassembly approach was preferred. Finally, we discuss the definition of true hgc genes and methods to normalize hgc gene counts from metagenomes

Formalizing patterns with the user requirements notation

Patterns need to be described and formalized in ways that enable the reader to determine whether the particular solution presented is useful and applicable to his or her problem in a given context. However, many pattern descriptions tend to focus on the solution to a problem, and not so much on how the various (and often

Tool support for combined rule-based and goal-based reasoning in Context-Aware systems

Context-aware systems often use rule-based reasoning engines for decision making without involving explicit interaction with the user. While rule-based systems excel in filtering out unsuitable s

Visualizing aspect-oriented requirements scenarios with use case maps

The benefits of aspects and aspect-oriented modelling are beginning to be recognized for requirements engineering activities. However, once aspects have been identified, the behaviour, structure, and pointcut expressions of aspects need to be modeled unobtrusively at the requirements level, allowing the engineer to seamlessly focus either on the behaviour and structure of the system without aspects or on the combined behaviour and structure. Furthermore, the modeling techniques for aspects should be the same as for the base system, ensuring that the engineer continues to work with familiar models. This position paper describes how, with the help of Use Case Maps, scenario-based aspects can be modeled visually and unobtrusively at the requirements level and with the same techniques as for non-aspectual systems. With Use Case Maps, aspects including pointcut expressions are modeled in a visual way which is generally considered the preferred choice for models of a high level of abstraction

Generation of test purposes from Use Case Maps

The Use Case Map (UCM) scenario notation can be used to model service requirements and high-level designs for reactive and distributed systems. It is therefore a natural candidate for use in the process of generating requirements-directed test suites. We survey several approaches for deriving test purposes from UCM models. We distinguish three main approaches. The first approach is based on testing patterns, the second one on UCM scenario definitions, and the third one on transformations to formal specifications (such as Lotos). Several techniques will be briefly illustrated and compared in terms of quality of the test purposes obtained, ease of use, and tool support. We also identify challenges in refining these test purposes into test cases as well as opportunities for improving current UCM-based testing

Visualizing early aspects with use case maps

Once aspects have been identified during requirements engineering activities, the behavior, structure, and pointcut expressions of aspects need to be modeled unobtrusively at the requirements level, allowing the engineer to seamlessly focus either on the behavior and structure of the system without aspects or the combined behavior and structure. Furthermore, the modeling techniques for aspects should be the same as for the base system, ensuring that the engineer continues to work with familiar models. This paper describes how, with the help of Use Case Maps (UCMs), scenario-based aspects can be modeled at the requirements level unobtrusively and with the same techniques as for non-aspectual systems. Use Case Maps are a visual scenario notation under standardization by the International Telecommunication Union. With Use Case Maps, aspects as well as pointcut expressions are modeled in a visual way which is generally considered the preferred choice for models of a high level of abstraction

Flexible and expressive composition rules with Aspect-oriented Use Case Maps (AoUCM)

Technologies based on aspect-orientation and multi-dimensional separation of concerns have given software engineers tools to better encapsulate concerns throughout the software lifecycle. Separated concerns must be composed, even during early lifecycle phases, to obtain an overall system understanding. Concern composition languages therefore must be expressive, scalable, and intuitive. Otherwise, gains achieved by concern separation are offset by the complexity of the composition rules. This paper focuses on a composition language for the requirements modeling phase and, in particular, on composition of concerns described with use cases or scenarios. We propose that existing composition techniques (such as before and after advices from AOP) are insufficient for requirements model composition because they do not support all composition rules frequently required for use cases or scenarios. Furthermore, composition rules for a modeling language should be visual and use the same notation as the modeling language. This paper presents Aspect-oriented Use Case Maps (AoUCM) and evaluates it

Goal models as run-time entities in context-aware systems

The strength of goal models is their ability to assess candidate solutions against high level criteria for many stakeholders, allowing system-wide trade-offs to be performed. We argue that, in a context-aware system, reasoning based on goal models can complement standard rule-based reasoning engines for decision making without involving explicit interaction with the user. While rule-based systems excel in filtering out unsuitable solutions based on clear criteria, it is difficult to rank suitable solutions based on vague, qualitative criteria of stakeholders with a rule-based approach. The User Requirements Notation (URN) is a goal-based and scenario-based requirements modeling language that has been applied to many different domains, from reactive systems to telecommunication standards to business processes. For context-aware systems, URN's workflow notation can describe the overall behavior of a context-aware system and URN's goal models can further enhance reasoning about contextual situations. While URN already supports some of the interactions between workflow and goal models required for the specification of context-aware systems, it does not yet fully support the modeling, design-time simulation, and run-time execution of a context-aware system based on its URN model. This paper (i) introduces such a modeling, simulation, and execution environment, (ii) discusses three architectural solutions for combined rule-based and goal-oriented reasoning, and (iii) reports on a URN profile that describes a domain-specific language for context-aware reasoning using goal-orientation with the help of an example application from the health care domain

Requirements for a modeling language to specify and match business process improvement patterns

Businesses are always looking for opportunities to improve their processes in order to become more efficient and effective. Patterns for business process improvement have been defined and used as best practices to help analysts discover such opportunities. A modeling language allowing analysts to define or use a predefined library of improvement patterns to detect improvement opportunities in business processes can be of a significant value. Based on a comprehensive set of improvement patterns from the literature, this paper defines the requirements for a modeling language to support a framework capable of defining and detecting such patterns. We use an example from the retail industry to motivate the collected requirements. The paper's contributions allow us to capture more sophisticated business process improvement patterns, bringing us one step closer to a comprehensive model-driven, aspect-oriented business process modeling language. Furthermore, the collected requirements for the desired modeling language clearly indicate that currently popular business process modeling languages are not yet capable of capturing all the required det

Visualizing aspect-oriented goal models with AoGRL

As goal models can be large and complex even for small problems, it is often a challenge to aptly visualize them and to efficiently structure them for maintenance and reuse activities. The Goal-oriented Requirement Language (GRL) based on i* and the Non-Functional Requirements (NFR) Framework is no exception regarding these challenges. We argue that new ways of visualizing GRL goal models are needed and propose to use Aspect-oriented GRL (AoGRL) to improve the current structure of GRL models and their visualization. The paper presents a case study to evaluate the modularity, understandability, reusability, maintainability, and scalability of AoGRL models compared to GRL models. The evaluation is carried out based on metrics adapted from literature. The evaluation suggests that AoGRL models are more scalable than GRL models and exhibit better modularity, understandability, reusability, and maintainabilit