Modelagem de Sistemas com UML

Prévia do material em texto

2
MODELAGEM DE SISTEMAS COM UML
AULA 1 – CONCEITOS BÁSICOS DE MODELAGEM DE SISTEMAS
Descrição
O desenvolvimento de sistemas orientado a objetos e a Linguagem Unificada de Modelagem (UML) para criação de modelos, sob a forma de diagramas, com representação dos requisitos e das soluções de análise e projeto de sistemas de qualquer porte e finalidade.
Propósito
Compreender a UML no contexto de desenvolvimento de sistemas orientado a objetos (ou não) como uma ferramenta de construção de diagramas padronizados para ajudar a equipe de desenvolvimento a entender o que o sistema deve fazer, num primeiro momento, e como o sistema deve fazer, num momento seguinte. Disponibilizar diagramas que permitam enxergar o sistema sob cinco diferentes perspectivas e usá-los da forma que convier, em consonância com qualquer processo de desenvolvimento de sistemas.
Preparação
Antes de iniciar este conteúdo, é indicado ter instalado em seu computador um programa que 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 ferramentas livres para modelagem de sistemas em UML podem ser encontradas em buscas na internet.
Objetivos
· Módulo 1: Reconhecer a importância dos modelos na exposição de requisitos e soluções sistêmicas
· Módulo 2: Distinguir os conceitos e pilares de análise e projeto orientados a objetos
· Módulo 3: Descrever as visões, a síntese geral e os diagramas da UML
Introdução
Aprenderemos os conceitos básicos de modelagem de sistemas para compreender a realidade do negócio inerente ao sistema e expor as soluções para atender às necessidades reais de seus usuários. Iniciaremos pelo conceito de modelo e mostraremos sua aplicabilidade no contexto de desenvolvimento de sistemas. Vamos compreender que existem diferentes modelos que devem ser aplicados, sob a forma de templates e diagramas, nas diferentes fases do processo de desenvolvimento do sistema.
Focaremos no 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, sob diferentes perspectivas, para abarcar as diversas necessidades de modelagem para exposição dos requisitos, das soluções de análise e de projeto do sistema em construção. A UML é uma linguagem de modelagem independente de tecnologia, que pode ser aplicada em diferentes processos e metodologias de desenvolvimento de sistemas orientados a objetos.
Módulo 1
Reconhecer a importância dos modelos na exposição de requisitos e soluções sistêmicas
Conceitos
Neste módulo, veremos por que são usados modelos, sob a forma de diagramas, durante o processo de desenvolvimento de sistemas computacionais para expor as necessidades dos usuários e as ideias dos desenvolvedores para a construção do novo sistema. Assim, vamos conceituar e compreender a relevância da modelagem de sistemas.
O que são modelos e para que eles servem
Exemplo: Uma família decide adquirir um imóvel na planta para moradia. Ela vai, então, a um lançamento imobiliário a convite de um corretor conhecido. Chegando lá, deparam-se com o terreno vazio e um stand de vendas. Imediatamente, vem a dúvida: como escolher o bloco e o apartamento para que não sejam devassados, considerando a vizinhança?
O corretor então 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 é uma representação, em miniatura, do condomínio real. É um modelo do empreendimento real. Ou seja, o empreendimento real será construído à imagem e semelhança da maquete construída.
A maquete é, portanto, um modelo (a base) a partir do qual o empreendimento real será construído. É uma simplificação da realidade, de forma que decisões prévias possam ser tomadas antes de sua construção, sob a perspectiva da construtora, e de sua aquisição, sob a perspectiva do comprador.
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.
Podemos estabelecer, então, a primeira finalidade de um modelo: antecipar a existência de uma realidade para avaliar sua estrutura e seu comportamento.
Voltando ao exemplo do imóvel:
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 as vizinhanças e respectivas distâncias entre eles.
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 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. A imagem a seguir mostra a planta de uma das unidades:
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.
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.
Resumindo
Modelo: representação abstrata e simplificada da realidade. Uma realidade pode demandar diferentes modelos, dependendo da perspectiva com que precise ser observada.
Finalidade principal: antecipar a existência de uma realidade de forma a avaliar sua estrutura e comportamento.
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 no que é relevante.
Dentre os benefícios que podemos citar para o uso de modelos em desenvolvimento de sistemas computacionais, além de tentar prever o comportamento do sistema e gerenciar sua complexidade, destacam-se:
	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
	Depois de pronto, sejaainda na fase de construção ou de manutenção, os sistemas carecem de ajustes e melhorias. A análise dessas melhorias tende a ser mais efetiva quando elaborada sobre os modelos construídos, aumentando a assertividade e diminuindo seus custos. Daí a relevância e a necessidade de manter os modelos sempre atualizados.
	Documentação do sistema
	Os modelos servem de consulta e orientação a toda 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.
	Delimitar o 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.
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).
Exemplo: Um sistema armazena e manipula dados através de funcionalidades e possui determinados controles. Poderíamos pensar então em três perspectivas e, dessa forma, construir modelos que representem os dados, as funcionalidades e os controles, cada um focando uma perspectiva diferente.
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. Outra forma de abordar os sistemas computacionais por meio de visões seria:
	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.
	Interação
	Modela-se as interações de seus componentes ou ainda do sistema e seu ambiente externo.
