CC BY
38
ИНФОРМАТИКА, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА И УПРАВЛЕНИЕ
УДК 519.715, 681.3.06 И. И. Бикмуллина
МАТЕМАТИЧЕСКАЯ МОДЕЛЬ СИНТЕЗА UML ДИАГРАММЫ КЛАССОВ
Ключевые слова: предметная область, UML, виды отношений, аксиома, синтез диаграммы классов.
Проанализированы технологии и проблемы разработки информационных систем. Исследование ориентировано на структурный синтез информационной системы. Из множества структурных моделей информационной технологии выбрана модель диаграммы классов UML. Сформулирована математическая постановка задачи синтеза диаграммы классов UML. Для разработки автоматизированного синтеза моделей UML формулируется система аксиом в качестве правил принятия решений, которая основывается на семантические отношения предметной области.
Key words: domain, UML, kinds of relationships, axiom, synthesis of class diagram.
Analyzed Technologies and problems of design of information systems. The study focused on structural synthesis of the information system. UML dass diagram chosen of the many structural models of information technology. The mathematical formulation of the task of synthesis of a class diagram UML is formulated. For the development of automated synthesis of UML models is formulated as a system of axioms as rules of decision-making, which is based on semantic relationships domain (of subject area).
Введение
Данная статья является продолжением статей [1,2], где были выделены: объект исследования - синтез структурных моделей информационных систем (ИС); предмет исследования, которым является автоматизированный структурный синтез объектов с иерархическими и неиерархическими связями на базе (семантических) моделей предметной области (ПрО); цель исследования всей работы - это повышение качества проектной проработки ИС благодаря автоматизированному синтезу (структурных) моделей. При этом из этого множества было принято решение выбрать диаграмму классов UML.
Унифицированный язык моделирования (UML) по мнению авторов [3] представляет собой (относительно) открытый стандарт, находящийся под управлением группы Object Management Group(OMG) [3], открытого консорциума компаний. UML является визуальным языком для создания объектно-ориентированных моделей самых разнообразных систем [4]. UML является визуальным языком моделирования общего назначения [5]. Методология UML по мнению авторов [6] разрабатывает проект (проектирует) определяя объект автоматизации и осуществляет построение для него информационной модели на физическом уровне вплоть до момента создания схем базы данных определенной СУБД и генерации (на различных объектно-ориентированных языках) кода [6].
Идея создания языка UML включала в себя не только реализацию стандарта для документирования и общения разработчиков, но и реализацию возможности использования UML как языка программирования. Однако, существует проблема, описанная в учебном пособии [7], заключающаяся в разработке и реализации, так как язык визуального моделирования по определению не мог содержать в себе всей выразительности объектно-ориентированных языков в плане проектирования (программирования) динамики и реализации алгоритмов [7].
Особенность ИС - это бинарное отношение ее базовых элементов и ПрО.
Разработана система аксиом и система (формальная) свойств и характеристик ИС, помогающие в описании: семантического, смыслового языка описания свойств и характеристик ИС, создания семантических ИС спецификаций; метод обрабатывания семантических характеристик ИС (спецификаций), что приводит к возможности решения задачи анализа и синтеза.
Ниже приводятся сформулированные, рассматриваемого исследования, задачи:
1. Выделение и проведение анализа современных методов синтеза структурных моделей ИС.
2. Разработка методики семантического синтеза моделей со структурными отношениями ПрО.
3. Разработка методики семантического синтеза структурных моделей ИС с неиерархическими отношениями.
4. Разработка и проектирования архитектуры автоматизированного структурного синтеза систем.
5. Проведение экспериментального исследо-ванияе разработанных методик и алгоритмов.
Конечная цель автоматизации синтеза диаграммы классов заключается в передаче функций разработки автоматизированных систем специалисту-предметнику, потому что только он может вложить в автоматизированную систему все богатство используемых методических приемов [1].
Приведенные формулировки задачи и примеры к ним в статьях [1,2] показывают некоторую общую последовательность решения задач автоматизированного проектирования:
1. специалисты, эксперты в различных ПрО профессий создают спецификации своих профессиональных взглядов на свойства и особенности ИС;
2. проверка автоматизированной системой на непротиворечивость (логическую) профессио-
нальных характеристик (спецификаций) и (или) дает заключение о том возможно ли использовать совместно различные профессиональные характеристики (спецификации);
3. последующие задачи проектирования решаются с помощью преобразования (доказательного) исходных профессиональных характеристик (спецификаций) с целью обеспечения совокупности необходимых (заданных) свойств (характеристик) и особенностей ИС;
4. заключительным этапом является синтез конструкции ИС по полученному варианту спецификации свойств и ее характеристик.
В статьях [1,2] описан как подход автоматизированного синтеза в целом, так и отдельных ее этапов. На основе этого схема процесса проектирования ИС заключается:
1. Описание ПрО, где предлагается язык описания семантических связей между сущностями и операциями, рассматриваются средства представления информации возможности ее транслирования в логические модели.
2. Описание логической модели ИС, где рассматривается более подробно процесс перехода от логических моделей в модели физические.
3. Описание физической модели языка программ, где акцент сделан в сторону трансляции физических моделей в программный код.
4. Программный код.
То есть основной результат исследования заключается в выработке концепции семантики ИС в качестве смысловой базы моделирования содержания, определении ИС, получения научных методологий автоматизированного проектирования.
В работе [2] предлагается новое логическое исчисление первого порядка, в отличие от классического исчисления направленное на автоматизацию поиска логического вывода, для которого применяют разработанный язык позитивно-образованных формул.
Рассматривается к рассматриваемой ПрО методика автоматического доказательства теорем. Данная методика применяется в решении задач управления объектами.
В рамках настоящей работы планируется с использованием методик [8] и [9]:
1. разработать программную реализацию системы логического вывода (PSB - Problem Solver Basic) с входным языком;
При этом PSB в качестве автоматического доказательства теорем для решения конструкторских задач уже существует [9].
2. сформулировать демонстрационные задачи проектирования и проанализировать эксперименты проводимые с целью решения рассматриваемых задач;
3. спроектировать интерфейс между SD(автоматизированная система, Semantic Design) системой и PSB системой, описанной ранее.
Интерфейс создается с целю использования более простого языка описания формулировок решаемых задач. SD разрабатывается в этом исследовании.
4. разработать методику решения проектных задач.
Анализ технологий создания программных систем
Попытки чрезмерной формализации процесса разработки программ, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) образовали ряд проблем, таких как необходимость повысить продуктивность разработки программного обеспечения (ПО). Для решения данной проблемы были предприняты попытки в усовершенствовании новых методов, технологий. Однако, разработчики программ пришли к решению, что невозможно достичь какого - то удовлетворительного результата даже применяя самые совершенные технологии и инструментальные средства, если данное применение производится бессистемно, а разработчики не обладают необходимой квалификацией для работы с данными технологиями, и сам проект в режиме «тушения пожара» (хаотически) реализуется, управляется. Поэтому разработчики программ выделили более фундаментальную проблему в данной ПрО. Данная проблема заключалась в неспособности эффективного управления проектами разработки ПО [10].
Бессистемное применение технологий создания программного обеспечения, в свою очередь, порождает разочарование в используемых методах и средствах. И является причиной распространения «хаотического» процесса создания программного обеспечения. Разрабатываются такие подходы как «Agile software development» (Быстрая разработка ПО, 2001) [10]. В практической реализации одним из наиболее известных примеров «быстрая разработка программного обеспечения» подхода является «Экстремальное программирование» (Extreme Programming - XP) [10].
На основе анализа задач проектирования информационных технологий сделаны следующие выводы:
1) В настоящее время методы автоматизированного построения моделей информационных систем проработаны в недостаточной мере.
2) Веяние нынешнего времени вынуждает современных разработчиков объектно-ориентированных приложений создавать эффективные программные продукты в достаточно жёсткие промежутки времени [11].
3) При разработке ПО для большинства разработчиков важным является этап синтеза кода, чем моделирования разрабатываемой системы. Тем более предварительный синтез моделей разрабатываемой системы подразумевает под собой дополнительные трудозатраты, у которых важность и необходимость получаемых результатов осознается разработчиками программ спустя лишь некоторое время. К тому же, изучение CASE - средств считается достаточно сложным, где требуется прилагать усилия.
4) При разработке программных систем разрабатывается сопровождающая документация достаточно разноплановая и разнообразная, достаточно большого объема. Данная документация используется в качестве средства передачи информации
между разработчиками программных систем, средства управления проектированием ПО, средства передачи информации (для реализации, сопровождения разрабатываемого ПО) экспертами ПрО пользователям, на создание которой, по мнению автора [12], приходится основная доля стоимости данного ПО. Установлено, что диаграммы языка иМЬ чаще используются при написании отчетов, чем при разработке программ. Одной из существенных причин является большая трудоемкость разработки диаграмм. Поэтому необходима разработка средств автоматизации построения диаграмм иМЬ.
5) В процессе обучения студенты разрабатывают диаграммы поведения информационной системы после этапа кодирования программ только при образовании сложных проектных ситуаций или для формирования отчетной документации. Возникший стереотип часто распространяется и на профессиональную деятельность программиста. Это пытаются объяснить нехваткой времени. В результате получается недостаточно проработанный программный продукт.
Таким образом, мы часто видим, студентов с высокими знаниями, которые, тем не менее, разрабатывают системы, с полным пренебрежением к структурам данных, алгоритмам и структурам программного обеспечения. Для многих, «программирование» стало странным сочетанием беспринципного взлома и применения библиотек других людей (с весьма смутным представлением о том, что происходит). В промышленности США, по мнению автора [11], жалобы на трудности с поиском выпускников, которые понимают «системы» и «могут создавать ПО», являются глобальными, отражающими реальность.
6) Используя CASE-мышление, разработчик ПО делает уже свои программы лучше так, как визуализация программных объектов в моделях иМЬ дает возможность распознать ошибки, недоработки в проектируемой иерархии, простому процессу манипуляции этой иерархией (при ручном кодировании - это практически разработчиком не осуществимо).
7) В настоящее время ПрО охватывает знания различных экспертов. И как следствие этого возникает проблемы междисциплинарного взаимопонимания экспертов ПрО (специалистов различных профессий) и согласования разнообразия (профессионального) проектных работ. Возникает необходимость включения специалистов различных профессий в процесс создания программных изделий. При этом специалисты должны быть не только консультантами, но и полноправными участниками проектного процесса.
8) Языки описания заказчика и программиста значительно отличаются друг от друга. иМЬ являясь промежуточным языком между данными экспертами позволяет решить данную проблему.
9) Хорошая модель предметной области — это то, что хотят получить во время разработки и одно из тех, что предопределяет высокую оценку предметной области, но построить такую модель довольно таки не просто, даже специалисту в выбранной области.
10) Разработчикам ПО приходится мыслить моделями иМЬ, в терминах иМЬ. Переход же к данному типу мышления требует больших усилий (примерно такой же, как переход от процедурного програм-
мирования к объектно-ориентированному программированию).
11) В организации разработчики ПО отдельных проектов придерживаются стандартизованным техпроцессам разработки ПО (чаще всего уже до них введенных самой организацией). Поэтому разработчикам ПО приходится настраивать уже принятый в данной организации техпроцесс для достижения целей текущего проекта.
12) В настоящее время для поддержки UML существуют инструментальные приложения, созданы средства визуального программирования, обеспечивающих синтез из UML моделей листинг программы. Из данных приложений особо выделяется Rational Rose.
13) Установившийся стереотип (кодирование, а лишь затем моделирование) не дает возможности полностью реализовать средства автоматизации разработки ПО (заложенные, в таких программах, как Rational Rose).
Разработка и исследование
Основой для автоматического синтеза структурной модели являются правила принятия решения построения элементов структурных моделей.
Каждое правило принятия решений определяет возможные структурные сочетания компонентов и атрибутов. Можно представить и описать семантическими структурными моделями разнообразные семантические отношения между компонентами модели.
Для того чтобы реализовать синтез диаграмм классов UML нужно разработать систему аксиом. Сформулируем базовые аксиомы [13, 14] диаграммы классов UML, где нумерация аксиом будет обозначать:
• Число перед первой точкой делит базовые и специализированные аксиомы (1-базовые аксиомы, с которых начинается первоначальный синтез диаграммы классов, 2-аксиомы, рассматривающие подробно каждый вид отношения);
• Число после первой точкой делит аксиомы по видам отношения (например, 2.1 для отношения наследования, 2.2 для отношения агрегации);
• Число после второй точки позволяет пронумеровать аксиомы для определенного типа отношения (например, аксиомы 2.2.1, 2.2.2 - для отношения агрегации).
Будем пользоваться устоявшимися соглашениями облегчённой расстановки скобок записи формул [9, 15, 16, 17]. Так как легко можно числовые индексы обозначающие количество аргументов у предикатных и функциональных букв восстановить, то по возможности будем их опускать. Например, вместо предиката Predoc2 (x, y) будем писать Predocx (x, y), и если нет других двуместных («двухаргументных») предикатных букв Pre-doc, то вместо Predocx (x, y) будем писать просто Predoc (x, y). В данном случае обозначаем предикат Predoc не с помощью предикатной буквы (на-
пример, Р), а выразительнее (например Predoc) [9, 15].
Введем следующие обозначения: С - это множество всех классов; К - 1-е отношение (вид отношения) диаграммы классов (агрегация, наследование и т.д.), то есть множество связей (хКу) между двумя классами х и у, которое можно обозначить упорядоченной парой (х, у), 1</<5, где 5 - это количество отношений между классами в диаграмме классов UML; Ах - множество атрибутов класса х; N - множество допустимых имен атрибутов.
Аксиома 1.1. Между двумя классами существует единственное отношение.
Условие возникновения осмысленного отношения между классами заключается в:
- существовании двух классов;
- существовании необходимости взаимодействия классов друг с другом;
- существовании между классами единственного отношения (любого).
Пусть
х, у -это классы, х,у е С ;
К(х) - предикат, означающий «построен класс х»; 0,(х, у) - предикат, означающий «построено отношение Кг от класса х к классу у», г е 1,5 . Тогда аксиома запишется следующим образом: Эх Зу (К(х)&К(у)&0Х (х,у)&02 (х,у) ^ (Ях = К2)). Это означает, что если построено два класса и два отношения между ними, то эти отношения являются одним и тем же отношением, то есть между любыми двумя классами существует единственное отношение.
Аксиома 1.2. Если есть (существует) имя атрибута, то это имя уникально внутри данного класса.
То есть в одном классе не существуют атрибуты с одинаковыми именами. Пусть
х - это класс, х е С ;
К(х) - предикат, означающий «построен класс х»; а* - г-ый атрибут класса х (а* е Ах; г е 1,тх , где тх -количество атрибутов класса х);
А/г(х, г, п) - это предикат, означающий «для г-го атрибута класса х задано имя п», г е 1,тх , п Е N. Тогда аксиома запишется следующим образом: УхЗг Э Эк Эп1Эп2Эп3 (K(x)&Atr(xJ,щ)&Atr(xj,n2)& &АК(х,к,п3)&(п1 =п2)&(п *п3)&(п2 *п3)=> =>( а1 = а2 )&(а1х Ф а3)).
Рассмотрим данную аксиому на примере. Пусть класс х содержит три атрибута. Предположим, что два из них будут с одинаковыми именами, а третий - с уникальным именем. Так как в классе должны быть атрибуты с уникальными именами, то в классе х существуют только атрибуты с уникальными именами.
Аксиома 1.3. В разных классах возможны атрибуты с одинаковыми именами.
Это означает, что если существует два различных класса, то в первом классе может существовать атрибут с таким же именем как у второго класса.
Таким образом, имя атрибута одного класса может совпадать с именем атрибута другого класса.
При этом одинаковыми являются имена атрибутов классов, а не их значения, которые сугубо индивидуальны для каждого класса. С использованием обозначений введённых выше данная аксиома запишется следующим образом:
Эх Зу Эг З; Зп1 Зп2 (г е 1,тх &] е\ту &К(х)&К(у)&
&А^(х,/,п1)&Ай"(у,У,п2)&(п1=п2)&(х*у)=>(а? ф ау).
Если у класса х есть атрибут с таким же именем как у класса у, то в данном случае данные атрибуты существуют независимо друг от друга.
Теперь сформулируем аксиомы для всех типов отношений, для определенных отношений между классами, используемых в диаграмме классов
имь.
Аксиома 2.1. Необходимо использовать между классами отношение наследования, если в классе используется один экземпляр другого класса.
Существует возможность возникновения исключительной ситуации, когда между двумя классами можно будет провести два вида отношения: наследования и агрегации. В этом случае система с помощью аксиомы 2.1 примет решение (сделает выбор) в пользу отношения наследования. Из выше представленных данных следует, что:
- потомком, при этом, является класс, использующий экземпляр другого класса;
- предком является тот класс, который предоставил данный экземпляр какому-то другому классу;
- предок предоставляет потомку только один свой экземпляр.
Пусть
х, у - это классы, где Зх,у е С; предикат К(у) означает «построен класс у»; предикат Predoc(x, у) означает «класс х предоставляет свой экземпляр классу у»; предикат Ро(отс(у, х) означает «класс у использует один экземпляр класса х»;
предикат Н(у, х) означает «существует отношение наследования от класса у к классу х». Тогда аксиома запишется следующим образом: ЗхЗу(К(х) &К(у)&Predoc(x,у) &Ро^отс{у,х)=> =>Н(у,х))
Аксиома 2.2.1. Между двумя классами существует отношение агрегация, если один класс использует несколько экземпляров другого класса. Таким образом, получаем что:
- класс «целое» - использует несколько экземпляров другого класса;
- класс «часть» - предоставляет несколько своих экземпляров;
- на класс «часть» класс «целое» имеет внутри себя ссылку;
- класс «часть» не включает внутри себя ссылку на класс «целое»;
- класс «часть» может в один момент времени находиться только в одном классе «целом». Пусть
х - класс «целое», х еС;
у - класс «часть» , у еС;
предикат К(у) означает «построен класс у»;
Whole(х, у) означает «класс х использует более
одного экземпляра класса у»;
Path(у, х) означает «класс у предоставляет более одного своих экземпляров классу х»;
Ag(y, х) означает «существует отношение агрегации от класса у к классу я».
Тогда аксиома запишется следующим образом: УхУу(К(х)&К(у)&Шо/в(х,у)&Ра^(у,х)=>Ад(у,х)).
Ниже отношение агрегации рассмотрено на примере компьютера и его составляющих.
При этом при удалении абстрактного класса «Компьютер» (класса «целое»), остальные классы (классы «часть») продолжат свое независимое существование.
Таким образом:
класс «Компьютер» - класс «целое»; класс «Мышь» - класс «часть»; класс «Клавиатура» - класс «часть»; класс «Процессор» - класс «часть». Аксиома 2.2.2. Между двумя классами существует отношение агрегация, если класс «целое» стандартный компонент системы программирования, а класс «часть» не стандартны компонент системы программирования.
Таким образом, получаем что:
- существует класс «часть», который не является стандартным компонентом системы программирования;
- в агрегации оба объекта могут существовать независимо. То есть если класс «целое» (контейнер) будет уничтожен, то класс «часть» (содержимое) не будет уничтожен автоматически.
Пусть
х - класс «целое» , Ух е С;
у - класс «часть» , Уу е С;
предикат К(у) означает «построен класс у»;
предикат ££(х) означает «существует стандартный
компонент системы программирования класса х»;
предикат Ag(y, х) означает «существует отношение
агрегации от класса у к классу х».
Тогда аксиома запишется следующим образом:
VxVy(K(x)&K(y)&SS(х)& -1$5(у) => Ад(у,х)).
Аксиома 2.2.3. Если между двумя классами существует отношение агрегация, то создание и удаление экземпляров класса «часть» решается явным образом (самим экспертом).
То есть можно сразу удалять экземпляры класса «часть». Пусть
х - класс «целое» , Ух е С;
у - класс «часть» , Vу е С;
предикат К(у) означает «построен класс у»;
предикат Del(y) означает «ликвидация экземпляров
класса у решается явным(самим разработчиком ПО)
образом»;
Ag(y,x) - «существует от класса у к классу х отношение агрегации».
Тогда аксиома запишется следующим образом: УхУ у(К(х)&К(у)&Ад(у,х) => Ов/(у)). Аксиома 2.3.1. Между двумя классами существует отношение композиция, если классы «целое» и «часть» стандартные компоненты системы программирования.
Таким образом, получаем что:
- класс «целое» -это стандартный компонент системы программирования;
- класс «часть» - стандартный компонент системы программирования. Пусть
х - класс «целое» , Ух е С;
у - класс «часть» , У у е С;
предикат К(у) означает «построен класс у»;
предикат ££(х) означает «является стандартным
компонентом системы программирования класса
х»;
предикат Ко (у, х) означает «существует отношение композиции от класса у к классу х». Тогда аксиома запишется следующим образом: VxVy(K(x)&K(y)&SS(х)&SS(y) => Ко(у,х)). Аксиома 2.3.2. Если класс «целое» и класс «часть» связаны между собой отношением композиция и происходит удаление класса «целое», то удаляется и данный класс «часть».
Таким образом, когда удаляется класс «целое», то удаляются и классы «часть». Пусть
х - класс «целое» , Ух е С; у - класс «часть» , Vу е С; предикат К(у) означает «построен класс у»; предикат СШ(х) означает «удаляется класс х»; предикат Ко (у, х) означает «существует отношение композиции от класса у к классу х». Тогда аксиома запишется следующим образом: УхУ у (К(х)&К(у)&Ко(у,х)&Си^(х) => Си^(у)). Аксиома 2.3.3. Если между классами «целое» и «часть» существует отношение агрегации, но при этом, также, при удалении класса «целое» следом происходит удаление класса «часть», то отношение между этими классами определяется как композиция.
То есть композиция - это агрегация, но когда класс «часть» (включаемый объект) не может существовать без своего класса «целое» (контейнера). Пусть
х - класс «целое» , Ух е С; у - класс «часть» , Уу е С; предикат К(у) означает «построен класс у»; предикат СШ(х) означает «удаляется класса х»; предикат Ас^(у) означает «автоматически удаляется класса у»;
Ag(y, х) - «существует отношение агрегации между у и х, где данное отношение направлено от у к
х»;
Ко(у, х) - «существует отношение композиции от класса у к классу х».
Тогда аксиома запишется следующим образом: УхУу(К(х) &К(у) &Ад(у,х)&Си? (х) &Аси? (у)=> =>Ко(у,х)).
Если построены класс х и у и между существующим классом у («часть») и классом х («целое») существует отношение агрегации, а также при удалении экспертом х автоматически удаляется и класс у, то в данном случае это данное отношение является композицией.
Заключение
На основе анализа технологий разработки ПО определяется важная проблема - это необходимость автоматизированного синтеза моделей UML.
Создается система аксиом, реализующаяся в правилах принятия решений в автоматизированном синтезе диаграмм классов UML.
Реализация системы аксиом в задаче синтеза диаграмм классов UML, проверка на полноту и непротиворечивость планируется рассмотреть в последующих публикациях.
Литература
1. И.А. Барков, И.И. Бикмуллина, Семантическое моделирование учебных задач в интеллектуальных образовательных средах. № 2. Вестник Казанского гос. технич. унта им. А. Н. Туполева, 2012. С. 216-220.
2. И.И. Бикмуллина, И.А. Барков, А.П. Кирпичников, Разработка методики автоматизированного синтеза информационных систем на основе семантических отношений предметной области. Т. 18. № 7. Вестник технологического университета, 2015. C. 236-242.
3. Simona Bernardi, Jos'eMerseguer, Dorina C. Petriu, Dependability Modeling and Assessment in UML-Based Software Development. Article ID 614635. The Scientific World Journal, 2012. С. 11.
4. Dal Cin M., Extending UML towards a Useful OO-Language for Modeling Dependability Features. №3. Informatik. University of Erlangen-Nurnberg, Germany.
5. Andrea Bondavalli, Dal Cin Mario, Latella Diego, Majzik Istvan, Andras Pataricza, Giancarlo Savoia. Dependability analysis in the early phases of UML-based system design. International Journal of Computer Systems Science & Engineering.
6. А.В. Иващенко, А.А. Сталькин, У.М. Калышенко, Применение методологии UML при автоматизации управления бизнес-процессами: эл. журнал. http://zhumal.ape.relarn.ru/artides/2004/094.pdf. Самар-скийГАУ, 2004.
7. Ю.Ю. Якунин, Технологии разработки программного обеспечения. Версия 1.0: электрон. учеб. пособие. Красноярск, ИПК СФУ, 2008.
8. И.А. Барков, Теория конструкторской семантики. ИжГТУ, Ижевск, 2003, С. 30.
9. С.Н. Васильев, А.К. Жерлов, Е.А. Федосов, Б.Е. Федунов, Интеллектное управление динамическими системами. Физмат лит.,М., 2000. C. 250.
10. А.М. Вендров, Современные технологии создания программного обеспечения. Обзор. № 4.Jet Info Online, 2004.
11. Bjarne Stroustrup. What Should We Teach New Software Developers? Why? Vol. 53 № 1. Communications of the ACM, 2010. С. 40-42.
12. Sommerville Ian, Software Engineering. Addison-Wesley Publishing Company, 1992.
13. Н.А. Черяк, Логика: Учебное пособие. Омск: ОГУ, 2004.C. 84.
14. В.И. Кириллов, А.А. Старченко, Логика : Учебное пособие. Изд-во Проспект, М, 2008. C. 240.
15. Н.Н. Непейвода, Прикладная логика: Учебное пособие. 1997-2002.
16. А.П. Кирпичников, С.А. Ляшева, М.П. Шлеймович, Обнаружение и сопровождение объектов в бортовых системах обработки изображений. Т. 17. № 13. Вестник Казанского технологического университета, 2014. С. 331-334.
17. А.П. Кирпичников, С.А. Ляшева, М.П. Шлеймович, И.В. Леонова, Проектирование автоматизированной системы обработки данных успеваемости студентов на основе нечеткой логики. Т. 17. № 22. Вестник Казанского технологического университета, 2014. С. 372376.
© И. И. Бикмуллина - аспирант кафедры автоматизированных систем обработки информации и управления КНИТУ-КАИ им А.Н. Туполева, e-mail: elsiyar-b@yandex.ru.
© 1 I. Bikmullina - postgraduate of the Department of Automated Information Processing Systems & Control, KNRTU named after A.N. Tupolev, e-mail: elsiyar-b@yandex.ru.
