modelagem e projetos orientado a objetos com uml2

Prévia do material em texto

www.princexml.com
Prince - Personal Edition
This document was created with Prince, a great way of getting web content onto paper.
Dedicatória
Ao meu filho, Murilo, pelo estímulo, carinho e compreensão.
A quem se destina este
livro
Este livro se destina a diferentes classes de leitores, que tem em
comum o desejo de conhecer técnicas para se descrever um software,
seja porque são profissionais da área da computação, seja porque
acreditam que um software possa ajudá-los a melhorar o seu negócio,
seja ele qual for. Os leitores deste livro podem ser:
· Estudantes e Professores que podem encontrar neste livro
apoio para o desenvolvimento de cursos de Engenharia de Software,
de Análise e Projeto de Sistemas e para o desenvolvimento de projetos
de software. Apesar da abordagem dada a este trabalho não ter uma
ênfase didática, ele pode ser utilizado como uma leitura complement-
ar. Especialmente nos capítulos iniciais, onde o livro tece os funda-
mentos da orientação a objetos, o teor introdutório pode ser de grande
ajuda a estudantes de computação e áreas afins.
· Analistas de Sistema e Programadores de Computa-
dor envolvidos em projetos de sistemas de software, que encontrarão
reunidas neste livro algumas técnicas úteis para o desenvolvimento de
modelos orientados a objeto destes projetos. A adoção destas técnicas
pode ajudá-los a construir sistemas de software mais robustos, mais
confiáveis e de manutenção mais fácil.
· Usuários ou Gerentes de Projeto de Software que po-
dem adotar algumas das idéias presentes no livro para facilitar o
planejamento de um projeto de software. A leitura ajudará a criar uma
linguagem comum entre o usuário, o gerente de projeto e a equipe téc-
nica de desenvolvimento. Como um projeto orientado a objetos requer
uma grande dose de modelagem, este livro pode uniformizar os ter-
mos usados na comunicação com a equipe de projeto e ajudar a definir
as etapas e produtos do projeto de software.
4/438
Convenções adotadas
neste livro
Para facilitar a leitura, este livro adota as seguintes convenções
tipográficas:
· Os termos e conceitos importantes para o texto são escritos em
negrito na primeira vez em que eles aparecem. Estes termos podem
ser encontrados novamente no glossário, ao final do livro, onde rece-
bem uma breve explicação.
· Os comandos e extratos de código, escritos em linguagem de
programação usam fonte currier, assim como os nomes de compon-
entes e elementos do modelo, quando citados no texto são escritos
também em fonte currier, para diferenciá-los do seu significado fora
do escopo do programa.
· As citações, os extratos de textos da bibliografia e palavras em
língua estrangeira são escritos com caractér itálico.
· A lista de referências bibliográficas escontra-se no final do liv-
ro. Quando citadas no texto, as referências aparecem entre parênteses
com o nome do autor e o ano de publicação. Por exemplo: (Beck, 1999)
ou citado por Beck (1999).
· Os endereços de websites citados no texto e na bibliografia
que podem ser acessados pela internet são grifados como no exemplo:
www.omg.org
6/438
1. Introdução
Este capítulo discute a importância de se criar um modelo nos
projetos de software. Inicialmente, apresenta o caráter dualista do
software: ora produto da criatividade, ora trabalho sistemático de
engenharia, para então discutir o porquê, em ambos os casos, o mod-
elo do software ser colocado no centro do processo de desenvolvi-
mento, como forma de unificar a visão do software entre os parti-
cipantes do projeto. O capítulo termina fazendo uma apresentação
do restante do livro e de como ele pode ser lido.
1.1. Introdução ao
Desenvolvimento de
Software
software é um produto da inteligência humana, por meio dele é
possível se preservar uma boa idéia e transmití-la para muitas outras
pessoas. O software é uma das poucas maneiras disponíveis capazes de
capturar o conhecimento de alguém e colocá-lo à serviço de outros.
Existem algumas formas para se fazer isso, como os livros ou as aulas
nas escolas, mas nenhuma delas tem a capacidade de interação que o
software oferece, e que pode transformar o conhecimento capturado,
diretamente, em uma habilidade para o seu usuário. Um usuário, de
posse de um software adequadamente contruído, passa a ter novas ha-
bilidades e pode fazer coisas que antes não sabia. Esta versatilidade,
faz com que haja um grande interesse em converter conhecimentos e
habilidades, cada vez mais complexas, em software. Este livro trata
desta conversão, discute-se aqui como se transforma uma idéia em um
software útil. Como se captura uma idéia para que o desenvolvedor
crie um sistema de software que irá dar esta habilidade ao usuário:
Figura 1- O software pode transformar uma idéia em uma
habilidade
Na construção de um software existe uma boa dose de criatividade,
mas há uma dose ainda maior de pensamento lógico e trabalho dis-
cipliando. O computador, uma das maiores invenções do homem, é
uma mero escravo do software. Todas as maravilhas que um computa-
dor é capaz de desempenhar, dependem, diretamente, da disponibilid-
ade de um software projetado para realizá-las. Além da criatividade
são necessários métodos, procedimentos e muita disciplina para criar
um software útil. Toda esta organização é conseqüência da distância
que separa os computadores dos homens, e das suas idéias. Os com-
putadores são meros autômatos, sabem realizar com grande velocid-
ade, e por repetidas vezes, tarefas simples, escritas em um programa
de computador. Os programas de computador são seqüências de
comandos simples escritos em uma linguagem de programação que
pode ser entendida pelo computador, e que ainda está muito longe da
linguagem humana, e da complexidade do pensamento humano.
A distância entre o conhecimento humano e as linguagens de pro-
gramação se reflete nas inúmeras dificuldades encontradas durante o
desenvolvimento de um software. Utiliza-se aqui o termo software
para descrever um conceito muito mais amplo do que um mero pro-
grama de computador. O sofware, que se refere este livro, compreende
toda a estratégia utilizada para resolver um problema real com apoio
de um computador. Mais do que uma série organizada de instruções, o
software atende uma finalidade, serve a um objetivo do seu utilizador.
Nesta visão, o software se completa ao hardware, o computador pro-
priamente dito, e seus equipamentos periféricos, que em conjunto
compõem o que se pode chamar de sistema computacional. O con-
junto de partes relativa ao software no sistema computacional é o cha-
mado sistema de software.
9/438
A atividade de programação de computadores é apenas uma etapa
do trabalho de desenvolvimento de um software. Programar é escrever
a solução de um problema, que já está definida, em uma linguagem
que possa ser entendida pelo computador. Desenvolver um software
compreende ainda muitas outras atividades como a de analisar o prob-
lema que se pretende resolver, e fazer o design da solução. Desen-
volver software é resolver problemas por intermédio da programação
de computadores é uma atividade de engenharia, da assim chamada “
Engenharia de Software”.
Engenharia de Software é a ciência da computação aplicada na
transformação do computador em uma ferramenta de trabalho para os
seus utilizadores. Ela é aplicada hoje aos mais diferentes desafios,
desde a manipulação de dados administrativos em um sistema de in-
formação gerencial até a transmissão de voz e imagem em equipamen-
tos de telecomunicação. O software é hoje uma tecnologia onipresente.
Do telefone ao despertador, da televisão ao supermercado, do brin-
quedo ao avião, do elevador à internet, o software está presente,
dando uma importante contribuição à produtividade das empresas e à
qualidade de vida das pessoas.
Pressman (1995) destaca a importância da Engenharia de Soft-
ware afirmando, que as práticasde engenharia de software se intensi-
ficaram com o agravamento dos problemas relativos ao software:
a) A sofisticação dos problemas ultrapassaram a nossa capacidade
de construir software que extraia o potencial oferecido pelo hardware,
b) Nossa capacidade de construir software de qualidade não pode
acompanhar a demanda por novas aplicações da computação, e
c) Nossa capacidade de manter os software existentes foi ameaçada
por projetos ruins e recursos inadequados
10/438
Observa-se, nestas considerações, que a Engenharia de Soft-
ware lida intimamente com as limitações da capacidade humana em
criar software. O crescimento do poder dos microprocessadores torna
mais aparente os limites da nossa capacidade de conceber e criar soft-
ware que aproveite todo esta potencialidade. As demandas crescentes
por parte dos usuários pressionam os desenvolvedores para uma luta
contra o tempo na busca por bons projetos de software, que possam
ser construídos e mantidos adequadamente. Os problemas atuais, a
serem resolvidos pelo software, não apenas se tornaram complexos,
eles estão se modificando continuamente, e se integrando a outros
problemas, igualmente complexos, em uma rede global de computa-
dores que é a internet. A digitalização da informação, por exemplo,
ajuda a criar novas demandas por software, com a possibilidade da
distribuição ampla da informação promovida pela internet.
Aparentemente, a distância entre os desafios propostos para o soft-
ware e as linguagens de programação disponíveis para construí-los é
intransponível. As linguagens se mantém relativamente simples, com
instruções elementares, criando programas de computador longos,
ambígos e sujeitos à muitas falhas. A principal razão desta limitação é
a própria arquitetura das máquinas de Von Neumann, base de todos
computadores e processadores comerciais existentes hoje (Eck, 1995).
Este uso, quase universal, da arquitetura de Von Neumann, como base
para os computadores é o fator mais importante para o projeto de lin-
guagens de programação, e conseqüentemente, dos métodos disponí-
veis para se criar software, como observa Sebesta (1996).
Para se aproximar o mundo dos problemas reais do universo virtual
de um computador é necessário que se selecione um paradigma único,
no qual se possam descrever os problemas reais, ao mesmo tempo,
que possuam uma trqadução direta para a linguagem do computador.
A busca deste paradigma pode ser usada para retratar o histórico das
linguagens de programação desde a sua criação, e resulta no que hoje
11/438
são as linguagens de programação que se utilizam do paradigma de
objetos, as chamadas linguagens orientadas a objetos. Essencialmente,
a programação orientada a objetos busca a solução dos problemas de
software pela identificação objetos do mundo real, que são depois
traduzidos em outros objetos de um modelo de software (Sebesta,
1996). As linguagens orientadas a objeto como Java, Delphi, Visual
Basic, C++ e C# facilitam esta tradução por se utilizarem dos mesmos
fundamentos do paradigma de objetos que foram usados na model-
agem. A disponibilidade e ampla divulgação destas linguages são as
grandes motivadoras para a evolução da análise e do projeto de sis-
temas orientados a objeto, como tentativas para se transpor o abismo
entre as boas idéias e o software que as implementaria.
Este livro objetiva capacitar analistas, programadores e gerentes de
projeto de software na construção de um modelo orientado a objetos
de um problema do mundo real. A principal meta deste trabalho é or-
ganizar um conjunto coerente de técnicas de análise e projeto de sis-
temas orientados a objetos, de modo que o modelo construído por es-
tas técnicas sirva de ponte para a construção do software.
12/438
1.2. Como este livro está
organizado
Para cumprir os objetivos propostos para este livro, a construção de
modelo de um sistema de software foi dividida em 6 capítulos, um
glossário de termos e um apêndice, que são descritos a seguir:
Capítulo 1 – Introdução. Apresenta esta introdução aos objet-
ivos do livro, a organização proposta, como ele pode ser lido, o seu
público alvo e destaca a importância da modelagem para o desenvolvi-
mento de software.
Capítulo 2 - Fundamentos da Modelagem Orientada a Ob-
jetos. Apresenta os conceitos fundamentais da orientação a objetos e
a sua relação com o processo de desenvolvimento de software. As cara-
cterísticas que diferem a abordagem de objetos das outras abordagens
são aqui descritas com detalhe. Os conceitos de encapsulamento, her-
ança, mensagens e polimorfismo são definidos e exemplificados por
uma aplicação simples de automação comercial. É um capítulo de
leitura obrigatória para quem deseja revisar os conceitos da tecnologia
de objetos e conhecer a nomenclatura utilizada no restante do livro.
Aos leitores que já possuem estes conceitos, a leitura deste capítulo
pode ser dispensada.
Capítulo 3 - O Modelo de Contexto. Apresenta o primeiro
modelo a ser desenvolvido para uma abordagem inicial de um prob-
lema de software. O modelo de contexto é um modelo alto nível
baseado na análise funcional, que visa definir a fronteira do sistema e
os seus objetivos principais. Neste modelo são utilizados os diagramas
de casos de uso propostos por Jacobson (1992) e adotados
porteriormente pela UML (Jacobson, 1998). A fronteira isola o sis-
tema de software dos componentes externos ao software, mas que in-
teragem com ele. Este capítulo é especialmente importante para os
leitores envolvidos nas definições iniciais de um sistema computacion-
al, que devem, em contato direto com os clientes do software, espe-
cificar os requisitos do sistema.
Capítulo 4 - O Modelo Conceitual apresentado é baseado nos
cartões CRC. Descreve a técnica dos cartões CRC aplicada na defin-
ição inicial de um sistema orientado a objetos. Esta técnica utiliza
cartões comuns de arquivo para representar os objetos, e ajudam na
distribuição das funcionalidades esperadas entre os objetos do mode-
lo. Este capítulo é recomendado para os leitores envolvidos na con-
cepção de sistemas, com experiência ou não em sistemas não orienta-
dos a objetos e que devem passar a "pensar" em objetos. Não é um
capítulo essencial para quem já posssui os conceitos de objetos bem
consolidados. Mesmo neste caso este leitores podem se servir da téc-
nica dos cartões CRC como um método que permite envolver os cli-
entes e usuários no levantamento de requsitos de projeto e no pro-
cesso de concepção do software.
Capítulo 5 - O Modelo de Detalhado de Objetos. Descreve, fi-
nalmente, os diagramas do modelo orientado a objetos na notação
proposta pela UML: diagrama de classes, estados, seqüência, ativid-
ades, colaboração, componentes e distribuição. Cada diagrama é
descrito em conjunto com seus elementos componentes e aplicado em
diversos exemplos, que permitem ao leitor visualizar as diversas al-
ternativas da sua aplicação na modelagem de sistemas. É um capítulo
essencial para a compreensão da notação e dos detalhes construtivos
dos diversos diagramas que compõem os modelos orientados a objeto.
Capítulo 6 – Estudo de Casos. Aplica os modelos apresentados
nos capítulos 3, 4 e 5 em três estudos de caso. Inicialmente o estudo de
14/438
caso da aplicação comercial do capítulo 2 é revisado, assim como o ex-
emplo do jogo da forca utilizado no capítulo 4, e o exemplo de estoque
do capítulo 5. Desenvolvido com uma visão didática, ele permite ao
leitor compreender a integração que existe entre os modelos e diagra-
mas. O leitor pode, se desejar, iniciar a leitura do livro por este
capítulo tendo uma abordagem inicial mais prática, para dai se apro-
fundar nos assuntos de maior interesse nos capítulos anteriores.
Um Glossário finaliza o trabalho listando os principais termos
utilizados na modelagem orientada a objetos. Como alguns destes ter-
mos pode ter um significado diferente forado contexto da modelagem,
o glossário deve ser consultado sempre que surgir dúvida em algum
termo durante a leitura do texto.
O Apêndice mostra o resultador da tradução dos modelos da
UML em códigos Java, transformando os exemplos em aplicações
completas. Lá encontram-se os códigos dos programas e o endereço do
website para executá-los. Todos os exemplos usados ao longo do texo
estão disponíveis para acesso pela internet.
São várias as possibilidades de leitura do texto do livro, e elas estão
esquematizadas na figura abaixo, partindo do interesse do leitor por
uma visão teórica, uma visão prática ou por um interesse específico
por algum tema:
15/438
Figura 2 - Encadeamento possível para leitura dos capítulos
Pode-se iniciar a leitura pelo Capítulo 2 para os que desejam con-
solidar os fundamentos da orientação a objetos. No entanto, se os
leitores já são familiares a estes conceitos, podem utilizar este capítulo
para familiarizarem-se com a nomenclatura utilizada no restante do
texto. Os capítulos 3, 4 e 5 são relativamente independentes por se
tratarem de 3 modelos que diferem em escala e objetivo. Podem, por
isso, ter uma leitura independente, mas que em conjunto apresentam
as possibildades de modelagem que a orientação a objetos nos
oferece. A leitura seqüencial destes três capítulos favorece o entendi-
mento da evolução dos modelos que ocorre, naturalmente, durante o
desenvolvimento de um sistema de software. Entretando, se o objetivo
do leitor é apenas criar uma especificação de alto nível do sistema
pode interromper a sua leitura no capítulo 3. Se além do modelo de es-
pecificação deseja um aprofundamento dos conceitos do sistema em
16/438
um modelo conceitual preliminar, ou se estiver diretamente envolvido
na análise do sistema, deve continuar sua leitura pelo capítulo 4. O
capítulo 5 se destina aos leitores que desejam compreender os detal-
hes de um modelo orientado a objetos criado com a notação da UML,
provavelmente por estarem envolvidos nas etapas de design e con-
strução de software. Uma alternativa possível para o leitor que desejar
uma visão rápida das técnicas de modelagem apresentadas aqui é ir
diretamente para o capítulo 6 e utilizar-se das referências citadas
neste capítulo para um aprofundamento nos itens de maior interesse
nos capítulos anteriores. Se no decorrer da leitura houver dúvida sobre
algum termo técnico empregado, o leitor pode procurar uma ex-
plicação no glossário de termos.
Com esta organização é possível cobrir várias possibilidades de
abordagem da orientação a objetos, desde uma abordagem mais form-
al, até uma abordagem mais prática e informal. Com um grande
número de exemplos, procura-se sempre apresentar as aplicações
típicas dos conceitos apresentados. O leitor deve, entretanto, manter-
se atento à limitação dos exemplos propostos e imaginar como utilizar
estes conceitos em seus próprios problemas e aplicações.
17/438
1.3. A importância da
modelagem
É fácil observar que outras áreas do conhecimento, as outras discip-
linas de engenharia, usam extensivamente da modelagem para repres-
entar seus projetos. A figura clássica de um engenheiro civil é alguém
envolvido com plantas e diagramas, gerenciando uma construção.
Uma planta de uma obra civil é uma representação gráfica do produto
final, o edifício. A planta permite que o cliente avalie o produto e
garanta que o resultado final é muito próximo do que ele deseja. A ca-
pacidade de gerenciamento da indústria da construção civil, permite
uma razoável precisão na data de entrega das obras graças à padroniz-
ação de processos de construção e a uma intensa padronização de
componentes. Com exceção talvez apenas da alvenaria, uma edificação
é composta de partes já construídas e que são integradas para formar
o produto final. Estas partes pré-fabricadas são os objetos da con-
strução civil.
A engenharia mecânica, na indústria automobilística por exemplo,
é uma indústria com um alto nível de automação, padronização e es-
pecialização. Um carro é fruto de um projeto básico que define os re-
quisitos para os projetos de cada peça. Ele movimenta uma grande
mercado para as indústrias de auto-peças que criam, isoladamente, os
objetos individuais do carro. A construção do carro é uma montagem,
uma integração de objetos.
A engenharia de software procura trazer para a ciência da com-
putação estas lições, e incentivar a elaboração de um projeto de soft-
ware, em um modelo orientado a objetos. Visando a padronização de
componentes de software, o projeto e o processo de desenvolvimento
são desenvolvidos segundo a orientação de se criar objetos.
Projetar software nada mais é do que construir um modelo do soft-
ware. Um modelo que representa, simplificadamente, o que se pre-
tende construir, como uma planta de uma residência. Um modelo que
mostra não só os requisitos do problema mas também como eles serão
atendidos pelos elementos da solução. Um modelo que permita avaliar
a qualidade da solução e simular o resultado final, de modo que pro-
jetista, cliente, construtor tenham todos uma mesma visão do projeto.
O processso de desenvolvimento de software é um processo com-
posto não apenas de componentes tecnológicos. Uma componente im-
portante, e decisiva para o sucesso de um empreendimento, é a com-
ponente social. A componente tecnológica nos projetos de software se
encontra, principalmente, nas atividades de contrução do software. A
componente social está ligada ao relacionamento entre o usuário e o
desenvolvedor, e uma parcela importante da interação do usuário com
o software. Pfleeger (1999) afirma que o sucesso do software depende
mais até do sucesso das interações sociais do que da aplicação da
tecnologia. Não se deve esquecer que software é desenvolvido por
pessoas para ser utilizado por outras pessoas. A interação do software
é uma interação entre pessoas, mediada pela tecnologia.
A qualidade de um software pode ser avaliada pela satisfação do cli-
ente. O cliente que se serve do software cria, ao estabelecer os requisi-
tos de um software, uma expectativa que só verá realizada quando o
software estiver concluído. Ao desenvolvedor cabe captar e atender es-
tas expectativas com as possibilidades de realização. Para isso cliente
deve contar, desde o início com um modelo do software.
Este trabalho objetiva auxiliar os desenvolvedores na criação de
modelos orientados a objetos dos sistemas de software. A principal
19/438
proposta é valorizar a atividade de criação do modelo para reduzir a
incerteza do software, aproximar a expectativa da realização, facilitar a
padronização e a automação dos projetos, incentivar a reutilização dos
componentes de software e aumentar a maturidade da engenharia de
software nas equipes de projeto.
20/438
2. Fundamentos da
Modelagem
Orientada a Objetos
Este capítulo descreve os conceitos fundamentais da modelagem
orientada a objetos por intermédio de um exemplo de aplicação. O
exemplo mostra a herança, o encapsulamento e a troca de
mensagens entre os objetos sob um ponto de vista prático. Apresenta
ainda as características principais do processo de desenvolvimento
de software, os fluxos de trabalho e a importância da modelagem de
objetos presentes neste processo.
2.1. Processo de
Desenvolvimento de
Software
O desenvolvimento de um software depende de muito trabalho dis-
ciplinado. Ter uma boa idéia para um software só não basta, ela deve
vir acompanhada da organização e da disposição necessárias para
realizar o trabalho de transformá-la em um produto. Um sistema de
software é resultado da união da criatividade , da tecnologia e do tra-
balho organizado. Um não funciona bem sem os demais. A tecnologia
sozinha não resolve os problemas, o esforço solitário fica isolado se
não for criativo. O que une a tecnologia com a criatividade e direciona
o trabalho é uma idéia comum, uma visão, representadaem um
modelo. Estudando-se as etapas para transformar uma idéia em um
produto de software, verifica-se a importância em criar um modelo.
Os métodos para desenvolvimento de software descrevem a
organização necessária para se criar um software. Métodos sugerem
passos a serem seguidos para cumprir o vazio existente entre a idéia e
o produto de software. Este estudo não pretende desenvolver um novo
método, nem tão pouco indicar um determinado método como sendo
o mais adequado. Pretende sim destacar algumas propriedades
presentes em todos os métodos, e observar que as técnicas de model-
agem estão no centro dos métodos, e dão a sustentação necessária
para a edificação do software.
Os métodos são organizados em fases, que caracterizam as etapas
de evolução pelas quais o software deve passar. Em cada fase uma
série de atividades são realizadas, produzindo documentos, esquemas
e diagramas que finalizam no código do programa de computador.
Sobre cada um destes subprodutos do método de desenvolvimento po-
dem ser realizados testes, para garantir que se está evoluindo na
direção prevista, e com a qualidade esperada.
Ao avaliar as etapas de um projeto de software, observa-se que elas
não são muito diferentes das etapas de qualquer outro projeto típico
de engenharia. Como todo projeto de engenharia, o projeto de soft-
ware tem como principal objetivo resolver um problema. A solução
do problema irá trazer benefícios para os usuários do produto do pro-
jeto, no caso, o software. A solução do problema, no caso da engen-
haria de software, é o próprio sistema de software.
Identificar os objetivos e reconhecer os requisitos do problema são
as atividades realizadas na fase de análise. Os requisitos variam de
caso para caso, e dependem de um bom entendimento da área de con-
hecimento na qual será desenvolvida o projeto, das condições iniciais e
das necessidades dos clientes. Pode-se dizer que a análise serve para
se formular o problema que o sistema irá resolver. Conhecidos os re-
quisitos e as necessidades do cliente pode-se elaborar uma estratégia
para resolver o problema, ou fazer, o que se chama aqui, do design da
solução. Na fase de design são tomadas todas as decisões que en-
volvem a solução do problema, e a partir dele inicia-se a construção
dos componentes da solução. Este componentes podem ser novos
ou reutilizados de outros projetos, já testados e aprovados. Com os
componentes da solução disponíveis realiza-se a integração que
coloca todas as partes juntas para se obter o produto final. É interess-
ante notar que esta descrição aplica-se igualmente à construção de
umar edificação, um projeto de instalação elétrica ou um projeto
mecânico qualquer. Esta coincidência sugere uma grande semelhança
na organização das atividades de engenharia seja qual for a disciplina.
23/438
Um elemento importante e presente em todos os projetos de engen-
haria são as plantas de engenharia. Todo projeto de engenharia é
realizado sobre uma planta, que é uma representação gráfica minu-
ciosa do que se pretende construir. Sobre a planta são avaliadas possí-
veis alternativas de solução, tomadas as decisões de projeto e a partir
dela são obtidas as orientações para a construção do produto. A planta
é, essencialmente, um elemento de comunicação entre os participantes
do projeto. A planta representa o projeto de uma forma simplificada, é
um modelo do sistema final.
Os modelos são contruídos para ajudar a entender um problema e
para comunicar este entendimento a outros. A simplicidade, própria
dos modelos, permite apenas que ele represente as informações im-
portantes, deixando de lado detalhes que dificultem a compreensão do
problema. Entendido o problema, o analista pode utilizar o modelo
para comunicar ao cliente o que entendeu e como pretende resolvê-lo.
O projetista comunica, por um modelo, como deverão ser construídos
os componentes e como estes serão integrados na solução. Terminado
o projeto, o modelo ainda ajuda a comunicar aos responsáveis pela op-
eração e manutenção do sistema, os cuidados que devem ser tomados
ao se realizar uma modificação ou um reparo no sistema. Como é uma
poderosa ferramenta de comunicação o modelo deve ser representado
em uma linguagem ao mesmo tempo precisa e clara, que comunique
sem gerar dúvidas de interpretação. Este é talvez o maior desafio da
modelagem, e a principal razão deste trabalho: como criar um modelo
de software claro, preciso e ao mesmo tempo simples.
Outra propriedade importante dos modelos é a de poder acompan-
har a evolução do projeto. No início, é comum os modelos serem apen-
as linhas gerais e esboços. Em alguns casos, nem os limites do prob-
lema estão ainda em definidos. Com um entendimento melhor do
problema, o modelo passa a agregar mais informação e a se tornar-se
uma visão mais completa de onde se pretende chegar. Um simples
24/438
esboço pode dar lugar a um diagrama mais preciso, a partir do qual
várias decisões de projeto podem ser tomadas. Concluída a etapa de
design, o modelo contém todas as informações necessárias para se ini-
ciar a construção da solução, o modelo está agora bastante detalhado e
preciso. Finalmente, com o produto construído e em operação é
importante manter-se o modelo atualizado e vivo, refletindo nele as
eventuais alterações feitas no produto quando ele sofre uma ma-
nutenção, ou são realizadas expansões.
O modelo é uma parte importante do projeto e deve evoluir com
ele. Assim é possível resumir as qualidades desejáveis de um modelo
como sendo a clareza, a precisão, a simplicidade e a facilidade de
evolução. A figura mostra um esquema das atividades em um projeto
de desenvolvimento de software qualquer, e a correspondente
evolução do modelo deste sistema.
Figura 3 - Esquema de um projeto de software
Com base neste esquema analisa-se a evolução do modelo no pro-
jeto de sistemas, as atividades realizadas para obtê-los e os principais
personagens envolvidos nestas atividades. Estuda-se, inicialmente, os
dois principais fluxos de atividades representados neste esquema: o
ciclo de desenvolvimento, representado pelas atividades do lado do
25/438
desenvolvedor, e o ciclo de teste do produto, representado pela seta
vertical à esquerda, do lado do cliente.
26/438
2.1.1. Ciclo de teste do
software
O ciclo de teste do software é um processo de responsabilidade
do cliente, ou do seu representante. Visa garantir que as necessidades
levantadas para a definição dos problemas estejam sendo atendidas
pelo produto. No ciclo de teste o cliente verifica se o produto fornecido
pelo ciclo de desenvolvimento está de acordo com os requisitos de pro-
jeto, e para isso ele realiza testes sobre o produto. Testes que colocam
o produto em situações de uso normal, e procuram detectar falhas e
novos requisitos não identificados ainda. Como um sub-produto dos
testes surgem correções e novas necessidades, que devem ser incor-
poradas aos requisitos de uma nova versão deste produto, dando iní-
cio a um novo ciclo de desenvolvimento.
Os clientes são todos os que contratam o serviço de desenvolvi-
mento do software, porque estão interessados pelo resultado que o
software irá dar ao seu negócio. Os clientes podem ser os usuários
finais, que irão usar o software, podem ser seus gerentes que devem
garantir a qualidade e a funcionalidade do software ou patrocinadores
do software que irão incentivar o desenvolvimento e arcar com seus
custos
• Gerente da aplicação é o responsável pela operação do
sistema no ambiente do usuário. Durante o desenvolvi-
mento do projeto o gerente é o lider dos usuários e atua
como facilitador dos relacionamento entre eles e a equipe
de desenvolvedores. Uma vez desenvolvido o sistema de
software o gerente da aplicação passa a responder por ele
internamente à organização.
• Usuário final é quem se utilizará do sistema para auxiliá-
lo em suas atividades. Em problemascomplexos os usuári-
os podem variar de departamento, função, hierarquia na
organização. Nestes casos é importante se criar um comis-
são de usuários, representativa da comunidade, para ori-
entar o desenvolvimento do sistema.
• Patrocinadores fazem parte do grupo de clientes que
dão apoio financeiro, técnico ou político ao desenvolvi-
mento do sistema. Este apoio é vital para que os desen-
volvedores possam ter acesso às informações e possam ex-
ecutar, se necessário, as alterações na organização para a
implantação do sistema.
28/438
2.1.2. Ciclo de
desenvolvimento do software
O ciclo de desenvolvimento do sistema é um fluxo de trabalho
cíclico que gera novos produtos a partir das informações obtidas no le-
vantamento de necessidades do problema. É dades cíclico porque o
produto de saída alimenta o ciclo seguinte, de modo que a cada volta
aproxima-se o produto das necessidades levantadas. Espera-se que o
ciclo seja convergente, isto é, em um determinado estágio o produto
atenderá todos os requisitos e poderá ser considerado terminado. Este
ciclo é realizado inteiramento no lado do desenvolvedor, mas possui
interações com o lado cliente, no ciclo de testes do produto.
O ciclo de desenvolvimento de um sistema é caracterizado por 4
atividades principais: análise, design, construção de componentes e
integração. A seguir verifica-se o papel do modelos nas fases e os papel
dos participantes de cada uma delas.
Fase de Análise
A análise é a fase de levantamento dos requisitos do problema a
ser resolvido. Nela estabelecem-se os limites do problema, e
identificam-se as necessidades do sistema. Deve-se procurar limitar a
análise exclusivamente ao problema em estudo, evitando a influência
de elementos que estão fora do escopo do problema. Detalhes de im-
plementação que podem ofuscar a definição do problema, falsos re-
quisitos, limitações inexistentes devem ser deixadas de lado. Para
ajudar o analista na busca de uma maior clareza nas definições inciais,
ele deve criar um modelo do problema. Este modelo deverá ter apenas
as informações relevantes para o entendimento do problema e deverá
receber a aprovação por parte do cliente, garantindo que o caminho
está correto e servindo de base para as demais fases do projeto.
As técnicas aplicáveis à análise são muitas, e dependem, gran-
demente, da experiência do analista. Quanto mais complexo o prob-
lema, mais difícil é a análise e mais importante o uso de modelos para
reduzir e gerenciar esta complexidade. Todas as informações obtidas
do cliente devem ser avaliadas e levadas em consideração na análise.
Não existe um momento preciso que indica o final da análise, mas o
analista pode identificar este momento quanto todas as facetas do
problema foram exploradas e a visão que o modelo traduz é suficiente
para iniciar as fases seguintes do projeto. Mesmo que alguns requisi-
tos foram esquecidos, não é motivo de preocupação, como o processo
de desenvolvimento é cíclico sempre será possível rever a análise e in-
cluir estes novos requisitos.
A análise é tarefa do analista de sistemas. Em projetos mais
simples esta atividade pode ser desempenhada por um desenvolvedor
sênior, ou pelo próprio gerente de projeto, se estes possuirem um con-
hecimento básico de modelagem de sistemas, e a disponibilidade para
entrevistar usuários, levantar e organizar as informações disponíveis
para o início do projeto. Em projetos mais complexos esta tarefa pode
ser dividida entre diversos profissionais como o Analista de Negócios,
o Analista de Documentação e o Analista de Banco de Dados.
• Analista de Negócios - deve ser um especialista na área
de conhecimento a que o sistema se destina, e tem como
objetivo identificar as responsabilidades que o sistema de-
ve cumprir para o negócio do cliente. O analista de negó-
cios pode desenvolver uma análise do retorno esperado
30/438
com o invetimento no sistema, e estudar a viabilidade téc-
nica do sistema, integrando-o ao ambiente computacional
existente. Os requisitos de negócio, as regras e os processos
de negócios devem ser modelados por este profissional.
• Analista de Banco de Dados - como uma grande parte
dos sistemas de informação são baseados na tecnologia de
banco de dados, é importante ter um entendimento preciso
das informações já existentes em bancos de dados, antes de
iniciar um novo projeto. O analista pode se utilizar de téc-
nicas próprias e ferramentas de software para criar os es-
quemas dos bancos de dados existentes e que serão úteis
para o novo projeto de sistema.
• Analista de Documentação - é o responsável por
elaborar a documentação do sistema, os documentos de es-
pecificação, manuais e diagramas. Como a fase de análise é
uma fase onde a geração de documentos é maior, é
importante ter-se um profissional técnico especializado en-
carregado da produção desta documentação. Uma prática
interessante pode ser a de produzir o manual do usuário do
sistema já na fase de análise, e utilizá-lo com parte da espe-
cificação técnica de requisitos do sistema.
Como parte importante da fase de análise temos um modelo inicial
do sistema que fará parte do documento de especificação, produto da
fase de análise. Porque as correções nas fases iniciais de um projeto
são sempre mais fáceis de serem feitas, do que em fases mais avança-
das, os documentos e os modelos desta fase devem ser, continua-
mente, avaliados e verificados pelos clientes.
31/438
Fase de Design
O design se concentra na solução do problema identificado na fase
de análise. Busca incorporar aos modelos, os elementos que formam
um sistema para resolver o problema de projeto. Como quase sempre
a seleção de uma estratégia de solução traz compromissos com outros
sistemas, deve-se, nesta fase, avaliar o melhor caminho, testar e escol-
her a alternativa de solução mais adequada. O designer conta com a
sua experiência e o apoio de modelos do sistema em projeto para apoi-
ar sua decisão.
O design é uma tarefa para engenheiros de software experientes.
Em um projeto mais complexo, diversos aspectos de um sistema de
software devem ser considerados, o que exige a participação de outros
especialistas, como o Engenheiro de Redes e o Designer de Interfaces.
• Engenheiro de Software - é o especialista em criar o
operar os modelos dos sistemas para levá-los ao código.
Deve possuir habilidade de conceber os componentes do
sistema e caracterizá-los de modo a que atendam os requis-
itos do problema. Pode testar soluções e se utilizar de
padrões de soluções já consagradas e aplicá-las a novos
problemas. O engenheiro de software deve garantir tam-
bém que as boas práticas de engenharia sejam respeitadas
no projeto, assegurando a qualidade do produto.
• Engenheiro de Redes - é um especialista importante
quando o sistema será implementado em um ambiente de
processamento distribuído. Neste caso, a comunicação
entre os componentes do sistema será feita pela rede de
comunicação de dados, que deve ser projetada para dar
vazão ao volume de comunicação esperado. Existindo uma
32/438
grande interação entre os componentes da solução pode
exigir, em alguns casos, que componentes especiais de
comunicação sejam especificados e construídos.
• Designer de Interfaces - é um especialista na comu-
nicação entre os usuários e o computador. É um profis-
sional muito importante em sistemas com grande interação
com os usuários como os sistemas para internet. O
aumento do número de usuários nos sistemas de inform-
ação tem feito com que este profissional tenha um papel
cada vez mais importante para a aceitação e para a usabil-
idade do sistema. Ele deve possuir a habilidade de e a cri-
atividade para criar metáforas para a operação do sistema.
Ao final da fase de design todas as definições do projeto devem es-
tar registradas no documento de especificação. Modelos, listas e es-
quemas servem como referências para osconstrutores dos compon-
entes e para a integração do sistema. O modelo produzido pelo design
pode variar muito no nível dos seus detalhes. No início do projeto ap-
resenta poucos detalhes mostrando conceitualmente a solução, para
uma avaliação inicial, ou para a validação de um cliente. Nos ciclos
mais avançados do projeto, o modelo deve estar muito bem detalhado
para determinar aos programadores todos os pormenores do software.
Fase de Construção doms
Componentes
Na fase de construção de componentes inicia-se as atividades
de programação na construção do software. A boa prática de con-
strução recomenda a adoção do conceito de componentes de software
33/438
reutilizáveis para reduzir prazos e custos no desenvolvimento,
mantendo a qualidadade do produto. É cada vez mais comum se
dispor de componentes pré-fabricados prontos para serem utilizados
em diversos projetos, organizados em um framework. Nestes casos a
construção de componentes se limitará a criar os componentes que
são específicos para o novo projeto.
A construção civil é um exemplo típico de padronização de peças
pré-fabricadas. Poucas são as partes criadas específicamente para uma
construção. Na área mecânica o exemplo mais interessante de criação
de componentes encontra-se na indústria automobilística, onde um
carro é efetivamente a montagem de peças e partes completas feitas
por outras empresas,. Muitas vezes a mesma peça é utilizada em difer-
entes carros. Esta abordagem ainda é nova na engenharia de software,
mas está, aos poucos, revolucionando o desenvolvimento de software.
A construção dos componentes é um trabalho para o progra-
mador de computadores, que é o especialista nas linguagens de
programação. Um mesmo sistema pode possuir compontentes escritos
em diferentes linguagens, no entanto, para facilitar a manutenção e
simplificar o sistema quanto menor o número de linguagens mais fa-
cilmente o sistema será mantido. O programador segue princípios e
práticas próprias, que não farão parte deste trabalho. Como uma
grande parte dos sistema atuais se utiliza de um banco de dados para
armazenar as informações e possui uma grande dose de interação com
os usuários, é importante também envolver na fase da construção out-
ros especialistas: o programador de banco de dados, o programador de
componentes e o programador de interfaces.
• Programador de interfaces é o profissional respon-
sável por desenvolver os componentes de interação entre o
sistema e os seus usuários. Os componentes de interface
devem se caracterizar pela facilidade de uso e pela precisão
34/438
na comunicação. O uso de uma interface gráfica e regras
próprias para criar estes componentes, projetador por um
designer, exigem que um programador especializado nesta
tarefa seja convocado para realizá-la.
• Programador de Componentes escreve os compon-
entes de negócio obedecendo as regras de negócio defini-
das pelo Analista de Negócios e projetadas pelo Engenheiro
de Software. Sua principal tarefa é garantir a qualidade do
componente, sua eficáfica e robustez. Utiliza, em geral,
uma linguagem robusta em um ambiente de desenvolvi-
mento próprio.
• Programador de Banco de Dados é um profissional
importante na fase de construção se houver necessidade de
criar componentes específicos para o armazenamento e re-
cuperação de informação. Em sistema orientados a objeto
o uso do banco de dados é limitado e organizado pelos ob-
jetos, sendo que este profissional deve ser responsável por
integrar os sistemas orientados a objeto com os sistema
legados em bancos de dados.
• Analista de Teste. Como o produto final da fase de con-
strução são os próprios componentes. Cada componente
próprio ou adquirido de ter terceiros deve ser testado indi-
vidualmente, para garantir que ele esteja de acordo com a
especificação do projeto. Este teste faz parte do processo de
criação de componentes mas não deve ser desprezado.
Pode-se criar, em projetos maiores, uma função específica
com esta responsabilidade, garantindo a sua qualidade e
funcionalidade. O analista de testes não pode ter uma fun-
ção acumulada com a função de programador, para evitar
um conflito de interesses.
35/438
Fase de Integração
A fase de integração encerra o processo de desenvolvimento ger-
ando, como produto final, uma nova versão do software. Nesta fase, a
atividade mais importante é a de configuração da versão do software,
compilando e instalando os componentes necessários nos equipamen-
tos servidores. É uma fase de trabalho minucioso e organizado, onde
se deve assegurar que todos os componentes necessários foram integ-
rados. Após este integração é importante realizar uma fase de teste. É
comum nesta fase se criar roteiros automatizados de teste, assim como
pode ser necessária alguma atividade de programação para integração
final dos componentes.
As atividades de integração podem, em sistemas mais simples, ser
realizadas pelo Engenheiro de Software ou pelo próprio Gerente
de Projetos. Em sistemas mais complexos é comum encontrarmos o
Gerente de integração ou Gerente de Configuração que irá co-
ordenar uma equipe de profissionais, os Integradores que respon-
derão pela união correta dos componentes.
Os modelos, na fase de integração, servem de mapa para a configur-
ação do sistema, e união dos componentes. Em muitos casos, não se
está interessado em criar um sistema totalmente novo, mas sim em
adaptar um sistema existente para as necessidades específicas de um
cliente. Chama-se ao processo de adaptar um software especialmente
para as necessidades de um cliente de customização[1]. O processo
de customização passa por todas as fases do processo de desenvolvi-
mento, mas tem uma ênfase maior na fase de integração, onde são
realizadas a maior parte das atividades de configuração do software.
36/438
2.2. Modelos de um
Software
O processo de desenvolvimento de um software apresentado é
baseado na evolução de uma visão que os desenvolvedores controem,
em conjunto com os clientes, sobre o problema a ser resolvido. Esta
visão é concretizada em modelos, que devem representar esta visão e
evoluir com ela. No início, a visão é incompleta e pode possuir ambi-
qüidades e distorções, que ao longo do processo de desenvolvimento,
com o entendimento do problema, são eliminadas. No final, o modelo
resultante é equivalente em significado ao código gerado para imple-
mentar a solução do problema, eles devem ter igual riqueza de detal-
hes e precisão.
Em um problema complexo, dificilmente uma visão única, com-
pleta e bem definida será obtida logo no início do processo. É import-
ante que os compromissos do software representados no modelo se-
jam assumidos aos poucos, acompanhando o entendimento que se tem
do problema. As técnicas de modelagem, que serão exploradas em de-
talhes nos próximos capítulos, ajudam os analistas e designers a docu-
mentar e comunicar o entendimento que adquirem do problema em
diagramas de forma precisa, evitando a construção de sistemas de
software inconsistentes.
Um único modelo apenas é insuficiente para representar todos os
fenômenos existentes em um sistema complexo, são necessários um
conjunto coerente de modelos com diferentes escalas, criados a partir
de diferentes pontos de vista. Jacobson (1992) propõe que a complex-
idade seja introduzida gradualmente no modelo do sistema, com a
ajuda de uma série de sucessivos modelos que aos poucos são capazes
de gerenciar essa complexidade. Ele propõe 5 tipos diferentes de
modelos:
• modelo de requisitos, que captura requisitos funcionais do
sistema,
• modelo de análise, que dá ao sistema uma estrutura de
objetos,
• modelo de design, que refina esta estrutura para a
implementação,
• modelo de implementação, que efetivamente implementa o
sistema,
• modelo de teste que verifica o sistema.
Este estudo utiliza apenas três modelos para representar os sistemade software:
• modelo de contexto,
• modelo conceitual e
• modelo detalhado.
A idéia central aqui também é introduzir a complexidade aos pou-
cos. O modelo de contexto equivale ao modelo de requisitos de Jacob-
son, enquanto o modelo conceitual se equivale ao modelo de análise
de Jacobson. O modelo detalhado pode ser aplicado ao design, à im-
plementação ou ao teste do sistema, dependendo do nível de detalhes
e da finalidade a que ele se destina; assim, substitui os 3 outros mode-
los propostos por Jacobson.
O modelo de contexto inicia a definição do problema. É con-
struído em uma escala grande, onde grande parte dos detalhes do
problema estão encobertos. Representa os aspectos funcionais de alto
nível do sistema, analogamente ao modelo de requisitos de Jacob-
son (1992). Serve para representar o sistema proposto no contexto do
38/438
negócio do cliente. Deve possuir uma representação simples, sem uma
formalidade excessiva, para poder ser entendido e validado pelo cli-
ente, que normalmente é leigo em assuntos de software. No modelo de
contexto define-se a fronteira do problema e os principais objetivos
que o sistema deve cumprir para os seus usuários. Este modelo é, es-
sencialmente, desenvolvido durante a fase de análise pois refere-se,
principalmente, à uma visão do problema a ser resolvido. Deve ser
possível ao modelo de contexto situar o sistema no contexto do cliente,
identificando pontos de integração com outros sistemas já existentes e
caracterizar a contribuição do novo sistema.
O modelo conceitual é um modelo que reúne todos os conceitos
presentes no problema em estudo. Construído com uma escala menor
do que o modelo de contexto, cria a estrutura do sistema, usando para
isso um modelo simplificado de classes. Nele devem estar representa-
das os principais componentes do sistema e suas relações. No modelo
conceitual está caracterizada as proposta de solução do problema, mas
sem o detalhe necessário para a sua implementação. A idéia central é
representar, simplificadamente, em poucos diagramas, o sistema
como um todo e as partes principais que o constituem. Como o modelo
final do sistema pode ser muito complexo, o modelo conceitual serve
de índice, de orientação, para que dele sejam detalhados os modelos
de implementação. É um modelo desenvolvido nas fases de análise e
design porque recebe não só os detalhes do problema a ser resolvido,
como também os elementos incorporados ao modelo durante o design
da solução.
A quantidade de detalhes do modelo conceitual deve estar entre a
abstração do modelo de contexto e a grande quantidade de detalhes do
modelo detalhado. Como o modelo conceitual possui um nível maior
de detalhamento que o modelo de contexto, é possível, a partir dele es-
tabelecer um planejamento do desenvolvimento e um dimensiona-
mento mais preciso dos recursos necessários para a construção do
39/438
sistema. Estas definições são impossíveis de serem feitas apenas com o
modelo contextual, assim o modelo conceitual assume também um
importante papel no gerenciamento do processo de desenvolvimento
de software.
O modelo detalhado, por sua vez, incorpora todos os detalhes de
uma versão projetada do software. O modelo detalhado pode possuir
um nível de detalhe equivalente ao código do software, podendo-se até
criar uma correspondência biunívoca com ele. Para cada versão de um
software o modelo detalhado pode mudar, incorporando as novidades
desta versão. Podem ser gerados quandos modelos detalhados quantas
versões do produto existirem. O objetivo principal do modelo detal-
hado é a construção do sistema, assim nele devem estar representados
todos os detalhes construtivos e as definições de projeto. É um modelo
que se inicia na fase de design, com os detalhes com componentes a
serem construídos e é detalhado na fase de construção. Como o mode-
lo detalhado possui uma escala ainda menor que o modelo conceitual,
os detalhes do sistemas são revelados com precisão, na medida da ne-
cessidade do desenvolvimento, seja para uma maior definição precisa
do design, seja para implementação ou seja para testes.
A figura abaixo mostra, de forma esquemática, as relações entre a
escala proposta de modelos e os produtos de software em suas diver-
sas versões.
40/438
Figura 4 - Seqüência de Modelos em um Projeto de Software
Típico
41/438
2.3. Documento de
Especificação de Projeto
O principal documento do desenvolvimento do software é o Docu-
mento de Especificação de Projeto. Como seu próprio nome diz, ele
deve descreve, detalhadamente, o projeto de um software. Normal-
mente, a especificação é tomada como um documento feito para ori-
entar a construção do software, mas neste estudo a especificação é
tomada como um espelho do projeto do sistema, e assim deve ser
mantida atualizada durante toda a evolução do sistema, inclusive após
a sua construção. Na fase de análise a especificação deve considerar os
objetivos do problema, apresentando os modelos de contexto e con-
ceitual. Na fase de design a especificação recebe os detalhes das
soluções escolhidas, para que na construção todas as alterações no sis-
tema possam ser representadas em modelos detalhados na
especificação. Mantém-se assim o documento vivo, acompanhando to-
do o projeto do sistema.
Como este trabalho não se propõe a apresentar um método para
desenvolvimento de um software, o documento de especificação não
será detalhado. Entretanto, é de esperar, encontrar muitos diagramas
e modelos em um documento de especificação de software.
2.4. A Modelagem
Orientada a Objetos
Para criar um modelo é preciso escolher o que é considerado im-
portante, e por isso será representado no modelo, do que pode ser
omitido. A seleção do que é, e do que não é, importante segue um
paradigma, um ponto de vista, uma forma de olhar a realidade que se
vai modelar. Descreve-se aqui algumas características dos diferentes
paradigmas usados para modelar sistemas de software.
Para desenvolver um sistema de software é necessário criar uma
visão do problema, representada em um modelo que orienta o pro-
cesso de desenvolvimento. Para se estabelecer esta visão deve-se
definir um ponto de vista, isto é, deve-se a olhar o software segundo
um paradigma. O paradigma define uma unidade de decomposição do
sistema, destacando alguns aspectos em prejuízo de outros. Algumas
possíveis visões e as unidades de decomposição associadas são:
• A Visão Funcional decompõe um sistema em funções;
• A Visão dos Dados decompõe um sistema em estruturas de
dados; e
• A Visão de Objetos decompõe um sistema em classes de
objetos.
A visão funcional valoriza o fluxo de informação do sistema,
buscando responder o que o sistema deve fazer. A idéia, que se traduz
em uma análise funcional, é a de definir o sistema como uma grande
função, que pode ser quebrada em funções menores, em uma técnica
de análise chamada de análise top-down (de cima para baixo). Este
procedimento parte do princípio que um sistema de software deve
fazer algo para o seu usuário. Uma função complexa pode ser decom-
posta em funções mais simples, continuamente, até que a quebra fun-
cional leva a funções tão simples a ponto de poderem ser implementa-
das e testadas. Testadas isoladamente, as funções elementares são
agrupadas e integradas em uma estratégia de integração botton-up (de
baixo para cima). Integrando todas as funcionalidades tem-se, ao fi-
nal, o sistema completo com toda a funcionalidade pretendida.
O termo “função” é quem orienta todo o processo de desenvolvi-
mento. O que o sistema deve fazer conduz o processo de análise e con-
strução. Por isso, se for necessário introduzir alterações, modificações
e novas funcionalidades nos softwares desenvolvidos sobre este
paradigma a tarefa mais difícil. Ao se introduzir uma alterção, uma
série de outras funcionalidades que decorreram desta podem ser
afetada. A quantidade de códigoenvolvido pode ser muito grande, in-
viabilizando grandes mudanças em sistemas desenvolvidos sob uma
visão exclusivamente funcional.
Figura 5 - Esquema da Modelagem Funcional
44/438
Na modelagem de dados, outro paradigma possível no desenvol-
vimento de software, o destaque se volta para a estrutura da inform-
ação que é tratada pelo sistema, ao contrário das operações ou funções
às quais estas informações estarão sujeitas. A estrutura da informação
de um sistema corresponde ao conjunto organizado de entidades que
guardam alguma informação para o software e como elas se rela-
cionam. O princípio por trás da modelagem de dados é que um sis-
tema de informação processa informação. Dá-se uma maior em qual
informação é processada e não em como se dá este processamento.
Na modelagem de dados não há lugar para representar as caracter-
ísticas dinâmicas do problema, suas funções, operações ou algorítmos.
Ainda que algumas regras de negócio reflitam apenas em elementos
estáticos ou limites destes elementos, a maioria das regras de negócio
exige a criação de algorítmos mais complexos que não encontram ab-
rigo no modelo de dados. Existe, entretanto, na modelagem de dados
uma grande reutilização das informações armazenadas e da sua estru-
tura. A capacidade em se adaptar uma mesma estrutura de dados em
problemas semelhantes é muito grande, dando amplas possibilidades
de uma grande reutilização deste tipo de modelo. Problemas semel-
hantes usam estruturas de informação semelhantes.
É importante se observar que nem sempre a estrutura da inform-
ação reflete a estrutura do problema. Algumas vezes redundâncias e
hierarquias presentes no problema são eliminadas ao se analisar apen-
as a informação armazenada. O processo de normalização de tabelas
de um banco de dados é um exemplo desta simplificação.
Outra observação importante é que um sistema exige dados e fun-
ções, e que nem sempre uma abordagem permite uma visão se integra
perfeitamento na outra. Desenvolver um sistema pelo paradigma de
dados ou pelo paradigma funcional resulta em um sistema com grande
acoplamento, onde qualquer modificação necessária, seja em dados,
45/438
seja em funções pode resultar em um trabalho complexo demais. A
figura mostra que um dado pode ser necessário para mais de uma fun-
ção e que que modificar um dado requer modificar muitas funções.
Figura 6 - Um programa combina dados e funções
A orientação a objetos enfoca a busca da estrutura do problema,
e não apenas da informação. Identifica em objetos, os elementos im-
portantes do domínio do problema, que guardam dados e possuem
funções que podem operar seus dados. Não são apenas as funções que
o sistema deve desempenhar, como na modelagem funcional, nem
somente os dados que serão armazendados, como na modelagem de
dados; a importância maior é encontrar os elementos do problema que
possuem todas estas propriedades.
Sebesta (1996) estuda a evolução das linguagens de programação e
verifica que enquanto a programação procedural foi desenvolvida na
década de 70, na década de 80 começou-se a combinação de algorit-
mos e estruturas de dados em objetos com a linguagem Smalltalk. As
idéias da programação orientada a objetos foram incorporadas à lin-
guagem C gerando C++ que ajudou a popularizar as linguagens ori-
entadas a objeto.
46/438
Apesar de ser possível haver programação orientada a objetos
desde 1980, os conceitos que envolvem o projeto de sistema com esta
filosofia não são simples, e por isso demoraram a ser utilizados pela
comunidade de desenvolvedores. Os programas continuavam, até
meados da década de 90, a serem projetados com uma separação clara
entre a análise funcional e a análise de dados. Num sistema onde
qualquer função pudesse se utilizar de qualquer dado armazenado,
seria impossível saber quais dados são necessários para cada função,
sem analisar cada uma das funções separadamente. Esta grande de-
pendência entre os dados e as funções dificulta uma alteração nos da-
dos ou nas funções, porque as conseqüências são imprevisíveis. É im-
portante criar um critério para se unir dados e funções em conjuntos
organizados e coerentes. Desta idéia surge a modelagem orientada a
objetos.
Um objeto, segundo Jacobson et al (1992), é caracterizado por um
conjunto de operações e um estado que armazena os efeitos das oper-
ações que o objeto é capaz de realizar. Assim os dados armazenados no
estado objeto servem para armazenar o efeito das funções, criando-se
o vínculo desejado entre as operações e os dados. Os objetos tem uma
dimensão maior do que apenas os dados e as funções isoladamente,
como exemplifica a figura.
47/438
Figura 7 - Objetos reúnem dados e funções
A orientação a objetos parte da constatação que o mundo é formado
por elementos autônomos e relativamente independentes, e que criar
um modelo de um sistema de software é identificar quais destes ele-
mentos são relevantes para o software. Os objetos que devem ser in-
cluídos no modelo são os que realizam algo de destaque para o prob-
lema em questão. Esta abordagem reduz a distância entre o modelo e o
mundo real, porque utiliza elementos da realidade para criar o mode-
lo, facilitanto o entendimento do problema pelo analista e pelo cliente.
Selecionar a orientação a objetos para analisar um problema, inclui
uma série de características intrínsicas à tecnologia de objetos que de-
vem ser bem entendidas para que o analista possa fazer um uso cor-
reto deste paradigma. Dentre estas características destacam-se o con-
ceito de encapsulamento das classes, a herança, a troca de mensagens
e o polimorfismo. Estas características serão apresentadas a seguir,
acompanhadas de exemplos práticos que visam a facilitar o
entendimento.
48/438
2.4.1. Encapsulamento
Todos os dados e operações necessárias para um objeto existir, e
realizar suas responsabilidades para o sistema, devem estar
armazenadas no próprio objeto. Diz-se que o comportamento e os da-
dos estão encapsulados no objeto. Envoltos em uma cápsula os dados
dos objetos não estão mais isolados das funções, eles caminham
juntos.
Figura 8 - Esquema do encapsulamento
O encapsulamento é a principal característica para se identificar um
objeto. O princípio por trás desta idéia é que o objeto possua todos os
dados e as funções necessárias para sua existência. Selecionar um ob-
jeto da realidade para o modelo indica que ele representa algo que ex-
iste de fato no domínio do problema, e que será transportado para o
domínio do modelo do software, com toda a sua autonomia.
Figura 9 - Um objeto deve representar algo que existe de verdade
Um lâmpada, como a da figura, é um objeto importante, por exem-
plo, para um sistema de controle doméstico. As propriedades que a
lâmpada possui, para este sistema são uma tensão elétrica e um preço.
A lâmpada oferece para este sistema as funcionalidades de acender a
um determinado preço pelo qual foi comprada.
O encapsulamento protege os dados de um objeto do acesso
descontrolado por outros objetos. O acesso é realizado por intermédio
de mensagens trocadas entre objetos, que nada mais são do que cha-
madas das funções do objeto. Apenas a interface do objeto, formada
pelo conjunto de funções, é exposta, oferecendo serviços deste objeto
ao mundo exterior. Como as mensagens passam por uma função do
objeto antes de acessar os dados, esse acesso é controlado e o dado
protegido. As informações do objeto e como ele implementa estes ser-
viços são mantidos ocultos. A este conceito chamamos de ocultamento
de informações, e é outra decorrência importante do encapsulamento
de objetos.
O encapsulamento dos objetos encontra analogia em diversas situ-
ações da vida diária. Um exemplo de sucesso de encapsulamento
presente em nossas casas é o caso do aparelho de TV e do aparelho de
reprodução de DVD. Vamos observar que as funções da TV e da unid-
ade de DVD são muitobem definidas: o aparelho de TV possui como
função apresentar imagens, enquanto o a unidade de DVD reproduz
50/438
imagens armazenadas no formato padrão do DVD. Eles se comple-
mentam para servir o seu usuário, e ao mesmo tempo se mantêm
independentes.
Figura 10 - Exemplos reais de encapsulamento
Além das funções específicas, os aparelhos possuem uma interface
bem definida e padronizada que permite que sejam operados sem a
necessidade de se conhecer o funcionamento interno dos aparelhos.
Assim como nos objetos, estes aparelhos protegem os componentes e
suas informações de um uso indevido, expondo apenas uma interface
externa.
O encapsulamento implica em outra característica própia da ori-
entação a objetos, que é a colaboração entre os objetos pela troca de
mensagens. A integração dos componentes ocorre interligando a saída
de um objeto com a entrada do outro, de modo que um objeto possa
acionar uma função do outro objeto. De modo análogo, o DVD se
comunica com a TV para utilizar a função de exibição de imagens. O
aparelho de DVD pede à TV que apresente as imagens, e para isso ele
envia pela interface externa de comunicação , a mensagem com a im-
agem a ser apresentada. A operação em separado dos aparelhos é
51/438
confiável e segura, o que leva a uma confiabilidade e segurança da op-
eração em conjunto.
O encapsulamento leva à reutilização, outro grande benefício da
orientação a objetos. Com ela é possível separar a criação de objetos,
da integração destes objetos em sistemas. A reutilização é uma das
conseqüências mais procuradas no projeto orientado a objeto, pois
dela decorre uma redução no custo do desenvolvimento de novos sis-
temas e uma maior facilidade de manutenção e expansão. Um objeto
bem projetado, testado e confiável pode ser utilizado em diversas situ-
ações, diluindo o seu custo entre várias aplicações. A manutenção é
simplificada e a expansão pode ser realizada de forma mais contro-
lada. Usando ainda o exemplo da TV e do DVD deve-se observar que a
TV pode ser utilizada como um objeto para apresentação de imagens
em diversos sistemas de multimídia, assim como quando um aparelho
de vídeo cassete pode ser substituido, quase sempre, por um aparelho
de DVD, mais moderno, sem necessariamente alterar o aparelho de
TV.
Figura 11 - Exemplo de interface padronizada
A figura mostra uma interface padronizada para a operação da
maioria dos aparelhos eletrônicos de reprodução de som e imagem. O
uso repetido permite que seja qualquer for a implementação interna, o
usuário saberá o que irá acontecer se escolher a seta (reproduzir) ou o
quadrado (interromper).
O que caracteriza um encapsulamento eficiente é a definição pre-
cisa da interface. A interface é a a lista dos serviços que o objeto
oferece, ela esconde como o objeto as implementa. Muitas interfaces já
52/438
estão padronziadas e há um grande esforço geral de padronização para
tornar o acesso aos serviços de objetos mais fácil e simplificado. Ex-
istem boas perspectivas para a modelagem orientada a objetos nos
serviços de objetos distribuidos. Diversos serviços comuns a muitos
sistemas podem ser oferecidos aos objetos desde eles atendam a uma
interface padronizada, como o padrão CORBA ou o padrão EJB. (Or-
fali, 1998).
53/438
2.4.2. Mensagens
A comunicação entre os objetos se dá por meio de mensagens.
Um objeto que desejar uma informação de outros objetos deve solicit-
ar às funções destes objetos, na forma de mensagens, que responda ao
seu pedido. Como um sistema é formado por um conjunto de objetos,
o processamento do sistemas é obtido mediante a troca de mensagens
entre os objetos.
Uma mensagem é a chamada de uma função de um objeto, é o acio-
namento de uma operação encapsulada no objeto de destino, feita a
partir do objeto de origem. A informação transmitida é passada ao ob-
jetos de destino pelos parâmetros da função, enquanto a resposta da
mensagem é obtida pelo parâmetro de retorno da função. Assim, por
definição, toda mensagem tem uma resposta de retorno e pode trans-
mitir uma informação na chamada e no retorno.
Para que os objetos se comuniquem é necessário que haja algum
tipo de vínculo integrando estes objetos. Estes vínculos, que podem
ser relacionamentos existentes entre os objetos, asseguram um conhe-
cimento que um objeto tem da existência do outro.
Figura 12 - Troca de mensagens entre objetos
Retomando o exemplo o DVD, nota-se que ele se comunica com a
TV por intermédio da função de exibir imagens que a TV possui. Esta
função está disponível na interface da TV, o que permite que outros
aparelhos possam servir a TV com imagens. Outra forma interessante
de comunicação existente entre estes objetos é a comunicação exist-
ente entre os equipamentos eletrônicos e o controle remoto. O con-
trole remoto recebe os comando do usuário e os transmite para a TV
como mensagens. Esta comunicação é facilitada porque as interfaces
entre o controle e a TV, e entre a TV e o DVD são padronizadas.
O que permite esta forma de comunicação entre os objetos é a
definição de uma interface precisa. Assim, como o encapsula-
mento isola as estruturas internas do objeto, ele deve expor uma inter-
face que permita que o objeto receba mensagens de outros, formando
o sistema. Vale observar que a comunicação entre os objetos é
55/438
bastante restrita, as mensagens recebidas por um objeto se limitam às
operações expostas na interface. Caso o sistema exija que uma nova
mensagem seja enviada, é necessário criar uma função específica para
receber esta mensagem no objeto de destino. A definição das inter-
faces e das mensagens a serem implementadas nos objetos é uma im-
portante atividade de modelagem do sistema, desempenhada durante
a fase de design no projeto de um software.
Figura 13 - Exemplo da comunicação entre objetos
56/438
2.4.3. Tipos, Classes e
Objetos
Aplicando o encapsulamento em larga escala, observa-se que ex-
istem grupos de objetos compartilham a mesma interface, isto é,
apesar se serem objetos distintos, oferecem os mesmos serviços para o
sistema. Estes objetos seguem a mesma estrutura e definem o que
chama-se de um tipo abstrato de dados. Um tipo é uma estrutura de
dados com um conjunto de definições de operações que afetam esta
estrutura. No tipo não existe a preocupação de implementar estas op-
erações, ele serve apenas para se definir um padrão no modelo, re-
duzindo a complexidade da modelagem.
A implementação de um tipo é uma classe. A classe possui, além
das definições, a implementação das operações, para criar um com-
ponente autônomo para o sistema. A classe é um molde para a criação
de objetos, porque permite descrever um conjunto de objetos que
compartilha a mesma estrutura de dados e as mesmas definições oper-
ações. Todos os objetos de uma classe possuem as mesmas definições
mas podem possuir valores diferentes nos dados, respondendo de
modo diferente às mensagens enviadas à ele.
Figura 14 - Exemplos de Classes e Objetos
Um objeto é uma instância de uma classe, ele realiza a classe para
o sistema. A estrutura do objetos é definida pela classe, mas as oper-
ações e estados são definidos na instância (Jacobson, 1992). No
mundo real os objetos existem e trocam mensagens. É a partir destes
objetos que se abstrai as classes para o modelo, porque no modelo se
está interessado nas estruturas dos objetos. O processo de classi-
ficação dos objetos, isto é, determinar a classe a que o objeto deva per-
tencer, é a essência da modelagem orientada a objetos.
Em um exemplo típico de uma instalação de engenharia é possível
classificar os equipamentos como equipamentos elétricos e equipa-
mentos hidráulicos. A figura abaixo mostra esta classificação na forma
de conjuntos . As classes estão associadas aos conjuntos,e os objetos
aos seus elementoss destes conjuntos, que compartilham as mesmas
propriedades. Pertencerao conjunto equivale dizer que o elemento
compartilha algumas características. Podem existir equipamentos que
possuem características de mais de um conjunto.
Figura 15 - Subclasses da classe Reprodutor de Imagens
O exemplo pode mostrar a classificação não é única e pode estar
sujeita a múltiplas interpretações, dependendo do enfoque que se
58/438
queira dar ao problema. O importante é verificar em cada classe quais
as propriedades que estão sendo compartilhadas pelos seus elementos,
para haver uma boa relação entre o modelo e a realidade.
Figura 16 - Classes se assemelham a conjutos de objetos
59/438
2.4.4. Herança
A herança é uma das principais características da orientação a obje-
tos, e que está intimamente associada ao conceito de agrupamento dos
objetos segundo um conjunto de propriedades comuns. Uma classe de
um objeto é o agrupamento de objetos que compartilham a mesma es-
trutura de dados e funções. É possível se encontrar grupos que pos-
suam um conjunto de propriedades, e que a partir deste grupo seja
possível criar outros grupos que possuam propriedades ainda mais es-
pecíficas, formando assim um subconjunto do anterior. A orientação a
objetos permite criar uma relação entre as classes de objetos de modo
que classe pode ser gerada a partir de outra classe, herdando dela suas
propriedades estáticas (atributos) e dinâmicas (funções).
A herança permite ainda que as características herdadas da classe
mãe possam ser alteradas e expandidas pela classe filha. Incluindo
novas características, ou modificando características existentes. Esta
capacidade dos modelos orientados a objetos permite que a model-
agem seja feita em camadas de classes, criando uma árvore para cada
classe, com um nível decrescente de abstração, quando se caminha da
mãe para a filha.
O uso da herança permite criar classes mais genéricas, com fun-
cionalidades gerais e que podem ser herdadas por várias classes em
diferentes situações simplificando a modelagem e implementação. A
herança de classes aumenta muito a capacidade de reutilização das
classes, porque pode-se criar classes genéricas com propriedades
gerais e que podem ser utilizadas em diversas situações. O reuso de
classes apresenta um efeito positivo no prazo e no custo do desenvolvi-
mento de projetos de software.
Figura 17 - Exemplo real de herança
No exemplo, a herança é utilizada para distribuir os equipamentos
em categorias. Observa-se que, inicialmente, todos são equipamentos.
Os equipamentos podem ser para casa, podem ser elétricos e podem
ser mecânicos. Alguns equipamentos para casa são também elétricos,
criando a classificação dos eletrodomésticos.
O conceito de herança e de objetos em software não é novo, mas foi
pouco utilizado nos projetos de sistema até que as linguagens de pro-
gramação que permitissem implementar em software estes conceitos
com facilidade. Hoje existem várias linguagens orientada a objetos que
permitem incorporar herança e encapsulamento nos sistema de
software.
61/438
2.4.5. Polimorfismo
Uma decorrência interessante da comunicação por mensagens e da
herança a orientação a objetos é o polimorfismo. Define-se polimor-
fismo como a propriedade que o emissor de uma mensagem não pre-
cisa conhecer a instância da classe que recebe esta mensagem. (Jacob-
son, et al, 1992). Esta propriedade leva ao fato de que uma mesma
mensagem pode ser interpretada de modos diferentes, quando for re-
cebida por objetos diferentes. Assim, como as implementações das
funções que recebem a mensagem são diferentes elas podem respon-
der de forma diferente (poli = múltiplas, morfo="forma"). Polimor-
fismo é a propriedade de que a mesma mensagem pode ser respondida
de forma diferente por duas ou mais classes.
Há alguma confusão entre o encapsulamento e o polimor-
fismo porque ambos se referem ao ocultamento da implementação do
mundo externo ao objeto. No entanto, o polimorfismo está centrado
na possibilidade de uma resposta diferente devido ao desconheci-
mento do destinatário da mensagem, enquanto no encapsulamento a
implementação está apenas oculta do mundo exterior.
Figura 18 - Polimorfismo: a mesma mensagem tem respostas
diferentes
63/438
2.4.6. Vantagens da
Orientação a Objetos
• Ao escolher desenvolver um software pelo paradigma de
objetos, o desenvolvedor procura obter uma série de vant-
agens, decorrentes das características desta abordagem:
• O uso de objetos na modelagem torna mais fácil descrever
as estruturas e o comportamento existente no mundo real.
Essa proximidade faz com que os clientes possam se identi-
ficar mais diretamente com os problemas nos modelos.
• O encapsulamento do conhecimento em componentes isola
o comportamento, o que permite que as mudanças nos re-
quisitos possam também serem isoladas em cada compon-
ente sem afetar o sistema como um todo.
• O uso de classes e objetos facilita a integração das fases do
processo de desenvolvimento, porque ao contrario de out-
ros modelos onde cada fase possui técnicas e paradigmas
próprios, na orientaçã a objetos o mesmo paradigma é con-
duzido da análise à construção.
• O encapsulamento favorece o teste dos sistemas de soft-
ware, que pode ser isolado para cada componente. O res-
ultado é um aumento na qualidade do sistema.
• O encapsulamento permite ainda que os componentes pos-
sam ser desenvolvido por fornecedores diferentes,
• A reutilização, decorrente do encapsulamento, reduz custos
e prazos no desenvolvimento de software porque possibil-
ita que o mesmo componente seja usado em vários
projetos,
• A herança associada ao encapsulamento permite abordar
problemas mais complexos do que com outras abordagems
de desenvolvimento. A herança cria uma família de objetos
com uma complexidade crescente e que podem ser aplica-
dos em vários problemas diferentes.
Algumas das vantagens da orientação a objetos podem ser com-
pravadas na prática com o estudo de caso que se segue.
65/438
2.5. Estudo de Caso:
Automação de Vendas
Para melhor entender os conceitos da tecnologia de objetos, segue
um exemplo da aplicação desta tecnologia. O objetivo é destacar, did-
aticamente, as características da orientação a objetos em um sistema
que reproduz uma automação de vendas. Não se pretende resolver o
problema de automação comercial, mas utilizar como exemplo o prob-
lema do sistema de informações para apoio às vendas em uma loja.
Como um sistema de informação gerencial, ele deve atender as regras
do negócio e, simultaneamente, ser flexível para acomodar as
mudanças destas regras, resultado natural da evolução do negócio. A
adoção do paradigma de objetos ajuda a obter esta flexibilidade, con-
seguida pelo uso correto das características desta tecnologia como: en-
capsulamento, as mensagens, a herança e o polimorfismo, que serão
demonstradas a seguir.
Este estudo de caso também serve para exemplificar a abrangência
e aplicabilidade dos modelos em um sistema prático. Inicia-se formu-
lando o problema por meio de uma visão do contexto onde este sis-
tema se encontra. Segue-se construindo um modelo conceitual do sis-
tema, que define as principais classes do sistema e suas relações. Das
definições preliminares passa-se para um detalhamento que se traduz
na implementação do sistema. O escopo do exemplo é limitado ao en-
tendimento dos princípios da orientação a objetos, sem descer em de-
talhes excessivos dos códigos e das opções de implementação, que po-
dem ser encontrados no capítulo 6, no final do livro.
2.5.1. Contexto do
Problema
O estudo de caso ocorre com uma loja de departamentos e o seu
processo de venda. Um cliente escolhe os produtos que deseja com-
prar. Ele se encaminha a um caixa que deve finalizar a venda. Em ger-
al, o caixa possui um terminal com um leitor de código de barras que
obtém, com base em um código, o preço dos produtos. Alguns
produtos podem ter