A construção dos diferentes modelos para um sistema compreende o que denominamos de Modelagem de Sistemas, onde:
· Os modelos 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.
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.
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 (vide imagem a seguir), quando o nível de abstração é alto e pouco se conhece da realidade.
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 na medida em 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.
Realidade X Sistema
1. Num primeiro momento, precisamos compreender com muita clareza as necessidades das pessoas que serão usuárias do sistema, o que elas precisam que o sistema faça para que possam cumprir suas funções.
2. Esse entendimento passa, também, pela necessidade da confirmação dessa compreensão pelas pessoas que estão construindo o sistema (os profissionais especializados).
Mas como entender e confirmar a compreensão numa linguagem ambígua como a nossa, tanto a falada como a escrita?
Se construirmos o sistema diretamente na linguagem de programação, a partir de um suposto entendimento da realidade, certamente teremos problemas de interpretação inadequada, e o sistema tende a não atender às necessidades de seus usuários, sendo então abandonado. Para representar adequadamente a realidade e entender o que se passa no contexto do sistema a ser construído, precisamos traduzir a realidade em modelos.
Fases comuns e mais relevantes do processo de desenvolvimento
Dentro desse raciocínio, os modelos nos ajudam a entender a realidade e discutir essa compreensão, reduzindo a complexidade e o nível de abstração.
Os modelos são, portanto, uma representação simplificada da realidade, representando os elementos de interesse naquele momento, permitindo abstrair o que não interessa e concentrar naquilo que de fato é relevante para o desenvolvimento do sistema.
Desde os anos 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. Objetivando um melhor gerenciamento da complexidade, os processos e as metodologias de desenvolvimento de sistemas costumam ser divididos em fases. Cada processo ou metodologia cria sua própria divisão, mas, de maneira geral, podemos citar que (haverá exceção, logicamente) compreendem as fases de:
	Identificação dos requisitos
	Requisitos podem ser entendidos como as necessidades que os usuários têm e que devem estar contidos nas funcionalidades e propriedades do sistema a ser construído.
	Análise
	Com base nos requisitos, compreende-se o que o sistema deve fazer em prol de seus usuários.
	Projeto
	Compreende a adequação dos requisitos a como eles serão implementados, usando a tecnologia adequada para tal, definindo sua arquitetura e seus componentes. Define-se ainda toda a infraestrutura do ambiente computacional que será usada na construção do sistema, como: redes de computadores, banco de dados, linguagem de programação, dentre outros elementos.
	Implementação
	Diz respeito à identificação dos programas necessários e sua codificação na linguagem de programação selecionada na fase de projeto, bem como o banco de dados que será usado.
Modelos como elementos de comunicação
Os modelos atuam em mão dupla enquanto elementos de comunicação no processo de desenvolvimento de sistemas, ajudando:
1. No entendimento e na validação dos modelos junto aos usuários; e
2. No entendimento do sistema por membros da equipe de desenvolvimento.
Entendimento e validação dos modelos junto aos usuários
A partir dos modelos, compreendemos e nos certificarmos do correto entendimento da realidade junto aos usuários, conforme ilustrado a seguir (Momento 1, Momento 2 e Momento 3):
	
Equipe levantando dados junto aos 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 que os usuários têm, visando a que sejam implementadas 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 se faz 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 junto aos 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ímosrepresentam 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 junto aos usuários, até que estejam adequados. Esse momento acontece nas fases de requisitos, análise e projeto.
Entendimento do sistema por membros da equipe de desenvolvimento
Outra finalidade dos modelos no desenvolvimento de sistemas é orientar membros da equipe quanto a 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 seria um projetista de interface, que precisa conhecer o funcionamento de determinado recurso para criar a interface necessária, então ele consulta o modelo que exibe a comunicação do usuário com o sistema para a referida funcionalidade. Esse momento acontece em todas as fases do projeto, pois sempre haverá desenvolvedores recebendo tarefas e consultando os respectivos modelos pertinentes. A imagem a seguir ilustra a consulta de diferentes pessoas da equipe aos modelos desenvolvidos.
Módulo 2
Distinguir os conceitos e pilares de análise e projeto orientados a objetos
Conceitos
Neste módulo, compreenderemos 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.
Paradigma Orientado 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 reuso 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 a esses problemas, permitindo − mediante propriedades como abstração, encapsulamento, herança e polimorfismo − maior organização, reaproveitamento e extensibilidade de código e, consequentemente, programas mais fáceis de serem escritos e mantidos.
O principal foco do paradigma orientado a objetos é permitir o desenvolvimento de sistemas de forma mais rápida e confiável.
Um dos criadores do paradigma orientado a objetos, Alan Kay, imaginou um sistema como um conjunto de agentes autônomos, os objetos, que interagem entre si. Ele definiu os princípios centrais da orientação a objetos:
	
	Qualquer coisa do mundo real é um objeto
	
	Objetos realizam tarefas requisitando serviços a outros objetos
	
	Os objetos similares são agrupados em classes e cada objeto pertence a uma classe
	
	A classe determina o comportamento possível a um objeto
	
	Classes são organizadas em hierarquias
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 software orientado a objetos consiste, portanto, em objetos colaborando para realizar as funcionalidades desse sistema. É graças à cooperação entre os objetos que a computação do sistema se desenvolve.
(BEZERRA, 2015)
Atenção: Observação: Ao longo do texto, abreviaremos o termo "orientação a objetos" como O.O.
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. Neste tópico, adentraremos nesses conceitos fundamentais da orientação a objetos.
Objetos e classes
Um objeto pode referenciar qualquer coisa do mundo real: 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.
Quando analisamos os objetos pertinentes a um contexto, não estamos preocupados com um objeto específico como, por exemplo, 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 (agrupa) 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”. Usando o princípio da abstração (que detalharemos mais adiante), temos que uma classe agrupa objetos com as mesmas características ou propriedades, que são seus dados (atributos) e seus procedimentos (métodos) que implementam os serviços que essa classe vai prestar.
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 métodos. Por exemplo, a classe ALUNO encapsula um conjunto de dados que identifique os alunos − matrícula, nome, endereço (rua, número, complemento, estado e CEP), CPF e Identidade − e um conjunto de métodos: Incluir Aluno, Matricular Aluno, Cancelar Matrícula, dentre outros.
Resumindo
Classe: abstração das características de um grupo de coisas do mundo real.
Objeto: um elemento específico de uma classe ou uma instância de uma classe.
A seguir, temos a representação de uma classe em três compartimentos: o nome da classe (ALUNO), seus atributos (Matrícula... Identidade) e métodos (Incluir Aluno... Cancelar Matrícula).
A seguir, temos 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. Escolha um dos conceitos a seguir.
	Operação
	Operação é o nome dado a cada ação (função) que o objeto sabe realizar. Mas um objeto não realiza nenhuma ação sem uma motivação, sem um estímulo.
	Mensagem
	Chamamos esse estímulo de mensagem, que chega a um objeto e solicita que ele realize uma de suas operações. Uma operação, por sua vez, pode ser implementada por meio de pelo menos um método.
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
	Já sabemos que um objeto contém atributos, que são dados necessários para prestar os serviços que cabem a esse objeto. Por definição, chama-se estado do objeto o conjunto de valores de seus atributos em dado momento. Uma mensagem enviada a um objeto pode (ou não) alterar o seu estado, na medida em que pode alterar um ou mais valores de seus atributos.
