Você está na página 1de 89

Universidade de Braslia

Instituto de Cincias Exatas Departamento de Cincia da Computao

Engenharia de Software baseada em componentes: uma abordagem prtica em ambientes Web.

Felipe Castaon de Oliveira Leonardo Lopes de Paula

Monograa apresentada como requisito parcial para concluso do Bacharelado em Cincia da Computao

Orientador Prof. Fernando Antonio de A. Chacon de Albuquerque

Braslia 2009

Universidade de Braslia UnB Instituto de Cincias Exatas Departamento de Cincia da Computao Bacharelado em Cincia da Computao

Coordenador: Prof.a Marcus Vinicius Lamar

Banca examinadora composta por: Prof. Fernando Antonio de A. Chacon de Albuquerque (Orientador) CIC/UnB Prof. Fernanda Lima CIC/UnB Prof. Genana Nunes Rodrigues CIC/UnB

CIP Catalogao Internacional na Publicao Oliveira, Felipe Castaon de. Engenharia de Software baseada em componentes: uma abordagem prtica em ambientes Web. / Felipe Castaon de Oliveira, Leonardo Lopes de Paula. Braslia : UnB, 2009. 88 p. : il. ; 29,5 cm. Monograa (Graduao) Universidade de Braslia, Braslia, 2009. 1. Engenharia de Software, 2. Componentes, 3. ESBC, 4. Processo de Desenvolvimento de Software, 5. Reuso CDU 004

Endereo:

Universidade de Braslia Campus Universitrio Darcy Ribeiro Asa Norte CEP 70910-900 BrasliaDF Brasil

Universidade de Braslia
Instituto de Cincias Exatas Departamento de Cincia da Computao

Engenharia de Software baseada em componentes: uma abordagem prtica em ambientes Web.

Felipe Castaon de Oliveira Leonardo Lopes de Paula

Monograa apresentada como requisito parcial para concluso do Bacharelado em Cincia da Computao

Prof. Fernando Antonio de A. Chacon de Albuquerque (Orientador) CIC/UnB

Prof. Fernanda Lima CIC/UnB

Prof. Genana Nunes Rodrigues CIC/UnB

Prof.a Marcus Vinicius Lamar Coordenador do Bacharelado em Cincia da Computao

Braslia, 04 de Dezembro de 2009

Agradecimentos
Em especial a Deus. Aos nossos pais, a famlia, aos amigos e a todos os professores que nos ajudaram a percorrer e vencer esse caminho.

Resumo
Este trabalho visa apresentar o desenvolvimento de um sistema construdo com a utilizao de componentes de software e guiado por um processo bem denido. Um processo baseado na abordagem de reuso de componentes ser estudado e utilizado em um estudo de caso. Ao nal, uma descrio da experincia adquirida com esse processo ser feita, assim como os resultados obtidos durante sua execuo. Palavras-chave: Engenharia de Software, Componentes, ESBC, Processo de Desenvolvimento de Software, Reuso

Abstract
This work presents the development of a system constructed with the use of softwares components and guided by a well dened process. A process based on the approach of reuse of components will be studied and utilized in a case study. The last chapters describes the experience adquired, just as the results obtained during its execution. Keywords: Software Engineering, Components, CBSE, Software Development Process, Reuse

Sumrio
1 Introduo 1.1 Processo de desenvolvimento de software baseado em componentes . 1.2 O trabalho apresentado . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Componentes 2.1 Denies de componentes de software . . . . . . . . . . . . . . . 2.1.1 Caractersticas de componentes . . . . . . . . . . . . . . . 2.2 Processo de desenvolvimento orientado a componentes . . . . . 2.3 Aspectos do desenvolvimento de componentes de software . . . 2.3.1 Processo para especicao de requisitos de componentes 2.3.2 Tipos de arquitetura . . . . . . . . . . . . . . . . . . . . . 2.3.3 Componentes arquiteturais em trs camadas . . . . . . . 2.3.4 Teste de componentes . . . . . . . . . . . . . . . . . . . . . 2.3.5 Documentao de componentes . . . . . . . . . . . . . . . 3 Processos de desenvolvimento de software 3.1 Fases do processo de desenvolvimento de software . . . . . . 3.1.1 Especicao . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Projeto e implementao . . . . . . . . . . . . . . . . . 3.1.3 Validao e testes . . . . . . . . . . . . . . . . . . . . . 3.1.4 Implantao e manuteno . . . . . . . . . . . . . . . 3.2 Processos de desenvolvimento . . . . . . . . . . . . . . . . . . 3.2.1 Processos em cascata . . . . . . . . . . . . . . . . . . . 3.2.2 Processos iterativos . . . . . . . . . . . . . . . . . . . . 3.2.3 Processos geis . . . . . . . . . . . . . . . . . . . . . . 3.3 Engenharia de Software Baseada em Componentes (CBSE) 3.3.1 Caractersticas da CBSE . . . . . . . . . . . . . . . . . 3.3.2 Diferena entre CBSE e outros processos . . . . . . . 3.4 Exemplos de Processos Baseados em Componentes . . . . . . 3.4.1 O processo de desenvolvimento em V . . . . . . . . . . 3.4.2 O processo de desenvolvimento Catalysis . . . . . . . 3.4.3 O processo descrito por Cheesman e Daniels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 3 3 4 6 8 8 9 9 11 12 13 13 14 14 15 15 15 16 16 17 17 18 18 20 20 22 23 26 26 27

4 O detalhamento do processo descrito por Cheesman e Daniels 4.1 Denio dos requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Especicao do sistema . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.1 Identicao dos componentes . . . . . . . . . . . . 4.2.2 Levantamento das interaes entre componentes . 4.2.3 Especicao dos componentes . . . . . . . . . . . 4.3 Seleo de Componentes . . . . . . . . . . . . . . . . . . . 4.4 Montagem do Sistema . . . . . . . . . . . . . . . . . . . . 4.5 Teste e Implantao . . . . . . . . . . . . . . . . . . . . . . 5 Tecnologias para desenvolvimento de componentes 5.1 COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 COM+ . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 NET . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Tipos de Beans . . . . . . . . . . . . . . . . . . . 5.2.2 Entidades . . . . . . . . . . . . . . . . . . . . . 5.2.3 Bean/Container managed persistence . . . . . 5.2.4 Callbacks e Listeners . . . . . . . . . . . . . . . 5.2.5 Interceptors . . . . . . . . . . . . . . . . . . . . 5.2.6 Jboss Seam . . . . . . . . . . . . . . . . . . . . . 6 Estudo de caso: Sistema de Alocao de Salas 6.1 Viso e escopo do sistema . . . . . . . . . . . . 6.2 Principais funcionalidades . . . . . . . . . . . . 6.2.1 Manter requerentes . . . . . . . . . . . . 6.2.2 Manter sala . . . . . . . . . . . . . . . . 6.2.3 Manter software . . . . . . . . . . . . . . 6.2.4 Solicitar software . . . . . . . . . . . . . 6.2.5 Reservar sala . . . . . . . . . . . . . . . 6.3 Modelagem conceitual do negcio . . . . . . . . 6.4 Identicao das interfaces do sistema . . . . . 6.5 Modelagem de tipo de negcio . . . . . . . . . . 6.6 Arquitetura de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 31 32 34 35 36 37 37 37 38 38 39 40 41 42 43 43 45 45 47 47 48 48 48 50 50 52 54 55 57 57 59 59 59 62 62 64 66 67 68 68 70 70

7 Anlise da utilizao do processo 7.1 Levantamento de requisitos . . . . . . . . . . . . . . . . . 7.2 Especicao dos componentes - A modelagem . . . . . . 7.2.1 Identicao dos componentes . . . . . . . . . . . . 7.2.2 Denio da interao dos componentes . . . . . . 7.2.3 Especicao dos componentes . . . . . . . . . . . 7.2.4 A exceo do projeto. . . . . . . . . . . . . . . . . . 7.3 Denio da arquitetura do projeto . . . . . . . . . . . . . 7.4 Codicao dos componentes . . . . . . . . . . . . . . . . . 7.4.1 Adaptaes do processo . . . . . . . . . . . . . . . . 7.4.2 Problemas encontrados e refatorao dos modelos 7.4.3 Documentao . . . . . . . . . . . . . . . . . . . . . 7.5 Integrao dos componentes e validao do sistema . . . 7.6 O sistema desenvolvido . . . . . . . . . . . . . . . . . . . .

8 Concluso Referncias

74 76

Lista de Figuras
2.1 Processo de desenvolvimento baseado a componentes. . . . . . . . . . 3.1 Processo de desenvolvimento iterativo. . . . . . . . . . . . . . . . . . . 3.2 Processo de desenvolvimento em V baseado em componentes. . . . . 3.3 Fases do processo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Os trs estgios do uxo de especicao. . . . . . . . . . . . . . . . . 4.2 Fase de montagem da aplicao. . . . . . . . . . . . . . . . . . . . . . . 5.1 Arquitetura EJB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 Atores e casos de uso. . . . . . . . . . . . . . . . . . . . Diagrama de caso de uso para solicitao de software. Diagrama de caso de uso para reservar de sala. . . . . Modelagem Conceitual do Negcio. . . . . . . . . . . . Mapeamento do ManterRequerente. . . . . . . . . . . Mapeamento do Manter Software. . . . . . . . . . . . Modelo do Tipo de Negcio. . . . . . . . . . . . . . . . . Arquitetura dos Componentes. . . . . . . . . . . . . . Diagrama de caso de uso para gesto de requerentes. Modelo do Tipo de Negocio. . . . . . . . . . . . . . . . . Primeira verso da arquitetura de componentes. . . . Exemplo de descrio textual na modelagem. . . . . . Exceo personalizada do projeto. . . . . . . . . . . . . Diviso dos Projetos. . . . . . . . . . . . . . . . . . . . Arquitetura padro por componente. . . . . . . . . . . Exemplo de atualizao da modelagem. . . . . . . . . Documentao Javadoc utilizada. . . . . . . . . . . . . Tela de pesquisar software. . . . . . . . . . . . . . . . Tela de pesquisar reservas de sala. . . . . . . . . . . . Tela de pesquisar requerente. . . . . . . . . . . . . . . Tela de visualizar sala. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 16 21 24 28 35 39 46 49 51 52 53 54 55 56 58 60 61 63 64 65 66 69 69 71 72 73 73

Captulo 1 Introduo
Este trabalho visa apresentar o desenvolvimento de uma aplicao baseada no reuso de componentes. Segundo Sommerville (1): "O componente uma entidade executvel independente. O cdigo-fonte no est disponvel, de modo que o componente no compilado com outros componentes do sistema. Os componentes publicam suas interfaces e todas as interaes so feitas por meio destas. A interface de um componente expressa em termos de operaes parametrizadas e seu estado interno nunca exposto". Segundo Miguel Pacheco(2), "O desenvolvimento de software baseado em componentes visto como uma abordagem que permite simultaneamente reduzir custos, minimizar o tempo necessrio para o desenvolvimento de um projeto e aumentar sua qualidade". A construo de componentes requer cuidado, pois seus requisitos devem ser especicados e compreendidos de maneira isolada do contexto de um sistema especco. Componentes devem prover interfaces que sejam claras para que um cliente possa utiliz-los sem conhecer seus cdigos-fonte. A aplicao de um processo que enfatiza o reuso de componentes o objetivo de estudo desse trabalho.

1.1

Processo de desenvolvimento de software baseado em componentes

Um processo de desenvolvimento de software inclui, divididas em eventuais fases, as seguintes disciplinas: Especicao e anlise de requisitos; Modelagem do sistema; Implementao e teste de unidade; Integrao do sistema; Validao do sistema; Suporte operacional e manuteno do sistema; Desinstalao do sistema. 1

Como outros processos denidos para o desenvolvimento de software, processos baseados em componentes so divididos em fases que atendem s disciplinas citadas anteriormente. Entretanto, nos processos baseados em componentes, essas disciplinas so adaptadas para maximizar o reuso de componentes, podendo-se necessitar de atividades especialmente voltadas para isso(3)(4). A primeira atividade o levantamento dos requisitos do sistema. Aps esta, deve-se identicar os componentes candidatos para incluso no sistema. Com os componentes escolhidos, deve-se revalidar os requisitos com o objetivo de alter-los, ou adapt-los, aos componentes selecionados. No projeto da arquitetura do sistema ser feita a seleo dos componentes a serem utilizados. Por m, o desenvolvimento do sistema pode ser feito atravs da utilizao dos componentes selecionados e sua adaptao para as necessidades do sistema.

1.2

O trabalho apresentado

O objetivo do trabalho realizado estudar e aplicar um processo de desenvolvimento baseado em componentes. Esse processo est detalhado e ser aplicado ao estudo de caso escolhido. Em seguida, a experincia obtida nesse projeto ser apresentada. O estudo de caso envolve o desenvolvimento de componentes para um sistema para alocao de salas em laboratrios de informtica, sendo que esse desenvolvimento segue as atividades descritas no processo adotado e produz os respectivos artefatos. Uma biblioteca de componentes ser construda para esse tipo de sistema, com o objetivo de aplicar o processo para o desenvolvimento de software e quais so suas principais caractersticas. Conceitos, disciplinas, caractersticas, processos e tecnologias acerca da Engenharia de Software Baseada em Componentes (CSBE) sero apresentados ao decorrer do documento. Ao nal da leitura, espera-se que esses conceitos tenham sido compreendidos e que uma anlise prtica, feita pelos autores, sirva como exemplo da aplicabilidade dos componentes. Este trabalho est organizado da seguinte forma. O referencial terico apresentado em quatro captulos que relacionam os principais tpicos investigados: Engenharia de Software baseada em componentes (Capitulo 2); processos de desenvolvimento de software baseados em reuso (Capitulo 3); detalhamento do processos escolhido (Capitulo 4); e uma viso das tecnologias utilizadas no desenvolvimento de componentes (Capitulo 5). Em seguida, dois captulos descrevem o uso deste referencial terico em um estudo de caso prtico: o sistema de alocao de salas em laboratrios de informtica (Capitulo 6) e a anlise sobre a experincia adquirida na implantao desse processo (Capitulo 7). As consideraes nais so apresentadas no Capitulo 8.

Captulo 2 Componentes
Este captulo abordar diversas denies dadas ao termo componente na rea de Engenharia de Software. Para isso, sero apresentados conceitos sobre o que so componentes, segundo vrios autores dessa rea. Em seguida, ser apresentada a denio adotada ao longo do trabalho.

2.1

Denies de componentes de software

A primeira vez que se citou componentizao para o desenvolvimento de software foi em 1968, durante uma conferncia de Engenharia de Software nos Estados Unidos. Nela McIlory(5) apresenta uma proposta de produzir software reutilizvel e propiciar aos desenvolvedores a possibilidade de escolher os componentes que querem utilizar segundo as suas necessidades. Em 1976, DeRemer(6) prope um paradigma de desenvolvimento baseado na construo de mdulos independentes e depois interlig-los. Na dcada de 80, surge o paradigma de orientao objetos que fortaleceu esta visa pela possibilidade de reutilizao. Com a necessidade de construir software de forma rpida e com qualidade, no nal dos anos 90 surgiu a proposta de desenvolvimento reutilizando componentes. Uma das suas motivaes foi a frustrao dos projetistas de software com o desenvolvimento orientado a objetos, que no conseguia atingir amplo nvel de reuso, como esperado originalmente (1). Algumas denies acerca do termo componente, aceitas na rea de Engenharia de Software, esto listadas a seguir: A denio dada por Clemens Szyperski(7): "Um componente uma unidade de composio com interfaces especicadas contratualmente e com dependncias de contexto explcitas; um componente de software pode ser implantado de forma independente ou se combinar com outros"; A denio de Jed Harris, presidente da CI Labs(7): "Um componente um pedao de software pequeno o suciente para criar e dar manuteno, grande o suciente para implantar e suportar e com interfaces padro para a interoperabilidade";

Grady Booch, em 1987 (8): "Um componente de software uma unidade coesa e de baixo acoplamento que denota a simples abstrao de um servio"; Judith Hurwitz, Presidente da CEO de Hurwitz Group(9): "Um componente um pacote de software que contm uma coleo de servios relacionados e atributos que abrangem a funcionalidade completa de algum problema do negcio". Devido variedade de denies sobre o que um componente, possvel confundir sua denio com a de um framework. Para isso, adotou-se neste trabalho a denio de Schmidt(10) para framework: "Um framework uma estrutura de classes inter relacionadas, que corresponde a uma implementao incompleta para um conjunto de aplicaes de um domnio. Esta estrutura de classes deve ser adaptada para a gerao de aplicaes especcas". Este trabalho utilizar a denio de Clemens Szyperski(7) sobre o que um componente. Sendo assim, a diferena entre um framework e um componente que a comunicao entre componentes estabelecida pelo contrato descrito pela interface do mesmo, enquanto em um framework provido um conjunto de classes interrelacionados nas quais este relacionamento foi denido pelo projeto do framework. Muitas vezes o uso de um framework dene qual tipo de arquitetura deve-se utilizar, mas componentes so mdulos independentes deste contexto. importante observar que podem existir frameworks baseados em componentes(11) que so bibliotecas de componentes com implicaes diretas sobre a arquitetura da aplicao.

2.1.1

Caractersticas de componentes

O desenvolvimento de software baseado no reuso de componentes deve considerar duas caractersticas: o desenvolvimento de componentes e o desenvolvimento com componentes. O desenvolvimento de componentes representa uma abordagem para desenvolver os componentes em si. Envolve disciplinas como especicar, desenvolver, testar, documentar e publicar verses dos componentes. O desenvolvimento com componentes signica adotar um processo de desenvolvimento de software baseado no reuso de componentes. Idealmente conta-se com a existncia de uma biblioteca de componentes e a partir dela pode-se selecionar os componentes desejados, adapt-los e utiliz-los no software a ser desenvolvido. Uma caracterstica dos componentes o encapsulamento, atributo que busca prover o critrio de visibilidade dos componentes do sistema. Ela diz que os componentes devem esconder a lgica de sua implementao. Componentes fornecem servios especcos descritos por suas interfaces e devem prover artefatos que descrevam os contratos estabelecidos por seus mtodos. Outra caracterstica o reuso. Para obt-la, as especicaes do componente devem ser feitas planejando um comportamento e fornecendo uma funcionalidade, mas esse comportamento deve ser exvel para permitir o reuso. Quanto mais genrica for a especicao do componente, maior ser sua taxa de reuso. Componentes devem atingir nveis esperados de conabilidade. Eles devem ser independentes do sistema ao qual se integram. Por isto, devem garantir sua prpria segurana, tolerncia a erros e estratgia para tratamento de excees. 4

