Table of Contents

0. Metamodel
2. Constants
parameter positions
1. Templates
0. Basics and relations
3. Process
4. Requirements
1. Abstractions
2. Code units
00. metamodel relations
00. model relations
1. Requirements
Categorize transactions
Transactions are in a database
The project should not impose constraints
The user should be informed
2. Process
0. Process overview
1. The user's project
external script
csv file
Config
2. categorizerai
data
Services and DTOs
ai
ui
update
db
not yet modeled
External dependencies
Deviations

List of Figures

1. Process constraints
2. Process
3. Requirements
4. Container
5. Type and property
6. Callable
7. Constraints and Derived Relations
8. Data abstractions
9. Thing and Constraint
10. Containers
11. Constant providers
12. DTO and factory
13. Service
14. Delegate
15. External units
16. Type definition
17. Unit test
18. Categorize transactions
19. Transactions are in a database
20. The project should not impose constraints
21. The user should be informed
22. Requirements
23. Process overview
24. external script
25. csv file
26. Config
27. Get Data From database
28. NumericConverterService
29. PrepareDataService
30. prepare data for AI
31. CategorizerService
32. AccuracyCheckService
33. NeuralNetBuilderService
34. NeuralNetTrainerService
35. AIData
36. ai
37. DisplayAccuracyService
38. AccuracyErrorDisplayService
39. ChoiceAskService
40. OptionDisplayService
41. TransactionDisplayService
42. ui
43. ChoiceObtainerService
44. choices
45. OptionPreparatorService
46. CategoryService
47. Compute suggestions
48. Test Data
49. External dependencies

0. Metamodel

2. Constants

parameter positions

Table 1. 

1

Is a Position.

connections:

2

Is a Position.

connections:

3

Is a Position.

connections:


Table 2. 


1. Templates

0. Basics and relations

Table 3. 

Basic Object

Is an .

Basic Relation

Basic Relation is an .


3. Process

constraints

Table 4. 

Figure 1. Process constraints

Process constraints


Contained in a Package or a process step

Is a Constraint.

(

count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='Package']) +
count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='External package']) +
count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='Process Step'])+ 
count(zenta:neighbours($p1,$p2,'iterates,2')[@xsi:type='Process Step'])

) > 0

connections:

Contained in at most one Package

Is a Constraint.

count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='Package']) < 2

connections:

Contained in at most one Process Step

Is a Constraint.

count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='Process Step']) <2

connections:

Iterates or contained in at most one Process Step

Is a Constraint.

(

count(zenta:neighbours($p1,$p2,'iterates,2')[@xsi:type='Process Step']) + 
count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='Process Step']) 

) <2

connections:

Is done by a user or implemented by a Callable

Is a Constraint.

(

count(zenta:neighbours($p1,$p2,'is done by/does,1')) + 
count(zenta:neighbours($p1,$p2,'is implemented by/implements,1')) 

) >= 1

connections:


Table 5. 

Figure 2. Process

Things which have business relevance but not implemented as is are colored blueish.

Process


Process Step

Is a Behaviour.

A behaviour which is carried out by either a role or a service. Process steps can contain other process steps, behaviours, Services and DTOs

<doctemplate> containing neighbours: <xpath>

zenta:itemizedList(zenta:neighbours(/,.,'contains,2'))

</xpath>

debug

<xpath> . </xpath> <doctemplate>

connections:

Role

Is a Thing.

The responsibility for performing specific behavior.

A role is assigned to human(s).

connections:

is implemented by/implements

Is a Derived Relation.

1| if (not(zenta:neighboursRun1($p1,$p2,'is implemented by/implements,1'))) then

(zenta:neighboursRun1($p1,$p2,'iterates,2;is implemented by/implements,1') |
zenta:neighboursRun1($p1,$p2,'contains,2;is implemented by/implements,1') )

else

()

connections:


4. Requirements

Table 6. 

Figure 3. Requirements

Requirements


Policy

Is a Thing.

A policy is a management level statement about what the software should do, should not do, or the perceived threats and constraints to avoid.

Policy, Threat, and Assumption of Common Criteria are modeled with a Policy.

connections:

Objective

Is a Thing.

An objective is a statement about the workings or structure of the software. It is lower level than a Policy, but higher level than a behaviour.

This is the same as Objective of Common Criteria

connections:

Behaviour

Is a Container.

A specific, implementable, testable statement about the behaviour of the software. The set of behaviours should fully define the workings of the callable (in most cases Service) implementing them.

The behaviour is the work unit offered for coding.

