Modelagem de Software com UML - Uma Introdução

Olá sejam bem-vindos ao canal engenheiria de software com ênfase uml meu nome é julianes Guedes e eu criei esse canal para falar sobre assuntos relacionados à área de engenharia de software principalmente assuntos relativos à modelagem do software com a linguagem uml mas também assuntos relacionados como engenhe requisitos projeto de software e verificação e validação eu já trabalho com modelagem de software com ml há vários anos Eu tenho quatro livros publicados na área eu já ministrei diversas palestras de cursos sobre como modelar software por meio da linguagem uml então nesta primeira aula eu pretendo introduzir a

linguagem uml apresentar Quais são as suas características onde ela é aplicada falar um pouquinho sobre requisitos um pouquinho sobre projeto de software falar um pouquinho sobre o que é necessário modelar software em suma dá uma introdução sobre a e ela é aplicada porque ela deve ser aplicada Então vamos iniciar a nossa primeira aula então ã o ml significa unified Modern language ou linguagem de modelagem unificada ah como eu falei eu já publiquei quatro livros sobre o mrl o meu primeiro livro foi o m uma abordagem prática que tratava na época sobre m 1.5 mas que

já incluí a ml2 estava surgindo na época ah depois eu criei o guia de consulta rápida que era exclusivo sobre ml2 alguns anos depois eu aumentei esse guia transformei em um livro maior eu chamei de ml2 via prática e depois eu lancei o meu livro principal que eu considero mais completo mais importante Meu Carro Chefe por assim dizer que é que é o MR2 uma abordagem prática que já se encontra na terceira Edição e eu já estou trabalhando na quarta Edição Mas vamos deixar de propaganda e vamos direto ao assunto então como eu falei o

ML é aura de unified Modern language ou linguagem modá unificada essa é uma linguagem visual utilizada para moderar softwares que se baseiam no paradigma de orientação objetos essa linguagem ela é a linguagem padrão adotada internacionalmente tanto pela indústria como pela academia atuantes na engenheria de software então praticamente qualquer modelo de software qualquer projeto de software utiliza a linguagem ml a maioria seão todas as ferramentas cas suportam a linguagem M sendo essa uma das suas principais características então a uml é utilizada para diversas funções da engenharia quisitos e no projeto de software Então ela serve para

auxiliar e compreender várias características do software tais como seus requisitos a estrutura lógica a dinâmica de seus processos como seus processos irão se comportar e até mesmo as necessidades físicas em termos de hardware quando o software precisa ser distribuído entre diversos servidores e é necessári determinar quais servidores estarão executando quais móvel do software Então como resumo o objetivo do ML é auxiliar engenheiros do software a analisar e projetar software antes que ele venha a ser efetivamente codificado Fala um pouquinho sobre histórico da uml a uml ela foi o resultado da União dos Três métodos mais

utilizados na metade da década de 1990 que era o m Bush o método omt que significa OB mod technic ou técnica de modelagem de objetos do IV jacobson e o método US que significa objet orienta de soft lí uma engenheria de soft orientada a objetos do James ral bom então ah a Rational software uma empresa na época resolveu criar uma linguagem padrão porque haviam diversos lingu de linguagem de modelagem então padrões diferentes isso atrapalhava um pouco a comunicação de projetos quando o profissional ia para outra empresa esse tipo de coisa então eles inicialmente contrataram o

Bush e o jacobson para unir os seus métodos isso gerou o método Unificado no final da déc no final do de 1995 e depois o rambal ele passou Air o método o uso dele a essa nova linguagem E isso gerou a primeira versão do ML em 1996 em 1997 a oml ela foi adotada pela OMG que significa Object Management group com uma linguagem padrão de modelagem a OMG Então ela é uma instituição que gerencia diversos padrões entre eles a uml atualmente a linguagem uml se encontra na versão do P 5.1 e toda a documentação oficial

da linguagem pode ser consultada no sites da omg.org ou no site da uml.org Inclusive a documentação das versões anteriores eu vou falar um pouquinho sobre engenharia de requisitos na minha opinião a engenharia de requisitos é a fase mais importante da engenharia de software é a fase mais essencial porque ela define o problema o que precisa ser feito a a palavra chave da engenharia de requisitos é o que nós precisamos compreender o problema bem compreendido para depois estabelecer uma solução para ele então não é possível determinar uma solução para um problema sem que o sem que

o problema em si tenha sido compreendido corretamente caso contrário vai se desenvolver algo que não satisfará as necessidades do cliente depois existe a fase do projeto na fase do projeto a palavra chave é o como a fase do projeto ela já se preocupa em determinar como o problema vai ser vai ser solucionado então ela tenta satisfazer os requisitos que foram identificados durante a fase de engenharia de requisitos Então primeiramente durante o projeto se define a arquitetura do software de tal maneira que ela venha satisfazer os requisitos não funcionais que foram identificados na fase anterior na

engenharia de requisitos nós determinamos Quais são os requisitos funcionais e não funcionais do software requisitos funcionais se referem as funcionalidades que o software precisa atender ou seja as funções e serviços que o software precisa oferecer enquanto que os requisitos não funcionais eles se referem a características gerais do sistema Como por exemplo o seu nível de desempenho Ah o seu nível de confiabilidade seu nível de manutenibilidade o seu nível de escalabilidade reusabilidade proteção segurança usabilidade etc então uma vez que os requisitos não funcionais foram identificados existe uma etapa intermediária entre Engenharia de requisitos e o projeto

software onde se estabelece a arquitetura como os requisitos não funcionais serão satisfeitos então uma arquitetura ela estabelece a estrutura Geral do sistema e a partir dessa estrutura geral os módulos do sistema serão organizados logicamente a arquitetura ela tem que ser feita com muita seriedade porque custa muito caro modificar a arquitetura mesmo em se tratando de métodos ágeis em que as mudanças são bem-vindas no caso da arquitetura de software ela tem que ser quase que totalmente definida antes de se passar a enfocar ciclos de de requisitos ciclos interativos e incrementais como acontece nos métodos ágeis por

quê Porque modificar a arquitetura é muito caro e pode fazer com que todo o projeto tenha que ser modificado após definir a arquitetura é definido como as funcion idades vão se comportar por meio de mais de um ou mais modelos ou visões de maneira a satisfazer os requisitos funcionais ou seja as funções que o software deve oferecer as suas funcionalidades Ah também vai estabelecer como essas funcionalidades serão distribuídas entre os diversos componentes do soft e como as componentes estarão alocados serão organizados dentro da arquitetura do sistema bom mas Por que nós devemos modelar software Qual

é a real necessidade de se modelar software H gente que diz que modelar software É desnecessário que é perda de tempo que simplesmente não fazem esse tipo de coisa Ah tem gente que muitos profissionais dizem que partem direto pro código eles nunca precisaram fazer projeto nunca precisaram fazer Engenheiro pitos nunca precisa modelar software eles fazem no máximo algumas entrevistas com os clientes e partem para cifica tem muitos profissionais que fazem isso agora qual é a real necessidade de se projetar uma casa um pedreiro ele é capaz de construir uma casa sem um projeto em alguns

casos sim ah mas vocês se arriscariam a morar em uma casa construída desse jeito Tem gente que se arrisca bom pode acontecer a casa ter sido mal ída que ela tenha sido mal calculada que ela apresente problemas estruturais que ela Rache ou que venha até mesmo a cair agora vamos supor que vocês vão se mudar para um prédio de vários andares você se arriscaria uma morar um prédio que foi construído sem um projeto bom da mesma forma que a casa o prédio pode apresentar problemas estruturais só que se ele cair o risco é um pouco

maior pouca coisa para se construir um edifício e é preciso criar um projeto muito bem elaborado com cálculos exatos corretos para evitar que haja Fes estruturais no edifício e que isso venha a prejudicar as vidas humanas o ideal é o construir o edifício que ele dure muitas décadas Se for possível até mais então durante um projeto de um Edifício vai se escolher o local onde o prédio será erguido vão se produzir diversos tipos de planta como planta baixa planta elétrica planta hidráulica vai se conhecer uma Estimativa de custos vamos determinar em quanto tempo a construção

vai estar concluída quantas pessoas precisarão trabalhar naquela construção Qual a quantidade de Material necessário para construir o prédio esse tipo de coisa o objetivo disso é garantir que a complexidade real da da obra tenha sido bem compreendida e para determinar Como aquela obra vai ser solucionada como aquele problema vai ser solucionado então ah por analogia é mais ou menos a o mesmo motivo pelo qual eh se modela software nós modelamos software para ter certeza que nós compreendemos corretamente o problema que nós conseguimos compreender corretamente a complexidade do problema que nós devemos solucion então nós modelamos