Objeto
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 desseobjeto 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.
Os Pilares da Orientação a Objetos
Dentre as principais características do paradigma orientado a objeto (O.O.), 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, como pode ser visualizado na figura seguinte. O encapsulamento é uma técnica para minimizar a interdependência entre as classes, pois apenas os métodos da respectiva classe podem alterar seus dados (atributos), facilitando a identificação de erros e a alteração dos programas. Em outras palavras, garante que apenas os métodos da própria classe possam alterar o estado de um objeto.
	Herança
	Mecanismo para derivar novas classes a partir da definição de classes existentes, com base em um processo de refinamento. Uma classe derivada ou descendente herda os dados (atributos) e o comportamento (métodos) da classe base ou ancestral ou ascendente. A implementação da herança garante a reutilização de código, que, além de economizar tempo e dinheiro, propicia mais segurança ao processo de desenvolvimento, posto que as funcionalidades da classe base podem ter sido usadas e testadas.
	Polimorfismo
	A palavra polimorfismo 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
Acompanhe 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.
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.
As hierarquias de classes (herança) são estruturas que permitem o seu reaproveitamento entre aplicações que, se bem projetadas, podem ser reutilizadas em vários sistemas, otimizando tempo e dinheiro.
Além disso, tais estruturas podem ser estendidas (usando o princípio do polimorfismo) sem corromper o que já existe. Dessa forma, pode-se concluir que a orientação a objetos traz em si os seguintes benefícios:
	Reusabilidade
	O uso de componentes já escritos pode ser a base para outros softwares (através da herança).
	Extensibilidade
	Novos componentes podem ser desenvolvidos a partir de outros, já desenvolvidos, sem afetar o comportamento do componente de origem (mediante o princípio do polimorfismo) e permitindo que esse comportamento seja alterado, estendido para um novo contexto.
Análise de Sistemas Orientada a Objetos
Antes de adentramos no universo da análise sob o enfoque do paradigma orientado a objetos, vamos tecer rápidos comentários acerca do que seja a atividade de análise no contexto do desenvolvimento de software.
De forma simples, pode-se dizer que a atividade de análise visa identificar o que os usuários e os demais interessados (que juntos formam os stakeholders) precisam que o sistema faça.
Análise de sistemas implica numa investigação dos problemas e dos requisitos (necessidades dos usuários) de um contexto, em particular, visando a construção de um sistema automatizado.
Atenção
O foco da atividade de análise é estudar e entender o funcionamento de um sistema sob pelo menos alguns pontos de vista: da estrutura que sustenta o sistema (os dados); dos procedimentos e processos intervenientes no sistema; da dinâmica de funcionamento do fluxo de informações e dados, dentre outros aspectos que podem ser adicionados, dependendo da especificidade do sistema em construção.
A atividade de análise, por ser muito abrangente, costuma ser dividida em: levantamento de requisitos (investigação dos requisitos) e análise dos requisitos.
	Inicialmente, entendemos a realidade, identificamos a abrangência do sistema e capturamos as necessidades dos usuários desse sistema, usando técnicas específicas (levantamento de requisitos).
	Posteriormente, analisamos e entendemos essas necessidades e o funcionamento e a dinâmica da organização (análise dos requisitos), visando à construção de modelos que representem o sistema a ser desenvolvido, em sua concepção lógica, sem preocupação com qualquer recurso tecnológico que venha sustentar o seu funcionamento.
A atividade de análise não leva em consideração nenhum recurso tecnológico que possa ser utilizado pelo sistema em construção. A ideia é construir uma estratégia de solução sem considerar como (com que tecnologia) essa estratégia será construída.
	A preocupação da atividade de análise é identificar: O QUE o sistema deve fazer para atender às necessidades de seus usuários.
A sua finalidade é 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.
No contexto da orientação a objetos, foca-se na identificação, no entendimento e na definição dos objetos de software e em como eles irão colaborar para que os requisitos dos usuários sejam respondidos satisfatoriamente.
Levantamento de requisitos
Nesta fase, o foco é conversar com as pessoas envolvidas com o sistema (patrocinadores, gestores, usuários atuais e futuros e demais envolvidos) e compreender as necessidades e desejos de cada um. O foco, portanto, é na compreensão do problema.
As necessidades e os desejos que os usuários têm são, tecnicamente, chamados de requisitos. Os desenvolvedores e as demais pessoas envolvidas se reúnem, visando à identificação dos requisitos do sistema, considerando o contexto específico e o domínio do problema (área do conhecimento ou atividade específica) a que o sistema se aplica.
Requisitos: Requisito pode ser definido como sendo uma condição ou capacidade que deve ser alcançada por um sistema para satisfazer uma necessidade.
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çãodo ambiente do usuário e questionários até técnicas mais sofisticadas como brainstorm. O produto gerado por essa fase é o documento de requisitos, que contém todos os requisitos necessários ao sistema, classificados em :
	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 dizem respeito a aspectos de qualidade, confiabilidade, desempenho, portabilidade, segurança e usabilidade do sistema.
Exemplo
Imagine um sistema financeiro, no qual haja a necessidade das seguintes funcionalidades: Cadastramento dos pagamentos, Quitação dos pagamentos, Cadastramento das receitas, Quitação das receitas e 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.
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.
Dica
O documento de requisitos seguirá como base da comunicação entre os desenvolvedores e os usuários, devendo ser validado por estes, uma vez que servirá de norte para as atividades subsequentes do desenvolvimento do sistema. É, portanto, fundamental a participação ativa e efetiva dos usuários do sistema na fase de levantamento de requisitos. No documento de requisitos estará definido, também, o escopo do sistema.
	O principal ponto da fase de LEVANTAMENTO DE REQUISITOS é compreender profundamente no sistema antes de iniciar a sua construção.
