DotNetGuru Weblogs

Matthieu Mezil, artiste de l’objet, est parti pour son article L’objet, c’est beau du besoin suivant:

• Prendre un fichier en entrée, effectuer un traitement sur celui-ci puis sauvegarder les modifications dans un fichier de sortie.
• Par défaut, il propose deux types de traitements : l’inversion des caractères ligne par ligne et la numérotation des lignes.
• De plus, il veut que les traitements soient composables à l’infini et qu’ils puissent être utilisés indépendant de la notion de fichiers.

L’article traite plusieurs problématiques comme le threading, la gestion d’erreurs … Je vais m’intéresser juste à la première partie : l’acte de création du « chef-d’œuvre ».

L’artiste propose d’organiser sa solution en 2 couches UI et Business, déjà ce choix artistique me pose problème … pourquoi deux couches ? Pourquoi pas une seule ? Pourquoi pas 5 ?
Enfaite on connaît tous la réponse, mais on a tendance à concevoir nos applications en n-couche par habitude / respect des bonnes pratiques. Ce reflexe acquis (chez d’autres développeurs c’est même un reflexe inné) peut parfois nuire à la santé de la solution.

Dans notre cas, la problématique posée est assez simple par rapport à la complexité des projets réels, le choix de plusieurs couches dans cet exemple n’est dû aux contrainte de maintanabilité / scalabilité / extensibilité … Mais probablement pour consolider la structure de la solution : J’aurai préféré si Matthieu partait d’une seule couche, un seul centre fort qui encapsule plusieurs sous-centres (centres latents + centres faibles) : UI / interface avec l’infra (manipulation des fichiers) / Traitement des données ) et qu’en avançant dans son analyse il faisait évoluer sa solution en passant les centres latents en centre forts et en éliminant les centres faibles … Par exemple l’application au début se limite à une application client lourd et petite à petit un nouveau centre celui du traitement apparaît et on l’externalise dans une couche à part.

De nos deux couche business / UI Matthieu a fait un zoom X 1000, et on se retrouve en train de discuter d’une interface IStringsTransform ! Moi, j’ai eu le vertige… On est passé d’un level of scale de l’ordre de l’assembly à celui d’une interface ! comme si un architecte te présente la structure des étages de ta futur maison et juste après il enchaine avec l’emplacement du divan dans ton salon.
Autre soucis avec le Zooming, l’artiste fait référence aux designs patterns. Les design patterns c’est bien mais se focalisent sur une partie du système: Avec un zoom réglé au niveau objet, on risque donc de perdre de vue la solution globale.

Ce que j’aurai aimé trouver dans l’article, c’est une explication plus détaillé de l’approche, une analogie avec le monde réel peut être.
Dans notre cas, on a un fichier et des transformations qu’on peut composer séquentiellement. Ca ressemble à mettre une capsule Nespresso dans la machine, demander une transformation (café court / moyen / et long) en appuyant sur la commande adéquate . On a donc des commandes qui référencent les transformations et un invoker a qui l’utilisateur associe à la demande une commande, la commande à son tour va s’appuyer sur la transformation pour satisfaire la requête du client:

Pour l'utilisation:

            ILineTransformation lineNumberTransformation = new LineNumberTransformation();
            TransformCommand lineNumberTransformCommand = new TransformCommand(lineNumberTransformation);
            ILineTransformation reverseCharLineTransformation = new ReverseCharLineTransformation();
            TransformCommand reverseTransformCommand = new TransformCommand(reverseCharLineTransformation);
            TransformationRemote remote = new TransformationRemote();
            remote.CurrentCommand = reverseTransformCommand;
            var resultWithReverse = remote.Zapping(input);
            remote.CurrentCommand = lineNumberTransformCommand;
            var resultWithLineNumber = remote.Zapping(input);

Pourquoi et comment diffuser un développement logiciel de laboratoire ou d'université en libre ?

A noter la présentation liée à TOPCASED: Logiciel avec une coopération privé-public:

Pourquoi avoir diffusé en libre ?
Comment ?
Quels problèmes ?
Quels retours positifs ?

Notez cette date sur votre agenda ...

J'ai la chance d'assister demain à la 6ème Journée Thématique AFIS : "Stratégies d'Entreprises en Ingénierie Système ".

Le programme est très alléchant, avec des orateurs de nombreuses grandes entreprises françaises : DGA, EADS, CNES, Thalès, EdF, Renault, Dassault, Alsthom ...

Pour ceux que cela intéresse...... j'annonce le lancement officiel d'un produit de gestion de parc informatique, développé en .NET 3.5 avec le trio magique : WPF / WCF / LINQ
Le développement est en cours.... le blog aussi ! On y parlera architecture, solutions retenues, retours en arrière, .... l'occasion de parler sur un exemple concret.
D'ailleurs nous avons récemment retourné notre veste Silverlight au profit d"un smart client WPF. Raison principale : le Printing, non supporté en SL.

Pour en savoir plus : http://www.itamplus.com

Et si vous trouvez aussi un intérêt dans ce produit.... n'hésitez pas à le faire savoir

Comme annoncé dans un précédent post, les planches présentées lors de la conférence Neptune sont maintenant disponibles ici.

Je vous recommande en particulier (choix subjectif ...) :
- MDE, DSL et UML : Où en est on ? P. Desfray (SOFTEAM )
- Modélisation UML/MARTE pour les SoPC A. Koudri (Thales/ENSIETA), J. Champeau (ENSIETA), D. Aulagnier (Thales), D. Vojtisek (INRIA/Triskell)
- MDE, DSL : Modernisation du patrimoine logiciel par les modèles A. Henry (Netfective Technology)
- La création de points de vue avec Obeo Designer, ou comment fabriquer des DSM Eclipse sans être un développeur expert ? É. Juliot (OBEO)
- Le support de MDE et des DSL dans les outils de modélisation de IBM P. Leblanc (IBM France)
- La plate-forme OpenEmbeDD et ses outils d’ingénierie de modèles D. Vojtisek (IRISA)
- Le modèle de temps MARTE et CCSL C. André, F. Mallet (Projet AOSTE, I3S/INRIA)

enfin, on sort des ténèbres... après presque 10 ans de règne sans partager sur l'accès aux données depuis la création du Framework .Net, les DataSets rendent les armes.

C'est une vision personnelle, mais je ne peux me rappeler que mes soirées de debuggage intenses avec les DataSet... absence de typage, requêtes SQL construites sur des concaténations de chaînes de caractère... en tout cas au début, on était obligé de commencer comme ca.

Même s'ils ont mûri, les DataSets sont synonymes de lignes et lignes de codes de plomberie techniques, lourdes, fastidieuses, inutiles... et à mon sens une vision tordue de l'accès aux données.
Tout cela m'avait vite poussé à regarder NHibernate et ses confrères. Vive le Mapping Objet Relationnel!

Pour moi Linq et surtout Ado.Net Entity Framework allait enterrer définitivement les odieux DataSets... il n'en a rien été.

Et cette nouvelle m'apparaît comme une sortie du tunnel: "here are no plans to add DataSet into future releases of Silverlight"
Un signe? Un espoir?
Une promesse d'une aube nouvelle????

Si une technologie qui a le vent en poupe ne soutient plus cet ancêtre, peut être est-ce l'annonce du début de la fin?
Allez, il faut croire au progrès.

http://blogs.msdn.com/adonet/archive/2009/05/26/dataset-and-silverlight.aspx
http://www.sheysrebellion.net/blog/2008/07/31/datasets-are-evil/
http://jelle.druyts.net/PermaLink.aspx?guid=61676665-06a7-443a-9462-71dae713539e (DataSets Are Not Evil)

