Tcc-Engenharia de software (1)

Prévia do material em texto

2
		
Processos de desenvolvimento e modelagem e conceitos de casos de uso e definições da UML 
Vandeilson Menezes da silva
Resumo
Atualmente como o aumento da informatização de diversos processos, a modelagem de sistemas tornou-se um dos pilares do desenvolvimento, certamente ao iniciarmos os processos de criação de um software sem o entendimento daquilo que precisa ser feito, haverá uma lacuna sobre como desenvolver, o presente artigo visa demonstra de forma conceitual os processos que envolvem a modelagem dos diagramas de caso de uso e da modelagem de classes que por sua vez são parte fundamental para o desenvolvimento de softwares modernos e confiáveis, aumentando assim os nível de confiabilidade e produtividade das equipos, consequentemente apresentando melhores resultados e lucros com a utilização das técnicas corretas.
Palavra-Chave: Modelagem; Caso de uso; Classes; Desenvolvimento.
Abstract: Currently, as the computerization of several processes has increased, the modeling of systems has become one of the pillars of development, certainly when we start the processes of creating software without understanding what needs to be done, there will be a gap on how to develop, the This article aims to demonstrate in a conceptual way the processes that involve the modeling of use case diagrams and class modeling, which in turn are a fundamental part for the development of modern and reliable software, thus increasing the levels of reliability and productivity of the teams , consequently presenting better results and profits with the use of the correct techniques.
Key word: Modeling; Use case; Classes; Development.
Introdução 
	Conforme a evolução tecnológica progride, conceitos de modelagem torna-se cada vez mais relevantes algumas etapas desta abordagem são os processos de desenvolvimento e modelos de caso de uso e uml, essas etapas consistem em diversas fases que irá produzir diversos diagramas que auxiliarão no desenvolvimento do software.
	Processos de desenvolvimento consistem em diversas etapas que por si só não são muito relevantes porem como parte de um todo irão auxiliar na criação dos diagramas de caso de uso facilitaram na identificação dos atores e seus relacionamentos e consequentemente auxiliarão a aplicação dos diagramas de caso de uso.
	O presente artigo visa apresentar processos que norteiam o desenvolvimento e modelagem de softwares, demonstrando seus aspectos e etapas que, por sua vez servem para o desenvolvimento de sistemas complexo e simples, mesmo sendo uma abordagem pratica, demonstrará as etapas para tais técnicas serem aplicadas.
	Certamente softwares, eficientes são de extrema necessidade na atualidade desta forma processos que auxiliam na identificação daquilo que precisa ser desenvolvido são de estrema relevância, e em não devem ser ignorados, assim os processos de desenvolvimento e seus aspectos como diagramas de caso de uso e modelagem uml são fundamentais na atualidade.
	Este artigo tem por objetivo apresentar as etapas que podem auxiliar nos processos de desenvolvimento de softwares e modelagem de diagramas de caso de uso e modelagem de classes da uml, apresentado os relacionamentos tipos de classes e suas respetivas iterações, com suas definições e formas gráficas. 
A pesquisa buscou nas referências bibliográficas e seus principais autores as definições e um aprofundamento teórico sobre o tema e suas características, o presente artigo contará com o uso de diversas ferramentas de modelagem e a consulta á autores que são considerados referência no seguimento de processos e modelagem.
Processo de desenvolvimento do software
	Dentro do processo de desenvolvimento existem atividades típicas que precisam ser consideradas para o início de um projeto são elas levantamento de requisitos, análise, projeto(desenho), testes, implementação valem ressaltar que esse processo é de fundamental importância pois a partir destes pontos a serem reunidos, surgirá as etapas de desenvolvimento para o software. 
	Um software para seus objetivos funcionais seja alcançado depende de uma fase na qual, as partes interessadas manifestam sua necessidade e objetivo a ser alcançando no desenvolvimento, consiste no uso de técnicas sistemáticas que serão documentadas assim sendo a fase de requisito avalia as questões do usuário e gera um entendimento.
 
Requisitos de um sistema
Essa atividade visa o momento em que os desenvolvedores juntamente com os clientes abordam o problema gerando assim as necessidades que precisam, ser solucionadas, de uma formalmente requisito são identificados a partir de um domínio. Domínio segundo Bezerra, Eduardo (2015, p.22) “no contexto do desenvolvimento de software, um domínio corresponde à parte do mundo real que é relevante, no sentido de que algumas informações e processos desse domínio precisam ser incluídos no sistema em desenvolvimento”, dentro desta definição as necessidades observadas no domínio precisam ser abstraídas para um produtivo processo de desenvolvimento.
Análise de requisitos
Consiste, na fragmentação do sistema a ser elaborado observando as suas interações, com o objetivo de entender como funcionam, dentro do contexto apresentado essa etapa deve-se realizar um estudo detalhado dos requisitos que fazem parte do sistema, tendo como grande foco elaborar formas de resolver os problemas apontados, afim de atender as necessidades do usuário podemos resumir essa fase, compreender aquilo que foi solicitado com o objetivo de apresentar as melhores propostas.
Projeto ou desenho
Conforme explicado por Bezerra, Eduardo (2015, p.29) “ Na fase de projeto, determina-se “como” o sistema funcionará para atender aos requisitos, de acordo com os recursos tecnológicos existentes”, produzindo um modelo computacional no qual irá definir o tipo de tecnologia a ser usado no desenvolvimento, consiste em duas fases projeto de arquitetura também conhecido como projeto de alto nível e projeto detalhado também chamado de baixo nível. Durante o desenvolvimento de software orientados a objetos a etapa de projeto de arquitetura consiste na distribuição do sistema em subsistemas e relacionado suas funcionalidades e usando diagramas de implementação “UML” para auxiliar nesse processo. Na fase de projeto detalhado é realizada a modelagem entre objetos de cada modulo também é realizado o projeto de interfaces e banco de dados, utiliza “UML” com o diagrama de classes, caso de uso, interação, estado e atividade.
Implementação
Na fase de implementação há a conversão daquilo que foi levantado nas fases anteriores, é feita a instalação do software no ambiente coorporativo, é feito o treinamento com o objetivo do sistema ser utilizado corretamente ,são criados manuais é feita a importação de dados se houverem, e em certos casos a migração de sistemas ou base de dados pré-existente.
Modelagem de caso de uso
	Sistemas necessitam de funcionalidades adequadas que atendam aos requisitos solicitados, portanto durante o levantamento de requisitos devemos nos certificar que tais requisitos estejam sendo devidamente observados e abstraídos corretamente, a UML disponibiliza para tal objetivo o diagrama de caso de uso que tem por função, diagramas de caso de uso apontam os atores do sistema e mapear a funcionalidades do mesmo.
	Diagramas de caso de uso tem por principal finalidade, apresentar as funcionalidades que foram solicitadas, ou seja o mesmo pode começar a ser elaborando após a etapa de levantamento de requisitos, tornando possível a elaboração da documentação e o mapeamento das funções que o sistema terá, diagrama de caso de uso também pode ser usado para homologar junto ao usuário final certificando assim que todos os requisitos foram identificado e entregues, orientar as equipes de desenvolvimento sobre aquilo que foi abstraído durante a fase de levantamento de requisitos.
	O diagrama de caso de uso possui uma praticidade no seu uso possuindo poucos elementos para sua manipulação são eles:
· Os atores são aqueles que irão interagir com o sistema normalmente representadospelo stickman ele demonstra papeis interno e externo da forma que irão interagir com o sistema. 
Conforme a figura acima demostra o ator é aquele que irá interagir com o sistema, podendo apresentar papeis interno e externos, como por exemplo demonstraremos nas figuras abaixo, duas formas de atuação de atores e seus respectivos papeis.
	Os atores podem assumir também a simbologia de setores vejamos abaixo.
Identificando atores
	Durante a fase de levantamento de requisito devemos prioritariamente alcançar o entendimento daquilo que o software fará, a construção do modelo de caso de uso depende dessa fase, tornado assim primordial essa fase, podemos alcançar esse objetivo realizando perguntas que ajudaram a identificar os atores algumas ´perguntas tais como:
· Quem usará o sistema “usuários ou setores”?
· Quem inicia o sistema “gerente, líder etc.”?
· Quem fornece os dados “operador de caixa, cliente, atendente”?
· Quem usa as informações “diretores, usuários, médicos”?
Caso de uso
	Conforme T.A Guedes, Gillesnes (2009, p.31)” O diagrama de casos de uso é o diagrama mais geral e informal da UML, utilizado normalmente nas fases de levantamento e análise de requisitos do sistema, embora venha a ser consultado durante todo o processo de modelagem e possa servir de base para outros diagramas.”, sendo de linguagem simples e fácil entendimento servira de constante consultas para a elaboração de outro tipos de diagramas, sendo descrito de forma narrativa o mesmo descreve sequencias de eventos que ocorrem quando um ator usa o sistema. 
	Sendo descritos na fase de levantamento de requisitos, cada sequência efetuada pelos atores é chamada de cenário, casos de uso vão tornam-se mais evidente cada vez que identificamos os atores e suas ações nos cenários que foram evidenciados nas etapas anteriores, algumas perguntas podem ser uteis na criação do caso de uso vejamos algumas.
· Qual o objetivo de cada ator ao usar o sistema?
· Qual o tipo de saída de dados o sistema irá produzir?
· O sistema será repetitivo em suas ações?
· Existirá um caso de uso para cada requisito funcional?
Vejamos a figura abaixo, ela demonstrará um caso de uso dos qual existirá três atores sete cenários:
 
Tipo de relacionamento e como interagem
	Dentro do conceito do diagrama de caso de uso existe a interação e o relacionamento, que definem a forma com a qual eles interagem entre si, desta forma ao observamos esses conceitos iremos abstrair a forma como a qual modelamos os casos de usos nas suas definições.
Relacionamento entre caso de uso e ator
	Relacionamento no diagrama de caso de uso e ator, sendo o mais comum demonstrado por uma linha continua ligando o ator e o caso indicando a interação, de forma mais direta indica que o ator realiza o caso de uso, a figura abaixo ilustra o relacionamento mostrando um relacionamento bidirecional denotando que o ator insere dados no caso de uso e recebe informações.
Relacionamento entre atores
	Relacionamento entre atores 	‘acarretando uma generalização/especialização os autores a relação são ilustrados por uma linha solida com uma seta indicando o ator principal, no desenho abaixo o ator geral é a secretária, e o especialista é o supervisor, sendo que de acordo com a regra de negócio ambos exercerão ações diferentes em um sistema.
	
Relacionamento entre caso de uso.
	São classificados em três tipos inclusão, extensão e generalização esses três tipos classificam o relacionamento entre caso de uso, demonstrando suas iterações entre eles iremos demonstrar suas aplicações individualmente:
Relacionamento do tipo Inclusão (include ou uses)
	Essa interação agrega de forma clara a funcionalidade de outro caso de uso, incluindo assim o caso de uso, adicionando ao caso de uso principal, esse relacionamento pode incluir mais de um caso de uso ao principal de acordo com a necessidade dos requisitos o mesmo é demonstrado por uma linha tracejada indicado o caso de uso que será incorporado ao caso de uso principal conforme BOOCH, G.;JACOBSON, I.;RUBAUCH,J.;(2012,p.244) “inclusão pode ser representado como uma dependência, estereotipada como include. Para especificar a localização em um fluxo de eventos no qual o caso de uso base inclui o comportamento de um outro” vejamos abaixo um exemplo.