This is the same as Requirement in Common Criteria.

connections:

uses

An uses is a Basic Relation.

determines

A determines is a Basic Relation.

is tested by/tests

An is tested by/tests is a Basic Relation.


1. Abstractions

Abstract entities are used to derive other ones. Abstract entities are white, and they are not meant to show up in any model.

1. Container

Table 7. 

Figure 4. Container

Container


Container

Is a Thing.

A container can contain another container, hence it can be contained by another container.

connections:


2. Type and property

Table 8. 

Figure 5. Type and property

Type and property


Property

Is a Thing.

A field of a type.

connections:

  • It is contained by Type
  • It is a at least 1 Type

Type

Is a Container.

This is an abstract entity used for anything which is either usually implemented as a class, or have some kind of property.

connections:


4. Callable

Table 9. 

Figure 6. Callable

Callable


Callable

Is a Type.

A Callable is an abstraction for anything which can be called.

connections:

Parameter

Is a Thing.

A parameter is determined by the Business Object (and the Type through it), its position, and an optional default value.

connections:

Position

Is a Thing.

The position of a parameter in the argument list of a callable

connections:


3. Data abstractions

constraints

Table 10. 

Figure 7. Constraints and Derived Relations

Constraints and Derived Relations


has an example as/is an example of

Is a Derived Relation.

2| zenta:neighboursRun1($p1,$p2,'is based on/is base of,2;has an example as/is an example of,2')

connections:

is a/is type of

Is a Derived Relation.

1| zenta:neighboursRun1($p1,$p2,'has an example as/is an example of,2;is of/is type of,1')

connections:

uses

Is a Derived Relation.

2|

zenta:neighboursRun1($p1,$p2,'has an example as/is an example of,2;is/is used as parameter,2;uses,2;is implemented by/implements,2') |
zenta:neighboursRun1($p1,$p2,'has an example as/is an example of,2;results,2;is implemented by/implements,2') |
zenta:neighboursRun1($p1,$p2,'is based on/is base of,2;has an example as/is an example of,2;is/is used as parameter,2;uses,2;is implemented by/implements,2') |
zenta:neighboursRun1($p1,$p2,'is based on/is base of,2;has an example as/is an example of,2;results,2;is implemented by/implements,2') 


connections:


Table 11. 

Figure 8. Data abstractions

Data abstractions


Business Object

Is a Type.

A Business Object is an object which have meaning in the context of certain steps of a process. It is in most cases carries the business meaning of something which is result of one service and input of another one. It does not have implementation, but tightly coupled with a type which has.

connections:

Constant Provider

Is a Type.

Constant provider is a type which have only constants as properties.

Constant

Is a Property.

Constant is a special property. Its value is predetermined and never changes.

connections:

has an example as/is an example of

A has an example as/is an example of is a Basic Relation.


0. Thing, Constraint and Derived Relation

Table 12. 

Figure 9. Thing and Constraint

Thing and Constraint


Thing

Is a Basic Object.

connections:

Constraint

Is a Basic Object.

connections:

Derived Relation

Is a Basic Object.

connections:

constrains

A constrains is a Basic Relation.

expands

An expands is a Basic Relation.


Table 13. 


2. Code units

Code units are the units which are implemented within the project. They are brownish in color, to make it

1. containers

Table 14. 

Figure 10. Containers

Containers


Package

Is a Container.

A set of code contributing to a functionality of a product. Packages contain process steps, and the code units (Services, DTOs, and other packages) implementing those process steps.

connections:

Project

Is a Container.

A set of code and documentation which is bundled together as a shippable unit useable for its intended audience (also known as product), or the complete procedure of software development from requirement gathering to testing and maintenance, carried out according to the execution methodologies, in a specified period of time to deliver the product.

Projects can contain packages.

connections:

In exactly one Project or Package

Is a Constraint.

(

 count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='External Project']) +
 count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='Project']) +
 count(zenta:neighbours($p1,$p2,'contains,2')[@xsi:type='Package'])

) = 1

connections:

Contains at least one package

Is a Constraint.

if ($p2/@xsi:type = 'Project') then

 count(zenta:neighbours($p1,$p2,'contains,1')[@xsi:type='Package']) >0

else

 true()

connections:


2. Constant proviers

Table 15. 

Figure 11. Constant providers

Constant providers


Configuration provider

Is a Constant Provider.

A set of constants provided by the user to parametrize the behaviour of the product.

connections:

TestData

Is a Constant Provider.

modeled

A set of constants for testing.

