Em que fase do desenvolvimento do software é usualmente construído o diagrama de atividades?

NOME : Alexandre Sierra de Oliveira                                         7NA - BCC

TUTORIAL :

·       CASOS SE USO

·       DIAGRAMA DE SEQUÊNCIA

·       DIAGRAMA DE ATIVIDADES

CASOS DE USO (Fonte Wikipedia)

            O processo de identificação de requisitos na engenharia de software tem uma função fundamental no correto desenvolvimento do projeto, pode-se no entanto facilmente tornar num processo extenso e trabalhoso.

            Durante o desenvolvimento da área de Engenharia de Software, vários autores sugeriram diversas técnicas para um processo mais rápido e eficiente de levantamento e validação de requisitos de sistemas de software.

            Uma das técnicas mais populares é a utilização de Casos de Uso para descrever claramente todos os requisitos de um dado sistema, esta técnica foi proposta por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos OOSE,  visando identificar os requisitos de um sistema. Foi aprimorada por várias outras personalidades do campo, como por exemplo, Alistair Cockburn.

            Posteriormente foi incorporado à linguagem UML, que define um diagrama para representar graficamente os casos de uso e seus relacionamentos (Diagrama de caso de uso).

            Na Engenharia de Software, um caso de uso (ou use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por seqüências de mensagens intercambiáveis entre os sistemas e um ou mais atores. Pode ser representado por uma elipse contendo, internamente, o nome do caso de uso.

            Um Caso de Uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. Um Caso de Uso é uma unidade de um trabalho significante. Cada Caso de Uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto. Um Caso de Uso pode "incluir" outra funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento. Casos de Uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um trabalho.

            É importante notar que não descreve como o software deverá ser construído, mas sim como ele deverá se comportar quando estiver pronto. Um software freqüentemente é um produto complexo, e sua descrição envolve a identificação e documentação de vários casos de uso, cada um deles descrevendo uma "fatia" do que o software ou uma de suas partes deverá oferecer.
            Cada chamado caso de uso descreve um cenário de possível interação com um utilizador ou um outro sistema. Devem ser o mais claro possível para que todos os eventuais leitores de diferentes campos e backgrounds possam entendê-los de igual modo. Devendo-se assim evitar termos técnicos ou obscuros que possam possivelmente dificultar a compreensão inequívoca da funcionalidade descrita.

            Cada caso de uso deve descrever somente uma funcionalidade ou objetivo do sistema. É então comum, para sistemas minimamente complexos, serem necessários bastantes casos de uso para uma correta e completa descrição de todas as funcionalidades requeridas pelo sistema.

            Os casos de uso devem ser identificados através de nomes curtos que identifiquem a sua atividade inequivocamente, para tal são usualmente utilizadas as formas verbais ativas.

            Para facilitar a visão geral do sistema é usual agregar casos de uso similares em pacotes e criar diagramas que ilustrem essa agregação e qual a interação com outros sistemas ou utilizadores do sistema.

            Os casos de uso nestes diagramas são usualmente representados por ovais com setas a indicar quais os utilizadores ou sistemas externos que interagem com eles.

Exemplo de Caso de Uso

            A criação destes diagramas deve ser feita de uma maneira completamente fechada, ou seja, assumindo que o ator não tem conhecimento sobre o estado interno do sistema quando acessa uma dada funcionalidade. Devendo as interações ser descritas do ponto de vista externo. Esta forma de encarar a descrição de interação simplifica a descrição dos requisitos evita falsas deduções sobre como a funcionalidade será implementada no sistema.

            O padrão mais seguido para a elaboração de diagramas de caso de uso, também habitualmente referidos como modelos de caso de uso, é o introduzido pelo UML. Embora sendo este o padrão mais comum, é de notar que existem alternativas e que na prática o padrão utilizado é o definido pelo manual de qualidade do projeto em curso que habitualmente deve ser previamente definido de acordo com as necessidades previstas do projeto, podendo vir a ser redefinido devido a alterações lógicas encontradas durante processo.

            O nível de detalhe da descrição do caso de uso dependerá sempre do nível de formalidade exigido pelo projeto e do estado atual de desenvolvimento. Em níveis iniciais pode-se assumir uma descrição mais breve e sucinta, em estados mais avançados é de se esperar um maior detalhe e cuidado.

            EXEMPLO:

            1 Fazer Pedido - versão 1

            Cenário informal

            O caso de uso começa quando o cliente seleciona "fazer pedido". O cliente fornece seu nome e endereço. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado. O cliente fornece os códigos do produto. O sistema devolve as descrições e o preço de cada produto. O sistema calculará os valores totais para cada produto fornecido. O cliente fornece as informações sobre cartão de crédito. Em seguida, ele             submete os dados ao sistema. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade         e pagamento. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente.

            Cada caso de uso foca-se numa característica do sistema. Para a maioria dos projetos de software isto significa que múltiplos, talvez dezenas, de casos de uso são necessários para especificar completamente um novo sistema.

            O grau de conformidade de um projeto de software em particular pode influenciar o nível de detalhe requerido em cada caso de uso. É geralmente aceito que cada caso de uso seja curto o suficiente para ser implementado por um desenvolvedor de software num lançamento.

            A engenharia de requisitos consiste num processo onde são identificados todos os diferentes requisitos que um sistema de software deverá satisfazer quando se encontrar funcional. Este processo recorre a várias diferentes técnicas, algumas delas complementares entre si. O objetivo final é o de obter todos os requisitos idealizados para o sistema, possivelmente classificados por ordem de importância, descritos o mais claramente possível e devidamente validados pelos interessados ou stakeholders do sistema.

            A clareza com que os requisitos são descritos e a sua abrangência que é idealizada pelos stakeholder é a máxima prioridade do processo tendo em vista não só a necessidade de transição do conhecimento dos requisitos do sistema tanto para os programadores que o irão implementar quanto para os utilizadores que dele farão uso, mas também para garantir que todo o conteúdo pretendido esteja identificado antes do processo de implementação começar de modo a facilitar a arquitetura e planejamento de implementação da solução evitando retrabalho.

       Conceitos

·        Ator: Agente externo que interage com o sistema, dividindo-se em primário que interage diretamente e secundário que somente faz um serviço.

·        Interação: Comunicação dos atores com o sistema.

·        Associação entre casos de uso:

·        Inclusão (Include): Um caso de uso pode ser aproveitado no contexto de outros casos de uso. Exemplo: "calcular o DV do CNPJ" é um comportamento que pode ser utilizado como mecanismo para validar a inclusão de um objeto cliente ("cadastrar CLIENTE"), como pode ser utilizado para validar a inclusão de um objeto fornecedor ("cadastrar FORNECEDOR"). Compartilhamento de uma ação por outras ações reutilização.

·        Extensão (Extend): Um caso de uso pode ter seu comportamento requerido por outro caso de uso (e somente por este outro caso de uso). Dois motivos para a utilização do Extend: melhorar a estabilidade do modelo (i.e. redução do impacto de eventuais mudanças de comportamento) e diminuir a complexidade das operações (i.e. isolar os elementos que apresentem comportamentos mais complexos). Exemplo: "cadastrar FUNCIONÁRIO" requer a chamada de uma operação para "cadastrar DEPENDENTE DO FUNCIONÁRIO". O comportamento de "cadastrar DEPENDENTE DO FUNCIONÁRIO" servirá apenas aos propósitos de "cadastrar FUNCIONÁRIO" (i.e. não será compartilhado com outras ações). Modularização. Menor acoplamento e maior coesão.

            DIAGRAMAS DE SEQUÊNCIA

            Diagrama de seqüência (ou Diagrama de Seqüência de Mensagens) é um diagrama usado em UML (Unified Modeling Language), representando a seqüência de processos (mais especificamente, de mensagens passadas entre objetos) num programa de computador. Como um projeto pode ter uma grande quantidade de métodos em classes diferentes, pode ser difícil determinar a seqüência global do comportamento. O diagrama de seqüência representa essa informação de uma forma simples e lógica.

            Um diagrama de seqüência descreve a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. Ele registra o comportamento de um único caso de uso e exibe os objetos e as mensagens passadas entre esses objetos no caso de uso.

            Em síntese: o Diagrama de Seqüência é uma das ferramentas UML usadas para representar interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções). Este diagrama é construído a partir do Diagrama de Casos de Usos. Primeiro, se define qual o papel do sistema (Use Cases), depois, é definido como o software realizará seu papel(Seqüência de operações).

            O diagrama de sequência dá ênfase a ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. Entende-se por mensagens os serviços solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitações.

