CONCEITOS DA UML E DA PROGRAMAÇÃO ORIENTADA A OBJETOS ESTUDO DOS DIAGRAMAS

(1)

1 CONCEITOS DA UML E DA PROGRAMAÇÃO ORIENTADA A OBJETOS

ESTUDO DOS DIAGRAMAS 03/08/2010 AULA 2

Artefatos são os documentos ou tudo que é entregue para a progressão e futura finalização do produto.

UML representa através de símbolos os fatos e os artefatos, é uma linguagem utilizada para qualquer fim, em qualquer área.

Processamento em Batch, tem uma sequencia que não pode ser interrompida, não tem interatividade.

Os requisitos funcionais são aqueles que o software deve entregar

Os não funcionais são as características de como o software deve ser, em ambos os casos existe a dependência de reunião e solicitação da empresa.

Fases Genéricas: - Definição (quê?)

- Desenvolvimento (como?) - Manutenção (mudanças) RUP

Racional Unifase Process É um framework

Engloba todas as visões dos artefatos.

Dividido em duas dimensões, uma é a dimensão dos artefatos; mostra o andamento do projeto:

Iniciação – Elaboração – Construção – Transição Wilson,

Veja o mapa mental sobre RUP postado pelo Edilberto. Na Iniciação o marco é o Objetivos do ciclo de vida. Na Elaboração o marco é a Arquitetura do ciclo de vida. Na Construção o marco é a Capacidade Operacional inicial. Na Transição o marco é o Release do Produto (ou seja, a entrega).

(2)

2 E as disciplinas:

Procurando saber as relações entre elas e entre a dimensão do andamento do projeto são 9. - Modelagem de negócio - Requisitos - Análise e Design - Implementação ou codificação - Teste - Implantação

Gerentes: Gerenciamento de Projetos

Gerenciamento de ambientes Gerenciamento de mudanças ... AULA 03 DIA 10/08/2010 PESSOA Classe Poliforfismo Sobrescrita Atributos Sobrecarga Métodos

FILME Nome dt.nasc ano teatro n.cartista

HERANÇA

O.O.

Encapsulamento é a característica de não se demonstrar os códigos internos fazendo com que eles não sejam visualizados.

Mesmo estando na mesma classe não significa que tenham as mesmas funções.

Nicole 10/08/80 3 1111 Juju 02/02/82 2 222 Julia Paes 03/03/83 4 333

}

Nome _______________ Data nascimento Incluir( ) n. anos de teatro n. C artista ... Selecionar ( ) Qtos car ... Incluir ( ) Nome Genero ... Alterar ( )

(3)

3 O objeto compartilha a mesma classe mas não as mesma funções (INSTANCIA é a retirada das funções de um objeto)

A reunião de todas as características é que formam o objeto dentro mesma classe.

O Polimorfismo é quando se divide os métodos e distribui-se entre o objeto é a herança dos métodos.

AS ASSINATURAS SÃO OS TIPOS DE DADOS DESTES PARAMETROS QUE O IDENTIFICAM. Se muda a assinatura do método estamos fazendo uma sobrecarga.

Quando não mudamos o método estamos fazendo uma sobrescrita. As mensagens são as formas de comunicação entre os objetos. A associação especial que relaciona pai e filhos é a HERANÇA. As mensagens são construtoras e destrutoras

As formas de segurança são 4: PACOTE ~

PÚBLICA +

PRIVADA -

PROTEGIDA #

Pacote: reúne ou separa as classes, os subsistemas.

Protegida: Todas as classes, bem como suas filhas podem acessar. Pública: Todos podem acessar.

Privada: apenas os autorizados podem acessar.

A mensagem construtora é aquela que aloca o objeto na memória.

E quando vc retira o objeto da memória vc esta em uma mensagem destrutora. UML

Diagramas estruturais: PACOTE CLASSE OBJETOS COMPONENTES

ESTRUTURA COMPOSTA IMPLANTAÇÃO

Diagrama comportamental: ATIVIDADES CASO DE USO

MAQUINAS DE ESTADO Diagrama de Interação: SEQUENCIA

COMUNICAÇÃO INTERAÇÃO GERAL TEMPO

(4)

4 A UML surgiu em 1996, A UML é uma ferramenta que auxilia na modelagem de sistemas padronizando projetos e considerando aspectos conceituais de reutilização.

É composto de 13 diagramas além do detalhamento de Casos de Uso, que também é considerado um diagrama, perfazendo o número de 14 diagramas.

A UML pode ser dividida em 2 categorias:

ESTRUTURAIS: Utilizados para descrever a Arquitetura do Sistema

COMPORTAMENTAIS: Consideram aspectos interativos e temporais existentes entre os elementos.

Cada diagrama da UML possui uma notação própria que descreve uma situação dentro do processo de software.

Quem gerencia a UML é a OMG (Object Management Group) mantendo e estabelecendo a especificação UML.

DIAGRAMA DE CASOS DE USO

O Diagrama de Casos de Uso é um dos mais importantes diagramas da UML, sanando dúvidas quanto ao sistema. Apresenta os aspectos estruturais do sistema, sem se preocupar com detalhes temporais.

(É um diagrama estrutural), Serve para que o cliente compreenda melhor os requisitos do sistema, o que o sistema realmente vai ter, quais as ações que os atores do sistema vão fazer. Definição dos Casos de Uso: Consiste na parte mais importante da construção de um software O.O., já que está presente do início ao fim do projeto (Medeiros, 2006).

Os Casos de Uso são úteis para que dúvidas sejam sanadas entre clientes e desenvolvedores. Descreve funcionalidades que devem estar presentes no software. Pessoas, recursos ou equipamentos que interagem com as funcionalidades. Proporciona, inclusive, a descoberta de novos requisitos.

Casos de Uso – ASPECTOS: Considerado por muitos autores como uma ferramenta de CAIXA PRETA. Serve como uma ferramenta para testes de validação.

A construção desses diagramas é composta por 3 elementos: 1 – Atores

2 – Casos de Uso

(5)

5 OS ATORES

Consistem em pessoas, departamentos ou equipamentos que são elementos externos ao sistema e que interagem com o sistema.

Ajuda a delimitar o sistema além de fornecer uma visão dos responsáveis por acionar as funcionalidades.

Um ator pode interagir ou atuar sobre um ou mais Casos de Uso, o que é definido como uma associação. O único relacionamento entre atores é por meio de generalização.

EXEMPLO DE ATORES: Usuário.

Administrador.

ATORES – PERGUNTAS ÚTEIS:

1 – Quem ou o que irá utilizar o sistema? 2 – Quem interage com o sistema?

2 – Quais outros sistemas utilizam o sistema que está sendo construído? CASOS DE USO - PERGUNTAS ÚTEIS: 1 - Quais funções o software precisa fornecer para atender aos atores? 2 – O que o ator precisa fazer?

3 – A quais informações o ator precisa ter acesso?

4 – O sistema deve notificar a algum ator eventos do sistema? OS RELACIONAMENTOS ENTRE CASOS DE USO:

Podem ser utilizados relacionamentos de: INCLUSÃO ==== INCLUDE

EXTENÇÃO == EXTEND DEPENDENCIA

