O documento discute metodologias de desenvolvimento de software, especificamente o Rational Unified Process (RUP). O RUP é uma metodologia iterativa e incremental que utiliza a linguagem UML para modelagem. Ele define atividades como análise, projeto e implementação ao longo de fases como iniciação, elaboração e construção.

1. Disciplina Engenharia de Software Ferramentas para análise - Metodologias Orientadas a Objetos
Prof. Esp. Rafael H Mauro
rafaelherman@yahoo.com.br

2. Metodologia de Desenvolvimento de Software
•Metodologia em um sentido amplo é o conjunto de métodos, regras e postulados empregados por uma disciplina, procedimento particular ou conjunto de procedimentos.

3. Metodologia de Desenvolvimento de Software
•Metodologia de Engenharia de Software pode ser considerada como uma lista de regras e diretrizes combinadas com alguma notação gráfica para modelar os requisitos e o projeto do sistema

4. Metodologia de Desenvolvimento de Software
•Adotar uma metodologia para desenvolvimento de software significa munir-se de um conjunto de princípios , normas ferramentas conceituais, técnicas procedimentos e documentos que permitam ao engenheiro de software implementar sem ambigüidade a especificação contida no ciclo de vida do software.

5. Benefícios da adoção de uma metodologia
•Os benefícios da adoção de uma Metodologia de Desenvolvimento de Software implicam em:
 Desenvolvimento mais rápido;
 Redução dos custos de desenvolvimento;
 Geração de código automatizado;
 Erros detectados mais cedo e por análise automática e estática;
 Padronização de produtos(documentos, especificação, etc.);
 Facilidade do controle do processo;
 Melhor qualidade do produto desenvolvido;
 Maior possibilidade do reuso dos produtos em várias etapas; e
 Maior facilidade de manutenção.

6. A Necessidade de uma Metodologia
•A partir do momento em que surge a necessidade de racionalizar o processo produtivo referente a qualquer atividade produtiva humana, se faz necessário o emprego de uma metodologia que vise a atender os objetivos organizacionais associados a:
 Padronização (documentos, métodos, técnicas, etc.);
 Planejamento;
 Controle;
 Produtividade;
 Eficiência;
 Qualidade; e etc.

7. Especificação de uma Metodologia
•O pré-requisito indispensável para a especificação de uma Metodologia de Desenvolvimento de software é a definição do ciclo de vida do software a ser adotado no processo de desenvolvimento do software. O ciclo de vida do software constitui o modelo de implementação de mais alto nível de abstração. O ciclo de vida do software especifica: 1. As macros atividades a serem executadas durante o processo; 2. A seqüência de execução de cada atividade; e 3. Identifica, para cada atividade, seus pré-requisitos, produto(s), ponto(s) de controle(s), forma de controle, etc.

8. Especificação de uma Metodologia
•Uma Metodologia de Desenvolvimento de Software detalhará o ciclo de vida, especificando um conjunto completo, único e internamente coerente de:
–Princípios
–Técnicas
–Linguagem de representação(ferramentas conceituais)
–Normas
–Procedimentos
–Documentos
•que permitam ao Engenheiro de Software implementar sem ambigüidade a especificação contida no ciclo de vida do software

9. Especificação de uma Metodologia
•Problema metodológico: uma questão pertencente à administração do desenvolvimento e não à tecnologia do desenvolvimento, em outras palavras, pode-se dizer que:
–1. O engenheiro de software, enquanto técnico do desenvolvimento caberia dominar um conjunto de técnicas e ferramentas que lhe permitissem construir software de boa qualidade, eficiente e eficaz
–2. O engenheiro de software enquanto administrador do desenvolvimento, caberia dominar um conjunto de critérios e de conhecimentos técnicos que lhe permitisse estabelecer - dado o ambiente de desenvolvimento e o tipo de software a ser desenvolvido, e elevado interesse da organização em que o processo ocorresse - a metodologia mais adequada à construção de um produto de boa qualidade, respeitando prazos e custos pré-estabelecidos.