Outra caracterstica a funcionalidade do componente. Ela faz referncia caracterizao de um componente como uma unidade independente para desenvolvimento e implantao. Documentao e testes devem ser feitos sem considerar o contexto onde ele utilizado, mas sim os requisitos especicados durante seu projeto. Uma caracterstica ligada funcionalidade do componente o desempenho. Este est associado ao nmero de solicitaes do usurio que so atendidas pelo componente e o tempo de resposta para cada uma dessas solicitaes. Para se obter um bom resultado deve-se levar em considerao a reduo da comunicao entre os componentes. Tambm necessrio viabilizar uma maneira de interagir com outros componentes. Como no vivel desenvolver um sistema inteiro sobre um nico componente, componentes devem possibilitar uma troca de informaes com outros componentes. Pode-se chamar isso de composio de componentes, onde um fornece servios ao outro e, possivelmente, vice-versa, conhecendo apenas as interfaces providas. Por m, a manuteno dene que o uso dos componentes na arquitetura utilizada favorece o encapsulamento destes e a sua modicao. Este o atributo mais complexo de se desenvolver, sendo tambm o mais dispendioso dos custos do projeto. Um grave problema pode ocorrer ao utilizar um componente que no tenha o cdigo-fonte disponvel, pois se o sistema requisitar mudanas, os custos de projetar e implementar o componente pode inviabilizar sua utilizao. Segundo Sommerville(1) alguns pontos a serem considerados dentro da manuteno so: Faltam ferramentas de apoio ao desenvolvimento baseado em componentes, pois muitas das ferramentas disponveis no consideram a abstrao dos componentes; H diculdade em se encontrar prossionais que sejam qualicados o suciente para compreender o processo de desenvolvimento de componentes. Muitos prossionais especializados em orientao a objetos no compreendem como agrupar objetos em um componente. Alm disso, alguns desenvolvedores acreditam que seu trabalho superior ao dos demais e, por isso, no gostam de desenvolver baseando-se em algo que no foi feito por eles mesmo ou adquirido atravs dos sistemas de prateleiras (Commercial-off-the-shelf - COTS), refazendo cdigo ao invs de reutilizar componentes. Geralmente os componentes so agrupados no que se chama de biblioteca de componentes, uma hierarquia para classicao, catalogao e recuperao dos mesmos. Esta biblioteca deve prover uma fcil localizao dos componentes para que eles sejam reutilizados. Quando se trabalha com os componentes de prateleiras (COTS), algumas vantagens so asseguradas. Por exemplo: a conana nos componentes, pois estes foram utilizados e testados em outros sistemas; os erros sero detectados mais rapidamente, minimizando os riscos do projeto; consegue-se estipular o custo com os componentes, facilitando a gerncia do projeto.

2.2

Processo de desenvolvimento orientado a componentes

Atualmente, no desenvolvimento de projetos, vem crescendo cada vez mais a complexidade do desenvolvimento de software, a minimizao dos prazos de entrega e a requisio por uma maior qualidade do produto. Neste sentido, o processo de desenvolvimento baseado em componentes traz uma abordagem que melhora a orientao a objetos, no que tange reutilizao de componentes. Essa abordagem possibilita que os componentes se integrem atravs de interfaces e conectores estando disponveis em bibliotecas. Existem alguns princpios no processo de desenvolvimento baseado em componentes. Segundo Pressman(12) destacam-se os seguintes: Princpio Aberto e Fechado: "Um componente deveria ser aberto para extenso, mas fechado para modicao."; Princpio da Substituio de Liskov: "Subclasses devem ser substituveis por suas classes-bases."; Princpio da Segregao de Interface: "Muitas interfaces especcas de clientes so melhores do que uma interface de propsito geral."; Princpio da Inverso de Dependncia: "Cone nas abstraes. No cone nas concretizaes.". O processo de desenvolvimento baseado em componentes vem sendo aceito como um processo eciente de construo de software de alta complexidade. Por outro lado, as organizaes tm diculdades para fazer modicaes em seus processos para adoo de prticas para o reuso. Essa no uma atividade de fcil execuo e, por isso, necessita de treinamento para as equipes. A adaptao s novas tecnologias, denio de novas necessidades do processo e a seleo das ferramentas adequadas fazem com que o processo de desenvolvimento baseado em componentes exija prossionais instrudos. Para denir um processo baseado em componentes, algumas atividades devem ser seguidas. O processo Catalysis(13), por exemplo, dene atividades como: Especicao de Requisitos; Especicao do Sistema; Projeto de Arquitetura; Projeto Interno dos Componentes; Implementao e teste do Sistema; Armazenamento dos Componentes em Bibliotecas. Com base nesse processo, apresentado uma simplicao do desenvolvimento baseado em componentes na gura 2.1. 6

Figura 2.1: Processo de desenvolvimento baseado a componentes.

O processo poder adotar duas abordagens diferentes que so o projeto com componentes e o projeto de componentes. Como este diagrama prope uma abordagem genrica nele se encontram as duas abordagens. Primeiramente, busca-se por componentes que j estejam prontos e sejam adequados especicao do sistema. Estes componentes de prateleiras (COTS) so muito teis no processo de desenvolvimento, pois geralmente foram usados em diversos sistemas. Normalmente contm menos erros, so mais robustos e conveis e, na maioria das vezes, minimizam os custos no desenvolvimento. Contudo, pode-se adotar a abordagem de construo dos componentes. Nela procura-se, com base na especicao do mesmo, selecionar a equipe que ir desenvolv-lo e produzir o componente. Mas essa abordagem costuma ser mais lenta 7

pelo fato de que o novo produto tem que passar pelas fases de validao e testes, enquanto os COTS so apenas utilizados. Passa-se para o estgio de projeto de arquitetura aps o desenvolvimento dos componentes. Nesta fase importante denir a organizao dos componentes para facilitar a integrao do sistema, denindo as estruturas de controle, os protocolos de comunicao, os padres de projeto e as interfaces. Todas estas atividades devem buscar a organizao do sistema de forma a facilitar a compreenso pelos desenvolvedores. Na fase de desenvolvimento tem-se a concretizao do componente em cdigo. Passando para o teste que vericar a correteza do cdigo, se o componente atende aos requisitos funcionais e no funcionais especicados e se o cdigo desenvolvido no infringe a denio de componente. Encontrando-se erros ou falhas, estes devem ser reportados e corrigidos. Aps estas fases, diversos componentes sero desenvolvidos. A nalizao do projeto consistir em, alm de obter o sistema nalizado, documentar e catalogar os componentes desenvolvidos.

2.3

Aspectos do desenvolvimento de componentes de software

O desenvolvimento de um componente, a ser integrado a uma biblioteca para futuro reuso, inclui atividades bsicas como: projeto do componente, considerando os tipos de sistemas aos quais ele dever ser integrado, implementao do componente, teste em diferentes ambientes, documentao das interfaces e manuteno do componente em verses futuras(14).

2.3.1

Processo para especicao de requisitos de componentes

Alguns processos para especicar requisitos so: UML Component(15), Catalysis(13) e Kobra(16). Com base nestes, algumas atividades em comum podem ser destacadas. Primeiramente, para especicar os componentes necessrio ler os documentos inicias do sistema, como Viso e Escopo, Documento de Especicao de Requisitos (SRS) e os modelos de casos de uso. Em seguida, necessrio centrar a especicao no que o componente deve prover e vericar quais so os requisitos deste componente especco. Passando, ento, para um esboo do componente, como se fosse um prottipo, podendo-se revisar e validar se o componente atende aos atributos citados anteriormente. Projetos fracassam por criarem uma soluo correta para o problema errado ou por que resolvem de maneira errada o problema certo. Compreender bem os requisitos um fator que auxiliar no sucesso de um projeto. Neste sentido, a especicao dos requisitos deve eliminar as ambiguidades do sistema que surgem pelo uso da linguagem natural.

2.3.2

Tipos de arquitetura

Um exemplo de arquitetura para projetos que envolvam o reuso de componentes Service Oriented Architecture, SOA , pois nela dividi-se as funcionalidades do sistema nos chamados servios. Esses servios representam para os requisitos o mesmo que os componentes representam para a arquitetura da aplicao. Sendo assim, pode-se dizer que um sistema que ser desenvolvido utilizando uma arquitetura SOA pode ser visto como uma composio de funcionalidades e essas funcionalidades podem ser desenvolvidas baseadas em componentes. O Gartner Group descreve SOA da seguinte maneira(17): "Mais do que uma tecnologia, SOA tambm inuencia regras e processos de negcios, alm de muitas vezes implicar reengenharia de software simultaneamente". Apesar das facilidades apresentadas em se trabalhar com SOA e componentes, no se pode restringir um ao outro. O desenvolvimento de componentes tambm pode ser usado quando so empregados outros estilos de arquiteturas.

2.3.3

Componentes arquiteturais em trs camadas

Uma especicao da qualidade para produtos de software, em diversos domnios de aplicao, mostrou a inuncia do domnio da aplicao no grau de importncia das propriedades de qualidade(18). Evidenciou-se que a importncia dada aos atributos de qualidade pode variar conforme a forma ou o nvel de abstrao em que o produto est sendo avaliado. Uma abordagem da funo arquitetural, atravs dos resultados obtidos em uma pesquisa de campo realizada em (18), demonstra a inuncia da mesma nas caractersticas de qualidade e na validao de um conjunto de atributos de qualidade para componentes de software. Para abordar o estudo acerca de componentes e suas caractersticas de qualidade, estes sero classicados em quatro grupos: interface, negcio, persistncia e infra-estrutura, de acordo com sua funo arquitetural. O primeiro grupo de componentes abordados o de interface, que engloba componentes responsveis por mostrar ao usurio as funcionalidades do sistema e realizar a troca de informaes entre usurios e sistemas ou entre sistemas diferentes. A caracterstica reuso descrita como uma das mais importantes para esse grupo. Compreende sub-caractersticas como: capacidade para ser instalado, acessibilidade e adaptabilidade, que so teis em tcnicas de montagem rpida de componentes, como montagem e validao de prottipos de telas no ambiente do usurio. Por serem responsveis pela interao com os usurios e obter informaes destes, este grupo mais suscetvel a mudanas, como uma alterao no estilo da pgina, disposio das tabelas ou formato dos campos apresentados. Para o desenvolvimento de componentes para a camada de interface, pode-se utilizar alguns padres de projeto(19): Intercepting Filter: Usado para interceptar e manipular requisies ou respostas, antes ou depois da concluso do servio solicitado; Front Controller: Usado para centralizar o ponto de acesso de requisies camada de apresentao; 9

Context Object: Busca acoplar lgicas de protocolos especcos e evitar que elas sejam tratadas pelo resto do sistema; View Helper: Separa a tela a ser apresentada da lgica utilizada na sua construo; Dispatcher View: Faz com que a tela tenha um pouco de lgica de negcio, sendo capaz de ela mesma tratar certas requisies. O prximo grupo est relacionado lgica do negcio e considerado o grupo de componentes mais difcil de ser adaptado. Isso porque este grupo tem uma forte conexo entre as regras especcas do sistema e o componente desenvolvido. No se pode dizer que isso destri sua caracterizao como um componente, pois mesmo sendo especco a um sistema, ele ainda pode ser utilizado em diferentes partes desse sistema e sistemas acerca do mesmo tipo de negcio. Questes como adequao dos servios, corretura, acurcia e segurana so importantes para esses componentes, assim como a caracterstica funcionalidade, responsvel por essas questes. Durante o desenvolvimento de um componente de negcio, alguns aspectos devem ser destacados. Justamente por trabalhar com a parte de negcio do sistema, eles devem ter um escopo muito bem denido para no se sobrecarregarem demais e no elevarem sua dependncia a outros componentes do sistema. Um exemplo seria ao desenvolver um componente de negcio para uma aplicao em Java Server Faces (JSF) no xar sua ligao com uma determinada classe de controle, mas sim criar um genrico o suciente para poder ser utilizado em qualquer sistema que necessite dessa funcionalidade. Ao projetar-se um componente de negcio, pode-se utilizar os seguintes padres de projeto(19): Business Delegate: Usado para esconder dos clientes a complexidade de comunicao remota entre componentes; Service Locator: Transparece o modo de localizao dos componentes de negcio e uniformaliza essa busca; Session Facade: Expe os servios de negcio aos clientes remotos; Application Service: Tenta centralizar diversas lgicas de negcio feitas nas variadas camadas desse tipo. O terceiro grupo de componentes o responsvel pela persistncia dos dados, devendo ter uma grande preocupao com integridade dos dados. Por ser este o grupo responsvel por efetuar as operaes com o banco de dados, deve garantir que nenhuma informao seja visualizada ou alterada sem o conhecimento e a autorizao do software. Durante o projeto de um componente de persistncia, o projetista deve ter preocupaes com o controle de acesso aos dados, suporte a transaes e tratamento de excees lanadas pelo prprio banco de dados. Erros lanados devem ser interceptados e repassados prxima camada de uma forma aceitvel dentro do sistema e sua linguagem, como o lanamento de excees ou envio de mensagens. 10

Para essa camada, pode-se utilizar os seguintes padres de projeto(19): Data Access Object: o padro DAO busca encapsular todo tipo de manipulao e acesso aos dados persistentes em uma camada isolada das de negcio da aplicao; Domain Store: busca separar a persistncia, em si, do modelo adotado na aplicao normalmente manipulando super classes em detrimento de classes mais especializadas; Web Service Broker: prov servios que utilizam XML e protocolos web (no caso de Java, serializao para transmisso de objetos persistentes pela rede). O ltimo grupo de componentes o que est ligado infra-estrutura do software. Ele deve fornecer suporte comunicao entre componentes distintos e permitir a comunicao entre diferentes partes do sistema, ou entre subsistemas. Uma prtica comum utilizar middlewares para realizar essa comunicao, evitando o desenvolvimento desse grupo de componentes em projetos. Outra soluo considerada a utilizao de um framework para integrar os componentes. O desenvolvimento dos componentes para infra-estrutura deve ser feito levandose em conta um elevado ndice de portabilidade, principalmente porque devem ser esses os componentes responsveis por trabalhar na camada mais prxima do hardware entre todos os componentes em um sistema.

2.3.4

Teste de componentes

"O teste consiste em executar o programa com a inteno de encontrar erros", segundo MYERS (20). Um processo de desenvolvimento que adie o teste, at que todos os componentes possam ser montados em um sistema completo, uma proposio arriscada. Defeitos encontrados tardiamente no ciclo de vida sero mais difceis de consertar e, provavelmente, provocaro atrasos na programao, principalmente se forem problemas arquiteturais que exijam um novo projeto para serem corrigidos. Sobre as abordagens de teste para os componentes, pode-se dizer que, assim como qualquer outro tipo de teste, tem-se duas principais tcnicas: caixa-preta ou caixa-branca(20). Tambm chamada de teste estrutural ou orientado lgica, a tcnica de caixa-branca avalia o comportamento interno do componente de software. Essa tcnica trabalha diretamente sobre o cdigo fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de uxo de dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados. A outra principal tcnica para teste dita caixa-preta. Tambm chamada de teste funcional, orientado a dado ou orientado a entrada e sada, avalia o comportamento externo do componente de software, sem considerar o comportamento interno do mesmo. Dados de entrada so fornecidos, o teste executado e o resultado obtido comparado a um resultado esperado, previamente conhecido. Para execuo automtica de testes de unidade em cdigo Java, pode-se utilizar a ferramenta JUnit. Esta ferramenta realiza testes de unidade nos componentes, passando classe por classe, executando os mtodos de uma maneira individual. A 11

cada unidade de teste denido um conjunto de mtodos, de dados de entrada e de sada associados a cada estmulo. As entradas so parmetros e as sadas so o valor de retorno, excees ou os estados do objeto.

2.3.5

Documentao de componentes

Um aspecto importante para o desenvolvimento de um componente sua documentao, pois sem uma documentao apropriada, o componente provavelmente no ser reutilizado. Documentao algo necessrio em todo desenvolvimento de software e deve adaptar-se ao processo escolhido de desenvolvimento. No caso do desenvolvimento de componentes, os programadores codicam componentes que devero compor uma biblioteca que ser utilizada por diversas pessoas. Sendo assim, a nica maneira de garantir o reuso desses componentes documentar os artefatos produzidos de uma maneira acessvel e compreensvel aos futuros usurios. Ao se tratar de componentes em nvel de objetos em Java, pode-se documentar as classes via comentrios entre as linhas cdigo. Entretanto existe um padro utilizado para documentar as classes em Java, chamado Javadoc. Javadoc um padro de documentao criado pela Sun Microsystems para documentar a Application Programming Interface (API) dos programas em Java a partir de palavras-chave reconhecidas de dentro do prprio cdigo-fonte. O resultado expresso em HyperText Markup Language (HTML).

12

Captulo 3 Processos de desenvolvimento de software


Atualmente, a indstria de desenvolvimento de software tem crescido de maneira exponencial(21). A alta demanda por sistemas que busquem automatizar e simplicar atividades dirias das organizaes tem ajudado nesse crescimento. Porm, para suprir esse mercado no basta apenas obter mo de obra qualicada e ferramentas que auxiliem o desenvolvimento de software, tambm preciso denir possveis metas para alcanar os objetivos desejados. Com isso, surgiu o conceito de processo de desenvolvimento de software, que, segundo Sommerville (1), pode-se descrever como: "Um processo de software um conjunto de atividades que leva produo de um produto de software. Essas atividades podem envolver o desenvolvimento de software propriamente dito, usando uma linguagem de programao como Java ou C. Cada vez mais, no entanto, o novo software desenvolvido como uma ampliao ou manuteno de sistemas j existentes." Um termo que pode-se confundir com a denio anterior sobre modelos de processo de desenvolvimento de software, ou simplesmente modelo de processo. Este pode ser visto como uma representao, ou abstrao dos objetos e atividades envolvidas no processo de software. Sendo assim, modelos so descries mais genricas do que processos. Alm de descreverem atividades de uma forma mais supercial, modelos normalmente abrangem projetos de diferentes tipos, j os processos so mais detalhados e especcos.

3.1

Fases do processo de desenvolvimento de software

Para suportar e englobar uma grande heterogeneidade entre os sistemas, uma srie de fases so denidas como sendo bsicas e gerais para qualquer desenvolvimento de software. Essas fases so (1): Especicao; Projeto e implementao; 13

Validao; Implantao e manuteno. Algumas vezes essas fases podem aparecer mescladas umas s outras ou divididas formando novas fases, dependendo da referncia adotada.

3.1.1

Especicao

Nesta fase, deve-se obter os requisitos, consideradas as funcionalidades do software e as restries quanto a seu uso. Essas premissas devem ser documentadas de modo que esses requisitos representem as necessidades identicadas do usurio que podem ser supridas pelas atuais tecnologias de hardware e software. Essa fase do processo tipicamente inclui as seguintes atividades(2): Identicao; Anlise e negociao; Especicao e documentao; Validao. Na atividade de identicao deve-se compreender o contexto do trabalho, identicar atores envolvidos, capturar os requisitos com os clientes e identicar os possveis problemas. Na anlise e negociao ocorre a diviso dos requisitos em mdulos, resoluo dos conitos entre requisitos e denio de uma prioridade para cada um deles. Na especicao ocorre o menor contato direto com o cliente e o analista dever documentar os requisitos para o sistema. A ltima atividade desta fase a validao, com o cliente do sistema, dos artefatos produzidos.

