Obiectivul temelor de casă este reprezentat de implementarea unui sistem informatic performant şi scalabil pentru gestiunea resurselor unei întreprinderi de dimensiuni mari. În acest an universitar, organizaţia pentru care se va proiecta şi dezvolta acest pachet de programe este un lanț de policlinici.
Se va realiza implementarea graduală a mai multor module din cadrul aplicației ERP, pe parcursul a patru etape.
În cadrul acestei etape, sistemul informatic va fi capabil să interogheze servicii care rulează în alte maşini virtuale şi ale căror funcţionalităţi le cunoaşte, acestea fiind accesibile prin intermediul unei reţele de calculatoare.
După rezolvarea temei de casă, studentul va fi capabil să:
Cunoştinţele necesare pentru rezolvarea temei de casă sunt:
Sistemul ERP pentru gestiunea activităţii dintr-un lanț de policlinici va fi completat spre a comunica cu alte aplicaţii ce oferă, prin intermediul reţelei Internet, anumite funcţionalităţi al căror mod de accesare este cunoscut.
Astfel, aplicația corespunzătoare lanțului de policlinici va interoga un serviciu care intermediază comunicația cu mai mulți producători de echipamente medicale în scopul achiziționării acestora, într-un anumit interval de timp și la un anumit preț. De asemenea, anumite servicii medicale, oferite de medici aflați în contract cu casa de asigurări de sănătate vor putea fi decontate, în limita unui barem prestabilit, pentru pacienții care pot beneficia de astfel de facilități.
Programul care gestionează activitatea din cadrul lanțului de policlinici se va conecta la un agent de intermediere a comunicației cu diferiți furnizori de echipamente medicale pe care îl poate interoga cu privire la lista producătorilor înregistrați, produsele pe care aceștia le comercializează (împreună cu data de livrare a unei cantități precizate și prețul lor), putând să le rezerve pentru un interval de timp (și să anuleze rezervarea), respectiv să le comande (și să anuleze comanda).
În acest sens, agentul de intermediere a comunicației cu producătorii va gestiona cererile și răspunsurile cu privire la furnizarea anumitor echipamente medicale, stocând local informații cu privire la starea acestor operații și redirecționând solicitările formulate de lanțul de policlinici către componenta corespunzătoare.
Așadar, funcționalitățile accesibile la distanță sunt:
Manufacturer[] getManufacturers();
Un producător este caracterizat prin denumirea sa și o descriere ce conține profilul / gama de produse comercializate.
MedicalSupply[] getMedicalSupplies(Manufacturer manufacturer);
Un echipament medical este caracterizat prin furnizorul care îl comercializează, denumirea sa, descrierea ce conține informații despre utilizarea sa, prețul unitar, stocul de care dispune producătorul la momentul respectiv și timpul de execuție, exprimat în număr de zile.
Există posibilitatea de a se filtra lista de echipamente medicale doar pentru un anumit furnizor, care este transmis ca parametru al metodei, în caz contrar întorcându-se toate produsele care pot fi rezervate / comandate prin intermediul agentului de intermediere, de la producătorii înregistrați.
int makeReservation(string manufacturer, string medicalSupply, int quantity);
Metoda va furniza un număr de înregistrare prin intermediul căruia aplicația corespunzătoare lanțului de farmacii va putea să realizeze și alte operații.
La apelul acestei metode, agentul de intermediere va apela metoda corespunzătoare producătorului indicat, obținând oferta pentru echipamentul medical solicitat.
În cazul în care producătorul sau echipamentul medical nu există, se va întoarce valoarea -1.
boolean cancelReservation(int reservationId);
În cazul în care anularea rezervării reușește, metoda va întoarce rezultatul true
, altfel (inclusiv în situația când se furnizează un număr de înregistrare inexistent sau care reprezintă o rezervare care a fost procesată deja) rezultatul va fi false
.
Offer getReservationStatus(int reservationId);
O ofertă corespunzătoare unei rezervări constă în data calendaristică la care produsele pot fi livrate, respectiv prețul care trebuie plătit pentru cantitatea solicitată.
În situația în care metoda este apelată cu un număr de înregistrare invalid (inexistent, corespunzător unei rezervări procesate), rezultatul va fi null
.
boolean makeOrder(int reservationId);
Prin intermediul acestei metode, se plasează o comandă către furnizorul respectiv, agentul de intermediere apelând metoda corespunzătoare producătorului în cauză.
Rezultatul este true
în situația în care cantitatea disponibilă pe stocul producătorului este suficienă și false
în caz contrar sau dacă numărul de înregistrare este inexistent / corespunde unei rezervări care a fost procesată (pentru care a fost emisă deja comanda).
boolean cancelOrder(int reservationId);
Această metodă semnalează faptul că lanțul de policlinici nu dorește achiziționarea produsului aferent numărului de înregistrare, anulând atât rezervarea cât și comanda.
Metoda întoarce true
în cazul în care operația a reușit și false
în caz contrar (dacă numărul de înregistrare este inexistent sau comanda nu a fost realizată).
int getOrderStatus(int reservationId);
Rezultatele pe care le poate întoarce această metodă sunt:
INVALID_REGISTRATION_ID
– pentru situația în care a fost furnizat un număr de înregistrare inexistent sau pentru care nu s-a realizat o comandă;ORDER_PLACED
– în cazul în care comanda a fost transmisă la furnizor pentru numărul de înregistrare transmis;ORDER_CANCELLED
– dacă comanda aferentă numărului de înregistrare a fost anulată.Producătorul unui echipament medical poate fi interogat de agentul de comunicare, furnizând denumirea și descrierea sa, produsele medicale pe care le comercializează, realizând rezervarea unui produs și anularea rezervării, comanda unui produs și anularea comenzii (pentru o rezervare anterioară).
string getName(); string getDescription(); MedicalSupply[] getMedicalSupplies(); Offer makeReservation(int reservationId, string medicalSupplyName, int medicalSupplyQuantity); boolean cancelReservation(int reservationId); boolean makeOrder(int reservationId); boolean cancelOrder(int reservationId);
În momentul în care se realizează rezervarea unui produs, cantitatea solicitată urmează a fi retrasă din stoc, pentru o perioadă de timp standard, interval în care aceasta poate fi anulată, respectiv se poate plasa o comandă.
Dacă stocul corespunzător produsului nu este suficient pentru a satisface solicitarea, oferta generată va conține un termen de livrare care va reflecta timpul de execuție pentru echipamentul medical în cauză. Într-o astfel de situație, nu se va putea transmite o comandă aferentă rezervării până în momentul când întregul lot de produse solicitat nu va fi disponibil, adică până la termenul de livrare transmis.
Anularea explicită a unei rezervări implică marcarea produselor respective ca fiind disponibile, pentru numărul de înregistrare respectiv nemaiputând fi realizate nici un fel de alte operații în continuare.
Dacă produsele corespunzătoare unei rezervări nu sunt comandate în perioada de timp standard, rezervarea respectivă va fi considerată ca fiind anulată implicit.
O comandă se poate plasa doar pentru acele echipamente medicale care au fost rezervate în prealabil și pentru care întreaga cantitate solicitată se găsește în stoc.
O comandă poate fi anulată tot doar în cadrul unei perioade de timp standard de la momentul în care a fost plasată, ulterior această operație fiind imposibilă. Anularea se extinde și asupra rezervării corespunzătoare, nemaiputând fi realizate nici un fel de operații ulterioare.
Nu se va lua în considerare posibilitatea de expirare a dispozitivelor medicale furnizate de producători.
De asemenea, furnizorul de echipamente medicale poate invoca metode oferite de agentul de intermediere pentru înregistrarea sa în contextul acesteia, respectiv pentru deînregistrarea sa. Disponibilitatea metodelor pe care le implementează este condiționată și de starea sa în cadrul componentei de intermediere (înregistrat / neînregistrat), nu doar de accesibilitatea sa prin intermediul rețelei de calculatoare (starea componentei de tip producător este pornit / oprit).
int registerManufacturer(string name, string description); boolean unregisterManufacturer(int registrationId);
Metoda registerManufacturer
furnizează denumirea și descrierea unui producător și întoarce numărul de înregistrare din cadrul agentului de intermediere. În cazul în care există un producător având aceeași denumire și descriere, se va transmite numărul de înregistrare deținut de acesta, modificând eventual starea sa (din neînregistrat în înregistrat). Componenta de intermediere trebuie să asigure totodată unicitatea numerelor de înregistrare (nu pot exista producători diferiți cu același număr de înregistrare alocat).
Metoda unregisterManufacturer
marchează indisponibilitatea furnizorului pentru invocarea funcționalității. Aceasta întoarce true
dacă starea componentei respective a fost modificată corespunzător și false
în situația în care numărul de înregistrare este inexistent sau dacă starea producătorului nu a putut fi schimbată / nu a fost necesar să fie schimbată.
Casa de asigurări de sănătate reține informații cu privire la contractele medicilor (încheiate pe o anumită perioadă de timp), starea pacienților (asigurați sau neasigurați), plafonul pentru decontarea de servicii medicale în cursul unui an calendaristic, investigațiile care fac obiectul decontării (cu specificarea eventuală a unui procent plătit din prețul total), costurile suportate în trecut pentru decontarea anumitor proceduri.
Pe baza lor, lanțul de policlinici poate solicita plata din fondurile casei de asigurări, pentru un serviciu medical realizat de un medic, pentru un anumit pacient, la o anumită dată, având un anumit cost. Datele sunt prelucrate, urmând ca cererea de decontare să fie aprobată sau nu.
int redeemMedicalService(int physicianId, int patientId, GregorianCalendar date, int medicalServiceId, double price);
Rezultatul întors de această metodă conține și justificarea motivului pentru care solicitarea nu a fost aprobată:
PHYSICIAN_NOT_IN_CONTRACTUAL_RELATIONSHIP
– dacă medicul care a furnizat serviciul medical nu se află în relații contractuale cu casa de asigurări de sănătate (verificările se realizează raportat la data calendaristică la care a fost efectuat respectivul serviciu medical);PATIENT_NOT_INSURED
– dacă pacientul care a beneficiat de serviciul medical nu deține statutul de asigurat;UNSUPPORTED_MEDICAL_SERVICE
– serviciul medical nu face obiectul decontării de casa de asigurări de sănătate;FOUNDS_EXCEEDED
– plafonul stabilit de casa de asigurări ar fi depășit prin decontarea serviciului medical respectiv;INFORMATION_NOT_AVAILABLE
– nu pot fi obținute informații la nivelul componentei corespunzătoare casei de asigurări sau s-a produs un alt tip de eroare (medic / pacient inexistenți, dată calendaristică invalidă – perioada care a trecut de la furnizarea serviciului medical până în prezent este prea mare sau data calendaristică se găsește în viitor, servciu medical nerecunoscut de casa se asigurări de sănătate, preț negativ).Arhitectura sistemului informatic va fi prin urmare formată din patru componente, dintre care două au comportament de server (furnizor de echipamente medicale, casa de asigurări de sănătate), una are comportament de client (lanțul de policlinici) și una are comportament mixt, atât de client cât și de server, în funcție de entitatea la care se raportează (agentul de intermediere al comunicației).
NU este permisă folosirea altor tehnologii cu excepția celor specificate în enunţ.
În cazul agentului de intermediere a comunicației cu furnizorii de produse medicale, care expune funcționalități de tip server atât către producători cât și către lanțul de policlinici, trebuie să se asigure un acces corespunzător la servicii, astfel încât fiecare componentă de tip client să nu poată invoca decât metodele care le privesc, fără să cunoască informații despre celelalte funcții pe care le implementează.
Persistența informațiilor la nivelul componentelor de tip server va fi asigurată prin stocarea acestora în baze de date dedicate. În cadrul intracțiunii cu acestea, operațiile trebuie să se realizeze atomic (în cadrul unor tranzacții).
Definițiile metodelor din cadrul enunțului au fost descrise în pseudocod. Acestea pot fi modificate la nivelul parametrilor și valorilor întoarse, cu menținerea funcționalității. În cazul în care se optează pentru o anumită codificare a semnificației parametrilor / valorilor întoarse ale metodelor, acestea trebuie codificate.
În cazul metodelor makeReservation
, cancelReservation
, makeOrder
, cancelOrder
, implementarea în cadrul agentului de intermediere a comunicației cu furnizorii implică apelarea metodelor omonime din cadrul producătorului corespunzător echipamentului medical pentru care s-a realizat rezervarea / comanda.
Pentru realizarea cerinţelor, poate fi necesară adaptarea bazei de date proiectată în cadrul etapei anterioare.
Anumite date care controlează modul de funcționare al componentelor (perioadele de menținere a unei rezervări sau în care poate fi anulată o comandă, plafonul de decontare a serviciilor medicale) pot fi definite în codul sursă sub formă de constante, pot fi stocate în bazele de date corespunzătoare componentelor respective sau pot fi transmise în linia de comandă.
Orice specificaţie care nu este menţionată mai sus reprezintă decizie de implementare. Puteţi considera orice simplificare în condiţiile în care enunţul nu precizează altfel.
Pentru ca tema să fie punctată, trebuie incluse scripturi de lansare în execuție a componentelor în care să fie implicate minim două componente de tip producător și câte o componentă din celelalte tipuri.
Punctaj | Criterii de acordare |
---|---|
1 p | proiectarea metodelor corespunzătoare componentelor de tip server • componenta producător: 25% • componenta agent de intermediere a comunicației cu furnizorii: 65% • componenta casa de asigurări de sănătate: 10% |
1 p | reproiectarea bazei de date astfel încât să corespundă noilor funcţionalităţi • componenta producător: 40% • componenta agent de intermediere a comunicației cu furnizorii: 40% • componenta casa de asigurări de sănătate: 20% |
2 p | implementarea metodelor corespunzătoare componentei producător • getName : 2,50%• getDescription : 2,50%• getMedicalSupplies : 15%• makeReservation : 35%• cancelReservation : 15%• makeOrder : 15%• cancelOrder : 15% |
2 p | implementarea metodelor din agentul de intermediere a comunicației cu furnizorii • getManufacturers : 10%• getMedicalSupplies : 15%• makeReservation : 30%• cancelReservation : 10%• getReservationStatus : 10%• makeOrder : 10%• cancelOrder : 10%• getOrderStatus : 5% |
1 p | implementarea funcţionalităţii casei de asigurări de sănătate (redeemMedicalService ) |
1 p | apelarea metodelor disponibile la distanță din cadrul componentelor de tip client • componenta lanț de policlinici: 55% • componenta agent de intermediere a comunicației cu furnizorii: 30% • componenta producător: 15% |
1 p | modularizare • structura aplicaţiei: 50% • lizibilitatea codului: 20% • comentarii, README: 30% |
BONUS. Se pot obţine punctaje suplimentare, astfel:
makeReservation
, cancelReservation
, makeOrder
, cancelOrder
astfel încât să permită rezervarea / anularea rezervării, comanda / anularea comenzii pentru mai multe comenzi concomitent, generând câte un număr de înregistrare pentru fiecare produs distinct, astfel încât să se poată realiza ulterior mai rapid comanda acelor echipamente medicale care sunt disponibile imediat;Tema va fi realizată individual şi va fi prezentată în cadrul laboratorului, până la sfârşitul semestrului. Neprezentarea temei de casă atrage după sine nepunctarea acesteia. În cadrul prezentării veţi specifica succint funcţionalităţile pe care le-aţi dezvoltat şi veţi răspunde la întrebări cu privire la diferite soluţii adoptate în rezolvarea problemelor întâlnite.
Tema va trebui încărcată pe site-ul cs.curs.pub.ro sub forma unei arhive de tip .zip (având denumirea Grupa34XCX_NumePrenume_Tema2.zip) care să conţină script-ul pentru crearea şi popularea tabelelor din bazele de date (numele bazelor de date fiind prefixate de Grupa34XCX_NumePrenume), sursele componentelor cu scenarii de utilizare (scripturi ce conţin lansări în execuţie ale componentelor de tip server şi client cu diferite operaţii, specificând argumentele necesare) şi un fişier README în care să argumentați tehnologia pe care ați ales-o și deciziile de implementare. Prezentarea se poate realiza numai după ce tema a fost încărcată pe site.
java.rmi.server.codebase
, java.rmi.server.hostname
, java.security.policy
, incluzându-se și fişierele ce conţin politica de securitate. Pentru CORBA, se vor preciza parametrii liniei de comandă ORBInitialHost
/ ORBInitialPort
. Dacă se optează pentru JAX-WS, vor trebui indicate locațiile la care vor fi publicate serviciile web.
Încărcarea pe site nu este redundantă, temele vor fi comparate prin aplicaţii specializate pentru a se depista eventualele fraude. În această situaţie, întreg punctajul pe parcursul semestrului va fi anulat, studenţii implicaţi (atât originalul, cât şi copia / copiile) fiind obligaţi să repete disciplina – cu taxă – în anul universitar următor.