Slides da Aula T05 by wuxiangyu

VIEWS: 9 PAGES: 69

									                       Modelação

                   Aula T05
           Engenharia de Requisitos
          Modelos Estrutural e Dinâmico

Referências:
  – Conceptual Modeling of Information Systems (Capítulos 1.4, 2 e 3)
  – UML, Metodologias e Ferramentas CASE (Capítulos 4 e 5)


                           José Borbinha
                               Programa
T01-T03 – Módulo 1
    – Introdução à Modelação de Sistemas            "Je n'ai fait celle-ci plus
T04-T07 – Módulo 2
                                                    longue que parce que je
    – Modelação Conceptual de Sistemas              n'ai pas eu le loisir de la
       • T05                                        faire plus courte".
              – Engenharia de Requisitos             (Pascal - 16ª Provinciale)
              – Modelo Estrutural
                 » Modelo de Domínio (introdução)
              – Modelo de Dinâmica
                 » Casos de Uso
                                                    ...Escrevi esta carta longa
                                                    porque não tive tempo de
T08-T11 – Módulo 3
    – Ontologias
                                                    a escrever mais curta...
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
                                                    Mas o que é que isto tem a
    – Temas avançados                               ver com a matéria de hoje?



                                      Modelação                                  2
Engenharia de
 Requisitos

     Modelação   3
    Engenharia de Requisitos

1. O Processo de Eng.ª de Requisitos
2. Levantamento de Requisitos
3. Análise de Requisitos
4. Negociação de Requisitos


                   Modelação           4
                 Sobre Requisitos
• Um requisito é uma condição ou restrição sobre um serviço
  ou sistema.
   – Um requisito errado significa, mais tarde ou mais cedo, problemas no
     projecto (erros, atrasos, ...).

• Engenharia de requisitos é o processo (conjunto estruturado
  de actividades) que envolve um levantamento de requisitos
   – Não há processos ideias, mas há técnicas já provadas que se podem
     usar em algumas situações típicas (a ver adiante...)

• O custo de um processo de levantamento de requisitos
  depende da natureza do problema e da metodologia usada,
  mas pode ser bastante substancial e nunca deve ser
  desprezado!!!
   – O resultado de um processo de levantamento de requisitos é
     geralmente um “Documento de Requisitos” (a ver adiante...)

                               Modelação                                    5
          Principais tipos de requisitos
• Requisitos funcionais (RF) dizem o que é que o sistema deve fazer...
   Exemplos:
   – Deve ser possível obter os nomes de todos os clientes numa lista
     ordenada alfabeticamente.
   – Sempre que é emitida uma factura deve ser enviado um email para o
     responsável financeiro da organização
   – Deve ser mantido um registo para todas as operações de alterações de
     dados dos últimos 30 dias.

• Requisitos não funcionais (RNF) dizem como é que o sistema deve
  ser feito e deve funcionar...
   Exemplos:
   – A apresentação da lista ordenada dos nomes de todos os clientes não
     deve demorar mais do que 1 segundo.
   – Todas as interfaces de utilizador devem ser apresentadas em Português e
     em Inglês
   – O sistema de gestão de base de dados deve ser o MySQL
   – Todo o sistema deve ser programado em Java, para ambiente Linux ou
     Windows


                                 Modelação                                  6
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            Análise de             Documentação          Validação dos
           requisitos             Requisitos e            dos Requisitos         Requisitos
         (“elicitation”)          Negociação


                                                                     Documento de
                                                                      Requisitos



                                                                    Especificação do
                                                                       Sistema...

                                              Modelação                                         7
Utilizadores do Documento de Requisitos
• Clientes do sistema
   – Especificam ou validam os requisitos
• Gestores de projecto
   – Planeamento de custos e prazos para o processo de
     desenvolvimento
• Engenheiros de sistemas e desenvolvimento
   – Entendimento do sistema a desenhar e desenvolver
