Análise Orientada a Objetos e Projeto Arquitetural

Prévia do material em texto

Itens iniciais
Preparação
Antes de começar, instale um programa de modelagem UML em seu computador, como o Astah Free Student License. Use seu e-mail institucional para ativar a licença, preenchendo o formulário e aguardando a liberação da licença neste mesmo e-mail. Após receber a licença, siga as instruções para instalar o produto em seu computador. Você também pode encontrar outras ferramentas livres para modelagem de sistemas em UML fazendo buscas na internet.
Objetivos
· Reconhecer a importância dos modelos na exposição de requisitos e soluções sistêmicas.
· Distinguir os conceitos e pilares de análise e de projeto orientados a objetos.
· Descrever as visões, a síntese geral e os diagramas da UML.
Introdução
Vamos explorar os fundamentos da modelagem de sistemas para entender a realidade do negócio associada ao sistema e apresentar soluções que atendam às necessidades reais dos usuários. Começaremos examinando o conceito de modelo e mostrando como ele é aplicável no desenvolvimento de sistemas. É importante compreender que há diversos modelos, apresentados na forma de templates e diagramas, que devem ser aplicados em diferentes fases do processo de desenvolvimento do sistema.
Focaremos o desenvolvimento de sistemas orientado a objetos, compreendendo suas bases conceituais e seus pilares de sustentação. Dentro desse contexto, conheceremos a linguagem unificada de modelagem (UML, do inglês unified modeling language) e suas visões integradas de modelos, que oferecem diferentes perspectivas para abordar as diversas necessidades de modelagem, incluindo exposição de requisitos, análise de soluções e projeto do sistema em desenvolvimento. A UML é uma linguagem de modelagem independente de tecnologia, adaptável a diferentes processos e metodologias de desenvolvimento de sistemas orientados a objetos.
Utilizando modelos
O entendimento teórico sobre o conceito de modelos e sua aplicabilidade é fundamental em diversas disciplinas. Os modelos são representações simplificadas da realidade, permitindo aos pesquisadores e profissionais analisarem, entenderem e preverem o comportamento de sistemas complexos. Eles servem como ferramentas poderosas para explorar cenários, testar hipóteses e tomar decisões embasadas. Ao compreender a natureza e a função dos modelos, os indivíduos podem empregar essas ferramentas de forma mais eficaz, contribuindo para o avanço do conhecimento em campos tão diversos quanto a ciência, a engenharia, a economia e a medicina.
O que são modelos e para que eles servem
Uma família decide adquirir um imóvel na planta para moradia. Eles vão a um lançamento imobiliário a convite de um corretor conhecido. Ao chegarem, encontram um terreno vazio e um stand de vendas. Imediatamente surge a dúvida: como escolher o bloco e o apartamento de forma a garantir privacidade, considerando a vizinhança?
O corretor inicia seu trabalho e leva a todos para conhecerem a maquete do empreendimento − que nada mais é do que a representação do empreendimento em bloco único − e a infraestrutura do parque aquático.
A maquete é simplesmente uma representação em miniatura do condomínio real, ou seja, um modelo do empreendimento real. O empreendimento real será construído à imagem e semelhança da maquete. Assim, podemos estabelecer a primeira finalidade de um modelo: antecipar a existência de uma realidade para avaliar sua estrutura e comportamento.
Maquete de um empreendimento.
No exemplo a seguir, encontramos maquetes de um empreendimento imobiliário, mostrando a perspectiva externa, dando a visão clara da vizinhança, do posicionamento do imóvel, da piscina e área de lazer e da entrada.
Analisando a maquete e o posicionamento do empreendimento no terreno, os integrantes da família verificam o bloco e a posição do imóvel que mais lhes interessam, avaliando a vizinhança e respectivas distâncias entre eles.
A família seleciona três unidades e pergunta sobre a disposição dos cômodos. O corretor, então, apresenta a planta baixa de cada unidade selecionada. Veja!
Planta de uma unidade de um empreendimento.
Em seguida, eles se sentam à mesa com o corretor para escolher a unidade no bloco selecionado. O corretor então apresenta a tabela de preços de cada unidade do bloco selecionado, informando a metragem, o valor da unidade e as condições de pagamento.
A planta ilustrativa da unidade é um segundo exemplo de modelo usado no mercado imobiliário, que possibilita ao comprador avaliar o posicionamento e a dimensão de cada cômodo.
A família decide-se pelo imóvel, fecha o negócio e recebe um pen drive contendo outras plantas da unidade: elétrica, hidráulica, dentre outras. Cada uma dessas plantas representa um modelo sob uma diferente perspectiva.
Protótipo automotivo.
Outro exemplo de modelo muito comum atualmente são os protótipos, 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ístico e o de desenvolvimento de sistemas usam com eficácia protótipos como modelos.
Um modelo é uma representação abstrata e simplificada da realidade, que pode variar conforme a perspectiva de observação. A principal finalidade de um modelo é antecipar a existência de uma realidade específica, permitindo avaliar sua estrutura e comportamento de maneira eficaz. Portanto, diferentes realidades podem exigir a criação de múltiplos modelos para atender às diversas necessidades de análise e compreensão.
Modelos se aplicam ao contexto de desenvolvimento de sistemas?
Na construção ou desenvolvimento de sistemas computacionais, assim como na construção imobiliária, há uma gradação da complexidade no processo de construção, que depende de alguns fatores, sendo o tamanho (do sistema ou do empreendimento) um deles.
Os modelos, além da finalidade inicial, 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 o que é relevante.
Entre os benefícios do uso de modelos no desenvolvimento de sistemas computacionais, além de prever o comportamento do sistema e gerenciar sua complexidade, destacam-se estes aqui. Veja!
Comunicação entre as 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
A análise de melhorias, seja na fase de construção ou de manutenção, 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 a equipe na construção e na manutenção do sistema, incluindo pessoas que sejam integradas após o início do desenvolvimento do sistema. Servem ainda para documentar as decisões tomadas.
Delimitação do escopo do sistema
A modelagem ajuda na delimitação do escopo, ou seja, abrangência do sistema, definindo o que será ou não tratado pelo sistema.
Agora, vamos conhecer mais a seguir sobre modelagem. Acompanhe!
Modelagem de sistemas
Assim como exemplificamos no mercado imobiliário, no contexto de desenvolvimento de sistemas computacionais podem ser usados diferentes modelos de um mesmo sistema, em que cada um apresenta uma perspectiva (uma visão).
Por exemplo, um sistema armazena e manipula dados por meio de funcionalidades e possui determinadosde componentes.
E
Diagrama de implantação.
Responder
Parabéns! A alternativa D está correta.
O diagrama de componentes é especificamente destinado a apresentar a estrutura e as conexões entre os componentes de um sistema. Ele fornece uma visão geral das partes que compõem o sistema e como elas se relacionam entre si, contribuindo para uma compreensão clara da arquitetura geral do sistema.
Diagramas UML e sua utilização nas fases
Esses diagramas servem como uma linguagem padrão para visualizar, especificar, construir e documentar os artefatos de um sistema. Desde a análise até a implementação e manutenção, os diagramas UML ajudam a comunicar conceitos complexos de forma clara e concisa, facilitando a compreensão entre os membros da equipe e garantindo uma representação precisa dos requisitos e da arquitetura do sistema em todas as etapas do processo de desenvolvimento.
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.
Já descrevemos aqui 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
Aqui estão os itens essenciais para a atividade de análise. Veja!
Levantamento de requisitos
· Esboço inicial do diagrama de pacotes para grandes sistemas, evidenciando a necessidade de particionamento.
· Esboço inicial do diagrama de casos de uso.
· Esboço inicial do diagrama conceitual de classes em alto nível (sem detalhes).
Análise de requisitos
· Detalhamento e aprofundamento do diagrama de pacotes.
· Detalhamento e aprofundamento do diagrama de casos de uso.
· 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.
O diagrama conceitual de classes destaca as classes, incluindo seus principais atributos (inicialmente sem métodos), e os principais relacionamentos entre elas, geralmente representando apenas associações, que são os relacionamentos mais básicos entre classes.
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
Aqui estão os itens essenciais para a 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 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.
O diagrama de classes de projeto é derivado do diagrama conceitual de classes, adicionando novos atributos, todos os métodos necessários e identificando os relacionamentos corretos entre as classes (não apenas associações). Ele também inclui as multiplicidades e outros elementos relevantes da UML.
Atividade 5
Questão 1
Assinale o diagrama que não é usado (no sentido de elaborado) na fase de projeto, independentemente do processo de desenvolvimento adotado:
A
Diagrama de sequência.
B
Diagrama de atividades.
C
Diagrama de casos de uso.
D
Diagrama de implantação.
E
Diagrama de componentes.
Responder
Parabéns! A alternativa C está correta.
Dos diagramas apresentados, o único cuja elaboração acontece exclusivamente na fase de análise é o diagrama de casos de uso. Os demais são típicos da fase de projeto, embora sequência e atividades possam também ser usados na fase de análise.
Considerações finais
· Modelagem de sistemas.
· Processo de desenvolvimento de sistemas.
· Conceitos fundamentais da orientação a objetos.
· Análise e projeto de sistemas orientados a objetos.
· UML e integração com processos de desenvolvimento.
· Diagramas UML.
Confira as indicações que separamos!
 
· Visão geral do desenvolvimento em camadas: trabalhando com desenvolvimento em camadas utilizando C#.v
 
· Desenvolvimento em três camadas: conceitos.
 
· Modelagem de sistemas através da UML: uma visão geral.
 
· UML (Unified Modeling Language) e Unified Software Development Process (Unified Process).
 
Pesquise na internet:
 
· O diagrama da arquitetura em camadas, publicado no cogle.it, sob forma de infográfico de domínio público.
Referências
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3. ed. Rio de Janeiro: Elsevier, 2015.
 
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2005.
 
FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. Trad. João Tortello. 3. ed. Porto Alegre: Bookman, 2005.
 
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao processo unificado. 3. ed. Porto Alegre: Artmed, 2007.
Descrição
Visão geral da modelagem do domínio da aplicação com a UML, por meio de modelo de Casos de Uso, modelo de Classes, Diagrama de Objetos e Diagrama de Pacotes.
PROPÓSITO
Aprender as ferramentas básicas de modelagem conceitual de um sistema usando a UML é fundamental para a construção e a especificação sólida dos requisitos de um sistema, bem como o entendimento profundo sobre o domínio do negócio em que esse sistema esteja inserido.
Preparação
Antes de iniciar este conteúdo, instale em seu computador um programa que o permita elaborar modelos sob a forma de diagramas da UML (Linguagem Unificada de Modelagem). Nossa sugestão inicial é o Astah Free Student License, e será necessário usar seu e-mail institucional para ativar a licença. Preencha os dados do formulário, envie e aguarde a liberação de sua licença em seu e-mail institucional. Ao receber a licença, siga as instruções do e-mail e instale o produto em seu computador.
Sugestões de links adicionais de programas livres para modelagem de sistemas em UML podem ser encontradas em buscas na internet.
OBJETIVOS
Módulo 1
Identificar requisitos funcionais de um sistema com uso de Diagrama de Casos de Uso
Módulo 2
Reconhecer casos de uso por meio de especificações textuais
Módulo 3
Identificar classes e seus relacionamentos em um domínio de aplicação com uso de Diagrama de Classes
Módulo 4
Empregar Diagramas de Objetos e de Pacotes para apoiar a especificação de um sistema
Introdução
Aprenderemos técnicas e notação para modelagem de requisitos e conceitos de domínio de sistemas. A Unified Modeling Language (UML) ou Linguagem de Modelagem Unificada é uma linguagem ou notação visual para especificação de sistemas orientados a objetos. Essa notação vem sendo adotada como padrão para modelagem em organizações, pois tem como objetivo principal prover um conjunto de ferramentas poderosas para análise e projeto de sistemas.
O foco deste conteúdo são os Diagramas de Casos de Uso, Diagrama de Classes e Objetos e Diagrama de Pacotes, com seus respectivos conceitos e elementos, muito úteis para arquitetos, analistas e projetistas de software na fase inicial do processo de desenvolvimento: a especificação de requisitos e modelagemconceitual do domínio.
Em Engenharia de Software, a palavra domínio denota ou agrupa um conjunto de sistemas ou de áreas com funcionalidades similares dentro dos sistemas. Assim, é possível definir domínio aplicacional como uma coleção de aplicações de software com determinadas características em comum. Logo, domínio é um conjunto de características de uma família de problemas que determinada aplicação pretende solucionar.
Atenção
Como se observará ao longo do conteúdo, essa definição de domínio não deve ser confundida com o domínio de um atributo de classe, que é o conjunto de valores possíveis que esse atributo pode assumir.
MÓDULO 1
Identificar requisitos funcionais de um sistema com uso de Diagrama de Casos de Uso
Ligando os pontos
Como você pode tornar a comunicação com o usuário mais lúdica? O uso de meios gráficos facilita a percepção da visão macroscópica de um sistema complexo?
Quando trabalhamos com metodologias ágeis, o primeiro passo ao projetar um sistema é criar uma lista de desejos do usuário, as quais formam o backlog do produto, uma lista dinâmica, em que os itens constituintes devem ser priorizados para determinação de cada Sprint, ou ciclo de desenvolvimento. O itens da lista apresentam uma relação direta com os requisitos do sistema, mas colocados de forma apenas textual não permitem que o usuário compreenda como o produto a ser desenvolvido irá se comportar e como será organizado.
Costumamos dizer que uma imagem vale mais do que mil palavras, ou seja, com um diagrama adequado podemos sintetizar as funcionalidades gerais do sistema, sem adicionar detalhes técnicos, o que se torna ideal na comunicação com o usuário. Normalmente, trabalhamos com o diagrama de casos de uso, pois nele temos uma representação gráfica do sistema, com o mapa das funcionalidades e atores envolvidos em cada processo.
Tomando como exemplo os sistemas de streaming de vídeo, podemos ter no backlog de produto frases como: “o cliente deve consultar os títulos presentes na base”, “o cliente deve ter acesso aos títulos executados recentemente” e “o cliente deve poder executar o título escolhido”. As solicitações irão se transformar em requisitos funcionais (RF), já que definem elementos relacionados às funcionalidades inerentes ao sistema, mas algumas delas podem incluir fatores externos, delineados nos requisitos não funcionais (RNF), por exemplo: “usuário deve estar logado”.
Tendo como base os requisitos citados como exemplo, o diagrama de casos de uso teria o cliente como ator envolvido, relacionado aos casos de uso “Buscar Títulos”, “Executar Título” e “Consultar Recentes”. Note como o requisito é desmembrado em ator e ação, assumindo um título resumido para cada processo, mas sem perder a semântica original, conforme pode ser observado na imagem a seguir.
 Diagrama de casos de uso.
Com base no diagrama do exemplo, os usuários e desenvolvedores poderão compreender de forma simples as funcionalidades principais, e com o conjunto completo de atores e casos de uso teríamos uma percepção melhorada da complexidade geral. Logo, o diagrama de casos de uso é um elemento estratégico para o desenvolvimento, levando a uma melhor estimativa em termos de tempo e custo, ao mesmo tempo em que oferece essa percepção ao usuário de maneira simples.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Parte superior do formulário
1. De forma geral, a comunicação com o usuário não deve envolver detalhes técnicos, pois não trazem ganhos para a discussão. Considerando que você será alocado como engenheiro de software em um projeto de desenvolvimento de software, qual diagrama selecionaria para apresentar as funcionalidades do sistema de uma forma simples?
Diagrama de objetos
Diagrama de casos de uso
Diagrama de atividades
Diagrama de sequência
Diagrama de classes
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
O usuário não precisa ter conhecimento acerca das estruturas internas de um sistema, ou da implementação de fluxos de execução com base nessas estruturas. Através do diagrama de casos de uso, temos uma visão global do sistema e de suas funcionalidades, sem o acréscimo de informações técnicas, facilitando bastante a comunicação com o usuário.
Parte superior do formulário
2. Os diagramas de casos de uso permitem uma visão macroscópica do sistema, contando com uma simbologia própria, em que os processos são representados com a colocação dos títulos em formas ovaladas, relacionadas com o executor da ação. Considerando que você está alocado em um projeto de desenvolvimento de software, como analista, finalizando um diagrama de caso de uso e precisa validá-lo com o referido executor da ação, aponte qual elemento do diagrama representa esse executor.
Classe
Instância
Ator
Objeto
Sensor
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
Quem executa as ações em casos de uso são os atores, sem uma denominação específica acerca das estruturas internas que irão representá-lo no sistema. Alguns atores podem se transformar em classes durante o desenvolvimento, mas não é uma regra, já que, muitas vezes, temos apenas a representação de uma pessoa utilizando o sistema.
3. Quando trabalhamos com metodologias ágeis, temos o conjunto de pedidos do usuário em uma pilha ordenada por prioridade, que recebe o nome de backlog do produto, mas não temos uma visão do sistema a partir da pilha. Como você pode representar essas solicitações de forma gráfica, transmitindo um primeiro nível de organização sistêmica?
Resposta
Espelho de resposta
Os itens do backlog do produto podem ser interpretados como requisitos funcionais do sistema, e podem ser divididos em ator e ação. Feita a divisão, as ações serão os casos de uso, já relacionados aos requisitos funcionais. Como especificamos os atores, temos todos os recursos necessários para construir o diagrama de casos de uso, o qual viabiliza uma visão macroscópica do sistema, sem a inclusão de detalhes técnicos.
Avalie este módulo:
 
    
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 entradasespecí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 implementar disposiçõ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
Organizações e suas divisões
Outros sistemas
Hardware
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.
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 profissionais envolvidos 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 > 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 usadaquando 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.
A importância do modelo de casos de uso na análise de requisitos
A especialista Flavia Maria Santoro fala sobre o modelo de casos de uso, sua finalidade, seus elementos e sua importância na especificação de requisitos funcionais.
Verificando o aprendizado
Parte superior do formulário
1. Caso de uso é o principal elemento do Modelo de Casos de Uso da UML. Sobre casos de uso, podemos afirmar que:
permitem a compreensão sobre como o sistema trabalha internamente para produzir os resultados.
descrevem primordialmente requisitos não funcionais.
assumem a forma de um retângulo com os cantos arredondados no diagrama de casos de uso.
fornecem uma perspectiva do sistema do ponto de vista de um observador externo.
descrevem as entidades do sistema.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
Casos de uso descrevem funcionalidades do sistema (requisitos funcionais) na perspectiva dos seus usuários.
Parte superior do formulário
2. Atores representam os tipos de entidades que interagem em um caso de uso. Assinale a alternativa que apresenta uma lista de nomes de atores adequados:
Carlos, Diretoria de Planejamento.
Sistema de Cobrança, Cliente, Sensor de temperatura.
Imprimir relatório, Biblioteca, Funcionário.
Impressora, Andreia, Imprimir relatório.
Comprador, Setor de Recursos Humanos, Pagar fatura.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
Atores representam papeis assumidos pelas entidades que interagem com um caso de uso do sistema.
MÓDULO 2
Reconhecer casos de uso por meio de especificações textuais
Ligando os pontos
Os diagramas de casos de uso estão definidos, mas e agora? Como você acha que os desenvolvedores saberão a forma correta de implementá-los?
Uma equipe de desenvolvimento envolve diversos profissionais, como programadores, analistas, designers e administradores de banco de dados. Se considerarmos o sistema da Netflix, por exemplo, precisamos de diversos designers com grande competência, pois será necessário um ambiente responsivo, englobando interfaces para web, dispositivos móveis e televisores smart, além de programadores para plataformas heterogêneas.
Embora os casos de uso transmitam a ideia geral acerca de processos e atores relacionados, será necessário descrever os passos para a correta implementação desses processos, algo que é conhecido como descritivo de caso de uso. Assim como na definição de um algoritmo, o texto descritivo de um caso de uso deve ser, até onde possível, independente de tecnologia, além de expressar a funcionalidade segundo uma sequência concisa e lógica.
Os descritivos são identificados por numeração com o prefixo UC, de use case, atrelada ao título que está presente no diagrama de casos de uso. Além da necessidade de descrever os passos para execução, incluindo fluxos alternativos em determinados trechos, precisamos especificar o ator principal participante e possíveis atores secundários.
Todo caso de uso deve ter uma descrição do objetivo, de forma sucinta, apenas definindo o resultado esperado com sua implementação, algo que pode ser muito útil para a equipe de testes. É interessante observar que um caso de uso sempre estará relacionado a um requisito funcional, com base no objetivo descrito.
Ainda temos as pré-condições, definindo elementos que não pertencem ao processo, mas são necessários para a correta execução da sequência de operações. De forma geral, é bastante comum observarmos um relacionamento entre as pré-condições e os requisitos não funcionais, por exemplo, para buscar um título, em que o cliente deve estar logado.
Por fim, temos as pós-condições, ou consequências, para a execução do caso de uso, como na alteração de dados da base ou inclusões no log para rastreabilidade. Por exemplo, ao buscar um título, uma lista com as últimas buscas efetuadas, até um limite de dez itens, deve ser exibida e, como pós-condição, a lista deve ser atualizada ao finalizar a busca.
Um exemplo de descritivo de caso de uso é apresentado na sequência, compreendendo a busca de títulos em sistemas similares ao da Netflix. Como podemos observar, o descritivo de casos de uso será essencial para guiar a equipe, não apenas definindo a sequência de operações, mas também contextualizando o processo frente ao restante do sistema.
	UC-001
	Buscar títulos
	Atores
	Cliente da plataforma
	Pré-condições
	Para efetuar a busca de títulos, o usuário (cliente) deve estar logado.
	Fluxo Principal
	1. Cliente seleciona a opção de busca.
2. Sistema alimenta lista com as últimas buscas efetuadas.
3. Cliente digita parte do nome e clica em buscar.
4. Sistema pesquisa o valor em nomes de filmes ou séries, estilo e nome de atores, apresentando uma coleção com os cem resultados principais.
5. Cliente clica no título para iniciar a exibição.
	Fluxo Alternativo
	3.1 Ao invés de digitar parte do nome, o cliente clica em um nome da lista de buscas recentes.
	Pós-condições
	Ao final da busca, a lista com consultas recentes deve ser atualizada.
	Requisitos
	RF-002: o cliente deve poder consultar os títulos presentes na base.
RNF-001: usuário deve estar logado.
Tabela: Descritivo do caso de uso.​
Elaborada por: Denis Gonçalves Cople​
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Parte superior do formulário
1. Ao descrever um caso de uso, temos a chance de especificar atividades finalísticas, que não pertencem ao fluxo de ações, mas que devem ser executadas para garantir a consistência em ações posteriores. Considerando que você está alocado no projeto como analista de teste, onde você irá inserir no ckeck-list de qualidade, particularmente no descritivo, essas atividades finalísticas?
Pós-condições
Fluxo Principal
Pré-condições
Atores
Fluxo alternativo
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
Quando descrevemos um caso de uso, temos um fluxo principal de ações e possíveis fluxos alternativos, ligados diretamente ao objetivo do caso de uso. Algumas ações não estão relacionadas ao fluxo de execução, mas devem ser acionadas após o fluxo, como a gravação de log, por exemplo, sendo especificadas na área de pós-condições.
Parte superior do formulário
2. O descritivo do caso de uso é uma ferramenta importante para guiar os desenvolvedores, pois especifica o fluxo de execução necessário e condições ambientais. Após a conclusão de um diagrama de casos de uso, você, como engenheiro de software, necessita validar o modelo com o usuário. Nesse contexto, qual das opções seguintes expressa uma característica do descritivo de caso de uso a ser esclarecida ao referido usuário?
Apresenta o relacionamento do caso de uso com o requisito funcional abordado.
Em pré-condições, temos atividades finalísticas que não pertencem ao fluxo de execução.
Os atores não fazem parte do descritivo do caso de uso.
Em pós-condições, temos ações de inicialização que não pertencem ao fluxo de execução.
Permite a existência de apenas um fluxo de execução.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
Algo interessante acerca dos casos de uso, principalmente se considerarmos as metodologias ágeis, é o relacionamento expresso entre o caso de uso e o requisito funcional abordado, algo que deve ser explicitado no descritivo do caso de uso. As pré-condições são utilizadas para inicializações, ou condições para execução do fluxo de ações do caso de uso, enquanto as pós-condições são atividades finalísticas. Os atores devem ser explicitados no descritivo, inclusive atores secundários, quando existirem. Finalmente, podemos ter fluxos alternativos de execução descritos, além do fluxo principal.
3. Quando trabalhamos com métodos ágeis, como o Scrum, temos ciclos pequenos para desenvolvimento de módulos funcionais, visando entregaro maior valor possível para o cliente no menor tempo. Embora a metodologia realmente não exija tal documentação, explique por que você, como um engenheiro de software, poderá exigir o descritivo de caso de uso, podendo ser nesse caso um bom instrumental para a equipe.
Resposta
Espelho de resposta
Os ciclos de desenvolvimento, ou Sprints, utilizam um período curto, onde a equipe especializada e multidisciplinar deve se auto-organizar e alinhar objetivos em curtas reuniões diárias. A utilização do descritivo de caso de uso gera um guia comum para a equipe, minimizando possíveis discussões, e funcionando como um meio auxiliar para o registro de problemas e busca de soluções no decorrer do desenvolvimento.
Obrigado pelo feedback!
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
Cenários de exceçã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:
Clique nas informações a seguir.
Cenário Principal
1. 
2. 
3. 
4. 
5. 
6. 
Cenário de exceção “Senha incorreta”
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 deuso 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 no sistema. 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.
Clique nas informações a seguir.
Casos de uso com inclusão
Casos de uso com extensão
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.
Descrições textuais de casos de uso
A especialista Flavia Maria Santoro fala sobre as formas de especificação dos casos de uso por meio de descrições textuais.
Verificando o aprendizado
Parte superior do formulário
1. Durante a execução de um caso de uso, podem ocorrer exceções. Assinale a opção que descreve como essas situações devem ser tratadas no modelo de casos de uso:
O analista deve especificar cenários de exceção.
O analista deve desconsiderar esse tipo de situação.
O analista deve criar um Diagrama de Tratamento de Exceções.
O analista deve solicitar ao usuário que não se desvie do cenário principal do caso de uso.
O analista deve incluir um tratamento para a exceção no cenário principal.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
A forma correta de tratar exceções no modelo de casos de uso é especificar cenários de exceção que, diferentemente dos cenários alternativos, representam situações de anomalias que rompem o fluxo do cenário principal.
Parte superior do formulário
2. A descrição textual de um caso de uso pode ser feita em diferentes formatos. Assinale a opção que lista os formatos mais comumente utilizados.
Conto, Crônica e Prosa.
Cenário principal, Cenário Alternativo, Cenário de Exceção.
Ator, Relacionamento, Caso de Uso.
Abstrato, Real, Básico.
Contínuo, Lista numerada e Tabela.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "E" está correta.
Um caso de uso pode ser descrito por meio de um texto simples corrido (contínuo), uma lista de passos numerada (lista numerada) ou na forma tabular com colunas para o sistema e cada um dos atores (tabela).
MÓDULO 3
Identificar classes e seus relacionamentos em um domínio de aplicação com uso de Diagrama de Classes
Ligando os pontos
Como você pode representar os elementos do domínio da aplicação? Quais as vantagens de utilizar a abordagem orientada a objetos?
Mesmo antes da adoção de orientação a objetos para o desenvolvimento de software, os elementos do domínio da aplicação precisavam ser modelados. Em termos gerais, no modelo estruturado, tínhamos apenas tipos compostos, para representar os dados, e fluxogramas, para expressar a sequência de operações dos processos, mas, na orientação a objetos, as classes englobam tanto valores quanto processos, em uma estrutura fechada.
As classes são, portanto, o ferramental básico para a definição de tipos na orientação a objetos, e o diagrama de classes oferece uma interpretação gráfica do domínio, com seus elementos e respectivos relacionamentos. Cada classe do diagrama recebe um nome, um conjunto de atributos, representando os dados, e um conjunto de métodos, para definir os processos que serão executados pelos objetos.
Uma classe é um molde, ou tipo, definindo uma estrutura fechada (encapsulada), o que leva à necessidade de determinar a visibilidade dos atributos e métodos. Em um sistema de Streaming, como o da Netflix, podemos ter uma classe de usuário com login, nome e senha, em que a senha seria um atributo privado, enquanto login e nome poderiam ser públicos.
Diversos tipos de relacionamento podem ocorrer entre as classes, como a composição, comum nas interfaces gráficas, onde uma janela deve conter outros objetos, incluindo botões e caixas de texto, ou relacionamentos simples, como no caso de títulos e atores, em que cada objeto terá um ciclo de vida independente. Porém, o relacionamento mais interessante é o de herança, no qual podemos aproveitar as características de uma classe já existente, como em uma possível derivação de usuário para cliente ou colaborador.
Além de ter maior semelhança com o mundo real que o modelo estruturado, o fato de que o código está concentrado nas classes facilita a manutenção, pois basta modificar em um ponto para refletir em todo o sistema. Ao mesmo tempo, a herança traz um alto nível de reuso, pois permite acrescentar funcionalidades de forma direta, aproveitando o que já funcionava e ainda podendo adaptar comportamentos através do polimorfismo.
Podemos concluir que o diagrama de classes traz uma representação adequada do domínio da aplicação, como podemos observar no exemplo apresentado a seguir, contendo alguns elementos, relacionamentos e comportamentos básicos de um sistema de streaming. Inclusive, várias ferramentas geram código a partir do modelo, e modificando o diagrama estaríamos efetuando a manutenção do sistema como um todo.
 Diagrama de classes inicial para o sistema de streaming.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Parte superior do formulário
