Dépendances entre classes (objets)

Chaque objet est associé à une structure de données dont les champs sont les attributs de cet objet et des pointeurs vers des fonctions (fragments de code) qui implémentent les opérations de cet objet (notez que les pointeurs de fonction, suite à l'optimisation du code, sont généralement remplacés par des appels à ces fonctions). Ainsi, un objet est une structure de données dont le type correspond à la classe de cet objet.

Vous pouvez installer entre les objets dépendances selon. Ces dépendances exprimer communications ou relation entre les classes d'objets spécifiés. Des exemples de telles dépendances sont présentés dans la figure 2.6 (les deux premières dépendances sont binaires, la troisième est trénaire). La dépendance est représentée par une ligne reliant les classes au-dessus de laquelle est écrit le nom de cette dépendance, ou les rôles des objets (classes) dans cette dépendance sont indiqués (indiquer les rôles est le moyen le plus pratique d'identifier la dépendance).

Riz. 2.6. Dépendances entre classes

Les dépendances entre classes sont bidirectionnelles : toutes les classes de la dépendance ont des droits égaux. Cela est vrai même dans les cas où le nom de la dépendance semble introduire une direction dans la dépendance. Ainsi, dans le premier exemple de la figure 2.6, le nom de la dépendance has_capital suggère que la dépendance est dirigée de la classe country vers la classe city (la nature bidirectionnelle de la dépendance semble avoir disparu) ; mais il ne faut pas oublier que cette dépendance est à double sens, en ce sens qu'en même temps la dépendance inverse est celle du capital. De la même manière, dans le deuxième exemple de la figure 2.6, on peut considérer la paire de dépendances appartenant au propriétaire. De tels malentendus peuvent être évités si les dépendances sont identifiées non pas par des noms, mais par les noms des rôles des classes qui composent la dépendance.

Dans les langages de programmation, les dépendances entre classes (objets) sont généralement implémentées à l'aide de références (pointeurs) d'une classe (objet) à une autre. Représenter les dépendances à l'aide de références révèle le fait qu'une dépendance est une propriété d'une paire de classes et non de l'une d'elles, c'est-à-dire La dépendance est une relation. Notez que bien que les dépendances entre objets soient bidirectionnelles, elles n'ont pas besoin d'être implémentées dans les programmes comme bidirectionnelles, laissant les références uniquement dans les classes où cela est nécessaire pour le programme.

D'autres exemples de dépendances entre classes sont présentés dans la figure 2.7. Le premier exemple montre la relation entre un client d'une banque et ses comptes. Un client d'une banque peut avoir plusieurs comptes dans cette banque en même temps, ou ne pas avoir de compte du tout (lorsqu'il devient pour la première fois client de la banque). Ainsi, il est nécessaire de décrire la relation entre le client et plusieurs comptes, ce qui est réalisé dans la figure 2.7. Le deuxième exemple montre la relation entre les lignes courbes (en particulier droites) qui se croisent. Vous pouvez envisager 2, 3 lignes de ce type ou plus, et elles peuvent avoir plusieurs points d'intersection. Enfin, le troisième exemple montre une dépendance facultative : l'ordinateur peut avoir ou non une souris.

Les dépendances entre classes correspondent aux dépendances entre objets de ces classes. La figure 2.8 montre les dépendances entre objets pour le premier exemple de la figure 2.6 ; La figure 2.9 montre les dépendances entre les objets pour les exemples présentés dans la figure 2.7.

Riz. 2.7. Autres exemples de dépendances. Désignations

Riz. 2.8. Dépendances entre objets

Notez que lorsque nous décrivons les dépendances entre des objets, nous connaissons généralement le nombre d'objets et n'avons pas besoin de désignations telles que « plusieurs », « deux ou plus », « pas nécessairement ».

Lors de la conception d'un système, il est plus pratique d'opérer non pas avec des objets, mais avec des classes.

Riz. 2.9. Dépendances plus complexes entre objets

Le concept de dépendance a été transféré à la technologie de conception orientée objet systèmes logiciels de la technologie de conception (et de modélisation) de bases de données, où les dépendances sont utilisées depuis longtemps. En règle générale, les langages de programmation ne prennent pas en charge la description explicite des dépendances. Cependant, décrire les dépendances est très utile lors du développement de systèmes logiciels. La technologie OMT utilise des dépendances pour interpréter les diagrammes qui décrivent un système.

Nous disposons désormais de tous les concepts nécessaires pour décrire le processus de construction. modèle objet. Ce processus comprend les étapes suivantes :

• définir des objets et des classes ;
• préparer un dictionnaire de données ;
• déterminer les dépendances entre les objets ;
• définir les attributs et les relations des objets ;
• organiser et simplifier les classes lors de l'utilisation de l'héritage ;
• poursuite des recherches et amélioration du modèle.

Système d'application représente un ensemble d’objets interdépendants. Chaque objet est caractérisé par un ensemble de propriétés dont les valeurs déterminent l'état de l'objet, et un ensemble d'opérations pouvant être appliquées à cet objet.

Lors du développement de systèmes d'application, il est pratique de supposer que toutes les propriétés des objets sont privées (c'est-à-dire qu'elles ne sont pas accessibles en dehors de l'objet). Les opérations sur les objets peuvent être publiques ou privées.

Ainsi, chaque objet possède une interface strictement définie, c'est-à-dire un ensemble d'opérations publiques pouvant être appliquées à cet objet. Tous les objets d'une même classe ont la même interface.

Le modèle objet représente la structure statistique du système conçu (sous-système). Cependant, la connaissance de la structure statique ne suffit pas pour comprendre et évaluer le sous-système robotique. Il est nécessaire de disposer de moyens pour décrire les changements qui se produisent avec les objets et leurs connexions lors du fonctionnement du sous-système.

L'un de ces moyens est modèle dynamique sous-systèmes. Il est construit une fois que le modèle objet du sous-système a été construit et préalablement convenu et débogué. Le modèle dynamique d'un sous-système se compose de diagrammes d'état de ses objets de sous-système.

L'état actuel d'un objet est caractérisé par un ensemble de valeurs actuelles de ses attributs et relations. Pendant le fonctionnement du système, ses objets constitutifs interagissent les uns avec les autres, ce qui entraîne un changement d'état. L'unité d'influence est événement: chaque événement entraîne un changement d'état d'un ou plusieurs objets du système, ou l'apparition de nouveaux événements. Le fonctionnement d'un système est caractérisé par la séquence d'événements qui s'y produisent.

Un événement se produit à un moment donné. Exemples d'événements : lancement de fusée, départ de la course de 100 m, début du câblage, remise d'argent, etc. L'événement n'a pas de durée (plus précisément, il prend un temps négligeable).

Si les événements n’ont pas de relation causale (c’est-à-dire qu’ils sont logiquement indépendants), ils sont appelés indépendant(concurrent). De tels événements ne s’influencent pas mutuellement. Il ne sert à rien d’ordonner des événements indépendants, puisqu’ils peuvent se produire dans n’importe quel ordre. Modèle système distribué doit nécessairement contenir des événements et des activités indépendants.

La séquence d'événements s'appelle un script. Une fois les scénarios développés et analysés, les objets qui génèrent et reçoivent chaque événement de scénario sont déterminés.

Lorsqu'un événement se produit, non seulement l'objet passe à un nouvel état, mais l'action associée à cet événement est également exécutée. Une action est une opération instantanée associée à un événement.

Le processus de création d'un modèle objet comprend les étapes suivantes :

Définition des objets et des classes ;

Préparation du dictionnaire de données :

Déterminer les dépendances entre les objets ;

Déterminer les propriétés des objets et des connexions ;

Organiser et simplifier les classes lors de l'utilisation de l'héritage ;

Poursuite des recherches et amélioration du modèle.

Lors de la création d’un projet logiciel, la première (et la plus importante) étape est toujours la conception. Dans toute discipline d'ingénierie, la conception fait généralement référence à une sorte d'approche unifiée par laquelle nous recherchons des moyens de résoudre un problème spécifique, garantissant ainsi que la tâche est accomplie. Derrière l'hypothèse de Stroustrup : "Le but du design est d'identifier une structure interne claire et relativement simple, parfois appelée architecture... Le design est le produit final du processus de conception." Les produits de conception sont des modèles qui nous permettent de comprendre la structure du futur système, d'équilibrer les exigences et de définir un schéma de mise en œuvre.

La modélisation est répandue dans toutes les disciplines de l'ingénierie, en grande partie parce qu'elle met en œuvre les principes de décomposition, d'abstraction et de hiérarchie. Chaque modèle décrit une certaine part système considéré, et nous, à notre tour, construisons de nouveaux modèles basés sur les anciens, dans lesquels nous avons plus ou moins confiance. Les modèles nous permettent de contrôler nos échecs. Nous évaluons le comportement de chaque modèle dans des situations normales et inhabituelles, puis procédons aux ajustements appropriés si nous ne sommes pas satisfaits de quelque chose.

