Inżynieria oprogramowania
Zakupy w sklepie internetowym
dr inż. Mirosław Miciak
Piotr Jaskólski
I. Ogólny opis systemu
Celem systemu jest stworzenie możliwości sprzedaży swoich produktów
przez Właściciela sklepu  Bajkolandia za pośrednictwem Internetu. Sklep
ten w swojej ofercie posiada ciuchy i zabawki dla dzieci.
Powstanie takiego oprogramowania wiąże się z chęcią rozszerzenia
działalności sklepu również o możliwość zakupów on-line. Dzięki
połączeniu z systemem ERP firmy w łatwy sposób można sprawdzać m.in.
stany magazynowe poszczególnych artykułów, czy w zautomatyzowany
sposób można wystawiać dokumenty księgowe i magazynowe.
Oprogramowanie to powinno w sobie zawierać takie funkcje jak:
Øð możliwość przechowywania informacji o zarejestrowanych
użytkownikach sklepu (pracownikach, kupujących, właścicieli),
Øð możliwość tworzenia/przywracania kopii zapasowych bazy danych,
Øð peÅ‚ne szyfrowanie danych transakcji, użytkowników i wszelkich
innych,
Øð klasyfikacja przedmiotów wg kategorii,
Øð integracja z systemem ERP firmy,
Øð możliwość wystawiania/kupowania towarów,
Øð możliwość tworzenia bonów rabatowych dla staÅ‚ych i nowych
klientów,
Øð możliwość wysyÅ‚ania powiadomieÅ„ o statusie zamówieÅ„ przez
e/mail i/lub sms,
Øð możliwość wysyÅ‚ania newsletterów,
Øð możliwość szybkich pÅ‚atnoÅ›ci on-line oraz za pomocÄ… karty
kredytowej.
Diagram przypadków użycia.
I. Analiza dziedziny
W poniższej tabeli przedstawiono klasy systemu, spis atrybutów oraz opis.
Klasa Atrybuty Opis
Klient ImiÄ™, nazwisko, adres e-mail, Klient sklepu, zawiera
telefon, miejsce pełne informację o
zamieszkania, hasło. użytkowniku.
Pracownik Imię, nazwisko, adres e-mail, Pracownik obsługi sklepu,
telefon, hasło. oprócz danych jak Klient
posiada rozbudowane
uprawnienia potrzebne do
obsługi sklepu
internetowego.
Faktura Data zakupu, towar, klient. Faktura wystawiana jest
automatycznie przez
oprogramowanie sklepu.
Zawiera wszelkie dane,
które powinny znalez
ć się na
takim dokumencie. Za
pomocą tabeli następuje
również synchronizacja z
systemem ERP.
Towar Tytuł, opis, kategoria, cena, Towary dostępne w sklepie,
zdjęcie. zawierają dane
identyfikujÄ…ce przedmiot
oraz cenÄ™.
Kategoria Nazwa kategorii. Zawiera wszelkie kategoriÄ™,
w których znajdują się
towary.
Koszyk Klient, towar, ilość Klasa zawiera informację o
koszyku kupujÄ…cego w
trakcie zakupów.
Stan magazynu Towar, ilość. Klasa zintegrowana z
systemem ERP za pomocÄ…
API, która na bieżąco
synchronizuje siÄ™ w celu
zaktualizowania informacji
o stanie magazynowym.
Diagram klas
II. Specyfikacja wymagań
Specyfikacja wymagań jest dokumentem opisującym wymagania stawiane
oprogramowaniu sklepu internetowego. Poniżej wyszczególniono założenia
funkcjonalne oraz niefunkcjonalne systemu.
Założenia funkcjonalne Opis
Oprogramowanie uwzględnia Każdy użytkownik sklepu (czy to
zakładanie i usuwanie kont dla pracownik, czy klient) musi mieć
klientów i pracowników możliwość założenia swojego
indywidualnego konta. Dodatkowo,
system musi uwzględniać opcję
usunięcia konta użytkownika, który
np. został zwolniony z pracy.
Oprogramowanie ma możliwość Dodawane towary powinny posiadać
dodawania towarów. cechy jednoznacznie je
charakteryzujÄ…ce, takie jak: cena, opis,
nazwa, zdjęcie
Oprogramowanie ma możliwość Aby łączyć towary potrzebne są
dodawania kategorii produktów. kategorie, wg których dodatkowo
można je sortować i filtrować.
System posiada możliwość W systemie można na bieżąco
sprawdzania stanów magazynowych. sprawdzać stan magazynowy  jest to
potrzebne zarówno dla sprzedawcy
(aby ew. domówić produkty) jak i dla
kupujących (jeżeli produktów już nie
ma  klient nie może zakupić towaru).
System posiada możliwość System musi posiadać szczegółowe
wystawiania faktur/paragonów na informacje o wszystkich sprzedażach,
podstawie sprzedanych towarów.
dzięki czemu można wykonywać
operacje księgowe dla celów firmy.
Oprogramowanie powinno mieć System musi przechowywać
możliwość dodawania oraz usuwania informacje o klientach sklepu, m.in.
danych klientów. adres zamieszkania dla celów wysyłki
zakupionych towarów.
Założenia niefunkcjonalne Opis
Oprogramowanie powinno posiadać Innymi słowy każdy przeciętny
intuicyjny interfejs użytkownika użytkownik komputera powinien
poradzić sobie z obsługą systemu. Jego
obsługa nie powinna być
skomplikowana, a interfejs nie
powinien się różnić od przyjętych
standardów stosowanych w tego typu
systemach. Ważnym jest również
stonowana grafika w interfejsie.
Należy unikać jaskrawej kolorystyki.
Oprogramowanie powinno zostać Jedną z myśli podczas wytwarzania
opracowane w taki sposób aby w oprogramowania musi być idea tego,
przyszłości można było aktualizować że system będzie w przyszłości
system. rozwijany. Nie jest określone w jakim
kierunku podąży rozwój. Niemniej
jednak wytworzone oprogramowanie
musi być napisane tak by w łatwy i
przyjazny sposób można było dalej je
rozwijać. Wytworzony system musi
zatem zawierać kod wysokiej jakości o
odpowiedniej czytelności, powinny
zostać zastosowane wszystkie dobre
praktyki stosowane w procesie
wytwarzania oprogramowania.
PU : Załóż konto
Aktorzy: Gość
Zdarzenie wyzwalajÄ…ce: pojawienie siÄ™ nowego klienta w sklepie
Warunki wstępne: brak
Warunki końcowe dla sukcesu: klient nie może być zarejestrowany w systemie
Warunki końcowe dla niepowodzenia: dany klient został już zarejestrowany w
systemie, brak wprowadzonych wymaganych danych
Scenariusz główny:
1. Nowy klient dokonuje swojej rejestracji
2. Po weryfikacji danych za pomocą e-mail następuje aktywacja konta.
PU : Dodaj do koszyka
Aktorzy: Klient
Zdarzenie wyzwalające: chęć zakupu towaru
Warunki wstępne: Klient musi być zalogowany na swoim koncie
Warunki końcowe dla sukcesu: wybrany towar musi być dostępny w magazynie
Warunki końcowe dla niepowodzenia: brak towaru w magazynie
Scenariusz główny:
1. Klient loguje siÄ™ na swoje konto.
2. Klient dodaje towar do koszyka.
PU : Finalizuj transakcjÄ™
Aktorzy: Klient, Pracownik
Zdarzenie wyzwalajÄ…ce: finalizacja zakupu
Warunki wstępne: Klient musi być zalogowany na swoim koncie
Warunki końcowe dla sukcesu: w koszyku musi znajdować się towar, płatność
zostaje zatwierdzona przez system
Warunki końcowe dla niepowodzenia: w koszyku nie ma towaru, brak płatności
Scenariusz główny:
1. Klient potwierdza chęć zakupu za wybrany towar.
2. Następuje płatność za produkty.
3. Potwierdzenie dokonania płatności przez system.
4. Potwierdzenie zakupu wysłane na e-mail oraz sms.
5. Wystawienie faktury/paragonu i wysyłka zamówionych towarów.
PU : PrzeglÄ…daj historiÄ™
Aktorzy: Klient
Zdarzenie wyzwalajÄ…ce: przeglÄ…danie historii
Warunki wstępne: Klient musi być zalogowany na swoim koncie
Warunki końcowe dla sukcesu: Klient musiał wcześniej dokonać zakupu
Warunki końcowe dla niepowodzenia: brak historii zakupów
Scenariusz główny:
1. Klient przegląda swoją historię zakupów
PU : ZarzÄ…dzaj kontem
Aktorzy: Klient
Zdarzenie wyzwalajÄ…ce: zmiana danych Klienta
Warunki wstępne: Klient musi być zalogowany na swoim koncie
Warunki końcowe dla sukcesu: wpisanie poprawnych danych, wpisane
poprawne hasło użytkownika
Warunki końcowe dla niepowodzenia: wpisane dane są niepoprawne, wpisane
hasło jest niepoprawne
Scenariusz główny:
1. Klient zmienia swoje dane.
2. Zatwierdza wprowadzone dane wpisując jeszcze swoje hasło.
PU : Aktualizuj stany magazynowe
Aktorzy: ERP
Zdarzenie wyzwalajÄ…ce: synchronizacja danych
Warunki wstępne: system synchronizuje stany magazynowe
Warunki końcowe dla sukcesu: poprawność wykonania synchronizacji
Warunki końcowe dla niepowodzenia: różne stany między systemem sklepu a
ERP
Scenariusz główny:
1. System co 30 minut wykonuje synchronizację stanów magazynowych.
PU : ZarzÄ…dzaj towarami
Aktorzy: Pracownik
Zdarzenie wyzwalajÄ…ce: dodanie/usuwanie/modyfikacja towaru
Warunki wstępne: pracownik zarządza towarami
Warunki końcowe dla sukcesu: poprawne wykonanie modyfikacji
Warunki końcowe dla niepowodzenia: brak wpisania wymaganych danych,
wpisane dane sÄ… niepoprawne
Scenariusz główny:
1. Pracownik dodaje towar.
Scenariusz alternatywny:
1. Pracownik usuwa towar.
Scenariusz alternatywny:
1. Pracownik edytuje towar.
PU : ZarzÄ…dzaj kategoriami
Aktorzy: Pracownik
Zdarzenie wyzwalajÄ…ce: dodanie/usuwanie/modyfikacja kategorii
Warunki wstępne: pracownik zarządza kategoriami
Warunki końcowe dla sukcesu: poprawne wykonanie modyfikacji
Warunki końcowe dla niepowodzenia: brak wpisania wymaganych danych,
wpisane dane sÄ… niepoprawne
Scenariusz główny:
1. Pracownik dodaje kategoriÄ™.
Scenariusz alternatywny:
1. Pracownik usuwa kategoriÄ™.
Scenariusz alternatywny:
1. Pracownik edytuje kategoriÄ™.
III. Analiza i projekt
System informatyczny dla sklepu internetowego oparty zostanie o technologiÄ™
PHP 5 przy wykorzystaniu serwera bazodanowego MySQL. Niniejsza
technologia nie narzuca wykorzystania żadnej architektury, ale dla naszego
projektu wybierzemy architekturÄ™ MVC  model, widok, kontroler do budowy
systemu.
1. Architektura systemu
MVC to nic innego, jak skrót od Model View Controller. Jest to wzorzec
projektowy (a więc zbiór pewnych reguł, według których budowane są aplikacje
na całym świecie), który cieszy się bardzo dużą popularnością wśród
webdeveloperów.
Z reguły proste aplikacje w PHP wyglądają tak, że sprawdzany jest adres
wpisany do przeglÄ…darki (na podstawie $_GET, bÄ…dz
innych właściwości z
$_SERVER), potem includowane są potrzebne pliki w zależności od
pozyskanych danych. Absolutne podstawy podstaw, stosując MVC nie możemy
opierać się, jak to zwykle bywa w tradycyjnym podejściu, tylko na jednym
pliku, np. index.php, w którym mieszamy kod prezentacji (np. HTML) i logikę
biznesową (dane np. z MySQL). Działa to zupełnie inaczej, a mianowicie mamy
3 główne elementy aplikacji, gdzie każda odpowiedzialna jest tylko za jedną
rzecz. SÄ… nimi:
·ð Controller steruje wszystkim tym, co dzieje siÄ™ podczas uruchamiania
danej akcji. Np. podczas wywołania index.php?controller=news&id=55.
Przykładowo, jeśli dodasz np. nowego usera do bazy, to kontroler
zdecyduje, że po tej czynności przeniesiony zostaniesz np. do edycji
profilu. Kontroler to mózg sterujący całym wywołaniem strony. W pliku
kontrolera wybierasz, z którego modelu (a więc pliku odpowiedzialnego
za pobieranie danych  może to być baza danych, plik, cokolwiek)
wez
miesz treść dla strony, a także jak ją wyświetlisz (czyli który widok
CiÄ™ interesuje).
·ð Model zajmuje siÄ™ tylko i wyÅ‚Ä…cznie pracÄ… na danych.
·ð Widok (View) zajmuje siÄ™ tylko i wyÅ‚Ä…cznie wyÅ›wietlaniem danych.
2. Projekt oprogramowania
Definicja klas
Klasa Atrybuty Opis
Klient ImiÄ™, nazwisko, adres e-mail, Klient sklepu, zawiera
telefon, miejsce pełne informację o
zamieszkania, hasło. użytkowniku.
Pracownik Imię, nazwisko, adres e-mail, Pracownik obsługi sklepu,
telefon, hasło. oprócz danych jak Klient
posiada rozbudowane
uprawnienia potrzebne do
obsługi sklepu
internetowego.
Faktura Data zakupu, towar, klient. Faktura wystawiana jest
automatycznie przez
oprogramowanie sklepu.
Zawiera wszelkie dane,
które powinny znalez
ć się na
takim dokumencie. Za
pomocą tabeli następuje
również synchronizacja z
systemem ERP.
Towar Tytuł, opis, kategoria, cena, Towary dostępne w sklepie,
zdjęcie. zawierają dane
identyfikujÄ…ce przedmiot
oraz cenÄ™.
Kategoria Nazwa kategorii. Zawiera wszelkie kategoriÄ™,
w których znajdują się
towary.
Koszyk Klient, towar, ilość Klasa zawiera informację o
koszyku kupujÄ…cego w
trakcie zakupów.
Stan magazynu Towar, ilość. Klasa zintegrowana z
systemem ERP za pomocÄ…
API, która na bieżąco
synchronizuje siÄ™ w celu
zaktualizowania informacji
o stanie magazynowym.
Klasa odpowiedzialna za składowanie danych
Do obsługi bazy danych posłuży nam wzorzec Active Records. To pośrednik
między naszymi operacjami w bazie danych a wynikowymi zapytaniami SQL.
Nie korzystamy z języka SQL - używamy specjalnych metod wykonujących
określone czynności w bazie.
Poza prostotą, główną korzyścią płynącą z używania klasy Active Record, jest
możliwość tworzenia aplikacji niezależnych od rodzaju bazy danych, której
używamy. Jest to możliwe, ponieważ składnia zapytań jest generowana osobno
dla każdego adaptera bazy danych. Klasa Active Record sprzyja tworzeniu
bezpiecznych zapytań, ponieważ wszystkie wartości są automatycznie
escapowane.
Klasy przetwarzajÄ…ce dane
Klasa Opis Metody
Klient Klasa odpowiedzialna +Loguj()
za obsługę kont +Wyloguj()
klientów. +DodajUzytkownika()
+EdytujUzytkownika()
Pracownik Klasa odpowiedzialna +Loguj()
za obsługę kont +Wyloguj()
pracowników. +DodajPracownika()
+EdytujPracownika()
+UsunPracownika()
Koszyk Klasa odpowiedzialna +DodajTowar()
za obsługę koszyka. +UsunTowar()
+ModyfikujZamowienie()
+FinalizujTransakcje()
Towar Klasa odpowiedzialna +DodajTowar()
za obsługę towaru. +UsunTowar()
+EdytujTowar()
Kategoria Klasa odpowiedzialna +DodajKategorie()
za obsługę kategorii +UsunKategorie()
towarów. +ZmienKolejnosc()
Stan magazynu Klasa odpowiedzialna +ZmienStan()
za obsługę stanu +Synchronizuj()
magazynowego oraz
jego synchronizacjÄ™ z
systemem ERP.
Diagram STD
Modyfikowanie danych klienta
Gość
Zarejestrowany klient
Pracownik
Wejście na stronę WWW
Panel Klienta
PrzeglÄ…danie Towaru Dodawanie towaru do koszyka
Rejestracja
Logowanie Usunięcie towaru z koszyka
Modyfikowanie danych
pracownika
Finalizowanie transakcji
Panel administracyjny
ZarzÄ…dzanie stanami
magazynowymi
Pobranie faktury
ZarzÄ…dzanie kategoriami
Wylogowanie
ZarzÄ…dzanie towarami
Diagram ERD