Um metodo para modelagem de exceções em desenvolvimento baseado em componentes

(1)

Um M´etodo Para Modelagem de Exce¸c˜oes Em Desenvolvimento Baseado em Componentes

Patrick Henrique da Silva Brito Disserta¸c˜ao de Mestrado

(2)

Um M´

etodo Para Modelagem de Exce¸c˜

oes Em

Desenvolvimento Baseado em Componentes

Patrick Henrique da Silva Brito

Outubro de 2005

Banca Examinadora:

• Profa. Dra. Cec´ılia Mary Fischer Rubira (Orientadora) • Prof. Dr. Paulo Cesar Masiero

ICMC – USP S˜ao Carlos • Profa. Dra. Eliane Martins

IC – UNICAMP

• Profa. Dra. Ariadne Maria Brito Rizzoni Carvalho (Suplente) IC – UNICAMP

(3)

(4)

Este exemplar corresponde à reda¸cão final da Disserta¸cão devidamente corrigida e defendida por Patrick Henrique da Silva Brito e aprovada pela Banca Examinadora.

Campinas, 14 de Outubro de 2005.

Profa. Dra. Cec´ılia Mary Fischer Rubira (Orientadora)

Disserta¸cão apresentada ao Instituto de Com-puta¸cão, unicamp, como requisito parcial para a obten¸cão do t´ıtulo de Mestre em Ciência da Computa¸cão.

(5)

c

(6)

Devido à grande populariza¸cão do Desenvolvimento Baseado em Componentes (DBC), ele vem sendo empregado inclusive no desenvolvimento de sistemas computacionais cr´ıticos. O emprego do DBC na constru¸cão de sistemas confiáveis evidencia a necessidade de se desenvolver componentes de software que sejam robustos e que possuam uma garantia maior do seu funcionamento correto.

Tratamento de exce¸cões é uma técnica bastante conhecida para a verifica¸cão e tra-tamento de erros em sistemas de software. Porém, apesar da sua popularidade, o seu projeto e a implementa¸cão são constitu´ıdos de tarefas muito complexas que não recebem uma aten¸cão adequada dos processos de desenvolvimento existentes. A situa¸cão é ainda mais cr´ıtica se levarmos em considera¸cão os métodos para DBC.

Este trabalho propõe um método para auxiliar a modelagem do comportamento excep-cional de sistemas baseados em componentes, chamado MDCE+. Baseado no refinamento da metodologia MDCE, o MDCE+ apresenta dois diferenciais importantes, que refor¸cam o seu aspecto robusto: (i) o fato dele combinar as abordagens top-down e botton-up para o desenvolvimento de sistemas confiáveis; e (ii) o fato dele ser centrado na arquitetura. O foco na arquitetura de software contribui para uma melhor defini¸cão e análise do fluxo de exce¸cões entre os componentes do sistema. Essa maneira estruturada de detectar e tratar exce¸cões no contexto da ocorrência de falhas é particularmente relevante para sistemas que apresentam requisitos de confiabilidade extrema.

O método MDCE+ é um método genérico que pode ser aplicada a processos de desen-volvimento modernos. Em particular, nesta disserta¸cão o método MDCE+ foi adaptado ao processo UML Components e a uma metodologia de testes. Como maneira de ava-liar esse método, foi desenvolvido um estudo de caso de um sistema financeiro real, com requisitos de tolerância a falhas. Dada a sua importância, o processo de avalia¸cão do método MDCE+ foi dividido em três etapas: (i) prepara¸cão; (ii) execu¸cão; e (iii) análise dos resultados. Nesse estudo foi necessário tratar exce¸cões na arquitetura do sistema, com o intuito de aumentar a disponibilidade dos servi¸cos.

(7)

Abstract

Due to the large adoption of the Component-Based Development (CBD), it has also been employed in the development of critical software systems. The development of depen-dable systems using the CBD paradigm evidences the necessity of developing software components that are robust and dependable.

Exception handling is a well known technique for verify and treat errors in software systems. However, despite its popularity, its design and implementation are constitu-ted of very complex tasks that do not receive the adequate attention from the existing development processes. This is still more critical in the context of CBD processes.

This work presents the MDCE+, a method that assists the modeling of the excepti-onal behavior in component-based software development. Based in the refinement of the MDCE methodology, the MDCE+ presents two important differentials, that strengthen its robustness: (i) it combines the top-down and bottom-up strategies for the development of dependable systems; and (ii) it is centered in the software architecture. As a conse-quence of the focus given to the software architecture, the exceptions that flow between the system components are better defined and analyzed. This structured way to detect and to treat exceptions in the context of the occurrence of imperfections is particularly needed for developing dependable systems.

The MDCE+ is a generic method that can be applied together with modern develop-ment processes. In particular, in this master thesis MDCE+ was adapted to the UML Components process and to a software test methodology. In order to evaluate this method, a case study of a real financial system with fault-tolerance requirements was developed. Given its importance, the evaluation process of the MDCE+ method was decomposed in three stages: (i) preparation; (ii) execution; and (iii) results analysis. In order to increase the services availability, in this study it was necessary to deal with exceptions in the software architecture.

(8)

Primeiramente, gostaria de agradecer a Deus, por todas as oportunidades, maravilhas e experiˆencias que Ele me proporcionou durante a minha vida e por ter me sustentado nessa ´ardua jornada. Devo a Ele cada um dos meus passos.

Aos meus Pais (Maria Lucia da Silva Brito e Neusvaldo Henrique de Brito), por todo amor, dedica¸c˜ao, incentivo e exemplo que serviram como motiva¸c˜ao fundamental para prosseguir caminhando e superar as dificuldades.

Aos meus irmãos (Papy, Boy e Piu), pela nossa cumplicidade e admira¸cão mútua, que aumenta cada vez mais a minha vontade de melhorar e assim me assemelhar a eles.

`

A Margareth (Nem), minha namorada, a quem amo e admiro e que será sempre a minha inspira¸cão. Obrigado por ter aceitado com tanta compreensão os sacrif´ıcios da distância e da saudade. Espero sempre retribuir tudo isso com muita dedica¸cão e amor.

`

A minha fam´ılia que a Nem me presenteou: D. Margareth, Sr. Pedro, Peu, Pedrinho, Iann (meu afilhado), Ilanne, Tiaguinho, Urˆania, Maelson, D. Ester e Vozinha. Muito obrigado pelo apoio, confian¸ca, torcida, e pelo carinho e admira¸c˜ao rec´ıprocos.

A todos os meus familiares: avós, tios, primos, padrinhos e cunhados (Gesse, Diran, Dinho, Peu e Pedrinho), em especial ao meu primo Marcos Henrique. Não sei se ele sabe, mas devo a ele a minha voca¸cão pela ciência da computa¸cão.

Em memória dos meus familiares que descansaram eternamente no decorrer do meu mestrado: Vó Júlia, D. Ester, Vovô Zé Henrique, Fabinho e Flávio (primos).

Em mem´oria ao tio Zezinho, a quem devo a alegria de torcer pelo glorioso ASA de Arapiraca :-)

Um agradecimento mais que especial à Cec´ılia Rubira, minha orientadora, pelos ensi-namentos, companheirismo e verdadeira amizade. Obrigado pelas conversas, dicas, pro-jetos, corre¸cões de textos, exigências por prazos :-), ... tudo isso foram tijolos impor-tant´ıssimos na constru¸cão do nosso objetivo. Com essa convivência tão saudável, me ensina a amadurecer cada vez mais.

A todos os meus professores de gradua¸cão, em especial ao Coradine, meu orientador de inicia¸cão cient´ıfica. O exemplo e o incentivo de vocês nortearam a minha decisão em continuar estudando e pesquisando. Muito obrigado!

(9)

Aos meus amigos da terra dos marechais (Alagoas): David, Medeiros, José Ricardo, Rosemeire, Túlio, Moacy, Katiane, André Atanasio, H´ıtalo, Fernando Rezende, Gilberto, Carlos Alberto... . As minhas sinceras desculpas pela minha ausência total. Espero que ainda lembrem de mim :-)

Aos meus amigos que conheci na Unicamp, que são os principais frutos do meu mes-trado, em especial à galera do grupo de pesquisa em engenharia de software (SED), do laboratório de sistemas distribu´ıdos (LSD) e ao Augusto, um dos meus revisores oficiais de inglês :-) Gra¸cas a vocês, a jornada se tornou ainda mais gratificante e prazerosa. Muito obrigado mesmo!

Aos companheiros de república e convivência: Eduardo, Felipe, Javier, Márcio, Mar-cos, além de Clayton e Matias (vizinhos). Por toda amizade, descontra¸cão, e como não podia esquecer, horários pol´ıticos e novelas assistidas e comentadas ao vivo :-)

Gostaria de agradecer especialmente a cada um dos professores do curso de espe-cializa¸cão em Engenharia de Software, onde fui monitor: Ariadne, Arnaldo, Buzatto, Cec´ılia, Célio, Eliane, Hans, Mário Cortes, Thelma e Vanini. Foram dois anos e meio de um conv´ıvio sensacional, com muito conhecimento e experiência adquiridos. Eu não poderia deixar de agradecer de maneira especial às secretárias do curso: Cláudia Regina e Ol´ıvia. Obrigado pelas conversas amigas e por toda ajuda dentro e fora do curso. Também gostaria de agradecer ao curso em si, na pessoa da coordenadora, a profa. Thelma Chi-ossi. Obrigado pelo aux´ılio material fundamental para a melhor condu¸cão da pesquisa. Obrigado também ao IC, ao FINEP e ao projeto CompGov, pelos aux´ılios em viagens.

