A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro.

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro."— Transcrição da apresentação:

1 Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro

2 An á lise de Requisitos Requisitos Funcionais – servi ç o que é necess á rio prestar, reac ç ão do sistema perante um determinado input, comportamento do sistema em determinadas situa ç ões ou o que é que o sistema não deve fazer; Requisitos não funcionais – constrangimentos nos servi ç os ou funcionalidades oferecidas (como tempo, processo de desenvolvimento ou standards); Requisitos de dom í nio – resultam do dom í nio aplicacional do sistema, reflectindo caracter í sticas e constrangimentos inerentes a esse dom í nio. Podem ser funcionais ou não funcionais.

3 Leitura dos diferentes tipos de especifica ç ões Requisitos dos utilizadores Requisitos dos utilizadores Gestores Utilizadores Finais Engenheiros Fornecedores Arquitectos Gestores Utilizadores Finais Engenheiros Fornecedores Arquitectos Requisitos do Sistema Requisitos do Sistema Utilizadores Finais Engenheiros Arquitectos Programadores Utilizadores Finais Engenheiros Arquitectos Programadores

4 Requisitos não funcionais Requisitos do produto – tempos de execu ç ão de transac ç ões; taxas de falha; usabilidade; Requisitos organizacionais – resultam de pol í ticas e procedimentos da organiza ç ão, tais como linguagens a utilizar ou especifica ç ão de quando se farão as entregas de produtos e documenta ç ão; Requisitos externos – como requisitos legais, interac ç ão com outros sistemas, requisitos é ticos, etc.

5 An á lise de Requisitos Funcionais Captura as inten ç ões e necessidades dos utilizadores do sistema atrav é s do recurso a "use-cases". Os "use-case", permitem modelar as entidades externas ao sistema (em UML chamados de "actores externos") que interagem e possuem interesse no sistema identificando as fun ç ões que são requeridas. Os actores externos e os "use-cases" são modelados atrav é s de relacionamentos que possuem comunica ç ão associativa entre eles ou são desmembrados em hierarquia. Cada "use-case" modelado é descrito atrav é s de um texto, que especifica os requisitos do actor externo que utilizar á este "use-case". O diagrama de "use-cases" mostrar á o que os actores externos, ou seja, os utilizadores do futuro sistema deverão esperar do sistema, conhecendo toda a sua funcionalidade sem preocupa ç ão sobre a forma como esta ser á implementada. A an á lise de requisitos tamb é m pode ser desenvolvida baseada em processos de neg ó cios, e não apenas para sistemas de software.

6 Casos de uso (Use Cases) Avaliar de acordo com as perspectivas: –Casos de utiliza ç ão para que serve o sistema (utilidade) num v í deo-gravador: reproduzir cassete, gravar cassete nem sempre evidente a partir da observa ç ão do interface! um caso de utiliza ç ão engloba uma sequência de interac ç ões com elementos da interface, para atingir resultado ú til (produto ou servi ç o) para o utilizador! –Interface sistema como caixa preta o que é vis í vel na fronteira do sistema (estrutura e funcionamento) num v í deo-gravador: teclas, visor, abertura para cassete, tomadas –Implementa ç ão sistema como caixa branca acrescenta o que est á escondido (estrutura e funcionamento) num v í deo-gravador: motor, cabe ç as de grava ç ão, sintonizador,...

7 Casos de uso - Exerc í cio Usar a agenda Receber chamada Utilizador ou Actor Efectuar chamada Rede Sistema ???

8 Casos de uso - Actores Actor = papel ( role ) – Um actor em rela ç ão a um sistema é um papel que algu é m ou alguma coisa do ambiente envolvente desempenha quando interage com o sistema Actor = classe –classes são frequentemente usadas para modelar pap é is que objectos individuais podem desempenhar Actor = tipo de utilizador (em sentido lato) –pode ser uma pessoa ou outro sistema –pode utilizar ou ser utilizado, o que interessa é que interage com o sistema Actor recurso do sistema –recursos são pessoas, m á quinas, etc. que pertencem ao sistema e que são usados para levar a cabo tarefas dentro do sistema Actor indiv í duo –o mesmo indiv í duo pode interagir com o sistema em v á rios pap é is (como cliente, como fornecedor, etc.) Actor

