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

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

UML Frei Joaquim José Hangalo Universidade Católica de Angola Faculdade de Engenharia.

Apresentações semelhantes


Apresentação em tema: "UML Frei Joaquim José Hangalo Universidade Católica de Angola Faculdade de Engenharia."— Transcrição da apresentação:

1 UML Frei Joaquim José Hangalo Universidade Católica de Angola Faculdade de Engenharia

2 UML n A Unified Modeling Language (UML) é a linguagem mais utilizada atualmente para especificação e projecto de software na abordagem orientada a objectos. A UML é o instrumento que permite a modelagem do software visualmente, tornando fácil partir dos requisitos do sistema à implementação de uma forma amigável.

3 UML n A UML está formalmente em desenvolvimento desde 1994, porém, a UML não é uma ideia que partiu do zero, a UML é uma consolidação de renomadas técnicas retiradas de metodologias já existentes e bastante praticadas até então.

4 n A UML abrange todas as etapas da produção de software, mas principalmente é utilizada para traduzir os requerimentos(requisitos) do sistema (em alto nível e mais próximos do usuário) em componentes codificáveis (mais próximos da aplicação).

5 UML n Mesmo estando entre essas duas camadas, a UML pretende ser fácil de entender para todos os envolvidos. A UML é uma linguagem, e como tal, é um meio de comunicação. Através de diagramas gráficos é mais fácil discutir e visualizar as ideias e soluções entre a equipa, ou com o usuário. Muito mais simples do que com programas em código.

6 Diagrama de casos de Uso

7 Casos de Uso n Modelando ou escrevendo, o principal para entender a importância do Caso de Uso são os objectivos dele: n Definir Escopo n Organizar e dividir o trabalho n Estimar o tamanho do projecto n Direccionar os testes

8 Escopo do sistema com Casos de Uso n Definir Escopo: Um conjunto de Casos de Uso define o escopo do sistema de uma maneira simples. Se no diagrama aparece um Caso de uso chamado Plantar Batata, os usuários não poderão dizer que plantar couve está no escopo do sistema.

9 Organizar e dividir o trabalho: n O Caso de Uso é uma importante unidade de organização do trabalho dentro do projecto, geralmente nas equipes de projecto é comum ouvir que o Zé está trabalhando no Caso de Uso X e o João está com o Caso de Uso Y.

10 Organizar e dividir o trabalho: n A unidade do Caso de Uso divide o trabalho da equipe entre as pessoas, fora isso, é comum dizer que o Caso de Uso está em Análise, em Programação ou em Teste.

11 Organizar e dividir o trabalho: n Casos de Uso também são entregues separadamente aos usuários em conjuntos divididos em fases ou iterações no projecto. Então, dizemos que a primeira iteração (ou entrega) terá os Casos de Uso X, Y, Z e W e na segunda iteração terá os Casos de Uso T, H, I e J.

12 Estimar o tamanho do projecto: n O Caso de Uso fornece métricas para definir o tempo de desenvolvimento. Uma das métricas que pode ser aplicada sobre Casos de Uso é a UCP (Use Case Point) que consiste em classificar os Casos de Uso em nível de complexidade e somando todos os Casos de Uso do projecto (e mais alguns factores) você consegue estimar o esforço do projecto em horas. Além do UCP, podem ser aplicadas as técnicas de Pontos de Função (Function Points) que são mais padronizadas e completas.

13 Direccionar os testes: n Os testes do sistema (essencialmente os funcionais que são os mais importantes) são derivados do Caso de Uso. Essa característica é uma das mais importantes e geralmente é desprezada, pois com Casos de Uso, os testes são planejados no início do projecto e não no fim, diminuindo os riscos. A partir dos Casos de Uso, Casos de Teste são criados para validar o funcionamento do software.

14 Diagrama de Casos de Uso Diagrama de Casos de Uso

15 O diagrama de CASOS DE USO procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, através da perspectiva do usuário...O diagrama de CASOS DE USO procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, através da perspectiva do usuário... Diagrama mais ABSTRATODiagrama mais ABSTRATO Diagrama mais FLEXÍVELDiagrama mais FLEXÍVEL Diagrama mais INFORMALDiagrama mais INFORMAL