Não tem como deixar de agradecer aos professores e funcionários do IC que me acom-panharam mais de perto: professores Eliane Martins, Ariadne, João Meidanis, Ricardo Anido, Paulo Centoducatte, Edmundo Madeira e Cláudia Bauzer; Flávio (secretaria), Nelson (portaria), Flávio (portaria), Mirian (patrimônio), e Eliane (financeiro). Muito obrigado a todos!

Para fechar com chave de ouro, agrade¸co também aos professores da banca e a to-dos que colaboraram diretamente com o trabalho, tanto durante a condu¸cão da pesquisa, quanto com a melhoria da qualidade do texto escrito. Ao pessoal da Autbank, em espe-cial ao Paulo Kato, Tomohiro, Michele e Denise. Aos professores Cec´ılia Rubira, Eliane Martins e Paulo Masiero. Aos meus companheiros de pesquisa e amigos: Camila Rocha (companheira inseparável de pesquisa e estudo de caso), Paulo Asterio, Fernando Castor Filho, Rodrigo Tomita, Tiago Moronte, Leonardo Tizzei, Maria Antônia, Regina, Bruno, Leonel Gayard, Ana Elisa, Jana´ına, Helder, Ivan, Eduardo Gon¸calves, Vin´ıcius, Moacir Caetano e Ricardo.

Finalmente, o meu muito obrigado a todos aqueles que trabalham nos bastidores, cujo nome eu desconhe¸co. Um obrigado especial´ıssimo a todos aqueles que esqueci injustamente de citar o nome aqui. Minhas sinceras desculpas e o meu agradecimento.

(10)

seu caminho um tra¸co da sua imagem.”

(Neusvaldo J´unior)

“Comece pelo necessário, fa¸ca o que for poss´ıvel, ao final você terá feito o imposs´ıvel.”

(S˜ao Francisco de Assis)

“Quem nunca errou nunca experimentou nada novo.”

(Albert Einstein)

“Sabemos o que somos, mas n˜ao o que podemos ser.”

(Willian Shakespeare)

“O mundo é um livro e quem fica sentado em casa lê somente uma página.” (Santo Agostinho)

(11)

Sum´

ario

Resumo vii Abstract ix Agradecimentos xi 1 Introdu¸cão 1 1.1 Objetivos . . . 3 1.2 A Solu¸cão Proposta . . . 4 1.2.1 Especifica¸cão de Requisitos . . . 6

1.2.2 Defini¸c˜ao dos Aspectos Gerenciais . . . 6

1.2.3 Projeto Arquitetural . . . 6

1.2.4 Especifica¸c˜ao do Sistema . . . 7

1.2.5 Provisionamento dos Componentes . . . 7

1.2.6 Montagem do Sistema . . . 8

1.3 Trabalhos Relacionados . . . 8

1.4 Organiza¸c˜ao deste Trabalho . . . 9

2 Fundamentos de DBC, Arquitetura de Software e Tolerˆancia a Falhas 11 2.1 Desenvolvimento Baseado em Componentes . . . 11

2.1.1 Processos de Desenvolvimento de Software . . . 13

2.1.2 Processos de Desenvolvimento Baseado em Componentes . . . 16

2.2 Arquitetura de Software . . . 17

2.2.1 Conceito e Terminologia . . . 17

2.2.2 Modelo COSMOS . . . 18

2.2.3 O M´etodo de Avalia¸c˜ao de Arquitetura ATAM . . . 21

2.3 Tolerˆancia a Falhas e Tratamento de Exce¸c˜oes . . . 23

2.3.1 Falha, Erro e Defeito . . . 23

2.3.2 Dimens˜oes da confiabilidade de sistemas de software . . . 24

2.3.3 Fases da Tolerˆancia a Falhas . . . 26 xv

(12)

2.3.7 Componente Tolerante a Falhas Ideal . . . 31

2.3.8 O M´etodo MDCE . . . 32

2.4 Uma Estrutura¸c˜ao do Comportamento Excepcional para DBC . . . 34

2.4.1 Hierarquia de Exce¸c˜oes . . . 34

2.4.2 Abordagem Intra-Componente . . . 36

2.4.3 Abordagem Inter-Componentes . . . 38

2.5 Uma Arquitetura Confi´avel Baseada em Tratamento de Exce¸c˜oes . . . 40

2.5.1 Componente Exception . . . 42 2.5.2 Componente Handler . . . 42 2.5.3 Componente ExceptionHandlingStrategy . . . 43 2.5.4 Componente ConcurrentExceptionHandlingAction . . . 44 2.6 Resumo . . . 45 3 O Método MDCE+ 47 3.1 Visão Geral do Método . . . 47

3.2 Fase 1: Especifica¸c˜ao e An´alise dos Requisitos . . . 53

3.2.1 Compreender o Problema Atrav´es de Descri¸c˜oes . . . 54

3.2.2 Analisar e Representar o Dom´ınio do Problema . . . 54

3.2.3 Definir o Escopo do Sistema . . . 55

3.2.4 Especificar os Requisitos Funcionais . . . 56

3.2.5 Especificar o Comportamento Excepcional . . . 57

3.2.6 Construir/Atualizar o Diagrama de Casos de Uso . . . 62

3.3 Fase 2: Defini¸c˜ao dos Aspectos Gerenciais . . . 62

3.3.1 Definir as Restri¸c˜oes para o Desenvolvimento . . . 63

3.3.2 Identificar as Funcionalidades Cr´ıticas . . . 64

3.3.3 Definir as Releases para Itera¸c˜oes . . . 65

3.4 Fase 3: Projeto Arquitetural . . . 67

3.4.1 M´etodo para a Especifica¸c˜ao da Arquitetura do Sistema . . . 68

3.5 Fase 4: An´alise do Sistema . . . 71

3.5.1 Especificar as Interfaces da Aplica¸c˜ao . . . 73

3.5.2 Processar as Exce¸c˜oes Agendadas . . . 73

3.5.3 Identificar as Interfaces de infra-estrutura . . . 75

3.5.4 Criar os Componentes e Posicion´a-los na Arquitetura . . . 75

3.6 Fase 5: Projeto do Sistema . . . 77

3.6.1 Analisar a Intera¸c˜ao entre os Componentes . . . 77 xvi

(13)

3.6.2 Formaliza¸c˜ao da Especifica¸c˜ao dos Componentes . . . 92

3.7 Fase 6: Materializa¸c˜ao dos Componentes . . . 93

3.7.1 Atividades Comuns (reutiliza¸c˜ao ou implementa¸c˜ao) . . . 93

3.7.2 Escolher a Forma de Materializa¸c˜ao . . . 96

3.7.3 Reutilizar Componentes . . . 98

3.7.4 Implementar Componentes Novos . . . 99

3.8 Fase 7: Integra¸c˜ao dos Componentes do Sistema . . . 101

3.8.1 Montar os Componentes Arquiteturais . . . 101

3.8.2 Materializar a Configura¸c˜ao do Sistema . . . 103

3.9 Materializa¸c˜ao da Arquitetura Confi´avel Adotada . . . 105

3.9.1 Componente Exception . . . 106

3.9.2 Componente Handler . . . 107

3.9.3 Componente ExceptionHandlingStrategy . . . 107

3.9.4 Componente ConcurrentExceptionHandlingAction . . . 108

3.10 Resumo . . . 108

4 M´etodo MDCE+ Aplicado ao Processo UML Components 111 4.1 O Processo UML Components . . . 112

4.1.1 Especifica¸c˜ao de Requisitos . . . 113

4.1.2 Especifica¸c˜ao dos Componentes . . . 114

4.1.3 Provisionamento dos componentes . . . 115

4.1.4 Montagem do sistema . . . 116

4.1.5 Testes . . . 116

4.1.6 Implanta¸c˜ao . . . 117

4.2 O Processo Adaptado . . . 117

4.3 Fase 1: Especifica¸c˜ao e An´alise dos Requisitos . . . 120

4.4 Fase 2: Defini¸c˜ao dos Aspectos Gerenciais . . . 122

4.5 Fase 3: Projeto Arquitetural . . . 123

4.6 Fase 4: Identifica¸c˜ao dos Componentes . . . 124

4.7 Fase 5: Intera¸c˜ao Entre os Componentes . . . 125

4.8 Fase 6: Especifica¸c˜ao Final do Sistema . . . 129

4.9 Fase 7: Provisionamento dos Componentes . . . 129

4.10 Fase 8: Montagem do Sistema . . . 131

4.11 Resumo . . . 134

5 Estudo de Caso: Sistema de Controle Banc´ario 135 5.1 Descri¸c˜ao do Problema . . . 135

5.2 Descri¸c˜ao do Estudo de Caso . . . 136

5.3 Prepara¸c˜ao do Estudo de Caso . . . 138 xvii

(14)

5.4.1 Especifica¸c˜ao de Requisitos . . . 140

5.4.2 Defini¸c˜ao dos Aspectos Gerenciais . . . 142

5.4.3 Projeto Arquitetural . . . 144

5.4.4 Identifica¸c˜ao dos Componentes . . . 145

5.4.5 Intera¸c˜ao entre os Componentes . . . 148

5.4.6 Especifica¸c˜ao Final dos Componentes . . . 153

5.4.7 Provisionamento dos Componentes . . . 153

