Modelagem de Sistemas

Linguagem de Modelagem Unificada - UM

Olá, estudante! Nesta videoaula, você conhecerá os fundamentos da UML (Unified Modeling Language), com foco em Diagramas Estruturais e Comportamentais. Estes conteúdos são essenciais para sua prática profissional, capacitando-o a visualizar e comunicar de forma eficaz a arquitetura e o comportamento de sistemas de software. Dominar a UML e seus diagramas permite uma análise mais precisa e uma comunicação mais clara entre os membros da equipe de desenvolvimento. Prepare-se para adquirir habilidades valiosas e impulsionar sua carreira.
Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Nesta aula, exploraremos uma linguagem essencial para a modelagem de sistemas de software, a UML(Unified Modeling Language). Começaremos discutindo a importância da UML como uma ferramenta padronizada e visualmente intuitiva para representar conceitos complexos de engenharia de software. Em seguida, abordaremos os diagramas estruturais, como o diagrama de classes e o diagrama de componentes, que são cruciais para compreender a organização estática de um sistema, incluindo suas classes, interfaces e relacionamentos. Estes diagramas são fundamentais durante as fases de design e arquitetura do software, ajudando os desenvolvedores a visualizar e comunicar a estrutura do sistema de forma clara e precisa.

Além disso, exploramos os diagramas comportamentais, como o diagrama de sequência e o diagrama de atividade, que oferecem insights valiosos sobre o fluxo dinâmico de interações e eventos em um sistema de software. Esses diagramas são essenciais para entender como os diferentes componentes do sistema interagem entre si ao longo do tempo, permitindo aos desenvolvedores modelar e analisar o comportamento funcional do software. Compreender os diagramas comportamentais é crucial para garantir que o sistema atenda aos requisitos funcionais e de desempenho esperados, além de facilitar a detecção e resolução de potenciais problemas de design.

Pensando nesses diagramas, vamos imaginar a seguinte situação, a empresa XYZ está planejando desenvolver um novo sistema de gerenciamento de projetos online chamado "ProjectMaster". Este sistema permitirá que os usuários criem projetos, atribuam tarefas, acompanhem o progresso, gerenciem recursos, colaborem em tempo real e gerem relatórios de desempenho. "ProjectMaster" será um sistema complexo com várias interações entre usuários e componentes do sistema, bem como uma estrutura de banco de dados abrangente para manter informações sobre projetos, tarefas, usuários e relatórios.

Como atividade, você deve refletir sobre o problema descrito e determinar quais diagramas UML seriam mais úteis para planejar e modelar o sistema "ProjectMaster". Sua tarefa é escolher ao menos três tipos de diagramas UML e justificar como cada um contribuirá para o desenvolvimento do sistema.

Para cada diagrama UML escolhido, você deve fornecer:

1. Nome do diagrama UML: especifique qual diagrama você está escolhendo.
2. Propósito do diagrama: descreva qual aspecto do sistema o diagrama ajudará a modelar.
3. Justificativa: explique por que você acredita que esse diagrama é uma boa escolha para o problema descrito e como ele pode beneficiar a equipe de desenvolvimento do "ProjectMaster".

Vamos Começar!

Fundamentos da UML

A Linguagem de Modelagem Unificada (Unified Modeling Language - UML) é uma linguagem visual projetada para modelar software baseado no paradigma de orientação a objetos. Ela é uma linguagem de modelagem de propósito geral, aplicável a uma ampla variedade de domínios de aplicação. Nos últimos anos, a UML emergiu como a linguagem-padrão de modelagem adotada internacionalmente pela indústria de engenharia de software.

É importante ressaltar que a UML não é uma linguagem de programação; em vez disso, é uma linguagem de modelagem, uma notação destinada a auxiliar engenheiros de software na definição das características do sistema. Isso inclui requisitos, comportamento, estrutura lógica, dinâmica de processos e até mesmo requisitos físicos relacionados ao hardware no qual o sistema será implantado. Essas características podem ser definidas por meio da UML antes do início do desenvolvimento do software (FOWLER, 2005).

Adicionalmente, é importante ressaltar que a UML não está intrinsecamente ligada a um processo específico de desenvolvimento de software. Ela é completamente independente e pode ser utilizada por uma variedade de processos de desenvolvimento diferentes, ou até mesmo de maneiras personalizadas, de acordo com a preferência do engenheiro.

Por que é necessário modelar um software? Muitos profissionais argumentam que conseguem discernir todas as necessidades de um sistema de informação de forma intuitiva e sempre operaram dessa maneira. Da mesma forma, por que projetar uma casa? Um pedreiro experiente não seria capaz de construí-la sem um projeto detalhado? Embora essas afirmações possam ser verdadeiras em alguns casos, a questão é muito mais complexa e abrange uma série de fatores, incluindo levantamento e análise de requisitos, prototipagem, escala do projeto, complexidade, prazos, custos, documentação, manutenção e reutilização, entre outros (GUEDES, 2011).

A diferença entre construir uma pequena casa e erigir um prédio de vários andares é marcante. Para edificar um prédio, é imprescindível elaborar um projeto minucioso, com cálculos precisos e corretos. Além disso, é necessário estimar custos, determinar o tempo de construção, avaliar a mão de obra necessária, especificar a quantidade de materiais, escolher o local de construção e muito mais. Grandes projetos não podem ser improvisados, e mesmo a maioria dos projetos pequenos demanda uma abordagem estruturada.

Na realidade, qualquer sistema, por mais simples que seja, deve ser modelado antes de sua implementação, principalmente porque os sistemas de informação tendem a crescer em tamanho, complexidade e alcance. Muitos profissionais consideram os sistemas de informação como "vivos" porque estão sempre sujeitos a mudanças. Na verdade, a designação mais precisa seria "dinâmicos", pois estão constantemente evoluindo. Essas mudanças são motivadas por diversos fatores, como solicitações de clientes por modificações ou melhorias, mudanças no mercado que exigem adaptações nas estratégias das empresas e alterações na legislação que requerem ajustes nos sistemas.

Portanto, é essencial que os sistemas de informação possuam documentação detalhada, precisa e atualizada para facilitar sua manutenção sem introduzir novos erros. A modelagem é uma maneira eficaz de documentar um sistema, mas não se limita a isso. Além da documentação, a modelagem oferece diversas outras vantagens (GUEDES, 2011).

A modelagem de software envolve a criação de modelos de software, mas o que exatamente é um modelo de software? Um modelo de software representa uma perspectiva de um sistema físico; é uma representação abstrata do sistema com um propósito específico, como descrever aspectos estruturais ou comportamentais do software. Esse propósito determina o que deve ser incorporado ao modelo e o que é considerado irrelevante.

Portanto, um modelo abrange completamente os aspectos do sistema físico que são relevantes para o propósito do modelo, no nível apropriado de detalhamento. Por exemplo, um modelo de casos de uso oferecerá uma visão dos requisitos essenciais do sistema, identificando as funcionalidades do software e os usuários que poderão interagir com elas, sem se preocupar em detalhar aspectos adicionais. Enquanto isso, um modelo conceitual identifica as classes relacionadas ao domínio do problema, sem entrar em detalhes sobre seus métodos. Por outro lado, um modelo de domínio amplia o modelo conceitual, incluindo informações relacionadas à solução do problema, como os métodos necessários para essa solução (GUEDES, 2011).

Atualmente, a versão mais recente da UML, conhecida como UML 2.5.1, oferece 13 diagramas diferentes para uso na modelagem de software (PRESSMAN, 2021). Com uma quantidade significativa de diagramas disponíveis, os desenvolvedores têm à disposição uma poderosa ferramenta para representar e comunicar diferentes aspectos de seus sistemas de software.

Os diagramas da UML podem ser categorizados em dois grandes grupos: os diagramas UML estruturais e os diagramas UML comportamentais. Além disso, existem os diagramas de interação, que geralmente se enquadram no grupo dos diagramas comportamentais. Essa distinção permite uma visualização do sistema a partir de diferentes perspectivas. A Figura 1 apresenta essa classificação e os diagramas que fazem parte de cada grupo.

Embora os manuais da linguagem UML não prescrevam uma ordem específica para a criação e utilização dos diagramas em um fluxo de desenvolvimento de software, geralmente os diagramas são apresentados em uma sequência didática. Essa sequência segue uma lógica baseada na complexidade dos diagramas, onde os mais simples são abordados primeiro para facilitar a compreensão do processo de criação. Seguindo essa abordagem, começamos de maneira simplificada com os diagramas estruturais e, em seguida, avançamos para os diagramas comportamentais, incluindo uma subdivisão para os diagramas de interação, que serão também explorados.

Siga em Frente...

Diagramas estruturais

Os diagramas estruturais revelam a organização de um sistema em suas partes constituintes, componentes e as interconexões entre esses elementos. Esses diagramas são frequentemente vinculados à modelagem estática, já que descrevem a estrutura do sistema em si. Geralmente, os diagramas estruturais são concebidos durante a fase inicial do projeto de arquitetura do sistema, representando conceitos significativos como abstrações, considerações de implementação e características do mundo real (FOWLER, 2005).

Os diagramas estruturais são seis, descritos a seguir, iniciando com o diagrama que provavelmente é um dos mais utilizados até por desenvolvedores que não estão totalmente familiarizados com os conceitos da UML: o diagrama de classes.

O diagrama de classes é amplamente reconhecido como um dos elementos mais essenciais e frequentemente utilizado na UML (GUEDES, 2011). Funciona como uma base para a maioria dos outros diagramas, fornecendo uma representação estruturada das classes empregadas pelo sistema. Este diagrama delineia os atributos e métodos associados a cada classe, além de especificar os relacionamentos e interações entre elas.

O diagrama de pacotes tem como objetivo representar os subsistemas ou submódulos incluídos em um sistema, identificando suas partes constituintes. Pode ser empregado de forma autônoma ou em conjunto com outros diagramas. Além disso, é útil para ilustrar a arquitetura de uma linguagem, como no caso da UML, e para definir as camadas de um software ou processo de desenvolvimento (PRESSMAN, 2021).

O diagrama de componentes está intimamente ligado à linguagem de programação escolhida para o desenvolvimento do sistema modelado. Ele visualiza os componentes do sistema no momento da implementação, representando-os como módulos de código-fonte, bibliotecas, formulários, arquivos de ajuda, entre outros (FOWLER, 2005). Este diagrama determina a estrutura e a interação dos componentes, essenciais para o funcionamento adequado do sistema.

