tcc - engenharia de software baseada em componentes
TRANSCRIPT
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
JULIANO TIAGO RINALDI
Artefatos gerados nos processos de desenvolvimento de software Catalysis e UML
Components
Trabalho de Conclusão de Curso apresentado aoInstituto 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 doprofessor Paulo Rogério Pires Manseira.
Joinville
2011/1
RINALDI J. T.. Artefatos gerados nos processos de desenvolvimento de soft-
ware Catalysis e UML Components
Joinville: SOCIESC, 2011/1.
JULIANO TIAGO RINALDI
Trabalho de Diplomação sob o tíulo Ar-tefatos gerados nos processos de desen-volvimento de software Catalysis e UMLComponents, apresentado por Juliano Ti-ago Rinaldi, e aprovado em 07 de julhode 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]
Dedico este trabalho ao meu pequenogrande filho Elyan, que me ensinou umnovo jeito de viver.
AGRADECIMENTO
Agradeço a várias pessoas que participaram diretamente e indiretamente deste trabalho paratorná-lo realizado. Primeiramente, à minha esposa Janaina, por me apoiar e sacrificar-se quasesozinha nos cuidados com nosso pequeno filho Elyan; à minha mãe, que sempre acreditouno meu potencial e me deu forças para conquistar minhas vitórias; ao meu orientador, PauloManseira, por compartilhar seu enorme conhecimento de engenharia de software e dedicar seutempo 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 quealunos realizassem um trabalho de conclusão de curso de ótima qualidade; ao professor LuizCarlos Camargo, pelo auxílio, esclarecimento e motivação apresentada sobre este trabalho.
"Só sei que nada sei"
Sócrates (470 a.C. - 399 a.C.)
RESUMO
A engenharia de software trouxe organização e foco na qualidade para a construção desoftwares. 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 softwarepropôs a construção de softwares componentizados. Esta nova forma de construir softwaretrouxe 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 focona 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 desoftwares para construção de aplicações baseadas em componentes, com isto, o objetivo destetrabalho é 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 qualoferece subsídios para uma melhor especificação de software baseado em componentes. Apesquisa aplicada foi de caráter exploratório, utilizando como estratégia um estudo comparativoentre as etapas e artefatos dos processos citados.
Conclui-se, que é de grande importância a construção de softwares moduláveis, pois comisso, além da arquitetura do software manter uma estrutura flexível em forma de componentesde negócios, possibilita a evolução do software sem interferir no todo, aplicando a manutençãosomente no componente desejado. Por fim, o reuso de componentes trazem maior confiançapara a aplicação, pois como os componentes já estão desenvolvidos e operando em outrossoftwares, são considerados maduros, com bugs já corrigidos, proporcionando um aumento daqualidade do software.
Palavras-chave: Engenharia de Software. ESBC. Catalysis. UML Components.
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 beenbranching 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 gavethe 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-basedapplications, 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 artifactsgenerated in these processes, to identify which provides resources for a better specification ofcomponent-based software. The applied research was exploratory, using a comparative studybetween 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 businesscomponents, enables the software evolution without interfering the complete software, applyingthe maintenance only in the desired component. Finally, the components reuse bring greaterconfidence to the application, because as components are already developed and operating inother software are considered mature, with fixed bugs, providing a software quality increase.modeling software.
Keywords: Software Engineering. CBSE. Catalysis. UML Components.
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
−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
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
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
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
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
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
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
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
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 paraconverter 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
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
[!htbp]
Figura 1: Primeiras cinco áreas do conhecimentoFonte: Abran et al. (2004, c. 1, p. 8)
22
Figura 2: Últimas seis áreas do conhecimentoFonte: Abran et al. (2004, c. 1, p. 9)
Figura 3: Disciplinas relacionadas a engenharia de softwareFonte: Abran et al. (2004, c. 12, p. 1)
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
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
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 processointerativo no qual a própria ferramenta serve como meio de comunicação, comcada nova rodada de diálogo explicitando mais conhecimento útil do pessoalenvolvido.
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
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
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 cascataFonte: Sommerville (2007, p. 44) com adaptações
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
Figura 5: Modelo de processo incrementalFonte: 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
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
Figura 7: Modelo prototipagemFonte: 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
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 espiralFonte: 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
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
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
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
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 XPFonte: Wells (2009)
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 SCRUMFonte: 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
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
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íliaFonte: 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
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
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
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
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 ESBCFonte: 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
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 completoFonte: 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
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
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
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
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 escopoFonte: 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
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çãoFonte: D’Souza (1998, p. 6)
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 CatalysisFonte: 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
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
talysis. É importante destacar que, neste trabalho, aborda-se o modelo de processo Catalysis
apresentado a seguir.
Figura 18: Modelo de processo CatalysisFonte: 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
Figura 19: Domínio do sistema com foco no clienteFonte: 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
Figura 20: Diagrama de mapa conceitualFonte: 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
Figura 21: Diagrama de contextoFonte: 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
Figura 22: Diagrama de cenário de usoFonte: D’Souza (1998, p. 81) com adaptações
Figura 23: Diagrama de tipo e operações do sistemaFonte: D’Souza (1998, p. 82) com adaptações
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 sistemaFonte: 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
Figura 25: Diagrama de arquitetura técnica do sistemaFonte: 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 componenteFonte: 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
59
de colaboração e comportamentos especificados nas etapas anteriores do processo. Em ou-
tras palavras, cada componente da aplicação tem de ser concebido internamente como um
conjunto de classes que implementam as interfaces necessárias externamente. O projeto re-
sultante deve possibilitar a avaliação da arquitetura dos tipos de objeto, ou seja, a avaliação da
colaboração entre os componentes atualmente definidos, com o propósito de validar a coerência
da arquitetura baseada em componentes.
Neste capítulo abordou-se sobre as etapas e artefatos gerados no processo Catalysis. Adi-
ante apresenta-se outro processo que idealiza a construção de softwares baseados em compo-
nentes. Da mesma forma que o Catalysis, o processo seguinte chamado de UML Components
é composto de etapas e artefatos para especificação de componentes de software, gerando
como objetivo um software baseado em componentes reutilizáveis.
60
4 UML COMPONENTS
O processo de desenvolvimento de software UML Components, derivou-se de um conjunto
de conhecimento de dois personagens da área da engenharia de software: John Cheesman e
John Daniels, que tiveram a idéia de utilizar alguns artefatos da linguagem UML para construir
um novo tipo de processo de desenvolvimento de software baseado em componentes, com foco
na reutilização e modularização de software. Isto somente foi exposto à indústria de software
com a publicação do livro “UML Components - A Simple Process for Specifying Component-
Based Software” no ano 2000. Como o desenvolvimento baseado em componentes já não era
uma novidade, alguns anos antes, em 1998, o autor Clemens Szyperski havia publicado seu
livro “Component Software - Beyond Object-Oriented Programming” que serviu de base para os
posteriores desenvolvimentos de processos de software com foco na reutilização de software
(CHESSMAN; DANIELS, 2001).
De modo geral, o modelo de processo de desenvolvimento UML Components maximizou
forças para a especificação do software. Facilitou a etapa de desenvolvimento do código fonte,
e posteriormente deu subsídios para agilizar outras etapas em sequência, simplificando os in-
crementos no desenvolvimento da aplicação.
O desenvolvimento baseado em componentes, é diferente das abordagens anteriores dos
processos de software, na essência da especificação do software, há a necessidade de pla-
nejar a arquitetura do sistema desde o início do projeto, visando modularizar a aplicação em
componentes. Um componente tem uma responsabilidade bem definida no sistema, por este
motivo, a aplicação é uma reunião de vários componentes integrados através de interfaces de
comunicação. Quando um sistema é composto pela integração de componentes, as interfaces
dos componentes significam dependências de baixo acoplamento, ou seja, facilmente um com-
ponente pode ser trocado por outro sem causar grande impacto no código fonte, bastando, para
o novo componente, implementar as interfaces que o sistema dispõem.
4.1 PROCESSO UML COMPONENTS
Chessman e Daniels (2001) afirmam que o processo de desenvolvimento de software base-
ado em componentes utilizando o método UML Components, tem base estruturada no processo
RUP (2.2.6). Na figura 27 exemplifica as fases do processo RUP padrão. Poder-se-ia dizer que
o processo UML Components não está preso ao processo RUP. Como o núcleo é composto por
uma sequência de etapas e artefatos da UML, pode-se utilizar, de outros processos de software
para gerenciamento de riscos e workflow.
61
Figura 27: Modelo de Processo UML Components baseado no RUPFonte: Chessman e Daniels (2001, p. 27)
O método UML Components depende de algumas etapas básicas para ser utilizado em um
processo de desenvolvimento de software. Chessman e Daniels (2001) explicam as etapas e
os artefatos necessários para o desenvolvimento do software (figura 28).
Figura 28: Etapas e artefatos gerados no processo UML ComponentsFonte: Chessman e Daniels (2001, p. 32)
62
Na etapa de especificação de requisitos, encontra-se a tarefa de modelagem do conceito
do negócio, também compreendida como definição do domínio da aplicação. Nela, deve-se
criar um vocabulário contendo os termos utilizados no projeto, para que os profissionais da
área técnica e os clientes estejam entendendo as palavras mencionadas nas discussões. Ainda
na especificação, está incluso os diagramas de casos de uso, que por sua vez, delimitam os
aspectos funcionais dos requisitos do sistema. O caso de uso tem uma importância muito
grande, pois esclarece as interações do usuário com o sistema.
O modelo de tipo de negócio está entre as etapas de especificação de requisitos e arquite-
tura do sistema. Ele propõe formalizar o conceito de negócio captando exatamente os aspectos
e regras do domínio da aplicação. Já a especificação de interface está diretamente relacionada
com a arquitetura do sistema. Ela visa definir o contrato entre as classes para especificar a
comunicação entre os objetos. Na especificação de componentes, faz-se uso das interfaces já
especificadas. O objetivo é definir as necessidades dos componentes, ou seja, quais objetos
necessitam se comunicar para seu funcionamento, e definir quais suas ações serão disponibili-
zadas. Na geração dos artefatos da arquitetura dos componentes, fica com a responsabilidade
de descrever como tudo funcionará em conjunto, bem como, a interação entre os componentes.
O processo UML Components implementa três grandes estágios no desenvolvimento de
software baseado em componentes: identificação de componentes, interação entre componen-
tes e especificação de componentes (figura 29). Desta forma, ele pode ser utilizado sob a
supervisão de outros processos, desde que mantenham a compatibilidade com o workflow de
sua etapas. O princípio básico de desenvolvimento para o método, é restringir a codificação do
sistema de forma incremental.
4.1.1 Identificação de Componentes
Neste estágio, são gerados os artefatos: modelo de conceito de negócio ou domínio da
aplicação, e modelo de casos de uso. Seu objetivo é identificar conceitualmente um conjunto
inicial de classes respeitando o domínio da aplicação, e um conjunto inicial de funcionalidades
para pré-definir os componentes do sistema. Com estes dois passos, dá-se início a arquitetura
dos componentes.
O modelo de tipo de negócio é um artefato intermediário na transição deste estágio, no qual
as interfaces de negócio estão formadas por estes tipos. Ele também é usado posteriormente
na fase de especificação de componentes, como matéria-prima, para o desenvolvimento de
modelos de informação de interface.
Neste primeiro estágio, além de identificar as classes e objetos conceituais do sistema,
também efetua um primeiro filtro nas operações que precisarão ser suportadas pelo sistema.
63
Figura 29: Três estágios do processo UML ComponentsFonte: Chessman e Daniels (2001, p. 34)
De qualquer forma, as funcionalidades mapeadas apenas receberão um nome de identificação,
pois, assinaturas e outros detalhes serão adicionados em um estágio posterior.
Nos tópicos a seguir estão descritos os artefatos pertencentes a esta fase.
a) Modelo Conceitual de Negócio.
Conforme o título do modelo, percebe-se que ele está relacionado com o conceito de
negócio ou domínio da aplicação. Além disso, há que se atentar sobre o modelo, que
não é considerado um modelo de software lógico, mas sim, um modelo expressando as
informações existentes no domínio do problema em forma de negócio.
O objetivo principal do diagrama de domínio da aplicação, é capturar conceitos e identi-
ficar relacionamentos entre o mundo real do negócio e a aplicação em desenvolvimento.
No processo da UML Components, este artefato é representado através do diagrama
de classe da UML (figura 30), porém, o modelo idealiza a divisão de escopo do soft-
ware em partes independentes. Uma boa prática para construção do modelo, é usar
um estereótipo «concept» para cada classe, com isto, fica claro para toda a equipe de
desenvolvimento que o diagrama trata do modelo conceitual do sistema.
Este modelo, tipicamente serve para capturar classes conceituais e suas associações.
Quando se trata de associação de papéis no sistema, pode ou não terem a multiplicidades
64
Figura 30: Modelo conceitual de negócio ou domínio da aplicaçãoFonte: Chessman e Daniels (2001, p. 43) com adaptações
especificadas no modelo, também, há a possibilidade de colocar somente os atributos
mais importantes para esclarecer o relacionamento do negócio.
b) Modelo de Caso de Uso.
Segundo Bezerra (2006) o modelo de casos de uso é composto de atores, sistemas, sub-
sistemas e do relacionamento entre eles. O diagrama tem em especial função, a especi-
ficação de uma sequência de interações do sistema e agentes externos que o compõe.
O diagrama de caso de uso mostra as ações e operações que um ator executa sobre
o sistema (figura 31), sem revelar a estrutura e o comportamento interno da aplicação.
Além do diagrama, faz parte do modelo, a descrição de cada caso de uso gerado (figura
32). As narrativas de cada caso, detalham as operação executadas pelo ator. Ainda den-
tro das narrativas, uma boa prática é representar as pré e pós condições do caso de uso
selecionado, assim como, representar um fluxo alternativo de execução da operação caso
houver exceção.
Para Chessman e Daniels (2001) o modelo de casos de uso oferece a modelagem da
interação entre usuário e sistema. Os autores ainda explicam que na linguagem UML,
não há uma especificação bem definida de como construir os diagramas de casos de uso
e suas narrativas, assim, é possível adaptar o diagrama para uma visão que melhor seja
compreendida pela equipe de desenvolvimento.
Os participantes de um diagrama de casos de uso são: atores e funcionalidades do sis-
tema. Um ator é uma entidade que interage com o sistema, normalmente na representa-
ção de uma pessoa, porém, também é possível o ator ser um outro sistema de software,
65
Figura 31: Exemplo - diagrama de casos de usoFonte: Chessman e Daniels (2001, p. 46) com adaptações
Figura 32: Exemplo - narrativa gerada de um caso de usoFonte: Chessman e Daniels (2001, p. 46)
66
de qualquer forma, estes detalhes são ocultados, permanecendo somente as ações e
operações representadas por cada um deles perante o sistema. Dito de outra forma, o
sistema é visto como uma caixa preta, que aceita estímulos de atores e gera respostas
representadas na narrativa do caso de uso.
É importante distinguir entre o ator e o mecanismo de comunicação executado por ele no
sistema. Como exemplo, uma televisão contém um aplicativo que responde ações execu-
tadas por um controle remoto. No exemplo, o ator é uma pessoa qualquer. Ela aperta um
botão do controle para satisfazer uma ação desejada, neste caso, o botão apertado foi o
desligar. O sistema responde a ação do usuário e desliga a televisão. No diagrama de
caso de uso, não se deve preocupar com o mecanismo de comunicação, representado
no exemplo, pelo controle remoto que funciona através da comunicação de um sensor
infravermelho com a televisão. O modelo apenas deve-se focar nos estímulos e respos-
tas da operação executada pelo ator, não se atendo ao o meio físico da comunicação
(CHESSMAN; DANIELS, 2001).
4.1.2 Interação entre Componentes
A etapa de interação entre componentes, se responsabiliza por examinar a forma de como
as operações do sistema serão realizadas. Para concretizar o objetivo desta etapa, dá-se início
a busca de informações que os objetos compartilham em comum. Uma boa prática é começar
com a definição da colaboração dos componentes.
Nos artefatos, utiliza-se com rigor os modelos de interação para obter o nível aprofundado
das operações do componente. Quanto mais interações são consideradas, mais informações
são extraídas sobre as operações comuns que poderão ser reutilizadas. Através desta aná-
lise, é possível identificar as responsabilidades das classes, tornando-os mais claras quanto a
compreensão, e facilidade com a manutenção futura do componente.
O comportamento dos objetos, para se ter um componente desacoplado, deve ser arqui-
tetado de forma que reduza ao máximo as dependências fixas entre outros objetos. Para isto,
os objetos devem ser construídos de forma que se comuniquem através de notificações de
mensagens pelas interfaces implementadas nos componentes. O intuito da interação entre
componentes é identificar e validar o funcionamento das operações das classes reunidas em
um sistema.
Quando identificado a estrutura básica de interação, deve haver um agrupamento das clas-
ses em colaboração, confirmando as operações através da comunicação entre elas. Essa ca-
deia de ações e funcionalidades, farão parte das regras de negócios a ser implementado no
sistema.
67
A seguir, estão descritos os artefatos pertencentes a esta fase.
a) Modelo de Tipo de Negócio.
O modelo apresentado, trata de definir a especificação de tipos de dados no sistema. Os
artefatos gerados são modelados através do diagrama de classes, com foco na tipagem
de dados, pois seu propósito é muito diferente do modelo conceitual. Neste modelo, a
geração de artefatos está direcionada em definir e separar cada tipo de classe e suas
propriedades relevantes para o entendimento.
Naturalmente, muitas classes identificadas neste modelo terão os mesmos nomes das
classes do modelo conceitual, porém, eles não representam a mesma coisa. Por exem-
plo, o modelo conceito de negócio pode conter uma classe chamada “cliente”, que repre-
senta o conceito de cliente no âmbito empresarial. Em contrapartida, a classe “cliente” no
modelo de tipo de negócio, representa a classe cliente com seus atributos e operações
para entendimento do software.
Para representar as classes no modelo do tipo de negócio utiliza-se do estereótipo «type»
(figura 33). O modelo pretende representar com precisão as informações sobre o negócio
com o qual o sistema precisa se preocupar. Isto significa extrair e refinar as classes
do modelo conceitual, para remover redundância na arquitetura do sistema. Ainda no
artefato gerado, há a possibilidade de utilizar a generalização, associações e todos as
funções prescritas no diagrama de classes na linguagem UML (CHESSMAN; DANIELS,
2001).
Figura 33: Exemplo - diagrama de classes representando o modelo de tipo de negócioFonte: Chessman e Daniels (2001, p. 49)
b) Modelo de Especificação de Interface.
Chessman e Daniels (2001) justificam que o modelo de especificação de interface é sub-
sidiado pelo conjunto de todas as especificações apresentadas até esta etapa. Seu foco
68
é definir com precisão o que as interfaces dos componentes disponibilizam de operações
(provided), e quais os serviços necessários para funcionamento do componente (requi-
red).
Praticamente uma especificação de interface é composta de tipo de interface própria;
modelo de informações contendo atributos e associações de papéis; tipos de dados inter-
nos; assinaturas das operações; e especificação das pré e pós condições. Cada interface
tem seu próprio ponto de vista sobre a informação em que se preocupa. Por esta razão,
para distinguir o diagrama de especificação de interface de outros diagramas, utiliza-se o
estereótipo «interface type».
Uma forma de organizar um componente é separar as interfaces pela similaridade do
negócio, esta tarefa gera um grupo de interfaces, chamado de pacote. O pacote pode im-
portar informações de especificações de outros pacotes já existentes, isto é comum nas
linguagens orientada a objetos. Como exemplo, na figura 34, apresenta um pacote cha-
mado de ICustomerMgt, que importa as informações de tipos de dados de outro pacote
qualquer.
Figura 34: Exemplo - diagrama de classes representando o modelo de especificação de inter-face
Fonte: Chessman e Daniels (2001, p. 56)
Um dos objetivos da modelagem de componentes, é definir especificações de interfaces
para oferecer operações e representar as necessidades do componente. Tomando como
válida essa afirmação, entende-se que as interfaces são criadas para definirem contrato
69
de relação entre os componentes. O sistema, não sabe de forma alguma os dados e
comportamentos das classes que implementam as interfaces, apenas, conhece as as-
sinaturas contratuadas pela interface, com isso, a aplicação se importa somente com a
chamada de assinatura dos métodos, confiando que a codificação desenvolvida nas clas-
ses, executará o propósito designado pelo método.
4.1.3 Especificação de Componentes
Nesta etapa, é considerado o último estágio do desenvolvimento de software baseado em
componentes utilizando o método UML Components. A fase prevê desenvolver uma especi-
ficação mais detalhada das operações e restrições do sistema. As interfaces ganham maior
atenção na definição dos estados possíveis que os objetos manterão perante os componentes,
e para reforçar esta análise, também são previstos especificar as pré e pós condições dos obje-
tos e componentes. Levando em conta estas atividades, possibilitam fundamentar a captura de
regras de negócios e restrições do sistema ainda não mapeados.
As pré e pós condições dos objetos e componentes, fazem referência aos tipos do modelo
de informação das interfaces. As restrições na especificação de um componente, determina
como as definições de tipos de interfaces correspondem ao contexto do componente. A arqui-
tetura do componente não deve ser alterada significativamente nesta fase, pois estas tarefas de
detalhamento somente devem ser realizadas assim que a arquitetura esteja estável e todas as
operações das interfaces tiverem identificadas.
O ato de escrever as regras precisas para cada objeto, componente, e operação, pode
ajudar a descobrir parâmetros em falta e pendentes do escopo do sistema. Mas a ênfase desta
atividade está no preenchimento de detalhes com objetivo de gerar um quadro estável entre a
arquitetura do sistema e compreensão da equipe de desenvolvimento.
Adiante, estão descritos os artefatos que fazem parte desta fase (CHESSMAN; DANIELS,
2001).
a) Modelo de Especificação de Componentes.
Verificou-se, até aqui, que a grande maioria dos modelos e diagramas, eram construídos
de artefatos unitários. Na especificação de componentes, este conceito, modifica-se para
geração de artefatos com a agregação de um conjunto de interfaces pertencentes ao
componente.
Em meio á linguagem UML, o conceito de componente, é voltado para o mundo da im-
plementação e implantação de software. Dentro desse domínio, um componente é muito
flexível, podendo acomodar muitas interfaces para definir um componente de negócio.
70
Como implantação, o componente pode-se ser tratado como um módulo instalado no
sistema, e ser responsável por executar uma determinada tarefa.
Na figura 35 do modelo apresentado, pode-se observar que o componente oferece uma
interface de implementação para se relacionar com outros componentes ou sistema. Esta
interface para alguns autores é chamada de provided (figura 36), porém, na bibliografia de
Chessman e Daniels (2001), está representada pelo estereótipo «offers». Essa especifi-
cação de oferenda de demanda de funcionalidades é detalhada mais adiante no modelo
de arquitetura de componentes.
Figura 35: Ilustração de um componente que oferece interface de implementaçãoFonte: Chessman e Daniels (2001, p. 60) com adaptações
Além das interfaces provides de um componente, existe também em sua especificação
as interfaces requires, exemplificado conforme a figura 36. O componente CustomerMgr
necessita de um outro componente que implemente a interface IDBConnection, servindo
como conexão de banco dados. As interfaces, por prática de padrão de desenvolvimento,
recebem a vogal “I” no início do nome; também, devem possuir nomes relativos aos obje-
tivos do contrato de negócio.
Figura 36: Ilustração de um componente com interface provided e requiredFonte: Chessman e Daniels (2001, p. 60) com adaptações
b) Modelo de Arquitetura de Componentes.
71
Por fim, mas não menos importante, chega-se a tarefa de especificar a arquitetura do
componente. Esta fase tem apoio em todos os artefatos criados no processo de espe-
cificação, porém, se assemelha em maior profundidade com o modelo de especificação
de interface. Assim como o processo de desenvolvimento é incremental, o processo de
especificação também o é, por este motivo, a construção da arquitetura do componente
começa desde as primeiras decisões tomadas na etapa inicial do projeto.
Neste modelo de diagrama, do ponto de vista da linguagem UML, o componente é con-
siderado uma caixa preta com especificação de oferendas e demandas de operações.
O termo utilizado para oferenda na UML é tratado como provide, e para o de demanda,
como require.
A arquitetura de componentes define um contexto no qual as dependências de uso das
interfaces de especificações dos componentes estão ligadas. Assim, em vez de uma
série de especificações de componentes independentes, tem-se uma arquitetura de com-
ponentes individuais (figura 37), ligadas entre interfaces provided e required.
Figura 37: Modelo de arquitetura de componentesFonte: Chessman e Daniels (2001, p. 100) com adaptações
Através deste último modelo, conclui-se a especificação de um sistema baseado em com-
ponentes. Como foco do trabalho, e mesmo na bibliografia utilizada, o processo de UML
Components cuida da especificação de componentes, deixando o desenvolvimento para
outros processos.
72
5 COMPARATIVO ENTRE ARTEFATOS CATALYSIS E UML COMPONENTS
Com a base teórica dos autores apresentados neste trabalho, buscou-se analisar os artefa-
tos gerados entre cada etapa dos dois processos envolvidos: Catalysis e UML Components. A
pesquisa executada foi de caráter exploratório, que possibilitou estudar exaustivamente o tema
a fim de obter a compreensão dos processos de engenharia de software para fins de reutilização
de software.
Nos dois processos da ESBC, apresentados neste trabalho, conforme a bibliografia utili-
zada, analisou-se somente as etapas de especificação de software baseado em componentes.
Com isto, o desenvolvimento de código não foi incluso no escopo. O trabalho proporcionou
compreender como especificar um sistema baseado em componentes com objetivo de reutiliza-
ção de código, para isto, foram abordados além dos conceitos teóricos, artefatos relacionados
a modelos e diagramas construídos em cada fase.
Neste capítulo, serão identificadas e exploradas as etapas em comum para os processos
Catalysis e UML Components. Também, serão analisados os artefatos gerados para a etapa
em estudo. O objetivo é compreender, para cada fase, qual dos dois processos tem uma melhor
abordagem para detalhar a especificação do projeto. A análise foi definida através da interpre-
tação das bibliografias estudadas em cada processo e definição de critérios estabelecidos, e,
para o demonstrativo do estudo comparativo, foram gerados exemplos, como modelos e diagra-
mas de referências para entendimento da comparação dos artefatos discutidos nas bibliogra-
fias utilizadas. Por fim, será dada uma conclusão baseada nas pontuações obtidas através da
aplicação dos critérios avaliadores, possibilitando a identificação do processo que trouxe uma
melhor visão de especificação de software sob a visão deste trabalho.
5.1 DEFINIÇÕES DE CRITÉRIOS
Primeiramente para analisar os artefatos, identificou-se a necessidade de relacionar as
etapas dos dois processos. Esta análise trata de identificar um título genérico das etapas em
comum dos processos abordados, e busca demonstrar meios de atingir o objetivo de cada fase
através da geração de artefatos. No quadro 1 apresenta o relacionamento de ambos processos
com uma definição gerérica de etapas dos processos.
De posse das etapas genéricas estabelecidas entre os processos, apresenta-se no quadro
2 os artefatos gerados em cada etapa genérica. Este mapeamento de artefatos no modelo
genérico de processo, define a relação de comparação entre os artefatos do processo Catalysis
e UML Components.
73
Etapas GenéricasCatalysis Etapa Genérica UML Components
Identificação de requisi-tos
Especificação de negó-cio
Identificação de requisi-tosIdentificação de compo-nentes
Especificação de soft-ware
Especificação do sis-tema
Especificação de soft-wareInteração de componen-tes
Arquitetura e desenhode componentes
Arquitetura de compo-nentes
Arquitetura e especifica-ção de componentes
Arquitetura interna decomponentes
Quadro 1: Geração de etapas genéricas entre os processos Catalysis e UML ComponentsFonte: O Autor
Em sequência, cada artefato de cada processo foi analisado individualmente através de
bibliografia e interpretação de modelo. Com isto, cada artefato demonstrou informações úteis a
que ele se propõe em sua etapa, sendo assim, gerou-se um repositório de dados para definições
de perguntas objetivas com propósito de comparar um artefato, com outro similar do processo
analisado. As perguntas estão detalhadas mais a frente, nas etapas do processo genérico.
A análise final para identificar que melhor processo de desenvolvimento de software base-
ado e componentes constrói uma especificação de software mais clara e robusta, se dá através
da pontuação das perguntas executadas sobre os artefatos de cada processo na etapa gené-
rica. O processo que possuir o maior número de respostas positivas sobre seus artefatos, será
considerado o processo que melhor especifica um sistema de software baseado em componen-
tes.
5.2 ESPECIFICAÇÃO DE NEGÓCIO
Como em todo o processo de desenvolvimento de software, na primeira fase, acontece
a concepção do negócio. A equipe de desenvolvimento se esforça para modelar o conceito
de negócio da aplicação. Neste sentido, observa-se que ambos processos começam com a
modelagem de domínio da aplicação. Como já discutido no referencial teórico, o domínio da
aplicação ou domínio do problema, tem objetivo de identificar o domínio de negócio do software
em construção. O negócio tem foco no mundo real, e deve ser compreendido pelo cliente.
74
Etapas e ArtefatosArtefatos Catalysis Etapa Genérica Artefatos UML Components
Mapa conceitual oumapa mental
Especificação de negó-cio
Diagrama de conceito denegócio ou domínio daaplicação
Diagrama de contextoGlossário e dicionário determos do projeto
Diagrama de casos deuso e narrativasGlossário e dicionário determos do projeto
Diagrama de cenário deuso
Especificação do sis-tema
Diagrama de tipos e ope-rações
Diagrama de tipos e ope-rações
Diagrama de classespara especificação deinterfaces
Modelo da plataforma re-querida do sistema
Arquitetura de compo-nentes
Diagrama de classespara especificação decomponentes
Modelo da arquiteturatécnica do sistemaModelo da arquitetura in-terna de componentes
Modelo da arquitetura decomponentes
Quadro 2: Etapas genéricas relacioados aos artefatos dos processos Catalysis e UML Compo-nents
Fonte: O Autor
75
Ainda na fase de especificação de negócio, aborda-se a identificação e captação de requisi-
tos do sistema que, mais tarde, são responsáveis por definir as funcionalidades que a aplicação
possuirá. A seguir, explica-se o objetivo de cada artefato gerado nesta fase pelos dois proces-
sos abordados.
O Catalysis mantém três formas de coletar informações para definir o modelo de negócio:
diagrama de mapa conceitual, diagrama de contexto do sistema, e dicionário de termos do pro-
jeto. O diagrama de mapa conceitual prevê construir um artefato com foco no cliente, ou seja,
que o cliente compreenda o conceito de negócio que será atribuído ao sistema. O diagrama
de contexto do sistema preocupa-se com o papel da aplicação no contexto do ambiente que
será implantado. Neste diagrama, além dos objetos conceituais que retratam o mundo real,
também identificam-se algumas interações e propriedades que os objetos potencialmente po-
derão necessitar. O diagrama de contexto permite uma visão de domínio da aplicação e serve
como modelo de captação de requisitos para o sistema. Já os dicionários ficam com a res-
ponsabilidade de esclarecer os termos utilizados no projeto, para que a equipe técnica fale na
mesma língua que a de negócio. Na figura 38, há uma representação dos artefatos gerados
para construção do domínio do sistema. Embora D’Souza e Wills (1998) expõem a possibili-
dade de utilizar casos de uso para coleta de requisitos, não será aceito para este trabalho, pois
o caso de uso não foi especificado no processo apresentado para o Catalysis.
Figura 38: Modelo de domínio do sistema no processo CatalysisFonte: D’Souza (1998, p. 78) com adaptações
O UML Components, por sua vez, trata esta fase utilizando artefatos da linguagem UML
chamados: modelo conceitual de negócio, diagrama de casos de uso e dicionários de termos.
O artefato de negócio possui o objetivo de retratar conceitualmente o mundo real do negócio
em que a aplicação será utilizada. O diagrama representa classes de UML (figura 30), com
estereótipo «concept» para descrever cada entidade de negócio. Permite ainda atribuir proprie-
76
dades e multiplicidade entre as classes conceituais, porém, de forma alguma, este modelo está
relacionado ao objetivo de arquitetura do sistema, apenas, seu foco é identificar o domínio da
aplicação. Ainda, faz parte desta etapa o artefato dicionário de termos, que ajuda a descre-
ver informações sobre o termos comentados no projeto. A figura 39 exemplifica os artefatos
gerados para o domínio do sistema.
Figura 39: Modelo de domínio do sistema no processo UML ComponentsFonte: O Autor
Na captação de requisitos, o processo UML Components utiliza do diagrama de casos de
uso da linguagem UML. O artefato gerado detalha as funções do sistema em níveis de ações,
definindo pré e pós condições para tarefa executada. Desta forma, além de especificar as
ações que o ator executa sobre o sistema, também detalha a narrativa passo a passo de como
a ação acontece. Ainda, na narrativa, são expressos fluxos alternativos em caso de exceções,
resguardando uma alternativa de saída para a operação falha.
No quadro 3 representa as perguntas formuladas para a comparação dos artafatos sobre os
dois processos abordados na etapa genérica de especificação de negócio. Também, na figura
40, demonstra a quantificação gráfica sobre o critério de perguntas aplicadas nos artefatos dos
processos Catalysis e UML Components.
Figura 40: Análise gráfica da comparação de artefatos da etapa Especificação de NegócioFonte: O Autor
77
Especificação de negócioRequisito comparado Catalysis UML Components
Pergunta 1: Demonstrana visão do cliente oconceito de negócio daaplicação
Diagrama de mapa con-ceitual
Diagrama de conceito denegócio
Pergunta 2: Permite cap-tar funcionalidades dosistema
Diagrama de contexto dosistema
Diagrama de casos deuso
Pergunta 3: Permite de-finir multiplicidade entreobjetos conceituais
Diagrama de mapa con-ceitual
Diagrama de conceito denegócio
Pergunta 4: Permite ex-pressar a ação que umator executa
Diagrama de mapaconceitual, diagrama decontexto do sistema
Diagrama de casos deuso
Pergunta 5: Permiteidentificar atributos nomodelo de negócio
Diagrama de mapaconceitual, diagrama decontexto do sistema
Diagrama de conceito denegócio
Pergunta 6: Permite re-lacionamento entre obje-tos conceituais
Diagrama de mapaconceitual, diagrama decontexto do sistema
Diagrama de conceito denegócio
Pergunta 7: Possui in-formações sobre termostécnicos e de negócios
Dicionário de termos doprojeto
Dicionário de termos doprojeto
Quadro 3: Informações captadas pelos artefatos na especificação de negócioFonte: O Autor
78
Analisando os artefatos gerados entre os processos, entende-se que os artefatos do Cataly-
sis, no quesito modelagem de domínio, têm vantagens sobre os da UML Components. Apesar
da similaridade entre eles, o processo Catalysis permite refinar as informações com mais de-
talhamento, pois aplica três construções de diagramas para determinar o domínio do sistema,
mas, na captação de requisitos, utiliza-se de um mesmo artefato para identifica-los. Já o pro-
cesso UML Components propõe uma definição de negócio apenas com o diagrama de classes
de negócio e os dicionários de termos, porém, quando se trata de captar requisitos, no UML
Components há um artefato de melhor qualidade. Os casos de uso, além de identificar os re-
quisitos do sistema, detalham em narrativa como será o procedimento de execução (D’SOUZA;
WILLS, 1998).
Como este trabalho define critérios para identificar o processo que possui os artefatos de
melhor qualidade para uma especificação de software, demonstra-se nesta etapa genérica de
especificação de negócio através da figura 41, um gráfico que representa a relação destes
critérios aplicados sobre os dois processos. Com o resultado expresso na figura 41, pode-se
constatar uma maior qualidade dos artefatos do processo Catalysis para a etapa genérica de
especificação de negócio.
Figura 41: Análise gráfica da etapa de Especificação de NegócioFonte: O Autor
5.3 ESPECIFICAÇÃO DE SISTEMA
Nesta etapa, a comparação entre processos foi definida através da similaridade dos artefa-
tos que objetivam a especificação técnica do sistema. A proposta desta fase é identificar como, e
79
por quem, as operações do sistema serão efetuadas, definir as classes de colaboração, depen-
dências e possíveis interfaces. Cada objeto definido nos artefatos desta fase deve receber uma
responsabilidade única de negócio, para posteriormente noutra etapa do processo, agrupar-se
a outros objetos de negócio similares, tornando-se componentes moduláveis. É imprescindí-
vel compreender que nesta etapa, os requisitos anteriormente captados se transformarão em
modelos técnicos de funcionalidades.
Entende-se que dois artefatos do processo Catalysis possuem objetivos de especificação
de sistema, são: diagrama de cenário de uso, e diagrama de tipo e operações. No diagrama
de cenário de uso, acontece o detalhamento técnico sobre o requisitos de negócio coletados.
A construção deste diagrama tem foco nas ações ou situações do ator perante a execução de
uma tarefa no sistema. Similar à narrativa do diagrama de casos de uso da UML, o diagrama
possui uma narrativa (figura 22) de operações realizadas. No entanto, este artefato não está
diretamente relacionada com a coleta de requisitos, nesta fase, possui objetivos de verificação
e validação de operações realizadas no sistema.
O segundo diagrama cotado para esta fase, chama-se diagrama de tipos e operações. O
artefato focaliza na junção de classes colaborativas, pois pretende agrupar as classes em um
único objeto. Para isto, há a necessidade de especificar propriedades e operações que poderão
ser acessadas externamente. A idéia de um objeto tipado segundo o diagrama, é estruturar em
um único objeto o conceito de negócio completo. O artefato após construído, por se tratar de
um agrupamento técnico de classes contendo um objetivo específico de negócio, dá subsídios
para a arquitetura de componente e reutilização de código.
No processo UML Components, esta fase contempla dois artefatos: diagrama de classes
como modelo de tipo de negócio, e diagrama de especificação de interface. No artefato dia-
grama de tipo de negócio, prevê estabelecer tipos de objetos através da abstração dos requisi-
tos do sistema. O tipo, como dito, é um conjunto de classes, atributos, operações, e colaboração
de objetos centrado em um tipo de negócio. O diagrama visa representar com precisão as infor-
mações herdadas do modelo conceitual de negócio, refinando e removendo redundâncias das
operações do sistema. Como o artefato tem base na linguagem UML, dispõe das funcionalida-
des de generalização, composição, agregação, entre outras.
Outro artefato desta fase, gerado pelo processo UML Components, é o diagrama de especi-
ficação de interface, que tem objetivo de definir as interfaces de comunicação entre os objetos,
nesse contexto as interfaces recebem uma certa identificação, como provided - interface que
disponibiliza operações e funcionalidades, e required - interface que necessita de operações
e funcionalidades. As interfaces, possuem as assinaturas dos métodos, ou seja, fazem um
contrato entre os objetos que utilizarão as operações do componente. Outra tarefa do arte-
80
fato, é ajudar a definir a hierarquia de pacotes. A especificação destas interfaces influencia na
arquitetura final do componente (D’SOUZA; WILLS, 1998).
No quadro 4, demonstra a aplicação de critérios de comparação entre os artefatos sele-
cionados na estapa genérica de especificação e sistema sobre os dois processos Catalysis e
UML Componentes. Em sequência, apresenta-se na figura 42, um gráfico resumo quantitativo
do resultado obtido sobre a aplicação destes critérios.
Especificação de sistemaRequisito comparado Catalysis UML Components
Pergunta 1: Permitetransformar regras denegócio em especifica-ção de software
Diagrama de tipos e ope-rações, diagrama de ce-nário de uso
Diagrama de tipos e ope-rações
Pergunta 2: Permite a in-teração entre objetos
Diagrama de cenário deuso, diagrama de tipos eoperações
Diagrama de tipos e ope-rações, diagrama de es-pecificação de interfaces
Pergunta 3: Permite ajunção de classes paraatribuir um conceito denegócio
Diagrama de tipos e ope-rações
Diagrama de tipos e ope-rações, diagrama de es-pecificação de interfaces
Pergunta 4: Permite de-talhar operações de umafuncionalidade
Diagrama de cenário deuso
Não possui nesta fase
Pergunta 5: Permiteidentificar e atribuir in-terfaces conceituais aosobjetos
Diagrama de tipos e ope-rações
Diagrama de tipos e ope-rações, diagrama de es-pecificação de interfaces
Pergunta 6: Permiteidentificar e atribuir res-ponsabilidade de objetos
Diagrama de cenário deuso, diagrama de tipos eoperações
Diagrama de tipos e ope-rações, diagrama de es-pecificação de interfaces
Pergunta 7: Permite tiparobjetos
Diagrama de tipos e ope-rações
Diagrama de tipos e ope-rações, diagrama de es-pecificação de interfaces
Quadro 4: Informações captadas pelos artefatos na especificação de sistemaFonte: O Autor
Na análise dos artefatos para esta fase do processo, identificou-se no processo Catalysis
um artefato similar a um caso de uso, ou seja, podendo, de certo modo, ser utilizado ainda
na captação de requisitos na fase anterior de especificação de negócio, porém, este artefato é
81
Figura 42: Análise gráfica da comparação de artefatos da etapa Especificação de SistemaFonte: O Autor
muito mais completo, contendo narrativa detalhada do procedimento, em conjunto com atores,
sistemas e operações, todos relacionados. Nota-se também, que sua estrutura tem base no
diagrama de sequência da UML, que demonstra de forma técnica a execução de uma operação,
e o tempo de vida que o objeto está em memória até o encerramento. O artefato ainda sofre um
complemento, ou seja, é suprido pelo segundo artefato, o diagrama de tipo e operações, que dá
ênfase no relacionamento e tipagem dos objetos, e especifica os métodos que serão expostos
através de implementação de interfaces. Por fim, o diagrama converge para uma única classe
que mais tarde tomará a estrutura de um componente (D’SOUZA; WILLS, 1998).
Já no processo UML Components, o diagrama de classes de tipo de negócio tem foco na
especificação das classes de negócios, contendo atributos, relacionamento e multiplicidade dos
objetos no sistema. Mas, o artefato gerado não demonstra as operações técnicas necessárias
para entendimento da execução de uma tarefa feita por um ator, com isso, entende-se que
o artefato mantém o objetivo de especificar a estrutura de classes do sistema, tornando-se
insuficiente para uma especificação completa de sistema, neste ponto de vista, os artefatos
do Catalysis se manteram superior, porém no UML Componentes ainda possui um segundo
artefato, o diagrama de especificação de interface, que expressa as necessidades de contratos
entre os módulos e componentes do sistema. Ele define quais interfaces serão necessárias
para construir um software componentizado e comunicável.
Conforme a aplicação de critérios nesta fase de especificação de sistema, que através de
perguntas direcionadas à qualidade que os artefatos podem expressar sobre informações do
sistema, obteve-se na figura 43 o resultado expresso em gráfico. Através da análise gráfica da
figura 43, apesar da pontuação quase idêntica entre os processos, justifica-se que nesta etapa
genérica os artefatos do UML Componentes se mostraram superior aos artefatos do Catalysis,
82
com isto, evidencia uma melhor especificação de sistema nesta etapa pelos artefatos UML
Componentes.
Figura 43: Análise gráfica da etapa de Especificação de SistemaFonte: O Autor
5.4 ARQUITETURA DE COMPONENTES
Interpretando os dois processos abordados neste trabalho, define-se esta fase como uma
validação de arquitetura, ou seja, tem maior atenção em verificar a coerência dos componen-
tes e menos atenção com a construção da arquitetura. Segundo as bibliografias estudas ao
decorrer deste trabalho, explicam que a arquitetura começa desde a criação dos primeiros dia-
gramas, e de forma incremental, é acrescentado novos detalhes, para que aos poucos aconteça
a evolução da arquitetura do sistema baseado em componentes.
Mesmo com objetivos primordiais de validação, os dois processos ainda delimitam tare-
fas para finalização do componente, como: plataforma requerida para o sistema, visão da ar-
quitetura técnica, especificação de componentes e arquitetura interna do componente. Estes
diagramas são essenciais para concluir a arquitetura do sistema baseado em componentes.
A etapa de arquitetura de componentes no processo Catalysis dispõe de três importan-
tes diagramas: modelo de plataforma requerida do sistema, diagrama de arquitetura técnica
do sistema e diagrama de arquitetura interna do sistema. Percebe-se um diferencial entre os
processos, pois no Catalysis há preocupação com requisitos de ambiente e plataforma de funci-
onamento que outros processos da engenharia de software não dão atenção. No diagrama de
83
plataforma requerida desenha-se o ambiente em que o sistema irá operar, assim como as ne-
cessidades de serviços e transações que comunicarão externamente com a aplicação. Com o
modelo planejado, pode-se efetuar estudos sobre as limitações de escalabilidade, desempenho,
transmissão de dados, segurança e outros requisitos não funcionais.
O artefato de arquitetura técnica do sistema, utiliza dos conceitos aplicados no diagrama
de plataforma requerida do sistema, pois de certa forma, é composto por um detalhamento
das dependências internas do sistema, que por sua vez, é representado pelos componentes
interconectados através das interfaces. Este artefato permite uma visão detalhada sobre as
dependências internas e externas dos componentes.
No último artefato do Catalysis que trata da arquitetura interna do sistema, aborda cla-
ramente a comunicação entre os componentes através das interfaces. Neste diagrama tam-
bém está planejado a visualização do código necessário para a implementação das interfaces,
tornando-se simples a codificação do fonte com base no diagrama (D’SOUZA; WILLS, 1998).
Para o processo UML Components, considerou-se para esta fase dois diagramas: diagrama
de classes para especificação de componentes e diagrama da arquitetura de componentes. O
primeiro artefato diz respeito a agregação de interfaces pertencentes ao componente, agora,
nesta fase, deve-se estar especificado as interfaces que o componente dispõe e os que ele
necessita. Este artefato se propõe a demonstrar as interfaces provided e required para que no
diagrama de arquitetura de componentes faça as ligações necessárias.
A arquitetura do sistema no processo UML Components é finalizada pela geração do arte-
fato de arquitetura de componente, que demonstra os componentes separados em conceitos
de negócios. Neste diagrama, o modelo de componentes ganha uma visão das necessidades
de colaboração entre cada componente, usando a tipagem das interfaces em provided e re-
quired definindo as interfaces que oferecem funcionalidades e as interfaces que necessitam de
funcionalidades.
No quadro 5 há a representação do comparativo dos critérios aplicados sobre os artefatos
na etapa genérica de arquitetura de componente. Além do quado, demonstra-se na figura 44
a quantificação das respostas obtidas sobre os critérios aplicados nos artefatos dos processos
Catalysis e UML Componentes nesta etapa de arquitetura de componentes.
Em análise realizada sobre esta etapa do processo genérico, conforme os dados gerados
sobre os critérios analisados, identifica-se que novamente o pocesso Catalysis possui qualidade
superior de seus artefatos comparados aos artefatos da UML Components. Isto é evidenciado
na figura 45, que demonstra o resultado da análise nesta etapa. O Catalysis manteve um
número maior de pontuação sobre o UML Components, sendo assim, sobre o ponto de vista
84
Arquitetura de componentesRequisito comparado Catalysis UML Components
Pergunta 1: Define re-quisitos para o ambientede implantação do sis-tema
Diagrama da plataformarequerida do sistema
Não possui no processo
Pergunta 2: Deixa claroas interfaces Providede Required dos compo-nentes
Não possui no processo Diagrama de classespara especificaçãode componentes, dia-grama da arquitetura decomponentes
Pergunta 3: Demons-tra a interação entre oscomponentes
Diagrama da plataformarequerida do sistema, di-agrama da arquiteturatécnica do sistema, dia-grama da arquitetura in-terna de componentes
Diagrama de classespara especificaçãode componentes, dia-grama da arquitetura decomponentes
Pergunta 4: Permite de-finir a implementação decódigo das interfaces
Diagrama da arquiteturainterna de componentes
Não possui no processo
Pergunta 5: Permite de-finir dependências comcomponentes e serviçosexternos
Diagrama da plataformarequerida do sistema, di-agrama da arquiteturatécnica do sistema
Diagrama da arquiteturade componentes
Pergunta 6: Permite de-finir interfaces de comu-nicação ente os compo-nentes
Diagrama da arquiteturainterna de componentes
Diagrama de classespara especificação decomponentes
Quadro 5: Informações captadas pelos artefatos na arquitetura de componentesFonte: O Autor
85
Figura 44: Análise gráfica da comparação de artefatos da etapa Arquitetura de ComponentesFonte: O Autor
dos critérios estabelecidos, a etapa de arquitetura de componentes é melhor especificada pelos
artefatos do processo Catalysis.
Neste estudo desta etapa e dos artefatos para os dois processos, considerou-se que os
artefatos gerados para o Catalysis e o UML Components deveriam ser integrados, pois para o
Catalysis, possui diagramas relacionados com a arquitetura de ambiente e arquitetura interna de
componente com foco na implementação, e para o UML Components, possui diagrama de espe-
cificação de componentes e diagrama de arquitetura de componentes com foco na definição de
dependências das interfaces required e provided. Entende-se que um diagrama complementa
o outro, sendo o ideal utilizar de ambos artefatos. Porém, nem sempre é aceitável, como os ar-
tefatos fazem parte de processos separados, a utilização dos artefatos depende da flexibilidade
do projeto em utilizar integração de processos e artefatos diferenciados.
Figura 45: Análise gráfica da etapa de Arquitetura de componentesFonte: O Autor
86
Por fim, a escolha do processo como melhor ferramenta para especificação do sistema ba-
seado em componentes, teve princípio na definição e aplicação de critérios comparativos entre
os artefatos de cada processo em uma etapa genérica. A escolha do processo ocorreu através
da coleta de pontuações pertinentes a análise comparativa, em sequência, foi construído um
gráfico representativo, conforme expressado na figura 46. Com isto, percebe-se que o Catalysis
manteve uma maior pontuação em duas etapas genéricas: especificação de negócio e arquite-
tura de componentes, e o processo UML Components teve maior pontuação somente sobre a
etapa de especificação de sistema. De qualquer forma, UML Components, apenas ficou com
um ponto acima que o Catalysis na etapa de especificação de sistema, simbolizando a forte
aproximação do Catalysis até mesmo nesta etapa.
Figura 46: Análise gráfica comparativa das etapas genéricasFonte: O Autor
Como este trabalho usou-se de um estudo exploratório, e definições de critérios para espe-
cificação do melhor processo para especificação de software baseado em componentes, pode-
se afirmar, que o processo que mais obteve pontuação foi o Catalysis, com isto, considera-se o
Catalysis como o processo que possui melhores artefatos para especificar um software baseado
em componentes.
Portanto, segundo os critérios deste trabalho exploratório, entre os processos Catalysis e
UML Componentes para especificação de software baseado em componentes, os melhores
artefatos para esta especificação encontra-se no processo Catalysis. Porém para se ter uma
visão detalhada de qual realmente processo é o melhor, deve-se constuir um software, gerando
todos os artefatos para ambos os processos, e assim coletar todas informações na prática,
para assim evidenciar os pontos fortes e fracos de cada processo, chegando a uma conclusão
técnica com maior rigor.
87
6 CONCLUSÃO
Este trabalho teve como objetivo aprimorar os conhecimentos de engenharia de software
baseada em componentes e reutilização de software. A engenharia de software, propriamente
dita, preza pela economia, seja de mão de obra, de materiais ou de tempo. Porém isto não
quer dizer que a qualidade será reduzida para os projetos, pelo contrário, a meta sempre é
atingir os maiores níveis de qualidade com custos reduzidas. Esta visão de economia se aplica
ao contexto deste trabalho, que apresenta e descreve os processos da engenharia de software
com foco em economia, ou seja, através da reutilização de software e sua modularização em
componentes, desta forma, é possível construir softwares de maneira acelerada economizando
tempo e custos, e com qualidade superior aos processos prescritivos.
A pesquisa realizada teve caráter exploratório, trazendo muitas vantagens através do estudo
exaustivo dos processos de software baseados em componentes. Neste trabalho foi possível
compreender a especificação de um sistema composto de componentes, bem como, a arquite-
tura interna e externa de componentes. Apesar do trabalho não ter foco no desenvolvimento de
código fonte, adquiriu-se o conhecimento sobre o uso de interfaces de negócios, que por sua
vez, tem uma grande importância no desenvolvimento de software por se tratar de um contrato
entre classes da aplicação, que mais tarde na implementação, recebem as qualificações de
requeridas required necessidade de implementação de uma interface, ou oferecidas provided,
que disponibilizam interfaces para outras classes implementar.
O trabalho possibilitou a obtenção de conhecimentos gerais da engenharia de software.
O estudo, sem dúvida, agregou o conhecimento sobre os diferentes tipos de processos da
engenharia de software, identificando qual processo melhor se encaixa em um determinado
projeto de software.
Os dois processos abordados neste trabalho: Catalysis e UML Components, foram devi-
damente compreendidos e explanados através das bibliografias chave, que, por sua vez, foram
desenvolvidas pelos autores criadores destes processos. No estudo comparativo, foi possí-
vel relacionar os processos em etapas semelhantes e definir critérios de comparação, com a
ajuda da compreensão adquirida no referencial teórico. Com isto, analisou-se cada artefato ge-
rado nas etapas similares, com objetivo de identificar dentre os artefatos, qual melhor processo
poderia ser utilizado para a especificação do sistema de software baseado em componentes.
Sendo assim, através da aplicação dos critérios, entende-se que o processo Catalysis possui os
artefados de melhor qualidade para a especificação de um software baseado em componentes.
Em se tratando de propostas futuras, este trabalho trouxe subsídios para construção da es-
pecificação de um software baseado em componentes sobre o ponto de vista de dois processos:
88
Catalysis e UML Components. Deixa-se como desafio e como proposta futura, a especificação
de um software baseado em componentes e com objetivo de reuso de software utilizando os
processos, etapas e artefatos apresentados neste trabalho. Também, como outras sugestões:
a construção de um software componentizado utilizando os processos Catalysis e UML Com-
ponents, ou mesmo, agregar um ou mais processos ao comparativo explorado neste trabalho.
Na construção deste trabalho, aconteceram muitos imprevistos, dificuldades e necessida-
des, começando pelo escopo do trabalho, que, por sua vez, estava baseado em um estudo de
caso comparativo entre dois processos: Catalysis e UML Components, sendo que neste es-
copo, haveria a construção da especificação de um sistema contendo todas as modelagens dos
artefatos do processo Catalysis e do processo UML Components com objetivo de documen-
tar as etapas e identificar qual processo melhor geraria a especificação. Ainda neste escopo,
o trabalho visava se transformar em um livro de engenharia de software baseado em compo-
nentes. Apesar da proposta tentadora de manter o escopo inicial, levaria uma demanda de
tempo enorme, que não seria possível terminar em um único semestre acadêmico. Com isto,
mudou-se de escopo.
O segundo escopo de trabalho, é este apresentado. O comparativo entre os processos
continuou, porém, teve base na compreensão do referencial teórico. Se tornou uma pesquisa
exploratória, com fins de entender e interpretar o processos da engenharia de software baseada
em componentes. O livro proposto no primeiro escopo, ficará para projetos futuros.
As dificuldades encontradas foram diversas, começando pela metodologia de trabalhos aca-
dêmicos. Inicialmente, escreveu-se parte do trabalho na ferramenta Microsoft Word, porém,
grande maioria dos acadêmicos estavam construindo seus trabalhos de conclusão de curso so-
bre a ferramenta LATEX que, enfim, mostrou-se superior. Começou-se o estudo da ferramenta
LATEX. Como a faculdade IST nos disponibiliza-ra um modelo de TCC para LATEX com a me-
todologia da ABNT inclusa, relativamente a primeira impressão do modelo foi apenas de que
seria necessário escrever o trabalho, porém, infelizmente a realidade foi outra, o modelo LATEX
demonstrou estar desatualizado com as novas versões do LATEX, por este motivo, a metodologia
ficou desconfigurada, trazendo dificuldades aos alunos que estão enfrentando problemas com
a metodologia no LATEX. Enfim, usando o LATEX, o trabalho mantém uma qualidade visual su-
perior, porém, com os problemas encontrados, algumas definições das normas da Associação
Brasileira de Normas Técnicas (ABNT) estão em desacordo no trabalho apresentado.
Outras dificuldades estão relacionadas com as bibliografias, pois a instituição possui pou-
cos materiais sobre ESBC, ou seja, são apenas alguns capítulos em livros de engenharia de
software. Com isto, buscou-se material externo, o qual se encontrou somente em inglês, que
exigiu um maior tempo para compreensão do assunto.
89
Outro ponto negativo durante o trabalho, foi a concorrência entre estudo, trabalhos e provas
do semestre letivo cursado, que interferiu fortemente no atraso da primeira entrega do Trabalho
de Conclusão de Curso (TCC).
Por fim, apesar das dificuldades, houve os ganhos, que foram muito maiores, estes, chamam-
se de conhecimento e experiência, que será levado para a vida, agora, com responsabilidade
de um engenheiro.
90
REFERÊNCIAS
ABRAN, A. et al. Swebok: Guide to the Software Engineering Body of Knowledge. Los Alamitos,CA, USA: IEEE, 2004.
BAETJER, H. Software as capital. IEEE Computer Society Press, p. 85, 1998.
BAUER, F.; NAUR, P.; RANDEL, B. Software engineering: A report on conference a sponsoredby the nato science committee. In: Scientific Affairs Division. Brussels: NATO, 1969.
BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível em: <http:/-/agilemanifesto.org/>. Acesso em: 01 fev. 2011.
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. [S.l.: s.n.], 2006.
BRUEGGE, B.; DUTOIT, A. H. Object-Oriented Software Engineering: Conquering Complexand Changing Systems. USA: Carnegie Mellon University, School of Computer SciencePittsburgh, 1999.
CATALYSIS. Catalysis Enterprise Components with UML. 1998. Disponível em: <http://www-.catalysis.org/>. Acesso em: 19 mar. 2011.
CHESSMAN, J.; DANIELS, J. UML Components: A Simple Process for SpecifyingComponent-Based Software. [S.l.]: United States of America and Canada, 2001.
CLEMENTS, P. C. From Subroutines to Subsystems: Component Based Software Development.[S.l.: s.n.], 1995.
COCKBURN, A. Agile Software Development. [S.l.]: Highsmith Series Editors, 2000.
CRNKOVIC, I.; LARSSON, M. Building Reliable Component-Based Software Systems.Norwood, MA.: Artech House, INC, 2002.
CRYSTAL. 2010. DevX is a division of Internet.com. 17424.jpg. Largura: 851 pixels. Altura: 631pixels. 57KB. Formato JPEG. Disponível em: <http://assets.devx.com/articlefigs/17424.jpg>.Acesso em: 13 fev. 2011.
DIJKSTRA, E. W. The Humble Programmer. [S.l.]: ACM Turing Award Lecture, 1972. 859-866 p.
D’SOUZA, D. Objects, Components, and Frameworks with UML: The Catalysis Approach. [S.l.]:ICON Computing, a Platinum Company, 1998.
D’SOUZA, D.; WILLS, A. C. Objects, Components, and Frameworks with UML: The CatalysisApproach. [S.l.]: Addison Wesley Longman, 1998.
FERREIRA, A. B. de H. Dicionário Aurélio Eletrônico. [S.l.]: V. 5.0, 2010.
IEEE, S. C. Software engineering. IEEE Standard 610, 12 1993.
MARSIC, I. Software Engineering. [S.l.]: Department of Electrical and Computer Engineering,2009.
MARTINS, J. C. C. Técnicas Para Gerenciamento de Projetos de Software. [S.l.]: Brasport,2007.
91
OLIVEIRA, F. C. de; PAULA, L. L. de. Engenharia de Software Baseada em Componentes: UmaAbordagem Prática em Ambientes Web. [S.l.]: Universidade de Brasília Instituto de CiênciasExatas Departamento de Ciência da Computação, 2009.
PÁDUA, W. de. Engenharia de Software; fundamentos, métodos e padrões. 3. ed. Rio deJaneiro: LTC, 2009.
PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.
RATIONAL. Rational unified process: Best practices for software development teams. RationalSoftware White Paper, TP026B, Rev 11/01, 2001.
SCHWABER, K.; SUTHERLAND, J. Scrum. [S.l.]: Scrum.org, 2010.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Addison-Wesley, 2007.
WANG, Y. Software Engineering Foundation: A Software Science Perspective. USA: AuerbachPublications, 2008.
WELLS, D. Extreme Programming. 1999–2009. Disponível em: <http://www-.extremeprogramming.org/>. Acesso em: 02 fev. 2011.
WELLS, D. Extreme Programming: A gentle introduction. 2009. Disponível em: <http://www-.extremeprogramming.org/>. Acesso em: 28 jul. 2011.