In user interface there are two policies for validation of user input: (1) Edit the whole thing then validate explicitly (a variant is arm the command, then do it or disarm it), (2) Validate each field and validate implicitly (either after each field edition, or when leaving).
The behavior depends of the use case and of the user habits.
So the use case could: Not let the choise to user (mostly for behavior (1)) or let the choise to the user. Is this later case, this behavior could be set at the O.S. level. At global scope, and tunable for each individual use case.
This validation policy is a use case property.

Delivery unit : Component and Assembly
We can see an object, say a car, in two perspectives: 1) The way it is made, and 2) the way it is used.
From the perspective 1) the object is about putting together a set of Components
For 2) the object is an Assembly it interact with, as this Assembly in it self and/or with one part of the interface of its Components.

So, is it interesting to distinguish that two perpectives ?

An Assembly can be a Component of a more general Assembly (a wheel for instance is an assembly of a tyre and of a rim, it is also a component of a car). The reverse is also true.

In software engeneering, this mounting concept is at first usefull in the 1) perspective in order to put to front the notion delivery unit.

Therefore, to the above question the answer is NO. It is not interesting to distinguish that two perpectives.

The Component word is already used in the Composition relation (Cf. UML) between a Composite and a Component. It is also assigning a role to the delivery unit that is as not alway: A car is not always a component (it is rarely in fact).
Therefore, the word Component sould avoided in this context.

Following that thinking, ISA should define the notion of Delivery unit thru an Assembly object.
Assembly :
1/ Assemble Objects and Assemblies.
It specifies its proper Objects and enumerates and qualifies preexiting Assemblies.
2/ Manifest its dependancies.
It enumerate the set of Interfaces and other Assemblies on witch it depends on to work. Objects implementing these Interfaces must be injected or available in a given way, at the appropriate moment by the runtime environnement.
3/ Exposes its own interface (DP Facade).
This interface is a View a) on it proper Objects + b) on the Interfaces of the Assemblies it aggregate.
3/ Specify its internal intercations (DP Mediator)
Describing the way the its proper Objects, internal Assemblies and Dependancies interacts together a) to by operationnal and b) to provide the behavior exposes by its interface.

SOA and OO
* SOA mostly useful to integrate complex systems (contract between provider and consumer). But this contract is often difficult to build (difficulties in SOA adoption – work better when the contract is imposed by one party (the provider) like often in REST API).
– SOA cannot support Object linking or embedding (like in OLE and DDE).
+ SOA is nice to separate concerns in layers. The UI and the business concerns can be well separated.
+ SOA also can offer low coupling via ESB (similar to Mediator OO Design Pattern).
– It complexifies the software building (multiple interfaces, mapping of DTO, layers and systems responsability limits dilemna, etc.).
– It lead to functional oriented implentations (large procedure inside not Object delegation).
* SOA is a declination of the functional paradigm.
– SOA is inefficent on large and complex data (a data grid in a client/server solutions like Microsofte VB or Oracle Forms is for instance much more simple and efficient).

Stream is a good principle to follow for efficiency and scalability. This is truebin computing but not only (energy, etc.).
LL and more gsneraly ISA must be stream oriented. The Observer Design Pattern support is one of the way to follow it.

An Object could be the instance of several Classes thru the dynamic addition mechanism.
Presentation of this Object in a UI can be made thru a polyhedron where each face present a facet, a class, a view for each Class it instanciate.
This polyhedron can be rorated freely by the user. One face can represents the Object summary. A 3D interface make sense here.

Some SOA difficulties :
– Scope
– Granularity (coarse grained vs microservice)
– Transaction (compensation)
– Abtraction levels (montage plan versus effective services and signature)
– Maturity levels
– Promote a functionnal decomposition approach (lack of Business Objects layer)
– All functional decomposition problems pointed out by B. Meyer.