• Equipas de teste do sistema
   – Usam os requisitos para desenvolver teste de validação
• Equipas de manutenção do sistema
   – Usam os requisitos para o melhor compreender



                            Modelação                         8
O standard IEEE/ANSI 830-1993 propõe uma estrutura
      para documentos de requisitos de software
1. Introdução
    1.1 Propósito do documento 1.2 Contexto do produto
    1.3 Definições, acrónimos e abreviaturas
    1.4 Referências
    1.5 Visão geral do documento
2. Descrição geral
    2.1 Perspectiva do produto
    2.2 Funções do produto
    2.3 Características dos utilizadores
    2.4 Restrições gerais
    2.5 Assunções e dependências
3. Requisitos específicos
        Este ponto aparece tipicamente estruturado em requisitos
                funcionais e em requisitos não funcionais...
4. Apêndices


                              Modelação                            9
Classificação de Requisitos Não Funcionais
     segundo o IEEE-Std 830 – 1993

•   Requisitos de desempenho
•   Requisitos de interface            Em cada projecto
•   Requisitos operacionais
•   Requisitos de recursos
                                       concreto devem
•   Requisitos de verificação          ser usadas as
•   Requisitos de aceitação            classes que se
•   Requisitos de documentação         considerem
•   Requisitos de segurança
•   Requisitos de portabilidade        relevantes...
•   Requisitos de qualidade
•   Requisitos de fiabilidade
•   Requisitos de manutenção

                           Modelação                  10
Mais exemplos de Requisitos Funcionais
  (do livro “Systems analysis and design with UML”)




                       Modelação                      11
Mais exemplos de Requisitos Não Funcionais
    (do livro “Systems analysis and design with UML”)




                        Modelação                       12
Níveis de Maturidade do processo de Engenharia
        de Requisitos numa organização
• Nível inicial (Initial level)
   – Não se reconhece o problema ou pensa-se que o mesmo não
     se aplica. Não existe processo. Risco de problemas de
     volatilidade de requisitos e custos elevados de alterações. O
     sucesso da actividade é muito dependente da capacidade e
     experiência individual das pessoas.

• Nível Repetitivo (Repeatable level)
   – Reconhecimento do problema e vontade de lidar devidamente
     com ele. São definidas normas para os documentos de
     requisitos e para os procedimentos de gestão de requisitos,
     geralmente copiando ou adaptando modelos exteriores.

• Nível Definido (Defined level)
   – O processo está definido com base em boas práticas,
     existindo uma preocupação na melhoria activa do processo. O
     processo é visto como uma vantagem competitiva da
     organização.
                              Modelação                              13
    Engenharia de Requisitos

1. O Processo de Eng.ª de Requisitos
2. Levantamento de Requisitos
3. Análise de Requisitos
4. Negociação de Requisitos


                   Modelação           14
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            Análise de             Documentação          Validação dos
           requisitos             Requisitos e            dos Requisitos         Requisitos
         (“elicitation”)          Negociação


                                                                     Documento de
                                                                      Requisitos



                                                                    Especificação do
                                                                       Sistema...

                                              Modelação                                     15
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              16
                 Questionários
• Relevante num cenário
   – Com muitos utilizadores conhecedores profundos do negócio
     e já com processos de negócio estabelecidos (mesmo que
     não formalizados),
   – Em que há uma percepção da necessidade do sistema, mas
     há ainda pouco conhecimento consolidado sobre os seus
     requisitos, especialmente funcionais.

• Processo
   – Seleccionar participantes (representativos dos stakeholders)
   – Definir questionário (selecção cuidada das questões)
   – Administrar o questionário (definir estratégias para obter
     respostas em bom número e de qualidade)
   – Follow-up do questionário (enviar os resultados do
     questionário aos participantes, para validação, ainda que
     implícita, e reconhecimento pelo papel dos mesmos)
                            Modelação                               17
       Análise de Documentos
