Egzamin 2018, pytania i odpowiedzi PDF

Preview

Summary

Download Egzamin 2018, pytania i odpowiedzi PDF

Description

Legenda: Termin I (wiki) Termin I (fejs) Termin II (2016) Termin II (2013) Termin III

Legenda: CZERWONYM zaznaczone są pytania które się powtórzyły w dwóch lub więcej egzaminach. I z tego co widzę to sporo materiału można wyciągnąć z: http://wazniak.mimuw.edu.pl/index.php?title=Strona_główna , tylko z przekopaniem się przez to może być problem :D

Termin I (wiki) 1. Czym różni się nowoczesna analiza systemu informatycznego (Yourdona) od klasycznej (DeMarco)? 2. Porównać modele życia systemu informatycznego: Boehm’a i Fry’ego. ●

Model Fry'ego (model systemów baz danych) Etapy 1. Faza projektowania: 1.1 Sformułowanie zagadnienia i analiza potrzeb - zabranie potrzeb informacyjnych użytkowników. 1.2 Modelowanie logiczne (konceptualne) - opis modelu danych i przyszłych procesów w systemie. 1.3 Projektowanie fizyczne - projekt struktury zbiorów, wzorców dokumentów, technologii przetwarzania, specyfikacji wewn.

2 .Faza eksploatacji: 2.1 Programowanie i Wdrożenie - stworzenie bazy danych i oprogramowanie zastosowań. 2.2 Eksploatacja i kontrola. 2.3 Modyfikacja i adaptacja - udoskonalenie funkcjonowania w wyniku pojawiających się nowych potrzeb. ●

Model Boehm'a (model spiralny) Każda pętla spirali podzielona jest na cztery sektory: 1. Ustalanie celów(Planowanie) - Definiowanie konkretnych celów wymaganych w tej fazie przedsięwzięcia. Identyfikacja ograniczeń i zagrożeń. Ustalanie planów realizacji. 2. Rozpoznanie i redukcja zagrożeń(Analiza ryzyka) - Przeprowadzenie szczegółowej analizy rozpoznanych zagrożeń, ich źródeł i sposobów zapobiegania. Podejmuje się odpowiednie kroki zapobiegawcze. 3. Tworzenie i zatwierdzanie(Konstruowanie) - Tworzenia oprogramowania w oparciu o najbardziej odpowiedni model, wybrany na podstawie oceny zagrożeń. 4. Ocena i planowanie(Weryfikacja) - Recenzja postępu prac i planowanie

Źródło: 3. Podać schemat procesu inżynierii wymagań.

Źródło: https://www.google.pl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=0ahUKEwiE6u6l7DRAhXK1SwKHTkCASgQFggjMAE&url=http%3A%2F%2Fwww.inmost.org.pl%2Farticles%2 FWprowadzenie_do_inAynierii_wymagaA&usg=AFQjCNGQMI40TOwf9yMXB57qBuvErqpxf Q&sig2=s5wRlGBJffRaRD1NiNyB8A 4. Co obejmuje kontekst planowania biznesowego w projekcie informatycznym. 5. Zdefiniować walidacje i weryfikacje dla projektowania systemu informatycznego. Weryfikację , czyli postrzeganie, można sprowadzić do odpowiedzi na pytanie: „Czy produkt tworzony jest prawidłowo?”, a z kolei walidację : „Czy tworzony produkt jest prawidłowy?”. Prawidłowo – to znaczy zgodnie z wytycznymi programowania, z zastosowaniem odpowiednich metod, języka programowania i algorytmów. Weryfikacja dokonywana jest podczas testów systemowych pojedynczego produktu, oraz testów integracyjnych, po wprowadzeniu produktu do istniejącego już i działającego środowiska informatycznego[3]. Weryfikację można wykonywać na dwa sposoby – statyczny i dynamiczny. Weryfikacja dynamiczna przeprowadzana jest już po uruchomieniu programu, z użyciem danych testowych, i kontroluje zachowanie systemu widoczne dla użytkownika. https://pl.wikipedia.org/wiki/Weryfikacja_i_walidacja_(oprogramowanie) 6. Zdefiniować i omówić pojęcia UML: behavioral feature, forward engineering, risk-driven, tagged value, stereotype. -

forward engineering - tworzenie kodu na podstawie diagramów UML - Forward engineering is the process of transforming a model into code through a mapping to an implementation language. Forward engineering results in a loss of information, because models written in the UML are semantically richer than any current object-oriented programming language. In fact, this is a major reason why you need models in addition to code. Structural features, such as collaborations, and behavioral features, behavioral feature - inaczej mówiąc -

