Характеристики на разработката на софтуерни агенти. Обосновка за избора на инструменти и среда за разработка на софтуер

Предлагаме цялостен преглед на всички елементи

Защо трябва да дефинирате изисквания

Средата за разработка трябва да съдържа всичко необходимо за създаване и внедряване на системи с интензивно използване на софтуер (т.е. системи, в които софтуерът е най-важният и незаменим елемент). Защо е важно да има последователна дефиниция на изискванията на средата за разработка? Накратко, много организации се стремят да намалят времето за излизане на пазара, да намалят разходите и да подобрят качеството, като всички те са бизнес цели, които са пряко свързани с качеството на средата, използвана за изграждане на такива системи. Наличието на последователна и изчерпателна дефиниция на средата за разработка под ръка гарантира, че нищо не се пренебрегва при планиране на действия за подобряване на съществуващата среда, дефиниране на изисквания към средата, дефиниране на архитектурата на средата, оценка на средата, осигуряване на подходящо ниво на възвръщаемост на инвестициите, когато промяна на средата и т.н. Определянето на вашата среда за разработка е критичен принос към всички тези задачи.

Място на средата за разработка в контекста

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

Фигура 1 показва център за осигуряване на качеството(Center of Excellence), отговорен за създаването и поддържането на средата за разработка. Тази среда се използва в проекти за разработка, които от своя страна създават и поддържат интензивни софтуерни системи (или някои други софтуерни активи, като компоненти или услуги). Тази проста визуализация ви позволява да изясните разликите между ролята на QA център (включително ролите на членовете на екипа, процесите и ключов възел - средата за разработка) и проектите, които използванетази среда за разработка (и тяхроли, процеси и възли).

Елементи на средата за разработка

Според софтуерните експерти на IBM Rational, средата за разработка се състои от следните шест елемента, всеки от които е показан на фигура 2 и подробно описан по-долу:

• Метод
• Инструменти
• Подготовка (Активиране)
• Организация
• Изпълнение (осиновяване)

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

• ПерсоналТова е организация и подготовка.
• Процесе техника.
• технологияТова са средствата и инфраструктурата.

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

Метод

Ключов елемент на всяка среда за разработка е методологията, следвана, формално или неформално, от практиците. Ето основните компоненти, свързани с методологията:

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

Инструменти

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

Ключови елементи, свързани с инструментите:

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

Подготовка (Активиране)

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

Основни елементи, свързани с подготовката:

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

Организация

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

Ключови елементи, свързани с организацията:

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

Инфраструктура

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

1. Първо, консолидация. Например, когато се разглеждат инфраструктурните нужди на средата за разработка като цяло, може да се определи, че е необходим само един уеб сървър, който да поддържа както методологията на уеб съдържание, така и уеб обучението.
2. Второ, уверете се, че целият допълнителен хардуер и софтуер, поддържащи средата за разработка (напр. операционни системи, системи за управление на бази данни, системи за управление на хардуер, инструменти за тестване за разработка в реално време и вградени устройства), са правилно взети предвид.
3. Трето, Центърът за осигуряване на качеството може да изисква разгръщане на инфраструктура, която да поддържа създаването и тестването на средата за разработка, преди тя да бъде разгърната в производствена инфраструктура, поддържаща бизнес проекти.

Ключови елементи, свързани с инфраструктурата:

• Местоположение, възли и свързаност.
• Софтуер (например операционни системи, системи за управление на бази данни, системи за управление на хардуер, инструменти за тестване).

Изпълнение (осиновяване)

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

Ключови елементи, свързани с изпълнението:

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

Контекст на решението

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

• Функционалностпредставлява схемата или реда на разработване на софтуер, предоставен от средата за разработка. Прилагането на тези изисквания налага да се вземат предвид всички елементи, споменати по-рано. Например редът за управление на изискванията (вижте Фигура 3) се поддържа от следните аспекти:
  • Методика за управление на изискванията.
  • Инструменти за управление на изискванията.
  • Обучение и наставничество за управление на изискванията.
  • Екип за поддръжка, който знае как да се справя с проблеми с управлението на изискванията.
  • Хардуер и софтуер за поддръжка на елементи, свързани с управлението на изискванията.
  • Подходящо прилагане на процедури за управление на изискванията в проекти.

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

