Związki w UML czyli abstrakcja vs rzeczywistość
|
|
- Wiktor Kaźmierczak
- 6 lat temu
- Przeglądów:
Transkrypt
1 Związki w UML czyli abstrakcja vs rzeczywistość Tym razem o kilku powszechnie popełnianych błędach w korzystaniu z UML. Chodzi o pojęcia abstrakcji, metamodeli i zależności oraz o związki między elementami na diagramach. Kluczową, moim zdaniem, przyczyną tworzenia złych modeli obiektowych jest używanie notacji UML do tworzenia modeli strukturalnych, nie mających z obiektowym paradygmatem nic wspólnego. Druga to niezrozumienie pojęcia paradygmatu obiektowego. Ogromna ilość diagramów wykonanych z użyciem symboli notacji UML, z UML i paradygmatem obiektowym ma niewiele wspólnego. Najpierw kilka definicji i pojęć. Paradygmat programowania (ang. programming paradigm) wzorzec programowania komputerów przedkładany w danym okresie rozwoju informatyki ponad inne lub ceniony w pewnych okolicznościach lub zastosowaniach. (Źródło: Paradygmat programowania Wikipedia, wolna encyklopedia) No to teraz obiektowy paradygmat: Programowanie obiektowe (ang. object-oriented programming) paradygmat programowania, w którym programy definiuje się za pomocą obiektów elementów łączących stan (czyli dane, nazywane najczęściej polami) i zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań. Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. (Źródło: Programowanie obiektowe Wikipedia, wolna encyklopedia)
2 albo: Programowanie obiektowe lub inaczej programowanie zorientowane obiektowo (ang. object-oriented programing, OOP) to paradygmat programowania przy pomocy obiektów posiadających swoje właściwości jak pola (dane, informacje o obiekcie) oraz metody (zachowanie, działania jakie wykonuje obiekt). Programowanie obiektowe polega na definiowaniu obiektów oraz wywoływaniu ich metod, tak aby współdziałały wzajemnie ze sobą. (Źródło: Programowanie obiektowe Encyklopedia Zarządzania) Słownik języka polskiego mówi: współdziałać 1. «działać wspólnie z kimś» 2. «przyczyniać się do czegoś razem z innymi czynnikami» 3. «o mechanizmach, narządach itp.: funkcjonować w powiązaniu z innymi» wywołać wywoływać 1. «wołaniem skłonić kogoś do wyjścia skądś» 2. «przypomnieć sobie lub innym coś» 3. «spowodować coś lub stać się przyczyną czegoś» 4. «oznajmić coś publicznie» 5. «oddziałać na kliszę, błonę lub papier fotograficzny środkami chemicznymi w celu uwidocznienia obrazu utajonego na materiale światłoczułym» Tak więc stwierdzenie, że obiekty z sobą współdziałają oznacza, że wywołują się wzajemnie w celu spowodowania czegoś konkretnego. Innymi słowy obiekty tworzące program (system) są od siebie wzajemnie uzależnione. Dlatego podstawowym związkiem w procesie analizy i projektowania zorientowanego obiektowo jest wzajemna zależność, nazywana w oryginalnej specyfikacji UML związkiem usługodawca-usługobiorca. Zależność Związek ten należy utożsamiać z każdą wzajemną zależnością. Z uwagi na to, że mamy wiele typów zależności, wskazujemy konkretny typ z pomocą stereotypu (<<[nazwa_typu]>>). Najczęściej występujący typ zależności to związek użycia. Oznacza on, że jeden obiekt wywołuje umiejętności (operacje) innego czyli używa go do realizacja swojego zadania. Związek taki oznaczany stereotypem <<use>>:
3 F używa (jest zależny od) E (co do zasady tu F nie jest samodzielny w tym co robi ). Formą zależności jest także dość rzadko wykorzystywana abstrakcja (<<Abstraction>>). Związek ten jest wykorzystywany do łączenia dwóch pojęć, z których jedno jest abstrakcją drugiego. Inna często wykorzystywana zależność to <<instanceof>> oznacza zależność modelu (obiektu) od jego metamodelu (klasyfikatora) a także od metametamodelu. Tak więc model oprogramowania w notacji UML z użyciem obiektowego paradygmatu powinien wyglądać mniej więcej tak: Na diagramie użyto symboli klas (graficzna reprezentacja stereotypów) zaczerpniętych wzorca architektonicznego BCE. Realizacja i kompozycja Dokumentowanie detali struktury elementów np. repozytorium, wymaga stworzenia kolejnego diagramu: modelu struktury obiektów reprezentujących np. złożoną strukturę obiektu niosącego informacje (np. z formularza). Korzystamy tu ze związku realizacja i związku kompozycja. Realizacja to związek pomiędzy specyfikacją a jej realizacją (projektem, implementacją, itp.), wskazuje zależność implementacji od jej modelu. C2 jest specyfikacją (opisem, dokumentacją) realizacji D2. Najczęściej związek ten jest stosowany pomiędzy specyfikacją interfejsu a jego implementacją a także generalnie pomiędzy abstrakcją a jej realizacją. Typowym przykładem użycia tego związku jest np. pokazanie na jednym diagramie abstrakcji bytu w repozytorium i realizacji jej struktury:
4 Na diagramie użyto także związku całość-część : linia zakończona wypełnionym rombem na jednym końcu. Romb wskazuje na całość : element nadrzędny drzewiastej struktury konstrukcji. Jest to specjalny związek oznaczający trwałe (konstrukcyjne) powiązanie pomiędzy detalami składającymi się na określoną całość. UWAGA! Nie ma on nic wspólnego z pojęciem relacji znanym z teorii relacyjnych baz danych! Biorąc pod uwagę fakt, jakim jest hermetyzacja jako cecha obiektowych konstrukcji, takie entities nie współdzielą miedzy sobą ŻADNYCH elementów (danych). Użycie na dnie bazy danych, wspólnej dla całej aplikacji, bazy doprowadzonej do tak zwanej znormalizowanej postaci, łamie wszelkie zasady obiektowych konstrukcji: łamie podstawową zasadę jaką jest hermetyzacja implementacji obiektów (zakaz jakiegokolwiek współdzielenia czegokolwiek, nie należy mylić współdzielenia z re-użyciem). Generalizacja i asocjacja Oprócz modeli struktur, powstają często modele pojęciowe. Są to odrębne diagramy. Ich celem jest dokumentowanie związków semantycznych i syntaktycznych pomiędzy kluczowymi pojęciami wykorzystywanymi w projekcie. Stanowią one nazwy obiektów i ich typy (atrybuty klas to także obiekty). Wykorzystywane są tu dwa rodzaje związków: generalizacja i asocjacja. Są to związki reprezentujące WYŁĄCZNIE logiczne powiązania pomiędzy pojęciami, nie modelują one struktur a ni implementacji! Jeżeli jakieś pojęcie ma swoje specjalizowane typy, lub z drugiej strony, grupa pojęć daje się uogólnić innym nadrzędnym pojęciem (generalizowanie), stosujemy związek generalizacji. Związek ten (korzystanie z niego) ma sens tylko gdy liczba typów to co najmniej dwa, co do zasady związek generalizacji służy do grupowania. Jeżeli pomiędzy pojęciami istnieje związek wynikający z dziedziny problemu (np. związek pomiędzy zwierzęciem a karmą dla niego) modelujemy go linią ciągłą łączącą powiązane tak pojęcia. Poniżej graficzny przykład użycia tych związków:
5 B1 i B2 to konkretne typy pojęcia A (typem jest także pojęcie). Analogicznie B12 i B22 to typy pojęcia A3. Pomiędzy pojęciami A i A3 istnieje związek logiczny (można go nazwać, wpisując te nazwę na linii). Typy mogą mieć więcej niż jeden kontekst dlatego mogą zostać pogrupowane a każda grupa otrzymuje nazwę nazwa grupy (oryg. Generalization Sets). Nie ma sensu związek generalizacji pomiędzy tylko jedną parą pojęć, bo oznacza wtedy po prostu tożsamość. Np. pojęcie województwo w Polsce ma obecnie szesnaście specjalizacji, mają one swoje nazwy, i to jest jedna grupa typów. Jednak województwa można podzielić także np. ze względu na wielkość na np. trzy grupy: małe województwo, średnie województwo i duże województwo, i to będzie druga i niezależna grupa typów. Modele Wszystkie powyższe przykłady to diagramy klas notacji UML, jednak jak widać każdy ma zupełnie inne przeznaczenie (jest modelem czego innego). Nie omawiałem tu zupełnie diagramów klas modelujących kod programów. Zaznaczę jedynie, że są to kolejne modele dokumentowane z użyciem diagramów klas notacji UML, i omówione powyżej związki dziedziczenia i asocjacje na modelach pojęciowych mają tam zupełnie inne znaczenie. Modele mogą być różne i dotyczyć różnych rzeczy (patrz Modele.). Tu chcę zwrócić uwagę na bardzo ważny aspekt: abstrakcyjne i rzeczywiste pojęcia w modelach (na diagramach). Dostrzegam ogromny bałagan nie tylko w dokumentach projektowych ale także i w literaturze, gdzie autorzy pokazują wiele różnych przykładów, które niestety są złe i pozbawione uzasadnienia. Przede wszystkim modele dzielimy, jak już wspomniałem, na pojęciowe i te modelujące jakąś określoną rzeczywistość. Modele pojęciowe to modele pokazujące pojęcia oraz semantyczne i syntaktyczne związki miedzy nimi. Modele pojęciowe służą do udokumentowania dziedzinowej taksonomii co z jednej strony pozwala utrzymać pełną jednoznaczność dokumentacji a z drugiej, na etapie implementacji, pozwala podejmować decyzje o typach danych. Służą one np. do budowania słowników i etykietowania np. pól formularzy (pole Nazwa województwa, którego zawartość będzie wybierana ze słownika zawierającego szesnaście nazw). Na tych modelach pojawiają się w zasadzie wyłącznie pojęcia stanowiące abstrakcje i typy, nie są to modele żadnego kodu, dziedziny itp. Tu przypomnę, że model dziedziny systemu to model opisujący mechanizm jego (systemu, aplikacji) działania, reprezentowany jest przez literkę M we wzorcu MVC, poważnym błędem jest uznawanie tych modeli za modele danych.
6 Modele struktury to modele opisujące określone konstrukcje, głównie na dwóch poziomach abstrakcji: jako model i jako metamodel. Z reguły, w projektach związanych z oprogramowaniem, ta konstrukcja to właśnie Model Dziedziny czyli mechanizm działania, tak zwana logika biznesowa/dziedzinowa aplikacji. Podsumowanie Tak więc nie ma czegoś takiego jak diagram klas dla projektu. Mamy dla danego projektu: model pojęciowy, modele logiki systemu, modele struktury obiektów, modele implementacji. To wszystko są diagramy klas ale każdy z nich do model czegoś innego. Paradygmat obiektowy jasno mówi: obiekty współpracują, więc standardowym związkiem w modelach logiki działania są związki użycia a nie asocjacje ani związki dziedziczenia czy kompozycji. Diagramy te nie są żadnymi modelami danych między innymi dlatego, że z zasady paradygmat obiektowy ukrywa je (hermetyzacja), na zewnątrz dostępne są wyłącznie publiczne operacje obiektów. Utrwalanie obiektów (zapis wartości atrybutów np. w bazie danych) to zadanie do rozwiązania dopiero na etapie implementacji, polegające na zagwarantowaniu zachowania stanów obiektów na czas wyłączenia zasilania, by nie uleciały z pamięci komputera, który jest środowiskiem wykonania programu. Na etapie analizy obiektowej i modelowania logiki systemu nie modelujemy żadnych danych. Poniższy przykład, jakich wiele w sieci, jest wzorcowym antyprzykładem. (źr. Pierwsza zła cecha tego diagramu to częsty błąd nazywany popularnie przeciążaniem obiektów : tu obiekt Faktura ma operacje sporządź. Klasyczny błąd architektoniczny polegający na obciążaniu obiektu cudzą odpowiedzialnością. Jeżeli klasa Faktura reprezentuje np. faktury sprzedaży, to system mający w pamięci kolekcję setek faktur i każda z kodem (ma te operację) służącym do jej sporządzenia byłby masakrą zajętości pamięci. Dodam, że model taki nie ma nic wspólnego z rzeczywistością, bo
7 faktury wystawia ktoś a nie faktura. Trzecia rzecz: faktura zakupu i faktura sprzedaży to niczym nie różniące się struktury, więc tworzenie takiego rozróżnienia jest pozbawione sensu. To błędy pojęciowe i ten diagram ma masę takich błędów. Druga wada: błędne użycie związku kompozycji: powyższy diagram należałoby interpretować jako strukturę o jednej zwartej konstrukcji, np. takiej jak samochód składający się z setek podzespołów ale stanowiący jednak jedną całość. Brak modelu pojęciowego i słownika powoduje wiele niejednoznaczności. Np. związek pomiędzy Klientem a reklamacją wskazuje, że Reklamacje są integralną częścią Klienta (tak jak koła i silnik są integralną częścią samochodu) co nawet w świetle potocznego rozumienia tych słów kłóci się ze zdrowym rozsądkiem. Użycie związków pojęciowych (asocjacja) jest zupełnie niezrozumiałe w tym przypadku. Nazwa asocjacji zawiera nie ma kierunku a więc nie wiadomo co jest zawarte w czym. Związki zależności także są niejasne: jak interpretować np. zapis mówiący, ze obiekty klasy użytkownicy zależą od obiektów klasy Raporty? Jeżeli autor miał na myśli użytkownik używa raportów to popłynął w sferę mowy potocznej, to chyba najczęściej spotykany błąd polegający na tym, że autor diagramu nadal pisze specyfikację prozą, ale z użyciem symboli (tu UML) zamiast słów. Mogę się jedynie domyślać, że autor diagramu miał w głowie model relacyjny związków encji i użył ikon z notacji UML w całkowicie innych znaczeniach niż ta notacja definiuje. Takie diagramy nie powinny powstawać, są one niestety dowodem na to, że programiści mówiący te dokumenty z UML nic nie wyjaśniają i są nieprecyzyjne, i tak musimy sami powtórzyć te analizę mają rację. Są także dowodem, że są to jednak projekty strukturalne a nie obiektowe, a użycie notacji UML polegało na skorzystaniu z zestawu ikon tak się to robi tworząc niesformalizowane schematy blokowe z użyciem np. programów do tworzenia prezentacji takich jak PowerPoint. Zapewne poza autorem tego diagram, nikt nie ma pojęcia o co w nim chodzi. Jeżeli autor miał na celu udokumentowanie modelu danych to powinien użyć notacji ERD. A tak to mamy schemat blokowy, w którym ktoś użył UML jako biblioteki symboli wprowadzając czytelnika w błąd. Z przykrością muszę przyznać, że od takich błędów nie są wolne także niektóre podręczniki i materiały szkoleniowe a także dokumenty tworzone przez pracowników wielu firm na rynku IT. P.S. Na przykłady poprawnych diagramów z uzasadnieniem zapraszam do mojej książki i na moje szkolenia i warsztaty. Specyfikacja UML v.2.5 Niestety sprawne korzystanie z takich specyfikacji wymaga umiejętności czytania modeli pojęciowych (diagramów klas UML) opisujacych syntaktykę (syntax) jak wyżej (ich tworzenie też do łatwych nie należy ). Przytaczam to jako źródło tego o czym tu pisałem. W UML wszystko jest klasą (klasyfikatorem), związki między elementami diagramów także. Zostało to pokazane w specyfikacji UML v.2.5.:
8
9
10
Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki
Dariusz Brzeziński Politechnika Poznańska, Instytut Informatyki Object-oriented programming Najpopularniejszy obecnie styl (paradygmat) programowania Rozwinięcie koncepcji programowania strukturalnego
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoPodstawy Programowania Obiektowego
Podstawy Programowania Obiektowego Wprowadzenie do programowania obiektowego. Pojęcie struktury i klasy. Spotkanie 03 Dr inż. Dariusz JĘDRZEJCZYK Tematyka wykładu Idea programowania obiektowego Definicja
Bardziej szczegółowoProgramowanie współbieżne Wykład 8 Podstawy programowania obiektowego. Iwona Kochaoska
Programowanie współbieżne Wykład 8 Podstawy programowania obiektowego Iwona Kochaoska Programowanie Obiektowe Programowanie obiektowe (ang. object-oriented programming) - metodyka tworzenia programów komputerowych,
Bardziej szczegółowoProgramowanie obiektowe - 1.
Programowanie obiektowe - 1 Mariusz.Masewicz@cs.put.poznan.pl Programowanie obiektowe Programowanie obiektowe (ang. object-oriented programming) to metodologia tworzenia programów komputerowych, która
Bardziej szczegółowoModelowanie i Programowanie Obiektowe
Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do
Bardziej szczegółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej
Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoPaweł Kurzawa, Delfina Kongo
Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management
Bardziej szczegółowoModelowanie danych, projektowanie systemu informatycznego
Modelowanie danych, projektowanie systemu informatycznego Modelowanie odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym Modele - konceptualne reprezentacja obiektów w uniwersalnym
Bardziej szczegółowoTechnologie i usługi internetowe cz. 2
Technologie i usługi internetowe cz. 2 Katedra Analizy Nieliniowej, WMiI UŁ Łódź, 15 luty 2014 r. 1 Programowanie obiektowe Programowanie obiektowe (z ang. object-oriented programming), to paradygmat programowania,
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoDiagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com
Diagramy klas dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com O czym będzie? Notacja Ujęcie w różnych perspektywach Prezentacja atrybutów Operacje i metody Zależności Klasy aktywne,
Bardziej szczegółowoProjektowanie logiki aplikacji
Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie logiki aplikacji Zagadnienia Rozproszone przetwarzanie obiektowe (DOC) Model klas w projektowaniu logiki aplikacji Klasy encyjne a klasy
Bardziej szczegółowoJęzyk programowania. Andrzej Bobyk http://www.alfabeta.lublin.pl. www.alfabeta.lublin.pl/jp/
Język programowania Andrzej Bobyk http://www.alfabeta.lublin.pl www.alfabeta.lublin.pl/jp/ Literatura K. Reisdorph: Delphi 6 dla każdego. Helion, Gliwice 2001 A. Grażyński, Z. Zarzycki: Delphi 7 dla każdego.
Bardziej szczegółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoProgramowanie w Javie 1 Wykład i Ćwiczenia 3 Programowanie obiektowe w Javie cd. Płock, 16 października 2013 r.
Programowanie w Javie 1 Wykład i Ćwiczenia 3 Programowanie obiektowe w Javie cd. Płock, 16 października 2013 r. Programowanie obiektowe Programowanie obiektowe (z ang. object-oriented programming), to
Bardziej szczegółowoModelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig
Modelowanie Obiektowe Wykład 1: Wprowadzenie do Modelowania i języka UML Anna Kulig Wprowadzenie do modelowania Zasady Pojęcia Wprowadzenie do języka UML Plan wykładu Model jest uproszczeniem rzeczywistości.
Bardziej szczegółowoWstęp [2/2] Wbrew częstemu przekonaniu, nie są one gotowymi rozwiązaniami, to tylko półprodukty rozwiązania.
Adrian Skalczuk Szymon Kosarzycki Spis Treści Wstęp [1/2] Wzorce projektowe są nieodłącznym przyjacielem programisty pozwalają pisać czystszy kod, łatwiejszy do zrozumienia przez innych i zapewniają pewien
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoInżynieria oprogramowania. Część 5: UML Diagramy klas
UNIWERSYTET RZESZOWSKI KATEDRA INFORMATYKI Opracował: mgr inż. Przemysław Pardel v1.01 2010 Inżynieria oprogramowania Część 5: UML Diagramy klas ZAGADNIENIA DO ZREALIZOWANIA (3H) 1. Diagram klas... 3 Zadanie
Bardziej szczegółowo1 Projektowanie systemu informatycznego
Plan wykładu Spis treści 1 Projektowanie systemu informatycznego 1 2 Modelowanie pojęciowe 4 2.1 Encja....................................... 5 2.2 Własności.................................... 6 2.3 Związki.....................................
Bardziej szczegółowoDiagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.
Umiejętność czytania oraz tworzenia diagramów klas UML jest podstawą w przypadku zawodu programisty. Z takimi diagramami będziesz spotykał się w przeciągu całej swojej kariery. Diagramy klas UML są zawsze
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoproblem w określonym kontekście siły istotę jego rozwiązania
Wzorzec projektowy Christopher Alexander: Wzorzec to sprawdzona koncepcja, która opisuje problem powtarzający się wielokrotnie w określonym kontekście, działające na niego siły, oraz podaje istotę jego
Bardziej szczegółowoZARZĄDZANIU. Wykład VI. dr Jan Kazimirski
INFORMATYKA W ZARZĄDZANIU Wykład VI dr Jan Kazimirski jankazim@mac.edu.pl http://www.mac.edu.pl/jankazim MODELOWANIE SYSTEMÓW UML Literatura Joseph Schmuller UML dla każdego, Helion 2001 Perdita Stevens
Bardziej szczegółowoSpis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania...
Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników Spis treúci Wstęp... 11 Podziękowania... 13 O autorach... 15 Robert A. Maksimchuk... 15 Eric J. Naiburg... 15 Przedmowa...
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoZofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1
Charakterystyka oprogramowania obiektowego 1. Definicja systemu informatycznego 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wymagania 4. Problemy z podejściem nieobiektowym
Bardziej szczegółowoINFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji
Modelowanie danych. Model związków-encji Plan wykładu Wprowadzenie do modelowania i projektowania kartograficznych systemów informatycznych Model związków-encji encje atrybuty encji związki pomiędzy encjami
Bardziej szczegółowoPodstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Bardziej szczegółowoRysunek 1: Przykłady graficznej prezentacji klas.
4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez
Bardziej szczegółowoProgramowanie obiektowe
Laboratorium z przedmiotu Programowanie obiektowe - zestaw 03 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas abstrakcyjnych i interfejsów. Wprowadzenie
Bardziej szczegółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 8 Diagram pakietów I Diagram pakietów (ang. package diagram) jest diagramem
Bardziej szczegółowoProgramowanie obiektowe
Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.
Bardziej szczegółowoTechnologie obiektowe
WYKŁAD dr inż. Paweł Jarosz Instytut Informatyki Politechnika Krakowska mail: pjarosz@pk.edu.pl LABORATORIUM dr inż. Paweł Jarosz (3 grupy) mgr inż. Piotr Szuster (3 grupy) warunki zaliczenia Obecność
Bardziej szczegółowoPodstawy programowania. Wykład PASCAL. Wstęp do programowania obiektowego. dr Artur Bartoszewski - Podstawy programowania, sem.
Podstawy programowania Wykład PASCAL Wstęp do programowania obiektowego 1 Programowanie obiektowe - definicja Programowanie obiektowe paradygmat programowania, w którym programy definiuje się za pomocą
Bardziej szczegółowoTechnologie informacyjne - wykład 12 -
Zakład Fizyki Budowli i Komputerowych Metod Projektowania Instytut Budownictwa Wydział Budownictwa Lądowego i Wodnego Politechnika Wrocławska Technologie informacyjne - wykład 12 - Prowadzący: Dmochowski
Bardziej szczegółowoNIFIED M L ODELLING ANGUAGE. Diagramy czynności
U M L NIFIED ODELLING ANGUAGE Diagramy czynności 1 Czym jest diagram czynności? Jeden z pięciu rodzajów diagramów UML służących do modelowania dynamicznych aspektów systemu. Przedstawia przepływ sterowania
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
Bardziej szczegółowoPodstawy projektowania systemów komputerowych
Podstawy projektowania systemów komputerowych Diagramy klas UML 1 Widok logiczny Widok logiczny Widok fizyczny Widok przypadków użycia Widok procesu Widok konstrukcji Używany do modelowania części systemu
Bardziej szczegółowoJarosław Żeliński analityk biznesowy, projektant systemów
Trendy w architekturze oprogramowania zarządzającego procesami biznesowymi i przepływem pracy - dedykowane czy standardowe? Jarosław Żeliński analityk biznesowy, projektant systemów O mnie Od 1991 roku
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Bardziej szczegółowoMariusz Trzaska Modelowanie i implementacja systemów informatycznych
Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Notka biograficzna Dr inż. Mariusz Trzaska jest adiunktem w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zajmuje się
Bardziej szczegółowoWPROWADZENIE DO UML-a
WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoPodstawy Języka Java
Podstawy Języka Java Programowanie obiektowe Programowanie obiektowe (z ang. object-oriented programming), to paradygmat programowania, w którym programy definiuje się za pomocą obiektów elementów łączących
Bardziej szczegółowoJęzyk JAVA podstawy. Wykład 4, część 1. Jacek Rumiński. Politechnika Gdańska, Inżynieria Biomedyczna
Język JAVA podstawy Wykład 4, część 1 1 Język JAVA podstawy Plan wykładu: 1. Podstawy modelowania obiektowego 2. Konstruktory 3. Dziedziczenie, związki pomiędzy klasami, UML 4. Polimorfizm 5. Klasy abstrakcyjne
Bardziej szczegółowoBaza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego
PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga
Bardziej szczegółowoInformatyka I stopień (I stopień / II stopień) Ogólnoakademicki (ogólno akademicki / praktyczny) stacjonarne (stacjonarne / niestacjonarne)
Załącznik nr 7 do Zarządzenia Rektora nr 10/12 z dnia 21 lutego 2012r. KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Programowanie obiektowe (Java) Nazwa modułu w języku angielskim Object oriented
Bardziej szczegółowoProgramowanie obiektowe
Laboratorium z przedmiotu - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia. Wprowadzenie teoretyczne.
Bardziej szczegółowoKARTA PRZEDMIOTU. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI Ogólne umiejętności posługiwania się komputerem
WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Zał. nr 4 do ZW 33/01 KARTA PRZEDMIOTU Nazwa w języku polskim: Nazwa w języku angielskim: Kierunek studiów (jeśli dotyczy): Specjalność (jeśli dotyczy): Stopień studiów
Bardziej szczegółowoPodstawy inżynierii oprogramowania
Podstawy inżynierii oprogramowania Modelowanie. Podstawy notacji UML Aleksander Lamża ZKSB Instytut Informatyki Uniwersytet Śląski w Katowicach aleksander.lamza@us.edu.pl Zawartość Czym jest UML? Wybrane
Bardziej szczegółowoWykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych
Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław
Bardziej szczegółowoProjektowanie Graficznych Interfejsów Użytkownika Robert Szmurło
Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło LATO 2007 Projektowanie Graficznych Interfejsów Użytkownika 1 UCD - User Centered Design 1) User Centered Design Projekt Skoncentrowany
Bardziej szczegółowoModelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014
Modelowanie diagramów klas w języku UML Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Czym jest UML - Unified Modeling Language - Rodzina języków modelowania graficznego - Powstanie na przełomie lat 80
Bardziej szczegółowoPodstawy Programowania Programowanie Obiektowe
Podstawy Programowania Programowanie Obiektowe Michał Bujacz bujaczm@p.lodz.pl B9 Lodex 207 godziny przyjęć: środy i czwartki 10:00-11:00 http://www.eletel.p.lodz.pl/bujacz/ 1 Pytania powtarzające x &
Bardziej szczegółowoZofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2
Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów
Bardziej szczegółowoBazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Bazy danych Wykład 3: Model związków encji. dr inż. Magdalena Krakowiak makrakowiak@wi.zut.edu.pl Co to jest model związków encji? Model związków
Bardziej szczegółowoObiekt klasy jest definiowany poprzez jej składniki. Składnikami są różne zmienne oraz funkcje. Składniki opisują rzeczywisty stan obiektu.
Zrozumienie funkcji danych statycznych jest podstawą programowania obiektowego. W niniejszym artykule opiszę zasadę tworzenia klas statycznych w C#. Oprócz tego dowiesz się czym są statyczne pola i metody
Bardziej szczegółowoBaza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego
PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga
Bardziej szczegółowoTechnologia informacyjna
Technologia informacyjna Pracownia nr 9 (studia stacjonarne) - 05.12.2008 - Rok akademicki 2008/2009 2/16 Bazy danych - Plan zajęć Podstawowe pojęcia: baza danych, system zarządzania bazą danych tabela,
Bardziej szczegółowoBPM vs. Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów
BPM vs. Content Management Jarosław Żeliński analityk biznesowy, projektant systemów Cel prezentacji Celem prezentacji jest zwrócenie uwagi na istotne różnice pomiędzy tym co nazywamy: zarzadzaniem dokumentami,
Bardziej szczegółowoLK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika
LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika Prowadzący: Dr inż. Jacek Habel Instytut Technologii Maszyn i Automatyzacji Produkcji Zakład Projektowania Procesów
Bardziej szczegółowoTutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.
AGH, EAIE, Informatyka Winda - tutorial Systemy czasu rzeczywistego Mirosław Jedynak, Adam Łączyński Spis treści 1 Wstęp... 2 2 Przypadki użycia (Use Case)... 2 3 Diagramy modelu (Object Model Diagram)...
Bardziej szczegółowoProgramowanie obiektowe
Laboratorium z przedmiotu - zestaw 03 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas abstrakcyjnych i interfejsów. Wprowadzenie teoretyczne. Rozważana
Bardziej szczegółowoRozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II
Zespół TI Instytut Informatyki Uniwersytet Wrocławski ti@ii.uni.wroc.pl http://www.wsip.com.pl/serwisy/ti/ Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II Rozkład wymagający
Bardziej szczegółowoTemat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych
PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych
Bardziej szczegółowoProjektowanie Zorientowane na Dziedzinę. ang. Domain Driven Design
Projektowanie Zorientowane na Dziedzinę ang. Domain Driven Design 2 Projektowanie Stan posiadania Przypadki użycia Model dziedziny Operacje systemowe Kontrakty dla operacji systemowych Problemy do rozwiązania
Bardziej szczegółowoInformacje ogólne. Karol Trybulec p-programowanie.pl 1. 2 // cialo klasy. class osoba { string imie; string nazwisko; int wiek; int wzrost;
Klasy w C++ są bardzo ważnym narzędziem w rękach programisty. Klasy są fundamentem programowania obiektowego. Z pomocą klas będziesz mógł tworzyć lepszy kod, a co najważniejsze będzie on bardzo dobrze
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoModelowanie obiektowe
Modelowanie obiektowe ZPO 2018/2019 Dr inż. W. Cichalewski Materiały wykonane przez W. Tylman Diagramy klas Diagramy klas Zawiera informacje o statycznych związkach między elementami (klasami) Są ściśle
Bardziej szczegółowoPodstawy modelowania programów Kod przedmiotu
Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 8: Przypisywanie obiektom odpowiedzialności (2)
Analiza i projektowanie obiektowe 2016/2017 Wykład 8: Przypisywanie obiektom odpowiedzialności (2) Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Wzorce
Bardziej szczegółowoAnaliza i projektowanie aplikacji Java
Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie
Bardziej szczegółowo12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:
Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 1) Oprogramowanie to: 2) Produkty oprogramowania w inżynierii oprogramowania można podzielić na: 3) W procesie wytwarzania oprogramowania
Bardziej szczegółowoEncje w Drupalu. Tworzenie własnych encji i ich wpływ na poprawę wydajności
Encje w Drupalu Tworzenie własnych encji i ich wpływ na poprawę wydajności DrupalCamp Wrocław 2015 Grzegorz Bartman https://twitter.com/grzegorzbartman O mnie Grzegorz Bartman http://twitter.com/grzegorzbartman
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoRozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja I
Zespół TI Instytut Informatyki Uniwersytet Wrocławski ti@ii.uni.wroc.pl http://www.wsip.com.pl/serwisy/ti/ Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja I Rozkład zgodny
Bardziej szczegółowoFaza analizy (modelowania) Faza projektowania
Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH
KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków
Bardziej szczegółowoUML a kod w C++ i Javie. Przypadki użycia. Diagramy klas. Klasy użytkowników i wykorzystywane funkcje. Związki pomiędzy przypadkami.
UML a kod w C++ i Javie Projektowanie oprogramowania Dokumentowanie oprogramowania Diagramy przypadków użycia Przewoznik Zarzadzanie pojazdami Optymalizacja Uzytkownik Wydawanie opinii Zarzadzanie uzytkownikami
Bardziej szczegółowo030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła
030 PROJEKTOWANIE BAZ DANYCH Prof. dr hab. Marek Wisła Elementy procesu projektowania bazy danych Badanie zależności funkcyjnych Normalizacja Projektowanie bazy danych Model ER, diagramy ERD Encje, atrybuty,
Bardziej szczegółowoSCENARIUSZ LEKCJI. Streszczenie. Czas realizacji. Podstawa programowa
Autorzy scenariusza: SCENARIUSZ LEKCJI OPRACOWANY W RAMACH PROJEKTU: INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA. PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH
Bardziej szczegółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowo1. Które składowe klasa posiada zawsze, niezależnie od tego czy je zdefiniujemy, czy nie?
1. Które składowe klasa posiada zawsze, niezależnie od tego czy je zdefiniujemy, czy nie? a) konstruktor b) referencje c) destruktor d) typy 2. Które z poniższych wyrażeń są poprawne dla klasy o nazwie
Bardziej szczegółowoLaboratorium z przedmiotu: Inżynieria Oprogramowania INP
Laboratoria 5-7- część 1 Identyfikacja klas reprezentujących logikę biznesową projektowanego oprogramowania, definicja atrybutów i operacji klas oraz związków między klasami - na podstawie analizy scenariuszy
Bardziej szczegółowoUML cz. II. UML cz. II 1/38
UML cz. II UML cz. II 1/38 UML cz. II 2/38 Klasy Najważniejsze informacje o klasie: różnica pomiędzy klasą a jej instancją (obiektem) na podstawie klasy tworzone są obiekty (instancje klasy) stan obiektu
Bardziej szczegółowoCel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Bardziej szczegółowoWykład I. Wprowadzenie do baz danych
Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles
Bardziej szczegółowoMetodyki i techniki programowania
Metodyki i techniki programowania dr inż. Maciej Kusy Katedra Podstaw Elektroniki Wydział Elektrotechniki i Informatyki Politechnika Rzeszowska Elektronika i Telekomunikacja, sem. 2 Plan wykładu Sprawy
Bardziej szczegółowoAnaliza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
Bardziej szczegółowoWprowadzenie do systemów informacyjnych
Uwagi ogólne: Wprowadzenie do systemów informacyjnych Projektowanie obiektowe Obiektowość jest nową ideologią, która zmienia myślenie realizatorów SI z zorientowanego na maszynę na zorientowane na człowieka.
Bardziej szczegółowoLaboratorium nr 12. Temat: Struktury, klasy. Zakres laboratorium:
Zakres laboratorium: definiowanie struktur terminologia obiektowa definiowanie klas funkcje składowe klas programy złożone z wielu plików zadania laboratoryjne Laboratorium nr 12 Temat: Struktury, klasy.
Bardziej szczegółowo10. Programowanie obiektowe w PHP5
Ogólnie definicja klasy wygląda jak w C++. Oczywiście elementy składowe klasy są zmiennymi PHP, stąd nieśmiertelne $. Warto zauważyć, że mogą one mieć wartość HHH mgr inż. Grzegorz Kraszewski TECHNOLOGIE
Bardziej szczegółowoCharakterystyka oprogramowania obiektowego
Charakterystyka oprogramowania obiektowego 1. Definicja systemu informatycznego 2. Model procesu wytwarzania oprogramowania - model cyklu Ŝycia oprogramowania 3. Wymagania 4. Problemy z podejściem nieobiektowym
Bardziej szczegółowoProcesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Bardziej szczegółowo