Modelagem de sistemas com UML

Prévia do material em texto

UML: Linguagem unificada de modelagem
É a criação de modelos na forma de diagramas, com representação dos requisitos e
das soluções de análise e projeto de sistemas de qualquer porte e finalidade.
O que são modelos e para que eles servem:
A maquete é uma representação, em miniatura, do condomínio real. É um modelo do
empreendimento real. Ou seja, o empreendimento real será construído à imagem e
semelhança da maquete construída.
A primeira finalidade de um modelo é: antecipar a existência de uma realidade para
avaliar sua estrutura e seu comportamento.
Protótipos são usados para aumentar a chance de sucesso dos produtos. A partir de
um protótipo inicial, outros modelos podem ser demandados e aprimoramentos podem
ser desenvolvidos. Os setores automobilísticos e o de desenvolvimento de sistemas
usam com eficácia protótipos como modelos.
Modelo: representação abstrata e simplificada da realidade.
Uma realidade pode demandar diferentes modelos, dependendo da perspectiva com
que precise ser observada.
Finalidade principal: antecipar a existência de uma realidade de forma a avaliar sua
estrutura e comportamento.
Os modelos, funcionam também como instrumento de gerenciamento da
complexidade, considerando a limitação humana em lidar com ela. Os sistemas
grandes e complexos carecem de ser modelados para sua melhor compreensão em
sua totalidade.
Modelos são capazes de revelar as propriedades essenciais de um sistema, ajudando
no processo de abstração (concentração nos pontos de interesse) e permitindo que
foquem no que é relevante.
Dentre os benefícios que podemos citar para o uso de modelos em desenvolvimento
de sistemas computacionais, destacam-se:
- Comunicação entre pessoas envolvidas: o modelo serve como elemento de
comunicação ou difusão de informações entre as pessoas envolvidas em sua
construção.
- Redução nos custos do desenvolvimento: a construção de modelos é bem mais
barata que a construção do sistema em si. A descoberta de erros e falhas em
modelos é bem menos onerosa e contribui para a redução dos custos finais do
sistema computacional. Isso também vale para as eventuais necessidades de
ajustes e melhorias no sistema.
- Facilidade para alterações do sistema: depois de pronto, seja ainda na fase de
construção ou de manutenção, os sistemas carecem de ajustes e melhorias. A
análise dessas melhorias tende a ser mais efetiva quando elaborada sobre os
modelos construídos, aumentando a assertividade e diminuindo seus custos.
Daí a relevância e a necessidade de manter os modelos sempre atualizados.
- Documentação do sistema: os modelos servem de consulta e orientação a toda
equipe na construção e na manutenção do sistema. Servem ainda para
documentar as decisões tomadas.
- Delimitar o escopo do sistema: a modelagem ajuda na delimitação do escopo,
ou seja, abrangência do sistema, definido o que será ou não tratado pelo
sistema.
Modelagem de sistemas
Formas de abordar os sistemas computacionais:
- Construir modelos que representam os dados, as funcionalidades, e os
controles, cada um focando em uma perspectiva diferente.
- Visão externa do usuário que e modela-se o ambiente em que o sistema está
inserido, mostrando sua relação com o usuário e demais sistemas com que
interage.
- Comportamental: modela-se o comportamento dinâmico do sistema e como ele
reage aos eventos que o afetam.
- Estrutural: modela-se sua estrutura organizacional ou os dados que o sistema
processa.
- Interação: modela-se as interações de seus componentes ou ainda do sistema e
seu ambiente externo.
A construção dos diferentes modelos para um sistema compreende o que
denominamos de Modelagem de sistemas, onde:
● Os modelos abstratos, deixando de lado os detalhes e concentrando-se nos
aspectos de interesse que são relevantes. A esse processo chamamos de
abstração.
● Cada modelo apresenta o sistema sob uma diferente visão ou perspectiva da
realidade.
● Os modelos são descritos em notações gráficas, que denominamos de
diagramas.
Modelagem de sistema de sistema de software consiste na utilização de notações
gráficas e textuais com o objetivo de construir modelos que representam as partes
essenciais de um sistema, considerando-se várias perspectivas diferentes e
complementares.
A UML permite a construção de modelos, na forma de diagramas, sob diferentes
visões ou perspectivas que, em conjunto, integram a solução de modelagem do
sistema quando desenvolvido usando o paradigma orientado a objetos.
O processo de desenvolvimento de sistemas em fases
- O conhecimento sobre o sistema aumenta, diminuindo, consequentemente, o
nível de abstração da realidade.
- O principal recurso de um sistema são pessoas, profissionais capacitados.
Num primeiro momento, precisamos compreender com muita clareza as necessidades
das pessoas que são usuárias do sistema, o que elas precisam que o sistema faça
para que possam cumprir suas funções.
Esse entendimento passa, também, pela necessidade da confirmação dessa
compreensão pelas pessoas que estão construindo o sistema (os profissionais
especializados).
Os modelos são, portanto, uma representação simplificada da realidade,
representando os elementos de interesse naquele momento, permitindo abstrair o que
não interessa e concentrar naquilo que de fato é relevante para o desenvolvimento do
sistema.
Cada processo da metodologia se tem as seguintes fases:
Identificação dos requisitos: requisitos podem ser entendidos como as
necessidades que os usuários têm e que devem estar contidos nas
funcionalidades e propriedades do sistema a ser construído.
Análise: com base nos requisitos, compreende-se o que o sistema deve fazer em
prol de seus usuários.
Projeto: compreende a adequação dos requisitos e como eles serão
implementados, usando a tecnologia adequada para tal, definindo sua arquitetura e
seus componentes. Define-se ainda toda a infraestrutura do ambiente computacional
que será usada na construção do sistema, como: redes de computadores, banco de
dados, linguagem de programação, dentre outros elementos.
Implementação: diz respeito à identificação dos programas necessários e sua
codificação na linguagem de programação selecionada na fase de projeto, bem como o
banco de dados que será usado.
Modelos como elementos de comunicação
Os elementos de comunicação no processo de desenvolvimento de sistemas, ajudam:
- no entendimento e na validação dos modelos juntos aos usuários.
- no entendimento do sistema por membros da equipe de desenvolvimento.
Assim, a equipe faz o levantamento de dados junto aos usuários, compreendendo a
realidade e a necessidade. Os dados levantados são registrados e usados na
construção de modelos. Esse momento acontece com mais intensidade na fase de
requisitos, mas também se faz presente nas fases de análise e de projeto.
Após a equipe constrói modelos que julgam como pertinentes para que se possa
compreender e destacar os aspectos relevantes da realidade.
E por último, a equipe vai validando os dados junto aos usuários, esse momento
acontece nas fases de requisitos, análise e projeto.
Paradigma orientado a objetos
- maneira de abordar um problema
A orientação a objetos tem como propriedade como abstração, encapsulamento,
herança e polimorfismo - maior organização, reaproveitamento e extensibilidade de
código e, consequentemente, programas mais fáceis de serem escritos e mantidos.
O principal foco do paradigma orientado a objetos é permitir o desenvolvimento de
sistemas de forma mais rápida e confiável.
Alan Kay imaginou um sistema como um conjunto de agentes autônomos, os objetos
que interagem entre si.
Ele definiu os princípios centrais da orientação a objetos:
- Qualquer coisa do mundo real é um objeto.
- Objetos realizam tarefas requisitando serviços a outros objetos.
- Os objetos similares são agrupados em classes e cada objeto pertence a uma
classe.
- A classe determina o comportamento possível a um objeto.
- As classes são organizadas em hierarquias.
O paradigma da orientação a objetos visualiza um sistema de software como uma
coleção de agentesinterconectados chamados objetos. Cada um deles é responsável
por realizar tarefas específicas e, para cumprir com algumas das tarefas sob sua
responsabilidade, um objeto pode ter que interagir com outros. É pela interação entre
eles que uma tarefa computacional é executada. Um sistema de software orientado a
objetos consiste, portanto, em objetos colaborando para realizar as funcionalidades
desse sistema. É graças à cooperação entre os objetos que a computação do sistema
se desenvolve.
Conceitos fundamentais da orientação a objetos
- A orientação a objetos enfatiza a identificação, a representação e a organização
dos objetos necessários ao funcionamento de um sistema.
- Tem por base os conceitos de objetos, classes, operação, mensagem e estado,
e está formada em quatro pilares fundamentais: abstração, encapsulamento, herança e
polimorfismo, discutidos na sequência.
Objetos e classes
Um objeto pode referenciar qualquer coisa do mundo real: um aluno, uma
disciplina, um professor, um curso, entre outros, considerando um sistema acadêmico
como contexto. Ou seja, um objeto é qualquer coisa do mundo real, de interesse no
contexto em estudo.
Quando observamos um objeto, nós não nos preocupamos só com um e sim com
todos.
Temos uma classe que agrupa objetos com as mesmas características ou
propriedades, que são seus dados (atributos) e seus procedimentos (métodos) que
implementam os serviços que essa classe vai prestar.
Um objeto é um elemento específico de uma classe, ou ainda uma instância de
uma classe.
As classes são, portanto, abstrações que definem uma estrutura que encapsula dados
(chamados de atributos) e um conjunto de operações possíveis de serem usados,
chamados métodos.
Por exemplo, a classe ALUNO encapsula um conjunto de dados que identifique os
alunos − matrícula, nome, endereço (rua, número, complemento, estado e CEP), CPF
e Identidade − e um conjunto de métodos: Incluir Aluno, Matricular Aluno, Cancelar
Matrícula, dentre outros.
Classe: abstração das características de um grupo de coisas do mundo real.
Objeto: um elemento específico de uma classe ou uma instância de uma classe.
A seguir, temos a representação de uma classe em três compartimentos: o nome da
classe (ALUNO), seus atributos (Matrícula... Identidade) e métodos (Incluir Aluno...
Cancelar Matrícula).
Operação, mensagem e estado
Um sistema que é orientado a objetos consiste na cooperação entre seus objetos.
Cada um tem uma responsabilidade no sistema, correspondendo à parte das
funcionalidades que lhes são atribuídas. Em outras palavras, uma tarefa computacional
é realizada pela interação entre seus objetos, cada um executa uma parte da tarefa.
Operação > é o nome dado a cada ação (função) que o objeto sabe realizar. Mas um
objeto não realiza nenhuma ação sem uma motivação, sem um estímulo.
Mensagem > Chamamos esse estímulo de mensagem, que chega a um objeto e
solicita que ele realize uma de suas operações. Uma operação, por sua vez, pode ser
implementada por meio de pelo menos um método.
Cada objeto presta um serviço. Quando o objeto precisa de um serviço da
responsabilidade de outro, ele precisa enviar uma mensagem a ele. Cada mensagem
ativa uma das operações do objeto.
Estado > chama-se estado do objeto o conjunto de valores de seus atributos em dado
momento. Uma mensagem enviada a um objeto pode (ou não) alterar o seu estado, na
medida em que pode alterar um ou mais valores de seus atributos.
Objeto
O objeto pode ser alterado com as mensagens que enviam.
OS PILARES DA ORIENTAÇÃO A OBJETOS
Abstração: é um processo mental que permeia toda a orientação a objetos, como um
princípio básico que serve de base aos demais princípios. É importante que ponhamos
nossa concentração nos aspectos relevantes e deixemos de lado os menos
importantes. Permite, portanto, gerenciar a complexidade de um objeto para que
possamos nos ater às suas propriedades essenciais. Uma propriedade de um objeto
pode ser relevante em um contexto e não ser em outro.
Encapsulamento: o objeto esconde (encapsula) seus dados (atributos) do acesso
indevido por outros objetos e somente permite que eles sejam acessados por
operações implementadas pelos seus próprios métodos (funcionalidades que
implementam o comportamento do objeto). O encapsulamento protege os dados do
objeto do uso arbitrário ou não intencional. O encapsulamento é uma técnica para
minimizar a interdependência entre as classes, pois apenas os métodos da respectiva
classe podem alterar seus dados (atributos), facilitando a identificação de erros e a
alteração dos programas. Em outras palavras, garante que apenas os métodos da
própria classe possam alterar o estado de um objeto.
Herança: mecanismo para derivar novas classes a partir da definição de classes
existentes, com base em um processo de refinamento. Uma classe derivada ou
descendente herda os dados (atributos) e o comportamento (métodos) da classe base
ou ancestral ou ascendente. A implementação da herança garante a reutilização de
código, que,além de economizar tempo e dinheiro, propicia mais segurança ao
processo de desenvolvimento, posto que as funcionalidades da classe base podem ter
sido usadas e testadas.
Polimorfismo: significa muitas formas. A partir do momento em que uma classe herda
atributos e métodos de uma (herança simples) ou mais (herança múltipla) classes
base, ela tem o poder de alterar o comportamento de cada um desses procedimentos
(métodos). Isso amplia o poder de reaproveitamento de código promovido pela
herança, permitindo que se aproveite alguns métodos e se altere (redefina) outros. Um
método com o mesmo nome em classes distintas pode ter diferentes comportamentos.
Exemplificando herança e polimorfismo
Na imagem a seguir, identificamos uma herança: Pagamento em Dinheiro, Pagamento
em Cartão e Pagamento em Cheque herdam da classe Pagamento, o atributo Valor e o
método Pagar.
Em cada classe filha (Pagamento em Dinheiro, Pagamento em Cartão e Pagamento
em Cheque), o método PagarConta é escrito de forma diferente, com distintos
parâmetros e códigos internos, conforme exige a respectiva forma de pagamento. Essa
possibilidade ocorre pelo princípio do polimorfismo.
Orientação a objetos como elemento de reusabilidade e extensibilidade
A orientação a objetos minimiza a gestão da complexidade na medida em que permite
uma organização mais adequada de seus componentes, além de seu
reaproveitamento. Um dos principais motivos para a baixa produtividade na construção
de sistemas computacionais é a dificuldade de reutilização de código.
As hierarquias de classes (herança) são estruturas que permitem o seu
reaproveitamento entre aplicações que, se bem projetadas, podem ser reutilizadas em
vários sistemas, otimizando tempo e dinheiro.
Além disso, tais estruturas podem ser estendidas (usando o princípio do polimorfismo)
sem corromper o que já existe. Dessa forma, pode-se concluir que a orientação a
objetos traz em si os seguintes benefícios:
- Reusabilidade: o uso de componentes já escritos pode ser a base para outros
softwares (através da herança)
- Extensibilidade: novos componentes podem ser desenvolvidos a partir de
outros, já desenvolvidos; sem afetar o comportamento do componente de
origem (mediante o princípio do polimorfismo) e permitindo que esse
comportamento seja alterado, estendido para um novo contexto.
ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS
A atividade de análise visa identificar o que os usuários e os demais interessados
(que juntos formam os stakeholders) precisam que o sistema faça.
Análise de sistemas implica numa investigação dos problemas e dos requisitos
(necessidades dos usuários) de um contexto, em particular, visando a construção de
um sistema automatizado.
O foco da atividade de análise é estudar e entender o funcionamento de um
sistema sob pelo menos alguns pontos de vista: da estrutura que sustenta o
sistema (os dados); dos procedimentos e processos intervenientes no sistema;
da dinâmica de funcionamento do fluxo de informações e dados, dentre outrosaspectos que podem ser adicionados, dependendo da especificidade do sistema
em construção.
A atividade de análise, por ser muito abrangente, costuma ser dividida em:
levantamento de requisitos (investigação dos requisitos) e análise dos
requisitos.
Inicialmente, entendemos a realidade, identificamos a abrangência do sistema e
capturamos as necessidades dos usuários desse sistema, usando técnicas específicas
(levantamento de requisitos).
Posteriormente, analisamos e entendemos essas necessidades e o funcionamento e a
dinâmica da organização (análise dos requisitos), visando à construção de modelos
que representem o sistema a ser desenvolvido, em sua concepção lógica, sem
preocupação com qualquer recurso tecnológico que venha sustentar o seu
funcionamento.
A atividade de análise não leva em consideração nenhum recurso tecnológico que
possa ser utilizado pelo sistema em construção. A ideia é construir uma estratégia de
solução sem considerar como (com que tecnologia) essa estratégia será construída.
A preocupação da atividade de análise é identificar: O QUE o sistema deve fazer para
atender às necessidades de seus usuários.
A finalidade é encontrar a melhor solução, que assim pode ser implementada em
qualquer tecnologia (plataforma operacional, linguagem de programação e banco de
dados), de acordo com as disponíveis no mercado, naquele momento.
No contexto da orientação a objetos, foca-se na identificação, no entendimento e na
definição dos objetos de software e em como eles irão colaborar para que os requisitos
dos usuários sejam respondidos satisfatoriamente.
LEVANTAMENTO DE REQUISITOS
Foco na compreensão do problema, onde se conversa com pessoas envolvidas com o
sistema (patrocinadores, gestores, usuários atuais e futuros e demais envolvidos. )
As necessidades e os desejos que os usuários têm são, tecnicamente, chamados de
requisitos. As pessoas específicas se reúnem identificando os requisitos do sistema,
considerando o contexto e o domínio do problema a que o sistema se aplica.
Para que os desenvolvedores possam identificar as necessidades dos usuários,
usando um conjunto de técnicas de levantamento de dados, desde as tradicionais
entrevistas até as técnicas de brainstorm.
Requisitos funcionais: declaram as funcionalidades necessárias ao sistema.
Requisitos não funcionais: apresentam algumas características associadas a uma,
algumas ou todas funcionalidades, e dizem respeito a aspectos de qualidade,
confiabilidade, desempenho, portabilidade, segurança e usabilidade do sistema.
A correta identificação e seu registo no documento de requisitos são cruciais para a
precisão e a qualidade do processo de desenvolvimento do sistema. Um requisito
faltante ou outro mal definido pode ser fatal para seu sucesso.
O documento de requisitos seguirá como base da comunicação entre os
desenvolvedores e os usuários, devendo ser validado por estes, uma vez que servirá
de norte para as atividades subsequentes do desenvolvimento do sistema. É portanto
fundamental a participação ativa e efetiva dos usuários do sistema na fase de
levantamento de requisitos. Na documentação de requisitos estará definido, também, o
escopo do sistema.
O principal ponto da fase de levantamento de requisitos é compreender profundamente
o sistema antes de iniciar a sua construção.
ANÁLISE DE REQUISITOS
- transposição dos requisitos dos requisitos funcionais e não funcionais para os
modelos que a equipe pretende usar.
A principal atividade é desdobrar os requisitos funcionais em funcionalidades do
sistema, uma vez que não necessariamente há uma relação de 1 para 1, ou seja, um
requisito funcional pode demandar mais de uma funcionalidade e uma funcionalidade
pode agregar mais de um requisito funcional.
A análise de requisitos tem, minimamente, duas perspectivas ou visões:
Análise do domínio (ou do negócio): visa identificar ou modelar os objetos que
serão usados na aplicação. Por exemplo, pagamento é um objeto no contexto do
sistema financeiro, usado para exemplificar os requisitos funcionais. Logo, pagamento
é um objeto do domínio, assim como Recebimento e fatura.
Análise da aplicação: em geral, sucede a análise do domínio. Nela, são identificados
os objetos de análise que não fazem sentido para os analistas de domínio,mas que
não são fundamentais para atender às funcionalidades necessárias ao sistema, a
aplicação em si (daí seu nome). Por exemplo, uma interface de cadastramento de
pagamentos é um objeto de aplicação do sistema de controle financeiro. Nesse
momento, o foco é apenas a identificação desse objeto, sem especificar sua
implementação, o que será detalhado na fase de projeto
ANÁLISE DE DOMÍNIO ANÁLISE DA APLICAÇÃO
Objetos do domínio (relacionado ao
problema).
Objeto de aplicação (relacionado a
aspectos computacionais de alto nível)
Os principais diagramas UML usados nas fases de análise são: diagramas de casos
de uso e diagrama de classes. Além desses, que ajuda, também, diagramas de
interação e de estados, em alguns casos.
A análise pode ser traduzida em “faça a coisa certa”.
PROJETO (DESENHO) DE SISTEMAS ORIENTADO A OBJETOS
A atividade de projeto denota uma solução, voltada a atender aos requisitos
identificados na fase de análise, considerando os recursos tecnológicos necessários
para implementar os objetos do domínio e os objetos da aplicação.
O objetivo é decidir “como o sistema funcionará” para atender aos requisitos. Em
geral, o projeto enfoca a definição da arquitetura do sistema, determinando suas partes
e a relação entre elas, o padrão de interface gráfica, o ambiente computacional
(sistema operacional e computacional), a linguagem de programação e o
gerenciamento do banco de dados.
O projeto, deriva da análise e produz uma descrição dos recursos computacionais e
de como o sistema deve ser executado no dia a dia. Muitas vezes algumas restrições
tecnológicas podem ser impostas.
A fase de projeto pode ser dividida em:
- Projet� d� arquitetur�: ato de distribuir as classes de análise em subsistemas com
seus componentes, bem como distribuir os componentes pelos recursos de
hardware disponíveis. Dentre os diagramas da UML, usamos aqui os diagramas
de pacotes, componentes e implantação.
- Projet� detalhad�: compreende atividades como modelagem das colaborações
entre os objetos, projeto da interface, projeto do banco de dados e aspectos
computacionais de alto nível (concorrência e distribuição de processamento e
dados). O projeto de algoritmos pode ser considerado aqui também, detalhando
aspectos do que for relevante para o projeto. Dentre os diagramas UML
utilizados aqui, destacam-se: diagrama de interação (sequência ou
comunicação), atividades (se demandar detalhamento de um método com
processamento paralelo), detalhamento do diagrama de classes, de estados,
dentre outros detalhamentos adiante.
Projeto pode ser traduzido em “faça a coisa certa”
Desenvolvimento de sistema em camadas
Foco de separar o desenvolvimento do código em camadas, diminuindo sua
complexidade e facilitando sua manutenção. Camadas separam as responsabilidades e
gerenciam as dependências. Abordaremos a arquitetura do software em camadas, sem
nos atermos a um modelo em especial.
No início da computação, os sistemas eram monolíticos, ou seja, todo o código ficava
confinado numa única camada, onde misturavam-se comandos de processamento, de
construção e manipulação de interface bem como de acesso e persistência de dados
em SGBD. “Tudo junto e misturado”.
Quando era preciso fazer manutenção no código, havia dificuldade no entendimento e
na separação do que de fato precisava ser alterado, sem contar a interferência em uma
parte do código quando se alterava outra, em princípio sem relação entre si.
À medida que os sistemas cresceram e se tornaram complexos, a manutenção ficou
mais difícil e a divisão em camadas foi uma das soluções encontradas para o projeto
de arquitetura de um software.
Num primeiro momento, a rede cliente-servidor, naturalmente dividiu o software em
duas camadas: a camada código que roda nocliente (camada de interface do usuário)
e a camada servidor (camadas de lógica do negócio e persistência dos dados). Com o
advento da web, separou-se em três e depois em quatro camadas. Atualmente,
pode-se criar tantas camadas quantas sejam necessárias, em função do tipo de
aplicação.
As camadas em geral:
• Possuem alta coesão e baixo acoplamento, ou seja, concentram atividades afins
(coesão) e são independentes umas das outras.
• Possuem propósito bem definido.
• A camada superior tem conhecimento apenas da imediatamente inferior, que fornece
os serviços, por uma interface.
No caso da orientação a objetos, as classes são organizadas em módulos maiores, as
chamadas camadas. Uma camada somente pode usar serviço (de outras classes) da
camada imediatamente inferior.
A seguir, as vantagens e desvantagens do desenvolvimento de software em camadas:
VANTAGENS
- Torna o código mais organizado e legível.
- Permite o desenvolvimento, o teste e a manutenção das camadas isoladamente.
- Permite melhor reuso do código ou dos objetos.
- Pode substituir uma tecnologia que implemente uma camada, de forma simples, sem
interferir nas demais. Por exemplo, para trocar o SGBD de SQL Server para
PostgreSQL, basta alterar a camada de persistência. As demais permanecem como
estavam.
- Disciplina as dependências entre as camadas.
- Mais adaptável a uma quantidade maior de usuários.
DESVANTAGENS
- Aumenta o número de classes do sistema.
- A adição de camadas torna o sistema mais complexo.
- Potencialmente, reduz o desempenho do software.
Como exemplo, podemos citar o modelo de camadas mais usado nos últimos anos, o
de três camadas, que engloba as camadas de:
Apresentação
Compreende as classes do sistema que permitem a interação com o usuário, as
chamadas classes de fronteira.
Negócio
Compreende as classes responsáveis pelos serviços e pelas regras do negócio, ou
seja, reúne as classes de controle e negócio.
Dados
Responsável pelo armazenamento e pela recuperação dos dados persistentes do
sistema, ou seja, as classes de persistência de dados.
Conceitos
Neste módulo, conheceremos a UML (Unified Modeling Language ou
Linguagem Unificada de Modelagem). Essa linguagem padronizada oferece
um conjunto de diagramas, sob diferentes visões, que permitem a
modelagem de sistemas orientada a objetos, independente de tecnologia e
de processos e metodologias de desenvolvimento de sistemas, cabendo
seu uso em qualquer contexto de desenvolvimento orientado a objetos.
O QUE É UML, AFINAL?
No final dos anos 1990, as linguagens de programação orientadas a objeto
já eram uma realidade, e cada profissional que desenvolvia atividade de
análise e projeto de sistemas criava seus próprios modelos, baseados em
suas necessidades e realidade. Ou seja, não havia consenso no mercado
sobre os modelos a serem usados para modelagem de sistemas
desenvolvidos sob a tecnologia de orientação a objetos.
Três competentes profissionais despontavam com seus modelos naquele
momento:
• Ivar Jacobson, idealizador do método OOSE (Object-Oriented Software
Engineering).
• James Rumbaugh, criador do método OMT (Object, Modeling Technique).
• Grady Booch, criador do método que leva seu nome.
A UML foi então adotada pela OMG (Object Management Group), em 1997,
oriunda da integração dos três métodos anteriormente descritos, como
uma linguagem de modelagem padrão para sistemas desenvolvidos sob o
paradigma orientado a objetos.
UML tornou-se o padrão para modelagem
gráfica, não apenas para objetos e, de fato, faz
sentido essa afirmativa, pois a UML pode ser a
linguagem de modelagem para diagramar
sistemas concorrentes e distribuídos.
(FOWLER, 2005.)
Desde sua versão inicial, a UML sofreu mudanças substanciais e
atualmente encontra-se em sua versão 2.5.1, de dezembro de 2017.
A UML é, portanto, uma linguagem padrão para construção de projetos de
sistemas, voltada para a visualização, a especificação, a construção e a
documentação de artefatos de um sistema. Foi projetada para ser
independente do método ou processo de desenvolvimento utilizado.
A UML é uma linguagem de modelagem, não é um método de
desenvolvimento nem tampouco uma metodologia ou um processo de
desenvolvimento de sistemas, uma vez que não determina a ordem e nem
como os diagramas devem ser usados. Simplesmente disponibiliza os
diagramas, sob as várias visões necessárias ao desenvolvimento de
sistemas, e cada empresa (ou equipe de desenvolvimento) a utiliza da
forma como lhe convenha, ou seja, adequando a UML ao seu processo ou
metodologia de desenvolvimento de sistemas.
A UML é uma linguagem destinada a:
Escolha um dos conceitos a seguir.
Visualização: A modelagem gráfica facilita a compreensão do sistema e das
decisões tomadas em análise e projeto, além de melhorar a comunicação
entre a equipe, permitindo sua interpretação sem ambiguidades.
Especificação: Permite a construção de modelos precisos, não ambíguos e
completos sob diferentes visões e atendendo às necessidades de
modelagem das diferentes fases do processo de desenvolvimento de
software, independentemente do processo ou modelo usado.
Construção: Os diagramas UML podem ser integrados às principais e mais
populares linguagens de programação do mercado, tais como Java e C++.
Mas, para isso, terá que buscar uma solução integrada de ferramenta CASE
(Computer-Aided Software Engineering) que gere código fonte (para
linguagens específicas) a partir de alguns diagramas UML.
Resumindo
A UML é uma linguagem de modelagem padronizada.
• A UML é independente de tecnologia, adequando-se a todo método,
metodologia ou processo de desenvolvimento.
• A UML não diz quais diagramas usar e nem em que ordem, pois a
metodologia de desenvolvimento ditará essa ordem.
• A UML disponibiliza diagramas sob diferentes visões ou perspectivas.
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps1
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps1
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps1
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps3
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps3
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps3
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps3
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps3
A UML se tornou não somente a notação gráfica
dominante dentro do mundo orientado a
objetos, como também uma técnica popular nos
círculos não orientado a objetos.
(FOWLER, 2005)
VISÕES DA UML
Assim como vimos nos exemplos do empreendimento imobiliário, as
plantas das unidades, a planta elétrica, a planta hidráulica, dentre outras,
cada modelo tinha uma perspectiva de compreensão da mesma realidade
(unidades residenciais em um empreendimento). No mundo de sistemas
computacionais, o mesmo acontece com relação à modelagem de
sistemas com UML. Os autores da UML entendem que um sistema deve ser
visto sob cinco diferentes perspectivas ou visões, descritas a seguir:
Clique nas barras para ver as informações.
VISÃO DE CASOS DE USO
Assim como a maquete permite uma perspectiva geral do empreendimento
imobiliário, sob o ponto de vista externo (visão do comprador), a visão de
caso de uso permite olhar o sistema sob o ponto de vista externo, do
usuário, descrevendo seu comportamento por conjunto de interações
usuário-sistema. Tal qual a maquete, é a primeira perspectiva de um
empreendimento; a visão de caso de uso é criada no estágio inicial do
desenvolvimento e guia todas as demais visões, na medida em que captura
os requisitos funcionais que definemo sistema.
VISÃO DE PROJETO (OU
LÓGICA)
Permite visualizar o sistema sob o ponto de vista de sua estrutura interna e
seu comportamento, em resposta às funcionalidades externamente
percebidas por seus usuários. Enfatiza os pacotes, as classes, as
interfaces, os subsistemas (pacotes) e as colaborações.
VISÃO DE IMPLEMENTAÇÃO
(OU DE DESENVOLVIMENTO)
Compreende o gerenciamento das versões do sistema, ou seja, de suas
implementações utilizáveis por seus usuários. Compreendem os
componentes, subsistemas e arquivos que compõem fisicamente o
sistema.
VISÃO DE IMPLANTAÇÃO (OU
FÍSICA)
Enfatiza a distribuição física do sistema em suas partes (subsistemas e
componentes) e as respectivas conexões entre elas. Enfatiza também a
organização física dos computadores e as conexões entre eles (a rede de
computadores).
VISÃO DE PROCESSO
Enfatiza aspectos físicos mais peculiares como concorrência, sincronismo
entre sistemas e desempenho (performance, confiabilidade, tolerância a
falhas e outros aspectos) do sistema, considerando os processos e os
processadores.
A UML implementa diagramas que atuam nas cinco visões descritas
anteriormente, permitindo ampla modelagem sobre todos os aspectos
(visões) relevantes do sistema.
Nem todas as perspectivas ou visões são úteis em todo desenvolvimento,
pois dependem das características, tipo e complexidade do sistema. A
imagem a seguir mostra a ideia central da visão de casos de uso,
influenciando todas as demais.
Visões da UML
UML E INTEGRAÇÃO COM PROCESSOS
DE DESENVOLVIMENTO
A UML é independente de metodologia e processo de desenvolvimento.
Isso é positivo para os fabricantes de software que implementam UML, pois
não limita seu mercado.
Sendo assim, cabe a cada empresa ou equipe de desenvolvimento a
integração da UML com sua metodologia de desenvolvimento de sistemas
computacionais, permitindo uma modelagem eficiente.
A UML pode ser usada de diversas formas, desde esboços manuais para
interação com usuários ou equipe, passando pelo uso de ferramentas de
diagramação UML até sofisticadas ferramentas CASE, que integram os
modelos e geram código em linguagens específicas.
A UML então pode ser adaptada em qualquer processo, seja ele:
Clique nas barras para ver as informações.
EM CASCATA
Com e sem retroalimentação, onde as fases se sucedem, a seguinte inicia
quando a anterior termina. A desvantagem é que, se for sem
retroalimentação, não há opção de retorno à fase anterior. Por exemplo, se
na fase de projeto identificamos novos requisitos, estes não podem ser
considerados, pois a fase de análise congelou os requisitos identificados.
Se a retroalimentação for permitida, esse problema pode ser minimizado,
mas não solucionado. O grande problema é que o usuário interage com a
equipe de desenvolvimento no início do processo e ao final, quando o
sistema é entregue.
INTERATIVO
Onde o sistema é dividido em subconjuntos de funcionalidades (com
mínimo de dependência com os demais conjuntos), e as atividades de
análise, projeto, implementação, teste e implantação são realizadas a cada
subconjunto. Isso significa que a cada subconjunto haverá a implantação
de uma parte do sistema, permitindo que ajustes das partes encerradas
ocorram em paralelo com o novo subconjunto de funcionalidades que está
sendo construído.
ÁGIL
Os processos são ditos ágeis porque compartilham um conjunto de valores
e princípios definido pelo manifesto ágil. O foco aqui é permitir modificação
sempre que preciso e no desenvolvimento de código. A modelagem existe,
mas em menor escala e com ênfase na comunicação com usuário e equipe
de desenvolvimento. Visa a pouca formalidade nos processos ágeis. Mais
usados: Extreme Programming (XP), Scrum, FDD (Feature Driven
Development).
RUP (RATIONAL UNIFIED
PROCESS)
O mercado muito fala da integração UML e RUP, mas, como os demais
processos, o RUP é independente da UML. O RUP, na verdade, é uma
estrutura de processo, que vai usar casos de desenvolvimentos (processo a
ser usado), a maioria deles iterativos. O RUP não se adapta a processo em
cascata.
VISÃO GERAL DOS DIAGRAMAS UML
Vamos nos ater aqui à versão mais recente da UML, a 2.5.1, que traz 14
diagramas divididos em estruturais e comportamentais, conforme imagem
a seguir.
Escolha um dos tipos de diagrama a seguir.
Os diagramas estruturais: Dizem respeito às estruturas estáticas necessárias ao
sistema, como os pacotes, as classes, os objetos, os componentes e a
estrutura de nós (estruturas computacionais). Também são chamados de
estruturas estáticas.
Os diagramas comportamentais: Evidenciam o comportamento (funcionamento)
de parte de um sistema ou processo de negócio relacionado ao sistema,
segundo determinada perspectiva. Dizem respeito às funcionalidades do
sistema, aos estados de um objeto em seu ciclo de vida, às interações entre
os objetos, dentre outros aspectos. Também são chamados de diagramas
dinâmicos.
Diagramas da UML
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps1
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps1
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps1
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps1
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/01425/index.html#collapse-steps2
A seguir, uma breve descrição de cada diagrama da UML:
Diagrama Especificação
Diagrama de
perfil
Permite a definição de tipos padronizados, como estereótipos,
restrições e valores rotulados. O foco é a adequação aos modelos
UML para diferentes plataformas, por exemplo.
Diagrama de
classes
Descreve, para cada classe, suas propriedades (atributos e
métodos) e seus relacionamentos com as demais classes. Classe é
a base estrutural dos sistemas orientados a objetos.
Diagrama de
estruturas
compostas
Possibilita a descrição de colaborações internas de classes,
interfaces ou componentes, visando a especificação de uma
funcionalidade.
Diagrama de
componentes
Apresenta a estrutura e as conexões entre os componentes de um
sistema.
Diagrama de
implantação
Especifica o ambiente computacional sobre o qual o sistema vai
operar, além de distribuir os artefatos (pacotes, classes e
componentes) nos nós (elementos computacionais).
Diagrama de
objetos
É um diagrama de classes instanciado, ou seja, mostra exemplos
de instâncias de classes.
Diagrama de
pacotes
Descreve estruturas hierárquicas que englobam outros elementos,
como outros pacotes, casos de uso, classes. Usado para
modularizar logicamente um sistema em suas partes relevantes
(subsistemas).
Diagrama de
atividades
Descreve o comportamento de procedimentos, processos de
negócios e fluxos de trabalho, suportando processamento
sequencial e paralelo.
Diagrama de
casos de uso
Mostra como os usuários (atores) interagem com o sistema, do
ponto de vista externo, evidenciando as funcionalidades com as
quais interagem.
Diagrama de
estados
Mostra como os eventos que afetam o sistema alteram o estado
dos objetos ao longo de seus ciclos de vida.
Diagrama de
sequência
Mostra como os objetos interagem, evidenciando a linha de tempo
(a sequência das interações).
Diagrama de
comunicação
Mostra como os objetos interagem, evidenciando as conexões e
colaborações entre eles.
Diagrama de
visão geral de
interação
Um mix de diagrama de sequência e de atividades. Uma
especialização do diagrama de atividades para interações.
Diagrama de
tempo
Diagrama de interação, com foco nas restrições de temporização,
como, por exemplo, para evidenciaras mudanças no estado de um
objeto ao longo do tempo.
Tabela: Marcelo Vasques de Oliveira
DIAGRAMAS UML E SUA UTILIZAÇÃO
NAS FASES
O descrito a seguir não é recomendado ou estipulado pela UML, pois a UML
não determina quais diagramas devem ser usados e tampouco em que
ordem devem ser elaborados. São dicas práticas.
Dificilmente usamos todos os diagramas da UML em um único sistema. Há
um conjunto de 4 a 8 diagramas que são os mais usados: pacotes, casos
de uso, classes, sequência (ou comunicação), estados, atividades,
componentes e implantação. Todos os mencionados são relevantes, mas
os em negrito são os essenciais.
No módulo 1, descrevemos as atividades das fases de análise
(levantamento e análise de requisitos) e projeto independentemente do
processo de desenvolvimento por entender que ambas estarão presentes
em qualquer processo que usemos. Agora, partindo desse mesmo
pressuposto, vamos descrever os diagramas UML que podem ser usados
em cada uma dessas três fases. Citaremos apenas os diagramas mais
usados.
Diagramas UML na atividade de
análise
Levantamento de requisitos Análise de requisitos
Esboço inicial do diagrama de
pacotes, para grandes sistemas,
evidenciando a necessidade de
particionamento
Detalhamento e aprofundamento do
diagrama de pacotes
Esboço inicial do diagrama de casos
de uso
Detalhamento e aprofundamento do
diagrama de casos de uso
Esboço inicial do diagrama
conceitual de classes, em alto nível
(sem detalhes)
Detalhamento e aprofundamento do
diagrama conceitual de classes
Diagrama de estados, para os objetos mais
complexos durante seu ciclo de vida
Diagrama de atividades, para elucidar um
processo ou fluxo de trabalho relevante ou
ainda para elucidar um caso de uso mais
complexo
Tabela: Marcelo Vasques de Oliveira
Nota: o diagrama conceitual de classes evidencia as classes (com
principais atributos e inicialmente sem métodos) e os principais
relacionamentos (em geral apenas associações, que são os
relacionamentos de classes mais elementares).
Os diagramas usados no levantamento de requisitos são, em geral, esboços
para a própria pessoa ou para debater com colegas da equipe. Já na fase
de análise de requisitos, alguns diagramas, em geral pacotes e casos de
uso, são usados para conversas com usuários.
Diagramas UML na atividade de
projeto
Adição de detalhes ao diagrama conceitual de classes, que passa a ser o
diagrama de classes de projeto.
Diagrama de sequência ou diagrama de comunicação, para cenários de uso mais
relevantes, o que ajuda a identificar métodos das classes envolvidas na interação.
Detalhamento dos diagramas de estados elaborados na atividade de análise,
podendo modelar de outros objetos percebidos.
Diagrama de componentes, caso o software use algum já pronto ou a ser
construído.
Diagrama de implantação, evidenciando as unidades computacionais e alocando os
componentes nelas.
Diagrama de atividades, esclarecendo métodos de classes mais complexos ou que
usem processamento paralelo.
Tabela: Marcelo Vasques de Oliveira
Nota: o diagrama de classes de projeto deriva do diagrama conceitual de
classes, agregando novos atributos, todos os métodos necessários,
identificando os corretos relacionamentos entre as classes (e não apenas
associações), adicionando as multiplicidades e outros elementos
relevantes da UML.
REQUISITOS FUNCIONAIS E NÃO
FUNCIONAIS
O desenvolvimento de um sistema começa pelo entendimento do problema
de negócio e o levantamento de quais requisitos esse sistema de software
deve satisfazer para resolvê-lo. Não existe uma definição padronizada para
requisito na literatura de Engenharia de Software. A norma ISO/IEC/IEEE
(IEEE, 1990) apresenta os seguintes enunciados para explicar o que é
requisito:
Uma condição ou capacidade do sistema solicitada por um usuário, para resolver um
problema ou atingir um objetivo.
Uma condição ou capacidade que deve ser atendida por uma solução para satisfazer
um contrato, uma especificação, um padrão ou quaisquer outros documentos formais
impostos.
Documentação da representação das condições ou capacidades apresentadas nos
dois anteriores.
Necessidades quantificadas e documentadas, desejos e expectativas do patrocinador,
clientes e outras partes interessadas.
Os requisitos são o ponto de partida para todo o processo de
desenvolvimento, sendo a base para as atividades de análise e projeto, bem
como implementação e testes. De acordo com Sommerville (2011), a área
de Engenharia de Software faz uma distinção, em termos de nível de
detalhamento de requisitos, entre requisitos de usuário e requisitos de
sistema. O primeiro expressa os requisitos abstratos de alto nível, e o
segundo revela uma descrição detalhada do que o sistema deve fazer.
Requisitos de usuário são declarações, em uma
linguagem natural com diagramas, de quais
serviços o sistema deverá fornecer a seus usuários
e as restrições com as quais este deve operar.
SOMMERVILLE, 2011
Requisitos de sistema são descrições mais
detalhadas das funções, serviços e restrições
operacionais do sistema de software.
SOMMERVILLE, 2011
Em uma perspectiva mais técnica, os requisitos de software são
normalmente classificados como requisitos funcionais e requisitos não
funcionais.
Requisitos funcionais são declarações de serviços
que o sistema deve fornecer, de como o sistema
deve reagir a entradas específicas e de como o
sistema deve se comportar em determinadas
situações.
SOMMERVILLE, 2011
Atenção
Requisito funcional é uma funcionalidade do sistema, é algo que o sistema deve
realizar para prover um resultado para o usuário. Requisitos funcionais pressupõem
interação do sistema com usuários.
Veja uma lista com alguns exemplos de enunciados dos chamados
requisitos funcionais:
O usuário deve ser capaz de pesquisar por nome na base de dados
disponível.
O sistema deve designar um identificador único (NUMERO_PEDIDO) para
cada pedido do usuário.
O sistema deve apresentar o documento selecionado para leitura do
usuário.
Perceba que, em todos os exemplos, estamos definindo atividades que o
sistema deve realizar, e, em todas essas atividades, o usuário está
envolvido, seja fornecendo entradas ou recebendo saídas (resultados).
A especificação de um sistema precisa considerar também como esses
requisitos serão entregues. Ou seja, quais características de qualidade e
quais restrições desejamos impor ao sistema. Assim, definimos os
chamados requisitos não funcionais.
Requisitos não funcionais são restrições aos
serviços ou funções oferecidos pelo sistema.
Incluem restrições de timing, restrições no processo
de desenvolvimento e restrições impostas pelas
normas. Ao contrário das características individuais
ou serviços do sistema, os requisitos não
funcionais, muitas vezes, aplicam-se ao sistema
como um todo.
SOMMERVILLE, 2011
Requisitos não funcionais (RNF) são frequentemente mais críticos do que
os requisitos funcionais (RF). Deixar de atender a um RNF pode significar a
inutilização de todo o sistema. Os RNF podem afetar a arquitetura geral de
um sistema em vez de apenas componentes individuais. No caso de um
website, um único RNF pode originar uma série de RF relacionados, que, por
sua vez, definem os serviços necessários.
Existem diversas classificações que visam a organizar e prover melhor
entendimento sobre os RNF. Um exemplo desse tipo de classificação é
apresentado na lista a seguir.
1
Requisitos de produto: usabilidade, eficiência, desempenho, confiança,
proteção.
2
Requisitos organizacionais: ambientais, operacionais, processo de
desenvolvimento.
3
Requisitos externos: reguladores, éticos, legais, contábeis.
Exemplo
Aqui estão alguns exemplos de enunciados de requisitos não funcionais:
● O sistema deve estar disponível durante todas as horas normais de
trabalho (2ª a 6ª, 8h30 às 17h). Períodos de não operação dentro
desses intervalos não podem ultrapassar 2 segundos em um dia.
● O sistema deve requerer autenticação dos usuários para permitir
acesso.
● O sistema deve implementardisposições de privacidade dos usuários
de acordo com a Lei Geral de Proteção de Dados.
Você pode perceber, nesses exemplos, que esses requisitos não indicam o que o
sistema realiza, mas como ele entrega uma ou mais de suas funcionalidades.
DIAGRAMA DE CASOS DE USO
A visão de casos de uso da UML apresenta o conjunto de funções (ou usos)
que o sistema deve executar para atender às necessidades dos usuários.
No modelo de casos de uso, o sistema é visto sob a perspectiva do usuário.
A documentação dos requisitos funcionais em um Diagrama de Casos de
Uso dá início ao processo de análise do sistema e permite entender sua
abrangência e complexidade.
O objetivo do Diagrama de Casos de Uso é apresentar uma visão geral dos requisitos
funcionais do sistema e, portanto, ele é o digrama mais abstrato, flexível e simples da
UML.
Esse diagrama é composto pelos seguintes elementos: casos de uso,
atores e relacionamentos. A figura 1 mostra um exemplo de Diagrama de
Casos de Uso para um sistema bancário.
Figura 1
– Exemplo de Diagrama de Casos de Uso, elaborado com ferramenta ASTAH (2021).
Os possíveis usos de um sistema são representados pelos casos de uso no
diagrama. Um Caso de Uso pode estar diretamente associado a um ou
mais requisitos funcionais, identificados na etapa de levantamento de
requisitos do processo de desenvolvimento.
Conforme observado na figura 1, o caso de uso assume a forma gráfica de
uma elipse contendo o seu nome no interior; nela, podemos observar quatro
casos de usos representados:
Abrir conta corrente
Depositar dinheiro
Sacar dinheiro
Consultar saldo
O caso de uso é o elemento fundamental do Modelo de Casos de Uso.
Atenção
Embora não exista um padrão para nomear casos de uso, a boa prática recomenda
utilizar uma frase verbal iniciando com verbo no infinitivo, denotando a ação prevista na
funcionalidade representada pelo Caso de Uso.
O segundo elemento do Diagrama de Casos de Uso é o Ator, que é
representado no Diagrama de Casos de Uso por um boneco palito, com o
nome na parte inferior.
O ator é quem utiliza ou interage em um caso de uso, ou seja, é uma entidade externa
que interage com o sistema, mas que não faz parte dele.
Interagir significa trocar informações com o sistema, seja fornecendo ou
recebendo essas informações. Na figura 1, temos a representação do ator
Cliente, que interage com os quatro casos de uso. Por exemplo, no caso de
uso Consultar Saldo, o ator Cliente informa os dados de sua conta e recebe
como resposta do sistema o valor de seu saldo.
O terceiro elemento do Diagrama de Casos de Uso são os
Relacionamentos, que permitem associar:
● Casos de uso com seus atores
● Casos de uso com outros casos de uso
● Atores com outros atores
Saiba mais
A forma mais comum e obrigatória dos relacionamentos é entre atores e casos de uso,
que assume a representação gráfica de segmento de reta (uma linha cheia) ligando o
ator ao Caso de Uso no qual ele interage.
Na figura 1, observamos que o ator Cliente interage com os quatro casos de
uso presentes nesse modelo, portanto, esses elementos gráficos estão
ligados por uma reta.
A seguir, vamos detalhar cada um desses elementos.
ATORES
Medeiros (2004) explica que atores atuam em casos de uso realizando
atividades. O ator não é uma entidade específica, mas representa um papel
ou aspecto particular de uma entidade. O ator pode representar papéis
executados por usuários humanos, um componente de hardware, outros
sistemas com os quais o sistema em desenvolvimento se comunica. Desse
modo, o nome do ator deve expressar esse papel de forma clara. No
exemplo da figura 1, o ator é o papel de cliente do banco. Esse papel pode
ser assumido pelos diversos clientes do banco.
Resumindo
Durante a execução de uma funcionalidade do sistema (um ou mais requisitos
funcionais), o ator precisa prover entradas (informações) para o sistema e deve
receber respostas dele.
O ator não é uma entidade específica, mas representa um papel ou aspecto
particular de uma entidade. O ator pode representar papéis executados por
usuários humanos, um componente de hardware, outros sistemas com os
quais o sistema em desenvolvimento se comunica. Desse modo, o nome do
ator deve expressar esse papel de forma clara. No exemplo da figura 1, o
ator é o papel de cliente do banco. Esse papel pode ser assumido pelos
diversos clientes do banco.
Tipos de atores que geralmente aparecem nos sistemas são:
Clique nas barras a seguir para ver exemplos de atores
Cargos: Por exemplo: empregado, cliente, gerente, vendedor, comprador etc.
Organizações e suas divisões: Por exemplo: fornecedor, agência reguladora,
administradora de cartões, setor de vendas etc.
Outros sistemas: Por exemplo: sistema de vendas, sistema de cobrança, sistema de
pagamento etc.
Hardware: Por exemplo: sensor de temperatura, leitora de código de barras
etc.
O relacionamento de generalização entre atores indica que uma instância
do primeiro ator interage com os mesmos tipos de instância de casos de
uso do segundo. Porém, o contrário não é verdade. Os casos de uso
associados ao ator mais específico nesse relacionamento são exclusivos
desse ator, que herda os casos de uso associados ao ator mais genérico. A
figura 2 mostra um exemplo desse tipo de relacionamento, no qual
percebemos que tanto o ator Vendedor quanto o ator Supervisor interagem
com o caso de uso Fazer pedido. No entanto, apenas o Supervisor participa
do caso de uso Aprovar crédito.
https://estacio.webaula.com.br/cursos/temas/02034/index.html#collapse-steps1
https://estacio.webaula.com.br/cursos/temas/02034/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/02034/index.html#collapse-steps2
https://estacio.webaula.com.br/cursos/temas/02034/index.html#collapse-steps3
https://estacio.webaula.com.br/cursos/temas/02034/index.html#collapse-steps3
https://estacio.webaula.com.br/cursos/temas/02034/index.html#collapse-steps4
https://estacio.webaula.com.br/cursos/temas/02034/index.html#collapse-steps4
Figura 2 – Exemplo do relacionamento
de generalização entre atores, elaborado com ferramenta ASTAH (2021). Imagem: Flavia Maria
Santoro.
Normalmente, o ator inicia a sequência de interações em um caso de uso. Portanto, a
forma mais fácil de começar a construir um modelo de casos de uso é identificar todos
os atores.
O analista de sistemas pode observar as fontes que devem fornecer
informações a serem processadas pelo sistema e para quem os resultados
do processamento devam ser fornecidos.
Bezerra (2015) sugere algumas perguntas úteis para guiar os analistas de
sistemas:
1. Que órgãos, empresas ou
pessoas utilizarão o sistema?
2. Que sistemas ou
equipamentos vão se comunicar
com o sistema a ser construído?
3. Alguém deve ser informado de
alguma ocorrência no sistema?
4. Quem está interessado em
certo requisito funcional do
sistema?
A partir daí, durante a identificação dos casos de uso, o analista poderá
perceber a existência de outros atores não identificados nessa etapa.
CASO DE USO
Caso de Uso é a descrição de uma sequência de interações entre um
sistema e um ou mais atores externos a esse sistema. De acordo com
Bezerra (2015), os casos de usos permitem a um observador externo ao
sistema entender quais são as funcionalidades fornecidas pelo sistema e
quais são os resultados externos produzidos por elas. Porém, não é
possível saber como o sistema trabalha internamente para produzir esses
resultados. Um modelo de casos de uso pode conter vários casos de uso,
dependendo do tamanho e da complexidade do sistema.
Atenção
Casos de uso não se limitam à sua representação gráfica; tão importante quanto isso é
a sua descrição textual. As descrições devem explicar de forma clara, simples e de
fácil entendimento, o que o sistema faz, sem entrar nos detalhes de como ele deve
fazê-lo. Casos de uso facilitam o processo de comunicação com usuários e são
utilizados para documentar a interação do sistema com eles. Desse modo, casos de
uso são úteis, tanto para os profissionaisenvolvidos no desenvolvimento do sistema
(analistas, projetistas, programadores, testadores) quanto para seus usuários e
clientes. A descrição textual de um caso de uso é uma espécie de história por meio da
qual contamos como um usuário realiza uma ação utilizando o sistema.
Casos de uso podem relatar as diversas formas de utilização de uma
funcionalidade do sistema. Assim, podemos definir cada uma dessas
formas por meio de cenários.
Cenário pode ser entendido como a instância de execução de um caso de
uso. Portanto, diversos cenários para o mesmo caso de uso podem ser
escritos. Os cenários podem ser usados para a especificação dos casos de
testes do sistema.
Para identificar os casos de uso, podemos pensar em dois tipos que
sempre estarão presentes nos sistemas: primário e secundário.
Clique nas barras para ver as informações.
CASOS DE USO PRIMÁRIOS
Estão relacionados diretamente aos objetivos dos atores, ou seja, são as
funcionalidades que agregam valor aos usuários. Bezerra (2015) sugere
uma lista de perguntas para auxiliar os analistas de sistemas na descoberta
dos casos de uso primários de um sistema:
1. Quais são as necessidades e os objetivos de cada ator em relação ao
sistema?
2. Que informações o sistema deve produzir?
3. O sistema deve realizar alguma ação que ocorre regularmente no
tempo?
4. Para cada requisito funcional, existe um caso de uso (ou mais) para
atendê-lo?
Alguns casos de uso são iniciados não por um ator, mas por um evento
temporal. Desse modo, normalmente o ator é o tipo de entidade que recebe
a informação resultante (por exemplo, um cliente que receba uma
notificação do sistema).
CASOS DE USO
SECUNDÁRIOS
Esses casos não apresentam uma relação direta de valor para os atores,
mas são imprescindíveis para o funcionamento do sistema. Por exemplo, a
manutenção de cadastros (inclusão, alteração, consulta e exclusão das
diversas informações que alimentam o sistema). Um sistema bancário
precisa cadastrar as informações sobre os clientes.
RELACIONAMENTOS
Os relacionamentos são responsáveis por estabelecer as associações entre atores e
casos de uso.
Todos os atores devem estar associados explicitamente aos casos de uso
com os quais interagem. Além disso, podemos estabelecer
relacionamentos entre os casos de uso ou entre os atores do sistema. O
Modelo de Casos de uso permite os seguintes tipos de relacionamentos:
comunicação, inclusão, extensão e generalização.
Relacionamento de
comunicação
É uma linha simples que mostra a que caso de uso determinado ator está
associado, ou seja, esse ator interage com o sistema por meio do caso de
uso. Um ator pode se relacionar com mais de um caso de uso, e todos os
atores devem estar associados a pelo menos um caso de uso. Esse
relacionamento foi mostrado na figura 1.
Atenção
Um erro comum na elaboração de diagramas de casos de uso é estabelecer
relacionamentos de comunicação entre casos de uso. Não existe troca de informações
entre casos de uso, uma vez que são funcionalidades independentes entre si.
Os relacionamentos de inclusão (include), extensão (extend) e generalização são
estabelecidos entre casos de uso.
Relacionamento de inclusão
Tem como objetivo principal a reutilização. Suponha que uma parte dos
passos de execução de um caso de uso se repita em diversos outros casos
de uso. Podemos criar um caso de uso separado e “incluí-lo” nos demais. A
inclusão funciona de forma semelhante à chamada de uma função em um
programa. A representação gráfica do relacionamento de inclusão é uma
linha pontilhada com o estereótipo <<include>> apontando do caso de uso
inclusor para o incluído.
A figura 3 mostra um exemplo desse tipo de relacionamento.
Figura 3 –
Exemplo do relacionamento de inclusão entre casos de uso, elaborado com ferramenta ASTAH (2021)
No exemplo da figura 3, o ator Médico participa de dois casos de uso: Fazer
pedido de exame e Fazer pedido de consulta. Em ambos os casos de uso, é
necessário realizar os passos do caso de uso Solicitar prontuário. Portanto,
este caso de uso é incluído nos dois primeiros.
Relacionamento de extensão
Tem como objetivo representar situações em que diferentes sequências de
passos possam ser inseridas no mesmo caso de uso. Ou seja, dependendo
de uma condição, o caso de uso segue um caminho diferente. Desse modo,
um caso de uso estende outro, permitindo um comportamento eventual.
Note que a existência do caso de uso estendido deve ser independente da
existência de quaisquer casos de uso que o estendam.
A figura 4 mostra um exemplo do relacionamento de extensão.
Figura 4 – Exemplo do relacionamento de
extensão entre casos de uso, elaborado com ferramenta ASTAH (2021)
Observe no exemplo da figura 4, em que o ator Cliente interage com o caso
de uso Realizar compra. O caso de uso Validar limite de crédito pode ser
necessário nesse contexto, portanto, é estendido para Realizar compra.
Ambos os casos de uso representam funcionalidades independentes no
sistema.
Relacionamento de
generalização
Pode existir entre dois casos de uso ou entre dois atores (conforme vimos
em Ator). Esse relacionamento permite que um caso de uso (mais
específico) herde características de outro (mais genérico).
Na generalização entre casos de uso, quando um caso de uso herda de
outro, significa que as sequências de passos de execução do caso de uso
mais genérico (pai) valem também para o mais específico (filho). Além
disso, o caso de uso herdeiro participa de qualquer associação do qual o
caso de uso mais genérico participe. Isso significa que um ator que
interage com o caso de uso pai pode também interagir em qualquer caso de
uso filho.
A figura 5 mostra um exemplo do relacionamento de generalização:
Figura 5 – Exemplo do relacionamento
de generalização entre casos de uso, elaborado com ferramenta ASTAH (2021)
Como podemos observar na figura 5, o caso de uso Cadastrar empregado
executa uma sequência de passos de cadastro para qualquer funcionário.
Já os casos de uso mais específicos (Cadastrar vendedor e Cadastrar
supervisor) herdam esses passos e ainda possuem passos específicos
para os tipos de funcionários Vendedor e Supervisor, respectivamente.
Os tipos de relacionamento entre casos de uso abordados permitem
manter a descrição dos casos de uso mais simples e sem repetições.
A inclusão deve ser usada quando um comportamento se repetir em mais
de um caso de uso.
A extensão é normalmente usada quando um comportamento que não é
executado em todas as instâncias de um caso de uso deva ser descrito.
A generalização deve ser aplicada em uma situação em que dois ou mais
casos de uso possuam comportamentos comuns.
ESPECIFICAÇÃO E FORMATOS DE
CASOS DE USO
Os casos de uso incluídos pelos analistas no Diagrama de Casos de Uso
devem ser especificados em um formato de narrativa textual, para
complementar a representação gráfica sob forma de diagramas. Desse
modo, o Modelo de Casos de Uso é formado pelo diagrama e pelo conjunto
de todas as descrições dos casos de uso.
Atenção
A descrição textual permite o entendimento mais preciso de qual funcionalidade do
sistema trata aquele caso de uso. Ela serve como ponto de partida para construção de
outros modelos, tais como, Modelo de Classes, ainda na fase de análise, e o Diagrama
de Sequência, na fase de projeto do desenvolvimento do sistema.
Comentário
A UML não propõe uma descrição formal de casos de uso e não existe uma forma
padronizada para a escrita dessa especificação. Os analistas e, muitas vezes, as
empresas definem seus padrões com base em exemplos, boas práticas e
necessidades particulares de cada projeto de desenvolvimento. As especificações
podem ser bem simples, abstraindo os detalhes da execução do caso de uso, ou mais
complexas, incluindo todo o passo a passo a ser seguido para obter os resultados
esperados.
Uma vez que não existe um padrão definido pela UML, a descrição textual
de um caso de uso pode ser feita em diferentes formatos. O que há em
comum em todos esses formatosé a forma de expressão narrativa.
O texto de um caso de uso é uma história que conta as ações ou a
sequência de passos de um ou mais atores e do sistema para atingir
determinado objetivo. Essa narrativa pode ser escrita em um parágrafo
contínuo, em passos numerados ou em uma tabela contendo uma coluna
para cada ator e uma coluna para o sistema.
Atenção
A descrição de um caso de uso deve ser clara, livre de jargões e termos técnicos, portanto, de
fácil entendimento não só para a equipe de desenvolvimento, mas para os usuários finais, pois
o modelo de casos de uso é lido e validado por todos os envolvidos.
Clique nas barras para ver as informações.
FORMATO CONTÍNUO
A narrativa é um texto livre. Como um exemplo, considere o caso de uso
Consultar saldo na figura 1. Uma especificação em formato contínuo para
esse caso de uso seria:
Este caso de uso inicia quando o Cliente chega ao caixa eletrônico e insere
seu cartão. O Sistema requisita a senha do Cliente. Após o Cliente fornecer
sua senha e esta ser validada, o Sistema exibe as opções de operações
possíveis. O Cliente opta por consultar saldo. O Sistema exibe o saldo da
conta e o caso de uso termina.
FORMATO NUMERADO
Aqui, a descrição desse caso de uso seria:
1. O Cliente insere cartão no caixa eletrônico.
2. O Sistema solicita a senha.
3. O Cliente digita senha.
4. O Sistema valida a senha e exibe menu de operações disponíveis.
5. O Cliente seleciona a opção consultar o saldo.
6. O Sistema exibe o saldo da conta.
FORMATO TABULAR
Cliente Sistema
Insere cartão no caixa eletrônico.
Solicita a senha.
Digita senha.
Valida a senha e exibe menu de operações
disponíveis.
Seleciona a opção consultar o
saldo.
Exibe o saldo da conta.
CENÁRIO PRINCIPAL E CENÁRIOS
ALTERNATIVOS
A especificação de um caso de uso descreve a sequência de passos de
interação entre o sistema e seus atores. A descrição do exemplo do caso
de uso Abrir conta corrente, na figura 1, mostra uma sequência, um fluxo ou
passo a passo mais usual, ou seja, aquela em que acontece exatamente o
que era esperado nessa interação.
Saiba mais
Essa sequência é chamada de cenário (ou fluxo) principal do caso de uso. Nesse
cenário, o ator consegue atingir seu objetivo seguindo o caminho “feliz”; em outras
palavras, nada de excepcional acontece. De acordo com Lima (2005), é o fluxo mais
óbvio, no qual todas as ações são bem-sucedidas.
Cada caso de uso possui apenas um cenário principal e ele deve ser
descrito de forma clara e concisa, sem uso de jargão computacional. Não
se esqueça: casos de uso devem ser escritos do ponto de vista do usuário
e, sempre que possível, com os termos que os usuários possam
compreender.
Agora, imagine que, em nosso exemplo, o Cliente digitou a senha errada. O que aconteceria
no fluxo descrito? Nada, pois esse problema não é previsto nesse cenário!
Para essa situação e algumas outras, o modelo de casos de uso prevê a
especificação dos cenários alternativos e cenários de exceção.
Clique nas informações a seguir.
Cenários alternativos: Nesta situação, o ator pode escolher formas diferentes para
chegar ao seu objetivo. Portanto, deve ser possível, apesar de não obrigatório,
especificar cenários alternativos. Em nosso exemplo da consulta de saldo, o
Cliente poderia optar por imprimir o saldo em vez de consultá-lo diretamente.
Um cenário alternativo não é uma exceção, é outra forma de fazer a mesma
coisa!
Cenários de exceção: Devem ser explicitados exceções, problemas ou
possíveis erros. Um cenário de exceção representa uma anomalia não
prevista no cenário principal, como o Cliente digitar sua senha errada. O
analista deve escrever cenários para tratar esse e outros desvios do
curso normal de um caso de uso, ou mesmo cancelar a realização do
caso de uso em questão.
De acordo com Bezerra (2015), esses cenários possuem as seguintes
características:
Representam erros de operação no cenário principal.
Não têm sentido fora do contexto do caso de uso no qual ocorre (ou seja, não são
casos de uso em si).
Precisam indicar em que passo o caso de uso continua ou, conforme for, indicar que o
caso de uso está finalizado.
No exemplo do caso de uso Abrir conta corrente, um cenário de exceção
para a situação em que o Cliente digitasse sua senha errada poderia ser
especificado da seguinte forma:
Cenário principal: O Cliente insere cartão no caixa eletrônico.
1. O Sistema solicita a senha.
2. O Cliente digita senha.
3. O Sistema valida a senha e exibe menu de operações disponíveis.
4. O Cliente seleciona a opção consultar o saldo.
5. O Sistema exibe o saldo da conta.
6. O sistema exibe o saldo da conta
Cenário de exceção “senha incorreta: No passo 4, caso a senha seja
incorreta:
4a. O Sistema informa que a senha está incorreta e solicita que o Cliente digite
novamente.
4b. O caso de uso retorna ao passo 3.
Observe que o cenário de exceção indica o ponto do cenário principal no
qual o problema pode ocorrer e o ponto exato para onde o fluxo deve
retornar. O analista deve especificar todas as possíveis exceções ou
problemas usando esses tipos de cenários.
ESTRUTURA DE ESPECIFICAÇÃO DE
CASOS DE USO
Como a UML não define um padrão para especificação de casos de uso,
você já observou que existem algumas formas práticas de apresentar a
narrativa ou o passo a passo de execução do caso de uso. No entanto, é
comum as empresas ou as equipes de desenvolvimento definirem seus
próprios padrões de estrutura e os tipos de informação a serem
apresentados, de modo a manter a qualidade dos documentos de requisitos
de software. Nesse sentido, você encontrará diversas sugestões de
modelos em livros ou sites na internet.
Um exemplo bastante útil é a estrutura descrita por Bezerra (2015). Veja, no
quadro 1, uma adaptação dessa proposta, que destaca os campos que
poderiam compor a descrição de um caso de uso. Você pode tomar como
base essa proposta e criar um padrão para seus projetos.
1. Identificador: código único para cada caso de uso que permite fazer a
rastreabilidade com outros elementos e modelos. Por exemplo, com
casos de teste e regras de negócio, UC01.
2. Nome: cada caso de uso tem um nome único que o identifica; é o
nome que aparece no Diagrama de Casos de Usos. O nome do caso de
uso é uma frase verbal iniciada por verbo no infinitivo. É importante ter
cuidado com coerência e clareza ao nomear um caso de uso. Por
exemplo, o nome do caso de uso UC01 é “Criar conta corrente”.
3. Objetivo: declaração sucinta do objetivo do ator no caso de uso. Para
o caso de uso Criar conta corrente, o Objetivo seria: “O objetivo deste
caso de uso é permitir que o Cliente do banco crie uma nova conta
corrente”.
4. Ator primário: nome do ator que inicia o caso de uso ou ator que
recebe o resultado do caso de uso; um caso de uso possui apenas um
ator primário. Para o caso de uso Criar conta corrente, o Ator primário
seria: “Cliente”.
5. Atores secundários: nomes dos demais atores que atuam no caso de
uso. Para o caso de uso Criar conta corrente, um ator secundário seria:
“Gerente da agência”.
6. Pré-condições: condições assumidas como verdadeiras para que o
caso de uso tenha início; um caso de uso pode conter zero ou mais
pré-condições. Por exemplo, em um caso de uso Criar conta corrente,
uma pré-condição poderia ser “Cliente cadastrado com CPF válido”.
7. Cenário (ou fluxo) principal: sequência de passos que normalmente
acontece quando o caso de uso é utilizado com sucesso; toda descrição
de caso de uso deve ter um fluxo principal.
8. Cenários (ou fluxos) alternativos e de exceção: sequência de passos
que apresentam formas de execução diferentes da descrita no fluxo
principal ou situações de exceções e erros que devem ser tratadas pelo
sistema. Não há obrigatoriedade de existirem fluxos alternativos ou de
exceção em um caso de uso.
9. Pós-condições: estado do sistema após o caso de uso ter sido
executado; tipicamente, uma pós-condição descreve que uma
informação foi alterada, excluída ou inserida nosistema. Uma boa
prática é usar verbo no particípio passado para descrever
pós-condições. Por exemplo, em um caso de uso Criar conta corrente,
uma pós-condição seria “conta corrente criada”.
10. Regras de negócio: a descrição de um caso de uso pode fazer
referência a uma ou mais regras de negócio. Aprenda mais sobre Regras
de Negócio em Explore +.
Quadro 1 – Proposta de estrutura para especificação de casos de uso. Quadro: Bezerra (2015),
adaptado por Flavia Maria Santoro.
ESPECIFICAÇÃO DE CASOS DE USO
COM INCLUSÃO E EXTENSÃO
A UML também não define uma forma padrão para a escrita de casos de
uso de inclusão ou extensão. No entanto, geralmente fazemos referência ao
caso de uso incluído/estendido na descrição do caso de uso que o
inclui/estende.
Casos de uso com inclusão: Para a situação dos casos de uso de inclusão, a
seguinte sintaxe pode ser usada: Include (nome do caso de uso incluso)
no ponto da descrição da sequência de interações em que o caso de
uso deve ser inserido.
Casos de uso com extensão: Para a situação dos casos de uso de extensão,
devemos lembrar que o caso de uso estendido existe
independentemente de outros casos de uso que o estendam. Ele possui
a descrição completa de sua sequência de passos. Se o ator escolhe
acessar o caso de uso estendido, ele executa o fluxo de ações desse
caso de uso e retorna para o ponto do cenário em que estava antes.
A especificação dos pontos de extensão em um caso de uso é feita
normalmente dentro da descrição textual do caso de uso extensor. A
descrição de um ponto de extensão deve indicar em que ponto (ou pontos)
do caso de uso estendido pode-se inserir o comportamento do extensor, e
podem existir vários pontos no estendido em que o extensor pode ser
ativado.
Atenção
Além da inclusão e extensão, um relacionamento de generalização requer uma forma de
especificação, na descrição do caso de uso herdeiro, de quais passos do caso de uso pai
estão sendo redefinidos. O analista pode criar marcadores no caso de uso pai. Esses
marcadores podem, então, ser referenciados na descrição do caso de uso filho para especificar
que passos estão sendo redefinidos ou onde está sendo definida uma extensão do
comportamento do pai.
CONCEITO E ELEMENTOS DE UMA
CLASSE
A abordagem de desenvolvimento de sistemas orientada a objetos assume
que um sistema é uma coleção de entidades – os objetos – que se
comunicam e realizam ações. A interação entre objetos é a forma de
execução de uma funcionalidade do software.
Essa abordagem se baseia nos seguintes princípios listados por Bezerra
(2015):
Qualquer coisa é um objeto.
Objetos realizam tarefas por meio da requisição de serviços a outros objetos.
Cada objeto pertence a uma classe, ou seja, classe é uma entidade que agrupa e abstrai
objetos similares.
Uma classe funciona com repositório para comportamento associado aos objetos instanciados
a partir dela.
Classes são organizadas em hierarquias.
Atenção
A UML é a linguagem padrão que permite a elaboração dos diversos modelos e das
perspectivas de um sistema na abordagem da orientação a objetos. Classes (e seus objetos)
são os componentes básicos dessa abordagem.
Objetos são entidades do mundo real que podemos observar. Por exemplo,
um objeto pode ser um carro, uma fruta, uma empresa, um empregado da
empresa, um concerto de música, um restaurante, um pedido de comida
nesse restaurante, entre muitos outros.
Quando pensamos nesses objetos em termos de grupos de coisas, por
exemplo, cada pessoa que assiste a aulas em uma turma é um objeto
diferente, mas, se abstrairmos esses objetos, observando suas
características comuns, criamos o conceito de Aluno, o qual é denominado,
então, de Classe. Uma classe de objetos com caraterísticas comuns, tais
como: estão matriculados em uma turma e assistem a aulas.
Uma classe pode ser definida como uma descrição de atributos (características) e serviços
(ações) comuns a um grupo de objetos.
Bezerra (2015) ressalta que uma classe pode ser entendida como uma
espécie de molde, a partir do qual objetos podem ser construídos. Portanto,
é comum afirmarmos que um objeto é uma instância de uma classe. Cada
objeto do mundo real é único, uma classe abstrai o tipo de objeto e permite
que novos objetos sejam criados a partir desse modelo. Se uma nova
pessoa se matricula na turma, ela é um novo objeto instanciado a partir da
classe Aluno.
Quando estamos tratando da modelagem de um sistema, somente um
subconjunto de características do grupo de objetos pode ser relevante.
Portanto, uma classe representa uma abstração das características
relevantes do mundo real para aquele conjunto de objetos.
Exemplo
Voltando aos nossos alunos, as características relevantes desses objetos, para um sistema
acadêmico, poderiam ser número de matrícula, idade e estilo de aprendizagem; mas outras,
tais como o esporte favorito ou número do calçado, talvez não façam parte do interesse desse
sistema.
A estrutura de uma classe é composta de atributos e de operações.
Os atributos descrevem os dados que deverão ser armazenados pelos
objetos dessa classe (suas características). Cada atributo de uma classe é
de um tipo de dados e possui um conjunto de valores que esse atributo
pode assumir, chamado de domínio. Veja um exemplo na figura 6.
As operações apresentam as ações que os objetos de uma classe podem
realizar. Como são ações, costumam ser nomeadas com uso de um verbo e
um complemento, e terminam com um par de parênteses (funções em
linguagens de programação). Ao contrário dos atributos, que para cada
objeto têm o seu próprio valor, os objetos de mesma classe compartilham
as suas operações. Em outras palavras, todos os objetos de uma classe
realizam as mesmas ações. Veja o exemplo de uma operação da classe
Aluno na figura 6.
Figura 6: Exemplo de Classe e seus
atributos e operações, elaborado com ferramenta ASTAH (2021)
Na figura 6, observamos que a representação de uma classe é feita por
meio de um retângulo com três compartimentos: nome da classe, lista de
atributos e lista de operações. Você também pode perceber a sintaxe de
especificação dos atributos e operações.
Um atributo é especificado no seguinte formato:
[visibilidade] nome: tipo = valor_inicial
Visibilidade de um atributo diz respeito ao seu nível de acesso, ou seja,
permite definir quais atributos de um objeto são acessíveis por outros
objetos. Essa propriedade serve para implementar o encapsulamento da
estrutura interna da classe. A visibilidade de um atributo pode ser:
pública (+)
protegida (#)
privativa (-)
de pacote (~)
Somente as propriedades que são realmente necessárias ao exterior da
classe devem ser definidas com visibilidade pública. Todo o resto é
escondido dentro da classe por meio das visibilidades protegida (visível
para subclasses da classe em que o atributo foi definido) e privativa
(invisível externamente à classe em que o atributo está definido). Com
visibilidade de pacote, o atributo é visível a qualquer classe que pertença ao
mesmo pacote no qual está definida a classe. Como veremos no módulo
seguinte, um pacote é um agrupamento de diagramas UML.
O elemento nome, única parte obrigatória na sintaxe do atributo,
corresponde ao nome do atributo. O elemento tipo, que especifica o tipo do
atributo, é dependente da linguagem de programação na qual a classe será
implementada. Por exemplo: int, float, boolean. No exemplo da figura 6, o
atributo matrícula é do tipo int.
É possível declarar o valor inicial que o atributo assume quando um objeto
daquela classe for instanciado. Desse modo, sempre que um objeto de uma
classe é instanciado, o valor inicial declarado é automaticamente definido
para o atributo. Em nosso exemplo, quando um novo aluno é inserido no
sistema, assumimos que seu estiloAprendizagem é aula prática.
Uma operação é especificada no seguinte formato:
visibilidade nome(parâmetros): tipo-retorno {propriedades}
O elemento nome corresponde ao nome dado à operação, em que
normalmente usamos verbos