Kezdőlap

|

Mi a kreditvadasz.hu Egy felsőoktatási közösségi oldal amely segít kapcsolatot tartani a hallgatók között, így segítséget nyújt a sikeres tanulmányokhoz...

Jegyzet

Országok listájaHungaryMiskolci EgyetemGépészmérnöki és Informatikai KarGazdaságinformatikusSzoftvertechnólogiák (SWENG)Jegyzet

2008.06.10 21:36:27
(10)
Szerző: Szabó Botond
Cimkék: jegyzet


Az alábbi szöveg egy formázás és képek nélküli előnézete a dokumentumnak. A tökéletes megjelenítéshez jelentkezz be, majd töltsd le a dokumentumot.
SWENG
Software Engineering

Alapfogalmak:
Technologia: Egy elQállítási folyamat szabályait technológiának nevezzük.
Sweng: Eszközök és módszerek a szoftver termékszerq elQállítására.
Dekompozíció: a teljes software módszeres részekre bontása.
Az objektum: egyediséggel rendelkezQ diszkrét entitás
OMT: Swengben használt módszertan, az objektumorientált programok tervezésére....
RUP: Keretrendszer, a mai modern fejlesztése feladatokra tulajdonságainak figyelembe vételével
Fejlesztési fázis típusok: Analizis, Specifikáció, Tervezés, Implementáció,Tesztelés, Használat
Waterfall(Boehm 1976):

Gyors prototipus:






Inkrementális:

Újrafelhasználás:







Very high level languages

Spirál modell(Boehm1988):





Object Modelling Technique
(OMT)




Objektum modell:
"MIVEL?"
A rendszer általános struktúrája
Funkcionálisdekompozícióhelyett strukturális
Jelölésrendszer:
-osztály diagramm
-komponens diagram
Eredetileg saját jelölésrendszer, a továbbiakban ahol lehet, UML

Dinamikus modell:
"MIKOR?"
A rendszer építQelemeinek viselkedése(idQbeli
Minden objektumra:
 hogyan változtatja állapotát
 hogyan hat a környezetére
Eszközök:
 állapot diagram (UML)
 sorrend diagram (UML)
 eseményfolyam-diagram (saját)változása)



Funkcionális modell:
"MI?"
A rendszeren belüli számítások, feldolgozások.
Nem tartalmaz idQt.
Megadhatjuk:
 az objektum modell mqveleteit
 a dinamikus modellakcióit
 az objektum modell korlátozó feltételeit
Eszköze:
" DFD (eredeti)
" aktivitás és együttmqködési diagramm (UML)

A fejlesztés fázisai:
1. Analízis
•A feladat szöveges megfogalmazásából indul
•Az alkalmazás szakterületének fogalmaival
•Kapcsolat a felhasználóval
•Bonyolult rendszernél több iteráció
•Elkészített modellek:
–objektum modell
Osztályok azonosítása(a szövegben általában fQnevek utalnak lehetséges osztályokra)
MegfelelQ osztályok kiválasztása.
Osztályok leírása  repository!
Asszociációk azonosítása.(Igék vagy igei kifejezések utalhatnak rá.)
MegfelelQ asszociációk kiválasztása.
Ternáris(illetve többszörös) asszociációk átalakítása
Asszociációk szemantikájának ellenQrzése
 megfelelQ elnevezés
 számosság meghatározása
 minQsített asszociációk kiválasztása
 hiányzó asszociációk feltárása
Attributumok azonosítása(melléknevek, birtokos szerkezetek)
MegfelelQ attributumok kiválasztása
Általánosítás(pl. jelzQs kapcsolat azonos attribútumok kiemelése, származtatási tárgyakhoz) - a több osztályban elQforduló hierarchia kialakítása
Elérési utak tesztelése
Modulok meghatározása
Iterációs finomítás, ha a rendszer összetettsége indokolja

 dinamikus modell
Forgatókönyvek készítése ( a mqködést kísérQ események)
Felhasználói felület (vezérlés, információ csere)
szekvencia diagram rajzolása (az események közötti ok-okozati összefüggések feltárása)
állapotdiagram rajzolása objektumonként
eseményfolyam diagram készítése

–funkcionális modell (ki dolgozik)
Be-és kimeneti értékek azonosítása
Adatfolyam-diagram megrajzolása
A transzformációk specifikálása
Objektumok közötti korlátozások meghatározása
Optimalizálandó értékek meghatározása

2. Rendszertervezés (systemdesign)
•alrendszerekre bontás
–réteges (zárt és nyílt architektúra)
–partíciók - egymáshoz lazán kapcsolódó részek
–osztott (distributed) architektúra - az egyes részek különbözQ csomópontokon
" a megvalósítás stratégiai döntései
 erQforrások elosztása
 optimalizálandó tulajdonságok
 alrendszerek közötti kommunikáció
 végrehajtás/vezérlés módja
A rendszer topológiájának meghatározása
Lényegi konkurencia meghatározása
Alrendszerek processzorokhoz és taszkokhoz rendelése
Adattárolás eszközének kiválasztása (kell-e adatbázis-kezelQ, ha igen, milyen)
Globális erQforrások elosztásának szabályozása (memória, processzor, hálózat stb.)
Vezérlés elvének kiválasztása (Eljárás orientált, Eseményorientált, valódi párhuzamos)
Rendszer határfeltételeinek meghatározása.(elsQ indulás elQtt, inicializálás, terminálás, hibás befejezQdés)
Felhasználói felület / külsQ interface tervezése

3. Objektumtervezés (object design)
" A három modell egyesítése
" Algoritmustervezés
" Asszociációk tervezése (egyirányú kétirányú)
" Láthatóság biztosítása
- globális objektum - mérlegelés után!
- argumentum - feltételekhez kötött!
- tartalmazás - gyakori
- elérési függvények
" KözvetítQ objektum
" Nem OO környezethez való illesztés
•Ütemezési szerkezet kialakítása
•Optimalizálás
•Deklarációs sorrend meghatározása
•Modultervezés

4. Implementáció
•a modell lefordítása egy programozási nyelvre















Unified Modeling Language
(UML)

Történelem:
Az 1990-esévek közepe - vezetQ módszertanok:
Booch'93 (Booch): erQs a tervezés fázisában, népszerq az engineering-intenzív alkalmazásoknál.
OMT2(Rumbaugh) : erQs az analízis fázis során, népszerq az adat-intenzív alkalmazásoknál.
OOSE(Jacobson) : kiváló támogatást ad a "businessengineering"-hez, és igazan csak ez támogatja a követelmény analízist.
1991-ben Grady BoochésJim Rumbaugh
1995 október: UML 0.8
1995-benIvar Jacobson is csatlakozott
1996. október: UML 0.91
1997. január 17.: UML 1.0 (OMG-nek!)
1997. szeptember: UML 1.1 (szabvány!)
Az utolsó teljes szabványos verzió az UML 1.5 ) (elfogadva 2003. március)
Részben elfogadva: UML 2.0 (2006. március.)













UML elemei:
use case diagramm
Osztály diagramm
Viselkedés diagrammok :
–állapot diagramm (state diagram)
–aktivitás diagramm (activity diagram)
 sorrend diagramm (sequence diagram)
 együttmqködési diagramm (collaboration diagram)
Implementációs diagrammok:
 komponens diagramm (component diagram)
 telepítési diagramm (deployment diagram)
Kiterjesztési mechanizmusok
 kiegészítQ jelölések, amelyek több diagramtípus által is használhatók


Az UML kiegészítQ jelölései:
 sztereotípia(stereotype): új modell elemek jelölésére
Formája: << megnevezés >>

 megszorítás(constraint): az UML más jelöléseivel
Formája: {megszoritás l:NXprèüp t ê ì

X
d
þ

¼
ò
>

?

V

W

X

j

k

o

s



‚

ƒ

–

õëäÙäÙÑÙÑÆ¾²§œ¾Æ¾ÆÑ¾Ñ‘‚Ñ‘sÑk‘k\kjíRhÁk hÁk CJUaJ hÁk CJaJj€zhÁk hÁk CJUaJjhÁk hÁk CJUaJ hÁk hÁk CJaJ hæ:hæ:CJaJ hæ:5CJ\aJhæ:hæ:CJ\aJ h
JÎCJaJ h
JÎh
JÎCJaJ hÁk CJaJ hÁk hÁk CJaJ

hÁk 5\hÁk hÁk 5\ hÁk 5CJ\aJ

8:Vìt ì X
þ
¼
?

V

X

j

l

o

p

q

r

s

‚

„

÷÷÷òòòéàòÓòÊÊÊÊòÁÁÁÁÁÁ„ ^„ gdÁk „ˆ^„ˆgdÁk

„ „0ý^„ `„0ýgd
J΄Ä`„Ägdæ:„Ä`„Ägd
JÎgdÁk $a$gdtJ{ý„

–

˜

™

š

›

œ



ž

¸

º

Ö

Ø

Ù

Ú

Û

Ü

ø

þ

ÿ





ööööööööööñäñß××××ÒÒÒÍÍgdtgdt $a$gdtgdÁk

„Ä„Ä^„Ä`„Ägd
JÎgd
J΄ ^„ gdÁk –

—

¸

¹

º

Ö

×

Ø

Ù

Ü

â

ã

ì

í

ö

ø

ý

þ

ÿ



>
J
^
j
|
}
Ž

Þ
á
ã
õ
0 F ò ²¶ðèÙèÑÂѾ³¥š¥š¥š¥‹ƒ‹|r|r|‹|‹|rkc|r|r|khtht\

ht5\htht5\

hthtjÓ¦htUht hthtCJaJ ht5CJ\aJhtht5CJ\aJ hÁk 5CJ\aJh
JÎj#fh
JÎh
JÎCJUaJ h
JÎCJaJj®‰hÁk hÁk CJUaJ hÁk CJaJj]|hÁk hÁk CJUaJ&

>
k
|
Ž
¡
â
ã
õ
þ
Z € ¼ ò 4b¶¸º¼æòööööíöääßÖÖÖÖÖÖÖÖÍßßßßք`„gdt„`„gdtgdt„Ä^„Ägdt„Ä`„Ägdt„Ä^„Ägdt¶æºÎö.Xâä Ö×ì 6 N V Ü Þ dh°²üõëõëõëõüçÝÖËõª¢“‡“{µpµpª¢µpµ^#h0
¾h0
¾5B*CJ \aJ phÿ h0
¾5CJ \aJ h0
¾B*CJ aJ phÿh½GUB*CJ aJ phÿh0
¾h0
¾B*CJ aJ phÿ h0
¾CJ aJ h0
¾h0
¾CJ aJ h0
¾h0
¾5CJ \aJ h0
¾CJaJ h0
¾h0
¾CJaJ

h0
¾h0
¾h0
¾h0
¾5\h0
¾htht5\

hththt-òPx’ÐZnŒäæ BnНÆ×P š Þ ööööööööííèßÖÖÖÖÖÍÀ··„Ä^„Ägd½GU

„¨

„˜þ^„¨

`„˜þgd½GU„L^„Lgd½GU„ˆ^„ˆgd0
¾„Ä^„Ägd0
¾gd0
¾„`„gdt„`„gdtÞ h²pšÌXÖBr <²Ê
òòòòåÜÜåÓòÆÆÆÆò½ÓÓ°°

„œ

„tþ^„œ

`„tþgd½GU„L^„Lgd½GU

„è
„(ÿ^„è
`„(ÿgd½GU„Ä^„Ägd½GU„Ô
^„Ô
gd½GU

„
„Ä^„
`„Ägd½GU

„L„Ä^„L`„Ägd½GU npV^vxŽªÔÖèê8¢¤ *,@Bœ äæ :Bvx®¸àðâ×ÌĶ«¶ ‘…¶«¶«¶«¶ } ‘…‘…¶«¶«k¶ }×âÌÄâ#h0
¾h0
¾5B*CJ\aJphÿ h0
¾CJaJh0
¾B*CJaJphÿh0
¾h0
¾B*CJaJphÿ h0
¾h0
¾CJaJ h0
¾5CJ\aJh0
¾h0
¾5CJ\aJ h0
¾CJ aJ h0
¾h0
¾CJ aJ h0
¾5CJ \aJ h0
¾h0
¾5CJ \aJ h0
¾5B*CJ \aJ phÿ&àâäTX´ÈÊúü


,-.CEPQRUw{š›º»Ûé2IJ|}ÄÅ.0õêâêÚÌõÁ²¦ÌõÁâÌÁž“‹“‹ž‹ÌõÌõÌõÌÁ̄zsoÁâÁâÁ²Áh0
¾

h0
¾h0
¾h0
¾h0
¾5\

h½GU5\ h½GUCJaJ h0
¾h0
¾CJaJ h0
¾CJaJh½GUB*CJ aJ phÿh½GUh½GUB*CJ aJ phÿ h½GUh½GUCJ aJ h½GUh½GU5CJ \aJ h0
¾CJ aJ h½GUCJ aJ h0
¾h0
¾CJ aJ h½GU5CJ \aJ +
-/Rx›»é3JpŸ0x¦äòééààÓÓÓʽ°££–°££

„ˆ„Ä^„ˆ`„Ägd½GU

„ˆ„Ü^„ˆ`„Ügd½GU

„Ä„Ü^„Ä`„Ügd½GU

„Ä„

^„Ä`„

gd½GU„Ä^„Ägd0
¾

„L„Ä^„L`„Ägd½GU„Ä^„Ägd½GU„L^„Lgd½GU

„œ

„tþ^„œ

`„tþgd½GUä*-d-¸-ü-f !ª!X"2#”#–#Þ# $<$˜$È$òåàÓÆÆ¹¬Ÿ¬––„ˆ^„ˆgdT°„Ä^„Ägd0
¾

„ „Œþ^„ `„Œþgd½GU

„Ä„Ä^„Ä`„ÄgdT°

„Ä„Ä^„Ä`„ÄgdQ

„Ä„Ä^„Ä`„Ägd½GU

„Ä„Ä^„Ä`„Ägd½GUgd½GU

„ˆ„Ü^„ˆ`„Ügd½GU

„ˆ„Ü^„ˆ`„Ügd½GU0`-d-h-¸-È-Þ-ü-< d f ° ¾ Þ !!!H!`!d!r!¦!¨!ª!Ì!ä!ùõñêÜÎÜêûܰ¥°ÜšÜˆye°SDÜÎh½GU5B*CJ\aJphÿ#h½GUh½GU5B*CJ\aJphÿ'hQ hQ 0J5CJOJQJ^JaJhQ 5B*CJ\aJphÿ#h½GUhQ 5B*CJ\aJphÿ h½GU5CJ\aJ h½GUhQ CJaJ h½GUh½GUCJaJh½GUB*phÿh½GUh½GUB*phÿh½GUhQ 5CJ\aJh½GUh½GU5CJ\aJ

h½GUh½GUh½GUh0
¾

h0
¾h0
¾ä!ö!ø!"

"T"V"X"Z"ª"2#j#l#€#’#”#–#œ#¼#Ì#Î#Ü#Þ#$:$V$X$j$‚$”$–$Æ$È$Ì$õíâí×ÏÁ¶¨¶šõšˆ×wmwfw_×â×Ï×ÏíÏ×ÏW hT°CJ aJ

h0
¾h0
¾

hT°5\h0
¾hQ 5\h0
¾h0
¾5\

h0
¾5\#hT°hT°5B*CJ\aJphÿhT°hT°5CJ\aJh½GUh½GU5CJ\aJ h½GU5CJ\aJhT°h½GU5CJ\aJ hT°CJaJ hT°hT°CJaJ hT°hQ CJaJ hQ CJaJ hQ 5CJ\aJ!Ì$Þ$ð$ò$ô$%%2%4%`%d%~%€%%”%¼%Î%â%w&x&ˆ&¸&¹&º&¼&Ç&È&á&â&ç&è&é&ô&õ&

'(*(õêâÚõÚõÚõÚõÚõÚõêõÏȾ·³¬¨¤™‹€‹™¤y¤nfn hQ CJaJ h©XÛh©XÛCJaJ

h©XÛh©XÛ hæ:5CJ\aJhæ:hæ:5CJ\aJ hæ:hæ:CJaJhæ:ht

hth0
¾h0
¾

h0
¾h0
¾h0
¾h0
¾5\

hT°5\ hT°hT°CJaJ hT°CJ aJ hQ CJ aJ hT°hQ CJ aJ hT°hT°CJ aJ $È$%`%%º%â%&6&E&h&w&x&‰&¸&º&»&¼&½&¾&¿&À&Á&Â&ööööíàíííí××ÎÉÄÄÄÄÄÄÄÄgdtgd0
¾„ˆ^„ˆgd0
¾„Ä`„ÄgdT°

„Ä„Ä^„Ä`„ÄgdT°„ˆ^„ˆgdT°„L^„LgdT°Â&Ã&Ä&Å&Æ&Ç&È&â&è&é&õ&*(è(œ)F*j*€*¦*¾*ã* +S+úúúúúõííúúàÓÓÆàààààà¹

„Є˜þ^„Ð`„˜þgd©XÛ

„,„˜þ^„,`„˜þgd©XÛ

„,„˜þ^„,`„˜þgd©XÛ

„Є˜þ^„Ð`„˜þgd©XÛ $a$gdæ:gdæ:gdt*(6(:(>(š(œ(è(ð(œ)¤) +
+/+7++€+™+¡+¢+«+²+¼+Æ+ì+í+&,(,p,r,Ò,Ô,æ,-X-Z-¬-®-À-Ú-„.ˆ.Š.Ä.Æ.Þ.0/h/l/‚/Î/0ZZ Z:ZxZzZ|ZŒZŽZòäÙÎÆÎòÎòλÎòγ¯Î§Î»Î»Î§Î§Î§Î§Î»Î§Î§Î»ÎŸ¯˜ÎòΟÎòΟ–ŸÎòΟ¯Î˜U

h©XÛh©XÛ h©XÛCJaJ hàuCJaJh©XÛj@< h©XÛU h©XÛhàuCJaJ hQ CJaJ h©XÛh©XÛCJaJ h©XÛhQ CJaJh©XÛhQ 5CJ\aJh©XÛh©XÛ5CJ\aJ;S+++‚+ƒ+„+…+†+‡+ˆ+‰+Š+‹+Œ++™+«+¼+Ô+ö+:,„,æ,-l-òííííííííííííííäääÛÛÛÒäۄ„^„„gd©Xۄ„^„„gd©XۄÄ^„Ägd©XÛgd©XÛ

„Є˜þ^„Ð`„˜þgd©XÛl-À-ø-†.ˆ.Š.Ä.2/h/j/Ð/ZZzZ®Z [¨[¼[Â[Ä[Æ[È[Ê[öíääßÚßßßßßßßßÍÚÚÄÄÚÚڄÄ`„Ägd©XÛ

„ˆ„Ä^„ˆ`„Ägd©XÛgd©XÛgd©Xۄ„^„„gd©XۄÄ^„Ägd©Xۄ„^„„gd©XÛeirása}

 kulcsszavas értékek(tagged values): modell elemek
Formája: { persistent }
{author="Ficsor", version=0.9.9, date=00.01.01}
 megjegyzések meg nem adható tulajdonságok speciális jellemzQinek megadására
Formája:





















Use-case diagram:
Aktor és use case között: asszociáció (jelölhetQ a számossága is)
Use case-ekközött:
<>: A1 use case magában foglalja A2-Qt (részletezés, vagy ismétlQdés kezelése)
<>: A1use case mqködését A2 kiegészíti (többlet funkciók vagy speciális esetek)
Aktorok vagy use case-ek között: általánosítás (generalization)
Pl.: webes jelentkezQ(speciális jelentkezQ) és sima jelentkezQ





FIGYELNI!!
Speckos folyamatra rá írni <>
Speckos Actorokat össze fqzni egybe ( ez az általánosítás általában speciális Aktoroknál)
Ha vmi nem megy más nélkül mindenképpen <>ot rá írni
Az ellipszisbe kell írni vagy alá a megnevezését





















Osztály diagram:
Három szint:
Koncepcionális

Specifikációs

implementációs

Láthatóság jelölése:
+ public
# protected
- private

Változók:
láthatóság név : típus = alapérték
pl.: + nev : string = Józsi

Operációk (függvények):
láthatóság név(param) : típus{comment}
pl.: #nevvalt(ujnev : string = noname ) : string {a bejövQ adattal visszaküldjük a változó nevet,ha nem küldünk semmit akkor noname lesz a neve}

Kapcsolat az egyes osztályok között:
Asszociáció (általános kapcsolat)
Nevesített kapcsolatok:
 általánosítás (Speciális (közvetett) viszony két osztály között)
 tartalmazás (aggregáció és kompozíció)
 beágyazott (osztály hatáskörben definiált) osztály - elsQsorban az implementációs szintq diagrammokon

Kétféle egész - rész viszony:
aggregáció: a rész az egészhez tartozik, de önállóan is létezQ entitás

kompozíció: a rész önmagában nem létezhet, csak valaminek a részeként.



Interface:
Az <> sztereotípiával, vagy egy körrel jelöljük
Interface-ek közötti lehetséges asszociáció: általánosítás

Interface és osztály közötti lehetséges asszociáció: implementálás, realizálás.





FIGYELNI!!!!
Nem mindegy hogy végzQdik a nyíl
Nem mindegy hogy a nyíl elején vagy a végén van a számozás
Ha a nyíl valamilyen cselekvést jelöl rá kell írni
Minden téglalap 3 sávból áll kivétel interface az csak kettQbQl (abba nincs változó)


Szekvencia diagram:
Objektumok közötti üzenetváltások az idQben
Elemei:
Példaobjektumok, életvonallal, aktivitási szakasszal (vezérlési fókusszal)
Üzenetek (név, argumentum, feltétel, ismétlQdés)
Megjegyzések az ábrától balra
Üzenet fajták:
Egyszerq üzenet, Szinkron üzenet, Aszinkron üzenet, Time-out üzenet






Figyelni!!!
Minden egyes függvényhez tartozik egy téglalap
A függvény elejétQl jön egy sima nyíl(input) és kifelé szaggatott (output)
Feltétel (if) mindig szögletes zárójelbe rakjuk
A szereplQk neveit mindig keretezzük aláhúzzuk
A szereplQk neveibQl jön egy szaggatott vonal függQlegesen, de a télalapban ezt nem szabad jelölni
A nyíl mindig V alakban végzQdjön mert amúgy le vonás jár érte

Állapot diagram:
Egy adott objektum
lehetséges állapotai
átmenetek az egyes állapotok között
 ehhez kapcsolható események
 az objektum értékeihez kapcsolható feltételek [feltétel]
 az ismétlQdés jelzése (*)
kezdQ és végállapot
egy állapot részletezhetQ (strukturált áll. diagram)
állapotok között lehet általánosítás kapcsolat





Figyelni!!!
Start mindig teli fekete kör
Kerekített sarkok
Mindig V alakú nyíl
Minden nyílra legyen írva vmi
Kilépés kör benne egy fekete ponttal


Aktivitás diagram:
IdQben lezajló változások ábrázolása a megadásával végrehajtandó tevékenységek és azok sorrendjének
Alapjai:
 munkafolyamat (work-flow) diagram
 folyamatábra (flow chart)
Alapelemei:
 tevékenységek (ívelt oldalú téglalap)
 átmenet (nyíl)
 szinkronizációs vonal (vastag vízszintes vonaldarab)
 döntési pont (rombusz)




FIGYELNI!!!
Kezdés mindig nagy fekete pontból
A párhuzamos dolgok két meg vastagított vonal között vannak
Mindig V alakú nyíl
Egy elágazásból min 2 nyíl jöjjön
Végén mindig kör benne fekete pont































Sávos aktivitás:
U.a. mint az aktivitás csak függQlegesen sávokra osztható.
Egy sáv egy felelQsségi kört (felhasználó, szervezeti egység stb.) jelöl


Hasonló témájú dokumentumok
- 2009-12-08 16:45:07
- 2008-05-22 18:14:07
- 2010-09-06 14:17:00
- 2008-02-21 17:40:30
- 2009-11-01 17:28:12
- 2011-12-14 19:00:23
A mások által feltöltött dokumentumokat értékelheted. Ha úgy ítéled meg, hogy a vizsgára való felkészülés szempontjából hasznos volt egy dokumentum, akkor adj rá sokcsillagos értékelést.
Ha hibákat tartalmaz, vagy egyéb probléma van vele, akkor keveset.
A dokumentumok sorrendje az értékelések alapján adódik. Ami fentebb van a listában, azt hasznosabbnak ítélték társaid. Az új dokumentumok pedig (értékelések hiányában) szintén a lista tetején kezdenek.

Hozzászólások

Ha észrevételed van egy dokumentummal kapcsolatban (például hibát találtál benne), akkor a Hozzászólások részben jelezheted. Az olyan jellegű kérdéseket mint pl.: A 2. feladat 4. sorából milyen átalakítással jutottunk az 5. sorban szereplő képlethez? - szintén ide érdemes írni
Egy tipp az oldalhoz! - Naptári bejegyzéseket vehettek fel egy tantárggyal kapcsolatban, vagy az egész szakotok számára. Például:
  • Zh időpontok
  • Gólyabál időpontja
  • Házi leadási határidő
  • Tanítási szünetek
  • stb ...
Kattints a Naptárra, majd a jobb felső részen levő Új naptári bejegyzés felvétele linkre.

Cimkefelhő

03.04/1 4.óra államháztartás alternatív energiaforrások áltkém beszámoló bibó biztosítás bogarak csavar csehov csokonai descartes előadás ember építésszervezés i. eu logisztika excel falusi turizmus fizikai+kémia forgó mozgás földrajz gazdaság glikoneogenezis gyep jogi alapismeretek jogképesség keringés kidolgozott kérdések kötelmi jog középkor leppelés litoszféra madarak magyar premodern móricz pdf politikatudomány ptk szabályzás számítógép architektúrák számtek szervezeti magatartás szociolingvisztika szöveg topográfia üzleti terv virológia vizsgakérdés vizsgasor