1. A orientação a objetos trouxe uma modelagem muito mais próxima do mundo real, em que as classes são abstrações de base, semelhantes aos tipos compostos da estruturada, mas concentrando ações e valores na mesma estrutura fechada. Você, como um engenheiro de software, está realizando a modelagem de classes, qual abstração deveria ser aplicada para o reuso estrutural?
Encapsulamento
Polimorfismo
Instância
Visibilidade
Herança
Parte inferior do formulário
Comentário
Parabéns! A alternativa "E" está correta.
Através da herança, temos o reuso estrutural, pois definimos uma nova classe a partir de outra já existente, aproveitando todas as características originais, e permitindo acrescentar novos métodos e atributos. Algo interessante acerca dos métodos herdados é que podemos modificá-los para adequar ao novo contexto, através do polimorfismo, o que acaba aumentando o poder adaptativo da herança.
Parte superior do formulário
2. Classessão estruturas fechadas, ou encapsuladas, e precisamos de meios para controlar o nível de acesso, ou visibilidade, para cada atributo ou método componente, e a visibilidade deve ser determinada no diagrama de classes segundo uma simbologia específica. Considerando que você é um analista de teste e está elaborando um check-list para inspecionar visibilidades no modelo de classes, qual a opção correta acerca da simbologia utilizada?
O sinal de mais precede elementos privados.
O sinal de menos precede elementos públicos.
O sinal de menos precede elementos privados.
O sinal de cerquilha precede elementos com o nível de pacote.
O sinal de til precede elementos protegidos.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
O diagrama de classes expressa a visibilidade através de símbolos precedendo os atributos e métodos. O sinal de mais precede elementos públicos, os quais podem ser acessados a partir de qualquer trecho de código, enquanto o sinal de menos é utilizado para os elementos privados, que só podem ser utilizados na programação interna da classe. Temos ainda o sinal de til para o nível de pacote e cerquilha para elementos protegidos.
3. O diagrama de classes oferece uma boa visão do domínio da aplicação, incluindo desde atributos das diversas entidades envolvidas e seus relacionamentos e ainda, algumas funcionalidades do sistema sob um ponto de vista amplo. Para você, quais as vantagens de se utilizar a abordagem orientada a objetos, e como o diagrama de classes se torna um facilitador para as atividades de desenvolvimento?
Resposta
Espelho de resposta
Com a orientação a objetos, temos um alto nível de reuso com base nas classes, bem como reaproveitamento estrutural através da herança. Temos ainda um aspecto adaptativo para os métodos herdados, devido ao polimorfismo. Além de aumentar o reuso, a adoção de classes facilita a manutenção, pois, ao modificar o código da classe, nós impactamos todos os objetos instanciados, bem como as instâncias de descendentes, o que pode, por outro lado, gerar efeitos não previstos para o sistema. O diagrama de classes é um excelente indicador para os efeitos secundários das modificações, tendo como base os relacionamentos diretos ou indiretos expressos no diagrama.
Obrigado pelo feedback!
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 que denotema ação realizada por essa operação (no exemplo, assistirAula). Uma operação é ativada (executada) quando um objeto envia uma mensagem para outro, sendo essa mensagem o nome da operação.
Do mesmo modo que os atributos, a visibilidade pode ser pública (+), privada (-), protegida (#) ou de pacote (~).
Os parâmetros de uma operação são informações que ela recebe do objeto que envia a mensagem para requisitar a execução da operação. Uma operação pode ter zero ou mais parâmetros, que devem ser separados por vírgulas. Parâmetros têm seu tipo definido: tipo retorno representa o tipo de dados do valor retornado por uma operação.
Visão geral do Diagrama de Classes
O Diagrama de Classes da UML é o modelo em que representamos as classes de um sistema, incluindo os detalhes sobre seus atributos e suas operações, e como essas classes se relacionam.
Portanto, a elaboração do Diagrama de Classes é fundamental em todo o processo de desenvolvimento que segue a abordagem da orientação a objetos.
Os diversos componentes de um Diagrama de Classes especificam as classes que serão realmente implementadas (ou seja, codificadas em uma linguagem de programação), sendo a base para a criação dos principais objetos e as interações entre eles.
Atenção
Góes (2014) explica que o Diagrama de Classes é o modelo mais importante da UML, pois permite a representação dos elementos da base de dados do sistema. Portanto, facilita a comunicação entre a equipe de desenvolvimento e com os usuários finais.
O Diagrama de Classes também explicita as demandas de dados e informações dos atores, que são declaradas nos casos de uso. Diagramas de classes são usados para expressar graficamente os conceitos a serem manipulados por um sistema, bem como as ações esperadas, e para fornecer uma descrição independente de implementação dos tipos utilizados em um sistema, ou seja, os modelos de dados.
Comentário
Costumamos dizer que esse diagrama destaca um aspecto estrutural estático do sistema, pois representa a estrutura interna do sistema, mas não como os objetos do sistema interagem no decorrer do tempo. As operações mostram quais são as possíveis interações entre os objetos, mas não explicitam em que momento serão invocadas.
O Diagrama de Classes é utilizado na construção do modelo de classes desde o nível de análise até o nível de especificação. O diagrama evolui à medida que o processo de desenvolvimento do sistema avança.
O que queremos dizer com “evolui”?
Resposta
Significa que vamos acrescentando detalhes e refinando o diagrama, tanto em termos de atributos e operações quanto na forma como associamos as classes.
É comum chamarmos esse diagrama que evolui sucessivamente de modelo de classes de análise, modelo de classes de projeto e modelo de classes de implementação, fazendo referência às etapas do processo de desenvolvimento.
Clique nas barras para ver as informações.
Modelo de classes de análise
É composto por elementos identificados na etapa de análise; é basicamente formado por classes relacionadas a conceitos do domínio da aplicação. Seu objetivo é descrever o problema representado pelo sistema a ser desenvolvido. É um modelo conceitual; com foco em o que o sistema deve tratar, não considera características técnicas da solução a ser utilizada. Em termos práticos, nesse modelo, incluímos as classes, a lista de atributos e a lista básica de operações, sem os detalhes de tipos de dados, ou parâmetros das funções, por exemplo. O modelo de casos de uso e o modelo de classes de análise são os dois principais modelos criados na fase de análise.
Modelo de classes de projeto
É construído na atividade de projeto do desenvolvimento e considera alguns detalhes da solução de software a ser utilizada, mas ainda em um nível alto de abstração. Nessa etapa do processo de desenvolvimento, é comum percebermos a necessidade de criar novas classes, uma vez que o foco agora está em como o sistema deve funcionar. Ou seja, como o sistema vai entregar suas funcionalidades. Os detalhes incluídos são relacionados, por exemplo, com tipos e domínio dos atributos; parâmetros, entradas e saídas das operações etc. Novas classes criadas podem ser de interfaces do sistema, bancos de dados, entre outras.
Modelo de classes de implementação
É a codificação das classes definidas nas fases de análise e projeto em alguma linguagem de programação, normalmente uma linguagem orientada a objetos (por exemplo, C++, Java, C# etc.). O modelo de implementação é construído na atividade de codificação de um processo de desenvolvimento
O exemplo da figura 7, extraído da obra de Bezerra (2015), ilustra a representação de uma classe em diferentes níveis de abstração. Observe que, em cada iteração do processo de desenvolvimento, são acrescentados mais detalhes sobre os atributos e operações.
Figura 7 – Exemplo de Classe ContaBancária em diferentes níveis de abstração.
Na especificação mais detalhada da classe ContaBancária do exemplo da figura 7, você pode observar a presença dos símbolos – e + antes dos nomes dos atributos e das operações, que representam sua visibilidade. Nessa mesma representação, temos as operações com seus parâmetros de entrada especificados (a Quantia em creditar e debitar).
Relacionamentos no Diagrama de Classes
Você já viu que especificar uma classe diz respeito a definir seus atributos e operações. Mas classes não existem isoladas, elas só fazem sentido quando se relacionam a outras, pois os objetos originados a partir delas trocam informações uns com os outros; e nisso reside a implementação de um sistema orientado a objetos.
Dizemos que os objetos colaboram uns com os outros. O desenho do Diagrama de Classes mostra como os objetos instanciados a partir dessas classes podem se relacionar. Existem diferentes tipos de relacionamentos possíveis, bem como diversos detalhes que podem ser acrescentados no diagrama para melhorar sua semântica. Trataremos deles a seguir.
A forma de relacionamento mais comum é chamada de associação e é representada no Diagrama de Classes por uma linha (normalmente um segmento de reta) ligando as classes às quais pertencem os objetos relacionados.
A figura 8 ilustra associações entre classes:
· Cliente faz Pedido;
· Professor ministra Disciplina.
Mas qual é o significado dessas associações? Quando ligamos as classes Cliente e Pedido significa que, durante a execução do sistema, haverá a possibilidade de troca de mensagens entre objetos dessas classes.
Figura 8 – Associações simples entre classes, elaborado com ferramenta ASTAH (2021)
As associações possuem diversas características que podem ser representadas, por escolha do analista, para prover um melhor entendimento do modelo: nome, multiplicidades, tipo de participação, direção de leitura e papéis.
Cliques nas barras para ver as características das associações.
Nome
Conforme a figura 8 mostra, os nomes das associações (ministra, faz) descrevem a relação que é estabelecida entre os objetos das classes associadas. Normalmente, são usados verbos ou expressões verbais para nomear associações.
Multiplicidades
As associações permitem representar a informação dos limites inferior e superior da quantidade de objetos aos quais outro objeto pode estar associado: são as chamadas multiplicidades. Cada associação em um Diagrama de Classes possui duas multiplicidades, uma em cada extremo da linha que a representa. Os símbolos que representam uma multiplicidade são apresentados na tabela 1.
	Apenas 1
	1..1 (ou 1)
	Zero ou Muitos
	0..* (ou *)
	Um ou Muitos
	1..*
	Zero ou Um
	0..1
	Intervalo Específico
	li..ls
Tabela 1 – Multiplicidades em um Diagrama de Classes. Tabela: Flavia Maria Santoro
Na figura 9, mostramos o exemplo com as multiplicidades correspondentes. Esses novos diagramas expressam mais do que o anterior. Eles informam que um professor pode ministrar nenhuma (zero) e no máximo três disciplinas (0..3). Uma disciplina precisa ser ministrada por pelo menos um professor, mas pode ser ministrada por muitos (1..*). Já um cliente pode fazer nenhum (zero) pedido, sem um limite máximo (0..*), eum pedido precisa ser feito por um cliente (1).
Figura 9 – Associações simples entre classes com multiplicidades, elaborado com ferramenta ASTAH (2021)
Tipo de participação
Indica a necessidade ou não da existência dessa associação entre objetos. A participação pode ser obrigatória ou opcional. Se o valor mínimo da multiplicidade de uma associação é igual a 1 (um), significa que a participação é obrigatória. Caso contrário, a participação é opcional. Por exemplo, a participação de Cliente e Professor nos exemplos da figura 9 é obrigatória, e a de Disciplina e Pedido é opcional. Isso significa que pode existir professores e clientes sem necessariamente estarem ministrando disciplinas ou fazendo pedidos.
Direção da leitura
A direção de leitura indica como a associação deve ser lida. Essa direção é representada por um pequeno triângulo posicionado próximo a um dos lados do nome da associação (como nos exemplos da figura 9).
Papéis
Quando um objeto participa de uma associação, ele tem um papel específico nela. Uma característica complementar à utilização de nomes e de direções de leitura é a indicação de papéis (roles) para cada uma das classes participantes em uma associação.
Classes associativas
São classes que estão ligadas a associações, em vez de estarem ligadas a outras classes. São também chamadas de classes de associação. Esse tipo de classe normalmente aparece quando duas ou mais classes estão associadas e seja necessário manter informações sobre a associação que existe entre elas.
É muito comum a necessidade de classes associativas em relacionamentos muitos para muitos, ou seja 0..* 0..*. Uma classe associativa é representada pela mesma notação utilizada para uma classe comum. A diferença é que aquela é ligada por uma linha tracejada a uma associação.
A figura 10 mostra um exemplo de classe associativa. Um professor ministra uma disciplina em determinada turma (que possui número, ano e semestre específicos).
Figura 10 – Exemplo de classe associativa, elaborado com ferramenta ASTAH (2021)
Autoassociação
Tem como objetivo relacionar objetos da mesma classe, mas cada objeto tem um papel distinto nessa associação. Por exemplo, na figura 11, objetos da classe Empregado estão associados entre si, um empregado como supervisor, que supervisiona outros empregados.
A figura 11 ilustra, também, o uso de papéis (roles) para distinguir o lado supervisor (multiplicidade 1) do lado supervisionado (lado muitos) da autoassociação.
Figura 11 – Exemplo de autoassociação, elaborado com ferramenta ASTAH (2021)
Todo-parte
Existe uma categoria especial de relacionamento que possui uma semântica (significado) particular: todo-parte.
Uma relação todo-parte entre dois objetos indica que um dos objetos está contido (é uma parte do) no outro, ou seja, o objeto do lado todo contém o do lado parte.
A UML define dois tipos de relacionamentos todo-parte: a agregação e a composição.
Atenção
A agregação e a composição são casos especiais da associação, logo, todas as características válidas para uma associação valem para agregações e composições. Agregações/composições são assimétricas no sentido que, se um objeto A é parte de um objeto B, o objeto B não pode ser parte do objeto A.
Agregações e composições propagam comportamento, pois um comportamento que se aplica a um todo, automaticamente se aplica às suas partes. Nas agregações/composições, as partes são normalmente criadas e destruídas pelo todo.
Uma agregação é representada graficamente como uma linha que conecta as classes relacionadas, com um diamante (losango) branco perto da classe que representa o todo. Uma composição é representada por meio de um diamante negro.
A figura 12 apresenta um exemplo de relacionamento de composição. Um pedido é composto de vários itens de pedidos.
Figura 12 – Exemplo de relacionamento de composição, elaborado com ferramenta ASTAH (2021)
A diferença entre agregação e composição é sutil, pois não é muito bem definida na UML. Ambas são relacionamentos todo-parte, mas pode-se dizer que, na agregação, a parte pode existir independentemente do todo; na composição, a existência da parte depende da existência do todo.
No exemplo da figura 12, não faria sentido a existência de ItemPedido se não existisse Pedido.
Exemplo
Um exemplo de agregação seria a associação entre Equipe e Jogador, em que este último é parte da Equipe; entretanto, um Jogador existe independentemente da existência da Equipe. Isso significa que a destruição de uma Equipe (todo) não implicaria na destruição do Jogador (parte), como ocorre na composição.
Herança
Outro relacionamento com semântica específica é o de herança, ou relacionamento de generalização/especialização. Esse tipo de relacionamento, diferente dos que você estudou, significa um relacionamento de generalidade ou especialidade entre as classes envolvidas. Por exemplo, o conceito animais é mais genérico que o conceito mamífero, que, por sua vez, é mais genérico que o conceito macaco.
Nesse tipo de relacionamento, as classes mais específicas herdam características das classes mais genéricas.
Usamos o termo subclasse para denotar a classe que herda as propriedades de outra classe mediante uma generalização. A classe que possui propriedades herdadas por outras classes é chamada de superclasse. No Diagrama de Classes, a herança é representada por uma flecha partindo da subclasse em direção à superclasse. Um relacionamento de herança representa um conjunto de objetos que compartilham um conjunto comum de propriedades (atributos, operações, associações), características inerentes à superclasse, além de possuírem características próprias.
A figura 13 mostra um exemplo do relacionamento de herança.
Figura 13 – Exemplo de relacionamento de herança, elaborado com ferramenta ASTAH (2021)
Nesse exemplo, um professor pode ser do tipo Tempo Integral ou Horista. Ambos possuem nome e matrícula, porém, o Professor Tempo Integral possui salário, e o Professor Horista possui valor de hora paga. Note que, além dos atributos da classe genérica (no exemplo, Professor), as classes especializadas herdam também as operações (não especificadas no exemplo), assim como os relacionamentos (no exemplo, a associação ministra) da classe genérica.
O diagrama de classes no processo de desenvolvimento de sistemas
A especialista Flavia Maria Santoro fala sobre o modelo de classes, sua finalidade, seus elementos e sua evolução ao longo do processo de desenvolvimento de sistemas.
Verificando o aprendizado
Parte superior do formulário
1. Na abordagem da orientação a objetos, o elemento central é a classe. Sobre os atributos de classes, podemos afirmar que:
descrevem os dados que deverão ser armazenados pelos objetos originados a partir dessa classe.
são as atividades do negócio representadas nas classes.
cada atributo de uma classe se relaciona com outros atributos de outras classes.
todos os atributos de uma classe são do mesmo tipo de dados.
um atributo só pode assumir um único valor em todos os objetos instanciados a partir da sua classe.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
Atributos são os dados de uma classe que assumem valores específicos nos objetos instanciados a partir dessa classe, dentro do conjunto de valores possíveis denominado domínio.
Parte superior do formulário
2. Assinale a lista que contém características de associações em Diagramas de Classes.
Atributo, relacionamento e operação.
Participação, nome, estado e atributo.
Nome, multiplicidades, direção de leitura, papéis e participação.
Multiplicidades, papéis, operação e herança.
Agregação, nome, herança.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
Diversos detalhes podem ser incluídos na especificação de relacionamentos entre classes, são eles: nome, multiplicidades, direção de leitura, papéis e participação. As demais alternativas contêm elementos que não dizem respeito a associações, como: atributo, operação, estado, herança, agregação.
MÓDULO 4
Empregar Diagramas de Objetos e de Pacotes paracontroles. Podemos, então, considerar três diferentes perspectivas e construir modelos que representem cada uma delas, tais como:
Os dados
As funcionalidades
Os controles
Outra perspectiva seria a visão externa, a de um usuário, que enxerga as funcionalidades necessárias, mas desconhece o que ocorre internamente. Essa seria mais uma perspectiva e mais um modelo que ajudaria nessa compreensão.
Confira algumas formas de abordar os sistemas computacionais por meio de visões.
Externa
Modela-se o ambiente em que o sistema está inserido, mostrando sua relação com os usuários 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.
Interacional
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 modelagem de sistemas, em que:
· Os modelos são 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 diagramas.
Com base no que acabamos de estudar, observe!
Modelagem 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.
(Bezerra, 2015)
Como veremos mais adiante, a UML é uma linguagem unificada de modelagem que permite a construção de um conjunto 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.
Atividade 1
Questão 1
Sobre os conceitos de modelos e modelagem, analise as assertivas a seguir.
 
I - Os modelos são representações da realidade.
 
II - Os modelos são construídos depois que os produtos são desenvolvidos.
 
III - A maquete de um empreendimento imobiliário mostra uma visão macro, do ponto de vista externo, de como será o empreendimento.
 
IV - Podemos ter apenas um modelo para cada produto.
 
V - Um protótipo de um novo avião pode ser considerado um modelo.
 
Com base em sua análise das assertivas, assinale a alternativa correta:
A
Estão corretas apenas as assertivas I, II, III e V.
B
Estão corretas apenas as assertivas I, III e V.
C
Estão corretas apenas as assertivas I e V.
D
Está correta apenas a assertiva III.
E
Está correta apenas a assertiva V.
Responder
Parabéns! A alternativa B está correta.
Vamos analisar cada assertiva:
São verdadeiras as opções: I, pois os modelos representam a realidade, antes de sua existência; III, já que uma maquete mostra o exterior do empreendimento e não esclarece nada sobre o interior das unidades; V, porque um protótipo é uma representação da realidade.
Estão incorretas as opções: II, já que os modelos são construídos antes dos produtos (realidade) para que possamos compreender melhor a sua complexidade e seu comportamento futuro; IV, pois podemos ter mais de um modelo para cada produto.
Desenvolvimento de sistemas computacionais
Conhecer a teoria do desenvolvimento de sistemas computacionais é fundamental para a revolução digital contemporânea. Ao entender os princípios fundamentais da criação de software, os profissionais são capacitados a projetar, implementar e otimizar sistemas computacionais complexos e eficientes.
Nesse contexto, o processo de desenvolvimento de sistemas em fases é uma abordagem estruturada para criar software. Começa com a análise dos requisitos do sistema, na qual as necessidades dos usuários são identificadas e documentadas. Em seguida, vem a fase de projeto, em que a arquitetura do sistema é planejada e as especificações técnicas são elaboradas. Após o projeto, entra-se na fase de implementação, quando o código é escrito e o sistema começa a ganhar vida. Finalmente, ocorre a fase de teste, na qual o software é submetido a uma série de testes para garantir sua funcionalidade e qualidade antes da implantação.
O processo de desenvolvimento de sistemas em fases
O desenvolvimento de sistemas computacionais é um processo que envolve pessoas e a necessidade de compreensão de uma realidade muitas vezes complexa e obscura, principalmente no início do desenvolvimento, quando o nível de abstração é alto e pouco se conhece da realidade. Podemos visualizar isso na imagem a seguir.
Realidade X Sistema.
Conforme as fases em que o processo de desenvolvimento é particionado se sucedem, o conhecimento sobre o sistema aumenta, diminuindo, consequentemente, o nível de abstração da realidade. Essa complexidade aumenta à medida que o tamanho do sistema cresce, requerendo um maior planejamento dos recursos a serem usados. O principal recurso no desenvolvimento de um sistema são pessoas, profissionais capacitados.
Primeiramente, precisamos entender as necessidades das pessoas que utilizarão o sistema e o que elas precisam que o sistema faça para desempenharem suas funções. Esse entendimento também requer que os profissionais responsáveis pela construção do sistema confirmem essa compreensão.
Mas como entender e confirmar a compreensão em uma linguagem ambígua como a nossa, tanto a falada como a escrita?
Se criarmos o sistema diretamente na linguagem de programação com base em uma compreensão suposta da realidade, certamente enfrentaremos problemas de interpretação inadequada. O sistema provavelmente não atenderá às necessidades dos usuários e acabará sendo abandonado. Para representar a realidade de maneira adequada e entender o contexto do sistema a ser desenvolvido, precisamos traduzir a realidade em modelos.
Com base no que estudamos até agora, vamos aprofundar nosso entendimento sobre as fases mais importantes.
Fases comuns e mais relevantes do processo de desenvolvimento
Os modelos nos ajudam a entender a realidade e discutir essa compreensão, reduzindo a complexidade e o nível de abstração.
Atenção
Os modelos são representações simplificadas da realidade, focando os elementos de interesse em um dado momento. Eles permitem abstrair o que não é relevante e concentrar naquilo que é essencial para o desenvolvimento do sistema.
Desde a década de 1960, muitos processos, métodos e diversas técnicas de desenvolvimento de sistemas foram criados e postos em prática, visando à construção de sistemas computacionais robustos, eficientes e de fácil manutenção.
Para gerenciar melhor a complexidade, os processos e metodologias de desenvolvimento de sistemas geralmente são divididos em fases. Embora cada processo ou metodologia possa ter sua própria divisão, de maneira geral, podemos identificar as seguintes fases (com algumas exceções). Confira!
Identificação dos requisitos
São 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
Envolve compreender o que o sistema deve fazer para atender às necessidades de seus usuários.
Projeto
Envolve a adequação dos requisitos à forma como serão implementados, utilizando a tecnologia adequada. Define-se a arquitetura e os componentes do sistema, bem como toda a infraestrutura do ambiente computacional necessária para sua construção, incluindo redes de computadores, banco de dados, linguagem de programação e outros elementos.
Implementação
Refere-se à 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.
Atividade 2
Questão 1
A modelagem de sistemas computacionais envolve a representação visual e conceitual de elementos, estrutura e processos de um sistema de software. Por que é tão importante traduzir a realidade em modelos durante as fases comuns e mais relevantes do processo de desenvolvimento de sistemasapoiar a especificação de um sistema
Ligando os pontos
Como você pode organizar os módulos de um sistema? E se quiser representar um conjunto de objetos, em um momento específico da execução, para guiar os testes?
É muito comum um sistema complexo conter centenas de elementos, e o diagrama de classes completo acaba trazendo certa confusão para os envolvidos, além de dificultar a definição de grupos com o mínimo de independência. O diagrama de pacotes permite agrupar as classes em módulos consistentes, facilitando a definição de entregas parciais funcionais do sistema, o que pode ser feito a cada Sprint dentro de um processo de desenvolvimento ágil.
Tomando como exemplo os sistemas de Streaming, as classes de Usuário, Colaborador e Cliente podem ser agrupadas em um módulo voltado para o acesso, enquanto Título e Ator fariam parte do módulo de catálogo. Se o sistema utiliza uma arquitetura em camadas, classes como Título e Ator seriam apenas entidades do catálogo, utilizadas para representar os valores do banco, sem métodos além dos construtores, enquanto teríamos classes como TítuloDAO e AtorDAO efetuando a consulta e manipulação dos registros no banco de dados.
Considerando uma arquitetura MVC (Model, View e Controller), os processos de negócio do sistema seriam efetuados por classes classificadas como controladores, com o acesso ao banco de dados intermediado pelas classes DAO (data access object). A arquitetura MVC promove uma divisão natural das classes, como pode ser observado na imagem seguinte, e influencia o mercado de tal forma que hoje temos vários frameworks voltados para a implementação de uma ou mais camadas, tendo como exemplos Spring, Hibernate e JSF (Java Server Faces).
 Diagrama de pacotes inicial para o sistema de streaming.
Em um sistema complexo, é interessante determinar testes para as funcionalidades desejadas, o que é, na verdade, uma exigência para as metodologias ágeis. Incluindo alguns valores no banco de dados manualmente, podemos inferir a coleção de objetos que resultará de uma consulta específica e definir um diagrama de objetos, os quais representarão um momento específico da execução do programa, como na imagem seguinte.
 Diagrama de objetos para teste de consulta.
Logo, é possível concluir que o diagrama de pacotes facilita muito a organização das entregas ao longo do desenvolvimento, sendo de grande valor na formalização das Sprints, enquanto o diagrama de objetos é extremamente útil para representar os valores de referência para as classes de teste unitário perante ações específicas dos usuários.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Parte superior do formulário
1. Metodologias ágeis, como XP (Extreme Programming), exigem a garantia de qualidade com base em testes, muitas vezes precedendo a própria codificação do sistema. Você, como analista de teste, sabe que os testes unitários precisam de um valor de referência; nesse contexto, qual diagrama permite expressar a referência em um ambiente orientado a objetos?
Diagrama de sequência
Diagrama de casos de uso
Diagrama de atividades
Diagrama de objetos
Diagrama de classes
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
O diagrama de objetos permite definir valores para um conjunto de objetos, funcionando como uma representação estática de determinado momento da execução do sistema. Instanciando os objetos da forma indicada pelo diagrama, conseguimos obter uma referência para os testes unitários.
Parte superior do formulário
2. Hoje, com a adoção da orientação a objetos, sistemas de médio porte podem conter centenas de classes, exigindo uma organização semântica. Um dos seus desafios, como engenheiro de software, durante a modelagem de um sistema é modularizar a solução; nesse caso, qual diagrama poderá ser adotado para demonstrar os agrupamentos de classes no sistema?
Diagrama de classes
Diagrama de pacotes
Diagrama de objetos
Diagrama de casos de uso
Diagrama de sequência
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
O diagrama de pacotes permite uma organização das classes em grupos, onde normalmente temos uma representação física em termos de diretórios, mas podendo ser baseada em namespace. A organização facilita a modularização do sistema, ao mesmo tempo em que agiliza a busca por classes, dentro de um universo menor de elementos.
3. Aplicativos que seguem a arquitetura MVC (Model, View e Controller) precisam de uma organização das classes de acordo com as camadas, mantendo a semântica de cada grupo. Como você expressaria graficamente a divisão citada?
Resposta
Espelho de resposta
O uso do diagrama de pacotes permite organizar as classes em grupos, de acordo com a semântica, e no caso da arquitetura MVC, podemos criar pacotes de base para cada uma das camadas, além de pacotes internos para cada módulo ou área de interesse do sistema, como: model.catalogo e model.financeiro.
Obrigado pelo feedback!
Visão geral do Diagrama de Objetos
Além do Diagrama de Classes, a UML define um segundo tipo de diagrama na perspectiva estática e estrutural do sistema: o Diagrama de Objetos.
Assim como objetos são instâncias de classes, os Diagramas de objetos podem ser vistos como instâncias de Diagramas de Classes.
Um Diagrama de Objetos UML representa uma instância específica de um Diagrama de Classes em determinado momento. Portanto, do ponto de vista gráfico, ele é bastante parecido com o Diagrama de Classes.
Saiba mais
Bezerra (2015) afirma que um Diagrama de Objetos exibe uma “fotografia” do sistema em certo momento, mostrando as associações estabelecidas entre objetos, de acordo com suas interações e com os valores que seus atributos assumem.
Um Diagrama de Objetos mostra os valores de atributos do conjunto de objetos que ele representa e como esses objetos se relacionam entre si. Um objeto, ou uma instância de uma classe, possui uma identificação única (não existem dois objetos iguais) e os seus atributos assumem determinados valores em um momento específico no tempo.
Os valores dos atributos podem sofrer alterações e, nesse caso, dizemos que o objeto sofreu uma mudança de estado.
Exemplo
Por exemplo, o objeto Maria, criado a partir de uma classe Pessoa, possui como valor do atributo Endereço: Rua das Palmeiras. Quando Maria muda de endereço, o valor do atributo passa a ser o novo endereço: Avenida Vieira Souto. Assim, em um diagrama de estados, o objeto Maria seria representado com o valor do atributo Endereço quando o diagrama foi criado.
No Diagrama de Objetos, não faz sentido falar em operações, que são as mesmas para todos os objetos de uma classe. Portanto, nesse diagrama, o elemento principal, o Objeto, possui apenas o nome e os atributos com seus valores.
Em um Diagrama de Objetos, cada objeto é representado por um retângulo com dois compartimentos. O compartimento superior mostra a identificação do objeto na forma de texto sublinhado:
:NomeClasse
nomeObjeto: NomeClasse
Lembre-se de que cada objeto é único e, portanto, esse nome identifica exclusivamente um objeto. A identificação do objeto pode ser omitida.
Por exemplo:
· Marta: Professor
· :Professor
No primeiro caso, o objeto da classe professor foi identificado com o nome Marta; no segundo, o analista optou por não caracterizar o objeto em si, significando que pode estar se referindo a qualquer objeto daquela classe.
A segunda representação é frequentemente usada na etapa de projeto do processo de desenvolvimento de sistemas, quando se representa a interação entre objetos (instâncias de classes) nos diagramas de sequência ou de comunicação.
No compartimento inferior (cuja utilização é opcional), aparecem os valores que os atributos definidos na classe assumem para este objeto. Dessa forma, deve mostrar uma lista de pares da forma: nome do atributo = valor do atributo.
A figura 14 reproduz o exemplo de Diagrama de Objetos mostrado por Bezerra (2015). Nesse exemplo, uma instância de pedido é associada a três instâncias de ItemPedido. Cada item,por sua vez, está ligado a um produto. Os valores para cada atributo de cada objeto são apresentados nesse diagrama.
Figura 14 – Exemplo de Diagrama de Objetos (BEZERRA, 2015)
Você pode observar também que não existem detalhes nos relacionamentos, tal como no Diagrama de Classes. Os relacionamentos no Diagrama de Objetos mostram uma situação específica em que aqueles objetos se encontram, não as possíveis relações entre eles.
No diagrama da figura 14, temos um Pedido que possui 3 Itens associados a ele, e 1 Produto associado respectivamente a cada Item.
A figura 15 mostra outro exemplo de Diagrama de Objetos, em que observamos que o Cliente Pablo está associado a 2 contratos de aluguel de carros diferentes. Cada contrato tem seu identificador e atributos próprios. Esse diagrama ajuda no entendimento da situação desse cliente.
Figura 15 – Exemplo de Diagrama de Objetos
Saiba mais
De acordo com Bezerra (2015), Diagramas de Objetos não são muito utilizados na prática. Mas eles podem ser úteis na atividade de validação no processo de desenvolvimento, pois permitem ilustrar e esclarecer certos aspectos de um Diagrama de Classes.
Mesmo antes de criar um Diagrama de Classes, você pode criar um Diagrama de Objetos para descobrir fatos sobre elementos específicos e suas associações ou para esclarecer dúvidas por meio de exemplos específicos. Além disso, ajuda na construção dos diagramas de interação (de sequência ou comunicação), pois estes utilizam a mesma notação.
Em resumo, os Diagramas de Objetos podem ter as seguintes aplicações:
Ajudar na análise de uma interação específica.
Mostrar uma visão geral de alto nível do sistema.
Validar um Diagrama de Classes.
Os Diagramas de Objetos podem ser usados também para verificar se o sistema foi desenvolvido conforme os requisitos, e até mesmo para analisar se uma regra de negócio está sendo cumprida.
Dica
Para criar esses diagramas, procure exibir associações entre objetos somente com uma ligação (por exemplo, uma linha única juntando dois objetos, sem setas ou outros detalhes), pois um Diagrama de Objetos tem por objetivo mostrar somente a existência de associações e não os tipos de associações, como em um Diagrama de Classes. Além disso, evite representar todos os objetos em um único Diagrama de Objetos, pois ele apresenta apenas um estado do objeto.
Visão geral do Diagrama de Pacotes
Muitos sistemas possuem uma quantidade bastante grande de casos de uso e classes, portanto, representá-los em um único diagrama é inviável devido à sua complexidade para o entendimento. Para resolver esse problema, usamos o elemento da UML chamado de pacote (do inglês, package).
Os pacotes servem para agrupar diagramas, tais como classes, casos de uso, ou mesmo outros pacotes. Normalmente, os grupos de classes são associados com módulos de programação do sistema. Uma classe só pode aparecer uma vez no mesmo pacote, mas pode estar presente em vários pacotes diferentes.
Um pacote representa um grupo de elementos que pode se relacionar com outros pacotes por meio de uma relação de dependência. É possível definir a visibilidade (conforme estudamos no Módulo 3) de pacotes e dos elementos contidos nele. Pacotes são úteis para prover uma visão geral de um conjunto grande de objetos; para organizar um modelo grande e agrupar seus elementos.
A representação gráfica de um pacote é um retângulo com uma aba no canto superior esquerdo, com o nome do pacote na aba ou no centro do retângulo. A figura 16 mostra um exemplo de pacotes que agrupam conjuntos de classes. O pacote Módulo Docente agrupa as classes relacionadas com professores, o Módulo Discente agrupa as classes relacionadas com alunos, e o Módulo Organização Curricular agrupa classes pertinentes à matriz curricular, em um sistema acadêmico.
Figura 16 – Exemplo de representação de pacote, elaborado com ferramenta ASTAH (2021)
Desdobramentos dos Diagramas no Pacote
As ligações entre pacotes são relacionamentos de dependência. Um pacote P1 depende de outro pacote P2, se algum elemento contido em P1 depende de algum elemento contido em P2.
A figura 17 mostra o Diagrama de Pacotes do exemplo do sistema acadêmico sem os relacionamentos explícitos entre as classes internas; apenas com a representação de dependências existentes entre os próprios pacotes. Ou seja:
Os pacotes se relacionam com outros pacotes por meio de um vínculo de dependência.
Figura 17 – Exemplo de representação de dependências entre pacote, elaborado com ferramenta ASTAH (2021)
As dependências entre pacotes mostram que um pacote depende ou influencia outro. As dependências podem ser divididas em dois tipos: acesso e importação.
Clique nas informações a seguir.
Dependência de acesso
Dependência de importação
Ambas são representadas por uma linha pontilhada com uma seta apontando para o pacote dependente.
Pacotes também podem formar grupos de pacotes e hierarquias. A figura 18 (Bezerra, 2015) mostra como pacotes podem ser agrupados dentro de outros pacotes, formando uma hierarquia de contenção.
Figura 18 - Agrupamento de pacotes (BEZERRA, 2015)
Além disso, como já vimos, existem três tipos de visibilidade de elementos dentro dos pacotes:
+ (público)
Visível por todos que importam ou acessam o pacote.
# (protegido)
Visível só pelos pacotes filhos (por relação de generalização).
– (privado)
Visível só por outros elementos do pacote.
Atenção
Note que aqui não se aplica a visibilidade de pacotes (~), que é aplicável tão somente a atributo de classe que seja visível a qualquer classe pertencente ao mesmo pacote no qual está definida a classe.
No contexto da modelagem de casos de uso, os pacotes podem ser utilizados com diversos objetivos. Alguns desses objetivos são: estruturar o modelo de casos de uso com base nos grupos de usuários do sistema; definir a prioridade na qual os casos de uso serão desenvolvidos; e definir o grau de correlação entre os casos de uso.
O critério para criar os pacotes é subjetivo e depende da visão e das necessidades do projetista.
Comentário
Normalmente, o projetista define uma semântica e aloca elementos similares em um pacote, pois esses elementos tendem a ser alterados em conjunto no mesmo pacote.
Um pacote bem estruturado tem as seguintes características:
É coeso em relação aos elementos incluídos.
É fracamente acoplado em relação à exportação apenas dos elementos que os outros pacotes precisam enxergar.
Não contém muitos alinhamentos, ou seja, possui um conjunto equilibrado de elementos.
Ao especificar um pacote, é uma prática usar a forma simples de ícone retangular, obscurecendo o seu conteúdo. No caso da necessidade de apresentar o seu conteúdo interno (como nas figuras 16 e 17), deve-se mostrar apenas os elementos necessários para a compreensão do significado.
Esse diagrama também é muito utilizado para ilustrar a arquitetura de um sistema, mostrando o agrupamento de suas classes. A figura 19 mostra um exemplo de Diagrama de Pacotes usado com o objetivo de organizar as classes de acordo com as camadas da arquitetura do sistema. Tipicamente, um sistema pode ser organizado conforme o padrão de projeto Model (Modelo), View (Visão) e Control (Controle).
Figura 19 – Exemplo de diagrama de pacotes
O pacote tem uma grande similaridade com a agregação. O fato de um pacote ser composto de modelos de elementos cria uma espécie de agregação de composição, pois, se esse pacote for destruído, todo o seu conteúdo também será.
Uso do diagrama de pacotes na modelagem de sistemas
A especialista Flavia Maria Santoro fala sobre o uso do diagrama de pacotes no agrupamento de diagramas de modelagem de sistemas.
Verificando o aprendizado
Parte superior do formulário
1. Qual das opções a seguir destaca uma aplicação do Diagrama de Objetos da UML?
Descrever os dados que deverão ser armazenados.
Apoiar a análise de uma interação específica do sistema.
Elaborar um novo diagrama de pacotes.
Garantir que o sistema terá a performance desejada.
Especificar os módulos do sistema.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
Diagramasde Objetivos podem, entre outras coisas, ajudar na análise de uma interação específica entre objetos do sistema.
Parte superior do formulário
2. Assinale a opção que apresenta um objetivo do pacote na UML.
Agrupamento de diagramas.
Representação da interação entre objetos.
Especificação de classes.
Permitir o polimorfismo.
Agregar atributos de classes.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
Os pacotes servem para agrupar diagramas, tais como classes, casos de uso, ou mesmo outros pacotes.
Conclusão
Considerações Finais
Estudamos os conceitos básicos para você iniciar a modelagem de um sistema orientado a objetos usando a UML. Observamos que a representação de requisitos funcionais deve ser feita por meio de um Diagrama de Casos de Uso, em conjunto com suas descrições textuais.
Você pode observar que a modelagem estrutural do sistema é feita com a identificação e representação de classes e seus objetos. Devemos definir seus atributos e operações e ficar atentos para os relacionamentos entre as classes, que podem ser associações simples, agregações e hierarquias. Vimos também que todos os elementos aprendidos podem ser agrupados em pacotes; além disso, podemos usar Diagramas de Objetos para apoiar no entendimento e análise de situações e interações específicas entre objetos.
Vimos que os diagramas da UML abordados neste tema podem ser usados na modelagem do domínio da aplicação, produzindo artefatos que serão refinados ao longo do processo de desenvolvimento do sistema. Na prática, nem todos esses diagramas são necessários em todos os tipos de sistema, destacando-se a relevância do diagrama de classes, por ser a base para a construção do banco de dados do sistema.
Podcast
Agora, a especialista Flavia Maria Santoro encerra o tema destacando os pontos mais relevantes da modelagem do domínio, as boas práticas na especificação de requisitos, diagrama de casos de uso e diagrama de classes.
0:00
10:51
Referências
ASTAH. Astah UML Modeling Tool. Consultado em meio eletrônico em: 31 jan. 2021.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 2015.
GÓES, W.M. Aprenda UML por meio de estudos de caso. São Paulo: Novatec, 2014.
IEEE STANDARD GLOSSARY of Software Engineering Terminology. In: IEEE Std. 610.12-1990, 31 dez. 1990.
LIMA, A. S. UML 2.0: Do Requisito à Solução. São Paulo: Érica, 2005.
MEDEIROS, E.S. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson Markron Books, 2004.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
Descrição
Uso de diagramas de Linguagem Unificada de Modelagem (UML) na fase de projeto de sistemas de informação.
PROPÓSITO
Compreender os modelos que fazem parte da UML, empregando os diagramas de interação, de classes de projeto, de atividades, de estado, de componentes e de implantação, durante a fase de projeto de software.
OBJETIVOS
Módulo 1
Empregar os diagramas de interação no projeto de sistema
Módulo 2
Revisar o diagrama de classes da análise no projeto de sistema
Módulo 3
Empregar os diagramas de estado e de atividades no projeto de sistema
Módulo 4
Empregar os diagramas de componentes e de implantação
Preparação
Antes de iniciar o conteúdo, é indicado que seja instalado em seu computador um programa que lhe permita elaborar modelos, sob a forma de diagramas da UML (Linguagem Unificada de Modelagem). Nossa sugestão inicial é o Astah Free Student License e será necessário usar seu e-mail institucional para ativar a licença. Preencha os dados do formulário no site do software, envie e aguarde a liberação de sua licença em seu e-mail. Ao recebê-la, siga as instruções e instale o produto em seu computador.
Sugestões de links adicionais de programas livres para modelagem de sistemas em UML (UML Tools) podem ser encontradas em buscas na internet.
Introdução
A modelagem de um software pode, de fato, determinar a quantidade de problemas que terão que ser tratados durante o desenvolvimento. Softwares de sucesso, que têm sua implantação quase sem nenhum tipo de erro, certamente contaram com um bom processo de modelagem durante seu desenvolvimento. Ou seja, um bom produto de software é sempre concebido por um bom processo de desenvolvimento, iniciado com a modelagem do sistema.
O processo de desenvolvimento conta com diversos métodos e técnicas para que o produto tenha a melhor qualidade possível, sendo a modelagem uma das técnicas utilizadas. Modelar algo é construir uma representação abstrata de um artefato do mundo real.
A modelagem conta com diversas regras e diretrizes que têm que ser respeitadas para se construir um modelo de qualidade para o software. Todas as funcionalidades implementadas pelo software, assim como todos os elementos de dados que utilize e as regras que devem ser seguidas, precisam ser pensadas, discutidas e estruturadas antes do início de sua construção, de modo que haja um completo entendimento de todo esse universo, não só por parte dos usuários, mas também dos desenvolvedores. Saber identificar cada característica do software durante seu projeto é importante para que venha de fato atender às necessidades dos usuários e cumprir com todas as regras a serem executadas por ele.
Vamos entender como construir os diagramas ao longo da etapa de projeto (ou design) de software. Nesta parte do desenvolvimento, alguns outros diagramas já terão sido construídos e precisam ser respeitadas suas regras e definições. Para isso, vamos ver as técnicas de concepção e de modelagem desses diagramas, assim como seus atributos e modelos. Por fim, vamos apresentar e discutir como aplicá-los.
MÓDULO 1
Objetivo: Empregar os diagramas de interação no projeto de sistema
Ligando os pontos
Como podemos transmitir para a equipe de desenvolvimento uma visão bem consolidada do fluxo de execução? Se você fosse responsável por essa tarefa, saberia fazer isso? Vamos entender melhor essa questão a seguir. 
Após a definição do descritivo de um caso de uso, devemos expressar o fluxo de execução de forma gráfica, contendo os atores e objetos participantes, segundo a sequência lógica de mensagens que são trocadas entre os envolvidos.
Certamente, estamos nos referindo ao diagrama de sequência, que constitui o guia gráfico mais completo para a equipe de desenvolvimento no que se refere à programação do sistema. Cabe destacar que existe o diagrama de comunicação, que possui a mesma semântica e diferente sintaxe.
Apesar de o diagrama de sequência oferecer, inicialmente, uma transposição direta do fluxo de execução descrito no caso de uso, aqui devem ser considerados elementos estruturais, como a presença de controladores e classes do tipo DAO (Data Access Object), levando ao acréscimo de objetos relacionados à arquitetura adotada.
Este é um diagrama menos conceitual e muito mais próximo da implementação, que envolve elementos tecnológicos não considerados na análise inicial do negócio.
Considerando o descritivo de caso de uso da busca de títulos em um sistema de streaming, dentro de uma arquitetura MVC (Model, View e Controller), teríamos, além do cliente que interage com o sistema, uma tela de busca, um controlador para as solicitações efetuadas e uma classe DAO para acesso ao banco. Teríamos ainda a entidade para representação de um registro, transportada em coleções entre as camadas da arquitetura.
O processo é iniciado com o usuário digitando os valores e clicando no botão de busca, que, segundo a arquitetura, deverá enviar uma mensagem para o controlador com o texto parcial a ser encontrado.
Aqui, já temos alguns pontos a considerar, como o uso de spring ou EJB (Enterprise Java Beans) e a adoção de um Session Bean como controlador padrão para este último.
Analisando a próxima camada, o controlador deve comunicar-se com o DAO, que terá como responsabilidade a execução do comando SQL e o mapeamento objeto-relacional, com os registros convertidos em entidades.
Novamente, o uso de frameworks pode modificar o diagrama, como na adoção do JPA (Java PersistenceArchitecture), onde as entidades são anotadas, para que o mapeamento seja automatizado. Além disso, precisamos de um EntityManager para efetuar as ações de consulta e persistência.
O diagrama descrito pode ser observado a seguir:
 Diagrama de sequência para busca de título.
Podemos concluir que se trata de um diagrama voltado para a implementação, com elementos tecnológicos que vão além das regras naturais do negócio, o que justifica a utilização pela equipe de desenvolvimento.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Parte superior do formulário
1. Um diagrama de sequência representa um fluxo de execução específico, que demonstra, de forma gráfica, outro artefato da modelagem orientada a objetos, mas pode incorporar elementos tecnológicos que não são abordados na análise preliminar.
De acordo com sua análise do caso apresentado e com base em sua experiência sobre o assunto, qual seria esse outro artefato?
Lista de requisitos não funcionais.
Diagrama de casos de uso.
Lista de requisitos funcionais.
Descritivo de caso de uso.
Diagrama de classes.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
O descritivo de um caso de uso especifica o fluxo de execução necessário para que determinada funcionalidade do sistema seja satisfeita. Inclusive, embora não tenha um formalismo absoluto, é recomendável que o descritivo de caso de uso especifique o requisito funcional que será satisfeito por ele. Como trata do fluxo de execução, ele serve de base para a definição do diagrama de sequência, embora possa ocorrer a inclusão de elementos tecnológicos e arquiteturais que não fazem parte da análise inicial.
Parte superior do formulário
2. Quando construímos o diagrama de sequência, estamos representando o fluxo de execução de determinado processo do sistema. Para isso, precisamos posicionar atores e objetos participantes, especificar as mensagens trocadas sequencialmente e representar o retorno de valores em determinadas circunstâncias.
Considerando que você é um analista de teste e está implementando um check-list de qualidade para o diagrama de sequência. Como deverá estar representado o retorno de valor?
Seta tracejada da direita para a esquerda.
Linha vertical, partindo do ator ou objeto.
Seta sólida da esquerda para a direita.
Figuras posicionadas no topo do diagrama.
Seta tracejada da esquerda para a direita.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
A criação de um diagrama de sequência é iniciada com os atores e objetos posicionados no topo, representados pelas figuras de seus estereótipos. Partindo dos atores e objetos, temos linhas verticais. As mensagens trocadas entre eles são expressas, de forma sequencial, por meio de setas sólidas da esquerda para a direita, com exceção da mensagem de criação de objeto, que é tracejada. Quando alguma mensagem retorna valor para o emissor, a representação adequada é uma seta tracejada da direita para a esquerda.
3. Ao fazer o desenho de um diagrama de sequência, você utilizou diversas figuras para representar atores e objetos, as quais são minimamente padronizadas de acordo com os estereótipos mais comuns. Para você, qual é a vantagem de utilizar o ícone de um estereótipo?
Resposta
Espelho de resposta
Os ícones padronizados dos estereótipos permitem a compreensão rápida da constituição do elemento frente à arquitetura e à tecnologia adotadas. Temos, por exemplo, o ícone para boundary class, que representa uma classe limítrofe, como uma das telas do sistema, e controller, um controlador que, no caso tecnologia EJB, define o conjunto formado por Session Bean, interfaces e anotações para configuração.
Avalie este módulo:
 
    
Atividades do desenvolvimento de software
As atividades típicas de um processo de desenvolvimento de software compreendem, de modo geral, independentemente do processo adotado, as seguintes etapas:
Levantamento de requisitos
Análise
Projeto (design)
Implementação
Testes
Implantação
Como se percebe, essas atividades são realizadas por etapas ou fases, em que uma etapa depende dos artefatos resultantes das anteriores. Neste conteúdo, o foco é a etapa de projeto (ou design) do sistema, na qual existe uma dependência de seus artefatos em relação aos artefatos elaborados na fase de análise (ou modelagem). A figura a seguir ilustra os diagramas da UML que, usualmente, são construídos nos modelos de análise e de projeto. Trata-se de uma visão prática, uma vez que a especificação da linguagem UML não determina quais diagramas devam ser usados em quais etapas e tampouco em que ordem devem ser elaborados.
Modelos da fase de análise X modelos da fase de projeto
Diagramas de interação
Em um sistema computacional orientado a objetos, as funcionalidades (casos de uso) são fornecidas através de serviços resultantes da colaboração de grupos de objetos. Estes interagem através de comunicações, de forma que juntos realizem os casos de uso.
As comunicações são explicitadas através da representação da interação durante as comunicações. Para tal, temos na UML os diagramas de interação, usados para mostrar o comportamento interativo de um sistema. Os diagramas de interação descrevem o fluxo de mensagens e fornecem contexto para uma ou mais linhas da vida de objetos dentro de um sistema. Além disso, os diagramas de interação podem ser usados para representar as sequências organizadas dentro de um sistema e servir como um meio para visualizar dados em tempo real.
Os diagramas de interação podem ser implementados em diversos cenários para fornecer um conjunto exclusivo de informações. Eles podem ser usados para modelar um sistema, como uma sequência de eventos organizada por tempo; fazer a engenharia reversa ou avançada de um sistema ou processo; organizar a estrutura de vários eventos interativos; mostrar, de forma simples, o comportamento de mensagens e linhas da vida dentro de um sistema e até identificar possíveis conexões entre elementos de linhas da vida. Seus principais objetivos são:
Obter informações adicionais para completar e aprimorar outros modelos (modelo de casos de uso e de classes).
Fornecer aos programadores uma visão detalhada dos objetos e das mensagens envolvidos na realização dos casos de uso do sistema.
Existem dois tipos de diagrama de interação:
Diagrama de comunicação
Diagrama de sequência
Cada tipo de diagrama aborda uma perspectiva diferente do comportamento de um sistema. Vamos ver a seguir os conceitos básicos de cada diagrama, como construí-los e utilizá-los.
Num diagrama de interação, as mensagens trocadas entre objetos, em geral, serão métodos da classe a que pertence o objeto receptor da mensagem, com os mesmos elementos oriundos das mensagens. Isso será percebido ao estudarmos os Diagramas de Classe de Projeto.
Os diagramas de interação servem para refinar o diagrama de classes na etapa de projeto, com o detalhamento dos métodos.
Isso nos mostra que os diagramas da etapa de projeto apresentados na figura anterior estão relacionados entre si e com os diagramas da etapa de análise, de modo que a construção de um diagrama depende de outros.
Diagrama de sequência
Diagramas de sequência recebem esse nome porque descrevem, ao longo de uma linha do tempo, a sequência de comunicações entre objetos de um sistema de informação. Em geral, são construídos logo após os diagramas de caso de uso e de classes, pois têm como principais objetivos:
Documentar casos de uso.
Mostrar como os objetos do sistema se comunicam através de mensagens em ordem temporal.
Validar se todas as operações das classes foram identificadas e declaradas.
Validar a existência de um objeto necessário ao funcionamento do sistema.
Atenção
Não é necessário construir diagramas de sequência para todos os casos de uso do sistema. Apenas os mais complexos, relacionados com o negócio da aplicação, são explorados por esse tipo de diagrama. Ele pode ser bastante trabalhoso e criá-lo para todas as partes do sistema pode não ser produtivo e nem ter benefícioscompensatórios.
Dependendo da complexidade ou do número de objetos envolvidos ou da presença de desvios condicionais no caso de uso, vários diagramas de sequência serão necessários para representar as interações do sistema. Assim, devemos construir um diagrama de sequência principal, descrevendo as sequências normais entre os objetos (fluxo normal) e diagramas complementares, descrevendo sequências alternativas (fluxos alternativos) e tratamento de situações de erro (fluxos de exceção).
Atenção
Diagramas de sequência são complementares aos diagramas de caso de uso.
Os diagramas de caso de uso são bastante completos nas descrições textuais, porém não são capazes de mostrar como os objetos do sistema se comunicam por intermédio de mensagens em ordem temporal, nem verificar se todas as operações das classes foram validadas e declaradas. Essas funções são muito mais bem executadas pelos diagramas de sequência.
Exemplo esquemático de diagrama de sequência.
Elementos do diagrama de sequência
O diagrama de sequência é composto de diversos tipos de elementos. Vamos aqui apresentar cada um deles.
Objetos
São apresentados na parte superior do diagrama (um ao lado do outro) na dimensão horizontal.
Não há uma ordem específica de apresentação obrigatória. Sua ordem é relevante somente como forma de tornar o diagrama mais legível. Ou seja, por exemplo, uma boa prática pode ser colocar os elementos que têm mais interação mais próximos. Já no centro e abaixo dos objetos temos sua linha da vida (linha reta tracejada). Todo e qualquer objeto ou classe nesse diagrama pode ser representado com um retângulo com o seu nome, mas existem notações específicas para tipos especiais de objetos. São quatro tipos especiais, a saber:
Clique na barra para ver as informações.
Ator
É uma entidade externa que interage com o sistema enviando ou recebendo dados. Um ator é representado pelo estereótipo de boneco magro (“palito”), como nos diagramas de casos de uso. Mensagens podem ser trocadas entre atores, ou entre atores e objetos ou classes de fronteira.
Exemplo de Ator. Elaborado na ferramenta Astah UML.
Fronteira
É uma classe ou um objeto responsável pela interface entre o sistema de informação e seus usuários, ou pela comunicação entre dois ou mais sistemas. Em geral, são programas (formulários, interfaces, janelas) que capturam, processam dados e exibem informações. É através da classe de fronteira que os atores (usuários) terão seus requisitos atendidos pelo sistema.
Exemplo de Fronteira. Elaborado na ferramenta Astah UML.
Controle
É uma classe ou um objeto usado quando os desenvolvedores optam por separar as regras de negócio, as manipulações de dados e o sequenciamento de tarefas da interface de comunicação do sistema com o usuário, seguindo um padrão de projeto conhecido como MVC (do inglês Model – View – Controller). Dessa forma, a classe de fronteira (View) só existe como interface para receber e exibir dados. Todas as outras tarefas são executadas pela classe de controle (Controller).
Exemplo de Controle. Elaborado na ferramenta Astah UML.
Entidades
São classes ou objetos responsáveis por armazenar e gerenciar os dados do sistema, bem como por mostrar a estrutura lógica e estática dos dados (Model no padrão MVC).
Exemplo de Entidade. Elaborado na ferramenta Astah UML.
Linda da Vida
Compõe a dimensão vertical (tempo) de cada objeto do diagrama. As linhas de vida representam a sequência na qual a vida do objeto transcorre durante a interação. Podem apresentar criação ou destruição de objetos. Quando são criadas interações entre os objetos, um retângulo sobre a linha é colocado (automaticamente pelas ferramentas de desenho de diagrama), identificando a interação. Mais de um retângulo pode existir em um único objeto. Esse retângulo é chamado de tempo de vida da interação.
Exemplos de linhas de vida (destacados em vermelho). Elaborado na ferramenta Astah UML.
Mensagens
São os serviços solicitados de um objeto a outro ou a ele mesmo, e as respostas a essas solicitações. Uma mensagem é representada por um segmento de reta, contendo uma seta em uma das suas extremidades. As mensagens são acompanhadas de um rótulo contendo seu nome. Pode conter também parâmetros da mensagem. As mensagens podem ser síncronas, assíncronas, de retorno e de criação de objeto. Para cada uma delas, a linguagem usa notações diferentes. Na UML, o rótulo de uma mensagem deve seguir a seguinte sintaxe:
[[expressão-sequência] controle:] [v :=] nome [(argumentos)]
Atenção
Os colchetes [ ] indicam que o elemento é opcional. Note que o único termo obrigatório corresponde ao nome da mensagem.
Muitas vezes é necessário indicar que o termo controle está associado a uma expressão lógica. Nesse caso, a sintaxe para o termo controle pode ser uma condição ou uma iteração:
‘*’ ‘[’ cláusulaiteração ‘]’
‘[’ cláusulacondição ‘]’
Onde o símbolo * significa repetições da cláusula iterativa. Nessa sintaxe, os elementos entre aspas simples ‘ ‘ significam que fazem parte da expressão.
Tipos de setas X tipos de mensagens
Exemplos de Mensagens (destacadas em vermelho). Elaborado na ferramenta Astah UML
Mensagens de iteração
São mensagens que podem ser enviadas repetidas vezes. São precedidas de um asterisco e representadas dentro de colchetes.
Exemplo de Mensagens de iteração. Elaborado na ferramenta Astah UML
Condições de guarda
São mensagens que tem indicada uma condição para seu envio.
Exemplo de condições de guarda. Elaborado na ferramenta Astah UML.
Autochamada
São mensagens que partem do objeto de origem e atingem a linha de vida dele mesmo disparando operações.
Exemplo de autochamada. Elaborado na ferramenta Astah UML.
Ocorrência de interação
São elementos de modelagem úteis quando se deseja simplificar um diagrama e extrair uma porção para outro, ou quando existe uma porção de ocorrência que se possa fazer reuso em outro diagrama. É representado por uma moldura com a etiqueta “ref” que se refere a outro diagrama de sequência.
Exemplo de ocorrência de interação. Elaborado na ferramenta Astah UML.
Opt
São elementos que permitem tornar um trecho da interação opcional.
Exemplo de interação opcional “opt”. Elaborado na ferramenta Astah UML.
Loop
São elementos que permitem repetir um trecho da interação até “n” vezes.
Exemplo de interação repetida “loop”. Elaborado na ferramenta Astah UML.
Alt
São elementos que permitem que um trecho da interação seja alternativo.
Exemplo de interação alternativa “alt”. Elaborado na ferramenta Astah UML.
Diagrama de comunicação
Diagramas de comunicação servem para mostrar como os objetos interagem para executar o comportamento de um caso de uso ou de parte dele, para determinar interfaces e responsabilidades de classes e definir os papéis dos objetos que executam determinado fluxo de eventos. Mostram a comunicação, ou seja, o fluxo de mensagens que ocorre entre os objetos de um sistema de informação, assim como o diagrama de sequência. Os dois expressam informações semelhantes, mas numa forma de exibição diferente.
Então, qual diagrama usar?
Diagrama de Sequência
Se o objetivo for apresentar o fluxo de mensagens no decorrer do tempo, utilize o diagrama de sequência.
Diagrama de comunicação
Se a intenção for de dar ênfase a como os objetos estão vinculados e quais mensagens trocam entre si, use o diagrama de comunicação.
No diagrama de comunicação, um vínculo é uma associação que identifica a ligação entre dois objetos envolvidos em um processo e é caracterizado pelo envio ou recebimento de uma mensagem ou de ambos. As mensagens enviadas de um objeto para outro são representadas por segmentos de retas com uma seta em uma das extremidades, indicando sua direção.
Mensagens devem ter nome, parâmetros (opcional) e a sequência que é expressa por números, assim como no diagrama de sequência.
Exemplo esquemático de diagrama de comunicação correspondente ao diagrama de sequência, anteriormente apresentado.
O exemplo esquemático acima ilustra a correspondência que existe entre o diagrama de sequência e o diagrama de comunicação. Os mesmos objetos sãoenvolvidos, trocando as mesmas mensagens. O fluxo de execução das mensagens, que no diagrama de sequência é determinado pela ordem temporal de cima para baixo, aqui no diagrama de comunicação é determinado pela numeração ordenada das mensagens.
Como construir um diagrama de interação
Para criação de um diagrama de interação (sequência ou comunicação), você pode seguir os seguintes passos (em geral):
1. Determine o caso de uso que será modelado e identifique suas operações
2. Para cada operação, identifique os objetos que farão parte de sua interação.
3. Identifique as conexões e os relacionamentos entre eles e, em seguida, categorize-os.
4. Identifique a sequência de fluxos de mensagens na interação entre os objetos.
5. Identifique os tipos de mensagens, bem como sua sequência.
6. Em seu software de diagramas UML, selecione as formas apropriadas para criar o diagrama.
7. Insira um rótulo para todas as formas para representar cada evento, interação e mensagem em seu sistema.
8. Dê nome ao seu diagrama usando algo que realmente o identifique. Com o volume, pode ficar complexa a busca pelo diagrama, caso use nomes sem muita semântica.
Dica
Não se recomenda incluir o ator nem o objeto de fronteira primeiramente, porque isso dificulta o entendimento. É mais recomendado iniciar a modelagem da interação com a representação do recebimento da mensagem para ativação da operação de sistema, no caso de uso. Essa recomendação ajuda a separar a lógica do domínio e a lógica da interface com o usuário.
As classes conceituais identificadas, que participam em cada caso de uso, correspondem às entidades do mundo real envolvidas na tarefa do caso do uso, como se este fosse executado manualmente. Durante a modelagem de interações, objetos dessas classes participam da realização de um ou mais casos de uso. Por outro lado, durante a modelagem de interações, o projetista pode ter a necessidade de adicionar classes de software (ou seja, classes da aplicação que não têm correspondência no mundo real) que ajudem a organizar as tarefas a serem executadas. Essas classes de software normalmente são necessárias para manter a coesão e o acoplamento das demais classes em um nível adequado.
Durante a aplicação do procedimento descrito acima, o projetista deve procurar construir diagramas de interação o mais inteligíveis possível. Por exemplo, é possível utilizar notas explicativas para esclarecer algumas partes do diagrama de interação. Essas notas podem conter texto livre ou pseudocódigo para orientar a programação. Outra estratégia que ajuda a construir um modelo de interações mais inteligível é utilizar os recursos de modularização (alt, loop, opt).
Atenção
Sempre que for adequado, o projetista deve fazer, com base nos princípios de projeto, com que as classes de domínio enviem mensagens entre si. Dessa forma, o controlador envia uma mensagem para um objeto do domínio e este, por sua vez, dispara o envio de mensagens para outros objetos do domínio, o que evita que o controlador precise ter conhecimento desses últimos.
Em que momento construir o modelo de interações
Alguns textos sobre modelagem de sistemas orientados a objetos indicam o início da modelagem de interações já na atividade de análise. Outros defendem o início de sua construção somente na etapa de projeto. O fato é que a distinção entre essas duas fases não é tão nítida na modelagem orientada a objetos e a modelagem de interações pode ser realizada em ambas as fases.
Na análise, podemos começar a construir o modelo de interações logo depois que uma primeira versão do modelo de casos de uso estiver pronta. Inicialmente, o modelo de interações pode ser utilizado para representar apenas os objetos participantes em cada caso de uso e com mensagens exibindo somente o nome da operação. Posteriormente (na etapa de projeto), esse modelo deve ser refinado, incluindo criação e destruição de objetos, detalhes sobre o tipo e assinatura completa de cada mensagem etc.
No caso do processo incremental e interativo de desenvolvimento, onde os modelos evoluem em conjunto durante o desenvolvimento do sistema, embora esses modelos representem visões distintas do sistema, eles são interdependentes. Os itens a seguir demonstram como o modelo de interações se relaciona aos de casos de uso e de classes.
Clique na barra para ver as informações.
Modelo de casos de uso ➔ modelo de interações
Utilizamos os cenários extraídos do modelo de casos de uso como fonte de identificação de mensagens na modelagem de interações. É adequado que se verifique se cada cenário relevante para todos os casos de uso foi considerado na modelagem de interações.
Modelo de classes de análise ➔ modelo de interações
Utilizamos informações provenientes do modelo de classes para construir modelos de interações. Em particular, algumas responsabilidades já podem ter sido definidas durante a modelagem de classes de análise. A notação do diagrama de interações não precisa ser totalmente utilizada na fase de análise. Em particular, podemos definir diagramas de interação que apresentam as mensagens apenas com os seus nomes. Essa definição inicial deve ser refinada posteriormente com a utilização da sintaxe mais avançada.
Modelo de interações ➔ modelo de casos de uso
A partir do conhecimento adquirido com a construção do modelo de interações, podemos aperfeiçoar e validar os cenários do modelo de casos de uso.
Modelo de interações ➔ modelo de classes
É pela construção de modelos de interações que informações necessárias para a alocação e o detalhamento de operações (métodos) para classes surgem. Durante a construção de um diagrama de interação, pode ser que algumas informações necessárias em certa classe de análise ainda não existam, em virtude de não terem sido identificadas anteriormente. Portanto, além da identificação de operações, é provável que novos atributos sejam identificados durante a modelagem de interações. Outro elemento do modelo de classes que é comumente identificado ou validado pela construção do modelo de interações são as associações: uma mensagem entre objetos implica a existência de uma associação entre as classes envolvidas. Também é comum a situação em que identificamos novas classes durante a modelagem de interações, principalmente aquelas relacionadas ao domínio da solução do problema.
Visão geral dos diagramas de interação
No vídeo a seguir são apresentados os componentes do diagrama de sequência e do diagrama de comunicação.
Verificando o aprendizado
Parte superior do formulário
1. Marque a opção que não apresenta uma característica do diagrama de sequência:
Documentam casos de uso.
Validam se as operações das classes foram declaradas
Mostram as mensagens entre objetos.
São necessários em todos os casos de uso do sistema.
Descrevam ao longo de uma linha do tempo a sequência de comunicações
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
Não há necessidade de construção de diagramas de sequência para todos os casos de uso de um sistema, mas apenas para os casos de uso primários, ou seja, aqueles que representam atividades típicas do negócio da aplicação.
Parte superior do formulário
2. Assinale a alternativa que indica uma atividade do processo de construção dos diagramas de interação:.
Identificar a sequência de fluxos de mensagens na interação entre os objetos.
Identificar os diagramas de classe.
Listar cada atributo e método do diagrama de classes.
Identificar componentes do software.
Listar interfaces do software.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
A sequência de fluxos de mensagens é uma atividade importante do processo de construção dos diagramas de interação, seja de sequência ou de comunicação, pois é através das mensagens que ocorre a interação entre os objetos do sistema.
MÓDULO 2
Objetivo: Revisar o diagrama de classes da análise no projeto de sistema
Ligando os pontos
De forma geral, os diagramas sofrem grandes modificações ao longo do desenvolvimento do sistema. Como podemos reconhecer as funcionalidadesque devem ser agregadas ao diagrama de classes? Vamos descobrir?
À medida em que evoluímos da nebulosidade inicial dos requisitos para os descritivos de casos de uso e a consequente concepção do fluxo de execução, por meio dos diagramas de sequência, nós nos tornamos capazes de inferir novas classes e funcionalidades adicionais para classes já existentes.
Mais que isso: a adoção de uma arquitetura de software específica, como MVC (Model, View e Controller) norteia a divisão de responsabilidades entre as classes estruturais padronizadas, como, por exemplo, criação das entidades de catálogo e elementos DAO (Data Access Object) associados.
Vamos observar o fluxo de execução na busca de títulos em um sistema como o da Netflix, tendo como base de implementação a persistência com JPA (Java Persistence Architecture) e controle via EJB (Enterprise Java Beans), dentro da arquitetura MVC com DAO.
A tela de busca deve ter um botão, a partir do qual a interatividade com o usuário fará com que o texto digitado seja passado como parâmetro, em uma chamada para o método buscar do controlador EJB, iniciando um processo que envolverá a criação de uma instância de TituloDAO.
Embora a relação com o EntityManager deva ser feita pelo container do EJB, seria na classe TituloDAO que teríamos a invocação do gerenciador, com a passagem da instrução correta na sintaxe JPA, para gerar um objeto do tipo Query. Após efetuar a consulta desejada, com base no método getResultList, teremos o retorno de um conjunto de entidades de Título, ao nível do controlador, repassado para a tela de consulta.
Na última camada, na qual todo o processo também foi iniciado, a coleção de entidades será recebida por tela Busca, em que podemos ter uma rotina para preenchimento da tela com as informações de cada título. Devido à natureza do negócio, elementos importantes para a visualização do título incluem uma imagem da capa, nome, duração em minutos e sinopse.
A funcionalidade deve ser iniciada por uma classe ativa – no caso, um usuário do tipo cliente, que deve estar logado para efetuar a pesquisa. Nesse ponto, há dois métodos que se tornam evidentes para a classe, que são logar e buscar Título, além de um atributo que sinalize o status de logado – basicamente um valor booleano.
Podemos concluir que a análise do fluxo de execução, descrito em casos de uso e diagramas de sequência, levará à correção do diagrama de classes, com o acréscimo de atributos e métodos relacionados à implementação, além de classes específicas para a arquitetura e elementos tecnológicos associados, como é possível observar no exemplo a seguir:
 Diagrama de classes de projeto.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Parte superior do formulário
1. Em diversas situações, usamos uma classe no lugar de outra, sem que seja definido um atributo do tipo da segunda classe. Uma situação comum é quando ocorre a criação de uma instância no fluxo de execução de determinado método. Nesse caso, que tipo de relacionamento você recomendaria?
Herança
Polimorfismo
Dependência
Composição
Agregação
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
A relação correta seria de dependência, representada por uma seta tracejada apontando para a segunda classe. Por exemplo, em uma arquitetura MVC, as entidades são uma representação dos dados e devem ser utilizadas pelo DAO, pelo controlador e pelas telas, mas não serão atributos de nenhum deles, já que são apenas instanciadas em meio a algum método ou utilizadas como parâmetros.
Parte superior do formulário
2. A definição de um diagrama de classes de projeto envolve a complementação da versão de análise com o acréscimo de atributos, métodos e classes, os quais podem ser extraídos dos descritivos de caso de uso ou adotados como consequência da utilização de tecnologias e arquiteturas específicas.
No caso da navegabilidade de associações, as associações entre classes podem ser classificadas em bidirecionais e unidirecionais. Uma associação bidirecional indica que há um conhecimento mútuo entre os objetos associados.
Imagine que você é engenheiro de software e precisa definir as navegabilidades no diagrama de classes de projeto. Qual diagrama permitiria que você fizesse isso?
Diagrama de casos de uso
Diagrama de sequência
Diagrama de estado
Diagrama de atividades
Diagrama de componentes
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
A definição da navegabilidade depende da troca de mensagens realizadas nas interações entre objetos do sistema. Nesse caso, o engenheiro de software deve analisar os fluxos das mensagens entre objetos no diagrama de sequência.
3. Quando iniciamos a análise de um sistema, temos a percepção inicial das classes que deverão ser utilizadas, e geramos um diagrama de classes de análise condizente com os casos de uso que foram especificados. Se temos esse diagrama disponível, por que não o utilizamos diretamente nas fases posteriores do desenvolvimento?
Resposta
Espelho de resposta
Sistemas são bastante dinâmicos, e a incerteza é mais comum do que deveria na área de desenvolvimento de software. Apesar de as fases iniciais de análise fornecerem os elementos básicos do sistema, após a escrita do descritivo dos casos de uso, a especificação das tecnologias necessárias e a escolha da arquitetura, surgem diversos novos elementos a serem considerados, que exigem múltiplas atualizações no diagrama de classes, agora já focando nos fluxos de execução ao nível da implementação.
Avalie este módulo:
 
    
Diagrama de classes de projeto
Vamos tratar agora do diagrama de classes de projeto. Esse diagrama é um refinamento do diagrama de classes construído na fase de análise. Nesse refinamento, algumas classes sofrem alterações de suas propriedades com o objetivo de transformar o modelo de classes de análise no modelo de classes de projeto, assim como suas notações adicionais, transformações sobre atributos, operações e associações.
Além disso, vamos abordar também os relacionamentos entre classes, apresentando outros elementos de notação e princípios de modelagem que não são usados na análise, mas que são importantes na construção do modelo de classes de projeto.
Definição
O diagrama de classes de projeto apresenta os dados que serão necessários para a construção do sistema de informação. Esse é o diagrama que possui o maior número de símbolos para sua diagramação.
O seu principal objetivo é permitir a visualização dos componentes das bases de dados do sistema, ou seja, as classes e seus objetos, relações entre elas, suas operações, seus métodos, suas interfaces e seus pacotes.
Também é papel desse diagrama atender às demandas dos casos de uso, armazenando as estruturas de dados projetadas para o sistema.
Na fase de análise, o diagrama de classes pode ser usado para produzir o modelo conceitual por meio do qual representamos as classes e seus atributos e não levamos em consideração aspectos relacionados ao software. Apenas estamos interessados no domínio do problema, ou seja, na representação das informações necessárias ao sistema e nos conceitos e características observados no ambiente. Já na fase de projeto, definimos a solução do problema, ou seja, damos importância ao software por meio do qual as classes serão programadas, evidenciamos detalhes da implementação, como, por exemplo, os tipos de dados dos atributos (varchar, integer, date etc.) e suas operações e métodos.
Especificação de atributos
No modelo de classes de análise, os atributos são definidos somente pelo nome. No entanto, a sintaxe completa da UML para definição de um atributo é bem mais detalhada. Essa sintaxe, usada na fase de especificação do modelo de classes de projeto, é a seguinte:
 ::= [/] [visibilidade] nome[: tipo] [= valor_inicial]
A visibilidade de um atributo indica seu nível de acesso. Ou seja, ela permite definir quais atributos de um objeto são acessíveis por outros objetos. A visibilidade de um atributo pode ser pública, protegida,privativa ou de pacote. A primeira é o que chamamos de default (se nenhuma visibilidade for especificada, essa é assumida).
A propriedade de visibilidade serve para implementar o encapsulamento da estrutura interna da classe. Somente as propriedades realmente necessárias ao exterior da classe devem ser definidas com visibilidade pública. Todo o resto deve ser definido através das visibilidades protegida e privativa. Abaixo temos a lista de tipos de visibilidades, seus símbolos e significados:
Clique nos itens a seguir.
Pública (+)
Protegida (#)
Privativa (-)
Pacote (~)
O elemento nome na sintaxe do atributo corresponde ao nome do atributo. Na verdade, somente esse elemento é obrigatório na sintaxe de declaração de um atributo, visto que os demais são opcionais.
O elemento tipo especifica o tipo do atributo. Esse elemento é dependente da linguagem de programação na qual a classe deve ser implementada. O tipo de um atributo pode ser definido pela utilização de um tipo primitivo da linguagem de programação a ser utilizada na implementação.
Exemplo
Se estamos utilizando a linguagem Java, temos, dentre outros, os seguintes tipos primitivos: int, float e boolean.
Um valor inicial também pode ser declarado para o atributo. Dessa forma, sempre que um objeto de uma classe é instanciado, o valor inicial declarado é automaticamente definido para o atributo. Assim como o tipo, o valor inicial de um atributo também é dependente da linguagem de programação.
Pode-se definir um atributo derivado em uma classe. Um atributo é derivado quando o seu valor pode ser obtido a partir do valor de outro(s) atributo(s). Por exemplo, o valor da idade de uma pessoa pode ser obtido a partir de sua data de nascimento. Um atributo derivado é representado com uma barra inclinada à esquerda (/). Atributos derivados normalmente são definidos por questões de desempenho.
Os atributos também têm multiplicidade. Esta determina o número mínimo e máximo de valores que um atributo pode conter. Abaixo podemos ver as multiplicidades e seus significados, que são similares às multiplicidades dos relacionamentos entre classes:
swap_horiz Arraste para os lados.
0..1
Indica que o atributo tem no mínimo zero (é opcional) e no máximo um valor.
1..1
Indica que o atributo tem no mínimo um (é obrigatório) e no máximo um valor.
0..*
Indica que o atributo tem no mínimo zero (é opcional) e no máximo muitos valores.
*
Indica que o atributo tem muitos valores e equivale a 0..* (é opcional).
1..*
Indica que o atributo tem no mínimo um (é obrigatório) e no máximo muitos valores.
2..6
Indica que o atributo tem no mínimo dois e no máximo seis valores.
Especificação de operações/métodos
Na descrição do modelo de interações, declaramos que as operações de uma classe são identificadas em consequência da identificação de mensagens enviadas de um objeto a outro. No detalhamento dessas operações, devemos considerar diversos aspectos: seu nome, lista de parâmetros, tipo de cada parâmetro, tipo de retorno. As operações de uma classe correspondem a algum processamento realizado por essa classe. Em termos de implementação, uma operação é uma rotina associada a uma classe. A sintaxe definida na UML para uma operação é a seguinte:
[visibilidade] nome([parâmetros]) [: tipo-retorno] [{propriedades}]
A visibilidade segue a mesma simbologia das visibilidades para atributos.
O elemento nome corresponde ao nome dado à operação. Se uma operação for pública, ela pode ser ativada com a passagem de uma mensagem para o objeto. Se for protegida, ela só é visível para a classe e para seus descendentes. Se for privativa, somente objetos da própria classe podem executá-la.
Os parâmetros de uma operação correspondem às informações que ela recebe quando é executada. Normalmente, essas informações são fornecidas pelo objeto remetente da mensagem que pede a execução da operação no objeto receptor. Uma operação pode ter zero ou mais parâmetros, que são separados por vírgulas. Cada parâmetro da lista tem a seguinte sintaxe:
[direção] nome-parâmetro: tipo-parâmetro
O elemento direção serve para definir se o parâmetro pode ou não ser modificado pela operação. O modelador pode definir se o parâmetro é de entrada (IN), saída (OUT) ou ambos (INOUT). Se a direção for omitida, o valor assumido pelo parâmetro será IN, de entrada. As possíveis direções na definição de um parâmetro pela UML são::
Clique nas informações a seguir.
IN
OUT
INOUT
O elemento nome-parâmetro corresponde ao nome do parâmetro. Cada parâmetro deve ter um nome único dentro da assinatura da operação.
O elemento tipo-parâmetro corresponde ao tipo do parâmetro e é dependente da linguagem de programação.
O elemento tipo-retorno representa o tipo de dados do valor retornado por uma operação. Esse tipo depende da linguagem de programação.
Especificação de associações
No modelo de classes de análise, relacionamentos entre objetos são normalmente definidos apenas com o uso da associação (ou como um de seus casos especiais, a generalização, a agregação ou a composição). As associações são os mecanismos que permitem aos objetos se comunicarem. Elas descrevem a conexão entre diferentes classes. Podem ter uma regra que especifica o propósito da associação e podem ser unidirecionais ou bidirecionais. Cada ponta da associação também possui um valor de multiplicidade que indica como os objetos de um lado se relacionam com os do outro lado. Existem diversos tipos de associação, que são modelados desde a etapa de análise:
Clique na barra para ver as informações.
Unárias, reflexivas ou recursivas (autoassociação)
Binárias
Ternárias ou n-árias
Agregação
Composição
Generalização/ Especialização
Classe Associativa
Na etapa de projeto, uma espécie de associação relevante é a dependência, que representa relacionamentos entre classes, onde uma é dependente da outra. Qualquer modificação na classe independente afetará diretamente objetos da classe dependente.
Exemplo de associação de dependência. Elaborado na ferramenta Astah UML.
Uma dependência entre classes indica que uma classe depende dos serviços fornecidos pela outra. No modelo de análise, é suficiente para o modelador identificar a existência de associações entre classes, que é uma forma de dependência. Mas, na fase de especificação do modelo de classes, essa dependência precisa ser mais bem definida pelo projetista, uma vez que ela tem influência na forma utilizada para implementar as classes envolvidas. Vamos descrever, então, detalhes das possíveis formas de dependência. Para isso, considere duas classes, A e B, onde A depende de B.
Vários tipos de dependência entre essas duas classes podem existir. Esses tipos são descritos a seguir:
Dependência por atributo
A possui um atributo cujo tipo é B. A dependência por atributo é também chamada de dependência estrutural.
Dependência por variável global
A utiliza uma variável global cujo tipo é B.
Dependência por variável local
A possui alguma operação cuja implementação utiliza uma variável local de tipo B.
Dependência por parâmetro
A possui pelo menos uma operação, que possui pelo menos um parâmetro, cujo tipo é B.
A notação da UML para representar uma dependência no diagrama de classes é de uma seta tracejada ligando as classes envolvidas. A seta sai da classe dependente e chega na classe da qual depende. Ainda com respeito à notação, as dependências podem ser estereotipadas para indicar o tipo de dependência existente entre duas classes. Os estereótipos da UML para rotular relacionamentos de dependência são:
>
Para variável global
>
Para variável local
>
Para parâmetro
Transformação de associações em dependências
No modelo de classes de análise, o modelador especifica uma ou mais associações entre uma classe e as demais apresentadas. Na passagem do modelo de classes de análise para o de projeto, o modelador deve estudar cada associação para identificar se ela pode ser transformada em dependências. A razão para essa transformação é definir melhor o encapsulamento. Quanto menos dependências estruturais houver no modelode classes, maior será a qualidade do projeto (do ponto de vista do encapsulamento e do acoplamento das classes constituintes). De um modo geral, as associações que ligam classes de entidade permanecem como associações no modelo de projeto.
Classes persistentes e transientes
As classes são divididas em:
Persistentes
Presumem que seus objetos precisam, de alguma maneira, ser preservados mesmo após o encerramento da utilização do sistema.
Não persistentes (transientes)
Terão seus objetos destruídos durante ou na finalização do uso do sistema. Estas são diferenciadas por estereótipos >.
Classes de interface
Uma classe de interface é uma coleção de operações com um nome e é utilizada para especificar um tipo de serviço sem especificar como será sua implementação. Essas classes não têm métodos concretos, apenas o declaram para que outra classe possa implementá-lo. Elas possibilitam que objetos externos ao sistema possam colaborar com uma ou mais classes do sistema.
São exemplos as interfaces gráficas, as de interações entre os usuários e as telas do sistema. Há um estereótipo para ela (>) e sua implementação utiliza uma reta tracejada oriunda da classe de implementação, contendo a seta vazia na extremidade que aponta para a classe de interface, como ilustra o exemplo a seguir.
Exemplo de classe de interface. Elaborado na ferramenta Astah UML.
Navegabilidade de associações
As associações podem ser classificadas em bidirecionais e unidirecionais. Uma associação bidirecional indica que há um conhecimento mútuo entre os objetos associados. Ou seja, se um diagrama de classes exibe uma associação entre duas classes C1 e C2, então as duas assertivas a seguir são verdadeiras:
• Cada objeto de C1 conhece todos os objetos de C2 aos quais está associado.
• Cada objeto de C2 conhece todos os objetos de C1 aos quais está associado.
Graficamente, uma associação unidirecional é representada adicionando-se um sentido à associação. A classe para a qual o sentido aponta é aquela cujos objetos não possuem a visibilidade dos objetos da outra classe.
Durante a construção do modelo de classes de análise, associações são normalmente consideradas “navegáveis” em ambos os sentidos, ou seja, as associações são bidirecionais. No modelo de classes de projeto, o modelador deve refinar a navegabilidade de todas as associações.
Atenção
Pode ser que algumas associações precisem permanecer bidirecionais. No entanto, se não houver essa necessidade, recomenda-se transformar a associação em unidirecional. Isso porque uma associação bidirecional é mais difícil de implementar e de manter do que uma associação unidirecional correspondente.
Para entender isso, basta ver que o acoplamento entre as classes envolvidas na associação é maior quando a navegabilidade é bidirecional, prejudicando a modularização. Portanto, um dos objetivos a alcançar durante o projeto é identificar quais navegabilidades são realmente necessárias.
A definição da navegabilidade se dá em função da troca de mensagens ocorridas nas interações entre objetos do sistema. Mais especificamente, devemos analisar os fluxos das mensagens entre objetos no diagrama de interações. Dados dois objetos associados, A e B, se há pelo menos uma mensagem de A para B em alguma interação, então a associação deve ser navegável de A para B. Da mesma forma, se existir pelo menos uma mensagem de B para A, então a associação deve ser navegável de B para A.
A definição do sentido da navegabilidade é feita em função das mensagens identificadas na modelagem de interação. Em particular, se um objeto do tipo A envia uma mensagem para outro do tipo B, então deve haver uma navegabilidade no sentido de A para B no diagrama de classes.
Mesmo em situações em que a navegabilidade de uma associação precise ser bidirecional, é possível implementar apenas um de seus sentidos.
Exemplo de navegabilidade. Elaborado na ferramenta Astah UML.
VISÃO GERAL SOBRE DIAGRAMAS DE CLASSE DE PROJETO
No vídeo a seguir são apresentados os componentes do diagrama de classes de projeto.
Verificando o aprendizado
Parte superior do formulário
1. No diagrama de classes, uma associação reflexiva ou autoassociação:
Permite apenas relacionamentos 1:1
Envolve uma relação bilateral entre duas classes.
Representa relacionamentos que ocorrem entre objetos da mesma classe.
Indica que há dependência direta entre duas classes.
Representa relacionamentos entre classes diferentes.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
Uma associação reflexiva ou recursiva representa relacionamentos que ocorrem entre objetos da mesma classe. Esses relacionamentos recursivos (também chamados de autorrelacionamentos ou autoassociações) são casos especiais onde uma entidade se relaciona com si própria. Os autorrelacionamentos podem ser do tipo 1:1 (um-para-um), 1:N (um-para-muitos) ou N:M (muitos-para-muitos).
Parte superior do formulário
2. Temos quatro tipos de especificação de visibilidade de atributos: público, protegido, privativo e pacote. Abaixo listamos definições relacionadas à visibilidade de um atributo. Assinale a alternativa que contenha a definição correta do atributo público.
Qualquer atributo visível para classes da subclasse em que foi definido
Qualquer objeto externo pode obter acesso a qualquer tipo de elemento da classe.
Qualquer objeto externo pode obter acesso ao atributo, desde que tenha uma referência para a classe externa ao pacote.
Qualquer objeto externo pode obter acesso ao atributo, desde que tenha uma referência para a classe em que o atributo está definido.
Qualquer objeto pode obter acesso ao elemento, desde que tenha uma referência para a classe externa deste elemento.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
A visibilidade (+) de um atributo público indica que as propriedades desse atributo são visíveis por qualquer objeto externo, isto é, pertencente a outra classe, contanto que tenha uma referência para a classe em que o atributo está definido.
MÓDULO 3
Objetivo: Empregar os diagramas de estado e de atividades no projeto de sistema
Ligando os pontos
Como a interface de um sistema deve responder às mudanças de estado decorrentes de sua execução e interações ocorridas? Vamos entender melhor o assunto a seguir.
Durante a utilização do sistema, os componentes mudam de estado constantemente, em decorrência de algum evento interno ou externo ao sistema. A cada estado, podemos ter um diferente conjunto de eventos disponível.
O diagrama de estados permite avaliar os estados do sistema como um todo. Trata-se de uma ferramenta de engenharia muito comum, mas plenamente aplicável ao desenvolvimento de sistemas de computação.
Analisando o sistema como um todo, a tela corrente funciona como uma expressão primária do estado do sistema, como inserindo, alterando ou consultando. Ainda há o estado de objetos gráficos, como no caso em que o botão de salvar fica habilitado apenas quando um documento sofreu uma modificação.
Para os componentes de tela, inclusive, tem sido comum o uso do padrão Observer, no qual as mudanças de estado de um objeto são refletidas em todos os elementos gráficos associados de forma automática.
Podemos observar, a seguir, o diagrama de estados de um cadastramento simples de título por um colaborador em um sistema de streaming:
 Diagrama de estados para a tela de cadastro de título.
A tela de cadastro seria apresentada em branco, em que os valores devem ser preenchidos, confirmados, e o upload do título, iniciado, fornecendo, ao completar o envio, as opções de fechar a janela ou cadastrar outro título.
Mesmo com um diagrama simples como esse, podemos observar a relação entre estados e eventos. Será possível efetuar o upload antes do preenchimento da janela, mas, apenas após a conclusão do envio, será possível disponibilizar o fechamento da janela ou a abertura de um novo cadastro.
Quanto ao diagrama de atividades, um bom exemplo seria extraído do contexto oferecido pela busca de título, a partir do descritivodo caso de uso, incluindo fluxos alternativos. A imagem apresentada a seguir demonstra o diagrama gerado. Vejamos:
 Diagrama de atividades com raias para busca de título.
A partir dos exemplos apresentados, é fácil observar como o diagrama de estados e o diagrama de atividades oferecem o fluxo lógico para execução do aplicativo, sem entrar em detalhes específicos da implementação, como ocorre no diagrama de sequência. Mesmo sem especificar elementos tecnológicos, esses diagramas transmitem uma ótima visão dos macroprocessos e do comportamento do sistema como um todo.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Parte superior do formulário
1. O diagrama de atividades permite mapear o fluxo de um macroprocesso, transmitindo uma visão bastante completa acerca da funcionalidade esperada em determinados contextos de utilização. Imagine que você é um analista de sistemas e necessita elaborar o diagrama de atividades de um projeto. Sobre essa elaboração, é correto afirmar que
não é possível definir fluxos de execução paralelos.
a construção do diagrama não permite o envolvimento de mais de um ator.
um ponto de ramificação inicia dois ou mais fluxos de execução paralelos.
a barra de junção aguarda até que uma das transições de entrada seja concluída.
quando desejamos iniciar transições paralelas, precisamos de uma bifurcação.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "E" está correta.
Algo interessante acerca do diagrama de atividades é que fornece suporte ao paralelismo, além de envolver quantas partes interessadas (prováveis atores) forem necessárias, divididas em raias. Pontos de ramificação, representados por um losango, executam fluxos alternativos perante certas condições, o que é diferente da bifurcação, que inicia as transições em paralelo. Enquanto a barra de junção exige o término de todas as transições de entrada, um losango – o mesmo usado na ramificação – exigiria o término de apenas uma transição.
Parte superior do formulário
2. Não são raras as situações em que determinado objeto só pode iniciar algumas ações perante condições específicas, como a transmissão de dados após efetuar a conexão. Suponha que, ao elaborar o diagrama de estados de um projeto de sistema, você tenha conseguido mapear os momentos em que determinadas ações podem ser iniciadas, considerando o estado do objeto como indicador. Como você denominaria a modificação do estado em determinado ponto do tempo?
Ação
Atividade
Evento
Ponto de junção
Condição de guarda
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
Por definição, evento é algo que acontece em determinado instante e que pode modificar o estado do objeto. Um evento pode ter parâmetros, como nas requisições HTTP, e iniciar ações, como o cadastro a partir dos valores enviados.
3. Os diagramas de estado e de atividades fornecem aos desenvolvedores a visão macroscópica do comportamento do sistema, bem como dos atores envolvidos e dos fluxos de execução para determinadas funcionalidades. Como podemos associar esses diagramas a outros artefatos da modelagem orientada a objetos?
Resposta
Espelho de resposta
Considerando o diagrama de estados, cada transição envolverá um fluxo de execução. Se temos o estado do sistema, podemos considerar que o diagrama de sequência expressaria adequadamente as ações efetuadas em decorrência da mudança. O diagrama de atividades, por sua vez, é um pouco mais amplo que o diagrama de sequência, pois inclui fluxos paralelos e alternativos, embora seja mais abstrato. Esse diagrama é ideal para expressar os descritivos dos casos de uso. Em ambos os diagramas, precisamos utilizar os atores, muitos dos quais poderão estar definidos no diagrama de classes.
Avalie este módulo:
 
    
Transição entre estados
Exemplo de transição de estado.
Objetos de um sistema de software orientado a objetos se encontram em um estado particular a cada momento. Um objeto muda de estado quando acontece algum evento interno ou externo ao sistema. Quando um objeto muda de um estado para outro, diz-se que ele realizou uma transição entre estados. Os estados e as transições de estado de um objeto constituem o seu ciclo de vida.
No momento de sua transição de um estado para outro, um objeto normalmente realiza determinadas ações dentro do sistema. Cada objeto pode passar por um número finito de estados durante a sua vida. Quando um objeto transita de um estado para outro, significa que o sistema no qual ele está inserido também está mudando de estado.
Pela análise das transições entre estados dos objetos de um sistema de software, é possível prever todas as possíveis operações realizadas, em função de eventos que podem ocorrer.
O diagrama da UML utilizado para realizar essa análise é o diagrama de estados, também conhecido como diagrama de máquina de estado ou de transição de estado (DTE).
Esse diagrama permite descrever o ciclo de vida de objetos de uma classe, os eventos que causam a transição de um estado para outro e a realização de operações resultantes.
Atenção
Assim como diagramas de interação não são construídos para todos os casos de uso, os diagramas de transição de estado não devem ser construídos para todas as classes de um sistema, mas apenas para aquelas que possuem um número definido de estados conhecidos, e quando o comportamento das classes de objetos é afetado e modificado pelos diferentes estados. Nessas classes, um DTE pode ser utilizado para enfatizar os eventos que resultam em mudanças de estado.
Diagrama de transição de estados
A UML tem um conjunto rico de notações para desenhar um DTE. Os elementos básicos de um diagrama de transição de estados são os estados e as transições. Associados a estas últimas estão os conceitos de evento, ação e atividade. Um DTE pode também conter elementos menos utilizados, mas às vezes úteis, como transições internas, estados aninhados e estados concorrentes. A figura a seguir mostra um diagrama de estados para o objeto oferta de disciplina, que pode ter quatro estados: aberta, cancelada, lotada e fechada.
Exemplo de diagrama de estados.
Um estado é uma situação na vida de um objeto durante a qual ele satisfaz alguma condição ou realiza alguma atividade. Cada estado de um objeto é normalmente determinado pelos valores dos seus atributos e (ou) pelas suas ligações com outros objetos.
A UML utiliza as seguintes notações para representar os estados:
Estado
O retângulo com as bordas arredondadas representa um estado. Em sua forma mais simples, o retângulo de um estado possui um único compartimento.
Estado inicial
O círculo preenchido indica o estado de um objeto quando ele é criado. Só pode haver um estado inicial em um DTE, restrição que serve para definir a partir de que ponto um DTE deve começar a ser lido.
Estado final
Representado por um círculo parcialmente preenchido. Diferentemente do estado inicial, pode haver vários estados finais, dependendo dos estados terminais do objeto modelado.
Transições
Os estados estão associados a outros pelas transições. Uma transição é mostrada como uma linha conectando estados, com uma seta apontando do estado origem para o estado destino. Quando ocorre uma transição entre estados, diz-se que a transição foi disparada. Note que, em uma transição, o estado subsequente pode ser igual ao estado original. Uma transição pode ser rotulada com uma expressão:
evento (lista-parâmetros) [guarda] / [ação]
A seguir, vamos entender os elementos envolvidos nas transições entre estados:
Clique na barra para ver as informações.
Evento
Um evento é algo que acontece em algum ponto no tempo e que pode modificar o estado de um objeto, provocando a transição de estado. Um evento pode conter uma lista de parâmetros que são passados para fornecer informações úteis ao objeto receptor de evento. A lista de parâmetros é especificada entre parênteses. Na figura exemplo de diagrama de estados, realização de inscrição / qtdAlunos := qtdAlunos + 1 é um exemplo de evento.
Os eventos relevantes a uma classecomputacionais?
A
Para dificultar o nível de abstração da realidade.
B
Para facilitar a interpretação inadequada.
C
Para aumentar a complexidade do sistema.
D
Para confirmar a compreensão das necessidades dos usuários.
E
Para representar adequadamente a realidade e entender o contexto do sistema a ser construído.
Responder
Parabéns! A alternativa E está correta.
Traduzir a realidade em modelos no desenvolvimento de sistemas é essencial para assegurar que os requisitos e necessidades dos usuários sejam compreendidos e atendidos de maneira eficaz. Essa prática permite uma visualização clara do funcionamento do sistema, facilitando a identificação de potenciais problemas e a implementação de soluções adequadas.
Modelos como elementos de comunicação
Os modelos facilitam a compreensão e a representação da realidade, tanto para os membros da equipe de desenvolvimento quanto para os usuários finais. Eles servem como ferramentas eficazes para traduzir os requisitos e as necessidades dos usuários em uma linguagem compreensível para os desenvolvedores, garantindo que o sistema atenda adequadamente às expectativas e às demandas. Além disso, os modelos auxiliam na validação e na verificação dos requisitos, contribuindo para o sucesso do projeto de desenvolvimento de software.
Entendimento e validação dos modelos com os usuários
A partir dos modelos, compreendemos e nos certificamos do correto entendimento da realidade dos usuários.
Equipe levantando dados com os usuários.
Momento 1
A equipe de desenvolvimento se reúne com os usuários e, usando técnicas de levantamento de dados, compreende a realidade e as necessidades dos usuários, visando implementá-las no sistema. Os dados levantados são registrados e usados na construção dos modelos. Esse momento acontece com maior intensidade na fase de requisitos, mas também está presente nas fases de análise e de projeto.
Equipe construindo os modelos.
Momento 2
A equipe de desenvolvimento constrói os modelos que julga pertinentes para que se possa compreender e destacar os aspectos relevantes da realidade. Esse momento acontece nas fases de requisitos, análise e projeto.
Equipe validando dados com os usuários.
Momento 3
A equipe de desenvolvimento se reúne com os usuários, apresentando e discutindo os modelos construídos, visando validá-los e responder à pergunta base: os modelos que construímos representam de fato a realidade dos usuários? Em caso positivo, prossegue-se no desenvolvimento; caso contrário, os modelos são ajustados e confirmados novamente com os usuários, até que estejam adequados. Esse momento acontece nas fases de requisitos, análise e projeto.
Os modelos são fundamentais para garantir o correto entendimento da realidade dos usuários. A equipe coleta dados, constrói os modelos com base nessas informações e, finalmente, valida-os com os usuários para assegurar que representam adequadamente a realidade.
Entendimento do sistema por membros da equipe de desenvolvimento
Outra finalidade dos modelos no desenvolvimento de sistemas é orientar membros da equipe em relação às suas tarefas no processo.
Exemplo
O programador deve construir os programas, mas não tem livre acesso aos usuários e nem precisa, pois os modelos servem como elementos de comunicação com todos da equipe. Os projetistas do software devem compreender a realidade dos requisitos para construir os modelos de projeto, por isso precisam ler os modelos das fases de requisitos e de análise. Os programadores consultam os modelos de seu interesse e conversam com os membros que fizeram o levantamento de dados e a modelagem para compreenderem melhor o contexto e desenvolverem com mais eficiência os programas necessários.
Outro exemplo é o projetista de interface, que precisa compreender o funcionamento de um determinado recurso para criar a interface adequada. Nesse caso, ele consulta o modelo que descreve a interação do usuário com o sistema para a funcionalidade em questão. Esse processo ocorre em todas as fases do projeto, já que sempre haverá desenvolvedores recebendo tarefas e consultando os modelos relevantes.
A imagem a seguir ilustra a consulta de diferentes pessoas da equipe aos modelos desenvolvidos.
Equipe consultando os modelos.
Atividade 3
Questão 1
No desenvolvimento de sistemas computacionais, os modelos são representações abstratas de elementos, processos ou comportamentos do sistema. Qual das opções indica uma das finalidades dos modelos no desenvolvimento de sistemas?
A
Aumentar a complexidade das tarefas da equipe.
B
Facilitar o acesso livre dos programadores aos usuários.
C
Servir como elementos de comunicação com todos os membros da equipe.
D
Substituir a interação direta entre os programadores e os usuários.
E
Limitar o acesso dos projetistas de interface aos modelos.
Responder
Parabéns! A alternativa C está correta.
Os modelos no desenvolvimento de sistemas atuam como ferramentas de comunicação, garantindo que todos os membros da equipe, desde programadores a designers e stakeholders, estejam alinhados quanto às expectativas e aos requisitos do sistema. Eles fornecem uma representação visual ou conceitual do sistema proposto, permitindo a discussão de ideias, a identificação de potenciais problemas e soluções antes da implementação, e facilitando o entendimento comum dos objetivos do projeto.
Orientação a objetos
Compreender os princípios fundamentais desse paradigma de desenvolvimento permite aos profissionais de tecnologia criarem sistemas modulares, flexíveis e de fácil manutenção. Além disso, a adoção de uma abordagem orientada a objetos promove a reutilização de código, a modularidade e a escalabilidade dos sistemas, contribuindo significativamente para a qualidade e a eficácia dos projetos de software. O conhecimento teórico nessa área é essencial para impulsionar a excelência na engenharia de software.
Paradigma orientado a objetos
Vamos analisar agora os conceitos, pilares, princípios e as orientações do paradigma orientado a objetos. Veremos também as visões, os objetivos e as entregas dos momentos de análise, projeto e implementação (em camadas), independentemente de processo ou metodologia de desenvolvimento de software.
Atenção
Ao longo do texto, utilizaremos a sigla OO para o termo orientação a objetos.
Com o aumento do tamanho do código e da complexidade dos programas, o paradigma estruturado, que antecedeu o paradigma orientado a objetos, começou a apresentar limitações nos sistemas sob o ponto de vista da dificuldade de manutenção e reúso de programas e rotinas padronizadas.
Vamos, inicialmente, definir o termo paradigma como a maneira de abordar um problema.
A orientação a objetos surge como solução para esses problemas, possibilitando uma maior organização, reutilização e extensibilidade de código por meio de propriedades como abstração, encapsulamento, herança e polimorfismo. Isso resulta em 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.
Um dos pioneiros do paradigma orientado a objetos, Alan Kay, imaginou um sistema como um conjunto de agentes autônomos, os objetos, que interagem entre si. Ele estabeleceu os princípios centrais da orientação a objetos. Vejamos!
 
· 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.
· Classes são organizadas em hierarquias.
A seguir, observe a definição sobre o paradigma da orientação a objetos.
O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados 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 softwarede objetos podem ser classificados em quatro tipos:
1. Evento de chamada: recebimento de uma mensagem de outro objeto. Pode-se pensar nesse tipo de evento como uma solicitação de serviço de um objeto a outro.
2. Evento de sinal: recebimento de um sinal. Este é um tipo especial do evento anterior. Nesse evento, o objeto recebe um sinal de outro objeto que pode fazê-lo mudar de estado. A diferença básica entre o evento de sinal e o evento de chamada é que neste último o objeto que envia a mensagem fica esperando a execução dela. No evento de sinal, o objeto remetente continua o seu processamento após ter enviado o sinal. O evento de sinal raramente é utilizado.
3. Evento temporal: passagem de um intervalo de tempo predefinido. Em vez de receber uma mensagem específica, um objeto pode interpretar a passagem de um certo intervalo de tempo como sendo um evento.
4. Evento de mudança: uma condição que se torna verdadeira. O fato de determinada condição se tornar verdadeira também pode ser visto como um evento.
Condição de guarda
Uma transição pode ter também uma condição de guarda. Uma condição de guarda, ou simplesmente guarda, é uma expressão de valor lógico, da mesma forma que a utilizada para diagramas de interação. A condição de guarda de uma transição pode ser definida utilizando-se parâmetros passados no evento e atributos e referências a ligações da classe em questão. Além disso, uma condição também pode testar o valor de um estado. Uma transição na qual foi definida uma condição de guarda é disparada somente se o evento associado ocorre e a condição de guarda é verdadeira. Se uma transição não tiver uma condição de guarda, ela sempre será disparada quando o evento ocorrer. É importante não confundir a condição de guarda de uma transição com um evento de mudança (que também é definido com uma expressão de valor lógico). A expressão condicional de uma condição de guarda é sempre apresentada entre colchetes, como em [qtdAlunospara a classe.
Identifique os eventos relevantes aos objetos de uma classe. Para cada evento, identifique qual transição que ele ocasiona.
2
3
Para cada estado, identifique as transições possíveis quando um evento relevante ocorre.
Para cada estado, identifique os eventos internos e as ações correspondentes relevantes.
4
5
Para cada transição, verifique se há fatores que influenciam o seu disparo. Se esse for o caso, uma condição de guarda deve ser definida.
Verifique também se alguma ação deve ser executada quando uma transição é disparada (ações).
6
7
Para cada condição de guarda e para cada ação, identifique os atributos e as ligações que estão envolvidos. Pode ser que esses atributos ou ligações ainda não existam. Nesse caso, eles devem ser adicionados ao modelo de classes.
Defina o estado inicial e os eventuais estados finais.
8
9
Desenhe o diagrama de estados. Procure posicionar os estados de tal forma que o ciclo de vida do objeto possa ser visualizado de cima para baixo e da esquerda para a direita.
Atenção
A construção de diagramas de estados de um sistema frequentemente leva à descoberta de novos atributos para uma classe, principalmente atributos que servem de abstrações para estados. Além disso, esse processo de construção permite identificar novas operações na classe, pois os objetos precisam reagir aos eventos que eles recebem, e essas reações são realizadas mediante operações.
Diagrama de atividades
Um diagrama de atividade pode ser considerado um tipo especial de diagrama de estados, em que são representados os estados de uma atividade em vez dos estados de um objeto. Ao contrário dos diagramas de estados, que são orientados a eventos, diagramas de atividade são orientados a fluxos de controle.
Muitos autores dizem que o diagrama de atividades é um fluxograma. Na verdade, o diagrama de atividade pode ser visto como uma extensão dos fluxogramas. Além de possuir toda a semântica existente em um fluxograma (com notação ligeiramente diferente), o diagrama de atividade possui notação para representar ações concorrentes (paralelas), juntamente com a sua sincronização.
Exemplo de diagrama de atividades. Elaborado na ferramenta Astah UML.
Os elementos de um diagrama de atividade podem ser divididos em dois grupos:
Elementos utilizados para representar fluxos de controle sequenciais.
Elementos utilizados para representar fluxos de controle paralelos.
Veremos mais detalhes de cada tipo a seguir.
Fluxo de controle sequencial
Os elementos de um diagrama de atividade usados no controle sequencial são:
Clique na barra para ver as informações.
Estado ação e estado atividade
Um diagrama de atividades exibe os passos de uma computação. Cada estado corresponde a um dos passos da computação, em que o sistema está realizando algo. Um estado em um diagrama de atividade pode ser um estado atividade ou um estado ação. O primeiro leva um certo tempo para ser finalizado. Já o segundo é realizado instantaneamente.
Estados inicial e final e condição de guarda
Assim como no diagrama de estados, um diagrama de atividade deve ter um estado inicial; ele pode ter também vários estados finais e guardas associados a transições. Um diagrama de atividade pode não ter estado final, o que significa que o processo ou procedimento sendo modelado é cíclico.
Transição de término
Uma transição de término liga um estado a outro. Essa transição significa o término de um passo e o consequente início do outro. Observe que, em vez de ser disparada pela ocorrência de um evento (como nos diagramas de estados), essa transição é disparada pelo término de um estado de ação. Pode haver uma transição rotulada com a condição de guarda especial [else], o que significa que, se todas as demais condições de guarda foram avaliadas como falsas, a transição associada a essa guarda especial é disparada.
Pontos de ramificação
Um ponto de ramificação possui uma única transição de entrada e várias de saída. Para cada transição de saída, há uma condição de guarda associada. Quando o fluxo de controle chega a um ponto de ramificação, uma e somente uma das condições de guarda deve ser verdadeira.
Ponto de união
Um ponto de união reúne diversas transições que, direta ou indiretamente, têm um ponto de ramificação em comum.
Fluxo de controle paralelo
Um diagrama de atividade pode conter fluxos de controle paralelos. Isso significa que é possível haver dois ou mais fluxos de controle sendo executados simultaneamente em um diagrama de atividades. Para sincronizar dois ou mais fluxos paralelos, as barras de sincronização são utilizadas. Há dois tipos de barra de sincronização:
Barra de bifurcação (fork)
Uma barra de bifurcação recebe uma transição de entrada e cria dois ou mais fluxos de controle paralelos. A partir desse momento, cada um dos fluxos criados é executado independentemente e em paralelo com os demais.
Barra de junção (join)
Uma barra de junção recebe duas ou mais transições de entrada e une os fluxos de controle em um único fluxo. Essa barra tem o objetivo de sincronizar fluxos de controle paralelos criados anteriormente no diagrama. As transições de saída da barra de junção somente são disparadas quando todas as transições de entrada tiverem sido disparadas.
Raias
Algumas vezes, as atividades de um processo podem ser distribuídas por vários agentes que o executarão. Isso normalmente ocorre em processos de negócio de uma organização, onde as tarefas são executadas por pessoas ou departamentos diversos. Nesses casos, o processo pode ser representado em um diagrama de atividades com o uso de raias de natação. As raias de natação dividem o diagrama de atividades em compartimentos. Cada compartimento contém atividades que são realizadas por um agente específico. Além disso, as entidades de cada compartimento podem estar realizando atividades em paralelo.
Exemplo de diagrama de atividades com raias e fork. Elaborado na ferramenta Astah UML.
Modelagem da lógica de uma operação complexa
Quando um sistema de software é adequadamente decomposto em seus objetos constituintes e as responsabilidades de cada objeto estão bem definidas, a maioria das operações é bastante simples. Essas operações não necessitam de modelagem gráfica para serem entendidas. No entanto, em alguns casos, notadamente quando uma operação de uma classe de controle implementa uma regra de negócio, pode haver a necessidade de se descrever a lógica dessa operação ou da própria regra de negócio. Diagramas de atividade também podem ser utilizados com esse objetivo, nisso se assemelhando a um fluxograma.
EMPREGO DOS DIAGRAMAS DE ESTADOS E DE ATIVIDADES NA ETAPA DE PROJETO
No vídeo a seguir, os componentes do diagrama de estados e do diagrama de atividades são apresentados.
Verificando o aprendizado
Parte superior do formulário
1. Um dos diagramas apresentados é o diagrama de transição de estados. Assinale abaixo a alternativa que define corretamente o que é um estado:
História de vida de um objeto.
Descrição das atividades realizadas por um objeto.
Situações e/ou condições na vida de um objeto.
Cenário onde está inserid um objeto.
Elemento que define o objeto.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
Um objeto pode mudar de estado ao longo de seu ciclo de vida, o qual é caracterizado por situações ou condições resultantes da ocorrência de eventos.
Parte superior do formulário
2. Neste módulo, apresentamos o diagrama de atividade. Esse diagrama utiliza barras de sincronização. Assinale a alternativa que contenha os dois tipos de sincronização existentes:
Bifurcação e junção.
Transição e criação.
Bifurcação e criação.
Junção e criação.
Transição e junção.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
No diagrama de atividades, podem ocorrer fluxos paralelos que requerem sincronização, representada por uma barra. Esta pode ser de dois tipos: bifurcação (fork), quando uma transição de entrada cria dois ou mais fluxos de saída paralelos, e junção (join) quando duas ou mais transições de entrada são unidasresultando num único fluxo de saída.
MÓDULO 4
Objetivo: Empregar os diagramas de componentes e de implantação
Ligando os pontos
Como podemos oferecer uma visão estrutural do sistema como um todo? E com relação ao ambiente necessário para execução? Para entender melhor essas questões, vamos analisar o caso a seguir.
Sistemas complexos, como o da Netflix, apresentam grande conjunto de classes, que podem ser organizadas em pacotes. Embora o uso de pacotes traga uma boa divisão em termos semânticos, eles nem sempre refletem a organização estrutural, em que a adoção de componentes viabiliza uma visão geral mais concisa.
Um componente vai além da codificação da classe, e pode envolver conjuntos de interfaces e arquivos de configuração em modo texto. Exemplos clássicos, no ambiente Microsoft, são os componentes do tipo Active X, que implementam as interfaces IUnknow e IDispatch. Já no ambiente Java, temos os EJBs (Enterprise Java Beans), normalmente, contando com a classe do EJB, interfaces de acesso e anotações para configuração.
Tendo como exemplo os diferentes clientes para uma plataforma de streaming, dentro de uma arquitetura MVC (Model, View e Controller), podemos considerar um núcleo comum com os elementos do modelo, em que ficam as entidades e classes DAO (Data Access Object), controladores com a tecnologia EJB e Web Services para exposição de informações.
Fora do núcleo, precisamos de clientes para as diferentes plataformas, além de um motor para transmissão de vídeo e um banco de dados, como no diagrama a seguir:
 Diagrama de componentes para clientes de streaming.
Utilizando o diagrama de componentes, foi possível demonstrar a arquitetura do sistema de forma ampla, sem a necessidade de detalhes da implementação, o que expressa não apenas os relacionamentos internos, mas também a integração com componentes externos.
Por meio do diagrama, é possível planejar futuras extensões, aproveitando o modelo atual de interoperabilidade, ao mesmo tempo em que funcionalidades anteriores são mantidas.
Embora o diagrama de componentes possa introduzir alguns poucos elementos externos, é o diagrama de implantação que especifica as ferramentas necessárias para gerar um ambiente de execução adequado.
Para um sistema de streaming, é necessário trabalhar com servidores web, como o GlassFish, banco de dados, servidores de arquivos, servidor de transmissão e fornecimento do sistema cliente nas diferentes lojas de aplicativos, conforme pode ser observado no diagrama parcial de implantação a seguir:
 Diagrama de implantação parcial para o sistema de streaming.
Fica claro, portanto, que o diagrama de implantação traz importantes informações acerca do ambiente de execução do sistema, mas sem restringir configurações alternativas que sejam compatíveis. Ele define os artefatos de infraestrutura que podem ser utilizados para definir a arquitetura física para utilização do produto, além de facilitar estimativas de custo relacionadas, como a necessidade de uma licença de desenvolvedor no Google Play ou da aquisição de uma versão comercial do Oracle.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Parte superior do formulário
1. Por meio do diagrama de componentes, temos a visão estrutural do sistema, expressando os artefatos de software padronizados e como eles se relacionam, segundo a arquitetura que foi adotada, como MVC ou Broker. Diante do entendimento de que componentes são estruturas fechadas, você diria que a comunicação com o ambiente externo é proporcionada por meio de qual das alternativas abaixo?
Atributos
Herança
Composições
Interfaces
Polimorfismo
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
A comunicação do componente com o ambiente externo, seja para oferecer, seja para requerer serviços, é feita por meio de interfaces, que são assinaturas para um conjunto de operações relacionadas aos serviços. Como exemplos de interfaces de mercado, temos IUnknow e IDispatch, para componentes ActiveX, ou Remote e Local, para EJBS.
Parte superior do formulário
2. Imagine que você foi contratado como consultor para a implementação de um sistema. Nesse tipo de consultoria, é comum a exigência do diagrama de implantação, visando a descrever o ambiente de execução necessário para a equipe que ficará responsável pela gerência do sistema. Nesse caso, que símbolo seria utilizado para representar o servidor GlassFish no diagrama?
Caixa tridimensional
Losango
Retângulo simples
Círculo preenchido
Retângulo com bordas arredondadas
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
O diagrama de implantação tem uma simbologia bastante simples, na qual os componentes de software ou hardware, como o servidor GlassFish e módulos do sistema, utilizam caixas tridimensionais. Os artefatos de software ficam em retângulos comuns, dentro das caixas pertinentes, e os relacionamentos são definidos por linhas. Os demais símbolos não fazem parte desse diagrama, mas o losango representa fluxos alternativos. O círculo cheio é um estado inicial, e o retângulo com bordas arredondadas é um estado comum.
3. Os diagramas de componentes e de implantação são ótimos guias para a equipe técnica que ficará responsável pelo gerenciamento do sistema durante sua vida útil. Quais contribuições de tais diagramas você identificaria para a viabilidade da execução e evolução do sistema?
Resposta
Espelho de resposta
Com o diagrama de componentes, temos uma boa compreensão da arquitetura do sistema e das tecnologias utilizadas em seu desenvolvimento, o que permite escolher complementos compatíveis em desenvolvimentos futuros, além de documentar os meios de interoperabilidade oferecidos para a comunicação com outros sistemas. Já no diagrama de implantação, são representados os detalhes acerca do ambiente de execução do sistema, como servidores e bancos de dados, bem como os relacionamentos existentes entre os diversos componentes de software, dirimindo quaisquer dúvidas quanto aos requisitos para o correto funcionamento do sistema.
Obrigado pelo feedback!
Diagrama de componentes
O diagrama de componentes apresenta o relacionamento entre os diferentes componentes de um sistema de software. Na UML, o termo "componente" refere-se a um módulo que representa sistemas ou subsistemas com capacidade de interagir. Para isso, existe uma abordagem de desenvolvimento em torno de componentes.
Nesse diagrama, são representados os diferentes componentes de software necessários para que o sistema funcione corretamente.
Em uma abordagem de programação orientada a objetos, o desenvolvedor usa o diagrama de componentes para agrupar classes com base em um objetivo comum. Assim, é função do diagrama de componentes documentar como os componentes estão estruturados, organizados e como se relacionam, permitindo uma melhor compreensão e facilitando a sua reutilização. Também serve para modelar arquivos de processos de negócio, descrevendo as partes que participam dele e suas relações.
Um diagrama de componentes suporta tanto a especificação dos componentes lógicos, como, por exemplo, componentes de negócio, de processo, entre outros. Os principais benefícios na construção desse diagrama são:
Permitir visualizar a estrutura lógica e física do sistema.
Identificar os componentes do sistema e como eles se relacionam.
Perceber o comportamento do serviço quanto à interface.
Componente
Um componente nada mais é do que uma caixa preta (artefato do sistema) que possui vida autônoma e que, somente por meio de suas interfaces, oferece ou requer serviços de outras caixas pretas, sem que para isso tenha que conhecer seus conteúdos. Um componente é modelado ao longo do ciclo de vida de desenvolvimento, incluindo a concepção da funcionalidade do sistema por meio de casos de uso, definição das classes, entre outros.
Na UML, os componentes também fazem uso de estereótipos. Os mais utilizados são arquivos, tabela, banco de dados, executável e biblioteca. Assim sendo, podemos dizer que um componenteé qualquer arquivo que seja necessário à execução do sistema de informação.
Representação de um componente
Os componentes são elementos de alto nível que permitem o agrupamento de várias interfaces sem considerá-las um pacote. Cada componente é representado por um retângulo contendo um nome que deve traduzir sua função. Se necessário, pode conter um estereótipo. No canto superior do retângulo, há um ícone que é também um retângulo com dois menores sobrepostos.
Os componentes também podem ser descritos por meio da visão externa usando símbolos de interface colados na caixa do componente. Nesse caso, é interessante anexar uma máquina de estados para interfaces, portas e para o próprio componente para permitir uma descrição mais precisa.
Exemplo de diagrama de componentes. Elaborado na ferramenta Astah UML.
Quando mais detalhes são necessários para a perfeita especificação de um componente, podemos definir uma estrutura interna de partes e conectores, usando o que podemos chamar de visão interna ou “caixa branca”. Nessa estrutura, geralmente estão contidos outros componentes. Esses componentes podem ser implementados por diferentes tipos de arquivo. No diagrama de componentes, esses tipos podem ser destacados por meio de estereótipos, representados por rótulos acima do nome do componente. Nas diretrizes da UML definidas pela OMG, um artefato é dito como sendo definido pelo usuário e representa um elemento concreto do mundo físico. Ele pode ter propriedades ou operações e pode ser instanciado ou associado com outros artefatos.
Interfaces
Interfaces são coleções de operações que especificam serviços de um componente. É por meio delas que os componentes se comunicam com o mundo externo, seja para oferecer ou receber serviços. Interfaces descrevem o comportamento visível externamente e não especificam qualquer estrutura (não podem incluir atributos), nem qualquer implementação.
As interfaces fazem as associações entre os componentes do software.
As interfaces podem ser chamadas quando requerem ou esperam serviços. Podem ser opcionalmente por meio de portas onde é possível haver informações adicionais, tais como requisito de desempenho ou políticas que determinem que a interface seja realizada de maneira adequada.
Conectores
São utilizados nos diagramas de componentes para incluir interfaces baseadas em restrições e notações. Existem dois tipos principais de conectores:
Clique nas informações a seguir.
ConectorAssembly
ConectorDelegate
Camadas
A arquitetura de sistemas em camadas permite isolar a camada de apresentação das de regras de negócio e de armazenamento de dados. Isso permite aumentar o desempenho do sistema, além de facilitar a manutenção, atualização e substituição de componentes. Isso é muito interessante nos sistemas atuais que se caracterizam muitas vezes por atender grande número de usuários e áreas de negócio.
Um exemplo clássico de arquitetura em camadas é o padrão de projeto MVC (Model – View – Controller), em que os componentes da aplicação consistem na interface (View) que invoca o controlador (Controller), o qual, por sua vez, acessa o banco de dados (Model).
Essa separação das camadas de software permite a modularização e o reuso dos componentes do sistema. Um exemplo é ilustrado na figura a seguir, em uma aplicação hipotética (note que diversas outras formas de componentização poderiam ser adotadas, a critério do projetista).
Exemplo de diagrama de componentes usando MVC. Elaborado na ferramenta Astah UML.
Diagrama de implantação
O diagrama de implantação especifica um conjunto de artefatos de infraestrutura que podem ser utilizados para definir a arquitetura física de execução de sistemas de informação. Ele foca a organização da arquitetura sobre a qual o software irá ser implantado e executado em termos de hardware, software básico e redes de comunicação, ou seja, quais máquinas (computadores, servidores, switches etc.), quais programas de software básico (sistema operacional, sistema gerenciador de banco de dados, browser) serão necessários para suportar o sistema, bem como definir como essas máquinas serão conectadas, com qual velocidade de conexão e quais protocolos de comunicação são utilizados.
O diagrama de implantação descreve a implementação física de informações geradas pelo programa de software em componentes de hardware. Na UML, um diagrama de implantação representa a estrutura física do sistema em si, o que, assim como o diagrama de componentes, pode ser feito de várias formas.
Caixas tridimensionais representam os elementos básicos de software básico ou hardware, ou nós no sistema.
As linhas de nós a nós indicam relacionamentos.
As formas menores contidas dentro das caixas tridimensionais representam os artefatos de software contidos nos nós.
Nós do diagrama de implantação
São definidos de maneira aninhada e representam dispositivos de hardware e ambientes de execução de software. São os elementos mais básicos do diagrama de implantação; podem representar computadores pessoais e/ou servidores de bancos de dados, de aplicação ou de internet, sistemas operacionais, browser, sistemas gerenciadores de bancos de dados etc. Eles podem ser compostos de outros nós, sendo comum encontrar um nó que representa um item de hardware contendo outros nós que representam ambientes de execução.
O nó representa um elemento físico capaz de oferecer recursos computacionais e, geralmente, possui pelo menos memória e processador. Também serve para representar topologias de rede por meio de ligações entre instâncias de nós. Podem ser conectados para representar uma topologia de redes usando caminhos de comunicação que podem ser definidos como servidor de aplicação, servidor web, entre outros.
Atenção
A elaboração do diagrama de implantação depende do porte do sistema a ser desenvolvido. Por exemplo, não faz muito sentido para um sistema que será executado dentro de um único computador. Em outros casos, porém, ele pode ser muito útil, principalmente para ser utilizado como meio de comunicação entre a equipe de desenvolvimento e de infraestrutura, pois servirá de base para a equipe de infraestrutura instalar e configurar servidores, gerenciadores de bancos de dados, entre outros.
A figura a seguir ilustra um diagrama de implantação.
Exemplo de diagrama de implantação. Elaborado na ferramenta Astah UML.
Podem ser usados estereótipos que são, como em outros diagramas da UML, uma maneira gráfica ou textual de diferenciar componentes dos diagramas (classes, casos de uso, associações etc.). Podem ser representados por meio de textos escritos entre dois sinais de maior e menor quando não modificam o modelo original do componente (>) e, também, por meio de um novo componente visual, porém padronizado pela UML, como os nós que podem conter os seguintes estereótipos: >, >, >.
Clique na barra para ver as informações.
Device
Representa um dispositivo computacional com capacidade de processamento em que artefatos podem ser implantados para execução. Os dispositivos podem ser complexos, isto é, podem ser constituídos por outros dispositivos. Para representar um device, utilizamos o estereótipo >.
Artefatos
Representam objetos concretos do mundo físico, usados e/ou resultantes de um processo de desenvolvimento. São exemplos de artefatos: programas fontes e executáveis, uma tabela de bancos de dados, scripts, um documento do sistema, uma mensagem de correio eletrônico etc. Para representar um artefato, é utilizado o estereótipo >. Artefatos são sempre implantados em nós.
Ambiente de execução
Representam uma subclasse de um nó. São exemplos de ambiente de execução: sistemas operacionais, sistemas gerenciadores de bancos de dados etc. Para representar um ambiente de execução utilizamos o estereótipo >.
Associação
Os nós são conectados por meio de caminhos de comunicação para criar sistemas em rede, ou seja, possuem ligações entre si de forma que possam se comunicar e trocar informações. Essas ligações são chamadasde associações e são representadas por segmentos de reta ligando um nó a outro. Uma associação pode conter estereótipos utilizados para determinar, por exemplo, o tipo de protocolo de comunicação usado entre os nós.
VISÃO GERAL DOS DIAGRAMAS DE COMPONENTES E DE IMPLANTAÇÃO
Os componentes do diagrama de componentes e do diagrama de implantação são apresentados no vídeo a seguir.
Verificando o aprendizado
Parte superior do formulário
1. Aprendemos que o diagrama de componentes documenta arquivos físicos armazenados em meio digital, representando diversos componentes de software do sistema. Assinale a alternativa que indica de forma mais completa o que é explicitado nesse diagrama.
Reuso e relações de arquivos.
Uso e definição dos arquivos nos processos de negócio.
Estrutura, organização e relacionamentos de arquivos.
Protótipos de arquivos e suas estruturas.
Comunicabilidade e organização de arquivos.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
O diagrama de componentes representa os arquivos do sistema que contêm programas e dados, separando-os de acordo com um padrão de projeto, e mostrando sua organização, estrutura e seus relacionamentos.
Parte superior do formulário
2. No diagrama de implantação, temos o conceito de nó e como este é utilizado. É correto afirmar que os nós representam:
Qualquer dispositivo de hardware ou ambiente de execução de software.
Classes de componentes ou dispositivos de hardware.
Memória e processador.
Servidores onde acontece a execução dos componentes do software.
Os componentes de um software.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
Os nós não representam um único tipo de artefato de infraestrutura do sistema. São tipicamente definidos de maneira aninhada e representam tanto dispositivos de hardware, quanto ambientes de execução de software básico, como sistemas operacionais, sistemas gerenciadores de banco de dados, navegadores de web etc.
Conclusão
Considerações Finais
Neste conteúdo, aprendemos a desenvolver diagramas usualmente empregados na fase de projeto de software. No primeiro módulo, vimos os diagramas de interação (sequência e comunicação). No diagrama de sequência, tivemos uma visão geral e sua relação com diagrama de classes e especificações de casos de uso. Também entendemos quais são os elementos que formam esse diagrama (básicos, decisões, repetições, criação e destruição de objetos). Falamos sobre as mensagens síncronas e assíncronas. Sobre o diagrama de comunicação, aprendemos sobre que elementos compõem esse diagrama e como ele pode ser utilizado em conjunto com o diagrama de sequência.
No módulo seguinte, tratamos do diagrama de classes de projeto. Esse é um dos diagramas mais importantes da fase de modelagem do software, desde a fase de análise, passando pelo projeto até a implementação. Tratamos das responsabilidades das classes, do papel dos relacionamentos, do detalhamento de métodos e dos atributos. Aprendemos sobre navegabilidade, classes de interface, de controle e pacotes.
Em seguida, falamos sobre diagrama de atividades e diagrama de estados. Em ambos, tratamos dos conceitos básicos e de suas respectivas finalidades. Cuidamos também de falar sobre seus elementos e o passo a passo para sua construção. Por fim, aprendemos também outros dois diagramas mais físicos, mas não menos importantes, que são o diagrama de componentes e o de implantação. Em ambos, vimos finalidades e conceitos.
Podcast
Ouça o podcast. Nele são esclarecidas as dúvidas sobre a utilização de UML para projetar softwares.
0:00
18:44
Referências
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro, Brasil: Campus, 2015.
OMG. Unified Modeling Language - Versão 2.5. OBJECT MANAGEMENT GROUP, 2015.
Descrição
A modelagem de um projeto de software de acordo com o paradigma orientado a objetos, usando a linguagem UML (Unified Modeling Language).
PROPÓSITO
Aplicar os conceitos relacionados com a modelagem de um projeto de software, empregando os modelos da UML em um estudo de caso, é importante para a formação do profissional de Computação.
Preparação
Antes de iniciar o conteúdo deste tema, instale em seu computador um programa que lhe permita elaborar modelos, sob a forma de diagramas da UML (Linguagem Unificada de Modelagem). Nossa sugestão inicial é o Astah Free Student License, e será necessário usar seu e-mail institucional para ativar a licença. Preencha os dados do formulário, envie e aguarde a liberação de sua licença em seu e-mail institucional. Ao receber a licença, siga as instruções do e-mail e instale o produto em seu computador. Após a instalação, utilize o Astah para acessar os arquivos utilizados neste tema: estudoCasoPousada_analise e estudoCasoPousada_projeto.
Sugestões de links adicionais de programas livres para modelagem de sistemas em UML (UML tools) podem ser encontradas em buscas na Internet.
OBJETIVOS
Módulo 1
Produzir o documento de requisitos para um estudo de caso de modelagem de sistemas
Módulo 2
Construir o modelo de casos de uso para um estudo de caso de modelagem de sistemas em UML
Módulo 3
Construir os modelos de análise para um estudo de caso de modelagem de sistemas em UML
Módulo 4
Produzir o modelo de projeto para um estudo de caso de modelagem de sistemas em UML
Introdução
O presente tema trata do desenvolvimento de um estudo de caso que inclui as principais atividades de modelagem exigidas durante um processo de desenvolvimento de software.
Na etapa de levantamento de requisitos, são identificados os serviços a serem fornecidos pelo sistema, bem como as restrições operacionais, ou seja, os requisitos funcionais e não funcionais, respectivamente.
A etapa de análise inclui a geração do modelo de casos de uso a partir dos requisitos funcionais, sendo esse modelo composto de diagramas de casos de uso, artefatos gráficos, complementados por descrições de casos de uso, artefatos textuais. Ainda na etapa de análise, são gerados: o modelo de classes, composto de diagramas de classes, que representam as estruturas estáticas dos objetos; o modelo de atividades, composto de diagramas de atividades, que descrevem os aspectos dinâmicos do sistema exibindo passos de uma computação, sendo esses orientados a fluxos de controle; e o modelo de estados, composto de diagramas de estados, que também descrevem os aspectos dinâmicos do sistema, modelando o comportamento de objetos de uma classe na forma de uma máquina de estados, sendo esses orientados a eventos.
Na etapa de projeto, podemos destacar: a geração do modelo de interação, que inclui os diagramas de sequência e/ou diagramas de comunicação, usados para modelar a interação entre os objetos das diversas classes identificadas nas fases de análise e projeto; o refinamento do modelo de classes, com os aspectos estáticos e estruturais do sistema, ou seja, os diagramas de classes de análise; a montagem do modelo de implementação, composto de diagramas de componentes; e a elaboração do modelo de implantação, composto de diagramas de implantação.
MÓDULO 1
Produzir o documento de requisitos para um estudo de caso de modelagem de sistemas
As atividades típicas que compõem o processo de desenvolvimento de software estão ilustradas a seguir, que mostra as atividades mais comuns dos processos de desenvolvimento de software, ou seja, qualquer processo deverá possuir as referidas atividades.
Atividades típicas de um processo de desenvolvimento de software.
UML (Unified Modeling Language)
Considerando que o padrão atual da indústria de software é o paradigma orientado a objetos, a UML, ou seja, Linguagem de Modelagem Unificada, permite a geração de diversos documentos, de acordo com o referido paradigma, durante o processo de desenvolvimento de software, sendo esses documentos denominados artefatos de software, que podem ser textuais ou gráficos.
Os artefatos gráficos produzidos em um sistema orientado a objetos são definidos através dos diagramas da UML. Como mostra a imagem a seguir,os diagramas da UML são classificados em diagramas de estruturas e de comportamentos, também conhecidos como diagramas estáticos e dinâmicos, respectivamente.
Diagramas da UML.
Segue, no quadro abaixo, breve descrição dos diagramas:
	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 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.
	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 o tempo (a sequência das interações).
	Diagrama de comunicação
	Mostra como os objetos interagem, evidenciando o tempo das conexõ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, por exemplo, evidenciar as mudanças no estado de um objeto ao longo do tempo.
Tabela: Alberto Tavares da Silva.
Dica
Nem todos os 14 diagramas serão utilizados no estudo de caso. Na verdade, alguns raramente são usados na prática.
Levantamento de requisitos
Considerando as atividades genéricas que compõem o processo de desenvolvimento de software, a atividade de levantamento de requisitos, também denominada elicitação de requisitos, corresponde à etapa de compreensão do problema por parte do engenheiro de software ou equipe.
O principal objetivo do levantamento de requisitos é que usuários e equipe de desenvolvimento tenham a mesma visão do problema a ser resolvido.
Nessa etapa, os desenvolvedores, juntamente com os clientes, tentam levantar e definir as necessidades dos futuros usuários do sistema a ser desenvolvido, sendo essas necessidades denominadas requisitos. Um requisito corresponde a uma descrição de um serviço a ser fornecido pelo sistema ou uma restrição operacional.
Como podemos elicitar os requisitos?
O engenheiro de software poderá utilizar determinadas técnicas:
Leitura de obras de referência e livros-texto
Observação do ambiente do usuário
Realização de entrevistas com os usuários
Entrevistas com especialistas do domínio
Reutilização de análises anteriores
Comparação com sistemas preexistentes do mesmo domínio do negócio
ARTEFATOS DO LEVANTAMENTO DE REQUISITOS]
O especialista Alberto Tavares da Silva demonstra as atividades e os artefatos da fase de levantamento de requisitos do processo de desenvolvimento de software.
Minimundo do estudo de caso
Para fins didáticos, escolhemos um estudo de caso simples o suficiente para entendimento do problema, porém, necessariamente completo para ilustrar todas as atividades do processo de análise e projeto do sistema, empregando os diagramas da UML mais frequentemente usados na prática.
Aplicadas as técnicas de elicitação de requisitos, a equipe de engenheiros de software definiu a descrição do minimundo do estudo de caso a ser desenvolvido conforme a seguir.
Descrição do Minimundo
A empresa fictícia Pousadas Férias no Nordeste possui uma rede de pousadas e pretende contratar um sistema de software para a gestão de reservas de quartos online, incluindo a precificação das diárias e produtos disponíveis para consumo, bem como o pagamento dessas diárias e produtos consumidos pelos respectivos clientes.
Uma reserva pode ser realizada de forma online ou por meio de contato telefônico com um funcionário da recepção da pousada. O cadastro do cliente é obrigatório para confirmação da reserva. O cancelamento da reserva pode ser realizado online ou por telefone.
Os produtos disponíveis incluem bebidas, lanches e refeições diversas, sendo os consumos realizados pelos clientes registrados por funcionários atendentes de bar ou de cozinha da pousada.
Os funcionários do setor administrativo da empresa mantêm atualizados os registros necessários à realização de reservas, tais como funcionários, pousadas, quartos e outros, bem como a precificação de diárias e produtos.
A seguir, veremos os requisitos estabelecidos pela equipe de engenheiros de software.
Requisitos funcionais (RF)
A tabela a seguir lista os requisitos funcionais estabelecidos pela equipe de engenheiros de software.
	RF 1
	O sistema deve permitir que os clientes realizem reservas de quartos online ou por contato telefônico com a recepção da pousada.
	RF 2
	O sistema deve permitir que um cliente realize uma reserva somente se estiver cadastrado, podendo o referido cadastro ocorrer de forma online ou por contato telefônico.
	RF 3
	Quando o cliente realiza uma reserva online, o sistema realiza a cobrança de uma diária no cartão de crédito para confirmação da reserva.
	RF 4
	Quando o cliente realiza uma reserva por meio telefônico, o sistema exige uma pré-reserva para confirmação da reserva. Nesse caso, a recepção realiza a validação (inclui o registro do valor depositado) ou cancelamento da pré-reserva.
	RF 5
	O cliente pode cancelar uma reserva.
	RF 6
	O sistema deve permitir a precificação das diárias dos quartos das pousadas pelo setor administrativo da empresa.
	RF 7
	O sistema deve permitir a precificação dos produtos disponíveis para consumo pelos clientes pelo setor administrativo da empresa.
	RF 8
	O sistema deve interagir com um sistema terceirizado (operadora de cartão crédito) para pagamentos com cartão de crédito.
	RF 9
	Os consumos de produtos por parte dos clientes devem ser registrados pelos atendentes de bares e cozinha das pousadas.
	RF 10
	Os funcionários do setor administrativo da empresa mantêm atualizados os registros necessários à realização de reservas, ou seja, funcionários, pousadas, quartos.
	RF 11
	A quitação da reserva, realizada pela recepção da pousada e somente com cartão de crédito, deve ocorrer no check-out.
	RF 12
	O setor administrativo gera relatórios periódicos das ocupações dos quartos das pousadas.
	RF 13
	O gerente da pousada gera relatórios periódicos de ocupação dos quartos da pousada.
Requisitos funcionais do estudo de caso. Tabela: Alberto Tavares da Silva.
Requisitos não funcionais (RNF)
Os requisitos não funcionais estão associados às restrições impostas ao sistema que podem ser categorizados como de produto, organizacionais e externos. A tabela a seguir lista os requisitos não funcionais definidos pela equipe de engenheiros de software.
	RNF 1
	O sistema deve utilizar tecnologia WEB.
	RNF 2
	O SGBD adotado é o MySQL.
	RNF 3
	A linguagem de programação para desenvolvimento adotada é Java, sendo a IDE Eclipse..
	RNF 4
	O framework para o mapeamento objeto-relacional é o Hibernate.
	RNF 5
	O padrão de arquitetura adotado é o MVC (model-view-controller).RNF 6
	O processo de desenvolvimento de software adotado é o Scrum.
	RNF 7
	O prazo estimado do projeto de software é de 04 (quatro) meses.
	RNF 8
	Atributo de qualidade crítico a ser considerado na seleção de um provedor de serviço na nuvem e de internet: confiabilidade.
Requisitos não funcionais do estudo de caso. Tabela: Alberto Tavares da Silva.
Requisitos de domínio
Os requisitos de domínio, também conhecidos por regras de negócio (RN), originam-se do domínio de aplicação do sistema, em vez das necessidades específicas dos usuários do sistema.
A tabela a seguir lista as regras de negócio definidas pela equipe de engenheiros de software.
	RN 1
	Uma reserva é realizada por um único cliente.
	RN 2
	Uma reserva pode incluir no mínimo 01 (um) quarto e no máximo 03 (três) quartos disponíveis no momento da reserva.
	RN 3
	A pré-reserva exigida na reserva por meio telefônico impõe um depósito bancário, por parte do cliente, correspondente a 40% do total da reserva na conta da respectiva Pousada. Nesse caso, a validade ou cancelamento da reserva é realizada pela recepção. O cliente tem o prazo de 24h para envio do recibo de depósito via WhatsApp ou SMS.
	RN 4
	O cancelamento de uma reserva pode ser realizado até 24h antes da data de check-in estabelecida na reserva.
	RN 5
	No caso de cancelamento da reserva realizada por telefone, o valor da pré-reserva é estornado ao cliente.
	RN 6
	No caso de cancelamento por período menor que 24h, ou não comparecimento, será cobrada uma diária.
	RN 7
	Uma reserva realizada online somente é confirmada após a autorização da operadora de cartão (sistema terceirizado).
	RN 8
	Os consumos de produtos por parte dos clientes são pagos no momento do check-out, com o valor restante das diárias.
	RN 9
	O check-in é realizado a partir de 15h e o check-out, até 12h.
	RN 10
	O sistema deve permitir o pagamento da reserva online e no check-out somente com cartão de crédito.
Regras de negócio do estudo de caso. Tabela: Alberto Tavares da Silva.
Vimos neste módulo que a etapa de levantamento de requisitos, ou elicitação de requisitos, permite o entendimento do problema por parte da equipe de engenheiros de software.
Na etapa de levantamento de requisitos, é gerado o documento de requisitos categorizado em requisitos funcionais, não funcionais e de domínio, as denominadas regras de negócio.
A identificação dos requisitos é realizada por meio de técnicas, tais como leitura de obras de referência e livros-texto, observação do ambiente do usuário, realização de entrevistas com os usuários, entrevistas com especialistas do domínio e outras.
O documento de requisitos inclui os requisitos funcionais que correspondem aos serviços a serem fornecidos pelo sistema, os requisitos não funcionais, às restrições operacionais e os requisitos de domínio, que se originam do domínio de aplicação do sistema.
Verificando o aprendizado
Parte superior do formulário
1. (IESES – 2016) Um contrato de desenvolvimento de software definiu que a primeira entrega atenderia somente requisitos funcionais. Dada esta primeira entrega, o cliente entrou em contato com a empresa encarregada do desenvolvimento. O cliente dizia que não poderia aceitar esta entrega, pois o sistema estava muito lento, sendo que as especificações do contrato eram bem claras sobre o tempo de resposta do sistema. Neste cenário, pode-se afirmar que:
O cliente está errado, pois não é possível especificar em contrato garantias sobre o tempo de resposta do sistema.
O cliente está errado, pois o tempo de resposta seria um requisito não funcional do sistema.
O cliente está correto, pois o cliente está sempre correto, independentemente do que está escrito no contrato
O cliente está errado, pois o tempo de resposta não pode ser considerado como requisito de sistema.
O cliente está correto, pois o tempo de resposta é um requisito funcional do sistema.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
A primeira entrega inclui a avaliação somente dos requisitos funcionais, que correspondem aos serviços a serem disponibilizados aos usuários, sendo o tempo de resposta um requisito não funcional, ou seja, não incluída nessa entrega inicial.
Parte superior do formulário
2. (Instituto Excelência ‒ 2018 ‒ Adaptada) Considerando a análise de requisitos e os requisitos funcionais de um software, assinale a alternativa abaixo que contém apenas exemplos de requisitos funcionais.
O Sistema deverá cadastrar médicos; A base de dados deve ser protegida para acesso apenas de usuários autorizados; O sistema deve ser implementado em PHP com banco de dados SQL.
O tempo de resposta do sistema não deve ultrapassar 30 segundos; O sistema deverá gerar cadastro e agendamento de consultas; O Sistema deve ter autenticação de duplo fator.
O sistema deverá cadastrar prontuários médicos; O sistema deve gerar relatórios de pacientes atendidos; O sistema deverá fazer o cancelamento de consultas.
Infraestrutura da rede e computadores devem ser padrão open source; O tempo de resposta do sistema não deve ultrapassar 30 segundos. A base de dados deve ser protegida para acesso apenas de usuários autorizados.
O sistema deverá permitir consultas por todos os médicos; O sistema deve gerar relatórios de prontuários; A implementação do sistema deve usar o padrão MVC.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
A opção C descreve somente serviços que deverão estar disponibilizados pelo sistema aos usuários.
Avalie este módulo:
 
    
MÓDULO 2
Construir o modelo de casos de uso para um estudo de caso de modelagem de sistemas em UML
Modelo de casos de uso
Vejamos agora a etapa de análise do processo de desenvolvimento de software genérico.
Etapa: Análise.
Nessa etapa, os engenheiros de software realizam um estudo detalhado dos requisitos levantados na etapa anterior, construindo modelos para representar o sistema a ser desenvolvido. Usualmente, a primeira abstração é a funcional, pois permite aos engenheiros de software moldar o sistema de acordo com as necessidades dos usuários.
A referida abstração funcional é representada pelo modelo de casos de uso, que direciona diversas das atividades posteriores do ciclo de vida do sistema de software.
O modelo de casos de uso é composto por um ou mais diagramas de casos de uso, artefatos gráficos, e pelas descrições de casos de usos, artefatos textuais. Os componentes do referido diagrama incluem casos de uso, atores, ou seja, elementos externos que interagem com o sistema, e relacionamentos entre os elementos anteriores.
ARTEFATOS DO MODELO FUNCIONAL – DIAGRAMAS DE CASOS DE USO
O especialista Alberto Tavares da Silva apresenta o modelo de casos de uso e os diagramas do estudo de caso.
Estudo de caso – diagrama de casos de uso
Vejamos agora a construção do diagrama de casos de uso com base nos requisitos funcionais listados no módulo anterior.
RF 1
Inicialmente, vamos analisar o RF 1 a seguir:
	RF 1
	O sistema deve permitir que os clientes realizem reservas de quartos online ou por contato telefônico com a recepção da pousada.
Podemos identificar no texto um caso de uso denominado “Registrar Reserva”, interagindo com dois atores: Cliente ou Recepção. A referida abstração é representada a seguir.
Diagrama de caso de uso RF 1 gerado pela ferramenta Astah.
O relacionamento entre ambos os atores é denominado de generalização, ou seja, o ator Recepção pode realizar também o caso de uso do ator Cliente.
RF 3
Vamos analisar o RF 3 a seguir:
	RF 3
	Quando o cliente realiza uma reserva online, o sistema realiza a cobrança de uma diária no cartão de crédito para confirmação da reserva.
Podemos identificar uma funcionalidade denominada “Registrar Cobrança de Diária”, interagindo com o caso de uso “Registrar Reserva” e com o ator Operadora Cartão Crédito. A abstração proposta está representada na imagem a seguir. Nesse caso, fizemos uso da abstração denominada “extend” que representa um relacionamento entre casos de uso, ou seja, o caso de uso “Registrar Reserva” (estendido)pode, na forma de um desvio condicional, incluir o comportamento representado pelo caso de uso “Registrar Cobrança de Diária” (extensor).
Diagrama de casos de uso RF 3 gerado pela ferramenta Astah.
RF 11
Vamos analisar o RF 11 a seguir:
	RF 11
	A quitação da reserva, realizada pela recepção da pousada e somente com cartão de crédito, deve ocorrer no check-out.
Podemos identificar uma funcionalidade denominada “Realizar Check-out” e uma segunda, “Quitar Reserva”. A primeira interage com o ator Recepção. A abstração proposta está representada a seguir.
Diagrama de casos de uso RF 11 gerado pela ferramenta Astah.
Nesse caso, fizemos uso da abstração denominada “include” que representa um relacionamento entre casos de uso, ou seja, o caso de uso “Realizar Check-out” (inclusor) utiliza, na forma de um desvio incondicional, o comportamento representado pelo caso de uso “Quitar Reserva” (incluído). Por sua vez, o caso de uso “Quitar Reserva” interage com o ator Operadora de Cartão de Crédito.
Diagrama de Casos de Uso aplicando todos RF
Aplicando as devidas abstrações para todos os requisitos funcionais listados na tabela de requisitos funcionais vista no módulo 1, propomos o diagrama de casos de uso, ilustrado a seguir, para nosso estudo de caso.
Diagrama de casos de uso do estudo de caso gerado pela ferramenta Astah.
Em sistemas complexos, representar todos os casos de uso do sistema em um único diagrama de casos de uso talvez o torne um tanto ilegível. Uma possibilidade é realizar o agrupamento de casos de uso em pacotes, podendo esse agrupamento lógico ocorrer por ator, por ciclo de desenvolvimento ou por área específica da empresa.
Veja a seguir uma proposta de empacotamento por atores.
Diagrama de pacotes de casos de uso do estudo de caso gerado pela ferramenta Astah.
Atenção
Importante destacar que um dos desafios iniciais do engenheiro de software é a modularização da solução do problema, sendo que esse empacotamento permite visualizar os principais módulos que poderão compor a referida modularização.
Também vale ressaltar que não existe uma solução única para o modelo de casos de uso e tampouco para o empacotamento, sendo muito provável que diferentes equipes produzam modelos diferentes para o mesmo minimundo.
Estudo de caso – descrições de casos de uso
Lembramos que cada caso de uso é definido por meio de uma descrição textual das interações que ocorrem entre ator(es) e o sistema, não sendo a forma dessa descrição definida pela UML.
De acordo com Bezerra (2014), existem dois tipos de casos de uso:
Clique nos itens
Primários
Secundários
Vejamos um exemplo a partir de um caso de uso que apresente um objetivo bem específico para os atores Cliente e Recepção: “Registrar Reserva”. Nesse caso, temos dois cenários: um principal, que considera a reserva online realizada pelo cliente, e um alternativo, que considera a reserva realizada por telefone e registrada por um funcionário da recepção.
	Caso de uso: Registrar Reserva.
	Atores: Cliente ou Recepção (funcionário)
	Pré-condição: Cliente ou Recepção deve estar identificado pelo sistema.
	Fluxo Principal:
1. O sistema busca as pousadas disponíveis.
2. O Cliente/Recepção informa a pousada destino e as datas de check-in e check-out.
3. O sistema busca quartos disponíveis no período informado.
4. O sistema lista os quartos disponíveis para o período informado por tipo, incluindo a quantidade máxima de pessoas a serem acomodadas.
5. O Cliente/Recepção seleciona os quartos e informa a quantidade de pessoas por quarto selecionado, sendo no mínimo 1 quarto e no máximo 3 (de acordo com RN 2).
6. O sistema exige os dados de login do cliente para efetivação da reserva online.
7. O cliente informa os dados para login no sistema.
8. O sistema valida o cliente.
9. O sistema calcula o valor total da reserva.
10. O sistema gera um resumo da reserva incluindo a pousada, período, quantidade de pessoas acomodadas por quarto selecionado e valor a pagar.
11. O Cliente/Recepção confirma a reserva.
12. Obter confirmação de pagamento parcial de reserva online por meio de cartão de crédito >.
13. O sistema registra a reserva e gera o código de reserva.
	Fluxo Alternativo (6): reserva realizada por contato telefônico (recepção da pousada)
a. O sistema exige dados de login do funcionário da recepção para efetivação da reserva por contato telefônico.
b. O funcionário da recepção informa dados para login.
c. O funcionário da recepção informa o CPF do cliente.
d. O sistema valida o cliente.
e. Prosseguir no passo 9.
	Fluxo Alternativo (10): reserva realizada por contato telefônico (recepção da pousada)
a. O sistema gera um resumo da reserva incluindo a pousada, período, quantidade de pessoas acomodadas por quarto selecionado, o valor total a pagar e o valor para depósito da pré-reserva pelo cliente (de acordo com RN 3).
b. Prosseguir passo 11.
	Fluxo Alternativo (12): reserva realizada por contato telefônico (recepção da pousada)
a. Prosseguir no passo 13.
	Fluxo de exceção (12): cartão de crédito não validado pela operadora.
a. Se o cliente tiver outro cartão, repetir o passo 12, senão encerrar caso de uso.
	Pós-condição: o código da reserva deve ser informado ao cliente.
	Regras de negócio: RN 2 e RN 3.
Tabela: Alberto Tavares da Silva.
Vejamos agora uma descrição de um caso de uso considerado secundário, cuja realização inclui as operações de CRUD.
	Caso de uso: Manter Pousada.
	Atores: Setor administrativo (funcionário).
	Pré-condição: O funcionário do setor administrativo deve estar identificado pelo sistema.
	Fluxo Principal:
1. O setor administrativo seleciona a operação:
· Opção Inserir.
· Opção Consultar.
· Opção Alterar.
Opção Excluir.
	Fluxo Alternativo (1.1): Inserir
a. O sistema busca os funcionários na função de gerente.
b. O setor administrativo informa: CNPJ, nome, nome fantasia, endereço completo, telefone, e-mail de contato e seleciona o gerente da pousada.
c. O sistema valida dados da nova pousada.
d. O setor administrativo confirma o cadastro.
O sistema registra a pousada com status de “ativa”.
	Fluxo Alternativo (1.2): Consultar
a. O sistema busca as pousadas cadastradas.
b. O setor administrativo seleciona a pousada.
O sistema busca os dados da pousada, incluindo o gerente dela.
	Fluxo Alternativo (1.3): Alterar
a. O setor administrativo seleciona a pousada.
b. O sistema busca os dados da pousada, incluindo o gerente da pousada.
c. O sistema busca os funcionários na função de gerente.
d. O setor administrativo edita: CNPJ, nome, nome fantasia, endereço completo, telefone, e-mail de contato, seleciona novo gerente da pousada e/ou altera o status (ativa/inativa).
e. O setor administrativo confirma a atualização.
O sistema atualiza registro da pousada.
	Fluxo Alternativo (1.4): Excluir
a. O sistema busca as pousadas cadastradas.
b. O setor administrativo seleciona a pousada.
c. O sistema busca os dados da pousada, incluindo o gerente da pousada.
d. O setor administrativo confirma exclusão.
e. O setor administrativo informa seus dados de login para confirmar a exclusão, pois serão excluídos todos os dados associados, tais como reservas, consumos, funcionários alocados.
O sistema realiza a exclusão da pousada.
Tabela: Alberto Tavares da Silva.
Vimos neste módulo a geração do modelo de casos de uso de um estudo de caso, atividade da etapa de análise de um processo de desenvolvimento de software genérico, a partir de um documento de requisitos gerado na etapa levantamento de requisitos do referido processo.
Verificando o aprendizado
Parte superior do formulário
1. (ESAF - 2004) Na modelagem com UML, o Diagrama de Casos de Uso fornece:
O comportamento dinâmico do sistema, tornando-se ideal para especificar as exigências de tempo real ou restrições do desenho.
O contexto completo de uma interação, inclusive os objetos e seus relacionamentos pertinentes a uma interação particular.
O comportamento estático do ator que participa deste diagrama, apenas com o objetivo de receber a informação final de execução doprocesso.
Um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade do sistema mediante uma requisição do usuário.
Um gráfico de atores montado sem a especificação de domínio, comunicações ou associações entre atores.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
O diagrama de casos de uso é um modelo com alto nível de abstração, onde são definidas as funcionalidades que irão atender às expectativas dos usuários denominados atores.
Parte superior do formulário
2. 2) (FGV - Senado Federal - 2008) Considere o caso de uso ilustrado na figura utilizando a notação UML.
A descrição do cenário que melhor descreve esse caso de uso é:
O atendente verifica o histórico dos pacientes que possuem consultas agendadas.
Um paciente liga para a clínica para marcar uma consulta. A atendente verifica o histórico do paciente, busca um horário vazio e agenda a consulta.
O atendente inclui os pacientes que têm consulta agendada e não possuem um histórico de atendimento.
O paciente liga para a clínica para agendar uma consulta e para alterar o seu histórico.
O atendente não marca consultas para pacientes que não tenham histórico na clínica.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
No caso de o paciente ligar para a clínica, o ator responsável pelo agendamento é o Atendente, sendo o comportamento do caso de uso “Verificar Histórico do Paciente” realizado pelo caso de uso inclusor “Agendar Consulta” em função da abstração que estabelece o relacionamento entre os dois casos de uso denominada .
Avalie este módulo:
 
    
MÓDULO 3
Construir os modelos de análise para um estudo de caso de modelagem de sistemas em UML
Modelo de classes
Após termos gerado o modelo de casos de uso com as funcionalidades a serem disponibilizadas aos usuários, e ainda na etapa de análise do processo de desenvolvimento de software genérico, vamos à construção do modelo de classes.
As referidas funcionalidades necessitam, internamente, que objetos colaborem mutuamente para produção dos resultados esperados pelos respectivos usuários; essa colaboração possui um aspecto estrutural estático que permite compreender como o sistema está estruturado internamente para que as citadas funcionalidades externamente visíveis sejam produzidas.
A abstração que permite identificar o aspecto estrutural e estático dos objetos que compõem a solução do problema é a modelagem de classes.
Um modelo de classes é composto por um ou mais diagramas de classes, mostrando a existência das classes e os seus relacionamentos numa visão lógica e estática do sistema.
Atenção
O modelo de classes evolui durante o processo de desenvolvimento. Portanto, o modelo de classes na etapa de análise não deve representar detalhes da solução do problema, limitando-se à identificação das classes, atributos e associações.
Classes se relacionam com outras classes ou mesmo com a própria classe através de associações, que podem ser associações simples ou específicas, como a agregação, a composição e a generalização/especialização. Esta última é também conhecida como herança, pelo fato de as classes especializadas (subclasses) herdarem as propriedades das classes genéricas (superclasses). Quando uma subclasse for uma especialização de diferentes superclasses, ocorre a herança múltipla, prevista na orientação a objetos e implementada pela UML.
ARTEFATOS DO MODELO DE CLASSES
O especialista Alberto Tavares da Silva apresenta o modelo de classes e os diagramas do estudo de caso.
Estudo de caso – modelo de classes
Daremos continuidade ao nosso estudo de caso a partir dos casos de uso identificados no módulo anterior, aplicando a técnica de identificação de classes denominada “Análise de casos de uso”, ou seja, a técnica de identificação dirigida por casos de uso. Nessa técnica, o engenheiro de software busca identificar as classes necessárias para produzir o comportamento que está documentado na descrição de caso de uso, de modo que quando todos os casos de uso tiverem sido analisados, todas as classes terão sido identificadas, ou a maioria delas.
Selecionemos o caso de uso “Registrar Reserva” para início da criação do nosso modelo de classes. Analisando a descrição textual desse caso de uso, mostrada anteriormente, podemos identificar os seguintes objetos:
Cliente
Funcionário (reserva realizada por telefone)
Reserva
Pousada
Quarto
Tipo de quarto
Preço da diária (para cálculo do valor total da reserva)
Pagamento (no caso de reserva online)
O diagrama de classes de análise para o caso de uso Registrar Reserva, a seguir, propõe uma solução para a estrutura estática dos objetos identificados, cabendo ressaltar que a tipagem de dados no modelo de classes de análise não é obrigatória.
Diagrama de classes de análise para o caso de uso Registrar Reserva gerado pela ferramenta Astah.
Vejamos as principais abstrações aplicadas:
swap_horiz Arraste para os lados.
Pessoa é uma superclasse de Cliente e Funcionário.
Toda reserva está associada a 1 (um) cliente, que pode fazer 1 (uma) ou mais reservas.
Uma reserva é registrada por no mínimo 0 (zero) funcionário (reserva online) e no máximo 1 (um) funcionário (reserva por telefone).
Uma reserva pode possuir no mínimo 1 (um) e no máximo 3 (três) quartos (RN 2).
• Uma pousada possui no mínimo 1 (um) e no máximo vários quartos, sendo utilizada a associação de composição, ou seja, o objeto parte (Quarto) só tem existência se o objeto todo (Pousada) existir.
Um quarto se associa com várias instâncias da classe PrecoDiaria, sendo o valor cobrado dependente da data da reserva.
Uma reserva pode estar associada a no mínimo 0 (zero), caso de reserva por telefone, ou no máximo vários pagamentos por cartão, caso de reserva online.
Historicamente, um funcionário pode ter gerenciado 0 (zero) ou mais pousadas e uma pousada pode ter sido gerenciada por 1 (um) ou mais gerentes.
Aplicando a mesma abstração, com foco nos objetos, para os demais casos de uso, temos como resultado o diagrama de classes de análise proposto para o nosso estudo de caso ilustrado a seguir.
Diagrama de classes do estudo de caso gerado pela ferramenta Astah.
Atenção
Assim como no modelo de casos de uso, é importante ressaltar que não há uma solução única para o modelo de classes, em face das diversas possibilidades de modelagem de classes, atributos e associações resultantes do modelo de casos de uso.
Destacamos a abstração aplicada à classe Consumo, sendo essa uma classe associativa resultante da associação entre Quarto e Produto, e que depois se associa à classe Funcionário, responsável pelo registro do consumo. Normalmente, uma classe associativa é necessária quando duas ou mais classes estão associadas, sendo necessário manter informações sobre essa associação, ou seja, toda vez que ocorre um consumo é registrada a data e a quantidade do produto consumido por um funcionário. Essa solução foi aplicada à classe associativa Gerenciamento que permite identificar a data em que um funcionário assume a função de gerente em uma pousada, bem como a respectiva data de liberação da função.
Modelo de atividades
O modelo de atividades é composto por diagramas de atividades que, entre outros, descrevem os aspectos dinâmicos de um sistema, ou seja, um diagrama de atividade exibe passos de uma computação. Os referidos diagramas possuem as seguintes aplicações:
Clique nos itens
Modelagem de processo de negócio
Modelagem da lógica de um caso de uso
Modelagem da lógica de uma operação
Estudo de caso ‒ modelo de atividades
Prossigamos no nosso estudo de caso construindo o diagrama de atividades que represente graficamente a modelagem da descrição de caso de uso “Registrar Reserva”, estabelecida anteriormente de forma textual em “Estudo de caso – descrições de casos de uso”.
Analisando a referida descrição, podemos observar que a interação ocorre entre os atores Cliente/Recepção (que possuem um relacionamento de generalização) e o sistema, ou seja, o diagramade atividades deve conter duas raias de acordo com a imagem a seguir, de modo que algumas atividades são de responsabilidade dos atores e outras, do sistema.
Diagrama de atividades parcial do caso de uso Registrar Reserva gerado pela ferramenta Astah.
No diagrama de atividades parcial do caso de uso Registrar Reserva, podemos ver as primeiras etapas de montagem do diagrama considerando os seguintes passos computacionais:
	Fluxo Principal:
a. O sistema busca as pousadas disponíveis.
b. O Cliente/Recepção informa a pousada destino e as datas de check-in e check-out.
c. O sistema busca quartos disponíveis no período informado.
d. O sistema lista os quartos disponíveis para o período informado por tipo, incluindo a quantidade máxima de pessoas a serem acomodadas.
e. O Cliente/Recepção seleciona os quartos e informa a quantidade de pessoas por quarto selecionado, sendo no mínimo 1 quarto e no máximo 3 (de acordo com RN 2 – Tabela 3).
f. O sistema exige os dados de login do cliente para efetivação da reserva online.
...
	Fluxo Alternativo (6): reserva realizada por contato telefônico (recepção da pousada)
a. O sistema exige dados de login do funcionário da recepção para efetivação da reserva por contato telefônico.
Tabela: Alberto Tavares da Silva.
Após a definição das raias, podemos inserir o elemento que representa o início do processo (círculo escuro). O primeiro passo a considerar é “Busca as pousadas disponíveis” sob responsabilidade do Sistema, sendo a próxima atividade “Informa a pousada destino e as datas de check-in e check-out”, do ator Cliente/Recepção. Interessante observar que no passo 6 “O sistema exige os dados de login do cliente para efetivação da reserva online” temos um fluxo alternativo (losango), ou seja, caso a reserva seja online, a atividade a ser realizada pelo sistema é “Exige os dados de login do cliente para efetivação da reserva online” e, no caso de reserva por telefone, a atividade será “Exige dados de login do funcionário da recepção para efetivação da reserva por contato telefônico”. Aplicando a mesma abstração nos demais fluxos da referida descrição, teremos o diagrama de atividades do caso de uso “Registrar Reserva” ilustrado na imagem a seguir, onde podemos observar que o fluxo de atividades tem quatro possíveis encerramentos, representados pelos círculos vazados.
Diagrama de atividades do caso de uso Registrar Reserva gerado pela ferramenta Astah.
Modelo de estados
Ainda na etapa de análise do processo, vejamos o modelo de estados.
No contexto do paradigma orientado a objetos, um determinado objeto possui um estado particular, mudando de estado quando acontece algum evento interno ou externo ao sistema.
Nessa transição de um estado para outro, um objeto realiza determinadas ações dentro do sistema.
O modelo de estados é composto por diagramas de estados que descrevem os possíveis estados pelos quais objetos, instâncias de uma determinada classe, podem passar e as alterações dos estados como resultado de eventos que atingem esses objetos.
Estudo de caso ‒ modelo de estados
Dando continuidade ao nosso estudo de caso, podemos identificar, no diagrama de classes do estudo de caso, uma classe cujos objetos possuem mudanças significativas de estados, a classe Reserva. Uma reserva pode assumir estados durante a execução do software, tal como no diagrama de atividades do caso de uso Registrar Reserva. Uma reserva pode ter dois estados iniciais:
Em validação
Quando a reserva é realizada por telefone
Confirmada
Quando a reserva é realizada de forma online
Analisemos a mudança de estado de “Em validação” para “Confirmada”, cuja expressão para transição é “Cliente deposita pré-reserva [até 24h depois da reserva] / Confirmar reserva”, ou seja, temos a expressão “evento [condição de guarda] / ação”. O evento corresponde a “Cliente deposita pré-reserva”, a condição para a mudança de estado inclui “[até 24h depois da reserva]” e, finalmente, a ação correspondente no sistema é denominada de “Confirmar reserva”. Aplicando a mesma expressão às demais mudanças de estados, temos o diagrama de estados ilustrado a seguir.
Diagrama de estados para a classe Reserva gerado pela ferramenta Astah.
Vimos, neste módulo, a construção dos artefatos da fase de análise, a saber:
Clique nas barras para ver as informações.
Modelo de classes de análise
Corresponde à estrutura estática dos objetos que irão colaborar mutuamente para a produção dos resultados esperados pelos respectivos usuários, ou seja, essa colaboração possui um aspecto estrutural estático que permite compreender como o sistema está estruturado internamente para que as citadas funcionalidades externamente visíveis sejam produzidas.
Modelo de atividades
Composto de diagramas de atividades, permite descrever os aspectos dinâmicos de um sistema tendo três possíveis aplicações: modelagem de processo de negócio, modelagem da lógica de um caso de uso e modelagem da lógica de uma operação ou método.
Modelo de estados
Composto de diagramas de estados, permite também identificar aspectos dinâmicos de um sistema, sendo que a transição entre estados ocorre a partir de um evento externo, incluindo uma ou mais condições de guarda e uma correspondente ação no sistema.
Verificando o aprendizado
Parte superior do formulário
1. (FEPESE – SEFAZ – SC – 2010) Relacione cada tipo de diagrama de UML da Coluna 1 com os respectivos elementos sintáticos da Coluna 2.
Coluna 1
1. Diagrama de atividades
2. Diagrama de máquina de estados
Coluna 2
( ) Ação
( ) Estado final
( ) Fluxo de controle
( ) Pseudoestado inicial
( ) Nodo fusão
( ) Pseudoestado escolha
( ) Transição
Assinale a alternativa que indica a sequência correta, de cima para baixo.
1 - 2 - 1 - 2 - 1 - 1 - 1
1 - 2 - 1 - 2 - 1 - 2 - 1
1 - 2 - 1 - 2 - 1 - 2 - 2
1 - 2 - 2 - 2 - 1 - 2 - 2
2 - 1 - 2 - 1 - 2 - 1 - 1
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
Ação, fluxo de controle e nodo fusão são elementos sintáticos do diagrama de atividades, que modela a dinâmica do sistema como um todo; e estado final, pseudoestado inicial, pseudoestado escolha e transição são elementos sintáticos do diagrama de estados, também denominado diagrama de máquina de estados, que modela a dinâmica de objetos específicos.
Parte superior do formulário
2. (CESGRANRIO ‒ BR Distribuidora ‒2008)
A figura anterior mostra um diagrama de classes UML desenvolvido para um projeto em que ainda não se sabe em que linguagem será realizada a implementação. Sobre o diagrama, assinale a afirmação correta.
Há um erro na cardinalidade da associação entre ClasseA e ClasseB, pois se trata de uma composição e, como tal, um objeto da ClasseB só pode estar associado a um objeto da ClasseA.
Há uma dependência cíclica entre ClasseB, ClasseC e ClasseE, o que não é permitido pela UML.
O fato de que ClasseD generaliza ClasseA e ClasseB se traduz em herança múltipla, o que não é permitido pela UML.
Retirando a ClasseA, o diagrama resultante corresponde ao padrão de projeto composite.
e) Invertendo o sentido de todas as generalizações, o diagrama resultante corresponde ao padrão de projeto chain of responsability.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
A composição é um relacionamento do tipo todo-parte, onde o objeto-todo (no caso a ClasseA) controla o ciclo de vida do objeto-parte (no caso a ClasseB), quer dizer, o objeto-parte não tem sentido existir sem o seu objeto-todo. Nesse caso, um objeto da ClasseB se relaciona com uma única instância de objeto da ClasseA.
Obrigado pelo feedback!
MÓDULO 4
Produzir o modelo de projeto para um estudo de caso de modelagem de sistemas em UML
Daremos continuidade ao nosso estudo de caso, que trata do gerenciamento de uma rede de pousadas, desenvolvendo os principais modelos da etapa de projeto do processo de desenvolvimento de software genérico.
Etapa: Projeto.
Modelo de interação
O modelo de interação é composto por diagramas de sequência e/ou diagramas de comunicação, podendo ser iniciado na fase de análise ou na fase deorientado 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.
(Bezerra, 2015)
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á calcada 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, por exemplo, um aluno, uma disciplina, um curso, um professor, entre outros, considerando um sistema acadêmico como contexto. Ou seja, um objeto é qualquer coisa do mundo real, de interesse no contexto em estudo.
Programadores.
Quando analisamos os objetos pertinentes a um contexto, não estamos preocupados com um objeto específico, como o aluno José Carlos Aragão, e sim com todos os alunos envolvidos no estudo. Surge, então, o conceito de classe que, conceitualmente, reúne um conjunto de objetos com as mesmas propriedades. Ou seja, estamos interessados em todos os alunos e não apenas em José Carlos Aragão. Aplicando o princípio da abstração (que será detalhado posteriormente), uma classe reúne objetos com características ou propriedades semelhantes, que consistem em seus dados (atributos) e procedimentos (métodos) que implementam os serviços que essa classe oferece.
A classe Aluno agrupa “José Carlos Aragão” e os demais alunos envolvidos. 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 de 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, entre outros.
Resumindo, podemos definir classe e objeto da seguinte forma. Observe!
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.
Confira 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).
Classe Aluno
Agora, veja a representação de dois objetos da classe Aluno.
Objeto − Aluno 1 da classe Aluno.
Objeto − Aluno 2 da classe Aluno.
Operação, mensagem e estado
Um sistema 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 parte da tarefa. Acompanhe!
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
Estímulo que chega a um objeto e solicita que ele realize uma de suas operações. Uma operação pode ser implementada através de pelo menos um método. Em outras palavras, cada objeto presta um serviço. Quando um 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.
Um sistema orientado a objetos funciona pela cooperação entre objetos, cada um responsável por parte das funcionalidades. Objetos realizam ações chamadas operações em resposta a estímulos chamados mensagens. O estado de um objeto é determinado pelos valores de seus atributos, que podem ser alterados pelas mensagens recebidas.
Objeto
Imagine, por exemplo, que o objeto Notas_Aluno contenha as notas do aluno em determinada disciplina. Em dado momento, é recebida uma mensagem informando uma nova nota a ser armazenada. O estado desse objeto foi alterado, pois um de seus atributos recebeu a nova nota.
Agora, suponha que determinado objeto enviou uma mensagem a Notas_Aluno solicitando que seja exibida a média atual; nesse caso, não houve alteração de estado, pois as notas foram consultadas, e a média foi calculada (não fica armazenada) e exibida.
Observe a seguir como se comporta as partes de um objeto ao receber a mensagem.
Partes de um objeto.
Atividade 1
Questão 1
Sobre os conceitos e pilares do paradigma orientado a objeto, analise as assertivas a seguir.
 
