Renovados são os desa os trazidos à computação distribuída pelos recentes desenvolvimentos nas tecnologias de computação móvel. Tais avanços inspiram uma perspectiva na qual a computação tornar-se-á uma entidade ubíqua em um futuro próximo, estando presente nas mais simples atividades do dia-a-dia. Esta perspectiva é motivadora das pesquisas conduzidas no escopo do projeto ISAM, as quais investigam as questões relativas ao uso da computação em ambientes móveis de larga escala. Neste trabalho é apresentado o sistema PRIMOS (PRIMitives for Object Scheduling), o qual busca, pela complementação da plataforma Java, satisfazer as emergentes necessidades do ISAM. Especi camente, o PRIMOS constitui um conjunto de primitivas para instanciação remota e migração de objetos, comunicação e monitoração, direcionadas a um ambiente de computação distribuída de larga escala de características pervasivas. A primitiva de instanciação remota disponibilizada pelo PRIMOS aumenta a plataforma Java padrão com a possibilidade de criar e ativar objetos em nodos remotos do sistema. Por sua vez, a primitiva de migração faculta a relocação de objetos. A consecu- ção de tais semânticas tem como sub-produto a de nição de semânticas para ativação e desativação de objetos, assim como para captura e restauração de contexto de execução. Sob a perspectiva da comunicação, o PRIMOS de ne um esquema de endereçamento independente de protocolo de transporte, assim como uma interface neutra para acesso às facilidades de comunicação. A integração destas funcionalidades ao mecanismo de invocações remotas da plataforma Java, o RMI, permite a desvinculação deste da pilha TCP/IP. Por conseguinte, habilita a adoção de transportes otimizados ao hardware de comunicação disponibilizado pelo sistema. No que se refere à monitoração, o PRIMOS de ne um esquema exível e extensível baseado em sensores. A exibilidade vem principalmente da possibilidade dos sensores terem seus parâmetros de operação recon gurados a qualquer momento em resposta a novas necessidades do sistema. Por outro lado, o sistema é extensível pois o conjunto de sensores básicos, ditos nativos, pode ser aumentado por sensores providos pela aplicação. Com intuito de validar as idéias postuladas, um protótipo foi construído para o sistema. Sobre este, baterias de testes foram realizadas para cada uma das primitivas constituintes do PRIMOS.

Este trabalho apresenta uma arquitetura para Ambientes de Desenvolvimento de Software (ADS). Esta arquitetura é baseada em produtos comerciais de prateleira (COTS), principalmente em um Sistema de Gerência de Workflow – SGW (Microsoft Exchange 2000 Server – E2K) - e tem como plataforma de funcionamento a Internet, integrando também algumas ferramentas que fazem parte do grande conjunto de aplicativos que é utilizado no processo de desenvolvimento de software. O desenvolvimento de um protótipo (WOSDIE – WOrkflow-based Software Development Integrated Environment) baseado na arquitetura apresentada é descrito em detalhes, mostrando as etapas de construção, funções implementadas e dispositivos necessários para a integração de um SGW, ferramentas de desenvolvimento, banco de dados (WSS – Web Storage System) e outros, para a construção de um ADS. O processo de software aplicado no WOSDIE foi extraído do RUP (Rational Unified Process – Processo Unificado Rational). Este processo foi modelado na ferramenta Workflow Designer, que permite a modelagem dos processos de workflow dentro do E2K. A ativação de ferramentas a partir de um navegador Web e o armazenamento dos artefatos produzidos em um projeto de software também são abordados. O E2K faz o monitoramento dos eventos que ocorrem dentro do ambiente WOSDIE, definindo, a partir das condições modeladas no Workflow Designer, quais atividades devem ser iniciadas após o término de alguma atividade anterior e quem é o responsável pela execução destas novas atividades (assinalamento de atividades). A arquitetura proposta e o protótipo WOSDIE são avaliados segundo alguns critérios retirados de vários trabalhos. Estas avaliações mostram em mais detalhes as características da arquitetura proposta e proporcionam uma descrição das vantagens e problemas associados ao WOSDIE.

