o processo de desenvolvimento (up/rup) -...

ES-rup-análise-2003

O Processo de Desenvolvimento(UP/RUP)

Mestrado em Ciência da ComputaçãoDisciplina: 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 : waterfall x iterativo e incremental ( possíveis soluções que seriam derivadas para os problemas dedesenvolvimento?)

gerenciar requisitos : o desafio: os requisitos são dinâmicos(possíveis soluções que seriam derivadas para os problemas de desenvolimento?)Requisito = condição ou capacidade que umsistema deve satisfazer.


Boas Práticaso gerenciamento de requisitos envolve:

elicitar, organizar e documentar as funcionalidadese restrições do sistema;avaliar as modificações e seus impactos edocumentar compromissos e decisões.


Boas Práticas

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

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

modelar visualmente o software: ajuda a melhorar ahabilidde da equipe para gerenciar a complexidade do software. (possíveis soluções que seriam derivadas para os problemas de desenvolvimento?)

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


Boas Práticas

verificar continuamente a qualidade do software: em relação à sua funcionalidade,confiabilidade, desempenho - testar cenárioscontrolar modificações do software: grandes equipes e sistemas complexos um controle coordenado de modificações para manter aconsistê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 deuma organização;é um process product: existe toda uma família deprodutos / ferramentas para dar o suporte;é um process framework: pode ser adaptado eextendido 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:Worker: “quem” - descreve o comportamentodo indivíduo no negócio e asresponsabilidades.

Exs: analista de sistema;projetista,gerente de projeto,projetista de interface,gerente de configuração


Elementos da Modelagem

Atividades: como - unidade de trabalho que oindivíduo com um determinado papel deve executar e produzir um resultado no contexto doprojeto.

Ex: planejar uma iteração - gerente de projeto;encontrar atores e use case - analista desistema;

Artefatos: o que - pedaço de informação que éproduzido, modificado ou usado por um processo.

Ex: um modelo de projetoWorkflow: quando - sequência de atividades que produzem um resultado de valor.


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?

Iteraçõescomo garantir que o projeto está convergindo?

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 doprocesso;

o produto é de melhor qualidade.


Ciclo de Vida UPO ciclo de vida está organizado em:

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

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, e cada release é um produto pronto para entrega.


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

Milestone Milestone Milestone Milestoneobjetivo Arquitetura Capaciadade releaseciclo vida ciclo vida operacional produto


As Fases...a)Inicial:

entender os requisitos e determinar o escopo do projetoConcentra-se em:

delimitar o escopo do sistema proposto,

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

identificar os riscos críticos,

construir um protótipo do sistema proposto comas idéias básicas do novo sistema

Pode-se decidir por continuar ou abandonar.


As Fases...

b) elaboração:

Concentra-se em:Elaborar a arquitetura básica do sistema proposto,

identificar e detalhar os use-cases,

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:Implementar, testar e integrar os mini-projetos para compor o sistema como um todo

Completar o desenvolvimento dos use-case

Disponibilizar a versão beta


As Fases...

Transição: é considerada uma espécie de período de análise pelos usuários do produto desenvolvidoConcetra-se em:

implantar o produto no ambiente , adequar às características desse ambiente, proporcionar treinamento aos usuários, 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 clientese outros stakeholders sobre o que o sistema fariae porque;prover os desenvolvedores do sistema com ummelhor 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 tempopara 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 todoModelo do domínio modelo de software


Artefatos1) Artefatosa) Modelo De Use Case

desenvolvedores de software e clientes entram em acordo sobre os requisitos.modelo contendo os atores e use case e suas relações.


Artefatos

b) Ator:Usuário; Worker; o papel desempenhado;sistema externo que o sistema interage;partes fora do sistema que colaboram com osistema.identificados os atores de um sistema identificou o ambiente externo do sistema.


Artefatos

C) Use Caseespecifica 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:capturado como uma descrição textual da sequenciade ações do use case.especifica como o sistema interage com atores quandoo use case é executado.

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


Artefatos

d) Descrição Da Arquiteturavisão arquitetural do modelo de use caseinclui use case com funcionalidade crítica ou importante, envolve requisito importante que deveser desenvolvido.

e) Glossário definir os conceitos, notações e termos importantes e comuns usados pelos analistas ( eoutros desenvolvedores).é útil para alcançar um consenso entre os desenvolvedores.


Artefatos

f) Protótipo Da Interface Do Usuárioajudam a capturar e entender as interações específicas entre os atores humanos e o sistemae também entender melhor os use case.


Worker

3) workers:analista de sistema é o responsável por:

delimitar o sistema,encontrar os atores e os use casegarantir que o modelo de use case está completo econsistente.liderar a modelagem e coordenar a captura derequisitos

especificador de use case: é o responsável por:detalhar as descrições de use case e dar suporte ao analista.


workers

projetista de interface do usuário

arquiteto:descrever a visão arquitetural do modelo use case


Workflow (requisitos com workers e artefatos)


Workflow

a) encontrar atores e use casepor que use case e atores?

