Técnicas e Projeto de Sistemas

1. Técnicas e Projeto de Sistemas André Mesquita Rincon andrerincon@ifto.edu.br andre.rincon@gmail.com Engenharia de requisitos – Continuação Técnico Subsequente – Módulo III (05/04/2010)

2. Engenharia de requisitos • A Engenharia de Requisitos é o processo de identificar todos os envolvidos (stakeholders), descobrir seus objetivos e necessidades, e documentá-los de forma adequada para análise, comunicação e posterior implementação • A maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades: • Elicitação de requisitos • Análise de requisitos • Especificação de requisitos • Validação de requisitos

3. Engenharia de requisitos • Visão geral de UML • UnifiedModelingLanguage (Linguagem de Modelagem Unificada) • UML é uma linguagem para visualização, especificação, construção e documentação de artefatos de um software orientado a objeto • Visa facilitar a comunicação entre “clientes” e desenvolvedores

4. Engenharia de requisitos • Visão geral de UML • Diagrama de classes • Diagrama de objetos • Diagrama de casos de uso • Diagrama de seqüência • Diagrama de colaborações • Diagrama de gráficos de estados • Diagrama de atividades • Diagrama de componentes • Diagrama de implantação

5. Casos de uso • Objetivo • Um diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário • O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema

6. Casos de uso • Atores • Um ator é representado por um boneco e um rótulo com o nome do ator • Um ator é um usuário do sistema, que pode ser um usuário humano ou um outro sistema computacional

7. Casos de uso • Casos de uso • Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso e define uma funcionalidade do sistema

8. Casos de uso • Relacionamento • Entre um ator de um caso de uso • Associação: define uma funcionalidade do sistema do ponto de vista do usuário • Entre atores • Generalização: os casos de uso de B são também casos de uso de A, mas A pode ter seus próprios casos de uso

9. Casos de uso • Relacionamento • Entre casos de uso • Include: um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A • Extend: um relacionamento extend de um caso de uso B para um caso de uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é essencial). A extensão é inserida em um ponto de extensão do caso de uso A.

10. Casos de uso • Exemplo de diagrama de caso de uso

11. Casos de uso • Estudo de caso: ferramenta de EAD (web) • Gerenciamento de aulas • Gerenciamento de conteúdo (usuários não cadastrados podem baixar) • Gerenciamento de usuários • Gerenciamento de fórum • Atores • Usuários não cadastrados • Alunos • Professores

12. Requisitos não funcionais • Requisitos não-funcionais descrevem características do sistema (como o sistema é) ao invés de suas funcionalidades (o que ele faz) • Podem constituir restrições aos requisitos funcionais • Assim como os funcionais eles devem ser verificáveis

13. Requisitos não funcionais • Uma prática comum é estabelecer a ISO/IEC 9126 como base para especificação dos requisitos não funcionais • Confiabilidade • Usabilidade • Eficiência • Manutenibilidade • Portabilidade

14. Requisitos não funcionais • Confiabilidade • Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas • Exemplo 1: O tempo médio suportado para recuperação de uma falha no sistema nas funcionalidades essenciais para se realizar XPTO deve ser menor que 1 hora • Exemplo 2: O tempo médio suportado para recuperação de uma falha no sistema em funcionalidade não crucial para a realização de XPTO deve ser menor que 6 horas

15. Requisitos não funcionais • Usabilidade • Capacidade do produto de software de ser compreendido, aprendido, operado e ser atraente ao usuário, quando usado sob condições especificadas • Exemplo 1: O sistema deverá fornecer tópicos de ajuda para cada tela apresentada ao usuário, descrevendo o funcionamento e a descrição dos campos da tela • Exemplo 2: Os usuários deverão ser capazes de utilizar o software, executando todas as funcionalidades disponibilizadas após uma demonstração de no máximo 10 minutos para cada uma das funcionalidades e características do software • Exemplo 3: O sistema deverá ter como único idioma (Português do Brasil)

16. Requisitos não funcionais • Eficiência • Capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas • Exemplo 1: O sistema deve permitir o acesso de pelo menos 50 usuários simultâneos sem perdas perceptíveis (ao usuário) de desempenho