10. Especificação de uma Metodologia
•Aplicação e Evolução de uma Metodologia possui uma abordagem puramente empírica (pesquisa e desenvolvimento)
•É necessário também que os grupos desenvolvam, em ambiente de desenvolvimento controladamente variado, um trabalho fortemente experimental, utilizando diferentes ferramentas e técnicas de desenvolvimento de sistemas, para produzir software de diferentes tipos.

11. Avaliação de uma Metodologia
•Não possui um valor intrínseco, mensurável por si mesmo, independente de parâmetros externos qualificadores. Em nível alto de abstração, esses parâmetros devem referir-se:
–Aos objetivos organizacionais;
–Ao ambiente de desenvolvimento onde será implantada;
–Ao tipo de software a ser desenvolvido.
•Uma proposta metodológica deveria conter sua própria mensuração buscando explicitar:
 Os parâmetros externos em relação aos quais foi testada (sempre que possível quantitativamente);
 O nível de coerência interna (e/ou integração) entre as alternativas tecnológicas (ferramentas e técnicas) adotadas;
O nível de suporte automatizado para as alternativas tecnológicas adotadas.

12. Avaliação de uma Metodologia
•Considerando o Desenvolvimento de Software como um processo de construção de sucessivos modelos de um sistema do mundo “real”, iniciado em um nível elevado de abstração relativamente às caraterísticas “físicas” da tecnologia computacional, até chegar a um modelo de automação final, executável total ou parcialmente por computador, o ciclo de vida do software, contém em geral, as seguintes atividades:
 Especificação de necessidades (análise de requisitos);
 Especificação de Requisitos ; projeto (design);
 implementação do software;
 implantação e manutenção do software; e
 Correção, Verificação e Validação.

13. Especificação de necessidades (análise de requisitos)
•Uma característica essencial de um sistema sócio-técnico é atender as necessidades do mundo exterior. Essas necessidades podem ser especificadas por diferentes técnicas:
–Levantamento detalhado do ambiente;
–Levantamento dos eventos externo aos quais os sistemas deve reagir;
–Pesquisa do mercado; e etc.
•Linguagem Textual
•Carência de ferramentas de apoio eficazes
•Os resultados desta fase são utilizados para validação

14. Especificação de Requisitos ; projeto (design)
•Durante essa atividade, inicia-se a modelagem interna do sistema. Nessa etapa podem ser utilizadas:
–A análise funcional
–A análise de dados
–Análise e Projeto Orientados a Objetos
•Ferramentas (ou diagramas) utilizados
–Diagrama de Fluxo de Dados - DFD;
–Diagrama Entidades-Relacionamentos - DER;
–Diagrama de Estado-Transição - DET
–Diagramas de Rede de Petri.
–Diagramas da Linguagem UML

15. Projeto de Software (Design).
•Detalhamento incorpora as características da tecnologia de automação a ser empregada, seu produto devendo ser validado em relação ao resultado da atividade anterior.
•Nesta etapa podem ser usados dois tipos de variante do projeto estruturado, que são o Orientado por dado e o Orientado por função.
•Problema: Descontinuidade em relação à atividade anterior somada a carência de ferramentas automatizadas que dêem apoio a sua execução.
–A orientação a objetos elimina este problema
•É abundante a quantidade de documentos, normas e procedimentos propostos para a execução dessa fase.

16. Implementação do software
•Codificação do modelo
•Preocupação com:
–A correção;
–A eficiência; e
–A flexibilidade dos aspectos executáveis do modelo construído.
•Utilização de ferramentas como:
–Compiladores;
–Interpretadores;
–Editores;
–Depuradores;
–Geradores de código ;
–Geradores de Massa de Teste;
–Formuladores de Código Fonte;
–Analisadores Estáticos, etc.

17. Implantação e manutenção do software
•A modelagem completa do processo de desenvolvimento de software exige modelos para as atividades de Implantação e manutenção.
•Manutenção costuma consumir uma grande quantidade de recursos alocados ao processo.