Test data contains the test artifacts. This is the set of inputs and corresponding outputs which pins the contract of the services. Test artifacts can be stubs describing the behaviour of parameters or actual data.

The test data for basic non-error behaviour should be provided by architects, and each data which is an easy conversation of another data should be defined using the conversation. This improves integration consistency.

Dependencies between test data units should be noncircular. Test data is placed in the same subsystem in the test hierarchy as the corresponding Service. Test data should not reference production code in any way. If the constant is needed, it should be copied over to test data.

In Java:

  • it is a class
  • The test artifacts are in public fields
  • The functions generating the test artifacts are private methods.
  • DTOs and other test data units are instantiated using new.

In Python:

  • test data units are classes ending as TestData, and beginning with the name of the package or service they are related.
  • all methods of test data units are private (start with ‘_’)
  • other test data units are instantiated in the constructor by “calling them”

connections:

Can contain only constants

Is a Constraint.

count(zenta:neighbours($p1,$p2,'contains,1')[@xsi:type='Property']) = 0

connections:

Contains only Test Artifacts

Is a Constraint.

count(zenta:neighbours($p1,$p2,'contains,1')[@xsi:type='Property']) = 0

connections:


3. DTO and Factory

Table 16. 

Figure 12. DTO and factory

DTO and factory


DTO

Is a Type.

DTO is used to hold a data object. It is transparent and have no business logic.

A DTO is placed in a data subpackage in the production code hierarchy

In java it is a class with no methods, just private fields, and Lombok @Getter, @Setter and possibly @EqualsAndHashCode annotations. A DTO have no explicit constructor, its constructor should not be used, except in its factory. A DTO is placed in the package designated by the architect.

A DTO have an associated factory responsible for creating it. A creation of a DTO instance in production code should only be initiated using its factory.

As all aspects of the DTO is determined by the architect, it is good practice to generate it.

invariants hashcode, toString and equals may be implemented in a subclass. In this case that subclass should be used throughout the rest of the code. This rule may change later as more experience is gathered, as this breaks the rule that a DTO should not have logic.

In python a DTO is a class with @DTO decorator, and propery type-annotated fields, initialized as None. No methods, not even __init__.

connections:

Factory

Is a Type.

A factory is a special kind of service solely responsible to create default instances of a DTO or Delegate.

A Factory is placed in a data subpackage in the production code hierarchy

In java it is a class annotated as @Service extending FactoryBean, and resides in the data subpackage of the created object’s package. In Python, factories should be created only for implemented DTOs, for all others we consider types.SimpleNamespace to be the factory.

As it is fully boilerplate, it is a good practice to generate it.

connections:

  • It creates at least 1 and at most 1 DTO


4. Service

Table 17. 

Figure 13. Service

Service


Service

Is a Callable.

A service is a unit implementing some logic. In java it is a class and an interface. In Python it is a class, using the Java naming convention, including the one class one module rule.

A service do not have any state. In java that means that the service only have fields for constants and the management of its dependencies (see below), no other fields. In python dependencies and constants are static: they are created in the module before the class definition.

A service does one thing. Therefore it either have one public function, or more public functions with different types of parameters where those functions do the same.

In polymorphic languages all the functions of the service therefore have to have the same name (“call”) as a rule. An exception of the rule when the compiler/interpreter cannot reliably determine the correct function to use.

A service references its dependencies in an abstract way, using dependency inversion. If there is a dependency injection mechanism for the language, that mechanism should be used. In java by default we use Spring, which means that the class is marked as @Service, and the dependencies are fields referencing the interface of the dependent service using @Autowired. In Python by default we use winterboot. Python services are marked with the @Service annotation, and referenced as serviceName = Autowired(‘servicename’). When the wider framework uses other DI mechanisms, their use should be modelled after this as closely as possible.

The service is placed in the production code hierarchy in a way which is related to its place in the business logic, and makes it easy to find it. In java this means that both the interface and implementation should be placed in the same package, the interface name ending in Service, the implementation name ending with ServiceImpl. In Python the class name (hence the module basename) ends with ‘Service’. In Python the service class should be descendant of object. The interface have one method called “call”.

If the need to break down the functionality of a package arises driven by programming activities (e.g. because of exceeding code complexity measures), the programmer’s responsibility is to notify the architect. The process of the resolution of the issue is left at the architect’s discretion until the need arises to further clarify it.

In java and python Services should not have static methods except when the needs of a Delegate dictate it.

In java all interface methods should have an @Override annotation in the implementation class. Other methods should be private.

In Python a service have a single public method called “call”, all other methods should start with ‘_’ to make them private. At least the call method should be properly annotated with the types of both the parameters and return value.

