Состав и функционирование ИС построенной по принципу клиент сервер для численного обоснования решений
Обработчик сообщений
Приложения
int
OpenProject (void); (Project.h à Project.cpp)
int
OpenProject (void)
{
OPENFILENAME
ofn;
char
OpenName [122];
char
szFile[256],
sz1[129],
szFileTitle[256];
char *szFilter = new char[256];
LoadString (hinstResource, STR56,
szFilter, 256);
szFile[0] = '\0';
memset (&ofn, 0,
sizeof(OPENFILENAME));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.hwndOwner = hWnd;
ofn.lpstrFilter = szFilter;
ofn.nFilterIndex = 1;
ofn.lpstrFile = szFile;
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFileTitle = szFileTitle;
ofn.nMaxFileTitle = sizeof(szFileTitle);
ofn.Flags = OFN_FILEMUSTEXIST;
ofn.lpstrTitle = new char[50];
LoadString (hinstResource,
STR1,(char*)ofn.lpstrTitle, 50);
ofn.lpstrDefExt = "pjt";
if (!bOpenAfterDir)
{
if (!GetOpenFileName(&ofn))
return CE_NOPROJECT;
UpdateWindow (hToolBarWnd);
UpdateWindow (hWnd);
strcpy (szCurrentProject,
strlwr(strcat (Mystrtok(szFile +
ofn.nFileOffset, "."), ".pjt")));
strcpy (szProjectDirectory,szFile);
szProjectDirectory[ofn.nFileOffset] =
'\0';
ProjectFlags = new ProjectFlagStruct;
CurrentProject = new ProjectStatusStruct;
NewCurrentProject = new PJTStruct;
strcpy(OpenName,strlwr(szFile));
}
else
{
ProjectFlags = new ProjectFlagStruct;
CurrentProject = new ProjectStatusStruct;
NewCurrentProject = new PJTStruct;
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
strcpy(OpenName,sz1);
}
delete szFilter;
delete (char *)ofn.lpstrTitle;
int rc;
if ((rc = OpenProjectFunct (OpenName)) ==
CE_NOPROJECT)
{
delete CurrentProject;
delete ProjectFlags;
delete NewCurrentProject;
return rc;
}
if (rc & CE_NODATABASE)
return rc;
DestroyMenu (hmenuMain);
hmenuMain = LoadMenu (hinstResource,
"MAINMENU");
hmenuProject = GetSubMenu (hmenuMain, 0);
hmenuAdjust = GetSubMenu (hmenuMain, 1);
hmenuDatabase = GetSubMenu (hmenuMain, 2);
hmenuStudy = GetSubMenu (hmenuMain, 3);
hmenuEvaluate = GetSubMenu (hmenuMain, 4);
hmenuOptions = GetSubMenu (hmenuMain, 5);
hmenuWindow = GetSubMenu(hmenuMain, 6);
SetMenu (hMainWnd, hmenuMain);
DrawMenuBar (hMainWnd);
SendMessage (hMDIClient, WM_MDISETMENU,
FALSE,
MAKELPARAM (hmenuMain,
GetSubMenu (hmenuMain, WINDOWMENU)));
BYTE flg = NewCurrentProject->Flags;
flg &= 3;
if ((flg < FL_PHASE2) ||
strcmp(CurrentProject->ProjectTask, "Classification"))
{
EnableMenuItem (hmenuOptions, ID_O_PHASE2,
MF_GRAYED);
}
if ((flg < FL_TOUGHT) ||
strcmp(CurrentProject->ProjectTask, "Classification"))
{
EnableMenuItem (hmenuStudy, ID_S_PHASE2,
MF_GRAYED);
EnableMenuItem (hmenuStudy, ID_S_ANALYZE,
MF_GRAYED);
}
if (flg < FL_TOUGHT)
if (flg < FL_BUILT)
EnableMenuItem (hmenuStudy, 0,
MF_BYPOSITION | MF_GRAYED); // Standards popup
if (!strcmp (CurrentProject->ProjectTask,
"Classification"))
EnableMenuItem (hmenuAdjust, ID_P_MODIFYCLS,
MF_ENABLED);
else
EnableMenuItem (hmenuAdjust, ID_P_MODIFYCLS,
MF_GRAYED);
if(!strcmp(CurrentProject->ProjectTask,
"Classification")) {
extern BOOL isPhase2;
extern int Ph2Ranges;
isPhase2 = FALSE;
Ph2Ranges = 10;
}
else {
extern BOOL isPhase2;
isPhase2 = FALSE;
}
ProjectFlags->NeedToDouble = FALSE;
return rc;
}
BOOL
CreateProject (void); (Project.h à Project.cpp)
BOOL
CreateProject (void)
{
BOOL nRC;
char *sztmp = new char [128];
char sz1 [121];
char sz2 [121];
ProjectFlags = new ProjectFlagStruct;
CurrentProject = new ProjectStatusStruct;
NewCurrentProject = new PJTStruct;
if (!GetProjectName ())
{
delete ProjectFlags;
delete CurrentProject;
delete NewCurrentProject;
return FALSE;
}
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
DelPrj (sz1);
if (RusResourse)
HelpStack->PushInt (ID_W_CREATE);
else
HelpStack->PushInt (ID_ENGLISHHELP);
FARPROC lpProjectDialog =
MakeProcInstance((int (PASCAL
*)()) ProjectDlgProc,hInst);
nRC = DialogBox(hinstResource, (LPSTR)
"CREATE_PROJECT", hWnd, lpProjectDialog);
FreeProcInstance (lpProjectDialog);
HelpStack->PopInt ();
if (!nRC)
{
delete ProjectFlags;
delete CurrentProject;
delete NewCurrentProject;
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
DelPrj (sz1);
return FALSE;
}
if (!OpenProjectDatabase())
{
delete ProjectFlags;
delete CurrentProject;
delete NewCurrentProject;
PXPswDel (szPsw);
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
DelPrj (sz1);
return FALSE;
}
ProjectFlags->TableIsValid = TRUE;
NumOfClasses = 1;
if (!strcmp(CurrentProject->ProjectTask,
"Classification"))
if (!CreateProjectClasses ())
{
NumOfClasses = 1;
clClasses->Clear ();
delete ProjectFlags;
delete CurrentProject;
delete NewCurrentProject;
delete Table;
delete Records;
PXPswDel (szPsw);
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
DelPrj (sz1);
return FALSE;
}
Standards = new ClassList;
strcpy (sz1, szProjectDirectory);
strcpy (sz2, szDBDirectory);
strcpy (sztmp, szCurrentProject);
strcpy (CurrentProject->ReqName,
strcat(Mystrtok (sztmp, "."), ".tpt"));
strcpy (CurrentProject->StdName,
strcat(Mystrtok (sztmp, "."), ".std"));
ProjectFlags->TemplateIsValid =
CreateDemandTemplate ();
if (ProjectFlags->TemplateIsValid)
strcpy (CurrentProject->ProjectState,
"Built");
Old2New (NewCurrentProject, CurrentProject);
Results = new TSTCList ("", FALSE,
Classes, NumOfClasses, Records);
AdjustResults (Results);
Standards->Init(strcat(sz1,szCurrentProject));
if (Demands->GetCount () !=0)
if (!strcmp
(CurrentProject->ProjectState, "Built"))
EditStandards();
DestroyMenu (hmenuMain);
hmenuMain = LoadMenu (hinstResource,
"MAINMENU");
hmenuProject = GetSubMenu (hmenuMain, 0);
hmenuAdjust = GetSubMenu (hmenuMain, 1);
hmenuDatabase = GetSubMenu (hmenuMain, 2);
hmenuStudy = GetSubMenu (hmenuMain, 3);
hmenuEvaluate = GetSubMenu (hmenuMain, 4);
hmenuOptions = GetSubMenu (hmenuMain, 5);
hmenuWindow = GetSubMenu(hmenuMain, 6);
SetMenu (hWnd, hmenuMain);
DrawMenuBar (hWnd);
SendMessage (hMDIClient, WM_MDISETMENU,
FALSE,
MAKELPARAM (hmenuMain,
GetSubMenu (hmenuMain, WINDOWMENU)));
if (!strcmp (CurrentProject->ProjectTask,
"Classification"))
EnableMenuItem (hmenuAdjust, ID_P_MODIFYCLS,
MF_ENABLED);
else
EnableMenuItem (hmenuAdjust, ID_P_MODIFYCLS,
MF_GRAYED);
//
**********************************************************
if(!strcmp(CurrentProject->ProjectTask,
"Classification")) {
EnableMenuItem (hmenuOptions,
ID_O_PHASE2, MF_ENABLED);
EnableMenuItem (hmenuStudy,
ID_S_PHASE2, MF_ENABLED);
EnableMenuItem (hmenuStudy,
ID_S_ANALYZE, MF_ENABLED);
extern BOOL isPhase2;
extern int Ph2Ranges;
isPhase2 = FALSE;
Ph2Ranges = 10;
}
else {
extern BOOL isPhase2;
isPhase2 = FALSE;
EnableMenuItem (hmenuOptions,
ID_O_PHASE2, MF_GRAYED);
EnableMenuItem (hmenuStudy,
ID_S_PHASE2, MF_GRAYED);
EnableMenuItem (hmenuStudy,
ID_S_ANALYZE, MF_GRAYED);
}
//
**********************************************************
ProjectFlags->NeedToDouble = FALSE;
pColumns[0] = pColumns[1] = pColumns[2] =
NULL;
nColumns[0] = nColumns[1] = nColumns[2] = 0;
SaveProject (szCurrentProject);
BYTE flg = NewCurrentProject->Flags;
flg &= 3;
EnableMenuItem (hmenuOptions, ID_O_PHASE2,
MF_GRAYED);
EnableMenuItem (hmenuStudy, ID_S_PHASE2,
MF_GRAYED);
EnableMenuItem (hmenuStudy, ID_S_ANALYZE,
MF_GRAYED);
EnableMenuItem (hmenuAdjust,
ID_P_MODIFYCLS, MF_GRAYED);
EnableMenuItem (hmenuEvaluate, 0, MF_GRAYED
| MF_BYPOSITION);
EnableMenuItem (hmenuEvaluate, 1, MF_GRAYED
| MF_BYPOSITION);
EnableMenuItem (hmenuStudy, 0,
MF_BYPOSITION | MF_GRAYED);
if (flg > FL_BUILDING)
EnableMenuItem (hmenuStudy, 0,
MF_BYPOSITION | MF_ENABLED);
if (flg > FL_BUILT)
EnableMenuItem (hmenuEvaluate, 0,
if ((flg > FL_BUILT) && !strcmp
(CurrentProject->ProjectTask, "Classification"))
{
EnableMenuItem (hmenuStudy, ID_S_ANALYZE,
MF_ENABLED);
EnableMenuItem (hmenuStudy, ID_S_PHASE2,
MF_ENABLED);
}
return TRUE;
}
void
CloseProjectChoice (void); (Project.h à Project.cpp)
void
CloseProjectChoice (void)
{
if (!CloseProject (szCurrentProject)) return;
delete ProjectFlags;
}
void
SaveProject (char *) (Project.h à Project.cpp)
BOOL
SaveProject (char *ProjectName)
{
char sztmp[121];
char sz1[121];
char sz2[121];
char szRCSTR [100];
LoadString (hinstResource,
STR44,szRCSTR, sizeof (szRCSTR));
SendMessage (hIndicationBarWnd,
WM_STARTPROCESS, 0, (LPARAM)(LPSTR) szRCSTR);
strcpy (sz1, szProjectDirectory);
strcpy (sz2, szDBDirectory);
strcpy (sztmp, ProjectName);
Mystrtok (sztmp, ".");
BOOL bflag = TRUE;
Records->GetSTC ();
Table->GetSTC ();
Demands->Get();
if (!SaveSTCFile (strcat(sz2, strcat
(Mystrtok(CurrentProject->ObjectsName, "."),
".stc")))) bflag = FALSE;
SendMessage (hIndicationBarWnd, WM_PROCESS,
51, 0L);
if (strcmp (CurrentProject->ProjectState,
"Building"))
if (!SaveTPTFile (strcat (sz1,
strcat (Mystrtok
(CurrentProject->ReqName, "."),
".tpt")))) bflag = FALSE;
SendMessage (hIndicationBarWnd, WM_PROCESS,
81, 0L);
strcpy (sz1, szProjectDirectory);
if (!SavePJTFile (strcat (sz1,
strcat
(Mystrtok(ProjectName, "."),
".pjt")))) bflag =
FALSE;
SendMessage
(hIndicationBarWnd, WM_PROCESS, 100, 0L);
ProjectFlags->TemplateModified =
ProjectFlags->TableModified = FALSE;
Records->ReleaseSTC ();
Table->ReleaseSTC ();
Demands->Release();
SendMessage
(hIndicationBarWnd, WM_ENDPROCESS, 0, 0L);
return bflag;
}
void DeleteProject
(void) (Project.h à Project.cpp)
void
DeleteProject (void)
szFile[ofn.nFileOffset] = '\0';
void
ModifyDB (void) (Project.h à Project.cpp)
void
ModifyDB (void)
{
int nRC;
int nLock;
nLock = Table->Lock;
Table->Destroy ();
if (!Table->GetSTC ())
return;
Table->Lock += nLock;
OrgRegNumber = Table->GetRegFields ();
OrgFieldNumber = Table->GetCount ();
Standards->Get ();
if (RusResourse)
HelpStack->PushInt (ID_W_FEATURES);
else
HelpStack->PushInt (ID_ENGLISHHELP);
FARPROC lpCreateStcProc =
MakeProcInstance((int (PASCAL *)()) CreateStcDlgProc,hInst);
nRC = DialogBox(hinstResource, (LPSTR)
"CREATESTC", hWnd, lpCreateStcProc);
FreeProcInstance (lpCreateStcProc);
HelpStack->PopInt ();
if ((!nRC) ||
(!ProjectFlags->NeedToDouble))
{
nLock = Table->Lock;
Table->Destroy ();
Table->GetSTC ();
Table->Lock += nLock;
Table->ReleaseSTC();
return;
}
ProjectFlags->TableModified = TRUE;
if (ProjectFlags->NeedToDouble)
{
DoubleDB ();
Table->Renumber ();
Table->SaveSTC ();
nLock = Table->Lock;
Table->Destroy ();
Table->GetSTC ();
Table->Lock += nLock;
Table->ReleaseSTC ();
}
}
void
ModifyDemands (void) (Project.h à Project.cpp)
void
ModifyDemands (void)
{
int nRC;
if (ProjectFlags->TemplateModified)
if (!SaveTPTFile
(CurrentProject->ReqName))
return ;
ProjectFlags->TemplateModified = FALSE;
if (!Demands->Get ())
{
Demands->Create ();
}
if (RusResourse)
HelpStack->PushInt (ID_W_DEMANDS);
else
HelpStack->PushInt (ID_ENGLISHHELP);
FARPROC lpCreateTptProc =
MakeProcInstance((int (PASCAL *)()) CreateTptDlgProc,hInst);
nRC = DialogBox(hinstResource, (LPSTR)
"CREATETPT", hWnd, (DLGPROC) lpCreateTptProc);
FreeProcInstance (lpCreateTptProc);
HelpStack->PopInt ();
#if defined
(DEMO_RECORD) || defined (DEMO_PLAY)
Demands->Destroy ();
Old2New (NewCurrentProject, CurrentProject);
return;
#endif
if (nRC)
{
if (Demands->GetCount() == 0)
{
Demands->Save ();
return;
}
if (!Demands->Save ())
return;
if (!strcmp
(CurrentProject->ProjectState, "Building"))
strcpy (CurrentProject->ProjectState,
"Built");
EnableMenuItem (hmenuStudy, 0,
MF_BYPOSITION | MF_ENABLED);
SendMessage (hIndicationBarWnd,
WM_PROJECTCHANGESTATE, FL_BUILT, 0l);
}
else
Demands->Destroy ();
Old2New
(NewCurrentProject, CurrentProject);
}
void
ModifyClasses (void) (Project.h à Project.cpp)
void
ModifyClasses (void)
{
int nRC;
BOOL
bOpened;
clClasses->Get (Classes, NumOfClasses);
Standards->Get ();
Demands->Get ();
if (RusResourse)
HelpStack->PushInt (ID_W_CLASSES);
else
HelpStack->PushInt (ID_ENGLISHHELP);
FARPROC lpCreateClassesProc =
MakeProcInstance((int (PASCAL *)()) ClassesDlgProc,hInst);
nRC = DialogBox(hinstResource, (LPSTR)
"CLASSLIST_DIALOG", hWnd, lpCreateClassesProc);
FreeProcInstance (lpCreateClassesProc);
HelpStack->PopInt ();
#if defined
(DEMO_PLAY) || defined (DEMO_RECORD)
clClasses->Release ();
Standards->Release ();
return;
#endif
if (!nRC)
{
clClasses->Release ();
Standards->Release ();
return;
}
Standards->UpdateClasses (clClasses);
Demands->UpdateClasses (clClasses);
clClasses->Save (Classes, NumOfClasses);
Table->GetSTC ();
Results->GetSTC ();
OrgFieldNumber = Results->GetCount();
OrgRegNumber = Results->GetRegFields ();
Results->ReleaseSTC ();
char szRCSTR [100];
LoadString (hinstResource, STR51,
szRCSTR, sizeof (szRCSTR));
SendMessage (hIndicationBarWnd,
WM_STARTPROCESS, 0, (LONG) szRCSTR);
bOpened = hDataBase;
if (bOpened)
SendMessage (hMDIClient,
WM_MDIDESTROY, hDataBase, 0L);
UpdateWindow (hMDIClient);
int oldLock;
oldLock = Results->Lock;
delete Results;
Results = new TSTCList ("",FALSE,
Classes, NumOfClasses,
Table);
Table->ReleaseSTC ();
Results->GetSTC ();
Results->Lock = oldLock+1;
Results->Renumber (clClasses);
char sz1[121];
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
strcat (Mystrtok(sz1, "."),
".db");
{
unsigned *crslnk;
startPercentage = 0;
endPercentage = 100;
crslnk = CreateCrossLinks (TRUE,
Results);
DoRestruct (sz1, Results, crslnk,
Results->GetCount () + 1);
delete crslnk;
delete pColumns[0];
delete pColumns[1];
delete pColumns[2];
pColumns[0] = pColumns[1] =
pColumns[2] = NULL;
nColumns[0] = nColumns[1] =
nColumns[2] = 0;
if (bOpened)
SendMessage (hMainWnd,
WM_COMMAND, ID_D_OPEN, 0L);
}
Results->ReleaseSTC ();
Standards->Save ();
clClasses->Release ();
Standards->Release ();
Demands->Release ();
SendMessage (hIndicationBarWnd,
WM_ENDPROCESS, 0, 0l);
SaveProject (szCurrentProject);
}
int
OpenProjectFunct (char *) (void) (Project.h à Project.cpp)
int
OpenProjectFunct (char *ProjectName)
{
FILE *file;
char sztmp[121];
char sz1[121], sz2[121];
char szCurrentFont[LF_FACESIZE];
int nRC = CE_SUCCESS;
strcat (Mystrtok (ProjectName,
"."), ".pjt");
if (!IsFileExist (ProjectName))
return CE_NOPROJECT;
extern BOOL
CheckProjectFile(char *);
if(!CheckProjectFile(ProjectName))
if ((file = fopen (ProjectName,
"rb")) == NULL) return CE_NOPROJECT;
if (!ReadOldPJT (file))
if (!ReadNewPJT (file))
{
fclose (file);
return CE_NOPROJECT;
}
Old2New
(NewCurrentProject, CurrentProject);
if (OpenAfterSaveAs)
{
strcpy (szPsw, sz1Psw);
PXPswAdd (szPsw);
if (!strcmp
(CurrentProject->ProjectStatus, "Private"))
strcpy (CurrentProject->Password,
szPsw);
}
else
if (!strcmp
(CurrentProject->ProjectStatus, "Private"))
{
if (!EnterPassword ())
{
return CE_NOPROJECT;
}
PXPswAdd (CurrentProject->Password);
strcpy (szPsw,CurrentProject->Password);
}
else
{
PXPswAdd ("Password");
strcpy (szPsw,"Password");
}
char szRCSTR1 [100];
LoadString (hinstResource, STR43,szRCSTR1,
sizeof (szRCSTR1));
SendMessage (hIndicationBarWnd,
WM_STARTPROCESS, 0, (LPARAM)(LPSTR) szRCSTR1);
NumOfClasses = 1;
if (!strcmp (CurrentProject->ProjectTask,
"Classification"))
{
if (fread (&NumOfClasses, sizeof
(NumOfClasses), 1, file) != 1)
{
fclose (file);
SendMessage (hIndicationBarWnd,
WM_ENDPROCESS, 0, 0l);
return CE_NOPROJECT;
}
for (int nI = 0; nI < NumOfClasses;
nI++)
{
Classes[nI] = new char[51];
if
(fread (Classes[nI], 51, 1, file) != 1)
{
fclose (file);
SendMessage (hIndicationBarWnd,
WM_ENDPROCESS, 0, 0l);
return CE_NOPROJECT;
}
}
}
SendMessage (hIndicationBarWnd, WM_PROCESS,
6, 0l);
fread (szDBDirectory, sizeof(szDBDirectory),
1, file);
if (fread (&nClmns, sizeof (nClmns), 1,
file) != 1)
{
nClmns = 0;
}
else
{
int Width;
BOOL Visible;
if (nClmns)
pClmns = new COLUMN[nClmns];
for (int nI = 0; nI < nClmns; nI++)
{
fread (&Width, sizeof (Width), 1,
file);
pClmns[nI].nWidth = Width;
fread (&Visible, sizeof (Visible), 1,
file);
pClmns[nI].bVisible = Visible;
}
}
SendMessage (hIndicationBarWnd, WM_PROCESS,
8, 0l);
if (fread (szCurrentFont, sizeof
(szCurrentFont), 1, file)!=1)
{
strcpy (szCurrentFont, "");
}
else
{
if (strcmp (szCurrentFont, ""))
strcpy (MainFontRec.lfFaceName,
szCurrentFont);
}
if (!strcmp(CurrentProject->ProjectStatus,
"Private"))
strcpy (szPsw, CurrentProject->Password);
else
strcpy (szPsw, "Password");
nRC = CheckingExistence ();
if (nRC & CE_NODATABASE)
MessageBox (hWnd, szRCSTR, NULL,
if ((nRC & CE_NOTEMPLATE) &&
strcmp (CurrentProject->ProjectState, "Building"))
strcpy (CurrentProject->ProjectState,
if (nRC & CE_NORESULTS)
MB_ICONEXCLAMATION);
if ((nRC & CE_NOSTANDARDS) &&
(!strcmp (CurrentProject->ProjectState,
"Tought") || !strcmp (CurrentProject->ProjectState,
"Phase 2")))
WM_RESTOREPROCESS, 0, 0l);
if ((!(nRC & CE_NOTEMPLATE)) &&
!strcmp (CurrentProject->ProjectState,
"Building"))
STR_SA_ATT,szRCSTR1, sizeof (szRCSTR));
if ((!(nRC & CE_NOSTANDARDS)) &&
!strcmp (CurrentProject->ProjectState,
"Built"))
fclose (file);
SendMessage (hIndicationBarWnd, WM_PROCESS,
10, 0l);
if (!CheckingWritable (nRC))
sizeof (szRCSTR));
strcpy (sztmp,
CurrentProject->ObjectsName);
strcat (Mystrtok(sztmp, "."),
".stc");
strcpy (sz1, szProjectDirectory);
strcpy (sz2, szDBDirectory);
Table = new TSTCList (strcat(sz2, sztmp),
TRUE);
Results = new TSTCList ("", FALSE,
Classes, NumOfClasses, Table);
strcat (sz1, szCurrentProject);
strcat (Mystrtok (sz1, "."),
".stc");
Records = new TSTCList (sz1, TRUE);
if ((nRC & CE_NOSTRUCTURE) &&
!(nRC & CE_NODATABASE))
Copy (Records, Table);
if ((nRC & CE_NOSTRUCTURE) &&
(nRC & CE_NODATABASE))
return nRC;
if (!strcmp
(CurrentProject->ProjectState, "Phase 2"))
switch (CheckPhase2 (sz1))
{
case OK_PH2:
break;
case MISSING_PH2:
case BAD_PH2:
SendMessage (hIndicationBarWnd,
DeletePhase2 (sz1);
strcpy
(CurrentProject->ProjectState, "Tought");
break;
}
if (!strcmp
(CurrentProject->ProjectState, "Tought") ||
!strcmp (CurrentProject->ProjectState,
"Phase 2"))
switch (CheckStandards (sz1))
{
case OK_STD:
break;
case BAD_STD:
DeleteStandards (sz1);
strcpy
(CurrentProject->ProjectState, "Built");
break;
}
if (!(nRC
& CE_NODATABASE))
if (!CheckingDB (sz2))
MB_OK
strcpy (sz1, szProjectDirectory);
ProjectFlags->TableModified = FALSE;
ProjectFlags->TemplateModified = FALSE;
Records->GetSTC ();
Standards = new ClassList;
Standards->Init(strcat (sz1,
szCurrentProject));
Standards->Get ();
Records->ReleaseSTC ();
strcpy (sz1, szProjectDirectory);
if (!strcmp(CurrentProject->ProjectTask,
"Classification"))
Demands = new TReqList (strcat (sz1,
CurrentProject->ReqName), NumOfClasses);
else
Demands = new TReqList (strcat (sz1,
CurrentProject->ReqName));
ProjectFlags->ResultsNeedSave = FALSE;
ProjectFlags->NowCreated = FALSE;
Records->GetSTC
();
OrgRegNumber
= Records->GetRegFields();
if (!(nRC
& CE_NOPROJECT) && !(nRC & CE_NODATABASE))
if ( CompareStructures ())
{
{
unsigned *crslnk;
BOOL bOpened;
strcpy (sz1, szProjectDirectory);
Mystrtok (strcat (sz1, szCurrentProject), ".");
bOpened = hDataBase;
if (bOpened)
SendMessage (hMDIClient,
WM_MDIDESTROY, hDataBase, 0L);
crslnk = CreateCrossLinks (FALSE);
DoRestruct (sz1, Results, crslnk,
Records->GetRegFields () + 1);
delete crslnk;
if (bOpened)
SendMessage (hMainWnd,
WM_COMMAND, ID_D_OPEN, 0L);
}
if (!(nRC & CE_NOTEMPLATE))
{
RecreateDemands ();
Standards->UpdateStructure ();
if (!Standards->Save ())
return CE_NOPROJECT;
}
else
{
strcpy (CurrentProject->ProjectState,
"Building");
}
}
Records->ReleaseSTC
();
if (!Records->GetSTC ()) return (nRC |
CE_NODATABASE);
Records->Renumber ();
if (!Records->SaveSTC ())
return CE_NOPROJECT;
Records->ReleaseSTC ();
SendMessage
(hIndicationBarWnd, WM_PROCESS, 14, 0L);
Old2New
(NewCurrentProject, CurrentProject);
return nRC;
}
BOOL
CreateDemandTemplate (void) (void) (Project.h à Project.cpp)
BOOL
CreateDemandTemplate (void)
{
int nRC;
char sz1[129];
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
strcat (Mystrtok (sz1, "."),
".stc");
if (!strcmp (CurrentProject->ProjectTask,
"Classification"))
Demands = new TReqList (sz1, NumOfClasses);
else
Demands = new TReqList (sz1);
Demands->Create ();
if (RusResourse)
HelpStack->PushInt (ID_W_DEMANDS);
else
HelpStack->PushInt (ID_ENGLISHHELP);
FARPROC lpCreateTptProc =
MakeProcInstance((int (PASCAL *)()) CreateTptDlgProc,hInst);
nRC = DialogBox(hinstResource, (LPSTR)
"CREATETPT", hWnd, (DLGPROC) lpCreateTptProc);
FreeProcInstance (lpCreateTptProc);
HelpStack->PopInt ();
ProjectFlags->TemplateModified = nRC;
if (nRC)
{
if (Demands->GetCount () == 0)
{
Demands->Release ();
return FALSE;
}
if (!strcmp
(CurrentProject->ProjectState, "Building"))
strcpy (CurrentProject->ProjectState,
"Built");
}
else
Demands->Release ();
return nRC;
}
BOOL
CreateProjectClasses (void) (void) (Project.h à Project.cpp)
BOOL
CreateProjectClasses (void)
{
int nRC;
if (RusResourse)
HelpStack->PushInt (ID_W_CLASSES);
else
HelpStack->PushInt (ID_ENGLISHHELP);
FARPROC lpCreateClassesProc =
MakeProcInstance((int (PASCAL *)()) ClassesDlgProc,hInst);
nRC = DialogBox(hinstResource, (LPSTR)
"CLASSLIST_DIALOG", hWnd, lpCreateClassesProc);
FreeProcInstance (lpCreateClassesProc);
HelpStack->PopInt ();
if (nRC)
{
for (int i = 0; i <
clClasses->GetCount (); i++)
Classes[i] = new char[51];
clClasses->Save (Classes, NumOfClasses);
clClasses->Release ();
}
return nRC;
}
BOOL
CreateDBStructure (char *) (void) (Project.h à Project.cpp)
BOOL
CreateDBStructure (char *ATableName)
{
int nRC;
char szAlpha[122];
char sztmp [122];
char sz1[129];
strcpy (szAlpha, ATableName);
Mystrtok (szAlpha, ".");
strcpy (sztmp, szAlpha);
strcat (sztmp, ".stc");
Table = new TSTCList (sztmp, TRUE);
Table->Create();
if (RusResourse) HelpStack->PushInt (ID_W_FEATURES);
else
HelpStack->PushInt (ID_ENGLISHHELP);
FARPROC lpCreateStcProc =
MakeProcInstance((int (PASCAL *)()) CreateStcDlgProc,hInst);
nRC = DialogBox(hinstResource, (LPSTR)
"CREATESTC", hWnd, lpCreateStcProc);
FreeProcInstance (lpCreateStcProc);
HelpStack->PopInt ();
if (!nRC) return FALSE;
Table->Renumber();
strcat (szAlpha, ".stc");
if (!SaveSTCFile (szAlpha)) return FALSE;
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
strcat (Mystrtok(sz1, "."),
".stc");
Records = new TSTCList (sz1, TRUE);
Copy (Records, Table);
return TRUE;
}
BOOL
UseExistingTable (char *) (void) (Project.h à Project.cpp)
BOOL
UseExistingTable (char *ATableName)
{
char szAlpha[122];
char sztmp[121];
char sz1[129];
TABLEHANDLE tmpTblHandle;
strcpy (szAlpha, ATableName);
Mystrtok (szAlpha, ".");
if (!CheckingDB (szAlpha))
{
return FALSE;
}
strcat (szAlpha, ".stc");
if (!IsFileExist (szAlpha)) return FALSE;
Table = new TSTCList (szAlpha, TRUE);
strcpy (sz1, szProjectDirectory);
strcat (sz1, szCurrentProject);
strcat (Mystrtok(sz1, "."),
".stc");
Records = new TSTCList (sz1, TRUE);
Copy (Records, Table);
ProjectFlags->TableModified = FALSE;
return TRUE;
}
BOOL FAR PASCAL _export CreateSTCDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam) (void) (Project.h à Project.cpp)
BOOL FAR
PASCAL _export CreateStcDlgProc (HWND hDlg,
UINT
message,
WPARAM wParam,
LPARAM lParam)
{
static int nCurrType;
static int nCurrPos;
static BOOL Modified;
static HPEN hBlackPen, hWhitePen;
static HBRUSH hNormBrush, hSelBrush, hBrush;
static char szRCSTR1[200];
static char szRCSTR2[200];
switch (message)
{
case WM_RBUTTONDBLCLK:
WORD w;
w = wParam;
if ((w & MK_CONTROL) && (w & MK_SHIFT)) return
FALSE;
case WM_INITDIALOG:
CheckRadioButton (hDlg,
ID_STC_REGFLD, ID_STC_IMPFLD,
ID_STC_REGFLD);
nCurrType = 2;
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_ADDSTRING,
0, (LPARAM)
"");
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_SETCURSEL,
0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_SETHORIZONTALEXTENT,
1000, 0l);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_SETHORIZONTALEXTENT,
1000, 0L);
Table->GotoFirst();
for (int nJ = 0; nJ <
Table->GetNumOfFields(); nJ++)
{
(*Table)[nJ];
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_INSERTSTRING,
nJ,
(LONG)
Table->GetFieldName());
}
Modified = FALSE;
SetTimer (hDlg, 1, 1000, NULL);
LoadString (hinstResource,
STR9,szRCSTR1, sizeof (szRCSTR1));
LoadString (hinstResource,
STR10,szRCSTR2, sizeof (szRCSTR2));
SendMessage (hDlg, WM_COMMAND,
ID_STC_CHARLIST,
((LONG)
LBN_SELCHANGE) << 16);
hBlackPen =
GetStockObject(BLACK_PEN);
hWhitePen =
GetStockObject(WHITE_PEN);
hNormBrush = CreateSolidBrush
(GetSysColor(COLOR_WINDOW));
hSelBrush = CreateSolidBrush
(GetSysColor (COLOR_HIGHLIGHT));
ProjectFlags->NeedToDouble =
FALSE;
break;
case WM_TIMER:
if (Modified &&
(Table->GetState() != 2) )
{
char sztemp[21];
GetDlgItemText (hDlg,
ID_STC_EDITFIELD, sztemp, 20);
if (!strcmp(sztemp, szRCSTR2))
SetDlgItemText (hDlg,
ID_STC_EDITFIELD, szRCSTR1);
else
SetDlgItemText (hDlg,
ID_STC_EDITFIELD, szRCSTR2);
}
if (SendDlgItemMessage (hDlg,
ID_STC_LISTVAL,
LB_GETCOUNT, 0, 0l) < 2)
EnableWindow (GetDlgItem (hDlg,
ID_STC_DELVAL), FALSE);
else
EnableWindow (GetDlgItem (hDlg,
ID_STC_DELVAL), TRUE);
break;
case WM_MEASUREITEM:
MEASUREITEMSTRUCT *mis =
(MEASUREITEMSTRUCT *) lParam;
switch (mis->CtlID)
{
case ID_STC_CHARLIST:
mis->itemHeight = 14;
break;
default: return FALSE;
}
break;
case WM_DRAWITEM:
DRAWITEMSTRUCT *disCtl =
(DRAWITEMSTRUCT *)lParam;
switch (disCtl->CtlID)
{
case ID_STC_CHARLIST:
if (disCtl->itemState &
ODS_SELECTED)
{
hBrush = hSelBrush;
SetBkColor
(disCtl->hDC,GetSysColor(COLOR_HIGHLIGHT));
}
else
{
hBrush = hNormBrush;
SetBkColor (disCtl->hDC,
GetSysColor(COLOR_WINDOW));
}
FillRect (disCtl->hDC,
&(disCtl->rcItem), hBrush);
COLORREF crColor;
if(((*Table)[disCtl->itemID])
== NULL) break;
if (disCtl->itemState &
ODS_SELECTED)
{
crColor = GetSysColor (COLOR_HIGHLIGHTTEXT);
}
else
switch (Table->GetState ())
{
case 1:
crColor = RGB (0,0,255);
break;
case 0:
crColor = RGB (0,0,0);
break;
case 2:
crColor = RGB (255,0,0);
break;
}
SetTextColor (disCtl->hDC,
crColor);
char szbuf[129];
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_GETTEXT,
disCtl->itemID, (LONG) szbuf);
ExtTextOut (disCtl->hDC,
disCtl->rcItem.left,
disCtl->rcItem.top, ETO_CLIPPED,
&(disCtl->rcItem), szbuf,
strlen (szbuf),
NULL);
if (disCtl->itemState &
ODS_FOCUS)
DrawFocusRect(disCtl->hDC,
&(disCtl->rcItem));
break;
default: return FALSE;
}
break;
case WM_COMMAND:
switch (wParam)
{
case ID_STC_CHARLIST:
switch (HIWORD(lParam))
{
char sztmp[129];
case LBN_SELCHANGE:
nCurrPos =
SendDlgItemMessage (hDlg, ID_STC_CHARLIST,
LB_GETCURSEL,
0,
0L);
if ((*Table)[nCurrPos] ==
NULL)
{
Modified = FALSE;
break;
}
else
{
EnableWindow (GetDlgItem
(hDlg, ID_STC_EDITFIELD),
TRUE);
EnableWindow (GetDlgItem
(hDlg, ID_STC_DELFIELD),
TRUE);
}
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL,
LB_RESETCONTENT,
0,
0L);
SetDlgItemText (hDlg,
ID_STC_EDITFIELD, szRCSTR1);
Modified = FALSE;
SetDlgItemText (hDlg, ID_STC_MINVAL, "");
SetDlgItemText (hDlg,
ID_STC_MAXVAL, "");
SetDlgItemText (hDlg,
ID_STC_VALNAME, "");
SetDlgItemText (hDlg,
ID_STC_FLDNAME,
Table->GetFieldName());
switch
(Table->GetFieldType())
{
case 0:
SendMessage (hDlg,
WM_COMMAND,
ID_STC_ENUMFLD,
0L);
for (int nJ = 0; nJ
< Table->GetNumOfValues(); nJ++)
{
Table->GotoVal
(nJ);
SendDlgItemMessage(hDlg, ID_STC_LISTVAL,
LB_INSERTSTRING,
nJ,
(LONG) Table->GetValue());
SendDlgItemMessage
(hDlg, ID_STC_LISTVAL,
LB_SETCURSEL,
0, 0l);
break;
case 1:
SendMessage (hDlg,
WM_COMMAND,
ID_STC_NUMFLD,
0L);
char szNum[21];
sprintf(szNum,
"%g",Table->GetMin());
SetDlgItemText
(hDlg, ID_STC_MINVAL, szNum);
sprintf(szNum,
"%g",Table->GetMax());
SetDlgItemText
(hDlg, ID_STC_MAXVAL, szNum);
break;
case 2:
SendMessage (hDlg,
WM_COMMAND,
ID_STC_REGFLD,
0L);
break;
}
break;
default: return FALSE;
}
break;
case ID_STC_FLDNAME:
switch (HIWORD (lParam))
{
char sztmp[129];
char sztmp1[129];
case EN_CHANGE:
GetDlgItemText (hDlg,
ID_STC_FLDNAME, sztmp, 128);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_GETTEXT,
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_GETCURSEL, 0, 0l),
(LONG)
sztmp1);
break;
case EN_SETFOCUS:
SendDlgItemMessage (hDlg,
ID_STC_FLDNAME, EM_SETSEL,
0,
MAKELPARAM (0, -1));
break;
default: return FALSE;
}
break;
case ID_STC_REGFLD:
CheckRadioButton (hDlg,
ID_STC_REGFLD, ID_STC_IMPFLD,
ID_STC_REGFLD);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_RESETCONTENT,
0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_ADDSTRING,
0, (LONG)
"");
SetDlgItemText (hDlg,
ID_STC_MINVAL, "");
SetDlgItemText (hDlg,
ID_STC_MAXVAL, "");
nCurrType = 2;
break;
case ID_STC_NUMFLD:
CheckRadioButton (hDlg,
ID_STC_REGFLD, ID_STC_IMPFLD,
ID_STC_NUMFLD);
nCurrType = 1;
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_RESETCONTENT,
0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_ADDSTRING,
0, (LONG)
"");
SetDlgItemText (hDlg,
ID_STC_MINVAL, "");
SetDlgItemText (hDlg,
ID_STC_MAXVAL, "");
break;
case ID_STC_ENUMFLD:
CheckRadioButton (hDlg,
ID_STC_REGFLD, ID_STC_IMPFLD,
ID_STC_ENUMFLD);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_RESETCONTENT,
0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_ADDSTRING,
0, (LONG) "");
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_SETCURSEL,
0, 0l);
SetDlgItemText (hDlg,
ID_STC_MINVAL, "");
SetDlgItemText (hDlg,
ID_STC_MAXVAL, "");
nCurrType = 0;
break;
case ID_STC_IMPFLD:
CheckRadioButton (hDlg,
ID_STC_REGFLD, ID_STC_IMPFLD,
ID_STC_IMPFLD);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_RESETCONTENT,
0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_ADDSTRING,
0, (LONG)
"");
SetDlgItemText (hDlg,
ID_STC_MINVAL, "");
SetDlgItemText (hDlg,
ID_STC_MAXVAL, "");
nCurrType = 3;
break;
case ID_STC_ADDFIELD:
char sztmp [129];
nCurrPos = SendMessage
(GetDlgItem (hDlg, ID_STC_CHARLIST),
LB_GETCURSEL, 0, 0L);
if (!AddField (hDlg, nCurrType,
nCurrPos, FALSE)) return TRUE;
char sztemp [129];
GetDlgItemText (hDlg,
ID_STC_FLDNAME, sztemp, 128);
nCurrPos = SendMessage (GetDlgItem
(hDlg, ID_STC_CHARLIST),
LB_GETCURSEL, 0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_INSERTSTRING, nCurrPos, (LONG) sztemp);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_SETCURSEL,
nCurrPos + 1,
0L);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_RESETCONTENT,
0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_ADDSTRING,
0, (LONG)
"");
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_SETCURSEL,
0, 0l);
SetDlgItemText (hDlg,
ID_STC_MINVAL, "");
SetDlgItemText (hDlg,
ID_STC_MAXVAL, "");
SetDlgItemText (hDlg,
ID_STC_VALNAME, "");
SetDlgItemText (hDlg,
ID_STC_EDITFIELD, szRCSTR1);
ProjectFlags->NeedToDouble =
TRUE;
Modified = FALSE;
break;
case ID_STC_DELFIELD:
nCurrPos = SendMessage
(GetDlgItem (hDlg, ID_STC_CHARLIST),
LB_GETCURSEL, 0, 0L);
char sz [129];
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_GETTEXT,
nCurrPos,
(LONG) sz);
if (!strcmp (sz, ""))
break;
(*Table)[nCurrPos];
Table->SetState (2);
Modified = FALSE;
ProjectFlags->NeedToDouble =
TRUE;
SetDlgItemText (hDlg,
ID_STC_EDITFIELD, szRCSTR1);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_SETCURSEL,
nCurrPos + 1,
0l);
SendMessage (hDlg, WM_COMMAND,
ID_STC_CHARLIST,
MAKELPARAM (0,
LBN_SELCHANGE));
break;
case ID_STC_EDITFIELD:
int Type;
nCurrPos = SendMessage
(GetDlgItem (hDlg, ID_STC_CHARLIST),
LB_GETCURSEL, 0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST, LB_GETTEXT,
nCurrPos,
(LONG) sz);
if (!strcmp (sz, ""))
break;
(*Table)[Table->GetNumberByName(sz)];
Type = Table->GetFieldType();
int Num =
Table->GetFieldNumber ();
switch (nCurrType)
{
case 2:
if (Type != 2)
szRCSTR,
break;
case 1:
if (Type != 1)
break;
case 0:
if (Type != 0)
LoadString (hinstResource,
break;
}
switch (Table->GetState())
{
case 2:
{
char szRCSTR [100];
LoadString (hinstResource,
STR12,szRCSTR, sizeof (szRCSTR));
if (MessageBox (hDlg,
szRCSTR,
NULL,
MB_YESNO | MB_ICONQUESTION)==IDNO)
return TRUE;
else
{
if (!AddField (hDlg,
nCurrType, nCurrPos, TRUE)) return TRUE;
Table->SetFieldNumber
(Num);
break;
}
}
case 0:
case 1:
BOOL bflg;
if (!AddField (hDlg,
nCurrType, nCurrPos, TRUE)) return TRUE;
Table->SetFieldNumber
(Num);
if ((*Table)++ == NULL)
bflg = TRUE;
else
bflg = FALSE;
Table->DeleteField ();
GetDlgItemText (hDlg,
ID_STC_FLDNAME, sztemp, 128);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_INSERTSTRING, nCurrPos,
(LONG) sztemp);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_DELETESTRING, nCurrPos + 1, 0l);
if (!bflg) (*Table)--;
Table->SetState (1);
break;
}
Modified = FALSE;
SetDlgItemText (hDlg,
ID_STC_EDITFIELD, szRCSTR1);
ProjectFlags->NeedToDouble =
TRUE;
break;
case ID_STC_MINVAL:
char sz1 [21];
switch (HIWORD (lParam))
{
case EN_KILLFOCUS:
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_GETTEXT,
SendDlgItemMessage (hDlg, ID_STC_CHARLIST,
LB_GETCURSEL,
0, 0l),
(LONG) sz);
GetDlgItemText (hDlg,
ID_STC_MINVAL, sz1, 20);
if (strcmp (sz,
""))
if (atof (sz1) !=
Table->GetMin ())
Modified = TRUE;
break;
default : return FALSE;
}
break;
case ID_STC_MAXVAL:
sz1 [21];
switch (HIWORD (lParam))
{
case EN_KILLFOCUS:
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_GETTEXT,
SendDlgItemMessage (hDlg, ID_STC_CHARLIST,
LB_GETCURSEL,
0, 0l),
(LONG)
sz);
GetDlgItemText (hDlg,
ID_STC_MAXVAL, sz1, 20);
if (strcmp (sz,
""))
if (atof (sz1) !=
Table->GetMax ())
Modified = TRUE;
break;
default : return FALSE;
}
break;
case ID_STC_NEWVAL:
char szStr [31];
sz [129];
int nCurrVal;
nCurrVal = SendDlgItemMessage (hDlg, ID_STC_LISTVAL,
LB_GETCURSEL,0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_GETTEXT,
nCurrVal,
(LONG) szStr);
GetDlgItemText (hDlg, ID_STC_VALNAME, szStr, 30);
if (!strcmp (szStr,
"")) break;
if (SendDlgItemMessage (hDlg,
ID_STC_LISTVAL,
LB_FINDSTRINGEXACT, -1, (LONG)szStr)
== LB_ERR)
SendMessage (GetDlgItem (hDlg,
ID_STC_LISTVAL),
LB_INSERTSTRING,
nCurrVal,
(LONG) szStr);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL,
LB_SETCURSEL, nCurrVal + 1, 0l);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_GETTEXT,
SendDlgItemMessage (hDlg, ID_STC_CHARLIST,
LB_GETCURSEL,
0, 0l),
(LONG) sz);
if (strcmp (sz, ""))
Modified = TRUE;
break;
case ID_STC_DELVAL:
nCurrVal = SendDlgItemMessage
(hDlg, ID_STC_LISTVAL,
LB_GETCURSEL,0, 0L);
SendDlgItemMessage (hDlg,
ID_STC_LISTVAL, LB_GETTEXT,
nCurrVal, (LONG) sz);
if (!strcmp (sz, ""))
break;
SendMessage (GetDlgItem (hDlg,
ID_STC_LISTVAL),
LB_DELETESTRING,
nCurrVal,
0L);
SendMessage (GetDlgItem (hDlg, ID_STC_LISTVAL),
LB_SETCURSEL,
nCurrVal,
0L);
SendDlgItemMessage (hDlg,
ID_STC_CHARLIST,
LB_GETTEXT,
SendDlgItemMessage (hDlg, ID_STC_CHARLIST,
LB_GETCURSEL,
0, 0l),
(LONG) sz);
if (strcmp (sz, ""))
Modified = TRUE;
break;
case ID_STC_EDITVAL:
SendMessage (hDlg, WM_COMMAND,
ID_STC_DELVAL, 0L);
SendMessage (hDlg, WM_COMMAND,
ID_STC_NEWVAL, 0L);
break;
case IDOK:
int All, Reg, Inf;
All = Reg = Inf = 0;
for (int i = 0; i <
Table->GetCount (); i++)
{
(*Table)[i];
switch (Table->GetState ())
{
case 1:
case 0:
switch (Table->GetFieldType())
{
case 0:
case 1:
Inf ++;
break;
case 2:
Reg ++;
break;
}
All++;
break;
default : continue;
}
}
if (!All)
MessageBox (hDlg, szRCSTR,
if (!Inf)
break;
if (!Reg)
LoadString (hinstResource,
Clear ();
Adjust ();
KillTimer (hDlg, 1);
EndDialog (hDlg, TRUE);
break;
case IDCANCEL:
KillTimer (hDlg, 1);
EndDialog (hDlg, FALSE);
break;
default:
return FALSE;
}
break;
default:
return FALSE;
}
return TRUE;
}
BOOL FAR PASCAL _export CreateTPTDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam) (void) (Project.h à Project.cpp)
BOOL FAR
PASCAL _export CreateTptDlgProc (HWND hDlg,
UINT message,
WPARAM wParam,
LPARAM lParam)
{
switch (message)
{
static char sztmp[129];
static int Items[255];
static int RealItems[255];
static unsigned nCount;
static unsigned nRealCount;
static int nCurrClass;
static int nCurrReq;
static int nCurrArch;
static BOOL WeightIsValid;
static BOOL RateIsValid;
static HBRUSH hNormBrush, hSelBrush, hBrush;
case WM_INITDIALOG:
WeightIsValid = TRUE;
RateIsValid = TRUE;
CheckDlgButton (hDlg, ID_TPT_EXTRDEM,
FALSE);
SendDlgItemMessage (hDlg,
ID_TPT_CLASSLIST, LB_SETHORIZONTALEXTENT,
1000, 0l);
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST, LB_SETHORIZONTALEXTENT,
1000, 0L);
SendDlgItemMessage (hDlg,
ID_TPT_CHARLIST, LB_SETHORIZONTALEXTENT,
1000, 0l);
for (int nI = 0; nI <
Demands->GetCount (); nI++)
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_ADDSTRING,
0,
(LONG)Demands->GetReqName (nI, sztmp));
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_ADDSTRING,
0,
(LONG)"");
if (!strcmp
(CurrentProject->ProjectTask, "Qualimetric"))
{
EnableWindow (GetDlgItem (hDlg,
ID_TPT_CLASSES), FALSE);
EnableWindow (GetDlgItem (hDlg,
ID_TPT_CLASSLIST), FALSE);
nCurrClass = 0;
}
else
{
for (int nI = 0; nI < NumOfClasses;
nI++)
SendDlgItemMessage (hDlg,
ID_TPT_CLASSLIST,
LB_ADDSTRING,
0,
(LONG)Classes[nI]);
SendDlgItemMessage (hDlg,
ID_TPT_CLASSLIST,
LB_SETCURSEL, 0,
0l);
}
if (!Records->GetSTC())
(szRCSTR));
Records->ReleaseSTC();
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST, LB_SETCURSEL, 0, 0L);
SendMessage (hDlg, WM_COMMAND,
ID_TPT_DEMLIST, ((LONG) LBN_SELCHANGE) << 16);
nCurrReq = 0;
nCurrClass = 0;
nCurrArch = 0;
hSelBrush =
CreateSolidBrush(GetSysColor(COLOR_HIGHLIGHT));
hNormBrush =
CreateSolidBrush(GetSysColor(COLOR_WINDOW));
break;
case WM_MEASUREITEM:
MEASUREITEMSTRUCT *mis =
(LPMEASUREITEMSTRUCT) lParam;
switch (mis->CtlID)
{
case ID_TPT_ARCHLIST:
mis = (MEASUREITEMSTRUCT *)
lParam;
mis->itemHeight = 14;
break;
default: return FALSE;
}
break;
case WM_DRAWITEM:
DRAWITEMSTRUCT *disCtl =
(LPDRAWITEMSTRUCT) lParam;
COLORREF crColor, crColor1;
static char *szbuf1;
switch (disCtl->CtlID)
{
case ID_TPT_ARCHLIST:
disCtl = (DRAWITEMSTRUCT
*)lParam;
if (Demands->GetArcQuantity
(nCurrReq) < 1)
break;
if (disCtl->itemState &
ODS_SELECTED)
{
hBrush = hSelBrush;
SetBkColor
(disCtl->hDC,GetSysColor(COLOR_HIGHLIGHT));
crColor = GetSysColor
(COLOR_HIGHLIGHTTEXT);
crColor1 = GetSysColor
(COLOR_HIGHLIGHTTEXT);
}
else
{
hBrush = hNormBrush;
SetBkColor (disCtl->hDC,
GetSysColor(COLOR_WINDOW));
crColor = GetSysColor
(COLOR_WINDOWTEXT);
crColor1 = RGB (0, 0, 255);
}
FillRect (disCtl->hDC,
&(disCtl->rcItem), hBrush);
SetTextColor (disCtl->hDC,
crColor);
char szbuf[129];
SendDlgItemMessage (hDlg,
ID_TPT_ARCHLIST, LB_GETTEXT,
disCtl->itemID, (LONG) szbuf);
strtok (szbuf, "\3");
WORD wWidht = LOWORD
(GetTextExtent (disCtl->hDC, szbuf,
strlen (szbuf)));
disCtl->rcItem.right = disCtl->rcItem.right - 40;
ExtTextOut (disCtl->hDC,
disCtl->rcItem.left,
disCtl->rcItem.top, ETO_CLIPPED,
&(disCtl->rcItem), szbuf,
strlen (szbuf),
NULL);
szbuf1 = strtok (NULL,
"\3");
if (szbuf1 != NULL)
strcpy (szbuf, szbuf1);
else
strcpy (szbuf, "");
SetTextColor (disCtl->hDC,
crColor1);
disCtl->rcItem.right =
disCtl->rcItem.right + 40;
ExtTextOut (disCtl->hDC,
disCtl->rcItem.right - 35,
disCtl->rcItem.top, ETO_CLIPPED,
&(disCtl->rcItem),
szbuf,
strlen (szbuf),
NULL);
if (disCtl->itemState &
ODS_FOCUS)
DrawFocusRect(disCtl->hDC,
&(disCtl->rcItem));
break;
default: return FALSE;
}
break;
case WM_COMMAND:
switch (wParam)
{
case IDOK:
if (!WeightIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_WEIGHT));
break;
}
if (!RateIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_ARCHRATE));
break;
}
int AllArc = 0;
for (int ind = 0; ind <
Demands->GetCount (); ind++)
AllArc +=
Demands->GetArcQuantity (ind);
if (!AllArc)
AdjustDemands ();
DeleteObject (hSelBrush);
DeleteObject (hNormBrush);
EndDialog (hDlg, TRUE);
break;
case IDCANCEL:
DeleteObject (hSelBrush);
DeleteObject (hNormBrush);
EndDialog (hDlg, FALSE);
break;
case ID_TPT_DEFAULT:
if (!WeightIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_WEIGHT));
break;
}
if (!RateIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_ARCHRATE));
break;
}
Records->GetSTC ();
Demands->Clear ();
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_RESETCONTENT, 0, 0l);
SendDlgItemMessage (hDlg,
ID_TPT_CLASSLIST,
LB_RESETCONTENT, 0, 0l);
for (int i =
Records->GetRegFields(), j = 0; i < Records->GetCount (); i++, j++)
{
(*Records)[i];
Demands->AddRequest
(Records->GetFieldName());
Demands->AddArc (j, i);
}
SendMessage (hDlg, WM_INITDIALOG,
0, 0l);
Records->ReleaseSTC ();
break;
case ID_TPT_EXTRDEM:
CheckDlgButton (hDlg,
ID_TPT_EXTRDEM,
!IsDlgButtonChecked (hDlg, ID_TPT_EXTRDEM));
Demands->SetExtremal
(nCurrReq, nCurrClass,
IsDlgButtonChecked(hDlg, ID_TPT_EXTRDEM));
break;
case ID_TPT_ADD:
if (!WeightIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_WEIGHT));
break;
}
if (!RateIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_ARCHRATE));
break;
}
char sztmp[129];
int n;
int nCurrPos = SendDlgItemMessage
(hDlg, ID_TPT_DEMLIST,
LB_GETCURSEL, 0,
0L);
GetDlgItemText (hDlg,
ID_TPT_DEMNAME, sztmp, 128);
if (!strcmp (sztmp,
"")) break;
if ((n = SendDlgItemMessage(hDlg,
ID_TPT_DEMLIST,
LB_FINDSTRINGEXACT, -1,
(LONG) sztmp)) != LB_ERR)
{
break;
}
AddDemand (GetDlgItem (hDlg,
ID_TPT_DEMLIST),
nCurrPos,
GetDlgItem (hDlg,
ID_TPT_DEMNAME),
GetDlgItem (hDlg,
ID_TPT_EXTRDEM));
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_SETCURSEL, nCurrPos + 1, 0l);
break;
case ID_TPT_DELETE:
nCurrPos = SendDlgItemMessage
(hDlg, ID_TPT_DEMLIST,
LB_GETCURSEL, 0, 0L);
DeleteDemand (GetDlgItem (hDlg,
ID_TPT_DEMLIST),
nCurrPos);
break;
case ID_TPT_ATTACH:
if (!WeightIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_WEIGHT));
break;
}
if (!RateIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_ARCHRATE));
break;
}
Records->GetSTC();
n = SendDlgItemMessage (hDlg,
ID_TPT_CHARLIST,
LB_GETSELITEMS, 254, (LONG)Items);
for (i = 0; i < n; i++)
{
SendDlgItemMessage (hDlg,
ID_TPT_CHARLIST,
LB_GETTEXT,
Items[i], (LONG)sztmp);
int nNum = Records->GetNumberByName (sztmp);
Demands->AddArc (nCurrReq,
nNum);
SendDlgItemMessage (hDlg,
ID_TPT_ARCHLIST,
LB_ADDSTRING, 0, (LONG) sztmp);
}
for (i = 0; i < n; i++)
SendDlgItemMessage (hDlg,
ID_TPT_CHARLIST,
LB_DELETESTRING, Items[i] - i, 0l);
Records->ReleaseSTC();
break;
case ID_TPT_DETACH:
if (!WeightIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_WEIGHT));
break;
}
if (!RateIsValid)
{
SetFocus (GetDlgItem (hDlg,
ID_TPT_ARCHRATE));
break;
}
Records->GetSTC ();
if ((n = SendDlgItemMessage
(hDlg, ID_TPT_ARCHLIST,
LB_GETCURSEL, 0, 0l)) !=LB_ERR)
if (Demands->GetArcQuantity
(nCurrReq) != 0)
{
int nNum =
Demands->GetArcField (nCurrReq, n);
Demands->DeleteArc (nCurrReq,
n);
int k = SendDlgItemMessage
(hDlg, ID_TPT_CHARLIST,
LB_GETCOUNT, 0, 0l);
for (int j = 0; j < k; j++)
{
SendDlgItemMessage (hDlg,
ID_TPT_CHARLIST,
LB_GETTEXT,
j, (LONG) sztmp);
strtok (sztmp, "\3");
if
(Records->GetNumberByName(sztmp) > nNum)
break;
}
(*Records)[nNum];
SendDlgItemMessage (hDlg,
ID_TPT_ARCHLIST,
LB_DELETESTRING, n, 0l);
SendDlgItemMessage (hDlg,
ID_TPT_CHARLIST,
LB_INSERTSTRING, j,
(LONG)
Records->GetFieldName());
}
Records->ReleaseSTC();
break;
case ID_TPT_DEMLIST:
switch (HIWORD(lParam))
{
case LBN_SELCHANGE:
nCurrReq = SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_GETCURSEL, 0, 0L);
UpdateReq (hDlg, nCurrReq,
nCurrClass, nCurrArch = 0,
GetDlgItem (hDlg, ID_TPT_WEIGHT),
GetDlgItem
(hDlg, ID_TPT_ARCHRATE),
GetDlgItem
(hDlg, ID_TPT_DEMNAME),
ID_TPT_EXTRDEM,
GetDlgItem (hDlg, ID_TPT_ARCHLIST),
GetDlgItem
(hDlg, ID_TPT_CHARLIST));
break;
default: return FALSE;
}
break;
case ID_TPT_DEMNAME:
switch (HIWORD(lParam))
{
char sz1[129];
char sz2[129];
int n;
case EN_CHANGE:
GetDlgItemText (hDlg,
ID_TPT_DEMNAME, sz1, 128);
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST, LB_GETTEXT,
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_GETCURSEL,
0,0l),
(LONG)
sz2);
if (strcmp (sz1, sz2))
EnableWindow (GetDlgItem
(hDlg, ID_TPT_DELETE), FALSE);
else
EnableWindow (GetDlgItem
(hDlg, ID_TPT_DELETE), TRUE);
break;
case EN_KILLFOCUS:
GetDlgItemText (hDlg,
ID_TPT_DEMNAME, sz1, 128);
if (!strcmp (sz1,
"")) break;
if ((n = SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_FINDSTRINGEXACT, -1,
(LPARAM) sz1)) != LB_ERR)
{
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_SETCURSEL, n, 0l);
SendMessage (hDlg,
WM_COMMAND, ID_TPT_DEMLIST,
((LONG)
LBN_SELCHANGE) << 16);
}
else
{
SendMessage (hDlg,
WM_COMMAND, ID_TPT_ADD, 0l);
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_SETCURSEL,
SendDlgItemMessage (hDlg,
ID_TPT_DEMLIST,
LB_GETCURSEL,
0, 0l)
- 1,
0l);
SendMessage (hDlg,
WM_COMMAND, ID_TPT_DEMLIST,
((LONG)
LBN_SELCHANGE) << 16);
}
break;
default: return FALSE;
}
break;
case ID_TPT_CLASSLIST:
switch (HIWORD(lParam))
{
nCurrClass =
SendDlgItemMessage(hDlg, ID_TPT_CLASSLIST,
LB_GETCURSEL, 0, 0L);
UpdateAll (hDlg, nCurrReq,
nCurrClass, nCurrArch,
GetDlgItem
(hDlg, ID_TPT_WEIGHT),
GetDlgItem
(hDlg, ID_TPT_ARCHRATE),
GetDlgItem (hDlg,
ID_TPT_DEMNAME),
ID_TPT_EXTRDEM);
break;
default: return FALSE;
}
break;
case ID_TPT_ARCHLIST:
switch (HIWORD(lParam))
{
case LBN_SELCHANGE:
if
(Demands->GetArcQuantity (nCurrReq) == 0)
break;
nCurrArch =
SendDlgItemMessage(hDlg, ID_TPT_ARCHLIST,
LB_GETCURSEL, 0, 0L);
UpdateArch (nCurrReq,
nCurrClass, nCurrArch,
GetDlgItem (hDlg,
ID_TPT_ARCHRATE));
break;
default: return FALSE;
}
break;
case ID_TPT_WEIGHT:
switch (HIWORD(lParam))
{
case EN_KILLFOCUS:
GetDlgItemText (hDlg,
ID_TPT_WEIGHT, sztmp, 21);
char *end;
float wght = strtod (sztmp,
&end);
if (*end != '\0')
{
WeightIsValid = FALSE;
break;
}
WeightIsValid = TRUE;
Demands->SetWeight
(nCurrReq, nCurrClass, wght);
break;
default: return FALSE;
}
break;
case ID_TPT_ARCHRATE:
switch (HIWORD(lParam))
{
case EN_KILLFOCUS:
char sztmp2[129];
char sztmp1[129];
if (SendDlgItemMessage
(hDlg, ID_TPT_ARCHLIST, LB_GETTEXT,
nCurrArch, (LONG) sztmp2) == LB_ERR)
break;
if (!strcmp (sztmp2,
"")) break;
strtok (sztmp2,
"\3");
GetDlgItemText (hDlg,
ID_TPT_ARCHRATE, sztmp, 21);
if (atof (sztmp) < 0)
break;
char *end;
float wght = strtod (sztmp,
&end);
if (*end != '\0')
{
RateIsValid = FALSE;
break;
}
RateIsValid = TRUE;
Demands->SetArcWeight
(nCurrReq,
nCurrClass, nCurrArch,
wght);
sprintf (sztmp1,
"%s\3%.2f", sztmp2, atof(sztmp));
SendDlgItemMessage (hDlg,
ID_TPT_ARCHLIST,
LB_DELETESTRING, nCurrArch, 0l);
SendDlgItemMessage (hDlg,
ID_TPT_ARCHLIST,
LB_INSERTSTRING, nCurrArch,
(LONG)
sztmp1);
break;
default: return FALSE;
}
break;
default:
return FALSE;
}
break;
default:
return FALSE;
}
return TRUE;
}
BOOL FAR PASCAL _export ClassesDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam) (void) (Project.h à Project.cpp)
BOOL FAR
PASCAL _export ClassesDlgProc (HWND hDlg,
unsigned message,
WORD
wParam,
LONG
lParam)
{
TClass CurClass;
switch (message)
{
case WM_INITDIALOG:
for (int nI = 0; nI <
clClasses->GetCount (); nI++)
{
(*clClasses)[nI];
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_ADDSTRING, 0,
(LONG) clClasses->GetName());
}
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_ADDSTRING, 0,
(LONG) "");
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_SETCURSEL, 0,
0L);
SendMessage (hDlg, WM_COMMAND,
ID_CLAS_LISTBOX,
((LONG) LBN_SELCHANGE)
<< 16);
break;
case WM_COMMAND:
switch (wParam)
{
case IDOK:
if (SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_GETCOUNT, 0, 0l) < 3)
EndDialog (hDlg, TRUE);
break;
case IDCANCEL:
EndDialog (hDlg, FALSE);
break;
case ID_CLAS_ADD:
char sztmp[51];
char sz1[51];
int n;
GetDlgItemText (hDlg,
ID_CLAS_CLASSNAME, sztmp, 50);
if (!strcmp (sztmp,
"")) break;
if ((n = SendDlgItemMessage
(hDlg, ID_CLAS_LISTBOX,
LB_FINDSTRINGEXACT, -1, (LONG)sztmp))
!= LB_ERR)
{
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_SETCURSEL,
n, 0l);
SendMessage (hDlg, WM_COMMAND,
ID_CLAS_LISTBOX,
((LONG)
LBN_SELCHANGE) << 16);
break;
}
n = SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_GETCURSEL, 0, 0l);
strcpy (CurClass.Name, sztmp);
CurClass.Number = -1;
SendDlgItemMessage (hDlg, ID_CLAS_LISTBOX,
LB_GETTEXT,
n, (LONG) sz1);
if (!strcmp(sz1, ""))
clClasses->AddClass
(&CurClass);
else
{
(*clClasses)[n];
clClasses->Insert(&CurClass);
}
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_INSERTSTRING, n, (LONG) sztmp);
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_SETCURSEL,
n + 1, 0l);
SendMessage (hDlg, WM_COMMAND,
ID_CLAS_LISTBOX,
((LONG)
LBN_SELCHANGE) << 16);
break;
case ID_CLAS_DELETE:
n = SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_GETCURSEL, 0, 0l);
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_GETTEXT,
n, (LONG)sz1);
if (!strcmp(sz1, ""))
break;
(*clClasses)[n];
clClasses->Delete();
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_DELETESTRING, n, (LONG) sztmp);
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_SETCURSEL,
n , 0l);
SendMessage (hDlg, WM_COMMAND,
ID_CLAS_LISTBOX,
((LONG)
LBN_SELCHANGE) << 16);
break;
case ID_CLAS_EDIT:
SendMessage (hDlg, WM_COMMAND,
ID_CLAS_DELETE, 0L);
SendMessage (hDlg, WM_COMMAND,
ID_CLAS_ADD, 0L);
break;
case ID_CLAS_LISTBOX:
switch (HIWORD(lParam))
{
case LBN_SELCHANGE:
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_GETTEXT,
SendDlgItemMessage (hDlg,
ID_CLAS_LISTBOX,
LB_GETCURSEL,
0, 0l),
(LONG)
sztmp);
SetDlgItemText (hDlg,
ID_CLAS_CLASSNAME, sztmp);
break;
default :return FALSE;
}
break;
default:
return FALSE;
}
break;
default:
return FALSE;
}
return TRUE;
}
1. ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ РАЗРАБОТКИ
2. АЛГОРИТМ
ВЗАИМОДЕЙСТВИЯ ЧЕРЕЗ КОММУНИКАЦИОННЫЙ СЕРВЕР ИС
EXPEK_N
3. ВЗАИМОДЕЙСТВИЕ БЛОКОВ СИСТЕМЫ ПО ПРИНЦИПУ
«КЛИЕНТ-СЕРВЕР»
4. МОДЕЛЬ ПРЕДСТАВЛЕНИЯ
ЗНАНИЙ В ИС EXPEK_N
5. ОПИСАНИЕ
СТРУКТУР ДАННЫХ ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ EXPEK
6. ОБЩИЙ ПОРЯДОК РАБОТЫ
В ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЕ EXPEK
1. ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ
РАЗРАБОТКИ
2. АЛГОРИТМ ВЗАИМОДЕЙСТВИЯ ЧЕРЕЗ
КОММУНИКАЦИОННЫЙ СЕРВЕР ИС EXPEK_N
3. ВЗАИМОДЕЙСТВИЕ БЛОКОВ СИСТЕМЫ ПО ПРИНЦИПУ
КЛИЕНТ-СЕРВЕР”
4. МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ЗНАНИЙ В ИС EXPEK_N
5. ОПИСАНИЕ СТРУКТУР ДАННЫХ ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ EXPEK
6. ОБЩИЙ ПОРЯДОК РАБОТЫ В ИНТЕЛЛЕКТУАЛЬНОЙ
СИСТЕМЕ EXPEK Обозначение Наименование Прим. АМДР.АМ932.1009-01 81 01 Организация данных и знаний в интеллектуальных системах построенных по типу “клиент- сервер”. Пояснительная записка АМДР.АМ932.1009-01 90 01 Алгоритм взаимодействия через коммуникационный сервер ИС ЕХРЕК_N АМДР.АМ932.1009-01 90 01 Взаимодействие блоков системы по принципу “клиент-сервер” АМДР.АМ932.1009-01 90 01 Модель представления знаний в ИС ЕХРЕК_N АМДР.АМ932.1009-01 90 01 Описание структур данных в ИС ЕХРЕК_N АМДР.АМ932.1009-01 90 01 Общий порядок работы ИС ЕХРЕК_N АМДР.АМ932.1009-01 90 01 Экономические показатели разработки Обозначение Наименование Прим.
1. DEMAND_LIST
Список
требований проекта № Имя поля Тип поля Длина поля Комментарий 1. PRJ_ID INTEGER 4 Код проекта 2. DEM_ID INTEGER 4 Код требования 3. DEM_NAME VARCHAR 50 Имя требования 4. DEM_RATE FLOAT 4 Вес требования 5. CRITICAL INTEGER 4 Критичность требования
2. DEMAND_PROPS
Список
свойств, входящих в требования проекта № Имя поля Тип поля Длина поля Комментарий 1. PRJ_ID INTEGER 4 Код проекта 2. DEM_ID INTEGER 4 Код требования 3. PROP_ID INTEGER 4 Код свойства, входящего в требование 4. PROP_RATE FLOAT 4 Вес свойства
3. DS_LIST
Список
источников данных № Имя поля Тип поля Длина поля Комментарий 1. DS_ID INTEGER 4 Код источника данных 2. DS_NAME VARCHAR 40 Имя источника данных 3. DS_PATH VARCHAR 128 Путь к файлу источника данных 4. DS_TABLE_NAME VARCHAR 40 Имя таблицы источника данных 5. DS_DRIVER VARCHAR 40 Драйвер источника данных 6. DS_KEY_FIELDS VARCHAR 100 Ключевые поля источника данных
4. OPTICS — Используется при обучения проекта. Содержит
количество разбиений, либо шаг приращения для численных свойств. № Имя поля Тип поля Длина поля Комментарий 1. DS_ID INTEGER 4 Код источника данных 2. PROP_ID INTEGER 4 Код свойства в источнике данных 3. CHEK INTEGER 4 0 – количество разбиений; 1 – шаг приращения 4. VAL CHAR 20 Значение либо количества разбиений, либо шага приращения в зависимости от поля CHEK
5. PROJECT_LIST
Список
проектов № Имя поля Тип поля Длина поля Комментарий 1. PRJ_ID INTEGER 4 Код проекта 2. PRJ_NAME VARCHAR 50 Код требования 3. DS_ID INTEGER 4 Код источника данных для проекта 4. PRJ_TYPE INTEGER 4 Тип проекта 5. FLAGS_ACCESS INTEGER 4 Флаги доступа 6. PRJ_COMMENT VARCHAR 100 Комментарии к проекту
Примечание: выделенные цветом поля в
таблицах являются ключевыми.
6. PROJECT_PROPS
Список
свойств, входящих в проект № Имя поля Тип поля Длина поля Комментарий 1. PRJ_ID INTEGER 4 Код проекта 2. PROP_ID INTEGER 4 Код свойства 3. FLAGS INTEGER 4 Флаги
7. PROP_LIST
Общий список
свойств № Имя поля Тип поля Длина поля Комментарий 1. DS_ID INTEGER 4 Код источника данных 2. PROP_ID INTEGER 4 Код свойства 3. PROP_NAME VARCHAR 30 Имя свойства 4. PROP_TYPE INTEGER 4 Тип свойства (0 – перечислимое; 1 – численное; 2 – регистрационное) 5. FIELD_NAME VARCHAR 40 Имя физического поля в таблице источника данных
8. PROP_REF — Справочник перечислимых
свойств. Кроме того, содержит информацию о значениях минимума и максимума для
перечислимых свойств № Имя поля Тип поля Длина поля Комментарий 1. DS_ID INTEGER 4 Код источника данных 2. PROP_ID INTEGER 4 Код свойства 3. PROP_VALUE_ID INTEGER 4 Код значения свойства – для перечислимых; (0 – Мин., 1 – Макс.) – для численных 4. PROP_VALUE_NAME VARCHAR 30 Название значения свойства – для перечислимых; Минимум либо максимум – для численных
9. STANDARDS
Список
эталонов для проекта № Имя поля Тип поля Длина поля Комментарий 1. DS_ID INTEGER 4 Код источника данных 2. PROP_ID INTEGER 4 Код свойства в источнике данных 3. PROP_VALUE FLOAT 4 Значение перечислимого либо числ-го свойства 4. MV FLOAT 4 Мера выраженности (“хорошесть”) данного значения свойства в рамках проекта
Примечание: выделенные цветом поля в
таблицах являются ключевыми.
АННОТАЦИЯ
Целью настоящей дипломной работы является разработка структуры и
алгоритмов взаимодействия программных блоков интеллектуальной системы для
оценки сложных объектов, построенной по принципу “клиент\сервер”. Конкретно
рассматривается проектирование одного из блоков системы – блока управления
данными и знаниями интеллектуальной системы, построенной по принципу
клиент\сервер”.
Проектируемый блок обеспечивает такие основные свойства системы
как распределенность данных и знаний, параллелизм при доступе и обработке
данных, гибкость при настройке, надежность и корректность всей информации.
Задачи, решаемые универсальной экспертной системой, делятся на
два вида - задачи квалиметрии (оценки качества) и классификации (распознавания
образов).
В ходе выполнения дипломной работы была:
- исследована структура и
функции ИС в целом и ее отдельных программных блоков - АРМ-ов администратора
системы, эксперта, лица принимающего решения (руководителя), рядового оператор
хранения компонентов модели;
- разработаны структуры
данных и основные функции перечисленных автоматизированных рабочих мест.
- разработан порядок
взаимодействия всех компонентов в целом.
- выполнена программная
реализация модуля администратор.
- выполнены экономические расчеты целесообразности разрабатываемого
продукта, а также рассмотрены вопросы безопасности жизнедеятельности
операторов ЭВМ.
ANNOTATION
The purpose of
this diploma work is development of structure and algorithms of interaction of
programm blocks of intelligent system for an estimation of complex objects,
constructed by the principle “client/server”. Designing one of blocks of system
- the block of management of data and knowledge of intelligent system,
constructed by the principle “client/server” is particularly considered.
The projected block provides such basic properties of
system as distribution of data and knowledge, parallelism at access and data
processing, flexibility at set-up, reliability and true sense of the information.
The problems, soluble by universal expert system, are
divided on two kinds - problem of estimation of quality and classification
(recognition of images).
During fulfillment of diploma work there were
completed these topics:
- Structure and functions: as a whole and its separate
programm blocks - automatic working place of the manager of system, expert,
person of the accepting decision (chief), ordinary the operator of components
of model is investigated;
- Structures and basic functions of listed automated
working places are developed.
- Order of interaction of all components as a whole is
developed.
- Programm realization of the module the manager is
carried out.
- Economic accounts of expediency is carried out of a
product are carried out, and also questions of safety work of the computer
operators are considered.
ВЗАИМОДЕЙСТВИЕ БЛОКОВ СИСТЕМЫ ПО ПРИНЦИПУ «КЛИЕНТ-СЕРВЕР»
СОДЕРЖАНИЕ
СОДЕРЖАНИЕ.................................................. 1
ВВЕДЕНИЕ.................................................... 4
1.
ПРЕДСТАВЛЕНИЕ ДАННЫХ И ЗНАНИЙ В
ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМАХ 10
1.1.
Модель представления знаний с помощьюправил.......... 10
1.2.
Модель представления знаний с помощью логики
предикатов 13
1.3.
Модель представления знаний с помощью сетей нейронов. 15
1.4.
Модель представления знаний с помощью семантических сетей 20
1.5.
Модель представления знаний с помощью фреймов........ 22
1.6.
Cистемы «клиент\сервер» и общая организация данных в них 24
ВЫВОДЫ.................................................... 28
2. АРХИТЕКТУРА ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМ
(ИС) ДЛЯ ОЦЕНКИ СЛОЖНЫХ ОБЪЕКТОВ 30
2.1.
Постановка задачи оценки сложных объектов.
Описание представления знаний.................................................... 30
2.2.
Типовая структура ИС................................. 34
3.
ПРОЕКТИРОВАНИЕ СРЕДСТВ УПРАВЛЕНИЯ ДАННЫМИ В ИС.......... 38
3.1.
Описание основных структур данных.................... 38
3.2.
Назначение, состав и описание блока управления данными 42
3.2.1
Функции первого уровня............................ 45
3.2.2.Описание
функций нижних уровней................... 47
4.
ОПИСАНИЕ ПРИМЕНЕНИЯ СРЕДСТВ УПРАВЛЕНИЯ ДАННЫМИ В ИС..... 49
4.1.
Описание интерфейса пользователя
(руководство пользователя) 49
4.1.1.
Создание проекта................................. 49
4.1.2.
Откытие проекта.................................. 52
4.1.3.
Закрытие проекта................................. 52
4.1.4.
Сохранение копии проекта......................... 53
4.1.5.
Удаление проекта................................. 53
4.1.6.
Формирование множества свойств................... 53
4.1.7.
Формирование перечня классов..................... 59
4.1.8.
Формирование перечня требований.................. 60
4.2.Описание
контрольного примера......................... 64
5.
ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ДИПЛОМНОЙ РАБОТЫ...... 68
5.1.
Бизнес-план.......................................... 68
5.1.1.
Резюме........................................... 68
5.1.2.
Описание программы.............................. 69
5.1.3.
Информация о возможных конкурентах............... 70
5.1.4.
Стратегия маркетинга............................. 70
5.1.6 План производства................................. 71
5.2.
Функционально-стоимостной анализ..................... 72
5.2.1
Построение дерева целей........................... 72
5.2.2.
Построение структурной модели программы.......... 74
5.2.3.
Построение функциональной модели................. 74
программы............................................... 74
5.2.4
Расчет стоимости программных единиц............... 75
5.3.
Построение и анализ функционально-стоимостной диаграммы 82
5.4.
Технико-экономические расчеты (на 12 мая 1998г.)..... 86
5.4.1.
Расчет стоимости машино-часа на ЭВМ.............. 86
5.4.2.
Расчет сметной стоимости НИ ОКР и цены
программы 90
5.4.3
Расчет эксплутационных издержек у потребителя..... 91
5.4.4
Расчет годового экономического эффекта............ 91
и
показателей эффективности............................. 91
5.5.
Выводы................................................ 93
6.
БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ.......................... 94
6.1.
Обоснование выбора объекта........................... 94
6.2.
Особенности труда пользователей ЭВМ.................. 94
6.2.1.
Общие сведения................................... 94
Диапазон................................................... 97
6.2.2.
Рекомендации по организации рабочих мест пользователей. 97
6.3.
Расчёт системы освещения............................. 99
6.3.1.
Индивидуальное задание........................... 99
6.3.2.
Общие теоретические сведения..................... 99
6.3.3.
Расчёт естественной освещенности................ 100
6.3.4.
Расчёт искусственного освещения помещения....... 101
6.4.
Выводы по изучению вопроса о безопасности
жизнедеятельности. 105
ЗАКЛЮЧЕНИЕ................................................ 106
ЛИТЕРАТУРА................................................ 108
ПЕРЕЧЕНЬ
ГРАФИЧЕСКОГО МАТЕРИАЛА........................... 112
ПРИЛОЖЕНИЯ................................................ 113
ВВЕДЕНИЕ
В настоящее время стремительными темпами распространяются
сетевые компьютерные технологии. Предпосылками к этому служат процессы
дальнейшего развития программных и аппаратных средств вычислительной техники.
Появились достаточно мощные и сравнительно дешевые аппаратные
средства. Резко повысилось быстродействие всех компонентов вычислительных
систем. Это коснулось как микропроцессорных устройств, так и других системных
компонентов таких как администраторы системных шин, математические сопроцессоры,
устройства ввода-вывода.
Внедрение новых технологий в производство аппаратуры привело
к появлению запоминающих устройств большой емкости, с высокими надежностью и
быстродействием.
Значительно повысились мощность и быстродействие периферийных
устройств ввода и вывода информации.
Было налажено массовое производство компонентов вычислительных
систем, что привело к резкому удешевлению всех средств вычислительной техники.
Кроме того, наметился переход от широкого использования
больших ЭВМ к настольным, персональным компьютерам. Этот переход кроме
вышеизложенных причин обуславливался миниатюризацией электронных компонентов, а
также повышением надежности серийно выпускаемых элементов. Совместное же
использование ресурсов вычислительных систем и обмен данными решается с помощью
вычислительных сетей разной топологии и масштаба. Также резко удешевились
средства Multimedia.
Прогресс в производстве оборудования происходил параллельно
с прогрессом в области разработки программного обеспечения. В последнее время
все шире используются проблемно-ориентированные языки программирования, что в
большинстве случаев снижает время на разработку программ в конкретной
предметной области.
В последние несколько лет широкое распространение получили
новые подходы к программированию. Речь идет о так называемых CASE-технологиях и
различных технологиях автоматического кодирования. Развитие и широкое внедрение
этих технологий сделало труд программиста более творческим чем рутинным и
позволило сократить время разработки программ.
Отдельно следует сказать о получившем широкое распространение
объектно-ориентированном подходе к программированию. Внедрение этого подхода
позволило более глубоко структурировать производимое программное обеспечение,
оптимизировать программный код, сделать программные модули более
аппаратно-независимыми, стандартизировать интерфейс с ними. В связи с этим на
рынке появилось много программных библиотек, в значительной мере облегчающих
разработку программ.
Автоматизация труда программистов привела к значительному
увеличению скорости развития и совершенствования прикладных программных
пакетов. В комбинации с прогрессом в развитии аппаратуры это привело к
появлению возможности разработки сложных прикладных программ во-первых, за
короткие сроки, во-вторых, ориентированных на массового потребителя, в-третьих,
за сравнительно низкую цену. При этом эти программные продукты не теряют ни в
мощности ни в быстродействии.
Появление на рынке современных операционных систем, таких
как Windows”95 и Windows NT фирмы Microsoft Corp, новых версий OS/2 фирмы IBM и
NetWare 4.X фирмы Novell, во-первых, позволило создавать программы на
аппаратно-независимом уровне; во-вторых, привело к созданию единой системы
пользовательского интерфейса и связанных с ним технологий; в-третьих, позволило
разрабатывать программы, ориентированные на многозадачный режим работы и
динамический обмен данными между ними; в-четвертых, позволило более полно
реализовать возможности современного аппаратного обеспечения; в-пятых,
облегчило построение малых локальных сетей и использование технологии
клиент-сервер.
Все вышеназванное привело к тому, что в настоящее время,
персональный компьютер стал настольным инструментом практически всех людей,
занятых умственным трудом во всех сферах деятельности человека и локализованных
во всех точках планеты. В то же время, автоматизации подвергаются в основном
работы, требующие выполнения рутинных процессов, расчетов, связанных с
громоздкими вычислениями. Это обусловило появление на рынке большого количества
программных продуктов, связанных с решением таких задач как: автоматизация
набора текста, пример - широко известный текстовый процессор Microsoft Word;
автоматизация издательской деятельности, примеры - PageMaker и Ventura
Publisher; широко распространены системы организации презентационной графики,
проверки орфографии, системы поддержки табличных вычислений (Exel); современные
СУБД типа Access, Paradox. Требования потребителей к автоматизации документооборота
привели к совершенствованию технологий управления базами данных и связи между
компьютерами т.е. привели к развитию вычислительных сетей разного масштаба и, в
первую очередь, малых локальных сетей. Развиваются связанные с этим технологии распределенных баз данных
(использующие клиент-серверный принцип построения). В настоящее время развитие
информационно-поисковых систем представляет собой отдельное научно-инженерное
направление.
Таким образом, развитие программных и аппаратных средств
вычислительной техники позволило успешно автоматизировать такие виды
человеческой деятельности как подготовка и оформление текстов, проведение
типовых расчетов, поиск и группирование информации в больших массивах данных и
некоторые другие. Однако более сложные, аналитические задачи по-прежнему остаются
уделом человеческого, а не “машинного” интеллекта.
С другой стороны, в повседневной деятельности менеджеров
различных уровней, лиц, принимающих решения, можно выделить ряд типовых задач,
которые во многом могут быть переложены на плечи ЭВМ. Эти задачи носят
определенно интеллектуальный характер и требуют большого опыта и внимания при
своем решении.
Примерами таких задач могут быть: оценка и выбор оптимальных
проектных решений; оценка ситуации и выбор решения при управлении сложными
процессами; техническая и медицинская диагностика; прогнозирование
финансово-экономических параметров: доходности предприятия, курсов валют,
биржевых цен и т.п.; оценка кредитных и инвестиционных рисков; оценка сложных
объектов (типа объектов недвижимости) при их купле/продаже; подбор и
расстановка кадров.
В мире уже сегодня известно значительное количество программных
систем, предназначенных для решения указанных задач. В силу интеллектуального
характера решаемых ими задач, а также в силу того, что самим системам присущи
способность обучаться и объяснять свои решения, способность достичь высокого
качества формируемых решений, такие системы называют интеллектуальными.
Под этим общим названием в последнее время принято объединять
достаточно широкий круг программных продуктов. К ним относятся и экспертные
системы, и системы для численного обоснования принятия решения(decision support
systems), и системы для распознавания образов(текстов, изображения, речи), и
некоторые другие.
Постепенное накопление опыта, оттачивание теории и отладка
алгоритмов, позволили доказать в конце концов ощутимую эффективность
интеллектуальных программ, что привело в конце 80-х - начале 90-х годов к
резкому всплеску интереса к подобным программным продуктам, особенно к системам
способным решать финансовые и управленческие задачи. Процесс развития этого
направления продолжается и в настоящее время. Кроме этого, в программировании в
целом наметилась быстро развивающаяся тенденция к интеллектуализации. Так,
практически все популярные программные продукты в большей, или в меньшей степени
приобрели черты интеллектуальности. Запоминание действий пользователя,
подсказки и рекомендации по оптимальному использованию соответствующих режимов
самих программ, сложные ассоциативные поиски, оптимизация кода при
программировании, сложные механизмы обеспечения корректности данных при вводе и
хранении – вот неполный перечень признаков «поумнения» современных программных
средств. А это, в свою очередь, является немало важной предпосылкой дальнейшего
прогресса в разработке интеллектуальных систем(ИС).
Одной из базовых
проблем, при создании ИС, является выбор модели представления знаний [3, 5, 8,
14]. Именно модель представления знаний определяет архитектуру, возможности и
свойства системы, а также методы приобретения знаний ИС. Именно она, в конце
концов, определяет насколько система может называться интеллектуальной.
Суть проблемы представления знаний заключается в их формализации,
то есть в переводе их в символьное представление. В настоящее время известен
ряд базовых моделей представления знаний и их модификаций, это представление с
помощью фактов и правил, исчисления предикатов, нейронные сети, семантические
сети, фреймы. При построении ИС может быть использован любой из них, сам по
себе или в сочетании с другими. Каждая из моделей позволяет получить систему с
некоторыми преимуществами - делает ее более эффективной в конкретных условиях,
облегчает ее понимание и модификацию. При этом сопоставление различных моделей
представления знаний является сложной, слабо формализуемой задачей.
Сетевые интеллектуальные системы, являясь программными
продуктами, разработка которых сложна и требует больших временных и
материальных затрат, разрабатывались обычно на заказ крупными
исследовательскими центрами и организациями. Такие экспертные системы
во-первых, ориентированы на решение задач оценки в конкретной предметной
области; во-вторых, такие экспертные системы имели весьма высокую цену, что
ограничивало их широкое распространение; в-третьих, такие экспертные системы
предъявляли высокие требования к аппаратному обеспечению; и, наконец,
в-четвертых, они ограничивали число пользователей одновременно работающих в
системе.
Перечисленные недостатки могут быть существенно ослаблены и
даже устранены полностью на базе применения современных аппаратных и
программных технологий, рассмотренных выше.
Целью настоящей дипломной работы является разработка
структуры и алгоритмов взаимодействия программных блоков интеллектуальной
системы для оценки сложных объектов, построенной по принципу «клиент\сервер».
Поскольку проектирование всей системы - задача трудоемкая и под силу лишь
группе программистов, конкретно рассматривается проектирование одного из блоков
системы – блока управления данными и знаниями интеллектуальной системы,
построенной по принципу «клиент\сервер». Проектируемый блок обеспечивает такие
основные свойства системы как распределенность данных и знаний, параллелизм при
доступе и обработке данных, гибкость при настройке, надежность и корректность
всей информации.
Для достижения указанной цели необходимо решить следующие
задачи:
- проанализировать основные задачи, решаемые ИС в целом и ее
отдельными блоками: АРМ администратора системы, АРМ эксперта, АРМ лица
принимающего решения (руководителя), АРМ рядового оператора;
- разработать структуры данных и основные функции перечисленных
автономных рабочих мест и серверного блока;
- разработать порядок взаимодействия всех блоков системы;
- выполнить программную реализацию блока управления данными
и знаниями интеллектуальной системы.
Данная дипломная работа состоит из пояснительной записки и
графического материала. Пояснительная записка состоит из шести глав.
В первой главе проводится обзор современных интеллектуальных
систем, особое внимание уделено проблемам представления данных и знаний.
Рассматриваются различные модели представления знаний в известных системах,
предложена конструктивная классификация этих моделей по набору объективных параметров.
Во второй главе рассмотрены общие вопросы построения ИС для
задач оценки сложных объектов. Проведена формализация основных задач оценки.
Описываются модель представления знаний и основные блоки ИС. Рассматривается
специфика и принципы построения ИС по технологии «клиент\сервер».
В третей главе описана разработка блока управления данными и
знаниями в сетевой многопользовательской ИС. Представлены основные структуры
данных и алгоритмы, реализация сделана в среде программирования Borland Delphi
3.0 для операционной системы Microsoft Windows”95 и Windows NT.
В четвертой главе приводится описание применения интеллектуальной
системы, пользовательский интерфейс, а также контрольный пример.
В пятой главе рассматриваются вопросы экономики, производится
технико-экономический расчет.
В шестой главе рассматриваются вопросы охраны труда при
работе с персональными компьютерами.
Работа заканчивается Заключением, в котором сделаны основные
выводы об эффективности полученных результатов, рассмотрены возможные
направления развития данной работы.
1. ПРЕДСТАВЛЕНИЕ
ДАННЫХ И ЗНАНИЙ
В ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМАХ
С учетом данных, встречающихся в различных источниках, можно
предложить следующий перечень критериев оценки моделей представления знаний:
- уровень
сложности (абстрактности) элемента знаний с которыми работает модель;
- универсальность
представления знаний - возможность описать знания из различных предметных
областей;
- естественность и
наглядность представления знаний при использовании;
- способность
модели к обучению и формированию новых, непротиворечивых знаний;
- размерность
модели, по объему памяти, необходимому для хранения элемента модели;
- удобство
разработки системы на основе модели.
В настоящей главе,
на базе использования указанных критериев, сделана попытка анализа современных
моделей представления знаний, на основании которых возможна формализация и
разработка математических методов решения задач интеллектуальной обработки
данных.
1.1. Модель
представления знаний с помощью правил
Представление
знаний, основанное на правилах, построено на использовании выражений вида
ЕСЛИ (условие) - ТО (действие).
Когда текущая
ситуация (факты) в задаче удовлетворяет или согласуется с частью правила ЕСЛИ,
то выполняется действие, определяемое частью ТО [13, 15, 16, 17, 20, 22]. Это
действие может оказаться воздействием на окружающий мир или же повлиять на
управление программой (например, вызвать проверку и запуск некоторого набора
других правил), или может сводиться к указанию системе добавить новый факт, или
гипотезу в базу данных.
Сопоставление
частей ЕСЛИ правил с фактами может породить так называемую цепочку выводов -
дерево решений [22].
Один из главных
недостатков метода представления знаний с помощью правил это значительные
затраты времени на построение цепочки вывода.
В базу знаний
могут быть добавлены как новые факты, так и новые правила, сгенерированные
(продуцированные) программой [20]. Эти правила и факты становятся полноценными
участниками процесса нахождения дерева решений. В системе с продукцией правил
учитывается число прохождения каждого дерева решений. При достаточно большом
числе использования какого-либо дерева решений, система редуцирует («сжимает»)
дерево решений до нового правила и вводит его в базу знаний. Очевидно, что
правило такого рода имеет значительно большую размерность, чем исходные
правила.
Системы,
построенные на основе редуцированных деревьев решений более эффективны по
затратам памяти и по быстродействию, чем системы, которые основаны просто на
правилах [22]. Они дают результаты обладающие достаточно высокой достоверностью,
но не могут генерировать новые знания на уровне системы. Разработка таких
моделей в конкретных предметных областях, их модификация и развитие требуют
высокой квалификации разработчика.
Для таких систем
возможно обратное использование редуцированных правил. Зная решение X мы с
высокой достоверностью можем сказать, что к этому решению привел набор фактов M
& E & F.
По уровню
абстрактности элемента знаний, модель работает с простейшими составляющими
знания -- фактами и правилами.
Модель направлена
на решение простых, однородных по свойствам задач и приводит к резкому падению
эффективности решения таких проблем, которые состоят из нескольких разнородных
задач. Но даже если проблема является простой, не удается построить систему для
управления знаниями как единым целым, поэтому целиком весь процесс управления
должен осуществляться человеком. Серьезнейшим недостатком является невозможность
в рамках данной системы эффективно описать правила с исключениями.
В продукционных
системах выводы определяются для ограниченного формализма ЕСЛИ-ТО, поэтому
алгоритмы вывода хорошо формализованы, легко понимаемы и наряду со своей простотой
они достаточно точны.
Способности модели
к обучению невысоки. Формирование новых знаний возможно на уровне фактов и
правил. Приблизительный объем памяти, необходимый для хранения элемента знаний
модели – конструкции ЕСЛИ-ТО, мал в
силу его простоты. Однако база знаний, описывающая реальную, даже не очень
сложную задачу, должна содержать весьма значительное количество указанных элементов.
В известных системах [12, 23] количество правил, хранящихся в базе, исчисляется
сотнями и тысячами.
Существует ряд экспертных оболочек, для разработки ИС на
основе продукционной модели. Формирование базы знаний и экспертных правил носит
итерационных характер.
Первые ИС были
построены именно на основе модели представления знаний с помощью продукционных
правил. Несмотря на все недостатки данной модели, эти системы были очень эффективны
и продолжают использоваться и сегодня.
Одним из первых
был проект системы DENDRAL [23]. Исследовательская группа DENDRAL была создана
в Стенфордском университете в 1965 году для проектирования системы, помогающей
химикам делать заключения о структурах химических соединений на основании
масс-спектрометрических данных.
Не менее
известными экспертными системами, основанными на описанной модели, являются:
MYCIN, система для диагностирования бактериальных инфекций; INTERNIST --
система-консультант в области общей терапии.
Эффективность этих
ИС объясняется довольно просто. Продукционная модель накладывает ряд
ограничений на решаемую задачу, объем знаний и некоторые другие параметры ИС.
Создатели первых подобных систем строили их в рамках этих ограничений и
получили эффективные и удобные решения.
Каждая из выше
перечисленных ИС охватывает узкую и сравнительно хорошо определенную предметную
область. Система предназначается для решения одной и только одной задачи, но
решает эту задачу хорошо. Данный подход - ограничение предметной области и
круга задач ИС, хоть и выглядит как "метод шулера", но позволяет
построить эффективные системы.
Разработанные системы настолько понравились пользователям,
что были предприняты попытки применения данного подхода к другим областям
знаний с аналогичными свойствами. Из системы MYCIN была извлечена
проблемно-независимая часть в форме "пустой" (empty) системы MYCIN,
названной EMYCIN. Последняя была использована в ряде сложных областей,
например: при создании систем PUFF (обеспечение активной медицинской помощи при
респираторных заболеваниях); SACOM (расчеты механических структур); CLOT
(измерение состава крови) и т.д.
1.2. Модель
представления знаний с помощью логики
предикатов
Логика предикатов
является одним из разделов математической логики и иногда называется символьной
логикой [4, 21, 31, 34, 35].
Логика как система
конструируется из языка, называемого исчислением предикатов первого порядка,
ряда теорем, представленных в терминах этого языка и правил вывода. Теоремы
логики предикатов описывают отношения, закладываемые в базис логически полной
системы. Правила вывода из заданной группы представлений выводят представления,
отличающиеся от всех заданных представлений этой группы [16].
Основными
формализмами представления предикатов являются "терм",
устанавливающий соответствие знаковых символов описываемому объекту, и предикат
для описания отношения сущностей, в виде реляционной формулы, содержащей в себе
термы.
Например, Иван, Василий - это термы. Когда же между ними
имеется отношение "отец" и "ребенок", то это отношение описывается
как ОТЕЦ (ИВАН, ВАСИЛИЙ).
Предикат, все
термы которого являются термами-константами, называются высказыванием. Когда же
говорится "предикат", то обычно имеется в виду, что в него входит
терм-переменная. Например, таким предикатом является ОТЕЦ (X,Y). Если в предикате
обеспечена возможность применения естественного языка, то он соответствует
предложению в наиболее простой его форме. Исходя из этой формы, задаются
специальные символы и синтаксические правила для определения предикатных
формул, соответствующих обычному предложению. Например, таким предложением
является
ОТЕЦ(ИВАН,
ВАСИЛИЙ) & МАТЬ (МАРИЯ, ВАСИЛИЙ) (отцом Василия является Иван, а матерью
Василия является Мария) или (существует Х [ЧЕЛОВЕК (Х) -> СМЕРТЕН (Х)] (если
субъект является человеком, то он смертен -> все люди умирают).
Обратим внимание
[13], что последний пример похож на продукционное правило. Сходство с
продукционными правилами следует из того, что в логике предикатов тоже
разрешаются формулы, которые задают соответствующее представление в форме ЕСЛИ
- ТО, допуская объединение нескольких описаний в составе условия ЕСЛИ и
заключения ТО, а формулы с подобной упорядоченностью описаний также являются
объектом логики предикатов [21].
По уровню
абстрактности элемента знаний, модель работает с простейшими составляющими
знания - фактами и правилами. Логика предикатов позволяет получить единую
систему представлений, в которой знания рассматриваются как единое целое -
описание конкретной предметной области.
Модель достаточно
универсальна, однако, также, как и модель представления знаний с помощью фактов
и правил, не может быть использована для создания ИС, которые должны одновременно
манипулировать специальными знаниями из разных предметных областей.
Способности модели
к обучению находятся на среднем уровне. Формирование новых знаний возможно на
низшем уровне абстрактности - на уровне фактов и правил. Алгоритмы вывода
хорошо формализованы в соответствии с правилами вывода. С помощью логики
предикатов можно, определяя произвольным образом знания, выяснить, имеются или
отсутствуют противоречия между новыми и уже существующими знаниями. Возможно
применение процедур вывода по умолчанию [21].
Приблизительный
объем памяти, необходимый для хранения элемента знаний модели – предиката или
предикатной формулы, мал в силу его
простоты. Однако, также как и в случае просто фактов и правил, база знаний,
описывающая реальную, даже не очень сложную предметную область, должна
содержать весьма значительное количество указанных элементов.
Модель часто
применяется в промышленных ИС. Она привлекает разработчиков высокой
модульностью, легкостью внесения дополнений и изменений в систему и простотой
механизма логического вывода.
Одна из первых
достаточно эффективных ИС была создана Хаммондом и Серготом [35]. В их системе
устройство Query-the-User комбинируется с оболочкой экспертных систем (APES).
Система реализована на микро-Прологе и дает очень гибкий инструмент, называемый
APE-the-User и предназначенный для построения экспертных систем.
В системе
предусмотрены также средства для структурирования запросов на естественном
языке. Сочетание всех этих возможностей образует благоприятную универсальную
среду для построения, модификации и эксплуатации экспертных систем.
Система APES была
с успехом использована для автоматизации юридических экспертных систем. Хаммонд
[34] описывает, например, как в сотрудничестве с министерством здравоохранения
и социального обеспечения в базе знаний системы APES были собраны более двухсот
инструкций, регулирующих норму дополнительного пособия. В более широких
масштабах и при наличии гораздо больших юридических и лингвистических сложностей
система APES была использования для кодирования принятого в 1981 г. закона о
гражданстве Великобритании, который определяет категории британского
гражданства и включает правила, предназначенные для своей же собственной
интерпретации.
1.3. Модель
представления знаний с помощью сетей нейронов
Начало современным
моделям нейронных сетей было положено в работе Маккаллока и Питтса [40], где
авторы сделали первую попытку эмулировать человеческие способности классифицировать
и распознавать образы. В их формализме нейроны имеют состояния 0, 1 и пороговую
логику перехода из состояния в состояние. Каждый нейрон в сети определяет
взвешенную сумму состояний всех других нейронов и сравнивает ее с порогом,
чтобы определить свое собственное состояние. Дальнейшее развитие связано с тем,
что Розенблат ввел в модель Маккаллока и Питтса способность связей к
модификации, что сделало ее обучаемой. Эта модель была названа персептроном
[10, 44, 45].
Новый виток
быстрого развития моделей нейронных сетей, который начался 9-10 лет тому назад,
связан с работами Амари, Андерсона, Карпентера [30], Кохена [28, 30, 32] и других,
и в особенности, Хопфилда [19, 37, 38, 39], а также под влиянием обещающих
успехов оптических технологий [1, 29] и зрелой фазы развития СБИС [32] для
реализации новых архитектур.
В основу
искусственных нейронных сетей положены следующие черты живых нейронных сетей,
позволяющие им хорошо справляться с нерегулярными задачами:
- простой
обрабатывающий элемент - нейрон;
- очень большое
число нейронов участвует в обработке информации;
- один нейрон
связан с большим числом других нейронов (глобальные связи);
- изменяющиеся по
весу связи между нейронами;
- массированная
параллельность обработки информации.
Основная их черта
- использование взвешенных связей между обрабатывающими элементами как
принципиальное средство запоминания информации. Обработка в таких сетях ведется
одновременно большим числом элементов, благодаря чему они устойчивы к
неисправностям и способны к быстрым вычислениям.
Задать нейронную
сеть, способную решить конкретную задачу, это значит определить модель нейрона,
топологию связей, веса связей. Нейронные сети, предназначенные для решения
различных задач, отличаются друг от друга менее всего моделями нейрона, а в
основном топологией связей и правилами определения весов или правилами
обучения.
По структуре
связей сети делятся на два больших класса: однослойные и многослойные. К
однослойным относятся модель Хопфилда [1, 19, 26, 37, 38, 39] и последующие
разработки [33], некоторые типы модели нейронной сети, известной под названием
"машина Больцмана" [24, 25]. Многослойная сеть имеет входной,
выходной и скрытые слои, на входной подается информация, с выходного снимается
ответ, скрытые слои участвуют в обработке [27].
Подходы к обучению
однослойных и многослойных сетей различны. В однослойных часто удается выразить
веса связей через параметры задачи (так обстоит дело с моделью Хопфилда и
однослойной машиной Больцмана). Обучение многослойных сетей состоит в том, что
на основе набора примеров {входное состояние -> выходное состояние}
постепенно подбираются веса всех связей так, чтобы каждое входное состояние
вызывало соответствующее выходное. Обучающие алгоритмы представляют собою
итерационные процедуры с постепенным приближением к окончательным значениям
весов связей.
Начало
современному математическому моделированию на базе нейронных вычислений было
положено работами Хопфилда [37], в которых была предложена математическая
модель ассоциативной памяти на нейронной сети [36]. Но не столько сама модель
послужила главным толчком к появлению работ других авторов на эту тему, сколько
введенная Хопфилдом функция вычислительной энергии нейронной сети. Это аналог
функции Ляпунова в динамических системах. Показано, что для однослойной нейронной
сети со связями типа "каждый с каждым" характерна сходимость к одной
из конечного множества равновесных точек, которые являются локальными
минимумами функции энергии. Понимание такой динамики нейронной сети было и у
других исследователей [32]. Однако Хопфилд и Тэнк показали, как конструировать
функцию энергии для конкретной оптимизационной задачи и использовать ее для
отображения задачи в нейронную сеть [38, 39]. Этот подход получил развитие и
для решения других комбинаторных оптимизационных задач [33]. Привлекательность
подхода Хопфилда состоит в том, что нейронная сеть для конкретной задачи может
быть запрограммирована без обучающих итераций. Веса связей вычисляются на
основании вида функции энергии, сконструированной для этой задачи.
Развитием модели
Хопфилда для решения комбинаторных оптимизационных задач и задач искусственного
интеллекта является машина Больцмана, предложенная Хинтоном и другими [27] и
далее исследованная в [24, 25]. В ней, как и в других моделях, нейрон имеет
состояния 1, 0 и связь между нейронами обладает весом. Каждое состояние сети
характеризуется определенным значением функции консенсуса (аналога функции энергии).
Максимум функции консенсуса соответствуют оптимальному решению задачи.
Итак, в рамках данного подхода элементом знания является
состояние сети -- вектор состояний всех нейронов сети. Это можно считать
средним уровнем абстрактности представления знаний. Для решения конкретной
задачи необходимо организовывать сети со значительным числом нейронов.
Небольшой объем памяти, необходимый для хранения нейрона позволяет эффективно
пользоваться такими сетями.
Основными
преимуществами нейросетей является их высокая адаптивность, а также их
способность к обработке зашумленной и неполной информации.. Однако переобучение
или дообучение сети затрагивает только значения весовых коэффициентов на межнейронных соединениях. Создание же
алгоритма обучения, так же как и проектирование структуры сети, являются творческими
задачами, выполняемыми специалистами высокой квалификации для конкретных задач.
Данный недостаток серьезно затрудняет создание ИС на основе нейронных сетей.
Еще один недостаток нейронных сетей - ненаглядность
представления знания – образы, запомненные сетью при обучении, закодированы в
виде состояний всех нейронов сети, а процесс принятия решения в сети не может
быть представлен в виде наглядных конструкций ЕСЛИ - ТО.
Модель может применяться для решения задач распознавания
образов в практически любой предметной области. Широкое применение нейронные
сети нашли при решении задач прогнозирования сложных процессов.
Так, по заказу
Chemical Bank (США) фирма Logica разработала и внедрила систему для
прогнозирования динамики биржевых курсов. На технической базе Sun SPARCstation
LX с помощью аппарата нейронных сетей моделировались рынки валютных курсов
доллар/швейцарский франк и немецкая марка/швейцарский франк. Выбор именно этих
валют объяснялся высоким уровнем подвижности первого соотношения и малым - второго.
Данные о динамике кросс-курсов этих валют собирались с 1 октября 1992 года по 1
сентября 1993, при этом ценовые прогнозы выражались пятью значениями: большой
рост, малый рост, без изменений, малый спад, большой спад. В итоге был достигнут
высокий процент достоверности прогноза около 60%.
Mellon equity
Associates -- подразделение Mellon Bank в Питсбурге(США) - внедрила у себя
систему Neural-Works Professional II /Plus 5.0 фирмы Neural-Ware. Эта система
ориентирована на IBM-совместимые компьютеры. Пакет внедрялся около 4-5 мес.
Основные решаемые задачи: распределение фондов и специальная селекция акций.
Группа
специалистов по заказу департамента торговли и индустрии правительства
Великобритании создала систему для выработки тактики распределения фондов на
глобальных рынках облигаций. С ноября 1992 года эта система внедрялась в Североамериканской
страховой компании в Бостоне (США). В итоге капитал этой компании быстро
увеличился с 25 до 50 млн. долл., а портфель ценных бумаг показал доходность
свыше 25% в первый же год внедрения системы.
Нейронные сети могут быть реализованы как программно, так и
аппаратно. В настоящий момент на компьютерном рынке предлагается весьма широкий
спектр аппаратных средств, обладающих различными функциями, возможностями и
естественно ценой [13, 27].
В качестве типичного примера нейроплаты можно назвать плату
МВ 86232 японской фирмы Fujitsu. На плате размещены процессор цифровой
обработки сигналов и оперативная память емкостью 4 Мбайт, что позволяет
использовать такую плату для реализации нейронных сетей, содержащих до тысячи
нейронов.
Среди разрабатываемых в настоящее время нейроБИС, которых
насчитывается несколько десятков типов, выделяются модели фирмы Adaptive
Solutions (США) и Hitachi (Япония). НейроБИС фирмы Adaptive Solutions, вероятно,
станет одной из самых быстродействующих: объявленая скорость обработки
составляет 1,2 млрд. соединений в секунду. (нейронная сеть содержит 64 нейрона
и 262144 соединения). НейроБИС фирмы Hitachi позволяет реализовать нейронную
сеть, содержащую до 576 нейронов. Эти нейроБИС, несомненно, станут основой
новых нейрокомпьютеров и специализированных многопроцессорных изделий.
Большинство сегодняшних нейрокомпьютеров представляют собой
просто персональный компьютер или рабочую станцию, в состав которых входит дополнительная
нейроплата. К их числу относятся, например, компьютеры серии FMR фирмы Fujitsu.
Такие системы имеют бесспорное право на существование, поскольку их
возможностей вполне достаточно для разработки новых алгоритмов и решения
большого числа прикладных задач методами нейроматематики. Однако наибольший
интерес представляют специализированные нейрокомпьютеры, непосредственно
реализующие принципы нейронных сетей. Типичными представителями таких систем
являются компьютеры семейства Mark фирмы TRW (первая реализация персептрона,
разработанная Розенблатом, называлась Mark I). Модель Mark III фирмы TRW
представляют собой рабочую станцию, содержащую до 15 процессоров семейства
Motorola 68000 с математическими сопроцессорами. Все процессоры объединены
шиной VME. Архитектура системы, поддерживающая до 65 000 виртуальных
процессорных элементов с более чем 1 млн. настраиваемых соединений, позволяет
обрабатывать до 450 тыс. межсоединений в секунду. Mark IV - это
однопроцессорный суперкомпьютер с конвейерной архитектурой. Он поддерживает до
236 тыс. виртуальных процессорных элементов, что позволяет обрабатывать до 5
млн. межсоединений в секунду. Компьютеры семейства Mark имеют общую программную
оболочку ANSE (Artificial Neural System Environment), обеспечивающую программную
совместимость моделей. Другой интересной моделью является нейрокомпьютер
NETSIM, созданный фирмой Texas Instruments на базе разработок Кембриджского
университета. Его топология представляет собой трехмерную решетку стандартных
вычислительных узлов на базе процессоров 80188.
1.4. Модель
представления знаний с помощью семантических сетей
Семантическая сеть
состоит из точек, называемых узлами, и связывающих их дуг, описывающих
отношения между узлами [2, 18]. Узлы в семантической сети соответствуют
объектам, концепциям или событиям. Дуги могут быть определены разными методами,
и описывают отношения между рассматриваемыми объектами. Обычно дуги,
используемые для представления иерархии, включают дуги типа IS-A (отношение
«является») и HAS-PART (отношение «имеет часть»). Эти отношения также
устанавливают иерархию наследования в сети. Это означает, что элементы более
низкого уровня в сети могут наследовать свойства элементов более высокого
уровня. Это экономит память, поскольку информацию о сходных узлах не нужно
повторять в каждом узле сети.
Выводы на
семантических сетях реализуются через отношения между элементами, однако они
таят в себе угрозу возникновения противоречий [2].
Семантические сети
позволяют пpедставлять весьма сложные совокупности объектов и отношений. Пpи
этом элементом знания становится сам объект и отношения к нему дpугих объектов.
Модель достаточно
универсальна и легко настраивается на конкретную предметную область. Каждое
отдельное знание рассматривается как некое отношение между сущностями и понятиями.
Следовательно, определенные заранее и уже существующие внутри системы знания
можно наращивать независимо, с сохранением их модульности.
Из-за того, что форма представления знаний в семантической
сети не задается жестко, для каждого конкретного формализма будут определены
свои собственные правила вывода, поэтому усиливается элемент произвольности и
субъективности, вносимый человеком при настройке на конкретную предметную область.
Характерная
особенность семантической сети -- наглядность знаний как системы.
Семантические сети
нашли широкое распространение при моделировании каузальных знаний. Узлы сети
представляют состояние системы, а дуги - каузальные отношения. На основе
данного подхода семантические сети были применены в качестве основной формы
представления знаний в системе CASNET (Caysal Associational NETwork),
разработанной в первой половине 70-х Куликовским и Вейссом из Рутгерского
университета [23]. Система создавалась с целью разработки и исследования
стратегий диагностирования с помощью компьютерных систем, в основу которых
положены психологические и функциональные модели болезней.
В системе CASNET
заболевание рассматривается как процесс, включающий переходы от одного
патофизиологического состояния к другому. В результате этого диагноз
определяется как идентификация взаимосвязи между картиной каузальных маршрутов,
свойственных пациенту, и категорией заболевания.
Также на основе
семантических сетей была разработана известная система PROSPECTOR [23],
предназначенная для оказания помощи геологам-изыскателям. Она способна давать
три типа "советов": оценку местности на предмет существования определенных
залежей, оценку геологических ресурсов региона и выбор участков местности,
наиболее благоприятных для бурения. Эта программа была создана компанией SRI
International (совместно с консультантами по геологии) и организацией U.S.
Geological Survey.
Серьезным
недостатком систем CASNET и PROSPECTOR является их неудовлетворительная
способность объяснить свои решения.
1.5. Модель
представления знаний с помощью фреймов
В области
искусственного интеллекта термин "фрейм" относится к специальному
методу представления общих концепций и ситуаций. Марвин Минский, первый, кто
предложил идею фреймов, описывает его следующим образом [9]: "Фрейм - это
структура данных, представляющая стереотипную ситуацию, вроде нахождения внутри
некоторого рода жилой комнаты, или сбора на вечеринку по поводу рождения
ребенка. Каждому фрейму присоединяются несколько видов информации. Часть этой
информации - о том, как использовать фрейм. Часть о том, чего можно ожидать
далее. Часть о том, что следует делать, если эти ожидания не
подтвердятся".
Фрейм по своей
организации во многом похож на семантическую сеть. Фрейм является сетью узлов и
отношений, организованных иерархически, где верхние узлы представляют общие
понятия, а подчиненные им узлы более частные случаи этих понятий. В системе,
основанной на фреймах, понятие в каждом узле определяется набором атрибутов
(например, имя, цвет, размер) и значениями этих атрибутов (например, Иван,
красный, маленький), атрибуты называются слотами. Каждый слот может быть связан
со специальными процедурами, которые выполняются, когда информация в слотах
(значения атрибутов) меняется. С каждым слотом можно связать любое число
процедур.
Описание некоторой
предметной области в виде фреймов обладает высоким уровнем абстрактности.
Фреймы, как элементы знаний, являются весьма сложными
структурно-функциональными образованиями, которые еще могут и объединяться в
сеть, т.е. устанавливать между собой не менее сложные связи и отношения.
Фреймовая система не только описывает знания, но и позволяет человеку описывать
метазнания – т.е. правила и процедуры обработки знаний, выбора стратегий, приобретения
и формирования новых знаний. С точки зрения специалиста, который очень хорошо
разбирается в обработке знаний, это выглядит преимуществом, однако для рядового
пользователя ИС -- это большая нагрузка.
Модель является
достаточно универсальной, поскольку существуют не только фреймы для обозначения
объектов и понятий, но и фреймы-роли (отец, мать, начальник, пешеход), фреймы-ситуации
(тревога, авария, рабочий режим устройства) и др.
Представление
знаний с помощью фреймов обладает наглядностью и интуитивно понятно. Однако при
усложнении задачи фреймовая система быстро усложняется, что, естественно, сильно
снижает наглядность ее функционирования.
Обучение фреймовых
систем затруднено. Приобретение новых знаний в модели возможно только в
системах со сложной структурой фреймов. Создание таких систем требует серьезных
затрат времени и средств, но эти системы позволяют приобретать новые знания на
уровне понятий. При этом проблема устранения противоречивых знаний должна
решаться самой системой.
Для хранения
элемента модели требуются значительные объемы памяти, определяемые сложностью
конкретного фрейма.
Создание фреймовых
систем является сложной и кропотливой работой. Изменение и модификация такой
системы требует привлечения разработчиков и, даже при выполнении этого условия,
является процессом, по трудоемкости сравнимым с созданием новой системы.
Одной из наиболее
известных ИС, построенных на основе фреймов, является система MOLGEN [20, 23].
Система MOLGEN предназначена для планирования экспериментов в области
молекулярной генетики. Необходимо отметить, что речь идет о планировании, а не
о решении аналитических задач. Т.е. невозможно полностью описать цель задачи
перед началом ее решения. При такой постановке вопроса редуцировать
пространство поиска с помощью простых методов не представляется возможным.
В настоящее время
концепция фреймов быстро развивается и расширяется благодаря развитию методов
объектно-ориентированного программирования [№№№№№№ ]. Практически во всех
современных языках программирования появились специальные
структурно-функциональные единицы (объекты, классы), обладающие основными
признаками фреймов. Таким образом модель представления знаний на базе фреймов
является сейчас весьма распространенной.
1.6. Cистемы
«клиент\сервер» и общая организация данных в них
Для начала расшифруем некоторые аббревиатуры, широко используемые
разработчиками:
ODBC (Open DataBase Connectivity) - открытый стандарт
совместимости баз данных;
CASE-технология (Computer-Aided Software/System Engineering)
- компьютерная разработка программ и систем;
SQL (Structure Query Language) - язык структурных запросов.
Уже само понятие "архитектура «клиент-сервер»"
трактуется разработчиками по-разному. Все сходятся лишь в одном: для
организации вычислительного процесса при распределенной обработке данных
желательно использование архитектуры «клиент-сервер». Так, фирма R-Style
Software Lab определяет архитектуру «клиент-сервер» как модель взаимодействия
компьютеров и процессов в сети (классификацию моделей рассмотрим ниже).
Для фирмы "Диасофт" утверждение, что некоторая
информационная система имеет архитектуру «клиент-сервер», означает, что
прикладная составляющая этой системы имеет распределенный характер и состоит из
двух взаимосвязанных компонент, одна из которых (клиент) формирует и посылает
запросы высокого уровня другой компоненте (серверу), задача которой состоит в
обслуживании этих запросов.
Юрий Зиссер ("Надежные программы", Минск) считает,
что в последнее время термин "клиент-сервер", к сожалению, девальвировался
и стал применяться по отношению к любым локально-сетевым технологиям. Минской
фирмой под архитектурой «клиент-сервер» понимается такая организация
вычислительного процесса, при которой вся обработка происходит в основном на
персональном компьютере, обращающемся с SQL-запросами к серверу, где содержатся
общие базы данных. По сети циркулируют только SQL-запросы/ответы (а не
фрагменты или отдельные записи СУБД, как в архитектуре файл-сервер), благодаря
чему резко снижается нагрузка на сеть. Обработка данных при этом более равномерно
распределяется между клиентом и сервером.
Самое примечательное свойство архитектуры «клиент-сервер»
состоит в возможности удалить клиента от сервера на любое расстояние без
существенного снижения скоростных характеристик системы (даже в случае сложных
запросов) и без всяких изменений в программном обеспечении. Удаленный клиент
подключается к серверу с помощью телефонного или иного канала. Это свойство
очень ценно для организации распределенной обработки данных. Кроме того, оно
позволяет заменять СУБД, операционную систему и сервер, не изменяя программного
обеспечения клиентской части системы.
Обычно выделяются три модели взаимодействия клиента и
сервера:
RDA (Remote Data Access), в которой компонента представления
(пользовательский интерфейс) и прикладная компонента (логика работы программы)
совмещены в клиентской части, а компонента доступа к информационным ресурсам
(данным) размещена в серверной части.
DBS (DataBase Server), в которой компонента представления
размещена в клиентской части, а прикладная компонента и доступ к информационным
ресурсам - в серверной;
AS (Application Server), в которой компонента представления
находится в клиентской части, прикладная компонента - в "сервере
приложения", а компонента доступа к информационным ресурсам - в
"сервере базы данных".
Рассмотрим другую, более детальную классификацию архитектур
(по методике Garthner Group). Пользовательский интерфейс (компонента
представления) может быть размещен в серверной части, тогда получается модель
хост-терминал, которая является предельным случаем архитектуры «клиент-сервер».
Другим предельным случаем (вырожденным) являются автономные вычисления на одном
компьютере, когда все данные, логика работы (прикладная компонента) и
пользовательский интерфейс сосредоточены в клиентской части. Учтем также, что и
прикладные компоненты (логика работы), и сами данные могут быть по-разному
распределены между клиентской и серверной частями. Кроме того, серверов
приложений может быть несколько.
Системы с архитектурой «клиент-сервер» могут быть двух- или
трехуровневыми.
Система является двухуровневой, если она построена с использованием
набора прикладных клиентских программ, имеющих общий доступ к ресурсам системы
и работающих с сервером базы данных или SQL-сервером. Прикладная программа
может при этом размещаться как в клиентской, так и в серверной частях в виде
хранимых процедур, триггеров и правил.
Система является трехуровневой, если она содержит три
следующие самостоятельные компоненты:
интерфейс пользователя, в функции которого входят только
отображение (вывод) результатов и взаимодействие с пользователем;
сервер приложения, в котором сосредоточены все
бизнес-функции, правила и/или хранимые процедуры;
сервер базы данных (в большинстве случаев - SQL-сервер
СУБД), он же - менеджер ресурсов.
Легко видеть, что трехуровневая система относится к модели
AS.
Такая система строится с использованием промежуточного
программного обеспечения (чаще всего - монитора транзакций), причем прикладная
логика переносится из клиентских программ в отдельный от СУБД сервер
приложений. Подробнее об отличиях и областях применения двух- и трехуровневой
архитектур будет сказано ниже.
Сегодня пропагандируется мнение, что самым лучшим и даже
чуть ли не единственно правильным вариантом архитектуры «клиент-сервер»
является SQL-сервер. Однако в этом варианте клиент не имеет непосредственного
навигационного доступа к записям в базе данных, а посылает серверу запросы на
языке SQL и получает от него множества записей, удовлетворяющих запросу. При
больших и сложных запросах такая архитектура действительно резко сокращает
сетевой трафик и позволяет существенно повысить производительность. Современные
версии SQL-серверов стараются использовать архитектуру SuperServer, когда всем
сервером управляет один процесс, а для обслуживания клиентов, выполнения
запросов и других задач создаются потоки (threads). Безусловно, такая
архитектура применительно к SQL-серверам имеет преимущества:
Увеличение производительности при тех-же характеристиках
сервера
Использование общего кэша при операциях ввода-вывода
Меньший объем используемой памяти
Большее количество обслуживаемых пользователей при том-же
объеме памяти
и недостатки
меньшая защищенность сервера при внутренних сбоях
Последний пункт относится ко всем SQL-серверам, имеющим
архитектуру SuperServer. Действительно, все потоки (threads) находятся в одном
адресном пространстве, и любой сбой может привести к "падению"
SQL-сервера.
Однако повседневная работа пользователей современных
приложений, особенно банковских, состоит в основном не в исполнении мудреных
запросов, а в проведении таких элементарных операций, как ввод записи,
редактирование записи, поиск записи по ключу и пролистывание массива записей на
экране. Операции такого рода выполняются SQL-сервером отнюдь не быстрее, чем
традиционными СУБД с навигационным способом доступа, а пролистывание вообще
сопряжено с массой трудностей. Здесь опять возникают проблемы инструментария,
ведь, пожалуй, только СУБД Progress содержит все необходимые компоненты разработки,
так как наряду с языком SQL предоставляет и средства навигационного доступа к
записям БД на низком уровне.
Из сказанного отнюдь не следует, что язык SQL не нужен или
вреден. Для определенного круга задач он очень удобен, но далеко не для всех. В
том, что этот язык не в состоянии удовлетворить многие потребности современных
пользователей, нет ничего удивительного: хотя он часто выдается за новейшую технологию,
на самом деле он был разработан десятки лет назад, в эпоху пакетной обработки
данных, когда потребители данных общались с компьютерами через операторов,
передавая им свои запросы и получая в ответ распечатки. Естественно, технология
обработки данных и взаимоотношения человека с компьютером с тех пор сильно
изменились, что потребовало разработки более современных языков доступа к
данным.
В качестве общего вывода к данной части обзора можно сказать
следующее. Архитектура «клиент-сервер», минимизируя сетевой трафик,
максимизирует нагрузку на сервер. Поэтому целесообразность применения этой
архитектуры зависит от того, какой элемент системы является узким местом.
ВЫВОДЫ
Для того, чтобы
упорядочить взгляд на модели представления знаний можно предложить их
классификацию в соответствии с уровнем сложности (абстрактности) элемента
знаний, которыми манипулирует модель. Исходя из этого рассмотренные выше модели
выстраиваются в иерархию, изображенную на рисунке.
Рис. 1. Иерархия моделей представления знаний
В нижней
«половине» иерархии расположены модели, которые обладают простотой элемента
знаний. Это приводит к высокой размерности описания реальной предметной
области, расчеты становятся громоздкими, решение -- ненаглядным. Все это
приводит к тому, что ИС, основанные на таких моделях, при решении реальных
задач теряют управляемость. В верхней «половине» иерархии находятся модели,
которые используют сложные, функционально загруженные элементы знаний. Это
приводит к тому, что между элементами возникают многообразные связи и отношения,
что предъявляет высокие требования к разработчику модели. Модификация таких
систем чрезвычайно затруднена.
В соответствии с предложенной классификацией можно сказать,
что, несмотря на различия, описанные модели не противоречат друг другу.
Предложения логики предикатов, например, имеют много общего с продукционными
правилами. По существу, интерпретируя правила продукции как предложение логики
предикатов, можно без каких-либо затруднений заменить его на предикаты. При
таких действиях выражение ОТЕЦ (ИВАН, ВАСИЛИЙ), которое описано предикатной
формулой, соответствует отношению ИВАН - ОТЕЦ - ВАСИЛИЙ в семантической сети. В
общем случае каждую дугу семантической сети можно задать предикатами как
отношения между сущностями, которые описывают узлы на концах дуги.
Передаточную функцию нейрона также можно представить в виде
решающих правил и предикатов, а некоторый фрейм разложить на факты и правила.
Однако при этом каждая из известных моделей представления
знаний обладает, как минимум тремя недостатками из списка, приведенного ниже:
- недостаточный
универсализм;
- сложность
получения новых знаний;
- возможность
получения противоречивых знаний;
- сложность
наращивания модели;
- значительная
размерность модели;
- отсутствие
наглядности в представлении знаний..
Именно поэтому в последнее время все большее значение в
инженерии знаний придается сочетанию разных моделей представления знаний. Все
больше создается ИС, основанных на таких, казалось бы несовместимых подходах,
как нейронные сети и фреймы, семантические сети и логика предикатов и т.п. Учитывая
все выше сказанное, можно сделать вывод о высокой актуальности исследований в
этой области, а также разработки новых подходов.
2. АРХИТЕКТУРА
ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМ (ИС) ДЛЯ ОЦЕНКИ СЛОЖНЫХ ОБЪЕКТОВ
В данной главе
дается постановка задачи на проектирование подсистемы управления данными,
описывается модель представления знаний, рассматриваются вопросы проектирования
структур данных и алгоритмов их обработки.
2.1. Постановка задачи оценки сложных объектов.
Описание представления знаний.
Исходя из того, что оценочная модель была предопределена в
техническом задании на разработку универсальной экспертной системы, приведем
здесь лишь краткое ее описание.
В рамках реализуемой модели оцениваемые объекты представляются
в виде множества S - свойств объектов. Заметим важную деталь - множество S
является объединением непересекающихся множеств N и E - соответственно множеств
численных и перечислимых свойств. Каждое перечислимое свойство Ei может
принимать значение из определенного конечного множества значений. Каждое
численное свойство Ni может принимать значения лежащие о области действительных
чисел, ограниченной минимальным и максимальным пределами Nimin Nimax
соответственно. Введением такого деления мы фактически даем возможность системе
учесть как количественные (численные), так и качественные (перечислимые)
характеристики объекта.
Задачи, решаемые универсальной экспертной системой, делятся
на два вида - задачи квалиметрии (оценки качества) и классификации
(распознавания образов). В процессе решения задачи квалиметрии каждому
оцениваемому объекту ставится в соответствие число I - являющееся оценкой
данного объекта. В процессе решения задачи классификации каждому объекту ставится
в соответствие наименование класса к которому относится данный объект.
В рамках конкретной оценочной задачи к оцениваемым объектам
предъявляются требования из множества T, а также устанавливаются соответствия F
между свойствами и требованиями. При этом одно требование может ссылаться на
несколько свойств. Например, в задаче оценки объекта недвижимости (например
квартиры), требование “удобная квартира” ссылается на свойства “район”, “этаж”,
наличие телефона”, поскольку эти свойства и определяют удобство квартиры.
Вообще, смысл введения требований, как инструмента, используемого для
адекватной оценки объекта следующий: требования выражают цель субъекта оценки
при решении конкретной оценочной задачи; свойства же, являясь описанием,
представлением объекта оценки, вообще говоря существую достаточно независимо от
решаемой задачи. Конкретную окраску свойства получают лишь с точки зрения
системы требований, предъявленной субъектом оценки.
Кроме того в задаче классификации формируется множество C -
множество классов. В задаче квалиметрии каждому требованию из множества T
ставится в соответствие вес (значимость) этого требования. В задаче
классификации каждому требованию ставятся в соответствие n весов, где n -
количество классов. В этом случае Pij - это вес (значимость) i-го требования из
множества T в j-ом классе из множества C. А все множество P - называется
множеством весов (весовых коэффициентов). Кроме этого в задаче квалиметрии для
каждого элемента из множества F - соответствий требования и зависимых от него
свойств задается т.н. дуговой весовой коэффициент, значение которого определяет
значимость конкретного свойства в рамках конкретного требования. Например, при
оценке компьютеров требованию “быстродействие” соответствуют свойства - “тип
процессора”, “тактовая частота”, “тип системной шины”. При этом тип процессора,
например, вносит в быстродействие компьютера больший вклад, чем тип системной
шины. Соответственно дуговой коэффициент свойства “тип процессора” в рамках
требования “быстродействие” будет больше, чем коэффициент свойства “тип
системной шины” в рамках того же требования, ввиду того, что тип процессора
вносит больший вклад в быстродействие системы, чем тип системной шины. При
решении задачи классификации в соответствие каждому элементу множества F
ставятся в соответствие n коэффициентов, где n - количество классов, определяющих
значимость свойства в пределах данного требования для данного класса из
множества C. Полученное таким образом множество D - называется множеством
дуговых весовых коэффициентов.
После формулировки множества требований можно говорить о
формировании следующего множества E - множества эталонов. Эталон как идеал
может в действительности не существовать, но для принятия решения он должен
быть задан. Причем, в рамках описываемой модели эталон - это вовсе не эталон в
общепринятом смысле этого слова. Эталон с точки зрения модели не только несет
информацию об идеальном значении того или иного свойства, но и о том на сколько
все остальные значения данного свойства “хороши” с точки зрения предъявленных
требований к объекту оценки. Элементом Ei множества E - является функция
V=fi(Si). Эта функция выражает то, насколько конкретное значение свойства Si удовлетворяет
задаче (повышает оценку). Значения же этой функции лежат в пределах нуля и
единицы. Если значение функции равно единице, то значение свойства полностью
удовлетворяет задаче и повышает общую оценку объекта в соответствие с весом
этого свойства в рамках требований и требований в рамках всей модели (т.е. с
учетом дуговых коэффициентов и весовых коэффициентов). Напротив, если значение
функции равно нулю, то данное значение не удовлетворяет данной задаче и
свойство не вносит вклада в общую оценку объекта. Очевидно, что функция эта
непрерывна, если свойство Si численное и имеет n значений, если свойство Si
перечислимое (где n - количество исходов i-го свойства). Для повышения эффективности
оценивания, в оценочную модель вводится т.н. бинарный вектор критичности K.
Если значение элемента вектора критичности Kij равно 1 то j-е свойство критично
в i-ом требовании. Это означает, что если значение j-го свойства конкретного
объекта имеет в рамках задачи меру выраженности равную 0, то объект заведомо
получает оценку равную 0 - низшую оценку. Вектор критичности вносит в модель
элемент логики предикатов, поскольку позволяет отсечь объекты, заведомо не
удовлетворяющие условиям задачи.
Таким образом, в задаче квалиметрии оценочная модель
представляет собой кортеж:
M<S,T,P,D,E,F,K>
а в задаче классификации:
M<S,T,P,D,E,C,F,K>.
Вышеописанных данных достаточно для принятия решения поставленной
оценочной задачи (классификации или квалиметрии). Причем в такой модели
существуют возможности для достаточно тонкого анализа принятого решения и
достаточно тонкой настройки системы. Несомненным достоинством модели является
ее универсальность. Действительно, модель так как она сформулирована здесь
инвариантна к предметной области, перечню свойств, другим ограничивающим
условиям.
Исходя из вышеизложенного, задача выглядит следующим образом.
Необходимо сформировать структуры данных, хранящие информацию о составных
частях модели (множествах S, T, P, D, E, C и их составляющих). Структуры данных
должны быть как внутренними (пригодными для использования другими программными
модулями экспертной системы) так и внешними (пригодными для хранения на внешних
носителях). Кроме того необходимо разработать механизмы формирования и
модификации сформированных структур данных для настойки системы на решение
конкретной оценочной задачи, а также механизмы, обеспечивающие получение
информации другими программными модулями (например модулями оценки и принятия
решения). Реализация механизмов управления данными должна быть представлена в
виде программных модулей (подпрограмм, классов, ресурсов), реализующих сами
структуры и алгоритмы и интерфейс этих структур (как программный так и
пользовательский). Реализация должна быть выполнена на языке программирования
C++ и ориентирована на операционную среду Microsoft Windows, что к началу
выполнения дипломной работы было предписано техническим заданием на разработку
универсальной экспертной системы.
Приступая к
проектированию, следует учитывать прежде всего особенности организации программ
для операционной среды MS-Windows. Прежде всего это событийная организация
управления программой, многооконный и, как продолжение, многодокументный
пользовательский и программный интерфейс. Кроме того приходится ориентироваться
на существующие средства разработки прикладных программ для этой операционной
системы. Выбранный инструментарий для работы с базами данных также имеет
значение для проектирования. Первая часть третьей главы посвящена выбору и
описанию инструментов, использованных для разработки универсальной экспертной
системы.
2.2. Типовая структура ИС
Характер задач решаемых ИС, а также основные функции,
выполняемые системой, во многом предопределяют ее структуру. Любая система
только тогда может претендовать на звание экспертной, когда в ее состав входят
блоки обеспечивающие непосредственно формирование экспертных оценок и обучение
системы.
Для ИС необходимы средства настройки на конкретную предметную
область. Кроме того, поскольку (как было сказано ранее) ИС представляет собой
рабочее место нескольких категорий пользователей: администратора системы,
экспертов - лиц принимающих решения, целесообразно придать системе сетевую архитектуру
типа клиент-сервер (КС).
Все вышесказанное обуславливает необходимость выделения в
разработанной ИС следующих, относительно самостоятельных подсистем:
- подсистема настройки и адаптации;
- подсистема управления базами данных;
- подсистема принятия и анализа решений;
- подсистема обучения;
- подсистема управления сетью.
1.Подсистема настройки и адаптации предназначена для настройки
системы для решения конкретной предметной задачи;
2.Подсистема обучения предназначена для накопления знаний в
предметной области, необходимых для решения конкретной задачи. Эта информация
может отражать как субъективное мнение экспертов, так объективную статистику
(обучающая выборка);
3.Подсистема управления сетью проектов, предназначенная для
динамического связывания данных, относится к разным предметным задачам, но
позволяющих решать более глобальные задачи;
4.Подсистема принятия и анализа решений предназначена для
непосредственного формирования оценки сложных объектов, а также анализа и
обоснования вычисленных оценок;
5.Подсистема управления базами данных (БД)предназначена для
ведения (ввод, удаление, редактирование, сортировка и т.д.) БД, содержащей
оцениваемые объекты.
Описания подсистемы фактически являются АРМ-ами различных
категорий пользователей. Так администратор системы должен пользоваться
подсистемой настройки и адаптации, а также подсистемой управления сетью
проектов и подсистемой управления БД.
Эксперты-специалисты в предметной области должны пользоваться
подсистемами обучения и возможно подсистемами настройки и адаптации и
подсистемами управления БД.
Лицо принимающее решение (руководитель) как правило
пользуется только подсистемой принятия и анализа решений. Рядовые операторы
обеспечивают внесение исходных данных в базу и являются основными
пользователями подсистемы управления базой данных. На основании этого
предлагается реализовать всю
универсальную экспертную систему в виде следующих пяти АРМ-ов:
- АРМ настройки и адаптации (“Администратор”);
- АРМ подсистема управления базами данных;
- АРМ принятия и анализа решений;
- АРМ обучения;
- АРМ управления проектов сетью.
С целью придания гибкости разрабатываемой системе целесообразно
предусмотреть возможность конфигурирования любого из АРМ-ов, с учетом
потребностей в конкретной организации. Это означает, что несмотря на совпадение
названий подсистем и АРМ-ов, конкретному АРМ-у могут быть приданы функции не
только основной подсистемы, входящей в его состав, но и функции других подобных
подсистем. Как было сказано ранее АРМ управления сетью проектов (администратор)
кроме того может быть снабжен функциями настройки и адаптации системы
управления БД и т.д. АРМ-обучение, является рабочим местом экспертов, иногда
целесообразно расширять функциями настройки и адаптации, функциями управления
БД и функциями принятия и анализа решений. Таким образом название каждому АРМ-у
дано по основной подсистеме входящей в его состав, при этом не исключается
возможность включения в отдельный АРМ дополнительных функций других подсистем.
Отдельно необходимо рассмотреть вопросы взаимодействия между
собой отдельных АРМ-ов. Поскольку по техническому заданию архитектура
проектируемой системы строится по принципу клиент-сервер (КС), необходимо произвести
такую декомпозицию отдельных подсистем, которая обеспечивала бы формирование типовых
запросов от разных АРМ-ов и обработку этих запросов серверной частью системы.
Именно поэтому в состав разработанной системы необходимо включить серверный
программный блок, который непосредственно управляет всеми БД всех одновременно
решаемых задач. Все обращения к любым данным системы происходят только через
этот серверный блок.. Таким образом в серверном блоке должны быть части
деллегированные ему описанными подсистемами. Это означает, что часть функций
обеспечивающих настройку системы, ее обучение, вычисление и интерпретацию
оценок, должны также выполняться и серверным блоком. Именно по этому в состав
серверного блока включены соответствующие фрагменты.
Еще одним механизмом, обеспечивающим сетевое функционирование
системы является механизм флагов состояния проекта, т.е. проект может
находиться в одном из следующих состояний:
-создание проекта не завершено;
-проект не обучен;
-обучение проекта завершено;
-обучение для задач классификации с уточнениями.
Этот механизм обеспечивает координацию действий отдельных
АРМ-ов через данные, а не через управление (через блок сервера). В соответствии
с этим механизмом отдельные АРМ-ы как бы передают эстафету друг другу при создании
модификаций и использовании конкретных проектов.
ВЫБОР СРЕДСТВ РАЗРАБОТКИ.
Среди имеющихся средств разработки прикладных программ для
выбранной операционной системы можно выделить две значительные группы:
средства,
реализующие блочно-функциональный подход к разработке программ(Windows SDK);
средства
реализующие объектно-ориентированный подход(OLW, MFC);
Сравнивая эти две группы, можно сказать что: средства,
основанные на традиционном подходе, были реализованы и появились на рынке
раньше, чем средства из второй группы, их использование менее требовательно к
мощности средств вычислительной техники, используемой при разработке, эти
средства позволяют обращаться непосредственно к функциям ядра операционной
системы. В то же время архитектура средств, основанных на
объектно-ориентированном подходе лучше согласуется с объектно-ориентированной
идеологией Windows, на определенных этапах позволяет сократить время на
кодирование; также позволяет сделать текст программы более наглядным и красивым
с программисткой точки зрения. Средства из обеих групп позволяют в одинаково
полной степени реализовать поставленную задачу и обеспечивают достаточно
возможностей для этого.
Проанализировав все вышесказанное примем решения при
проектировании пользоваться средствами разработки из первой группы
(блочно-функциональными), как более простыми в использовании и менее
требовательными к оборудованию.
3.
ПРОЕКТИРОВАНИЕ СРЕДСТВ УПРАВЛЕНИЯ ДАННЫМИ В ИС
3.1. Описание
основных структур данных
Исходя из основной цели, которую необходимо достичь при
разработке структур данных - универсальности, следует прежде всего разделить
весь объем перерабатываемой информации на информацию разделяемую несколькими
оценочными задачами и информацию приватную (доступную только одной задаче).
Ввиду того, что для одного и того же набора объектов (базы данных) может быть
сформулировано несколько оценочных задач весь перечень объектов, подвергающихся
оценке, является разделяемой информацией, т.е. объекты, оцениваемые в одной
задаче, должны быть доступны также и другим задачам (например на базе данных объектов
недвижимости может решаться как задача поиска оптимальной квартиры с точки
зрения цены и района, так и задача поиска наилучшей квартиры с точки зрения
площади и удобств). Назовем всю информацию (в виде физических структур данных)
о конкретной оценочной задаче, решаемой универсальной экспертной системой -
проектом, тогда перечень объектов, а следовательно и их описание, т.е.
конкретная реализация множества S является информацией, доступной нескольким
проектам. Ввиду того, что перечень объектов легко представляется в виде таблицы
где столбцы соответствуют конкретным свойствам из множества S, а строки
соответствуют объектам, примем решение использовать для хранения перечня
объектов существующие инструментарии поддержки популярных форматов данных
(поддержки СУБД). Это обеспечит нам, кроме того возможность подготовки данных
вне оболочки экспертной системы, что в будущем может оказаться немаловажным.
С другой стороны, из выше приведенного примера с объектами
недвижимости видно, что если перечень объектов - это информация разделяемая, то
перечень оценок этих объектов - информация приватная для каждого проекта.
Следовательно, следует всю базу данных объектов разделить на два физических
файла - один, хранящий информацию о значениях свойств объектов и второй,
хранящий информацию о вычисленных оценках объектов. Каждому объекту, с другой
стороны, должна быть поставлена в соответствие оценка, т.е. таблицы должны быть
связаны. Выберем реляционный тип связывания таблиц, как наиболее распространенный
с одной стороны, и наиболее легко реализуемый, если основываться на
существующих программных библиотеках (во всяком случае библиотеки поддержки
нереляционных СУБД автору неизвестны). Для связывания таблиц по реляционному
принципу введем в обе таблицы, поля, значения которых идентифицирующих объект -
регистрационные поля.
Далее выясняется, что существующих терминов описания баз
данных недостаточно для полного описания множества S. Например, для того чтобы
составить весь перечень возможных исходов перечислимого поля нужно полностью
перебрать всю базу данных по этому полю (и даже в этом случае мы получим
неполный перечень возможных значений), определить же пределы изменения
численных полей тем более затруднительно. Исходя из вышеизложенного,
выясняется, что необходимы дополнительные структуры данных для хранения
информации о множестве S. Эта структура должна содержать информацию во-первых,
о наименовании свойства, во-вторых, о его типе (численное, перечислимое или регистрационное),
в-третьих, о пределах изменений значения для численных свойств и о перечне
значений для перечислимых свойств.
Что касается перечня классов, то здесь нет смысла использовать
форматы данных СУБД, во-первых, потому что этот перечень невелик, а во-вторых,
потому что перечень содержит только наименования классов.
Далее представляется целесообразным объединить множества T,
D, P, K и соответствий F в одну структуру данных, во-первых, потому что эти
множества логически связаны между собой (существование множеств P и D вытекает
из смысла и формулировки множества Т), во-вторых, появляется возможность совместить
параметры P и F (таким образом, что если соответствия между i-ым требованием и
j-ым свойством нет то вес Pij = 0).
И, наконец, для того, чтобы связать все эти файлы вместе
необходима структура данных, хранящая информацию о самом проекте в целом (о
типе решаемой задачи, об именах файлов и т.д.).
Файл с расширением *.pjt. Этот файл хранит информацию о
модели в целом. Файл имеет следующую структуру:
Таблица 3.1. Смещение Длина Описание 0 1 Байт флагов - содержит информацию о задача, состоянии, статусе проекта 1 30 Имя файла STC связанного с проектом 31 80 Краткое наименование проекта 121 20 Пароль 141 1 Количество классов (только для задачи классификации) 142 n*41 Наименования классов
Файл с расширением *.stc. Этот файл хранит информацию о
множестве свойств объектов. Файл имеет следующую структуру:
Таблица 3.2. Смещение Длина Описание 0 2 Номер свойства 2 129 Наименование свойства 131 1 Тип свойства 132 30 Имя значения. (Только для перечислимых свойств) 164 4 Граничное значение. (Только для численных свойств)
Файлы с расширением *.db. Этих файлов в каждом проекте два.
Один из них имеет имя, такое же как у вышеописанного stc-файла и хранит
перечень объектов, подвергаемых оценке. Второй имеет имя, такое же как у
pjt-файла и хранит оценки объектов, полученные в процессе решения оценочной
задачи. Имена полей файлов формируются по принципу: первый символ - это буква
обозначающая тип свойства, соответствующего данному полю R - для
регистрационных и I для информационных (численных и перечислимых) полей;
следующие символы представляют собой порядковый номер поля в символьном
виде(причем нумерация информационных и регистрационных полей ведется
раздельно).Оба файла связаны друг с другом по реляционному принципу. Файл имеет
формат Paradox 3.5.
Файл с расширением *.tpt. Файл имеет имя, такое же как имя
pjt-файла и хранит информацию о множествах T, P, D, К и соответствиях F. Файл
имеет следующий формат:
Таблица 3.3. Смещение Длина Описание 0 129 Имя требования 130 n*4 Вектор весов требования в каждом классе - n Вектор критичностей требований в каждом классе - 1 Количество свойств, относящихся к данному требованию - m Вектор номеров свойств, относящихся к данному требованию - n*m*4 Матрица дуговых коэффициентов m свойств в n классах
Кроме вышеописанных алгоритмов необходимо сформировать
совокупность структур и алгоритмов для хранения информации о модели в
оперативной памяти т.н. логические структуры и алгоритмы управления ими. Ввиду
того, что физически информация о компонентах модели записана последовательно
имеет смысл придерживаться того же принципа и при разработке логических
структур. В то же время при работе других подсистем, может понадобится иметь
доступ к определенному элементу структуры не последовательно, а например, по
порядковому номеру.
Исходя из этого, логические структуры должны совмещать
достоинства структур с последовательным доступом и структур со случайным
доступом. При этом структуры должны хранить информацию, записанную в
файлах-компонентах системы и предоставлять по требованию других программных
модулей разностороннюю информацию о хранимых данных.Для структуризации описания
целесообразно поделить реализуемые функции на уровни. При этом функции первого
уровня вызываются непосредственно при обработке того или иного сообщения
главного окна приложения. Функции второго уровня вызываются функциями первого
уровня и т.д.
3.2. Назначение,
состав и описание блока управления данными
После формулировки представления информации в виде структур
физических данных можно перейти к проектированию алгоритмов управления этими
структурами. Сформулируем в начале, какие действия должна позволять производить
система с точки зрения пользователя по настройке на решение конкретной оценочной
задачи. Система должна позволять:
- создавать описание конкретной оценочной задачи и всех ее
компонентов (создавать новый проект);
- настраиваться на решение ранее сформулированной задачи
(открывать существующий проект);
- удалять информацию о задаче, если в ней отпала необходимость
(удалять проект);
- модифицировать все составные части проекта, несущие
информацию о компонентах оценочной модели, т.е. модифицировать представления
множеств S, T, P, E, D, C, K и соответствий F.
- производить сохранение проведенных изменений с предоставлением
возможности пользователю продублировать информацию.
Последний пункт требует пояснения. В связи с тем, что
некоторые компоненты модели являются информацией, разделяемой несколькими
проектами, изменения ,проведенные в них при работе с одним проектом, могут
привести к потере данных, существенных для другого проекта, использующего этот
же компонент. Например, удаление поля “жилая площадь” из сеанса работы с
проектом оценивающим квартиры с точки зрения их расположения (района) привет к
невозможности оценки этого же перечня квартир с точки зрения их жилой площади.
С точки зрения программного интерфейса проектируемые алгоритмы
должны:
- предоставлять информацию о всех компонентах модели другим
программным модулям системы;
- хранить в памяти информацию об именах файлов-компонентов
проекта для возможности их записи на диск и чтения с диска;
- хранить и позволять динамически (из других подсистем)
изменять информацию о состоянии проекта. Имеется в виду следующее: система
должна постоянно знать полностью ли сформированы все компоненты модели и
зависимости от этого позволять или не позволять производить те или иные
действия. Например нельзя позволять производить оценку пока не сформированы эталоны
и нельзя позволять формировать эталоны пока не сформированы множества
требований и весовых коэффициентов.
- оповещать остальные подсистемы об изменениях компонентов
модели и состояния проекта.
Третий пункт требует пояснения. Будем различать следующие
возможные состояния проекта:
- “проект не создан” - не сформировано множество требований
к объектам - некорректен файл tpt;
- “проект не обучен” - не сформированы эталоны - некорректен
файл эталонов;
- “проект обучен” в этом состоянии допускается проведение
оценки объектов;
- “обучен с уточнением” - это состояние присваивается при
решении задачи классификации после проведения т.н. обучения с уточнением (или
второй фазы обучения). Рассмотрение механизма такого обучения выходит за рамки
настоящей дипломной работы.
Исходя из вышеизложенных требований можно составить наиболее
укрупненный перечень блоков по управлению данными:
- блок создания проекта;
- блок открытия проекта;
- блок закрытия проекта;
- блок удаления проекта;
- блок модификации проекта;
- блоки оповещения других подсистем об изменении состояния
проекта;
- блоки реакции на ошибки и обработки исключительных ситуаций;
- блоки контроля действий пользователя.
Приведенный список весьма укрупнено отражает структуру
подсистемы и требует дальнейшей детализации.
Блоки открытия проекта включают в себя:
- алгоритмы восстановления информации о составных частях
проекта, именах файлов, информации о состоянии проекта;
- алгоритмы восстановления (чтения) составных частей проекта
в зависимости от типа решаемой задачи и состояния проекта;
- алгоритмы анализа корректности восстановленной информации
и принятия решения о возможности открытия проекта или об изменении состояния.
- алгоритмы запуска необходимых подпрограмм дальнейшей
настройки системы.
Блоки создания проекта включают в себя:
- алгоритмы запроса и присвоения имен файлам-компонентам
проекта;
- алгоритмы формирования составных частей проекта;
- алгоритмы записи сформированных компонентов проекта на
диск;
- алгоритмы установки состояния проекта, в зависимости от
количества и качества сформированных частей проекта;
блоки закрытия проекта включают в себя:
- алгоритмы записи компонентов проекта на диск;
- алгоритмы освобождения памяти;
- оповещение других подсистем о закрытии проекта;
- закрытие открытых файлов, баз данных и т.д.
Блоки модификации проекта и формирования компонентов проекта
включают в себя:
- поддержку диалогов с пользователем при модификации
конкретных частей проекта;
- алгоритмы анализа необходимости модификации других
компонентов проекта;
- алгоритмы анализа необходимости изменения состояния
проекта и необходимости переобучения;
- анализ необходимости и алгоритмы запуска механизмов
модификации баз данных из подсистемы управления базами данных;
- алгоритмы сохранения изменений и возможности отказа от
них.
Блоки контроля действий пользователя запускаются в основном
из алгоритмов поддержки диалогов с пользователем, которые в том или ином виде
присутствуют во всех вышеописанных алгоритмах. Контроль же зависит от специфики
конкретной вводимой пользователем информации и включает в себя как синтаксический
так и семантический контроль. Синтаксический контроль включает в себя контроль
правильности ввода с точки зрения типа вводимых простых данных и длины
массивов: например, если запрашивается число, а пользователь вводит строковую
величину. Семантический контроль включает в себя контроль вводимых данных с
учетом их специфики.
Блоки реакции на изменение состояния проекта включают в себя
запрещение тех или иных действий не допустимых при вновь устанавливаемом
состоянии и оповещение других подсистем об изменениях.
Блоки удаления проекта включают в себя запрос имени проекта
и верификацию запроса на удаление.
- Блоки реакции на ошибки включают в себя анализ происшедшей
ошибки и при необходимости запрос пользователя на возможные пути решения
возникшей проблемы. После чего запускается выбранный пользователем механизм
решения ошибки либо останавливается проводящийся в момент возникновения ошибки
процесс. Во многих случаях пользователь лишь оповещается о происшедшей ошибке,
а процесс автоматически прерывается. Блоки реакции на ошибки также включают в
себя:
-реакцию на несоответствие фактически имеющимся данным
состоянию проекта;
-реакцию на фатальные ошибки;
-реакцию на ошибки поиска файлов.
3.2.1 Функции первого уровня
OpenProject
Прототип: int
OpenProject (void);
Назначение:
Реакция на выбор пункта меню Проект|Открыть... Открывает проект, инициализирует
переменные CurrentProject, Records, Demands, Table.
Параметры: нет
Возврат: 0 - в
случае удачного выполнения; !0 - в
противном случае
CreateProject
Прототип: BOOL
CreateProject (void);
Назначение:
Реакция на выбор пункта меню Проект|Создать... Создает новый проект, в
диалоговом режиме инициализирует переменные CurrentProject, Records, Demands,
Table.
Параметры: нет
Возврат: TRUE - в
случае удачного выполнения; FALSE - в противном случае
CloseProjectChoice
Прототип: void
CloseProjectChoice (void);
Назначение:
Реакция на выбор пункта меню Проект|Закрыть. Закрывает открытый проект, очищает
переменные CurrentProject, Records, Demands, Table, закрывает файлы.
Параметры: нет.
Возврат: нет.
SaveProject
Прототип: void
SaveProject (char *)
Назначение:
Сохраняет информацию о компонентах модели в соответствующих файлах.
Параметры: имя
проекта
Возврат: нет
DeleteProject
Прототип: void
DeleteProject (void)
Назначение:
Удаляет файлы проекта.
Параметры: нет
Возврат: нет
ModifyDB
Прототип: void
ModifyDB (void)
Назначение: В
диалоговом режиме производит модификацию перечня свойств объектов и при
необходимости запускает механизм модификации баз данных
Параметры: нет
Возврат: нет
ModifyDemands
Прототип: void
ModifyDemands (void)
Назначение: В
диалоговом режиме производит модификацию перечня требований к объектам.
Параметры: нет
Возврат: нет
ModifyClasses
Прототип: void
ModifyClasses (void)
Назначение: В
диалоговом режиме производит модификацию распознаваемых классов в задаче
классификации, при необходимости запускает механизм модификации баз данных.
Параметры: нет
Возврат: нет
3.2.2.Описание функций нижних уровней
OpenProjectFunct
Прототип: int
OpenProjectFunct (char *);
Назначение:
Проверяет наличие и корректность файлов проекта и инициализирует необходимые
переменные
Вызывающие
функции: OpenProject
Параметры: имя
проекта
Возврат: 0 - в
случае успешного завершения, иначе - код ошибки
CreateDemandTemplate
Прототип: BOOL
CreateDemandTemplate (void)
Назначение: на
основе диалога с пользователем инициализирует переменную Demands (создает
требования)
Вызывающие
функции: CreateProject
Параметры: нет
Возврат: TRUE - в
случае удачного выполнения; FALSE - в противном случае
CreateProjectClasses
Прототип: BOOL
CreateProjectClasses (void)
Назначение: на
основе диалога с пользователем создает множество классов
Вызывающие
функции: CreateProject
Параметры: нет
Возврат: TRUE - в
случае удачного выполнения; FALSE - в противном случае
CreateDBStructure
Прототип: BOOL
CreateDBStructure (char *)
Назначение: на
основе диалога с пользователем создает множество свойств (инициализирует
переменные Records, Table).
Вызывающие
функции: CreateProject
Параметры: имя
файла STC
Возврат: TRUE - в
случае удачного выполнения; FALSE - в противном случае
UseExistingTable
Прототип: BOOL
UseExistingTable (char *);
Назначение:
Инициализирует переменные
Records, Table на основе данных существующего файла STC.
Вызывающие
функции: CreateProject.
Параметры: имя
файла STC
Возврат: TRUE - в
случае удачного выполнения; FALSE - в противном случае
CreateSTCDlgProc
Прототип: BOOL FAR
PASCAL _export CreateSTCDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam)
Назначение:
реализует диалог с пользователем по созданию множества свойств
Вызывающие
функции: ModifyDB,
CreateDBStructure
Параметры: hDlg -
дескриптор диалогового окна; msg - код сообщения; wParam, lParam - параметры
сообщения
Возврат: код
выхода из диалога
CreateTPTDlgProc
Прототип: BOOL FAR
PASCAL _export CreateTPTDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam)
Назначение:
реализует диалог с пользователем по созданию множества требований
Вызывающие
функции: ModifyDemands,
CreateDemandTemplate
Параметры: hDlg -
дескриптор диалогового окна; msg - код сообщения; wParam, lParam - параметры
сообщения
Возврат: код
выхода из диалога
ClassesDlgProc
Прототип: BOOL FAR
PASCAL _export ClassesDlgProc
(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam)
Назначение:
реализует диалог с пользователем по созданию множества классов в задаче
классификации
Вызывающие
функции: ModifyClasse
Параметры: hDlg -
дескриптор диалогового окна; msg - код сообщения; wParam, lParam - параметры
сообщения
Возврат: код
выхода из диалога.
4. ОПИСАНИЕ
ПРИМЕНЕНИЯ СРЕДСТВ УПРАВЛЕНИЯ ДАННЫМИ В ИС
4.1. Описание
интерфейса пользователя
(руководство пользователя)
4.1.1. Создание проекта
Создание проекта происходит в диалоговом режиме и включает
следующие шаги:
1.Описание параметров проекта. На этом
шаге пользователь должен указать тип решаемой
задачи, режим доступа к используемой базе данных и, если выбран индивидуальный
режим доступа, ввести пароль доступа к проекту.
2.Описание множества свойств оцениваемых
объектов. На этом шаге пользователь может выбрать существующее множество
свойств или сформировать новое.
3.Описание множества распознаваемых
классов (только для задачи кассификации).
Для создания проекта выберите пункт меню "Проект|Создать..." ("Project|Create..."). После этого пройдите все шаги создания
проекта.
Создание проекта может быть прервано на любом из этих шагов.
Однако, проект создается только в том случае, если пользователь корректно
совершил все шаги. После создания проекта пользователю будет предложено
сформировать требования и провести обучение системы.
Описание
параметров проекта происходит в диалоговом окне, внешний вид и описание
которого приведены ниже
Рис 4.1.
Окно установки параметров проекта
· Строка ввода описания -
"Описание" ("Description"). Служит для ввода краткого описания (или наименования) проекта
(до 20 символов)
· Кнопка одиночного выбора типа решаемой
задачи - "Задача" ("Task"). Позволяет выбрать тип решаемой задачи из двух вариантов:
· "Квалиметрия"
("Qualimetric"),
· "Классификация"
("Classification").
· Кнопка одиночного выбора способа
доступа к используемой базе данных "Статус" ("Status").
Позволяет выбрать способ доступа к базе
данных из двух вариантов:
· "Общий" ("Public"),
· "Частный"
("Private").
для
задания коллективного или индивидуального способа использования базы данных
соответственно.
· Кнопка "OK". Служит для
подтверждения описания проекта.
· Кнопка "Отмена"
("Cancel"). Служит для отказа от введенных параметров и прерывания
создания проекта.
Для установки параметров создаваемого проекта выполните
следующую последовательность действий:
1.В строке ввода описания проекта введите
краткое наименование проекта.
2.Выберите тип задачи, которую будет
решать создаваемый проект.
3.Выберите способ доступа к используемой
базе данных:
· Выберите коллективный способ доступа,
если база данных проекта будет или уже используется в нескольких проектах,
владельцами которых являются разные пользователи.
· Выберите индивидуальный способ доступа,
если Вы хотите, чтобы информация об объектах, хранящейся в базе данных, была
доступна только Вам.
4.Нажмите кнопку "OK".
Имя файла, содержащего описание свойств, должно отличатся от
имени файла проекта.
Если Вы выбрали индивидуальный способ доступа к базе данных,
система запросит пароль доступа к проекту в окне запроса пароля.
Установка
пароля происходит в окне, внешний вид которого приведен ниже
Рис 4.2.
Окно ввода пароля
Органы
управления окна:
· Строка ввода пароля. "Введите
пароль" ("Enter password").
· Строка повторного ввода пароля.
"Еще раз" ("Retype password").
· Кнопка "OK" - подтверждение
установки пароля. Пароль установится при условии, что он введен одинаково в обеих
строках ввода. В противном случае Вам будет предложено еще раз попытаться
установить правильный пароль.
· Кнопка "Отмена"
("Cancel") - отказ от установки пароля.
Для установки пароля доступа к проекту введите пароль в
строке ввода пароля и повторите ввод в строке повторного ввода пароля. Затем
нажмите кнопку "OK".
Если Вы откажетесь от ввода пароля и нажмете кнопку "Отмена"
("Cancel"), для базы данных будет установлен коллективный способ
доступа.
После описания параметров создаваемого проекта Вам будет
предложено выполнить следующие действия:
1.В типовом окне запроса имени файла
система запросит имя файла с описанием перечня свойств. В нем Вы должны выбрать
существующий файл с описанием перечня свойств объектов или ввести имя нового
файла.
Если вы
создаете проект с индивидуальным способом доступа к базе данных, то Вы не
сможете использовать в нем базу данных,
созданную в проекте с общим способом доступа, и наоборот.
2.Если файл с описанием перечня свойств
не существует, система предложит сформировать перечень свойств объектов в
редакторе свойств.
3.Система предложит сформировать
множество классов (только для классификации).
4.Система предложит сформировать
требования.
5.Вам будет предложено обучить
систему.
Вы можете
прервать создание проекта на любом из шагов, нажав кнопку "Отмена"
("Cancel") в любом из окон.
4.1.2. Откытие проекта
Если
решаемая задача уже описана в рамках системы Expek Pro (проект создан), то для
начала работы с ней необходимо подготовить систему к решению этой задачи -
открыть проект.
Для открытия проекта выберите команду меню "Проект|Открыть..." ("Project|Open..."). Затем выберите имя нужного проекта в типовом
окне открытия файла.
Система
загрузит в память всю необходимую информацию о задаче, описанной в открываемом
проекте. После этого можно выполнять действия по обучению системы, оценке объектов
и модификации проекта. При этом пользователю предложено будет пройти
последовательно шаги по формированию шаблона требований и обучению, если он не
выполнил их при создании проекта (смотри пункт Создание проекта).
4.1.3. Закрытие проекта
Для
завершения работы с конкретной оценочной задачей необходимо закрыть проект.
Для этого
нужно выбрать команду меню "Проект|Закрыть" ("Project|Close").
Система завершит работу с проектом с обязательным сохранением всей информации
о текущем состоянии проекта в файлах, используемых проектом.
4.1.4. Сохранение копии проекта
Для
сохранения копии проекта выберите команду меню "Проект|Сохранить как..."
("Project|Save as..."). Система запросит имя копии проекта и
имя копии базы данных в типовом окне запроса имени сохраняемого файла. Имена
проекта и базы данных не должны совпадать. Если Вы введете одинаковые имена
проекта и базы данных, то в сохранении копии проекта будет отказано.
4.1.5. Удаление проекта
Для удаления проекта выберите команду меню "Проект|Удалить..." ("Project|Delete...").
Система запросит имя удаляемого проекта в типовом окне выбора имени файла и удалит
файлы, относящиеся к проекту.
Ввиду
того, что база данных объектов, используемая
удаляемым проектом, может использоваться другими проектами, удаление
файлов базы данных объектов не производится.
4.1.6. Формирование множества свойств
Описание множества свойств объектов происходит в экране,
внешний вид которого показан ниже:
Рис.4.3. Окно редактора свойств.
Редактор свойств предназначен
для описания и модификации множества свойств, описывающих объект в
данной оценочной задаче.
Экран состоит из трех панелей:
· Панель описания перечня свойств. В этой
панели отображается информация о
перечне свойств: список свойств, имя и тип выделенного свойства.
· Панель описания свойств численного
типа. В этой панели отображается информация о выделенном свойстве численного
типа.
· Панель описания свойств перечислимого
типа. В ней отображается информация о выделенном свойстве перечислимого типа.
· Список
имен свойств - "Список свойств"
("Characteristic list"). В
зависимости от состояния свойства имя его в данном списке может быть отображено
одним из следующих цветов:
· синим - если свойство было модифицировано или добавлено в текущем сеансе
редактирования;
· черным - если свойство не
модифицировалось в текущем сеансе редактирования;
· красным - если свойство было удалено в текущем сеансе редактирования.
· Строка
ввода имени свойства - "Имя свойства"
("Characteristic name"). Отображает
имя выделенного свойства. Также
используется для ввода имени нового свойства или модификации имени выделенного.
· Кнопка одиночного выбора типа свойства.
"Тип свойства" ("Characteristic type"). Отображает тип выделенного свойства и позволяет ввести тип
нового свойства. Возможен выбор из трех
вариантов:
· "Регистрационное"
("Registrational");
· "Численное"
("Numeric");
· "Перечислимое"
("Enumerated").
· Кнопка "Добавить"
("Add"). Реализует функцию добавления нового свойства.
· Кнопка "Удалить"
("Delete"). Реализует функцию удаления выделенного свойства.
· Кнопка "Изменить"
("Modify"). Реализует функцию модификации описания выделенного
свойства.
Панель
содержит две строки ввода "Минимум" ("Min") и
"Максимум" ("Max") для задания минимального и максимального значения
численного свойства соответственно.
Панель доступна, если текущее свойство имеет численный тип.
Панель содержит:
· Список имен значений выделенного
свойства "Список значений" ("List of values").
· Имя вводимого значения "Имя
значения" ("Value name").
· Кнопка добавления значения
"Новое" ("New").
· Кнопка удаления значения
"Удалить" ("Delete").
Панель доступна, если тип выделенного свойства - перечислимый.
Кроме органов управления, находящихся в вышеописанных
панелях, в экране редактора свойств находятся следующие органы управления:
· Кнопка "OK". Служит для
завершения формирования с сохранением сделанных изменений.
· Кнопка "Отмена"
("Cancel"). Служит для завершения формироания перечня свойств с
отказом от сделанных изменений.
Для добавления
регистрационного свойства необходимо:
1.В списке имен свойств выбрать свойство,
перед которым необходимо вставить вводимое регистрационное свойство.
2.Ввести имя свойства в строке ввода
имени свойства.
3.Выбрать тип свойства
"Регистрационное" ("Registrational").
4.Нажать кнопку "Добавить"
("Add").
После выполнения этих действий свойство добавится в список
(и будет отображаться синим цветом) при условии соблюдения следующих условий:
· имя свойства уникально;
· свойство добавляется первым либо
непосредственно после регистрационного.
В противном случае добавления не произойдет, и появится
соответствующее объясняющее сообщение.
Для добавления численного свойства необходимо:
1.В списке имен свойств выбрать свойство,
перед которым необходимо вставить вводимое численное свойство.
2.Ввести имя свойства в строке ввода
имени свойства.
3.Выбрать тип свойства
"Численное" ("Numeric").
4.В панели численного свойства ввести
минимальное и максимальное значения.
5.Нажать кнопку "Добавить"
("Add").
После выполнения этих действий свойство добавится в список
(и будет отображаться синим цветом) при условии соблюдения следующих условий:
· имя свойства уникально;
· после добавляемого свойства не следует
ни одного регистрационного свойства;
· численные значения минимума и максимума
введены корректно;
· минимальное значение меньше
максимального.
В противном случае добавления не произойдет, и появится
соответствующее объясняющее сообщение.
Для добавления перечислимого свойства необходимо:
1.В списке имен свойств выбрать свойство,
перед которым необходимо вставить вводимое свойство.
2.Ввести имя свойства в строке ввода
имени.
3.Выбрать тип свойства
"Перечислимое" ("Enumerated").
4.Сформировать множество значений в
панели перечислимого свойства. При этом следует иметь ввиду, что количество
значений должно быть не меньше двух.
5.Нажать кнопку "Добавить"
("Add").
При необходимости Вы можете изменить имя и описание существующего
свойства. При этом необходимо соблюдение тех же ограничений, что и при
добавлении свойства.
Для изменения имени свойства необходимо:
1.В списке имен выбрать свойство, которое модифицируется.
2.Изменить его имя в строке ввода имени (при этом кнопка
"Изменить" ("Modify") начнет мигать, указывая на необходимость
нажатия на нее). Вновь введенное имя должно быть уникально.
3.Нажать кнопку "Изменить"
("Modify").
Модификация
типа свойства не допускается. При
попытке модифицировать тип высветится сообщение о невозможности модификации.
Для изменения типа необходимо удалить свойство, а затем восстановить его с
новым типом
Для изменения границ численного свойства необходимо:
1.В списке имен выбрать свойство, которое модифицируется.
2.Изменить границы диапазона его значений
в строках ввода минимального и максимального значений (при этом кнопка
"Изменить" ("Modify") начнет мигать, указывая на необходимость
нажатия на нее). Минимальное значение должно быть меньше максимального.
Нажать
кнопку "Изменить" ("Modify").
Для изменения перечня значений перечислимого свойства
необходимо:
1.В списке имен выбрать свойство, которое модифицируется.
2.Для
добавления значения необходимо в списке выбрать значение, перед
которым нужно вставить вводимое. Затем
необходимо в строке ввода имени значения ввести имя. Затем - нажать кнопку
"Новое" ("New"). Если введенное имя уникально, значение
будет добавлено в список.
3.Для удаления значения необходимо
выбрать в списке значений необходимое значение и нажать кнопку
"Удалить" ("Delete").
4.Нажать кнопку "Изменить"
("Modify").
5.Если введенные данные корректны (число
значений не меньше двух) будет выполнена модификация свойства и в списке имен свойство выделится синим цветом.
Любую
модификацию свойства необходимо завершать нажатием кнопки "Изменить"
("Modify"). Если Вы этого не
сделаете, при переходе к другому свойству в списке все изменения описания
редактируемого свойства будут потеряны.
Для удаления свойства
необходимо:
1.В
списке имен свойств
выбрать свойство, которое нужно удалить.
2.Нажать кнопку "Удалить"
("Delete"). Свойство будет помечено красным цветом в списке имен
свойств. Вы можете восстановить удаленное в текущем сеансе редактирования
свойство в первоначальном либо измененном по Вашему желанию виде
Для восстановления удаленного в текущем сеансе свойства необходимо:
1.Выбрать имя удаленного свойства.
2.Изменить параметры описания свойства
(если необходимо).
3.Нажать кнопку "Добавить"
("Add").
Для
сохранения сформированного перечня свойств необходимо нажать кнопку
"OK". В перечне свойств должно быть как минимум одно регистрационное
и одно информационное свойство. При соблюдении этих условий сформированный
перечень свойств будет сохранен. В противном случае будет выведено сообщение об
ошибке, и будет предложено вернуться к формированию перечня свойств.
Следующие изменения, сделанные в описаниях свойств, приводят
к потере данных в базе данных проекта:
· удаление свойства;
· сужение границ диапазона численного
свойства;
· удаление значения перечислимого
свойства.
Для выхода
из редактора свойств без сохранения изменений, сделанных в последнем сеансе
работы, нажмите кнопку "Отмена" ("Cancel").
4.1.7. Формирование перечня классов
Формирование
перечня классов производится и доступно
только при решении задачи классификации. Для этого используйте редактор
классов, внешний вид и описание экрана которого приводится ниже:
Рис.4.4. Окно редактора классов
Органы
управления: · Список классов "Классы" ("Classes"). Содержит имена классов, распознаваемых в данной задаче (проекте). · Строка ввода имени класса "Имя класса" ("Class name"). Служит для ввода имени класса при добавлении в список классов. Перечисленные ниже органы управления позволят Вам управлять процессом редактирования перечня классов. Следующая таблица показывает назначение каждого из органов управления. Добавить (Add) Служит для добавления имени класса к списку классов. Удалить (Delete) Служит для удаления текущего (выделенного) класса. OK Служит для завершения формирования списка классов с сохранением сделанных изменений. Отмена (Cancel) Служит для завершения описания классов с потерей сделанных изменений Для добавления нового класса к множеству классов необходимо: 1.Выбрать в списке классов имя класса перед которым нужно вставить новый класс. 2.Ввести имя добавляемого класса в строке ввода имени. 3.Нажать кнопку "Добавить" ("Add"). Если имя уникально, то класс добавится к множеству классов. Для удаления класса необходимо выбрать имя удаляемого класса в списке классов и нажать кнопку "Удалить" ("Delete"). Для редактирования класса необходимо удалить его из перечня классов, а затем добавить с новым именем. Отредактированный класс является по-существу новым, поэтому такое редактирование приведет к необходимости переобучения по этому классу.
Для сохранения перечня классов необходимо нажать кнопку OK.
Количество классов должно быть не меньше двух. Если это условие не выполняется,
то выведется сообщение об ошибке, и Вам будет предложено вернуться к
формированию перечня классов.
Для выхода
без сохранения изменений, сделанных в последнем сеансе работы, нажмите кнопку
"Отмена" ("Cancel").
4.1.8. Формирование перечня требований Описание шаблона требований к объектам производится в экране, внешний вид которого показан на рисунке Рис.4.5. Окно редактора требований Экран состоит из трех панелей: · панель перечня требований; · панель описания характеристик требования по классам; · панель описания соответствий; Панель перечня требований состоит из следующих органов управления и зон ввода: · Список имен требований к объектам - "Список требований" ("Demand list"). · Строка ввода имени требования - "Имя требования" ("Demand name"). Служит для отображения имени текущего требования. Также служит для ввода имени нового требования. · Кнопка "Добавить" ("Add"). Служит для добавления нового требования. · Кнопка "Удалить" ("Delete"). Служит для удаления текущего требования. · Список классов - "Классы" ("Classes"). Содержит список классов, распознаваемых в данной задаче. · Строка ввода веса требования - "Вес" ("Weight"). Служит для ввода весового коэффициента выбранного требования в выбранном классе. · Флажок критичности - "Критичность" ("Extremal"). Служит для указания критичности выбранного требования в выбранном классе. · Список независимых свойств - "Независимые свойства" ("Independent characteristics"). Содержит список свойств, не зависимых от текущего требования. · Список зависимых свойств "Зависимые свойства" ("Dependent characteristics") . Содержит список свойств, зависимых от данного требования. · Строка ввода дугового весового коэффициента - "Вес" ("Rate"). Для данного класса содержит значимость текущего свойства по отношению к другим свойствам, зависящим от текущего требования. · Кнопка присоединения свойств ("->"). Переносит свойства, выделенные в окне списка независимых свойств, в список зависимых свойств. · Кнопка отсоединения свойств ("<-"). Переносит свойство, выделенное в списке зависимых свойств, в список независимых свойств. Кроме органов управления, находящихся в вышеперечисленных панелях, в экране редактора требований находятся следующие общие органы управления: · Кнопка "OK". Служит для завершения формирования шаблона требований с сохранением сделанных изменений. · Кнопка "Отмена" ("Cancel"). Служит для завершения формирования шаблона требований с отказом от сделанных изменений. · Кнопка "По умолчанию" ("Default"). Служит для формирования шаблона требований с соответствиями один в один. Для формирования требований по умолчанию необходимо нажать кнопку "По умолчанию" ("Default"). Система сформирует шаблон требований, в котором каждое свойство зависимо только от одного требования с таким же именем, все тебования некритичны и имеют единичный вес во всех классах. Для добавления нового требования необходимо: 1.Выбрать требование, перед которым нужно добавить новое. 2.Ввести имя требования в строке ввода имени. 3.Если имя требования уникально, то при переходе из строки ввода имени или при нажатии кнопки "Добавить" ("Add") требование автоматически добавится в список требований. Иначе осуществится переход к редактированию того требования, имя которого было введено. 4.Далее следует установить соответствия добавленного требования и свойств; веса и критичность так, как показано ниже. Для установки весового коэффициета и критичности требования необходимо: 1.Выбрать требование и класс (в задаче классификации), для которых необходимо установить вес. 2.В строке ввода веса задать вес требования в данном классе. 3.Установить флажок критичности, если требование критично в даннном классе. Для указания свойств, зависимых от данного требования необходимо : 1.Выбрать требование, для которого устанавливается соответствие свойств и требования. При решении задачи классификации соответствия всегда одинаковы во всех классах. 2.В окне списка независимых свойств выбрать те, которые необходимо сделать зависящими от данного требования. 3.Нажать кнопку "->". Для удаления свойств из списка зависимых свойств необходимо: 1.Выбрать требование, для которого устанавливается соответствие свойств и требования. 2.В окне списка зависимых свойств выбрать то, которое необходимо сделать независящим от данного требования. 3.Нажать кнопку "<-". Для задания дугового весового коэффициента необходимо: 1.Выбрать требование, класс и зависимое свойство для которых необходимо установить весовой коэффициент. 2.В строке ввода дугового весового коэффициента задать вес свойства в данном классе. После нажатия кнопки "OK" система автоматически отнормирует дуговые весовые коэффициенты так, что сумма весов всех свойств зависимых от данного требования в каждом классе будет равна единице. Все изменения в описании требований сохраняются автоматически при завершении редактирования требования. Завершение редактирования происходит при выборе в списке требований другого требования для редактирования. Для удаления требования необходимо: 1.Выбрать требование, которое нужно удалить. 2.Нажать кнопку "Удалить" ("Delete"). Для сохранения шаблона требований необходимо в окне редактора требований нажать кнопку "OK". Для выхода без сохранения изменений, сделанных в последнем сеансе работы, необходимо нажать кнопку "Отмена" ("Cancel").
4.2.Описание контрольного
примера
В качестве контрольного
примера рассмотрим задачу выбора компьютера оптимальной конфигурации.
Оцениваемые объекты - персональные компьютеры представлены следующим перечнем
свойств:
код модели.
Свойство регистрационное.
тип процессора.
Свойство перечислимое. Исходы:
286
386SX
386DX
486SLC
486SX
486DX
486DX2
486DX4
Pentium
фирма
производитель процессора. Свойство перечислимое. Исходы:
Intel
AMD
Cyrix
Texas Instruments
другая
тактовая частота (МГц). Свойство
численное. Диапазон значений 8 - 150
наличие
сопроцессора. Свойство перечислимое. Исходы:
сопроцессор
установлен
сопроцессор не
установлен
объем ОЗУ (Мб).
Свойство численное. Диапазон значений 1-130
тип системной
шины. Свойство перечислимое. Исходы
ISA
EISA
VLB
PCI
объем жесткого диска (Мб). Свойство
численное. Диапазон 40-3000
тип контроллера
НЖМД. Свойство перечислимое. Исходы:
MFM
IDE
EIDE
SCSI
ESDI
объем аппаратной кэш-памяти.(Кб)
Свойство численное. Диапазон 0-2000.
объем памяти
видеоадаптера (Кб). Свойство численное. Диапазон 128-3000.
предоставляемая
гарантия (мес). Свойство численное. Диапазон 0-72.
цена. (ам.
Доллар). Свойство численное. Диапазон 300-10000.
сборка. Свойство
перечислимое. Исходы:
местная
желтая
белая
Перечень свойств довольно полно отражает предметную область.
Сформируем перечень требований и весовых коэффициентов.
Быстродействие. Вес 10
Зависимые
свойства: Тип процессора Вес 1.
Тактовая частота. Вес 1
Объем ОЗУ. Вес 0.7
Тип систем. шины. Вес 0.6
Наличие сопр. Вес 0.6
Объем кэш. Вес 0.6
Качество видеосистемы. Вес 8
Зависимые
свойства: Память видеосист. Вес 1
Качество НЖМД. Вес 8
Зависимые
свойства: Объем НЖМД. Вес 1
Тип контроллера.Вес 0.8
Надежность и совместимость. Вес 9
Зависимые
свойства: Производ. процесс. Вес 1
Гарантия. Вес 1
Сборка. Вес 0.9
Низкая цена. Вес 9.5
Зависимые
свойства: Цена. Вес 1
Итак, требования сформированы. Опишем задачу в терминах
экспертной системы. Запустим систему. Создадим новый проект, новую базу данных.
Оценка трудоемкости настройки произведем, подсчитывая
количество действий пользователя. К действиям пользователя отнесем следующие
операции:
выбор пункта меню;
ввод строки в поле
ввода;
выбор строки в
списке;
нажатие на кнопку;
Для добавления регистрационного свойства в текущую позицию,
таким образом необходимо выполнить три действия. Ввести имя свойства, выбрать
тип, нажать кнопку Добавить.
Для добавления численного свойства необходимо выполнить пять
действий - ввод имени, выбор типа, ввод минимума, ввод максимума, нажатие
кнопки Добавить.
Для добавления исхода перечислимого свойства необходимо
выполнить два действия - ввод имени исхода и нажатие кнопки Новый. Таким образом для добавления
перечислимого свойства необходимо выполнить 2*n+3 действия, где n - количество исходов.
Таким образом для полной настройки множества свойств необходимо
выполнить (по свойствам):
Таблица 4.1. Свойство Кол-во действий Код 3 Тип процессора 21 Фирма-производитель 13 Тактовая частота 5 Наличие сопроцессора 7 Объем ОЗУ 5 Тип системной шины 11 Объем жесткого диска 5 Тип контроллера НЖМД 13 Объем кэш-памяти 5 Объем памяти видеоадаптера 5 Срок гарантии 5 Цена 5 Сборка 9 Итого 112
Для добавления требования с установкой веса необходимо
выполнить два действия - ввести имя и ввести вес. Для добавления соответствий
необходимо выполнить 3n+2
действия - выбор требования, выбор свойств, нажатие кнопки -> выбор свойства, ввод коэффициента,
где n - количество зависимых
свойств.
Таким образом для формирования требований необходимо выполнить
следующее количество действий (по требованиям):
Таблица 4.2. Требование Кол-во действий Быстродействие 20 Производительность видеосистемы 5 Качество НЖМД 8 Надежность и совместимость 11 Низкая цена 5 Итого 49
Таким образом, общая трудоемкость настройки свойств и
требований составила 112+49=161 действие пользователя. К этой величине следует
добавить еще 8 действий, связанных с настройкой системы на новый проект - выбор
пункта меню, ввод имени проекта, ввод описания проекта, выбор типа задачи, выбор
статуса проекта, ввод имени базы данных, нажатия кнопки ОК в окнах редактирования свойств и требований. Таким образом
полная трудоемкость настройки системы на решение контрольного примера составила
168 действий.
В итоге изучения настоящей главы были рассмотрены вопросы
реализации механизмов управления данными в универсальной экспертной системе.
Приведены описания основных логических структур данных, основных функций, дано
краткое руководство пользователя.
5.
ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ДИПЛОМНОЙ
РАБОТЫ
5.1.
Бизнес-план
5.1.1. Резюме
В настоящее
время стремительными темпами распространяются сетевые компьютерные технологии.
Предпосылками к этому служат процессы дальнейшего развития программных и
аппаратных средств вычислительной техники.
Появились
достаточно мощные и сравнительно дешевые аппаратные средства. Резко повысилось
быстродействие всех компонентов вычислительных систем. Это коснулось как
микропроцессорных устройств, так и других системных компонентов, таких как
администраторы системных шин, математические сопроцессоры, устройства
ввода-вывода.
Целью данной
дипломной работы является создание принципиально нового продукта
представляющего собой интеллектуальную
систему способную принимать единственно верное логическое решение среди
множества как взаимно исключающих, так и взаимно пересекающихся возможностей.
Это решение находиться путем сопоставления правил с фактами, что порождает так
называемую цепочку выводов - дерево решений.
Данный
программный продукт может применяться во многих областях народного хозяйства,
где необходимо участие человека для оценки ситуаций и принятия решений на
основе каких-либо первоначальных данных и фактах. Например: система, помогающая
химикам делать заключения о структурах химических соединений на основании
масс-спектрометрических данных; система для диагностирования
бактериальных инфекций; система-консультант в
области общей терапии. Данные примеры приведены на основе уже существующих
экспертных систем.
Данный
программный продукт будет отличаться от аналогичных программ дешевизной,
дружеским интерфейсом, широтой возможного использования, возможностью настройки
под конкретную задачу путем внесения в базу данных новых правил и фактов.
В настоящее
время на рынке программного обеспечения присутствует узкий круг ограниченных
программ, как правило зарубежных компаний производителей, следствием чего
интерфейс последних является критично нелояльным к местному пользователю.
Из
вышесказанного следует, что на нашем рынке программного обеспечения
образовалась ситуация благоприятная для реализации данной программы. Цена реализации
разработанной новой программы с учетом НДС
составляет 321 грн. Время окупаемости программы 0,2 года, годовой
экономический эффект составляет 166,17 грн./год. Учитывая относительно
невысокую себестоимость разрабатываемого программного продукта можно сделать
вывод о высокой прибыльности инвестированных вложений.
5.1.2. Описание программы
Возникновение
и бурное развитие в последние десять - пятнадцать лет различных теорий
искусственных нейронных сетей (ИНС) явилось проявлением и попыткой преодоления
драматического разрыва между огромным фактическим материалом, относящимся к
биологическим механизмам работы мозга, накопленным в нейрофизиологии в конце
XIX - начале XX веков, и неадекватностью имевшегося математического аппарата и
вычислительных средств его технической реализации.
Целью настоящей дипломной работы является
разработка структуры и алгоритмов взаимодействия программных блоков
интеллектуальной системы для оценки сложных объектов, построенной по принципу
«клиент\сервер». Поскольку проектирование всей системы - задача трудоемкая и
под силу лишь группе программистов, конкретно рассматривается проектирование
одного из блоков системы – блока управления данными и знаниями интеллектуальной
системы, построенной по принципу «клиент\сервер». Проектируемый блок
обеспечивает такие основные свойства системы как распределенность данных и
знаний, параллелизм при доступе и обработке данных, гибкость при настройке,
надежность и корректность всей информации.
Представленная программа позволяет проанализировать работу нейронной сети и
сформировать рекомендации для ее оптимизации.
5.1.3. Информация о возможных конкурентах
Одним из
первых был проект системы DENDRAL [23]. Исследовательская группа
DENDRAL была создана в Стенфордском университете в 1995 году для проектирования
системы, помогающей химикам делать заключения о структурах химических
соединений на основании масс-спектрометрических данных.
Не менее известными
экспертными системами, основанными на описанной модели, являются: MYCIN,
система для диагностирования бактериальных инфекций[ ]; INTERNIST --
система-консультант в области общей терапии[ ].
Каждая из
выше перечисленных ИС охватывает узкую и сравнительно хорошо определенную
предметную область. Система предназначается для решения одной и только одной
задачи, но решает эту задачу хорошо. Данный подход - ограничение предметной
области и круга задач ИС и выглядит как "метод шулера".
5.1.4. Стратегия
маркетинга
Сведения об
программном продукте будут посланы на центральные узлы компьютерных сетей,
доступ к которым имеют почти все предприятия и организации, имеющие
вычислительные центры. С ростом сферы распространения, цена на товар будет
снижаться. Будет организована БД по пользователям системы, которые при выпуске
новых версий системы будут поощряться системой скидок при повторных
приобретениях.
5.1.5. Организационный план
Учитывая перспективность
разработки данного продукта организуется общество с ограниченной ответственностью
. В качестве учредителей данного
общества выступают Овчаренко Д.В. и Крисилов В.А. , паи которых в основном
капитале составляют соответственно 60 % и 40%. Взносы в основной капитал учредителями производится компьютерным
оборудованием на сумму определенную законом. Государственная регистрация производится
в Малиновском районе г. Одессы (учитывая наибольшую лояльность налоговых
органов и возможность организации уставного капитала вышеописанным способом).
Расчетный счет открывается в КБ “Реал Банк” (учитывая
наиболее низкую стоимость кассового обслуживания последнего по
г. Одессе). В качестве сотрудников вновь созданного ООО будут выступать учредители,
в том числе в качестве программиста будет выступать Овчаренко Д.В. Также
необходимо отметить что учитывая род деятельности , в соответствии с уставом в
штатном расписании должность бухгалтера не числится, бухгалтерское обслуживание
будет осуществлять приходящий специалист Косатых М.В. В соответствии с
протоколом собрания учредителей 1 директором назначен Овчаренко Д.В.,
заместителем директора Крисилов В.А. Учредители участвуют в прибыли в
соответствии с внесенными паями.
5.1.6 План производства
Программные
продукты будут производиться на арендованной площади. В качестве оборудования
используемого в производстве применяется:
Компьютер DELL DIMENSION XPS
D333 333Mhz PENTIUM II PROCESSOR.
Принтер EPSON STYLUS COLOR 800.
Факс-модем ZYXEL OMNI-PRO 369.
Сканер HP Scan-Jet IIs.
Все указанное
оборудование было внесено учредителями
в основной фонд в качестве паев.
Расходные
материалы будут закупаться в магазине «Т&Д» по безналичному расчету.
Также можно отметить отсутствие неблагоприятного воздействия на окружающую
среду.
5.2. Функционально-стоимостной анализ
В данном разделе дипломной работы
применяется один из методов расчета для определения экономического показателя
программного продукта. Данный расчет основан на методе функционально-стоимостного
анализа (ФСА). Расчет позволяет снизить затраты при разработке программного
продукта путем выбора более рационального подхода к разработке программного продукта.
Это позволяет сократить совокупные затраты при одновременном повышении качества
разрабатываемого продукта.
Расчет основных экономических
показателей проводился с помощью электронных таблиц Microsoft Excel.
5.2.1 Построение дерева целей.
Определение генеральной цели
разработки, подцелей и задач ПО. Построение 3-х, 4-х уровней иерархической
схемы целей. Построения дерева целей.
Дерево целей для прогнозирующей системы
приведено на рис.5.1.
Рис. 5.1. Дерево
целей.
5.2.2. Построение структурной модели программы
Для проведения структурного анализа
программного обеспечения (ПО), базовая программа разбивается на отдельные блоки
с указанием взаимосвязей отдельных частей. При выделении структурных
компонентов ПО, руководствуются следующими требованиями к элементам:
относительная самостоятельность, существенность для процесса в целом,
устойчивая различимость. Структурная модель ПО представлена на рис.5.2.
На веpхнем уpовне пpедставляется объект
ФСА ПО в целом, а на последующих - его стpуктуpные составляющие в соответствии
с выбpанным пpизнаком стpуктуpизации. Связи между стpуктуpными составляющими
соседних уpовней пpедставляются в виде дуг гpафа, а сами составляющие объекта
ФСА ПО - в виде гpафа, который приведен на рис. 5.2.
Рис. 5.2. Структурная модель программы.
5.2.3. Построение
функциональной модели программы
Функциональная модель описывается в
графической формах, что дает возможность оптимального восприятия иерархической
группировки по назначению и распределению их по блокам структурной модели.
Значимость функций определяется специалистом, который выставляет функции баллы
в зависимости от важности решаемых ею задач в составе всей программы. Баллы по
всем функциям суммируются. Значимость функции есть отношение числа ее баллов к
сумме баллов всех функций.
Функциональная модель может быть
приемлемо описана в терминах графа. Функция, являющаяся вершиной куста, имеет
значимость равную сумме значимостей функций, составляющих ветви куста. Если
функция принадлежит ветвям различных кустов, ее значимость распределяется между
всеми ветвями. (см.рис.5.3)
Рис. 5.3. Функциональная
модель программы.
5.2.4 Расчет стоимости программных единиц
Для проведения ФСА необходимо
сопоставление значимости отдельных блоков программы с их стоимостью. Поэтому
важным является точный расчет затрат по функциям.
Для расчета выделяем элементарные
функции - они не имеют составных частей, т.е. нет последующего дробления этой
функции на более простые. В нашем примере, из рис.5.3 видно, что элементарными
являются: F111, F112, F121, F12, F211, F212, F221, F222, F23,F31, F32, F33.
Сумма их значимости должна быть равна 1.
Расчет затрат по функциям включает в
себя затраты на разработку и отладку программы.
Расчет затрат на материалы проводится
по формуле:
(5.1)
где:
Цi - цена единицы i-го
материала;
Ni - количество единиц i-го
вида материала, необходимого для
разработки ПО.
Заработная плата рассчитывается по
следующей формуле:
(5.2)
где:
Тi - трудоемкость i-го
этапа;
Цi - часовая тарифная ставка
разработчика на i-ом этапе.
При создании программы выделим 4
основных этапа:
разработка алгоритма 0.75 - 2
написание программы 1 [Тр]
отладка 0.8 - 1.2
разработка документации 0.2 - 0.4
где: цифры в столбце - коэффициент
трудоемкости разработки алгоритма отладки и разработки документации по отношению
к написанию программы. Время написания программы каждой отдельной функции
определяется по формуле:
Тр = Трн * Кс (5.3)
где:
Трн - нормативная трудоемкость
Кс - суммарный справочный коэффициент:
Кс=Кт*Ка*Кя (5.4)
где:
Кт - коэффициент, зависящий от типа
задачи;
Ка - коэффициент, учитывающий наличие
аналога в промышленности;
Кя - коэффициент, учитывающий язык.
Расчет по всем функциям проводился с
применением электронных таблиц MicrosoftExcel, поэтому приведем пример только
для одной функции F12.
Тнр = 4.0,Кт = 2.0,Ка = 0.6,Кя = 0.25,Kc = 0.3, Тр = 2*Кс = 4*2*0.6*0.25= 1.2
( грв. ).
Аналогично вычисляется среднее время на
разработку других функций.
Все 4-е этапа выполняет программист с
часовой тарифной ставкой – 1,1 грв.
Трудоемкость написания программы:
Трп = 1.00 * Тр
Трудоемкость разработки алгоритма:
Тра = 0.75 * Трп
Трудоемкость отладки:
Тро = 1.50 * Трп
Трудоемкость разработки документации:
Трд = 0.30 * Трп
Тогда для функции F12 получим: (см.
Таблицу 5.1)
Трп = 1.2,Тра = 0.9, Тро = 1.8, Трд = 0.36
З/П = (1.2+0.9+1.8+0.36)*1,1 = 4,69 (грв.)
Аналогично производится расчет основной
зарплаты для остальных функций. (см. Таблицу 5.1)Таблица 5.1
Расчет заработной платы по функциям Функц- Сумма Норма- Трудоёмкость Часовая ия рный коэф. . Тивная трудое- Мкость Трн. напис-ания програ-ммы Трп. Разра-ботки Алгори-тма Тра. Отла-дки Тро. разработки документации Трд. Тарифная ставка Зарплата F111 0,30 3,00 0,90 0,68 1,35 0,27 1,1 3,51 F112 0,30 11,00 3,30 2,48 4,95 0,99 1,1 12,89 F121 0,30 10,00 3,00 2,25 4,50 0,90 1,1 11,72 F12 0,30 4,00 1,20 0,90 1,80 0,36 1,1 4,69 F211 0,30 6,00 1,80 1,35 2,70 0,54 1,1 7,03 F212 0,30 7,00 2,10 1,58 3,15 0,63 1,1 8,20 F221 0,30 11,00 3,30 2,48 4,95 0,99 1,1 12,89 F222 0,30 8,00 2,40 1,80 3,60 0,72 1,1 9,37 F23 0,30 8,00 2,40 1,80 3,60 0,72 1,1 9,37 F31 0,30 7,00 2,10 1,58 3,15 0,63 1,1 8,20 F32 0,30 10,00 2,40 1,80 3,60 0,72 1,1 9,37 F33 0,30 12,00 3,60 2,70 5,40 1,08 1,1 14,06
3) Расчет затрат на материалы и
транспортно-заготовительные расходы (на 12 мая 1998г.):
При разработке и отладки базовой
программы использовались материалы:
красящая лента - 1 шт. (2грв.);
бумага пачка - 2 шт. (1 2,1 грв.);
ГМД - 1 уп. (2 3,5 грв.);
Зм = 2*1 + 12,1*2 + 23,5*1 = 49,7
(грв.)
Транспортно-заготовительные расходы
составляют 10% от стоимости материала, т.е. 4,97 грв.
4) Расчет дополнительной заработной
платы.
Зд = 0.1 * Зо
Например, для функции F12:
Зд = 0.1 * 4,69 = 0,47 (грв.)
Расчет остальных Зд сведен в таблицу
5.2.
5) Расчет отчислений на пенсионное
страхование, на социальное страхование на случай безработицы, в фонд Чернобыля,
сбор в инновационный фонд, на содержание дорог, коммунальный налог.
Отчисления на социальное страхование и пенсионный фонд:
Осс = 0.36 * (Зо + Зд)
Отчисления на социальное страхование на
случай безработицы:
Обз=0.015*(Зо+Зд)
В фонд Чернобыля:
Очер = 0.1 * (Зо + Зд)
В инновационный фонд:
Оиф = 0.09 * (Зо + Зд)
Сбор на содержание дорог:
Зид = (Зо + Зд)*0,1
Коммунальный налог :
З = Числен* 17* 0,05
;
Числен = ФОТ / Зср = ( Зо + Зд ) / 165.
6) Расчет расходов на служебные
командировки, услуги сторонних организаций, прочие прямые и накладные расходы.
Услуги сторонних организаций:
Ус = 0.15 * Зо
Расходы на служебные командировки:
Рс = 0.15 * Зо
Прочие прямые расходы:
Рпп = 0.1 * Зо
Накладные расходы:
Рн = 0.08 * Зо
7) Расчет плановой себестоимости.
Плановая себестоимость каждой функции
рассчитывается путем суммирования всех калькуляционных статей, перечисленных
выше.
Например, для функции F12:
C = 7,00 (грв.)
Результаты расчета себестоимости по
каждой функции сводены в таблицу 5.2.
Таблица 5.2.1
Расчет затрат на разработку и отладку
ПО Элементарные функции Сумма Наименование статьи F111 F112 F121 F12 F211 F212 затрат по статье 1 2 3 4 5 6 7 8 Основная зарплата 3,51 12,89 11,72 4,69 7,03 8,20 111,29 Дополнительная зарплата 0,35 1,29 1,17 0,47 0,70 0,82 11,13 Затраты на материалы 1,40 5,62 5,05 5,62 2,81 3,37 49,70 Транспортно-загот. Расходы 0,14 0,56 0,51 0,56 0,28 0,34 4,97 Отчисления на соцстрах и пенсионный Ф. 1,43 5,24 4,77 1,91 2,86 3,34 45,30 Отчисления в Ф. Чернобыля 0,46 1,70 1,55 0,62 0,93 1,08 14,69 Отчисления на случай безработицы 0,06 1,28 1,16 0,46 0,7 0,81 9,67 Сбор на содерж. дорог 0,42 1,23 1,24 0,53 0,71 0,82 11,03 Отчисления в инновац. фонд 0,35 1,28 1,16 0,46 0,7 0,81 11,34 Коммунальный налог 0,03 0,11 0,10 0,04 0,06 0,07 0,93 Расходы на служебные командировки 0,53 1,93 1,76 0,70 1,05 1,23 16,69 Услуги сторонних организаций 0,53 1,93 1,76 0,70 1,05 1,23 16,69 Прочие прямые расходы 0,35 1,29 1,17 0,47 0,70 0,82 11,13 Накладные расходы 0,28 1,03 0,94 0,37 0,56 0,66 8,90 Плановая себестоимость 5,53 20,78 18,83 11,49 11,05 13,00 180,76 Затраты на отладку 0,17 0,62 0,56 0,34 0,33 0,39 5,42 Общая себестоимость 5,69 21,40 19,40 11,83 11,38 13,39 186,19 Удельный вес общей с/с в суммарной 0,03 0,11 0,10 0,04 0,06 0,07 1,00 Оценка элементарных функций 5,00 20,00 18,00 20,00 10,00 12,00 177,00 Значимость функции -0,03 -0,11 -0,10 -0,04 -0,06 -0,07 -1,00
Таблица 5.2.2
Расчет затрат на разработку и отладку
ПО Элементарные функции Сумма Наименование статьи F221 F222 F23 F31 F32 F33 Затрат по статье 1 2 3 4 5 6 7 8 Основная зарплата 12,89 9,37 9,37 8,20 9,37 14,06 111,29 Дополнительная зарплата 1,29 0,94 0,94 0,82 0,94 1,41 11,13 Затраты на материалы 4,49 3,93 4,21 3,65 3,93 5,62 49,70 Транспортно-загот. Расходы 0,45 0,39 0,42 0,37 0,39 0,56 4,97 Отчисления на соцстрах и пенсионный ф. 5,24 3,81 3,81 3,34 3,81 5,72 45,30 Отчисления в Ф. Чернобыля 1,70 1,24 1,24 1,08 1,24 1,86 14,69 Отчисления в инновац. Фонд 1,28 0,93 0,93 0,81 0,93 1,39 11,34 Сбор на случай безработицы 0,21 0,93 0,93 0,81 0,93 1,39 9,67 Сбор на содерж. Дорог 1,31 0,93 0,86 0,79 0,87 1,40 11,03 Коммунальный налог 0,11 0,08 0,08 0,07 0,08 0,12 0,93 Расходы на служебные командировки 1,93 1,41 1,41 1,23 1,41 2,11 16,69 Услуги сторонних организаций 1,93 1,41 1,41 1,23 1,41 2,11 16,69 Прочие прямые расходы 1,29 0,94 0,94 0,82 0,94 1,41 11,13 Накладные расходы 1,03 0,75 0,75 0,66 0,75 1,12 8,90 Плановая себестоимость 19,54 14,94 15,25 13,31 14,94 22,11 180,76 Затраты на отладку 0,59 0,45 0,46 0,40 0,45 0,66 5,42 Общая себестоимость 20,13 15,39 15,71 13,71 15,39 22,77 186,19 Удельный вес общей с/с в суммарной 0,11 0,08 0,08 0,07 0,08 0,12 1,00 Оценка элементарных функции 16,00 14,00 15,00 13,00 14,00 20,00 177,00 Значимость функции -0,09 -0,08 -0,08 -0,07 -0,08 -0,11 -1,00
5.3. Построение и анализ
функционально-стоимостной диаграммы
Построение функционально-стоимостных
диаграмм по уровням функциональной модели осуществляется с целью выявления зон
согласования затрат на их значимость (при условии, что качество исполнения
функций соответствует заданному). На оси абсцисс отражаются Fj, на оси ординат
в 1-м квадранте - удельный вес стоимости функций в стоимости разработки Sfj, во
2-м квадранте - значимости функций Rfj Анализ функционально-стоимостной
диаграммы позволяет выявить зоны несоответствия затрат, качества и значимости
функций.
Рис. 5.4. ФСА диаграмма.
На диаграмме видно, что у функции F12 наблюдается несоответствие затрат и
значимостей, поэтому придется подвергнуть их дальнейшему анализу.
Рассматриваются различные возможности реализации этих
функций иными методами (принципиально иная запись блока, на другом языке
программирования и т.д.), учитывая совместимость с другими блоками данной программы.
В случае
невозможности изменения указанных блоков пересмотру подвергаются и остальные,
связанные с ними. После этого для них также производятся расчеты стоимости и
построения второй диаграммы.
В нашем случае представилось возможным добиться симметричности
графиков за счет изменения нормативных трудоемкостей по несимметричным
функциям ( см. табл. 5.3. и рис. 5.5.
).
Таблица 5.3.1
Расчет затрат на разработку и отладку
ПО Элементарные функции Сумма Наименование статьи F111 F112 F121 F12 F211 F212 затрат по статье 1 2 3 4 5 6 7 8 Основная зарплата 3,51 12,89 11,72 4,69 7,03 8,20 111,29 Дополнительная зарплата 0,35 1,29 1,17 0,47 0,70 0,82 11,13 Затраты на материалы 1,53 6,14 5,52 1,53 3,07 3,68 49,70 Транспортно-загот. Расходы 0,15 0,61 0,55 0,15 0,31 0,37 4,97 Отчисления на соцстрах 1,43 5,24 4,77 1,91 2,86 3,34 45,30 Отчисления в фонд Чернобыля 0,46 1,70 1,55 0,62 0,93 1,08 14,69 Отчисления в инновационный фонд 0,02 0,09 0,08 0,03 0,05 0,05 0,73 Сбор на содерж. дорог 0,41 1,3 1,19 0,52 0,71 0,80 11,03 Отчисл. На случай безработицы 0,06 1,28 1,16 0,46 0,7 0,81 9,67 Коммунальный налог 0,03 0,11 0,10 0,04 0,06 0,07 0,93 Расходы на служебные командировки 0,53 1,93 1,76 0,70 1,05 1,23 16,69 Услуги сторонних организаций 0,53 1,93 1,76 0,70 1,05 1,23 16,69 Прочие прямые расходы 0,35 1,29 1,17 0,47 0,70 0,82 11,13 Накладные расходы 0,28 1,03 0,94 0,37 0,56 0,66 8,90 Плановая себестоимость 5,67 21,35 19,35 7,00 11,34 13,34 180,76 Затраты на отладку 0,17 0,64 0,58 0,21 0,34 0,40 5,42
Таблица 5.3.1 ( продолжение ) 1 2 3 4 5 6 7 8 Общая себестоимость 5,84 21,99 19,93 7,21 11,68 13,74 186,19 Удельный вес общей с/с в суммарной 0,03 0,12 0,11 0,04 0,06 0,07 1,00 Оценка элементарных функции 5,00 20,00 18,00 5,00 10,00 12,00 162,00 Значимость функции -0,03 -0,12 -0,11 -0,03 -0,06 -0,07 -1,00
Таблица 5.3.2
Расчет затрат на разработку и отладку
ПО Элементарные функции Сумма Наименование статьи F221 F222 F23 F31 F32 F33 зат рат по статье 1 2 3 4 5 6 7 8 Основная зарплата 12,89 9,37 9,37 8,20 9,37 14,06 111,29 Дополнительная зарплата 1,29 0,94 0,94 0,82 0,94 1,41 11,13 Затраты на материалы 4,91 4,30 4,60 3,99 4,30 6,14 49,70 Транспортно-загот. Расходы 0,49 0,43 0,46 0,40 0,43 0,61 4,97 Отчисления на соцстрах 5,24 3,81 3,81 3,34 3,81 5,72 45,30 Отчисления в фонд Чернобыля 1,70 1,24 1,24 1,08 1,24 1,86 14,69 Отчисления в инновационный фонд 0,09 0,06 0,06 0,05 0,06 0,09 0,73 Отчисл. на случай безраб. 0,21 0,93 0,93 0,81 0,93 1,39 9,67 Сбор на содерж. Дорог 1,32 0,91 0,91 0,82 0,91 1,37 11,03 Коммунальный налог 0,11 0,08 0,08 0,07 0,08 0,12 0,93 Расходы на служебные командировки 1,93 1,41 1,41 1,23 1,41 2,11 16,69 Услуги сторонних организаций 1,93 1,41 1,41 1,23 1,41 2,11 16,69 Прочие прямые расходы 1,29 0,94 0,94 0,82 0,94 1,41 11,13 Накладн. расходы 1,03 0,75 0,75 0,66 0,75 1,12 8,90 Плановая себестоимость 20,00 15,34 15,68 13,68 15,34 22,68 180,76
Таблица
5.3.2
Продолжение Затраты на отладку 0,60 0,46 0,47 0,41 0,46 0,68 5,42 Общая себестоимость 20,60 15,80 16,15 14,09 15,80 23,36 186,19 Удельный вес общей с/с в суммарной 0,11 0,08 0,09 0,08 0,08 0,13 1,00 Оценка элементарных функции 16,00 14,00 15,00 13,00 14,00 20,00 162,00 Значимость функции -0,10 -0,09 -0,09 -0,08 -0,09 -0,12 -1,00
Рис. 5.4. Диаграмма
зависимости функций от их значимости.
В этом варианте расчетов мы наблюдаем
приблизительную симметричность диаграммы изображенной на рис.5.4. Считаем что
диаграмма, а значит и модель, оптимальна.
5.4.
Технико-экономические расчеты (на 12 мая 1998г.)
5.4.1. Расчет стоимости машино-часа на ЭВМ
Смч = V / Тплан (5.5)
где:
V - годовые эксплуатационные расходы;
Тплан - плановый годовой фонд времени
работы.
V = Зм + Зп + Зс + Зэ + За + Зр + Зн + Зпр, (5.6)
где:
Зм - затраты на материалы;
Зп- среднегодовая основная и
дополнительная
плата обслуживающего персонала;
Зс - Расчет отчислений на пенсионное
страхование, на социальное страхование на случай безработицы, в фонд Чернобыля,
сбор в инновационный фонд, на содержание дорог, коммунальный налог ;
Зэ - затраты на энергию;
За - годовые амортизационные
отчисления;
Зр - затраты на текущий ремонт;
Зпр - прочие прямые расходы;
Зн - накладные расходы;
При экстплуатации программы расходуются
следующие материалы
красящая лента - 1 шт. (2 грв.);
бумага пачка - 2 шт. (10 грв.);
ГМД - 1 шт. (2 грв.);
Зм = 2*1 + 10*2 + 2*1 = 2 4 (грв.)
Зп = 1.1 * Зо, (5.7)
где:
Зо - основная з/п
Зо = 12 * М * Ч , (5.8)
где:
М - месячный оклад обслуживающего
персонала;
Ч - численность обслуживающего
персонала.
Зо = 12* 200 *1 = 2 400 (грв.)
Зп = 1.1 * 2 400 = 2 640 (грв.)
Расчет отчислений на социальное страхование, в фонд Чернобыля,
фонд занятости населения.
Отчисления на социальное страхование и пенсионный фонд:
Осс = 0.36 * (Зо + Зд) ;
Осс=0,36*2640
= 950 (грн.)
Отчисления на социальное страхование на
случай безработицы:
Обз=0.015*(Зо+Зд) = 0,015*2640 = 39,6 (грн.)
В фонд Чернобыля:
Очер = 0.1 * (Зо + Зд) = 0,1*2640 = 264
(грн.)
Сбор на содержание дорог:
Зд = (Зо + Зп)*0,1 = 0,1*2640 = 264
(грн.)
В инновационный фонд:
Оиф = 0.09 * (Зо + Зд) = 0,09*2640 = 237 (грн.)
Коммунальный налог :
З к = Числен *17 *0,05= 13,6
(грн.) ;
Числен = ФОТ / Зср = ( Зо + Зд ) / 165 = 16
Все отчисления за 1998 г.
Зс = 1530(грв.)
Зэ = Тплан * Р * См * Rр , (5.9)
где:
Р - удельная мощность ПЭВМ;
См - стоимость одного кВт/час; (1998г.-
0,09 грв )
Rр - коэффициент использования
мощности.
Тплан = Д * m * tсм * (1 - Ам), (5.10)
где:
Д - количество дней в году;
m - количество смен;
tсм - продолжительность одной смены
исходя из среднесуточной нагрузки;
Ам - коэффициент
ремонтно-профилактических работ.
Р = 0.07 кВт/час Д = 255
См = 0,09 грв. m = 1
Rр = 0.9 tсм = 7.5 час.
Ам = 0.2
Тплан = 255*1*7.5*(1 - 0.2) = 1530
(часов)
Зэ = 1530 *0.07*0,09*0.9 = 8,68 (грв.)
(5.11)
где:
Цо - стоимость основного оборудования;
Змн - затраты на монтаж, наладку
основного оборудования;
Цв - стоимость вспомогательного
оборудования;
Зтрм - затраты на транспорт, монтаж;
Нвт о - норма основных амортизационных
отчислений;
Нвт в - норма вспомогательных
амортизационных отчислений;
Cs - стоимость квадратного метра
площади;
S - площадь здания для размещения
оборудования;
Цо = 2 000 грв. Цв = 0
Змн = 140 грв. Зтрм = 0
S = 10 кв.м
Нвт в = 25%
Cs = 5 грв.
За = (2 000 + 140)*0.25 + 5*10 = 585 (грв.)
Зр = Цо * Кр , (5.12)
где:
Кр - коэффициент, учитывающий затраты
на текущий ремонт. (Кр = 0.025)
Зр = 2 000*0.025 = 50(грв.)
Зн = Зо * Кн , (5.13)
где:
Кн - коэффициент, учитывающий удельный
вес накладных расходов (Кн = 0.9).
Зн = 2 400*0.9 = 2160 (грв.)
Зпр = Зо * Кпр. , (5.14)
где:
Ктр - коэффициент, учитывающий удельный
вес транспортных расходов (Кн = 0.15).
Зпр. = 2 400*0.15 = 360 (грв.)
V = 24 + 2 640 + 1530 + 8,68 + 585 + 50
+ 2160 + 360 = 7357,68 (грв.)
Смч = 7357,68 / 1 530 = 4,81 ( грв.)
5.4.2. Расчет сметной стоимости НИ
ОКР и цены программы
Цена базовой программы рассчитывается по следующей формуле:
Цб = Сб + 0,3*Сб
Цб = 186,19 +
0,3*186,19 = 242 (грн.)
Цена новой программы:
Цн = Сн + 0.3*Сн*Кк , (5.15)
где:
Сн - суммарная себестоимость программы.
где
Кк - коэффициент качества.
Оценка уровня качества каждого варианта
ПО проводится по тем показателям качества, которые изменились (с учетом целей
ФСА) в следующем порядке: выбираются критерии на основе целей ФСА; оцениваются
коэффициенты весомости критериев bi; количество критериев n; проводится бальная
оценка Xi степени удовлетворения каждого варианта данному критерию
экспериментальным методом; для каждого варианта расчитывается комплексный
показатель качества Кк. Критерий Значимость Баллы X; по вариантов bi Xi bi Xi Новое Базов. Надежность Скорость Удобство Число ре- зультатов 6 8 9 3 4 7 4 1 1 3 5 2 24 56 36 3 6 24 45 6 Итого 119 81
bi Xi нов
Кк = ------------ = 1.47
bi Xi баз
Цнов = 186,19 + 0.3*186,19*1.47 = 268,23 (грн.)
Цнов.р. = Цнов + НДС = 268,23 + 268,23*0,2=321 грн.
5.4.3 Расчет
эксплутационных издержек у потребителя.
Эксплуатационные издержки потребителя рассчитываются по
следующей формуле:
Uзд = Смч * n * t ,
где t - срок эксплуатации программы.
tб - 1.1 год;
tн - 1 год.
Uзд б =
Смч б*пб*б = 4,8*288*1.1 = 1479,46
Uзд н =
Смч н*пн*н = 4,8*288*1 = 1344,96
5.4.4 Расчет
годового экономического эффекта
и показателей эффективности.
Годовой
экономический эффект расчитывается по следуещей
формуле:
Uзд
б Uзд н Сб Сн nн
nб
Эг = ( ------
- ------ ) + (---- - ----) + (---- - --- ),
Nб Nн Nб Nн Nн Nб
где Nб - число
организаций-пользователей базовой программы;
Nн - число
организаций-пользователей новой программы;
nн,б -
базовая и новая прибыль от реализации первого и
второго варианта программы.
nб = 0.3*Сб
= 0.3*186,19 = 55,85
nн = nб*Кк
=55,85*1.47 = 82,09
Nб = Nн = 1
Эг =
(1479,46 - 1344,96 ) + (186,19 –
180,76) + +(82,09 - 55,85) =166,17 (грн./год)
Срок окупаемости
программы расчитывается по следующей формуле:
Цн Цб
---- -
----
Nн Nб
Т =
--------------
зд
б зд н
-----
- ----
Nб Nн
268,23 - 242
Т = ----------------------- = 0.2 (год.).
1479,46 –
1344,96
5.5. Выводы
В данной дипломной работе был применен
один из расчетов для определения экономического показателя программного продукта.
Данный расчет основан на методе функционально-стоимостного анализа (ФСА).
Расчет показал, что создание программного продукта, представленного в дипломной
работе является экономически целесообразным.
6. БЕЗОПАСНОСТЬ
ЖИЗНЕДЕЯТЕЛЬНОСТИ.
6.1. Обоснование
выбора объекта.
Тема данной дипломной работы
связана с интенсивным использованием ПЭВМ на этапах разработки и тестирования
создаваемого алгоритма. В связи с этим вопросы защиты пользователей ПЭВМ от
разнообразных вредных воздействий, возникающих в процессе работы с компьютерной
техникой актуальны .
Большое
значение для обеспечения безопасных условий труда оператора ПЭВМ имеет
правильное и достаточное освещение рабочего места, что будет способствовать
предупреждению возникновения различных зрительных нарушений, повышению работоспособности и уменьшению усталости.
Учитывая вышесказанное, в качестве темы исследования автором был
выбран расчет естественного и искусственного освещения в лаборатории ПЭВМ.
6.2. Особенности
труда пользователей ЭВМ.
6.2.1. Общие сведения.
Визуальные дисплейные терминалы (ВДТ) в настоящее время
являются основным средством взаимосвязи человека с ЭВМ. Ускоренное внедрение
ЭВМ (персонального и коллективного пользования) практически во все области
деятельности, ведёт к появлению большого количества рабочих мест с ВДТ. Они
широко распространяются как на различные производства в различных системах контроля
и управления, так и в различных административно-общественных зданиях, где
размещаются вычислительные центры организации и институтов, читальные и
справочные залы библиотек, компьютерные залы школ, техникумов, и , в конце
концов , офисов и частных квартир.
По данным Всемирной
организации здравоохранения, профессиональная деятельность с ВДТ может в
отдельных случаях приводить к нарушениям со стороны зрительного анализатора человека,
костно-мышечным (неправильная поза) и нарушениям связанным со стрессовыми
ситуациями и нервно-эмоциональным напряжением при работе, кожным заболеваниям и
т.д.
Сотрудники института медицины труда в течение многих лет
проводят разносторонние исследования труда пользователей ЭВМ, связанные с
изучением характера и условий их труда, функциональных изменений в динамике
выполнения трудовых заданий, заболеваемости и состояния здоровья.
Эти исследования показывают, что современная профессия
пользователя ЭВМ представляет собой модель умственного труда, выполняемого в
однообразной позе в условиях ограничения мышечной активности при подвижности
кистей рук, при высоком напряжении зрительных функций и нервно-эмоциональном
напряжении в условиях воздействия многих физических факторов. Установлено, что
состояние организма пользователей по субъективным и объективным показателям
зависит от типа работа у экрана и условий её выполнения. Все пользователи
подразделяются на программистов (разработчиков и пользователей программ) и операторов
прецизионных работ, а также вода и вывода данных. Непрофессионалы -–это
кассиры, библиотекари, студенты, школьники и т.д.
В период работы с ВДТ на электронно-лучевых трубках на
организм пользователей действует целый ряд факторов физических факторов, но все
они находятся в пределах и значительно ниже нормированных величин в
соответствии с действующими в настоящее время нормативными документами.
При исследовании зрительных функций в лабораторных и
производственных условиях были обнаружены расстройства аккомодации,
конвергенции, остроты зрения и контрастной чувствительности глаза. Причем
обнаруженные изменения носили более глубоким характером, когда работа
сопровождалась высоким нервно-эмоциональным компонентом. Например, поиск ошибок
в программе или её отладка в условиях дефицита времени.
Патологические изменения зрительного анализатора как
следствие производственной деятельности у пользователей ЭВМ практически не встречаются. Однако
физиологические исследования показывают, что у большинства программистов
наблюдаются некоторые нарушения функций аккомодации и контрастной чувствительности
глаза.
Отрицательное действие ВДТ у большинства пользователей
проявляется в виде рези, жжения, боли в глазах, ломоты надбровной области, а
также в виде размытия границ объекта, вызванного временными нарушениями
светочувствительности аппарата глаза.
Эти явления часто сопровождаются головной болью, тяжестью в
голове, общей усталостью, сонливостью, вялостью.
В формировании зрительного утомления у пользователей огромную
роль играет специфика зрительной работы с экраном.
В соответствии с действующими нормативами видеотерминал –
это устройство для оперативного ввода и вывода данных из ЭВМ, для отображения
на экране информации в форме, удобной для пользователя.
Светотехническая специфика рабочих мест с ВТ вызвана
следующими пятью уникальными особенностями:
1)
Светотехническая разнородность объектов зрительной работы
пользователей ЭВМ, работающих с ВДТ, связана с наличием трёх объектов (экран,
клавиатура, документация), расположенных в разных зонах, что требует
многократного перевода линии зрения от одного объекта к другому. Условия
расположения этих трёх объектов неосознанно ассоциируются с «взглядом вдаль»,
когда аккомодационные и конвергирующие мышечные механизмы совсем расслаблены,
хотя для достижения качественного различения знаков на дисплее они должны интенсивно
работать, с целью обеспечить остроту зрения, к тому же при непривычном
расстоянии до объекта. Эти особенности создают неудобства, а также напряжение
мышечного и светоощущающего аппарата глаз, что и является одной из главных
причин возникновения астенопических явлений.
2)
Работа с пульсирующими самосветящимися объектом, постоянно
находящимся в поле зрения.
3)
На рабочем месте имеет место неблагоприятное распределение
яркости в поле зрения.
4)
Слепящее действие светильников, освещающих помещение на рабочем месте с ВТ больше чем на других.
5)
Наличие зеркально отражающей поверхности ЭЛТ не позволяет
полностью устранить из поля зрения пользователя все отраженные блики. Виды излучений Диапазон Фактические данные замера Нормируемые значения Рентгеновское Более 1,2 Кэв 9-12 мк Р/час 75 мк Р/час Ультрафиолетовое 220-280 нм 280-320 0 0-0,02 0,01Вт 0,01Вт Видимый диапазон 320-400 нм 400-700 нм 0,1-2,0 2,5-4,0 10 Вт/м2 Яркость 75-80 кД/м2 Не менее 35 кД/м2 ИК излучение 700нм – 1мм 0,05-4,0 100 Вт/м2 Электростатическое поле 0 гц 15 Кв/м 20-60 Кв/м
Таблица 6.1. Виды
электромагнитных излучений ВДТ.
6.2.2. Рекомендации по организации рабочих мест пользователей.
Анализируя
выше написанное можно дать следующие рекомендации для сохранения
работоспособности пользователей ЭВМ и устранения возможности возникновения
общих и зрительных нарушений:
·
в дисплейных классах температура должна составлять
19-21°С,
относительная влажность воздуха 55-56%, скорость движения воздуха не более
0,2м/с
·
уровни звука не должны превышать 50 ДБ. Учитывая, что
основным источником шума в дисплейных классах является принтер и, принимая во
внимание повсеместное использование практически бесшумных струйных принтеров,
этого требования достичь не трудно
·
Необходимы некоторые приёмы борьбы со статическим электричеством.
Для этого рекомендуется в дисплейных классах пол покрывать антистатическим
линолеумом
·
Учитывая специфику работы оператора ЭВМ, связанную со
значительной зрительной нагрузкой, первоочередной задачей является обеспечения
приемлемых условий визуальной работы пользователей за счёт наилучшего
распределения яркостей в поле зрения работающего и максимально возможного
уменьшения ослеплённости от прямых и отраженных бликов. Необходимо обеспечить
как количественные, так и качественные параметры освещения.
Из
выше написанного следует, что жизненно важным для повышения работоспособности
пользователя и сохранения его здоровья, является правильная организация
освещенности рабочего места пользователя. Параметры освещения начинать выбирать
надо с выбора помещения:
при
выборе помещения необходимо учитывать, что окна могут создавать блики на
экранах дисплеев и вызывать значительную ослеплённость у сидящих перед ними.
Поэтому рекомендуется использования помещения с односторонним расположением
световых проёмов, обязательно снабженных солнцезащитными устройствами: шторами,
жалюзи и т.д. Необходимо по возможности также обеспечить отделку интерьера
имеющего невысокий коэффициент отражения. Поэтому не рекомендуется светлая
отделка стен помещения, а также использования светлой мебели. Все отделочные
материалы должны быть матовыми.
Очень
важно правильно расположить рабочие места пользователей: расположение рабочего
места пользователя лицом либо спиной к оконному ряду недопустимо. Выбор типа
светильника по светораспределению и способу расположения в помещении зависит от
высоты помещения, количества рабочих мест
и некоторых других факторов.
Рабочие
места следует располагать рядами
параллельно оконному ряду, таким образом, чтобы плоскость экрана пользователя
была перпендикулярна плоскости оконного ряда. Наиболее оптимальным является
вариант использования люминесцентных светильников дневного света.
Светильники
должны располагаться над проходами между рядами рабочих мест сплошной линией
или линией с разрывами в зависимости от количества светильников в линии, для
обеспечения нормируемой освещенности рабочих мест пользователей.
Внедрение вышеописанных
рекомендаций при выборе расположения и организации рабочего места пользователей
ЭВМ, значительно снизит жалобы пользователей на усталость и утомление,
предупредит появление и развитие общих зрительных и других нарушений, а также
повысит работоспособность пользователей.
6.3. Расчёт
системы освещения.
6.3.1. Индивидуальное задание.
Работы по диагностированию функционирования устройств будут
проводится в прямоугольном помещении, размерами:
длина А =8 м.;
ширина В = 5 м.;
высота Н = 3.4 м.
Для освещения
помещения используются потолочные светильники УСП 35 с двумя люминесцентными
лампами мощностью 40Вт (световой поток 3120 Лм).
Коэффициенты
отражения светового потока от потолка, стен и рабочей поверхности
соответственно равны 70%, 50%, 10%. Затемнения рабочих мест нет.
В помещении
установлены стеклопакеты от фирмы «Inter windows» площадью So = 6 м2,
со световой характеристикой окна
ro = 4.
Кроме того, зададим коэффициент затемнения зданиями Кзд = 1.
6.3.2. Общие теоретические сведения.
Важным требованием к гигиеничности производственного помещения
является достаточное освещение, так как человек воспринимает около 80% всей
информации через зрительные рецепторы. Плохое освещение подчас является
причиной примерно 5% несчастных случаев на предприятиях, а в 20% несчастных
случаев оно прямо или косвенно приводит к травматизму.
Рабочие места
пользователей, работающих с дисплеями, должны быть расположены как можно дальше
от окон и таким образом, чтобы оконные проёмы находились сбоку.
В целях создания
комфортных условий, каждому работающему подбирают высоту и угол наклона
клавиатуры, экрана и сиденья. Рабочее место обычно располагают на высоте 74 см.
от пола.
Исследуем
освещенность помещения, где будет расположено диагностируемое устройство, а
также аппаратные средства для его диагностирования.
Различают два вида
освещенности:
-
естественное освещение;
-
искусственное освещение.
6.3.3. Расчёт естественной освещенности.
Естественное освещение отличается гигиеничностью и экономичностью.
Оно определяется как отношение внутренней освещенности в некоторой заданной
точке помещения (ЕВ) к одновременному значению наружной горизонтальной
освещенности (ЕН), создаваемой светом полностью открытого небосвода и
выражается коэффициентом естественной освещённости (КЕО):
E=100%*EВ/ЕН (I)
Нормирование освещенности производится в соответствии со
строительными нормативами и правилами СНиП 11-4-79.
Согласно СниП 11-4-79 значения КЕО нормируются в зависимости
от характеристики зрительной работы. Работа на ЭВМ, с помощью которой будет
производится диагностирование устройств, соответствует четвёртому разряду
зрительной работы. Нормированный коэффициент (е4н) определяется по формуле:
е4н = е3н *м*с (II)
где е3н – нормированное значение КЕО для третьего пояса в
соответствии с четвёртым разрядом зрительной работы е3н = 1.5%, м – коэффициент
светового климата, с – коэффициент солнечности.
Так как город Одесса расположен в четвёртом поясе светового
климата, то для него значения коэффициентов выбираются равными м = 0.9; с=0.95.
Следовательно:
е4н = 1.5*0.9*0.95 = 1.28%
По классическому методу Данилюка определяем естественную
фактическую освещенность в помещении по формуле:
So*t0*t1*100 (III)
Sn*ro*Kзд
где So/Sn – отношение площади световых проёмов к площади
пола помещения;
to – общий коэффициент светопропускания;
t1 – коэффициент, учитывающий влияние отраженного света при
боковом освещении;
ro – световая характеристика окна;
Кзд – затемнение окон противостоящими зданиями.
Для нашего примера имеем:
So = 6 m2;
Sn = 40 m2;
to = 0.3136;
t1 = 1.35;
ro = 4;
Кзд = 1.
Следовательно, получим:
en = 6*0.3136*1.35*100 / 40*4*1
= 1.58%
Расчёт
показывает, что фактическая освещенность выше требуемой, что свидетельствует о
том, что помещение достаточно освещено.
6.3.4. Расчёт искусственного освещения помещения.
В
тёмное и переходное время суток в помещении необходимо организовать
искусственное освещение.
Необходимо
рассчитать мощность осветительной установки и определить схему расположения
светильников для искусственного освещения, используемого помещения.
Наиболее
благоприятным с гигиенической точки зрения являются люминесцентные лампы
дневного света. В качестве источников света выберем светильники с
люминесцентными лампами ЛБ80-4, которые создают световой поток на 2470 Лм.
Вычисления
будут производится по методу коэффициента использования светового потока,
предназначенного для расчёта освещенности общего равномерного освещения
горизонтальных поверхностей. Для освещения помещений компьютерных классов (к
коим можно отнести используемое помещение) обычно используют люминесцентные
лампы, у которых высокая светоотдача, продолжительный срок службы, малая
яркость светящейся поверхности, близкий к естественному свету спектральный
состав излучения, что обеспечивает
хорошую цветопередачу цветных графических дисплеев, что особо важно при работе
с CAD и CAM приложениями, а также другими графическими пакетами (Corel Draw,
Adobe Photoshop и др.). Для исключения появления зон затемнения в середине
помещения, а также для более равномерной освещенности рабочих мест светильники располагаем перпендикулярно линии
зрения оператора ЭВМ.
Согласно
отраслевым нормам освещенности уровень рабочей поверхности над полом для
компьютерных классов составляет 0.8м. и установлена норма освещённости Е = 400
Лк.
h
= H – 0.8 = 3.4 – 0.8 = 2.6 (м), (IV)
где h – расчётная высота
подвеса светильников над рабочей поверхностью.
Экономичность осветительной установки зависит от отношения:
Л=L/h (V)
где L – расстояние между
рядами светильников, м.
Для светильников УСП 35 лучшее
отношение Л = 1.4.
Отсюда расстояние между рядами
светильников:
L = Л * h = 1.4 * 2.6 = 3.64 (м). (VI)
Два ряда светильников будут расположены вдоль длинной стены
помещения. Расстояние между рядами светильников и стенами:
L = (A – L) / 2 = (5 – 3.64) / 2
= 0.68 (м) (VII)
Определим индекс помещения:
I = A*B / (A+B) * h = 8 * 5 / (8
+ 5) * 2.6 = 1.18 (VIII)
С учётом выше написанного при рассчитанном индексе помещения,
из справочных данных находим коэффициент использования излучаемого
светильниками светового потока h = 0.59. Расчёт необходимого числа светильников
выполняем по формуле:
N = ( E * k * S * z ) / ( n * ф *
h ) (IX)
где: Е – норма освещённости компьютерного класса, Е = 400
лк;
k – коэффициент запаса, учитывающий запыление светильников и
износ источников света в процессе эксплуатации, к = 1.5.
S – площадь помещения, S = 8 * 5 = 40 м2;
z – коэффициент неравномерности освещения,
z = 1.1;
n – число рядов светильников, n =
2;
h - коэффициент
использования светового потока, h = 0.59;
ф – световой поток, излучаемый
светильником.
Для лампы ЛБ40
номинальный световой поток, излучаемый светильником, равен 3120лм, учитывая, что
в светильнике две люминесцентных лампы,
имеем:
Ф = 2ф = 2 * 3120
= 6240лк.
Подставляя
численные значения в (IX), имеем:
N = 400 * 1.5 * 40
* 1.1 / ( 2 * 6420 * 0.59 ) = 3.5 (шт) » 4
(шт).
Длина одного
светильника УСП35 составляет д = 1.27 м.
При поперечном расположении расстояние между светильниками
составит:
Расстояние между
светильниками = А / n1 = 8/5=1.6
(м)
Где n1
количество промежутков между светильниками и короткими стенами.
Заключаем, что в
компьютерном классе устанавливаются два ряда светильников УСП 35 по четыре в
ряду вдоль длинных стен помещения, на расстоянии 3.64 м. ряд от ряда и на 0.68
м. от длинных стен помещения. Расстояние между светильниками в ряду и между
светильниками и короткими стенами помещения 1.6 м.
Схема расположения светильников приведена на рис.6.1
5 0рр1.6 3.2
8
Рис.6.1.
Расположение светильников.
6.4. Выводы по
изучению вопроса о безопасности
жизнедеятельности.
Полностью
безопасных и безвредных производств не существует. Однако задача охраны труда –
свести к минимуму вероятность несчастного случая или заболевания работающего с
одновременным обеспечением комфортных условий при максимальной
производительности труда.
Так основная часть
данной дипломной работы выполнялась на компьютере и реализация описываемого
метода, в основном, также будет производиться на компьютере, очень важно
обеспечить оператору достаточную освещенность рабочего места для предотвращения
усталости глаз и ухудшения зрения. Выше была рассчитана схема расположения
светильников для создания максимально комфортных условий оператору, с целью
повышения его работоспособности и предупреждения появления и развития
зрительных и других нарушений.
ЗАКЛЮЧЕНИЕ
В ходе разработки интеллектуальной системы на базе технологии
«клиент-сервер» достигнуты основные цели, поставленные перед началом
проектирования.
Была разработана архитектура, структура данных, алгоритмы
взаимодействия, программных модулей, образующих ИС на базе применения последних
разработок в области технологий «клиент-сервер». В ходе выполнения дипломной
работы были выполнены следующие задачи:
- исследована структура и функции ИС в целом и ее отдельных
программных блоков - АРМ-ов администратора системы, эксперта, лица принимающего
решения (руководителя), рядового оператор хранения компонентов модели;
- разработаны структуры данных и основные функции перечисленных
автоматизированных рабочих мест.
- разработан порядок взаимодействия всех компонентов в
целом.
- выполнена
программная реализация модуля администратор.
Перспективы развития сетевой интеллектуальной системы
определяются факторами, изложенными во введении к настоящей дипломной работе.
Следует добавить, что основные пути развития представляются автору разработки
наиболее целесообразными в следующих областях:
- использование новых технологий управления базами данных,
широко развивающихся в последние несколько лет;
- учет знаний группы экспертов позволит существенно повысить
достоверность получаемых результатов;
- использование технологии связывания и внедрения объектов (OLE) позволит эффективно
обмениваться данными с другими приложениями.
Тем не менее работе присущ ряд недостатков. Прежде всего это
высокая сложность управления проектами и распределенными данными. Этот
недостаток стал очевидным лишь к концу разработки системы и исправление его
привело бы к недопустимым затратам времени.
Несмотря на недостатки можно сказать, что основная цель
работы достигнута.
ЛИТЕРАТУРА
1.
Aбу-Мустафа Я.С., Псалтис Д. Оптические нейронно-сетевые
компьютеры//В мире науки. 1987. N 5. С. 42-50.
2.
Вольфенгаген В.Э., Воскресенская О.В., Горбанев Ю.Г. Система
представления знаний с использованием семантических сетей//Вопросы кибернетики:
Интеллектуальные банки данных. -М.: АН СССР, 1979. - С. 49-69.
3.
Вудс У.А. Основные проблемы представления знаний//ТИИЭР. -
1986. - Т.74, N 10. -С. 32-47.
4.
Гаврилова Т.А. Представление знаний в экспертной диагностической
системе АВТАНТЕСТ//Изв. АН СССР. Техн. кибернетика. - 1984. - N 5. - С. 165-173.
5.
Ивашко В.Г., Финн В.К. Экспертные системы и некоторые проблемы
их интеллектуализации//Семиотика и информатика. -1986. - Вып.27. - С.25-61.
6.
Кирсанов Б.С., Попов Э.В. Отечественные оболочки экспертных
систем для больших ЭВМ//Искусственный интеллект: Справочник. - Т.1. - М.: Радио
и связь, 1990. - С. 369-388.
7.
Ковригин О.В., Перфильев К.Г. Гибридные средства представления
знаний в системе СПЭИС//Всесоюзная конференция по искусственному интеллекту:
Тез. докл. - Переславль-Залесский, 1988. -Т.2.- С.490-494.
8.
Кук М.Н., Макдональд Дж. Формальная методология приобретения и
представления экспертных знаний. - ТИИЭР. - Т.74, N 10. - 1986. -С.145-155.
9.
Минский М. Фреймы для представления знаний. - М.:Мир, 1979.
-151 с.
10.
Минский М., Пейперт С. Персептроны. М.:Мир, 1971. С. 261.
11.
Нечеткие множества в моделях управления и искусственного
интеллекта/А.Н. Аверкин, И.З. Батыршин, А.Ф. Блишун и др.- М.: Наука, 1986.
-312 с.
12.
Осипов Г.С. Метод формирования и структурирования модели
знаний для одного типа предметных областей//Изв. АН СССР. Техн. кибернетика. -
1988. -N 2. -С.3-12.
13.
Осуга С. Обработка знаний: Пер. с япон. - М.: Мир, 1989. -292
с.
14.
Попов Э.В. Экспертные системы: Решение неформализованных задач
в диалоге с ЭВМ. -М.: Наука, 1987. -288 с.
15.
Построение экспертных систем/Под ред. Ф. Хейес-Рота, Д.
Уотермана, Д. Лената. -М.: Мир, 1987. -С. 434.
16.
Представление и использование знаний/Под ред. Х. Уэно, М.
Исидзука. -М.: Мир, 1989. -220 с.
17.
Приобретение знаний: Пер. с япон./Под ред. С. Осуги, Ю. Саэки.
-М.: Мир, 1990. -304 с.
18.
Скрэгг Г. Семантические сети как модели памяти//Новое в
зарубежной лингвистике. -М.: Радуга, 1983. -Вып. XII. -С.228-271.
19.
Тэнк Д.У., Хопфилд Д.Д. Коллективные вычисления в нейроноподобных
электронных схемах//В мире науки. 1988. N 2. С. 44-53.
20.
Уотермен Д. Руководство по экспертным системам: Пер. с англ.
-М.: Мир, 1989. -388 с.
21.
Хоггер К. Введение в логическое программирование. - М. Мир,
1988. -348с.
22.
Экспертные системы. Принципы работы и примеры: Пер. с
англ./Под ред. Р. Форсайта. -М.: Радио и связь, 1987. -224 С.
23.
Элти Дж., Кумбс М. Экспертные системы: Концепции и примеры:
Пер. с англ. -М.: Финансы и статистика, 1986. -191 с.
24.
Aarts
E.H.L., Korst J.H.M. Boltzmann machines and their applications//Lect. Notes
Comput. Sci. 1987. V. 258. P. 34-50.
25.
Aarts
E.H.L., Korst J.H.M. Boltzmann machines for travelling salesman
problem//European J. Oper. Res. 1989. V. 39. P. 79-95.
26.
Abu-Mostafa
Y.S., Jaques J.N.St. Information capacity of the Hopfield model//IEEE Trans.
Inform. Theory. 1985. V. 31. P. 461.
27.
Ackley
D.H., Hinton G.E., Sejnowski T.J. A learning algorithm for Bolzmann
machines//Cognit. Sci. 1985. V. 9. N 1. P. 147-169.
28.
Amari
S. Field theory of self-organizing neural networks//IEEE Trans. Syst., Man,
Cybern. 1983. V. 13. P. 741.
29.
Athale
R., Stirk C.W. Compact architectures for adaptive neuraal nets//Ibid. 1989. V.
28. N 4. 34. Boahen K.A., Pouliquen P.O., Andreou A.G., Jenkins R.E. A
Heteroassociative memory using current-mode MOS analog VLSI circuits//IEEE
Trans. Circuits Syst. 1989. V. 36. N 5. P. 747-755.
30.
Carpenter
G.A., Grossberg S. A massively parallel architecture for a self-organizing
neural pattern recognition machine//Comput. Vision Graphics Image Process.
1986. V. 37. P. 54-115.
31.
Cohen
M.A., Grossberg S. Absolute stability of global pattern formation and parallel
memory storage by competitive neural networks//IEEE Trans. Syst., Man, Cybern.
1983. V. 13. N 5. P. 815-826.
32.
Fox
G.C., Koller J.G. Code generation by a generalized neural networks: general
principles and elementary examples//J. Parallel Distributed Comput. 1989. V. 6.
N 2. P. 388-410.
33.
Hammond
P. Logic programming for expert systems//M. Sc. Thesis, Dept. of Computing.
Imperial College, Univ> of London, England. 1980.
34.
Hammond
P. APES: a user manual. //Doc Report 82/9. 1983.
35.
Hebb
D.O. The organization of behaviour. N.Y.: Wiley, 1949.
36.
Hopfield
J.J. Neural networks and physical systems with emergent collective
computational abilities//Proc. Natl. Acad. Sci. 1984. V. 9 P. 147-169.
37.
Hopfield
J.J., Feinstein D.I., Palmer F.G. Unlearning has a stabilizing effect in
collective memories//Nature. 1983. V. 304. P. 141-152.
38.
Hopfield
J.J., Tank D.W. Neural computation of decision in optimization problems//Biol.
Cybernet. 1985. V. 52. P. 141-152.
39.
McCulloch
W.S., Pitts W.H. A logical calculus of the ideas immanent in nervous activity//Bull.
Math. Biophys. 1943. V. 5. P. 115-133.
40.
Newell
A., Simon H. Computer simulation of human thinking//Science. 1961. P.
2011-2017. 49. Newell A., Simon H. Human problem solving//Englewood Cliffs,
N.Y. 1972.
41.
Newell
A., Shaw J.C., Simon H. Chess playing programs and the problem of complexity
IBM//J. Res. Develop. 1958. P. 320-335.
42.
Ohta
J., Tai S., Oita M. et. al. Optical implementation of an assoñiative
neural network model with aa stohastic process//Ibid. 1989. V. 28. N 12. P.
2426-2428.
43.
Rosenblatt
F. The peseptron: a probabilistic model for information storage and
organization in the brain//Psychol. Rev. 1958. V. 65. P. 386.
44.
Rosenblatt
F. Principles of neurodynamics. Spartan., Washington, D.C., 1962.
45.
Simon
H. Models of man//N.Y. 1957.
46.
Simon
H. The science of the artifitial//Cambridge. 1969.
47.
Simon
H. The theory of problem solving//Information processing 1971, Amsterdam,
P.267-277.
48.
Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование
мира в состояниях: Пер. с англ. - Киев : Диалектика, 1993. - 240 с.
49.
Шевченко В. Нейронные сети.//Компьютерное обозрение, №46, 1996,
С.19.
ПЕРЕЧЕНЬ ГРАФИЧЕСКОГО МАТЕРИАЛА
ПРИЛОЖЕНИЯ
ДОКЛАД
1.В
данной дипломной работе рассматривается состав и функционирование ИС построенной
по принципу «клиент-сервер» для численного обоснования решений.
2.В настоящее время стремительными темпами
распространяются сетевые компьютерные технологии. Предпосылками к этому служат
процессы дальнейшего развития программных и аппаратных средств вычислительной
техники. Так как любая ИС предполагает одновременную работу с ней пользователей
различных категорий, то разумней всего было построить такую систему по принципу
«клиент-сервер». Самое примечательное свойство архитектуры «клиент-сервер»
состоит в возможности удалить клиента от сервера на любое расстояние без
существенного снижения скоростных характеристик системы (даже в случае сложных
запросов) и без всяких изменений в программном обеспечении. Удаленный клиент
подключается к серверу с помощью телефонного или иного канала. Это свойство
очень ценно для организации распределенной обработки данных. Кроме того, оно
позволяет заменять СУБД, операционную систему и сервер, не изменяя программного
обеспечения клиентской части системы.
3.Целью настоящей
дипломной работы является разработка структуры и алгоритмов взаимодействия
программных блоков интеллектуальной системы для оценки сложных объектов,
построенной по принципу «клиент\сервер». Конкретно рассматривается
проектирование одного из блоков системы – блока управления данными и знаниями
интеллектуальной системы, построенной по принципу «клиент\сервер».
Проектируемый блок обеспечивает такие
основные свойства системы как распределенность данных и знаний, параллелизм при
доступе и обработке данных, гибкость при настройке, надежность и корректность
всей информации.
4.Для достижения указанной цели необходимо решить
следующие задачи:
- проанализировать основные задачи, решаемые ИС в целом и
ее отдельными блоками: АРМ администратора системы, АРМ эксперта, АРМ лица
принимающего решения (руководителя), АРМ рядового оператора;
- разработать структуры данных и основные функции перечисленных
автономных рабочих мест и серверного блока;
- разработать порядок взаимодействия всех блоков системы;
-
выполнить программную реализацию блока управления данными
и знаниями интеллектуальной системы.
Характер задач решаемых ИС, а также основные функции, выполняемые
системой, во многом предопределяют ее структуру. Любая система только тогда
может претендовать на звание экспертной, когда в ее состав входят блоки
обеспечивающие непосредственно формирование экспертных оценок и обучение
системы.
Для ИС необходимы средства настройки на конкретную предметную
область. Кроме того, поскольку (как было сказано ранее) ИС представляет собой
рабочее место нескольких категорий пользователей: администратора системы,
экспертов - лиц принимающих решения, целесообразно придать системе сетевую
архитектуру типа клиент-сервер (КС).
Все вышесказанное обуславливает необходимость выделения в
разработанной ИС следующих, относительно самостоятельных подсистем:
- подсистема настройки и адаптации;
- подсистема управления базами данных;
- подсистема принятия и анализа решений;
- подсистема обучения;
- подсистема управления сетью.
1.Подсистема настройки и адаптации предназначена для настройки
системы для решения конкретной предметной задачи;
2.Подсистема обучения предназначена для накопления знаний
в предметной области, необходимых для решения конкретной задачи. Эта информация
может отражать как субъективное мнение экспертов, так объективную статистику
(обучающая выборка);
3.Подсистема управления сетью проектов, предназначенная
для динамического связывания данных, относится к разным предметным задачам, но
позволяющих решать более глобальные задачи;
4.Подсистема принятия и анализа решений предназначена для
непосредственного формирования оценки сложных объектов, а также анализа и
обоснования вычисленных оценок;
5.Подсистема управления базами данных (БД)предназначена
для ведения (ввод, удаление, редактирование, сортировка и т.д.) БД, содержащей
оцениваемые объекты.
Описания подсистемы фактически являются АРМ-ами различных
категорий пользователей. Так администратор системы должен пользоваться
подсистемой настройки и адаптации, а также подсистемой управления сетью
проектов и подсистемой управления БД.
Эксперты-специалисты в предметной области должны пользоваться
подсистемами обучения и возможно подсистемами настройки и адаптации и
подсистемами управления БД.
Лицо принимающее решение (руководитель) как правило пользуется
только подсистемой принятия и анализа решений. Рядовые операторы обеспечивают
внесение исходных данных в базу и являются основными пользователями подсистемы
управления базой данных. На основании этого предлагается реализовать всю универсальную экспертную систему в виде
следующих пяти АРМ-ов:
- АРМ настройки и адаптации (“Администратор”);
- АРМ подсистема управления базами данных;
- АРМ принятия и анализа решений;
- АРМ обучения;
- АРМ управления проектов сетью.
С целью придания гибкости разрабатываемой системе целесообразно
предусмотреть возможность конфигурирования любого из АРМ-ов, с учетом
потребностей в конкретной организации. Это означает, что несмотря на совпадение
названий подсистем и АРМ-ов, конкретному АРМ-у могут быть приданы функции не
только основной подсистемы, входящей в его состав, но и функции других подобных
подсистем. Как было сказано ранее АРМ управления сетью проектов (администратор)
кроме того может быть снабжен функциями настройки и адаптации системы
управления БД и т.д. АРМ-обучение, является рабочим местом экспертов, иногда
целесообразно расширять функциями настройки и адаптации, функциями управления
БД и функциями принятия и анализа решений. Таким образом название каждому АРМ-у
дано по основной подсистеме входящей в его состав, при этом не исключается
возможность включения в отдельный АРМ дополнительных функций других подсистем.
Отдельно необходимо рассмотреть вопросы взаимодействия между
собой отдельных АРМ-ов. Поскольку по техническому заданию архитектура
проектируемой системы строится по принципу клиент-сервер (КС), необходимо
произвести такую декомпозицию отдельных подсистем, которая обеспечивала бы
формирование типовых запросов от разных АРМ-ов и обработку этих запросов
серверной частью системы. Именно поэтому в состав разработанной системы необходимо
включить серверный программный блок, который непосредственно управляет всеми БД
всех одновременно решаемых задач. Все обращения к любым данным системы
происходят только через этот серверный блок.. Таким образом в серверном блоке
должны быть части деллегированные ему описанными подсистемами. Это означает,
что часть функций обеспечивающих настройку системы, ее обучение, вычисление и
интерпретацию оценок, должны также выполняться и серверным блоком. Именно по
этому в состав серверного блока включены соответствующие фрагменты.
Еще одним механизмом, обеспечивающим сетевое функционирование
системы является механизм флагов состояния проекта, т.е. проект может
находиться в одном из следующих состояний:
-создание проекта не завершено;
-проект не обучен;
-обучение проекта завершено;
-обучение для задач классификации с уточнениями.
Этот механизм обеспечивает координацию действий отдельных
АРМ-ов через данные, а не через управление (через блок сервера). В соответствии
с этим механизмом отдельные АРМ-ы как бы передают эстафету друг другу при
создании модификаций и использовании конкретных проектов.
5. Уже само понятие "архитектура
«клиент-сервер»" трактуется разработчиками по-разному. Все сходятся лишь в
одном: для организации вычислительного процесса при распределенной обработке
данных желательно использование архитектуры «клиент-сервер». Так, некоторые
определяют архитектуру «клиент-сервер» как модель взаимодействия компьютеров и
процессов в сети (классификацию моделей рассмотрим ниже). Для других утверждение,
что некоторая информационная система имеет архитектуру «клиент-сервер»,
означает, что прикладная составляющая этой системы имеет распределенный характер
и состоит из двух взаимосвязанных компонент, одна из которых (клиент) формирует
и посылает запросы высокого уровня другой компоненте (серверу), задача которой
состоит в обслуживании этих запросов.
Третьи считают, что в последнее время термин
"клиент-сервер", к сожалению, девальвировался и стал применяться по
отношению к любым локально-сетевым технологиям. Минской фирмой под архитектурой
«клиент-сервер» понимается такая организация вычислительного процесса, при
которой вся обработка происходит в основном на персональном компьютере,
обращающемся с SQL-запросами к серверу, где содержатся общие базы данных. По
сети циркулируют только SQL-запросы/ответы (а не фрагменты или отдельные записи
СУБД, как в архитектуре файл-сервер), благодаря чему резко снижается нагрузка
на сеть. Обработка данных при этом более равномерно распределяется между
клиентом и сервером.
Обычно выделяются три модели взаимодействия клиента и сервера:
RDA (Remote Data Access), в которой компонента представления
(пользовательский интерфейс) и прикладная компонента (логика работы программы)
совмещены в клиентской части, а компонента доступа к информационным ресурсам
(данным) размещена в серверной части.
DBS (DataBase Server), в которой компонента представления
размещена в клиентской части, а прикладная компонента и доступ к информационным
ресурсам - в серверной;
AS (Application Server), в которой компонента представления
находится в клиентской части, прикладная компонента - в "сервере
приложения", а компонента доступа к информационным ресурсам - в
"сервере базы данных".
Системы с
архитектурой «клиент-сервер» могут быть двух- или трехуровневыми.
Система является двухуровневой, если она построена с использованием
набора прикладных клиентских программ, имеющих общий доступ к ресурсам системы
и работающих с сервером базы данных или SQL-сервером. Прикладная программа
может при этом размещаться как в клиентской, так и в серверной частях в виде хранимых
процедур, триггеров и правил.
Система является трехуровневой, если она содержит три следующие
самостоятельные компоненты:
интерфейс пользователя, в функции которого входят только
отображение (вывод) результатов и взаимодействие с пользователем;
сервер приложения, в котором сосредоточены все
бизнес-функции, правила и/или хранимые процедуры;
сервер базы данных (в большинстве случаев - SQL-сервер
СУБД), он же - менеджер ресурсов.
Легко видеть, что трехуровневая система относится к модели
AS.
6.В работе проведен анализ функционирования различных ИС.
Любая ИС предполагает одновременную работу разных категорий пользователей с единым
пространством данных. В состав пользователей входят рядовые операторы, вносящие
данные в базу, и эксперты осуществляющие обучение ИС и лица непосредственно
принимающие решения, пользующиеся результатами работы ИС, а также администратор
системы, обеспечивающий целостность данных. Для всех вышеперечисленных АРМ
следуют клиентские части, на сервер же возлагается задача введения баз данных.
Были проанализированы все эти части и программно реализован блок администратора
7.В ходе разработки интеллектуальной системы на базе технологии
«клиент-сервер» достигнуты основные цели, поставленные перед началом
проектирования.
Была разработана архитектура, структура данных, алгоритмы
взаимодействия, программных модулей, образующих ИС на базе применения последних
разработок в области технологий «клиент-сервер». В ходе выполнения дипломной работы
были выполнены следующие задачи:
- исследована структура и функции ИС в целом и ее отдельных
программных блоков - АРМ-ов администратора системы, эксперта, лица принимающего
решения (руководителя), рядового оператор хранения компонентов модели;
- разработаны структуры данных и основные функции перечисленных
автоматизированных рабочих мест.
- разработан порядок взаимодействия всех компонентов в целом.
- выполнена программная реализация модуля администратор.
ДОКЛАД
1.В данной дипломной работе
рассматривается состав и функционирование ИС построенной по принципу «клиент-сервер»
для численного обоснования решений.
2.В настоящее время
стремительными темпами распространяются сетевые компьютерные технологии.
Предпосылками к этому служат процессы дальнейшего развития программных и
аппаратных средств вычислительной техники. Так как любая ИС предполагает одновременную
работу с ней пользователей различных категорий, то разумней всего было построить
такую систему по принципу «клиент-сервер». Самое примечательное свойство
архитектуры «клиент-сервер» состоит в возможности удалить клиента от сервера на
любое расстояние без существенного снижения скоростных характеристик системы
(даже в случае сложных запросов) и без всяких изменений в программном
обеспечении. Удаленный клиент подключается к серверу с помощью телефонного или
иного канала. Это свойство очень ценно для организации распределенной обработки
данных. Кроме того, оно позволяет заменять СУБД, операционную систему и сервер,
не изменяя программного обеспечения клиентской части системы.
3.Целью
настоящей дипломной работы является разработка структуры и алгоритмов
взаимодействия программных блоков интеллектуальной системы для оценки сложных
объектов, построенной по принципу «клиент\сервер». Конкретно рассматривается
проектирование одного из блоков системы – блока управления данными и знаниями
интеллектуальной системы, построенной по принципу «клиент\сервер».
Проектируемый блок обеспечивает такие
основные свойства системы как распределенность данных и знаний, параллелизм при
доступе и обработке данных, гибкость при настройке, надежность и корректность
всей информации.
4.Для достижения указанной цели
необходимо решить следующие задачи:
- проанализировать основные
задачи, решаемые ИС в целом и ее отдельными блоками: АРМ администратора
системы, АРМ эксперта, АРМ лица принимающего решения (руководителя), АРМ
рядового оператора;
- разработать структуры данных
и основные функции перечисленных автономных рабочих мест и серверного блока;
- разработать порядок
взаимодействия всех блоков системы;
-
выполнить программную реализацию блока управления данными
и знаниями интеллектуальной системы.
Характер задач решаемых ИС, а
также основные функции, выполняемые системой, во многом предопределяют ее
структуру. Любая система только тогда может претендовать на название интеллектуальной,
когда в ее состав входят блоки обеспечивающие непосредственно формирование
экспертных оценок и обучение системы.
Для ИС необходимы средства
настройки на конкретную предметную область. Кроме того, поскольку (как было
сказано ранее) ИС представляет собой рабочее место нескольких категорий пользователей:
администратора системы, экспертов - лиц принимающих решения, целесообразно
придать системе сетевую архитектуру типа клиент-сервер (КС).
Все вышесказанное обуславливает
необходимость выделения в разработанной ИС следующих, относительно
самостоятельных подсистем:
- подсистема настройки и
адаптации;
- подсистема управления базами
данных;
- подсистема принятия и анализа
решений;
- подсистема обучения;
- подсистема управления сетью.
1.Подсистема настройки и
адаптации предназначена для настройки системы для решения конкретной предметной
задачи;
2.Подсистема обучения
предназначена для накопления знаний в предметной области, необходимых для
решения конкретной задачи. Эта информация может отражать как субъективное
мнение экспертов, так объективную статистику (обучающая выборка);
3.Подсистема управления сетью
проектов, предназначенная для динамического связывания данных, относится к
разным предметным задачам, но позволяющих решать более глобальные задачи;
4.Подсистема принятия и анализа
решений предназначена для непосредственного формирования оценки сложных
объектов, а также анализа и обоснования
вычисленных оценок;
5.Подсистема управления базами
данных (БД)предназначена для ведения (ввод, удаление, редактирование, сортировка
и т.д.) БД, содержащей оцениваемые объекты.
Описания подсистемы фактически
являются АРМ-ами различных категорий пользователей. Так администратор системы
должен пользоваться подсистемой настройки и адаптации, а также подсистемой
управления сетью проектов и подсистемой управления БД.
Эксперты-специалисты в
предметной области должны пользоваться подсистемами обучения и возможно
подсистемами настройки и адаптации и подсистемами управления БД.
Лицо принимающее решение
(руководитель) как правило пользуется только подсистемой принятия и анализа
решений. Рядовые операторы обеспечивают внесение исходных данных в базу и являются
основными пользователями подсистемы управления базой данных. На основании этого
предлагается реализовать всю универсальную
экспертную систему в виде следующих пяти АРМ-ов:
- АРМ настройки и адаптации
(“Администратор”);
- АРМ подсистема управления
базами данных;
- АРМ принятия и анализа
решений;
- АРМ обучения;
- АРМ управления проектов
сетью.
С целью придания гибкости
разрабатываемой системе целесообразно предусмотреть возможность
конфигурирования любого из АРМ-ов, с учетом потребностей в конкретной
организации. Это означает, что несмотря на совпадение названий подсистем и
АРМ-ов, конкретному АРМ-у могут быть приданы функции не только основной
подсистемы, входящей в его состав, но и функции других подобных подсистем. Как
было сказано ранее АРМ управления сетью проектов (администратор) кроме того
может быть снабжен функциями настройки и адаптации системы управления БД и т.д.
АРМ-обучение, является рабочим местом экспертов, иногда целесообразно расширять
функциями настройки и адаптации, функциями управления БД и функциями принятия и
анализа решений. Таким образом название каждому АРМ-у дано по основной
подсистеме входящей в его состав, при этом не исключается возможность включения
в отдельный АРМ дополнительных функций других подсистем.
Отдельно необходимо рассмотреть
вопросы взаимодействия между собой отдельных АРМ-ов. Поскольку по техническому
заданию архитектура проектируемой системы строится по принципу клиент-сервер
(КС), необходимо произвести такую декомпозицию отдельных подсистем, которая
обеспечивала бы формирование типовых запросов от разных АРМ-ов и обработку этих
запросов серверной частью системы. Именно поэтому в состав разработанной системы
необходимо включить серверный программный блок, который непосредственно
управляет всеми БД всех одновременно решаемых задач. Все обращения к любым
данным системы происходят только через этот серверный блок.. Таким образом в
серверном блоке должны быть части деллегированные ему описанными подсистемами.
Это означает, что часть функций обеспечивающих настройку системы, ее обучение,
вычисление и интерпретацию оценок, должны также выполняться и серверным блоком.
Именно по этому в состав серверного блока включены соответствующие фрагменты.
Еще одним механизмом,
обеспечивающим сетевое функционирование системы является механизм флагов
состояния проекта(конкретная оценочная задача), т.е. проект может находиться в
одном из следующих состояний:
-создание проекта не завершено;
-проект не обучен;
-обучение проекта завершено;
-обучение для задач
классификации с уточнениями.
Этот механизм обеспечивает
координацию действий отдельных АРМ-ов через данные, а не через управление
(через блок сервера). В соответствии с этим механизмом отдельные АРМ-ы как бы
передают эстафету друг другу при создании модификаций и использовании
конкретных проектов.
AS (Application Server), в
которой компонента представления находится в клиентской части, прикладная
компонента - в "сервере приложения", а компонента доступа к
информационным ресурсам - в "сервере базы данных".
Система является трехуровневой,
если она содержит три следующие самостоятельные компоненты:
интерфейс пользователя, в
функции которого входят только отображение (вывод) результатов и взаимодействие
с пользователем;
сервер приложения, в котором
сосредоточены все бизнес-функции, правила и/или хранимые процедуры;
сервер базы данных (в
большинстве случаев - SQL-сервер СУБД), он же - менеджер ресурсов.
6.В работе проведен анализ
функционирования различных ИС.
Были проанализированы все эти
части и программно реализован блок администратора
7.В ходе разработки
интеллектуальной системы на базе технологии «клиент-сервер» достигнуты основные
цели, поставленные перед началом проектирования.
Была разработана архитектура,
структура данных, алгоритмы взаимодействия, программных модулей, образующих ИС
на базе применения последних разработок в области технологий «клиент-сервер». В
ходе выполнения дипломной работы были выполнены следующие задачи:
- исследована структура и
функции ИС в целом и ее отдельных программных блоков - АРМ-ов администратора
системы, эксперта, лица принимающего решения (руководителя), рядового оператор
хранения компонентов модели;
- разработаны структуры данных
и основные функции перечисленных автоматизированных рабочих мест.
- разработан порядок
взаимодействия всех компонентов в целом.
- выполнена программная
реализация модуля администратор.
Список аббревиатур
ИС –
интеллектуальные системы
АРМ
- автоматизированные рабочие места
M Þ (S, V, F, P, E )
ОТЗЫВ
на дипломную работу
ОРГАНИЗАЦИЯ ДАННЫХ И ЗНАНИЙ В
ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМАХ, ПОСТРОЕННЫХ ПО ПРИНЦИПУ “КЛИЕНТ/СЕРВЕР” ”
студента группы ____________
Проектирование интеллектуальных
систем является одной из наиболее актуальных задач в области информационных
технологий. Существующие аналоги обладают рядом недостатков, связанных с
ориентацией их на автономный (не сетевой) режим функционирования. Для
устранения этих недостатков требуется разработка универсальной интеллектуальной
системы, построенной по принципу “клиент\сервер”.
Коренным вопросом при разработке
универсальной интеллектуальной системы является проектирование механизмов
управления данными. Именно они определяют универсальность системы и
обеспечивают реально сетевой, многопользовательский режим работы. Поэтому
решение этого вопроса представляется актуальным.
В дипломной работе проведено
проектирование алгоритмов и программных средств управления данными. Разработаны
структуры данных для хранения информации об элементах оценочной модели и
алгоритмы их обработки. Предлагаемые средства обеспечивают настройку ной
системы на решение задач оценки качества и распознавания образов в любой
предметной области в терминах понятных пользователю-эксперту.
Описанные механизмы реализованы в
виде подсистемы управления данными, интегрированными в универсальную
интеллектуальную систему EXPEKW, разработанную на кафедре.
В ходе выполнения дипломной работы
Овчаренко Д.В. проявил себя как грамотный специалист, способный решать сложные
инженерные задачи. Пояснительная записка и графический материал выполнены на
хорошем инженерном уровне и отвечают требованиям соответствующих нормативных
документов.
Считаю, что дипломная работа “Организация данных и знаний в интеллектуальных системах,
построенных по принципу “клиент/сервер” заслуживает оценки “отлично”, а ОВЧАРЕНКО Дмитрий Владимирович - присвоения квалификации
СПЕЦИАЛИСТ по специальности 7.091501
- “Компьютерные и
интеллектуальные системы и сети”.
Доц. кафедры КИСС,
к.т.н. Николенко
А.А.
|
