Inhalt
- Worum geht es?
- Die Aufgabenstellung
- Use Cases
- Fachliches Datenmodell
- Logisches Datenmodell
- Statusmodell für ein Objekt vom Typ `Order`
In dieser Übung bereiten wir schon einmal auf den ersten Meilenstein M0 vor, in dem Sie eine ähnliche Aufgabenstellung bekommen werden. Sie werden ein einfaches eCommerce-System modellieren.
In diesem Semester werden wir uns damit beschäftigen, ein stark vereinfachtes (aber im Kern trotzdem realistisches) eCommerce-System zu implementieren. Im ersten Meilenstein M0 bekommen Sie erst einmal eine einfache Aufgabenstellung ohne weitere Vorgaben, die Sie nach eigenem Ermessen in Java lösen sollen. (In den weiteren Meilensteinen wird es dann immer wieder neue Anforderungen, aber auch andere Vorgaben geben.) In dieser Übung machen wir einen groben “Vorgriff” auf M0.
Wie auch in ST1 formulieren wir alle Aufgabenstellungen auf Englisch.
Your software development company has been contracted to delevop an eCommerce system for a small online shop. The shop sells a number of products, which are not perishable and not fragile. A product has a name, description, and size. In addition, it has a purchase price (Einkaufspreis), and a sales price. Shop admins can add new products to the shop catalog, or drop products from it.
The shop sells products to end customers. A customer has a name, an email address, a date of birth, and a shipping address. There is no user name, i.e. a customer can only be identified by his email address. A customer can place an order for one or more products. There are no products with an age limit, i.e. all products can be sold to all customers. However, the shop has a minimum age limit of 18 years.
The shop has only one warehouse, which stores all products. The warehouse contains some products from the catalog in stock, but not necessarily all products. Customers can order only products that are in stock. For simplicity reasons, customer returns will not be handled by the system (for now), but outside the system via email. Shop admins can manually change the stock level after having received a customer return, ordered new products, or dropped products from the catalog.
When a customer orders products, he/she puts them in the shopping basket first. By that action, the products are reserved for the customer, and cannot be ordered by other customers. There is (as of now) no time limit for the reservation. The customer can remove products from the shopping basket, or place the order. The order is then processed by the shop. The order is then processed by the shop. There are no shipping costs - the price for shipping is factored into the sales price. Payment is done via a payment system (API) that is not part of the system. After successful payment, the products are handed over to the shipping company (API) that is not part of the system. The shipping company delivers the products to the customer. The shop has only one shipping and one payment partner.
Ermitteln Sie die Use Cases für das System, die sich aus dem obigen Text ableiten lassen. Machen Sie ein einfaches Use Case Diagramm, wie in ST1 gezeigt. Erfinden Sie nichts dazu, sondern nutzen Sie nur die Informationen aus dem obigen Text. Sie brauchen nur die Use Cases zu modellieren, die auch in Zusammenhang mit dem System stehen - also z.B. nicht das manuelle Anfordern einer Retoure durch den Kunden per Email.
(Warum ist das praxisrelevant? In der Praxis werden Sie häufig mit mündlichen oder textuellen Anforderungen konfrontiert. Use Cases sind eine Möglichkeit, um diese Anforderungen zu modellieren und zu dokumentieren. Außerdem hilft es Ihnen, die Anforderungen zu verstehen und zu priorisieren.)
Erstellen Sie das fachliche Datenmodell für das System, wie in ST1 gezeigt. Erfinden Sie nichts dazu, sondern nutzen Sie nur die Informationen aus dem obigen Text. Nutzen Sie die Hinweise auf Attribute aus dem Text. Beim Typ der Attribute sollten Sie sinnvolle Annahmen treffen. Machen Sie sich ggfs. eine Liste mit offenen Fragen.
(Warum ist das praxisrelevant? Sie sollten IMMER als erstes ein Domain Model machen. Das können Sie direkt in die Klassenstruktur übersetzen. Die explizite Trennung in Fachliches und Logisches Datenmodell bräuchten Sie in der Praxis vielleicht nicht unbedingt, sondern könnten das fachliche Datenmodell auch direkt in die Klassenstruktur übersetzen - oder aber direkt das Logische Datenmodell mit gerichteten Beziehungen modellieren. Aber wir machen das in dieser Übung noch mal ausführlicher, in zwei Schritten.)
Machen Sie aufbauend auf dem Fachlichen Datenmodell das Logische Datenmodell.
(Warum ist das praxisrelevant? Nur das Logische Datenmodell können Sie direkt in Code übersetzen.)
Machen Sie ein Statusmodell für ein Objekt vom Typ Order. Durch welche Stadien läuft eine Bestellung eines Kunden? Modellieren Sie
das als Statusdiagramm.
(Warum ist das praxisrelevant? Das Statusdiagramm gibt Ihnen wertvolle Hinweise, wie Sie die Konzepte und Use Cases implementieren können, z.B. so etwas wie den Warenkorb.)