MODELOS, VIEWS E DIAGRAMAS EM UML

O ELEMENTOS DE MODELAGEM EM UML

• ELEMENTOS ESTRUTURAIS

  • CLASSE

  • INTERFACE

  • COLABORAÇÃO

  • USE CASE

  • CLASSE ATIVA

  • COMPONENTE

  • NODO

• ELEMENTOS COMPORTAMENTAIS

  • INTERAÇÃO

  • MÁQUINA DE ESTADO

• ELEMENTOS DE AGRUPAMENTO

  • PACOTE (PACKAGE)

  • SUB-SISTEMA

• OUTROS ELEMENTOS

  • ANOTAÇÃO (NOTE)

MODELOS, VIEWS E DIAGRAMAS

• NA FIGURA ACIMA, AZUL = DINÂMICO, ROSA = ESTÁTICO

• UM MODELO É UMA DESCRIÇÃO SEMANTICAMENTE COMPLETA DE UM SISTEMA SOB UM PONTO DE VISTA PARTICULAR

  • A UML NÃO DIZ QUE MODELOS DEVEM SER CONSTRUÍDOS PARA VISUALIZAR, ESPECIFICAR, CONSTRUIR E DOCUMENTAR UM SISTEMA

  • O PROCESSO UNIFICADO SUGERE MODELOS CONCRETOS (E QUE ESTAREMOS USANDO)

• UM VIEW É UMA PROJEÇÃO DENTRO DE UM MODELO

  • UMA VIEW ABRANGE UM SUB-CONJUNTO DAS COISAS QUE PERTENCEM AO MODELO

  • UMA VIEW NÃO ABRANGE O MODELO INTEIRO QUANDO O MODELO É COMPLEXO

• MODELOS (NA REALIDADE: VIEWS DE MODELOS) SÃO REPRESENTADOS EM GRANDE PARTE POR DIAGRAMAS

  • 9 TIPOS DE DIAGRAMAS

  • DIAGRAMAS DANDO UMA VIEW ESTÁTICA:

    • USE CASE

    • CLASS

    • OBJECT

    • COMPONENT

    • DEPLOYMENT

  • DIAGRAMAS DANDO UMA VIEW DINÂMICA:

    • SEQUENCE

    • COLLABORATION

    • STATECHART

    • ACTIVITY

DIAGRAMAS DE USE CASE

• JÁ FORAM VISTOS EM CAPÍTULO ANTERIOR

• EXEMPLO:

DIAGRAMAS DE CLASSE

• UM DOS DIAGRAMAS MAIS USADOS DA UML

• CAPTURAM O VOCABULÁRIO DO SISTEMA

• DIAGRAMA DE CLASSE DESCREVE:

  • TIPOS DE OBJETOS NO SISTEMA

  • RELACIONAMENTOS ESTÁTICOS ENTRE OS TIPOS

• RELACIONAMENTOS ESTÁTICOS BÁSICOS:

  • ASSOCIAÇÕES (UM FREGUÊS ALUGA FITAS DE VÍDEO)

  • SUB-TIPOS (HÁ O FREGUÊS QUE APARECE NA LOJA E O FREGUÊS QUE LIGA)

• DIAGRAMAS DE CLASSES MOSTRAM TAMBÉM:

  • ATRIBUTOS DE OBJETOS DA CLASSE

  • OPERAÇÕES DA CLASSE

  • RESTRIÇÕES A OBEDECER NOS RELACIONAMENTOS

• UM EXEMPLO:

• TRÊS PERSPECTIVAS PARA USAR CLASSES

  • CONCEITUAL

    • MODELA CONCEITOS NO DOMÍNIO

    • AS CLASSES QUE IMPLEMENTARÃO OS CONCEITOS ENTRAM FREQUENTEMENTE (MAS NÃO NECESSARIAMENTE) NO DIAGRAMA

    • MODELAGEM CONCEITUAL É USADA NA ANÁLISE

  • ESPECIFICAÇÃO

    • PROCURAMOS TIPOS (OU INTERFACES) SEM PENSAR NA IMPLEMENTAÇÃO (ISTO É, SEM PENSAR EM CLASSES QUE SERÃO INSTANCIADAS)

    • CONCENTRA-SE NO COMPORTAMENTO DAS COISAS E NÃO NO QUE ELAS SÃO

    • MODELAGEM DE ESPECIFICAÇÃO É PREFERÍVEL DURANTE A FASE DE PROJETO

  • IMPLEMENTAÇÃO

    • CLASSES REPRESENTAM ESTRITAMENTE CONCEITOS DE IMPLEMENTAÇÃO

    • MELHOR NÃO MODELAR A NÍVEL DE IMPLEMENTAÇÃO USANDO DIAGRAMAS DE CLASSES, A NÃO SER PARA ILUSTRAR UMA TÉCNICA ESPECIAL DE IMPLEMENTAÇÃO

      • O MELHOR MODELO DE IMPLEMENTAÇÃO É O PROGRAMA

  • A MAIORIA DAS PESSOAS USA APENAS A PERSPECTIVA DE IMPLEMENTAÇÃO

  • É MELHOR MUDAR DE PERSPECTIVA DEPENDENDO DA FASE SENDO ATACADA NO DESENVOLVIMENTO

    • CONCEITUAL NO INÍCIO

    • ESPECIFICAÇÃO E IMPLEMENTAÇÃO NA FASE DE PROJETO MAS COM CLARA PREDOMINÂNCIA DA PERSPECTIVA DE ESPECIFICAÇÃO PARA FAVORECER O APARECIMENTO DE TIPOS DE COMPORTAMENTO

  • UML NÃO FALA DE PERSPECTIVAS MAS NÃO SABER QUE PERSPECTIVA FOI USADA PARA FAZER UM DIAGRAMA DE CLASSE DIFICULTA SEU ENTENDIMENTO

• ASSOCIAÇÕES

  • CONCEITUALMENTE, REPRESENTAM RELACIONAMENTOS ENTRE INSTÂNCIAS DE CLASSES

    • NA FIGURA ACIMA:

      • UMA EMPRESA TEM DEPARTAMENTOS E "OFFICES" (FILIAIS/SEDE)

      • UM DEPARTAMENTO TEM UM GERENTE

      • E ASSIM POR DIANTE

  • CADA ASSOCIAÇÃO TEM DOIS PAPEIS (ROLES)

    • CADA PAPEL É UMA DIREÇÃO DA ASSOCIAÇÃO

    • EXEMPLO: TEM UMA ASSOCIAÇÃO DE EMPRESA PARA DEPARTAMENTO E DE DEPARTAMENTO PARA EMPRESA

    • UM PAPEL PODE TER UM NOME EXIBIDO COM RÓTULO E DIREÇÃO

      • "LOCATION" ACIMA

  • UM PAPEL TEM UMA MULTIPLICIDADE (CARDINALIDADE)

    • UM "A" SEMPRE TEM UM "B" ASSOCIADO

    • UM "A" SEMPRE TEM UM OU MAIS "B" ASSOCIADOS

    • UM "A" PODE OU NÃO ESTAR ASSOCIADO A UM "B"

    • UM "A" PODE ESTAR ASSOCIADO A ZERO, UM OU MAIS "B"

  • NA PERSPECTIVA DE ESPECIFICAÇÃO, UMA ASSOCIAÇÃO REPRESENTA UMA RESPONSABILIDADE

    • OBRIGA O APARECIMENTO DE OPERAÇÕES PARA CUMPRIR A RESPONSABILIDADE

  • AS ASSOCIAÇÕES PODEM TER UMA SETA (NA FIGURA ACIMA, NÃO TEM), O QUE IMPLICA QUE A NAVEGAÇÃO QUE SÓ É PERMITIDA NA DIREÇÃO DA SETA

    • SEM SETA (NAVEGABILIDADE), SUPÕE-SE NAVEGABILIDADE NAS DUAS DIREÇÕES OU NAVEGABILIDADE DESCONHECIDA

      • UML NÃO DIZ QUAL, MAS VOCÊ TEM QUE SER CONSISTENTE

    • EXEMPLO: SE HOUVESSE SETA DE DEPARTMENT PARA PERSON (PAPEL MANAGER), ISSO IMPLICARIA QUE UM DEPARTAMENTO TEM QUE DIZER (TER ATRIBUTO/MÉTODO PARA INFORMAR) QUEM É O GERENTE MAS A PESSOA NÃO TEM QUE DIZER DE QUE DEPARTAMENTO ELA É GERENTE

    • NAVEGABILIDADE É MAIS IMPORTANTE NAS PERSPECTIVAS DE ESPECIFICAÇÃO E IMPLEMENTAÇÃO, MAS NÃO NA PERSPECTIVA CONCEITUAL

  • VOCÊ PODE DAR UMA NOME A CADA ASSOCIAÇÃO OU (EU PREFIRO ASSIM) APENAS PARA MELHORAR A LEGIBILIDADE

