Inżynieria oprogramowania zakupy on line



Inżynieria oprogramowania
Zakupy w sklepie internetowym
dr inż. Mirosław Miciak

Piotr Jaskólski

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.

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


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ę.


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






















Diagram ERD





Wyszukiwarka

Podobne podstrony:
nju mobile na kartę i abonament zakupy on line njumobile
Inżynieria oprogramowania zakupy w sklepie internetowym
zakupy on line njumobile
2006 06 Wstęp do Scrum [Inzynieria Oprogramowania]
Inżynieria oprogramowania II
2006 09 Wielozadaniowość w systemach operacyjnych [Inzynieria Oprogramowania]
25#5902 egzaminator on line
Inżynieria oprogramowania
Osobowość wykład3 on line
2006 03 XFire w akcji [Inzynieria Oprogramowania]
2007 08 UML – modelowanie statycznych aspektów oprogramowania [Inzynieria Oprogramowania]
Inżynieria oprogramowania Diagramy ERD
2006 10 Przegląd modeli cyklu życia oprogramowania [Inzynieria Oprogramowania]
,Inżynieria oprogramowania L, operacje w bazie danych biblioteki
2007 06 UML – potrzeba standaryzacji notacji [Inzynieria Oprogramowania]
2007 11 Extreme Programming i CMMI [Inzynieria Oprogramowania]

więcej podobnych podstron