O diagrama de instalação descreve a estrutura de hardware e software necessária para a correta execução do software em desenvolvimento. No diagrama é possível relacionar quais componentes do software desenvolvido serão executados em cada um dos nós de hardware descritos.

O diagrama de objetos está intimamente relacionado ao diagrama de classes, servindo como um complemento essencial e dependente deste último (GUEDES, 2011). Ele oferece uma perspectiva dos valores contidos pelos objetos representados no diagrama de classes em um instante específico durante a execução de um processo de software.

O diagrama de estrutura composta oferece uma representação detalhada da organização interna de um classificador, como uma classe ou componente, delineando suas partes constituintes, comunicação e colaboração entre elas. Além disso, é empregado para descrever uma colaboração na qual um conjunto de instâncias trabalha em conjunto para realizar uma determinada tarefa.

Diagramas comportamentais

Os diagramas comportamentais têm como finalidade representar o fluxo de informações e eventos ao longo do tempo no sistema. Em outras palavras, eles ilustram a resposta do sistema a eventos do ambiente, exibindo o comportamento dinâmico dos objetos e como o sistema reage a ações específicas ou eventos.

Os diagramas de interação estão incluídos no conjunto de diagramas comportamentais e são utilizados para modelar as interações dentro do sistema ou entre os seus componentes.

O diagrama de casos de uso é amplamente reconhecido como o diagrama mais abrangente e informal da UML, frequentemente empregado nas etapas de levantamento e análise de requisitos do sistema. Contudo, ele continua a ser uma referência ao longo de todo o processo de modelagem e pode servir como base para outros diagramas. Este diagrama utiliza uma linguagem simples e de fácil compreensão para proporcionar aos usuários uma visão geral do comportamento esperado do sistema (PRESSMAN, 2021). Seu objetivo é identificar os atores (sejam usuários, outros sistemas ou hardware especializado) que interagirão de alguma forma com o software, bem como os serviços ou funcionalidades oferecidas pelo sistema aos atores, denominados casos de uso neste contexto.

O diagrama de atividade tem como objetivo descrever os passos necessários para a conclusão de uma determinada atividade, que pode variar desde um método com certo nível de complexidade até um algoritmo ou até mesmo um processo completo. Sua principal preocupação reside na representação do fluxo de controle durante a execução da atividade.

O diagrama de visão geral de interação é uma derivação do diagrama de atividade, projetado para oferecer uma perspectiva global dentro de um sistema ou processo de negócios. Esta representação foi introduzida na UML 2.

O diagrama de sequência é uma representação comportamental que se concentra na ordem temporal das mensagens trocadas entre os objetos envolvidos em um determinado processo. Tipicamente, ele se baseia em um caso de uso definido pelo mesmo nome e utiliza o diagrama de classes para identificar os objetos das classes envolvidas no processo. Este diagrama costuma identificar o evento que desencadeia o processo modelado, assim como o ator responsável por esse evento. Ele delineia como o processo deve se desdobrar e ser concluído, através da invocação de métodos por meio de mensagens enviadas entre os objetos.

O diagrama de máquina de estados ilustra o comportamento de um elemento através de um conjunto finito de transições de estado, representando essencialmente uma máquina de estados. Além de descrever o comportamento de uma parte do sistema, quando é denominado máquina de estado comportamental, ele também pode expressar o protocolo de uso de uma parte do sistema ao identificar uma máquina de estado de protocolo. Similar ao diagrama de sequência, o diagrama de máquina de estados pode ser baseado em um caso de uso, mas também é capaz de rastrear os estados de outros elementos, como uma instância de uma classe.

O diagrama de comunicação está estreitamente ligado ao diagrama de sequência, sendo, na verdade, um complemento deste. As informações representadas no diagrama de comunicação muitas vezes são semelhantes às apresentadas no diagrama de sequência, porém com uma abordagem distinta. Enquanto o diagrama de sequência se concentra na ordem temporal das interações, o diagrama de comunicação destaca como os elementos estão conectados e quais mensagens são trocadas entre eles durante o processo.

O diagrama de tempo representa a evolução do estado ou condição de uma instância de classe ou seu papel ao longo de um período específico. Ele é frequentemente empregado para ilustrar a alteração no estado de um objeto ao longo do tempo em resposta a eventos externos (GUEDES, 2011). 

Vamos Exercitar?

Esta atividade visa desenvolver a capacidade de tomada de decisão do estudante sobre quais diagramas UML são mais adequados para modelar diferentes aspectos de um sistema de software. Com isso, você deve selecionar e justificar o uso de diagramas UML específicos com base em um cenário de problema fornecido no início da aula.

Um exemplo de resposta é:

• Diagrama UML: diagrama de casos de uso
• Propósito do diagrama: representar as funcionalidades do sistema a partir da perspectiva do usuário, mostrando como diferentes atores interagem com o sistema.
• Justificativa: esse diagrama é crucial para entender as necessidades dos usuários e garantir que o "ProjectMaster" ofereça as funcionalidades necessárias para gerenciamento de projetos. Ele ajuda a definir os requisitos do sistema de uma maneira que todos os stakeholders possam entender.

Saiba Mais

O livro UML Essencial apresenta os principais conceitos da UML, além de trazer diversos exemplos de diagramas. 

FOWLER, Martin. UML essencial. 3.ed. – Porto Alegre: Bookman, 2005. 

A UML é uma linguagem de modelagem que suporta o paradigma Orientado a Objetos. No livro Análise e Design Orientados a Objetos para Sistemas de Informação você pode ver diversos exemplos utilizando a UML para a POO.

WAZLAWICK, R. S. Análise e Design Orientados a Objetos para Sistemas de Informação: Modelagem com UML, OCL e IFML. Grupo GEN, 2014.

Referências Bibliográficas

FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3.ed. – Porto Alegre: Bookman, 2005.

GUEDES, Gilleanes T. A UML 2: uma abordagem prática. 2. ed. - São Paulo: Novatec Editora, 2011.

PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

Diagrama de casos de uso

Nesta videoaula, abordaremos a introdução ao Diagrama de casos de uso, seus elementos e um exemplo prático de sua aplicação. Esses conteúdos são fundamentais para sua prática profissional na Engenharia de software, pois permitem a compreensão e a comunicação eficaz dos requisitos de um sistema. Dominar o Diagrama de casos de uso capacita o profissional a modelar e analisar os comportamentos esperados do software, garantindo sua eficiência e adequação às necessidades dos usuários. Prepare-se para adquirir conhecimentos essenciais e elevar sua competência na área!

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Nesta aula, exploraremos um dos aspectos fundamentais da modelagem de sistemas de software: o Diagrama de casos de uso. Este diagrama é uma ferramenta poderosa da Linguagem de Modelagem Unificada (UML), essencial para capturar as funcionalidades de um sistema do ponto de vista dos usuários. Ao entender como criar e interpretar um diagrama de casos de uso, você estará equipado para visualizar o escopo de um projeto, detalhar interações entre o sistema e seus usuários e identificar requisitos críticos de uma maneira organizada e eficiente. Estudaremos atores, casos de uso, relações de inclusão e extensão. Todos os componentes que juntos fornecem uma visão clara das expectativas dos usuários e dos requisitos funcionais do sistema.

Compreender o diagrama de casos de uso é mais do que um exercício acadêmico; é uma habilidade prática que melhora a comunicação entre desenvolvedores, analistas de sistemas, stakeholders e usuários finais. Essa compreensão assegura que o desenvolvimento do software esteja alinhado com as necessidades reais dos usuários, evitando mal-entendidos e retrabalhos dispendiosos.

Para exercitar o que será aprendido nesta aula, elabore um diagrama de casos de uso da seguinte situação: "O sistema de pedidos da empresa oferece uma série de funcionalidades para facilitar e gerenciar a forma como os clientes realizam pedidos. Os clientes podem fazer pedidos de três maneiras diferentes: por telefone, on-line através do website, ou usando o aplicativo móvel. Quando um pedido é realizado, independente do método, ele é gerenciado por um responsável pelos pedidos, que tem a tarefa de assegurar que o pedido seja processado corretamente. Para os pedidos on-line, existe a possibilidade de extensão para fazer pedidos utilizando o aplicativo móvel. Além disso, antes de um pedido ser confirmado, o gerente do sistema deve verificar os dados do pedido, uma etapa incluída no processo de realização de pedido. O sistema também permite o cadastro de novos usuários, que é uma funcionalidade acessível pelo cliente e inclui um passo adicional onde o gerente deve verificar os dados fornecidos pelo novo usuário."

Vamos Começar!

Introdução ao diagrama de casos de uso

O diagrama de casos de uso tem como objetivo simplificar a compreensão do comportamento externo do sistema, mostrando suas funcionalidades de forma acessível a qualquer pessoa e destacando a perspectiva do usuário. É o diagrama mais abstrato e flexível da UML, sendo comumente utilizado nas fases iniciais de modelagem do sistema, especialmente durante o levantamento e análise de requisitos. No entanto, ele continua sendo consultado e ajustado ao longo do processo de engenharia, servindo de base para outros diagramas.

Este diagrama oferece uma visão panorâmica das funcionalidades que o sistema deve disponibilizar aos usuários, sem entrar em detalhes sobre sua implementação. Ele é fundamental para identificar e compreender os requisitos do sistema, ajudando a especificar, visualizar e documentar as características, funções e serviços desejados pelos usuários. Além disso, ele ajuda a identificar os diferentes tipos de usuários que interagirão com o sistema, os papéis que desempenharão e as funções que cada usuário poderá solicitar.

Devido à sua linguagem informal e capacidade de proporcionar uma visão geral do comportamento do sistema a ser desenvolvido, o diagrama de casos de uso é uma ferramenta valiosa para ser apresentada durante as primeiras reuniões com os clientes. Ele serve como uma forma de ilustrar o funcionamento do sistema de informação, tornando mais fácil para os usuários compreenderem e identificarem possíveis lacunas na especificação, garantindo assim que os requisitos do sistema tenham sido entendidos corretamente. Recomenda-se fortemente apresentar o diagrama de casos de uso juntamente com um protótipo, pois isso permite que um complemente o outro, oferecendo uma visão mais abrangente e concreta do sistema em desenvolvimento.

O primeiro passo ao desenvolver um caso de uso é estabelecer o conjunto de "atores" envolvidos na narrativa. Os atores são as diversas entidades (sejam pessoas ou dispositivos) que interagem com o sistema ou produto dentro do contexto das funcionalidades e comportamentos a serem descritos. Eles representam os papéis que estas entidades desempenham enquanto o sistema está em operação. Em termos mais formais, um ator é qualquer entidade externa ao sistema ou produto que se comunica com ele e possui uma ou mais metas específicas ao usar o sistema.