3.1.2

Projeto e implementao

Esta fase consiste de duas etapas: o projeto e a implementao. Enquanto o primeiro descrito em diferentes processos, o segundo tido como individual, descrito em poucos processos e permitindo que cada desenvolvedor estabelea as melhores prticas para si. Para a etapa de projeto do software, Sommerville (1) dene algumas atividades bsicas. As principais so: Projeto de arquitetura. Onde os subsistemas, que constituem o sistema e as suas relaes, so identicados e documentados; Especicao abstrata. Com os subsistemas identicados, para cada um deles produzido uma especicao abstrata de suas funes e das restries dentro das quais ele deve operar; Projeto de interface. Deve-se detalhar a interface de cada subsistema com outros subsistemas, assim como esboar seu projeto e document-la; 14

Projeto de componentes. Nessa etapa deve-se alocar as diferentes funes aos componentes e assim projetar suas interfaces; Projeto de estrutura de dados. Deve-se, em um nvel prximo da codicao, avaliar quais estruturas de dados deveriam ser utilizadas na implementao dos sistemas, e ento projet-las e especic-las; Projeto de algoritmos. O mais baixo nvel do projeto, consiste de elaborar e especicar, detalhadamente, os algoritmos a serem utilizados.

3.1.3

Validao e testes

A fase de validao e testes busca encontrar eventuais erros que os desenvolvedores tenham codicado na fase de implementao. Nela os sistemas devem ser testados desde suas pequenas partes, utilizando os testes de componente ou unidade, passando pelo teste do sistema integrado e at um teste de aceitao submetido ao usurio nal da aplicao. Outras etapas de teste so denidas por Pressman em seu livro (12) como: teste de operao e testes alfa e beta. Geralmente, as organizaes contam com equipes de teste que so responsveis pela construo de casos de testes. Estes casos sero utilizados para vericar as funcionalidades do sistema podendo assim fazer as validaes de qualidade exigidas na documentao do projeto e vericar se o sistema desenvolvido est em conformidade com os requisitos que foram identicados(20).

3.1.4

Implantao e manuteno

A fase de implantao e manuteno do sistema depende do tipo de sistema que est sendo desenvolvido e como o cliente espera que esse produto seja entregue. Algumas etapas para manuteno do sistema so: Manuteno corretiva; Manuteno evolutiva. A manuteno corretiva tem como objetivo corrigir defeitos e decincias encontrados durante a utilizao do software pelo usurio. Essas alteraes so executadas para corrigir erros no capturados em outras fases do processo. Na manuteno evolutiva so feitas melhorias aplicabilidade e usabilidade do software. Esta a etapa de modicar o sistema existente, para suprir novas funcionalidades que atendam a novos requisitos propostos pelo cliente.

3.2

Processos de desenvolvimento

Antes de abordar como o processo de desenvolvimento baseado em componentes, ser apresentada uma viso de outros processos de desenvolvimento de software e seus pontos fortes e fracos. Dependendo da organizao, pode existir a necessidade de mesclar vrios processos de desenvolvimento visando atender critrios de rapidez, correteza, qualidade entre outros. 15

3.2.1

Processos em cascata

O primeiro processo de desenvolvimento originou-se dos processos mais gerais de engenharia de sistemas (22). Este o processo em cascata, onde os desenvolvedores, de maneira geral, seguem as quatro fases, em ordem, descritas anteriormente. Depois que cada atividade terminada, o processo segue para a prxima. As principais fases desse processo so: anlise e denio de requisitos, projeto de sistema, implementao e teste de unidade, integrao e teste de sistema e manuteno. A respeito deste processo pode-se apontar vantagens como a documentao produzida em cada fase, pois tudo deve car especicado da melhor forma possvel para que as pessoas envolvidas na fase seguinte possam dar continuidade ao trabalho. Os marcos so bem denidos a cada fase, por isso se torna mais fcil vericar os artefatos que foram produzidos at o momento e controlar com maior preciso os cronogramas do projeto. Entretanto, este tipo de processo no possibilita a realizao de tarefas em paralelo, como por exemplo: a implementao de uma parte do sistema enquanto outra est sendo especicada. s vezes, esse processo diculta o andamento do projeto, pois pode-se detectar um problema na implementao de determinado requisito especicado que poderia ter sido corrigido em uma etapa anterior, mas foi preciso terminar por completo as fases anteriores para poder detect-lo. Deste modo, este tipo de processo utilizado em projetos que tem o escopo bem denido.

3.2.2

Processos iterativos

O desenvolvimento atravs de iteraes baseado na construo de pequenas pores do software. Deve-se fazer uma implementao inicial e renar esse resultado por meio de sucessivas iteraes at que o sistema seja nalizado. A gura 3.1 esboa como deve ser feito um processo de modo iterativo.

Figura 3.1: Processo de desenvolvimento iterativo. Segundo Sommerville(1) duas prticas muito utilizadas em processos iterativos so: Desenvolvimento exploratrio; 16

Prototipao descartvel. O desenvolvimento exploratrio tem como objetivo principal compreender os requisitos do sistema e desenvolver, primeiro, as partes mais simples. Com elas solidicadas, possvel avanar para partes mais complexas e com regras de negcio do sistema. O sistema evolui por meio de novas caractersticas apontadas pelo cliente. A prototipao descartvel visa documentar e validar os requisitos do cliente e permitir o desenvolvimento com a especicao do sistema e suas necessidades. Os prottipos so utilizados para ajudar o cliente a explicitar suas necessidades mais complexas e validar as denies dadas pelo analista.

3.2.3

Processos geis

Processos geis de desenvolvimento de software so construdos com os fundamentos do desenvolvimento iterativo (23). Os processos geis usam iteraes contnuas com o cliente, conseguindo buscar informaes que servem como realimentao para planejar os prximos passos do desenvolvimento do projeto. A realimentao realizada atravs de testes regulares e pelas verses liberadas do software. Os processos geis de desenvolvimento de software seguem alguns princpios, como satisfazer o cliente atravs de entregas frequentes (semanais, quinzenais ou mensais) e contnuas. Alteraes, mesmo que tardias, so aceitas com naturalidade e iteraes dirias entre analista de negcio e desenvolvedores, comunicao direta, equipe auto-organizada, simplicidade e capacidade de adaptao so outras caractersticas desses processos. Esses princpios visam minimizar o esforo no desenvolvimento de softwares, mas o processo gil contm desvantagens, entre elas; a diculdade de ter uma viso a longo prazo, conseguir estimar os custos do software, estimar quantas iteraes sero necessrias para a concluso do projeto, saber qual a arquitetura adequada para comear o projeto e se ela continuar til at o m do projeto. Existem vrios processos considerados como geis, entre eles: EXtreme Programming, Scrum, o desenvolvimento guiado por funcionalidades Feature Driven Development (FDD), Crystal Clear, a metodologia de desenvolvimento de sistemas dinmicos Dynamic Systems Development Method (DSDM) entre outros.

3.3

Engenharia de Software Baseada em Componentes (CBSE)

Segundo Heineman e Councill (24), pode-se denir a Engenharia de Software Baseada em Componentes (CBSE) como: "A CBSE atualmente a forma mais rpida de produzir software, com menos esforo e de alta qualidade. Ela est tornando-se um elemento indispensvel no desenvolvimento de software no mundo."

17

3.3.1

Caractersticas da CBSE

Na maioria dos projetos de software existe reuso, algumas vezes de apenas algumas bibliotecas ou APIs, mas, s vezes, at mesmo de camadas ou modelos inteiros. Isso pode ocorrer de maneira informal, quando os desenvolvedores conhecem cdigos similares aos necessrios, existentes em outros sistemas. Sendo assim eles procuram, alteram e incorporam essas funcionalidades ao sistema atual. Segundo Sommerville (1) alguns pontos essenciais da CBSE podem ser ressaltados. Primeiro, a necessidade de ter componentes independentes e descritos por suas interfaces. Como j se discutiu anteriormente, a lgica de um componente deve car restrita a ele, sua implementao deve car encapsulada e a comunicao com outras partes do sistema deve ser feita via as interfaces desse componente. Em seguida pode-se ressaltar que a padronizao dos componentes adotados facilita a integrao dos mesmos e a formulao do sistema. Caso diferentes componentes sigam um padro bem estabelecido de comunicao, ser possvel integrar componentes implementados em diferentes linguagens de programao. Entretanto at mesmo dois componentes desenvolvidos sob uma mesma linguagem podem no ser compatveis caso seus padres no estejam adequados. Neste sentido tem-se tambm que, independente do processo escolhido, caso o desenvolvedor busque reutilizar componentes, seu processo dever incorporar atividades que busquem a reutilizao de componentes. Isso porque, mesmo de maneira informal, sero necessrias adaptaes para o uso do componente, utilizando atividades denidas em processos baseados em reuso. Por exemplo, no se pode deixar de adaptar um componente ao sistema, pois isso provavelmente vai limitar ou, at mesmo, inviabilizar o seu uso. Alguns problemas podem aparecer quanto ao uso de componentes, entre eles tem-se (1): Falta de conana em certos componentes; Certicao dos componentes; Previso de propriedades emergentes (no funcionais para o componente); Compromisso entre requisitos desejados com funcionalidade obtida.

3.3.2

Diferena entre CBSE e outros processos

Um dos pontos a serem considerados no incio do projeto que os requisitos do cliente so descritos de uma forma geral, para que se tenha um grande nmero de componentes possveis inicialmente. Com o passar do desenvolvimento, esse requisitos vo sendo renados e os componentes podem ser melhor qualicados e selecionados para atender as necessidades do usurio. Outra caracterstica que nem sempre so somente os clientes que denem os requisitos do sistema; algumas vezes suas vontades devem se adaptar s limitaes impostas pela biblioteca utilizada. Normalmente os clientes aceitam essas mudanas, pois elas implicam em imposies tecnolgicas e causam um melhor custo benefcio ao cliente. 18

Mesmo depois de denida a arquitetura do sistema, existe uma busca por novos componentes para o sistema. Isso ocorre porque durante o desenvolvimento muitos componentes selecionados mostram-se inadequados para o uso ao qual foram projetados, e assim no funcionam como esperado. Durante o desenvolvimento, feita a composio dos componentes. Existir uma forte integrao entre eles e a infra-estrutura do sistema. Como dito anteriormente, essa unio pode ser feita atravs de um framework ou por codicao. Caso o desenvolvedor decida codicar como os componentes se comunicaro, esse cdigo poder ser especco para o sistema, no apresentando a caracterstica de reuso. As principais diculdades encontradas em processos baseados em componentes em relao a outros processos de desenvolvimento so as seguintes(25): Encontra-se diculdade em tcnicas de armazenamento e busca de componentes, pois, na maioria dos projetos, existe o problema de localizar o componente adequado para o uso. Pode ser feito, neste aspecto, uma cadeia de dependncias de componentes e um sistema hierrquico para os mesmos; Gerenciar o controle de alteraes dos componentes e prover formas para que estes no sejam alterados por vrios desenvolvedores simultaneamente; Existe diculdade na manuteno dos componentes, deve-se ter o controle das verses de cada componente, como o controle de permisses para alteraes desses componentes; Como os componentes trabalham de forma independente, s vezes este fato gera diculdades na integrao com os outros componentes para a montagem do sistema, inviabilizando o seu uso e tendo que especicar novos componentes; Durante a especicao do sistema, diculdades em denir quais partes podem ser encapsuladas em um componente podem surgir, levando a criao de componentes que nunca sero utilizados. Existem tambm alguns fatores organizacionais, que aumentam os riscos de processos de desenvolvimento baseado em componentes. Nas organizaes, com um processo denido para o desenvolvimento de software, geralmente esto inclusas as atividades para o desenvolvimento de componentes. Tambm existe a diculdade dos funcionrios em aceitar e entender o desenvolvimento de componentes, fazendo com que muitos no utilizem prticas de reuso. As principais vantagens de processos baseados em componentes, em relao a outros processos, so (26): Utilizam as tcnicas, princpios e melhores prticas do passado para fornecer uma teoria e prticas que auxiliam no desenvolvimento de software de larga escala e do suporte a sua industrializao; Servem para controlar a complexidade e os riscos do desenvolvimento de software, utilizando a sua abordagem centrada na arquitetura e reuso;

19

O uso de unidades quase autnomas para estruturar os sistemas de informao traz novos desaos e oportunidades no que tange o desenvolvimento, os testes e a distribuio, feitos de forma concorrente; Reduz o tempo de entrega do software, ou seja, diminui o tempo necessrio para se desenvolver um novo software, de acordo com as novas necessidades do mercado, e disponibiliz-lo.

3.4

Exemplos de Processos Baseados em Componentes

Nessa seo sero apresentados exemplos de processos baseado em componentes, dentre os quais esto: o processo de desenvolvimento em V (14), o processo Catalysis (27) e o processo detalhado em (15) que voltado para o desenvolvimento de sistemas de negcio. Existem outros processos baseados em componentes, mas apenas esses trs sero apresentados neste trabalho, sendo que o ltimo(15) ser aplicado ao estudo de caso.

3.4.1

O processo de desenvolvimento em V

No processo de desenvolvimento em V baseado em componentes foi apresentado por Crnkovic, Larsson e Chaudron(14). Neste trabalho, os autores falam sobre a importncia entre separar conceitos de desenvolver com componentes e desenvolver componentes. A nfase do desenvolvimento em V na construo de sistemas atravs da composio dos componentes. A gura 3.2 ilustra como este processo adaptou o modelo em cascata, e suas vrias fases sequenciais, em uma abordagem baseada em componentes. Neste diagrama, o processo comea de uma forma habitual, com a engenharia de requisitos e a especicao dos mesmos, seguido pela especicao do sistema como um todo. Em uma abordagem no baseada em componentes o processo deveria continuar com a fase concepo, implementao e teste. Em vez de realizar atividades que muitas vezes levam muito tempo e requerem elevado esforo, devese adequar componentes e integr-los ao sistema. Nessa abordagem, os autores descrevem as seguintes fases: Anlise de requisitos e especicao; Projeto do sistema; Implementao e testes unitrios; Integrao do sistema; Vericao e validao do sistema; Suporte e manuteno.

20

Figura 3.2: Processo de desenvolvimento em V baseado em componentes. Na fase de anlise de requisitos e especicao, uma atividade importante analisar a possibilidade de realizar as solues que atendam a esses requisitos. Uma abordagem baseada em componentes implica em analisar se estas exigncias podem ser satisfeitas pelos componentes disponveis. Como improvvel que os componentes possam sempre ser encontrados, h uma possibilidade de que elementos tenham que ser implementados. Nesse tipo de desenvolvimento, um caso ideal seria a construo de uma aplicao pela integrao direta dos componentes. O termo cdigo cola signica que o cdigo implementa a comunicao dos componentes. Na prtica, o cdigo cola deve no somente adaptar os componentes, mas tambm implementar as novas funes que no sejam supridas por eles. A fase de integrao inclui a infra-estrutura adotada para comunicao e os componentes que sero utilizados na aplicao. A implantao de uma componente um mecanismo para a integrao de um grupo de componentes, que inclui a transferncia e registro do componente. Na fase de vericao e validao do sistema, aplicam-se alguns testes e outras tcnicas de validao para garantir a aceitao do cliente para o software. Como analisado anteriormente, o problema da abordagem baseada em componentes a localizao dos erros, lembrando que isso pode ocorrer dentro de um componente ou no cdigo cola. Ocasionalmente, um componente pode exibir um erro, mas a falha reside em outro componente. Para esses casos, as interfaces tm um papel essencial, pois elas determinam o comportamento que o componente apresenta para o sistema. A fase de manuteno inclui algumas medidas que so semelhantes ao processo de integrao como quando um novo, ou modicado, componente acoplado ao sistema. Na maioria dos casos, j existe um componente que, agora, deve ser modicado ou uma nova verso de um componente foi lanada e ela dever se in-

21

tegrar ao sistema. Novos problemas podem ser causados pela incompatibilidade entre componentes, ou entre as suas dependncias. Apesar de ser descrito como uma adaptao do processo de desenvolvimento em cascata, ele tem a capacidade de reduzir os custos na fase de implementao pelo reuso de componentes. Entretanto, outros problemas surgem como a seleo e a validao dos componentes a serem integrados ao sistema e a depurao de eventuais erros reportados pelos usurios.

3.4.2

O processo de desenvolvimento Catalysis

O processo Catalysis utilizado para fornecer um suporte ao desenvolvimento baseado em componentes. Este nome vem da palavra catlise que seria o processo de acelerao na qumica, logo o processo Catalysis vem buscar principalmente a agilidade no desenvolvimento de software. Neste sentido, nele encontram-se diversas vises que denem um padro de colaborao que, usando um conjunto de ferramentas como as de modelagem, compartilham artefatos para descrever sistemas. O processo basicamente utiliza a Unied Modeling Languague (UML)(28), com algumas alteraes, para especicar os diferentes artefatos que so elaborados na construo dos componentes. As principais caractersticas do processo Catalysis comeam, primeiramente, na denio dos participantes, no uso de dicionrio que permita uma especicao clara das responsabilidades, no impondo a implementao de decises. Dene-se as seguintes atividades (27): Desenvolver o dicionrio partilhado por clientes e equipe de desenvolvedores; Descobrir quaisquer equvocos graves, decincias e interface incompletas; Ter uma compreenso clara das hipteses, das garantias e das excees; Escolher as ferramentas de testes. As iteraes podem ser descritas em vrios nveis de detalhe. O Catalysis produz uma detalhada descrio do que ser construdo de maneira sistemtica. Nas atividades de renamento esto (27): Manter a rastreabilidade dos requisitos at o cdigo concreto; Utilizar uma abordagem gradual para modelar o desenvolvimento; Acompanhar problemas complexos; Adiar informaes de segurana, quando necessrio; Tratar o desenvolvimento com nveis variados de detalhe e completude. O Catalysis divido nas seguintes etapas para o desenvolvimento de software baseado em componentes(27): Modelagem de domnio; 22

