Програма "Софтуерни технологии в интернет" на тема уеб система за проверка на кредитоискатели Дипломант: Георги Желев Калчев

Обяснението какво представляват наименованията на самите търсения на тази страница съвпада със тези на SureLoc. Тук разликата е, че се ползват различни доставчици на информация и съответно резултатите са различни по пълнота, ранг и т.н. Данните които се въвеждат са описани на фиг.3.11. Тук всяко търсене вече е разделено по тагове което подсказва че всяко търсене е от различен доставчик на информация - различен не само от SureLoc секцията но е всяко едно помежду си. Тук в тази секция са избрани най-добрите доставчици и съответно най-скъпите. Тук самите клиенти използващи системата решават кой компонент да използват.

Фиг.3.11
Резултатните данни са показани на фиг.3.6. Единствено резултатите от “Phone Lookup” страницата и “Phone” секцията на “Locator” са различни и са показани на фиг.3.12.

Използвайки уникален идентификатор като номер на шофьорската книжка или SSN, тази страница извежда данни за валидността на SSN-a или шофьорската книжка. Ако не са въведени тези данни а останалите са правилни – търсенето връща предполагаемите SSN-и.

• 
  Credit Header – Този вид търсене връща като резултат предишни задълженията на кредитоискателя, изплатени и неизплатени кредити, показва текущите доходи на кредитоискателя. Преди да направи всички тези проверки с цел спестяване на ресурси и пари, се прави предварителна проверка за валидност на SSN и дали не се използват данните на вече умрял човек. Тук е по-изгодно да се извикат дори и без нужда SSN Validation и Death Records търсенията, тъй като Credit Header търсенето е много по-скъпо тях.
  
• 
  Death Records – Това търсене проверява дали не се използват данните на вече умрял човек. Резултатите са показани на фиг.3.14
  

• 
  SSN Validation – този вид търсене проверява дали съществува подобен SSN, от кога до кога е валиден и съответно ако е непълен - връща данни за подобни SSN-и. Резултатите са на Фиг.3.15
  

Проверка на кредитоискателя за съвпадение за представената идентичност, извличане на личните данни на кредитоискателя от три различни източника. Системата автоматично сравнява данните и филтрира излишната или не пълна информация. В зависимост от това дали е въведен SSN-а на кредитоискателя се пускат различни видове търсене. Данните които се въвеждат са показани на фигура 3.16.

• 
  Dynamic Inquisition, Public Data – динамично намиране и сортиране на най-високата по рейтинг на важност информация. Тук се търсят данни за големи корпорации. За по-голяма сигурност се извеждат и въпроси, който доказват че човека е същия за който се представя. Резултатните данни са показани на фиг. 3.16. Тук в резултата се връща и дата на раждане (DOB).
  

• 
  Dynamic Inquisition, Private Data – Този вид търсене се ползва при търсене на фирми. При търсенето на фирма не се задават въпроси, но се извеждат резултати за основните хора участващи в управлението на фирмата – това може да стане тъй като в вътрешната(privet) база данни се пази ранга на всеки служител за съответната фирма. Резултатните данни са показани на фиг. 3.17. Тук в резултата не се връща дата на раждане (DOB).
  

Тези страници са така наречените „клиентки страници”. Тъй като съм влязъл във системата с права на супер администратор аз виждам абсолютно всички възможности на тези страници. Но тяхната идея е всяка фирма да си ги ограничи да показват само специфични търсения.Данните които се въвеждат(фиг.3.18) са много, като в зависимост от избраните търсения се променят задължителните полета.

• 
  BANKRUPTCY BUSSINESS BASIC, BANKRUPTCY BUSSINESS LIENS & JUDGEMENTS, BANKRUPTCY INDIVIDUAL BASIC, BANKRUPTCY INDIVIDUAL LIENS & JUDGEMENTS – тези всичките са за проверка на фалити на компания или частни лица в период до 15 години назад. Тук върнатите данни са изключително пълни, като се започне, с какво се занимава компанията, която се разследва, всичките дъщерни компании, финансови възможности на компаниите, техните активи и пасиви до информация с какво се е занимавала компанията до преди 15 години ако е съществувала. Резултатните колони тук са 176, поради което няма как да ги покажа тъй като ще заемат прекалено голям обем, а считам че информацията не е толкова важна в случая.
  
• 
  PROPERTY RECORDS – това е пълна информация за всяка притежавана собственост на фирмата или частното лице което се проверява. Тук отново информацията е изключително широка(50 колони), примерно се показват лист със недвижимите собствености, тяхната квадратура, оценката в различните периоди през които е била продавана, хората които са я притежавали, колко етажа е и т.н. Недатайлните данни които се извеждат на екрана са показани на фигура 3.19.
  

• 
  CRIMINAL RECORDS – тук се търси дали дадената личност има криминално минало. Данните които се извеждат на екрана са показани на фигура 3.20.
  

Тези страници дава различни справки за това какви сървиси са използвани на дадена дата. Резултатите и въведените данни са еднотипни и затова няма да се спирам на тази страница по-подробно. Примерните данни които се въвеждат и изходните данни са показани на фигура 3.21.