funkcje obiektów. A  b  ehavioral feature is a feature of a classifier that specifies an aspect of the b  ehavior of its instances. A behavioral feature specifies that an instance of a classifier will respond to specific requests by invoking behavior. An operation is an example of b  ehavioral feature . -

such as interactions, can be visualized clearly in the UML, but not so clearly from raw code. To forward engineer a class diagram,

-

-

-

-

-

Identify the rules for mapping to your implementation language or languages of choice. This is something you'll want to do for your project or your organization as a whole. Depending on the semantics of the languages you choose, you may want to constrain your use of certain UML features. For example, the UML permits you to model multiple inheritance, but Smalltalk permits only single inheritance. You can choose to prohibit developers from modeling with multiple inheritance (which makes your models language-dependent), or you can develop idioms that transform these richer features into the implementation language (which makes the mapping more complex). Use tagged values to guide implementation choices in your target language. You can do this at the level of individual classes if you need precise control. You can also do so at a higher level, such as with collaborations or packages. Use tools to generate code. http://umlguide2.uw.hu/ch08lev1sec3.html

risk-driven tagged value - nieużywane w UML 2.X - przykładowa wartość przypisana do danego pola w klasie? stereotype - S  tereotypy - wykorzystywane przede wszystkim do meta-klasyfikacji elementów modelu - ułatwiają wprowadzanie nowego rodzaju elementów modelu do diagramów, co w konsekwencji skutkuje podniesieniem ich czytelności i zwięzłości. Standard UML definiuje pewną liczbę stereotypów dla elementów różnych diagramów (np. stereotypy «include» i «extend» stosowane na diagramach przypadków użycia), dopuszczając - zgodnie z ideą mechanizmów rozszerzalności - możliwość wprowadzenia przez analityka w razie potrzeby nowych stereotypów. h  ttp://edu.pjwstk.edu.pl/wyklady/pri/scb/index141.html http://edu.pjwstk.edu.pl/wyklady/pri/scb/index142.html

7. Opisać perspektywę projektową, przypadków użycia i wdrożeniową dla modelowania architektury. Jakie jeszcze inne perspektywy są realizowane w tym modelowaniu? 8. Podać charakter powiązań pomiędzy obiektami w diagramach ERD. 9. Podać klasy i atrybuty obiektów w kontekście pomiarów oprogramowania. 10. Omówić punkty funkcyjne Albrechta. Punkt funkcyjny – metryka złożoności o programowania podawana jako liczba bezwymiarowa określająca efektywną względną miarę wartości funkcji oferowanej przez program użytkownikowi. Najczęściej jest podstawą do oszacowania m.in. pracochłonności wytworzenia danego oprogramowania. Pojęcie to zaproponował w 1979 r. A. J. Albrecht z firmy IBM[1]. Metoda punktów funkcyjnych jest aktualnie jednym z popularnych sposobów szacowania miary zastosowania programów. System został stworzony przez pracownika IBM, który zdefiniował go i opracował wraz z kolegami w latach siedemdziesiątych. IBM zrzekł się wyłączności, dzięki czemu dostęp do niego został umożliwiony dla każdego. W wyniku tego działania powołano w USA organizację zwaną the International Function Point Users Group – IFPUG, która zajmuje się rozwojem, rozpowszechnianiem i standaryzacją systemu FPA[2]. Zasada działania metody punktów funkcyjnych polega na wydzieleniu w programie pięciu typów: wejściowego, wyjściowego, logicznego typu wejściowego, zewnętrznego typu interfejsów oraz zewnętrznego typu zapytań- następnie na przydzielaniu im złożoności oraz przypisaniu

odpowiedniej liczby punktów funkcyjnych. FPA umożliwia szacowanie wartości funkcyjnej programu niezależnie od stosowanego języka oprogramowania w którym aplikacja została napisana. Pozwala to na e  fektywne zarządzanie projektami programistycznymi oraz związanymi z nimi kosztami. Punkty funkcyjne liczy się dla trzech różnych typów: 1. Dla projektów w fazie planowania- wszelkich ocen dokonuje się na podstawie wymagań przedstawionych przez użytkownika. 2. Dla zmian w istniejącym programie- uaktualnienia, nowe wersje, wszelkich modyfikacji zmieniających funkcjonalność. 3. Dla gotowego programu. Źródła: https://pl.wikipedia.org/wiki/Punkt_funkcyjny https://kot.rogacz.com/Science/Studies/07/inzynieriaOprogramowania/wyklad/mpf.pdf - tutaj jest więcej info.

