Uma Avaliação da Metodologia MAS-CommonKADS

Tamanho: px
Começar a partir da página:

Download "Uma Avaliação da Metodologia MAS-CommonKADS"

Transcrição

1 Uma Avaliação da Metodologia MAS-CommonKADS V.M. B. Werneck 1 ; L. F. Pereira 1 ; T. S. Silva 1 ; E. K. Almentero 1, L. M. Cysneiros 2 1 Instituto de Matemática e Estatística UERJ - Universidade do Estado do Rio de Janeiro - Brasil 2 Dept. of Math. & Stat.- Information Technology Program York University Toronto Canada Abstract: The agent-oriented approach to software engineering introduces concepts such as pro-activeness and autonomy to achieve more flexible and robust systems for complex applications environments. A number of AOSE (Agent Oriented Software Engineering) methodologies have been proposed so far. In order to evaluate and compare some of these methods in depth, we used a common exemplar a detailed application setting within which each of the methodologies will be worked out. In this paper we show how to apply this exemplar to evaluate MAS-Common-KADS. Resumo. A Modelagem Orientada a Agentes introduz conceitos como proatividade e autonomia para obter sistemas mais flexíveis e robustos em ambientes computacionais complexos. Até o momento, várias metodologias foram propostas adotando este novo paradigma. Para avaliar e comparar essas metodologias com mais detalhes, utilizamos um exemplar, onde cenários e questões metodológicas são definidos com o objetivo de modelar esses aspectos de sistemas multi-agentes. Neste trabalho apresentamos a avaliação da metodologia orientada a agentes MAS-CommonKADS baseado nessa proposta de avaliação. 1. Introdução O paradigma orientado a agentes para desenvolvimento de software tem se destacado como uma abordagem para tratar de requisitos que vêem surgindo com a grande proliferação de componentes de software distribuídos por grande número de usuários em distribuições geográficas que podem atingir escala mundial. Necessidades proeminentes dessas novas aplicações, como autonomia e sociabilidade não são tratadas pelos atuais paradigmas. No contexto emergente, uma das principais características destes componentes de software (visto aqui como agentes) é ter autonomia para decidir se um serviço requisitado por outro agente será ou não realizado em tempo real. Esta decisão é baseada nas necessidades individuais de quem estiver usando esse agente. Em decorrência desta autonomia, aspectos de sociabilidade como a dependência de um agente em outro e quanto crítica essa dependência será devem ser tratados desde o principio do processo do desenvolvimento de software. Este trabalho está inserido num projeto de pesquisa de avaliação de metodologias Orientadas a Agentes [Cysneiros, Werneck e Yu, 2005], [Cysneiros, Werneck, Amaral e Yu, 2005], [Coppieters, Marzulo, Kinder e Werneck, 2005], com

2 base no framework de avaliação proposto por Yu e Cysneiros (2002). Este trabalho visa analisar a metodologia MAS-CommonKADS utilizando-se da experiência na definição, modelagem e implementação dos requisitos de um Sistema Multi-agentes de Apoio a Diabéticos. Este experimento permitiu que a metodologia MAS-CommonKADS fosse avaliada, considerando sua potencialidade na identificação, modelagem e implementação de requisitos e características dos sistemas multi-agentes. Na Seção 2 deste artigo apresentamos o framework de avaliação baseado num exemplar. Na Seção 3 fornecemos uma visão geral da metodologia MAS- CommonKADS. Na Seção 4, apresentamos a modelagem MAS-CommonKADS dos requisitos do domínio do problema abordando os aspectos fundamentais da modelagem e o protótipo desenvolvido. A avaliação de MAS-CommonKADS é discutida no Seção 5, comparando-a a trabalhos correlatos. Na Seção 6 destacamos nossas conclusões e sugestões para trabalhos futuros. 2. O Framework de Avaliação baseado em um Exemplar O framework de avaliação [Yu e Cysneiros, 2002] utilizado neste trabalho é baseado no Projeto Guardian Angel [Szolovits et al, 1994]. Esse estudo de caso provê o suporte automático para assessorar pacientes com doenças crônicas tais como diabetes e hipertensão, integrando todos aspectos relacionados ao sistema de saúde incluindo informações legadas de remédios e informações financeiras. Este exemplo é construído através de um conjunto de agentes representando o hospital (GA_Hospital), os membros familiares em casa (GA_Home) e o paciente monitorado (GA_PDA). Esse sistema pessoal auxilia na captura, gerenciamento e interpretação do histórico pessoal da saúde do paciente e sua rotina diária na condução do tratamento, aconselhando-o com as melhores opções com base em suas preferências pessoais. O sistema mantém os registros médicos de forma compreensiva, acumulativa, correta, e coerente, acessível em tempo, em diferentes locais e para diferentes sistemas de saúde. O projeto do Guardian Angel [Szolovits et al, 1994] foi escolhido como base para o exemplar, pois apresenta um problema complexo, abrangendo as necessidades dos sistemas atuais. Assim, podemos ter experimentos que requerem modelos complexos confrontando com problemas de distribuição, privacidade, autonomia, proatividade e sociabilidade. Como um problema facilmente compreendido e aberto podese analisar melhor o poder e a fragilidade das metodologias, identificando suas vantagens, deficiências e desvantagens. O exemplar [Yu e Cysneiros, 2002] é expresso em termos de um conjunto de cenários numerados (EA0.0 até EA9.0) como por exemplo: EA2.0- Uma vez que o paciente e o médico estabeleceram um plano de tratamento GA-PDA deverá auxiliar para que o paciente siga e monitore o andamento desta rotina. O processo propõe, também, acoplado a esses cenários um conjunto de questões de avaliação (primeira coluna da Tabela 1) para apoiar a avaliação de como a metodologia suporta a modelagem desses cenários. Neste trabalho, porém, utilizamos principalmente as perguntas metodológicas apresentadas no exemplar. Em razão de estarmos desenvolvendo um sistema real baseado em agentes decidimos usar este experimento para avaliar a metodologia MAS- CommonKADS. O uso das perguntas metodológicas apresentadas em Yu e Cysneiros

