• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Uml in Action
 

Uml in Action

on

  • 4,682 views

Como fazer bom uso da UML? É necessário fazer os 13 diagramas para modelar um sistema?

Como fazer bom uso da UML? É necessário fazer os 13 diagramas para modelar um sistema?
Como fazer um bom diagrama de classes?

Statistics

Views

Total Views
4,682
Views on SlideShare
4,661
Embed Views
21

Actions

Likes
10
Downloads
0
Comments
0

1 Embed 21

http://www.slideshare.net 21

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Uml in Action Uml in Action Presentation Transcript

    • www.braxis.com.br www.cpm.com.br www.cpminternational.com UML in Action by Roger Camargo
    • Como fazer bom uso da UML ? É necessário fazer os 13 diagramas para modelar um sistema ? Como fazer um bom diagrama de classes ? Com o objetivo de responder estas perguntas e mostrar que UML não é documentação. Este pequeno curso mostra a modelagem Estática e Dinâmica aplicada para modelar sistemas com um mínimo de diagramas, porém diagramas úteis. Agenda: - Motivações, - UML e Orientação a Objetos - Objetivos da UML - Uma imagem vale mais que mil palavras - Use apenas o que você precisa - Parte Estática (Diagrama de Casos de Uso, Seqüência e Classes Estático) - Parte Dinâmica (Diagrama de seqüências, Classes dinâmico, Estados e Atividades)
      • Motivações
      - Pouca atualização da documentação - Não separação da modelagem estática/dinâmica - Confusão de UML com Unified Process - Documentar com uma linguagem expressiva e universal
      • Um pouco sobre
      • Ciclo de Desenvolvimento
      • Ciclo desenvolvimento (Visão Resumida)
      Stackeholders Sistema Legado Artefatos sobre o sistema Requisitos Definição Requisitos Analise Requisitos Concepção Extração de requisitos Projeto de Sistemas Especificação Requisitos Elaboração Implementação Código Construção
      • Ciclo desenvolvimento (Visão Resumida)
      1) Elaboração 2) Concepção 3) Construção
      • Ciclo desenvolvimento (Visão Resumida)
      Uma das dificuldades no desenvolvimento de software é: Entendimento dos Requisitos
      • O que dificulta ainda mais?
      • Complexidade de Software
      - Sistemas de software são intrinsecamente complicados - Os requisitos modernos tendem a complicá-lo cada vez mais Alta confiabilidade Alto desempenho Qualidade ...
    • Com a ocorrência de:
      • - Dificuldade de entendimento dos requisitos
      • - Sistemas mais complexos
      • - Alta rotatividade de desenvolvedores
      • - Equipe com baixo conhecimento
      • - Falta de comunicação
      Necessidade de Documentação Modelagem
      • O que pode ser utilizado
      • para modelar um sistema ?
      • Definição da UML
      • 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
    • UML é uma ferramenta de análise
      • Traduzir requisitos em componentes do software
      • ( design ou modelagem )
    • Modelagem com UML ... - Auxilia o desenvolvimento de software, desde o seu planejamento até a implantação - Permite corrigir erros antecipadamente, deixando a implementação mais segura e objetiva
    • Iniciou em 94 pela recém criada Rational Software Corporation Tornou-se padrão do Object Management Group em 97 Se popularizou após a criação do RUP em 98
      • Histórico
      • Objetivos
      - Modelar sistemas usando conceitos de OO de maneira padronizada - Estabelecer a conexão entre elementos, desde o modelo conceitual até a implementação física.
      • Onde utilizar UML?
      - Análise de requisitos - Análise O.O. - Projeto O.O. - Implementação - Teste (Domínio do Problema) (Domínio da Solução) Concepção Elaboração Construção Escopo da apresentação
      • “ Uma imagem vale mais que mil palavras ”
      • Como ajudar
      • ainda mais ?
      • Diagramas de Comportamento
      • Diagrama de Caso de Uso
      • Diagrama de atividade
      • Diagrama de transição de estados
      • Diagramas da UML:
      • Diagramas de Interação
      • Diagrama de seqüência
      • Diagrama de colaboração
      • Diagrama de tempo
      • Diagrama de Interatividade
      • Diagrama de objetos
      • Diagramas de Estrutura
      • Diagrama de classes
      • Diagrama de componentes
      • Diagrama de estrutura composição
      • Diagrama de pacotes
      • Diagrama de instalação
      Devemos utilizar todos os diagramas ?
    • Bom Uso da UML . . .
      • Não existe um conjunto certo de diagramas
      • Modelar apenas o necessário
      • Não duplicar informações
      • Criar diagramas que serão utilizados
      • Bom uso da UML
      Concepção Escopo da apresentação
      • Bom uso da UML
      -Utilizar na maneira correta a elaboração dos documentos -Criar o mínimo necessário (apenas diagramas úteis para o projeto atual)
    •  
    •  
    •  
    •  
      • Bom uso da UML - Sugestão de uso:
      -Parte 1 - Estático 1.1 - Diagrama de Casos de Uso 1.2 - Diagrama de Seqüência (de sistema) 1.3 - Diagrama de Classes Estático -Parte 2 - Dinâmico 2.1 - Diagrama de Seqüência 2.2 - Diagrama de Classes Dinâmico 2.3 - Diagrama de Estados 2.4 - Diagrama de Atividades UC DS s DC e DE DS DC d DA Estático Dinâmico
    • Primeira Parte: Modelagem Estática
    • UC DSs DC e DE DS DCd DA 1.1 1.1 - Diagrama de Casos de Uso Requisitos Estático Dinâmico
      • 1 - Diagrama de Casos de Uso
      Objetivos Principais • Delimitação do contexto de um sistema • Documentação e o entendimento dos requisitos • Descreve os requisitos funcionais • Principal saída da etapa de especificação de requisitos • Principal entrada da etapa de análise Objetivos Secundários • Facilita a comunicação entre os “stakeholders” • É base para a definição do cronograma • Auxilia a elaboração dos casos de teste • Auxilia nas estimativas
      • Complexidade de Software
      - Ponte entre Requisitos e Análise: Especificação Do Sistema Escopo do Projeto Requisitos dos stakeholders Cronograma Atividades ?
      • Exemplo: Diagrama de Casos de Uso
      Ator Caso de Uso
      • Exemplo: Diagrama de Casos de Uso
    • UC DSs DC e DE DS DCd DA 1.2 1.2 - Diagrama de Seqüência (de sistema) Requisitos Estático Dinâmico
      • 1.2 - Diagrama de Seqüência (de sistema)
      Objetivos Principais • Detalhar os casos de uso • Determinar a ordem das atividades Objetivos Secundários • Facilitar a geração dos diagramas de seqüências finais • Determinar quais atividades deverão possuir diagramas de atividades
      • Complexidade de Software
      - Descrição visual de uma funcionalidade Especificação Do Sistema Requisitos dos stakeholders Diagrama de Seqüência Descrição casos de uso Diag. Seqüência detalhado Diag. Colaboração
      • Exemplo: Diagrama de Seqüência (Sistema)
      Candidato a ser detalhado
    • UC DSs DCe DE DS DCd DA 1.3 1.3 - Diagrama de Classe Estático Requisitos Estático Dinâmico
      • 1.3 - Diagrama de Classes (estático)
      Objetivos Principais • Complementar as descrições dos casos de uso • Encontrar classes de análise • Distribuir comportamento entre as classes de análise • Descrever responsabilidades • Descrever atributos • Estabelecer associações entre classes de análise.
      • Atividades para criar um DC
      Substantivos Classes Atributos
    • i) Extrair classes candidatas
      • Atividades para criar um DC: 1 – Criar classes de análise
      processo de empréstimo empréstimo terminal publicação emprestado tese número de tombo período de empréstimo dias banco de dados proibição exemplares cliente sistema disponível livro manual código do cliente tipo de usuário alunos informação cópias biblioteca atendente sistema de cadastro suspenso periódico número de registro status do cliente usuário professores período ii) Eliminar classes inapropriadas
    • Pode-se criar um descritivo de cada classe Livro: Representa um título de um livro Exemplar: Representa cada exemplar físico de um livro
      • Atividades para criar um DC: 2 – Dicionário de dados
    • 1 – identificar agregações 2 – identificar associações 3 – identificar heranças
      • Atividades para criar um DC: 3 – Criar Relacionamentos
      • Atividades para criar um DC: 4 – Identificar e refinar atributos
    • Exemplo: Refinamento com MVC
      • Atividades para criar um DC: 5 – Iterar e refinar
    • Segunda Parte: Modelagem Dinâmica
      • Identifica e modela os aspectos do sistema de software que podem mudar durante a sua execução, devido à ocorrência de eventos .
      • Foco no comportamento que o sistema deve apresentar.
      Como fazer? -Deve ser realizada uma nova análise textual nas especificações dos casos de uso, prestando-se atenção aos pontos nos quais trocas de informação ocorrem. Obs: Normalmente, esses pontos estão associados a verbos.
      • Modelagem Dinâmica
    • i) Extrair comportamentos
      • Modelagem Dinâmica
      Verbos Associações Operações
    • UC DSs DCe DE DS DCd DA 2.1 2.1 - Diagrama de Seqüência Requisitos Estático Dinâmico
      • - Partindo do diagrama de seqüência de sistema e
      • usando-se os eventos identificados na modelagem dinâmica,
      • constrói-se o diagrama de seqüência final.
      • Diagrama de seqüência
      • Exemplo de Diagrama de seqüência
      Detalhar
      • Exemplo de Diagrama de seqüência
    • UC DSs DCe DE DS DCd DA 2.2 2.2 - Diagrama de Classe Dinâmico Requisitos Estático Dinâmico
      • Diagramas de classes dinâmico
      • Depois de associar eventos as classes de análise,
      • é necessário atualizar o diagrama de classes,
      • para que passe a incluir essa informação.
      • Diagramas de classes dinâmico
    • UC DSs DCe DE DS DCd DA 2.3 2.3 - Diagrama de Estado Requisitos Estático Dinâmico
      • 1 - Diagrama de Estados
      Objetivos Principais • Modelar comportamento de um objeto individual • Identificar a ordem dos estados
    • Mas é necessário modelar um DE que pode ser descrito em uma linha ?
      • Exemplo de Diagrama de Estado
      • Exemplo de Diagrama de Estado
      • Exemplo de Diagrama de Estado
    • UC DSs DCe DE DS DCd DA 2.4 2.4 - Diagrama de Atividades Requisitos Estático Dinâmico
      • 1 - Diagrama de Atividades
      Objetivos Principais • Modelar o fluxo de trabalho • Modelar uma operação
      • Diagrama de Atividades
    • Conclusão !
    • A modelagem tem uma seqüência para construção dos artefatos e assim obter detalhes de maneira correta. Modelar simplesmente para cumprir os “Entregáveis” deve ser evitado. Modelos são difíceis de se manter, se o modelo esta muito “Profundo” a tendência é que fique mais defasado com o código.
      • Conclusão
    • Um pouco mais !
      • Pode gerar documentos poluídos e de difícil compreensão.
      • Não gera todos diagramas
      • Existe informação que não é importante para um diagrama UML
      • Engenharia Reversa
      • Ferramentas que geram diagramas UML lendo códigos fontes
      Então vamos codificar primeiro ? E gerar diagramas automaticamente !
      • Ferramentas UML
      Visual Paradigm http://www.visual-paradigm.com Rational Software Modeler Enterprise Architect “ Free” Jude http://jude.change-vision.com/ ArgoUML
      • Ferramentas UML - Eclipse
      Green UML http://green.sourceforge.net/index.html
      • Ferramentas UML – Para refletir...
      Diagramas bonitos feitos por ferramentas caras nem sempre são os melhores para ajudar na comunicação ou qualidade do seu código. Modelagem Ágil, defendido por Scott Ambler: Modelar o software em grupo e com a participação dos usuários, utilizando por exemplo, um rascunho, é uma das maneiras interessantes de se conseguir qualidade no design...
      • Livros
    • Obrigado !
      • Referências Bibliográficas:
      • - UML Distilled Applying the Standard Object Modeling Language, Martin Fowler
      • - UML guia do usuário, Grady Booch, James Rumbaugh, Ivar Jacobson
      • - INF318 - Engenharia de Software – Unicamp
      • - Artigos Mundo Java – Rodrigo Yoshima
      • - http://www.uml.org/
      • - http://www.omg.org/
      • http://pt.wikipedia.org/wiki/Categoria:UML
      • http://www.projectcartoon.com/
      • by Roger Camargo - Jun/2009
      • [email_address]
      • http://www.linkedin.com/in/rogercamargo