Modelação

1. Modelação Aula T02 – Modelação Conceptual Universo do Discurso e Casos de Uso Referências: Conceptual Modeling of Information Systems (Capítulos 1 e 15) UML, Metodologias e Ferramentas CASE (Capítulos 1, 2 e 5) José Borbinha

2. Programa (Aulas Teóricas) T01-T02 (2 aulas) – Módulo 1 • Introdução à Modelação de Sistemas T03-T06 (4 aulas) – Módulo 2 • Modelação Conceptual: Domínio T07-T11 (5 aulas) – Módulo 3 • Modelação Conceptual: Comportamento T12-T15 (4 aulas) – Módulo 4 • Ontologias T16-T19 (4 aulas) – Módulo 5 • Modelação Conceptual: Arquitectura T20-T21 (2 aulas) – Módulo 6 • Modelação Conceptual: Metodologias T22-T23 (2 aulas) – Módulo 7 • Ontologias: Temas avançados T24-T25 (2 aulas) • Modelação Conceptual: revisões e exercícios Modelação

3. ...Sistema?... • Uma definição de sistema: um conjunto entidades que interagem entre si com o objectivo de atingir um determinado objectivo. • Regra geral o objectivo de um sistema é a sua sobrevivência, o que pode ser levado à letra no caso dos sistemas biológicos, mas também em qualquer outro contexto (um sistema solar é sistema enquanto conseguir manter o seu equilíbrio, tal como uma organização, uma máquina, ...) • Um “sistema de informação” pode ser assim definido como: • um conjunto de entidades (humanas e tecnológicas) interagindo entre si com o objectivo de satisfazer adequadamente as necessidades de informação de uma organização e respectivos processos de negócio! Modelação

4. Sobre Modelação e Eng.ª de Software • Engenharia de Softwareé a aplicação de um processo sistemático, disciplinado, e quantificado ao desenvolvimento, operação e manutenção de software; ou seja, a aplicação de técnicas de engenharia ao software (IEEE, 93) • As actividades da Eng.ª de Software podem ser agrupadas em três grandes fases: concepção, implementação e manutenção • A concepção de um sistema é efectuada sobre os requisitos, os quais por sua vez derivam dos objectivos de negócio. É nesta fase que a modelação é especial importante. • Após a concepção de um sistema procede-se então à concepção do software (na concepção da Eng.ª de Software) Modelação

5. Sobre Eng.ª de SW e processo de desenvolvimento de sistemas • Concepção do Sistema • Especificação de Requisitos: descrição do problema na óptica do cliente. • Análise: descrição do problema na óptica do engenheiro de sistema • Desenho: especificação da soluçãoem termos da plataforma e tecnologia computacional usada. • Desenvolvimento e Manutenção do Sistema • Concretização da solução desenhada... • Testes ... • Aceitação ... • Manutenção ... Modelação

6. Universo do Discurso Modelação

7. Modelação Conceptual !!! • “Na área de sistemas de informação usamos o termo Modelação Conceptual para a actividade de descoberta e descrição do conhecimento geral que um determinado sistema de informação necessita ter” (Conceptual Modeling of Information Systems, pag. xi) • Nota de tradução importante • “elicit” ≈ deduzir, descobrir, obter gradualmente • “elicit” ≠ licitar !!! Modelação

8. De volta à definição de sistema Um sistema tem três funções principais: • Memória: manter a representação do estado de um domínio • Informar: dar informação (ao exterior) sobre o estado de um domínio • Actuar: agir para mudar o estado de um domínio (Conceptual Modeling of Information Systems, pag. 3) Modelação

9. Domínio ??? • Um domínio é o fragmento do mundo real sobre o qual é focada a tarefa de modelação e construção de um sistema. • Exemplos de domínios: • Sistema bancário nacional • Sistema universitário nacional • O futebol • ... • Geralmente ao domínio também se dá o nome de universo do discurso (UoD = “Universe of Discourse”) Modelação

10. Domínio / UoD • Na área de sistemas de informação assumimos que um domínio consiste num número de objectos e de relações entre eles, que são classificadas em conceitos. O estado de um dado domínio, num dado momento, consiste assim num grupo de objectos, num grupo de relações, e num conjunto de conceitos segundo os quais esses objectos e relações são classificados. (Conceptual Modeling of Information Systems, pag. 10) • Classificação é o processo que associa um objecto do domínio a um conceito do domínio. Modelação