• Relevante num cenário em que já há processos
  de negócio bem estabelecidos ou mesmo já
  sistemas instalados (cenário “as-is”) que se
  pretendem substituir (cenário “to-be”)

• Documentos típicos:
   – Formulários
   – Relatórios
   – Manuais de procedimento
• Procurar documentos e práticas de uso dos mesmos
  menos usuais (formulários, procedimentos locais, ...)
                          Modelação                       18
                      Entrevistas
• Relevante quando os requisitos dependem de um
  número relativamente pequeno e bem identificado de
  utilizadores ou decisores bastante especializados mas
  ao mesmo tempo com perspectivas diferenciadas.

• Adequada a cenários com orgânicas rígidas

• Planeamento
   – Documentar-se e ler material de suporte
   – Estabelecer claramente os objectivos da entrevista
   – Decidir quem entrevistar (cuidado com as hierarquias)
   – Avisar antecipadamente o entrevistado (dando-lhe a
     possibilidade de se preparar devidamente)
   – Decidir cuidadosamente os tipos de questões e a sua estrutura
                             Modelação                               19
     Joint Application Design (JAD)
• Técnica relevante quando se pretende algo de novo mas os
  requisitos dependem de um conjunto alargado de classes de
  utilizadores ou decisores
• Adequada a cenários de organizações horizontais ou em que a
  cultura organizacional suporta a resolução de problemas em grupo
• Processo:
   – Organizar entre 2 a 3 sessões de um dia fora do local do trabalho para
     minimizar interferências. Planear ambiente funcional, com comida e
     bebidas
   – Só realizar as reuniões se todos os participantes podem estar
     presentes. Um dos participantes deve registar o conteúdo da sessão
• Participantes:
   – Pelo menos 1 analista e 1 ou 2 técnicos especializados, que devem ter
     papéis passivos (contribuição reservada para a análise)
   – 1 moderador, escolhido com base no seu poder de comunicação, não
     devendo ser o analista. O supervisor directo do moderador deve
     pertencer ao grupo
   – 8 a 12 utilizadores
   – Um executivo de topo de aparecer como patrocinador, introduzindo
     concluindo a sessão
                                 Modelação                                20
      Análise comparativa da JAD
                                     • Riscos
• Vantagens
                                           – Exige que os vários
  – Menos 15% do tempo em                    participantes tenham tempo
    comparação com as                        disponível para todas as
    entrevistas individuais                  sessões
  – Permite desenho criativo e             – Exige grande esforço de
    desenvolvimento rápido                   preparação (ou a sessão pode
  – Os utilizadores sentem-se                não ter sucesso)
    integrados no                          – Se o relatório de uma sessão
    desenvolvimento do sistema               estiver incompleto pode por em
  – Permite ao analista efectuar o           risco a próxima sessão
    levantamento de requisitos             – Cultura organizacional pode
    com os utilizadores                      não ser na realidade
                                             compatível com a JAD



                               Modelação                                21
Já agora, a galeria das “figurinhas” difíceis: Esta relação pode ser apresentada no início da
      primeira reunião JAD, após as apresentações, a fim de inibir tais procedimentos...
               http://blog.nicholas.eti.br/2006/06/23/jad-joint-application-design/

O Atrasadinho
    - Sempre chega atrasado. Dá seu “show” na chegada.
O que sai mais cedo
    - Abala a energia e a moral do grupo.
O Ampulheta
    - “Joga areia” em todas as ideias.
    - Sempre esfriando o entusiasmo do grupo, dizendo algo como “isso nunca vai funcionar”.
O desinteressado
    - Senta afastado da mesa ou no fundo da sala.
    - Pode cochilar, ler alguma coisa, ficar rabiscando papéis.
O disco quebrado
    - Traz de volta sempre o mesmo ponto.
    - Dificulta o avanço do grupo para novos itens.
O cochichador
    - Vive cochichando durante as reuniões, mantendo conversas paralelas.
