|
Conception et implémentation d'une base de données dynamique et partagée de gestion clinique( Télécharger le fichier original )par Eddy MUGISHO IMANI Institut supérieur d'informatique et de gestion de Goma - Licence 2009 |
CHAPITRE II. RECHERCHE METHODOLOGIQUE ET ANALYSEDU SYSTEME EXISTANT
Une méthodologie est cet ensemble des techniques, méthodes et procédures adoptées en terminologie pour arriver au but d'une recherche.31(*)
La méthode hypothético-déductive a été choisie pour l'élaboration de ce sujet. Comme méthode scientifique elle nous a aidé à formuler des hypothèses afin d'en déduire des conséquences observables futures mais également passées permettant d'en déterminer la validité. La méthode analytique nous a aidé à diviser l'analyse du problème apparemment complexe en sous problèmes plus simples.
Comme opération, une technique recouvre tout travail fait avec une certaine méthode, en vue d'atteindre un certain résultat et comme phénomène elle est la préoccupation de l'immense majorité des hommes de notre temps de rechercher en toutes choses la méthode absolument la plus efficace.32(*) Pour le cas précis de notre travail, nous nous sommes servis de la technique documentaire dans le parcourt des différents documents mis à notre disposition par le CSMR/C et autres ouvrages de la bibliothèque ainsi que les sites Internet en rapport avec notre sujet. Et la technique d'interview libre nous a permis de poser des nombreuses questions, formulées et non formulées, aux personnes qui pouvaient détenir de l'information qui nous a aidé à modéliser le système d'information du CSRM/C.
Le système devra exiger une méthodologie prototype dans un bon ordre afin de conduire le projet et d'atteindre les objectifs établis précédemment. Le model de développent retiendra que les besoins évoluent au rythme de l'organisation. Une organisation très réactive par rapport aux besoins du marché sera plus sujette qu'une autre à une évolution rapide des besoins en cours de projet. D'autre part, des besoins définis par des utilisateurs qui ont parfois du mal à se représenter les solutions qui en découlent seront également susceptibles d'évolutions tardives.
Modéliser une application n'est pas une activité linéaire, il s'agit d'une tâche très complexe, qui nécessite une approche itérative et incrémentale, car il est plus efficace de construire et valider par étapes, ce qui est difficile à cerner et à maîtriser. Cette modélisation est centrée sur l'architecture et est guidée par la prise en compte des besoins des utilisateurs qui motivent l'existence même du système à concevoir. 2.2.2.2. MODELE DE LA TRANSFORMATION AUTOMATIQUEDans ce modèle la transformation des spécifications en code n'intervient que lorsque les spécifications sont complètement définies. DUT Définition des Spécifications besoins Réalisation Expérimentation Fig 2. Modèle de la transformation automatique
Le développement d'un logiciel est vu comme un processus graduel d'élimination de risques. A chaque itération, on refait les spécifications, la conception, l'implémentation et les tests.
Fig. 3. Processus graduel du développement d'un logiciel Les risques majeurs sont traités en priorité. Chaque itération donne lieu à un incrément et produit une nouvelle version exécutable.
Une démarche d'analyse et de conception objet est nécessaire afin de ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet dès le départ, définir les vues qui permettent de décrire tous les aspects d'un système avec des concepts objets. Il faut donc disposer d'un outil qui donne une dimension méthodologique à l'approche objet et qui va permette de mieux maîtriser sa richesse.
Elle va consister à décomposer les systèmes biologiques en niveaux d'organisation et en unités élémentaires, les plus petites et les plus simples possible. Puis à chaque niveau d'organisation, chacune de ces unités élémentaires sera étudiée en détail par une discipline spécialisée, afin de comprendre sa structure et son fonctionnement.
La principale avancée des quinze dernières années réside dans la programmation orientée objet (P.O.O.). Face à ce nouveau mode de programmation, les méthodes de modélisation classique telle que MERISE ont rapidement montré certaines limites. De très nombreuses méthodes ont également vu le jour. Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception « Orientée objet », l'Object Management Group (OMG) a eu comme objectif de définir une notation standard utilisable dans les développements informatiques basés sur l'objet. C'est ainsi qu'est apparu UML (langage de modélisation objet unifié «Unified Modified Language »), Issu du terrain et fruit d'un travail d'experts reconnus, UML favorise donc le prototypage, et c'est là une de ses forces.
Il n'est cependant pas très intéressants d'établir des liens de correspondance entre les modèles de MERISE et d'UML car les 2 modèles ne sont pas réalisés avec les mêmes objectifs et n'utilisent pas toujours les mêmes concepts. MERISE permet de modéliser le métier de l'entreprise indépendamment des techniques, aux niveaux conceptuel et organisationnel. Le système informatique est un sous-ensemble du système d'information. Les modèles sont progressivement élaborés et enrichis, et constituent des supports de communication et de participation pour les utilisateurs. UML présente des caractéristiques voisines. Les modèles basés sur un nombre déterminé de diagrammes en fonction de la vue sont progressivement enrichis. Mais UML reste incontournable si l'entreprise veut utiliser les techniques objets.
A. Cycle de vie Le cycle de développement sous-jacent est itératif et incrémental, guidé par les cas d'utilisation et centré sur l'architecture. B. Cycle d'abstraction Laisse le soin de présenter les diagrammes cohérents qui contiennent des objets de même niveau de préoccupation et modélise le système aux différents niveaux d'abstraction. C. Cycle de décision Il concerne les différentes décisions et choix qui sont effectués tout au long du cycle de vie, et permet de faire valider petit à petit le système que l'on est en train de construire en se souciant d'associer étroitement les utilisateurs dans les tâches d'analyse et de conception (notamment au niveau des cas d'utilisation).
A. Acteur Il représente un rôle joué par une personne ou une chose qui interagit avec le système. La même personne physique peut donc être représentée par plusieurs acteurs en fonction des rôles qu'elle joue. Plusieurs personnes jouant le même rôle vis-à-vis du système, sont représentées par un seul acteur. B. Attribut Il représente la modélisation d'une information élémentaire représentée par son nom et son format. C. Association Elle est la plus courante et la plus riche du point de vue sémantique qu'une relation. Une association est une relation statique n-aire (le plus souvent : elle est binaire), c'est-à-dire qu'elle relie plusieurs classes entre elles. D. Classe Elle correspond à un concept global d'information et se compose d'un ensemble d'informations élémentaires, appelées attributs de classe. Les classes sont représentées par des rectangles compartimentés; le premier compartiment représente le nom de la classe, le deuxième compartiment représente les attributs de la classe et le troisième compartiment représente les opérations de la classe.
E. Messages Elles sont le seul moyen de communication entre les objets. Ils sont décrits essentiellement par l'objet émetteur et l'objet récepteur. F. Multiplicité Elle définit le nombre d'instances de l'association pour une instance de la classe. La multiplicité est définie par un nombre entier ou un intervalle de valeurs. La multiplicité est notée sur le rôle (elle est notée à l'envers de la notation MERISE). Elle est représentée sous la forme d'un couple de cardinalités.
G. Noeud Elle représente au diagramme de déploiement un cube dont le nom respecte la syntaxe des noms de classes. Les noeuds peuvent être associés comme des classes et on peut spécifier des multiplicités. H. Opération Elle comprend l'ensemble des activités que le domaine peut effectuer à partir des informations fournies par l'événement, et de celles déjà connues dans la mémoire du système d'information. I. Propriété Elle est la modélisation de l'information élémentaire. C'est un ensemble de données ayant la même structure et représentant des informations analogues. La modélisation des propriétés doit éviter les synonymes et les polysémies. Les attributs et les opérations sont les propriétés d'une classe. Leur nom commence par une minuscule. J. Relation Elle existe entre classes pour former les liens entre leurs objets. K. Synchronisation Elle est une condition préalable au démarrage d'une opération. Elle se traduit par une opération logique.
Il décrit les grandes fonctions d'un système du point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation, modélise à QUOI sert le système. C'est à ce niveau qu'on assimile les fonctionnalités demandées par le client, en montrant ce qu'on attend du système. Cependant dans le cadre de notre travail, ce diagramme va nous monter les différentes personnes et choses qui vont devoir interagir par leurs informations échangées au sein du système du CSMR/C.
Il est au coeur de la conception d'un système, permet de spécifier la structure et les liens entre les objets dont le système est composé. Il spécifie QUI sera à l'oeuvre dans le système pour réaliser les fonctionnalités décrites par les diagrammes de cas d'utilisation. Le diagramme de classes modélise des règles. Dans ce travail les différentes classes vont montrer les différentes entités qui gèrent et gardent l'information pour qu'elle soit cohérente et fluide.
Il montre toute la dynamique du système. Le diagramme d'activité offre une manière graphique et non ambiguë pour modéliser les traitements où une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles. Le passage d'une activité à l'autre est matérialisé par une transition. Dans le présent travail, ce diagramme va nous montrer, de l'arrivé à la sortie du centre de santé, les différents processus qu'un patient doit devoir franchir.
Elle aide à comprendre comment les éléments du système interagissent entre eux et avec les acteurs en s'échangent des messages. En outre, il montre des interactions sous un angle temporel en mettant l'emphase sur le séquencement temporel. Les séquences pour le cas du CSMR/C montrent les différents postes de travails et surtout les informations qui y sont échangées.
Elle montre la disposition physique des différentes ressources matérielles (l'architecture du système) qui entrent dans la composition d'un système et la répartition des instances de composants, processus et objets qui « vivent » sur ces matériels. Dans le cadre de notre travail elle nous prépare à l'implémentation de l'architecture technologique du système à mettre en place.
Elle montre la technologie physique et les équipements utilisés sur le réseau local créé. Nous trouvons les différents postes qui pourront communiquer ensemble et se comprendre par un dialogue avec un protocole commun. Cette technologie est composée des matériels puissants et récents pour supporter la gestion de la base de données. A cette technologie il faudra y alloué les utilisateurs qualifiés ou formés. Son succès s'explique facilement de part les nombreux avantages dont il disposera : outre le réseau sera le plus évolutif puisque nous pourrons rajouter des composants à l'infini, modifier l'architecture du réseau comme bon nous semblera ou encore ajouter un ou plusieurs PC sans changer les paramètres des PC déjà reliés. Nous pourrons de plus relier nos PC les plus éloignés par un concentrateur.
Il est l'ensemble des schémas et des règles de passage entre les schémas associés à une base de données, combinés à une description de la signification des données. Pour ce travail il nous a permis de quitter le model existant pour passer à la conception du model future en passant par l'étape de la validation et de délimitation du système à modéliser. Notre existant diffère du futur par le fait qu'à part le Personnel Soignant nous ne nous sommes plus intéressés du reste du Personnel.
* 31 http://www.btb.gc.ca/btb.php?lang=fra&cont=700, visité le 28/09/2010 à 15h20 * 32 http://agora.qc.ca/dossiers/Technique. visité le 28/09/2010 à 15h25 |
|