Para o desenvolvimento de sistemas interativos que respeitem critérios de usabilidade em adição aos critérios de qualidade convencionais, é necessário que, desde suas primeiras etapas, as áreas de Engenharia de Software (ES) e de Interação Humano- Computador (IHC) sejam consideradas, simultaneamente e de maneira integrada. Essas duas áreas investigam modelos, conceitos, técnicas e práticas que refletem diferentes perspectivas sobre a atividade de desenvolvimento, uma orientada mais ao sistema (ES) e outra, mais ao usuário (IHC). Para conciliar estas perspectivas, é necessário o estabelecimento de um entendimento mútuo e a utilização conjunta e integrada de conceitos, técnicas e práticas de desenvolvimento de ambas as áreas. Este trabalho visa mostrar as possibilidades desta integração, através da combinação dos conceitos de Casos de Uso (Use Cases) e Cenários (Scenarios), importantes técnicas de modelagem amplamente utilizadas respectivamente nas áreas de ES e IHC, em diferentes contextos, com diferentes visões; mas apresentando similaridades valiosas para propiciarem o uso complementar de ambas as técnicas. Para sistematizar esta integração, é proposta uma abordagem teleológica – baseada em objetivos – de construção sistemática de casos de uso com quatro diferentes níveis de abstração, desde os mais abstratos casos de uso essenciais até os cenários, aqui utilizados como instâncias concretas de casos de uso. Com esta abordagem, pretende-se construir um modelo de casos de uso que permita especificar requisitos funcionais, conjuntamente com requisitos de interação, de maneira compreensível e praticável e que sirva como ponto de partida à continuidade do desenvolvimento orientado a objetos de software. Com o intuito de exemplificar a proposta, é descrita e discutida a aplicação passo a passo desta abordagem a um exemplo.

Os requisitos direcionam o desenvolvimento de software porque são cruciais para a sua qualidade. Como conseqüência tanto requisitos funcionais quanto não funcionais devem ser identificados o mais cedo possível e sua elicitação deve ser precisa e completa. Os requisitos funcionais exercem um papel importante uma vez que expressam os serviços esperados pela aplicação. Por outro lado, os requisitos não funcionais estão relacionados com as restrições e propriedades aplicadas ao software. Este trabalho descreve como identificar requisitos não funcionais e seu mapeamento para aspectos. O desenvolvimento de software orientado a aspectos é apontado como a solução para os problemas envolvidos na elicitação e modelagem dos requisitos não funcionais. No modelo orientado a aspectos, o aspecto é considerado o elemento de primeira ordem, onde o software pode ser modelado com classes e aspectos. As classes são comumente usadas para modelar e implementar os requisitos funcionais, já os aspectos são adotados para a modelagem e implementação dos requisitos não funcionais. Desse modo, é proposta a modelagem dos requisitos não funcionais através das fases do ciclo de vida do software, desde as primeiras etapas do processo de desenvolvimento. Este trabalho apresenta o método chamado FRIDA – From RequIrements to Design using Aspects, cujo objetivo é determinar uma forma sistemática para elicitar e modelar tanto os requisitos funcionais quanto os não funcionais, desde as fases iniciais do ciclo de desenvolvimento. Em FRIDA, a elicitação dos requisitos não funcionais é realizada usando-se checklists e léxicos, os quais auxiliam o desenvolvedor a descobrir os aspectos globais – utilizados por toda a aplicação – bem como, os aspectos parciais que podem ser empregados somente a algumas partes da aplicação. O próximo passo consiste na identificação dos possíveis conflitos gerados entre aspectos e como resolvê-los. No método FRIDA, a identificação e resolução de conflitos é tão importante quanto a elicitação de requisitos não funcionais, nas primeiras fases do ciclo de vida do software. Além disso, é descrito como usar a matriz de conflitos para automatizar esse processo sempre que possível. A extração dos aspectos e sua modelagem visual são características muito importantes, suportadas pelo método, porque elas possibilitam a criação de modelos que podem ser reutilizados no futuro. Em FRIDA, é demonstrado como transformar os requisitos em elementos da fase de projeto (classes e aspectos) e como traduzir esses elementos em código. Outra característica do método FRIDA é que a conexão entre diagramas, que pertencem a diferentes fases do processo de desenvolvimento do software, permite um alto nível de rastreabilidade. Em resumo, FRIDA requer que o desenvolvedor migre de uma visão puramente funcional para outra que contemple também os requisitos não funcionais.

