De quelle manière la méthodologie orientée objet modélise-t-elle un système d'information? [fermé]

-2

Répondez brièvement à la façon dont la méthodologie orientée objet transforme un système d’information.

Je ne sais vraiment pas comment répondre à cette question. Je sais ce qu’est un système d’information ("Système capable de collecter, de stocker, de traiter et de distribuer des informations à temps et sous forme décisionnelle au sein d’une organisation") et aussi Je ne sais pas comment ce dernier modélise le premier.

systems-engineering

— manooooh
source

Vous pourriez trouver cette page perspicace Lettre ouverte aux étudiants ayant des problèmes de devoirs

— Nick Alexeev

@ NickAlexeev êtes-vous en train de dire que cette question n'a aucun lien avec ce site?

— manooooh

Je dis que cette question ne volera probablement nulle part sur StackExchange. Sauf quelques bavardoirs, peut-être.

— Nick Alexeev

Je ne pense pas que la question citée, en gras, soit en fait très bien écrite - il faut travailler ...

— Solar Mike

Fermeture comme "pas claire". La communauté est disposée à aider avec les problèmes de devoirs, mais n'est pas là pour le faire pour vous

— GlenH7

La méthodologie orientée objet permet de représenter le système en tant que structure hiérarchique de sous-systèmes autonomes et d'entités le composant. Cela permet de développer et de tester séparément les sous-systèmes les uns des autres, de bien réutiliser le code (par héritage - objets similaires; et par le biais de bibliothèques d'objets - utilisation d'objets prédéfinis par des tiers) et par la synthèse des éléments internes des sous-systèmes en les utilisant, en créant des interfaces cohérentes entre elles, faciles à étendre, à déboguer et à modifier.

Pour une analogie facile: vous construisez le grand système à partir de grosses briques, chacune d’elles étant de petites briques, et celles-ci - encore plus petites, chacune avec ses propres bizarreries et ses buts spéciaux, certaines étant juste des variantes spéciales d’autres, grandes briques prêtes à l'emploi emballées. Ils doivent tous être parfaitement ajustés, mais si vous fabriquez une petite brique à partir de briques minuscules et que celle-ci s’adapte parfaitement à la plus grosse Si vous aviez commencé à construire le système entier à partir des plus petites briques du début, vous vous retrouveriez avec un désordre où chaque segment, peu importe sa fréquence habituelle, doit être refait à zéro, et si quelque chose est cassé , vous ne suivez pas la simple chaîne grosse brique; une brique plus petite à l'intérieur, encore plus petite à l'intérieur, la plus petite - vous devez suivre toutes les centaines de petites briques du haut au défectueux en passant par le bordel.

— SF.
source

Merci, j'aime bien l'exemple !! Pourriez-vous expliquer un peu plus la phrase "(...) et résumer les composants internes des sous-systèmes en dehors des systèmes qui les utilisent" Je ne sais pas ce que le mot "interne" signifie dans ce contexte.

— manooooh

@manooooh: Dans le jargon informatique, on les appelle "méthodes et propriétés privées" (d'un objet / classe), par opposition à "publiques". Il y a "Que peut-on faire en utilisant cette brique" et "comment cette brique parvient-elle à atteindre cet objectif". L'utilisateur n'est pas intéressé par ce dernier, il utilise l'ensemble comme un outil - et le créateur n'expose à l'utilisateur que (déclare comme public) les parties dont l'utilisateur a besoin - et les maintient relativement inchangées, tout en conservant la liberté d'optimiser, de modifier ou de modifier. étendre le fonctionnement interne - sans casser le code de l'utilisateur. * couche d'abstraction * de l'interface publique

— SF.

@manooooh: Le système doit donc communiquer avec un autre système. Donc, il y a une «connexion» de classe. Vous créez une instance - un objet, qui prend les paramètres du système avec lequel il doit se connecter et expose les méthodes .send () et .receive (). Et ainsi, en tant qu’écrivain du système et utilisateur de l’objet 'connexion', vous ne faites que transmettre des données avec les autres systèmes par l’intermédiaire de ces deux systèmes, sans vous soucier de la magie du codage, de la localisation, de la correction des erreurs de transmission, etc. Ensuite, le «connecteur» fait sous le capot pour obtenir les données aller et retour.

— SF.