Vers l urbanisation agile d un client mobile ios/android natif, économique, flexible et pérenne

Transcription

1 Vers l urbanisation agile d un client mobile ios/android natif, économique, flexible et pérenne Développement des Systèmes Dynamiques, Programmation Sémantique Opérationnelle, Programmation Fonctionnelle Pilotée par les Données, Programmation Fonctionnelle et Développement Natif, Cross-Development Mobile, LiveCode, Interopérabilité du Client Mobile avec les API Serveur We can only see a short distance ahead, but we can see plenty there that needs to be done. The key to performance is elegance, not battalions of special cases. Alan Turing Jon Bentley and Doug McIlroy 1 / 9 17/02/2015 Sahores Conseil

2 Les 9 principes de base de la DSDM* : 1. Implication des utilisateurs durant tout le cycle de développement. Ils sont considérés comme des membres à part entière de l'équipe projet ; 2. Autonomie. L'équipe projet doit avoir un pouvoir de prise de décision concernant l'évolution des besoins ; 3. Visibilité du résultat. L'application doit être livrée le plus souvent possible afin de permettre un feed-back rapide. Les délais entre les livraisons doivent être le plus court possible ; 4. Adéquation. L'objectif est de livrer une application en adéquation avec le besoin métier du client ; 6. Réversibilité. Toute modification effectuée durant le développement doit être réversible ; 7. Synthèse. Un schéma directeur, défini de manière préalable, fixe les grandes lignes du projet, notamment son périmètre et son échéancier de recette ; 8. Tests. Les tests unitaires sont continus durant tout le développement. Ils permettent de revalider l intégrité fonctionnelle de l'application à chaque étape du développement ; 9. Coopération. Les acteurs du projet doivent faire preuve de souplesse concernant les modifications des fonctionnalités demandées. 5. Développement itératif et incrémental. L'évolution du développement est basée sur le feed-back des utilisateurs ; *Dynamic Systems Development Methodology 2 / 9 17/02/2015 Sahores Conseil

3 Les 9 principes de base de la PSO* : 1. La *Programmation Sémantique Opérationnelle a pour objet de démembrer le système d information en l ensemble de ses éléments premiers à l effet de pouvoir les représenter en un unique diagramme en 2 dimensions ; 2. La PSO est un nouveau language de description de la complexité du système d information exposant la transformation des datas tout au long de leur traitement ; 3. Le diagramme de PSO se présente sous la forme d un algorithme de flots (source, arêtes, sommets, puits) ; 4. Le diagramme de PSO expose des messages (data) et des traitements (commandes, fonctions, librairies) ; 5. Le diagramme de PSO expose 3 types de messages : les datas entrants (source), les états intermédiaires des datas en cours de traitement (arêtes), les datas sortants (puits); 6. Le diagramme de PSO expose 3 type de traitements : des commandes, des fonctions et des librairies ; 7. La PSO identifie les commandes comme les contrôleurs chargés de dispatcher les messages vers les fonctions, à raison de leur contenu ; 8. La PSO identifie les fonctions comme les traitements chargés d appliquer une transformation aux messages reçus ; 9. La PSO identifie les librairies comme des traitements complexes déjà validés et dont elle n expose que les messages entrants et sortants. 3 / 9 17/02/2015 Sahores Conseil

4 La modélisation PSO/PF : une alternative flexible et sûre à UML3/POO -> Système d Information Piloté par les Données -> Système Expert de Fouille de Données en mode 24/7 4 / 9 17/02/2015 Sahores Conseil