18. Correção, Verificação e Validação
•Essas atividades, em geral, estão inseridas nos intervalos que separam as atividades geradoras do modelo de automação
•Têm por objetivo garantir a consistência global do processo de desenvolvimento.
•Devem garantir que o produto de cada etapa do ciclo de vida atenda a seus pré-requisitos, produza respostas corretas e respeite as restrições impostas ao processo.

19. Metodologia
•Uma Metodologia identifica as principais atividades (análise, projeto, codificação, teste) a serem executadas e indica quais pessoas (usuários, gerentes, técnicos) devem estar envolvidos em cada atividade e que papel deverão desempenhar.
•Também descreve os critérios de entrada, os critérios de saída e os pontos de conferências para decisões de prosseguir ou não no processo de desenvolvimento do software.
•As metodologias mais populares:
–Técnicas estruturadas ou técnicas de engenharias de informação (metodologias estruturadas e metodologias de engenharia de informação)
–As técnicas orientadas a objeto e a metodologia orientada a objeto oriundas dessas técnicas, têm atraído muita atenção

20. REFORÇANDO..........

21. Exemplos de Processos de Desenvolvimento
•Processo
–APE: Análise e Projeto Estruturados
•DeMarco, Page-Jones, Gane-Sarson
–APOD: Análise e Projeto Orientados a Dados
•Jackson, Warnier-Orr
–APOO: Análise e Projeto Orientados a Objeto
•Modelo Iterativo
»Booch, OMT, OOSE
»(R)UP: (Rational) Unified Process
»

22. Metodologia de Desenvolvimento
•Metodologia = Processo + Linguagem
•A linguagem define formalmente os artefatos produzidos ao longo do processo
•UML: Unified Modeling Language
–UML é uma linguagem orientada a objeto e unificada
•Cobre as atividades de análise e design
•Unificação é uma grande vantagem
–Evita problemas de “impedance mismatch”
•Metodologia de Desenvolvimento Adotada na Disciplina
–(R)UP + UML

23. RUP

24. O Que é RUP?
O RUP (Rational Unified Process) é um processo de engenharia de software desenvolvido pela empresas Rational.
Ele serve como um guia de como utilizar de maneira eficiente a UML (Unified Modeling Language).
Utiliza desenvolvimento Iterativo e Incremental.
Tem como objetivo oferecer um processo de desenvolvimento “bem definido” e “bem gerido”.

25. Histórico

26. “Melhores” Práticas do RUP
São seis:
1. Desenvolvimento de software interativo
2. Gerenciamento de Requisitos
3. Arquitetura baseada em Componentes
4. Modelo de Software Visual (UML)
5. Verificação contínua da qualidade do Software
6. Gerenciamento e controle de mudanças

27. Processo
Pode ser dividido em duas dimensões:
1. Horizontal (Dinâmico)
2. Vertical (Estático)

28. Processo (Dinâmico)
Iniciação (Inception)
Definição do escopo do projeto, identificação dos atores, casos de uso e descrição dos mais significativos
Elaboração (Elaboration)
Análise do sistema, definição da arquitetura de software
Construção (Construction)
Desenvolvimento iterativo e incremental do produto
Transição (Transition)
Atividades de “entrega” do software
CADA FASE PODE SER DECOMPOSTA EM ITERAÇÕES

29. Processo (Estático)
Estruturo do processo:
Intervenientes (Workers) - Quem? (who)
Atividades (Activities) - Como? (how)
Artefatos (Artifacts) - O Que? (what)
Fluxo de Trabalho (Workflows) - Quando? (when)

30. Processo (Estático)
Fluxo de Trabalho (Workflow)

31. Processo (Estático)
Fluxo de Trabalho “Chave”:
Fluxo de Trabalho de Engenharia (Engineering)
1. Modelação do negócio (Business modeling)
2. Levantamento de Requisitos (Requirements)
3. Análise & Projeto (Analysis & Design)
4. Implementação (Implementation)
5. Testes (Test)
6. Implantação (Deployment)
Fluxo de Trabalho de Suporte (Supporting)
1. Gerência de projeto (Project Management)
2. Gerência de configuração e mudança (Configuration and Change Management)
3. Ambiente (Environment)