9 Casos de uso - Actores Cada actor deve comunicar com pelo menos 1 caso de uso. São humanos, não humanos, activos, passivos. Questões para identificar actores: –Quem utiliza o sistema? –Quem est á interessado nos resultados do sistema? –Quem é respons á vel pela administra ç ão do sistema? –Com que sistemas comunica este? –Quem fornece informa ç ão ao sistema? –Quem vai usar o sistema, para a realiza ç ão de tarefas –Quem utiliza o sistema? Actor

10 Casos de uso - Exerc í cio Cliente Servir almoço Fornecedor Restaurante (negócio) Servir jantar Comprar bens

11 Casos de uso - Exerc í cio Empregado de mesa Registar pedido Restaurante (Gestão) Emitir factura Cozinheiro

12 Casos de uso Defini ç ão: descri ç ão de um conjunto de sequências de ac ç ões (1), incluindo variantes (2), que um sistema realiza (3) para produzir um resultado observ á vel com valor para um actor (4,5) (1) a defini ç ão d á ênfase à sequência (modo) de funcionamento, mas este detalhe s ó surge numa 2 ª itera ç ão, depois de se ter alguma ideia do interface do sistema (2) a sequência concreta de ac ç ões pode variar de instância para instância do caso de utiliza ç ão (3) interessam-nos mais as ac ç ões do sistema, pois são essas que temos de implementar, mas tamb é m interessa descrever as ac ç ões do actor (4) é esta utilidade ou objectivo que importa descrever numa 1 ª itera ç ão (5) o resultado pode ser um produto, um servi ç o, etc. Mais simplesmente, um caso de utiliza ç ão é : –uma funcionalidade do sistema vista pelos utilizadores –um tipo de interac ç ão (de alto n í vel) entre actores e o sistema

13 Casos de uso A identifica ç ão de casos de uso é feita atrav é s da recolha e an á lise dos requisitos do utilizador Pensar em cada actor e nas interac ç ões que tem com o sistema Um caso de uso agrupa interac ç ões elementares de actores com elementos da interface do sistema, mas qual deve ser o n í vel de agrupamento? –Exemplos: dar informa ç ão sobre produto, fazer encomenda, cancelar encomenda, levantar dinheiro. Questões p/ identificar use cases: –Que fun ç ões um actor vai querer do sistema? –O sistema armazena informa ç ão? –O sistema necessita de notificar um actor sobre mudan ç as no seu estado interno?

14 Casos de uso Caso de utiliza ç ão simples : utiliza ç ão de funcionalidade de grão mais fino poss í vel que, uma vez implementada, acrescenta valor (do ponto de vista dos utilizadores) ao sistema que est á a ser desenvolvido –Exemplo no multibanco: "introduzir cartão" não é um caso de utiliza ç ão porque não tem valor isoladamente "levantar dinheiro" é um caso de utiliza ç ão porque tem valor para o detentor do cartão –O caso de utiliza ç ão inclui todas as ac ç ões a montante (de prepara ç ão) e a jusante (de finaliza ç ão) necess á rias (numa rela ç ão de um para um) à produ ç ão do resultado Levantamento no multibanco, vai desde a introdu ç ão do cartão at é à recolha do cartão, do talão e do dinheiro Caso de utiliza ç ão composto : combina ç ão de casos de utiliza ç ão mais simples –modelar apenas quando importa automatizar

15 Casos de Uso - Rela ç ões Associa ç ão – rela ç ão b á sica e representa a interac ç ão entre o actor e o caso de uso; Dependência – Rela ç ão entre classes, a qual pode ser do tipo: –Uso ( >) – comportamento idêntico em v á rios casos de uso; –Heran ç a ( >) – quase igual, mas com alguma diferen ç a; –Inclu í do ( >) - v á rios casos de utiliza ç ão têm uma sub- sequência de funcionamento comum. É conveniente separar essa parte comum para um novo caso de utiliza ç ão que é inclu í do pelos primeiros

16 Casos de uso - Rela ç ões Registar Curso Registar Formação Registo >

17 Casos de uso - Rela ç ões Registar Curso Actualizar estrutura curricular Autorização >

18 Casos de uso - Rela ç ões Servir Almoço Servir Jantar Pagar Refeição >