3 (2002) justifica-se por já termos usado-as em diversos estudos anteriores durante os quais fomos capazes de avaliar o elevado grau de utilidade destas perguntas. Este aspecto será mais detalhado na seção 5. Tabela 1. Questões Metodológicas e Avaliação MAS-CommonKADS MAS- Common KADS QA1 - Pro-atividade S QA18 - Projeto e raciocínio da arquitetura S QA2 - Autonomia Humana X autonomia de software S QA19 - Elicitando e Raciocinando requisitos não-funcionais W QA3 - Raciocínio da autonomia S QA20 - Projeto e raciocínio da arquitetura N QA4 - Diferentes níveis de Abstração S QA21 - Projeto e raciocínio da arquitetura W QA5 - Identificando participantes do domínio S QA22 - Validando especificação ao longo do ciclo de vida W QA6 - Capturando, entendendo e registrando terminologia N QA23 - Rastreando mudanças dos requisitos ao projeto N QA7 - Análise de domínio S QA24 - Rastreando mudanças do projeto ao código N QA8 - Levantamento de requisitos S QA25 - Concorrência W QA9 - Cooperação homem-máquina N QA26 - Rastreando de volta aos requisitos N QA10 - Projeto de banco de dados N QA27 - Modularidade de software S QA11 - Evolução de banco de dados W QA28 - Verificação e Validação Formal W QA12 - Projeto de banco de dados legados N QA29 - Gerenciamento de Projeto N QA13 - Raciocinando diferentes requisitos não-funcionais W QA30 - Trabalhando equipes distribuídas N QA14 - Mobilidade W QA31 - Suporte de ferramentas W QA15 - Projeto de interface com usuário S QA32 - Curva de aprendizagem N QA16 - Gerando casos de teste N QA33 - Integração com outras metodologias N QA17 - Projeto de interface com usuário S QB7- Simplificação da metodologia para problemas simples N Total de S (Pontos Fortes) 11 Total de N (Pontos Neutros) 14 Total de W (Deficiências) 9 MAS- Common KADS 3. O Método MAS-CommonKADS A metodologia MAS-CommonKADS [Iglesias, 1998], [Iglesias e Garijo, 1999], [Iglesias e Garijo, 2005] é uma extensão da metodologia CommonKADS englobando aspectos que são relevantes para sistemas multi-agentes. CommonKADS tornou-se, principalmente na Europa, uma referência no desenvolvimento de sistemas baseados em conhecimento (SBC). No CommonKADS são definidos vários modelos [Schreiber et al, 1999], sendo o Modelo de Experiência o central da metodologia CommonKADS com objetivo de modelar o conhecimento de resolução de problemas empregado por um agente para realizar uma tarefa. Este modelo divide o conhecimento da aplicação em três subníveis: nível do domínio (conhecimento declarativo sobre o domínio), nível de inferência (uma biblioteca de estruturas genéricas de inferência) e nível de tarefa (ordem das inferências). Algumas considerações e problemas foram analisados ao se aplicar diretamente CommonKADS ao desenvolvimento de sistemas multi-agentes [Iglesias, 1998], [Iglesias e Garijo, 1999] surgindo a proposta MAS-CommonKADS centrada no Modelo de Agentes. Esta metodologia define sete modelos (Iglesias, 1998): Modelo de Agentes, Modelo de Organização, Modelo de Tarefas, Modelo de Experiência, Modelo de Comunicação, Modelo de Coordenação e Modelo de Design. O Modelo de Agentes especifica as características de um agente: sua capacidade de raciocínio, habilidades, serviços, sensores, grupos de agentes aos que pertence e classe de agente. Um agente pode ser um agente humano, software, ou qualquer entidade capaz de empregar uma linguagem de comunicação de agentes. O Modelo de Organização é uma ferramenta para analisar a organização humana em que o sistema multi-agente vai ser introduzido e para descrever a organização dos agentes de software e sua relação com o meio. O Modelo de Tarefas descreve as tarefas que os agentes podem realizar, os objetivos de cada tarefa, sua decomposição e os métodos de resolução de problemas para resolver cada objetivo. O Modelo de Experiência descreve o conhecimento necessário aos agentes para atingir seus objetivos. Segue a

4 decomposição de CommonKADS e reutiliza as bibliotecas de tarefas genéricas. O Modelo de Comunicação descreve as interações entre um agente humano e um agente software. Centra-se na consideração de fatores humanos para dita interação. O Modelo de Coordenação descreve as interações entre agentes de software. E finalmente o Modelo de Design descreve a arquitetura e o design do sistema multi-agentes como passo prévio a sua implementação, sendo o único modelo a não tratar da Análise O modelo de ciclo de vida para o desenvolvimento de sistemas multi-agentes [Iglesias, 1998], [Iglesias e Garijo, 1999], [Iglesias e Garijo, 2005] segue a gestão de projetos de Common-KADS [Schreiber et al, 1999] sendo dirigido por riscos e engloba as seguintes fases: Conceituação, Análise, Design, Codificação, Integração e Operação e Manutenção. A fase de Conceituação consiste na tarefa de elicitação para obter uma primeira descrição do problema e a determinação dos casos de uso que podem ajudar a entender os requisitos informais e a testar o sistema. A Análise determina os requisitos do sistema partindo do enunciado do problema. Durante esta fase se desenvolvem os seguintes modelos: organização, tarefas, agentes, comunicação, coordenação e experiência. No Design define-se como os requisitos da fase de análise podem ser conseguidos mediante o desenvolvimento do modelo de design, determinando-se as arquiteturas tanto da rede multi-agentes como de cada agente. Na Codificação cada agente é implementado e testado e na fase de Integração, o sistema completo é testado. 4. A Modelagem MAS-CommonKADS do Sistema Monitor Glicêmico O sistema Monitor Glicêmico surgiu de uma especialização do Guardian Angel [Szolovits et al, 1994], [Yu e Cysneiros, 2002] para o tratamento de pacientes com Diabetes Mellitus. Esse sistema foi baseado, também, no conhecimento existente e disponível nos sites da Sociedade Brasileira de Diabetes (2005), da Federação Internacional de Diabetes (2005) e da Associação Americana de Diabetes (2005). Um paciente diabético precisa contato constante com um médico para acompanhar o tratamento. Com a idéia do Guardian Angel instanciada no Monitor Glicêmico, é possível fazer isto, sem sair de casa ou marcar consulta. O sistema permite monitorar taxas de açúcar através de um medidor portátil e registrá-las no computador. O processo de identificação dos requisitos do sistema Monitor Glicêmico foi realizado nas fases de Conceituação e Análise seguida de uma fase de rápida de Design e construção de um protótipo. 4.1 Fase de Conceituação O objetivo desta fase é obter uma primeira descrição do problema e do sistema que será desenvolvido. O documento desta fase teve como objetivo modelar um protótipo do Monitor Glicêmico, implementando algumas das funções propostas inicialmente ao sistema. O protótipo foi construído para ajudar pacientes com diabetes mellitus tipo 1, em terapia insulínica intensiva, no seu dia a dia. O sistema Monitor Glicêmico pretende dar mais liberdade ao paciente customizando o próprio tratamento, fornecendo sugestões ao paciente e um direcionamento para o seu tratamento. Este auxilia no controle da taxa de glicose no sangue, no controle da dosagem de insulina e na flexibilização da dieta. O objetivo principal é que o paciente tenha conselhos de um especialista, o sistema no caso, sem precisar efetivamente ir ao médico. Nessa fase de conceituação foram realizadas as

