Da modelagem de processos ao design de um sistema automatizado (Parte 2)

“Um dia na vida de um esquilo” ou desde processos de modelagem até o design de um sistema automatizado de contabilidade para valores de material “Squirrel-1.0” (Parte 2)

A ilustração do conto do czar Saltan de A.S. Pushkin foi usada, publicada pela Children's Literature, Moscou, 1949, Leningrado, desenhos de K. Kuznetsov

Resumo das séries anteriores

Na primeira parte, usamos uma área de assunto "conto de fadas", inspirada em exemplos do estudo de diagramas UML baseados em tramas de contos de fadas (veja, por exemplo, aqui [1]). Antes do início da modelagem, concordamos com o uso de alguns elementos do diagrama de Atividades e começamos a formular um contrato de modelagem. Com base nesses acordos, na 1ª etapa, descrevemos o processo na forma de diagramas de atividades e, na 2ª etapa, identificamos as etapas do processo para as quais a automação é necessária (e possível).

Deixe-me lembrá-lo de que vamos automatizar a atividade de contabilizar valores materiais que surgem nesses processos.

...
A ilha fica no mar (E1, E2)
Cidade na arquibancada da ilha (E3, E1)
Com igrejas com cúpula dourada, (E4)
Com torres e jardins; (E5, E6)
Abeto cresce em frente ao palácio, (E7, E8)
E embaixo está uma casa de cristal; (E9)
O esquilo mora lá manual (A1)
Que artista! (A1)
Esquilo canta canções, (P1, A1)
Sim, nozes roem tudo, (P2)
E as nozes não são simples, (C1)
Todas as conchas são douradas, (C2)
Os núcleos são pura esmeralda; (C3)
Servos guardam o esquilo, (P3, A2)
Eles servem a ela uma serva diferente (P4)
E o funcionário foi ordenado (A3)
Estrito relato de nozes; (P5, C1)
Saúda seu exército; (P6, A4)
De uma concha, despeje uma moeda (P7, C2, C4)
Sim, flutue pelo mundo; (P8)
Meninas de esmeralda (P9, A5, C3)
Nas despensas, mas em segundo plano; (E10, E11)
...
(A.S. Pushkin "O conto do czar Saltan, de seu glorioso e poderoso herói Príncipe Gvidon Saltanovich e da bela princesa Cisne", como se acredita, um tratamento gratuito do conto popular "Joelho em ouro, cotovelo da mão em prata", gravado por Pushkin de várias maneiras )

Neste exemplo, eu uso o ambiente Enterprise Architect da empresa australiana Sparx Systems [2] e, como parte da sessão de treinamento, uso Modelio [3].
Deixe-me lembrá-lo de que os processos são diferentes, você pode se familiarizar, por exemplo, aqui [4] e aqui [5].
Para mais informações sobre as abordagens aplicadas à modelagem e design, consulte [6, 7].
Veja a especificação UML completa aqui [8].

Agora estamos prontos para avançar para as próximas etapas e começar a projetar as funções do sistema e sua organização interna. A numeração das figuras continuará.

Etapa 3. A etapa automatizada precisa corresponder à função ou funções do sistema

O sistema automatizado desenvolvido (AS) foi projetado para manter um registro estrito das nozes, lembra? Para cada etapa selecionada (consulte a Figura 3, Figura 4 na 1ª parte ), que automatizaremos, anotamos os requisitos funcionais, aplicando aproximadamente a seguinte construção: “O sistema deve ter a oportunidade de ser implementado ...” e desenvolva o diagrama de casos de uso. Agora, na verdade, estamos complementando nosso contrato de modelagem com novas regras. Deixe-me explicar quais elementos usaremos.

Entre a “Função do Usuário” e a “Função”, usaremos a associação de associação (Figura 5), ​​o que significa que, para um usuário com essa função, a execução dessa função está disponível.

Figura 5. Usando comunicação do tipo de associação

