1. Conhecendo as técnicas do
estudo de análise
Profª Taliane Lima

2. Os paradigmas de desenvolvimento
de sistemas
Primeiros sistemas – até 70
• Aplicações não tinham grandes dimensões
• Limitações das máquinas existentes
• Análise sem métodos e formalismos
• Praticamente a ferramenta era o fluxograma
• Derivação da fase de análise para fase de projeto sem
critérios

3. Os paradigmas de desenvolvimento
de sistemas
Mais tarde – década de 70
• Conceito de Engenharia de Software surge em
repulsa à crise de informática – 1968
• Dijkstra escreve sobre a programação estruturada
dando importância à complexidade dos sistemas.
• Codd descreve o modelo Relacional para banco de
dados – 1978
• Niklaus Wirth desenvolve o Pascal

4. Os paradigmas de desenvolvimento
de sistemas
• A linguagem C e desenvolvida por Ritchie
• A análise estruturada é popularizada por Tom
Demarco
• Passamos a conviver com Diagramas de Fluxo
de Dados (DFD), Diagramas de Entidades
e Relacionamento (DER) e outros naquilo que
ficou conhecido como Análise Essencial

5. Porém...
• Existia uma dificuldade em garantir a
compatibilidade entre as fases de análise e
projeto e desta para a de implementação.
Alteração ou extensões dos modelos criados
necessitam de grande esforço.
• A comunicação entre desenvolvedores e usuários
era difícil, os modelos fugiam à compreensão dos
usuários.

6. O início de novo paradigma
• Ainda na década de 70, métodos orientados a
objetos começaram a surgir amadurecendo nova
mudança de paradigma com o conceito de análise
orientada a objetos.
• E mais, melhorou a comunicação entre
desenvolvedores e usuários, com estes conseguindo
participar mais ativamente do desenvolvimento,
pela análise e validação dos diagramas
apresentados.

7. • Na tentativa de reverter à crise foram propostas
metodologias de desenvolvimento de sistema:
 Análise Estruturada ( processos e dados);
 Análise Essencial (processos, dados e
controle);
Análise Orientada a Objetos (paradigma de
objeto);

9. Análise Estruturada
• A analise estruturada consiste na construção de
um modelo lógico de sistemas, utilizando
técnicas gráficas capazes de levar usuários,
analistas e projetistas a formarem um quadro
claro e geral do sistema e de como suas partes se
encaixam para atender às necessidades daqueles
que dele precisam.

10. Análise Essencial
• A Análise Essencial de Sistemas pode ser
considerada uma evolução da análise
estruturada, propondo o reparticionamento do
sistema, utiliza-se das mesmas ferramentas de
modelagem da análise estruturada, mas com
mecanismos diferentes.

11. OS MÉTODOS...
Análise Estruturada Análise Essencial
 Diagrama de Fluxo de
Dados(DFD)
 Diagrama de Estrutura de
Dados) Modelo Conceitual
 Miniespecificações
 Normalização
 Dicionário de Dados
 Diagrama de Fluxo de
Dados(DFD)
 Lista de Eventos
 Diagrama de Entidade –
Relacionamento(DER)
 Diagrama de Transição de
Estado(DTE)
 Miniespecificações
 Normalização
 Dicionário de Dados

12. Linguagens tradicionais

13. Análise Orientada a Objetos
• A Análise Orientada a Objetos parte do
paradigma de que o mundo é formado de objetos e
de que desenvolver um sistema nada mais é que
criar uma simulação dos objetos e de seu
comportamento.

15. OO
• A orientação a objetos propicia aumento de
produtividade, menor custos de
desenvolvimento e de manutenção e, ainda,
maior portabilidade e reutilização de código.
• Classes – de onde se originam os objetos – bem
escritas reduzem tempo e custo de
desenvolvimento.

16. • MER OOA
Entidade ------------------> Classe
Ocorrência ----------------> Objeto
Atributo -------------------> Atributo

