A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Componentes: A Abordagem Catalysis

Apresentações semelhantes


Apresentação em tema: "Componentes: A Abordagem Catalysis"— Transcrição da apresentação:

1 Componentes: A Abordagem Catalysis
Schubert Carvalho Thaise Yano Universidade Estadual de Campinas - UNICAMP Instituto de Computação - IC Disciplina de Engenharia de Software - MO409 Novembro/2004

2 Tópicos Introdução e Motivação
Características do Sistema Baseado em Componentes Formas de Visualização dos Componentes Componentes: Vantagens e Desvantagens Processo de desenvolvimento com Catalysis Modelos usados pela metodologia Ferramentas de Apoio Catalysis: Vantagens e Desvantagens Referências

3 Introdução e Motivação
Requisitos de Qualidade: manutenabilidade, portabilidade, confiabilidade, usabilidade, interoperabilidade e reusabilidade. Definição “Um componente de software é uma unidade de composição com interfaces especificadas e com dependências de contexto explícitas. Um componente de software pode ser desenvolvido independentemente e está sujeito a composição de terceiros” [4]. INTERFACE get_Qualquer_Coisa() set_Qualquer_Coisa() Introdução e Motivação: Entre os principais requisitos de qualidade de software segundo Pressman [1] estão a reusabilidade, manutenabilidade, portabilidade, confiabilidade, usabilidade e interoperabilidade. Dentre estes, a reusabilidade representa uma alternativa significativa para incrementar a produtividade e a qualidade no desenvolvimento e na manutenção do software. O desenvolvimento de software com reuso é uma abordagem que tenta maximizar a reutilização de componentes de software já existentes [3], ou seja, o desenvolvimento baseado em componentes permite que uma aplicação seja construída através da reutilização de componentes de software que já foram bem especificados e testados anteriormente. Um dos principais motivos para este reuso é a diminuição dos custos durante o processo de desenvolvimento [2]. Interface: A especificação de todas as funcionalidades de um componente de software é representada através de suas interfaces. Uma interface é uma coleção de operações que são utilizadas para especificar um serviço do componente [5]. Uma interface resume como um cliente deve interagir com o componente, escondendo detalhes de implementação (idéia da caixa preta), fornecendo ao cliente todas as informações que ele precisa para utilizar o componente. Métodos get_Quanquer_Coisa() e set_Quanquer_Coisa () podem ser utilizados para ler ou modificar os dados do componente [6]. Componente como uma Caixa preta: Um componente de software pode ser considerado como uma caixa preta onde suas interações ocorrem através de sua interface.

4 Características dos Sistemas Baseados em Componentes
O desenvolvimento do software é baseado em componentes que já existem. Fornecimento de interfaces bem definidas. Completa separação entre interfaces e implementação. Reutilização de especificação e projeto do componente. O projeto baseado em Componentes é diferente do projeto OO. O desenvolvimento do software é baseado em componentes que já existem: o principal objetivo do sistema baseado no desenvolvimento de componentes(CBD) é a reutilização de componentes já existentes para a construção de um sistema [7,8], ou seja, componentes são partes de software que podem ser combinadas para formar um sistema maior [8]. Fornecimento de interfaces bem definidas: a única maneira de um componente interagir com outro é através de suas interfaces. A especificação do componente deve descrever explicitamente todas as interfaces que o cliente pode acessar [8]. Completa separação entre interfaces e implementação: componentes de software necessitam que a especificação das suas interfaces estejam completamente separadas da sua implementação, pois a especificação da interface, ao invés do código, define o que o componente realmente irá fazer e o que esperar do mesmo quando ele for utilizado [8]. Reutilização de especificação e projeto do componente: a reutilização de um componente não significa, apenas, a reutilização do código. É possível, também, reutilizar a especificação e o projeto do componente [3]. Projeto Baseado em Componentes versus Projeto OO: quando a construção de um software é baseada no projeto de componentes, não existe a necessidade de saber como o sistema é representado na forma de objetos ou como instâncias de uma classe. Objetos são instâncias criadas durante a execução do sistema, através da execução de um código, este código faz parte de um componente. Considerando esta diferença, um objeto não é um componente. Ele é o código interno do componente que pode ser reutilizado [8].

