14-03-2012           Bases de Dados              Paulo AzevedoObjectivos• Aquisição de um processo simplificado de  desenv...
14-03-2012Produção de software• A produção de software é frequentemente  uma actividade não estruturada, sem  orientações ...
14-03-2012Produção de softwareRegra dos quatro “P’s”:  – Pessoas – Só com Motivação e compromisso é que    se consegue gar...
14-03-2012Produção de software  Processo de desenvolvimento de sw é uma  sequência de actividades, agrupadas em fases,  ex...
14-03-2012Produção de software  Metodologias de desenvolvimento de sw  sequência de etapas e procedimentos  recomendados p...
14-03-2012Produção de software Um modelo consiste na interpretação de um dado domínio do problema, segundo uma determinada...
14-03-2012Produção de softwareBenefícios da modelação:• Modelos ajudam a visualizar um esquema;• Permitem especificar a es...
14-03-2012Produção de softwareAproximação estruturada ou funcional:• Diversidade de autores propõem abordagens  especifica...
14-03-2012Produção de softwareSSADM:• Metodologia de referência e ensinada em  diversos cursos universitários;• Diagramas ...
14-03-2012Produção de software  Aproximação baseada no paradigma dos  objectos:• Notação padronizada, constituída por um  ...
14-03-2012Produção de software    Contribuições para o UML:                                                               ...
14-03-2012UML                       Paulo Azevedo - Fev/2011              23UML• Resultado de um longo processo de maturaç...
14-03-2012UML• Um modelo UML é constituído por um conjunto  de diagramas que representam aspectos  complementares de um SI...
14-03-2012UML – Diagrama de Use Cases Serve para identificar as fronteiras do sistema e descrever os serviços (use cases) ...
14-03-2012UML – Diagrama de Objectos Utilizado para ilustrar um diagrama de classes com um exemplo concreto.              ...
14-03-2012UML – Diagrama de Actividade Pode ser utilizado para descrever cada um dos use cases, realçando o encadeamento d...
14-03-2012UML – Diagrama de Componentes Utilizado para descrever a arquitectura da aplicação informática em termos de comp...
14-03-2012UML• Métodos que se baseiam na utilização da  notação UML:  – Rational Unified Process (RUP), da Rational       ...
14-03-2012Modelação de software• Um projecto de desenvolvimento engloba três  grandes etapas (ver figura):  – Análise da O...
14-03-2012 Ciclo de vida • Preparar - investigar a área do problema e fixar   os requisitos e âmbito da solução; • Constru...
14-03-2012Fase 1 - Panorâmica A fase Preparar envolve actividades para as quais não é particularmente importante ser versa...
14-03-2012Fase 1 – Definir requisitos     Empresa ABC     1 – Propósito     -…     -…     2 – Objectivos     -…     -…    ...
14-03-2012Quais os requisitos essenciais para uma soluçãode posto de venda para a empresa ABC?                   Paulo Aze...
14-03-2012Diagramas CU• Representa uma acção entre um utilizador  (humano ou máquina) e um sistema;• Descrevem a funcional...
14-03-2012Diagramas UC• Actor – Papel que um utilizador desempenha  relativamente ao sistema em análise. Também  pode corr...
14-03-2012Exemplo                       Aplicação GesEscola                                  Efectuar Inscrição           ...
14-03-2012CenárioForma livre  Caso de utilização inicia-se quando o aluno  acede ao sistema GesEscola, selecciona uma  esc...
14-03-2012Proposta  Com base nos requisitos identificados na  empresa ABC vamos construir um modelo de  casos de utilizaçã...
14-03-2012Regras PráticasDuas técnicas para levantamento de UCs• Baseadas no actores:   – Identificar os actores relevante...
14-03-2012Regras Práticas No processador de texto, escrever cada UC no modo essencial.                 Paulo Azevedo - Fev...
14-03-2012Regras Práticas              Paulo Azevedo - Fev/2012   61Descrição detalhada do UC              Paulo Azevedo -...
14-03-2012Descrição detalhada do UC                  Paulo Azevedo - Fev/2012     63Proposta Durante o semestre o Prof. Fa...
14-03-2012PropostaNeste caso identificamos os seguintes UCs:1. Enviar sumários via e-mail;2. Actualizar sumários via web;3...
14-03-2012PropostaDiagrama de UC                  Paulo Azevedo - Fev/2012      67Relações entre UC As relações mais frequ...
14-03-2012Include Neste diagrama utiliza-se a relação <<include>> para demonstrar que a funcionalidade “controlo de acesso...
14-03-2012Generalização O comportamento do UC “efectuar encomenda internet” é semelhante ao UC “efectuar encomenda”, exist...
14-03-2012Generalização A relação também pode ser efectuada entre dois actores. No exemplo é estabelecido uma relação de g...
14-03-2012Generalização  Ilustre a seguinte generalização entre os  actores: Patrão e Empregado. Ambos são  recursos human...
14-03-2012Revisão1. O que significa Use Case?   Constituem a técnica UML para representar o   levantamento de requisitos d...
14-03-2012Revisão5. Para que servem os diagramas de UC?   Para apresentação de requisitos e para   assegurar que tanto o u...
14-03-2012Revisão7. Que tipos de requisitos existem?   Funcionais – Descrevem o que o sistema faz, ou se   pretende que fa...
14-03-2012Exercícios     De uma entrevista com o responsável de biblioteca de     uma universidade resultou a seguinte des...
Próximos SlideShares
Carregando em…5
×