16 n Olhando para um diagrama de Casos de Uso, pela sua simplicidade, um analista poderá observar rapidamente as funcionalidades envolvidas no sistema, os usuários envolvidos e integrações com sistemas externos. O propósito maior do Caso de Uso é fornecer uma descrição do comportamento do sistema do ponto de vista do usuário.

17 Diagrama de Casos de Uso Diagrama de Casos de Uso MAS extremamente importante...MAS extremamente importante... Mapeamento dos REQUISITOSMapeamento dos REQUISITOS Base para os demais diagramas da UMLBase para os demais diagramas da UML

18 Diagrama de Casos de Uso Diagrama de Casos de Uso Objetivos – Funções Apresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer aos usuáriosApresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer aos usuários Sem se preocupar com o COMOSem se preocupar com o COMO Tenta identificar os tipos de usuários que irão interagir com o sistema, quais os papéis que estes usuários irão assumir e quais funções serão requisitas por cada usuário específicoTenta identificar os tipos de usuários que irão interagir com o sistema, quais os papéis que estes usuários irão assumir e quais funções serão requisitas por cada usuário específico

19 Diagrama de Casos de Uso Diagrama de Casos de Uso COMPONENTES PRINCIPAIS

20 n A notação básica do diagrama são Atores representados pelos bonequinhos. Uma linha conecta atores aos Casos de Uso informando que o sistema permitirá ao Ator usar o Caso de Uso directamente. Os Casos de Uso são representados por elipses (existem notações alternativas para os elementos, mas essas são as mais usuais).

21 Diagrama de Casos de Uso Diagrama de Casos de Uso ACTORES Representam os papéis desempenhados pelos diversos usuários que poderão utilizar de alguma maneira os serviços e funções do sistemaRepresentam os papéis desempenhados pelos diversos usuários que poderão utilizar de alguma maneira os serviços e funções do sistema Normalmente PESSOASNormalmente PESSOAS Eventualmente HARDWARE – SOFTWARE que interajam com o sistemaEventualmente HARDWARE – SOFTWARE que interajam com o sistema

22 Diagrama de Casos de Uso Diagrama de Casos de Uso ACTORES n um Actor é um PAPEL DESEMPENHADO POR ALGUMA COISA EXTERNA ao sistema (não necessariamente uma pessoa). Até mesmo o tempo pode ser um Actor para tarefas que ocorrem com frequência temporal.

23 Diagrama de Casos de Uso Diagrama de Casos de Uso ATORES - representação

24 n componentes internos do sistema não são Actores: É comum o analista imaginar que porque sistemas externos podem ser atores, o banco de dados da aplicação que está sendo desenvolvida deve ser um actor também, mas isso é errado, lembre que Actor é um papel de responsabilidade externa ao sistema. O que deve funcionar dentro da responsabilidade do sistema não pode ser extraído como um Actor.

25 n Hardwares internos do sistema não são Atores: pode-se imaginar que um servidor é externo ao sistema, ou uma impressora num Caso de Uso que precise imprimir alguma coisa é externa ao sistema também, porém, esses itens externos ao sistema são componentes que o software pressupõe que existem e cumprirão seu papel. Então, são como os componentes do funcionamento interno do software (como a base de dados da aplicação) e assim sendo, não são Actores.

26 n Alguns tipos de hardwares podem ser Actores, mas somente quando for importante para a análise do sistema destacar a presença desse hardware. Por exemplo, softwares para controles industriais podem ter alguns sensores que indicam algum tipo de problema na linha de produção e disparam algum comportamento (Caso de Uso) no sistema. Este sim pode ser um hardware que é um Actor no sistema, pois é importante destacar isso para o funcionamento do Caso de Uso. Outro hardware que pode ser um Actor seria o aparelho de controlo de ponto (entrada e saída de funcionários) para um sistema de Administração de Pessoal. Ela desempenha um papel no sistema, seria um Actor.

