CONȚINUT

1. Introducere ………………………………………………………… 1
[Link] ………………………………………………………… 1
[Link] Proiectului……………………………………………………. 2
[Link] ………………………………………………………... 2
5. Prezentarea proiectului……………………………………………………. 2
[Link] ț ie H/W, S/W…………………………………………… 4
7. Model de proces software……………………………………. 11
[Link] ș i descrierea problemei………………………………. 13
[Link] ș i Proiectarea Sistemelor………………………………………..... 15
10. Analiza sistemelor…………………………………………………….. 16
[Link] Fluxului de Date………………………………………………… 18
[Link] E-R……………………………………………………….. 24
[Link] bazei de date 25
14. Aspecte ale ecranului…………………………………………………….. 26
[Link]………………………………………………………………. 36
[Link]…………………………………………………….. 38
[Link]ț ie…………………………………………………………… 40
[Link]………………………………………………………. 41
INTRODUCERE

Tehnologia face via ț a mai u ș oară oferind un suport mai bun pentru
sisteme diferite, mai multă precizie, op ț iuni de securitate mai bune, mai u ș or

mentenanț ă, etc.
Astăzi, tehnologia înseamnă în cele din urmă „calculatoare”, care este
cele mai mari realizări ale secolului trecut. Zi de zi, calculatoarele devin mai
ș i mai popular datorită caracteristicilor sale, cum ar fi uș urinț a de lucru, uș urinț a de învăț are,

precizie mai mare cu cel mai mic consum de timp ș i ultimul, dar nu cel din urmă
cel mai puț in adică uș urinț a în întreț inere cu eficienț a costurilor.

A ș adar, ca parte a acestei abordări evolutive continue, tradi ț ional

sistemele sunt computerizate pentru a le face mai fructuoase ca niciodată.
[Link]

Sistemul de gestionare a orarului este un sistem automatizat care generează

tabel de ore conform datelor furnizate de utilizator. Cerinț a principală a

aplicaț ia este de a oferi detalii despre ramură, subiecte, nr.
laboratoare, numărul total de perioade ș i detalii despre asisten ț a de laborator. Apoi

aplicaț ia generează orarul conform nevoilor tale.

[Link]ȚIA PROIECTULUI

Proiectul de bază este de a crea un Sistem de Management al Orarului.

Pentru a crea baze de date pentru diferitele entităț i implicate în acest proces.
Men ț inerea unei baze de date care con ț ine informa ț ii despre diferitele
semestri
 [Link]

Aș a cum am discutat mai devreme despre întreț inerea manuală a unui Orar
Sistemul de management este o muncă obositoare. A ș a că, pentru a spori u ș urinț a

lucrăm, mergem pentru acest pachet.

Întreț inerea manuală a bazelor de date ale articolelor, procesarea programului este o

un proces consumator de timp ș i într-un fel eronat.

Pentru a oferi o mai mare precizie sistemului adică în loc să facem manual

modificare, implicăm computerul pentru precizie.

Cel mai puț in, dar cel mai important, economiseș te timp.
5. PREZENTAREA PROIECTULUI

Obiectivele pachetului

Creează un sistem de gestionare a programului de cursuri care să fie folosit de orice colegiu.

Pentru a îndeplini cerinț ele de bază ale firmei.

Menț inerea bazelor de date privind detaliile subiectului, clasei ș i semestrului.

Domeniile ș i limitele pachetului

Deoarece este un pachet bazat pe calculator, întreț inerea ș i funcț ionarea

este oarecum dificil din modul manual de abordare.

Deoarece nu este posibil să asociem fiecare cerinț ă a
sistemul aș a că într-un fel sau altul va crea probleme la
unele etape de execuț ie (cum ar fi generarea de rapoarte).

Ca un sistem bazat pe computer, este mai uș or să preiei date din

bază de date pentru activităț i antisociale. De asemenea, mai uș or de distrus cele existente.

Beneficii aș teptate
 Prin implementarea acestui pachet, ferma va obț ine date fără erori.
a analiza.
Acest pachet ar limita factorul timp ș i bani implicat în
Sistem de Management al Tabelului Orar

Între ț inerea este mult mai u ș oară ș i precisă decât cea existentă
sistem manual.
Func ț iile de securitate sunt oarecum mai ridicate decât cele manuale.

aproape.
6. Configurarea hardware ș i software

Hardware-ul ș i software-ul ar trebui să fie alese cu atenț ie, având în vedere următorul punct

în minte

Sistemul trebuie să fie u ș or de utilizat

Sistemul trebuie să fie capabil să gestioneze un număr mare de date.

Viteza de procesare a sistemului trebuie să fie rapidă

Configuraț ia hardware

Procesor principal Pentium IV

Memorie cu acces aleator: 1 GB
Capacitatea hard disk-ului 80 GB

Configurare software

Sistem de operare Windows (2000, ME, NT, XP)

Specificaț ia de programare JAVA (J2SE/J2EE), Swing, JDBC
Dezvoltare Integrată
Mediu Eclipse 5.5 / Eclipse
 Model de design utilizat:

Model DAO (Obiect de Acces la Date)

Model DTO (Obiect de Tranzacț ie a Datelor)

Accesul la date ș i modelul obiectului de transfer de date:

Modelul Data Access Object (sau DAO):

•Separă interfa ț a clientului unei resurse de date de mecanismele sale de acces la date

•Adaptează API-ul de acces al unei surse specifice de date la o interfa ț ă generală de client

Modelul DAO permite mecanismelor de acces la date să se schimbe independent de

cod care foloseș te datele.

FABRICA DAO
DATE

SURSĂ
OBIECTIV DE AFACERI
OBIECT DE ACCES LA DATE E
(PAGINA JSP)

OBIECT DE TRANSFER DE DATE

Patternul de design DAO este o altă strat de abstrare peste persisten ț ă

mecanismul aplicaț iei. Aplicaț ia se ocupă cu Obiectele de Acces la Date
ș i Obiectele de Transfer de Date (DTO) în loc să apelăm direct driverul JDBC.
Schimbarea metodei de persistenț ă la o dată ulterioară nu necesită modificări în codul aplicaț iei