Relacionamento do tipo Extensão (extend)
	Descrito por BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.356) ”O relacionamento estendido é representado como uma dependência, estereotipada como extend. Os pontos de extensão do caso de uso base poderão ser relacionados em um compartimento extra.”, sendo assim entendemos que um caso um caso B estende-se a um caso A sendo que o caso A é o principal, normalmente o extend é incluído quando a alguma interrupção no fluxo de execução do caso de uso vejamos abaixo um exemplo:
	
	Onde o extend foi adicionado houve uma interrupção e o sistema irá gerar uma informação de erro no pedido.
Relacionamento do tipo generalização 
	
	Trate-se de generalização conforme os atores BOOCH,G.; JACOBOSON,I.;RUBAUCH,J.;(2012,p.354) “Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso em uma localização especificada na base.”, desta quando há uma semelhança funcional no caso de uso, devemos tomar cuidado para não confundir com o extend, no caso em questão este relacionamento caracteriza-se pelo caso de uso possuir funcionalidades, possuindo um comportamento de adição podemos identificar tal situação no exemplo que será demonstrado na ilustração abaixo.
A especificação do caso de uso e suas vantagens
	Diagramas de caso de uso fornecem uma visão geral das funcionalidades do sistema, essa visão é fornecida através do conjunto de caso de uso que serão identificados devidamente relacionados, entretanto o mesmo não demonstra as interações que existem, podemos compreender que os diagramas são um resumo e prospectam, aos desenvolvedores as funcionalidades do sistema, entretanto o valor real do caso de uso é apresentado na descrição textual de cada caso, que demonstram a abstração do mundo real, que facilitará o desenvolvimento de softwares, uma vantagem á mais do diagrama é sua facilidade de entendimento tornando assim uma boa ferramenta de comunicação das equipes de desenvolvimento e usuário, tornado o mesmo umas boas pratica e aconselhável reserva, tempo para a elaboração de tal recurso.
 
Formatos específicos para caso de uso 
	Em sua obra Utilizando UML e Padrões - Uma introdução à análise e ao projeto orientado a objeto ao desenvolvimento interativo, de Craig Larman o autor destaca três tipos comuns de caso de uso, são eles;
	Resumido, descrito em poucas palavras em um parágrafo, geralmente destaca o cenário principal, recomenta-se seu uso durante a fase de requisito inicial com a finalidade de obter, uma ideia geral do assunto a ser tratado.
	Informal, descrito em vários parágrafos que abordam vários cenários, auxilia na fase inicial de requisitos com a finalidade de obter uma ideia geral do assunto.
	Completo, descrito em detalhes há seções de suporte como pré-condições, pode ser usado após vários casos de uso terem sido elaborados e descritos na forma resumida e informal, durante a fase de requisito recomendamos esse formato para a elaboração de caso de uso mais complexos e relevantes.
Diferenças entre os três tipos de especificações	
	Usaremos um exemplo para demonstrar a diferença entre os três tipos de formatos, resumido, informal e completo o caso de uso descreverá o registro de uma venda.
 
	No trecho do diagrama acima, forma considerados dois atores “caixa” e “cliente”, consideramos o “cliente”, como ator pois o mesmo interage com os sistemas.
Formato resumido
	Ao chegar ao guichê de pagamento o cliente, entrega os itens que escolheu na loja ao caixa que irá registrar no sistema cada item entregue pelo cliente, o sistema emite um cupom que irá listar os itens, quantidades, valores e total da compra, após o cliente informará ao caixa a forma de pagamento que são reconhecidopelo sistema, que atualiza o estoque e emite o cupom do cliente e cliente pode levar os produtos após a emissão c do cupom pois o mesmo indica o fim da compra.
Formato informal
	O cliente direciona-se ao caixa com o produtos escolhidos, o operador de caixa usa um sistema de pdv para registra todos os itens selecionados pelo cliente, ao final o sistema informa os itens registrados, valores e quantidades realizando efetuando o total da compra, o cliente informa a forma de pagamento, o caixa validada o forma de pagamento no sistema que atualiza o estoque e emite um cupom após isto o cliente pode sair da loja com a compra realizada.
Cenário alternativo	
	
	Caso seja registrado no sistema algum item que não esteja cadastrado o sistema informa ao caixa que há um item, que não está cadastrado.
	Na forma de pagamento caso o cliente queira pagar com cartão de crédito, e o mesmo não possua saldo positivo o operado de caixa deverá informar ao cliente que o mesmo deverá informa outra forma de pagamento. 
	Outra situação que pode ser prevista se o sistema não atualizar o estoque gerando inconsistências o mesmo deverá informar ao operador, que transmitirá a informação ao seu superior para a devida correção.
Formato completo
	Como o formato completo é o mais recomendado para a elaboração de casos de uso complexo o mesmo, apresenta vários padrões e formatos disponíveis, como há caso de uso que são mais relevantes os mesmos precisam de especificações mais completas, em seu livro Craig Larman demonstra seções que compõem o formato completo vejamos abaixo será demonstrado um gabarito sugerido pelo autor.
	Seção do caso de uso
	Comentário
	Nome do caso de uso 
	Começar com um verbo
	Escopo
	O sistema em projeto
	Nível
	“objetivo do usuário” ou “sub-função”
	Ator principal
	Chama o sistema para fornecer os serviços
	Interessados e interesses
	Quem se importa com esse caso de uso e o que eles desejam?
	Pré-condição
	O que precisa ser verdade de início e vale a pena dizer ao leitor?
	Garantia de sucesso
	O que precisa ser verdade quando da finalização bem-sucedida e se vale a pena dizer ao leitor.
	Cenário de sucesso principal
	Um caminho típico, incondicional e otimista do cenário de sucesso.
	Extensões
	Cenários alternativos de sucesso ou fracasso.
	Requisitos especiais
	Requisito não funcional relacionados.
	Lista de variedades tecnológicas e de dados
	Métodos de entrada e saída e formatos de dados variáveis.
	Frequência e ocorrência 
	Influencia a investigação, teste e oportunidade da implementação 
	Diversos 
	Como, por exemplo, pontos em aberto.
	Como podemos observar esse gabarito sugerido pelo autor abrange diversos aspectos do caso de uso com a finalidade de entendermos melhor abordaremos o exemplo citado anteriormente vejamos novamente o trecho do caso de uso e em seguida, aplicando o gabarito sugerido pelo autor. 
	Agora iremos aplicar o gabarito sugerido pelo auto Craig Larman.
	Seção do caso de uso
	Comentário
	Nome do caso de uso 
	Registro de venda
	Escopo
	Sistema de venda - pdv
	Nível
	objetivo do usuário
	Ator principal
	Caixa
	Interessados e interesses
	O caixa deseja que o sistema seja eficiente e rápido.