5 Formas de Visualização dos Componentes
Componentes como implementação. Comercial Off-The-Shelf(COTS) Componentes como abstrações arquiteturais. Catalysis: é uma metodologia para o desenvolvimento sistemático de objetos e de sistemas baseados em componentes. Componentes de software podem ser visualizados em duas perspectivas: componentes como implementação e componentes como uma abstração arquitetural. Componentes como implementação: faz referência aos componentes de prateleira ou “Comercial Off-The-Shelf(COTS) Components” [1]. Os COTS podem implementar funcionalidades (o que o componente faz) e coordenação (como um componente interage com o mundo externo). Componentes como abstrações arquiteturais: componentes de software são referenciados como componentes arquiteturais. Estas arquiteturas são desenvolvidas utilizando metodologias baseadas na análise e no projeto de sistemas baseados em componentes, como a metodologia Catalysis [8]

6 Componentes: Vantagens
 Redução dos custos iniciais do sistema.  Aumento na confiança do sistema e na qualidade do software, com a reutilização de componentes que já foram bem testados e utilizados anteriormente.  O risco total no processo de desenvolvimento é reduzido se os componentes já existem.  O tempo no desenvolvimento do software pode ser reduzido.

7 Componentes: Desvantagens
 É difícil de quantificar a redução dos custos através da reutilização de componentes.  Alguns desenvolvedores preferem reescrever o código do componente aos invés de reutilizá-lo. É difícil de quantificar a redução dos custos através da reutilização de componentes: componentes de software devem ser entendidos e, as vezes, devem ser adaptados para trabalhar em um novo ambiente. Estes custos de reutilização, geralmente, são mais altos do que desenvolver um novo componente [3]. Alguns desenvolvedores preferem reescrever o código do componente: os desenvolvedores, geralmente, acreditam que podem melhorar a eficiência do componente. De certa forma, esta é uma conseqüência natural do processo de desenvolvimento que se concentra na desenvolvimento de softwares originais, ao invés de reutilizá-los [3].

8 Processo de Desenvolvimento
Não propõe um único processo de desenvolvimento Propõe padrões de processo O processo de desenvolvimento pode ser adaptado de acordo com suas características através dos padrões de processo Não propõe um único processo de desenvolvimento, mas Propõe padrões de processo: Catalysis não propõe um único processo de desenvolvimento e sim padrões de processo (process patterns) que auxiliam a planejar um projeto de acordo com sua necessidade, visto que não há um único processo que seja adequado a todos projetos: cada um possui diferentes pontos de partida, objetivos e restrições [8]. O processo de desenvolvimento pode ser adaptado de acordo com suas características através dos padrões de processo: existem diferentes modos de utilizar e adaptar Catalysis, sendo que os processos de desenvolvimento podem ter diferentes seqüências de tarefas e artefatos dependendo do que for mais apropriado às características do projeto. Para tanto são propostos padrões de projeto que descrevem alguns dos principais contextos de desenvolvimento e uma estratégia para cada um, sendo combinados para atender às necessidades de cada projeto. A idéia é que esses padrões formam um kit de ferramentas de desenvolvimento ao invés de um procedimento fixo [8].

9 Três Níveis de Modelagem
Domínio do problema “Lado de fora”: descreve o ambiente no qual o sistema está inserido Especificação do componente “Fronteira”: descreve os comportamentos externos desejados Projeto do componente “Lado de dentro”: descreve o projeto interno Embora Catalysis não proponha uma ordem para o desenvolvimento dos modelos, são indicados três níveis de modelagem em um projeto típico [8]: Domínio do problema: O termo domínio abrange todos os conceitos relevantes ao cliente e ao problema. Assim, descreve-se o ambiente no qual o sistema será inserido. Especificação do componente: Uma especificação do componente descreve a visão externa do seu comportamento com o ambiente, desse modo descreve-se o comportamento que é visível na fronteira entre o componente e seu ambiente. Nesse nível são definidas as ações que um componente ou objeto participa no seu ambiente. Projeto interno do componente: Nesse nível “abre-se a caixa” de um determinado componente e descreve como ele é projetado internamente a fim de prover o comportamento especificado. São descritas as diferentes partes que o compõe, suas conexões e interações.

10 Processo de desenvolvimento
“lado de fora” Entendimento do problema, contexto do sistema, arquitetura e dos requisitos funcionais e não funcionais Requisitos “fronteira” Descrição do comportamento externo do sistema alvo usando o modelo do domínio do problema Especificação do Sistema “lado de dentro” Arquitetura dos componentes e as conexões para alcançar os objetivos do projeto A Figura acima mapeia as atividades do processo de desenvolvimento para os três níveis de modelagem descritos no slide anterior. De certa maneira ainda existem três níveis conceituais: domínio (“lado de fora”), especificação do componente (“fronteira”) e projeto do componente (“lado de dentro”). Os requisitos e a análise estão principalmente envolvidos com o “lado de fora” e a “fronteira”, realizando desde a identificação e entendimento do problema até a especificação do componente visível externamente; o projeto enfatiza a estrutura interna e a arquitetura do componente [8]. Projeto da Arquitetura Proj. Interno do Comp. Projeto das interfaces e das classes para cada componente; construção e teste