Especicao do sistema; Projeto da arquitetura; Projeto interno dos componentes; Implementao, integrao e teste. Na etapa de modelagem de domnio so denidas mtricas para avaliao do sistema como, por exemplo, o tempo, linhas de cdigo, etc; alm de fatores de rastreabilidade. Elaborando, paralelamente, o dicionrio de termos do sistema. Na etapa de especicao do sistema deve-se adicionar funcionalidades ou interfaces ao modelo. Alm disso, deve-se escrever as ps-condies para operao do sistema, em termos de atributos sobre o domnio da aplicao, e explicitar alguns cenrios concretos do uso do sistema. Deve-se priorizar os casos de uso, como um plano inicial de incrementos, e sucessivamente ir detalhando estes incrementos de forma iterativa ou incremental. Tambm necessrio denir os servios que sero providos pelo sistema e confeccionar os prottipos de interface com o usurio para modelar as interfaces e seus atributos. No projeto da arquitetura dene-se o projeto dos mdulos do sistema, as classes que devero ser implementadas. Deve-se utilizar uma forma de criar os componentes. Neste sentido, deve-se atribuir os nomes, construir o modelo e identicar as principais responsabilidades para cada um. Ento para cada servio provido pelo sistema, saber qual o conjunto de componentes necessrios para prov-lo. Ainda para cada uma dessas operaes, devem ser identicadas as iteraes sobre elas, estabelecendo parmetros e retornos, levando em conta as pr e ps-condies para aquele componente. No projeto interno dos componentes devero ser escolhidos os padres de comunicao entre os componentes, alm de document-los com esteretipos sobre a natureza do protocolo. Alm de descrever nos pacotes a utilidade de cada um, para saber o domnio especco de cada componente dever ser feita a escolha do banco de dados e a denio das classes e das interfaces dos componentes. Os testes podero ser: teste de unidade, de integrao, de carga e funcionais para o sistema. Na implementao, integrao e testes dos componentes, o Catalysis descreve que deve-se separar os contextos a partir dos modelos de domnio, particionar o sistema em modelos independentes, identicar o funcionamento interno dos componentes, identicar as interfaces dos componentes, denir um conjunto de facilidades para a conexo entre os componentes e realizar a manuteno do repositrio dos componentes. No processo Catalysis possvel desenvolver a granularidade dos componentes dividindo sistemas complexos em partes menores, conseguindo todos os benefcios que os componentes podem prover ao projeto. Desta maneira, pode-se ver a importncia do processo e suas caractersticas principais na estruturao do sistema.

3.4.3

O processo descrito por Cheesman e Daniels

O processo descrito nesta subseo fruto do estudo do livro UML Components (15) voltado para o desenvolvimento de sistemas de negcio. Os autores deixam 23

claro que o processo descrito apenas o processo de desenvolvimento e no apresentado nenhum processo para a gerncia do projeto. Com isso, possvel desenvolver o software, segundo este processo, e utilizar qualquer outro processo de gerenciamento para realizar o controle do projeto. Isso permite ao gestor a adoo do processo de gerenciamento mais conveniente. Este processo denido por uma srie de fases que produzem vrios artefatos para as fases seguintes, visando contribuir para a construo do sistema nal. A gura 3.3 mostra como e quais fases existem durante o processo.

Figura 3.3: Fases do processo. No diagrama, as fases do processo so representadas pelas caixas com nomes e os artefatos so os crculos com nmeros. Ento, os seguintes artefatos so especicados(15): 1. Requisitos do negcio do sistema a ser desenvolvido; 2. Modelo Conceitual do Negcio; 3. Modelo de casos de uso; 4. Especicao e arquitetura dos componentes; 5. Limitaes tcnicas; 6. Conguraes j existentes no sistema; 7. Componentes; 24

8. Aplicaes; 9. Aplicaes testadas. As fases de requisitos e de especicao so as responsveis pela produo da maior parte dos artefatos. Na fase de requisitos, pode-se destacar a criao de dois artefatos, o Modelo Conceitual do Negcio e o Modelo de Casos de Uso. A prxima fase com grande volume de artefatos a de especicao. Nela temse um artefato que no exportado para outras etapas do processo, mas que utilizado internamente. Este o Modelo do Tipo de Negcio. Nele deve-se propor uma viso da interao do sistema com o usurio, baseando-se no Modelo Conceitual do Negcio. O artefato que pode ser gerado a partir do anterior a Especicao das Interfaces; com ele possvel xar uma srie de contratos a serem denidos para comunicao entre os clientes e seus componentes de negcio. Denido como os componentes devem se comunicar pode-se gerar a Especicao de Componentes juntando as interfaces e as limitaes de cada componente. Por m falta denir como os componentes se integraro. Isso deve ser feito com o artefato de Arquitetura de Componentes. Nele preciso denir uma relao entre as interfaces de componentes e suas implementaes, assim como as dependncias entre os componentes. Este processo descreve a fase de especicao com bastante detalhes e realiza esta fase por meio de sucessivas iteraes para a evoluo dos artefatos. Ento consegue-se uma documentao detalhada para o desenvolvimento dos componentes, que no foi vista nos outros exemplos de processos da CSBE. Este fato foi o motivo da escolha deste processo para aplicao no estudo de caso, pois com os artefatos de especicao produzidos de forma evolutiva, conforme a quantidade de informaes aumenta sobre o sistema, a possibilidade de implementar componentes que sejam coerentes com os requisitos especicados maior.

25

Captulo 4 O detalhamento do processo descrito por Cheesman e Daniels


Neste captulo ser descrito o processo detalhado por Cheesman e Daniels (15), sendo descritas as atividades do processo e como sero produzidos os artefatos denidos para cada atividade. Este um processo para desenvolvimento de componentes de negcio. As atividades a serem realizadas esto distribudas em fases, sendo que a fase de especicao foi dividida em etapas para uma melhor execuo das vrias atividades denidas para ela.

4.1

Denio dos requisitos

Na fase de requisitos, preciso que os responsveis pelas suas atividades tenham um claro entendimento sobre o funcionamento do processo. Caso isso no seja a realidade, desenvolver um modelo de abstrao do processo a ser automatizado pode ajudar. Nesse caso, o diagrama a ser utilizado seria o Diagrama de Atividades descrito pela UML(28). Essa modelagem pode no denir muito sobre como e o que acontece durante o processo, mas ela ajuda a entender o funcionamento das atividades envolvidas. Com essa viso denida, possvel garantir a construo do Modelo Conceitual do Negcio. Mas antes de desenvolver esse artefato, precisa-se conhecer o vocabulrio do negcio. Siglas, jarges, nomes de usurios, entidades, devem ser descritos em um documento a parte para facilitar a consulta de quem tenha necessidade de conhec-los. Com esta compreenso, pode-se denir o que vem a ser o Modelo Conceitual do Negcio. Ele deve representar como as entidades bsicas do sistema esto relacionadas entre si, no se resumindo a descrever a entidade como ela deve ser no sistema (mtodos e atributos), mas sim relacionamentos entre elas e tambm a cardinalidade desses relacionamentos. Um diagrama propcio para isso o Diagrama de Classes da UML(28). Antes de descrever os casos de uso necessrio validar com os usurios como o processo pode ser mapeado para o sistema. Essa validao do sistema poder ser feita atravs da apresentao de cenrios aos stakeholders, todos os interessados ou envolvidos no processo. 26

Para escrever os casos de uso, o primeiro passo dividir quais etapas existem no sistema e como elas esto relacionadas com os usurios. No necessariamente um usurio do sistema deve ser uma pessoa, mas poder ser, em determinado, momento outro sistema. Para mostrar o relacionamento entre os casos de uso identicados para o sistema e os atores envolvidos pode-se utilizar o diagrama de Casos de Uso da UML(28). Para denir quantos e quais casos de uso existem fundamental entender as fases existentes no processo e quais atividades elas envolvem. Isso varia de sistema para sistema, mas pode-se generalizar a ideia de que um caso de uso deve descrever a iterao de um nico evento do negcio. Alm de diagramas da UML, essa fase deve produzir artefatos textuais para documentar a viso, o escopo, os requisitos e o detalhamento dos casos de uso. Para esses documentos sero adotados os mesmo formatos do RUP (29) e neles devem ser descritos: atores envolvidos, objetivo, ou viso, do sistema e de cada caso de uso individualmente, tratamento de erros, regras de negcio e requisitos funcionais e no funcionais.

4.2

Especicao do sistema

Essa fase possui atividades sequenciais e incrementais, complementando as anteriores. Isto ocorre pois muitos artefatos so construdos e refatorados de maneira incremental para melhorar a descrio e a funo de cada um. Para auxiliar nessa refatorao dos artefatos, essa fase foi dividida em trs etapas: identicao, levantamento das interaes e especicao dos componentes, como mostrado na gura 4.1. Na gura 4.1, as pastas so as etapas da fase, os retngulos so as atividades de cada etapa e os artefatos produzidos esto representados por crculos com nmeros. A legenda para os artefatos : 1. Modelo Conceitual do Negcio; 2. Modelo de casos de uso; 3. Interfaces existentes; 4. Conguraes j existentes no sistema; 5. Padres de arquitetura; 6. Interfaces de negcio; 7. Especicao e arquitetura de componentes (primeira verso); 8. Interfaces do sistema; 9. Especicao e arquitetura de componentes (segunda verso); 10. Interfaces (primeira verso); 11. Interfaces (segunda verso); 27

Figura 4.1: Os trs estgios do uxo de especicao. 12. Especicao e arquitetura de componentes (terceira verso). Alm dos artefatos, ser detalhado o objetivo de cada uma dessas trs etapas. Ao identicar os componentes, deve-se produzir uma viso inicial de como ser a arquitetura dos componentes a partir dos requisitos recebidos. Na etapa de inte28

rao entre os componentes necessita-se descobrir as operaes necessrias e as responsabilidades alocadas por componente. Finalmente, na etapa de especicao dos componentes, precisa-se criar as especicaes precisas e detalhadas sobre as operaes, interfaces e os componentes envolvidos no sistema.

4.2.1

Identicao dos componentes

A primeira etapa da fase de especicao recebe os artefatos de Modelo Conceitual do Negcio e os casos de uso do sistema para produzir um esboo das interfaces dos componentes e suas especicaes. Alm de moldar uma viso bsica da arquitetura dos componentes utilizados, essa etapa tambm produz o artefato Modelo do Tipo do Negcio que ser futuramente utilizado para fornecer as informaes necessrias para descrever as interfaces dos componentes. Nessa etapa importante denir e distinguir as interfaces que provero os servios de negcio do sistema e as que prestaro servios secundrios ao negcio, importantes para o sistema, mas sem regras envolvidas. Aliado identicao destes componentes, necessrio considerar as interfaces, subsistemas, base de dados e componentes que existem no sistema e que necessitam de interface com a parte a ser desenvolvida. Para auxiliar na identicao das interfaces necessrias, o processo busca dividilas em dois grupos: as interfaces do sistema e as interfaces do negcio. As interfaces do sistema so aquelas que surgem de uma anlise sobre os casos de uso e focam no negcio especco do sistema, com suas regras e validaes. As interfaces do negcio so as responsveis por auxiliar as anteriores, mas que trabalham com operaes mais simples do ponto de vista do processo, com poucas validaes ou regras de negcio a serem aplicadas. Normalmente ser especicada uma interface do sistema por caso de uso, mas isso no obrigatrio. Essas interfaces devem prover as informaes necessrias para que o usurio possa informar todos os dados que o caso de uso requer para completar seu processamento. Por exemplo, possveis operaes presentes nessas interfaces podem ser consultas de informaes sobre domnios do sistema, pedido de incluso, alterao ou excluso de dados do sistema, auxiliar na navegao entre pontos de extenso dos casos de uso, invocar validaes e outras possveis tarefas a serem processadas. Denidas as interfaces de sistema deve-se identicar as interfaces de negcio. Para isso, o processo descreve que algumas atividades devem ser realizadas (15): Criar o modelo de tipo de negcio a partir do Modelo Conceitual do Negcio; Especicar regras de negcio para adicionar as limitaes do modelo de tipo de negcio; Identicar o ncleo de atividades do negcio; Criar interfaces para essas atividades e agreg-las ao modelo de tipo de negcio; Revisar o modelo gerado para documentar as responsabilidades das interfaces. 29

A primeira atividade relaciona os dois modelos, o provido pela fase de requisitos e o que ser construdo nesta etapa. Aquele deve servir como base para a construo deste, sendo que o novo artefato no deve mais focar no que seria o conceito do processo, mas sim os tipos que devero ser utilizados quando a implementao dos componentes for feita. Na segunda atividade deve-se melhorar esse diagrama. Melhorias quanto a remoo de tipos que no se fazem necessrios, associaes que podem ser simplicadas ou fundidas, dependncias que no fazem parte do foco do sistema e outras representaes supruas ao domnio devem ser excludas para simplicar a representao. Em terceiro lugar deve-se denir as regras do negcio. Isso inclui atribuir a cada um dos domnios representados seus atributos e relacionamentos (incluindo cardinalidades) com outros domnios do sistema. Determinados os tipos do sistema e seus atributos necessrios, devem ser destacados quais sero os mais importantes dentre eles. Esses tipos normalmente so facilmente identicados, pois sua caracterstica estar ligado a outros tipos, porm no dependem de nenhum deles para existir, mas sim o contrrio. Estes so conhecidos como tipo ncleo, pois mesmo isolados eles esto denidos para o contexto do sistema. Agora resta incluir no modelo esteritipos core aos tipos considerados como ncleo do sistema. Como ltima atividade, deve-se criar as interfaces de negcio para os tipos do sistema apontados no Modelo do Tipo de Negcio como sendo os mais importantes. Ento, cria-se uma interface para cada tipo e ela deve ter responsabilidades de gerenciamento das informaes para o respectivo ncleo. Os modelos devem ser atualizados para mostrarem como as interfaces esto relacionadas com os tipos e como ser feita a composio entre eles. Ao executar esses procedimentos, faltar apenas denir qual das entidades obrigatria em uma relao e qual seria a dependente. Na UML (28) pode-se representar essa restrio com o uso de dependncia entre os tipos. Mas importante lembrar que quanto mais dependncias chegarem ao tipo implica o quanto ele importante para o sistema. Se as dependncias saem desse tipo mostra o quanto este estar condicionado a outros. Especicadas as interfaces que devero ser utilizadas, pode-se partir para a especicao da arquitetura dos componentes. Vrios aspectos do projeto devem ser levados em conta para essa etapa, mas importante focar nas caractersticas bsicas dos componentes para que eles no sejam sobrecarregados de funes e acabem perdendo suas caractersticas de componentes, podendo tornar-se mdulos do sistema. Denir quais interfaces sero implementadas por quais componentes uma tarefa importante para a prxima atividade. possvel denir mais de uma interface para ser implementada por componente, mas o que ocorre com frequncia que essa associao seja feita de um para um. Como foram denidos dois tipos de interfaces, deve-se trabalhar com suas especicaes separadamente antes de construir a arquitetura do sistema, seguindo os passos (15): Especicar os componentes de sistema; Especicar os componentes de negcio; 30

Constuir a arquitetura dos componentes. No primeiro passo as especicaes podem ser feitas tomando por base as funcionalidades descritas nos casos de uso. Normalmente, essa uma etapa na qual pode-se facilmente implementar vrias interfaces em um mesmo componente. Na segunda parte, deve-se criar as especicaes para as interfaces identicadas na etapa de modelagem dos tipos do negcio. Ao contrrio da primeira fase, essa normalmente requer um relacionamento de um para um entre interfaces implementadas e os componentes que as suportam. Ao nal dessas duas fases, pode-se ter uma viso em alto nvel de como ser a arquitetura dos componentes.

4.2.2

Levantamento das interaes entre componentes

Nesta etapa, ser detalhada a segunda parte da fase de especicao, onde ser exigida a especicao das funcionalidades dos componentes. Esta etapa preocupase em denir as interfaces que sero implementadas por componentes no sistema. Pode ser que um componente implemente uma ou mais interfaces, mas essa relao ser estabelecida ao denir a arquitetura dos componentes. Voltando gura 4.1 percebe-se que as entradas para esta etapa so as interfaces de negcio, as interfaces de sistema e a especicao e arquitetura dos componentes. Nesta etapa so denidas trs atividades (15): Descobrir as operaes do negcio; Renar operaes e interfaces; Renar as especicaes e denies dos componentes. Como dito anteriormente, esta etapa deve melhorar os artefatos recebidos de modo a descrever melhor quais funcionalidades cada componente deve prover ao sistema. Com isso, deve-se renar as interfaces existentes para detalhar como estas se relacionam e interagem com os demais componentes. Descobrir novas interfaces e novas operaes providas tambm pode ser feito nesse momento. importante detectar a possibilidade de usar padres de projeto, conseguir identicar um padro de operaes, criar uma operao genrica, substituir as mesmas e compreender as dependncias de cada interface. No comeo da atividade de descoberta das operaes do negcio, no possvel saber quais sero as assinaturas das operaes, nem como sero implementadas usando os componentes de negcio, ou seja, por enquanto busca-se uma especicao para as interfaces dos componentes, abstraindo como esta ser implementada. Uma maneira adequada de especicar as interfaces de negcio necessrias no sistema utilizar a elaborao dos diagramas de colaborao, da UML (28). Cada diagrama mostrar uma ou mais interaes do uxo dos casos de uso, podendo assim conseguir examinar quais operaes sero necessrias para que o usurio execute determinada tarefa. Por m estar denido qual interface prover este servio. Uma interface deve ser dividida em novas interfaces caso ela que sobrecarregada de funcionalidades. 31

Para reestruturar a arquitetura dos componentes, necessrio deixar claro quando um componente depende do servio provido por outro. O processo dene opes para estabelecer as responsabilidades dos componentes de forma a assegurar que as associaes entre eles sejam vlidas. Algumas dessas opes so (15): A responsabilidade pode ser atribuda ao componente que armazenar a referncia do objeto; A responsabilidade pode ser atribuda ao componente no objeto que propriamente tem a sua referncia, ou seja, haveria um mecanismo para identicar quais os outros componentes que esto mantendo referncias aquele objeto e noticando-os adequadamente; A responsabilidade pode ser atribuda a um terceiro componente, geralmente com uma chamada ascendente em sua hierarquia; Permitir e tolerar referncias que se tornem invlidas; No permitir a supresso de informaes. Estas opes tm como meta geral desenvolver um sistema baseado em componentes, onde os componentes possuam o menor nvel de acoplamento possvel, permitindo seu reuso. Antes de iniciar a atividade de renamento das interfaces, deve-se completar os possveis casos das interaes entre os componentes. Neste momento objetiva-se descobrir as funcionalidades e suas responsabilidades, mas no em minimizar chamadas, remover dependncias cclicas, normalizar as operaes e as interfaces, entre outros. No necessrio antecipar a construo de novas funcionalidades e nem tornar a interface o mais genrica possvel. A exibilidade dos sistemas baseados em componentes vem do fato que os componentes podem oferecer mltiplas interfaces. Assim, quando novas funcionalidades forem acrescentadas podem ser criadas novas interfaces para poder gerenciar melhor o acoplamento das mesmas.

4.2.3

Especicao dos componentes

Nesta seo ser detalhada a terceira etapa da fase de especicao, a especicao dos componentes. Ela poder restringir a forma como as interfaces sero implementadas. As interfaces denem servios, atravs de seus mtodos, que sero providos aos clientes. O principal objetivo de especicar as interfaces minimizar a dependncia entre os componentes, deixando clara suas dependncias, e documentar as funcionalidades que cada componente deve fornecer. Ao documentar as operaes deve-se detalhar as informaes necessrias sobre o funcionamento e o comportamento esperado pela sua execuo. Tendo as seguintes partes (15): Os parmetros de entrada: especicando as informaes passadas ao componente; 32

