There aren't any silver bullets in software development, and there probably never will be. However, Extreme Programming is a simple set of common-sense practices that, when used together, really can give you much of what you just read in the paragraph above. In this book, we tell you what the XP practices are, and how to install them in your project.

Factory AbstractFactory CreateProduct() Builder Builder BuildPart() Command Command Execute() Interprete r AbstractExpression Interpret() Observer Observer Update() Prototype Prototype Clone() State State Handle() Strategy Strategy AlgorithmInterface() 2000, M. Fontoura, W. Pree, B. Rumpe ECOOP, Cannes, June 2000 16 Recursive combinations These patterns allow building of directed graphs of interconnected objects message forwarding in the object graphs due to a certain structure of the template method The playground of adaptations through composition is enlarged TH 1 H T 2000, M. Fontoura, W. Pree, B. Rumpe ECOOP, Cannes, June 2000 17 GoF catalog entries based on recursive compositions Composite, Decorator, and Chain of Responsibility: (and Unification, Separation are the 5 essential patterns) H T 1 H T * TH 1 2000, M. Fontoura, W. Pree, B. Rumpe ECOOP, Cannes, June 2000 18 Essential patterns scale up What is a template method in one context may become a hoo...

Goal- and agent-oriented models have become a consolidated type of artifact in various software and knowledge engineering activities. Several languages exist for representing such type of models but there is a lack of associated methodologies for guiding their construction up to the necessary level of detail. In this paper we present RiSD, a method for building Strategic Dependency (SD) models in the i∗ notation. RiSD is defined in a prescriptive way to reduce uncertainness when constructing the model. RiSD tackles three fundamental issues: (1) it tends to reduce the average size of the resulting models; (2) it defines some traceability relationships among model elements; (3) it provides some lexical and syntactical conventions. As a result, we may say that RiSD supports the construction process of goal- and agent-oriented models whilst increasing their understanding.

A great deal of effort is needed to construct software products in a predictable and repeatable manner. Having a precisely defined methodology in place can certainly help, especially if it includes the comprehensive specification of the process to be followed and the work products to be created. However, a convenient integration of these two aspects (process and work product) has not yet been performed. This paper presents a new approach to the definition of methodologies that supports the process and work product domains concurrently through the specification of discrete methodology elements. Some of these elements, called here templates, are designed to be instantiated during the use of the methodology in specific projects, while others, called resources, are intended to be used directly. Theoretical and practical implications of this division, especially regarding metamodelling and the use of powertypes, are explored. The proposed metamodelling approach is shown to facilitate the precise and complete specification of comprehensive methodologies, establishing the foundations for predictable and repeatable results from software development. 1

When the user interface (UI) has to be specified, a picture is worth a thousand words and the worst thing a humancomputer interaction (HCI) expert can do is attempt to write a natural language specification for it. Nevertheless, this practice is still common and it is therefore a difficult task to move from text-based requirements and problemspace concepts to a final UI design, and then back again. Especially for the specification of interactive UIs, however, HCI experts must frequently switch between high-level descriptions and detailed screens. In our research we found that advanced UI specifications therefore have to be made up of interconnected artefacts that have distinct levels of abstraction. With regards to the transparency and traceability of the rationale of the UI

Abstract: When the user interface is specified, a picture is worth a thousand words, and the worst thing one can do is write a natural-language specification for it. Because this practice is still common, it is a challenging task to move from text-based requirements and problem-space concepts to a final UI design, and then back again. However, this activity is required frequently and is necessary to drive creative ideas. In our research we found that advanced UI specifications should therefore be made up of interconnected artefacts that have distinct levels of abstraction. With regards to the transparency and traceability of the rationale of the specification process, transitions and dependencies must be visual and traversable. For this purpose, we introduce a model-based user interface specification method and a corresponding experimental tool that interactively integrates interdisciplinary and informal models with different levels of fidelity of user-interface prototyping. With innovative styles of interaction and user input, our proposed tool supports the collaboration required in a multidisciplinary context.

– Basic modeling tags Basic modeling concepts – Essential pattern tags Annotating 5 essential patterns – Catalog & domain-specific pattern tags – UML-F & adaptation cookbooks

In this paper we report a survey examining the approach to performance and software engineering in courses at highly ranked computer science schools in the United States. An analysis of the survey shows serious shortcomings including inadequate or missing definitions of performance, reactive ”fix it later ” mentality, vague performance requirements, and a general lack of awareness of the practices developed by the Software Performance Engineering (SPE) community. The survey is followed by guidelines for teaching SPE to undergraduates based on a semester long course we have developed. It is our plan to incorporate these guidelines into the curriculum of our senior capstone software engineering course.

Several years of experience with the functional language Erlang have learned Ericsson that it is highly beneficial to use this language for programming control software for large systems. Systems that could not be built before, have been constructed in less time and with fewer lines of code than one would need with conventional languages. The success of Ericsson in the business area of telephone switches is partly because of their solid fault tolerant architecture, both in hardware and in software. A lot of time and money have been invested in the development of this fault tolerant architecture, all to catch these errors that are overlooked in numerous tests. By using Erlang and its extensive libraries, the number of these uncaught errors decreases; the fault recovery mechanism of the system is used less. One saves on maintenance costs and the overall performance of a system increases. The additional use of formal verifiation aims on reducing even more the number of uncaught errors.

Abstract: Modern software development business, as a very dynamic and often risky process, imposes new approaches to planning and organisation of the work. At present, a typical team can apply one of the agile methodologies, among which RUP and XP are the most common. They are both well-established and proven in practice, but nowadays it is clear that they cannot respond to all the new challenges separately. The gap between them leaves uncovered exactly those issues that mostly affect small and middle-size projects, which are the majority of all projects in modern business. This paper proposes an integral process, a combination of RUP and XP, which should be more convenient for small and middle-size projects than RUP or XP alone. Generally, it anticipates less documentation than RUP and suggests more planning than XP, trying to adopt the best form of both and adjust them to the modern business. Properly applied, the proposed process should be more acceptable and more efficient than other similar methods.