In 2024, Demis Hassabis and John Jumper won the Nobel Prize for Chemistry for developing an AI model to predict the shape of every protein known to mankind. Chair of the Nobel Committee, Heiner Linke, described the AI system as the achievement of a ''50-year-old dream'' that solved a notoriously difficult problem eluding scientists since the 1970s. This AI system, AlphaFold, has ushered in a golden age of AI for science - the development of AI techniques for accelerating scientific discovery. We are currently amid the largest surge in the application and development of AI for scientific research in history. Scholarly publications, patents, education, training, research activity and investment are increasing at unprecedented rates. AI may help scientists address humanity's greatest challenges such as climate change, pollution, resource scarcity and infectious diseases.

Foundation model-enabled generative artificial intelligence facilitates the development and implementation of agents, which can leverage distinguished reasoning and language processing capabilities to takes a proactive, autonomous role to pursue users’ goals. Nevertheless, there is a lack of systematic knowledge to guide practitioners in designing the agents considering challenges of goal-seeking (including generating instrumental goals and plans), such as hallucinations inherent in foundation models, explainability of reasoning process, complex accountability, etc. To address this issue, we have performed a systematic literature review to understand the state-of-the-art foundation model-based agents and the broader ecosystem. In this paper, we present a pattern catalogue consisting of 18 architectural patterns with analyses of the context, forces, and trade-offs as the outcomes from the previous literature review. We propose a decision model for selecting the patterns. The proposed catalogue can provide holistic guidance for the effective use of patterns, and support the architecture design of foundation model-based agents by facilitating goal-seeking and plan generation. • A collection of architectural patterns for real-world agent implementations. • FM-based agent ecosystem with architectural pattern annotations as a guidance. • Curated analysis of patterns including benefits, trade-offs, and real-world uses. • A decision model for structuring the patterns and making rational design decisions.

Large language model (LLM) based chatbots, such as ChatGPT, have attracted huge interest in foundation models. It is widely believed that foundation models will serve as the fundamental building blocks for future AI systems. However, the architecture design of foundation model based systems has not yet been systematically explored. There is limited understanding about the impact of introducing foundation models in software architecture. Therefore, in this paper, we propose a taxonomy of foundation model based systems, which classifies and compares the characteristics of foundation models and system design options. Our taxonomy comprises three categories: the pretraining and adaptation of foundation models, the architecture design of foundation model based systems, and responsible-AI-by-design. This taxonomy can serve as concrete guidance for designing foundation model based systems.

The rapid development of artificial intelligence (AI) has led to increasing concerns about the capability of AI systems to make decisions and behave responsibly. Responsible AI (RAI) refers to the development and use of AI systems that benefit humans, society, and the environment while minimising the risk of negative consequences. To ensure responsible AI, the risks associated with AI systems' development and use must be identified, assessed and mitigated. Various AI risk assessment frameworks have been released recently by governments, organisations, and companies. However, it can be challenging for AI stakeholders to have a clear picture of the available frameworks and determine the most suitable ones for a specific context. Additionally, there is a need to identify areas that require further research or development of new frameworks, as well as updating and maintaining existing ones. To fill the gap, we present a mapping study of 16 existing AI risk assessment frameworks from the industry, governments, and non-government organizations (NGOs). We identify key characteristics of each framework and analyse them in terms of RAI principles, stakeholders, system lifecycle stages, geographical locations, targeted domains, and assessment methods. Our study provides a comprehensive analysis of the current state of the frameworks and highlights areas of convergence and divergence among them. We also identify the deficiencies in existing frameworks and outlines the essential characteristics of a concrete and connected framework AI risk assessment (C2AIRA) framework. Our findings and insights can help relevant stakeholders choose suitable AI risk assessment frameworks and guide the design of future frameworks towards concreteness and connectedness.

Abstract There is a growing awareness of the importance of human values in software systems. However, limited tools are available to support the integration of human values during software development. Most of these tools are focused on concepts related to specific, well-known human values (e.g., privacy, security) in software engineering. This paper aims to (partially) address this gap by developing a human values dashboard. We conducted a multi-stage study to design, implement and evaluate a human values dashboard. First, an exploratory study was conducted by interviewing 15 software practitioners to investigate the possibility of using a human values dashboard to help address human values in software development, its potential benefits, and required features. Second, we experimented with four Machine Learning approaches to detect the presence of human values in issue discussions. We used the best approach to develop a human values dashboard for software development. The dashboard displays whether any human values are present in each issue discussion. Finally, we interviewed ten different practitioners to investigate the usefulness of the dashboard in practice. This study found that the human values dashboard could help raise awareness, focus attention, and prioritise issues based on the presence of values. This study also identified two potential challenges to the adoption of the dashboard. First, the possible incorrect issues description that can mislead the automated values identification in the dashboard. Second, the lack of willingness of a company to adopt the dashboard.

Abstract Human values such as honesty, social responsibility, fairness, privacy, and the like are things considered important by individuals and society. Software systems, including mobile software applications (apps), may ignore or violate such values, leading to negative effects in various ways for individuals and society. While some works have investigated different aspects of human values in software engineering, this mixed-methods study focuses on honesty as a critical human value. In particular, we studied (i) how to detect honesty violations in mobile apps, (ii) the types of honesty violations in mobile apps, and (iii) the perspectives of app developers on these detected honesty violations. We first develop and evaluate 7 machine learning (ML) models to automatically detect violations of the value of honesty in app reviews from an end-user perspective. The most promising was a Deep Neural Network model with F1 score of 0.921. We then conducted a manual analysis of 401 reviews containing honesty violations and characterised honesty violations in mobile apps into 10 categories: unfair cancellation and refund policies; false advertisements; delusive subscriptions; cheating systems; inaccurate information; unfair fees; no service; deletion of reviews; impersonation; and fraudulent-looking apps. A developer survey and interview study with mobile developers then identified 7 key causes behind honesty violations in mobile apps and 8 strategies to avoid or fix such violations. The findings of our developer study also articulate the negative consequences that honesty violations might bring for businesses, developers, and users. Finally, the app developers’ feedback shows that our prototype ML-based models can have promising benefits in practice.

