dataesr/scientific-paragraphs-categorization huggingface dataset:
In silico design and simulation Computer-automated implementation of biochemical logic circuits was performed using the Silicell Maker software suite with NetBuild and NetGate programs (https://silicellmaker. lri. fr/, Patrick Amar), and stochastic simulations (SSA) were performed using HSIM (https://www. lri. fr/~pa/Hsim/, Patrick Amar). Recent improvements that we brought to HSIM for the purpose of this study consist of multisubstrate enzymatic mechanisms implementation (ordered sequential bi-bi mechanism, Ping Pong bi-bi mechanism, and random sequential bi-bi mechanism), automated translation of probability from HSIM stochastic simulator to mass action rates for BIOCHAM ODE solver, the implementation of physical models for protosensor membrane permeability, as well as SBML support (more information on these improvements can be found in Appendix).
Simulations were run for 60 min, with protosensors diameters of 10 lm, and computed output values were calculated using calibration curves giving relation between concentration and fluorescence or absorbance values. Permeability coefficient and other kinetic parameters were obtained from previous literature and the BRENDA database. Sensitivity analysis and parameter search were performed using BIOCHAM (https://lifeware. inria. fr/biocham/ ). Step-by-step detailed information, computer code, and BIOCHAM executable notebooks showing the process of biochemically programming a protosensor can be found in Appendix and can be executed on the online server (http://lifeware. inria. fr/biocham/on line/). SBML models (Code EV1-EV4), and corresponding Biocham code (Code EV5-EV7) of the synthetic circuits described in this can be found in SI.
Protosensors microfluidic generation PDMS microfluidic chips were designed and prototyped using AutoCAD software, and fabrication was carried out by the Stanford University microfluidic foundry. The microfluidic chips were connected with PTFE tubing to neMESYS V2 syringe pumps (Cetoni GmbH, Germany). Microfluidic processes were imaged using a Leica DMIL microscope mounted with a Canon 750D or a Phantom V7. 3 camera. Detailed information can be found in Appendix.
Spectrometric assays, flow cytometry, and microscopy To test the operability of the systems, synthetic biochemical networks and protosensors were inoculated in 100 ll total volume of PBS with or without input biomarkers, or urine from patients diluted at a ratio of 1:2 in PBS for a total volume of 100 ll in a 96well plate. Kinetic measurements or endpoint measurements after 1 h of incubation were performed at 25C with gentle 200 cpm double orbital shaking; fluorescence and absorbance were read using a synergy H1 plate reader (more details can be found in the Appendix). We concomitantly tested these urines from non-stabilized diabetic patients using the Siemens Multistix 8 SG reagent strip according to the manufacturer's protocol. Flow cytometry experiments were performed on a Guava EasyCyte benchtop flow cytometer (Merck) equipped with a 488-nm laser and analyzed using FlowJo vX software.
Acknowledgements This work was supported by the  Centre National pour la Recherche Scientifique (CNRS) , the  University Hospital of Montpellier  ( Centre Hospitalier Regional Universitaire, CHRU ), and by the  French National Research Agency (ANR Biopsy). A. C. was a recipient of a fellowship from the  French Ministry of Health  and a Resident at the  University Hospital of Montpellier  and is now supported by the  Innovation Fellowship  from the  Washington Research Foundation  and the  Human Frontier Science Program. We thank  Jerome Bonnet  and  Drew Endy  for fruitful collaboration, insightful perspectives, and invaluable discussions. We thank  Kathy Wei ,  Marc Lajoie ,  Anindya Roy ,  Scott Boyken , and  Daniel Adriano Silva Manzano  for helpful feedback during the preparation and revision of the manuscript.
Data analysis and statistics Experimental values are reported as means AE SD. For all bar plots, reported P-values were computed used a two-sided unpaired t-test. All experiments were performed in triplicates. Data, statistics, graphs, and tables were processed and generated using MATLAB (MathWorks) and SigmaPlot (Systat Software Inc. ). Flow cytometry data collection was carried on 10,000 individual events. For receiver operating characteristic analysis, a set of 72 measurements performed in non-pathological urine were compared to 72 measurements performed in urine containing 1% glucose. Expanded View for this article is available online.
a b s t r a c t Systems which manipulate important volumes of data need to be managed with Real-Time (RT) databases. These systems are subject to several temporal constraints related to data and to transactions. Thus, their design remains a complex task. To remedy this complexity, it is necessary to integrate design methods to support data and transactions temporal constraints. Among the design methods, those based on patterns have been widely used in several fields. However, despite their advantages, these patterns present some shortcomings. Indeed, they do not manage efficiently the patterns variability and they do not specify the pattern elements when they are instantiated. To overcome these limitations, we propose, in this paper, a new UML profile to (i) express the variability in patterns and (ii) to identify the pattern elements in its instance.
Introduction Recently, many Real-Time (RT) systems (e. g. driver assistance systems and control traffic systems) need to store large amounts of data and to process them in order to operate efficiently. Therefore, an RT database should be used. This database must have not only have the same features of conventional databases (e. g. , efficient management of accesses to structured data), but requires also efficient management of data and transactions timing constraints  (Ramamritham, 1993). The design methods already proposed for traditional databases cannot be directly applied to model RT database applications since there is no mechanism to deal with the representation of time constraints. Besides, RT database applications become more complex, leading to an extensive conceptual description and to a prohibitive complexity from the practical point of view.
Therefore, the design of these applications is a hard process which requires the development of new design methods to support both data structures and the dynamic behavior of RT applications, based on RT databases. In order to successfully design such applications, we believe that a powerful design method (e. g. design patterns  (Gamma et al. , 1995) ) may improve the quality of development process. The design patterns are reusable abstract design elements that can reduce the difficulty of systems modeling. These patterns present mechanisms which successfully capture and promote best practices in the software design. However, despite the benefits of design patterns, the designer may spend a lot of time to understand and to instantiate them. Thus, many researchers proposed several notations in order to facilitate the specification of the patterns and the documentation of their instances.
These notations facilitate the understanding of complex concepts. There exist in the litterature different notations for documenting the patterns. For instance, we can mention the natural languages, which are imprecise and too ambigus, and the visual languages (e. g. the Unified Modeling Language (UML)). UML language is a standard object-oriented modeling language for general-purpose software. It is a commonly used language for visualizing, specifying and cumenting artifacts of systems by providing a precise semantics of its concepts  (Rumbaugh et al. , 1999). It provides a set of graphical notations to capture different aspects of the developed system. Among the benefits, these notations (such as diagrams and icons) bring are (i) enhancing the communication between designers (facilitating communication between all participants in the development process), (ii) making easier the understanding of concepts and models.
Moreover, the notations are not expressive enough to model specific domains. Indeed, in a particular domain design, UML should take into account the domain specificities. For instance, if we consider RT databases applications, we find that these applications are complex and they have several details that should be considered by the UML notations. They must specify RT database features, such as the time-constrained data and transactions. To overcome the shortcomings of the graphical notations, UML defines a new package, named Profile, to extend its syntax and its semantics. This profile provides three extension mechanisms with specific names in order to annotate UML diagrams with quantitative information: (stereotype-name): a stereotype which allows the definition of extensions to the UML vocabulary.
It is possible to associate a tagged value and constraints to a stereotype. A tagged value: which is an attribute associated to a modeling element in order to extend its properties with a certain kind of details. A constraint: which is a semantic restriction added to a model element. Usually, constraints are written in OCL  (OMG, 2003). The definition of a profile is very important as it allows adding semantics as well as constraints to UML concepts (e. g. , classes, attributes and lifelines). Besides, it provides new vocabulary for a particular domain by giving specific notations related to it. Thus, we define, in this paper, a new profile, which represents a specialized variant of the UML 2. 1. 2. This profile provides UML extensions to support RT database requirements. In addition, it aims at extending UML with concepts in accordance with design patterns representation.
The development of this profile has three motivations: 1. It represents the RT database applications concepts. A RT database has two main features: the notions of (i) data temporal consistency and (ii) the transactions RT constraints  (Ramamritham and Pu, 1995). Some of its data must not only be logically consistent, but also temporally consistent, i. e. a data must be used during its validity interval and two correlated data must be used within their relative validity interval (a certain temporal window). RT data are classified into: (i) sensor data collected from sensors, and (ii) derived data calculated using the sensor data  (Amirijoo et al. , 2006). RT data are updated through update transactions which can be executed either periodically (to update sensor data) or sporadically (to update derived data).
Therefore, we can deduce that RT databases have their own specificities. Thus, their design need to have appropriate concepts in order to consider factors, such as sensor data, derived data, the quality of data management, tem-poral semantics of transactions and concurrency control mechanisms in order to meet the timing constraints of RT applications  (Idoudi et al. , 2008). For this reason, in our work, we define UML extensions to take into account all these concepts. 2. It represents the patterns at the specification level. At this level, our profile is beneficial, as: (i) it offers flexible patterns that allow distinguishing between the fundamental elements and the variable elements, and (ii) it facilitates the comprehension of patterns instantiation. It expresses the patterns at the instantiation level.
This means that it is difficult (i) to trace these pattern elements, and (ii) to differentiate between the pattern elements and the added elements. Park et al. developed a PICUP (Pattern Instance Changes with UML Profiles) design method with the DPUPs (Design pattern in UML profiles)  (Park et al. , 2013). This design method helped preserving the quality of UML pattern-based design during perfective and corrective design maintenance for software systems by reducing the number of design pattern defects. The authors specified the design pattern using the UML profile extended from UML metamodel (M2). This profile was used to verify the conformance of design patterns instances to design patterns. Conformance checking can be achieved with UML class diagrams and OCL constraints. The authors distinguished between a stereotype and a stereotype instance.
Hence, the UML profile can express adequately the traceability and the composition criteria. To conclude, none of the above-studied profiles satisfies all the criteria of the patterns specification and instantiation. We note that the UML profiles satisfying both patterns specification and instantiation criteria have some limitations. For instance, the UML-RTDP profile has limitations in expressing the variability in the patterns. Furthermore, the above-studied profiles do not deal with the RT design patterns since they do not provide extensions to represent RT features. The UML-RTDP profile is the only one that provides extensions to fulfill the RT domain requirements. But, these extensions are not very expressive since they do not express clearly the RT databases requirements (e. g. , the two kinds of RT attributes: sensor attributes and derived attributes).
RT UML profiles Several researches defining UML extensions for RT applications have been proposed. For instance, we can mention TURTLE (Timed UML and RT-LOTOS Environment) profile  (Apvrille et al. , 2004)  and RT-UML profile  (Douglass, 2004). The basic concepts of RT-UML were integrated in the UML standard through the UML profile for Schedulability, Performance and Time (denoted SPT profile)  (OMG et al. , 2005). The SPT profile which is extended from UML 1. 4 does not specify a full methodology. It has some limitations related to expressive power and flexibility. For this reason, this profile is replaced by the MARTE profile which is an UML OMG standard for the Modeling and Analysis of RT Embedded systems  (OMG, 2011). This profile extends UML 2. 0 to support the aspects of time, hardware and software resources and Non-Functional Properties (NFP).
However, the notions of RT data and RT transactions which are the basic features of RT databases do not taken into account in MARTE. Thus, Idoudi et al. introduced the UML-RTDB (UML-Real-Time DataBase) profile to take into account the RT database requirements only in the structural model (class diagram)  (Idoudi et al. , 2008). This profile specifies RT classes and two kinds of RT attributes: sensor and derived attributes in order to satisfy the requirements of current RT applications. Moreover, this profile represents explicitly the type of RT operations through the stereotypes (periodic), (sporadic) and (aperiodic). Nevertheless, the UML-RTDB does not mention how to specify some properties of RT databases, especially non-functional properties despite their importance in enhancing the software development quality.
The UML/MARTE profile was introduced to express RT databases features in a structural model  (Louati et al. , 2012). In  Louati et al. (2012) , some concepts were inspired by the UML-RTDB and the MARTE profiles. The UML/MARTE profile supports all RT databases features, i. e. time-constrained data, timeconstrained transactions, concurrency, schedulability, nonfunctional properties, etc. However, it does not supply extensions for the behavioral view. Moreover, it does not mention how to specify the values of certain constraints (e. g. , the triggered time of a sporadic transaction). From the previous UML RT profiles description, we conclude that a new profile should be introduced to represent the RT databases features and the non-functional properties in both structural and behavioral models.
Nevertheless, the only UML extensions, defined for representing RT databases characteristics, remains insufficient to specify design patterns. Indeed, they must be generic designs intended to be instantiated in order to model any system that needs RT database environment. For this reason, additionally to the UML notations, expressing RT databases features, we need notations distinguishing the commonalities and differences between systems in the pattern domain. We need also extensions for the explicit representation of the pattern elements roles in a design model instantiating the pattern.
DP-RTDB profile In this section, we propose DP-RTDB (Design Pattern-Real Time DataBase), a UML profile for patterns. It represents an extension of UML 2. 1. 2. Our profile takes into account not only the RT databases aspects, but also the variability and the aspects relative to the patterns. Indeed, the DP-RTDB profile provides extensions that allow (i) expressing the variability in a pattern, (ii) specifying the roles played by each pattern element in its instance and (iii) representing RT databases requirements as well as the non-functional properties. To define our profile, we imported some extensions from the existing profiles. We proposed also new extensions. Each stereotype and its tagged values are presented on the UML diagrams using notes.
UML extensions for modeling RT database features This sub-section summarizes the UML extensions supporting the modeling of RT database features. Some stereotypes were inspired by the UML-RTDB profile  (Idoudi et al. , 2008)  used in the UML class diagram. We applied these stereotypes also on the UML sequence diagram. Moreover, the stereotype (nfp) was imported from the MARTE profile  (OMG, 2011). Besides, we defined a new stereotype that represents explicitly the database system storing RT data and managing RT operations. We describe below the purpose of using each stereotype: (sensor) stereotype. We used this stereotype to extend Class and Lifeline meta-classes. It indicates that the measurement is a sensor data (data issued from sensors). This stereotype has the same meaning of the (sensor) stereotype defined in  Idoudi et al.
(2008) , which extends only theProperty meta-class. (derived) stereotype. We used this stereotype to extend the Class and Lifeline meta-classes. It indicates that the measurement is a derived data i. e. , data is calculated using sensor data. This stereotype has the same signification of the (derived) stereotype defined in  Idoudi et al. (2008) , which extends only the Property meta-class. We used these two stereotypes to extend the Class and the Lifeline meta-classes since the sensor data and the derived data represent objects characterized by the attributes: value, unit, timestamp and validity duration. We did not consider the tagged values associated to the (sensor) and (derived) stereotypes introduced in Idoudi et al. (  2008 ) since these attributes are represented as fields associated to each RT data stored in the database.
(rtDatabase) stereotype. A RT database is, by definition, a database system having several components, such as transactions, concurrency control and storage management  (Stankovic et al. , 1999). Thus, the design of a RT database is to consider these components. So, we define the (rtDatabase) stereotype which extends the meta-class Class and the metaclass Lifeline. This stereotype specifies the database system storing RT data (sensor and derived data) and managing RT operations (e. g. , concurrency control and updating the data). (periodic) and (sporadic) stereotypes. We used them to extend Operation and Message meta-classes. The (periodic) stereotype indicates that a transaction is executed periodically. The (sporadic) stereotype shows that a transaction is executed sporadically (the method is executed in the demand).
It has also to indicate the fundamental participants through the (mandatory) stereotype. Expressing explicitly the variable elements and the fundamental elements helps the designer choosing the adapted variation in a pattern instantiation. Moreover, this profile defines a set of well-formed rules written in OCL language in order to verify the patterns consistency and correctness. These rules allow constraining dependencies between pattern variable elements in three views (class diagram, use case diagram and sequence diagram). They allow validating the consistency and the correctness of each diagram (see Section 6). At the instantiation level, our DP-RTDB profile allows easily identifying design patterns when they are instantiated by using extensions (e. g. , (PatternClass) and (PatternLifeline)) for explicit representation of patterns participants in software designs.
Questionnaire The case study researcher asks each designer about his/her background related to their experience in information system, especially in design patterns. In Table  4 , there are two different types of questions given in this case study questionnaire: (1) yesor-no questions, and (2) short-descriptive-answer questions. The results of questionnaire are collected from a group of ten professors on software engineering. These participants had substantial software development experience ranging from 8 to 12 years. In fact, from the answers of question 1 (Q1), the designers agreed that the applications models resulting from the pattern instantiation with the respect to the UML profile are conform to the pattern. They also agreed that it easy to understand the pattern annotated with UML profile.
In the push mechanism, each active sensor initiates the transmission of its value to the fusion unit. An active sensor sets the data values related to the observed element (i. e. , the controlled vehicle and its environment). In the pull mechanism, each passive sensor transmits its value only if the fusion unit queries it, i. e. a passive sensor gets the data values related to the observed element. Functional view: Fig. 4  shows the functional view of the Sensing pattern using the UML use case diagram. This diagram describes the shared and the varying functions of the sensing module. Exteroceptive sensor, Proprioceptive sensor and Fusion unit are the actors of the sensing module. The use cases describe five main functions: observe the vehicle, observe the vehicle environment, process data, merge data and save data in a database.
We know from our discussions with domain experts in driver assistance domain that (i) observe the vehicle, observe the vehicle environment, process data and save data in a database functionalities and (ii) exteroceptive sensors, proprioceptive sensors and fusion unit actors are fundamental. However, merging data functionality is optional, then they can be omitted in several driver assistance systems since it is considered only if the system uses sensors that provide redundant or complementary data. Thus, the use cases Observe vehicle, Observe vehicle environment, Process data and Save data in database are stereotyped (mandatory), whereas the use case Merge data is stereotyped (optional), which expresses explicitly the variability in the pattern use case diagram. Structural view: Fig. 5  illustrates the structural view of the Sensing pattern i.
This class has the observeVehicle() operation which indicates that the sensor acquires periodically the measures related to the vehicle. Thus, this operation is defined with the stereotype (periodic). TrackedElement. This class represents the tracked elements (e. g. , road, fixed obstacle, driver and so on) observed by the exteroceptive sensors. The tracked elements are common between all driver assistance systems. Therefore, the TrackedElement class is defined with the stereotype (mandatory). ControlledVehicle. This class defines the controlled vehicle observed by the proprioceptive sensors. It is stereotyped (mandatory) since the vehicle is a common element between all driver assistance systems. Measurement. This class represents the database which stores RT data (sensor data and derived data) and manages RT transactions.