INTRODUCTION

Les caractéristiques les plus importantes de tout système sont sa structure et son processus de fonctionnement. La structure d’un système est comprise comme un ensemble de relations stables dans le temps entre ses éléments ou composants. C'est la structure qui lie tous les éléments entre eux et empêche le système de se désintégrer en composants séparés. La structure d’un système peut refléter diverses relations, notamment l’imbrication d’éléments d’un système dans un autre. Dans ce cas, il est d’usage d’appeler le système plus petit ou imbriqué un sous-système. Le processus de fonctionnement du système est étroitement lié aux changements de ses propriétés ou de son comportement au fil du temps. Dans ce cas, une caractéristique importante du système est son état, qui est compris comme un ensemble de propriétés ou de caractéristiques qui, à chaque instant, reflètent les caractéristiques les plus significatives du comportement du système. Une propriété commune à tous les modèles est leur similitude avec le système original. L'importance des modèles de construction réside dans la possibilité de les utiliser pour obtenir des informations sur les propriétés ou le comportement du système d'origine. Dans ce cas, le processus de construction et d'application ultérieure de modèles pour obtenir des informations sur le système d'origine est appelé modélisation. Le modèle général du système contient des informations importantes sur les caractéristiques fonctionnelles d'un système donné, qui donnent un aperçu de son comportement futur.

L'étude du processus de modélisation est l'objet d'étude dans ce cours. La construction d'un modèle objet spécifique et l'étude de son comportement seront considérées comme un sujet de recherche. Pour atteindre cet objectif, les méthodes suivantes sont utilisées : étude de la littérature nécessaire, comparaison, exemples tirés de l'expérience de vie La construction d'un modèle objet étant réalisée à partir de l'exemple d'un service automobile, il est nécessaire d'étudier le fonctionnement. principe de cette organisation. Pour ce faire, il suffit de visiter les sites officiels des différents services automobiles. Mais pour étudier les principes de construction d'un modèle objet, j'ai étudié la littérature scientifique nationale et étrangère. Cela s’est avéré être une activité très excitante.

De ce fait, le but de mon cours était de construire un modèle objet du système d'information Autoservice, d'étudier le principe de construction d'un modèle objet, de décrire le processus de construction, de prouver l'importance de posséder ces connaissances et la capacité de les appliquer dans pratique.

La structure du cours est la suivante : d'abord, la théorie de la construction d'un modèle objectif est étudiée, puis la mise en œuvre de la théorie est testée à l'aide d'un exemple pratique.

1. Concepts de base de l'approche orientée objet

L'approche orientée objet repose sur l'utilisation systématique de modèles. 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. 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.

Le modèle ne contient pas toutes les caractéristiques et propriétés de l'objet ou du 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 simple que l’objet (concept) qu’il représente. 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 aide à faire face à des problèmes complexes tels que la réduction de la complexité logicielle ; accroître la fiabilité des logiciels ; garantir la possibilité de modifier des composants logiciels individuels sans modifier 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. 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.

Le développement de logiciels orientés objet implique l'utilisation de modèles orientés objet dans le développement de systèmes logiciels et de leurs composants.

Le développement orienté objet peut commencer dès la toute première étape du cycle de vie ; il n'est pas lié au langage de programmation dans lequel le système logiciel en cours de développement est censé être implémenté : ce langage ne peut pas être orienté objet. Au stade du développement, les objets sont des structures formelles (par exemple, des rectangles aux coins arrondis, à l'aide desquels ils sont représentés sur des diagrammes), qui ne sont encore en aucun cas liées à leur future implémentation dans l'un des langages de programmation.

Le développement de logiciels orientés objet implique l'utilisation de méthodologies (technologies) orientées objet. Généralement, ces méthodologies orientées objet sont prises en charge par des outils logiciels, mais même sans de tels outils, elles sont utiles, car elles permettent une bonne compréhension des différents aspects et propriétés du système logiciel en cours de développement, ce qui facilite par la suite considérablement sa mise en œuvre, ses tests, maintenance, développement de nouvelles versions et modifications plus importantes.

La conception d'un système logiciel d'application commence par une analyse des exigences auxquelles il devra satisfaire. Une telle analyse est réalisée afin de comprendre suffisamment la finalité et les conditions de fonctionnement du système pour pouvoir en établir l'avant-projet.

Avec une approche orientée objet, l'analyse des exigences du système se résume à l'élaboration de modèles de ce système. Un modèle d'un système (ou de tout autre objet ou phénomène) est une description formelle du système, qui identifie les principaux objets qui composent le système et les relations entre ces objets. La construction de modèles est un moyen répandu d’étudier des objets et des phénomènes complexes. Le modèle omet de nombreux détails qui le rendent difficile à comprendre. La modélisation est répandue tant dans la science que dans la technologie.

