ENGENHARIA

DE SOFTWARE

Izabelly Soares de Morais

Modelo de análise de
software (orientada
a objetos)
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

„„ Identificar os objetivos da análise orientada a objetos.

„„ Aplicar os principais elementos de modelagem (diagramas da UML).
„„ Avaliar as vantagens e as desvantagens deste modelo.

Introdução
A análise orientada a objetos, diferentemente do enfoque tradicional,
sugere que um sistema é uma coletânea de objetos que interagem entre
si, com características próprias, representadas por atributos e operações.
Neste tipo de análise, os atributos representam os dados de um objeto
e servem para expressar características e informações. Já as operações
são as ações que podem ser realizadas pelo objeto. O mais interessante
é a possibilidade de modelar o sistema usando objetos que representam
elementos do mundo real. Isso permite que sistemas complexos sejam
facilmente modelados e implementados, além de facilitar o seu cresci-
mento e a manutenção.
Neste capítulo, você vai adquirir conhecimentos fundamentais para
avançar no aprendizado sobre análise orientada a objetos. Explore concei-
tos básicos sobre o modelo, suas ferramentas, vantagens e desvantagens.

Engenharia de software aplicada à análise de

software orientada a objetos
A era tecnológica almeja por softwares cada vez mais complexos. Essa com-
plexidade está ligada diretamente à grande quantidade de informações que
2 Modelo de análise de software (orientada a objetos)

devem ser processadas simultaneamente. Com o tempo, os recursos tecno-

lógicos passaram por diversas mudanças, tanto em seus dispositivos físicos
quanto lógicos. A Engenharia de Software surgiu devido à necessidade de
haver técnicas que norteassem o processo de desenvolvimento do software.
Diante dos diversos conceitos, métricas e ferramentas que regem a Engenha-
ria de Software, foram desenvolvidas maneiras de realizar a análise de software.
Primeiramente, o modelo mais utilizado foi o modelo de análise estruturada,
que ficou conhecido também como um modelo clássico. Por ser clássico, ele
traz conceitos de base para se realizar a análise de um software. Porém, como
citado anteriormente, vivemos em uma era em que os artefatos tecnológicos
devem ser cada vez mais robustos e compatíveis às novas tecnologias.
A OOA (análise orientada a objetos, em inglês object-oriented analysis,)
é uma técnica de análise semiformal para o paradigma de orientação a obje-
tos. A análise orientada a objetos é um componente-chave do paradigma de
orientação a objetos. Quando esse fluxo de trabalho é realizado, as classes são
extraídas. Os casos de uso e as classes são a base de um produto de software
orientado a objetos a ser desenvolvido (SCHACH, 2010, p.395). Dessa forma,
“concentra-se na definição de classes e na maneira como colaboram entre si
para atender aos requisitos dos clientes” (PRESSMAN; MAXIM, 2016, p.
172). Uma classe traz um conceito do mundo real, representa algum conceito,
um objeto, que tem comportamento e características e que executa ações.
Assim como as diversas vertentes da Engenharia de Software, a metodologia
de análise de software também requer técnicas específicas para que todos os
detalhes observados sejam documentados, seja por meio da escrita de uma
documentação específica, seja pelo uso de recursos gráficos. Veremos quais
elementos são utilizados pela análise orientada a objetos no próximo tópico.
Uma das metodologias existentes na Engenharia de Software é a meto-
dologia ágil e que pode ser aplicada na análise de software. No The Official
Agile Modeling Site, Scott Ambler (apud PRESSMAN; MAXIM, 2016, p. 81),
descreve modelagem ágil (AM) da seguinte maneira:

Modelagem ágil (AM) consiste em uma metodologia prática, voltada para a

modelagem e documentação de sistemas baseados em software. Simplificando,
modelagem ágil consiste em um conjunto de valores, princípios e práticas
voltados para a modelagem do software que podem ser aplicados a um projeto
de desenvolvimento de software de forma leve e eficiente. Os modelos ágeis
são mais eficientes do que os tradicionais pelo fato de serem simplesmente
bons, pois não têm a obrigação de ser perfeitos.
 Modelo de análise de software (orientada a objetos) 3

Elementos da modelagem orientada a objetos

O modelo de análise de software estruturado faz uso do diagrama de fluxo de
dados e do dicionário de dados, não se limitando a nenhum desses elementos,
até mesmo porque o uso de uma metodologia ou ferramenta irá depender do
contexto ao qual ela será inserida. Dessa forma, para a realização da análise de
software orientado a objetos, se faz comum o uso da linguagem de modelagem
unificada (do inglês UML – unified modeling language) como elemento de
representação gráfica e informacional de dados e informações de um software.