27 n A definição de Actores (e Casos de Uso) não é o controle de acessos da aplicação: Esse erro também é comum: confundir a definição de Actores com o que os usuários podem ou não fazer dentro do sistema. Não é essa a ideia! A representação do Actor somente destaca o papel que um usuário assume ao usar o Caso de Uso.

28 Papéis x Utilizadores Neste exemplo, o diagrama de Casos de Uso somente diz que para Emitir Pedido o utilizador deverá assumir o papel de Vendedor, isso não implica que um usuário que possui o cargo de vendedor na organização não possa Aprovar Pedido.

29 n O que consideramos mais importante na definição de Actores é dar nome aos papéis que pessoas assumirão ao utilizar o sistema e informar integrações com sistemas externos. Enfim, em 90% dos casos um Actor será uma pessoa (utilizador do sistema) ou um sistema externo. Isso serve para dar clareza a quem lê o diagrama deixando as coisas o mais simples possível.

30 n é possível definir uma herança entre Actores para estabelecer generalizações de Actores. Generalização de Actores

31 n A generalização de Atores serve para passar a ideia de algo em comum entre papéis no sistema. Assim, se um Caso de Uso requer um Vendedor, vendedores remotos e locais se encaixam no papel pela herança. Essa notação também não é muito comum, pois para pessoal não técnico, o conceito de generalização não é fácil de compreender.

32 casos de uso

33 Diagrama de Casos de Uso Diagrama de Casos de Uso CASOS DE USO Referem-se aos serviços, tarefas ou funções que podem ser utilizados pelos usuários do sistemaReferem-se aos serviços, tarefas ou funções que podem ser utilizados pelos usuários do sistema Utilizados para expressar/documentar os comportamentos pretendidos para as funções do sistemaUtilizados para expressar/documentar os comportamentos pretendidos para as funções do sistema Abrir Conta

34 n A representação do Caso de Uso no Diagrama é simples: a elipse representa uma forma que o sistema se comporta do ponto de vista do Actor. O nome do Caso de Uso é uma forma de elucidar esse comportamento do sistema, assim sendo, o nome do caso de uso define o OBJETIVO do Actor, isto é, o que ele quer fazer no sistema.

35 Caso de Uso = Objectivo do Actor

36 n Todo o conjunto de Casos de Uso e Actores do sistema organiza o escopo do sistema a respeito dos objectivos que os usuários atingirão quando o sistema estiver pronto.

37 Todos os Casos de Uso = Escopo

38 n Dar nomes aos Casos de Uso com o objectivo do Actor é a maneira de tornar o diagrama claro para o pessoal menos técnico saber exactamente o que será possível fazer no sistema. A narrativa (texto) do Caso de Uso deve ser consistente com esse objectivo definido pelo seu nome.

39 Diagrama de Casos de Uso Diagrama de Casos de Uso Narrativa ou documentação do Caso de Uso do Caso de Uso

40 n existem inúmeros formatos ou templates de preenchimento de uma narrativa de Caso de Uso. n a UML não define o modo como uma narrativa deve ser descrita.

41 Diagrama de Casos de Uso Diagrama de Casos de Uso NarrativaNarrativa ObjectivoObjectivo Descrever, através de uma linguagem simples, a função em linhas gerais do caso de uso, quais atores interagem com o mesmo, quais etapas devem ser executadas pelo ator e pelo sistema, quais parâmetros devem ser fornecidos e quais as restrições/validações o caso de uso deve possuirDescrever, através de uma linguagem simples, a função em linhas gerais do caso de uso, quais atores interagem com o mesmo, quais etapas devem ser executadas pelo ator e pelo sistema, quais parâmetros devem ser fornecidos e quais as restrições/validações o caso de uso deve possuir

42 n A narrativa do Caso de Uso é um texto passo a passo sobre as acções que o Actor pode tomar e como o Sistema responderá a esta acção. A narrativa vai então evoluindo, entre acções do Actor e as respostas do Sistema, para o objectivo do Actor, até este ser alcançado.