a schimba, adăugând doar un nou set de DAO-uri. Folosind DAO în aplicaț ia web
permite o concentrare mai mare asupra accesului la date decât asupra mecanicii modului în care

datele sunt stocate ș i recuperate.

Standardizarea oferită de acest nou strat facilitează de asemenea

generează automat codul Java necesar pentru a accesa baza de date. Cele mai multe JDBC
apelurile sunt foarte repetitive ș i consumatoare de timp. Folosirea unui generator DAO este o alegere bună

modalitate de a elimina acea muncă ș i de a face dezvoltarea aplicaț iei mai rapidă.

Prezentare generală a Swing:

Swing este un toolkit de widget-uri pentru Java. Face parte din Java Foundation a Sun Microsystems.
Clase (JFC) — unAPIpentru a oferi uninterfaț ă grafică utilizator(GUI) pentru Java
programe.

Swing a fost dezvoltat pentru a oferi un set mai sofisticat de GUIcomponentedecât

mai devremeToolkit-ul pentru feronerie abstractă . Swing oferă un nativaspect ș i senzaț iecă
emulează aspectul ș i senzaț ia mai multor platforme ș i, de asemenea, suportă ointercambiabiluită-te
ș i simtecare permite aplicaț iilor să aibă un aspect ș i o senzaț ie fără legătură cu fundalul
platformă.

Arhitectură
Swing este o platformă independentă,Model-Vizualizare-ControlerInterfaț ă graficăcadru pentru Java.
Urmează omodel de programare pe un singur fir, ș i de ț ine următoarele
traits
• Independenț a faț ă de platformă: Swing este independent de platformă atât în ceea ce priveș te...
expresie (Java) ș i implementarea sa (redare universală non-nativă a
widget-uri).

• Extensibilitate:Swing este o arhitectură foarte partitionată, care permite pentru

îmbinarea diferitelor implementări personalizate ale cadrului specificat
interfeț e: Utilizatorii pot oferi propria implementare personalizată a acestora
componente pentru a suprascrie implementările implicite. În general, utilizatorii Swing
poate extinde cadrul prin extinderea claselor existente (ale cadrului) ș i/sau
oferind implementări alternative ale componentelor de bază.
 • Orientat pe componente: Swing este un cadru bazat pe componente.
distinc ț ia între obiecte ș i componente este un punct destul de subtil:
Pe scurt, un component este un obiect bine comportat cu un comportament cunoscut/precizat.
model caracteristic de comportament. Obiectele swing se activează asincron.
evenimente, au proprietă ț i „legate” ș i răspund la un set bine cunoscut de
comenzi (specifice componentei.) În mod specific, componentele Swing sunt
Java Beanscomponente, conforme cu Componenta Java Beans
Specificaț iile arhitecturii.

• Personalizabil: Având în vedere modelul de redare programatic al Swing

cadru, control fin asupra detaliilor de redare a unei componente este
posibil în Swing. Ca un model general, reprezentarea vizuală a unui Swing
componenta este o compunere a unui set standard de elemente, cum ar fi o
„bordură”, „inser ț ie”, decora ț iuni etc. De obicei, utilizatorii vor programa în mod programatic
personaliza ț i un component standard Swing (cum ar fi un JTable) prin atribuirea
Borduri specifice, culori, fundaluri, opacitate etc., ca proprietăț i ale
acest component. Componenta de bază va folosi apoi aceste proprietăț i (setări)
pentru a determina renderer-ii corespunzători de utilizat în pictarea diferitelor sale aspecte.
Cu toate acestea, este de asemenea complet posibil să creaț i controlere GUI unice cu
reprezentare vizuală foarte personalizată.

• Configurabil: Dependenț a puternică a Swing de mecanismele de execuț ie ș i indirecte

modelele de compunere îi permit să răspundă în timpul execuț iei la schimbări fundamentale
în setările sale. De exemplu, o aplicaț ie bazată pe Swing poate schimba aspectul său
ș i să simtă la runtime. În plus, utilizatorii pot oferi propriul lor aspect ș i senza ț ie
implementare, care permite modificări uniforme în aspectul ș i senzaț ia de
aplica ț ii Swing existente fără nicio modificare programatică la
codul aplicaț iei.

• Interfaț ă uș oară: Configurabilitatea Swing este rezultatul unei alegeri de a nu folosi

controalele GUI ale sistemului de operare gazdă native pentru a se afi ș a. Swing „picta”
controlează programatic prin utilizarea API-urilor Java 2D, mai degrabă decât
apelând la un toolkit de interfaț ă utilizator nativ. Astfel, un component Swing face
nu are un component GUI nativ corespunzător, ș i este liber să redea
în orice mod posibil cu API-urile grafice subiacente.

Cu toate acestea, în esenț ă, fiecare componentă Swing se bazează pe un container AWT, deoarece
(Swing's) JComponent extinde (AWT's) Container. Aceasta permite Swing să se integreze în
framework-ul de gestionare GUI al sistemului de operare gazdă, inclusiv dispozitivele/efectele cruciale
mapări ș i interacț iuni ale utilizatorului, cum ar fi apăsările de taste sau miș cările mouse-ului. Swing
pur ș i simplu "transpune" propriile sale semantici (indiferente de sistemul de operare) peste cel de bază (sistemul de operare
componentele specifice). Aș adar, de exemplu, fiecare componentă Swing îș i pictează reprezentarea
pe dispozitivul grafic ca răspuns la un apel la [Link](), care este definit
în (AWT) Container. Dar, spre deosebire de componentele AWT, care delegau pictarea
la widget-ul lor nativ OS „greu”, componentele Swing sunt responsabile pentru
propria lor redare.

Această transpunere ș i decuplare nu sunt doar vizuale ș i se extind la Swing.

managementul ș i aplicarea propriilor sale semantici independente de sistemul de operare pentru evenimentele declanș ate

