No description available.

No description available.

No description available.

No description available.

<p> Identifying design pattern instances within an existing software system can support understanding and reuse of the system functionality. Moreover, incorporating behavioral features through task scenario into the design pattern recovery would enhance both the scalability of the process and the usefulness of the design pattern instances. In this context, we present a novel method for recovering design pattern instances from the implementation of system behavioral features through a semi-automatic and multi-phase reverse engineering process.</p> <p> The proposed method consists of a feature-oriented dynamic analysis and a two-phase design pattern detection process. The feature-oriented dynamic analysis works on the software system behavioral features' run-time information and produces a mapping between features and their realization at class level. In the two-phase design pattern detection process, we employ an approximate matching and a structural matching to detect the instances of the target design pattern described in our proposed Pattern Description Language (PDL), which is an XML-based design pattern description language. The correspondence between system features and the identified design pattern instances can facilitate the construction of more reusable and configurable software components. Our target application domain is an evolutionary development of software product line which emphasizes on reusing software artifacts to construct a reference architecture for several similar products. We have implemented a prototype toolkit and conducted experimentations on three versions of JHotDraw systems to evaluate our approach.</p> / Thesis / Master of Applied Science (MASc)

Desenvolvimento Guiado por Testes (TDD) e uma das praticas sugeridas na Programacao Extrema. A mecanica da pratica e simples: o programador escreve o teste antes de escrever o codigo. E, portanto, possivel inferir que a pratica de TDD e uma pratica de testes de software. Entretanto, muitos autores de livros conhecidos pela industria e academia afirmam que os efeitos da pratica vao alem. Segundo eles, TDD ajuda o desenvolvedor durante o processo de criacao do projeto classes, fazendo-os criar classes menos acopladas e mais coesas. Entretanto, grande parte dos trabalhos da literatura sao voltados a descobrir se a pratica faz diferenca na qualidade do codigo gerado, mas poucos sao os autores que discutem como a pratica realmente auxilia. Mesmo os proprios praticantes nao entendem ou conseguem expressar bem como a pratica os guia. Este trabalho tem por objetivo compreender melhor os efeitos de TDD e como sua pratica influencia o desenvolvedor durante o processo de projeto de sistemas orientados a objetos. Para entende-las, neste trabalho optamos por um estudo exploratorio essencialmente qualitativo, no qual participantes foram convidados a resolver exercicios pre-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, nos levantamos detalhes sobre como a pratica influenciou as decisoes de projeto de classes dos participantes por meio de entrevistas. Ao final, observamos que a pratica de TDD pode guiar o desenvolvedor durante o processo de criacao do projeto de classes por meio de constantes feedbacks sobre a qualidade do projeto. Esses feedbacks alertam desenvolvedores sobre possiveis problemas, como alto acoplamento ou baixa coesao. Os desenvolvedores, por sua vez, devem interpretar e melhorar o projeto de classes. Este trabalho catalogou e nomeou os padroes de feedback percebidos pelos participantes. / Test-Driven Development (TDD) is one of the suggested practices in Extreme Programming (XP). The mechanical is simple: the developer writes a test before writing the implementation. Thus, TDD is often seen as a software testing technique. However, many famous book authors suggest that TDD can help developers during the class design creation process, enabling developers to create less coupled highly cohesive classes. Most of the academic studies are interested on finding the difference between a TDDd and a non-TDDd code. Only a few of them discuss how the practice really supports class design. Even practitioners do not understand how the practice guides them. This work aims to understand better the effects of TDD and how the practice influences the practitioner during the class design process in object-oriented systems. To better understand them, we did a essencially qualitative explorative study, in which participants were invited to solve a set of pre-prepared exercises using TDD and, based on the gathered data, we retrieved details of how the practice influenced the developers class design decisions through interviews. At the end, we observed that the practice of TDD can guide developers during the class design creation process through constant feedback about its quality. These feedbacks alert developers about possible problems, such as high coupling or low cohesion. Developers then should interpret and improve the class design accordingly. This study also catalogues the TDD feedback patterns perceived by the participants.

