curso-lpoo.blogspot.com

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

Antes de colocarmos a mão na massa e começarmos a programar, precisamos preparar o nosso "ambiente de trabalho". Pense nisso como um pintor preparando sua tela e suas tintas, ou um chef organizando seus ingredientes e facas. Para criar programas em Java, a nossa "tinta" e o nosso "ingrediente" principal é o Kit de Desenvolvimento Java, também conhecido como JDK. Não se preocupe com os nomes técnicos. O JDK é simplesmente um pacote de ferramentas que instalamos no computador para que ele entenda e execute comandos escritos em Java. Para todos os exercícios e para o projeto final que faremos juntos, vamos usar a linguagem Java. A versão mínima que precisamos é a 1.2, mas, como sempre queremos o melhor e mais atualizado, é recomendável baixar a versão mais recente disponível. O local mais comum para conseguir o JDK é diretamente do site da Oracle (que herdou o projeto da Sun Microsystems). Você pode encontrá-lo facilmente fazendo uma busca na internet por ...

O encapsulamento é um dos conceitos mais importantes da programação orientada a objetos e pode ser entendido como a ideia de “esconder o que não é necessário e mostrar apenas o que importa”. Para os alunos que estão começando, pense em uma televisão: você não precisa saber como todos os circuitos funcionam por dentro para usá-la, basta apertar os botões do controle remoto. O funcionamento interno fica escondido (encapsulado), e você só tem acesso ao que realmente precisa. Esse conceito traz várias vantagens. A primeira delas é que ele nos ajuda a pensar nos problemas de maneira natural. Quando estamos modelando um programa, conseguimos separar responsabilidades e criar classes que representem as coisas do mundo real. Isso torna o raciocínio mais simples, porque podemos focar no problema em si e não nos detalhes técnicos da implementação. Outra vantagem é a confiabilidade. Quando cada parte do programa tem responsabilidades bem definidas e sua implementação fica escondida, fica mais f...