ANÁLISE E

PROJETO DE
SISTEMAS

Cleverson Lopes Ledur

Realizar análise da solução
Objetivos de aprendizagem
Ao final deste capítulo, você deve apresentar os seguintes aprendizados:

„„ Identificar o problema e realizar a identificação das classes envolvidas.

„„ Elaborar a análise do problema.
„„ Descrever a análise da solução.

Introdução
A análise de um problema e criação de uma solução são tarefas essenciais
dentro de um projeto de software. Neste contexto, existem dois tipos de
análise, uma clássica que atualmente é pouco utilizada, e outra abordagem
orientada a objetos. A análise orientada a objetos é amplamente utilizada
atualmente, por facilitar a criação, testes e manutenção do software. Mas
antes de qualquer análise, precisamos definir os problemas, identificar
as causas e efeitos.
Também é necessário verificar com o cliente se o problema é real e
se deve ser solucionado. Saber identificar os problemas e transformá-los
em uma solução de software não é uma tarefa trivial.
Neste texto, você vai percorrer conceitos e técnicas utilizadas para
identificar problemas, identificar as classes de um sistema e também criar
a documentação de uma solução de software. Vai entender a análise
orientada a objetos e também conhecer algumas diferenças entre os
métodos tradicionais e os orientados a objetos na etapa de análise.

O problema e suas classes

Nesta seção, serão abordados dois conceitos que andam juntos no momento
de análise de um problema:
 Realizar análise da solução 2

„„ Identificação de problemas: aqui, você vai ver quais os passos e ques-

tionamentos devem ser feitos para realizar esta identificação durante
um projeto.
„„ Identificação de classes: aqui, você vai aprender como realizar a análise
orientada de objetos para tentar extrair as classes, atributos e outras
informações importantes para o andamento do projeto.

Identificar o problema
A identificação de um problema é muito importante durante a análise de uma
solução. É feito a identificação do problema para que ao final do projeto, a
solução realmente resolva o problema do cliente, e não apenas parcialmente.
Pode ser definido o processo de identificação do problema de um projeto de
software com os seguintes itens:

1. Identificação dos Stakeholders.

2. Obter concordância em relação ao problema que é identificado.
3. Identificar restrições do projeto.
4. Elaborar documento de visão.

Dessa forma, é possível ter certeza que durante a criação de uma solução,
o projeto estará atacando realmente o problema que os clientes possuem.
Portanto, deve-se realizar as seguintes perguntas para entender melhor e
identificar o problema:

„„ Qual é o real problema?

„„ O que pode inviabilizar a solução?
„„ Quais as possíveis soluções?

Após esses questionamentos, é importante alinhar o que foi levantado com

o cliente. Em alguns casos, é necessário fazer o levantamento dos problemas
que, para o cliente, não são prioridade ou não influenciam o negócio, de forma
que a solução não é interessante. Por esse motivo, validar com o cliente é
essencial antes de avançar na solução.
3 Realizar análise da solução

Identificar as classes
Supondo que já se tem um problema para ser resolvido, pode-se identificar as
classes desse problema para criar a solução no decorrer do projeto. Para isso,
é utilizada a análise orientada a objetos. Ela consiste em realizar a definição
das classes (objetos) que representam o problema que deverá ser resolvido,
bem como o modo que as classes relacionam e interagem entre si (SCHACH,
2009). A análise orientada a objetos também representa o funcionamento
interno dos objetos (por meio dos atributos e operações) e os mecanismos de
comunicação que permitem o trabalho mútuo. Por isso, ao final dessa análise, é
interessante fazer uma descrição das características das classes que descrevem
um sistema ou um produto, podendo ser estática ou dinâmica.
Assim, a análise orientada a objetos pode ser explicada através de alguns
passos. Basicamente, deve-se seguir os seguintes itens para a sua realização:

1. Descrição de casos de uso: uma descrição baseada no cenário de como

