Motivations Clause Examples
The 'Motivations' clause outlines the underlying reasons or objectives that drive the parties to enter into the agreement. It typically provides context by describing the goals, intentions, or business purposes behind the contract, such as fostering collaboration, achieving a specific project outcome, or addressing a mutual need. By clearly stating these motivations, the clause helps ensure that both parties have a shared understanding of the contract's purpose, which can aid in interpreting the agreement and resolving ambiguities if disputes arise.
Motivations. The interest in MBT is to get the opportunity, by using the Event-B models, not only to formally validate specifications, but also to verify using test cases, that an existing implementation behaves as expected. Along with code generation, MBT (using Event-B) operates at the lower level of the envisaged rigorous engineering chain. In DEPLOY, this chain goes from high-level requirements down to software implementations via specification, architecture and refined designs. Deployment partners (DP), especially SAP (WP4), showed interest into having tool support for MBT. As a consequence, this topic was introduced in the refocus exercise (in the middle of the project [M24]) and was documented in the updated version DoW signed in August 2010 (see Task 9.10 there). The deployment partner SSF (WP3) had recently also shown interest in the MBT task. For the SAP use case, MBT is applied in the area of integration and system testing for service-oriented applications. First, a method for integration testing using SAP's message choreography models was developed using ProB. In the reported period (Feb. 2010 - Jan. 2011), SAP focused on UI system testing using high-level business processes. This required an adaptation of the first MBT approach to the new model types. In these new models, the associated test data constraints played a more prominent position which required also more effort from the tooling point of view.
Motivations. The above works were motivated mainly to support the following three industrial deployments: • Siemens: enable Siemens to use ProB in their SIL4 development chain, replacing Atelier B for data validation (see above). • Bosch: provide animation and constraint-based deadlock detection for the Cruise Control. Indeed, proving absence of deadlocks is important to Bosch, as it means that the modelers have thought of every possible scenario. Currently, the proof obligation is so big (see above) that it is difficult to apply the provers and the feedback obtained during a failed proof attempt is not very useful. Using ProB to find concrete deadlock counterexample helps Bosch to find scenarios they have not yet thought about, and enables them to adapt the model. Once all cases have been covered, the proof of deadlock freedom can be done with Xxxxx'x provers (at least that was the case for the smaller of the two models; the bigger one is still contains deadlocks and is being improved). • SAP: provide a way to generate test cases using constraint-based animation; for more details see the description of the Model-based testing work[8] .
Motivations. The evolutive maintenance (resp. corrective maintenance) has its origin in the DEPLOY description of work, and the various requests (resp. bug reports) listed by WP1-4 partners, developers and users. Since the DEPLOY project inception, various streams have been used to request new features or track known bugs: - dedicated trackers[10] [11] , - platform mailing lists [12] - DEPLOY WP9 mailing list. Maintenance tasks to perform are collected from the aforementioned streams and scheduled during WP9 meetings. These tasks are processed in the same way as the task planned in the description of work. The following table describes the main tasks (either performed or scheduled) motivating the evolutive maintenance: DoW / WP1-4 partners Prover efficiency and integrity x x Deliverable D25 Test reports and test coverage x WP1-4 partners Updating fields of records x WP1-4 partners Team work x WP1-4 partners Edition x WP1-4 partners Increase platform stability x WP1-4 partners Comments everywhere [13] x WP1-4 partners Plug-in incompatibilities x WP1-4 partners Search in goal window [14] x WP1-4 partners Preferences for the automatic tactics [15] x WP1-4 partners Hierarchy / refinement view[16] x x Plug-in developers API to extend the Pretty Printer view [17] x Plug-in developers View the error log [18] x Plug-in developers Prover API x Plug-in developers A different update site for unstable plug-ins x End Users 64-bit Rodin for Mac x End Users Adding a replay proof command in the Event-B explorer [19] x End Users Having auto-completion in proof control [20] x End Users Displaying instantiated hypotheses [21] x End Users Displaying the inherited elements x
Motivations. Main reasons for implementing teamwork are: • SVN Teamwork The reason to support compatibility of Rodin projects with Subversion was to allow Rodin users to share their projects and work on them together, as well as have the benefits of versioning and revision control, provided by the SVN system. It was difficult to work on models in parallel and manage changes made by different parties, especially for big and complex models. Other users expressed a concern on safety aspect of collaborative development, thus pointing out the benefits of centralised repository storage of the models under development on SVN. • Decomposition Difficulties in managing complex models (in particular for a large number of proof obligations) fed the idea of decomposing a model in a way that the resulting sub-models could be developed by different individuals. The decomposition process should be seen as a refinement step where the original properties and respective proof obligations should remain valid. With shared event and shared variable decomposition, these requirements are preserved, with the advantage of simplifying the overall development by dealing with sub-parts of the model at once in each sub-model.
Motivations. What is the customer doing at each stage? What actions are they taking to move themselves on to the next stage? Customer initiated or service driven ? In achieving our vision of integrated service provision around the needs of customers the Alliance has established a 'cradle to grave' timeline which follows both the positive and negative milestones throughout the main lifestages. This ensures that our focus in on prevention and early intervention at each stage of a customers life cycle, and ensures that where there are barriers to positive life milestones that we can identify them early and intervene to prevent escalation. The concept of our customer journey follows the principles from early years collaborative work through to reshaping care for older people. The whole process will be underpinned by XXXXXX, but supported by a similar early intervention and prevention approach aimed right through adulthood. Figure 7 sets out the Customer Life Journey 'Cradle to Grave' timeline. This customer journey helps partners to identify where, when and what something is impacting on a child, adolescent or adult in reaching positive life milestones. Where an issue is identified, cross partner interventions will be in place to provide support around a Whole Systems Approach model of delivery. A key part of our vision is to streamline and improve the pace of intervention for each problem identified for each customer. This process will be enhanced through improved information sharing, intelligence and performance management. In designing and shaping our services around this model, partners will be able to target resources around prevention and towards the most vulnerable families in our communities.
Motivations. In this thesis, we study the key agreement problem over a state-dependent wiretap channel paralleled with a public channel. The channel state is drawn i.i.d. according to a given distribution and it is non-causally known at the transmitter. In Chapter 3, we study the discrete memoryless (DM) model in which the wiretap channel is a DM-SWC (see
Motivations. 8.2.1. Flow plug-in
Motivations. The decision was taken in 2009 to include code generation as a project goal [5] . It had been recognised that support for generation of code from refined Event-B models would be an important factor in ensuring eventual deployment of the DEPLOY approach within their organisations. This was especially true for Bosch and Space Systems Finland (SSF). After receiving more detailed requirements from Bosch and SSF, it became clear we should focus our efforts on supporting the generation of code for typical real-time embedded control software.
Motivations. Monitoring tasks comprise a fundamental functionality in every distributed computing system. Every service should be monitored in order to check its performance and allow for corrective actions in case of failure. Monitoring data represents an operational snapshot of the system behavior along the time axis. Such information is fundamental in determining the origin of the problems or for tuning different system components. For instance, fault detection and recovery mechanisms need a monitoring component to decide whether a particular subsystem or server should be restarted due to the information collected by the monitoring system. Metering tasks are necessary for checking the disk space, network and memory usage from the machines of the platform. This information is vital to allocate services under conditions of optimum performance. Metering and monitoring play an important role in Cloud computing, which can be attributed to the following reasons: From Cloud computing SPI model perspective – Customer consumes services provided by a service provider and service provider outsources the service hosting to the dedicated infrastructure providers. Service Level Agreement (SLA) is usually employed to serve as a bilateral contract between two parties to specify the requirements, quality of service, responsibilities and obligations. SLA can contain a variety of service performance metrics with corresponding Service Level Objectives (SLO). Therefore, we need to meter values of associated metrics defined in the SLA at the usage stage to monitor whether the specified service level objectives are achieved or not. From Cloud computing “Pay-per-use” / “Pay-as-you-go” / “Utility computing” perspective - Cloud service provider delivers QoS-assured services and other commitments in exchange for financial commitments based on an agreed schedule of prices and payments. This requires the service / resource usage to be metered, based on which the bill can then be calculated. From Cloud computing scalability / elasticity and data center perspective - These two perspectives have a feature in common, that is, capacity on-demand or called on-demand resources provisioning. The service and resource usage need to be metered and monitored to support this dynamic scale feature on an as-needed basis.
Motivations. In real-life applications, the measurements of biometric and physical identifiers are affected by noise. For instance, a scanned image of a face results in a noisy version of the original face, and thus, considering HSM as in [19] is more realistic. However, for a general class of ACs, the computational complexity for computing the capacity region with two auxiliary RVs may be prohibitively high. Due to practical concerns in calculating the capacity region of the authentication systems as explicitly as possible, it is of interest to scale down and explore the classes of ACs that need only one auxiliary RV in the expressions of the capacity regions. The signals of biometric and physical identifiers are funda- mentally represented by continuous values, and the noise in most communication channels is modeled as additive white Gaussian noise. Motivated by this nature, we later extend the GS and CS models considered in [19] to characterize the capacity regions for Gaussian sources and channels.