La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 9: Architecting and Designing Software.

Présentations similaires


Présentation au sujet: "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 9: Architecting and Designing Software."— Transcription de la présentation:

1 Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 9: Architecting and Designing Software

2 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software2 9.1 Le Design Définition: Le Design est un processus de résolution de problèmes dont lobjectif est didentifier la meilleure façon de: implémenter les exigences fonctionnelles dun système... tout en respectant les contraintes imposées par les exigences non-fonctionnelles... -y incluant les contraintes de budget et en adhérant à des principes de base menant à un logiciel de bonne qualité

3 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software3 Le design en tant que série de décisions Tout designer doit faire face à une série de problèmes Ce sont des sous-problèmes devant être résolus. Chacun de ces problèmes peut être solutionné de différentes façons: Ce sont des options de design. Le designer doit donc prendre des décisions de design afin de résoudre chacun de ces sous-problèmes. Il faut donc être en mesure de toujours choisir la meilleure alternative.

4 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software4 Prendre des décisions Afin de prendre une décision de design, lingénieur logiciel doit tenir compte: des exigences du design courant de la technologie disponible des principes de bon design de lexpérience passée

5 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software5 Lespace de Design Lespace engendré par lensemble des solutions possibles pour un design sappelle lespace de design Par exemple:

6 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software6 Composante Tout élément logiciel ou matériel ayant un rôle bien défini. Une composante peut être isolée, et remplacée par une autre composante ayant des fonctionnalités équivalentes. La plupart des composantes devrait être réutilisable.

7 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software7 Module Une composante définie au niveau logiciel Par exemple des méthodes, des classes, des paquetages sont des modules en Java.

8 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software8 Système Une entité logique matérielle, logicielle, ou les deux, et ayant un ensemble de responsabilités définies Un système est implémenté à laide dun ensemble de modules Un système continu à exister même après que ses composantes ont été changées ou remplacées. Lanalyse des exigences consiste à déterminer les responsabilités dun système. Sous-système: Un système faisant partie dun système plus grand et ayant une interface bien définie

9 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software9 Diagramme UML représentant les parties dun système

10 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software10 Effectuer un design de haut en bas De haut en bas Dabord, la structure générale du design est conçue Puis les éléments de plus bas niveau sont étudiés Finalement pour en arriver aux détails fins du design: le format des données; les algorithmes.

11 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software11 Effectuer un design de bas en haut De bas en haut Identifier les éléments de bas niveau Prendre des décisions concernant la réutilisation Puis décider comment ces éléments seront assemblés pour créer des structures de plus haut niveau. Un savant mélange de ces deux approches est normalement utilisé: Une approche de haut en bas est nécessaire afin de garantir une bonne structure au système. Une approche de bas en haut est utile afin dassurer que des composantes réutilisables seront conçues.

12 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software12 Différents aspects du design Design darchitecture: La division du système en sous-systèmes et composantes -Comment ceux-ci seront interconnectées. -Comment vont-ils interagir. -Leurs interfaces. Design de classes: Attributs, opérations et associations. Design de linterface utilisateur Design des algorithmes: Étude de leur efficacité. Design de protocoles: Les messages et règles utilisés dans la conversation.

13 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software Principes menant à un design de qualité Justification: Accroître les profits par la réduction des coûts et laccroissement des revenus Sassurer de ladhérence aux exigences Accélérer le développement Accroître les attributs de qualité tels Utilisabilité Efficacité Fiabilité Maintenabilité Réutilisabilité

14 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software14 Principe de design 1: Diviser pour régner Afin de maîtriser un système complexe, il faut le subdiviser en une série de plus petits systèmes Différentes personnes peuvent ainsi travailler sur chacune des sous-parties. Chaque ingénieur peut se spécialiser Chacune des composantes est plus petite et plus facile à comprendre. Certaines parties peuvent être remplacées, changées ou modifiées sans avoir à modifier les autres parties du système.

15 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software15 Différentes façons de subdiviser un système Un système distribué est divisé en clients et serveurs Un système est divisé en sous-systèmes Un sous-système peut être subdivisé en paquetages Un paquetage est composé de classes Un classe est composée de méthodes

16 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software16 Principe de design 2: Accroître la cohésion autant que possible Un système a une cohésion élevée si les éléments interreliés sont groupés ensemble et si les éléments indépendants sont dans des groupes distincts Le système devient alors plus facile à saisir et éventuellement a y apporter des changements Type de cohésion: Fonctionnelle, en couches, communicationnelle, séquentiel, procédurale, temporelle, utilitaire

