"Um dia na vida de um esquilo" ou de processos de modelagem para projetar um sistema automatizado para contabilização de ativos materiais "Belka-1.0" (Parte 1)
O que “esquilo” tem a ver com isso?
Explicarei imediatamente o que o “esquilo” tem a ver com isso. Tendo encontrado projetos divertidos na Internet para aprender UML baseados em uma área temática emprestada de contos de fadas (por exemplo, [1]), também decidi preparar um exemplo semelhante para meus alunos, para que eles pudessem estudar apenas três tipos de diagramas: Diagrama de Atividades, Diagrama de Casos de Uso e Diagrama de Classes. Deliberadamente não traduzo os nomes dos diagramas para o russo para evitar disputas sobre “dificuldades de tradução”. Explicarei para que serve um pouco mais tarde. Neste exemplo estou usando o framework Enterprise Architect de uma empresa australiana [2] – uma boa ferramenta por um preço razoável. E como parte dos meus treinos eu uso [3], uma boa ferramenta gratuita de design orientado a objetos que suporta os padrões UML2.0 e BPMN, sem recursos desnecessários em termos de recursos visuais, mas suficiente para aprender o básico da linguagem.
Vamos automatizar a atividade de contabilização de bens materiais, que surge nestes processos.
...
Encontra-se uma ilha no mar, (E1, E2)
Granizo nas arquibancadas da ilha (E3, E1)
Com igrejas de cúpula dourada, (E4)
Com torres e jardins; (E5, E6)
Spruce cresce em frente ao palácio, (E7, E8)
E embaixo dela está uma casa de cristal; (E9)
O esquilo mora lá, manso, (A1)
Sim, que artista! (A1)
Esquilo canta canções, (P1, A1)
Sim, ele roe todas as nozes, (P2)
E as nozes não são simples, (C1)
Todas as conchas são douradas, (C2)
Kernels puro esmeralda; (C3)
Os servos guardam o esquilo, (P3, A2)
Sirva-a como servos de vários tipos (P4)
E foi designado um escriturário (A3)
Conta estrita de notícias de nozes; (P5, C1)
Dá honra ao seu exército; (P6, A4)
Uma moeda é derramada das conchas, (P7, C2, C4)
Deixe-os flutuar pelo mundo; (P8)
Meninas jogam esmeralda (P9, A5, C3)
Nas despensas, mas debaixo do alqueire; (E10, E11)
...
(A.S. Pushkin “O Conto do Czar Saltan, de seu glorioso e poderoso herói Príncipe Guidon Saltanovich e da bela Princesa Swan”, — 10 anos desde o conceito até a publicação, aliás!)
Um pouco sobre os códigos que estão escritos à direita das linhas. “A” (de “Ator”) significa que a linha contém informações sobre um participante do processo. “C” (de “Class”) – informações sobre objetos de classe que são processados durante a execução de processos. “E” (de “Ambiente”) – informações sobre objetos de classe que caracterizam o ambiente de execução de processos. “P” (de “Processo”) – informações sobre os próprios processos.
Aliás, a definição exata de um processo também afirma ser causa de disputas metodológicas, mesmo que apenas pelo fato de existirem processos diferentes: empresariais, produtivos, tecnológicos, etc. e assim por diante. (você pode descobrir, por exemplo, [4] e [5]). Para evitar polêmica, vamos concordar que Estamos interessados no processo do ponto de vista da sua repetibilidade ao longo do tempo e da necessidade de automatização, ou seja transferir a execução de qualquer parte das operações do processo para um sistema automatizado.
Notas sobre o uso do diagrama de atividades
Vamos começar a modelar nosso processo e usar o diagrama de Atividades para isso. Primeiro, deixe-me explicar como os códigos acima serão usados no modelo. É mais fácil explicar com um exemplo gráfico, mas ao mesmo tempo analisaremos alguns (quase todos os que precisamos) elementos do diagrama de Atividades.
Vamos analisar o seguinte fragmento:
...
Esquilo canta canções, (P1, A1)
Sim, ele roe todas as nozes, (P2)
E as nozes não são simples, (C1)
Todas as conchas são douradas, (C2)
Kernels puro esmeralda; (C3)
...
Temos duas etapas de processo P1 e P2, participante A1, e objetos de três classes diferentes: um objeto da classe C1 é inserido na etapa, objetos das classes C2 e C3 são gerados como resultado da atividade desta etapa P2 do nosso processo. Para o diagrama usamos os seguintes elementos de modelagem.
Um fragmento do nosso processo pode ser representado mais ou menos assim (Figura 1).
Figura 1. Fragmento do diagrama de atividades
Para organizar o espaço e estruturar o diagrama de Atividades, utilizaremos uma abordagem não padronizada, do ponto de vista do uso clássico da notação UML. Mas existem várias razões para isso. Primeiramente, pouco antes de iniciar a modelagem iremos compilar os chamados acordo de modelagem, no qual registramos todos os recursos de uso da notação. Em segundo lugar, esta abordagem foi repetidamente aplicada com sucesso na fase de modelagem de negócios em projetos reais para criar sistemas de software; os resultados foram registrados por nossa pequena equipe de autores no objeto de copyright correspondente [6], e também foram usados em um manual de treinamento [ 7]. Para o diagrama de Atividades, definimos que o campo do diagrama é estruturado usando “raias de natação”. O nome da faixa corresponderá ao tipo de elementos do gráfico que serão colocados nessa faixa.
"Artefatos de entrada e saída": Esta trilha conterá elementos Objects - objetos que são utilizados ou são o resultado da execução de alguma etapa do processo.
"Etapas do processo": Aqui colocaremos os elementos da Atividade - as ações dos participantes do processo.
"Participantes": um caminho para elementos que denotarão os papéis dos executores da ação em nosso processo; para eles usaremos o mesmo elemento de modelagem Objeto - um objeto, mas adicionaremos o estereótipo “Ator” a ele.
A próxima faixa é chamada "Regras do negócio" e nesta trilha colocaremos em forma de texto as regras de execução das etapas do processo, e para isso utilizaremos o elemento de modelagem Nota - uma nota.
Pararemos por aqui, embora também possamos usar o caminho "Ferramentas" para coletar informações sobre o nível de automação de processos. Um caminho também pode ser útil "Posições e divisões dos participantes", pode ser usado para vincular funções a cargos e departamentos de participantes do processo.
Tudo o que acabei de descrever é um fragmento convenções de modelagem, esta parte do acordo diz respeito às regras para organizar um diagrama e, consequentemente, às regras para escrevê-lo e lê-lo.
"Receita"
Agora vamos considerar a opção de modelar o sistema especificamente do diagrama de atividades. Esta é apenas uma das opções, observo que, claro, não é a única. O diagrama de atividades nos interessará do ponto de vista de seu papel na transição da modelagem de processos para o projeto de um sistema automatizado. Para isso, seguiremos as recomendações metodológicas - uma espécie de receita composta por apenas cinco etapas e que prevê o desenvolvimento de apenas três tipos de diagramas. Usar esta receita nos ajudará a obter uma descrição formalizada do processo que queremos automatizar e coletar dados para o projeto do sistema. E para os alunos que estão começando a estudar UML, esse é um tipo de salva-vidas que não permitirá que eles se afoguem em toda a variedade de meios e técnicas visuais encontrados na UML e nas modernas ferramentas de modelagem.
Aqui, de fato, está a receita em si, e a seguir siga os diagramas construídos para nossa área temática de “conto de fadas”.
Etapa 1. Descrevemos o processo na forma de um diagrama de atividades. Para um processo com mais de 10 etapas, faz sentido aplicar o princípio da decomposição das etapas do processo para melhorar a legibilidade do diagrama.
Etapa 2. Selecione o que pode ser automatizado (as etapas podem ser destacadas em um diagrama, por exemplo).
Etapa 3. A etapa automatizada deve ser atribuída a uma função ou funções do sistema (o relacionamento pode ser de muitos para muitos), desenhe um diagrama de casos de uso. Estas são as funções do nosso sistema.
Etapa 4. Vamos descrever a organização interna do AS usando um diagrama de classes - Aula. A rota “Objetos de entrada e saída (documentos)” no diagrama de atividades é a base para construir um modelo de objeto e um modelo de relacionamento de entidade.
Etapa 5. Vamos analisar as notas da trilha "Regras de Negócios", fornecem vários tipos de restrições e condições, que são gradualmente transformadas em requisitos não funcionais.
O conjunto resultante de diagramas (Atividade, Caso de Uso, Classe) nos dá uma descrição formalizada em uma notação bastante estrita, ou seja, tem uma leitura inequívoca. Agora você pode desenvolver especificações técnicas, esclarecer especificações de requisitos, etc.
Vamos começar a modelar.
Etapa 1. Descreva o processo na forma de um diagrama de atividades
Deixe-me lembrar que estruturamos o campo do diagrama usando raias “natação”; cada raia contém elementos do mesmo tipo (Figura 2). Além dos elementos do diagrama descritos acima, usaremos elementos adicionais, vamos descrevê-los.
Decisão (Decisão) denota o ponto de ramificação do nosso processo no diagrama, e a fusão de threads (Mesclar) – o ponto de sua reunificação. As condições de transição são escritas entre colchetes nas transições.
Entre dois sincronizadores (Fork) mostraremos ramificações de processos paralelos.
Nosso processo pode ter apenas um início – um ponto de entrada (Inicial). Mas pode haver várias conclusões (Final), mas não para o nosso diagrama específico.
São muitas setas, com um grande número de elementos e conexões é possível primeiro identificar as etapas do processo e depois realizar uma decomposição dessas etapas. Mas, para maior clareza, gostaria de mostrar nosso processo de “conto de fadas” inteiramente em um diagrama, enquanto, é claro, precisamos garantir que as setas “não fiquem juntas”, seria possível rastrear com precisão o que está conectado para quê.
Figura 2. Diagrama de atividades – visão geral do processo
Porque nos versos poéticos, alguns detalhes do processo são omitidos, tiveram que ser restaurados, são mostrados por elementos com fundo branco. Esses detalhes incluem a etapa de Transferência/Recepção para Armazenamento e Processamento e vários artefatos de entrada e saída. Vale ressaltar que esta etapa também não revela totalmente o processo, pois precisaríamos designar separadamente a etapa de transmissão e a etapa de recepção, e até mesmo adicionar uma etapa separada para conchas, e também pensar que primeiro todos esses valores materiais deveriam ser armazenados temporariamente em algum lugar, etc. e assim por diante.
Observemos também que a questão da origem das nozes permanece sem resposta - de onde elas vêm e como chegam ao esquilo? E esta questão (está destacada em fonte vermelha na nota - o elemento Nota) requer um estudo separado! É assim que funciona um analista - coletando informações aos poucos, fazendo suposições e recebendo “ok” ou “não-ok” de especialistas no assunto - pessoas muito importantes e simplesmente insubstituíveis na fase de modelagem de negócios ao criar sistemas.
Observe também que a etapa do processo P5 consiste em duas partes.
E vamos decompor cada parte e considerá-la com mais detalhes (Figura 3, Figura 4), porque as atividades realizadas nessas etapas específicas serão automatizadas.
Figura 3. Diagrama de atividades – detalhamento (parte 1)
Figura 4. Diagrama de atividades – detalhamento (parte 2)
Etapa 2. Selecione o que pode ser automatizado
As etapas a serem automatizadas são destacadas em cores nos diagramas (ver Figura 3, Figura 4).
Todos eles são realizados por um participante do processo - o Escriturário:
- Insere informações sobre o peso da castanha no extrato;
- Insere informações sobre a transferência da noz no extrato;
- Registra o fato da transformação de uma noz em casca e caroço;
- Insere informações sobre o caroço da noz na instrução;
- Insere informações sobre cascas de nozes na lista.
Análise do trabalho realizado. Qual é o próximo?
Então, fizemos muito trabalho preparatório: coletamos informações sobre o processo que vamos automatizar; começou a chegar a um acordo sobre modelagem (até agora apenas em termos de utilização do diagrama de Atividades); realizou uma simulação do processo e ainda decompôs diversas de suas etapas; Identificamos as etapas do processo que iremos automatizar. Agora estamos prontos para passar para as próximas etapas e começar a projetar a funcionalidade e a organização interna do sistema.
Como você sabe, teoria sem prática não é nada. Definitivamente, você deve tentar “modelar” com suas próprias mãos; isso também é útil para entender a abordagem proposta. Por exemplo, você pode trabalhar em um ambiente de modelagem [3]. Decompusemos apenas parte das etapas do diagrama geral do processo (ver Figura 2). Como tarefa prática, poderá ser solicitado que você repita todos os diagramas do ambiente Modelio e realize uma decomposição da etapa “Transferência/Recepção para Armazenamento e Processamento”.
Ainda não estamos pensando em trabalhar em ambientes de modelagem específicos, mas isso poderá se tornar assunto de artigos e revisões independentes.
Na segunda parte do artigo, analisaremos as técnicas de modelagem e design necessárias nos estágios 3 a 5; usaremos diagramas de casos de uso e de classes UML. Continua.
Lista de fontes
- Site "UML2.ru". Fórum da comunidade de analistas. Seção geral. Exemplos. Exemplos de contos de fadas na forma de diagramas UML. [Recurso eletrônico] Modo de acesso: Internet:
- Site da Sparx Systems. [Recurso eletrônico] Modo de acesso: Internet:
- Site Modelio. [Recurso eletrônico] Modo de acesso: Internet:
- Grande Dicionário Enciclopédico. Processo (interpretação). [Recurso eletrônico] Modo de acesso: Internet:
- Site "Organização de gestão eficaz". blog. Título "Gestão de processos de negócios". Definição de processo de negócio. [Recurso eletrônico] Modo de acesso: Internet:
- Certificado nº 18249 sobre registro e depósito de produto do resultado da atividade intelectual. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. O manuscrito do auxiliar de ensino intitulado "Modeling the subject area using Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelagem de processos de negócio. - M.: KURS, NITs INFRA-M, EBS Znanium.com. — 2017.
Fonte: habr.com