Unidade IV MODELAGEM DE. Prof. Daniel Arthur Gennari Junior

Transcrição

1 Unidade IV MODELAGEM DE SISTEMAS 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 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 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 de 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 diferentes equipes de desenvolvimento; Melhor participação dos usuários no processo de desenvolvimento do sistema; 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.

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; d) Bases de interação com o Sistema; e) N.D.A.

10 Conceitos de Orientação a Objeto Os conceitos básicos de orientação a objeto permitem a definição de: Classes; Objetos; 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 abranger.

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 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 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é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 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.

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; 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, 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 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.

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é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 quadro dos fatores que dizem respeito ao sucesso ou fracasso do sistema.

35 Verdadeiras ou Falsos Quando 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 falso. Requisitos tecnológicos falsos: Tecnologias futuras ou passadas; Linguagens a serem utilizadas; 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 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 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á-los. los Busca de fatos Coletas e Classificação de Requisitos Racionalização e Avaliação Priorizaçã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; 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; 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; 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ã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 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; c) Concluir a modelagem de Dados; d) Interagir com os usuários; e) Todos os itens anteriores.

50 ATÉ A PRÓXIMA!