Imagem de www.uml.org Este
artigo é sobre UML e seus usos atuais. Poucas informações históricas, muito pouco, apenas os pontos principais:
- A UML teve origem nos anos 90 como resultado do trabalho para criar uma linguagem de modelagem orientada a objetos.
- A especificação 1.0 foi lançada em 1997.
- A especificação 2.0 foi lançada em 2005.
- Até o momento, na UML 2.5, vários perfis evoluíram, como SysML e SoaML .
Se você observar como a UML foi aplicada no momento e agora, e pensar sobre isso, poderá tirar a seguinte conclusão: Deixe a versão da UML agora ser 2.5, mas os princípios de uso da linguagem não foram alterados desde a primeira versão.
E como resultado: os analistas usam o conceito de uma descrição de sistemas de software, estabelecida há mais de 20 anos. O conceito em si é bom, mas você precisa relacioná-lo com o local e o contexto de uso.
Se continuarmos essa análise do uso da UML, bem como a correlacionarmos com os requisitos do tempo atual, as conclusões são as seguintes:
- Todas as técnicas para usar a UML "dão a volta" no Desenvolvimento Orientado a Casos de Uso.
- Os modelos UML não têm integridade. A abordagem escolhida para descrever separadamente aspectos da estrutura e comportamento, níveis de negócios e aplicativos complica a percepção dos modelos como um todo.
- A UML é uma linguagem orientada a objetos, o que dificulta a expressão de outros conceitos.
Não vou falar nada sobre a abordagem de Desenvolvimento Orientado a Casos de Uso; uma de suas encarnações é o Rational Unified Process. A seguir, falarei sobre os dois últimos pontos.
Aspectos da apresentação
A UML é composta por muitos diagramas. Cada um dos quais obedece a suas próprias regras, usa elementos e setas em seu próprio entendimento. E do lado de fora não parece uma linguagem unificada, mas como um conjunto de representações diferentes, que muitas vezes é apresentado como uma oportunidade de olhar a área de assunto sob diferentes pontos de vista. Com o mesmo sucesso, você pode chamar a faca suíça de ferramenta unificada, que em essência é um conjunto composto por lâminas, chaves de fenda, abridores, colheres, garfos e tudo em uma alça.
O que um analista faz ao tentar vincular todos os gráficos em um modelo? Ele começa a criar gráficos híbridos e tabelas de links. O resultado não é um modelo único, mas um conjunto de diagramas, aos quais foram adicionados mais diagramas e tabelas.
Níveis de apresentação
Digamos que um analista de negócios tenha descrito uma área de assunto usando diagramas UML. E agora um analista de sistemas ou o mesmo analista precisa formar um modelo de sistema de software. Se o analista estiver focado na UML, ele começará a criar representações correspondentes às feitas anteriormente, mas já dentro da estrutura do sistema. Isso parecerá novamente na forma de diagramas semelhantes.
O que o analista fará quando quiser comparar a descrição da área de assunto e o modelo do sistema?
Ele novamente começa a criar diagramas híbridos, tabelas de links e rastreios.
O resultado é novamente um monte de gráficos e tabelas.
Também deve ser observado aqui que a UML é uma linguagem antiga e há muitos livros e exemplos antigos para ela.Nos quais são descritos principalmente casos de transição de uma empresa manual para outra automatizada. E os analistas aprendem com esses exemplos. Hoje, porém, as tecnologias da informação têm penetrado em todos os lugares. A abordagem "Negócios separadamente, TI separadamente" é inaceitável .
Abordagem Orientada a Serviços
UML é uma linguagem orientada a objetos, o que dificulta a expressão de outros conceitos. Por exemplo, orientado a serviços. No perfil UML padrão, não há conceito de "Serviço", mas há um perfil SoaML , que é apresentado como uma linguagem de modelagem para uma arquitetura orientada a serviços.
Vou falar brevemente sobre uma abordagem orientada a serviços, para que seja entendido ainda mais por que o SoaML não é adequado para sua modelagem. Vamos tomar a interpretação das definições do TOGAF como base .
Para uma formalização simples de uma abordagem orientada a serviços, precisamos de 2 abstrações:
- Processo é o fluxo de controle entre / sobre serviços. Também é preciso dizer que um processo é uma sequência de ações que, juntas, atingem um determinado resultado.
- Serviço - um elemento de comportamento que fornece uma certa funcionalidade em resposta a solicitações de sujeitos ou outros serviços. Um serviço fornece ou suporta recursos , possui uma interface definida explicitamente e é controlado explicitamente.
Vamos ver como isso é modelado no SoaML. Ao mesmo tempo, vamos comparar como a modelagem orientada a objetos na UML e a modelagem orientada a serviços no SoaML serão diferentes.
Man and Shop
Tarefa: Descreva o modelo de compra de mercadorias na loja.
A abordagem orientada a objetos, eu acho, é clara e simples para todos. Para não perder tempo, não consideraremos a camada de negócios. Acho que todo mundo pode imaginar mentalmente o Caso de Uso de aconselhamento e seus detalhes na forma de um diagrama de atividades ou um diagrama de sequência.
Uma pessoa age não como usuário, mas como um dos lados da interação.
Agora vamos resolver esse problema usando o SoaML, estritamente de acordo com a especificação .
Neste diagrama, definimos a comunidade de pessoas que interagem, isto é, a Loja e a Pessoa.
Definimos o processo de negócios "Venda de mercadorias" operando entre eles, no qual a Loja atua como "vendedor" e a Pessoa como "comprador".
Com base no processo de negócios, agora podemos identificar o próximo serviço de negócios, no SoaML, o classificador ServiceContract é usado para isso.
Dentro da estrutura deste serviço: O Vendedor atua como fornecedor e o Comprador atua como consumidor.
O vendedor como fornecedor fornece uma operação de "venda". A análise de negócios está completa, passamos ao nível do sistema.
Precisamos simular no nível do sistema uma versão atualizada do nosso processo de negócios para a venda de mercadorias. Para isso, escolhi um diagrama de sequência, você pode usar qualquer outro diagrama de comportamento.
A partir do processo de negócios atualizado, podemos destacar uma operação "vender", organizá-la na interface básica "Quem sabe vender".
Em seguida, precisamos descrever as interfaces de serviço que serão usadas para implementar o serviço.
Temos as seguintes interfaces de serviço:
- "O desejo de vender", que é herdado da interface "capaz de vender";
- "Precisa comprar", que depende da interface "capaz de vender".
Agora você pode imaginar o modelo de serviço de destino na forma de um diagrama de estrutura composto.
Compare os resultados da modelagem orientada a objetos na UML e da modelagem orientada a serviços no SoaML.
Visualmente, toda a diferença está nesses pequenos quadrados na borda dos componentes. Eu os marquei em vermelho. Isso faz toda a diferença?
Existe realmente uma diferença entre modelagem orientada a objetos e modelada, mas o SoaML reduziu tudo a objetos. Mas mais sobre isso mais tarde.
E agora vamos terminar a consideração do SoaML em um caso mais complexo, depois abordaremos os seguintes esquemas.
O que há de errado, na minha opinião, com o SoaML.
primeiramente: Novamente, problemas com a integridade do idioma e o relacionamento entre o nível de negócios e o nível do aplicativo, você mesmo viu como é difícil tudo se relacionar.
Segundo : o serviço é descrito como um objeto de estrutura, isso não é bom. No discurso em russo, a frase "O provedor representa um serviço" é comum, é uma abordagem orientada a componentes implementada no SoaML. Mas, no caso do paradigma orientado a serviços, é mais correto dizer "O fornecedor fornece um serviço". E se você traduzir "Serviço" para o russo de maneira diferente, tudo se encaixará imediatamente: "O fornecedor fornece um serviço ". Deste ponto de vista, "Serviço" não é um "Objeto", é um "Comportamento".
Em terceiro lugar: No slide sobre arquitetura orientada a serviços, falei sobre duas abstrações: Processo e Serviço. Visualizar e descrevê-los através das lentes de uma abordagem orientada a objetos é, para dizer o mínimo, uma tarefa estressante.
Paradigmas
Vamos voltar para a UML. A UML, por meio de seu paradigma, está tentando descrever outros paradigmas.
E se tudo der certo com o paradigma orientado a componentes, ele pode ser apresentado como uma continuação lógica do orientado a objetos. O orientado a serviços não funcionou bem.
Nesse caso, expressar um paradigma através de outra idéia infeliz.
Demonstrei o uso desse conceito com o SoaML usando o exemplo da tarefa "Man and Shop".
Aplica-se a paradigmas melhor, conforme indicado abaixo.
Vou demonstrar como a modelagem orientada a serviços difere da modelagem orientada a objetos.
Homem e cachorro
Objetivo: Descrever o modelo de interação - Uma pessoa caminha com um cachorro.
Sem pensar duas vezes, essa tarefa provavelmente será resolvida por qualquer aluno da faculdade técnica. A programação orientada a objetos é essencial nas escolas e universidades das especialidades relevantes. A abordagem orientada a objetos é apresentada abaixo.
Como seria um modelo orientado a serviços? Não sei se o aluno responderá a essa pergunta.
Aqui está o que eu gostaria de receber. (Pense por um minuto e veja)
, . - . () () «».
, . - . () () «».
Você pode recordar o histórico da programação orientada a objetos. Até que ponto céticos eram pessoas com muita autoridade, como Edsger Dijkstra e Niklaus Wirth, no início de sua aparição. E até hoje, algumas pessoas consideram o POO indigno de atenção.
Bem, este modelo também pode causar sorrisos. O ponto é que o paradigma orientado a serviços não tem suporte suficiente no nível inicial de programação e design. Para programadores, o suporte é fornecido apenas por estruturas, por exemplo, Java Enterprise Edition ou Spring. Eu acho que os programadores chegam até eles com uma cabeça já formatada para uma abordagem orientada a objetos.
Os analistas estão construindo suas idéias sobre arquitetura orientada a serviços e projetando para artigos na Internet que tenham uma compreensão diferente do que é, e alguns artigos sem uma imersão profunda nos detalhes e detalhes técnicos são geralmente incompreensíveis. Como resultado, os analistas retornam aos Casos de Uso geralmente aceitos entre o sistema e os usuários. Também é comum que a arquitetura do sistema e sua composição de componentes já sejam fixadas pelo arquiteto ou determinadas pela plataforma escolhida. E então os analistas novamente descrevem simplesmente o Caso de Uso entre o sistema e os usuários.
Compare a abordagem orientada a objetos e essa aparentemente ridícula, onde o Homem presta ao Cão um serviço de "Caminhada". Quando ele deixa de ser engraçado para você, mas a abordagem orientada a objetos, onde o Humano implementa o método de "andar", parecerá engraçado,na entrada para a qual o cão é servido !!! Foi aí que você entendeu o paradigma orientado a serviços.
Note-se que esses paradigmas são bastante compatíveis. Uma pessoa ainda pode realizar suas ações habituais: dormir e dançar, e o cão pode latir.
Mais um ponto: neste exemplo, introduzi um novo conceito "Serviço". No entanto, ainda não defini claramente as regras para seu uso, mas difere das regras no SoaML. Aqui você precisa ter cuidado, não se deixe levar por isso, pois essas extensões estão relacionadas ao metamodelo. Pode acontecer que os modelos criados se mostrem contraditórios e obscuros.
Em vez de uma conclusão
- UML . , . .
- . , . .
- UML . , . , UML, .