O Processo de Desenvolvimento (UP/RUP)

O Processo de Desenvolvimento (UP/RUP)

Mestrado em Ciência da Computação Disciplina: Engenharia de Software

Profa. Dra. Elisa H. M. Huzita

Processo de Desenvolvimento de Software

O processo de desenvolvimento de software é um conjunto de atividades e resultados associados que tem por objetivo produzir software eficiente, de alta qualidade, com baixa taxa de erros e que atenda às necessidades e expectativas do usuário de forma geral, JACOBSON (1999).

Processo de Desenvolvimento de Software

O processo define quem irá fazer o que e como será atingido o objetivo. Entende-se por objetivo a

construção de um software ou a melhoria de um existente.

Boas Práticas

desenvolver o software iterativamente :

z waterfall x iterativo e incremental ( possíveis soluções que seriam derivadas para os problemas de desenvolvimento?)

gerenciar requisitos :

z o desafio: os requisitos são dinâmicos (possíveis soluções que seriam derivadas para os problemas de desenvolimento?)

z Requisito = condição ou capacidade que um sistema deve satisfazer.

Boas Práticas

z o gerenciamento de requisitos envolve:

z elicitar, organizar e documentar as funcionalidades e restrições do sistema;

z avaliar as modificações e seus impactos e

z documentar compromissos e decisões.

Boas Práticas

usar arquiteturas baseada em componentes: possibilita o reuso ou customização de componentes.

z iteração + CBD : a cada iteração pode-se medir, testar e avaliar em relação aos requisitos.

modelar visualmente o software: ajuda a melhorar a habilidde da equipe para gerenciar a complexidade do software. (possíveis soluções que seriam derivadas para os

problemas de desenvolvimento?)

z Um modelo é uma simplificação da realidde que descreve completamente um sistema de uma perspectiva em

Boas Práticas

verificar continuamente a qualidade do

software: em relação à sua funcionalidade, confiabilidade, desempenho - testar cenários controlar modificações do software: grandes

equipes e sistemas complexos um controle coordenado de modificações para manter a

consistência.

O que é a RUP

é um processo de engenharia de software: provê uma abordagem disciplinada - por todo o ciclo de vida para assinalar tarefas e responsabilidades dentro de uma organização;

é um process product: existe toda uma família de produtos / ferramentas para dar o suporte;

é um process framework: pode ser adaptado e extendido para satisfazer as necessidades da organização que está adotando;

é dirigido a use case;

segue as boas práticas de desenvolvimento.

é uma especialização do UP

Caracterísitcas do UP

Dirigido a use-case - os use-cases estão presentes desde a captura dos requisitos até a realização dos testes do sistema.

Centrado na arquitetura - significa que um sistema de arquitetura é usado como um artefato primário para conceituação, construção, gerenciamento e evolução do sistema no processo de desenvolvimento

Caracterísitcas do UP

Desenvolvimento iterativo e incremental - cada parte do projeto , passa por todas as fases de

desenvolvimento (inicio, elaboração, construção e

transição). Cada workflow pode ser repetido (iteração) até que se atinja as necessidades do projeto. Em cada nova iteração os riscos são identificados e analisados.

Elementos da Modelagem

Processo: descreve quem está fazendo o que, como e quando.

No UP:

z Worker: “quem” - descreve o comportamento do indivíduo no negócio e as

responsabilidades.

z Exs: analista de sistema;

projetista,

gerente de projeto,

Elementos da Modelagem

z Atividades: como - unidade de trabalho que o indivíduo com um determinado papel deve

executar e produzir um resultado no contexto do projeto.

z Ex: planejar uma iteração - gerente de projeto;

encontrar atores e use case - analista de sistema;

z Artefatos: o que - pedaço de informação que é

produzido, modificado ou usado por um processo.

z Ex: um modelo de projeto

Workflow: quando - sequência de atividades que

Workflow do RUP

de engenharia de suporte

* modelagem do negócio * gerenciamento de projeto

* requisitos * gerenciamento de

* análise e projeto configuração e de

* implementação modificação

* teste * ambiente

* entrega

Arquitetura do UP

Ciclo de Vida UP

como vencer pontos fracos do modelo cascata?

z Iterações

como garantir que o projeto está convergindo?

z Fases e Milestones

Vantagens da Iteração

