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

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

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

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

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

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

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

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

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

• Метод
• Инструменти
• Позволение
• Организация
• Осиновяване

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

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

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

Метод

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

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

Инструменти

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

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

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

Позволение

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

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

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

Организация

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

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

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

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

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

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

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

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

Осиновяване

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

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

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

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

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

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

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

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

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

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

Дефиниране, внедряване, управление

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

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

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

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

Определение

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

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

Таблица 1. Аспекти на определението

Разгръщане

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

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

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

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

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

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

Ключови елементи подготовка:

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

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

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

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

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

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

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

контрол

Както е показано в таблица 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 сървър, FoxPro->Visual FoxPro->Microsoft SQL Server).

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

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

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

Първата категория включва инструменти за разработка с обширни библиотеки от класове, голяма сума"masters" и генератори на кодове, но фокусирани върху "ръчно" създаване на код и доста рядко използвани за създаване на "стандартни" приложения за работа с бази данни (тук под фразата " стандартно приложение"имаме предвид приложение, което има директен достъп до базата данни, с която потребителят взаимодейства, т.е. това е "класически" клиент на сървърна СУБД). Типичен (и единственият наистина популярен на софтуерния пазар) представител на това клас продукти е 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. Средите за разработка на такива продукти са много сходни на външен вид (до подреждането по подразбиране на прозорците на екрана): като правило средата за разработка на такъв продукт съдържа „заготовка“ на проектираната форма (аналог на прозорец) , отделен панел с икони на елементи на потребителския интерфейс и други обекти, използвани в приложението, които могат да бъдат избрани и поставени във формуляра, прозорец, в който се показват и редактират свойствата на един от елементите, избрани във формуляра (и понякога списък със събития, на които този елемент реагира), прозорец на редактор на код, където можете да въведете кодови фрагменти, свързани с обработката на определени събития, както и код, който реализира логиката на приложението. По правило съвременните инструменти за разработка от този клас ви позволяват да създавате прости приложения за редактиране на данни без практически никакво кодиране.

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

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

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

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

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

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

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

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

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

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

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