As the deployment of artificial intelligence (AI) is changing many fields and industries, there are concerns about AI systems making decisions and recommendations without adequately considering various ethical aspects, such as accountability, reliability, transparency, explainability, contestability, privacy, and fairness. While many sets of AI ethics principles have been recently proposed that acknowledge these concerns, such principles are high-level and do not provide tangible advice on how to develop ethical and responsible AI systems. To gain insight on the possible implementation of the principles, we conducted an empirical investigation involving semi-structured interviews with a cohort of AI practitioners. The salient findings cover four aspects of AI system design and development, adapting processes used in software engineering: (i) high-level view, (ii) requirements engineering, (iii) design and implementation, (iv) deployment and operation.

Although AI is transforming the world, there are serious concerns about its ability to behave and make decisions responsibly. Many ethical regulations, principles, and frameworks for responsible AI have been issued recently. However, they are high level and difficult to put into practice. On the other hand, most AI researchers focus on algorithmic solutions, while the responsible AI challenges actually crosscut the entire engineering lifecycle and components of AI systems. To close the gap in operationalizing responsible AI, this paper aims to develop a roadmap on software engineering for responsible AI. The roadmap focuses on (i) establishing multi-level governance for responsible AI systems, (ii) setting up the development processes incorporating process-oriented practices for responsible AI systems, and (iii) building responsible-AI-by-design into AI systems through system-level architectural style, patterns and techniques.

Human values such as integrity, privacy, curiosity, security, and honesty are guiding principles for what people consider important in life. Such human values may be violated by mobile software applications (apps), and the negative effects of such human value violations can be seen in various ways in society. In this work, we focus on the human value of honesty. We present a model to support the automatic identification of violations of the value of honesty from app reviews from an end-user perspective. Beyond the automatic detection of honesty violations by apps, we also aim to better understand different categories of honesty violations expressed by users in their app reviews. The result of our manual analysis of our honesty violations dataset shows that honesty violations can be characterised into ten categories: unfair cancellation and refund policies; false advertisements; delusive subscriptions; cheating systems; inaccurate information; unfair fees; no service; deletion of reviews; impersonation; and fraudulent-looking apps. Based on these results, we argue for a conscious effort in developing more honest software artefacts including mobile apps, and the promotion of honesty as a key value in software development practices. Furthermore, we discuss the role of app distribution platforms as enforcers of ethical systems supporting human values, and highlight some proposed next steps for human values in software engineering (SE) research.

The growing diffusion of software in society and its influence on people demands from its creators that their work carefully considers human values such as transparency, social responsibility, and equality. But how do software practitioners address human values in software engineering practice? We interviewed 31 software practitioners from two organizations, each having a strong values framework, with the aim to understand: (a) practitioners’ perceptions of human values and their role in software engineering; (b) practices that practitioners use to address human values in software; and (c) challenges they face during this process. We report our findings from two contrasting case organizations on how practitioners “engineer” values in their unique organizational settings. We found evidence that organizational culture significantly contributes to how values are addressed in software. We summarize recommendations from the practitioners to support proactive engineering of values-conscious software.

Agile methods are predominantly focused on delivering business values. But can Agile methods be adapted to effectively address and deliver human values such as social justice, privacy, and sustainability in the software they produce Human values are what an individual or a society considers important in life. Ignoring these human values in software can pose difficulties or risks for all stakeholders (e.g., user dissatisfaction, reputation damage, financial loss). To answer this question, we selected the Scaled AgileFramework (SAFe), one of the most commonly used Agile methods in the industry, and conducted a qualitative case study to identify possible intervention points within SAFe that are the most natural to address and integrate human values in software. We present five high-level empirically-justified sets of interventions in SAFe: artefacts, roles, ceremonies, practices, and culture. We elaborate how some currentAgile artefacts (e.g., user story), roles (e.g., product owner), ceremonies (e.g., stand-up meeting), and practices (e.g., business-facing testing) in SAFe can be modified to support the inclusion of human values in software. Further, our study suggests new and exclusive values-based artefacts (e.g., legislative requirement), ceremonies (e.g., values conversation), roles (e.g., values champion), and cultural practices (e.g., induction and hiring) to be introduced in SAFe for this purpose. Guided by our findings, we argue that existingAgile methods can account for human values in software delivery with some evolutionary adaptations.

The elicitation of end-users& human values - such as freedom, honesty, transparency, etc - is important in the development of software systems. We carried out two preliminary Q-studies to understand (a) the general human value opinion types of eHealth applications (apps) end-users (b) the eHealth domain human value opinion types of eHealth apps end-users (c) whether there are differences between the general and eHealth domain opinion types. Our early results show three value opinion types using generic value instruments: (1) fun-loving, success-driven and independent end-user, (2) security-conscious, socially-concerned, and success-driven end-user, and (3) benevolent, success-driven, and conformist end-user. Our results also show two value opinion types using domain-specific value instruments: (1) security-conscious, reputable, and honest end-user, and (2) success-driven, reputable and pain-avoiding end-user. Given these results, consideration should be given to domain context in the design and application of values elicitation instruments.

Background: There is a growing awareness of the importance of human values (e.g., inclusiveness, privacy) in software systems. However, there are no practical tools to support the integration of human values during software development. We argue that a tool that can identify human values from software development artefacts and present them to varying software development roles can (partially) address this gap. We refer to such a tool as human values dashboard. Further to this, our understanding of such a tool is limited. Aims: This study aims to (1) investigate the possibility of using a human values dashboard to help address human values during software development, (2) identify possible benefits of using a human values dashboard, and (3) elicit practitioners' needs from a human values dashboard. Method: We conducted an exploratory study by interviewing 15 software practitioners. A dashboard prototype was developed to support the interview process. We applied thematic analysis to analyse the collected data. Results: Our study finds that a human values dashboard would be useful for the development team (e.g., project manager, developer, tester). Our participants acknowledge that development artefacts, especially requirements documents and issue discussions, are the most suitable source for identifying values for the dashboard. Our study also yields a set of high-level user requirements for a human values dashboard (e.g., it shall allow determining values priority of a project). Conclusions: Our study suggests that a values dashboard is potentially used to raise awareness of values and support values-based decision-making in software development. Future work will focus on addressing the requirements and using issue discussions as potential artefacts for the dashboard.

