O emprego do_rup_na_uml_-_trabalho_poo_2012
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

O emprego do_rup_na_uml_-_trabalho_poo_2012

on

  • 474 views

 

Statistics

Views

Total Views
474
Views on SlideShare
474
Embed Views
0

Actions

Likes
0
Downloads
16
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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

O emprego do_rup_na_uml_-_trabalho_poo_2012 Presentation Transcript

  • 1. RUP e UMLBrasília - DF, Outubro/2012 1
  • 2. Curso: Análise e desenvolvimento de sistemasDisciplina: Projeto Orientado a ObjetosProfessor: Roberto Ávila PaldêsPeríodo: 2º/2012 • Carlos Antônio Castro • Egon Freitas • Gabriel Costa • Igor Gentil • Rafael Faria 2
  • 3. Resumo do TrabalhoUm produto de qualidade deve ter ausência de defeitos e,principalmente, deve atender aos propósitos desejados. Alguma coisacom qualidade deve fazer o que as pessoas querem que ela faça. Sealguma coisa é livre de defeitos, mas não faz o que as pessoas queremque ela faça, essa coisa produto é um desnecessário.A qualidade de software não pode ser avaliada de maneira isolada.Softwares são desenvolvidos pelas organizações através deprocedimentos. Um método pobre ou a ausência de uma metodologiapode ser a causa da baixa qualidade. Sendo assim, a avaliação daqualidade está diretamente relacionada com a qualidade de processos,ferramentas e metodologias utilizadas.Referência: http://javafree.uol.com.br/artigo/871455/Obtendo-Qualidade-de-Software-com-o-RUP.html#ixzz2AQYpfXaI 3
  • 4. 1Introdução a UML 4
  • 5. O que é UML?• A Unified Modelling Language (UML) é uma linguagem ou notação de diagramas para especificar, visualizar e documentar modelos de software orientados por objetos. A UML não é um método de desenvolvimento, o que significa que não lhe diz o que fazer primeiro ou o que fazer depois ou como desenhar o seu sistema, mas ajuda-o a visualizar o seu desenho e a comunicar com os outros. O UML é controlado pelo Object Management Group (OMG). 5
  • 6. Criação da UML• UML foi desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson que são conhecidos como "os três amigos". Eles possuem uma extenso conhecimento na área de modelagem orientada a objetos já que as três mais conceituadas metodologias de modelagem orientada a objetos foram eles que desenvolveram e a UML é a junção do que havia de melhor nestas três metodologias adicionando novos conceitos e visões da linguagem. Eles disponibilizaram inúmeras versões preliminares da UML para a comunidade de desenvolvedores e a resposta incrementou muitas novas idéias que melhoraram ainda mais a linguagem. 6
  • 7. Vantagens da UML• Uma das grandes vantagens da UML é o fato dela ser totalmente extensível e adaptável. Você não adapta sua modelagem à UML. Você seleciona os elementos da UML que melhor expressarão sua modelagem. E se para isto for necessário estender os modelos da UML, você o faz sem perder compreensão. Qualquer um que leia seu modelo, entenderá que foi feita uma extensão. Além disso, acabam-se as fronteiras entre as fases de análise e projeto. Um mesmo diagrama é utilizado em todas as fases, mudando-se, apenas, sua visão. 7
  • 8. • O mapeamento direto dos modelos para as linguagens de programação orientadas a objeto e vice-versa também é um dos grandes ganhos da UML.• A padronização é outro fator importante e forte, porque em uma organização quando vamos desenvolver um software é o mínimo necessário para o projeto sair de acordo.• Esses são alguns dos inúmeros benefícios que a UML nos fornece, sem que percamos a liberdade de criar. 8
  • 9. Método BOOCH• Booch definiu a noção de que um sistema é analisado a partir de um número de visões, onde cada visão é descrita por um número de modelos e diagramas. O Método de Booch trazia uma simbologia complexa de ser desenhada a mão, continha também o processo pelo qual sistemas são analisados por macro e micro visões. 9
  • 10. OMT• OMT – Técnica de Modelagem de Objetos (Object Modelling Technique) é um método desenvolvido pela GE (General Electric) onde James Rumbaugh trabalhava. O método é especialmente voltado para o teste dos modelos, baseado nas especificações da análise de requisitos do sistema. O modelo total do sistema baseado no método OMT é composto pela junção dos modelos de objetos, funcional e casos de usos. 10
  • 11. OOSE / Objectory• OOSE/Objectory – Os métodos OOSE e o Objectory foram desenvolvidos baseados no mesmo ponto de vista formado por Ivar Jacobson. O método OOSE é a visão de Jacobson de um método orientado a objetos, já o Objectory é usado para a construção de sistemas tão diversos quanto eles forem. Ambos os métodos são baseados na utilização de casos de usos, que definem os requisitos iniciais do sistema, vistos por um ator externo. O método Objectory também foi adaptado para a engenharia de negócios, onde é usado para modelar e melhorar os processos envolvidos no funcionamento de empresas. 11
  • 12. Objetivos da UMLOs principais objetivos da UML são:• A modelagem de sistemas (não apenas de software) usando os conceitos da orientação a objetos• Estabelecer uma união fazendo com que métodos conceituais sejam também executáveis• Criar uma linguagem de modelagem usável tanto pelo homem quanto pela máquina 12
  • 13. Fases do Desenvolvimento com UML• Existem cinco fases no desenvolvimento de sistemas de software: análise de requisitos, análise, design (projeto), programação e testes que devem ser realizadas não necessariamente nesta ordem, mas de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e performance. 13
  • 14. Uso da UML• A UML é usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer característica de um sistema em um de seus diagramas e é também aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificação da análise de requisitos até a finalização com a fase de testes. 14
  • 15. A Notação da UML - Composição• Visões: As Visões mostram diferentes aspectos do sistema que está sendo modelado. A visão não é um gráfico, mas uma abstração consistindo em uma série de diagramas. Ex: Visão de caso de uso, lógica, componentes, concorrência e física.• Modelos de Elementos: Os conceitos usados nos diagramas são modelos de elementos que representam definições comuns da orientação a objetos como as classes, objetos, mensagens, relacionamentos entre classes incluindo associações, dependências e heranças. 15
  • 16. • Mecanismos Gerais: Os mecanismos gerais provém comentários suplementares, informações, ou semântica sobre os elementos que compõem os modelos; eles provém também mecanismos de extensão para adaptar ou estender a UML para um método/processo, organização ou usuário específico.• Diagramas: Os diagramas são os gráficos que descrevem o conteúdo em uma visão. UML possui nove tipo de diagramas que são usados em combinação para prover todas as visões do sistema. Ex: Casos de Uso, Atividades, Classes, Sequência, Implantação, Componentes... 16
  • 17. Futuro da UML• Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em técnicas antigas e marcantes da orientação a objetos, mas muitas outras influenciarão a linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir a sua estrutura interna.• A UML integrou muitas idéias adversas, e esta integração vai acelerar o uso do desenvolvimento de softwares orientados a objetos. 17
  • 18. • Para usar a UML com sucesso é necessário adotar algum tipo de método de desenvolvimento, especialmente em sistema de grande porte, onde a organização de tarefas é essencial. A utilização de um processo de desenvolvimento torna mais eficiente calcular o progresso do projeto, controlar e melhorar o trabalho. 18
  • 19. 2Introdução ao RUP 19
  • 20. Rational Unified Process• O Rational Unified Process é um processo de engenharia de software. Ele provê uma abordagem disciplinada para designar tarefas e responsabilidades em uma organização de desenvolvimento. O objetivo é assegurar a produção de um software de alta qualidade que vai de encontro com a necessidade dos usuários finais com um cronograma real e administração de recursos eficiente. 20
  • 21. Criação do RUP RUP foi criado em 1996 quando a Rational adquiriu um processo escrito por Ivar Jacobson. Posteriormente adquirido pela IBM em 2003, a idéia inicial era se formalizar um processo lógico de desenvolvimento formalizando a passagem por marcos importantes do sistema através das disciplinas de desenvolvimento de software contando com uma documentação completa e eficiente para que as equipes que soubessem onde atuar e como interagir de forma eficaz. 21
  • 22. Metodologias??? Workflows  Tarefas, subprodutos. Tarefas  Detalhadas (Papéis responsáveis, subprodutos gerados) Modelo de equipe  Papéis (Analista de Sistemas, Analista de Negócio) Modelos de Documento  Artefatos (Rational Software) 22
  • 23. Estrutura Básica• Concepção: ênfase no escopo do sistema, entendimento da necessidade e visão do projeto• Elaboração: ênfase na arquitetura, especificação e abordagem dos pontos de maior risco• Construção: ênfase no desenvolvimento;• Transição: ênfase em ajustes, implantação e transferência de propriedade do sistema. 23
  • 24. 24
  • 25. Concepção• Documento de Visão• Modelo de Caso de uso inicial• Glossário do Projeto• Caso de Negócio• Mapeamento de Riscos• Plano de Projeto e Plano de Iterações• Modelo de negócio• Protótipos 25
  • 26. Elaboração• Modelo de Caso de Uso• Requisitos complementares e não-funcionais• Modelo de Analise• Descrição da Arquitetura• Riscos Revisados• Plano de Iterações, marcos• Manual do usuário preliminar 26
  • 27. Construção• Design• Componentes do Software• Planos de teste• Casos de teste• Documentação de Suporte(Manual do Usuário, manual de instalação)• Relatórios de Defeito• Solicitações de mudanças validadas 27
  • 28. Transição• Produto entregável• Relatórios de testes BETA• Feedback geral do Usuário 28
  • 29. Melhores Práticas• Desenvolvimento de software iterativo• Gerenciamento de requisitos• Uso de arquitetura baseada em componente• Modelagem visual de software• Verificação da qualidade do software• Controle de alteração no software 29
  • 30. Vantagens• Simplicidade• Fácil Manutenção• Fácil de Customizar 30
  • 31. Suíte de Ferramentas• Implementação Nativa do RUP • Rational Requisite PRO • Rational ClearCase • Rational ClearQuest • Rational TestManager Suite • Rational Software Architect • Rational Rose • Rational Method Composer 31
  • 32. 3Emprego da UML no RUP 32
  • 33. 33
  • 34. 4Boas práticas – UML / RUP 34
  • 35. • Desenvolvimento de software RUP pode hoje ser ofuscado pelo advento da metodologia SCRUM, mas ele ainda tem um lugar importante em certos tipos de desenvolvimentos de software. Desde a sua criação pela empresa de software Rational (agora comprada pela IBM) ainda é utilizado mais amplamente do que inicialmente pode ser pensado. Para entender se é melhor, se adapte às suas necessidades que nós compilamos uma lista de vantagens e desvantagens em relação RUP para permitir que você faça a sua própria mente. 35
  • 36. Vantagens• Metodologia completa por si só, com ênfase na precisão da documentação.• É capaz de resolver, de forma proativa, os riscos de projeto associado aos requisitos de evolução do cliente, exigindo uma gestão cuidadosa dos pedidos de mudanças.• É necessário menos tempo para a integração, pois como o processo de integração durante todo o ciclo de vida de desenvolvimento de software.• O tempo de desenvolvimento requerido é menor, devido à reutilização de componentes.• Há treinamentos online e tutoriais disponíveis para este processo. 36
  • 37. Desvantagens• Os membros da equipe precisam ser especialistas na sua área para desenvolver um software sob essa metodologia.• O processo de desenvolvimento é muito complexo e desorganizado.• Em projetos de ponta que utilizam uma nova tecnologia, a reutilização de componentes não será possível. Daí a economia de tempo que poderia ter feito, será impossível de se cumprir.• Integração ao longo do processo de desenvolvimento de software, que em teoria parece ser uma coisa boa, mas em particular, os grandes projetos com múltiplos fluxos de desenvolvimento, ela só vai aumentar a confusão e causar mais problemas durante as fases de testes. 37
  • 38. As 6 melhores práticas• Desenvolvimento IterativoA especificação de requisitos de software (SRS)continua a evoluir ao longo do processo dedesenvolvimento, e loops são criados para adicioná-los, sem afetar o custo de desenvolvimento.• Requisitos GerenciaisA documentação de requisitos e gerenciamento derequisitos de projeto precisa ser recolhidacorretamente do usuário, a fim de alcançar o objetivovisado. 38
  • 39. • Componentes de usoOs grandes componentes do projeto que já estãotestados e em uso, é convenientemente utilizá-lo emoutros projetos. Esta reutilização de componentesreduz o tempo de produção.• Modelo VisualUso da Unified Modeling Language (UML) facilita aanálise e desenho de vários componentes.Diagramas e modelos são usados ​para representar osvários componentes e suas interações. 39
  • 40. • Verificação da qualidadeTestar e implementar uma gestão eficaz da qualidade doprojeto, deve ser uma parte importante de todos e de cadafase do projeto, do início até a entrega (também conhecidocomo o ciclo de vida do projeto de gestão).• Alterações de ControleA sincronização de várias partes do sistema torna-se aindamais difícil quando as peças estão sendo desenvolvidaspor diversas equipes de trabalho de diferentes áreasgeográficas e em diferentes plataformas dedesenvolvimento. Daí o cuidado especial que deve sertomado nessa direção para que as alterações possam sercontroladas. 40
  • 41. 5Dinâmica em Grupo 41
  • 42. 42
  • 43. FIMDúvidas? 43