5.4.8 Montagem do Sistema . . . 156

5.5 An´alise dos Resultados . . . 159

5.5.1 Avalia¸c˜ao do Produto . . . 160

5.5.2 Avalia¸c˜ao do Processo Adaptado . . . 162

5.6 Resumo . . . 164

6 Conclus˜oes 167 6.1 Contribui¸c˜oes . . . 168

6.2 Trabalhos Futuros . . . 170

6.3 Publica¸c˜oes . . . 172

A Questionários de Avalia¸cão do Estudo de Caso 175 A.1 Questionário das Fases . . . 175

A.2 Question´ario Geral . . . 177

Bibliografia 179

(15)

Lista de Tabelas

2.1 Pontos de Vista de um Componente . . . 13

2.2 Principais entidades do modelo COSMOS . . . 21

2.3 Abordagens para a implementa¸c˜ao de sistemas confi´aveis . . . 25

2.4 Diretrizes para o Mapeamento entre Exce¸c˜oes de Componentes Distintos . 40 3.1 Especifica¸c˜ao Normal de um Caso de Uso . . . 57

3.2 Especifica¸c˜ao Excepcional de um Caso de Uso . . . 61

3.3 Principais Focos de Restri¸c˜oes . . . 64

3.4 Principais Restri¸c˜oes Ligadas ao Reuso de Componentes . . . 64

3.5 Custos das Formas de Materializa¸c˜ao . . . 97

4.1 Caso de Uso Normal: Efetuar Venda . . . 121

4.2 Cen´arios Excepcionais do Caso de Uso Efetuar Venda . . . 122

4.3 Caso de Uso Excepcional: Tratar Estoque Baixo . . . 122

4.4 Formaliza¸c˜ao das Assertivas do Caso de Uso Efetuar Venda . . . 129

5.1 Atividades para a Execu¸c˜ao do Estudo de Caso . . . 140

5.2 Especifica¸c˜ao do Caso de Uso Cancelar Contrato da Conta . . . 143

5.3 Um Cen´ario Excepcional do Caso de Uso Cancelar Contrato da Conta . . . 143

5.4 Itera¸c˜oes Definidas . . . 144

5.5 Especifica¸c˜ao do Caso de Uso Tratar Erro de Cancelamento de Contrato . . . 151

5.6 Classifica¸cão das Exce¸cões de Acordo com a Propaga¸cão . . . 153

5.7 An´alise das Fases da Especifica¸c˜ao (valores de 1 a 5) . . . 161

5.8 An´alise Geral do Processo Adaptado (valores de 1 a 5) . . . 161

5.9 Critérios de Avalia¸cão do Método MDCE+ . . . 163

(16)

1.1 Interferˆencia do M´etodo MDCE+ nas fases do UML Components . . . 5

2.1 Modelo de Especifica¸c˜ao do COSMOS . . . 19

2.2 Modelo de Implementa¸c˜ao do COSMOS . . . 20

2.3 Modelo de Conectores do COSMOS . . . 20

2.4 Ciclo entre a ocorrˆencia de Falhas, Erros e Defeitos . . . 23

2.5 Funcionamento de um Mecanismo de Tratamento de Exce¸c˜oes (MTE) . . . 28

2.6 Opera¸cão de Depósito em Cheque (Colabora¸cão) . . . 29

2.7 Grafo de Resolu¸cão da Colabora¸cão agência-agência . . . 30

2.8 Estrutura do Componente Tolerante a Falhas Ideal . . . 32

2.9 Hierarquia Excepcional Proposta . . . 35

2.10 Estrutura¸c˜ao Interna do Componente . . . 36

2.11 Estrutura¸c˜ao Interna do Componente com Reuso . . . 39

2.12 Estrutura¸c˜ao de um Tratador CLE . . . 39

2.13 Arquitetura de Componentes Gen´erica para Tratamento de Exce¸c˜oes . . . 41

2.14 Meta-modelo da Estrutura¸c˜ao de uma Colabora¸c˜ao . . . 44

3.1 Fases do M´etodo MDCE+ . . . 51

3.2 Fase de Especifica¸c˜ao de Requisitos . . . 54

3.3 Atividades da Especifica¸c˜ao dos Requisitos Funcionais . . . 56

3.4 Verifica¸c˜ao de Assertivas . . . 58

3.5 Agendamento de Exce¸c˜oes Candidatas . . . 59

3.6 Especifica¸c˜ao do Comportamento Excepcional . . . 62

3.7 Defini¸c˜ao das Releases do Sistema . . . 66

3.8 Especifica¸c˜ao da Arquitetura do Sistema . . . 69

3.9 Arvore de Precedˆencia dos Requisitos N˜ao-Funcionais . . . 70´

3.10 Árvore de Precedência de Requisitos Não-Funcionais com Cenários . . . 70

3.11 Workflow da Fase de An´alise . . . 72

3.12 Processamento das Exce¸c˜oes Agendadas . . . 74

3.13 Cria¸c˜ao dos Componentes (Normais e Excepcionais) . . . 76 xxi

(17)

3.14 Analisar a Intera¸c˜ao entre os Componentes . . . 78

3.15 Detalhamento dos Tratadores . . . 80

3.16 Workflow de Estrutura¸c˜ao dos Componentes Arquiteturais do Sistema . . . 82

3.17 Workflow da Verifica¸c˜ao de Tratamento ou Propaga¸c˜ao . . . 85

3.18 Workflow de Especifica¸c˜ao do Grafo de Resolu¸c˜ao . . . 88

3.19 Encapsulamento dos Participantes Atrav´es do Coordenador . . . 90

3.20 Uma Arquitetura em Quatro Camadas . . . 92

3.21 Exemplo do Componente A . . . 92

3.22 Atividades Comuns (reutiliza¸c˜ao e implementa¸c˜ao) . . . 94

3.23 Novo Modelo de Implementa¸c˜ao do COSMOS . . . 95

3.24 Modelagem de Classes de Exce¸c˜oes Simples e Compostas . . . 96

3.25 Ilustra¸c˜ao do Papel do Wrapper . . . 98

3.26 Implementa¸c˜ao de um Componente no COSMOS . . . 100

3.27 Estrutura do Componente Ideal Projetado . . . 102

3.28 Implementa¸c˜ao do Conector Interno ALE . . . 102

3.29 Exemplo em Java da Liga¸c˜ao entre dois Componentes . . . 103

3.30 Simula¸c˜ao de uma Reconfigura¸c˜ao Permanente do Sistema . . . 105

3.31 Simula¸cão de uma Reconfigura¸cão Temporária do Sistema . . . 106

4.1 Arquitetura Adotada pelo UML Components [CD00] . . . 112

4.2 Fases do UML Components [CD00] . . . 113

4.3 Especifica¸c˜ao dos Componentes no UML Components [CD00] . . . 114

4.4 Fases do Processo Adaptado . . . 118

4.5 Modelo Conceitual de Neg´ocio de um Sistema de Vendas [CD00] . . . 121

4.6 Interfaces Identificadas e Componentes Criados . . . 125

4.7 Colabora¸c˜ao da opera¸c˜ao Efetuar Venda . . . 126

4.8 Colabora¸c˜ao da opera¸c˜ao Tratar Estoque Baixo . . . 126

4.9 Atualiza¸c˜ao das Interfaces (Neg´ocio e Sistema) . . . 127

4.10 Estrutura¸c˜ao do Componente Arquitetural Efetuar Venda . . . 127

4.11 Arquitetura Refinada do Sistema . . . 128

4.12 Novas Entidades Cr´ıticas Identificadas . . . 128

4.13 Interfaces Requeridas do Componente operacoesVendasArq . . . 129

4.14 Modelagem do Componente gerenciamentoVendas . . . 130

4.15 Modelagem do Componente operacoesVendas . . . 131

4.16 Materializa¸c˜ao do Componente Arquitetural operacoesVendas . . . 132

4.17 Simula¸c˜ao de Uma Reconfigura¸c˜ao Permanente do Sistema . . . 133

4.18 Arquitetura do Sistema Materializada com Conectores . . . 133

5.1 Etapas do Estudo de Caso . . . 138 xxii

(18)

5.5 Modelo de Tipos de Neg´ocio . . . 145

5.6 Interfaces Identificadas . . . 146

5.7 Exce¸c˜oes Identificadas . . . 146

5.8 Componentes Identificados . . . 147

5.9 Intera¸c˜ao da Opera¸c˜ao cancelarContrato() . . . 148

5.10 Intera¸cão da Opera¸cão cancelarContrato() com Deteçcão de Exce¸cões . . . . 149

5.11 Interfaces Refinadas com a Colabora¸c˜ao . . . 150

5.12 Tipos de Dados Necess´arios . . . 151

5.13 Componente Arquitetural operacoesContaArq . . . 152

5.14 Interfaces Requeridas do Componente operacoesContaArq . . . 152

5.15 Modelo de Informa¸c˜ao da Interface ICancelamentoContratoMgt . . . 154

5.16 Estrutura¸c˜ao Interna do Componente gerenciamentoContas . . . 155

5.17 Estrutura¸c˜ao Interna do Componente operacoesConta . . . 155

5.18 Comportamento do Tratador de TETransacaoNaoFoiConcluidaException 157 5.19 Estrutura¸c˜ao do Componente Arquitetural operacoesContaArq . . . 157

5.20 Parte da Arquitetura do Sistema . . . 158