19 Casos de uso - Cen á rios Um cen á rio consiste numa sequência de passos ou ac ç ões, dos muitos poss í veis na execu ç ão de um Caso de Uso, que serve para atingir um determinado objectivo.Como em geral existe mais de uma forma de execu ç ão de um Caso de Uso, é conveniente registar todos os poss í veis cen á rios de execu ç ão. O cen á rio descreve-se quando o caso de uso interactua com os actores Tipos de cen á rio: – Principal : descreve a situa ç ão quando tudo corre bem (happy day scenario) – Alternativo ou secund á rio : permite uma sequência diferente de eventos em rela ç ão ao cen á rio principal (e.g. Execu ç ões ou outras ac ç ões poss í veis)

20 Casos de uso 3 n í veis de detalhe, de acordo com as 3 perspectivas de um sistema 1 º ) essência / utilidade –descri ç ão breve independente da interface que o sistema apresenta –descrever o objectivo ou resultado a produzir –opcionalmente, indicar lista de features e limita ç ões (n í vel de requisitos) 2 º ) interface –descri ç ão de sequências de funcionamento normais e excepcionais, em termos de interac ç ões dos actores com elementos da interface –opcionalmente, acompanhar de desenhos da interface para o utilizador e de diagramas dinâmicos –indicar quando é que o caso de utiliza ç ão come ç a e acaba, quando ocorrem interac ç ões com os actores, que objectos são trocados, quem faz o quê (o sistema ou um actor) –pode culminar no manual do utilizador 3 º ) implementa ç ão –realiza ç ão do caso de utiliza ç ão por uma colabora ç ão de objectos internos ao sistema –sequências de funcionamento detalhadas com (inter)ac ç ões internas ao sistema –j á não compete ao analista, mais sim ao projectista/implementador –j á não faz parte do modelo de casos de utiliza ç ão, mas sim do modelo de design

21 Conclusões Os Casos de Uso são ú teis para apoiar o processo de engenharia de requisitos, desta a fase de an á lise at é ao planeamento de projectos. Os Casos de Uso pretender representar potenciais requisitos do sistema como requisitos das entidades externas que interagem com o sistema.

22 Recomenda ç ões e Regras de Estilo Recomenda ç ões: –Devemos considerar a comunica ç ão com o sistema. –Deve conter apenas os casos de uso e os actores que são essenciais para compreender a dita comunica ç ão. –É aconselh á vel come ç ar por um conjunto não exaustivo de casos de uso. Regras de Estilo –Utilizar nomes representativos –Evitar as linhas cruzadas –Num s ó diagrama determinar o grau de granularidade.

23 Casos de uso - Exerc í cio Descrever o caso de uso – servir almo ç o: –Objectivo –Funcionalidade e Limita ç ões –Sequência normal de funcionamento –Sequência excepcional de funcionamento

24 Casos de uso- Exerc í cio M á quina de Dep ó sito de vasilhame –Pretende-se: Registar o n ú mero de produtos introduzidos; Imprimir recibo apenas se solicitado; Descrever o(s) produto(s); Identificar o valor do vasilhame do produto; Calcular o total do valor do dep ó sito –Utilizador inicia o processo pressionando o botão Iniciar; –O utilizador tem como requisito obter o recibo com o valor do dep ó sito; –O Operador deve ter a seguinte informa ç ão: Quantos produtos foram recebidos / dia; Relat ó rio final di á rio; –O Operador pode alterar informa ç ão de: Produtos; Avisos do sistema; Invalidade do produto; Inexistência de papel de recibo.

25 Casos de uso - Exerc í cio Sistema de Informa ç ão de uma Biblioteca Objectivo Pretende-se projectar o Sistema de Informa ç ão de uma Biblioteca (SIB), para apoiar as seguintes actividades: –gestão de aquisi ç ões de publica ç ões –registar a aquisi ç ão –gestão de consultas e fotoc ó pias de publica ç ões dentro da biblioteca –interessa contar o n º de vezes que cada publica ç ão foi consultada –consulta da base de dados de publica ç ões (p ú blico e empregados) –gestão de s ó cios –inscri ç ão, renova ç ão, cancelamento –gestão de requisi ç ões –s ó os s ó cios podem requisitar publica ç ões –requisi ç ão com levantamento, devolu ç ão

26 Casos de uso - Exerc í cio Estudar o sistema de funcionamento de uma m á quina Multibanco

27 Casos de uso – Exerc í cio Estudar o sistema de funcionamento da Brisa (Via Verde)


Carregar ppt "Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro."

Apresentações semelhantes


Anúncios Google