Modelagem Orientada a Objetos Com UML

Prévia do material em texto

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
complementar. Especialmente nos capítulos iniciais, onde o livro tece os fundamentos
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 Computador 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 podem 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écnica de desenvolvimento. Como um projeto orientado a objetos requer uma
grande dose de modelagem, este livro pode uniformizar os termos usados na
comunicação com a equipe de projeto e ajudar a definir as etapas e produtos do projeto
de software.
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 recebem 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 componentes 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 livro. 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 
 
 
 
 
 
 
 
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 modelo do software ser colocado no centro do processo de
desenvolvimento, como forma de unificar a visão do software entre os participantes
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 habilidades 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 discipliando. O computador, uma das
maiores invenções do homem, é uma mero escravo do software. Todas as maravilhas
que um computador é capaz de desempenhar, dependem, diretamente, da
disponibilidade 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 computadores são meros autômatos, sabem realizar com
grande velocidade, 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 programaçã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 programa 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 propriamente dito, e seus equipamentos periféricos, que em
conjunto compõem o que se pode chamar de sistema computacional. O conjunto de
partes relativa ao software no sistema computacional é o chamado sistema de
software.
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 problema que se pretende resolver, e fazer o design da solução. Desenvolver
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 informação gerencial até a transmissão de voz e imagem em equipamentos
de telecomunicação. O software é hoje uma tecnologia onipresente. Do telefone ao
despertador, da televisão ao supermercado, do brinquedo 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 Software afirmando, que 
as práticas de engenharia de software se intensificaram com o agravamento dos
problemas relativos ao software:
a) A sofisticação dos problemas ultrapassaram a nossacapacidade 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
Observa-se, nestas considerações, que a Engenharia de Software 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 software 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 computadores 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 software 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 linguagens 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
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 modelagem. A disponibilidade e ampla
divulgação destas linguages são as grandes motivadoras para a evolução da análise e
do projeto de sistemas 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 é organizar um conjunto coerente de técnicas de
análise e projeto de sistemas orientados a objetos, de modo que o modelo construído
por estas técnicas sirva de ponte para a construção do software.
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 objetivos 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 desenvolvimento de software.
Capítulo 2 - Fundamentos da Modelagem Orientada a Objetos. Apresenta os
conceitos fundamentais da orientação a objetos e a sua relação com o processo de
desenvolvimento de software. As características que diferem a abordagem de objetos
das outras abordagens são aqui descritas com detalhe. Os conceitos de encapsulamento,
heranç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 problema 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 sistema de software dos componentes
externos ao software, mas que interagem com ele. Este capítulo é especialmente
importante para os leitores envolvidos nas definições iniciais de um sistema
computacional, que devem, em contato direto com os clientes do software, especificar
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 definiçã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
modelo. Este capítulo é recomendado para os leitores envolvidos na concepção de
sistemas, com experiência ou não em sistemas não orientados 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écnica dos cartões CRC como um método que permite envolver os clientes e
usuários no levantamento de requsitos de projeto e no processo de concepção do
software.
Capítulo 5 - O Modelo de Detalhado de Objetos. Descreve, finalmente, os
diagramas do modelo orientado a objetos na notação proposta pela UML: diagrama de
classes, estados, seqüência, atividades, 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 alternativas 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 caso da aplicação comercial do
capítulo 2 é revisado, assim como o exemplo 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 diagramas. O leitor
pode, se desejar, iniciar a leitura do livro por este capítulo tendo uma abordagem
inicial mais prática, para dai se aprofundar 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 termos pode ter um significado
diferente fora do 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 oscó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:
Figura 2 - Encadeamento possível para leitura dos capítulos
Pode-se iniciar a leitura pelo Capítulo 2 para os que desejam consolidar 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 entendimento 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 especificação deseja um aprofundamento
dos conceitos do sistema em 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 detalhes de um
modelo orientado a objetos criado com a notação da UML, provavelmente por estarem
envolvidos nas etapas de design e construçã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 explicaçã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 formal, 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.
1.3. A importância da modelagem
É fácil observar que outras áreas do conhecimento, as outras disciplinas de
engenharia, usam extensivamente da modelagem para representar 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 capacidade de
gerenciamento da indústria da construção civil, permite uma razoável precisão na data
de entrega das obras graças à padronizaçã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 construçã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 especialização. Um carro é fruto de
um projeto básico que define os requisitos 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 computação estas lições,
e incentivar a elaboração de um projeto de software, 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 software. Um modelo
que representa, simplificadamente, o que se pretende 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 projetista, cliente,
construtor tenham todos uma mesma visão do projeto.
O processso de desenvolvimento de software é um processo composto não apenas
de componentes tecnológicos. Uma componente importante, e decisiva para o sucesso
de um empreendimento, é a componente 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 cliente. O cliente
que se serve do software cria, ao estabelecer os requisitos de um software, uma
expectativa que só verá realizada quando o software estiver concluído. Ao
desenvolvedor cabe captar e atender estas 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 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.
 
 
 
 
 
 
 
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 disciplinado. 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
trabalho 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,
representada em 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 modelagem 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 podem
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 software tem como principal objetivo resolver um
problema. A solução do problema irá trazer benefícios para os usuários do produto do
projeto, no caso, o software. A solução do problema, no caso da engenharia 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 conhecimento 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 requisitos 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 envolvem 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. É interessante 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.
Um elemento importante e presente em todos os projetos de engenharia são as
plantas de engenharia. Todo projeto de engenharia é realizado sobre uma planta, que é
uma representação gráfica minuciosa 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 importantes, 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 operaçã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 acompanhar a evolução do
projeto. No início, é comum os modelos serem apenas linhas gerais e esboços. Em
alguns casos, nem os limites do problema 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 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 iniciar 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 manutençã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 projeto 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 desenvolvedor, e o ciclo de teste do produto, representado pela
seta vertical à esquerda, do lado do cliente.
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
projeto, 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 incorporadas 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 desenvolvimento 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 desenvolvimento 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 problemas complexos os usuários podem variar de departamento, função,
hierarquia na organização. Nestes casos é importante se criar um comissão de
usuários, representativa da comunidade, para orientar o desenvolvimento do
sistema.
Patrocinadores fazem parte do grupo de clientes que dão apoio financeiro,
técnico ou político ao desenvolvimento do sistema. Este apoio é vital para que os
desenvolvedores possam ter acesso às informações e possam executar, se
necessário, as alteraçõesna organização para a implantação do sistema.
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 levantamento 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
implementação que podem ofuscar a definição do problema, falsos requisitos,
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, grandemente, da
experiência do analista. Quanto mais complexo o problema, 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 requisitos foram esquecidos, não é motivo de preocupação, como o
processo de desenvolvimento é cíclico sempre será possível rever a análise e incluir
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 conhecimento 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 deve cumprir para o negócio do cliente. O analista de negócios pode
desenvolver uma análise do retorno esperado com o invetimento no sistema, e
estudar a viabilidade técnica 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écnicas próprias e ferramentas de
software para criar os esquemas 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 especificaçã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 encarregado 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 especificaçã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çadas, os documentos e os modelos desta fase devem ser,
continuamente, avaliados e verificados pelos clientes.
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 escolher 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 apoiar 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 requisitos 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 també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 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 comunicação entre os usuários e o
computador. É um profissional 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 informação tem feito com que este profissional tenha um
papel cada vez mais importante para a aceitação e para a usabilidade do sistema.
Ele deve possuir a habilidade de e a criatividade para criar metáforas para a
operação do sistema.
Ao final da fase de design todas as definições do projeto devem estar registradas no
documento de especificação. Modelos, listas e esquemas servem como referências para
os construtores dos componentes 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
apresenta 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 construção recomenda a adoçãodo conceito
de componentes de software 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 diferentes
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 programador 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
facilmente 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 outros
especialistas: o programador de banco de dados, o programador de componentes e o
programador de interfaces.
Programador de interfaces é o profissional responsá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 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 componentes de negócio obedecendo
as regras de negócio definidas 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 desenvolvimento 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 recuperação de informação. Em sistema orientados a objeto o
uso do banco de dados é limitado e organizado pelos objetos, 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 construção são os próprios
componentes. Cada componente próprio ou adquirido de ter terceiros deve ser
testado individualmente, 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.
Fase de Integração
A fase de integração encerra o processo de desenvolvimento gerando, 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 equipamentos servidores. É uma fase de trabalho minucioso e
organizado, onde se deve assegurar que todos os componentes necessários foram
integrados. 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á coordenar uma equipe de profissionais, os Integradores que
responderão pela união correta dos componentes.
Os modelos, na fase de integração, servem de mapa para a configuraçã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 desenvolvimento, mas tem uma ênfase maior na
fase de integração, onde são realizadas a maior parte das atividades de configuração do
software.
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
ambiqü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 implementar a solução do problema, eles devem
ter igual riqueza de detalhes e precisão.
Em um problema complexo, dificilmente uma visão única, completa e bem definida
será obtida logo no início do processo. É importante que os compromissos do software
representados no modelo sejam assumidos aos poucos, acompanhando o entendimento
que se tem do problema. As técnicas de modelagem, que serão exploradas em detalhes
nos próximos capítulos, ajudam os analistas e designers a documentar 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 complexidade 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 sistema de software:
modelo de contexto,
modelo conceitual e
modelo detalhado.
A idéia central aqui também é introduzir a complexidade aos poucos. O modelo de
contexto equivale ao modelo de requisitos de Jacobson, enquanto o modelo
conceitual se equivale ao modelo de análise de Jacobson. O modelo detalhado pode ser
aplicado ao design, à implementaçã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 modelos
propostos por Jacobson.
O modelo de contexto inicia a definição do problema. É construí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 Jacobson (1992). Serve pararepresentar o sistema proposto no contexto
do negócio do cliente. Deve possuir uma representação simples, sem uma
formalidade excessiva, para poder ser entendido e validado pelo cliente, 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 é, essencialmente, 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 representadas 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 estabelecer um planejamento do desenvolvimento e um
dimensionamento mais preciso dos recursos necessários para a construção do 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
detalhado é 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 modelo detalhado possui uma escala ainda menor que o modelo
conceitual, os detalhes do sistemas são revelados com precisão, na medida da
necessidade 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 diversas versões. 
Figura 4 - Seqüência de Modelos em um Projeto de Software Típico
2.3. Documento de Especificação de Projeto
O principal documento do desenvolvimento do software é o Documento de 
Especificação de Projeto. Como seu próprio nome diz, ele deve descreve,
detalhadamente, o projeto de um software. Normalmente, a especificação é tomada
como um documento feito para orientar 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 conceitual. Na fase de design a especificação
recebe os detalhes das soluções escolhidas, para que na construção todas as alterações
no sistema possam ser representadas em modelos detalhados na especificação.
Mantém-se assim o documento vivo, acompanhando todo 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 importante, 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 processo 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 decomposta em funções mais simples,
continuamente, até que a quebra funcional leva a funções tão simples a ponto de
poderem ser implementadas 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 final, o sistema completo com
toda a funcionalidade pretendida.
O termo “função” é quem orienta todo o processo de desenvolvimento. O que o
sistema deve fazer conduz o processo de análise e construçã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ódigo envolvido pode ser muito grande, inviabilizando grandes
mudanças em sistemas desenvolvidos sob uma visão exclusivamente funcional.
Figura 5 - Esquema da Modelagem Funcional
Na modelagem de dados, outro paradigma possível no desenvolvimento de
software, o destaque se volta para a estrutura da informaçã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 relacionam.
O princípio por trás da modelagem de dados é que um sistema 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 algumasregras 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
abrigo no modelo de dados. Existe, entretanto, na modelagem de dados uma grande
reutilização das informações armazenadas e da sua estrutura. 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 semelhantes usam estruturas de informação semelhantes.
É importante se observar que nem sempre a estrutura da informação reflete a
estrutura do problema. Algumas vezes redundâncias e hierarquias presentes no
problema são eliminadas ao se analisar apenas 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, 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 importantes 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 algoritmos e estruturas de dados em objetos com a
linguagem Smalltalk. As idéias da programação orientada a objetos foram incorporadas
à linguagem C gerando C++ que ajudou a popularizar as linguagens orientadas a objeto.
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 dependência entre os dados e as funções dificulta uma alteração nos dados
ou nas funções, porque as conseqüências são imprevisíveis. É importante 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 operaçõ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.
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 elementos são relevantes para o software. Os
objetos que devem ser incluídos no modelo são os que realizam algo de destaque para o
problema em questão. Esta abordagem reduz a distância entre o modelo e o mundo real,
porque utiliza elementos da realidade para criar o modelo, 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 devem ser bem entendidas para
que o analista possa fazer um uso correto deste paradigma. Dentre estas características
destacam-se o conceito 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.
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 dados 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 objeto da realidade para o modelo
indica que ele representa algo que existe 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 exemplo, 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 chamadas 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 serviç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 situaçõ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 unidade de DVD são muito bem definidas: o aparelho de TV possui
como função apresentar imagens, enquanto o a unidade de DVD reproduz imagens
armazenadas no formato padrão do DVD. Eles se complementam 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 orientaçã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 aparelhode DVD
pede à TV que apresente as imagens, e para isso ele envia pela interface externa de
comunicação , a mensagem com a imagem a ser apresentada. A operação em separado
dos aparelhos é confiável e segura, o que leva a uma confiabilidade e segurança da
operaçã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 sistemas e uma maior facilidade de manutenção e expansão. Um objeto bem
projetado, testado e confiável pode ser utilizado em diversas situações, diluindo o seu
custo entre várias aplicações. A manutenção é simplificada e a expansão pode ser
realizada de forma mais controlada. 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 precisa da interface. A
interface é a a lista dos serviços que o objeto oferece, ela esconde como o objeto as
implementa. Muitas interfaces já 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.
Existem 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. (Orfali, 1998).
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 solicitar à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 acionamento de uma
operação encapsulada no objeto de destino, feita a partir do objeto de origem. A
informação transmitida é passada ao objetos 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 transmitir 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 conhecimento 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
existente entre os equipamentos eletrônicos e o controle remoto. O controle 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 encapsulamento isola as estruturas internas do objeto,
ele deve expor uma interface que permita que o objeto receba mensagens de outros,
formando o sistema. Vale observar que a comunicação entre os objetos é 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 interfaces e das mensagens a serem implementadas nos objetos é uma importante
atividade de modelagem do sistema, desempenhada durante a fase de design no projeto
de um software.
Figura 13 - Exemplo da comunicação entre objetos
 