11. Conceitos • Um conceito é algo que concebemos no nosso entendimento através da generalização de certas instâncias. • Um conceito tem intenção e extensão: • Intenção são as propriedades partilhadas por todas as instâncias • Extensão são todas as possíveis instâncias desse conceito (Conceptual Modeling of Information Systems, pag. 12) Modelação

12. Esquemas Conceptuais • A especificação do conjunto de conceitos de um domínio é o esquema conceptual desse domínio • Para um mesmo domínio podemos definir mais que um esquema conceptual, dependendo da perspectiva e dos objectivos... Modelação

13. Esquemas Conceptuais mais em detalhe • O modelo de um domínio do sistema, ou base de informação*, são as entidades e relações desse domínio (conceito a desenvolver nas próximas aulas...) *Termo usado em “Conceptual Modeling of Information Systems” • A descrição do modelo de domínio de um sistema é o esquema estrutural desse sistema. • O esquema de comportamento especifica as acções válidas e as mudanças no estado do domínio que o sistema pode executar (a desenvolver mais adiante no semestre...) • Ao conjunto formado pelo esquema estrutural e pelo esquema de comportamento de um sistema dá-se o nome de esquema conceptual. Modelação

14. De volta ao Sistema • Para poder cumprir as suas funções Memória, Informar e Actuar, um sistema necessita de ter conhecimento do seu domínio e das funções que tem de executar. • Isto é, temos de definir o estado que o sistema deve representar e as suas regras de consistência de representação (função Memória) e as mudanças potenciais de ocorrer nesse estado (função Actuar). Finalmente, temos ainda de garantir ao sistema capacidade de inferência sobre o seu estado (função Informar). Modelação

15. Modelos • Um modelo é uma interpretação de um sistema segundo um determinado ponto de vista, envolvendo a sua especificação a um certo nível de abstracção e de detalhe. • Linguagem de Modelação • É a estruturação e especificação da estrutura de conceitos segundo uma ou mais linguagens. • Linguagens podem ser formais ou informais, textuais ou gráficas. • No caso de linguagens de modelação gráficas, a notação consiste na apresentação visual dos diferentes elementos da estrutura de conceitos subjacente. Modelação

16. Esquemas • Um esquema é a especificação de um modelo usando uma determinada linguagem, a qual pode ser formal, informal (e.g., linguagem natural); de texto, gráfica, ... • Quando a representação do esquema é gráfica designa-se usualmente por diagrama. Modelação

17. Casos de Uso Modelação

18. Casos de Uso • Relembrando: • Ao conjunto formado pelo esquema estrutural e pelo esquema de comportamento de um sistema dá-se o nome de esquema conceptual • Por outras palavras, um esquema conceptual define o conhecimento geral que um sistema precisa para executar as suas funções. • Mas quais são essas funções e qual é o conhecimento requeridos para as executar? • Essa informação é representada, ao mais alto nível, por casos de uso (“use cases”). Modelação

19. Casos de Usos • Um caso se uso representa um conjunto de acções que um ou mais actores realizam num sistema para obter um resultado concreto • Um caso de uso representa uma visão externa do sistema • descreve o que faz um sistema (ou parte deste), • não descreve como é que tal é realizado Modelação

20. Casos de Uso • Um caso de uso deve ser representado num modo impessoal, por uma frase na voz activa, com um verbo no infinitivo (“Gerar relatórios”, “Criar factura”, “Calibrar roda”) Modelação

21. Administrador Alarme Cliente Actores • Um Actor representa uma papel (“role”) que um utilizador pode desempenhar relativamente ao sistema a modelar. • Um mesmo utilizador nominal pode desempenhar diferentes papéis, podendo, por conseguinte, representar conceptualmente diferentes actores (desempenhar vários “roles”). • Um actor de um sistema pode ser um ser humano ou outro sistema! Modelação

22. Diagramas de Casos de Uso • Um diagrama de casos de uso ilustra um conjunto de Casos de Uso, de Actores, e as suas Relações, com objectivos de • Modelação do contexto de um sistema, com ênfase na identificação da fronteira do sistema, dos seus actores e no significado das suas funções. • Modelação dos requisitos de um sistema, consistindo na identificação do que o sistema deve fazer e independentemente de como o sistema o deve realizar. Modelação