43 n o Caso de Uso Emitir Pedido envolve várias tarefas menores como seleccionar produtos, escolher forma de pagamento, calcular descontos, escolher forma de entrega, porém, tudo isso são partes do objectivo maior que é emitir o pedido.

44 n IMPORTANTE: Na narrativa do Caso de Uso a resposta do sistema deve-se limitar somente ao que o Actor consegue ver. Não é necessário se preocupar em como o sistema obteve ou calculou os dados. Limite-se a escrever o que o sistema responde e não como ele obtém a resposta.

45 Diagrama de Casos de Uso Diagrama de Casos de Uso

46

47 ASSOCIAÇÕES Representam INTERAÇÕES/RELACIONAMENTOS entre:Representam INTERAÇÕES/RELACIONAMENTOS entre: ATORESATORES ATORES e CASOS DE USOATORES e CASOS DE USO CASOS DE USO e CASOS DE USOCASOS DE USO e CASOS DE USO Relacionamentos entre CASOS DE USO:Relacionamentos entre CASOS DE USO: INCLUSÃOINCLUSÃO EXTENSÃOEXTENSÃO GENERALIZAÇÃOGENERALIZAÇÃO

48 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES ATOR CASO DE USOATOR CASO DE USO Demonstra que o ator utiliza-se da função do sistema representada pelo caso de uso – requisitando a execução, recebendo o resultado produzidoDemonstra que o ator utiliza-se da função do sistema representada pelo caso de uso – requisitando a execução, recebendo o resultado produzido

49 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES ATOR CASO DE USO

50 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES ESPECIALIZAÇÃO/GENERALIZAÇÃOESPECIALIZAÇÃO/GENERALIZAÇÃO Associação entre Casos de Uso com características semelhantesAssociação entre Casos de Uso com características semelhantes A estrutura de um Caso de Uso generalizado é herdada pelos Casos de Usos especializadosA estrutura de um Caso de Uso generalizado é herdada pelos Casos de Usos especializados

51 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES ESPECIALIZAÇÃO/GENERALIZAÇÃOESPECIALIZAÇÃO/GENERALIZAÇÃO

52 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES ESPECIALIZAÇÃO/GENERALIZAÇÃOESPECIALIZAÇÃO/GENERALIZAÇÃO

53 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES INCLUSÃOINCLUSÃO Usada quando existe um serviço, situação ou rotina comum a mais de um Caso de UsoUsada quando existe um serviço, situação ou rotina comum a mais de um Caso de Uso Outros Casos de Uso utilizam-se de um Caso de UsoOutros Casos de Uso utilizam-se de um Caso de Uso Chamada de Sub-RotinaChamada de Sub-Rotina Linha tracejada com texto >Linha tracejada com texto >

54 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES - INCLUSÃO

55 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES EXTENSÃOEXTENSÃO Descrever cenários opcionais de um Caso de UsoDescrever cenários opcionais de um Caso de Uso Descrevem cenários que somente ocorrerão em uma situação específica – se uma determinada condição for satisfeitaDescrevem cenários que somente ocorrerão em uma situação específica – se uma determinada condição for satisfeita > >

56 Diagrama de Casos de Uso Diagrama de Casos de Uso ASSOCIAÇÕES - EXTENSÃO

57 Diagrama de Casos de Uso Diagrama de Casos de Uso EXTRAS GERAIS NotasNotas Apresentar texto explicativoApresentar texto explicativo

58 Diagrama de Casos de Uso Diagrama de Casos de Uso EXTRAS GERAIS PacotesPacotes Organizar elementos em grupos para serem utilizados na modelagem de sistemas muito extensos – principalmente quando existem vários sistemas ou sub-sistemas integradosOrganizar elementos em grupos para serem utilizados na modelagem de sistemas muito extensos – principalmente quando existem vários sistemas ou sub-sistemas integrados Demonstram os limites de cada sub-sistema e como eles se inter-relacionamDemonstram os limites de cada sub-sistema e como eles se inter-relacionam

59 Diagrama de Casos de Uso Diagrama de Casos de Uso EXTRAS GERAIS PacotesPacotes

