Merge branch 'cart' into andreas

This commit is contained in:
Andreas Zweili 2018-02-27 18:42:53 +01:00
commit 6bfe1c7ff9
10 changed files with 320 additions and 302 deletions

View File

@ -74,7 +74,6 @@ class CartForm(forms.Form):
class CheckoutForm(forms.Form):
checkout = forms.BooleanField(
required=True,
label='Yes. I have read the General Terms and Conditions.')

View File

@ -84,7 +84,10 @@ class Order(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE)
status = models.ForeignKey(OrderStatus)
date = models.DateTimeField(default=timezone.now)
exchange_rate = models.ForeignKey(ExchangeRate)
exchange_rate = models.ForeignKey(ExchangeRate, null=True)
def __str__(self):
return str(self.id)
class OrderPosition(models.Model):

View File

@ -73,7 +73,7 @@
target='_blank'
href='http://www.ibz.ch'
>This is a case study project of Ivan Hörler and Andreas Zweili.
</br>
<br>
It is a school project/excercise and has no commercial intent.
</a>
</li>

View File

@ -1,7 +1,8 @@
{% extends "webshop/base.html" %}
{% block section_title %}<h1>CHECKOUT</h1>{% endblock %}
{% block section_title %}CHECKOUT{% endblock %}
{% block content %}
<h3>Preview your Purchase:</h3>
<br>
<h4>Shipping Address:</h4>
{% if person %}
<p><b>Salutation: </b>{{ person.salutation }}</p>
@ -17,54 +18,64 @@
<strong>
</p>
{% endif %}
{% if articles_list %}
<h4>Articles:</h4>
<table class="table">
{% if cart_position_list %}
<br>
<h4>Your Items:</h4>
<table class="table price-table">
<tr class="table_header">
<th scope="col">POS.</th>
<th scope="col">ART#</th>
<th scope="col">NAME</th>
<th scope="col">STOCK</th>
<th scope="col">AMOUNT</th>
<th scope="col">PRICE p.pce.</th>
<th scope="col">POSITION PRICE</th>
<th scope="col" class="price-label">PRICE p.pce.</th>
<th scope="col" class="price-label">POSITION PRICE</th>
</tr>
{% for article in articles_list %}
{% for cart_position in cart_position_list %}
<tr class="table_content">
<td scope="col">{{ article.id }}</td>
<td scope="col">{{ article.article.id }}</td>
<td scope="col">{{ cart_position.id }}</td>
<td scope="col">{{ cart_position.article.id }}</td>
<td scope="col">
<a href="{% url 'details' article.article.id %}">
{{ article.article.name }}
<a href="{% url 'details' cart_position.article.id %}">
{{ cart_position.article.name }}
</a>
</td>
<td scope="col">{{ article.article.stock }}</td>
<td scope="col">
{{ article.amount }}
</td>
<td scope="col">
{{ article.article.price_in_chf }}
<td scope="col">{{ cart_position.article.stock }}</td>
<td scope="col">{{ cart_position.amount }}</td>
<td scope="col" class="price-value">
{{ cart_position.article.price_in_chf }}
{{ currency_name }}
</td>
<td scope="col">{{ article.position_price }} {{ currency_name }}</td>
<td scope="col" class="price-value">
{{ cart_position.position_price }} {{ currency_name }}
</td>
</tr>
{% endfor %}
<tr>
<td scope="col" colspan="7" class="text-right">
Total: {{ total }} {{ currency_name }}
<td scope="col" colspan="5" class="text-right">
<td scope="col" class="price-value">
<dt><dl>Total:</dl></dt></td>
<td scope="col" class="price-value">
<dt><dl>{{ total }} {{ currency_name }}</dl></dt>
</td>
</tr>
</table>
<form id="checkout_form" action="" method="POST">
{% csrf_token %}
{{ checkout_form.as_p }}
<input type="submit" value="Order" class="btn btn-success" role="button"/>
</form>
{% else %}
<p class="alert alert-danger">
<strong>
Something whent wrong. Your cart is empty.
Your cart seamed to lack Items.
Go get some in the store!
<strong>
</p>
{% endif %}
<p class="alert text-danger">
<strong>
{{ message }}
<strong>
</strong>
</p>
{% endblock %}

View File

@ -20,7 +20,7 @@
<li><input type="submit" value="Select"></li>
{% csrf_token %}
</form>
{% endif %}
{% endif %}
</li>
</ul>
</div>

View File

@ -0,0 +1,7 @@
{% extends "webshop/base.html" %}
{% load customfilters %}
{% block section_title %}Order{% endblock %}
{% block content %}
<h1> Your order was submitted. </h1>
<h3> Thank you for Purchase. </h3>
{% endblock %}

View File

@ -23,4 +23,7 @@ urlpatterns = [
url(r'^cart/checkout/$',
views.checkout,
name='checkout'),
url(r'^order/$',
views.order,
name='order'),
]

View File