Това е страницата от която може да се сменят страниците позволени за дадена компания (това действие изисква права супер администратор), да се редактират или добавят потребителите към дадена компания (това действие изисква права минимум администратор). Страницата е показана на фиг. 3.22.

На тази страница се показва информация за акаунта с който потребителя е в момента. Тук той може да си смени паролата да провери статусите по своя акаунт, показва се към коя компания работи и към кой клон на тази компания ако има такъв. Страницата е показана на фиг.3.23.

• 
  Трислойната софтуерна архитектура е много по-комплексна и сложна за реализация в сравнение с еднослойни и двуслойни IT решения, но в замяна на това предоставя следните значителни предимства и ползи, както следва:
  
• 
  Разширяемост на системата - Трислойният софтуерен модел и разделянето на функциите за изпълнение от различни софтуерни и хардуерни компоненти позволява системата да бъде доразвивана и подобрявана на точно необходимото място (както промени във функционалността на софтуера или добавяне на нови такива, така и подобрения на хардуера на системата). Повторно дистрибутиране на потребителското приложение е нужно само когато промените са свързани с промяна на потребителския интерфейс или логика.
  
• 
  Разделяне на функциите - Трислойната софтуерна архитектура позволява функциите за достъп до базата от данни да бъдат разделени от бизнес логиката на софтуерната система. От друга страна функциите на потребителския интерфейс, посредством които потребителят взаимодейства със системата, също са разделени от първите две. Това позволява разработването на системата да обхваща разработване на няколко сравнително независими обекта, имащи различни специфични функции. Това разделение от своя страна довежда до намаляване на рисковете за промени в кода и евентуални несъответствия на софтуера. При еднослойна или двуслойна софтуерна архитектура промяна във функционалността на клиентското приложение може да доведе до риска да бъдат нарушени други компоненти поради това, че логиката на потребителския интерфейс и бизнес логиката са смесени заедно. Трислойният модел намалява риска от бъгове и несъответствия в софтуера поради това, че бизнес функционалността може да бъде тествана независимо от потребителския интерфейс.
  
• 
  Сигурност - Трислойната софтуерна архитектура може да намали риска от пробив в сигурността на системата. Директната комуникация на клиентското приложение (десктоп базирано или уеб базирано) със сървъра за бази данни може да доведе до големи дупки в сигурността на системата. Поставянето на сървър по между им, който да поеме функциите на бизнес логиката и комуникацията между клиентското приложение и базата от данни, позволява да бъде реализирана много по-добра архитектура от гледна точка на сигурността. Сървърът за бази данни може да бъде достигнат и да комуникира единствено посредством сървъра, изпълняващ бизнес логиката на системата.
  
• 
  Гъвкавост – Трислойният модел предоставя възможност за разработване на различни видове клиенти: десктоп приложение, уеб базирано клиентско приложение или и двете заедно. Потребителите на системата си взаимодействат с базата от данни индиректно, посредством бизнес съобщения, изпратени до сървъра, реализиращ бизнес логиката. Трислойната архитектура позволява намаляване на повторенията в софтуерния код. Споделената бизнес логика на системата елиминира нуждата от повтарящи се бизнес функции в потребителския слой (логиката на потребителския интерфейс). Трислойният модел подобрява управлението и контрола на софтуера. Поради това, че модела разделя системата на самостоятелно обособени обекти, бъдещи промени в системата могат да бъдат бързо и лесно реализирани на точното място
  

Статичните страници в системата са три:

• 
  BasePage.master – това е статичната страница използвана при страниците за влизането в системата и изпирането на договор
  
• 
  Sleuth22ManagementMaster.master – това е статичната страницата, която се използва от страниците за менажиране на потребителите и от страниците за информация за текущия потребител
  
• 
  Sleuth22Master.master – тази статична част се използва от всички останали страници.
  

Самите страници от този вид започват с този инициализатор:

и съответно всяка тяхна съдържателна страница има право да променя само частта между таговете и .

foreach (DataRow row in MenuTabs.Rows)

{

string sID = SourceCheck22.Classes.Jinx.Utilities.ConvertHelper.ToString(row["ID"]);

string sURL = ResolveUrl(SourceCheck22.Classes.Jinx.Utilities.ConvertHelper.ToString(row["URL"]));

string bActive = (sID == sActiveTab) ? "true" : "false";

if (bActive.ToLower() == "true")

{

%>

}

else

}

}

От друга страна всяка страница трябва да се идентифицира пред това меню, за да може да се покаже коя от всички страници в момента е активна. Това става по следния начин:

ctrl.ActiveTab = ConvertHelper.ToString(GetPageIdentity());

като “ctrl” е идентификационното име на контролата меню, а метода GetPageIdentity() връща идентификацията на страницата.

