[email protected] - cic/unbjhcf/mybooks/iess/rup/introducaoaengenhariade... · tarefa contínua e...

Introdução à Engenharia de Software com foco no RUP – Rational Unified Process © 2004 por Jorge H C Fernandes

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

Rational Unified Process

Prof. Dr. Jorge Henrique C Fernandes ([email protected])

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


Introdução à Engenharia de Software com Foco no RUP: Rational Unified Process• Copyright © 2003, por Jorge Henrique C

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)

Tempo

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


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

Resultados

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

Unidade

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]

State

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

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

Ú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)

Ator

Sistema

Caso de Uso

Sinal

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

uso


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

[email protected] - cic/unbjhcf/mybooks/iess/rup/introducaoaengenhariade... · tarefa contínua e...

Documents