Os parmetros de sada: especicando as informaes retornadas pelo componente; Qualquer restrio de uso, como lanamento de excees. As operaes devem especicar as suas entradas, sadas, e os estados dos componentes relacionados e qual o efeito que a chamada da operao pode causar. Mesmo quando no se conhece como esta operao se relaciona com as outras interfaces ou como esta ser implementada e quais outros relacionamentos sero necessrios, pois para quem vai consumir os servios providos pela interface no necessrio conhecer o cdigo fonte. Para se documentar as informaes necessrias de cada interface dos componentes, deve-se construir um modelo visando mostrar os possveis estados do componente para cada operao da interface. As interfaces precisam conter as informaes relevantes para o funcionamento do que foi especicado. Neste sentido vivel construir o modelo de forma incremental, denindo a assinatura das operaes, acrescentando os tipos de entrada e sada, os atributos e as restries aplicveis. Cada operao dene um conjunto de pr e ps-condies. Estas condies servem para informar o cliente como essa operao dever se comportar ao ser chamada. A pr-condio representa os pressupostos de que a operao convel e estar bem denida. A ps-condio representa uma garantia contratual de que a operao retornar o resultado esperado. Sendo assim, garantir que a operao seja utilizada em um contexto correto de responsabilidade do cliente. Mas as garantias da funcionalidade correta sob as condies descritas so de responsabilidade do servidor. Para componentes complexos, uma tarefa difcil denir as informaes de cada interface. Uma maneira prtica de criar a interface para o Modelo de Informaes de Negcio fazer uma cpia do Modelo do Tipo de Negcio para o pacote da interface e em seguida, remover tipos, associaes, e os atributos que no so necessrios. necessrio permitir especicaes parciais, para que detalhes sejam preenchidos posteriormente. Mas isto no signica todas as informaes so passveis de detalhamento futuro. Para isso devem-se seguir algumas orientaes (15): Se a pr-condio for verdadeira, tudo que for mencionado na ps condio deve se manter inalterado; Se a pr-condio for falsa, o efeito indenido, podendo-se, futuramente, alterar essa denio. Ser necessrio documentar cada componente dizendo quais interfaces ele ir realizar. Melhorar as denies de cada componente necessrio para que a documentao atinja um nvel de detalhamento suciente para ser entregue ao desenvolvedor. Deve-se denir quais outras interfaces sero necessrias para realizar o componente. Para criar o modelo de informaes de interface preciso que cada interface tenha sua prpria denio. Nesse propsito, a refatorao das interfaces visa 33

introduzir interfaces que generalizem o comportamento de outras interfaces, como uma interface me que as outras devem herdar. Isso faz com que as operaes em comum sejam mantidas pelas lhas e preservem centralizadas as denies desses mtodos na interface mais genrica.

4.3

Seleo de Componentes

Nas fases anteriores, tentou-se criar especicaes de componentes que fossem to independentes quanto possvel a uma determinada tecnologia de mercado. Algumas especicaes tcnicas vo fazer com que certas tecnologias no possam ser usadas. Por isso, ser necessrio mapear como as diferentes tecnologias afetam a transposio da especicao para a implementao. Deve-se escolher uma determinada tecnologia para desenvolver o sistema de modo que as especicaes atendam s restries especicadas para os componentes. Dentre as tecnologias de desenvolvimento de componentes tem-se os seguintes exemplos: Component Object Model (COM+)(30) e Entreprise Java Beans (EJB)(31). Os principais problemas que podem surgir com o mapeamento para uma determinada meta tecnolgica so os seguintes (15): Tipos de parmetros da operao, como entrada ou sada, e restries; Excees e mecanismos de correo de erros; Herana de interfaces e apoio a restries; Propriedades das interfaces; Mecanismos para criao de objetos; Oferecer suporte a eventos. Ao especicar excees e mecanismos de correo de erros, pode-se comear por denir as pr e ps-condies para esses casos, descrever os estados que so assumidos e garantir os estados resultantes em uma sequncia de execuo das operaes, uma vez que pode existir uma variedade de estados iniciais com os seus resultantes estados nais. As pr e ps-condies podero ser associadas a uma operao dentro de um diagrama da UML, mas no est denido um padro para descrev-las. Algumas abordagens possveis so (15): Utilizar um padro de nome para cada restrio (eles devem ser o mais simples e prticos possveis); Ter uma nica pr-condio, com mltiplas ps-condies, incluindo a apropriada distino de cada pr-condio do caso; Vericar a existncia de operaes com o mesmo nome e assinatura, combinlas para fazer uma especicao completa, como descrita no Catalysis(27).

34

No contexto de herana das interfaces, a linguagem Java permite herana de interfaces alm de permitir que classes Java implementem vrias interfaces, enquanto que uma classe Java poder herdar outra classe Java. Deve-se ter cautela ao usar a herana de interfaces, pois estas denem especicao dos componentes. Na criao de objetos em EJB, comum usar objetos fbrica que so usados para criar instncias de outros objetos, diminuindo o acoplamento entre as classes. As fbricas so usadas para identicar famlias de objetos. O suporte a eventos feito de forma que, ao invs do componente oferecer a interface, ele ir invocar operaes desta interface para sinalizar eventos ou mudanas signicativas no estado. A sada de uma interface atua como um sorvedouro ou o destino para eventos de sinais e o componente oferece uma interface para permitir o tratamento aos eventos.

4.4

Montagem do Sistema

A montagem o processo de reunir componentes e os sistemas existentes em um sistema funcional, projetando uma interface para o usurio baseada na utilizao dos modelos de caso de uso para formar a aplicao. As partes da montagem tm vrias caractersticas com o padro de congurao e prticas de gerenciamento. Cada componente individual ou sistema existente dever ser encarado como um item separado de congurao tendo assim sua prpria verso de controle. O componente de arquitetura representa a congurao do sistema que dene a quantidade de itens necessrios e quais as suas dependncias. A montagem responsvel pela denio da interface de usurio e a lgica de iterao do usurio com o sistema. A estratgia de interao com o usurio concebida em funo da utilizao dos casos de uso e modelos de interface. A aplicao passada para o uxo de testes do sistema e so feitos os testes de aceitao do usurio. A fase de montagem dos componentes recebe a especicao da arquitetura de componentes e utiliza os componentes, os sistemas existentes e os casos de usos para produzir a aplicao desejada, como pode ser visto na gura 4.2.

Figura 4.2: Fase de montagem da aplicao.

35

4.5

Teste e Implantao

O processo adotado no descreve as atividades para as fases de teste e implantao. Estas fases no foram detalhadas em atividades no processo, deixando a livre escolha do adotante ao processo que estabelece as atividades de teste e implantao.

36

Captulo 5 Tecnologias para desenvolvimento de componentes


Neste captulo sero apresentadas algumas tecnologias para desenvolver componentes, assim como suas caractersticas e restries. Uma abordagem mais profunda ser feita com a tecnologia EJB pois ser essa a adotada para o desenvolvimento dos componentes durante a parte prtica desse trabalho.

5.1

COM

Component Object Model (COM)(30) uma plataforma da Microsoft para componentes. Ela viabiliza comunicao entre processos e criao dinmica de objetos em diferentes linguagens. A sigla COM muitas vezes usada como sinnimo para um grupo de tecnologias, dentre elas: Object Linking and Embedding (OLE), OLE Automation, ActiveX, COM+ e DCOM. Apesar de introduzido em 1993 no desenvolvimento dos produtos, a Microsoft no divulgou sua biblioteca at 1997. COM uma tecnologia independente de linguagem de programao para o desenvolvimento dos seus componentes. Dessa forma, eles podem ser utilizados em ambientes diferentes dos quais foram criados. uma pr-condio do Component Object Model que o desenvolvedor fornea uma interface bem denida e separada da implementao, permitindo a reutilizao dos objetos sem o conhecimento de sua implementao. Apesar de ter sido implementado portvel a vrias plataformas, COM muito utilizado nos sistemas operacionais da Microsoft Windows(30). Tem-se trabalhado para que ela seja substitudo, ou pelo menos estendido, pela plataforma Microsoft .NET, suportando ento Web Services atravs da Windows Communication Foundation (WCF).

5.1.1

COM+

COM+ o nome da tecnologia baseada nos servios e funcionalidades da COM e sua primeira verso foi lanada no Windows 2000. COM+ acrescentou COM componentes para suportar as funcionalidades da Microsoft Transaction Server (MTS).

37

Essa tecnologia tambm encapsula algumas atividades de baixo nvel, como manuteno do pool de conexes, nalizao de conexes, controle transacional e distribuio e controle de submisses. Para fornecer aos desenvolvedores suporte a transaes distribudas e melhor gerenciamento de memria e processamento, assim como para posicionar o Windows como uma alternativa a outros sistemas operacionais corporativos, a Microsoft introduziu a tecnologia Microsoft Transaction Server no Windows NT Service Pack 4. No Windows 2000, tal extenso signicativa COM foi incorporada ao sistema operacional e renomeada COM+. Na mesma poca a DCOM foi reconsiderada como uma entidade separada.

5.1.2

NET

A plataforma COM vem sendo substituda pela Microsoft .NET, com a Microsoft focando seu marketing exclusivamente a essa nova plataforma. A COM era geralmente usada para interoperar cdigos complexos e de grande desempenho com interfaces ao usurio em Visual Basic ou ASP. Para algumas extenses a COM agora foi depreciada em favor da .NET j que a .NET fornece ferramentas de desenvolvimento rpido similares ao Visual Basic tanto para Windows Forms quanto para Web Forms com Just-in-Time(JIT), o cdigo de alto desempenho pode ser implementado em C#. Apesar disso, a COM permanece como uma tecnologia vivel com importante base de sistema legado. Por exemplo, o Software Development Kit (SDK), popular renderizador do DirectX 3D, baseado em COM. A COM tambm trabalha com o controle de scripts de aplicaes como o Ofce ou o Internet Explorer, pois fornece uma interface para chamar mtodos de objetos COM de um script ao invs de necessitar o conhecimento de uma API em tempo de compilao. Vrios servios fornecidos pela COM+ ainda so importantes em aplicaes .NET corporativas, tais como transaes e las de componentes.

5.2

EJB

Nessa seo sero abordados tpicos sobre o funcionamento dos Enterprise Java Beans (EJB) em sua verso 3.0. A gura 5.1 simplica o funcionamento da arquitetura EJB: Os EJBs so conhecidos por serem o ncleo da plataforma J2EE (Java 2 Plataform Enterprise Edition) justamente por sustentarem de uma maneira robusta e simples o desenvolvimento de aplicaes de grande porte, provendo um modelo distribudo de componentes de negcio e provedores de servios dentro do continer da aplicao. Em EJB, os beans so considerados remotos; ento, mesmo na implementao de um bean descrito como local, deve-se fazer uma busca pela implementao da interface e ento pode-se utilizar suas funcionalidades. O responsvel por achar, instanciar e retornar a implementao da interface o continer onde executa-se

38

Figura 5.1: Arquitetura EJB. a aplicao. Caso o continer no ache ou apresente falha nesse processo, uma exceo ser lanada pela aplicao e o uso do componente car inviabilizado. Alguns dos conceitos a serem apresentados sobre os EJB sero: Tipos de beans (stateless,statefull e Message driven beans); Entidades; Bean ou Container Managed Persistence (BMP ou CMP); Callbacks e Listeners; Interceptors.

5.2.1

Tipos de Beans

O primeiro estudo a se fazer sobre os EJBs so quais os tipos de beans existem. Esta uma pergunta simples tendo em vista que existem apenas trs tipos: stateless, statefull e Message Driven Beans (MDB). Para entender o porqu de existirem trs tipos diferentes, preciso saber quais so suas funcionalidades quando utilizar cada um deles. Os chamados stateless beans e os statefull beans so aqueles que devem ser descritos em uma interface com a anotao @Remote ou @Local. Essas interfaces denem o contrato estabelecido com os clientes para que possam utilizar as funcionalidades desse componentes. Ambos possuem suas diferenas. As classes que os implementam devem ser anotadas com @Stateless, para o primeiro, ou @Statefull, para o segundo. Isso garante que o bean dito no estvel tenha um ciclo de vida de submisso e a cada nova submisso uma instncia sem dados preservados seja apresentada ao cliente. Para esse caso, as variveis de instncia no devem ser utilizadas no processamento pois sero perdidas a cada nova submisso. O bean com a descrio de estvel ser mantido pelo continer at que um mtodo seja chamado para destruir essa instncia. Nesse caso ele ter um escopo de vida dito de sesso e mesmo que o cliente submeta vrios pedidos, os dados mantidos em variveis de instncia sero passados entre as submisses e podem 39

ser utilizados em diferentes chamadas do componente. Para esses EJBs, deve existir um mtodo com a anotao @Remove que, ao ser invocado, o cliente esta informando ao continer que essa instncia pode ser desalocada da memria. Por ser estvel, esse bean pode car muito tempo em memria at que seja desalocado. Nesse tempo nem sempre ele estar sendo utilizado. Sendo assim, o continer EJB pode aplicar instncia do bean statefull uma tcnica de economia de memria chamada, tornando o bean "inativo". Na verdade esse bean no ser retirado do pool, mas sim da memria principal. Todos seus atributos sero serializados e guardados em uma memria secundria. Quando o cliente voltar a requisitar os servios desse EJB, o continer ativa-o e restaura seus atributos. Ambos tm suas vantagens e desvantagens, mas dependendo da situao e da lgica a ser utilizada o desenvolvedor pode optar por um tipo ou pelo outro. O terceiro e ltimo tipo de bean o Message Driven Bean (MDB). Esses componentes so um novo tipo de bean introduzido na verso 2.0 da especicao dos EJB. MDB stateless em termos de suporte do estado de conversao entre os clientes. Ele utilizado para o processamento assncrono de mensagens do Java Message Service (JMS) e entra em ao aps o recebimento de uma mensagem de um cliente, sendo que no esto ligados a nenhum cliente especco. Na verdade, desde que as mensagens venham de uma la, um nico bean pode process-la. Em contraste com os outros tipos de beans, os MDB so invocados pelo continer em resposta chegada de mensagens JMS. Do ponto de vista do cliente, um MDB um consumidor de mensagens que executa uma ou mais tarefas no servidor, com base na sua interpretao da mensagem. Todos os MDB so assncronos, porm no so os nicos que podem processar mensagens. Os outros tipos de bean podem processar mensagens tambm, mas para eles isso deveria ser feito de um modo sncrono. Os MDB devem possuir a anotao @MessageDriven e devem implementar a interface MessageListener. Assim, eles devem possuir o mtodo onMessage que o continer chama para tratar o recebimento de mensagens.

5.2.2

Entidades

As entidades em EJB so descritas com a anotao @Entity. Esses beans so responsveis por representar um mapeamento el do banco de dados da aplicao para a linguagem Java. At a verso EJB 2.1, os beans com as anotaes reconhecidos como entidades deviam ser descritos em Java e mapeados para o banco de dados atravs de um arquivo .xml. Na verso 3.0 utiliza-se anotaes para mapear seus atributos. Uma curiosidade que as anotaes podem ser colocadas tanto na declarao dos atributos como nos mtodos get dessas propriedades. Essas entidades devem possuir um identicador nico, chamado de chave primria, primary key ou PK, e essa chave ser a responsvel por identicar unicamente uma instncia dentre todas de uma mesma entidade. Essa PK pode ser uma primitiva, int, long ou oat, ou outra classe, Integer, Long, Float ou String. Sendo que caso seja uma classe, esta deve seguir algumas especicaes para garantia da unicidade: 40

Os mtodos hashCode e equals devem ser sobrescritos nela; A classe e seu construtor, sem parmetros, devem ser declarados como pblicos; Deve implementar a interface Serializable; Todos seus atributos devem ter visibilidade pblica, ou com os respectivos mtodos get e set. Alm da chave primria, todos os atributos e relacionamentos no transientes da entidade podem ser anotados. Seguindo um mesmo padro que o utilizado em .xml pelas outras verses do EJB, as anotaes devem fazer a descrio de como os atributos da classe sero mapeados para o banco de dados utilizado.

5.2.3

Bean/Container managed persistence

A tecnologia EJB possui duas maneiras de suportar e controlar transaes. A primeira delas chamada de Bean Managed Persistence (BMP) e consiste em atribuir as responsabilidades desse controle ao programador. A outra maneira chamada Conteiner Managed Persistence (CMP) e consiste de utilizar uma implementao fornecida pelo prprio continer. Os beans de sesso, Statefull e Stateless, e os MDB podem declarar o uso de transaes por meio de BMP, onde o desenvolvedor deve utilizar a Java Transaction API (JTA) para codicar como ser feito o controle transacional das operaes de persistncia. A interface com a JTA provida pela classe UserTransaction do pacote javax.transaction e que obtida pelo bean atravs do contexto ao qual ele est inserido, via o objeto EJBContext. EJBContext uma super classe de EntityContext, MessageDrivenContext e SessionContext, e pode ser obtido atravs de uma injeo automtica de dependncia desse objeto. Uma vez que uma instncia da classe UserTransaction obtida pelo bean, ele est hbil a invocar mtodos como: begin(), commit() e rollback() que so responsveis pelo controle das transaes. Lembrando que ao utilizar a JTA o desenvolvedor no pode invocar outros mtodos de controle das transaes, como via JDBC. Para permitir o uso das BMP na aplicao, deve-se garantir que no deployment descriptor existe a entrada <transaction-type>Bean</transaction-type>. Qualquer bean pode usar o Conteiner Managed Persistence, CMT, que completamente declarativa, no existindo nenhuma indicao no cdigo que as transaes esto sendo controladas. Mas o continer deve ser informado sobre seu controle sobre as transaes por meio de uma entrada <transaction-type> Container </ transaction-type> no deployment descriptor. Os tipo de transaes adotados so: Mandatory; Never; NotSupported; Required; 41

RequiresNew; Supports. O atributo Required uma escolha segura para todos os componentes EJB: se uma transao est em andamento, quando uma operao executada, a operao se une, se no, uma nova transao iniciada. Os outros atributos fornecem variaes transacionais, mas so restritos a tipos especcos de beans. O lanamento de uma exceo levar, automaticamente, ao cancelamento da transao. Se uma exceo for lanada, o controlador de excees do continer deve invocar o mtodo setRollbackOnly() da classe EJBContext. Como est descrito na documentao da API da classe EJBContext, esse mtodo ir atribuir transao corrente um ndice para seu cancelamento e reverso de todas operaes nela feitas. Uma transao marcada para reverso nunca pode ser efetivada. Apenas os beans marcados como CMT podem acessar essa operao.

5.2.4

Callbacks e Listeners

No EJB 3 possvel denir algumas funes ditas callback e elas servem para executar algum processamento em uma etapa da vida de um determinado bean. Apesar das etapas passveis de callback serem pr denidas, o processamento a ser executado nelas deve ser denido pelo desenvolvedor. Segue a lista de possveis callbacks para o beans: Stateless beans e MDB: PostConstruct invocado na criao do bean e logo aps feitas as injees automticas de dependncia. PreDestroy invocado quando o bean j est sem nenhuma referncia e imediatamente antes do continer remov-lo do pool. Statefull beans: PostConstruct invocado na criao do bean e logo aps feitas as injees automticas de dependncia. PreDestroy invocado quando o bean j est sem nenhuma referncia e imediatamente antes do continer remov-lo do pool. Ser chamado imediatamente antes do mtodo com a anotao @Remove ser chamado. PrePassivate mtodo chamado antes de tornar o bean inativo e mandlo para a memria secundria. PostActivate mtodo chamado aps a reativao do bean para a memria principal e j com seus atributos restaurados. Entity: PrePersist invocada antes da entidade ser persistida no banco de dados. Todas as associativas que tiverem a opo de cascata sero alvo desse callback. 42