O Rei da Voz
    - Fala muito e excessivamente alto. Domina a discussão.
    - Parece impossível fazê-lo calar.
O Intérprete
    - Sempre fala por outra pessoa, normalmente sem ser solicitado.
    - Recoloca ideias alheias distorcendo-as durante sua explanação.
O Móveis e Utensílios
    - Usa credencias como idade e tempo de casa para fazer prevalecer suas ideias.
O Ocupado
    - Sempre entrando e saindo das reuniões com papéis debaixo do braço.
    - Permite que seja chamado frequentemente por secretárias e subordinados.
    - Tenta dar a impressão de muito ocupado e portanto, muito importante.
                                         Modelação                                              22
                          Etnografia
• Técnica desenvolvida na área das ciências sociais. Relevante
  quando já existem processos em prática mas é difícil
  descrever como que se realizam. A solução é observar como
  as tarefas são realizadas e tentar depois fazer o “reverse
  engineering” dos processos.

• Permite detectar divergências entre os métodos de trabalho
  usados e a sua definição formal

• Processo:
   –   Procurar métodos de trabalho pouco usuais
   –   Estabelecer uma relação de confiança com os utilizadores
   –   Manter notas detalhadas sobre os métodos de trabalho.
   –   Combinar observação com entrevistas abertas
   –   Organizar sessões regulares de esclarecimento
   –   Só por si esta técnica é insuficiente, pelo que se devem usar
       sempre outras técnicas como complemento
                                 Modelação                             23
                        Prototipagem
• Protótipos são versões iniciais de um sistema para experimentação
  que devem estar disponíveis durante o levantamento de requisitos.
• Técnica relevante quando é necessário testar provas de conceito
  (especialmente em cenários de grande inovação), especialmente
  quando o resultado final depende bastante de pormenores de
  interface.
• Processos
    – Protótipos “throw-away”: ajudam ao levantamento e desenvolvimento
      dos requisitos difíceis de perceber
    – Protótipos Evolutivos: desenvolvimento rápido de uma versão inicial do
      sistema, especialmente quando já há requisitos bem definidos e
      aceites
• Os protótipos podem ser feitos na mesma tecnologia do sistema
  final (protótipos evolutivos), ou noutra tecnologia mais adequada a
  fins de curto prazo (especialmente para protótipos “throw-away”)

                                  Modelação                                24
Prototipagem em papel,,,




          Modelação        25
    Casos de Uso (ver continuação adiante...)
•   A técnica de casos de uso ajuda a capturar os requisitos de um
    sistema através do detalhe de todos os cenários de interacção do
    sistema com o seu exterior.
•   O resultado de um processo de desenho de casos de uso deve ser um
    conjunto de diagramas (tipicamente em UML, representando-se mais
    que um caso em cada diagrama) e um conjunto de descrições textuais
    (uma para cada caso)
•   Um caso de uso deve ser representado num modo impessoal, por uma
    frase na voz activa, com um verbo no infinitivo (“Registar Cliente”, “Emitir
    Factura”, “Efectuar Compra”, ...)
•   Os casos podem ser usados como técnica de levantamento de requisitos, e
    depois mais tarde também para fazer a ponte entre os requisitos e a
    modelação do comportamento de um sistema (tipicamente o desenho do
    modelo da dinâmica de um sistema começa com a análise dos seus casos
    de uso)
•   Por ser mais genérica, a descrição dos casos de uso pode aparecer na
    documentação de requisitos, antes da enunciação dos mesmos (na
    descrição geral do sistema), para ajudar ao entendimento do contexto.
                                   Modelação                                 26
    Engenharia de Requisitos

1. O Processo de Eng.ª de Requisitos
2. Levantamento de Requisitos
3. Análise de Requisitos
4. Negociação de Requisitos


                  Modelação            27
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            Análise de             Documentação          Validação dos
           requisitos             Requisitos e            dos Requisitos         Requisitos
         (“elicitation”)          Negociação


                                                                     Documento de
                                                                      Requisitos



                                                                    Especificação do
                                                                       Sistema...

                                              Modelação                                     28
        Análise de Requisitos