5 seguintes atividades: descrição do problema, identificação dos atores, identificação e descrição dos casos de uso, definição dos diagramas de casos de uso e dos diagramas de seqüência de mensagens. Os seguintes atores foram identificados no sistema: o paciente, o médico e o responsável pelo paciente. Nesta primeira versão, o Paciente é uma Pessoa com diabetes mellitus em terapia insulínica intensiva, com múltiplas doses. O paciente acessará o sistema com o objetivo de auxiliar a administração de alguns aspectos do tratamento. O Médico é responsável pelo tratamento do paciente usuário do sistema e deverá ter completo conhecimento sobre as informações contidas no sistema e sobre o papel deste no tratamento. Ocasionalmente, o médico receberá mensagens do sistema informando a ocorrência de desvios de padrão na taxa glicêmica do paciente. No futuro esses alertas poderão ser configurados pelo médico para que este se sinta confortável com o nível de alerta sem ser incomodado muitas vezes por dia. O Responsável pelo acompanhamento do tratamento do paciente tem o papel de acompanhar o andamento do tratamento, recebendo alertas informando sobre desvios graves no padrão da taxa glicêmica. No futuro todas as funcionalidades relacionadas aos três atores poderão rodar em PDA ou telefones celular, principalmente, no caso de emergências. Para cada ator foram identificados vários casos de uso e, por exemplo, o caso de uso UC06-Enviar Alertas, o paciente participa recebendo alertas de nível leve, médio e grave, enquanto o médico recebe alertas de nível médio e grave, e o responsável somente alertas de nível grave. Na descrição dos casos de uso foram descritos os fluxos de eventos de cada um dos casos de uso identificados e estes fazem referência aos agentes que constituem o sistema. Esses agentes foram descritos de maneira detalhada no modelo de agentes. Os Diagramas de Seqüência de Mensagens formalizam as interações e usam a notação do diagrama de seqüência de mensagens do UML. 4.2 Fase de Análise Nesta fase foram desenvolvidos os Modelos de Agentes, Tarefas, Conhecimento, Organização, Coordenação e Comunicação. O modelo de agentes tem o objetivo de descrever os agentes que participam da solução dos problemas e são descritos nas Planilhas de CRC (Classes- Responsabilidades-Colaborações), nos diagramas de casos de uso interno (extensão do conceito de casos de uso do UML para agentes humanos e de software), nos diagramas de seqüência de mensagens relativas aos casos de uso internos, nas Planilhas de Agentes e na Tabela de Distribuição de Tarefas e Agentes. As atividades realizadas na modelagem de agentes foram identificação dos agentes, descrição dos agentes, classificação dos agentes, identificação, diagramação e descrição dos casos de uso interno e seus respectivos diagramas de seqüência de mensagens. Os diagramas de caso de uso interno descrevem as funções desempenhadas internamente pelos agentes. A partir da fase de conceituação, foi possível identificar os Agentes Humanos: Paciente, Médico e Responsável; e os Agentes de software: Gerenciador de Dados Pessoais, Gerenciador de Alimentação, Gerenciador de Alertas, Gerenciador de Insulina, Gerenciador de Exercícios, Gerenciador do Banco de Dados e Avaliador de Tratamento.

6 Os agentes foram agrupados por categorias, observando as semelhanças e diferenças entre cada agente. Assim pudemos, por exemplo, ter uma Classe de Agentes Especialistas que representa os agentes que utilizam conhecimentos de um especialista na área de diabetes para produzir informações úteis ao paciente. Os Agentes classificados nessa categoria são: Gerenciador de Insulina, Gerenciador de Exercícios e Avaliador de Tratamento. As planilhas CRC proporcionam um método para organizar as classes necessárias para a construção do sistema e facilitam a aplicação dos conceitos de orientação a agentes. Como os agentes humanos não realizam nenhuma tarefa além de iniciar ou terminar cada um dos casos de uso, não foram elaborados os CRCs e as planilhas de Agentes para agentes humanos. Para cada agente de software foi construída uma planilha CRC como apresentado para agente Avaliador de Tratamento na Tabela 2. Tabela 2 Planilha CRC para o Avaliador de Tratamento. Agente: Avaliador de Tratamento Classe: Especialistas Objetivo Plano Conhecimento Colaborador Cadastrar taxa de glicose, dose de insulina e resultado da avaliação. Solicitar cadastro ao Gerenciador do Banco de Dados. Formato da avaliação e da taxa de glicose. Gerenciador do Banco de Dados. Verificar se os resultados do tratamento estão dentro dos padrões esperados. Comparar resultados atuais com o esperado e solicitar ao Gerenciador de alertas o envio de alertas. Formato dos alertas, níveis normais de taxa glicêmica e da dose de insulina, histórico de utilização de insulina, histórico da taxa glicêmica. Gerenciador de Alertas. No sistema Monitor Glicêmico foram identificados vários casos de uso internos: e a Figura 1 ilustra um exemplo de Diagrama de Casos de Uso Interno. As Descrições dos Casos de Uso Internos foram descritas de forma idêntica aos casos de uso através dos fluxos de eventos que fazem referência aos agentes que constituem o sistema. Solicitar envio de alerta MSC Processar e armazenar alerta Legenda Agente de Software Avaliador de Tratamento Armazenar alerta Gerenciador de Alertas Casos de Uso Interno MSC Diagrama de Seqüência de Mensagens Gerenciador do Banco de Dados Figura 1. Diagrama de Casos de Uso Interno UC06 - Enviar Alerta Os diagramas de seqüência de mensagens apresentam a interação entre os agentes, conforme exemplifica a Figura 2. Ainda no Modelo de Agentes foram construídas as planilhas de agentes cujo objetivo é descrever melhor as capacidades e conhecimentos dos agentes. O Modelo de Tarefas é outro modelo elaborado na fase de Análise e permite mostrar a decomposição funcional do sistema. Para representar a decomposição das tarefas foram construídos diagramas de fluxo de dados que permitem mostrar de forma mais explícita a relação entre as tarefas e as informações. A descrição das tarefas se completou na identificação e descrição de seus objetivos. Esse detalhamento contém os parâmetros de entrada e saída, as condições de ativação e finalização além da descrição do processamento e tipo de objetivo. Para finalizar o Modelo de Tarefas e de Agentes foi elaborada uma Tabela com a Distribuição das Tarefas e dos Agentes onde essas tarefas são as descritas nos casos de uso interno.

7 O Modelo de Conhecimento foi, também, definido na fase de Análise, sendo composto das Estruturas de Domínio, Inferências e de Tarefas. A Estrutura de Domínio representa o conhecimento declarativo do problema, descrevendo as entidades relevantes do domínio e as relações entre essas entidades. Neste sistema foram identificados conceitos agrupados nos seguintes esquemas do domínio: Esquemapaciente, Esquema-insulina e Esquema-exercício. A Estrutura de Inferência foi especificada para os agentes inteligentes mediante a definição das inferências que são realizadas para a resolução do problema e da estrutura que relaciona as inferências e os papéis do conhecimento. Essa estrutura foi definida e instanciada para o domínio do problema a partir de estruturas genéricas contidas numa biblioteca de modelo [Schreiber et al, 1999]. A Estrutura de Tarefas representa de forma procedural de tarefas as primitivas definidas na estrutura de inferência. No Monitor Glicêmico especificamos a Estrutura de Inferência e de Tarefas para o Avaliador de Tratamento. msc PROCESSAR ALERTA Avaliador de Tratamento Gerenciador de alertas Gerenciador de Banco de Dados solicitar_envio_alerta (gravidade,msg alerta) solicitar_armazenamento confirma_armazenamento ( ) informa_resultado (cod_ret) retorna_erro (desc_erro) Figura 2. Diagrama de Seqüência de Mensagens: Processar e armazenar alerta. O Modelo de Organização construído permitiu analisar as relações estruturais entre os agentes, tanto de software quanto humanos, que interagem com o sistema. Finalmente o último modelo elaborado na fase de Análise foi o Modelo de Coordenação cujo principal objetivo foi definir as interações entre agentes, permitindo um estudo mais aprofundado das interações homem-máquina e máquina-máquina. Para cada interação foi definido um Diagrama de Fluxo de Eventos, descrevendo como os agentes processam as mensagens recebidas e como enviam a mensagem através dos Diagramas de Transição de Estado na notação do UML [Rumbaugh, Jacobson e Booch, 1999]. 4.3 Fase de Design e Protótipo O Modelo de Design tem como propósito a descrição dos componentes que cumprem os requisitos dos modelos de análise e que levam em conta os requisitos funcionais. Nesse primeiro protótipo, a plataforma escolhida foi a Web, para permitir o acesso de qualquer lugar via Internet. Além de outras vantagens, elimina as etapas de instalação e configuração do software o que facilita o primeiro contato com o usuário. Nessa primeira versão as linguagens utilizadas foram Java, JSP, HTML, JavaScript. e SQL. Uma nova versão está sendo implementada em JADE (2006). O acesso do sistema é realizado através de um login 1 e uma senha disponibilizando suas funções. Este protótipo encontra-se em fase de teste com 1 O sistema pode ser acessado para teste com Usuário: vera e Senha: veraxxx e o endereço de acesso é

8 especialistas que consideram o sistema muito importante. Entretanto, algumas regras de inferência deverão ser melhor calibradas, pois ainda não atingiu o nível esperado de um especialista. A Figura 3 ilustra uma interação do sistema mostrando o cálculo da dosagem de insulina e o resultado da avaliação do paciente. Fig. 3. Monitor Glicêmico - Resultado do cálculo da dose de insulina 5. AVALIAÇÃO DA METODOLOGIA MAS-COMMON-KADS A escolha do framework de avaliação proposto por Yu e Cysneiros (2002) é justificada considerando vários aspectos, sendo fundamental o uso de um exemplo prático, real e grande o suficiente para testar e verificar como a metodologia se comporta em situações reais. Embora o Monitor Glicêmico seja um sistema específico para o tratamento de diabéticos este foi definido com base nos cenários descritos no framework. Alguns desses cenários são incompletos, intencionalmente omitidos para testar como a metodologia direciona e suporta a elícitação de requisitos. As questões metodológicas complementam esses cenários, identificando situações em que a metodologia deve orientar na elicitação e análise dos requisitos e também casos específicos de modelagem que a metodologia deve atender. Trabalhos anteriores de avaliação das metodologias Tropos, Gaia, MESSAGE e UML/RUP [Cysneiros, Werneck e Yu, 2005], [Cysneiros, Werneck, Amaral e Yu, 2005], [Coppieters, Marzulo, Kinder e Werneck, 2005], mostraram o uso eficiente desse framework de avaliação ressaltando os pontos fortes, as deficiências e as potencialidades de cada metodologia. Assim apresentamos, a priori, uma análise geral da metodologia MAS- CommonKADS, com os principais aspectos identificados a partir da respostas fornecidas para as diversas questões conforme a Tabela 1. Na segunda coluna da Tabela 1 temos relacionadas as questões metodológicas de avaliação da metodologia MAS- CommonKADS em termos dos pontos fortes (S), das deficiências (W) e dos pontos neutros (N). A seguir é descrita uma comparação com base em outras avaliações realizadas nesse projeto e os trabalhos correlatos encontrados na literatura. 5.1 Avaliação Geral MAS-CommonKADS é uma metodologia oriunda da engenharia de conhecimento por isso agrega aspectos interessantes da definição de estruturas heurísticas. Nessa metodologia foram também incorporadas técnicas orientadas a objetos, técnicas

9 estruturadas (Diagramas de Fluxo de Dados) e técnicas de colaboração como os cartões de Classes-Responsabilidade-Colaboração (CRC). O uso de técnicas consagradas facilitou a definição dos diagramas e planilhas. Entretanto, alguns desses artefatos não são bem definidos nem exemplificados. A metodologia MAS-Common-KADS mostrouse fácil de modelar embora em muitos modelos como Modelo de Especialidade foi necessário consultar livros da metodologia Common-KADS [Schreiber et al, 1999], refletindo na atribuição neutra para curva de aprendizagem (QA32). O grande número de diagramas e planilhas dificulta a referência cruzada dos diagramas/planilhas e a rastreabilidade dos requisitos (QA23, QA24 e QA26). MAS-CommonKADS suporta a pro-atividade (QA1) através do Modelo de Agentes, Modelo de Tarefas, Modelo de Conhecimento e Modelo de Coordenação. Neste último são definidas também as interações entre os agentes e seus detalhes (QA9), sendo possível definir melhor a pro-atividade. No aspecto de decidir autonomia humana versus autonomia do software (QA2), MAS-CommonKADS permite que isso possa ser feito em tempo de execução através de heurísticas definidas no Modelo de Conhecimento. No raciocínio da autonomia (QA3) podemos ter um protocolo de cooperação entre os agentes através da negociação. Esta é expressa nos diagramas do Modelo de Coordenação através de categorias de decisão que podem se apoiar em estratégias, preferências, procedimentos ou comportamentos. MAS-CommonKADS tem três níveis de abstração (QA4) definidos nas fases de conceituação que define os requisitos iniciais, de análise e projeto. Na identificação do domínio do problema (QA7) e dos participantes do domínio (QA5), MAS- CommonKADS apóia o desenvolvedor na compreensão dos objetivos do sistema e representa a hierarquia dos agentes (QA18) através do Modelo de Organização. A fase de conceituação permite capturar requisitos (QA8) através dos seus casos de uso e também pelas suas interações definidas nos Diagramas de Seqüência de Mensagens. Assim as interações humanas e dos agentes de software (QA9) são definidas num alto nível de abstração. Esta fase foi considerada fundamental na captura de novos requisitos e refinamentos de requisitos já identificados previamente. Os Casos de Uso Interno e os seus Diagramas de Seqüência de Mensagens são definidos em MAS-CommonKADS para modelar o comportamento dos agentes. Porém, os aspectos não funcionais (QA13, QA19) não são explicitamente modelados nem é possível através desses diagramas considerar os aspectos não funcionais que irão ou não trazer conseqüências ao sistema. Apesar da rastreabilidade dos requisitos (QA23, QA24, QA26) ser um aspecto considerado não muito bem definido, 82% dos requisitos funcionais identificados na modelagem puderam ser facilmente identificados no código. Os requisitos nãofuncionais são de difícil identificação. Os agentes e seus comportamentos não são identificados no código possivelmente por ser utilizada uma linguagem orientada a objetos nesse primeiro protótipo. A maior dificuldade encontrada foi no rastreamento das funcionalidades onde havia alguma pró-atividade, pois essa característica na programação orientada a objetos ficou diluída nas várias classes. Assim sendo, a equipe não chegou a um consenso neste atributo. E MAS-CommonKADS não se preocupa em definir meios de se obter rastreabilidade. MAS-CommonKADS incentiva o uso de encapsulamento de conhecimento e comportamento nos agentes de software (QA18) o que minimiza o impacto de mudanças futuras. O modelo de projeto identificou para arquitetura (QA20, QA21)

