Um Padrão para o Desenvolvimento de Software Baseado em Componentes Distribuídos 1

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

Download "Um Padrão para o Desenvolvimento de Software Baseado em Componentes Distribuídos 1"

Transcrição

1 Um Padrão para o Desenvolvimento de Software Baseado em Componentes Distribuídos 1 Eduardo Santana de Almeida Calebe de Paula Bianchini Antonio Francisco do Prado Luis Carlos Trevelin Departamento de Computação DC Universidade Federal de São Carlos UFSCar 1. Contexto O Padrão proposto está inserido no contexto do Desenvolvimento Baseado em Componentes Distribuídos (DBCD), onde a intenção é a criação de componentes distribuídos reutilizáveis para diferentes domínios de aplicações. 2. Motivação De maneira a motivar o uso do Padrão, parte de um domínio de Ordem de Serviços (OS) foi construído. O domínio possui componentes de negócio, como clientes, funcionários, ordens de serviço e tarefas. Outros requisitos não funcionais, como persistência em banco de dados, arquitetura distribuída e interfaces, também, foram utilizados no padrão. Adicionalmente, é utilizado um processo para o desenvolvimento de aplicações, reutilizando os componentes construídos. 3. Problema O Desenvolvimento Baseado em Componentes se preocupa com a criação de componentes que possam ser reutilizados em outras aplicações. A reutilização caracteriza-se pela utilização de produtos de software, em uma situação diferente daquela para qual estes produtos foram originalmente construídos [21]. Para aumentar a reutilização de software, pesquisas [8, 16, 21] apontam, como passo fundamental, a sistematização do processo de análise e criação de componentes para um determinado domínio de aplicações. Para que a reutilização possa ser efetiva, deve-se considerá-la em todas as fases do processo de desenvolvimento do software. Portanto, o Desenvolvimento Baseado em Componentes (DBC) deve oferecer métodos, técnicas e ferramentas que suportem desde a identificação e especificação dos componentes, referente ao domínio do problema, até o seu projeto e implementação em uma linguagem executável. Além disso, o DBC deve empregar inter-relações entre componentes já existentes, que tenham sido previamente testados, visando reduzir a complexidade e o custo de desenvolvimento do software [21]. Apesar das recentes e constantes pesquisas na área de DBC, ainda há carência de métodos, técnicas e ferramentas que suportem tanto o desenvolvimento quanto a reutilização de componentes, em aplicações de um determinado domínio. Outro problema importante relaciona-se com a dificuldade de integração das diferentes técnicas e ferramentas que apóiam o DBC. Considerando o caso de componentes distribuídos, como ocorre na rede Internet, com plataforma cliente e servidor, o problema é ainda maior. 1 Copyright (c) 2002, Eduardo Santana de Almeida. Permission is granted to copy for the SugarloafPLoP 2002 Conference. All other rights reserved.

2 Diferentes métodos, técnicas e ferramentas têm sido propostos para suportar o DBC, destacando-se as ferramentas CASE [7, 9, 17]. Entretanto, a maioria destes métodos, técnicas e ferramentas, cobrem parcialmente o DBC, principalmente no caso de aplicações distribuídas. Assim, o Padrão de DBCD permite: a integração de diferentes tecnologias, como UML [3, 12], Catalysis [5, 8], CORBA [1, 6, 14], e Java [11] em uma ferramenta CASE, para apoiar o DBC, particularmente o de aplicações distribuídas. A ferramenta CASE automatiza grande parte das atividades do DBC Distribuídos; cobrir todo o ciclo de vida dos componentes distribuídos, desde a fase de especificação, em alto nível de abstração, na ferramenta CASE, até a sua implementação em uma linguagem orientada a objetos; definir mudanças no código de comunicação dos componentes, de uma forma minimizada, com a utilização do padrão DAP (Distributed Adapters Pattern) [1]. 4. Solução Assim, combinando as idéias do método Catalysis de desenvolvimento de software baseado em componentes, a arquitetura CORBA para especificação dos componentes distribuídos, os frameworks baseado em Padrões e a ferramenta MVCase [15], definiu-se um padrão para o Desenvolvimento de Software Baseado em Componentes Distribuídos. O padrão cobre os três níveis de Catalysis, e é realizado em quatro passos: Definir Problema, Especificar Componentes, Projetar Componentes e Implementar Componentes, conforme mostra a Figura 1. Figura 1 Padrão de DBC Distribuídos. Segue-se uma apresentação de cada passo do padrão, instanciado para desenvolver componentes para um domínio de Ordem de Serviços, o qual faz parte de um domínio maior, 1 76

3 o de Gestão de Recursos de Negócio, conforme mostra a Figura 2. Embora o domínio de Ordem de Serviços não esteja completo, o exemplo serve para mostrar detalhes das técnicas empregadas, e os principais artefatos gerados em cada passo do padrão. Figura 2 Estrutura geral da Gestão de Recursos de Negócio. 4.1 Definir Problema Conforme mostra a Figura 3, as aplicações do domínio de Ordem de Serviços se dividem em três grandes módulos: o primeiro, Clientes, é responsável pelo cadastro e notificação dos clientes de uma determinada ordem de serviço. O segundo, Funcionários, é responsável pelo cadastro de funcionários e controle das tarefas da ordem de serviço. O terceiro, Relatórios, é responsável pela emissão de relatórios para a gerência, relacionados com a consulta de tarefas realizadas e pendentes, ordens de serviços de determinado cliente e dos funcionários responsáveis por cada tarefa. Figura 3 Domínio Ordem de Serviços. Neste primeiro passo do padrão, é dada ênfase no entendimento do problema, especificando-se o quê os componentes devem atender para solucionar o problema. Inicialmente, são identificados os requisitos do sistema, usando técnicas como storyboards ou mind-maps [16], visando representar as diferentes situações e cenários do domínio do problema. Em seguida, os requisitos identificados são especificados em Modelos de Colaborações [3, 8, 12], representando a coleção de ações e os objetos participantes. Finalmente, os modelos de colaborações são refinados em Modelos de Casos de Uso [3, 8, 12]. A Figura 4 resume o primeiro passo do padrão, onde um mind-map, definido na identificação dos requisitos do domínio Ordem de Serviços, é especificado num Modelo de 1 77