• O objectivo é 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




                   Modelação              29
     Lista típica de verificação de requisitos
• Para cada requisito concreto aplicar verificação:
  – Desenho prematuro: Verificar se inclui informação prematura sobre o
    design ou a implementação
  – Detalhe: Verificar é um único requisito ou se o mesmo deve ser dividido em
    diferentes requisitos
  – Necessidade: Verificar se é apenas uma adição “cosmética” ao sistema.
  – Tecnologia não normalizada: Detectar se o requisito obriga ao uso de
    hardware ou outra tecnologia não “standard”.
  – Conformidade com os objectivos de negócio: Verificar se é consistente
    com os objectivos definidos na introdução do documento de requisitos
  – Ambiguidades: Verificar se o requisito pode ser lido de forma diferentes por
    diferentes pessoas e quais as interpretações possíveis?
  – Realismo: Verificar se o requisito é realista, especialmente tendo em conta
    o custo e a tecnologia a ser usada para implementar o sistema
  – Teste: Verificar se é possível derivar um teste a partir da descrição do
    requisito que mostre que o sistema satisfaz esse requisito


                                  Modelação                                 30
         Matrizes de Interacção
  • Técnica para determinar as interacções entre
    requisitos, evidenciando conflitos e sobreposições:
      – 0     => Requisitos independentes
      – 1     => Requisitos em conflito (contraditórios)
      – 1000 => Requisitos sobrepostos (dizem a mesma
        coisa, total ou parcialmente)



Requirement     R1      R2       R3       R4       R5       R6
    R1           0       0      1000       0       1        1
    R2           0       0        0        0       0        0
    R3         1000      0        0      1000      0       1000
    R4           0       0      1000       0       1        1
    R5           1       0        0        1       0        0
    R6           1       0      1000       1       0        0


                             Modelação                            31
    Engenharia de Requisitos

1. O Processo de Eng.ª de Requisitos
2. Levantamento de Requisitos
3. Análise de Requisitos
4. Negociação de Requisitos


                   Modelação           32
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            Análise de             Documentação          Validação dos
           requisitos             Requisitos e            dos Requisitos         Requisitos
         (“elicitation”)          Negociação


                                                                     Documento de
                                                                      Requisitos



                                                                    Especificação do
                                                                       Sistema...

                                              Modelação                                     33
         Negociação de requisitos

• A negociação de requisitos tenta encontrar soluções de
  concordância. Pode ser um processo demorado, pois
  obriga a consensos

• Fases do Processo:
   – Informação: Explicar os problemas associados com os requisitos
     a negociar
   – Discussão: “Stakeholders” devem ter oportunidade de comentar
     os requisitos que lhes dizem respeito. Usar esta fase para
     atribuir prioridades aos requisitos
   – Resolução: Eliminar, alterar ou refinar o requisito


                             Modelação                           34
Sobre Linguagens
 de Modelação

Perspectiva Geral
       Modelação    35
      Relembrando da aula T04...

• O modelo de um domínio, do sistema, ou base de
  informação*, são as entidades e relações desse domínio
              *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
• Ao conjunto formado pelo esquema estrutural e pelo
  esquema de comportamento de um sistema dá-se o
  nome de esquema conceptual.

                             Modelação                                   36
  Diagrama de Classes dos diagramas da linguagem UML 2.0
                Comportamento e Estrutura