10 escolhida como os agentes poderiam ser implementados e seus comportamentos, facilitando a implementação. A implementação embora não tenha utilizado um paradigma orientado a agentes foi bastante simples. Entretanto na implementação da parte heurística encontramos grande dificuldade por não se utilizar nenhuma linguagem orientada ao conhecimento heurístico. 5.2 Comparação com Trabalhos Correlatos Na literatura de orientação a agentes podem ser encontrados trabalhos comparando metodologias, como Sturm e Shehory (2003) que define um framework de avaliação quantitativa e qualitativa e o utiliza na avaliação das metodologias GAIA, Adept e Desire utilizando um estudo de caso de leilão. Outro trabalho de avaliação interessante foi o desenvolvido por Dam e Winikoff (2003) que utiliza um framework baseado em atributos e um questionário enviado e respondido pelos pesquisadores, por autores das metodologias e alunos que modelaram o estudo de caso Planejamento de Itinerário Pessoal. Essa avaliação foi realizada nas metodologias GAIA, MaSE, Message, Prometheus e Tropos. Iglesias e González (1998) descrevem um levantamento de metodologias analisando suas extensões nos paradigmas orientados a objetos e de conhecimento. Ceruzzi e Rossi (2002) propõe outra avaliação que usa métricas e métodos quantitativos, mostrando a utilidade deste framework na comparação das metodologias MAS-CommonKADS e Agent Modelling Technique for Systems of BDI Agents. Essa avaliação é baseada em critérios previamente definidos e através da quantificação dos resultados e aplicação de média aritmética. Um dos resultados apontados para MAS- CommonKADS é que esta só atende o critério de pro-atividade (QA1) parcialmente, pois não permite a definição explicita de objetivos e de aspectos nebulosos e de evolução da autonomia. Entretanto através dos Modelos de Agentes, de Tarefas, de Conhecimento e de Coordenação esse aspecto pode ser bem definido, e apontamos como um aspecto poderoso da metodologia. Realmente a evolução da autonomia é um fator considerado fraco na metodologia, mas esse também é um fator crítico em sistemas inteligentes. Esse fator poderia ser uma questão a ser introduzida no exemplar. Outro exemplo é em relação ao critério transição sistemática, onde Cerruzzi e Rossi (2002) atribuem a MAS-CommonKADS o valor máximo. Entretanto, em nossa avaliação esses atributos (QA23 e QA24) são neutros, pois a metodologia não possui uma descrição detalhada das tarefas para construção de todos os artefatos propostos nem da transição de um para outro. Outro trabalho relevante de avaliação da metodologia MAS-CommonKADS encontrado foi o proposto por Tran, Low e Williams (2004). Nessa proposta são definidos 50 critérios para avaliação agrupados em critérios relacionados a processo, técnica, modelo e apoio. Porém alguns desses critérios não são analisados, principalmente os relativos ao emprego das técnicas. O artigo menciona que uma análise mais profunda deve ser realizada num futuro. No critério suporte a ontologia é atribuída uma afirmação, mas através da questão QA6 consideramos este um fator neutro, pois a descrição de como essa ontologia se insere no MAS-CommonKADS não é encontrada em nenhum documento da metodologia embora seja uma característica da metodologia CommonKADS. Em relação ao suporte na definição da interface de comportamento do agente e instanciação das classes de agentes, Tran, Low e Williams

11 (2004) atribuem zero a esses fatores. Consideram que MAS-CommonKADS não suporta esses aspectos. Entretanto o valor atribuído deveria ser 1, pois o passo é incluído na metodologia mas não referenciado explicitamente ou através de exemplos. O critério QA9 neutro reflete essa questão. Com base nos trabalhos anteriores do projeto [Cysneiros, Werneck e Yu, 2005], [Cysneiros, Werneck, Amaral e Yu, 2005], [Coppieters, Marzulo, Kinder e Werneck, 2005], podemos concluir que MAS-CommonKADS provê apoio as fases de Análise e Projeto inclusive as fases iniciais de Definição de Requisitos como as metodologias MESSAGE e Tropos. Mas não tão abrangente como Tropos, pois não permite a definição e raciocínio dos requisitos não-funcionais nem avaliação de alternativas ao processo. MAS-CommonKADS como Gaia e Tropos permite modelar os conceitos de agentes, como autonomia, pro-atividade, objetivos e desejos. Em termos de facilidade de aprendizagem (QA32) é neutro, pois embora tenha documentação disponível alguns dos seus diagramas e artefatos não são bem definidos. Esse atributo também não foi o máximo nas metodologias MESSAGE e Tropos. Gaia por ser mais concisa tem uma documentação melhor. 6. CONCLUSÃO Neste trabalho foram abordados aspectos importantes da modelagem e da identificação de requisitos em sistemas multi-agentes. O objetivo deste foi avaliar qualitativamente a metodologia MAS-CommonKADS utilizando-a para desenvolver um protótipo de um sistema para ajudar pacientes portadores de diabetes mellitus tipo 1. Esta avaliação foi baseada no conjunto de perguntas apresentada no exemplar proposto por Yu e Cysneiros (2002). O framework utilizado [Yu e Cysneiros, 2002] nessa avaliação foi bastante útil tanto no auxílio à definição dos requisitos como para se identificar situações não modeladas. A análise dos pontos fortes e fracos da metodologia MAS-CommonKADS pode ser melhor compreendida após serem respondidas as questões metodológicas. Podemos sintetizar que a metodologia MAS-CommonKADS tem como pontos fortes a identificação dos agentes, de seus requisitos funcionais através da descrição do comportamento desses diferentes agentes, facilitando principalmente a implementação de agentes que utilizam estruturas de inferência. Entretanto, podemos ressaltar como problemas o uso excessivo de modelos e diagramas de análise e de não descrever explicitamente a relação entre os diferentes artefatos. Outro aspecto que a metodologia necessita de melhoria é no tratamento dos requisitos não-funcionais. A continuação deste trabalho está sendo realizada em duas iniciativas em paralelo. A primeira deverá continuar o processo de avaliação da metodologia implementando essa mesma modelagem utilizando uma plataforma orientada a agentes. A segunda consistirá na continuação do desenvolvimento do sistema Monitor Glicêmico que deverá ser melhorado com mais funcionalidade, melhor desempenho em suas respostas e implementado para diferentes ambientes (PDA, telefone celular,...), pois existe um grande interesse de uso na prática. REFERÊNCIAS BIBLIOGRÁFICAS Ceruzzi, L. e Rossi, G. (2002) On the Evaluation of Agent-Oriented Methods, Agent Oriented Methodology Workshop, November.