riscos são amenizados antecipadamente;

as modificações são melhor gerenciáveis;

existe um maior grau de reuso;

a equipe de projeto pode aprender ao longo do processo;

o produto é de melhor qualidade

.

Ciclo de Vida UP

O ciclo de vida está organizado em:

z fases: inicio, elaboração, construção e transição

z workflows: requisitos, análise, projeto, implementação e teste

Cada fase pode ser dividida em um ou mais iterações e termina com um maior ou menor milestone respectivamente.

Cada ciclo resulta em uma nova release do sistema,

Inicial Elaboração Construção Transição

Milestone Milestone Milestone Milestone objetivo Arquitetura Capaciadade release ciclo vida ciclo vida operacional produto

As Fases...

a)Inicial:

entender os requisitos e determinar o escopo do projeto

Concentra-se em:

z delimitar o escopo do sistema proposto,

z descrever ou delinear a arquitetura do sistema (principalmente as partes do sistemas que são novas, de risco ou apresentam dificuldades),

z identificar os riscos críticos,

z construir um protótipo do sistema proposto comas idéias

As Fases...

b)

Concentra-se em:

z Elaborar a arquitetura básica do sistema proposto,

z identificar e detalhar os use-cases,

z desenvolver um plano de projeto e eliminar os elementos de maior risco para o projeto.

As Fases...

Construção: é o desenvolvimento do produto propriamente dito

Concentra-se em:

z Implementar, testar e integrar os mini-projetos para compor o sistema como um todo

z Completar o desenvolvimento dos use-case

z Disponibilizar a versão beta

As Fases...

Transição: é considerada uma espécie de

período de análise pelos usuários do produto desenvolvido

Concetra-se em:

z implantar o produto no ambiente ,

z adequar às características desse ambiente,

z proporcionar treinamento aos usuários,

z oferecer assistência técnica.

Workflow do UP

* requisitos

* análise

* projeto

* implementação

* teste

Workflow Requisitos

1) Objetivos:

estabelecer e manter um acordo com os clientes e outros stakeholders sobre o que o sistema faria e porque;

prover os desenvolvedores do sistema com um melhor entendimento dos requisitos do sistema;

definir os limites do sistema;

prover uma base para planejamento do conteúdo técncio das iterações;

Workflow Requisitos

prover uma base para estimar custo e tempo para desenvolver o sistema;

definir uma interface do usuário

Domínio x negócio

Modelo do Domínio X Modelo do Negócio

parte todo

Às vezes parte coincide com o todo

Modelo do domínio modelo de software

Artefatos 1) Artefatos

a)

z desenvolvedores de software e clientes entram em acordo sobre os requisitos.

z modelo contendo os atores e use case e suas relações.

Artefatos

b)

z Usuário;

z Worker;

z o papel desempenhado;

z sistema externo que o sistema interage;

z partes fora do sistema que colaboram com o sistema.

z identificados os atores de um sistema

Artefatos

C) Use Case

especifica uma sequência de ações incluindo alternativas de sequencia que o sistema pode executar, interagindo com os atores do sistema.

c1) fluxo de eventos:

z capturado como uma descrição textual da sequencia de ações do use case.

z especifica como o sistema interage com atores quando o use case é executado.

c2) requisitos especiais: requisitos não funcionais sobre um use case.

Artefatos

d) Descrição Da Arquitetura

z visão arquitetural do modelo de use case

inclui use case com funcionalidade crítica ou

importante, envolve requisito importante que deve ser desenvolvido.

e) Glossário

z definir os conceitos, notações e termos

importantes e comuns usados pelos analistas ( e outros desenvolvedores).

z é útil para alcançar um consenso entre os

Artefatos

f)

z ajudam a capturar e entender as interações

específicas entre os atores humanos e o sistema e também entender melhor os use case.

Worker

3) workers:

analista de sistema é o responsável por:

z delimitar o sistema,

z encontrar os atores e os use case

z garantir que o modelo de use case está completo e consistente.

z liderar a modelagem e coordenar a captura de requisitos

workers

projetista de interface do usuário arquiteto:

z descrever a visão arquitetural do modelo use case

Workflow (requisitos com workers e

artefatos)

Workflow

a) encontrar atores e use case

z por que use case e atores?

z (i) delimitar o sistema;