atores (pessoas, máquinas e outros sistemas) interagem com o produto.
2. Criação de um modelo de análise orientada a objetos: é composto
de representações gráficas ou baseado em uma linguagem que defina
os atributos, relacionamento e comportamento das classes, bem como
a comunicação interclasse e um gráfico do comportamento da classe
ao longo do tempo.
3. Definição de todas as classes que são relevantes para o problema
a ser resolvido: as operações e os atributos associados às classes, as
relações entre elas e o comportamento exibido por elas.

A análise orientada a objetos divide a solução em diversos modelos e

partes que representam diferentes visões (PRESSMAN; MAXIM, 2016). Este
comportamento é obtido baseado nos seguintes princípios:

„„ O domínio da informação é modelado.

„„ A função é descrita.
„„ O comportamento é representado.
„„ Os modelos de dado, funcional e comportamental são divididos para
expor maiores detalhes.
„„ Os primeiros modelos representam a essência do problema, enquanto
os últimos modelos fornecem detalhes de implementação.
 Realizar análise da solução 4

Para a identificação das classes, deve-se seguir os seguintes passos:

1. Deduzir os requisitos do cliente para o sistema.

2. Identificar cenários de casos de uso.
3. Selecionar classes e objetos por meio de requisitos básicos, como diretriz.
4. Identificar atributos e operações para cada objeto do sistema.
5. Definir estruturas e hierarquias que organizem as classes.
6. Construir um modelo objeto-relacionamento.
7. Construir um modelo de comportamento de objeto.
8. Revisar o modelo de análise OO com base nos casos de uso ou cenários.

Uma abordagem bastante utilizada na identificação das classes de um

sistema é, a partir de uma descrição de módulo ou do sistema, fazer a extração
dos substantivos. Essa abordagem é conhecida como o método de extração
de substantivos (SCHACH, 2009). Analise a seguinte descrição de sistema:

“O RH da empresa realiza a gestão de funcionários e visitantes. Diariamente,

são realizadas análises de candidatos para possíveis vagas em aberto.
Também, é realizada a gerência do ponto, ou seja, o horário de entrada
e saída dos funcionários. Ainda, no dia 20 de cada mês, é realizado o
cálculo de salário dos funcionários.”

Nessa descrição, já se consegue extrair alguns substantivos que não são

externos ao escopo e nem abstratos (não representam algo físico), são eles:
funcionário, visitante, candidato, horário e salário. Esses substantivos, possi-
velmente, serão as classes de um sistema que faria a gestão deste RH. Por isso,
deve-se ter cuidado nesta técnica para não utilizar substantivos que poderiam
ser atributos, como classes.

Análise do problema
Assim que um problema é identificado, se deve realizar a análise e modela-
gem da solução. Dentro do ciclo de vida de software, é chamada essa etapa
de análise. O objetivo de qualquer atividade de análise no ciclo de vida do
software é criar um modelo dos requisitos funcionais do sistema que seja
independente das restrições de implementação, ou seja, cria-se uma descrição
do sistema sem entrar em detalhes técnicos de implementação (DENNIS;
WIXOM; TEGARDEN, 2015).
5 Realizar análise da solução

A principal diferença entre a análise orientada a objetos e outras formas de

análise é que, pela abordagem orientada a objetos, são organizados requisitos
em torno de objetos, que integram comportamentos (processos) e estados
(dados) modelados por objetos do mundo real, com os quais o sistema interage.
Em outras metodologias de análise tradicionais, os dois aspectos: processos
e dados são considerados separadamente. Por exemplo, os dados podem ser
modelados por diagramas ER e comportamentos por fluxogramas ou gráficos
de estrutura.
As tarefas primárias na análise orientada a objetos (OOA) são:

1. Encontrar os objetos.
2. Organizar os objetos.
3. Descrever como os objetos interagem.
4. Estabelecer o comportamento dos objetos.
5. Definir o interior dos objetos

Os modelos comuns, usados em OOA, são casos de uso e modelos de objetos.

