sli4

1. Unidade IV
MODELAGEM DE
SISTEMAS DE INFORMAÇÃOSISTEMAS DE INFORMAÇÃO
Prof. Daniel Arthur Gennari Junior

2. Sobre esta aula
 Análise Orientada a Objetos
 Análise, Definição e Especificação de
Requisitos
 Modelagem de Casos de Uso

3. Análise Orientada a Objetos
Inicialmente observamos, como a análise
orientada a objeto utiliza conceitos que
aprendemos há muito tempo: objetos,
atributos, classes, membros, todos e
partes.
Só não podemos explicar porque demorou
tanto tempo para se aplicarem esses
conceitos na análise e especificações dos
sistemas de informação.

4. Análise Orientada a Objetos
Leva em consideração que:
 Produto da equipe é um software.
 A satisfação dos Propósitos passa por
uma interação com os usuários de forma
organizada e com isso expõe osorganizada e com isso expõe os
requisitos reais do sistema.
 Esse software só terá uma qualidade de
longa duração se a sua arquitetura
aceitar modificações.

5. Modelagem
É tida como a parte central de todas as
atividades para a construção de um bom
Sistema. Com ela podemos:
 Construir modelos que comunicam a
estrutura e o comportamento do sistema;
 Construir modelos que visualizam e
controlam a arquitetura do Sistema;
 Construir modelos que gerenciam os
riscos;
 Construir modelos que propiciam a Construir modelos que propiciam a
simplificação e reaproveitamento de
sistemas.

6. Modelagem Orientada a Objetos
Segundo James Rumbaugh:
“A modelagem baseada em objeto é tida
como um novo modo de estudar problemas
com a utilização de modelos que são
fundamentados em conceitos do mundo
real.
A estrutura básica é o objeto, que combina
a estrutura e o comportamento dos dados
em uma única entidade.
São úteis para a compreensão dep p
problemas, para a comunicação com os
peritos em aplicações, para modelar
empresas, preparar
documentações e projetar
programas e bases de dados”.

7. Principais vantagens da análise OO
 Melhor entendimento do problema a ser
resolvido;
 Maior flexibilidade entre os blocos
independentes que são produzidos;
 Boa divisão do trabalho entre diferentesBoa divisão do trabalho entre diferentes
equipes de desenvolvimento;
 Melhor participação dos usuários no
processo de desenvolvimento do
sistema;
 Ajuda a trabalhar com aplicativos Ajuda a trabalhar com aplicativos
complexos.

8. Principais problemas encontrados
na análise OO
 Exige uma melhor concentração na
análise e no projeto do sistema;
 Mudança na cultura de desenvolvimento;
 Os benefícios são evidenciados a longo
prazo.prazo.

9. Interatividade
A Modelagem de Sistemas é uma atividade
que pressupõe a utilização de:
a) Metodologias e procedimentos;
b) Softwares e Frameworks;
c) Bases de comparação;c) Bases de comparação;
d) Bases de interação com o Sistema;
e) N.D.A.

10. Conceitos de Orientação a Objeto
O it bá i d i t ãOs conceitos básicos de orientação a
objeto permitem a definição de:
 Classes;
 Objetos;
H Herança;
 Associações;
 Agregação;
 Composição;
 Encapsulamento;
 Métodos;
 Polimorfismo;
 Interface.

11. Classe
Segundo Yourdon:
“Classe é uma descrição de um ou mais
objetos com conjunto uniforme de atributos
e serviços, incluindo uma descrição de
como criar novos objetos na classe”.

12. Classe
A classe é a construção mais importante na
orientação a objeto, em que cada classe
pode conter: nome, atributo e Método.
Nome: o nome de uma classe é obrigatório
e é utilizado para identificá-la diante das
outras. Os nomes das classes são
substantivos ou expressões breves,
definidos a partir do vocabulário do
sistema.

