jorge@dimap.ufrn - CIC/UnBjhcf/MyBooks/iess/RUP/IntroducaoaEngenhariade... · tarefa contínua e...

Introdução À Engenharia De Software Com Foco No RUP -

Rational Unified Process

Prof. Dr. Jorge Henrique C Fernandes (jorge@dimap.ufrn.br)

POTI – Pólo De Tecnologia Da InformaçãoDepartamento De Informática E Mat. AplicadaUniversidade Federal Do Rio Grande Do Norte

Fernandes• A estrutura deste curso é baseada, mas não

substitui, o uso nos seguintes materiais– Livro:

• [Kruchten, 2000] Introduction to the Rational Unified Process, de Philippe Kruchten, Addison-Wesley, 2000

– Software: • [Rational, 2000] Rational Unified Process – RUP. Rational

Software Corporation. 2000

• Rational e Rational Unified Process são marcas comerciais da Rational Software Corporation

Outras Referências• [Kruchten, 2000] Introduction to the Rational Unified Process, de

Philippe Kruchten, Addison-Wesley, 2000.• [Clements et alli, 1998] Software Architecture in Practice. Len Bass,

Paul Clements and Rick Kazman. Addison-Wesley, 1998.• [J2EE, 2002] Designing Enterprise Applications with the J2EETM

Platform, Second Edition. Inderjeet Singh, Beth Stearns, MarkJohnson, and the Enterprise Team. Addison-Wesley. 2002.

• [Sun, 2002] Designing Wireless Enterprise Applications Using Java™Technology; A Java BluePrints for Wireless White Paper. Sun Microsystems, Inc. 2002.

• [SPEM, 2002] Software Process Engineering Metamodel Specification.November 2002. Version 1.0. formal/02-11-14

• [Kobryn, 2001] Introduction to UML: Structural and Use CaseModeling. Cris Kobryn. OMG UML Tutorial Series.2001

Características do Treinamento• Introdutório• Carga de 30 (trinta) horas-aula• Pré-requisitos

– Conhecimentos básicos de desenvolvimento de software

• Conhecimentos desejáveis– Orientação a objetos– UML – Unified Modeling Language– Gerencia de projetos de software

• Audiência– Gerentes de projetos, desenvolvedores de software, engenheiros

de qualidade, de processos e sistemas, analistas de negócios e estudantes de cursos profissionalizantes de informática, computação, sistemas de informação e engenharia de software

Objetivos do treinamento

• Apresentar e discutir abordagens efetivas para desenvolvimento de software

• Entender o que é o RUP, seus vocabulário e conceitos

• Entender como as disciplinas do RUP colaboram para a estruturação efetiva e eficaz de tarefas e fluxos de trabalho de profissionais, atuando em equipes de desenvolvimento de software

Conteúdo: RUP – Módulo IntrodutórioParte I

A1. Abordagens Efetivas Para Desenvolvimento De Software

A2. O Que é o Rational Unified Process - RUP?

A3. Conceitos e OrganizaçãoA4. Estágios, Fases,

Iterações, Disciplinas e Ciclo de Vida

A5. Foco em ArquiteturaA6. Foco em Casos de Uso

Parte IIA7. Gestão de projetosA8. Modelagem de NegóciosA9. RequisitosA10. Análise e ProjetoA11. ImplementaçãoA12. TestesA13. Gestão de

Configuração e Mudanças

A14. Gestão de AmbienteA15. Instalação

Introdução À Engenharia De Software Com Foco No RUP: Rational

Unified Process

Parte IConceitos para Entendimento do RUP

Parte I - Aula 1Abordagens Efetivas Para

Desenvolvimento De Software

Abordagens Efetivas Para Desenvolvimento De Software

• Objetivos desta aula– Compreender o valor do software na

sociedade em que vivemos– Compreender e discutir os sintomas e causas

de problemas no desenvolvimento de software– Compreender e discutir abordagens efetivas

para desenvolvimento de software

Valor Do Software Na Sociedade

• Atividades econômicas e o software• Expansão do software e sistemas

computacionais em complexidade e tamanho

• O Estado da prática em Desenvolvimento de Software

Atividades Econômicas E O Software

• Empresas e o software• Indivíduos e o software• Sociedade e o software

Expansão Do Software E Sistemas Computacionais Em Complexidade E Tamanho

• O custo do software para a sociedade– Governo

• Educação• Saúde• Infra-estrutura

– Indivíduos• Casa, trabalho

– Indústrias– Comércio– Serviços– Bancos– Telecom

O Estado Da Prática Em Desenvolvimento De Software

• Sem software é difícil aumentar a produtividade e qualidade da economia

• Software está se tornando cada vez mais complexo e difícil de produzir e manter

• Reproducibilidade de resultados e previsibilidade da qualidade• metas difíceis de implantar numa organização

produtora e mantenedora de software

Sintomas E Causas De Problemas No Desenvolvimento De Software [Booch, 1999]1.Sintomas

1.O que dá errado em projetos de software?2.Causas

1.Porque dão errado?

Sintomas De Falhas Em Projetos De Software

• Compreensão inadequada das necessidades dos usuários

• Inabilidade para tratar mudanças de requisitos • Módulos incompatíveis entre si• Software difícil de manter (corrigir, adaptar e evoluir)• Descoberta de falhas em fases adiantadas do projeto• Baixa qualidade da solução entregue ao usuário• Desempenho inaceitável• Não dá para saber quem fez o quê, como e porque• Falhas no empacotamento e entrega do produto

Causas Fundamentais De Falhas De Projetos De Software (1 De 2)