(i) delimitar o sistema; (ii) esboçar quem/o que (atores) irá interagircom o sistema e a funcionalidade (use case)esperado do sistema; (iii) capturar e definir um glossário de termos comuns descrever funcionalidade dosistema.


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


Workflow

Etapas:a1) encontrar atores:

se existe um modelo de negócio : é direto. um ator para cada worker no negócio e um ator para cada ator de negócio (isto é cada cliente do negócio) que irá usar o sistema deinformação.

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

os atores relevantes esem sobreposição de papéis


Workflow

- a2) encontrar use case:um para todo papel de cada worker que participa na realização do use case do negócio para se chegar a um use case podem ser necessárias várias interações com o usuário.use case deve ser fácil de modificar, rever, testar egerenciar como unidade.definir escopo do use case : alguns são completos por si só, outros pertencem a uma “cadeia”.use case executado com sucesso valor para oator alcançar algum objetivo.


Workflow

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

Esta etapa inclui :preparar glossário de termos usados, se necessário, organizar o modelo de use case como pacotes de use casepreparar uma descrição survey - revisão para:

requisitos funcionais foram capturados como use case?a sequencia de ações está correta, completa eentendivel para cada use casealgum use case prove pouco ou nenhum valor?


Workflow

Resultados:uma versão do modelo use case comatores 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.


Workflowc) detalhar use case:

descrever para cada use case o fluxo de eventos em detalhe, como o use case inicia, termina e a interface com os atores.deve-se definir:

todos os caminhos alternativos do use case:estado inicial (pré-condição) e final (pós-condição)a ordem - sequencia numerada - em que as ações devemser executadas,caminhos não permitidos (ex. pagar uma conta 2 vezes)a interação do sistema com os atores (mensagens eresultados)

descrever as ações do sistema e dos atores


Workflow

quando encerrar as descrições ?os requisitos podem ser entendidos em profundidade, de forma correta ,completo,consistentes.

como formalizar a descrição ?statechart,diagramas de atividades,diagramas de interação.


Workflow

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


Workflow

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

Na construção do protótipo verificar (por ex.):como os use case se relacionam;dados que seriam manipulados;elementos da interface que o ator usa?ações/decisões que o ator toma?informações/diretrizes necessárias antes que o ator chame cada ação no use case?informações necessárias ao sistema?


Workflow

e) estruturar o modelo de use case: pode sernecessário explicitar relações include/extend.


Gerenciar Evento

Coordenador de Participante

Coordenador do

Controlar Participante

Controlar CertificadoCoordenador do Comitê Científi co

Cadastrar Atividade

Gerencia r Programação

Coordenador de Programação

Participante

Controlar Crachá


SUMÁRIO DO WORKFLOW REQUISITOS:

um modelo de negócio ou de dominio;um modelo use case: requisitos funcionais/ não funcionais específicos a cada use case;protótipos/projeto de interfaces;especificação de requisitos suplementares para os requisitos genéricos.


Workflow Análise


Análise

OBJETIVOS DA ANÁLISE:manter uma especificação precisa dos requisitos através do modelo de análise;descrever o modelo de análise usando alinguagem dos desenvolvedores um modelo de análise estrutura os requisitos em uma forma que facilita o entendimento deles,preparando-os, modificando-os e em geral mantendo-osum modelo de análise é o primeiro passo para omodelo de projeto.


modelo use case modelo análisedescrito usando a linguagem do cliente descrito usando a linguagem do

desenvolvedorvisão externa do sistema visão interna do sistemaestruturado por use case: da a estrutura davisão externa

estruturado por classes estereótipos epacotes; dá a visão da estrutura interna

usado principalmente como um contratoentre o cliente os desenvolvedores sobre oque o sistema seria e não faria

usado principalmente pelosdesenvolvedores para entender como osistema seria projetado e implementado

pode conter redundâncias, inconsistênciasentre os requisitos

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

captura a funcionalidade do sistemaincluindo funcionalidade significativaarquiteturalmente

esboça como realizar a funcionalidadedentro do sistema, incluindo afuncionalidade significativaarquiteturalmente, trabalha como umprimeiro passo para o projeto

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

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


Artefatos

a) modelo de análise:constituído da análise de sistema que é opacote do nível de topo, constituído depacotes 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çãode um ou várias classes e/ou subsistemas noprojeto do sistema.características:

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

raramente provê ou define interface em termos de operações e suas assinaturas -define responsabilidades define atributos, em um nível mais altoconceituais e reconhecíveis do domínio doproblema. Podem se tornar classes no projetoe implementação.envolvida em relações conceituais obedecem aos 3 estereótipos: de limite, de controle ou entidade.


Artefatos

use-case realization - análise:descreve como um use case específico écompreendido e executado em termos de classes de análise interagindo. Provê umrastreamento para um use case específico nomodelo de use case.


Artefatos

é constituído de:uma descrição textual do fluxo de eventos,diagrama de classes com as classes de análise participantes 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 deobjetos de análise. ( figuras: diagrama de classe para realization do use case pagto fatura e do diagrama de colaboração correspondente).


Artefatos