Muitos aplicativos atuais, envolvendo diversos domínios de conhecimento, são estruturados como arquiteturas de software que incorporam, além dos requisitos funcionais, requisitos não funcionais, como segurança, por exemplo. Tais requisitos podem constituir um domínio próprio, e, portanto, serem comuns a várias outras arquiteturas de software. Tecnologias como Programação Orientada a Aspectos, Reflexão Computacional e Padrões de Projeto colaboram no desenvolvimento de arquiteturas que provêem a separação de requisitos não funcionais. Porém, sua experimentação e adoção no domínio da segurança computacional ainda é incipiente. O foco deste trabalho é a elaboração de um padrão de projeto voltado à segurança, utilizando como arquitetura conceitual programação orientada a aspectos, e como arquitetura de implementação, reflexão computacional. A composição destas tecnologias resulta em um middleware orientado à segurança, voltado a aplicações desenvolvidas em Java. Estuda-se as tecnologias, seus relacionamentos com a área de segurança, seguido da proposta de uma arquitetura de referência, a partir da qual é extraído um protótipo do middleware de segurança. Este, por sua vez, provê mecanismos de segurança tão transparentes quanto possível para as aplicações que suporta. Com o objetivo de realizar a implementação do middleware de segurança, também são estudadas os mecanismos de segurança da plataforma Java, porém limitado ao escopo deste trabalho. Segue-se o estudo da base conceitual das tecnologias de Reflexão Computacional, o modelo de implementação, seguido de Programação Orientada a Aspectos, o modelo conceitual, e, por fim, têm-se os Padrões de Projeto, a arquitetura de referência. Integrando as três tecnologias apresentadas, propõe-se um modelo, que estabelece a composição de um Padrão Proxy, estruturado de acordo com a arquitetura reflexiva. Este modelo de arquitetura objetiva implementar o aspecto de segurança de acesso a componentes Java, de forma não intrusiva,. Baseado no modelo, descreve-se a implementação dos diversos elementos do middleware, estruturados de forma a ilustrar os conceitos propostos. Ao final, apresenta-se resultados obtidos durante a elaboração deste trabalho, bem como críticas e sugestões de trabalhos futuros.

Este trabalho apresenta uma ferramenta para gerenciamento de projetos, priorizando as fases de planejamento e o controle do desenvolvimento de software. Ao efetuar o planejamento de um projeto é necessário estimar o prazo, o custo e o esforço necessário, aplicando técnicas já aprovadas, existentes na literatura, tais como: Estimativa do Esforço, Estimativa de Putnam, Modelo COCOMO, Análise de Pontos por Função, Pontos de Particularidade e PSP. É necessária a utilização de uma ferramenta que automatizem o processo de estimativa. Hoje no mercado, encontram-se várias ferramentas de estimativas, tais como: ESTIMACS, SLIM, SPQR/20, ESTIMATE Professional. O controle do desenvolvimento do projeto está relacionado ao acompanhamento do projeto, do profissional e da própria estimativa de custo e esforço de desenvolvimento. Nenhuma das ferramentas estudadas permitiu o controle do projeto por parte da gerência, por isto esta se propondo o desenvolvimento uma nova ferramenta que permita o planejamento e controle do processo de desenvolvimento. Esta ferramenta deve permitir a comparação entre as diversas técnicas de estimativas, desde que baseadas na mesma medida de tamanho: pontos por função. Para exemplificar o uso desta ferramenta, foram aplicados dois estudos de casos desenvolvidos pela empresa Newsoft Consultoria de Informática.