17. Requisitos não funcionais • Manutenibilidade • Capacidade do produto de ser modificado • Exemplo 1: Devem ser entregues documentos de design que especifiquem a arquitetura e o design detalhado do software • Exemplo 2: O código desenvolvido e entregue deve ser compatível com o produto do design de software

18. Requisitos não funcionais • Portabilidade • Capacidade de um produto ser transferido de um ambiente para outro • Exemplo 1: O sistema deve executar sem perda de funcionalidades em ambiente Linux e Windows, utilizando-se o navegador Firefox versão 3.0 ou superior • Exemplo 2: O servidor que executará a aplicação deverá tem pelo menos 1GB de memória RAM e processador compatível com Pentium V, com um servidor de aplicação Java e um Sistema de Gerenciamento de Banco de Dados devidamente instalados e configurados • Exemplo 3:A interface gráfica para o ambiente de mesa de trabalho poderá ser executada em máquinas com, no mínimo, 512 MB de memória RAM

19. Atividade Adequação dos requisitos não funcionais ao contexto do seu projeto

20. Casos de uso expandido • Detalha as ações dos usuários no sistema em forma de sequencia de interações dos atores com o sistema • É criado um caso de uso expandido “para cada” funcionalidade do sistema que está presente no diagrama de casos de uso • Pode utilizar protótipos de tela para facilitar o entendimento do usuário

21. Casos de uso expandido • Elementos do cabeçalho • Nome do caso de uso com um identificador único (UC1, UC2, UC3...) • Descrição breve sobre o caso de uso • Ator(es) envolvidos no caso de uso • Pré-condições para realização do caso de uso • Pós-condições que representa o estado do sistema após a realização do caso de uso

22. Casos de uso expandido • Fluxo principal • Descrição numerada da sequencia de passos que o ator irá executar durante a realização do caso de uso • 1... • 2... • 3... • 4...

23. Casos de uso expandido • Fluxo alternativo • Ações que ocorrem dentro do sistema, mas que não correspondem ao fluxo “normal” que o usuário esperava • Faz referência ao passo que o fluxo alternativo acontece • 4... no passo 4 o sistema faz XPTO • Observações • Informações complementares que podem auxiliar no entendimento do caso de uso

24. Casos de uso expandido – exemplo • Processo de autenticação em um sistema web em que é exigido nome de usuário e senha para ter acesso às funcionalidades internas da aplicação • A) a única página do sistema que usuário tem acesso aberto (isto é: sem estar autenticado) é a página que apresenta o formulário de autenticação. • B) o sistema deve registrar um log de acesso a cada entrada (log-in) e saída (log-out) do sistema em que as seguintes informações serão armazenadas: nome do usuário, data/hora do log-in ou log-out, IP da máquina e operação realizada (log-in ou log-out). • C) a seguinte funcionalidade deverá estar presente na sua descrição de caso de uso (seja no fluxo principal ou no fluxo alternativo): “Quando o ator ficar sem realizar ações no sistema por 20 minutos, seu log-out será feito automaticamente”.

25. Atividade Fazer um exemplo no quadro (turma toda) Cada um deve fazer um caso de uso do seu projeto

26. Tópicos de revisão • Engenharia de software, SWEBOK e a relação com Técnicas e Projeto de Sistemas • Objetivos da Engenharia de Software • Por que se preocupar com o processo de desenvolvimento de software? • Características do produto de software • O que é sistema? Software é um sistema? • Hierarquia de sistemas e relações entre sistemas • Sistemas organizacionais

27. Tópicos de revisão • Ciclo de vida de software (definição, vantagens e desvantagens) • Ciclo de vida clássico • Incremental • Prototipação • Espiral • Técnicas de quarta geração • Processo de software • Como se define um processo?

28. Tópicos de revisão • Engenharia de requisitos • Definição e objetivo • Tipos de requisitos • Processo de requisitos • Elicitação • Análise • Especificação • Validação

29. Tópicos de revisão • UML • Definição e objetivo • Diagrama de casos de uso • Definição, objetivo, interpretação e elaboração • Requisitos funcionais • Definição e elaboração • Requisitos não funcionais • Definição e elaboração • Casos de uso expandido • Definição, objetivo, interpretação e elaboração