4 Colaborações, e, posteriormente, refinado e particionado em um Modelo de Casos de Uso, visando diminuir a complexidade e melhorar o entendimento do domínio do problema. 4.2 Especificar Componentes Figura 4 - Primeiro Passo do Padrão: Definir Problema. Este passo cobre o segundo nível de Catalysis, onde é descrito o comportamento externo do sistema de uma forma não ambígua. Na ferramenta CASE, o engenheiro de software refina as especificações do nível anterior, visando obter as especificações dos componentes. Esse passo tem início com o refinamento dos modelos do domínio do problema. Especifica-se o Modelo de Tipos [3, 8, 12], conforme mostra a Figura 5, mostrando atributos e operações dos tipos de objetos, sem se preocupar com a implementação. Ainda neste passo, pode-se utilizar o dicionário de dados para especificar cada tipo encontrado, e a Object Constraint Language (OCL) [3, 12], para detalhar o comportamento dos objetos, sem ambigüidades. Figura 5 Modelo de Tipos do passo Especificar Componentes. 17 8

5 Conforme mostra a Figura 6, o Modelo de Tipos é organizado em um Framework de Modelos de Tipos de componentes [4, 7], com os seus atributos e relacionamentos. O framework é reutilizado através do Modelo de Aplicação do Framework [4, 7], representando a dependência dos tipos do framework, com os tipos estendidos na aplicação. Os Modelos de Casos de Uso, do passo anterior, são refinados em Modelos de Interações representados pelos diagramas de seqüência [4, 7, 11], para detalhar os cenários de utilização dos componentes nas diferentes aplicações do domínio do problema. Figura 6 Segundo Passo do Padrão: Especificar Componentes. Em resumo, as atividades deste passo, realizadas pelo engenheiro de software, na ferramenta MVCase, compreendem a especificação do: a) Modelo de Tipos; b) Framework de Modelos de Tipos de componentes; c) Modelo de Aplicação do Framework, baseado nos Modelos de Tipo de componentes; e d) Modelos de Interações representados pelos diagramas de seqüência, baseado nos Modelos de Casos de Uso. Estes modelos são utilizados no próximo passo do padrão, para obter o projeto interno dos componentes. 4.3 Projetar Componentes Neste passo, o engenheiro de software faz o projeto interno dos componentes, conforme o terceiro nível de Catalysis. Agora, os detalhes de implementação são importantes, destacando-se: segurança, persistência, arquitetura distribuída e a linguagem de implementação. Como passo inicial, refina-se o Modelo de Tipos em Modelos de Classes de componentes, onde são modeladas as classes, e seus relacionamentos, preocupando-se com a definição dos componentes com suas interfaces, conforme mostra a Figura 7. Os Modelos de Interações, representados pelas técnicas dos diagramas de seqüência são refinados para mostrar detalhes de projeto dos comportamentos dos métodos dos em cada classe. 17 9

6 Figura 7 Modelo de Classes obtido do Modelo de Tipos. A partir do Modelo de Classes, pode-se construir o Modelo de Componentes [3, 8, 12], que mostra a organização e a dependência entre os componentes. O Modelo de Componentes pode reutilizar componentes de outros frameworks já existentes. Assim, podem ser reutilizados componentes de domínios relacionados com requisitos não funcionais, como, por exemplo, para criação de interfaces (GUI) [10], persistência em Banco de Dados (Persistencia) [10, 19, 23] e distribuição de componentes (Broker) [1, 10]. A Figura 8 mostra o Modelo de Componentes obtido do Modelo de Classes da Figura 7, fazendo reuso dos componentes dos frameworks GUI, Persistencia e Broker. Figura 8 Modelo de Componentes. A utilização de Padrões de Projeto do Catálogo de Gamma [10], Abstract Factory, Factory Method, e Singleton, na construção dos componentes, pode aumentar a sua reutilização. A Figura 9 mostra, por exemplo, os componentes do framework GUI. O componente AbstractToolkit permite criar componentes básicos de widgets, como frames, textfields, labels, botões, e demais elementos que compõem a interface do usuário. Para melhor visualização das interfaces, existem, ainda, outros widgets que compõem a interface do usuário, como: combobox, panel, e textarea que não aparecem na figura, assim como os componentes da biblioteca swing [11] do Java. Os componentes LinToolkit e WinToolkit 18 0

7 implementam os métodos definidos pelo componente AbstractToolkit para as plataformas Linux e Windows, respectivamente, mantendo a portabilidade da aplicação para diferentes ambientes. O framework GUI dispõe, ainda, de interfaces para cada tipo de widget, como: IFrame, ITextField, ILabel, e IButton. Os componentes WinFrame, LinFrame, WinTextField, LinTextField, WinLabel, LinLabel, WinButton, e LinButton implementam os widgets, conforme a plataforma de execução da interface. Figura 9 Framework GUI. Da mesma forma, têm-se os componentes dos demais frameworks, como no caso do framework Persistencia, que suporta a persistência das informações em banco de dados relacional. Baseia-se nos padrões de Projeto do Catálogo de Gamma, Singleton, Facade e outros, como PersistentObject [10, 23] e ObjectPool [10, 23]. A Figura 10 mostra componentes do framework Persistencia. O componente ConnectionPool, através de sua interface IConnectionPool, faz a gerência e conexão com o banco de dados utilizado na aplicação. O componente DriversUtil, com base em definições extensible Markup Language (XML) [22], contém as informações do banco de dados disponibilizadas, através de sua interface IDriverUtil. O componente TableManager gerencia o mapeamento de um objeto para tabelas do banco de dados, disponibilizando seus métodos pela interface ITableManager. O componente persistente da estrutura FacadePersistent, através de sua interface IPersistentObject, disponibiliza os valores que devem ser adicionados ao banco de dados, passando parâmetros ao componente TableManager. Figura 10 Framework Persistencia. Os componentes do framework Broker utilizam o Padrão Distributed Adapters Pattern (DAP) [1] para comunicação remota entre dois componentes. A técnica adotada pelo DAP 1 81