GENERALIZAÇÃO

A DEPENDENCIA, consiste na definição de que um caso de uso depende de que outro exista para que ele também possa vir a ser utilizado.

=====

A INCLUSÃO, pode ser total ou parcial de um caso de uso, e o incluso sempre será executado. ---

A EXTENÇÃO, Semelhante ao relacionamento por inclusão, porém nem sempre o caso de uso a ser utilizado pelo caso de uso base é incorporado.

--- include

(6)

6 A GENERALIZAÇÃO, Usado para descrever o principio de herança do paradigma de orientação a objetos, assim como nos atores.

O ESCOPO DO SISTEMA:

É o elemento UML responsável por descrever a abrangência do sistema em um diagrama de casos de uso.

DETALHAMENTO DOS CASOS DE USO:

Consiste em uma descrição de cada caso de uso de maneira a tornar mais nítido o que deve ser feito, o que é possível por meio da observação ou da entrevista. Não existe detalhamento padrão. EXEMPLO DE DETALHAMENTO: 1 – Nome de Referencia 2 – Breve Descritivo 3 – Pré Condições 4 – Atores Envolvidos 5 – Cenário Principal 6 – Cenário Alternativo 7 – Requisitos Epeciais 8 – Dados DIAGRAMAS DE ATIVIDADES Existem 2 tipos:

ESTRUTURAIS: Utilizados para descrever a Arquitetura do Sistema, Os componentes que existem no sistema,todo o necessário para o desenvolvimento das telas do sistema.

COMPORTAMENTAIS: Descreve o comportamento correto das estruturas do sistema.

Tem a capacidade de expressão temporal e comportamental das interações que podem ocorrer sobre as funcionalidades e as atividades de um sistema.

O Diagrama de Atividades é utilizado para obter um entendimento do comportamento de um requisito.

(7)

7 Sim

Não ?

COMPONENTES DO DIAGRAMA DE ATIVIDADES:

ATIVIDADE: Comportamento composto por uma ou mais ações que devem estar presentes na funcionalidade ou requisitos.

Os Diagramas de Atividades devem possuir dois marcos (INÍCIO E FIM). ATIVIDADE INICIAL :

ATIVIDADE FINAL:

Em um Diagrama de Atividades podem haver diversas atividades iniciais assim como finais. As TRANSIÇÕES são pontos de passagem de uma atividade para outra. A transição é o caminho de como as ações serão desempenhadas em uma funcionalidade que deve fazer parte do sistema.

PONTOS DE DECISÃO: São os elementos para a representação de uma parte do fluxo da Atividade, no qual é necessário fazer escolhas, indicando diferentes caminhos.

Os Pontos de Decisão sempre fazem uma pergunta, indicando um caminho com a resposta (sim) e outro alternativo com a resposta (não)

FORK e JOIN ou BIFURCAÇÃO e SINCRONIZAÇÃO:

Possibilitam delimitar o início e o fim do paralelismo entre seqüências de Atividades concorrentes.

FORK traduzindo para o português, significa GARFO, é responsável pela bifurcação de um elemento subdividindo-o em várias transições ou seja, de um fluxo podemos dividir essas informações ou detalhes para várias outras atividades.

JOIN traduzindo para o português, significa JUNTAR, é responsável pela sincronização das atividades.

(8)

8 (FORK OU BIFURCAÇÃO)

(JOIN OU SINCRONIZAÇÃO)

Uma bifurcação não gera, necessariamente uma sincronização, pois uma bifurcação pode gerar resultados finais nas ações, as quais ela se relaciona.

MERGE: É o responsável pela continuidade do processo, no qual o fluxo de dados prossegue com a chegada de várias transições para o elemento. É representado por um losango preenchido.

É utilizado depois que se utiliza uma estrutura de condição, na qual, ambas as respostas convergem para um único tipo de ação possível.

PARTIÇÕES: São responsáveis por indicar a passagem de fluxo de uma atividade entre um ator e outro.

Atendente Gerente

Neste caso a partição retira do atendente a responsabilidade e repassa para o gerente, que é quem autorizará a execução da ação ou atividade.

AÇÃO 1 AÇÃO 2

Atividade 1

(9)

9 Outros elementos do Diagrama de Atividades:

Sinais de envio

Sinais de recebimento

DIAGRAMA DE CLASSES

Os Diagramas de Casos de Uso e Diagramas de Atividades são o ponto de partida para se poder formular os Diagramas de Classe.

O Diagrama de Classes é o ponto inicial para passarmos a automatizar o processo de desenvolvimento. Expressar a estrutura estática de um sistema.

O Diagrama de Classes é utilizado e mantido durante todo o ciclo de vida do sistema. São o resultado de quão bom foram nossa descrição de Casos de Uso.

As definições de Casos de Uso e o detalhamento são importantíssimos para conseguirmos construir os Diagramas de Classe com qualidade.

Os Diagramas de Classe podem ser trabalhados de duas maneiras, representando aspectos do sistema.

DOMINIO PROJETO

DOMINIO: Conhecido como modelo conceitual, trabalha em um nível mais alto de abstração e independe da tecnologia e formas de trabalho.

PROJETO: Trabalha com a especificação UML, no qual são consideradas as classes com seus atributos e métodos.

Este é o elemento de nota, utilizado quando se fizer necessário algum comentário.

Este é o elemento de Pin, utilizado juntamente com as ações no Diagrama de Atividades.

Este é o elemento de Periodicidade, afeta a freqüência em que determinada ação vai acontecer.

(10)

10 Tais descrições acima citadas, não fazem parte da especificação UML, são metodologias para melhor organizar e entender o processo.

O elemento básico do diagrama que existirá em ambos, consiste na classe.

As classes consistem em uma descrição genérica de algo que deve estar presente no sistema. É a modelagem mais natural, pois estamos acostumados a lidar com “objetos”.

A UML fornece uma notação gráfica para a representação de uma classe de objetos, NOME CLASSE

<ATRIBUTOS> <MÉTODOS>

Alguns aspectos devem ser descritos para refletir o que será implementado em uma linguagem de programação.

ATRIBUTOS E METODOS:

(VISIBILIDADE) Nome do atributo:

[TIPO DO ATRIBUTO] = {VALOR DEFAULT} (PROPRIEDADES) [+] PÚBLICA (PUBLIC)

