Modelagem para Web

1. Modelagem para Web Aula de 11/04/2011

2. Diagramas UML Estruturais Comportamentais Diagrama de Casos de Uso Diagrama de Interação Diagrama de Visão Geral Diagrama de Sequência Diagrama Temporal Diagrama de Comunicação Diagrama de Atividades Diagrama de Máquina de Estados • Diagrama de Classes • Diagrama de Objetos • Diagrama de Componentes • Diagrama de Pacotes • Diagrama de Implantação • Diagrama de Estrutura Composta • Diagrama de Perfil

3. Comparação entre Diagramas

4. Exercícios • Por que a UML foi chamada de linguagem unificada? • Que organização adotou a UML como padrão de metodologia e a qual órgão foi dada a responsabilidade por suas revisões? • Por que dizemos que a UML é uma linguagem de modelagem para visualização de artefatos de software?

5. Exercícios • Que mecanismo de extensão permite que os elementos básicos da UML sejam estendidos? • Quais são os diagramas estruturais da UML 2.0? Que novo diagrama estrutural foi incluído na versão 2.2?

6. Exercícios • A respeito da linguagem UML, é correto afirmar que: • Não se trata de uma linguagem de documentação • É voltada para a representação conceitual e física de um sistema • Não abrange a documentação para a realização de testes • Não deve ser empregada para a documentação de artefatos que façam uso de sistemas complexos de software • É uma linguagem utilizada para a realização de testes de programas

7. Exercícios • Entre outros, a UML inclui diagramas de: • Classes, de objetos, de fluxo de dados e de atividades • Classes, de implantação, de gráficos de estados e de sequência • Objetos, de classes, de contexto e de implantação • Classes, de objetos, de testes e de implantação • Objetos, de casos de uso, de contexto e de implantação

8. Diagramas de Casos de Uso

9. Introdução • A maior dificuldade em modelarmos um sistema não está nos diagramas que temos de desenhar, no código que devemos criar ou nas bases de dados que devemos projetar. Na realidade, está nos requisitos que devemos gerenciar.

10. Levantamento de requisitos • Desenvolvedor (analista) • O que o senhor espera deste sistema? • Usuário • Eu tenho uma loja de peças. Gostaria que o meu PV fosse interligado com o meu estoque e eu pudesse a qualquer momento alterar valores dos FPs. Posso oferecer descontos a alguns tipos de clientes, mas preciso autorizar esta operação. • No fim do mês quero um relatório dos produtos que mais venderam. Preciso também saber a estatística de vendas por forma de pagamento. • De tempos em tempos deve aparecer na tela do sistema uma promoção relâmpago que dê um brinde ao cliente. • Preciso que o sistema controle os pedidos também.

11. Levantamento de requisitos • Existem ambiguidades ou elementos não compreensíveis nesta descrição do usuário? • Cabe ao analista o esclarecimento desses itens. • Ele poderia começar perguntando ao usuário: • O que é PV e FP? • Que tipos de clientes podem receber descontos? • Como seria feita esta autorização de descontos e por quem? • Que quantidade de produtos deve aparecer no relatório dos que mais venderam? • A estatística leva em conta qual período (semanal, quinzenal, mensal etc.)? • Quanto tempo significa “de tempos em tempos”? • Quais pedidos precisam ser controlados: o dos clientes ou os feitos aos fornecedres? • Provavelmente, as respostas a essas perguntas levarão a novas dúvidas, que precisarão ser esclarecidas. • Neste ponto, a modelagem de casos de uso nos ajuda, unindo usuários e desenvolvedores

12. O que é um Caso de Uso? • Um caso de uso (use case) descreve uma sequência de ações que representam um cenário principal (perfeito) e cenários alternativos, com objetivo de demonstrar o comportamento de um sistema (ou parte dele), através de interações com atores. • Cenários alternativos podem ser criados para representar exceções ao cenário perfeito

13. Relacionamento de Casos de Uso e Atores • Associação • Representa a interação do ator com o caso de uso • Generalização • Ocorre entre casos de uso ou entre atores • Extensão (opcional) • Indica que um deles terá o seu procedimento acrescido, em um ponto de extensão, de outro caso de uso, identificado como base • Inclusão (obrigatório) • O comportamento definido em um caso de uso de inclusão é incluído no comportamento de um caso de uso base

14. Representação de atores

15. Diagrama de Casos de Uso

16. A importância dos protótipos • As técnicas atuais de desenvolvimento de software procuram prever mais do que remediar • Com ferramentas RAD atuais, gastamos muito pouco tempo para rascunhar uma tela • Esse rascunho, ao ser mostrado ao usuário, aumenta a segurança quanto à validação de requisitos

17. Exercícios • Desenhe os relacionamentos existentes (include, extend, generalização) entre os casos de uso abaixo:

18. Exercícios • Como pode ser representado um ator na UML? • Para que servem os casos de uso? • É possível colocar condições no cenário principal de um caso de uso? • Como sabemos num caso de uso base o local de incluir o caso de uso de extensão? • Os casos de uso podem ser usados para funções de gerenciamento do sistema, como, por exemplo, backup de dados?

19. Exercícios • Na descrição de caso de uso a seguir, assinale o que está inadequado

20. Caso deUso: Solicitar vale-refeição/alimentação • Objetivo: verificar os funcionários que recebem vale-refeição/alimentação, a quantidade de dias úteis do mês e processar pedido, levando em conta a opção do funcionário, bem como situações especiais como férias, licenças etc. • Ator: Emilia Maria • Cenário Principal 1. O sistema verifica para cada funcionário: 1.1. O número de dias úteis do mês de referência 1.2. A opção do funcionário (refeição/alimentação) 1.3. Se o funcionário estiver ativo: 1.3.1. Multiplicar o número de dias úteis pelo valor do ticket padrão 1.3.2. Gravar linha do arquivo de solicitação 1.3.3. Atualizar o sistema de RH com o valor de desconto do ticket • Cenário alternativo 1.3. Se o funcionário estiver de férias ou de licença, não realizar a solicitação do vale e checar novo funcionário

21. Exercícios • A Visão do Caso de Uso em UML descreve: • O comportamento da distribuição, do fornecimento e instalação das partes que compõe o sistema físico • A especificação da organização do sistema de software • A visão de questões referentes ao desempenho do sistema • O comportamento do sistema conforme é visto pelos usuários finais • A modelagem dos aspectos dinâmicos do sistema