11 Processo de desenvolvimento
“lado de fora” Requisitos “fronteira” Especificação do Sistema “lado de dentro” A Figura acima mapeia as atividades do processo de desenvolvimento para os três níveis de modelagem descritos no slide anterior. De certa maneira ainda existem três níveis conceituais: domínio (“lado de fora”), especificação do componente (“fronteira”) e implementação do componente (“lado de dentro”). Os requisitos e a análise estão principalmente envolvidos com o “lado de fora” e a “fronteira”, realizando desde a identificação e entendimento do problema até a especificação do componente visível externamente; o projeto enfatiza a estrutura interna e a arquitetura do componente [8]. Projeto da Arquitetura Proj. Interno do Comp.

12 Requisitos Entendimento do problema, requisitos funcionais e não funcionais, restrições arquiteturais e de planejamento Modelos Concept Map Diagrama de contexto Cenários Requisitos Entendimento do problema requisitos funcionais e não funcionais, restrições arquiteturais e de planejamento: A atividade de requisitos tem como principal objetivo entender o problema e como a solução proposta será direcionada. Os principais produtos são [8]: Modelo de negócio: colaborações, tipos e dicionários. Requisitos funcionais do sistema: normalmente na forma de diagrama de contexto do sistema através de use cases e cenários. Requisitos não funcionais: objetivos de desempenho, confiabilidade, escalabilidade e reuso. Restrições arquiteturais ou de plataforma conhecidas: máquinas, sistemas operacionais, distribuição, middleware, sistemas legados e requisitos de interoperabilidade, todos capturados por uma estrutura de pacote e colaborações. Restrições de projeto e planejamento: orçamentos, cronogramas, quadro de funcionários e envolvimento de usuários Modelos: As técnicas e construções específicas usadas para descrever o modelo de negócio e requisitos são: concept map, diagrama de contexto e cenários.

13 Concept Map Representação informal da estrutura dos principais termos e conceitos que são relacionados. Ajuda a obter uma visão geral do comportamento do sistema e suas funcionalidades. Representação informal da estrutura dos principais termos e conceitos relacionados: Como ponto inicial para o entendimento do problema, é feita uma representação informal porém estruturada dos principais termos e conceitos relacionados ao domínio através de um concept map, a fim de capturar o vocabulário usado e os relacionamentos entre os termos. Um concept map é simplesmente um grafo de nós e arestas (preferencialmente orientadas) rotuladas por verbos ou substantivos extraídos da idéia do problema [8]. Ajuda a obter uma visão geral do comportamento do sistema e suas funcionalidades: O concept map ajuda o desenvolvedor a obter uma visão geral do comportamento do sistema e suas funcionalidades. O desenvolvedor passa a ter uma visão mais clara do escopo que será considerado, além de obter uma primeira impressão acerca das classes que farão parte do sistema [8]. OBS: Nessa apresentação não será feita a explicação detalhada dos modelos devido ao tempo da apresentação e visto que na próxima apresentação serão mostrados os modelos para o estudo de caso do hotel.

14 Diagrama de Contexto Identifica os atores no domínio e suas interações
O diagrama de contexto identifica os atores no domínio e suas interações (as ações, ou use cases, e informações trocadas). Os atores tipicamente representam os papéis das pessoas que interagem com o sistema (tal como cliente) ou sistema de software (tal como sistema de controle de gastos). O diagrama ajuda a definir mais precisamente os limites do sistema com relação àqueles limites definidos nos concept map. Além disso, o desenvolvedor tem a idéia das operações do sistema e quais são os atores que interagem a fim de executar a operação. As ações nas quais o sistema em questão é um ator são aquelas que devem ser desenvolvidas como parte do sistema [8].

15 Cenários Ilustra uma seqüência na qual as ações acontecem
Cada cenário ilustra uma seqüência na qual as ações acontecem. Geralmente, o desenvolvimento de cenários ajuda na identificação de ações que ainda não foram descritas no diagrama de contexto. Representam quais são as ações e interações que são necessárias para que ocorra uma determinada operação [8]. Os atores que interagem nas ações são representados como setas verticais e setas horizontais representam as ações que são realizadas e unem os atores que interagem na ocorrência dessa ação.