É importante observar que "ator" e "usuário" não são sinônimos. Enquanto um usuário típico pode assumir diversos papéis ao interagir com um sistema, um ator representa uma classe de entidades externas (que podem ser pessoas, mas não necessariamente) que desempenham apenas um papel dentro do contexto de um caso de uso específico. Por exemplo, consideremos um usuário que utiliza um software para configurar os sensores de alarme em um edifício virtual. Após analisar os requisitos do sistema, o software requer quatro modos distintos de interação: modo de posicionamento, modo de teste, modo de monitoramento e modo de diagnóstico. Assim, podemos definir quatro atores: o editor, o testador, o monitorador e o diagnosticador. Em alguns casos, uma única pessoa pode desempenhar todos esses papéis, enquanto em outros, diferentes pessoas podem assumir cada papel de ator.

Elementos do diagrama de casos de uso

Atores

O diagrama de casos de uso se concentra em dois elementos principais: atores e casos de uso. Os atores representam os papéis desempenhados pelos vários usuários que podem utilizar os serviços e funções do sistema de alguma forma. Em alguns casos, um ator pode representar hardware especializado ou até mesmo outro software que interaja com o sistema, como em um sistema integrado. Portanto, um ator pode ser qualquer entidade externa que interaja com o software. Os atores são representados por símbolos de "bonecos magros", acompanhados de uma breve descrição abaixo de seu símbolo, identificando o papel que o ator desempenha no contexto do diagrama. A Figura 1 apresenta a representação de três possíveis atores de um sistema.

Nesse exemplo, os atores Cliente e Gerente representam usuários normais, enquanto o ator Sistema Integrado representa um software que interage de alguma forma com o sistema.

Casos de uso

Os casos de uso servem para capturar os requisitos do sistema, ou seja, englobam os serviços, tarefas ou funcionalidades identificadas como essenciais para o software e que podem ser utilizados pelos atores que interagem com o sistema. Eles são empregados para expressar e documentar os comportamentos desejados das funções do sistema. Podem ser divididos em casos de uso primários e secundários. Um caso de uso primário refere-se a um processo crucial que se concentra em um dos requisitos funcionais do software, como efetuar um saque ou gerar um extrato em um sistema bancário. Por outro lado, um caso de uso secundário aborda um processo periférico, como a manutenção de um cadastro (GUEDES, 2011).

Em algumas situações, um caso de uso pode estar associado a um formulário do sistema, embora isso não seja uma regra absoluta, uma vez que uma funcionalidade do sistema, ou seja, um caso de uso, pode abranger vários formulários ou até mesmo consistir em uma pequena opção de interface, como um botão, por exemplo. Os casos de uso são representados por elipses contendo um texto que descreve a funcionalidade a que se refere. Não há um limite específico para o texto dentro da elipse, mas geralmente a descrição de um caso de uso é concisa. A Figura 2 exemplifica um caso de uso, representando a funcionalidade de matricular aluno.

Os casos de uso costumam ser documentados, fornecendo instruções em linhas gerais de como será seu funcionamento, quais atividades deverão ser executadas, qual evento forçará sua execução, quais atores poderão utilizá-los e quais suas possíveis restrições, entre outras.

A documentação de um caso de uso geralmente inclui informações básicas sobre sua função, os atores envolvidos, as etapas necessárias para sua execução por parte do ator e do sistema, os parâmetros necessários e quaisquer restrições ou validações aplicáveis. No entanto, não há um formato fixo para a documentação de casos de uso definido pela UML, o que reflete a própria flexibilidade do diagrama. Assim, o formato da documentação pode variar amplamente, permitindo diferentes abordagens, incluindo o uso de pseudocódigo ou até mesmo código de programação real. No entanto, é importante considerar que o objetivo principal do diagrama de casos de uso é utilizar uma linguagem simples e acessível, compreensível até mesmo para usuários não técnicos.

Por essa razão, é recomendável evitar o uso de pseudocódigo na documentação de casos de uso, uma vez que isso é mais apropriado para outros tipos de diagramas, como o de atividade. Além disso, os casos de uso também podem ser documentados usando outros tipos de diagramas, como o de sequência, de estado ou de atividade (GUEDES, 2011). O Quadro 1 oferece uma sugestão de como documentar o caso de uso representado na Figura 2.

Nome do caso de uso	Matricular Aluno
Ator Principal	Aluno
Atores Secundários	Secretária
Resumo	Este caso de uso tem por objetivo detalhar o processo de matrícula do aluno no sistema.
Pré-condições	1. O aluno deverá estar matriculado no sistema. 2. Não poderá haver nenhuma pendência financeira no sistema.
Fluxo Principal
Ações do Ator		Ações do Sistema
1. O aluno informa a matrícula e senha para se logar no sistema. 4. O aluno poderá escolher a disciplina que cursará num total de 6 disciplinas por semestre. 5. O aluno deverá finalizar a escolha da disciplina apertando o botão FINALIZAR. 6. O aluno poderá escolher entre imprimir ou salvar o comprovante de matrícula.		2. O sistema deverá verificar a matrícula e validar a senha do aluno. 3. Deverão ser apresentadas as disciplinas que o aluno poderá cursar. 6. Um comprovante de matrícula deverá ser gerado em formato PDF.
Fluxos Alternativos
Ações do Ator		Ações do Sistema
1.1 O aluno poderá redefinir a sua senha.		2.1 - Caso o aluno não tenha senha o sistema deverá permitir o cadastramento da senha ou a sua redefinição. 3.1 - Deverá ser verificado o semestre atual do aluno, se for o 1° semestre do aluno, ele deverá escolher todas as disciplinas. 3.2 - Deverá ser verificada a quantidade de disciplinas a serem escolhidas (limite dever ser igual a 6).

Quadro 1 | Especificação do caso de uso: Matricular Aluno. Fonte: adaptado de Werlich (2020, p. 159).

Associação

As associações representam as interações ou conexões entre os atores dentro do diagrama, entre os atores e os casos de uso, ou entre os próprios casos de uso. Esses relacionamentos entre os casos de uso recebem nomes específicos, como inclusão, extensão e generalização (FOWLER, 2015).  Uma associação entre um ator e um caso de uso indica que o ator está de alguma forma envolvido na utilização da funcionalidade representada pelo caso de uso, seja solicitando a execução dessa função, seja recebendo o resultado produzido por ela em resposta a uma ação de outro ator.

Essa associação entre um ator e um caso de uso é denotada por uma linha conectando o ator ao caso de uso. Em certos casos, as extremidades dessa linha podem ter setas, indicando a direção do fluxo de informações: se elas são fornecidas pelo ator ao caso de uso, se são transmitidas pelo caso de uso ao ator ou se ocorre uma troca de informações bidirecional (nesse caso, a linha não possui setas, indicando que as informações fluem em ambas as direções). As setas também esclarecem quem inicia a comunicação. Além disso, uma associação pode conter uma descrição própria para esclarecer a natureza das informações transmitidas ou para atribuir um nome à associação, quando necessário.  A Figura 3 apresenta uma associação entre ator e caso de uso.

Ao examinarmos o exemplo ilustrado pela Figura 3, percebemos que o ator Secretária utiliza, de alguma forma, a funcionalidade de Matricular aluno, representada pelo caso de uso, e que a informação referente a esse processo trafega nas duas direções.

Generalização/Especialização

O relacionamento de generalização/especialização é uma forma de associação entre casos de uso em que dois ou mais casos de uso compartilham características semelhantes, mas apresentam pequenas diferenças entre si. Nesse cenário, costuma-se criar um caso de uso genérico que descreve as características comuns a todos os casos de uso envolvidos, e então relacioná-lo aos casos de uso específicos, cuja documentação incluirá apenas as características distintas de cada um.

Dessa forma, torna-se desnecessário repetir a mesma documentação para todos os casos de uso, uma vez que todas as características do caso de uso genérico são herdadas pelos casos de uso especializados. Além disso, os casos de uso especializados também herdam quaisquer associações de inclusão ou extensão do caso de uso genérico, bem como as associações com os atores que utilizam o caso de uso genérico (GUEDES, 2011).

O relacionamento de generalização/especialização é representado por uma linha com uma seta mais espessa, que indica o caso de uso genérico (ponta da seta) e os casos de uso especializados (extremidade oposta da seta, apontando para o caso de uso genérico). Um exemplo desse tipo de relacionamento pode ser observado na Figura 4.

Inclusão

A associação de inclusão é frequentemente aplicada quando há uma rotina, situação ou cenário comum a múltiplos casos de uso. Nesse contexto, a documentação dessa rotina é centralizada em um caso de uso específico para que outros casos de uso possam utilizar esse serviço, evitando a redundância na descrição de uma mesma sequência de passos em vários casos de uso. As associações de inclusão indicam uma dependência obrigatória, ou seja, quando um caso de uso possui uma associação de inclusão com outro, a execução do primeiro implica automaticamente a execução do segundo. Essa relação de inclusão pode ser comparada à chamada de uma sub-rotina ou função, um conceito comum em diversas linguagens de programação (GUEDES, 2011).

Uma associação de inclusão é representada por uma linha tracejada, contendo uma seta em uma das extremidades, que aponta para o caso de uso que está sendo incluído pelo caso de uso posicionado na outra extremidade da linha. Essas associações costumam incluir um estereótipo que contém o texto "include" entre dois sinais de menor (<) e dois de maior (>). Os estereótipos são utilizados para destacar componentes ou associações, atribuindo-lhes características especiais em relação aos demais. Um exemplo de associação de inclusão pode ser observado na Figura 5.

Ao analisarmos a Figura 5, percebemos que sempre que ocorrer a matrícula de um aluno, o sistema deve gerar um relatório referente a essa matrícula.

Extensão

As associações de extensão são empregadas para descrever cenários opcionais dentro de um caso de uso. Os casos de uso estendidos descrevem situações que ocorrerão apenas sob circunstâncias específicas, dependendo se determinada condição for satisfeita ou não. Assim, as associações de extensão indicam a necessidade de uma avaliação para determinar se é necessário ou não executar o caso de uso estendido. Os relacionamentos de extensão representam eventos que não ocorrem sempre, embora isso não signifique que sejam raros. As associações de extensão possuem uma representação muito semelhante às associações de inclusão, sendo também representadas por uma linha tracejada. A diferença está na direção da seta, que aponta para o caso de uso que aciona a extensão, e na presença de um estereótipo contendo o texto "extend" em vez de "include" (GUEDES, 2011). Para ilustrar o conceito de extensão, apresentamos um exemplo na Figura 6.

