The Role of ¨Roles¨ in Use Case Diagrams

Use cases are the modeling technique of UML for formalizing the functional requirements placed on systems. This technique has limitations in modeling the context of a system, in relating systems involved in a same business process, in reusing use cases, and in specifying various constraints such as execution constraints between use case occurrences. These limitations can be overcome to some extent by the realization of multiple diagrams of various types, but with unclear relationships between them. Thus, the specification activity becomes complex and error prone. In this paper, we show how to overcome the limitations of use cases by making the roles of actors explicit. Interestingly, our contributions not only make UML a more expressive specification language, they also make it simpler to use and more consistent

The emergent roles of a designer in the development of an e learning service

This paper presents reflections from a service design case study and uses it to investigate the emerging roles of a designer. Skills, methodologies and values are drawn through the case study and used to communicate how this contributes to the continuing expansion of the profession today. Seven roles are discussed in this paper: designer as a facilitator, communicator, capability builder, strategist, researcher, entrepreneur and co-creator. The analysis of the activities of the designer in this particular case study has indicated a presence of all of these roles in various degrees. This brings up three key questions for discussion: 1. How can the design profession communicate the value of this role shift to external audiences? 2. How will design education address the requirements of these emerging roles? and more relevant to this workshop, 3. How will businesses utilise these additional skills of a designer

Designing requirements engineering research

Engineering sciences study different different topics than natural sciences, and utility is an essential factor in choosing engineering research problems. But despite these differences, research methods for the engineering sciences are no different than research methods for any other kind of science. At most there is a difference in emphasis. In the case of requirements engineering research - and more generally software engineering research - there is a confusion about the relative roles of research and about design and the methods appropriate for each of these activities. This paper analyzes these roles and provides a classification of research methods that can be used in any science—engineering or otherwise

Automatic extraction of heap reference properties in object-oriented programs

We present a new technique for helping developers understand heap referencing properties of object-oriented programs and how the actions of the program affect these properties. Our dynamic analysis uses the aliasing properties of objects to synthesize a set of roles; each role represents an abstract object state intended to be of interest to the developer. We allow the developer to customize the analysis to explore the object states and behavior of the program at multiple different and potentially complementary levels of abstraction. The analysis uses roles as the basis for three abstractions: role transition diagrams, which present the observed transitions between roles and the methods responsible for the transitions; role relationship diagrams, which present the observed referencing relationships between objects playing different roles; and enhanced method interfaces, which present the observed roles of method parameters. Together, these abstractions provide useful information about important object and data structure properties and how the actions of the program affect these properties. We have implemented the role analysis and have used this implementation to explore the behavior of several Java programs. Our experience indicates that, when combined with a powerful graphical user interface, roles are a useful abstraction for helping developers explore and understand the behavior of object-oriented programs

Roles and responsibilities in agile ICT for development

This paper examines the different roles in designing interactive software in a ICT for development context. Using experiences from a participatory action research project, in which we used agile methods to design and deploy an system to support ‘agricultural information flow’ for a co-operative of small farmers in rural India, we identify points of difference between the roles in standard descriptions of agile software methods and the roles as they emerged in our project. A key finding is the critical role played by a ‘Development Project Manager’ in facilitating dialogue, orchestrating the activities of other actors and in building the capabilities and confidence of all the participants in joint action

Exploring roles and relationships in the production of the built environment

Given the number of different agencies and the complexity of institutional and professional relationships in the production, management and regulation of the built environment, many students entering built environment professions leave university education to take up work placements or employment without a sufficient understanding of the different actors and the formal and informal interactions and social relationships between them. Furthermore, destructive stereotypes may form during the educational process as students construct their own professional identity, in part learnt from their teachers and peers, and naturalised by the academic and professional institutions that form the context of their education – a process of enculturation termed ‘professional socialization’ by social scientists (Cuff, 1991: 118). These stereotypes may lead ultimately to inter-professional tensions and hostilities. Innovations in practice often involve challenges to established roles or joined-up thinking which breaches institutional structures, for all of which graduates may be ill-prepared