Um dia na vida de um esquilo ou da modelagem de processos ao design de um sistema automatizado de contabilidade de bens materiais "Esquilo-1.0" (Parte 2)
Resumo do episódio anterior
Em utilizamos uma área temática "fabulosa", inspirados em exemplos de estudo de diagramas UML com base em histórias de contos de fadas (veja, por exemplo, [1]). Antes de começar a modelagem, concordamos sobre o uso de alguns elementos do diagrama de Atividade e começamos a formar um acordo sobre a modelagem. Considerando esses acordos, descrevemos o processo na 1ª etapa na forma de diagramas de Atividade, e na 2ª etapa, destacamos os passos do processo para os quais a automação é necessária (e possível).
Lembro que pretendemos automatizar a atividade de contabilidade de bens materiais, que ocorre nesses processos.
…
Uma ilha no mar repousa, (E1, E2)
Cidade na ilha se ergue (E3, E1)
Com catedrais de cúpulas douradas, (E4)
Com casas e jardins; (E5, E6)
Um abeto cresce em frente ao palácio, (E7, E8)
E sob ele uma casa de cristal; (E9)
Ali vive uma esquilo domesticada, (A1)
E que criativa ela é! (A1)
A esquilo canta músicas, (P1, A1)
E fica a roer nozes, (P2)
Mas as nozes não são comuns, (C1)
Todas as cascas são douradas, (C2)
As sementes são de um verde esmeralda; (C3)
Os servos guardam a esquilo, (P3, A2)
Servem-lhe de diversas maneiras (P4)
E um escriba severo está encarregado (A3)
São rigorosos com as nozes; (P5, C1)
Rendeu homenagem à esquilo; (P6, A4)
Das cascas derramam moeda, (P7, C2, C4)
E circulam pelo mundo; (P8)
As moças espalham esmeraldas (P9, A5, C3)
Nas arrecadações, e sob a tampa; (E10, E11)
…
(A.S. Pushkin "A História do Rei Salta, do seu glorioso e poderoso filho, o príncipe Guidão Saltonov, e da bela princesa Cisne", )
Neste exemplo, utilizo o ambiente Enterprise Architect da empresa australiana [2], e no âmbito das aulas aplico [3].
Lembro que os processos podem ser diferentes, você pode se familiarizar, por exemplo, [4] e [5].
Para mais detalhes sobre as abordagens utilizadas na modelagem e design, veja [6, 7].
A especificação completa do UML está disponível em. [8].
Agora estamos prontos para passar para as próximas etapas e começar o design das funções do sistema e sua organização interna. A numeração das ilustrações será continuada.
Etapa 3. A etapa a ser automatizada deve ser associada a uma ou mais funções do sistema
O sistema automatizado em desenvolvimento (SA) destina-se a manter um controle rigoroso das nozes, você se lembra? Para cada passo destacado (veja Figura 3, Figura 4 ), que vamos automatizar, registraremos o requisito funcional, usando aproximadamente a seguinte construção "O sistema deve implementar a possibilidade de ..." e desenvolveremos um diagrama de Caso de Uso. Agora, estamos efetivamente complementando nosso acordo de modelagem com novas regras. Vou explicar quais elementos vamos utilizar.
Entre o "Papel do usuário" e a "Função", utilizaremos a relação de "Associação" (Figura 5), o que significa que para um usuário com esse papel, é possível executar essa função.
Figura 5. Uso da relação do tipo "Associação"
Da "Função" para o "Requisito", estabelecemos a relação de "Implementação" (Figura 6), para mostrar que esse requisito será realizado por essas funções, a relação pode ser "muitos-para-muitos", ou seja, uma função pode participar da implementação de vários requisitos, e pode ser necessário mais de uma função para implementar um requisito.
Figura 6. Uso da relação do tipo "Implementação"
Se uma função requer que outra função seja executada para sua realização, obrigatoriamente, utilizaremos a relação de "Dependência" com o estereótipo "Include" — inclusão (Figura 7). Se a execução de uma função adicional for necessária sob certas condições, utilizaremos a relação de "Dependência" com o estereótipo "Extend" — extensão. É muito fácil de lembrar: "Include" — SEMPRE, e "Extend" – ÀS VEZES.
Figura 7. Uso da relação do tipo "Dependência (inclusão)"
No final, nosso diagrama ficará assim (Figura 8).
Figura 8. Diagrama de Use-case (modelo funcional do AS)
Além disso, o diagrama de Use-case é usado para modelar papéis de usuários (Figura 9).
Figura 9. Diagrama de Use-case (papéis de usuários do AS)
Etapa 4. Descreveremos a organização interna do AS através do diagrama de classes
Usando informações sobre os artefatos de entrada e saída do nosso processo (ver diagramas Activity — Figura 2, Figura 3, Figura 4), desenvolveremos o diagrama de classes. Utilizaremos elementos modeladores de "Classe" e vários tipos de relações entre eles.
Para mostrar a relação "todo-parte", utilizaremos a relação do tipo "Agregação" (Figura 10): a noz é o todo, e as cascas e o núcleo são as partes.
Figura 10. Relação "todo-parte"
Como resultado, o fragmento do nosso diagrama ficará assim (Figura 11). As classes destacadas em cores foram destacadas diretamente na descrição textual do processo.
Figura 11. Diagrama de classes
O diagrama de classes foi também utilizado para modelar outros artefatos – não apenas aqueles que têm relação com o modelo conceitual do processo automatizado de contabilização de bens materiais, mas também em relação ao ambiente de execução – ou seja, o ambiente (Figura 12) e os processos "vizinhos" (Figura 13), que podem influenciar o processo automatizado, mas que ainda não estão em nosso foco (presumimos que o sistema irá evoluir e essa informação será útil).
Figura 12. Diagrama de classes (ambiente)
A relação de herança mostra a generalização de várias construções, com as classes "filhas" sob a classe "pai" generalizada, que é "Construção".
Figura 13. Diagrama de classes (informação adicional sobre artefatos)
"A reação à situação" depende dos "Dados de controle visual". Para várias relações de dependência, utiliza-se o estereótipo "trace" para mostrar o rastreamento de classes que não estão explicitamente indicadas na descrição do processo, mas que são necessárias para sua automação, para as classes cujos instâncias estão claramente indicadas em nossa descrição.
Etapa 5. Analisaremos as notas na pista 'Regras de Negócio'
As regras foram indicadas (ver Figura 2) ):
- a necessidade de dividir um dos passos em 2 partes, onde a segunda parte inicia a execução apenas sob certas condições;
- a designação para a realização da contabilização de nozes por um determinado funcionário;
- um recurso técnico (cor de elementos brancos), que indica que o elemento não foi explicitamente mencionado na descrição do processo.
É importante notar que todas essas regras já foram utilizadas na elaboração dos diagramas.
Considerações finais
Assim, passamos por 5 etapas e construímos 3 tipos de diagramas. Adicionarei ainda um breve comentário sobre a organização de nossos modelos no ambiente de modelagem. Existe uma grande quantidade de frameworks que ajudam a estruturar os modelos em desenvolvimento, mas isso não é objeto deste artigo, portanto, limitaremos a um conjunto simples de pacotes para a gestão ordenada de nosso projeto: Processo de Negócio, Modelo Funcional, Artefatos, Participantes e Ambiente (Figura 14).
Figura 14. Estrutura dos pacotes do projeto
Assim, desenvolvemos modelos coerentes que descrevem o sistema de contabilidade de ativos materiais sob várias perspectivas: o modelo do processo de negócios automatizável, o modelo funcional e o modelo de organização interna do sistema em nível conceitual.
Lista de fontes
- Site "UML2.ru". Fórum da Comunidade de Analistas. Seção Geral. Exemplos. Exemplos de histórias apresentadas na forma de diagramas UML. [Recurso eletrônico] Acesso: Internet:
- Site Sparx Systems. [Recurso eletrônico] Acesso: Internet:
- Site Modelio. [Fonte eletrônica] Acesso: Internet:
- Grande Dicionário Enciclopédico. Processo (interpretação). [Fonte eletrônica] Acesso: Internet:
- Site "Organização para uma Gestão Eficiente". Blog. Categoria "Gestão de Processos de Negócios". Definição de processo de negócios. [Fonte eletrônica] Acesso: Internet:
- Certificado nº 18249 de registro e depósito da obra resultado da atividade intelectual. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuscrito do material didático intitulado "Modelagem da Área do Problema com o uso do Enterprise Architect" / / 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelagem de Processos de Negócios. — M.: KURS, NIC INFRA-M, EBS Znanium.com. — 2017.
- Especificação da Linguagem de Modelagem Unificada (UML) da OMG. Versão 2.5.1. [Recurso eletrônico] Acesso: Internet:
Fonte: habr.com