• Gestão de requisitos é feita ‘nas coxas’• Informações trocadas entre os envolvidos

(stakeholders) são ambíguas e imprecisas• Arquiteturas concebidas são frágeis• Complexidade do software é absurda e

desnecessária• Não se investigam as inconsistências

existentes entre requisitos, design e implementação

Causas Fundamentais De Falhas De Projetos De Software (2 De 2)

• Teste insuficiente dos módulos, subsistemas e do sistema

• Avaliação de status do projeto feita de forma subjetiva

• Falha no ataque aos riscos• “Se você não atacar os riscos, eles atacarão

você!” (Tom Gilb)• Controle inadequado da propagação das

mudanças• Nível insuficiente de automação

Abordagens Efetivas Para Desenvolvimento De Software [Booch, 1999]

#1: desenvolver software iterativamente#2: gerenciar requisitos#3: usar arquiteturas baseadas em

componentes#4: modelar visualmente o software#5: verificação contínua da qualidade#6: controle de mudanças

Abordagem Efetiva #1: Desenvolver Software Iterativamente

Modelo Cascata Versus

Modelo Espiral

Modelo Cascata (Waterfall)

• Intenção: Uma seqüência unidirecional de atividades transforma requisitos em um sistema

• Realidade– Reduz flexibilidade: é difícil saber onde se vai chegar

quando os caminhos são vários– Desestimula inovação: software em execução constrói

uma máquina (sistema), em muitos casos uma novidade

• Evita-se experimentar novos conceitos porque o sistema pode não se adequar às necessidades reais de seus usuários

requisitosdesign

implementaçãotestes

implantação

Modelo Espiral (Spiral)

• Modelo Espiral [Boehm, 2000]• “De modo cíclico e incremental, aprimorar

o grau de definição e implementação de um sistema, enquanto diminui o grau de risco do projeto”

• Milestones (marcos de ancoragem) asseguram compromisso de todos os envolvidos com a satisfação dos objetivos do projeto

Modelo Espiral Original [Boehm, 1989]

Um Ciclo na Espiral do RUP [Rational, 2000]

RUP: Espiral de Iterações

Invariantes De Processos Baseados No Modelo Espiral (1 De 2)

• Produção dos artefatos é concorrente, e não seqüencial

• Elementos fundamentais considerados em um ciclo espiral– Objetivos e restrições dos envolvidos – Alternativas para produtos e processos– Identificação e resolução de riscos– Revisão por parte dos envolvidos (stakeholders)– Compromisso no prosseguimento para próxima etapa

• Riscos determinam:– Nível de esforço para próxima etapa– Nível de detalhe dos artefatos a produzir

• Três grandes milestones– Objetivos (LCO), arquitetura (LCA) e capacidade

operacional inicial (IOC)

• Ênfase do sistema e no ciclo de vida, em vez de código

Resultados De Uma Abordagem Iterativa Incremental

• Erros, riscos e inconsistências se tornam evidentes mais cedo

• Encoraja feedback do usuário • Mantém foco do time nas questões cruciais do

projeto• Avaliação periódica e precisa do status do projeto• Carga de trabalho entre equipes é distribuída ao

longo do tempo• Feedback e reflexão ocorrem mais cedo• Envolvidos obtém evidência concreta periódica

sobre status do projeto

Abordagem Efetiva #2: Gerenciar Requisitos

• Requisitos – Capacidades, propriedades e restrições que devem

estar presentes em um sistema• O problema dos requisitos:

– Mudança constante:• Sistemas são máquinas, máquinas se comunicam através de

linguagens, e quanto mais complexas maior sua necessidade de evolução

• Determinar requisitos reais do sistema é uma tarefa contínua e constante– Elicitação, especificação, rastreamento, negociação e

evolução

Abordagem Efetiva #3: Usar Arquiteturas Baseadas Em

Componentes

O Que É Arquitetura De Um Software Ou Sistema?

• Arquitetura é a estrutura, ou as estruturas, do software ou sistema, composta por:– Seus componentes– As propriedades externamente visíveis destes

componentes– Os relacionamentos entre estes

• Todo sistema de software possui uma arquitetura– Que pode não ser conhecida pelos usuários do

sistema, pelos responsáveis pela sua operação– O comportamento externo de cada componente é

parte integrante da arquitetura

Componentes e Abstrações

• Componentes de software– São unidades de software fisicamente identificáveis– Possuem uma interface bem definida, – Encapsulam detalhes privados de implementação

• Quais abstrações são componentes?– Objetos? Processos? Processadores? Bibliotecas? Bases

de dados? Produtos comerciais?• São omitidas de uma descrição arquitetural as

informações sobre componentes que não são pertinentes às interações entre eles

• Detalhes privados dos componentes nãopertencem à arquitetura

Propriedades Externamente Visíveis Dos Componentes

Dependem da abstração que se está observando, como:

• Métodos que provê (objetos, classes);• Características de desempenho

(processador, rede);• Tratamento de erros (módulos);• Uso de recursos compartilhados (funções);• Etc.

Visão 4+1 [Kruchten, 1996]

Abordagem Efetiva #4: Modelar Visualmente O Software

Modelagem Visual De Software

• Modelos são abstrações da realidade– Estruturam solução de problemas– Permite experimentar com várias soluções– Reduzem complexidade e incrementam compreensão– Reduzem custo e tempo para desenvolvimento de

conceitos e produtos– Reduz riscos

• UML – Linguagem visual para• Visualizar, Especificar, Construir e documentar

