RUP-Stereotype

Aus Nettundfroh
Wechseln zu: Navigation, Suche

Aufgabe:

Erweitern des Analyseklassenmodell über die RUP-Stereotype

Die Nomen/Verb-Analyse hilft Ihnen im Wesentlichen, die Entitätsklassen des Systems aufzuspüren, es muss jedoch auch Klassen geben, die Entitätsüberreifende Abläufe steuern sowie Klassen, die für die Nutzereingaben zuständig sind. Fügen Sie Ihrem Diagramm die zu den Anwendungsfällen gehörigen Steuerungsklassen und Grenzklassen hinzu. Orientieren Sie sich hierbei an den Anwendungsfällen, die sich auf bestimmte Entitätsklassen beziehen, und an den Dialogelementen, die Sie für Ihr Teilsystem ermittelt haben.


Entspricht eigentlich schon der Entwurfsphase und wird zum 8.12.2008 banalisiert:

Entitätslassen:

org.eduLibrary.model.entity
IEntity <<interface>>
- id : Long
+ getId() : Long
Role implements IEntity
- id : Long
- name : String
+ getId() : Long
+ getName() : String
+ setName(name:String) : void
User implements IEntity
- id : Long
- roles : Set<Role>
+ getId() : Long
+ getRoles() : Set<Role>
+ addRole(role:Role) : boolean
+ addRole(id:long): boolean
+ removeRole(role:Role) : boolean
+ removeRole(id:long): boolean
...

Grenzklassen:

Alle Grenzklassen schmeißen java.lang.SecurityException, wenn eine auszuführende Aktion durch die fehlende Zuordnung einer Rolle etc. nicht erlaubt ist.

org.eduLibrary.model.border
ManagementContainer<T:IEntity> (um Verwaltungsfunktionalitäten für möglicherweise folgende Entities abzudecken und weil Informatiker faul sind!)
- maxPerPage : int = 20
- pageCount : int
- currentPage : int
- orderBy : String
- orderHow : String = "ASC"
+ create(entity:T) : void
+ update(entity:T) : void
+ remove(id:long) : boolean
+ get(id:long) : T
+ list() : List<T>
+ search(searchCondition:String, searchInField:String) : List<T>
+ search(searchCondition:String) : List<T> (sucht mit boolschen Ausdrücken, so dass mit dieser Methode jegliche Form von gefilterter Listenansicht realisiert werden kann)
+ getMaxPerPage() : int
+ setMaxPerPage(mpp:int) : void
+ getPageCount() : int
+ getCurrentPage() : int
+ setCurrentPage(page:int) : void
+ getOrderBy() : String
+ setOrderBy(orderBy:String) : void
+ getOrderHow() : String
+ setOrderHow(orderHow:String) : void
UserManagementContainer extends ManagementContainer<User>
+ printIdentityCard(id:long) : void
+ collectCharges(id:long) : void
+ importUserData() : void
Authentication
- currentUser : User
+ getCurrentUser() : User
+ login(loginName:String, pwd:String) : void
+ logout() : void
+ resetPassword(loginName:String) : boolean

Steuerungsklassen:

hier sollten Controller für jeden einzelnen Geschäftsprozess stehen, in dem eine Grenzklasse (UserContainer) (durch eine Factory) erzeugt oder aus einer Registry geholt und ihre Funktionaliät einem View bekanntgemacht wird (dazu müsste man sich ja bereits auf Architektur/Viewframework festlegen oder selbst zumindest einen allgemeinen View zur Tabellendarstellung und einen zur Entitybearbeitung definieren?!)...


Da sich alles im Web abspielt und am Ende immer nur Strings zwischen Server und Client hin und her geschickt werden, haben Controller in MVC Model 2 Frameworks oft so etwas wie eine process():String (Struts) oder handleRequestInternal():ModelAndView (Spring) methode, die Views und Models in einem sequenziellen Durchlauf zusammensteckt, den View rendert und den Ausgabestring des Views zurückgibt. process() verallgemeinert die Ausführung eines Geschäftsprozesses und kapselt jede weitere Implementierung. So kann ein Geschäftsprozess an einer bestimmten Stelle eines Seitentemplates ausgeführt, das Ergebnis eingesetzt und die Seite zum Client geschickt werden. Ein vereinfachtes Ajaxsystem lässt sich dann auch erstellen, indem man ermöglicht, dass die Ausgabe eines einzelnen Controllers auch über ein bestimmtes URL-Schema zu erreichen ist, so dass innerhalb einer HTML-Seite einfach einzelne HTML-Root-Noden eines Geschäftsprozesses mit Javascript neu geladen werden können. Also könnten unsere Controller grundsätzlich so aussehen:

org.eduLibrary.controller
IController <<interface>>
+ process(javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse resp) : String
MenuController implements IController
+ process(javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse resp) : String
ContentController implements IController (Observer; ruft - abhängig vom request - den zuständigen Geschäftsprozess-Controller auf)
+ process(javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse resp) : String
RoleManagementController implements IController (eine Tabellenansicht zur Rollenverwaltung; bisher nicht erwähnt, aber da wir Rollen haben, muss es auch zwangsläufig ein Verwaltungswerkzeug geben)
+ process(javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse resp) : String
UserManagementController implements IController
+ process(javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse resp) : String
UserEditController implements IController (hier kann man auch Rollen zuordnen)
+ process(javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse resp) : String
LoginController implements IController
+ process(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse resp) : String
LogoutController implements IController
+ process(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse resp) : String
PasswordForgottenController implements IController
+ process(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse resp) : String


Um diese Konstruktion abzurunden (abgesehen von den Views selbst) und JSPs zu entgehen, könnten wir noch sagen, dass wir ein ObserverServlet(Filter) haben, das in einem definierten Template alle Vorkommen von {[ControllerName]} mit dem Ergebnis von ControllerName.process(request) ersetzt.

Dann hätten wir beispielsweise ein Seitentemplate

	<html>
		<body>
			<p>{[MenuController]}</p>
			<p>{[ContentController]}</p>
		</body>
	</html>

und eine Konfiguration der veröffentlichten Controller mit ihren Menünamen (und URLs).


Eine Ajax-Implementierung wäre ebenso einfach möglich: Wenn ein Benutzer beispielsweise die HTML-Seite http://edulibrary/users aufruft, in welcher der ContentController im oben gezeigten Template den UserManagementController aufruft, kann ein Javascript, das nach Abschluss des Requests auf dem Client ausgeführt wird, bei einer Aktion in diesem Geschäftsprozess den Inhalt seines umschließenden HTML-Tags von http://edulibrary/users/@@UserManagementController nachladen, ohne die ganze Seite neu zu laden, vorausgesetzt, jeder Controller hat per Definition einen umschließenden HTML-Tag, bzw. Containerview. Aber das geht dann auch alles schon in die große weite Welt der Views.

Master Semester 2