O cliente deseja adquirir os produtos de forma rápida e sem erros.
O gerente deseja um controle eficiente das vendas.
O repositor deseja que o estoque seja atualizado corretamente.
	Pré-condição
	Todos os itens devem estar devidamente codificados no sistema, com os respectivos preções e códigos.
	Garantia de sucesso
	Uso correto, a venda salva, itens registrados e atualizado o estoque, impostos contabilizados, regras fiscais cumpridas.
	Cenário de sucesso principal
	Devido controle contábil, financeiro e estoque
	Extensões ou cenário alternativo
	A qualquer momento o caixa pode solicitar, correção de preços, ajuste de quantidades, cancelamento de venda etc.
	Requisitos especiais
	Interface sensível ao toque, texto visível a distância de um metro.
	Lista de variedades tecnológicas e de dados
	Leitor biométrico para autorização especial, leitor de código de barras a laser.
	Frequência e ocorrência 
	Continua
	Diversos 
	Questões não observadas que podem ser relevantes.
Cenário principal ou fluxo básico.
	
	O cenário principal é trata-se da forma padrão do usuário usar o sistema, basicamente é o caminho criado para o objetivo ser alcançado abaixo iremos descrever conforme, o livro de Craig Larman o que é caracterizado como fluxo básico ou cenário principal de acordo com o exemplo que está sendo demonstrado.
1. O cliente chega ao caixa com os bens ou serviços que serão adquiridos.
2. O operado de caixa inicia uma nova venda.
3. O operador de caixa inicia a leitura digital dos códigos de barras pertencentes a cada produtos com o leitor ou digitando manualmente.
4. O sistema identifica os itens, apresenta a descrição o valor calcula os impostos, repete-se está operação ‘1,2,3,4’ até encerra-se as compras do cliente.
5. O sistema apresenta o valor final com quantidades e valores com os impostos.
6. O operador informa o valor final e as formas de pagamento ao cliente.
7. O cliente informa a forma de pagamento e o sistema processa.
8. O sistema registra a venda completa emite um cupom na tela, envia as informações da venda, atualiza o estoque, contabiliza os impostos finais e finaliza a venda.
9. O sistema imprime o recibo.
10. O cliente vai embora com as mercadorias ou serviços prestados.
Cenários alternativos ou fluxos alternativos
	Fluxo alternativos são aqueles que independente da ação humana podem acontecer, fora do fluxo principal, iremos demonstra com o exemplo visto anteriormente conforme o autor Craig Larman demonstra um fluxo que apresenta várias possibilidades, que devem ser consideradas, podemos observar que cada cenário recebe um número indicando o sucesso e posteriormente o insucesso que ficará indicado com uma letra e número que servirá para indicar a ordem que o sistema recebera informações para as possíveis soluções as situações que surgem, vejamos abaixo um trecho do caso demonstrado por Craig Larman.
	
A. A qualquer momento o caixa solicita suporte ao gerente
1. O sistema entra o modo de autorização pelo gerente.
2. O gerente ou o caixa realiza a operação do modo gerente, por exemplo cancelar cupom, cancelar item, fazer sangria.
3. O sistema volta ao fluxo normal.
B. A Qualquer momento o sistema pode falhar.
Para garantir a integridade das informações é necessário que seja possível a sua recuperação que estavam sendo trabalhadas no momento da operação por exemplo emissão do cupom, transação com cartão de crédito.
1. O caixa reinicia o sistema, registra e solicita a recuperação do estado anterior.
2. Sistema retorna à situação anterior.
2a. Sistema detecta uma situação atípica que impossibilitara a recuperação
1. O sistema avisa o caixa, registra o erro e entra em um estado novo consistente.
2. O operador começa um novo processo.
1a. O cliente ou o gerente solicitam a retomada da venda suspensa.
1. O operador inicia uma operação de retomada e insere uma informação que possibilita a recuperação.
2. O sistema mostra a venda retomada no atual estado da falha com as informações recuperadas.
2a. Venda não encontrada.
1. Sistema avisa ao operado sobre o erro.
2. O operador reinicia uma nova venda do começo realizando as etapas 1,2,3,4.
 	Conforme Craig Larman demonstra as extensões ou fluxo alternativos, são basicamente um caminho que o sistema terá de oferece aos atores no caso de uso, em que situação atípicas apareçam em alguma etapa das funções convencionais do sistema, caso alguma dessas situações ocorram fica dito que o sistema deverá oferecer, uma alternativas para os atores continuarem a utilizar o sistema e prosseguir com o fluxo do sistema.
	Embora o caso demonstrado não seja real o mesmo exemplificar como devemos proceder, levando em consideração que na fase de levantamento de requisitos podemos identificar esses cenário junto aos usuários, que possivelmente tem um domínio maior daquilo que precisa ser modelado, situações que não sejam identificadasnessas etapas podem gerar inconsistências funcionais se não forem consideradas, tornando assim o sistema algo de pouca credibilidade nas informações que serão produzidas.
Requisitos especiais
	
	Conforme o gabarito o autor Craig Larman sugeriu uma tela sensível ao toque para o uso dos atores, podemos entender que esses requisitos agregarão usabilidade ao sistema. 
