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
ES-rup-análise-2003
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).
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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
ES-rup-análise-2003
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
ES-rup-análise-2003
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.
ES-rup-análise-2003
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
ES-rup-análise-2003
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.
ES-rup-análise-2003
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
ES-rup-análise-2003
Ciclo de Vida UP
como vencer pontos fracos do modelo cascata?
Iteraçõescomo garantir que o projeto está convergindo?
Fases e Milestones
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
Inicial Elaboração Construção Transição
Milestone Milestone Milestone Milestoneobjetivo Arquitetura Capaciadade releaseciclo vida ciclo vida operacional produto
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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
ES-rup-análise-2003
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.
ES-rup-análise-2003
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;
ES-rup-análise-2003
Workflow Requisitos
prover uma base para estimar custo e tempopara desenvolver o sistema;
definir uma interface do usuário
ES-rup-análise-2003
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
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
workers
projetista de interface do usuário
arquiteto:descrever a visão arquitetural do modelo use case
ES-rup-análise-2003
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.
ES-rup-análise-2003
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
ES-rup-análise-2003
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.
ES-rup-análise-2003
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?
ES-rup-análise-2003
Workflow
Resultados:uma versão do modelo use case comatores e use case novos ou modificados.
ES-rup-análise-2003
Workflow
b) estabelecer prioridade entre os use case:determinar/planejar use case a serem implementados em iterações iniciais os que serão postergados.
ES-rup-análise-2003
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
ES-rup-análise-2003
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.
ES-rup-análise-2003
Workflow
resultado:descrição detalhada de um particular use case: em texto e diagramas.
ES-rup-análise-2003
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?
ES-rup-análise-2003
Workflow
e) estruturar o modelo de use case: pode sernecessário explicitar relações include/extend.
ES-rup-análise-2003
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á
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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
ES-rup-análise-2003
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
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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).
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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
ES-rup-análise-2003
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.
ES-rup-análise-2003
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).
ES-rup-análise-2003
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.
ES-rup-análise-2003
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;
ES-rup-análise-2003
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.
ES-rup-análise-2003
Workflow
as classes de análise dentro do mesmo pacotede serviço contribuirão para o mesmo serviço. Pacote serviço
ES-rup-análise-2003
Workflow
A direção de dependência = direção denavegabilidade. Os pacotes são fracamente acoplados efortemente coesos
ES-rup-análise-2003
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.
ES-rup-análise-2003
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)
ES-rup-análise-2003
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.
ES-rup-análise-2003
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
ES-rup-análise-2003
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”.
ES-rup-análise-2003
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
ES-rup-análise-2003
Workflow
c3) capturar os requisitos especiais da classeno use case realization-análise.
ES-rup-análise-2003
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.
ES-rup-análise-2003
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.
Top Related