17. EXEMPLO:
Sistema de cadastramento de veículos

18. O COMEÇO...
1. A crise do software aconteceu em meados da década
de 1970.
2. Causadas pelo aumento da demanda e da
necessidade de uso de softwares.
3. Essa crise foi desencadeada a partir de um conjunto
de problemas como:
 muitas descrições textuais de difícil compreensão e
manutenção
 ocorrendo ambiguidades
 prazos e custos extrapolados
 dificuldades envolvendo a construção implantação e
manutenção dos softwares.

19. • Os estudos sobre a tecnologia de objetos
iniciaram-se na década de 1980 com ênfase nas
linguagens de programação. No final da mesma
década começaram a surgir os métodos de
análise e projeto. Os principais métodos foram
de:

20. • SHLAER & MELLOR (1989 e 1991);
• COAD & YOURDON (1991);
• COAD & NICOLA (1993);
• COAD et al. (1995);
• WIRFS-BROCK et al. (1990);
• BOOCH (1994 e 1995);
• RUMBAUGH et al. (1991 e 1996);
• MARTIN & ODELL (1994 e 1995);
• JACOBSON (1994 e 1995).

21. • Guerra dos métodos.
• Durante 1996 eles trabalharam no método que
passou a chamar de Unified Modeling
Language (UML)
• Object Management Group (OMG) iniciou
um esforço para padronização na área de
métodos.

22. UML – A Linguagem de Modelagem
Unificada
• “A UML proporciona uma forma padrão para a
preparação de planos de arquitetura de projetos
de sistemas, incluindo aspectos conceituais tais
como processos de negócios e funções do
sistema, além de itens concretos como as classes
escritas em determinada linguagem de
programação, esquemas de bancos de dados e
componentes de software reutilizáveis”

23. UML – A Linguagem de Modelagem
Unificada
• Os elementos gráficos têm sintaxe – forma
predeterminada – evitando ambiguidades. Com
isto evita que um analista modele uma classe
como um retângulo e outro como um cubo.
Elementos também possuem semântica –
significado e função.

24. Diagramas da UML

25. Diagramas de Casos de Uso (Use
Case)
• É um diagrama usado para se identificar como o
sistema se comporta em várias situações que
podem ocorrer durante sua operação.

27. • Ator: Representa qualquer entidade que interage
com o sistema durante sua execução essa
interação se dá através de comunicações (troca
de mensagens).
• Um ator pode ser uma pessoa (usuário,
secretaria, aluno...), um dispositivo (impressora,
máquina...), hardware (placa de modem,
scaner...), softwares (sistema de bd,
aplicativos...), etc.

28. Algumas de suas características são
descritas abaixo:
 Ator não é parte do sistema. Representa os
papéis que o usuário do sistema pode
desempenhar.
 Ator pode interagir ativamente com o
sistema.
 Ator pode ser um receptor passivo de
informação.
 Ator pode representar um ser humano,
uma máquina ou outro sistema.

29. Representação:

30. • Como foi exemplificado acima, é uma sequencia
de ações que o sistema executa e produz um
resultado de valor para o ator. Modela o dialogo
entre os atores e o sistema; é um fluxo de
eventos completos.

31. Algumas de suas características são
descritas abaixo:
Um "Use Case" modela o diálogo entre
atores e o sistema.
Um "Use Case" é iniciado por um ator
para invocar uma certa funcionalidade do
sistema.
Um "Use Case" é fluxo de eventos
completo e consistente.
O conjunto de todos os "Use Case"
representa todas as situações possíveis de
utilização do sistema.

32. • Os relacionamentos ligam as classes/objetos
entre si criando relações lógicas entre estas
entidades. Os relacionamentos podem ser dos
seguintes tipos:

33. • Os relacionamentos em um diagrama de casos
de uso podem envolver dois atores e dois casos
de uso ou um ator e um caso de uso e assim
sucessivamente. O relacionamento é
representado através de uma seta :