software para compreender corretamente o que precisa ser feito para entender os requisitos do software para compreender a complexidade do que preca ser desenvolvido para diminuir a possibilidade que ocorram erros ao longo do projeto nós modelamos software Por uma questão de documentação de maneira que isso possa nos auxiliar a manter o software de maneira correta E que nos permita reutilizar código em nossos projetos entre outras razões então desenvolver software partindo direto pro código ele agrega um risco bastante alto eh porque muitas vezes a complexidade do software é maior do que havia sido prevista eh em um

primeiro momento e no momento que se descobre que o software é mais complexo do que você havia sido previsto ou ainda no momento que se descobre que as necessidades do do software não foram Compridas corretamente isso acarreta grandes problemas do meu projeto AC carreta atrasos e a carrega e a carreta no desgaste do meu código Como assim meu código vai sofrer desgaste ele vai sofrer desgaste na medida que ele for sendo alterado diversas vezes para se adaptar as mudanças relacionadas aos erros de projeto que haviam sido feitos anteriormente Então vai chegar um momento em que

o software vai est est vai S modificado tantas vezes vai estar tão remendado que não vai valer a pena mais mantê-lo é melhor jogar fora e criar uma versão nova É Assim que o sof se desgasta Ok então projetos de softare eles não podem na maioria das vezes não é possível mesmo serem moderados de cabeça mesmo que eles sejam bastante simples porque na verdade não existe software simples tá todo software carrega uma certa complexidade e os softwares eles possuem a característica de crescerem Eles começam pequenos Mas eles vão evoluindo eles vão aumentando em tamanho em

complexidade e abrangência ah alguns profissionais até afirmam que os software são vivos porque eles nunca estão finalizados completamente o Tero mais correto seria que eles são dinâmicos porque eh eles estão em constante mudança estão em constante evolução e isso se deve porque as empresas elas precisam ser dinâmicas para serem competitivas elas precisam estar constantemente se adaptando ao mercado se adaptando às novas necessidades dos seus clientes investindo em novos lixos de mercado e se adaptando às mudanças impostas pelos governos e Como as empresas elas são muito dependentes de software hoje em dia o software precisa se

adaptar da do mesmo nível de ao mesmo nível de dinamismo então um software ele precisa ser documentado ele precisa ter uma documentação precisa e atualizada para que ele possa ser mantido para que ele possa ser evoluído com facilidade rapidez e correção sem produzir novos erros a coros antigos porque acontece muito de se dá manutenção no software e o que já está funcionando anteriormente passa a apresentar erros então A modelagem de software ela permite documentar o software em questão mas ela não serve somente para isso a documentação e Por conseguinte a sua facilidade em manter o

software é apenas uma das vantagens fornecidas pela modelagem A modelagem ela também seria compreender e executar diversas atividades complexas entre elas a análise especificação de requisitos o obeto de software e a reutilização de código de componentes bom vou explicar um pouquinho o que é o modelo de software nós estamos falando de modelagem de software para lá modelagem de software para cá mas o que é o modelo de software o modelo de software ele é uma visão de um sistema físico é uma abstração do sistema com um determinado propósito que pode ser o de descrever aspectos

estruturais ou aspectos comportamentais do software esse propósito iria irá determinar o que precisa ser incluído no modelo e o que não deve ser incluído nesse modelo O que é considerado irrelevante então o modelo ele vai descrever completamente os aspectos do sistema físico que são importantes para o proposto do modelo naquele nível apropriado de detalhe então de acordo com babo o modelo é qualquer representação simplificada de uma realidade complexa sendo útil para compreensão e tomar de decisão no contexto dessa realidade modelos eles podem ser tanto textuais como gráficos ou uma combinação das duas formas modelos gráficos

em geral são chamados diagramas e a oml produz diversos diagramas Então os modelos eles são uma simplificação do mundo real o seu objetivo é nos ajudar a compreender e resolver o problema em questão então eles facilita a compreensão do problema diminui a sua complexidade no momento que eles trabalham com o conceito de dividir para conquistar Então se existe um problema difícil um problema complexo passamos a enfocar apenas uma faceta deles resolvemos aquela faceta depois nós pegamos uma outra faceta um outro aspecto daquele daquele software resolvemos E aí nós unimos tudo para ter a solução do