32. Qualidade, Padrões e Estratégia de Testes
•Qualidade: Verificação a cada artefato/atividade;
•Padrões: Guidelines definidos pelo usuário do processo;
•Estratégias de Testes: Não restritivo, porém recomenda a verificação da qualidade dos testes aplicados;

33. Diretrizes para o Gerenciamento do Projeto
 O gerenciamento de projeto de software é a arte de equilibrar objetivos concorrentes, gerenciar risco e superar limites para entregar com sucesso um produto que vá ao encontro das necessidades dos clientes e dos usuários. Os propósitos do gerenciamento de projeto são:
 Fornecer uma estrutura para gerenciar projetos de software- intensivo;
 Fornecer diretrizes práticas para planejar, montar equipes, executar, e monitorar projetos;
 Fornecer uma estrutura para gerenciamento de risco;
 O papel de gerente de projeto é alocar recursos, modelar prioridades, coordenar interações com clientes e usuários, e manter a equipe do projeto focalizada no objetivo.
 O gerente de projeto estabelece um conjunto de práticas que assegurem integridade e qualidade aos artefatos do projeto.

34. Diretrizes para o Gerenciamento do Projeto
 A disciplina de Gerenciamento do Rational Unified Process (RUP) não tenta cobrir todos os aspectos de gerenciamento de projeto. Por exemplo, não cobre questões como:
 Gerência de pessoal: contratação, treinamento, instrução
 Gerência de orçamento: definição, alocação
 Gerência de contratos, com fornecedores e clientes

35. Diretrizes para o Gerenciamento do Projeto

36. Rational Suite Enterprise
•Rational RequisitePro Gerência de Requisitos
•Rational Unified Process Engenharia de Processo
•Rational Rose Análise/Projeto
–Rational QualityArchitect Gerador de Stubs para Teste
•Rational PurifyPlus Suite para Teste
–Purify -Análise de memória
–Quantify -Análise de desempenho
–PureCoverage -Cobertura de código
•Rational Robot Automação de Testes
•Rational TestManager Gerência de Testes
•Rational ProjectConsole Gerência de Projeto
•Rational ClearCase LT Gerência de Versão
•Rational ClearQuest Gerência de Mudança

37. UML

38. •Porque utilizar UML?
–Padronização dos Métodos OO
•UML: O que é?
•Diagramas e Processo de Software
–Processo de desenvolvimento e os Diagramas da UML
–Diagramas UML: Usos Comuns
•Diagramas:Teoria e exemplos
–Casos de Uso, Classe, Seqüência, Estados, Atividades
•Estudo de Caso.
•Exercícios

39. Porque utilizar UML?
•UML é o resultado da combinação (unificação) de três métodos
–Métodos de Booch, Rumbaugh (OMT) e Jacobson (OOSE)
–Tem alcance maior do que seus “originários”
•Padrão “de fato” para modelagem de software OO
•Passou por um processo de padronização pela OMG (Object Management Group)
•Comunicação
–Diferentes grupos de desenvolvedores possuem o mesmo entendimento dos modelos

40. Porque utilizar UML?
•Modelagem de sistemas de software (e outros)
–Parte central para implantação de um bom software
–Modelo – Abstração da realidade (simplificação)
–Comunicação de aspectos de sistemas de SW:
•Estrutura
•Comportamento
•UML fornece a notação e a semântica suficientes para modelagem de sistemas de software

41. UML: O que é?
•Unified Modeling Language - UML
•Linguagem de Modelagem Unificada
•A UML é uma linguagem-padrão para a elaboração da estrutura de projetos. Possui três elementos principais:
–Blocos básicos de construção da UML
–Regras que determinam como estes blocos deverão ser combinados
–Mecanismos básicos que se aplicam a toda a linguagem
•A UML é apenas uma parte de um método para desenvolvimento de software.
•A UML é independente do processo de desenvolvimento de software
–Processo orientado a casos de usos, centrado na arquitetura, iterativo e incremental.

