Szoftver technikák vizsga, 2005. 12. 21.

A VIK Wikiből

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.


<style> ol { margin-top: 0px; } </style>

1. feladat

DLL-ek definíciója, előnyei? Mi a különbség a statikus és dinamikus linkelés között?

  • DLL*: Dynamic-link library. Kódot, adatokat, erőforrásokat tartalmazó, exe-vel azonos szerkezetű file.

Előnyei:

  • lehetővé teszi moduláris szoftver készítését: az egyes funkciók külön fejleszthetők és tesztelhetők
  • a file újrafelhasználható más szoftverekben => winchester spórolás
  • elég csak az éppen szükséges modulokat betölteni => memória spórolás
  • nyelvfüggetlen

Hátrányai (összefoglaló néven: függőségi probléma vagy „dll hell”)

  • Az interfész nem változtatható
  • Nincs szabványos verziókezelés
  • A dll-eknek nincs szabványos helye a file rendszerben.
  • Statikus linkelés (lib)*: A könyvtár a program indításakor betöltődik (leképződik a processz címtartományára). Gyorsabb.
  • Dinamikus linkelés (dll)*: Rugalmasabb, de nagyobb az overheadje. Két fajtája van
  1. Implicit: a könyvtár stubját (egy .lib-et) hozzálinkeljük a programhoz, a dll-t a Windows tölti be a program indításakor.
  2. Explicit: futás közben, =LoadLibrary= hívással töltjük be a dll-t, és 
    GetProcAddress
    -szel kérdezzük le a használt függvények címét. A kód =FreeLibrary= hívással törölhető ki a memóriából.

2. feladat

WinAPI-ban jelenítsünk meg egy négyzetet. Menüpont hatására jöjjön elő egy modális dialógusablak, amiben be lehet állítani a négyzet oldalát. Első indításkor az Edit mező 70-es értéket tartalmazzon. A kurzor billentyűk lenyomására a négyzet mozduljon el 1 pixellel a megfelelő irányba.

A teljes kód letölthető innen. 

struct Square {
	 int x, y, size;
} square;

LRESULT CALLBACK DlgProc(HWND hwnd, UINT iMsg,
	 WPARAM wParam, LPARAM lParam)
{
	 char size[11];

	 switch(iMsg) {
		  case WM_INITDIALOG:
				sprintf(size, "%d", square.size);
				SetDlgItemTextA(hwnd, TEXTBOX_SIZE, size);
				return TRUE;

		  case WM_COMMAND:
				if (wParam==IDOK) {
					 GetDlgItemTextA(hwnd, TEXTBOX_SIZE, size, 10);
					 square.size = atoi(size);
					 EndDialog(hwnd, 0);
					 return TRUE;
				}
				break;
	 }

	 return FALSE;
}

LRESULT CALLBACK WndProc(HWND hwnd, UINT iMsg,
	 WPARAM wParam, LPARAM lParam)
{
	 HDC hdc;
	 PAINTSTRUCT ps;
	 RECT rect;
	 HBRUSH redBrush;
	 HPEN redPen;
	 int moved;

	 switch(iMsg) {
		  case WM_CREATE:
				square.x = 0;
				square.y = 0;
				square.size = 70;
				return 0;

		  case WM_COMMAND:
				if (wParam==MENUITEM_SETTINGS) {
					 DialogBox(hInst, MAKEINTRESOURCE(DIALOG_SETTINGS), hwnd, DlgProc);
					 InvalidateRect(hwnd, NULL, 1);
				}
				return 0;

		  case WM_KEYDOWN:
				moved = 1;
				switch (wParam) {
					 case VK_LEFT: square.x--; break;
					 case VK_RIGHT: square.x++; break;
					 case VK_UP: square.y--; break;
					 case VK_DOWN: square.y++; break;
					 default: moved = 0;
				}
				if (moved) InvalidateRect(hwnd, NULL, 1);
				return 0;

		  case WM_PAINT:
				hdc = BeginPaint(hwnd, &ps);
				redBrush = CreateSolidBrush(RGB(255, 0, 0));

				/*
				rect.left = square.x;
				rect.top = square.y;
				rect.right = square.x + square.size;
				rect.bottom = square.y + square.size;
				FillRect(hdc, &rect, redBrush);
				*/

				// vagy

				redPen = CreatePen(PS_SOLID, 1, RGB(255, 0, 0));
				SelectObject(hdc, redBrush);
				SelectObject(hdc, redPen);
				Rectangle(hdc, square.x, square.y, square.x + square.size, square.y + square.size);
				DeleteObject(redBrush);
				DeleteObject(redPen);

				EndPaint(hwnd, &ps);
				return 0;

		  case WM_DESTROY:
				PostQuitMessage(0);
				return 0;

		  default:
				return DefWindowProc(hwnd, iMsg, wParam, lParam);
	 }
}