No caso de uso anterior, pode-se notar que matricular aluno e consultar informações das turmas são casos de uso e existe uma relação de extensão entre eles. Isso demostra que consultar informações de turmas, poderá ser chamado a partir do caso de uso matricular aluno, porém isso não é obrigatório.

Siga em Frente...

Exemplos de utilização do diagrama

Para exemplificar os elementos estudados, vamos ver o seguinte exemplo apresentado na Figura 7, que apresenta um diagrama de casos de uso para o sistema bancário.

A Figura 7 mostra o diagrama de casos de uso relacionado a um sistema de controle bancário. Este sistema possibilita que os clientes realizem a abertura e o encerramento de contas, bem como efetuem depósitos ou saques e solicitem saldos ou extratos. As quatro últimas funcionalidades mencionadas podem ser utilizadas diretamente pelo cliente por meio de um caixa eletrônico. No entanto, para abrir ou encerrar uma conta, o cliente precisa interagir com um funcionário do banco, que também pode executar algumas operações de manutenção em seu cadastro, como registrá-lo ou alterar seus dados.

No sistema representado, um cliente, representado como um ator, pode solicitar a abertura de uma conta comum, especial ou poupança. Como os processos de abertura para cada tipo de conta são muito semelhantes entre si, decidiu-se usar o caso de uso "Abrir Conta Comum" como uma generalização, com os outros dois tipos de abertura como especializações, detalhando as características específicas em sua documentação.

Uma associação de extensão existe entre o caso de uso "Abrir Conta Comum" (herdada também por suas especializações) e o "Manter Clientes". Embora o caso de uso "Manter Clientes" possa ser utilizado independentemente pelos funcionários do banco, a criação de uma conta normalmente implica o registro do novo cliente ou a atualização de seus dados. No entanto, como isso nem sempre é necessário, esse caso de uso não é uma inclusão e só será executado se o cliente não estiver registrado ou precisar atualizar seus dados.

Há também uma associação de inclusão entre o caso de uso "Abrir Conta Comum" (igualmente herdado por suas especializações) e o "Realizar Depósito", pois é necessário depositar algum valor no momento da abertura da conta. Sempre que uma conta é aberta, as instruções contidas no caso de uso "Realizar Depósito" são executadas.

Um cliente pode querer encerrar uma conta, mas antes disso, é necessário verificar o saldo para determinar se é necessário devolver dinheiro ao cliente ou se ele precisa depositar dinheiro para encerrar a conta. Essa verificação de saldo é obrigatória e é representada por uma associação de inclusão entre os casos de uso "Encerrar Conta" e "Emitir Saldo".

Se o saldo for positivo, um saque é realizado por meio do caso de uso "Realizar Saque". Se o saldo for negativo, um depósito é feito através do caso de uso "Realizar Depósito". Como não é possível prever se será necessário sacar ou depositar, as associações entre esses casos de uso são representadas por extensões.

Uma última associação de extensão existe entre o caso de uso "Encerrar Conta" e o "Manter Cliente" devido à possibilidade de a conta a ser encerrada ser a única conta mantida pelo cliente. Nesse caso, o registro do cliente é mantido, identificando-o como inativo, pois, uma vez cliente, seu registro não pode ser excluído do sistema.

Além disso, há os casos de uso "Emitir Saldo" e "Emitir Extrato", que são serviços simples utilizados diretamente pelo cliente por meio de um caixa eletrônico, sem a intermediação de um funcionário. Esses casos de uso não requerem interações com outros casos de uso do diagrama, embora o caso de uso "Emitir Saldo" seja utilizado pelo caso de uso "Encerrar Conta".

Por fim, abordamos os casos de uso "Realizar Saque" e "Realizar Depósito", os quais já foram mencionados anteriormente, pois também podem ser solicitados pelo caso de uso "Encerrar Conta". Normalmente, no entanto, esses serviços, assim como os casos de uso "Saldo" e "Extrato", são utilizados diretamente pelo cliente. No entanto, para garantir o registro adequado das transações, ambos os casos de uso obrigatoriamente envolvem o caso de uso "Registrar Movimento", que registra qualquer saque ou depósito realizados em uma conta para fins de histórico bancário. Devido à sua obrigatoriedade, a associação entre os casos de uso "Realizar Saque" e "Realizar Depósito" com o caso de uso "Registrar Movimento" precisa ser uma associação de inclusão.

O exemplo do sistema de controle bancário apresentado é relativamente complexo, envolvendo diversos tipos de associações. Entretanto, é importante ressaltar que o diagrama de casos de uso é geralmente concebido para oferecer uma visão externa simplificada do sistema ao usuário, caracterizando-se muitas vezes por sua simplicidade. Portanto, sempre que possível, deve-se evitar desenvolver diagramas de casos de uso excessivamente complexos. Ao longo deste capítulo e nas soluções dos exercícios propostos, serão apresentados novos exemplos, alguns mais simples que este (GUEDES, 2011). 

Vamos Exercitar?

Nesta atividade, você deve desenvolver um diagrama de casos de uso para um sistema de pedidos de compras. Na Figura 8, está apresentado uma possível solução para o sistema proposto.

Saiba Mais

O Visual Paradigma Online oferece uma plataforma intuitiva e acessível para criar diagramas UML com facilidade, ajudando os usuários a visualizarem e comunicarem eficientemente suas ideias e projetos.

VISUALPARADIGM ONLINE. Modelos de diagramas. [s. d.].

O livro UML Essencial apresenta os principais conceitos do diagrama de casos de uso no Capítulo 9.

FOWLER, M. UML essencial. 3.ed. – Porto Alegre: Bookman, 2005.

 O livro Engenharia de Software - Pressman aborda o diagrama de casos de uso diversas vezes durante o seu livro, mas ele traz no Apêndice 1, a descrição deste diagrama e exemplos de aplicações. 

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Grupo A, 2021. 

Referências Bibliográficas

FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3.ed. – Porto Alegre: Bookman, 2005.

GUEDES, G. T. A UML 2: uma abordagem prática. 2. ed. -- São Paulo: Novatec Editora, 2011.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

WERLICH, C. Análise e modelagem de sistemas. Londrina: Editora e Distribuidora Educacional S.A., 2020.

Diagrama de atividades

Nesta videoaula, exploraremos a introdução ao Diagrama de atividades, seus elementos essenciais e exemplos práticos de sua aplicação. Esses conteúdos são essenciais para sua prática profissional, permitindo a visualização e análise dos processos e fluxos de trabalho de um sistema. Ao compreender e dominar o Diagrama de atividades, você estará capacitado a modelar e otimizar os processos de negócios, sistemas de software e fluxos de trabalho, impulsionando a eficiência e a qualidade dos projetos. Prepare-se para mergulhar em conceitos fundamentais e ampliar suas habilidades nesta área!

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Nesta aula, vamos nos aprofundar nos Diagrama de atividades, uma parte integral da Linguagem de Modelagem Unificada (UML) que nos permite mapear processos e fluxos de trabalho dentro de sistemas complexos. Este diagrama é uma ferramenta valiosa que fornece uma visão dinâmica das sequências de ações, decisões e paralelismo em operações de negócios e sistemas de software. A importância dos Diagramas de Atividades vai além da simples documentação; eles são fundamentais para a compreensão e a otimização de processos. Ao visualizar as etapas de um processo, podemos identificar gargalos, redundâncias e oportunidades para melhorias, garantindo que o design do sistema seja tanto eficiente quanto eficaz.

Durante a aula, examinaremos os elementos que compõem o diagrama de atividades, como nós de atividades, transições, decisões, ramificações e junções, assim como pontos de sincronização. Estes elementos trabalham juntos para fornecer um mapa claro de como um processo é realizado, permitindo que todos os envolvidos no desenvolvimento do sistema tenham a mesma compreensão de como as coisas devem funcionar. Com o conhecimento prático desses conceitos, você estará bem equipado para enfrentar os desafios do design de processos em seus projetos futuros.

Para colocar em prática o que veremos em aula, pense na seguinte situação: "o processo de preparação de um bolo é um esforço colaborativo que envolve várias etapas coordenadas entre Jennie, Mary e Helen. Inicialmente, Mary é responsável por procurar a receita, enquanto Jennie e Helen preparam os ingredientes necessários. Jennie mistura os ingredientes secos e Mary mistura os ingredientes molhados. Uma vez que os ingredientes secos e molhados estão prontos, Jennie mistura tudo. Paralelamente, Helen é encarregada de aquecer o forno. Após a mistura estar pronta e o forno aquecido, a massa é levada para assar. A etapa de assar inclui uma verificação de conclusão, onde o bolo é testado para ver se está pronto. Se não estiver pronto, o bolo continua a assar; se estiver pronto, ele é retirado do forno por Mary, concluindo o processo de preparação do bolo”.

Vamos Começar!

Introdução ao diagrama de atividades

O diagrama de atividades, anteriormente, era considerado uma variante do antigo diagrama de gráfico de estados, agora chamado de diagrama de máquina de estados na versão atual da UML. A partir da versão 2.0 da UML, esse diagrama foi elevado à categoria de um diagrama totalmente independente, deixando de se basear em máquinas de estados e passando a se basear em redes de Petri (GUEDES, 2011).

A modelagem de atividade enfatiza a sequência e as condições para coordenar comportamentos de baixo nível. Assim, o diagrama de atividade destaca-se como o diagrama mais focado no nível de algoritmo da UML e provavelmente um dos mais detalhados. Esse diagrama compartilha muitas semelhanças com os antigos fluxogramas utilizados para desenvolver a lógica de programação e determinar o fluxo de controle de um algoritmo.

Este diagrama é empregado, conforme o próprio nome sugere, para modelar atividades, que podem ser um método ou um algoritmo, ou mesmo um processo completo. As atividades podem descrever computação procedural, sendo os métodos correspondentes às operações sobre classes nesse contexto. Elas também podem ser aplicadas à modelagem organizacional para engenharia de processos de negócios e fluxo de trabalho. Por fim, as atividades podem ser usadas na modelagem de sistemas de informação para especificar processos ao nível do sistema (GUEDES, 2011). Uma atividade é composta por um conjunto de ações, ou seja, os passos necessários para que a atividade seja concluída.

Um diagrama de atividade pode modelar mais de uma atividade. Embora uma atividade sempre contenha ações, não é obrigatório que elas estejam representadas dentro da própria atividade, podendo ser feita referência a uma atividade já modelada ou para economizar espaço no diagrama. Além disso, o diagrama de atividade pode ser usado para representar dois tipos de fluxo: de controle e de objetos, como será explorado a seguir.