17 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software17 Cohésion fonctionnelle Lorsque que tout le code effectuant le calcul dun certain résultat se trouve au même endroit i.e. lorsquun module effectue le calcul dun seul résultat, sans effets secondaires. Bénéfices: Facilite la compréhension Plus facile à réutiliser Plus facile à remplacer Un module gérant une base de données, créant des fichiers ou interagissant avec un utilisateur nest pas fonctionnellement cohésif

18 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software18 Cohésion en couches Tous les fournisseurs daccès à un ensemble de services interreliés sont groupés ensemble Les différentes couches devraient former une hiérarchie Les couches de plus haut niveau peuvent accéder aux couches de plus bas niveaux, Les couches de bas niveaux naccèdent pas aux couches de plus haut niveau Lensemble des procédures quune couche met à la disposition des autres couches pour accéder aux services quelle ofre est lapplication programming interface (API) Une couche peut être remplacée sans que cela naffecte les autres couche Il faut simplement reproduire le même API

19 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software19 Exemples de systèmes en couches Screen display facilities User account management File system Kernel (handling processes and swapping) Application programs User interface Application logic Database access Network communication Transmitting and receiving Dealing with packets Dealing with connections Dealing with application protocols a) Typical layers in an application program b) Typical layers in an operating system c) Simplified view of layers in a communication system Operating system access

20 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software20 Cohésion communicationnelle Tous les modules accédant ou manipulant les même données sont groupées ensemble Une classe a une bonne cohésion communicationnelle si Toutes les opérations de manipulation de données sont contenus dans cette classe. La classe ne gère que les données qui la concerne. Avantage: Lorsquun changement doit être effectué sur les données, tout le code concerné se trouve au même endroit

21 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software21 Cohésion séquentielle Les procédures pour lesquelles lune produit une sortie servant dentrée à une autre sont groupées ensemble Ce genre de cohésion est valable lorsque les autres types de cohésion ont été achevés.

22 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software22 Cohésion procédurale Les procédure qui se succèdent lune après lautre sont groupées ensemble Même si une ne produit pas un résultat utilisé par la suivante. Plus faible que la cohésion séquentielle.

23 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software23 Cohésion temporelle Les opérations effectuées lors de la même phase dexécution sont groupées ensemble Par exemple, tout le code utilisé lors de linitialisation pourrait être regroupé.

24 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software24 Cohésion utilitaire Tous les autres utilitaires qui ne peuvent être placés ailleurs sont groupés ensemble Un utilitaire est une procédure dintérêt général pouvant être utilisé dans une grande variété dapplications. Les utilitaires sont hautement réutilisables Par exemple, la classe java.lang.Math.

25 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software25 Principe de design 3: Réduire le couplage en autant que possible Il y a couplage lorsquune interdépendance existe entre deux modules Lorsquil y a dépendance, un changement dans une composante implique un changement dans une autre composante. Un réseau complexe de dépendances rend difficile la compréhension dune composante. Type de couplage: Contenu, Commun, Contrôle, Estampillage, Données, Appel, Type, Inclusion, Externe

26 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software26 Couplage de contenu Lorsquune composante subrepticement modifie les données internes dune autre composante Le fait dencapsuler les données réduit considérablement le couplage Elles sont déclarées private Avec des méthodes get et set