Recent years has seen renewed interest in the social impact of technology, as major scandals such as Cambridge Analytica and bias in AI systems have made the international press. There is an increasing acceptance that software systems must properly embed human values - such as inclusion, diversity, social responsibility, and cultural context - in their design. The software engineering field, however, has been slow to adopt human-value based methods for software design, in contrast to other fields such as Human Computer Interaction. In this tutorial, we gave an overview of approaches for embedding human values in technology, summarizing work in other fields. We then described work in addressing human values in the software engineering field, with a specific focus on requirements engineering. Through a series of interactive exercises, we helped participants to explore what human values mean in a requirements engineering context, how they can be captured as part of requirements engineering, and practical steps that can be taken to address human values in software.

Failure to account for human values in software (e.g., equality and fairness) can result in user dissatisfaction and negative socio-economic impact. Engineering these values in software, however, requires technical and methodological support throughout the development life cycle. This paper investigates to what extent top Software Engineering (SE) conferences and journals have included research on human values in SE. We investigate the prevalence of human values in recent (2015 -- 2018) publications in these top venues. We classify these publications, based on their relevance to different values, against a widely used value structure adopted from the social sciences. Our results show that: (a) only a small proportion of the publications directly consider values, classified as directly relevant publications; (b) for the majority of the values, very few or no directly relevant publications were found; and (c) the prevalence of directly relevant publications was higher in SE conferences compared to SE journals. This paper shares these and other insights that may motivate future research on human values in software engineering.

Software failures that demonstrate violations of human values can result in financial losses, reputation damages and social implications. Therefore, integrating human values into software is vital to satisfy stakeholder needs. However, developing methodological approaches that allow systematic integration of human values throughout the software development life cycle is an open challenge. This paper proposes the Continual Value(s) Assessment (CVA) framework that uses extended goal and feature modeling techniques to support systematic integration, tracing and evaluation of human values in software systems. The CVA framework prescribes (i) brainstorming of value implications of system features based on conventional system artefacts and (ii) the expansion of the existing set of system features to better serve stakeholder values expectations. In a pilot study, we use an emergency alarm system for the elderly to demonstrate the feasibility of the framework. We further discuss the challenges we faced while applying the framework and present the lessons learned from the pilot study.

Software has become an integral part of human life. This gives rise to the need of developing software that respects human values such as transparency, fairness and privacy. Software that compromises on human values (e.g. privacy) can affect people's reputation and impinges on their ability to function in society with the usual freedom and autonomy. Integrating human values into software is, however, a challenging task due to its imprecise and subjective nature. Enforcing regulations is one way to make software development considerate of the desired standards and values. The European Union's General Data Protection Regulation (GDPR) on software is one such effort to protect EU citizens' data and personal information. GDPR prescribes data protection principles and data subject rights mainly to protect user privacy. Looking beyond privacy, we studied GDPR to identify the extent to which it covers human values. We mapped GDPR's data protection principles and data subject rights to a widely accepted human values structure adopted from social sciences. Our results show that GDPR addresses not only privacy but also several other human values including power, security and universalism. Moreover, fairness and transparency stand out as the most value-conscious principles prescribed in GDPR.

Requirements engineering (RE) has generally done a good job of helping to define software systems with the intended functionality and cost and that is safe, secure and reliable. However, there is a broader set of human values - such as transparency, integrity, diversity, compassion, social justice - that are largely ignored when we develop software systems. In this talk, I will argue that RE methods should place more emphasis on these human values so we do a better job of building software that aligns with our individual, corporate or societal values. Furthermore, drawing on recent evidence from case studies in industry, I will argue that dealing with human values in software systems is not just of interest to a small group of organisations; rather, all software projects should think about human values, build them in where appropriate, test for them, and use them to drive design decisions. When they are not dealt with in this way, there can be severe social and economic consequences.

Summary form only given, as follows. Software engineering has generally done a good job of building software systems with the intended functionality and cost and that is safe, secure and reliable. However, there is a broader set of human values – such as transparency, integrity, diversity, compassion, social justice – that are largely ignored when we develop software systems. In this talk, I will argue that software development methods should place more emphasis on these human values so we do a better job of building software that aligns with our individual, corporate or societal values. Furthermore, drawing on recent evidence from case studies in industry, I will argue that dealing with human values in software systems is not just of interest to a small group of organisations; rather, all software projects should think about human values, build them in where appropriate, test for them, and use them to drive design decisions. When they are not dealt with in this way, there can be severe social and economic consequences.

Software influences several aspects of people's lives and therefore needs to reflect their values. However, existing software engineering methods fail to account for human values, which may result in breaching those values in software and, therefore, dissatisfaction of users and loss of profit and reputation. To avoid such negative consequences, human values need to be integrated -- in a verifiable way -- into software. We refer to this as Operationalizing Human Values in Software. But this is not easy to achieve due to three main obstacles: first, human values are hard to define in a way that can be put into practice; second, existing software design decisions are mainly ignorant of values; finally, values are hard to determine and quantify in software. This paper aims to establish a research roadmap for overcoming these obstacles. The proposed roadmap focuses on (i) establishing practical definitions for human values, (ii) integrating values into software design, and (iii) measuring values in the software development life cycle.

Identifying which agile methods and processes are most effective depends on the goals and aims of an organisation. Agile development promotes an environment of continuous improvement and trust within self-organising teams. Therefore, it is important to allow teams to have the flexibility to customize and tailor their chosen methods. However, in a large-scale agile deployment, there needs to be a degree of process standardization across the organisation; otherwise, different teams will not be able to effectively share knowledge and best practices. This paper addresses the classic CSCW issue of the tensions that arise between process standardization and flexibility in a large-scale agile development through a case study at the British Broadcasting Corporation (BBC).

This paper presents a digital relay baton that connects long-distance runners with distributed online spectators. The baton broadcasts athletes? live locative data to a social network and communicates back remote-crowd support through haptic and audible cheers. Our work takes an exploratory design approach to bring new insights into the design of real-time techno-mediated social support. The prototype was deployed during a 170-mile charity relay race across the UK with 13 participants, 261 on-line supporters, and gathered a total of 3,153 'cheers'. We report on the insights collected during the design and deployment process and identify three fundamental design considerations: the degree of spectator expression that the design affords, the context applicability, and the data flow within the social network.