60 Diagrama de Casos de Uso Diagrama de Casos de Uso EXTRAS GERAIS EstereótiposEstereótipos Permitem a identificação de componentes – permitindo sua diferenciação dando maior destaque no diagramaPermitem a identificação de componentes – permitindo sua diferenciação dando maior destaque no diagrama

61 Diagrama de Casos de Uso Diagrama de Casos de Uso Exercícios – Estudos de Caso Video ClubVideo Club Gestão de CursosGestão de Cursos Venda de Passagens AéreasVenda de Passagens Aéreas Clínica VeterináriaClínica Veterinária Escritório de AdvocaciaEscritório de Advocacia

62 Diagrama de Casos de Uso Diagrama de Casos de Uso Exercícios – Estudos de Caso Controlo de CinemaControlo de Cinema Controlo de Clube SocialControlo de Clube Social Locação de VeículosLocação de Veículos Leilão via InternetLeilão via Internet Controlo de HotelariaControlo de Hotelaria

63 Diagrama de Casos de Uso Diagrama de Casos de Uso Exercícios – Estudos de Caso

64 Diagrama de Classes

65 65 Introdução n O modelo de casos de uso fornece uma perspectiva do sistema a partir de um ponto de vista externo. n De posse da visão de casos de uso, os desenvolvedores precisam prosseguir no desenvolvimento do sistema.

66 66 n A funcionalidade externa de um sistema orientado a objetos é fornecida através de colaborações entre objetos. Externamente, os atores visualizam resultados de cálculos, relatórios produzidos, confirmações de requisições realizadas, etc.Externamente, os atores visualizam resultados de cálculos, relatórios produzidos, confirmações de requisições realizadas, etc. Internamente, os objetos colaboram uns com os outros para produzir os resultados.Internamente, os objetos colaboram uns com os outros para produzir os resultados. n Essa colaboração pode ser vista sob o aspecto dinâmico e sob o aspecto estrutural estático. Aspectos dinâmico e estático

67 67 Modelo de classes n O diagrama da UML utilizado para representar o aspecto estrutural estático é o diagrama de classes. n O modelo de classes é composto desse diagrama e da descrição textual associada. n O modelo de classes evolui durante o desenvolvimento do sistema. À medida que o sistema é desenvolvido, o modelo de classes é incrementado com novos detalhes.À medida que o sistema é desenvolvido, o modelo de classes é incrementado com novos detalhes.

68 68 Classes n Uma classe representa um grupo de objetos semelhantes. n Uma classe descreve esses objetos através de atributos e operações. n Os atributos correspondem às informações que um objeto armazena. n As operações correspondem às ações que um objeto sabe realizar.

69 Classes n Uma classe é uma descrição de um conjunto de objectos que partilham os mesmos atributos, operações, relações e semântica

70 70 Notação para uma classe n Representada através de uma caixa com no máximo três compartimentos exibidos. n Notação utilizada depende do nível de abstração desejado.

71 n Na secção de topo indica-se o nome da classe (que tem que ser único num diagrama), na secção intermédia enumeram-se os atributos da classe, e na secção inferior enumeram-se as operações que são permitidas efectuar sobre os objectos da classe.

72 classes n Como regra geral de bom senso, de modo a não sobrecarregar os diagramas, é aconselhável não enumerar o conjunto básico de operações que usualmente podem ser aplicadas a todos os objectos de todas as classes, nomeadamente, adicionar, remover, listar e alterar n Estas operações apenas devem ser indicadas caso possuam alguma particularidade específica

73 73 Exemplo (classe ContaBancária)

74 Relações n Em qualquer sistema existem objectos que se relacionam entre si. n Por exemplo, se considerarmos a classe das facturas de uma empresa, o cliente Abel relaciona-se com as facturas emitidas em seu nome

75 Relações n A relação entre objectos é representada através das relações entre as classes. n Existem diferentes tipos de relações, n Aqui serão abordadas algumas que se podem classificar em dois tipos, associações e generalizações.