în cadrul ierarhiilor de con ț inere a componentelor sale. În general, Swing

Arhitectura delegă sarcina de a mapare diferitele tipuri de interfa ț ă grafică a sistemului de operare
semantica pe un model simplu, dar generalizat, pentru containerul AWT. Construind
pe acea platformă generalizată, î ș i stabile ș te propriul GUI bogat ș i complex
semantica sub forma modelului JComponent. O revizuire a sursei de
Clasele [Link] ș i [Link] sunt recomandate pentru informaț ii suplimentare
în natura interfe ț ei dintre componentele u ș oare ale Swing ș i
widget-urile grele AWT.

• Loosely-Coupled/MVC: Biblioteca Swing foloseș te intens

Model/View/Controllersoftwaremodel de design, care conceptual
decuplează datele vizualizate de controalele interfeț ei utilizatorului prin
pentru care este vizualizat. Din această cauză, cele mai multe componente Swing au asociat
modele (care sunt specificate în termeni de Javainterfeț e), ș i
programatorul poate folosi diverse implementări implicite sau poate oferi propriile sale.
Frameworkul oferă implementări implicite ale interfeț elor model pentru toate
ale componentelor sale concrete.

De obicei, obiectele modelului componentelor Swing sunt responsabile pentru furnizarea unui rezumat concis
interfaț ă care defineș te evenimentele declanș ate ș i proprietăț ile accesibile pentru datele (conceptuale)
model pentru utilizarea de către JComponent asociat. Având în vedere că modelul general MVC
este un model de relaț ie a obiectelor colaborative cu o legătură liberă, modelul oferă
mijloacele programatice pentru ataș area ascultătorilor de evenimente la obiectul modelului de date.
În mod obiș nuit, aceste evenimente sunt centrate pe model (de exemplu: un eveniment "linie inserată" într-un tabel
model) ș i sunt mapate de specializarea JComponent într-un eveniment semnificativ
pentru componenta GUI.

De exemplu,JTableare un model numitModel de tabelăcare descrie o interfaț ă

pentru modul în care o masă ar accesa datele tabulare. O implementare implicită a acestui lucru
funcț ionează pe o două-dimensionalăarray.

Componenta de vizualizare a unui JComponent Swing este obiectul folosit pentru a reprezenta grafic
"reprezintă" controlul conceptual al interfe ț ei grafice. O distinc ț ie a Swing, ca interfa ț ă grafică
framework-ul său se bazează pe controale GUI renderizate programatic (după cum
opus utilizării controalelor GUI ale sistemului de operare gazdă nativ). (Această distincț ie este o
sursa complicaț iilor atunci când se amestecă controalele AWT, care folosesc controale native,
cu controale Swing într-o interfaț ă grafică.)
Trebuie menț ionat că utilizarea tipică a framework-ului Swing nu necesită ...
crea ț ia de modele personalizate, deoarece cadrul oferă un set de valori implicite
implementări care sunt transparen ț e, prin defectoare, asociate cu
clasa copil JComponent corespunzătoare din biblioteca Swing. În general, doar
componente complexe, cum ar fi tabele, arbori ș i uneori liste, pot necesita
implementări personalizate de modele în jurul structurilor de date specifice aplicaț iei.

(Cu toate acestea, pentru a obț ine o bună înț elegere a potenț ialului pe care arhitectura Swing îl oferă
posibil, consideraț i situaț ia ipotetică în care modelele personalizate pentru tabele ș i
listele sunt înveliș uri pesteDAOș i/sauEJBservicii.)
În cele din urmă, în ceea ce priveș te compoziț ia vizuală ș i gestionarea, Swing favorizează relativitatea
dispuneri (care specifică rela ț iile de pozi ț ie între componente) ca
opuse la layout-uri absolute (care specifică loca ț ia ș i dimensiunea exactă a
componente). Această prejudecată faț ă de ordonarea vizuală "fluidă" se datorează originilor sale în
appletmediu de operare care a conturat designul ș i dezvoltarea
toolkit-ul Java GUI original. (Conceptual, această viziune asupra gestionării aranjamentului este
destul de similar cu ceea ce informează redarea conț inutului HTML în browsere,
ș i abordează aceeaș i serie de preocupări care au motivat pe cei anteriori.

Aspect ș i senzaț ie

Swing permite specializareaaspect ș i senzaț iedewidget-uri, prin modificarea

implicit (prin parametrii de execuț ie), derivând dintr-unul existent, prin crearea unuiul
de la zero, sau, începând cu J2SE 5.0, folosindpersonalizabilsynthUită-te ș i
Simte (veziAspect ș i senzaț ie Synth), care este configurat cu unXMLfiș ier de proprietate.
Aspectul ș i senzaț ia pot fi schimbate în timpul execuț iei, iar demonstrele timpurii ale Swing
de multe ori a oferit o modalitate de a face acest lucru.

Relaț ia cu AWT
Încă din primele versiuni ale Java, o parte dinToolkit-ul pentru Fereastră Abstractă(AWT) are
a furnizat API-uri independente de platformă pentru componentele interfeț ei utilizatorului. În AWT, fiecare
componenta este redată ș i controlată de o componentă nativă specifică pentru
sistemul de feronerie de bază.

În schimb, componentele Swing sunt adesea descrise ca fiind uș oare deoarece nu

nu necesită alocarea de resurse native în sistemul de feronerie al sistemului de operare
kit de unelte. Componentele AWT sunt denumite componente grele.

Marea parte a API-ului Swing este în general o extensie complementară a AWT.

decât o înlocuire directă. De fapt, fiecare interfaț ă uș oară Swing în cele din urmă
există într-un component greu AWT deoarece toate nivelurile superioare
componente în SwingJApplet, JDialog, JFrame, ș iJWindow) extinde un AWT
container de nivel superior. Cu toate acestea, utilizarea atât a celor u ș oare, cât ș i a celor grele
componentelor din aceea ș i fereastră este în general descurajat din cauzaOrdinea Z
incompatibilităț i.
Func ț ionalitatea de redare de bază utilizată de Swing pentru a desena componentele sale u ș oare
componentele sunt furnizate deJava 2D, o altă parte a JFC.