За създаване на бизнес обекти се използват както инструменти за разработка с разширени визуални инструменти, така и инструменти за разработка, фокусирани върху „ръчното“ създаване на код на приложение (като 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 – генератори на отчети, инструменти за аналитична обработка на данни и търсене на модели. Ще говорим за тях в следващата статия от тази поредица.

1.3 Избор на инструменти за разработка на софтуер

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

Те включват софтуер като Delphi, Visual C++, C Builder, Visual Basic, Java Builder;

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

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

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

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

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

Бяха взети предвид различни критерии за оценка на качеството на софтуерния продукт, по-специално тези, които отчитат аспекти на софтуерния продукт, който се разработва:

Наличие на инструменти за разработка и внедряване на софтуер;

Съответствие на избрания софтуер с нивото на подготовка на програмиста;

Софтуерни възможности за разработка на професионални и комплексни приложения софтуерни системи;

Оценка на качеството на инструментите по отношение на надеждност, производителност, лекота на използване и трудоемкост на тяхната работа;

Перспективите и жизнеспособността на компаниите за производство на софтуер, възможността за актуализиране и наличието на нови версии на продукти при модернизиране на софтуерната и хардуерната среда;

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

Скачване с широк обхватдруги СУБД и възможност за прехвърляне на базата данни за това софтуерен инструменткъм други СУБД;

Възможност за свързване към корпоративни мрежи и Интернет/Интранет, поддръжка за постоянно развитие WEB технологии;

Модулният принцип на конструкцията, степента на неговата гъвкавост.

Наличие на документация на руски език, помощни системи, документация в печатен и електронен вариант, възможност за консултации;

Простота на езика за програмиране;

Скорост на приложение;

Скорост на компилиране на приложението;

Наличие на интегриран дебъгер;

Обработка на изключения;

Методът за определяне на подходящ софтуерен продукт е следният.

Първо се избират няколко налични и добре познати софтуерни продукта. Избрах Delphi 5.0, Visual C++ 6.0 и Visual Basic за разглеждане. На всеки критерий беше присвоено тегло въз основа на целите на дизайна по такъв начин, че сумата от теглата на всички критерии да е равна на 1.

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

В ролята на експерти, които дадоха експертната оценка, бяха студенти от пети курс от група IT98-1.

Изчисленията по формула (1.1) са обобщени в таблица 1.2.

Както се вижда от таблица 1.2, най-подходящият инструмент за разработване на софтуерен пакет е Delphi 5.0.

Таблица 1.2 - Сравнение на софтуерни продукти

1.4 Техническо задание 1.4.1 Въведение

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

1.4.2 Причини за развитие

Разработването на софтуерния пакет се извършва въз основа на дипломна работа, одобрена със заповед на ректора на Донбаската инженерна академия в съответствие с GOST 19.101-77.

Темата на дипломната работа е „Програмно-методически комплекс за мултимедийна презентация образователна информация».

Специална част от разработката – ​​„Разработка на софтуер за интерфейса на сложната обвивка и пример за информационно съдържание“

1.4.3 Цел на разработката

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

1.4.4 Изисквания към софтуерния продукт 1.4.4.1 Изисквания за функционални характеристики

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

Осигурете възможност за въвеждане на лекции и други образователни материали със снимки, видео и аудио;

Осигурете възможност за промяна на курса;

Осигуряване на възможност за преминаване на курс (обучение);

Дават възможност за контрол на придобитите знания;

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

1.4.4.2 Изисквания за надеждност

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

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

1.4.4.3 Условия на работа

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

За да създадете курс за обучение, ви е необходим човек - преподавател или потребител, който ще създаде материала. Човек трябва да има умения за работа с персонален компютър, оборудван с операционна зала Windows система.

1.4.4.4 Изисквания за състав и параметри технически средства

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

Сила на звука оперативна паметнай-малко 32 мегабайта;

Процесор не по-нисък от Pentium 166, мишка, клавиатура;

Наличност свободно пространствона твърд диск от поне 5 мегабайта;

3.5'' дисково устройство;

Звукова карта;

SVGA монитор.

1.5.4.5 Изисквания за информационна и софтуерна съвместимост

Програмата трябва да работи под операционна система Windows. Програмата BDE Administrator трябва да бъде инсталирана за работа с бази данни. Изходните кодове на програмата трябва да бъдат написани на езика Object Pascal в среда за разработка Delphi 5.0. Информацията трябва да се въведе директно през GUI. Резултатът от визуализацията на информацията трябва да бъде представен в ясна и разбираема форма.

1.4.4.6 Изисквания към софтуерната документация

Предварителният състав на програмната документация е установен в съответствие с GOST 19.101-77. По-долу има списък програмни документии тяхното съдържание.

Програмен текст – запис на програмата с необходимите обяснения и коментари.

Описание на програмата - информация за логическа структураи функционирането на програмата.

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

Техническо задание – този документ.

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

1.4.5 Етапи и етапи на развитие

Етапите и фазите на развитие трябва да отговарят на GOST 19.101-77 и се състоят от следните точки.

1 Техническа спецификация – груба дефиниция на изискванията към програмния пакет и софтуерната документация.

2 Ескизен дизайн – разработване на структури за представяне на информация в софтуерния пакет, разработване на структурата на класовете, необходими за изпълнението на дадения алгоритъм. Формулиране на методи за реализиране на влагане в софтуерен пакет, разработване на програмна структура.

3 Технически проект– изясняване на структурата на класовете и методите за представяне на информация. Детайлно изясняване на метода на внедряване. Разработване на програмната структура.

4 Работен проект - разработване на програма, разработване на програмна документация, тестване на програмата.

1.4.6 Процедура за проверка и приемане

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

1.5 Разработване на математически модел

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

Предлагат се следните стъпки за проектиране на курс за обучение:

Методическо развитие на темата на програмата за обучение.

Чрез анализиране на резултатите от експерименти със специален модел разработете модел на глава за специализиран учебник.

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

Разработете софтуерен пакет, предназначен за разработка електронни средства образователна цел: информационни и експертни системи, електронни учебници, специални средства за обучение на студенти.

Да се ​​предложи технология за разработване на електронни учебници за профилирана подготовка с използване на пакет.

Разработете редица учебници и провеждайте експерименти, за да ги тествате с ученици и учители.

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

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

Етапите на разработване на електронен учебник могат да бъдат представени под формата на диаграма, показана на фигура 1.2.

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

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

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

Фигура 1.2 - Етапи на развитие на електроцентралата

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

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

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

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

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

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

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

Въз основа на горното се предлага структурата на материалите, показана на фигура 1.3.

1.6 Разработване на компоненти на софтуерния пакет 1.6.1 Разработване на логически модел на софтуерния пакет

Един от начините за описване на логическия модел на софтуерен пакет е структурният анализ.

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

Всички най-разпространени методологии на структурен подход се основават на редица общи принципи. Използват се следните два основни принципа:

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

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

Изолирането на два основни принципа не означава, че останалите принципи са вторични, тъй като игнорирането на който и да е от тях

могат да доведат до непредвидими последици (включително провал на целия проект). Основните от тези принципи са следните:

Принципът на абстракцията е да се подчертаят съществените аспекти на системата и да се абстрахират от маловажните;

Риск 1.3- Структура на материалите

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

Принципът на последователност – лежи в валидността и последователността на елементите;

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

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

SADT (Structured Analysis and Design Technique) модели и съответните функционални диаграми;

DFD (Data Flow Diagrams) диаграми на потока от данни;

ERD (Entity-Relationship Diagrams) диаграми на същност-връзка;

В часовете по биология. [Електронен ресурс]. Режим на достъп: http://www. nenc.gov.ua/index.php? id=79. - Заглавие и заглавие. екран. РЕЗЮМЕТА Slipchuk I.Yu. Методика за обучение по биология на ученици от 8-9 клас с помощта на модерни компютърни технологии. – Ръкопис. Дисертация за развитие на научното ниво на кандидат на педагогическите науки по специалност 13.00.02 – теория и методика на науката (биология). – Нация...

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

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

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

Има три основни класа инструментални среди за разработка и поддръжка на софтуер (фиг. 16.1): ·

среди за програмиране, ·

работни места в областта на компютърните технологии,

програмни технологии инструментални системи.

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

Ориз. 16.1. Основни класове инструментални среди за разработка и поддръжка на софтуер.

1. Инструментални среди за програмиране.

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

Съществуват следните класове инструменти за програмиране (виж Фиг. 14.2): ·

среди с общо предназначение,

езиково ориентирани среди.

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

Фиг. 16.2. Класификация на средствата за програмиране.

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

интерпретативна среда, ·

синтактично управлявани среди.

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

За оптимално разработване на софтуерна среда е необходимо да се комбинират различни езици за програмиране, тъй като всеки от тях е насочен към постигане на конкретни цели и задачи. Например, няколко 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 тагове по това, че определяха външния вид, а не структурата. Това също доведе до оригинални маркери за структуриране като

, все повече се използват за дизайн на страници вместо за структуриране на текст. Много нови етикети за дизайн като , се поддържаха само от един браузър. „Необходим ви е браузър X, за да видите тази страница“ се превърна в често срещан отказ от отговорност на уеб сайтовете.

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

Появата на CSS беше революция в света на уеб дизайна. Специфични предимства на CSS:

Контролирайте показването на множество документи с помощта на един стилов лист;

По-прецизен контрол върху външен видстраници;

Различни изгледи за различни медии (екран, печат и др.);

Сложна и изтънчена дизайнерска техника.

Има начини за кандидатстване CSS правилакъм HTML документа.

Метод 1: Inline/In-line (стилов атрибут). Можете да приложите CSS към HTML, като използвате атрибута HTML style. Цветът на фона може да бъде настроен на червен по следния начин:

Това е червена страница

Метод 2: Вътрешен (етикет за стил). Вторият начин за вмъкване на CSS кодове е HTML таг

Израел, Арад – обиколки, снимки, отзиви на туристи Ресторанти и кафенета

Как да хакнете Nokia: подробни инструкции

Не може да се промени хост файлът на windows 8

• Изтеглете psd файл. Как да отворите PSD файл? Най-добрите програми за четене и редактиране: правим без Photoshop. Как да отворите .PSD файл
• Как да върнете актуализация на конфигурация 1s 8
• Защо USB портовете не работят?