Análise de requisitos
A fase de análise de requisitos é a transposição dos registros dos requisitos funcionais e não funcionais para os modelos que a equipe pretende usar. A principal atividade é desdobrar os requisitos funcionais em funcionalidades do sistema, uma vez que não necessariamente há uma relação de 1 para 1, ou seja, um requisito funcional pode demandar mais de uma funcionalidade e uma funcionalidade pode agregar mais de um requisito funcional. A análise de requisitos tem, minimamente, duas perspectivas ou visões:
	Análise do Domínio (ou do Negócio)
	Visa a identificar ou modelar os objetos que serão usados na aplicação. Por exemplo, Pagamento é um objeto no contexto do sistema financeiro, usado para exemplificar os requisitos funcionais. Logo, Pagamento é um objeto do domínio, assim como Recebimento e Fatura.
	Análise da Aplicação
	Em geral, sucede a análise do domínio. Nela, são identificados os objetos de análise que não fazem sentido para os analistas de domínio, mas que são fundamentais para atender às funcionalidades necessárias ao sistema, a aplicação em si (daí seu nome). Por exemplo, uma interface de cadastramento de pagamentos é um objeto de aplicação do sistema de controle financeiro. Nesse momento, o foco é apenas a identificação desse objeto, sem especificar sua implementação, o que será detalhado na fase de Projeto (descrita adiante).
	Análise do domínio
	≠
	Análise da aplicação
	Objetos do domínio (relacionado ao problema)
	
	Objetos da aplicação (relacionado a aspectos computacionais de alto nível)
Os principais diagramas UML usados nas fases de análise são: diagramas de casos de uso e diagrama de classes. Além desses, ajudam também diagramas de interação e de estados, em alguns casos.
	Análise pode ser traduzida em ”faça a coisa certa”.
Projeto (Desenho) de Sistemas Orientado a Objetos
A atividade de projeto denota uma solução, voltada a atender aos requisitos identificados na fase de análise, considerando os recursos tecnológicos necessários para implementar os objetos do domínio e os objetos da aplicação.
O objetivo é decidir “como o sistema funcionará” para atender aos requisitos. Em geral, o projeto enfoca a definição da arquitetura do sistema, determinando suas partes e a relação entre elas, o padrão de interface gráfica, o ambiente computacional (sistema operacional e computacional), a linguagem de programação o gerenciamento do banco de dados.
O projeto, portanto, deriva da análise e produz uma descrição dos recursos computacionais e de como o sistema deve executar no dia a dia. Muitas vezes algumas restrições tecnológicas podem ser impostas como, por exemplo, desenvolver na linguagem X, pelo fato de os sistemas da organização estarem nessa linguagem (claro, se ainda existir no mercado), ou usar o sistema gerenciador de banco de dados Y, pelo fato de a base corporativa da organização estar nele. A fase de projeto pode ser dividida em:
	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. Dentre os diagramas da UML, usamos aqui os diagramas de pacotes, componentes e implantação.
	Projeto detalhado
	Compreende atividades como modelagem das colaborações entre os objetos, projeto da interface, projeto do banco de dados e aspectos computacionais de alto nível (concorrência e distribuição de processamento e dados). O projeto de algoritmos pode ser considerado aqui também, detalhando aspectos do que for relevante para o projeto. Dentre os diagramas UML usados aqui, destacam-se: diagrama de interação (sequência ou comunicação), atividades (se demandar detalhamento de um método ou método com processamento paralelo), detalhamento do diagrama de classes, de estados, dentre outros detalhados adiante.
	Observação: Projeto pode ser traduzido em “faça certo a coisa”.
Desenvolvimento de sistemas em camadas
Abordaremos, inicialmente, a arquitetura de projeto de software em camadas de uma forma geral, sem nos atermos a um modelo em especial. O foco é separar o desenvolvimento do código em camadas, diminuindo sua complexidade e facilitando a sua manutenção. Camadas separam as responsabilidades e gerenciam as dependências.
	No início da computação, os sistemas eram monolíticos, ou seja, todo o código ficava confinado numa única camada, onde misturavam-se comandos de processamento, de construção e manipulação de interface, bem como de acesso e persistência de dados em SGBD. “Tudo junto e misturado”.
	Quando era preciso fazer manutenção no código, havia dificuldade no entendimento e na separação do que de fato precisava ser alterado, sem contar a interferência em uma parte do código quando se alterava outra, em princípio sem relação entre si.
	À medida que os sistemas cresceram e se tornaram complexos, a manutenção ficou mais difícil e a divisão em camadas foi uma das soluções encontradas para o projeto de arquitetura de um software.
Num primeiro momento, a rede cliente-servidor, naturalmente, dividiu o software em duas camadas: a camada 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. As camadas em geral:
· Possuem alta coesão e baixo acoplamento, ou seja, concentram atividades afins (coesão) e são independentes umas das outras.
· Possuem propósito bem definido.
· A camada superior tem conhecimento apenas da imediatamente inferior, que fornece os serviços, por uma interface.
No caso da orientação a objetos, as classes são organizadas em módulos maiores, as chamadas camadas. Uma camada somente pode usar serviço (de outras classes) da camada imediatamente inferior. A seguir, as vantagens e desvantagens do desenvolvimento de software em camadas:
	VANTAGENS
	· Torna o código mais organizado e legível.
· Permite o desenvolvimento, o teste e a manutençãodas camadas isoladamente.
· Permite melhor reuso do código ou dos objetos.
· Pode substituir uma tecnologia que implemente uma camada, de forma simples, sem interferir nas demais. Por exemplo, para trocar o SGBD de SQL Server para PostgreSQL, basta alterar a camada de persistência. As demais permanecem como estavam.
· Disciplina as dependências entre as camadas.
· Mais adaptável a uma quantidade maior de usuários.
	DESVANTAGENS
	· Aumenta o número de classes do sistema.
· A adição de camadas torna o sistema mais complexo.
· Potencialmente, reduz o desempenho do software.
Como exemplo, podemos citar o modelo de camadas mais usado nos últimos anos, o de três camadas, que engloba as camadas de:
	Apresentação
	Compreende as classes do sistema que permitem a interação com o usuário, as chamadas classes de fronteira.
	Negócio
	Compreende as classes responsáveis pelos serviços e pelas regras do negócio, ou seja, reúne as classes de controle e negócio.
	Dados
	Responsável pelo armazenamento e pela recuperação dos dados persistentes do sistema, ou seja, as classes de persistência de dados.