[#] PROTEGIDA (PROTECTED) [-] PRIVADA (PRIVATE)

Para descrever os métodos utilizamos a visibilidade descrevendo o nome do método e os parâmetros para serem trabalhados dentro do método.

Assim podemos identificar qual o tipo de retorno será utilizado para o método. CARRO

-COR:String +LIGAR: boolean

+SETLIGAR(valor;boolean):VOID +GETLIGAR():Boolean

O resultado seria a criação de uma classe chamada CARRO, que teria ATRIBUTOS privados e públicos. METODOS públicos com o tipo de retorno que foi definido, sendo que cada um possui o nome e sua lista de parâmetros.

IDENTIFICANDO AS CLASSES:

Uma das melhores maneiras é utilizarmos o detalhamento ou a descrição dos Casos de Uso. Geralmente, atores refletem em classes.

(11)

11 DE FRONTEIRA

DE ENTIDADE DE CONTROLE

Ex: Classe “Aluno” com o objeto “estudante”. (UMA CLASSE DE ENTIDADE) Algo que o ator vai interagir no sistema o tipo de janela que ele vai interagir dentro do sistema. (UMA CLASSE DE FRONTEIRA) Algo que vai modelar o fluxo de execução do sistema, da Ação de controle do cadastro (UMA CLASSE DE CONTROLE)

Por natureza, um Diagrama de Classes é incompleto e, no decorrer da construção é comum encontrarmos novas classes. (Essa notação refere-se a todo e qualquer diagrama).

Para que possamos contextualizar nossas classes temos que pensar que no mundo nada está isolado, pois um objeto pode ser decomposto em vários pedaços.

Classes isoladas não seriam capazes de descrever um projeto de software. É aí que surgem os relacionamentos entre as classes.

RELACIONAMENTOS ENTRE CLASSES:

Classes são elementos que por meio de colaboração e do relacionamento com outras classes apresentam soluções para um problema.

O mais simples de todos os relacionamentos consiste na associação, sendo o mais utilizado de todos possíveis. A associação nada mais é do que uma conexão semântica entre a classe, é o que vai determinar quando uma classe está associada a outra.

No exemplo CARRO, sabemos que este pode ser conduzido por uma pessoa, portanto a classe CARRO tem uma associação com a classe MOTORISTA.

No diagrama de classes ficaria assim:

A NAVEGABILIDADE NOS RELACIONAMENTOS:

Possibilita representar a comunicação entre duas classes, a menos que exista uma navegabilidade absolutamente expressa.

PESSOA <ATRIBUTOS> <MÉTODOS> CARRO <ATRIBUTOS> <MÉTODOS> Estudante:Aluno JANELA DE ENTRADA JANELA CADASTRO Controle de Cadastro dirige

(12)

12

Desta forma vc parte da pessoa e faz a pergunta; A pessoa faz o que? A resposta: Dirige um carro.

Existem elementos que são responsáveis por representar a MULTIPLICIDADE entre as classes. São conhecidos também como CARDINALIDADE.

A CARDINALIDADE nada mais é do que a quantidade mínima e máxima que uma classe pode estar associada a outra. É muito importante a definição da Cardinalidade entre as classes. TIPOS DE CARDINALIDADES:

0– 1 ZERO OU UMA INSTANCIAS

1 SOMENTE UMA INSTANCIA

0 * ZERO E MAIS INSTANCIAS

* DEFAULT ILIMITADO DE INSTANCIAS

1 * UMA OU MAIS INSTANCIAS

_ * NÚMERO EXATO OU MAIS INSTANCIAS

A associação é de extrema importância para a legibilidade dos Diagramas de Classe. TIPOS DE ASSOCIAÇÃO:

RECURSIVA: É uma situação onde se tem um auto relacionamento, ou seja, onde uma instancia de uma classe depende de outra instancia dessa mesma classe. Sempre uma associação recursiva tem multiplicidade.

CARRO <ATRIBUTOS> <MÉTODOS> PESSOA <ATRIBUTOS> <MÉTODOS> Disciplina -nome: String -periodo: int Operações +getnome():String +setnome(nome:String):void +getperiodo():int +setperiodo(period:int):void dirige 0_* 0_*

(13)

13 TERNÁRIA: Quando mais de uma classe está associada para trabalhar em conjunto, é representada através de um losango onde diversas classes estão ligadas a ele e apenas uma associação irá descrever o processo desta classe.

CLASSES DA ASSOCIAÇÃO: É um tipo especial de classe, é um relacionamento onde será armazenado informações de outro relacionamento.

Ex: 2 classes se relacionam só que aparecem informações desse relacionamento, para manter essas informações criam-se as classes da associação.

- Neste exemplo, vemos que no relacionamento pessoa com empresa nasce uma nova entidade. Neste caso a entidade Funcionário não está relacionada com uma ou outra classe e sim com as duas.

RELACIONAMENTOS DE AGREGAÇÃO:

São utilizados para apresentar um tipo de classe que é formado pela AGREGAÇÃO de outras classes. (também conhecido como TODO-PARTE).

PROJETOS <ATRIBUTOS> <MÉTODOS> PRÉ-REQUISITOS <ATRIBUTOS> <MÉTODOS> FUNCIONARIOS <ATRIBUTOS> <MÉTODOS> AVALIAÇÃO <ATRIBUTOS> <MÉTODOS> PESSOA <ATRIBUTOS> <MÉTODOS> EMPRESA <ATRIBUTOS> <MÉTODOS> FUNCIONARIO <ATRIBUTOS> <MÉTODOS> 0_* 0_*

(14)

14 TIPOS DE AGREGAÇÃO:

REFERENCIA: Dão uma idéia de independência, o todo será composto pelo conjunto das partes ou somente por um sub-conjunto das partes.

COMPOSIÇÃO: É dependente, onde todas as partes irão formar o todo. HERANÇA:

EXPRESSA DOIS CONCEITOS BÁSIOCOS:

GENERALIZAÇÃO: , Usado para descrever o principio de herança do paradigma de orientação a objetos, assim como nos atores.

ESPECIALIZAÇÃO: Criar algo novo a partir do que já existe, agregando valor aquela classe. SUBCLASSE: É aquela que herda os atributos da SUPERCLASSE.

SUPER CLASSE: É a classe pai.

DEPENDENCIA:

Expressa a existência de uma instancia de uma classe dependente da existência de uma instancia de outra classe. GERALMENTE CONHECIDAS COMO CLIENTE/SERVIDORA. Geralmente utilizada para uma instancia, já que para múltiplas instancias seria mais apropriado utilizar agregação por composição.

Um motorista depende de uma habilitação. CLASSES ABSTRATAS:

É um tipo especial de classe que dita o comportamento e não necessita implementação. A herança é muito forte nas classes abstratas, Outras classes tendem a ficar próximas dela,

PESSOA <ATRIBUTOS> <MÉTODOS> PESSOA FISICA <ATRIBUTOS> <MÉTODOS> PESSOA JURIDICA <ATRIBUTOS> <MÉTODOS> MOTORISTA <ATRIBUTOS> <MÉTODOS> HABILITAÇÃO <ATRIBUTOS> <MÉTODOS>

(15)

15 DIAGRAMA DE SEQUENCIA:

Entra em cena o Diagrama de Sequencia e o de Colaboração, importantes ferramentas para a descrição do processo de interação.

Os Diagramas de Interação são divididos em duas categorias: ESTRUTURAIS: Mostram a arquitetura do sistema.

COMPORTAMENTAIS: Os Comportamentais auxiliam na representação temporal e colaborativa.

Os Diagramas de Interação, favorecem a identificação de novas características ou responsabilidades que possam ter ficado despercebidas.

O Diagrama de Sequencia: São utilizados para representar a evolção de uma funcionalidade em um determinado momento do software.

Possui duas dimensões:

VERTICAL: EM QUE É REPRESENTADO O TEMPO

HORIZONTAL: É RESPONSAVEL POR REPRESENTAR OS DIFERENTES OBJETOS QUE COMPÕE A INTERAÇÃO.

As mensagens recursivas ocorrem quando um objeto chama um método dele mesmo.

DIAGRAMAS DE ESTADO E COMPONENTES

Os objetos podem estar em determinado estado, em certo momento, fruto da utilização de componentes reutilizáveis.

QUANDO UTILIZAR UM DIAGRAMA DE ESTADO?

- Quando objetos possuem um atrTAibuto de estado com duas propriedades. - Assume um pequeno número de valores possíveis.

- As transações permitidas entre os valores são restritas.

O Diagrama Estrutural(de Estado) auxilia na verificação do processo de descrição do domínio do problema.

Explicitar classes que podem faltar no Diagrama de Classes.

O Diagrama de Estado é utilizado quando em nossa classe um ou mais atributos reflitam o estado de seus objetos em um determinado momento, visando a simplificar a complexidade de entendimento em um software.

<<Classe Abstrata>> <ATRIBUTOS>

<Operações> + operação (): String

(16)

16 Quando os relacionamentos entre as classes não estão claros o suficiente, considerando valores discretos e restrições entre passagem de estados.

A passagem de estados na UML é conhecida como transição de estados.

O menor elemento de um Diagrama de Estado é o próprio estado, e a notação para sua representação é parecida com a definição de uma classe.

Podemos nos deparar com situações em que teremos estados compostos.

Assim como no Diagrama de Atividades, o Diagrama de Estado tem seu estado inicial e seu estado final representados por um círculo.

A transição é a alteração de estado. É provocada por um evento interno ou externo sobre a entidade modelada. Para que haja transição de estado, são necessários dois mecanismos: CONDIÇÃO e AÇÃO

Pode-se utilizar no Diagrama de Estado as ferramentas FORK e JOIN.

Estado 1 Estado 2

EstadoComposto

Estado Estado Estado 2 Estado 1 Estado 3 Estado 4

(17)

17 Outros Elementos são:

ESTADO DE ESCOLHA PONTO DE JUNÇÃO

Neste caso o círculo verde representa um estado de escolha, enquanto o azul representa um ponto de junção.

Toda vez que entramos em um determinado estado, podemos executar uma operação. METODOLOGIAS AGEIS

SCRUM

O SCRUM foi criado em 1990 por Jeff Sutherland e Ken Chwaber. O SCRUM é um método ágil para gerenciamento de projetos, com o SCRUM os projetos progridem através de interações chamadas de SPRINTS, Cada SPRINT dura aproximadamente entre duas e quatro semanas, ou seja, o objetivo final vai sendo entregue aos poucos em pequenos pedaços até atingir a sua totalidade.

A união de todos os requisitos no SCRUM é chamado de Product Backlog. No Product Backlog temos uma lista de requisitos e escolhemos aqueles que farão parte do sistema.

Para o desenvolvimento de um produto precisamos de pessoas desempenhando determinados papeis.

Um desses papéis é o de Product Owner que é a pessoa encarregada de analisar a lista de requisitos e saber quais serão os requisitos necessários ao sistema, representando os usuários e clientes do produto, Ela auxilia a determinar a direção do produto.

Entra em cena então o Scrum Master, o seu trabalho é garantir que o projeto do produto esteja progredindo e que cada membro da equipe tenha as ferramentas necessárias para

Estado 3 Estado 1

Estado 2

Estado 4

(18)

18 realizar seus trabalhos. Ele organiza reuniões, monitora o trabalho sendo feito e facilita o desenvolvimento do release. Ele é essencialmente um Gerente de Projeto.

Existem ainda os Developers, que desenvolvem o produto.

Os Testers, que testam o produto para ter certeza de que funciona bem. Costumers, são os que utilizam o produto e pagam por ele.

Executives, são os caras que ficam no caminho.

A equipe começa o trabalho com o Release Planning, que é o lugar (ProductBacklog) onde eles identificam os requisitos que eles querem colocar no Release, estes requisitos então, tornam-se parte do Releatornam-se BackLog.

A Equipe então prioriza os requisitos e estima quanto tempo o trabalho envolve cada um deles, provendo uma idéia geral da quantidade de trabalho envolvido para completar todo release.

Com o Release BackLog pronto em mãos o próximo passo e planejar os vários Sprints para realizar o trabalho.

SPRINTS são marcos curtos de direção que possibilita a equipe gerenciar o tronco do projeto e ficar em um estado geral pronto. Sprints geralmente duram de alguns dias a no máximo 30 dias dependendo dos ciclos do release do produto.

QUANTO MAIS CURTO FO O CICLO DO RELEASE DO PRODUTO, MAIS BREVE O SPRINT DEVERÁ SER.

Com o Release BackLog na mão é hora de dividi-lo em vários Sprints BackLogs. Uma das coisas mais importantes para se lembrar sobre Sprints, é que a meta de cada Sprint é a de levar o Product BackLog para um estado geral de pronto. Então no final de cada Sprint a equipe terá um produto completamente testado com todos os requisitos daquele Sprint 100% completo. O término tardio de um Sprint é um grande indicador de que o produto não está no prazo. O SCRUM é apoiado em quatro fundamentos:

Papéis Artefatos Cerimônias Atitude

1. QUAIS SÃO AS PRINCIPAIS CARACTERÍSTICAS DOS MÉTODOS

ÁGEIS? O QUE É O "MANIFESTO ÁGIL"

quanto as características creio já tenham sido bem tratadas já em relação a esse

"manifesto ágil", creio a necessidade de ir mais além nos projetos, além de meras

documentações, ter maior interação com o cliente tenha gerado esse manifesto.

2. Métodos ágeis estão em desuso? O método XP e SCRUM morreram?

de forma alguma eles estão em desuso, muito menos tais métodos, em nossa sala de aula

mesmo temos um colega que trabalha com XP.

(19)

19

Programadores - foco central da metodologia, sem hierarquia.

Treinador (ou coach) – pessoa com mais experiência no time, responsável por lembrar

os outros das regras do jogo (que são as práticas e os valores de XP). O treinador não

precisa necessariamente ser o melhor programador da equipe e sim o que mais entende

da metodologia XP.

Acompanhador (ou tracker) – responsável por trazer para o time dados, gráficos,

informações que mostrem o andamento do projeto e ajudem a equipe a tomar decisões

de implementação, arquitetura e design. Algumas vezes o próprio coach faz papel de

tracker. Outras o time escolhe sozinho quem exercerá este papel.

Cliente – em XP o cliente faz parte da equipe. Deve estar sempre presente e pronto para

responder às dúvidas dos programadores.

4. QUAIS OS PRINCIPAIS FASES/ETAPAS DA METODOLOGIA XP? ELA É

ITERATIVA COMO O RUP?

Exploração;

Planejamento;

Iterações para Release;

Validação para Produção (productionizing);

Manutenção;

Morte.

5 -O QUE SÃO ESTÓRIAS, RELEASES DE CODIGO , PROGRAMAÇÃO EM

PARES NO CONTEXTO DA METODOLOGIA XP?

O foco do XP é o trabalho colaborativo e em equipe, visando sempre a satisfação do

cliente, mantendo-o envolvido no projeto e o tempo todo próximo aos desenvolvedores

de forma a colher feedback do desenvolvimento de forma ágil e que permita assim

realizar as mudanças necessárias o mais rápido possível.

Estórias na metodologia XP são utilizadas para descrever as funcionalidades do sistema

e estimar o custo de cada uma delas, o cliente descreve em cartões o que deseja, de

forma simples a fim de facilitar o entendimento, e os desenvolvedores se utilizam desse

cartões para fazer estimativas e mostrar ao cliente para que sejam eleitas as prioridades .

Desenvolvendo as funcionalidades através das estórias é possível uma validação mais

rápida e implementação mais eficaz agilizando dessa forma a recepção do feedback e

permitindo que os desenvolvedores percebam as reais necessidades do cliente.

Releases são espaços de tempo não muito longo onde são feitas entregas ao cliente,

permitindo que ele já possa utilizá-las e se beneficiar delas. Essas entregas são avaliadas

pelo cliente e assim podem ser feitos ajustes. As releases são planejadas no ‘jogo do

planejamento’.

A programação em pares permite uma revisão permanente, maior aprendizado,

possibilita soluções inovadoras, correção de erros com mais agilidades, já que enquanto

um programador digita o outro revisa o código e uniformiza o conhecimento.

(20)

20

6. QUAIS OS PRINCIPAIS PAPÉIS (FUNÇÕES) DA METODOLOGIA

SCRUM? METODOLOGIA OU FRAMEWORK?

7. QUAIS OS PRINCIPAIS FASES/ETAPAS DA METODOLOGIA SCRUM?



Backlog de produto: fase de iniciação;



Planejamento de sprint, formação do backlog de sprint: fase de planejamento;



Execução/ desenvolvimento: fase de execução;



Daily meeting: fase de monitoramento e controle;



Retrospectiva, demonstração: fase de encerramento.

8. O QUE É BACKLOG, BURNDOWN E SPRINT, O QUE ISTO TEM HAVER

COM TIMEBOX, NO CONTEXTO DESTA METODOLOGIA SCRUM?

No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de

Sprints. O tempo de duração de cada Sprint representa um Time Box dentro do qual um

conjunto de atividades deve ser executado um ou o conjunto de Sprints executados se

consegue montar uma ou mais funcionalidades do sistema, o conjunto de funcionalidade

integrada forma o sistema. O Backlog de Produto, lista todas as funcionalidades que

serão necessárias no sistema e suas prioridades, associado ao valor de negócio para que

se consiga calcular o retorno do projeto. O Backlog de Impedimentos é a lista de

impedimentos conhecidos que impedem a equipe de progredir na execução das tarefas

ou dos Sprints Para o controle do desenvolvimento e desempenho da equipe se monta o

Burndown Chart. O Burndown Chart, é um gráfico que demonstra a quantidade de

horas e dias previstos para a realização do Sprint, com o que foi realizado, observando

esse documento é fácil entender se o projeto está sendo realizado no prazo ou se está

atrasado.

9. SCRUM E XP TÊM FASES DE PLANEJAMENTO? SE TIVER O QUE É

TRATADO NESTA?

No SCRUM, a fase de planejamento é o chamado SPRINT, que dura em torno de 2 a 4

semanas e ocorre várias vezes durante o projeto.

No XP, o cliente escreve um documento informando o que o sistema deve conter. Isto é

chamado de User Stories que é parecida com o Use Cases da UML.

O tempo para que cada programador desenvolva cada uma das User Stories é

determinado e caso o tempo seja maior que 3 semanas a User Story deve ser subdividida

em outras partes.

(21)

21

Comparação entre RUP e XP

Enquanto a RUP é considerada um metodologia tradicional, rigorosa, pesada e

orientada ao planejamento, tendo a documentação como uma parte vital e

voltada, principalmente, para projetos de sistemas complexos. O XP é uma

metodologia ágil voltada para projetos de pequeno e médio porte e sistemas

mais simples, que valoriza principalmente a interação como o cliente,

mantendo-o próximo à equipe de desenvolvimento, dando feedback constante

a cada release do sistema e a comunicação direta entre os envolvidos na

equipe.

Outra comparação que pode ser feita é no diz respeito às atividades de cada

metodologia, a RUP divide as tarefas de forma específica ao passo que no XP

não há distinção de funções específicas, ou seja, um programador no XP não

está ‗preso‘ a uma tarefa específica, pode participar de outras partes do

projeto.

No XP o código é tratado coletivamente, assim, qualquer programador pode

alterar o código caso perceba alguma anomalia. Na RUP o código é dividido

em subsistemas e é designado um membro para cuidar de cada uma das

partes.

Ambas as metodologias tem pontos fracos ou fortes, e cabe a equipe

designada para o desenvolvimento do projeto decidir qual é mais adequada ao

seu desenvolvimento, levando em conta características como: comunicação,

interação e complexidade do projeto, dentre outras.

http://www.frb.br/ciente/BSI/BSI.CASTRO.%20et%20al%20.F2%20.pdf

Princípios Básicos

Um grande problema nos projetos atuais é o grande dinamismo e

complexidade dos negócios nos dias de hoje. Cada vez mais os sistemas são

complexos e precisam estar prontos em menos tempo. Mais do que isso, as

necessidades mudam ao longo do tempo e a especificação de um sistema

provavelmente será alterada durante seu desenvolvimento. Além disso, temos

tecnologias novas (software e hardware) surgindo a cada dia. Algumas

funcionam bem. Outras não. Visando atacar estes problemas, o RUP adota as

seguintes premissas básicas:



Uso de iterações para evitar o impacto de mudanças no projeto,



Gerenciamento de mudanças e



Abordagens dos pontos de maior risco o mais cedo possível.

Estrutura Básica do RUP

A figura 1 apresenta os elementos básicos do RUP. Nesta metodologia, o

projeto passa por 4 fases básicas. Estas fases são:

(22)

22 

Elaboration - especificação e abordagem dos pontos de maior risco,



Construction - desenvolvimento principal do sistema,



Transition - ajustes, implantação e transferência de propriedade do

sistema

Figura 1: Modelo Básico do RUP

Apesar de parecer um modelo em cascata, na verdade cada fase é composta

de uma ou mais iterações, o que se assemelha a um modelo em espiral. Estas

iterações são em geral curtas (1-2 semanas) e abordam algumas poucas

funções do sistema. Isto reduz o impacto de mudanças, pois quanto menor o

tempo, menor a probabilidade de haver uma mudança neste período para as

funções em questão.

Além das fases e iterações, existem os workflows. Cada workflow é na verdade

uma sequência de tarefas encadeadas e relacionadas a um aspecto importante

do projeto, tal como análise do negócio, testes, etc. Os gráficos da figura

mostram a ênfase de cada workflow em cada etapa do projeto.

Conteúdo do RUP

O que é o RUP afinal? Sabemos neste ponto que é uma metodologia completa

e vimos sua estrutura básica. Porém o que ele oferece?

O RUP, além de uma metodologia, é um produto comercializado pela Rational,

que é uma grande documentação baseada em hipertexto (HTML). Do conteúdo

deste material, destaco os seguintes assuntos:

(23)

23

Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo

as tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos.

Cada tarefa, subproduto e papel é descrito em detalhe. Este modelo pode ser

seguido à risca ou adaptado conforme sua necessidade específica.

Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável

por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e

saída.

Modelo de equipe: Os diversos papéis necessários no projeto são descritos em

detalhe. Assim como no MSF, cada papel pode ser representado por mais de

uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga

de trabalho necessário. Porém o RUP aborda os papéis em um maior nível de

detalhe. Ao todo são mais de 30. Exemplos de papéis são: analista de

sistemas, analista de negócio, etc.

Modelos de documentos: O RUP apresenta modelos e exemplos para os

diversos documentos (artefatos) gerados ao longo do projeto. Estes

documentos são descritos em detalhe, assim como as tarefas que os geram e

as que os utilizam. Para os usuários das ferramentas Rational, existe um

recurso adicional e-coach, que orienta o usuário a usar ferramentas como o

Requisite Pro passo a passo. Os documentos são totalmente compatíveis com

a UML, o que reforça a questão de padronização.

Como Adotar

Com base nestes recursos a adoção do RUP pode ser feita de mais de uma

maneira. Um extremo seria usar o RUP à risca, ou seja, aplicar todos os

métodos e processos exatamente como são propostos. A vantagem desta

abordagem é que nada deve ser alterado, pois o RUP é bem completo e

detalhado. Porém existe um preço a ser pago, pois o RUP na íntegra é

complexo. Esta abordagem implicaria em treinamentos, projetos piloto, etc.

Propostas de projetos de adoção do RUP são descritos no próprio produto.

O extremo oposto seria adotar outro modelo de processo mais simples ou

conhecido (o atual, se existir) e utilizar o material do RUP como fonte de

referência complementar para assuntos não abordados em outro modelo como,

por exemplo, os modelos de documentos.

A primeira abordagem é interessante para empresas que precisam de uma

grande formalização do processo de desenvolvimento de software e cujo

método atual seja totalmente inadequado ou inexistente. A segunda

abordagem seria interessante para quem já tem alguma metodologia que

considera adequada, mas que tem deficiência em alguma área como, por

exemplo, suporte a UML. Soluções intermediárias também são possíveis.

Vimos de forma suscinta o que o RUP é e o que ele oferece. Para aqueles que

desejam mais informações sobre o RUP, sugiro ler o livro ―The Rational Unified

Proccess, An Introduction‖ de Philippe Kruchten, disponível na Amazon. Para

(24)

24

quem deseja ver o produto, uma cópia de avaliação pode ser solicitada a

Rational (http://www.rational.com).

Fonte:

http://www.linhadecodigo.com.br/Artigo.aspx?id=79

O RUP usa desenvolvimento iterativo e incremental pelas seguintes razões:

A integração é feita passo a passo durante o processo de desenvolvimento,

limitando-se cada passo a poucos elementos

A integração é menos complexa, reduzindo seu custo e aumentado sua

eficiência

Partes separadas de projeto e/ou implementação podem ser facilmente

identificadas para posterior reuso

Mudanças de requisitos são registradas e podem ser acomodadas

Os riscos são abordados no inicio do desenvolvimento e cada iteração permite

a verificação de riscos já percebidos bem como a identificação de novos

Arquitetura de software é melhorada através de um escrutino repetitivo

Usando iterações, um projeto terá um plano geral, como também múltiplos

planos de iteração. O envolvimento dos stakeholders é freqüentemente

encorajado a cada entrega. Desta maneira, as entregas servem como uma

forma de se obter o comprometimento dos envolvidos, promovendo também

uma constante comparação entre os requisitos e o desenvolvimento da

organização para as pendências que surgem.

http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process

http://mundo.busca.uol.com.br/buscar.html?ad=on&ref=esporte&origem=barrauol&q=R UP

Alguns dos diagramas da RUP:

Casos de uso

– Possui uma linguagem informal, e é utilizado nas fases de

levantamento e analise de requisitos. É consultado durante todas as fases do

processo de modelagem. Identifica o atores que utilizarão o software, assim

como os serviços a serem oferecidos por ele.

Classes - Considerado um dos mais importantes e o mais utilizado na UML.

Serve como base para todos os outros diagramas. O diagrama de classes tem

ampla ligação com o diagrama de objetos.

Objetos

– complementa o diagrama de classes, visto fornecer um visão dos

valores dos objetos de um diagrama de classes em um determinado momento.

Pacotes

– Mostra os subsistemas englobados por um sistema e é utilizado

independente ou junto com outros diagramas.

Sequência

– A ordem seqüencial com que as mensagens de um sistema são

trocadas são mostradas nesses diagrama, que geralmente se associa a um

diagrama de caso de uso

(25)

25

Além dos diagramas apresentados acima a UML possui ainda outros 9

diagramas para apoiar a modelagem de um sistema.

Fonte: GUEDES, Gilleanes T A. UML: uma abordagem prática / Inclui UML 2. 3

ed. São Paulo: Novatec, 2008

Rational Unified Process

IBM Rational Unified Process®, ou RUP®, é uma plataforma de processo

de desenvolvimento de software configurável que oferece melhores práticas

comprovadas e uma arquitetura configurável.

Permite selecionar e implementar apenas os componentes de processo que

você precisa para cada estágio de seu projeto.

A plataforma RUP® inclui:

Ferramentas para configurar a RUP para as necessidades

específicas de seu projeto.

Ferramentas para desenvolver seu próprio conhecimento interno em

componentes de processo.

Ferramentas de implementação eficientes e personalizáveis

baseadas na Web.

Uma comunidade online para trocar melhores práticas com colegas e

líderes do segmento de mercado.

O objetivo do RUP é assegurar uma produção de alta qualidade de

software, que realiza a necessidade do usuário seguindo prazos e o

orçamento.

Com o advento do CMM as organizações focalizam a qualidade em primeiro

plano e o RUP pode ser bastante útil quando se quer atingir níveis maiores.

A Unified Modeling Language (UML) é uma linguagem de

modelagem

não

proprietária de terceira geração. A UML não é uma

metodologia

de

desenvolvimento, o que significa que ela não diz para você o que fazer primeiro

e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu

desenho e a comunicação entre objetos.

Basicamente, a UML permite que desenvolvedores visualizem os produtos de

seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, a

UML também especifica significados, isto é,

semântica

. É uma notação

independente de

processos

, embora o

RUP

(Rational Unified Process) tenha

sido especificamente desenvolvido utilizando a UML.

(26)

26

É importante distinguir entre um modelo UML e um

diagrama

(ou conjunto de

diagramas) de UML. O último é uma representação gráfica da informação do

primeiro, mas o primeiro pode existir independentemente. O

XMI

(

XML

Metadata Interchange) na sua versão corrente disponibiliza troca de modelos

mas não de diagramas.

Os objetivos da UML são: especificação, documentação, estruturação para

sub-visualização e maior visualização lógica do desenvolvimento completo de

um sistema de informação. A UML é um modo de padronizar as formas de

modelagem.

O RUP utiliza a UML para desenvolvimento dos diagramas do sistema. É

nestes diagramas e suas representações que os analistas e projetistas se

basearão

para finalizar cada ciclo eficazmente, considerando também as mudanças

que podem ocorrer após a entrega de um software em relação ao ambiente,

aos

sistemas operacionais, ao banco de dados e ao hardware.

UML

Diagramas da UML:

1. Diagrama de Caso de Uso

– Defini e descreve os requisitos funcionais de

um sistema.

2. Diagrama de Classes

– Representa os relacionamentos e as estruturas das

classes.

3. Diagrama de Objetos – Apresenta os objetos instanciados das classes.

4. Diagrama de Estado – Complementação da descrição das classes.

5. Diagrama de Seqüência

– Apresenta a colaboração dinâmica entre os vários

objetos de um sistema.

6. Diagrama de Colaboração

– Apresenta a colaboração dinâmica entre os

objetos.

7. Diagrama de Atividade

– Captura as ações e resultados nas mudanças dos

objetos.

8. Diagrama de Componente – Apresenta o sistema pela visão funcional.

9. Diagrama de Execução

– Apresenta a arquitetura física do hardware e do

software no sistema.

(27)

27

Modelagem de Negócio

Requisitos

Finalidades da disciplina Requisitos:

Estabelecer e manter concordância

com os clientes e outros envolvidos sobre o que o sistema deve fazer.

Oferecer aos desenvolvedores do sistema uma compreensão melhor dos

requisitos do sistema.

Definir as fronteiras do sistema (ou delimitar o

sistema).

Fornecer uma base para planejar o conteúdo técnico das

iterações.

Definir uma interface de usuário para o sistema, focado nas

necessidades e metas dos usuários. Análise e Design Finalidades da disciplina

Análise e Design: Transformar os requisitos em um design do sistema a ser

criado.

Implementação

A finalidade da implementação é:

Implementar classes e objetos em termos de componentes

(arquivos-fonte, binários, executáveis e

outros)

testar

os

componentes

desenvolvidos como unidades

integrar os resultados produzidos por

implementadores individuais (ou equipes) ao sistema executável

Testes

O teste enfatiza principalmente a avaliação da:

qualidade do produto

práticas centrais:

Implantação

A Disciplina Implantação descreve as atividades que garantem que o

produto de software será disponibilizado a seus usuários finais.

Gerenciamento de Configuração e Mudança

Um Sistema de CM é fundamental para

Atualização Simultânea:

Quando dois ou mais membros da equipe

trabalham

separadamente

no

mesmo

artefato.

Notificação

Limitada:Quando um problema é corrigido nos artefatos compartilhados

por vários desenvolvedores e alguns deles não são notificados da

mudança.

(28)

28

A disciplina de Ambiente concentra-se nas

atividades

necessárias à

configuração

do processo para um projeto.

A

meta das atividades dessa disciplina é oferecer à organização o ambiente de

desenvolvimento de software

— processos e ferramentas — que dará suporte

à equipe de desenvolvimento. Ela descreve as atividades para o

desenvolvimento das diretrizes de

suporte de um projeto. Várias Versões:

A maioria dos programas de grande porte é desenvolvida em releases

evolutivas.controlar os inúmeros artefatos produzidos

pelas muitas

pessoas que trabalham em um mesmo projeto. O controle ajuda a

evitar

confusões dispendiosas e garante que os artefatos resultantes não

entrem em

conflito

devido a algum dos seguintes problemas:Localizar e

documentar defeitos na qualidade do software.

Avisar de forma geral

sobre a qualidade observada no software.

Validar as suposições feitas

nas especificações de design e requisito através de demonstração

concreta.

Validar as funções do software conforme projetadas.

Verificar

se os requisitos foram implementados de forma adequada., realizada

através de várias

definir a organização do código em termos de subsistemas de implementação

organizadas em camadas Desenvolver uma arquitetura sofisticada para o

sistema.

Adaptar o design para que corresponda ao ambiente de

implementação, projetando-o para fins de desempenho.Fornecer uma

base para estimar o custo e o tempo de desenvolvimento do sistema.

Entender a estrutura e a dinâmica da organização na qual um sistema deve ser

implantado (a organização-alvo). Entender os problemas atuais da

organização-alvo e identificar as possibilidades de melhoria. Assegurar que os

clientes, usuários e desenvolvedores tenham um entendimento comum da

organização-alvo. Derivar os requisitos de sistema necessários para sustentar

a organização-alvo.Finalidades da Modelagem de Negócio

A UML (Unified Modeling Language)é uma linguagem para especificação,

documentação, visualização e desenvolvimento de sistemas orientados a

objetos. Sintetiza os principais métodos existentes, sendo considerada uma

das linguagens mais expressivas para modelagem de sistemas orientados a

objetos.

Por

meio

de

seus

diagramas

é

possível

representar

sistemas de softwares sob diversas perspectivas de visualização.

Facilita a comunicação de todas as pessoas envolvidas no processo

de desenvolvimento de um sistema - gerentes, coordenadores, analistas,

desenvolvedores - por apresentar um vocabulário de fácil entendimento.

Este guia descreve os conceitos da UML e seus diagramas. Apresenta

exemplos de utilização destes diagramas, demostrando, de maneira prática,

como pode ser feita a transição de um diagrama para outro.

Pode ser de utilidade para profissionais que estejam conhecendo a modelagem

de sistemas orientados a objetos, e para alunos dos cursos de Ciência da

Computação, Engenharia de Software, Processamento de Dados e Análise de

Sistemas que estejam estudando o assunto.

(29)

29

Fonte:

http://www.novateceditora.com.br/guias/uml/

A UML (Unified Modeling Language - Linguagem de Modelagem Unificada) Nos

últimos anos, a UML consagrou-se como a linguagem-padrão de modelagem

adotada pela indústria de engenharia de software, existindo atualmente um

amplo mercado para profissionais que a dominem.

Fonte:

http://www.submarino.com.br/produto/1/241945/uml:+uma+abordagem+pratica

Objetivos da UML:

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

http://www.infotem.hpg.com.br/lin_progr_uml.htm

BRAND

Brand é um conceito da área de marketing que atribui ou associa valores da

marca aos seus produtos, ou seja, o mercado reconhe que os produtos da

marca IBM (no caso, IRUP) estão associados à qualidade e desempenho,

mesmo que a IBM não tenha criado o RUP.

UML

É uma linguagem para especificação, documentação, visualização e

desenvolvimento de sistemas orientados a objetos, abrange todas as fases do

projeto desde a especificação de requisitos até a de testes. Esta dividida em

diagramas, cujo o objetivo é fornecer múltiplas visões do sistema a ser

modelado e assim atingir a compleitude da modelagem, permitindo que cada

diagrama complete os outros.

Os diagramas da UML dividem-se em Diagramas Estruturais(Classes,

Estrutura Composta, Objetos, Componentes,implantação e de pacotes ) e

Diagramas Comportamentais(Casos de Uso, Atividades, Máquina de

Estado,Sequência,Colaboraçã , Interação geral e Tempo), sendo que estes

últimos quatros correspondem aos diagramas da subdivisão de diagramas de

Iteração.

Diagramas:

- Caso de Uso: É o diagrama mais geral e informal da UML, é utilizado

normalmente nas fases de levantamento e análise de requisitos do sistema,

(30)

30

embora venha a ser consultado durante o processo de modelagem e possa

servir da base para os outros.

- Classe: É o diagrama mais importante da uml, serve de apoio para os demais.

Como o próprio nome diz define a estrutura das classes utilizadas pelo sistema.

- Objeto: Está amplamente associado ao diagrama de Classe. Na realidade é

praticamente um complemento do diagrama de Classes e bastante dependente

deste. Esse diagrama fornece uma visão dos valores armazenados pelos

objetos de um diagrama de classe em determinado momento da execução de

um processo de software.

- Sequência: Preocupa-se com a ordem temporal em que as mensagens são

trocadas entre os objetos envolvidos em um processo. Em geral baseia-se em

caso de uso definido pelo diagrama de mesmo nome, e apóia-se no diagrama

de classe para determinar os objetos das classes envolvidas em um processo.

- Colaboração: Está amplamente ligado ao de seqüência, um complementa o

outro, as informações mostradas são freqüentemente as mesmas. Visto que

este diagrama não se preocupa com a temporalidade do processo,

concentrando-se em como os objetos estão vinculados e quais mensagens

trocam entre si durante o processo.

- Estado: Este diagrama procura acompanhar as mudanças sofridas dentro de

um determinado processo. Esse diagrama muitas vezes baseia-se em um caso

de uso descrito no diagrama do mesmo nome e apóia-se no diagrama de

classes. O diagrama de estado é utilizado normalmente para acompanhar os

estados por que passa uma instância de uma classe, mas pode ser utilizado

para representar os estados de um caso de uso ou os estados gerais de um

subsistema ou de um sistema completo.

- Atividade: Preocupa-se em descrever os passos a serem percorridos para a

conclusão de uma atividade específica, muitas vezes representada por um

certo grau de complexidade, e não um processo completo como é o caso dos

diagramas de seqüência e colaboração, embora também possa ser utilizado

para tal fim. Esse diagrama concentra-se na representação do fluxo de controle

de uma atividade.

- Componente: Está amplamente associado à linguagem de programação que

será utilizada para desenvolver o sistema modelado. Esse diagrama representa

os componentes do sistema quando o mesmo for implementado em termos de

módulos de código-fonte, bibliotecas, formulários, arquivos de ajuda, módulos

executáveis etc. Ele determina como tais componentes estarão estruturados e

irão interagir para que o sistema funcione de maneira adequada.

- Implantação: Determina as necessidades de hardware do sistema, as

características físicas como servidor, estações, topologia e protocolos de

comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser

executado.

- Pacotes: Seu objetivo é representar os subsistemas englobados por um

sistema de forma a determinar as partes que o compõem. Pode ser utilizado

de maneira independente ou associado com outros diagramas.

(31)

31

- Interação Geral: É uma variação do diagrama de atividade que fornece uma

visão geral dentro de um sistema ou processo de negócio.

- Tempo: Descreve a mudança no estado ou condição de uma instância de

uma classe ou seu papel durante um tempo. Tipicamente utilizada para

demonstrar a mudança no estado de um objeto no tempo em resposta a

eventos externos.

- Estrutura composta: Descreve a estrutura interna de um Classificador, como

uma classe ou componente, detalhando as partes internas que o compõem,

como estas se comunicam e colaboram entre si.

www.edilms.eti.br/

www.livrariacultura.com.br/imagem/capitulo/11017056.pdf

www.novateceditora.com.br/guias/uml/

A Unified Modeling Language (UML) é uma linguagem de modelagem não

proprietária de terceira geração. A UML não é uma metodologia de

desenvolvimento, o que significa que ela não diz para você o que fazer

primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a

visualizar seu desenho e a comunicação entre objetos.

Basicamente, a UML permite que desenvolvedores visualizem os produtos de

seus trabalhos em diagramas padronizados. Junto com uma notação gráfica,

a UML também especifica significados, isto é, semântica. É uma notação

independente de processos, embora o RUP (Rational Unified Process) tenha

sido especificamente desenvolvido utilizando a UML.

É importante distinguir entre um modelo UML e um diagrama (ou conjunto de

diagramas) de UML. O último é uma representação gráfica da informação do

primeiro, mas o primeiro pode existir independentemente. O XMI (XML

Metadata Interchange) na sua versão corrente disponibiliza troca de modelos

mas não de diagramas.

Obs:. Diagramas são meios utilizados para a visualização dos blocos de

construção da UML, utilizando representações gráficas de um conjunto de

elementos que permitem visualizar o sistema sob diferentes perspectivas.

http://pt.wikipedia.org/wiki/UML

Sobre a UML e RUP

A UML possui 14 diagramas. O objetivo destes diagramas é fornecer múltiplas

visões do sistema, permitindo que seja analisado e modelado sob diversos

aspectos. Assim cada diagrama complementa o outro. Essa utilização permite

que falhas sejam descobertas, minimizando a ocorrência de erros futuros.

(32)

32

Alguns diagramas fornecem uma visão mais geral do sistema, enquanto outros

se aprofundam e mostram detalhes mais técnicos. O objetivo porém é o

mesmo, ver o sistema em camadas possibilitando assim, uma analise do

sistema ou parte dele, sob diversas ópticas

Pergunta: - NO DESENVOLVIMENTO DE UM PROJETO DE SOFTWARE

QUAL A RELAÇÃO, SE HOUVER, ENTRE A UML E O RUP?

Resposta: NÃO HÁ.

RUP é um processo de engenharia de software que aborda todo o ciclo de vida

de um projeto e guia as equipes de desenvolvimento no gerenciamento e nas

atividades práticas de engenharia de software.

http://javafree.uol.com.br/topic-4294-RUP.html

A UML não é uma metodologia de desenvolvimento, o que significa que ela não

diz para você o que fazer primeiro e em seguida ou como projetar seu sistema,

mas ela lhe auxilia a visualizar seu desenho e a comunicação entre os objetos

http://javafree.uol.com.br/topic-4294-RUP.html

A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz

para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela

lhe auxilia a visualizar seu desenho e a comunicação entre os objetos.

O projeto poderá ser anulado ou completamente repensado caso o marco não

seja atingido.

Princípios do Processo

O RUP se norteia em princípios largamente utilizados no desenvolvimento de

software desde o seu surgimento até os dias presentes. O processo, ao

contrário que muitos pensam, não prega que devemos fazer tudo exatamente

como está no papel, ele prega que devemos seguir as boas práticas de

desenvolvimento de software e ele se propõe a ser um guia que ajuda na

construção de software de qualidade.

Equilibrar prioridades dos investidores: Esse princípio prega que devemos

equilibrar as necessidades dos investidores do projeto como o desenvolvimento

de customizações VS e a reutilização de recursos. A idéia do RUP é de

otimizar ao máximo o valor do negócio.

De forma enfática, o RUP prega que, para podemos atender e priorizar as

necessidades dos investidores de forma correta, precisamos gerenciar os

requisitos efetivamente. Para que isso aconteça de forma efetiva é necessário

(33)

33