Rappels. Génie logiciel. Implemented tactics. Pattern: Facade. Tactiques de performance Tactiques de disponibilité. Patterns

Transcription

1 Rappels Génie logiciel Philippe Dugerdil Tactiques de performance Tactiques de disponibilité Patterns Layer Publish/subscribe MVC Value object Proxy Pattern: Facade Implemented tactics Client Class Class5 Class3 Class4 Class6 Class7 Class2 Modifiability tactics Hide information Restrict communication paths Use an intermediary Class Class4 Class7 Client Facade Class3 Class2 Class5 Class6 3

2 Example: client-server objects & proxies New architecture: façade & proxy 5 6 Pattern: Broker Implemented tactics Bridge to other broker Modifiability tactics Use an intermediary Client-side Proxy 0..* transfers message Broker transfers message 0..* Server-side Proxy calls 0..* 0..* calls Client 0..* uses API uses API 0..* Server

3 Pattern: Pipes and Filters The processing chain Filter Filter Filter Filter Pipe Pipe Pipe Performance tactics: It Introduce concurrency First-in first-out Implemented tactics Example Early compiler architecture inputfile : Data Source lexicalanalysis : Filter syntacticalanalysis y : Filter semanticalanalysis : Filter codegeneration : Filter outputfile : Data Sink

4 Effets de bord: dépendances Syntaxe et sémantique des méthodes Syntaxe et sémantique des données Semblable au précédent en OO Séquence des messages entre 2 modules Identité & localisation d un module Solution: mettre un intermédiaire. Façade Pblih Publish subscribe Façade Broker Designing a layered architecture: strategies Anticipate change.. 4 Responsibility-based structure Exemple [Source: Peter Eeles - Layering Strategies, Rational Software White Paper TP 99, 08/0, 2002] 6

5 Structuring in the dvt environment Reuse-based structure 7 8 Exemple Structuring in the dvt environment [Source: Peter Eeles - Layering Strategies, Rational Software White Paper TP 99, 08/0, 2002] 9 20

6 Business component-based horizontal structure Structuring in the dvt environment 2 22 Bi-dimensional structure component / responsibility Structuring in the dvt environment 23 24

7 Bi-dimensional structure component / reuse What is the structuring criterion? 25 e: RUP2000, IBM/Rational, Packaging the analysis objects Bi-dimensional structure component / reuse with analysis objects Modification source GUI=> grouping by responsibility Functionality l => grouping by function 27 28

8 Steps to layer a system. Identify modification sources 2. Choose the layering criteria 3. Identify the reusable subsystems 4. Dispatch the objects in subsystems, components and packages 5. Dispatch the subsystems, components and packages in the layers 6. Check the dependencies between elements in layers 7. If required, dispatch the elements over the machines Example From the use-case to the layered architecture 2 30 Example: library management system UC Borrow a book Nom : Borrow a book Actor: primary librarian, secondary: printer Trigger : the librarian launches the borrowing function Basic flow. The librarian launches the borrowing function 2. The librarian enters the client number 3. The system displays the personal data of the customer, the list of books he already borrowed and asks for confirmation 4. The system verifies that the maximum number of borrowings is not reached 5. The librarian enters the book number 6. The system displays the detailed information on the book and asks for confirmation 7. The system records the new borrowing 8. The systems asks the printer to print the borrowing sheet 3 3

9 Borrow a book: analysis objects Analysis model BorrowingScreen CustomerInformationScreen BookInformationScreen PrinterInterface Person(DOM) Borrowing(DOM) Book(DOM) 34 Gross architecture component/reuse Component/reuse/responsibility 35 36

10 Responsable des réservations Directeur Caissier Réservation chambre Suppression réservation Check-in Changement de chambre Prolongation séjour Règlement de la note Horloge de l'hôtel Lecteur de carte magnétique Centrale de carte de crédit <<boundary>> Ecran de check in GestionnaireOccupation Validati onvi ew display(model) display(model) modele modele << co nt rol >> CheckIn display() displayva lid ati on () <<boundary>> Horloge getoccupationfomnameanddate(string) $ Singleton <<boundary>> Dialogue de demande insertion carte display(model) nom,date current Sejour <<entity>> Personne OccupationVie w display(model) <<entity>> Occupation * datedebut() datefin() person ne () chambre () display() modele modele * Reservation <<entity>> Ecran de check in occupant <<entity>> Personne nom() adresse() <<entity>> Chambre numero() <<boundary>> Interface lecteur cartes enregistre(reservation) display() Sejour CheckIn Occupation Reservation Interf ace d af f ichage des données Horloge Interf ace lecteur cartes Dialogue de demande insertion carte Chambre Dialogue de demande de v alidation Conception Concevoir les classes Image: Copyright (c) , Rational Software Corporation Image: Copyright (c) , Rational Software Corporation De l analyse à la conception Du modèle d analyse au modèle de conception Design patterns Métier Analyse Conception. Reprendre l architecture des classes d analyse 2. Transformer A. Design des boundaries Sous-systèmes / composants réutilisables B. Application des design patterns C. Etude de la persistence 3. Affiner A ffic hage Implementation Traitement client Traitement commandes Utilitaires Communication

11 Quand faire un design explicite?. Pour tout composant complexe 2. Pour tout composant réutilisable 3. Pour les développements externalisés. Contrôle qualité, vérification de conformité 4. Dans l approche MDA Toutefois Il est courant de faire du reverse-engineering en cours de développement pour conserver la vue globale Check Analysis Reverse-engineering i Double-loop process Architecture Check Implementation Design Delivery Boundary Entity Protocole DomainObject Interface user Contrôleur Device driver Protocole2 DomainObject Interface user 2 protocole() protocole2() protocole3() Protocole3 DomainObjec t Window Contrôleur DomainObject Spécialiste Spécialiste2 Device driver subsystem DomainObject Device driver Interface DomainObject Table

12 Control Associations Entity Entity2 Spécialiste2 Spécialiste responsabilité2() Entity Entity2 Contrôleur Device driver control responsabilité() responsabilité2() responsabilité3() responsabilité() responsabilité2() responsabilité3() Spécialiste3 responsabilité3() Contrôleur Entity Contrôleur Interface <<subsystem>> Device Driver Gestionaire entités * Entity Contrôleur Spécialiste