Desenvolvimento Guiado por Testes (TDD) e uma das praticas sugeridas na Programacao Extrema. A mecanica da pratica e simples: o programador escreve o teste antes de escrever o codigo. E, portanto, possivel inferir que a pratica de TDD e uma pratica de testes de software. Entretanto, muitos autores de livros conhecidos pela industria e academia afirmam que os efeitos da pratica vao alem. Segundo eles, TDD ajuda o desenvolvedor durante o processo de criacao do projeto classes, fazendo-os criar classes menos acopladas e mais coesas. Entretanto, grande parte dos trabalhos da literatura sao voltados a descobrir se a pratica faz diferenca na qualidade do codigo gerado, mas poucos sao os autores que discutem como a pratica realmente auxilia. Mesmo os proprios praticantes nao entendem ou conseguem expressar bem como a pratica os guia. Este trabalho tem por objetivo compreender melhor os efeitos de TDD e como sua pratica influencia o desenvolvedor durante o processo de projeto de sistemas orientados a objetos. Para entende-las, neste trabalho optamos por um estudo exploratorio essencialmente qualitativo, no qual participantes foram convidados a resolver exercicios pre-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, nos levantamos detalhes sobre como a pratica influenciou as decisoes de projeto de classes dos participantes por meio de entrevistas. Ao final, observamos que a pratica de TDD pode guiar o desenvolvedor durante o processo de criacao do projeto de classes por meio de constantes feedbacks sobre a qualidade do projeto. Esses feedbacks alertam desenvolvedores sobre possiveis problemas, como alto acoplamento ou baixa coesao. Os desenvolvedores, por sua vez, devem interpretar e melhorar o projeto de classes. Este trabalho catalogou e nomeou os padroes de feedback percebidos pelos participantes. / Test-Driven Development (TDD) is one of the suggested practices in Extreme Programming (XP). The mechanical is simple: the developer writes a test before writing the implementation. Thus, TDD is often seen as a software testing technique. However, many famous book authors suggest that TDD can help developers during the class design creation process, enabling developers to create less coupled highly cohesive classes. Most of the academic studies are interested on finding the difference between a TDDd and a non-TDDd code. Only a few of them discuss how the practice really supports class design. Even practitioners do not understand how the practice guides them. This work aims to understand better the effects of TDD and how the practice influences the practitioner during the class design process in object-oriented systems. To better understand them, we did a essencially qualitative explorative study, in which participants were invited to solve a set of pre-prepared exercises using TDD and, based on the gathered data, we retrieved details of how the practice influenced the developers class design decisions through interviews. At the end, we observed that the practice of TDD can guide developers during the class design creation process through constant feedback about its quality. These feedbacks alert developers about possible problems, such as high coupling or low cohesion. Developers then should interpret and improve the class design accordingly. This study also catalogues the TDD feedback patterns perceived by the participants.

The Object-Oriented Data Specification Framework (OODSF) is a C++ framework to facilitate programming in a heterogeneous distributed environment. Using the OODSF, C++ language bindings of commonly used specification languages, such as Abstract Syntax Notation 1 (ASN.l) and Interface Definition Language (IDL), can be defined. The OODSF defines C++ class libraries for ASN.l and IDL to simplify the C++ language bindings. Arbitrary application-level IDL and ASN.l specifications can be translated into C++ representations based on these class libraries. The OODSF contains facilities for encoding and decoding transferred data, allowing interoperability in a heterogeneous distributed system. A general interface is provided to encoding and decoding services so that a flexible choice of an encoding rule can be made. The current implementation of the OODSF contains external Encoding Rule (XDR) and Basic Encoding Rule (BER). / Master of Science

"This research is aimed at studying the key technologies of Computer-Aided Manufacturing Planning (CAMP) of mass customization for non-rotational part production. The main goal of the CAMP is to rapidly generate manufacturing plans by using of the best-of-practice (BOP) provided by specific companies. A systematic information modeling hierarchy is proposed to facilitate changes in manufacturing plans according to changes in part design. The Object-oriented Systems Analysis (OSA) approach is used to represent information relationships and associativities in the CAMP. A feature-based part information model, a process model, a setup planning model, and manufacturing resource capability models are established. A three-level decision-making mechanism is proposed for the CAMP. At the feature- level, combined features are defined based on part families, and a process model is proposed to describe the information associativities between features and their manufacturing strategies, which include customized cutters and toolpaths. At the part level, graph-based setup planning is carried out by tolerance analysis and manufacturing resource capability analysis. At the machine level, multi-part fixtures are utilized to pursue high productivity. Cycle time is used to evaluate manufacturing plans. Computer software for the CAMP has been developed and integrated with CAD package Unigraphs. The BOP of part families is stored in XML format, which has good extendibility and can be read and edited by standard browsers."