1. Interface sensível ao toque, em um monitor de tela plana.
2. Resposta á autorizações de crédito dentro de 30 segundos.
3. De alguma forma queremos a recuperação robusta, quanto ao acesso de informações do estoque.
4. Opções de idiomas a linguagem do texto exibida.
5. Regras de negócios plugáveis.
Listas de Vantagens tecnológicas e de dados
	
	No gabarito fornecido esta etapa demostra os aparatos que podem torna o sistema mais eficiente com o auxílio de tecnologias atuas vejamos o que Craig Larman cita em seu exemplo.
	-Correção através da passagem de um cartão em uma leitora ou inserindo um código de autorização através do teclado.
	-Uma leitora a laser que identifica os itens passando o código de barras.
Frequência de ocorrência: Poderia ser quase contínuo.
Diversos
	São situações que devem ser consideradas pois as mesmas podem ser de uso relevante, Craig Larman cita, leis de impostos, recuperação de serviços remotos, a forma que o dinheiro em espécie deve ser manipulado dentre outras.
Sobre especificações
 	 A uml não relata nada a respeito de especificações textuais do caso de uso, ficando limitado aos diagramas de caso de uso, porem as especificações são de uso relevante para o entendimento dos requisitos, facilitando assim a implementação do serviços em código, vale ressaltar que esta metodologia não é a única disponível, entretanto por apresentar uma eficiência na sua construção pode ser usada seguramente que poderemos obter bons resultados.
Linguagem unificada de modelagem UML 
	
	A UML é uma ferramenta visual considerada como uma linguagem de modelagem, muito utilizada na orientação a objeto, serve para um propósito geral que se aplica em todos os domínios do software, tornado no últimos anos uma linguagem padrão para desenvolvedores, o autor diz que T.A Guedes, Gillesnes (2009, p.3) “Deve ficar bem claro, porém, que a UML não é uma linguagem de programação, e sim uma linguagem de modelagem, uma notação, cujo objetivo é auxiliar os engenheiros de software a definirem as características do sistema”, fica claro na observação do autor a utilização como ferramenta de auxílio ao desenvolvedores.
	Atualmente reconhecido por uma grande parcela dos desenvolvedores, a UML é um dos diagramas de maior ênfase na programação orientada a objeto, diversos autores indicam que a modelagem de sistemas é uma etapa fundamental para o sucesso de sistemas simples e complexos conforme T.A Guedes, Gillesnes (2009, p.21)” todo e qualquer sistema deve ser modelado antes de se iniciar sua implementação, entre outras coisas, porque os sistemas de informação frequentemente costumam ter a propriedade de “crescer”, isto é, aumentar em tamanho, complexidade e abrangência.”, isso implica que modelar tornasse uma boa pratica no trabalho de construir softwares.
Diagrama de classe
	Por muitos é considerado um dos mais importantes diagramas da UML o mesmo possui vários níveis de diagramas, conforme o autor diz T.A Guedes, Gillesnes (2009, p.21)” Serve de apoio para a maioria dos demais diagramas. Como o próprio nome diz, define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos que cada classe tem”, tudo isso partido do princípio que ouve uma abstração do muito real para a UML, denotando como as classes interagem entre si e trocam informações.
	Sua finalidade principal é demonstrar graficamente os tipos de objetos que interagem com o objetivo de realizar um determinada tarefa prevista para um sistema, BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.159) “Um diagrama de classes mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos.”, conforme o autor descreve o diagrama de classe é basicamente o desenho das classes do software, seus relacionamentos, restrições, objetivos do sistema.
	Existem dois tipos de classe que são consideradas as principais são elas, classe de fronteira (Boundary) ou interface que é responsável pela interação dos atores e classe de controle que é responsável pela coordenação dos objetos nas interações de como interagem na realização de um caso de uso.
Diagrama de classes de implementação
	Durante as fase de implementação (momento em está sendo programando na linguagem escolhida) podem surgi alterações, sejam elas por parte do clientes ou por modificações técnicas (requisitos ou características da linguagem), nesta circunstância usamos o diagrama de implementação, embora possuindo uma nomenclatura diferente, o diagrama de classe é único, que irá modificando-se além do estado inicial sendo acrescentadas, as novas funcionalidades ou as alterações que poderão ser feitas.
Classes	
	Como o princípio para a criação, de diagramas o paço inicial será desenvolvermos a capacidade de abstração do mundo real, classes são basicamente isso, conforme BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.97) ” Uma classe é uma abstração de itens que fazem parte de seu vocabulário. A classe não é um objeto individual, mas representa um conjunto inteiro de objetos.”, a definição abstrata destes objetos é convertida em atributos e posteriormente em classes que, irão adquirindo os seus respetivos valores ao decorrer da modelagem.
	São representados graficamente na UML por um retângulo que irá conter, três partes que irão transmitir de forma visual a denominação da classe, os dados que serão retidos na classe e as operações que está classe irá realizar, vejamos abaixo um exemplo de classe onde iremos simular uma classe, que receberá a denominação de ‘Cliente’, os dados que irão ser retidos são ‘Nome’, ‘Matricula’, e as operações que irão realizar ou os métodos que devem ser programados que serão os seguintes ‘Cria()’, ‘Destruir()’, ‘Incluir()’ agora vejamos a representa gráfica deste modelo.
	
Classe e objeto	
	
	Classes são basicamente modelos que serão usados para processar informações me massa, como na figura acima podemos entender que a classe, cliente serve para implementar várias pessoas na sua forma que foi criada, já objetos trata-se de uma instancia de uma classe ou o objeto é claramente o que precisa ser trabalhado para o sistema obter, os resultados específicos, basicamente modelamos em busca das classes e não por objetos vejamos como ficaria na figura abaixo.
