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

(1)

1

Pólo de Tecnologia da Informação

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ção Departamento De Informática E Mat. Aplicada Universidade Federal Do Rio Grande Do Norte

(2)

2

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

(3)

3

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, Mark Johnson, 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 Case Modeling. Cris Kobryn. OMG UML Tutorial Series.2001

(4)

4

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

(5)

5

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

(6)

6

Conteúdo: RUP – Módulo Introdutório

A1. Abordagens efetivas para desenvolvimento de software

A2. Conceitos e

Organização do RUP A3. Estrutura estática e

dinâmica do RUP A4. Foco em arquitetura A5. Foco em casos de uso A6. Disciplina de gestão de

projetos A7. Disciplina de

modelagem de negócios A8. Disciplina de requisitos

A9. Disciplina de análise e projeto

A10. Disciplina de implementação A11. Disciplina de testes A12. Disciplina de gestão de

configuração e mudanças

A13. Disciplina de (gestão de) ambiente

A14. Disciplina de instalação A15. Sumário e conclusões

(7)

7

Introdução À Engenharia De

Software Com Foco No RUP: Rational

Unified Process

Parte I

(8)

8

Parte I - Aula 1

Abordagens Efetivas Para

Desenvolvimento De Software

(9)

9

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

(10)

10

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

(11)

11

Atividades Econômicas E O Software

• Empresas e o software

• Indivíduos e o software

• Sociedade e o software

(12)

12

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

(13)

13

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

(14)

14

Sintomas E Causas De Problemas No

Desenvolvimento De Software [Booch, 1999]

1.Sintomas

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

2.Causas

(15)

15

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

(16)

16

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

(17)

17

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

(18)

18

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

(19)

19

Abordagem Efetiva #1: Desenvolver

Software Iterativamente

Modelo Cascata

Versus

Modelo Espiral

(20)

20

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

requisitos

design

implementação

testes

(21)

21

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

(22)

22

(23)

23

Um Ciclo na Espiral do RUP

[Rational, 2000]

(24)

24

(25)

25

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

(26)

26

Invariantes De Processos Baseados No

Modelo Espiral (2 De 2)

• 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

(27)

27

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

(28)

28

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

(29)

29

Abordagem Efetiva #3: Usar

Arquiteturas Baseadas Em

(30)

30

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 é

(31)

31

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ão

pertencem à arquitetura

(32)

32

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.

(33)

33

(34)

34

Abordagem Efetiva #4: Modelar

Visualmente O Software

(35)

35

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

(36)

36

Alguns Modelos Estruturais [Kobryn, 2000]

Diagrama de Classes Diagrama de Objetos “Uma Molécula de Etano (C₂H₆)” “Classes de átomos e Suas ligações”

(37)

37

Diagrama De Componentes Ilustrando

Evolução De UML [Kobryn, 2000]

(38)

38

Modelo Estrutural De Um Site [Conallen,

2000]

(39)

39

Diagramas De Interação: Seqüência E

Colaboração [Övergaard, 2000]

(40)

40

Diagrama De Seqüência

(Elementos) [Övergaard, 2000]

(41)

41

Diagrama De Estados

(42)

42

Diagrama de Atividades

(43)

43

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

(44)

44

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’

(45)

45

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

(46)

46

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

(47)

47

Parte I - Aula 2

O Que É O Rational Unified Process

- RUP?

(48)

48

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

(49)

49

O Que É O RUP?

• RUP: processo de engenharia de software

• RUP: produto comercializado pela IBM/Rational

• RUP: integra-se com ferramentas da

(50)

50

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

(51)

51

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

(52)

52

(53)

53

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

(54)

54

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

(55)

55

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

(56)

56

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

(57)

57

Parte I - Aula 3

(58)

58

(59)

59

RUP: Conceitos e Organização

• Role (Papel)

• Artifact (Artefato) ou WorkProduct

• Activity (Atividade)

• WorkflowDetail (Detalhe de Fluxo)

• Workflow (Fluxo)

• Discipline (Disciplina)

(60)

60

RUP: (Role) Papel, Artifact (Artefato) e Activity

(Atividade) [Rational, 2000]

(61)

61

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

(62)

62

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

(63)

63

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.

(64)

64

(65)

65

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

Atividade Papel

Resultados

Resultados Resultados

(66)

66

RUP: Atividade Ou Activity

• Atividades utilizam um ou mais artefatos

previamente 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

(67)

67

RUP: Atividade Ou Activity

