curso-lpoo.blogspot.com

Um diagrama de sequência modela as interações entre o usuário registrado, o representante de serviço ao cliente e o site Web, com o passar do tempo. Você deve usar diagramas de seqüência quando quiser chamar a atenção para a sequência de eventos de um caso de uso, com o passar do tempo. A Figura 9.9 apresenta um diagrama de sequência para o caso de uso Senha Esquecida. Conforme você pode ver na ilustração, um diagrama de sequência representa os eventos entre cada ator e o sistema (o site Web). Cada participante do caso de uso é representado no início do diagrama como uma caixa ou como um desenho de pessoa (mas você pode chamar ambos de caixa). Uma linha tracejada, conhecida como linha da vida, sai de cada caixa. A linha da vida representa o tempo de vida da caixa durante o caso de uso. Assim, se um dos atores fosse embora durante o caso de uso, a linha terminaria na última seta que termina ou se origina no ator. Quando um ator deixa um caso de uso, você pode dizer que seu tempo de vida...

Os diagramas de caso de uso ajudam a modelar os relacionamentos entre casos de uso. Os diagramas de interação ajudam a capturar as interações entre os vários atores participantes do sistema. Vamos expandir os casos de uso que vimos anteriormente. Vamos adicionar um novo ator, o representante de serviço ao cliente. Frequentemente, um usuário registrado pode se esquecer de sua senha. O representante de serviço ao cliente está lá para ajudar o usuário a reaver o acesso à sua conta. Vamos criar um novo caso de uso, Senha Esquecida’ Um usuário registrado liga para o representante de serviço ao cliente e informa ao representante que perdeu sua senha. O representante de serviço ao cliente pega o nome completo do usuário e extrai as informações de conta do usuário. O representante de serviço ao cliente faz então várias perguntas ao usuário registrado, para estabelecer sua identidade. Após passar por várias interpelações, o representante de serviço ao cliente exclui a senha antiga e cria uma no...

Assim como a UML fornece uma maneira de documentar e transmitir projeto de classe, também existem maneiras formais de capturar seus casos de uso. De especial interesse são os diagramas de caso de uso, diagramas de interação e diagramas de atividade. Cada um ajuda a visualizar os vários casos de uso. Os diagramas de caso de uso modelam os relacionamentos entre casos de uso e os relacionamentos entre casos de uso e atores. Embora a descrição textual de um caso de uso possa ajudá-lo a entender um caso de uso isolado, um diagrama o ajuda a ver como os casos de uso se relacionam uns com os outros. A Figura 9.5 ilustra a notação UML para um caso de uso: uma elipse rotulada. Coloque um ator em um caso de uso juntos no mesmo diagrama e você terá um diagrama de caso de uso. A figura 9.6 é o diagrama de caso de uso "Pedido". Esse diagrama é muito simples; entretanto, examinando-o, você pode ver que o usuário registrado executa o caso de uso Pedido. Os diagramas podem ser um pouco mais ...

A breve lista de casos de uso só informa parte da história. Internamente, muito mais poderia estar ocorrendo dentro de um caso de uso. Pegue um pedido como exemplo. Um usuário não pode fazer um pedido em um passo. Em vez disso, ele deve usar uma sequência de passos para concluir um pedido com êxito (como fornecer um método de pagamento). A sequência de passos que um usuário usa para completar um caso de uso é conhecida como cenário. Um caso de uso é constituído de vários cenários. Novo Termo Um cenário é uma sequência ou fluxo de eventos entre o usuário e o sistema.  Como parte de sua análise de casos de uso, você deve especificar os cenários de cada caso de uso. Vamos desenvolver o caso de uso Pedido. Primeiro, comece descrevendo o caso de uso em um parágrafo: O usuário registrado prossegue com a totalização e pagamento, para adquirir os itens de seu carrinho de compras. Uma vez na página de totalização e pagamento, o usuário fornece informações de entrega. Uma vez fornecidas, o s...

Nessa aula vamos entender como é essencial evitar casos de uso redundantes. Uma forma de prevenir a redundância é identificar as  variantes  de um caso de uso. Ao encontrá-las, o ideal é consolidá-las em um único caso de uso. Novo Termo:  Uma variante de caso de uso é uma versão especializada de um caso de uso mais genérico. Considere os dois exemplos a seguir: • Usuários visitantes podem navegar pelo catálogo de produtos. • Usuários visitantes podem buscar um item específico. Neste exemplo, o segundo caso é simplesmente uma variante do primeiro, que é mais abrangente. A diferença entre eles está basicamente nos parâmetros da busca. A abordagem mais eficiente é ter um único caso de uso e documentar a variante posteriormente, nos modelos de caso de uso que serão construídos. Uma variante é análoga a uma instância de uma classe. Pense na classe  ContaBancaria . Um objeto  ContaBancaria  com um saldo de R$ 10.000 possui mais fundos que um com R$ 100, mas ambos...

Para definir seus casos de uso, você precisa fazer algumas perguntas. Comece com sua lista de atores conhecidos.  Você precisa perguntar o que cada ator faz com o sistema. No caso da loja da Web on-line, você tem usuários registrados e usuários convidados.  O que cada um desses atores faz? Os usuários convidados podem fazer o seguinte: 1. Navegar pelo catálogo de produtos.  2. Pesquisar o catálogo de produtos.  3. Procurar um item específico.  4. Pesquisar o site.  5. Adicionar itens em um carrinho de compras e especificar a quantidade.  6. Ver o preço dos itens selecionados.  7. Mudar a quantidade de itens em seu carrinho.  8. Ver a lista de produtos popular e nova.  9. Navegar pela lista de itens desejados de outros usuários.  10. Solicitar mais informações sobre produto. Os usuários registrados podem fazer o seguinte:  1. Tudo que o usuário convidado pode fazer.  2. Fazer uma compra.  3. Adicionar itens em sua list...