Diagrama de classes e seus elementos 
	São constantemente encontrados com maior frequência na modelagem orientada a objeto, mostra o conjunto de classes, interfaces, colaboração e relacionamentos podemos usar o diagrama de classes para fazer a modelagem de visão do projeto de um sistema, na maioria dos casos isso necessita da modelagem dos vocabulários, colaboração e a modelagem de esquemas. 
	Como os diagramas podem servir para um variedade maior de diagramas, podemos considera, que dar uma devida atenção para esta etapa poderá trazer bons resultados ao desenvolvimento do sistema conforme BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.175) dizem os autores.
“Os diagramas de classes também são a base para um par de diagramas relacionados: os diagramas de componentes e os diagramas de implantação. Os diagramas de classes são importantes não só para a visualização, a especificação e a documentação de modelos estruturais, mas também para a construção de sistemas executáveis por intermédio de engenharia direta e reversa.”
	Conforme o auto demonstra devemos atentar as etapas pois a partir deste ponto, poderemos perder informações críticas que tornarão mais praticas a implementação, ou caso haja negligência com que os requisitos não sejam cumpridos, tornando assim o processo de desenvolvimento cheio de erros e falhas.
	Vejamos a seguir os elementos básicos que compões os diagramas de classes na figura abaixo:
	
Fonte: Figura retirada do livro UMLGuia do usuário, de BOOCH,G.; JACOBOSN,I.;RUBAUCH,J. 2ª edição.
	Conforme a figura demonstra o diagrama de classes possui os seguintes elementos básicos, classes com atributos e operações (métodos), relacionamentos entre classes, multiplicidade de elementos, visibilidade de atributos e métodos, nome dos relacionamentos e seus papeis, navegabilidade nos relacionamentos, notas e comentários.
Atributos e operações
	Podemos definir atributos como á um conjunto de características que irá fazer, parte do diagrama, sendo assim podemos exemplificar, que se quisermos modelas os atributos de um objeto chamado carro, devemos atentar á aquilo que precisara ser trabalhado por exemplo, cor, modelo, fabricante, número do chassi, número de portas essas características, devem ser identificadas primordialmente na fase de levantamento de requisitos.
	O conceito de atributos visa descrever as propriedades estruturais da classe com os dados relevantes que devemos armazenar existe uma forma mínima para representar um atributo na UML que é da seguinte forma. Dentro de um retângulo, com os seguintes campos que exibirão graficamente as características, visibilidade Nome: tipo.
	Visibilidade segundo BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.199), “os atributos e operações de um classificador é a sua visibilidade. A visibilidade de uma característica especifica se ela pode ser utilizada por outros classificadores.”, sendo que essa característica é fundamental para que no momento de codificar as características da linguagem sejam devidamente aplicadas, na UML é possível aplicar quatro tipos de visibilidades, public(+) denotado pelo sinal de mais, protected(#)denotado pelo asterisco, private(-)denotado pelo sinal de menos, package(~) denotado pelo sinal de til.
	Nome é o qual iremos chamar o atributo sendo que, está diretamente relacionado com as características do atributo, devemos manter sempre esses nomes diretamente atrelados aos objetos para facilitar seu entendimento e codificação.
	Tipo do atributo é basicamente as variáveis que podem ser trabalhadas na codificação, cada linguagem possui seus tipos, podem ser números, letras em exemplo que podemos citar caso, precisemos trabalhar com nome podemos usar o tipo String, caso precisemos trabalhar com números podemos usar int, float etc lembrado que os tipos devem ser atentado para a linguagem que vamos usar pois cada linguagem pode implementar de formas diferente suas sintaxes.
	Operações são apresentadas como uma coleção de funções que conforme BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.53), “Uma interface é uma coleção de operações que especificam serviços de uma classe ou componente. Portanto, uma interface descreve o comportamento externamente visível desse elemento”, assim sendo poderá apresentar o comportamento de uma classe ou componente. 
	Vejamos abaixo uma representação gráfica de um objeto com os aspectos citados acima.
	
Métodos
	Podemos definir métodos como um conjunto de operações ou comportamentos que uma classe fornece, criar, excluir, alterar, atualizar são exemplos de métodos conforme BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.249) .
	“Uma interface especifica o contrato para uma classe ou componente sem determinar sua implementação. Uma classe ou componente poderá realizar várias interfaces. Nesse caso, a classe ou o componente se compromete a executar fielmente todos esses contratos, o que significa que é fornecido um conjunto de métodos capazes de implementar adequadamente as operações definidas na interface.”
	Conforme o autor diz podemos concluir que métodos serão tarefas que as classes irão realizar durante o ciclo de processamento para a obtenção de um resultado, que irá ser destinado à uma saída, como uma informação numa tela, armazenar em um baco de dados, processamento de um cálculo, são muitas as possibilidade vejamos abaixo na demonstração gráfica que os métodos Cria, Excluir, Atualizar, Alterar são os métodos da classe aluno e irão realizar as respectivas tarefar citadas.
	
Associação entre classes.
	
	O conceito de associação, são basicamente a forma que essas classes interagem entre si podendo haver, uma relação entre duas ou mais classes não distintas é não correlacionada e independente, sempre ao final deste relacionamento as classes retornam para sua forma anterior, o tipo de associação mais comum é que existe entre duas classes chamado de binário, sua representação gráfica é feita através de uma linha solida que conecta as classes, existem outros tipos de associações que serão demonstrados mais adiante, vejamos uma representação gráfica de uma associação binário.
 
Tipos de associações entre classes
	As associações podem ocorrer na mesma classe com a denominação de auto associação ou associação unária, neste tipo de associação o a relação é pré-requisito, a outra classe, é possível também o relacionamento entre três ou mais classes entretendo são de uma certa dificuldade encontra-las em cenários reais.
	Associação exclusiva são restrições entre uma ou mais associações, indicando o objeto de uma determinada classe pode participar de no máximo uma das associações no momento é representado por uma linha tracejada entre as associações com a especificação {ou} demonstrando o relacionamento é exclusivo a somente duas classes.
	
