Discussion :

[artiom]

Bonjour a vous tous.

Voila, je connais bien plusieurs languages de programmation tels que C, C++, JAVA, PHP etc etc

Mon soucis au jour d'aujourd'hui est de trouver un tutoriel qui me permette d'apprendre des methodes standarts de developpement de logiciels/jeux etc etc...

JE m'explique. Par exemple dans un jeu il y a des ecrans de depart. avec des menus. etc etc comment es ce qu'on gere ca niveau programmation. Es ce que c tout simplement en fesant des fonctions a la suite. ou alors une pile ou alors...

Donc voila disons que je ne sais pas prendre en main un gros projet de developpement proprement. J'ai tendence a faire de la programmation du genre, "j'ai besoin de ca? bah je le glisse a l'arrache entre la et la.."

Je pense que vous voyez mon probleme. pourriez vous m'eclairer a ce niveau la. ca me rendrait bien service si quelqu'un pouvais m'envoyer sur un tuto un peu generaliste sur l'archi logicielle.

Merci beaucoup. et desolé si le post a deja été crée. J'ai peut etre pas pris suffisement le temps de chercher sur ce forum car en lisant en diagonale je n'ai vu que des choses specialisés sur une methode precise, genre uml ep etc etc

[cinemania]

J'ai une question qui me brule les levres...

Quel est le besoin ? tu travail pour une société qui a besoin de ca ? ou c'est juste à titre personnel ?

Alors ça c'est le job d'un architecte logiciel... malheureusement, beaucoup semble croire qu'on peut devenir architecte logiciel juste en regardant des tutoriels... c'est "utopique"... certes c'est déjà bien mais ce n'est pas tout.

En effet, avant meme d'etre architecte logiciel, il y a des bases théoriques plus ou moins mathématiques qu'il est nécessaire d'apprendre, qu'on ne trouve générallement pas dans les tutoriels, ou jamais dans un seul tuto, mais divers tuto pas structurés entre eux, et surtout personne ne pourra te dire lesquels regarder et dans quel ordre...
car contrairement à une autre croyance populaire, savoir faire de l'UML ne suffit pas... sinon tout le monde sortant de BTS pourrait faire Architecte logiciel, alors que ce n'est pas du tout le cas.
Ensuite il y a pas mal d'autres trucs à apprendre. Comme savoir reconnaitre et décomposer les différentes parties du probleme, de facon à savoir comment architecturer chacune d'entre elles, par exemple par du pattern matching.

Ensuite il faut quelque chose qui s'acquiert... un bon esprit analytique et être capable de faire abstraction... et c'est là que là que ca se gâtte.
Car on ne doit pas regarder les choses du meme point de vue que le développeur tout en bas. On doit avoir une vision d'ensemble du projet, des tenants, aboutissants, besoins, requis, facultatifs sans trop se soucier du code (enfin faut savoir si ca sera ou non codable, et si trop complexe décomposer le probleme en sous solutions qui elles serons codable aisément ou sans trop de difficultés)

Commence déjà par apprendre dans un tutoriel l'UML.
Ca te donnera dejà une vue d'ensemble de comment marche un programme en règle général et surtout comment "modéliser" les différentes étapes.
Ensuite si tu ne doit pas devenir architecte logiciel pour ton entreprise... reste en là ca te suffira pour la plupart des projets personnels que tu débutera... si par contre tu souhaite devenir architecte logiciel... je ne saurais trop te conseiller de reprendre le chemin des formations et des cours en université ou grande école, ou institut de formations comme le CNAM et autres...

[Marc Lussac]

Ta question ressemble à de la génération d'IHM, et les solutions ne sont pas les mêmes pour tous ces langages, regarde les forums IHM des langages en question.

Il y à aussi de nombreux articles sur les IHM pour tous ces langages sur developpez.com

[artiom]

Merci pour ces reponses.

Bon juste a titre d'information je reponds a quelques questions que vous m'avez posé.