34. EXEMPLO DE CASO DE USO
Sistema automatizado de Matrícula num
Curso

35. • Um Caso de Uso é uma fatia de funcionalidade
do sistema, sem superposição nem lacunas, que
representam algo de valor para os usuários
finais.
• Um Ator é representação dos usuários e outros
sistemas que interagem com o produto

36. • Os Diagramas de Caso de Uso exibe
os relacionamentos entre atores e
casos de uso, deixando claro que
grupos utilizam quais funções.

38. Diagrama de Casos de Uso
• Esse diagrama documenta o que o sistema
faz do ponto de vista do usuário. Em outras
palavras, ele descreve as principais
funcionalidades do sistema e a interação dessas
funcionalidades com os usuários do mesmo
sistema.
• Nesse diagrama não nos aprofundamos em
detalhes técnicos que dizem como o sistema
faz.

39. EXERCITANDO...
Desenvolver um diagrama de caso de uso, de
acordo com as características abaixo:
1)Certa agência, possui um atendente onde este é
responsável pelo abastecimento de dinheiro ao caixa
eletrônico.
2)Nesta mesma agência um cliente verifica o saldo da
conta
3)O cliente solicita extrato
4)O cliente realiza saque
5)O cliente realiza deposito
6)O atendente recolhe o envelope de depósito do cliente

40. Análise
O fluxo da Análise tem como objetivos:
• modelar de forma precisa os conceitos relevantes
do domínio do problema, identificados a partir
do levantamento de requisitos;
• verificar a qualidade dos requisitos identificados;
• detalhar esses requisitos o suficiente para que
atinjam o nível de detalhe adequado aos
desenvolvedores.

41. • Quando se usa um Modelo de Análise orientado
a objetos, os requisitos funcionais são
tipicamente descritos e verificados através dos
seguintes recursos de notação:

42. • Os casos de uso descrevem o comportamento
esperado do produto.
• Os diagramas de casos de uso descrevem os
relacionamentos dos casos de uso entre si e com os
atores.
• As classes representam os conceitos do mundo da
aplicação que sejam relevantes para a descrição
mais precisa dos requisitos, exibindo os
relacionamentos entre essas.
• As realizações dos casos de uso mostram como
objetos das classes descritas colaboram entre si
para realizar os principais roteiros que podem ser
percorridos dentro de cada caso de uso.

43. UML – Diagrama de Classes
• Introdução – Diagrama de classes
• Elementos do diagrama de classes
• Exemplo: Sistema de matrícula

44. Introdução - Diagrama de Classes
• Mostra um conjunto de classes e seus
relacionamentos.
• É o diagrama central da modelagem orientada a
objetos.

46. Elementos – Diagrama de Classes
Elementos de um diagrama de classes :
Classes
Relacionamentos
 Associação
• Agregação
• Composição
 Generalização
 Dependência

47. Elementos – Diagrama de Classes
Elementos de um diagrama de classes :
Classes
Relacionamentos
Associação
• Agregação
• Composição
 Generalização
 Dependência

48. Elementos – Diagrama de Classes
Classes
• Graficamente, as classes são representadas por
retângulos incluindo nome, atributos e métodos.

49. • Devem receber nomes de acordo com o
vocabulário do domínio do problema.
• É comum adotar um padrão para nomeá-las
 Ex: todos os nomes de classes serão
substantivos singulares com a primeira letra
maiúscula

50. Elementos – Diagrama de Classes
Classes
 Atributos
Representam o conjunto de características
(estado) dos objetos daquela classe

51. Visibilidade:
 + público: visível em qualquer classe de
qualquer pacote
 # protegido: visível para classes do mesmo
pacote
 - privado: visível somente para classe
Exemplo: + nome : String

52. Elementos – Diagrama de Classes
Classes
Métodos
– Representam o conjunto de operações
(comportamento) que a classe fornece
 Visibilidade:
+ público: visível em qualquer classe de qualquer
pacote
# protegido: visível para classes do mesmo pacote
- privado: visível somente para classe

53. Elementos – Diagrama de Classes
Elementos de um diagrama de classes :
Classes
Relacionamentos
 Associação
• Agregação
• Composição
 Generalização
 Dependência

54. Elementos – Diagrama de Classes
Relacionamentos
• Os relacionamentos possuem:
– Nome: descrição dada ao relacionamento (faz,
tem, possui,...)
– Sentido de leitura
– Navegabilidade: indicada por uma seta no fim
do relacionamento

55. – Multiplicidade: 0..1, 0..*, 1, 1..*, 2, 3..7
– Tipo: associação (agregação, composição),
generalização e dependência
– Papéis: desempenhados por classes em um
relacionamento

56. Relacionamentos

57. Relacionamentos
• O cliente sabe quais são seus endereços, mas o
endereço não sabe a quais clientes pertence

58. Elementos – Diagrama de Classes
Elementos de um diagrama de classes :
Classes
Relacionamentos
 Associação
• Agregação
• Composição
 Generalização
 Dependência

59. Elementos – Diagrama de Classes
Relacionamentos:
- Associação
 Uma associação é um relacionamento estrutural
que indica que os objetos de uma classe estão
vinculados a objetos de outra classe.
Uma associação é representada por uma linha
sólida conectando duas classes.

60. Associação

61. Elementos – Diagrama de Classes
Relacionamentos: Associação
 Indicadores de multiplicidade:
– 1 Exatamente um
– 1..* Um ou mais
– 0..* Zero ou mais (muitos)
– * Zero ou mais (muitos)
– 0..1 Zero ou um
– m..n Faixa de valores (por exemplo: 4..7)

63. • Relacionamentos: Associação
Exemplo:
Um Estudante pode ser um aluno de
uma Disciplina e
um jogador da Equipe de Futebol
• Cada Disciplina deve ser cursada por no
mínimo 1 aluno
• Um aluno pode cursar de 0 até 8 disciplinas

65. Elementos – Diagrama de Classes
Elementos de um diagrama de classes :
Classes
Relacionamentos
 Associação
• Agregação
• Composição
 Generalização
 Dependência

66. • Relacionamento: Agregação
– É um tipo especial de associação
– Utilizada para indicar “todo-parte”

67. – um objeto “parte” pode fazer parte de vários
objetos “todo”

68. Elementos – Diagrama de Classes
Elementos de um diagrama de classes :
Classes
Relacionamentos
 Associação
• Agregação
• Composição
 Generalização
 Dependência

69. • Relacionamento: Composição
– É uma variante semanticamente mais “forte” da
agregação
– Os objetos “parte” só podem pertencer a um
único objeto “todo” e têm o seu tempo de vida
coincidente com o dele

70. Elementos – Diagrama de Classes
 Quando o “todo” morre todas as suas
“partes” também morrem

71. Elementos – Diagrama de Classes
Elementos de um diagrama de classes :
Classes
Relacionamentos
 Associação
• Agregação
• Composição
 Generalização
 Dependência

72. Elementos – Diagrama de Classes
• Relacionamento: Generalização
É um relacionamento entre itens gerais
(superclasses) e itens mais específicos
(subclasses)

73. Elementos – Diagrama de Classes
Elementos de um diagrama de classes :
Classes
Relacionamentos
 Associação
• Agregação
• Composição
 Generalização
 Dependência

74. Elementos – Diagrama de Classes
• Relacionamento: Dependência
 Representa que a alteração de um objeto (o
objeto indepedendente) pode afetar outro objeto
(o objeto dependente)

75. Elementos – Diagrama de Classes
 Obs:
o Aclasse clie nte de pe nde de alg um se rviço da
classe fo rne ce do r
o Am udança de e stado do fo rne ce do r afe ta o
o bje to clie nte