Conference Program

During the requirements and analysis stages of software development, the primary goal is to define precise and detailed requirements without concern for software realizations. Security constraints are based on the semantic aspects of applications and they should be reflected on the requirements. From a security point of view we can identify threats as attacker goals and we need to indicate which specific security defenses are needed to control the identified threats, rather than getting involved with low-level design and implementation details. If we use a pattern-based secure system development methodology, at this stage we should produce a set of patterns which define abstract security mechanisms. These patterns should specify only the fundamental characteristics of the security mechanism or service, not software aspects. We develop here the concept of Abstract Security Pattern (ASP), which describes a conceptual security mechanism that realizes one or more security policies able to handle a threat or comply with a security-related regulation or institutional policy. We present a detailed example of an ASP to define its fundamental features as well as concrete patterns derived from it. We relate ASPs to each other using pattern diagrams as well as Security Solution Frames. Finally, we discuss their value for defining security requirements and for building secure systems.

Design patterns are very good to illuminate and motivate architectures. They provide expert solutions to recurrent design problems, being extremely useful to design and explain complex software systems. Patterns preserve design decisions made by original designers and provide a common vocabulary that improves communication. Patterns must be instantiated to the specificities of the context at hands. a process that often starts with a set of design problems, then searching, selecting and applying the patterns, one at once, to derive a concrete implementation.

Due to their abstract nature, design patterns may be incorrectly applied and misused by non-experts, leading to solutions more complex than strictly necessary. To understand a specific pattern instantiation, it is important to know its design context, why the selection of the patterns, how the pattern was mapped to the concrete design, and to be aware of the resulting benefits and liabilities, eventually in comparison with other alternatives. For all of this, pattern instantiations may take considerable effort both to produce by the original designers and to grasp by others. What if design pattern instantiations could be easily documented and visualized, in a close psychological proximity to where they reside, the source code? What if we can provide real-time feedback to designers, turning the pattern instantiation cycle of searching-selecting-applying into a continuum, accelerating the process of instantiating the “right pattern” the “right way”?

This quality is commonly known as liveness. In this talk, we will describe undergoing research work to bring liveness to design patterns, as a way to streamline pattern-based design activities, so that instantiations can be faster to write, retrieve, visualize and understand, with the support of a few features of a Live Software Development Environment.

Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, it can be all too easy to primarily focus on features and overlook software qualities, specifically those related to the architecture. Some believe that by simply following Agile practices—starting as fast as possible, keeping code clean, and having lots of tests—a good architecture will magically emerge.

While an architecture will emerge, if there is not enough attention paid to it and the code, technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably. It is essential to have a sustainable architecture that can evolve through the project life-cycle. Sustainable architecture requires ongoing attention, especially when there are evolving priorities, lots of technical risk, and many dependencies.

This talk presents a set of patterns that focus on practices for creating and evolving a software architecture while remaining Agile. These practices include a set of tools that allow teams to define “enough” architecture in the beginning of the project and to manage the state and the evolution of the architecture as the project evolves.

Pattern languages describe "good design practices or patterns of useful organization within a field of expertise," and individual design patterns are described using well-established templates and formats. Thus, patterns are a mechanism to record and related knowledge for its reuse. Large software systems are designed to satisfy or accomodate many requirements, and non-functional requirements (also called quality attributes) may be inconsistent at time; e.g. high security typically hampers performance and scalability. Thus, a key concern of systems architects are the trade-offs that each alternative solution makes regarding NFRs; e.g. a pattern may favor performance at the expense of scalability or security, another may privilege scalability, and yet another may push security.

This presentation will explore the visual representation of trade-offs among individual patterns of a pattern language, regarding their impact on a given set of non-functional requirements; and will also show how scenario-based architecture evaluation methods may be harnessed to assess alternative patterns for complex situations.

Many decisions made during software development of software about operation, business or architecture are often based purely on experience and intuition. There is wide variety of data available to developers that could help in the decision-making process, but rarely are they harvested and used for that purpose. This talk will introduce the Software Analytics technique and how it can fit into an agile development process. A set of patterns with a running example to identify critical decisions for the project, to identify metrics and to analyze data for decision making will be presented.

"Two threat patterns that exploit 'Cloud Based Leaky Buckets' and 'Malware Laden Buckets'"
by Rohini Sulatycki and Eduardo B. Fernandez

"A Security Information and Event Management Pattern"
by Manfred Vielberth and Günther Pernul

"A Pattern for Controlled Access to a Cargo Port Terminal Physical Structure"
by Virginia Mendiola Romero and Eduardo B. Fernandez

"A security pattern for Zone Isolation using Virtual Processors in mobile and embedded systems"
by Eduardo B. Fernandez y Jorge Forneron

"The Remote Laboratory Management System (RLMS) Pattern"
by Luis Felipe Zapata Rivera and Maria M. Larrondo Petrie

"A Security Pattern for Cloud service certification"
by Antonio Muñoz and Javier López

"Patterns of Store-oriented Software Ecosystems: Detection, Classification, and Analysis of Design Options"
by Bahareh Jazayeri, Olaf Zimmermann, Jochen Küster, Gregor Engels, Dennis Kundisch and Daniel Szopinski

"APEP - An Architectural Pattern Evaluation Process"
by Andreas Seitz, Felix Thiele and Bernd Bruegge

"Learning to Experiments, Set Thresholds, Hold Measurement: Three more patterns in a Software Analytics Pattern Language"
by Joelma Choma, Eduardo Martins Guerra and Tiago Silva da Silva

"Patterns for Continuous Experimentation"
by Alexandre Bittencourt Faria, Danilo Alves De Jesus, Fernando Pereira, Joelma Choma, Luis Ricardo Arantes Filho and Vanessa Gomes Albuquerque EDUARDO GUERRA

"Deliver Value with Confidence: Quality Delivery Pipeline"
by Joseph W. Yoder, Hironori Washizaki and Ademar Aguiar

"Trade-offs evaluation in pattern-based product migration: A Chilean case study"
by Pablo Cruz and Hernán Astudillo

"Delivering Value with Confidence “Swarming Patterns”"
by Joseph W. Yoder, Danijel Arsenovski and Ademar Aguiar