Elementos do diagrama de atividades

Em geral, a criação dos diagramas de atividades é realizada do topo para o final e, normalmente, possui os seguintes elementos principais:

• Estados iniciais e finais.
• Atividades e nós de ação
• Fluxo de controle
• Nó de Decisões
• Fork e Join
• Swimlanes (partições)

Agora, iremos definir todos os elementos listados anteriormente.

Estados iniciais e finais

Todo diagrama possui os estados iniciais e finais em sua notação, conforme notação ilustrada na Figura 1. Em um diagrama de atividades, pode-se ter um símbolo inicial e um símbolo final.

O nó inicial é usado para representar o início do fluxo quando a atividade é invocada. É representado por um círculo preenchido. Já o nó final é utilizado para representar o fim de um fluxo de uma atividade. É representado por um círculo preenchido dentro de um círculo vazio.

Atividades e nós de ação

Uma atividade define a coordenação das execuções de comportamentos subordinados utilizando um modelo de fluxo de controle e dados. Esses comportamentos subordinados podem ser acionados quando outros comportamentos no modelo terminam sua execução, quando objetos e dados se tornam disponíveis, ou quando eventos externos ocorrem (GUEDES, 2011). Uma atividade é representada por um retângulo grande com bordas arredondadas, conforme ilustrado na Figura 2.

Este exemplo retrata a atividade relacionada ao processo de emissão de saldo de uma conta, que faz parte do sistema de controle bancário

As atividades podem incluir ações de diversos tipos, como:

• Execução de funções primitivas, como operações aritméticas.
• Chamadas de comportamento, como a execução de outras atividades.
• Ações de comunicação, como o envio de sinais.
• Manipulação de objetos, como a leitura ou gravação de atributos, ou até mesmo a criação ou destruição de objetos.

Já o nó de ação são os elementos fundamentais de uma atividade. Eles representam passos ou etapas que devem ser executados dentro de uma atividade. Um nó de ação é considerado atômico, ou seja, não pode ser decomposto em partes menores. Ele é simbolizado por um pequeno retângulo com bordas arredondadas, semelhante a uma atividade, porém em tamanho reduzido (Guedes, 2011). Um exemplo de nó de ação é apresentado na Figura 3.

Fluxo de controle

O fluxo de controle é uma conexão que une dois nós, transmitindo sinais de controle entre eles. Ele é representado por uma linha com uma seta que aponta para o novo nó, partindo do nó anterior. Esta linha pode conter uma descrição, uma condição de guarda ou uma restrição, conhecida neste diagrama como peso (weight), que especifica, por exemplo, o número mínimo de sinais que devem ser transmitidos pelo fluxo (GUEDES, 2011).

Um sinal (token) pode conter valores de controle, objetos ou dados. No entanto, os objetos e dados só podem ser transmitidos através de um fluxo de objetos. Um exemplo de fluxo de controle é apresentado na Figura 4.

Neste exemplo, há dois nós de ação. O primeiro nó de ação representa a entrada do número de uma conta, enquanto o segundo representa a consulta da conta fornecida. É importante observar que a transição entre uma ação e outra é indicada pela linha do fluxo de controle que conecta os dois nós de ação. Além disso, a seta no fluxo de controle indica a ordem em que as ações serão executadas. 

Nó de decisões

Um nó de decisão é também um nó de controle, utilizado para representar uma escolha entre dois ou mais fluxos possíveis, em que um dos fluxos será escolhido em detrimento dos outros (FOWLER, 2005). Normalmente, um nó de decisão é acompanhado por condições de guarda, que são expressas entre colchetes e determinam as condições para a seleção de um determinado caminho. Além disso, um nó de decisão pode ser usado para reunir fluxos divergentes originados de um nó de decisão anterior, nesse caso, sendo denominado nó de junção. A Figura 5 ilustra um exemplo de nó de decisão.

Neste exemplo, continuamos a atividade que representa o processo de emissão de saldo, onde, após a consulta da conta, uma decisão deve ser tomada, representada por um losango. Se a conta for inválida, o processo é encerrado; caso contrário, é solicitada a senha. As condições para essa decisão são definidas por meio de condições de guarda, apresentadas entre colchetes e posicionadas sobre os dois fluxos alternativos.

Fork e Join

Um fork indica a separação de atividades em duas ou mais atividades concorrentes. Visualmente, é representado por uma barra horizontal preta com uma seta apontando para ela e duas ou mais setas saindo dela. Cada seta de saída representa um fluxo de controle que pode ser executado simultaneamente com os fluxos associados às outras setas que também saem do fork (PRESSMAN, 2021). Essas atividades concorrentes podem ser executadas em um único computador, usando diferentes threads, ou até mesmo em diferentes computadores.

Uma junção (join) é utilizada para sincronizar fluxos de controle concorrentes. Visualmente, é representada por uma barra preta horizontal com duas ou mais setas chegando e uma seta saindo. O fluxo de controle representado pela seta que sai não pode iniciar a execução até que todos os outros fluxos representados pelas setas que chegam tenham sido completados.

A Figura 6 apresenta esses elementos.

Swimlanes

Swimlanes são divisões horizontais ou verticais em um diagrama de atividades que ajudam a visualizar a responsabilidade e a interação entre diferentes participantes ou entidades envolvidas em um processo. Cada swimlane representa uma unidade organizacional, um papel ou uma entidade distinta que desempenha um conjunto específico de atividades dentro do processo. Essa abordagem ajuda a tornar mais claro quem é responsável por cada etapa do processo e como as informações fluem entre as partes envolvidas. As swimlanes são uma ferramenta útil para modelar e analisar processos complexos, permitindo uma compreensão mais clara das interações entre os diferentes componentes do sistema (PRESSMAN, 2021). A Figura 7 apresenta um exemplo de Swimlanes.

Siga em Frente...

Exemplos de utilização do diagrama

Para exemplificar os elementos estudados, vamos ver o seguinte exemplo apresentado na Figura 8, que apresenta um diagrama de atividades que apresenta um processo de retirada de dinheiro em um caixa eletrônico.

Baseado no diagrama de atividades apresentado, o enunciado apropriado poderia ser o seguinte:

O diagrama descreve o processo de retirada de dinheiro em um caixa eletrônico a partir da interação entre o Consumidor, o Caixa Automático e o Servidor do Banco. Inicialmente, o consumidor insere o cartão no caixa automático, que então valida o cartão com o servidor do banco. Após a validação, o consumidor digita a senha, que é verificada pelo servidor do banco. Se a senha estiver correta, o sistema verifica o saldo da conta. Caso o saldo seja suficiente para a quantidade de dinheiro solicitada, o servidor do banco procede com o débito na conta do consumidor e o caixa automático disponibiliza o dinheiro. Em seguida, o consumidor pode optar por mostrar o saldo restante na tela do caixa automático. Por fim, o consumidor retira o cartão quando o caixa automático o ejeta, concluindo a transação. Se em algum ponto do processo a senha digitada estiver incorreta ou o saldo for insuficiente, o caixa automático não procederá com a retirada do dinheiro e ejeta o cartão, também finalizando a sessão. 

Vamos Exercitar?

Nesta atividade, o você deve desenvolver um diagrama de atividades que represente uma preparação de um bolo, conforme apresentada no início da aula. Na Figura 9, está apresentado uma possível solução para o problema proposto.

Saiba Mais

O livro UML Essencial apresenta no Capítulo 11 os principais conceitos do diagrama de atividades, além de trazer diversos exemplos deste diagrama.  

FOWLER, M. UML essencial. Grupo A, 2011. 

Quer entender mais sobre a UML sobre como aplicar o diagrama de atividades? O livro Utilizando UML e Padrões  traz essas explicações e exemplos no Capítulo 27.

LARMAN, C. Utilizando UML e padrões. 3.ed. – Porto Alegre: Bookman, 2005.

Referências Bibliográficas

FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3.ed. – Porto Alegre: Bookman, 2005.

GUEDES, G. T. A UML 2: uma abordagem prática. 2. ed. - São Paulo: Novatec Editora, 2011.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021. 

Diagrama de classes

Nesta videoaula, adentraremos ao fascinante mundo do paradigma Orientado a Objetos, explorando os elementos fundamentais do Diagrama de classes e exemplos práticos de sua aplicação. Estes conteúdos são essenciais para sua prática profissional na Engenharia de Software, permitindo a modelagem e representação visual das estruturas de dados e relacionamentos entre objetos em um sistema. Ao dominar o Diagrama de classes, você estará preparado para projetar e desenvolver sistemas de software mais robustos e flexíveis. Prepare-se para ampliar seus conhecimentos e habilidades nesta área empolgante! 

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Nesta aula, vamos nos concentrar na introdução ao paradigma orientado a objetos, um pilar fundamental na programação moderna e design de software. Vamos dissecar os elementos do Diagrama de Classes, uma ferramenta essencial da UML que nos ajuda a visualizar a estrutura e o design de um sistema de software.

Abordaremos os conceitos-chave da orientação a objetos, como classes, objetos, atributos, métodos e as relações entre eles, como herança, associação, agregação e composição. Esses conceitos não são apenas teóricos; eles são a base para a criação de código real e funcional que você irá escrever e interagir no seu dia a dia como desenvolvedor.

Ao analisar exemplos práticos de utilização do Diagrama de classes, você começará a ver como esses conceitos se traduzem em aplicações do mundo real. Esta compreensão é crítica, pois permite que você estruture seus projetos de software de maneira lógica e sustentável.

Para colocar em prática o que foi aprendido, desenvolva um diagrama de classes para o seguinte problema: “o sistema de vendas de veículos é projetado para capturar as relações entre carros, clientes, vendas e vendedores. Cada “Carro” é definido por atributos como placa, ano, marca, modelo e origem. Os “Clientes” são identificados por nome, telefone, endereço e CPF. As vendas, representadas pela classe “Venda”, são caracterizadas por um número de venda, data, valor e tipo.  A classe “Venda” é especializada em duas formas de pagamento: “A vista” e “A_prazo”. A venda à vista inclui informações sobre o valor do desconto, o banco e o tipo, enquanto a venda a prazo detalha a quantidade e o valor das parcelas, além de conter um atributo genérico. Cada venda está associada a um único “Cliente” e um “Vendedor”, mas tanto clientes quanto vendedores podem estar ligados a várias vendas. Os vendedores são simplesmente caracterizados por um número e um nome”.