Da “Função” ao “Requisito”, desenhamos a conexão “Implementação” (Figura 6) para mostrar que esse requisito será implementado por essas funções, o relacionamento pode ser “muitos para muitos”. 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 um requisito.

Figura 6. Usando um relacionamento do tipo "Implementação"

Se uma função exigir para sua execução que outra função seja executada e for necessária, usaremos o relacionamento “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 o relacionamento "Dependence" com o estereótipo "Extend" - extensão. Tudo é muito fácil de lembrar: "Incluir" - SEMPRE e "Estender" - Às vezes.

Figura 7. Usando um relacionamento do tipo “Dependência (inclusão)”

Como resultado, nosso diagrama será mais ou menos assim (Figura 8).

Figura 8. Diagrama de casos de uso (modelo funcional AS)

Além disso, o diagrama de casos de uso é usado para modelar funções de usuário (Figura 9).

Figura 9. Diagrama de casos de uso (funções de usuário do alto-falante)

Etapa 4. Descrevemos a organização interna do AS usando o diagrama de classes

Usando informações sobre os artefatos de entrada e saída de nosso processo (consulte Diagramas de Atividades - Figura 2, Figura 3, Figura 4), desenvolveremos um diagrama de classes. Usaremos os elementos de modelagem "Class" e vários tipos de conexões entre eles.

Para mostrar o relacionamento “todo para peça”, usaremos o relacionamento do tipo “Agregação” (Figura 10): a porca é o todo e as conchas e o kernel são partes.

Figura 10. O relacionamento "parte inteira"

Como resultado, um fragmento do nosso diagrama será mais ou menos assim (Figura 11). A cor indica as classes que identificamos diretamente na descrição de texto do processo.

Figura 11. Diagrama de classes

O diagrama de classes também foi usado para modelar outros artefatos - não apenas aqueles que serão relacionados ao modelo conceitual do processo automatizado de contabilização de valores de material, mas que estão relacionados ao ambiente de tempo de execução - o ambiente (Figura 12) e os processos "vizinhos" (Figura 13), que podem influenciar o processo automatizado, mas ainda não estamos no foco de nossa atenção (assumimos que o sistema se desenvolverá e essas informações serão úteis).

Figura 12. Diagrama de classes (ambiente)

A relação de herança mostra uma generalização de vários edifícios, classes "filho", na classe "pai" generalizada "Estrutura".

Figura 13. Diagrama de classes (informações adicionais sobre artefatos)

"Resposta à situação" depende de "Dados de inspeção visual". Para vários relacionamentos de dependência, o estereótipo "trace" é usado 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 para instâncias nas quais existe uma indicação exata em nossa descrição.

Etapa 5. Analisamos as notas na faixa "Business Rules"

As regras foram indicadas (veja a Figura 2 na 1ª parte ):

1. a necessidade de dividir uma das etapas em 2 partes, a segunda parte começa a ser executada apenas sob certas condições;
2. a nomeação de um oficial específico para realizar a contabilidade contábil
3. técnica técnica (cor branca dos elementos), que indica que o elemento não foi indicado explicitamente na descrição do processo.

Deve-se notar que já usamos todas essas regras ao desenvolver diagramas.

Observações finais

Então, passamos por cinco estágios e construímos três tipos de diagramas. Adicione um pequeno comentário sobre a organização de nossos modelos no ambiente de modelagem. Há um grande número de estruturas que ajudam a estruturar os modelos em desenvolvimento, mas este não é o assunto deste artigo, portanto, nos restringiremos ao seguinte conjunto simples de pacotes para conduzir nosso projeto em ordem: Processo de negócios, Modelo Funcional, Artefatos, Participantes e Ambiente (Figura 14).

Figura 14. Estrutura do pacote do projeto

Assim, desenvolvemos modelos consistentes que descrevem o sistema de contabilização de valores de materiais sob vários ângulos: um modelo de um processo de negócios automatizado, um modelo funcional e um modelo da organização interna do sistema em um nível conceitual.

Da modelagem de processos ao design de um sistema automatizado (Parte 1)