13. Atributo de uma Classe
Atributo: é propriedade nomeado de uma
classe que descreve um intervalo de
valores cujas instâncias podem apresentar,
sendo ele uma abstração do tipo de dado
ou do estado que os objetos podem
abrangerabranger.

14. Método de uma Classe
O método é a implementação de um serviço
a ser solicitado compartilhado por todos os
objetos dentro da classe.
O método pode expressar o comportamento
que um objeto apresentar.

15. Objetos
Um objeto pode ser um lugar, evento, coisa,
relatório ou conceito que possa ser
aplicado ao sistema, sendo uma abstração,
algo que possui um limite nítido e
simplificado em relação ao problema.
O objeto facilita a compreensão do mundo
real, e oferece a base para a implementação
do mundo real no computador.

16. Herança
A herança mostra a igualdade entre as
classes, podendo ser feita a simplificação
da definição de classes iguais a outras que
já foram definidas. Com isso, é possível
representar a generalização e
especialização tornando visíveis osespecialização, tornando visíveis os
atributos e serviços que são comuns em
uma hierarquia de classes. A herança pode
ser entendida como um relacionamento
entre uma superclasse (classe mãe), e um
tipo mais específico chamado de subclassetipo mais específico chamado de subclasse
(classe filha). A classe filha herda as
características da mãe e pode adicionar
novas estruturas ou
comportamentos.

17. Exemplos de herança
Simples: uma classe herda as
características apenas de uma classe mãe;
Composta: uma classe herda as
características de mais de uma classe mãe.

18. Associações
As associações são relacionamentos fracos
entre os objetos.
Na UML, uma associação pode ser
representada como uma linha que liga uma
classe a outra.

19. Agregação
A agregação representa um exemplo de
relacionamento do tipo “tem um”,
significando que o objeto do todo contém
os objetos das partes. Algumas vezes, um
objeto é constituído por outros objetos.

20. Composição
É um caso particular de agregação,
utilizado principalmente para evidenciar
uma forte conotação de propriedade.
Também especifica que o objeto tem um
ciclo de vida, e, quando ele é destruído, as
partes também são.

21. Encapsulamento
Por meio do encapsulamento, podemos
ocultar detalhes referentes à
implementação do objeto, protegendo os
dados contra a adulteração, pois eles só
podem ser acessados pelo próprio objeto,
pelos seus métodospelos seus métodos.

22. Métodos
Os métodos são as operações de uma
classe. Eles são formados por interfaces
que descrevem as características externas
do método e pela implementação, que
contém o código efetivo para a operação.

23. Polimorfismo
O polimorfismo permite tratar instâncias de
várias classes da mesma forma dentro do
sistema.
Ex: O objeto “Francisco” pode ser um
estudante, um registro ou mesmo um
Écoordenador. É interessante para os outros
objetos saberem que tipo de pessoa
Francisco é. O esforço no desenvolvimento
seria reduzido se outros tipos de objetos
tratassem o objeto pessoa da mesma
forma não existindo códigos separadosforma, não existindo códigos separados
para cada tipo.

24. Interface
A interface é um contrato de
implementação de métodos de uma classe,
que implementa uma interface, e deve
implementar todos os métodos que são
especificados pela interface.p p

25. Conclusão
A análise orientada a objeto tem como
principal objetivo fazer com que o mundo
computacional torne-se o mais próximo
possível do mundo real.
Com o auxílio de todos os conceitos que
citamos, é possível representar
computacionalmente os objetos do mundo
real e classificá-los em classes
reconhecíveis.

26. Interatividade
Um dos principais problemas na utilização
da Metodologia Orientada a Objetos é:
a) Uso errado dos Métodos;
b) Exige uma melhor concentração na
análise e no projeto do sistema;análise e no projeto do sistema;
c) Indisposição da Alta direção;
d) É uma metodologia Nova;
e) N.D.A.

