Processo de Desenvolvimento de Software

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.

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.

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.

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.

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 a modelagem 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

Visão Geral da 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

Criação da UML UML 1.3 Aceitação do OMG, Nov 1997
feedback Aceitação do OMG, Nov 1997 Submissão Final ao OMG, Set 1997 UML 1.1 Primeira Submissão ao OMG, Jan 1997 UML 1.0 Parcerias UML UML 0.9 Web - Junho 1996 OOPSLA ´95 Unified Method 0.8 Outros Métodos Método Booch OMT OOSE

Sócios da UML Rational Software Corporation Hewlett-Packard I-Logix
IBM ICON Computing Intellicorp MCI Systemhouse Microsoft ObjecTime Oracle Platinum Technology Taskon Sterling Software Unisys

Contribuições à UML Harel Gamma, et al Meyer HP Fusion Booch Embley
Pré e Pós Condições Gamma, et al “Frameworks” e “patterns”, Máquinas de Estados HP Fusion Descrições de Operações e Numeração de Menssagens Booch Booch method Embley Classes Singleton e Visão de Alto Nível Rumbaugh OMT Jacobson OOSE Wirfs-Brock Responsabilidades Shlaer - Mellor Odell Classificação Ciclos de Vida de Objetos

Unified Modeling Language
UML significa Linguagem de Modelagem Unificada A UML combina o melhor do melhor de: Conceitos de Modelagem de Dados (Diagramas Entidade-Relacionamento) Modelagem de Negócios (Fluxo de trabalhos) Modelagem de Objetos Modelagem de Componentes A UML é a linguagem padrão para visualizar, especificar, construir e documentar os artefatos de um sistema intensamente baseado em software Pode 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 Apresentado da perspectiva de um patrocinador em particular
Um Diagrama é uma visão do modelo Apresentado da perspectiva de um patrocinador em particular Fornece 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ção Visão dinâmica: sequência, colaboração, máquinas de estados, atividades

Modelos, Visões e Diagramas
State Diagramas Classes Use Case Diagramas Casos de Usos State Diagramas Objetos Use Case Diagramas Sequência Scenario Diagramas Colaboração State Diagramas Componentes Modelos Scenario Diagramas Máquinas de Estados Component Diagramas Distribuição Diagramas Atividades

Modelos, Visões, Diagramas
Visão estrutural Visão de implementação Objetos Componentes Classes Visão do usuário Caso de Uso Iteração Sequência Colaboração Distribuição Estado Atividade Visão de ambiente Visão comportamental

Usuários dos Sistemas Visão Lógica Visão de Implementação
Programadores Gerenciamento de Software Usuário FInal Funcionalidade Visão de Casos de Uso Desempenho Escalabilidade Integradores Engenheiros Visão de Instalação/ Distribuição Visão de Processo Topologia de Sistema Instalação Comunicação Conceitual Físico

Arquitetura e a UML Componentes Classes, interfaces, colaborações
Visão de Projeto Visão de Implementação Casos de Uso Classes ativas Casos de Uso Pacotes Visão de Processo Visão de Distribuição

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 sistema Visão Funcional

Diagrama de Caso de uso

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 objeto Mostra 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 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 atividade Mostra 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 estados mostra 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

Diagrama de componentes
O 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

Diagrama de distribuição
O 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

Use case – Casos 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.

Relacionamentos entre os elementos anteriores.
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.

Atores “externo”: atores não fazem parte do sistema.
Elemento 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 Pessoa Sistema Cobrança Secretaria Professor Funcionario

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 Uso Um 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 necessidades Secretaria – Cadastrar notas Professor - Solicitar compra de livro Aluno - Fazer exercício da aula Sistema Cobrança - Solicitar informações sobre pagamento Fazer exercício da aula Cadastrar notas

Identificação de casos de uso
A 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ários Quais 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.

1. Incluir Caso de Uso “Login”.
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.

6. O sistema apresenta o endereço de envio,
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 conceitual O 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 colaboradores
Identificaçã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 Classe limite Classe controle e Classe entidade
Foi proposta por Ivar Jacobson Fornece 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 MVC
Separar: 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$ 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ática Histó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)

Exercicio A 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

Trabalho Informatização de uma loja comercial (supermercado, livraria, restaurante, loja de departamentos, etc.). A loja pode ser dividida em pelo menos 3 setores: Venda, Estoque e Recurso Humano. Escolha e descreva o tipo de loja a ser informatizada. Modelar um dos setores da loja, especificando diagramas de caso de uso, classes e de seqüência. 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

Apresentações semelhantes

Apresentação em tema: "Processo de Desenvolvimento de Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Processo de Desenvolvimento de Software

Apresentações semelhantes

Apresentação em tema: "Processo de Desenvolvimento de Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback