Modelação Aula T07 Modelação Conceptual - ppt carregar
Modelação Aula T07 Modelação Conceptual
PublicouGabrielly Leite Alterado mais de 3 anos atrás
Apresentação em tema: "Modelação Aula T07 Modelação Conceptual"— Transcrição da apresentação:
1 Modelação Aula T07 Modelação Conceptual
Modelos Estrutural – Instâncias e Objectos Revisão geral do Módulo... José Borbinha
2 Programa Modelação Conceptual de Sistemas T07
T01-T03 – Módulo 1 Introdução à Modelação de Sistemas T04-T07 – Módulo 2 Modelação Conceptual de Sistemas T07 Modelo Estrutural Instâncias e Objectos Revisão Geral T08-T11 – Módulo 3 Ontologias T12-T15 – Módulo 4 Modelação de Sistemas: Dinâmica T16-T18 – Módulo 5 Modelação de Sistemas: Arquitectura T19-T25 – Módulo 6 Temas avançados Modelação
3 Instâncias e Objectos Modelação
4 Instâncias Uma instância é uma manifestação concreta de um conceito
Uma instância tem um estado, que pode ser alterado por operações Exemplos: uma instância de uma classe é um objecto uma instância de uma associação é uma ligação (link) uma instância de um nó é um computador em concreto uma instância de um caso de uso (use case) é um cenário Modelação
5 Objectos Uma instância de uma classe é um objecto
Um objecto incorpora os atributos e métodos definidos na sua classe Sintaxe do nome de um objecto em UML: Nome-do-objecto : Nome-da-classe Nome da Instância Maria:Pessoa F :Factura Classe Modelação
6 Objectos O conjunto de valores dos atributos de um objecto num dado instante definem o seu estado nesse instante O estado de um objecto pode ser, variando ao longo do tempo à medida que o objecto interactua com outros objectos F :Factura Valor = 897€ Entidade: Jaime Correia SA F :Factura Valor = 300€ Entidade: Santos e Silva SA Modelação
7 Objectos Compostos Um objecto composto é constituído por outros (sub)objectos. Em geral tal reflecte relações de agregação entre as respectivas classes. No entanto representar um conjunto relacionado (por agregação) de objectos através de um objecto composto pode trazer clareza e simplicidade aos diagramas my:Empresa my:Empresa d-fin:Departamento d-fin:Departamento d-ven:Departamento  d-ven:Departamento d-pro:Departamento d-pro:Departamento Objecto composto Modelação
8 Diagramas de Objectos Um diagrama de objectos ilustra um conjunto de objectos e respectivas relações num determinado momento Um diagrama de objectos permite captar uma imagem ou fotografia momentânea sobre determinado sistema Nota: Regra geral um diagrama de objectos não pretende especificar completamente a estrutura de objectos de um dado sistema, pois para cada classe há quase sempre um grande número de combinações potenciais entre instâncias. Desta forma o objectivo dos diagramas de objectos é apenas expor conjuntos relevantes de objectos de modo a melhor se entender as suas funcionalidades e relações. Modelação
9 Diagramas de Objectos Veículo Motor Pessoa Exemplo:
Uma pessoa pode ser proprietário de vários veículos e estes são possuídos apenas por uma única pessoa. Um veículo tem de possuir necessariamente um motor. Um veículo é identificado univocamente pela matrícula e possuí ainda outras informações, tais como a cor, data de fabrico, marca e modelo. Um motor é identificado por um número de motor, tipo de combustível e cilindrada Veículo modelo matricula cor Motor número cilindrada combustível Pessoa 0..1 * 0..1 1 Modelação
10 Diagramas de Objectos Uma pessoa pode ser proprietário de vários veículos e estes são possuídos apenas por uma única pessoa. Um veículo tem de possuir necessariamente um motor. Um veículo é identificado univocamente pela matrícula e possuí ainda outras informações, tais como a cor, data de fabrico, marca e modelo. Um motor é identificado por um número de motor, tipo de combustível e cilindrada Veículo modelo matricula cor Motor número cilindrada combustível Pessoa 0..1 * 0..1 1 O Zé Maria é dono de um Audi A3 TDi vermelho, com matricula '99-99-MM', que tem um motor 1900cc, com número '9999' ZéMaria:Pessoa nome="Zé Maria" AudiA3:Veiculo modelo=A3 TDi matricula=99-99-MM cor=vermelho :Motor número=9999 cilindrada=1900cc combustível=gasóleo tem Modelação
11 Um diagrama de objectos bem estruturado
Tem um foco num determinado aspecto da visão de modelação do sistema É pragmático: contém apenas os elementos que são essenciais à compreensão de determinado aspecto É consistente: providencia detalhes de forma consistente com o seu nível de abstracção Modelação
12 Resumo do Módulo Modelação
13 Contexto: Modelação e desenvolvimento de sistemas
14 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
15 Uma definição de sistema
16 Domínio / UoD 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
17 Conceitos Um conceito é algo que concebemos no nosso entendimento através da generalização de certas instâncias. (Conceptual Modeling of Information Systems, pag. 12) 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
18 Esquemas Conceptuais 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. A descrição do modelo de domínio de um sistema é o seu esquema estrutural. O esquema de comportamento especifica as acções válidas e as mudanças no estado do domínio que o sistema pode executar. O esquema estrutural e o esquema de comportamento de um sistema compõem um esquema conceptual. 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 deve ser representado num modo impessoal, por uma frase na voz activa, com um verbo no infinitivo ("Gerar relatórios", "Criar factura", "Calibrar roda"). 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 e Cenários Um cenário é uma instância de um caso de uso quando este interactua com os actores. É 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
21 Casos de Uso: Exemplo de uma "template"
22 Casos de Uso - Generalização
Uma relação de generalização entre casos de utilização permite definir casos à custa de outros já existentes, pelo mecanismo de especialização, ou alternativamente, permite definir casos mais abstractos a partir de casos concretos pelo mecanismo da redução ou generalização Modelação
23 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
24 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. O caso de uso de base é estendido num ou mais pontos, designados por "pontos de extensão". Atribui lugar à janela «extend» Modelação
25 Engenharia de Requisitos
Um requisito especifica algo que um sistema deve fazer. Engenharia de requisitos é o processo (conjunto estruturado de actividades) que envolve um levantamento de requisitos Requisitos funcionais (RF) especificam as acções que o sistema deve suportar Requisitos não funcionais (RNF) impõem condições ou restrições sobre o sistema Modelação
26 Processo Geral de Engenharia de Requisitos
Objectivos de negócio Necessidades dos utilizadores Informação sobre o domínio Informação sobre os sistemas existentes Normas, leis e regulamentos a cumprir .., Identificação de requisitos ("elicitation") Análise de Requisitos e Negociação Documentação dos Requisitos Validação dos Requisitos Documento de Requisitos Especificação do Sistema... Modelação
27 Técnicas de levantamento de requisitos
Questionários Análise de documentos Entrevistas JAD - Joint Application Design Etnografia Prototipagem Casos de Uso (de novo...) Modelação
28 Análise e Negociação de Requisitos
O objectivo da análise é encontrar problemas, falhas e inconsistências. A análise deve ser intercalada com o levantamento de requisitos e suportada por uma lista de verificação de problemas A negociação de requisitos tenta encontrar soluções de concordância. Pode ser um processo demorado, pois obriga a consensos Modelação
29 Modelação da Estrutura
Uma classe providencia uma abstracção definida a partir do vocabulário do domínio do sistema Uma classe agrega um conjunto restrito e bem definido de propriedades Diagramas de classes representam o modelo de domínio (a visão lógica) do sistema, expressa pelo conjunto de todas as suas classes e respectivas relações. Modelação
30 Uma instância é uma manifestação concreta de um conceito
Instâncias e Objectos Uma instância é uma manifestação concreta de um conceito Uma instância tem um estado, que pode ser alterado por operações Uma instância de uma classe é um objecto Um objecto incorpora os atributos e métodos definidos na sua classe Modelação