Multiplicidade nos relacionamentos
	Uma forma bem simples de entendermos o conceito de multiplicidade nos relacionamentos é conseguimos visualizar é conseguirmos indicar quantos objetos podem estar envolvidos em uma relação os autores definem da seguinte forma multiplicidade BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.121) ” é importante determinar a quantidade de objetos que podem ser conectados pela instância de uma associação. Essa “quantidade” é chamada de multiplicidade”, vamos visualizar de forma gráfica esse somente assim iremos facilitar o entendimento do conceito de multiplicidade.
	Vamos analisar este diagrama, podemos observar que o cliente pode realizar nenhum ou vários pedidos observe que o pedido somente pode pertencer a um cliente, sempre devemos realiza a analisa de um lado de cada vez sempre seguido uma ordem.
Possibilidade e significados das multiplicidades
	Multiplicidade
	Significado
	1 
	Exatamente 1
	1.. *
	Um ou vários “muitos”
	0.. *
	Nenhum ou muitos
	*
	Muitos; a leitura é zero ou vários “muitos”
	0..1
	Nenhum ou um
	m..n
	Faixa de valores ex: 1 a 5 ou 9 a 10
Visibilidade de atributos e métodos
	A visibilidade de um atributo ou métodos diz respeito á forma que podem ser utilizados por outras classes, visibilidade pode ser dividida em quatro tipos público, privado, protegido e pacote representados por +, -, # e ~ respectivamente, conforme é explicado pelos autores BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.199), as seguintes definições abaixo são aplicadas.
“1. público qualquer classificador externo com visibilidade para que determinado classificador seja capaz de usar a característica;
especificado por ser antecedido pelo símbolo +. 
2. protegido qualquer descendente do classificador é capaz de usar a característica; especificado por ser antecedido pelo símbolo #.
 3. privado somente o próprio classificador é capaz de usar a característica; especificado por ser antecedido pelo símbolo –. 
4. pacote somente classificadores declarados no mesmo pacote podem usar a característica; especificado por ser antecedido pelo símbolo ~.”
	
	Essas visibilidades podem ser combinadas de acordo com as necessidades, encontradas na fase de levantamento de requisitos, ficam esses critérios a cargo das equipes de desenvolvimentos, outra característica muito importante para um desenvolvimento de diagramas de classes é a forma com que a UML atende a semântica das linguagem de programação conforme BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.199)”A propriedade de visibilidade da UML atende à semântica comum à maioria das linguagens de programação, incluindo C++, Java, Ada e Eiffel. Entretanto, observe que as linguagens distinguem-se ligeiramente em sua semântica de visibilidade.”, tornado desta formauma característica de grande importância nos critérios de modelagem, vejamos abaixo uma ilustração. 
	Devemos atentar sobre um princípio básicos da orientação a objetos, chamado encapsulamento, que diz o seguinte os atributos de uma classe não podem ser utilizados por outra classe e sim por métodos próprios da classe, sendo assim os atributos devem ser classificados como visibilidade tipo privada, sobre os métodos, métodos podem prestar serviços á outra classes desta forma recebem a sua visibilidade publica, num relacionamento tipo generalização ou especialização esses atributos ou métodos que venham a ser herdados pela classe especialização recebem a visibilidade protegida na classe principal.
	
Tipos de relacionamentos 	
	Associação é o tipo de relacionamento que consiste na interação entre duas classes que pode surgir uma no classe desta relação por exemplo, um cliente com seus respectivos atributo e decide alugar um veículo que possuirá seus atributos, desta relação surgira a classe aluguel que possuirá seu atributos e métodos próprios vejamos a ilustração gráfica abaixo, onde o relacionamento é demonstrado pela linha tracejada.
	
	Generalização/especialização com um forte conceito atrelado á orientação objeto, trata do relacionamento entre classes que implementa o conceito de herança, onde uma classe de uso mais geral relaciona-se com uma mais especifica, onde a classe mais especifica recebe através da visibilidade de atributos e métodos, que foram permitidas recebendo assim o nome de super classe e a classe mais especifica o nome de sub- classe, os autores BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.354), definem o conceito de generalização da seguinte forma.
”a generalização significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai; o filho deverá acrescentar ou sobrescrever o comportamento de seu pai; e o filho poderá ser substituído em qualquer local no qual o pai apareça (ambos, o pai e o filho poderão ter instâncias concretas. ”
	Desta forma como os autores definem chegamos ao conceito de herança que conforme descrito pode ser entendido que uma classe deixa seus atributo e métodos disponíveis através da visibilidade para ser usada por outras classes, esse tipo de relação é representado graficamente por uma seta que aponta para a classe mais geral vejamos abaixo uma representação gráfica de uma classe com generalização/especialização.
	
	Existe uma característica que devemos considerar chamada de generalização completa e incompleta, completa significa que todas as classes e subclasses já foram instanciadas desta forma não haverá mais a possibilidade de nenhuma outra forma de generalização e a incompleta é exatamente o contrário dos padrões da uml.
	
Diferença entre agregação e composição
	Um dos pontos mais controversos na modelagem de classes, são as agregações e composições eles são do tipo “todo-parte”, existe uma classe que define o todo e outra que define a parte, tornado assim estas definições uns pouco difíceis de ser diferenciada.
	Composição são relacionamentos mais fortes onde são possíveis prever as seguintes características, toda classe pode um componente de muitas outras classes mas toda instancia pode ser somente de um componente, possui cardinalidade de 1 para o objeto todo, quando o objeto for excluído todas as outra parte também devem ser excluídas, conforme os autores dizem BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.233).