• Uma atividade é um elemento atômico de

planejamento de projeto

(68)

68

RUP: Atividade Ou Activity

• 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

(69)

69

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

(70)

70

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

(71)

71

RUP: Workflow Detail: Analisar o Problema [Rational,

2002]

Atividades Artefatos

(72)

72

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

(73)

73

RUP: Workflow (Fluxo) Típico da

Disciplina de Requisitos [Rational, 2002]

Detalhes de workflow

(74)

74

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

(75)

75

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

(76)

76

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

(77)

77

Tool Mentors (Mentores) [Rational, 2000]

• Guias especializados em uso de

ferramentas

(78)

78

Parte I - Aula

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

Disciplinas e Ciclo de Vida

(79)

79

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

• 2 Estágios: engenharia e produção

• 4 Fases: concepção, elaboração,

construção e transição

• Várias iterações em cada fase

– Viabilidade

– Arquitetura

– Uso

(80)

80

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

(81)

81

RUP: Metas de Cada Fase

• Concepçã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 concepçã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)

(82)

82

Detalhes da Fase de Concepçã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

(83)

83

Detalhes da Fase de Concepção

[Kruchten, 2000] (2 de 5)

• 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

(84)

84

Detalhes da Fase de Concepção

[Kruchten, 2000] (3 de 5)

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

(85)

85

Detalhes da Fase de Concepção

[Kruchten, 2000] (4 de 5)

• 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

(86)

86

Detalhes da Fase de Concepção

[Kruchten, 2000] (5 de 5)

• 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

(87)

87

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 concepçã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

(88)

88

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

(89)

89

Detalhes da Fase de Elaboração

[Kruchten, 2000](3 de 5)

• 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

(90)

90

Detalhes da Fase de Elaboração

[Kruchten, 2000](4 de 5)

• 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

(91)

91

Detalhes da Fase de Elaboração

[Kruchten, 2000](5 de 5)

• 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?

(92)

92

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

(93)

93

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?

(94)

94

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

(95)

95

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

(96)

96

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,

(97)

97

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?

(98)

98

RUP: Fases e Iterações Usuais

• Fase de Concepçã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

(99)

99

RUP: Disciplinas

• Disciplinas de Engenharia

– Business Modeling – Requirements – Analysis & Design – Implementation – Test – Deployment

• Disciplinas de Suporte

– Environment – Project Management

(100)

100

RUP: Exercício de Disciplinas Numa

Iteração [Rational, 2000]

(101)

101

RUP: Fases, Disciplinas e Iterações

[Rational, 2000]

(102)

102

RUP: Ciclos de Vida de um Produto

Software X Geração 2 Software X Geração 1 Software X Geração n

(103)

103

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

(104)

104

Invariantes De Processos Baseados No

Modelo Espiral (2 De 2)

• 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

(105)

105

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

(106)

106

Parte I - Aula

6 RUP:

(107)

107

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]

(108)

108

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 é

(109)

109

(110)

110

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ão

pertencem à arquitetura

(111)

111

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.

(112)

112

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

(113)

113

Concepçã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

(114)

114

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

(115)

115

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

(116)

116

Conceitos Usados Em

Arquitetura E Design

• Estilos Arquiteturais

• Modelos de Referência

• Arquiteturas de Referência

• Arquitetura de Software

• Arquitetura de Sistema

(117)

117

Relacionamentos Entre Conceitos

Modelo de Referência Estilo Arquitetural Arquitetura de Referência Arquitetura de Software Arquitetura de Sistema

(118)

118

Estilos Arquiteturais

• Descrição dos tipos de componentes

• Padrões de

– Controle de execução

– Transferência de dados

• Restrições sobre uma arquitetura

(119)

119

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

(120)

120

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

(121)

121

(122)

122

(123)

123

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)

(124)

124

Arquitetura de Referência da Aplicação

Smart Ticket [Sun, 2002]

(125)

125

Arquitetura De Sistema

É o que está sendo executado

– Processos

– Processadores

• CPU • Memória

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

bridges, etc)

(126)

126

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

(127)

127

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

(128)

128

Parte I - Aula 7

RUP

(129)

129

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

(130)

130

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

(131)

131

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

(132)

132

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)

(133)

133

Exemplo de Modelo de Casos de Uso:

Sistema de Recursos Humanos [

(134)

134

Exemplo de Diagrama de Caso de Uso:

Detalhe de Atualização de Benefícios

(135)

135

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

(136)

136

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

(137)

137