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
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
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:
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
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 discute-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 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
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
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
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
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.
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 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:
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
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.
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.
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 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
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
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
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ções na 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
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
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
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.
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.
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ção do 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
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
para representar 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 deProjeto. 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
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
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 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 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