Os casos de uso descrevem cenários para funções de domínio padrão que o
sistema deve realizar. Os modelos de objetos descrevem os nomes, as relações
de classe, as operações e as propriedades dos objetos principais. Mockups ou
protótipos de interface de usuário também podem ser criados nesta fase de
análise, mas são mais comuns no projeto do sistema.

Ferramentas e abordagens
A decomposição orientada a objetos é o conceito sobre o qual a análise orientada
a objetos e o projeto orientado a objetos se baseiam. Existem três ferramentas
principais usadas em técnicas de análise e projeto orientado a objetos:

„„ Diagramas / modelos de classes.

„„ Diagramas de objetos.
„„ Diagramas de estado de objetos.

Os diagramas de classes são usados para modelar as abstrações de chaves

no domínio do problema e as relações entre si. Já os diagramas de objetos são
usados para modelar as interações entre objetos, enquanto os diagramas de
estado do objeto modelam o comportamento dinâmico dentro de um único
 Realizar análise da solução 6

objeto. Um diagrama de estado de objeto mostra todos os estados possíveis

de um objeto e a transição permitida entre os estados.
As ferramentas são apenas os meios pelos quais os desenvolvedores co-
municam os requisitos ou o design do sistema. Como eles realmente aplicam
essas ferramentas para a análise, o projeto também é importante. Ao contrário
da abordagem tradicional de cascata, a abordagem geral para análise e design
orientado a objetos é altamente integrativo. Por isso, na abordagem orientada
a objetos, todo o sistema é criado para que a manutenção de software seja
realizada da forma mais fácil e simples. Os sistemas orientados a objetos são
projetados para serem alterados (DENNIS; WIXOM; TEGARDEN, 2015).
Na análise orientada a objetos, existem quatro etapas principais a serem
executadas:

1. Identificação de objetos e classes.

2. Identificação dos relacionamentos do objeto.
3. Identificação dos atributos.
4. Identificação de serviços.

O primeiro passo envolve a identificação de objetos e classes candidatas,

que podem ser pessoas, lugares, coisas, organizações, conceitos ou eventos.
Em seguida, relacionamentos de objetos são documentados em diagramas
de objetos. Os atributos e serviços de cada classe são, então, identificados e
documentados em modelos de classe.
Da mesma forma, existem quatro etapas principais a serem realizadas:

„„ Definir ciclos de vida do objeto.

„„ Estabelecer relacionamentos de classe.
„„ Determinar a lógica do serviço.
„„ Concluir as definições de classe.

Com isso, o primeiro item consiste em analisar o ciclo de vida de cada

objeto e formalizar o ciclo de vida em um diagrama de estado do objeto. Em
seguida, as relações de classe são definidas em um diagrama de classes. Cada
serviço, que é fornecido por uma classe, é definido, incluindo qualquer lógica
que seja necessária. Por fim, os diagramas de classe e objeto são concluídos
juntamente com todos os modelos de classe.
7 Realizar análise da solução

Análise orientada a objetos x métodos tradicionais

Foi mencionado na introdução deste capítulo os métodos tradicionais. Neste
momento, você irá ver as diferenças entre esses dois métodos. Muito antes
da introdução à abordagem orientada a objetos, a maioria dos profissionais
de sistemas de informação foram instruídos para saber que o ciclo de vida
clássico de desenvolvimento em cascata era a maneira correta de abordar a
engenharia de software e, que a decomposição de processos de alto nível era
uma maneira prática de lidar com grandes projetos de desenvolvimento de
software. Esses métodos tradicionais criaram as bases das práticas modernas
de software, no entanto, essa base foi desestabilizada pela análise e projeto
orientado a objetos (BLAHA; RUMBAUGH, 2005).
O desenvolvimento de sistemas estruturados começou na década de 1960,
com o conceito de ciclo de vida de desenvolvimento de sistemas. Na década
de 1970, as metodologias estruturadas com foco nos processos foram desen-
volvidas para permitir a análise técnica de projetos de software de maneira
mais efetiva. A chamada revolução estruturada foi baseada em estruturas
de programas de computador, com etapas (processos) e dados de programas
separados.
Com a década de 1980, o planejamento e modelagem de dados começou a
desempenhar um papel mais importante no desenvolvimento, que resultou em
metodologias orientadas a dados, como a engenharia da informação. “Embora
as metodologias orientadas para dados tenham feito melhor uso dos poderosos
modelos de banco de dados que estavam evoluindo, as metodologias de dados
ainda dependiam da decomposição do processo e simplesmente dos processos
mapeados para os dados” (BLAHA; RUMBAUGH, 2005).
As organizações continuaram a usar métodos tradicionais no desenvolvi-
mento de software, mas elas perceberam que esses métodos tinham algumas
deficiências. Podem ser citadas como deficiências:

„„ A abordagem tradicional de cachoeira para o desenvolvimento de

software determina a conclusão da fase de análise antes do projeto e,
da mesma forma, a conclusão de todas as etapas de projeto antes da
construção. Esse pressuposto tem um risco inerente de realizar análises
incorretas ou incompletas no projeto e na construção.
„„ A decomposição do processo pode levar a projetos instáveis, porque
ele é baseado em processos que, muitas vezes, mudam com o resultado
de novos requisitos, correções de erros, novos ambientes ou melhorias.
 Realizar análise da solução 8

Os processos devem ser desmontados e modificados com frequência,

com obtenção de resultados incertos.
„„ As metodologias tradicionais de desenvolvimento de software sugerem
o desenvolvimento dele a partir do zero, em vez de reutilizar o código
existente, o que não é surpreendente, porque a decomposição do processo
resulta na separação dos processos e dos dados, tornando o transporte
e a reutilização do código extremamente difíceis.
„„ Como a decomposição do processo é orientada para resolver um pro-
blema específico, a resposta resultante (projeto) é única, dificultando
a reutilização de uma aplicação genérica.

Logo, estes problemas e inúmeros outros, levaram os desenvolvedores a

examinar diferentes formas de pensar sobre as abordagens para o desenvol-
vimento de sistemas.
O desenvolvimento de abordagens de design estruturado de cima para baixo
é uma questão simples de decomposição algorítmica, em que cada módulo
de um sistema denota um passo importante em algum processo geral. Em
contraste, a decomposição orientada a objetos é baseada em objetos e não em
algoritmos. Assim, a análise orientada a objetos se esforça para descrever o
que o sistema deve fazer em termos de objetos-chave no domínio do problema,
enquanto o projeto orientado a objetos se empenha para descrever como o
sistema funcionará usando esses objetos (BLAHA; RUMBAUGH, 2005).
Portanto, a análise orientada a objetos difere da análise estruturada em
muitos aspectos. A análise estruturada mantém uma visão orientada a processos
dos sistemas, fornecendo uma decomposição baseada em processos, enquanto
a análise orientada a objetos decompõe a base de domínio do problema em
entidades de classificação (classes e objetos).
Os desenvolvedores que, atualmente, usam técnicas de análise estruturada,
geralmente, descobrem que a sua experiência nos requisitos de modelagem com
o uso de diagramas de fluxo de dados é irrelevante ou vale a pena apenas no
contexto da modelagem de procedimentos existentes. Esses desenvolvedores,
que foram instruídos desta forma, podem encontrar nas análises orientadas a
objetos uma maneira muito mais fácil de modelar um sistema.
9 Realizar análise da solução

Documentar a solução
A solução pode ser documentada utilizando-se diversos modelos e técnicas
existentes. Você irá analisar que uma abordagem genérica pode ser utilizada em
diversos projetos. Nesta abordagem, o documento deve ter a seguinte estrutura:

1. Introdução ao documento: tema, objetivos, delimitações, justificativas,

