Wykład 4. Projektowanie. MIS n Inżynieria oprogramowania Październik 2014

Wielkość: px

Rozpocząć pokaz od strony:

Download "Wykład 4. Projektowanie. MIS n Inżynieria oprogramowania Październik 2014"

Bogna Laura Wieczorek
7 lat temu
Przeglądów:

1 Wykład 4 MIS n Inżynieria oprogramowania Październik 2014 Metody Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 4.1

2 Agenda Metody Metody

3 Implementacja Metody 4.3

4 Implementacja = + Programowanie Implementacja = + Programowanie Projekt to opis: struktury oprogramowania danych w systemie interfejsów między komponentami użytych algorytmów Metody 4.4

5 Projektant nie tworzy od razu końcowego projektu! Projekt opracowuje się iteracyjnie w czasie Projekt może mieć wiele różnych wersji W miarę upływu czasu projekt jest coraz bardziej formalny i szczegółowy Powraca się do już opracowanych fragmentów w celu ich poprawy Sprzężenie zwrotne między fazami i powtarzanie prac sa nieuniknione w każdym procesie! Metody 4.5

6 Wyróżniamy różne rodzaje : (Architektury systemów rozproszonych) oprogramowania czasu rzeczywistego z użyciem wielokrotnym interfejsu użytkownika Metody 4.6

7 : architektury Specyfikowanie abstrakcyjne interfejsów komponentów struktur danych algorytmów Metody 4.7

8 Metoda ad hoc: Nieformalny projekt Projekt jest zmieniany w miarę programowania Nie ma formalnej kontroli zmian Nie ma zarzadzania projektem Po zakończeniu fazy implementacji projekt jest najczęściej niepoprawny i niekompletny Metody 4.8

9 Metody strukturalne Graficzne modele systemu Duża ilość dokumentacji projektowej Obejmuja modele przepływu danych, model encja-zwiazek, model strukturalny, modele dziedziczenia, statycznych i dynamicznych zwiazków i inne. Przykładowe metody strukturalne: Structured Design Structured System Analysis Jackson System Development Różne dla go Metody 4.9

10 Co to jest projektowanie? Systemy sa podzielone na podsystemy, powiazane poprzez interfejsy. Definicja Poczatkowa faza procesu, w której identyfikuje się podsystemy i ustala zrab sterowania oraz komunikacji to projektowanie. Produktem tej fazy jest opis architektury oprogramowania. Metody 4.10

11 Zalety go Komunikacja z uczestnikami Podstawa do dyskusji na bardzo różnych poziomach Analiza systemu Ujawnienie architektury we wczesnej fazie pozwala na przeprowadzenie analizy pod katem krytycznych cech systemu Użycie wielokrotne w wielkiej skali Architektura jest zwartym i łatwym do opanowania opisem organizacji systemu i współpracy komponentów Metody 4.11

12 Czynności go 1 Strukturalizacja systemu 2 Modelowanie sterowania 3 Podział na moduły Podsystem a moduł: Podsystem : jego usługi nie zależa od usług oferowanych przez inne systemy; składa się z modułów; maja interfejsy do komunikacji z innymi podsystemami Moduł : komponent systemu; oferuje co najmniej jedn a usługę innym modułom; korzysta z innych modułów; zwykle nie jest traktowany jako niezależny system Metody 4.12

13 Model architektoniczny 4+1 Metody 4.13

14 jest to strategia, w której projektanci systemu myśla w kategoriach bytów, a nie operacji albo funkcji Działajacy system składa się z oddziałujacych na siebie obiektów. Obiekty przechowuja swój lokalny stan i oferuja operacje na tym stanie Obiekty ukrywaja informacje o reprezentacji stanu i ograniczaja do niego dostęp. Metody 4.14

15 Jest częścia tworzenia go w którym strategie sa stosowane w czasie całego procesu tworzenia: Analiza obiektowa Programowanie Metody 4.15

16 : pierwsze pięć zasad S.O.L.I.D. S SRP Single responsibility principle O OCP Open/closed principle L LSP Liskov substitution principle I ISP Interface segregation principle D DIP Dependency inversion principle Metody 4.16

17 SRP Single responsibility principle a class should have only a single responsibility (i.e. only one potential change in the software s specification should be able to affect the specification of the class) Zasada pojedynczej odpowiedzialności Nigdy nie powinno być więcej niż jednego powodu do modyfikacji klasy. Metody 4.17

18 OCP Open/closed principle software entities... should be open for extension, but closed for modification. Zasada otwarte-zamknięte elementy systemu takie, jak klasy, moduły, funkcje itd. powinny być otwarte na rozszerzenie, ale zamknięte na modyfikacje Metody 4.18

19 LSP Liskov substitution principle objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. Zasada podstawienia Liskov Funkcje które używaja wskaźników lub referencji do klas bazowych, musza być w stanie używać również obiektów klas dziedziczacych po klasach bazowych, bez dokładnej znajomości tych obiektów. Metody 4.19

20 ISP Interface segregation principle many client-specific interfaces are better than one general-purpose interface". Zasada segregacji interfejsów wiele interfejsów odpowiadaj acych konkretnym potrzebom jest lepsze niż jeden ogólny interfejs do wszystkiego Metody 4.20

21 DIP Dependency inversion principle one should Depend upon Abstractions. Do not depend upon concretions. Zasada odwrócenia zależności Zależności powinny opierać się na abstrakcjach, a nie na ich konkretnych realizacjach. Metody 4.21

22 G.R.A.S.P. GRASP General Responsibility Assignment Software Patterns (or Principles) Controller Creator High Cohesion Indirection Information Expert Low Coupling Polymorphism Protected Variations Pure Fabrication Metody 4.22

Podobne dokumenty

Projektowanie obiektowe oprogramowania Wykład 4 - SOLID GRASP Wiktor Zychla 2012

Projektowanie obiektowe oprogramowania Wykład 4 - SOLID GRASP Wiktor Zychla 2012 1 Taksonomia RDD RDD = Responsibility-Driven Development, przemyślane projektowanie obiektowe Wzorce aplikacyjne Wzorce