OBJETIVO: Desenvolver um mini-projeto seguindo os 12 exercícios listados abaixo. 1. Desenvolver uma declaração de problema. 2. Desenvolva um documento SRS padrão IEEE. Desenvolva também gerenciamento de risco e plano de projeto (gráfico de Gantt). 3. Identifique Casos de Uso e desenvolva o modelo de Caso de Uso. 4. Identifique as atividades comerciais e desenvolva um diagrama de atividade UML. 5. Identidade as classes conceituais e desenvolver um modelo de domínio com diagrama de classe UML. 6. Usando os cenários identificados, encontre a interação entre objetos e os represente usando os diagramas de interação UML. 7. Desenhe o diagrama do diagrama de estado. 8. Identifique a Interface do Usuário, Objetos do Domínio e Serviços Técnicos. Desenhe o diagrama de arquitetura lógica em camadas parcial com a notação do diagrama de pacote UML. 9. Implementar a camada de serviços técnicos. 10. Implementar a camada de objetos do Domínio. 11. Implementar a camada de interface do usuário. 12. Desenhe diagramas de componentes e implantação. 18 Domínios sugeridos para Mini-projeto. 1. Sistema de automação de passaportes. 2. Banco de livros 3. Registro de exames 4. Sistema de manutenção de estoque. 5. Sistema de reserva de curso on-line 6. E-ticketing 7. Sistema de gerenciamento de pessoal de software 8. Processamento de cartão de crédito 9. Sistema de gerenciamento de e-book 10. Sistema de recrutamento 11. Sistema de comércio exterior 12. Sistema de gerenciamento de conferências 13. Sistema de Gerenciamento BPO Clique no Abaixo links para baixar o manual Posts relacionados: CS2357 2 comentários: você pode dar a codificação em java ou básico visual para o sistema de manutenção de estoque. Você pode dar o documento ou a codificação no sistema incorporado de segurança c para o sistema de segurança do atm. Publique um Comentário MANUAL LAB MANUAL Pesquisar este Blog MANUAL LAB Manual Arquivo do blogUtilizar Diagramas de casos Diagramas de casos de uso Além de introduzir casos de uso como elementos principais no desenvolvimento de software, Jacobson (1994) também introduziu Um diagrama para visualizar casos de uso. O diagrama de caso de uso também faz parte da UML. Muitas pessoas acham esse tipo de diagrama útil. No entanto, devo enfatizar que você não precisa desenhar um diagrama para usar casos de uso. Um dos projetos mais eficazes que eu conheço que usaram casos de uso envolveu manter cada um em um cartão de índice e classificar os cartões em pilhas para mostrar o que precisava construir em cada iteração. A Figura 3-2 mostra alguns dos casos de uso para um sistema de comércio financeiro. Figura 3-2. Diagrama de casos de uso Um ator é um papel que um usuário desempenha em relação ao sistema. Existem quatro atores na Figura 3-2: Gerente de Negociação, Comerciante, Vendedor e Sistema de Contabilidade. (Sim, eu sei que seria melhor usar o papel da palavra, mas, aparentemente, houve uma má tradução do sueco.) Provavelmente haverá muitos comerciantes na organização dada, mas, no que diz respeito ao sistema, todos eles jogam O mesmo papel. Um usuário também pode desempenhar mais de uma função. Por exemplo, um comerciante sênior pode desempenhar o papel de Gerente de Negociação e também ser um comerciante regular, um Comerciante também pode ser um Vendedor. Ao lidar com atores, é importante pensar sobre papéis e não sobre pessoas ou cargos. Os atores executam casos de uso. Um único ator pode realizar muitos casos de uso ao contrário, um caso de uso pode ter vários atores que o executam. Na prática, acho que os atores são mais úteis ao tentar encontrar os casos de uso. Diante de um sistema grande, muitas vezes pode ser difícil encontrar uma lista de casos de uso. É mais fácil, nessas situações, chegar à lista de atores primeiro, e depois tentar resolver os casos de uso para cada ator. Os atores não precisam ser humanos, mesmo que os atores sejam representados como figuras de vara dentro de um diagrama de caso de uso. Um ator também pode ser um sistema externo que precisa de algumas informações do sistema atual. Na Figura 3-2, podemos ver a necessidade de atualizar as contas do Sistema de Contabilidade. Existem várias variações sobre o que as pessoas mostram como atores. Algumas pessoas mostram todo sistema externo ou ator humano no diagrama de caso de uso que outros preferem mostrar o iniciador do caso de uso. Prefiro mostrar ao ator que obtém valor do caso de uso, que algumas pessoas se referem como o principal ator. No entanto, eu não levo isso longe demais. Estou feliz em ver o sistema contábil obter valor, sem tentar descobrir o ator humano que obtém valor do sistema contábil que implicaria modelar o próprio sistema contábil. Dito isto, você sempre deve questionar os casos de uso com os atores do sistema, descobrir quais são os objetivos dos usuários reais e considerar formas alternativas de atingir esses objetivos. Quando estou trabalhando com atores e casos de uso, não me preocupo muito com o que os relacionamentos exatos estão entre eles. Na maioria das vezes, o que eu realmente aprendo são os casos de uso, os atores são apenas uma maneira de chegar lá. Enquanto eu tiver todos os casos de uso, não estou preocupado com os detalhes dos atores. Existem algumas situações em que pode valer a pena seguir os atores mais tarde. O sistema pode precisar de configuração para vários tipos de usuários. Neste caso, cada tipo de usuário é um ator, e os casos de uso mostram o que cada ator precisa fazer. O acompanhamento de quem quer casos de uso pode ajudá-lo a negociar prioridades entre vários atores. Alguns casos de uso não possuem links claros para atores específicos. Considere uma empresa de serviços públicos. Claramente, um dos casos de uso é Send Out Bill. Não é tão fácil identificar um ator associado, no entanto. Nenhuma função de usuário particular solicita uma conta. A conta é enviada ao cliente, mas o cliente não se oporia se não acontecesse. O melhor palpite de um ator aqui é o Departamento de cobrança, na medida em que obtém valor do caso de uso. Mas o faturamento geralmente não está envolvido na execução do caso de uso. Esteja ciente de que alguns casos de uso não aparecerão como resultado do processo de pensar sobre os casos de uso para cada ator. Se isso acontecer, não se preocupe demais. O importante é entender os casos de uso e os objetivos do usuário que eles satisfazem. Uma boa fonte para identificar casos de uso são eventos externos. Pense em todos os eventos do mundo exterior para os quais você deseja reagir. Um determinado evento pode causar uma reação do sistema que não envolve usuários, ou pode causar uma reação principalmente dos usuários. Identificar os eventos que você precisa reagir irá ajudá-lo a identificar os casos de uso. Relacionamentos de casos de uso Além dos links entre atores e casos de uso, você pode mostrar vários tipos de relações entre os casos de uso. O relacionamento de inclusão ocorre quando você tem um pedaço de comportamento que é semelhante em mais do que um caso de uso e você não deseja continuar copiando a descrição desse comportamento. Por exemplo, tanto Analyze Risk e Price Deal exigem que você valorize o negócio. Descrever a avaliação do negócio envolve um pedaço justo de escrita, e odeio copiar e colar. Então, tirei um caso de uso de Value Deal separado para esta situação e referi-lo a partir dos casos de uso originais. Você usa a generalização de casos de uso quando você possui um caso de uso que é semelhante a outro caso de uso, mas faz um pouco mais. Com efeito, isso nos dá outra maneira de capturar cenários alternativos. No nosso exemplo, o caso básico de uso é Capture Deal. Este é o caso em que tudo corre bem. As coisas podem prejudicar a captura suave de um acordo, no entanto. Um é quando um limite é excedido por exemplo, o valor máximo que a organização comercial estabeleceu para um determinado cliente. Aqui, não realizamos o comportamento usual associado ao caso de uso dado, realizamos uma alternativa. Poderíamos colocar essa variação dentro do caso de uso do Capture Deal como alternativa, como com o caso de uso Buy a Product que eu descrevi anteriormente. No entanto, podemos achar que esta alternativa é suficientemente diferente para merecer um caso de uso separado. Colocamos o caminho alternativo em um caso de uso especializado que se refere ao caso de uso básico. O caso de uso especializado pode substituir qualquer parte do caso de uso básico, embora ainda seja satisfatório o mesmo objetivo essencial do usuário. Um terceiro relacionamento, que não mostrei na Figura 3-2, é chamado de extensão. Essencialmente, isso é semelhante à generalização, mas com mais regras. Com esta construção, o caso de uso que se estende pode adicionar comportamento ao caso de uso básico, mas desta vez o caso de uso base deve declarar certos pontos de extensão e o caso de uso extensivo pode adicionar comportamento adicional somente nesses pontos de extensão. (Figura 3-3.) Figura 3-3. Estender o relacionamento Um caso de uso pode ter muitos pontos de extensão e um caso de uso prolongado pode estender um ou mais desses pontos de extensão. Você indica quais na linha entre os casos de uso no diagrama. A generalização e a extensão permitem dividir um caso de uso. Durante a elaboração, costumo dividir qualquer caso de uso que está ficando muito complicado. Eu dividi durante a fase de construção do projeto se eu achar que eu não posso construir todo o caso de uso em uma iteração. Quando eu dividir, eu gosto de fazer o caso normal primeiro e as variações mais tarde. Aplique as seguintes regras. Use incluir quando você está se repetindo em dois ou mais casos de uso separados e você deseja evitar a repetição. Use a generalização quando você descreve uma variação no comportamento normal e você deseja descrevê-la casualmente. Use estender quando você está descrevendo uma variação no comportamento normal e você deseja usar o formulário mais controlado, declarando seus pontos de extensão no seu caso de uso básico. Prepare os seguintes documentos para cada experiência e desenvolva o software usando a metodologia de engenharia de software. 1. Análise de Problemas e Planejamento de Projeto Estudo aprofundado do problema 8211 Identificar o escopo do projeto, Objetivos, infra-estrutura 2. Análise de requisitos de software Descreva os módulos de fases individuais do projeto, Identifique os resultados. 3. Modelagem de dados Use produtos de trabalho 8211 dicionário de dados, diagramas de casos de uso e diagramas de atividades, construa e teste diagramas de classes, diagramas de seqüência e adicione interface para diagramas de classe. 4. Desenvolvimento e depuração de software. 5. Teste de software Prepare o plano de teste, execute testes de validação, análise de cobertura, vazamentos de memória, desenvolva hierarquia de casos de teste, verificação do site e monitor do site. Lista de experimentos: sistema de registro do sistema de registro do sistema sistema de reserva de ingressos on-line Monitoramento remoto do computador Cadastro de estudantes sistema de análise Sistema especializado para prescrever os medicamentos para os sintomas fornecidos Sistema ATM Sistema de atribuição de plataforma para trens em uma estação ferroviária Manutenção de estoque Sistema de correio eletrônico. Case Tools: Rational Suite, Win runner, Empirix Idiomas: CCJDK 1.3, JSDK, INTERNET EXPLORER, UML Front End: VB, VC, Developer 2000
No comments:
Post a Comment