Multi-tenancy is sharing a single application's resources to serve more than a single group of users (i.e. tenant). Cloud application providers are encouraged to adopt multi-tenancy as it facilitates increased resource utilization and ease of maintenance, translating into lower operational and energy costs. However, introducing multi-tenancy to a single-tenant application requires significant changes in its structure to ensure tenant isolation, configurability and extensibility. In this paper, we analyse and address the different challenges associated with evolving an application's architecture to a multi-tenant cloud deployment. We focus specifically on multi-tenant data architectures, commonly the prime candidate for consolidation and multi-tenancy. We present a Domain-Specific Modeling language (DSML) to model a multi-tenant data architecture, and automatically generate source code that handles the evolution of the application's data layer. We apply the DSML on a representative case study of a single-tenant application evolving to become a multi-tenant cloud application under two resource sharing scenarios. We evaluate the costs associated with using this DSML against the state of the art and against manual evolution, reporting specifically on the gained benefits in terms of development effort and reliability.

Since its infancy, Model Driven Engineering (MDE) research has primarily focused on technical issues. Although it is becoming increasingly common for MDE research papers to evaluate their theoretical and practical solutions, extensive usability studies are still uncommon. We observe a scarcity of User eXperience (UX)-related research in the MDE community, and posit that many existing tools and languages have room for improvement with respect to UX [26], [44], [37], where UX is a key focus area in the software development industry. We consider this gap a fundamental problem that needs to be addressed by the community if MDE is to gain widespread use. In this vision paper, we explore how and where UX fits into MDE by considering motivating use cases that revolve around different dimensions of integration: model integration, tool integration, and integration between process and tool support. Based on the literature and our collective experience in research and industrial collaborations, we propose future directions for addressing these challenges.

For many people living with conditions such as autism, anxiety manifests so powerfully it has a big impact on quality of life. By investigating the suitability of truly customizable wearable health devices we build on prior research that found each experience of anxiety in people with autism is unique, so 'one-suits all' solutions are not suitable. In addition, users desire agency and control in all aspects of the system. The participative approach we take is to iteratively co-develop prototypes with end users. Here we describe a case study of the co-development of one prototype, a digital stretch wristband that records interaction for later reflection called Snap. Snap has been designed to sit within a platform that allows the distributed and sustainable design, manufacture and data analysis of customizable digital health technologies. We contribute to HCI with (1) lessons learned from a DIY co-development process that follows the principles of modularity, participation and iteration and (2) the potential impact of technology in self-management of anxiety and the broader design implications of addressing unique anxiety experiences.

Organizations increasingly rely on digital tools, such as social media, to harvest public opinion on a variety of issues ranging from brand reputations to political debates. One area in which digital tools have great potential is in consultation on design of public spaces. Public organizations are expected to consult with users of a public space before, during and after occupancy. Digital tools could increase the effectiveness of this consultation because: (i) they are available 24 h and do not rely on the presence of researchers and (ii) data are collected and analysed using automated methods, allowing faster decision-making. Despite these potential advantages, little is understood about how digital and non-digital consultations compare in practice. This paper reports on a live trial with a prototype digital consultation tool called VoiceYourView, which was co-designed with stakeholders and used to canvass opinion on the refurbishment of a major metropolitan library. Over 6 weeks, we used a variety of methods to collect comment from 600 users. VoiceYourView solicits opinion in unprompted form—it does not ask specific questions as in a survey—so users can say anything they like at any time. VoiceYourView carries out real-time analysis of data collected and uses public display screens to summarize comments-to-date in situ. Our research methods focused on observational studies conducted ‘in the wild’: this allowed us to capture user interactions with VoiceYourView in a realistic setting. Our findings indicate that VoiceYourView encouraged more positive feedback than non-digital methods. We also find that positive comments in general contain less actionable information than negative comments, and unprompted comments have similar actionable content to prompted comments. We suggest that this pattern in soliciting more (traditionally difficult to obtain) positive comments with VoiceYourView versus traditional survey methods implies that digital consultation tools of this type can complement existing channels.

Many studies have shown that crowd-support, such as cheering during sport events, can have a positive impact on athletes' performance. However, up until recently this support was only possible if the supporters and the athletes were geographically co-located. Can cheering be done remotely and would this be effective? In this paper we investigate the effect and possibilities of live remote cheering on co-located athletes and online supporting crowds that have a weak social tie and no social tie with the athlete. We recruit 140 online spectators and 5 athletes for an ad-hoc 5km road race. Results indicate that crowds socially closer to the athletes are significantly more engaged in the support. The athletes were excited by live remote cheering from friendsourced spectators and cheering from unknown crowdsourced participants indicating that remote friends and outsourced spectators could be an important source of support.

We have been generally successful for transferring software engineering knowledge to industry through various forms of education. However, many challenges in software engineering training remain. A key amongst these is how best to energise software engineering education with real-world software engineering practices. This paper describes our experience of delivering a radically different approach based on the notion of a Software Design Studio. The Software Design Studio is both a lab for students engaged in conceiving, designing and developing software products as well as an approach for teaching software engineering in the lab which emphasizes practical hands-on work and experimentation. The feedback on the Software Design Studio -- from both staff and students -- has been outstanding. Although the programme is designed as a small, elite programme there is interest to see if the teaching methods can be transferred across to the much larger undergraduate programme in Computer Science. In this paper, we provide a detailed description of how our studio works in practice so that others, thinking of tak-ing a studio or studio-inspired approach, can use in designing their own courses.

Social Software Engineering (Social SE), that is SE aiming to promote positive social change, is a rapidly emerging area. Here, software and digital artefacts are seen as tools for social change, rather than end products or 'solutions'. Moreover, Social SE requires a sustained buy-in from a range of stakeholders and end-users working in partnership with multidisciplinary software development teams often at a distance. This context poses new challenges to software engineering: it requires both an agile approach for handling uncertainties in the software development process, and the application of participatory, creative design processes to bridge the knowledge asymmetries and the geographical distances in the partnership. This paper argues for the role of design thinking in Social SE and highlights its implications for software engineering in general. It does so by reporting on the contributions that design thinking -- and in particular physical design -- has brought to (1) the problem space definition, (2) user requirements capture and (3) system feature design of a renewable energy forecasting system developed in partnership with a remote Scottish Island community.

There is growing research interest in exploring how biometric data is and can be shared across online social networks. However, most existing tools for sharing biometric data lock researchers into vendor-specific solutions that cannot be easily adapted to the specific researchers' requirements, users' needs and ethical considerations.