I - Se uma disciplina é uma classe, "modelagem de sistemas com UML" é um objeto dessa classe.
 
II - Em um sistema orientado a objeto, quando um objeto precisa de um serviço prestado por outro, ele deve enviar uma mensagem a esse objeto.
 
III - Como consequência do princípio do encapsulamento, temos que os atributos de um objeto devem estar acessíveis diretamente por todos os demais objetos.
 
IV - E possível que apliquemos o polimorfismo sem antes aplicar o mecanismo da herança.
 
V - A orientação a objetos visa também facilitar o reúso de software.
 
Com base em sua análise das assertivas, assinale a alternativa correta:
A
Estão corretas apenas as assertivas I, III e V.
B
Estão corretas apenas as assertivas I, II e V.
C
Estão corretas apenas as assertivas I e V.
D
Estão corretas apenas as assertivas I, II, III e V.
E
Estão corretas apenas as assertivas II e V.
Responder
Parabéns! A alternativa B está correta.
Estão corretas as afirmativas: I, pois objeto é uma instância específica de uma classe. Classe é o molde de objetos afins (mesmos atributos e métodos); II, pois esse é um dos conceitos fundamentais de orientação a objeto; V, já que o aumento do reúso é um dos propósitos da existência do paradigma OO. 
 
Estão incorretas as afirmativas: III, porque o encapsulamento diz que os atributos devem ser protegidos de acesso direto por demais objetos; IV, visto que somente pode haver polimorfismo se antes houve a aplicação do princípio da herança.
Principais características do paradigma orientado a objeto
Compreender conceitos como encapsulamento, herança, polimorfismo e abstração permite aos desenvolvedores criarem soluções mais modulares, flexíveis e fáceis de manter. Essas características capacitam os profissionais de tecnologia a desenvolverem sistemas que melhor representam e modelam objetos do mundo real, resultando em um código mais legível, reutilizável e escalável. Em resumo, o conhecimento teórico dessas características é essencial para impulsionar a qualidade e a eficácia no desenvolvimento de software orientado a objetos.
Os pilares da orientação a objetos
Entre as principais características do paradigma orientado a objeto (OO), destacamos:
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. A abstração permite que, ao estudar algo, 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. E os aspectos essenciais de um objeto dependem, claro, do contexto no qual os analisamos, podendo variar. Ou seja, 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). Com isso, o encapsulamento protege os dados do objeto do uso arbitrário ou não intencional.
O encapsulamento é uma técnica para minimizarprojeto para representar os aspectos dinâmicos do sistema. Consideremos que o início da sua construção ocorre na etapa de projeto do processo, tendo como finalidade principal detalhar os objetos e mensagens requeridas na realização de um caso de uso.
Embora os modelos representem visões distintas do sistema, esses modelos são interdependentes, estando a modelagem de interação diretamente relacionada com a modelagem de casos de uso e a modelagem de classes.
Clique nas barras para ver as informações.
Diagrama de sequência
Este diagrama organiza os objetos participantes da interação na horizontal, sendo que cada objeto possui uma linha de vida e as mensagens entre esses objetos são representadas com linhas horizontais rotuladas partindo da linha de vida do objeto remetente e chegando à linha de vida do objeto receptor. A posição vertical das mensagens permite deduzir a ordem na qual elas são enviadas.
Diagrama de comunicação
Este diagrama organiza os objetos em forma de nós, sendo adicionados setas e rótulos de mensagens nas ligações entre esses objetos; a ordem das mensagens é explicitada pela sua numeração sequencial no diagrama de comunicação.
Atenção
Os diagramas de comunicação e sequência representam as mesmas interações e devem estar consistentes com o diagrama de classes e com a respectiva descrição de caso de uso.
ARTEFATOS DO MODELO DE INTERAÇÃO
O especialista Alberto Tavares da Silva apresenta o modelo de interação e seus diagramas do estudo de caso.
Estudo de caso – modelo de interação
Daremos continuidade ao nosso estudo de caso, gerando o diagrama de sequência do caso de uso “Registrar Reserva”. Como afirmado anteriormente, esse diagrama possui uma interdependência com os modelos de casos de uso e modelo de classes, portanto vamos iniciar nossa abstração “dinâmica” com a descrição do referido caso de uso desenvolvida no tópico Estudo de caso – modelo de casos de uso, sendo parcialmente replicada a seguir:
	Caso de uso: Registrar Reserva.
	Atores: Cliente e Recepção (funcionário)
	Pré-condição: Cliente ou Recepção deve estar identificado pelo sistema.
	Fluxo Principal:
1. O sistema busca as pousadas disponíveis.
2. O Cliente/Recepção informa a pousada destino e as datas de check-in e check-out.
3. O sistema busca quartos disponíveis no período informado.
4. O sistema lista os quartos disponíveis para o período informado por tipo, incluindo a quantidade máxima de pessoas a serem acomodadas.
5. O Cliente/Recepção seleciona os quartos e informa a quantidade de pessoas por quarto selecionado, sendo no mínimo 1 (um) quarto e no máximo 3 (três) (de acordo com RN 2).
6. O sistema exige os dados de login do cliente para efetivação da reserva online.
7. ...
	Fluxo Alternativo (6): reserva realizada por contato telefônico (recepção da pousada)
a. O sistema exige dados de login do funcionário da recepção para efetivação da reserva por contato telefônico.
b. O funcionário da recepção informa dados para login.
c. O funcionário da recepção informa o CPF do cliente.
d. O sistema valida o cliente.
e. Prosseguir no passo 9.
Tabela: Alberto Tavares da Silva.
Temos que considerar na construção do modelo de interação o requisito não funcional “RNF 5 ‒ O padrão de arquitetura adotado é o MVC (model-view-controller)”, pois novos objetos serão incorporados, a fim de permitir que o projeto do sistema tenha um nível de detalhamento suficiente para sua implementação.
Diagrama de sequência
Retornando à nossa descrição, analisemos o passo 1, “O sistema busca as pousadas disponíveis”, estando a respectiva modelagem ilustrada a seguir. Nos diagramas de interação, por convenção de boa prática, empregamos os sufixos Model, View e Controller na denominação dos objetos, para indicar as camadas respectivas na fase de implementação do modelo.
Diagrama de sequência parcial do caso de uso “Registrar Reserva” gerado pela ferramenta Astah.
A interação do ator, cliente ou funcionário da recepção definido no diagrama de casos de uso do estudo de caso, é iniciada pelo método CreateAction da classe controladora ReservaController que, por sua vez, instancia um objeto PousadaModel, que é um objeto entidade identificado a partir do diagrama de classes de análise, a fim de que esse busque as pousadas disponíveis.
Em seguida, analisemos os passos 2, “O Cliente/Recepção informa a pousada destino e as datas de check-in e check-out” e 3, “O sistema busca quartos disponíveis no período informado”, cujas modelagens estão representadas a seguir.
Diagrama de sequência parcial do caso de uso “Registrar Reserva” passo 2 gerado pela ferramenta Astah.
Após uma segunda interação do ator, ou seja, seleção da pousada, uma função JavaScript na camada View aciona um método na classe controladora a fim de buscar os quartos disponíveis para a selecionada pousada no período desejado, conforme observado na imagem a seguir.
Diagrama de sequência parcial do caso de uso “Registrar Reserva” passo 3 gerado pela ferramenta Astah.
Finalmente, vamos analisar o passo 6, “O sistema exige os dados de login do cliente para efetivação da reserva online”. 
Após uma quarta interação do ator, ou seja, informação de dados do login, ocorre a possibilidade de dois cenários estabelecidos pelos fluxos principal e alternativo, ou seja, reserva realizada pelo cliente (principal) ou pelo funcionário da recepção (alternativo). O operador “alt” permite representar essa abstração, pois caso o ator seja o cliente, será acionado o respectivo método de validação, e caso seja o funcionário, ocorrerá a respectiva validação de login, bem como a validação do CPF do cliente.
Na quinta interação, a confirmação da reserva, temos duas opções de acordo com o cenário; no cenário que a reserva é realizada pelo ator cliente, ocorre a extensão do caso de uso Registrar Cobrança de Diária, reveja o diagrama de casos de uso do estudo de caso:
Extend em diagrama de casos de uso do estudo de caso gerado pela ferramenta Astah.
Caso essa cobrança seja confirmada, ou a reserva seja realizada pelo ator funcionário da recepção (cenário alternativo), ocorre o registro da reserva. Após a aplicação das abstrações descritas, propomos o diagrama de sequência ilustrado a seguir.
Diagrama de sequência do caso de uso “Registrar Reserva” gerado pela ferramenta Astah.
Diagrama de comunicação
Agora, vejamos a elaboração do diagrama de comunicação para o mesmo caso de uso, ou seja, “Registrar Reserva”. Nesse caso, podemos aplicar a mesma abstração aplicada na construção do diagrama de sequência, ou seja, a partir da descrição de caso de uso e do diagrama de classes identificar os objetos que fazem parte da solução do caso de uso e as respectivas trocas de mensagens, levando em consideração algum requisito não funcional relacionado com o padrão de arquitetura adotado (no caso MVC). A imagem a seguir ilustra o diagrama de comunicação proposto. Note que a sequência da execução é ordenada pelos números sequenciais das mensagens e o resultado das interações é o mesmo do diagrama de sequência.
Diagrama de comunicação do caso de uso “Registrar Reserva” gerado pela ferramenta Astah.
Modelo de classes de projeto
O modelo de classes de projeto é resultante de refinamentos no modelo de classes de análise, sendo incluídos detalhes úteis para a implementação das respectivas classes.
Dica
Como boa prática, sugerimos que esse modelo seja construído em paralelo com o modelo de interações.
Estudo de caso ‒ modelo de classes de projeto
Aplicando os principais refinamentos no diagrama de classe de análise para o caso de uso Registrar Reserva ilustrado anteriormente no módulo 3, propomos o diagrama de classes de projeto apresentado a seguir. A sintaxe dos atributos foi definida no modelo de análise, sendo as visibilidades privativas (qualificador de visibilidade “–“).
Diagrama de classes de projeto para o caso de uso Registrar Reserva gerado pela ferramenta Astah.
Podemos observar que as mensagens definidas no diagrama de sequência apresentado anteriormente foram incorporadas como métodos na respectivas classes, tal como a mensagem“10.1 Registrar()” implementada na classe destino “Reserva”, incluindo o tipo de visibilidade, no caso públicas (qualificador de visibilidade “+”), e tipo de retorno.
Vamos exemplificar refinamentos relacionados com a navegabilidade entre classes (repare nas multiplicidades de cada associação):
(a)
ocorrência de uma associação bidirecional entre Cliente/Reserva, pois a navegabilidade não está representada por flechas, ou seja, o envio de mensagens deverá ocorrer em ambos os sentidos, sendo que um objeto Cliente poderá instanciar uma coleção de objetos Reserva (veja atributo oLstReserva) e um objeto Reserva poderá instanciar um objeto Cliente (veja o atributo oCliente).
(b)
ocorrência de uma associação unidirecional entre Reserva/Quarto, pois a navegabilidade está representada por uma flecha, ou seja, o envio de mensagens deverá ocorrer em um único sentido, sendo que um objeto Reserva poderá instanciar uma coleção de objetos Quarto (veja atributo oLstQuarto).
Nosso diagrama de classes de projeto para o caso de uso Registrar Reserva permite ilustrar, também, o refinamento relacionado com o conceito de classe abstrata, que permite organizar hierarquias gen/spec e a implementação do princípio do polimorfismo. A classe Pessoa é uma classe abstrata estando a mesma em itálico.
Aplicando a abstração descrita para o caso de uso “Registrar Reserva” para os demais casos de uso, teremos o diagrama de projeto do sistema.
Dica
Os métodos de acesso get/set, ou as propriedades, não estão representados em função da geração automática pelos compiladores modernos a partir dos atributos.
Modelo de implementação
O modelo de implementação é composto de um ou mais diagramas de componentes, que permite representar, de forma gráfica, os componentes do sistema e suas dependências.
Estudo de caso ‒ modelo de implementação
Retornemos ao nosso estudo de caso, ainda na fase de projeto do processo. A imagem a seguir ilustra uma proposta para o diagrama de componentes, considerando os modelos de casos de uso (módulo 2), de classes (módulo 3) e de interação (módulo 4).
Diagrama de componentes para o estudo de caso gerado pela ferramenta Astah.
A partir do empacotamento de casos de uso, propomos uma solução (entre outras muitas!) onde cada pacote corresponde a uma aplicação. Cada aplicação possui suas próprias classes controladoras (pacote Controller) e views (pacote View); entretanto, as classes do tipo model (stereotype) são acessadas por todas as aplicações por uma interface IPadrao. Como especificado no requisito não funcional RNF 2 no módulo 1, o banco de dados é o MySql, sendo o framework de persistência o Hibernate (RNF 4). Lembramos que esse diagrama representa um alto nível de abstração, pois podemos detalhar cada aplicação com um respectivo diagrama de componentes.
Modelo de implantação
O modelo de implantação é composto de um ou mais diagramas de implantação e define os nós de processamento disponíveis, ou seja, os componentes físicos do sistema e suas interdependências. A referida modelagem cresce de importância em função da complexidade do sistema.
Estudo de caso ‒ modelo de implantação
A imagem a seguir ilustra uma proposta de diagrama de implantação para o nosso estudo de caso, sendo necessários apenas três nós computacionais para sua implantação.
Diagrama de implantação para o estudo de caso gerado pela ferramenta Astah.
Neste módulo, demos continuidade ao estudo de caso que trata do gerenciamento de uma rede de pousadas desenvolvendo os principais modelos da etapa de projeto do processo de desenvolvimento de software genérico.
Neste módulo vimos os seguintes modelos:
Clique nos itens.
Modelo de interação
Modelo de classes de projeto
Modelo de implementação
Modelo de implantação
Verificando o aprendizado
Parte superior do formulário
1. (ESAF – CGU – 2006) Quanto ao uso de diagramas na UML para a modelagem de objetos, é correto afirmar que o diagrama de sequência:
Descreve a funcionalidade do sistema percebida por atores externos.
Apresenta a interação de sequência de tempo dos objetos que participam na interação.
Apresenta a interação de sequência de atores que participam na interação.
Descreve a funcionalidade do sistema percebida por atores internos.
Apresenta a interação de sequência estática de pacotes, relacionamentos e instâncias.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
O diagrama de sequência representa a sequência de mensagens trocadas entre objetos.
Parte superior do formulário
2. (FGV ‒ DPE-RJ ‒ 2014) Maria participa de um projeto cujo objetivo é desenvolver em C# uma versão orientada a objetos de um software legado, e deseja criar um diagrama UML para definir os modelos das classes do sistema. Esse diagrama deve representar as estruturas dessas classes, determinando:
O conjunto de casos de testes segundo as melhores práticas de desenvolvimento de software.
A sequência de criação dos objetos.
Os atributos e os métodos.
Os casos de uso que deram origem ao diagrama.
O número de objetos que serão criados quando o sistema estiver em produção.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
O modelo de classes de projeto permite o refinamento dos atributos identificados no modelo de classes de análise e a identificação dos métodos, ou operações, que compõem cada classe a partir dos diagramas de sequência ou comunicação.
Avalie este módulo:
 
    
Conclusão
Considerações Finais
Apresentamos neste tema um estudo de caso que permitiu a aplicação dos conceitos relacionados com a modelagem de um projeto de software, incluindo as etapas de levantamento de requisitos, análise e projeto do processo de desenvolvimento de software genérico.
Na etapa de levantamento de requisitos, identificamos os serviços a serem fornecidos pelo sistema, bem como as restrições operacionais, ou seja, os requisitos funcionais, não funcionais e as regras de negócio.
Na etapa de análise foram gerados, a partir dos requisitos funcionais, o modelo de casos de uso, composto de diagramas de casos de uso e de descrições de casos de uso, o modelo de classes, composto de diagramas de classes, o modelo de atividades, composto de diagramas de atividades, e o modelo de estados, composto de diagramas de estados.
Na etapa de projeto, foi gerado o modelo de interação, que inclui os diagramas de sequência e/ou diagramas de comunicação, o modelo de classes de projeto, composto de diagramas de classes devidamente refinados a partir dos diagramas de classes de análise, o modelo de implementação, composto de diagramas de componentes, e o modelo de implantação, composto de diagramas de implantação.
image6.jpeg
image69.png
image70.jpeg
image71.jpeg
image72.jpeg
image73.jpeg
image74.jpeg
image75.jpeg
image76.jpeg
image77.jpeg
image7.jpeg
image78.jpeg
image79.png
image80.png
image81.jpeg
image82.jpeg
image83.jpeg
image84.jpeg
image8.jpeg
image85.jpeg
image86.jpeg
image87.jpeg
image88.jpeg
image89.jpeg
image90.jpeg
image9.jpeg
image91.jpeg
image92.jpeg
image93.jpeg
image94.jpeg
image95.jpeg
image96.jpeg
image97.jpeg
image10.jpeg
image98.jpeg
image99.jpeg
image100.jpeg
image101.jpeg
image102.jpeg
image103.jpeg
image104.jpeg
image11.jpeg
image105.jpeg
image106.jpeg
image107.jpeg
image108.jpeg
image109.jpeg
image110.jpeg
image111.jpeg
image112.jpeg
image12.jpeg
image13.jpeg
image14.jpeg
image15.jpeg
image16.jpeg
image17.jpeg
image18.jpeg
image19.jpeg
image20.jpeg
image21.jpeg
image22.jpeg
image23.jpeg
image24.jpeg
image25.jpeg
image26.jpeg
image27.jpeg
image28.jpeg
image29.jpeg
image30.jpeg
image31.jpeg
image32.jpeg
image1.jpeg
image33.jpeg
image34.jpeg
image35.jpeg
image36.jpeg
image37.jpeg
image38.jpeg
image39.jpeg
image40.jpeg
image2.jpeg
image41.jpeg
image42.jpeg
image43.png
image44.jpeg
image45.jpeg
image46.jpeg
image47.jpeg
image3.jpeg
image48.jpeg
image49.jpeg
image50.jpeg
image51.jpeg
image52.jpeg
image53.jpeg
image54.jpeg
image55.jpeg
image56.jpeg
image57.jpegimage4.jpeg
image58.jpeg
image59.jpeg
image60.jpeg
image61.jpeg
image62.jpeg
image63.png
image64.jpeg
image5.jpeg
image65.jpeg
image66.jpeg
image67.jpeg
image68.pnga 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, como podemos ver na imagem.
Encapsulamento.
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, visto que as funcionalidades da classe base podem ter sido usadas e testadas.
Polimorfismo
A palavra deriva do grego e 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 do reaproveitamento de código promovido pela herança, permitindo que se aproveite alguns métodos e se altere (redefina) outros. Dessa forma, um método com mesmo nome em classes distintas pode ter diferentes comportamentos.
Exemplificando herança e polimorfismo
Observe o exemplo da imagem a seguir, na qual identificamos uma herança: Pagamento em Dinheiro, Pagamento em CC (cartão de crédito) e Pagamento em Cheque herdam da classe Pagamento, o atributo Valor e o método Pagar.
Herança e polimorfismo.
Observe que, 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.
Atenção
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. Assim, podemos concluir que a orientação a objetos traz em si alguns benefícios. Veja!
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.
Atividade 2
Questão 1
O paradigma orientado a objetos é um modelo de programação que organiza o software em objetos, que são instâncias de classes. Qual das seguintes características do paradigma orientado a objetos permite a reutilização de código entre aplicações?
A
Encapsulamento.
B
Abstração.
C
Polimorfismo.
D
Modularidade.
E
Herança.
Responder
Parabéns! A alternativa E está correta.
A herança é um princípio fundamental do paradigma orientado a objetos que permite a reutilização de código. Por meio da herança, uma nova classe pode herdar atributos e métodos de uma classe existente, facilitando a reutilização e a extensibilidade do código sem a necessidade de reescrevê-lo. Esse mecanismo não só economiza tempo e recursos no desenvolvimento de software, mas também promove a consistência e a confiabilidade ao permitir que novas funcionalidades sejam construídas sobre bases já testadas e comprovadas.
Análise de sistemas orientada a objetos
É fundamental no desenvolvimento de software moderno, oferecendo uma abordagem coerente e eficiente para capturar os requisitos do sistema e modelar soluções complexas. Ao entender seus conceitos e práticas, desenvolvedores e analistas podem criar sistemas mais robustos, flexíveis e reutilizáveis, que se alinham melhor às necessidades dos usuários finais. Esse conhecimento teórico não apenas melhora a qualidade do design do sistema, mas também facilita a comunicação dentro das equipes de desenvolvimento, estabelecendo uma linguagem comum que apoia uma implementação eficaz e uma manutenção simplificada ao longo do ciclo de vida do software.
Análise de sistemas
Antes de entrarmos no universo da análise sob a perspectiva da orientação a objetos, vamos fazer breves comentários sobre a atividade de análise no contexto do desenvolvimento de software. De maneira simples, a atividade de análise busca identificar o que os usuários e outros interessados (stakeholders) necessitam que o sistema realize. A análise de sistemas envolve investigar os problemas e requisitos (necessidades dos usuários) de um contexto específico, com o objetivo de construir 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.
Além desses, outros aspectos podem ser adicionados, dependendo da especificidade do sistema em construção.
A atividade de análise, por ser muito abrangente, costuma ser dividida da seguinte forma. Acompanhe!
Levantamento de requisitos
Também chamado de investigação dos requisitos, consiste em entender a realidade, identificar a abrangência do sistema e capturar as necessidades dos usuários. Isso é feito usando técnicas específicas para o levantamento de requisitos.
Análise dos requisitos
Consiste no estudo e compreensão das necessidades, bem como do funcionamento e da dinâmica da organização. O objetivo é construir modelos que representem o sistema a ser desenvolvido em sua concepção lógica, sem considerar os recursos tecnológicos que o sustentarão.
A atividade de análise não considera 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.
Atenção
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 da atividade de análise é construir a melhor solução, que possa 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.
Na orientação a objetos, o foco está na identificação, compreensão e definição dos objetos de software e em como eles irão colaborar para atender satisfatoriamente aos requisitos dos usuários.
Levantamento de requisitos
Requisito pode ser definido como uma condição ou capacidade que deve ser alcançada por um sistema para satisfazer uma necessidade.
Nessa fase, o objetivo é dialogar com as pessoas ligadas ao sistema (patrocinadores, gestores, usuários atuais e futuros, entre outros) para compreender suas necessidades e expectativas individuais. O foco principal está na compreensão do problema.
Atenção
As necessidades e preferências dos usuários são tecnicamente denominadas requisitos. Os desenvolvedores e outras partes interessadas se reúnem para identificar os requisitos do sistema, levando em conta o contexto específico e o domínio do problema ao qual o sistema se aplica.
Para que os desenvolvedores possam identificar as necessidades dos usuários do sistema, é usado um conjunto de técnicas de levantamento de dados, desde as tradicionais entrevistas, reuniões, observação do ambiente do usuário e questionários até técnicasmais sofisticadas como brainstorm.
O produto gerado por essa fase é o documento de requisitos, que contém todos os requisitos necessários ao sistema. Confira sua classificação!
Requisitos funcionais
Declaram as funcionalidades necessárias ao sistema.
Requisitos não funcionais
Apresentam algumas características associadas a uma, algumas ou todas as funcionalidades, e referem-se a aspectos de qualidade, confiabilidade, desempenho, portabilidade, segurança e usabilidade do sistema.
Para exemplificar melhor, considere um sistema financeiro que precise das seguintes funcionalidades:
· Cadastramento dos pagamentos
· Quitação dos pagamentos
· Cadastramento das receitas
· Quitação das receitas
· Emissão das faturas
Cada uma das cinco funcionalidades anteriores representa um requisito funcional do sistema. Imagine, então, que o sistema precise ser touch screen. Tal característica da funcionalidade Emissão das faturas é um requisito não funcional de usabilidade (relacionada com uma interface de qualidade). Outro requisito não funcional de segurança seria a necessidade de um backup diário da base de dados.
Programadora em conexão com usuário do sistema.
A correta identificação e seu registro 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. Esse documento 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.
No documento de requisitos estará definido, também, o escopo do sistema. Portanto, o principal objetivo da fase de levantamento de requisitos é compreender profundamente o sistema antes de iniciar sua construção.
Análise de requisitos
Nessa fase, os requisitos funcionais e não funcionais são traduzidos para os modelos que a equipe planeja utilizar.
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. Confira!
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
Nessa etapa, identificamos objetos importantes para o sistema, mesmo que não sejam óbvios para os analistas de domínio. Esses objetos são específicos da aplicação, como uma interface de cadastramento de pagamentos em um sistema financeiro. O objetivo é apenas identificar esses objetos, sem detalhar sua implementação, que será feita na fase de projeto.
Entenda melhor com o esquema a seguir.
Análise do domínio
Objetos do domínio (relacionado ao problema).
Análise da aplicação
Objetos da aplicação (relacionado a aspectos computacionais de alto nível).
Os principais diagramas UML utilizados nas fases de análise incluem os diagramas de casos de uso e de classes. Em alguns casos, também são úteis os diagramas de interação e de estados.
Curiosidade
Análise pode ser traduzida em ”faça a coisa certa”.
Atividade 3
Questão 1
Na fase de análise de um desenvolvimento de sistema orientado a objetos, são identificados e modelados os objetos do mundo real relevantes para o sistema, suas características e como eles interagem. Qual das seguintes afirmações descreve uma atividade da fase de análise em um desenvolvimento de sistema orientado a objetos?
A
Estabelecer os requisitos funcionais e não funcionais do sistema, identificando o que o sistema deve fazer.
B
Codificar e implementar as funcionalidades do sistema conforme especificado nos requisitos.
C
Testar o sistema para garantir que todos os requisitos identificados foram adequadamente implementados.
D
Decidir como o sistema funcionará para atender aos requisitos, definindo a arquitetura do sistema e os recursos computacionais necessários.
E
Treinar os usuários finais sobre como utilizar o sistema uma vez que esteja implementado e em funcionamento.
Responder
Parabéns! A alternativa A está correta.
Na análise de sistemas, os requisitos podem ser classificados em diferentes tipos. Os requisitos funcionais descrevem as funcionalidades específicas que o sistema deve executar, como processamento de dados ou interação com o usuário. Por outro lado, os requisitos não funcionais definem atributos do sistema, como desempenho, segurança e usabilidade. Compreender e documentar adequadamente esses diferentes tipos de requisitos é essencial para garantir que o sistema atenda às expectativas e necessidades dos usuários finais.
Projeto (desenho) de sistemas orientado a objetos
É essencial no desenvolvimento de software, pois estabelece a estrutura sobre a qual os sistemas são construídos. Com um sólido conhecimento teórico nessa área, é possível projetar sistemas mais eficientes, mantendo a coesão e minimizando o acoplamento entre os objetos. Isso não apenas facilita a implementação, como também a manutenção e a expansão futuras do sistema. Dominar os princípios do design orientado a objetos promove a criação de software de alta qualidade, otimizando recursos e maximizando a adaptabilidade às mudanças de requisitos, fundamentais em um ambiente tecnológico que evolui rapidamente.
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 o gerenciamento do banco de dados.
O projeto, consequentemente, é uma extensão da análise e resulta em uma descrição dos recursos computacionais e de como o sistema deve operar no cotidiano. Em algumas situações, podem existir restrições tecnológicas, como a necessidade de desenvolver na linguagem X devido à predominância dos sistemas da organização nessa linguagem (se ainda estiver em uso no mercado), ou usar o sistema gerenciador de banco de dados Y, devido à base corporativa da organização estar nele. Veja como a fase de projeto pode ser dividida!
Projeto da arquitetura
Ato de distribuir as classes de análise em subsistemas com seus componentes, bem como distribuir os componentes pelos recursos de hardware disponíveis. Entre os diagramas da UML, usamos aqui os diagramas de pacotes, componentes e implantação.
Projeto detalhado
Envolve atividades como modelagem das interações entre objetos, design da interface e do banco de dados, e considerações sobre aspectos computacionais avançados, como concorrência e distribuição de processamento e dados. Também inclui o design de algoritmos, se necessário, e a criação de diversos diagramas UML, como diagramas de interação, atividades e detalhamento dos diagramas de classes e de estados.
Portanto, podemos concluir que o projeto pode ser traduzido em “faça certo a coisa”.
Atividade 4
Questão 1
Sobre as atividades de análise e projeto no contexto da orientação a objetos, examine as assertivas a seguir.
 
