Artigos Java UML e os diagramas de casos de uso, sequência e atividade

De que se trata o artigo: Apresentação dos conceitos relacionados ao comportamento dinâmico do sistema, aqui representados pelos diagramas de casos de uso, de sequência e de atividades.


Para que serve: Visa mostrar ao leitor os conceitos fundamentais sobre os diagramas de casos de uso, de sequência e de atividades para que ele possa criar modelos de sistemas usando esses diagramas.


Em que situação o tema é útil: Ao se projetar um software de grande porte, precisamos conhecer a fundo os diagramas UML. Neste artigo, abordamos os diagramas UML capazes de modelar o comportamento de um sistema.

Resumo DevMan: Neste artigo, aprenderemos os conceitos relacionados aos diagramas de casos de uso, de sequência e de atividades. Veremos como eles podem ser usados no processo de desenvolvimento de software. Os casos de uso são o ponto de partida do processo e representam as funcionalidades do sistema na visão dos atores. Os casos de uso modelam o que o sistema deve fazer. Para criar artefatos que representem como o software deve fazer para alcançar esses objetivos existem os diagramas de sequência e os diagramas de atividade. Os diagramas de sequência modelam a interação entre os objetos de um único caso de uso, enfatizando a ordem em que essas interações ocorrem. Por sua vez, os diagramas de atividades representam a visão de processo de um único caso de uso ou a modelagem da lógica detalhada de uma regra de negócio.

O levantamento de requisitos, possivelmente, é a tarefa mais difícil de todo o processo de desenvolvimento de um software. Em geral, os requisitos são identificados a partir de questionários, entrevistas com os usuários ou ainda análise de documentos usados no sistema corrente, entre outras técnicas. E isto em geral conduz a documentos redigidos pelos engenheiros de software, que descrevem essas funcionalidades. A descrição das funcionalidades comumente é feita em linguagem natural – linguagem usada para escrever este artigo. E não podemos negar que esse tipo de linguagem permite várias interpretações, pois se sabe que escrever algo de maneira que todos entendam o que se está querendo dizer é um grande desafio. Por outro lado, usar desenhos em vez de linguagem natural também pode não ser uma boa solução, visto que um desenho que faz sentido para uma pessoa pode não fazer para outra.

Então, como transformar estes requisitos em um formato que os stakeholders entendam, sem perder detalhes que são importantes para o processo de desenvolvimento? A resposta está nos casos de uso. Os casos de uso são o centro de tudo na UML, o ponto de partida para a criação de um sistema. Este artefato da UML é o primeiro tema a ser exposto nesta matéria.

Em seguida serão estudados os diagramas de sequencia, que fazem parte de um grupo da UML denominado diagramas de interação. Neste grupo estão também os diagramas de comunicação e de tempo. Os diagramas de interação modelam as interações entre as partes – os objetos, modelados no diagrama de classes – que compõem o sistema.

Será estudado mais adiante que os casos de uso modelam o que o sistema deve fazer, mas não especificam como o sistema irá cumprir esses objetivos. Para este fim existem os diagramas de atividade. Tais diagramas normalmente são usados para modelar os processos, e serão detalhados na parte final do artigo.

Diagrama de casos de uso

O diagrama de casos de uso é bastante usado no processo de levantamento de requisitos e análise. À medida que os requisitos são coletados, uma visão geral das funções e características do sistema começa a se materializar. No entanto, é difícil avançar para atividades mais técnicas de engenharia de software até que a equipe de software entenda como essas funções e características serão usadas por diferentes usuários finais.

Segundo McLaughlin, Pollice e West [5], um requisito é uma necessidade única que detalha o que um produto ou serviço em particular deve ser ou fazer. É frequentemente utilizado na engenharia de sistemas ou engenharia de software para identificar os atributos, características ou funcionalidades de um sistema que atendam às necessidades dos usuários.

Para que se consiga um melhor entendimento das necessidades de um software, desenvolvedores e usuários podem criar um conjunto de cenários que identifiquem uma maneira de se usar o sistema a ser construído. Esses cenários, conhecidos como casos de uso, fornecem uma descrição de como o sistema será usado.

Segundo Cockburn [4], um caso de uso se refere a um contrato que descreve o comportamento do sistema sob várias condições em que este responde a uma solicitação de um dos seus interessados. Em essência, um caso de uso conta uma história sobre a maneira como um usuário final interage com o sistema sob um conjunto específico de circunstâncias. A história pode ser um texto narrativo, um delineamento das tarefas e/ou interações ou uma representação em diagrama. Independentemente de sua forma, um caso de uso descreve o sistema do ponto de vista do usuário.

O primeiro passo ao se escrever um caso de uso é definir o conjunto de atores que estarão envolvidos na história. Atores representam papéis que pessoas (ou dispositivos) desempenham quando o sistema está em operação. Definindo mais formalmente, um ator é qualquer coisa que se comunique – ou interaja – com o sistema e que seja externo ao sistema em si. Durante essa interação com o sistema pode-se notar que cada ator tem um ou mais objetivos.

É importante notar que um ator e um usuário final não são necessariamente a mesma entidade. O usuário típico pode desempenhar vários papéis diferentes quando usa um sistema, enquanto o ator representa uma classe de entidades externas que desempenham apenas um papel no contexto do caso de uso. Como exemplo, pense num sistema em que autores de artigos recebam dinheiro pelas suas publicações. Nesse sistema, cada usuário pode ler artigos e/ou submeter artigos para publicação. Com isso, cada usuário pode desempenhar dois papéis distintos (leitor e escritor). Cada um desses papéis é modelado no diagrama de casos de uso como atores distintos, mas que podem representar as ações de um mesmo usuário. Isso evidencia a diferença entre atores e usuários.

...
Quer ler esse conteúdo completo? Tenha acesso completo