27. Análise, Definição e Especificação
dos Requisitos
A análise de requisitos busca compreender
os requisitos solicitados pelo cliente para a
construção dos sistemas de informação. É
nela que são descritas as abordagens
utilizadas para descobrir os requisitos,
envolvendo uma equipe técnica que emenvolvendo uma equipe técnica que, em
conjunto com os usuários do sistema,
estabelece um domínio da aplicação do
sistema.
Neste processo de análise, usuários como
gerentes engenheiros de manutenção egerentes, engenheiros de manutenção e
especialistas de domínio também estão
envolvidos, sendo conhecidos como
STAKEHOLDERS.

28. Problemas na análise
 O usuário do sistema não possui uma
idéia concreta do que deseja, e, mesmo
sabendo, existe uma grande dificuldade
em se expressar.
 O usuário tenta expressar-se utilizando
seus próprios termos, supondo que o
desenvolvedor sabe o que ele está
falando.
 Como os requisitos são definidos por
diferentes usuários, surgem diversos
conflitos, difíceis de serem descobertos,
pois os usuários expressam-se de
formas diferentes.

29. Processo de Análise dos Requisitos
Deve ser estabelecida uma compreensão
sistemática. O modelo é composto pelas
Seguintes atividades:
Compreensão do domínio: é estabelecido
um entendimento do domínio da aplicação,
em que se deve descobrir o maior número
de informações possível.
Coleção de requisitos: é feito um processo
de interação com os usuários envolvidos,
com a intenção de identificar os requisitos.

30. Atividades do Modelo
 Classificação: classificar a lista de
requisitos em categorias coerentes.
 Resolução de Conflitos: identificação e
resolução de requisitos, decidindo o que
fazer quando os requisitos solicitados
por um usuário entram em conflito com
outros já existentes.
 Priorização: definir quais requisitos
possuem uma escala maior de
prioridade.
 Validação: verificar se o conjunto de
requisitos é compatível com os
solicitados pelos usuários.

31. Atividades do Modelo
Durante a atividade de análise, três
atividades podem ser desenvolvidas:
 Particionamento: identifica o
relacionamento estrutural entre as
atividades.
 Abstração: identifica a generalidade
entre as atividades.
 Projeção: identifica as diferentes formas
possíveis de enxergar o mesmo
problema.problema.

32. Requisitos Funcionais
Representam algo que o sistema deve fazer
por meio de uma função do sistema que
agregue valor ao usuário que o está
utilizando.
Ex:Emissão de relatório ou a realização de
um cadastro.
Os eventos essenciais têm como função
principal a definição de todos os requisitos
Funcionais existentes no sistema,
respondendo a todos os eventos.

33. Requisitos não-funcionais
Abordam a forma como os requisitos
funcionais podem ser alcançados,
definindo restrições e propriedades de um
sistema.
Alguns requisitos não-funcionais também
são conhecidos como requisitos de
qualidade, responsáveis por exigir
resistência e robustez do sistema.
EX: a velocidade e a sua
transportabilidade.

34. Outros tipos de Requisitos
Restrições do projeto: limites impostos
para que o sistema seja capaz de funcionar
no seu ambiente de operação:
 Hardware • Software • Rede
 Características técnicasCaracterísticas técnicas
Impulsionadores do projeto: forças que
fazem o projeto acontecer. Os
impulsionadores são geradores de
requisitos funcionais e não-funcionais.
Assuntos do projeto: completam o quadroAssuntos do projeto: completam o quadro
dos fatores que dizem respeito ao sucesso
ou fracasso do sistema.

35. Verdadeiras ou Falsos
Q d i t d i lQuando um sistema deve cumprir qualquer
tecnologia de implementação escolhida, é
considerado um requisito verdadeiro, mas
quando o sistema cumpre suas finalidades
sem que um requisito seja implementado,
este é considerado um requisito falsoeste é considerado um requisito falso.
Requisitos tecnológicos falsos:
 Tecnologias futuras ou passadas;
 Linguagens a serem utilizadas;
