Análise orientada

Introdução

Este trabalho está falando sobre Diagramas de Sequência e Diagramas de Atividades, focando em definição de diagramas de sequência e seus componentes e em definição de diagrama de atividades e seus componentes. O mesmo também contém modelos de cada diagrama, feito através do AstahCommunity.

Agradecimentos

Agradeço primeiramente, a Deus por ter derramado suas bênçãos sobre mim, dando-me forças e sabedorias para concluir mais esse trabalho, com muita dedicação. Ao meu Professor e a Anhanguera educacional por, dedicar-se a ensinar a todos com muita força de vontade, paciência e sabedoria. Sabendo que tudo isso vai propor grandes oportunidades, para que todo tenha uma ótima carreira pela frente. No final deste trabalho não posso deixar de expressar o meu sincero agradecimento às pessoas que, direta ou indiretamente, contribuíram para a concretização desta investigação. Assim, as minhas palavras de apreço e gratidão, a todos o sites que propôs que pesquisássemos conteúdos para esse trabalho.

O meu muito obrigado que Deus abençoe a todos.

Resumo 3.1 – Diagrama de Sequência

Um diagrama de sequência do sistema é um artefato criado rápida e facilmente que ilustra os eventos de entrada e saída relacionados com o sistema em discussão. Eles são entradas para contratos de operação e projeto de objetos.

A UML contem notação na forma de diagramas de sequencia para ilustrar eventos provenientes de atores externos ao sistema. Inclui diagramas de sequencia, como uma notação que pode ilustrar as interações de atores e as operações iniciadas por eles.

Um diagrama de sequência do sistema é uma figura que mostra, para um cenário especifico de um caso de uso, os eventos que os atores externos geram sua ordem e os eventos entre sistemas. Todos os sistemas são tratados como uma caixa preta: a ênfase do diagrama esta nos eventos que cruzam fronteira do sistema de atores para sistemas.

Um diagrama de sequência do sistema mostra eventos do sistema para um cenário de um caso de uso, portanto é gerado a partir da inspeção de um caso de uso. Também podem ser usados para ilustrar as colaborações entre sistemas, tais como entre o PDV ProxGer e o autorizador externo de pagamento a crédito. Entretanto, isso é adiado até uma iteração posterior no estudo de caso, uma vez que essa iteração não inclui a colaboração com sistemas remotos. Os DSSs são também muito uteis quando você deseja entender a interface e as colaborações de sistemas existentes ou documentar a arquitetura.

Identificar as operaçõespublicas de um sistema de software é uma necessidade muito antiga, assim, variantes de diagramas de interface do sistema que ilustram os eventos para um sistema tratado como caixa preta têm tido amplo uso há várias décadas. Eles foram inicialmente popularizados em métodos OO no método Fusion, o qual fornecia um exemplo detalhado entre o relacionamento do DSS e as operações do sistema com outros artefatos de análise e projeto.

Resumo 3.2 – Utilização do Diagrama de Sequênica

O TDD ( Test DrivenDevelopment) define e aplica testes de unidade antes da codificação das unidades envolvidas. Um código para uma unidade de software só pode ser desenvolvido se houver um conjunto de casos de testes. O mesmo consiste em 3etapas:definição dos casos te teste; codificação das classes com objetivo de atender aos casos de teste e refatoração. Em cada etapa se aplica a cada unidade de software .Destaca- se a definição dos casos de teste comparado ao teste de software tradicional, pois guia a codificação do sistema. Os drivers e stubs são identificados para uma codificação.

Drivers: Determinam a execução dos casos de teste definindo as mensagens e as verificações entre os objetos envolvidos. Este código geralmente é desenvolvido para que através de uma ferramenta automatize a execução dos testes.

Stubs: Substitui outras unidades de software envolvidas em um caso de teste, não dependendo mais de outras unidade, pois atende ao principio de isolamento das unidades,em que a mesma deve ser testada de forma isolada de outras.A codificação das classes se efetua com base nos casos de testes estabelecidos. Na etapa de refatoração o código desenvolvido para atender os casos de testes é avaliado de forma que verifica varias questões como a duplicidade no código

Um dos requisitos para o uso da técnica TDD é a automatização dos testes de unidade, pois os mesmos são executados com grande frequência na implementação das unidades.

Durante a elaboração do caso de teste devem ser definidas mensagens entre o driver e os objetos definidos.

A ferramenta para apoio no planejamento nos casos de teste tem como objetivo permitir a criação de um projeto, focando testes de unidades. Mas para isso é preciso que o modelo de classes do projeto testado esteja definido.

Ao solicitar a criação de um novo caso de teste, a partir de um métodopresente no modelo e importado pela ferramenta, é apresentado ao usuário o diagrama de sequencia com elementos pré – definidos:

- Gerenciador

- Stubs

- Objeto assert

Com os elementos do caso de teste definidos, pode-se estabelecer as mensagens entre o gerenciador do caso de teste e os demais objetos. Utilizando a opção de validação, o sistema apresenta criticas quanto aos possíveis problemas encontrados nos casos de testes definido pelo usuário. Com objetivo de apresentar a estrutura utilizada para implementação da ferramenta são exibidos os diagramas de classes de domínio, sendo que cada um representa um dos pacotes de ferramenta:modelo  e casoDeTeste.

O diagrama de sequencia como proposta para definição de teste juntamente com a ferramenta desenvolvida se configuram como soluçãopara os problemas, o código auxiliar é gerado automaticamente pela ferramenta.

Os casos de testes podem ser definidos de forma visual sem qualquer contato com a linguagem de implementação , tendo como base apenas o modelo de classes do projeto.

Diagrama de Sequência do Sistema

[pic 1]

Resumo 4.1 – Diagrama de Atividades

Um diagrama de atividades UML mostra atividades sequenciais e paralelas em um processo. Eles são uteis para modelagem de processos de negócios, fluxos de trabalhos, fluxos de dados e algoritmos complexos.