🖨️ Version PDF
La SYSTÉMIQUE a pour objet l’étude des systèmes au sens large. Elle reflète un courant de pensée de portée très générale dont l’origine est peut être la CYBERNÉTIQUE fondée par Norbert Wiener (mathématicien américain de 1894-1964) après la seconde guerre mondiale. L’informatique est une application de la cybernétique. Ainsi, la systémique est un courant TRANSDICIPLINAIRE qui s’applique aussi bien à la physique, à la biologie en passant par l’information et la communication.
Note : Le mot système est issu du grec ancien systema « ensemble organisé ». La Systémique est une méthode d’étude ou une façon de penser les sujets complexes. La Cybernétique est une modélisation des échanges par l’étude de l’information et des principes d’intéraction. (N. Wiener 1947)
Joël de Rosnay (Scientifique passionné par la théorie des Systèmes) donne une définition plutôt vague qui est la suivante :
Un système est un ensemble d’éléments en interaction dynamique organisé en fonction d’un but.
Un système est un ensemble d’éléments en interaction dynamique organisé en fonction d’un but
Jean-Louis Le Moigne (Spécialiste de la Systémique) propose une autre définition plus complète et cependant énigmatique qui ne permet pas de reconnaître un système si par hasard on en rencontrait un :
Un SYSTEME est :
QUELQUE CHOSE : n’importe quoi, identifiable
QUELQUE CHOSE
DANS autre chose : un environnement
DANS
POUR quelque chose : une finalité ou projet
POUR
QUI FAIT quelque chose : activité, fonctionnement
QUI FAIT
PAR quelque chose : une structure, une forme stable
PAR
QUI se transforme : évolution dans le temps
QUI se transforme
Dans un lointain passé, un professeur d’université m’a donné la définition suivante :
“Un système est un ensemble complexe (composé de plusieurs éléments) qui est plus que la somme de ses parties. Les composants de l’ensemble ont des choses en COMMUN qui assurent la COHÉRENCE”
Un système est un ensemble complexe (composé de plusieurs éléments) qui est plus que la somme de ses parties. Les composants de l’ensemble ont des choses en COMMUN qui assurent la COHÉRENCE
L’approche systémique doit permettre de dégager, à partir des invariants, des propriétés et du comportement des systèmes complexes, quelques règles générales destinées à mieux comprendre ces systèmes et à agir sur eux.
mieux comprendre ces systèmes et à agir sur eux
globalisante
descendante
Analyse
Modélisation
Simulation
Comme nous venons de le découvrir grâce à la Systémique, une entreprise est un système que nous allons étudier et appréhender de manière intelligente et le décomposer en SOUS-SYSTÈMES pour nous intéresser plus particulièrement au fameux SYSTÈME D’INFORMATION (SI) qui repose essentiellement sur la DESCRIPTION DES FLUX.
On peut conclure qu’une entreprise (Système) est :
Note : Il faut se souvenir qu’un SYSTÈME D’INFORMATION est plus qu’un système informatique avec lequel il ne doit pas être confondu. Rappelons que le SI d’une organisation est l’ensemble des éléments chargés de STOCKER et TRAITER les informations (ordinateurs, postes de travail, règles et méthodes).
un SYSTÈME D’INFORMATION est plus qu’un système informatique avec lequel il ne doit pas être confondu
Le bon fonctionnement d’une organisation voire sa survie est conditionné par la mise en place d’une communication cohérente et fluide entre ses différents composants et avec son environnement. L’essence de cette communication est l’INFORMATION.
Cette information n’est utile que si elle est exploitée et mise à disposition de façon OPTIMALE.
L’augmentation du volume d’informations à traiter et la complexité croissante de la communication au sein des organisations nécessitent la mise en place d’un SI.
Pour conclure :
SI est la MÉMOIRE de l’entreprise (système)
SI est une composante indissociable des organisations
UML signifie Unified Modeling Language que l’on peut traduire par Langage Unifié de Modélisation.
Il est orienté OBJET !
C’est un standard devenu incontournable, on peut le voir comme le couteau Suisse de la modélisation.
Attention, UML n’est pas une méthode !
UML est un langage PUBLIC et STANDARDISÉ par l’ OMG (Object Management Group) :
UML est un langage (on parle de notation) pour formaliser notre démarche on utiliser souvent UP (Unified Process).
UML ne fournit aucun processus de développement. Pour cela on utilise une démarche méthodologique appelée RUP (Rational Unified Process - IBM).
RUP est une base de connaissance issue de milliers de projets rassemblés durant un certain nombre d’années. Cette base est accessible via internet. Elle n’est pas traduite en Français.
Pour info, Object Management Group est association américaine dont le but est de standardiser et promouvoir le modèle objet sous toutes ses formes et Rational Unified Process est une implémentation de la méthode PU (Processus Unifié) = guidé par les besoins des utilisateurs, centrée sur l’architecture logicielle, itérative et incrémentale.
Nous allons voir que le langage UML permet de comprendre et décrire les besoins spécifier dans le cahier des charges, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir et communiquer des points de vue.
Ainsi, une réalisation conforme au Processus Unifié pour transformer les besoins des utilisateurs en logiciel doit nécessairement présenter les caractéristiques suivantes :
➢ Basée sur des composants
➢ Utilise UML
➢ pilotée par les cas d’utilisation
➢ Centrée sur l’architecture
➢ Itératif et Incrémental
Itératif : Exprime l’idée d’une répétition de l’action, “le processus de développement est appliquée plusieurs fois”.
Incrémental : Chaque itération augmente la quantité d’information.
On pourrait détailler ce processus de développement logiciel (UP) comme ceci :
Exemple de l’expression des besoins avec un cas d’utilisation :
Exemple de modélisation du système et détails des besoins avec un diagramme des classes métier
Exemple avec un diagramme de séquence “Emprunter”
Exemple de diagramme de Composants (packages : ui, service, domain, repository, integration) et collaboration avec éléments
Exemple de méthode service (Java basique) avec intégration des composants & mapping classes -> composants
public Pret emprunter(Long lecteurId, Long exemplaireId) { Exemplaire exemplaire = exRepo.findById(exemplaireId).orElseThrow(); if (!exemplaire.estDisponible()) throw new IllegalStateException("Indisponible"); Pret pret = new Pret(lecteurId, exemplaireId, today(), today().plusDays(21)); pretRepo.save(pret); exemplaire.marquerIndisponible(); exRepo.save(exemplaire); return pret; }
Objectif : valider que le système répond aux cas d’utilisation.
Exemple avec le diagramme de séquences
Exemple de Tests unitaires :
@Test void emprunt_disponible_ok() { Pret pret = service.emprunter(philippeId, livreJavaId); assertNotNull(pret.getId()); assertFalse(exRepo.findById(livreJavaId).orElseThrow().estDisponible()); }
Exemple de diagramme de déploiement :
Quoi ?
Quoi précisément ?
Comment ?
Quel code ?
Est-ce que ça marche ?
Où ça tourne ?
Les premiers objets ont été développés pour gérer les interfaces graphiques. Les suivants doivent être les objets métiers, c’est-à-dire ceux que l’entreprise manipule dans le cadre de son activité.
On peut considérer 1986 comme le début de l’époque des pionniers en ce qui concerne les méthodes OO (Orientée Objet).
UML naît le 11 novembre 1997 avec la version 1.1 standardisée par l’OMG (Object Management Group)
UML naît le 11 novembre 1997 avec la version 1.1 standardisée par l’OMG
Le résultat du tri des différents concepts proposés par les méthodes existantes (environ une cinquantaine) a permis l’Unification des méthodes de modélisation objet considérées comme les plus efficaces.
Les trois locomotives en matière de méthodes Orientées Objets sont :
Ils ont travaillé à une convergence de leurs méthodes au sein de la société américaine Rational Software.
Leurs travaux ont aboutis à la naissance d’UML (Unified Modeling Language) :
Voici un lien pour avoir un aperçu de l’évolution d’UML sur Wikipédia
Les créateurs d’UML sont arrivés à un consensus en terme de modélisation mais pas encore en temps que démarche.
Rappel sur l’Object Management Group : Organisme à but non lucratif crée en 1989 à l’initiative de grandes sociétés. Plus de 700 entreprises adhérentes (DEC, HP, IBM, Microsoft, Oracle …)
Les 8 diagrammes que nous allons décrire dans la suite du cours vont nous permettre de : REPRESENTER GRAPHIQUEMENT UN SYSTEME
REPRESENTER GRAPHIQUEMENT UN SYSTEME
Les systèmes étant des choses complexes, on utilise une simplification de la réalité : LE MODELE (réalité perçue)
LE MODELE
Qui sera représenté sous différents angles (à l’aide de nos 8 diagrammes)
Cela nous permettra de : DÉFINIR ET VISUALISER NOTRE SYSTÈME
DÉFINIR ET VISUALISER NOTRE SYSTÈME
La modélisation est une pratique indispensable servant à : REPRESENTER DE MANIERE ABSTRAITE UN SYSTÈME LOGICIEL
REPRESENTER DE MANIERE ABSTRAITE UN SYSTÈME LOGICIEL
Chaque diagramme va s’intéresser à un aspect précis du modèle.
Un diagramme possède : UNE STRUCTURE ET UNE SÉMANTIQUE
UNE STRUCTURE ET UNE SÉMANTIQUE
La combinaison des différents types de diagrammes va nous offrir une vue complète des aspects : STATIQUES ET DYNAMIQUES D’UN SYSTÈME
STATIQUES ET DYNAMIQUES D’UN SYSTÈME
Pour commencer, on identifie les acteurs (utilisateurs) et les besoins fonctionnels avec un ou plusieurs diagrammes de cas d’utilisation (les Uses Cases).
L’étape suivante consiste à détailler les différents Cas d’utilisation sous forme textuelle qui comprend un scénario qui décompose, étape par étape, les interactions entre le ou les acteurs et le Cas d’utilisation en précisant qui réalise chaque étape. On utilise fréquemment les maquettes des écrans destinés à l’utilisateur pour décrire les scénarios.
Il nous faut aussi rédiger les scénarios lorsque tout ne se passe pas comme prévu. On appelle cela les scénarios alternatifs.
On peut aussi utiliser le diagramme d’Activité pour représenter graphiquement la version textuelle du scénario.
Comme dans la méthode Merise lors de la conception d’un MCD, nous devons lister chaque concepts et en donner la définition pour éviter toute confusion lors de la modélisation. Nous allons constituer un glossaire.
On peut alors commencer le diagramme de Classes pour représenter les concepts et les relations.
Puisque l’on sait que les classes deviendront des objets, nous pouvons réaliser le ou les diagrammes de Séquences ou sous forme de tableau excel : l’objectif étant de montrer les échanges de message (méthodes) entre les différents objets de manière séquentielle.
Dans ce type de diagramme, on fait apparaitre les acteurs, les interfaces et les classes métiers. On peut faire apparaitre les classes Entity, Boundary et Control.
Si l’on souhaite davantage faire ressortir les liens entre les objets sans se soucier de l’aspect séquentiel, on peut utiliser le diagramme de Collaboration (en numérotant les différents liens).
A cette étape, on peut concevoir une solution.
Nous devons passer à la phase de développement à partir des informations que nous donnent les différents schémas réalisés lors des phases précédentes.
Les classes, interfaces et scipts de génération de tables de la bases de données peuvent être générées à partir des diagrammes de classes UML. Ainsi le squelette de l’architecture sera généré automatiquement.
Les traitements seront écrits par les développeur-euse.s…. ou pas une IA :(
Si besoin, on peut réaliser un diagramme de Déploiement pour préciser les composants et les nœuds correspondants.
Auteur : Philippe Bouget