• Имотиса параметрите, които трябва да притежава средата за разработка. Те също така изискват да се вземат предвид всички елементи на средата за разработка. Например, за да се приложи свойство за мащабируемост (например способността да се поддържа различен брой едновременни потребители), се използват следните подходи:
  • Метод, който може да бъде персонализиран, за да отговаря на размера на проекта.
  • Инструменти, които могат да бъдат конфигурирани да поддържат конфигурируем метод.
  • Подходящи механизми и нива на обучение за проекти с различни размери.
  • Организационни ресурси, за да се гарантира, че персоналът с подходящи нива на квалификация е наличен, за да поддържа очаквания брой проекти за развитие.
  • Инфраструктура, която може да се мащабира, за да поддържа очаквания брой едновременни потребители.
  • Подходящи механизми за инжектиране на околната среда.
• Ограничения, на които трябва да отговаря средата за разработка, също изискват отчитане на всички елементи на средата за разработка. Например, ако трябва да мигрирате от съществуваща среда, може да се наложи да направите следното:
  • Вземете правилата от съществуващата методология и ги включете в новата.
  • Мигрирайте работни продукти от наследения инструментариум към новия инструментариум (или интегрирайте със съществуващи инструменти).
  • Осигурете обучение, адекватно на текущото състояние на нещата и правилно организирано.
  • Осигурете персонал, за да осигурите плавен преход от началендържави в планирано.
  • Идентифицирайте инфраструктура, която използва максимално съществуващата инфраструктура (напр. повторно използване на съществуващи лицензи за хардуер и софтуер, когато е възможно).
  • Осигурете механизми за внедряване, които потвърждават, че миграцията е завършена.

Друго важно ограничение при обмислянето на промяна на съществуваща среда за разработка е, разбира се, възвръщаемостта на инвестицията (ROI). За да бъде успешна подобна инициатива, тя със сигурност трябва да даде положителни резултати в съответствие с бизнес плана. Всеки аспект на средата за разработка влияе върху възвръщаемостта на инвестициите както по отношение на разходите, така и на печалбата.

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

Дефинирайте, разположете, управлявайте

Когато дефинирате различните елементи на средата за разработка, е полезно да вземете предвид следните елементи от жизнения цикъл на средата (вижте Фигура 4), тъй като в допълнение към контекста на решението, всеки от тях има свои собствени аспекти, които влияят на дефиницията:

• Определение за среда.
• Разгръщане на околната среда.
• Управление на околната среда.

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

Следващите раздели обхващат всеки елемент от средата за разработка, заедно с дефиниране на решение, внедряване на решение и управление на решение.

Определение

Приложено към определениесредите за разработка припомнят предишното обсъждане на ключови елементи. Тази дискусия не се повтаря тук, въпреки че за изчерпателност таблица 1 изброява различните дефинирани по-рано елементи.

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

Таблица 1 Аспекти на дефиницията

Разгръщане

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

Таблица 2. Съображения за внедряване

Ключови елементи методи:

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

Ключови елементи инструменти:

• производителност локална настройка. Всяко локално персонализиране на инструментите се използва за автоматизиране на персонализирането на локалната методология.
• Монтаж на инструменти. Прави инсталираните инструменти (и тяхната интеграция) достъпни за специалистите.
• Миграция на локални данни. Например, може да е необходимо да мигрирате данни от съществуващ инструментариум към нов.

Ключови елементи обучение:

• Извършете локална настройка. локална настройка. При необходимост - адаптиране, уточняване или актуализиране учебни материали. Можете например да преразгледате обучителните материали, за да ги приведете в съответствие с процеса, дефиниран за дадена бизнес единица или проект за развитие.
• Разполагане на обучителни материали. Гарантира достъп до тях от страна на изпълнителите, включително достъп до всички Web-материали.
• Обучение на изпълнители. По време на обучението се събира обратна връзка от изпълнителите.