I - Na fase de análise de requisitos é feita a transposição dos registros dos requisitos funcionais e nāo funcionais para os respectivos modelos a serem usados.
 
II - Em um sistema acadêmico escolar, um requisito funcional é "o sistema deve emitir o boletim bimestral do aluno”.
 
III - Um requisito não funcional deum sistema de autoatendimento em estacionamentos é "o sistema deve ser touch screen”.
 
IV - No projeto detalhado, é feita a distribuição das classes de análise em subsistemas com seus componentes.
 
Com base nas assertivas, assinale a alternativa correta:
A
Estão corretas apenas as assertivas I e III.
B
Estão corretas apenas as assertivas I, II e III.
C
Estão corretas apenas as assertivas l e ll.
D
Está correta apenas a assertiva I.
E
Estão corretas apenes as assertivas II e IV.
Responder
Parabéns! A alternativa B está correta.
Estão corretas as afirmativas: I, já que antes da análise dos requisitos temos a listagem de todos, porém, alguns têm relação e podem ser agrupados em uma funcionalidade, por exemplo; II, pois essa é uma funcionalidade do sistema; III, já que essa é uma necessidade que vai guiar toda a interface desse sistema. A afirmativa IV está incorreta, pois é no projeto de arquitetura que essa distribuição das classes é realizada.
Desenvolvimento de sistemas em camadas
Compreender o desenvolvimento em camadas é essencial para estudantes de engenharia de software, fornecendo uma compreensão sobre a organização modular dos sistemas de software. Isso facilita a manutenção, escalabilidade e colaboração entre equipes. Além disso, ajuda na compreensão de padrões de projeto e arquiteturas modernas, preparando você para desafios no desenvolvimento de sistemas robustos.
Vamos começar discutindo a arquitetura de projeto de software em camadas de maneira geral, sem nos prender a um modelo específico. O objetivo principal é dividir o código em camadas para simplificar sua manutenção, reduzindo sua complexidade. As camadas ajudam a separar responsabilidades e gerenciar dependências.
Programador analisando dados.
No início da computação, os sistemas eram monolíticos, ou seja, todo o código ficava confinado em uma ú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 (Sistemas de Gestão de Base de Dados). 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.
Inicialmente, a rede cliente-servidor dividiu o software em duas camadas: a camada de código que roda no cliente (camada de interface com usuário) e a camada servidor (camadas de lógica do negócio e persistência dos dados). Posteriormente, 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.
Com base no que acabamos de estudar, podemos concluir que 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.
Aqui estão as vantagens e desvantagens do desenvolvimento de software em camadas. Confira!
Vantagens
Confira!
 
