Изграждане на информационна система за мониторинг производството на интериорни компоненти

Почти цялата работа на приложението с базата данни се осъществява с помощта на съхранени процедури. Те имат много предимства пред заявките под формата на string обект изпратен до SQL Server-a, защото осигуряват много по-добра ефективност чрез локалното си съхранение и предварителна компилация на кода. От гледна точка на сигурността имат също много предимства. Едно от тях е предпазването от SQL инжекции.

За пълната реализация на комуникацията между бизнес слоя и базата данни наложи създаването на 96 съхранени процедури, които информационната система използва и се намират на SQL сървъра. Те имат най-различно предназначение: въвеждане, зареждане, промяна на данните, манипулирани от обектите от бизнес логиката, логин, справки, изтриване на данни и др.

В следващите няколко подточки са изложени няколко от тях

Извлича реда от таблицата, в който има съвпадащи потребителско име и парола. Ако има ред значи автентикирането е успешно.

CREATE PROCEDURE [dbo].[login]

@userName nvarchar(50),

@password nvarchar (50)

AS

SELECT *

WHERE (userName= @userName) AND ([password] = @password)

GO

3.2.2 Съхранена процедура “poruchkiDogramaAdd”

Добавя нова поръчка за дограма в базата с данни и връща id-то на записа.

CREATE PROCEDURE [dbo].[poruchkiDogramaAdd]

@id int output,

@clientName nvarchar(50),

@clientAddress nvarchar(250),

@clientPhone nvarchar(50),

@cviatDogramaId int,

@cviatStuklopaketId int,

@podProzDuskiId int,

@dateCreated datetime,

@endDate datetime,

@price float,

@isActive bit,

@usersId int
AS
INSERT

INTO poruchkiDograma (clientName,clientAddress,clientPhone,cviatDogramaId,cviatStuklopaketId,podProzDuskiId,dateCreated,endDate,price,isActive,usersId)

VALUES (@clientName,@clientAddress,@clientPhone,@cviatDogramaId,@cviatStuklopaketId,@podProzDuskiId,@dateCreated,@endDate,@price,@isActive,@usersId)
SELECT @id=@@IDENTITY

GO

3.2.3 Съхранена процедура “poruchkiVratiUpdate”

Обновява данните за поръчка с подаденото id като параметър.
CREATE PROCEDURE [dbo].[poruchkiVratiUpdate]

@id int ,

@clientName nvarchar(50),

@clientAddress nvarchar(250),

@clientPhone nvarchar(50),

@furnirId int,

@baicId int,

@profilId int,

@laminatId int,

@pervazId int,

@cviatObkovId int,

@drujkiId int,

@cenoobrazuvane nvarchar(500),

@dateCreated datetime,

@endDate datetime,

@price float,

@isActive bit,

@usersId int

AS
UPDATE poruchkiVrati

SET

clientAddress=@clientAddress ,

clientPhone=@clientPhone ,

furnirId=@furnirId ,

baicId=@baicId ,

profilId=@profilId ,

laminatId=@laminatId ,

pervazId=@pervazId ,

cviatObkovId=@cviatObkovId ,

drujkiId=@drujkiId ,

cenoobrazuvane=@cenoobrazuvane ,

dateCreated=@dateCreated ,

endDate=@endDate ,

price=@price ,

isActive=@isActive ,

usersId=@usersId

GO
3.3. Програмна реализация

Windows Forms е стандартната библиотека на .NET Framework за изграж­дане на прозоречно-базиран графичен потребителски интерфейс (GUI) за настолни (desktop) приложения. Windows Forms дефинира набор от класове и типове, които позволяват изграждане на прозорци и диалози с графични контроли в тях, чрез които се извършва интерактивно взаимо­дей­ствие с потребителя.

При настолните приложения, графичният потребителски интерфейс позво­лява потребителят директно да взаимодейства с програмата чрез мишката и клавиатурата, а програмата прихваща неговите действия и ги обработва по подходящ начин. Windows Forms е типична компонентно-ориентирана библиотека за създа­ване на GUI, която предоставя възможност с малко писане на програмен код да се създава гъвкав графичен потребителски интерфейс.

3.3.2 Проекти

За правилното реализиране и логическо разделяне на слоевете на системата са включени 4 проекта за разработката на приложението : Karabulev, BusinessLogic, DataAccess и SetupKarabulev (виж фиг. 3)

фиг. 3
Два от трите слоя на информационната система са част от това приложение - презентационния и бизнес слоя. В следващите няколко подточки са описани структурата и функциите на всеки един от 4-те проекта.

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

фиг. 4.
Стартовата точка на цялото приложение в класа Program.cs. При стартиране, след успешно логване на екрана се появява основната форма - MainForm.cs. Приложението е изградено на следния принцип: През цялото време стои на екрана основната форма, която съдържа менюто и всички други форми, които биха могли да се извикат, се показват модално, извършва се определена работа и после се скриват.