16 Processo de desenvolvimento
“lado de fora” Requisitos “fronteira” Especificação do Sistema “lado de dentro” A Figura acima mapeia as atividades do processo de desenvolvimento para os três níveis de modelagem descritos no slide anterior. De certa maneira ainda existem três níveis conceituais: domínio (“lado de fora”), especificação do componente (“fronteira”) e implementação do componente (“lado de dentro”). Os requisitos e a análise estão principalmente envolvidos com o “lado de fora” e a “fronteira”, realizando desde a identificação e entendimento do problema até a especificação do componente visível externamente; o projeto enfatiza a estrutura interna e a arquitetura do componente [8]. Projeto da Arquitetura Proj. Interno do Comp.

17 Especificação do Sistema
Descreve o comportamento externo do sistema Modelos Especificação das operações Snapshots Modelo de tipos Especificação do sistema Descreve o comportamento externo do sistema: A especificação do sistema procura descrever o comportamento do sistema, visível externamente. Assim descreve-se o comportamento que é visível na fronteira entre o sistema e seu ambiente. São definidas as ações que um componente ou objeto participa no seu ambiente [8]. A especificação pode ser dividida em áreas de assuntos – áreas principais de uso ou função que ajuda a repartir o comportamento do sistema – assim uma área pode ser analisada separadamente das outras. Pacotes podem ser usados para estruturar todo trabalho de um sistema de larga escala através de múltiplas visões. Modelos: Os artefatos comuns da especificação do sistema são: modelo de tipo, especificação de operações e snapshots. Esses são acompanhados por protótipos e especificação de UI (user-interface) descrevendo as telas, fluxo de diálogo entre as janelas, informações apresentadas e requeridas, e relatórios. Esses elementos de interface-usuário deve-se manter consistente com o modelo de tipo e são revisados através de cenários [8].

18 Especificação das Operações
Definição de pré e pós condições em termos de entrada e atributos do objeto Operação AlteraReserva (nomeCliente, numReserva) Pré: Existe uma reserva em nome do cliente para um determinado tipo de quarto (x) e existe a disponibilidade de outros quartos (y). Pós: A reserva passa a ser para o tipo de quarto y. Quartos do tipo y passa a ter um quarto a menos disponível e quartos do tipo x passa ter uma quarto a mais disponível. Definição de pré e pós condições em termos de entrada e atributos do objeto: Inicialmente as operações são especificadas informalmente indicando as entradas requeridas pela operação, as mudanças no objeto e as saídas retornadas, e ainda as condições sob as quais o comportamento é garantido. Isso é feito através da definição de pré e pós condições [8]. Em seguida é preciso uma especificação formal das operações. Para isto é necessário: identificar entradas e saídas (valores retornados); identificar atributos (termos derivados das entradas das operações); identificar tipos para parâmetros de entrada/saída; formalizar a especificação da operação de modo a especificar saídas e mudanças de estados nos atributos, estritamente em termos de entradas e atributos do objeto; revisar e melhorar a especificação informal.

19 Snapshots Mostram o subconjunto de valores de atributos que existem antes e depois da execução de uma operação Mostram o subconjunto de valores de atributos que existem antes e depois da execução de uma operação: Para esclarecer como os atributos de um sistema são afetados por uma operação descrita no cenário, pode-se criar os snapshots. Eles mostram o subconjunto de valores de atributos que existem antes da execução de uma operação e depois desta. Na parte superior de um snapshot é representado os atributos antes da operação e, na parte inferior, os atributos após a operação, assim é possível visualizar e especificar precisamente os efeitos de uma operação. Os snapshots possuem o intuito de fornecer uma representação visual dos efeitos da operação, no entanto, eles podem ser expressos em forma de texto, indicando o valor de um atributo antes e depois da operação [8].

20 Modelos de Tipo Sistema representado como um tipo
Consiste de um modelo e um conjunto de operações sobre esse modelo Sistema representado como um tipo: Em Catalysis, um tipo especifica o comportamento externo de um objeto. Um tipo formaliza a noção baseada em assinatura de uma interface. Um componente pode implementar vários tipos, dependendo das interfaces que precisa oferecer a outros componentes [8]. No nível de especificação, o sistema que está sendo desenvolvido é representado como um tipo, que consiste de um modelo e um conjunto de operações sobre esse modelo (requisitos comportamentais). A definição inicial envolve a identificação de cada ação na qual o sistema a ser desenvolvido participa, especificando-a como uma operação sobre o tipo [8]. É representado por um retângulo, onde a parte superior identifica o nome do tipo, a parte central a sua interação com outros tipos e na parte inferior as operações na qual o tipo interage.

