Diagramas de Seqüência mostram a troca de mensagens (isto é chamada de método) entre diversos Objetos, numa situação específica e delimitada no tempo. Objetos são instâncias de classes. Diagramas de Seqüência colocam ênfase especial na ordem e nos momentos nos quais mensagens para os objetos são enviadas.

Em Diagramas de Seqüência objetos são representados através de linhas verticais tracejadas, com o nome do Objeto no topo. O eixo do tempo é também vertical, aumentando para baixo, de modo que as mensagens são enviadas de um Objeto para outro na forma de setas com a operação e os nomes dos parâmetros.

Mensagens pode ser síncronas, o tipo normal de mensagem de chamada onde o controle é passado para o objeto chamado até o método ter terminado sua execução, ou assíncronas onde o controle é passado diretamente para o objeto chamado. Mensagens síncronas possui uma caixa vertical no lado do objeto chamado para mostrar o controle do fluxo do programa.

Diagramas de Colaboração mostram as interações que ocorrem entre os objetos participantes numa situação específica. Isto é mais ou menos a mesma informação mostrada pelos Diagramas de Seqüência, mas neste a ênfase é colocada em como as interações ocorrem no tempo, enquanto os Diagramas de Colaboração colocam os relacionamentos entre os objetos e sua topologia em destaque.

Em Diagramas de Colaboração as mensagens enviadas de um objeto para outro são representadas por setas, mostrando o nome da mensagem, parâmetros, e a seqüência da mensagem. Diagramas de Colaboração são especialmente indicados para mostrar um fluxo ou situação específica do programa e são um dos melhores tipos de diagrama para rapidamente demonstrar ou explanar um processo na lógica do programa.

Diagramas de Classe podem conter diversos outros ítens além das classes.

Interfaces

Interfaces são classes abstratas que significam instâncias que não podem ser diretamente criadas delas. Elas podem conter operações mas não podem conter atributos. Classes podem derivar de interfaces (através da realização de uma associação) e instâncias podem então ser feitas destes diagramas.

Tipos de dados

Tipos de dados são primitivos uma vez que são tipicamente construídos numa linguagem de programação. Exemplos comuns são inteiros e lógicos. Eles não podem ser relacionados à classes mas classes pode se relacionar com eles.

Enumerações

Enumerações são uma lista simples de valores. Um exemplo típico é uma enumeração para dias da semana. As opções de uma enumeração são chamadas Literais de Enumeração. Como tipos de dados, elas não podem ter relacionamentos para classes mas classes podem relacionar-se com elas.

Pacotes

Pacotes representam um espaço de nomes numa linguagem de programação. Num diagrama eles são usados para representar partes de um sistema que contém mais de uma classe, talvez centenas de classes.

Classes podem relacionar-se (ser associada com) com outras de diferentes maneiras:

Generalização

Herança é um dos conceitos fundamentais da programação Orientada à Objeto, na qual uma classe “herda” todos os atributos e operações da classe da qual deriva, e pode sobrescrever/modificar alguns deles, bem como adicionar mais atributos e operações próprios.

EM UML, uma associação Generalização entre duas classes coloca-as numa hierarquia representando o conceito de herança de uma classe derivada de uma classe base. Em UML, Generalizações são representadas por uma linha conectando duas classes, com uma seta no lado da classe base.

Associações

Um associação representa um relacionamento entre classes, e fornece a semântica comum e a estrutura para muitos tipos de “conexões” entre objetos.