Ключови елементи организации:

• Определяне на локалната конфигурация. Експерти може да са необходими за подпомагане на специфичните нужди на конкретна бизнес единица или проект за развитие.
• Реорганизация. Организация на персонала и ресурсите за подпомагане на средата за разработка.

Ключови елементи инфраструктура:

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

Ключови елементи изпълнение:

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

контрол

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

Таблица 3. Аспекти на управлението

Ключови елементи методи:

• Събиране на обратна връзка по методологията. Ключов аспект от управлението на среда за разработка е нейното непрекъснато подобряване. Следователно събирането на обратна връзка се отнася за всички елементи. Обратната връзка обикновено се събира субективно, като се използват например въпросници.

Ключови елементи инструменти:

• Архивиране, архивиране, възстановяване на данни. Уверете се, че работните продукти, създадени от специалисти, се управляват правилно и се прилагат практики за „добра администрация“.
• Съберете отзиви за инструментите. Съберете отзиви (както положителни, така и отрицателни) относно наличността и ефективността на инструментите.

Ключови елементи обучение:

• Обучение на изпълнители. Назначете спонсори на проекта, така че изпълнителите да знаят как да използват околната среда.
• Събиране на обратна връзка за подготовката, т.е. за обучение или наставничество.

Ключови елементи организации:

• Съберете отзиви за организацията. Изпълнителите дават своите коментари относно предоставената поддръжка за използване на средата за разработка (например относно качеството на услугата за поддръжка).

Ключови елементи инфраструктура:

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

Ключови елементи изпълнение:

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

Взаимовръзки

И накрая, имайте предвид, че различните елементи на средата за разработка не са независими. Алтернативно представяне на Фигура 2 е показано на Фигура 5, което показва, че всеки елемент има връзки с всички останали елементи.

Ето няколко примера за зависимости между елементи:

• Методология (методология) се отнася до налични курсове за обучение (обучение).
• Инструменти (инструменти) автоматизират задачи (методология).
• Административните роли (организация) са дефинирани за поддържащи инструменти (инструменти).
• Предоставят се сървъри (инфраструктура) за хостване на набор от инструменти (инструменти).
• Прилагането на методите на работа (внедряването) се оценява чрез специфичен подход (методология).

Заключение

Тази статия допълва статията (EN), публикувана от същия автор в Рационалното предимствопрез 2008г. Той подробно описва ключовите елементи на среда за разработка и подчертава различните аспекти на дефинирането, внедряването и управлението на тази среда. Той предоставя проста рамка, за да се гарантира, че всички тези аспекти са взети предвид при планиране на действия за подобряване на съществуваща среда, дефиниране на екологични изисквания, дефиниране на архитектура, оценка на среда и т.н.

Алексей Федоров, Наталия Елманова

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