5 Les 9 principes de base de la DDFP* : 1. La *Programmation Fonctionnelle Pilotée par les Données est un modèle de développement optimisé où chaque composant, client ou serveur, du système d information opère les datas qui le traversent sous la stricte autorité d un contrôleur d intégrité référentielle ; 2. La DDFP délègue le contrôle d intégrité des datas à un moteur d inférence exploitant une base fermée de règles impératives ; 3. En DDFP, seuls les datas dont la structure est reconnue par le contrôleur d intégrité référentielle sont dispatchés pour traitement ; 4. En DDFP, les data de structure non reconnue portent le contrôleur d intégrité référentielle à retourner un simple code de rejet à l émetteur ; 6. La DDFP opère 3 type de traitements : des commandes, des fonctions et des librairies ; 7. La DDFP identifie les commandes comme les contrôleurs chargés de dispatcher les messages vers les fonctions, à raison de leur contenu ; 8. La DDFP identifie les fonctions comme les traitements chargés d appliquer une transformation aux messages reçus ; 9. La DDFP identifie les librairies comme des traitements complexes déjà validés et dont elle n expose que les messages entrants et sortants. 5. La DDFP prend en charge 3 types de messages : les datas entrants, les états intermédiaires des datas en cours de traitement, les datas sortants; *Data Driven Functional Programming (Programmation Fonctionnelle Pilotée par les Données) 5 / 9 17/02/2015 Sahores Conseil