Associações são o mecanismo que permite objetos comunicarem-se entre si. Elas descrevem a conexão entre diferentes classes (a conexão entre os objetos atuais é chamada conexão do objeto, ou link.

Associações podem ter um regra que especifica o propósito da associação e pode ser uni ou bidirecional (indicadando se os dois objetos participantes do relacionamento podem mandar mensagens para o outro, ou se apenas um deles sabe sobre o outro). Cada ponta da associação também possui uma valor de multiplicidade, que dita como muitos objetos neste lado da associação pode relacionar-se com o outro lado.

Em UML, associações são representadas como linhas conectando as classes participantes do relacionamento, e podem também mostrar a regra e a multiplicidade de cada um dos participantes. A multiplicidade é exibida como um intervalo [min...máx] de valores não negativos, com uma estrela (*) no lado máximo representando infinito.

Agregação

Agregações são um tipo especial de associação no qual as duas classes participantes não possuem em nível igual, mas fazem um relacionamento “todo-parte”. Uma Agregação descreve como a classe que possui a regra do todo, é composta (tem) de outras classes, que possuem a regra das partes. Para Agregações, a classe que age como o todo sempre tem uma multiplicidade de um.

Em UML, Agregações são representadas por uma associação que mostra um rombóide no lado do todo.

Composição

Composições são associações que representam agregações muito fortes. Isto significa que Composições formam relacionamentos todo-parte também, mas o relacionamento é tão forte que as partes não pode existir independentes. Elas existem somente dentro do todo, e se o todo é destruído as partes morrem também.

Em UML, Composições são representadas por um rombóide sólido no lado do todo.

Diagramas de Classe mostram as diferentes classes que fazem um sistema e como elas se relacionam. Os Diagramas de Classe são chamados diagramas “estáticos” porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas: quais classes “conhecem” quais classes ou quais classes “são parte” de outras classes, mas não mostram a troca de mensagens entre elas.

Classe

Um Classe define os atributos e os métodos de um conjunto de objetos. Todos os objetos desta classe (instâncias desta classe) compartilham o mesmo comportamento, e possuem o mesmo conjunto de atributos (cada objeto possui seu próprio conjunto). O termo “Tipo” é algumas vezes usado ao invés de Classe, mas é importante mencionar que estes dois termos não são a mesma coisa, e Tipo é um termo mais genérico.

Em UML Classes são representadas por retângulos, com o nome da classe, e podem também mostrar os atributos e operações da classe em dois outros “compartimentos” dentro do retângulo.

Atributos

Na UML, atributos são mostrados com pelo menos seu nome, e podem também mostrar seu tipo, valor inicial e outras propriedades. Atributos podem também ser exibidos com sua visibilidade:

• + indica atributos públicos
• # indica atributos protegidos
• - indica atributos privados

Operações

Operações (métodos) também são exibidos com pelo menos seu nome, e podem também mostrar seus parâmetros e valores de retorno. Operações podem, como os Atributos, mostras sua visibilidade:

• + indica operações públicas
• # indica operações protegidas
• - indica operações privadas

Modelos

Classes podem ter modelos, um valor que é usado para uma classe ou tipo não especificado. O tipo de modelo é especificado quando uma classe é iniciada (isto é um objeto é criado). Modelos existem no C++ moderno e foram introduzidos no Java 1.5 onde eles são chamados de Genéricos.

Diagramas de Caso de Uso não são adequados para representar o desenho, e não podem descrever os mecanismos internos de um sistema. Diagramas de Caso de Uso são feitos para facilitar a comunicação com os futuros usuários do sistema, e com o cliente, e são especialmente úteis para determinar os recursos necessários que o sistema deve ter. Diagramas de Caso de Uso dizem o quê o sistema deve fazer, mas não fazem e não podem especificar como isto será conseguido.

Um Caso de Uso descreve um grupo de atividades num sistema que produz um resultado concreto e tangível.

Casos de Uso são descrições de interações típicas entre os usuários de um sistema e o sistema propriamente dito. Eles representam a interface externa do sistema e especificam um conjunto de exigências do que o sistema deve fazer

algumas regras simples Quando trabalhar com Casos de Uso

• Cada Caso de Uso está relacionado com no mínimo um ator
• Cada Caso de Uso possui um iniciador (isto é um ator)
• Cada Caso de Uso liga-se a um resultado relevante (um resultado com “valor de negócio”)
• Casos de Uso também podem ter relacionamentos com outros Casos de Uso. Os três tipos mais comuns de relacionamento entre Casos de Uso são:
  • <<inclui-se>> que especifica que um Caso de Uso toma lugar dentro de outro Caso de Uso
  • <<estende>> que especifica que em determinadas situações, ou em algum ponto (chamado um ponto de extensão) um Caso de Uso será estendido por outro.
  • Generalização especifica que um Caso de Uso herda as características do “Super” Caso de Uso, e pode sobrepor algumas delas ou adicionar novas de maneira semelhante a herança entre classes.

  Ator

  Um ator é uma entidade externa (fora do sistema) que interage com o sistema participando (e freqüentemente iniciando) um Caso de Uso. Atores podem ser pessoas reais (por exemplo usuários do sistema), outro sistema de computador ou eventos externos.

• Descrição do Caso de Uso são narrativas de texto do Caso de Uso. Elas usualmente tomam a forma de uma nota ou um documento que é de alguma maneira ligado ao Caso de Uso, e explana o processo ou atividades que tomarão lugar no Caso de Uso.

O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade.

O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.

É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala. Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software.

O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela Rational através de seus “Rational Suites”.

Métodos concorrentes no campo da engenharia de software incluem o “Cleanroom” (considerado pesado) e os Modelos Ágeis (leves) como a Programação Extrema.

Linhas mestras
O RUP define as seguintes linhas-mestras e esqueletos (templates) para os membros da equipe de um ciclo de produção:

parte do cliente, e uma avaliação do progresso do projeto pela sua gerência. Além disso, ajuda os programadores a manterem-se concentrados no projeto.

Gestão de requisitos
Uma documentação apropriada é essencial para qualquer grande projeto; note-se que o RUP descreve como documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio.

Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, que têm sido considerados muito mais eficazes na captura de requisitos funcionais.

Uso de arquitetura baseada em componentes
A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo. Um componente normalmente se relaciona com um objeto na programação orientada a objetos.

O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala.

Estes componentes são normalmente incluidos em infraestruturas existentes como o CORBA e o COM (Modelo de Componentes de Objectos).

Uso de software de modelos visuais
Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução. O uso de modelos visuais também pode permitir que indíviduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.

A línguagem de modelação UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP.

Verificação da qualidade do software
Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa-se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade por uma equipe diferente da equipe de desenvolvimento. O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.

Gestão e Controle de Mudanças do Software
Em todos os projectos de software a mudança é inevitável. O RUP define métodos para controlar e monitorizar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisiveis, o controle de mudanças é essencial para o sucesso de um projeto.

O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.

Fases
Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida de um projecto. As fases indicam a ênfase que é dada no projeto em um dado instante. Para capturar a dimensão do tempo de um projecto, o RUP divide o projecto em quatro fases diferentes:

Concepção: ênfase no escopo do sistema
Elaboração: ênfase na arquitetura
Construção: ênfase no desenvolvimento
Transição: ênfase na implantação
O RUP também se baseia nos 4 P’s:

Pessoas
Projeto
Produto
Processo
As fases são compostas de iterações. As iterações são janelas de tempo; as iterações possuem prazo definido enquanto as fases são objetivas.

Todas as fases geram artefatos. Estes serão utilizados nas proximas fases e documentam o projeto. Além de permitir melhor acompanhamento.

A Fase de concepção
A fase de concepção contém os workflows necessários que as partes interessadas (stakeholders) concordem com os objetivos, arquitetura, e o planejamento do projeto [... ] se as partes interessadas tiverem bons conhecimentos, pouca análise será requerida então. Se não tiverem o conhecimento necessário, mais análise será requerida.

Como cita o RUP, o ideal é que sejam feitas iterações. Porém estas devem ser bem definidas quanto a sua quantidade e objetivos.

Criado por Jader e Jonathan.

Em 1990, com a adoção da orientação a objetos por parte de desenvolvedores e analistas de todo o mundo fez-se necessária a criação de novas metodologias, que colocassem mais ordem ao caos vigente no desenvolvimento de software. Além disso, buscava-se obter o hoje chamado reúso, ou seja, o reaproveitamento de código já escrito. Dentre as várias metodologias que surgiram para atender a esta demanda, destacam-se o Processo Unificado da Rational (RUP), e os Modelos Ágeis, um dos quais é o Extreme Programming (XP), criado por Kent Beck no fim da década de 90.

Vê-se que Extreme Programming têm uma maior leveza e simplicidade quando comparada a RUP, que também é amplamente empregada. Enquanto RUP prega uma maior formalidade e preocupação com documentação, que tornam o processo mais “pesado” e resistente à mudanças, XP recomenda que mudanças sejam prontamente “abraçadas” , aceitas sem relutância, pois parte-se do princípio de que alterações de projeto são inevitáveis, e o custo destas alterações não é alto como antigamente, mesmo na fase de implementação do software, idéia que é defendida por Beck (2004) e Wuestefeld (2001), entre outros. Isto é válido sobretudo quando se agrega ao processo características como simplicidade e um rápido feedback por parte dos clientes, que como já foi dito são os valores essenciais em Extreme Programming.

Quando se fala em simplicidade, o que se afirma é que deve-se ser objetivo e fazer um design simplificado e incremental do sistema. O código implementado também deve ser o mais simples e “enxuto” possível. Código e testes devem comunicar tudo o que analistas e desenvolvedores precisam saber, e nenhum código deve ser repetido, em princípio. Os nomes dos métodos, variáveis e demais entidades também devem ser significativos. Estes fatos já seriam suficientes para notarmos a importância da adoção de padrões de codificação.

Criar um sistema simples que resolva de forma elegante uma demanda não é tarefa fácil. Além disso, quando se projeta um “sistema simples” deve-se ter em mente todos os requisitos do mesmo, que normalmente não podem ser menosprezados. Extreme Programming valoriza sistemas simples, não simplórios e/ou medíocres.

Outro fato a se considerar é a relatividade da simplicidade. Ao se mostrar soluções distintas para equipes diferentes, com conhecimentos diferentes, certamente a solução mais simples aos olhos de uma das equipes não será necessariamente a solução mais simples aos olhos da outra.

XP recomenda que se uma solução funciona em determinado lugar deve-se tentar usá-la em outro contexto, mesmo em escalas diferentes. Obviamente nem sempre tal procedimento funcionará, mas em muitos casos é um bom ponto de partida .

Outro princípio aparentemente controverso em XP é o da falha. A metodologia recomenda que em alguns casos, se você não sabe o que fazer, arrisque-se a falhar, implementando soluções que você não sabe se funcionarão, a fim de descobrir se elas serão boas soluções ou não. Em alguns casos, o tempo gasto será menor do que o tempo decorrido em extensas discussões sobre diferentes soluções com a equipe .

Obviamente, caso seja realmente considerado este princípio requer bom-senso. Ir direto para implementações sem um mínimo de reflexão e discussão vai contra a comunicação, que é um valor crucial em XP. Além disso, em alguns casos (possivelmente na maioria deles) a equipe de desenvolvimento chega a um relativo consenso sem a necessidade de longas e exaustivas discussões, o que leva a apenas uma tentativa de implementação inicial (que espera-se ser a mais adequada, obviamente).

Em XP o desenvolvimento (incluindo design e outras etapas) é feito em forma de pequenos incrementos, partindo-se do pressuposto que o overhead de pequenos passos é bem menor do que o tempo perdido quando grandes mudanças mostram-se incorretas depois. Várias práticas em Extreme Programming são concretizações deste princípio, como os testes antes do código e a integração contínua.

A programação em pares é certamente a prática mais característica e mais controversa de XP, pois recomenda que a implementação do código seja feita sempre por pares de desenvolvedores (em apenas um computador por par). Note-se que está se falando da implementação: idéias podem – e devem – ser pensadas também individualmente.

Beck (2004) enumera algumas vantagens da programação em pares. Segundo ele os parceiros:

Mantêm um ao outro focado no trabalho.

Realizam refinamentos no sistema (brainstorms);

Tornam idéias mais claras;

Possivelmente tomam iniciativa quando o outro não sabe o que fazer;

Estimulam-se a cumprir as práticas com mais rigor.

Ainda segundo Beck (2004), a programação em pares é cansativa e usualmente desenvolvedores conseguem realizá-la por no máximo 6 horas por dia.

Uma prática essencial em Extreme Programming (mas não exclusiva desta metodologia) é o uso de padrões de projeto. O objetivo é aumentar consideravelmente o reúso, e consequentemente a velocidade de desenvolvimento. Além disso, a manutenção do sistema torna-se mais fácil, devido à maior simplicidade e similaridade com outros sistemas já criados.

Ao que tudo indica, os fatos se mostram favoráveis a Extreme Programming. Amorin (2006), que inicialmente também duvidava dos benefícios da metodologia, confirma a afirmação de Beck: ao se utilizar as práticas em conjunto, obtém-se melhorias dramáticas de desempenho. Brad Jensen, vice-presidente da Airline Products Development, Sabre Airline Solutions, afirma em entrevista a Beck (2004) que utilizou XP em uma equipe de 300 pessoas. Os resultados foram aparentemente excelentes: Um dos sistemas não apresentou um único erro em dois anos de uso. A taxa média de erros segundo Jensen é de um ou dois a cada mil linhas de código. Ainda segundo ele, o Bangalore SPIN, que consiste em dez empresas Capability Maturity Model (CMM) nível 5, reporta uma taxa média de oito defeitos a cada mil linhas, portanto muito superior.

Não se afirmará aqui que todos os princípios e práticas de Extreme Programming são válidos, nem tampouco se afirmará o oposto. De qualquer maneira, trata-se de uma metodologia que tem seu mérito por propor soluções inovadoras, humanas, criativas, objetivas e ágeis e que trazem resultado real em alguns contextos, além de romper corajosamente paradigmas ultrapassados do desenvolvimento de sistemas e dar novos ares a esta ciência.

Texto Resumido Retirado de

Extreme Programming – Valores, Princípios e Práticas

Por

Alexandre de Castro Gontijo

Monografia final de Curso

Prof. Dr. Roberto da Silva Bigonha

Orientador

Diagrama de Caso de Uso mostra atores (pessoas ou outros usuários do sistema), casos de uso (os cenários onde eles usam o sistema), e seus relacionamentos

Diagrama de Classe mostra classes e os relacionamentos entre elas

Diagrama de Seqüência mostra objetos e uma seqüência das chamadas do método feitas para outros objetos.

Diagrama de Colaboração mostra objetos e seus relacionamentos, colocando ênfase nos objetos que participam na troca de mensagens

Diagrama de Estado mostra estados, mudanças de estado e eventos num objeto ou uma parte do sistema

Diagrama de Atividade mostra atividades e as mudanças de uma atividade para outra com os eventos ocorridos em alguma parte do sistema

Diagrama de Componente mostra os componentes de programação de alto nível (como KParts ou Java Beans).

Diagrama de Distribuição mostra as instâncias dos componentes e seus relacionamentos.

Existem vários tipos de diagramas UML:

->Diagramas estruturais:

           *Diagrama de objetos – mostra objetos instanciados das classes

           *Diagrama de classes – é uma representação da estrutura e relações das classes que servem de modelo para objetos. Existem dois tipos de associação entre classes: agregação(quando um objeto não depende do outro para existir) e composição(quando um objeto não existe sem o outro)