connections:

Implements a Process Step

Is a Constraint.

count(zenta:neighbours($p1,$p2,'is implemented by/implements,2')[@xsi:type='Process Step']) = 1

connections:


5. Delegate

Table 18. 

Figure 14. Delegate

Delegate


Delegate

Is a Type.

Delegates are to implement classes containing both state and business logic, and/or when the DI framework needs to be manually bootstrapped.

The state is delegated to a DTO

The business logic is delegated to one or more Services

In Java:

  • The DI bootstrapping is delegated to a static void method with sole parameter of this in an interface of the underlying service.
  • The state of a delegate is stored in a DTO, referenced in a field annotated with @Delegate and if the integration tests need it, @Getter annotation.
  • The underlying services are referenced using @Autowire -d fields using the interface
  • The methods use the delegate pattern, with this as an extra parameter in the delegated call.

connections:

  • It uses at least 1 and at most 1 Service
  • It uses at least 1 and at most 1 DTO


6. External units

External units are implemented outside of the project, hence they are all grey. Configuration provider is shown earlier, and it is also an external unit.

In a model view it is a good practice to grey out elements which are outside of the scope of implementation for the view, even if they are implemented elsewhere inside the project.

Table 19. 

Figure 15. External units

External units


External Service under DI framework

Is a Callable.

A service which can be used by the DI framework of the project as an internal one, but implemented outside of the project.

External type

Is a Callable.

An external type, used either as data carrier, service, or both.

connections:

External Project

Is a Project.

External package

Is a Package.


8. Python specific

Table 20. 

Figure 16. Type definition

Type definition


Type Alias

Is a Type.

A class descending from types in the typing package.

It is technically needed when a complex type annotation cannot be carried out using an external type.

The only content of the class is:

 __slots__ = ()

connections:

aliases

Aliases is a Basic Relation.


7. Not modeled but implemented

1. Unit test

Table 21. 

Figure 17. Unit test

Unit test


Test Case

Is a Thing.

Tests one aspect of a behaviour.

The unit of payment for coding work.

Not modeled.

connections:

Unit Test

Is a Type.

Not modeled

A unit test is a code testing (a part of) the implementation of a Service. If there is a TCDD (temporary name) framework for the given language, that should be used instead of unit tests.

Only services implemented by the project should be tested.

A unit test is placed in the same subsystem in the test hierarchy as the service in the production code hierarchy

The unit test references the implementation class of the service, but must avoid calling methods not contained in the interface.

The unit test otherwise uses the standard practices for unit testing in the given language.

The unit tests names/descriptions are used to generate low level documentation of the project. Therefore they should be a full declarative sentence, using whatever ways the language offers: method names, annotations, and even comments may be used. If not method names are used, then naming is left to the discretion of the programmer, with minimal language-specific rules. In the face of it this is against the clean code principles, but checking that the description is indeed covers the functionality checked by the unit test is a central element of the review process, and if there is other descriptive element, then actual method names do not matter.

All behaviours should be tested in at least one unit referencing the behaviour in its name and an appropriate way in the source code (annotation or comment, if annotations are not available in the language). Separating the tests to further units (e.g. because code complexity constraints) is the responsibility of the programmer. Separation should be made in a way that minimizes boilerplate.

The unit tests should not contain constants, stubs, or helper functions constants should be used from test data units. No constants in production code should be used.

stubs describing behaviour of production code or external dependencies should be put to stub providers

stubs describing behaviour of parameters should be put to test data units

helper functions should be put to test helpers

setup can be used to actually call the tested service, and leave only the assertions to the test cases

connections:

Test Helper

Is a Type.

not modeled

The test helpers contain the methods helping assertions: assertion methods, and methods to make easier to write assertions.

In Java a testhelper contains static methods.

In python the module directly contains the methods.

connections:

Stub provider

Is a Type.

not modeled

stub providers provide the stubs describing the service behaviours using the test artifacts. There are two kinds of stubs:

  • stubs describing the behaviour of the service with respect to some external state (e.g. the role of the logged in user). These are context stubs.
  • stubs describing the service behaviour which is independent of external states: behaviour stubs

Stub providers are placed in the test hierarchy in the subsystem of the described service, with a name referencing the service described. Stubs for external dependencies go to a subsystem dedicated to that. In java, the package name is the package name of the external dependency, in python it is the “externalstubs” package in the test hierarchy.

If the need arises to place stub providers into more units, it is the responsibility of the programmer.