12 Coppieters, A. M., Marzulo, L.A.J., Kinder, E. e Werneck, V.M.. (2005) Modelagem Orientada a Agentes utilizando MESSAGE, Cadernos do IME- Série Informática, Rio de Janeiro, v.18, p Cysneiros, L. M., Werneck, V. M. B., Amaral, J. e Yu, E. (2005) Agent/Goal Orientation versus Object Orientation for Requirements Engineering: A Practical Evaluation Using an Exemplar, In: Proc. Of VIII Workshop in Requirements Engineering, Porto, 2005, p , ISBN Cysneiros, L. M., Werneck, V. M. B.; Yu, Eric (2005) Evaluating Methodologies: A Requirements Engineering Approach Through the Use of an Exemplar. Journal of Computer Science & Technology, USA, v. 5, n. 2, p Dam K. H. e Winikoff, M. (2003) Comparing Agent-Oriented Methodologies, 5th International Workshop on Agent-Oriented Information Systems (AOIS 03), p Iglesias, C. Á. (1998) Definición de una Metodología para el Desarrollo de Sistemas Multiagente, Tese de Doutorado, Departamento de Engenharia de Sistemas de Telecomunicação, Universidade Politécnica de Madri. Madri, 322p. Iglesias, C.A. e Garijo, M. (1999) UER Technique: Conceptualisation for Agent- Oriented Development, In Proceeding of 5th International Conference on Information Systems Analysis and Synthesis (ISAS 99), Vol 5, p Iglesias, C.A. e Garijo, M. (2005) The Agent Oriented Methodology MAS- CommonKADS; IN Agented-Oriented Methodologies, Brian Henderson-Sellers e Paolo Giorgini (ed.), IDEA Group Publishing, p Iglesias, C.A. e González, J.C. (1998) A Survey of Agent-Oriented Methodologies In Proceedings of the 5th International Workshop on Agent Theories, Architectures and Languages (ATAL'98), LNAI n Springer Verlag, Paris, France, p JADE Java Agent Development Framework. Disponível em acessado em abril Rumbaugh, J., Jacobson, I. e Booch, G. (1999) The Unified Modeling Language Reference Manual ; Addison-Wesley. Schreiber, G et al (1999) Knowledge Engineering and Management: The CommonKADS Methodology, Cambridge, MA,. Sturm, A. e Shehory, O. (2003) A Framework for Evaluating Agent-Oriented Methodologies, 5th International Workshop on Agent-Oriented Information Systems (AOIS 03), p Szolovits, P., Doyle, J., Long, W.J., Kohane, I. e Pauker, S. G. (1994) Guardian Angel: Patient-Centered Health Information Systems, Technical Report MIT/LCS/TR-604. Disponível em. Tran, Q.N., Low, G. e Williams, M. (2004) A Prelimary Comparative Feature Analysis of Multi-agent Systems Developments Methodologies, In Proc of the 6th Intl. Bi- Conference Workshop on Agent-Oriented Information Systems (AOIS 2004),. Yu, E. e Cysneiros, L.M. (2002), Agent-Oriented Methodologies-Towards a Challenge Exemplar in Proc of the 4th Intl. Bi-Conference Workshop on Agent-Oriented Information Systems (AOIS 2002), Toronto.

Monitor Glicêmico: Um Sistema Multi-Agentes para Controle de Diabetes

Monitor Glicêmico: Um Sistema Multi-Agentes para Controle de Diabetes Monitor Glicêmico: Um Sistema Multi-Agentes para Controle de Diabetes V.M. B. Werneck 1 ; L. F. Pereira 1 ; T. S. Silva 1 ; E. K. Almentero 1, L. M. Cysneiros 2 1 Instituto de Matemática e Estatística

Leia mais

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Introdução a INGENIAS:

Introdução a INGENIAS: Universidade do Estado do Rio Grande do Norte UERN Universidade Federal Rural do Semi-Árido UFERSA Mestrado em Ciência da Computação MCC Disciplina: Engenharia de Software Orientada a Agentes Professores:

Leia mais

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso Casos de Uso O que é Casos de Uso Descrições narrativas de processos do domínio da aplicação Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

UTILIZAÇÃO DE METODOLOGIAS PARA DESENVOLVIMENTO DE AGENTES: UM ESTUDO DE CASO NA MICROECONOMIA

UTILIZAÇÃO DE METODOLOGIAS PARA DESENVOLVIMENTO DE AGENTES: UM ESTUDO DE CASO NA MICROECONOMIA UTILIZAÇÃO DE METODOLOGIAS PARA DESENVOLVIMENTO DE AGENTES: UM ESTUDO DE CASO NA MICROECONOMIA VANESSA M. BERNY, DIANA F. ADAMATTI, DANIELA FERREIRA GOMES, ANTONIO C. DA ROCHA COSTA RESUMO Este artigo

Leia mais

Um processo para construção de software mais transparente

Um processo para construção de software mais transparente Um processo para construção de software mais transparente Eduardo Almentero 1, and Julio Cesar Sampaio do Prado Leite 1 1 Pontifícia Universidade Católica do Rio de Janeiro, PUC - Rio, Brasil {ealmentero,

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

DESENVOLVENDO SISTEMAS MULTI-AGENTES

DESENVOLVENDO SISTEMAS MULTI-AGENTES UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA DESENVOLVENDO SISTEMAS MULTI-AGENTES UTILIZANDO TROPOS E JADEX PROPOSTA DE TRABALHO DE GRADUAÇÃO Aluno: Bárbara

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente

Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente Carla Gomes de Faria1, Ismênia Ribeiro de Oliveira1, Rosario Girardi1 1Universidade Federal do Maranhão (UFMA)

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA Introduçãoa Engenhariade Software Prof. Anderson Cavalcanti UFRN-CT-DCA O que é Software? O que é software? São programas de computadores, em suas diversas formas, e a documentação associada. Um programa

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Engenharia de Software: Introdução Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Programa 1. O processo de engenharia de software 2. UML 3. O Processo Unificado 1. Captura de requisitos 2.

Leia mais

ATENAS: Um Sistema Gerenciador de Regras de Negócio

ATENAS: Um Sistema Gerenciador de Regras de Negócio 1. Introdução ATENAS: Um Sistema Gerenciador de Regras de Negócio Geraldo Zimbrão da Silva (IM/UFRJ) Victor Teixeira de Almeida (COPPE/UFRJ) Jano Moreira de Souza (COPPE/UFRJ) Francisco Gonçalves Pereira

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 08 APRESENTAÇÃO Na aula de hoje vamos apresentar e discutir como definir

Leia mais

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com ANÁLISE E PROJETO ORIENTADO A OBJETOS Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Análise Descrição do problema a ser implementado Descrição dos objetos e classes que fazem parte do problema, Descrição

Leia mais

Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos

Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos Marco Aurélio Wehrmeister mawehrmeister@inf.ufrgs.br Roteiro Introdução Orientação a Objetos UML Real-Time UML Estudo de Caso: Automação

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

Diagrama de Classes. Diagrama de Classes. Diagramas de Classe. POST Criando Diagramas de Classe. Como construir (2)

Diagrama de Classes. Diagrama de Classes. Diagramas de Classe. POST Criando Diagramas de Classe. Como construir (2) Diagrama de Classes Diagrama de Classes Modelo de classes de especificação Perspectiva de Projeto Ilustra as especificações de software para as classes e interfaces do sistema. É obtido através da adição

Leia mais

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br MC302A Modelagem de Sistemas com UML Prof. Fernando Vanini vanini@ic.unicamp.br Modelamento de Sistemas e Orientação a Objetos O paradigma de Orientação a Objetos oferece um conjunto de características

Leia mais

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

Leia mais

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo? O que é a UML? Introdução a UML Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação

Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação Valdemar Vicente GRACIANO NETO 1 ; Juliano Lopes DE OLIVEIRA 1 1 Instituto de Informática

Leia mais

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso Desenvolvimento de Software Dirigido por Caso de Uso Parte II: Especificando Caso de Uso Vinicius Lourenço de Sousa viniciuslsousa@gmail.com Atua no ramo de desenvolvimento de software há mais de 10 anos,

Leia mais

2 Auto-sintonia de Bancos de Dados e Agentes de Software

2 Auto-sintonia de Bancos de Dados e Agentes de Software 2 Auto-sintonia de Bancos de Dados e Agentes de Software A uso da abordagem de agentes de software 1 pode trazer benefícios a áreas de aplicação em que é necessário construir sistemas autônomos, ou seja,

Leia mais

Representando Características Autonômicas nos Processos de Negócio

Representando Características Autonômicas nos Processos de Negócio Representando Características Autonômicas nos Processos de Negócio Karolyne Oliveira, Tarcísio Pereira, Emanuel Santos, Jaelson Castro Universidade Federal de Pernambuco UFPE, Recife, PE 50 740-560, Brazil

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA?

A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA? A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA? ADEMILSON ANGELO CABRAL Discente da AEMS Faculdades Integradas de Três Lagoas DIEGO BEZERRA DA SILVA Discente da AEMS Faculdades

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

18º Congresso de Iniciação Científica UM ESTUDO EXPLORATÓRIO SOBRE TÉCNICAS DE MODELAGEM DE REQUISITOS DE SOFTWARE PARA SISTEMA EMBARCADO

18º Congresso de Iniciação Científica UM ESTUDO EXPLORATÓRIO SOBRE TÉCNICAS DE MODELAGEM DE REQUISITOS DE SOFTWARE PARA SISTEMA EMBARCADO 18º Congresso de Iniciação Científica UM ESTUDO EXPLORATÓRIO SOBRE TÉCNICAS DE MODELAGEM DE REQUISITOS DE SOFTWARE PARA SISTEMA EMBARCADO Autor(es) MARINA CALÇA Orientador(es) LUIZ EDUARDO GALVÃO MARTINS

Leia mais

Modelo de Negociação do Ambiente ICS

Modelo de Negociação do Ambiente ICS Modelo de Negociação do Ambiente ICS Sofiane Labidi 1, Bernardo W. Maia Jr. 1, Sérgio G. Martins 1 1 Laboratório de Sistemas Inteligentes Universidade Federal do Maranhão (UFMA) Av. dos Portugueses, s/n

Leia mais

Diagrama de Caso de Uso e Diagrama de Sequência

Diagrama de Caso de Uso e Diagrama de Sequência Diagrama de Caso de Uso e Diagrama de Sequência Milena Alexandre dos Santos Baesso (Mestranda em Engenharia Elétrica) Agenda Ciclo de Vida de um Sistema A Fase de Análise Análise Orientada à Objetos Diagramas

Leia mais

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código Igor Steinmacher 1, Éderson Fernando Amorim 1, Flávio Luiz Schiavoni 1, Elisa Hatsue Moriya Huzita 1 1 Departamento de Informática

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

MINISTÉRIO DA INTEGRAÇÃO NACIONAL SECRETARIA EXECUTIVA DEPARTAMENTO DE GESTÃO ESTRATÉGICA COORDENAÇÃO-GERAL DE TECNOLOGIA DA INFORMAÇÃO ENCARTE R

MINISTÉRIO DA INTEGRAÇÃO NACIONAL SECRETARIA EXECUTIVA DEPARTAMENTO DE GESTÃO ESTRATÉGICA COORDENAÇÃO-GERAL DE TECNOLOGIA DA INFORMAÇÃO ENCARTE R ENCARTE R Estimativa de de Software Estimativa de de Software: Contratação de Serviços de Fábrica de Software Página 1 de 10 SUMÁRIO 1 REFERÊNCIAS... 3 1 INTRODUÇÃO... 3 3.1 ESTIMATIVA PRELIMINAR... 4

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

Ontologia de Domínio da Biodisponibilidade de Ferro: Uma Experiência no Projeto Nutri-Fuzzy-Orixás

Ontologia de Domínio da Biodisponibilidade de Ferro: Uma Experiência no Projeto Nutri-Fuzzy-Orixás Ontologia de Domínio da Biodisponibilidade de Ferro: Uma Experiência no Projeto Nutri-Fuzzy-Orixás Alessandra Brito F. Oliveira 1; Vera Maria Benjamim Werneck 1 ; Regina Serrão Lanzillotti 1 ; Haydée Serrão

Leia mais

CURSO: Tecnologia em Análise e Desenvolvimento de Sistemas SÉRIE: 3º Semestre TURNO: Noturno DISCIPLINA: ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS

CURSO: Tecnologia em Análise e Desenvolvimento de Sistemas SÉRIE: 3º Semestre TURNO: Noturno DISCIPLINA: ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS CURSO: Tecnologia em Análise e Desenvolvimento de Sistemas SÉRIE: 3º Semestre TURNO: Noturno DISCIPLINA: ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS CARGA HORÁRIA: 60 horas I - Ementa Modelagem de Processos

Leia mais

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos.

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos. A GESTÃO DE PROJETOS EXISTENTE NA NORMA DO-178B Matheus da Silva Souza, matheusdasilvasouza@gmail.com Prof. Dr. Luiz Alberto Vieira Dias, vdias@ita.br Instituto Tecnológico de Aeronáutica Praça Marechal

Leia mais

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional. Unidade 3: Modelagem de requisitos e de soluções (Parte a) 1 Casos de uso 1.1 Conceitos básicos e parâmetros de descrição Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

2. Sistemas Multi-Agentes (Multi-Agent System - MAS)

2. Sistemas Multi-Agentes (Multi-Agent System - MAS) AORML uma linguagem para modelagem de uma aplicação Multiagentes: Uma Aplicação no Sistema Expertcop. Hebert de Aquino Nery, Daniel Gonçalves de Oliveira e Vasco Furtado. Universidade de Fortaleza UNIFOR

Leia mais

Padrões de projeto 1

Padrões de projeto 1 Padrões de projeto 1 Design Orientado Objeto Encapsulamento Herança Polimorfismo Design Patterns 2 Responsabilidades Booch e Rumbaugh Responsabilidade é um contrato ou obrigação de um tipo ou classe. Dois

Leia mais

UML: Unified Modeling Language. Graduação em Informática 2008 Profa. Itana Gimenes

UML: Unified Modeling Language. Graduação em Informática 2008 Profa. Itana Gimenes UML: Unified Modeling Language Graduação em Informática 2008 Profa. Itana Gimenes Unified Modelling Language (UML) Não é uma linguagem de programação. Linguagem de modelagem visual utilizada para especificar,

Leia mais

guia prático 2a Edição Gilleanes T.A. Guedes Novatec

guia prático 2a Edição Gilleanes T.A. Guedes Novatec guia prático 2a Edição Gilleanes T.A. Guedes Novatec Copyright 2007, 2014 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

Leia mais

Análise e Projeto Orientados a Objeto

Análise e Projeto Orientados a Objeto Análise e Projeto Orientados a Objeto com UML e Padrões Parte I Análise, Projeto, e Processo Baseado em Craig Larman 1 Aplicando UML, Padrões e APOO Objetivo Desenvolver habilidades práticas na utilização

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Computação Sensível ao Contexto

Computação Sensível ao Contexto Computação Sensível ao Contexto Percepção de Contexto em Ambientes Domiciliares Modelagem de Contexto Modelagem de Contexto + Modelagem de Usuário Fabrício J. Barth novembro de 2004 Sumário O que já foi

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

É uma forma do engenheiro de requisitos especificar os limites e as funcionalidades do sistema.

É uma forma do engenheiro de requisitos especificar os limites e as funcionalidades do sistema. Definindo o Escopo: Modelo de Caso de Uso Agradei-me, particularmente, da possibilidade de que Joshua estivesse tão preso ao seu modo clássico de pensar que me permitisse realizar o incrível feito de chegar

Leia mais

ERACE-TOOL - UMA FERRAMENTA BASEADA EM CENÁRIOS PARA À ENGENHARIA DE REQUISITOS

ERACE-TOOL - UMA FERRAMENTA BASEADA EM CENÁRIOS PARA À ENGENHARIA DE REQUISITOS ERACE-TOOL - UMA FERRAMENTA BASEADA EM CENÁRIOS PARA À ENGENHARIA DE REQUISITOS João Caldas Júnior FIL- Fundação Paulista de Educação e Tecnologia Paulo C. Masiero ICMC - Universidade de São Paulo masiero@icmsc.sc.usp.br

Leia mais

DESENVOLVIMENTO DE APLICATIVO MÓVEL PARA AUXÍLIO NA PREVENÇÃO DE TRAGÉDIAS EM DECORRÊNCIA DE ENCHENTES

DESENVOLVIMENTO DE APLICATIVO MÓVEL PARA AUXÍLIO NA PREVENÇÃO DE TRAGÉDIAS EM DECORRÊNCIA DE ENCHENTES DESENVOLVIMENTO DE APLICATIVO MÓVEL PARA AUXÍLIO NA PREVENÇÃO DE TRAGÉDIAS EM DECORRÊNCIA DE ENCHENTES Autores: Luciano GONÇALVES JUNIOR, Natália Maria Karmierczak DA SILVA, Paulo César Rodacki GOMES,

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar

Leia mais

Modelagemde Software Orientadaa Objetos com UML

Modelagemde Software Orientadaa Objetos com UML Modelagemde Software Orientadaa Objetos com UML André Maués Brabo Pereira Departamento de Engenharia Civil Universidade Federal Fluminense Colaborando para a disciplina CIV 2802 Sistemas Gráficos para

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Explorando o cenário das Metodologias de Engenharia de Software Orientado a Agentes

Explorando o cenário das Metodologias de Engenharia de Software Orientado a Agentes 136 Explorando o cenário das Metodologias de Engenharia de Software Orientado a Agentes Eduardo Augusto Ferreira da Silva 1, Heder Dorneles Soares 1, Rafael Sampaio Rocha Machado 1 1 Instituto de Computação

Leia mais

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso...

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso... Projeto de Software usando UML Sumário Capítulo I : Casos de Uso...3 1. Modelo de Casos de Uso... 3 2. Diagramas de Casos de Uso... 3 3. Exemplo... 9 4. Conclusão... 13 Capítulo II : Levantamento de Classes...15

Leia mais

Análise Orientada a Objetos

Análise Orientada a Objetos Análise Orientada a Objetos Breve Histórico: Fim da década de 80: amadurecimento da Orientação a Objeto Década de 1990: diversas proposições a partir de diversos autores, como Booch, Rumbaugh e Jacobson.

Leia mais

Engenharia de Software I: Análise e Projeto de Software Usando UML

Engenharia de Software I: Análise e Projeto de Software Usando UML Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,

Leia mais

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre

Leia mais

Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil

Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil Ivan Guilherme 1, Jonas Queiroz 1, Caio Marques 2 1 Universidade Estadual Paulista, IGCE, DEMAC, Caixa

Leia mais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem

Leia mais

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

Leia mais

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE Tathiana da Silva Barrére Antonio Francisco do Prado Vitor César Bonafe E-mail: (tathiana,prado,bonafe)@dc.ufscar.br

Leia mais

Frameworks. Pasteur Ottoni de Miranda Junior

Frameworks. Pasteur Ottoni de Miranda Junior Frameworks Pasteur Ottoni de Miranda Junior 1-Definição Apesar do avanço das técnicas de desenvolvimento de software, a construção de software ainda é um processo extremamente complexo.a reutilização tem

Leia mais

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE Nelson Ribeiro de Carvalho Júnior 1 RESUMO Atualmente o cenário mundial cuja dependência do software está cada vez mais evidente requer que

Leia mais

7 Trabalhos Relacionados A idéia é tentar dar todas as informações que ajudem os outros a julgar o valor da sua contribuição; não apenas as informações que levem o julgamento a uma direção em particular.

Leia mais

Resumo. 1. Introdução. Abstract. 2. Motivação

Resumo. 1. Introdução. Abstract. 2. Motivação Um Estudo para a Definição de Processos das Gerências da Qualidade e da Configuração em um Ambiente Integrado para Apoio ao Desenvolvimento e Gestão de Projetos de Software Abdala, Martha A. D.; Lahoz,

Leia mais

Ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído

Ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído Ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído Ana Paula Chaves 1, Jocimara Segantini Ferranti 1, Alexandre L Erário 1, Rogério

Leia mais

Avaliação de Modelos i* com o Processo AIRDoc-i*

Avaliação de Modelos i* com o Processo AIRDoc-i* Avaliação de Modelos i* com o Processo AIRDoc-i* Cleice Souza 1, Cláudia Souza 1, Fernanda Alencar 2, Jaelson Castro 1, Paulo Cavalcanti 1, Monique Soares 1, Gabriela Guedes 1, Eduardo Figueiredo 3 1 Centro

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes

Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes Ana Paula Blois 1, 2, Karin Becker 2, Cláudia Werner 1 1 COPPE/UFRJ, Universidade Federal do Rio de Janeiro,

Leia mais

Uma Ferramenta para Geração Automática de Testes Funcionais e Protótipos de Interface a partir de Casos de Uso

Uma Ferramenta para Geração Automática de Testes Funcionais e Protótipos de Interface a partir de Casos de Uso Uma Ferramenta para Geração Automática de Testes Funcionais e Protótipos de Interface a partir de Casos de Uso Ernesto C. Brasil 1, Thiago C. de Sousa 2 1 Centro de Ensino Unificado de Teresina (CEUT)

Leia mais

Tecnologia para Sistemas Inteligentes Apontamentos para as aulas sobre. Introdução à Representação e Processamento de Ontologias: Framework O3f

Tecnologia para Sistemas Inteligentes Apontamentos para as aulas sobre. Introdução à Representação e Processamento de Ontologias: Framework O3f Tecnologia para Sistemas Inteligentes Apontamentos para as aulas sobre Introdução à Representação e Processamento de Ontologias: Framework O3f Luís Miguel Botelho Departamento de Ciências e Tecnologias

Leia mais

3. PARADIGMA ORIENTADO A OBJETOS

3. PARADIGMA ORIENTADO A OBJETOS Paradigmas de Linguagens I 1 3. PARADIGMA ORIENTADO A OBJETOS Este paradigma é o que mais reflete os problemas atuais. Linguagens orientada a objetos (OO) são projetadas para implementar diretamente a

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

modelagem do negócio (processos e objetos do negócio) modelagem de requisitos alocados ao software modelagem da solução de software

modelagem do negócio (processos e objetos do negócio) modelagem de requisitos alocados ao software modelagem da solução de software POO com UML Java Uso da linguagem UML(Unified Modeling Language) A UML, ou Linguagem de Modelagem Unificada, é a junção das três mais conceituadas linguagens de modelagem orientados a objectos (Booch de

Leia mais

Uma proposta de um processo prático para apoiar o reuso de software

Uma proposta de um processo prático para apoiar o reuso de software Uma proposta de um processo prático para apoiar o reuso de software Rosangela Kronig (UNIP) rkronig.mes.engprod@unip.br Ivanir Costa (UNIP) icosta@unip.br Mauro Spínola (UNIP) mspinola@unip.br Resumo A

Leia mais