11. Podać problemy (i przykłady) w modelowaniu morfologicznym, semantycznym i numerycznym systemu informacyjnego. 12. Co to jest model COCOMO? Metoda s  zacowania kosztowności (pracochłonności) tworzenia oprogramowania , bazująca na rozmiarze oprogramowania. Opiera się na danych historycznych przeszło 100 rzeczywistych projektach informatycznych. [Można jeszcze ten temat rozwinąć] Źródło: h  ttp://wazniak.mimuw.edu.pl/images/3/30/Zio-13-wyk.pdf 13. Omówić model CMM. Można powiedzieć, że w omawianym na poprzednim wykładzie standardzie ISO 9001:2000 mamy dwa poziomy: niespełniający wymagań ISO 9001:2000 i spełniający te wymagania. W modelu wwI tych poziomów jest pięć. P  ierwszy poziom to p  oziom początkowy . Na tym poziomie są wszystkie firmy, które nie spełniają wymagań związanych z wyższymi poziomami. A zatem znalezienie się na pierwszym poziomie CMMI jest bardzo łatwe. D  rugi poziom CMMI jest zwany Z  arządzanym (w starym modelu CMM nazywał się Powtarzalny). Na tym poziomie znajdują się najważniejsze praktyki dotyczące zarządzania przedsięwzięciem informatycznym. T  rzeci poziom, Zdefiniowany , dotyczy całej organizacji i prezentuje bardziej zaawansowane praktyki. P  oziom czwarty, Zarządzany ilościowo , zawiera zaawansowane praktyki analizy danych dotyczących efektywności procesów wytwarzania oprogramowania bazujące na statystycznej kontroli procesów (Statistical Process Control, w skrócie SPC). Najwyższy, p  iąty, poziom nazywa się O  ptymalizujący – organizacje znajdujące się na tym poziomie potrafią w systematyczny sposób przygotować się do zmian (np. zmian związanych z rozwojem technologii wytwarzania oprogramowania). http://wazniak.mimuw.edu.pl/images/d/d3/Zio-3-wyk.pdf

14. Wymienić własności deterministycznego grafu programu. Po co konstruuje się taki graf? 15. Wymienić własności stochastycznego grafu programu. Po co konstruuje się taki graf? Nie wiem jak to się ma w kontekście grafu dla p  rogramu, aczkolwiek własności to: ● ● ●

awwStopień wierzchołka - liczba krawędzi które wychodzą z danego wierzchołka, w grafie stochastycznym stopień ten jest stały średnia długość drogi - długość najkrótszej drogi między dowolnie wybranymi wierzchołkami Klikowatość - jest to prawdopodobieństwo tego, że dwaj losowi sąsiedzi danego wierzchołka również są przyjaciółmi.

Graf ten konstruujemy aby zamodelować sieć rzeczywistą. 16. Podać w punktach konstrukcję grafu przepływu dla projektu w VHDL. Po co konstruuje się taki graf? 17. W jaki sposób uwzględnia się architekturę sprzętową w estymacji parametrów egzekucyjnych aplikacji? 18. Co to jest QoS i jakie są stosowane mechanizmy do jego zapewnienia? 19. Jakie znasz technologie komponentowe (przynajmniej 3) i podaj ich główne charakterystyczne cechy. - JavaBeans – wprowadzona do języka Java już od pierwszej wersji. - CORBA (ang. Common Object Request Broker Architecture ) - COM (ang. Component Object Model) – opracowana przez Microsoft; następnie rozszerzona do DCOM i COM+ - . NET – lansowana przez Microsoft jako następca COM/DCOM/COM+ - XML – nowy zawodnik w grze komponentowej http://kik.weii.tu.koszalin.pl/komponenty/Programowanie%20komponentowe.pdf

20. Wymienić w punktach realizację procesu tworzenia archiwum dla bezpieczeństwa danych. Jakie typy logów są konieczne do realizacji archiwizacji?

Termin I (fejs) 1. Podać przykłady systemów informatycznych: a. Proceduralnych

b. Współbieżnych c. Zdarzeniowych 2. Podać różnice “nowoczesnej” analizy systemu informatycznego od analizy “klasycznej” 3. Porównać modele życia systemu informatycznego: Boehm’a i Fry’ego. Podać podobieństwa i różnice dotyczące tych modeli. 4. Omówić technikę polimorfizmu w programowaniu obiektowym. Dlaczego wprowadzono polimorfizm do języków programowania?