5.21 Simula¸c˜ao da Reconfigura¸c˜ao do Servi¸co cancelarContrato(...) . . . 158

5.22 Distribui¸c˜ao do Custo Total Durante as Fases do Desenvolvimento . . . 159

5.23 Distribui¸cão do Custo da Fase nos Estágios da Especifica¸cão . . . 159

(19)

Cap´ıtulo 1

Introdu¸c˜

ao

Sistemas de software são intrinsicamente complexos e esta complexidade é agravada ainda mais com os requisitos impostos pelas aplica¸cões modernas, como por exemplo, confia-bilidade, disponibilidade e seguran¸ca. Apesar das exigências em se produzir sistemas confiáveis, esse aumento da complexidade, aliado às restri¸cões de tempo de desenvol-vimento, comprometem o funcionamento correto do sistema, uma vez que induzem a inser¸cão de um maior número de falhas durante o seu desenvolvimento [AL90]. A fim de lidar com essa complexidade e de reduzir o tempo e o custo de desenvolvimento, a indústria de software vem adotando cada vez mais o desenvolvimento baseado em com-ponentes (DBC), que modulariza o sistema em comcom-ponentes e a partir dessas unidades básicas, outros sistemas são constru´ıdos recursivamente [Szy98].

Com a populariza¸cão do DBC, é inevitável a cria¸cão de sistemas baseados em compo-nentes para desempenhar atividades cr´ıticas, quer seja com requisitos de disponibilidade, como sistemas web1 _{e bancários; quer seja com requisitos de confiabilidade cr´ıtica, como}

sistemas médicos ou embarcados. Por esse motivo, é necessário se preocupar em produzir sistemas baseados em componentes que sejam robustos.

Apesar do avan¸co das pesquisas em ciência da computa¸cão, ainda não existem meios para garantir a ausência de falhas em sistemas de software [Som01]. Sendo assim, para a constru¸cão de sistemas confiáveis, devem ser utilizadas técnicas de tolerância a fa-lhas [AL90], que visam manter o sistema em funcionamento mesmo na ocorrência de falhas. Essas técnicas podem ser implementadas através de mecanismos de tratamento de exce¸cões [Fer01], os quais oferecem um arcabou¸co para a cria¸cão de tratadores adequados para cada tipo de exce¸cão, possibilitando o tratamento de poss´ıveis inconsistências, ou até mesmo a continua¸cão da execu¸cão das funcionalidades do sistema. Devido à popularidade dos mecanismos de tratamento de exce¸cões, as falhas que podem ser detectadas no sistema também são conhecidas como situa¸cões excepcionais, enquanto o comportamento

cor-1

do inglˆes World Wide Web

(20)

retivo mediante a ocorrência de situa¸cões excepcionais é chamado de comportamento excepcional. O comportamento que implementa a execu¸cão esperada do sistema é co-nhecido como comportamento normal.

A incorpora¸cão efetiva de deteçcão e tratamento de exce¸cões, visando a implanta¸cão de tolerância a falhas, aumenta consideravelmente a complexidade do sistema [Cri89], uma vez que o número de linhas de código adicionais necessário para a execu¸cão dessas ativi-dades pode representar mais de dois ter¸cos do total [Cri89]. Devido a essa complexidade extra, os desenvolvedores de software sentem dificuldade tanto para utilizar corretamente os mecanismos, quanto para reconhecer e tratar adequadamente as exce¸cões, o que gera sistemas com tratamento excepcional deficiente, com baixa manutenibilidade e baixa ca-pacidade de reutiliza¸cão.

Um fator agravante na qualidade do tratamento excepcional é o fato de um componente isolado não possuir os recursos necessários para detectar e tratar as exce¸cões de uma maneira efetiva [dLR99]. Sendo assim, é necessário considerar as colabora¸cões entre os componentes do sistema. Essa necessidade de se conhecer o fluxo interativo entre os componentes contribui para que a arquitetura de software assuma um papel fundamental para a melhoria da qualidade e da confiabilidade final dos programas. Isso se deve ao fato da arquitetura de software [SG96] explicitar as restri¸cões de comunica¸cão entre os componentes do sistema, uma vez que o representa de maneira abstrata, através dos seus componentes arquiteturais e das regras de intera¸cão entre eles.

Para se ter uma idéia dessa importância, com a manipula¸cão sistemática desses fluxos de informa¸cões, os tratadores excepcionais localizados na arquitetura, chamados aqui de tratadores arquiteturais [IB01], são capazes por exemplo, de isolar componentes fa-lhos do sistema em tempo de execu¸cão, desviando o fluxo de requisi¸cão para componentes redundantes. Outra vantagem de se conhecer a estrutura do sistema é a possibilidade de executar um tratamento excepcional de maneira coordenada, envolvendo diferentes com-ponentes (tratamento colaborativo coordenado [dLR99]). Além disso, o tratamento de exce¸cões no contexto da arquitetura de software possibilita o uso de componentes COTS2 _{na constru¸cão de sistemas confiáveis.}

Apesar da necessidade de lidar com o comportamento excepcional de maneira sis-temática, por falta de metodologias e ferramentas adequadas, os desenvolvedores cos-tumam adiar essa preocupa¸cão para a fase de projeto ou até mesmo para a fase de implementa¸cão, executando-a de maneira “ad hoc”, guiados apenas pela sua intui¸cão. Porém, a antecipa¸cão dessa preocupa¸cão para as fases iniciais do desenvolvimento acar-reta benef´ıcios consideráveis para o aumento da confiabilidade dos sistemas [RdLeFCF04]. Os principais benef´ıcios alcan¸cados são: (i) evita-se a perda de contexto, devido à identi-fica¸cão antecipada do erro; (ii) melhora-se o tratamento excepcional, tendo em vista o maior

2

(21)

1.1. Objetivos 3

número de informa¸cões contextuais dispon´ıveis; (iii) diminui-se o re-trabalho, uma vez que uma fase pode delimitar restri¸cões às fases seguintes; (iv) facilita-se o gerenciamento do desenvolvimento, tendo em vista que a garantia da confiabilidade é distribu´ıda ao longo do processo.

Este trabalho propõe um método para o projeto e implementa¸cão do comportamento excepcional no DBC, denominado MDCE+. Nossa solu¸cão é um refinamento de um método proposto anteriormente chamado Metodologia para Defini¸cão do Comportamento Excepcional (MDCE) [RdLeFCF04], que é uma extensão do processo de DBC Cataly-sis [DW99]. O método MDCE apresenta diretrizes para a especifica¸cão do comportamento excepcional de um sistema nas fases de identifica¸cão de requisitos, análise e projeto. O foco do nosso refinamento está principalmente nas fases de projeto arquitetural e imple-menta¸cão, atividades nas quais o MDCE é deficiente.

Além do refinamento, o MDCE+ foi adaptado ao processo de DBC UML Compo-nents [CD00]. A escolha desse processo se deve principalmente ao fato de possuir uma es-trutura¸cão simples, de fácil compreensão e utiliza¸cão prática; ao contrário do processo Ca-talysis, que é bem complexo. Essa caracter´ıstica torna o UML Components mais acess´ıvel ao mercado corporativo, principalmente quando comparado a outros processos de DBC, como o Catalysis.

1.1 Objetivos

O objetivo principal deste trabalho é a defini¸cão de um método para auxiliar a cons-tru¸cão de sistemas de software com requisitos de confiabilidade ligados à tolerância a falhas. Esse método é chamado de MDCE+. Isso deve ser feito através da utiliza¸cão sistemática dos mecanismos de tratamento de exce¸cões existentes nas principais lingua-gens de programa¸cão atuais. Esse método deve estruturar a identifica¸cão de exce¸cões e a especifica¸cão dos seus tratadores durante todas as fases de desenvolvimento do software. Outra caracter´ıstica importante do MDCE+ é a preocupa¸cão com a informa¸cão contex-tual dos fluxos interativos entre os componentes do sistema. Aproveitando esse enfoque na arquitetura, o método deve guiar o desenvolvedor na especifica¸cão de tratadores de exce¸cões localizados na arquitetura de software, a partir de uma análise sistemática das propaga¸cões excepcionais.

Além de sistematizar a modelagem das exce¸cões e do comportamento excepcional do sistema, o MDCE+ propõe diretrizes para a estrutura¸cão das hierarquias de tipos de exce¸cões. Essas diretrizes devem orientar também sobre a utiliza¸cão de pol´ıticas de logging, com o intuito de beneficiar as atividades de manuten¸cão do sistema.

(22)

de modelagem UML3_{[RJB99, BRJ99], uma vez que desde o seu lan¸camento em 1997, tem}

se mostrado um padr˜ao de fato na ind´ustria de desenvolvimento de software.

De forma complementar ao método MDCE+, é apresentada uma arquitetura para estruturar o comportamento excepcional para sistemas confiáveis. Baseado nessa ar-quitetura, o método compõe o sistema de maneira estruturada, a fim de, no final do desenvolvimento, se ter todos os componentes arquiteturais materializados.

Após a defini¸cão do método, ele é incorporado ao processo UML Components. Esse processo adaptado distribui as atividades relativas à modelagem excepcional do sistema em todas as suas fases. Sendo assim, o processo resultante dessa adapta¸cão sistema-tiza tanto a modelagem dos requisitos funcionais do sistema, quanto dos requisitos não-funcionais relativos a tolerância a falhas, através do uso disciplinado dos mecanismos de tratamento de exce¸cões.