problema completo é mais ou menos como se o que se faz quando se eh conem prévios Se produzem diversas plantas cada uma enfocando um aspecto específico então uma planta hidráulica vai eh enfocar somente questão de do encanamento do prédio uma planta elétrica somente a questão da Fiação e assim vai depois se une tudo então modelos de software eles demonstram uma maneira de solucionar o problema são uma forma de documentar o projeto e as decisões que foram tomadas durante a busca pela solução eu vou dar alguns exemplos de modelos de software eu posso criar modelos de

caso de uso posso criar modelos de classe conceituais modelos de classe de domínio posso criar modelos de interação entre outros modelos então o modelo de caso de uso na uml ele apresenta uma visão de Quais são os requisitos necessários do sistema ou seja Quais são as as suas funcionalidades e quem pode utilizá-las somente isso já o modelo de classe conceitual ele vai identificar Quais são as classes relacionadas ao domínio do problema ou seja as suas classe de entidade sem se preocupar em questões H relacionadas à solução como os métodos das classes Isso já é tarefa

da fase de projeto identificado o modelo de classe de domínio já é uma evolução do modelo de classe conceitual que é produzido durante a fase de projeto envolve várias questões relacionadas à solução do problema como por exemplo os métodos Ahã então a escolha de quais modelos devem ser desenvolvidos vai influenciar na forma como o problema vai ser solucionado então em geral o único tipo de modelo ele é insuficiente para solucionar o problema em geral é necessário criar vários modelos com enfoques diferentes de maneira que eles abordem problemas sobre ótica sobre facetas diferentes e se complementem

agora a uml ela possui 14 diagramas alg vai perguntar por tantos diagramas bom o objetivo disso é apresentar diversas visões do sistema novamente é a filosofia do dividir para conquistar vamos enfocar várias facetas diferentes do sistema para diminuir a sua complexidade nós resolvemos uma pequena parte do problema depois outra pequena parte do problema a juntamos tudo então a o objetivo da ml todos e tantos diagramas eh oferecer múltiplas visões do sistema de forma que elas se complementem enfocando vários aspectos diferentes do software então cada diagrama analisa o sistema ou uma parte dele sobre uma determinada

Ótica então é como se o sistema fosse sendo modelado em Camaros Ah então alguns diagramas enfoco o sistema de maneira muito geral como é o caso do modelo de casos de uso apresentando uma visão externa do sistema e outros enfocam uma visão de uma camada mais profunda do sistema apresenta um enfoque mais técnico ou enfocam apenas uma característica específica do software então o uso de diversos diagramas permite que falha sejam descobertas os diagramas vão se complementando mutuamente então A modelagem ela se torna mais completa a possibilidade de ocorrência de de erros futuros Ah vai diminuir

Ok e Aqui nós temos um diagrama representando os diagramas da umr nós temos a umr se divide em diagramas estruturais e diagramas comportamentais os diagramas estruturais se dividem em diagramas de classe de componentes de objetos de estruturas compostas de implantação de pacotes e de perfil enquanto que os diagramas comportamentais se dividem em diagramas de caso de uso de atividade de máquina de Estados e possuem ainda uma subdivisão que são os diagramas de interação que se dividem em diagrama de sequência de comunicação div visão Geral de interação e de temporização OK mas agora a alguém vai

perguntar oxa mas eu preciso do meu projeto criar todos esses diagramas é realmente ISO necessário não na maioria das vezes se não em todas não é necessário modelar todos os diagramas do ML em um determinado projeto ah na verdade só deve se criar modelos momento que eles agreguem valor ao projeto que eles auxiliem a compreender o problema ou auxiliem a resolver o problem se não desenvolvê-los é contraproducente tá então em muitos casos eu não preciso utilizar todos os diagramas do ML eu acredito que quase nunca ah alguns diagramas Eles são muito específicos então eles só

só deverão ser utilizados em situações muito específicas quando realmente eles são necessários como por exemplo os diagramas de estruturas compostas o diagrama de tempo ou o diagrama de perfil o diagrama de tempo por exemplo ele só vai ser útil se o meu sistema eh levar em consideração o tempo como algo essencial estabelecer o tempo exato for essencial isso ocorre por exemplo em Sistemas de tempo real em Sistemas de intermídia em Sistemas em que a é necessário H trabalhar com detalhes de comunicação em redes como o tempo de gravação e tempo de leitura sendo algo muito