PostPersist invocada aps a entidade ser persistida no banco de dados. Todas as associativas que tiverem a opo de cascata sero alvo desse callback. PreRemove invocada antes da entidade ser removida no banco de dados. Todas as associativas que tiverem a opo de cascata sero alvo desse callback. PostRemove invocada aps a entidade ser removida no banco de dados. Todas as associativas que tiverem a opo de cascata sero alvo desse callback. PreUpdate chamada imediatamente antes do banco de dados ser sincronizado com o as entidades da aplicao corrente. PostUpdate chamada imediatamente aps o banco de dados ser sincronizado com o as entidades da aplicao corrente. PostLoad chamada imediatamente aps os dados da entidade serem carregados para a entidade e as associaes sejam feitas. Vale ressaltar que no existe o callback PreLoad e que esses mtodos no so compulsrios, ou seja, pode-se implementar um e deixar os outros sem denio. Os mtodos denidos pelos callbacks so chamados de Listeners e sempre que esse bean passar pelo callback que ele responsvel, seu processamento ser invocado.

5.2.5

Interceptors

Interceptors so funcionalidades de EJB que permitem que classes ou mtodos sejam interceptados antes de sua invocao. Essa interceptao deve ser implementada em um mtodo que tenha a anotao @AroundInvoke. O mtodo ou a classe a ser interceptado tambm deve ser anotado, mas com a anotao @Interceptors. Alm disso, importante ver que o mtodo interceptador e o mtodo interceptado podem estar implementados em uma mesma classe. A classe onde o mtodo interceptador est implementado no precisa de anotao, apenas o mtodo precisa da indicao.

5.2.6

Jboss Seam

Seam um framework sustentado e distribudo pela Jboss e combina duas das principais tecnologias para desenvolvimento em Java para Web atualmente: Enterprise JavaBeans, EJB 3.0, e Java Server Faces, JSF. Com o Seam pode-se buscar qualquer componente EJB, para isso, basta conhecer o seu nome no Seam. Seam tambm introduz o conceito de bijeo. Tomados a partir da injeo de dependncia do Spring, os objetos podem ser injetados ou exportados em variveis utilizando as anotaes @In e @Out. Esse framework tambm possui um conceito de contextos. Cada componente Seam existe dentro de um contexto. O contexto Seam padro chamado conversao e pode ser estendido por vrias submisses e, geralmente, acompanha o uxo 43

de negcios do todo, do comeo ao m. O contexto de sesso captura todas as aes de um usurio at que ele encerre o sistema ou feche o navegador. Pode-se gerar automaticamente um CRUD (Create-Retrieve-Update-Delete) na aplicao Web a partir de um banco de dados usando o comando ferramenta de linha de "seam-gen", que fornecido junto do framework. O desenvolvimento com Seam facilitado pelo uso do JBoss Tools, um conjunto de plugins desenvolvidos para a IDE Eclipse. Seam faz a integrao com JBoss RichFaces e as bibliotecas ICEsoft e ICEfaces, deAsynchronous Javascript And XML(AJAX), sem a necessidade de escrever o cdigo Javascript, facilitando a vida do desenvolvedor. Entre os recursos adicionais esto um criador de documentos Portable Document Format (PDF), e-mail, gerador de grcos e criador de planilhas Microsoft Excel. Pelas facilidades apresentadas pela framework, ela ser utilizada para integrar os componentes desse trabalho e manter a interface com o usurio atravs das pginas Web.

44

Captulo 6 Estudo de caso: Sistema de Alocao de Salas


Neste captulo ser apresentada a abordagem prtica realizada para estudo do processo de desenvolvimento baseado em componentes. Visando o desenvolvimento de uma biblioteca de componentes de negcio, bem especicada e devidamente documentada para o Sistema de Alocao de Salas em laboratrios de informtica.

6.1

Viso e escopo do sistema

Visando benefcios Universidade de Braslia, UnB, a abordagem prtica para o trabalho ser realizada no laboratrio de informtica do Departamento de Cincia da Computao, Linf, sendo um ambiente de uso comum dos alunos da graduao e ps-graduao em Cincia da Computao. O objetivo do sistema a ser desenvolvido automatizar atividades no processo de alocao de salas do laboratrio. Atualmente, esse processo envolve o preenchimento manual de formulrios para reserva de salas para os professores e tambm a requisio de instalao de softwares para uso em aula prticas nos laboratrios. Alm disso, o sistema busca solucionar problemas de conitos entre os requerentes na reserva de salas no mesmo horrio e minimizar a espera pela instalao de software em determinada sala. Os principais atores envolvidos neste sistema sero enquadrados em dois tipos: Os requerentes de sala; Os gestores do Linf. Neste sentido os requerentes so qualquer usurio capaz de alocar salas no laboratrio. No contexto do Linf sero: professores, palestrantes externos, as empresas Junior como, por exemplo: a de Computao (Cjr) e a de Engenharia Mecatrnica (Mecajun), e outras possveis pessoas. Os gestores do Linf correspondem a trs atores: Secretria;

45

Bolsista; Coordenador. A Secretria responsvel por receber todos os pedidos de alocao de sala e de instalao de software, realizando o primeiro ltro na avaliao dos pedidos. Vericada a necessidade de instalao de software, o Bolsista includo no processo. O Bolsista responsvel por prover a manuteno do hardware e software nas mquinas do Linf. Sendo assim, solicitada a instalao de um novo software, ele responsvel pela segunda avaliao do pedido de instalao, vericando todas as possibilidades para melhor uso do laboratrio. O Coordenador do Linf acompanha todas as atividades que ocorrem no laboratrio e pode emitir parecer sobre a ocorrncia de alguma ilegalidade. Tambm o responsvel mximo para resoluo de pedidos de maior diculdade ou urgncia. Com a identicao destes atores foram representados de forma hierrquica, para que funcionalidades que podem ser executadas por todos os atores fossem executadas de forma genrica. Neste sentido a gura, 6.1 visa exemplicar esta viso.

Figura 6.1: Atores e casos de uso. No sistema atual, o preenchimento de formulrios para reserva de sala e instalao de softwares deve ser feito pelos professores que desejam esses benefcios. Preenchidos, esses formulrios so avaliados pela secretria do Linf que verica se no h conitos de horrio para as salas e, se assim estiver, efetua a reserva utilizando planilhas do Microsoft Excel. Se nos pedidos contiverem softwares a ser instalados, ela entrar em contato com o bolsista para que ele verique a possibilidade de instalao do software requerido. Aps estes procedimentos a secretria avisa ao professor que este j poder fazer uso da sala solicitada. A soluo proposta que, utilizando os recursos Web, construa-se um sistema que gerencie a alocao de salas, sendo exvel para insero de: novas salas, novos softwares e novos usurios. Esta prover uma exibilidade necessria para alocao dos horrios de aula e gerando o mnimo de transtorno para todos os usurios 46

envolvidos neste sistema. O sistema dever suportar vrios usurios utilizando o sistema concorrentemente, pois os usurios podem se cadastrar e reservar salas quando necessitarem, aps passarem por aprovao da secretria do laboratrio. Algumas questes no funcionais que devero ser providas pelo sistema so: permitir no mnimo cinco usurios concorrentemente, a gerao das pginas dever ser no mximo de dez segundos e o tempo de resposta mdia dos servios dever ser de trs segundos. Dever existir autenticao dos usurios provendo integridade e conana para utilizao do sistema. Tambm ser provido tratamento de erros, disponibilizao de mensagens na execuo das operaes e o sistema dever ser modular e extensvel, sendo utilizada a linguagem Java para o seu desenvolvimento e banco de dados MySQL.

6.2

Principais funcionalidades

As principais funcionalidades do Sistema de Alocao de Salas, SAS, identicadas juntamente com usurios do laboratrio, so as seguintes: Manter Requerentes; Manter Sala; Manter Software; Solicitar Software; Reservar Sala; Autenticar Usurio. Cada item ser detalhado em uma sequncia de passos para que os usurios compreendam como ser utilizado o sistema, para prover de forma clara e concisa a funcionalidades que o mesmo deseja.

6.2.1

Manter requerentes

Esta a funcionalidade responsvel pela manuteno dos requerentes na base do sistema. O primeiro passo a ser realizado o de cadastro, sendo feito por qualquer pessoa tendo o uso da Internet, apenas sendo necessrio o preenchimento de dados pessoais de identicao do usurio. Este usurio estar inativo para o sistema at que a Secretria autorize seu acesso. Conrmado o cadastro, o usurio poder requisitar reservas de salas e alterar seus dados cadastrais no sistema. Os responsveis pela gerncia do laboratrio possuem a funcionalidade de pesquisar os usurios cadastrados, para vericar em qual situao o usurio se encontra e as formas de entrar em contato com este usurio.

47

6.2.2

Manter sala

Nesta funcionalidade fornecida a manuteno das salas, que disponibiliza primeiramente a incluso das salas do laboratrio por parte dos responsveis pelo Linf. Entre as informaes que sero providas nesta incluso, que so de importncia relevante para a reserva da sala pelo Requerente esto: Nmero de mquinas na sala; Nmero de mquinas funcionando na sala; Situao do projetor da sala; Observaes gerais sobre a sala; Lista de softwares instalados na sala. Aps essas informaes, a sala estar liberada para ser reservada pelo requerente. As informaes acima podem ser editadas pelos responsveis pelo Linf. Caso a situao da sala sofra alterao nestas caractersticas, as mesmas podem ser visualizadas pelo Requerente. Todos os usurios tm acesso tabela de alocao dos horrios das salas para vericar os horrios que se encontram disponveis e os que esto ocupados. Isso ajudar no gerenciamento de salas no laboratrio, j que implica no respeito s regras de negcio para alocao, como a permanncia de uma sala livre em todos os horrios do laboratrio para uso dos alunos ou a vericao se o mesmo requerente possui no mesmo horrio mais de uma sala.

6.2.3

Manter software

Nesta funcionalidade, o responsvel tcnico do laboratrio, o Bolsista, tem controle sobre todos os uxos. Ele pode incluir informaes de sistema operacional, verso e descrio dos softwares na base do sistema, sendo possvel atualiz-los ou exclu-los futuramente. Neste sentido, ele sempre respeitar a necessidade dos requerentes vericando nas salas a necessidades dos softwares que podem ser includos ou removidos sempre buscando o melhor desempenho dos equipamentos do laboratrio.

6.2.4

Solicitar software

Esta funcionalidade busca oferecer ao Requerente uma forma de requisitar um software para ser instalado em uma determinada sala para ministrar uma determinada aula ou palestra sendo uma das atividades principais do sistema. Primeiramente o requerente dever preencher o formulrio de solicitao informando: Nome do professor; Nome da disciplina e turma; Nome do programa; 48

Formas de encontrar o programa; Necessidade de instalao em um sistema operacional especco; Alternativas quele programa; Alguma observao adicional. Preenchida adequadamente a solicitao, a Secretria do Linf poder visualizar que existe uma pendncia de instalao. No havendo nenhuma irregularidade na solicitao, o sistema noticar o Bolsista do laboratrio para que este prossiga com a instalao do software na sala determinada. Caso haja algum problema na etapa de instalao, o Requerente ser informado; caso contrrio, o Bolsista dever realizar a instalao e, manualmente, utilizar a funcionalidade de manuteno de software para incluir o software no sistema e associ-lo sala onde foi instalado. O diagrama de caso de uso 6.2 foi construdo para expressar essas funcionalidades:

Figura 6.2: Diagrama de caso de uso para solicitao de software.

49

6.2.5

Reservar sala

A principal funcionalidade do sistema reservar salas. Sendo assim, o procedimento dever acontecer com o Requerente escolhendo o horrio e a sala que ele deseja reservar. Para isso dever preencher o formulrio de reserva, com as seguintes informaes: Perodo de alocao; Motivo; Softwares necessrios para o uso; Observaes adicionais; Publico alvo; Professor ministrante. Com o formulrio preenchido, este passar para a aprovao da Secretria do Linf. Se no necessitar da instalao de um novo software, ser aprovado pela Secretria e ento a reserva j estar conrmada. Necessitando de novos softwares, precisar da avaliao de instalao do software pelo Bolsista. Caso a Secretria ou o Bolsista no aprovem, o Requerente ser comunicado dos motivos da rejeio. Justamente por ser possvel visualizar o estado do pedido de reserva, o requerente pode acompanhar sua requisio. Sendo este o principal uxo do SAS, o diagrama de caso de uso da gura 6.3 foi construdo. Este caso uso contm o maior nmero de regras de negcio do sistema, dentre elas: Vericar se existem reservas no mesmo horrio em uma mesma sala; Certicar a existncia de, pelo menos, uma sala livre para uso dos alunos; Validar se um Requerente possui mais de uma sala alocada no mesmo horrio, se ocorrer a Secretria alertada da situao; Solicitar aprovao do Bolsista, caso haja necessidade de instalao de softwares. Essas regras devero ser respeitas para execuo dos servios mostrados na gura 6.3 pelos atores que esto envolvidos.

6.3

Modelagem conceitual do negcio

Como visto no captulo 4, o Modelo Conceitual do Negcio visa moldar uma arquitetura bsica das entidades do sistema para modelagem dos futuros componentes. Para alcanar este objetivo foram consideradas as funcionalidades providas e identicou-se as seguintes entidades: Software; 50

Figura 6.3: Diagrama de caso de uso para reservar de sala. Sala; Usurio; Instalao de Software; Reserva de Sala; Horrio. Sendo assim, tomando por base que a principal funcionalidade do sistema a reserva de sala, pode-se fazer algumas consideraes. A reserva de sala est vinculada a somente uma sala e um usurio em um nico horrio, mas que pode se repetir em vrios dias. Estes usurios podem solicitar vrias instalaes de software, mas estas esto vinculadas a uma nica sala. A ltima relao que uma sala pode conter vrios softwares instalados. Com isso, o diagrama do Modelo Conceitual do Negcio foi construdo e segue na gura 6.4. Esta a verso inicial do modelo, que ser renado ao longo do processo, trazendo maiores detalhes de como ser a identicao, interao e montagem dos componentes.

51

Figura 6.4: Modelagem Conceitual do Negcio.

6.4

Identicao das interfaces do sistema

Esta parte visa identicar as interfaces do sistema. O padro de nomenclatura para as interfaces dos componentes de negcio o suxo "Service", j para as interfaces dos componentes de persistncia o suxo "Dao". Para ambos os casos, suas implementaes devem ter o mesmo nome, seguido pelo suxo "Impl". Para facilitar esse trabalho de modelagem, elas foram divididas em trs tipos: Interfaces de negcio; Interfaces de sistema; Interfaces de persistncia. Como foi visto anteriormente, as interfaces de negcio so responsveis por prover os mtodos que trabalham com dados de entrada e produzem resultados seguindo as regras de negcio do sistema. As interfaces de sistema que so aquelas que provm do estudo dos casos de usos focando como o sistema interagir para manter informaes sem envolver regras de negcio. As interfaces de persistncia visam fornecer aos componentes uma interface com o banco de dados para que o componente no perca a exibilidade e portabilidade com uma possvel mudana da camada de persistncia. Com isso, identicou-se as seguintes interfaces de negcio: 52

ManterRequerenteService; ManterSalaService. As interfaces ManterRequerenteService e ManterSalaService so as nicas funcionalidades do sistema que no dependem de outras funcionalidades para existirem no processo. Desse modo, essas interfaces so consideradas como o ncleo do sistema pois se tornam importantes para que as outras funcionalidades existam utilizando estas duas. Como resultado do renamento destas interfaces, ser mostrado na gura 6.5 o mapeamento das funcionalidades especicadas nos requisitos para os mtodos que a interface prover, como a interface do ManterRequerente.

Figura 6.5: Mapeamento do ManterRequerente. Aps ter identicado as interfaces de negcio, foram identicadas as interfaces de sistemas: AutenticarUsuarioService; ManterSoftwareService; ReservarSalaService; SolicitarSoftwareService. A interface AutenticarUsuarioService depende da existncia de um requerente provido pela interface ManterRequerenteService. As interfaces ManterSoftwareService, ReservarSalaService e SolicitarSoftwareService necessitam do ManterSalaService, pois s far sentido reservar salas existentes criadas pelo ManterSalaService e tambm no faz sentido existirem softwares ou mesmo solicit-los se no encontrem uma sala para instalao dos mesmos. Neste sentido, essas interfaces apiam as interfaces ncleo na construo do sistema e no fazem sentido existir sem a presena destas. O mapeamento e o renamento da interface Manter Software segue na gura 6.6. Aps a denio das interfaces de negcio as seguintes interfaces de persistncia dos dados, foram identicadas: AutenticarUsuarioDao; 53

Figura 6.6: Mapeamento do Manter Software. ManterRequerenteDao; ManterSalaDao; ManterSoftwareDao; ReservarSalaDao; SolicitarSoftwareDao. Estas interfaces foram criadas para separar a camada de negcio da camada de persistncia, visando maior exibilidade s mudanas na lgica de persistncia. Substituir componentes de persistncia, alterar o banco de dados utilizado ou modicar o protocolo de comunicao entre a linguagem Java e o banco de dados no deve impactar em alteraes na camada de negcio.

6.5

Modelagem de tipo de negcio

Este modelo um renamento do Modelo Conceitual do Negcio. O modelo de tipo de negcio o mapeamento do modelo de entidade da parte de anlise para a parte de projeto. Neste modelo so denidos os atributos de cada classe e as classes que independem da existncia de outras so consideradas como principais para o projeto, recebendo o esteritipo core. O mapeamento para o Modelo do Tipo de Negcio feito atravs das classes que foram renadas do Modelo Conceitual do Negcio. No caso do sistema SAS foi observado que a classe Horrio poderia ser incorporada aos atributos da classe ReservaSala tornando-se desnecessrio manter uma entidade somente para armazenar os registros de horrio. Aps este renamento criou-se o seguinte modelo 6.7 de tipo de negcio para o sistema SAS: Obtendo uma clara concepo do sistema, sabendo as entidades relacionadas nesta modelagem de tipos de negcio e tendo as interfaces do sistema denidas, assim como seus mtodos e o seu funcionamento compreendido, chega-se na etapa de interao destas interfaces para formar o sistema. Esta atividade se d com a construo da arquitetura dos componentes.

54

Figura 6.7: Modelo do Tipo de Negcio.

6.6

Arquitetura de componentes

