Aula01_VisaoGeral_AOO-1

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
Análise de Requisitos 
Orientada a Objetos
Visão Geral
*
Análise de Requisitos
A analise de requisitos é a extração, definição e validação das necessidades do cliente que devem ser supridas pelo sistema de informação 
É baseada na comunicação entre analistas de sistemas e usuários. Essa comunicação normalmente é problemática devido as limitações cognitivas e diferenças de vocabulário 
*
Tarefas da Análise de Requisitos
1)      Reconhecimento do problema
2)      Avaliação e síntese
3)      Modelagem
4)      Especificação
5) Revisão 
*
1)Compreender conceitos abstratos, reorganiza-los em divisões lógicas e sintetizar soluções baseadas em cada divisão.
2)Absorver fatos pertinentes de fontes conflitantes ou confusas.
3) Comunicar-se bem nas formas escrita e verbal
O Analista deve ter 
capacidade de:
*
Análise de Requisitos
Levantamento de Requisitos
Estudo do Sistema existente (software ou não)
Entrevistas
Questionários
Estudo de Normas, Regulamentos e Legislação
Construção de Protótipos 
*
Princípios de uma boa especificação
Precisa , sem ambigüidade;
Completa;
Verificável;
Consistente;
Rastreável;
Útil também para as fases de Operação e Manutenção.
*
Análise de Requisitos
a engenharia de software define dois métodos para a análise de requisitos:
 		Análise estruturada e
 		Análise Orientada a Objetos.
*
Análise Orientada a Objetos
Enquanto a análise estruturada tem como objetivo levantar as funcionalidades do sistema, a análise orientada a objetos tem como enfoque a descoberta de objetos nas necessidades levantadas junto aos processos de negócios. 
*
Análise Orientada a Objetos
Objeto: Representam “coisas” do mundo real. É uma ocorrência específica (instância) de uma classe.
Classe: é uma descrição de um conjunto de objetos que compartilham os mesmo atributos, operações e relacionamentos.
*
Análise Orientada a Objetos
Mensagem: É um sinal enviado de um objeto a outro requisitando um serviço através da execução de uma operação.  
Polimorfismo: palavra originária do grego “muitas formas”. Tais formas se referem aos vários comportamentos que uma mesma operação pode assumir.
*
Análise Orientada a Objetos
 Herança: é a capacidade de um novo objeto tomar atributos e operações de um objeto existente.
*
Classes
 Tarefa
Detalhar cada ope-
ração, condição,
etc.
Atributos
Métodos
Detalhar natureza,
tamanho de campo
valores válidos.
 Especificação Análise Projeto/Implementação
*
Análise Orientada a Objetos
Para se descobrir os objetos a partir da análise de requisitos é utilizada a UML (Unified Modeling Language), que é uma linguagem que se utiliza intensamente de técnicas gráficas para se verificar as visões dos objetos encontrados. 
Os diagramas são desenhados para permitir a visualização de um sistema sob diferentes perspectivas. 
*
Diagramas UML (2.0)
Caso de Uso;
Classes;
Objetos;
Estrutura composta;
Seqüência;
 Colaboração;
Estado;
Atividades;
Componentes; 
Implantação;
Pacotes;
Interação Geral e
Tempo.
*
Diagrama de Casos de Uso
Os requisitos funcionais do sistema são definidos em termos de casos de usos. 
Um caso de uso descreve a interação entre o ator ( que pode ser um usuário, um dispositivo ou outro sistema) e o sistema. 
Na fase de análise de requisitos, o caso de uso considera o sistema uma caixa preta e descreve as interações entre o ator e o sistema em forma de uma narrativa composta de entradas do ator e as respostas do sistema. 
*
Diagrama de casos de uso
*
Descrição casos de uso
Programar tear: A partir do planejamento da produção é definido o que deverá ser produzido em cada tear. Isto é feito agrupando-se pela cor do urdume, pois esse é o item com maior dificuldade de ser alterado em um tear. A ficha de programação do tear gerada tem as seguintes informações: número do tear, nome do artigo, data, cor, quantidade (peças) e observação. 
*
Classes identificadas a partir da descrição dos casos de uso
*
Protótipo de tela 
*
Diagrama de Seqüência
O diagrama de seqüência mostra um fluxo de controle temporal que representa a ordem com que os métodos de cada classe são invocados.
Em outras palavras, ele apresenta a seqüência lógica com que cada método do SI é invocado.
O diagrama de seqüência contém as classes do modelo de objetos representadas horizontalmente, uma linha vertical para cada classe representando sua fronteira e setas que indicam a invocação de cada método.
*
A partir do caso de uso “Programar Tear” são gerados o diagrama de seqüência e o protótipo de tela
*
Diagrama de Colaboração
Este diagrama tem a finalidade de confirmar os resultados apresentados pelo diagrama de seqüência.
*
Diagrama de Colaboração
*
Diagrama de componentes
Componentes representam o empacotamento físico das classes.
O diagrama de componentes define como será o empacotamento, definindo onde as classes serão armazenadas e exibe os relacionamentos entre os componentes de software.
*
Diagrama de componentes
*
Outros Diagramas
*
Diagrama de Estado
Diagrama de Estado é utilizado para mostrar em classes complexas os comportamento possíveis de seus objetos
*
Diagrama de Estado
*
Diagrama de Atividade
É um diagrama de Estado especial e ao mesmo tempo uma variação dos fluxogramas.
É usado para descrever processos de negócios ou outros fluxos em que o paralelismo de atividades seja importante.
*
Diagrama de Atividade
*
Diagrama de Implantação
Mostra elementos de configuração de processamento, incluindo o uso físico do sistema considerando computadores, dispositivos e suas interconexões.
*
Diagrama de Implantação
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*