5. Omówić poziom upper CASE. Podać przykłady narzędzi tego poziomu. Narzędzia Upper- CASE (wysokiego poziomu) wspomagają pierwszą fazę budowy systemu – analizę organizacyjną , funkcjonalną i procesową, modelowanie funkcji, procesów, obiektów, modelowanie struktur i tworzenie wszelkich diagramów. Narzędzia te koncentrują się na opisie i modelowaniu rzeczywistości, modelowaniu struktury systemu, bez wszelkich faz implementacji. Źródło: str8 http://mariusz.makuchowski.staff.iiar.pwr.wroc.pl/download/courses/komputerowe.wspomag anie.zarzadzania/wyk.slajdy/wyk12.CASE.pdf

6. Co zawiera repozytorium? Słowniki danych (repozytoria) – bazy wszelkich danych o tworzonym systemie wraz z narzędziami edytującymi, zarządzającymi i wyszukującymi te dane. Źródło: str19 http://mariusz.makuchowski.staff.iiar.pwr.wroc.pl/download/courses/komputerowe.wspomag anie.zarzadzania/wyk.slajdy/wyk12.CASE.pdf 7. Co zawiera projekt konceptualny systemu informacyjnego z relacyjną bazą danych?

8. Podać algorytm X-domkniętości.

9. Jaki operacyjny diagram CASE odpowiada modelowi Toma DeMarco analizy systemu? Przedstawić ten diagram 10. Na czym polega weryfikowalność pod względem zupełności diagramu DFD? Zasada zupełności danych – proces musi otrzymać wszystkie potrzebne dane do poprawnego wyprodukowania wyników 11. Jak identyfikujemy więzy bezpośrednie obiektów w diagramie ERD?

12. Omówić diagram operacyjny ELH. Kiedy stosujemy ten typ diagramu? Diagramy ELH — prezentuję zmiany stanu encji w czasie działania systemu. Diagram ELH prezentuje w jaki sposób encje systemu zmieniają się w czasie jego funkcjonowania. Diagram ten prezentuje pełny zbiór zmian jaki mogą zajść dla encji, łącznie z informacją o kontekście tych zmian. Diagram ELH tworzony jest dla każdej z encji osobno, przedstawia on losy hipotetycznego egzemplarza encji, począwszy od jego utworzenia aż po jego usunięcie. 13. Omówić diagram operacyjny STD. Kiedy stosujemy ten typ diagramu? 14. Czym są stereotypy w mechanizmach językowych UML? 15. Podać atrybuty specyfikacji systemu informatycznego. 16. Podać kryteria akceptacji dla systemu informatycznego. - Weryfikowalność i testowalność – czy wymaganie jest testowalne? Czy została zdefiniowana metryka i warunki akceptacji wymagania? - Zrozumiałość – czy wymaganie jest rozumiane przez wszystkich członów grupy tworzacej specyfikacje? Czy wymaganie jest łatwe do zrozumienia przez innych (nowych) członków grupy projektowej? - Kontrolowalność – czy powód dla którego wymaganie zostało zawarte w specyfikacji jest wyraźnie zidentyfikowany? Czy został określony wpływ wymagania na inne funkcje systemu? - Adaptowalność – czy wymaganie może zostać zmienione bez zmian w wielu modułach systemu? Czy wymaganie w ogóle może podlegać zmianom? http://artemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria_Oprogramowania_WSZiB_03.pdf

17. Zdefiniować walidacje dla systemu informatycznego 18. Podać powody rozpatrywania problemów pomiarów oprogramowania. 19. Omówić model CMM Patrz: Termin I(wiki) -> https://docs.google.com/document/d/1l9S-FfO9v1VBxXg9O2vfu8hesSANIExP16Pwdrn4IY0/ edit#heading=h.6rb3hzat1wu3

20. Czego dotyczy metoda GQM? 21. Czego dotyczy system ISO 9001:2000? międzynarodowa norma określająca wymagania, które powinien spełniać system zarządzania jakościąw organizacji.

22. Podać perspektywy modelowania architektury systemu informatycznego. 23. Wymienić zadania procesowe związane występujące w produkcji oprogramowania. 24. Które zadania procesowe występują we wszystkich etapach powstawania oprogramowania ? 25. Co to jest QoS i jakie są stosowane podejścia do jego zapewnienia? 26. Zdefiniować weryfikację dla systemu informatycznego. 27. Podać przykłady technologii komponentowych, ich główne, charakterystyczne cechy oraz porównać z technologiami obiektowymi. 28. Omówić planowanie i wymagania w XP.

Termin II (2016) 1. Przedstawić struktury aplikacji w środowiskach komponentowych. 2. Podać obszary wiedzy inżyniera oprogramowania (analityka informatycznych) 3. Omówić elementy składowe określające każdy język programowania. 4. Omówić wskaźnik *this w programowaniu obiektowym. 5. Podać różnice między zaprzyjaźnieniem a dziedziczeniem.