Software

606 visualizações

Publicada em

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
606
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Software

  1. 1. 14-03-2012 Bases de Dados Paulo AzevedoObjectivos• Aquisição de um processo simplificado de desenvolvimento de soluções de software, baseada na utilização da notação UML e técnicas associadas. Paulo Azevedo - Fev/2012 2 1
  2. 2. 14-03-2012Produção de software• A produção de software é frequentemente uma actividade não estruturada, sem orientações de natureza estratégica e sem planos de gestão e controlo;• Os problemas associados ao desenvolvimento de software são tão complexos que é necessário a utilização de princípios, regras e estratégias que conduzam a melhorias. Paulo Azevedo - Fev/2012 3Produção de software• Definir o tipo de intervenção e conjugar correctamente as interacções entre as pessoas, o processo aplicado, as características do produto e o projecto que orienta as actividades a desenvolver.• Regra dos quatro “P’s”. Paulo Azevedo - Fev/2012 4 2
  3. 3. 14-03-2012Produção de softwareRegra dos quatro “P’s”: – Pessoas – Só com Motivação e compromisso é que se consegue garantir o sucesso; – Processo – Com técnicas e regras bem definidas; – Produto – Compreendendo as necessidades reais dos utilizadores obtemos um resultado com qualidade; – Projecto – Deve ser credível e controlado para cumprir prazos e custos propostos Paulo Azevedo - Fev/2012 5Produção de softwareUm projecto de sistemas de informação deve responder – W5H2 (Barry Boehm 1996): – Porque é que vai ser desenvolvido WHY; – O que vai ser feito/deve ser feito WHAT; – Quando é que vai ser feito WHEN; – Quem é o responsável WHO; – Onde estão as responsabilidades WHERE; – Como é que vai ser feito HOW; – Quanto vai custar HOW MUCH. Paulo Azevedo - Fev/2012 6 3
  4. 4. 14-03-2012Produção de software Processo de desenvolvimento de sw é uma sequência de actividades, agrupadas em fases, executadas de forma sistemática e uniformizada, realizadas por intervenientes com responsabilidades definidas em que a partir de um conjunto de entradas se produzem um conjunto de saídas. Tem quatro objectivos fundamentais. Paulo Azevedo - Fev/2012 7Produção de software Objectivos do Processo de desenvolvimento de sw:1. Providenciar orientação sobre a sequência de realização das actividades;2. Especificar modelos descritivos do sistema que devem ser desenvolvidos;3. Dirigir tarefas dos participantes e da equipa;4. Providenciar critérios para monitorização e avaliação dos modelos. Paulo Azevedo - Fev/2012 8 4
  5. 5. 14-03-2012Produção de software Metodologias de desenvolvimento de sw sequência de etapas e procedimentos recomendados para serem aplicados durante o processo de desenvolvimento de SI. Acrescenta a utilização de um conjunto de ferramentas, técnicas e notações. Inclui referências a princípios e regras para concretizar na prática regras teóricas Paulo Azevedo - Fev/2012 9Produção de softwarePrincípios Metodologias de desenvolvimento sw:• Elaborar estimativas (custos/prazos);• Técnicas para efectuar medições;• Procedimentos para garantir qualidade;• Programas de formação;• Modelos de documentação a produzir;• Modelos práticos;• Técnicas para configuração de metodologia. Paulo Azevedo - Fev/2012 10 5
  6. 6. 14-03-2012Produção de software Um modelo consiste na interpretação de um dado domínio do problema, segundo uma determinada estrutura de conceitos. Um esquema é a especificação de um modelo usando uma determinada linguagem, formal ou informal. A representação gráfica de um esquema é um diagrama. Paulo Azevedo - Fev/2012 11Produção de software A modelação é a arte e a ciência de criar modelos de uma determinada realidade. Técnica aceite pela generalidade das disciplinas conhecidas. Permite a partilha de conhecimento entre grupos intervenientes. Paulo Azevedo - Fev/2012 12 6
  7. 7. 14-03-2012Produção de softwareBenefícios da modelação:• Modelos ajudam a visualizar um esquema;• Permitem especificar a estrutura ou comportamento de um sistema;• Controlar e guiar o processo de construção do sistema;• Documentam decisões tomadas. Paulo Azevedo - Fev/2012 13Produção de software A Evolução das técnicas e metodologias de modelação divide-se em duas fases (Rumbaugh, 1996):1. Aproximação estruturada ou funcional;2. Aproximação baseada no paradigma dos objectos. Paulo Azevedo - Fev/2012 14 7
  8. 8. 14-03-2012Produção de softwareAproximação estruturada ou funcional:• Diversidade de autores propõem abordagens especificas e nomenclaturas distintas para a modelação de sistemas de informação;• Grande diversidade de propostas tornava difícil a comunicação e reduzia a utilidade prática desta área de conhecimento; Paulo Azevedo - Fev/2012 15Produção de softwareAproximação estruturada ou funcional (cont.):• Diferenças nos modelos semânticos, notação sintáctica e diagramas originaram uma proposta unificadora;• SSADM, Yourdon. Paulo Azevedo - Fev/2012 16 8
  9. 9. 14-03-2012Produção de softwareSSADM:• Metodologia de referência e ensinada em diversos cursos universitários;• Diagramas de Fluxos de Dados;• Diagramas Entidade Relação;• Diagramas de Ciclo da Vida das Entidades;• Focada na análise e desenho do sistema, não contempla tarefas relacionadas com a implementação. Paulo Azevedo - Fev/2012 17Produção de softwareYourdon:• Baseada da filosofia da decomposição funcional (top down);• Suportada na utilização de DFD;• Recorre muito à decomposição funcional;• Atribui importância significativa à estrutura de dados. Paulo Azevedo - Fev/2012 18 9
  10. 10. 14-03-2012Produção de software Aproximação baseada no paradigma dos objectos:• Notação padronizada, constituída por um conjunto limitado de elementos que podem ser tipificados em diagramas, abstracções e relacionamentos. Paulo Azevedo - Fev/2012 19Produção de software Booch, Jacobson e Rumbaugh iniciaram um trabalho para apresentar uma proposta unificadora dos seus trabalhos individuais. Este trabalho deu origem ao UML (Unified Modelling Language), apresentado publicamente em Outubro de 1995. Em Novembro de 1997 a UML foi adoptada pela OMG como linguagem de modelação padronizada. Paulo Azevedo - Fev/2012 20 10
  11. 11. 14-03-2012Produção de software Contribuições para o UML: V 1.0 V 1.4 V 2.0 1997 2001 2004Wirfs-Brock Coad-Yourdon Gamma et al. Wirfs-Brock 1990 1991 1995 1997 UMLShlaer-Mellor Rumbaugh Booch Jacobson 1989 1991 1994 1995 V 1.3 V 1.5 1999 2003 Paulo Azevedo - Fev/2012 21Produção de software Actualmente na versão 2.0. Esta versão demonstra um grau de maturidade da linguagem, utilizando princípios da meta-modelação para definir os conceitos do UML através da própria linguagem. Paulo Azevedo - Fev/2012 22 11
  12. 12. 14-03-2012UML Paulo Azevedo - Fev/2011 23UML• Resultado de um longo processo de maturação no domínio da modelação.• Fornece uma linguagem universal para especificação de software.• A utilização da notação UML deve ser enquadrada pela adopção de um processo que estruture o trabalho de desenvolvimento: – O que deve ser feito; – Como deve ser feito, como fazer (técnicas a utilizar). Paulo Azevedo - Fev/2012 24 12
  13. 13. 14-03-2012UML• Um modelo UML é constituído por um conjunto de diagramas que representam aspectos complementares de um SI.• Em cada um destes diagramas são utilizados símbolos que representam os elementos que estão a ser modelados (abstracções) e linhas que relacionam esses elementos.• Os símbolos e as linhas têm significado especifico e possuem formas distintas, constituindo um modo de notação. Paulo Azevedo - Fev/2012 25UML - Diagramas O UML disponibiliza o seguinte conjunto de diagramas:1. Diagrama de Use Cases;2. Diagrama de Classes;3. Diagrama de Objectos;4. Diagrama de Sequência e Diagrama de Colaboração;5. Diagrama de Actividade;6. Diagrama de Estados;7. Diagrama de Componentes;8. Diagrama de Instalação Paulo Azevedo - Fev/2012 26 13
  14. 14. 14-03-2012UML – Diagrama de Use Cases Serve para identificar as fronteiras do sistema e descrever os serviços (use cases) que devem ser disponibilizados a cada um dos diversos utilizadores (actores). Paulo Azevedo - Fev/2012 27UML – Diagrama de Classes Através do qual descrevemos a estrutura da informação (classes e suas relações) que é utilizada no sistema. Paulo Azevedo - Fev/2012 28 14
  15. 15. 14-03-2012UML – Diagrama de Objectos Utilizado para ilustrar um diagrama de classes com um exemplo concreto. Paulo Azevedo - Fev/2012 29UML – Diagrama de sequência e colaboração Ilustram como os objectos do sistema interagem para fornecer a funcionalidade do use case. Estes diagramas designam-se genericamente por diagramas de interacção. Paulo Azevedo - Fev/2012 30 15
  16. 16. 14-03-2012UML – Diagrama de Actividade Pode ser utilizado para descrever cada um dos use cases, realçando o encadeamento de actividades realizadas por cada um dos objectos do sistema, numa óptica de fluxo de trabalho. Paulo Azevedo - Fev/2012 31UML – Diagrama de Estados Utilizado para modelar o comportamento dos objectos, isto é, descrever as alterações nos valores de atributos dos objectos em resultado da ocorrência de certos eventos . Paulo Azevedo - Fev/2012 32 16
  17. 17. 14-03-2012UML – Diagrama de Componentes Utilizado para descrever a arquitectura da aplicação informática em termos de componentes de software Paulo Azevedo - Fev/2012 33UML – Diagrama de Instalação Permite descrever a arquitectura de equipamento informático utilizado e atribuição dos componentes da aplicação aos diversos equipamentos. Paulo Azevedo - Fev/2012 34 17
  18. 18. 14-03-2012UML• Métodos que se baseiam na utilização da notação UML: – Rational Unified Process (RUP), da Rational 2 Software, por Philippe Kruchten, Ivar Jacobson e outros; – Extreme Programming (XP), por Kent Beck e 3 outros; – Feature Dreaven Development (FDD), por Peter4 Coad; Paulo Azevedo - Fev/2012 35UML• No projecto de desenvolvimento que aqui exploramos, vamos utilizar um Processo Simplificado. O objectivo não é discutir um Processo completo e com alguma complexidade, mas mostrar a aplicação da UML de uma forma ágil e consequente. Paulo Azevedo - Fev/2012 36 18
  19. 19. 14-03-2012Modelação de software• Um projecto de desenvolvimento engloba três grandes etapas (ver figura): – Análise da Organização (análise estratégica, levantamento de requisitos, etc.); – Especificação do sistema de software que responda às necessidades identificadas; – Implementação e instalação da solução Processo de desenvolvimento Análise do Especificação do Implementação negócio sistema de SW Técnicas; Técnicas; Técnicas; Instrumentos; Instrumentos; Instrumentos; Ferramentas. Ferramentas. Paulo Azevedo - Fev/2012 Ferramentas. 37Exemplo Implementar um mini-projecto para a gestão de um ponto de venda de uma loja. O problema pode ser formulado nestes termos: “A empresa ABC necessita de um sistema informático para registar as vendas, que têm lugar na loja, ao consumidor final, assim como os respectivos pagamentos.” Sabemos o que queremos fazer! Mas, por onde começar? Paulo Azevedo - Fev/2012 38 19
  20. 20. 14-03-2012 Ciclo de vida • Preparar - investigar a área do problema e fixar os requisitos e âmbito da solução; • Construir - analisar o problema, e construir modelos abstractos de resolução. Destes modelos, evoluir para especificações lógicas da solução pretendida e, finalmente, implementar numa linguagem de programação.; • Instalar - transferir a solução para os ambientes reais de produção. Paulo Azevedo - Fev/2012 39 Ciclo de vida Preparar Construir InstalarCompreensão do problema; Modelos de Análise e Transferência paraRequisitos e âmbito do Desenho; ambiente de produçãosistema; Protótipo operacional.Plano de projecto. Paulo Azevedo - Fev/2012 40 20
  21. 21. 14-03-2012Fase 1 - Panorâmica A fase Preparar envolve actividades para as quais não é particularmente importante ser versado em competências "Orientadas ao Objecto". O principal objectivo é identificar claramente quais são os requisitos do sistema a desenvolver de modo a suportar o planeamento, avaliação do risco e benefícios, bem como colher o compromisso de avançar junto do “cliente”. Paulo Azevedo - Fev/2012 41Fase 1 – Definir requisitos A análise de requisitos é uma disciplina só por si, para além do âmbito deste texto. A bem da simplicidade, vamos abreviar e avançar uma listagem informal de requisitos. No nosso caso de estudo, vamos limitar-nos ao processador de texto Microsoft Word. Verdadeiramente importante é que neste processo não sejam omitidos requisitos! Paulo Azevedo - Fev/2012 42 21
  22. 22. 14-03-2012Fase 1 – Definir requisitos Empresa ABC 1 – Propósito -… -… 2 – Objectivos -… -… 3 – Cliente -… 4 – Requisitos funcionais -RF1 -RF2 5 – Atributos do sistema Performance; Interfaces Paulo Azevedo - Fev/2012 43Regra prática• Os requisitos devem ser numerados de forma a poderem ser rastreados nas fases subsequentes do desenvolvimento. Paulo Azevedo - Fev/2012 44 22
  23. 23. 14-03-2012Quais os requisitos essenciais para uma soluçãode posto de venda para a empresa ABC? Paulo Azevedo - Fev/2012 45Exemplo Problema: “A empresa ABC necessita de um sistema informático para registar as vendas, que têm lugar na loja, ao consumidor final, assim como os respectivos pagamentos.” Paulo Azevedo - Fev/2012 46 23
  24. 24. 14-03-2012Diagramas CU• Representa uma acção entre um utilizador (humano ou máquina) e um sistema;• Descrevem a funcionalidade que um actor necessita de executar para obter um determinado resultado, um objectivo;• Diagramas de alto nível, pouco detalhados;• Sequência de acções que um ou mais actores realizam num sistema [OMG99]. Paulo Azevedo - Fev/2012 47Diagramas CU• O Diagrama de CU funciona frequentemente como instrumento de comunicação com os utilizadores. Actores ACTOR Caso de Utilização Casos de Utilização Paulo Azevedo - Fev/2012 48 24
  25. 25. 14-03-2012Diagramas UC• Actor – Papel que um utilizador desempenha relativamente ao sistema em análise. Também pode corresponder a um SI ou hardware.• Caso de Utilização – Especificação de uma sequência de acções que um sistema pode realizar interagindo com actores do sistema. Paulo Azevedo - Fev/2012 49Regras Práticas• Os UC são modelados como elipses;• Os UC devem começar com um verbo no infinitivo. Esta técnica dá enfoque à natureza funcional dos UC. Por exemplo: – “Levantar dinheiro”; – “Agendar consulta”; – “Efectuar inscrição”.• Actores, figuras estilizadas de pessoas. Paulo Azevedo - Fev/2012 50 25
  26. 26. 14-03-2012Exemplo Aplicação GesEscola Efectuar Inscrição Aluno Paulo Azevedo - Fev/2012 51Cenário Principal e Secundário A descrição do cenário pode assumir a forma de texto livre ou estruturada, segundo um conjunto de passos numerados. As especificações do cenários devem incluir: – Pressupostos; – Pré-condições; – Inicialização; – (…). Paulo Azevedo - Fev/2012 52 26
  27. 27. 14-03-2012CenárioForma livre Caso de utilização inicia-se quando o aluno acede ao sistema GesEscola, selecciona uma escola, verifica os cursos existentes e efectua a sua inscrição no curso. Termina após inscrição. Paulo Azevedo - Fev/2012 53CenárioForma estruturadaEfectuar InscriçãoPré condição Aluno é utilizador válido. 1 – UC começa quando aluno selecciona a opção efectuar inscrição; 2 – Sistema mostra lista de escolas; 3 – Aluno selecciona escola; 4 – Sistema mostra lista de cursos; 5 – Aluno selecciona curso; 6 – Aluno efectua inscrição.Pós condição Aluno recebe comprovativo da inscrição. Paulo Azevedo - Fev/2012 54 27
  28. 28. 14-03-2012Proposta Com base nos requisitos identificados na empresa ABC vamos construir um modelo de casos de utilização de alto nível.1. Enumerar os actores que interagem com o sistema;2. Levantar casos de utilização (UC) do sistema. “A empresa ABC necessita de um sistema informático para registar as vendas, que têm lugar na loja, ao consumidor final, assim como os respectivos pagamentos.” Paulo Azevedo - Fev/2012 55Proposta Paulo Azevedo - Fev/2012 56 28
  29. 29. 14-03-2012Regras PráticasDuas técnicas para levantamento de UCs• Baseadas no actores: – Identificar os actores relevantes relacionados com o sistema ou organização; – Para cada actor, identificar os processos que ele inicia ou participa.• Baseada em eventos: – Identificar eventos do exterior que a empresa tem de responder; – Relacionar os eventos com actores e UCs. Paulo Azevedo - Fev/2012 57Regras Práticas• Depois de identificados, os UC são especificados através de descrições textuais estruturadas. O nível de detalhe é variável, podendo a descrição centrar-se na intenção do UC (chamado de essencial – foco na essência do processo) ou detalhar a sua implementação concreta (chamado de real).• Um UC essencial não está dependente de tecnologia de implementação enquanto que um UC real refere as opções concretas da sua realização ("Introduzir código do produto" vs. "Ler código através de um leitor óptico de códigos de barras"). Paulo Azevedo - Fev/2012 58 29
  30. 30. 14-03-2012Regras Práticas No processador de texto, escrever cada UC no modo essencial. Paulo Azevedo - Fev/2012 59Regras Práticas De forma a evidenciar o actor, a descrição geral do UC pode iniciar-se com uma estrutura padrão do tipo: • <Actor>; • <Verbo>; • <Acção>. Paulo Azevedo - Fev/2012 60 30
  31. 31. 14-03-2012Regras Práticas Paulo Azevedo - Fev/2012 61Descrição detalhada do UC Paulo Azevedo - Fev/2012 62 31
  32. 32. 14-03-2012Descrição detalhada do UC Paulo Azevedo - Fev/2012 63Proposta Durante o semestre o Prof. Faísca foi enviando os sumários com breves resumos da matéria leccionada, via e-mail, para o sistema Fly2. Após o fim das aulas, o Prof. Faísca utilizou a interface web do sistema para actualizar cada um dos sumários com descrições mais completas das matérias leccionadas. Finda essa actualização imprimiu os sumários e enviou-os à Secretaria. Paulo Azevedo - Fev/2012 64 32
  33. 33. 14-03-2012PropostaNeste caso identificamos os seguintes UCs:1. Enviar sumários via e-mail;2. Actualizar sumários via web;3. Imprimir sumários (via web?/via e-mail?);4. Enviar sumários à secretaria — deverá este use case ser considerado? No cenário descrito o envio é feito em papel. Não se trata, portanto, de um serviço fornecido pelo sistema. No entanto, podemos discutir a possibilidade de o envio passar a ser feito electronicamente. Durante o semestre o Prof. Faísca (1.) foi enviando os sumários com breves resumos da matéria leccionada, via e-mail, para o sistema Fly2. Após o fim das aulas, o Prof. Faísca (2.) utilizou a interface web do sistema para actualizar cada um dos sumários com descrições mais completas das matérias leccionadas. Finda essa actualização (3.) imprimiu os sumários e (4.) enviou-os à Secretaria. Paulo Azevedo - Fev/2012 65PropostaNeste caso identificamos os seguintes Actores:1. Docente;2. Aluno;3. Secretaria. “Quem vai usar o sistema” Paulo Azevedo - Fev/2012 66 33
  34. 34. 14-03-2012PropostaDiagrama de UC Paulo Azevedo - Fev/2012 67Relações entre UC As relações mais frequentes entre UC são <<include>> e <<extend>> e generalização. <<Include>> ou <<uses>> - Significa que um determinado UC utiliza ou inclui a a funcionalidade disponibilizada noutro UC; <<extend>> - Ocorre quando existe um comportamento opcional que deve ser incluído num UC; Generalização – Quando existe um caso particular de outro UC. Paulo Azevedo - Fev/2012 68 34
  35. 35. 14-03-2012Include Neste diagrama utiliza-se a relação <<include>> para demonstrar que a funcionalidade “controlo de acesso” é utilizada quando a encomenda é feita pela internet. Alguns autores utilizam <<uses>> em vez de <<include>>. Esta relação é útil para evitar a duplicação de UC. Paulo Azevedo - Fev/2012 69Extend O mecanismo de pontos de extensão permite definir no UC base onde o comportamento será incorporado, sem alterar a sua descrição. Também garante que o comportamento não se altera se ele deixe de existir Neste diagrama utiliza-se a relação <<extend>> para demonstrar que a funcionalidade “Desconto internet” pode ser aplicada. Paulo Azevedo - Fev/2012 70 35
  36. 36. 14-03-2012Generalização O comportamento do UC “efectuar encomenda internet” é semelhante ao UC “efectuar encomenda”, existindo apenas variações especificas do meio onde é efectuada a encomenda. Paulo Azevedo - Fev/2012 71Generalização A generalização possui as mesmas propriedades que uma relação “pai/filho”, onde o UC filho herda ou substitui por completo o comportamento do UC pai, por exemplo o UC “controlo de acesso” pode ser realizado de duas formas diferentes, consoante seja efectuado na loja ou na internet. Paulo Azevedo - Fev/2012 72 36
  37. 37. 14-03-2012Generalização A relação também pode ser efectuada entre dois actores. No exemplo é estabelecido uma relação de generalização entre o actor “funcionário” e o actor “empregado de balcão” (caso geral -> caso específico). Esta relação evita a duplicação de relações. Paulo Azevedo - Fev/2012 73Generalização O que significa esta generalização?. Paulo Azevedo - Fev/2012 74 37
  38. 38. 14-03-2012Generalização Ilustre a seguinte generalização entre os actores: Patrão e Empregado. Ambos são recursos humanos de uma organização: “Todas as manhãs os recursos da organização registam a hora de entrada no relógio de ponto da empresa ABC. Semanalmente, o patrão extrai o registo de horas do relógio e envia a listagem para o departamento de recursos humanos.” Paulo Azevedo - Fev/2011 75RevisãoPerguntas de revisão:1. O que significa Use Case?2. Qual a notação para Use Case?3. O que significa Actor?4. Qual a notação para Actor?5. Para que servem os diagramas de UC?6. Defina conceito de requisito.7. Que tipos de requisitos existem?8. Que tipos de relação podem ser efectuadas entre UC?9. Qual a diferença entre <<extend>> e <<include>>? Paulo Azevedo - Fev/2012 76 38
  39. 39. 14-03-2012Revisão1. O que significa Use Case? Constituem a técnica UML para representar o levantamento de requisitos de um sistema. Desde sempre que o correcto levantamento de requisitos no desenvolvimento de sistemas de informação tenta garantir que o sistema seja útil para o utilizador final, estando de acordo com as necessidades2. Qual a notação para Use Case? Elipse Paulo Azevedo - Fev/2012 77Revisão3. O que significa Actor? Um actor representa uma entidade externa que interage com o sistema. Devem ser caracterizados através de um pequena descrição, de forma a assegurar uma correcta compreensão do significado do actor por todos os elementos da equipa envolvida da análise.4. Qual a notação para Use Case? Figuras estilizadas de pessoas Paulo Azevedo - Fev/2012 78 39
  40. 40. 14-03-2012Revisão5. Para que servem os diagramas de UC? Para apresentação de requisitos e para assegurar que tanto o utilizador final como o perito numa determinada área, ou o especialista informático possuem um entendimento comum dos requisitos. O objectivo é mostrar o que um sistema deve efectuar e não como o vai fazer. Paulo Azevedo - Fev/2012 79Revisão6. Defina conceito de requisito Funcionalidade ou característica considerada relevante na óptica do utilizador. Normalmente, representa um comportamento esperado do sistema, que na prática consiste num serviço que deve ser disponibilizado a um utilizador. Paulo Azevedo - Fev/2012 80 40
  41. 41. 14-03-2012Revisão7. Que tipos de requisitos existem? Funcionais – Descrevem o que o sistema faz, ou se pretende que faça. Requisitos levantados inicialmente. Descrição de processamentos a efectuar pelo sistema, inputs e outputs; Não funcionais – Relacionados com as características qualitativas do sistema, descrevendo a qualidade com que o sistema deverá fornecer requisitos funcionais (tempos de resposta); Usabilidade – Garantem uma boa relação entre o sistema desenvolvido, utilizadores do sistema e também as tarefas que desempenham apoiados pelo sistema. Paulo Azevedo - Fev/2012 81Revisão8. Que tipos de relação podem ser efectuadas entre UC? <<extend>>; <<include>> e generalização9. Qual a diferença entre <<extend>> e <<include>>? <<include>> - Significa que um determinado UC utiliza ou inclui a a funcionalidade disponibilizada noutro UC; <<extend>> - Ocorre quando existe um comportamento opcional que deve ser incluído num UC; Paulo Azevedo - Fev/2012 82 41
  42. 42. 14-03-2012Exercícios De uma entrevista com o responsável de biblioteca de uma universidade resultou a seguinte descrição para um novo SI: “Uma das actividades principais da biblioteca é efectuar o empréstimo de publicações aos alunos da universidade. O empréstimo é registado pelos funcionários da biblioteca, que também consultam diariamente os empréstimos cujos prazos foram ultrapassados. Todo este processo é realizado manualmente, sendo muito ineficiente. Espera- se que o novo sistema resolva esta situação. Os alunos necessitam de pesquisar livros existentes na biblioteca. Caso um livro esteja requisitado, é mostrada a data esperada de entrega.” Paulo Azevedo - Fev/2012 83Exercícios Considere os seguintes requisitos de um SI para gestão de um parque de estacionamento.a) O controlo é efectuado com base na matrícula do veículo;b) Na entrada do parque existirá um funcionário que introduz as matrículas do sistema, ficando de imediato registado a data e hora de início de estacionamento. O sistema tem de verificar as a matrícula existe;c) Se a matrícula não for reconhecida pelo sistema, então o funcionário registará um novo veículo no sistema;d) Na saída, um funcionário introduz novamente a matrícula, calculando o sistema o custo do estacionamento;e) O gestor do parque de estacionamento precisa de consultar diariamente uma listagem dos estacionamentos. Em algumas situações, o gestor poderá desempenhar as funções de atendimento, no entanto, apenas o gestor poderá obter listagens. Paulo Azevedo - Fev/2012 84 42

×