La technologie orientée objet est basée sur ce que l'on appelle le modèle objet. Ses grands principes sont : l'abstraction, l'encapsulation, la modularité, la hiérarchie, le typage, le parallélisme et la persistance. Chacun de ces principes n’est en réalité pas nouveau, mais dans le modèle objet, ils sont appliqués ensemble pour la première fois. Les quatre premiers concepts sont obligatoires, étant entendu que sans chacun d'eux, le modèle ne sera pas orienté objet. D'autres sont facultatifs, ce qui signifie qu'ils sont utiles dans le modèle objet, mais pas obligatoires.

Avantages du modèle objet

Le modèle objet est fondamentalement différent des modèles associés aux méthodes plus traditionnelles d'analyse structurelle, de conception et de programmation. Cela ne signifie pas que le modèle objet nécessite l'abandon de toutes les méthodes et techniques précédemment trouvées et éprouvées. Au contraire, il introduit de nouveaux éléments qui s’ajoutent à l’expérience précédente. L'approche objet offre un certain nombre de commodités importantes qui n'étaient pas fournies par d'autres modèles. Plus important encore, l'approche basée sur les objets vous permet de créer des systèmes qui satisfont aux caractéristiques de systèmes complexes bien structurés. Le modèle objet offre cinq autres avantages.

1. Le modèle objet vous permet d'utiliser pleinement les capacités expressives de la programmation objet et orientée objet. Stroustrup note : « Il n'est pas toujours évident de savoir comment tirer pleinement parti d'un langage tel que C++. Des améliorations significatives en termes d'efficacité et de qualité du code peuvent être obtenues simplement en utilisant C++ comme un « C amélioré » avec des éléments d'abstraction de données. une avancée significative est l'introduction de la hiérarchie des classes dans le processus de conception. C'est ce qu'on appelle la conception orientée objet et c'est là que les avantages du C++ sont démontrés. la meilleure façon"L'expérience a montré que lorsque des langages tels que Smalltalk, Object Pascal, C++, CLOS et Ada sont utilisés en dehors du modèle objet, leurs fonctionnalités les plus fortes sont soit ignorées, soit mal appliquées.
2. L'utilisation d'une approche basée sur les objets augmente considérablement le niveau d'unification du développement et l'adéquation à réutilisation non seulement des programmes, mais aussi des projets, ce qui conduit finalement à la création d'un environnement de développement. Les systèmes orientés objet sont souvent plus compacts que leurs équivalents non orientés objet. Et cela signifie non seulement une réduction du volume de code du programme, mais aussi une réduction du coût du projet, grâce à l'utilisation des développements antérieurs, ce qui donne un gain de coût et de temps.
3. L'utilisation d'un modèle objet conduit à la construction de systèmes basés sur des descriptions intermédiaires stables, ce qui simplifie le processus de modification. Cela donne au système la possibilité de se développer progressivement et ne conduit pas à sa refonte complète même en cas de changements significatifs dans les exigences initiales.
4. Le modèle objet réduit le risque de développer des systèmes complexes, principalement parce que le processus d'intégration s'étend sur toute la période de développement plutôt que de devenir un événement ponctuel. L'approche objet consiste en une série d'étapes de conception bien pensées, qui réduit également le degré de risque et augmente la confiance dans l'exactitude des décisions prises.
5. Le modèle objet est orienté vers la perception humaine du monde ou, selon les mots de Robson : « De nombreuses personnes qui n'ont aucune idée du fonctionnement d'un ordinateur trouvent l'approche orientée objet des systèmes tout à fait naturelle. »

Envoyer votre bon travail dans la base de connaissances est simple. Utilisez le formulaire ci-dessous

Les étudiants, étudiants diplômés, jeunes scientifiques qui utilisent la base de connaissances dans leurs études et leur travail vous en seront très reconnaissants.

Publié sur http://www.allbest.ru/

INTRODUCTION

1.1 Principes théoriques de base de la technologie de programmation orientée objet ; Concepts de base de l'approche orientée objet

1.2 Objet conceptuel

2. construction d'un modèle objet du domaine « organisation des processus des clubs sportifs » en utilisant le langage de modélisation UML

2.1 Caractéristiques du langage de modélisation UML

2.1.1 Bref historique d'UML

2.1.2 Langage UML

2.1.3 Vocabulaire UML

2.1.4 Vue de contrôle du modèle.

3.1 Description de la structure de la candidature

CONCLUSION

LISTE DES SOURCES

Annexe A

INTRODUCTION

Le club sportif réalise des activités complètes pour développer la culture physique et le sport auprès des jeunes et des membres de leurs familles. De plus en plus de clubs sportifs apparaissent, comprenant de nombreuses sections sportives. Le processus d'inscription des jeunes impliqués dans ces sections prend beaucoup de temps et constitue un processus complexe. Par conséquent, la question de l’automatisation de ce processus devient de plus en plus pertinente.

Lors de l'utilisation d'un ordinateur, ce processus devient beaucoup plus précis et plus rapide, dépourvu de nombreuses complications résultant de son organisation manuelle.

Les caractéristiques de l'organisation des processus des clubs sportifs sont identifiées à l'aide d'un modèle objet du domaine. De tels modèles sont particulièrement utiles pour organiser le processus de comptabilité des jeunes impliqués dans les sections des clubs sportifs, puisque la modélisation de ce domaine permet d'examiner l'objet sous toutes les coutures et, grâce à cela, de prévoir tous les problèmes possibles. Par exemple, lors de la création d'un planning, le modèle objet de l'organisation processus éducatif permet d'éviter les chevauchements qui surviennent lors de la répartition des horaires par sections, puisque ce point sera prévu lors du développement.

Un modèle objet d'un domaine peut être construit à l'aide du langage de modélisation d'objet visuel UML ou en tant que produit logiciel dans un langage de programmation prenant en charge la technologie de programmation objet, dont un exemple est le langage Object Pascal.

Le but de cette recherche est d'étudier la méthodologie orientée objet et la technologie de programmation en utilisant l'exemple du langage Objet Pascal, des méthodes et des outils pour construire des modèles objets de domaines, et en appliquant les connaissances acquises pour construire un modèle objet du domaine " Organisation du travail d’un club sportif.

Pour atteindre l'objectif de cette étude, les tâches suivantes ont été définies :

· Étudier les principes théoriques de base de la méthodologie orientée objet ;

· Considérer le langage UML et construire un modèle objet du domaine en utilisant ce langage ;

· Développer une application qui utilise un ensemble de classes pour représenter des informations sur les athlètes.

L'objet d'étude de ce cours est la méthodologie de conception orientée objet.

Le sujet de cette étude est le modèle objet du domaine « Organisation du travail d'un club sportif » et ses principales propriétés.

L'hypothèse de recherche est que la mise en œuvre d'un modèle objet dans l'environnement de développement visuel Delphi, en utilisant les principes de base de la méthodologie orientée objet, simplifiera le processus de collecte, de stockage et de traitement des informations sur les participants d'un club sportif.

Au stade de l'analyse du domaine et de la conception de la structure de l'application, il est nécessaire de construire un diagramme de classes UML.

Dans le processus de rédaction du projet de cours, les méthodes de recherche suivantes ont été utilisées :

· La méthode descriptive permet de présenter les aspects théoriques du problème et de caractériser brièvement l'objet d'étude ;

· Méthode de comparaison et d'analyse. Permet de comparer différents points de vue sur le sujet considéré et de diagnostiquer l'objet d'étude ;

· Approche systémique. Il a été utilisé pour résumer les résultats obtenus et identifier leur relation logique.

1. DISPOSITIONS THÉORIQUES DE BASE DE LA MÉTHODOLOGIE ORIENTÉE OBJET

1.1 Concepts de base de l'approche orientée objet

modèle de programmation en langage sujet

Pendant longtemps, la programmation a utilisé un modèle structuré et orienté procédure. La sélection des objectifs du projet s'effectue selon l'une des deux approches, dite « top-down » et, par conséquent, « bottom-up »

1. L'approche « descendante » implique que la tâche est divisée en sous-tâches, elles-mêmes divisées en sous-tâches du niveau suivant, etc. Ce processus, appelé décomposition, se poursuit jusqu'à ce que la simplification des sous-tâches soit réduite à des fonctions élémentaires formalisables.

2. L'approche « ascendante » implique que les procédures sont écrites pour résoudre des problèmes simples, puis elles sont successivement combinées en procédures plus complexes jusqu'à ce que l'effet souhaité soit obtenu.