Além de utilizar a linguagem UML como nota¸cão para os seus artefatos produzidos,as atividades do processo UML Components adaptado com tratamento de exce¸cões são repre-sentadas através de diagramas de atividades UML. Essa representa¸cão espec´ıfica deverá proporcionar uma melhor documenta¸cão de suas atividades e diretrizes, além de uma distin¸cão clara entre as atividades originais e as incorporadas ao processo adaptado. A principal vantagem decorrente dessa distin¸cão é o aumento da facilidade de adapta¸cão do método MDCE+ para outros processos de desenvolvimento de software.

Como um estudo da viabilidade do m´etodo MDCE+, foi feito um estudo de caso real baseado no desenvolvimento de um sistema financeiro com requisitos de confiabilidade4_.

O estudo de caso foi conduzido por terceiros e consistiu na aplica¸cão do processo UML Components adaptado com o método MDCE+ para a especifica¸cão e implementa¸cão do sistema citado. A especifica¸cão foi realizada desde a fase de engenharia de requisitos, passando pelo projeto arquitetural e especifica¸cão interna dos componentes, culminando na sua implementa¸cão e na montagem do sistema.

1.2 A Solu¸c˜

ao Proposta

O método MDCE+ sistematiza a especifica¸cão e a implementa¸cão do comportamento excepcional nas fases de desenvolvimento do software com ênfase no projeto da arquite-tura de componentes. Na especifica¸cão de requisitos, que é baseada no método MDCE (Se¸cão 2.3.8), é feita a antecipa¸cão das atividades excepcionais relacionadas ao dom´ınio do problema. Já nas fases de análise e projeto são especificadas as exce¸cões relacionadas às intera¸cões entre os componentes, enfatizando os aspectos arquiteturais do sistema.

3

do inglˆes Unified Modeling Language

4

(23)

1.2. A Solu¸c˜ao Proposta 5

Para facilitar o entendimento durante as atividades do desenvolvimento, o método MDCE+ apresenta uma distin¸cão entre os conceitos de componente arquitetural e componente de implementa¸cão. Os componentes arquiteturais do sistema são es-truturados segundo o modelo do componente tolerante a falhas ideal, apresentado na Se¸cão 2.3.7. Dessa forma, mesmo no n´ıvel arquitetural do sistema, se faz uma separa¸cão expl´ıcita entre os comportamentos normal e excepcional, não adiando apenas para a fase de implementa¸cão.

O comportamento de um componente tolerante a falhas ideal, ou simplesmente com-ponente ideal, é categorizado em dois tipos: normal, que produz respostas corretas, e excepcional (ou anormal), que é executado quando um erro é detectado.

Pelo fato da solu¸cão proposta ser centrada na arquitetura de software, é destacada a importância dos conectores [SG96], que materializam as intera¸cões entre os componentes arquiteturais. Por esse motivo, eles são os principais responsáveis pelo tratamento das exce¸cões no n´ıvel da arquitetura.

A incorpora¸cão do MDCE+ ao processo UML Components consistiu na distribui¸cão das atividades do método proposto nas fases do processo de DBC. O produto final dessa extensão é um processo iterativo que contém basicamente três novas atividades, ortogonais às etapas definidas pelo processo (Figura 1.1): (i) defini¸cão dos cenários excepcionais dos casos de uso e identifica¸cão de exce¸cões durante a análise dos requisitos; (ii) análise do fluxo excepcional e detalhamento dos tratadores durante a especifica¸cão dos componentes; e (iii) diretrizes para a estrutura¸cão excepcional, implementa¸cão dos componentes e montagem do sistema. Especificação/Análise de Requisitos Início Identificação dos Componentes Interação entre os Componentes Especificação final dos Componentes Provisionamento dos Componentes Montagem do Sistema Fim Definição dos cenários excepcionais dos casos de uso e Identificaçao de Exceções Separação de interesse entre os os componentes Normal e Excepcional Análise do Fluxo Excepcional e

Refinamento dos tratadores.

Formalização das Assertivas

Implementaçao dos Componentes e Criação de "wrappers" para os componentes reutilizados Implementação dos conectores [existem casos de uso a especificar] [senão]

(24)

As sub-se¸cões seguintes apresentam as fases do processo UML Components adaptado ao método MDCE+. Mais detalhes dessa adapta¸cão estão dispon´ıveis no Cap´ıtulo 4 desta disserta¸cão.

1.2.1 Especifica¸c˜

ao de Requisitos

Nesta fase, os requisitos do sistemas são mapeados através de casos de uso, cujas restri¸cões são especificadas através de assertivas, isto é, pré-, pós-condi¸cões, invariantes e outras restri¸cões de negócio. A partir da viola¸cão dessas assertivas, são identificadas exce¸cões, que são agendadas nesta fase, a fim de serem especificadas na fase de análise (Se¸cão 1.2.4). Além de especificar e analisar os requisitos, é elaborado o modelo conceitual do negócio, que representa as principais entidades do negócio e o relacionamento entre elas. Esse mo-delo é útil para promover a compreensão do dom´ınio que é necessária para a especifica¸cão do sistema. Após a elabora¸cão desse modelo, são identificadas as entidades cr´ıticas, isto é, as entidades consideradas essenciais para a execu¸cão das principais atividades do negócio. Nas fases seguintes da especifica¸cão, essas entidades serão o foco central para o tratamento de exce¸cões na arquitetura do sistema, através da utiliza¸cão de componentes redundan-tes [IB01, SDUV03].

1.2.2 Defini¸c˜

ao dos Aspectos Gerenciais

Após a defini¸cão dos requisitos desejados para o sistema, o processo MDCE+ apresenta uma fase para a defini¸cão de algumas questões gerenciais do desenvolvimento. As prin-cipais questões definidas são: (i) análise inicial dos riscos; e (ii) defini¸cão das itera¸cões do desenvolvimento. Durante a análise dos riscos são identificadas algumas restri¸cões poss´ıveis para o desenvolvimento. Essas restri¸cões podem interferir no projeto da arqui-tetura do sistema (Se¸cão 1.2.3) ou até mesmo nas decisões relacionadas à reutiliza¸cão de componentes (Se¸cão 1.2.5).

Com a defini¸cão de itera¸cões para o desenvolvimento, espera-se compensar o overhead esperado para o desenvolvimento de sistemas robustos. Essa compensa¸cão é decorrente da entrega5 _{gradativa do sistema, priorizando as funcionalidades de acordo com a necessidade}

do cliente.

1.2.3 Projeto Arquitetural

Na fase de projeto arquitetural ´e especificada a arquitetura adotada para o sistema. De-vido ao direcionamento dado pelo processo UML Components, a escolha da arquitetura

5

(25)

1.2. A Solu¸c˜ao Proposta 7

deve obedecer a restri¸cões. Recomenda-se a existência de duas camadas espec´ıficas: (i) camada de sistema, que trata de particularidades do sistema em questão; e (ii) camada de negócio, constitu´ıda por componentes que implementam as funcionalidades básicas e por isso são candidatos a serem reutilizados. Além das restri¸cões impostas pelo UML Components, a arquitetura final adotada deve obedecer às restri¸cões comuns ao ambiente de desenvolvimento utilizado, que são definidas pelo arquiteto.

1.2.4 Especifica¸c˜

ao do Sistema

Na fase de especifica¸cão são realizadas as atividades relativas à análise e projeto dos componentes do sistema. Essa fase é dividida em 3 sub-fases: (i) identifica¸cão dos com-ponentes, na qual os componentes são identificados a partir de suas interfaces providas; (ii) intera¸cão entre os componentes, na qual são identificadas as opera¸cões requeridas pelos componentes de sistema, a partir das intera¸cões entre os componentes das camadas de negócio e de sistema; e (iii) especifica¸cão final dos componentes, onde são formalizadas as especifica¸cões dos componentes.

1.2.5 Provisionamento dos Componentes

A fase de Provisionamento dos componentes tem como objetivo garantir a materializa¸cão dos componentes especificados. Isso pode ocorrer de três formas: (i) reutiliza¸cão de componentes já existentes; (ii) aquisi¸cão de componentes de prateleira; (iii) implementa¸cão de componentes novos.

Em rela¸cão à reutiliza¸cão de componentes, é necessário realizar um mapeamento entre as suas opera¸cões e as opera¸cões requeridas especificadas. Esse mapeamento é materi-alizado através de adaptadores [dCGFPR04], como mostrado na Se¸cão 2.4, cuja fun¸cão é mascarar a assinatura real das opera¸cões reutilizadas, a fim de tornar a reutiliza¸cão transparente para o componente cliente. Além disso, os adaptadores podem identificar a ocorrência de situa¸cões excepcionais e conseqüentemente executar o tratamento adequado. Já no caso dos componentes implementados, é necessário especificar as suas estruturas internas de acordo com algum modelo de componentes dispon´ıvel. O modelo de mate-rializa¸cão utilizado para os componentes foi o modelo COSMOS [JGR03], apresentado na Se¸cão 2.2.2, que utiliza estruturas dispon´ıveis em linguagens orientadas a objetos e explicita as abstra¸cões da arquitetura do sistema.

Quanto às exce¸cões, elas devem ser definidas como classes e organizadas de acordo com uma hierarquia predefinida, baseada na proposta apresentada na Se¸cão 2.4. O obje-tivo principal dessa hierarquia excepcional é relacionar de maneira consistente as exce¸cões internas e as exce¸cões que fluem entre diferentes componentes arquiteturais. Dessa forma,

(26)