systemów

Klasa zaprzyjaźniona - klasa, która ma dostęp do prywatnych i chronionych składników danej klasy , a konkretniej: której funkcje składowe ( metody ) mają dostęp do prywatnych i chronionych składników danej klasy. Przyjaźń deklaruje zawsze klasa która chce by inna klasa miała dostęp do jej składników prywatnych - nigdy na odwrót. Właściwości: ●

● ●

 rotected , p  ublic) zadeklaruje się przyjaźń. Nieistotne jest, gdzie ( private , p Przyjaźnie danej klasy są stosunkowo ważne z punktu widzenia projektanta, dlatego, w celu przejrzystości kodu dobrze jest zrobić to na samym początku deklaracji klasy. Klasa może być przyjacielem wielu klas. Klasa może mieć wielu przyjaciół (zarówno klasy jak i funkcje).

●

●

Przyjaźń nie jest przechodnia. Oznacza to, że gdy klasa C  jest przyjacielem klasy B, a klasa B  jest przyjacielem klasy A  , to nie oznacza to, że klasa C  jest przyjacielem klasy A  ( przyjaciel mojego przyjaciela nie musi być moim przyjacielem). Przyjaźń nie jest d  ziedziczona .

Przykład w C++ class B  ; //deklaracja zapowiadająca c  lass A  { friend c  lass B  ; // deklaracja przyjaźni p  rivate : int x; // zmienna w sekcji prywatnej }; c  lass B  { p  ublic : void wpiszIks( A& obiekt , c  onst int wartosc ) { obiekt.x = wartosc; // niemożliwe bez deklaracji przyjaźni return ; } }; 6. Podać kryteria akceptacjibi dla systemu oprogramowania. Patrz -> https://docs.google.com/document/d/1l9S-FfO9v1VBxXg9O2vfu8hesSANIExP16Pwdrn4IY0/ edit#heading=h.ky3zslubolrd

7. Przedstawić taksonomię (według M.L.Gibsona) CASE i podać przykłady programów tego wspomagania. 8. Podać (co najmniej 3) i omówić kluczowe metryki oprogramowania. Metryki rozmiaru: - Linie kodu - liczba linii kodu źródłowego, daje ogólne pojęcie skali programu, nie wystarcza do szczegółowej analizy - Liczba tokenów - liczba podstawowych składni języka programowania (operatory i operandy) Metryki złożoności: - Złożoność cyklomatyczna McCabe’a - liczba prostych ścieżek przebiegu programu bez uwzględniania cykli. Niska wartość tej metryki oznacza łatwość zrozumienia danej metody. Wartość powyżej 20 charakteryzuje złożony kod i wiąże się z dużym

ryzykiem wystąpienia błędów. Z  aletami metryki CC są m.in. łatwość jej obliczenia i możliwość wskazania elementów aplikacji, które należy przeprojektować - Złożoność Halsteada - pozwala na zdefiniowanie bardziej skomplikowanych metryk złożoności, takich jak: T  rudność , czyli podatność na błędy, P  oziom programu , czyli współczynnik podatności aplikacji na błędy, W  ysiłek potrzebny do zaimplementowania programu, C  zas potrzebny do zaimplementowania oraz szacunkowa liczba B  łędów Metryki obiektowe: - WMC - Weighted Methods per Class - zlicza złożoność metod występujących w danej klasie -

DIT - Depth of Inheritance Tree - pozwala na określenie stopnia dziedziczenia, jest to liczba kolejnych klas po których dziedziczy dana klasa. ….

https://pl.wikipedia.org/wiki/Metryka_oprogramowania 9. Do czego służy FSM? 10. Co to jest dedykowany i ogólny estymator? 11. Co charakteryzuje indukcyjny, a co dedukcyjny system oprogramowania? 12. Wymienić własności deterministycznego grafu programu. Po co konstruuje się taki graf? 13. Wymienić własności stochastycznego grafu programu. Po co konstruuje się taki graf? 14. Podać w punktach konstrukcję grafu przepływu dla projektu w VHDL. Po co konstruuje się taki graf? 15. W jaki sposób uwzględnia się architekturę sprzętową w estymacji parametrów egzekucyjnych aplikacji? 16. Podać schemat powiązań menedżera transakcji i menadżera logów w SZBD. 17. Podać reguły ochrony za pomocą logu z unieważnieniem 18. Omówić problem utraconej modyfikacji. 19. Podać proto...