Uma interface com o usuário é composta por duas "vias" de comunicação, uma que vai do usuário até o sistema e outra que vai do sistema até o usuário. Cada uma destas "vias" possui um formalismo que define a comunicação associado. Neste trabalho, estes formalismos são descritos com uma gramática de atributos. Esta gramática foi expandida de forma a permitir a definição dos elementos que compõe a interface do usuário, e da estrutura que irá controlar a seqüência de execução das tarefas oferecidas pelos sistemas de aplicação. Ao longo do trabalho são discutidas algumas técnicas de descrição do formalismo de comunicação entre interface e sistema, são abordados os estilos de interação e apresentada as expansões aplicadas sobre gramáticas de atributos. Um exemplo auxilia a compreensão do uso da linguagem proposta, e um protótipo permite a validação das definições. / A user interface is composed by two "ways" of communication, one from the user to the system and the other linking the system to the user. Each of these "ways" has it's own mechanism. In this work, these mechanisms are described through an attribute grammar. This grammar has been expanded to allow the definition of the structure of the interface elements and the control of the execution of the tasks that the application system implements. Through this work, technics that describe the communication between the interface and the system, interaction styles and the extensions made on attribute grammar are discussed. An example is given to explain the use of the proposed mechanism and a prototype validates ideas discussed.

Vários são os problemas que afligem o desenvolvimento de software. Estes problemas, que originaram a crise do software nos anos 60, perduram ate hoje. Praticas de Engenharia de Software tem sido adotadas em todas as fases do ciclo de vida para tentar minimizá-los. A etapa de definição de requisitos é considerada como a atividade mais importante, decisiva e ao mesmo tempo critica do desenvolvimento de software, principalmente no que diz respeito a elicitação. A Engenharia de Requisitos é a disciplina que procura sistematizar o processo de definir requisitos. Muitas vezes os sistemas de informação das organizações são complexos e/ou informais, apresentando características que dificultam o seu entendimento. Além disso, a maioria das metodologias existentes não enfatiza a aquisição de conhecimento sobre o problema a ser resolvido. Este trabalho apresenta um método para auxiliar a aquisição de conhecimento de sistemas de informação, bem como sua representação e validação. O método proposto, que tem a finalidade de sistematizar uma tarefa anterior a definição de requisitos do software, ou seja, é um método de apoio a elicitação de requisitos, inclui as etapas de elicitação, modelagem e validação. Na etapa de elicitação é feita a aquisição de conhecimento dos fatos e das situações que compõem o sistema de informações vigente, utilizando para isso, técnicas como entrevistas, observações e uma abordagem baseada em etnografia. Para guiar esta etapa foi elaborada uma sistematização combinando as técnicas anteriormente citadas. No final da etapa de elicitação são produzidas representações textuais dos objetos elicitados e o Léxico Ampliado da Linguagem, que descreve a linguagem da aplicação em estudo. A partir dessas representações é feita a modelagem através de Workflow. Na etapa de validação, as representações produzidas pelas etapas de elicitação e modelagem são validadas junto aos atores do sistema de informação. A partir das representações produzidas o engenheiro de requisitos poderá definir os requisitos funcionais do software a ser construído. A aplicação do método é adequada para ambientes que já possuem um sistema de informação definido, seja ele formal ou informal. O método proposto foi aplicado a uma situação real e parte deste estudo de caso é apresentado neste trabalho. / There are many problems in software development. These problems, which had started the software crisis in the 1960s, still exist. Software Engineering practices have been adopted in all fases of the life cycle as an attempt to minimize them. The requirements definition is considered the most important, decisive and difficult activity in software development, particularly the elicitation of the system requirements. The Requirements Engineering is the discipline that try to sistematize the requirements definition process. Information systems are often complexes, informals and present features that make difficult to understand them. Besides, most of the existing metodologies do not handle procedures for knowledge acquisition about the problem to be solved. This work proposes a method to help knowledge acquisition of information systems, and also representation and validation of the acquired knowledge. The proposal method which support the requirements elicitation, anticipate the software requirements definition process. The method includes three stages: elicitation, modeling and validation. The elicitation stage comprises knowledge acquisition of the facts and situations of the information system, through the application of techniques such as interviews, observations and a based approach on ethnography. Textual representations are produced at the end of the elicitation stage to represent the elicited objects. The Language Extended Lexicon, which describe the language used in the information system, is also produced in this stage. In the modeling stage workflow representations are produced based on those initial representations. In the validation stage all the representations produced are validated by the actors working on the information system. Based on those representations the requirements engineer can define the functional software requirements. The method can be applied to environments where a defined information systems exists. The proposal method was applied in a real world situation and part of this case study is presented in this work.