This paper presents Clasp, a novel tactile anxiety management, communication and peer support tool developed with, by and for adults diagnosed with High Functioning Autism (HFA). Clasp connects a tactile anxiety coping device to a smartphone, which records and communicates anxiety levels for self-feedback and reflection. By adopting an iterative prototyping approach, we gained a deep insight into anxiety experienced by adults with HFA and evaluated the role of digital technology in its management. The paper describes our development approach, which we argue is unique to this multidisciplinary and multiorganizational design context involving hard-to-reach and vulnerable groups. Finally, we reflect on lessons learned from this process and share a set of design implications for the future development of digital tools that, like Clasp, are specifically designed with, by and for adults with HFA.

Studio-based learning for software engineering is a well-received concept, despite its apparent lack of uptake across institutions worldwide. Studio education affords a variety of highly desirable benefits, and is also popular amongst its students. This paper presents Lancaster University's software engineering studio, details of its implementation, observations made throughout its first year, evidence of its successes, and reflections against the recently defined studio framework. This paper aims to provide useful information for anyone that is considering utilizing a studio-based approach.

Context: Hutchinson et al. conducted an interview-based study of how model-driven engineering, MDE, is practiced in 17 companies. Their results include that successful MDE companies develop domain-specific languages; are motivated by a clear business case; and are committed at all levels of the organization. Goal: Whilst the results are useful, the study is a very broad one, with one or two interviewees per company. This paper supplements Hutchinson's study by focusing on three large companies that are applying MDE and undergoing a parallel transition to agile methods. Method: Formal data collection strategies -- 25 semi-structured interviews, observations and progress meetings -- were combined with informal interaction. The data was analysed both inductively for new insights and deductively for comparison with the results of Hutchinson et al. Results: Our findings show how MDE can include domain experts in software development and how agile development and MDE can coexist. In general our results validate the findings of Hutchinson et al. There are two areas where our results differ -- the engineers' sense of control and the appropriateness of their skills and training. Conclusions: Using a combination of data collection strategies and analysis techniques our study casts new light on earlier research as well as contributes with novel insights regarding the adoption of MDE.

The diary method has been adopted for recording participants' behaviours. However, recording diary entries can be difficult or deemed inappropriate in certain situations, like in a social group or in a meeting. In this demo we present SqueezeDiary, a tool that adopts squeeze gestures for users to denote triggers of diary events, and the users reflect on the triggers later when they are not busy (e.g. during lunch). Our application enables delayed reflection, where users can reflect on their recorded event instances retrospectively during their downtime.

A number of studies in the literature have looked into the use of real-time biometric data to improve one's own physiological performance and wellbeing. However, there is limited research that looks into the effects that sharing biometric data with others could have on one's social network. Following a period of research on existing mobile applications and prototype testing, we developed a system, HeartLink, which collects real-time personal biometric data such as heart rate and broadcasts this data online. Insights gained on designing systems to broadcast real-time biometric data are presented. In this paper we also report emerging results from testing HeartLink in a pilot study and a user study that were conducted during sport events. The results showed that sharing heart rate data does influence the relationship of the persons involved and that the degree of influence seems related to the tie strength prior to visualizing the data.

Studio-based teaching is a method commonly used in arts and design that emphasizes a physical "home" for students, problem-based and peer-based learning, and mentoring by academic staff rather than formal lectures. There have been some attempts to transfer studio-based teaching to software engineering education. In many ways, this is natural as software engineering has significant practical elements. However, attempts at software studios have usually ignored experiences and theory from arts and design studio teaching. There is therefore a lack of understanding of what "studio" really means, how well the concepts transfer to software engineering, and how effective studios are in practice. Without a clear definition of "studio", software studios cannot be properly evaluated for their impact on student learning nor can best and worst practices be shared between those who run studios. In this paper, we address this problem head-on by conducting a qualitative analysis of what "studio" really means in both arts and design. We carried out 15 interviews with a range of people with studio experiences and present an analysis and model for evaluation here. Our results suggest that there are many intertwined aspects that define studio education, but it is primarily the people and the culture that make a studio. Digital technology on the other hand can have an adverse effect on studios, unless properly recognised.

Composition code defines the binding of two or more modules in a program. Post object-oriented programming techniques are increasingly providing expressive mechanisms to enable the flexible definition of composition code. Such composition mechanisms are intended to support programmers in factoring out the complexity of a program and facilitate its evolution. However, the properties of composition code might introduce new flavours of complexity, and in turn cause side effects on program evolvability. Unfortunately, the role of composition code properties on evolving software systems is not yet well understood. This gap is mostly due to the lack of a measurement framework to characterize and quantify composition code. Existing metrics suites are focused on quantifying properties of programs and their modules only. Therefore, programmers are not able to analyse and understand the impact of particular composition properties on program evolvability. This paper presents a framework aimed at characterizing and computing composition code properties. The proposed framework consists of terminology and a metrics suite, which can be used in programs structured with diverse sets of composition mechanisms. We also empirically studied the role of the measurement framework through 22 versions of 4 software projects. Our evaluation revealed that the measurement framework provided consistent indicators of program instabilities observed in history of the evolving compositions

Software engineering is a team activity yet the programmer's key tool, the IDE, is still largely that of a soloist. This paper describes the vision, implementation and initial evaluation of CoffeeTable - a fully featured research prototype resulting from our reflections on the software design process. CoffeeTable exchanges the traditional IDE for one built around a shared interactive desk. The proposed solution encourages smooth transitions between agile and traditional modes of working whilst helping to create a shared vision and common reference frame - key to sustaining a good design. This paper also presents early results from the evaluation of CoffeeTable and offers some insights from the lessons learned. In particular, it highlights the role of developer tools and the software constructions that are shaped by them.

In this paper, we attempt to address the relative absence of empirical studies of model driven engineering through describing the practices of three commercial organizations as they adopted a model driven engineering approach to their software development. Using in-depth semi-structured interviewing we invited practitioners to reflect on their experiences and selected three to use as exemplars or case studies. In documenting some details of attempts to deploy model driven practices, we identify some 'lessons learned', in particular the importance of complex organizational, managerial and social factors - as opposed to simple technical factors - in the relative success, or failure, of the endeavour. As an example of organizational change management the successful deployment of model driven engineering appears to require: a progressive and iterative approach; transparent organizational commitment and motivation; integration with existing organizational processes and a clear business focus.

