Philosophies de l'approche de mise en œuvre
approche en cascade
L'approche en cascade de la mise en œuvre d'une application nécessite qu'un concepteur consulte un ou plusieurs représentants de l'organisation de l'utilisateur final et écrive toutes les spécifications de l'application. En règle générale, les spécifications sont présentées dans un ensemble de documents fonctionnels ou de cas d'utilisation, rédigés de manière à ce que l'utilisateur final puisse facilement lire et comprendre les documents.
L'utilisateur final signe ces documents, et les documents sont ensuite collectés par l'équipe de conception technique qui conçoit l'application, créant divers artefacts tels que des diagrammes de modèles de classes, des diagrammes d'états, des diagrammes d'activités et des modèles de données. Le but de cette phase est de tout écrire avec tant de détails qu'un développeur n'aura aucun mal à créer le code nécessaire. Il y a un transfert formel de la conception à l'équipe de développement et à l'équipe de test. Après la livraison, l'équipe de développement commence à coder et l'équipe de test utilise la conception technique en combinaison avec les cas d'utilisation pour créer des cas de test et des scénarios de test.
Une fois que l'équipe de développement a terminé le codage, le code est remis à l'équipe de test. L'équipe de test effectue les tests qu'elle a conçus en fonction des exigences et de la conception détaillée. Tous les problèmes seront résolus par l'équipe de développement. Une fois le processus de test et de correction terminé, l'application est livrée à l'utilisateur final pour un test d'acceptation. L'utilisateur final effectue une vérification finale pour voir si l'application est conforme aux exigences initiales. S'il est approuvé, il approuve le produit fini et le projet est terminé. Une fois que l'équipe de développement a terminé le codage, le code est remis à l'équipe de test.
L'équipe de test effectue les tests qu'elle a conçus en fonction des exigences et de la conception détaillée. Tous les problèmes seront résolus par l'équipe de développement. Une fois le processus de test et de correction terminé, l'application est livrée à l'utilisateur final pour un test d'acceptation. L'utilisateur final effectue une vérification finale pour voir si l'application est conforme aux exigences initiales. S'il est approuvé, il approuve le produit fini et le projet est terminé. Une fois que l'équipe de développement a terminé le codage, le code est remis à l'équipe de test. L'équipe de test effectue les tests qu'elle a conçus en fonction des exigences et de la conception détaillée.
Tous les problèmes seront résolus par l'équipe de développement. Une fois le processus de test et de correction terminé, l'application est livrée à l'utilisateur final pour un test d'acceptation. L'utilisateur final effectue une vérification finale pour voir si l'application est conforme aux exigences initiales. S'il est approuvé, il approuve le produit fini et le projet est terminé.
L'utilisateur final effectue une vérification finale pour voir si l'application est conforme aux exigences initiales. S'il est approuvé, il approuve le produit fini et le projet est terminé. L'utilisateur final effectue une vérification finale pour voir si l'application est conforme aux exigences initiales. S'il est approuvé, il approuve le produit fini et le projet est terminé.
Un projet peut avoir plus ou moins de phases lors de l'utilisation de l'approche en cascade, mais la caractéristique clé est un début et une fin très formels de chaque phase, avec des livrables très formels.
L'avantage de l'approche en cascade est que la responsabilité de l'équipe responsable de chaque phase est plus grande. Il est clair ce qu'ils doivent livrer, quand ils doivent le livrer et à qui ils doivent le livrer. Souvent, l'équipe de développement n'aura pas besoin d'interagir avec l'utilisateur. Cela peut être très utile lors de l'externalisation du développement dans un autre pays.
Le principal inconvénient de l'approche en cascade est que, dans un environnement où tout est organisé de manière très formelle, la flexibilité pour réagir aux changements diminue. Même le déménagement doit être organisé. Très peu d'entreprises semblent le faire efficacement, ce qui entraîne souvent une augmentation significative des frais généraux. Pour gérer les coûts d'un projet, certaines entreprises retardent même toute modification des exigences jusqu'à la livraison initiale de l'application, livrant ainsi une application qui ne répond pas aux besoins de l'utilisateur final.
développement agile
De nombreux projets de développement de logiciels de longue durée ont dépassé leur budget et n'ont pas livré le produit à temps. Le principe de la philosophie de développement logiciel agile est de minimiser les risques en développant des logiciels dans des délais courts, appelés itérations, qui durent généralement de une à quatre semaines. Chaque itération est comme son propre projet logiciel miniature et comprend toutes les tâches nécessaires pour libérer l'incrément de nouvelles fonctionnalités : planification, analyse des exigences, conception, codage, test et documentation. Alors qu'une itération peut ne pas ajouter suffisamment de fonctionnalités pour justifier la sortie du produit, un projet logiciel agile vise à être en mesure de publier un nouveau logiciel à la fin de chaque itération. A la fin de chaque itération, l'équipe réévalue les priorités du projet.
L'objectif du développement logiciel agile est d'atteindre la satisfaction du client grâce à la livraison rapide et continue de logiciels utiles ; visant toujours à construire ce dont le client a besoin ; saluer plutôt que s'opposer aux modifications tardives des exigences ; s'adapter régulièrement aux circonstances changeantes; d'avoir une coopération étroite et quotidienne entre entrepreneurs et développeurs, dans laquelle la conversation en face à face est la meilleure forme de communication.
Le principal avantage du développement logiciel agile est la flexibilité dans la gestion des changements, visant toujours à livrer en fonction des besoins de l'entreprise. L'inconvénient, bien sûr, est une augmentation de la complexité de la gestion de la portée, de la planification et de la budgétisation. Un autre risque courant est l'attention limitée portée à la documentation (technique).
Développement incrémental
Le développement logiciel incrémental est un mélange de développement agile et en cascade. Une application est conçue, implémentée et testée de manière incrémentielle afin que chaque incrément puisse être livré à l'utilisateur final. Le projet n'est pas terminé tant que la dernière incrémentation n'est pas terminée. Il vise à raccourcir la cascade en définissant des incréments intermédiaires et en utilisant certains des avantages du développement agile. Sur la base des commentaires reçus sur un incrément précédent, des ajustements peuvent être apportés lors de la livraison de l'incrément suivant. L'incrément suivant peut consister en un nouveau code ainsi qu'en des modifications du code fourni précédemment.
L'avantage est que les formalités restent en place, mais la gestion du changement devient plus facile. Le coût de tester et de déployer une application plusieurs fois sera plus élevé que de le faire une seule fois.
Contrôle du déroulement du programme
Le choix d'une approche de contrôle de flux de programme est une tâche très architecturale. L'objectif est de créer un plan de votre application où, une fois que vous commencez à ajouter des fonctionnalités et du code, tout semble avoir sa place. Si vous avez déjà révisé ou écrit du code de haute qualité, vous comprenez ce principe.
Code organisateur
La première étape de la conception du déroulement du programme consiste à organiser le code en établissant un ensemble de règles pour aider à créer un plan ou un plan de l'application. La maintenance, le débogage et la correction des bogues seront plus faciles car le code est situé dans un emplacement logique. Une fois que vous avez fait le travail préparatoire, vous pouvez choisir une approche pour implémenter la logique de votre application.
Les modèles de conception devraient jouer un rôle important dans la conception du contrôle de flux de programme. Au fil des ans, beaucoup de code a été écrit et de nombreuses solutions ont été conçues pour des problèmes récurrents. Ces solutions sont présentées dans des modèles de conception. L'application d'un modèle de conception à un problème de conception de logiciel courant vous aidera à créer des solutions facilement reconnaissables et pouvant être mises en œuvre par vos pairs. Les problèmes uniques nécessiteront toujours des solutions uniques, mais vous pouvez utiliser des modèles de conception pour vous guider dans leur résolution.
Création du projet
couches
La première étape consiste à considérer les couches logiques. Notez que les calques ne sont pas les mêmes que les calques, souvent confondus ou même considérés comme identiques.
couches contre couches
Les couches consistent à créer des limites dans votre code. La couche supérieure peut avoir des références au code dans les couches inférieures, mais une couche ne peut jamais avoir de référence au code dans une couche supérieure. Les niveaux font référence à la distribution physique des niveaux sur plusieurs ordinateurs. Par exemple, dans une application à trois niveaux, l'interface utilisateur est conçue pour s'exécuter sur un ordinateur de bureau, la logique d'application est conçue pour s'exécuter sur un serveur d'applications et la base de données s'exécute sur un serveur de données dédiées et le code dans chaque couche peut être composée de plusieurs couches.
Figure 8-1 : Organisation de base à trois niveaux
Les couches font référence aux niveaux d'abstraction. Les couches illustrées à la Figure 8-1 sont valables pour la plupart des applications. Ces niveaux sont également appelés les trois couches principales et peuvent avoir divers autres noms. En règle générale, le code de la couche présentation peut appeler des services dans la couche logique d'application, mais la couche logique d'application ne doit pas appeler la méthode dans la couche présentation. La couche de présentation ne doit jamais appeler directement la couche d'accès aux données, car cela contournerait les responsabilités mises en œuvre par la couche logique d'application. La couche d'accès aux données ne doit jamais appeler la couche logique d'application.
Les calques ne sont qu'une abstraction et le moyen le plus simple d'implémenter des calques est probablement de créer des dossiers dans votre projet et d'ajouter du code dans le dossier approprié. Une approche plus utile consisterait à placer chaque couche dans un projet distinct, créant ainsi des assemblages distincts. L'avantage de placer la logique de votre application dans un assembly de bibliothèque est que cela vous permettra de créer des tests unitaires, à l'aide de Microsoft Visual Studio ou de NUnit, pour tester la logique. Cela crée également une flexibilité dans le choix de l'emplacement de déploiement de chaque couche.
Couches physiques
Dans une application d'entreprise, vous vous attendez à avoir plusieurs clients pour la même logique. En fait, ce qui fait d'une application une application d'entreprise, c'est qu'elle sera déployée en trois couches : client, serveur d'applications et serveur de base de données. L'application Microsoft Office Access créée par le service commercial de votre entreprise, bien que très importante pour le service commercial, n'est pas une application d'entreprise.
Notez que la logique d'application et les couches d'accès aux données sont souvent déployées ensemble sur le serveur d'applications. Une partie de la conception du projet consiste à choisir d'accéder ou non au serveur d'applications à l'aide de services .NET ou Web distants. Quel que soit votre choix, vous ajouterez du code pour accéder facilement aux services distants dans la couche de présentation. Si vous utilisez des services Web pour accéder aux services sur votre serveur d'applications, Visual Studio .NET fera le travail pour vous et générera le code proxy, fournissant automatiquement une implémentation du modèle de proxy distant.
Ajout de motifs aux calques
Les trois couches de base fournissent une vue d'ensemble de haut niveau. Ajoutons quelques modèles structurels pour créer une architecture d'entreprise robuste. Le résultat est illustré à la Figure 8-2.
Concentrez-vous sur la couche logique de l'application. La figure 8-2 montre que l'accès à la logique d'application utilise le modèle de façade. Une façade est un objet qui fournit une interface simplifiée à un plus grand corps de code, comme une bibliothèque de classes. Une façade peut réduire les dépendances de code externe sur le fonctionnement interne d'une bibliothèque car la plupart du code utilise la façade, permettant ainsi plus de flexibilité dans le développement du système. Pour ce faire, la façade fournira une interface à grain grossier à une collection d'objets à grain fin.
flux de décision
Le contrôle de flux de programme, également appelé flux de décision, concerne la façon dont vous concevez les services dans votre couche logique d'application ou, comme vous l'avez vu dans le paragraphe précédent, la façon dont vous concevez les méthodes dans votre façade.
Il existe deux approches pour organiser vos services :
- orienté vers l'action
- conduit par l'état
Approche orientée vers l'action
En organisant les services en fonction des actions de l'utilisateur, vous implémentez la logique d'application en proposant des services, chacun d'entre eux traitant une demande spécifique de la couche de présentation. Ceci est également connu sous le nom de modèle de script de transaction. Cette approche est populaire car elle est simple et semble très naturelle. Des exemples de méthodes qui suivent cette approche sont BookStoreService.AddNewOrder(Order order) et BookStoreService.CancelOrder(int orderId).
La logique nécessaire pour effectuer l'action est implémentée de manière très séquentielle dans la méthode, ce qui rend le code très lisible mais aussi plus difficile à réutiliser. L'utilisation de modèles de conception supplémentaires, tels que le modèle de module de table, peut aider à augmenter la réutilisabilité.
Approche axée sur l'État
Il est également possible d'implémenter le flux de décision de l'application d'une manière beaucoup plus orientée état. Les services offerts par le serveur d'application sont de nature plus générique, par exemple BookStoreService.SaveOrder(Order order). Cette méthode examinera le statut de la commande et décidera d'ajouter une nouvelle commande ou d'annuler une commande existante.
Projets de structure de données
Vous devez faire plusieurs choix lors de la conception de vos structures de données. Le premier choix est le mécanisme de stockage des données, le second l'utilisation prévue des données et le troisième les exigences de version. Il existe trois façons d'examiner les conceptions de structure de données :
- Les services offrent des données ; les données sont le reflet de la base de données relationnelle.
- Les données doivent être mappées aux objets et les services permettent d'accéder aux objets.
- Les données proposées par les services doivent être basées sur des schémas.
Le choix de l'un des trois comme base de votre structure de flux de données doit être effectué à un stade précoce du processus de conception. De nombreuses entreprises ont une directive d'entreprise qui impose l'une des trois options sur tous les projets, mais dans la mesure du possible, vous devez réévaluer les options pour chaque projet, en choisissant l'approche optimale pour le projet en cours.
Choisir un moteur de stockage de données
Lors de la conception de votre application, vous devrez sans aucun doute concevoir une sorte de magasin de données. Les magasins et formes de stockage de données suivants sont disponibles :
- Enregistrer
- fichier app.config
- fichiers xml
- fichiers de texte brut
- Base de données
- file d'attente des messages
Chaque magasin a ses propres caractéristiques uniques et peut être adapté à des besoins spécifiques.
Conception du flux de données
Flux de données à l'aide d'ADO.NET
En implémentant des services centrés sur les données dans la couche logique de l'application, vous concevrez votre flux de données à l'aide d'ADO.NET. La bibliothèque de classes .NET Framework fournit une interface de programmation d'application (API) complète pour manipuler les données dans le code managé. Appelée ADO.NET, l'API se trouve dans l'espace de noms System.Data. La séparation complète des supports de données et des magasins de données est une caractéristique de conception importante d'ADO.NET. Des classes telles que DataSet, DataTable et DataRow sont conçues pour stocker des données mais ne conservent aucune connaissance de l'origine des données. Ils sont considérés comme indépendants de la source de données. Un ensemble distinct de classes, telles que SqlConnection, SqlDataAdapter et SqlCommand, s'occupe de la connexion à une source de données, de la récupération des données et du remplissage de DataSet, DataTable et DataRow. Ces classes sont situées dans des sous-espaces de noms tels que System.Data.Sql, System.Data.OleDB, System.Data.Oracle, etc. Selon la source de données à laquelle vous souhaitez vous connecter, vous pouvez utiliser des classes dans le bon espace de noms, et selon la portée du produit que vous utilisez, vous constaterez que ces classes offrent plus ou moins de fonctionnalités.
Étant donné que le DataSet n'est pas connecté à la source de données, il peut être utilisé avec succès pour gérer le flux de données dans une application. La figure 8-5 montre le flux de données lors de cette opération.
Examinons ce projet et imaginons que quelqu'un s'est connecté à votre librairie et a commandé trois livres. La couche de présentation gérait l'état du panier. Le client est prêt à passer la commande et a fourni toutes les données nécessaires. Il choisit d'envoyer la commande. La page Web transforme toutes les données en un DataSet contenant deux DataTables, un pour la commande et un pour la commande ; insère un DataRow pour la commande ; et insère trois DataRows pour les lignes de commande. La page Web affiche ensuite à nouveau ces données à l'utilisateur, en liant les contrôles de données au DataSet et en demandant Êtes-vous sûr ? L'utilisateur confirme la requête et celle-ci est soumise à la couche logique de l'application. La couche logique d'application vérifie le DataSet pour voir si tous les champs obligatoires ont une valeur et effectue une vérification pour voir si l'utilisateur a plus de 1000 US$. 00 sur les factures impayées. Si tout se passe bien, le DataSet est transmis à la couche d'accès aux données, qui se connecte à la base de données et génère des instructions d'insertion à partir des informations du DataSet.
L'utilisation du DataSet de cette manière est un moyen rapide et efficace de créer une application et d'utiliser la puissance de la bibliothèque de classes Framework et la capacité d'ASP.NET à lier des données à divers contrôles tels que GridView par rapport à un DataSet. Au lieu d'utiliser de simples objets DataSet, vous pouvez utiliser des objets DataSet typés et améliorer l'expérience de codage en implémentant du code dans la couche de présentation ainsi que dans la couche logique d'application. L'avantage de cette approche est aussi l'inconvénient de l'approche. De petites modifications du modèle de données n'entraînent pas nécessairement que de nombreuses méthodes doivent changer leurs signatures. Donc, en termes d'entretien, cela fonctionne très bien. Si vous vous souvenez que la couche de présentation n'est pas nécessairement une interface utilisateur, il peut également s'agir d'un service Web. Et si vous modifiez la définition du DataSet, peut-être parce que vous renommez un champ dans la base de données, alors vous modifiez le contrat auquel le service Web est abonné. Comme vous pouvez l'imaginer, cela peut entraîner des problèmes importants. Ce scénario fonctionne bien si la couche de présentation n'est qu'une interface utilisateur, mais pour les interfaces vers des systèmes ou des composants externes, vous souhaiterez masquer le fonctionnement interne de votre application et transformer les données en autre chose qu'un clone direct de votre modèle de données et vous souhaiterez créer des objets de transfert de données (DTO).
Flux de données utilisant le mappage relationnel d'objet
Le flux de données utilisant ADO.NET est une approche très centrée sur les données pour gérer le flux de données. Les données et la logique sont discrètes. L'autre extrémité du spectre adopte une approche plus orientée objet. Ici, des classes sont créées pour regrouper les données et le comportement. L'objectif est de définir des classes qui imitent les données et le comportement trouvés dans le domaine métier pour lequel l'application a été créée. Le résultat est souvent appelé objet métier. La collection d'objets métier qui composent l'application est appelée le modèle de domaine. Certains développeurs affirment qu'un modèle de domaine riche est préférable pour concevoir une logique plus complexe. Il est difficile de prouver ou de réfuter une telle affirmation. Sachez simplement que vous avez le choix et que c'est à vous de le faire.
La figure 8-6 montre un flux de données similaire à la figure 8-5 , sauf que vous avez maintenant ajouté la couche de mappage relationnel d'objet et remplacé les objets DataSet par différents supports de données.
Faites maintenant la même étape par étape qu'avant; imaginez que quelqu'un se soit connecté à votre librairie et ait commandé trois livres. La couche de présentation gérait l'état du panier. Le client est prêt à passer la commande et a fourni toutes les données nécessaires. Il choisit d'envoyer la commande. La page Web transforme toutes les données en un DTO, contenant les données d'une commande et avec trois lignes de commande, créant les objets selon les besoins. La page Web affiche à nouveau ces données à l'utilisateur, les contrôles de liaison de données par rapport au DTO à l'aide de l'ObjectDataSource dans ASP.NET 2.0 et demande Êtes-vous sûr ? L'utilisateur valide son choix et le DTO est soumis à la couche logique de l'application. La couche logique d'application transforme le DTO en un objet métier de type Order avec une propriété pour contenir trois objets OrderLine. La méthode Order. Validate() est appelé pour valider la commande et vérifier que tous les champs obligatoires ont une valeur, et une vérification est effectuée pour déterminer si l'utilisateur a plus de 1 000,00 R$ dans les bordereaux en attente. Pour ce faire, la commande appelle Order.Customer.GetOutstandingBills(). Si tout va bien, la méthode Order.Save() est appelée. La demande passera par la couche de mappage relationnel d'objet, où la demande et les lignes de la demande sont mappées à un DataTable dans un DataSet, et le DataSet est transmis à la couche d'accès aux données, qui se connecte à la base de données et génère des instructions d'insertion à partir de les informations du DataSet. Il existe, bien sûr, de nombreuses façons dont le mappage objet-relationnel peut se produire, mais toutes n'incluront pas la transformation en un DataSet. Certains créeront directement l'instruction d'insertion mais utiliseront toujours la couche d'accès aux données pour exécuter cette instruction.
Comme vous pouvez le voir, certaines transformations ont lieu. L'utilisation de DTO est nécessaire car un objet métier implémente le comportement et le comportement est susceptible de changer. Pour minimiser l'impact de ces modifications sur la couche de présentation, vous devez transformer les données de l'objet métier en un objet de transfert de données. En Java, l'objet de transfert de données est souvent appelé objet de valeur.
L'un des grands avantages de travailler avec des objets métier est qu'il aide vraiment à organiser votre code. Si vous regardez en arrière un élément de logique complexe, il est généralement très lisible car il y a très peu de code de plomberie. L'inconvénient est que la plupart des magasins de données sont encore relationnels et que le mappage des objets métier aux données relationnelles peut devenir assez complexe.
services basés sur un schéma
Vous venez de voir deux opposés lorsqu'il s'agit de gérer le flux de données. De nombreuses variantes sont possibles. Une variante courante est la variante dans laquelle un ensemble de données est utilisé comme support de données de base de l'interface utilisateur pour stocker les données, mais des schémas séparés (DTO) sont utilisés pour les services Web appelés à partir d'autres systèmes. La couche application transforme les données relationnelles en un schéma prédéfini. Le principal avantage de ceci est que toute application qui référence le service ne dépend d'aucun type d'implémentation interne du composant. Cela permet une plus grande flexibilité dans la gestion des versions, la rétrocompatibilité des interfaces et la possibilité de modifier l'implémentation du composant sans modifier l'interface du service.
Bien sûr, vous pouvez utiliser des objets métier dans l'application Web et contourner la transformation DTO, mais cela ne fonctionne généralement bien que si la logique d'application est implémentée avec l'application Web. N'oubliez pas que pour appeler Order.Save(), vous aurez besoin d'une connexion à la base de données. Que cela soit souhaitable dépend de vous et probablement de votre directeur de la sécurité.