42. UML: O que é?
•A UML é destinada a:
–Visualizar (notação com semântica bem-definida)
–Especificar (definir modelos precisos, sem ambigüidades e completos)
–Construir (modelos podem ser mapeados para linguagens de programação e tabelas de BD (Relacionais ou OO). É possível a execução direta dos modelos, a simulação e a instrumentação de sistemas em execução)
–Documentar (construção de artefatos críticos para controlar, medir e comunicar determinado sistema durante seu desenvolvimento e após sua implantação) os artefatos de um sistema complexo (ou não) de software.

43. UML: O que é?
•A UML é uma linguagem, e como tal, fornece um vocabulário e as regras para a combinação de palavras desse vocabulário com a finalidade de comunicar algo (criação de modelos bem formados).
•UML não é um processo, portanto não indica quais modelos deverão ser criados, nem quando deverão ser criados.

44. UML: O que é?
•Um modelo conceitual da UML
–Blocos básicos de construção da UML. Existem três tipos de blocos de construção:
•1. Itens
•2. Relacionamentos
•3. Diagramas
–Itens da UML. Quatro tipos:
•1. Itens estruturais
•2. Itens comportamentais
•3. Itens de agrupamentos
•4. Itens anotacionais
–Itens Estruturais
•Os itens estruturais são os substantivos utilizados em modelos da UML. São as partes estáticas do modelo, representando elementos conceituais ou físicos.

45. UML: O que é?
•Itens Estruturais - sete tipos de itens estruturais:
–As classes são descrições como conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.
–Uma Interface é uma coleção de operações que especificam serviços de uma classe ou componente. Descreve o comportamento externamente visível desse elemento. Pode representar todo, ou parte, o comportamento de uma classe ou componente. Define um conjunto de especificações de operações (suas assinaturas), mas nunca um conjunto de implementações de operações. Uma interface costuma aparecer anexada à classe ou ao componente que realiza a interface.

46. UML: O que é?
–As colaborações definem interações e são sociedades de papéis e outros elementos que funcionam em conjunto para proporcionar um comportamento cooperativo superior à soma de todos os elementos. Possuem dimensões estruturais, assim como comportamentais. Uma classe pode participar em várias colaborações.
–Um caso de uso é a descrição de um conjunto de seqüência de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator. É utilizado para estruturar o comportamento de itens em um modelo. Um caso de uso é realizado por uma colaboração.

47. UML: O que é?
•Os três tipos de itens restantes - classes ativas, componentes e nós - são semelhantes a classes, porém, estes são suficientemente diferentes e necessários para a modelagem de certos aspectos de sistemas orientados a objetos e, portanto, merecem um tratamento especial.
•Os cinco primeiros tipos de itens são itens conceituais ou lógicos. Os dois últimos (componentes e nós) representam itens físicos.

48. UML: O que é?
–As classes ativas são classes cujos objetos têm um ou mais processos ou threads e, portanto, podem iniciar a atividade de controle. Uma classe ativa é semelhante a uma classe, exceto pelo fato de que seus objetos representam elementos cujo comportamento é concorrente com o de outros elementos.
–Os componentes são partes físicas e substituíveis de um sistema, que proporcionam a realização de um conjunto de interfaces. Em um sistema, encontram-se deferentes tipos de componentes próprios da implantação, como os componentes COM+ ou Java Beans, assim como componentes que são artefatos do processo de desenvolvimento, como arquivos de código-fonte. Tipicamente os componentes representam o pacote físico de elementos lógicos diferentes, como classes, interfaces e colaborações.

49. UML: O que é?
–Um nó é um elemento físico existente em tempo de execução que representa um recurso computacional, geralmente com pelo menos alguma memória e, freqüentemente, capacidade de processamento. Um conjunto de componentes poderá estar contido em um nó e também poderá migrar de um nó para outro.
–Além desses sete tipos de itens estruturais, existem, também, variações desses, como: atores, sinais e utilitários (tipos de classes), processos e threads (tipos de classes ativas), e aplicações, documentos, arquivos, bibliotecas, páginas e tabelas (tipos de componentes).