· Torna o código mais organizado e legível.
· Permite o desenvolvimento, o teste e a manutenção das camadas isoladamente.
· Permite melhor reúso 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
Confira!
 
· Aumenta o número de classes do sistema.
· A adição de camadas torna o sistema mais complexo.
· Potencialmente, reduz o desempenho do software.
Um modelo comumente utilizado nos últimos anos é o de três camadas, veja!
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.
Atividade 5
Questão 1
No desenvolvimento de sistemas de software em camadas, a aplicação é dividida em camadas distintas, cada uma responsável por uma função específica. Qual das seguintes afirmações melhor descreve uma característica importante do desenvolvimento de sistemas em camadas?
A
Torna o código mais desorganizado e fácil de entender.
B
Permite o desenvolvimento, o teste, mas dificulta a manutenção das camadas isoladamente.
C
Diminui a flexibilidade do sistema para substituir tecnologias.
D
Facilita o reúso do código ou dos objetos.
E
Aumenta a complexidade do sistema e reduz o desempenho do software.
Responder
Parabéns! A alternativa D está correta.
O desenvolvimento em camadas torna mais fácil o processo de reúso do código ou dos objetos, pois permite que cada camada seja desenvolvida, testada e mantida independentemente das outras. Isso possibilita uma melhor organização do código e uma maior facilidade na implementação de mudanças ou substituição de tecnologias em determinada camada, sem afetar as demais partes do sistema.
O que é UML, afinal?
É uma linguagem visual padronizada usada para modelar sistemas de software, fornecendo uma representação gráfica e detalhada das estruturas, dos comportamentos e das interações de um sistema. Dominar os conceitos teóricos da UML capacita você a comunicar efetivamente suas ideias de design, colaborar de forma mais eficaz com suas equipes de desenvolvimento, entender modelos existentes e interpretar documentação técnica. Além disso, o conhecimento da UML é altamente valorizado na indústria de TI, oferecendo uma vantagem competitiva no mercado de trabalho.
A linguagem unificada de modelagem (UML) oferece um conjunto de diagramas, sob diferentes visões, que permitem a modelagem de sistemas orientada a objetos, independentemente de tecnologia e de processos e metodologias de desenvolvimento de sistemas, cabendo seu uso em qualquer contexto de desenvolvimento orientado a objetos.
No final da década de 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 realidades. 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 adotada pela OMG (Object Management Group) em 1997, consolidando-se a partir da fusão dos três métodos mencionados, tornando-se 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 é uma linguagem padrão para construção de projetos de sistemas, voltadapara 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 que tem o seguinte objetivo. Vejamos!
Visualização
A modelagem gráfica facilita a compreensão do sistema e das decisões tomadas durante as fases de análise e projeto, além de melhorar significativamente a comunicação entre os membros da equipe, permitindo que suas interpretações sejam feitas 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, como Java e C++. No entanto, para isso, é necessário utilizar uma ferramenta CASE (Computer-Aided Software Engineering) integrada que seja capaz de gerar código-fonte específico para essas linguagens a partir dos diagramas UML.
A UML é uma linguagem de modelagem padronizada em que podemos observar o seguinte:
· É independente de tecnologia, adequando-se a todo método, metodologia ou processo de desenvolvimento.
 