Следващият етап от жизнения цикъл информационна система- разработка на клиентски приложения. Резултатът от този етап е завършен продукт, състоящ се от множество приложения, които позволяват на потребителите да въвеждат данни в таблици или да редактират съществуващи данни, да анализират въведените данни и да ги представят в по-разбираема форма - графики, обобщени таблици или отчети (вкл. "хартиени документи).

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

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

Класификация на средствата за разработка на приложения

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

Почти всеки инструмент за разработка, който претендира да бъде универсален, може да бъде направен да работи с всяка база данни - достатъчно е да поддържате използването на библиотеки на трети страни в този инструмент за разработка и тази база данни има набор от клиентски интерфейси (API) за платформата на които създадените приложения трябва да работят. Въпреки това, не всяка двойка продукти "инструмент за разработка плюс СУБД" е привлекателна по отношение на разходите за труд, свързани със създаването на такива приложения. Можете да напишете цялостно приложение, което извиква API функциите на клиента и имплементира удобен потребителски интерфейс с помощта на C компилатор и проста графична библиотека (например, позволяваща ви да промените цвета на пикселите на екрана) за операционната система, на която това приложението ще се изпълнява. Но разходите, свързани с внедряването на такъв проект, може да са напълно неоправдани, тъй като в този случай разработчиците ще трябва да внедрят функции, които вече се съдържат в библиотеките на класове и компоненти на инструменти за разработка, които са по-дълбоко фокусирани върху създаването на приложения за бази данни или включват поддръжка за създаване на такива приложения.

Инструменти за разработка, фокусирани върху специфични СУБД

Преди десет или двадесет години в много приложения, използващи бази данни, клиентските API функции се извикваха от код, написан на един от езиците за програмиране, най-често на C. Просто погледнете описанието на API на клиентската част на почти всяка страна на сървъра СУБД - и ще намерите много примери за най-типичните кодови фрагменти, например за регистриране на потребител, изпълнение на заявки и др. Въпреки това, бързо стана ясно на разработчиците на СУБД, че разходите за труд, свързани с писането на такъв код, могат да бъдат значително намалени чрез събиране на най-типичните кодови фрагменти и най-често срещаните елементи на потребителския интерфейс в библиотеки (дори за буквено-цифрови терминали), форматиране на тези библиотеки в като отделен продукт и добавяне към него на среда за разработка и помощни програми за проектиране на потребителски формуляри за преглед и редактиране на данни, както и отчети. Така се появяват първите инструменти за разработка, специфични за СУБД, като Oracle * Forms (предшественикът на текущия Разработчик на Oracle Forms).

Продукти от този клас все още се предлагат на пазара на инструменти за разработка днес. Почти всички доставчици на сървърни бази данни също произвеждат инструменти за разработка на приложения. В по-голямата част от случаите съвременните версии на тези инструменти за разработка поддържат достъп до СУБД от други производители, използвайки поне един от универсалните механизми за достъп до данни (ODBC, OLE DB, BDE). Въпреки това, достъпът до "техните" СУБД обикновено се извършва възможно най-много ефективен начин, тоест използване на клиентски API, обекти, съдържащи се в библиотеките на клиентската част на сървърната СУБД, специални класове за достъп до данните на тази СУБД или чрез внедряване на драйвери за универсални механизми за достъп до данни, които могат да вземат предвид специфичните характеристики на тази СУБД.

Средите за разработка на настолни СУБД могат да бъдат отделени в отделна категория. В статията от тази серия, посветена на настолни СУБД, вече отбелязахме, че по-голямата част от настолните СУБД, които са оцелели до днес, като Microsoft Visual FoxPro, Microsoft Access, Corel Paradox, Visual dBase, поддържат достъп до сървърни СУБД, поне с помощта на универсални механизми за достъп до данни, което ни позволява условно да ги класифицираме като инструменти за разработка. Имайте предвид обаче, че понастоящем създаването на приложения в архитектурата "клиент-сървър" с тяхна помощ е рядко явление. Изключение може би са двойките Microsoft Access - MSDE, Microsoft Access - Microsoft SQL Server и Microsoft Visual FoxPro - Microsoft SQL сървър. Това е резултат от компетентна политика на Microsoft, стремяща се към максимална съвместимост на продуктите си и предоставяща най-безболезнената за потребителите замяна на своите настолни СУБД със собствени сървъри за бази данни (Access->MSDE->Microsoft SQL Server, FoxPro->Visual FoxPro->Microsoft SQL Server).

Инструменти за разработка, които са универсални по отношение на СУБД

Инструментите за разработка, които са универсални по отношение на СУБД (или претендиращи за подобна универсалност), като правило са последователи на конвенционалните инструменти за разработка на приложения, които не са пряко свързани с базите данни. Типични примери за такива инструменти за разработка са Borland Pascal, Borland C++, Microsoft QuickC. Способни да използват библиотеки на трети страни, тези инструменти направиха възможен достъп до функциите на клиентските API, а с разработването на универсални механизми за достъп до данни (като ODBC), също и до API функциите на библиотеки, които прилагат такива механизми. Трябва да се отбележи, че настолни СУБД среди (като dBase, FoxBase) или псевдокомпилатори за езици от семейството xBase (като Clipper) често се създават с помощта на тези инструменти за разработка.

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

Първата категория включва инструменти за разработка, които имат обширни библиотеки с класове, голям брой "магьосници" и генератори на кодове, но са фокусирани върху "ръчно" създаване на код и рядко се използват за създаване на "стандартни" приложения за бази данни (тук под фразата " стандартно приложение"има предвид приложение, което има директен достъп до базата данни, с която потребителят взаимодейства, т.е. това е "класически" клиент на сървърната СУБД). Типичен (и единственият наистина популярен на софтуерния пазар) представител на това клас продукти е Microsoft Visual C ++. помощ от MicrosoftБиблиотеките на Visual C++ и MFC (Microsoft Foundation Classes) могат да създадат всяко приложение, ако имате умения, знания, умения и време. Въпреки това приложенията със сложен потребителски интерфейс (например, използващи бази данни) не се разработват често с негова помощ (въпреки че примери за използването му могат да бъдат намерени дори в руската литература). По принцип този продукт се използва за създаване на клиентски приложения в случай на предявяване на специални изисквания към тях, като висока производителност, възможност за извършване на всякакви нестандартни операции и др.

Втората категория включва инструменти за разработка с усъвършенствани визуални инструменти, които ви позволяват буквално да "нарисувате" потребителския интерфейс, като частично изтривате разликите между работата на програмиста и потребителя и намалявате цената на крайния продукт чрез привличане на разработчици, които не са най-висока квалификация за проектиране на интерфейса (ако внимателно проучите програмите на курса центрове за обучение, специализирани в преподаването на инструменти за разработка на Microsoft, Borland и Sybase, можете да откриете, че продължителността на курса на обучение, след слушане на което обичайното потребител на Windowsтрябва да научите как да създавате клиентски приложения за сървърна СУБД, е от 5 до 10 работни дни).

Именно тази категория инструменти за разработка се използва най-често при създаване на клиентски приложения. Най-популярните продукти от този клас включват Microsoft Visual Basic, Borland Delphi , Sybase PowerBuilderи Borland C++Builder. Средите за разработка на такива продукти са много сходни на външен вид (до местоположението на прозорците на екрана, което е зададено „по подразбиране“): като правило средата за разработка на такъв продукт съдържа „празно“ от проектираното форма (аналогично на прозорец), отделен панел с икони на елементи на потребителския интерфейс и други обекти, използвани в приложението, които могат да бъдат избрани и поставени върху формата, прозорец, в който са свойствата на един от елементите, избрани във формата показани и редактирани (и понякога списък със събития, на които този елемент реагира), прозорец на редактор на код, където можете да въведете кодови фрагменти, свързани с обработката на определени събития, както и кода, който реализира логиката на работа това приложение. обикновено, модерни съоръженияразработките от този клас ви позволяват да създавате най-простите приложения за редактиране на данни с малко или никакъв код.

Напоследък също стана много популярно да се създават приложения, които използват достъп до база данни, но се намират в обикновени документи. Инструментите за разработка на такива приложения се основават на макро езиците на съответните редактори. Най-типичният и почти единствен популярен представител на инструментите за разработка в тази категория е Visual. Основен заПриложения, което е подобно на изброените по-горе инструменти за визуална разработка и се различава от тях по това, че приложенията, създадени с него, се съдържат в документи Microsoft Officeи не са отчуждени от тях.

Имайте предвид обаче, че горното разделение на средствата за разработка на тези два класа е доста условно. Както казахме по-горе, почти всички инструменти за разработка на приложения за бази данни, включително тези, фокусирани върху конкретни СУБД, поддържат поне един от универсалните механизми за достъп до данни. И почти всички "универсални" инструменти за разработка на приложения, ако принадлежат на производителя на която и да е сървърна СУБД, поддържат "своята" СУБД по-добре от СУБД на трети страни (това може да се изрази, например, в специални библиотеки от класове или компоненти за достъп до това сървър, а също и при наличие на общи хранилища на обекти и модели на данни, а понякога и редактори на параметри за достъп до данни или схеми на данни, общи с клиентската част на сървърната СУБД)

Класификация на приложенията, които използват бази данни

Приложения в архитектура клиент-сървър

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

В този случай най-често се използват инструменти за разработка с разширени визуални инструменти, като Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder, за създаване на клиентски приложения.

Имайте предвид обаче, че изборът на модерни архитектури на приложения в момента е доста широк и не се ограничава до "класическата" клиент-сървър архитектура, което предполага, че приложението се състои от сървър на база данни и клиентски приложения, взаимодействащи с този сървър. Ето защо по-долу ще обсъдим кои инструменти за разработка са удобни за използване при създаване на разпределени приложения.

Разпределени приложения

Разпределените (или многослойни) приложения обикновено се състоят от презентационни услуги (или "тънки" клиенти, с които обикновено взаимодействат крайните потребители), бизнес логически услуги, внедрени като бизнес обекти (или услуги от средно ниво; често за описание на колекция от такива услуги се наричат междинен софтуер) и услуги за данни (обикновено състоящи се от сървър на база данни и механизми за достъп до данни). Услугите за бизнес логика са предназначени да получават информация от потребителя от услугите за представяне, да взаимодействат с услугите за данни за извършване на бизнес операции (като обработка на поръчки или изчисляване на баланс) и да връщат резултатите от тези операции към услугите за представяне.

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

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

За създаване на бизнес обекти се използват както инструменти за разработка с разширени визуални инструменти, така и инструменти за разработка, фокусирани върху „ръчното“ създаване на код на приложение (като Visual C ++). Имайте предвид, че най-новите версии на почти всички най-популярни инструменти за разработка на Windows приложения (Microsoft Visual Basic, Visual FoxPro и Visual C++, Borland Delphi и C++Builder, Sybase PowerBuilder) поддържат създаването на различни видове бизнес обекти (уеб приложения, ASP-обекти, COM сървъри и др.), с възможно изключение на Microsoft Access - този продукт е предназначен повече за квалифицирани потребители, отколкото за разработчици на разпределени системи. Често за тази цел се използват и инструменти за създаване на Java приложения (като Borland JBuilder).

Имайте предвид, че в допълнение към гореспоменатите "универсални" инструменти за създаване както на приложения в архитектурата "клиент-сървър", така и на бизнес обекти за разпределени системи, на пазара на инструменти за разработка има специализирани инструменти, които са предназначени специално за създаване на бизнес обекти (обикновено уеб приложения). От инструментите за разработка от този клас за платформата Windows най-популярният е Microsoft Visual InterDev, чиято първа версия се появи през 1998 г. Можем да споменем и друг интересен продукт, принадлежащ към същата категория инструменти за разработка - Borland IntraBuilder, който се появи две години по-рано, но по някаква причина, въпреки нарастващата нужда от продукти от този клас, не получи по-нататъшно развитие. Инструментите за разработка от този клас, като правило, ви позволяват да създавате приложения, които динамично генерират HTML код или код на един от скриптовите езици (VBScript или JavaScript), който се предава от уеб сървъра към браузъра на потребителя като част от уеб страница и приемане на данни, въведени от потребителя в HTML форма и предадени от браузъра на уеб сървъра.

Заключение

В тази статия обсъдихме процеса на създаване на приложения, които използват бази данни, както и различните категории инструменти, използвани при тяхното разработване. Видяхме, че инструментите за разработка могат да бъдат условно разделени, от една страна, на инструменти, фокусирани върху използването на специфични СУБД, инструменти, които са универсални по отношение на СУБД, и настолни СУБД среди, използвани за разработване на приложения. От друга страна, те могат да бъдат разделени на инструменти, фокусирани върху дизайна на визуален потребителски интерфейс (тази категория включва Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder) и инструменти, фокусирани върху писане на код на приложение (Visual C++).

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

• поне един от универсалните механизми за достъп до данни, който позволява използването на данни от различни СУБД в създаваните приложения;
• създаване на няколко вида разпределени приложения;
• автоматично генериране на код на приложение въз основа на модели, създадени с помощта на най-популярните инструменти за проектиране на данни и моделиране на бизнес процеси.

Обсъдихме също как приложенията клиент-сървър се различават от разпределените системи и какви инструменти за разработка могат да се използват за създаване на двата типа приложения.

Жизненият цикъл на една информационна система не завършва с разработването на приложения. Веднъж създадени, те трябва да бъдат тествани, внедрени, обучени да ги използват и накрая да бъдат използвани в продължение на няколко години. В резултат на такава експлоатация се натрупват данни, които по правило са много по-ценни от самите приложения. Тези данни често представляват необходимия материал за вземане на важни управленски решения, така че е важно да можете да ги преобразувате в подходяща за тази цел форма. За целта има инструменти, свързани с категорията Business Intelligence – генератори на отчети, инструменти аналитична обработкаданни и търсене на модели. Ще говорим за тях в следващата статия от тази поредица.

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

HTML е език за маркиране на хипертекст, който се използва за създаване на документи в Интернет. С него се създава необходимата структура и мрежа на страницата, чийто външен вид е допълнително подобрен чрез CSS и JavaScript. В момента най-новата версия е HTML5, която беше предшествана от HTML4.01. Повечето уеб ресурси са изградени на базата на този конкретен език.

За разлика от HTML 4, който има 3 валидатора, HTML 5 има един валидатор:. HTML 5 поддържа MathML и SVG.

Нови тагове: раздел, статия, настрани, hgroup, заглавка, долен колонтитул, навигация, диалогов прозорец, фигура, видео, аудио, източник, вграждане за вграждане на съдържание с плъгин (само), маркиране, прогрес, измервател, време, рубин, rt, rp , платно, команда, подробности, списък с данни, keygen, изход.

Нови типове въвеждане: телефон, търсене, url, имейл, дата и час, дата, месец, седмица, час, дата и час-локално, число, диапазон, цвят.

Нови атрибути за тагове: ping медийни атрибути за a и област и др.

Изчезването на някои тагове, поради факта, че те могат да бъдат заменени от CSS: basefont, big, center, font, s, strike, tt, u.

Рамките изчезват поради отрицателно въздействие върху цялата страница

Изчезването на някои тагове, заменени в актуализираната спецификация с по-подходящи: акроним (използван е abbr), аплет (използван е обект), isindex, dir.

Някои атрибути на тагове не се поддържат поради липса на необходимост: rev и charset за връзка и a, форма и координати за a и т.н.

Някои атрибути на етикети не се поддържат поради факта, че когато използвайки CSSпостигнати най-добър ефект: подравняване за всички тагове, alink, връзка, текст, vlink за тяло и т.н.

Нови API: рисуване на 2D изображения в реално време; контрол върху възпроизвеждането на медийни файлове; съхраняване на данни в браузъра; редактиране; Дръпни и пусни; работа в мрежа; MIME нови елементи в DOM.

CSS е формален език за описание на външния вид на документ, написан с помощта на език за маркиране. CSS е акроним за Cascading Style Sheets. CSS е стилов език, който определя изобразяването на HTML документи. Например CSS се занимава с шрифтове, цвят, полета, линии, височина, ширина, фонови изображения, позициониране на елементи и много други неща. HTML може да се използва за стилизиране на уеб сайтове, но CSS е по-мощен и по-прецизен и сложен. В момента CSS се поддържа от всички браузъри.

HTML се използва за структуриране на съдържанието на страница. CSS се използва за форматиране на това структурирано съдържание. Като уеб разработкадизайнерите започнаха да търсят начини за форматиране на онлайн документи. За да отговорят на нарастващите изисквания на потребителите, производителите на браузъри (тогава Netscape и Microsoft) изобретиха нови HTML тагове като , които се различаваха от оригиналните HTML тагове по това, че определяха външния вид, а не структурата. Това също доведе до оригинални маркери за структуриране като