Linguagem de modelagem unificada (UML)

A UML nos permite visualizar e especificar detalhes de um software em
desenvolvimento por meio de uma linguagem específica. Ela permite que
elementos, relacionamentos e diagramas sejam modelados. Esses elementos
podem ser estruturais, comportamentais e, até, simples anotações sobre os
artefatos do software, que são compostos por classes, componente, interações,
pacotes, dentre outros. Os relacionamentos entre as classes, ou seja, entre
os objetos dentro de um contexto de orientação a objetos, ocorrem por meio
de dependências, associações, implementações e até generalizações. Cada
relacionamento é estabelecido conforme o problema a ser solucionado.
Para Larman (2007, p. 39), a palavra visual na definição é um ponto-chave.
A UML é a notação diagramática padrão, de fato, para desenhar ou apresentar
figuras (com algum texto) relacionadas a software – principalmente software
orientado a objetos (OO). Em Fowler (2003 apud Larman, 2007), três modos
pelos quais as pessoas aplicam UML são apresentados:

„„ UML como rascunho: diagramas incompletos e informais (frequente-

mente rascunhados à mão em quadros brancos) criados para explorar
partes difíceis do problema ou espaço de soluções, explorando o poder
das linguagens visuais.
„„ UML como planta de software: diagramas de projeto relativamente
detalhados, usados seja em Engenharia reversa, para visualizar e melhor
entender o código existente em diagramas UML; ou geração de código
(Engenharia avante).
■■ Em Engenharia reversa: uma ferramenta UML lê o código fonte ou
o código binário e gera (tipicamente) diagramas UML de pacotes, de
4 Modelo de análise de software (orientada a objetos)

classes e de sequência. Essas “plantas de software” podem ajudar o

leitor a entender os elementos, a estrutura e as colaborações globais.
■■ Antes da programação, alguns diagramas detalhados podem fornecer
diretrizes para a geração de código (por exemplo, em Java), quer
manualmente, quer automaticamente, com uma ferramenta. É comum
que os diagramas sejam usados para uma parte do código e outra
parte seja preenchida por um desenvolvedor que esteja codificando
(talvez também aplicando rascunhos UML).
„„ UML como linguagem de programação: especificação executável com-
pleta de um sistema de software em UML. Código executável será
automaticamente gerado, mas não é normalmente visto ou modificado
por desenvolvedores; trabalha-se apenas na “linguagem de programa-
ção” UML. Esse uso da UML requer um modo prático de diagramar
todo o comportamento ou a lógica (provavelmente usando diagramas
de interação ou estado) e está ainda em desenvolvimento em termos
de teoria, ferramentas robustas e usabilidade.

Ainda sob o ponto de vista do autor, “a UML descreve tipos de esboço

de diagramas, tais como diagramas de classe e diagramas de sequência. Ela
não superpõe a eles uma perspectiva de modelagem. Por exemplo, a mesma
notação UML de diagrama de classes pode ser usada para desenhar imagens
de conceitos do mundo real ou de classes de software em Java” (LARMAN,
2007, p. 40).

Diagrama de classe

O diagrama de classe

“fornece um conjunto inicial de elementos de notação que todos os outros

