Workflow-Next-Step

[GoogleCodeExporter]

0. Etapa precedenta a stabilit (macar in linii mari) care sunt modulele si 
cerintele pe fiecare modul in parte.

1. Activitatile pentru pasul urmator ar putea sa se desfasoare dupa urmatoarea 
strategie.
1.1 Obiective: 
- stabilirea claselor arhitecturale pe fiecare modul;
- stabilirea protocolului (API-ul) de servicii al fiecarui modul;
- stabilirea interdependentelor dintre module
1.2 Flux de lucru pentru fiecare modul
a) Preluarea cazurilor de utilizare circumscrise modulului si a diagramelor de 
activitati asociate acestor cazuri de utilizare.
b) Schitarea realizarii fiecarui caz de utilizare prin crearea unor diagrame de 
secvente. 
Acestea vor prelua activitatile din diagram de activitati initiala a u.c. 
(cazului de utilizare) drept mesaje initiale care vor fi explicitate 
arhitectural catre posibilele obiecte cu responsabilitati interne.
c) Schitarea colaborarilor claselor participante la realizarea fiecarui u.c. 
- Obiectele interne schitate in diagrama de activitati vor sugera tipologia si 
clasele interne de realizare a u.c. Fiecare u.c. ar putea avea astfel o 
diagrama cu clasele ce au responsabilitati in realizarea acestuia.
- Mesajele primite de obiectele interne schitate in diagrama de activitati vor 
sugera operatiile/metodele necesare pentru clasele interne de realizare a u.c.
d) Re-organizarea claselor specifice fiecarui modul.
- Identificarea claselor ce ar putea fi implicate in realizarea mai multor 
cazuri de utilizare.
- Reunirea tuturor claselor intr-o diagrama de clase globala la nivelul 
modulului si repartizarea lor in pachete arhitecturale.
- Crearea pachetelor de organizare pentru entitatile ce vor forma modelul 
"afacerii". Ar putea exista trei genuri de pachete:
    - un pachet cu entitatile interne specifice modulului curent si care nu vor fi exportate/accesibile din alte module;
    - un pachet cu entitati specifice modulului curent care vor fi exportate/accesibile catre alte module (de exemplu ca parametri) - modulele care le vor importa le pot procesa, insa pentru operatiile CRUD vor apela la modulul din care provin;
    - un pachet (sau mai multe) cu entitatile externe ne-specifice modulului curent care nu vor fi importate din alte module (de exemplu care parametri de intrare);
e) Trebuie creata o clasa-serviciu pe fiecare modul care va concentra toate 
operatiile-servicii oferite de clasele interne ale fiecarui modul.
- Structura operatiilor-servicii (cel putin a celor dictate de initierea 
cazurilor de utilizare specifice) vor forma o interfata-serviciu pentru 
clasa-serviciu. 
- Interfata-serviciu si pachetul cu entitatile-exportate vor forma protocolul 
sau API-ul fiecarui modul.

(De realizat in continuare)
2. Structurile bazei de date si maparea O/R adica maparea [entitati ale 
modulelor] - [tabele relationale]
- Arhitectura JPA
- Structurile SQL

Original issue reported on code.google.com by catalin....@gmail.com on 22 May 2012 at 7:18

[GoogleCodeExporter]

La partea de diagrame in exemplu sunt cele doua diagrame de clase care mi se 
par nitel redundante..., diferenta e ca una dintre ele are si incadrarea in 
pachet. Ma gandesc ca ar fi suficienta cea mai completa.
ServiciuSecuritate acea clasa, este clasa Facade? 
Eu zic sa avem Facade+ servicii task(care implementeaza logica de business) 
fara a separa eu stiu... servicii care fac persistenta de altele (ma gandesc la 
rolul acelui repository care nu imi e clar de ce e marcat asa...)
Am mai avea o alta categorie de servicii sa le zicem Utility adica managerul de 
persistenta, eventual un manager de validare logare sau mai stiu eu ce taskuri 
comune per toate modulele; servicile utility sa poata fi injectate cumva in 
serviciile task si sa fie impachetate intr-o zona (proiect comun ) per toate 
modulele

Original comment by viorel.iacoban@gmail.com on 22 May 2012 at 9:54

[GoogleCodeExporter]

Registrul este "managerul de persistenta" al modulului.

Original comment by catalin....@gmail.com on 22 May 2012 at 10:17

[GoogleCodeExporter]

Prima diagrama de clase este o trecere simpla de la diagrama de secvente a unui 
caz de utilizare - se circumscrie sctrict unui caz de utilizare.
A doua diagrama de clase pur si simplu se formeaza prin drag&drop a claselor 
din prima (primile) diagrame de clase - se circumscrie global modulului.

Cu alte cuvint am gandit o "trecere" cat mai simpla si coerenta de la 
realizarea cazurilor in particular la specificatiile modulului in general.

Original comment by catalin....@gmail.com on 22 May 2012 at 10:24

[GoogleCodeExporter]

Ok eu ma gandeam sa avem un serviciu(manager) general(pe toata aplicatia) de 
persistenta(metode standard), iar tot ce inseamna logica inclusiv salvare, 
extragere din baza de date sa fie in serviciile "normale" taskuri intermediate 
de acel manager general de persistenta. 

Original comment by viorel.iacoban@gmail.com on 22 May 2012 at 10:24

[GoogleCodeExporter]

Ok sa fie doua viziuni diferite de acord.

