Discussion :

[SNatoon]

Un IDE entièrement graphique pour Delphi
Est-ce réellement utilisable ?

Un IDE entièrement graphique, conçu comme un assistant complet de création de classes et de code, est-ce l'IDE parfait ? Ou une impasse ?

Voyez sur cette vidéo : StroyCode Demo

Le site de l'éditeur du freeware en question : http://softconstructors.com/en/applications/stroycode/

Et vous ?
Que pensez-vous de ce genre d'environnement de développement ?

[Paul TOTH]

c'est joli, mais à mon avis loin d'être pratique.

à la rigueur lire un source Pascal pour afficher graphiquement les objets comme ça permettrait peut-être d'en facilité la lecture, de documenter etc...mais pour créer les classes je préfère la complétion de code.

[Charly910]

Bonjour,

Tout cela pour éviter de taper ou de recopier quelques lignes de code. Je préfère l'IDE actuel, qui à mon avis a toujours été le meilleur devant les IDE des autres langages.

Est ce que cela fonctionne dans les 2 sens : si on modifie directement le code ?

A+

Charly

[sevyc64]

Ouais, bof !

Je suis pas expert Delphi, mais ça n'a pas l'air de révolutionner le monde.
Ce n'est rien d'autre qu'un assistant de création de classe (ou équivalent).

Avec un bon plug-in qui va bien, ça doit même pouvoir être greffé à n'importe quel IDE.

Est-il capable de faire l'inverse, à partir d'un .pas, régénérer la version graphique ? Pas sur, il n'a pas l'air d'être directement branché sur le .pas mais de le générer à coté.

[GoustiFruit]

Ça a l'air plutôt sympa. Peut-être que ça n'intéressera pas les hard-coders mais pour les débutants, pour apprendre les concepts, et même pour les programmeurs un peu plus avancés qui veulent avoir un aperçu rapide de leur structure, ça me semble utile et bien pensé.
Et en effet ça serait top si il était possible de reconstruire un graph à partir d'un code existant...

[ShaiLeTroll]

Des outils comme Rational Rose le font déjà pour générer les tables et même du code
Tu as plein d'outil de conception UML qui propose une conversion vers Java ou C#

On peut penser que les outils DB de Embarcadero pourrait amener à ce genre
de chose avec une ré-apparition d'une bibliothèque façon BOLD

La bonne chose c'est que c'est orienté objet mais en tant que pro, je peux témoigner qu'au travers les 6 (petites) sociétés que j'ai traversé, la POO est peu maitrisé, souvent ce n'est que TQuery, TForm, TDataModule ou des compos persos héritant de TCustomEdit\TCustomPanel mais pas une vrai programmation architecturé !
Les Design Patterns c'est encore moins connu, alors que la POO sans Pattern, c'est la foire à l'andouille !

Je n'ai que très peu vu des objets métiers !
En une grosse décénnie :
UML, jamais vu !
Diagramme de Classe (DelphiToDoc les génère à partir du code pourquoi les faire avant )
GANTT, 1 fourni par un client et 1 que j'ai fait !
PERT, Aucun
MOT et Diagramme de Séquence, j'en faisais des tout pourris sous Excel ou Visio quand j'étais apprenti en alternance, j'ai totalement oublié comment on en fait depuis !

[Ph. B.]

Sera-ce un IDE parfait? ou impasse?

ils ont réinventé ModelMaker !

Bon, ils ont encore un peu de travail de finalisation...

[ShaiLeTroll]

quitte à utiliser des "objets", autant le faire franco et les manipuler dans l'IDE, plutôt que d'en faire de longues descriptions littéraires à la Balzac

Faut-il en faire !
C'est juste que la modélisation de classe n'a rien de nouveau !
Cela existe même dans Delphi : Diagrammes UML et Delphi

Synchronisation entre le code source et les modèles UML
[ame="http://www.youtube.com/watch?v=LTpAAz3WkZk"]UML Visualize With RAD Studio 2010[/ame]

Je suis sûr qu'on y gagnera en clarté et en efficacité car cela synthétisera, rationisera et uniformisera la conception ET l'écriture du code.

Perso, j'ai déjà ma propre couche objet métier persistant, quand tu as créé plus de 200 classes (en 2 ans), c'est vrai, on oubli un peu ce que l'on a fait !
J'ai prévu de faire un Doxygen, j'utilise déjà ce format de notation dans le code par habitude, faudra que je mouline un coup !