2.4.3. Tipos, Classes e Objetos
Aplicando o encapsulamento em larga escala, observa-se que existem 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 operações, ele serve apenas para se definir
um padrão no modelo, reduzindo 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 componente 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 operaçõ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 operaçõ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 classificação dos objetos, isto é,
determinar a classe a que o objeto deva pertencer, é 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 equipamentos 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. Pertencer ao 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 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
2.4.4. Herança
A herança é uma das principais características da orientação a objetos, 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 estrutura de dados e funções. É possível se encontrar grupos que
possuam um conjunto de propriedades, e que a partir deste grupo seja possível criar
outros grupos que possuam propriedades ainda mais específicas, formando assim um
subconjuntodo 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 modelagem 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 funcionalidades 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 desenvolvimento 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 programaçã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.
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 polimorfismo como a propriedade
que o emissor de uma mensagem não precisa conhecer a instância da classe que recebe
esta mensagem. (Jacobson, et al, 1992). Esta propriedade leva ao fato de que uma
mesma mensagem pode ser interpretada de modos diferentes, quando for recebida por
objetos diferentes. Assim, como as implementações das funções que recebem a
mensagem são diferentes elas podem responder de forma diferente (poli = múltiplas,
morfo="forma"). Polimorfismo é 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 polimorfismo 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
desconhecimento 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
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 vantagens, 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 identificar mais diretamente com os problemas nos modelos.
O encapsulamento do conhecimento em componentes isola o comportamento, o que
permite que as mudanças nos requisitos possam também serem isoladas em cada
componente 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 outros modelos onde cada fase possui
técnicas e paradigmas próprios, na orientaçã a objetos o mesmo paradigma é
conduzido da análise à construção.
O encapsulamento favorece o teste dos sistemas de software, que pode ser isolado
para cada componente. O resultado é um aumento na qualidade do sistema.
O encapsulamento permite ainda que os componentes possam ser desenvolvido
por fornecedores diferentes,
A reutilização, decorrente do encapsulamento, reduz custos e prazos no
desenvolvimento de software porque possibilita 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
aplicados em vários problemas diferentes.
Algumas das vantagens da orientação a objetos podem ser compravadas na prática
com o estudo de caso que se segue.
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, didaticamente, 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
problema 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, conseguida pelo uso correto das características desta tecnologia como:
encapsulamento, 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 formulando o problema por meio de uma
visão do contexto onde este sistema se encontra. Segue-se construindo um modelo
conceitual do sistema, 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 entendimento dos princípios da
orientação a objetos, sem descer em detalhes excessivos dos códigos e das opções de
implementação, que podem 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 comprar. Ele se encaminha a um caixa que
deve finalizar a venda. Em geral, 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 descontos para pagamento a vista, ou parcelamento em 2 ou 3 vezes, com ou
sem juros. Este estudo se interessa pelas etapas de determinação do preço e das
condições de pagamento do produto. Deseja-se um sistema de informação que dado o
código do produto informe o preço e as condições de pagamento deste produto. As
condições de pagamento serão definidas em função do crédito que o cliente tem com a
loja em uma regra de negócio pré-estabelecida. Segue-se a arquitetura do sistema e as
regras de negócio:
Arquitetura do Sistema
O sistema é processado em uma rede de postos de venda, também conhecidos como
POS (do inglês: point of sale). Eles fazem a interface entre o caixa, funcionário da loja,
e um computador central que processa as requisições do processo de venda. A figura
abaixo descreve esta arquitetura:
 
Figura 19 - Esquema da Arquitetura do Sistema da Loja
O computador central armazena os dados dos produtos, dos clientes e do histórico
das vendas em um banco de dados. As regras do negócio também são processadas no
computador central. Os POS implementam uma camada de apresentação e comunicação
com o caixa, e fazem as requisições ao computador central. Existe um pequeno poder
de processamento local nos POS que pode ser utilizado, dependendo da aplicação