Tecnologia de Objetos

O uso da orientação a objetos na engenharia de software

Junho 2001

O desenvolvimento de software orientado a objetos não é apenas outra forma de realizar as atividades
existentes na análise, projeto e programação. Ela é na verdade uma evolução tecnológica, que surgiu como
resposta a uma demanda por softwares com qualidade, que possa ser desenvolvido rapidamente e com
forte aderência ao avanço tecnológico incorporado aos recursos e colocados à disposição dos
desenvolvedores e usuários pela tecnologia da informação. Portanto, aderir à orientação a objetos não é
mais uma opção, e sim, uma necessidade.

O desenvolvimento de software sempre foi uma tarefa de engenharia e, como tal, revestida da
complexidade e dificuldades inerentes aos processos dessa natureza. Não é uma tarefa fácil e, a orientação
a objeto pode, a princípio, torná-la mais complexa. Mas não fique desencorajado em persistir nessa
abordagem. Ela é fascinante, atual e cada vez mais solicitada, não somente pela indústria de software, mas
também por todos os demais segmentos da economia e da sociedade.

Este artigo levará você, que utiliza a análise e projeto estruturado, a iniciar uma discussão sobre o uso da
orientação a objeto e mostrará um caminho para você viabilizar a sua aplicação, melhor seqüenciar suas
tarefas e atribuir prioridade aos seus esforços. No final, você visualizará um processo básico, mas eficaz,
de desenvolvimento, indispensável para guiar a construção de software com qualidade.

Provavelmente você já ouviu falar sobre o paradigma da orientação a objetos e descobriu que ele é uma estratégia
para desenvolvimento de software baseada na idéia de que software pode ser construído usando componentes
reutilizáveis denominados objetos. O conceito fundamental deste paradigma é o de que um sistema pode ser
definido como uma coleção de objetos que interagem entre si, ao invés de defini-los em duas partes distintas: Dados
e Funcionalidades.

Objetos executam tarefas, isto é, são providos de funcionalidades e reconhecem suas propriedades e estados, ou
seja, incorporam uma estrutura de dados. O conceito parece simples, mas na prática, não é. Desenvolver software é
naturalmente difícil e a aplicação das técnicas orientadas a objeto tem se mostrado muitas vezes, mais trabalhosa
do que os métodos estruturados. Entretanto, tratá-la como um processo revestido de adequado formalismo é o que a
tornará mais simples e eficaz.

Para entender os diversos artefatos existentes na orientação a objetos você precisa antes conhecer alguns
fundamentos básicos dessa tecnologia. E é exatamente isto que faremos agora.

Primeiro vamos caracterizar o desenvolvimento de software como um processo que contém no mínimo as atividades
apresentadas na figura 1. Observe que dissemos no mínimo, pois o processo da figura 1 mostra cinco fases básicas
e essenciais. Ele não menciona outras atividades importantes tais como: Gerenciamento de Projetos,
Estabelecimento de Métricas, Definição de Arquitetura e Implantação.

Como um processo, o desenvolvimento de software é incremental e interativo. Ele apresenta em cada fase, tarefas
que podem ser exercidas em paralelo, estarem sujeitas a precedências ou ainda serem dependentes. Mas em
quaisquer dos casos, é certo que o produto de cada tarefa pode ser refinado a posteriori, através de uma interação
dinâmica que surge entre as tarefas de forma recorrente. O fundamental, entretanto é que cada tarefa deve
apresentar um resultado formalmente reconhecido que caracteriza o encerramento dos trabalhos daquela atividade.
Figura 1 – Fases básicas do desenvolvimento de software

Especificação de Requisitos

Análise
Teste
Projeto

Programação

Especificação de Requisitos

Na realidade não existe uma especificação de requisitos própria da orientação a objeto. Segundo minha experiência,
a especificação tem se mostrado independente da tecnologia utilizada. Assim, não se preocupe com a tecnologia
neste momento. Você deve preocupar-se apenas com o que seu software deve fazer. Compreender os requisitos de
forma abrangente e correta é essencial para qualquer projeto bem sucedido. A meu ver, o maior problema desta
fase é o fato de que as pessoas não estão interessadas em investir muito tempo na atividade de esclarecer os
requisitos de um sistema. Geralmente, aqueles usuários que são especialistas no domínio do problema, estão
envolvidos com suas rotinas diárias de trabalho, enquanto os analistas e desenvolvedores pressionados pelo tempo,
estão ansiosos para iniciar as atividades de codificação dos programas. Ainda é comum acreditar que a
desenvolvimento de um software está evoluindo porque alguns fragmentos de código já foram escritos. Não acredite
nessa lenda!

