Figure 10 - uploaded by Rosângela Penteado
Content may be subject to copyright.
Source publication
Background
Statecharts are diagrams comprised of visual elements that can improve the modeling of reactive system behaviors. They extend conventional state diagrams with the notions of hierarchy, concurrency and communication. However, when statecharts are considered to support the modeling of system interactions, e.g., in Systems of Systems (SoS),...
Similar publications
The Ultra-Reliable Low Latency Communication~(URLLC) applications have been proposed in recent years, targeting a round-trip end-to-end latency less than 1 ms with high reliability. Therefore, an order of magnitude improvements are needed in all layers of the wireless communication stack. This is a particular challenge for the physical layer, where...
Citations
... We model call events (Cl) as synchronization events that are unicast to other statecharts. The unicast communication offers handshake synchronization between two statecharts, and is blocking, that is, the synchronization takes place only if both sender and receiver are ready to traverse their edges [20]. In addition, we consider that statecharts can be composed in parallel, by defining their interactions via Cl events [20]. ...
... The unicast communication offers handshake synchronization between two statecharts, and is blocking, that is, the synchronization takes place only if both sender and receiver are ready to traverse their edges [20]. In addition, we consider that statecharts can be composed in parallel, by defining their interactions via Cl events [20]. ...
... Of special importance in this context is modeling compositions using diagrammatic representations, which can increase understanding and motivate discussions about interactions before systems are effectively designed. This leads to -possibly reducing risks and costs associated to system misbehaviors discovered in advanced stages of the development process‖ [11]. Clearly, this subject is very broad; thus, we focus on a single detailed system: a railcar system. ...
... It moves to the terminal, where it parks for 90 seconds (9). After stopping in the terminal for 90 seconds, the railcar either continues its travel trail (10) or goes to park in terminal P1 or P2, assuming that one of them is available (11). In the latter case, the railcar enters the parking facilities (12); it enters either P1 or P2 (13). ...
This paper is in the intersection of software engineering and system engineering, two intimately intertwined disciplines. A dominating theme in this paper is the integral conceptualization of systems at large, as well as an underlying concern with software systems. In the software development life cycle, challenges still exist in translating requirements into a design artifact and then into an implementation (e.g., coding), then validating the results. From our perspective, software engineering requires an integrating paradigm toward a unified modeling orientation. Many methodologies, languages, and tools exist for facilitating system development processes. This paper is a venture into project development. To focus the materials, we concentrate on Harel s novel (and classic) development environment, which integrates a scenario-based engineering object orientation and statecharts through developing a railcar system. The railcar system is used as a detailed sample of translating requirements into a design artifact and then into an implementation, then validating the result. The project is re-cased as a single integrated modeling endeavor to be contrasted with the scenario and statecharts development. The result of this scheme is an enriched understanding through experimenting with and contrasting various development methods of software projects.
... Of special importance in this context is modeling compositions using diagrammatic representations, which can increase understanding and motivate discussions about interactions before systems are effectively designed. This leads to -possibly reducing risks and costs associated to system misbehaviors discovered in advanced stages of the development process‖ [11]. Clearly, this subject is very broad; thus, we focus on a single detailed system: a railcar system. ...
... It moves to the terminal, where it parks for 90 seconds (9). After stopping in the terminal for 90 seconds, the railcar either continues its travel trail (10) or goes to park in terminal P1 or P2, assuming that one of them is available (11). In the latter case, the railcar enters the parking facilities (12); it enters either P1 or P2 (13). ...
This paper is in the intersection of software engineering and system engineering, two intimately intertwined disciplines. A dominating theme in this paper is the integral conceptualization of systems at large, as well as an underlying concern with software systems. In the software development life cycle, challenges still exist in translating requirements into a design artifact and then into an implementation (e.g., coding), then validating the results. From our perspective, software engineering requires an integrating paradigm toward a unified modeling orientation. Many methodologies, languages, and tools exist for facilitating system development processes. This paper is a venture into project development. To focus the materials, we concentrate on Harel's novel (and classic) development environment, which integrates a scenario-based engineering object orientation and statecharts through developing a railcar system. The railcar system is used as a detailed sample of translating requirements into a design artifact and then into an implementation, then validating the result. The project is re-cased as a single integrated modeling endeavor to be contrasted with the scenario and statecharts' development. The result of this scheme is an enriched understanding through experimenting with and contrasting various development methods of software projects.
... The process modeling method based on a state transition, contrary to activity-based process, is distributed control logic. Although we can analyze the state transitions from the perspective of the entire system, each user role has its own state transition diagram that interacts with other user roles as needed [15] . This approach is not considered for the relevance of state transitions and the relevance of the planning process. ...
... The identified actors are presented in Table 1. The identification took as a starting point the actors found in the literature, such as SoS-User and SoS-Developer [20,34]. Our approach has some similarities with these works. ...
According to a previously conducted systematic literature review, there are several remaining challenges related to integrating software systems. These systems have become increasingly complex, and they are often formed by integrating independent systems, resulting in a new class of systems referenced as System-of-Systems (SoS). However, there is a lack of studies that are comprehensive and, at the same time, contain a detailed view of how the constituent systems are integrated in order to collectively achieve a common goal. In systematic literature review conducted in this context, it was identified that several of remaining challenges is due to the lack of documentation about integration in SoS, its constituents and their relationships. Based on this scenario, the main contribution of this work is to investigate and propose an approach to assist the Software Engineering community during the integration among constituent systems of a SoS. We argue that if the integration in SoS is properly documented, we can decrease system of systems integration problems and mitigate the lack of existing SoS documentation. We also conclude how the SoS approach can be beneficial for assist the integration of several tools or systems.
... Process description modeling is a hot research direction in process management system. According to their own needs and application, different scholars put forward different modeling methods [2] [3] . The existing modeling methods are mainly based on interaction, activity, state transition, and relational capture. ...
Analysis of business objects focuses on mapping of classes of business objects and the business rules that describe causality and modality that is inherent to them. For their capturing, we use two models. Model of concepts allows one in a systematic way to establish business glossary in the form of a UML class diagram for the analyzed business and so to get an overview of concepts used by the business, understand the business concepts and their relationships, and specify detailed properties of the business concepts. An object life cycle model allows one to specify business rules in relation to relevant class of business objects (business concept) in a systematic way and so in the form of a UML state machine diagram to specify what life phases an object of a particular class may go through during its lifetime, what events are essential for an object in particular life phase, what the response is to relevant events when they occur when the object is in a particular life stage, and at what moments the life of an object ends. For both models, we specify a step-by-step modeling process for their creation.
Conceptual modeling is traditionally regarded to be a static picture of the Real World. This opinion is also manifested in UML, where the class instance is defined as a “snapshot” of the modeled domain object. In this paper, we argue for the idea that causality, as a regular part of the modal logic should be also regarded as a part of the Real World conceptual model. In the paper, we describe the use of the life cycle model for the extension of a traditional conceptual model that allows us to enrich the traditional conceptual modeling with the Real World causality model. We also introduce the methodology for modeling business systems MMABP, which is a methodical basis for the proposed combination of Class Diagram and State Chart, and describe its principles, and rules for this combination. The importance and effects of the use of the State Chart as a complement to the Class Diagram are then illustrated by an example. By this example, the basic related problems and specifics of this way of expressing the causal Real World logic are also discussed. In the Conclusions section we then summarize the importance and position of the life cycle model in MMABP and shortly discuss its general methodical contribution to the conceptual modeling.Keywordsconceptual modelingobject life cycleUML Class DiagramState ChartMMABP
The 5G communication technology has the ability to create logical net works, called network slices, which are specifically carved to serve particular application domains. Due to the mix of different application criticality, it becomes crucial to verify if the applications? service level agreements are met. In this pa per, we propose a novel framework for modeling and verifying 5G orchestration, considering simultaneous access and admission of new requests to slices as well as virtual network function scheduling and routing. By combining modeling in user friendly UML, with UPPAAL model checking and satisfiability-modulo-theories based model finding, our framework supports both modeling and formal verification of service orchestration. We demonstrate our approach on a e-health case study showing how a user, with no knowledge of formal methods, can model a system in UML and verify that the application meets its requirements.