50. UML: O que é?
–Itens comportamentais
•São as partes dinâmicas dos modelos UML. São os verbos de um modelo, representando comportamentos no tempo e no espaço. Existem dois tipos de itens comportamentais:
•Uma interação é um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos em determinado contexto para a realização de propósitos específicos. O comportamento de uma sociedade de objetos ou de uma operação individual poderá ser especificado por meio de uma interação. As interações envolvem outros elementos, inclusive mensagens, seqüências de ações (os comportamentos chamados pelas mensagens) e ligações (as conexões entre os objetos).
•Uma máquina de estado é um comportamento que especifica as seqüências de estados pelas quais objetos ou interações passam durante sua existência em resposta a eventos, bem como suas respostas a esses eventos. Uma máquina de estado abrange outros elementos, incluindo estados, transições (o fluxo de um estado a outro), eventos (itens que disparam uma transição) e atividades (as respostas às transições)

51. UML: O que é?
–Itens de agrupamentos
•São as partes organizacionais dos modelos UML. São os blocos em que os modelos podem ser decompostos. Existe apenas um tipo de itens de agrupamento, chamado Pacote.
–Um pacote é um mecanismo de propósito geral para a organização de elementos em grupos. Os itens estruturais, os itens comportamentais e até outros itens de grupos podem ser colocados em pacotes. Ao contrário dos componentes (que existem em tempo de execução), um pacote é puramente conceitual (existem apenas em tempo de desenvolvimento). Existem algumas variações, como frameworks, modelos e subsistemas (tipos de pacotes).
–Itens anotacionais
•São as partes explicativas dos modelos UML. São comentários, incluídos para descrever, esclarecer e fazer alguma observação sobre qualquer elemento do modelo. Existe somente um tipo de item anotacional, chamado nota. Uma nota é apenas um símbolo para representar restrições e comentários anexados a um elemento ou a uma coleção de elementos.

52. UML: O que é?
•Relacionamentos na UML.
–1. Dependência - é um relacionamento semântico entre dois itens, nos quais a alteração de um (o item independente) pode afetar a semântica do outro (o item dependente).
–2. Associação - é um relacionamento estrutural que descreve um conjunto de ligações, em que as ligações são conexões entre objetos. A agregação é um tipo especial de associação, representando um relacionamento estrutural entre o todo e suas partes. A composição é um tipo especial de agregação.

53. UML: O que é?
•Relacionamentos na UML.
–3. Generalização - é um relacionamento de especialização/generalização, nos quais os objetos dos elementos especializados (os filhos) são substituíveis por objetos de elemento generalizado (os pais). Dessa maneira, os filhos compartilham a estrutura e o comportamento dos pais.
–4. Realização - é um relacionamento semântico entre classificadores, em que um classificador especifica um contrato que outro classificador garante executar. Os relacionamentos de realizações serão encontrados em dois locais: entre interfaces e as classes ou componentes que as realizam; e entre casos de uso e as colaborações que os realizam.

54. UML: O que é?
•Mecanismos
–Mecanismos básicos da UML. São os mecanismos básicos que se aplicam a toda a linguagem, que são:
–1. Especificações - Cada parte da notação gráfica possui uma especificação capaz de fornecer uma declaração textual da sintaxe e da semântica do respectivo bloco de construção.
•Exemplo: Ícone de classe - existe uma especificação que fornece o conjunto completo de atributos, operações e comportamentos de classe. O ícone poderia exibir somente uma parte de interesse em determinado diagrama.
•O ícone de classe permite a visualização da mesma no sistema.
•A especificação determina os detalhes da classe.

55. UML: O que é?
•Mecanismos
–2. Adornos - Em sua maioria, os elementos da UML possuem uma notação gráfica única e direta (representação visual). Por exemplo; a notação gráfica para classes expõe os aspectos mais importantes da classe (nome, atributos e operações).
•Através de adornos pode-se definir detalhes como:
–Se uma classe é Abstrata (nome da classe em itálico)
–Visibilidade de atributos e operações
•Todos os elementos da notação da UML possuem símbolos básicos que podem ser adornados.