Les modèles aident à vérifier les performances du système en cours de développement dès les premiers stades de son développement, à communiquer avec le client du système, à clarifier ses exigences pour le système et à apporter (si nécessaire) des modifications à la conception du système (à la fois au début de sa conception et à d'autres phases de son cycle de vie).

Les modèles développés et débogués au cours de la première phase du cycle de vie du système continuent d'être utilisés dans toutes les phases ultérieures, facilitant la programmation, le débogage et les tests du système, la maintenance et les modifications ultérieures.

Le modèle objet décrit la structure des objets qui composent le système, leurs attributs, leurs opérations et leurs relations avec d'autres objets. Le modèle objet doit refléter les concepts et objets du monde réel qui sont importants pour le système en cours de développement. Le modèle objet reflète avant tout la pragmatique du système en cours de développement, qui s'exprime dans l'utilisation de la terminologie du domaine d'application associée à l'utilisation du système en cours de développement.

Considérons les concepts de base utilisés dans la construction d'un modèle objet.

Un objet est une abstraction ou toute chose avec des limites clairement définies qui a du sens dans le contexte du problème appliqué. L'introduction d'objets a deux objectifs : comprendre la tâche appliquée (problème) et introduire les bases de la mise en œuvre sur un ordinateur.

Le but du développement d'un modèle objet est de décrire les objets qui composent collectivement le système conçu, ainsi que d'identifier et d'indiquer diverses dépendances entre les objets.

Une classe est un descripteur d’un ensemble d’objets possédant les mêmes propriétés. Une classe décrit les propriétés d'un certain nombre d'objets. Chaque objet est une instance d'une seule classe.

Tous les objets d’une même classe sont caractérisés par les mêmes ensembles d’attributs. Cependant, le regroupement des objets en classes n'est pas déterminé par des ensembles d'attributs, mais par la sémantique. Ainsi, par exemple, les objets écurie et cheval peuvent avoir les mêmes attributs : prix et âge. De plus, ils peuvent appartenir à la même classe, s’ils sont considérés dans le problème simplement comme un produit, ou à des classes différentes, ce qui est plus naturel.

La combinaison d'objets en classes permet d'introduire l'abstraction dans le problème et de l'envisager dans une formulation plus générale. Une classe a un nom (comme cheval) qui s'applique à tous les objets de cette classe. De plus, la classe contient les noms des attributs définis pour les objets. En ce sens, la description d’une classe est similaire à la description d’un type de structure (enregistrement) ; De plus, chaque objet a la même signification qu'une instance de la structure (variable ou constante du type correspondant).

Un attribut d'objet est une valeur qui caractérise un objet dans sa classe. Exemples d'attributs : marque, année de fabrication, couleur (attributs des objets de la classe automobile), etc.

Une opération est une fonction (ou transformation) qui peut être appliquée aux objets d'une classe donnée. Exemples d'opérations : vérifier, supprimer, installer (pour les objets de la classe pièces détachées).

Tous les objets d'une classe donnée utilisent la même instance de chaque opération (c'est-à-dire qu'augmenter le nombre d'objets d'une certaine classe n'entraîne pas une augmentation de la quantité de code de programme chargé). L'objet à partir duquel l'opération est appelée lui est transmis comme argument implicite (paramètre).

La même opération peut être appliquée à des objets de classes différentes : une telle opération est dite polymorphe car elle peut avoir des formes différentes pour différentes 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 cette dépendance. Les dépendances entre classes correspondent aux dépendances entre objets de ces classes. Les dépendances, comme les classes, peuvent avoir des attributs.

Un discriminateur est un attribut de type « énumération » qui montre de quelles propriétés d'objets est faite une généralisation donnée.

Le rôle définit un côté de la dépendance. Dans une dépendance binaire, deux rôles sont définis. Le nom du rôle identifie de manière unique un côté de la dépendance. Les rôles permettent d'envisager une dépendance binaire comme une relation entre un objet et un ensemble d'objets dépendants : chaque rôle est une désignation d'un objet ou d'un ensemble d'objets reliés par une dépendance à un objet à l'autre extrémité de la dépendance. Un nom de rôle peut être considéré comme un attribut dérivé dont l'ensemble de valeurs est l'ensemble des objets associés à ce rôle. Dans une dépendance binaire, une paire de noms de rôles peut être utilisée pour identifier cette dépendance.

Les noms de rôles doivent être spécifiés dans les cas où une dépendance est établie entre des objets d'une même classe. Les noms de rôle doivent être uniques car ils sont utilisés pour distinguer les objets impliqués dans la dépendance.

Un qualificatif est un attribut qui permet de réduire la multiplicité effective d'une dépendance. Les qualificateurs sont utilisés dans des dépendances un-à-plusieurs ou plusieurs-à-plusieurs.

L'agrégation est une dépendance entre une classe d'objets composites et les classes représentant les composants de ces objets (la relation « tout » - « partie »).

La généralisation et l'héritage permettent d'identifier des analogies entre différentes classes d'objets et de déterminer la classification multi-niveaux des objets. Ainsi, dans les systèmes graphiques, il peut y avoir des classes qui déterminent la représentation de diverses formes géométriques : points, lignes (lignes droites, arcs de cercle et courbes définies par des splines), polygones, cercles, etc.

Un discriminateur est un attribut de type « énumération », montrant de quelles propriétés d'objets est faite une généralisation donnée.