Esta aula é um investimento na sua capacidade de pensar e projetar sistematicamente, uma habilidade que será aplicada em qualquer situação de desenvolvimento de software. Então, vamos mergulhar de cabeça e começar a construir uma base sólida no paradigma orientado a objetos.

Vamos Começar!

Introdução ao paradigma orientado a objetos

Frequentemente, você pode encontrar expressões como "Este é um novo paradigma" ou "A mudança de paradigma fez toda a diferença". Mas afinal, o que é um paradigma?

Um paradigma é considerado como um modelo previamente testado que segue princípios específicos para resolver problemas computacionais. Seguir um modelo traz uma vantagem significativa, pois facilita o desenvolvimento e a compreensão da solução encontrada.

O paradigma orientado a objetos ganhou ampla adoção a partir de 1997 com o surgimento da Linguagem de Modelagem Unificada (UML). No entanto, sua origem remonta a 1966 com a linguagem SIMULA, que introduziu o conceito de objeto. Em seguida, em 1980, a Linguagem Smalltalk 80 expandiu e aprimorou esse conceito, tratando todos os itens como objetos, o que aproximou o paradigma dos objetos físicos do mundo real. Tanto a Smalltalk 80 quanto a SIMULA suportavam recursos de orientação a objetos, como abstração, herança e vinculação dinâmica. Em 1983, surgiu a Linguagem C with Classes, que posteriormente, em 1986, evoluiu para o C++ (FOWLER, 2005).

Com o advento do paradigma orientado a objetos, não apenas emergiu um novo padrão para o desenvolvimento de software, mas também uma nova forma de pensar como modelar os problemas do mundo real.

A orientação a objetos então é um paradigma de programação que organiza o software em torno de objetos e suas interações. Cada objeto é uma instância de uma classe, que define seu comportamento e estrutura. Essas interações entre objetos são realizadas através de trocas de mensagens. Entre os conceitos e princípios básicos de POO (Programação Orientada a Objetos) destacaremos (GUEDES, 2011):

1. A essência do paradigma orientado a objetos reside na abstração. Na prática da abstração, referimo-nos a um objeto (um item do mundo real, como casa, bolo, carro, sanduíche, boleto, contrato, etc.) sem nos preocuparmos com detalhes específicos, como cor, tamanho, código ou validade, entre outros. Frequentemente, associamos a abstração à categorização do objeto. Portanto, o processo de modelagem de um objeto começa pela abstração, que ocorre quando reconhecemos os objetos. Por exemplo, ao ouvir o termo "cadeira", concebemos uma ideia geral do que é uma cadeira, e isso é um ato de abstração.

2. Uma classe representa essa abstração; é o ponto em que se definem as características que todas as cadeiras devem possuir e as ações que elas podem realizar.

3. As características técnicas dentro de uma classe são denominadas atributos, enquanto as ações ou comportamentos são chamados de métodos. Dessa forma, nossa concepção de uma cadeira se materializa quando criamos a classe "Cadeira" e especificamos seus atributos, por exemplo: a classe "Cadeira" pode ter atributos como pés, rodinhas, encosto, assento e cor. Além disso, ela pode executar ações como mover o encosto, elevar o assento e deslocar-se. Essas ações são seus métodos. Em relação à classe, ela é conceitualmente abstrata, mas se torna uma definição do projeto de uma cadeira. Quando uma cadeira é instanciada a partir dessa classe, obtemos um objeto do tipo "Cadeira", ou seja, um objeto que segue as características e comportamentos definidos pela classe "Cadeira".

4. O objeto é a representação concreta e única de uma classe, e a essa representação específica damos o nome de instância da classe. Portanto, um objeto é uma instância única de uma classe. Embora pertençam à mesma classe, os objetos são distintos uns dos outros devido aos valores de seus atributos e comportamentos (ações).

5. Dessa forma, uma classe é a abstração de um conjunto de objetos; em outras palavras, é a representação abstrata do objeto com seus atributos e comportamentos. Ao criarmos uma cadeira chamada "cadeiraCinza" a partir da classe "Cadeira" definida no item (3), obtemos um objeto do tipo "Cadeira" com cor cinza, rodinhas, pés, encosto e assento, capaz de mover o encosto e deslocar-se. A cadeiraCinza é única. Em um programa, a classe "Cadeira" existe e, ao instanciarmos a "cadeiraCinza" a partir dessa classe, ela ocupará um espaço na memória do computador, onde serão armazenados seus atributos e métodos, além de receber um endereço único que a identifica. Em resumo, o objeto é a realização concreta de um exemplar do tipo de classe que o define.

Em UML, utiliza-se uma representação simples para representar uma classe. Um retângulo, dividido em três partes: nome da classe, atributos e métodos.

6. A herança permite criar classes a partir de classes já existentes, sem duplicar nenhum código. Durante o processo de abstração, podemos definir classes amplas, que serão refinadas e estendidas durante a modelagem para formar subclasses. Essas subclasses podem herdar as características e comportamentos da classe mais geral, conhecida como superclasse. Por sua vez, a classe que herda essas características é denominada subclasse, como ilustrado na Figura 1.

É importante destacar que a subclasse pode adicionar novos atributos e comportamentos, além de modificar os existentes, pois ela é uma nova entidade. Tais modificações afetam exclusivamente a nova classe especificada.

Retomando o exemplo da classe "Cadeira", poderíamos criar uma classe genérica "Cadeira" contendo apenas os atributos "encosto", "assento" e "pés" – esta seria nossa superclasse, ou classe pai. Em seguida, aproveitando as características dessa superclasse "Cadeira", poderíamos construir uma nova classe "CadeiraGiratória", acrescentando a ela o atributo "rodas" e os métodos "andar", "girar" e "mover assento". Para indicar que a classe "CadeiraGiratória" herda as características da classe "Cadeira", usamos uma seta com a ponta vazada apontando para a classe "CadeiraGiratória", conforme mostrado na Figura 4.1. A classe "CadeiraGiratória" é uma subclasse da classe "Cadeira", também conhecida como classe filha.

Outro exemplo de herança apresentado na Figura 1 é a classe "CadeiraExecutiva", que herda as características da classe "Cadeira" e adiciona o atributo "braço" e o método "balanço".

7. O encapsulamento é a prática de unir partes isoladas de um programa, permitindo que essas partes sejam acessadas separadamente. Na Programação Orientada a Objetos (POO), o encapsulamento tem a capacidade de ocultar ou restringir a visibilidade das informações e os detalhes da implementação dos métodos de uma classe. Em outras palavras, ele esconde do usuário da classe como uma determinada ação é realizada ou como os dados são representados. É o processo de dissimulação de todos os detalhes de um objeto que não contribuem para suas características essenciais (WERLICH, 2020).

Um exemplo prático do conceito de encapsulamento pode ser observado ao utilizar um caixa eletrônico (um objeto). Você simplesmente fornece sua identificação e senha para acesso, e os serviços são liberados para utilização. Você não precisa entender como o caixa eletrônico valida suas informações, onde elas estão armazenadas ou como a senha é descriptografada. Isso exemplifica o encapsulamento, no qual o usuário interage com o objeto sem precisar compreender os processos internos.

No diagrama de classe, usamos o símbolo "-" (um traço) para indicar que o atributo ou o método está encapsulado. Isso significa que somente o objeto da classe pode modificá-los ou acessá-los. Por outro lado, o símbolo "+" (adição) indica que o atributo ou método é visível para outros objetos, ou seja, é público. Um exemplo desse diagrama pode ser observado na Figura 1.

8. O polimorfismo significa que a mesma operação [método] pode atuar de modos diversos em classes diferentes. Essa característica da Programação Orientada a Objetos (POO) confere flexibilidade às classes na construção de soluções e no reuso do código. Dentro de uma classe, um método (ou operação) pode ser definido várias vezes, pois pode ter comportamentos distintos nas subclasses.

Agora que você está familiarizado com os principais conceitos e princípios da POO, será mais fácil perceber as vantagens desse paradigma, pois ele abrange a análise, o projeto e a implementação.

A POO aplica os conceitos da Orientação a Objetos (OO) no desenvolvimento do código. Por outro lado, a Análise e Projeto Orientados a Objetos (A/POO) aplicam os conceitos da OO na análise e na elaboração do projeto, etapas que precedem a programação. Durante a análise, um instrumento utilizado é o caso de uso, enquanto no projeto é empregada a UML (Linguagem de Modelagem Unificada). Segundo Sommerville (2018), um projeto que adote o paradigma orientado a objetos deve empregar essa estratégia em todo o seu processo de desenvolvimento, observando as práticas tanto no projeto quanto na programação.

Dessa forma, podemos elencar as seguintes vantagens da Orientação a Objetos:

• Reutilização de código.
• Utilização de um único modelo conceitual para análise, projeto e implementação.
• Aceleração do tempo de desenvolvimento do software.
• Simplificação da construção de sistemas complexos, pois cada objeto é simples, fácil de testar e integrar com outros objetos. Isso prolonga o ciclo de vida do software, já que as horas dedicadas ao desenvolvimento são gastas principalmente em manutenção e adição de novas funcionalidades. O conceito de objeto e sua interação simplificam a implementação de novos recursos, aumentando assim a longevidade das aplicações.
• Potencial redução dos custos de desenvolvimento.

Por outro lado, as desvantagens do paradigma orientado a objetos são relativamente poucas:

• Exige desenvolvedores familiarizados com esse paradigma.
• A modelagem requer maior atenção em comparação com a análise estruturada.
• Necessita de uma documentação minuciosa e detalhada.

Siga em Frente...

Elementos do diagrama de classes

O diagrama de classes é uma das ferramentas mais importantes e amplamente utilizadas na Linguagem de Modelagem Unificada (UML). Seu foco principal é possibilitar a visualização das classes que compõem o sistema, juntamente com seus atributos e métodos correspondentes. Além disso, o diagrama destaca as relações entre essas classes, mostrando como elas se complementam e trocam informações entre si. Este diagrama oferece uma visão estática da organização das classes, concentrando-se na definição da estrutura lógica das mesmas. Também serve como base para a construção de muitos outros diagramas na UML. Essencialmente, o diagrama de classes é composto pelas próprias classes e pelas associações que existem entre elas, ou seja, pelos relacionamentos entre as classes.