Para a construo deste artefato, primeiramente deve-se ter o modelo de tipos de negcio e as interfaces para esse modelo. Estas devero conter as assinaturas dos mtodos que sero providos, dos tipos de parmetros de entrada e os valores de retorno. Deve-se tomar um cuidado especial para denir as excees que podero ser lanadas por estes mtodos. Com estas questes renadas passa-se para a construo da arquitetura que dever mostrar como a interface de cada componente se relacionar com outros componentes para formar o sistema. No sistema SAS os componentes identicados, alm de implementarem as suas respectivas interfaces de negcio, devero consumir servios das interfaces de per55

sistncia para prover menos dependncia com a parte de persistncia dos dados. O modelo de arquitetura de componentes atribui um esteritipo aos componentes do sistema, comp_spec. O diagrama 6.8 representa a arquitetura dos componentes do sistema:

Figura 6.8: Arquitetura dos Componentes. Esta a composio do sistema de alocao de salas, contendo os seus uxos de manuteno e os processos de reserva de sala e instalao de software. No diagrama esto, tambm, todas as dependncias do sistema e relaes para interao dos componentes. Aps estes passos, pode-se partir para implementao de cada componente descrito nesta seo.

56

Captulo 7 Anlise da utilizao do processo


Neste captulo ser feita uma anlise sobre o desenvolvimento de um sistema de negcio que adotou o processo descrito por John Cheesman e John Daniels em (15). Para isso, as atividades descritas orientaram as fases do desenvolvimento do sistema, com o objetivo de produzir uma biblioteca de componentes de negcio. Seguindo o processo adotado, foi feita a especicao dos requisitos e das regras de negcio e projetada uma diviso, em componentes, das funcionalidades a serem providas. A documentao, as interfaces disponibilizadas, o tratamento de erros e outras caractersticas, acerca dos componentes, foram especicados e esto disponveis dentre os diversos artefatos produzidos. O processo de desenvolvimento adotado no restringe quais tecnologias, ferramentas ou padres utilizar para confeccionar os artefatos descritos. Sendo assim, a tecnologia escolhida para construir os artefatos de modelagem foi a linguagem UML, auxiliada pela ferramente JUDE devido habilidade da equipe envolvida e facilidade de obteno. Por isso, os artefatos de modelagem esto restritos a essa ferramenta.

7.1

Levantamento de requisitos

Nesta fase foi feita especicao dos requisitos a serem atendidos pelo sistema. As funcionalidades foram destacadas e os casos de uso foram detalhados em artefatos. Para isso foi necessrio um entendimento do processo a ser automatizado, com as regras de negcio envolvidas e os relacionamentos dos atores envolvidos. Antes da especicao das funcionalidades do sistema, foi preciso conhecer como o processo a ser automatizado ocorre. Nesse sentido, o processo de desenvolvimento descreve que a construo de um Diagrama de Atividades pode ser feita para facilitar o entendimento de como as atividades envolvidas ocorrem dentro do negcio. Para esse estudo de caso, em particular, os cenrios foram considerados simples de entender, no necessitando desses artefatos. Para realizar a especicao de requisitos, visando conhecer as funcionalidades que devem ser implementadas no sistema, foi utilizada a tcnica de entrevista. Foram realizadas trs entrevistas com o bolsista do Linf, sendo que duas destas contaram com a presena da secretria tambm. Com a interao com estes usurios, suas necessidades quanto ao processo foram capturadas tomando por base 57

a tcnica utilizada. O preenchimento dos formulrios de solicitao de software e de reserva de sala eram feitos manualmente e as regras de negcio aplicadas pela secretria. Aps a entrevista, buscou-se elaborar um prottipo do sistema para validar se os requisitos especicados foram compreendidos e se os processos de reserva de sala e solicitao de software estavam corretamente identicados. Aps esta validao partiu-se para a formalizao dos requisitos em documentos de casos de uso. Seguindo o processo, os diagramas de casos de uso foram construdos para modelar quais casos de uso existem no sistema e qual a relao de cada um com os atores. O padro a ser adotado para documentao e detalhamento dos casos de uso no foi denido pelo processo. Por isso o padro proposto e disponibilizado pelo RUP foi utilizado, j que a equipe que trabalhou com essa atividade tem experincia com esse formato. A modelagem dos casos de uso baseia-se na existncia de quatro atores principais para o sistema: o Coordenador, o Secretrio, o Bolsista e o Requerente. Com isso foi proposto que um ator fosse criado, o usurio, para representar as funcionalidades viveis a esses quatro atores. Isso ocorre para as funcionalidades que so o ncleo do negcio, como a pesquisa e reserva de salas ou a solicitao de um software. Os atores esto representados na gura 6.1 que foram vistos no captulo anterior e o diagrama de caso de uso Manter Requerente segue na gura 7.1. Esse caso de uso exemplica como os diversos atores foram utilizados nos diagramas, inclusive o usurio.

Figura 7.1: Diagrama de caso de uso para gesto de requerentes. Um outro diagrama construdo nesta fase segue o padro de um diagrama de classes e visa ilustrar a ideia de como as entidades envolvidas com o sistema esto relacionadas entre si. Essa uma boa prtica porque esse modelo dever ser reestruturado e incrementado at que se tenha o diagrama de classes das entidades para o desenvolvimento do sistema.

58

7.2

Especicao dos componentes - A modelagem

Ao contrrio da fase anterior, nesta fase foram confeccionados muitos artefatos e nela que se concentrou a maior parte das atividades. De modo que ela foi descrita, atravs de atividades que foram desenvolvidas de uma maneira iterativa, com auto-alimentao e que foi dividida em trs etapas. Seguindo por essas etapas, os artefatos foram produzidos, passados para as seguintes etapas e incrementados. As atividades, por vrias vezes, implicam no aprimoramento de um diagrama ou no detalhamento de um descrio ou na refatorao de documentos produzidos. As trs etapas que compem essa fase so: Identicao dos componentes; Denio da interao dos componentes; Especicao dos componentes.

7.2.1

Identicao dos componentes

Pela ordem de simplicidade e independncia dos outros artefatos, a primeira atividade realizada foi o renamento do Modelo Conceitual do Negcio para que surgisse o Modelo do Tipo de Negcio. Inicialmente foi difcil entender o que deveria ser alterado de um para o outro, pois ambos so similares. Mas aps a avaliao dos tipos que deveriam permanecer no modelo foi fcil atualizar esse artefato para que nele estivessem os esteretipos e os campos de informao de cada um dos tipos identicados. O diagrama para o Modelo do Tipo de Negcio segue na gura 7.2. Realizada esta atividade, a prxima executada foi modelar, sob uma primeira perspectiva, quais interfaces que existiriam no sistema e separ-las em interfaces de negcio ou interfaces de sistema. O processo dene que essas interfaces devem ser diferenciadas, para a especicao dos componentes, entre as com maior nmero de regras de negcio implementadas, as interfaces de sistema, e as com menor, as interfaces de negcio. No estudo de caso deste trabalho, essas denies no tiveram grandes impactos no projeto do sistema. Talvez para projetos de maior complexidade, que existam muitas interfaces, a diferenciao destes tipos pode facilitar a construo da arquitetura do sistema. Aps a confeco desses artefatos, para nalizar esta etapa falta a construo do esboo da arquitetura adotada entre os componentes. Com as interfaces dos componentes j construdas, resta denir quais componentes se relacionam com outros e como eles deveriam se comunicar para realizar a persistncia dos dados.

7.2.2

Denio da interao dos componentes

O processo descreve que esta etapa deve melhorar os modelos que descrevem as interfaces dos componentes, incluindo as operaes a serem providas por cada uma. Com essa atividade, deveriam ser includos mtodos, as descries sobre o que cada

59

Figura 7.2: Modelo do Tipo de Negocio. um deles deveria fazer, os parmetros de entrada e os parmetros de sada. Entretanto durante a especicao dessas interfaces na etapa anterior, alguns desses mtodos j foram descritos. Esta etapa incluiu a reviso das especicaes dos mtodos j presentes nos modelos de interfaces e com o aprimoramento dos mesmos. Para essa atividade, o processo dene trs objetivos: identicar as operaes de negcio, revisar e refatorar os diagramas que identicam as interfaces de sistema e de negcio e o diagrama de arquitetura dos componentes. Devido a isso, o trabalho dessa etapa foi revisar o que j havia sido denido na anterior. As assinaturas dos mtodos foram denidas na etapa anterior, mas todos foram revisados neste momento. Nomes, parmetros de entrada e sada foram 60

modelados e documentados juntos aos diagramas j construdos. Algumas alteraes surgiram, pois s foram visveis com o modelo de arquitetura entre os componentes construdo. Agora as chamadas entre os componentes puderam ser melhor especicadas, permitindo que os tipos de parmetros dos componentes servidores fossem coerentes com os tipos manipulados pelos seus respectivos clientes. Uma das mudanas oriundas da anlise do diagrama de arquitetura foi a diviso das funcionalidades dos componentes. Com o objetivo de descrever componentes que tivessem funcionalidades exclusivamente de processamento das regras de negcio, foi utilizado o padro Data Acess Object(DAO). Cada implementao deve executar seu processamento com as regras de negcio e delegar o processamento das operaes com o banco de dados para, pelo menos, um DAO. O diagrama de arquitetura antigo segue na gura 7.3.

Figura 7.3: Primeira verso da arquitetura de componentes. A adoo do padro DAO uma soluo que viabiliza a separao entre a camada de negcio e a de persistncia. Com a reestruturao do diagrama, uma nova verso do artefato de arquitetura dos componentes foi produzido; na gura 6.8, do captulo anterior.

61

7.2.3

Especicao dos componentes

Esta foi ltima etapa da fase de especicao e projeto do sistema. Como descrito pelo processo, essa etapa deve revisar, validar e documentar tudo o que as outras duas etapas eventualmente no zeram e que pode originar a um erro durante a implementao. Durante a primeira etapa da especicao foi feito um esboo de documentao. Ento nessa etapa foi realizada a atividade de detalhamento dessa documentao. Primeiramente, foram analisadas as pr e ps condies necessrias nos mtodos dos componentes. Em seguida, as premissas para que um componente pudesse realizar seu processamento, com base no conjunto parmetros de entrada. Em terceiro, foram analisados e documentados possveis cenrios de erro descritos no caso de uso. Validaes como garantir que um parmetro no nulo ou se uma diviso no por zero, no foram o enfoque dessa etapa. Os alvos dessas documentaes foram cenrios em que regras de negcio seriam violadas; por exemplo, reservar uma sala que ainda no foi salva no sistema. Primeiro deve-se registrar essa sala e depois possvel efetuar qualquer reserva sobre ela. Aps discorrer sobre essas validaes, faltou ainda descrever o que fazer caso alguma regra de negcio seja violada. O processo adota o padro de lanamento de excees com qualquer no conformidade com as regras, assim que essa seja detectada. Um exceo foi criada no projeto, LinfBusinessException, e serve para avisar o cliente de que alguma regra do sistema foi violada. Um exemplo de documentao utilizada segue na gura 7.4 para o mtodo incluir do componente ReservarSalaService. Finalizada essa etapa concluiu-se tambm a fase de especicao e projeto do sistema. Seguindo os passos descritos no processo foi possvel ter uma viso de quais componentes implementar e o que cada um deveria fazer. Apesar de um tanto quanto repetitiva, do ponto de vista de revisar o mesmo artefato vrias vezes, o processo descrito foi til nessa fase, auxiliando na tomada de decises sobre a modelagem dos componentes do projeto.

7.2.4

A exceo do projeto.

Como mencionado anteriormente, uma exceo foi criada dentro do projeto para que as regras de negcio pudessem ser validadas, ou no, pela captura de uma instncia dessa classe, a LinfBusinessException. Seu cdigo simples, visto que consiste apenas na extenso da classe Exception e da sobrescrita de seus construtores principais. A lgica de implementao herdada de sua classe me. A captura de seu lanamento tambm feito de maneira idntica s outras excees. No houve nenhuma necessidade em personalizar mais a exceo para este projeto. Entretanto, justamente por dela ser requisitado apenas o funcionamento herdado pela super-classe, nada impede que em projetos futuros ela seja alterada e adquira novas funcionalidades.

62

Figura 7.4: Exemplo de descrio textual na modelagem. Um trecho de sua codicao e documentao segue na gura 7.5. No cabealho, em Javadoc, est descrito que ela ser utilizada para validar as regras de negcio dos sistemas e que pode ser alterada ou estendida em projetos futuros.

63

Figura 7.5: Exceo personalizada do projeto.

7.3

Denio da arquitetura do projeto

Com os componentes denidos, especicados e documentados, encerrou-se a fase de especicao e projeto. Entretanto, antes que se iniciasse a codicao dos componentes, foi necessrio elaborar uma arquitetura para que o sistema suportasse a comunicao desses componentes entre si e com outras camadas a serem desenvolvidas. Alm disso, um banco de dados precisou ser projetado. Essa seo no est descrita no processo adotado, mas devido ao nmero de diculdades encontradas durante sua execuo ela ganha importncia em ser analisada tambm. Alguns problemas chave foram contornados nessa fase. O primeiro problema foi a diculdade em lidar com a nova tecnologia, Jboss Seam. Este framework foi adotado para o projeto devido s facilidades que apresenta na integrao de Java Server Faces, JSF, com a tecnologia utilizada no desenvolvimento dos componentes, Enterprise Java Beans, EJB. Conhecer e trabalhar com uma nova tecnologia requer conhecimentos tericos e prticos. Sendo assim, aps os estudos tericos sobre o framework, a arquitetura base para o projeto elaborada com o desenvolvimento de um caso de uso bsico, ManterSoftware. Os componentes que implementam essa funcionalidade tambm foram implementados como teste para validar a viabilidade do uso das ferramentas. A diviso do projeto cou como representado na gura 7.6. Mas ela foi adotada para permitir que as camadas pudessem operar independentemente uma da outra. Cada camada tem suas prprias conguraes e se comunicam atravs da atuao do framework, que cadastra e integra os componentes de cada camada.

64

Figura 7.6: Diviso dos Projetos. Com isso pode-se ver os quatro projetos existentes. O primeiro, o sas, contm a camada de interface, que, nesse sistema, ser implementada em JSF. O segundo projeto, o sas-ear, o que contm as informaes para publicar o projeto dentro do servidor Jboss, servindo apenas para que o Seam consiga efetivar a integrao entre JSF e EJB. O terceiro projeto, o sas-ejb, o que contm os componentes de negcio a serem implementados, em EJB. O quarto projeto, o sas-persistence, o que contm os componentes de persistncia do sistema, assim como as entidades utilizadas e seus mapeamentos para o banco de dados. A atividade seguinte deu incio fase de codicao, comeando pelas entidades do sistema, mas envolveu uma deciso de projeto que permite que o sistema mantenha seus componentes, independentemente do banco de dados e o mapeamento utilizado. As entidades foram construdas em dois nveis hierrquicos, um nvel bsico e outro de mapeamento. No primeiro nvel foram criadas as entidades utilizadas na camada de negcio. Nelas foram representados os atributos de cada uma das classes e ainda constantes que fazem referncia a esses atributos. Isto foi projetado para centralizar, tanto a denio dos atributos como uma referncia a eles em um conjunto de classes comuns aos sistemas que utilizarem esses componentes. O segundo nvel das entidades utilizado pelos componentes de persistncia e so especializaes, herdam, das respectivas entidades base. Essas classes mapeiam

65

as entidades para as tabelas do banco de dados atravs das anotaes das entidades em EJB nos mtodos get das propriedades das classes. A gura 7.7 mostra como os nveis arquiteturais esto organizados pelos projetos.

Figura 7.7: Arquitetura padro por componente.

7.4

Codicao dos componentes

Essa etapa foi descrita no processo, mas por diversas razes ela sofreu vrias mudanas ao longo de sua execuo. Essas mudanas ocorreram por razes tecnolgicas. Durante a descrio da fase de codicao dos componentes, o processo utiliza exemplos baseado em verses antigas de EJB e baseando-se em um sistema que utiliza EJB puro. Alm de mudanas tcnicas de implementao dos componentes, tambm foram feitas algumas alteraes na modelagem. A inexperincia no desenvolvimento deste tipo de sistema levou alguns componentes a alteraes desde sua modelagem, na fase de especicao. Entretanto, todas essas alteraes foram levadas 66

aos artefatos de modelagem e os diagramas foram atualizados, mantendo-os como fonte de documentao dos componentes.

7.4.1

Adaptaes do processo

Como j foi descrito, a verso utilizada para o desenvolvimento dos EJB 3.0. Suas caractersticas j foram discutidas anteriormente, mas diferenas como uso de anotaes, tratamento de excees e instanciao de componentes so as principais alteraes entre as verses. Alm das questes da tecnologia EJB, importante analisar o uso do framework escolhido para integrar as diferentes tecnologias utilizadas nas diferentes camadas, o Jboss Seam. Embora JSF, tecnologia dos componentes de apresentao, e EJB, tecnologia dos componentes de negcio, possam ser utilizados sem o Seam para criar suas dependncias na aplicao, nesse estudo de caso foi decidido utiliz-lo. Como o processo trata que os EJBs devem ter sua infra-estrutura feita manualmente, algumas adaptaes tiveram que ser feitas. Um exemplo de alterao foi o tratamento instanciao dos componentes EJB. O processo descreve esta atividade como sendo uma atribuio do programador iniciar e cadastrar o componente servidor e realizar uma busca pelo componente cliente, caracterstica da verso 1.0 de EJB. Com a verso atual, 3.0, o servidor j automaticamente cadastrado, mas ainda necessrio que o cliente busque essa instncia. Utilizando Seam, nenhum dos dois necessrio. Anotaes do tipo @In e @Out fazem desnecessrio essa codicao por parte dos desenvolvedores. As adaptaes feitas no visaram apenas viabilizar detalhes tcnicos devido evoluo das tecnologias. Duas alteraes no processo tambm foram feitas nessa fase. A primeira que, segundo o processo, os EJBs deveriam guardar os estados nos diferentes nveis da aplicao, incluindo a conversao com o usurio. Porm os responsveis por fazer isso so as chamadas Actions que so conguradas pelo JSF. Sendo assim, foram propostos trs nveis de componentes pelo processo, mas devido adaptao com as tecnologias empregadas no sistema, apenas dois nveis de componentes de negcio existiro. O terceiro ser substitudo por uma camada de pginas JSF e componentes backing beans para controle de troca de informaes e interface com o usurio. Outra alterao no processo foi o tratamento descrito para o controle transacional. Na verso utilizada de EJB existe a opo desse controle ser feito exclusivamente pelo continer EJB do servidor utilizado. Nessa verso, as operaes com o banco cam agrupadas em uma nica transao at que o programador chame o mtodo de sincronizao da sesso persistente com o banco de dados. Durante o intervalo de duas sincronizaes uma transao ca aberta e as operaes que ela envolver ocorrerem de forma atmica. Neste tipo de transao, controlada pelo continer, ca determinado que qualquer exceo lanada pelo sistema ser tratada como estmulo ao cancelamento da transao corrente. Sendo assim, qualquer exceo capturada, seja ela de Java ou do sistema, levar ao cancelamento e a volta ao estado original (rollback) da transao, com o cancelamento da operao. assim que so tratadas e validadas 67