o método MDCE+ oferece diretrizes para o mapeamento entre os tipos de exce¸cões apre-sentados na hierarquia e a classifica¸cão dada pelo modelo do componente ideal.

1.2.6 Montagem do Sistema

Por se tratar de um método centrado na arquitetura, a fase de montagem é dividida em duas etapas: (i) montagem dos componentes arquiteturais; e (ii) montagem do sistema em si. Na primeira etapa é feita a montagem dos componentes arquiteturais. Dessa forma, os componentes de implementa¸cão, que implementam os comportamentos relativos à implementa¸cão das funcionalidades e do tratamento de exce¸cões são estruturados de acordo com o modelo do componente tolerante a falhas ideal.

A segunda etapa da fase de montagem do sistema consiste na implementa¸cão dos co-nectores do sistema e na constru¸cão do programa principal, que instancia e “monta” os componentes arquiteturais do sistema em tempo de execu¸cão. Apesar dos conectores se-rem refinados nesta fase, eles são especificados gradativamente desde a fase de especifica¸cão dos componentes, mais especificamente na sub-fase de intera¸cão entre os componentes. A principal atividade excepcional desempenhada pelos conectores é a implementa¸cão dos tratadores de exce¸cões na arquitetura do sistema.

1.3 Trabalhos Relacionados

Utilizar um mecanismo de tratamento de exce¸cões é uma das formas mais importan-tes de deteçcão e recupera¸cão de erros e estrutura¸cão de atividades de tolerância a fa-lhas [AL90, Cri89, GRRX01]. Apesar da complexidade desses mecanismos motivar o uso de metodologias de desenvolvimento espec´ıficas, há poucos trabalhos nessa área [Avi97, dLR99, dLR00, Fer01]. O método MDCE, descrito na Se¸cão 2.3.8, orienta o desenvolvi-mento excepcional desde a especifica¸cão dos requisitos, passando pela análise e projeto do sistema. Porém, o MDCE não apresenta diretrizes para tratar as exce¸cões na arquitetura do software, o que impossibilita, entre outras coisas, a reutiliza¸cão de componentes COTS no desenvolvimento de sistemas confiáveis. Dessa forma, enquanto o MDCE busca espe-cificar sistemas confiáveis a partir do desenvolvimento de componentes tolerantes a falhas (abordagem botton-up), o método MDCE+ também possibilita a especifica¸cão das ativi-dades de tratamento de exce¸cões durante a liga¸cão entre os componentes, não exigindo que eles possuam esses mecanismos implementados internamente (abordagem combinada botton-up e top-down).

Tolerância a falhas na arquitetura de software é uma área que vem se destacando pela sua relevância [GRdL03, FdCGR03, SDUV03]. O método MECE [Pag04] propõe uma sistemática com enfoque arquitetural para a especifica¸cão do comportamento excepcional

(27)

1.4. Organiza¸c˜ao deste Trabalho 9

em sistemas baseados em componentes. Sua abordagem propõe o uso conjunto e seq¨ uen-cial da MDCE, descrita anteriormente, e do processo UML Components. Além disso, o MECE sugere um refinamento da arquitetura do sistema através da ado¸cão de conectores expl´ıcitos. Apesar dessa melhoria no caráter arquitetural do MDCE, o MECE não sis-tematiza a especifica¸cão dos tratadores arquiteturais [IB01]. Outra deficiência existente nesse método é o fato dela não lidar com o tratamento colaborativo de exce¸cões, isto é, situa¸cões onde um conjunto de componentes precisam agir de forma coordenada para a recupera¸cão do estado normal do sistema. Outro diferencial do método MDCE+ é a preo-cupa¸cão com aspectos gerenciais, tais como a defini¸cão de releases para o desenvolvimento incremental e a identifica¸cão e prioriza¸cão de componentes cr´ıticos do sistema.

CO-Actions [dLR99] é uma abstra¸cão de modelagem para representa¸cão de compor-tamento colaborativo nas diversas fases da especifica¸cão de um sistema. Apesar de ser voltado para sistemas orientados a objetos, seus conceitos podem ser mapeados dire-tamente para o DBC. Além do comportamento colaborativo, CO-Actions considera a necessidade de se especificar o comportamento excepcional desde as fases iniciais do de-senvolvimento do software, propondo uma classifica¸cão das exce¸cões entre: (i) exce¸cões relativas à aplica¸cão6_{; (ii) exce¸cões relativas ao projeto}7_{; e (iii) exce¸cões relativas ao suporte}

& implementa¸c˜ao8_{. Por´em, apesar de oferecer formas de modelar e estruturar melhor o}

comportamento excepcional, essa abordagem não é apoiada por um processo, isto é, ela não oferece diretrizes para a descoberta e modelagem das exce¸cões e dos seus tratadores.

1.4 Organiza¸c˜

ao deste Trabalho

Este documento foi dividido em seis cap´ıtulos e dois apˆendices, organizados da seguinte forma:

• Cap´ıtulo 2 – Fundamentos de DBC, Arquitetura de Software e Tolerˆancia

a Falhas: O segundo cap´ıtulo apresenta os fundamentos teóricos necessários para embasar este trabalho. Esses conceitos estão classificados em cinco categorias: (i) desenvolvimento baseado em componentes; (ii) arquitetura de software; (iii) tolerância a falhas e tratamento de exce¸cões; (iv) uma estrutura¸cão do comportamento excepcional para DBC; e (v) uma arquitetura confiável baseada em tratamento de exce¸cões.

• Cap´ıtulo 3 – O Método MDCE+: Neste cap´ıtulo é apresentado o método

para modelagem do comportamento excepcional MDCE+, que utiliza a arquitetura

6

do inglˆes Application-related

7

do inglˆes Design-related

8

(28)

proposta na Se¸cão 2.5 e apresenta diretrizes e atividades importantes a serem consi-deradas no desenvolvimento de sistemas confiáveis. São abordados tanto aspectos do desenvolvimento interno dos componentes quanto aspectos arquiteturais do sistema, distribu´ıdos em todas as fases propostas pelo método.

• Cap´ıtulo 4 – M´etodo MDCE+ Aplicado ao Processo UML Components:

Neste cap´ıtulo, o método MDCE+ apresentado no cap´ıtulo 3 foi aplicado ao pro-cesso de DBC UML Components. As fases de desenvolvimento espec´ıficas desse processo foram estendidas de forma a sistematizar a identifica¸cão das exce¸cões e a especifica¸cão do comportamento excepcional.

• Cap´ıtulo 5 – Estudo de Caso: Sistema de Controle Banc´ario Neste cap´ıtulo, o processo UML Components modificado, apresentado no Cap´ıtulo 4, foi aplicado num estudo de caso real de um sistema financeiro [dSBRMR05].

• Cap´ıtulo 6 – Conclusões: Neste cap´ıtulo são apresentadas as conclusões deste trabalho. Além disso, são apontadas as principais contribui¸cões e alguns direciona-mentos para trabalhos futuros.

• Apêndice A – Questionário de Avalia¸cão do Estudo de Caso: Neste apêndice são apresentados os questionários utilizados para a avalia¸cão do método MDCE+, descrito no Cap´ıtulo 5.

(29)

Cap´ıtulo 2

Fundamentos de DBC, Arquitetura

de Software e Tolerˆ

ancia a Falhas

Este cap´ıtulo apresenta os fundamentos teóricos necessários para embasar este trabalho. Esses conceitos estão agrupados em cinco se¸cões. As Se¸cões 2.1 e 2.2 tratam de aspectos necessários para o sucesso de um projeto baseado em componentes, tais como o próprio conceito de desenvolvimento baseado em componentes (DBC), arquitetura e processos de desenvolvimento de software. A Se¸cão 2.3 apresenta os princ´ıpios de confiabilidade, to-lerância a falhas e tratamento de exce¸cões. Essa se¸cão discute as terminologias utilizadas no decorrer do trabalho e como os mecanismos de tolerância a falhas podem ser imple-mentados em sistemas de software. A Se¸cão 2.4 apresenta uma maneira de estruturar o comportamento excepcional no DBC. Essa estrutura¸cão contempla tanto as exce¸cões internas aos componentes, quanto as exce¸cões que fluem entre diferentes componentes do sistema. A Se¸cão 2.5 mostra a arquitetura adotada pelo MDCE+ para a estrutura¸cão do comportamento excepcional do software.

2.1 Desenvolvimento Baseado em Componentes

A idéia de utilizar o conceito de DBC na produ¸cão de software data de 1976 [McI76]. Ape-sar desse tempo relativamente longo, o interesse pelo DBC só foi intensificado vinte anos depois, após a realiza¸cão do Primeiro Workshop Internacional em Programa¸cão Orientada a Componentes, o WCOP’96 [WCO].

Hoje em dia, a populariza¸cão do DBC está sendo motivada principalmente pelas pressões sofridas na indústria de software por prazos mais curtos e produtos de maior qualidade. No DBC, uma aplica¸cão é constru´ıda a partir da composi¸cão de componen-tes de software que já foram previamente especificados, constru´ıdos e componen-testados, o que proporciona um ganho de produtividade e qualidade no software produzido.

(30)

Esse aumento da produtividade é decorrente da reutiliza¸cão de componentes existentes na constru¸cão de novos sistemas. Já o aumento da qualidade é uma conseqüência do fato dos componentes utilizados já terem sido empregados e testados em outros contextos. Porém, vale a pena ressaltar que apesar desses testes prévios serem benéficos, a reutiliza¸cão de componentes não dispensa a execu¸cão dos testes no novo contexto onde o componente está sendo reutilizado.