Alguns métodos de desenvolvimento de software, como o Processo Unificado, recomendam o uso do diagrama de classes desde a fase de análise. Nesta etapa, um modelo conceitual é elaborado para representar as informações necessárias ao software. Neste modelo, o foco está em retratar apenas as informações que o software precisará, incluindo classes, seus atributos e as associações entre elas (PRESSMAN, 2021). Detalhes como os métodos que as classes irão conter não são modelados nesta fase, pois fazem parte da implementação do software. Somente na fase de projeto é que o modelo conceitual do diagrama de classes é utilizado para produzir o modelo de domínio, que aborda diretamente a solução do problema. Os métodos necessários às classes são identificados a partir da modelagem de diagramas de interação, como o diagrama de sequência, que será abordado nos próximos capítulos.

A representação da classe é um retângulo dividido em três partes: o nome da classe; os atributos e; os métodos, como mostra a Figura 2.

Os estereótipos são um recurso de extensibilidade amplamente empregado na UML, especialmente nos diagramas de classes. Sua finalidade é categorizar elementos do diagrama que compartilham características semelhantes. Os estereótipos podem ser definidos pelo desenvolvedor ou já estar predefinidos na linguagem. A UML possui 50 estereótipos predefinidos, conforme a especificação OMG® (2017), sendo que três dos mais comuns são (GUEDES, 2011):

• <<entity>>: identifica classes de persistência, responsáveis por armazenar dados recebidos pelo sistema. Além da notação textual, <<entity>> pode ser representada graficamente por um símbolo, como a classe "Produto" na Figura 3.
• <<boundary>>: identifica uma classe de fronteira, que atua na comunicação entre atores externos e o sistema. Sua representação gráfica pode ser vista na Figura 3 pela interface "Sistema_da_Loja".
• <<control>>: representa classes responsáveis por implementar regras de negócio. Na Figura 3, é exemplificado pela classe "controlador_Sistema_da_Loja".

As classes estabelecem diferentes tipos de relacionamentos entre si, conforme especificado na UML (GUEDES, 2011):

1. Dependência: este é o tipo de relacionamento mais fraco, representando uma relação semântica entre duas classes. Uma alteração na classe independente pode afetar a classe dependente. Por exemplo, na Figura 3, há uma dependência entre as classes "Produto" e "Receita". Embora existam independentemente, uma mudança na classe "Receita" pode impactar a classe "Produto".
2. Associação: este é o tipo mais comum de relacionamento, indicando que a classe A tem algum tipo de relação com a classe B. É um relacionamento genérico.
3. Agregação: este tipo de relacionamento é mais específico, onde a classe filha pode existir independentemente da classe pai. Na Figura 3, por exemplo, há uma agregação entre a classe "Produto" (pai) e a classe "Cobertura" (filha). Isso significa que, se um objeto do tipo "Produto" deixar de existir, o objeto do tipo "Cobertura" continuará a existir.
4. Composição: este é um tipo específico de associação em que, se o objeto da classe pai for destruído, não faz sentido a existência do outro objeto associado à classe filha. Por exemplo, entre as classes "Pedido" e "Item_de_Pedido", temos um relacionamento de composição, onde os "Itens_de_Pedido" são partes integrantes do "Pedido". Se excluirmos o "Pedido", os "Itens_de_Pedido" também devem ser excluídos. Este relacionamento é representado na Figura 3
5. Generalização/especialização: indica que a classe filha herda as características da classe pai, também conhecida como especialização da classe. As classes Revendedor e Varejo são classes filhas da classe Cliente, conforme mostrado na Figura 3.
6. Multiplicidade: indica quantas instâncias dos objetos estão envolvidos na associação, como está mostrado na Figura 3.

Exemplo de utilização do diagrama

Para exemplificar e explicar os elementos de um diagrama de classes, analise a Figura 4, que apresenta uma modelagem de um sistema de pedidos.

O diagrama de classes apresentado descreve um sistema de pedidos com foco na interação entre clientes, pedidos e formas de pagamento. No sistema, cada “Cliente”, identificado por nome e endereço, pode fazer vários “Pedidos”. Cada “Pedido” tem uma data, um status e está associado a um ou mais “Detalhes do pedido”, que descrevem a quantidade de itens pedidos e o status fiscal. Os pedidos têm métodos para calcular peso, impostos e o total do pedido.

Para realizar o pagamento de um pedido, são oferecidas múltiplas formas de pagamento, representadas pela classe “Pagamento”, que é uma classe generalizada para “Dinheiro”, “Cartão de crédito” e “Cheque”. O pagamento em “Dinheiro” é simples, tendo apenas o valor como atributo. O “Cartão de crédito” inclui detalhes como número, tipo, data de expiração e código de segurança, e possui uma operação para verificar se a transação está autorizada. Da mesma forma, “Cheque” tem atributos para nome e banco e uma operação para validação. O diagrama ilustra como diferentes formas de pagamento são integradas ao processo de finalização de pedidos no sistema. 

Vamos Exercitar?

Este diagrama destaca a estrutura de dados que fundamenta o sistema de vendas veículos, conforme apresentado no início da aula, que permite que desenvolvedores e analistas compreendam as relações e atributos necessários para implementar as funcionalidades desejadas no sistema de gerenciamento de vendas de veículos.

Saiba Mais

O Capítulo 6 do livro Análise e Design Orientados a Objetos para Sistemas de Informação apresenta os fundamentos dos diagramas de classes e relaciona isso com exemplos em programação.

WAZLAWICK, R. S. Análise e Design Orientados a Objetos para Sistemas de Informação: Modelagem com UML, OCL e IFML. Grupo GEN, 2014.

O livro UML Essencial apresenta os principais conceitos do diagrama de classes no Capítulo 5.

FOWLER, M. UML essencial. 3.ed. – Porto Alegre: Bookman, 2005.

Quer entender mais sobre o diagrama de classes? O livro Utilizando UML e Padrões traz esses padrões de maneira clara e simplificada no Capítulo 16.

LARMAN, C. Utilizando UML e padrões. Grupo A, 2011. 

Referências Bibliográficas

FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3.ed. – Porto Alegre: Bookman, 2005.

GUEDES, G. T. A UML 2: uma abordagem prática. 2. ed. -- São Paulo: Novatec Editora, 2011.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

WERLICH, C. Análise e modelagem de sistemas. Londrina: Editora e Distribuidora Educacional S.A., 2020. 

Videoaula de Encerramento

Nesta videoaula, exploraremos os princípios da UML, com foco nos Diagramas de Casos de Uso e Atividades. Além disso, abordaremos a Modelagem de Sistemas e o Diagrama de Classes. Esses conteúdos são cruciais para a prática profissional, permitindo a visualização, análise e comunicação eficaz dos sistemas. Dominar essas técnicas de modelagem capacita os profissionais a projetar e desenvolver sistemas de alta qualidade. Prepare-se para aprofundar seus conhecimentos e habilidades!

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Chegada

Olá, estudante! Para desenvolver a competência desta Unidade, que é elaborar diagramas de acordo com as especificações da UML, você deverá primeiramente conhecer os conceitos fundamentais da Linguagem de Modelagem Unificada, conhecida como UML. Esta é uma linguagem visual que se tornou padrão na indústria de engenharia de software para modelar sistemas baseados em orientação a objetos. Diferentemente de uma linguagem de programação, a UML é uma notação para auxiliar engenheiros de software a definir as características do sistema, abrangendo desde requisitos até aspectos físicos do hardware onde o sistema será implantado. A UML é flexível, podendo ser adaptada a diversos processos de desenvolvimento de software, conforme a preferência do engenheiro (FOWLER, 2005).

Modelar software é essencial devido à sua complexidade e à constante evolução dos sistemas de informação. A modelagem não se limita à documentação, mas também oferece vantagens como facilitar a compreensão do sistema, estimar custos e identificar mudanças necessárias ao longo do tempo. Um modelo de software representa uma perspectiva abstrata do sistema, detalhando aspectos estruturais e comportamentais conforme o propósito do modelo, seja identificar requisitos essenciais, definir classes ou especificar métodos para resolver problemas.

A UML 2.5.1 oferece uma variedade de diagramas para modelagem de software, divididos em estruturais e comportamentais, permitindo aos desenvolvedores representarem e comunicarem diferentes aspectos dos sistemas de software (PRESSMAN, 2021). Embora não haja uma ordem prescrita para a criação e utilização dos diagramas, geralmente eles seguem uma sequência didática, começando pelos mais simples, como os diagramas estruturais, e avançando para os comportamentais, incluindo os de interação, para facilitar o processo de modelagem e compreensão do sistema.

Os diagramas estruturais da UML revelam a organização e interconexões de um sistema em suas partes constituintes. Eles fornecem uma visão estática da estrutura do sistema e são fundamentais na fase inicial do projeto de arquitetura. Entre os seis tipos de diagramas estruturais, o diagrama de classes se destaca como um dos mais essenciais, delineando atributos, métodos e relacionamentos entre as classes. Outros diagramas, como o de pacotes, componentes e instalação, oferecem representações específicas das partes do sistema, incluindo subsistemas, componentes de código e requisitos de hardware e software.

Os diagramas estruturais da UML, como o de classes, pacotes, componentes e instalação, entre outros, proporcionam uma visão estática e detalhada da organização e interconexões de um sistema, sendo cruciais na fase inicial do projeto de arquitetura. Enquanto o diagrama de classes delineia as características e relacionamentos das classes do sistema, o diagrama de componentes visualiza os módulos de código-fonte e bibliotecas. Já o diagrama de instalação descreve a configuração necessária de hardware e software para a execução do sistema, oferecendo uma visão abrangente da infraestrutura necessária (FOWLER, 2005).

Já os diagramas comportamentais da UML visam representar o fluxo de informações e eventos ao longo do tempo em um sistema, evidenciando o comportamento dinâmico dos objetos e suas respostas a ações específicas ou eventos. Dentro desse conjunto, os diagramas de interação, como o diagrama de sequência e o diagrama de comunicação, modelam interações dentro do sistema ou entre seus componentes, enquanto o diagrama de casos de uso destaca os atores e as funcionalidades do sistema de forma mais abrangente e informal, servindo como base para outros diagramas (GUEDES, 2011).

Esses tipos de diagramas oferecem uma visão dinâmica do sistema, incluindo representações detalhadas das interações e do fluxo de controle durante a execução de atividades. Enquanto o diagrama de atividade descreve os passos necessários para concluir uma atividade específica, o diagrama de máquina de estados ilustra o comportamento de um elemento através de transições de estado. Além disso, o diagrama de tempo destaca a evolução do estado de uma instância ao longo do tempo em resposta a eventos externos, fornecendo uma compreensão mais abrangente do comportamento do sistema.