Il convient de noter que les classifications multi-niveaux étendues doivent être évitées car le comportement des sous-classes des niveaux inférieurs d'une classification multi-niveaux peut être difficile à comprendre : la plupart (et souvent la totalité) des attributs et opérations de ces classes sont définis dans leurs superclasses de différents niveaux. Si le nombre de niveaux de classification est devenu prohibitif, vous devez modifier légèrement la structuration du système.

La généralisation et l'héritage sont largement utilisés non seulement dans l'analyse des exigences relatives aux systèmes logiciels et à leur conception préliminaire, mais également dans leur mise en œuvre.

Il est parfois nécessaire qu'une sous-classe remplace une opération définie dans l'une de ses superclasses. Pour y parvenir, une opération qui peut être dérivée de la superclasse par héritage est également définie dans la sous-classe ; cette redéfinition "obscurcit" sa définition dans la superclasse, de sorte que l'opération remplacée dans la sous-classe, et non celle héritée, soit appliquée. Rappelons que chaque opération est définie par sa signature ; par conséquent, la signature d'un remplacement d'opération doit correspondre à la signature de l'opération dans la superclasse qui est remplacée par l'opération.

Un remplacement peut servir à l’un des objectifs suivants :

extension : la nouvelle opération étend l'opération héritée, en prenant en compte l'influence des attributs de la sous-classe ;

limitation : la nouvelle opération se limite à effectuer seulement une partie des actions de l'opération héritée, en utilisant les spécificités des objets de la sous-classe ;

optimisation : utiliser les spécificités des objets de sous-classe permet de simplifier et d'accélérer la méthode correspondante ;

commodité.

Il est conseillé de respecter les règles sémantiques d'héritage suivantes :

