Processo de Desenvolvimento de Software Atividades-chave do Processo: Planejamento, levantamento de...

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.


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


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


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


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


• Prototipação


• Modelo em V


• Desenvolvimento em fases: incrementos e iterações


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


• Modelo Incremental:


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


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


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


• 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



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.

Processo de Desenvolvimento de Software Atividades-chave do Processo: Planejamento, levantamento de...

Documents

Transcript of Processo de Desenvolvimento de Software Atividades-chave do Processo: Planejamento, levantamento de...