Domain-Specific Language for Coordination patterns

The integration and composition of software systems requires a good architectural design phase to speed up communications between (remote) components. However, during implementation phase, the code to coordinate such components often ends up mixed in the main business code. This leads to maintenance problems, raising the need for, on the one hand, separating the coordination code from the business code, and on the other hand, providing mechanisms for analysis and comprehension of the architectural decisions once made. In this context our aim is at developing a domain-specific language, CoordL, to describe typical coordination patterns. From our point of view, coordination patterns are abstractions, in a graph form, over the composition of coordination statements from the system code. These patterns would allow us to identify, by means of pattern-based graph search strategies, the code responsible for the coordination of the several components in a system. The recovering and separation of the architectural decisions for a better comprehension of the software is the main purpose of this pattern language

Contribution towards a reflection about methodological strategies in design education and the function of drawing in design

This work presents a reflection on Design education and specifically on the role of Drawing in this area. As a subject, Design has expanded its field of action expanding into new areas such as Experience Design or Service Design. It became necessary for the designer to have more than an education based on technological knowledge or know-how. Many authors like Meredith Davis, Don Norman or Jamie Hobson point out the urgency to review the curricula of Design courses because nowadays “… design is more than appearance, design is about interaction, about strategy and about services. Designers change social behavior” (Norman 2011). When shifting from a product-centered design to a person-centered design (in a structure, a service or in a relationship) what should the function of drawing in a design course be? What should its curriculum be? Our work methodology will be to confront today’s perspectives on design theory and practice in an attempt to add to the discussion on the methodological strategies in design teaching in the contemporary context.

Contribution towards a reflection about methodological strategies in Design Education and the function of Drawing in Design

This work presents a reflection on Design education and specifically on the role of Drawing in this area. As a subject, Design has expanded its field of action expanding into new areas such as Experience Design or Service Design. It became necessary for the designer to have more than an education based on technological knowledge or know-how. Many authors like Meredith Davis, Don Norman or Jamie Hobson point out the urgency to review the curricula of Design courses because nowadays “ … design is more than appearance, design is about interaction, about strategy and about services. Designers change social behavior” (Norman, 2011) When shifting from a product-centered design to a person-centered design (in a structure, a service or in a relationship) what should the function of drawing in a design course be? What should its curriculum be? Our work methodology will be to confront today’s perspectives on design theory and practice in an attempt to add to the discussion on the methodological strategies in design teaching in the contemporary context.

Combining Formal Methods and Functional Strategies Regarding the Reverse Engineering of Interactive Applications

Abstract. Graphical user interfaces (GUIs) make software easy to use by providing the user with visual controls. Therefore, correctness of GUI’s code is essential to the correct execution of the overall software. Models can help in the evaluation of interactive applications by allowing designers to concentrate on its more important aspects. This paper describes our approach to reverse engineer an abstract model of a user interface directly from the GUI’s legacy code. We also present results from a case study. These results are encouraging and give evidence that the goal of reverse engineering user interfaces can be met with more work on this technique.