Módulo 3
Descrever as visões, a síntese geral e os diagramas da UML
Conceitos
Neste módulo, conheceremos a UML (Unified Modeling Language ou Linguagem Unificada de Modelagem). Essa linguagem padronizada oferece um conjunto de diagramas, sob diferentes visões, que permitem a modelagem de sistemas orientada a objetos, independente de tecnologia e de processos e metodologias de desenvolvimento de sistemas, cabendo seu uso em qualquer contexto de desenvolvimento orientado a objetos.
O que é UML, afinal?
No final dos anos 1990, as linguagens de programação orientadas a objeto já eram uma realidade, e cada profissional que desenvolvia atividade de análise e projeto de sistemas criava seus próprios modelos, baseados em suas necessidades e realidade. Ou seja, não havia consenso no mercado sobre os modelos a serem usados para modelagem de sistemas desenvolvidos sob a tecnologia de orientação a objetos. Três competentes profissionais despontavam com seus modelos naquele momento:
· Ivar Jacobson, idealizador do método OOSE (Object-Oriented Software Engineering).
· James Rumbaugh, criador do método OMT (Object, Modeling Technique).
· Grady Booch, criador do método que leva seu nome.
A UML foi então adotada pela OMG (Object Management Group), em 1997, oriunda da integração dos três métodos anteriormente descritos, como uma linguagem de modelagem padrão para sistemas desenvolvidos sob o paradigma orientado a objetos.
UML tornou-se o padrão para modelagem gráfica, não apenas para objetos e, de fato, faz sentido essa afirmativa, pois a UML pode ser a linguagem de modelagem para diagramar sistemas concorrentes e distribuídos.
(FOWLER, 2005.)
Desde sua versão inicial, a UML sofreu mudanças substanciais e atualmente encontra-se em sua versão 2.5.1, de dezembro de 2017.
A UML é, portanto, uma linguagem padrão para construção de projetos de sistemas, voltada para a visualização, a especificação, a construção e a documentação de artefatos de um sistema. Foi projetada para ser independente do método ou processo de desenvolvimento utilizado.
A UML é uma linguagem de modelagem, não é um método de desenvolvimento nem tampouco uma metodologia ou um processo de desenvolvimento de sistemas, uma vez que não determina a ordem e nem como os diagramas devem ser usados. Simplesmente disponibiliza os diagramas, sob as várias visões necessárias ao desenvolvimento de sistemas, e cada empresa (ou equipe de desenvolvimento) a utiliza da forma como lhe convenha, ou seja, adequando a UML ao seu processo ou metodologia de desenvolvimento de sistemas. A UML é uma linguagem destinada a:
	Visualização
	A modelagem gráfica facilita a compreensão do sistema e das decisões tomadas em análise e projeto, além de melhorar a comunicação entre a equipe, permitindo sua interpretação sem ambiguidades.
	Especificação
	Permite a construção de modelos precisos, não ambíguos e completos sob diferentes visões e atendendo às necessidades de modelagem das diferentes fases do processo de desenvolvimento de software, independentemente do processo ou modelo usado.
	Construção
	Os diagramas UML podem ser integrados às principais e mais populares linguagens de programação do mercado, tais como Java e C++. Mas, para isso, terá que buscar uma solução integrada de ferramenta CASE (Computer-Aided Software Engineering) que gere código fonte (para linguagens específicas) a partir de alguns diagramas UML.
Resumindo
· A UML é uma linguagem de modelagem padronizada.
· A UML é independente de tecnologia, adequando-se a todo método, metodologia ou processo de desenvolvimento.
· A UML não diz quais diagramas usar e nem em que ordem, pois a metodologia de desenvolvimento ditará essa ordem.
· A UML disponibiliza diagramas sob diferentes visões ou perspectivas.
A UML se tornou não somente a notação gráfica dominante dentro do mundo orientado a objetos, como também uma técnica popular nos círculos não orientado a objetos.
(FOWLER, 2005)
Visões da UML
Assim como vimos nos exemplos do empreendimento imobiliário, as plantas das unidades, a planta elétrica, a planta hidráulica, dentre outras, cada modelo tinha uma perspectiva de compreensão da mesma realidade (unidades residenciais em um empreendimento). No mundo de sistemas computacionais, o mesmo acontece com relação à modelagem de sistemas com UML. Os autores da UML entendem que um sistema deve ser visto sob cinco diferentes perspectivas ou visões, descritas a seguir:
	Visão de casos de uso
	Assim como a maquete permite uma perspectiva geral do empreendimento imobiliário, sob o ponto de vista externo (visão do comprador), a visão de caso de uso permite olhar o sistema sob o ponto de vista externo, do usuário, descrevendo seu comportamento por conjunto de interações usuário-sistema. Tal qual a maquete, é a primeira perspectiva de um empreendimento; a visão de caso de uso é criada no estágio inicial do desenvolvimento e guia todas as demais visões, na medida em que captura os requisitos funcionais que 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)
	Compreende o gerenciamento das versões do sistema, ou seja, de suas implementações utilizáveis por seus usuários. Compreendem os componentes, subsistemas e arquivos que compõem fisicamente o sistema.
	Visão de implantação (ou física)
	Enfatiza a distribuição física do sistema em suas partes (subsistemas e componentes) e as respectivas conexões entre elas. Enfatiza também a organização física dos computadores e as conexões entre eles (a rede de computadores).
	Visão de processo
	Enfatiza aspectos físicos mais peculiares como concorrência, sincronismo entre sistemas e desempenho (performance, confiabilidade, tolerância a falhas e outros aspectos) do sistema, considerando os processos e os processadores.
