Linguagem de Modelagem Unificada UML

Transcrição

1 Linguagem de Modelagem Unificada UML Parte 1 Rosemary Silveira Filgueiras Melo [email protected] 1

2 Tópicos abordados Paradigma Orientado a Objetos Linguagem UML e seus principais diagramas Diagramas de Casos de Uso Diagramas de Classes 2

3 Contextualização Sistemas de Informação cada vez mais complexo Necessidade de planejamento e organização prévio para desenvolver sistemas de informação O uso da modelagem de Sistemas permite pensar, planejar e organizar as soluções antes de implementar o software A modelagem de sistemas está intimamente relacionada ao paradigma de desenvolvimento e ao processo de desenvolvimento em uso. 3

4 Contextualização - continuação O foco do desenvolvimento de sistema sob o paradigma orientado objetos está voltada para identificação e a modelagem dos objetos do mundo real que afetam o sistema. A linguagem UML é mundialmente aceita para modelagem de sistemas baseado no Paradigma Orientado a Objetos. 4

5 Paradigma Orientado a Objetos 5

6 Princípios Fundamentais Objeto Classe Encapsulamento Herança Polimorfismo Visibilidade

7 Objetos Representa as coisas a serem modeladas do mundo real. Pode ser algo concreto ou abstrato Concreto -> Abstrato -> Ex.: aluno, professor, etc Ex.: turma, disciplina, etc

8 Objetos

9 Objetos Objetos tem um estado (atributos) Objetos possuem um comportamento (métodos) Objetos possuem uma identidade

10 Classes Abstração da realidade na qual representamos algo do mundo real. Descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.

11 Objetos x Classes Objeto é uma instância de uma classe Classe é o Molde Objeto é a coisa real CONJUNTO DE PESSOAS

12 Encapsulamento capacidade de ocultar dados de acesso indevido de outros objetos. só permite que estes dados sejam acessados por operações implementadas pelos seus próprios métodos. protege os dados do objeto do uso arbitrário ou não intencional. usuários tem conhecimento das operações que podem ser requisitadas e o que elas realizam não é necessário saber como foram implementadas.

13 Encapsulamento Interação entre objetos sem conhecimento do funcionamento interno.

14 Herança Mecanismo usado para derivar novas classes a partir da definição de classes existentes. Uma classe derivada herda os atributos (dados) e métodos (operações) da classe base ou ancestral. Garante reutilização de código propiciando economia de tempo, dinheiro e mais segurança.

15 Herança

16 Polimorfismo Palavra derivada do grego, significa muitas formas. Possibilidade de ter método com mesmo nome em classes distintas com comportamentos diferente. Se uma classe herda atributos e métodos de uma ou mais classe base ela tem o poder de alterar o comportamento destes métodos.

17 Polimorfismo

18 Visibilidade Define o que uma classe pode visualizar de outra classe. A visibilidade envolve a possibilidade de visualização tanto de atributo, como de método. Tipos de Visibilidade: - Pública: atributos e métodos podem ser visível a todas as classes. - Privada: atributos e métodos só podem ser visível pela própria classe. - Protegida: atributos e métodos visível somente pelas classes descendentes.

19 Visibilidade o atributo Valor e método Pagar_conta da classe Pagamento somente podem ser vistas pelas classes filhas ou subclasses desta classe.

20 Linguagem UML e seus principais diagramas 20

21 UML UML - Unified Modeling Language. Desenvolvida pela Rational Software Rumbaugh Booch Jacobson Reconhecida pela OMG Object Management Group em 1997.

22 Origem da UML Booch Grady Booch OMT James Rumbaugh / General Eletric OOSE Ivar Jacobson / Ericsson UML Rational Software / OMG

23 UML Histórico Nov/97 Set/97 Jan/97 Out/96 UML reconhecida pela OMG e com feedback do público. UML 1.1 UML 1.0 UML 0.9 & 0.91 Parceiros Da UML Industrialização Padronização Jun/96 Unified Method 0.8 Unificação Out/95 Booch 93 OMT-3 Jan/91 Outros Métodos Booch 91 OMT-1 OOSE Framentação 23

24 UML - Características UML não é uma Metodologia UML é uma Linguagem de Modelagem: Não proprietária e aberta Independente da linguagem de programação Independente do processo de desenvolvimento Predominantemente visual e de fácil leitura Apropriada para uso de conceitos OO Abrange desde a modelagem conceitual até a implementação física Composta por diagramas 24

25 UML - Diagramas 25

