Abstract. The discussion in the computer-science literature of the relative merits of linear- versus branching-time frameworks goes back to early 1980s. One of the beliefs dominating this discussion has been that the linear-time framework is not expressive enough semantically, making linear-time logics lacking in expressiveness. In this work we examine the branching-linear issue from the perspective of process equivalence, which is one of the most fundamental notions in concurrency theory, as defining a notion of process equivalence essentially amounts to defining semantics for processes. Over the last three decades numerous notions of process equivalence have been proposed. Researchers in this area do not anymore try to identify the “right ” notion of equivalence. Rather, focus has shifted to providing taxonomic frameworks, such as “the linear-branching spectrum”, for the many proposed notions and trying to determine suitability for different applications. We revisit this issue here from a fresh perspective. We postulate three principles that we view as fundamental to any discussion of process equivalence. First, we borrow from research in denotational semantics and take contextual equivalence as the primary notion of equivalence. This eliminates many testing scenarios as either too strong or too weak. Second, we require the description of a process to fully specify all relevant behavioral aspects of the process. Finally, we require observable process behavior to be reflected in its input/output behavior. Under these postulates the distinctions between the linear and branching semantics tend to evaporate. As an example, we apply these principles to the framework of transducers, a classical notion of state-based processes that dates back to the 1950s and is well suited to hardware modeling. We show that our postulates result in a unique notion of process equivalence, which is trace based, rather than tree based. 1

This paper presents the results of case studies evaluating a method of unifying use cases (UCs) to derive a unified statechart model of the behavior of the domain of a proposed computer-based system. An evaluation of the unification method, the obtained statechart model of the domain, the method’s and model’s feedback on the UCs themselves, and how the method is used in requirements engineering practice was carried out by examining 58 software requirements specifications produced by 189 upper-year undergraduate and graduate students. The results of these studies independently confirm some of the benefits of building a unified SC mentioned in the works of Glinz; Whittle and Schumann; and Harel, Kugler, and Pnueli. 1

Abstract. Our goal is to help the developers of computer-based systems to make informed design decisions on the basis of insights gained from the rigorous analysis of abstract system models. The early work on model-oriented specification has inspired the development of numerous formalisms and tools supporting modelling and analysis. There are also many stories of successful industrial application, often driven by a few champions possessing deep a priori understanding of formalisms. There are fewer cases of successful take-up or adoption of the technology in the long term. We argue that successful industrial adoption of this technology requires that potential users strike a balance between the effort expended in producing and analysing a model and insight gained. In order to support this balancing act, tools need to offer a range of levels of effort and insight. Further, educators need to recognise that training in formal development techniques must support this trade-off process. 1

Programs that use multi-threaded concurrency are known to be difficult to design. Moreover, research in computer-science education suggests that concurrency and synchronization concepts are generally difficult to master. It stands to reason that comprehension tasks may be more complex for programs that employ concurrency than for sequential programs. We believe that external representations, specifically refinements to some of the popular UML modeling notations, should aid students in mastering fundamental concurrency/synchronization concepts and should enable practitioners to better comprehend the dynamically evolving nature of the these programs. In this paper, we present our synchronization adorned UML (saUML) sequence diagram notation that highlights aspects of thread interactions and describe an empirical study of whether these diagrams, as opposed to purely textual representations, help students to better understand concurrent executions and concurrency concepts, as measured by their ability to answer questions about a particular execution of a multi-threaded system. A statistically significant benefit was found from the study. 1.

Abstract. We show how aspects of performance, resource consumption, and deployment on the cloud can be formally modeled for an industrial case study of a distributed system, using the abstract behavioral specification language ABS. These non-functional aspects are integrated with an existing formal model of the functional system behavior, supporting a separation of concerns between the functional and non-functional aspects in the integrated model. The ABS model is parameterized with respect to deployment scenarios which capture different application-level management policies for virtualized resources. The model is validated against the existing system’s performance characteristics and used to simulate and compare deployment scenarios on the cloud. 1

Abstraction is one of the fundamental concepts of software design. Consequently, the determination of an appropriate abstraction level for the multitude of artefacts that form a software system is an integral part of software engineering. However, the very nature of abstraction in software design and particularly its interrelation with equally important concepts like complexity, specificity or genericity are not fully understood today. As a step towards a better understanding of the trade-offs involved, this paper proposes a distinction of abstraction into two types that have different effects on the specificity and the complexity of artefacts. We discuss the roles of the two types of abstraction in software design and explain the interrelations between abstractness, specificity, and complexity. Furthermore, we illustrate the benefit of the proposed distinction with multiple examples and describe consequences of our findings for software design activities.

Learning about concurrency and synchronization is difficult for novices. In prior work, we developed saUML, a refinement of UML sequence diagrams, to address these difficulties and found them to be beneficial when compared to text-only presentations. This paper compares saUML to standard UML sequence diagrams to judge their relative effectiveness in enhancing a novice programmer’s understanding of programs with different levels of synchronization complexity. One experiment compared the two notations when used to understand programs of low synchronization complexity, as judged by their use of only simple synchronization primitives, such as mutex locks. Here, a beneficial trend was observed, but it did not rise to the level of statistical significance. A second experiment compared the two notations on similar tasks but on programs with more complex synchronization constructs, in this case condition synchronization using primitives, such as wait and signal. Here, a significant benefit (p < 0.05) was found to exist.

imaman @ cs.technion.ac.il Abstract thinking is considered to be a high level cognitive skill that enables a comprehensive understanding of a specific concept or a problem using different levels of detailing. Based on a lab activity we conducted on the matter of abstraction, we present guidelines for enabling an Integrated Development Environment (IDE) to promote abstract thinking. The guidelines are defined in the context of an Aspect-Oriented Process Support (AOPS) framework that aims at customizing IDEs to automatically support various software development practices. Specifically, we suggest two kinds of guidelines. The first is concerned with a positive feedback from the IDE in cases where abstraction is used. The second kind is concerned with cases in which the developer is encouraged to move to a different level of detailing, that is, promoted to use abstract thinking. Categories and Subject Descriptors

Abstract—In this paper, we study how three pairs of professional software developers use abstraction in the course of a two-hour design exercise. We devise a scheme for classifying abstractions according domain (e.g., problem domain vs. userinterface domain vs. computer-science domain), which enables us to better compare the developers ’ different uses of abstraction. We also examine how focusing on a particular domain (e.g., how the real-world really operates, or the formal definitions of computer-science concepts) sometimes hinders the developers’ ability or willingness to abstract from those concepts.

Abstract One widely perceived yet poorly understood phenomenon in the practice of critical infrastructure protection is that of blind spots. These are certain aspects of the interrelationships among different critical infrastructure systems (CI systems) that could trigger catastrophe across CI systems but are concealed from planners, and discovered only in the aftermath of a crisis. In this paper, we discuss the sources of blind spots, and explore the feasibility of various techniques to help reveal blind spots. 1