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,

telefon, miejsce

zamieszkania, hasło.

Klient sklepu, zawiera

pełne informację o

użytkowniku.

Pracownik

Imię, nazwisko, adres e-mail,

telefon, hasło.

Pracownik obsługi sklepu,

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 znaleźć się na

takim

dokumencie.

Za

pomocą tabeli następuje

również synchronizacja z

systemem ERP.

Towar

Tytuł, opis, kategoria, cena,

zdjęcie.

Towary dostępne w sklepie,

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

zakładanie i usuwanie kont dla

klientów i pracowników

Każdy użytkownik sklepu (czy to

pracownik, czy klient) musi mieć

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ść

dodawania towarów.

Dodawane towary powinny posiadać

cechy

jednoznacznie

je

charakteryzujące, takie jak: cena, opis,

nazwa, zdjęcie

Oprogramowanie

ma

możliwość

dodawania kategorii produktów.

Aby łączyć towary potrzebne są

kategorie, wg których dodatkowo

można je sortować i filtrować.

System

posiada

możliwość

sprawdzania stanów magazynowych.

W systemie można na bieżąco

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ść

wystawiania faktur/paragonów na

podstawie sprzedanych towarów.

System musi posiadać szczegółowe

informacje o wszystkich sprzedażach,

dzięki czemu można wykonywać

operacje księgowe dla celów firmy.

Oprogramowanie

powinno

mieć

możliwość dodawania oraz usuwania

danych klientów.

System

musi

przechowywać

informacje o klientach sklepu, m.in.

adres zamieszkania dla celów wysyłki

zakupionych towarów.

Założenia niefunkcjonalne

Opis

Oprogramowanie powinno posiadać

intuicyjny interfejs użytkownika

Innymi słowy każdy przeciętny

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ć

opracowane w taki sposób aby w

przyszłości można było aktualizować

system.

Jedną z myśli podczas wytwarzania

oprogramowania musi być idea tego,

że system będzie w przyszłości

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ądź 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)

weź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,

telefon, miejsce

zamieszkania, hasło.

Klient sklepu, zawiera

pełne informację o

użytkowniku.

Pracownik

Imię, nazwisko, adres e-mail,

telefon, hasło.

Pracownik obsługi sklepu,

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 znaleźć się na

takim

dokumencie.

Za

pomocą tabeli następuje

również synchronizacja z

systemem ERP.

Towar

Tytuł, opis, kategoria, cena,

zdjęcie.

Towary dostępne w sklepie,

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

za

obsługę

kont

klientów.

+Loguj()

+Wyloguj()

+DodajUzytkownika()

+EdytujUzytkownika()

Pracownik

Klasa odpowiedzialna

za

obsługę

kont

pracowników.

+Loguj()

+Wyloguj()

+DodajPracownika()

+EdytujPracownika()

+UsunPracownika()

Koszyk

Klasa odpowiedzialna

za obsługę koszyka.

+DodajTowar()

+UsunTowar()

+ModyfikujZamowienie()

+FinalizujTransakcje()

Towar

Klasa odpowiedzialna

za obsługę towaru.

+DodajTowar()

+UsunTowar()

+EdytujTowar()

Kategoria

Klasa odpowiedzialna

za obsługę kategorii

towarów.

+DodajKategorie()

+UsunKategorie()

+ZmienKolejnosc()

Stan magazynu

Klasa odpowiedzialna

za

obsługę

stanu

magazynowego

oraz

jego synchronizację z

systemem ERP.

+ZmienStan()

+Synchronizuj()

Diagram STD

Gość

Zarejestrowany klient

Pracownik

Wejście na stronę WWW

Przeglądanie Towaru

Logowanie

Panel administracyjny

Dodawanie towaru do koszyka

Usunięcie towaru z koszyka

Finalizowanie transakcji

Rejestracja

Pobranie faktury

Panel Klienta

Wylogowanie

Modyfikowanie danych klienta

Zarządzanie stanami

magazynowymi

Modyfikowanie danych

pracownika

Zarządzanie kategoriami

Zarządzanie towarami

Diagram ERD