Técnicas e Projeto de Sistemas

Apresentação em tema: "Técnicas e Projeto de Sistemas"— Transcrição da apresentação:

1 Técnicas e Projeto de Sistemas
André Mesquita Rincon Técnicas e Projeto de Sistemas 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 Unified Modeling Language (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 Visão geral de UML Diagrama de classes Diagrama de objetos
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 Relacionamento Entre um ator de um caso de uso Entre atores
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 Relacionamento Entre casos de uso 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 Exemplo de diagrama de caso de uso
Casos de uso Exemplo de diagrama de caso de uso

11 Estudo de caso: ferramenta de EAD (web)
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 Podem constituir restrições aos requisitos funcionais
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 como base para especificação dos requisitos não funcionais Confiabilidade Usabilidade Eficiência Manutenibilidade Portabilidade

14 Confiabilidade Requisitos não funcionais
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 Manutenibilidade Capacidade do produto de ser modificado
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 Portabilidade Requisitos não funcionais
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 Elementos do cabeçalho
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 Fluxo alternativo Observações
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 Objetivos da Engenharia de Software
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 Ciclo de vida de software (definição, vantagens e desvantagens)
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 Engenharia de requisitos
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 Diagrama de casos de uso
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 Casos de uso expandido