Engenharia de Software

Apresentação em tema: "Engenharia de Software"— 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
Gestores Utilizadores Finais Engenheiros Fornecedores Arquitectos Requisitos dos utilizadores Utilizadores Finais Engenheiros Arquitectos Programadores Requisitos do Sistema

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
Sistema ??? Efectuar chamada Rede Receber chamada Utilizador ou Actor Usar a agenda

8 Casos de uso - Actores Actor 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 Actor
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 Actor

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

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 (<<uses>>) – comportamento idêntico em vários casos de uso; Herança (<<extend>>) – quase igual, mas com alguma diferença; Incluído (<<include>>) - 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 Registo Registar Formação
<<extend>> Registo <<extend>> Registar Formação

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

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

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
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)