Saturday, 3 August 2019

Objects Graph, Model of a Program.

In this article we consider 'interactive' applications, uses of 'improper algorithms'.


Directed Objects Graph can be a model of a program, or can be data model as well.

Values of Objects' references/pointers/handles/etc ... are also a part of state, as any variable's value is, as well.

... in a Directed Graph we have 'dots & arrows', 'nodes & arrows'.

... in a directed object graph, objects are 'dots/nodes', references/etc are 'arrows'.

Graphs can be either 'directed' or 'undirected', but in this article we don't need to use 'undirected graphs'.


Classes are something as 'objects blueprints', a part of application's static resources.

After Classes are written & ready, objects can be created.


... i call objects graph's construction, including initial state's set-up: 'Configuration', 'Application Configuration', 'Object Graph Configuration'.

... resources as graphic image files, dvd iso files, localization text files, etc ... are also a part of application's static configuration, can be used in objects graph as a part/whole of objects graph's initial state.

... different versions of application are just different objects graphs, with different initial state. Different versions sometimes do not need to be backward-compatible, sometimes are wholly different software - more than functionality reductions and new functionality additions. Code should be reusable, usable in many projects.

... initial state can be static, 'hardcoded' or dynamically loaded from input/output devices as keyboard, mouse, graphic tablet, eye-retina scanner, a file from persistent memory, a data from database indirectly acquired via DBMS
/ Database Management System /, or a report from 'web-service' acquired via the internet socket, etc.

'Initialization Phase' has to complete fully, before application can enter different 'mode/state' in which it starts working, doing it's job.


Objects graph configuration can be done manually - in one of 'entry points' to application, or tools as Java's
'Spring Framework' with it's 'xml configuration' can be used.

After objects graph is configured, we can 'launch' a proper entry point / for example: one of main(...) methods /, so application starts.


Here we can use 'root object' as 'entry point', 'but root object' can also be referenced, we can have 'cycles/loops' in our graph.

We can have many 'entry points', and many 'root objects' ... but eventually we might need to choose which 'entry point' to use at that moment, which 'application/version' to run this time.


Summarizing, object-oriented application's development & launch goes through following phases:

Minimum requirements:
1. Write Classes,
2. Construct Objects Graph, setting-up initial state using 'hardcoded' data and 'static resources' as well.
3. Launch one of Entry Points, providing values to arguments if neccessary.
4. Application starts, can enter 'Dynamic Initialization Phase' - if needed,
5. Applicaion switches to 'Running Phase', starts doing it's job,
6. ...

Other considerations:
1. As a part of writing classes: documentation, testing, reports and other quality procedures should be used,
2. Do we need a 'Shutdown Phase', a 'Resource Deallocation / Reporting Phase'?
3. Error handling should be considered,
- for example: what if/when a 'web service' doesn't answer connection attempts / requests? This can occur both in 'Dynamic Initialization Phase', 'Running Phase', as well as in 'Shutdown Phase',
...

'Application Deployment' is something more than 'Application Launch', however.


Concurrency needs:

When one designs objects graph, concurrency needs are to be addressed somehow: 'objects multiplication', 'monitors' and 'router / load balancer with waiting queue' comes to mind at first.

Router queue size & related errors need to be considered as well.

... dynamic 'spawning' and 'despawning' of 'objects' is possible, perhaps managed by 'router / load balancer'.

... 'stateless objects', and 'idempotence' can be useful as well.

... i suspect this amounts to standard java's approach to writing both distributed, as well as in-memory applications.


What's state?

... state can be defined many ways.

... i'll use 'defensive' approach this time:

Phase-approach:
- what we'll configure in static way is 'compile-time object graph' - ready at phase's end,
- what we'll configure in a 'dynamic initialization phase' is 'dynamic-init-time object graph' - ready at phase's end,
- what happens in a 'runtime' is 'runtime object graph' - 'timestamped-snapshot runtime object graph',
...

Infrastructure approach:
- in-memory object graph,
- network objects graphs - with defined internet adresses, port numbers and process names in these nodes,
/ for example: 'ProcessName:myProc1,IPv4:84.108.84.108,Port:108;' /,
...

What about objects created inside method(s) scope(s)?
- scope state(s) are part of object state,
- networking makes data redundancy an issue - not sure how to handle it yet - probably it's wise to consider/include many ways, different tools for different 'situations'.

What's static, what's dynamic?
... dynamic programming allows applications to change without restarting, as well.
... in this case, any modification to application - including editing included resource files - implies static resource.

... perhaps example will help to understand:
- java applications are 'archived' in .JAR files, in .WAR files, in .EAR files, etc. ; to modify application, one has to 'unpack', or just use source code and generate new 'archive'; ... anything within 'archive' is static ... everything else is dynamic data,


What's next?

... events queues can be used as well,
... 'Token Game' can be used as well.

No comments:

Post a Comment