"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 2)
Resumo da série anterior
В usamos uma área temática de "conto de fadas" inspirada em exemplos de estudo de diagramas UML baseados em enredos de contos de fadas (veja, por exemplo, [1]). Antes da modelagem, concordamos com o uso de alguns elementos do diagrama de atividades e começamos a formar um acordo de modelagem. Tendo em conta estes acordos, na 1ª fase descrevemos o processo na forma de Diagramas de Actividades, e na 2ª fase identificamos os passos do processo para os quais a automatização é necessária (e possível).
Recordo-vos que vamos automatizar a atividade de contabilização de valores 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 filho Príncipe Gvidon Saltanovich e a bela Princesa Cisne", )
Neste exemplo, estou usando o ambiente Enterprise Architect de uma empresa australiana. [2], e no âmbito das sessões de treinamento eu uso [3].
Deixe-me lembrá-lo de que os processos são diferentes, você pode se familiarizar, por exemplo, [4] e [5].
Consulte [6, 7] para obter detalhes sobre as abordagens aplicadas à modelagem e projeto.
Para obter a especificação UML completa, consulte [8].
Agora estamos prontos para passar para as próximas etapas e começar a desenhar as funções do sistema e sua organização interna. A numeração das figuras continuará.
Etapa 3. A etapa automatizada deve ser atribuída a uma função ou funções do sistema
O sistema automatizado (AS) que está sendo desenvolvido é projetado para manter um registro rigoroso das nozes, lembra? Para cada etapa destacada (ver Figura 3, Figura 4 ), que iremos automatizar, anotar o requisito funcional, usando algo como esta construção “O sistema deve ser capaz de...” e desenvolver um diagrama de caso de uso. Agora estamos realmente complementando nosso acordo de modelagem com novas regras. Deixe-me explicar quais elementos usaremos.
Entre o “User Role” e a “Function” utilizaremos a relação “Association” (Figura 5), o que significa que o usuário com este role pode realizar esta função.
Figura 5. Usando um relacionamento de tipo de associação
De “Função” para “Requisito”, vamos traçar o link “Implementação” (Figura 6) para mostrar que esse requisito será implementado por essas funções, a relação pode ser “muitos para muitos”, ou seja, uma função pode estar envolvida na implementação de vários requisitos e mais de uma função pode ser necessária para implementar o requisito.
Figura 6. Usando um relacionamento de Implementação
Caso uma função requeira para sua execução alguma outra função a ser executada, e seja necessário, utilizaremos a conexão “Dependência” com o estereótipo “Incluir” - inclusão (Figura 7). Se a execução de uma função adicional for necessária sob certas condições, usaremos a conexão "Dependência" com o estereótipo "Estender" - uma extensão. Tudo é muito fácil de lembrar: "Incluir" - SEMPRE e "Estender" - ÀS VEZES.
Figura 7. Usando o tipo de link "Dependência (incluir)"
Como resultado, nosso diagrama ficará mais ou menos assim (Figura 8).
Figura 8. Diagrama de caso de uso (modelo funcional do AS)
Além disso, o diagrama de caso de uso é usado para modelar as funções do usuário (Figura 9).
Figura 9. Diagrama de caso de uso (papéis de usuários AS)
Etapa 4. Vamos descrever a organização interna do AS usando um diagrama de classes
Usando informações sobre os artefatos de entrada e saída do nosso processo (consulte Diagramas de atividades - Figura 2, Figura 3, Figura 4), desenvolveremos um diagrama de classes. Usaremos os elementos de modelagem “Classe” e vários tipos de relacionamentos entre eles.
Para mostrar a relação “todo-parte”, usaremos a relação do tipo “Agregação” (Figura 10): a noz é o todo, e as cascas e o miolo são as partes.
Figura 10. Relação Todo-Parte
Como resultado, um fragmento do nosso diagrama ficará mais ou menos assim (Figura 11). As aulas são marcadas com cores, que destacamos diretamente no texto descritivo do processo.
Figura 11. Diagrama de classe
O diagrama de classes também foi utilizado para modelar outros artefatos - não apenas aqueles que serão relevantes para o modelo conceitual do processo de inventário automatizado, mas relacionados ao ambiente de execução - o ambiente (Figura 12) e os processos "vizinhos" (Figura 13). que podem influenciar o processo automatizado, mas ainda não estão no foco de nossa atenção (assumimos que o sistema irá evoluir e esta informação será útil).
Figura 12. Diagrama de classes (ambiente)
A relação de herança mostra a generalização de vários edifícios, classes "filho", sob a generalização da classe "pai" "Edifício".
Figura 13. Diagrama de classes (mais informações sobre artefatos)
A "Reação à situação" depende dos "Dados de controle visual". Para diversos relacionamentos de dependência, o estereótipo “trace” é utilizado para mostrar o rastreamento de classes que não são explicitamente indicadas na descrição do processo, mas que são necessárias para sua automação, para classes cujas instâncias são precisamente indicadas em nossa descrição.
Etapa 5. Vamos analisar as notas da trilha "Regras de Negócios"
Como as regras foram especificadas (ver Figura 2 ):
- a necessidade de dividir uma das etapas em 2 partes, a segunda parte passa a ser realizada apenas sob certas condições;
- nomeação de um determinado funcionário para realizar a contabilidade das nozes;
- uma técnica (cor branca dos elementos), que indica que o elemento não foi listado explicitamente na descrição do processo.
Deve-se notar que já usamos todas essas regras ao desenvolver diagramas.
Considerações finais
Assim, passamos por 5 etapas e construímos 3 tipos de diagramas. Acrescentarei mais um comentário sobre a organização de nossos modelos no ambiente de modelagem. Existe um grande número de frameworks que ajudam a estruturar os modelos que desenvolvemos, mas não é este o assunto deste artigo, então nos limitaremos ao seguinte conjunto simples de pacotes para manutenção ordenada do nosso projeto: Processo de Negócio, Modelo Funcional, Artefatos, Participantes e Ambiente (Figura 14).
Figura 14. A estrutura dos pacotes do projeto
Assim, desenvolvemos modelos consistentes que descrevem o sistema de contabilidade de ativos materiais de vários ângulos: um modelo de processo de negócios automatizado, um modelo funcional e um 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 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.
- Especificação OMG Unified Modeling Language (OMG UML). Versão 2.5.1. [Recurso eletrônico] Modo de acesso: Internet:
Fonte: habr.com