This page gathers my raw ideas as they appear in my brain. Therefore comments on this page is just something like as idea snapshot. It do not reveal anyhing on Ideal Software Architecture, but the way concepts comes into my conscience.
| Legend |
| The thoughts incorporated in ISA appear with this green box containing the location where this idea is taken into account. |
| The thoughts partly incorporated in ISA appear with this blue box containing the location where this idea is taken into account. |
| The thoughts rejected from ISA appear with this red box containing the location where this idea is rejected if any. |
| The thoughts not actually incorporated in ISA appear with this gray box containing the location where this idea is not taken into account. The purpose of this box is mainly for blog internal management. |
#
Why more than 3 layers is too much
I have often seen that more than 3 layers is often confusing and over add complexity. That in fact it add more problems that it solves. Because layers are here firstly fore separation of concerns, but more that 3 layers make always questions on where (and how) to put things. It also introduces specific problems like how to manage transactions.
Therefore I concluded taht 3 layers is the right number : User interface, Business services, Data (business objects). Thats’s enough ! Even in this way, its also sometime confusing of where to put functions (and even some kind of data).
Intuitivly, I link this 3 numbers to the 3 letters of the MVC framework. V for user interface, M for data layer and C for the business services.
To the fundation of software science that defines a software as follows:
Data => Treatment => Data
Where data and services directly map to that definition. And where user interface is just a look on that process.
#
Concurency
Immutable objects are simple for managing consystency. However they are inefficient in mem ory cunsumsion, in performance because of fréquent memory allocation and in functions.
So a class could have a concurency property with possible values: Immutable (not-threaded), Threaded (one thread per Object).
#
Concurency
Use case could run in two modes: Single thread (one thread for the. Whole UC) or Threaded.
#
Security isolation and SOA and integration
The universe manager mechanism addresses in an uniform, simple and efficient way the security isolation, and the SOA, and also the intégration questions.
The universes forms a hierarchical structure.
Root(public real world)\organisation OR Individuals\Domain\Sub-domain\….\System\Application\Environnement
An object is member of one and only one universe. An object may be a machine, a user, etc. They also could be virtual (virtual machine, virtual users).
In a given universe there is one main manager, the official production, and several submanagers, one per purpose: Integration, test, pre production, training…
The ISA universe and its Purpose mechanism can be used for architecture structures like the layers.
Purposes could be organised in a grid, with an axis per purposes family.
The architecture layers are a mean to avoid coupling in distributed Systems.
#
Security by confident tiers
Security by confident tiers with wich each ends agree on and have a pre-existing crypting key.
The agreement is made thru a class refering to its provenance: The confident tiers.
The problem of this approach is to share a secret with this tiers, which become a vulnerable point.
Using such a tiers only is relevant for non-confidential artefact or for an external attesting of something.
#
Having multiple confident tiers having no links solve the problem
Also see https://en.wikipedia.org/wiki/Certificate-less_authenticated_encryption
#
Security, password and crypting
The password is considered to be the most secure way for authentication by many security specialists.
More generally, the brain is certainly the surest place to keep a secret. Think that with firmware attacks, any storage or network device is a sure place to keep a secret. So where else could we place private secrets ?
So a true strategy realying on passwords and threir managment have to be established.
Some principle could drive :
– As soon as possible, don’t store or send password.
– Have a password policy both sure and acceptable by most humans.
– If storing or sending is necessary, derives the secret from a combinaison of a master password and a local automatic key in a non-reversible ways. This prevent from having a big number of passwords and from cracking have only local impacts.
Other ideas :
– master password dedicated for local storage of 12 digits or more. This password is never stored anywhere.
– usual password of 8 digits or more for OS session.
– Local crypting policy
a) master password hashed to build 100 to 999 random generators.
b) based on the OID, each random generator taken in order encrypt this object or not (chain of responsibility). The last one do the job if it is reached.
c) encrypt the object using the selected random generator initialized with the master password and the OID.
#
Smart pointers
If the process concept disapears, smart pointeurs should be at system scope.
So why not incorporates a Reference counter (volatile) to each Object instance.
#
`LL`: Character string, symbol and text
Definitions :
Character: A written or printed symbol, or letter.
Symbol : A character or glyph representing an idea, concept or object.
The Unicode Standard is a character coding system
Characters string are dedicated to internal computing processing. Computing artefacts like parameters, names, values uses string extensivly.
This kind of string are encoder on 8 bits. It uses the Unicode character set from 0x00 to 0xFF. This range is compatible with ASCII standard. It adds the “Complement Latin1” for code points from 0x80 to 0xFF. This complement includes the most common special characters of european language. Although the whole extend is well defined, software engineers are encouraged to only uses ASCII characters from 0x00 to 0xFF for worldwide ease of use.
Text are dedicated to external textual representation. Document objects uses uses text extensivly, but it they are not alone. Any field typed Text also could need any kind of character of any language.
This kind of text are encoded on 32 bits. It uses the Unicode character set UTF-32. Any field type Text are one of it child are encoded using UTF-32.
“Pure text” class represents directly UTF-32 characters using 32bits. Therefore a sbtyte have enough rooms for 2 characters.
“Rich text” class represents uses 64 bits. The 32 first ones for the UTF-32 character. The 32 others bits for typographical attributes.
32 Mode 1 Mode 2
31 G Index de style
30 I
29 S
28 DS
27 Over
26 Barré
25 Exp
24 Indice
23 Ombre
22 Contour
21 Relief
20 Contour
19 Empreinte
18 Masqué
17 Réservé
16 Réservé
15 Réservé
14 Fnt 16
13 Fnt
12 Fnt
11 Fnt
10 Bg-col 16
9 Bg-col
8 Bg-col
7 Bg-col
6 Fo-col 64
5 Fo-col
4 Fo-col
3 Fo-col
2 Fo-col
1 Fo-col
#
In the style mode, the bit 31 is used to distinguish standards styles from custom ones.
This offers a capacity of more than 1 billion for each kind.
Standard style are registered directly in public search engines. Custom ones are also but qualified by an organization.
In the first case the search string is something like “text style reference 00000004”, in the second “text style reference f000000008 at e-Companion Software”
#
This way allows to draw each character independantly of the others not depending of any preceding style expressed thru a flow (like HTML does and most word processor).
This promote parallel processing and speed of rendering. The static mode also allows to put it in silico making rendering far quicker and leaving rooms for core processors to do their other jobs.
#
Static & Dynamic
Computer science is a 4D world,
Point in this space give the performance and the memory space occuped.
All kind if data structure can Be represented in this
In this space data structure are related or not to a treatment type. Ex: File (bag of bytes), primitive types, characters, Object, RDBMS tables, etc.
#
When considering the ISA spaces it possible to structure it like that:
* Multiverse : This space is unique and have 2 dimensions
– One that broadly maps to the actual environment notion (Development, Integration, Test, Production, etc.). They are associated to a Process step.
– The second to a Zone : Location.
Each point in this space is a Universe. Points in this space are also spaces.
The origin point is the Public Real world.
Universe managers allows to define “vectors” between 2 Universes. They therefore act as operators in the Multiverse.
It is important to design the Multiverse in a way that do not require any central management.
Universes managers are typically unique per Organization allowing to manage all Process steps for it.
They can interact 2 by 2 by a cross approbation mechanism.
*Universe: This space have 1 dimension containing Nodes.
– Each point in a Universe is a Node (~ a machine) acceded by an 64 bit ID (the cardinal of the Node).
Node of this space are also space. A Node has several properties (resources, real or virtual, etc.).
* Nodes : This space contains Object and have dimensions corresponding to the resources given to Objects :
– Memory address slots : begin address and size of the Object in memory.
– CPUs : the CPU allocated to the Object)
– Time for allocation (the periods of time a given CPU is allocated to the Object. At a given time several Object shares the same allocated CPU.
– Time for execution on the allocated CPU : the periods of time given on the allocated CPU for the Object execution).
– Store : the store on witch the Object is stored
– Storage : begin address and size of the Object on the store
– Network : The network adapter the Object can use
– Bandwidth : an traffic amount are time slot given on the network adapter to the Object
– etc.
This space dimensions are special because they have the capability to have “no value”.
Theses dimensions can also be structured as follow:
– Area (Store, Network adapter, etc.) : Discrete dimension.
– Location (Address on the storage or in memory) : Spacial dimension.
– Time of usage (period of time given to the object to use this resource) : Temporal dimension.
All of these dimensions are candidate to be an axis of monitoring because their are related to resources.
#
These spaces and dimensions should be presents in the model of ISA.
They are not Elements because they are not base building blocks for the language (in most cases at least, possible exceptions: Smart pointer, Exception). But they are often Objects.
For instance, an Assembly Resources is certainly a good artifact for ISA.
#
The Node space doesn’t contains Object, it is the Universe that contain both Nodes and Objects. Just Object are resident on one or several Nodes.
#
Statics close the debate of how to make things.
Dynamics as assemble dynamicaly static structures of same naturev=> best of all worlds.
Dynamics when it applies to concept or fonctions Dynamics by nature (data replication for instance).
Same approach for statics.
The frontier has to be exammined in our 4D wolrd of computer science.
#
Tests
Integrates tests in LL.
Tests are an integral part of a class. Tests should be declined by universe: Unit tests for Developement and Assemblage universe for instance, Integration tests in the Integration universe, etc. even for the Production universe (think about ping). However in the Production universe, in depth tests are features in them selves (use cases).
(Cf. Beautifull architecture page 37).
Have some level of maturity based controls to ensure test coverage and other metrics.
#
`LL` : Migration and generics
For promotion from an universe to an other, the target universe manager could perform a migration of objects of upgraded classes (migration of classes is also a subject not discuted here).
This could be made thru a method of the class having the following signature
migrate(MyClass ExistingObject) : MyClass UpgradedObject.For universe manager to operated uniformly, the migrate operation should be defined on the Class class. The signature would be
migrate(Class ExistingObject) : Class UpgradedObjectBut implementing this operation results in the first signature
migrate(MyClass ExistingObject) : MyClass UpgradedObjectwhich is different.Possible solutions :
– Defines an overide “keyword”
migrate(MyClass ExistingObject) : MyClass UpgradedObject overides migrate(Class ExistingObject) : Class UpgradedObjectwork fine but quite heavy.
– Use generics
migrate(<T> ExistingObject) : <T> UpgradedObjectbut T is not any type but the type of the current class, this is not expressed, or you could add contraints on T : also heavy.
– Use a concept of current class (this on the class)
migrate(ThisClass ExistingObject) : ThisClass UpgradedObjectThe definition is the same in the Class class as in the MyClass. In MyClass the definition could also be
migrate(MyClass ExistingObject) : MyClass UpgradedObjectwhich is just a synonym.The way do not require generics. Its an enrichment of polymorphism.
#
Class, object, instance and views.
An instance is the instanciation of an object in a given execution environment. Typicaly, a persistent object is only instancied in one environment (its master environement). While a volatile and a replicate object is instancied on several environments .
A views is a volatile or replicate object that represents a persistent object.
A volatile object resides only in memory, while replicate are stored locally.
A class is an replicable object. It is a singleton. A singleton is the unique instance of an object in an execution environment.
The class object defines 3 parts :
– the class structure : fields, properties, operations, constructors.
– the object structure : fields, properties, operations, listeners, is singleton, etc.
– the commun structure : name, namespace, inheritance relationships.
#
Date and time
Date and time have to be ditinguished because thay are differents.
A date relates to an era that defines a start point. Its units is the day.
Time have a moving start point and its reference unit is the second. It can expresse an time in a day, a duration, delay.
Therefore, in the LL language Date and Time must be basic types (peraps not primitive in the sence µP should supports them). Date and Time classes could be combined in a DateTime class for giving a precise “date” in the common sence of the term. This is different from a Date+Time object where the two concepts remain seperated (not possible to have add operation for instance).
Date could be expressed with a sbyte. Its starting point is the year 1 of the Gregorian calendar.
Time could also be expressed with a sbyte. The resolution could be the ns, giving a maximum time of 583 years.
#
`LL`
Measurement and instrumentation have to be basicaly incorporated.
More generally, usual and basic features and operations like CRUDE ones, logging, listening, Designe Patterns, etc. have to directly supported.
#
In order to have good performances, object instances and storage (persistence) have to be located on the same physical node.
Cf. Beautiful Architecture P59
#
Locality also applies to server size as pointed out by Beautifull Architecture page 59.
So Object instance and Storage must be on the sole node physical.
This means machines dedicated to RDBMS, storage (disk bay, SAN, and the like) should be avoided.
#
`LL`
On views, operations could be specified as remote or local. Remote ones calls the operation on the remote object while local calls the downloaded method locally.
Remote operations on views is the way to define SOA services. The service concept could be reified has declining the Facade Design Pattern. Views of services objects only have remote operations.
More generally, remote exchange could be classified like this :
– CRUD operations on object/view : send/receive
– Receiving an update notification on a view
– Search on object/view
– Sending/Receiving an object event (?)
– Calling a remote operation on a view of an object that could be a service object.
#
`LL` language calls syntax
Call Me\Person\Compute age difference with arguments : {John\Person\Age} result time in age diffence between Luke and John.Call : The call operation on the class class.
An operation can be defined either by LL instructions or by directives to the compiler.
This last case is used for the call operation on the class class. This is a very powerfull feature that change the way assembly code is produced. The compilers have just to expose the right API to supports the LL language.
The compiler directives could also be exposed by the O.S. This results in : A LL interpreter, an interpreter runnable at early times just after download, a debugger, this interpreter could also be viewed as a rule player, etc. And all of that integrated in the O.S !
Note : This line of code have not any key word, and that specifying a result (type) also to distingish signature by their return type which will increase method overload.
#
`LL`
The Call operation on the class class is not needed because by defaut naming a member is accessing it. Accessing a property is either writing or reading it, on an operation it is either calling it or giving its reference.
#
Akways ask This question.: The existing features can they do it in simplest are more uniform way?
If yes, reject the candidate feature.
#
OO major problems (`LL`):
Unitary oriented, do not supports well transversal behaviors, static inheritance is rigid.
It also is not a natural approach for humans, at least at first, because they are more procedural, case of use oriented. There is the noticeable exception of direct Object manipulation like in drawing software and also while less in document editing software.
#
Configuration of a module : see Beautiful Architecture page 69
#
Consider persisting tasks (services, publish/subcribe, etc.), as they did in game server at Beautiful architecture page 60, by saving either client side calls or incoming calls on server, in order to increase availability.
#
REX interesting on OO design and concurrency at Beautiful Architecture page 61.
#
User Interface management
Model:
The model is the object it self. It is generaly represented by a view.
This view can either be derived or enriched by Displayable View or Editable View that has respectivly display and edit operations.a
It is important to enrich the model object/view in order to not break the encapulation OO principle.
These views also take presentations context properties like : Layout, Look and feel.
Tis model object/view also have (business) operations that controls dynamically the conditions of the presentation like: hidden/show, enabled/disabled, etc. (Cf. like in Pollen UML GUI Designer). Therefore there is no disruption between view rules and business rules.
Look and feel (View):
It comes from the use cases. It follows the principle and scope of the look and feel of Java Swing. It can be recovered for the operating system.
Layout (View):
It could either be automatic (Cf. like in Pollen UML GUI Designer or in IDE properties editors) or specified externally (in the manner of HTML or XAML).
In the first case a Layout Manager class is specified.
In the second one a Layout Object is provided. The object only have layout properties. Each layout property maps to a model object/view property. This mapping could be done thru an indirection for more flexibility.
A layout property defines the presentation : location, color, font, etc. The Layout Object is typicaly edited thru a graphical designer tool like Microsoft Blend.
CSS3 appears as a good base for the properties of a Layout object.
Use case (Controler):
Use case objects are also objects and follow the same presentation mechanism presented above.
They moreover have operations that are mapped to actions in the layout.
#
See Beautiful architecture page72
#
`LL` Replicate
A View are a local representation of an Object. It is typically updated following one of this case : Snapshot (not synchronised)asynchronously (after transaction finished), synchronously (within transaction). The Object is the master.
A Replicate are multiple instances of the same Object. There is no master. Synchronisation is preferably asynchronous in order to allows offline terminals to be updated or to push their updates of the Replicate they own. A reconciliation mecasnism have to be established.
The Replicate is important to allows peer to peer updates without needing a central (could) server to centralise the Object.
#
Expression of specific encoding
My number:f369 ed89(b16).
A 32 bits value expressed in hexadecimal put in my number variable.
Parenthesis enrich an expression as usual in common languages.
Values: b2, b16, b64, BCD, etc.
#
Where are functionnalities?
Question have to be addressed by the `LL` language. Incoporating Use Case is not a gadget but a major feature as Beautiful Architecture page 36.
An other advantage of Use Case approach, and above them of requirements managment, is that they promote YAGNI (You ain’t gonna need it – Cf. Beautiful architecture page 37).
#
Conceptual integrity, consistency => one way to do one thing
Beautiful Architecture p21
#
Application façade DP at page 76 of Beautiful architecture express not linking domain and façade objects.
=> consider having View consolidating several objets…
#
Separation of concerns
> Root of all Design Patterns
http://stackoverflow.com/questions/389318/ideal-net-architecture
>Layering => Low coupling
Observer DP update of object traversal all layers to view or replicate (in/after transaction) => layering principle compatibilty ?
http://www.supraliminalsolutions.com/blog/listings/software-construction-ideal-architecture/
#
In fact it doesn’t break the layering principle. It breaks the client/server paradigm.
Client/server relies on request from client with associated response from the server. In a distributed architecture, this paradigm makes less sense. In particular for events and data coming for “back” nodes to “front” ones. This is the case for Observer DP, but also for kind of application like supervision consoles (thing about HTML 5 Senver Sent Event that are not client server by essence).
So client/server is broken. That’s not rely a problem for layering. Just layers can be traversed in the two ways ! That’s the more important.
The client / server paradigm is mutated in a front end / back end approach.
#
`LL` syntax
In method calls, only variables, properties or true values should be allowed.
In this way previous operation results are allways put in some kind of variable.
This have the following advantages :
– A line of code has a complexity limitation. It eliminates very cryotic ones that geeks like.
– Lines of code are more homogen, and that render the LoC metric more accurate.
– The code is more simple for everyone.
– Facilitate smart pointer usage.
– Optimisation can be done easily by compilers.
#
Requirements
Add or incorporate a wish to support the software developement process from specifications, design, realisation, tests, etc. thru environnements (already taken into account thru uniserses) and abstraction levels.
Abstraction levels should be done via multiple in depth raffinements (like in SADT/RT method), more than in isolated levels and traceability links.
#
The specification thru abstract levels could be done using : system, use case, top level use case, services that are also a kind of use case invoked by a system, and also using “up views”.
In `LL` it is refered in this brainstorming section as view that are a more specific aspect of a class (let call them “down view”). Symetricaly, an “up view” concept can also be defined to specify a more general aspect of a class.
#
The key point here is to have a single object that supports all abstraction levels, this is a guaranty of synchronisation between this levels.
This feature is not supported this way because all Object will be overloaded be these data.
However, Assemblies and View concept are supported, and Assembly are attached to a “Process Step”.
Connexions between abstraction levels will be addressed in a further iteration of the LL metamodel.
#
This requirement should embrase more generally a large part of the software life cycle.
This include :
– Spécification
– Design
– Realization
– Test
– Deployment (including migration)
– Monitoring (log and statistics)
ISA should offers foundations and ground floor for all these life cycle steps.
#
`LL`
To inject features dynamicaly, like log, monitoring and the like, plus those I can’t imagine, it is important to have an efficient mecanism.
The prefered way seems to be “hooks” that can be incorporated in the class at runtime by native compilation. This hook could be any arbitrary piece of code that can only interact with the public interface of the class.
Metaproperties on the class and on operation can be defined to allow hooks, logs, etc.
#
`LL` native code compiler
In order to make more easy the development of platform specific LL compilers, the following options could be made :
1/ Provide a meta-compiler where µP founders can incorporate theirs instruction set and specificities (how to do it ?).
2/ Provide a Pre-compiler that optimize the LL code in itself before executing the Compiler.
#
LL and basic type usage
Statistics of usage of type on a typical Web Application
private String 590 => 47%
private Date 187 => 15%
private Boolean 40 => 3%
private Integer 289 => 23%
private Long 15 => 1%
private Double 4 => 0%
private Byte 0 => 0%
private Short 130 => 10%
private Float 0 => 0%
private Character 0 => 0%
1255
#
`LL`
Boolean -> Not optimized
Integer -> Primitive type on 1 sbyte => Optimal
Date -> Primitive on 1 sbyte with separation of Date and Time for accuracy and performance => Optimal
String -> The most important to optimize -> Primitive, mutable gives a first optimisation level.
The String operations must be supported by the O.S. (and even by the microprocessor).
Smart pointer can support Object and String directly:
-21 bits (lower ones) for reference counter
-21 bits for object/string current size
-21 bits for buffer size
– 1 extra bit to signal exented representation on 3 sbytes of theses data.
=> 2M of reference or size.
=> No need to memory occupation table for the O.S. just a table of smart pointers.
#
`LL` : String as primitive type
String primitive type implementation have the following properties :
– Representation : Pointer to the string primitive type. The first sbyte contains the Length, and the buffer follows.
– Instruction set : copy(src, dst), compare(s1, s2) , concatenate(s[]).
In LL, the concatenation is done with the + sign. The compiler works as follow : in a line all strings are computed and then the resulting table is passed in argument to the CPU intsruction concatenate(s[]).
Remark : The copy and concatenate instructions poses the problem of memory allocation and of its managment (program, OS, CPU ?).
#
The difference with existing instructions set, of x86 for instance, is (1) the knowledge of the string structure (2) the capability to allocate memory (the caller has just to give a next available address and the maximum allocated size) and (3) to supports natively all operations of java.lang.String / System.String plus the string building (append, susbtitutions, etc.).
#
Single instruction advantages :
– Another interest is to have non interruptible instructions.
– Moreover this is more perfoamnt because you don’t have to follow the program flow with ordinal counter increment, instruction loading, etc.
#
Smart pointer functions : avoid direct object access in particular to write directly the length of string.
#
`LL`
Mutable / Unmutable objects and in particular basic types (like string)
If there is a thread per object, all variables and fields can be mutable.
Return type should be protected against concurence because it is shared between caller/called threads. However, if there is not static variable and that fields are prohibited to be directly returned, it could not be a problem because the called thread don’t know anymore the returned variable and the caller thread is the only one to know it.
#
`LL`
Basic asynchronous call are addressed by the one thread per object approach.
For long latency calls, the Observer DP implanted on each object is used to notify the caller of the end of the long time action. Also think about a time out throw. The obversed object is then called to know the long call status and more.
Exemple:
class header definition + Connexion observer
Connector connector : new Connector(“an address”).
Add me as observer of connector on connected event.
…
on connected event(Connector c){
Condition c.status;
when connected: bla bla.
when time out: bla bla.
}
#
An Event Producer are autonomous and doesn’t care about others.
An Event Interested wants to know about these events.
1/ Polling is the right answer from both point of view : only concerned entities do the job for it.
=> It is inefficient in time, in processing, in traffic.
2/ To avoid polling, the Event Producer must tell that an event occurs.
=> It does more that it needs in it self. It cares about its Event Interested.
2-a/ It tell the event to an Event Intermediate that in turn notify Event Interested.
=> A central Event Intermediate is needed (mediator) and known by every ones.
2-b/ It tell the event directly to Event Interested.
=> The Event Producer must also know about its Event Interested.
Deciding.
– Both solutions 2-a and 2-b can be made more or less fault tolerant. It is certainly even easier for 2-b that could delegate guaranteed delivery to the network (as TCP/IP does).
– The ultimate criteria appears to be about distribution : Do you want your system to be distributed or could it centralized ?
In a distributed approach like ISA the 2-b solution is preferred.
#
2-a is more usual for Event processing in real work because it decrease coupling and enhance reliability. For instance JMS uses Topic and Queue mechanism for that. A mediator is needed, like the Web Methods UM. In ISA the mediator must be at the distributed and supported by OS. This means that on the wire it is only a question of protocol, the approach is therefore closed of the AMQP one.
=> Approach 2-a must be selected.
#
A typical method call results in this sequence:
Caller operation :
1/ Call operation on called, put in the called stack.
2/ Make other call and instructions.
3/ Wait for called operations to finish (rendez-vous).
Called operation:
1-1/ Unstack a call from a given caller
1-2/ Pre-Check
1-2-1/ Access rights
1-2-2/ Operation pre-conditions
1-3/ Pre-treatment
1-3-1/ OS pre-treatment
1-3-2/ Class pre-treatment
1-3-3/ Object pre-treatment
1-3-4/ Operation pre-treatment
1-4/ Operation treatment
1-5/ Post check
1-5-1/ Operation post-conditions
1-5-2/ Class invariants
1-6/ Condition on exception thrown from 1-1 to 1-5
1-6-1/ When exception occurs,
1-6-1-1/ Clear calls in stack from the given caller
1-6-1-2/ Return exception.
1-6-1-3/ Signal rendez-vous with caller
1-6-1-4/ End
1-6-2/ Otherwise,
1-6-2-1/ Stack return values.
1-6-2-2/ Condition on calls in stack from the given caller
1-6-2-2-1/ When calls exists, jump to 1-1/
1-6-2-2-2/ Otherwise, Signal rendez-vous with caller transmiting return values stack
1-7/ Post-treatment (in particular observer notification) in reverse order of Pre-Treatment
1-8/ End
Also consider putting step 1-7 Post-treatment only when the call stack is empty for any caller.
As in synchronous call systems, inconsistencies have to be treated by caller. The difference here is 1/ that several calls on distinct called can report exceptions, at most one per called object; 2/ that object called after an other called throwing an exception are really called.
Similar inconsistency with synchronous call like this :
Open file f;
For(i = 0; i < 100; i++) Write "i value " & i & "\r\n" in f; Close f; At any time an I/O exception can be thrown letting the file system in an inconsistent state that the program have to deal with.
#
`LL` language
The syntax and the semantic should be lax.
Syntax : the operation arguments could be passed within the operation name declaration.
operations:
name: add.
aliases: add to, added to.
parameters:
name:operand one.
type:number.
name:operand two.
type:number.
syntaxes:
operand one added to operand two.
add operand one to operand two.
}….
possible syntaxes “2 added to 3.6.” or “add 2 to 3.6.” or “add 2 3.6”.
Semantic: If the type is not specified, it is infered or assumed to Object to begin (equivalent of the Variant type in Visual Basic).
#
The syntax flexibility is just a way an changing the expression of a same thing. Flexibility in form not in the meaning.
This variability that breacks the principle of having only one way to do one thing is only acceptable if it increase the comprehensibility in the LL language, if it makes it closer to english.
#
`LL`
Object Orientation is fundamentaly unitary. The interaction way with modules is atomic.
This drives to problems when needing to access structures at an other scale :
1/ A set objects (higher scale).
2/ A field (lower scale).
3/ An operation (lower scale).
Some other paradigms deal better with theses items: Aspect and Relational for 1/ and 2/, Functionnal for 3/.
To solve this problems remaining in the OO world, it is possible to jump at the metamodel level.
1/ Maps to the Class object.
2/ Maps to the Field/Property object.
3/ Maps to the Operation/Method object.
#
`LL`
Some solved problem thru tis meta-model way
A/ Aspect: Transversal behavior can be defined in the Class meta-object as concept on Class, Field or Operation (class invariant, pre-condition, post-treatment, etc.). It can also be added/removed at runtime.
B/ Relationnal : Set requesting is done via operations on the Class object of the targeted Objects.
C/ Functionnal: Operation are made accessible and runnable.
Ex: To manage event driven action we need 3 things : Control, Event type and The action.
The action also need 3 things: A target, an executed action identifier, a set of parameters.
TheControlObject.AddAction(AListFieldNamesOfControlObject, TheTargetObject, TheMethodName, AListOfParameters);
– TheControlObject -> Control.
– AddAction -> Registering : Observer DP available on all objects.
– AListFieldNamesOfControlObject -> Event type : The list of fields of the control object throwing the event when a change occurs.
– TheTargetObject -> Target : The object target (can be a class object).
– TheMethodName -> Executed action identifier : The name of the Operation on the target object.
– AListOfParameters -> Parameters set : The parameters values.
Problem : In this exemple, the action have to closed at the moment the AddAction instruction is executed. Not at time the event occurs.
#
Another way to address the OO problems, and also the more important ones of other paradigms, could be to create a new paradigm.
This new paradigm sould be both as modular as Object Oriented software and as super down and up scaling.
In my experience, the only way to get a fine grain result, is to work at this finest grain scale. When you aggregate, you loss some information. Therefore, it appears that it is necssary to work at the basic constituant level : the atom.
In this approach, atoms are of two kinds : data (field) behavior (function).
You can assemble the atoms to constituate molecules (object).
You can group similar molecules together to elaborate a uniforme element (class).
You operate on atoms or element together in a recipient (package, aspect, set, table, column, etc).
We can call this paradigm Atom Oriented.
#
`LL`
Modules Use Cases
A Module have several use case, visual or not, that allows to manage it.
In particular, there is a UI use case for add/remove of calls on pre-treatment and post-treatment on a class. This management scope can be at the class, the object or the instance level.
This mecanism can applies to monitoring, log, etc.
In any case, these add/remove pre/post treatment do not modify the object behavior in any way (encapsulation).
Pre-treatment have read access to the object and its arguments. Post-treatment have moreover read access to returns.
They can be conditioned : on exception, on normal end, on a particular argument or property value, etc.
The module use cases, give access to its sub-modules use cases.
#
Avoid null
See if it is possible in `LL` to avoid having null pointer or null reference. For C# 7 there is proposal around this problem.
see https://github.com/dotnet/roslyn/issues/5032
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/nullable-types/index
#
`LL`
In representing objects, see how to implement a flat representation allowing to directly store/load from the disk.
This is easy for fixed length properties, like boolean, integer or OID to objects (relationship). For variable length primitive types, and in particular strings, this can be done by a length first sub-field followed by the character sequence.
This direct mapping will greatly improve I/O and perhaps some computation.
#
`LL`
See how to replace filter/map and functionnal programming like behavior by SQL request with Selection and Projection.
SELECT (* | View) -> Map
FROM (Class [IN Collection] [AS Alias]) +
JOIN (BY Relationship | WITH Role) * -> Filter
WHERE (condition) * -> Filter
#
This SQL like idom should be the way of expressing an internal DSL.
DSL could be done by an API.
In this case it could be some thing lie that :
Variable request: OS make query request.
Variable response: request execution with select: MyPersonEmployeeView, from {{Class:Person, Alias: P}, {Class: Employee, Alias: E}}, join {{P + E}}, where { {P age > 50} and {E salary < 20000}}.
#
`LL`
This syntax don’t look very sexy isn’t it ?
We can use semicolumn for separator of first order (between parameters for instance) and column for separator of second order (between list elements for instance), as it is natural language.
Moreover, It is possible to use parenthesis to add information on an expression, also like in natural language.
Plus using commun logical operators & for instance.
And finally use also a positionning parameters mecanism, as usualy in programming language.
The sentence become:
Variable response: request execution parameters: select: my person employee view; from: Person(P), Employee (E); join: P + E; where: person age > 50 & E salary < 20000.
#
`LL`
A DSL opposite way could be to use the mathematical language to express conditions, and also why not the ensemblist operations.
In this case the syntax looks like that:
∀ P ∈ Person, ∀ E ∈ Employee, Person ∩ Employee ↦ my person employee view ∣ P age > 50 ∧ E salary < 20000.
Not necessarly clearer but certainly more general and powerful (possible support for all ensemblist and Bool algebra operators).
Perhaps that approach is not in line with the wish N°5 – Simple and freed of experts…
#
An approach could be to use the mathematical language as the `LL` normal way of expressing ensemblist and Bool algebra operators, having the advantage of the completude and universality of the unicode mathematics symbol set; and, additionnaly to build an SQL like and Boolean like DSLs on top of it having the advantage of the experience of computer science.
This have the following virtues:
– Having both universal powerful language and an usual one for IT peoples.
– In defining internal DSLs at LL early stage will have the advantage of building basicaly LL as an extensible language
– Concepts coming for mathematics could be incorporated in the SQL / Boolean DSLs that are not actually present
– Alternatively, mathematics could also be fecondated by concepts coming from computer science.
– This approach can be generalised to other languages like regular expression.
#
Often functionnal programming breack encapsulation and therefore modularity.
#
Codification should be incorporated in the base type set as an abstract class with two fields : Code (String) and Label (Text).
Concrete codification inherit from this class and add the semantic.
Other properties like image, short label and the like could be incorporated by field addition or class addition.
#
`LL`
Internationalisation / Translation : The translation is just a particular kind transformation of a Class in a View.
There is no need of any mechanism of text code and resources files.
This apply of course to the Label field of Codification.
Date and number format follows the same rule.
An automatic view mechanism could exist to provide automatically a default internationalized view of a view by providing the language/country transformation rules. The automatic view could be overidden to give some particular translations.
This automatic view mecanism could also be applyed to other purpose that internationalisation.
The autamtic view could be either concrete/static, the transformation is partly or completely done at design time and no connexion is required to use the view; or virtual/dynamic, the transformation is played at runtime.
#
`LL`
Typical View names are New car or Updated car, this means a name composed of the of event the view is supposed to be use followed by the class name.