estrutura e comportamento de um sistema de software• Modelos estruturais e comportamentais

Alguns Modelos Estruturais [Kobryn, 2000]

Diagrama de Classes

Diagrama de Objetos

“Uma Moléculade Etano (C2H6)”

“Classes de átomos e Suas ligações”

Diagrama De Componentes Ilustrando Evolução De UML [Kobryn, 2000]

Modelo Estrutural De Um Site [Conallen, 2000]

Diagramas De Interação: Seqüência E Colaboração [Övergaard, 2000]

Diagrama De Seqüência(Elementos) [Övergaard, 2000]

Diagrama De Estados Ligando Uma Lâmpada [Övergaard, 2000]

Diagrama de Atividades (construindo uma casa) [Övergaard, 2000]

Abordagem Efetiva #5: Verificação Contínua Da Qualidade

• Evolução do custo de correção no software

• É importante avaliar continuamente, e de forma objetiva, a satisfação dos requisitos:– externos (funcionalidades) – Internos (qualidade interna)

Custos

Verificação Da Qualidade

• Avaliação objetiva de status do projeto• Busca de inconsistências entre requisitos,

design e implementação• Testes unitários, de integração e de

sistema– Eliminação de defeitos, se possível ainda na

`bancada’

• Testes automatizados

Abordagem Efetiva #6: Controle De Mudanças

• Realidade numa organização de engenharia de software– Vários times– Vários artefatos– Várias estações de trabalho (workspaces)– Vários produtos– Várias plataformas de execução– Várias iterações e ‘releases’– Vários meses e anos– Vários sistemas legados

Controlar Mudanças: Fundamental Para Garantir reproducibilidade E Previsibilidade

• Atividades bem definidas• Controle na

– Solicitação, encaminhamento e rastreamento de mudanças

– Propagação de mudanças

• Isolamento de workspaces• Medidas e métricas de alteração

Parte I - Aula 2O Que É O Rational Unified Process

- RUP?

O Que É O RUP?

• RUP: processo de engenharia de software• A Base de Conhecimento do RUP (site) É

um produto comercializado pela IBM/Rational

• A IBM/Rational comercializa ferramentas que podem ser empregadas para agilizar o uso produtivo do RUP

O Que É O RUP?

• RUP: processo de engenharia de software• RUP: produto comercializado pela IBM/Rational• RUP: integra-se com ferramentas da

IBM/Rational

RUP: Um Processo De Engenharia De Software

• RUP: framework metodológico para organização do processo (de produção) de software

• Aplica princípios do processo unificado[Booch]– Baseado do modelo de processo espiral

• Processo adaptável, permitindo ajustes para domínios e aspectos específicos como:– Software de tempo real– Teste de software– Maturidade de processos– Manutenção de software legado

RUP: Produto Comercializado Pela IBM/Rational

• Base de conhecimento do RUP: Site web, contendo:– Páginas HTML– Mapas– Applets

• Browser• Engenho de busca

– Figuras– Hiperlinks– Mentores sobre ferramentas– Templates e exemplos

RUP: Site Web [Rational, 2000]

RUP: Produto Comercializado Pela IBM/Rational

• Possibilita ajustes (customizações) em vários escopos– indivíduo– projeto– organização

• Como uma mídia digital, pode receber manutenção regular

• Como um produto de software, pode integrar workflow com outros produtos e ferramentas

Para Que Serve O RUP?• RUP: captura e descreve abordagens reconhecidamente

efetivas pela comunidade de engenharia de software:– Meta Fundamental da Engenharia de Software:

• Desenvolver e adotar métodos, técnicas, ferramentas e processos para produzir software com prazo, custo e qualidade previsíveis

• RUP: estimula adoção de uma abordagem disciplinada (fluxos ou disciplinas) na atribuição e gerenciamento de papéis e tarefas em uma organização que desenvolve software– Existem outras, como a Praxis, de Wilson de Pádua Filho

• RUP: bastante reconhecido e utilizando por organizações que desenvolvem software no mundo inteiro– O vocabulário do RUP tornou-se vocabulário comum

Para Que Serve O RUP?• RUP: captura e descreve abordagens reconhecidamente

efetivas pela comunidade de engenharia de software:– Meta Fundamental da Engenharia de Software:

• Desenvolver e adotar métodos, técnicas, ferramentas e processos para produzir software com prazo, custo e qualidade previsíveis

• RUP: estimula adoção de uma abordagem disciplinada (fluxos ou disciplinas) na atribuição e gerenciamento de papéis e tarefas em uma organização que desenvolve software– Existem outras, como a Praxis, de Wilson de Pádua Filho

• RUP: bastante reconhecido e utilizando por organizações que desenvolvem software no mundo inteiro– O vocabulário do RUP tornou-se vocabulário comum

Princípios do RUP

• Além dos seis + importantes:– #1: desenvolver software iterativamente– #2: gerenciar requisitos– #3: usar arquiteturas baseadas em componentes– #4: modelar visualmente o software– #5: verificação contínua da qualidade– #6: controle de mudanças

• Pode-se ainda destacar– Desenvolvimento baseado em casos de uso– Processo configurável– Suporte a ferramentas (tool mentors)

Parte I - Aula 3RUP: Conceitos e Organização

RUP: Conceitos [Rational, 2000]

RUP: Conceitos e Organização

• Role (Papel)• Artifact (Artefato) ou WorkProduct• Activity (Atividade)• WorkflowDetail (Detalhe de Fluxo)• Workflow (Fluxo)• Discipline (Disciplina)• Phases (Fases) e Iterations (Iterações)

RUP: (Role) Papel, Artifact (Artefato) e Activity(Atividade) [Rational, 2000]

RUP: Papel ou Role ou ProcessRole

• Anteriormente chamado de “Worker”• No SPEM[OMG, 2002] chamado de ProcessRole• Conjunto de atividades coerentemente

desempenhadas por uma pessoa (recurso), atuando em um time de pessoas com múltiplas competências

• Um recurso (pessoa) pode desempenhar muitos papéis, conforme suas habilidades individuais

• Papéis são agregados em 5 conjuntos chamados de RoleSets: Analistas, Desenvolvedores, Testadores, Gerentes e Outros

RUP: Alguns Exemplos de Papéis• Analistas

– System Analyst – Business Designer– Business-Model Reviewer – Business-Process Analyst

• Desenvolvedores– Capsule Designer– Code Reviewer – Database Designer– Implementer – Integrator – Software Architect– Architecture Reviewer – Design Reviewer

• Gerentes– Process Engineer – Project Manager – Change Control

Manager – Configuration Manager – Deployment Manager – Project Reviewer – Test Manager

• Outros

RUP: Artefato ou Artifact ou WorkProduct

• Resulta de uma atividade executada por um recurso, desempenhando um papel

• É qualquer coisa produzida, consumida ou modificada por um processo

• Pode ser uma peça de informação, um documento, um modelo UML, um código fonte, etc.

RUP: Principais Artefatos [Rational, 2000]

RUP: Atividade Ou Activity

• Unidade de trabalho a ser realizada por um recurso desempenhando um papel, produzindo resultados tangíveis para um projeto, normalmente representados por artefatos

AtividadePapel

Resultados

• Atividades utilizam um ou mais artefatospreviamente existentes

• Atividades em geral criam, atualizam ou refinam um ou mais artefatos

Artefato #O1

Artefato #O2

Artefato #On

Artefato #I1

Artefato #I2

Artefato #In

Atividade

Artefato #IO1

Artefato #IO2

Artefato #IOn

input output

Input/output

• Uma atividade é um elemento atômico de planejamento de projeto

Inicio -> Fim Inicio -> Fim Inicio -> Fim

• Uma atividade é realizada em poucos minutos, horas ou dias

• Atividades são compostas por uma seqüência de passos a executar

• Passos para realização de uma atividade são organizados em três categorias: planejamento, execução e revisão

RUP: Exemplos de Atividades• Papel: Analista de

Sistemas– Elicitar necessidades de

stakeholders– Capturar vocabulário– Desenvolver Plano de

Gestão de Requisitos– Desenvolver guias de

construção de casos de uso– Encontrar atores e casos de

uso– Desenvolver Visão– Gerenciar (rastrear)

dependências– Estruturar modelo de casos

de uso

• Papel : Implementador– Implementar

componentes– Implementar teste de

componentes e subsistemas

– Executar testes unitários

– Corrigir defeitos– Desenvolver artefatos

de instalação

RUP: Detalhe De Workflow (Workflow Detail)

• Conjunto de atividades, artefatos e papéis realizadas de forma interdependente por um indivíduo ou pequeno grupo

• Sem prescrição de controle interno do fluxo de atividades

• Cria um foco local (individual) de execução de atividades que produz resultados tangíveis e mensuráveis

• Orienta na gestão individual das atividades

RUP: Workflow Detail: Analisar o Problema [Rational, 2002]

Atividades

Artefatos

Workflow (Fluxo ou Core Workflow)

• Fluxo macroscópico de controle de execução das atividades de uma disciplina

• Controle descrito na forma de diagrama de atividades, que agrega vários Detalhes de Workflow

• Orienta na gestão grupal das atividades

RUP: Workflow (Fluxo) Típico daDisciplina de Requisitos [Rational, 2002]

Detalhes de

workflow

RUP: Disciplina ou Domínio

• Particiona atividades, artefatos e papéis em um tema ou subárea comum

• Disciplinas de Engenharia– Business Modeling – Requirements – Analysis & Design– Implementation – Test – Deployment

• Disciplinas de Suporte– Environment – Project Management – Configuration & Change Management

RUP: Outros Elementos do Processo

• Guia de Trabalho– Orienta sobre como desempenhar uma

atividade

• Guia de Artefato– Descreve como construir um artefato

• Guia de Ferramenta (Tool Mentor)– Descreve como usar uma ferramenta para

construir um artefato

RUP: Outros Elementos do Processo

• Checkpoints– Auxiliar na verificação da qualidade de um

artefato

• Template– Protótipos ou modelos de artefatos

• Report– Informação extraída automaticamente de

alguns artefatos

Tool Mentors (Mentores) [Rational, 2000]

• Guias especializados em uso de ferramentas

Parte I - Aula 4RUP: Estágios, Fases, Iterações,

Disciplinas e Ciclo de Vida

RUP: Estágios, Fases E Iterações

• 2 Estágios: engenharia e produção• 4 Fases: Iniciação, elaboração, construção

e transição• Várias iterações em cada fase

– Viabilidade– Arquitetura– Uso– “Release”

RUP: Estágios do Ciclo de Vida

• Engenharia– Demonstrar a viabilidade econômica-técnica do

produto (software)– Inovação e Propriedade intelectual– Criar uma arquitetura que facilite a produção

• Produção– Realizar o produto– Processo de manufatura, onde se busca a melhor

qualidade, no menor tempo e com o consumo de recursos

– Propriedade Industrial

RUP: Metas de Cada Fase• Iniciação

– Obter uma visão do produto acabado, e concordância acerca dos objetivos e resultados finais do projeto

– Marco de conclusão: definição dos objetivos do ciclo de vida (lifecycle objective milestone)

• Elaboração– Obter uma arquitetura viável,

através da especificação de todas as características do produto, com Iniciação e validação de uma arquitetura que às atenda

– Marco de conclusão : arquitetura do ciclo de vida (lifecycle architecture milestone)

• Construção– Construir o produto, evoluindo

sua visão, arquitetura, até que esteja pronto para release

– Marco de conclusão: capacidade operacional inicial (initial operational capability)

• Transição– Concluir a entrega do produto

para clientes e usuários até plena satisfação dos objetivos e resultados estabelecidos, incluindo atividades de (entrega, treinamento, suporte e manutenção)

– Marco de conclusão: release do produto (product release milestone)

Detalhes da Fase de Iniciação [Kruchten, 2000] (1 de 5)

• Meta– Obter uma visão do produto acabado, e

concordância acerca dos objetivos e resultados finais do projeto

• Objetivos– Estabelecer o escopo do projeto de software– Estabelecer condições de contorno, incluindo

documento de conceitos de operações, critérios de aceitação, descrição do escopo positivo e negativo

– Descrever casos de uso críticos, que irão direcionar as linhas mestras do sistema

– Exibir ou demonstrar uma arquitetura candidata, validada com alguns cenários confrontados

– Estimativa de custo global e cronograma do projeto– Prover estimativas detalhadas da fase de elaboração– Estimar riscos

• Atividades– Formular escopo do projeto, de modo a

permitir especificação de critérios objetivos de sucesso

– de projeto, riscos, recursos necessários e data de realização das principais etapas

– Delimitar o escopo do projeto– Identificar os atores que interagem com o

sistema– Identificar as interações dos atores com o

sistema (casos de uso)

• Artefatos produzidos– Documento de visão: visão geral dos requisitos,

características e restrições essenciais do projeto– Modelo inicial de casos de uso (10%-20%)– Glossário do projeto (opcionalmente um modelo de

domínio)– Definição de objetivos e viabilidade do projeto incluído

contexto, critérios de sucesso, projeção de ROI (retorno sobre investimentos) e prognóstico financeiro

– Avaliação inicial de riscos– Plano de projeto, com fases e interações– Modelo de negócios, se necessário– Um ou vários protótipos

• Marco de conclusão– definição dos objetivos do ciclo de vida

(lifecycle objective milestone)– Critérios de Satisfação

• Concordância quanto à definição de escopo e estimativas de custo e cronograma

• Compreensão dos requisitos funcionais• Credibilidade das estimativas de custo, cronograma,

prioridades, riscos, e processo de desenvolvimento• Profundidade e amplitude dos protótipos

desenvolvidos• Custos planejados versus realizados

Detalhes da Fase de Elaboração [Kruchten, 2000] (1 de 5)

• Meta– Obter uma arquitetura viável, através da

especificação de todas as características do produto, com Iniciação e validação de uma arquitetura que às atenda

– Preparação para decisão (vai/não-vai), frente à escalada de custos nas fases posteriores

Detalhes da Fase de Elaboração [Kruchten, 2000](2 de 5)

• Objetivos– Definir, validar e criar uma linha de base para

a arquitetura – Criar uma linha de base para o documento de

visão– Criar uma linha de base para o plano de

execução da fase de construção, com alto grau de fidelidade

– Demonstrar que a arquitetura da linha de base suportará a visão de linha de base, dentro de custo e prazo razoáveis

• Atividades– Refinar a visão, até que o entendimento pleno dos

casos de uso críticos– Montar a estrutura de suporte para o desenvolvimento– Construir protótipos executáveis, em uma ou mais

interações– Atacar os casos de uso críticos, que expõe os maiores

riscos técnicos– Construir protótipos evolucionários ou descartáveis,

com objetivo de analisar custos-benefícios, demonstrar para investidores, clientes e usuários

• Resultados (artefatos)– Modelo de casos de uso (80% ou mais)– Requisitos não funcionais– Descrição da arquitetura do software– Protótipos arquiteturais executáveis– Revisão da visão de negócios e lista de riscos– Plano detalhado de desenvolvimento do

projeto, com interações e critérios de avaliação– Plano de processo de desenvolvimento– Manual de usuário preliminar

• Marco de conclusão– arquitetura do ciclo de vida (lifecycle architecture

milestone)– Critérios de Satisfação (para suporte à decisão sobre

continuar ou não com o projeto)• A visão do produto é estável?• A arquitetura é estável frente os requisitos?• A demonstração executável mostrou que os elementos de

maior risco foram abordados satisfatoriamente?• O plano de desenvolvimento está suficientemente detalhado e

preciso? O plano é consistente e coerente?• Todos os interessados concordam quando à coerência entre

visão, plano e arquitetura?• Os custos planejados e executados estão aceitáveis?

Fase de Construção [Kruchten, 2000](1 de 2)

• Meta– Construir o produto, evoluindo sua visão,

arquitetura, até que esteja pronto para release

• Objetivos– Minimizar custos e prazo, enquanto maximiza

qualidade– Concluir desenvolvimento e testes dos

componentes– Validar produto com relação aos requisitos

Fase de Construção [Kruchten, 2000] (2 de 2)

• Resultados (artefatos)– A release do produto, descrito e integrado nas

plataformas adequadas– Manual do usuário

• Marco de conclusão: capacidade operacional inicial (initial operational capability)– Critérios de Satisfação

• A release do produto é suficientemente estável e amadurecida para ser entregue ao usuário?

• Todos os envolvidos estão preparados para a fase de transição?

• O consumo de recursos executado e planejado é ainda aceitável?

Fase de Transição

• Meta– Concluir a entrega do produto para clientes e

usuários até plena satisfação dos objetivos e resultados estabelecidos, incluindo atividades de (entrega, treinamento, suporte e manutenção)

Fase de Transição

• Objetivos– Permitir que o usuário possa usar o produto

independentemente– Obter concordância de todos os envolvidos

acerca do alcance das metas do ciclo de vida– Obter um release final do produto da forma

mais custo-efetiva possível

Fase de Transição

• Atividades– Correção de defeitos– “beta teste” – Operações paralelas com sistema legado– Conversão de bases de dados– Treinamento de usuários a mantenedores– Roll-out para setores de marketing,

distribuição e vendas

Fase de Transição

• Resultados (artefatos)– Em conformidade com atividades

• Marco de conclusão– Release do produto (product release

milestone)– Critérios de Satisfação

• O usuário está satisfeito?• Os custos de manutenção ainda são aceitáveis?

RUP: Fases e Iterações Usuais

• Fase de Iniciação– 1 iteração

• Fase de Elaboração– 1 a 2 iterações

• Fase de Construção– 2 a 3 iterações

• Fase de Transição– 1 a 2 iterações

RUP: Disciplinas

• Disciplinas de Engenharia– Business Modeling – Requirements – Analysis & Design– Implementation – Test – Deployment

• Disciplinas de Suporte– Environment – Project Management – Configuration & Change Management

RUP: Exercício de Disciplinas Numa Iteração [Rational, 2000]

RUP: Fases, Disciplinas e Iterações [Rational, 2000]

RUP: Ciclos de Vida de um Produto

Software XGeração 2

Software XGeração 1

Software XGeração n

• Produção dos artefatos é concorrente, e não seqüencial

• Elementos fundamentais considerados em um ciclo espiral– Objetivos e restrições dos envolvidos – Alternativas para produtos e processos– Identificação e resolução de riscos– Revisão por parte dos envolvidos (stakeholders)– Compromisso no prosseguimento para próxima etapa

• Riscos determinam:– Nível de esforço para próxima etapa– Nível de detalhe dos artefatos a produzir

• Três grandes milestones– Objetivos (LCO), arquitetura (LCA) e capacidade

operacional inicial (IOC)

• Ênfase do sistema e no ciclo de vida, em vez de código

Resultados De Uma Abordagem Iterativa Incremental

• Erros, riscos e inconsistências se tornam evidentes mais cedo

• Encoraja feedback do usuário • Mantém foco do time nas questões cruciais do

projeto• Avaliação periódica e precisa do status do projeto• Carga de trabalho entre equipes é distribuída ao

longo do tempo• Feedback e reflexão ocorrem mais cedo• Envolvidos obtém evidência concreta periódica

sobre status do projeto

Parte I - Aula 5RUP:

Foco em Arquitetura

Arquiteturas Baseadas Em Componentes• O Que É Arquitetura De Um Software Ou

Sistema?• Componentes São Abstrações• Propriedades Externamente Visíveis Dos

Componentes• Arquitetura De Software é uma das Primeiras

Decisões De Projeto• Arquitetura Versus Design• Sistemas possuem mais de uma Estrutura• Visões (Ou Estruturas) Arquiteturais Mais Comuns• Visão 4+1 [Kruchten, 1996]

O Que É Arquitetura De Um Software Ou Sistema?

• Arquitetura é a estrutura, ou as estruturas, do software ou sistema, composta por:– Seus componentes– As propriedades externamente visíveis destes

componentes– Os relacionamentos entre estes

• Todo sistema de software possui uma arquitetura– Que pode não ser conhecida pelos usuários do

sistema, pelos responsáveis pela sua operação– O comportamento externo de cada componente é

parte integrante da arquitetura

Visão 4+1 [Kruchten, 1996]

Componentes e Abstrações

• Componentes de software– São unidades de software fisicamente identificáveis– Possuem uma interface bem definida, – Encapsulam detalhes privados de implementação

• Quais abstrações são componentes?– Objetos? Processos? Processadores? Bibliotecas? Bases

de dados? Produtos comerciais?• São omitidas de uma descrição arquitetural as

informações sobre componentes que não são pertinentes às interações entre eles

• Detalhes privados dos componentes nãopertencem à arquitetura

Propriedades Externamente Visíveis Dos Componentes

Dependem da abstração que se está observando, como:

• Métodos que provê (objetos, classes);• Características de desempenho

(processador, rede);• Tratamento de erros (módulos);• Uso de recursos compartilhados (funções);• Etc.

Arquitetura Versus Design

• Design– Objetiva a realização do sistema como uma entidade

funcional– Faz parte do software life-cycle – Resulta dos requisitos técnicos que o sistema deve

satisfazer• Arquitetura

– Considera um maior escopo de requisitos • Confiabilidade, baixo custo, modificabilidade, segurança,

turnover de pessoal, time-to-market• Horizonte de tempo que extrapola a vida de um sistema em

particular– Representa a organização que a co-produz

Iniciação Da Arquitetura De Software ÉUma Das Primeiras Decisões De Projeto• Restringe a implementação• Direciona estrutura organizacional• Inibe e estimula atributos de qualidade do

sistema• Permitem predições sobre qualidade dos

sistemas• Facilita análise e gerência de mudanças• Auxilia prototipagem evolucionária

Sistemas Possuem Mais De Uma Arquitetura

• Diversos pontos de vista ou visões arquiteturais– Times e sub-times de programação– Processos e sincronizações– Módulos e processos– Subdivisão e sincronização– Desenvolvimento versus runtime

Visões (Ou Estruturas) Arquiteturais Mais Comuns

• Estrutura de módulos• Estrutura lógica ou conceitual• Estrutura de processo ou de coordenação• Estrutura física• Estrutura de usos• Estrutura de chamadas• Fluxo de dados• Fluxo de controle• Estrutura de classes

Unidade

Conceitos Usados Em Arquitetura E Design

• Estilos Arquiteturais• Modelos de Referência• Arquiteturas de Referência• Arquitetura de Software• Arquitetura de Sistema

Relacionamentos Entre Conceitos

Modelo de Referência

EstiloArquitetural

Arquiteturade Referência

Arquiteturade Software

Arquiteturade Sistema

Estilos Arquiteturais

• Descrição dos tipos de componentes• Padrões de

– Controle de execução– Transferência de dados

• Restrições sobre uma arquitetura– cliente-servidor, pipes-e-filtros, camadas, etc

Estilos Arquiteturais Mais Comuns [Shaw, 96]

• Data flow– Batch– Pipes e filtros

• Chamada e retorno– Programa principal e

subrotinas– Remote Procedure Call– Orientado a objetos/TAD– Camadas

• Componentes Independentes– Processos comunicantes

• Cliente/Servidor

– Sistemas de eventos • Invocação Implícita

• Centrado em Dados– Repositório– Blackboard

• Máquina virtual– Interpretador

Modelo De Referência

• Divisão de funcionalidade em partes, juntamente com o fluxo de dados entre estas

• Características de domínios amadurecidos• Compiladores, DBMS, WWW, etc

Modelo de Referência J2EE [J2EE, 2002]

Arquitetura de Referência

Modelo de referência mapeado em:– Componentes de software (os quais irão

cooperativamente implementar a funcionalidade definida no modelo de referência)

– Fluxos de dados entre os componentes

Arquitetura de Referência da Aplicação Smart Ticket [Sun, 2002]

Arquitetura De Sistema

É o que está sendo executado– Processos– Processadores

• CPU• Memória

– Configuração atual da rede (backbone, routers, bridges, etc)

– Mapeamento de processos para servidores

Vantagens do Desenvolvimento Baseado em Arquiteturas

• Gerenciamento da Complexidade– Manutenção de integridade– Instrumento de comunicação

• Controle do Projeto– Arquitetura de um software tende a mimetizar

a arquitetura da organização que o desenvolve, e vice-versa

– Arquitetura do código deve espelhar arquitetura do software

Arquiteturas e Componentes Reusáveis

• Componentes de Software– Runtime– Componentes genéricos, incorporados durante

o desenvolvimento– Componentes de domínios específicos

• Estilos, modelos, arquiteturas de referência• Padrões de projeto

Uma Linguagem de Padrões de Projeto para Programas OO[Gamma, Helm, Vlissides, Johnson 1994]

Memento Adapter Proxy

Bridge

Command

Chain of Responsibility

Singleton

Abstract Factory

Prototype

Template Method

Facade

Factory Method

Observer

MediatorStrategy

Decorator

Flyweight

Composite

Interpreter

Visitor

Iterator

Builder

AdicionandoOperações

EnumerandoFilhos

SalvandoEstado da Operação

CriandoComposições

AdicionandoResponsabilidades

a Objetos

Modificando Peleversus Entranhas

CompartilhandoComposições

DefinindoGramática

DefinindoTravessias

Definindoa Cadeia

CompostoUsando

EvitandoHisterese

CompartilhandoEstratégias

CompartilhandoEstados Compartilhando

Terminais

ConfigurarFábrica

Dinamicamente

ÚnicaInstância

ImplementadaUsando

GerenciamentoComplexo deDependências

Freqüentemente Usa

DefinindoPassos doAlgoritmo

Parte I - Aula 6RUP

Foco em Casos de Uso

Foco em Casos de Uso• Ator e sistema

• Caso de Uso– Seqüência de ações que um sistema executa sob

estímulo de um ator, produzindo um resultado útil e externamente observável pelo ator

• Sistema– Interage com o usuário – Executa ações (internas)– Produz resultados

Ator Sistema

Caso de Uso

Outros Elementos de um Caso de Uso

• Sinal ou estímulo– Produzido pelo ator

• Ação– Procedimento computacional internamente realizado pelo sistema

• Fluxo de eventos – Seqüência de ações (internas) que ocorre em resposta à ativação

do caso de uso

• Resultado observável– Externamente visível (fora do sistema)

Sistema

Caso de Uso

Resultado Ações

Especificação de Casos de Uso s

• Modelo de Casos de Uso– Diagrama com o conjunto de casos de uso de um

sistema

• Diagrama de Caso de Uso– Facilita a visualização de um caso de uso específico

• Fluxo de eventos– Descrição textual das ações que ocorrem durante a

ativação de um caso de uso

• Cenários– Variações do fluxo de eventos básico de um caso de

Identificação, Evolução e Organização de Casos de Uso

• Identificação– Cada caso de uso tem que produzir um resultado

significativo para o usuário• Evolução

– Identificar primeiro os casos de uso de alto nível. Refinar posteriormente.

• Organização– Inclusão (similar à noção de subrotina)– Extensão (refinamento de uma ação do fluxo original

de eventos)– Especialização (refinamento de várias ações do fluxo

original de eventos)

Exemplo de Modelo de Casos de Uso: Sistema de Recursos Humanos [

Exemplo de Diagrama de Caso de Uso: Detalhe de Atualização de Benefícios

Exemplo de Descrição de um Caso de Uso

• Actors: employee, employee account db, healthcare plan system, insurance plan system

• Preconditions– Employee has logged on to the system and selected ‘update

benefits’ option• Basic course

– System retrieves employee account from employee account db– System asks employee to select medical plan type; include

Update Medical Plan– System asks employee to select dental plan type; include Update

Dental Plan ...

• Alternative courses– If health plan is not available in the employee’s area the employee

is informed and asked to select another plan

Casos de Uso no RUP• Modelo de casos de uso de negócios

– Descrever casos de uso da organização que usa o sistema

• Modelo de objetos de negócios– Realiza modelo de casos de uso de negócios

• Modelo de casos de uso– Descreve casos de uso do sistema a desenvolver

• Modelo de design– Realiza modelo de casos de uso

• Modelo de implementação– Implementa modelo de casos de uso

• Modelo de testes– Testa modelo de casos de uso

Introdução À Engenharia De Software Com Foco No RUP: Rational

Unified Process

Parte IConceitos para Entendimento do RUP

jorge@dimap.ufrn - CIC/UnBjhcf/MyBooks/iess/RUP/IntroducaoaEngenhariade... · tarefa contínua e...

Documents

Transcript of jorge@dimap.ufrn - CIC/UnBjhcf/MyBooks/iess/RUP/IntroducaoaEngenhariade... · tarefa contínua e...

Java - cic.unb.brjhcf/MyBooks/itjava/slides/JavaDeployment... · Java TM Deployment Course Java e Engenharia de Software Orientada a Objetos por Jorge H C Fernandes (jhcf@di.ufpe.br)

SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES GSIC701jhcf/MyBooks/cegsic/2009_2011/... · 5.4 A segurança de aplicações na gestão da segurança da informação • ..34 [35] 6.

Sistemas de Informações IF660 - Aula 1 - Princípiosjhcf/MyBooks/iti/IntroducaoAosPrincipiosEObjetiv… · Sistemas de Informações IF660 - Aula 1 - Princípios Jorge Henrique

A Gestão do Conhecimento por Meio da Aplicação de Modelos ...jhcf/MyBooks/iti/palestras/GestaoConhecimento... · para concepção e inserção de novos produtos e serviços. ...

Desenvolvimento de Sistemas Móveis em Java com J2MEjhcf/MyBooks/itjava/slides/DesenvolvimentodeSist… · J2EE [Gupta and Mayank, 2001] Próximos passos • Instalar o WTK 1.0.4

Pesquisa datafolha iess

Introdução à Televisão Digital Interativa: Arquitetura ...jhcf/MyBooks/itvdi/texto/itvdi.pdf · ... do Congresso da Sociedade Brasileira de ... de tecnologia da informação e

Sistema Universidade Exercício de Fixação #1 Java ...jhcf/MyBooks/itjava/slides/... · Java Deployment Course Exercício de Fixação #1 Sistema Universidade Jorge H. C. Fernandes

Modelos de qualidade de gestao de TI-cmmi-spice-cobit-itiljhcf/MyBooks/iti/ModelosQualidadeSWTI/Modelos_de_q... · Modelos de Qualidade emTI e Software: CMMI / SPICE / ITIL / COBIT.

Experiencias de un Banco Pùblico - El Banco del IESS

Objetos e Classes - CIC/UnBjhcf/cursos/DIM322s03.2/Objetos e... · 2006-08-24 · Introdução à Programação com Java e Orientação a Objetos. ... Sumário da aula • Objeto:

Referências Bibliográficas completas IESs

Visão Geral do RUP – Rational Unified Processjhcf/MyBooks/iess/RUP/VisaoGeralDoRUP.pdf · Visão Geral do RUP ... – Documento de visão: visão geral dos requisitos, características

por (Tutorial) - cic.unb.brjhcf/MyBooks/itjava/slides/IntegrandoJavaEBan...Integrando Java e Banco de Dados (Tutorial) por Jorge Henrique Cabral Fernandes ... quaisquer outros programas

Confidential and Proprietary - Internal Audit Consulting ...jhcf/MyBooks/iti/COBIT/COBIT_VisaoGeral_EOCenario... · Confidential and Proprietary - Internal Audit Consulting Group

por Jorge Henrique Cabral Fernandes Recife, Agosto de 2000jhcf/MyBooks/ciber/Ciber2000.pdf · Sites, Bibliotecas Digitais, Computador na Reforma do Ensino e Comércio Eletrônico.

de Objetos - CIC/UnBjhcf/MyBooks/itjava/slides/Conceitos... · 2006-08-24 · Polimorfismo na Construção de Software: um Estudo de Caso usando Contas Bancárias. Java Básico. Copyright

INFRAESTRUTURA DE TECNOLOGIA DA INFORMAÇÃO …jhcf/MyBooks/cegsic/2009_2011/03_GSIC201... · Rodrigo Moraes Vinícius Tafuri Equipe de Tecnologia da Informação Douglas Ferlini

Polimorfismo em Javajhcf/MyBooks/itjava/slides/... · Problemas com Herança Múltipla são solucionados em Java através do uso de interfaces Separação entre subclasses e subtipos

Introdução à Televisão Digital Interativa: Arquitetura ...jhcf/MyBooks/itvdi/slides-jai2004/Introducao... · Introdução à Televisão DigitalInterativa: Arquitetura, ... Apresenta