IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un IDE entièrement graphique pour Delphi : est-ce réellement utilisable ?
Les pros sont sceptiques

Le , par SNatoon
35 commentaires

5PARTAGES

0  0 
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 :

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


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

Une erreur dans cette actualité ? Signalez-nous-la !

35 commentaires
Commenter Signaler un problème
Paul TOTH
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 01/02/2013 à 6:09
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.
6  0 
SergioMaster
Avatar de SergioMaster
Rédacteur/Modérateur https://www.developpez.com
Le 15/06/2013 à 8:25
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
6  0 
e-ric
Avatar de e-ric
Membre expert https://www.developpez.com
Le 17/06/2013 à 13:03
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.

@+
4  0 
Paul TOTH
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 05/02/2013 à 4:56
Citation Envoyé par SNatoon Voir le message
>> j'aimerai voir la tête de cet IDE avec 200
classes

(photo de 15 classes)
encore 185 et le compte y sera

un truc comme le poster des premiers Delphi (ceux qui étaient vendus en carton)

ou comme QT
3  0 
Charly910
Avatar de Charly910
Membre expert https://www.developpez.com
Le 01/02/2013 à 8:33
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
2  0 
ShaiLeTroll
Avatar de ShaiLeTroll
Expert éminent sénior https://www.developpez.com
Le 01/02/2013 à 16:58
Citation Envoyé par Caribensila Voir le message
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]

Citation Envoyé par Caribensila Voir le message
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 !

Citation Envoyé par Caribensila Voir le message
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 !

Citation Envoyé par Caribensila Voir le message
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 !

Citation Envoyé par SNatoon Voir le message
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 !

Citation Envoyé par Ph. B. Voir le message
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 ?
2  0 
Paul TOTH
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 12/02/2013 à 5:16
SNatoon, quelle est ta relation avec ce produit ? tu en fais manifestement la publicité, as-tu un intérêt personnel pour le faire ? en es-tu l'auteur ?
2  0 
ShaiLeTroll
Avatar de ShaiLeTroll
Expert éminent sénior https://www.developpez.com
Le 01/02/2013 à 11:58
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 !
1  0 
ShaiLeTroll
Avatar de ShaiLeTroll
Expert éminent sénior https://www.developpez.com
Le 17/06/2013 à 11:56
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 
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 !
1  0 
arkhamon
Avatar de arkhamon
Membre éprouvé https://www.developpez.com
Le 18/06/2013 à 11:55
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...
1  0 
Commenter Signaler un problème