In java

  • stub providers are interfaces named [service name]Stubs, for example ContractRunnerStubs for ContractRunnerService
  • the stubs are created in static void methods with no parameters
  • the static void behaviour() method uses all behaviour stubs to provide the whole contract of a given service.
  • if the need arises to use additional interfaces for the same service (e.g. due to code complexity constraints), the additional code should be placed in interfaces with names starting with the name of the service, and ending with Stubs, e.g. ContractRunnerReturningContractsStubs. The additional services should extend the default-named interface so it is enough to reference that in tests. In case of multiple interfaces, it is good practice to keep only the behaviour() method in the default one.

In Python

  • stub providers are modules named [service name]StubProvider
  • stubs are defined in methods. the service to be stubbed is obtained with Autowired(). At the phase the stub services are called, this will result in a mock object.

connections:

Test Artifact

Is a Constant.

connections:

contains

A contains is a Basic Relation.

uses

An uses is a Basic Relation.

uses

An uses is a Basic Relation.

uses

An uses is a Basic Relation.

is based on/is base of

An is based on/is base of is a Basic Relation.


Table 22. 


Table 23. 


00. metamodel relations

Table 24. 

contains

A contains is a Basic Relation.

contains

A contains is a Basic Relation.

contributes to/uses

A contributes to/uses is a Basic Relation.

defaults to/is default for

A defaults to/is default for is a Basic Relation.

is/is used as parameter

An is/is used as parameter is a Basic Relation.

is a/is type of

An is a/is type of is a Basic Relation.

is created by/creates

An is created by/creates is a Basic Relation.

is of/is type of

An is of/is type of is a Basic Relation.

referenced as/references

A referenced as/references is a Basic Relation.

results

A results is a Basic Relation.

uses

An uses is a Basic Relation.

uses

An uses is a Basic Relation.

represented in/contains examples of

A represented in/contains examples of is a Basic Relation.

is done by/does

An is done by/does is a Basic Relation.

is implemented by/implements

An is implemented by/implements is a Basic Relation.

iterates

An iterates is a Basic Relation.

triggers

A triggers is a Basic Relation.

drives

A drives is a Basic Relation.


Table 25. 


Table 26. 


00. model relations

Table 27. 

[0]

[0] is a contains.

[1]

[1] is an is of/is type of.


1. Requirements

Categorize transactions

Table 28. 

Figure 18. Categorize transactions

Categorize transactions


Refuse work if the accuracy of predictions are too low

Is an Objective.

connections:

The user is presented with the most probable category combinations, and chooses one of them

Is an Objective.

connections:

Use an AI to categorize the transactions

Is an Objective.

connections:


Transactions are in a database

Table 29. 

Figure 19. Transactions are in a database

Transactions are in a database


The record data is provided by the user in CSV

Is an Objective.

connections:

The records are updated in the database

Is an Objective.

connections:

Use category combinations determined in the database

Is an Objective.

connections:


The project should not impose constraints

Table 30. 

Figure 20. The project should not impose constraints

The project should not impose constraints


The important AI parameters should be tuneable

Is an Objective.

connections:

All aspects of the database structure are configureable

Is an Objective.

connections:


The user should be informed

Table 31. 

Figure 21. The user should be informed

The user should be informed


Information about the record and possible choices should be presented to the user in a way that makes it easy to comprehend, and contains all information needed by the user

Is an Objective.

connections:

The accuracy of the model and probability of predictions should be shown

Is an Objective.

connections:


Table 32. 

Figure 22. Requirements

Requirements


Categorize transactions

Is a Policy.

connections:

Transactions are in a database

Is a Policy.

connections:

The project should not impose constraints on the database structure, and be adaptable for various needs

Is a Policy.

connections:

The user should be informed about significant circumstances

Is a Policy.

connections:


2. Process

0. Process overview

Table 33. 

Figure 23. Process overview

Process overview



1. The user's project

external script

Table 34. 

Figure 24. external script

external script


external script

Is an External type.

connections:

Problem set csv

Is a Business Object.

connections:

Training set csv

Is a Business Object.

connections:

gets dataset from database

Is a Behaviour.

the dataset is put into a CSV, containing columns for at least: - id: the id of the row in the database - comment: a text compiled from the fields of the record, on which the AI decides - category id: a small number representing the (combination of) category(es) for the row

connections:

gets problemset from the database

Is a Behaviour.

the problemset is put into a CSV, containing columns for at least: - id: the id of the row in the database - comment: a text compiled from the fields of the record, on which the AI decides

connections:

starts categorizer

Is a Behaviour.