8 para oferecer esta funcionalidade é introduzir um par de componentes adaptadores, visando conseguir um melhor desacoplamento dos componentes dentro de uma arquitetura distribuída. Os adaptadores, basicamente, encapsulam a API, necessária para permitir o acesso remoto, para componentes Targets. Deste modo, componentes Sources de uma aplicação possuem autonomia em relação à camada de distribuição, e as mudanças nesta camada não causam impactos. A Figura 11 mostra a estrutura do framework Broker. Os componentes Source e Target abstraem regras de negócio, do domínio de um problema. A interface TargetInterface abstrai o comportamento do componente Target em um cenário distribuído. Tanto esta interface, como os componentes, Source e Target, não possuem código de comunicação. Estes três elementos constituem uma camada independente de distribuição. Os principais componentes do framework Broker são SourceAdapter e TargetAdapter. Estes elementos estão conectados a uma específica API de distribuição e encapsulam os detalhes de comunicação. SourceAdapter é um adaptador que isola o componente Source do código de distribuição. Reside na mesma máquina que o Source e trabalha como um proxy para o TargetAdapter. TargetAdapter reside em outra máquina, isolando o componente Target do código de distribuição. SourceAdapter e TargetAdapter, usualmente, residem em máquinas diferentes, e não interagem diretamente. TargetAdapter implementa a RemoteInterface usada para conectar com SourceAdapter. O componente Initializer reside na mesma máquina que os componentes Target e TargetAdapter, e é responsável pela criação dos componentes TargetAdapter e Target [1]. Figura 11 Estrutura do Framework Broker. A Figura 12 resume os principais artefatos e a seqüência de atividades do passo Projetar Componentes, que incluem: a) Refinamento dos Modelos de Tipos em Modelos de Classes; b) Refinamento dos Modelos de Interações; e c) Criação dos Modelos de Componentes, com reutilização de componentes já disponíveis. Figura 12 Terceiro passo do Padrão: Projetar Componentes. 1 82

9 4.4. Implementar Componentes Por último, após o projeto dos componentes, o engenheiro de software determina, na MVCase, que se faça a geração automática do código dos stubs e skeletons, e interfaces dos componentes. A Figura 13 mostra parte dos componentes projetados do Domínio Ordem de Serviços, e os respectivos códigos em IDL e Java gerados. A geração do código é feita com o utilitário idlj, nativo do Java Development Kit (JDK), disponibilizado na ferramenta. Resumindo, as principais atividades do passo Implementar Componentes, realizada pelo engenheiro de software, na ferramenta MVCase, incluem a geração dos códigos IDL e Java dos componentes distribuídos. 5. Consequências Figura 13 Quarto passo do Padrão: Implementar Componentes. O Padrão de Desenvolvimento de Software Baseado em Componentes Distribuídos oferece os seguintes benefícios: Modularidade: o Padrão permite separar os aspectos de distribuição, interface e persistência em banco de dados; Reutilização: através dos aspectos de modularidade oferecidos com a divisão em camadas, os desenvolvedores podem reutilizar os componentes para diversas aplicações do domínio construído, diminuindo a redundância de código; Automação Parcial: com o suporte da ferramenta MVCase, grande parte das atividades propostas no padrão podem ser executadas de forma automática. Mesmo com as vantagens listadas acima, as seguintes desvantagens podem ser apresentadas: Incremental número de classes [1]: com a utilização do padrão DAP, usa-se um par de adaptadores, componentes de inicialização e nomeação que são necessários; de qualquer modo, estas estruturas podem ser geradas através da automação parcial, utilizando a ferramenta MVCase; Conhecimento de outras tecnologias: com o uso do framework Persistencia, o engenheiro de software necessita conhecer tecnologias, como o XML, para definição das informações referentes aos sistemas gerenciadores de banco de dados, como porta de conexão, nome do usuário, senha, e outros. 1 83