importante em outras situações o diagrama de tempo provavelmente não vai ser necessário o diagrama de perfil um outro exemplo ele só vai ser útil no momento que é necessário adaptar o ML para um domínio para o qual ela não foi projetado Originalmente se não é o caso ele não deve ser utilizado então como eu falei o modelo ou diagrama Ele só pode só deve ser produzido se ele agregar valor ao projeto por quê Porque Nós criamos modelos para auxiliar a compreender o problema ou a solucioná-lo se o diagrama em questão ele não faz isso ele

não atende ess a essa necessidade então não se deve utilizá não se deve criar modelos à toa tá isso é contraproducente agora qual é o mínimo necessário bom na minha opinião eh Bom na verdade essa pergunta Ela depende Depende de uma série de questões Depende do que o para que o software se destina depende da complexidade e seus objetivos e também do nível de exigência de documentação do cliente entre outros fatores agora eu acabei de falar não se deve modelar à toa se não for necessário Não não se cria diagramas que não vão agregar valor

agora existem situações em que o cliente pode exigir uma documentação desnecessário Então nesse caso tem que tem que se fazer tá acabado não tem não tem como argumentar se o cliente exige tem que se fazer Tá mas na maioria das vezes só deve se modelar quando realmente for a agregar valor ao projeto bom mas qual é o mínimo necessário Na minha opinião iniciando pela Engenharia requisitos Eu recomendo que se crie um modelo de caso de uso isso é essencial para identificar os requisitos em termos de requisitos funcionais e os atores ou seja quem pode utilizar

essas funcionalidades o modelo de caso de uso ele vai servir de base para quase todo o projeto Ah ainda durante a engenharia de requisitos deve se produzir um diagrama de classes conceitual onde vão se identificar as classes de entidade classe de entidade são classes relacionadas ao domínio do problema que muitas vezes vão ter eh muitos objetos e esses objetos precisarão ser persistidos em disco são as classes de entidade elas são muito muito semelhantes às entidades do modelo entidade relacionamento tem muita semelhança entre si então basicamente como nome já diz elas identificam os conceitos que precisam

ser focados no sistema ou seja eh os conceitos relacionados ao domínio do problema também se for necessário pode-se produzir diagramas atividade para entender a estrutura organizacional da empresa os seus processos de trabalho e no caso de casos deos complexos ajudar a compreender como vai ser o seu comportamento se for considerado necessário ah depois entre o final de requisitos e o início do projeto se estabelecer a arquitetura do software criando-se um diagrama de pacotes e eventualmente pode se criar também um diagrama de componentes para determinar qu Quais componentes deverão estar localizados em quais partes da arquitetura

soft ah essa arquitetura depois ela vai ser consolidada durante a fase do projeto e como eu falei anteriormente ela precisa ser enfocada com muita seriedade porque a sua alteração é muito cara e demorada eh então durante o projeto de software durante o projeto detalhado os casos de uso eles vão ser detalhados por meio de diagramas de interação ah Principalmente eu costumo usar diagrama de sequência então para cada caso de uso primário ou seja casos usos importantes que realmente agregam valor ao projeto não são simples cadastros ou relatórios simples eu vou criar um diagrama de interação

para aquele caso de uso certo vou detalhar Quais são os objetos que estão envolvidos no processo representado pelo R de uso Que métodos vão ser disparados Entre esses objetos a partir desses métodos identificados pelo diagrama de interação eu enriqueço o modelo conceitual e passo a transformar ele em um modelo de classe de domínio onde as minhas classes de entidade já passa a conter métodos e obviamente eu posso criar outros detalhes relativos relacionados à solução ã eu posso produzir vários diagramas de classe durante o projeto detalhado dependendo da arquitetura escolhida da dificuldade do projeto Mas como

eu falei eu considero que deve ter no mínimo o modelo de classe conceitual e o modelo de classe de domínio outros diagramas poderão ser produzidos se isto for considerado necessário caso contrário não e é isso nós terminamos a nossa primeira aula eu espero que vocês tenham gostado se esse vídeo Foi útil para vocês eu gostaria que vocês curtissem se isso fosse possível compartilhassem com seus colegas e eu agradeço a quem chegou até aqui obrigado pela atenção nós nos vemos em outros vídeos agradeço atenção de vocês