“A composição é uma forma de agregação, com propriedade bem definida e tempo de vida coincidente como parte do todo. As partes sem multiplicidade fixada podem ser criadas após a composição, mas, uma vez criadas, vivem e morrem com ela. Essas partes também podem ser removidas explicitamente antes da morte do objeto composto.”
	Conforme dito pelos autores o conceito de composição fica ligado diretamente a existências do todo assim sendo a vida do todo coincide com o todo, a representação gráfica da composição é feita com um losango preenchido de preto e ele deve ficar posicionado ao lado do objeto vejamos abaixo um exemplo.
	O objeto parte (item) não pertence ao todo pois aquele item é exclusivamente daquele pedido, assim conforme a característica da composição quando o pedido deixar de existir não há mais a necessidade o item existir assim sento ele morre junto com a classe pedido.
	Assim quando houve a constatação destas característica podemos afirmar que este relacionamento é uma composição de acordo com os autores BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.233). “Isso significa que, em uma agregação composta, um objeto poderá ser uma parte de somente uma composição em determinado momento. “, com está condição satisfeita chegamos ao entendimento que se está condição for possível, identificaremos uma composição.
	Agora a agregação possui, duas características que se não forem identificadas como a anterior estamos diante de uma agregação, ou seja, a definição da agregação depende da análise e caso não seja identificada uma composição, chegaremos a conclusão que é uma agregação conforme os atores BOOCH,G.; JACOBSON,I.;RUBAUCH,J.;(2012,p.122).
“O significado dessa forma simples de agregação é inteiramente conceitual. O diamante aberto diferencia o “todo” da “parte” e nada mais. Isso significa que essa agregação simples não altera o significado da navegação pela associação entre o todo e suas partes, nem está vinculada ao período de vida do todo e de suas partes.”
	Sua representação gráfica, é feita com um losango sem preenchimento de cor ao lado do objeto todo, vejamos abaixo uma ilustração gráfica da agregação.
	Analisando estas classes chegamos a seguinte conclusão o objeto questão pode pertencer a mais de uma avalição ou seja a mais de um todo, quando a avalição deixar de existir as questões podem continuar a existir para serem utilizadas em outras avaliações, assim já que não identificamos nenhuma das características como verdadeiras concluirmos que o relacionamento trata-se de uma agregação.
Dependência
	Uma dependência trata-se de um relacionamento de utilização, quando duas classes que interagem entre si, na forma de alteração da definição da outra classe, desta forma uma classe pode conter dados de outra classe, ou chama os métodos de outra classe. 
“Uma dependência é um relacionamento de utilização, determinando que um item (por exemplo, a classe Janela) usa as informações e os serviços de outro item (por exemplo, a classe Evento), mas não necessariamente o inverso. A dependência é representada graficamente como linhas tracejadas apontando o item do qual o outro depende. Use as dependências sempre que quiser indicar algum item dependendo de outro. BOOCH, G.; JACOBSON ,I.;RUBAUCH, J.;(2012,p.126).”
	Conforme os autores definem as dependências são determinadas por itens como a classe janela dita pelo autor que usa os serviços de outra classe, esses serviços podem ser os atributos ou métodos sempre levamos em consideração quando estamos abordando uma dependência, a visibilidade e os paramentos da linguagem que está sendo utilizada.
	Na uml devemos ser seletivos ao modelar dependências, devemos considerar seu uso somente quando for relevante no contexto da modelagem, seu uso mais comum é nas dependências de relacionamentos transitórios vejamos a seguir a ilustração gráfica deste tipo de relacionamento.
Nome e papel de um relacionamento
	O nome de um relacionamento refere-se a função na qual o mesmo desempenha na ilustração gráfica da uml, de forma didática facilita no entendimento do diagrama, assim sendo como toda classe pode possuir algum tipo de relacionamento, sendo representado por uma seta que indica sua função onde a função é descrita através de um verbo que deve expressar sua ação dentro do relacionamento, seu uso é opcional entretendo, para facilitar o entendimento dos diagramas por terceiro é recomendável usar esta técnica vejamos abaixo sua representação gráfica. 
Navegabilidade nos relacionamentos
 	
	Visando mostrar o sentido das interações e navegação, podemos identificar este tipo de navegaçãoquando analisamos as classes e podemos observar as interações que existem, com essa observação feita, podemos apontar como um objeto se comunica com outro ou envia uma mensagem, desta forma é indicado por uma seta que aponta a direção da comunicação e sua navegação.
Notas e comentários nos diagramas
	Notas ou comentários que podem ser usados em qualquer parte dos diagramas, são isolados entre si, não possuem vínculos estruturais, são ligados aos diagramas através de uma linha tracejada até o elemento que está sendo comentado ou recebendo a nota, a figura abaixo demonstra o uso das notas ou comentário.
Conclusão
	Dentro do contexto econômico tecnológico, softwares apresentam um grande diferencial na forma que interagimos com os diversos segmentos da sociedade, o presente artigo identifica as principais características destes aspectos, demonstrando o uso de técnicas e apresentando as metodologias que podem proporcionar um desenvolvimento mais pratico e eficiente, assim certamente os desenvolvedores que usam essas técnicas, podem proporcionar um desenvolvimento mais eficiente no seu dia-a-dia e produzir sistemas computacionais mais passivos de funcionalidades que cumpra os requisitos solicitados, evitando assim, que sistemas que serão postos em produção contribuam significativamente, para aquilo que foram propostos. 
	
Bibliografia
BEZERRA, Eduardo. Princípios de análise e projetos de sistemas com UML. 2. ed. Rio de Janeiro: Campus, 2006.
BOOCH, G.; JACOBSON , I.;RUBAUCH, J. UML: guia do usuário. 2. ed. Rio de Janeiro: Campus, 2006.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objeto e ao desenvolvimento interativo. 3. ed. São Paulo: Bookman, 2008.
Vandeilson Menezes da Silva Pós-graduação em engenharia de software Universidade Estácio de Sá. E-mail vandeilsonmenezesdasilva@gmail.com .