· Não diz quais diagramas usar e nem em que ordem, pois a metodologia de desenvolvimento ditará essa ordem.
 
· Disponibiliza diagramas sob diferentes visões ou perspectivas.
Para Fowler (2005), a UML se tornou não somente a notação gráfica dominante no mundo orientado a objetos, como também uma técnica popular nos círculos não orientado a objetos.
Atividade 1
Questão 1
A linguagem unificada de modelagem (UML) é uma linguagem visual padronizada para representar modelos de sistemas de software. Ela oferece uma variedade de diagramas, como diagramas de classes, de sequência e de atividades. Qual é o principal objetivo da UML?
A
Padronizar as linguagens de programação orientadas a objeto.
B
Determinar a ordem dos diagramas a serem utilizados no desenvolvimento de sistemas.
C
Especificar os métodos de desenvolvimento de sistemas.
D
Disponibilizar diagramas sob diferentes visões ou perspectivas.
E
Ser independente de tecnologia, adequando-se a todo método, metodologia ou processo de desenvolvimento.
Responder
Parabéns! A alternativa E está correta.
A UML é uma linguagem de modelagem padronizada que não determina a ordem dos diagramas a serem utilizados nem os métodos de desenvolvimento de sistemas. Ela tem como principal objetivo disponibilizar diagramas sob diferentes visões ou perspectivas e ser independente de tecnologia, adaptando-se a qualquer método, metodologia ou processo de desenvolvimento.
Visões da UML
A UML oferece uma variedade de diagramas que representam perspectivas específicas de um sistema, como estrutura, comportamento e interação. Compreender essas visões permite que você analise e comunique efetivamente os requisitos, a arquitetura e o design de um sistema, promovendo uma modelagem mais precisa e ampla. Além disso, o conhecimento teórico sobre as visões da UML permite a colaboração de forma mais eficiente em equipes de desenvolvimento e a tomada de decisões fundamentadas durante todo o ciclo de vida do software.
Assim como vimos nos exemplos do empreendimento imobiliário, as plantas das unidades, a planta elétrica, a planta hidráulica, entre 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 em 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.
Visão de casos de uso
Oferece uma visão externa do sistema, do ponto de vista do usuário, descrevendo seu comportamento por meio de interações entre usuário e sistema. É uma perspectiva inicial em um projeto; a visão de caso de uso é estabelecida no estágio inicial do desenvolvimento e orienta todas as outras visões, ao capturar os requisitos funcionais que definem o 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)
Envolve o gerenciamento das versões do sistema, ou seja, suas implementações utilizáveis pelos usuários. Abrange 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, 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.
Atividade 2
Questão 1
Associe as duas colunas relacionando as visões da UML (coluna A) com sua respectiva finalidade ou característica.
	Coluna A – visão UML
	Coluna B – finalidade ou característica
	1) Casos de uso
	a) Enfatiza os pacotes, as classes, as interfaces, os subsistemas (pacotes) e as colaborações
	2) Lógica ou projeto
	b) Permite olhar o sistema sob o ponto de vista externo, descrevendo seu comportamento por interações usuário-sistema
	3) Processo
	c) Enfatiza a distribuição física do sistema em suas partes e as respectivas conexões entre elas
	4) Implementação
	d) Enfatiza aspectos físicos mais peculiares, como concorrência, sincronismo entre sistemas e desempenho
	5) Implantação
	e) Compreendem os componentes, os subsistemas e os arquivos que compõem fisicamente o sistema