Requisitos arbitrários falsos:Requisitos arbitrários falsos:
 Influência de ferramentas de modelagem;
 Preciosismo;
 Ferramentas hipotéticas no
sistema.

36. Requisitos Falsos
A introdução dos requisitos falsos no
sistema aumenta os riscos de o projeto não
ser completado, pois um requisito falso
pode acabar mascarando um requisito
verdadeiro.
Para garantir o sucesso de um projeto,
devemos buscar apenas os requisitos
verdadeiros, mas não é uma tarefa fácil,
pois um sistema implementado só com
requisitos verdadeiros é considerado um
sistema tecnologicamente perfeitosistema tecnologicamente perfeito.

37. Descrições de Requisitos
 Identificador
 Tipo
 Evento ao qual atende
 Descrição
 Justificativa
 Fonte do requisito
 Critérios de aceitação
 Satisfação do usuário
I ti f ã d á i Insatisfação do usuário
 Dependências
 Conflitos

38. Levantamentos de requisitos
O levantamento dos requisitos aborda as
expectativas do sistema, seguindo-se a
validação e a consolidação de todas as
expectativas em requisitos formais. Essas
diferentes visões implicam projetar esses
interesses e conciliá losinteresses e conciliá-los.
Busca de fatos
Coletas e Classificação de Requisitos
Racionalização e Avaliação
PriorizaçãoPriorização
Integração e Validação

39. Ilustrando

40. Interatividade
Um Sistema de Marketing exigiria os
seguintes requisitos:
a) Produtos em Estoque;
b) Vendas de um determinado período;
c) Pontos de vendas de um produto;c) Pontos de vendas de um produto;
d) Fabricação no ano;
e) Todos os requisitos anteriores.

41. Modelagem de Casos de Uso
Os Modelos mostram como os valores são
processados, sem preocupações com:
 Ordenamento (sequência) das ações;
 As decisões;
 As estruturas dos objetos; As estruturas dos objetos;
 Dependência de valores entre si e quais
as funções que os relacionam.

42. Modelagem Funcional
Etapas para Modelagem Funcional
 Identificar as requisições de entrada e
saída;
 Construir diagramas mostrando as
dependências funcionais;dependências funcionais;
 Descrever as funções (casos de uso);
 Identificar as restrições.

43. Diagrama de Casos de Uso
O diagrama de casos de uso exerce um
papel importante na análise de Sistemas:
1. É o principal diagrama para ser usado
no diálogo com o usuário na descoberta
e validação de requisitos;
2. Os casos de uso constituem elementos
que estruturam todas as etapas do
processo de software.

44. Analogia com Controle Remoto

45. Tipos de Interação
Comunicação
Representa quais atores estão ligados a
quais casos de uso e é representada pro
um arco simples
Usuário
telefone

46. Tipos de Interação
Inclusão
Um caso inclui outro
Representada através de um arco
pontilhado
ExtensãoExtensão
Um caso de uso pode opcionalmente
utilizar um outro

47. DFD e Diagramas de Caso de Uso
possuem similaridades
Os DFDs são mais complexos em virtude
da maior quantidade de itens
Entidades externas
Depósitos de Dados
Fluxos de DadosFluxos de Dados
Os casos de Uso não descrevem fluxo de
Dados

48. Comentário Final
Os casos de uso são elementos muito
importantes na modelagem de um sistema
baseado em Processo Unificado.
Todas as atividades de desenvolvimento
são organizadas em função dos casos de
uso.

49. Interatividade
Os Casos de Uso são muito importantes
para:
a) Promover a interação dos atores com o
sistema;
b) Realçar a importância do Sistema;b) Realçar a importância do Sistema;
c) Concluir a modelagem de Dados;
d) Interagir com os usuários;
e) Todos os itens anteriores.

50. ATÉ A PRÓXIMA!