Всички форми всъщност са класове. Те взаимодействат помежду си и си предават параметри чрез public членове.

Всеки един от класовете на формите наследява BaseForm.cs , който е наследник на System.Windows.Forms.Form. По този начин в BaseForm.cs се дефинират public или protected методи, които се използват във всички други форми.

В този проект се съдържа и файлът app.config- конфигурационният файл на приложението. Той представлява обикновен XML файл.

В тага <appSettings> могат да се добавят конфигурационни параметри на приложението, които представляват двойки от ключ и стойност. Настрой­ки­те от конфигурационния файл могат да бъдат извличани по време на изпълнение по следния начин:

string serverIP = System.Configuration.

ConfigurationSettings.AppSettings["serverIP"];

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

Проектът “Karabulev” не съдържа бизнес обектите. Той работи с тях благодарение на добавената референция към проекта “BusinessLogic”.

Този проект е първата от двете части на бизнес слоя. Типът му е Class Library и по същество представлявя дефиниции на множество класове.

Фиг. 5

Фиг. 6

Изключение прави класа Cfg. Той е конфигурационен клас. Многократно в приложението се налага използването на константни стойности, низове, указващи форматиране, пътеки към ресурсни файлове и др. С цел лесната им употреба, тези константи са обединени в клас- класа Cfg. Така при необходимост те много лесно могат да се променят и направените промени ще се отразят из цялото приложение.Това е част от кода на конфигурационния клас :

using System;

using System.Collections.Generic;

using System.Collections.Specialized;

using System.Text;

using System.Configuration;

using System.Data.Sql;

using System.Data.SqlClient;

using System.Data;

using DataAccess;

namespace BusinessLogic

