Please note that no charge is necessary for all registrants to attend APSEC 2007.

Tutorial: Evaluating Product Line Architectures: Methods and Techniques

Muhammad Ali Babar (Lero, University of Limerick, Ireland)
December 4 2007, 10:00 to 13:00 (3 hours)
Good software architecture is one of the key factors in successfully developing and evolving a system or a family of systems. Software architecture provides the key framework for the earliest design decisions taken to achieve functional and quality requirements. In addition, it has a profound influence on project organizations' functioning and structure. Poor architecture usually results in project inefficiencies, poor communication, and poor decision making. Software architecture for a family of systems also helps identify the commonality among different systems and explicitly document variability. Since software architecture plays a significant role in the life of a system, it is important to evaluate a system's architecture as early as possible. Architecture evaluation is considered one of the most important and effective techniques of addressing quality related issues at the software architecture level and mitigating architectural risks. Moreover, architecture evaluation sessions are an effective means of sharing and capturing architecture design rationale, reasoning behind architecture design decisions. This tutorial highlights the benefits and challenges in evaluating software architectures. It discusses theoretical and practical concepts underpinning some of the well-known scenario-based architecture evaluation methods and various approaches to characterize quality attributes using scenarios. The use of the presented methods, techniques, and tools will be demonstrated with a case study based on an industrial project.

Tutorial: The Problem Frames Approach to Software Engineering

Michael Jackson (The Open University, UK)
December 4 2007, 14:00 to 17:00 (3 hours)
Software-intensive systems are those in which the computer executing the software is only one of the parts of the system. Problem frames offer a conceptual structure for the development of such systems: that is, a coherent way of analysing the problem to be solved, identifying the concerns and difficulties that it poses, and working towards a solution. This tutorial will present the basic ideas of problem frames, illustrating them in the context of a small software-intensive system.
The basic ideas of the approach are:
  1. to attend both to the hardware/software machine, which is to be developed, and to the other system parts, which constitute the problem world;
  2. to distinguish the given properties of the problem world from the requirements, which are the properties that the machine must establish and maintain in the world;
  3. to pay careful attention to the phenomena of the problem world;
  4. to structure the development problem as a set of subproblems, and to consider each subproblem in isolation before considering the composition of the subproblems and their solutions;
  5. so far as possible, to recognise each subproblem as a member of a recognised class for which a solution method is known and whose most important concerns have been identified.
Problem frames are not a notation or a calculus or a formalism; nor are they a development method or a process. They can fit with, into, or around specific techniques (such as agile or RUP) and specific notations (such as UML, Petri Nets, or DFDs). Problem frames do not promise a prescription for every problem; nor do they promise a complete prescription for any problem. They remind you of things you know already, but may not always pay enough attention to.