23. Actor Actor Actor Diagramas de Caso de Uso • Um diagrama de Casos de Utilização é utilizado para ilustrar a interacção entre os actores e os casos de utilização pelo envio recíproco de “estímulos”. • Uma associação de comunicação entre um actor e um caso de utilização implica uma interacção entre ambos. • Cada função nesta associação tem uma propriedade de navegação, que indica a direcção da comunicação. • Se for bidireccional, omite-se a representação da direcção. Use Case A Use Case A Use Case A Modelação

24. Casos de uso e Cenários • Um cenário é uma instância de um caso de uso quando este interactua com os actores. Representa assim uma sequência de acções concreta que ilustra um comportamento do sistema. • É normal que um caso de uso possa ser descrito por vários cenários • Tipos de cenários: • Principal: descreve a sequência normal de acções (“happy day scenario”) • Alternativo ou secundário: descreve uma sequência de acções a considerar para além da principal, o que pode acontecer devido a excepções ou apenas para outras acções possíveis Modelação

25. Casos de uso e Cenários - Exemplos • Cenários secundários do caso de uso “Fazer encomenda” • Informação do cartão de crédito incorrecta • Pedido incompleto • Cliente pretende pagar por cheque • Cliente requer atendimento especial • Endereço de entrega incompleto • Produto já não comercializado • Produto não existe em armazém • Produto em promoção Cenário principal do caso de uso “Fazer encomenda” • O caso inicia-se quando o cliente selecciona “Fazer encomenda” • O cliente introduz nome e endereço • O cliente introduz códigos dos produtos desejados • O sistema fornece descrição e preço dos produtos • O cliente selecciona os produtos desejados • O cliente fornece informação do cartão de crédito • O cliente submete o pedido • O sistema verifica a informação • Quando o pagamento é confirmado é criado e apresentado ao cliente um código de encomenda. Caso termina Modelação

26. Casos de Uso: Descrição Textual • Pode-se especificar um caso de uso descrevendo textualmente o fluxo de eventos, de modo a que qualquer pessoa o possa entender. • Tal especificação deve incluir: • Assunções • Pré-condições • Inicialização: como e quando o caso de utilização começa • Diálogo: quando é que o caso de utilização interactua com os actores • Conclusão: como e quando o caso de utilização termina • Pós-condições • Para estas descrições deve usar-se “templates” Modelação

27. Casos de Uso: Exemplo de uma ”template” Modelação

28. Casos de Uso - Inclusão • A relação de inclusão entre casos de uso corresponde a uma relação típica de delegação, significando que o caso base incorpora o comportamento do outro caso relacionado. • Usa-se a relação de inclusão para evitar descreverem-se os mesmos fluxos de eventos inúmeras vezes… (reutilização) Modelação

29. Atribui lugar à janela «extend» Atribui lugar Casos de Uso - Extensão • Numa relação de extensão o caso base incorpora implicitamente o seu comportamento num local especificado indirectamente pelo caso que o usa. Ou seja, um caso destino pode ser estendido com o comportamento de outros casos. • Uma relação de extensão permite representar: • A parte de um caso que um actor vê como opcional, ou como existindo várias alternativas. • Um sub-fluxo de acções que é executado apenas se determinadas condições se verificarem. • Vários fluxos de acções que podem ser inseridos num determinado ponto de extensão, de forma controlada, através de uma interacção explícita com um actor. • O caso de uso de base é estendido num ou mais pontos, designados por “pontos de extensão”. Modelação

30. Agente do Fornecedor Colector Cliente Dono Diagramas de Caso de Uso - Exemplo A Máquina de Bebidas Comprar Bebida Repor Bebidas Retirar dinheiro Modelação

31. A Máquina de Bebidas Comprar Bebida Repor bebidas «include» Abrir a Máquina «include» «include» Retirar dinheiro Agente do Fornecedor Colector Cliente Dono Fechar a Máquina «include» Diagramas de Caso de Uso – Exemplo com Inclusão Modelação

32. Dono Diagramas de Caso de Uso – Exemplo com Extensão • Representa-se agora a possibilidade da reposição de bebidas na máquina depender de um algoritmo considerando as marcas e número de unidades vendidas... A Máquina de Bebidas Abrir a Máquina «include» Repor Bebidas Agente do Fornecedor Extension Point encher prateleiras «include» «extend» (encher prateleiras) Fechar a Máquina Repor Bebidas segundo as vendas Modelação