REALIZAR A ANÁLISE DA SOLUÇÃO

Prévia do material em texto

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: 
 � 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.
2Realizar 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ção3
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). 
4Realizar 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ção5
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.
6Realizar 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ção7
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. 
8Realizar 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éricapode 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ção9
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.
Figura 1. Diagramas da UML.
Fonte: Object Management Group (2001). 
Diagrama
Diagrama
de Estruturas
Diagrama
de Classes
Diagrama
de Per�l
Diagrama
de Estruturas 
Compostas
Diagrama
de Máquina
 de Estados
Diagrama de
 Visão Geral
de Interação
Diagrama de 
Componentes
Diagrama de 
Implantação
Diagrama de 
Sequência
Diagrama de 
Comunicação
Diagrama 
de Interação
Diagrama 
de Pacotes
Diagrama 
de Tempo
Diagrama de 
Atividades
Diagrama de 
Casos de Uso
Diagrama 
de Objetos
Diagrama de
Comportamentos
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.
10Realizar 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.
Realizar análise da solução11
Encerra aqui o trecho do livro disponibilizado para 
esta Unidade de Aprendizagem. Na Biblioteca Virtual 
da Instituição, você encontra a obra na íntegra.