O que você precisa fazer no inicio da fase de especificação é comunicar a todos os envolvidos no desenvolvimento
do software que esta fase é crítica para o sucesso do projeto e que os esforços nela despendidos serão
compensados no prazo total do projeto e, evidentemente, na qualidade produzida.

Como disse, a fase de especificação independe da tecnologia. O que a orientação a objetos nos traz nessa fase, são
algumas técnicas apropriadas para registrar e expressar de forma clara os requisitos especificados. São elas: Caso
de Uso e o Cartão CRC que mutuamente se alimentam, de forma cíclica, contribuindo para o entendimento do
domínio do problema e descrevendo de forma clara, cenários da realidade estudada.

A figura 2 mostra o relacionamento existente entre as técnicas que você utiliza na fase de especificação de
requisitos. As elipses representam as técnicas e as setas os relacionamentos entre elas.
Figura 2 – Visão geral das técnicas utilizadas na especificação de requisitos

Domínio do Problema

Gerenciamento de
Versões Protótipo das GUIs Relacionamento
Dos GUIs

Regras de
Casos de Uso Negócios
Requisitos
Não Funcionais

Restrições
Modelo CRC

Vamos examinar a figura 2. Podemos tirar dela pelo menos três lições. A primeira, que o processo de especificação
de requisitos é altamente interativo. Segundo, que no processo de especificação de requisitos há muito mais coisas
a serem feitas, do que simplesmente construir os casos de uso, embora sejam eles parte central da especificação de
requisitos. Terceiro, que todo o estudo e solução a ser apresentada estão subordinados a um domínio do problema.

Ainda examinando a figura 2, observamos o que já dissemos anteriormente. A novidade aqui é o uso de duas
técnicas bastante difundidas na orientação a objetos. São elas: Casos de uso e os cartões CRC. As demais são
técnicas comuns utilizadas também nos processos estruturados de construção de software.

Análise orientada a objetos

O objetivo da análise, em qualquer abordagem, é entender a realidade para o qual o software será construído. A
análise é um estudo da realidade através da decomposição do todo em partes para melhor compreensão deste todo.
Similar aos outros processos de engenharia, a intenção aqui é a de identificar o que os usuários querem construir e
com que propósito. Até aqui nada de novo na análise orientada a objetos em relação à análise estruturada. As
diferenças surgem na abordagem técnica utilizada para realização das atividades de análise. Nos processos
estruturados a decomposição é funcional, o todo é decomposto em partes funcionais e as técnicas utilizadas são o
Diagrama de Contexto, DFD – Diagrama de Fluxo de Dados e DHF – Diagrama Hierárquico de Funções e,
separadamente, o DER – Diagrama de Entidades e Relacionamentos, que neste momento representa uma visão
lógica dos dados.

Na análise orientada a objetos a decomposição é feita através dos objetos que compõe o sistema e estes objetos
podem apresentar diferentes estados, podem implementar diferentes operações e até mesmo ter sua estrutura de
dados alterada conforme o contexto ao qual ele foi submetido. Por isso, ele deve ser analisado sob vários ângulos e
visões. As técnicas utilizadas para analisar um software orientado a objeto não estão sujeitas a fluxo nem à
hierarquia de funções, mas sim a eventos e trocas de mensagens. Os diagramas ER dão lugar a modelos de
persistência de objetos, mas ainda poderão ser usados se estivermos trabalhando com bancos híbridos
(objeto/relacional). Restou o diagrama de contexto que na análise orientada a objetos é substituído pelos casos de
uso. Uma forma expandida de mostrar o escopo do software e seus atores, que são elementos humanos,
dispositivos de hardware ou software que com ele interagem.

