RUP e UML

Brasília - DF, Outubro/2012 1

• Carlos Antônio Castro

• Egon Freitas

• Gabriel Costa

• Igor Gentil

• Rafael Faria

Curso: Análise e desenvolvimento de sistemas

Disciplina: Projeto Orientado a Objetos

Professor: Roberto Ávila Paldês

Período: 2º/2012

2

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

Introdução a UML

1

4

• 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).

O que é UML?

5

• 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.

Criação da UML

6

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

• 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

• 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.

Método BOOCH

9

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

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

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

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

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

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

• 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

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

• 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

Introdução ao RUP

2

19

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

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

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

• 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.

Estrutura Básica

23

24

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

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

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

Transição

• Produto entregável

• Relatórios de testes BETA

• Feedback geral do Usuário

28

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

Vantagens

• Simplicidade

• Fácil Manutenção

• Fácil de Customizar

30

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

Emprego da UML no RUP

3

32

33

Boas práticas – UML / RUP

4

34

• 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

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

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

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

• 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

• 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

Dinâmica em Grupo

5

41

42

Dúvidas?

FIM

43