Relaț ia cu SWT
TheToolkit-ul Standard pentru Widget-uri (SWT) este un toolkit concurent dezvoltat iniț ial
deIBMș i acum întreț inut deFundaț ia Eclipse. Implementarea SWT
are mai multe în comun cu componentele grele ale AWT. Acest lucru conferă
beneficii precum o fidelitate mai precisă cu fereastra nativă de bază
kit de instrumente, cu costul unei expuneri sporite la platforma nativă în
model de programare.

Apariț ia SWT a generat o mare divizare în rândul aplicaț iilor desktop Java
dezvoltatori, mulț i favorizând fie SWT fie Swing. dezvoltarea Sun
Swing continuă să se concentreze pe fidelitatea aspectului ș i senzaț iei platformei (PLAF) cu fiecare
kitul de instrumente pentru feronerie al platformei în apropiereJava SE 7lansare (începând cu luna decembrie
2006). Între timp, există ș i alte surse de PLAF-uri de înaltă fidelitate, multe dintre care
care sunt colectate pejavootoosite.

A existat o dezbatere ș i speculaț ii semnificative cu privire la performanț a SWT

versus Swing; unii au sugerat că dependenț a puternică a SWT deJNIar face-o
mai lent atunci când componenta GUI ș i Java trebuie să comunice date, dar mai rapid la
redare atunci când modelul de date a fost încărcat în GUI[1]Cu toate acestea,
benchmark-urile nu arată un câș tigător clar, iar rezultatele depind foarte mult de context
ș i mediile[2].

SWT servează foarte bine platforma Windows, dar este considerat de unii a fi mai puț in
eficient ca tehnologie pentru dezvoltarea multiplatformă. Prin utilizarea unui nivel înalt
caracteristicile fiecărui toolkit de feronerie nativ, SWT revine la problemele observate în
mijlocul anilor '90 (cu kituri de instrumente precum zApp, Zinc, XVT ș i IBM/Smalltalk) unde kiturile
a încercat să mascheze diferenț ele în comportamentul de focalizare, declanș area evenimentelor ș i grafic.
layout. Neconformarea comportamentului pe fiecare platformă poate provoca probleme subtile, dar dificile -
a rezolva erorile care afectează interacț iunea utilizatorului ș i aspectul interfeț ei grafice.

Depanarea aplicaț iilor Swing

Debugging aplicaț iilor Swing poate fi dificil din cauza naturii vizuale a toolkit-ului.
În contrast cu aplica ț iile non-vizuale, GUIaplica ț iile nu pot fi la fel de u ș or
debugged folosind pas cu pasdebuggeriUnul dintre motive este că Swing, de obicei
realizează pictura într-un buffer off-screen (dublu buffer) mai întâi ș i apoi copiază
întreaga rezultată pe ecran. Acest lucru face imposibilă observarea impactului de
fiecare operaț iune grafică separată peinterfaț ă utilizatorfolosind un scop general
JavadebuggerExistă, de asemenea, câteva probleme comune legate de vopsea.
fir. Swing utilizeazăfirul de execuț ie pentru gestionarea evenimentelor AWTpentru componente de vopsit. În
conform standardelor Swing, toate componentele trebuie accesate doar din
fire ș te, firul de dispatch al evenimentelor AWTDacă aplica ț ia încalcă această regulă, ar putea cauza
comportament imprevizibil. Dacă operaț iunile de lungă durată sunt efectuate înAWT
firea evenimentelorvopsirea din nou a Swing-ului interfaț ă utilizatortemporar devine
imposibil să cauzeze blocări ale ecranului.

Există instrumente ș i utilitare de diagnosticare cu scop special care facilitează depanarea.

aplicaț iilor Swing ș i abordaț i problemele menț ionate mai sus:

7. Modelul procesului software

În timpul dezvoltării sistemului, am urmat ciclul de viaț ă al sistemului,

care este o practică generală în Cyber Mate. În conformitate cu ISO 9000-3
terminologie, întregul ciclu de via ț ă al software-ului a fost împăr ț it în ș ase etape distincte
procese. Am urmat modelul iterativ de tip waterfall ca model de ciclu de viaț ă
pentru proiectul nostru.

Cele ș ase procese ale ciclului de viaț ă al sistemului software sunt următoarele:

Studii de fezabilitate
Analiza ș i specifica ț ia cerin ț elor
•Design
•Codare ș i testare unitară
Testare de integrare ș i a sistemului
Între ț inere

Studiu de Fezabilitate:

Scopul principal al studiului de fezabilitate este de a determina dacă ar fi

financiar ș i tehnic fezabil pentru a dezvolta produsul.
În această fază am analizat datele colectate ș i am ajuns la următoarele:
 •O defini ț ie abstractă a problemei. Este descrierea brută a proiectului.
care ia în considerare doar cerinț ele importante ș i ignoră restul.
Formularea diferitelor strategii de solu ț ionare.

•Analiza strategiilor alternative de solu ț ionare pentru a compara beneficiile acestora ș i

neajunsuri. În această fază, estimăm resursele necesare, costul de

dezvoltare ș i timpul de dezvoltare pentru fiecare dintre opț iuni.

Analiza ș i specificaț ia cerinț elor:

Scopul fazei de analiză ș i specificare a cerinț elor este de a înț elege
cerinț ele exacte ale clientului ș i să le documenteze corespunzător.

Această etapă constă în două activităț i distincte, ș i anume colectarea cerinț elor
ș i analiză, ș i specificaț ia cerinț elor.
Design
Scopul fazei de proiectare este de a transforma cerinț ele specificate în
Document SRS într-o structură care este potrivită pentru implementare în unele
limbaj de programare.
În această fază, am urmat abordarea proiectării orientate pe obiecte (OOD).
tehnică, diverse obiecte care apar în domeniul problemei ș i domeniul soluț iei
sunt mai întâi identificate ș i apoi există diferite relaț ii între acele obiecte
sunt identificate.
Codare ș i Testare unitară:
Scopul fazei de codare ș i testare unitară a dezvoltării software-ului este să
transformaț i designul software-ului în cod sursă ș i testaț i fiecare modul în izolare ca
aceasta este cea mai bună metodă de a debuga erorile identificate în această etapă.

Integrarea ș i Testarea Sistemului:

Scopul de bază al integrării ș i testării sistemului este de a se asigura că dezvoltarea
sistemul se conformează specificaț iilor sale de cerinț e.

În timpul fazei de integrare ș i testare a sistemului, modulele sunt integrate într-o

mod planificat. Am realizat incremental acest lucru pe parcursul unui număr de paș i. În timpul

fiecare pas de integrare, sistemul parț ial integrat este testat ș i seturi de
modulele planificate sunt adăugate la acesta. În cele din urmă, când toate modulele au fost

a fost integrat ș i testat cu succes, testarea sistemului este efectuată.

Întreț inere:
Întreț inerea unui produs software tipic necesită mult mai mult efort decât
efortul necesar pentru a dezvolta produsul în sine.
Întreț inerea implică efectuarea uneia sau mai multor dintre următoarele trei tipuri
de activităț i:
Întreț inere corectivă:
Corectarea erorilor care nu au fost descoperite în timpul dezvoltării produsului
fază.
Întreț inere perfectivă:
Îmbunătăț irea implementării sistemului ș i îmbunătăț irea funcț ionalităț ilor

al sistemului conform cerinț elor clienț ilor.

Întreț inere adaptivă

Portarea software-ului pentru a funcț iona într-un nou mediu.

8. Definirea ș i descrierea problemei

Sistem de gestionare a programului

Sistemul de gestionare a orarului este un sistem pentru men ț inerea întregului orar
procesul de generare într-o colegiu ș i păstrarea unui istoric al informaț iilor despre subiecte,
laboratoare ș i profesori. Cele mai mari firme ar trebui să aibă propriul lor Orar

Sistem de Management.

Sistem existent

Sistemul existent era un sistem manual. Necesitatea computerizării

sistemul existent a apărut din cauza multor dificultăț i, nereguli ș i inexactităț i
prezent în sistemul actual. Principala cauză a îngrijorării include lipsa e-mailurilor,
întârziere de informa ț ii, lipsă de interac ț iune. În sistemul anterior colegiile erau

menț inerea detaliilor programului manual pe hârtie, care necesita mult timp
ș i costisitoare. Toate acestea au fost cauzele celei mai puț in eficiente strategii de management. Aș adar,

ferma a decis să informatizeze acest sistem.

Sistem propus

Sistemul propus este o aplicaț ie complet bazată pe computer. În propus

administratorul de sistem nu ar trebui să- ș i facă griji cu privire la întârzierea ș i comportamentul lor necorespunzător

gestionarea detaliilor de vânzări. Toate informaț iile vor fi disponibile printr-un singur clic

pe un singur buton. Mii de înregistrări pot fi căutate ș i afi ș ate fără

luând orice timp semnificativ.

Avantajele sistemului propus:

Prin implementarea acestui pachet, organizaț ia va primi o eroare.

date gratuite de analizat.

Administratorul va urmări informaț iile despre clienț i ș i articole

uș or.
Raportul zilnic de vânzări poate fi uș or întreț inut ș i generat.
Va oferi un proces de planificare mai bun.
 Această pachet ar limita factorul timp ș i bani implicat în
Procesul de gestionare a orarului
Între ț inerea este mult mai u ș oară ș i precisă decât cea existentă
sistem manual.
Func ț iile de securitate sunt oarecum mai ridicate decât cele manuale

abordare.

Specificaț ie de cerinț e:

Sistemul ar trebui să fie prietenos cu utilizatorul.

Ar trebui să fie capabil să gestioneze mai mul ț i utilizatori simultan.

Sistemul ar trebui să fie rapid.

Men ț inerea unei baze de date a diferitelor articole.

i. Adăugarea unui nou element

[Link] articolului existent
iii. Ș tergerea celor existente

Ar trebui să fie capabil să gestioneze detaliile clien ț ilor eficient.

[Link]ăugarea de noi subiecte

ii. Adăugarea detaliilor noi ale laboratorului

Sistemul trebuie să satisfacă nevoile întregi ale fermei.

9. Analiza ș i Proiectarea Sistemelor:

Analiza este principala preocupare a dezvoltării sistemului ș i este etapa în care sistemul
designeri trebuie să lucreze la două niveluri de definiț ie în ceea ce priveș te studiul situaț ional

probleme ș i soluț ii posibile în termeni de „ce să facem” ș i „cum să facem”.

Studiul sistemului

Definirea Sistemului:

Un sistem este un grup organizat de componente independente legate între ele

conform unui plan pentru a atinge un obiectiv specific. Principalele sale caracteristici sunt

organizaț ie, interacț iune, independent, integrare ș i obiectiv central a

sistemul nu înseamnă neapărat un sistem de calcul. Poate fi unul manual

sistem sau orice altceva

Necesităț ile sistemului:

• Factor social ș i economic:

O undă de schimbări sociale ș i economice urmează adesea în urma
tehnologie nouă. Noi oportunităț i pot apărea pentru a îmbunătăț i o producț ie
proces sau a face ceva care anterior nu era posibil. Schimbări în
modurile în care indivizii sunt organizaț i în grupuri pot fi apoi necesare, iar
noi grupuri pot concura pentru resurse economice cu unităț i deja stabilite.
• Factor tehnologic:
Oamenii nu au fost niciodată într-o epocă în care amploarea cercetării ș tiinț ifice să fie atât de

larg, aș a că atunci când viteza aplicării noii tehnologii este responsabilă pentru multe

schimbări în organizaț ie.

• Decizii la nivel înalt ș i procese operaț ionale:

În răspuns la factorii tehnologici ș i socio-economici, managerii de vârf pot
decide să recunoască operaț iunile ș i să introducă produse noi.

Pentru a face faț ă acestor nevoi, oamenii caută de obicei informaț ii noi ș i modificate pentru

sus ț ine decizia. Când se întâmplă asta, atunci ei ob ț in o întoarcere la un computer

sistem pentru a ajuta utilizatorii de informaț ii ș i specialiș tii în procesarea datelor să lucreze

împreună pentru a finaliza o serie de paș i într-un studiu de sistem pentru a produce rezultate de ieș ire către

satisfac nevoile de informaț ii.

[Link] sistemului
Analiza sistemului este un proces prin care atribuim procese sau obiective unei persoane.

activitate, determină cât de bine sunt realizate acele scopuri ș i specifică

cerinț ele diferitelor instrumente ș i tehnici care urmează să fie utilizate în cadrul
sistem dacă performanț ele sistemului urmează să fie atinse.

Planificarea sistemului

Planificarea sistemelor de informaț ii are un orizont temporal ș i o dimensiune de concentrare.

Dimensiunea orizontului temporal specifică intervalul de timp al planului, în timp ce

dimensiunea de concentrare se referă la faptul dacă preocuparea principală este strategică, managerială sau

operativ. Proiectul care ne-a fost atribuit trebuia să fie finalizat în termen de 16

Săptămâni. Ceea ce am planificat este următorul lucru:

Analiza cerin ț elor, Investiga ț ia preliminară ș i Colectarea informa ț iilor

ar trebui să fie acoperit în 1stș i 2ndsăptămână. Deoarece nu eram conș tienț i de unele dintre

unealta, adică struts, server web ș i tiles, am păstrat 3 săptămâni pentru a înț elege
nodurile ș i ș uruburile acestor unelte. 9 săptămâni pentru designul sistemului sub
dezvoltare. 1 săptămână pentru Testare ș i Implementare. Ș i restul de 2 săptămâni rezervate.

Investigaț ie preliminară
Investigaț ia iniț ială are ca obiectiv determinarea validităț ii
cererea utilizatorului pentru un sistem de candidaț i ș i dacă ar trebui să se efectueze un studiu de fezabilitate

efectuat.
Obiectivele problemei formulate de utilizator trebuie înț elese în cadrul
cadru al planului MIS al organiza ț iei. Am investigat din
autoritatea competentă cu privire la proiect
Colectarea informaț iilor

O parte esenț ială a analizei de fezabilitate este colectarea informaț iilor despre prezent
sistem. Analistul trebuie să ș tie ce informaț ii să colecteze, unde să le găsească, cum să
colectează-l ș i ce să faci cu el. Utilizarea corectă a uneltelor pentru adunarea informaț iilor
este cheia analizei de succes. Instrumentele sunt interviul tradi ț ional,
chestionare ș i observaț ie la faț a locului.
Analiză Structurată
Instrumentele tradi ț ionale de colectare a datelor au limitări. O nara ț iune în limba engleză
descrierea este adesea vagă ș i dificil de înț eles pentru utilizator. Diagramă de flux a sistemului

concentrează-te mai mult pe implementarea fizică decât pe cea logică a sistemului candidatul.

Din cauza acestor dezavantaje, au fost introduse unelte structurate pentru analiză.
Analiza structurată este un set de tehnici ș i unelte grafice (DFD) care permit
analist pentru a dezvolta un nou tip de specifica ț ii ale sistemului care sunt u ș or de

înț eles de utilizator.

11. DIAGRAMA Fluxului de Date

Diagrama fluxului de date este o reprezentare diagramatică a miș cării datelor printr-o
sistem - manual sau automat - de la intrări la ieș iri prin procesare. The
diagramele de flux de date ajută la analiza fluxului de date printr-un sistem ș i
astfel ajutând la identificarea cerinț elor sistemului. Acestea sunt de două tipuri - Logic
Diagrama Fluxului de Date ș i Diagrama Fizică a Fluxului de Date. Diagrama Fluxului de Date

(DFD) clarifică cerinț ele sistemului ș i identifică transformările majore care vor
devin programe în proiectarea sistemelor. Este punctul de plecare al proiectării sistemelor care

decomite specificaț iile cerinț elor la cel mai mic nivel de detaliu.

Diagramă de Flux de Date Logic

Diagrama Fluxului de Date Logice reprezintă transformarea datelor din
introducere în ie ș ire prin procesare logică ș i independentă de fizic
componente care pot fi asociate cu sistemul.

Diagramă de flux de date fizice

Diagrama fluxului de date fizic arată implementarea ș i miș carea efectivă

de date între oameni, departamente ș i staț ii de lucru. Fiecare componentă a unui DFD
este etichetat cu un nume descriptiv. Numele proceselor sunt numerotate ulterior, care vor fi
folosit pentru scopuri de identificare. Numărul atribuit unui proces specific nu
nu corespunde secven ț ei de procese. Este strict pentru identificare
scopuri. Un diagramă de flux de date permite activităț i paralele, adică un număr de fluxuri de date.

ieș ind din sursă ș i mergând spre destinaț ie. Un DFD se concentrează pe
datele care circulă prin sistem ș i nu pe dispozitive sau echipamente. Un DFD
poate consta dintr-un număr de niveluri. Diagrama de nivel superior se numeș te Context
Diagrama, care constă dintr-un singur proces ș i joacă un rol foarte important în
studiază sistemul. Oferă cea mai generală ș i lărgită viziune asupra sistemului.
Muta ț i-vă, oferă reprezentarea picturală a limitelor domeniului de aplicare al
sistem în studiu.

NOTATIONS:

Fluxurile de date arată mi ș carea datelor într-o direc ț ie specifică de la

sursa către destinaț ie. Reprezintă un pachet de date.

Procesele arată operaț iile efectuate asupra datelor, care le transformă

de la intrare la ieș ire.
 Sursele ș i destinaț iile datelor sunt sursele ș i destinaț iile externe ale
date, care pot fi persoane, programe, organiza ț ii sau alte entită ț i
interacț ionând cu sistemul, dar fiind în afara graniț ei sale.

Stocările de date sunt locuri unde datele sunt stocate, cum ar fi fiș ierele ș i tabelele.

Mai jos este DFD-ul de nivel superior care arată cum este procesată cererea utilizatorului
server cu interacț iune cu baza de date ș i trimite răspunsul înapoi utilizatorului.

Studie de fezabilitate

Toate proiectele sunt fezabile atunci când se oferă resurse nelimitate ș i timp infinit! Dar
dezvoltarea sistemului bazat pe calculator este probabil să fie influen ț ată de lipsa de

resurse ș i dificultate în datele de finalizare.

Fezabilitatea unui sistem bazat pe computer poate fi studiată în trei domenii principale:

Fezabilitate economică
Fezabilitate tehnică
Fezabilitatea Funcț ională

Fezabilitatea Economică

O evaluare a costului dezvoltării raportat la venitul final de beneficiu

derivate din sistemul dezvoltat. Informaț ii foarte importante conț inute în
studiul de fezabilitate se ocupă de analiza cost-beneficiu, care este
evaluarea justificării economice pentru un proiect de sistem bazat pe calculator.

Sistemul este foarte prietenos cu utilizatorul ș i sunt folosite doar termeni comuni în

aplicaț ie ș i astfel nu va fi greu pentru utilizatorul final să gestioneze sistemul.

Sistemul oferă o ghidare foarte detaliată pentru fiecare pas de urmat în timp ce este utilizat.

Fezabilitatea Tehnică

Un studiu asupra funcț iei, performanț ei ș i constrângerilor care pot afecta capacitatea de
obț ine un sistem acceptabil. Analistul evaluează meritele tehnice ale
sistem, în acelaș i timp, colectează informaț ii suplimentare despre performanț ă,
fiabilitatea ș i întreț inerea produselor finale.

Tehnologia nu este o constrângere pentru dezvoltarea sistemelor. Cele mai recente tehnologii sunt

încorporată astfel încât să atingă cele mai bune dintre aceste noi dezvoltări în sistem.
Sistemele dezvoltate se generalizează complet, astfel încât orice expansiune viitoare nu va fi o

problemă.
Fezabilitate Funcț ională
Sistemul va fi acceptabil pentru utilizatorii care vor fi ajuta ț i foarte mult de
sistemul, implicarea utilizatorului în fiecare parte a dezvoltării va fi
util în cre ș terea factorului său de succes. Sistemul actual existent este mai pu ț in
interactiv ș i nu la înălț ime în ceea ce priveș te suportul pentru clienț i.

Din toate acestea, putem concluziona că acest sistem este economic, tehnic ș i
funcț ional fezabil.
Aprobat proiect
Proiectele care sunt atât fezabile, cât ș i dorite ar trebui incluse într-un program.
După aprobarea unei cereri de proiect, costul, prioritatea, timpul de finalizare ș i
cerinț ele personale sunt estimate ș i folosite pentru a determina unde să le adăugăm la un

lista existentă.

DIAGRAMĂ DE FLUX DE DATE

Diagramă de nivel contextual

Program Program
Administrator Management
0.0

Diagrame de flux de date de nivelul întâi

Admin Admin

Stăpân
Intrare Raportare Raport
1.0 2.0

Admin Admin

Depozit de Date
Ramură Subiect
Master Maestru
Diagrama DFD de Nivelul doi 1.1 1.2

Ramură Subiect
Stăpân Stăpân
Admin Admin

Perioadă Învăț ător

Maestru Maestru
1.3 1.5

Perioadă
Profesor
Maestru

Admin

Lab
Maestru
1.4

Laborator Ș ef
DIAGRAMĂ E-R
 DESCRIEREA BAZEI DE DATE

- Filială
Acest tabel este pentru întreț inerea filialelor disponibile

Tabel
Această tabelă păstrează informaț iile despre informaț iile sucursalei.

Tabel:- Asistent de laborator

Această tabelă conț ine informaț ii despre toate asistenț ele de laborator

Tabel :- Perioadă
În această tabelă menț inem detaliile perioadei.
Subiect
Această tabelă este pentru menț inerea înregistrărilor detaliate despre subiecte.

Profesor
Această tabelă conț ine detalii despre profesor.
 DISPOZIȚII ECRAN

Aceasta este pagina principală de start a aplicaț iei.

În acest ecran trebuie să menț inem detaliile filialei. De asemenea, putem actualiza ș i
eliminaț i detaliile filialei.
Această pagină este responsabilă pentru menț inerea informaț iilor despre profesori.
Managementul subiectelor
Gestionarea perioadelor
Gestionarea detaliilor laboratorului
Managementul asistenț ei de laborator
Pe această pagină, aplicaț ia vă solicită lotul pentru a genera raportul.
În această pagină, aplicaț ia vă cere sesiunea educaț ională pentru a genera raportul.
Această pagină oferă orarul complet funcț ional.
TESTARE

Testarea este un pas în procesul de inginerie software care ar putea fi văzut ca

destructiv mai degrabă decât constructiv. Testarea necesită ca dezvoltatorul să renun ț e
no ț iuni preconcepute despre „corectitudinea” software-ului dezvoltat recent ș i
depăș irea unui conflict de interese care apare atunci când se descoperă erori.

Dacă testarea este efectuată cu succes, aceasta descoperă erori în software.

beneficiu secundar, testarea demonstrează că func ț iile software-ului par a fi
lucrând conform specifica ț iei. Testarea oferă o bună indica ț ie a
fiabilitatea software-ului ș i o anumită indicaț ie a calităț ii software-ului în ansamblu.

Testarea nu poate demonstra absenț a defectelor, ci doar că există defecte în software.

sunt prezent.

Deoarece software-ul dezvoltat nu îndeplineș te toate cerinț ele unei organizaț ii,
aș adar, nu este posibil să testăm cu date în timp real.

Încă atunci am încercat din răsputeri să testăm fiecare modul individual ș i, de asemenea, ca un întreg.
module (în ansamblu) cu date suficiente pe care o organizaț ie le poate avea, îndeplinind
obiectivul sistemului nostru de „Gestionare a Tabelului de Ore”.

Testarea joacă un rol foarte critic pentru asigurarea calită ț ii ș i asigurarea

fiabilitatea software-ului. În timpul testării, programul care urmează să fie testat este executat cu
un set de cazuri de testare ș i ieș irea programului pentru cazurile de testare ș i ieș irea de
programul pentru cazul de test este evaluat pentru a determina dacă programul funcț ionează ca
se aș teaptă să. Prin urmare

Testarea este procesul de executare a unui program cu inten ț ia de a găsi

eroare.
Un caz de testare bun este acela care are o probabilitate mare de a găsi încă
eroare nedescoperită.
Un test de succes este unul care descoperă erori încă neidentificate.

Testarea se efectuează conform a două strategii diferite:

.
Testarea Codului:
Strategia de testare a codului examinează logica programului, adică analistul dezvoltă
cazuri de testare care rezultă în executarea fiecărei instruc ț iuni din program. Practic
în timpul testării codului, fiecare cale prin program este testată.

Testarea specificaț iilor:

Pentru a efectua testarea specifica ț iilor, analistul examinează specifica ț ia începând cu
ce ar trebui să facă programul ș i cum ar trebui să funcț ioneze în diverse condiț ii.
Apoi sunt dezvoltate cazuri de testare pentru fiecare. Pentru a găsi ce strategii să urmezi,
nivelurile de testare ar trebui să fie urmate

Niveluri de testare

Nivelurile de bază sunt testarea unităț ii, testarea de integrare, testarea sistemului ș i acceptarea
testare. Aceste niveluri diferite de testare încearcă să
detecta diferite tipuri de defecte. Nivelurile diferite de testare sunt următoarele:

Testarea unităț ilor:

În acest test, diferite module sunt testate împotriva specificaț iei elaborate în timpul
designul modulelor. Testarea unităț ii este esenț ială pentru verificarea codului produs
în timpul fazei de codare ș i, prin urmare, scopul său principal este de a testa modulele de logică internă.
Testare de integrare:
În acest test, modulele testate sunt combinate în subsisteme care sunt apoi testate.
Scopul aici este să vedem dacă modulele pot fi indicate corect ș i accentul este
a fi pe teste interfeț e între module.
Testare de sistem:
În acest test, întregul sistem software este testat. Documentul de referinț ă pentru acest
procesul este documentul de cerinț e ș i scopul este de a verifica dacă sistemul îndeplineș te cerinț ele sale
cerinț e.

Aceasta se desfăș oară în mod normal pe datele realiste ale clientului pentru a demonstra pentru
software-ul funcț ionează satisfăcător. Testarea aici se concentrează pe comportamentul extern al
sistem.

Implementarea sistemului

Implementarea este etapa proiectului când designul teoretic se transformă într-un

sistem de lucru. În această etapă, volumul principal de muncă, recuperarea ș i impactul major
pe practicile existente, transferul către departamentul utilizatorului. Dacă etapa de implementare nu este

planificat ș i controlat cu atenț ie, poate provoca haos. Astfel, poate fi considerat a
fi etapa cea mai crucială în atingerea unui nou sistem de succes ș i în oferirea
încrederea utilizatorilor că noul sistem va funcț iona ș i va fi
eficient.

Viziunea de implementare a cerin ț elor software prezintă realitatea

manifestarea funcț iilor de procesare ș i structurilor de informaț ii. În unele cazuri, o
reprezentarea fizică este dezvoltată ca primul pas în proiectarea software-ului. Cu toate acestea
cele mai multe sisteme bazate pe calculatoare sunt specificate într-un mod care dictează

acomodarea anumitor detalii de implementare.

Implementarea implică o planificare atentă, investigarea sistemului actual ș i

constrângeri asupra implementării, designul metodelor pentru a realiza schimbarea,
instruirea personalului în procedurile de schimbare ș i evaluarea schimbării
metode. Prima sarcină este planificarea implementării adică decizia metodelor
ș i intervalul de timp care urmează să fie adoptat.

Odată ce planificarea a fost finalizată, efortul major în computer

departamentul trebuie să se asigure că programele din sistem funcț ionează corect. La
în acelaș i timp, departamentul utilizatorului trebuie să se concentreze pe formarea personalului utilizator.

personalul a fost pregătit, un test complet al sistemului poate fi efectuat, implicând atât ...
proceduri informatice ș i administrative.

Paș ii principali ai implementării includ

1. Instalarea ma ș inii client.
2. Instalarea software-ului pe server.
3. Instruirea personalului operativ.
 Cerinț ele continuă să se schimbe în timp, aș a că implementarea acestuia
proiectul poate evolua în timp, prin urmare implementarea este un proces continuu, care
poate să se schimbe în viitor.

DISCUȚIE

Aș a cum am discutat mai devreme în cadrul proiectului, "timpul nu permite finalizarea întregii

proiect, astfel încât ca parte a întregului să fie realizat ș i să fie trimis ca

proiect în curriculumul nostru. Software-ul total, împreună cu caracteristici extinse, va fi

submit ca Proiect Major", aici este întregul Sistem de Gestionare a Timpului

cu caracteristici extinse care îndeplinesc cerin ț ele oricărei distribu ț ii moderne
ferme.

Deș i am încercat să facem întregul pachet infailibil în ceea ce priveș te erorile, este posibil să

au unele erori inerente (dincolo de cunoș tinț ele noastre), deoarece nu a fost încă testat cu
date în timp real.

În cele din urmă, ne vom continua efortul în dezvoltarea software-ului care îndepline ș te cerin ț ele de bază

cerinț ele oricărei ferme de distribuț ie, dacă timpul permite.

Credem că sistemul va satisface nevoile de bază ș i se va dovedi a fi util.

software prietenos ș i eficient ori de câte ori este implementat în
organizaț ie.
 BIBLIOGRAFIE

[Link]ț ă completă J2SE 5thediț ie

[Link]