76 76 Associações n Para representar o fato de que objetos podem se relacionar uns com os outros, utiliza-se a associação. n Uma associação representa relacionamentos (ligações) que são formados entre objetos durante a execução do sistema. embora as associações sejam representadas entre classes do diagrama, tais associações representam ligações possíveis entre objetos das classes envolvidas.embora as associações sejam representadas entre classes do diagrama, tais associações representam ligações possíveis entre objetos das classes envolvidas.

77 77 Notação para uma associação n Representada através de um segmento de reta ligando as classes cujos objetos se relacionam. n Exemplos:

78 Associação

79 n Os intervalos de valores indicados nos extremos da semi-recta indicam, a multiplicidade da associação n O intervalo {0..*} significa o intervalo entre entre 0 e infinito, o intervalo {1..1} (que usualmente é abreviado para {1}, isto é, quando o limite inferior é igual ao superior apenas se indica um dos limites) corresponde ao intervalo que apenas contém o valor 1 n O exemplo da figura indica que: um cliente pode estar associado a várias (infinitas) facturas, ou a nenhuma, e uma factura necessariamente tem que estar associada a um cliente e a não mais do que um

80 80 Multiplicidades n Representam a informação dos limites inferior e superior da quantidade de objetos aos quais um outro objeto pode estar associado. n Cada associação num diagrama de classes possui duas multiplicidades, uma em cada extremo da linha de associação.

81 Multiplicidade n Uma associação deve ser sempre lida nos dois sentidos

82 Multiplicidade n A multiplicidade diz sempre respeito ao número de objectos da classe mais próxima que podem estar associados a um objecto da classe do extremo oposto.

83 83 Multiplicidades NomeSimbologia Apenas Um1..1 (ou 1) Zero ou Muitos0..* (ou *) Um ou Muitos1..* Zero ou Um0..1 Intervalo Específicol i..l s

84 84 Exemplo (multiplicidade) n Pode haver um cliente que esteja associado a vários pedidos. n Pode haver um cliente que não esteja associado a pedido algum. n Um pedido está associado a um, e somente um, cliente.

85 85 Exemplo (multiplicidade) n Uma corrida está associada a, no mínimo, dois velocistas n Uma corrida está associada a, no máximo, seis velocistas. n Um velocista pode estar associado a nenhuma ou várias corridas.

86 86 Conectividade n A conectividade corresponde ao tipo de associação entre duas classes: muitos para muitos, um para muitos e um para um. n A conectividade da associação entre duas classes depende dos símbolos de multiplicidade que são utilizados na associação.

87 87 Conectividade X Multiplicidade ConectividadeNum extremo No outro extremo Um para um Um para muitos * 1..* 0..* Muitos para muitos* 1..* 0..* * 1..* 0..*

88 88 Exemplo (conectividade)

89 89 Participação n Uma característica de uma associação que indica a necessidade (ou não) da existência desta associação entre objetos. n A participação pode ser obrigatória ou opcional. Se o valor mínimo da multiplicidade de uma associação é igual a 1 (um), significa que a participação é obrigatóriaSe o valor mínimo da multiplicidade de uma associação é igual a 1 (um), significa que a participação é obrigatória Caso contrário, a participação é opcional.Caso contrário, a participação é opcional.

90 90 Nome de associação, direção de leitura e papéis n Para melhor esclarecer o significado de uma associação no diagrama de classes, a UML define três recursos de notação: Nome da associação: fornece algum significado semântico a mesma.Nome da associação: fornece algum significado semântico a mesma. Direção de leitura: indica como a associação deve ser lidaDireção de leitura: indica como a associação deve ser lida Papel: para representar um papel específico numa associação.Papel: para representar um papel específico numa associação.

91 91 Exemplo (Nome de associação, direção de leitura e papéis)

92 92 Agregação n É um caso especial da associação conseqüentemente, multiplicidades, participações, papéis, etc. podem ser usados igualmenteconseqüentemente, multiplicidades, participações, papéis, etc. podem ser usados igualmente n Utilizada para representar conexões que guardam uma relação todo-parte entre si.

93 93 Agregação n Numa agregação, um objeto está contido no outro, ao contrário de uma associação. n Onde se puder utilizar uma agregação, uma associação também poderá ser utilizada.