This paper presents some initial results from a twelve-month empirical research study of model driven engineering (MDE). Using largely qualitative questionnaire and interview methods we investigate and document a range of technical, organizational and social factors that apparently influence organizational responses to MDE: specifically, its perception as a successful or unsuccessful organizational intervention. We then outline a range of lessons learned. Whilst, as with all qualitative research, these lessons should be interpreted with care, they should also be seen as providing a greater understanding of MDE practice in industry, as well as shedding light on the varied, and occasionally surprising, social, technical and organizational factors that affect success and failure. We conclude by suggesting how the next phase of the research will attempt to investigate some of these issues from a different angle and in greater depth.

This paper reports on VoiceYourView, a kind of intelligent kiosk, which uses speech recognition and natural language processing to gather the public's creative input on the public space designs. Over a six week period, VoiceYourView was deployed in a public space and 2000 design critiques were collected from 600 people. The paper shows that people are capable of providing creative input on their environment using unstructured speech or text and that a good proportion of these comments are actionable. The paper also investigates the use of public displays to auto-summarize comments left by the public so far. Although there is anecdotal evidence that this encourages participation, an experiment found that filtering comments (e.g., to display only positive responses) had no effect on what people had to say.

Computational reflection is a well-established technique that gives a program the ability to dynamically observe and possibly modify its behaviour. To date, however, reflection is mainly applied either to the software architecture or its implementation. We know of no approach that fully supports requirements reflection- that is, making requirements available as runtime objects. Although there is a body of literature on requirements monitoring, such work typically generates runtime artefacts from requirements and so the requirements themselves are not directly accessible at runtime. In this paper, we define requirements reflection and a set of research challenges. Requirements reflection is important because software systems of the future will be self-managing and will need to adapt continuously to changing environmental conditions. We argue requirements reflection can support such self-adaptive systems by making requirements first-class runtime entities, thus endowing software systems with the ability to reason about, understand, explain and modify requirements at runtime.

Requirements are sensitive to the context in which the system-to-be must operate. Where such context is well understood and is static or evolves slowly, existing RE techniques can be made to work well. Increasingly, however, development projects are being challenged to build systems to operate in contexts that are volatile over short periods in ways that are imperfectly understood. Such systems need to be able to adapt to new environmental contexts dynamically, but the contextual uncertainty that demands this self-adaptive ability makes it hard to formulate, validate and manage their requirements. Different contexts may demand different requirements trade-offs. Unanticipated contexts may even lead to entirely new requirements. To help counter this uncertainty, we argue that requirements for self-adaptive systems should be run-time entities that can be reasoned over in order to understand the extent to which they are being satisfied and to support adaptation decisions that can take advantage of the systems' self-adaptive machinery. We take our inspiration from the fact that explicit, abstract representations of software architectures used to be considered design-time-only entities but computational reflection showed that architectural concerns could be represented at run-time too, helping systems to dynamically reconfigure themselves according to changing context. We propose to use analogous mechanisms to achieve requirements reflection. In this paper we discuss the ideas that support requirements reflection as a means to articulate some of the outstanding research challenges.

There are many examples in the literature of algorithms for synthesizing state machines from scenario-based models. The motivation for these is to automate the transition from scenario-based requirements to early behavioral design models. To date, however, these synthesis algorithms have tended to generate flat state machines which can be difficult to understand or adapt for practical systems. One of the reasons for this is that relationships between scenarios are often not taken into account during synthesis—either because the relationships are not explicitly defined or because the synthesis algorithms are not sophisticated enough to cope with them. If relationships are not considered, it is impossible for a synthesis algorithm to know, for example, where one scenario stops and another continues. Furthermore, the lack of relationships makes it difficult to introduce structure into the generated state machines. With the introduction of interaction overview diagrams (IODs) in UML2.0, relationships such as continuation and concurrency can now be specified between scenarios in a way that conforms to the UML standard. But synthesis algorithms do not currently exist that take into account all of these relationships. This article presents a novel synthesis algorithm for an extended version of interaction overview diagram. This algorithm takes into account not only continuation and concurrency, but also preemption, suspension and the notion of a negative scenario. Furthermore, the synthesis algorithm generates well-structured state machines. These state machines are executable and can therefore be used to validate the scenarios. The hierarchy generated aids readability and so the state machines are more amenable to subsequent design steps. Our IOD extensions have a formal semantics and are supported by a synthesis and execution tool, UCSIM, which is currently provided as a plug-in to IBM Rational Software Modeler.

It is often claimed that inaccurate modularisation of crosscutting concerns hinders program comprehension and, as a consequence, leads to harmful software instabilities. However, recent studies have pointed out that crosscutting concerns are not always harmful to design stability. Hence, software maintainers would benefit from well documented patterns of crosscutting concerns and a better understanding about their actual impact on design stability. This paper presents a catalogue of crosscutting concern patterns recurrently observed in software systems. These patterns are described and classified based on an intuitive vocabulary that facilitates their recognition by software engineers. We analysed instances of the crosscutting patterns in object-oriented and aspect-oriented versions of three evolving programs. The outcomes of our exploratory evaluation indicated that: (i) a certain category of crosscutting patterns seems to be good indicator of harmful instabilities, and (ii) aspect-oriented solutions were unable to modularise concerns matching some crosscutting patterns.

Interactions between dependent or conflicting aspects are a well-known problem with aspect-oriented development (and related paradigms). These interactions are potentially dangerous and can lead to unexpected or incorrect results when aspects are composed. To date, most aspect interaction detection methods have been based either on purely syntactic comparisons or have relied on heavyweight formal methods. We present a new approach that is based instead on lightweight semantic annotations of aspects. Each aspect is annotated with domain-specific markers and a separate influence model describes how semantic markers from different domains influence each other. Automated analysis can then be used both to highlight semantic aspect conflicts and to trade-off aspects. We apply this technique to early aspects, namely, aspect scenarios, because it is desirable to detect aspect interactions as early in the software lifecycle as possible. We evaluate the technique using an industrial case study and show that the technique detects interactions that cannot be discovered using syntactic techniques.