A UML implementa diagramas que atuam nas cinco visões descritas anteriormente, permitindo ampla modelagem sobre todos os aspectos (visões) relevantes do sistema.
Nem todas as perspectivas ou visões são úteis em todo desenvolvimento, pois dependem das características, tipo e complexidade do sistema. A imagem a seguir mostra a ideia central da visão de casos de uso, influenciando todas as demais.
UML e Integração com processos de desenvolvimento
A UML é independente de metodologia e processo de desenvolvimento. Isso é positivo para os fabricantes de software que implementam UML, pois não limita seu mercado. Sendo assim, cabe a cada empresa ou equipe de desenvolvimento a integração da UML com sua metodologia de desenvolvimento de sistemas computacionais, permitindo uma modelagem eficiente.
A UML pode ser usada de diversas formas, desde esboços manuais para interaçãocom usuários ou equipe, passando pelo uso de ferramentas de diagramação UML até sofisticadas ferramentas CASE, que integram os modelos e geram código em linguagens específicas. A UML então pode ser adaptada em qualquer processo, seja ele:
	Em cascata
	Com e sem retroalimentação, onde as fases se sucedem, a seguinte inicia quando a anterior termina. A desvantagem é que, se for sem retroalimentação, não há opção de retorno à fase anterior. Por exemplo, se na fase de projeto identificamos novos requisitos, estes não podem ser considerados, pois a fase de análise congelou os requisitos identificados. Se a retroalimentação for permitida, esse problema pode ser minimizado, mas não solucionado. O grande problema é que o usuário interage com a equipe de desenvolvimento no início do processo e ao final, quando o sistema é entregue.
	Interativo
	Onde o sistema é dividido em subconjuntos de funcionalidades (com mínimo de dependência com os demais conjuntos), e as atividades de análise, projeto, implementação, teste e implantação são realizadas a cada subconjunto. Isso significa que a cada subconjunto haverá a implantação de uma parte do sistema, permitindo que ajustes das partes encerradas ocorram em paralelo com o novo subconjunto de funcionalidades que está sendo construído.
	Ágil
	Os processos são ditos ágeis porque compartilham um conjunto de valores e princípios definido pelo manifesto ágil. O foco aqui é permitir modificação sempre que preciso e no desenvolvimento de código. A modelagem existe, mas em menor escala e com ênfase na comunicação com usuário e equipe de desenvolvimento. Visa a pouca formalidade nos processos ágeis. Mais usados: Extreme Programming (XP), Scrum, FDD (Feature Driven Development).
	RUP (Rational Unified Process)
	O mercado muito fala da integração UML e RUP, mas, como os demais processos, o RUP é independente da UML. O RUP, na verdade, é uma estrutura de processo, que vai usar casos de desenvolvimentos (processo a ser usado), a maioria deles iterativos. O RUP não se adapta a processo em cascata.
Visão geral dos diagramas UML
Vamos nos ater aqui à versão mais recente da UML, a 2.5.1, que traz 14 diagramas divididos em estruturais e comportamentais, conforme imagem a seguir.
	Os diagramas estruturais
	Dizem respeito às estruturas estáticas necessárias ao sistema, como os pacotes, as classes, os objetos, os componentes e a estrutura de nós (estruturas computacionais). Também são chamados de estruturas estáticas.
	Os diagramas comportamentais
	Evidenciam o comportamento (funcionamento) de parte de um sistema ou processo de negócio relacionado ao sistema, segundo determinada perspectiva. Dizem respeito às funcionalidades do sistema, aos estados de um objeto em seu ciclo de vida, às interações entre os objetos, dentre outros aspectos. Também são chamados de diagramas dinâmicos.
A seguir, uma breve descrição de cada diagrama da UML:
	Diagrama
	Especificação
	Diagrama de perfil
	Permite a definição de tipos padronizados, como estereótipos, restrições e valores rotulados. O foco é a adequação aos modelos UML para diferentes plataformas, por exemplo.
	Diagrama de classes
	Descreve, para cada classe, suas propriedades (atributos e métodos) e seus relacionamentos com as demais classes. Classe é a base estrutural dos sistemas orientados a objetos.
	Diagrama de estruturas compostas
	Possibilita a descrição de colaborações internas de classes, interfaces ou componentes, visando a especificação de uma funcionalidade.
	Diagrama de componentes
	Apresenta a estrutura e as conexões entre os componentes de um sistema.
	Diagrama de implantação
	Especifica o ambiente computacional sobre o qual o sistema vai operar, além de distribuir os artefatos (pacotes, classes e componentes) nos nós (elementos computacionais).
	Diagrama de objetos
	É um diagrama de classes instanciado, ou seja, mostra exemplos de instâncias de classes.
	Diagrama de pacotes
	Descreve estruturas hierárquicas que englobam outros elementos, como outros pacotes, casos de uso, classes. Usado para modularizar logicamente um sistema em suas partes relevantes (subsistemas).
	Diagrama de atividades
	Descreve o comportamento de procedimentos, processos de negócios e fluxos de trabalho, suportando processamento sequencial e paralelo.
	Diagrama de casos de uso
	Mostra como os usuários (atores) interagem com o sistema, do ponto de vista externo, evidenciando as funcionalidades com as quais interagem.
	Diagrama de estados
	Mostra como os eventos que afetam o sistema alteram o estado dos objetos ao longo de seus ciclos de vida.
	Diagrama de sequência
	Mostra como os objetos interagem, evidenciando a linha de tempo (a sequência das interações).
	Diagrama de comunicação
	Mostra como os objetos interagem, evidenciando as conexões e colaborações entre eles.
	Diagrama de visão geral de interação
	Um mix de diagrama de sequência e de atividades. Uma especialização do diagrama de atividades para interações.
	Diagrama de tempo
	Diagrama de interação, com foco nas restrições de temporização, como, por exemplo, para evidenciar as mudanças no estado de um objeto ao longo do tempo.
Diagramas UML e sua utilização nas fases
O descrito a seguir não é recomendado ou estipulado pela UML, pois a UML não determina quais diagramas devem ser usados e tampouco em que ordem devem ser elaborados. São dicas práticas.
Dificilmente usamos todos os diagramas da UML em um único sistema. Há um conjunto de 4 a 8 diagramas que são os mais usados: pacotes, casos de uso, classes, sequência (ou comunicação), estados, atividades, componentes e implantação. Todos os mencionados são relevantes, mas os em negrito são os essenciais.
No módulo 1, descrevemos as atividades das fases de análise (levantamento e análise de requisitos) e projeto independentemente do processo de desenvolvimento por entender que ambas estarão presentes em qualquer processo que usemos. Agora, partindo desse mesmo pressuposto, vamos descrever os diagramas UML que podem ser usados em cada uma dessas três fases. Citaremos apenas os diagramas mais usados.
Diagramas UML na atividade de análise
	Levantamento de requisitos
	Análise de requisitos
	Esboço inicial do diagrama de pacotes, para grandes sistemas, evidenciando a necessidade de particionamento
	Detalhamento e aprofundamento do diagrama de pacotes
	Esboço inicial do diagrama de casos de uso
	Detalhamento e aprofundamento do diagrama de casos de uso
	Esboço inicial do diagrama conceitual de classes, em alto nível (sem detalhes)
	Detalhamento e aprofundamento do diagrama conceitual de classes
	
	Diagrama de estados, para os objetos mais complexos durante seu ciclo de vida
	
	Diagrama de atividades, para elucidar um processo ou fluxo de trabalho relevante ou ainda para elucidar um caso de uso mais complexo
