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

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. 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. RINALDI J. T.. Artefatos gerados nos processos de desenvolvimento de soft-
ware Catalysis e UML Components
Joinville: SOCIESC, 2011/1.

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. Dedico este trabalho ao meu pequeno
grande filho Elyan, que me ensinou um
novo jeito de viver.

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. "Só sei que nada sei"
Sócrates (470 a.C. - 399 a.C.)

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. 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. 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. −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. 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. 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. 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. 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
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
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
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
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
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
[!htbp]
Figura 1: Primeiras cinco áreas do conhecimento
Fonte: Abran et al. (2004, c. 1, p. 8)

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
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
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
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
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
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
É 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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