Um conjunto de diagramas, 9 ao todo, compreende o arsenal técnico definido pela UML – Unified Modeling
Language para a representação gráfica dos modelos de software orientado a objetos. Nem todos são sempre
necessários. A complexidade, porte e natureza do software determinam quais deles usar. Entretanto 4 deles são
básicos para a fase de análise: (1) Diagrama de Casos de Uso, que não devem ser confundidos com a descrição
dos casos de uso mencionados na fase de especificação, (2) Diagrama de Classes e (3) Diagramas de Interação
compreendidos pelos Diagramas de Seqüência e Diagramas de Colaboração e o (4) Diagramas de Atividade.
Destes, um é considerado diagrama estrutural (o diagrama de classes) os demais são considerados diagramas
comportamentais.

A figura 3 mostra os diagramas utilizados em suporte aos trabalhos de análise, o relacionamento entre eles e a
vinculação com a fase de especificação de requisitos.

Figura 3 – Visão geral dos diagramas utilizados na fase de análise orientada a objetos

Análise

Estrutural Comportamental Restrições

Casos de Uso Classes

Caso de Uso
Interação Protótipo
. Seqüência das GUIs
. Colaboração
Estado
Atividade
Modelo CRC
Relacionamento
Dos GUIs

Regras de
Negócios

Podemos também extrair da figura 3 algumas lições. A primeira é que a interação continua não somente dentre os
elementos da fase de análise, mas também com a fase anterior de especificação de requisitos. Isto significa que
você pode descobrir novos casos de uso ou, se preferir, novos cenários para a realidade estudada. Pode mostrar
também que seus protótipos deixaram de contemplar alguma necessidade nas interfaces existentes entre os
usuários e o software. Nestes casos, volte à fase anterior e complete sua especificação. Não deixe para atualizá-la
depois que a análise estiver pronta. Esta é mais uma das mentiras universais!

Outra lição, a segunda, que tiramos desta figura é que algumas atividades da fase anterior não se relacionam
diretamente com a fase atual. Isto significa que elas foram concluídas na fase anterior e devem ter apresentado um
resultado, um produto final da fase de especificação que não seja input desta fase.

Uma terceira lição que tiramos é que na orientação a objetos existe uma modelo estrutural e outro comportamental.
Um define as estruturas das classes e objetos, o outro define o comportamento esperado destes elementos.

E, finalmente, observamos que a exemplo do que ocorre na análise estruturada, à medida que construímos novos
diagramas de análise, poderemos ser remetidos à revisão e/ou refinamento de outros que já julgávamos prontos.

Projeto Orientado a Objetos

O propósito do projeto é definir como você irá construir seu software. Aqui você precisa de informações sobre como
fazer, enquanto a análise demonstra o que fazer. Os diagramas definidos pela UML para uso na fase de projeto são
os diagramas de implantação e componentes. Ambos são também estruturais e refletem estaticamente como
classes e interfaces poderão fazer parte de um componente e como estes elementos serão implantados, segundo a
arquitetura tecnológica existente.

Há ainda, o modelo de persistência, que não é um diagrama e nem é definido pela UML. O modelo de persistência é
na realidade um suporte metodológico que serve para orientar a tradução dos objetos em tabelas relacionais quando
estamos usando banco de dados dito híbridos ou objeto/relacional. O modelo de persistência é obtido através do
modelo das classes.

A figura 4 mostra os diagramas utilizados em suporte aos trabalhos de projeto, o relacionamento entre eles e a
vinculação com as fases anteriores de análise e especificação de requisitos.

Figura 4 – Visão geral dos diagramas utilizados na fase de projeto orientado a objetos

Projeto

Diagrama de Protótipo
Implantação das GUIs
Casos de Uso

Diagrama de Relacionamento
Componentes Dos GUIs

Diagrama de
Classes Diagrama de Classes
(Projeto)

Modelo de
Persistência

Ao iniciar a fase de projeto deveremos decidir alguns pontos importantes que irão orientar nosso trabalho. O primeiro
deles é se iremos adotar uma abordagem pura ou baseada em componentes. Uma abordagem orientada a objeto
pura o software é construído a partir de uma coleção de classes, enquanto numa abordagem baseada em
componentes, usaremos uma coleção de componentes. Componentes por sua vez são construídos usando outros
componentes ou classes, inclusive usando componentes não orientado a objetos.