10 6. Implementação Para suportar o padrão proposto para DBC Distribuídos, são utilizados diferentes métodos, técnicas e ferramentas, apresentados a seguir. 6.1 Método Catalysis O padrão baseia-se no método Catalysis [5, 8] para DBC, que é executado em três níveis: Definição do Domínio do Problema, onde é dada ênfase no entendimento do problema, especificando-se o quê o sistema deve atender para solucionar o problema; Especificação dos Componentes, onde é descrito o comportamento do sistema de uma forma não ambígua; e, Projeto Interno dos Componentes, onde define-se como serão implementados os requisitos especificados para os componentes. Catalysis fundamenta-se nos princípios de abstração, precisão e componentes plugin. O princípio abstração orienta o desenvolvedor na busca dos aspectos essenciais do sistema, dispensando detalhes que não são relevantes para o contexto do sistema. O princípio precisão tem como objetivo descobrir erros e inconsistências na modelagem e o princípio componentes plug-in suporta o reuso de componentes para construir outros sistemas. 6.2 Common Object Request Broker Architecture (CORBA) No DBC é necessário estabelecer uma relação formal entre os componentes e a aplicação que os utiliza, por meio de interfaces bem definidas. Para atender a este requisito, o padrão de DBC Distribuídos baseia-se na arquitetura CORBA [1, 6, 14], que é um padrão estabelecido pela Object Management Group (OMG) para suporte a objetos distribuídos. CORBA apresenta interfaces bem definidas e independentes de aplicações, através da Interface Definition Language (IDL), que se encaixa perfeitamente no contexto de DBC. Outros aspectos que motivaram o uso do CORBA foram: a independência de linguagem de programação, devido ao mapeamento da IDL para diversas linguagens; a portabilidade entre ambientes computacionais; e os serviços de Segurança, Nomeação e Notificação, oferecidos pela especificação. 6.3 Frameworks e Padrões Para especificar e construir componentes de software mais seguros, confiáveis, fáceis de manter e de utilizar, o DBC emprega técnicas de frameworks, baseados em Padrões [10, 12]. Framework é um conjunto de classes relacionadas, que fazem reuso de um projeto para classes específicas de software [10]. A utilização de padrões em sistemas complexos de softwares permite que soluções previamente testadas sejam reutilizadas, tornando o sistema mais compreensível, flexível, fácil de desenvolver e de manter. O objetivo do uso de padrões de software é a disseminação das soluções de desenvolvimento de software já existentes. O uso de padrões na construção de frameworks objetiva torná-los ainda mais flexíveis, e, principalmente, facilitar a reutilização dos componentes no desenvolvimento das aplicações. 6.4 Ferramenta MVCase Ferramentas CASE têm sido empregadas, com sucesso, no projeto ou reprojeto de sistemas a serem reconstruídos. Dentre as ferramentas CASE, destaca-se a MVCase [15], que suporta a especificação do sistema em linguagens de modelagem orientadas a objetos, gera código, automaticamente, em uma linguagem de programação orientada a objetos, a partir das especificações em alto nível, usando componentes distribuídos especificados em IDL. A MVCase utiliza uma arquitetura em três camadas para construção de componentes. As três camadas permitem que o engenheiro de software separe as aplicações clientes das 18 4

11 regras de negócio, e dos serviços de armazenamento em banco de dados, ou outro meio de armazenamento. Os componentes destas camadas podem ser distribuídos em diferentes plataformas, suportando aplicações cliente-servidor, que podem ser executadas pela internet. 7. Exemplo de Aplicação do Padrão Uma vez construídos, os componentes podem ser reutilizados pelas aplicações do domínio. A Figura 14 mostra os passos para o desenvolvimento das aplicações. Parte-se dos requisitos da aplicação e segue-se o ciclo de vida normal de desenvolvimento, que compreende: Especificar Aplicação, Projetar Aplicação, Implementar Aplicação e Testar Aplicação. As principais diferenças do ciclo de vida normal do software estão na reutilização dos componentes previamente construídos e na distribuição de objetos, baseado na arquitetura CORBA. Figura 14- Desenvolvimento de aplicações usando Componentes. Para melhor compreensão, o desenvolvimento será instanciado para uma aplicação que registra uma ordem de serviço, do domínio Ordem de Serviço (OS), cujos componentes foram construídos. 7.1 Especificar Aplicação Este passo tem inicio com o entendimento do problema, identificando-se os requisitos da aplicação. Antes de iniciar a especificação dos requisitos da aplicação, na MVCase, o engenheiro de software importa os componentes do domínio do problema, no caso OS, que serão reutilizados pela aplicação. Em seguida, o engenheiro de software especifica os requisitos em Diagramas de Casos de Uso e de Seqüência. A Figura 15 mostra o Caso de Uso RegistrarOrdemServico e o Diagrama de Seqüência do seu curso normal. 1 85

12 Figura 15 Diagrama de Caso de Uso e Seqüência. Continuando a modelagem, o engenheiro de software especifica o modelo de classes da aplicação. No caso, foi criada a classe FrameRegistrarOrdemServico, que reutiliza os serviços dos componentes do domínio OS. A Figura 16 mostra quatro componentes (sombreados), reutilizados na aplicação Registrar Ordem de Serviço. Figura 16 Componentes reutilizados para Aplicação Registrar Ordem de Serviço. 7.2 Projetar Aplicação As especificações do passo anterior são refinadas pelo engenheiro de software para obter o projeto da aplicação. Neste passo, são especificados os requisitos não funcionais, relacionados com: segurança da aplicação, arquitetura distribuída, linguagem de implementação, e outros. A Figura 17 mostra o diagrama de componentes do projeto da aplicação, onde foram adicionados os componentes DriversUtil, ConnectionPool, FacadePersistent e TableManager para tratar o acesso a banco de dados e os componentes OrdemServicoSourceAdapter, 1 86

13 TargetOrdemServico, Initializer e OrdemServicoTargetAdapter para tratar a distribuição dos objetos. 7.3 Implementar Aplicação Figura 17 Projeto da Aplicação. Com base no projeto da aplicação, o engenheiro de software utiliza o gerador de código da MVCase para fazer sua implementação. A Figura 18 mostra parte do código gerado para a aplicação Registrar Ordem de Serviço. Figura 18 Implementação da Aplicação Registrar Ordem de Serviço. Após a implementação da aplicação, o engenheiro de software passa para o último passo, que consiste em testar a aplicação. 1 87