Self-adaptive systems have the capability to autonomously modify their behaviour at run-time in response to changes in their environment. Self-adaptation is particularly necessary for applications that must run continuously, even under adverse conditions and changing requirements; sample domains include automotive systems, telecommunications, and environmental monitoring systems. While a few techniques have been developed to support the monitoring and analysis of requirements for adaptive systems, limited attention has been paid to the actual creation and specification of requirements of self-adaptive systems. As a result, self-adaptivity is often constructed in an ad-hoc manner. In this paper, we argue that a more rigorous treatment of requirements explicitly relating to self-adaptivity is needed and that, in particular, requirements languages for self-adaptive systems should include explicit constructs for specifying and dealing with the uncertainty inherent in self-adaptive systems. We present RELAX, a new requirements language for self-adaptive systems and illustrate it using examples from the smart home domain.

Crosscutting concerns can hinder maintainability of a design because they do not adhere to a system's underlying modular structure. Developers, therefore, may wish to refactor designs to improve modularisation or to implement crosscutting concerns as aspects. However, few tools currently exist that assist developers in detecting and classifying crosscutting concerns in their code. Classification is important because, as recent studies have shown, crosscutting concerns are not always harmful. This paper describes a tool, ConcernMorph, for identifying crosscutting concerns and classifying them into one of a number of predefined crosscutting patterns.

Misuse cases are a way of modeling negative requirements, that is, behaviors that should not occur in a system. In particular, they can be used to model attacks on a system as well as the security mechanisms needed to avoid them. However, like use cases, misuse cases describe requirements in a high-level and informal manner. This means that, whilst they are easy to understand, they do not lend themselves to testing or analysis. In this paper, we present an executable misuse case modeling language which allows modelers to specify misuse case scenarios in a formal yet intuitive way and to execute the misuse case model in tandem with a corresponding use case model. Misuse scenarios are given in executable form and mitigations are captured using aspect-oriented modeling. The technique is useful for brainstorming potential attacks and their mitigations. Furthermore, the use of aspects allows mitigations to be maintained separately from the core system model. The paper, supported by a UML-based modeling tool, describes an application to two case studies, providing evidence that the technique can support red-teaming of security requirements forn realistic systems.

This paper proposes a framework for Composite Alternative Recommendation Development (CARD), which supports composite product and service definitions, top-k decision optimization, and dynamic preference learning. Composite services are characterized by a set of sub-services, which, in turn, can be composite or atomic. Each atomic and composite service is associated with metrics, such as cost, duration, and enjoyment ranking. The framework is based on the Composite Recommender Knowledge Base, which is composed of views, including Service Metric Views that specify services and their metrics; Recommendation Views that specify the ranking definition to balance optimality and diversity; parametric Transformers that specify how service metrics are defined in terms of metrics of its subservices; and learning sets from which the unknown parameters in the transformers are iteratively learned. Also introduced in the paper is the top-k selection criterion that, based on a vector of utility metrics, provides the balance between the optimality of individual metrics and the diversity of recommendations. To exemplify the framework, specific views are developed for a travel package recommender system.

Aspect-oriented software development (AOSD) provides effective modularization and composition mechanisms and can be applied at any stage of the software lifecycle. Aspect composition is a crucial feature of AOSD since it allows a developer to get an overall understanding of a system and better analyze the impact of a concern to a set of other concerns. The effort involved in composition, however, may vary depending on the lifecycle stage at which it is applied. This paper compares two methods of composing aspects during the early stages of the lifecycle. In both cases, scenarios and aspectual scenarios are developed for concerns and aspects, respectively. In the first method, the aspectual scenarios are composed immediately. In the second one, they are composed only after the scenarios have been converted to individual object behavioral descriptions. A comparison of the composition effort involved is made based on results of a case study

SCESM '06 is the 5th International Workshop on Scenarios and State Machines: Models, Algorithms and Tools. It is a one day ICSE '06 workshop. Details about SCESM '06 may be found at http://ise.gmu.edu/scesm06/.

There are many examples, in the literature, of algorithms for synthesizing state machines from scenario-based models. The motivation for these is to automate the transition from scenario-based requirements to early analysis and design models. A major challenge for such algorithms, however, is that the relationships between scenarios are usually not explicitly defined. This means that synthesis algorithms have to infer the relationships and this cannot generally be done without also inferring false positives. An alternative is to require users to explicitly give scenario relationships. The challenge here is that the additional burden placed on the user must be less than the effort saved by automatic synthesis. In this paper, we address this problem by defining a synthesis algorithm for use case charts, a language for precisely describing use cases and their relationships. Use case charts are sufficiently precise to allow the automatic generation of hierarchical state machines but retain the benefits of existing scenario-based notations by being based on UML. Use case charts provide an easy way of specifying scenario relationships but also have a formal semantics that can be used both in synthesis and to execute the use case charts. This paper presents the synthesis algorithm for use case charts and illustrates it on a significant example based on students' solutions to an analysis and design problem

The development of a family of applications in a domain can be greatly eased if patterns in the domain are systematically reused. Systematic use of such patterns can be achieved by tools that support the specification of patterns and their instantiation in a specific application context. In this paper, we present a prototype tool called RBML-Pattern Instantiator (RBML-PI) that generates application-specific UML class diagrams and sequence diagrams from a pattern specification described in the Role-Based Metamodeling Language (RBML), a pattern specification language defining a domain-specific sub-language of the UML. We give an overview of the RBML using the Visitor design pattern, and demonstrate the tool using an RBML specification for the CheckIn-CheckOut (CICO) domain pattern that specifies services to check in and check out items. We use the CICO pattern specification to generate an application-specific UML model of a library system using RBML-PI.

EHAVIOR models play a key role in the engineering of software-basedsystems.Theyarethebasisforsystematic approaches to requirements elicitation, specification, architecture design, simulation, code generation, and verification and validation. A range of notations, techniques, and tools supporting behavior modeling for these development tasks have been suggested. Underlying these notations, techniques, and tools, two complementary approaches to modeling behavior can be identified: interaction-based and state-based modeling. Interaction-based modeling focuses on the interactions between actors and components in a system. Consequently, communication between such entities is viewed as the principal modeling construct. Interaction modeling, commonly realized using scenario and use case techniques, provides an overall view of a system which is particularly suited for supporting communication between project