A single 10 characters key is sufficient to ensure privacy.
This key produce long string signature (say 1000 digits) with a 1 way function for authentication. The key it self is never stored, but this signature is stored.
So a brute force attack can try combination of key to retrieve this signature.
If 1 microsecond is needed by a core to try a key and if 1000 core are running in parallel. You try 1000 key per seconds. So pirats can try 100 millions key per day.
With a 10 character keys having a variation exends on 100 characters, you have 1E+20 possible combination.
A pirats need 1E+12 days to break the key, so more than 2 billion years.

`LL`
For OID the format can be a set of sbytes. One for each of this concepts : Class, Object, Grouping, Version, Universe.
The string representation of an OID is not positional to allow more flexibility it is done by a letter prefix followed by the sbyte decimal value. The first letter of the concept. Any no-alphanumeric digit is ignored.
Example:
O40541 : Object with ID 45041
C4229 41621-558 30970 O45041 : Object with ID 45041 of Class e-CS\Pollen UML GUI Designer\Generator\Model reader
C4229 41621-558 30970 O45041 G10574 28306-768 84331 : Object with ID 45041 of Class e-CS\Pollen UML GUI Designer\Generator\Model reader from the France-Paris Group
C4229 41621-558 30970 O45041 V42 G10574 28306-768 84331 : Object with ID 45041 in Version 42 of Class e-CS\Pollen UML GUI Designer\Generator\Model reader from the France-Paris Group
Code
class LongHash {
public static void main(String args[]){
String sClassFullName = "e-CS\\Pollen UML GUI Designer\\Generator\\Model reader";
String sPrefix = "C";
if (args.length != 0){
sClassFullName = args[0];
sPrefix = "X";
}
int iLastIndexOfSeparator = sClassFullName.lastIndexOf("\\");
if (iLastIndexOfSeparator == -1){
iLastIndexOfSeparator = sClassFullName.length() / 2;
}
int iPosition = iLastIndexOfSeparator + 1;
String sNameSpace = sClassFullName.substring(0, iPosition);
String sClassName = sClassFullName.substring(iPosition);
long lNameSpaceCode = getLongPositiveValues(sNameSpace.hashCode());
long lClassCode = getLongPositiveValues(sClassName.hashCode());

private static String format(Long l){
return new java.text.DecimalFormat("#####,####0").format(l).trim();
}
}

Use Case and Reuse Case introduced in the SOA paradigm post.
Be careful to not lead by successive decomposition to some thing like SADT / SART that is not nice and not OO as B. Meyer explains in OOSC.
The UC and RUC should be limited in depth of invocation.
– RUC has Scenarii
– UC inherit RUC
– UC associated with Actor by a Usage relationship
– UC associated with UC by a Usage relationship

=> RUC cannot reuse => RUC is terminal

Connexion:
– 2 wires: Signal and Power +, Power 0. Similar to Ethernet with power supply provided by the synchronization 1 (see above). Static resource allocation can also be used to increase power supply.
– 4 wires: Power +, Power 0, Signal A, Signal B in phase opposition similar to Ethernet.
– 5 wires: 2 AC Power phases (typically 220V/50Hz), 1 Ground, Signal A, Signal B in phase opposition similar to Ethernet.
-140 wires: 64 address bus, 64 data bus, Power +, Power 0, Clock, Peripheral has token, Peripheral interruption request, other wires are reserved for further use.

Save is an operation on persistent objects (it cannot be on class since an object have several ones).
Load is an operation of the O.S.

Object oriented neural network
Example:
Person own Cars between two dates.

What is a Request ?
An objective to KNOW something.

If you can express it in a path with constraints in the model, a formal request (SQL) can be written.
Example: What are the cars a given person own at the moment?

If you cannot write it formally, some “intelligence” have to be solicitated.
Example: What car should I suggest to own to a given Person ?

To do so some formal requests can be injected in input for a given request giving the corresponding output answer of the neural network. This could resquest is a priori sufficient for the system to auto learn.

Neural network can be OO organized. With one neural network (NN) associated with each class for a request.
Example: 1 NN with Car, 1 NN with Person and 1 NN with Own relationship. These 3 NN connected to a 4th NN giving the result of the request.
Possibly the 3 first NN could be shared by several requests.