Le WS UML&AADL'2009 à ICECCS 2009 ,Potsdam s'est déroulé avec succès, 15 présentations !! avec en fin de journée un débat très animé (jusqu'a 19h30 !!) brillamment mené par Frédéric Mallet (Inria), Peter Feiler (Carnegie Mellon) et Oleg Sokolsky (Université de Pennsylvanie). Le prochain workshop, UML&AADL'2010 / ICECCS'2010 aura probablement lieu à York, en avril.

Les transparents, seront bientôt disponibles sur le site.

The UML/AADL Team

Mon livre sur SysML, le premier en français sur le sujet, est enfin paru chez Eyrolles en e-book, dans la collection iZibook.

Mais il est aussi disponible en version papier sur le site i-Kiosque.

Suivez le lien et tapez UML

Actuellement je travaille sur un site Web capable de s’adapter à plusieurs marques et pour différents pays.
L’idée générale est de construire un moule auquel tout le monde devra s’adapter.

Ce n’est pas toujours possible, en particulier la difficile question de certaines règles métiers qui peuvent différer fortement.
Par exemple les prix, promotion et autres cadeaux clients répondent à des logiques différentes selon la marque.

On a donc besoin par moment de sortir localement du moule et exécuter un code ou un autre selon le contexte. Comment s’y prendre concrètement ?

Si on ne parlait que de quelques lignes on pourrait envisager de placer une ou deux clauses if et tester par exemple le nom de la marque. Evidemment si une nouvelle marque vient s’ajouter, on devra prendre le risque de modifier un code qui marche.

Ce blog est publié sur un site qui fait depuis toujours la promotion de l’architecture de code alors on va essayer de faire mieux avec un patron de conception que j’aime bien : le provider.

L’idée générale n’est pas très révolutionnaire. On a (au moins) trois étapes à implémenter :

1. On écrit une interface qui définit la liste des méthodes et propriétés communes. Lorsque je parle d’interface, il s’agit aussi de classe abstraite. A vous de voir ce qui est utile dans votre cas
2. On implémente cette interface autant de fois que nécessaire (une implémentation par marque a priori)
3. On isole la logique d’instanciation de la classe réelle selon le contexte dans une classe factory qui retourne une instance de notre interface.
4. Puisque l’on est ambitieux, on voudrait que la factory soit paramétrable de façon à ne pas avoir besoin de la modifier si une nouvelle marque vient s’ajouter

Le provider est omniprésent dans .Net, il n’est donc pas étonnant que Microsoft nous fournissent une plomberie pour l’implémenter facilement. Découvrons la ensemble.

On commence par l’interface qui doit avoir une dépendance technique avec la classe ProviderBase [1].

public abstract class PricesProvider : ProviderBase

La suite du code définit les méthodes, propriétés… dont nous aurons besoin. Par exemple :

/// <summary>
/// Obtient le meilleur prix d'un article donné compte tenu des réductions auxquelles le client est eligible
/// </summary>
/// <param name="userContext">Instance de <see cref="IPrincipal"/> détenant le profil du client</param>
/// <param name="idProduit">Id du produit</param>
/// <returns>Meilleurs prix proposé</returns>
public abstract double GetBestPrice(IPrincipal userContext, string idProduit);

Je vous conseille vivement d’adopter une cohérence dans la signature des méthodes. Par exemple dans notre cas elles dépendent toutes du profil client que nous chargeons dans l’IPrincipal en cours (on a écrit un principal personnalisé). Celui-ci est par convention le premier paramètre de la ligne et porte systématiquement le même nom et les autres paramètres sont toujours positionnés dans le même ordre.

Croyez moi, c’est très pratique à l’usage et peut à l’occasion éviter quelques bogues de copier/coller.

Il ne vous reste plus qu’à implémenter votre logique métier pour chaque marque :

public sealed class ContosoPricesProvider : PricesProvider
{
Random rnd = new Random(DateTime.Now.Millisecond);

	
public double GetBestPrice(IPrincipal userContext, string idProduit)
{
    return 500 * rnd.NextDouble();
}
}

Note : ce code n’est pas contractuel !

Implémentons la factory. Le corps de la classe est le suivant :

public static class PricesFactory
{
// le code ici
}

Avant de procéder à son implémentation des étapes intermédiaires nous attendent.
Tout d’abord une collection de fournisseurs nous rendra quelques services :

public sealed class PricesProviderCollection : ProviderCollection
{
    new public PricesProvider this[string name]
    {
        [DebuggerStepThrough]
        get
        {
            return (PricesProvider)base[name];
        }
    }

	
    public override void Add(ProviderBase provider)
    {
        if (provider == null)
        {
            throw new ArgumentNullException(Ressources.PricesProviderCollection_ProviderNull);
        }
	
        if (!(provider is PricesProvider))
        {
            throw new ArgumentException("Le type du provider doit être PricesProvider");
        }
	
        base.Add(provider);
    }
}

Il s’agit simplement de typer fortement ProviderCollection qui ne semble pas exister en version générique. Rien d’obligatoire, mais conseillé tout de même.

Nous souhaiterions déclarer dans le fichier web.config le provider qui sera utilisé. Pour cela on doit écrire une classe de configuration. Rien de plus simple :

public sealed class PricesProviderConfiguration : ConfigurationSection
{
    [ConfigurationProperty("providers")]
    public ProviderSettingsCollection Providers
    {
        get
        {
            return (ProviderSettingsCollection)base["providers"];
        }
    }

	
    [ConfigurationProperty("default")]
    public string DefaultProviderName
    {
        [DebuggerStepThrough]
        get
        {
            return base["default"] as string;
        }
	
        [DebuggerStepThrough]
        set
        {
            base["default"] = value;
        }
    }
}

On peut ajouter diverses fioritures selon ce que vous souhaitez faire, mais vous voyez l’idée générale qui est de pouvoir ajouter dans le fichier de configuration quelque chose comme ceci :

<PricesConfigSection default="ContosoPricesProvider">
  <providers>
    <add name="ContosoPricesProvider" type=" PriceModule.ContosoPricesProvider, Business" />
  </providers>
</PricesConfigSection>

Dans la section <providers> vous ajoutez autant de déclaration de classe réelle que nécessaire, et l’attribut default permet de sélectionner celle que le provider devra charger.

Une petite formalité toutefois, il faut aussi ajouter une déclaration similaire à celle-ci :

<section name="PricesConfigSection" type=" PriceModule.PricesProviderConfiguration, Business" />

Pour que l’analyseur du fichier web.config sache comment traiter la section ajoutée.
Revenons donc à notre factory.
Le constructeur (forcément static) est très simple :

static PricesFactory()
{
    Initialize();
}

La méthode Initialize va simplement charger la collection de fournisseur trouvée dans le fichier de configuration. On implémente un patron singleton.

private static void Initialize()
    {
        if (IsInitialized)
        {
            return;
        }

	
        // début de l'initialisation
        lock (InitializationLock)
        {
            // pattern du double-checkin
            if (IsInitialized)
            {
                return;
            }
	
            PricesProviderConfiguration configSection = (PricesProviderConfiguration)ConfigurationManager.GetSection("PricesConfigSection");
	
            if (configSection == null)
            {
                throw new …
            }
	
            _Providers = new PricesProviderCollection();
            ProvidersHelper.InstantiateProviders(configSection.Providers, _Providers, typeof(PricesProvider));
            _ProviderSettings = configSection.Providers;
	
            if (_Providers[configSection.DefaultProviderName] == null)
            {
                throw new …
            }
            _Default = _Providers[configSection.DefaultProviderName];
	
            IsInitialized = true;
        }
    }
	
    /// <summary>
    /// <b>false</b> indique que la classe n'a pas été initialisée
    /// </summary>
    private static bool IsInitialized;
    /// <summary>
    /// Variable utilisée pour poser un verrou
    /// </summary>
    private static object InitializationLock = new object();

Notez l’utilisation des classes ConfigurationManager et ProvidersHelper qui font l’essentiel du travail. Donc au total un code relativement simple.

Ce n’est pas tout, on doit encore déclarer la propriété suivante qui sera alimentée par la méthode que nous venons de voir :

[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private static PricesProvider _Default;

	
public static PricesProvider Default
{
    [DebuggerStepThrough]
    get
    {
        return _Default;
    }
}

Elle remonte le provider par défaut déclaré dans le fichier de configuration. Notez bien que la propriété est statique.

On peut agrémenter la classe en rendant public les collections ProvidersCollection ou ProviderSettingsCollection.

Bibliographie

[1] Aide en ligne sur ProviderBase
http://msdn.microsoft.com/fr-fr/library/system.configuration.provider.providerbase.aspx

Après le Barça, l'usap CAMPION .....

Hello everyone,

It's been a long time since I posted something on my blog. I was a little busy with my work. But this work enables now me to introduce you a new codeplex project : jQuery Control Toolkit. The aim of the project is to be able to use jQuery trough extenders in ASP.NET, but more globally, it adds new functionalities as jQuery plugins. The project is not so detailed yet, but if you can't wait for a description of each functionality, just have a look at the source code, there is a web application project which uses each (main) functionality. There are also more functionalities in the javascript source file jQuery.ACT.js, but, it is not documented at all (yet).

Have fun,

http://www.slideshare.net/mcottmeyer/adopting-agile-1521562

exactement le genre de présentation que je fais
rapide, concis, une idée par slide, des idées claires & simples
des diapositives compréhensibles par tous et d'elles-même!

a MUST HAVE and a MUST FOLLOW

IDM en Espagnol ce dit DSDM !!!

ÁMBITO Y MOTIVACIÓN

El Desarrollo de Software Dirigido por Modelos (DSDM), Model-Driven Development en inglés, es una propuesta para el desarrollo de software en la que se atribuye a los modelos el papel principal de todo el proceso. DSDM persigue elevar el nivel de abstracción en el desarrollo de software, convirtiendo a los modelos y a las transformaciones entre ellos en los principales artefactos de todas las fases del proceso de desarrollo de software: captura y gestión de los requisitos, análisis, diseño, implementación, despliegue, configuración, mantenimiento, evolución, etc. De esta forma se consigue mejorar la eficiencia del proceso de desarrollo y la calidad de la aplicación final.

La cinquième édition des journées sur l'Ingénierie Dirigée par les Modèles (IDM) a rejoint cette année les conférences CAL (Conférence sur les Architectures Logicielles) et LMO (Langages et Modèles à Objets) à Nancy. Ce rapprochement a été l'occasion de nouvelles interactions entre nos communautés pour répondre aux objectifs fondamentaux de l'IDM : maitriser la complexité du passage du problème au logiciel.

Depuis l'adoption par l'OMG de l'expression "Model Driven Architecture" en 2000, le développement dirigé par les modèles a été appliqué dans différents domaines (les systèmes critiques, les grands systèmes d'information, la production de portails web, etc) selon différents points de vue (la validation, le test, la production de code, la traçabilité, la sécurité, l'interopérabilité, etc). Avec la maturité des travaux en IDM vient le temps d'évaluer les solutions proposées. Les journées IDM qui visent à permettre aux chercheurs de présenter des travaux émergents, de discuter de nouvelles approches ou de retours d'expérience dans ce vaste domaine sont un lieu privilégié pour échanger sur ce thème. Dans le très riche programme des journées IDM 2009 nous lui avons accordé une part importante à la fois au travers des articles présentés, un atelier sur la validation des modèles et la mise en place d'une table ronde sur le thème "difficultés industrielles en IDM". Une conférence invitée de P. Albert (ex Ilog aujourd'hui IBM) a permis de parcourir les évolutions du développement logiciel et de souligner les points difficiles en terme d'ingénierie des modèles.

The IDM Team