Sequence diagrams are a popular technique for describing interactions between software entities. However, because the OMG group's UML standard is not based on a rigorous mathematical structure, it is impossible to deduce a single interpretation for the notation's semantics, nor to understand precisely how its different fragments interact. While there are a lot of suggested semantics in the literature, they are too mathematically demanding for the majority of software engineers, and often incomplete, especially in dealing with the semantics of lifeline creation and deletion. In this work we describe a simple semantics based on the theory of regular languages, a mathematical theory that is a standard part of the curriculum in every computer science undergraduate degree and covers all the major compositional fragments, and the creation and deletion of lifelines.

Cyber-physical systems (CPSs) are distributed assemblages of computing, communicating, and physical components that sense their environment, algorithmically assess the incoming information, and affect their physical environment. Thus, they share a common structure with other complex adaptive systems, and therefore share both the possible benefits and the probable harmful effects of emergent phenomena. Emergence is an often unexpected pattern that arises from the interactions among the individual system components and the environment. In this paper we focus on three major problems concerning emergence in the context of CPSs: how to successfully exploit emergence, how to avoid its detrimental effects in a single CPS, and how to avoid harmful emergence that arises due to unexpected interaction among several independently developed CPSs that are operating in the same environment. We review the state of the research with regard to these problems and outline several approaches that could be used to address them.

Large and complicated UML models are not useful, because they are difficult to understand. This problem can be solved by using several diagrams of the same system at different levels of abstraction. Unfortunately, UML does not define an explicit set of rules for ensuring that diagrams at different levels of abstraction are consistent. We define such a set of rules, that we call diagram refinement. Diagram refinement is intuitive, and applicable to several kinds of UML diagrams (mostly to structural diagrams but also to use case diagrams), yet it rests on a solid mathematical basis-the theory of graph homomorphisms. We illustrate its usefulness with a series of examples.

Abstract Decomposing a system into subsystems is essential to the design of large software systems. Traditionally, it is performed intuitively without rigorously analyzing the system model. This makes it difficult to check the decomposition correctness, and risks creating subsystems that are either too tightly coupled or not cohesive enough. An aggravating factor is that traditionally classes are the atomic design units. In many cases, however, the same classes play a role in more than one subsystem, and partitioning them unbroken among the subsystems may increase coupling and reduce cohesion. We present an analytical approach that enables reasoning about early exploration of decomposition alternatives. In addition, we describe a visual notation for diagramming the composition of subsystems, and an automatic technique for suggesting good decompositions. A key to our approach is that individual relations, not classes, are the atomic design units. We illustrate the approach with examples and demonstrate its effectiveness on a commercial system. This paper is an extended version of previous work.

Many approaches to software specification and design make use of invariants: statements whose truth is preserved under various operations upon a system or component. Approaches that involve the construction of object-oriented or entity-relationship models require the expression of a particular kind of global invariant, concerning associations between objects or entities. This paper shows how association invariants can be expressed in a new, object-based formal language. It then explains how these expressions can be used to determine pre- and post-conditions for local operations, sufficient to ensure that the invariants are maintained. These conditions - and the program text to implement them - can be generated automatically. This makes it easier to produce correct implementations of an object-oriented design.