94 94 Agregação n Sejam duas classes associadas, X e Y. Se uma das perguntas a seguir for respondida com um sim, provavelmente há uma agregação onde X é todo e Y é parte. X tem um ou mais Y?X tem um ou mais Y? Y é parte de X?Y é parte de X?

95 95 Notação para uma agregação n Representada como uma linha conectando as classes relacionadas, com um diamante (losango) branco perto da classe que representa o todo. n Exemplo:

96 96 Composição n Forma ainda mais forte da agregação. n Objetos-parte pertencem a um único todo. n Objetos-parte são sempre criados e destruídos pelo objeto-todo. n Se o todo deixa de existir, o mesmo acontece com as suas partes. PedidoItemPedido 1..* 1

97 97 Generalização/Especialização (Herança) n É um relacionamento no qual os objetos especializados (filhos) são substituídos por objetos generalizados (pais); n Graficamente, é representada por linhas sólidas com uma seta em branco apontando para o pai: Pessoa FisicaJuridica

98 Exemplos Pessoa nome Aluno matricula Professor

99 Sistema Acadêmico Pessoa nome Aluno matricula Professor SistemaAcademico

100 Locadora de DVD Pessoa nome Cliente registo Funcionario MinhaLocadora DVD titulo

101 Locadora de DVD Pessoa nome Cliente registo Funcionario MinhaLocadora DVD titulo

102 Campeonato de Futebol Pessoa nome Jogador posicao Presidente CampeonatoAngolano Time nome Tecnico...

103 Classe Associativa n As associações também podem ter atributos, nestas situações (Classes Associativas) cria-se uma classe (unida à associação por uma semi-recta a tracejado) onde se colocam os respectivos atributos.

104 104 Classe associativa n É uma classe que está ligada a uma associação, ao invés de estar ligada a outras classes. n É normalmente necessária quando duas ou mais classes estão associadas, e é necessário manter informações sobre esta associação. n Uma classe associativa pode estar ligada a associações de qualquer tipo de conectividade.

105 105 Notação para uma classe associativa n Representada pela notação utilizada para uma classe. A diferença é que esta classe é ligada a uma associação. n Exemplo:

106 106 Associações reflexivas n Associa objetos da mesma classe. Cada objeto tem um papel distinto na associação.Cada objeto tem um papel distinto na associação. n A utilização de papéis é bastante importante para evitar ambigüidades na leitura da associação. n Uma associação reflexiva não indica que um objeto se associa com ele próprio. Ao contrário, indica que objetos de uma mesma classe se associamAo contrário, indica que objetos de uma mesma classe se associam

107 107 Exemplo (associação reflexiva)

108 108 Classe Abstrata n São parcialmente implementadas e compostas por pelo menos 1 (em JAVA isso não é imposto) ou mais operações abstratas (operações sem implementação); n Tem como finalidade servir de base para a implementação do polimorfismo;

109 109 Classe Abstrata n São identificadas pela palavra abstract e na UML são em itálico; n Não gera instâncias e existem apenas em hierarquia; n Uma classe abstrata pode ter subclasses abstratas, mas nos níveis mais baixos (especializados) devem estar classes concretas;

110 110 Classe Abstrata n Podem herdar de classes abstratas e não abstratas; n Podem possuir dados (atributos); n Uma subclasse de uma classe abstrata só pode ser instanciada se sobrescrever todos os métodos abstratos da superclasse e implementá- los.

111 111 Interface n É um conjunto de especificações de serviços (operações); n Um serviço tem especificação e implementação; n A especificação define o que faz o serviço (operação); n A implementação define como o serviço é feito (método); n Uma interface pode ser representada na UML por uma pequena circunferência ligada por um segmento de reta sólido (não pontilhado) a uma classe.

112 112 Interface n Uma interface é uma classe onde todos os serviços possuem apenas especificação (método com apenas assinaturas sem implementação). n Impõe especificação do que uma classe deve oferecer e implementar. n Há semelhanças entre Interface e Classe Abstrata.