Les concepts de programmation importants sont la programmation orientée procédures et la programmation orientée objet.

La programmation orientée procédure est une programmation dans un langage impératif, dans lequel des instructions exécutées séquentiellement peuvent être assemblées en sous-programmes, c'est-à-dire des unités intégrales de code plus grandes, en utilisant les mécanismes du langage lui-même.

La programmation orientée objet (POO) est un style de programmation qui capture le comportement du monde réel de manière à masquer les détails de son implémentation.

Un objet est une entité distincte qui se distingue des autres entités en raison de ses propriétés, de son comportement et de son interaction avec d'autres objets d'application.

L'utilisation de cette technologie permet de représenter la structure d'un programme sous la forme d'un ensemble d'objets interagissant entre eux. À la suite d'une telle interaction, réalisée en passant des messages entre objets, les fonctions spécifiées du programme sont implémentées. Après avoir reçu un message, un objet peut effectuer une action spécifique, appelée méthode.

Il existe deux différences importantes entre la POO et la programmation orientée procédures :

1. En POO, le programmeur sélectionne d'abord les classes dans la description du domaine, puis construit un modèle objet pour résoudre le problème, et seulement après cela, il procède à l'analyse de leurs méthodes et propriétés.

2. Les méthodes et propriétés sont associées à une classe destinée à effectuer les opérations correspondantes.

Si nous analysons comment une personne résout divers problèmes pratiques dans le monde qui l'entoure, nous pouvons alors comprendre que ce monde est également orienté objet. Par exemple, pour se rendre au travail, une personne interagit généralement avec un objet tel qu'un véhicule. Le véhicule, à son tour, est constitué d'objets qui, interagissant les uns avec les autres, le mettent en mouvement, grâce auquel une personne réalise sa tâche - arriver au point souhaité. Dans le même temps, ni le conducteur ni le passager n’ont besoin de savoir comment les objets qui composent le véhicule interagissent.

Dans la programmation orientée objet, comme dans le monde réel, les utilisateurs de programmes sont isolés de la logique nécessaire à l'exécution des tâches. Par exemple, pour imprimer une page dans un traitement de texte, l'utilisateur appelle une certaine fonction en cliquant sur un bouton de la barre d'outils, mais ne voit pas les processus internes se produire. Lors de l'impression d'une page pendant l'exécution du programme, une interaction complexe d'objets se produit, qui, à leur tour, interagissent avec l'imprimante.

Lors de la création d'un programme orienté objet, le domaine est représenté comme un ensemble d'objets combinés en classes. L'exécution du programme consiste en des objets échangeant des messages (interagissant les uns avec les autres). Lors de la représentation d'un objet réel appartenant à un domaine à l'aide d'une classe de programme, il est nécessaire de mettre en évidence ses caractéristiques essentielles dans un objet réel et d'ignorer de nombreuses autres propriétés, en se limitant uniquement à celles qui sont nécessaires pour résoudre un problème pratique. Cette technique s'appelle l'abstraction.

L'abstraction est l'identification des caractéristiques essentielles d'un objet qui le distinguent des autres objets. De plus, la liste des propriétés essentielles dépend des objectifs de la modélisation et peut être complètement différente selon les tâches. Par exemple, l'objet « rat » du point de vue d'un biologiste des migrations, d'un vétérinaire ou d'un chef cuisinier aura des caractéristiques complètement différentes.

Une classe est un ensemble d’objets ayant des propriétés et un comportement communs. Ainsi, une classe peut être définie comme une certaine communauté d’objets spécifiques, comme une description de ce qu’ils devraient être et de ce qu’ils devraient faire. Si les objets existent réellement dans les applications, alors une classe est une abstraction qui regroupe les objets en un seul groupe en fonction de leurs propriétés et de leur comportement dans l'environnement dans lequel ils existent et interagissent. Par exemple, Button1 sur un formulaire, avec toutes ses propriétés et actions spécifiques, est un objet de la classe Button.

Le comportement est une caractéristique de la façon dont un objet affecte d'autres objets ou se modifie sous leur influence. Le comportement affecte la manière dont les états d'un objet changent.

La technologie de programmation orientée objet repose sur « trois piliers » : l’encapsulation, l’héritage et le polymorphisme.

L'encapsulation est la propriété de combiner l'état et le comportement au sein d'une même structure, et de masquer la structure interne d'un objet et les détails d'implémentation (du mot « capsule »). Une propriété importante de tout objet est son isolement. Détails d'implémentation de l'objet, c'est-à-dire les structures de données internes et les algorithmes permettant de les traiter sont cachés à l'utilisateur de l'objet et inaccessibles aux modifications involontaires. L'objet est utilisé via une interface - un ensemble de règles d'accès. Par exemple, pour changer de programme télévisé, il suffit de composer son numéro sur la télécommande, ce qui lancera un mécanisme complexe qui mènera finalement au résultat souhaité. Nous n'avons pas nécessairement besoin de savoir ce qui se passe dans la télécommande et dans le téléviseur, nous avons juste besoin de savoir que le téléviseur a cette capacité (méthode) et comment elle peut être activée. L'encapsulation, ou masquage de l'implémentation, est une propriété fondamentale de la POO. Il vous permet de créer des objets personnalisés dotés des méthodes requises, puis d'opérer avec eux sans entrer dans la structure de ces objets. Ainsi, l'encapsulation est un mécanisme qui combine des données et des méthodes de traitement (manipulation) de ces données et protège les deux contre les interférences externes ou les utilisations abusives. L'encapsulation du code dans une classe garantit que le code ne peut pas être « cassé » par un changement dans les détails d'implémentation de classes individuelles. Vous pouvez donc utiliser un objet dans un autre environnement, et être sûr qu'il ne corrompra pas les zones de mémoire qui ne lui appartiennent pas. Si vous devez encore modifier ou ajouter quelque chose dans la classe, les mécanismes d'héritage et de polymorphisme sont utilisés.

L'héritage est la capacité hiérarchique des classes à incorporer les propriétés et le comportement des classes ancêtres et à leur ajouter leurs propres comportements et propriétés. Chaque année, de nombreux programmes sont écrits dans le monde et il est important d'utiliser du code déjà écrit. L'avantage de la programmation orientée objet est qu'il est possible de définir des descendants pour un objet qui corrigent ou complètent son comportement. Dans ce cas, il n'est pas nécessaire non seulement de répéter le code source de l'objet parent, mais même d'y avoir accès. Cela facilite la modification d'un programme et la création de nouveaux programmes basés sur un programme existant. Ce n'est que par héritage que vous pouvez utiliser des objets dont le code source n'est pas disponible, mais auxquels vous devez apporter des modifications. Ainsi, lors de l'héritage, vous pouvez non seulement ajouter de nouvelles fonctionnalités, mais également modifier celles existantes. Et cela est largement réalisé grâce au polymorphisme.

Polymorphisme (« plusieurs formes ») - la capacité d'utiliser les mêmes expressions pour désigner différentes opérations, la capacité des classes descendantes à implémenter la méthode décrite pour la classe ancêtre de différentes manières, c'est-à-dire la possibilité d'exécuter pendant l'exécution du programme en utilisant le même nom différentes actions ou accéder à des objets différents types. Le polymorphisme est implémenté via le remplacement de méthode dans les classes descendantes (la méthode a le même nom et les mêmes paramètres, mais fonctionne différemment) - il s'agit d'un mécanisme méthodes virtuelles via une liaison dynamique. Le polymorphisme est également implémenté sous forme de « surcharge » de méthodes (une méthode a le même nom et des paramètres différents) - par exemple, en utilisant le signe + pour indiquer l'addition dans une classe réelle ou entière et une classe de chaîne : des messages similaires donnent des résultats complètement différents. Le polymorphisme offre la possibilité d'abstraire des propriétés communes.

La modularité est une propriété d'un système décomposé en modules intérieurement cohérents mais faiblement interconnectés.
Lors du processus de division d’un système en modules, deux règles peuvent être utiles. Premièrement, parce que les modules servent de blocs de programme élémentaires et indivisibles pouvant être réutilisés dans tout le système, la répartition des classes et des objets entre les modules doit en tenir compte. Deuxièmement, de nombreux compilateurs créent un segment de code distinct pour chaque module. Par conséquent, il peut y avoir des restrictions sur la taille des modules. La dynamique des appels de sous-programmes et la disposition des déclarations au sein des modules peuvent grandement affecter la localité de référence et la gestion des pages de mémoire virtuelle. Lorsque les procédures sont mal modularisées, les appels mutuels entre segments deviennent plus fréquents, ce qui entraîne une perte d'efficacité du cache et des changements de page fréquents.