26 UML Expressividade Através da UML é possível: Explicitar as fronteiras do sistema e suas principais funcionalidades (casos de uso e atores) Ilustrar a realização dos casos de usos (diagramas de interação) Representar as estruturas estáticas do sistema (diagramas de classes) 26

27 UML Expressividade Além disso... Modelar o comportamento dos objetos (diagramas de transição de estados) Mostrar a arquitetura física da implementação ( componentes (diagramas de Capturar a topologia de hardware do sistema (diagrama ( implantação de 27

28 Diagrama de Casos de Uso 28

29 Diagrama de Casos de Uso Apresenta uma visão das principais funções ou serviços oferecidas pelo sistema Considerado o mais abstrato e informal. Utilizado principalmente nas etapas de Levantamento de requisitos e Análise Ajuda na identificação dos requisitos do sistema Ferramenta para troca de informações entre clientes e equipe de desenvolvimento Fornece a base para o planejamento dos testes 29

30 Diagrama de Casos de Uso Visa identificar: o Os usuários que irão interagir com o sistema o Os papéis que eles irão assumir o As funcionalidades que serão requisitadas por cada usuário específico. 30

31 Diagrama de Casos de Uso Principais elementos do diagrama de Casos de Uso: 31

32 Diagrama de Casos de Uso - Representação Sistema Bancário Realizar depósito Cliente Realizar saque Ator Associação Casos de uso 32

33 Diagrama de Casos de Uso - Atores Agente externo que interage com o sistema Comunica-se com o sistema enviando e recebendo mensagens Pode representar: pessoas, papéis, um hardware especial, outros sistemas, outros órgãos,etc... Exemplo de Atores: Gerente Funcionário Cliente Caixa Eletrônico Sistema de Contas a Pagar e Receber 33

34 Diagrama de Casos de Uso - Atores Tipos de atores: principal: interessado nos resultados produzidos pelo sistema (quem solicita o serviço), mas não necessariamente interage com o sistema. Ex.: cliente secundário: interage com o sistema e que não tem interesse em seus resultados. ex.: funcionário contratado para atender os clientes 34

35 Diagrama de Casos de Uso Casos de Uso Referem-se aos serviços, tarefas ou funções que podem ser utilizados de alguma maneira pelos usuários do sistema. Utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema. Abrir conta Obter extrato de conta Casos de uso 35

36 Diagrama de Casos de Uso Relacionamentos O diagrama de Casos de Uso possibilita o relacionamento entre: o Atores e Casos de Uso o Atores o Casos de Uso 36

37 Diagrama de Casos de Uso Relacionamentos Tipos de relacionamento: o Comunicação Entre Ator e Caso de Uso o Generalização/Especialização Entre Atores Entre Casos de Uso o Inclusão Entre Casos de Uso o Extensão Entre Casos de Uso 37

38 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Ator e Casos de Uso 38

39 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Ator e Casos de Uso Só é permitido o relacionamento tipo Comunicação Pode ser navegável: em uma direção em duas direções Sistema de Matrícula Cliente Efetuar matrícula Emitir Comprovante de matrícula Ator Casos de uso 39

40 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Atores 40

41 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Atores - tipo Generalização Só é permitido o relacionamento tipo Generalização usada para representar a relação entre atores que realização tarefas comuns, com pequenas diferenças entre si. Ocorre a sobreposição de papéis no Ator que atua como Especialização. 41

42 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Atores tipo Generalização 42

43 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Casos de Uso 43

44 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Casos de Uso Tipo Generalização usada para representar a relação entre dois ou mais Casos de Uso com características semelhantes, com algumas diferenças entre si. Pode ocorrer sobreposição de funcionalidade 44

45 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Casos de Uso Tipo Generalização 45

46 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Casos de Uso Tipo Inclusão Utilizado quando existe um serviço comum a mais de um Caso de Uso. Deve ser colocado em um caso de uso específico para que outros Casos de Uso utilizem-se desse serviço A relação de inclusão implica em obrigatoriedade de execução 46

47 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Casos de Uso Tipo Inclusão 47

48 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Casos de Uso Tipo Extensão Utilizado para descrever cenários opcionais de um Caso de Uso Indica a necessidade de testar uma condição para determinar se é necessário executar o caso de uso estendido ou não. Representam eventos que não ocorrem sempre, o que não significa que eles sejam incomum 48

49 Diagrama de Casos de Uso Relacionamentos Relacionamento entre Casos de Uso Tipo Extensão 49

50 Diagrama de Casos de Uso - Exemplo 50

51 Diagrama de Casos de Uso Outro Exemplo 51

52 Documento de Especificação de Casos de Uso Documento com a descrição textual de como ocorre a interação entre atores e sistema na realização de um caso de uso Nele é possível : Indicar COMO e QUANDO o caso de uso se inicia e termina quando o caso de uso interage com atores quais objetos são transferidos fluxo básico e alternativos do comportamento

53 Modelo de Documentação de Casos de Uso Descrição detalhada Nome Descrição sucinta Atores Pré-Condições Pós-Condições Fluxo Básico Fluxos Alternativo Fluxos de Exceção Estrutura de dados Regras de negócio Observações

54 Documentação de Casos de Uso Fluxo Alternativo Alternativa ao fluxo principal Fluxo de Exceção Possível consequência de uma alternativa escolhida previamente ou de um erro. Regras de Negócio Modo como realiza o negócio.

55 Diagrama de Classes 55

56 Diagrama de Classes Considerado o diagrama mais importante e utilizado da UML. Enfoque na visualização das classes pertencentes ao sistema e nas relações entre estas classes. Fornece uma visão de como as classes pertencentes a um sistema estão organizadas (visão estática do sistema). Pode ser representado em vários níveis diferentes: nível conceitual ou de domínio e nível de projeto. Serve como base para a construção da maioria dos outros diagramas da UML. 56

57 Diagrama de Classes Exemplo de diagrama de classes representando um Sistema de Vendas 57

58 Classes conjunto de objetos com propriedades comuns (atributos, operações e relacionamentos). representa os estados e comportamentos que os objetos podem assumir: o estado corresponde os atributos o comportamento corresponde as operações As classes podem ser usadas para representar: software, hardware ou puramente itens conceituais. 58

59 Representação básica A classe é representada graficamente com um retângulo contendo nome, atributos e operações. A apresentação dos atributos e operações pode variar conforme as necessidades e objetivos. Nome Atributos Operações 59

60 Nomes de Classes Cada classe deve ter um nome único; Classes em pacotes diferentes podem ter o mesmo nome; Procure usar substantivos; A primeira letra de cada palavra deve ser maiúscula. Exemplos: Produto Cliente ItemPedido 60

61 Atributos da Classe Representam o estado das instâncias da classe São valores que a classe e ou instâncias (objetos) contém Uma classe pode conter nenhum ou vários atributos; 61

62 Operações da Classe implementação de um serviço que pode modificar o comportamento do objeto pode ter nenhuma ou várias operações Os nomes das operações inicia-se com verbos Mesmo que não tenha parâmetros, finalizar com parênteses () 62

63 Operações da Classe Sua assinatura é composta pelo seu nome, quantidade de parâmetros e pelos tipos dos parâmetros Iniciado em minúsculo, demais palavras com inicial maiúsculo. Exemplos: apresentarcliente() incluirnotafiscal() consultarpedido() 63

64 Visibilidade As marcações de acesso servem para especificar o tipo de acesso permitido aos atributos e operações: + publico: visível a todos os classificadores # protegido: visível ao próprio classificador e seus descendentes - privado: visível apenas ao próprio classificador 64

65 Relacionamentos vínculo que ocorre entre as classes com o intuito de compartilhar informações e colaborarem umas com as outras para executar tarefas. Tipos de relacionamentos em diagramas de classes: o Associação o Generalização o Dependência 65

66 Associação descreve o vínculo que ocorre entre as classes Tipos de Associação: o associação unária ou reflexiva (entre uma classe) o associação binária (entre duas classes) o associação ternária ou N-ária (entre três ou várias classes) 66

67 Associação determina que as instâncias de uma classe estão de alguma forma ligadas às instâncias das outras classes envolvidas na associação pode haver troca de informações entre as classes e o compartilhamento de métodos. Nas extremidades da assoicação deve conter: o Os papéis das classes naquela associação o A multiplicidade o A navegabilidade da associação. 67

68 Exemplo Associação com Papel Neste exemplo a classe estudante assume dois papéis diferentes. 68

69 Multiplicidade Define o limite de vezes que as instâncias de uma classe devem se relacionar com as instâncias de outra classe Tipos de cardinalidade: Cardinalidade pode ser 0 ou Cardinalidade só pode ser 1 0..* - Cardinalidade pode variar de 0 até infinito * - Cardinalidade pode variar de 0 até infinito 1..* - Cardinalidade pode variar de 1 até infinito Cardinalidade pode variar de 1 até 6 69

70 Exemplo - Associação com Multiplicidade Quando não for definida a multiplicidade na extremidade da relação considera que a multiplicidade é 1. 70

71 Navegabilidade Representada por uma seta na extremidade da linha que indica o relacionamento entre duas classes. Expressa o sentido em que as informações são transmitidas entre as classes envolvidas. Indica também as classes que cada classe pode enviar mensagem. 71

72 Navegabilidade Associação Unidirecional (com navegabilidade em uma única direção) o indica que só uma classe está ciente da relação o as informações trafegam em uma única direação. Associação Bidirecional (com navegabilidade nas duas direçãoes ou sem navegabilidade) o todas as classes estão ciente da relação o as informações podem trafegar em todas as direções entre as classes da associação Por padrão as associações são bidirecional. 72

73 Exemplo Associação com Navegabilidade A empresa sabe quais são seus funcionários, mas o funcionário não sabe a que empresa pertence. public class Empresa { private string NomEmpresa; public funcionario empregado[]; } public class Funcionário { private long Codigo; private char Nome; private long codchefe; } 73

74 Associação As associações podem ser modeladas da seguinte forma: Associação Unária ou Reflexiva Associação Binária Classe de Associação (Classe Associativa) Agregação Composição 74

75 Associação Unária ou Reflexiva Uma mesma classe pode se relacionar com ela própria através de uma associação. 75

76 Associação Binária Ocorre quando são identificados relacionamentos entre duas duas classes. Constitui-se o tipo de relacionamento mais comum encontrado nos diagramas de classe. 76

77 Classe de Associação (Classe Associativa) Classes produzidas quando da ocorrência de associações que possuem multiplicidade muitos (*) em todas as suas extremidades. Necessárias para armazenar as informações produzidas pela associação, além dos atributos próprios da relação. Válidas somente quando existe um único objeto associado a duas instâncias associadas. 77

78 Classe Associativa - Exemplo. Podem ser substitídas por classes normais só que permite vários objetos relacionados a duas instâncias associadas. No caso acima, um ator pode atuar no mesmo filme com vários papéis diferentes.. 78

79 Agregação Tipo especial de associação usado para modelar relacionamentos do tipo todo-parte. Usado para indicar que as informações de um objeto (objetotodo) precisam ser completadas pelas informações contidas em um ou mais objetos de outra classe (objeto-parte). Os objetos-parte podem ser compartilhados por mais de um objeto-todo. Indica obrigatoriedade de complementação das informações de um objeto-todo por seus objeto-parte. 79

80 Agregação - Exemplos Indica que sempre que uma pessoa for consultada, além de suas informações serão apresentadas todas as contas referentes a esta pessoa. 80

81 Composição Constitui-se em uma variação da associação de agregação. Representa um vínculo mais forte entre os objetos-todo e os objetos-parte. Demonstra que os objetos-parte tem de pertencer exclusivamente a um único objeto-todo com que se relacionam Em uma composição os objeto-parte não podem ser destruídos por um objeto diferente do objeto-todo ao qual estão relacionados. 81

82 Composição - Exemplo 82

83 Composição - Exemplo 83

84 Generalização / Especialização Relacionamento utilizado para a modelar Herança Herança é a habilidade de uma classe (classe filha) de herdar as propriedades de outra classe (classe pai), podendo possuir atributos e métodos próprios. 84

85 Generalização / Especialização 85

86 Relacionamento de Dependência Expressa um certo grau de dependência de uma classe com relação a outra. Implica que sempre que ocorrer uma alteração na classe da qual uma outra depende, esta deverá também sofrer uma alteração. Não costuma ser encontrado com muita frequência nos diagramas de classes. Deve-se modelar dependência apenas quando for relevante para o contexto da aplicação. 86

87 Dependência - Exemplo O método Incluir da classe Disciplina usa o objeto Aluno como parâmetro da classe Estudante Qualquer mudança na classe Estudante poderá afetar a classe Disciplina 87

88 Representação de Restrição Informações extras que definem condições a serem validadas durante a implementação dos relacionamentos entres as classes. Em geral, são representadas nos diagramas de classes por textos limitados por chaves. 88

89 Representação de Restrição - Exemplo 89

90 Representação de Restrição - Exemplo Indica que uma conta corrente pode tanto ser possuída por uma pessoa física como uma pessoa jurídica, mas uma determinada conta só pode pertencer a uma única pessoa. 90

91 Representação de Restrição para classes especializadas. Indica que se uma pessoa for física, ela não pode ser jurídica e vice-versa. 91

92 Representação de Restrição para classes especializadas. Indica que um veículo pode ser tanto aéreo como aquático, como é o caso de um hidro-avião. 92

93 Visão Geral Diagrama de Classes e seus elementos 93