c'est la dimension "temps" dans la structure des applications qui devront être pensées parallèles.

C'est pour cela que l'on est censé faire des Diagramme de Séquence, des MOT, MCT... je n'en fais plus, disons que c'est fait au feeling et par habitude de jouer avec TThread, TThreadList, TMREWS, TCS, TEvent, ...
Je fais des applis proche d'un temps réel en intéraction avec notre matériel, il y a toute une partie de programmation basique proche de l'informatique de gestion, là un seul proc suffit pour afficher une pauvre IHM avec des DBEdit ... et des parties serveur bien plus costauds subissant des milliers de notifications à la seconde !

La parallèlisation de traitement inter-dépendant ce n'est pas évident, semble que le programmeur qui je remplace avait de grosse lacune à ce sujet ainsi un gros manque d'abstraction aussi !

Et encore, ce n'était pas explicite. Toujours est-il que cette démo illustre très bien comment on devra systématiquement tirer parti des architectures multicoeurs dans un avenir très proche.

Oui le but étant plutôt de contourner les limites de bande passante pour un téléchargement.
La sollicitation processeur est minime pour ce cas !

disent-ils, le compilateur sera au programme. pas besoin de savoir pascal

Le compilateur ???
Si leur programme génère du code, il suffit d'avoir celui d'Embarcadero ou même celui de Lazarus !
tu pourrais citer tes sources, je n'ai pas vu cela sur leur site

Si l'outil est en plus destiné à des "non programmeurs" qui ne connaissent pas le Pascal\Delphi, cela signifie que l'ensemble des traitements seront décrit par des graphiques, c'est utile dans un processus de développement très normé, je pense en SSII\Outsourcing avec un fort turn-over et donc facilite la reprise du code grace à la modélisation

Je trouve que Delphi est déjà trop utilisé comme un Clicodrome !
Combien ont des difficultés à faire un Create ou affecter un gestionnaire d'évènement par code parce que l'IDE les a aliénés !

ils ont réinventé ModelMaker !

C'est vrai, je l'avais regardé, il y a un paquet d'année
Je crois qu'il ne fourni pas le support pour C++Builder ! si ?

[Ph. B.]

C'est vrai, je l'avais regardé, il y a un paquet d'année
Je crois qu'il ne fourni pas le support pour C++Builder ! si ?

Eh non, juste Delphi et C#...

[SNatoon]

non, non, non! Aucune UML! vidéo ne reflète pas l'essence! Vous ne pouvez utiliser le clavier sans souris. C'est tout le texte.
vous devriez certainement essayer le StroyCode programme, à comprendre. Je suis maintenant une fan de ce programme.

[Paul TOTH]

..
Perso, j'ai déjà ma propre couche objet métier persistant, quand tu as créé plus de 200 classes (en 2 ans), c'est vrai, on oubli un peu ce que l'on a fait !
J'ai prévu de faire un Doxygen, j'utilise déjà ce format de notation dans le code par habitude, faudra que je mouline un coup !
...

j'aimerai voir la tête de cet IDE avec 200 classes

[ShaiLeTroll]

j'aimerai voir la tête de cet IDE avec 200 classes

J'ai tenté de voir le support intégré du RAD, mon BCB monte à plus de 650Mo de RAM, sachant que je n'ai que 1Go, j'attends d'avoir mon PC neuf pour voir vraiment ce que cela donne !

Pour cet IDE StroyCode, je pense qu'il souffrira des mêmes problème de charge et d'un fouilli sans nom avec des fleches partout avec des classes comme celle qui suit qui fait appel a plus de 10 classes et 20 interfaces (aux implémentations multiples)

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
//---------------------------------------------------------------------------
//                            TShaïCameraCustom                            -
//---------------------------------------------------------------------------
class /*abstract*/ TShaïCameraCustom : public TShaïHardwareProviderAbstractPersistentObject
{
  typedef TShaïHardwareProviderAbstractPersistentObject inherited;
  friend /*method*/ void __fastcall TShaïCameraCustomManager::EventHandlerPurposeEntityChangeStateEvent(TShaïHardwareProviderManager * Sender, IShaïHardwareEntity* AEntity, int AState, void *Data);
  friend /*method*/ void __fastcall TShaïCameraCustomManager::EventHandlerPurposeEntityErrorEvent(TShaïHardwareProviderManager * Sender, IShaïHardwareEntity* AEntity, int AError, void *Data);
 
private:
  // Membres Privés
  TShaïCameraStates FCameraStates;
  TMultiReadExclusiveWriteSynchronizer *FCameraStatesThreadLock;
  TShaïCameraTestConnectionState FTestConnectionState;
 