Tabela: coluna A (visão UML) e coluna B (finalidade ou característica).
Alberto Tavares da Silva.
Com base nas assertivas, assinale a alternativa que associa corretamente as duas colunas:
A
1-a, 2-b, 3-d, 4-e, 5-c
B
1-b, 2-a, 3-d, 4-e, 5-c
C
1-c, 2-b, 3-e, 4-d, 5-a
D
1-e, 2-b, 3-c, 4-d,5-a
E
1-a, 2-b, 3-e, 4-d, 5-c
Responder
Parabéns! A alternativa B está correta.
Vamos analisar cada assertiva: 
 
1. Visão de casos de uso: visão externa, mostra os usuários e as funcionalidades com as quais interage; portanto, letra B (permite olhar do sistema sob o ponto de vista externo, descrevendo seu comportamento por interações usuário-sistema). 
 
2. Visão lógica: permite visualizar o sistema sob o ponto de vista de sua estrutura interna e seu comportamento; portanto, letra A (enfatiza os pacotes, as classes, as interfaces, os subsistemas − pacotes − e as colaborações). 
 
3. Visão de processo: concentra-se na divisão do sistema em processos e processadores; portanto, Letra D (enfatiza aspectos físicos mais peculiares, como concorrência, sincronismo entre sistemas e desempenho). 
 
4. Visão de implementação: retrata a visão física do sistema em seus elementos; portanto,letra E (compreendem os componentes, subsistemas e arquivos que compõem fisicamente o sistema). 
 
5. Visão de implantação: concentra-se em mostrar como o sistema vai ser distribuído entre os nós (elementos computacionais); portanto, letra C (enfatiza a distribuição física do sistema em suas partes e as respectivas conexões entre elas).
UML e integração com processos de desenvolvimento
Como uma linguagem padronizada de modelagem, a UML pode ser adaptada a uma variedade de metodologias e processos de desenvolvimento, como Ágil, Cascata, Iterativo e RUP. O conhecimento teórico nesse aspecto torna você apto a selecionar e aplicar adequadamente os diagramas UML em cada fase do ciclo de vida do software, garantindo uma comunicação eficaz entre equipes e uma implementação bem-sucedida dos sistemas.
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.
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. Conheça alguns deles!
Cascata
Com ou sem retroalimentação, as fases ocorrem sequencialmente, iniciando a próxima quando a anterior é concluída. A desvantagem é que, sem retroalimentação, não há retorno à fase anterior. Por exemplo, se novos requisitos são identificados durante a fase de projeto, eles não podem ser considerados porque a fase de análise já congelou os requisitos identificados. Se a retroalimentação é permitida, esse problema pode ser minimizado, mas não totalmente resolvido. Um grande problema é que o usuário interage com a equipe de desenvolvimento apenas no início e no final do processo, quando o sistema é entregue.
Iterativo
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
Compartilha um conjunto de valores e princípios definidos pelo Manifesto Ágil. O foco está na capacidade de adaptação contínua e no desenvolvimento de código. A modelagem existe, mas é menos abrangente, com ênfase na comunicação entre usuário e equipe de desenvolvimento. Os processos ágeis tendem a ser menos formais. Alguns dos métodos mais utilizados incluem Extreme Programming (XP), Scrum e FDD (Feature Driven Development).
RUP (Rational Unified Process)
É 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 e, assim como os demais processos, é independente da UML.
Atividade 3
Questão 1
O processo de desenvolvimento de software é uma sequência de atividades planejadas e estruturadas para criar um produto de software. Inclui etapas como análise, design, implementação, teste e manutenção, visando atender aos requisitos do cliente. Qual dos seguintes processos de desenvolvimento é caracterizado por permitir modificações sempre que necessário e enfatizar o desenvolvimento de código?
A
Cascata.
B
Iterativo.
C
Ágil
D
RUP (Rational Unified Process).
E
Estruturado.
Responder
Parabéns! A alternativa C está correta.
O processo de desenvolvimento ágil compartilha um conjunto de valores e princípios definidos pelo Manifesto Ágil. Ele permite modificações sempre que necessário e enfatiza o desenvolvimento de código, priorizando a comunicação com o usuário e a equipe de desenvolvimento.
Visão geral dos diagramas UML
Esses diagramas fornecem uma linguagem visual unificada para modelar sistemas complexos, permitindo uma comunicação clara e eficiente entre desenvolvedores, analistas e stakeholders. Compreender a variedade de diagramas UML disponíveis, e saber quando e como aplicá-los em diferentes estágios do desenvolvimento de software, é fundamental para garantir precisão, consistência e compreensão do sistema em desenvolvimento. Portanto, o conhecimento teórico sobre os diagramas UML oferece uma base sólida para análise, projeto e documentação desses sistemas.
Aqui vamos analisar a versão mais recente da UML, a 2.5.1, que traz 14 diagramas com as divisões a seguir.
Diagramas estruturais
São estruturas estáticas necessárias ao sistema, como os pacotes, as classes, os objetos, os componentes e a estrutura de nós (estruturas computacionais). São essenciais para o funcionamento do sistema. Também são chamadas de estruturas estáticas.
Diagramas comportamentais
Evidenciam o comportamento (funcionamento) de parte de um sistema ou processo de negócio relacionado ao sistema, segundo determinada perspectiva. Estão relacionados às funcionalidades do sistema, aos estados de um objeto em seu ciclo de vida, às interações entre os objetos, entre outros aspectos. Também são chamados de diagramas dinâmicos.
Observe esses diagramas!
Diagramas da UML.
Fique agora com uma breve descrição de cada diagrama da UML. Vamos lá!
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 à 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, por exemplo, para evidenciar as mudanças no estado de um objeto ao longo do tempo.
Atividade 4
Questão 1
Qual diagrama da UML é usado para descrever a estrutura e as conexões entre os componentes de um sistema, sendo uma parte importante da modelagem de sistemas complexos e podendo ser usado em conjunto com outros diagramas para fornecer uma visão abrangente do sistema?
A
Diagrama de perfil.
B
Diagrama de classes.
C
Diagrama de estruturas compostas.
D
Diagrama