2paradigmes - Curs 1 Part 2 - Introduction To Programming Paradigms Rev 2022 Vol 1
2paradigmes - Curs 1 Part 2 - Introduction To Programming Paradigms Rev 2022 Vol 1
2paradigmes - Curs 1 Part 2 - Introduction To Programming Paradigms Rev 2022 Vol 1
com
1
Ordre du Jour
1. Définitions
2. Ingénierie logicielle et paradigmes logiciels
3. Modèles de cycles de vie des logiciels
Construire et réparer (Build & Fix)
Cascade et cascade modifiée (Waterfall)
Prototypage rapide (Rapid Prototyping)
Spirale de Boehm (Bohem Spiral)
Agile
2
Paradigme
◦ catégorie d'entités partageant une caractéristique commune
◦ Exemples:
Économie Internet vs ère industrielle
Logiciel sous licence vs Open Source
Licence d'utilisation perpétuelle vs SaaS (logiciel en tant que service)
Data Processing Paradigm
3
Modèle pour une classe de langages de programmation partageant un ensemble de
caractéristiques communes
1. Langage de programmation
système de signes utilisé pour communiquer une tâche/un algorithme à un ordinateur, provoquant
l'exécution de la tâche
2. Calcul
La tâche à effectuer
3. Paradigme linguistique
Principes généraux utilisés par un programmeur pour communiquer une tâche/un algorithme à un
ordinateur à l'aide de deux composants :
Syntaxe - manière de spécifier ce qui est légal dans la structure de phrase de la langue
Sémantique - signification d'un programme dans cette langue
Quatre grands paradigmes de langage de programmation:
1. Impératif/procédural
2. Orienté objet
3. Logique
4. Fonctionnel
4
incarne les résultats des idées des gens sur
◦ comment construire des programmes,
◦ les combiner dans de grands systèmes logiciels et
◦ des mécanismes formels sur la manière dont ces idées doivent être
exprimées
Les phases suivantes sont impactées par le paradigme logiciel
sélectionné :
a. Modèles de conception
b. Composants
c. Architecture logicielle
d. Cadres
Ainsi, nous pouvons dire qu'un paradigme de conception logicielle est un modèle pour une classe de
problèmes qui partagent un ensemble de caractéristiques communes.
Il convient de noter en particulier qu'un paradigme de programmation particulier définit
essentiellement les paradigmes de conception de logiciels. Par exemple, on peut parler de modèles
de conception orientés objet, de composants procéduraux (modules), d'architecture logicielle
fonctionnelle, etc.
5
solution éprouvée pour un problème de conception général
◦ Modèles architecturaux : expriment une organisation ou un schéma
structurel fondamental pour les systèmes logiciels. Fournir un ensemble de
sous-systèmes prédéfinis, spécifier leurs responsabilités et inclure des
règles et des directives pour organiser les relations entre eux.
◦ Modèles de conception : fournit un schéma pour affiner les sous-systèmes
ou les composants d'un système logiciel, ou les relations entre eux
◦ Idiomes: modèle de bas niveau spécifique à un langage de
programmation. Décrit comment implémenter des aspects particuliers des
composants ou les relations entre eux en utilisant les fonctionnalités du
langage donné
Elle consiste à communiquer des « objets » personnalisés pour résoudre le problème dans un
contexte particulier.
Les modèles ont leur origine dans la programmation orientée objet où ils ont commencé comme des
collections d'objets organisés pour résoudre un problème. Il n'y a pas de relation fondamentale entre
les motifs et les objets ; il se trouve qu'ils ont commencé là. Des modèles peuvent être apparus parce
que les objets semblent si élémentaires, mais les problèmes que nous essayions de résoudre avec
eux étaient si complexes.
6
Les composants logiciels sont des unités binaires de production,
d'acquisition et de déploiement indépendants qui interagissent
pour former un programme fonctionnel
Exemples de composants : "Fenêtre", "Bouton poussoir", "Editeur
de texte", etc.
Problèmes liés aux informations sur l'interopérabilité:
◦ comment exprimer des informations d'interopérabilité (par exemple,
comment ajouter un « bouton poussoir » à une « fenêtre » ;
◦ comment publier ces informations (par exemple bibliothèque avec API
réutilisable via une instruction "include")
Un composant est une partie physique et remplaçable d'un système à qui il se conforme et fournit la
réalisation d'un ensemble d'interfaces ... représente généralement l'emballage physique d'éléments
autrement logiques, tels que des classes, des interfaces et des collaborations.
Un composant doit être compatible et interopérer avec toute une gamme d'autres composants.
Exemples de composants : "Fenêtre", "Bouton poussoir", "Editeur de texte", etc.
Deux problèmes principaux se posent en ce qui concerne les informations d'interopérabilité:
1. comment exprimer des informations d'interopérabilité (par exemple, comment ajouter un
« bouton poussoir » à une « fenêtre » ;
2. comment publier ces informations (par exemple bibliothèque avec API réutilisable via une
instruction « include »)
7
L'architecture traite de la structure des composants de la
solution
Une architecture définit les composants du système logiciel,
leur intégration et leur interopérabilité :
• L'intégration
• signifie que les pièces d’un système s'emboîtent bien
• L'interopérabilité
• signifie que plusieurs systèmes travaillent ensemble efficacement
pour produire une réponse
Une architecture logicielle particulière décompose un problème en petits morceaux et tente de trouver
une solution (composant) pour chaque morceau.
Il existe de nombreuses architectures logicielles. Choisir le bon peut être un problème difficile en soi.
Ex : client/serveur vs architecture sur 3 niveaux
Il est très important de faire la distinction entre intégration et interopérabilité!
8
Mini-architecture réutilisable qui fournit la structure et le comportement
génériques d'une famille d'abstractions logicielles
Les Cadres peuvent être vus comme un niveau intermédiaire entre les
composants et une architecture logicielle
9
Des couches d'abstraction critiques se situent entre le programme d'application et le matériel
réel. L'application est écrite pour un modèle de programmation, qui dicte la manière dont les
éléments du programme partagent les informations et coordonnent leur abstraction, qui est la
frontière entre le programme utilisateur et l'implémentation du système. Cette abstraction est
réalisée par le support du compilateur ou de la bibliothèque en utilisant des primitives
disponibles à partir du matériel ou du système d'exploitation, qui utilise des primitives
matérielles privilégiées.
10
Génie logiciel - l'établissement et l'utilisation de principes d'ingénierie solides afin
d'obtenir de manière économique un logiciel fiable et fonctionnant efficacement sur de
vraies machines
Emploie une variété de:
◦ Paradigmes - approches ou philosophies particulières pour la conception, la construction et la
maintenance de logiciels. Les phases suivantes sont fortement affectées par les paradigmes logiciels
sélectionnés :
Conception
Mise en œuvre
L'intégration
Maintenance
◦ Méthodes (techniques) - dépendaient fortement d'un paradigme sélectionné et peuvent être considérées
comme une procédure pour produire un résultat
◦ Outils - systèmes automatisés mettant en œuvre une méthode particulière
Discuter la situation actuelle du développement logiciel
La complexité et le manque de ressources ont créé une situation sans précédent dans l'industrie informatique :
2 500 milliards de dollars (environ 70 % du budget informatique mondial) sont investis de manière inefficace. En
conséquence, 1 projet sur 5 n'est pas développé et commercialisé.
• La correction de bogues dans les logiciels livrés a la tendance de produir plus de bogues
• Augmentation de la taille des systèmes logiciels
1. NASA
2. Initiative de défense StarWars
3. Administration de la sécurité sociale
4. Systèmes de transactions financières
• Changements dans le rapport entre les coûts matériels et logiciels
1. début des années 60 - 80% des coûts de matériel
2. milieu des années 60 - 40 à 50 % de coûts de logiciel
3. aujourd'hui - moins de 20 % de coûts matériels (!?)
• Rôle de plus en plus important de la maintenance
1. Correction des erreurs, modification, ajout d'options
2. Le coût est souvent le double de celui du développement du logiciel
• Progrès dans le matériel (coûts réduits)
• Progrès dans les techniques logicielles (par exemple, interaction avec l'utilisateur)
• Demandes accrues de logiciels
• Médecine, fabrication, divertissement, édition
• Demande de systèmes logiciels plus grands et plus complexes
• Avions (accidents), NASA (lancements échouées de navettes spatiales),
11
Les entreprises font face à de nombreux défis lors de la mise en œuvre de nouvelles
technologies
Certains inconvénients des systèmes d'information en fonction influent les modèles de
sélection
◦ Ne tiennent pas compte des interdépendances entre les critères et les projets candidats qui pourraient
réaliser des économies et des avantages précieux découlant de l'utilisation des TI/SI
PRE-IMPLEMENTATION POST-IMPLEMENTATION
Une mauvaise
planification et Adoption par
gestion du l’utilisateur
projet
TOP
CHALLENGES
Integration
avec Performance et
environment Disponibilité
des TI/SI
existent
La diapositive décrit les défis les plus importants auxquels les entreprises sont
confrontées lorsqu’elles veulent mettre en œuvre un projet. Avant de commencer
le projet, nous voyons une mauvaise planification du projet comme un obstacle
majeur à la réussite du projet. Le deuxième problème de pré-mise en œuvre est
la mauvaise intégration du nouveau projet avec l’infrastructure et les applications
TI/SI existantes. En supposant que ces défis aient été correctement abordés,
dans la phase post-implémentation, le plus souvent, les gestionnaires de projet
s’affrontent avec une résistance a l’adoption par l’utilisateur. Enfin, les
performances ultimes du système ainsi que la grande disponibilité sont des
facteurs qui peuvent contribuer au succès ou à l’échec du projet.
12
1. Implique les activités de production d'un système logiciel et comporte les phases suivantes:
2. Analyse des besoins et spécifications
3. Conception
◦ Conception préliminaire
◦ Conception détaillée
4. Mise en œuvre
◦ Implémentation des composants
◦ Intégration de composants
5. [Documentation du système]
6. Essai
◦ Tests unitaires
◦ Tests d'intégration
◦ Test du système
7. Déploiement
◦ Réception du projet pour d'installation et d'acceptation
8. Maintenance
◦ Rapport et correction de bogues
◦ Modification des exigences et mise à niveau du logiciel
13
Nous allons passer en revue les modèles suivants :
◦ Construire et réparer (Build & Fix)
◦ Cascade et cascade modifiée (Waterfall and Modified Waterfall)
◦ Prototypage rapide
◦ Spirale de Boehm
◦ Agile
14
• OK pour les petits systèmes simples
• Le coût de ce modèle de processus est en fait bien supérieur au coût d'un projet
correctement spécifié et conçu.
• La maintenance peut également être problématique dans un système logiciel développé
selon ce scénario.
Cela fonctionne bien pour les petits systèmes simples, mais est totalement insatisfaisant pour les
systèmes logiciels de taille appreciable. Il a été démontré empiriquement que le coût de changement
d'un produit logiciel est relativement faible si le changement est effectué lors des phases de la
définition des exigences ou de conception, mais qu'il devient important lors des phases ultérieures.
Le coût de ce modèle de processus est en fait bien supérieur au coût d'un projet correctement
spécifié et conçu. La maintenance peut également être problématique dans un système logiciel
développé selon ce scénario.
15
Le Modèle en Cascade Cascade Modifié
Le modèle en cascade est dérivé d'autres processus d'ingénierie en 1970. Offre un moyen de rendre
le processus de développement plus structuré. Exprime l'interaction entre les phases successives.
Chaque phase se transforme en cascade dans la phase suivante. Dans le modèle original en
cascade, une séquence stricte était au moins implicite. Cela signifiait qu'une phase devait être
achevée avant que la phase suivante ne commence.
Il ne prévoyait pas non plus de retour d'information entre les phases ni de mise à jour/redéfinition des
phases précédentes. Implique qu'il y a des pauses définies entre les phases, c'est-à-dire que chaque
phase a un début et une fin stricts et sans chevauchement et est effectuée de manière séquentielle.
Le point critique est qu'aucune phase n'est terminée tant que la documentation et/ou les autres
produits associés à cette phase ne sont pas terminés.
16
Le prototypage repose sur l'idée de développer une première implémentation pour
les retours des utilisateurs, puis d'affiner ce prototype à travers de nombreuses
versions jusqu'à ce qu'un système satisfaisant émerge.
• Programmation exploratoire - travaillez avec l'utilisateur pour explorer ses besoins et fournir un
système final.
• Prototypage jetable - L'objectif est de comprendre les exigences des utilisateurs et de développer
une meilleure définition des exigences pour le système
Le prototypage, aussi appelé développement évolutif, ou RAD (Rapid Application Development) vise à
améliorer la précision de la perception par le concepteur des besoins de l'utilisateur. Le prototypage repose sur
l'idée de développer une première implémentation pour les retours des utilisateurs, puis d'affiner ce prototype à
travers de nombreuses versions jusqu'à ce qu'un système satisfaisant émerge. Les activités de spécification, de
développement et de validation sont menées en parallèle avec un retour d'expérience rapide sur l'ensemble des
activités. Généralement, le prototypage se caractérise par l'utilisation de langages de très haut niveau, qui ne
seront probablement pas utilisés dans l'implémentation logicielle finale mais qui permettent un développement
rapide, et le développement d'un système avec moins de fonctionnalités par rapport aux attributs de qualité tels
que la robustesse, vitesse, etc... Le prototypage permet de clarifier les besoins des utilisateurs grâce,
notamment, au développement précoce de l'interface utilisateur. L'utilisateur peut alors essayer le système,
même s'il s'agit d'un (sous-)système de ce qui sera le produit final. Cela permet à l'utilisateur de fournir des
commentaires avant qu'un investissement important n'ait été fait dans le développement du mauvais système.
Des expériences de prototypage ont montré que cette approche prenait 40 % de temps en moins et entraînait
45 % de code en moins ; cependant, il produisait un code moins robuste et donc plus difficile à maintenir. La
documentation était souvent sacrifiée ou incomplète. Les attentes de calendrier des utilisateurs et des
gestionnaires avaient tendance à être irréalistes, en particulier en ce qui concerne les prototypes jetables.
Exemple: utilisez Oracle APEX pour le développement rapide d'applications afin de rendre vos données
rapidement et facilement disponibles via une application Web. • Créez de puissantes applications Web
multipages fonctionnelles en quelques minutes • Utilisez des rapports "interactifs" avancés prêts à l'emploi •
Intégrez les fonctionnalités javascript et AJAX avec des actions dynamiques construites par pointer-cliquer •
Créez facilement des graphiques et des diagrammes avec drill-to -fonctionnalités détaillées • Comprendre les
multiples outils en un d'APEX, y compris le développement complet SQL/PLSQL et les capacités
d'administration.
17
Boehm a proposé un modèle en spirale où chaque tour de la spirale
a. identifie le sous-problème auquel est associé le risque le plus élevé
b. trouve une solution à ce problème
18
3/3/2022
Individus et
over Processus et outils
interactions
Documentation
Logiciel fonctionel over
complète
Répondre au
over Suivre un plan
changement
Source: www.agilemanifesto.org
Mountain Goat Software,
LLC
19
Exigences
Conception
Mise en oeuvre
Essai (Testing)
Déploiement
Entretien
20
1
3/3/2022
Changements
Exigences
Conception
Mise en oeuvre
Prend trop longtemps
Essai (Testing) Ignoré
Déploiement
Redouté Entretien
21
Naturellement Chaos!
22
2
3/3/2022
Accepter la réalité.
23
24
3
3/3/2022
25
Comment?
26
4
3/3/2022
SCRUM (mêlée)
27
28
5
3/3/2022
29
Personnes
Choses
Comportements
30
6
3/3/2022
Personnes
(Acteurs)
31
32
7
3/3/2022
Propriétaire du produit
Scrum Master (Maitre de mêlé)
équipe Scrum
33
Choses
34
8
3/3/2022
35
Le Produit.
36
9
3/3/2022
37
(L'arriéré)
38
10
3/3/2022
39
40
11
3/3/2022
41
42
12
3/3/2022
Le propriétaire du produit
détient
la liste des arriérés du produit.
43
Scrum (mêlée)
Personnages Choses
Propriétaire du produit Liste des Arierés
Scrum Master Histoires
équipe Scrum Estimations
44
13
3/3/2022
Comportements
45
Changements
Exigences
Conception
Mise en oeuvre
Prend trop longtemps
Essai (Testing) Ignoré
Déploiement
Redouté Entretien
46
14
3/3/2022
Exigences
Conception Entretien
Essai (Testing)
47
48
15
3/3/2022
Pourquoi itératif?
49
50
16
3/3/2022
51
52
17
3/3/2022
Iterations = Sprints
2 - 4 semaines
53
54
18
3/3/2022
55
56
19
3/3/2022
Lors de la réunion de
planification, on s’engage à une
quantité de travail.
57
58
20
3/3/2022
59
60
21
3/3/2022
61
62
22
3/3/2022
63
1. Qu'avez-vous fait?
2. Il y a des obstacles?
3. Qu’allez vous faire jusqu’à demain?
64
23
3/3/2022
Comportements
65
66
24
3/3/2022
Sprint
• Réunion de planification
• Rétrospective
• Réunions quotidiennes
67
Pourquoi Scrum?
68
25
3/3/2022
C'est simple.
69
70
26
3/3/2022
71
72
27
3/3/2022
73
74
28
3/3/2022
75
Maintient la flexibilité.
76
29
3/3/2022
Comment on va commencer?
77
78
30
3/3/2022
79
80
31
3/3/2022
81
82
32
3/3/2022
Continuer à essayer.
83
84
33
SPRINT pour le Processus d’Adoption Cloud
P R O G R ÈS DE L ' AD O PT I O N C L O U D
Les clients sont profilés par le Consultant Cloud
(étape d'adoption, cas d'utilisation sélectionné, industrie, rôle) en 4 compartiments :
Embarquement Sélection du
scénario d'utilisation Mise en œuvre Lancement de la
production …
Les compartiments et les tâches peuvent changer en fonction des priorités du sprint (décidées toutes les 2 semaines)
L'équipe CSC (Customer Success Consultants) est divisée en plusieurs équipes scrum, 6 à 8
consultants par équipe
Chaque sprint a un certain nombre de tâches, cela peut varier en fonction des priorités du sprint.
Ils exploitent une clientèle de 2000 comptes. Les clients sont profilés en 4 catégories (buckets) selon
le stade d'adoption du Cloud :
• Embarquement
• Utiliser la sélection de cas
• La mise en œuvre
• Production
Selon la catégorie, les consultants vont entreprendre diverses activités pour faire avancer le client
dans l'entonnoir d'adoption du cloud
85
Lancement de
Embarquement Sélection du Mise en œuvre la production
(On Boarding) scénario d'utilisation (Go Live)
Implementation
1. Use Case Selection 1. 4th E-mailing campaign
1. On Boarding Brochure
Presentation (Congratulations)
2. On Boarding webinars (Users
2. Use Case selection webinars 2. Check / Discuss Renewal
and Roles, Identity Cloud 1. Implementation One to one Oppty with TSR and OLCSM
(service specific like VPN,
Service, Oracle Cloud webinars – delivered by CSC, (if applicable)
DB12c, etc)
Infrastructure) PreSales or KM 3. Hand-over Account to
3. One to one webinars –
3. One to one webinars 2. Eloqua 3nd E-mailing OLCSM
delivered by CSC, PreSales or
4. 1-st Email blast campaign campaign (Message 1,2,3, 4 – 4. Assist specific issues: Identity
KM
5. Contact Customer by Phone as needed) Domains; Data Center
1 on 1 4. 2nd E-mailing campaign relocation; Security, etc.
3. Check Use case has started
6. Check Services provisioned (Message 1, 2, 3, 4 – as implementation: progress 5. Identify Upsell, Cross-sell
vs MyAccount needed) and estimated Go-live date; opportunities together with
5. Customer call and agreement 4. Send CLM Adoption Survey; Account Team
(cloud.oracle.com)
of 1 or more Use Cases 5. Assist in specific issues: Bugs; (TSR/OC/OLCSM) if
7. Assist 1 on 1 in specific
6. Present Oracle Consulting Deployment; Connectivity; applicable
issues:
and reflect benefits for Sizing etc. 6. Internal Go Live, PR & Social
- Provisioning
implementation Media Public Go Live Tweet
- Credentials reset (User/Pass)
- Welcome E-mail (resend)
7. Send Unsolicited Offer form 7. Nano Reference
OC and engage consultant 8. Public Reference
86
86
Processus d'adoption – Compartiment – Sprint – Tâche
◦ L'équipe Cloud Success est structurée en plusieurs mêlée (Inspiré de la méthodologie Agile).
◦ Une mêlée est composée de 8 personnes dirigées par un Maitre (Scrum master).
◦ Le Maitre (Scrum master) mesure la performance de l'équipe et s'occupe des bloqueurs
◦ L'objectif de l'équipe (mêlée) est de faire progresser les clients à travers les compartiments pour
parvenir à l'adoption
◦ L'activité est organisée en cycles de 2 semaines appelés Sprints.
◦ Le mêlée (L'équipe Scrum) a établi les Tâches à exécuter dans chaque Sprint
◦ Un reunion quotidien (stand-up meeting) de 15 min donne une visibilité sur le projet sur l'avancement des
tâches et expose les bloqueurs empêchant les tâches
◦ Les bloqueurs qui ne sont pas résolus au sein de l'équipe sont remontés au manager
◦ Après l'achèvement de chaque sprint, une retrospective est organisée afin de discuter les réalisations de
la tâche, des inconvénients possibles et des leçons apprises.
87
Planification Equipe d’adoption Cloud
du Sprint
Mêlée #1 Mêlée #2 Mêlée #n
Coup d'envoi
du Sprint SPRINT (cycle de 2 semaines)
Reunion
quotidien
Task #1 Task #2 Task #3 Task #m
Compartiments client (Customer Buckets)
Retrospective
du Sprint Embarquement
Sélection du
Mise en œuvre Lancement
scénario
88
88
Pourquoi Agile et Scrum
devraient vous intéresser ?
89