27 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software27 Exemple de couplage de contenu public class Line { private Point start, end;... public Point getStart() { return start; } public Point getEnd() { return end; } } public class Arch { private Line baseline;... void slant(int newY) { Point theEnd = baseline.getEnd(); theEnd.setLocation(theEnd.getX(),newY); }

28 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software28 Couplage commun Lorsquune variable globale est utilisée Toutes les composantes utilisant cette variable globale deviennent alors couplées les unes aux autres Une forme plus faible de couplage est présente lorsque la variable est accessible à un nombre restreint de classes e.g. un paquetage Java Acceptable lorsque la variable globale fait référence à des paramètres globaux du système Le Singleton est un moyen doffrir un accès contrôlé à un objet

29 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software29 Couplage de contrôle Lorsquune procédure en appel une autre en utilisant une variable de contrôle ou une commande contrôlant lexécution de la procédure appelée Afin deffectuer un changement, il faut modifier à la fois lappelé et lappelant Lutilisation dune opération polymorphique constitue la meilleure façon déviter le couplage de contrôle Une autre façon de réduire ce type de couplage consiste à avoir recours à une table look-up Chaque commande est alors associée une méthode qui sera appelée lorsque ces commande est lancée

30 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software30 Exemple de couplage de contrôle public routineX(String command) { if (command.equals("drawCircle") { drawCircle(); } else { drawRectangle(); }

31 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software31 Couplage destampillage Lorsquune classe est déclarée dans la liste des arguments dune méthode Une classe en utilise donc une autre Afin de réutiliser une classe, il faut aussi utiliser lautre Pour réduire ce type de couplage Utiliser une interface Transmettre que des variables simples

32 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software32 Exemple de couplage destampillage En utilisant des données simples: public class er { public void send (Employee e, String text) {...}... } public class er { public void send (String name, String , String text) {...}... }

33 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software33 Exemple de couplage destampillage En utilisant une interface: public interface Addressee { public abstract String getName(); public abstract String get (); } public class Employee implements Addressee {…} public class er { public void send (Addressee e, String text) {...}... }

34 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software34 Couplage de données Lorsque les types des arguments sont des données simples Plus il y a dargument, plus ce couplage est fort Les méthodes appelantes doivent fournir tous ces arguments Il faut réduire ce type de couplage en évitant dutiliser des arguments non-nécessaires Il y a souvent un compromis à faire en couplage de données et couplage destampillage i.e. réduire lun accroît lautre

35 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software35 Couplage dappel Lorsquune méthode en appelle une autre Ces méthodes sont couplée car le comportement de lune dépend du comportement de lautre Il y aura toujours du couplage dappel dans tout système Si une même séquence dappel se répète fréquemment, alors il faudrait songer à encapsuler cette séquence en créant une méthode regroupant ces appels

36 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software36 Couplage de type Lorsquun module utilise un type défini dans un autre module Est présent chaque fois quune classe déclare un attribut dune autre classe. La conséquence est que si le type (la classe) est modifié, alors la classe qui en fait usage devra aussi être changé Toujours utiliser le type le plus général

37 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software37 Couplage dinclusion Lorsquune composante en importe une autre (un paquetage en Java) ou en inclut une autre (comme en C++). La composante qui procède à linclusion devient dépendante de la composante inclue. Si cette composante incluse est modifiée ou si quelque chose y est ajouté. Il peut se produire un conflit; un nouvel élément pouvant avoir le même nom quun élément existant.

38 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software38 Couplage externe Lorsquun module dépend dune librairie, dun système dexploitation, dun matériel Il faut réduire au maximum la dispersion de cette dépendance à travers le code. La Façade est un moyen efficace de réduire ce type de couplage

39 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software39 Principe de design 4: Maintenir le niveau dabstraction aussi élevé que possible La complexité dun design est réduite lorsquun maximum de détails se trouve masqué Une abstraction de qualité utilise toujours le principe de masquage de linformation Une abstraction permet de saisir lessence dun système sans avoir à en connaître les détails de son implémentation

40 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software40 Abstraction et classes Les classes sont des abstractions de données contenant des abstractions de procédures Attribuer une visibilité privée aux variables permet daccroître la qualité de labstraction. Réduire le nombre de méthodes publique accroît la qualité de labstraction La création de super-classes et dinterfaces permet accroît considérablement la qualité de labstraction. Les attributs et les associations sont des abstractions de données. Les méthodes sont des abstractions de procédures Une meilleure abstraction est obtenue en définissant des méthodes ayant peu de paramètres

41 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software41 Principe de design 5: Accroître la réutilisabilité en autant que possible Concevoir le design de façon à ce que les différents aspects du système soient utilisable dans différents contextes Généraliser le design en autant que possible Simplifier le design en autant que possible Ajouter des options aux différents modules

42 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software42 Principe de design 6: Réutiliser autant de composantes que possible La réutilisation est le principe complémentaire au principe de réutilisabilité Réutiliser les designs existants permet de tirer profit de leffort investi par les concepteurs de composantes réutilisables Le clonage ne doit pas être vu comme une forme de réutilisation

43 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software43 Principe de design 7: Rendre le design flexible Anticiper les changements qui seront apportés au design Réduire le couplage et accroître la cohésion Créer des abstractions Ne pas introduire de constante numérique ad hoc (pas de hard-coding) Permettre un maximum doptions Ne pas restreindre inutilement les options Utiliser du code réutilisable et rendre le code réutilisable

44 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software44 Principe de design 8: Anticiper lobsolescence Planifier les changements de technologies ou denvironnements de façon à ce que peu ou pas de modifications soient requises Éviter dutiliser des versions préliminaires de nouvelles technologies Éviter dutiliser des librairies spécifiques à des environnements particuliers Éviter dutiliser des éléments mal documentés Éviter dutiliser des logiciels ou du matériel provenant de fournisseurs peu fiables Utiliser des technologies standards supportés par de multiples vendeurs

45 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software45 Principe de design 9: Concevoir des designs portables Permettre au logiciel de sexécuter sur autant de plate- formes que possible Éviter dutiliser des éléments spécifiques à un environnement particulier E.g. une librairie disponible seulement sous Microsoft Windows

46 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software46 Principe de design 10: Concevoir un design aisé à tester Faciliter lincorporation de tests Concevoir un programme permettant de tester automatiquement le logiciel Cet aspect sera discuté au chapitre 10 Sassurer que toutes les fonctionnalités du logiciel peuvent être conduites par un programme externes sans avoir à passer par linterface utilisateur Sous Java, il est possible de créer une méthode main() dont le rôle est de tester les autres méthodes de la classe

47 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software47 Principe de design 11: Concevoir un design défensif Ne jamais faire confiance aux composantes utilisées Traiter tous les cas possibles, même les cas dusage inappropriés Vérifier que toutes les données en entrée sont valides: les préconditions Toutefois un design trop précautionneux peu résulter en une multiplication inefficace de séquences répétées vérifications

48 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software48 Design par contrats Il sagit dune technique permettant de concevoir de façon systématique un design défensif qui demeure efficace Principe de base Chaque méthode conclut un contrat avec ses appelant Ce contrat introduit un ensemble dassertions définissant: Quelles sont les préconditions requises pour que la méthode puisse démarrer son exécution Quelles sont les postconditions que la méthode assure rencontrer à la fin de son exécution Quels sont les invariants que la méthode requiert et garantie au cours de son exécution

49 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software Des techniques permettant de prendre les bonnes décision de design Définir les priorités et les objectifs afin de choisir les bonnes alternatives Étape 1: Lister et décrire les différentes alternatives possibles. Étape 2: Lister les avantages et désavantages de chacune des alternatives en fonction des priorités et objectifs. Étape 3: Déterminer quelles alternatives ne permettent pas de rencontrer certains objectifs. Étape 4: Choisir lalternative qui permet le mieux de rencontrer les objectifs définis. Étape 5: Ajuster les priorités pour les décision subséquentes.

50 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software50 Exemple de priorités et objectifs Imaginer un système ayant les objectifs suivants (par ordre de priorité): Securité: Le code cryptographique ne doit pas est brisable en moins de 100 heures de CPU sur un processeur Intel de 400Mhz en utilisant les techniques connues de crypto-analyse. Maintenabilité. Efficacité du CPU. Temps de réponse inférieur à une seconde. Largeur de bande: Pas plus de 8KB de données par transaction. Mémoire. Pas plus de 20MB de RAM. Portabilité. Doit être exécutable sous Windows 98, NT 4 et ME ainsi que sous Linux

51 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software51 Exemple dévaluation dalternatives DNMOsignifie: ne rencontre pas cet objectif

52 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software52 Analyse coût-bénéfice afin de déterminer lalternative la plus avantageuse Le coût est constitué de: Le coût incrémental lié à lingénierie du logiciel envisagé, y incluant sa maintenance Le coût incrémental du développement de la technologie envisagée Le coût incrémental subit par les utilisateur et léquipe de support Les bénéfices sont constitué de: La réduction du temps de développement présent et futur Laccroissement anticipé des ventes ou de bénéfices financiers profitables aux utilisateurs

53 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software Architecture logicielle Larchitecture logicielle est le processus de conception de lorganisation globale du système et incluant: La subdivision du logiciel en sous-systèmes. Les décisions à prendre concernant leur interactions. La détermination des interfaces. Larchitecture est le cœur du système, tous les ingénieurs impliqués doivent donc bien la maîtriser. Larchitecture va souvent contraindre lefficacité, la réutilisabilité et la maintenabilité du système.

54 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software54 Limportance dune bonne architecture logicielle Pourquoi développer un bon modèle de larchitecture: Afin que tous aient une meilleure compréhension du système Afin que les différents concepteurs puissent travailler isolement sur différentes composantes du système Afin dêtre mieux préparer à étendre les fonctionnalités du système Afin de faciliter la réutilisation et la réutilisabilité

55 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software55 Un bon modèle architectural Une architecture sera habituellement décrite sous divers points de vue La subdivision du système en sous-systèmes Les interfaces des différents sous-systèmes La dynamique de linteraction requise entre les différentes composantes du système Les données utilisées et échangées à travers le système Les composantes qui existeront et leur répartition physique

56 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software56 Concevoir une architecture stable Afin dassurer la maintenabilité et la fiabilité du système, une architecture doit demeurer stable. Une architecture est stable lorsque lajout dun nouvel élément ne requiert que des changements mineurs

57 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software57 Le développement dun modèle de larchitecture Débuter avec une première ébauche de larchitecture globale Fondée sur les principales exigences et les cas type les plus importants Déterminer les principales composantes Sélectionner certains patrons architecturaux Section 9.5 Suggestion: plusieurs équipes distinctes peuvent travailler de façon indépendante pour ensuite comparer et fusionner leurs idées

58 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software58 Le développement dun modèle de larchitecture Raffiner larchitecture Identifier les principales interactions entre composantes et les interfaces qui seront requises Décider comment les données et les procédures seront réparties Déterminer si certains éléments seront réutilisés ou si, par exemple, un cadre dapplications pourrait être conçu Considérer tour à tour chacun des cas type afin de sassurer quils seront réalisables Faire évoluer cette architecture

59 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software59 La description dune architecture avec UML Tous les diagrammes UML peuvent être mis à contribution Quatre diagrammes sont particulièrement utiles: Diagrammes de paquetage Diagramme de sous-système Diagramme de composante Diagramme de déploiement

60 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software60 Diagrammes de paquetage

61 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software61 Diagrammes de composantes

62 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software62 Diagrammes de déploiement

63 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software Patrons architecturaux La notion de patron peut aussi sappliquer à larchitecture. Ce sont donc des patrons architecturaux ou styles darchitecture. Ceux-ci permettent de concevoir une architecture solide et flexible en utilisant les composantes appropriées Ces composantes doivent être indépendantes les une des autres, dans la mesure du possible.

64 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software64 Larchitecture multi-couches Dans un système en couches, chaque couche ne communique quavec la couche inférieure. Chacune des couches doit avoir une interface clairement définie. Les couches inférieures offrent des services aux couches supérieures. Un système complexe se construit en superposant des couches de niveaux dabstraction croissant. Linterface utilisateur est lune de ces couches distinctes. La couche immédiatement sous linterface utilisateur offre les services définis par les cas-type. Les couches inférieures offre des services plus spécifiques. -e.g. accès à des bases de données

65 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software65 Exemple dun système multi-couches

66 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software66 Larchitecture multi-couche et les principes de design 1. Diviser pour régner: les couches son conçues indépendamment. 2. Accroître la cohésion: les couches présentent une cohésion en couches. 3. Réduire le couplage: les couches inférieures ne connaissent rien des couches supérieures et communiquent entre elles via leur API. 4. Accroître labstraction: il nest pas nécessaire de connaître les détails internes des couches inférieures pour concevoir les couches supérieures. 5. Accroître la réutilisation: les couches inférieures peuvent est conçues de façon à offrir des services génériques.

67 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software67 Larchitecture multi-couche et les principes de design 6. Accroître la réutilisation: toute couche existante offrant les services requis peut être utilisé. 7. Accroître la flexibilité: de nouvelles fonctionnalités peuvent être ajoutées à laide des couches inférieures; une couche peut être remplacée facilement. 8. Anticiper lobsolescence: en isolant les composantes, elle deviennent plus résistante à lobsolescence. 9. Concevoir des designs portables: Toutes les fonctionnalités dépendantes peuvent être confinées au couches inférieures. 10. Faciliter les tests: Chacune des couches peut être testée indépendamment. 11. Concevoir de façon défensive: le API est lendroit par excellence ou placer les assertions de vérification.

68 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software68 Larchitecture client-serveur et autres architectures distribuées Au moins une des composantes joue le rôle de serveur pouvant recevoir des connexions. Au moins une des composantes joue le rôle de client pouvant se connecter à un serveur et requérir des services. Lextension de cette architecture est le patron pair-à- pair. Un système composé des plusieurs composantes distribué à travers plusieurs hôtes.

69 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software69 Un exemple de systèmes distribués

70 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software70 Larchitecture distribuée et les principes de design 1. Diviser pour régner: la division du système en clients et serveurs est une manière très efficace de subdiviser le système. Chacune de ces composantes peut être développé séparément. 2. Accroître la cohésion: le serveur offre des services cohésifs aux clients. 3. Réduire le couplage: il existe généralement un seul canal de communication. 4. Accroître labstraction: chacune des composantes distribuées constituent de bonne abstractions. 6. Accroître la réutilisation: il est souvent possible de trouver des composantes à réutiliser sur lesquelles construire un bon système distribué Toutefois, les système client-serveur sont souvent bâtis de façon très spécifique.

71 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software71 Larchitecture distribuée et les principes de design 7. Accroître la flexibilité: Les systèmes distribués peuvent aisément être configurés pour recevoir de nouveaux clients ou serveurs. 9. Concevoir des designs portables: des clients sur différentes plate-formes peuvent communiquer entre eux. 10 Faciliter les tests: les client et serveurs peuvent être testés de façon indépendante. 11. Concevoir de façon défensive: les vérifications sont insérés dans le traitement des messages.

72 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software72 Larchitecture courtier (broker) Le but est de distribuer de façon transparente différents aspects du système Un objet fait appel aux méthodes dun autre objet sans savoir que celui-ci est localisé sur une autre machine. CORBA est lun des standards bien connu permettant de construire ce genre darchitecture.

73 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software73 Exemple dune architecture courtier

74 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software74 Larchitecture courtier et les principes de design 1. Diviser pour régner: les objets distribués peuvent être conçus séparément. 5. Accroître la réutilisation: il est souvent possible de concevoir les objets distribués de façon à ce que les objets distribués puisse être utilisés par dautres systèmes. 6. Accroître la réutilisation: différents objets distribués peuvent être réutilisé. 7. Accroître la flexibilité: les courtiers sont des objets facile à mettre à jour et les objets peuvent communiquer avec différents courtiers. 9. Concevoir des designs portables: les différents objets en transaction peuvent être localisés sur des plate-formes différentes. 11. Concevoir de façon défensive: des assertions peuvent facilement être ajoutés aux courtiers.

75 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software75 Larchitecture transactionnelle Un processus traite les différentes entrées une à une. Chaque entrée décrit une transaction – une commande qui modifie les données stockées dans le système Une composante effectue la répartition des transactions vers les composantes de traitement

76 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software76 Exemple dun système transactionnel

77 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software77 Larchitecture courtier et les principes de design 1. Diviser pour régner: les différents processus de traitement sont en fait des divisions naturelles du système. 2. Accroître la cohésion: les différentes composantes de traitement sont naturellement cohésifs. 3. Réduire le couplage: séparer le répartiteur et les composantes de traitement tend à réduire le couplage. 7. Accroître la flexibilité: il est très facile dajouter de nouvelles transactions. 11. Concevoir de façon défensive: il est possible dajouter des assertions dans chacune des composantes de traitement.

78 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software78 Larchitecture en filtres Un flot de données, souvent relativement simples, passe dun processus à un autre pour être transformées Les données sont donc transformées par les traitements subits. Les différents processus travaillent en concurrence. Cette architecture est très flexible. Presque toutes les composantes peuvent être retirées. Les composantes peuvent être remplacées. De nouvelles composantes peuvent être insérées. Certaines composantes peuvent être réordonnées.

79 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software79 Exemple darchitecture en filtres

80 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software80 Larchitecture en filtres et les principes de design 1. Diviser pour régner: les différents filtres peuvent être conçus indépendamment. 2. Accroître la cohésion: ces différents processus ont une cohésion fonctionnelle. 3. Réduire le couplage: les différents filtres ont une seule entrée et une seule sortie. 4. Accroître labstraction: chacun des filtres, dont les détails internes sont masqués, constitue une bonne abstraction. 5. Accroître la réutilisabilité: les différents filtres peuvent être réutilisé dans différents contextes. 6. Accroître la réutilisation: il est souvent possible de trouver des filtres à réutiliser.

81 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software81 Larchitecture en filtre et les principes de design 7. Accroître la flexibilité: la séquence de filtres peut être modifiée à volonté. 10. Faciliter les tests: les différents filtres sont aisé à tester individuellement. 11. Concevoir de façon défensive: les entrées du filtre peuvent être rigoureusement vérifiées.

82 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software82 Larchitecture Modèle-Vue-Contrôleur (MVC) Ce patron architectural est utilisé pour séparer linterface utilisateur des autres parties du système Le modèle contient les classes dont les instances seront visualisée et manipulée La vue contient les objets utilisés pour afficher les données du modèle Le contrôleur contient les objets qui gère les interactions de lutilisateur avec la vue et le modèle Le patron de conception observateur-observé est normalement utilisé pour séparer la vue du modèle

83 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software83 Exemple darchitecture MVC

84 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software84 Larchitecture MVC et les principes de design 1. Diviser pour régner: les trois composantes peuvent être conçues séparément. 2. Accroître la cohésion: les composantes ont une cohésion plus forte que si ces composantes étaient combinées. 3. Réduire le couplage: la communication entre les composantes est minimale. 6. Accroître la réutilisation: la vue et le contrôleur se construisent avec des éléments réutilisables. 7. Accroître la flexibilité: il est habituellement aisé dapporter des changements aux différentes composantes. 10. Faciliter les tests: il est possible de tester lapplication indépendamment de lIU.

85 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software85 Larchitecture orienté Service Cette architecture organise une application en une collection de services communiquant entre eux via des interfaces bien définies Sous Internet, ce sont des services Web Un service web est une application accessible vis lInternet, pouvant être intégrée à dautres services afin de former un système complet Les différentes composantes communiquent généralement entre elles en utilisant le standard XML

86 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software86 Exemple dune application orientée service

87 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software87 Larchitecture orientée service et les principes de design 1. Diviser pour régner: lapplication est construite à partir de services indépendants. 2. Accroître la cohésion: les service Web sont structurés en couches et ont une excellent cohésion fonctionnelle. 3. Réduire le couplage: les application Web sont très peu couplées puisque bâties à laide de composantes distribuées. 5. Accroître la réutilisabilité: un service Web est une composante hautement réutilisable. 6. Accroître la réutilisation: une application Web est conçues à partir de service Web existant. 7. Accroître la flexibilité: il est habituellement aisé dapporter des changements aux différentes composantes.

88 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software88 Larchitecture orientée service et les principes de design 8. Anticiper lobsolescence: les services obsolètes peuvent être remplacés par de plus récents sans affecter les applications lutilisant. 9. Concevoir des designs portables: un service peut être déployé sur toute plateforme supportant les standards requis. 10. Faciliter les tests: chaque service peut être testé indépendamment. 11. Concevoir de façon défensive: un service Web impose le design défensif puisque plusieurs applications peuvent y accéder.

89 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software89 Larchitecture orientée message Sous cette architecture, les différents sous-systèmes communiquent et collaborent entre eux via léchange de messages. Aussi connu sous le nom de Message-oriented Middleware (MOM) Le cœur de cette architecture est un systèeme de messagerie entre applications Les applications communiquant entre elles nont pas à être tous disponibles en même temps Le message est envoyé par une composante (le publisher) à travers un canal virtuel (topic) auquel se sont inscrits les composantes intéressées (subscribers)

90 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software90 Exemple darchitecture orientée message

91 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software91 Larchitecture orientée message et les principes de design 1. Diviser pour régner: lapplication est construite à partir de composantes isoléess. 3. Réduire le couplage: les composantes ne partagent que les messages. 4. Accroître labstraction: le format des messages est généralement simple, tous les détails de lapplication étant caché derrière le système de messagerie. 5. Accroître la réutilisabilité: une composante sera réutilisable si les messages sont suffisamment flexible. 6. Accroître la réutilisation: une composante peut être réutilisée en autant que le système adhère au format de message prescrit. 7. Accroître la flexibilité: les composantes peuvent facilement être mises à jour ou remplacées.

92 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software92 Larchitecture orientée service et les principes de design 10. Faciliter les tests: chaque composante peut être testée indépendemment. 11. Concevoir de façon défensive: la défense dune composante est assurée en validant tous les messages reçus.

93 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software93 Sommaire des archtectures vs les principes de design Multi-layers Client-server Broker Transaction processing Pipe-and-filter MVC Service-oriented Message-oriented

94 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software Écrire un bon document de design Les documents de design aident à concevoir de meilleurs designs Ils obligent les concepteurs à considérer les différentes alternatives avec de commencer limplémentation. Ils permettent de procéder à la révision et à lamélioration du design en groupe. Le document de design est un bon moyen de communication. Pour ceux qui vont procéder à la réalisation du design. Pour ceux qui auront à modifier le design. Pour ceux qui auront à créer de nouveaux systèmes à intégrer aux systèmes existants.

95 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software95 Structure du document de design A. Objectif: Quel système ce document décrit-il. Faire référence aux exigences qui sont implémentées par ce design (retraçabilité). B. Priorités générales: Décrire les priorités qui ont guidées lélaboration de ce design. C. Survol du design: Donner une vue générale du design. D. Principaux problèmes identifiés: Discuter les principaux problèmes rencontrés. Donner les alternatives possibles, la décision et les justifications. E. Autres éléments: Donner tout autre détails dintérêt.

96 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software96 Quand écrire un document de design Éviter de documenter des éléments du design qui apparaîtraient évidents à un programmeur expérimenté. Éviter de placer dans le document de linformation qui devrait se trouver dans les commentaires du programme.

97 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software Design of a Feature of the SimpleChat System A. Purpose This document describes important aspects of the implementation of the #block, #unblock, #whoiblock and #whoblocksme commands of the SimpleChat system. B. General Priorities Decisions in this document are made based on the following priorities (most important first): Maintainability, Usability, Portability, Efficiency C. Outline of the design Blocking information will be maintained in the ConnectionToClient objects. The various commands will update and query the data using setValue and getValue.

98 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software98 Design Example D. Major design issue Issue 1: Where should we store information regarding the establishment of blocking? Option 1.1: Store the information in the ConnectionToClient object associated with the client requesting the block. Option 1.2: Store the information in the ConnectionToClient object associated with the client that is being blocked. Decision: Point 2.2 of the specification requires that we be able to block a client even if that client is not logged on. This means that we must choose option 1.1 since no ConnectionToClient will exist for clients that are logged off.

99 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software99 Design Example E. Details of the design: Client side: The four new commands will be accepted by handleMessageFromClientUI and passed unchanged to the server. Responses from the server will be displayed on the UI. There will be no need for handleMessageFromServer to understand that the responses are replies to the commands.

100 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software100 Design Example Server side: Method handleMessageFromClient will interpret #block commands by adding a record of the block in the data associated with the originating client. This method will modify the data in response to #unblock. The information will be stored by calling setValue("blockedUsers", arg) where arg is a Vector containing the names of the blocked users. Method handleMessageFromServerUI will also have to have an implementation of #block and #unblock. These will have to save the blocked users as elements of a new instance variable declared thus: Vector blockedUsers ;

101 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software101 Design Example The implementations of #whoiblock in handleMessageFromClient and handleMessageFromServerUI will straightforwardly process the contents of the vectors. For #whoblocksme, a new method will be created in the server class that will be called by both handleMessageFromClient and handleMessageFromServerUI. This will take a single argument (the name of the initiating client, or else 'SERVER'). It will check all the blockedUsers vectors of the connected clients and also the blockedUsers instance variable for matching clients.

102 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software102 Design example The #forward, #msg and #private commands will be modified as needed to reflect the specifications. Each of these will each examine the relevant blockedUsers vectors and take appropriate action.

103 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software Risques et difficultés en design Comme la modélisation, le design est une habilité qui sacquière avec lexpérience Les ingénieurs logiciels ne devrait pas procéder seuls au design dun grand système Les architecte devrait attentivement étudier les designs de systèmes existants Un design mal conçu mène à une maintenance coûteuse Toujours sassurer de suivre les principes de design

104 © Lethbridge/Laganière 2001 Chapitre 9: Architecting and designing software104 Risques et difficultés en design La qualité dun design exige une attention de tous les instants Concevoir le design de façon flexible afin de sadapter harmonieusement aux changements. Sassurer que la documentation est adéquate Sassurer que les changements sont bien gérés


Télécharger ppt "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapitre 9: Architecting and Designing Software."

Présentations similaires


Annonces Google