6 Programmation Fonctionnnelle et Développement Natif 1. Android Studio/SDK/NDK/JNI -> Prog. Fonctionnelle/UXIE/Dév. Natif/OpenSource : NON/ OUI/Android/OUI; Retour d expérience : Favorable; Apps publiées : > 10 K; 2. Delphi XE7 -> Prog. Fonctionnelle/UXIE/Dév. Natif/ OpenSource : NON/OUI/OUI/NON, Retour d expérience : NC -> Apps publiées : NC; 3. Frameworks HTML5/CSS3/JS -> Prog. Fonctionnelle/ UXIE/Dév. Natif/OpenSource : NON/NON/NON/OUI; Retour d expérience : Négatif; Apps publiées > 10 K; 4. LiveCode Mobile -> Prog. Fonctionnelle/UXIE/Dev. Natif/OpenSource : OUI/OUI/OUI/GPL&COM; Retour d expérience : Favorable; Apps publiées : > 500; 5. Objective-C -> Prog. Fonctionnelle/UXIE/Dév. Natif/ OpenSource : NON/NON/iOS/NON; Retour d expérience : Favorable -> Apps publiées > 10 K; 6. Oracle MAF : Prog. Fonctionnelle/UXIE/Dév. Natif/ OpenSource : NON/SWING/OUI/NON; Retour d expérience : NC -> Apps publiées : NC; 7. Scala/Migeran/Scaloid : Prog. Fonctionnelle/UXIE/ Dév. Natif/OpenSource : OUI/OUI/OUI/OUI; Retour d expérience : Favorable -> Apps publiées : NC; 8. SWIFT : Prog. Fonctionnelle/UXIE/Dév. Natif/ OpenSource : OUI/NON/iOS/NC; Retour d expérience : Favorable -> Apps publiées : > 1 K; 9. Windev Mobile -> Prog. Fonctionnelle/UXIE/Dév. Natif/OpenSource : NON/OUI/OUI/NON; Retour d expérience : Favorable -> Apps publiées : NC; 10. Xamarin (C#,.NET, Mono) -> Prog. Fonctionnelle/ UXIE/Dév. Natif/OpenSource :?/OUI/OUI/NON; Retour d expérience : Rdio : lignes de code -> Apps publiées : NC; 6 / 9 17/02/2015 Sahores Conseil

7 Les 10 principes de base du Cross-Development Mobile 1. Le Cross-Development Mobile doit, idéalement, adresser un language de programmation fonctionnelle (fonctions de rang supérieur, récursivité des parcours de liste,...); 2. Le Cross-Development Mobile doit adresser les API et librairies natives dédiées au contrôle applicatif et matériel des plateformes mobiles prises en charge; 3. Le Cross-Development Mobile doit mettre en oeuvre un éditeur d IHM complet (UXIE wisiwig, drag n drop, clavier, souris, génération automatique du code source des Vues) capable de s interfacer avec tous types d éditeurs externes (image, son, video, icones, texte,...); 4. Le Cross-Development Mobile doit mettre en oeuvre un éditeur de programmation interactif (debugger, documentation, variable scope,...); 5. Le Cross-Development Mobile doit adresser un système de ramasse-miettes (garbage collector) efficace; 6. Le Cross-Development Mobile doit, à l occasion, savoir déléguer certains traitements à des fonctions externes propres à chaque plateforme adressée ; 7. Le Cross-Development Mobile Natif ne doit pas s interdire le recours ponctuel à des ressources hybrides exploitées en accès local sandboxé (HTML5/CSS3/JS Natif); 8. Le Cross-Development Mobile doit être pensé en termes de modularité, favorable au versioning, à la réutilisation et à l optimisation continue du code généré de projet en projet; 9. Le Cross-Development Mobile doit être pensé en termes de flexibilité, au regard des API réseau qui pourront lui être présentées, idéalement sans adaptations spécifiques; 10. Le Cross-Development Mobile doit permettre un fonctionnement des applications adressées en mode semi-connecté (mode avion, persistance locale des données en mode ACID); 7 / 9 17/02/2015 Sahores Conseil

8 Les 8 caractéristiques principales de LiveCode 1. LiveCode est un RAD de développement intégré (IDE/UXE, ByteCode Compiler JIT singlethread) mature et fiable, disponible depuis 1991; 2. LiveCode est surtout un puissant langage fonctionnel sans changement d état qui permet de gérer les tests unitaires de validation de l intégrité applicative en mode continu, tout au long du développement (cf : DSDM 3, 5, 6, 8); 3. L enregistrement et l appel de procédures distantes (file, http, include, start using) étant nativement supporté, LiveCode rend la gestion de dépôts et le team-coding techniquement transparent. 4. Une syntaxe verbe, valeur, container rend la courbe d apprentissage du language très plate, dès lors que les concepts de base de la programmation fonctionnelle sont acquis; 5. La puissance de LiveCode découle du nombre réduit de lignes nécessaires au codage de fonctions complexes. Cette caractéristique constitue un des points forts du language en termes de maintenance évolutive (debuggage, optimisation, scalabilité), le besoin de commenter le code s en trouvant allégé d autant. 6. Le ByteCode Compiler LiveCode est écrit en C/C ++. Très économique en termes d empreinte mémoire (3.5 < LC < 6 Mo / thread), il se compare à PHP en termes de vitesse de calcul. 7. LiveCode adresse ios, Android (Mobile), Windows, MacOS X, Linux (Desktop), Windows, MacOS X, Linux (CGI Server), Solaris, SunOS, SGI IRIS, HP/UX, IBM RS, BSD, NetBSD, MacOS (Non Officiellement Supportés); 8. LiveCode est distribué en dual-licence (GPL3, Commercial) et regroupe une communauté d experts très resserrée autour de RunRev Ltd, l éditeur du produit depuis 2003; 8 / 9 17/02/2015 Sahores Conseil

9 Interopérabilité du Client Mobile avec les API Serveur 1. Favoriser la réutilisation des API serveur existantes chaque fois que c est possible : dès lors qu une API de présentation des datas adresse déjà d autres types de clients (Web, WebServices, Windows Natif, MacOS X Natif), il sera généralement optimal de reporter, côté Mobile, la couche d abstraction permettant de la réutiliser sans modification ; à défaut, le codage d un Web Service HTTP(S) REST ou JSON(B) dédié sera souvent le moyen le plus simple de traiter le besoin ; 2. Le Client Mobile constitue, dès lors qu il s affranchit des frameworks Javascript issus du Responsive Web, un terminal ntiers efficace (serveurs ACID-SQL, NewSQL ou NoSQL, serveurs de Streaming AV, SendMail, PostFix, serveurs Push, Opérateurs de Paiement, Authentification Forte,...) ; 3. Persistence Locale des Données : le Client Mobile Natif autorise une persistance locale sandboxée des datas (flat-files, SQLite) lui permettant de supporter avec flexibilité le Mode Avion ; 9 / 9 17/02/2015 Sahores Conseil

10 Merci! Programmation fonctionnelle et urbanisation du SI Mobile : Use Case SI SaaS de Commerce Web et Mobile WS Stores Sahores Conseil 17/02/2015 Sahores Conseil