z (ii) esboçar quem/o que (atores) irá interagir com o sistema e a funcionalidade (use case) esperado do sistema;

z (iii) capturar e definir um glossário de termos comuns descrever funcionalidade do

sistema.

As entradas e saídas de identificar atores e use case

Workflow

Etapas:

z a1) encontrar atores:

z se existe um modelo de negócio : é direto.

z um ator para cada worker no negócio

z e um ator para cada ator de negócio (isto é cada cliente do negócio) que irá usar o sistema de

informação.

z se não, identificar com o cliente os usuários e tentar organizá-los em categorias:

z os atores relevantes e

z sem sobreposição de papéis

Workflow

- a2) encontrar use case:

z um para todo papel de cada worker que participa na realização do use case do negócio

z para se chegar a um use case podem ser necessárias várias interações com o usuário.

z use case deve ser fácil de modificar, rever, testar e gerenciar como unidade.

z definir escopo do use case : alguns são completos por si só, outros pertencem a uma “cadeia”.

Workflow

-a3) descrever brevemente cada use case -a4) descrever o modelo de use case :

z Esta etapa inclui :

z preparar glossário de termos usados,

z se necessário, organizar o modelo de use case como pacotes de use case

z preparar uma descrição survey - revisão para:

z requisitos funcionais foram capturados como use case?

z a sequencia de ações está correta, completa e entendivel para cada use case

Workflow

Resultados:

uma versão do modelo use case com

atores e use case novos ou

modificados.

Workflow

b) estabelecer prioridade entre os use case:

determinar/planejar use case a serem

implementados em iterações iniciais os que serão postergados.

Workflow

c) detalhar use case:

z descrever para cada use case o fluxo de eventos em detalhe, como o use case inicia, termina e a interface com os atores.

z deve-se definir:

z todos os caminhos alternativos do use case:

z estado inicial (pré-condição) e final (pós-condição)

z a ordem - sequencia numerada - em que as ações devem ser executadas,

z caminhos não permitidos (ex. pagar uma conta 2 vezes)

z a interação do sistema com os atores (mensagens e

Workflow

z quando encerrar as descrições ?

z os requisitos podem ser entendidos em profundidade,

z de forma correta ,

z completo,

z consistentes.

z como formalizar a descrição ?

z statechart,

z diagramas de atividades,

z diagramas de interação.

Workflow

resultado:

z descrição detalhada de um particular use case: em texto e diagramas.

Workflow

d) construir protótipo da interface do usuário: {protótipos e esboços de interfaces que especificarão o look and feel das interfaces para os atores mais importantes }.

z Na construção do protótipo verificar (por ex.):

z como os use case se relacionam;

z dados que seriam manipulados;

z elementos da interface que o ator usa?

z ações/decisões que o ator toma?

z informações/diretrizes necessárias antes que o ator chame cada ação no use case?

z informações necessárias ao sistema?

Workflow

e) estruturar o modelo de use case

:

necessário explicitar relações include/extend.

Gerenciar Evento Coordenador de Participante

Coord enador do Controlar Participante

Controlar Certificado Co orden ador do Com itê Científi co

Cadastrar Atividade

Geren cia r Program ação Coordenador de Program ação

Participante

Controlar Crachá

SUMÁRIO DO WORKFLOW REQUISITOS:

z um modelo de negócio ou de dominio;

z um modelo use case: requisitos funcionais/ não funcionais específicos a cada use case;

z protótipos/projeto de interfaces;

z especificação de requisitos suplementares para os requisitos genéricos.

Workflow Análise

Análise

OBJETIVOS DA ANÁLISE:

z manter uma especificação precisa dos requisitos através do modelo de análise;

z descrever o modelo de análise usando a linguagem dos desenvolvedores

z um modelo de análise estrutura os requisitos em uma forma que facilita o entendimento deles,

preparando-os, modificando-os e em geral mantendo-os

um modelo de análise é o primeiro passo para o

modelo use case modelo análise

descrito usando a linguagem do cliente descrito usando a linguagem do desenvolvedor

visão externa do sistema visão interna do sistema estruturado por use case: da a estrutura da

visão externa

estruturado por classes estereótipos e pacotes; dá a visão da estrutura interna usado principalmente como um contrato

entre o cliente os desenvolvedores sobre o que o sistema seria e não faria

