Baixe o app para aproveitar ainda mais
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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Compartilhar