diagramas de estrutura usam. A representação UML de uma classe é um
retângulo contendo três compartimentos empilhados verticalmente [...]. O
compartimento superior mostra o nome da classe. O compartimento do meio
lista os atributos da classe. O compartimento inferior lista as operações
da classe. Ao projetar um elemento de classes em um diagrama de classes,
deve-se usar o compartimento superior, e os dois compartimentos inferiores
são opcionais (os dois inferiores seriam desnecessários em um diagrama que
ilustrasse um nível mais alto de detalhes, no qual o propósito fosse mostrar
somente o relacionamento entre os classificadores (BELL, 2016, p. 3).
 Modelo de análise de software (orientada a objetos) 5

A Figura 1 a seguir traz um exemplo da notação gráfica do diagrama de

classes.

Figura 1. Notação de um diagrama de classe.

O contexto que envolve a manipulação de objetos traz também a questão

da herança, a qual permite que uma classe herde outras funcionalidades e
até outros atributos. A representação gráfica desse conceito é realizada pela
ligação entre as classes por meio de uma ponta de seta, já que o “traço” re-
presenta apenas uma associação. Neste caso, essa ponta de seta não deve ser
preenchida e deve apontar, da classe que está disponibilizando, seus atributos
e operações. Chamamos essa classe de superclasse (Figura 2).

Figura 2. Representação de uma herança no diagrama de classe.

6 Modelo de análise de software (orientada a objetos)

De acordo com Pressman e Maxim (2016, p. 895),

qualquer alteração nos atributos ou nas operações contidas dentro de uma

superclasse é imediatamente herdada por todas as subclasses. Portanto, a
hierarquia de classes torna-se um mecanismo pelo qual alterações (em altos
níveis) podem ser imediatamente propagadas em um sistema. É importante
notar que, em cada nível de hierarquia de classe, novos atributos e operações
podem ser acrescentados àqueles que foram herdados de níveis mais altos
na hierarquia.

As operações que envolvem o diagrama de classes podem ser contempladas também

com outros tipos de eventos. Para isso, Bell (2016) descreve as seguintes associações
que podem ser utilizadas com o diagrama de classes:
„„ Associação bidirecional (padrão): Uma associação é uma ligação entre duas classes.
As associações são sempre consideradas bidirecionais. Isso significa que ambas as
classes estão cientes de cada uma e do relacionamento que têm, a menos que
você qualifique a associação como algum outro tipo.
„„ Associação unidirecional: em uma associação unidirecional, duas classes são re-
lacionadas, mas somente uma classe reconhece que o relacionamento existe.
„„ Uso de pacotes, interfaces e outros tipos de associações.

Casos de uso

O caso de uso é outro diagrama da UML, e Alistair Cockburn (2001, apud

PRESSMAN; MAXIM, 2016, p. 149) observa que “um caso de uso captura
um contrato [...] [que] descreve o comportamento do sistema sob várias con-
dições, à medida que o sistema responde a uma solicitação de um de seus
envolvidos”. Para Pressman e Maxim (2016, p. 149), basicamente, um caso
de uso conta uma jornada estilizada sobre como um usuário (desempenhando
um de uma série de papéis possíveis) interage com o sistema sob um conjunto
de circunstâncias específicas.
De acordo com Schach (2010, p. 290), outra forma de interpretar um caso
de uso é que ele mostra a interação entre o produto de software e o ambiente
no qual ele opera, isto é, o ator é o membro do mundo externo ao produto de
software, ao passo que o retângulo no caso de uso representa o produto de
software. Normalmente, é mais fácil identificar um ator.
 Modelo de análise de software (orientada a objetos) 7

„„ Frequentemente, ator é um usuário de produto de software. No caso

de um produto de software para a área bancária, os usuários desse
produto de software são os clientes e os funcionários do banco, como
caixas e gerentes.
„„ Em geral, o ator desempenha um papel em relação ao produto de sof-
tware, que poderia ser como usuário deste. Entretanto, o iniciador de
um caso de uso, ou alguém que desempenhe um papel crítico em um
caso de uso, também desempenha um papel, portanto, é considerado
um ator, independentemente de essa pessoa também ser um usuário do
produto de software (Figura 3).

Figura 3. Representação do diagrama de caso de uso.

Assim como no diagrama de classe, o caso de uso também traz associações,

que relacionam os autores, os casos de uso, e até outros autores que podem
estar envolvidos no mesmo contexto. Para Jacobson (1992 apud PRESSMAN;
MAXIM, 2016, p. 150), algumas perguntas que devem ser respondidas por
um caso de uso:

„„ Quais são as metas do ator?

„„ Que precondições devem existir antes de uma jornada começar?
„„ Que tarefas ou funções principais são realizadas pelo ator?
„„ Que exceções poderiam ser consideradas à medida que uma jornada
é descrita?
„„ Quais são as variações possíveis na interação do ator?
„„ Que informações de sistema o ator adquire, produz ou modifica?
„„ O ator terá de informar o sistema sobre mudanças no ambiente externo?
„„ Que informações o ator deseja do sistema?
„„ O ator gostaria de ser informado sobre mudanças inesperadas?
8 Modelo de análise de software (orientada a objetos)

Diversos mecanismos podem ser utilizados na concepção de um caso de

uso. Geralmente, as informações contidas nesse tipo de diagrama são oriun-
das de uma completa documentação de requisitos, os quais devem trazer os
requisitos funcionais do sistema. Dessa forma, todos devem trazer mais clareza
e consistência ao sistema, pois demonstram visualmente alguns de seus mais
importantes aspectos, que são suas funcionalidades.

A UML tem muitos tipos de diagramas e, dessa forma, apoia a criação de diferentes
modelos de sistema. No entanto, uma pesquisa em 2007 (ERICKSON; SIAU, 2007 apud
SOMMERVILLE, 2011, p. 83) mostrou que a maioria dos usuários de UML acredita que
cinco tipos de diagramas podem representar a essência de um sistema:
„„ diagramas de atividades, que mostram as atividades envolvidas em um processo
ou no processamento de dados;
„„ diagramas de casos de uso, que mostram as interações entre um sistema e seu
ambiente;
„„ Diagramas de sequência, que mostram as interações entre os atores e o sistema,
e entre os componentes do sistema;
„„ Diagramas de estado, que mostram como o sistema reage aos eventos internos
e externos.

Vantagens e desvantagens da análise orientada

a objetos
A demanda social trouxe diversas versões da UML. Dessa forma, suas co-
notações buscaram sempre acompanhar a necessidade dos desenvolvedores
de software. Com isso, uma das vantagens em utilizar a UML na análise de
software orientada a objetos é que sempre há alguma atualização nova, para
que sua usabilidade não fique obsoleta. Ela também traz facilidades que visam
à melhor compreensão das funcionalidades de um sistema, deixando todos os
detalhes mais claros, não só para os desenvolvedores, mas também para os
clientes, que na maioria das vezes são leigos no assunto.
 Modelo de análise de software (orientada a objetos) 9

A desvantagem se encontra no tempo, o qual deve ser dedicado ao desen-

volvimento dos diagramas e, consequentemente, de uma vasta documentação.
Dessa forma, só é indicado dar início ao processo de implementação após
todo o sistema ter sido especificado nos diagramas. Outro fator atrelado à
desvantagem do uso da UML na análise de software orientado a objetos é a
familiaridade da equipe desenvolvedora com as notações dos diagramas e com
as ferramentas utilizadas para desenvolvê-los, um fato que acaba atrelado ao
tempo – e sabemos que para obter lucro no desenvolvimento de um software
o custo-benefício deve estar ligado diretamente ao investimento de tempo,
ferramentas e uma equipe especializada.
De qualquer forma, a Engenharia de Software traz métodos que podem ser
adaptáveis a qualquer projeto. O importante é sabermos que temos diversas
opções. Porém, para realizarmos a melhor escolha, devemos conhecer todas
as técnicas disponíveis e sabermos como elas operam em um ciclo de desen-
volvimento de software.

A UML começou como um esforço de Booch e Rumbaugh, em 1994, não apenas

com o intuito de criar uma notação comum, mas de combinar seus dois métodos:
o de Booch e o OMT. Assim, o primeiro rascunho público do que hoje é a UML foi
apresentado como o Método Unificado (Unified Method). Ivar Jacobson, o criador do
Método Objectory, se juntou a eles na Rational Corporation e, já formando um grupo,
vieram a ser conhecidos como “os três amigos”. Foi nesse ponto que eles decidiram
reduzir o escopo do seu esforço e enfocar em uma notação comum de diagramação
a UML em vez de um método comum (LARMAN, 2007, p. 43).
10 Modelo de análise de software (orientada a objetos)

Veja a seguir um exemplo prático de um diagrama de caso de uso que traz o contexto
de uma empresa da área de segurança residencial. Na imagem deste diagrama de caso
de uso, podemos identificar os atores: proprietário e administrador do sistema, e os casos
de uso: arma/desarma o sistema, acessa o sistema via internet, dentre outros (Figura 4).

Figura 4. Exemplo de diagrama de casos de uso e seus atores.

Fonte: Pressman e Maxim (2016, p. 153)
 Modelo de análise de software (orientada a objetos) 11

BELL, D. Fundamentos básicos de UML: o diagrama de classes. Uma introdução aos

diagramas de estrutura em UML 2. IBM developerWorks, Nova York, 2016. Disponível em:
<https://www.ibm.com/developerworks/br/rational/library/content/RationalEdge/
sep04/bell/index.html>. Acesso em: 16 ago. 2017.
COCKBURN, A. Writing Effective Use-Cases. Reading: Addison-Wesley, 2001.
FOWLER, M. UML Distilled. 3. ed. Reading: Addison-Wesley.2003.
JACOBSON, I. Object-Oriented Software Engineering. Reading: Addison-Wesley, 1992.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orien-
tados a objetos e ao desenvolvimento iterativo.3. ed. Porto Alegre: Bookman, 2007.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional.
8. ed. Porto Alegre: AMGH, 2016.
SCHACH, S.R. Engenharia de software: os paradigmas clássicos e orientado a objetos.
7. ed. Porto Alegre: AMGH, 2010.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.

Leituras recomendadas
DEMARCO, T. Structured Analysis and System Specification. New York: Yourdon Press, 1978.
SLACK, N.; CHAMBERS, S.; JOHNSTON, R.; BETTS, A. Gerenciamento de operações e de
processos: princípios e práticas de impacto estratégico. 2. ed. Porto Alegre: Bookman, 2013.
YOURDON, E.; CONSTANTINE, L. L. Structured Design: fundamentals of a Discipline
of Computer Program and Systems Design. Englewood Cliffs: Prentice Hall, 1979.