{

public class Cfg

public static readonly string ConnectionString = System.Configuration.ConfigurationSettings.AppSettings["server"].ToString();

public static readonly Int32 Int32Empty = Int32.MinValue;

public static readonly Int64 Int64Empty = Int64.MinValue;

public static readonly byte ByteEmpty = byte.MinValue;

public static readonly decimal DecimalEmpty = decimal.MinValue;

public static readonly Single SingleEmpty = Single.MinValue;

public static readonly float FloatEmpty = float.MinValue;

public static readonly double DoubleEmpty = double.MinValue;

public static readonly DateTime DateTimeEmpty = DateTime.MinValue;

#endregion

public static readonly string DATE_STR1 = @"dd.MM.yyyy";

public static readonly string DATE_STR2 = @"dd.MM.yy";

public static readonly string DATE_STR3 = @"dd MMMM yy, HH:mm";

#endregion
#region Resources

public static readonly string DirImages = @"\resursi\images\";

public static readonly string BlankaZaiavkaEdinichna=@"\resursi\blanki\zaiavkaEdinichna.jpg";

public static readonly string BlankaZaiavkaRamka = @"\resursi\blanki\zaiavkaRamka.jpg";

public static readonly string BlankaZaiavkaCiala = @"\resursi\blanki\zaiavkaCiala.jpg";

public static readonly string BlankaPoruchkaVrata = @"\resursi\blanki\poruchkaVrata.jpg";

public static readonly string BlankaPoruchkaDograma = @"\resursi\blanki\poruchkaDograma.jpg";

public static readonly string BlankaDogovorVrati = @"\resursi\blanki\dogovorVrati.jpg";

public static readonly string BlankaDogovorDograma = @"\resursi\blanki\dogovorDograma.jpg";

public static readonly string DirPrices = @"\resursi\prices\";

public static readonly string Ednokril = "Ednokril";

public static readonly string Dvukril = "Dvukril";

{

VratiProfil, Ostuklenie ,Vid

.

.

.

}

В Cfg, както и в останалите класове, полетата и методите са подходящо групирани. Това е направено с помощта на региони, които много удобно разделят кода по начин, по който желае програмиста.

Проектът “BusinessLogic” също не работи директно с базата данни. Той изцяло работи само с бизнес обектите. Комуникацията с базата данни се извършва в проекта “DataAccess”, към който “BusinessLogic” имa добавена референция. Следва метод, чрез който се добавя нов запис за монтажист (метод от класа Montajist.cs) в базата данни:

..

using DataAccess;

..

public void Add(SqlConnection cn)

//dobavia montajist

bool privCn = (cn == null);

if (privCn)

{

cn = new SqlConnection(Cfg.ConnectionString);

}
ListDictionary parameters = new ListDictionary();

parameters.Add("firstName", this._FirstName);

parameters.Add("middleName", this._MiddleName);

parameters.Add("lastName", this._LastName);

parameters.Add("egn", this._EGN );

parameters.Add("sex", this._Sex);

parameters.Add("address", this._Address);

parameters.Add("phone", this._Phone);

parameters.Add("mobilePhone", this._GSM);

parameters.Add("isActive", this._IsActive);
SqlDBAccess.ExecuteNonQuery(cn, "montajistAdd", parameters);
if (privCn)

{

cn.Close();

}

От подчертания ред код се вижда, че класът извиква метод от “DataAccess” - проекта за комуникация с базата данни. Какво представлява “DataAccess” e обяснено в т. 3.3.2.3.

Този проект е втората част от бизнес слоя на информационната система. Той също е от тип Class Library. За разлика от “BusinessLogic” той съдържа само 2 класа:

фиг. 7

Класът SqlDBAccess.cs предлага множество от методи, които извършват комуникацията с базата данни.

фиг. 8

Разделянето на бизнес слоя по този начин на 2 части има своето преимущество. SqlDBAccess предлага методи, които връщат един и същ резултат като различен обект, тоест един метод от BusinessLogic може да зареди данните си като DataTable,SqlDataReader,DataView и др. според това тип резултат е необходим и промяната на типа на този резултат става само с промяната на една дума в кода - името на метода от SqlDBAccess, който извикваме в класа от BusinessLogic.

Това е последният проект към приложението. Той е от тип Setup Project. Добавен към останалите, той дава възможност цялото приложение да бъде сведено до инсталационен файл като предоставя много удобства при инсталация:

• 
  Прави проверка за инсталиран .NET Framework 2.0 на клиентската машина и ако не е, то той се инсталира автоматично. Това се налага поради невъзможността на приложението да работи без .NET Framework 2.0.
  
• 
  Включва в себе си и копира на клиентската машина допълнително указани файлове.
  
• 
  Има указана версия и при наличие на по-стара версия от текущата, премахва старата инсталация от машината.
  
• 
  Предоставя много лесна деинсталация през Control Panel-а и др.
  

фиг. 9

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

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

фиг. 10

При несъответствие с посоченото потребителско име и(или) парола се показва следното съобщение:

фиг. 11

фиг. 12

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

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

Основната форма изглежда по следният начин :

фиг. 13

фиг. 14

Всички форми за заявки за размери и поръчки имат част от интерфейса си, където се определя кои монтажисти ще извършат съответната услуга. Модул монтажисти е достъпен по следният път чрез менюто:

фиг. 15

След изборът от менюто на екрана се появява следната форма:

фиг. 16

Редакцията на монтажисти се извършва в същата форма, където и въвеждането им:

фиг. 17

фиг. 18

“Техническите изисквания” са гръбнака на информационната система. Те полагат основата от необходимите данни, на които се основава работата на същинската част от приложението. Те формират ресурса, който използва модул “Дейности”. Разположени са в основното меню по следния начин:

фиг. 19

В следващите няколко точки те ще бъдат разгледани накратко. Понеже имат доста еднотипна и проста структура, потребителският интерфейс, който предоставя достъп до функционалността за добавяне и редакция на “технически изисквания” е целенасочено сходен. Това прави работата с тях много интуитивна и позволява по-сбитото им разглеждане. Във всички форми, където е необходимо, е имплементирана валидация на задължителни полета, коректни стойности и т.н. като при невалидни данни се показват подходящи съобщения на потребителя. Също така някои от обясненията и изискванията са валидни за всички “технически изисквания”. Бутоните “Отказ” и “Запази” има едно и също предназначение във всички форми – отказ от направени промени и запазване на промените.

Техническите изисквания се делят на 4 групи : за врати, за дограма, остъкление и дръжки. Следва разглеждане на всяка от тези групи.

3.4.5.2 Врати

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

фиг. 20

При избор на “Фурнир” от менюто се появява следната форма:

фиг. 21

За редакция се избира радиобутона “Редакция”, след което се появява падащото меню за избор на фурнир за редакция. В този случай бутонът “Запази” вече е натоварен с функция за обновяване на данните, а не за въвеждане.

фиг. 22

При избор на “Байц” се появява формата от фиг. 23а. Разликата тук е, че за всеки байц трябва да се избере фурнир от падащото меню, към който принадлежи.

Формата от фиг. 23б илюстрира редакцията на байц. Случаят, с малки разлики, е аналогичен на т. 3.4.5.2.1.

фиг. 23а фиг. 23б

При избор на “Профил” се появява формата от фиг. 24 Особеното тук е вкарването на изображение за профила.

То се осъществява чрез кликане на бутона “Снимка” и избор на изображение от файловата система, което ще се визуализира в рамката в умален вид.

фиг. 24

Фиг. 25

Ламинат е друго техническо изискване към врата. Аналогичен интерфейс и логика на работа при въвеждане (фиг. 26а) и редакция (фиг. 26б)

фиг. 26а фиг. 26б

Това техническо изискване е най-простото. То има чисто информативен характер. Формите за въвеждане/редакция са както следват : фиг. 27а и фиг. 27б

фиг. 27а фиг. 27б