• ATRIBUTOS

  • CONCEITUALMENTE, SÃO EQUIVALENTES A ASSOCIAÇÕES

    • "UMA PESSOA TEM UM NOME" PODE SER DITO NO CONTEXTO DE UMA ASSOCIAÇÃO OU NO CONTEXTO DE UM ATRIBUTO

  • NAS PERSPECTIVAS DE ESPECIFICAÇÃO OU IMPLEMENTAÇÃO, TEM DIFERENÇAS:

    • UM ATRIBUTO IMPLICA NAVEGABILIDADE APENAS DO TIPO PARA O ATRIBUTO (E NÃO VICE VERSA)

    • O ATRIBUTO FAZ PARTE DE CADA INSTÂNCIA DA CLASSE E TEM PORTANTO SEMÂNTICA DE "VALOR" E NÃO DE "REFERÊNCIA" (NÃO É COMPARTILHADO)

  • SINTAXE UML

    • VISIBILIDADE NOME: TIPO = VALOR-DEFAULT

    • VISIBILIDADE: + (PÚBLICO), # (PROTECTED), - (PRIVADO)

      • A SEMÂNTICA DISSO NÃO ESTÁ DEFINIDA

      • NÃO DEPENDA MUITO DISSO, PORTANTO!

      • SE QUISER USAR, USE A SEMÂNTICA DA LINGUAGEM SENDO USADA

• OPERAÇÕES

  • SÃO OS PROCESSOS QUE UMA CLASSE SABE EXECUTAR

  • CORRESPONDEM TIPICAMENTE A MÉTODOS DA CLASSE

  • NA PERSPECTIVA DE ESPECIFICAÇÃO, CORRESPONDEM AOS MÉTODOS PÚBLICOS DE UM TIPO

  • NORMALMENTE NÃO INCLUI "ACESSOR/MUTATOR METHODS" DE ATRIBUTOS, POR SEREM IMPLÍCITOS

    • MAS ATRIBUTOS IMUTÁVEIS (READ-ONLY) DEVEM SER INDICADOS

  • NUM MODELO DE IMPLEMENTAÇÃO, PODE MOSTRAR OPERAÇÕES PRIVADAS E PROTECTED

  • SINTAXE UML PARA OPERAÇÕES:

    • VISIBILIDADE NOME(LISTA-DE-PARÂMETROS): TIPO-DE-RETORNO

    • LISTA-DE-PARÂMETROS TEM A MESMA SINTAXE DE ATRIBUTOS

  • EM MODELOS CONCEITUAIS (DE ANÁLISE), OPERAÇÕES NÃO DEVERIAM ESPECIFICAR A INTERFACE DE UMA CLASSE MAS SUAS RESPONSABILIDADES

    • RESPONSABILIDADES SÃO FREQUENTEMENTE DESCOBERTAS USANDO CRC CARDS

    • CRC = CLASS-RESPONSIBILITY=COLLABORATION

    • CRC CARDS INVENTADAS PORD WARD CUNNINGHAM E KENT BECK (TEKTRONIX)

    • USA CARDS PEQUENOS (PARA SÓ ESCREVER O ESSENCIAL) PARA DESCREVER CLASSES

    • AO USAR CRC CARDS, SÓ PENSE NAS RESPONSABILIDADES DE ALTO NÍVEL

    • MAIS DETALHES aqui:

      • Designing Object-Oriented Software; Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.

