Philippe Kruchten

The 4+1 View Model of architecture

The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns. Architects capture their design decisions in four views and use the fifth view to illustrate and validate them. The logical view describes the designs object model when an object-oriented design method is used. To design an application that is very data driven, you can use an alternative approach to develop some other form of logical view, such as an entity-relationship diagram. The process view describes the designs concurrency and synchronization aspects. The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. The development view describes the softwares static organization in its development environment. >This article presents a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various stakeholders of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed using an architecture-centered, scenario-driven, iterative development process.

Building up and reasoning about architectural knowledge

Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving quality systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use-case model for an architectural knowledge base, together with its underlying ontology. We present a small case study in which we model available architectural knowledge in a commercial tool, the Aduna Cluster Map Viewer, which is aimed at ontology-based visualization. Putting together ontologies, use cases and tool support, we are able to reason about which types of architecting tasks can be supported, and how this can be done.

The Past, Present, and Future for Software Architecture

Its been 10 years since David Garlan and Mary Shaw wrote their seminal book Software Architecture Perspective on an Emerging Discipline, since Maarten Boasson edited a special issue of IEEE Software on software architecture, and since the first International Software Architecture Workshop took place. What has happened over these 10 years? What have we learned? Where do we look for information? Whats the community around this discipline? And where are we going from here?This article is part of a focus section on software architecture.

Using grounded theory to study the experience of software development

Grounded Theory is a research method that generates theory from data and is useful for understanding how people resolve problems that are of concern to them. Although the method looks deceptively simple in concept, implementing Grounded Theory research can often be confusing in practice. Furthermore, despite many papers in the social science disciplines and nursing describing the use of Grounded Theory, there are very few examples and relevant guides for the software engineering researcher. This paper describes our experience using classical (i.e., Glaserian) Grounded Theory in a software engineering context and attempts to interpret the canons of classical Grounded Theory in a manner that is relevant to software engineers. We provide model to help the software engineering researchers interpret the often fuzzy definitions found in Grounded Theory texts and share our experience and lessons learned during our research. We summarize these lessons learned in a set of fifteen guidelines.

Real Challenges in Mobile App Development

Context: Mobile app development is a relatively new phenomenon that is increasing rapidly due to the ubiquity and popularity of smartphones among end-users. Objective: The goal of our study is to gain an understanding of the main challenges developers face in practice when they build apps for different mobile devices. Method: We conducted a qualitative study, following a Grounded Theory approach, in which we interviewed 12 senior mobile developers from 9 different companies, followed by a semi-structured survey, with 188 respondents from the mobile development community. Results: The outcome is an overview of the current challenges faced by mobile developers in practice, such as developing apps across multiple platforms, lack of robust monitoring, analysis, and testing tools, and emulators that are slow or miss many features of mobile devices. Conclusion: Based on our findings of the current practices and challenges, we highlight areas that require more attention from the research and development community.

Towards agile security assurance

Agile development methodologies are gaining acceptance in the software industry. If they are to be used for constructing security-critical solutions, what do we do about assurance? This paper examines how conventional security assurance suits agile methodologies for developing software-intensive systems. It classifies security assurance methods and techniques with regards to their clash with agile development. Suggestions are made for alleviating mismatches between these two methods.

Decision-making techniques for software architecture design: A comparative survey

The architecture of a software-intensive system can be defined as the set of relevant design decisions that affect the qualities of the overall system functionality; therefore, architectural decisions are eventually crucial to the success of a software project. The software engineering literature describes several techniques to choose among architectural alternatives, but it gives no clear guidance on which technique is more suitable than another, and in which circumstances. As such, there is no systematic way for software engineers to choose among decision-making techniques for resolving tradeoffs in architecture design. In this article, we provide a comparison of existing decision-making techniques, aimed to guide architects in their selection. The results show that there is no “best” decision-making technique; however, some techniques are more susceptible to specific difficulties. Hence architects should choose a decision-making technique based on the difficulties that they wish to avoid. This article represents a first attempt to reason on meta-decision-making, that is, the issue of deciding how to decide.

In Search of a Metric for Managing Architectural Technical Debt

Practices designed to expedite the delivery of stakeholder value can paradoxically lead to unexpected rework costs that ultimately degrade the flow of value over time. This is especially observable when features are developed based on immediate value, while dependencies that may slow down future development efforts are neglected. The technical debt metaphor conceptualizes this tradeoff between short-term and long-term value: taking shortcuts to optimize the delivery of features in the short term incurs debt, analogous to financial debt, that must be paid off later to optimize long-term success. In this paper, we describe taking an architecture-focused and measurement-based approach to develop a metric that assists in strategically managing technical debt. Such an approach can be used to optimize the cost of development over time while continuing to deliver value to the customer. We demonstrate our approach by describing its application to an ongoing system development effort.

Contextualizing agile software development

This paper presents a contextual model for software‐intensive systems development to guide the adoption and adaptation of agile software development practices. This model was found especially useful when the project context departs significantly from the “agile sweet spot”, that is, the ideal conditions in which agile software development practices originated from, and where they are most likely to succeed, “out of the box”. This is the case for large systems, distributed development environment, safety‐critical systems, system requiring a novel architecture, or systems with an unorthodox business model or governance model. Copyright

A Survey on Mobile Social Networks: Applications, Platforms, System Architectures, and Future Research Directions

Mobile social networks (MSNs) have become increasingly popular in supporting many novel applications since emerging in the recent years. Their applications and services are of great interest to service providers, application developers, and users. This paper distinguishes MSNs from conventional social networks and provides a comprehensive survey of MSNs with regard to platforms, solutions, and designs of the overall system architecture. We review the popular MSN platforms and experimental solutions for existing MSN applications and services and present the dominant mobile operating systems on which MSNs are implemented. We then analyze and propose the overall architectural designs of conventional and future MSN systems. In particular, we present the architectural designs from two perspectives: from the client side to the server side, and from the wireless data transmission level to the terminal utilization level. We further introduce and compare the unique features, services, and key technologies of two generations of architectural designs of MSN systems. Then, we classify the existing MSN applications and propose one special form of MSN, i.e., vehicular social network, and demonstrate its unique features and challenges compared with common MSNs. Finally, we summarize the major challenges for on-going MSN research and outline possible future research directions.