toutes les opérations de requête (opérations qui utilisent des valeurs d'attribut mais ne les modifient pas) doivent être héritées par toutes les sous-classes ;

toutes les opérations qui modifient les valeurs d'attribut doivent être héritées dans toutes leurs extensions ;

toutes les opérations qui modifient les valeurs des attributs restreints ou des attributs qui définissent des dépendances doivent être bloquées dans toutes leurs extensions ;

les opérations ne doivent pas être fondamentalement redéfinies ; toutes les méthodes implémentant la même opération doivent effectuer une conversion d'attribut similaire ;

Les opérations héritées peuvent être affinées en ajoutant des actions supplémentaires.

En suivant ces règles, qui sont malheureusement rarement prises en charge par les langages de programmation orientés objet, vous pouvez rendre le programme que vous développez plus compréhensible, plus facile à modifier et moins sensible à diverses erreurs et oublis.

Une classe abstraite ne peut pas avoir d'objets car elle ne définit pas d'opérations sur les objets ; les objets doivent appartenir à des sous-classes concrètes de la classe abstraite. Les classes abstraites sont utilisées pour spécifier des interfaces pour les opérations (les méthodes qui implémentent ces opérations sont ensuite définies dans les sous-classes de la classe abstraite). Les classes abstraites sont pratiques pendant la phase d'analyse des exigences du système, car elles nous permettent d'identifier des analogies dans des opérations apparemment différentes définies dans le système analysé.

L'héritage multiple permet à une classe d'avoir plus d'une superclasse, héritant des propriétés (attributs et opérations) de toutes ses superclasses. Une classe qui possède plusieurs superclasses est appelée une classe syndicale. Les propriétés d'une classe ancêtre qui apparaissent plusieurs fois dans le graphe d'héritage sont héritées dans une seule instance. Les conflits entre définitions parallèles créent des ambiguïtés qui doivent être résolues lors de la mise en œuvre. En pratique, de telles ambiguïtés ou mauvaises compréhensions doivent être évitées même lorsque le langage de programmation particulier choisi pour mettre en œuvre le système offre la possibilité de les résoudre en utilisant des priorités ou d'autres moyens.

Dans la conception orientée objet, nous traitons d’ensembles d’objets interconnectés. Chaque objet peut être traité comme une variable ou une constante de type structure (de cette manière, les méthodes décrites dans l'objet sont traitées comme des adresses de fonctions pouvant être appliquées à cet objet). Par conséquent, un ensemble d’objets est un ensemble de données interconnectées, c’est-à-dire : quelque chose de très similaire à une base de données. Par conséquent, l’application des concepts de bases de données est souvent utile dans l’analyse orientée objet et la conception orientée objet de systèmes logiciels d’application.

Les métadonnées sont des données qui décrivent d'autres données. Par exemple, la définition d'une classe est celle des métadonnées, puisque la classe décrit d'autres données - objets de cette classe. Les modèles sont des métadonnées car ils décrivent les objets modélisés. Un autre exemple de métadonnées est une classe abstraite.

Les acteurs sont des rôles joués par des entités qui interagissent directement avec le système.

Un acteur définit le rôle que joue une entité externe lorsqu'elle interagit directement avec un système donné. Il peut représenter un rôle d'utilisateur ou un rôle joué par un autre système ou élément matériel qui touche les limites du système.

J'ai beaucoup aimé la description du concept d'« acteur » dans l'ouvrage « UML 2 and the Unified Process » de Jim Arlow et Isle Neustadt : « Pour comprendre les acteurs, il est important de comprendre le concept de rôles. Un rôle peut être considéré comme un chapeau porté dans une certaine situation. » (page 92).

Lorsque les concepts de base sont connus, on peut envisager de construire le modèle lui-même

1. Construire un modèle objet

1. Définir des classes

L'analyse des exigences externes pour le système d'application conçu nous permet de déterminer les objets et les classes d'objets associés au problème d'application que ce système doit résoudre. Vous devez commencer par identifier les classes possibles à partir de l'énoncé écrit du problème appliqué (spécifications techniques et autres documents fournis par le client). Il s'agit d'une étape de développement très difficile et responsable, car le sort futur du projet en dépend en grande partie.

Lors de l'identification des classes possibles, vous devez essayer d'identifier autant de classes que possible, en notant le nom de chaque classe qui vous vient à l'esprit. En particulier, chaque nom apparaissant dans l'énoncé préliminaire du problème peut avoir une classe correspondante. Par conséquent, lors de l’identification des classes possibles, chacun de ces noms est généralement associé à une classe possible.

classes redondantes : si deux ou plusieurs classes expriment la même information, une seule d’entre elles doit être conservée ;

classes non pertinentes (non directement liées au problème) : pour chaque nom d'une classe possible, on évalue sa nécessité dans le futur système (il est souvent très difficile d'évaluer cela) ; les classes non pertinentes sont exclues ;

des classes vaguement définies (du point de vue du problème considéré) ;

attributs : certains noms correspondent davantage à des attributs qu'à des classes ; En règle générale, ces noms décrivent les propriétés des objets (par exemple, le nom, l'âge, le poids, l'adresse, etc.) ;

opérations : certains noms sont plus susceptibles d'être des noms d'opérations que des classes (par exemple, il est peu probable que appel_téléphone désigne une classe) ;

rôles : certains noms définissent des noms de rôle dans le modèle objet (par exemple, propriétaire, conducteur, patron, employé ; tous ces noms sont associés à des rôles dans diverses dépendances d'objet de la classe de personne) ;

constructions de mise en œuvre : les noms davantage associés à la programmation et au matériel informatique ne doivent pas être comparés aux classes à ce stade, car ils ne reflètent pas les caractéristiques du système d'application conçu ; exemples de tels noms : sous-programme, processus, algorithme, interruption, etc.

Après avoir éliminé les noms de toutes les classes possibles inutiles (superflues), une liste préliminaire des classes qui composent le système conçu sera obtenue.

1. Préparation du dictionnaire de données

Les mots individuels ont trop d’interprétations. Par conséquent, il est nécessaire dès le début de la conception de préparer un dictionnaire de données contenant des définitions claires et sans ambiguïté de tous les objets (classes), attributs, opérations, rôles et autres entités pris en compte dans le projet. Sans un tel dictionnaire, discuter du projet avec d’autres développeurs et clients du système n’a aucun sens, puisque chacun peut interpréter les termes abordés à sa manière.

2.3. Définir les dépendances

À l'étape suivante de la construction d'un modèle objet, les dépendances entre les classes sont déterminées. Tout d'abord, les attributs qui sont des liens explicites vers d'autres classes sont exclus des classes ; ces attributs sont remplacés par des dépendances. L'intérêt de ce remplacement est que les dépendances représentent une abstraction au même niveau que les classes, et n'ont donc pas d'impact direct sur l'implémentation future (une référence à une classe n'est qu'une façon d'implémenter des dépendances).

Tout comme les noms des classes possibles ont été obtenus à partir des noms trouvés dans l'énoncé préliminaire du problème d'application, les noms des dépendances possibles peuvent être obtenus à partir des verbes ou des phrases verbales trouvés dans le document spécifié. C'est ainsi qu'ils décrivent habituellement : la position physique (follows_behind, is_part, is_contained), l'action dirigée (leads_to_movement), la communication (talks_to), l'appartenance (has, is_part), etc.

Vous devez ensuite supprimer les dépendances inutiles ou incorrectes en utilisant les critères suivants :

les dépendances entre classes exclues doivent être éliminées, ou reformulées en fonction des classes restantes ;

Les dépendances non pertinentes et liées à la mise en œuvre doivent être éliminées ;

actions : la dépendance doit décrire les propriétés structurelles du domaine d'application, et non des événements sans importance ;

dépendances trénaires : la plupart des dépendances entre trois classes ou plus peuvent être décomposées en plusieurs dépendances binaires, en utilisant des qualificatifs si nécessaire ; dans certains cas (très rares), une telle décomposition ne peut pas être effectuée ; par exemple, la dépendance trénaire « Le professeur donne un cours dans la salle 628 » ne peut être décomposée en dépendances binaires sans perte d'information ;

dépendances dérivées : il faut exclure les dépendances qui peuvent s'exprimer à travers d'autres dépendances, car elles sont redondantes ; lorsque vous excluez les dépendances redondantes (dérivées), vous devez être particulièrement prudent, car toutes les dépendances de duplication entre classes ne sont pas redondantes ; dans certains cas, d'autres dépendances permettent d'établir seulement l'existence d'une autre dépendance dérivée, mais ne permettent pas d'établir la multiplicité de cette dépendance.

Après avoir supprimé les dépendances redondantes, vous devez clarifier la sémantique des dépendances restantes comme suit :

dépendances mal nommées : elles doivent être renommées pour que leur signification devienne claire ;

noms de rôles : vous devez ajouter des noms de rôles si nécessaire ; le nom du rôle décrit le rôle joué par la classe correspondante dans une dépendance donnée du point de vue d'une autre classe participant à cette dépendance ; si le nom du rôle est clair dans le nom de la classe, il peut être omis ;

qualificatifs : en ajoutant des qualificatifs là où cela est nécessaire, nous introduisons des éléments de contexte, ce qui permet d'obtenir une identification sans ambiguïté des objets ; les qualificatifs permettent également de simplifier certaines dépendances en réduisant leur multiplicité ;

multiplicité : il faut ajouter des désignations pour la multiplicité des dépendances ; Il ne faut pas oublier que la multiplicité des dépendances peut changer au cours du processus d'analyse plus approfondie des exigences du système ;

les dépendances non comptabilisées doivent être identifiées et ajoutées au modèle.

2.4. Affinement des attributs

A l'étape suivante, le système d'attributs est clarifié : les attributs de classe sont ajustés, de nouveaux attributs sont introduits si nécessaire. Les attributs expriment les propriétés des objets de la classe en question, ou déterminent leur état actuel.

Les attributs correspondent généralement à des noms ; par exemple, car_color (propriété de l'objet), curseur_position (état de l'objet). En règle générale, les attributs ont peu d'effet sur la structure du modèle objet.

Outre les attributs des objets, il est également nécessaire de saisir les attributs de dépendances entre classes (relations entre objets).

Lors de la spécification des attributs, ils sont guidés par les critères suivants :

Remplacement des attributs par des objets. Si la présence d'une entité est plus importante que sa valeur, alors c'est un objet ; si la valeur est plus importante, alors c'est un attribut : par exemple, un patron est un objet (peu importe qui est le patron). , l'essentiel est que quelqu'un l'est), le salaire est un attribut ( sa signification est très significative) ; la ville est toujours un objet, même si dans certains cas, il peut sembler qu'il s'agit d'un attribut (par exemple, la ville dans le cadre de l'adresse d'une entreprise) ; dans les cas où vous souhaitez que city soit un attribut, vous devez définir une dépendance (par exemple, localisée) entre les classes firm et city.

Qualifications. Si la signification d'un attribut dépend d'un contexte spécifique, il convient d'en faire un qualificatif.

Noms. Les noms correspondent généralement mieux aux qualificatifs qu'aux attributs d'objet ; dans tous les cas où un nom permet de sélectionner parmi les objets d'un certain ensemble, il doit être transformé en qualificatif.

Identifiants. Les identifiants d'objet sont associés à leur implémentation. Aux premiers stades de la conception, ils ne doivent pas être considérés comme des attributs.

Attributs des connexions. Si une propriété ne caractérise pas l'objet lui-même, mais sa relation avec un autre objet (des objets), alors il s'agit d'un attribut de connexion et non d'un attribut de l'objet.

Valeurs internes. Les attributs qui définissent uniquement l'état interne d'un objet, invisible à l'extérieur de l'objet, doivent être exclus de la considération.

Des détails sans importance. Il est recommandé d'omettre les attributs qui n'affectent pas l'exécution de la plupart des opérations.

2.5. Isolement des sous-systèmes

Un système applicatif est un ensemble d’objets interdépendants. Chaque objet est caractérisé par un ensemble d'attributs 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 tous les attributs d'objet sont privés (c'est-à-dire qu'ils ne sont pas accessibles en dehors de l'objet, et afin de connaître la valeur d'un attribut d'un autre objet dans un objet, ou de le modifier, vous devez utiliser une des opérations publiques de cet objet, si, bien entendu, une telle opération est définie). 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. L'interface d'une classe (et, par conséquent, de chaque objet de cette classe) est spécifiée par une liste de signatures de ses opérations ouvertes (publiques) (et des méthodes qui les implémentent) ; les signatures des opérations fermées ne sont pas incluses dans l'interface des objets de la classe correspondante.

etc.............

Le modèle objet d'une entreprise existante montre comment et par quels moyens les précédents sont mis en œuvre. Ce modèle révèle la structure interne d'une entreprise, à savoir : quels types de ressources sont utilisées pour mettre en œuvre les précédents et comment elles interagissent. La description du modèle objet repose sur la notion d'« objet ». Les objets représentent les participants au processus et divers types d'entités (produits finis, commande, etc.).

Objets d'interface du processus métier étudié :

• 1. Responsable du service client. Attributs : nom complet, poste, salaire. Responsabilités : interagit avec les clients, passe les commandes, accepte les paiements des clients pour les commandes.
• 2. Magasinier financièrement responsable. Attributs : nom complet, poste, salaire. Responsabilités : interagir avec les fournisseurs, accepter les matériaux et signer les factures.
• 3. Chauffeur-livreur. Attributs : nom complet, poste, salaire. Responsabilités : Livraison du produit fini au client.

Objets de contrôle du processus métier étudié :

• 1. Concepteur. Attributs : nom complet, poste, salaire. Responsabilités : conception de produits, gestion de projet, contrôle.
• 2. Opérateur de comptabilité automatisée. Attributs : nom complet, poste, salaire. Responsabilités : maintenir des enregistrements automatisés, travailler avec une base de données.
• 3. Maître meuble (Assembleur). Attributs : nom complet, poste, salaire. Responsabilités : Fabrication du produit conformément au projet.

Objets entités du processus métier étudié :

• 1. Chèque - un document émis lors du paiement de la commande.
• 2. Catalogue - un document reflétant la gamme de produits.
• 3. Bon de commande - un document qui comprend le numéro de commande, la date de commande, les informations client, le type sélectionné, le croquis du produit, les souhaits du client.
• 4. Conception de produits - conception de meubles commandés.
• 5. Demande de matériel - un document caractérisant les matériaux nécessaires et leurs volumes.
• 6. Base de données - un programme qui vous permet de conserver des enregistrements de matériaux dans une entreprise.
• 7. Matériaux - nécessaires à la fabrication d'un produit personnalisé.
• 8. Facture - un document signé lors de l'expédition des matériaux.
• 9. Le produit fini est le résultat d'une production caractérisée par son appartenance à une commande.

Le tableau 5.1 fournit une description de la relation des objets entre eux.

Tableau 5.1 Description de la manière dont les objets interagissent les uns avec les autres

	Objets de communication	Type de communication
	Client - Gestionnaire de compte	attitude de communication	Le client contacte le responsable pour passer une commande de production de meubles
	Gestionnaire - Client	attitude de communication	Le responsable met à disposition du client un catalogue de croquis de produits possibles
	Client - Catalogue	taux d'utilisation	Le client sélectionne un croquis approprié
	Client - Gestionnaire	attitude de communication	Le client exprime son choix et ses souhaits
	Gestionnaire - Client	attitude de communication	Le gérant explique les conditions et modalités
	Client - Gestionnaire	attitude de communication	Le client paie la commande
	Gestionnaire - Chèque	taux d'utilisation	Gestionnaire imprimant un chèque
	Gestionnaire - Client	attitude de communication	Le gestionnaire remet le chèque au client
	Gestionnaire - Bon de commande	taux d'utilisation	Le responsable crée un bon de commande
	Gérant - Concepteur	attitude de communication	Le responsable apporte le bon de commande au designer du service design
	Concepteur - Bon de commande	taux d'utilisation	Le créateur accepte le bon de commande
		taux d'utilisation	Le designer développe le projet
	Designer - Conception de produits	taux d'utilisation	Le concepteur évalue le projet
	Designer - Demande de matériaux	taux d'utilisation	Le designer crée une demande de matériaux
	Concepteur - Opérateur de comptabilité automatisée	attitude de communication	Le concepteur soumet une demande de matériel à l'opérateur de comptabilité automatisée
	Opérateur de comptabilité automatisée - Demande de matériel	taux d'utilisation	L'opérateur de comptabilité automatisée accepte une demande de matériaux
	Opérateur de comptabilité automatisée - Base de données	taux d'utilisation	L'opérateur de comptabilité automatisée vérifie la disponibilité des matériaux nécessaires avec les matériaux disponibles
	Magasinier financièrement responsable - Fournisseurs	attitude de communication	Un magasinier matériellement responsable commande les matériaux nécessaires auprès des fournisseurs
	Fournisseurs - Magasinier financièrement responsable	attitude de communication	Livraison des matériaux
	Magasinier financièrement responsable - Matériaux	taux d'utilisation	Réception du matériel
	Magasinier financièrement responsable - Facture	taux d'utilisation	Il signe la facture
	Magasinier financièrement responsable - Collectionneur	attitude de communication	Message sur la disponibilité des matériaux dans l'entrepôt
	Concepteur - Assembleur	attitude de communication	Transfert de la conception du produit à l'assembleur
	Assembleur - Conception de produits	taux d'utilisation	L'assembleur de meubles reçoit et étudie la conception du produit
	Assembleur - Produit fini	taux d'utilisation	L'assembleur fabrique le produit
	Assembleur - Concepteur	attitude de communication	L'assembleur appelle le designer pour contrôler la qualité du produit
	Designer - Produit fini	taux d'utilisation	Contrôle qualité des produits
	Concepteur - Assembleur	attitude de communication	Le designer donne une évaluation de la qualité du produit
	Assembleur - Produit fini	taux d'utilisation	Correction des défauts du produit fini
	Récupérateur - Chauffeur transitaire	attitude de communication	Remise du bon de commande et du produit fini au chauffeur transporteur
	Chauffeur-livreur - Client	attitude de communication	Transfert du produit fini

Remarque : Si le matériel nécessaire est en stock, les paragraphes 18, 19, 20, 21 de ce tableau sont ignorés.

Le modèle dynamique d'interaction entre les services et le client dans le précédent « Vendre un produit personnalisé » est illustré à la figure 5.1. Le modèle dynamique d'interaction entre le service, l'employé et le client dans le précédent « Commande » est présenté à la figure 5.2. Le modèle dynamique L'interaction entre le département, les employés et le client dans le précédent « Conception » est illustrée à la figure 5.3. Le modèle dynamique d'interaction des employés, dans le précédent « Fabrication » est illustré à la figure 5.4.

Figure 5.1 Diagramme de séquence du cas d'utilisation Vendre un produit personnalisé

Figure 5.2 Diagramme de séquence du cas d'utilisation « Passer une commande »

Figure 5.3 Diagramme de séquence de cas d'utilisation de conception

Figure 5.4 Diagramme de séquence du cas d'utilisation Fabrication

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 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.

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 le mieux démontrés. 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 de l'approche basée sur les objets augmente considérablement le niveau d'unification du développement et la réutilisabilité non seulement des programmes, mais également 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 se concentre sur 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. »

Bases de données. Étudiants par correspondance

Travail de laboratoire n°1

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

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.

informations générales

Construire un modèle est nécessaire afin de mieux comprendre le système en cours de développement.

La modélisation permet de résoudre les problèmes suivants :

Visualisez le système dans son état actuel ou souhaité ;

Déterminer la structure ou le comportement d'un système ;

Obtenez un modèle qui vous permet ensuite de concevoir le système ;

Documenter les décisions prises à l’aide des modèles résultants.

Classe(Classe) est une description d'une collection d'objets avec des attributs, des opérations et des relations communes. Graphiquement, une classe est représentée par un rectangle dans lequel son nom, ses attributs et ses opérations sont généralement écrits, comme le montre la Fig. 1. L'un des types de classes d'entités est acteur(Acteur). Généralement, un acteur représente le rôle joué par une personne, un périphérique matériel ou même un autre système dans un système donné. Comme le montre la fig. 2, les acteurs sont représentés comme des figures humaines.

Précédent Un cas d'utilisation est une description d'une séquence d'actions exécutées par un système qui produit un résultat observable et significatif pour un acteur spécifique. Un cas d'utilisation permet de structurer les entités comportementales d'un modèle. Graphiquement, un précédent est représenté comme une ellipse délimitée par une ligne continue, contenant généralement uniquement son nom, comme le montre la Fig. 3.

Entités comportementales sont des composants dynamiques du modèle UML. Ce sont des verbes du langage : ils décrivent le comportement du modèle dans le temps et dans l’espace. Il existe deux types d'entités comportementales :

Interaction;

Machine à états.

Interaction L'interaction est un comportement dont l'essence est l'échange de messages (Messages) entre des objets dans un contexte spécifique pour atteindre un objectif spécifique. Les messages sont affichés graphiquement sous la forme d'une flèche, au-dessus de laquelle est presque toujours écrit le nom de l'opération correspondante, comme le montre la Fig. 4.

Regroupement d'entités sont les parties organisatrices d’UML. Ce sont des blocs dans lesquels le modèle peut être décomposé. Il n’existe qu’une seule entité de regroupement, à savoir le package.

Forfaits Les packages sont un mécanisme universel pour organiser des éléments en groupes. Vous pouvez regrouper des entités structurelles, comportementales et même d'autres entités dans un package. Contrairement aux composants qui existent pendant le fonctionnement du système, les packages sont purement conceptuels, ce qui signifie qu'ils n'existent que pendant le développement. Le package est affiché sous la forme d'un dossier avec un signet contenant, en règle générale, uniquement le nom (voir Fig. 5).

Entités d'annotation– parties explicatives du modèle UML. Il s'agit de commentaires visant à fournir une description supplémentaire, des éclaircissements ou des commentaires sur tout élément du modèle. Il n'existe qu'un seul type d'élément d'annotation : Note.

Note est simplement un symbole pour représenter des commentaires ou des restrictions attachés à un élément ou un groupe d'éléments. Graphiquement, une note est représentée comme un rectangle avec un bord incurvé contenant un texte ou un commentaire graphique, comme le montre la Fig. 6.

L'UML définit quatre types de relations :

Dépendance;

Association;

Généralisation;

Mise en œuvre.

Ces relations constituent les éléments de base d’UML et sont utilisées pour créer des modèles valides.

Dépendance(Dépendance) est une relation sémantique entre deux entités, dans laquelle un changement dans l'une d'elles, indépendante, peut affecter la sémantique de l'autre, dépendante. Graphiquement, la dépendance est représentée par une ligne droite pointillée, souvent accompagnée d'une flèche (voir Fig. 7).

Association(Association) – une relation structurelle qui décrit un ensemble de connexions ; une connexion est une connexion entre des objets. Graphiquement, une association est représentée par une ligne droite (se terminant parfois par une flèche ou contenant une étiquette), à ​​côté de laquelle peuvent se trouver des symboles supplémentaires tels que la multiplicité et les noms de rôle. Sur la fig. La figure 8 montre un exemple de ce type de relation.

Un diagramme en UML est une représentation graphique d'un ensemble d'éléments, le plus souvent représenté comme un graphe connecté avec des sommets (entités) et des arêtes (relations). Des diagrammes sont dessinés pour visualiser un système sous différentes perspectives. Il existe neuf types de diagrammes en UML :

Diagrammes de classes ;

Diagrammes d'objets ;

Diagrammes de cas d'utilisation ;

Diagrammes de séquence ;

Diagrammes de coopération ;

Diagrammes d'état ;

Diagrammes d'activités ;

Diagrammes de composants ;

Diagrammes de déploiement.

Sur diagramme de classes afficher les classes, les interfaces, les objets et les collaborations, ainsi que leurs relations. Lors de la modélisation de systèmes orientés objet, ce type de diagramme est le plus souvent utilisé. Les diagrammes de classes correspondent à la vue statique du système d'un point de vue conception.

Sur diagramme de cas d'utilisation les précédents et les acteurs (cas particulier des classes) sont présentés, ainsi que les relations entre eux. Les diagrammes de cas d'utilisation font référence à une vue statique d'un système en termes de cas d'utilisation. Ils sont particulièrement importants lors de l’organisation et de la modélisation du comportement du système.

Diagrammes de séquence sont un cas particulier des diagrammes d’interaction. Sur diagrammes d'interaction les connexions entre les objets sont présentées ; montrant notamment les messages que les objets peuvent échanger. Les diagrammes d'interaction font référence à la vue dynamique du système. Les diagrammes de séquence reflètent l'ordre temporel des messages.

L'ordre des travaux sera discuté en utilisant la tâche suivante comme exemple :

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

- des informations sur les étudiants (y compris le nom complet, l'adresse du domicile, les détails du passeport, le numéro de dossier, la date de naissance, le groupe) ;

- des informations sur les spécialités (nom de la spécialité, code) ;

- informations sur les groupes (spécialité, année d'admission, numéro de groupe).

Assurer la délivrance du document « Liste de groupe » contenant les champs suivants : numéro de série, nom complet, numéro de dossier.

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. 10.

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). 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.

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 appeler le menu contextuel dessus (NewàSequence Diagram), 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.

Avec une approche orientée objet, l'analyse des exigences du système se résume à l'élaboration de modèles de ce système. Un modèle d'un système (ou de tout autre objet ou phénomène) est une description formelle d'un système qui identifie les principaux objets qui composent le système et les relations entre ces objets. La construction de modèles est un moyen répandu d’étudier des objets et des phénomènes complexes. Le modèle omet de nombreux détails qui le rendent difficile à comprendre. La modélisation est répandue tant dans la science que dans la technologie.

Les modèles aident :

Vérifier les performances du système en cours de développement dès les premières étapes de son développement ;

Communiquer avec le client du système, en clarifiant ses exigences concernant le système ;

Apporter (si nécessaire) des modifications à la conception du système (à la fois au début de sa conception et à d'autres phases de son cycle de vie).

Actuellement, il existe plusieurs technologies pour le développement orienté objet de systèmes logiciels d'application, qui reposent sur la construction et l'interprétation de modèles de ces systèmes sur un ordinateur. Ce projet utilise l'un d'entre eux - OMT (Object Modeling Techniques). De plus, un diagramme de modèle objet a été construit en UML.

Le modèle objet décrit la structure des objets qui composent le système, leurs attributs, leurs opérations et leurs relations avec d'autres objets. Le modèle objet doit refléter les concepts et objets du monde réel qui sont importants pour le système en cours de développement. Le modèle objet reflète principalement la pragmatique du système en cours de développement, qui s'exprime dans l'utilisation de la terminologie du domaine d'application associée à l'utilisation du système en cours de développement.

Définition des classes de modèle objet

L'analyse des exigences externes pour le système conçu permet de déterminer les objets et classes d'objets associés au problème appliqué que ce système doit résoudre. Toutes les classes doivent être significatives dans le domaine d'application en question ; classes associées à l'implémentation informatique, telles que liste, pile, etc. ne doit pas être administré à ce stade.

Commençons par identifier les classes possibles à partir d'un énoncé écrit d'un problème appliqué. Lors de l'identification des classes possibles, vous devez essayer d'identifier autant de classes que possible, en notant le nom de chaque classe qui vous vient à l'esprit. En particulier, chaque nom apparaissant dans l'énoncé préliminaire du problème peut avoir une classe correspondante. Par conséquent, lors de l’identification des classes possibles, chacun de ces noms est généralement associé à une classe possible.

En conséquence, nous obtenons la liste suivante de noms de classe possibles :

Un autre mandataire ;

Document;

Serveur Web distant ;

Configuration;

Informations sur le document ;

Informations sur le serveur Web distant ;

En-tête de requête ;

En-tête de réponse.