14 7.4 Testar Aplicação Neste passo, o engenheiro de software realiza os testes com a aplicação, para verificar se a mesma atende aos requisitos especificados. Os testes ficam facilitados, considerando que os componentes reutilizados já foram previamente testados. A Figura 19 mostra o ambiente de execução e teste da aplicação, utilizando os pacotes de componentes GUI, Broker, Persistencia e OS numa arquitetura distribuída cliente e servidor. Figura 19 Teste da Aplicação de Ordem de Serviço. A aplicação pode ser executada em diferentes sistemas operacionais e CPUs, e os resultados das execuções são analisados pelo engenheiro de software, para verificar se atendem aos requisitos da aplicação. Estes resultados fornecem um feedback para os passos anteriores, orientando as correções. 8. Padrões Relacionados Abstract Factory, Factory Method e Singleton. O framework GUI é implementado usando os padrões de projeto [9] Abstract Factory, Factory Method e Singleton. Broker e Trader. O Broker [4] e o Trader [4] são padrões arquiteturais com o principal objetivo de permitir mecanismos de distribuição específicos, como empacotamentos de parâmetros e protocolos de mensagens. DAP usa estes padrões e provê um alto nível de abstração, com transparência de API de distribuição para ambos, clientes e servidores [1]. Wrapper-Facade [18] e DAP possuem objetivos comuns de minimizar variações no código das aplicações com mudanças de plataformas. De qualquer modo, Wrapper-Facade encapsula existentes APIs não orientadas a objetos (como sockets, threads), enquanto DAP encapsula APIs de distribuição orientada a objetos, como RMI (Remote Method Invocation) [20] e CORBA. Facade, PersistentObject e ObjectPool. O framework Persistencia é implementado usando os padrões de projeto Singleton e Facade, e, padrões para persistência em banco de dados [20], como PersistentObject e ObjectPool. 1 88

15 9. Agradecimentos Os autores gostariam de agradecer ao Shepherd Dr. Jugurta Lisboa Filho pelas criticas e sugestões recebidas durante o andamento deste processo. 10. Referências [1] ALVES, V., BORBA, P. Distributed Adapters Pattern: A Design Pattern for Object-Oriented Distributed Applications, I Conferência Latino Americana em Linguagens de Padrões para Programação. Rio de Janeiro [2] BEM-NATAN, R. CORBA A Guide to the Common Object Request Broker Architecture. Mc-Graw-Hill, [3] BOOCH, G. UML Guia do Usuário. Editora Campus, [4] BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P., STAL, M. Pattern Oriented Software Architecture: A System of Patterns. John Wiley & Sons, [5] CATALYSIS. Catalysis Enterprise Components with UML. Disponível: site URL: Consultado em 10/08/2001. [6] CORBA. The Common Object Request Broker: Architecture and Specification. Disponível: site OMG (1996). URL: Consultado em 10/04/2001. [7] COOL:GEN. Ferramenta Cool:Gen. Disponível: site URL: Consultado em 10/07/2001. [8] D SOUZA, D.; WILLS, A. Objects, Components and Frameworks with UML The Catalysis Approach. USA:Addison Wesley, [9] ERWIN. Ferramenta Erwin. Disponível: site URL: Consultado em 10/07/2001. [10] GAMMA, E. et al. Design Patterns. Elements of Reusable Object-Oriented Software. Ed. Addison-Wesley. USA [11] HORSTMANN, S, C. Core Java2 Volume2-Advanced Features. Sun Microsystems Hal [12] LARMAN, C. Utilizando UML e Padrões. Prentice Hall, Inc, [13] NETSCAPE. Introduction to SSL. Disponível site DevEdge OnLine (1998). URL: Consultado em 02/05/2001. [14] ORFALI, R., HARKEY, D. Client/Server Programming with Java and CORBA. John Wiley & Sons, Second Edition, [15] LUCRÉDIO, D., PRADO, A. F. Ferramenta MVCASE Estágio Atual: Especificação, Projeto e Construção de Componentes, XV Simpósio Brasileiro de Engenharia de Software, Sessão de Ferramentas. Outubro de [16] PRESSMAN, R. S. Software Engineering: A Practitioner's Approach. 5th Edition, june [17] ROSE. Ferramenta Rational Rose. Disponível: site URL: Consultado em 10/07/2001. [18] SCHMIDT, D., STAL, M., ROHNERT, H., BUSCHMANN, F. Pattern Oriented Software Architecture. John Wiley & Sons, [19] SOBRAL, D. Framework para Comércio Eletrônico Mediado por Agentes de Software. Dissertação de Mestrado. DC UFSCar fevereiro de [20] SUN. RMI Specification. Disponível: site URL: Consultado em 10/01/2002. [21] WERNER, C.M.L., BRAGA, R. M.M. Desenvolvimento Baseado em Componentes. XIV Simpósio Brasileiro de Engenharia de Software SBES2000 Minicursos e Tutoriais pg de Outubro,

16 [22] XML. Extensible Markup Language (XML) 1.0 Second Edition. Disponível: site URL: Consultado em 10/07/2001. [23] YODER, J.W., JOHNSON, R.E., WILSON, Q.D. Connecting Business Objects to Relational Databases. In: Conference on the PLOP, 5, Monticello-IL, EUA. Proceedings

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

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Edson Alves de Oliveira Junior 1, Itana Maria de Souza Gimenes 1 1 Departamento de

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

Palavras-chave: Desenvolvimento Baseado em Componentes (DBC), Transformação de Software, framework e ObjectPascal.

Palavras-chave: Desenvolvimento Baseado em Componentes (DBC), Transformação de Software, framework e ObjectPascal. Construção e Reutilização de de Software do Domínio de Cardiologia João L C Moraes, Daniel Lucrédio, Adriano A Bossonaro, Dr Rubens Tofano, Prof Dr Antonio F Prado DC/UFSCar - Departamento de Computação

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos 11 Objetivos Este capítulo apresenta uma introdução aos sistemas distribuídos em geral Arquiteturas de cliente servidor Características das arquiteturas de 2 e 3 camadas Ambiente