3. feladat

MFC-ben milyen osztályokkal valósítják meg az MDI-os document-view architektúrát, ezek hogy érik el egymást? 

GetActiveView() +-----------+ <-----------------\
		/-------> |	CView	|						 | GetFirstViewPosition()
		|			+-----------+ ---------------\  | GetNextView()
		|								GetDocument() |  | UpdateAllViews()
		|												  |  |
		|												  V  |
+-----------+	GetActiveDocument()	+-----------+
| CFrameWnd | ----------------------> | CDocument |
+-----------+								 +-----------+

Az UpdateAllViews() minden view-ra meghívja az =OnUpdate= eseménykezelőt, amiben paraméterként átad egy referenciát a módosítást végző view-ra. Az MDI működését az Observer tervezési minta írja le. 

			  +------------+		  +---------+		  +---------+
			  | MyDocument |		  |  View1  |		  |  View2  |
			  +------------+		  +---------+		  +---------+
					  |						  |						|
					  |						  |	 user			 |
					  |		SetData()	  ■ <--------		  |
				x=2  ■ <----------------- ■						|
			  /---- ■						  |						|
			  \---> ■						  |						|
					  ■						  |						|
UpdateAllViews() ■						  |						|
  /------------- ■						  |						|
  \------------> ■	  OnUpdate()	  |						|
					  ■ -----------------> ■						|
					  ■		 GetData()	 ■						|
					  ■ ■ <--------------- ■						|
					  ■ ■						■						|
					  ■					OnUpdate()				  |
					  ■ ------------------------------------> ■
					  |					 GetData()				  ■
					  | ■ <---------------------------------- ■
					  | ■						|						■
					  |						  |						|

4. feladat

Milyen életciklus modellt választanál egy 2-3 hónapos projekthez, amit már csinált a csapat?
Mit jelent a Unified Process? Fázisai?
Mit jelent az iteratív fejlesztés? Magyarázd el az UP példáján.
Mik az egyes fázisok végtermékei?

5. feladat

Composite tervezési minta mire jó, mikor használják, class diagram, osztályok szerepe?

6. feladat

Hogyan néz ki egy use case diagram? Mik az elemei?

A use case diagram egy projekt üzleti modelljét írja le. Legegyszerűbb esetben egy páros gráf az aktorok és a rendszer funkciói között. Bonyolultabb esetben a funkciók szétbonthatók hierarchikusan kisebb funkciókra.

A funkciók működése forgatókönyvekkel írható le. A főforgatókönyv a hibamentes esetben végrehajtandó lépéseket sorolja fel. A kiegészítő forgatókönyv definiálja, hogy a főforgatókönyvben melyik lépésben milyen hibák léphetnek fel, és megmondja, hogy mi a teendő a bekövetkezésük esetén.

7. feladat

KDE-ben készítsünk egy view-t, ami lekérdezi a dokumentumtól egy téglalap adatait, és kettős puffereléssel megjeleníti.

Megoldás

8. feladat

Tesztelés típusai + magyarázat

  • Formális teszt: párhuzamosan fut a szoftver tervezése és tesztelése
    • (+) ismert a forgatókönyv
    • (+) ismert az elfogadási kritérium
    • (+) automatizálható
    • (-) sok tervezési igényel
    • (-) nem térhetünk ki mindenre (időbeli és pénzbeli korlátok miatt)
  • Informális teszt
    • (+) olcsó
    • (+) random módon történik
    • (-) alap forgatókönyvek kieshetnek
    • (-) szoftver tervvel nincs összhangban a tesztelési terv
  • Béta teszt
    • (+) sok felhasználó csinálja
    • (+) ingyen van
    • (-) known bugs az azonnali javítás helyett
  • FAT (Factory Acceptance Test)

Átadás előtti teszt a vevő bevonásával, valós környezetben.

-- Peti - 2007.06.13.

A lap eredeti címe: „https://vik.wiki/index.php?title=Szoftver_technikák_vizsga,_2005._12._21.&oldid=139774”