113 113 Interface n Uma interface não pode ser instanciada; n Interface só possui métodos (exceto construtores). Não possui atributos (em JAVA pode possuir atributos); n Uma classe implementa uma ou mais interface (através da cláusula implements); n Uma classe pode ao mesmo tempo herdar de uma classe e implementar uma interface;

114 114 Visibilidade Atributo e Método em APodem ser acedido por Público (+)A,B,C,D,E Protegido (#)A,B,C,D Pacote (default) (Java)A,B,D Privado (-)A (Maior Encapsulamento)

115 115 Identificando classes n Um sistema de software orientado a objetos é composto de objetos em colaboração para realizar as tarefas do sistema. n Por outro lado, todo objeto pertence a uma classe. n Portanto, quando se fala na identificação das classes, o objetivo na verdade é saber quais objetos irão compor o sistema.

116 116 Categorias de responsabilidades n Costuma-se categorizar os objetos de um sistema de acordo com o tipo de responsabilidade a ele atribuída. objetos de entidade (a que estudaremos)objetos de entidade (a que estudaremos) objetos de controleobjetos de controle objetos de fronteiraobjetos de fronteira n Esta categorização foi proposta por Ivar Jacobson (Jacobson et al, 1992) em uma técnica denominada Análise de Robustez.

117 117 Objetos de Entidade n Um objeto de entidade é um repositório para alguma informação manipulada pelo sistema. n Esses objetos representam conceitos do domínio do negócio. n Normalmente esses objetos armazenam informações persistentes. n Há várias instâncias de uma mesma classe de entidade coexistindo no sistema.

118 118 Objetos de Fronteira n Esses objetos traduzem os eventos gerados por um ator em eventos relevantes ao sistema. n Também são responsáveis por apresentar os resultados de uma interação dos objetos em algo inteligível pelo ator. n Um objeto de fronteira existe para que o sistema se comunique com o mundo exterior.

119 119 Objetos de Controle n São a ponte de comunicação entre objetos de fronteira e objetos de entidade. n Responsáveis por controlar a lógica de execução correspondente a um caso de uso. n Decidem o que o sistema deve fazer quando um evento externo relevante ocorre. Eles realizam o controle do processamentoEles realizam o controle do processamento Agem como gerentes (coordenadores, controladores) dos outros objetos para a realização de um ou mais caso de uso.Agem como gerentes (coordenadores, controladores) dos outros objetos para a realização de um ou mais caso de uso.

120 Projecto Exemplo (UML) Por onde começar?

121 Identificar os Objetos Jogador Dado Jogo

122 Identificar Métodos e Atributos Jogador nome pontos Dado numeroDeLados jogarDado() Jogo objetivo sorteiarIniciante() mostrarSituacao() iniciar() mostrarVencedor() aumentarPontos() jaGanhou()

123 Qual é a visibilidade? Jogador + nome # pontos Dado - numeroDeLados + jogarDado() Jogo # objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor() + aumentarPontos() + jaGanhou()

124 Relacionamentos entre Classes Jogador + nome # pontos Dado - numeroDeLados + jogarDado() Jogo # objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor() + aumentarPontos() + jaGanhou()

125 Definir Multiplicidade Jogador + nome # pontos Dado - numeroDeLados + jogarDado() Jogo # objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor() + aumentarPontos() + jaGanhou() * 0..1

126 Alguma dependência? Jogador + nome # pontos Dado - numeroDeLados + jogarDado() Jogo # objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor() + aumentarPontos() + jaGanhou() * 0..1

127 Uma Possível Solução UML Jogador + nome # pontos Dado - numeroDeLados + jogarDado() Jogo # objetivo + sorteiarIniciante() + mostrarSituacao() + iniciar() + mostrarVencedor() + aumentarPontos() + jaGanhou() * 0..1 O método jaGanhou precisa saber o objetivo do jogo

128 Obrigado


Carregar ppt "UML Frei Joaquim José Hangalo Universidade Católica de Angola Faculdade de Engenharia."

Apresentações semelhantes


Anúncios Google