Leia mais

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br CORBA Common Object Request Broker Architecture Unicamp Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br Objetivos Apresentação Tecnologia CORBA Conceitos Básicos e Terminologia Considerações

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

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

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

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

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

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

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Capítulo VI CORBA. Common Object Request Broker Architecture. [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008.

Capítulo VI CORBA. Common Object Request Broker Architecture. [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008. Common Object Request Broker Architecture [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008. From: Fintan Bolton Pure CORBA SAMS, 2001 From: Coulouris, Dollimore and

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

Padrões de Projeto. Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson

Padrões de Projeto. Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson Padrões de Projeto Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson Apresentação Conceitos Definição Ponto de vista prático História Padrões de Projeto Conhecidos

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

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

INE5380 - Sistemas Distribuídos

INE5380 - Sistemas Distribuídos INE5380 - Sistemas Distribuídos Object Request Broker e CORBA Por: Léo Willian Kölln - 0513227-4 Novembro de 2006 ORB Object Request Broker ORB aqui será tratado como um Middleware que permite a construção

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

Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes

Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes Alexandro Deschamps (Ápice) alexandro@apicesoft.com Everaldo Artur Grahl (FURB/DSC) egrahl@furb.br Resumo. Uma das grandes

Leia mais

Web Services. (Introdução)

Web Services. (Introdução) Web Services (Introdução) Agenda Introdução SOA (Service Oriented Architecture) Web Services Arquitetura XML SOAP WSDL UDDI Conclusão Introdução Comunicação distribuída Estratégias que permitem a comunicação

Leia mais

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS Pág. CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 2.1 A tecnologia de orientação a objetos 25 2.1.1 Projeto de software

Leia mais

Definição de Padrões. Padrões Arquiteturais. Padrões Arquiteturais. Arquiteturas de Referência. Da arquitetura a implementação. Elementos de um Padrão

Definição de Padrões. Padrões Arquiteturais. Padrões Arquiteturais. Arquiteturas de Referência. Da arquitetura a implementação. Elementos de um Padrão DCC / ICEx / UFMG Definição de Padrões Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Um padrão é uma descrição do problema e a essência da sua solução Documenta boas soluções para problemas recorrentes

Leia mais

Protótipo tipo de software para geração de sistemas distribuídos. dos utilizando Design Patterns

Protótipo tipo de software para geração de sistemas distribuídos. dos utilizando Design Patterns Protótipo tipo de software para geração de sistemas distribuídos dos utilizando Design Patterns Aluno: Fabiano Oss fabiano@inf.furb.br Orientador: Everaldo A Grahl egrahl@furb.br Agenda Introdução; Objetivos;

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

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

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

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Soquetes Um soquete é formado por um endereço IP concatenado com um número de porta. Em geral, os soquetes utilizam uma arquitetura cliente-servidor. O servidor espera por pedidos

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

Sistemas Distribuídos

Sistemas Distribuídos Faculdades SENAC Análise e Desenvolvimento de Sistemas 28 de abril de 2010 Principais suportes de Java RMI (Remote Method Invocation), da Sun Microsystems DCOM (Distributed Component Object Model), da

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

Aplicação de design patterns no desenvolvimento de sistemas distribuídos

Aplicação de design patterns no desenvolvimento de sistemas distribuídos Aplicação de design patterns no desenvolvimento de sistemas distribuídos Fabiano Oss (FURB) fabiano.oss@benner.com.br Everaldo Artur Grahl (FURB) egrahl@furb.br Maurício Capobianco Lopes (FURB) mclopes@furb.br

Leia mais

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos

Leia mais

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Sobre entidades externas ao sistema Quais sistemas externos devem ser acessados? Como serão acessados? Há integração com o legado a ser feita?

Leia mais

Um Arcabouço open source em Python para DBC com

Um Arcabouço open source em Python para DBC com Um Arcabouço open source em Python para DBC com Suporte à Evolução Dinâmica não Antecipada Yguaratã C. Cavacanti 1, Hyggo Oliveira de Almeida 1, Evandro Costa 2 1 Instituto de Computação Universidade Federal

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Princípios de Sistemas Distribuídos. Tecnologias utilizadas em sistemas distribuídos Aula 5

Princípios de Sistemas Distribuídos. Tecnologias utilizadas em sistemas distribuídos Aula 5 Princípios de Sistemas Distribuídos Tecnologias utilizadas em sistemas distribuídos Aula 5 Conceitos de comunicação entre processos Interprocess Communication (IPC) Sistemas distribuídos são construídos

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

Componentes para Computação Distribuída

Componentes para Computação Distribuída Componentes para Computação Distribuída Conceitos Foi a partir do fenômeno da Internet (WWW), no início dos anos noventa, que a computação distribuída passou a ter relevância definitiva, a ponto de a Internet

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

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

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

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO UTILIZANDO O HIBERNATE Rafael Laurino GUERRA, Dra. Luciana Aparecida Martinez ZAINA Faculdade de Tecnologia de Indaiatuba FATEC-ID 1 RESUMO Este artigo apresenta

Leia mais

GERÊNCIA DINÂMICA DE REDE BASEADA NA TECNOLOGIA JAVA JMX

GERÊNCIA DINÂMICA DE REDE BASEADA NA TECNOLOGIA JAVA JMX GERÊNCIA DINÂMICA DE REDE BASEADA NA TECNOLOGIA JAVA JMX Por Francisco Adell Péricas Resumo Este artigo apresenta uma avaliação da proposta de desenvolvimento de aplicações de gerência de rede de acordo

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

Padrões Arquiteturais. Sistemas Distribuídos: Broker

Padrões Arquiteturais. Sistemas Distribuídos: Broker Padrões Arquiteturais Sistemas Distribuídos: Broker Sistemas Distribuídos Tendências: Sistemas Comp. com múltiplas CPUs Redes locais com centenas de hospedeiros Benefícios Economia Desempenho e escalabilidade

Leia mais

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros (regras de interação)

Leia mais

O modelo de arquitetura CORBA e suas aplicações

O modelo de arquitetura CORBA e suas aplicações ABR. MAI. JUN. 2004 ANO X, N º 37 157-163 INTEGRAÇÃO 157 O modelo de arquitetura CORBA e suas aplicações ANA PAULA GONÇALVES SERRA* Resumo Nos últimos anos, os sistemas de informação nas empresas têm evoluído

Leia mais

Laboratório de Computação VI JAVA IDL. Fabricio Aparecido Breve - 981648-9

Laboratório de Computação VI JAVA IDL. Fabricio Aparecido Breve - 981648-9 Laboratório de Computação VI JAVA IDL Fabricio Aparecido Breve - 981648-9 O que é Java IDL? Java IDL é uma tecnologia para objetos distribuídos, ou seja, objetos em diferentes plataformas interagindo através

Leia mais

RMI: Uma Visão Conceitual

RMI: Uma Visão Conceitual RMI: Uma Visão Conceitual Márcio Castro, Mateus Raeder e Thiago Nunes 11 de abril de 2007 Resumo Invocação de Método Remoto (Remote Method Invocation - RMI) trata-se de uma abordagem Java para disponibilizar

Leia mais

Desenvolvimento de um Framework, baseado em componentes, do domínio de Cardiologia João L C de Moraes, Adriano A Bossonaro, Antonio F do Prado

Desenvolvimento de um Framework, baseado em componentes, do domínio de Cardiologia João L C de Moraes, Adriano A Bossonaro, Antonio F do Prado 1 Desenvolvimento de um Framework, baseado em componentes, do domínio de Cardiologia João L C de Moraes, Adriano A Bossonaro, Antonio F do Prado Universidade Federal de São Carlos UFSCar, Departamento

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

Documento de Projeto de Sistema

Documento de Projeto de Sistema Documento de Projeto de Sistema 1 IFES / Serra Projeto: Gerenciador de Pelada - Oasis Registro de Alterações: Versão Responsável Data Alterações 0.1 Eduardo Rigamonte, Geann Valfré, João Paulo Miranda,

Leia mais

HIBERNATE EM APLICAÇÃO JAVA WEB

HIBERNATE EM APLICAÇÃO JAVA WEB HIBERNATE EM APLICAÇÃO JAVA WEB Raul Victtor Barbosa Claudino¹, Ricardo Ribeiro Rufino¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil victtor.claudino@gmail.com, ricardo@unipar.br Resumo: Este

Leia mais

Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW

Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW Baseado nos materiais dos profs: Prof.: Edilberto M. Silva http://www.edilms.eti.br Edna Canedo Marcio de Carvalho Victorino Brasília-DF,

Leia mais

Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software

Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software Itana M. S. Gimenes 1 itana@din.uem.br Radames J. Halmeman 1 radames@cm.cefetpr.br Fabrício R.

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

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

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

Novas Tecnologias para Construção do Prontuário Eletrônico do Paciente

Novas Tecnologias para Construção do Prontuário Eletrônico do Paciente Novas Tecnologias para Construção do Prontuário Eletrônico do Paciente Fabiane Bizinella Nardon 1, Sérgio Furuie 2, Umberto Tachinardi 3 Instituto do Coração do Hospital das Clínicas da Faculdade de Medicina

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. 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

Uma Introdução à Arquitetura CORBA. O Object Request Broker (ORB)

Uma Introdução à Arquitetura CORBA. O Object Request Broker (ORB) Uma Introdução à Arquitetura Francisco C. R. Reverbel 1 Copyright 1998-2006 Francisco Reverbel O Object Request Broker (ORB) Via de comunicação entre objetos (object bus), na arquitetura do OMG Definido

Leia mais

O Padrão Arquitetural Auto-Adaptável

O Padrão Arquitetural Auto-Adaptável MAC5715 - Tópicos Avançados em POO O Padrão Arquitetural Auto-Adaptável Raphael Y. de Camargo e Carlos Alexandre Queiroz 30 de outubro de 2003 1 Intenção O padrão auto-adaptável permite o desenvolvimento

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos

Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos Programação Avançada Padrões de Projeto de Software 1 Fonte: Oswaldo B. Peres e K19 Treinamentos Introdução Projetar software OO reusável e de boa qualidade é uma tarefa difícil; Para realizar essa tarefa

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

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

Arquitetura de Software. Silvia Regina Vergilio

Arquitetura de Software. Silvia Regina Vergilio Arquitetura de Software Silvia Regina Vergilio Atividades de Projeto Projeto Geral ou Preliminar: fase que traduz a especificação do sistema em termos da arquitetura de dados e de módulos. Descreve a organização

Leia mais

Objetos Distribuídos - Programação Distribuída Orientado a Objetos. Luiz Affonso Guedes

Objetos Distribuídos - Programação Distribuída Orientado a Objetos. Luiz Affonso Guedes Objetos Distribuídos - Programação Distribuída Orientado a Objetos Luiz Affonso Guedes Introdução Conceitos básicos programação distribuída + programação orientada a objetos = Objetos distribuídos Motivação

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

Ciência da Computação ENGENHARIA DE SOFTWARE. UML-Unified Modeling Language Linguagem de Modelagem Unificada

Ciência da Computação ENGENHARIA DE SOFTWARE. UML-Unified Modeling Language Linguagem de Modelagem Unificada Ciência da Computação ENGENHARIA DE SOFTWARE UML-Unified Modeling Language Linguagem de Modelagem Unificada Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução a linguagem UML

Leia mais

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS.

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS. PADRÕES DE SOFTWARE 1 Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade Grupo de Padrões de Software da UECE (GPS.UECE) Julho-2009 CONTEÚDO Introdução aos Padrões de Software O quê são padrões?

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

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

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO DESCRIÇÃO DO SIGAI O SIGAI (Sistema Integrado de Gestão do Acesso à Informação) é uma solução de software que foi desenvolvida para automatizar os processos administrativos e operacionais visando a atender

Leia mais

Suporte a Padrões no Projeto de Software

Suporte a Padrões no Projeto de Software Suporte a Padrões no Projeto de Software Alexandre Dantas, Gustavo Veronese Alexandre Correa, José Ricardo Xavier, Cláudia Werner {alexrd, veronese, alexcorr, xavier, werner}@cos.ufrj.br COPPE/UFRJ Programa

Leia mais

GERADOR DE APLICAÇÕES WEB BASEADO EM UMA LINGUAGEM DE PADRÕES DEFINIDA EM XML

GERADOR DE APLICAÇÕES WEB BASEADO EM UMA LINGUAGEM DE PADRÕES DEFINIDA EM XML GERADOR DE APLICAÇÕES WEB BASEADO EM UMA LINGUAGEM DE PADRÕES DEFINIDA EM XML GENERATOR WEB APPLICATION BASED ON A PATTERN LANGUAGE DEFINED IN XML Prof. Me Anderson Pazin a.pazin@gmail.com RESUMO Linguagens

Leia mais

Desenvolvimento de software orientado a características e dirigido por modelos

Desenvolvimento de software orientado a características e dirigido por modelos Desenvolvimento de software orientado a características e dirigido por modelos Universidade Federal de Uberlândia Rodrigo Reis Pereira Prof. Dr. Marcelo Almeida Maia Agenda Motivação Introdução Modelagem

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

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS Pablo dos Santos Alves Alexander Roberto Valdameri - Orientador Roteiro da apresentação Introdução Objetivos Motivação Revisão bibliográfica

Leia mais

Usando Borland DELPHI para implementar aplicações CORBA

Usando Borland DELPHI para implementar aplicações CORBA Página 1 de 10 USANDO BORLAND DELPHI PARA IMPLEMENTAR APLICAÇÕES CORBA por Simone Vey Dutra e César Bridi Introdução A Arquitetura CORBA Criando uma Aplicação CORBA em Delphi Criando um Servidor CORBA

Leia mais

Arquitetura de Software: Uma Central para Gestão da execução de serviços

Arquitetura de Software: Uma Central para Gestão da execução de serviços Arquitetura de Software: Uma Central para Gestão da execução de serviços ADILSON FERREIRA DA SILVA Centro Paula Souza São Paulo Brasil afs.software@gmail.com Prof.a. Dr.a. MARILIA MACORIN DE AZEVEDO Centro

Leia mais

UML 01. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan

UML 01. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Faculdade INED UML 01 Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Referências BARBIERI, Carlos. Análise e Programação

Leia mais

MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java

MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java Leonardo Gresta Paulino Murta Gustavo Olanda Veronese Cláudia Maria Lima Werner {murta, veronese, werner}@cos.ufrj.br COPPE/UFRJ Programa

Leia mais

Um sistema gerenciador de Workflow de acordo com o método Catalysis

Um sistema gerenciador de Workflow de acordo com o método Catalysis Um sistema gerenciador de Workflow de acordo com o método Catalysis Edson Alves de Oliveira Junior e Itana Maria de Souza Gimenes* Departamento de Informática, Universidade Estadual de Maringá, Av. Colombo,

Leia mais

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS

EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS Edson Alves de Oliveira Junior (1) Igor Fábio Steinmacher (2) eaojunio@bol.com.br ifsteinm@din.uem.br Edna Tomie Takano

Leia mais

Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br

Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br Padrões GoF Leonardo Gresta Paulino Murta leomurta@ic.uff.br Agenda Introdução Padrões de Criação Padrões de Estrutura Padrões de comportamento Leonardo Murta Padrões GoF 2 Introdução Os padrões GoF (Gamma

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

Curso - Padrões de Projeto Módulo 1: Introdução

Curso - Padrões de Projeto Módulo 1: Introdução Curso - Padrões de Projeto Módulo 1: Introdução Vítor E. Silva Souza vitorsouza@gmail.com http://www.javablogs.com.br/page/engenho http://esjug.dev.java.net Sobre o Instrutor Formação: Java: Graduação

Leia mais

GLOSSÁRIO. ActiveX Controls. É essencialmente uma interface usada para entrada e saída de dados para uma aplicação.

GLOSSÁRIO. ActiveX Controls. É essencialmente uma interface usada para entrada e saída de dados para uma aplicação. GLOSSÁRIO Este glossário contém termos e siglas utilizados para Internet. Este material foi compilado de trabalhos publicados por Plewe (1998), Enzer (2000) e outros manuais e referências localizadas na

Leia mais

Cliente/Servidor. Objetos Distribuídos. Graça Bressan. Graça Bressan/LARC 2000 1

Cliente/Servidor. Objetos Distribuídos. Graça Bressan. Graça Bressan/LARC 2000 1 Cliente/Servidor Objetos Distribuídos Graça Bressan Graça Bressan/LARC 2000 1 Objetos São entidades de software que encapsulam dados, ou atributos, e código e que são acessados através de funções ou métodos.

Leia mais

Camadas de Software - o Middleware. Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas. Aplicações. Middleware.

Camadas de Software - o Middleware. Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas. Aplicações. Middleware. Camadas de Software - o Middleware Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas Modelos de Arquitecturas para sistemas distribuidos Interfaces e Objectos Requerimentos para Arquitecturas Distribuídas

Leia mais