Ce besoin reside dans le fait que je commence a maitriser pas mal de languages, mais de la defficience en structure logiciele decoule un genre de programmation qui malgré le fait qu'elle marche, est tres dur a structurer, a debugguer et surtout a ameliorer ou etoffer.

En gros quand j'ecris du code pour un programme, je reinvente la roue et tout est tellement ancré dans le programme que aucune partie ou presque n'est reutilisable correctement dans un application approximativement similaire...

En ce qui concerne les etudes, j'ai une licence de mathematiques/informatique. Avec pas mal de matieres en plus que j'ai validé de maniere a ce que malgré les maths, ca reste une formation informatique universitaire complete.

J'ai arreté les etudes pour la raison que je ne progressait plus. En autodidacte j'allais bien plus vite, et de ce fait je m'ennuyais en cours. Resultat des courses : BAC +3 sorti parmis les 5 premiers de Jussieux dans pas mal de matieres informatiques et incapable de prendre en charge le developpement d'une application a 100%.

Bon evidement la je vous parle du fait que j'ai envie de tendre vers une excelence en ce qui conserne l'archi logicielle.

A l'heure actuelle j'ai pris en main un projet qui se nomme ShoringWarfare. Sur ce forum j'ai recruté du monde. Je me dis que si je n'ai pas reussi a avoir cette formation en université, j'y arriverai par moi meme en etudiant ennormement et en appliquant mes connaissances dans ce projet en cours de developpement.
D'ou ma demande sur ce forum de ressources vis a vis de ce vaste sujet qu'est l'architecture logicielle.

En ce qui conserne l'UML je me suis pas mal penché sur la question, mais ce me semble beaucoup trop theorique. C'est a dire que je ne crois pas avoir de lacunes en analyse des besoins et schematisation.
C'est a l'etape suivante que ca pose probleme. Comment rediger proprement un module dont on a deja l'analyse. J'ai presque envie de dire que je me demande si ca ne releve pas d'un ensemble de conventions deja existantes...
C'est donc ces "convention de redaction" que je recherche.

[cinemania]

si tu prend des logiciels uml poussés, la plupart peuvent te générer pas mal de code de tonappli, parfois carrément tout le code de la classe sans qu'il y ai besoin d'y retoucher... pour peu que TOUS les diagrammes utiles aient été pleinement complétés et validés pour que le logiciel puisse en tirer partie.

en réalité il n'y a pas de méthode toute faite,c'est effectivement une suite de conventions.

Quand tu écrit ton code, ou tout module, il faut le faire de façon à séparer tout cequi est séparable...
exemple :
si je prend mon projet, j'ai une 20aines d'objets métiers, qui ne cessent de s'agrémenter, d'augmenter ...
et j'ai tout un tronc commun qui gere la partie communicationnelle réseau, les accès à la base de données. Aucun de mes objets métiers ne gere la base... ce n'est pas leur role. Ces objets métiers sont réutilisables dans d'autres projets pour peu qu'ils aient le meme framework, certes, mais les objets du frameworks sont réutilisables ailleurs car pour tous très indépendants.

Mes abstractions de base de données sont faites pour etre totalement indépendantes du support avec chargement dyanique du bon modele (configuration indique quel base on souhaite connecté) Elles sont TOTALEMENT AUTONOMES et ne nécessite que une ou deux classe du reste du package, qui sont des structures de données améliorées.

il faut bien te dire que certaines choses sont facilement codable pour etre autonome et "générique" et d'autres pas du tout car elles utilisent justement ces objets que tuas mis au point.

une bonne méthode malheureusement pas toujours possible et encore moins réaliste dans un projet,voudrait que les objets métiers par exemple n'ai pas de code dépendant, et que ce soit des "connecteurs" fournis avec qui eux sont fait pour créer ces notions de dépendances.
Cette architecture est toutefois pas mal, mais multiplie parfois de facon exponentielle le nombre de classes du projet.