Il est assez difficile de réunir des exigences aussi contradictoires, mais l'essentiel est de comprendre que l'isolement des classes et des objets dans un projet et l'organisation d'une structure modulaire sont des actions indépendantes. Le processus d'isolation des classes et des objets fait partie du processus de conception logique d'un système, et la division en modules est une étape de la conception physique. Bien entendu, il est parfois impossible de terminer la conception logique d’un système sans terminer la conception physique, et vice versa. Ces deux processus sont effectués de manière itérative.

La saisie est un moyen de se protéger contre l'utilisation d'objets d'une classe au lieu d'une autre, ou du moins de contrôler une telle utilisation.

Le parallélisme est une propriété qui distingue les objets actifs des objets passifs.

La persistance est la capacité d'un objet à exister dans le temps, en survivant au processus qui lui a donné naissance, et (ou) dans l'espace, en s'éloignant de son espace d'adressage d'origine.

Les concepts de base de la POO ont été transférés à la programmation à partir d'autres domaines de la connaissance, tels que la philosophie, la logique, les mathématiques et la sémiotique, sans subir de changements particuliers, du moins en ce qui concerne l'essence de ces concepts. La méthode objet de décomposition (représentation) est naturelle et est utilisée depuis de nombreux siècles. Il n’est donc pas surprenant qu’elle ait pris la place qui lui revient dans le processus d’évolution de la technologie de programmation.

Ainsi, dans le processus de développement de programmes orientés objet, il est nécessaire :

1. déterminer l'ensemble des classes d'objets qui le composent (décomposition) ;

2. pour chaque classe d'objets, préciser un ensemble de données nécessaires (champs) ;

3. pour chaque classe d'objets, spécifier un ensemble d'actions (méthodes) effectuées par les objets ;

4. pour chaque classe d'objets, spécifier les événements auxquels les objets réagiront et écrire les procédures de gestion correspondantes.

Le code source doit contenir des descriptions de classe pour tous les objets logiciels. De plus, il faut décrire des variables dont les types sont les noms des classes correspondantes. Des instances de classes (objets) sont créées lors de l'exécution du programme.

Après sa création, une instance d'une classe doit recevoir des valeurs pour tous ses champs. Différentes instances de la même classe peuvent avoir des valeurs de champ différentes, mais avoir les mêmes méthodes. Les champs de classe ne sont pas disponibles pour un accès direct, y compris l'affectation. Ceci est fait pour augmenter la fiabilité des programmes. Au lieu d'attribuer directement une valeur à un champ d'objet, il faut appeler une méthode spéciale de la classe correspondante, qui effectue une telle affectation et surveille l'exactitude de la valeur saisie. De même, des méthodes de classe spéciales peuvent également être utilisées pour lire la valeur d'un champ. Pour connecter les champs avec des méthodes de lecture/écriture de leurs valeurs, des membres de classe appelés propriétés sont utilisés. L'utilisateur, lorsqu'il saisit des données pour les enregistrer dans les champs d'un objet ou lit les valeurs des champs, s'occupe des propriétés qui représentent ces champs. Par conséquent, le terme « valeurs de propriété » est généralement utilisé à la place du terme « valeurs de champ ».

Les membres de la classe peuvent être :

1. champs utilisés pour stocker les données ;

2. les propriétés comme moyen d'accès aux champs privés ;

3. des méthodes qui définissent la fonctionnalité des objets ;

4. les événements et leurs gestionnaires comme moyens de gestion du programme.

1.2 Objet conceptuel

L'approche de programmation orientée objet propose que tout ce qui fait partie de l'application soit considéré comme des objets qui interagissent entre eux et avec l'utilisateur conformément aux propriétés et au comportement spécifiés dans le programme, effectuant fonctions nécessaires applications. Ainsi, toute application adoptant cette approche est un ensemble d'objets interconnectés qui implémentent les exigences fonctionnelles nécessaires à l'application.

Un objet est toujours concret et existe réellement sous une forme ou une application, tout en possédant uniquement ses propres propriétés et comportements. Les caractéristiques des objets qui les distinguent les uns des autres sont leurs propriétés et leur comportement. Dans le monde réel, chaque objet ou processus possède un ensemble de caractéristiques statiques et dynamiques (propriétés et comportement). Le comportement d'un objet dépend de son état et des influences extérieures. Par exemple, un objet « voiture » n'ira nulle part s'il n'y a pas d'essence dans le réservoir, et si vous tournez le volant, la position des roues changera. Ainsi, un objet est représenté comme un ensemble de données caractérisant son état et les méthodes (procédures et fonctions) pour les traiter, modélisant son comportement. L'appel d'une procédure ou d'une fonction pour exécution est souvent appelé l'envoi d'un message à un objet (par exemple, l'appel de la procédure « tourner le volant » est souvent interprété comme l'envoi du message « voiture, tourne le volant ! »). Ainsi, chaque objet est caractérisé par les concepts de base suivants :

1. une méthode est une fonction ou une procédure qui implémente des actions possibles avec un objet ;

2. un événement est un moyen d'interaction d'objets entre eux. Les objets génèrent des événements spécifiés et effectuent des actions en réponse à des événements spécifiés. Les événements sont analogues aux messages que les objets reçoivent et envoient ;

3. état - chaque objet est toujours dans un certain état, caractérisé par un ensemble de propriétés de l'objet. Sous l'influence des événements, un objet passe dans d'autres états. Dans ce cas, l'objet lui-même peut générer des événements lors de la transition vers un autre état ;

4. propriété - un signe, une qualité distincte (paramètre) d'un objet.

Par exemple, les propriétés peuvent être les dimensions d'un objet, son titre, son nom. L'ensemble des propriétés d'un objet détermine son état. En règle générale, les propriétés sont un ensemble de variables et de constantes qui stockent des valeurs définissant les paramètres d'un objet.

Il est nécessaire de noter qu'à côté des objets physiques, il peut également exister des objets abstraits, dont les représentants typiques sont les nombres. Ainsi, un objet est toute entité physique ou abstraite clairement identifiable d'un domaine.

Les objets sont caractérisés par des attributs. Ainsi, par exemple, les attributs d'une voiture sont la vitesse maximale, la puissance du moteur, la couleur de la carrosserie, etc. Les attributs d'un amplificateur sont la plage de fréquences, la puissance de sortie, la distorsion harmonique, le niveau de bruit, etc.

En plus des attributs, les objets ont certaines fonctionnalités, appelées en POO opérations, fonctions ou méthodes. Ainsi, une voiture peut conduire, un navire peut naviguer, un ordinateur peut effectuer des calculs.

De cette manière, un objet encapsule des attributs et des méthodes, cachant ainsi son implémentation aux autres objets qui interagissent avec lui et utilisent ses fonctionnalités.

L'approche orientée objet repose sur l'utilisation systématique de modèles pour le développement indépendant du langage d'un système logiciel, basé sur sa pragmatique.

Ce dernier terme mérite d'être clarifié. La pragmatique est déterminée par l'objectif de développer un système logiciel : pour le service aux clients des banques, pour la gestion du fonctionnement d'un aéroport, pour le service de la Coupe du monde, etc. La formulation de l'objectif implique des objets et des concepts du monde réel qui sont pertinents pour le système logiciel en cours de développement (voir Figure 1.2.1).

Avec une approche orientée objet, ces objets et concepts sont remplacés par leurs modèles, c'est-à-dire certaines structures formelles qui les représentent dans un système logiciel.

Fig.1.2.1 Sémantique.

Le modèle ne contient pas toutes les caractéristiques et propriétés de l'objet (concept) qu'il représente, mais uniquement celles qui sont essentielles au système logiciel en cours de développement. Ainsi, le modèle est « plus pauvre » et donc plus simple que l’objet (concept) qu’il représente. Mais l'essentiel n'est même pas cela, mais que le modèle est une construction formelle : la nature formelle des modèles nous permet de déterminer les dépendances formelles entre eux et les opérations formelles sur eux. Cela simplifie à la fois le développement et l'étude (analyse) des modèles et leur mise en œuvre sur ordinateur. En particulier, la nature formelle des modèles nous permet d'obtenir un modèle formel du système logiciel en cours de développement comme une composition de modèles formels de ses composants.

Ainsi, l’approche orientée objet permet de résoudre des problèmes complexes tels que

· réduire la complexité des logiciels ;

· accroître la fiabilité des logiciels ;

· offrir la possibilité de modifier des composants logiciels individuels sans changer les composants restants ;

· assurer la possibilité de réutiliser des composants logiciels individuels.

L'application systématique d'une approche orientée objet permet le développement de systèmes logiciels bien structurés, fiables et assez facilement modifiables. Ceci explique l'intérêt des programmeurs pour l'approche orientée objet et les langages de programmation orientés objet. L'approche orientée objet est l'un des domaines de la programmation théorique et appliquée qui se développe le plus rapidement.