Para reutilização, manutenção e refatoração, projetistas de sistemas de software, freqüentemente, precisam examinar o código fonte da aplicação para entender os detalhes dos sistemas desenvolvidos. As aplicações orientadas a objetos em geral, tornam-se coleções nebulosas de classes e implementações de métodos. Sem dúvida a habilidade de entender sistemas de software é largamente aumentada visualizando-se esses produtos em níveis mais altos de abstração. Os padrões de projeto demonstram um alto índice de abstração e são considerados uma ferramenta efetiva para o entendimento de sistemas de software orientados a objetos. Aplicações orientadas a objetos visualizadas como um sistema de interação de padrões requerem a descoberta, identificação e classificação de grupos de classes relacionadas. Estas visualizações podem representar qualquer padrão conhecido ou agrupamentos que executam uma tarefa abstrata e necessariamente não são uma solução de padrão conhecida. Os padrões de projeto descrevem, portanto, microarquiteturas que resolvem problemas arquitetônicos em sistemas de software orientados a objetos. É importante identificar estas microarquiteturas durante a fase de manutenção de aplicações orientadas a objetos. Faz-se necessário salientar que estas microarquiteturas aparecem freqüentemente distorcidas na aplicação fonte. O objeto deste trabalho é demonstrar a viabilidade de construir uma ferramenta para descobrir a utilização de padrões de projeto em aplicações Java. Assim, esta tese examina as características de alguns padrões, determinando a natureza do que faz um padrão ser detectável por intermédio de meios automatizados, e propõe algumas regras pelas quais um conjunto de padrões possa ser identificado. As regras são baseadas nos relacionamentos entre classes e objetos mediante observação dos modelos estático e dinâmico. Este trabalho também documenta o desenvolvimento do protótipo da ferramenta de inspeção, que tem por objetivo aplicar os processos de engenharia reversa e reflexão computacional sobre código Java, utilizando as informações adquiridas para detectar padrões de projeto. Finalmente, esta tese demonstra a utilização dessa ferramenta em um exemplo pequeno de aplicação Java e forma a base para trabalhos adicionais que investiguem a existência de diferentes padrões de projeto em sistemas de software construídos em Java.

Uma interface com o usuário é composta por duas "vias" de comunicação, uma que vai do usuário até o sistema e outra que vai do sistema até o usuário. Cada uma destas "vias" possui um formalismo que define a comunicação associado. Neste trabalho, estes formalismos são descritos com uma gramática de atributos. Esta gramática foi expandida de forma a permitir a definição dos elementos que compõe a interface do usuário, e da estrutura que irá controlar a seqüência de execução das tarefas oferecidas pelos sistemas de aplicação. Ao longo do trabalho são discutidas algumas técnicas de descrição do formalismo de comunicação entre interface e sistema, são abordados os estilos de interação e apresentada as expansões aplicadas sobre gramáticas de atributos. Um exemplo auxilia a compreensão do uso da linguagem proposta, e um protótipo permite a validação das definições. / A user interface is composed by two "ways" of communication, one from the user to the system and the other linking the system to the user. Each of these "ways" has it's own mechanism. In this work, these mechanisms are described through an attribute grammar. This grammar has been expanded to allow the definition of the structure of the interface elements and the control of the execution of the tasks that the application system implements. Through this work, technics that describe the communication between the interface and the system, interaction styles and the extensions made on attribute grammar are discussed. An example is given to explain the use of the proposed mechanism and a prototype validates ideas discussed.