Nota: o diagrama conceitual de classes evidencia as classes (com principais atributos e inicialmente sem métodos) e os principais relacionamentos (em geral apenas associações, que são os relacionamentos de classes mais elementares).
Os diagramas usados no levantamento de requisitos são, em geral, esboços para a própria pessoa ou para debater com colegas da equipe. Já na fase de análise de requisitos, alguns diagramas, em geral pacotes e casos de uso, são usados para conversas com usuários.
Diagramas UML na atividade de projeto
	Adição de detalhes ao diagrama conceitual de classes, que passa a ser o diagrama de classes de projeto.
	Diagrama de sequência ou diagrama de comunicação, para cenários de uso mais relevantes, o que ajuda a identificar métodos das classes envolvidas na interação.
	Detalhamento dos diagramas de estados elaborados na atividade de análise, podendo modelar de outros objetos percebidos.
	Diagrama de componentes, caso o software use algum já pronto ou a ser construído.
	Diagrama de implantação, evidenciando as unidades computacionais e alocando os componentes nelas.
	Diagrama de atividades, esclarecendo métodos de classes mais complexos ou que usem processamento paralelo.
Nota: o diagramade classes de projeto deriva do diagrama conceitual de classes, agregando novos atributos, todos os métodos necessários, identificando os corretos relacionamentos entre as classes (e não apenas associações), adicionando as multiplicidades e outros elementos relevantes da UML.
Conclusão
Considerações finais
Vimos que o desenvolvimento de sistemas é uma atividade complexa, que envolve pessoas estudando um sistema que também será usado por outras pessoas. Ou seja, existe muita subjetividade envolvida nesse processo. Para minimizar essa subjetividade, o processo de desenvolvimento de um software é divido em fases, de forma que inicialmente tenhamos uma visão geral do sistema e, à medida que nos aprofundamos, conhecemos mais detalhes da estrutura e do funcionamento desse sistema.
Vimos ainda que os processos de desenvolvimento usam diagramas, que são modelos que expressam a realidade sob determinada perspectiva, para melhorar a comunicação com os usuários e entre os membros da equipe de desenvolvimento.
Conforme apresentado, os sistemas foram crescendo em tamanho e complexidade, e as técnicas usadas passaram a não atender às demandas. Percebeu-se, então, uma nova forma de visualizar os sistemas, com objetos do mundo real que interagem. Nasceu, assim, um novo paradigma de desenvolvimento: o paradigma orientado a objetos.
Esse novo paradigma, porém, precisou de modelos compatíveis, pois os modelos dos paradigmas anteriores não atendiam à nova forma de ver e de construir sistemas. Os melhores profissionais do mercado produziram seus próprios modelos e, em 1997, criaram uma linguagem unificada, em padrão relativamente aberto: a UML (em português, Linguagem Unificada de Modelagem), que vem evoluindo substancialmente desde sua criação, estando em sua versão 2.5.1, de 2017.
A UML é uma linguagem de modelagem independente de tecnologia, que se aplica a qualquer processo de desenvolvimento (orientado a objetos ou não). Ela especifica um conjunto de diagramas sob cinco diferentes visões que podemos ter sobre um sistema: visão de casos de uso (central), visão de projeto ou lógica, visão de implementação (ou desenvolvimento), visão de implantação (ou física) e visão de processo. Os diagramas de cada versão da UML atendem a uma ou mais dessas perspectivas e são usados nas diferentes fases de um processo de desenvolvimento.
AULA 2 – UML PARA MODELAGEM DO DOMÍNIO
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 modelagem conceitual 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
Requisitos Funcionais e Não Funcionais
O desenvolvimento de um sistema começa pelo entendimento do problema de negócio e o levantamento de quais requisitos esse sistema de software deve satisfazer para resolvê-lo. Não existe uma definição padronizada para requisito na literatura de Engenharia de Software. A norma ISO/IEC/IEEE (IEEE, 1990) apresenta os seguintes enunciados para explicar o que é requisito:
· Uma condição ou capacidade do sistema solicitada por um usuário, para resolver um problema ou atingir um objetivo.
· Uma condição ou capacidade que deve ser atendida por uma solução para satisfazer um contrato, uma especificação, um padrão ou quaisquer outros documentos formais impostos.
· Documentação da representação das condições ou capacidades apresentadas nos dois anteriores.
· Necessidades quantificadas e documentadas, desejos e expectativas do patrocinador, clientes e outras partes interessadas.
Os requisitos são o ponto de partida para todo o processo de desenvolvimento, sendo a base para as atividades de análise e projeto, bem como implementação e testes. De acordo com Sommerville (2011), a área de Engenharia de Software faz uma distinção, em termos de nível de detalhamento de requisitos, entre requisitos de usuário e requisitos de sistema. O primeiro expressa os requisitos abstratos de alto nível, e o segundo revela uma descrição detalhada do que o sistema deve fazer.
Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este deve operar.
Sommerville, 2011
Requisitos de sistema são descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software.
Sommerville, 2011
Em uma perspectiva mais técnica, os requisitos de software são normalmente classificados como requisitos funcionais e requisitos não funcionais.
Requisitos funcionais são declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações.
Sommerville, 2011
Atenção: Requisito funcional é uma funcionalidade do sistema, é algo que o sistema deve realizar para prover um resultado para o usuário. Requisitos funcionais pressupõem interação do sistema com usuários.
Veja uma lista com alguns exemplos de enunciados dos chamados requisitos funcionais:
· O usuário deve ser capaz de pesquisar por nome na base de dados disponível.
· O sistema deve designar um identificador único (NUMERO_PEDIDO) para cada pedido do usuário.
· O sistema deve apresentar o documento selecionado para leitura do usuário.
Perceba que, em todos os exemplos,estamos definindo atividades que o sistema deve realizar, e, em todas essas atividades, o usuário está envolvido, seja fornecendo entradas ou recebendo saídas (resultados).
A especificação de um sistema precisa considerar também como esses requisitos serão entregues. Ou seja, quais características de qualidade e quais restrições desejamos impor ao sistema. Assim, definimos os chamados requisitos não funcionais.
Requisitos não funcionais são restrições aos serviços ou funções oferecidos pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das características individuais ou serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo.
Sommerville, 2011
Requisitos não funcionais (RNF) são frequentemente mais críticos do que os requisitos funcionais (RF). Deixar de atender a um RNF pode significar a inutilização de todo o sistema. Os RNF podem afetar a arquitetura geral de um sistema em vez de apenas componentes individuais. No caso de um website, um único RNF pode originar uma série de RF relacionados, que, por sua vez, definem os serviços necessários.
Existem diversas classificações que visam a organizar e prover melhor entendimento sobre os RNF. Um exemplo desse tipo de classificação é apresentado na lista a seguir.
· Requisitos de produto: usabilidade, eficiência, desempenho, confiança, proteção.
· Requisitos organizacionais: ambientais, operacionais, processo de desenvolvimento.
· Requisitos externos: reguladores, éticos, legais, contábeis.
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 abaixo mostra um exemplo de Diagrama de Casos de Uso para um sistema bancário.
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 acima, 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 acima, 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, 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:
	Cargos
	Por exemplo: empregado, cliente, gerente, vendedor, comprador etc.
	Organizações e suas divisões
	Por exemplo: fornecedor, agência reguladora, administradora de cartões, setor de vendas etc.
	Outros sistemas
	Por exemplo: sistema de vendas, sistema de cobrança, sistema de pagamento etc.
	Hardware
	Por exemplo: sensor de temperatura, leitora de código de barras etc.