21 Processo de desenvolvimento
“lado de fora” Requisitos “fronteira” Especificação do Sistema “lado de dentro” A Figura acima mapeia as atividades do processo de desenvolvimento para os três níveis de modelagem descritos no slide anterior. De certa maneira ainda existem três níveis conceituais: domínio (“lado de fora”), especificação do componente (“fronteira”) e implementação do componente (“lado de dentro”). Os requisitos e a análise estão principalmente envolvidos com o “lado de fora” e a “fronteira”, realizando desde a identificação e entendimento do problema até a especificação do componente visível externamente; o projeto enfatiza a estrutura interna e a arquitetura do componente [8]. Projeto da Arquitetura Proj. Interno do Comp.

22 Projeto Arquitetural Implementação interna do sistema Modelos
Arquitetura da aplicação Arquitetura técnica Projeto arquitetural Implementação interna do sistema: A implementação interna do sistema é divida em duas partes relacionadas [8]: a arquitetura da aplicação e a arquitetura técnica. Modelos: Os principais produtos são: arquitetura da aplicação e arquitetura técnica.

23 Arquitetura Técnica Mostra a colaboração entre componentes de tecnologia e as dependências estáticas Mostra a colaboração entre componentes de tecnologia e as dependências estáticas: Uma estrutura de pacote (para dependências estáticas) e colaborações (entre componentes de tecnologia, tais como UI, servidores e banco de dados). Abrange todas as partes independentes de domínio do sistema: hardware e plataforma de software; componentes de infra-estrutura tal como middleware e banco de dados; utilitários para logging, exceções, ligar e desligar; ferramentas; e a escolha da arquitetura do componente, tal como JavaBeans ou COM. Também inclui-se as regras de projetos e padrões que serão usados na implementação. A arquitetura técnica é projetada e implementada no início e é avaliada juntamente com os requisitos não funcionais tal como o tempo de resposta [8].

24 Arquitetura da Aplicação
Implementa a lógica do negócio como uma coleção de componentes que se colaboram Implementa a lógica do negócio como uma coleção de componentes que se colaboram: Uma estrutura de pacote ou colaborações (descrição de um conjunto de ações entre um grupo de objetos). Implementa a lógica do negócio como uma coleção de componentes que se colaboram [8].

25 Processo de desenvolvimento
“lado de fora” Requisitos “fronteira” Especificação do Sistema “lado de dentro” A Figura acima mapeia as atividades do processo de desenvolvimento para os três níveis de modelagem descritos no slide anterior. De certa maneira ainda existem três níveis conceituais: domínio (“lado de fora”), especificação do componente (“fronteira”) e implementação do componente (“lado de dentro”). Os requisitos e a análise estão principalmente envolvidos com o “lado de fora” e a “fronteira”, realizando desde a identificação e entendimento do problema até a especificação do componente visível externamente; o projeto enfatiza a estrutura interna e a arquitetura do componente [8]. Projeto da Arquitetura Proj. Interno do Comp.

26 Implementação do Componente
Estrutura interna e interações do componente Modelos Diagrama de interação Diagrama de classes Diagrama de estados Implementação do componente Estrutura interna e interações do componente: O objetivo da implementação do componente é definir uma estrutura interna e interações que satisfaçam os requisitos comportamentais, tecnológicos, não funcionais e de engenharia de software para um componente [8]. Modelos: São desenvolvidos: os diagrama de classes, diagrama de interação e diagrama de estados.

27 Diagrama de Interação Especifica como os objetos interagem com outros para atingir o resultado de uma operação Especifica como os objetos interagem com outros para atingir o resultado de uma operação: A notação do diagrama de interação é semelhante ao de cenário, no entanto semanticamente possuem diferenças. No diagrama de interação representa-se as operações e respostas (setas tracejadas) a essas operações por parte dos atores do sistema. Uma representação de uma operação feita por um diagrama de interação, pode ser detalhada em termos das ações que compõe essa operação (cenários). Para cada operação especificada, identifica-se um objeto para “receber” a operação requisitada. Identificado o receptor da operação, constrói-se um diagrama de interação a fim de especificar como os objetos interagem com outros para atingir o resultado da operação [8]. Para construir o diagrama de interação: Use os snapshots criados na análise para definir a configuração inicial do objeto Identifique as requisições recebidas por cada objeto como uma operação sobre a classe Identifique os atributos de classe para indicar o que cada classe precisa considerar antes e depois de cada requisição recebida.