56. UML: O que é?
•Mecanismos
–3. Divisões comuns - O mundo costuma ser dividido pelo menos de duas maneiras.
•Primeiro, a Divisão Classe/Objeto: classe é a abstração; objeto é a manifestação concreta dessa abstração.
•Quase todos os blocos de construção disponíveis na UML apresentam este mesmo tipo de dicotomia classe/objeto (abstração do elemento e instância desta abstração)
•Ex.:
–Casos de Uso e Instâncias de Casos de Uso
–Componentes e Instâncias de Componentes
–Nós e Instâncias de Nós

57. UML: O que é?
•Mecanismos
–3. Divisões Comuns
•Segundo, separação de interface e implementação.
•Interface declara um contrato. Implementação representa uma realização completa desse contrato, responsável pela manutenção fiel da semântica completa da interface.
•Quase todos blocos de construção da UML apresentam esse mesmo tipo de dicotomia interface/implementação
•Ex.:
–Casos de Uso e as Colaborações que as realizam.
–Operações e Métodos que as implementam.

58. UML: O que é?
•Mecanismos
–4. Mecanismos de extensão - A UML permite a sua própria ampliação (de maneira controlada), para isto são utilizados os mecanismos de extensibilidade da UML, os quais incluem:
•Estereótipos - amplia o vocabulário da UML, permitindo a criação de novos tipos de blocos de construção que são derivados dos já existentes, mas específicos a determinados problemas.
•Por exemplo: Modelar as exceções de linguagens como Java e C++ como uma classe marcada com um estereótipo (<<exception>>).

59. UML: O que é?
•Valores atribuídos e Restrições
–Valores atribuídos - estende as propriedades dos blocos de construção permitindo a criação de novas informações na especificação de um elemento. Por exemplo: Produtos com muitas versões ao longo do tempo. Marcar, com valores atribuídos, a versão e o autor deste produto.
–Restrições - amplia a semântica dos blocos de construção permitindo acrescentar novas regras ou modificar as já existentes. Por exemplo: restringir um método de uma classe de modo que todos acréscimos (através de uma operação add(), por exemplo) sejam feitos ordenadamente.
–O importante na utilização dos mecanismos de extensão é que seja controlada, para que um dos propósitos da UML não seja perdido - a comunicação de informações.

60. UML: O que é?

61. Diagramas e Processo de SW
•Diagramas na UML
–Um diagrama é a apresentação gráfica de um conjunto de elementos. Geralmente representada como gráficos de vértices (itens) e arcos (relacionamentos). Os diagramas são desenhados para permitir a visualização de um sistema sob diferentes perspectivas.
–Um diagrama, ao menos talvez para sistemas triviais, representa uma visão parcial dos elementos que compõem o sistema. Um mesmo elemento pode aparecer em todos os diagramas, em apenas alguns ou em nenhum diagrama. Na teoria, um diagrama pode conter qualquer combinação de itens e de relacionamentos. Na prática, porém, aparecerá um pequeno número de combinações comuns, que são consistentes com as cinco visões mais úteis da arquitetura de um sistema complexo de software.
•Visão do Caso de Uso, de Projeto, de Processo, de Implementação e de Implantação
–A UML inclui vários diagramas

62. Diagramas e Processo de SW
–1. Diagrama de classes - exibe um conjunto de classes, interfaces e colaborações, bem como seus relacionamentos.
–2. Diagrama de objetos - exibe um conjunto de objetos e seus relacionamentos.
–3. Diagrama de casos de uso - exibe um conjunto de casos de uso e atores (um tipo especial de classe) e seus relacionamentos.
–4. Diagrama de seqüências - é um diagrama de interação cuja ênfase está na ordenação temporal das mensagens.
–5. Diagrama de colaborações - é um diagrama de interação cuja ênfase está na organização estrutural dos objetos que enviam e recebem mensagens.

63. Diagramas e Processo de SW
–6. Diagrama de gráficos de estados - exibem uma máquina de estados, formada por estados, transições, eventos e atividades.
–7. Diagrama de atividades - é um tipo especial de diagrama de gráfico de estados, exibindo o fluxo de uma atividade para outra no sistema.
–8. Diagrama de componentes - exibe as organizações e as dependências existentes em um conjunto de componentes.
–9. Diagrama de implantação - mostra a configuração dos nós de processamento em tempo de execução e os componentes neles existentes.