  TShaïCameraDirectView* FDirectView;
  TShaïCameraRecording *FRecording;
  bool FForbiddenReload; // Pour éviter que l'on puisse changer de Provider alors des Interfaces se baladent dans la nature
 
  enum TDownloadDirectoryState {ddsNone, ddsSet, ddsNotSupported};
  TDownloadDirectoryState FDownloadDirectoryState;
 
  // Méthodes Privées
  void InternalCreate(); // all constructors must call InternalCreate
  void InternalDestroy(); // all destructors must call InternalDestroy
  void InternalCleanPurposeInterfaces();
 
  TShaïCameraTestConnectionState SetTestConnectionStateFromHardwareCameraState(TShaïHardwareCameraState AState, bool AsyncMode);
 
  // Méthodes Privées (Signalement d'Evènement)
  void NotifyChangeState(TShaïCameraCustomManager * Sender, TShaïHardwareCameraState AState, void *Data);
  void NotifyError(TShaïCameraCustomManager * Sender, TShaïHardwareCameraError AError, void *Data);
 
protected:
  // Méthodes Redéfinies
  /*override*/virtual TShaïHardwareProviderManager* __fastcall GetProviderManagerInstance();
  /*override*/virtual void CleanPurposeInterfaces();
  /*override*/virtual bool AllowLoad();
 
  // Accesseurs (Divers)
  TShaïCameraStates __fastcall GetCameraStates();
  TShaïCameraDirectView* __fastcall GetDirectView();
  TShaïCameraRecording* __fastcall GetRecording();
  TFileName __fastcall GetCameraVideoDirectory();
 
  // Accesseurs (Sensor)
  bool __fastcall GetSensorAvailable() {/* TODO CAM*/};
 
  // Accesseurs (Propriétés Publiques)
  IShaïCameraEntityPurposeDelphiInterface __fastcall GetCameraPurposeInterface();
 
public:
  // Constructeurs Publiques
  /*constructor*/__fastcall TShaïCameraCustom();
  /*constructor*/__fastcall TShaïCameraCustom(TDataSet* ADataSet);
  /*destructor*/__fastcall virtual ~TShaïCameraCustom();
 
  // Méthodes Publiques (Vues)
  TShaïCameraDirectView* CreateDirectView(); // Crée un nouvel objet Vue, l'appelant est responsable de la libération, augmente le compteur de référence sur la Camera
  bool HasDirectView();
 
  // Méthodes Publiques (Enregistrements)
  TShaïCameraRecording* CreateRecording(); // Crée un nouvel objet Enregistrement, l'appelant est responsable de la libération, augmente le compteur de référence sur la Camera
  TShaïCameraRecording* CreateRecordingWithContext(TShaïCameraActionRecordingContext *AActionContext);
  bool HasRecording();
 
  // Méthodes Publiques (Relecture d'Archive)
  TShaïCameraPlaybackView* CreatePlaybackView(); // Crée un nouvel objet Redifusion, l'appelant est responsable de la libération, augmente le compteur de référence sur la Camera
 
  // Méthodes Publiques (Connection)
  TShaïCameraTestConnectionState TestConnection();
  void TestConnectionTimedOut();
 
  // Méthodes Publiques (Sensor)
  bool ActiveSensor(bool Active, bool AsynchronousMode = true)
    {/* TODO CAM - AXIS, devra être async avec vérification par Socket avant de tenter un HTTP, ne pas cumuler les demandes via scsSensorActivating, scsSensorDesactivating, scsSensorActive */
     /* TODO CAM - Dahua, nécessite une connexion permanente pour l'abonnement au système de message de la motion*/
     /* TODO CAM - CamTrace, nécessite une connexion permanente sur le socket de notification*/};
 