autofilter is a tool that generates implementations that solve state estimation problems using Kalman filters. From a high-level, mathematics-based description of a state estimation problem, autofilter automatically generates code that computes a statistically optimal estimate using one or more of a number of well-known variants of the Kalman filter algorithm. The problem description may be given in terms of continuous or discrete, linear or nonlinear process and measurement dynamics. From this description, autofilter automates many common solution methods (e.g., linearization, discretization) and generates C or Matlab code fully automatically. autofilter surpasses toolkit-based programming approaches for Kalman filters because it requires no low-level programming skills (e.g., to "glue" together library function calls). autofilter raises the level of discourse to the mathematics of the problem at hand rather than the details of what algorithms, data structures, optimizations and so on are required to implement it. An overview of autofilter is given along with an example of its practical application to deep space attitude estimation.

Two high profile workshops at OOPSLA and ICSE, an IEEE Computer article by David Harel and a growing number of research papers have all suggested algorithms that translate scenarios of a system's behavior into state machines. One of the uses of such algorithms is in the transition from requirements scenarios to component design. To date, however, most efforts have concentrated on the algorithmic details of the proposed translations. Less work has been done on evaluating these algorithms on a realistic case study. In this paper, we do exactly that for the algorithm presented in [10]. Our study is a component of an air traffic advisory system developed at NASA Ames Research Center.

We present a technique for certifying domain-specific properties of code generated using program synthesis technology. Program synthesis is a maturing technology that generates code from high-level specifications in particular domains. For acceptance in safety-critical applications, the generated code must be thoroughly tested which is a costly process. We show how the program synthesis system AUTOFILTER can be extended to generate not only code but also proofs that properties hold in the code. This technique has the potential to reduce the costs of testing generated code.

Abstract. C Y NTHIA is a transformation-based editor for a functional subset of ML that lies somewhere between a structure editor and a framework for formal program development. Users construct programs from existing code by applying editing commands that make a semantic analysis of the program's behaviour, e.g., whether it is terminating. All analysis is done using the Oyster system, which is an implementation of proofs-as-programs. We concentrate on identifying analyses that can be done fully automatically (e.g., using a decision procedure) and hence can be hidden from the user. As a result, C Y NTHIA represents progress towards a goal of program editors that make an intelligent analysis of their code, but in a way that requires no extra input from the programmer.

Previous work on domain-specific deductive program synthesis described the Amphion/NAIF system for generating Fortran code from high-level graphical specifications describing problems in space system geometry. Amphion/NAIF specifications describe input-output functions that compute geometric quantities (e.g., the distance between two planets at a point in time, or the time when a radio communication path between a spacecraft and earth is occluded) by composing together Fortran subroutines from the NAIF subroutine library developed at the Jet Propulsion Laboratory. In essence, Amphion/NAIF synthesizes code for glueing together the NAIF components in a way such that the generated code implements the specification, with a concurrently generated proof that this implementation is correct. Amphion/NAIF demonstrated the success of domain-specific deductive program synthesis and is still in use today within the space science community. However, a number of questions remained open that we will attempt to answer in this paper.

This paper presents an algorithm for automatically generating UML statecharts from a collection of UML sequence diagrams. Computer support for this transition between requirements and design is important for a successful application of UML's highly iterative, distributed software development process. There are three main issues which must be addressed when generating statecharts from sequence diagrams. Firstly, conflicts arising from the merging of independently developed sequence diagrams must be detected and resolved. Secondly, different sequence diagrams often contain identical or similar behaviors. For a true interleaving of the sequence diagrams, these behaviors must be recognized and merged. Finally, generated statecharts usually are only an approximation of the system and thus must be hand-modified and refined by designers. As such, the generated artifact should be highly structured and readable. In terms of statecharts, this corresponds to the introduction of hierarchy. Our algorithm successfully tackles all three of these aspects and will be illustrated in this paper with a well-known ATM example.

Formal methods, whereby a system is described and/or analyzed using precise mathematical techniques, is a well -established and yet, under-used approach for developing software systems. One of the reasons for this is that project deadlines often impose an unsatisfactory development strategy in which code is produced on an ad-hoc basis without proper thought about the requirements and design of the piece of software in mind. The result is a large, often poorly documented and un-modular monolith of code, which does not lend itself to formal analysis. Because of their complexity, formal methods work best when code is well structured, e.g., when they are applied at the modeling level. UML is a modeling language that is easily learned by system developers and, more importantly, an industry standard, which supports communication between the various project stakeholders. The increased popularity of UML provides a real opportunity for formal methods to be used on a daily basis within the software lifecycle. Unfortunately, the lack of preciseness of UML means that many formal techniques cannot be applied directly. If formal methods are to be given the place they deserve within UML, a more precise description of UML must be developed. This article surveys recent attempts to provide such a description, as well as techniques for analyzing UML models formally.

Deductive retrieval and deductive synthesis are two conceptually closely related software development methods which apply theorem proving techniques to support the construction of correct programs. In this paper, we describe an integration of both methods which combines their complementary benefits and alleviates some of their drawbacks. The core of our integration is an algorithm which automatically extracts queries from the synthesis proof state and submits them to a specialized retrieval system. Retrieved components are then used to close open subgoals in the proof. We use a higher-order framework for synthesis in which higher-order meta-variables are used to represent program fragments still to be synthesized. Hence, the introduction of a new meta-variable is an attempt to synthesize a new fragment and so highlights a possible reuse step. This observation allows us to invoke retrieval only after a substantial change rather than at every proof step and prevents overloading the retrieval mechanism. Our integration raises the granularity level of synthesis by avoiding a substantial number of proof steps. It also provides a framework for adapting "near-miss" components in the case that an exact match cannot be retrieved.

C/sup Y/NTHIA is a novel editor for the functional programming language ML in which each function definition is represented as the proof of a simple specification. Users of C/sup Y/NTHIA edit programs by applying sequences of high-level editing commands to existing programs. These commands make changes to the proof representation from which a new program is then extracted. The use of proofs is a sound framework for analysing ML programs and giving useful feedback about errors. Amongst the properties analysed within C/sup Y/NTHIA at present is termination. C/sup Y/NTHIA has been successfully used in the teaching of ML in two courses at Napier University, Scotland. C/sup Y/NTHIA is a convincing, real-world application of the proofs-as-programs idea.