Original comment by viorel.iacoban@gmail.com on 22 May 2012 at 10:25

[GoogleCodeExporter]

In legatura cu registrul (sau managerul de persistenta).
Abordarea nu-mi apartine (am preluat-o din DDD - Domain Driven Design).
Nu am dorit sa merg pe ideea partajarii unui utilitar CRUD la nivelul intregii 
aplicatii. M-am gandit ca "interogarile/cererile" pe baza de date pot fi si ele 
organizate modular repartizandu-le registrelor specifice fiecarui modul.
Eu am mers pe o abordare "la mijloc": nici hiper-centralizata, dar nici 
descentralizata la maxim gen clasa DAO pentru fiecare clasa entitate sau 
agregat de clase entitate.

(In metodologia DDD un repository se adreseaza unei entitati sau agregat de 
entitati ... deci foarte descentralizat. Un repository este oarecum similar 
implementarii unui colectii de entitati persistente de acelasi tip. De ex: 
intr-un List, cind adaugam un nou element, apelam add(newElement) - la fel - un 
repository ar trebui sa fie un astfel de List, sau Map, dar metoda 
add(newElement) sa rezolve si salvarea noului element in baza de date).

Original comment by catalin....@gmail.com on 22 May 2012 at 10:31

[GoogleCodeExporter]

Astept(am) si parerea Dianei ...

Original comment by catalin....@gmail.com on 22 May 2012 at 10:34

[GoogleCodeExporter]

Ok mergem pe ideea de repository

Original comment by viorel.iacoban@gmail.com on 22 May 2012 at 12:54

[GoogleCodeExporter]

Ca sa putem merge mai departe avem nevoie de diagramele realizate pana acum de 
fete insa, nu vad proiectul postat.Mi-a scapat ceva?Multumesc

Original comment by stefy21s...@yahoo.com on 22 May 2012 at 4:30

[GoogleCodeExporter]

Este postat proiectul, dar ar trebui pus intr-un folder ca sa faceti checkout. 

Original comment by viorel.iacoban@gmail.com on 22 May 2012 at 6:41

[GoogleCodeExporter]

Mi se pare ok ideea de repository (cu sau fara modul CRUD basic comun), dar 
cred ca mai e nevoie de ceva clarificari pentru a face o separare clara intre 
cele 2 categorii de clase (serviciu/registru)  in cazul operatiunilor gen 
salvare:
 *procesarile aditionale, validari pre-persistare etc vor fi incluse in clasa Service (ServiciuSecuritate din ex) - caz in care registrul va contine doar metode elementare de persistare,stergere etc entitati- 
 *sau acesta va face doar o delegare spre Repository, care va contine intreaga logica?
Si daca tot veni vorba de delegare - intelesem ca vom avea o clasa Facade care 
va delega apelurile spre diverse servicii specifice care implementeaza logica 
de business, pentru a nu ajunge la o clasa mamut. Ramane valabil, da?

Pe de alta parte, un manager de persistenta comun per toate modulele care sa 
fie injectat sau extins de repository ne-ar scuti de a avea cod duplicat in mai 
multe module (nu ca ar fi multe). Cu atat mai mult cu cat pentru o mare parte 
dintre entitati estimez ca vom avea operatii CRUD de baza. Dar e mai mult o 
chestiune de preferinte - si conteaza intr-adevar si cat de descentralizate se 
doresc a fi modulele

Original comment by neagu.diana on 22 May 2012 at 8:13

[GoogleCodeExporter]

1. Despre Facade
- In proiectul-model clasa-facade se numeste ServiciuSecurizare. 
- Clasa Facade ar trebui sa implementeze sau sa delege (dupa preferinte) logica 
de business. 
- Ceea ce nu are la acest moment este clasa Facade o interfata asociata.

2. Despre repository
- scopul unui astfel de repository ar putea fi sa preia si o parte din logica 
de validare datelor;
- logica de persistenta ar fi principalul rol al unui repository, insa nu as 
vrea (la acest moment - tinand cont si de echipele pe care le aveam) sa 
"imbracam" prea tare logica de persisenta simpla JPA - apelarea directa la un 
EntityManager (injectat :)) mi s-ar parea de ajuns in prima faza.

3. Ideea ar fi ca modulele sa aiba si oarecare autonomie ...

Original comment by catalin....@gmail.com on 23 May 2012 at 5:40

[GoogleCodeExporter]

Ok suna bine, adaugam si interfata. Pai ii dam drumu?
Facem un proiect uml per modul in spiritul exemplului?
Eu am copiat proiectul mare din docs in ProiectUML-Base ca sa poata si tras.

Original comment by viorel.iacoban@gmail.com on 23 May 2012 at 5:50

[GoogleCodeExporter]

Dati drumul la treaba. Dupa parerea mea abia de acum incepe "greul" si s-ar 
obtine ceva cat de cat "palpabil" ...

Original comment by catalin....@gmail.com on 23 May 2012 at 12:46

[GoogleCodeExporter]

Am adaugat in ADMITERE_AdminService suportul pentru JSF2-RichFaces4.
Vezi directorul WEB-INF/lib dupa Update.
Intotdeauna Update si apoi COMMIT daca e ceva de urcat pe svn din proiectele 
locale !!!!!

Original comment by catalin....@gmail.com on 25 May 2012 at 10:30

[GoogleCodeExporter]

Original comment by catalin....@gmail.com on 7 Mar 2013 at 1:26

• Changed state: Done