Um texto escrito em termos de objetos, contem o fluxode eventos da análise e facilitaria aleitura/compreensão do diagrama de colaboração.

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

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:organizar os artefatos do modelo de análise em pedaços gerenciáveis.pode consistir de classes de análise, use case realization eoutros pacotes de análise recursivamenteUm pacote de análise seria coeso e fracamente acoplado.


Artefatos

características:pode representar uma separação de interesses: alguns pacotes de análise podem seranalisados separadamente, por diferentes desenvolvedores com diferentes conhecimentosdo domínio.seriam criados com base nos requisitos funcionais e no domínio do problema e seriam reconhecidos pelas pessoas com conhecimentodo domínio.


Artefatos

pode-se ter também pacote de serviços (serviços providos pelo sistema ao cliente) Ex. verificar ortografiaa funcionalidade de um pacote de serviço podeser gerenciada como uma unidade. o pacote de serviço constitui uma entrada essencial para as atividades de projeto eimplementação subsequentes.


Artefatos

d) descrição arquitetural ( visão do modelo deanálise):

é constituído:a decomposição do modelo de análise em pacotesde análise e suas dependências. as classes de análise ( entidade, limite e controle).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 necessita ser desenvolvido anteriormente no ciclode vida de software


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: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 realizationque participa.mantém a integridade de pacotes de análise,garantindo a corretude e que a dependência em relação a outros pacotes está correta e mínima.


Workflow

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

engenheiros de use case definem os use case realization em termos das classes de análise que participam;arquitetos identificam os maiores pacotes de análise, as classes entidade e os requisitos;engenheiro de componentes especifica os requisitos eintegra-os em cada classe(responsabilidades, atributose relações consistentes).


Workflow

Principais atividades:a) análise arquitetural: esboçar o modelo de análise

e a arquitetura identificando os pacotes de análise, as classes de análise e os requisitos especiais.

a1) identificando os pacotes de análise:organizar o modelo de análise dividindo o trabalho deanálise, podem ser encontrados no modelo de análiseà medida que ele evolui e necessita ser decomposto.


WorkflowCritérios para identificar os pacotes deanálise:

os requisitos funcionais = use caseidentificar pacotes de análise é alocar aporção principal de um número de use casepara um pacote em específico e então compreender a funcionalidade correspondente.estratégias:

os use case requeridos para suportar um processode negócio específicoos use case requeridos para suportar um ator específico do sistema;


Workflow

os use case que são relacionados (figuraabaixo)


Workflow

dois ou mais pacotes que compartilham asmesmas classes extrair as classescompartilhadas, colocá-los em seu pacote próprio ou outro pacote e definir asdependências onde for o caso.


Workflow

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


Workflow

A direção de dependência = direção denavegabilidade. Os pacotes são fracamente acoplados efortemente coesos


Workflow

identificar classes:algumas com base nas classes do domínio ou entidades do negócio são identificadas durante acaptura dos requisitos.muitas serão identificadas quando o use case realization for executada. as agregações e associações entre as classes dedomí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 econcorrência; características de segurança, tolerância afalhas, gerenciamento de transações.

Ex: as características chave de um requisito especial:Um requisito persistência tem as seguintes caracterísitcas:Intervalo de valores válidos para um atributo; o volume; o período de persitêcia; a frequência de atualização; confiabilidae (objetos sobreviveriam a um crash)


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:

Esboçar nome, responsabilidade, atributos e relações,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áliseb3) capturar os requisitos especiais - não funcionais.

Exemplos: A fatura deve ser persistenteA classe Manipular Pedido sdeve ser capaz de manipular 10000

transações por hora.


Workflow

c) analisar uma classe:objetivos:

c1) identificar e manter as responsabilidades deuma classe de análise com base no seu papelno use case realization.onde encontrar?

combinando os papéis desempenhados nos diferentes use case realization;estudando os diagramas de classe, de interação e adescriçã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

do use cse Fatura Comprador como do use case Pagar Fatura”.


Workflow

c2) identificar e manter os atributos e relaçõesdas classes de análisecomo identificar os atributos?

o nome deve ser um substantivo;os atributos seriam conceituais;tentar reusar um que já exista;um único atributo não pode ser compartilhado por vários objetos de análisecomplexidade para compreensão de uma classe por causa dos atributos, estes devem ser separados

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


Workflow

c3) capturar os requisitos especiais da classeno use case realization-análise.


Workflow

d) analisar um pacote.objetivo:

(i) garantir que os pacotes são independentes um do outro;(ii) garantir que o pacote colabora em um use case realization;(iii) descrever dependências de modo que o efeitode próximas modificações possam ser estimadas.


Workflow

principais diretrizes: (figura a seguir):definir e manter as dependências entre pacotes;certificar que contém as classes corretaslimitar as dependências a outros pacotes.


SUMÁRIO DO WORKFLOW ANÁLISE

os resultados:Pacotes de análise e pacotes de serviço e suas dependências e conteúdos.Classes de análise e suas responsabilidades,atributos, relações e requisitos especiaisuse case realization - análiseVisão arquitetural

o processo de desenvolvimento (up/rup) -...

Documents