SOCIEDADE EDUCACIONAL DE SANTA CATARINA - SOCIESC
INSTITUTO SUPERIOR TUPY - IST
Juliano Tiago Rinaldi
ARTEFATOS GERADOS NO...
JULIANO TIAGO RINALDI
Artefatos gerados nos processos de desenvolvimento de software Catalysis e UML
Components
Trabalho d...
RINALDI J. T.. Artefatos gerados nos processos de desenvolvimento de soft-
ware Catalysis e UML Components
Joinville: SOCI...
JULIANO TIAGO RINALDI
Trabalho de Diplomação sob o tíulo Ar-
tefatos gerados nos processos de desen-
volvimento de softwar...
Dedico este trabalho ao meu pequeno
grande filho Elyan, que me ensinou um
novo jeito de viver.
AGRADECIMENTO
Agradeço a várias pessoas que participaram diretamente e indiretamente deste trabalho para
torná-lo realizad...
"Só sei que nada sei"
Sócrates (470 a.C. - 399 a.C.)
RESUMO
A engenharia de software trouxe organização e foco na qualidade para a construção de
softwares. Criada a menos de 5...
ABSTRACT
Software engineering has brought organization and focus on quality for software construc-
tion. Established less ...
LISTA DE ILUSTRAÇÕES
−Figura 1 Primeiras cinco áreas do conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . ....
−Figura 34 Exemplo - diagrama de classes representando o modelo de especificação de
interface . . . . . . . . . . . . . . ....
LISTA DE QUADROS
−Quadro 1 Geração de etapas genéricas entre os processos Catalysis e UML Compo-
nents . . . . . . . . . ....
LISTA DE SIGLAS
ABNT Associação Brasileira de Normas Técnicas
CASE Computer-aided Software Engineering
COTS Commercial Off...
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 ENGENHARIA DE SOFTWA...
5 COMPARATIVO ENTRE ARTEFATOS CATALYSIS E UML COMPONENTS . . . . . . 72
5.1 DEFINIÇÕES DE CRITÉRIOS . . . . . . . . . . . ...
16
1 INTRODUÇÃO
Uma vez que o mercado de software está mudando a forma de desenvolvimento de sis-
temas, para Sommerville ...
17
sam buscar formas de desenvolver softwares reutilizáveis (DIJKSTRA, 1972 apud PRESSMAN,
2006).
Seguindo essa linha de p...
18
avaliação e do comparativo entre artefatos Catalysis e UML Components, que descreverá uma
análise sobre os artefatos pe...
19
2 ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES
Este capítulo objetiva formular conceitos bases para compreensão da eng...
20
Segundo Bruegge e Dutoit (1999), a engenharia de software é uma atividade de modela-
gem. Os engenheiros de software li...
21
[!htbp]
Figura 1: Primeiras cinco áreas do conhecimento
Fonte: Abran et al. (2004, c. 1, p. 8)
22
Figura 2: Últimas seis áreas do conhecimento
Fonte: Abran et al. (2004, c. 1, p. 9)
Figura 3: Disciplinas relacionadas ...
23
Estava intitulada a crise do software. Novos conceitos técnicos e métodos eram necessários
para assegurar o desenvolvim...
24
aplicações; os softwares são usados para tratar negócio, ciência, engenharia, assegurar vidas,
lazer e muito mais (PRES...
25
de pessoas com capacidades intelectuais e criativas. Por esse motivo, a automatização do
processo de software tem conse...
26
Pressman (2006) descreve como o processo é aplicado na engenharia de software e ex-
plana que o processo une as camadas...
27
2.2 MODELOS DE PROCESSOS DE SOFTWARE
Modelos de processos de software fornecem informações e práticas úteis para colabo...
28
É comum identificar problemas com requisitos, principalmente durante a codificação quando
aparecem problemas mais dispend...
29
Figura 5: Modelo de processo incremental
Fonte: Crnkovic e Larsson (2002, p. 94)
2.2.3 Rapid Application Development
Pa...
30
Figura 6: Modelo de desenvolvimento rápido de aplicações (RAD)
Fonte: Sommerville (2007)
e) Testes. Como o desenvolvime...
31
Figura 7: Modelo prototipagem
Fonte: Pressman (2006, p. 43) com adaptações
nem sempre estão planejadas nos projetos, ev...
32
rodada atual. Geralmente realiza-se uma revisão envolvendo todos os participantes do projeto,
incluindo desenvolvedores...
33
No início da década, esses autores constituíram um modelo combinando as melhores caracte-
rísticas dos métodos de model...
34
Uma das diferenças do RUP em relação aos outros processos, são as atividades divididas
em subprocessos chamados de fluxo...
35
Sommerville (2007) explica as causas da criação da metodologia ágil. Segundo ele, na
década de 80 e 90 o desenvolviment...
36
h) Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvol-
vedores e usuários devem ser c...
37
Assim que os testes unitários estejam programados para validar as funcionalidades, a me-
todologia indica a próxima eta...
38
do product backlog e prioridades; time, conjunto de desenvolvedores que transformam o product
backlog em incrementos en...
39
colunas que contém a quantidade de pessoas relacionadas com a necessidade de cada projeto,
ao encontrar a coluna que sa...
40
2.4 REUSO DE SOFTWARE
Segundo Sommerville (2007), a engenharia de software baseada em reuso de software é
uma abordagem...
41
orientado a aspectos. O reuso pode ser incluso em todos os processos de software devido a
grande gama de práticas possí...
42
c) Middleware como fornecedor para integração de componentes. Trata-se de uma aplicação
que gerencia a integração entre...
43
necessidades da aplicação. Na etapa seguinte, dá-se início à arquitetura e análise do sistema.
Após esta etapa, em vez ...
44
b) Desenvolvimento baseado em componentes. Define a arquietura do software baseada em
componentes, framework, padrões de...
45
propriedade da empresa desenvolvedora, sendo utilizado apenas para interpretação e conheci-
mento interno da arquitetur...
46
3 CATALYSIS
Catalysis fornece um processo sistemático para a construção de modelos precisos no de-
senvolvimento de com...
47
d) Grau variável de rigor: Descrever as pós-condições dos casos de uso em um estilo formal, ou
opcionalmente em linguag...
48
será desmembrado o núcleo do Catalysis em três formas de descrever como utilizar o modelo
e o processo abordado.
3.1 MO...
49
portamento de cada objeto, sua comunicação e colaboração através de mensagens, interfaces
externamente disponíveis e in...
50
3.3 PRINCÍPIOS FUNDAMENTAIS
Neste tópico apresentam-se os princípios necessários para se efetuar um projeto, usando o
C...
51
interpretações do problema a ser resolvido, mesmo que cerquem todas as lacunas passíveis
de erros sempre existe um ou o...
52
talysis. É importante destacar que, neste trabalho, aborda-se o modelo de processo Catalysis
apresentado a seguir.
Figu...
53
Figura 19: Domínio do sistema com foco no cliente
Fonte: D’Souza (1998, p. 77)
ware e muitas vezes desconhecem regras c...
54
Figura 20: Diagrama de mapa conceitual
Fonte: D’Souza (1998, p. 79) com adaptações
Outro aspecto que se pode ressaltar ...
55
Figura 21: Diagrama de contexto
Fonte: D’Souza (1998, p. 79) com adaptações
Na figura 22 encontra-se um exemplo de como ...
56
Figura 22: Diagrama de cenário de uso
Fonte: D’Souza (1998, p. 81) com adaptações
Figura 23: Diagrama de tipo e operaçõ...
57
do sistema. Nessa perspectiva, deve ser iniciada mais precocemente possível, observando a
evolução do projeto e readequ...
58
Figura 25: Diagrama de arquitetura técnica do sistema
Fonte: D’Souza (1998, p. 84)
dularização dos componentes do siste...
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
Próximos SlideShares
Carregando em…5
×

TCC - Engenharia de Software Baseada em Componentes

522 visualizações

Publicada em

A engenharia de software trouxe organização e foco na qualidade para a construção de softwares. Criada a menos de 50 anos. Com o passar dos anos, as maneiras de desenvolver softwares foram se ramificando, criando processos específicos para cada tipo de software, ou mesmo, objetivos de softwares, chegando em um momento que a engenharia de software propôs a construção de softwares componentizados. Esta nova forma de construir software trouxe benefícios à engenharia, que por fim, deu-se o nome de Engenharia de Software Baseada em Componentes (ESBC). A ESBC é um ramo da engenharia de software com foco na reutilização de softwares, que através de componentes moduláveis proporcionam aplicações mais robustas e confiáveis. Dentro da ESBC, existem diferentes tipos de processos de softwares para construção de aplicações baseadas em componentes, com isto, o objetivo deste trabalho é apresentar o estudo de dois processos, Catalysis e UML Components, e, diante disto, fazer uma comparação entre etapas e artefatos gerados nestes processos, para identificar qual oferece subsídios para uma melhor especificação de software baseado em componentes. A pesquisa aplicada foi de caráter exploratório, utilizando como estratégia um estudo comparativo entre as etapas e artefatos dos processos citados. Conclui-se, que é de grande importância a construção de softwares moduláveis, pois com isso, além da arquitetura do software manter uma estrutura flexível em forma de componentes de negócios, possibilita a evolução do software sem interferir no todo, aplicando a manutenção somente no componente desejado. Por fim, o reuso de componentes trazem maior confiança para a aplicação, pois como os componentes já estão desenvolvidos e operando em outros softwares, são considerados maduros, com bugs já corrigidos, proporcionando um aumento da qualidade do software.
Palavras-chave: Engenharia de Software. ESBC. Catalysis. UML Components

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
522
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
13
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