28 Diagrama de Classe Classes que compõe o sistema, seus atributos, operações e associações Classes que compõe o sistema, seus atributos, operações e associações: Um componente pode ser projetado e implementado internamente como um conjunto de classes que implementa as interfaces requeridas externamente e que também realiza as interações internas. O modelo de classes consiste das classes que compõe o sistema, seus atributos e operações, e as associações entre elas. O modelo inicial de classe é derivado considerando cada modelo de tipo para uma classe, adicionando as operações que a classe precisa implementar do diagrama de interação e projetando os atributos e as associações que a classe precisa para implementar as operações [8]. Na parte superior da representação de uma classe descreve-se o nome da classe, na parte intermediária são descritos os atributos e na parte inferior as operações.

29 Diagrama de Estados Representa os estados de uma classe
O diagrama de estados pode ser representado por state charts que representariam os estados de uma classe, ou seja, as condições de uma classe após a realização de uma transição – que em Catalysis correspondem a ocorrência de uma operação [8].

30 Ferramentas de Apoio Ferramentas de apoio à modelagem UML
Rational Rose ArgoUML Visual Paradigm Como Catalysis é centrada na UML, podem-se utilizar as ferramentas de apoio à modelagem de objetos UML [8] para a construção e validação dos artefatos do processo de desenvolvimento de Catalysis, tais como: Rational Rose, ArgoUML e Visual Paradigm.

31 Desvantagens Não provê um modo pré-definido do processo de desenvolvimento Não há recurso para teste Não provê um modo pré-definido do processo de desenvolvimento: Catalysis provê exemplos do processo mas não fornece um conjunto fixo de milestones, e nem um modo pré-definido do processo de desenvolvimento [7]. Isso apesar de tornar a metodologia flexível, pode causar também uma certa dificuldade para o entendimento e aprendizado da metodologia. Não há recurso para teste: Catalysis não proporciona qualquer recurso, para explicitamente, fazer a execução de testes. Seria necessário um plano de teste independentes para se verificar a validade do sistema.

32 Vantagens Desenvolvimento flexível Centrada em UML
Mapeamento para implementação Coerência Além das vantagens do desenvolvimento baseado em componentes, alguns pontos forte de Catalysis são: Desenvolvimento flexível: a separação de níveis de decisão e os padrões de processo torna Catalysis apropriado para diversos projetos, que podem ser de pequena ou larga escala [8]. Centrada em UML: aprendizado mais fácil para aqueles já possuem conhecimento em UML ou outras metodologias orientadas a objeto, visto que Catalysis adota muitos aspectos conceituais e práticos dessas metodologias [8]. Mapeamento para implementação: O mapeamento da especificação para a implementação tende a ser facilitada com o uso de Catalysis [8]. Várias visualizações do sistema facilitam essa visão em termos de implementação, tais como cenários e diagramas de interação que representam quais as entidades que se relacionam para a realização das operações. Coerência: há um grande relacionamento entre os diferentes modelos, sendo fornecidas diferentes visões que podem ser utilizadas em conjunto [8].

33 Referências [1] Pressman, R.S. Software Engineering – A practitioner´s approach. McGraw-Hill, 5ª edition, 2001. [2] Brown A.W., The Current State of CBSE. IEEE, 1998. [3] Sommerville I. Software Engineering. Addison Wesley. 5ª edition, 1996. [4] Szypersky, C. Component Software: Beyond Object-Oriented Programming. Addison-Wesley Publishing Company, ACM Press, New York 1998. [5] Booch G., Rumbaugh J. & Jacobson I.. The Unified Modeling Language User Guide. Addsion-Wesley, 1999. [6]Flanagan D. Java in a Nutshell. A Desktop Quick Reference. O´REILLY. , 3ª edition, 1999. [7] Boertien N., Steen M.W.A., Jonkers H.. Evaluation of Component-Based Development Methods [8] D´Souza D.F., Wills A.C. Objects, Components, and Frameworks with UML. The Catalysis Approach. Addsion-Wesley


Carregar ppt "Componentes: A Abordagem Catalysis"

Apresentações semelhantes


Anúncios Google