(http://www.omg.org/)     Modelação                   37
 Diagrama de Classes dos diagramas da linguagem
 SysML (subconjunto da UML com extensões para satisfazer requisitos
    de engenharia de sistemas.. voltaremos a isto nos módulos 5 e 6...)




                                 Modelação                                38
http://www.omgsysml.org/)
Diagrama de Classes dos diagramas da linguagem SysML




                       Modelação                   39
Modelo Estrutural

Modelo de Domínio

       Modelação    40
• Entidades e relações...
• o que se explicar aqui do modelo pode-se
  depois aproveitar para suportar o resto da
  conversa dos casos de uso (i.e., casos de
  uso são entidades e relações tal como nos
  diagramas de domínio...)



                   Modelação              41
    Modelação da Estrutura

• Uma visão pragmática:
 – Classes
 – Relações
 – Diagramas de Classes

 Nota: Adiante vamos apresentar uma
  explicação muito pragmática destes conceitos.
  Mais adiante no curso iremos voltar a este
  assunto para os formalizar melhor...
                   Modelação                 42
                        Classes
Uma classe representa um conceito ou
categoria de objectos que partilham:
– atributos (que determinam o estado dos objectos)
– operações (que definem o comportamento)



                                      Nome da classe
                     Pessoa
Estereótipo de
representação    Nome                    Atributo da classe
de uma classe    atribuirNome()
   em UML
                 retornarNome()       Operações da classe


                          Modelação                           43
      Uma classe bem estruturada

• Providencia uma abstracção definida a partir do
  vocabulário do domínio do sistema

• Agrega um conjunto restrito e bem definido de
  propriedades

• Providencia uma separação clara entre a
  especificação abstracta e a sua implementação

• É simples e facilmente entendida.

                        Modelação                   44
    Modelação da Estrutura

• Uma visão pragmática:
 – Classes
 – Relações
 – Diagramas de Classes




                  Modelação   45
                           Relações
• Uma relação é uma ligação entre elementos.
• Numa linguagem de modelação orientada a objectos os
  três tipos de relações mais importantes são:
    – Dependências
    – Generalizações
    – Associações
                             Relação

              Pessoa                         Carro
          Nome                          Modelo
          atribuirNome()                VelocidadeMax()
          retornarNome()                ConsumoMedio()



                            Modelação                     46
           Relações - Dependência
Uma dependência indica que a alteração na especificação de um
elemento (por exemplo, pacote “UML 0.9”) pode afectar outro elemento
que o usa (pacote “UML 1.0”) mas não necessariamente o oposto.




       Em UML as dependências são usadas entre normalmente com
                   packages, componentes e notas.

                             Modelação                                 47
                  Relações - Generalização
                                                         Shape

Uma generalização é uma relação                       origin
entre um elemento geral                               move()
(superclasse) e um tipo mais                          resize()
                                                      display()
específico desse elemento
(subclasse).


                                       Rectangle          Circle         Polygn
Geralmente conhecida como uma        corner: Point   radius: Float   points: List
relação “is-a” ou “is-a-kind-of”.


                                        Square


   No contexto de classes usam-se generalizações para ilustrar
                      relações de herança.

                                    Modelação                                  48
              Relações - Associação
Uma associação é uma relação semântica entre dois ou mais
elementos de um modelo.




  • Este exemplo lê-se:
      • Uma pessoa pode trabalhar para várias empresas (0 ou mais).
      • Numa empresa trabalham 1 ou mais pessoas.



                             Modelação                                49
             Relações - Associação
• Multiplicidade de uma associação
   – Define quantos objectos participam na relação
   – O número de instâncias de uma classe relacionadas com uma
     instância da outra classe
   – Especificada para cada participante (classe) da associação


                  Não especificada
                      Apenas uma         1

                      Zero ou mais       0..* ou apenas *

                      Uma ou mais        1..*

                      Zero ou uma        0..1

             Intervalo especificado      2..4

      Valores e intervalos múltiplos     2, 4..6

                             Modelação                      50
                        Relações – Associação
• Relações entre classes do tipo “is-part-of” ou “has-a” são representadas
  através de agregação.



    ... uma Pessoa
   pode existir sem
   uma Empresa...




• Uma composição é uma agregação forte ( “todo” em relação à “parte”) e
  com tempo de vida delimitado (as “partes” não podem existir sem o “todo”).
  O “todo” é responsável pela criação e destruição das suas “partes”.


        ... um
    Departamento
   não existe sem o
   contexto de uma
     Empresa...
                                   Modelação                                 51
Relações - Associação




        Modelação       52
              Relações – Associação...
• «Uma mesa é constituída por um tampo e por quatro pernas…»
• «Uma mesa é constituída por um tampo e por duas a seis pernas, as
  quais têm de estar ordenadas…»




                                                       Mesa
              Mesa
                                                  1         Ordem
          1            1
                                                  1            1
          1            4
                                               Tampo           2..6
      Tampo          Perna
                                                            Perna




                              Modelação                               53
         Relações - Associação
• Classes-Associação
   • Numa associação entre classes, a associação pode
     também ter as suas próprias propriedades, devendo ser,
     por conseguinte, modelada também como uma classe.

                 1..*                        *
      Pessoa                         empregador
                                                  Empresa
                empregado




                          Tarefa
                        descrição
                        dataInício                   classe associação
                        salário




                         Modelação                                       54
        Relações - Associações Reflexivas

  Quando uma classe tem uma associação consigo própria...


                *
Departamento                                     professor 1
               sub-departamento
    1                                              Docente     *
                                                               assistente


    “um departamento                      • “um docente, enquanto
    universitário pode                      professor, pode ser responsável
    conter outros                           por outros docentes, designados
    departamentos”                          por assistentes”
                                          • “um docente, enquanto
                                            assistente, está dependente de
                                            um outro docente, designado por
                                            professor”

                                  Modelação                                 55
    Modelação da Estrutura

• Uma visão pragmática:
 – Classes
 – Relações
 – Diagramas de Classes




                 Modelação   56
                  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.

• Elementos UML que são representados num diagrama
  de classes:
   – Classes e sua estrutura interna
   – Relações
      •   Tipos (Associações, Agregações, Dependências, Generalização)
      •   Multiplicidade
      •   Navegabilidade
      •   Nome da relação e papel de cada interveniente
      •   ....


                                Modelação                                57
Modelação   58
Modelação   59
 Modelo de
 Dinâmica

Casos de Uso
     Modelação   60
Organização de 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




• O caso de uso filho herda o comportamento e semântica do seu
  pai; o filho pode substituir especificações definidas no seu pai.

                               Modelação                              61
Casos de Uso - Generalização de Actores


                                           generalização
                                             de actores

                    Cliente

  Cliente Anónimo                Cliente VIP




                     Modelação                       62
          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                           63
     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”.


            Atribui lugar       «extend»
                                                 Atribui lugar
              à janela

                                 Modelação                                   64
           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                          65
     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
  Actor
                                                              Use Case
                                                                  A
                      Use Case            Actor
                          A
  Actor
                                   Modelação                                  66
Diagramas de Caso de Uso - Exemplo
                 A Máquina de Bebidas


                  Comprar Bebida

     Cliente




                    Repor Bebidas
    Agente do
    Fornecedor                          Dono




                   Retirar dinheiro
     Colector




                       Modelação               67
Diagramas de Caso de Uso – Exemplo com Inclusão

                        A Máquina de Bebidas


                            Comprar Bebida
          Cliente



                             Repor bebidas
        Agente do
                     «include»                             Dono
        Fornecedor
                       Abrir a                 «include»
                       Máquina
                                   «include»



                            Retirar dinheiro
         Colector
                                               Fechar a
                                 «include»
                                               Máquina



                                  Modelação                       68
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
                                     «include»          Abrir a
                                                        Máquina

                         Repor Bebidas
      Agente do             Extension Point                            Dono
      Fornecedor           encher prateleiras
                                                «include»
                        «extend»                            Fechar a
                   (encher prateleiras)
                                                            Máquina

                        Repor Bebidas
                      segundo as vendas



                                          Modelação                           69

								
To top