  // Propriétés Publiques
  __property Provider; // Augmentation de Visibilité
  __property Model; // Augmentation de Visibilité
  __property Entity; // Augmentation de Visibilité
  __property IShaïCameraEntityPurposeDelphiInterface CameraPurposeInterface = {read=GetCameraPurposeInterface};
 
  // Propriétés Publiques
  __property TShaïCameraStates CameraStates = {read=GetCameraStates};
  __property TFileName CameraVideoDirectory = {read=GetCameraVideoDirectory};
 
  // Propriétés Publiques (Vues)
  __property TShaïCameraDirectView* DirectView = {read=GetDirectView}; // Cherche la vue existante, création si nécessaire !
 
  // Propriétés Publiques (Enregistrements)
  __property TShaïCameraRecording* Recording = {read=GetRecording}; // Cherche l'enregistreur existant, création si nécessaire !
 
  // Méthodes Publiques (Connection)
  __property TShaïCameraTestConnectionState TestConnectionState = {read=FTestConnectionState};
 
  // Propriétés Publiques (Sensor)
  __property bool SensorAvailable = {read=GetSensorAvailable};
};

[SNatoon]

>> j'aimerai voir la tête de cet IDE avec 200 classes

[SNatoon]

[ame="http://www.youtube.com/watch?v=P0XMOr3JrUc"]http://www.youtube.com/watch?v=P0XMOr3JrUc[/ame]
nouvelle vidéo

[SergioMaster]

Bonjour,
c'est une très jolie interface , bien que je pense que ce n'est qu'une couche de plus tel l'évolution des traitements de texte . Ce que j'entends par là est que l'évolution est certes au rendez-vous mais au dépend de la productivité comme les traitements de texte simple au départ ce n'étaient que des machines à écrire , maintenant on y passe plus de temps a mettre en forme qu'a taper le texte idem on passera plus de temps sur cet outil a faire des clics, drag drops etc qu'a concevoir les Objets et écrire le texte produit au Final .

pour finir pourquoi ai-je l'impression d'avoir affaire a une publicité déguisée ? enfreignant les règles

[ShaiLeTroll]

Peu importe si c'est une publicité déguisée, plusieurs points font qu'elle dissuade l'utilisation de StroyCode

1- Beaucoup de Clic !
Comme tout le monde professionnel le sait, alterner entre le clavier et la souris est une opération lente
C'est pour cela que pour une application de saisie en masse, on va privilégier les raccourcis clavier pour réduire l'utilisation de la souris

Au final, un développeur qui a une bonne idée générale des deux classes qu'il va produire, ne devrait pas mettre plus de temps à taper le code que d'utiliser StroyCode !

D'ailleurs, pour la property, gros défaut de devoir créer séparément la variable privé et la property
Un assistant digne de ce nom devrait permettre de créer la property (Nom + Classe) et de générer au clic droit le partie simpliste Get\Set\FMember sans devoir faire ces copier coller

Dommage, il y avait là de quoi optimiser la frappe ! démonstration ratée à ce sujet !
Au moins le refactoring sur le renommage de FUser lui fonctionne ! c'est le minimum !


2 - Modification du sources par un programme autre que StroyCode !
On nous montre la génération, c'est bien mais incomplet !

Pas de démonstration de réintégration de modification dans cette vidéo, dommage, même une modification mineure aurait été sympa à être ré-intégré au diagramme !
Je pense à une modification faite en Delphi mais surtout à l'utilisation d'un outil comme TortoiseSVN utilisé dans une équipe de professionnel pour synchroniser les sources (merge auto, merge conflict ...), il faut que StroyCode puisse le gérer pour être convaincant !


3- Ensuite, le code choisi n'est pas terrible !
Utiliser un gestionnaire d'évènement affecté durant le setter, hum, j'ai fait cette erreur, je ne le ferais plus ! Trop vicieux !

On ne peut plus librement affecté le gestionnaire, ainsi si un controller dans son IHM ou TUserManager avait affecté son propre gestionnaire à cet instance de TUser, il est donc perdu !

C'est un sacré piège ce code !
On est à la limite d'une anti-pattern Action à distance

Un développeur aussi doué que l'auteur de StroyCode (faut reconnaitre que c'est assez "chiadé" visuellement) n'aurait du faire ce genre d'erreur de conception !

Evidemment, on pourrait tomber dans un abus d'architecture et obtenir une anti-pattern Programmation spaghetti avec un gestion des événements complexes avec une liste de listener et un tralala d'interface pour gérer plusieurs gestionnaire simultanément mais cela ne serait pas raisonnable !

