processo de desenvolvimento de software atividades-chave do processo: planejamento, levantamento de...
TRANSCRIPT
Processo de Desenvolvimento de Software
• Atividades-chave do Processo:• Planejamento, levantamento de requisitos,
análise, projeto, implementação e testes;• Escolha de um modelo de ciclo de vida;• Detalhamento das macro-atividades;• Escolha de métodos e técnicas para a sua
realização;• Definição de recursos e artefatos
necessários.• Um processo deve ser adequado ao domínio da
aplicação e ao projeto específico. Deve ser considerado a tecnologia, a organização e o grupo de desenvolvimento.
Processo de Desenvolvimento de Software
• Modelo de ciclo de vida é o ponto de partida para o PDS.
• São atividades que devem ser executadas durante um projeto, sendo associadas, a cada atividade, técnicas, ferramentas, critérios de qualidade, etc. Também atividades gerenciais são definidas, como gerência de configuração e controle de qualidade.
Processo de Desenvolvimento de Software
• Ciclo de Vida:• Planejamento – fornece uma estrutura que possibilite ao gerente
fazer estimativas de recursos, custos e prazos. Deve ser atualizada ao final de cada fase (requisitos, análise, projeto, implementação e teste);
• Levantamento de Requisitos – escopo deve ser refinado e requisitos identificados;
• Análise – os requisitos devem ser avaliados, documentados e modelados, descrevendo o que o software deve fazer e não como;
• Projeto – incorpora os requisitos tecnológicos aos requisitos essenciais do sistema, modelados na análise. Requer a definição da plataforma de desenvolvimento e envolve o projeto de arquitetura do sistema e projeto detalhado. A arquitetura descreve a estrutura de nível mais alta da aplicação e identifica os principais componentes. O projeto detalha os componentes identificados em níveis refinados sucessivamente até que possam ser codificados e testados.
Processo de Desenvolvimento de Software
• Ciclo de Vida:• Implementação - fase de codificação usando uma linguagem
escolhida;• Testes - inclui testes de unidade, de integração e de sistemas.
Cada unidade deve ser testada, documentando os resultados e integrada com as outras até se obter o sistema, que deve ser testado integralmente;
• Implantação - consiste de treinar usuários, configurar o ambiente e converter bases de dados. Estabelece a satisfação dos requisitos realizando testes de aceitação;
• Operação – o software é utilizado no ambiente de produção;• Manutenção – para atender novos requisitos, correções,
melhorias em geral. Pode requerer a definição de um novo processo. Modelo de Ciclo de Vida estrutura as atividades do projeto em fases e define o relacionamento entre elas. É dependente das características do projeto e podem ser Seqüencial Linear, Incremental e Evolutivos.
Processo inclui:• Recursos; está sujeito a um conjunto de restrições
(como um cronograma) Produtos intermediários e finais
• Subprocessos, com hierarquia ou organizados de algum modo
• Critérios de entrada e saída para cada atividade• Seqüência de atividades, de modo que a ordem de
execução de uma para outra seja clara• Conjunto de diretrizes que explicam os objetivos de
cada atividade• Restrições e controles para cada atividade, recurso
ou produto
Razões para modelar um processo
• Formar um entendimento comum• Encontrar inconsistências, redundâncias e omissões• Encontrar e avaliar atividades propostas mais
adequadas aos objetivos• Fazer um processo geral para uma situação particular
na qual ele será utilizado
Exemplos de modelos de processo
• Modelo cascata abordagem sequencial sistemática onde as fases são executadas sequencialmente.
Processo de Desenvolvimento de Software
• Críticas ao modelo sequencial linear:• Projeto reais muitas vezes não seguem o fluxo
sequencial;• É difícil se colocar todos os requisitos
explicitamente.• Versão operacional estará presente só no final do
projeto;• A natureza linear leva a situações onde membros
da equipe precisam aguardar que outros membros completem tarefas dependentes.
• Para sistemas pequenos e bem-definidos é aconselhado a sua utilização por ser mais fácil de ser gerenciado.
Processo de Desenvolvimento de Software
Exemplos de modelos de processo
• Prototipação
Exemplos de modelos de processo
• Modelo em V
Exemplos de modelos de processo
• Desenvolvimento em fases: incrementos e iterações
Exemplos de modelos de processo
• Desenvolvimento em fases: incrementos e iterações
Exemplos de modelos de processo
• Modelo Incremental:• Fases de requisitos, análise e projeto da
arquitetura são realizadas para o software como um todo.
• As demais fases ( projeto detalhado, implementação e testes) são definidos para incrementos específicos, facilitando a distribuição de versões, onde as funcionalidades e capacidades são aumentadas.
• É aplicável em sistemas grandes, porém com o problema bem definido, com recursos limitados e quando se deseja apresentar resultados aos usuários.
Exemplos de modelos de processo
• Modelo Incremental:
Exemplos de modelos de processo
• Modelos Evolutivo: aplicado para desenvolvimento de softwares que evoluam ao longo do tempo, onde requisitos do negócio e produto mudam no período de desenvolvimento, seja por pressões do negócio, competitividade, etc.
• Modelos evolutivos aplicam sequências lineares de modo escalonado, cada seqüências produz um incremento que é colocado em uso. Durante o uso novos requisitos são levantados dando início a um novo ciclo.
Exemplos de modelos de processo
• Modelo evolutivo espiral: descreve como um produto se desenvolve para formar novas versões e como versões podem ser incrementalmente desenvolvidas.
Processo de Desenvolvimento de Software• Modelo evolutivo espiral:no desenvolvimento OO a
equipe de desenvolvimento está envolvida na descoberta, documentação, prototipação e desenvolvimento de objetos em todas as fases (requisito, análise, projeto, implementação), apresentando características desejáveis ao processo e que proporcionam o uso deste modelo: • Desenvolvimento incremental e evolutivo – desejável para
que um produto seja desenvolvido em etapas e por equipes distintas;
• Reusabilidade - possibilitando reaproveitar parcelas de código, projetos ou especificações de requisitos;
• Possibilidade de incorporar pequenas diferenças a elementos do sistema, mantendo a coesão do sistema;
• Modularidade – conceito de classes, incorporando dados e operações, proporcionando modularização efetiva e encapsulamento.
Processo de Desenvolvimento de Software• Modelo evolutivo Básico:pressupõe que o
desenvolvimento ocorre em ciclos, onde ao fim de cada ciclo uma versão é colocada em uso. No uso, novos requisitos são levantados, dando início a um novo ciclo. Útil para pequenas equipes e para incrementos planejados para gerenciar riscos técnicos.
Processo de Desenvolvimento de Software• Modelo evolutivo Rational: Modelo desenvolvido,
integrado com ferramentas para desenvolvimento de sistemas complexos e orientados a objetos. São definidas fases: • Concepção: estabelecido o escopo do projeto e
suas fronteiras, discriminando os casos de uso do sistema. Estima-se os custos, prazos e prover estimativas detalhadas para a fase de elaboração;
• Elaboração: analisa refinadamente o domínio, estabelece uma arquitetura sólida, desenvolve um plano de projeto para o sistema e elimina-se os elementos de projeto que oferecem maior risco.
Processo de Desenvolvimento de Software• Elaboração: Esta fase deve assegurar que
os requisitos, a arquitetura e os planos estão estáveis e que os riscos estão sob controle de modo a prever com precisão os custos e prazos para a conclusão do desenvolvimento;
• Construção: desenvolvimento de maneira interativa e incremental;
• Transição: disponibilização do software aos usuários de forma que novas versões sejam elaboradas para permitir ajustes, correções etc.
Processo de Desenvolvimento de Software
• Em cada fase um conjunto de iterações, envolvendo planejamento, requisitos, análise, projeto, implementação e testes, é realizado. De uma iteração para outra e de uma fase para a seguinte, a ênfase sobre as atividades varia.
Processo de Desenvolvimento de Software
• O Conjunto de fases em si pode ser iterativo.
Processo de Desenvolvimento de Software
• O Conjunto de fases em si pode ser iterativo.
Ferramentas e técnicas para amodelagem do processo
• Exemplo:• Atividade• Seqüência• modelo de processo• Recursos• Controle• Política• Organização
Modelo dinâmico de processo
• Elucida o processo, de modo que possamos ver como os produtos intermediários e final são transformados
• Simula alternativas e faz mudanças para melhorar o processo
Propriedades desejáveis das ferramentas e técnicas para
modelagem de processos
• Facilitar o entendimento humano e a comunicação
• Apoiar a melhoria do processo • Apoiar o gerenciamento do processo • Fornecer orientação automatizada para a
utilização do processo • Apoiar a execução automatizada do
processo
O que é UML
• A UML é uma linguagem para:• Visualizar• Especificar• Construir• Documentar
• Os artefatos de um sistema intensivamente baseado em software• Elementos de modelagem• Relacionamentos• Mecanismos de extensibilidade• Diagramas
Visão Geral da UML
Criação da UML
Método Booch OMT
Unified Method 0.8OOPSLA ´95
OOSEOutros Métodos
UML 0.9Web - Junho 1996
feedback
Submissão Final ao OMG, Set 1997Primeira Submissão ao OMG, Jan 1997
UML 1.1Aceitação do OMG, Nov 1997
UML 1.3
UML 1.0Parcerias UML
Sócios da UML
Rational Software CorporationHewlett-PackardI-LogixIBMICON ComputingIntellicorpMCI SystemhouseMicrosoftObjecTimeOraclePlatinum TechnologyTaskonSterling SoftwareUnisys
Meyer
Pré e Pós Condições
Harel
Máquinas de EstadosGamma, et al
“Frameworks” e “patterns”,
HP Fusion
Descrições de Operações eNumeração de Menssagens
Embley
Classes Singleton eVisão de Alto Nível
Wirfs-Brock
Responsabilidades
Odell
Classificação
Shlaer - MellorCiclos de Vida de Objetos
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE
Contribuições à UML
Unified Modeling Language
UML significa Linguagem de Modelagem UnificadaA UML combina o melhor do melhor de:
Conceitos de Modelagem de Dados (Diagramas Entidade-Relacionamento)Modelagem de Negócios (Fluxo de trabalhos)Modelagem de ObjetosModelagem de Componentes
A UML é a linguagem padrão para visualizar, especificar, construir e documentar os artefatos de um sistema intensamente baseado em softwarePode ser usada com todos os processos, durante todo o ciclo de desenvolvimento, e com diferentes tecnologias de implementação
Existem Diversas Metodologias OO no Mercado
UML é uma notação padrão, e não pretende padronizar o processo intrínseco a cada método. Métodos diferentes podem utilizar a mesma linguagem para modelagem.
UML é a Linguagem, o método é a frase.Vários metodologistas seguiram de perto este trabalho e anunciaram o suporte a esta notação, como Steve Mellor, Bertrand Meyer, Rebeca Wirfs, James Martin, e outros.Metodologias mais
Diagramas
Um Diagrama é uma visão do modeloApresentado da perspectiva de um patrocinador em particularFornece uma representação parcial do sistemaÉ semanticamente consistente com outras visões
Na UML, há nove Diagramas padrão:Visão estática: casos de usos, classes, objetos, componentes, distribuiçãoVisão dinâmica: sequência, colaboração, máquinas de estados, atividades
Modelos, Visões e Diagramas
Use CaseDiagramasUse Case
DiagramasCasos de Usos
ScenarioDiagramasScenario
DiagramasDiagramasColaboração
StateDiagramasState
DiagramasDiagramas Componentes
ComponentDiagramasComponent
DiagramasDiagramasDistribuição
StateDiagramasState
DiagramasDiagramasObjetos
ScenarioDiagramasScenario
DiagramasMáquinas de Estados
Use CaseDiagramasUse Case
DiagramasDiagramasSequência
StateDiagramasState
DiagramasDiagramasClasses
DiagramasAtividades
Modelos
Modelos, Visões, Diagramas
Caso de Uso
Componentes
Distribuição
Objetos
Estado
Classes
Atividade
Colaboração
Sequência
Iteração
Visão do usuário
Visão comportamental Visão de ambiente
Visão estrutural Visão de implementação
Usuários dos Sistemas
Visão Lógica
Usuário FInal Funcionalidade
Visão de Implementação
ProgramadoresGerenciamento de
Software
Visão de ProcessoDesempenhoEscalabilidade
IntegradoresVisão de Instalação/ Distribuição Topologia de Sistema
InstalaçãoComunicação
Engenheiros
Conceitual Físico
Visão de Casos de Uso
Arquitetura e a UML
Visão de Projeto Visão de Implementação
Visão de Processo
Componentes Classes, interfaces,colaborações
Classes ativas
Visão de Distribuição
Pacotes
Casos de UsoCasos de Uso
Dicas
Nem todos os Diagramas necessitam ser utilizados;Evite Diagramas estranhos ou redundantes;Utilize apenas informações coerentes para os propósitos da Modelagem;
Evite a poluição nos Diagramas;Não simplifique demais os Diagramas;Faça um balanceamento dos Diagramas Comportamentais, Estruturais e Funcionais do Sistema;Utilize nomes significativos nos Diagramas ;Use Ferramentas CASE para desenhar os Diagramas.
Diagrama de Caso de Uso
Mostra um conjunto de Casos de Uso e Atores e seus Relacionamentos. Descreve as funcionalidades do Sistema;Representa quem faz o que (interage) com o sistema, sem considerar o comportamento interno do sistemaVisão Funcional
Diagrama de Caso de usoSubsistema Compras
AgendarPagamento de
Duplicata
RegistrarPagamentoDuplicata
ElaborarPedido deCompra
RegistrarRecebimento
Produtos
AcompanharPedido deCompra
<<actor>><Almoxarife>
<<actor>><Funcionário Setor Financeiro>
<<actor>><Funcionário Setor de Compras>
AcompanharDuplicatas a
Pagar
AcompanharEstoque
Diagrama de classe
Mostra um conjunto de Classes, Interfaces e Colaborações com seus respectivos relacionamentos. É o Diagrama mais comum na modelagem de Sistema Orientados a Objeto;Visões estrutural e estática
Diagrama de classe
Diagrama de objetoMostra um conjunto de Objetos e seus relacionamentos. A sua utilização ilustra as estruturas de dados e é uma fotografia (snapshot) das Instâncias das Classes (e outros elementos) obtidos nos Diagramas de Classe.Visões estrutural e estática
Diagrama de objeto
Diagrama de objeto
PedidoItemPedidoProduto
nome = "Caderno M"descrição = "Caderno em espiral tamanho médio"preçoUnitário = 4,50desconto = 15
produto20 : Produto
nome = "Caneta ESF"descrição = "Caneta esferográfica 5mm"preçoUnitário = 1,20desconto = 2
produto12 : Produto
nome = "Esquadro"descrição = "Esquadro de acrílico 20 cm"preçoUnitário = 2,35desconto = 10
produto07 : Produto
quantidade = 20item2 : ItemPedido
quantidade = 6item1 : ItemPedido
quantidade = 1item3 : ItemPedido
data = 13/ 09/ 2002hora = 10:00am
Pedido1 : Pedido
Diagrama de seqüência É um diagrama de interação que enfatiza o ordenamento temporal das mensagens. Mostra um conjunto de objetos e as mensagens enviadas e recebidas por esses objetos;Visões dinâmica e comportamental
Diagrama de seqüência
Diagrama de atividadeMostra o fluxo de atividade para atividade dentro de um sistema. Mostra um conjunto de atividades, os fluxos de sequenciamento ou divisão de atividade para atividade e os objetos que atuam ou são afetados.Visões dinâmica e comportamental
Diagrama de atividade
Diagrama de estadosmostra uma máquina de estados, consistindo de estados, transições, eventos e atividades. É um diagrama importante na modelagem do comportamento de interfaces, classes e colaborações e enfatizam o comportamento ordenado a eventos de objeto; Visões dinâmica e comportamental
Diagrama de estado
Diagrama de colaboração é um diagrama de interação que enfatiza a organização estrutural dos objetos que enviam e recebem mensagens. Mostra um conjunto de objetos, os links entre esses objetos e as mensagens enviadas e recebidas por esses objetos.Visões dinâmica e comportamental
Diagrama de colaboração
FormCadCliente:CadastrarCliente
FormPesqVend:PesquisarVenda
FormRegVenda:RegistrarVenda
Item:ItemDeVenda
Ven:<Vendedor>
Ven:Vendedor
Prod:Produto
Venda:Venda
<<actor>><Vendedor>
Cli:Cliente
: Confirmar: Sair
: Abrir: Cancelar
: CancelarExclusao: Confirmar
: ConfirmarExclusao: ExcluirVenda: IndicarCliente: IndicarProduto
: IndicarVendedor: NovoCliente
: NovoItemDeVenda: Pesquisar
: Sair: SelecionarItemDeVenda
: ObterTodos
: ObterTodos
: Excluir: ObterPelaNotaFiscal
: PrepararParaAlteracao: PrepararParaInclusao
: Salvar
: AcionarRelacionamento: Excluir
: PrepararParaAlteracao: PrepararParaInclusao
: Salvar
: AbrirParaInclusao
: Abrir
: Cancelar: Confirmar
: AtualizarEstoque: ObterTodos
Diagrama de componentesO diagrama de componente descreve os componentes de software e suas dependências entre si, representando a estrutura do código gerado. Os componentes são a implementação na arquitetura física dos conceitos e da funcionalidade definidos na arquitetura lógica (classes, objetos e seus relacionamentos). Eles são tipicamente os arquivos implementados no ambiente de desenvolvimento.
Diagrama de componentes
UCliente.pas
UCadastrarCliente.pas
USistemaComercial.pas UServidorDeObjetos.pas
SisCom.dpr
Persistencia.pas
TipoSQL.pas
Diagrama de distribuiçãoO diagrama de distribuição mostra a arquitetura física do hardware e do software no sistema. Pode mostrar os atuais computadores e periféricos, juntamente com as conexões que eles estabelecem entre si e pode mostrar também os tipos de conexões entre esses computadores e periféricos. Especifica-se também os componentes executáveis e objetos que são alocados para mostrar quais unidades de software são executados e em que destes computadores são executados.
Diagrama de distribuição
Estação Cliente Estação Servidora
ClassesDeNegocio.dpl
SisCom.exe
Interbase Server
Isc4.gdb
Use ca
se – C
asos
de uso
Casos de Uso
Técnica de modelagem idealizada por Ivar Jacobson, na década de 1970.
Posteriormente, foi adicionada à UML.
O modelo de casos de uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com o mesmo.
O modelo de casos de uso modela os requisitos funcionais do sistema.
O diagrama da UML utilizado na modelagem de casos de uso é o diagrama de casos de uso.
Casos de Uso
Este modelo direciona diversas das tarefas posteriores do ciclo de vida do sistema de software.Além disso, o modelo de casos de uso força os desenvolvedores a moldar o sistema de acordo com o usuário.
Um caso de uso é a especificação de uma seqüência de interações entre um sistema e os agentes externos.
Define parte da funcionalidade de um sistema, sem revelar a estrutura e o comportamento internos deste sistema.
Um modelo de casos de uso típico é formado de vários casos de uso.
Componentes do modelo de casos de uso
O modelo de casos de uso de um sistema é composto de:
• Casos de uso• Atores
• Relacionamentos entre os elementos anteriores.
AtoresElemento externo que interage com o sistema.
“externo”: atores não fazem parte do sistema.“interage”: um ator troca informações com o sistema.
Um Ator é alguém ou alguma coisa que deve interagir com o sistema a ser desenvolvido
Funcionario
Secretaria
Professor
Sistema Cobrança
Pessoa
Identificando atores
Que órgãos empresas ou pessoas utilizarão o sistema?
Que outros sistemas irão se comunicar com o sistema a ser construído?
Alguém deve ser informado de alguma ocorrência no sistema?
Quem esta interessado em um certo requisito funcional do sistema?
Categorias de atores:
pessoas (Empregado, Cliente, Gerente, Almoxarife, Vendedor, etc);
organizações (Empresa Fornecedora, Agência de Impostos, Administradora de Cartões, etc);
outros sistemas (Sistema de Cobrança, Sistema de Estoque, etc).
equipamentos (Leitora de Código de Barras, Sensor, etc.)
Casos de UsoUm caso de uso é um padrão de comportamento que o sistema exibe
Cada caso de uso é uma sequência de transações relacionadas executadas por um ator e o sistema num diálogo
Atores são examinados para determinar suas necessidadesSecretaria – Cadastrar notasProfessor - Solicitar compra de livroAluno - Fazer exercício da aulaSistema Cobrança - Solicitar informações sobre pagamento
Cadastrar notas Fazer exercício da aula
Identificação de casos de usoA partir da lista (inicial) de atores, deve-se passar à identificação dos casos de uso.Nessa identificação, pode-se distinguir entre dois tipos de casos de uso
Primário: representa os objetivos dos atores. Secundário: aquele que não traz benefício direto
para os atores, mas que é necessário para que sistema funcione adequadamente.
Identificando Casos de uso primáriosQuais são as necessidades e objetivos de cada ator em relação ao sistema?
Que informações o sistema deve produzir?
O sistema deve realizar alguma ação que ocorre regularmente no tempo?
Para cada requisito funcional, existe um (ou mais) caso(s) de uso para atendê-lo?
Casos de uso secundários
Estes se encaixam nas seguintes categorias:Manutenção de cadastros. Manutenção de usuários.Manutenção de informações
provenientes de outros sistemas.
Importante: Um sistema de software não existe para cadastrar informações, nem tampouco para gerenciar os seus usuários.
O objetivo principal é produzir algo de valor para o ambiente no qual ele está implantado.
Diagrama de casos de uso
Os diagramas de casos de uso devem servir para dar suporte à parte escrita do modelo, fornecendo uma visão de alto nível.
Quanto mais fácil for a leitura do diagrama representando casos de uso, melhor.
Se o sistema sendo modelado não for tão complexo, pode ser criado um único diagrama.
Este diagrama permite dar uma visão global e de alto nível do sistema.
Diagrama de Casos de Uso
Realização do Caso de Uso Finalizar compra
O Caso de Uso Finalizar compra será realizado de acordo como o plano do projeto mostrado no diagrama de rastreabilidade baixo
O Analista de sistemas necessita especificar os detalhes do use case(fluxo de eventos) de Finalizar compra.
Especificação do Caso de Uso Finalizar compra
1. Incluir Caso de Uso “Login”.
2. O sistema examina o conteúdo do carrinho de compras e mostra a lista de todos os itens.
3. O Sistema calcula o subtotal, imposto, despesa de envio e valor total, e os mostra.
4. O cliente confirma para continuar o processo de checkout; o sistema pede ao cliente para entrar os detalhes de pagamento e o endereço de envio;
5. O cliente seleciona o método de pagamento no cartão de crédito e entra o tipo de cartão de crédito, numero do cartão, nome que consta no cartão e data de expiração.
Especificação do Caso de Uso Finalizar compra
6. O sistema apresenta o endereço de envio,
7. O sistema gera um requerimento da requisição do crédito e envia para serviço de autorização do cartão.
8. O serviço de autorização do cartão autoriza o pagamento; o sistema recebe a aprovação do pagamento por cartão responde para o sistema de autorização e indica o sucesso de autorização.
9. O sistema salva a ordem do cliente na base de dados e mostra o resumo da ordem e finaliza o use case.
Descobrindo Classes
Como encontrar um grupo das classes que realizam o comportamento especificado no fluxo de eventos do caso do uso
Uma das tarefas as mais difíceis na análise e no projeto orientados objeto.
De uma forma geral, a identificação de classes se divide em duas atividades.
Primeiramente, classes candidatas são identificadas.Depois disso, são aplicados alguns princípios para eliminar classes candidatas desnecessárias.
Modelo conceitualO modelo conceitual é um diagrama de classes para capturar o conhecimento do domínio.
Baseado no entendimento e na experiência dos arquitetos podemos identificar vários conceitos do domínio de seus relacionamentos.
Fornece um bom ponto de inicio para analise de use cases individuais
Modelo conceitual
Responsabilidades e colaboradoresIdentificação de classes a partir de seus comportamentos externos relevantes para o sistema
Responsabilidades
Uma responsabilidade é uma obrigação que um objeto tem para com o sistema no qual ele está inserido.
Através delas, um objeto colabora (ajuda) com outros para que os objetivos do sistema sejam alcançados.
Na prática, uma responsabilidade é alguma coisa que um objeto conhece ou faz. (sozinho ou não).
Um objeto Cliente conhece seu nome, seu endereço, seu telefone, etc.
Um objeto Pedido conhece sua data de realização e sabe fazer o cálculo do seu total.
Se um objeto tem uma responsabilidade com a qual não pode cumprir sozinho, ele deve requisitar colaborações de outros objetos.
Colaboradores Um exemplo: quando a impressão de uma fatura é requisitada em um sistema de vendas, vários objetos precisam colaborar:
um objeto Pedido pode ter a responsabilidade de fornecer o seu valor total um objeto Cliente fornece seu nome
cada ItemPedido informa a quantidade correspondente e o valor de seu subtotal
os objetos Produto também colaboraram fornecendo seu nome e preço unitário.
Análise de robustez
Foi proposta por Ivar JacobsonFornece uma facilidade de entender e uma abordagem consistente para identificar as classes de analise do modelo de Use Case. Há três tipos de classes da análise:
Classe limite Classe controle e Classe entidade
Na notação de UML, são classes estereotipo com seus próprios ícones específicos, Também é possível usar a notação de classes com o rótulo estereotipo.Sua origem vem do padrão MVC
Arquitetura MVC
View
Controller
Model
Inclui Informações
Altera o modelo
Disparo de evento ao ocorrer alteração no modelo
Objetivo Arquitetura MVCSeparar:
dados ou lógica de negócios (Model); da interface do usuário (View) e;do fluxo da aplicação (Control) O modelo do negócio não deve conhecer nada sobre as telas que
exibem seu estado.
Regras de Negócios• São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização.
•Descrevem a maneira pela qual a organização funciona.
•A descrição do modelo de regras do negócio pode ser feita utilizando-se texto informal, ou alguma forma de estruturação.
•Regras do negócio normalmente têm influência sobre um ou mais casos de uso.
•Os identificadores das regras do negócio devem ser adicionados à descrição do caso de uso.
•Utilizando a seção “regras do negócio” da descrição do caso de uso.
Regras do negócio
Alguns exemplos de regras do negócio:O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega.
Um professor só pode estar lecionando disciplinas para as quais esteja habilitado.
Um cliente do banco não pode retirar mais de R$ 1.000 por dia de sua conta.
Os pedidos para um cliente não especial devem ser pagos antecipadamente.
Regras do negócio Possível formato para documentação de uma regra de negócio.
Nome Quantidade de inscrições possíveis (RN01)Descrição Um aluno não pode ser inscrever em mais de seis
disciplinas por semestre letivo.Fonte Coordenador da escola de informáticaHistórico Data de identificação: 12/07/2002
Análise de robustez
Classe limite Classe controle Classe entidade
Classe Limite
Representa as relações entre os atores (mundo externo) e o sistema.
Dependendo do tipo do ator, uma classe do limite é requerida para representar interfaces com:◦ o usuário (atores humanos), ◦ sistemas externos (sistema legado) ou ◦ um dispositivo externo atrelado ao sistema..
Esses objetos traduzem os eventos gerados por um ator em eventos relevantes ao sistema.
Também são responsáveis por apresentar os resultados de uma interação dos objetos em algo inteligível pelo ator.
É altamente dependente do ambiente Normalmente têm as seguintes responsabilidades de:
Notificar aos objetos de controle de eventos gerados externamente ao sistema.
Notificar aos atores do resultado de interações entre os objetos internos.
Classe Controle
•Representa a lógica do caso do uso e coordena as outras classes. •Implementam as ações aplicadas as demais classes.•Separa as classes de interface das classes da lógica do negócio.•Responsáveis por controlar a lógica de execução correspondente a um caso de uso.•Decidem o que o sistema deve fazer quando um evento externo relevante ocorre.
• Eles realizam o controle do processamento• Agem como gerentes (coordenadores, controladores) dos outros• objetos para a realização de um ou mais caso de uso.
•Traduzem eventos externos em operações que devem ser realizadas pelos demais objetos. Podem também ter o objetivo de manter o estado da realização do caso de uso. As instancias da classe controle, normalmente, têm vida curta, existem somente durante a realização de um caso de uso.
Classe Entidade
São classes básicas do domínio do problema.
Gerencia as informações que o sistema necessita para fornecer a funcionalidade requerida.
Geralmente as classes da entidade são específicas do negócio.
São informações especializadas e encapsulam o conhecimento do negócio.
Na maioria das vezes, classes da entidade são as classes persistentes que podem ser usadas para gerar diretamente o esquema da base de dados.
É um repositório para alguma informação manipulada pelo sistema.
Classe Entidade
Atores não têm acesso direto a estes objetos. Objetos de entidade normalmente participam de vários casos de uso e têm um ciclo de vida longo.Responsabilidades de fazer típicas de objetos de entidade:
Informar valores de seus atributos a objetos de controle.Realizar cálculos simples, normalmente com a colaboração de objetos de entidade associados através de agregações.No caso de possuir subclasses (agregação por composição), criar e destruir objetos parte.
Diagrama de seqüência
Diagrama de Classe (realização Finalizar Compra)
ExercicioA empresa de aviação VAF resolveu criar um Sistema de
Transporte Aéreo em Tempo Real para automatizar o planejamento de vôos e transporte de passageiros.
O sistema deve ser capaz de permitir que o passageiro verifique a existência de vôos de um local para outro, e a existência de poltronas vagas.
• Modele através de diagrama de caso de uso, e faça a realização de um use case, identificando as classes Entidade, Controle e Limite
Trabalho1. Informatização de uma loja comercial
(supermercado, livraria, restaurante, loja de departamentos, etc.).
2. A loja pode ser dividida em pelo menos 3 setores: Venda, Estoque e Recurso Humano.
3. Escolha e descreva o tipo de loja a ser informatizada.
4. Modelar um dos setores da loja, especificando diagramas de caso de uso, classes e de seqüência.
5. Utilize para isto os princípios de realização de Casos de uso e analise de robustez, segundo o padrão MVC.