TCC - Engenharia de Software Baseada em Componentes

  1. 1. SOCIEDADE EDUCACIONAL DE SANTA CATARINA - SOCIESC INSTITUTO SUPERIOR TUPY - IST Juliano Tiago Rinaldi ARTEFATOS GERADOS NOS PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE CATALYSIS E UML COMPONENTS: UM ESTUDO EXPLORATÓRIO COMPARATIVO Joinville 2011/1
  2. 2. JULIANO TIAGO RINALDI Artefatos gerados nos processos de desenvolvimento de software Catalysis e UML Components Trabalho de Conclusão de Curso apresentado ao Instituto Superior Tupy - IST, como requisito par- cial para a obtenção de grau de Bacharel de En- genharia da Computação, sob a orientação do professor Paulo Rogério Pires Manseira. Joinville 2011/1
  3. 3. RINALDI J. T.. Artefatos gerados nos processos de desenvolvimento de soft- ware Catalysis e UML Components Joinville: SOCIESC, 2011/1.
  4. 4. JULIANO TIAGO RINALDI Trabalho de Diplomação sob o tíulo Ar- tefatos gerados nos processos de desen- volvimento de software Catalysis e UML Components, apresentado por Juliano Ti- ago Rinaldi, e aprovado em 07 de julho de 2011, em Joinville, pela banca exami- nadora constituída conforme abaixo: Luiz Carlos Camargo - [IST - SOCIESC] Paulo Rogério Pires Manseira - [IST - SOCIESC] Salvador Antônio dos Santos - [IST - SOCIESC]
  5. 5. Dedico este trabalho ao meu pequeno grande filho Elyan, que me ensinou um novo jeito de viver.
  6. 6. AGRADECIMENTO Agradeço a várias pessoas que participaram diretamente e indiretamente deste trabalho para torná-lo realizado. Primeiramente, à minha esposa Janaina, por me apoiar e sacrificar-se quase sozinha nos cuidados com nosso pequeno filho Elyan; à minha mãe, que sempre acreditou no meu potencial e me deu forças para conquistar minhas vitórias; ao meu orientador, Paulo Manseira, por compartilhar seu enorme conhecimento de engenharia de software e dedicar seu tempo em revisar e melhorar este trabalho; aos meus colegas de turma, que foram companhei- ros durante todo o curso; à professora Glaci Gurgacz, por sua dedicação e cobrança para que alunos realizassem um trabalho de conclusão de curso de ótima qualidade; ao professor Luiz Carlos Camargo, pelo auxílio, esclarecimento e motivação apresentada sobre este trabalho.
  7. 7. "Só sei que nada sei" Sócrates (470 a.C. - 399 a.C.)
  8. 8. RESUMO A engenharia de software trouxe organização e foco na qualidade para a construção de softwares. Criada a menos de 50 anos. Com o passar dos anos, as maneiras de desenvol- ver softwares foram se ramificando, criando processos específicos para cada tipo de software, ou mesmo, objetivos de softwares, chegando em um momento que a engenharia de software propôs a construção de softwares componentizados. Esta nova forma de construir software trouxe benefícios à engenharia, que por fim, deu-se o nome de Engenharia de Software Ba- seada em Componentes (ESBC). A ESBC é um ramo da engenharia de software com foco na reutilização de softwares, que através de componentes moduláveis proporcionam aplica- ções mais robustas e confiáveis. Dentro da ESBC, existem diferentes tipos de processos de softwares para construção de aplicações baseadas em componentes, com isto, o objetivo deste trabalho é apresentar o estudo de dois processos, Catalysis e UML Components, e, diante disto, fazer uma comparação entre etapas e artefatos gerados nestes processos, para identificar qual oferece subsídios para uma melhor especificação de software baseado em componentes. A pesquisa aplicada foi de caráter exploratório, utilizando como estratégia um estudo comparativo entre as etapas e artefatos dos processos citados. Conclui-se, que é de grande importância a construção de softwares moduláveis, pois com isso, além da arquitetura do software manter uma estrutura flexível em forma de componentes de negócios, possibilita a evolução do software sem interferir no todo, aplicando a manutenção somente no componente desejado. Por fim, o reuso de componentes trazem maior confiança para a aplicação, pois como os componentes já estão desenvolvidos e operando em outros softwares, são considerados maduros, com bugs já corrigidos, proporcionando um aumento da qualidade do software. Palavras-chave: Engenharia de Software. ESBC. Catalysis. UML Components.
  9. 9. ABSTRACT Software engineering has brought organization and focus on quality for software construc- tion. Established less than 50 years. Over the years, the ways of developing software has been branching out, creating specific processes for each type of software, or even targets of softwares. With this, it was a time that software engineering has proposed building componentized software. This new way of building software has brought benefits to engineering, which eventually gave the name of Component-based software engineering (CBSE), with a focus on software reuse. Within the CBSE, there are different types of software processes for building component-based applications, thus, the objective of this paper is to present the study of two processes, Cataly- sis and UML Components, and before that, make a comparison between steps and artifacts generated in these processes, to identify which provides resources for a better specification of component-based software. The applied research was exploratory, using a comparative study between steps and artifacts of the processes mentioned. The conclusion, which has a great importance about modular software construction, be- cause, beyond the software architecture to maintain a flexible structurein order to build business components, enables the software evolution without interfering the complete software, applying the maintenance only in the desired component. Finally, the components reuse bring greater confidence to the application, because as components are already developed and operating in other software are considered mature, with fixed bugs, providing a software quality increase. modeling software. Keywords: Software Engineering. CBSE. Catalysis. UML Components.
  10. 10. LISTA DE ILUSTRAÇÕES −Figura 1 Primeiras cinco áreas do conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 −Figura 2 Últimas seis áreas do conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 −Figura 3 Disciplinas relacionadas a engenharia de software . . . . . . . . . . . . . . . . . . . . . . . 22 −Figura 4 Modelo de processo em cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 −Figura 5 Modelo de processo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 −Figura 6 Modelo de desenvolvimento rápido de aplicações (RAD) . . . . . . . . . . . . . . . . . 30 −Figura 7 Modelo prototipagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 −Figura 8 Modelo espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 −Figura 9 Modelo de processo unificado (RUP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 −Figura 10 Atividades da metodologia Extreme Programming (XP) . . . . . . . . . . . . . . . . . . 36 −Figura 11 Modelo de processo da metodologia SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 −Figura 12 Metodologia Crystal - mapa da família . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 −Figura 13 Processo da ESBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 −Figura 14 Modelo de processo da ESBC completo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 −Figura 15 Modelo de escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 −Figura 16 Modelo de construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 −Figura 17 Princípios do Catalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 −Figura 18 Modelo de processo Catalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 −Figura 19 Domínio do sistema com foco no cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 −Figura 20 Diagrama de mapa conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 −Figura 21 Diagrama de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 −Figura 22 Diagrama de cenário de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 −Figura 23 Diagrama de tipo e operações do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 −Figura 24 Modelo da plataforma requerida do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 −Figura 25 Diagrama de arquitetura técnica do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 −Figura 26 Diagrama de arquitetura interna de componente . . . . . . . . . . . . . . . . . . . . . . . . . 58 −Figura 27 Modelo de Processo UML Components baseado no RUP . . . . . . . . . . . . . . . . 61 −Figura 28 Etapas e artefatos gerados no processo UML Components . . . . . . . . . . . . . . 61 −Figura 29 Três estágios do processo UML Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 −Figura 30 Modelo conceitual de negócio ou domínio da aplicação . . . . . . . . . . . . . . . . . . 64 −Figura 31 Exemplo - diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 −Figura 32 Exemplo - narrativa gerada de um caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 65 −Figura 33 Exemplo - diagrama de classes representando o modelo de tipo de negócio 67
  11. 11. −Figura 34 Exemplo - diagrama de classes representando o modelo de especificação de interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 −Figura 35 Ilustração de um componente que oferece interface de implementação . . . 70 −Figura 36 Ilustração de um componente com interface provided e required . . . . . . . . . 70 −Figura 37 Modelo de arquitetura de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 −Figura 38 Modelo de domínio do sistema no processo Catalysis . . . . . . . . . . . . . . . . . . . . 75 −Figura 39 Modelo de domínio do sistema no processo UML Components . . . . . . . . . . . 76 −Figura 40 Análise gráfica da comparação de artefatos da etapa Especificação de Ne- gócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 −Figura 41 Análise gráfica da etapa de Especificação de Negócio . . . . . . . . . . . . . . . . . . . 78 −Figura 42 Análise gráfica da comparação de artefatos da etapa Especificação de Sis- tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 −Figura 43 Análise gráfica da etapa de Especificação de Sistema . . . . . . . . . . . . . . . . . . . 82 −Figura 44 Análise gráfica da comparação de artefatos da etapa Arquitetura de Compo- nentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 −Figura 45 Análise gráfica da etapa de Arquitetura de componentes . . . . . . . . . . . . . . . . . 85 −Figura 46 Análise gráfica comparativa das etapas genéricas . . . . . . . . . . . . . . . . . . . . . . . 86
  12. 12. LISTA DE QUADROS −Quadro 1 Geração de etapas genéricas entre os processos Catalysis e UML Compo- nents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 −Quadro 2 Etapas genéricas relacioados aos artefatos dos processos Catalysis e UML Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 −Quadro 3 Informações captadas pelos artefatos na especificação de negócio . . . . . 77 −Quadro 4 Informações captadas pelos artefatos na especificação de sistema . . . . . 80 −Quadro 5 Informações captadas pelos artefatos na arquitetura de componentes . . 84
  13. 13. LISTA DE SIGLAS ABNT Associação Brasileira de Normas Técnicas CASE Computer-aided Software Engineering COTS Commercial Off-The-Shelf ECP Bacharelado em Engenharia da Computação ERP Enterprise Resource Planning ESBC Engenharia de Software Baseada em Componentes IST Instituto Superior Tupy NATO Nato Science Committe RAD Rapid Application Development RUP Rational Unified Process SWEBOK Software Engineering Body of Knowledge TCC Trabalho de Conclusão de Curso UML Unified Modeling Language XP Extreme Programming
  14. 14. SUMÁRIO 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2 ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES . . . . . . . . . . . 19 2.1 ENGENHARIA DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.2 Processos de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2 MODELOS DE PROCESSOS DE SOFTWARE . . . . . . . . . . . . . . . . . . . . 27 2.2.1 Modelo em cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.2 Modelo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3 Rapid Application Development . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.4 Prototipagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.2.5 Modelo espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.6 Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 METODOLOGIAS ÁGEIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3.1 Extreme programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.3.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3.3 Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.4 REUSO DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.4.1 ESBC como solução de reuso de software . . . . . . . . . . . . . . . . . . . . 41 2.4.2 Processo da ESBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.4.3 Componentes de prateleira (COTS) . . . . . . . . . . . . . . . . . . . . . . . . 44 3 CATALYSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.1 MODELO DE ESCOPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.2 MODELO DE CONSTRUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3 PRINCÍPIOS FUNDAMENTAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.4 PROCESSO CATALYSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.4.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.2 Especificação do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.4.3 Arquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.4.4 Arquitetura interna dos componentes . . . . . . . . . . . . . . . . . . . . . . . 57 4 UML COMPONENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.1 PROCESSO UML COMPONENTS . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.1.1 Identificação de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.1.2 Interação entre Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.1.3 Especificação de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 69
  15. 15. 5 COMPARATIVO ENTRE ARTEFATOS CATALYSIS E UML COMPONENTS . . . . . . 72 5.1 DEFINIÇÕES DE CRITÉRIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2 ESPECIFICAÇÃO DE NEGÓCIO . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.3 ESPECIFICAÇÃO DE SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4 ARQUITETURA DE COMPONENTES . . . . . . . . . . . . . . . . . . . . . . . . 82 6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
  16. 16. 16 1 INTRODUÇÃO Uma vez que o mercado de software está mudando a forma de desenvolvimento de sis- temas, para Sommerville (2007), os métodos ágeis vêm recebendo uma grande atenção nos últimos anos, devido aos seus objetivos de desenvolvimento rápidos e interativos de aplicações. Esta nova visão desencadeou, em muitas empresas, a filosofia “comprar, em vez de construir softwares” (CLEMENTS, 1995 apud PRESSMAN, 2006), chamados de Commercial Off-The- Shelf (COTS) componentes comerciais de prateleira. Percebe-se, portanto, que o domínio dos conceitos e técnicas de desenvolvimento de software baseado em componentes torna-se pre- missa para qualquer profissional da área. Com o avanço das linguagens de software, criou-se o conceito de Orientação a Objetos na década de 1960, que evolui a partir de então. Este recurso desdobra-se, a partir de 1968 para o desenvolvimento de componentes, permitindo o amadurecimento dos estudos na reutilização de software. O desenvolvimento de software voltado para orientação a objeto possibilita abordar a relação dos objetos abstratos com o conceito, definição, e comportamento no mundo real, facilitando a compreensão de sistemas complexos estruturando-os em objetos comunicáveis. A flexibilidade destes sistemas foi tão ascendente que as novas linguagens de desenvolvimento tiveram que se adaptar ao novo paradigma. Atualmente o desenvolvimento de componentes implica em desenvolvimento orientado a objeto, onde os próprios processos e metodologias especificam como requisito de conhecimento a análise orientada a objeto. A Engenharia de Software Baseada em Componentes (ESBC) foi criada para padronizar o processo de descoberta, reuso, e aplicação de componentes dentro da engenharia de software. De forma conceitual, especifica um macro processo para todas as metodologias de desenvolvi- mento de componentes. Para Pressman (2006), a ESBC é um ramo da engenharia de software que contempla duas atividades: engenharia de domínio e desenvolvimento baseado em componentes. A engenharia de domínio determina processos para elaborar o projeto de software baseado em componentes, bem como explana técnicas para coleta de componentes funcionais reusáveis e comportamento de dados. Já o desenvolvimento é a etapa de produção do software. Por meio dos processos e técnicas da ESBC, constroem-se componentes moduláveis de grande qualidade que impactam diretamente em rápido desenvolvimento de novos softwares. O objetivo é tornar componentes reutilizáveis para desenvolvimento de futuros sistemas com domínios de aplicações semelhantes. Software é um produto diferenciado, onde qualidade não obrigatoriamente é sinônimo de alto preço. Os profissionais que desejam o patamar de alta qualidade com baixo preço preci-
  17. 17. 17 sam buscar formas de desenvolver softwares reutilizáveis (DIJKSTRA, 1972 apud PRESSMAN, 2006). Seguindo essa linha de pensamento, a questão que surge é: Como produzir software de qualidade, reutilizando o máximo de funcionalidades já desenvolvidas e testadas? Esta per- gunta deixa muitas dúvidas tanto no âmbito acadêmico quanto no empresarial. Os projetos de reutilização de software são poucos publicados no mundo acadêmico de- vido à complexidade do processo de análise de sistema e arquitetura do software. Professores acadêmicos sentem a necessidade de um material mais palpável para transpor a teoria para a prática da ESBC aos seus alunos. Dentre as bibliografias pesquisadas, os autores dos livros da engenharia de software publicam seus trabalhos sobre ESBC de modo conceitual, servindo para os leitores como base teórica de desenvolvimento de software baseado em componentes, porém, não se encontra atualmente nas bibliografias conhecidas, algum material mais consis- tente, que pudesse apresentar as etapas e artefatos de processos ligados a ESBC. Com isso, este trabalho tem por objetivo geral compreender e comparar artefatos dos processos Cataly- sis e UML Components da engenharia de software baseado em componentes. Para atingi-lo, foram formulados os seguintes objetivos específicos: conhecer o processo da engenharia de software baseada em componentes; conceituar a importância da reutilização de software; re- latar metodologias de desenvolvimento de software baseado em componentes; compreender a construção de artefatos para modelagem de software basedo em componentes e analisar os artefatos gerados de cada etapa na especificação de componentes. A metodologia utilizada neste trabalho consiste em uma pesquisa de natureza exploratória sobre o tema engenharia de software baseada em componentes. Em um segundo momento desenvolveu-se um estudo comparativo entre as etapas e artefatos de cada processo. Na compação dos artefatos, foram gerados critérios de avaliação através de perguntas, sendo assim, o objetivo é focado em obter quais as informações que os artefatos de cada processo pode responder sobre a especificação de um software. Em sequência, através da análise do referencial teórico, deu-se comentários sobre pontos positivos e negativos do material gerado para especificação de um sistema base- ado em componentes. Este trabalho está estruturado em 5 capítulos. Inicia-se com o referencial teórico sob o tí- tulo de Engenharia de Software Baseada em Componentes, onde explõe sobre a engenharia de software, modelos de processos de software, metodologias ágeis, ESBC e Reuso de Software. No capítulo 3, apresenta-se o processo Catalysis. Será abordado, processo, etapas e artefatos do desenvolvimento de software baseado em componentes através do Catalysis. Logo após, no capítulo 4, o trabalho é dedicado a sintetizar os artefatos e as etapas do processo de desenvol- vimento de sistemas utilizando UML Components. Enfim, no capítulo 5, trata-se dos critérios de
  18. 18. 18 avaliação e do comparativo entre artefatos Catalysis e UML Components, que descreverá uma análise sobre os artefatos pertencentes as etapas dos processos apresentados neste trabalho. A comparação teve como requisito, a compreensão do referencial teórico e os critérios de ava- liação descritos no capítulo. Por fim, a conclusão descreve as dificuldades encontradas, bem como o aprendizado extraído deste trabalho, deixando para trabalhos futuros, sugestões de desenvolvimento de software baseado em componentes utilizando os processos apresentados neste trabalho. Adiante, o trabalho inicia com o referencial teórico, explicando sobre a engenharia de soft- ware baseada em componentes, que agrupa as definições da engenharia de software, conceito de software, processos e reuso de softwares.
  19. 19. 19 2 ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES Este capítulo objetiva formular conceitos bases para compreensão da engenharia de soft- ware baseada em componentes. Para isso, explana um referencial teórico extenso sobre pontos importantes e necessários que cabem à engenharia de software. 2.1 ENGENHARIA DE SOFTWARE A engenharia de software está centralizada como uma engenharia de cunho econômico, com perspectivas de desenvolvimento de software com custos adequados e alta qualidade. (SOMMERVILLE, 2007). Em outro ponto de sua bibliografia, Sommerville (2007) especifica engenharia de software como uma disciplina da engenharia relacionada a todo conhecimento necessário para produção de software, considerando desde estágios primários de especificação até a manutenção e operação do sistema. Bauer, Naur e Randel (apud PRESSMAN, 2006, p. 17) descrevem na conferência Nato Science Committe (NATO), que “Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que tra- balhem eficientemente em máquinas reais”. Já a IEEE (1993), desenvolveu uma abordagem mais abrangente sobre engenharia de software: “É a aplicação de uma abordagem sistemática, disciplinada e quantificável, para o desenvolvimento, operação e manutenção do software [...]”. Pádua (2009) compreende que a engenharia de software se preocupa com o software como um produto, ou seja, determina subsídios para que o software seja projetado para solucionar um problema. Na busca do conceito de engenharia de software em um dicionário de português, encontra- se apenas o termo engenharia. Ferreira (2010) conceitua o termo como: Arte de aplicar conhecimentos científicos e empíricos e certas habilitações es- pecíficas à criação de estruturas, dispositivos e processos que se utilizam para converter recursos naturais em formas adequadas ao atendimento das neces- sidades humanas. Esta descrição é considerada muito genérica ao se tratar dos princípios da engenharia de software, pois esta trata de um produto intangível quanto a materiais físicos. Na procura nos dicionários de língua inglesa uma possível definição sobre engenharia de software, não foi encontrado assunto específico para descrevê-la, se trata de um conceito direcionado, ligado á tecnologia, e ainda pouco explorado, menos de 50 anos de existência.
  20. 20. 20 Segundo Bruegge e Dutoit (1999), a engenharia de software é uma atividade de modela- gem. Os engenheiros de software lidam com complexidade de sistemas através da modelagem e arquitetura de software cujo o propósito é focar na solução do problema de uma forma acei- tável, sendo que muitas vezes, esta pesquisa é conduzida através da experimentação. Os processos iniciais começam com a coleta de dados; catalogando e absorvendo todas as infor- mações do projeto. Na sequência, deve-se organizá-las e formalizá-las em conhecimento. A aquisição de conhecimento não é linear, já que uma única peça de dados pode invalidar mo- delos completos de sistema. Ao adquirir o conhecimento e tomar decisões sobre o sistema e domínio da aplicação, os engenheiros de software necessitam entender o contexto e razões da aplicação para não só atingir, mas superar as expectativas do cliente. Os engenheiros de software ficam limitados pelos orçamentos e prazos do projeto. O de- safio encontrado para maioria dos engenheiros é arquitetar a solução do sistema com custos e prazos reduzidos, garantindo qualidade no processo de desenvolvimento e garantia de entrega. Utiliza-se de recursos como construção de diagramas, estruturas de dados e conceitos tecnoló- gicos, e deve deixar detalhes irrelevantes da funcionalidade para outras áreas do conhecimento (BRUEGGE; DUTOIT, 1999, p. 5). Enquanto alguns autores discutem o termo engenharia de software com foco em soluções e processos para a área de desenvolvimento de software, a Software Engineering Body of Kno- wledge (SWEBOK) se preocupa com a área acadêmica, definindo áreas de estudo, conforme a figura 1 e 2, que por sua vez, determinam as disciplinas de conhecimento na engenharia de software. Seus objetivos são mais estruturais. Caracterizada por conteúdos e tópicos de es- tudo que devem ser tratados em um curso relacionado à engenharia de software. A SWEBOK demonstra uma visão universal sobre a engenharia de software e relaciona suas semelhanças e interações com outras disciplinas do conhecimento (figura 3) (ABRAN et al., 2004). A denominação de engenharia de software foi proposta no ano de 1968 em uma conferência organizada para a discussão da “crise de software”. O fenômeno da crise do software foi qualifi- cado quando começaram a surgir novos hardwares de computadores construídos com circuitos integrados. O poder de processamento de um computador da época construído com circui- tos integrados foi tão ascendente que softwares considerados até então não realizáveis, foram considerados propostas viáveis. Começaram a surgir demandas de softwares com grandeza e complexidade muito superior aos produzidos da época. O desenvolvimento destes softwares comprovou a inexperiência das equipes para construção de aplicações complexas que impac- tavam diretamente em anos de atraso de entrega do software, e custos exorbitantes ao final do projeto. A manutenção do software se tornava uma tarefa para heróis, e o desempenho era in- satisfatório, percebeu-se que todo o trabalho desenvolvido não caberia á evolução do sistema.
  21. 21. 21 [!htbp] Figura 1: Primeiras cinco áreas do conhecimento Fonte: Abran et al. (2004, c. 1, p. 8)
  22. 22. 22 Figura 2: Últimas seis áreas do conhecimento Fonte: Abran et al. (2004, c. 1, p. 9) Figura 3: Disciplinas relacionadas a engenharia de software Fonte: Abran et al. (2004, c. 12, p. 1)
  23. 23. 23 Estava intitulada a crise do software. Novos conceitos técnicos e métodos eram necessários para assegurar o desenvolvimento de software de maneira controlada, através desta necessi- dade foi criado a então engenharia de software (PRESSMAN, 2006). Todos os autores concordam que engenharia de software tem objetivo em construir softwa- res de qualidade, com custos adequados e processos bem definidos. Para entender os objetivos da engenharia de software precisamos conhecer definitivamente o que é software, e como ele é construído em um processo de desenvolvimento de software. 2.1.1 Software Software é abstrato e intangível, sem limite quanto à física dos materiais. Está qualificado como uma área complexa da engenharia que facilmente se expande e torna-se de difícil com- preensão (SOMMERVILLE, 2007). Pressman (2006) conceitua software como instruções ou programas de computadores que quando executados fornecem as características, funções e desempenho desejados. São estru- turas de dados que permitem aos programas manipular adequadamente a informação. Devem ainda fazer parte do software, os documentos que descrevem operações e uso dos programas. Para Pádua (2009), software é a parte programável de um sistema de informática, sendo considerado elemento central de estruturas complexas e ao mesmo tempo flexíveis, que trazem funções, utilidade e valor ao sistema. O software não pode ser pesado ou medido em unidades físicas, de forma estrutural é en- tendido como uma série de instruções lógicas adequadas para executar uma função no sistema. Ele não trabalha sozinho, aliás, necessita de muitos outros componentes trabalhando em con- junto para lhe dar a condição de execução das tarefas. Por outro lado, o software não executa tarefas, pois esta responsabilidade é diretamente dedicada ao processador da máquina, que necessita ser alimentado para executar as ações. O processador precisa receber instruções para saber o que fazer; neste momento entra o alimento, ou seja, o software, que contém uma série de lógicas utilizadas pelo processador para traduzir a ação á tomar no sistema. Software, sob o ponto de vista de Wang (2008), é a compilação de códigos de uma certa linguagem de programação, composta por algoritmos de dados logicamente transpassados para um computador responsável pela execução do sistema. Além do arcabouço lógico, fazem parte do software a documentação da aplicação, manuais do usuário, especificação e concepção do sistema, testes de verificação e validação de requisitos, e mecanismos de manutenção. O Software está em constante evolução; ninguém da década de 50 poderia prever que tal tecnologia tornar-se-ia tão necessária em nossos dias. Hoje somos dependentes de muitas
  24. 24. 24 aplicações; os softwares são usados para tratar negócio, ciência, engenharia, assegurar vidas, lazer e muito mais (PRESSMAN, 2006). Para esse autor, a indústria de Software tornou-se um fator dominante nas economias dos países industrializados. O programador que mantinha o conhecimento por inteiro do software foi substituído por uma equipe de especialista em software, cada um preocupado com uma parte da tecnologia necessária para produzir uma aplicação complexa. É importante entender que software não é apenas um programa de computador. Som- merville (2007) explica que há outros artefatos inclusos no escopo de um sistema. Dados de documentação e configuração são partes necessárias para que uma aplicação opere correta- mente. Estas informações fazem parte de um software. Os engenheiros de software constroem suas aplicações como um produto de software, incluem no escopo todas as informações e mão de obra necessária para que o produto entre em operação. O autor propõe a divisão do produto de software em dois caminhos. a) Produtos genéricos. São produtos de softwares desenvolvido por uma organização que visa vendê-los no mercado a qualquer cliente interessado. Dentre os produtos de software, qualifica-se um produto genérico como, por exemplo: um processador de texto, de fácil instalação e utilização por diversas pessoas. b) Produtos sob encomenda. São produtos diferenciados, produzidos por uma organização que atende diretamente um cliente específico. O produto final deve apoiar o cliente na melhoria de processos ou mesmo na resolução de problemas. Classifica-se produto sob encomenda, como um simples Enterprise Resource Planning (ERP) customizado a de- terminado cliente. É notável a diferença entre os tipos de produtos de software. Este fato se estende também para a especificação dos requisitos de sistema. Nos produtos genéricos, a própria organização gerencia e cria seus requisitos, já nos produtos encomendados, a especificação do sistema fica com o cliente, que deve transpassar suas necessidades em forma de requisitos para a organização desenvolver o produto necessário. Após a compreensão do que é um software, há a necessidade de entender como ele é construído, que por sua vez, estrutura-se através de processos de software. 2.1.2 Processos de software O processo de software para Sommerville (2007) é um conjunto de ferramentas e atividades para confeccionar um produto de software. Os processos para serem executados dependem
  25. 25. 25 de pessoas com capacidades intelectuais e criativas. Por esse motivo, a automatização do processo de software tem conseguido um sucesso limitado. Baetjer (apud PRESSMAN, 2006, p. 16) comenta que: [...] O processo é um diálogo no qual o conhecimento, que deve ser transfor- mado em software é reunido e incorporado ao software. [...] É um processo interativo no qual a própria ferramenta serve como meio de comunicação, com cada nova rodada de diálogo explicitando mais conhecimento útil do pessoal envolvido. Interpretando o comentário de Baetjer (1998), conclui-se que processos de software são interativos, e necessitam das pessoas em equipe para assim aplicar e adquirir o conhecimento útil ao software. Aplicando um conceito simples sobre processos, o melhor encaixe à definição vem de Pá- dua (2009), que resume processos como “um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta”. O autor abrange simplificadamente o tema por definição técnica, transparecendo um entendi- mento global sobre os processos existentes nas indústrias. Quando o referido autor trata da engenharia de software, define processo listando apenas algumas práticas de forma sucinta, como atividades de desenvolvimento, manutenção, aquisição e contratação de software. Abran et al. (2004, p. 6) entende que o processo de software está preocupado com a defi- nição, implementação, avaliação, medição, gestão, mudança e melhoria do processo da enge- nharia de software. O autor ainda explana que o processo de software está dividido em quatro subáreas. a) A primeira subárea apresenta processo de implementação e mudança: considerado como infraestrutura de processo, gestão do ciclo do processo de software, modelo de imple- mentação e mudanças de processos. b) A segunda subárea apresenta a definição do processo. Inclui temas como ciclo de vida de modelos de softwares, ciclo de vida do processo de software, definições de processos, adaptação e automação de processos. c) A terceira subárea é a avaliação do processo. Nela são apresentados modelos de processo de avaliação e métodos de avaliação do processo. d) A quarta subárea descreve as medidas de processos e produtos. O processo de engenharia de software abrange a medição geral dos produtos, bem como a medição do processo em geral. Fazem parte desta subárea, processos de medição, medição de produtos de software, qualidade dos resultados das medições, modelos de informação e técnicas de medição do processo.
  26. 26. 26 Pressman (2006) descreve como o processo é aplicado na engenharia de software e ex- plana que o processo une as camadas de tecnologia, possibilitando o desenvolvimento racional do software como produto. No contexto gerencial, dá subsídios para administração e controle dos projetos de software, já no contexto técnico define como as ferramentas e técnicas são aplicadas. O produto do trabalho são modelos, documentos, dados, relatórios, formulários, etc. A estrutura básica do processo de software é definida por um arcabouço de atividades que são aplicadas a qualquer projeto de software independente de tamanho ou complexidade. Cada atividade é justificada por ações, composta por tarefas individuais que são responsáveis pela execução de parte do trabalho determinado pela ação. Projetos são distintos, e sua produção também segue processos diferenciados. De qualquer forma, a maior parte dos projetos cons- truídos tem início através das atividades de um processo genérico, conforme descrito a seguir: a) Comunicação. Envolve comunicação e colaboração com os stakeholders (clientes), que cooperam na definição de requisitos e atividades afins para seguimento do projeto. b) Planejamento. É a parte primordial para o sucesso do projeto. Define plano de trabalho, tarefas técnicas á serem desenvolvidas, riscos prováveis, recursos necessários, produto do trabalho e o cronograma, que quanto mais previsível, melhor será a condução do projeto. c) Modelagem. A modelagem é um processo de transformação do conceito para o modelo. Nesta etapa, o engenheiro de software deve traduzir os requisitos em estrutura de mode- los de sistema. d) Construção. Essa etapa pode ser considerada como a mais importante. É nela que real- mente são gerados o código e os testes unitários necessários para revelar erros. Neste ponto, o produto começa a ser confeccionado para executar as funções definidas pelos requisitos dos sistema. e) Implantação. Dependendo do processo de desenvolvimento de software, esta atividade pode ser apenas um incremento de software entregue ao cliente, ou a entrega final do projeto. O cliente avalia a aplicação recebida e fornece um feedback sobre os serviços prestados. No campo das engenharias, cada procedimento preza por seguir um processo determinado. O objetivo é garantir qualidade, ou mesmo, garantia de entrega do produto ou projeto. Para isto, existem os modelos de processos, que por sua vez, na engenharia de software são imprescin- díveis para construção de uma aplicação. Adiante, aborda-se sobre os modelos de processos dentro da engenharia de software.
  27. 27. 27 2.2 MODELOS DE PROCESSOS DE SOFTWARE Modelos de processos de software fornecem informações e práticas úteis para colaborar com o trabalho da engenharia de software, são baseados em um conjunto de atividades, ações, tarefas, marcos, produtos de software, garantia de qualidade e controle de modificações dos projetos. Cada modelo de processo determina um foco central do fluxo de trabalho, o qual estabelece como os processos serão inter-relacionados (PRESSMAN, 2006). Sommerville (2007) entende que os modelos de processos representam uma visão restrita e parcial do processo aplicado à organização, devido ao foco central de cada processo na computação, existem modelos genéricos de processos, os quais são bases para todo projeto de engenharia de software, sendo flexíveis quanto a adaptações e mudanças para processos mais específicos. Para esse autor, sob a perspectiva de arquitetura de modelo genérico; pode ser considerado um framework. Adiante serão abordados os modelos de processos mais conhecidos da engenharia de software. 2.2.1 Modelo em cascata Sommerville (2007) define o modelo de processo em cascata, como um encadeamento de uma fase após a outra, uma sequência de estágios de desenvolvimento do software (figura 4). Como regra do modelo, uma fase não pode começar antes que a fase anterior tenha terminado. Assim, este modelo torna-se inflexível quanto a mudanças de escopo e requisitos de sistema. Figura 4: Modelo de processo em cascata Fonte: Sommerville (2007, p. 44) com adaptações
  28. 28. 28 É comum identificar problemas com requisitos, principalmente durante a codificação quando aparecem problemas mais dispendiosos de solução. Os projetos de software são limitados a custos de produção. Por este motivo, a redução de tempo de projeto interfere nas iterações dos processos, que posteriormente gerará um maior tempo de retrabalho. É normal, neste tipo de modelo, acontecer de suspender etapas do desenvolvimento, e retomar as pendências no final do projeto ou mesmo ignorá-las, isto significa que o cliente não receberá a funcionalidade em estado completo. Em fase final do projeto de software, quando colocado em uso direto com o cliente; - etapa considerada crítica pelo modelo - aparecem os erros e omissões nos requisitos do software, e, para contornar, inicia-se a manutenção do software sem previsão de fim. Porém o modelo de cascata tem alguns benefícios, como a documentação produzida em cada fase do processo. Pressman (2006) entende que, nos dias de hoje, o modelo em cascata é inadequado aos processos de desenvolvimento de sistemas. O desenvolvimento de softwares atuais, frequen- temente muda de requisitos e altera escopos inteiros de projeto com frequência, isto invalidaria parte do sistema em desenvolvimento sobre modelo em cascata. No entanto, o autor ainda afirma, de certo modo, que seria possível utilizar o modelo em cascata caso o software fosse definido com requisitos fixos e o trabalho prosseguir sem problemas inesperados. 2.2.2 Modelo incremental O modelo incremental combina elementos do modelo em cascata com a abordagem ite- rativa. Funciona em forma de estágios (figura 5) e, a cada estágio, produz um incremento de entrega de software com novas funcionalidades. As entregas geram reconhecimento do status do produto, e o cliente sente-se atendido por colaborar com o software em desenvolvimento. Após as iterações serem finalizadas e entregues, planejam-se os próximos requisitos que farão parte do novo incremento, que propõe alterar o software para satisfazer as necessidades do cli- ente de forma eficaz. O cliente recebe o incremento do sistema funcional, podendo executar as funções dos requisitos já entregues. O processo de iterações é repetido até que o sistema fique completo. O modelo incremental é particularmente útil para lidar com sistemas que necessitam de mudanças nos requisitos, e sistemas que tendem a evoluir em grande escala (CRNKOVIC; LARSSON, 2002, p. 93). Uma vantagem no modelo incremental é a gerência de riscos técnicos, uma vez que a com- pilação do código fonte do software é executada em períodos mais curtos, conforme a definição do incremento, garante uma visão funcional da aplicação para a equipe de desenvolvimento. Isto serve como motivação e progresso do projeto, minimiza riscos de integração entre os mó- dulos do sistema e eleva a qualidade do processo (WANG, 2008, p. 85).
  29. 29. 29 Figura 5: Modelo de processo incremental Fonte: Crnkovic e Larsson (2002, p. 94) 2.2.3 Rapid Application Development Para Sommerville (2007), o desenvolvimento rápido de aplicações (RAD) é um modelo de processo de software incremental que enfatiza um ciclo de desenvolvimento curto. O modelo de processo Rapid Application Development (RAD) prevê o uso de softwares baseado em com- ponentes para minimizar o prazo de entrega do produto. Se um software pode ser modularizado permitindo que cada função principal seja concluída em menos de três meses, este software, é um candidato a utilizar como processo de desenvol- vimento de software o modelo RAD. Ainda, o projeto pode ser dividido em equipes RAD, e ao fim de cada fase, as equipes integram as partes moduláveis do software para formar apenas um sistema. Em sequência, aborda-se as fases do processo RAD (figura 6): a) Modelagem de negócio. O objetivo desta fase é obter o conhecimento do negócio do siste- mas. Para a modelagem de negócio são feitas algumas perguntas: Quais informações definem o processo de negócio? Quais informações são geradas? O que gera elas? Para onde vai estas informações? Quem será responsável por processá-las? b) Modelagem de dados. São mapeados quais informações serão necessárias para funciona- mento do negócio. Esta fase utiliza-se de conhecimento técnico para definir as caracte- rísticas dos objetos de dados que compõe a aplicação. c) Modelagem de processos. Os objetos de dados definidos na fase de modelagem de da- dos são transformados em prioridades para gerar fluxo de informações necessárias para implementar uma função de negócio. d) Geração de aplicações. No processo RAD, a linguagem de programação deve como requi- sito utilizar as técnicas de quarta geração. O objetivo principal é reutilizar os componentes de programas existentes ou criar componentes reutilizáveis.
  30. 30. 30 Figura 6: Modelo de desenvolvimento rápido de aplicações (RAD) Fonte: Sommerville (2007) e) Testes. Como o desenvolvimento é baseado em componentes, entende-se que muitos mó- dulos já estão testados, porém, para novos componentes, os testes são imprecindíveis em conjunto com as interfaces da aplicação. 2.2.4 Prototipagem Como a maioria dos modelos de processos da engenharia de software, a prototipagem tam- bém tem início com a comunicação (figura 7). Engenheiros e clientes se reúnem para definir os requisitos gerais do sistema. Como esta fase pode gerar muitas dúvidas quanto às necessida- des do cliente e funcionalidades do sistema, dá-se início ao protótipo do sistema (PRESSMAN, 2006, p. 42). O protótipo é uma versão preliminar e intencionalmente incompleta do propósito do sistema. As equipes que utilizam o modelo de prototipagem como processo de engenharia de software, acabam desenvolvendo a aplicação sobre a base do protótipo, que por esta vez, é gradual- mente melhorada até encontrar um nível de aceitabilidade para se transformar no produto final. Esta abordagem pode ser perigosa. Quando todo o sistema repousa sobre um núcleo inicial do software com objetivos de protótipo, poderão ocorrer surpresas desafiadoras. Como o pro- tótipo sofre mudanças desde o início do projeto para suprir uma visão funcional do sistema, são injetados códigos para satisfazer os novos requisitos em teste. Estas alterações funcionais
  31. 31. 31 Figura 7: Modelo prototipagem Fonte: Pressman (2006, p. 43) com adaptações nem sempre estão planejadas nos projetos, evidenciando um núcleo de sistema com possíveis problemas, como lentidão, segurança e extensibilidade (CRNKOVIC; LARSSON, 2002, p. 95). Os mesmos autores afirmam que o protótipo deve servir apenas como um mecanismo para identificar requisitos de software, e quando capturados, o protótipo deve deixar de existir, criando uma nova estrutura arquitetada para a aplicação real. 2.2.5 Modelo espiral Pressman (2006, p. 44) entende que o modelo espiral derivou da combinação de dois outros processos: prototipagem e cascata. Esse modelo foi concebido primordialmente para responder aos pontos fracos do modelo em cascata, a melhoria principal do processo foi a implantação de alternativas para gerenciar riscos do projeto, e se adaptar a mudanças nos requisitos durante o desenvolvimento de soft- ware. O modelo se concentra sobre rotações de fases e atividades do processo, seguindo sempre de forma incremental em ordem de prioridade. Cada rodada é composta por quatro fases. Na figura 8 exemplifica dois projetos em execução sobre o modelo espiral, P1 está na atividade de análise de riscos associados aos requisitos, e P2 na fase da arquitetura do produto. Na primeira fase, a equipe define restrições, objetivos e buscam alternativas para problemas propostos. Durante a segunda fase a equipe foca no gerenciamento de riscos associados com as soluções definidas na primeira fase. Na terceira fase, a equipe necessita implementar um protótipo ou parte do sistema de forma que possam validar à funcionalidade. Na última fase, a preocupação da equipe é planejar a próxima rodada com base nos resultados produzidos na
  32. 32. 32 rodada atual. Geralmente realiza-se uma revisão envolvendo todos os participantes do projeto, incluindo desenvolvedores, clientes e usuários (BRUEGGE; DUTOIT, 1999, p. 477). Cada rodada inclui as seguintes atividades: a) Determinar os objetivos. b) Especificar restrições. c) Gerar alternativas. d) Identificar os riscos. e) Resolver os riscos. f) Desenvolver e avaliar o produto no próximo nível. Figura 8: Modelo espiral Fonte: Bruegge e Dutoit (1999, p. 478) Um grande problema que atinge a engenharia de software é o gerenciamento de risco. Nesta condição, o modelo espiral torna-se realista por tratá-lo com atenção a cada ciclo do processo. Conforme o projeto de software progride, o processo no modelo espiral cresce em conjunto tornando-se um avanço compartilhado (PRESSMAN, 2006). 2.2.6 Rational Unified Process O modelo de processo Rational Unified Process (RUP) de tradução processo unificado da Rational, foi proposto na década de 90 por James Rumbaugh, Grady Booch e Ivar Jacobson.
  33. 33. 33 No início da década, esses autores constituíram um modelo combinando as melhores caracte- rísticas dos métodos de modelagem de sistemas existentes, e opiniões de outros especialistas no assunto. O resultado foi a Unified Modeling Language (UML) linguagem de modelagem uni- ficada. Porém a UML não é um processo, ela apenas fornece tecnologia necessária para apoiar modelos e arquitetura de sistemas na engenharia de software. Cinco anos mais tarde, nova- mente Rambaugh, Booch e Jacobson coletaram algumas métricas da UML com a junção de melhores práticas dos processos existentes de software, e criaram o processo unificado. O modelo tem ênfase na comunicação com o cliente, esta afirmação pode ser melhor es- clarecida com o uso de diagramas de casos de uso, sendo um método da UML de levantamento de requisitos utilizado no processo unificado. O cliente é muito importante para o processo, ele deve estar sempre próximo de todas as atividades de desenvolvimento da aplicação. A arqui- tetura do sistema deve suprir as funcionalidades com base nas necessidades do cliente, para isto, a aplicação deve permitir receber mudanças de requisitos e alterações de escopo de forma flexível (PRESSMAN, 2006). Sommerville (2007) explica que o RUP está dividido em quatro fases discretas: a) Concepção. Objetivo de identificar todas as entidades externas, como pessoas e sistemas que farão de certo modo interação com a aplicação. Esta fase também prevê a definição de interação dos autores com o sistema, como casos de uso simplificados. b) Elaboração. Objetivo de absorver o entendimento do domínio do problema e transpassar aos integrantes da equipe. Determinar a arquitetura do sistema, framework, plano de projeto, riscos, e evoluir os requisitos. c) Construção. Objetivo de construir o software. Esta fase deve abordar o desenvolvimento, testes e documentação da aplicação. d) Transição. Objetivo de transferir o software da fábrica para os usuários finais. Nesta fase acontece a implantação do sistema, onde a aplicação deverá funcionar corretamente em seu ambiente operacional. Pádua (2009) explica como o processo unificado é executado. a) Abstrai requisitos e funcionalidades através de diagramas de casos de uso. b) Tem objetivos claros de arquitetura de sistema centralizada. c) Seu processo segue de forma interativa e incremental. O ciclo de vida da aplicação, com base no RUP, deve herdar as características do modelo espiral por se tratar de ciclos de desenvolvimento.
  34. 34. 34 Uma das diferenças do RUP em relação aos outros processos, são as atividades divididas em subprocessos chamados de fluxos de trabalho. As fases definem divisões gerenciais, e as atividades de fluxos de trabalho atingem metas bem definidas como: requisitos, análise, desenho, implementação e testes. A figura 9 demonstra como segue o modelo de processo unificado. Ele pode ser descrito em duas dimensões, ou ao longo de dois eixos: a) O eixo horizontal representa o tempo e demonstra o processo expresso em termos de ciclos, fases, iterações e marcos. b) O eixo vertical representa o aspecto estático do processo. Descrito em termos de atividades, artefatos, colaboradores do projeto e fluxos de trabalho. Figura 9: Modelo de processo unificado (RUP) Fonte: Rational (2001, p. 3) 2.3 METODOLOGIAS ÁGEIS Marsic (2009) entende que metodologia ágil é uma filosofia de desenvolvimento focada em resultados, funciona de forma iterativa, e conta com gerência de riscos e mudanças. Sua principal característica, é envolver ativamente os clientes no processo de desenvolvimento da aplicação. Quando se trata de artefatos produzidos, atende-se absolutamente os mínimos ne- cessários para o projeto.
  35. 35. 35 Sommerville (2007) explica as causas da criação da metodologia ágil. Segundo ele, na década de 80 e 90 o desenvolvimento de software praticamente se baseava em rigorosos pro- cessos de especificação, planejamento, garantia de qualidade formalizada e métodos de análise através de ferramentas Computer-aided Software Engineering (CASE). Esta visão se dava em consequência de softwares críticos de grande escala necessários naquela época. Contudo, quando aplicado os mesmos processos de desenvolvimento em empresas de pequena e mé- dio porte, observou-se um grande atraso nas fases do projeto. O tempo gasto nos processos iniciais até a chegada do desenvolvimento e teste, ultrapassava-os em conjunto. Os problemas geraram insatisfação para a comunidade dos desenvolvedores na década de 90, e então, na luta para resolvê-los, criaram os conhecidos métodos ágeis. O foco proposto era a concentra- ção total no software como aplicação funcional no cliente, em vez de árdua documentação e detalhamento de projeto Mais tarde, em fevereiro de 2001, dezessete figuras importantes da tecnologia ligadas à metodologias ágeis, se reuniram no estado de Utah (EUA) para discutirem maneiras de criar softwares mais compreensíveis para o cliente, além de serem mais rápidos de desenvolvimento. Estas pessoas então identificaram alguns princípios para as metodologias ágeis, com isso, foi criado o manifesto ágil (BECK et al., 2001). Os princípios estão destacados a seguir: a) Nossa maior prioridade é satisfazer o cliente através da entrega contínua e antecipada de software com valor agregado. b) Mudanças nos requisitos são bem-vindas, inclusive as incluídas ao mais tardar do desen- volvimento. Processos ágeis tiram proveito de mudanças visando vantagem competitiva para o cliente. c) Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. d) Pessoas de negócios e desenvolvedores devem trabalhar diariamente em equipe por todo o projeto. e) Construir projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie na equipe para executar o trabalho. f) O método mais eficiente e eficaz de transmitir informações entre uma equipe de desenvolvi- mento é através de conversa face a face. g) Software funcionando é a medida primária de progresso.
  36. 36. 36 h) Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvol- vedores e usuários devem ser capazes de manter um ritmo constante de proveito. i) Atenção contínua à excelência técnica e boa arquitetura aumentam a agilidade. j) Simplicidade é essencial. k) As melhores arquiteturas, requisitos e análises emergem de equipes auto-organizáveis. l) Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento para o progresso. Como este trabalho não tem objetivos específicos de detalhar as metodologias ágeis, adi- ante serão conceituadas algumas metodologias ágeis de maior abrangência nos dias atuais. 2.3.1 Extreme programming Dentre as metodologias ágeis, o XP possui uma característica bem diferenciada, chamada de programação em pares, onde dois desenvolvedores trabalham na mesma máquina lado a lado, fornecendo apoio de validação e verificação em tempo real no código desenvolvido. Dentre as atividades realizadas na metodologia XP (figura 10), destaca-se a atividade de requisitos de software, que são expressos em histórias de usuários, que por fim acabam se tornando várias tarefas. Já na etapa de desenvolvimento, antes de qualquer implementação das novas funcionalidades, o desenvolvedor primeiramente escreve os testes unitários. Figura 10: Atividades da metodologia XP Fonte: Wells (2009)
  37. 37. 37 Assim que os testes unitários estejam programados para validar as funcionalidades, a me- todologia indica a próxima etapa de desenvolvimento: a implementação das funcionalidades da tarefa, porém, no início desta fase ainda não temos código desenvolvido, com isto, o teste começa reprovando a funcionalidade, e o desenvolvedor programará o código até que seja fun- cional (SOMMERVILLE, 2007). Desde o primeiro uso da metodologia, observaram-se benefícios agregados à equipe de desenvolvimento e ao produto final por meio da satisfação do cliente. O XP prevê entregas de software com frequência em ciclos pequenos de tempo, de forma iterativa e incremental. Valoriza o trabalho em equipe, onde gerentes, clientes e desenvolvedores são todos parceiros de igual grau hierárquico, porém com diferentes responsabilidades (WELLS, 1999-2009). 2.3.2 Scrum Schwaber e Sutherland (2010) explicam que a metodologia Scrum é determinada para o controle de processos empíricos otimizado, trabalhando de forma iterativa e incremental. Martins (2007) expõe Scrum como um processo para gerenciar e controlar projeto de de- senvolvimento de softwares, ainda o autor explica que Scrum é uma metodologia ágil, e se concentra realmente no que é importante, focando na gerência de projetos com atruibuto de va- lor ao produto desenvolvido e, prazo e custos propostos no planejamento. O modelo do Scrum é representado na figura 11. Figura 11: Modelo de processo da metodologia SCRUM Fonte: Martins (2007, p. 270) com adaptações O Scrum não é apenas uma metodologia ágil, é considerado um framework, que consiste na junção de pessoas na formação de times. Os integrantes deste time estão divididos em três papéis; scrum master, responsável por garantir que o processo seja compreendido pela equipe seguindo regras e práticas do Scrum; product owner, responsável pelo gerenciamento
  38. 38. 38 do product backlog e prioridades; time, conjunto de desenvolvedores que transformam o product backlog em incrementos entregáveis no sistema a cada sprint. O time não está limitado a ter apenas programadores, entre os membros são encontrados pessoas com conhecimentos específicos como: controle de qualidade, análise de negócios, arquitetura, projeto de interface de usuário e banco de dados. Como metodologia ágil, o Scrum entrega seus incrementos de software através de iterações no processo. O product backlog é uma lista com requisitos priorizados de tudo que pode ser necessário á aplicação, já o sprint backlog é uma lista de tarefas para transformar ítens do product backlog em uma sprint. A sprint é o prazo de um mês ou menos de duração de esforço de desenvolvimento que gera uma iteração e incremento no software. Uma prática utilizada pelo Scrum é empregar eventos com duração fixa, os time-boxes sendo a reunião de planejamento da release, reunião de planejamento da sprint, a sprint, revi- são da sprint, retrospectiva da sprint e daily scrum. Dentre os eventos, o daily scrum recebe destaque pela quebra do paradigma que reunião deve-se durar muito tempo. Seu objetivo pro- põem fazer uma reunião diariamente de no máximo quinze minutos no mesmo horário e mesmo local. Nesta reunião os participantes devem responder três perguntas: a) O que realizou desde a última reunião? b) O que vai fazer antes da próxima reunião? c) Quais os obstáculos estão em seu caminho? O daily scrum não é uma reunião de status. Ela tem por objetivo a comunicação, eliminar outras reuniões, identificar e remover impedimentos para o desenvolvimento. O Scrum, sem dúvida, ganha novos admiradores a cada dia, suas regras garante uma qualidade controlada aliada ao prazo de entrega bem definido. A equipe luta como um time, unindo forças para manterem suas metas e batalhas para conquistarem a vitória. O resultado do projeto, construído através da metodologia Scrum, é prazo certo, custo reduzido, qualidade controlada e satisfação do cliente. 2.3.3 Crystal Cockburn (2000) relata que Crystal não é necessariamente uma metodologia, e sim uma família de metodologias. O autor explica o funcionamento do Crystal através do mapa família na figura 12. Para cada projeto de software, na etapa de planejamento, estimasse uma quantidade de pessoas para suprir o ciclo de desenvolvimento, este parâmetro define o movimento no eixo X, ou seja, movendo para a direita no mapa Crystal. Este procedimento navegará pelas
  39. 39. 39 colunas que contém a quantidade de pessoas relacionadas com a necessidade de cada projeto, ao encontrar a coluna que satisfaz a condição do projeto, lhe retornará uma cor que propõe a metodologia adequada para uso. Entretanto, o Crystal não trata somente do número de pessoas, há também a relação de custos e riscos do projeto, esta necessidade de mensuração se dá ao eixo Y, ou seja, movendo para cima. Encontramos os seguintes enquadramento de custos e riscos do projeto: a) Confort. Confortável, poucos riscos e recursos financeiros sustentáveis. b) Discretionary money. Discreto, onde custos e riscos devem serem calculados com mais ênfase. c) Essential money. Essencial, orçamento limitado, riscos altos. c) Life. Projeto com riscos extremos, deve ser desenvolvido por especialistas. Figura 12: Metodologia Crystal - mapa da família Fonte: Crystal (2010) As duas regras mais comuns para a família Crystal são: O processo de desenvolvimento do projeto deve usar o modelo incremental com incrementos de quatro meses ou menos, e a equipe deve realizar antes e após o projeto, oficinas de reflexão das expectativas esperadas e resultados obtidos.
  40. 40. 40 2.4 REUSO DE SOFTWARE Segundo Sommerville (2007), a engenharia de software baseada em reuso de software é uma abordagem de desenvolvimento que visa a maximizar a reutilização das funcionalidades de software já existente. Na concepção de reutilização de software, classifica-se como reuso de um produto completo incorporado a outro software através de configurações, adaptações e integrações. Seguindo esta linha de raciocínio, na visão de componentes, define-se como a reutilização de subsistemas incorporados ao domínio da aplicação e reutilização de objetos e funções especificados como rotinas operacionais, servindo de execução para uma determinada tarefa interna no sistema. O reuso apresenta como vantagem a redução de custos totais no desenvolvimento, pois poucos componentes de software terão a necessidade de serem especificados, projetados, implementados e validados, ficando somente com o trabalho de adaptações das interfaces e integração dos subsistemas. Reuso de software não tem somente como benefício a redução de custos de desenvolvimento. Abaixo são pontuados alguns ítens para firmar a real vantagem desta prática. a) Confiança aumentada. Considerada devido à expectativa de um software estar experimen- tado, testado, estável e funcional. O software reusável deve estar estruturado para compor todas estas qualidades. b) Conformidade com padrões. Os softwares produzidos para fins de reutilização são estrutu- rados das melhores práticas de software, chamado de Design Patterns. Este benefício garante extensibilidade e qualidade das funcionalidades. c) Desenvolvimento acelerado. Ganho de velocidade com desenvolvimento por apenas tratar de integração e adaptação de subsistemas na aplicação. O software final ganha o mer- cado em prazo reduzido. No entanto, há custos evidentes com o reuso, como, por exemplo, ao buscar no mercado um componente para suprir uma necessidade no sistema há de certo modo um custo significativo em entendimento do componente ser adequado para a situação, gastos com conhecimento das funcionalidades do componente, e se o componente é confiável e extensível assegurando que não haverá problemas futuros. Na engenharia de software, o reuso é apoiado por algumas práticas que geram base es- trutural para reutilização. As mais frequentes usadas são: Design Patterns, desenvolvimento baseado em componentes, framework de aplicações, sistemas orientados a serviços, integra- ção de COTS, bibliotecas de programa, geradores de programa e desenvolvimento de software
  41. 41. 41 orientado a aspectos. O reuso pode ser incluso em todos os processos de software devido a grande gama de práticas possíveis. Porém nem sempre ele é tratado como vantagem, a auto estima dos engenheiros de softwares de não reutilizar este benefício, leva-o a criar sempre uma nova aplicação partindo do zero. Isto evidencia a enorme quantidade de tempo para entrega de um projeto. Trazendo a discussão para o contexto atual, vale dizer que a ESBC veio para solucionar grande parte destes problemas (SOMMERVILLE, 2007). 2.4.1 ESBC como solução de reuso de software A ESBC surgiu no final da década de 1990, ou seja, pouco mais de 20 anos. É uma área que envolve alta complexidade para desenvolvimento de softwares, pois trata de analisar o software com objetivos de reuso, em partes ou totalmente. Teve início quando o desenvolvimento de softwares orientado a objetos se tornara especialista; as classes dos objetos eram criadas de tal forma que para utilizá-las deveria conhecê-las detalhadamente, o desenvolvimento era focado para aplicações especialistas dos clientes, o qual não tinha êxito quanto ao reuso de software (SOMMERVILLE, 2007). Essa área dedica-se a trabalhar com componentes de softwares, englobando as atividades de: definição, implementação, integração ou composição de componentes independentes desa- coplados do sistema. Sommerville (2007) explica que os softwares estão cada vez mais se tor- nando complexos, e os clientes cada vez mais exigentes quanto às garantias de confiabilidade e rapidez no recebimento do produto. Uma das saídas para tal comportamento da atualidade é utilizar e reusar componentes em maior escala do que reimplementar as funcionalidades no sistema. Dessa forma, o produto ganharia a qualidade e estabilidade de um componente já implementado e maduro, também reduziria o tempo de desenvolvimento do sistema como um todo. Sommerville (2007) define alguns pontos cruciais para um projeto de sucesso usando ESBC. a) Componentes independentes completamente especificados e documentados. As interfaces devem ser bem definidas e coerentes com cada conjunto de classes. O componente deve ter uma clara separação entre interfaces e implementação para que possa ser substituído do sistema sem causar mudança alguma. b) Padrões de componentes para compatibilidade entre os sistemas. Se o desenvolvimento seguir os padrões de componentes, o componente escrito em certa linguagem poderá ser usado em qualquer outra que aceite estes padrões. Para isso acontecer, no mínimo a arquitetura do componente deverá dispor das interfaces de implementação.
  42. 42. 42 c) Middleware como fornecedor para integração de componentes. Trata-se de uma aplicação que gerencia a integração entre os componentes independentes e distribuídos. O mid- dleware fica responsável pela manipulação da comunicação, fornece apoio à alocação de recursos, gerenciamento de transações, proteção e concorrência dos componentes. d) Processo de desenvolvimento através da ESBC. Todo desenvolvimento deve seguir os pro- cessos da ESBC com foco em reuso de software. Como todo projeto não está livre de riscos, a seguir estão listados alguns problemas que devem ser evitados e levados a sério. a) Confiabilidade de componentes. Sommerville (2007) deixa claro em sua literatura, que com- ponentes são fechados quanto ao seu código fonte, considerados caixas pretas na área da engenharia de software. Neste caso, não tem como detectar um possível problema no componente através da análise do código fonte. O sistema que recebeu a implementação do componente poderá comportar-se de uma maneira diferente da proposta na documen- tação, e a causa poderia ser uma falha no componente. Este é um dos maiores desafios da ESBC. A solução para o problema perante à ESBC é criar componentes maduros livres de falhas e documentar suas funcionalidades e comportamentos esperados. b) Certificação de componentes. Totalmente relacionada à confiabilidade do componente. Se- gundo Sommerville (2007), infelizmente ainda hoje não há uma instituição que garanta que um componente se comportará em todos os parâmetros conforme seu funcionamento proposto. c) Previsão de propriedade emergente. Refere-se ao propósito das funcionalidades dos com- ponentes. Muitos componentes são desenvolvidos com foco em sistemas especialistas, e quando são reutilizados em outros projetos, acabam limitando os novos sistemas. d) Compromissos de requisitos. Na busca de componentes que suprirão as necessidades dos requisitos, há a necessidade de um método de análise estruturado e sistemático para ajudar o projetista selecionar e configurar componentes. Deve dar muita atenção aos requisitos, uma prática para eleger componentes é juntar os requisitos similares e assim analisar um componente que atenda o conjunto de requisitos (SOMMERVILLE, 2007). 2.4.2 Processo da ESBC O processo da ESBC, como na maioria dos processos da engenharia de software, inicia-se com as definições dos requisitos do sistema, que é uma abordagem geral das funcionalidades e
  43. 43. 43 necessidades da aplicação. Na etapa seguinte, dá-se início à arquitetura e análise do sistema. Após esta etapa, em vez de passar para o detalhamento das tarefas do projeto, a equipe es- tuda e interpreta dentre os requisitos quais são adequados à junção de operações e quais são dependentes uns dos outros, para assim separá-los em negócios bem definidos. Além deste estudo, Sommerville (2007) explique que a equipe deve gerar os seguintes questionamentos: a) Componentes comerciais prontos para uso, chamados de COTS, estão disponíveis para implementar o requisito? b) Componentes reusáveis, internamente desenvolvidos e aprimorados em outros projetos con- cluídos, estão disponíveis para implementar o requisito? c) As interfaces dos componentes disponíveis possuem compatibilidade com o sistema a ser construído? Após ocorrer a avaliação dos requisitos que serão atendidos com uso de componentes COTS ou internos, o processo ganha novas atividades: busca de componentes, seleção de componentes e validação de componentes. Esta etapa do processo pode ser resumida con- forme a figura 13. Figura 13: Processo da ESBC Fonte: Sommerville (2007, p. 298) Por fim, o processo passa para o desenvolvimento baseado em componentes, seguindo as atividades de: qualificação, adaptação, composição e atualização. Os requisitos não atendidos pelos componentes disponíveis, receberão as implementações com objetivo de futuro reuso do software (PRESSMAN, 2006). Adiante, na figura 14 ilustra um modelo genérico de processo da engenharia de software baseada em componentes. O modelo se divide-se em duas partes: a) Engenharia de domínio. Define o conceito de negócio do software, usado para analisar a aplicação em forma de requisitos, coleta de componentes existentes e reutilização código gerado.
  44. 44. 44 b) Desenvolvimento baseado em componentes. Define a arquietura do software baseada em componentes, framework, padrões de projeto e comportamentos. Figura 14: Modelo de processo da ESBC completo Fonte: Pressman (2006, p. 666) 2.4.3 Componentes de prateleira (COTS) As empresas, que desenvolvem componentes comerciais de prateleira, têm a finalidade de comercializar software como um subsistema ou componente. Elas são especializadas em desenvolver softwares componentizados, estruturam suas aplicações e funcionalidades em mó- dulos de fácil integração e extensão por meio de interfaces. Os componentes desenvolvidos partem de um domínio definido de aplicação ou funcionalidade específica. Para o uso do componente adquirido, o pacote comercial deve dispor de interfaces bem documentadas para que a aplicação implemente a integração com o componentes e possibilite a extensão de novas funcionalidades. Algumas empresas também comercializam seus compo- nentes em conjunto com o código fonte, porém este negócio envolve contratos de garantia de
  45. 45. 45 propriedade da empresa desenvolvedora, sendo utilizado apenas para interpretação e conheci- mento interno da arquitetura do componente. As vantagens de utilizar COTS, na aplicação em desenvolvimento, estão relacionadas com o reuso de componentes, cujos benefícios mais evidentes são a redução de custo e entrega do projeto. Um projeto de software pode utilizar vários componentes COTS de diversos fornece- dores, como pré-requisito os componentes deverão dispor de interfaces, e serem compatíveis com a plataforma de desenvolvimento (SOMMERVILLE, 2007). Contudo, trabalhar com componentes de terceiros possibilita em maior escala os problemas imprevistos. A falta de controle sobre a funcionalidade e desempenho do componente, pode invalidar um requisito do sistema. A dificuldade de suporte e entendimento das funcionalidades poderão gerar desconforto e abandono do recurso. De qualquer forma, os pontos positivos de utilizar COTS sobressaem os pontos negativos, visto que tratam dos fatores de maior impacto nos projetos, tempo e custo (SOMMERVILLE, 2007). Apresentou-se nesta, etapa do trabalho, a estrutura conceitual da engenharia de software com objetivo de reuso de software, porém, não foi comentado até o momento, sobre como construí-los em um processo definido dentro da ESBC. No próximo capítulo, será contextuali- zado o processo de desenvolvimento de software Catalysis que, por sua vez, tem objetivo de construir softwares componentizados e reutilizáveis.
  46. 46. 46 3 CATALYSIS Catalysis fornece um processo sistemático para a construção de modelos precisos no de- senvolvimento de componentes (D’SOUZA, 1998). Em outras palavras, determina métodos para construir softwares componentizados para reuso. Este termo foi ditado na literatura de 1992 pelos autores Desmond D’Souza e Alan Wills. É derivada da palavra catálise, significando um processo em que reações ocorram de forma mais eficaz. Esta definição foi estudada e com- provada pela área química. Porém, no contexto da modelagem de sistemas e desenvolvimento de software, o nome descreve uma abordagem que torna o processo de desenvolvimento mais repetitivo, escalável e eficaz (CATALYSIS, 1998). Para D’Souza e Wills (1998), o método Catalysis é um conjunto de padrões de processos. Eles justificam que como todos os processos, não há um processo individual que englobe to- das as necessidades de um projeto. Para isso, sempre há mesclas de atividades e conceitos de outros processos embutidos. Embora, possua esta complexidade, o processo Catalysis é composto por um núcleo simples, abrangendo três níveis de modelo de escopo (domínio de negócio, especificação de sistema, arquitetura do componente), três construções básicas de modelagem (colaboração e comportamento, tipo, refinamento), e a aplicação de três princípios fundamentais (abstração, precisão, partes plugáveis). O passo seguinte é analisar e modelar o sistema em volta do núcleo. Esses autores ressaltam algumas características que o modelo Catalysis prescreve para construção de um software bem elaborado. a) Baseado em componentes: Desenvolvimento através da construção de produtos a partir de kits de componentes interoperáveis. Pode-se separar o projeto de componentes em três grandes áreas: kit de arquitetura, define normas de interconexão comum; desenvolvi- mento de componentes, especificação cuidadosa e arquitetura de software reutilizáveis; montagem do produto, rápido desenvolvimento de produtos finais a partir de componen- tes. b) Ciclos curtos: Recomendam a utilização do modelo RAD princípio de desenvolvimento rá- pido de aplicações. Trabalhando com ciclos curtos de desenvolvimento, o projeto recebe um andamento mais palpável, com visões bem definidas de cada fase, isto agrega bene- fícios à equipe, que, por sua vez, é motivada a mover-se para próxima fase. c) Desenvolvimento em fases: Construção de uma pequena fatia do sistema o mais cedo possí- vel, a fim de obter feedback antecipado do cliente e construção do restante gradualmente em torno do núcleo.
  47. 47. 47 d) Grau variável de rigor: Descrever as pós-condições dos casos de uso em um estilo formal, ou opcionalmente em linguagem natural. O mais alto rigor na descrição ajudará a encontrar problemas mais cedo. e) Fase de análise robusta: A construção de modelos de negócios e requisitos, no processo Catalysis, abrange mais do que no estilo convencional. No Catalysis, as decisões impor- tantes estão centralizadas em diagramas. Como resultado, há menos trabalho posterior na fase de concepção e manutenção do ciclo de vida do software. f) Maturidade organizacional: Dependendo da maturidade da equipe, existem diferentes for- mas de adotar o processo Catalysis. Se o time está acostumado a um processo repetitivo com resultados definidos e prazos curtos, a adoção do processo é plenamente aconse- lhável, caso contrário, a equipe deve começar a aprender as notações técnicas do Cataly- sis, de modo a serem capazes de se comunicar com eficácia com todos os integrantes. Neste contexto, a equipe ousaria criar novas aplicações e migrar seus projetos para novos conceitos moduláveis, utilizando de todos os artifícios e benefícios do desenvolvimento baseado em componentes. Além das características, D’Souza e Wills (1998) expõem o modelo Catalysis em métodos e técnicas utilizadas na engenharia de software. Os métodos são abordados para diversos objetivos: a) Desenvolvimento de software baseado em componentes. Definir com precisão interfaces independentes para implementação, construir arquitetura de componentes e conectores, garantir a conformidade do componente com os conectores. b) Integridade da arquitetura do componente. Precisão nas especificações abstratas e garantia dos objetivos de negócio. c) Projeto orientado a objetos. Código legível, técnicas de caso de uso para transformar modelo conceitual em código orientado a objeto centrado em interfaces. d) Reengenharia. Técnicas para compreensão de software já existentes e concepção de novos softwares utilizando o legado funcional. Ao se tratar de um processo de desenvolvimento de software utilizando o Catalysis, são permitidas inúmeras variações. Como o foco do modelo é disponibilizar formas precisas de construir componentes e sistemas moduláveis, não existe somente um processo definido. Para este trabalho, o processo utilizado terá base em D’Souza (1998), que explana um processo de maior abrangência nas empresas que atualmente utilizam o Catalysis. Desta forma, a seguir,
  48. 48. 48 será desmembrado o núcleo do Catalysis em três formas de descrever como utilizar o modelo e o processo abordado. 3.1 MODELO DE ESCOPO Os modelos utilizam-se de intenso uso da diagramação UML para satisfazer todas as eta- pas definidas no processo. Entretanto, alguns diagramas UML sofreram alterações para se adaptar ao contexto do processo de especificação (OLIVEIRA; PAULA, 2009). Como mencio- nado anteriormente, uma parte do núcleo do Catalysis é composta por três níveis no modelo de escopo. Na figura 15 exemplifica a estrutura do modelo. Figura 15: Modelo de escopo Fonte: D’Souza (1998, p. 5) O primeiro item do escopo, determina a concentração no domínio do problema ou de ne- gócio. Nele estão inclusos todos os conceitos relevantes coletados através das reuniões de requisitos feito com o cliente, bem como deve ser mapeado todo o problema e identificar o domínio da aplicação. No segundo item do escopo, fica centrado na especificação do componente ou do sistema em conjunto com comportamentos externamente visíveis. Nesta modelagem, haverá a neces- sidade de identificar as fronteiras, construir diagramas, e firmar todas suas ligações com outros objetos. O objetivo de um componente é sempre estar desacoplado da aplicação, sendo imple- mentado apenas através do uso de suas interfaces públicas conectadas ao sistema. No terceiro e último item do escopo, define-se o projeto interno do componente e a arqui- tetura lógica do sistema. Nesta etapa do processo, há a preocupação de especificar o com-
  49. 49. 49 portamento de cada objeto, sua comunicação e colaboração através de mensagens, interfaces externamente disponíveis e interfaces necessárias para o funcionamento. Nos requisitos não funcionais define-se qual a tecnologia a ser utilizada, desempenho e confiabilidade (D’SOUZA; WILLS, 1998). 3.2 MODELO DE CONSTRUÇÃO Há três níveis no modelo de construção para o processo Catalysis. Conforme na figura 16, estão representados como: colaboração ou comportamento, tipo e refinamento. A colaboração representa os aspectos mais importantes do projeto, pois envolve as descrições de objetos e suas interações entre os grupos, com objetivo de definir um conjunto de ações que desempe- nharão trocas de mensagens, nela está contido os resumos e detalhes das interações entre os participantes. Para o tipo, se concretiza de forma bem definida a tipagem, atributos e operações visíveis externamente de um objeto. Já para o refinamento, é entendido como uma relação aprofundada entre conceitos definidos; a abstração de diferentes pontos de vistas devem ser mantidos e respeitados, porém em níveis de detalhes diversos. Um sinônimo usual para o refi- namento é dado como aperfeiçoamento, onde o detalhamento é aprofundado a cada tentativa de melhoria. Em Catalysis, o refinamento consiste em captar detalhes e abstrair o conteúdo proposto através de refatorações dos requisitos já especificados, finalmente, este repetitivo pro- cesso garante o código de execução em conformidade com os requisitos que o cliente solicitou (D’SOUZA; WILLS, 1998). Figura 16: Modelo de construção Fonte: D’Souza (1998, p. 6)
  50. 50. 50 3.3 PRINCÍPIOS FUNDAMENTAIS Neste tópico apresentam-se os princípios necessários para se efetuar um projeto, usando o Catalysis como processo de modelagem e desenvolvimento do sistema. Na figura 17, é repre- sentado um modelo contemplando os três níveis de princípios restritos: princípios de abstração, precisão e partes plugáveis de componentes moduláveis que devem ser respeitados na cons- trução da arquitetura do sistema. Figura 17: Princípios do Catalysis Fonte: D’Souza (1998, p. 7) O princípio de abstração tem foco na complexidade dos componentes. A abstração é utili- zada para descrever somente partes do sistema considerado de maior escala e complexidade, deixando detalhes não relevantes para outra etapa do projeto. Em um projeto como um fluxo de decisões, algumas decisões serão tomadas através de outras já especificadas, gerando uma dependência estrutural. Neste caso, como exemplo, não haveria sentido de criar tabelas de banco de dados antes de estabelecer as funcionalidades do sistema. O exemplo demonstra a inconsistência do projeto se tratado em ordem incorreta de eventos, consequentemente invali- dando o modelo do processo de software. No entanto, percebe-se que a abstração de qualquer informação pertinente ao sistema tem sua posição ordenada dentro do processo. Encontra-se em um projeto de desenvolvimento baseado em componentes algumas abstrações importantes, que incluem o modelo de negócio e regras, requisitos, modelo geral de interação e arquitetura do componente (D’SOUZA; WILLS, 1998). No princípio da precisão, a preocupação de analistas e arquitetos é especificar o máximo de funcionalidades possíveis para compor a aplicação. Como qualquer grupo de pessoas em discussão sobre um determinado assunto, há divergências entre cada integrante, e em um projeto de software isto não é diferente. Quantas vezes grupos de analistas e arquitetos de amplo conhecimento técnico discutem exigências sobre um produto, e saem com diferentes
  51. 51. 51 interpretações do problema a ser resolvido, mesmo que cerquem todas as lacunas passíveis de erros sempre existe um ou outro profissional que está em desacordo com a solução. Mas para um projeto de componentes, as dúvidas e desacordos devem serem sanadas, para isso a precisão das informações são refinadas ao máximo. Entra neste conceito a abstração do sistema, fornecendo aos colaboradores do projeto uma visão mais próxima da funcionalidade em execução. De qualquer forma, a insegurança quanto ao real funcionamento do requisito só é sanada quando o código for escrito. Consegue-se, com este princípio, expor as lacunas e inconsistências do projeto o mais cedo possível, permitindo uma reação da equipe contra os riscos identificados; os requisitos permanecem em monitoramento e testes através dos modelos desenvolvidos ao longo do projeto, servindo para auditoria, validação e verificação; por fim, a precisão das informações necessitam de um apoio ferramental, através das ferramentas Cases que controlam as informações de fluxo, alterações, controle de versões, e disseminação dos dados (D’SOUZA; WILLS, 1998). No último princípio do Catalysis, está especificado que os componentes devem ser cons- truídos como partes plugáveis. Esta abordagem pode ser considerada a mais importante entre todos os princípios, pois um componente deve ser plugável e adaptável o suficiente para po- der agrupar-se a outros componentes, ou ter suas funcionalidades estendidas para evolução do sistema. Os ganhos com este método de desenvolvimento são enormes, começando com a modularização de funcionalidades, confiança no módulo já estável que apenas é plugado ao sistema, reutilização de classes, uso de frameworks e padrões de desenvolvimento. Para softwares construídos sem a utilização de componentes bem definidos, primeiramente são in- flexíveis e representam uma deficiência quanto a mudança de requisitos, forçando a alteração bruta do código fonte da aplicação, e as vezes até impactando em outras funcionalidades que estavam totalmente livre de erros. Um componente bom, é aquele que pode plugar-se a uma grande variedade de outros componentes. Porém, para isto acontecer, só faz sentido se no pro- jeto do componente foi exatamente previsto quais interfaces de conexões integram com outros componentes plugáveis (D’SOUZA; WILLS, 1998). 3.4 PROCESSO CATALYSIS Conforme se verificou até aqui, o Catalysis, através de seus modelos e artefatos, disponibi- liza uma alternativa de estruturar um processo que se adapte a realidade das empresas, nessa perspectiva D’Souza e Wills (1998) aborda na figura 18 um típico processo que normalmente é utilizado como modelo de desenvolvimento Catalysis nas indústrias de softwares. Tem-se assim o ponto de partida para compreensão da construção de softwares e componentes utilizando Ca-
  52. 52. 52 talysis. É importante destacar que, neste trabalho, aborda-se o modelo de processo Catalysis apresentado a seguir. Figura 18: Modelo de processo Catalysis Fonte: D’Souza (1998, p. 76) 3.4.1 Requisitos Softwares são sistemas de computadores que implicitamente abstraem as regras de negó- cios para tratar de um objetivo específico, para tal análise, buscam-se subsídios para identificar as necessidades que uma aplicação deve conter. Pode-se afirmar, então, que requisitos de sis- tema ajudam a identificar e compreender o problema, bem como possibilita soluções propostas para enfrentá-lo. Em outro ponto de vista, requisitos são dispostos para compor as funcionalida- des do sistema, neste conceito, nos permite mapear entre visões internas e a visão natural para um cliente. Neste processo, requisitos estão desmembrados em duas atividades agrupadoras, o modelo de domínio, e o contexto do sistema. Uma aplicação é centralizada em um modelo de domínio, também conhecido como modelo de negócio ou domínio do problema. O domínio deve sempre refletir a visão do cliente (figura 19), como exemplo, um sistema de contas a pagar, é de domínio financeiro. Nas fábricas de softwares, quando os profissionais estão desenvolvendo suas aplicações, primeiramente necessitam conhecer quais os objetivos do software, assim como suas funcio- nalidades captadas através dos requisitos. Em sequência, buscam entender o software, e para isso vão atrás de profissionais que nem sempre são relacionados com a área de tecnologia da informação, mas sim que contenham o conhecimento do domínio e negócio da aplicação, isto é necessário pois os engenheiros de software estão preocupados com a construção do soft-
  53. 53. 53 Figura 19: Domínio do sistema com foco no cliente Fonte: D’Souza (1998, p. 77) ware e muitas vezes desconhecem regras conceituais de outras áreas do conhecimento como: contábeis, logística, etc. É inviável, em questão de tempo e custo, um engenheiro saber to- das as regras de cada sistema desenvolvido, porque uma fábrica de software normalmente não escolhe produto de negócio para desenvolver, apenas aceita o desafio e concretiza o desenvol- vimento do sistema. Por outro lado, existem empresas especializadas em desenvolvimento de sistemas com domínios específicos, neste caso, o conhecimento do negócio está na empresa e é frequentemente compartilhado entre todos os integrantes. Para este seguimento de mercado, a indústria de software é vista como uma especialista no domínio do negócio. A análise do domínio dedica-se na compreensão do ambiente em que um sistema irá re- sidir, bem como o papel da aplicação nesse ambiente. Em Catalysis, existem alguns artefatos para descobrir e refinar qual o domínio da aplicação. O primeiro artefato chama-se mapa con- ceitual conforme a figura 20, que expõem uma representação informal, entretanto estruturado de termos relacionados ao domínio. A notação é bem semelhante a um mapa mental, formado simplesmente de conceitos ou expressões com indicações de linhas interconectadas indicando a relação entre eles; pode-se também utilizar figuras ou desenhos para uma representação mais elaborada.
  54. 54. 54 Figura 20: Diagrama de mapa conceitual Fonte: D’Souza (1998, p. 79) com adaptações Outro aspecto que se pode ressaltar sobre artefatos de domínio é a construção de dicio- nários e glossários para o sistema, explicando os termos utilizados na modelagem do domínio. Conforme os incrementos do projeto avançam, os documentos também recebem novas comple- mentações. Durante o processo de desenvolvimento do sistema, há riscos quanto à rotatividade de pessoas, e para sincronizar as informações do projeto atual com novos colaboradores, os dicionários e glossários servem como base teórica e resolução de dúvidas para conhecimento dos termos usados no desenvolvimento da aplicação. O diagrama de contexto (figura 21) fica com a responsabilidade de representar a colabora- ção entre o sistema e objetos. Envolve a compreensão do papel do sistema em desempenhar suas funcionalidades no contexto de negócios. Frente a isso, deve-se observar que o diagrama deixa explícito a interação dos participantes, seus papéis e suas ações perante o sistema. O objetivo deste diagrama é captar todas estas informações para mapear o foco do sistema, ou seja, o domínio da aplicação. 3.4.2 Especificação do sistema Após a fase de requisitos, segue o processo de detalhamento de cada requisito através de análise e documentação. Os analistas possuem as responsabilidades de transpassarem o conhecimento de negócio para o detalhamento técnico. Os artefatos, que até agora eram so- mente detalhamento de negócio, dão lugar à especificação de operação dos objetos, protótipos de funcionalidades, especificação de interface do usuário, relatórios e outras funcionalidades que foram definidos para o sistema. A especificação do sistema, neste processo, é represen- tada pelos diagramas de cenário de uso, tipos e operações. O produto principal desta fase é a especificação do sistema em um único tipo de objeto como um componente.
  55. 55. 55 Figura 21: Diagrama de contexto Fonte: D’Souza (1998, p. 79) com adaptações Na figura 22 encontra-se um exemplo de como utilizar o diagrama de cenário de uso. O diagrama sempre é construído através de uma situação ou ação que possa ser efetuada no sistema. Como se constata, este diagrama aloca vários conceitos de artefatos já apresentados, o uso da colaboração entre os objetos é necessário para expressar o fluxo das mensagens, os tipos e operações também estão presentes no diagrama. Contudo, o objetivo do diagrama é detalhar a sequência de interações realizadas entre os participantes. Outro diagrama pertencente à especificação do sistema está exemplificado na figura 23. O diagrama em estudo fornece uma especificação centrada em um único tipo («type»). Para que isso aconteça, a descrição do modelo se baseia em termos de tipos de objetos, atributos e associações. O produto do diagrama é agrupar a especificação do sistema em um componente específico de negócio. 3.4.3 Arquitetura do sistema O processo Catalysis, abordado neste trabalho, possui uma etapa de definição de plata- forma do sistema em conjunto com arquitetura técnica e lógica. Nesta fase, são detalhados diagramas para fins de reconhecimento e limitação do ambiente de implantação, bem como, molda-se os diagramas de comunicação entre os componentes sendo gerenciados através de transações. Como exemplo, na figura 24, representa-se um modelo de plataforma do sistema requerido. A arquitetura física é, muitas vezes, negligenciada nos projetos pela incapacidade dos profis- sionais de prever certamente o ambiente e arquitetura necessária para o bom funcionamento
  56. 56. 56 Figura 22: Diagrama de cenário de uso Fonte: D’Souza (1998, p. 81) com adaptações Figura 23: Diagrama de tipo e operações do sistema Fonte: D’Souza (1998, p. 82) com adaptações
  57. 57. 57 do sistema. Nessa perspectiva, deve ser iniciada mais precocemente possível, observando a evolução do projeto e readequando sua estrutura. O sistema é composto por serviços agre- gados às funcionalidades para a execução da aplicação como um todo. Por este motivo, há a necessidade de apontar cada comunicação entre os componentes externos. Neste exemplo, foi utilizada uma arquitetura em camadas centralizada em um servidor, existindo uma camada separada para visualização, responsável pela interface do usuário; e outra camada para tratar de dados requisitados através de transações. O modelo apresentando tem objetivo de definir e estudar sobre a escalabilidade, desempenho, transmissão das informações, segurança, e entre outros requisitos não funcionais mapeados no sistema. Figura 24: Modelo da plataforma requerida do sistema Fonte: D’Souza (1998, p. 83) A arquitetura técnica ou lógica consiste em uma partição do comportamento da aplicação em componentes separados com base em critérios de reutilização de software, poder-se-ia dizer mais, que ela implementa a camada de negócio próprio como uma coleção de componentes de colaboração mantendo os tipos de objetos originais, porém, agora dividido entre componentes especificados para construção e componentes COTS. (figura 25). Assim, é facilmente verificá- vel que o diagrama se propõe a especificar as dependências entre os componentes, como a interface do usuário, servidores, objeto de negócios, bancos de dados, middlewares, serviço de log, exceções, padrões de projeto e ferramentas. Da mesma forma, pode-se dizer ainda que o diagrama serve para definir a tecnologia da arquitetura de componentes utilizadas, tais como: JavaBeans, COM - Microsoft, CORBA, etc. 3.4.4 Arquitetura interna dos componentes No modelo de processo de desenvolvimento de sistemas, utilizando o Catalysis, prezou- se, até agora, em estruturar a base da aplicação conceitual e técnica, transportando as regras de negócios e visão sistêmica para a arquitetura do software. É de importância acrescentar ainda que os modelos e diagramas criados, servem de guia para reforçar os objetivos de mo-
  58. 58. 58 Figura 25: Diagrama de arquitetura técnica do sistema Fonte: D’Souza (1998, p. 84) dularização dos componentes do sistema. Em contrapartida, não foi abordado nos diagramas anteriores um modelo que definisse o código de implementação, ou mesmo como utilizar as im- plementações das interfaces para comunicação dos componentes. Com o intuito de esclarecer esta etapa do projeto, o processo determina como auxílio o uso da diagramação exemplificada na figura 26. Figura 26: Diagrama de arquitetura interna de componente Fonte: D’Souza (1998, p. 86) Como se vê, no diagrama de arquitetura interna, os componentes individuais já estão es- tabelecidos com suas classes internas. Neste contexto a modelagem do digrama necessita expor o nível de interfaces de comunicação entre os componentes, respeitando os requisitos

×