W jaki sposób metodologia obiektowa modeluje system informacyjny? [Zamknięte]

-2

Odpowiedz krótko, jak metodologia obiektowa przekształca system informacyjny.

Naprawdę nie wiem, jak odpowiedzieć na to pytanie. Wiem, co to jest system informacyjny („System zdolny do gromadzenia, przechowywania, przetwarzania i dystrybucji informacji w czasie i formie do podejmowania decyzji w organizacji”), a także czym jest metodologia obiektowa („dyscyplina związana z programowaniem”), ale ja nie wiem, jak ten ostatni modeluje pierwszy.

systems-engineering

— manooooh
źródło

Ta strona może być wnikliwa. Otwarty list do uczniów z problemami z pracą domową

— Nick Alexeev,

@NickAlexeev, czy mówisz, że to pytanie nie ma związku z tą witryną?

— manooooh,

Mówię, że to pytanie prawdopodobnie nie poleci nigdzie na StackExchange. Może z wyjątkiem niektórych pokojów rozmów.

— Nick Alexeev,

Nie wydaje mi się, aby cytowane pogrubione pytanie zostało napisane bardzo dobrze - wymaga pracy ...

— Solar Mike

Zamykanie jako „niejasne”. Społeczność chętnie pomaga w rozwiązywaniu problemów domowych, ale nie ma jej tutaj, aby odrobić pracę domową.

— GlenH7

Metodologia obiektowa pozwala na reprezentowanie systemu jako hierarchicznej struktury samodzielnych podsystemów i tworzących go podmiotów. Umożliwia to oddzielne opracowywanie i testowanie podsystemów niezależnie od siebie, dobre ponowne użycie kodu (poprzez dziedziczenie - podobne obiekty; oraz poprzez użycie bibliotek obiektów - wykorzystanie wstępnie przygotowanych obiektów przez strony trzecie) i wyodrębnienie wewnętrznych elementów podsystemów poza systemami używając ich, tworząc spójne interfejsy między nimi, łatwe do rozszerzenia, debugowania i modyfikacji.

Dla łatwej analogii: budujesz wielki system z dużych cegieł, z których każda budujesz z mniejszych cegieł, a te - jeszcze mniejsze, każda z własnymi dziwactwami i specjalnymi celami, niektóre są tylko specjalnymi wariantami innych, inne są pre -pakowane gotowe do użycia większe cegły. Wszystkie muszą dobrze pasować, ale jeśli zrobisz małą cegłę z małych cegieł i będzie ona pasować do większej cegły, możesz po prostu ponownie użyć jej wszędzie tam, gdzie jest potrzebna (a jeśli jest wadliwa, możesz wskazać usterkę i naprawić łatwo.) Gdybyś zaczął budować cały system z najmniejszych klocków od samego początku, skończyłby się bałaganem, w którym każdy segment, bez względu na to, jak powszechny, musi być wykonany od nowa od nowa, a jeśli coś jest zepsute , nie podążasz za prostą wielką cegłą; mniejsza cegła w nim, nawet mniejsza w środku,

— SF.
źródło

Dziękuję, podoba mi się przykład !! Czy możesz wyjaśnić nieco więcej zdanie „(...) i wyodrębnić elementy wewnętrzne podsystemów oprócz systemów je wykorzystujących”, proszę? Nie wiem, co w tym kontekście oznacza słowo „wewnętrzny”.

— manooooh,

@manooooh: W języku komputerowym są one nazywane „prywatnymi metodami i właściwościami” (obiektu / klasy), a nie „publicznym”. Jest „Co można zrobić za pomocą tego klocka” i „Jak ta cegła zdoła to osiągnąć”. Użytkownik nie jest zainteresowany tym ostatnim, wykorzystując całość jako narzędzie - a twórca ujawnia użytkownikowi (deklaruje jako publiczne) części, których potrzebuje użytkownik - i utrzymuje je względnie niezmienione, zachowując swobodę optymalizacji, modyfikacji lub rozszerzyć wewnętrzne funkcjonowanie - bez łamania kodu użytkownika. * warstwa abstrakcji * interfejsu publicznego

— SF.

@manooooh: Tak więc powiedzmy, system musi komunikować się z innym systemem. Istnieje więc „połączenie” klasy. Tworzysz instancję - obiekt, który pobiera parametry systemu, z którym ma się połączyć, i udostępnia metody .send () i .receive (). I tak, jako twórca systemu i użytkownik obiektu „połączenia”, przekazujesz dane tam iz powrotem przez inne systemy tylko przez te dwa systemy, nie martwiąc się o to, jaka magia kodowania, lokalizowania, poprawiania błędów transmisji itd. dalej „złącze” robi to pod maską, aby uzyskać dane tam iz powrotem.

— SF.