usado principalmente pelos desenvolvedores para entender como o sistema seria projetado e implementado pode conter redundâncias, inconsistências

entre os requisitos

não conteria redundâncias, inconsistências entre os requisitos

captura a funcionalidade do sistema incluindo funcionalidade significativa arquiteturalmente

esboça como realizar a funcionalidade dentro do sistema, incluindo a funcionalidade significativa arquiteturalmente, trabalha como um primeiro passo para o projeto

define os use case que são depois analisados no modelo de análise

define as realizações de use case, cada um representando a análise de um use case do

Artefatos

a) modelo de análise:

constituído da análise de sistema que é o pacote do nível de topo, constituído de pacotes de análise, classes de análise e use case-realization - análise

Figura do modelo de análise

Artefatos

b) classe de análise: representa uma abstração de um ou várias classes e/ou subsistemas no projeto do sistema.

características:

z enfoca sobre a manipulação dos requisitos funcionais mais óbvia no contexto do domínio do problema, mais conceitual e de granularidade maior do que o seu

correspondente projeto e implementação.

Artefatos

z raramente provê ou define interface em termos de operações e suas assinaturas - define responsabilidades

z define atributos, em um nível mais alto

conceituais e reconhecíveis do domínio do

problema. Podem se tornar classes no projeto e implementação.

z envolvida em relações conceituais obedecem aos 3 estereótipos: de limite, de controle ou entidade

.

Artefatos

use-case realization - análise:

z descreve como um use case específico é compreendido e executado em termos de classes de análise interagindo. Provê um

rastreamento para um use case específico no modelo de use case.

Artefatos

é constituído de:

z uma descrição textual do fluxo de eventos,

z diagrama de classes com as classes de análise participantes

z os diagramas de interação (colaboração) que

desenham a compreensão de um particular fluxo ou cenário de use case em termos das interações de

objetos de análise. ( figuras: diagrama de classe para realization do use case pagto fatura e do diagrama de colaboração correspondente).

Artefatos

z Um texto escrito em termos de objetos, contem o fluxo de eventos da análise e facilitaria a

leitura/compreensão do diagrama de colaboração.

z requisitos especiais: descrições textuais que coletam todos os requisitos não funcionais sobre um use case realization

z Ex: quando um comprador solicitar a visualização das

faturas recebidas, não levaria mais do que 0,5 segundos.

As faturas seriam pagas usando um padrão X.

Artefatos

c) pacote de análise:

z organizar os artefatos do modelo de análise em pedaços gerenciáveis.

z pode consistir de classes de análise,

z use case realization e

z outros pacotes de análise recursivamente

z Um pacote de análise seria coeso e fracamente acoplado.

Artefatos

z características:

z pode representar uma separação de interesses : alguns pacotes de análise podem ser

analisados separadamente, por diferentes

desenvolvedores com diferentes conhecimentos do domínio.

z seriam criados com base nos requisitos

funcionais e no domínio do problema e seriam reconhecidos pelas pessoas com conhecimento do domínio.

Artefatos

z pode-se ter também pacote de serviços (serviços providos pelo sistema ao cliente) Ex. verificar

ortografia

z a funcionalidade de um pacote de serviço pode ser gerenciada como uma unidade.

z o pacote de serviço constitui uma entrada essencial para as atividades de projeto e implementação subsequentes.

Artefatos

d)

z é constituído:

z a decomposição do modelo de análise em pacotes de análise e suas dependências.

z as classes de análise ( entidade, limite e controle).

z use case realization de uma funcionalidade crítica/

importante e envolve vários pacotes de análise, ou foco sobre algum use case importante que

Worker

a)arquiteto: responsável pela integridade (correto, consistente e legível ) do modelo de análise,

b) engenheiro de use case: responsável por um ou mais use case realization

c) engenheiro de componente:

z define e mantém as responsabilidades, atributos,

relações e requisitos especiais das classes de análise, de acordo com os requisitos do use case realization que participa.

z mantém a integridade de pacotes de análise,

Workflow

os passos para a criação do modelo de análise:

z engenheiros de use case definem os use case realization em termos das classes de análise que participam;

z arquitetos identificam os maiores pacotes de análise, as classes entidade e os requisitos;

z engenheiro de componentes especifica os requisitos e integra-os em cada classe(responsabilidades, atributos

Workflow

Principais atividades:

a) análise arquitetural