Exemplo de Diagrama de Seqüência (Fonte Wikipedia)

            Em um primeiro momento pode ser difícil obter um diagrama de seqüência com uma boa qualidade, tendo em vista que os eventos ainda podem ainda não estar claros. Uma técnica que facilita isso é a de fazer um diagrama de atividades após uma primeira versão do diagrama de seqüências, visando a procura de mais eventos para serem inseridos em uma nova versão do diagrama.

        Conceitos

·        Atores: São entidades externas que interagem com o sistema e que solicitam serviços, gerando dessa forma eventos que iniciam processos.

·        Objetos: Representam as instâncias das classes representadas no processo. Os objetos são ilustrados como retângulos. Eles compõem a dimensão horizontal (->).

·        Gate: Indica um ponto em que a mensagem pode ser transmitida para dentro ou para fora do fragmento de interação.

·        Fragmento: Fragmentos de interação como: Alt (Alternativa), Opt (Opcional), Break (Parar), Loop (Repetição) e outras.

·        Linha de vida: As linhas de vida compõem a dimensão vertical (tempo). A dimensão vertical é a seqüência onde a vida do objeto durante a interação representada.

DIAGRAMA DE ATIVIDADES

            O Diagrama de atividade é um diagrama definido pela UML, e representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente isso envolve a modelagem das etapas seqüenciais em um processo computacional.

            Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.

            O Diagrama de atividade pode ser feito para facilitar a detecção dos eventos, assim como sua ordem o que agiliza a confecção de um Diagrama de Seqüência mais completo. Tendo em vista que sua utilidade base não é essa ele deve ser descartado para não se tornar nocivo para o resto da engenharia de requisitos e ser novamente gerado em um momento mais oportuno.

Exemplo:

Então uma boa ordem para se chegar nos requisitos de um novo sistema seria :

1 - Definição de um novo Caso de Uso.

2 - A partir do Caso de Uso gerar um Diagrama de Seqüência inicial.

3 - A partir do Diagrama de Seqüência gerar um Diagrama de Atividades provisório.

4 - A partir do Diagrama de Atividades provisório gerar um novo Diagrama de Seqüência refinado.

5 - Descartar o Diagrama de Atividades provisório.

6 - Verificar eventos e requisitos encontrados.

Bibliografia

·        Inside the Unified Modeling Language, Material da Rational

·        UML Distilled Applying the Standard Object Modeling Language, Martin Fowler

·        Wikipedia, www.wikipedia.org

·        Especificação da Linguagem UML Versão 1.4, OMG

Em que fase é construído o diagrama de atividades?

Em que situações deve elaborar o diagrama de atividades?

Quais são as fases de um desenvolvimento de software?

Onde fazer diagrama de atividades?