by setting up PYTHONPATH to contain the config for the preoject, and calling the CategorizerAI script

connections:

problem_set.csv

Is a Test Artifact.

1115 boo 1116 fefefe

connections:

training_set.csv

Is a Test Artifact.

1112 abc 2 1113 cő 3 1114 efgh 3 1118 baz 1

connections:


csv file

Table 35. 

Figure 25. csv file

csv file


column list

Is a Property.

connections:

filename

Is a Property.

connections:

csv file

Is a Type.

connections:


Config

Table 36. 

Figure 26. Config

Config


Config

Is a Configuration provider.

connections:

PROBLEM_SET_COLUMNS

Is a Constant.

connections:

PROBLEM_SET_FILE

Is a Constant.

connections:

TRAINING_SET_COLUMNS

Is a Constant.

connections:

TRAINING_SET_FILE

Is a Constant.

connections:

MIN_ACCURACY

Is a Constant.

connections:

FIRST_LAYER_NEURONS

Is a Constant.

connections:

SECOND_LAYER_NEURONS

Is a Constant.

connections:

BATCH_SIZE

Is a Constant.

connections:

PROBLEM_SET_ID_COLUMN

Is a Constant.

connections:

PROBLEM_SET_INPUT_COLUMN

Is a Constant.

connections:

TRAINING_SET_INPUT_COLUMN

Is a Constant.

connections:

TRAINING_SET_OUTPUT_COLUMN

Is a Constant.

connections:

OPTION_DISPLAY_FORMAT

Is a Constant.

connections:


Table 37. 

Figure 27. Get Data From database

Get Data From database


User

Is a Role.

connections:

Get data from database

Is a Process Step.

connections:


2. categorizerai

data

Services and DTOs

NumericConverterService

Table 38. 

Figure 28. NumericConverterService

NumericConverterService


inputSet

Is a Parameter.

connections:

max_length

Is a Parameter.

connections:

NumericConverterService

Is a Service.

connections:

Input set

Is a Business Object.

connections:

input array for AI model

Is a Business Object.

connections:

Convert strings to numeric arrays

Is a Process Step.

connections:

NCS.ARRAY_SIZE

Is a Behaviour.

the array contains a row for each string

connections:

NCS.ROW_SIZE

Is a Behaviour.

the row contains as many elements as characters in the string

connections:

NCS.ELEMENTS

Is a Behaviour.

Each element in the row corresponds to the codepoint of the character in the string

connections:

TRAIN_SET_VALUES

Is a Test Artifact.

numpy.array(list(DbTestData.trainComments))

connections:

MAX_LENGTH

Is a Test Artifact.

6

connections:


PrepareDataService

Table 39. 

Figure 29. PrepareDataService

PrepareDataService


PrepareDataService

Is a Service.

connections:

problemSet

Is a Parameter.

connections:

trainSet

Is a Parameter.

connections:

data for AI

Is a Business Object.

connections:

trainset dataframe

Is a Business Object.

connections:

problemset dataframe

Is a Business Object.

connections:

Calculates maximum string length

Is a Process Step.

using both the problem set and training set

connections:

calculates number of output neurons

Is a Process Step.

connections:

prepares problemValues for AI

Is a Process Step.

connections:

prepares trainValues for AI

Is a Process Step.

connections:

prepares trainResults for AI

Is a Process Step.

connections:

prepares problemOids

Is a Process Step.

connections:

data

Is a Test Artifact.

self._makePreparedData()

connections:

TRAIN_SET

Is a Test Artifact.

pandas.read_csv(Config.TRAINING_SET_FILE,'\t',encoding='utf-8',names=Config.TRAINING_SET_COLUMNS)

connections:

PROBLEM_SET

Is a Test Artifact.

pandas.read_csv(Config.PROBLEM_SET_FILE,'\t',encoding='utf-8',names=Config.PROBLEM_SET_COLUMNS)

connections:


Table 40. 


Table 41. 

Figure 30. prepare data for AI

prepare data for AI


data

Is a Package.

connections:

DataTestData

Is a TestData.

connections:


Services and DTOs

CategorizerService

Table 42. 

Figure 31. CategorizerService

CategorizerService


CategorizerService

Is a Service.

connections:

loads problemset from csv

Is a Process Step.

connections:

loads training set from csv

Is a Process Step.

connections:


Table 43. 


ai

Services and DTOs

AccuracyCheckService

Table 44. 

Figure 32. AccuracyCheckService

AccuracyCheckService


Accuracy

Is a Parameter.

connections:

AccuracyCheckService