64. Diagramas e Processo de SW
•Diagramas
–Atividades
–Casos de Uso
–Classes
–Objetos
–Seqüência
–Colaboração
–Estado
–Componentes
–Implantação
•Processo de Software
–Fluxo de negócios / métodos classe
–Contexto/Requisitos de sistema
–Estrutura/Relacionamentos (asp. estáticos)
–Estrutura/Relacion. (asp. estáticos de instâncias)
–Casos de Uso, Sistema (aspectos dinâmicos)
–Casos de Uso, Sistema (aspectos dinâmicos)
–Sistema, subsistema, classe (tempo de vida)
–Implementação física (aspectos estáticos)
–Nós físicos (aspectos estáticos)

65. Diagramas:teoria e exemplos
•Diagrama de Casos de Uso
–Especifica o comportamento de um sistema ou de parte de um sistema
–E uma descrição de um conjunto de seqüências de ações, incluindo variantes realizadas pelo sistema realizadas pelo sistema para produzir um resultado observável do valor de um ator
–Descrição textual do caso de uso

66. Diagramas:teoria e exemplos

67. Diagramas:teoria e exemplos
•Diagrama de Casos de Uso
–Descrição Textual
Caso de Uso – Validar Usuário (ValidateUser)
Fluxo de eventos principal: o caso de uso começa quando o sistema solicitar ao "Cliente" (Customer) um número PIN, seu número de identificação pessoal. O "Cliente" agora pode digitar o número PIN via teclado numérico. O "Cliente" confirma a entrada, pressionando a tecla 'Enter'. O sistema então verifica o número PIN para saber ser é válido. Se o número PIN for válido, o sistema reconhece a entrada, finalizando o caso de uso.
Fluxo excepcional de eventos: o "Cliente" pode cancelar uma transação a qualquer momento, pressionando o botão Cancelar, reiniciando assim o caso de uso. Nenhuma alteração é realizada na conta do "Cliente".
Fluxo excepcional de eventos: o "Cliente" pode limpar o número PIN a qualquer momento antes de submetê-lo e redigitar um novo número PIN.
Fluxo excepcional de eventos: se o "Cliente" entrar um número PIN inválido, o caso de uso é reiniciado. Se isso ocorrer três vezes seguidas, o sistema cancela toda a transação, impedindo ao "Cliente" interagir com o caixa eletrônico por 60 segundos

68. Diagramas:teoria e exemplos
•Diagrama de Casos de Uso
–Descrição Textual
Caso de Uso: Track Order
Fluxo principal de eventos: Obter e verificar o número do pedido. include (Validate User). Para cada parte do pedido, consulte seu status e depois retorne um relatório para o usuário.
Caso de Uso: Place Order
Fluxo principal de eventos: include(Validate User). Receba os itens do pedido do usuário. (set priority). Submeta o pedido para o processamento.

69. Diagramas:teoria e exemplos

70. Diagramas: teoria e exemplos
•Contexto

71. Diagramas:teoria e exemplos
•Requisitos

72. Diagramas:teoria e exemplos
•Diagrama de Classes
–Servem para fazer a modelagem estática do sistema, dando suporte, principalmente, aos requisitos funcionais de um sistema (serviços que o sistema deverá fornecer aos usuários finais).
–Os Diagrama de Classes são usados, tipicamente, de três formas:
•Para fazer a modelagem do vocabulário de um sistema (abstrações do domínio do problema)
•Para fazer a modelagem de colaborações simples: uma colaboração é uma sociedade de classes, interfaces e outros elementos que funcionam em conjunto para proporcionar algum comportamento cooperativo, maior do que a soma de todos os elementos.
•Para fazer a modelagem do esquema lógico de um banco de dados

73. Diagramas:teoria e exemplos

74. Diagramas:teoria e exemplos

75. Diagramas:teoria e exemplos
•Associações

76. Fim da Apresentação