O relacionamento de generalização entre atores indica que uma instância do primeiro ator interage com os mesmos tipos de instância de casos de uso do segundo. Porém, o contrário não é verdade. Os casos de uso associados ao ator mais específico nesse relacionamento são exclusivos desse ator, que herda os casos de uso associados ao ator mais genérico. A figura 2 mostra um exemplo desse tipo de relacionamento, no qual percebemos que tanto o ator Vendedor quanto o ator Supervisor interagem com o caso de uso Fazer pedido. No entanto, apenas o Supervisor participa do caso de uso Aprovar crédito.
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 doscasos 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.
Casos de Uso Primários
Estão relacionados diretamente aos objetivos dos atores, ou seja, são as funcionalidades que agregam valor aos usuários. Bezerra (2015) sugere uma lista de perguntas para auxiliar os analistas de sistemas na descoberta dos casos de uso primários de um sistema:
1. Quais são as necessidades e os objetivos de cada ator em relação ao sistema?
2. Que informações o sistema deve produzir?
3. O sistema deve realizar alguma ação que ocorre regularmente no tempo?
4. Para cada requisito funcional, existe um caso de uso (ou mais) para atendê-lo?
Alguns casos de uso são iniciados não por um ator, mas por um evento temporal. Desse modo, normalmente o ator é o tipo de entidade que recebe a informação resultante (por exemplo, um cliente que receba uma notificação do sistema).
Casos de Uso Secundários
Esses casos não apresentam uma relação direta de valor para os atores, mas são imprescindíveis para o funcionamento do sistema. Por exemplo, a manutenção de cadastros (inclusão, alteração, consulta e exclusão das diversas informações que alimentam o sistema). Um sistema bancário precisa cadastrar as informações sobre os clientes.
Relacionamentos
	Os relacionamentos são responsáveis por estabelecer as associações entre atores e casos de uso.
Todos os atores devem estar associados explicitamente aos casos de uso com os quais interagem. Além disso, podemos estabelecer relacionamentos entre os casos de uso ou entre os atores do sistema. O Modelo de Casos de uso permite os seguintes tipos de relacionamentos: comunicação, inclusão, extensão e generalização.
Relacionamento de comunicação
É uma linha simples que mostra a que caso de uso determinado ator está associado, ou seja, esse ator interage com o sistema por meio do caso de uso. Um ator pode se relacionar com mais de um caso de uso, e todos os atores devem estar associados a pelo menos um caso de uso. Esse relacionamento foi mostrado na figura 1.
Atenção: Um erro comum na elaboração de diagramas de casos de uso é estabelecer relacionamentos de comunicação entre casos de uso. Não existe troca de informações entre casos de uso, uma vez que são funcionalidades independentes entre si.
Os relacionamentos de inclusão (include), extensão (extend) e generalização são estabelecidos entre casos de uso.
Relacionamento de inclusão
Tem como objetivo principal a reutilização. Suponha que uma parte dos passos de execução de um caso de uso se repita em diversos outros casos de uso. Podemos criar um caso de uso separado e “incluí-lo” nos demais. A inclusão funciona de forma semelhante à chamada de uma função em um programa. A representação gráfica do relacionamento de inclusão é uma linha pontilhada com o estereótipo <<include>> apontando do caso de uso inclusor para o incluído. A figura abaixo mostra um exemplo desse tipo de relacionamento.
No exemplo acima, 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 abaixo mostra um exemplo do relacionamento de extensão.
Observe no exemplo acima, 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 abaixo mostra um exemplo do relacionamento de generalização:
Como podemos observar na figura acima, o caso de uso Cadastrar empregado executa uma sequência de passos de cadastro para qualquer funcionário. Já os casos de uso mais específicos (Cadastrar vendedor e Cadastrar supervisor) herdam esses passos e ainda possuem passos específicos para os tipos de funcionários Vendedor e Supervisor, respectivamente. Os tipos de relacionamento entre casos de uso abordados permitem manter a descrição dos casos de uso mais simples e sem repetições.
· A inclusão deve ser usada quando um comportamento se repetir em mais de um caso de uso.
· A extensão é normalmente usada quando um comportamento que não é executado em todas as instâncias de um caso de uso deva ser descrito.
· A generalização deve ser aplicada em uma situação em que dois ou mais casos de uso possuam comportamentos comuns.
Módulo 2
Reconhecer casos de uso por meio de especificações textuais
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