Is a Service.

connections:

ACCURACYCHECK_FAILURE_HANDLING

Is a Behaviour.

If the accuracy is below MIN_ACCURACY, it displays the error message and exits the program

connections:


NeuralNetBuilderService

Table 45. 

Figure 33. NeuralNetBuilderService

NeuralNetBuilderService


NeuralNetBuilderService

Is a Service.

connections:

max_length

Is a Parameter.

connections:

numberOfOutputNeurons

Is a Parameter.

connections:

Neural net

Is a Business Object.

connections:

number of categories

Is a Business Object.

connections:

maximum string length in all records

Is a Business Object.

connections:

There are three layers in the model

Is a Behaviour.

connections:

All three layers are Dense

Is a Behaviour.

connections:

The number of neurons is configureable

Is a Behaviour.

in the first two layers

connections:

the number of output neurons

Is a Behaviour.

is used from the parameter

connections:

model

Is a Test Artifact.

self._initModel()

connections:

OUTPUT_NEURONS

Is a Test Artifact.

4

connections:


NeuralNetTrainerService

Table 46. 

Figure 34. NeuralNetTrainerService

NeuralNetTrainerService


model

Is a Parameter.

connections:

NeuralNetTrainerService

Is a Service.

connections:

trainResults

Is a Parameter.

connections:

trainValues

Is a Parameter.

connections:

model accuracy

Is a Business Object.

connections:

trainValues

Is a Business Object.

connections:

trainResults

Is a Business Object.

connections:

compiles the model

Is a Process Step.

loss function is sparse categorical crossentropy optimizer is adam

connections:

trains the model

Is a Process Step.

connections:

returns model accuracy

Is a Process Step.

connections:

TRAIN_VALUES

Is a Test Artifact.

"train_values"

connections:

TRAIN_RESULTS

Is a Test Artifact.

"train_results"

connections:

ACCURACY

Is a Test Artifact.

0.78

connections:


AIData

Table 47. 

Figure 35. AIData

AIData


AIData

Is a DTO.

connections:

max_length

Is a Property.

connections:

numberOfOutputNeurons

Is a Property.

connections:

problemOids

Is a Property.

connections:

problemValues

Is a Property.

connections:

trainResults

Is a Property.

connections:

trainValues

Is a Property.

connections:

AIDataFactory

Is a Factory.

connections:


Table 48. 


Table 49. 

Figure 36. ai

ai


ai

Is a Package.

connections:

build AI

Is a Process Step.

connections:

check model accuracy

Is a Process Step.

connections:

Train AI

Is a Process Step.

connections:

AITestData

Is a TestData.

   def _initModel(self):
       model = MagicMock()
       history = MagicMock()
       model.fit.return_value = history
       history.history.get.return_value = [self.ACCURACY]
       self.model = model

connections:


ui

Services and DTOs

DisplayAccuracyService

Table 50. 

Figure 37. DisplayAccuracyService

DisplayAccuracyService


DisplayAccuracyService

Is a Service.

connections:

accuracy

Is a Parameter.

connections:


AccuracyErrorDisplayService

Table 51. 

Figure 38. AccuracyErrorDisplayService

AccuracyErrorDisplayService


AccuracyErrorDisplayService

Is a Service.

connections:


ChoiceAskService

Table 52. 

Figure 39. ChoiceAskService

ChoiceAskService


ChoiceAskService

Is a Service.

connections:

choice

Is a Business Object.

connections:

ANSWER_TO_CHOICE_PROMPT

Is a Test Artifact.

"42"

connections:


OptionDisplayService

Table 53. 

Figure 40. OptionDisplayService

OptionDisplayService


OptionDisplayService

Is a Service.

connections:

choiceNumber

Is a Parameter.

connections:

probability

Is a Parameter.

connections:

categoriesForAnswer

Is a Parameter.

connections:

tuple of categories and the ID of the combination

Is a Business Object.

connections:

probability of an answer

Is a Business Object.

connections:

number of the choice offered

Is a Business Object.

connections:

OFFERED_CHOICE

Is a Test Artifact.

self.UpdateTestData.resultKeys[0]

connections:

ANSWER_PROBABILITY

Is a Test Artifact.

self.UpdateTestData.data.problemValues[0][2]

connections:

CATEGORY_TUPLE

Is a Test Artifact.

self.UpdateTestData.categories[3]

connections:


TransactionDisplayService

Table 54. 

Figure 41. TransactionDisplayService

TransactionDisplayService


TransactionDisplayService

Is a Service.

connections:

row

Is a Parameter.