• GENERALIZAÇÃO

  • SEMELHANÇAS ENTRE CLASSES SÃO COLOCADAS NUMA SUPERCLASSE, MAIS GERAL

  • AS SUBCLASSES ESPECIALIZAM A SUPERCLASSE

  • EXATAMENTE COMO HERANÇA JÁ VISTA EM CAPÍTULOS ANTERIORES

    • ESTRITAMENTE FALANDO, HERANÇA SE APLICA APENAS A LINGUAGENS DE PROGRAMAÇÃO PORQUE SUBCLASSES HERDAM COISAS DA SUPERCLASSE

  • LEMBRE QUE HERANÇA É UM RELACIONAMENTO DO TIPO "É UM"

    • NA FIGURA ACIMA, HEADQUARTERS "É UM" OFFICE

    • TUDO QUE PODE SER DITO SOBRE UM OFFICE TAMBÉM É VERDADE DE UM HEADQUARTERS

  • TENHA CUIDADO AO APLICAR A FRASE "É UM" AO TESTAR A HERANÇA "NA SUA CABEÇA"

    • EXEMPLO:

      • BIDU É UM CACHORRO

      • BIDU É UM PASTOR ALEMÃO

      • PASTOR ALEMÃO É UMA RAÇA

      • POR TRANSITIVIDADE, BIDU É UMA RAÇA (ERRADO)

    • O PROBLEMA É A MISTURA DE "É UM" COMO CLASSIFICAÇÃO (O OBJETO BIDU É UMA INSTÂNCIA DO TIPO PASTOR ALEMÃO) E "É UM" COMO GENERALIZAÇÃO (O TIPO PASTOR ALEMÃO É UM SUB-TIPO DO TIPO RAÇA)

      • GENERALIZAÇÃO É TRANSITIVA, CLASSIFICAÇÃO NÃO O É

    • MELHOR USAR "CADA INSTÂNCIA DE XXX É UMA INSTÂNCIA DE YYY"

  • TEM UMA DIFERENÇA BÁSICA ENTRE GENERALIZAÇÃO NA PERSPECTIVA DE ESPECIFICAÇÃO (SUB-TYPING OU HERANÇA DE INTERFACE) E NA PERSPECTIVA DE IMPLEMENTAÇÃO (SUB-CLASSES OU HERANÇA DE IMPLEMENTAÇÃO)

    • SUB-TYPING É O CONCEITO MAIS GERAL E IMPORTANTE

    • SUB-TYPING (ESTENDER UM TIPO) PODE SER FEITO COM SUB-CLASSES (HERANÇA DE IMPLEMENTAÇÃO) OU COM COMPOSIÇÃO/DELEGAÇÃO

    • VEREMOS DETALHES DISSO NUM CAPÍTULO POSTERIOR

• RESTRIÇÕES (CONSTRAINTS)

  • USAM A SINTAXE { ... }

  • VER { SUBSET } NA FIGURA ACIMA

• AGREGAÇÃO

  • SEMELHANTE A ASSOCIAÇÃO, MAS AGREGAÇÃO É DIFERENTE DE ASSOCIAÇÃO PORQUE O OBJETO "POSSUI" OU "É RESPONSÁVEL" PELOS OBJETOS AGREGADOS

    REPRESENTA UMA RELAÇÃO "PARTE DE" (A "É PARTE" B)

    MESMO ASSIM, OS EXPERTS NÃO CONCORDAM SEMPRE (O RELACIONAMENTO ENTRE UMA EMPRESA E SEUS EMPREGADOS É AGREGAÇÃO? COAD ACHA QUE SIM E RUMBAUGH ACHA QUE NÃO)

• COMPOSIÇÃO OU (AGREGAÇÃO COMPOSTA)

  • É COMO AGREGAÇÃO MAS APENAS O OBJETO PRINCIPAL CONTÉM OS AGREGADOS

  • O OBJETO PRINCIPAL E SEUS AGREGADOS TÊM O MESMO TEMPO DE VIDA

  • OPERAÇÕES NO OBJETO PRINCIPAL SE APLICAM NORMALMENTE A TODOS OS OBJETOS AGREGADOS

    "CASCADING OPERATIONS"

  • EXEMPLO: CLONE DO OBJETO PRINCIPAL VAI CLONAR OS AGREGADOS

  • EXEMPLO: REMOÇÃO DO OBJETO PRINCIPAL VAI REMOVER OS AGREGADOS

• DIFERENÇAS ENTRE AGREGAÇÃO E COMPOSIÇÃO

  • CONSIDERE POLIGONOS E CIRCULOS, AMBOS TENDO UM RELACIONAMENTO COM PONTOS E ESTILOS

    • UM POLIGONO TEM 3 OU MAIS PONTOS

    • UM CÍRCULO É DEFINIDO POR UM PONTO (E OUTRAS COISAS)

    • AMBOS TÊM UM ESTILO

    • A COMPOSIÇÃO MOSTRA QUE UM PONOTO PERTENCE A UM POLÍGONO OU A UM CÍRCULO, MAS NÃO AMBOS

    • PORÉM, ELES PODEM COMPARTILHAR UM ESTILO

    • REMOVER UM POLÍGONO OU CÍRCULO REMOVE OS PONTOS MAS NÃO O ESTILO!

• INTERFACES

  • DUAS NOTAÇÕES: COMPLETA E RESUMIDA

DIAGRAMAS DE OBJETOS

• CAPTURAM INSTÂNCIAS E LINKS

• ILUSTRAM ESTRUTURAS DE DADOS

• PODEM SER USADOS NA ANÁLISE MAS SÃO MAIS COMUNS DURANTE O PROJETO