Là si je prend mon projet, le noyau est totalement utilisable pour autre chose... les modules eux non. Deja ils nécessite le noyau qu'est un vrai framework, et ensuite, ils sont tous spécifiques à une utilité particulière, et sont tous développés autour d'un ou plusieurs objets métiers.

[artiom]

Bon alors je crois que je commence a comprendre le fait qu'il n'y a rien a comprendre...

En gros vous etes d'accord avec moi donc que etre un bon Designer de logiciel c'est avant tout:
1. Une parfaite maitrise du language utilisé
2. Une rigueur dans le suivi des conventions de redaction du language
3. Une tres longue experiance
4. Faire de la programmation modulaire des que cela n'es qu'un tout petit peu possible.

Si j'ai bien compris, on peut aisement dire que Logiciel Design pour les nuls, est un livre que je ne trouverai pas. Et tout tutoriel ou aide qui pretenderai nous appredre cela, serai totalement ridicule en vue des enjeux qu'impose ce domaine.

[madfu]

Si j'ai bien compris, on peut aisement dire que Logiciel Design pour les nuls, est un livre que je ne trouverai pas. Et tout tutoriel ou aide qui pretenderai nous appredre cela, serai totalement ridicule en vue des enjeux qu'impose ce domaine.

Tout dépend de tes ambitions: entre jouer à l'architecte et apprendre à concevoir une application en utilisant des principes de conception il y a une différence et il existe de très bons livres qui traitent de conception de manière pragmatique et qui te permettront de mettre le pied à l'étrier et t'éclaireront sur les grands principes de conception à retenir mais oui ça ne prend pas 5 min et tu vas faire bcp d'erreur au début c'est sûr.

Après tout dépend de ton niveau de départ, par exemple un simple tutoriel comme celui là sur le développement en couche donne de bonnes habitudes à appliquer dans ses développement par exemple.

[cinemania]

j'ai parlé de tutoriel, en revanche des livres il y en a quelques uns... j'en ai un comme livre de chevet... non je plaisante, mais j'en ai lu pendant mes études
ensuite le truc c'est que comme déjà dit tout dépend de tes ambitions et des besoins.

pour ce qui est du langage... en temps qu"architecte il n'est pas indispensable de bien connaitre le langage dans lequel le logiciel sera développé sauf si tu fait parti des développeurs... mais en temps qu'"architecte logiciel, ce n'est pas obligatoire... En effet, une architecture décrite de facon claire en UML, et éventuellement décrivant certains écueils algorithmique dans un langage algorithmique clair ou adapté... est largement suffisant.

J'ai meme deja vu une doc/cahier des charges, contenant tous les algos de bases de la partie réseau, protocoles et autres décrits en CAML (remarque le CAML est parfois utilisé pour justifier les algorithmes et les différents protocoles réseaux, dans pas mal de traités scientifiques)

Donc il n'est primordial de maitriserle langage à la perfection... autrement dit il n'est pas nécessaire d'etre en mesure d'écrire un livre, traité, sur les spécifications de C++ les yeux fermés, pour que le projet soit développé en C++. Il est juste nécessaire d'en comprendre les fondements de bases, et les constructions syntaxiques les plus courantes.

[artiom]

d'accord...

Vous n'auriez pas quelques references a me recommander? ca pourrai etre cool...
Je parle des references bibliographiques =)

[madfu]

Je te recommande chaudement les livres suivants qui mettent l'accent sur la pédagogie et le pragmatisme.

- "UML 2 - Modéliser une application Web" de la collection "cahiers du programmeur" : Le livre est en fait une étude de cas de la conception d'une application en UML. A noter que ça se transpose très facilement vers n'importe quelle application.

- "Conception orienté objet" et "Design patterns" de la collection "Tête la première":plus denses mais très didactique.

[artiom]

Parfait merci beaucoup j'ai bien pris note des titres de ces ouvrages. J'essayerai de me les procurer tres prochainement.