Apesar da populariza¸cão atual do DBC, não existe um consenso geral sobre a defini¸cão de um componente de software, que é a unidade básica de desenvolvimento do DBC. Porém, um aspecto muito importante é sempre ressaltado na literatura: um componente deve encapsular dentro de si seu projeto e implementa¸cão, além de oferecer interfaces bem definidas para o meio externo. O baixo acoplamento decorrente dessa pol´ıtica proporciona muitas flexibilidades, tais como: (i) facilidade de montagem de um sistema a partir de componentes COTS1_{; e (ii) facilidade de substitui¸cão de componentes que implementam}

interfaces equivalentes.

Uma defini¸cão complementar de componentes, adotada na maioria dos trabalhos pu-blicados atualmente, foi proposta em 1998 [Szy98]. Segundo Szyperski, um componente de software é uma unidade de composi¸cão com interfaces especificadas através de contra-tos e dependências de contexto expl´ıcitas. Sendo assim, além de explicitar as interfaces com os servi¸cos oferecidos (interfaces providas), um componente de software deve de-clarar explicitamente as dependências necessárias para o seu funcionamento, através de suas interfaces requeridas.

Além dessa distin¸cão clara entre interfaces providas e requeridas, os componentes seguem três princ´ıpios fundamentais, que são comuns à tecnologia de objetos [CD00]:

1. Unifica¸cão de dados e fun¸cões: Um componente deve encapsular o seu estado (dados relevantes) e a implementa¸cão das suas opera¸cões oferecidas, que acessam esses dados. Essa liga¸cão estreita entre os dados e as opera¸cões ajudam a aumentar a coesão do sistema;

2. Encapsulamento: Os clientes que utilizam um componente devem depender so-mente da sua especifica¸cão, nunca da sua implementa¸cão. Essa separa¸cão de inte-resse2 _{reduz o acoplamento entre os módulos do sistema, além de melhorar a sua}

manuten¸c˜ao;

3. Identidade: Independentemente dos valores dos seus atributos de estado, cada componente possui um identificador ´unico que o difere dos demais.

1

do inglˆes Common-Off-The-Shelf

2

(31)

2.1. Desenvolvimento Baseado em Componentes 13

A fim de contextualizar o componente em rela¸cão aos diferentes n´ıveis de abstra¸cão que ele pode ser analisado, um componente pode ser observado através de diferentes pontos de vista [CD00]. Em outras palavras, dependendo do papel que o interessado3 _{exerce no}

processo de desenvolvimento, a abstra¸c˜ao como o componente ´e analisado pode variar. A Tabela 2.1 descreve os diferentes pontos de vista de um componente [CD00].

Tabela 2.1: Pontos de Vista de um Componente

Ponto de Vista Descric¸ ˜ao

Especifica¸c˜ao E constitu´ıdo da especifica¸c˜` ao de uma unidade de software que descreve o compor-tamento de um componente. Esse comporcompor-tamento ´e definido como um conjunto de interfaces providas e requeridas.

Plataforma São definidas restri¸cões que o componente deve seguir a fim de ser utilizado em al-guma plataforma espec´ıfica de desenvolvimento. As principais plataformas comerciais existentes são Enterprise Java Beans [MH99], Corba [MM00] e COM+ [Ses98]. Implementa¸cão E a realiza¸c˜´ ao de uma especifica¸cão. Sendo assim, a implementa¸cão de um

compo-nente está para a sua especifica¸cão, assim como uma classe está para a sua interface. Esse ponto de vista é compartilhado por todos os componentes já implementados em alguma linguagem de programa¸cão. Ele representa componentes prontos para serem instalados, como por exemplo, os componentes COTS.

Instala¸cão E uma instala¸c˜´ ao ou cópia de um componente implementado. Esse ponto de vista é utilizado na análise do ambiente de execu¸cão. Neste caso, pode ser feita uma analogia `

as classes localizadas no classpath do Java. O classpath é a lista de diretórios onde a máquina virtual procura as classes a serem instanciadas.

Instancia¸cão E uma instˆ´ ancia de um componente instalado. Esta é a visão de execu¸cão do com-ponente, com os seus dados encapsulados e um identificador único. É semelhante ao conceito de objetos no paradigma de orienta¸cão a objetos.

2.1.1 Processos de Desenvolvimento de Software

O objetivo de um processo de desenvolvimento de software é sistematizar as atividades de constru¸cão de programas, distribuindo a sua complexidade em três grupos de ativi-dades gerais [Pre01]: (i) defini¸cão do problema; (ii) desenvolvimento do sistema; e (iv) manuten¸cão. O uso de processos disciplinados de desenvolvimento reduz o número de falhas introduzidas no sistema [Avi97, AL90]. A fim de atingir a sistemática necessária para isso, os processos devem possuir um conjunto de métodos estruturados que detalhem e auxiliem o desenvolvimento de sistemas nas suas fases [Pre01]. Esses métodos são pro-cedimentos sistemáticos que usam nota¸cões bem definidas para alcan¸car seus objetivos. Assim, os métodos são compostos de atividades e diretrizes de desenvolvimento, normal-mente orientadas a um processo espec´ıfico. De uma maneira geral, os métodos devem incluir informa¸cões sobre [Som01]: (i) os modelos produzidos; (ii) as restri¸cões aplicadas a esses modelos; (iii) diretrizes de projeto; e (iv) a seqüência de atividades a ser seguida. A maioria dos processos de desenvolvimento de software atuais mapeiam o desen-volvimento do sistema em fases, que detalham os quatro grupos de atividades gerais

3

(32)

apresentados anteriormente: Grupo 1: Definic¸˜ao do problema:

• Fase de Especifica¸cão de Requisitos. O objetivo principal desta fase é a identifica¸cão dos servi¸cos que devem ser automatizados pelo sistema. Além disso, outras informa¸cões e restri¸cões importantes devem ser igualmente docu-mentadas. De acordo com a sua natureza, esses requisitos podem ser classi-ficados em duas categorias: (i)requisitos funcionais, que representam os com-portamentos que um sistema deve apresentar diante de certas a¸cões de seus usuários; e (ii) requisitos não-funcionais, que quantificam determinados aspec-tos do comportamento do sistema [Som01].

Grupo 2: Desenvolvimento do Sistema:

• Fase de Análise - Nesta etapa, os desenvolvedores se concentram na iden-tifica¸cão das entidades principais para a implementa¸cão dos requisitos do sis-tema. As entidades identificadas são representadas a partir das suas informa¸cões de estado (dados internos) e das principais opera¸cões a serem oferecidas. • Fase de Especifica¸cão da Arquitetura - Baseado principalmente nos

re-quisitos não-funcionais especificados na fase de especifica¸cão de rere-quisitos, se dá in´ıcio à especifica¸cão da arquitetura do sistema. Normalmente, essa fase consiste na escolha da arquitetura que melhor ofere¸ca as propriedades arquite-turais desejadas para satisfazer os requisitos não funcionais.

• Fase de Projeto - A etapa de projeto consiste no refinamento dos modelos gerados na análise. Esse refinamento visa a aplica¸cões de padrões, por exemplo, os padrões de projetos4 _{sugeridos por Gamma et.al. [GHJV95]. Ainda nessa}

etapa, a forma como as entidades interagem entre si é detalhada e especificada. • Fase de Implementa¸cão - Esta etapa consiste na materializa¸cão dos mode-los especificados e detalhados no projeto em uma linguagem de programa¸cão. Normalmente é feito um mapeamento direto das estruturas da modelagem para a linguagem de programa¸cão. Quando isso não é poss´ıvel, se faz necessário a utiliza¸cão de um modelo de mapeamento. Alguns exemplos de modelos para a implementa¸cão de componentes de software em linguagens orientadas a ob-jetos podem ser os modelos EJB5 _{[MH99], CCM}6 _{[MM00], DCOM}7 _{[Ses98] e}

4

do inglˆes Design patterns

5

do inglˆes Enterprise Java Beans

6

do inglˆes Corba Component Model

7

(33)

2.1. Desenvolvimento Baseado em Componentes 15

COSMOS8 _[JGR03].

• Fase de Testes - Na etapa de testes, o sistema é verificado para se certificar de que os requisitos especificados estão implementados de maneira satisfatória. • Fase de Distribui¸cão9_{- Esta etapa consiste na entrega e instala¸cão do sistema}

nos diversos ambientes onde serão utilizados pelos clientes. Grupo 3: Manutenção:

• Fase de Manuten¸cões Corretivas - As atividades desta fase consistem de a¸cões com o objetivo de corrigir inconsistências entre os requisitos especificados e o sistema implementado;

• Fase de Manuten¸cões Evolutivas (ou perfectivas) - As a¸cões de manu-ten¸cões evolutivas adicionam novas funcionalidades aos sistemas já desenvol-vidos. Sendo assim, com a aplica¸cão dessas atividades, o tempo de vida dos sistemas costumam aumentar;

• Fase de Manuten¸cões Adaptativas - Esse tipo de manuten¸cão é decorrente de mudan¸cas no ambiente tecnológico onde o software atua. Exemplos desse tipo de mudan¸ca pode ser a utiliza¸cão de um novo sistema operacional ou um novo sistema gerenciador de banco de dados [HHK+_99];

