O documento discute a introdução do RUP e UML. Resume os principais conceitos do RUP como um processo de engenharia de software iterativo e disciplinado e como a UML é usada para modelagem visual no RUP.

1. RUP e UML
Brasília - DF, Outubro/2012
1

2. Curso: Análise e desenvolvimento de sistemas
Disciplina: Projeto Orientado a Objetos
Professor: Roberto Ávila Paldês
Período: 2º/2012
• Carlos Antônio Castro
• Egon Freitas
• Gabriel Costa
• Igor Gentil
• Rafael Faria
2

3. Resumo do Trabalho
Um produto de qualidade deve ter ausência de defeitos e,
principalmente, deve atender aos propósitos desejados. Alguma coisa
com qualidade deve fazer o que as pessoas querem que ela faça. Se
alguma coisa é livre de defeitos, mas não faz o que as pessoas querem
que 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 de
procedimentos. Um método pobre ou a ausência de uma metodologia
pode ser a causa da baixa qualidade. Sendo assim, a avaliação da
qualidade 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. 1
Introduçã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 UML
Os 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. 2
Introduçã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. 3
Emprego da UML no RUP
32

33. 33

34. 4
Boas 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 Iterativo
A especificação de requisitos de software (SRS)
continua a evoluir ao longo do processo de
desenvolvimento, e loops são criados para adicioná-
los, sem afetar o custo de desenvolvimento.
• Requisitos Gerenciais
A documentação de requisitos e gerenciamento de
requisitos de projeto precisa ser recolhida
corretamente do usuário, a fim de alcançar o objetivo
visado.
38

39. • Componentes de uso
Os grandes componentes do projeto que já estão
testados e em uso, é convenientemente utilizá-lo em
outros projetos. Esta reutilização de componentes
reduz o tempo de produção.
• Modelo Visual
Uso da Unified Modeling Language (UML) facilita a
análise e desenho de vários componentes.
Diagramas e modelos são usados ​para representar os
vários componentes e suas interações.
39

40. • Verificação da qualidade
Testar e implementar uma gestão eficaz da qualidade do
projeto, deve ser uma parte importante de todos e de cada
fase do projeto, do início até a entrega (também conhecido
como o ciclo de vida do projeto de gestão).
• Alterações de Controle
A sincronização de várias partes do sistema torna-se ainda
mais difícil quando as peças estão sendo desenvolvidas
por diversas equipes de trabalho de diferentes áreas
geográficas e em diferentes plataformas de
desenvolvimento. Daí o cuidado especial que deve ser
tomado nessa direção para que as alterações possam ser
controladas.
40

41. 5
Dinâmica em Grupo
41

42. 42

43. FIM
Dúvidas?
43