1.3 Outils pour mettre en œuvre la technologie de programmation orientée objet

En technologie POO, la relation entre données et algorithme est plus régulière : d'une part, une classe (concept de base de cette technologie) combine données (variable structurée) et méthodes (fonctions). Deuxièmement, le modèle d’interaction entre les fonctions et les données est fondamentalement différent. Une méthode (fonction) appelée sur un objet n’appelle généralement pas directement une autre fonction. Tout d'abord, il doit avoir accès à un autre objet (créer, récupérer un pointeur, utiliser un objet interne dans l'objet actuel, etc.), après quoi il peut déjà appeler une des méthodes connues sur celui-ci. Ainsi, la structure du programme est déterminée par l'interaction d'objets de différentes classes entre eux. En règle générale, il existe une hiérarchie de classes, et la technologie POO peut autrement être appelée programmation « classe à classe ».

Toute programmation s'effectue selon l'un des quatre principes suivants :

principe de modularité

principe « du général au particulier »

· principe du pas à pas

· principe structurant

Programmation modulaire. Le principe de modularité est formulé comme l'exigence de développer un programme sous la forme d'un ensemble de modules (fonctions). Dans ce cas, la division en modules ne doit pas être de nature mécanique, mais basée sur la logique du programme :

1. la taille des modules doit être limitée ;

2. le module doit effectuer une action logiquement intégrale et complète ;

3. le module doit être universel, c'est-à-dire, autant que possible, paramétré : toutes les caractéristiques modifiables de l'action réalisée doivent être transmises par des paramètres ;

4. Il est conseillé de transmettre les paramètres d'entrée et le résultat du module non pas via des variables globales, mais via des paramètres formels et le résultat de la fonction.

Une autre unité, mais déjà physique, du programme est fichier texte, contenant un certain nombre de fonctions et de définitions de types de données et de variables. La programmation modulaire au niveau des fichiers est la capacité de séparer texte intégral programmes pour plusieurs fichiers. Le principe de modularité s'applique non seulement aux programmes, mais aussi aux données : tout ensemble de paramètres caractérisant un objet logique ou physique doit être représenté dans le programme sous la forme d'une structure de données unique (variable structurée).

L'incarnation du principe de modularité est la bibliothèque caractéristiques standards. Il fournit généralement ensemble complet actions paramétrées à l'aide structures générales données. Les bibliothèques sont des programmes similaires, traduits indépendamment et placés dans le catalogue de la bibliothèque.

Programmation descendante. La conception de programme descendante signifie que le développement procède d'une formulation générale informelle d'une action de programme en langage naturel, « du général au spécifique » : jusqu'à son remplacement par l'une des trois constructions formelles du langage de programmation :

· séquence d'actions simple ;

· constructions de sélection ou instructions if ;

· constructions de répétitions ou de cycles.

Dans la notation de l'algorithme, cela correspond à un passage d'une structure externe (englobante) à une structure interne (emboîtée). Ces conceptions peuvent également contenir des descriptions informelles d'actions dans leurs parties, c'est-à-dire que la conception descendante est de nature étape par étape. Notons les principales propriétés de cette approche :

· initialement, le programme est formulé sous la forme d'une action informelle en langage naturel ;

· les paramètres d'entrée et le résultat de l'action sont initialement déterminés ;

· l'étape suivante de détail ne modifie pas la structure du programme obtenu aux étapes précédentes ;

· si au cours du processus de conception, des actions identiques sont obtenues dans différentes branches, cela signifie qu'il est nécessaire de concevoir cette action comme une fonction distincte ;

· les structures de données nécessaires sont conçues simultanément avec le détail du programme.

Programmation étape par étape. La conception descendante est de nature incrémentale, car elle implique de remplacer à chaque fois une formulation verbale par une seule construction linguistique. Mais dans le processus d'élaboration d'un programme, il peut y avoir d'autres étapes liées à la spécification de la formulation verbale elle-même en des étapes plus détaillées.

Le fait que ce principe soit mis en évidence séparément indique la nécessité d'éviter la tentation de détailler le programme immédiatement du début à la fin et de développer la capacité de mettre en évidence et de concentrer l'attention sur les détails principaux plutôt que mineurs de l'algorithme.

En général, la conception d'un programme descendant, étape par étape, ne garantit pas un programme « correct », mais elle vous permet de revenir à l'une des étapes de détail supérieures lorsqu'un blocage est détecté.

Programmation structurée. Avec le raffinement du programme étape par étape, les structures de données et les variables nécessaires au fonctionnement apparaissent à mesure que nous passons des définitions informelles aux constructions linguistiques, c'est-à-dire que les processus de détail de l'algorithme et des données se déroulent en parallèle. Toutefois, cela s'applique principalement aux variables locales individuelles et aux paramètres internes. Du point de vue le plus général, l'objet (dans notre cas, les données) est toujours primordial par rapport aux actions réalisées avec lui (dans notre cas, l'algorithme). Par conséquent, en fait, la manière dont un programme organise les données a un impact plus significatif sur la structure de son algorithme que toute autre chose, et le processus de conception des structures de données devrait précéder le processus de conception d'un algorithme pour les traiter.

La programmation structurée est une conception modulaire, descendante et étape par étape d'algorithmes et de structures de données.

L'approche de programmation orientée objet comprend 3 composants principaux :

· analyse orientée objet (OOA),

· conception orientée objet (OOD),

· programmation orientée objet (POO).

Dans toute discipline d'ingénierie, la conception fait généralement référence à une approche unifiée par laquelle nous recherchons des moyens de résoudre un problème spécifique, garantissant ainsi que la tâche est accomplie. Dans le contexte de la conception technique, l'objectif de la conception est défini comme la création d'un système qui

· satisfait aux spécifications fonctionnelles données (éventuellement informelles) ;

· compatible avec les limitations imposées par l'équipement ;

· satisfait aux exigences explicites et implicites en matière de performances et de consommation de ressources ;

· satisfait aux critères de conception de produits explicites et implicites ;

· satisfait aux exigences du processus de développement lui-même, telles que la durée et le coût, ainsi qu'à l'implication de ressources supplémentaires. outils.

La conception implique la prise en compte d’exigences contradictoires. Ses produits sont des modèles qui nous permettent de comprendre la structure du futur système, d'équilibrer les exigences et d'esquisser un schéma de mise en œuvre.

Le programme est un modèle numérique du système en cours de conception (Fig. 1.3.1.)

Riz. 1.3.1. Structure du programme.

L’importance de construire un modèle. La modélisation est répandue dans toutes les disciplines de l'ingénierie, en grande partie parce qu'elle met en œuvre les principes de décomposition, d'abstraction et de hiérarchie. Chaque modèle décrit une certaine partie du système considéré et, à notre tour, nous construisons de nouveaux modèles basés sur les anciens, dans lesquels nous avons plus ou moins confiance. Les modèles nous permettent de contrôler nos échecs. Nous évaluons le comportement de chaque modèle dans des situations normales et inhabituelles, puis procédons aux ajustements appropriés si nous ne sommes pas satisfaits de quelque chose.

Éléments de conception de logiciels. Il est clair que cela n'existe pas méthode universelle, qui guiderait un ingénieur logiciel tout au long du chemin depuis les exigences d'un système logiciel complexe jusqu'à leur mise en œuvre. Concevoir un système logiciel complexe ne consiste pas à suivre aveuglément un ensemble de recettes. Il s’agit plutôt d’un processus graduel et itératif. Pourtant, le recours à une méthodologie de conception apporte une certaine organisation au processus de développement. Les ingénieurs logiciels ont développé des dizaines diverses méthodes, que l’on peut classer en trois catégories. Malgré leurs différences, ces méthodes ont quelque chose en commun. Ils sont notamment unis par les éléments suivants :

· symboles - langage pour décrire chaque modèle ;

· processus - règles de conception d'un modèle ;

· outils - outils qui accélèrent le processus de création de modèles et dans lesquels les lois de fonctionnement des modèles sont déjà incarnées. Les outils aident à identifier les erreurs pendant le processus de développement.

Une bonne méthode de conception est basée sur un solide base théorique et donne en même temps au programmeur une certaine liberté d'expression.

Modèles orientés objet. Il est très utile de créer des modèles axés sur les objets trouvés dans le domaine lui-même, formant ce qu'on appelle une décomposition orientée objet.

L'analyse et la conception orientées objet sont une méthode qui mène logiquement à une décomposition orientée objet. Grâce à la conception orientée objet, des programmes flexibles et écrits de manière rentable sont créés. En divisant judicieusement l’espace des états, nous gagnons en confiance dans l’exactitude de notre programme. En conséquence, nous réduisons les risques lors du développement de systèmes logiciels complexes.

Étant donné que la construction de modèles est extrêmement importante lors de la conception de systèmes complexes, la conception orientée objet offre une riche sélection de modèles (illustré sur la Fig. 1.3.2). Les modèles de conception orientée objet reflètent la hiérarchie des classes et des objets du système. Ces modèles couvrent toute la gamme des décisions de conception critiques qui doivent être prises en compte lors de la conception d'un système complexe et nous incitent ainsi à créer des conceptions qui présentent les cinq attributs d'un système complexe bien conçu.

Riz. 1.3.2 Modèles orientés objet.

La POO est une idéologie de programmation basée sur la combinaison de données et de procédures pouvant fonctionner collectivement avec ces données, appelées classes.

L'essence de la POO est l'utilisation d'un modèle objet familier dans la vie quotidienne. Chaque objet possède ses propres propriétés et vous pouvez effectuer des actions qui lui sont spécifiques. Une classe est un type d'objet. La classe décrit et implémente ces mêmes propriétés et actions. Un objet, selon notre compréhension, sera une variable dont le type sera une sorte de classe. Nous appellerons les champs d'une classe ses propriétés, et ses méthodes les actions pouvant être effectuées avec une instance de cette classe (objet).

À titre d'exemple d'implémentation de classe, regardons l'implémentation du concept de livre utilisant une classe pour définir une représentation du livre TBook et un ensemble de fonctions pour travailler avec des variables de ce type :

Nombre de pages : entier ;

fonction CompareWithBook(OtherBook: TBook) : entier ;

procédure ShowTitle ;

constructeur Créer(NouveauTitre, Nouveau

Les capacités cognitives humaines sont limitées ; nous pouvons repousser leurs limites en utilisant la décomposition, l'abstraction et les hiérarchies.

Les systèmes complexes peuvent être étudiés en se concentrant soit sur des objets, soit sur des processus ; Il existe de bonnes raisons d’utiliser la décomposition orientée objet, dans laquelle le monde est considéré comme un ensemble ordonné d’objets qui, en interagissant les uns avec les autres, déterminent le comportement du système.

L'analyse et la conception orientées objet sont une méthode qui utilise la décomposition d'objets ; l'approche orientée objet a son propre système symboles et offre un riche ensemble de modèles logiques et physiques grâce auxquels nous pouvons avoir un aperçu de divers aspects du système considéré.

2. CONSTRUCTION D'UN MODÈLE OBJET DU DOMAINE « ORGANISATION DES PROCESSUS DES CLUB SPORTIFS » EN UTILISANT LE LANGAGE DE MODÉLISATION UML

2.1 Notion de langage UML

UML (Unified Modeling Language) est un langage de modélisation graphique unifié permettant de décrire, visualiser, concevoir et documenter des systèmes orientés objet. UML est conçu pour prendre en charge le processus de modélisation logiciel sur la base d'une approche orientée objet, organiser la relation entre les concepts conceptuels et les concepts de programme, refléter les problèmes de mise à l'échelle de systèmes complexes. Les modèles UML sont utilisés à toutes les étapes cycle de vie outils logiciels, de l'analyse commerciale à la maintenance du système. Différentes organisations peuvent utiliser UML comme bon leur semble en fonction de leur zones à problèmes et les technologies utilisées.

2.1.1 Bref historique d'UML

Au milieu des années 90, divers auteurs avaient proposé plusieurs dizaines de méthodes de modélisation orientées objet, chacune utilisant sa propre notation graphique. De plus, chacune de ces méthodes avait ses propres atouts, mais ne permettait pas de construire suffisamment modèle complet logiciel, montrez-le « de tous les côtés », c'est-à-dire toutes les projections nécessaires. De plus, l'absence de norme pour la modélisation orientée objet a rendu difficile pour les développeurs de choisir la méthode la plus appropriée, ce qui a empêché l'adoption généralisée de l'approche orientée objet dans le développement de logiciels.

À la demande de l'Object Management Group (OMG), l'organisation chargée d'adopter des normes dans le domaine des technologies objets et des bases de données, le problème urgent de l'unification et de la standardisation a été résolu par les auteurs des trois méthodes orientées objet les plus populaires - G Butch, D. Rambo et A. Jacobson, qui ont collaboré pour créer UML 1.1, qui a été adopté comme standard par l'OMG en 1997.

Suite à l'intérêt croissant pour UML, des sociétés telles que Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software ont rejoint le développement de nouvelles versions du langage. au sein du consortium UML Partners, Texas Instruments et Unisys. Le résultat de ce travail commun a été la spécification UML 1.0, publiée en janvier 1997. Elle fut suivie en novembre de la même année par la version 1.1, qui contenait des améliorations de la notation ainsi que quelques extensions sémantiques. UML 1.4.2 a été adopté comme norme internationale par ISO/IEC 19501:2005.

La spécification formelle de la dernière version d'UML 2.0 a été publiée en août 2005. La sémantique du langage a été considérablement affinée et étendue pour prendre en charge la méthodologie Model Driven Development - MDD. Dernière version UML 2.4.1 a été publié en août 2011. UML 2.4.1 a été adopté comme norme internationale par ISO/IEC 19505-1, 19505-2.

2.1.2 langage UML

Toute langue se compose d'un vocabulaire et de règles permettant de combiner des mots pour créer des constructions significatives. C'est notamment ainsi que sont structurés les langages de programmation, comme UML. Sa particularité est que le vocabulaire de la langue est formé d'éléments graphiques. Pour chaque symbole graphique des sémantiques spécifiques correspondent, de sorte qu'un modèle créé par un développeur puisse être compris sans ambiguïté par un autre, ainsi que par un outil logiciel qui interprète l'UML. De là, en particulier, il s'ensuit qu'un modèle logiciel présenté en UML peut être automatiquement traduit dans un langage de programmation OO (tel que Java, C++, VisualBasic), c'est-à-dire s'il existe un bon outil de modélisation visuelle prenant en charge UML, ayant construit le modèle, nous recevrons également un exemple de code de programme correspondant à ce modèle.

Il convient de souligner qu’UML est un langage et non une méthode. Il explique à partir de quels éléments créer des modèles et comment les lire, mais ne dit rien sur les modèles qui doivent être développés et dans quels cas. Pour créer une méthode basée sur UML, il est nécessaire de la compléter par une description du processus de développement logiciel. Un exemple d'un tel processus est le processus unifié rationnel, qui sera discuté dans les articles suivants.

2.1.3 Dictionnaire UML

Le modèle est représenté sous forme d'entités et de relations entre elles, présentées sous forme de diagrammes.

Les entités sont des abstractions qui sont les éléments de base des modèles. Il existe quatre types d'entités : structurelle (classe, interface, composant, cas d'utilisation, collaboration, nœud), comportementale (interaction, état), regroupement (packages) et annotation (commentaires). Chaque type d'entité possède sa propre représentation graphique. Les entités seront discutées en détail lors de l’étude des diagrammes.

Les relations montrent les différentes connexions entre les entités. UML définit les types de relations suivants :

· La dépendance montre une telle connexion entre deux entités lorsqu'un changement dans l'une d'elles - indépendante - peut affecter la sémantique de l'autre - dépendante. La dépendance est représentée par une flèche en pointillé dirigée de l'entité dépendante vers l'entité indépendante.

· L'association est une relation structurelle montrant que les objets d'une entité sont associés aux objets d'une autre. Graphiquement, une association est représentée par une ligne reliant les entités associées. Les associations servent à naviguer entre les objets. Par exemple, l'association entre les classes « Commande » et « Produit » peut être utilisée pour retrouver tous les produits spécifiés dans une commande spécifique, d'une part, ou pour retrouver toutes les commandes qui contiennent ce produit, d'autre part. Il est clair que les programmes correspondants doivent implémenter un mécanisme permettant une telle navigation. Si une navigation dans une seule direction est requise, elle est indiquée par une flèche à la fin de l'association. Un cas particulier d'association est l'agrégation - une relation de la forme « tout » - « partie ». Graphiquement, il est souligné d'un losange à l'extrémité proche de l'essence-toute.

· Une généralisation est une relation entre une entité parent et une entité enfant. Essentiellement, cette relation reflète la propriété d’héritage des classes et des objets. La généralisation est représentée par une ligne se terminant par un triangle dirigé vers l'entité mère. L'enfant hérite de la structure (attributs) et du comportement (méthodes) du parent, mais en même temps il peut avoir de nouveaux éléments de structure et de nouvelles méthodes. UML permet l'héritage multiple, lorsqu'une entité est liée à plusieurs entités parent.

· Implémentation - la relation entre une entité qui définit une spécification de comportement (interface) avec une entité qui définit l'implémentation de ce comportement (classe, composant). Cette relation est couramment utilisée lors de la modélisation de composants et sera décrite plus en détail dans les articles suivants.

Diagrammes. UML fournit les diagrammes suivants :

· Schémas décrivant le comportement du système :

Diagrammes d'état

· Diagrammes d'activités,

· Diagrammes d'objets,

Diagrammes de séquence

· Diagrammes de collaboration ;

· Schémas décrivant la mise en œuvre physique du système :

· Diagrammes de composants ;

· Diagrammes de déploiement.

2.1.4 Structure de gestion modèle

Pour qu’un modèle soit bien compris par les humains, il est nécessaire de l’organiser hiérarchiquement, en laissant un petit nombre d’entités à chaque niveau de la hiérarchie. UML inclut un moyen d'organiser une représentation hiérarchique d'un modèle : les packages. Tout modèle se compose d'un ensemble de packages pouvant contenir des classes, des cas d'utilisation et d'autres entités et diagrammes. Un package peut contenir d'autres packages, permettant la création de hiérarchies. UML ne fournit pas de diagrammes de packages séparés, mais ils peuvent apparaître dans d'autres diagrammes. Le colis est représenté par un rectangle avec un signet.

UML fournit.

· description hiérarchique d'un système complexe par mise en évidence de packages ;

· formalisation des exigences fonctionnelles du système à l'aide de l'appareil des cas d'utilisation ;

· détailler les exigences du système en construisant des diagrammes d'activités et des scénarios ;

· identifier les classes de données et construire un modèle de données conceptuel sous forme de diagrammes de classes ;

· identifier les classes qui décrivent l'interface utilisateur et créer un schéma de navigation sur écran ;

· description des processus d'interaction entre les objets lors de l'exécution des fonctions du système ;

· description du comportement des objets sous forme de diagrammes d'activité et d'état ;

· description des composants logiciels et de leur interaction via les interfaces ;

· description de l'architecture physique du système.

UML serait difficile à utiliser dans la modélisation logicielle réelle sans outils de modélisation visuelle. De tels outils vous permettent de présenter rapidement des diagrammes sur l'écran d'affichage, de les documenter, de générer des modèles de code de programme dans divers langages de programmation orientés objet et de créer des diagrammes de base de données. La plupart d'entre eux incluent la possibilité de réingénierie des codes de programme - restaurer certaines projections d'un modèle logiciel en analysant automatiquement les codes sources des programmes, ce qui est très important pour assurer la cohérence entre le modèle et les codes et lors de la conception de systèmes héritant des fonctionnalités des systèmes précédents.

2.2 Description du fonctionnement du domaine « Organisation du travail d'un club sportif »

Selon la nature des liens entre les divisions de l'entreprise, on distingue les types de structures organisationnelles suivants : linéaire, fonctionnelle, linéaire-fonctionnelle et matricielle.

Le travail de ce club sportif utilise une structure de gestion linéaire.

Le club sportif résout les problèmes suivants :

· l'implication des jeunes et des membres de leurs familles dans l'éducation physique et sportive systématique ;

· l'éducation des qualités physiques et morales-volontaires, renforçant la santé et réduisant la morbidité, augmentant le niveau de préparation professionnelle et d'activité sociale des jeunes ;

· organiser et conduire des événements de masse récréatifs, d'éducation physique et sportives ;

· création d'associations, de clubs, de sections et d'équipes sportives amateurs ;

· promotion de la culture physique et du sport, d'un mode de vie sain, organisation de loisirs significatifs, implication des larges masses de jeunes dans des événements sociopolitiques de masse

Le club sportif remplit les fonctions suivantes :

· met en œuvre la culture physique et le sport dans les activités des jeunes, leur vie et leurs loisirs ; promeut un mode de vie sain, lutte pour surmonter les mauvaises habitudes ;

· crée les conditions organisationnelles et méthodologiques nécessaires à la pratique de diverses formes et types de culture physique et sportive conformément aux traditions établies dans le pays ;

· introduit de nouvelles formes et méthodes d'éducation physique, d'expériences avancées et de réalisations scientifiques ; utilise les ressources matérielles de manière rationnelle et efficace ;

· développe les principes sociaux de toutes les manières possibles dans le travail d'éducation physique, de santé et de sport de masse ;

· fournit une assistance aux écoles secondaires et aux collèges pour l'organisation d'activités récréatives, d'éducation physique et sportives de masse ;

· organise le processus éducatif et de formation dans les sections sportives (équipes nationales) ;

· élabore et met en œuvre des plans de calendrier pour les événements récréatifs, physiques et sportifs de masse, assure la sécurité de leur mise en œuvre ;

· assure le contrôle du processus d'éducation et de formation dans les sections d'un club sportif pour la préparation des athlètes des plus hautes qualifications sportives, contribue à la création conditions nécessaires accroître leur esprit sportif;

· organise, en collaboration avec les autorités sanitaires, le contrôle médical de l'état de santé des acteurs de la culture physique et du sport dans les sections (équipes nationales) ;

· établit les plans actuels et à long terme de développement des activités d'éducation physique, de santé, éducatives et sportives de masse, ainsi que les estimations de coûts pour le club.

· dans les limites de sa compétence, sélectionne et place le personnel d'éducation physique ;

· peut avoir un drapeau, un emblème, un uniforme de sport, un cachet, du papier à en-tête ;

· organise des compétitions de masse, des journées sportives (universiades), des camps éducatifs et d'entraînement ;

· conformément à la procédure approuvée, envoie des équipes et des athlètes individuels aux compétitions ;

· délivre les certificats (badges) appropriés aux membres des équipes universitaires ;

2.3 Construction d'un diagramme de classes pour le domaine « Organisation des processus des clubs sportifs »

Le club sportif comprend quatre sections basées sur le club :

· Basket-ball

· Volley-ball

· Tennis.

Lorsque des candidats-athlètes postulent à un club sportif pour s'inscrire dans une section, une inscription est effectuée, ce qui implique les actions suivantes :

· Les données sur les sportifs sont saisies dans un tableau indiquant 5 champs : Nom, Prénom, Âge, Téléphone, Section.

· Les athlètes sont divisés en sections auxquelles la candidature a été soumise.

· Les parents d'athlètes reçoivent un calendrier des sections du club sportif.

Pour organiser le bon travail du club, coordonner le travail des sections et l'emploi des entraîneurs, l'administrateur du club sportif remplit le planning.

Lorsqu'il rejoint un club, un athlète est inscrit dans un tableau indiquant la section. Tous les athlètes impliqués dans le club doivent être inscrits dans le tableau principal en indiquant la section.

Pour représenter visuellement les processus de travail du club sportif, un diagramme UML a été construit (Fig. 2.3.1).

Riz. 2.3.1 Modèle orienté objet d'un club de sport.

3. CONSTRUCTION D'UN MODÈLE OBJET DU DOMAINE « ORGANISATION DU TRAVAIL D'UN CLUB SPORTIF » À L'AIDE DE L'ENVIRONNEMENT DE PROGRAMMATION VISUEL DELPHI

3.1 Description de la structure de la candidature

Cette application fait partie du package Sport. Il est constitué d'une classe : la classe TPeople.

La classe « TPeople » permet de créer et d'accumuler des informations sur les enfants impliqués dans ce club sportif appelé « Ogonyok ». Il comporte cinq champs : Le nom est spécifié par la chaîne « Nom » ; Le nom de famille est spécifié par la chaîne « Famil » ; L'âge est stocké dans la variable numérique (int) "Age" ; le numéro de téléphone est précisé par la chaîne « Tel » ; La section dans laquelle l'athlète s'entraîne est précisée par la chaîne « Sekc ».

TPeople = classe

Nom : chaîne ;

Famille : chaîne ;

Âge : entier ;

tél : chaîne ;

sekc : chaîne ;

constructeur Create(AName: String);

fin;

Dans ce cas, les champs sont saisis de deux manières :

Chargement d'une valeur à partir d'un fichier enregistré avec l'extension LST. (Figure 3.1.1.)

La méthode est organisée à l'aide de la fonction OpenDlg, chaque ligne de la classe étant lue comme une valeur distincte.

var F : FichierTexte ;

je : entier ;

commencer

essayer

avec OpenDlg, PersonsList.Items fait

commencer

si ce n'est pas exécuté, quittez ;

LoadFromFile(NomFichier);

AssignFile(F, Copy(FileName,1,Length(FileName)-4)+".lso");

Réinitialiser (F);

je:= 0;

tandis que Not EOF(F) fait

commencer

Objets[i] := TPeople.Create("");

Readln(F, (Objets[i] en tant que TPeople).Name);

Readln(F, (Objets[i] comme TPeople).Famil);

Readln(F, (Objets[i] comme TPeople).Age);

Readln(F, (Objets[i] comme TPeople).tel);

Readln(F, (Objets[i] comme TPeople).sekc);

Inc(i);

fin;

FermerFichier(F);

fin;

sauf

sur E : EFOpenError do ShowMessage("Erreur d'ouverture du fichier");

fin;fin;

Riz. 3.1.1 Téléchargement de fichiers.

La deuxième méthode de remplissage du tableau est la saisie à l'aide des composants Edit (Fig. 3.1.2.).

Riz. 3.1.2 Remplir le tableau à l'aide du composant Edit.

De plus, la valeur du champ « Section » est sélectionnée parmi les valeurs du composant Combobox et affectée à la ligne « Sekc ». (Fig.3.1.3)

Riz. 3.1.3 Composant Combobox.

Les valeurs saisies peuvent être ajustées en sélectionnant la valeur souhaitée et en cliquant sur le bouton « Modifier » (Fig. 3.1.4)

Riz. 3.1.4 Modification des valeurs.

Le programme permet de supprimer une valeur en supprimant une entrée (Fig. 3.1.5) et en supprimant toutes les entrées (Fig. 3.1.6).

La suppression d'un enregistrement se fait en sélectionnant une valeur et en cliquant sur le bouton « Supprimer ».

Riz. 3.1.5 Suppression d'une entrée.

Afin d'effacer tous les enregistrements, cliquez sur le bouton « Effacer ».

Riz. 3.1.6 Bouton « Effacer ».

Les deux méthodes de suppression sont effectuées en utilisant les méthodes suivantes :

procédure TMainForm.ToolButton4Click(Expéditeur : TObject);

commencer

avec PersonsList, faites Items.Delete(ItemIndex);

fin;

procédure TMainForm.ToolButton5Click(Expéditeur : TObject);

commencer

PersonnesList.Items.Clear ;

fin;

Après avoir rempli le tableau des athlètes, il devient nécessaire de le conserver pour une utilisation future. Cela se fait en cliquant sur le bouton « Enregistrer » (Fig. 3.1.7). Après avoir cliqué sur ce bouton, une boîte de dialogue s'ouvre, où le dossier de stockage des fichiers et son nom sont indiqués. (Fig. 3.1.8).

Documents similaires

Brève description du domaine. La pertinence de développer un modèle de système d’information orienté objet pour bibliothèque pédagogique. Créez un diagramme de cas d'utilisation, un diagramme de séquence, un diagramme de collaboration, un diagramme de classes.

travail de cours, ajouté le 01/06/2009


Développement d'un sous-système orienté objet comptabilité d'entrepôt pour la société "KavkazYugAvto". Brève description du domaine. Dessiner des diagrammes de placement, de cas d'utilisation, de séquence, de composants et de classes. Génération de code C++.

travail de cours, ajouté le 26/06/2011


Éléments de base du modèle objet. L'essence et les avantages de l'approche orientée objet, le concept d'objet et de classe. Langage de modélisation unifié UML. Diagrammes de classes et d'interactions : objectif, construction et exemples d'utilisation.

résumé, ajouté le 09/06/2009


Description du domaine « Magasin vendant des composants informatiques ». Construire des modèles de données, d'entités et de relations ER et relationnelles. Création d'un modèle de données ER et relationnel, de requêtes, de vues, de procédures stockées pour le domaine.

travail de cours, ajouté le 15/06/2014


Pertinence et importance pratique des systèmes logiciels des clubs informatiques. Analyse de domaine. Diagramme de classes, modèle physique systèmes. Développement projet visuel IS, utilisant le langage UML2.0 et l'environnement de modélisation Microsoft Visio.

travail de cours, ajouté le 21/06/2014


Analyse du domaine « Concours de poètes » basée sur une approche orientée objet. Développement et description d'applications Windows modèle d'information Domaine. Description des procédures C++ développées et des résultats des tests d'application.

travail de cours, ajouté le 18/06/2013


Modélisation fonctionnelle IDEF0. Description de tous les processus de travail du service de support technique. Décomposition du diagramme de contexte et des processus centraux. Construire un modèle de processus de domaine dans la norme IDEF1X. Interface du programme de contrôle du trafic.

rapport de pratique, ajouté le 22/11/2014


Construction d'un modèle infologique d'un domaine à l'aide de la méthode Diagrammes ER. Création de relations de bases de données en utilisant le langage SQL. Remplissage de la base de données. Création de requêtes vers la base de données du club informatique. Créez un rapport en utilisant Microsoft Word et Microsoft Excel.

travail de cours, ajouté le 26/02/2009


Brève description du domaine. Créez des cas d'utilisation, des séquences, des collaborations, des classes, des placements et des diagrammes de composants. Ajout de détails aux descriptions d'opérations et définition des attributs CLASS. Génération de code C++.

travail de cours, ajouté le 29/06/2011


caractéristiques générales entrepôt comme objet d'activité économique. Créez un cas d'utilisation et un diagramme de séquence. Construire un diagramme de collaboration d'entreprise. Objectif des diagrammes de classes et de composants. Génération de code C++.

Construire un modèle objet d'un problème à l'aide du langage de modélisation UML.

LE TRAVAIL EST FAIT DANS StarUML

Délai de mise en œuvre:

2 – 3 leçons

Pour défendre votre travail, vous devez fournir un projet créé dans le package Rational Rose, comprenant trois types de diagrammes : cas d'utilisation, classes (interface, données) et séquences pour chaque fonction.

EXEMPLE DE TÂCHE :

Il est nécessaire de s'assurer que les informations suivantes sont stockées dans la base de données :

- informations sur les étudiants

o NOM ET PRÉNOM.,

o adresse,

o informations du passeport,

o numéro d'enregistrement,

o Date de naissance,

o groupe);

- informations sur les spécialités

o nom de la spécialité,

o chiffrer;

- informations sur les groupes

o spécialité,

o année d'admission,

o numéro de groupe.

Assurer l’émission d’un document « Liste de groupe » contenant les champs suivants :

· numéro de série,

· NOM ET PRÉNOM.,

· numéro d'enregistrement.

Demande de service

La construction du modèle objet est réalisée dans le package Rational Rose. Pour ce faire, créons un projet vide. Vous devriez commencer votre travail avec un diagramme de cas d'utilisation. Il est construit dans la zone principale de la section Use Case View, comme le montre la Fig. 9.

Avant de commencer à construire un diagramme, il est nécessaire de définir les rôles des utilisateurs du système (acteurs) et leurs fonctions (cas d'utilisation). Dans notre cas, deux acteurs travaillent avec le système : « Employé du service éducatif » et « Employé du doyenné ». Les fonctions d'un employé du service éducatif comprennent la tenue d'une liste de spécialités (sous tenir une liste nous comprendrons ajouter des enregistrements, les ajuster et les supprimer). Les fonctions de l'employé du bureau du doyen comprennent la tenue d'une liste d'étudiants et la tenue d'une liste de groupes.

Le diagramme construit est présenté sur la Fig. dix.

Ensuite, dans la section Vue logique, vous devez créer deux diagrammes de classes. Pour ce faire, vous pouvez créer deux packages. Le premier diagramme doit contenir les classes d'interface de l'application en cours de conception (voir Figure 11). Sur cette figure, dans les classes « Liste des groupes » et « Liste des élèves », les opérations d'ajout, de modification et de suppression sont omises pour ne pas encombrer la figure. La liste de groupe (classe inférieure) est le document de sortie (elle est précédée de la classe « Sélection de groupe », puisqu'il est nécessaire d'obtenir une liste des étudiants d'un certain groupe). Le deuxième diagramme représente les entités de base de données (voir Fig. 12).

Le diagramme de classes construit affiche toutes les formes de la future application et leurs relations.

Vous devez saisir les champs clés et établir une connexion (à partir du menu contextuel fléché - Multiplicité).

La prochaine étape de la création d'un modèle objet consiste à créer des diagrammes de séquence. Des diagrammes de séquence sont créés pour chaque cas d'utilisation dans le diagramme de cas d'utilisation. Pour ajouter un diagramme de séquence à un cas d'utilisation, vous devez le sélectionner dans l'arborescence et l'appeler menu contextuel(Diagramme NewàSequence) comme le montre la Fig. 13.

Un exemple de diagramme de séquence pour le précédent « Maintenir une liste de spécialités » est présenté dans la Fig. 14.

Il convient de noter que lors de la construction de ce type de diagramme pour le document de sortie « Liste de groupes », dans notre cas, vous devez d'abord sélectionner le groupe sur le formulaire « Sélection de groupe » (celui-ci, à son tour, doit recevoir les données du « Groupe "), puis affichez le document du formulaire de sortie, auquel les données proviennent de l'entité "Étudiant".