• Fase de Manuten¸cões Preventivas - As atividades de manuten¸cões preven-tivas são decorrentes de modifica¸cões realizadas para melhorar a confiabilidade ou a manutenibilidade futura [Pfl01]. Dessa forma, esse tipo de manuten¸cão tem o intuito de aumentar a vida do software, facilitando futuras evolu¸cões do sistema.

Essas fases apresentadas constituem as etapas de execu¸cão do desenvolvimento de um software. Porém, além do processo de desenvolvimento, que especifica e implementa o sistema a partir dos seus requisitos, para se desenvolver um sistema de software é ne-cessário seguir ao mesmo tempo um processo gerencial [CD00]. Um processo gerencial é responsável por esquematizar atividades, planejar libera¸cões, alocar recursos e monitorar os progressos do desenvolvimento. Na literatura encontramos alguns exemplos de aborda-gens que incluem um dos processos ou ambos. Por exemplo, o processo Catalysis [DW99] e o processo UML Components [CD00] são basicamente processos de desenvolvimento; enquanto que o processo unificado (RUP10_{) [JBR99] trata tanto do processo gerencial}

quanto do processo de desenvolvimento.

8

do inglˆes Component Structuring Model dor Object-oriented Systems

9

do inglˆes Deployment

10

(34)

Este trabalho est´a concentrado em processos de desenvolvimento de software e para facilitar a leitura, quando o termo simples processo for utilizado, se trata de uma referˆencia a um processo de desenvolvimento.

2.1.2 Processos de Desenvolvimento Baseado em Componentes

Com a populariza¸cão do DBC, a necessidade de novos processos voltados para esse para-digma é uma realidade. Isso acontece porque os processos de desenvolvimento tradicionais não se adequam totalmente ao desenvolvimento de sistemas baseados em componentes. Mais especificamente, esses processos devem conter fases e métodos que também ofere¸cam técnicas que permitam o empacotamento de componentes com o objetivo espec´ıfico de se-rem reutilizados [Som01]. Essa reutiliza¸cão sistemática deve levar em considera¸cão a captura de abstra¸cões que facilitem o entendimento do sistema tanto para seu desenvolvi-mento, quanto para a reutiliza¸cão de componentes [Szy98, Som01]. Os métodos também devem auxiliar na defini¸cão de como os componentes devem ser conectados uns aos outros para atender aos requisitos especificados. Em outras palavras, processos de DBC devem auxiliar na constru¸cão da arquitetura do software [CD00].

Uma técnica bastante utilizada para a estrutura¸cão de componentes prop´ıcios a serem reutilizados é a de análise de dom´ınio11 _[KCH+_{90, FH95]. O fundamento básico dessa}

técnica é a análise da lógica do negócio no qual os componentes se inserem. Sendo assim, os componentes que contêm as funcionalidades das entidades básicas do dom´ınio são considerados candidatos à reutiliza¸cão.

As principais particularidades dos processos de DBC podem ser observadas tanto no acréscimo de estágios técnicos ao processo convencional, quanto no enfoque dado a algumas práticas já realizadas. Um processo de desenvolvimento de software baseado em componentes geralmente inclui a defini¸cão de estratégias para [JBR99, CD00]:

• Defini¸cão expl´ıcita da arquitetura do sistema. A explicita¸cão da arquitetura tem o objetivo principal de enfatizar os aspectos de intera¸cão entre os componentes do sistema, com os seus fluxos e restri¸cões;

• Separa¸c˜ao de contextos a partir do modelo de dom´ınios. Com essa

se-para¸cão, pretende-se classificar os componentes mais prop´ıcios à reutiliza¸cão, de acordo com a lógica do negócio de cada sistema em desenvolvimento;

• Identifica¸cão das interfaces dos componentes. Um dos objetivos principais do DBC é a constru¸cão de sistemas facilmente modificáveis [CD00]. O baixo acopla-mento proporcionado pela defini¸cão de interfaces providas e requeridas é um meio de alcan¸car esse objetivo;

11

(35)

2.2. Arquitetura de Software 17

• Identifica¸c˜ao do comportamento interno dos componentes. A etapa de

projeto, comum a todos os processos de desenvolvimento, consiste na modelagem dos servi¸cos oferecidos pelo componente. Por ser uma estrutura altamente encapsulada, deve haver transparência em rela¸cão à tecnologia utilizada para a sua implementa¸cão interna;

• Montagem dos componentes do sistema. Nesta etapa ocorre a materializa¸cão da configura¸cão da arquitetura do sistema final. Devido à sua autonomia, um com-ponente de software implementa seus servi¸cos utilizando unicamente as suas interfa-ces requeridas. Sendo assim, a fase de montagem consiste na indica¸cão dos objetos reais que implementam essas interfaces; e

• Manuten¸cão de um repositório de componentes. O objetivo principal da utiliza¸cão de repositórios é maximizar a reutiliza¸cão de componentes. Isso acon-tece através do oferecimento de mecanismos de busca sistemáticos que auxiliam o desenvolvimento do software. Normalmente, essas técnicas são utilizadas em dois momentos principais: (I) no in´ıcio da especifica¸cão; e (ii) antes do projeto interno dos componentes do sistema.

2.2 Arquitetura de Software

2.2.1 Conceito e Terminologia

A arquitetura de software, através de um alto n´ıvel de abstra¸cão, define o sistema em termos de seus componentes arquiteturais, que representam unidades abstratas do sistema; a intera¸cão entre essas entidades, que são materializadas explicitamente através dos conectores; e os atributos e funcionalidades de cada um [Som01]. Por conhecerem o fluxo interativo entre os componentes do sistema, é poss´ıvel nos conectores, estabelecer protocolos de comunica¸cão e coordenar a execu¸cão dos servi¸cos que envolvam mais de um componente do sistema.

Essa visão estrutural do sistema em um alto n´ıvel de abstra¸cão proporciona benef´ıcios importantes, que são imprescind´ıveis para o desenvolvimento de sistemas de software com-plexos. Os principais benef´ıcios são: (i) a organiza¸cão do sistema como uma composi¸cão de componentes lógicos; (ii) a antecipa¸cão da defini¸cão das estruturas de controle globais; (iii) a defini¸cão da forma de comunica¸cão e composi¸cão dos elementos do projeto; e (iv) o aux´ılio na defini¸cão das funcionalidade de cada componente projetado. Além disso, uma propriedade arquitetural representa uma decisão de projeto relacionada a algum requisito não-funcional do sistema, que quantifica determinados aspectos do seu comportamento, como confiabilidade, reusabilidade e modificabilidade [CK03, Som01].

(36)

A presen¸ca de uma determinada propriedade arquitetural pode ser obtida através da utiliza¸cão de estilos arquiteturais que possam garantir a preserva¸cão dessa propriedade durante o desenvolvimento do sistema [SG96, MKMG97]. Um estilo arquitetural ca-racteriza uma fam´ılia de sistemas que são relacionados pelo compartilhamento de suas propriedades estruturais e semânticas. Esses estilos definem inclusive restri¸cões de comu-nica¸cão entre os componentes do sistema. A maneira como os componentes de um sistema ficam dispostos é conhecida como configura¸cão.

As propriedades arquiteturais são derivadas dos requisitos do sistema e influenciam, direcionam e restringem todas as fases do seu ciclo de vida. Sendo assim, a arquitetura de software é um artefato essencial no processo de desenvolvimento de softwares modernos, sendo útil em todas as suas fases [CWMY02]. A importância da arquitetura fica ainda mais clara no contexto do desenvolvimento baseados em componentes. Isso acontece, uma vez que na composi¸cão de sistemas, os componentes precisam interagir entre si para ofe-recer as funcionalidades desejadas. Além disso, devido à diferen¸ca de abstra¸cão entre a arquitetura e a implementa¸cão de um sistema, um processo de desenvolvimento baseado em componentes deve apresentar uma distin¸cão clara entre os conceitos de componente arquitetural, que é abstrato e não é necessariamente instanciável; e componente de imple-menta¸cão, que representa a materializa¸cão de uma especifica¸cão em alguma tecnologia espec´ıfica e deve necessariamente ser instanciável.

2.2.2 Modelo COSMOS

Para que os benef´ıcios proporcionados pela arquitetura de software sejam efetivamente válidos, é necessário que as abstra¸cões produzidas no projeto arquitetural do sistema sejam consideradas nas várias fases do desenvolvimento, vistas na Se¸cão 2.1.1: análise, projeto arquitetural, projeto, implementa¸cão, testes e distribui¸cão [CWMY02]. Porém, as linguagens de programa¸cão atuais não oferecem a abstra¸cão necessária para o mapeamento direto das estruturas básicas da arquitetura para o código [JGR03]. Sendo assim, se faz necessário o uso de um modelo capaz de viabilizar a implementa¸cão dos componentes, conectores e configura¸cões.

O modelo COSMOS [JGR03] é um modelo genérico e independente de plataforma, que utiliza estruturas dispon´ıveis na maioria das linguagens de programa¸cão orientadas a objetos, para a implementa¸cão de componentes de software. Os principais objetivos do COSMOS são (i) garantir que a implementa¸cão do sistema esteja em conformidade com a sua arquitetura e (ii) facilitar a evolu¸cão dessa implementa¸cão.

Para oferecer esses objetivos, o modelo COSMOS incorpora um conjunto de direti-vas de projeto que facilita a evolu¸cão dos componentes implementados. Essas diretidireti-vas incluem: (i) materializa¸cão dos elementos arquiteturais, isto é, componentes, conectores