métodos de trabalho, organização e glossário.
2. Descrição geral do sistema: descrição do problema, principais envol-
vidos e regras de negócio.
3. Requisitos do sistema: requisitos funcionais, requisitos não funcionais,
protótipo, métricas e cronograma.
4. Análise e design: arquitetura do sistema, modelo de domínio, diagramas
de interação, diagramas de classes, diagrama de atividades, diagrama
de estados, diagrama de componentes e modelo de dados.
5. Implementação: descrição da implementação do sistema.
6. Testes: plano de testes e execução do plano de testes.
7. Implantação: diagrama de implantação e manual de implantação.
8. Manual de usuário
9. Conclusão e considerações finais
10. Bibliografia

Para saber mais sobre um documento de solução, leia o artigo “Documentação de

um produto de software”, disponível no link a seguir:

https://qrgo.page.link/Cjbvz

Nesse momento, será dado enfoque para os itens da análise e design do

documento. Pode-se ver que dentro deste tópico se tem um grande conjunto
de diagramas. Os diagramas descritos neste item pertencem a UML. A UML
consiste em um certo número de elementos gráficos que se combinam para
formar diagramas. Como a UML é uma linguagem, ela possui regras para
combinar os elementos nos diversos diagramas (LARMAN, 2000).
 Realizar análise da solução 10

A UML fornece uma lista de diagramas bastante completa, que permite a

documentação de diversos aspectos do sistema. Veja na Figura 1, a estrutura dos
diagramas da UML. Nela se vê uma divisão de diagramas voltados para apre-
sentar elementos estruturais da solução e outra de diagramas comportamentais.

Diagrama

Diagrama Diagrama de
de Estruturas Comportamentos

Diagrama Diagrama de Diagrama Diagrama de Diagrama de

de Classes Componentes de Objetos Atividades Casos de Uso

Diagrama Diagrama Diagrama de Diagrama Diagrama Diagrama

de Perfil de Estruturas Implantação de Pacotes de Interação de Máquina
Compostas de Estados

Diagrama de Diagrama de Diagrama de Diagrama

Sequência Comunicação Visão Geral de Tempo
de Interação

Figura 1. Diagramas da UML.

Fonte: Object Management Group (2001).

BLAHA, M.; RUMBAUGH, J. Object-oriented modeling and design with UML. Upper Saddle
River: Pearson Education, 2005.
DENNIS, A.; WIXOM, B. H.; TEGARDEN, D. Systems analysis and design: an object-oriented
approach with UML. New Jersey: John Wiley & Sons, 2015.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados
a objetos. Porto Alegre: Bookman, 2000.
OBJECT MANAGEMENT GROUP. UML Superstructure Specification 2.4.1. Needham, 2011.
Disponível em: <http://www.omg.org/spec/UML/2.4.1>. Acesso em: 29 ago. 2017.
11 Realizar análise da solução

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ássico e orientado a Objetos.
7. ed. Porto Alegre: McGraw-Hill, 2009
WAZLAWICK, R. Análise e Design Orientados a Objetos para Sistemas de Informação:
modelagem com UML, OCL e IFML. Rio de Janeiro: Elsevier Brasil, 2016.

Leituras recomendadas
BEZERRA, E. Princípios de Análise e Projeto de Sistema com UML. Rio de Janeiro: Elsevier
Brasil, 2015. v. 3.
ENGHOLM, H. Análise e design orientados a objetos. São Paulo: Novatec, 2017.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de Software: aprenda as metodologias e
técnicas mais modernas para o desenvolvimento de software. 2. ed. São Paulo:
Novatec. 2007.
SALES, M. Diagrama de Pareto. GestioPolis, Bogotá, 2002. Disponível em: <https://
www.gestiopolis.com/diagrama-de-pareto/>. Acesso em: 29 ago. 2017.
 Encerra aqui o trecho do livro disponibilizado para
esta Unidade de Aprendizagem. Na Biblioteca Virtual
da Instituição, você encontra a obra na íntegra.