Outro ponto importante para alcançar a competência da unidade é conhecer e saber aplicar o diagrama de casos de uso. Esse diagrama é uma ferramenta fundamental para compreender as funcionalidades do sistema de forma abstrata e acessível, destacando a perspectiva do usuário e simplificando a compreensão do comportamento externo do sistema. Ele é amplamente utilizado nas fases iniciais de modelagem do sistema, especialmente durante o levantamento e análise de requisitos, servindo como base para outros diagramas ao longo do processo de engenharia. Ao oferecer uma visão panorâmica das funcionalidades desejadas pelos usuários sem entrar em detalhes de implementação, o diagrama de casos de uso ajuda a identificar, especificar e documentar os requisitos do sistema, além de auxiliar na identificação dos diferentes tipos de usuários e suas interações com o sistema.

O diagrama de casos de uso da UML é composto por elementos essenciais que capturam os requisitos e interações do sistema. Os atores representam os papéis desempenhados pelos usuários e entidades externas que interagem com o sistema, enquanto os casos de uso descrevem as funcionalidades ou serviços que o sistema oferece aos atores. Os atores podem ser usuários comuns, hardware especializado ou outros sistemas integrados, representados por símbolos de "bonecos magros" no diagrama (GUEDES, 2011). Os casos de uso, por sua vez, identificam e documentam as diferentes atividades essenciais do sistema, divididos em primários e secundários, e representados por elipses com uma descrição concisa dentro.

Além dos atores e casos de uso, as associações são fundamentais para representar as interações no diagrama de casos de uso. Essas associações incluem relacionamentos de inclusão, extensão e generalização/especialização. A inclusão é usada para descrever rotinas comuns a múltiplos casos de uso, evitando a redundância na documentação, enquanto a extensão trata de cenários opcionais que ocorrem sob circunstâncias específicas. A generalização/especialização relaciona casos de uso genéricos a casos de uso especializados, permitindo herdar características comuns e associações entre eles.

Outro diagrama importante da UML é o diagrama de atividades. Este diagrama anteriormente era considerado uma variação do diagrama de gráfico de estados. O diagrama de atividade na UML foi promovido à sua própria categoria a partir da versão 2.0, deixando de se basear em máquinas de estados para se fundamentar em redes de Petri. Esse diagrama destaca-se por sua ênfase na sequência e nas condições para coordenar comportamentos de baixo nível, tornando-se um dos mais detalhados e focados em nível de algoritmo na UML (PRESSMAN, 2021). Comumente associado aos antigos fluxogramas, o diagrama de atividade é utilizado para modelar atividades que podem variar de métodos e algoritmos a processos completos, sendo aplicável tanto para computação procedural quanto para modelagem organizacional e sistemas de informação.

Cada atividade, que pode ser um método, algoritmo ou processo, é composta por um conjunto de ações representando os passos necessários para sua conclusão. Embora uma atividade deva conter ações, estas não precisam estar todas representadas dentro da própria atividade no diagrama, permitindo referências a atividades já modeladas ou economia de espaço. Além disso, o diagrama de atividade é capaz de modelar dois tipos de fluxo: o de controle, que descreve a ordem das ações, e o de objetos, que representa como os objetos são passados entre as ações durante a execução da atividade.

A criação dos diagramas de atividades geralmente segue uma abordagem de cima para baixo e envolve vários elementos principais, incluindo estados iniciais e finais, atividades, nós de ação, fluxo de controle, nós de decisão, forks, joins, e swimlanes. Os estados iniciais e finais marcam o início e o término do fluxo de uma atividade, representados por símbolos específicos. As atividades representam as etapas ou processos no diagrama, enquanto os nós de ação são os elementos fundamentais dentro de uma atividade, cada um representando uma etapa a ser executada. O fluxo de controle é estabelecido por conexões entre os nós, indicando a ordem de execução das ações, podendo conter descrições ou condições (GUEDES, 2011).

Os nós de decisão são utilizados para escolher entre diferentes caminhos de fluxo, com base em condições especificadas, e podem também ser usados para reunir fluxos divergentes. Forks indicam a separação de atividades em múltiplos fluxos concorrentes, enquanto joins sincronizam esses fluxos, garantindo que a execução prossiga somente quando todos os caminhos concorrentes forem completados. As swimlanes, por sua vez, são divisões horizontais ou verticais que ajudam a visualizar a responsabilidade e a interação entre diferentes participantes ou entidades envolvidas em um processo, tornando mais clara a compreensão das interações e fluxos de informação. Esses elementos combinados proporcionam uma representação detalhada e compreensível do comportamento e da lógica de um processo ou sistema.

O diagrama mais utilizado da UML é o diagrama de classes. Para compreender esse diagrama é indispensável conhecer o paradigma orientado a objetos. Um paradigma é um modelo testado que segue princípios específicos para resolver problemas computacionais, simplificando o desenvolvimento e a compreensão das soluções encontradas. O paradigma orientado a objetos, amplamente adotado desde o surgimento da UML em 1997, organiza o software em torno de objetos e suas interações, cada objeto sendo uma instância de uma classe que define sua estrutura e comportamento. A abstração, a herança, o encapsulamento e o polimorfismo são conceitos fundamentais desse paradigma, proporcionando uma nova maneira de abordar problemas do mundo real e facilitando o desenvolvimento de software.

Na Programação Orientada a Objetos (POO), a abstração é essencial, representada por classes que definem características e comportamentos de objetos, enquanto o encapsulamento oculta detalhes de implementação, permitindo que partes isoladas do programa sejam acessadas separadamente. A herança possibilita a criação de classes a partir de outras já existentes, enquanto o polimorfismo confere flexibilidade às classes ao permitir que uma mesma operação tenha comportamentos distintos em diferentes classes. Adotar o paradigma orientado a objetos não só estabelece um novo padrão para o desenvolvimento de software, mas também muda a forma como problemas são modelados, abrangendo análise, projeto e implementação de maneira integrada, embora exija atenção à modelagem e documentação detalhada.

O diagrama de classes na UML é uma ferramenta essencial para visualizar a estrutura estática de um sistema de software, destacando as classes, seus atributos e métodos, bem como as relações entre elas. Utilizado desde a fase de análise até o projeto, o diagrama de classes concentra-se na representação conceitual das informações necessárias ao software, sendo a base para a construção de outros diagramas na UML. As classes são representadas por retângulos divididos em três partes: nome da classe, atributos e métodos, enquanto os relacionamentos entre classes, como dependência, associação, agregação, composição e herança, são definidos para mostrar como as classes interagem entre si.

Além disso, os estereótipos são amplamente empregados para categorizar elementos do diagrama de classes, como classes de persistência, fronteira e controle. Os tipos de relacionamentos entre as classes, como dependência, associação, agregação, composição, generalização/especialização e multiplicidade, são especificados para indicar a natureza das interações entre as classes. Por meio desses elementos e relacionamentos, o diagrama de classes oferece uma representação clara e abrangente da estrutura e das interações do sistema de software, facilitando o desenvolvimento e a compreensão do software durante todo o ciclo de vida do projeto (GUEDES, 2011).

A compreensão e aplicação da Linguagem de Modelagem Unificada (UML) e seus diagramas, como casos de uso, atividades e classes, é fundamental para o desenvolvimento eficaz e eficiente de software. Essas ferramentas oferecem uma representação visual clara e concisa dos requisitos do sistema, das interações entre os usuários e o software, das atividades necessárias para alcançar determinados objetivos e da estrutura lógica do software em si. Ao aplicar adequadamente os conceitos e técnicas da UML, os desenvolvedores podem comunicar de forma mais eficaz as necessidades do cliente, planejar e projetar sistemas de software de maneira abrangente e construir soluções que atendam às expectativas e requisitos do usuário final. 

É Hora de Praticar!

Os diagramas de casos de uso são uma ferramenta essencial na modelagem de sistemas, pois ajudam a capturar os requisitos do sistema de forma clara e concisa. Eles descrevem como os usuários interagem com o sistema em diferentes cenários, identificando suas necessidades e objetivos. Sabendo disso, leia o enunciado a seguir e elabore um diagrama de casos de uso.

O diagrama de casos que será desenvolvido deve ilustrar o fluxo de operações em um sistema de gerenciamento de vendas. O sistema envolve três atores principais: Gerente Comercial, Gerente e Vendedor, cada um com responsabilidades específicas e interações com o sistema de contabilidade. O objetivo do sistema é facilitar e registrar as atividades comerciais, garantindo que os processos de negócio sejam conduzidos de maneira eficiente e controlada.

O Gerente Comercial é responsável por “Estabelecer Limites” para as operações de vendas, assegurando que haja um controle sobre as margens comerciais e os riscos associados. Ele também desempenha a função de “Analisar Riscos” para avaliar potenciais problemas que possam afetar as transações comerciais.

O gerente tem a tarefa de “Fechar Preço” nas negociações, o que é um passo crítico no processo de venda. Esta ação inclui a avaliação do negócio de modo obrigatório.

O Vendedor é o ator que realiza a “Atualização de Contas” no Sistema de Contabilidade e também “Registrar Negócio”, o que indica que o vendedor interage diretamente com o sistema para garantir que todas as informações de vendas sejam devidamente documentadas e contabilizadas.

O Sistema de Contabilidade é um ator secundário que serve como um repositório para registrar as transações e manter as contas atualizadas. Este sistema é essencial para manter a integridade dos dados financeiros e para o funcionamento geral do processo de vendas.

Reflita

• Considerando o investimento significativo de tempo e recursos que as empresas dedicam à modelagem de software, como você avalia o papel da UML nesse processo?
• É possível que a complexidade inerente à UML possa, em certos contextos, aumentar a carga de trabalho ao invés de simplificá-la?
• Qual é a importância de selecionar os diagramas adequados da UML durante o processo de desenvolvimento de software?
• Como as empresas podem tomar decisões informadas ao escolher os diagramas mais apropriados para seus projetos específicos, levando em consideração as necessidades do cliente, a complexidade do sistema e os recursos disponíveis?

Dê o Play!

Clique aqui para acessar os slides do Dê o play!

Resolução do estudo de caso

Uma possível solução para o exercício está apresentada a seguir:

Dê o play!

Assimile

Desvende a essência da modelagem de sistemas com a UML. Este infográfico apresenta a descrição dos diagramas de casos de uso, a dinâmica dos processos com diagramas de atividades, e a estrutura sólida do sistema com diagramas de classes.

Referências

GUEDES, G. T. A. UML 2: uma abordagem prática. 2. ed. - São Paulo: Novatec Editora, 2011.

FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3.ed. – Porto Alegre: Bookman, 2005.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.