as regras de negcio dentro dos componentes do sistema, qualquer violao deve lanar uma LinfBusinessException e cancelar a operao.

7.4.2

Problemas encontrados e refatorao dos modelos

Outras mudanas tiveram que ser feitas, mas diferente das anteriores, no foram no processo, mas sim na prpria modelagem do sistema. Os modelos elaborados na fase de especicao foram muito teis para o desenvolvimento dos componentes. Quatro componentes foram implementados assim como foram especicados, mas dois sofreram alteraes nessa fase. Curiosamente, apenas as interfaces que devem conter implementaes das regras de negcio sofrem modicaes desde a modelagem inicial. Isso se deve ao fato de que os outros componentes, pela falta de regras que so aplicadas a eles, so muito simples. J quando o sistema mostra-se complexo, mudanas so necessrias. Os componentes alterados durante a codicao so os responsveis pelas implementaes das interfaces ReservarSalaService e SolicitarSoftwareService. Para ambos os componentes que sofreram alteraes, nenhuma complicao ocorreu durante essa refatorao. Primeiramente, foi feito um estudo sobre o modelo e uma anlise do impacto dessas mudanas. Estas interfaces contm poucas regras de negcio e praticamente no se relacionam com outras interfaces. Sendo assim, suas mudanas pouco inuenciam outras partes do sistema. Aps essa anlise dos impactos possveis, um novo modelo foi construdo para substituir o que estava incompatvel com as necessidades apresentadas. Com isso, novos mtodos foram inseridos e outros removidos do artefato de modelagem responsvel pela descrio desses componentes. Um exemplo segue na gura 7.8 com uma verso antes e outra aps a reestruturao da modelagem da interface ReservarSalaService. Quanto aos outros componentes, nenhuma alterao foi necessria, mantendose, ento, a coerncia com os diagramas construdos anteriormente.

7.4.3

Testes

Nesta fase, utilizou-se a reviso em pares. Um programador revisou os componentes produzidos por outro e vice-versa. Este procedimento se repete at que todos os componentes desenvolvidos sejam testados. Com os componentes testados, a mesma tcnica de reviso foi aplicada s funcionalidades e aos casos de uso. Cada um deles foi revisado e testado por outro desenvolvedor, que no tenha participado de sua implementao. Outro teste realizado para garantir a qualidade do sistema foi feito por um grupo de usurios que no participaram do desenvolvimento. Utilizando a documentao do projeto, esses usurios reportaram os erros encontrados, para futura correo. Este teste foi bom para validao das interfaces, funcionalidades e acessibilidade do sistema. No desenvolvimento desse sistema no foi possvel garantir a conabilidade dos componentes produzidos, pois faltou uma rigorosa execuo de testes. Por exemplo, 68

Figura 7.8: Exemplo de atualizao da modelagem. casos como: aumentar o nmero de usurios do sistema, validar os componentes desenvolvidos com o usurio nal e realizar os mais diversos uxos de execuo para fazer um teste de cobertura sobre as funcionalidades providas pelos componentes, deveriam ter sido feitos para que estes pudessem ser validados quanto sua conabilidade para que fossem reusados.

7.4.4

Documentao

Com os componentes desenvolvidos e testados, a ltima atividade a ser feita a documentao dos mesmos para que possam ser disponibilizados em uma biblioteca para consulta e reuso. Uma parte da documentao j est feita no formato de diagramas na linguagem UML. Estes diagramas so os mesmos desenvolvidos durante a fase de especicao e de projeto dos componentes. Neles esto especicadas quais interfaces existem e os mtodos de cada uma, assim como uma breve descrio textual explicativa do funcionamento de cada componente e seus parmetros de entrada e retorno. Entretanto, no basta ter uma srie de diagramas a parte e esperar que os desenvolvedores, sempre que desejarem buscar um componente, procurem em cada um desses diagramas. O mais fcil, para consultas, a documentao dentro do cdigo, j que pode ser facilmente consultada durante o desenvolvimento. Para os componentes de negcio desenvolvidos, essa documentao foi feita segundo o padro Javadoc. Um trecho de documentao retirado do cdigo segue na gura 7.9. importante lembrar que esse tipo de documentao foi colocado nas classes interface, pois assim sero visveis aos usurios dos componentes. Caso esse tipo

69

Figura 7.9: Documentao Javadoc utilizada. de documentao seja feito dentro das classes que implementam os componentes, seus usurio no tero visibilidade ao seu contedo. A documentao dentro das classes de implementao seguem um padro Javadoc para alguns mtodos considerados relevantes. Dentro dessas classes predominam comentrios em Java para descrio do cdigo, facilitando a manuteno do funcionamento interno dos mesmos e no visam ser disponibilizados para qualquer cliente.

7.5

Integrao dos componentes e validao do sistema

A ltima fase descrita pelo processo adotado faz referncia integrao dos componentes atravs de uma montagem entre eles. Basicamente consiste em agrupar todos os componentes desenvolvidos e coloc-los de modo a se encaixarem para atingir as funcionalidades desejadas no sistema. Essa fase foi a com menos problemas pois com os componentes desenvolvidos e testados individualmente, integr-los signica coloc-los dentro da arquitetura Seam e deixar que o framework utilizado faa a integrao entre eles. Todos os componentes foram registrados junto ao Seam para que eles cassem sob a responsabilidade deste framework. Nesta etapa, nenhum problema foi detectado. A prxima envolve validar as funcionalidades obtidas aps a integrao e comparar com o esperado como resultado. 70

Para isso, uma srie de testes foi realizada para garantir o sucesso da integrao e a corretura das funcionalidades. No foi detectado nenhum problema referente aos componentes. As nicas questes que ainda deveriam ser tratadas eram referentes a parte de controle de acesso do sistema. Essa caracterstica tambm foi deixada a cargo do framework Seam. Outra facilidade provida pelo Seam um componente para autenticao no sistema. Enquanto uma estrutura bsica fornecida pelo framework, o componente de autenticao implementa a lgica a ser utilizada para acessar o sistema. No controle de acesso implementado, foram utilizados os pers dos quatro usurios considerados para o sistema. Sendo assim, todas as restries impostas pelos documentos de caso de uso foram respeitadas. Aps o cumprimento de todas essas fases o processo est completo e seu objetivo foi atingido com a produo dos artefatos exigidos e a construo dos componentes modelados, resultando na composio do sistema com as funes requisitadas.

7.6

O sistema desenvolvido

Nesta seo, sero abordados alguns resultados do desenvolvimento do sistema, apresentando telas para facilitar a navegao de um usurio, utilizando a tecnologia EJB para o desenvolvimento dos componentes e o modelo da arquitetura, gura 7.7. Conseguiu-se desenvolver um sistema de alocao de salas adotando o processo descrito neste trabalho e chegou-se em alguns resultados consistentes com os artefatos que eram esperados. Para exemplicar a construo do sistema algumas telas foram capturadas. Primeiramente, uma tela dos possveis softwares cadastrados pelo Bolsista, mostrando as possibilidades de escolha de vrios sistemas operacionais e da gesto destes softwares, que podem ser alterados ou removidos. Como mostrado na gura 7.10. A funcionalidade de pesquisar reservas de sala mostrada pela tela apresentada na gura 7.11. Ela permite a visualizao das reservas que esto pendentes para Secretria e Bolsista. As reservas que contm a opo de conrmao para o Bolsista so as que necessitam de instalao de software. Na funcionalidade de pesquisar os requerentes possvel visualizar se os requerentes esto ativos ou inativos no sistema. Essa tela pode ser visualizada na gura 7.12. Esta funcionalidade apresentada para os pers de Secretria e Bolsista. A partir, do momento da ativao do requerente, este poder fazer uso de suas funcionalidades no sistema. Entre essas funcionalidades esto a solicitao de reserva de sala e solicitao de software, que pode ser visualizada na gura 7.13. Existem outras funcionalidades que no foram detalhadas, mas as aes para acessar essas funcionalidades na maioria j se encontram nestas telas. Portanto, essas telas conseguem passar uma noo da implementao feita do sistema e um manual de navegao para usurio.

71

Figura 7.10: Tela de pesquisar software.

72

Figura 7.11: Tela de pesquisar reservas de sala.

Figura 7.12: Tela de pesquisar requerente. 73

Figura 7.13: Tela de visualizar sala.

74

Captulo 8 Concluso
Este trabalho apresentou um estudo sobre a Engenharia de Software baseada em componentes. Foi realizado um estudo terico dos conceitos desta rea e detalhado um processo de desenvolvimento baseado em componentes. Neste sentido, tentou-se obter experincia na adoo de processos dessa rea, visando a produo de componentes com caractersticas como: encapsulamento, conabilidade, portabilidade, desempenho e, principalmente, capacidade de reuso. Ao identicar funcionalidades genricas, torna-se possvel criar componentes reutilizveis em outros softwares. Assim sendo, estes componentes necessitam de documentao e de estarem organizados em uma biblioteca para consulta por desenvolvedores. A interface do componente a forma de especicar os servios que sero providos pelo mesmo e nela deve ser documentada uma parte do componente. Aps vericar a consistncia do componente deve-se catalog-lo na biblioteca utilizada pelos desenvolvedores. Ento ser necessrio que a organizao treine seus funcionrios no processo de desenvolvimento baseado em componentes. Estes devero ser instrudos a utilizar a biblioteca construda para desenvolver as suas aplicaes. Esta tarefa trabalhosa porque na maioria das vezes existe um receio a adoo de uma nova tecnologia, principalmente quando determinada soluo j se encontra implementada e o desenvolvedor acredita que o seu cdigo pode ser melhor que o cdigo disponibilizado. Alm disso, existe uma diculdade em especicar os requisitos de um sistema que adotar o processo de desenvolvimento baseado em componentes. Aps os analistas especicarem os requisitos com os clientes, necessrio encontrar as partes que sero independentes, uma das outras, e podero ser encapsuladas em componentes. As vantagens desse processo podem ser vistas aps a implementao dos componentes, pois, com a biblioteca de componentes, o desenvolvimento de novos sistemas ser a adaptao desses s regras especcas do sistema a ser desenvolvido. Neste sentido, consegue-se elevar os nveis de produtividade e ecincia da equipe de desenvolvimento. Entre os processos de desenvolvimento baseado em componentes escolheu-se o processo descrito no livro UML Components. A escolha do processo descrito por Cheesman e Daniels foi feita devido a fase de especicao dos componentes. Nesse

75

livro so atendidas as necessidades propostas para criao de componentes, alm de descrever outras fases do desenvolvimento do software. Neste aspecto o processo divide a fase de especicao em trs etapas: identicao de componentes, iterao entre os componentes e a especicao dos componentes. O processo deixa em aberto como sero realizadas as fases de implementao e composio dos componentes, pois, segundo ele, tendo a especicao clara do componente, as prximas fases devem se preocupar com a escolha da tecnologia para conceber os componentes e com estes construdos necessita-se vericar se estes atendem a especicao descrita. Aps aplicar o processo no desenvolvimento de um estudo de caso, conclui-se que ele atinge os objetivos esperados. Apesar de apresentar de uma maneira imprecisa algumas atividades, como por exemplo: a diviso das interfaces dos componentes em interfaces de sistema e de negcio, faltam de detalhes nas fases de especicao de requisitos e como identicar os componentes nesta fase, a necessidade de explicaes ou experincias em implementar os componentes em determinadas tecnologias e em como montar o sistema com os componentes. Este processo conseguiu estabelecer atividades para especicar os componentes e com o estudo de caso obteve-se a experincia em aspectos tcnicos referentes s diculdades de se trabalhar com EJB e com o framework JBossSeam. Uma experincia obtida envolve a necessidade de especicar interfaces de persistncia, aspecto no abordado pelo processo, pois este envolve apenas os componentes de negcio. Essa atividade envolveu a reestruturao do cdigo e dos modelos. O resultado da aplicao do processo adotado foi positivo, pois aps sua execuo obteve-se os componentes de negcio especcos para montagem do sistema de alocao de salas para laboratrio de informtica. Estes podem ser usados em sistemas para alocao de salas de diferentes laboratrios, sendo adaptveis futuras regras de negcio. As principais mudanas a serem feitas para melhorar o processo adotado so: Incluso de atividades para identicao dos requisitos que levaro especicao de um componente; Melhorar a atividade de separao das interfaces em: ncleo e complementares; Extenso do processo para que as interfaces de comunicao com o banco de dados tambm sejam especicadas; Descrio de padres para a codicao dos componentes e procedimentos para utilizao do EJB. Este trabalho atendeu os objetivos esperados e foi graticante para o conhecimento no processo de desenvolvimento baseado em componentes, conseguindo-se construir os componentes e entender as funcionalidades providas por eles. Sendo assim, os componentes que foram produzidos tm suas implementaes encapsuladas e possuem interfaces concisas para uso, atendendo s caractersticas denidas para um componente.

76

Referncias
[1] SOMMERVILLE, I. Engenharia de software. 8. ed. Pearson, 2006. 1, 3, 5, 13, 14, 16, 18 [2] GOULO, M. C. Engenharia de software baseado em componentes: uma abordagem quantitativa. Dezembro 2003. Tese (Doutorado em Fsica) - Universidade Nova de Lisboa, Dezembro 2003. 1, 14 [3] DANTAS, C.; OLIVEIRA, H.; LOPES, L. G.; WERNER, C.; MURTA, L. A caminho da manuteno de software baseado em componentes via tcnica de gerencia de congurao de software. Revista Tecnologia da Informao, Rio de Janeiro, p. p. 4562, 2005. 2 [4] DE PAULA BIACHINI, C.; do Prado, A. F.; TREVELIN, L. C.; de Almeida, E. S. Um padro de desenvolvimento de software baseado em componentes distribudos. In Second Latin American Conference on Pattern Languages of Programming, Itaipava, Brasil, p. p 175190, 2002. 2 [5] MCILROY, M. D. Nato software engineering conference report. Garmisch, c1968. p. 7985. 3 In: .

[6] FRANK, D.; HANS, K. Programming-in-the large versus programming-inthe-small. In: . New York, NY, USA: ACM, c1975. p. 114121. 3 [7] SZYPERSKI, C. Component software: Beyond object-oriented programming. 2. ed. Addison-Wesley, 2002. 3, 4 [8] BOOCH, G. Software components with ada structures, tools, and subsystems. 2. ed. Benjamin-Cummings Pub Co, 1987. 4 [9] HURWITZ, J.; BLOOR, R.; KAUFMAN, M.; HALPER, F. Service oriented architecture for dummies. 2. ed. John Wiley and Sons, 2009. 4 [10] E SILVA, R. P. Suporte ao desenvolvimento e uso de frameworks e componentes. 2000. Dissertao (Mestrado em Fsica) - Institudo de Informtica da Universidade Federal do Rio Grande do Sul, 2000. Trabalho orientado pelo professor Roberto Tom Price. 4 [11] LARSEN, G. Component-based enterprise frameworks. ACM, New York, NY, USA, v. 43, n. 10, p. 2426, 2000. 4

77

[12] PRESSMAN, R. Software engineering: A practitioners approach 6th international edition. 6. ed. McGraw Hill Higher Education, 2004. 6, 15 [13] DSOUZA, D. F.; WILLS, A. C. Objects, components and frameworks with uml: The catalysis approach. 1. ed. Addison Wesley, 1998. 6, 8 [14] CRNKOVIC, I.; CHAUDRON, M.; LARSSON, S. Component-based development process and component lifecycle. Software Engineering Advances, International Conference on, Los Alamitos, CA, USA, v. 0, p. 44, 2006. 8, 20 [15] CHEESMAN, J.; DANIELS, J. Uml components: A simple process for specifying component-based software. 1. ed. Addison-Wesley, 2000. 8, 20, 23, 24, 26, 29, 30, 31, 32, 33, 34, 57 [16] ATKINSON, C.; BAYER, J.; BUNSE, C.; KAMSTIES, E.; LAITENBERGER, O.; LAQUA, R.; MUTHIG, D.; PAECH, B.; WUST, J.; ZETTEL, J. Componentbased product line engineering with uml. 1. ed. Addison-Wesley, 2001. 8 [17] NATIS, Y. V. Service-oriented architecture scenario. Disponvel no site: http://www.gartner.com para documentao SOA., Abril 2003. 9 [18] SIMO, R. P. S.; BELCHIOR, A. D. Um padro de qualidade para componentes de software. In: . Gramado, Rio Grande do Sul, Brasil: , c2002. 9 [19] ALUR, D.; CRUPI, J.; MALKS, D. Core j2ee patterns: Best practices and design strategies. Sun Microsystems Press. 9, 10, 11 [20] MYERS, G. The art of software testing. 1. ed. John Wiley and Sons, 1979. 11, 15 [21] ALVES, A.; DE LUCCA, J. E.; CARNEIRO, A. M.; FERREIRA, C.; VEIGA, R.; MINODA, R.; TACCA, T.; RESENDE, A.; B., A. S. Perspectivas de desenvolvimento e uso de componentes na indstria brasileira de software e servios. Parceria entre Associao para Promoo da Excelncia do Software Brasileiro - SOFTEX,Ministrio da Cincia e Tecnologia - MCT, Departamento de Poltica Cientca e Tecnolgica - DPCT/Unicamp, 2007. 13 [22] ROYCE, W. W. Managing the development of large software systems: concepts and techniques. In: . IEEE Computer Society Press, c1987. p. 328338. 16 [23] WELLS, D. Extreme programming: A gentle introduction. Extreme Programming, Maio 2009. Disponvel em http://www.extremeprogramming.org. 17 [24] HEINEMAN, G.; COUNCILL, W. Component-based software engineering: Putting the pieces together. 1. ed. Addison-Wesley, 2001. 17 [25] MEIRA, S. L.; de Almeida, E. S. Porque componentizao e reuso no funcionaram at agora! In: . So Carlos, So Paulo, Brasil: , c2003. 19

78

[26] DOS SANTOS, L. L. Desenvolvimento baseado em componentes. 2004. Dissertao (Mestrado em Fsica) - Ncleo de Computao Eletronica da UFRJ, 2004. Trabalho orientado pelo professor Paulo Pires. 19 [27] CATALYSIS. Catalysis entreprise components with uml, Junho 2009. Disponvel em http://www.cataylsis.org. 20, 22, 34 [28] OBJECT MANAGEMENT GROUP. The unied modeling language - uml omg, Outubro 2009. Disponvel em http://www.uml.org/. 22, 26, 27, 30, 31 [29] KRUCHTEN, P. Rational unied process made easy, the: A practitioners guide to the rup. Addison-Wesley Professional, 2009. 27 [30] MICROSOFT WINDOWS. Microsoft com (component object model), Julho 2009. Disponvel em http://www.microsoft.com/com/default.mspx. 34, 37 [31] PANDA, D.; RAHMAN, R.; LANE, D. Ejb 3 in action. 1. ed. Manning Publications, 2007. 34

79