The initiation to architectural analysis viewed by a group of architect teachers

Ponencia presentada a Session 4: Investigar los procesos de diseño: etnografías y análisis de dialogías sociales / Research through the design processes: etnographic and social dialogical perspectivesThis article is about a pedagogical experience in architecture workshop teaching first-year student? at the National School of architecture of Tunis (ENAU). It focuses, in particular, on the initiation of the student to the architectural analysis process which is a major step in his course. The present work is based on a comparative study between the statements of the exercises related to the topics studied in the workshop. This comparison covers a period of eight years of teaching for the same group of teachers, and deals with their conception of architectural analysis and their way to approaching this initiation to their students. For this purpose, the Group of teachers has implemented an analysis grid that serves, to guide students in their work, and provides a good understanding of the architectural analysis as a process and brain action summoning both the senses and the mind. For this, the Group of teachers made the choice that the parameters to be analyzed concern only the geometry and topology of architectural form levels. They built their grid of architectural analysis on the basis of a postulate stating that “an architectural project is a complex act”. Thus, they consider the architectural project as a whole composed of a multitude of elements; a unit that draws its essence from the plurality. They formulate this complexity by the following equation: [An architectural project = A = 1 unit = 1+1+1+1+1...] Where the (1) represents the components of the project and the (+), the relationships that binds them to each other

Slicing for architectural analysis

Current software development often relies on non trivial coordination logic for combining autonomous services, eventually running on different platforms. As a rule, however, such a coordination layer is strongly weaved within the application at source code level. Therefore, its precise identification becomes a major methodological (and technical) problem and a challenge to any program understanding or refactoring process. The approach introduced in this paper resorts to slicing techniques to extract coordination data from source code. Such data is captured in a specific dependency graph structure from which a coordination model can be recovered either in the form of an Orc specification or as a collection of code fragments corresponding to the identification of typical coordination patterns in the system. Tool support is also discussed.Fundação para a Ciência e a Tecnologia (FCT) - projeto Mondrian, PTDC/EIA-CCO/108302/200

Cybersecurity Architectural Analysis for Complex Cyber-Physical Systems

In the modern military’s highly interconnected and technology-reliant operational environment, cybersecurity is rapidly growing in importance. Moreover, as a number of highly publicized attacks have occurred against complex cyber-physical systems such as automobiles and airplanes, cybersecurity is no longer limited to traditional computer systems and IT networks. While architectural analysis approaches are critical to improving cybersecurity, these approaches are often poorly understood and applied in ad hoc fashion. This work addresses these gaps by answering the questions: 1. “What is cybersecurity architectural analysis?” and 2. “How can architectural analysis be used to more effectively support cybersecurity decision making for complex cyber-physical systems?” First, a readily understandable description of key architectural concepts and definitions is provided which culminates in a working definition of “cybersecurity architectural analysis,” since none is available in the literature. Next, we survey several architectural analysis approaches to provide the reader with an understanding of the various approaches being used across government and industry. Based on our proposed definition, the previously introduced key concepts, and our survey results, we establish desirable characteristics for evaluating cybersecurity architectural analysis approaches. Lastly, each of the surveyed approaches is assessed against the characteristics and areas of future work are identified

Micro-architectural analysis of in-memory OLTP: Revisited

Micro-architectural behavior of traditional disk-based online transaction processing (OLTP) systems has been investigated extensively over the past couple of decades. Results show that traditional OLTP systems mostly under-utilize the available micro-architectural resources. In-memory OLTP systems, on the other hand, process all the data in main-memory and, therefore, can omit the buffer pool. Furthermore, they usually adopt more lightweight concurrency control mechanisms, cache-conscious data structures, and cleaner codebases since they are usually designed from scratch. Hence, we expect significant differences in micro-architectural behavior when running OLTP on platforms optimized for in-memory processing as opposed to disk-based database systems. In particular, we expect that in-memory systems exploit micro-architectural features such as instruction and data caches significantly better than disk-based systems. This paper sheds light on the micro-architectural behavior of in-memory database systems by analyzing and contrasting it to the behavior of disk-based systems when running OLTP workloads. The results show that, despite all the design changes, in-memory OLTP exhibits very similar micro-architectural behavior to disk-based OLTP: more than half of the execution time goes to memory stalls where instruction cache misses or the long-latency data misses from the last-level cache (LLC) are the dominant factors in the overall execution time. Even though ground-up designed in-memory systems can eliminate the instruction cache misses, the reduction in instruction stalls amplifies the impact of LLC data misses. As a result, only 30% of the CPU cycles are used to retire instructions, and 70% of the CPU cycles are wasted to stalls for both traditional disk-based and new generation in-memory OLTP

A Longitudinal Study of Identifying and Paying Down Architectural Debt

Architectural debt is a form of technical debt that derives from the gap between the architectural design of the system as it "should be" compared to "as it is". We measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architectural flaws. In recent work it was shown that the amount of architectural debt has a huge impact on software maintainability and evolution. Consequently, detecting and reducing the debt is expected to make software more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by Brightsquid Secure Communications Corp. This start-up company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and-dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the "before" system, which indicated the impacts of change requests. This initial study motivated a more in-depth analysis of architectural debt. The results of this analysis were used to motivate a comprehensive refactoring of the software system. The third phase of the study was a follow-on architectural debt analysis which quantified the improvements made. Using this quantitative evidence, augmented by qualitative evidence gathered from in-depth interviews with Brightsquid's architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.Comment: Submitted to ICSE-SEIP 201

Usability requirements for architectural analysis tool to support CBD

Component-based development is an architecture-centric process that relies on the integration of pre-fabricated software components. These are often blackbox components whose functionality and configuration may not match the “ideal” system architecture. Systematic architectural analysis can help ensure that risks resulting from architectural adaptations and trade-offs do not adversely affect critical system qualities (e.g. performance, security and modifiability). However, architectural analysis is a complex activity that involves planning, analysis, negotiation and assessment of large amounts of interrelated, often conflicting information. Good tool support is therefore essential for effective architectural analysis. However, the success of a tool depended not only on powerful analysis methods but also on the quality of the toolset's usability. This paper presents functional and non-functional requirements of the tool’s user interface, and discusses the HCI design principles and guidelines in designing a high-quality user interface that would allow developers to parse, analyse and modify architecture specification easily and effectively