@ -10,7 +10,10 @@ from webshop.models import (Article,
City,
Picture,
CartPosition,
ShoppingCart)
ShoppingCart,
Order,
OrderStatus,
OrderPosition)
from webshop.forms import (RegistrationForm,
AddToCartForm,
CartForm,
@ -83,7 +86,7 @@ def restrict_cart_to_one_article(user_id, article_id, amount, operation):
if operation == 'add':
new_amount = cart_position.amount + amount
if operation == 'replace':
new_amount = amount # ref two times check later !!
new_amount = amount
# if article is in cart already update amount:
cart_position = CartPosition.objects.filter(
article=article_id).update(
@ -177,7 +180,7 @@ def registration(request):
user.last_name = pf['last_name']
user.first_name = pf['first_name']
user.save()
person = Person.objects.create(
Person.objects.create(
salutation=pf['salutation'],
city=City.objects.get(zip_code=pf['zip_code'],
name=pf['city']),
@ -194,6 +197,7 @@ def registration(request):
'user_form': user_form})
@login_required
def cart(request):
category_list = get_categories()
currencies_form = CurrenciesForm
@ -283,11 +287,6 @@ def cart(request):
currency,
cart_position.article.price_in_chf
)
cart_position.position_price = rate.exchange(
currency,
cart_position.position_price
)
amount_form = CartForm(
initial={'amount_form': cart_position.amount}
)
@ -312,112 +311,107 @@ def cart(request):
})
@login_required
def checkout(request):
category_list = get_categories()
currencies_form = CurrenciesForm
amount_form = CartForm
rate = ExchangeRate
article_view = True
article_view = False
currency_name = "CHF"
exchange_rate = False
message = ""
cart_position_list = []
amount_form_list = []
totalprice_list = []
total = 0
cart_position_list_zip = []
# here we configure the users Currency:
person = Person.objects.get(user=request.user.id)
checkout_form = CheckoutForm()
if 'currency' not in request.session:
request.session['currency'] = None
else:
currency = request.session['currency']
# Here we handle all POST Operations:
if request.method == 'POST':
# here we react to a currency dropdown change:
if 'currencies' in request.POST:
print('currencies')
currencies_form = CurrenciesForm(request.POST)
if currencies_form.is_valid():
cf = currencies_form.cleaned_data
if cf['currencies']:
print('currencies cf:', cf)
selection = cf['currencies']
request.session['currency'] = selection.id
currency_name = ExchangeRate_name.objects.get(
id=selection.id)
print('currencies currency_name:', currency_name)
else:
request.session['currency'] = None
# here we react to a change of amount per item in the Cart:
if 'amount_form' in request.POST:
amount_form = CartForm(request.POST)
if amount_form.is_valid():
amount = amount_form.cleaned_data['amount_form']
article_id = request.POST.get('article_id')
operation = 'replace'
restrict_cart_to_one_article(
request.user.id,
article_id,
amount,
operation
)
# here we react to a change of amount per item in the Cart:
if 'delete' in request.POST:
delete = CartForm(request.POST)
if delete.is_valid():
amount = delete.cleaned_data['amount_form']
article_id = request.POST.get('article_id')
amount = 1
operation = 'delete'
restrict_cart_to_one_article(
request.user.id,
article_id,
amount,
operation
)
# here we handle the normal cart view:
# if cart_id is not existent create a cart:
cart_id, created_cart = ShoppingCart.objects.get_or_create(user=request.user)
# get all items in the cart of this customer:
cart_positions = CartPosition.objects.filter(cart=cart_id)
if (cart_positions.count()) > 0:
# make a list out of all articles:
cart_position_list = list(cart_positions)
# enumerate the list of articles and loop over items:
for idx, cart_position in enumerate(cart_position_list):
# scrap out the details to calculate Total of item and Summ of All:
if currency:
# get currencyname to display:
currency_name = ExchangeRate_name.objects.get(id=currency)
# get exchange_rate multiplyed:
cart_position.price_in_chf = rate.exchange(
currency,
cart_position.article.price_in_chf
)
totalprice_list.append(cart_position.price_in_chf)
amount_form = CartForm(
initial={'amount_form': cart_position.amount}
)
amount_form_list.append(amount_form)
cart_position_list[idx] = cart_position
cart_position_list_zip = zip(cart_position_list, amount_form_list)
if currency:
exchange_rate = rate.objects.filter(name=currency).latest('date')
cart = ShoppingCart.objects.get(user=request.user)
if cart:
# get all items in the cart of this customer:
cart_positions = CartPosition.objects.filter(cart=cart)
if (cart_positions.count()) > 0:
# make a list out of all articles:
cart_position_list = list(cart_positions)
# enumerate the list of articles and loop over items:
for idx, cart_position in enumerate(cart_position_list):
if request.session['currency']:
# get currencyname to display:
currency_name = ExchangeRate_name.objects.get(id=currency)
# get exchange_rate multiplyed:
cart_position.article.price_in_chf = rate.exchange(
currency,
cart_position.article.price_in_chf
)
cart_position.calculate_position_price()
totalprice_list.append(cart_position.position_price)
cart_position_list[idx] = cart_position
else:
message = """something whent wrong.
Seams like your cart was
not existent before. How come? """
total = sum(totalprice_list)
checkout_form = CheckoutForm()
registration_form = RegistrationForm()
person = Person.objects.get(user=request.user.id)
# Here we handle all POST Operations:
if request.method == 'POST':
# here we react to a change of amount per item in the Cart:
if 'checkout' in request.POST:
checkout_form = CheckoutForm(request.POST)
if checkout_form.is_valid():
orderstatus = OrderStatus.objects.get(name='ordered')
if exchange_rate:
order = Order.objects.create(user=request.user,
status=orderstatus,
exchange_rate=exchange_rate)
else:
order = Order.objects.create(user=request.user,
status=orderstatus)
print('order', order, 'created:', order)
for position in cart_positions:
OrderPosition.objects.create(
article=position.article,
order=order,
amount=position.amount,
price_in_chf=position.article.price_in_chf
)
return HttpResponseRedirect('/order/')
return render(request, 'webshop/checkout.html',
{'cart_position_list_zip': cart_position_list_zip,
'totalprice_list': totalprice_list,
{'cart_position_list': cart_position_list,
'total': total,
'currencies_form': currencies_form,
'amount_form': amount_form,
'checkout_form': checkout_form,
'registration_form': registration_form,
'article_view': article_view,
'currency_name': currency_name,
'article_view': article_view,
'category_list': category_list,
'message': message,
'person': person
})
def order(request):
cart = ShoppingCart.objects.get(user=request.user)
if cart:
# get all items in the cart of this customer:
cart_positions = CartPosition.objects.filter(cart=cart)
if (cart_positions.count()) > 0:
for cart_position in cart_positions:
restrict_cart_to_one_article(
request.user,
cart_position.article.id,
0,
'delete'
)
else:
message = """something whent wrong.
We cold not delete your cartitems. """
return render(request, 'webshop/order.html', {})

View File

@ -24,11 +24,12 @@ Lustigste entschieden.
- Barewahre-Shop
- *Didgeridoo-Shop*
Aufgrund des eher lustigen Namens dieses Instruments haben wir uns
Aufgrund des eher lustigen Namens dieses Instruments, haben wir uns
entschieden diesen Titel zu verwenden. Die Ursprünge des Instruments
liegen 2000 Jahre, sagen die Forscher 40.000 Jahre, sagen die
Aborigines zurück.
liegen weit zurück. Die Forscher sagen bis zu 2000 Jahre, und die
Aborigines sogar bis 40.000 Jahre.
Zitat:
…Als das Traumzeitvolk die Erde verliess, hinterliess es den Menschen
ein Geschenk: Ein Horn, das ein Klangfeld zwischen ihrer Welt und
unserer erzeugt…\footcite{didgeridoo}
@ -65,7 +66,7 @@ zur Verfügung stehende Zeit ist pro Student mit 80h zu veranschlagen.
Am Ende dieser Zeitspanne soll ein funktionaler Web-Shop mit minimalem
graphischen User Interface entstehen, die dazugehörige Dokumentation
umfasst alle Aspekte um die gewählte Lösung nachzuvollziehen.
Die Projekt wurden in der Tabelle: ([[tab:projektziele]]) zusätzlich noch
Die Projekte wurden in der Tabelle: ([[tab:projektziele]]) zusätzlich noch
nach Prioritäten gewichtet.
#+CAPTION: Projektziele
@ -92,12 +93,12 @@ nach Prioritäten gewichtet.
** Methoden
Die Methodik die, die Gruppe wählt ist Aufgrund der nur zwei Personen
im Team beschränkt. Da jedoch Fehler und Rückschläge erwartet werden
Die Methodik, die die Gruppe wählt, ist aufgrund der nur zwei Personen
im Team beschränkt. Da jedoch Fehler und Rückschläge erwartet werden,
ist eine iterative Methodik unabdingbar. Daher wandte die Gruppe eine
angepasste Version von Scrum an. In dieser wird jeweils während
Sitzungen die Position des Product Owners und des Scrum Masters
eingenommen und die Backlog-Tasks dementsprechend erstellt resp.
eingenommen und die Backlog-Tasks dementsprechend erstellt, resp.
verteilt. Während der Woche arbeiten beide Team-Mitglieder an der
Arbeit als Team-Kollegen
@ -105,13 +106,13 @@ Arbeit als Team-Kollegen
Die benötigten Vorkenntnisse wurden in den vorangegangenen Semestern
erarbeitet und sind in der Basis gefestigt. Diese Arbeit wird
vorwiegend weiterführende Elemente wie Frameworks neu einbringen deren
vorwiegend weiterführende Elemente wie Frameworks neu einbringen, deren
Verhalten letztendlich nicht abgeschätzt werden kann.
** Vision
Wir wollen einen Web-Shop mit geeigneter Software erstellen. Dabei
setzen wir nur freie Software ein (frei im Bezug auf Freiheit nicht
setzen wir nur freie Software ein (frei, in Bezug auf Freiheit, nicht
Preis). Wir untersuchen die Anforderung und wählen die uns als
geeignet erscheinenden Frameworks. Jede noch so kleine Zeiteinsparung
durch vorgefertigte Entwicklungen werden angenommen und dennoch wollen
@ -194,7 +195,7 @@ Abbildung:(\ref{fig:swot}) zu sehen.
\footnotesize{
\begin{itemize}
\item Know-How in Webtechnologien.
\item Quell offene Software ist leichter zu unterhalten.
\item Quelloffene Software ist leichter zu unterhalten.
\item durch Verwendung des Frameworks kann die Entwicklungszeit
stark reduziert werden.
\item Wir als Programmierer haben ein gutes Know-How
@ -209,14 +210,14 @@ Abbildung:(\ref{fig:swot}) zu sehen.
\begin{itemize}
\item Das Framework ist nicht vollkommen. Teile davon müssten
eventuell selber konzipiert/erarbeitet werden.
Welche Teile das sind ist noch nicht ersichtlich.
Durch die Quell offene Lizenz kann dies dem Projekt jedoch
einen Mehrwert geben, in dem diese Teile wiederverwendet
Welche Teile, das sind ist noch nicht ersichtlich.
Durch die Quelloffene Lizenz kann dies dem Projekt jedoch
einen Mehrwert geben, indem diese Teile wiederverwendet
werden können.
\item Der Kunde vertraut uns, und die Beziehung ist gut.
\item Der Kunde vertraut uns und die Beziehung ist gut.
Diese Ausgangslage mag helfen interne Schwächen durch
offene Kommunikation übergehen.
\end{itemize}}
offene Kommunikation zu übergehen.
\end{itemize}
};
\node[
any,
@ -224,11 +225,11 @@ Abbildung:(\ref{fig:swot}) zu sehen.
] at (SWOT-3-2) { % Interne Stärken/ Externe Risiken feld:
\footnotesize{
\begin{itemize}
\item Quell offene Software kann unkontrolliert kopiert werden.
\item Die Implementation von Währungsänderungen ist
\item Quelloffene Software kann unkontrolliert kopiert werden.
\item Die Implementierung von Währungsänderungen ist
nicht trivial. Der Zeitpunkt zu dem die Kosten
eines Produktes sich ändert muss gut durchdacht werden.
\end{itemize}}
eines Produktes sich ändert, muss gut durchdacht werden.
\end{itemize}
};
\node[
any,
@ -237,7 +238,7 @@ Abbildung:(\ref{fig:swot}) zu sehen.
\footnotesize{
\begin{itemize}
\item Wir als Programmierer haben keine Erfahrung im
Konsumsegment unseres Nutzers..
Konsumsegment unseres Nutzers.
\item Die Umsetzung der graphischen Anwendungsoberfläche
könnte sich als schwierig erweisen.
\item Die Umsetzungszeit ist knapp bemessen.
@ -268,23 +269,23 @@ Abbildung:([[fig:umweltgrafik]]) grafisch dargestellt.
#+CAPTION: Umwelt-Analyse
#+ATTR_LATEX: :align |>{\columncolor[HTML]{EFEFEF}}p{0.8cm}|l|l|p{8cm}|l|
#+NAME: tab:umweltanalyse
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| <5> | <20> | <20> | | |
|-------+----------------------+----------------------+-----------------------------------------------+----------------------------------------------|
| <5> | <20> | <20> | | |
| *Nr*.\cellcolor[HTML]{C0C0C0} | *Stakeholder*\cellcolor[HTML]{C0C0C0} | *Einfluss*\cellcolor[HTML]{C0C0C0} | *Anforderung/Wünsche*\cellcolor[HTML]{C0C0C0} | *Wahrscheinlichkeit*\cellcolor[HTML]{C0C0C0} |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| 1. | Auftraggeber | hoch | - Innovatives Produkt auf dem Markt anbieten. | hoch |
| | | | - Einhaltung von Terminen und Qualität. | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| 2. | Kunden | gering | - Einfache Lösung die anpassungsfähig ist. | hoch |
| | | | - Schnell anfangen können. | hoch |
| | | | - Viele Arbeitsschritte Automatisieren | mittel |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| 3. | Interessenten | gering | - Intuitiv bedienbare Webseite | hoch |
| | | | - schnell finden was gesucht wird. | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| 4. | Projektleiter | hoch | - Gutes Innovatives Produkt erschaffen. | mittel |
| | | | - Anerkennung im fachlichen Umfeld | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
|-------+----------------------+----------------------+-----------------------------------------------+----------------------------------------------|
| 1. | Auftraggeber | hoch | - Innovatives Produkt auf dem Markt anbieten. | hoch |
| | | | - Einhaltung von Terminen und Qualität. | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+----------------------------------------------|
| 2. | Kunden | gering | - Einfache Lösung die anpassungsfähig ist. | hoch |
| | | | - Schnell anfangen können. | hoch |
| | | | - Viele Arbeitsschritte automatisieren | mittel |
|-------+----------------------+----------------------+-----------------------------------------------+----------------------------------------------|
| 3. | Interessenten | gering | - Intuitiv bedienbare Webseite | hoch |
| | | | - schnell finden, was gesucht wird. | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+----------------------------------------------|
| 4. | Projektleiter | hoch | - Gutes innovatives Produkt erschaffen. | mittel |
| | | | - Anerkennung im fachlichen Umfeld | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+----------------------------------------------|
#+LATEX:\end{landscape}
#+CAPTION: Stakeholder Diagramm
@ -302,15 +303,15 @@ Abbildung:([[fig:umweltgrafik]]) grafisch dargestellt.
| <10> | <30> | <30> | | |
| *Nr.*\cellcolor[HTML]{C0C0C0} | *Beschreibung*\cellcolor[HTML]{C0C0C0} | *Massnahmen*\cellcolor[HTML]{C0C0C0} | *W^1*\cellcolor[HTML]{C0C0C0} | *A^2*\cellcolor[HTML]{C0C0C0} |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 1. | Die Datenbank ist schlecht modelliert | Das ERM nach dessen Erstellung gründlich auf Fehler prüfen, falls nötig extern prüfen lassen. | 2 | 3 |
| 1. | Die Datenbank ist schlecht modelliert | Das ERM, nach dessen Erstellung, gründlich auf Fehler prüfen, falls nötig extern prüfen lassen. | 2 | 3 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 2. | Viel Arbeit an der Arbeitsstelle, dabei bleibt weniger Zeit für die Casestudy. | Die Zeit die einem zur Verfügung steht nutzen und fixe Tage definieren. Projektplanung machen. | 1 | 2 |
| 2. | Viel Arbeit an der Arbeitsstelle, dabei bleibt weniger Zeit für die Casestudy. | Die Zeit die einem zur Verfügung steht, nutzen und fixe Tage definieren. Projektplanung machen. | 1 | 2 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 3. | Know-How zur Umsetzung ist nicht vollständig vorhanden. | Gute Informationsbeschaffung im Internet, Mitschülern, Arbeitgeber, Dozenten etc. | 2 | 2 |
| 3. | Know-How zur Umsetzung ist nicht vollständig vorhanden. | Gute Informationsbeschaffung im Internet, Mitschülern, Arbeitgebern, Dozenten etc. | 2 | 2 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 4. | Kommunikation innerhalb des Teams. | Klare Arbeitsaufteilung innerhalb des Teams und alle 2 Wochen Besprechungen über offene Aufgaben oder Problembehandlungen | 1 | 1 |
| 4. | Kommunikation innerhalb des Teams. | Klare Arbeitsaufteilung innerhalb des Teams und alle 2 Wochen Besprechungen über offene Aufgaben oder Problembehandlungen. | 1 | 1 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 5. | Die Programmierung des Shops benötigt zu viel Zeit | Bei der Projektplanung genau definieren was die GUI Applikation beinhalten muss. Ziele definieren, Abgrenzungen treffen. | 3 | 1 |
| 5. | Die Programmierung des Shops benötigt zu viel Zeit. | Bei der Projektplanung genau definieren was die GUI Applikation beinhalten muss. Ziele definieren, Abgrenzungen treffen. | 3 | 1 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
*** Risikobewertung
@ -319,7 +320,7 @@ Abbildung:([[fig:umweltgrafik]]) grafisch dargestellt.
#+ATTR_LATEX: :align l|l :placement [H]
#+NAME: tab:wahrscheinlichkeit
| *Bewertung* | *Beschreibung: Wahrscheinlichkeit (W)* |
|-------------+---------------------------------------|
|-------------+----------------------------------------|
| 1 = gering | Unwahrscheinlich, <20% |
| 2 = mittel | Mässig wahrscheinlich, 20-50% |
| 3 = hoch | Hohe Wahrscheinlichkeit > 50% |
@ -340,7 +341,7 @@ Abbildung:([[fig:umweltgrafik]]) grafisch dargestellt.
** TODO Projektabgrenzung
Am ende des Projekts die nicht lauffähigen teile ausgrenzen. :-)
Am Ende des Projekts die nicht lauffähigen Teile ausgrenzen. :-)
* Projektmanagement
** Organigramm
@ -383,8 +384,8 @@ Am ende des Projekts die nicht lauffähigen teile ausgrenzen. :-)
** Projektstrukturplan
** Varianten
Wir haben uns 3 mögliche Varianten überlegt im Bezug auf die zu
verwendende Software. Die Varianten wurden bewertet und die Variante
Wir haben uns 3 mögliche Varianten in Bezug auf die zu
verwendende Software überlegt. Die Varianten wurden bewertet und die Variante
mit den meisten Punkten dann schlussendlich ausgewählt.
Bei jeder Variante wurden die gleichen Kriterien mit der gleichen
Gewichtung bewertet. Die Punktzahl pro Kriterium wird nach der
@ -400,14 +401,14 @@ Punktzahl(/EP/) ergibt das Kriteriumsergebnis(/KE/).
*** ASP.NET und SQL Server
ASP.NET und SQL Server, Tabelle:([[tab:asp-net]]), haben vor allem viele
Punkte verloren da C# nur in Teilen und SQL Server gar nicht unter
Punkte verloren, da C# nur in Teilen und SQL Server gar nicht unter
einer freien Lizenz steht. Des weiteren läuft .NET Core zwar auch auf
Unix Systemen allerdings ist das verhältnismässig ein relativ kleiner
Unix Systemen, allerdings ist das verhältnismässig ein relativ kleiner
Teil der gesamten Sprache. SQL Server läuft hingegen nur unter Windows
und Linux. Des weiteren ist es sehr schwierig C# Applikationen ohne
Visual Studio zu entwickeln. Es geht in der Theorie, in der Praxis ist
es jedoch eher umständlich. Die Vorkenntnisse wurden mit 6 von 10
Punkten bewertet da wir C# zwar im Rahmen der Ausbildung lernen,
Punkten bewertet, da wir C# zwar im Rahmen der Ausbildung lernen,
allerdings noch nicht das Gefühl haben sonderlich gut mit C# umgehen
zu können.
@ -433,18 +434,18 @@ zu können.
*** PHP und MySQL
Die Variante PHP und MySQL, Tabelle:([[tab:php]]), hat insgesamt ein sehr
Die Variante PHP und MySQL, Tabelle:([[tab:php]]), hat insgesamt eine sehr
gute Bewertung erhalten. Beide Projekte sind zumindest teilweise unter
einer freien Lizenz verfügbar und sind sowohl unter Windows, wie auch
Mac und Linux einsetzbar. Allerdings gibt es von MySQL noch eine
proprietäre Enterprise Variante weshalb wir hier nicht die volle
proprietäre Enterprise Variante, weshalb wir hier nicht die volle
Punktzahl vergeben konnten. Abstriche gab es bei der Lesbarkeit des
Codes. Da PHP insgesamt eine ziemlich inkonsistente und ausschweifende
Sprache ist. Dafür ist das Setup sehr einfach und man kann eine PHP
basierte Applikation ohne spezielle Werkzeuge entwickeln. Da wir
jedoch bereits sehr intensiv mit PHP und MySQL in Berührung kamen haben
jedoch bereits sehr intensiv mit PHP und MySQL in Berührung kamen, haben
wir beim Lernfaktor Abstriche gemacht. In Zusammenhang mit einem
Framework hätten wir sicher auch viel dazugelernt im Vergleich zu den
Framework hätten wir sicher auch viel dazugelernt. Im Vergleich zu den
anderen Varianten jedoch auf jeden Fall weniger.
#+CAPTION: Bewertung der Variante PHP und MySQL
@ -472,12 +473,12 @@ anderen Varianten jedoch auf jeden Fall weniger.
Diese Variante, Tabelle:([[tab:django]]), hat am meisten Punkte erhalten.
Wie bei der Variante "PHP und MySQL" sind auch hier beide Komponenten
freie Software. Im Gegensatz zu der vorherigen Variante gibt es bei
diesen Komponenten nur eine mögliche Lizenz Form. Womit sie die volle
diesen Komponenten nur eine mögliche Lizenzform. Womit sie die volle
Punktzahl in dieser Kategorie erreichten.
Beide Projekte laufen unter Windows, Linux sowie Mac. Wobei das Setup
unter für Django(Python) unter Windows etwas komplizierter ausfällt
als wir gerne hätten weshalb wir hier bei der Cross Plattform
für Django(Python) unter Windows etwas komplizierter ausfällt
als wir gerne hätten, weshalb wir hier bei der Cross Plattform
Kompatibilität und dem Setup einen Abstrich gemacht haben. Python kann
ohne spezielle Tools programmiert werden und gilt als eine der
Sprachen mit der leserlichsten Syntax. Die Vorkenntnisse haben wir hier
@ -506,11 +507,11 @@ als eher niedrig eingestuft dafür den Lernfaktor umso höher.
*** Ergebnis
Aufgrund der erreichten Punktzahl, Tabelle:([[tab:result]]), bei den
vorhergehenden Variantenbewertungen haben wir uns dafür entschieden
vorhergehenden Variantenbewertungen, haben wir uns dafür entschieden,
die Variante "Django(Python) und MariaDB" umzusetzen. In der Sektion
[[Werkzeuge]] beschreiben wir noch die weiteren Mittel welche beim
Erstellen der Case Study verwendet wurden und erklären wenn möglich
auch weshalb wir uns dafür entschieden haben.
[[Werkzeuge]] beschreiben wir noch die weiteren Mittel, welche beim
Erstellen der Case Study verwendet wurden und erklären, wenn möglich
auch, weshalb wir uns dafür entschieden haben.
#+CAPTION: Variantenbewertung Ergebnis
#+ATTR_LATEX: :align |>{\columncolor[HTML]{EFEFEF}}p{4.5cm}|r|
@ -536,10 +537,10 @@ Web-Shop an sich sondern generell für alle Tasks im Projekt.
*** Versionskontrolle
Eine Versionskontrollsoftware erschien uns als notwendig um den Code
Eine Versionskontrollsoftware erschien uns als notwendig, um den Code
auf einfache und zuverlässige Weise untereinander austauschen zu
können. Andere Lösungen wie Dropbox, etc. hätten es uns nicht erlaubt
Konflikte zu vermeiden
Konflikte zu vermeiden.
Als Software für die Versionskontrolle wurde Git \footcite{git} gewählt.
Git wurde aus diversen Gründen gewählt:
@ -549,7 +550,7 @@ Git wurde aus diversen Gründen gewählt:
- Es gäbe gratis Services die man nutzen könnte (Github, Gitlab)
- Man kann offline arbeiten und Commits erstellen
- Das Team hat bereits einen eigenen Git Server zur Verfügung
- Das Team ist bereits mit Git aus vorhergehenden Projekten vertraut
- Das Team ist bereits mit Git aus vorhergehenden Projekten vertraut,
dadurch muss man keine Ressourcen aufwenden eine neue Software zu lernen.
Zusätzlich hat sich Git in den vorhergehenden Projekten als robuste
und schnelle Software erwiesen.
@ -557,25 +558,25 @@ Git wurde aus diversen Gründen gewählt:
*** Entwicklungsumgebung
Damit beide Studenten auf der gleichen Basis arbeiten haben wir uns
dazu entschieden den Web-Shop in einer virtuellen Maschine zu
Damit beide Studenten auf der gleichen Basis arbeiten, haben wir uns
dazu entschieden, den Web-Shop in einer virtuellen Maschine zu
entwickeln. Dies führt jedoch in der Regel zum Problem, dass die
Änderungen in der virtuellen Maschine miteinander abgesprochen und
ausgetauscht werden müssen. Um dieses Problem zu beheben haben wir uns
ausgetauscht werden müssen. Um dieses Problem zu beheben, haben wir uns
dazu entschieden Vagrant\footcite{vagrant} zu verwenden.
Vagrant ist freie Software unter der MIT Lizenz.
Vagrant erlaubt es einem den Zustand einer virtuellen Maschine in
einer Text Datei zu beschreiben und diese dann gemäss der Beschreibung
automatisiert aufzusetzen. Dies hat den Vorteil das die Konfiguration
automatisiert aufzusetzen. Dies hat den Vorteil, dass die Konfiguration
der virtuellen Maschine auch ohne Weiteres mit dem restlichen Code in
der Versionskontrollsoftware gepflegt werden kann.
Des weiteren hilft das automatisierte Aufsetzen, das Vermeiden von
menschlichen Fehlern. Somit kann davon ausgegangen werden dass, das
menschlichen Fehlern. Somit kann davon ausgegangen werden, dass das
System in der virtuellen Maschine immer den korrekten Stand zum
Entwickeln hat. Sollte dies nicht mehr der Fall sein lässt sich die
virtuelle Maschine mit einem maximal zwei Befehlen wieder in den
Entwickeln hat. Sollte dies nicht mehr der Fall sein, lässt sich die
virtuelle Maschine mit einem, maximal zwei Befehlen wieder in den
Ursprungszustand zurücksetzen.
Als Hypervisor der virtuellen Maschine wurde
@ -591,7 +592,7 @@ Debian\footcite{debian} in der Version 9 (Stretch) gewählt. Für Debian
haben wir uns vor allem aus folgenden Gründen entschieden:
- Stabiles Betriebsystem
- Sehr guter Paketmanager was einem das Scripting vereinfacht
- Sehr guter Paketmanager, was einem das Scripting vereinfacht
- Gilt als sehr sicher
- Hat sich in vorhergehenden Projekten bereits als gute Basis bewiesen
- Enthält in der Grundkonfiguration nur freie Software (nicht freie
@ -602,20 +603,20 @@ haben wir uns vor allem aus folgenden Gründen entschieden:
*** Deployment Software für Produktionsserver
Auch auf dem produktiven Server haben wir uns für Debian entschieden.
Um diesen aufzusetzen hatten wir in etwa die ähnlichen Anforderungen
Um diesen aufzusetzen, hatten wir in etwa die ähnlichen Anforderungen
wie für die Entwicklungsumgebung. Also einen Weg um das System
möglichst automatisch und reproduzierbar aufzusetzen. Die für die
Entwicklungsumgebung verwendete Software Vagrant ist für produktive
System allerdings eher weniger geeignet.
Systeme allerdings eher weniger geeignet.
Für solche Fälle bietet sich eine Software Namens
"Ansible"\footcite{ansible} an. Diese bietet einem ähnlich wie Vagrant
die Möglichkeit den Zustand eines Systems in Text Dateien zu
"Ansible"\footcite{ansible} an. Diese bietet einem, ähnlich wie Vagrant,
die Möglichkeit, den Zustand eines Systems in Textdateien zu
beschreiben. Allerdings bietet einem Ansible noch zusätzliche
Möglichkeiten und vor allem ein standardisiertes Interface um
unterschiedliche Systeme auf die selbe Weise zu konfigurieren.
Möglichkeiten und vor allem ein standardisiertes Interface, um
unterschiedliche Systeme auf dieselbe Weise zu konfigurieren.
Der Vorteil gegenüber anderen System ist das Ansible mit sehr
Der Vorteil gegenüber anderen System ist, dass Ansible mit sehr
wenig Abhängigkeiten für das zu konfigurierende System daherkommt. Auf
einem Linux System ist nur SSH Zugriff und Python notwendig. Einen
Client braucht man nicht zu installieren.
@ -623,11 +624,11 @@ Ansible ist freie Software unter der GNU Public License v3.
*** Framework
Um die Entwicklung der Applikation zu vereinfachen haben wir uns dazu
Um die Entwicklung der Applikation zu vereinfachen, haben wir uns dazu
entschlossen ein Framework einzusetzen. Frameworks bringen einem in
der Entwicklung diverse Vorteile. Unter anderem bieten sie Hilfen bei
sich wiederholenden Programmieraufgaben und bieten je nachdem die
Möglichkeit die Applikation in einer einzigen Sprache zu schreiben da
Möglichkeit, die Applikation in einer einzigen Sprache zu schreiben, da
sich das Framework auch um die Datenbank kümmert. In der
Webentwicklung helfen sie einem insbesondere auch dabei
Sicherheitslücken wie Cross Site Scripting und SQL Injections
@ -640,8 +641,8 @@ folgenden Gründen für ein Python basiertes Framework gegenüber einem
PHP basierten Framework entschieden:
- Python gilt als die Sprache mit der schöneren Syntax.
- Wir wollten im Bezug auf das Programmieren etwas neues ausprobieren
was sich im Rahmen einer Case Study sehr gut machen lässt. Da man
- Wir wollten im Bezug auf das Programmieren etwas Neues ausprobieren
was sich im Rahmen einer Case Study sehr gut machen lässt, da man
ein "realistisches" Szenarium erhält und dieses in einem relativ
kontrollierten Rahmen ausführen kann.
- Python ist in dem von uns gewählten Hostsystem wie in den meisten
@ -654,7 +655,7 @@ Die verwendete Version war dabei 1.10.7-2 aus dem Debian Stretch Repository.
*** Webserver
Als Webserver verwenden wir ganz klassisch Apache\footcite{apache}.
Dies vor allem aus dem Grund das wir Apache aus diversen vorhergehenden
Dies vor allem desswegen weil wir Apache aus diversen vorhergehenden
Projekten bereits sehr gut kennen und sich der Webserver dort sehr gut
bewährt hat. Apache wird dabei auch noch gut von Django unterstützt.
Der Apache Webserver ist freie Software unter der Apache License 2.0
@ -668,7 +669,7 @@ vorhergehenden Projekt kennen. MariaDB ist ein Fork von MySQL welcher
gegenüber MySQL rückwärts kompatibel ist. MariaDB ist dabei jedoch viel
Community näher als MySQL und wird dabei auch sehr demokratisch
entwickelt\footcite{mariadbgov}. MariaDB gehört dabei keiner einzelnen
Firma oder Person sonder der gemeinnützigen Organisation "MariaDB
Firma oder Person sondern der gemeinnützigen Organisation "MariaDB
Foundation". Was für zusätzliche Stabilität sorgen sollte. MariaDB ist
freie Software unter GNU Public License v2. Des weiteren hat MariaDB bei
einer Variantenbewertung das beste Ergebnis geholt.
@ -677,12 +678,12 @@ einer Variantenbewertung das beste Ergebnis geholt.
*** Editoren
Das Hauptwerkzeug von jedem Entwickler ist sein Text Editor. Dabei
hat jeder meistens seine ganz eigene Präferenzen wenn es um die Wahl
hat jeder meistens seine ganz eigene Präferenzen, wenn es um die Wahl
des Editors geht.
- Atom :: Ivan hat während der Case Study hauptsächlich mit
Atom\footcite{atom} gearbeitet. Atom wird von Github Inc.
entwickelt und basiert auf dem Electron Framework welches
entwickelt und basiert auf dem Electron Framework, welches
seinerseits auf Webtechnologien wie Node.js und Chromium
basiert. Atom ist freie Software unter der MIT Lizenz.
@ -695,18 +696,18 @@ des Editors geht.
*** Dokumentation
Diese Dokumentation wurde in Org-mode\footcite{orgmode} einer
Erweiterung für den Text Editor Emacs geschrieben. Anschliessend wurde
Diese Dokumentation wurde in Org-mode\footcite{orgmode}, einer
Erweiterung für den Text Editor Emacs, geschrieben. Anschliessend wurde
die Dokumentation in LaTeX\footcite{latex} Code konvertiert und
finalisiert. Der Zwischenschritt über Org-mode wurde gewählt weil
finalisiert. Der Zwischenschritt über Org-mode wurde gewählt, weil
Org-mode etwas einfacher zu schreiben ist als reines LaTeX.
LaTeX ist eine Software welche einem die Benutzung des Textsatzsystems
LaTeX ist eine Software, welche einem die Benutzung des Textsatzsystems
TeXs vereinfacht. Wir haben LaTeX gegenüber einem "What You See Is
What You Get" Editor gewählt weil es einem mit seiner Markup Sprache
erlaubt das Dokument in Text Dateien zu erstellen. Was wir als
Programmierer sehr angenehm finden. Dadurch das LaTeX auch nur aus
reinen Textdateien besteht kann man die Dokumente auch ohne weiteres
What You Get", Editor gewählt weil es einem mit seiner Markup Sprache
erlaubt das Dokument in Text Dateien zu erstellen, was wir als
Programmierer sehr angenehm finden. Dadurch, dass LaTeX auch nur aus
reinen Textdateien besteht, kann man die Dokumente auch ohne weiteres
in die Versionskontrollsoftware einchecken und somit auf einfache
Weise zusammen daran arbeiten und die Entwicklung im Log
zurückverfolgen.
@ -718,52 +719,52 @@ Software unter der GNU Public License v3. Für das Entity Relation
Diagramm in [[Modells]] haben wir jedoch Dia\footcite{dia} verwendet. Dia
ist freie Software unter der GNU Public License v2.
Die Klassen Diagramme haben wir mit der Django Erweiterung
Die Klassendiagramme haben wir mit der Django Erweiterung
"Django-Extensions"\footcite{django_extensions} erstellt.
Django-Extensions ist freie Software unter der MIT Lizenz.
** Spezifikation
*** User Stories
User Stories sind eine in Alltagssprache geschriebenen
User Stories sind in Alltagssprache geschriebene
Software-Anforderungen. Sie sind bewusst kurz gehalten und beschreiben
die Wünsche und Ziele der Rollen welche die Software
die Wünsche und Ziele der Rollen, welche die Software
verwenden.\footcite{userstory}
**** Auftraggeber/Verwaltung
Als Anbieter möchte ich...
- Artikel in Kategorien strukturieren damit Kunden sich orientieren können.
- Bilder zu meinen Artikeln hinzufügen damit sich Kunden das Produkt
- Artikel in Kategorien strukturieren, damit Kunden sich orientieren können.
- Bilder zu meinen Artikeln hinzufügen, damit sich Kunden das Produkt
anschauen können.
- Artikel aktiv oder versteckt schalten können damit ich Produkte auch
- Artikel aktiv oder versteckt schalten können, damit ich Produkte auch
temporär aus dem Verkauf nehmen kann.
- Lagerbestände verwalten können damit ich rechtzeitig nachbestellen kann.
- Nachbestellungen von Artikeln erfassen können damit ich weiss was
- Lagerbestände verwalten können, damit ich rechtzeitig nachbestellen kann.
- Nachbestellungen von Artikeln erfassen können, damit ich weiss, was
bestellt wurde.
- eine komplette Liste meiner Artikel einsehen können damit ich einen
- eine komplette Liste meiner Artikel einsehen können, damit ich einen
Überblick über meine Produkte habe.
- eine Liste aller Bestellungen einsehen können um allenfalls
- eine Liste aller Bestellungen einsehen können, um allenfalls
Anpassungen vornehmen zu können.
- Produkte und Kategorien in einer Admin Seite editieren können um
- Produkte und Kategorien in einer Admin Seite editieren können, um
diese einfach administrieren zu können.
**** Kunde
Als Kunde möchte ich...
- durch Kategorien zu den Produkten navigieren um diese einfacher zu finden.
- Artikel einem Warenkorb hinzufügen können damit ich ungestört
- Artikel einem Warenkorb hinzufügen können, damit ich ungestört
stöbern kann und erst am Schluss den administrativen Teil erledigen muss.
- meinen Warenkorb anzeigen und editieren können um allenfalls
Korrekturen vornehmen zu können.
- die Artikel in meinem Warenkorb bestellen können.
- vor dem Abschluss des Kaufs eine Zusammenstellung der Bestellung
einsehen um die Richtigkeit der Daten zu überprüfen.
- mich registrieren können damit ich meine Adresse nicht jedes Mal neu
- mich registrieren können, damit ich meine Adresse nicht jedes Mal neu
eingeben muss.
- in einem Bereich der Webseite meine Profildaten zur Überprüfung
einsehen können.
- Artikel in meiner bevorzugten Währung kaufen können damit ich die
- Artikel in meiner bevorzugten Währung kaufen können, damit ich die
Preise nicht umrechnen muss.
**** Interessenten
@ -778,7 +779,7 @@ Als Interessent möchte ich...
Ein Use Case sammelt alle möglichen Szenarien, die eintreten können,
wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein
bestimmtes Ziel zu erreichen. Dabei beschreibt er was beim Versuch der
bestimmtes Ziel zu erreichen. Dabei beschreibt er, was beim Versuch der
Zielerreichung passieren kann. Je nach Ablauf kann auch ein Fehlschlag
ein Ergebnis eines Anwendungsfalls sein (e.g. falsches Passwort beim
Login). Dabei wird die technische Lösung nicht konkret beschrieben.
@ -808,15 +809,15 @@ Webshops beschränkt.
**** Use Cases Detailbeschreibung
Use Cases werden in der Regel mit Hilfe einer sogenannten Use Case
Schablone im Detail beschrieben damit klar ist wie der Ablauf jeweils
Schablone im Detail beschrieben, damit klar ist, wie der Ablauf jeweils
genau aussieht. Die von uns verwendete Schablone wurde von Alistair
Cockburn definiert.
Da ein Web-Shop eine sehr umfangreiche Applikation ist gibt es sehr
viele Use Cases welche beschrieben und umgesetzt werden müssen. Aus
Da ein Web-Shop eine sehr umfangreiche Applikation ist, gibt es sehr
viele Use Cases, welche beschrieben und umgesetzt werden müssen. Aus
zeitlichen Gründen haben wir nur einen kleinen Teil der Use Cases im
Detail ausgearbeitet. Insbesondere diese welche wir selber
aus programmiert haben. Die gesamte Liste an Use Cases sieht wie folgt
Detail ausgearbeitet. Insbesondere diese, welche wir selber
ausprogrammiert haben. Die gesamte Liste an Use Cases sieht wie folgt
aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
#+LATEX: {\footnotesize
@ -850,7 +851,7 @@ aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
| | <30> |
| *Identifier + Name* | 1.0 Artikel durchstöbern |
|---------------------+--------------------------------|
| *Description* | Durch klicken der verschiedenen Kategorien und ansehen der Artikel Details und Bilder. |
| *Description* | Durchklicken der verschiedenen Kategorien und ansehen der Artikel, Details und Bilder. |
|---------------------+--------------------------------|
| *Actors* | Kunden, Interessenten |
|---------------------+--------------------------------|
@ -865,14 +866,14 @@ aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
| *Postconditions* | - |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Website aufrufen |
| | 2. Kategorien durchsehen |
| | 2. Kategorien durchsehen |
| | 3. Artikel anklicken |
|---------------------+--------------------------------|
| *Alternative Flow* | - |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Draft erstellt durch AZ |
| *UC History* | 1.0 Draft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
@ -894,7 +895,7 @@ aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
|---------------------+--------------------------------|
| *Actors* | Interessent |
|---------------------+--------------------------------|
| *Status* | Freigegeben |
| *Status* | Freigegeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
@ -910,7 +911,7 @@ aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
| | 4. Die Website leitet ihn in den Login Bereich um. |
|---------------------+--------------------------------|
| *Alternative Flow* | 1. User klickt auf den Link "Go to registration.". |
| | 2. User füllt das Registrations Formular mir falschen Daten aus. |
| | 2. User füllt das Registrationsformular mir falschen Daten aus. |
| | 3. Die Website gibt die entsprechenden Fehler aus. |
| | 4. Der User korrigiert die Angaben. |
| | 5. User schliesst die Registrierung mit Klick auf "Register" ab. |
@ -1115,7 +1116,7 @@ aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Ein Administrator möchte ein Passwort zurücksetzen weil es vergessen wurde. |
| *Trigger* | Ein Administrator möchte ein Passwort zurücksetzen, weil es vergessen wurde. |
|---------------------+--------------------------------|
| *Preconditions* | Account mit Administrationsrechten vorhanden. |
|---------------------+--------------------------------|
@ -1165,7 +1166,7 @@ aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Um das Sortiment zu erweitern möchte der Administrator einen neuen Artikel erfassen. |
| *Trigger* | Um das Sortiment zu erweitern, möchte der Administrator einen neuen Artikel erfassen. |
|---------------------+--------------------------------|
| *Preconditions* | Account mit Administrationsrechten vorhanden. |
|---------------------+--------------------------------|
@ -1308,7 +1309,7 @@ aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
|---------------------+--------------------------------|
| *Preconditions* | Account mit Administrationsrechten vorhanden. |
|---------------------+--------------------------------|
| *Postconditions* | Die Bestellung hat eine angepasste Artikel Menge. |
| *Postconditions* | Die Bestellung hat eine angepasste Artikelmenge. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| | 2. Admin klickt auf "Orders" und anschliessend auf die passende Order ID. |
@ -1328,20 +1329,20 @@ aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
|---------------------+--------------------------------|
#+LATEX:}
*** Modells
*** Models
Wie bereits in [[Framework]] beschrieben übernimmt das Framework die
Wie bereits in [[Framework]] beschrieben, übernimmt das Framework die
Erstellung der Tabellen in der Datenbank. Für den Aufbau der Anwendung
und der Kommunikation im Team ist es jedoch von absoluter
Notwendigkeit das man sich über die Beziehung zwischen den Objekten
Gedanken macht. Insbesondere wenn die Anwendung nach wie vor auf einer
Notwendigkeit, dass man sich über die Beziehung zwischen den Objekten
Gedanken macht. Insbesondere, wenn die Anwendung nach wie vor auf einer
relationalen Datenbank basiert. Aus diesem Grund haben wir vor Beginn
der Arbeit ein klassisches Entity Relation Diagramm aufgezeichnet.
Während der Entwicklung haben wir es dann kontinuierlich erweitert und
korrigiert. Das finale Ergebnis ist in der Abbildung:([[fig:erd]]) zu sehen.
Django übernimmt dann jedoch das Erstellen der Tabellen und Benennen
derjenigen weshalb das Resultat in der Datenbank etwas anders
Django übernimmt dann jedoch das Erstellen und Benennen
der Tabellen, weshalb das Resultat in der Datenbank etwas anders
aussieht. Zusätzlich kommt Django auch noch mit eigenen Tabellen
daher. Der finale Aufbau der Datenbank ist in der
Abbildung:([[fig:final_erd]]) zu sehen. Dieses ERD wurde mit der Django
@ -1372,14 +1373,14 @@ beschreiben und auf jeweils spezifische Probleme eingehen.
Das "Category" Modell, Abbildung:([[fig:category]]), ist der Kernpunkt der
Artikelnavigation und vom Aufbau her eigentlich eher simpel.
Allerdings hatten wir etwas Mühe die hierarchische Darstellung im
Allerdings hatten wir etwas Mühe, die hierarchische Darstellung im
Template sauber abzubilden. Hier half uns ein Artikel\footcite{tree}
von Stackoverflow auf die richtige Lösung zu kommen. Nämlich das sich
das Ganze um zwei in einander verschachtelte Dictionaries handelt.
von Stackoverflow auf die richtige Lösung zu kommen mit dem Hinweis,
dass sich das ganze um zwei in einander verschachtelte Dictionaries handelt.
Somit konnten wir dann über die Kategorie iterieren.
#+ATTR_LATEX: :width 9cm :placement [H]
#+CAPTION: Klassenmodelll für Kategorien
#+CAPTION: Klassenmodell für Kategorien
#+NAME: fig:category
[[file:pictures/class_category.png]]
@ -1387,23 +1388,23 @@ Somit konnten wir dann über die Kategorie iterieren.
Gemäss der Anforderung FA_1.4 muss es möglich sein für einen Artikel 0-5
Bilder hochzuladen. Wir stellen dies über eine Variabel im "Option"
Modell, Abbildung:([[fig:option]]), sicher gegen welche beim Speichern
überprüft wird. Die Variabel ist als Option im Admin Interface
Modell ( Abbildung:([[fig:option]]) ) sicher, gegen welche beim Speichern
geprüft wird. Die Variabel ist als Option im Admin Interface
hinterlegt. Dadurch ist es möglich den Wert auch nachträglich
noch zu ändern oder ganz zu deaktivieren.
Da diese Variabel jedoch essentiell für die Funktion des Webshops ist
mussten wir sicherstellen das sie von einem Administrator nicht aus
Versehen gelöscht oder umbenannt wird. Des weiteren macht es in der
Applikation im Momentan wenig Sinn wenn der User selber Optionen
Da diese Variabel jedoch essentiell für die Funktion des Webshops ist,
mussten wir sicherstellen, dass sie von einem Administrator nicht aus
Versehen gelöscht oder umbenannt wird. Des Weiteren macht es in der
Applikation momentan wenig Sinn, wenn der User selber Optionen
hinzufügen kann. Aus diesen Gründen haben wir für das "Option" Modell
den "Add" Button\footcite{removeadd} und die "Delete"
Option\footcite{removedelete} entfernt, sowie den Namen im Admin
Option\footcite{removedelete} entfernt sowie den Namen im Admin
Interface nur lesbar gemacht\footcite{readonly}. Somit ist nur noch
der Wert editierbar.
#+ATTR_LATEX: :width 9cm :placement [H]
#+CAPTION: Klassenmodelll für Optionen
#+CAPTION: Klassenmodell für Optionen
#+NAME: fig:option
[[file:pictures/class_option.png]]
@ -1413,11 +1414,11 @@ Das Modell "ArticleStatus", Abbildung:([[fig:articlestatus]]), wird über
einen Fremdschlüssel mit dem "Article" Modell verbunden und gibt
diesem verschiedene Status. Gemäss der Anforderung FA_1.4 muss ein
Artikel die Status "active" und "hidden" haben. Wir haben dies in der
Applikation dann auch gleich so umgesetzt das nur die Artikel
Applikation dann auch gleich so umgesetzt damit nur die Artikel
angezeigt werden welche nicht den Status "hidden" haben.
#+ATTR_LATEX: :width 9cm :placement [H]
#+CAPTION: Klassenmodelll für Artikelstatus
#+CAPTION: Klassenmodell für Artikelstatus
#+NAME: fig:articlestatus
[[file:pictures/class_articlestatus.png]]
@ -1425,18 +1426,18 @@ angezeigt werden welche nicht den Status "hidden" haben.
Wir legen die Wechselkurse im Modell "ExchangeRate",
Abbildung:([[fig:exchangerate]]), ab. Um Manipulationen aufs Datum und den
Namen einfacher zu machen werden diese beiden Attribute als
Namen einfacher zu machen, werden diese beiden Attribute als
Fremdschlüssel hinterlegt. Die Wechselkurse werden dabei aus dem RSS
Feed\footcite{snb} der Schweizerischen Nationalbank stündlich
abgeholt. Vor dem Ablegen in der Datenbank wird dann noch überprüft ob
abgeholt. Vor dem Ablegen in der Datenbank wird dann noch überprüft, ob
sich die Werte geändert haben oder nicht.
Wir haben uns für den die Daten der SNB entschieden da sie einerseits
Wir haben uns für die Daten der SNB entschieden, da sie einerseits
die benötigten Wechselkurse anbieten und anderseits bereits von unserer
Basiswährung CHF ausgehen. Dadurch müssen wir nicht zuerst aus einer
anderen Währung zurückrechnen.
#+ATTR_LATEX: :width 9cm :placement [H]
#+CAPTION: Klassenmodelll für Wechselkurse
#+CAPTION: Klassenmodell für Wechselkurse
#+NAME: fig:exchangerate
[[file:pictures/class_exchangerate.png]]
@ -1453,15 +1454,15 @@ eine Liste mit allen möglichen Währungsnamen abgelegt.
**** ExchangeRate_date
Damit die Wechselkurse des Tages einfacher auf einer Zeile angezeigt
werden können haben wir das Datum in ein eigenes Modell,
werden können, haben wir das Datum in ein eigenes Modell,
Abbildung:([[fig:exchangerate_date]]), ausgelagert. Dabei wird das Datum
als Standardwert mitgegeben. Wir hatten dies zu Beginn noch falsch
implementiert und das Datum als Funktion übergeben. Das führte jedoch
dazu, dass die Funktion einmal beim Starten des Servers ausgeführt
wurde und alle Wechselkurse immer das gleiche Datum hatten. Auf
Stackoverflow fanden wir dann die Lösung\footcite{timezone} das wir
die Datumsfunktion als Variabel übergeben müssen damit sie bei jedem
Erstellen des Objekt evaluiert wird.
Stackoverflow fanden wir dann die Lösung\footcite{timezone}, die
Datumsfunktion als Variabel zu übergeben damit sie bei jedem
Erstellen des Objektes evaluiert wird.
#+ATTR_LATEX: :width 9cm :placement [H]
#+CAPTION: Klassenmodell für Wechselkurse
@ -1475,7 +1476,7 @@ sehr komplex und widerspiegelt einen Artikel aus der realen Welt.
Gemäss der Anforderung FA_1.4 hat er eine eindeutige ID (den
Primärschlüssel), einen Namen von maximal 200 Zeichen, eine
Beschreibung von maximal 2000 Zeichen, Status sowie 0 - 5
Produktbilder welche vom Modell "Picture" über einen Fremdschlüssel
Produktbilder, welche vom Modell "Picture" über einen Fremdschlüssel
zugewiesen werden.
#+ATTR_LATEX: :width 9cm :placement [H]
@ -1486,7 +1487,7 @@ zugewiesen werden.
**** OrderStatus
Damit nachvollzogen werden kann in welchen Zustand sich eine
Bestellung gerade befindet haben wir ein Modell "OrderStatus",
Bestellung gerade befindet, haben wir ein Modell "OrderStatus",
Abbildung:([[fig:orderstatus]]), erstellt. Für dieses Modell sind folgende
Status angedacht:
- ordered -> vom Kunden bestellt
@ -1539,9 +1540,9 @@ Foreign Key zum "ExchangeRate" Modell. Über den Foreign Key wird eine
Beziehung auf den für die Bestellung aktuellen Wechselkurs der Währung
hergestellt.
Da sich bei der Beziehung zwischen den Artikeln und dem Kunden um eine
"Viele zu Viele" Beziehung handelt braucht es noch ein zusätzliches
Modell welches die Beziehung abbildet. Dies realisieren wir über das
Da es sich bei der Beziehung zwischen den Artikeln und dem Kunden um eine
"Viele zu Viele" Beziehung handelt, braucht es noch ein zusätzliches
Modell, welches die Beziehung abbildet. Dies realisieren wir über das
Modell "OrderPostion", Abbildung:([[fig:orderposition]]).
In diesem Modell werden dann noch zusätzlich die bestellte Menge sowie
@ -1561,13 +1562,13 @@ welchem Preis die Ware bezogen wurde.
**** ShoppingCart und ShoppingCartPosition
Bevor die Bestellungen erfasst werden kann der Kunde die Artikel in
Bevor die Bestellungen erfasst werden, kann der Kunde die Artikel in
einem Warenkorb sammeln. Dieser funktioniert sehr ähnlich wie die
Bestellungen. Über das Modell "ShoppingCart",
Abbildung:([[fig:shoppingcart]]), und das Modell "ShoppingCartPosition",
Abbildung:([[fig:shoppingcartposition]]), werden die ausgewählten Artikel
sowie ihre Mengen einem User zugewiesen. Im Gegensatz zur Bestellung
wird im Artikel jedoch der Preis nicht gespeichert da sich der Preis
wird im Artikel jedoch der Preis nicht gespeichert, da sich der Preis
vor der Bestellung noch ändern könnte. Wenn die Verwaltung etwa die
Preise anpasst oder die Währungskurse ändern.
@ -1583,8 +1584,8 @@ Preise anpasst oder die Währungskurse ändern.
**** City
Das "City" Modell speichert Städte Namen und die dazugehörige
Postleitzahl Die Städte werden als Teil der Adresse auf dem "Person"
Das "City" Modell speichert Städtenamen und die dazugehörige
Postleitzahl. Die Städte werden als Teil der Adresse auf dem "Person"
Modell hinterlegt. Im aktuellen Zustand der Applikation enthält die
Tabelle die Daten aller Schweizer Städte.
@ -1595,8 +1596,8 @@ Tabelle die Daten aller Schweizer Städte.
**** Salutation
"Salutation", zu Deutsch Anrede, ist das Modell welches die möglichen
Anreden beinhaltet die ein User für sich hinterlegen kann.
"Salutation", zu Deutsch Anrede, ist das Modell, welches die möglichen
Anreden beinhaltet, die ein User für sich hinterlegen kann.
Für den Moment haben wir die folgenden Auswahlmöglichkeiten
hinterlegt:
- Herr
@ -1618,18 +1619,18 @@ erweitern kann. In einem Post\footcite{usermodel} von Vitor Freitas
werden die möglichen vier Varianten aufgeführt und erklärt. Eine davon
ist nicht dafür gemacht zusätzliche Informationen zu speichern. Zwei
weitere Varianten bauen darauf auf von einer Basis "User" Klasse
abzuleiten. Die erste Variante war für unsere Zwecke nicht geeignet da
abzuleiten. Die erste Variante war für unsere Zwecke nicht geeignet, da
wir zwingend zusätzliche Informationen speichern wollten. Die
Varianten mit Vererbungen erschienen uns ungeeignet da die Möglichkeit
besteht die Sicherheit der Authentifizierung zu schwächen. Aus diesem
Varianten mit Vererbungen erschienen uns ungeeignet, da die Möglichkeit
besteht, die Sicherheit der Authentifizierung zu schwächen. Aus diesem
Grund wird in der Django Dokumentation eher davor abgeraten diese
Varianten zu verwenden wenn man nicht genau weiss was man macht.
Varianten zu verwenden, wenn man nicht genau weiss, was man macht.
Die verbleibende Variante erweitert das "User" Modell über eine
"One-to-One" Beziehung ein sogenanntes "Profil". Dadurch bleibt das
"One-to-One" Beziehung, ein sogenanntes "Profil". Dadurch bleibt das
"User" Modell intakt und man kann zusätzliche Informationen über den
User speichern. Man sollte im Profil jedoch nur Daten speichern welche
nicht sicherheitsrelevant sind. Der Nachteil dieser Variante ist das
User speichern. Man sollte im Profil jedoch nur Daten speichern, welche
nicht sicherheitsrelevant sind. Der Nachteil dieser Variante ist, dass
die Datenbank mit zusätzlichen Anfragen belastet werden kann.
#+ATTR_LATEX: :width 9cm :placement [H]
@ -1680,29 +1681,29 @@ jeden Benutzer wird eine listitem erstellt und der Username als Text eingefügt.
*** Backend Umsetzung
Django ist ein modellbasiertes Framework das die Programmierung der
Django ist ein modellbasiertes Framework, das die Programmierung der
Datenbank gleich selbst regelt. Dadurch lässt sich backend seitig
durchgängig in Python arbeiten. Die Umsetzung gliedert sich
vereinfacht in 3 Bereiche:
1. Einem Frontend dass für den Benutzer gemacht ist und das mehrere
1. Einem Frontend, das für den Benutzer gemacht ist und das mehrere
Submodule wie Categories oder Warenkorb beinhaltet.
2. Ein Backend welches zum Bearbeiten/Erstellen von Produkten dient.
3. Currencies die täglich abgeholt werden
2. Ein Backend, welches zum Bearbeiten/Erstellen von Produkten dient.
3. Currencies, die täglich abgeholt werden
** TODO Testing
Um die Funktionalität des Webshops sicherzustellen haben wir Die
Um die Funktionalität des Webshops sicherzustellen, haben wir die
Applikation kontinuierlich gemäss den Testfällen unter [[Testfälle]]
getestet und geprüft. Bei den Testfällen haben wir uns wie auch bei
den Use Cases hauptsächlich auf die Funktionen beschränkt welche wir
selber aus programmiert haben. Auch sehr hilfreich war das Admin
den Use Cases hauptsächlich auf die Funktionen beschränkt, welche wir
selber ausprogrammiert haben. Auch sehr hilfreich war das Admin
Interface von Django. Damit konnten wir die Modells sehr gut auf ihre
Funktionalität überprüfen bevor wir sie im Frontend verwendeten.
Funktionalität überprüfen, bevor wir sie im Frontend verwendeten.
*Fixtures*
Django hat ein Funktion\footcite{fixtures} genannt "Fixtures" welche
es einem erlaubt fixe Daten in die Datenbank zu schreiben. Dabei
Django hat eine Funktion\footcite{fixtures}, genannt "Fixtures", welche
es einem erlaubt, fixe Daten in die Datenbank zu schreiben. Dabei
werden die Daten in YAML Syntax in eine .yaml Datei geschrieben und
mittels folgendem Befehl dann in die Datenbank geladen:
@ -1714,7 +1715,7 @@ python3 /vagrant/django/didgeridoo/manage.py loaddata webshop
Wir haben diese Funktion verwendet um Testdaten in der Datenbank zu
speichern. Somit mussten wir etwa nicht von Hand Artikel oder User
erfassen. Zumindest nicht mehr sobald wir sicher waren das die
erfassen. Zumindest nicht mehr, als wir sicher waren, dass die
dazugehörige Funktionen korrekt funktionieren.
#+LATEX:\newpage
@ -1722,7 +1723,7 @@ dazugehörige Funktionen korrekt funktionieren.
*** NEXT Testfälle
Alle Testfälle werden ausgehend von der Index Seite aus gestartet.
Alle Testfälle werden von der Index Seite aus gestartet.
Dies wird in den Test Cases nicht noch einmal explizit erwähnt. Die
Tabelle: ([[tab:testcases]]) zeigt dabei die Resultate des letzten
Testlaufs. Dabei wurden keine Probleme mehr mit der Applikation
@ -1752,7 +1753,7 @@ entdeckt.
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-08* | Artikel in Warenkorb legen | - | 1. Auf "Article of First Parent Category" klicken. | - | Meldung "please login to fill your basket..." | Die Artikel Details werden angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-09* | Artikel in Warenkorb legen | TC-02\newline ausgeführt | 1. Auf "Article of First Parent Category"\newline 2. In das "Amount in piece." Feld Die Menge eintragen.\newline 3. Auf den "Add to Cart" Button klicken.\newline 4. Auf "CART" klicken. | Menge: 5 | Der Artikel wird als Warenkorb Position in der Datenbank gespeichert. | Der Cart mit dem Artikel wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
| *TC-09* | Artikel in Warenkorb legen | TC-02\newline ausgeführt | 1. Auf "Article of First Parent Category"\newline 2. In das "Amount in piece" Feld Die Menge eintragen.\newline 3. Auf den "Add to Cart" Button klicken.\newline 4. Auf "CART" klicken. | Menge: 5 | Der Artikel wird als Warenkorb Position in der Datenbank gespeichert. | Der Cart mit dem Artikel wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-10* | Währung ändern | - | 1. Auf das Dropdown "Currencies" klicken.\newline 2. Den Eintrag "EUR" auswählen.\newline 3. Auf den Button "Select" klicken. | - | Die Artikel Preise werden in Euro angezeigt. | Die Index Seite wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|

View File

@ -10,7 +10,7 @@
\renewcommand{\abstractname}{Management Summary}
\begin{abstract}
Dies ist die Dokumentation für die zweite Case Study im Fach
Webtechnologien von Ivan Hörler und Andreas Zweili. Welche diese im
Webtechnologien von Ivan Hörler und Andreas Zweili, welche diese im
Rahmen ihres 5. Semesters an der IBZ Schule in Aarau erarbeiteten. Die
Case Study behandelt dabei das Erstellen eines Web-Shops und der dafür
gewählten Werkzeuge, die Projektplanung sowie die dabei aufgetretenen
@ -18,7 +18,7 @@ Probleme.
Zusätzlich sollen auch die Erfahrungen der Studenten im Zusammenhang
des verwendeten Frameworks Django aufgezeigt werden. Dieses ist nicht
Teil des Kurikulums weshalb diese Arbeit interessante zusätzliche
Teil des Kurikulums, weshalb diese Arbeit interessante, zusätzliche
Möglichkeiten im Bereich der Entwicklung von Webapplikationen
aufzeigen kann.
\end{abstract}