Il y a plusieurs possibilités pour gérer cela SANS gestionnaire !

Une property ReadOnly ou une méthode LockRigths\UnlockRigths, pour empêcher une modification de Rigths
une property ReadOnly basique : true\false pose un problème si l'on rétabli ReadOnly à true au changement de TUser, est-ce correct ?
Mémoriser la valeur précédente, bof, pas très fiable

il faudrait un compteur comme BeginUpdate\EndUpdate
Cela a l'avantage de généraliser cela à l'objet TUser et pas juste au TSystem, le mécanisme LockRigths\UnlockRigths est réutilisable !


Autre technique le clonage d'instance, on connait bien cela avec le TPicture\TBitmap

TUser hérite de TPersistent et redéfini Assign !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
constructor TSystem.Create();
begin
  inherited Create();
 
  FAdministrator := TUser.Create();
end;
 
destructor TSystem.Destroy();
begin
  FreeAndNil(FAdministrator);
 
  inherited Destroy();
end;
 
procedure TSystem.SetAdministrator(AValue: TUser);
begin
  FAdministrator.Assign(AValue); // Copie ce qu'il faut ! 
end;

L'inconvénient, c'est que si l'on modifie l'autre TUser, le TSystem ne le saura pas, on en revient à devoir faire une notification des clones, une patten Observateur pourrait être ainsi mis en place

L'avantage, c'est un code bien plus simple !

[e-ric]

Salut à tous

J'ajoute ma contrib'. Encore un gadget de marketing destiné au DSI...
Je me demande si les personnes qui ont développé ce machin s'en serviraient pour le maintenir...

C'est le genre de fausse bonne idée qui démontre la faible connaissance du métier de développeur de la part de cette société. Un éditeur de source qui ressemble à un éditeur UML, quel progrès... On prend parfois (sic!) les développeurs pour des demeurés. Pour de l'UML, la fonction communication avec des non-informaticiens a du sens mais pour l'édition de code source, j'ai encore du mal de voir l'intérêt, je suis sans doute un peu dépassé. Si vous avez déjà vu un "fonctionnel" lire du code, vous m'appelez.

Au final, je trouve que cela n'apporte pas grand chose, rien ne remplacera un bon éditeur de texte et la capacité du développeur à lire un source et le comprendre. D'un point de vue pratique, cette représentation graphique consomme plus de place à l'écran que l'affichage "traditionnel". Enfin, cela complique encore les environnements de développement en les rendant pus fragiles.

@+

[arkhamon]

Bonjour à tous,
je suis assez d'accord avec les précédents avis. En particulier avec ShaiLeTroll quand il pointe du doigt (pas sur la souris ) le fait de savoir ce qui se passera quand on aura modifié le code avec Delphi et qu'on reviendra dans cet outil ? J'ai eu le même soucis à l'époque ou j'ai voulu apprendre Java, et que j'ai utilise un plugin de Eclipse pour faire la création des IHM : j'ai fait l'erreur de vouloir modifier un peu le code généré (sans trop le savoir d'ailleurs), ça m'a pété à la figure.

Donc mon avis de super spécialiste dans tous les domaines (je suis omniscient si si, et de super spécialiste du Delphi (environ 3% de degré de maîtrise des nouveaux concepts) me fait dire que ce genre d'outil de super maquétage destiné aux super projets, ben il est difficilement utilisable dans les super projets...

Plus sérieusement (sur mon niveau de compétence en Delphi, mais pas que), c'est vrai que j'ai pas mal décroché depuis près de 10 ans sur Delphi, et que le retour est parfois douloureux : y a des concepts que je ne comprends pas, d'autres dont je ne vois pas l'utilité, d'autres que je n'arrive pas à mettre en oeuvre. Le problème, c'est que un peu partout (et surtout ici), je lis qu'ils sont super top... Mais je pense que la programmation, ça passe encore par une phase primordiale d'écriture de code au clavier, et que tous les AGL et autres concepteurs super graphiques de code ont un gros défaut : ils ne sont pas intelligents, et donc ne savent pas gérer les cas hyper particuliers. Le problème, c'est qu'en développement, quand on fait du standard... on prend un produit standard. On se refait pas le sien...