:

a1) identificando os pacotes de análise:

z organizar o modelo de análise dividindo o trabalho de análise, podem ser encontrados no modelo de análise à medida que ele evolui e necessita ser decomposto.

Workflow

Critérios para identificar os pacotes de análise:

z os requisitos funcionais = use case

identificar pacotes de análise é alocar a

porção principal de um número de use case para um pacote em específico e então

compreender a funcionalidade correspondente.

z estratégias:

z os use case requeridos para suportar um processo

Workflow

z os use case que são relacionados (figura abaixo)

Workflow

z dois ou mais pacotes que compartilham as mesmas classes extrair as classes

compartilhadas, colocá-los em seu pacote próprio ou outro pacote e definir as

dependências onde for o caso.

Workflow

z as classes de análise dentro do mesmo pacote de serviço contribuirão para o mesmo serviço.

z Pacote serviço

Workflow

z A direção de dependência = direção de navegabilidade.

z Os pacotes são fracamente acoplados e fortemente coesos

Workflow

identificar classes:

z algumas com base nas classes do domínio ou entidades do negócio são identificadas durante a captura dos requisitos.

z muitas serão identificadas quando o use case realization for executada.

z as agregações e associações entre as classes de domínio no modelo de domínio pode ser usado para identificar um conjunto de associações entre as

classes entidades.

Workflow

a3) identificar os requisitos especiais:

capturar para que sejam adequadamente manipulados nas fases subsequentes. Exs: persistência, distribuição e concorrência; características de segurança, tolerância a falhas, gerenciamento de transações.

z Ex: as características chave de um requisito especial:

z Um requisito persistência tem as seguintes caracterísitcas:

z Intervalo de valores válidos para um atributo; o volume; o

Workflow

b) analisar um use case:

Workflow

b1) identificar as classes de análise cujos objetos são necessários para executar o fluxo de eventos do use case:

z Esboçar nome, responsabilidade, atributos e relações,

z descrever as interações dos objetos de análise usando o diagrama de colaboração para cada fluxo ou subfluxo,

b2) Cada use case é refinado como uma colaboração de classes de análise

b3) capturar os requisitos especiais - não funcionais.

Exemplos:

Workflow

c) analisar uma classe:

z objetivos:

c1) identificar e manter as responsabilidades de uma classe de análise com base no seu papel no use case realization.

z onde encontrar?

z combinando os papéis desempenhados nos diferentes use case realization;

z estudando os diagramas de classe, de interação e a descrição textual

Workflow

Exemplo de descrição textual:

“ Os objetos Fatura são criados durante o use case Fatura do Comprador. O vendedor executa este use case para cobrar pelo pagamento de uma compra ( um pedido que foi criado durante o use case Solicite Produtos e Serviços). Durante a execução do use case, a Fatura é passada para o comprador que pode mais tarde decidir por pagá-la.

O pagamento é efetuado no use case Pagar Fatura onde o objeto EscalonaPagto escalona um objeto Fatura para

pagamento. Mais tarde a fatura é paga e o objeto Fatura é liquidado.

Note no entanto que a mesma instância Fatura participa tanto

Workflow

z c2) identificar e manter os atributos e relações das classes de análise

z como identificar os atributos?

z o nome deve ser um substantivo;

z os atributos seriam conceituais;

z tentar reusar um que já exista;

z um único atributo não pode ser compartilhado por vários objetos de análise

z complexidade para compreensão de uma classe por causa dos atributos, estes devem ser separados

z identifcar as relações de associação, generalização e agregação

Workflow

z c3) capturar os requisitos especiais da classe no use case realization-análise.

Workflow

d) analisar um pacote.

z objetivo:

z (i) garantir que os pacotes são independentes um do outro;

z (ii) garantir que o pacote colabora em um use case realization;

z (iii) descrever dependências de modo que o efeito de próximas modificações possam ser estimadas.

Workflow

z principais diretrizes: (figura a seguir):

z definir e manter as dependências entre pacotes;

z certificar que contém as classes corretas

z limitar as dependências a outros pacotes.

SUMÁRIO DO WORKFLOW ANÁLISE

os resultados:

z Pacotes de análise e pacotes de serviço e suas dependências e conteúdos.

z Classes de análise e suas responsabilidades, atributos, relações e requisitos especiais

z use case realization - análise