Uma segunda decisão, não menos importante, diz respeito ao uso parcial ou total do modelo de gestão que você irá
seguir. Um modelo de gestão pode ser próprio quando a organização desenvolveu seu próprio modelo ou de
terceiros quando a organização incorpora modelos embutidos em sistemas ERPs ou em “management patterns”
desenvolvidos para grupos comuns de mesma categoria econômica tais como: Hospitais, Manufaturas, Seguros,
bancos, órgãos da administração pública, dentre outros.

Outra decisão importante diz respeito ao uso parcial ou total da infraestrutura tecnológica que você irá seguir. Ela
compreende o uso de componentes ou frameworks tais como EJB – Enterprise JavaBeans, Corba ou qualquer
‘Business Component Framework’. Você também poderá tomar a decisão de construir seus próprios componentes
ou elementos de infraestrutura para reutilização em projetos futuros.

Finalmente, você deve decidir quais das especificações não funcionais e restrições surgidas na fase de análise de
requisitos serão implementadas. Provavelmente alguns destes requisitos e restrições foram resolvidos em tempo de
análise, mas é no projeto que você deve considerar a alocação de recursos para atendê-los.
Programação Orientada a Objeto

O propósito da programação orientada a objeto é codificar e construir o software. Como você poderá notar na figura
5, os seguintes elementos darão subsidio a sua codificação:
a) diagramas de classe (refinados em tempo de projeto);
b) diagramas de estado;
c) diagramas de colaboração;
d) regras de negócios;
e) modelos de persistência e,
f) protótipos das GUIs.

A implicação mais importante desta fase é a de que projeto e codificação são fortemente relacionados e interativos.
Seus esforços de codificação poderão mostrar falhas ocorridas na fase de projeto que deverão ser solucionadas
neste momento.

Figura 5 – Artefatos desenvolvidos no projeto que orientam a fase de codificação

Modelo de
Persistência
Diagrama de Estado

Protótipo
Diagrama de Classes das GUIs
(versão do projeto)

Código Fonte
Diagrama de Relacionamento
Colaboração Dos GUIs

Regras de Negócios

Restrições

Ė importante observar que o foco está centrado em dois tipos de códigos fontes. Um escrito com linguagem
orientada a objeto (C++ ou Java) e outro escrito em SQL ou uma de suas derivações (Ex: PL/SQL) para atender os
requisitos de persistência tais como DML – Data Manipulation Language, DDL – Data Definition Language, Stored
Procedures e triggers. Os diagramas, protótipos, regras e restrições orientam o primeiro grupo. O modelo de
persistência orienta o segundo.

Teste Orientado a Objeto

Uma regra fundamental na engenharia de software é a de que os testes devem ser feitos o mais cedo possível.
Muito dos erros são cometidos no início do ciclo de vida do projeto e o custo de correção será tanto maior quanto
mais tarde eles forem descobertos.

Geralmente, os técnicos em desenvolvimento de software são muito bons em realizar atividades de projeto e
codificação, mas não apresentam as mesmas qualidades em atividades de especificação de requisitos e análise.
Como resultado os desenvolvedores tendem a cometer mais erros nestas duas fases. Para neutralizar este risco
uma metodologia de teste chamada FLOOT – Full Life Cicle Object Oriented Testing foi desenvolvida para validar e
verificar software construído com orientação a objeto.
Figura 6 - Coleção de técnicas FLOOT para teste de software

FLOOT – Full Life Cycle Object Oriented Testing

Testes de Testes de Análise Testes do Projeto

Especificação de
Requisitos

• Teste dos • Revisão dos • Revisão dos

Cenários de modelos modelos
Caso de Uso
• Walkthroughs • Walkthroughs
• Walkthroughs dos modelos dos modelos
dos protótipos
• Teste dos • Walkthroughs
• Revisão dos Cenários de dos protótipos
requisitos Caso de Uso

• Walkthroughs
dos protótipos

Testes de Testes do Sistema Testes do Usuário

Codificação
(Unitário)

• Classes • Funções • Alfa

• Integração • Instalação • Beta

• Herança • Operação • Piloto

• Agregação • Stress • Aceitação

• Interfaces • Suporte

• Paths