DIAGRAMAS DE COMPONENTES

• PARA CAPTURAR A ESTRUTURA FÍSICA DA IMPLEMENTAÇÃO

  • PODE SER USADO NA ESPECIFICAÇÃO DA ARQUITETURA

  • RARAMENTE USADO

• PODE SER USADO PARA:

  • ORGANIZAR CÓDIGO FONTE

  • CONSTRUIR UM RELEASE EXECUTÁVEL

  • ESPECIFICAR UM BANCO DE DADOS FÍSICO

DIAGRAMAS DE DEPLOYMENT

• PARA CAPTURAR A TOPOLOGIA DO HARDWARE DO SISTEMA

  • PODE SER USADO NA ESPECIFICAÇÃO DA ARQUITETURA

  • RARAMENTE USADO

DIAGRAMAS DE SEQUÊNCIA

• PARA CAPTURAR O COMPORTAMENTO DINÂMICO EVIDENCIANDO O TEMPO

  • MODELA O FLUXO DE CONTROLE

  • ILUSTRA CENÁRIOS TÍPICOS

• IMPORTANTE PORQUE A COISA MAIS DIFÍCIL A ENTENDER NUM SISTEMA OO COM CENTENAS DE PEQUENAS CLASSES É O FLUXO DE CONTROLE

• RETURNS NORMALMENTE NÃO MOSTRADOS PORQUE SÃO ÓBVIOS

• USADOS PARA EXAMINAR O COMPORTAMENTO DE VÁRIOS OBJETOS DO MESMO USE CASE

DIAGRAMAS DE COLABORAÇÃO

• PARA CAPTURAR O COMPORTAMENTO DINÂMICO EVIDENCIANDO AS MENSAGENS E AS A COORDENAÇÃO ENTRE OBJETOS

• DIAGRAMAS DE SEQUÊNCIA SÃO MAIS USADOS PORQUE CAPTURAM MELHOR O ASPECTO TEMPO

• O ASPECTO TEMPO (SEQUÊNCIAMENTO) É DIFÍCIL DE VER NOS DIAGRAMAS DE COLABORAÇÃO

• CAPTURAR DECISÕES (COMPORTAMENTO CONDICIONAL) EM AMBOS OS DIAGRAMAS É UM POUCO DIFÍCIL

  • USE VÁRIOS DIAGRAMAS PARA MOSTRAR AS SITUAÇÕES DIFERENTES

  • DIAGRAMAS QUE FICAM COMPLEXOS RAPIDAMENTE PERDEM SUA UTILIDADE

• USADOS PARA EXAMINAR O COMPORTAMENTO DE VÁRIOS OBJETOS DO MESMO USE CASE

DIAGRAMAS DE ESTADO

• PARA CAPTURAR O COMPORTAMENTO DINÂMICO EVIDENCIANDO OS EVENTOS

  • ADEQUADOS PARA MODELAR O CICLO DE VIDA DE UM ONJETO QUANDO ESTE CICLO É COMPLEXO

  • MODELA OBJETOS REATIVOS (INTERFACES COM O USUÁRIO, DISPOSITIVOS)

• USADOS PARA EXAMINAR O COMPORTAMENTO DE UM OBJETO AO LONGO DE VÁRIOS USE CASES

DIAGRAMAS DE ATIVIDADE

• PARA CAPTURAR O COMPORTAMENTO DINÂMICO EVIDENCIANDO AS ATIVIDADES

• BONS PARA MODELAR WORKFLOWS, ONDE PODE HAVER BASTANTE PARALELISMO

• NÃO MOSTRAM QUE CLASSES SÃO REPONSÁVEIS POR QUAL ATIVIDADE

  • PODE USAR SWIMLANES PARA EVIDENCIAR ISSO

• USADOS PARA EXAMINAR O COMPORTAMENTO DE UM OBJETO AO LONGO DE VÁRIOS USE CASES E/OU VÁRIOS THREADS

USO DE PACKAGES

• PODE SER USADO COM QUALQUER DIAGRAMA PARA EMPACOTAR E REDUZIR A COMPLEXIDADE

• NENHUM DIAGRAMA DEVE SER MAIOR QUE UMA FOLHA

• DIAGRAMAS COM PACKAGES EVIDENCIAM A ARQUITETURA, OS AGRUPAMENTOS E SUBSISTEMAS (PACKAGES) E AS DEPENDÊNCIAS ENTRE SUBSISTEMAS

caso2.htm programa anterior próxima