Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
B basis
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • m223
  • basis
  • Wiki
  • lbv 1 2

Last edited by Stephan Metzler Nov 19, 2018
Page history

lbv 1 2

Zurück zum Modul: m223.komeo.net
Vorgabe: Sample Project m223/m223-api
WorkSpace: arbeite im GitLab in Deiner Projekt-Gruppe m223-nnnn-n
Thema: UML Diagramm in Gruppenarbeit erstellen
Abgeben: 4 Wikis mit UML Diagramm
Bewertung: Einzelarbeit

LBV 1.2 Anforderungen abbilden - UML (Zeit: 4 Lektionen)

UML Diagramme durch revese Engineering konsolidieren

image
by geek & poke

Re-Engineere die Sample-Applikation

  • m223/m223-api

und erstelle die folgenden UML Diagramme:

  • Use-Case Diagram mit Casual Style Beschreibung
  • Klassen Diagramm
  • Sequenz Diagramm
  • Deployment Diagramm

Klone dazu das Projekt :
git clone https://k289gitlab1.citrin.ch/m223/m223-api.git

Ziel

  • 4 Wikis mit
    • Use-Case-Diagramm mit Casual-Style-Beschreibung
    • Klassen-Diagramm
    • Sequenz-Diagramm
    • Deployment-Diagramm

Aufgabe (Zeit: 3 Lektionen)

  • arbeite in Deiner Projekt-Gruppe m223-nnnn-n im api Projekt
  • erstellt als Wiki das Use Case gemeinsam, das UC Diagramm ist die Basis
    • Name: m223-nnnn-n/m223-nnnn-n-api/wikis/lb-1.2-uc
  • teillt die anderen 3 Diagramme untereinder auf, achtet jedoch auf die Schnittstellen
    • Notation, Namensgebung, Transparenz, Nachvollziehbarkeit, etc.
  • erstelle ein Wiki in Deiner Projekt-Gruppe
    • Name: lb-1.2-[uml-diagram]-[name]-[vorname]
    • trage Deinen vollständigen Name im Wiki ein!
    • achte darauf dass Du auch der Ersteller des Wikis bist!
  • ergänze die Liste mit dem URI zum erstellten Wiki
    • Wiki im Klassen-Order: m223-nnnn/basis/wikis/lb-1.2

arbeite mit einem Tool, z.B. draw.io

Use Case: Micro-Services gitlab

Achte auf:

  • Systemgrenze
  • aktive (links) und passive (rechts) Aktoren mit korrekter (Berechtigungs-) Rollen Zuweisung
  • als messbare (verb-) Nutzen (-Nomen) für die Aktoren

use-case

Ergänze das UC mit einer Casual Style Beschreibung

  • Casual Style vs. Fully Dressed

Klassen Diagramm: Micro-Services gitlab

Achte auf:

  • Framework / Meta-Informationen
  • Beziehungen inklusiv Kardinalitäten abbilden
  • Package Struktur ersichtlich

class-diagram

Sequenz Diagramm: Micro-Service https://api1.komeo.net/gitlab/merge

Achte auf:

  • Sequenz beschreiben
  • auf Notation achten, die Methode public void foo(Object o) muss in der Klasse vorhanden sein!

sequence-diagram

Deployment Diagramm: Micro-Services user und gitlab

Achte auf:

  • Komponentenverteilung
  • Services (APIs)
  • Protokolle
  • Nachvollziehbarkeit

deployment-diagram

weitere optionale Aufgabe: Testabdeckung

Alle Bussiness-Object Klassen sind mit remote Unit-Tests abgedeckt

Arbeite mit einem Code-Coverage PlugIn Deiner Wahl in der IDE

  1. erstelle Testklassen der Business Object-Kassen
  2. installiere ein CodeCoveragePlugIn in der IDE

Abgabe: LB 1 am Abend des 2. Modultags

was als
Wiki 4 UML Diagramme als Wikis in Deiner Projekt-Gruppe:
- wiki: m223-nnnn-n/m223-nnnn-n-api/wikis/lb-1.2-[uml-diagram]-[name]-[vorname]
- trage Dein Name/Vorname auch im Wiki ein - Einzelarbeit
- URI zum Wikis in der Klassen-Gruppe ../m223-nnnn/basis/lb-1.2

Bewertung: Einzelarbeit

  • die Bewertung entspricht 12.5% ( 1/8 ) der Modul-Note.
Raster Kriterien
A 1. UML Diagramm ist vorhanden und refenzierbar (URI eingetragen),
2. im Ansatz vollständig, nachvollziehbar und folgt einer Notation und
3. ist im Umfang fachlich korrekt abgegrenzt.
B Zwei der genannten Bewertungspunkte treffen zu.
C Einer der genannten Bewertungspunkte treffen zu.
D Keiner der genannten Bewertungspunkte treffen zu.
  • schön bei der Arbeit mit Git ist, dass Sie Ihre Mitarbeit nicht verstecken können, also:
  • keine nachweisbare, individuelle aktive Beteilligung in der Gruppe resultiert als individuelle Note 1
Clone repository

Home


1. und 2. Tag

1 Anforderungen

  • LBV 1.1
  • LBV 1.2
  • LBV 1.3
  • LBV 1.4

3. bis 5. Tag

2 Erweiterungen

  • LBV 2.1
  • LBV 2.2
  • LBV 2.3
  • LBV 2.4

laufende Projekte

Bewertunsraster

Klassen