No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Software engineering 3. Domains, requirements, and software design
... • The complexity of domain knowledge: The knowledge within a domain like healthcare can be vast, complex, and constantly evolving. Domain engineering helps to systematically organize, model, and formally represent this knowledge ( [8], pages 193-198) so that it can be understood and utilized by the DDSS. • Interdisciplinary gaps: Professionals from different disciplines may have varied perspectives and terminologies, creating communication challenges like different viewpoints [9] about the domain facets. ...
... • Interdisciplinary gaps: Professionals from different disciplines may have varied perspectives and terminologies, creating communication challenges like different viewpoints [9] about the domain facets. Domain engineering helps bridge these gaps by providing stakeholders with a common language and unified conceptual framework for the domain facets ( [8], pages 251-318). • Requirement analysis: Identifying the most critical and relevant information for a DDSS is challenging, as the system requirements may vary depending on the context and end-users. ...
... • Requirement analysis: Identifying the most critical and relevant information for a DDSS is challenging, as the system requirements may vary depending on the context and end-users. Domain engineering-based requirements analysis ( [8], pages 479-492) enables a more methodological analysis of requirements by providing tools and methodologies to elicit, analyze, and prioritize them. Requirements acquisition (a part of domainengineering-based requirements analysis) from the already engineered, common and unified domain models or theories leads hopefully to more interoperable DDSSs. ...
Regardless of the often-claimed success of artificial intelligence (AI) and machine learning (ML), AI-based Digital Decision Support Systems (DDSS) still suffer from low adoption rates. Much algorithmic research is done, but examples of AI bringing tangible benefits to the healthcare industry are rare. In this paper, we argue that one of the reasons for those low adoption rates might be the missing domain understanding among the DDSS developers and/or the heterogeneity of domain understanding among the DDSS developers and domain experts. To overcome this, we are working towards methodology to utilize the Domain Engineering approach to create a shared common understanding of key concepts and relationships within the healthcare domain in a structured, formalized way. Especially in the complex interdisciplinary area of DDSS development in healthcare, the Domain Engineering approach can provide a valuable tool to bridge the gap between IT and domain experts by providing a common understanding of the domain and ultimately helps to raise the adoption rates of DDSS, which bring real value to the clinical process. In this paper, we are proposing our work-in-progress ideas and preliminary results.
... Within the literature review they identified more than sixty different computer programming concepts that were grouped into twelve master categories. To extract only concepts relevant to algorithm, abstraction and decomposition, each particular concept from [10] was further analysed with the relevant sections of the Computer Science Curricula 2013 [17] and chapters concerning the software engineering [2]. The aims of the second step were the intersection points between particular fundamental computer programming concepts and the CT concepts. ...
... The primary source for identifying programming skills and practices was the Computer Science Curricula's sections Fundamental Programming Concepts, Development Methods, Algorithms and Design [17]. Furthermore, to observe the broadest spectrum, software engineering skills and practices were also included within our study [2], [9]. Finally, problem conceptualization, implementation, debugging and evaluation were included in the framework. ...
... It is a part of requirements engineering process that assures the problems are properly defined, understood and framed in a way that allows algorithmic solution. Domain specific knowledge is required within the requirement engineering process [2]. Implementation is a practice of programming the algorithmic solution within specific programming language. ...
... System engineering on the basis of the triptych consisting of the application domain description at the strategic level, the requirements prescriptions at the business user level, and finally the systems specifications for the information system and the presentation system are considered in [4] and [12]. The specification is oriented towards systems that are easy and intuitive to use. ...
... Modern information system engineering uses the triptych consisting of the application domain description, the requirements prescriptions, and finally the systems specifications [4,13]. Main methods for application domain description are life case specification, intention description, profile and portfolio description, and sufficient understanding of context. ...
... inheritance of functionality and data ("extends") or composition ("uses"). We embed our specification approach into classical software engineering approaches that use application domain description, requirements prescription and software specification as three different concerns in the system development triptych [4]. The starting point in our co-design framework are users or a group of users with a similar profile and task portfolio (called actors), their life cases and their context, e.g. the platform to be used. ...
The chapter introduces the co-design framework for the design and development of web information systems. Starting from a discussion of general aspects in conceptual modelling and design, their specificity for web information systems is investigated. This leads to a general characterisation by six decisive aspects: intention, usage, content, functionality, context and presentation. This is followed by the presentation of the abstraction layer model for web information system development emphasising different layers of abstraction and the dimensions of focus (global vs. local aspects) and modus (static vs. dynamic aspects). The strategic, business, conceptual, presentation and implementation layers layers, respectively, provide views on a web information system on different levels of abstraction emphasising in general, what the system is about, how users are intended to use the system, how the system can be modelled in an integrated way, how presentation can be tailored, and finally how the whole development process is to be organised.
... System engineering on the basis of the triptych consisting of the application domain description at the strategic level, the requirements prescriptions at the business user level, and finally the systems specifications for the information system and the presentation system are considered in [4] and [12]. The specification is oriented towards systems that are easy and intuitive to use. ...
... Modern information system engineering uses the triptych consisting of the application domain description, the requirements prescriptions, and finally the systems specifications [4,13]. Main methods for application domain description are life case specification, intention description, profile and portfolio description, and sufficient understanding of context. ...
... We embed our specification approach into classical software engineering approaches that use application domain description, requirements prescription and software specification as three different concerns in the system development triptych [4]. The starting point in our co-design framework are users or a group of users with a similar profile and task portfolio (called actors), their life cases and their context, e.g. the platform to be used. ...
The chapter places the co-design method for WIS development from Chapter 11 into the context of web engineering. The chapter first discusses the conformity of the method with general software engineering quality frameworks such as SPICE and CMMI. It then continues with the investigation of architecture- and pattern-driven development, and finally illustrates them by taking a glance at the CottbusNet WIS and the underlying design and development decisions. This is rounded up by a discussion of WIS development dimensions.
... ISs and their requirements are specific to the application domain for which they have been developed and in which they are used [Bjø06]. An application domain is anything to which computing may be applied [Bjø06]. ...
... ISs and their requirements are specific to the application domain for which they have been developed and in which they are used [Bjø06]. An application domain is anything to which computing may be applied [Bjø06]. More Examples of application domains and system domains application domains: information management in hospitals, financial services, transport and logistic, and the publishing sector. ...
... New opportunities for other research: Initially, the system type was considered as an integral part of the application domain [Bjø06]. For the method adaptation, a more differentiated view is helpful. ...
[Context and motivation] Requirements are fundamental for the development of softwarebased information systems (ISs). Stakeholder needs for such ISs are documented as requirements following a requirements engineering (RE) method. Requirements are specific to the application domain for which ISs are developed and in which they are used. A system domain is represented by ISs that share a minimal set of common requirements to solve similar domain independent problems. Both domain-specific aspects need to be considered explicitly during the specification of ISs. Generic RE methods can be used in different domains, but do not consider explicitly domain-specific details. A solution to this problem is the domain-specific adaptation of RE methods. Domain-specific modeling languages (DSMLs) allow conceptual modeling in specific system domains. Domain ontologies provide formalized domain knowledge of an application domain. [Objectives] The objective of this thesis is to investigate, through the example of the task-oriented RE conceptual framework TORE, (1) how a generic RE method can be adapted to consider system domain-specifics with the use of a DSML, and (2) how a generic RE method can be adapted to use an application domain ontology. For the system domain adaptation, we use a personal decision support system (PDSS). The PDSS supports a Chief Information Officer (CIO) in decision-making with tasks in information management (IM). For the adaptation to the application domain, we use IM in hospitals represented by the semantic network of information management in hospitals (SNIK) domain ontology. [Contributions:] The results of this investigation consist of two method adaptations: first, the system domain-specific DsTORE, and second, the application domain-specific TOREOnto. The contributions of the system domain-specific adaptation DsTORE are fourfold. First, an as-is domain study provides details about the information management department of a specific hospital in order to understand the organizational context for the PDSS that will be employed. Second, an exploratory case study shows the extent of task-oriented requirements engineering (TORE) to support the RE specification of a PDSS. Third, the design of DsTORE provides the system domain-specific adaptation of TORE to support the specification of PDSS. Fourth, a case study documents the evaluation of DsTORE. The application domain-specific adaptation TOREOnto consists of three contributions. First, a literature review provides the state of the art regarding the use of domain ontologies in RE, describing nine different usage scenarios of domain ontologies to improve the quality of requirements. Second, the design of TOREOnto provides the application domain-specific adaptation to support the improvement of requirements quality. Third, a case study shows the retrospective evaluation of TOREOnto with RE artifacts created in this thesis. [Methods:] The overall research method of this thesis is Design Science according to Wieringa. The problem investigation of domain ontology usage in RE is based on a systematic literature review by Kitchenham and Charters.
... System engineering on the basis of the triptych consisting of the application domain description at the strategic level, the requirements prescriptions at the business user level, and finally the systems specifications for the information system and the presentation system are considered in [4] and [12]. The specification is oriented towards systems that are easy and intuitive to use. ...
... Modern information system engineering uses the triptych consisting of the application domain description, the requirements prescriptions, and finally the systems specifications [4,13]. Main methods for application domain description are life case specification, intention description, profile and portfolio description, and sufficient understanding of context. ...
... inheritance of functionality and data ("extends") or composition ("uses"). We embed our specification approach into classical software engineering approaches that use application domain description, requirements prescription and software specification as three different concerns in the system development triptych [4]. The starting point in our co-design framework are users or a group of users with a similar profile and task portfolio (called actors), their life cases and their context, e.g. the platform to be used. ...
... System engineering on the basis of the triptych consisting of the application domain description at the strategic level, the requirements prescriptions at the business user level, and finally the systems specifications for the information system and the presentation system are considered in [4] and [12]. The specification is oriented towards systems that are easy and intuitive to use. ...
... Modern information system engineering uses the triptych consisting of the application domain description, the requirements prescriptions, and finally the systems specifications [4,13]. Main methods for application domain description are life case specification, intention description, profile and portfolio description, and sufficient understanding of context. ...
... inheritance of functionality and data ("extends") or composition ("uses"). software specification as three different concerns in the system development triptych [4]. The starting point in our co-design framework are users or a group of users with a similar profile and task portfolio (called actors), their life cases and their context, e.g. the platform to be used. ...
We have already mentioned the definition of database design:
Design the logical and physical structure of a database in a given database management system (or for a database paradigm) so that it contains all the information required by the user and for the efficient behavior of the whole information system for all users and with application processes and user interaction.
... System engineering on the basis of the triptych consisting of the application domain description at the strategic level, the requirements prescriptions at the business user level, and finally the systems specifications for the information system and the presentation system are considered in [4] and [12]. The specification is oriented towards systems that are easy and intuitive to use. ...
... Modern information system engineering uses the triptych consisting of the application domain description, the requirements prescriptions, and finally the systems specifications [4,13]. Main methods for application domain description are life case specification, intention description, profile and portfolio description, and sufficient understanding of context. ...
... We embed our specification approach into classical software engineering approaches that use application domain description, requirements prescription and software specification as three different concerns in the system development triptych [4]. The starting point in our co-design framework are users or a group of users with a similar profile and task portfolio (called actors), their life cases and their context, e.g. the platform to be used. ...
Web information systems are nowadays widely used. E-business, edutainment, infotainment, community and identity Web systems are data and information intensive. They integrate a variety of database, workflow and other processing, communication and presentation systems. Their design and development is thus based on an integrated development of structuring, functionality, distribution and interactivity of users. The codesign framework allows the integration of these different aspects. This chapter surveys the codesign approach and its deployment for the development of large Web information systems.
... We describe and explain the meaning of ZF columns and rows in terms of business archetype patterns and software triptych. We also explain how we use this archetype patterns based ZF in domain analysis and compare our ZF based domain analysis approach with Dines Björners domain facets based approach [18]. ...
... The Björner's domain analysis method [18] is based on domain stakeholders and on pragmatically chosen domain facets. According to Björner, the domain facets are intrinsic, business processes, supporting technologies, management and organization, rules and regulations, scripts and human behavior. ...
... We analyze the business domains by domain analysis methodology similarly to one suggested by Björner [18]. Björners domain analysis methodology is based on domain stakeholders and on pragmatically chosen domain facets (intrinsic, business processes, supporting technologies, management and organization, rules and regulations, scripts and human behavior). ...
Development of enterprise applications is expensive, takes time and requires knowledge, tools and techniques. Contemporary enterprise applications must be dependable as well as customizable in the evolutionary way according to changes in the enterprise business processes. The wider goal of our research is to develop techniques for development of enterprise applications that software end users, in collaboration with software developers, are able to change safely and easily according to changing requirements. In accordance to the software engineering triptych: to write software, the requirements must be prescribed; to prescribe the requirements, the domain must be understood; to understand the domain, we must study one. We present and exemplify P systems based enterprise domain model. We treat an enterprise as a membrane-computing structure and utilize P system notions, notations and formalisms in modelling of enterprises and enterprise business processes. In our understanding this P systems based enterprise model can provide a practically usable framework for development of evolutionary enterprise applications.
... Based on the domain model of laboratory [14] the LIMS Software Factory architecture consists of LIMS DSL (domain specific language), LIMS Engine and Tests Engine. With LIMS DSL the requirements for particular LIMS software will be described. ...
... The idea behind the Figure 1 is the software engineering triptych [14]. According to software engineering triptych, in order to develop software we must first informally or formally describe the domain ( ); then we must somehow derive the requirements ( ) from these domain descriptions; and finally from these requirements we must determine software design specifications and implement the software ( ), so that (meaning the software is correct) holds [15]. ...
... Archetypes Based Development is a software triptych process (from domain model via requirements to software) [14] with business archetypes and business archetype patterns. ABD involves ZF based implementation for AP&P, for the domain, as well as for requirements (Table 2). ...
We present archetypes based techniques we are using in developing of real life laboratory information management systems (LIMS) software and LIMS Software Factory. These archetypes based techniques utilize software engineering triptych together with archetypes and archetype patterns for software factories. Following the software engineering triptych, to write software we have to know requirements; to know requirements we have to know domain; to know the domain we have to analyze and model one. We call our techniques as Archetypes Based Development (ABD). In ABD the domain is analyzed according to Zachman Framework by asking questions what, how, where, who, when, and why. The domain model is developed by using the product (what), business process (how), organization structure (where), person (who), order and inventory (when), as well as rule (why) archetype patterns. We use the domain model analyzed and developed in this way as a domain specific language for prescribing requirements. In our understanding, with ABD it is possible to increase the dependability of developed software; reduce semantic heterogeneity of models and data types; improve the maturity of the development process; and lead developments of one-off software towards software factory.
... In this methodology, the understanding and modelling of business domains ("what to do"), as they are, without any reference to the software requirements or to the design to any software system, is the main objective. We evaluate our archetypes and archetype patterns based domain modelling methodology by comparing it with Bjørner's domain facets [3] based domain analysis methodology. In this evaluation we rely on the Bjørner's domain theory research topics [2]. ...
... We analysed Arlow and Neustadt's business archetype patterns according to the Zachman Framework [5] and Bjørner's domain analysis methodology [3]. We also compared these archetype patterns with analysis and data model patterns by Hay [6;7], Fowler [8], and Silverston [9; 10]. ...
... A domain stakeholder [3] is a person or an organization united somehow in interest or dependency on the domain. Each stakeholder has some roles, rights, duties as well as specifically identified perspective or view on a domain. ...
We present business archetypes and archetype patterns based methodology for modelling of business domains. Business domain model (e.g. in health care, banking, transportation, etc.) describes universe of discourse of business without any reference to the software requirements or to the design to any software system. Business archetype is an abstract model describing some common term that consistently and universally occurs in business domains and in business software systems. Business archetype pattern is collaboration between business archetypes. Product, process, party, party relationship, inventory, order, quantity and rule archetype patterns are members of this archetype patterns framework. We exemplify the usefulness of this framework of business archetypes and archetype patterns by utilizing it in development of clinical laboratory domain model and of clinical laboratory information management system (LIMS) software based on this domain model. In software development we follow the software engineering triptych-from domain modelling via requirements constructing to design and implementation of software. In our understanding the domain modelling with archetypes and archetype patterns complements Bjørner's domain facets based domain analysis methodology and results in more flexible, customizable, reliable and interoperable software.
... . Thus the combined universes of domain engineering, requirements engineering, and software design constitute the universe of discourse of software engineering [4]. Model and modeling play a crucial role in the software development process. ...
... Using only one of them as the sole modeling approach will not guarantee high quality software. Literature review also confirmed this conclusion [4], [8]. As a result, we can supplement semi-formal models with formal ones to introduce precision in the development process and to sweeten formal languages usage. ...
... According to the literature, formal modeling languages such as Object-Z take a precise approach to software development, delivering reliable software; however, in addition to high cost involvements, they require a level of expertise that is not common in commercial development communities. These limitations lead to decreasing their practicality [4]. Semi-formal modeling languages such as UML that are widely used in practical large-scale software development do not take a rigorous approach to reliability of software in development [8]. ...
This paper empirically investigates the advantages and limitations of modeling languages by specifying the multi-lift system as a non-trivial case study. The multi-lift system is a suitable test bed to demonstrate the expressive power of modeling languages in specifying such a concurrent, reactive, and complex system. English, UML, and Object-Z have been chosen, respectively, as informal, semi-formal, and formal modeling languages to specify the software requirements of the multi-lift system. These modeling languages are then compared and evaluated based on their likelihood to produce a specification with some defined characteristics. The conclusion is that informal languages such as English cannot be used to produce software models, because they are prone to ambiguity. Each of the formal and semi-formal languages has some unique advantages and limitations. Semi-formal models should be supplemented with formal ones to produce high quality software.
... opers understand the system's requirements and design an appropriate solution. It helps developers identify the key concepts, relationships, and constraints relevant to the problem domain (Bjørner, 2006). In healthcare, domain modelling is developing apace. ...
... We follow archetypes and archetype patterns based methodology of domain engineering (Piho, 2011), (Piho et al., 2010a). This methodology is based on the domain engineering methodology proposed by Dines Björner (Bjørner, 2006) and utilizes the Zachman Framework (Zachman, 1987), (Piho et al., 2010b) and archetypes and archetype patterns based modeldriven architecture (Arlow and Neustadt, 2003), (Piho et al., 2012), (Piho et al., 2011b). The general idea of the methodology is illustrated in Figure 1. ...
... In this work, the modelling process deals with various languages, as seen by considering the triptych of Bjoerner [24][25][26][27]: D, S −→ R. Here, the domain D deals with properties, axioms, sets, constants, functions, relations and theories. The system model S expresses a model or a refinement-based chain of models of the system. ...
... Theorems for the context are proved using the RODIN tool, but it is clear that the process for constructing the domain D is crucial to modelling the system, from consid- [24][25][26][27] and variations of this methodology. ...
State-based formal methods [e.g. Event-B/RODIN (Abrial in Modeling in Event-B—system and software engineering. Cambridge University Press, Cambridge, 2010; Abrial et al. in Int J Softw Tools Technol Transf (STTT) 12(6):447–466, 2010)] for critical system development and verification are now well established, with track records including tool support and industrial applications. The focus of proof-based verification, in particular, is on safety properties. Liveness properties, which guarantee eventual, or converging computations of some requirements, are less well dealt with. Inductive reasoning about liveness is not explicitly supported. Liveness proofs are often complex and expensive, requiring high-skill levels on the part of the verification engineer. Fairness-based temporal logic approaches have been proposed to address this, e.g. TLA Lamport (ACM Trans Program Lang Syst 16(3):872–923, 1994) and that of Manna and Pnueli (Temporal verification of reactive systems—safety. Springer, New York, 1995).
We contribute to this technology need by proposing a fairness-based method integrating temporal and first-order logic, proof and tools for modelling and verification of safety and liveness properties. The method is based on an integration of Event-B and TLA. Building on our previous work (Méry and Poppleton in Integrated formal methods, 10th international conference, IFM 2013, Turku, Finland, pp 208–222, 2013. doi:10. 1007/ 978-3-642-38613-8_ 15), we present the method via three example population protocols Angluin et al. (Distrib Comput 18(4):235–253, 2006). These were proposed as a theoretical framework for computability reasoning about Wireless Sensor Network and Mobile Ad-Hoc Network algorithms.
Our examples present typical liveness and convergence requirements. We prove convergence results for the examples by integrated modelling and proof with Event-B/RODIN and TLA. We exploit existing proof rules, define and apply three new proof rules; soundness proofs are also provided. During the process we observe certain repeating patterns in the proofs. These are easily identified and reused because of the explicit nature of the reasoning.
... D'un point de vue général, cette thèse propose une formalisation d'outils de couverture de code structurelle pour un langage de haut-niveau d'abstraction qui est précisément dé ni dans le chapitre III. Ce chapitre aborde très succinctement le très large domaine du génie logiciel [8,9,7] pour donner le contexte dans lequel se place la couverture de code, c'est-à-dire au sein des activités de véri cation d'un processus de développement d'un logiciel (éventuellement) critique. ...
... Néanmoins il est toujours possible d'adopter un modèle et d'y ajouter des contraintes pour le rendre plus adéquat au problème. Par exemple, on peut adopter le cycle Agile et le renforcer au niveau de la traçabilité et de la documentation.II.4.3 L'importance du processus de développement pour un logiciel critiquePartant du constat qu'il est impossible, sinon extrêmement di cile, de compter exactement le nombre d'erreurs existant dans un logiciel 7 , DO-178B s'appuie sur le processus de développement.Gérard Ladier[48] donne l'analogie selon laquelle « on ne délivre pas d'eau propre avec un tuyau7. Les résultats d'indécidabilité de la logique nous disent même que ce but est impossible à atteindre : il n'y a pas de méthode systématique ou d'algorithme permettant de savoir si une propriété est véri ée ou non.II.5. ...
This thesis presents a study on structural code coverage for a language of the ML family, in response to an industrial need in safety-critical software domain to develop tools. In this context, ML appears as a particularly rich and high-level language with a high degree of expressiveness. Its use is a progress but also raises issues when trying to apply classical safety-critical software engineering processes. In particular, the two notions of condition and decision, as well as coverage criteria associated with them, rapidly become very complex. The first contribution of this thesis answers the question of what conditions and decisions mean for a language of the ML family, by giving several formal definitions. Then, we present a formalised technique for structural code coverage which rewrites the source code to produce traces at run-time. We name it the intrusive instrumentation. We also formalise another technique which does not rewrite the source code, which allows to use the same binary for both testing activities and production. This second technique is called non intrusive and consists in generating at compile-time the information needed to match the machine code back to the source code. Other information are also generated for the execution environment to record specific traces that we need to generate a coverage report involving Boolean measures. Finally, we compare these two techniques both formally and practically, but also in terms of implementation.
... Very few papers and book consider these early phases. [5] and [20] consider application domain description beside [35]. [5] considers software engineering on the basis of the triptych consisting of the application domain description, the requirements prescriptions, and finally the systems specifications. ...
... [5] and [20] consider application domain description beside [35]. [5] considers software engineering on the basis of the triptych consisting of the application domain description, the requirements prescriptions, and finally the systems specifications. ...
On a high level of abstraction a Web Information System (WIS) can be described by a storyboard, which in an abstract way specifies who will be using the system, in which way and for which goals. While syntax and semantics of storyboarding has been well explored, its pragmatics has not. This paper contributes the first step towards closing this gap by analysing the usage of WISs. Starting from a classification of intentions we first present life cases, which capture observations of user behaviour in reality. We discuss the facets of life cases and present a semi-formal way for their documentation. Life cases can be used in a pragmatic way to specify a story space, which is an important component of a storyboard. In a second step we complement life cases by user models that are specified by various facets of actor profiles that are needed for them. We analyse actor profiles and present a semi-formal way for their documentation. We outline how these profiles can be used to specify actors, which are an important component of a storyboard. Finally, we analyse contexts and the way they impact on life cases, user models and the storyboard.
... 3. The actor names are inconsistent. 4. There are too many use cases. ...
... The gripper releases the blank sheet on the loading area of the Feed Belt. 4 15. The crane travels to the right back to the Deposit Belt. ...
Experience is showing some modeling quality problems with the Use Case Modeling Approach. There is a need for another higher quality modeling approach with a sound theoretical basis and a precise definition. This research has developed an alternative, a new event-oriented approach (BPA), and the case studies carried out support the hypothesis that BPA is a more effective alternative to the Use Case Approach (UCA) in modeling and understanding system functional requirements. In BPA, events are considered the primary objects of the world model. The Event defined in BPA is a real-life conceptual entity that is unrelated to any implementation. The BPA Behavioral Patterns are temporally ordered according to the sequence of the
real world events.The major contributions of this research are:
The Behavioral Pattern Analysis (BPA) modeling approach.
Validation of the research hypothesis that the Behavioral Pattern Analysis (BPA) approach is a more effective alternative to Use Case Analysis (UCA) in modeling the functional requirements of Human-Machine Safety-Critical Real-time Systems. The development of an interactive software tool (DECISION), which is based on a combination of the Analytic Hierarchy Process (AHP) and the ELECTRE Multi-Criteria Decision Making (MCDM) methods. The DECISION software tool was used to process the assessment results of the case studies.
... The non-functional requirements focused on restrictions to the system's functioning, such as requiring internet access, consuming high RAM, overloading the device's image processor, ensuring responsiveness and portability, and featuring an avatar with sufficient characteristics to reproduce manual alphabet signs accurately. Below are the data collected from volunteers who used the prototype (Bjørner, 2006). The platform implemented in an online environment was analyzed in its high-fidelity prototype phase. ...
This study aims to analyse the users’ perceptions about a 3D digital artifacts prototype for teaching the fingerspelling alphabet of Brazilian Sign Language (LIBRAS). For this purpose, a high-fidelity prototype was developed with a non-programming method, and a usability test was conducted using a structured questionnaire with 31 participants, including Deaf and hearing people. Most users (96.7%) rated the learning experience with the tool as positive, with 67.7% rating the experience as "good", 12.9% as "very good", and 16.1% as "excellent". Comparing the evaluation between Deaf and hearing people showed that both target groups mostly rated it positively. However, most hearing people rated it "good," while the majority of the Deaf rated it as "excellent" (29%) or "outstanding" (14%) compared to 13% and 12%, respectively, among the hearing. In summary, considering the variables presented, the experience was well rated and did not encounter solid obstacles or resistance.
... That particular problem, activity or interest, which can be named as subject area, where the created software program has been applied is the domain of the software. Formally, it represents the target subject of a specific programming project, whether narrowly or broadly defined (Bjørner 2017). Evans claims domain simply as "it's the thing the software is about" (Evans 2003). ...
Context
Software developers need to constantly work on evolving the structure and the stability of the code due to changing business needs of the product. There are various refactoring approaches in industry which promise improvements over source code composition and maintainability.
Objective
In our research, we want to improve the maintainability of an existing system through refactoring using Domain-Driven Design (DDD) as a software design approach. We also aim for providing empirical evidence on its effect on maintainability and the challenges as perceived by developers.
Method
In this study, we applied the action research methodology, which facilitates close academia-industry collaboration and regular presence in the studied product. We utilized focus groups to discover problems of the existing system with a qualitative approach. We reviewed the subject codebase to construct our own expert opinion as well and identified problems in the codebase and matched them with the ones raised by engineers in the team. We refactored the existing software system according to DDD principles. To measure the effects of our actions, we utilized Technology Acceptance Model (mTAM) questionnaire, and also semi-structured interviews with the development team for data collection, and card sorting methodology for qualitative analysis. For minimizing bias that might affect our results with the existing software engineers in the team, we extended our measurement with three new joiner software engineers in the team through the think aloud protocol.
Results
We have identified that engineers mostly gave positive answers to our interview questions, which are mapped to software maintainability metrics defined by ISO/IEC 25010. Our DDD refactoring scored 85 in PU and 83 in PEU, leading to an overall mTAM score of 84. This means acceptable on the acceptability scale, B on the grade scale, and good on the adjective rating scale.
Conclusion
Our research led us to conclude that a powerful design approach, like DDD, is an effective tool for restructuring and resolving software issues in this situation. It offers standardization to the software and the refactoring efforts. We realized that DDD entails a certain degree of complexity and cognitive load, which is a barrier for software engineers, but they are aware of its benefits.
... In view of these facts, web applications are significantly large, complex, and even critical software systems. Formalization of software/web engineering designwhich is a pre-requisite step for automated design, but yet to be applied sufficiently in design-has been discussed in [6][7][8][9][10][11]. Systematic, automated web engineering [12]-which applies computation to its various design, development & other activities-is highly desirable, rather, essentially required for developing such systems, specially, in view of their dynamic nature: web applications need to modify & evolve almost continuously over time. ...
In view of the fact that web applications are significantly large, complex, highly dynamic & critical software systems, it is desirable that processes of web design and development be systematic & be automated as far as possible. The task of automating an engineering activity is quite complex because it involves two types of contrasting intelligences: (i) Human intelligence which is rooted in informal expression, judgmental evaluation, inductive reasoning and commonsense, and (ii) The machine intelligence which is essentially based on formal expression, formal rule-based evaluation & deductive reasoning etc. Human intelligence is required for understanding the problem domains & their environments, and then for using the understanding for designing & developing solutions in such a form that it is understood and executed by the contrasting intelligence, viz. the machine intelligence. The proposed approach takes care of the facts of human capabilities being rooted in informality & of machine capabilities being purely formal. For this purpose, solutions conceived by human experts-which are generally expressed in some natural language-are, first of all, translated to semi-formal mathematical entities: recursive lists. These recursive lists then are easily translated to fully formal entities in some functional programming language like LISP or Haskell. In this communication, the approach is applied to structural aspects of web and is explained through sufficient exemplars. The dynamics of web will be discussed subsequently.
... For example, human competencies may evolve more slowly than management and organization, which may evolve more slowly than work, which in turn may evolve more slowly than technologies. Different conceptual frameworks exist to analyze work and its context, which may be useful in understanding the separation of concerns (see, e.g., PACT [65], Cognitive Work Analysis [6], Contextual Design [56] and Six facets of domain engineering [66]). Hvannberg and Rudinsky [67] reviewed conceptual modelling that was performed for a training simulator for crisis management training. ...
Systems evolve with societal, business and technological changes. Because of these changes, socio-technical systems need to adapt to new situations that were unknown at the time of design. Good knowledge of system evolution can help with that adaption. Although the evolution of software and interactive systems has been broadly debated, little research has been conducted on the specific genre of systems and even less empirical research on the evolution of interactive software has been performed. We propose a three-dimensional framework which consists of what changes during the evolution of training simulators, what are the drivers for those changes and how the changes effect innovation and robustness of the training simulators. By reviewing the literature on training simulators, we argue for this framework. The contribution of the paper is a framework that can be used to carry out empirical studies on evolution of training simulators.
... As a part of this domain, we identify and define the core concepts that should be implemented as part of the domain functionality. These concepts are categorized as entities which may have values, properties and types, or functions over entities or events and behaviors of the entities [8]. We abstract these concepts as a result of interaction with domain experts. ...
Architecture styles in the software world continue to evolve driven by the need to present easier and more appealing ways of designing and building software systems to meet stakeholder needs. One of the popular trends at the moment is microservices. Microservice architecture is gaining the market of software development architecture due to its capability to scale. It separates independent small services of a system to perform one business capability at a time. However, determining the right size of business capability that could be called a microservice is still a challenge. Current practices of partitioning microservice rely on personal practice within industry which is prone to bias by practitioners. Based on the ambiguity of determining the optimum size of a microservice, in this paper, we propose a conceptual methodology to partition a microservice based on domain engineering technique. Domain engineering identifies the information needed by a microservice, services needed for microservice functionality and provides description for workflows in the service. We demonstrate the usage of this methodology on the weather information dissemination domain as a confirmatory case study. We show how to split the weather information dissemination system sub-domain into different microservices that accomplish the weather information dissemination business capability.
... Various methods are available for reengineering. For example, framework of BPI (Business Process Improvement) can be used with steps as follows: (1) process simplification, (2) looks for portion that is valueless for consumer, (3) accelerates the rate, (4) response flexibility, (5) improves responsibility clarity, and (6) cuts down process cost and keeps fulfilling consumer expectation (Bjørner, 2006). ...
This article examines the relationship of leader perception of business entrepreneurship in their organizations and important change and performance outcomes. A model is presented in which business entrepreneurship and reengineering predicts business organizational performance. Results from this studies (N = 110) confirm that a model linking intrapreneurship and business process reengineering to organizational performance was supported. Findings are discussed in light of travel business attempts to maximizing benefits of intrapreneurship and financial management.
Keywords : Business process reengineering, financial management, Intrapreneurship, organizational performance, travel business.
... Various methods are available for reengineering. For example, framework of BPI (Business Process Improvement) can be used with steps as follows: (1) process simplification, (2) looks for portion that is valueless for consumer, (3) accelerates the rate, (4) response flexibility, (5) improves responsibility clarity, and (6) cuts down process cost and keeps fulfilling consumer expectation (Bjørner, 2006). ...
T
their
or
g
aniz
a
tions
and
import
an
t
change
and
perf
ormance
out
c
omes.
A
model
is
pr
esen
t
ed
in
which
business
en
tr
epr
eneur
ship
and
r
eengineering
pr
edicts
business
or
g
aniz
a
tional
perf
ormance.
R
esults
fr
om
this
s
tudies
(N
=
110)
c
onfirm
tha
t
a
model
l
i
n
k
i
n
g
i
n
t
ra
p
r
e
n
e
u
r
s
h
i
p
a
n
d
b
u
s
i
n
e
s
s
p
r
o
c
e
s
s
r
eengineering
t
o
or
g
aniz
a
tional
perf
ormance
w
as
support
ed.
Findings
ar
e
discussed
in
ligh
t
of
tr
a
v
el
b
u
s
i
n
e
s
s
a
t
t
e
m
p
t
s
t
o
m
a
x
i
m
i
z
i
n
g
b
e
n
e
f
i
t
s
o
f
in
tr
apr
eneur
ship
and
financial
manag
emen
t.
B
u
s
i
n
e
s
s
p
r
o
c
e
s
s
r
e
e
n
g
i
n
e
e
r
i
n
g
,
f
i
n
a
n
c
i
a
l
m
a
n
a
g
e
m
e
n
t
,
I
n
t
r
a
p
r
e
n
e
u
r
s
h
i
p
,
organiz
ational
perf
ormance,
travel
business.
... Applications' domain description also facilitates matching user profile with activity concepts and their associations. Regarding the diverse aspects of domain modeling [5], we only model the concepts of the activity domain due to the dynamicity of activities. In our model, we consider concepts with two kinds of direct associations: (a) part-whole relations, e.g., "living room" contains "temperature sensor," and (b) weighted relations, e.g., "user" prefers "leisure" with a 0.8 weight. ...
Representing people activities in smart environments is an important aspect of supporting people well-being. Improving activity representation enables exploiting the semantics of people’s actions. We propose a novel activity model that facilitates the representation based on the ContextAA micro context-aware programming approach. In this approach, applications contain a self-described semantics in an ontic knowledge, and autonomic components interpret the knowledge to augment the interaction and adaptation of pervasive smart environments. In this paper, we present our model which integrates the semantics of the activity as an essential part of the ontic knowledge. We also present the programming constructs designed to facilitate building micro context-aware applications, and the components implemented to reduce the activity semantics to a minimal self-described context capable of being deployed in our ContextAA micro smart environment platform.
... Figure 1 summarizes the two kinds of models that are used in the formal development. In this work the modelling process deals with various languages, as seen by considering the triptych of Bjoerner [5]: D, S −→ R. Here, the domain D deals with properties, axioms, sets, constants, functions, relations, and theories. The system model S expresses a model or a refinement-based chain of models of the system. ...
The design of e-voting systems requires the use of techniques which guarantee that the resulting system is safe, secure and preserves privacy. We develop Event-B models of a voting system, by applying a decomposition pattern and a technique of contextualisation, using a dependency mechanism. Through refinement, we take into account the precise regulation and structure of a specific voting process, and reason formally about the system’s resistence to common attacks and threats.
... The engineer brings this knowledge to bear on practical problems 1 . The software engineering triptych [3,1] consists of the application domain description, the requirements prescriptions, and finally the systems specifications. Requirements must be reasonably well understood before software can be designed, programmed, and coded. ...
... Some RE methods, such as KAOS [14] or i* [8], use an object model to do this. We think that it is also necessary to model domain knowledge, as advocated by [7] and [6], also called explicit knowledge by [3]. For a long time, it is well-known in RE that domain knowledge is one of the crucial factors to perform high quality requirements elicitation [13]. ...
When using formal methods, one of the main difficulties is to elaborate the initial formal specification from informal descriptions obtained during the requirements analysis phase. For that purpose, we propose a goal-based approach in which the building of an initial formal model (in Event-B) is driven by a goal-oriented requirements engineering model (SysML/KAOS). In a previous work, we have defined a set of rules to derive a partial Event-B specification from a goal model. In this paper, we propose to enhance the goal model in order to obtain a more complete formal specification. First, we advocate the specification of a domain ontology in order to share common understanding of the structure of the different applications of the underlying domain. This is particularly useful for complex systems to explicit and make clearer the domain knowledge. For a specific system, a class and an object diagrams are then specified to detail its components and their relationships. Finally, we describe how the ontology and the structural model are translated into Event-B. The proposed approach is illustrated through a landing gear system.
... The engineer brings this knowledge to bear on practical problems 1 . The software engineering triptych [3,1] consists of the application domain description, the requirements prescriptions, and finally the systems specifications. Requirements must be reasonably well understood before software can be designed, programmed, and coded. ...
... The engineer brings this knowledge to bear on practical problems 1 . The software engineering triptych [3,1] consists of the application domain description, the requirements prescriptions, and finally the systems specifications. Requirements must be reasonably well understood before software can be designed, programmed, and coded. ...
Computer science and technology is an area of very intensive research and development. It is estimated that the half-life period of knowledge in this area is about 12 to 18 months. No other branch of science has such short half-life period. Therefore new problems have to solved. At the same time some of the old open problems must be solved. This invited talk aims at a systematic survey of open problems and proposes a number of solutions to their solution. We structure these open problems in structuring problems, into size or more generally complexity problems, functionality problems, interactivity problems, distribution problems, and general problems.
... It is however not clear whether such separation is universal and is applicable for any kind of collaboration. • The 3C-C schemata for specification of collaboration should be based on business user requirements prescription, system requirements prescription, and application domain description [4]. Therefore, a methodology of elicitation of the domain description and for derivation of requirements is needed. ...
Specification of collaboration has neglected over a long period although collaboration is one of main conceptions in computer science and computer engineering. We distinguish between collaborations among systems and socio-technical collaboration. Database research has succeeded in developing approaches for collaboration among database systems that incorporate conceptual specification and allow to reason on systems at a far higher abstraction level. Conceptual modelling of socio-technical collaborating systems is however an open research issue. With the advent of web information systems systems became naturally socio-technical and collaborating. Therefore, we need a techniques for conceptual description of collaboration. Collaboration modelling may be based on models for communication, models for coordination, and models for cooperation. In socio-technical systems users work within their local environment and collaborate within the global world. Therefore, users inject their culture and their specific behaviour into collaboration. Users use information, communication, cooperation and coordination services. These services must be highly flexible and adaptable to the needs of users, to the circumstances and contexts of these users, and to the technical infrastructures used.
... These techniques are well established on a solid formal basis and their domain of e ciency, their strengths and weaknesses are well acknowledged by the formal methods community. Although, some ad-hoc formalisation of domain knowledge [7][8][9] within formal methods is possible, none of these techniques o↵ers a built-in mechanism for handling explicit semantics. ...
All software systems execute within an environment or context. Reasoning about the correct behavior of such systems is a ternary relation linking the requirements, system and context models. Formal methods are concerned with providing tool (automated) support for the synthesis and analysis of such models. These methods have quite successfully focused on binary relationships, for example: validation of a formal model against an informal one, verification of one formal model against another formal model, generation of code from a design, and generation of tests from requirements. The contexts of the systems in these cases are treated as second-class citizens: in general, the modelling is implicit and usually distributed between the requirements model and the system model. This paper is concerned with the explicit modelling of contexts as first-class citizens and illustrates concepts related to implicit and explicit semantics on an example using the Event B language.
Regardless of the often-claimed success of artificial intelligence (AI) and machine learning (ML), AI-based Digital Decision Support Systems (DDSSs) still suffer from low adoption rates. Much algorithmic research is done, but examples of AI bringing tangible benefits to the healthcare industry are rare. We argue that one of the reasons for low adoption rates is missing domain understanding and/or the heterogeneity of domain understanding among the DDSS developers and domain experts. To overcome this, we are working towards a methodology to utilize the Domain Engineering approach to create a shared common understanding of key concepts and relationships within the healthcare domain in a structured, formalized way. In the realm of complex interdisciplinary DDSS development within healthcare, the Domain Engineering approach can serve as a valuable instrument for bridging the gap between IT professionals and domain experts. It facilitates establishing a shared comprehension of the domain and hopefully contributes significantly to increasing the value and adoption rates of DDSSs in the clinical process. In this paper, we are proposing our work-in-progress ideas and preliminary results.
Domain modelling, as per the approach of this paper, offers the possibility of describing software application domains in a precise and comprehensive manner – well before requirements capture can take place. We endow domain modelling with appropriate analysis and description calculi and a systematic method for constructing domain models. The present paper is a latest exposé of the domain science & engineering as published in earlier papers and a book. It reports on our most recent simplifications to the domain analysis & description approach.
Plantation forests the world over have been established in order to supply industrial mills with wood. It is estimated that by 2050, over half of the world’s requirements for industrial timber could be supplied from plantations, thus reducing the pressure on natural forests. Ensuring that the plantation, with its many stands, different planted species, terrains, etc., delivers the correct volume of timber over time is a complex problem. Although many forest harvest models and systems have been described in the literature, not many have been described from a computer science or information systems perspective. In this paper, the plantation forestry domain (based on South African experience) is described using formal models (Z notation), augmented by semi-formal (conceptual) models. Since plantations are generally planted to provide wood to mills, the forest-to-mill supply chain is described. This paper contributes toward an understanding of the plantation forestry domain.
The paper is devoted to research into methods for requirements elicita-tion. From our perspective, the use of ontology engineering is particularly interesting. The author focuses his attention on selected aspects of ontology engineering , resulting from the needs of his doctoral thesis, organized by the Design Science Research paradigm. The article seeks to recognize a certain level of interplay between ontology engineering and individual tasks of the process of requirements elicitation (a synergy). Therefore, it aims to explain possible expectations for ontology engineering, which result from the specific features of the process of requirements elicitation. In order to identify the guidelines for the developing domain ontologies based on the requirements elicitation process. The originality of the article results from the consideration of the interplay between ontology engineering and requirements engineering, relative to the context of software engineering. As a result, the software engineering layers propagated by Pressman have been extended to include another layer of management philosophy. The rationale behind this was the noticing of the impact of other concepts of philosophy on this work, such as axiology or epistemology.
We present a method for analysing and describing domains.
By a domain we shall understand a rationally describable segment of a human assisted reality, i.e., of the world, its physical parts: natural [“God-given”] and artifactual [“human-made”], and living species: plants and animals including, notably, humans. These are endurants (“still”), as well as perdurants (“alive”). Emphasis is placed on “human-assistedness,” that is, that there is at least one (human-made) artifact and, therefore, that humans are a primary cause for change of endurant states as well as perdurant behaviours.
By a method we shall mean a set of principles of analysis and for selecting and applying a number of techniques and tools in the construction of some artifact, say a domain description. We shall present a method for constructing domain descriptions. Among the tools we shall only be concerned with are the analysis and synthesis languages.
Domain science and engineering marks a new area of computing science. Just as we are formalising the syntax and semantics of programming languages, so we are formalising the syntax and semantics of human-assisted domains. Just as physicists are studying the natural physical world, endowing it with mathematical models, so we, computing scientists, are studying these domains, endowing them with mathematical models, A difference between the endeavours of physicists and ours lies in the tools: The physics models are based on classical mathematics, differential equations and integrals, and so on; our models are based on mathematical logic, set theory, and algebra [1].
Where physicists thus classically use a variety of differential and integral calculi to model the physical world, we shall be using the analysis and description calculi presented in this article to model primarily artifactual domains.
A personal account is given of my scientific work since I retired 10 years ago. This work centers around a new dimension to computing science: that of domain science & engineering. By a domain we shall understand a rationally describable segment of a human assisted reality, i.e., of the world, its physical parts, and living species. These are endurants (“still”), existing in space, as well as perdurants (“alive”), existing also in time. Emphasis is placed on “human-assistedness”, that is, that there is at least one (man-made) artifact and that humans are a primary cause for change of endurant states as well as perdurant behaviours. Section 7 brings my laudatio.
اینترنت اشیاء فناوری مدرنی است که قابلیت ارسال داده از طریق شبکه های ارتباطی، اعم از اینترنت یا اینترانت، را فراهم می کند. با توجه به آن که مفهوم اینترنت اشیاء مفهوم نوینی می باشد، در این مقاله به عنوان راه حلی برای ساخت و توسعه ی یک شهر هوشمند روی آن تمرکز نمودیم. هدف ما تبیین ابعاد شهر هوشمند و چگونگی کمک فناوری اینترنت اشیاء به ساخت و توسعه ی یک شهر هوشمند از ابعاد مختلف می باشد. استفاده از این فناوری منجر به کاهش هزینه ها، زمان، مصرف انرژی و
ترافیک می گردد.
کلمات کلیدی: اینترنت اشیاء – شهر هوشمند – ابعاد شهر هوشمند – فناوری مدرن
In this chapter, we first introduce how eight bio-molecular operations are used to perform representation of bit patterns for data stored in tubes in bio-molecular computer. Then, we describe how eight bio-molecular operations are applied to deal with various problems.
We present a theory of security testing based on the basic distinction between system specifications and security requirements. Specifications describe a system’s desired behavior over its interface. Security requirements, in contrast, specify desired properties of the world the system lives in. We propose the notion of a security rationale, which supports reductive security arguments for deriving a system specification and assumptions on the system’s environment sufficient for fulfilling stated security requirements. These reductions give rise to two types of tests: those that test the system with respect to its specification and those that test the validity of the assumptions about the adversarial environment. It is the second type of tests that distinguishes security testing from functional testing and defies systematization and automation.
In this “40 years of formal methods” essay we shall first delineate, Sect. 1, what we mean by method, formal method, computer science, computing science, software engineering, and model-oriented and algebraic methods. Based on this, we shall characterize a spectrum from specification-oriented methods to analysis-oriented methods. Then, Sect. 2, we shall provide a “survey”: which are the ‘prerequisite works’ that have enabled formal methods, Sect. 2.1, and which are, to us, the, by now, classical ‘formal methods’, Sect. 2.2. We then ask ourselves the question: have formal methods for software development, in the sense of this paper been successful? Our answer is, regretfully, no! We motivate this answer, in Sect. 3.2, by discussing eight obstacles or hindrances to the proper integration of formal methods in university research and education as well as in industry practice. This “looking back” is complemented, in Sect. 3.4, by a “looking forward” at some promising developments — besides the alleviation of the (eighth or more) hindrances!
Plantation forests the world over have been established in order to supply industrial mills with wood. It is estimated that by 2050, over half of the world's requirements for industrial timber could be sup-plied from plantations, thus reducing the pressure on natural forests. Ensuring that the plantation, with its many stands, different planted species, terrains, etc., delivers the correct volume of timber over time is a complex problem. Although many forest harvest models and systems have been described in the literature, not many have been described from a computer science or information systems perspective. In this pa-per, the plantation forestry domain (based on South African experience) is described using formal models (Z notation), augmented by semi-formal (conceptual) models. Since plantations are generally planted to providewood to mills, the forest-to-mill supply chain is described. This paper contributes toward an understanding of the plantation forestry domain.
This paper illustrates an approach for architectural design of a Learning Management System (LMS), which is verifiable against the Learning Technology System Architecture (LTSA) conformance rules. We introduce a new method for software architectural design that extends the Unified Modeling Language (UML) component diagram with the formal architectural style of Acme, hence, combines the advantages of the visual appeal of a graphical method and preciseness of a formal method. We propose some new stereotypes for UML component-connector style to incorporate Acme style within UML. A UML meta-model for the design components is also proposed to elucidate the relationships between the components. We also propose a verification method to ensure that the design artifact is holding conformance with LTSA standard. The design process as well as the verification process entails additional knowledge about the domain, which is supplied by the domain Ontology. The LTSA conformance rules, written in natural language, are represented more formally with help of Conceptual Graph representation, before using them in the verification process. Finally, we introduce a verification method that tries to find out a design pattern in the architectural design that conforms to the particular conformance rule intended to check. The verification process also introduces a goodness measure of the conformance.
The main theme of this research is to study and develop techniques for modeling of software-controlled safety-critical systems. The area we focus in this thesis is the specification of a domain, where such systems are supposed to operate, and its validation. The contribution of this thesis is twofold: First, we model the land transport domain, a good candidate for this study because of its safety-critical nature, in the formal framework of Event-B and propose some guidelines for it. Second, we present an approach, based on the technique of animation and low-cost transformations, for stepwise validation of formal specifications.
This chapter provides results on the modeling and verification of systems using transition systems. The goal is to provide the basic fundamental and conceptual theories, which support Event B approach. The chapter explains how invariant properties and safety properties are defined in the framework of a transition system, which may model a program, an algorithm or a distributed system. It details the Event B language and related concepts such as events, contexts, machines and refinement. The chapter explains proof obligations (POs) generated for checking the consistency of the Event B structure. It develops three case studies, in order to illustrate the incremental and proof-based modeling using Event B. The chapter emphasizes the notion of proof-based patterns applied for the Event B method. It describes available tools for supporting the Event B modeling language concludes with the current and future trends for this method.
The standardized business processing rules and information processing flow, as well as the risk control according to the internal control norms, reflect the reliability, validity and robustness of the Enterprise Information System (EIS). The business objectives effectively met in EIS requires the integration of internal control concepts, rule & regulatory, standardized processes and measures in EIS. Furthermore, its implementation is a complex and large systematic engineering, and related to corporate governance structure, enterprise internal control environment, as well as many other factors. We introduce domain analysis and formal methods, which are a mathematic-based methodology in software engineering, to specify, model, verify the EIS if the desired internal control properties are contained in the software system during the design stage. So we can find defects and vulnerabilities quickly and effectively in the early-stage during EIS implementation, to reduce the risk of the inefficient or failure of internal control in EIS. In this paper, we first study the background of internal control in EIS, especially Chinese enterprise internal control environment, then introduce how to apply domain analysis and formal methods into EIS design to ensure internal control met business objective, at last, we take the sales activities of internal control under Chinese enterprise environment as an example to illustrate our method.
ResearchGate has not been able to resolve any references for this publication.