O primeiro passo na definição de seus casos de uso é definir os atores que usarão o sistema. Novo Termo: Um ator é tudo que interage com o sistema. Pode ser um usuário humano, outro sistema de computador ou um chimpanzé.  Você precisa pedir aos seus clientes para que descrevam os usuários do sistema. As perguntas podem incluir as seguintes: • Quem principalmente usará o sistema? • Existem outros sistemas que usarão o sistema? Por exemplo, existem quaisquer usuários que não são seres humanos? • O sistema se comunicará com qualquer outro sistema? Por exemplo, há um banco de dados já existente que você precise integrar? • O sistema responde ao estímulo gerado por alguém que não seja usuário? Por exemplo, o sistema precisa fazer algo em certo dia de cada mês? Um estímulo pode ser proveniente de fontes normalmente não consideradas ao se pensar do ponto de vista puramente do usuário. Considere uma loja da Web on-line. Uma loja on-line permite que usuários convidados naveguem pelo catálo...

Ao começar a analisar um problema, você primeiro precisa entender como seus usuários utilizarão ou interagirão com o sistema. Esses usos compreendem os requisitos do sistema e prescrevem o sistema que você cria. Atendendo os requisitos de seus usuários, você produz um sistema útil. Novo Termo Os requisitos são os recursos ou características que o sistema deve ter para resolver determinado problema. Novo Termo Um modo de descobrir esses usos é através de análise de casos de uso. Através da análise você definirá vários casos de uso. Um caso de uso descreve como um usuário vai interagir com o sistema. Novo Termo Análise de casos de uso é o processo de descoberta de casos de uso através da criação de cenários e histórias com usuários em potencial ou existentes de um sistema Novo Termo Um caso de uso descreve a interação entre o usuário do sistema e o sistema — como o usuário utilizará o sistema do seu próprio ponto de vista. A criação de casos de uso é um processo iterativo. Existem vá...

AOO (Análise Orientada a Objetos) é o processo usado para entender o problema que você está tentando resolver. Após completar a análise, você deverá entender os requisitos do problema, assim como o vocabulário do domínio do problema. Novo Termo: Análise orientada a objetos é um processo que usa uma estratégia orientada a objetos para ajudá-lo a entender o problema que está tentando resolver. No final da análise, você deverá entender o domínio do problema e seus requisitos em termos de classes e interações de objetos. Para projetar uma solução para um problema, você precisa entender como os usuários utilizarão o sistema. A resposta dessa pergunta são os requisitos do sistema. Os requisitos informam a você o que os usuários querem fazer com o sistema e quais tipos de respostas eles esperam receber. Novo Termo: Sistema é o termo da AOO para um conjunto de objetos que interagem. Você pode dizer que esses objetos constituem um sistema ou modelo do problema. Esses objetos são instâncias de...

Existem tantas maneiras de desenvolver software quanto existem desenvolvedores. Entretanto, uma equipe de desenvolvimento de software precisa de uma estratégia unificada para desenvolver software. Nada será feito, se cada desenvolvedor fizer sua própria atividade. As metodologias de software definem uma maneira comum de encarar o desenvolvimento de software. Uma metodologia frequentemente conterá uma linguagem de modelagem (como a UML) e um processo. Novo Termo Um processo de software mostra os vários estágios do desenvolvimento de software. Um exemplo familiar de processo de software é o processo de cascata Figura 9.1       O processo de cascata.  Conforme a Figura 9.1 ilustra, o processo de cascata é sequencial e unidirecional. O processo é constituído de quatro estágios distintos:  1. Análise de requisitos  2. Projeto  3. Implementação  4. Teste Quando segue o processo de cascata, você vai de um estágio para o próximo. Entretanto, uma vez ...

Imagine que você está construindo uma casa. Antes de começar a assentar os tijolos ou escolher a cor da tinta, é preciso entender muito bem como a casa será usada: quantos quartos são necessários, onde ficará a cozinha, como a luz do sol entra pela janela pela manhã. Na programação, acontece algo parecido. A Análise Orientada a Objetos (AOO) é justamente essa etapa de "planejamento da casa": é o processo de entender profundamente o problema que queremos resolver antes de começar a escrever qualquer código. Muitas vezes, na ansiedade de colocar a mão na massa, os desenvolvedores pulam essa etapa e partem diretamente para a programação. O resultado pode ser um software que até funciona, mas que não atende direito às necessidades reais dos usuários, como uma casa com a porta principal abrindo para a parede. A AOO existe para evitar isso. Ela nos força a fazer as perguntas certas, a conversar com as pessoas que usarão o sistema e a compreender as regras do "mundo real" ...

Hoje vamos mergulhar um pouco mais no mundo das classes, construindo sobre o que já aprendemos anteriormente. Imagine que uma classe é como uma planta baixa para criar objetos - ela define como algo deve ser construído e como vai se comportar. Pense em uma classe como uma receita de bolo. A receita em si não é o bolo, mas nos diz exatamente quais ingredientes usar e como misturá-los para criar deliciosos bolos. Da mesma forma, uma classe descreve que atributos (ingredientes) e métodos (ações) nossos objetos terão. Um conceito importante que vamos explorar são os construtores. Eles são como os primeiros passos na preparação do nosso bolo. Temos dois tipos principais: os construtores que não recebem ingredientes especiais (chamados de "noargs") e aqueles que já começam com ingredientes específicos. Por exemplo, se pensarmos em uma classe "Café", um construtor sem argumentos poderia criar um café padrão, enquanto um construtor com argumentos poderia especificar se quer...