Тези страници съм ги обединил тъй като функционалността тук, до голяма степен си прилича. Всяка една страница се обръща към бизнес обекта грижещ се за викането на сървисите(ако се викат повече от един сървис се използват специално създадени обекти за много-нишково извикване, които са описани в частта с бизнес логиката) и обработването на данните от съответния сървис до удобни за използване от потребителите:

iDataStore = WebServiceItems.SCIAddressPhoneSearch(

lscAccount

, sItemName

, sTelephone

, SCCommon.BuildAddress(

sStreetNumber

, sDirections

, sStreetName

, sSuffix)

, ""

, sCity

, sPostalCode

, SCPublicConstants.SureLocResultLimit.ToString()

);

bSCIResponsed = true;

WUC_SCIResponse1.DataBind(

iDataStore

, SCIResponsePageView.SCIPage

, (nItem != WebServiceItems.SCI_WildCard)

, bResidenceAllowed

, bNearbysAllowed

, bSkipSearchAllowed

, lscAccount.ItemPages.GetItemURL(WebServiceItems.SCI_SkipSearch)

, lscAccount.ItemPages.GetItemURL(WebServiceItems.SCI_ReversePhoneLookup)

, lscAccount.ItemPages.GetItemURL(WebServiceItems.SCI_AddressSearch)

);
Самата контрола за извеждане на данните е “repeater” или „gridVew” (това са .Net контроли^[18] за листване на резултатите), като често за детайлната информация се използват контрола във контрола. Тук трябва да се грижиш за всеки получен ред в родителската контрола да взимаш листа със данни за нейната детайлна контрола по съответната идентификация на родителската, показваща до къде точно е стигнала с редовете.

От друга страна за връзка между контролата и приложението се ползват и делегати. Например:

public delegate void OnSearchCommandEvent(int nItemID, string sLastName, string sFirstName, string sMiddleName, string sTelephone, string sAddress, string sCity, string sStateCode, string sPostalCode, DataGridItem oItem);

public OnSearchCommandEvent OnSearchCommand

{

get { return mOnSearchCommand; }

}

Всяка контрола има изграден и метод, за конвертиране на резултатите до файлове на MS EXCEL. Този метод ползва клас изграден специално за генериране на подобни файлове наречен „MSExcelHelper”. За подробно разглеждане -класа е приложен в приложението.

function isValidAddressStreet(Street) {

var reFullAddress= /^ {0,}(([a-zA-Z ]{1,})|([0-9]{1,}(((t|T)(h|H) {1,})|((s|S)(t|T) {1,})|((n|N)(d|D) {1,}))[a-zA-Z ]{0,}[a-zA-Z]{1,})) {0,}$/;

след което ако всичките въведени данни върнат вярност на въведените данни се вика съответния сървис. Ползата е че не се плащат излишни извиквания на сървисите с неверни или неправилно въведени данни.

Възможността да се принтира резултата е направена чрез прилагане на различни “@metadata”(таг определящ стила при различните изходи на приложениете – например стила при изход принтер или изход видео карта) в файла за определяне на стиловете
Този вид страници имат и общ модел за сигурност. Това се определя от наследяването на класа „SCSecurityPage”, който се грижи за сигурността на системата и ще бъде по-подробно една от следващите под теми. Накратко ако нямаш права, страницата изобщо не се вижда във менюто на системата и при опит за навигиране на страницата директно от адрес-бара на търсачката без наличните права, автоматично потребителя е прехвърлен към страницата за идентификация
Съдържателна страници за менажиране на потребителите по компаниите

Тук интересното е изграждането на дървото с компаниите от лявата страна. То се изгражда от таблицата(в базата) с компаниите, като рекурсивно се извиква метода:

protected void tvCompanies_BuildTreeNodes(TreeNode tnParent, string nParentCompanyID)

{

DataView dv = new DataView(dtCompanies, ((nParentCompanyID != "") ? "ParentID = '" + nParentCompanyID + "'" : "ParentID is null"), "", DataViewRowState.CurrentRows);

{

string nCompanyID = ConvertHelper.ToString(drv["CompanyID"]);

TreeNode tn = new TreeNode(nCompanyName, nCompanyID);

tn.Expanded = false;

tnParent.ChildNodes.Add(tn);

tvCompanies_BuildTreeNodes(tn, nCompanyID);

}

}

protected void butCompanyPagesUpdate_Click(object sender, EventArgs e)

{

string sPages = "";

{
if ((dgItem.ItemType == ListItemType.Item) || (dgItem.ItemType == ListItemType.AlternatingItem))

{

CheckBox chkIsSelected = (CheckBox)dgItem.FindControl("chkIsSelected");

{

TextBox txtOrderNumer = (TextBox)dgItem.FindControl("txtOrderNumer");

HtmlInputHidden txtPageID = (HtmlInputHidden)dgItem.FindControl("txtPageID");

string sPageID = txtPageID.Value;

sPages += sPageID + ";" + sOrderNumber + ",";

}

}

}

sPages = sPages.Remove(sPages.Length - 1);

lscAccount.UserManagementCompanyPagesSetActive(new Guid(tvCompanies.SelectedNode.Value), sPages);

}

Бизнес слой