|
|||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
 |
|||||||||||||||||||||
|
Monday, March 21 2:00pm Bran Selic
Tuesday, March 22 9:00am Ralf Laemmel
Tuesday, March 22 9:00am Joseph W. Yoder
Tuesday, March 22 2:00pm Gunter Mussbache
Tutorials (Tutorials Program Overview)Understanding Programming Technologies by analogy, examples, and abstraction (Slides) Ralf Laemmel, Universitat Koblenz-Landau, Germany Room: Caboclinhos
Abstract: Given the various technical spaces in IT, given the various programming technologies in and between the spaces, how can \Joe the Student Programmer" ever expect to fundamentally understand those spaces and get a conceptual handle on some of these technologies before he ends up in practice and only gets to understand some per-project piece of space and technology? This tutorial gives a sneak preview of a new course on programming technologies that exactly tries to address this diffiult question. The course covers, for example, X/O/R mapping, different programming paradigms, model-driven engineering, and advanced modularization. The spaces and technologies are associated with metadata and megamodels to support analogy and abstraction. The spacesand technologies are systematically demonstrated with a running example: the 101companies example. Refactoring Course (Slides) Joseph W. Yoder Room: Caboclinhos
Abstract: Refactoring code to make it more maintainable and extendable has become a more mainstream practice. Refactoring is the process of changing software without altering its external behavior. It is done in such as way to improve the structure of the code to allow for later extensions or to make maintenance of the code easier. It is important to refactor your code in a disciplined way to minimize disruptions and to allow the system to safely evolve. Improving a systems structure and readability through refactoring enhances its comprehensibility, readability, and maintainability.
This tutorial will teach attendees how to recognize code smells, or signs that code needs to be refactored. It takes you through some of the common refactorings as provided by tools such as the Refactoring Browser and Eclipse and those outlined in Martin Fowlers Refactoring book, teaching you the correct discipline for refactoring your code. Various code examples will be used to illustrate how and when to refactor. Tools and Testing techniques to support refactoring will also be examined. The class will examine how to apply object-oriented design patterns to guide your refactoring decisions. The Theory and Practice of Modern Modeling Language Design (for Model-Based Software Engineering) (Slides) Bran Selic, Malina Software Corp. Room: Caboclinhos
Abstract: Model-based software engineering (MBSE), while not a panacea, has demonstrated its effectiveness in mitigating some of the most critical design problems in developing complex software systems. This tutorial focuses on a vital component of MBSE: the design of modeling languages and related technologies such as model-to-model transformations and automated code generation. In contrast to traditional programming languages, whose primary purpose is to specify design implementations such that they can be realized by a computer, modeling languages must satisfy a broader set of objectives, since the role of models typically covers more than just specification. This imposes significant challenges for language designers, often requiring expertise beyond what suffices for programming language design. The first part of the tutorial covers the overall MBSE landscape: the rationale behind it, key developments, the current states of the art and practice, the role of modeling languages, and, finally, major open problems. Next, the general structure of modeling languages is described and fundamental design issues are identified. Different approaches to modeling language definition along with supporting technologies are then reviewed, and guidelines for their practical application are given. Standard widespread modeling languages, including EMF, UML, and MOF, are used to illustrate both good and bad design practices. Special emphasis is placed on the design of domain-specific modeling languages. The final part of the tutorial is dedicated to a review of model transformation technologies, including both model-to-model and model-to-code methods. Rulemakers and Toolmakers: Adaptive Object-Models as an Agile Division of Labor (Slides) Joseph W. Yoder Room: Frevo
Abstract: Agile practices liberate us from the straightjackets of top-down design. But, the ease with which requirements can change encourages users to overwhelm us with requests for features. The result: Featuritis, which promotes hasty construction of poorly designed software to support those features. The design of an expressive domain model might get lost in the rush to write working code. Adaptive Object-Models support changeable domain modules by casting business rules as interpreted data and representing objects, properties and relationships in external declarations. Now users can change the system domain models themselves as their business dictates without having to deal with programmers at all. It’s the ultimate in agility! The Aspect-Oriented User Requirements Notation: Aspects, Goals, and Scenarios (Slides) Gunter Mussbacher, University of Ottawa Room: Frevo
Abstract: The User Requirements Notation (URN) is a recent modeling standard, published by the International Telecommunication Union in November 2008, that supports the elicitation, analysis, specification, and validation of requirements. URN is the first standard that combines modeling concepts and notations for goals and intentions (mainly for non-functional requirements, quality attributes, and reasoning about alternatives) and scenarios (mainly for operational requirements, functional requirements, and performance and architectural reasoning). Changes to requirements are inevitable and ideal requirements models should cope with change efficiently. However, crosscutting requirements make changing requirements more difficult, since change impact is more complicated and costly to manage due to scattered and tangled requirements models. Therefore, it is necessary even at the requirements stage to model crosscutting concerns (aspects) independently, but also to compose aspects with other requirements in a way that will allow the entire set of requirements to be analyzed and validated.
In this tutorial, we discuss aspect-oriented requirements models. In particular, we concentrate on goal-based and scenario-based requirements engineering with the Aspect-oriented URN (AoURN). AoURN is an extension to the URN standard and a strong candidate for inclusion in future versions of the standard as it aims to address the aforementioned issues. AoURN allows for a thorough introduction to aspect-oriented requirements engineering, as goals and scenarios are commonly used requirements engineering techniques and AoURN contains two very different modeling notations for goals and scenarios that require tailored approaches for aspect-oriented modeling. Particular emphasis is placed on AoURN's advanced composition mechanisms that allow for interleaved and semantics-enhanced compositions. The definition of aspect-oriented models, however, is only a first step that needs to be complemented by aspect-oriented approaches for any existing analysis and validation techniques. Consequently, the built-in URN analysis techniques for stakeholder trade-offs and scenario test suites are discussed from an aspect-oriented point of view. Modularizing Crosscutting Concerns with Ptolemy (Slides) Hridesh Rajan, Iowa State University Room: Caboclinhos
Abstract: We present Ptolemy, our programming language that improves separation of crosscutting concerns, and its development environment. A crosscutting concern is a requirement whose implementation is spread across and mixed with the code of other requirements. There has been attempts to improve separation of crosscutting concerns, e.g. by aspect-oriented languages and implicit-invocation design style, but none give software developers expressiveness of quantification and modular reasoning at the same time. Ptolemy has both these properties important for scalable software engineering.
|
|||||||||||||||||||||
|
|||||||||||||||||||||
  |
|---|
 |
|