connections:

transaction from the database

Is a Business Object.

connections:

fetched_row

Is a Test Artifact.

self.all_rows[3]

connections:


Table 55. 


Table 56. 

Figure 42. ui

ui


display an error message about accuracy being low

Is a Process Step.

connections:

display model accuracy

Is a Process Step.

connections:

ask the user about choice of categories

Is a Process Step.

connections:

Display choice for user

Is a Process Step.

connections:

Display a transaction

Is a Process Step.

connections:

ui

Is a Package.

connections:

UITestData

Is a TestData.

connections:


update

Services and DTOs

ChoiceObtainerService

Table 57. 

Figure 43. ChoiceObtainerService

ChoiceObtainerService


ChoiceObtainerService

Is a Service.

connections:

obtain user's choice on the category

Is a Process Step.

connections:

compute chouce from the answer

Is a Process Step.

connections:

COS.number

Is a Behaviour.

if a user entered the number of a choice offered, then the categories corresponding to that are returned

connections:

COS.None

Is a Behaviour.

If the user did not enter Anything, then None is returned

connections:

COS.categories

Is a Behaviour.

The regex matching with legitimate choices is CHOICE_FORMAT_REGEX. If the user entered a string of categories separated by a ',', then a tuple of those strings are returned.

connections:

options

Is a Parameter.

connections:

CHOICE_FORMAT_REGEX

Is a Constant.

connections:


choices

Table 58. 

Figure 44. choices

choices


categories

Is a Business Object.

connections:

choice

Is a Business Object.

connections:

choices

Is a Business Object.

connections:

key

Is a Property.

connections:

probability

Is a Property.

connections:

value

Is a Property.

connections:


OptionPreparatorService

Table 59. 

Figure 45. OptionPreparatorService

OptionPreparatorService


OptionPreparatorService

Is a Service.

connections:


Table 60. 


Table 61. 

UpdateTestData

Is a TestData.

   def _makePreparedData(self):
       data = MagicMock()
       data.problemOids = self.DataTestData.PROBLEM_OIDS
       data.problemValues = self.DataTestData.PROBLEM_MODEL_RESULT
       data.numberOfOutputNeurons = self.DataTestData.OUTPUT_NEURONS
       data.max_length = self.DataTestData.MAX_LENGTH
       return data

connections:


db

Services and DTOs

CategoryService

Table 62. 

Figure 46. CategoryService

CategoryService



Table 63. 


Table 64. 

DbTestData

Is a TestData.

connections:


Table 65. 

Figure 47. Compute suggestions

Compute suggestions


CategorizerAI

Is a Project.

connections:

categorizerai

Is a Package.

connections:

Update database with categories

Is a Process Step.

connections:


not yet modeled

Table 66. 

Figure 48. Test Data

Test Data


decide on the categories

Is a Process Step.

connections:

obtain categories

Is a Process Step.

connections:

Obtain database connection

Is a Process Step.

connections:

prepare data for AI

Is a Process Step.

connections:

prepare options for a row

Is a Process Step.

connections:

run AI on problem set

Is a Process Step.

connections:

Update data

Is a Process Step.

connections:

update one row

Is a Process Step.

connections:

update the row in the database

Is a Process Step.

connections:

all_rows

Is a Test Artifact.

[

(1112, "abc", 11.12, "a", "b" ),
(1113, "cő", -11.13, "d", "e" ),
(1114, "efgh", -11.14, "d", "e" ),
(1118, "baz", -11.18, "e", "f" ),
(1115, "boo", 11.15, None , None ),
(1116, "fefefe", -11.16, None, None )

]

connections:


External dependencies

Table 67. 

Figure 49. External dependencies

External dependencies


numpy.ndarray [numpy.ndarray [float]]

Is an External type.

connections:

numpy.ndarray [int]

Is an External type.

connections:

keras.Model

Is an External type.

connections:

int

Is an External type.

connections:

list[list[int]]

Is an External type.

connections:

list[int]

Is an External type.

connections:

list[str]

Is an External type.

connections:

float

Is an External type.

connections:

pandas.DataFrame

Is an External type.

connections:

numpy.ndarray [str]

Is an External type.

connections:

str

Is an External type.

connections:

User's own project

Is an External Project.

connections:

record categorization

Is an External package.

connections:

Keras

Is an External Project.

connections:

numpy

Is an External Project.

connections:

pandas

Is an External Project.

connections:

Python core

Is an External Project.

connections:

tuple

Is an External type.

connections:

dict

Is an External type.

connections:


Table 68. 


Deviations