Прохождение практики в ООО "Фо Тапс"

Министерство общего и профессионального образования
Российской Федерации
ФГБОУ ВПО «Тольяттинский государственный университет»
ТГУ
Кафедра «Прикладная математика и информатика»

ОТЧЕТ
ПО УЧЕБНОЙ ПРАКТИКЕ



Выполнил:
группа ПМИб-1201
Место прохождения практики: ООО "Фо Тапс"


Руководитель практики от учреждения:
Рекомендуемая оценка работы:

Руководитель практики от вуза:
Оценка работы:







Тольятти
2014 г.
Содержание
1. Введение 3
1.1 Цели практики 3
1.2 Задачи практики 3
1.3 Сроки прохождения практики 3
1.4 Сведения о направленности предприятия 4
2. Общая характеристика организации 5
2.1 Краткая характеристика предприятия 5
2.2 Цели предприятия 5
2.3 Задачи предприятия 5
2.4 Организационная структура производства 6
2.4.1 Отдел маркетинга 6
2.4.2 Отдел разработки 7
2.4.3 Отдел продвижения 8
2.5 Действующие нормативные акты предметной области 9
3 Технология разработки программного обеспечения 12
3.1 Понятие о жизненном цикле програмного обеспечения 12
3.2 Общие сведения о применяемой технологии 13
3.3 Преимущества 14
3.4 Недостатки 15
3.5 Стандарты проектирования, оформления документации, пользовательского интерфейса 16
4 Объектно-ориентированные методы реализации программного обеспечения 18
4.1 Общие сведения 18
4.2 Понятие объекта 20
4.3 Объектно-ориентированное программирование 23
4.4 Объектно-ориентированное проектирование 24
4.5 Объектно-ориентированный анализ 25
Список литературы 26

1. Введение
1.1 Цели практики
 Закрепление теоретических знаний и практических навыков, полученных за предшествующий период обучения;
 подготовка к осознанному и углубленному изучению дисциплин, формирующих специальные знания, умения и навыки;
 получение первичных профессиональных умений и навыков в области разработки программного обеспечения.
1.2 Задачи практики
 Ознакомление со структурой организации и управлением разработкой программного обеспечения в организации (предприятии, подразделении);
 ознакомление с технологическими процессами разработки ПО, аппаратным и программным обеспечением организации (предприятия, подразделения), на котором проводится практика;
 изучение нормативной документации (стандартов, технических условий, положений, инструкций и т.п.) по эксплуатации аппаратных и программных средств, по программам испытаний и оформлению технической документации;
 освоение соответствующих объектно-ориентированных (или иных) технологий разработки ПО, проектирования и реализации БД, алгоритмов и структур данных.
1.3 Сроки прохождения практики
Первая неделя: 16 — 22 июня 2014
Вторая неделя: 23 — 29 июня 2014
1.4 Сведения о направленности предприятия
ООО "Фо Тапс" — развивающаяся организация, специализирующаяся на разработке и продаже программных продуктов для создания и передачи различного контента посредством использования Web-технологий.



















2. Общая характеристика организации
2.1 Краткая характеристика предприятия
ООО "Фо Тапс" выполняет разработку, продажу и сопровождение ряда программных продуктов, основной задачей которых является работа с сайтами. Их создание, передачи и продвижение.
2.2 Цели предприятия
 Получение прибыли;
 Обучение молодого персонала.
2.3 Задачи предприятия
 Ведение исследований на рынке и поиск потребителей и поставщиков;
 разработка программных продуктов для удовлетворения потребностей потребителей;
 интеграция и сопровождение разработанных программных продуктов;
 продажа разработанных программных продуктов.

2.4 Организационная структура производства
2.4.1 Отдел маркетинга
В отделе маркетинга начинается постановка большинства производственных задач. Отдел маркетинга занимается определением новых потребностей на информационном рынке, поиском потребителей и новых поставщиков. Отдел маркетинга контактирует с заказчиками и принимает от них заказы на осуществление услуг в области разработки.
Задачи отдела маркетинга:
 проведение бесед с клиентами;
 управление рекламой;
 постановка задач управленческому аппарату;
 исследование рынка, поиск новых поставщиков и заказчиков в пределах всего мира.

2.4.2 Отдел разработки
Данный отдел занимается разработкой макетов продукции, проработкой интерфейса, программированием и тестированием.
В отделе разработки есть следующие должности:
 Дизайнер
 Верстальщик
 Программист
Дизайнеры занимаются разработкой макетов сайта, приложений, разработкой вида интерфейса.
Верстальщик составляет формы и страницы приложений и сайтов по макету дизайнера.
Программист занимается программирование созданных форм и страниц. Тестированием программного продукта.
Программист также выполняет следующие задачи:
 проведение проверки на совпадение конечного результата с желанием заказчика;
 проведение проверки на корректность работы готовых модулей, осуществление контроля качества;
 составление отчетов о требующихся изменениях;
 формирование задач срочного внесения изменений.
2.4.3 Отдел продвижения
Основная задача отдела продвижение является продвижение программных продуктов, заказанных в компании.
Задачи отдела продвижения:
 Анализировать данные о программных продуктах;
 Составлять документацию по вносимым изменениям в программный продукт, для увеличения его популярности;
 Размещением рекламы о продукции.
2.5 Действующие нормативные акты предметной области
 Федеральный закон Российской Федерации от 26 июня 2008 года N 102-ФЗ Об обеспечении единства измерений.
 Приказ №1081 от 30 ноября 2009 г. Об утверждении Порядка проведения испытаний стандартных образцов или средств измерений в целях утверждения типа, Порядка утверждения типа стандартных образцов или типа средств измерений, Порядка выдачи свидетельств об утверждении типа стандартных образцов или типа средств измерений, установления и изменения срока действия указанных свидетельств и интервала между поверками средств измерений, требований к знакам утверждения типа стандартных образцов или типа средств измерений и порядка их нанесения. (Приложение №1, Приложение №2, Приложение №3, Приложение №4).
 ГОСТ Р 8.654-2009 Требования к программному обеспечению средств измерений. Основные положения.
 ГОСТ Р 8.596-2002 Метрологическое обеспечение измерительных систем. Основные положения.
 ГОСТ Р ИСО/МЭК 17025-2006 Общие требования к компетентности испытательных и калибровочных лабораторий.
 ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.
 ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование.
 ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.
 Рекомендация KOOMET R/LM/10:2004 Программное обеспечение средств измерений. Общие технические требования.
 МИ 2955-2005 ГСИ. Типовая методика аттестации программного обеспечения средств измерений и порядок её проведения.
 МИ 2174-91 ГСИ. Аттестация алгоритмов и программ обработки данных при измерениях. Основные положения.
 ГОСТ Р ИСО/МЭК ТО 12182-2002 Информационная технология. Классификация программных средств.
 ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств.
 ГОСТ Р ИСО/МЭК 14764-2002 Информационная технология. Сопровождение программных средств.
 ГОСТ Р ИСО/МЭК 15026-2002 Информационная технология. Уровни целостности систем и программных средств.
 ГОСТ Р ИСО/МЭК ТО 15271-2002 Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207. (Процессы жизненного цикла программных средств).
 ГОСТ Р ИСО/МЭК 15910-2002 Информационная технология. Процесс создания документации пользователя программного средства.
 ГОСТ 19.001-77 Единая система программной документации. Общие положения.
 ГОСТ 19.005-85 Единая система программной документации. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения.
 ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.
 ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению.
 ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.
 ГОСТ 28195-89 Оценка качества программных средств. Общие положения.
 ГОСТ 28195-99 Оценка качества программных средств. Общие положения.
 ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.
 ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
 ГОСТ Р 51188-98 Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство.
 ГОСТ Р 51189-98 Средства программные систем вооружения. Порядок разработки.
 ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию.
 ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления.
 ГОСТ Р ИСО/МЭК ТО 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения.

3 Технология разработки программного обеспечения
3.1 Понятие о жизненном цикле программного обеспечения
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Во многих случаях более ранние варианты, которые все еще продолжают использоваться, должны технически обслуживаться и находиться под контролем. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в стандарте ISO 12207-2.
Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
3.2 Общие сведения о применяемой технологии
В ООО "Фо Тапс" применяется каскадная модель жизненного цикла программного обеспечения, имеющая следующий вид:
 формирование требований;
 проектирование;
 реализация;
 тестирование;
 внедрение;
 эксплуатация и сопровождение.
Водопадная модель жизненного цикла была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.
3.3 Преимущества
 полная и согласованная документация на каждом этапе;
 легко определить сроки и затраты на проект.

3.4 Недостатки
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем.

3.5 Стандарты проектирования, оформления документации, пользовательского интерфейса
SO/IEС JTC1/SC7 — международный технический комитет стандартов под контролем ИСО.
Стандарт проектирования устанавливает:
 набор необходимых моделей на каждой стадии проектирования и степень их детализации;
 правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов, набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов;
 требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта;
 механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии, правила проверки проектных решений на непротиворечивость.
Стандарт оформления проектной документации устанавливает:
 комплектность, состав и структуру документации на каждой стадии проектирования;
 требования к ее оформлению,
 правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
 требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
 требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя устанавливает:
 правила оформления экранов, состав и расположение окон и элементов управления;
 правила использования клавиатуры и мыши;
 правила оформления текстов помощи;
 перечень стандартных сообщений;
 правила обработки реакции пользователя.
4 Объектно-ориентированные методы реализации программного обеспечения
4.1 Общие сведения
Объектно-ориентированное проектирование состоит в описании структуры и поведения проектируемой системы, то есть, фактически, в ответе на два основных вопроса:
 из каких частей состоит система;
 в чём состоит ответственность каждой из частей.
Выделение частей производится таким образом, чтобы каждая имела минимальный по объёму и точно определённый набор выполняемых функций, и при этом взаимодействовала с другими частями как можно меньше.
Дальнейшее уточнение приводит к выделению более мелких фрагментов описания. По мере детализации описания и определения ответственности выявляются данные, которые необходимо хранить, наличие близких по поведению агентов, которые становятся кандидатами на реализацию в виде классов с общими предками. После выделения компонентов и определения интерфейсов между ними реализация каждого компонента может проводиться практически независимо от остальных.
Большое значение имеет правильное построение иерархии классов. Одна из известных проблем больших систем, построенных по ООП-технологии — так называемая проблема хрупкости базового класса. Она состоит в том, что на поздних этапах разработки, когда иерархия классов построена и на её основе разработано большое количество кода, оказывается трудно или даже невозможно внести какие-либо изменения в код базовых классов иерархии. Даже если вносимые изменения не затронут интерфейс базового класса, изменение его поведения может непредсказуемым образом отразиться на классах-потомках. В случае крупной системы разработчик базового класса просто не в состоянии предугадать последствия изменений, он даже не знает о том, как именно базовый класс используется и от каких особенностей его поведения зависит корректность работы классов-потомков.

4.2 Понятие объекта
Объект в программировании — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеющая заданные значения свойств и операций над ними. Как правило, при рассмотрении объектов выделяется то, что объекты принадлежат одному или нескольким классам, которые определяют поведение объекта. Термины «экземпляр класса» и «объект» взаимозаменяемы.
Понятие "объект" впервые было использовано более 30 лет назад при конструировании компьютеров с descriptor-based и capability-based архитектурами. В этих работах делались попытки отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программной абстракции и низким уровнем ЭВМ. По мнению сторонников этих подходов, тогда были созданы более качественные средства, обеспечивающие: лучшее выявление ошибок, большую эффективность реализации программ, сокращение набора инструкций, упрощение компиляции, снижение объема требуемой памяти.
С объектно-ориентированной архитектурой тесно связаны объектно-ориентированные операционные системы. Дейкстра, работая над мультипрограммной системой THE, впервые ввел понятие машины с уровнями состояния в качестве средства построения системы. Среди первых объектно-ориентированных ОС следует отметить: Plessey/System 250 (для мультипроцессора Plessey 250), Hydra (для CMU C.mmp), CALTSS (для CDC 6400), CAP (для компьютера Cambridge CAP), UCLA Secure UNIX (для PDP 11/45 и 11/70), StarOS (для CMU Cm*), Medusa (также для CMU Cm*) и iMAX (для Intel 432). Следующее поколение операционных систем, таких, как Microsoft Cairo и Taligent Pink, будет, по всей видимости, объектно-ориентированным [21].
Наиболее значительный вклад в объектный подход внесен объектными и объектно-ориентированными языками программирования. Впервые понятия классов и объектов введены в языке Simula 67. Система Flex и последовавшие за ней диалекты Smalltalk-72, -74, -76 и, наконец, -80, взяв за основу методы Simula, довели их до логического завершения, выполняя все действия на основе классов. В 1970-х годах создан ряд языков, реализующих идею абстракции данных: Alphard, CLU, Euclid, Gypsy, Mesa и Modula. Затем методы, используемые в языках Simula и Smalltalk, были использованы в традиционных языках высокого уровня. Внесение объектно-ориентированного подхода в С привело к возникновению языков C++ и Objective С. На основе языка Pascal возникли Object Pascal, Eiffel и Ada. Появились диалекты LISP, такие, как Flavors, LOOPS и CLOS (Common LISP Object System), с возможностями языков Simula и Smalltalk. Более подробно особенности этих языков изложены в приложении [22, 23].
Первым, кто указал на необходимость построения систем в виде структурированных абстракций, был Дейкстра. Позднее Парнас ввел идею скрытия информации, а в 70-х годах ряд исследователей, главным образом Лисков и Жиль, Гуттаг, и Шоу, разработал механизмы абстрактных типов данных. Хоар дополнил эти подходы теорией типов и подклассов.
Развивавшиеся достаточно независимо технологии построения баз данных также оказали влияние на объектный подход, в первую очередь благодаря так называемой модели "сущность-отношение" (ER, entity-relationship). В моделях ER, впервые предложенных Ченом, моделирование происходит в терминах сущностей, их атрибутов и взаимоотношений.
Разработчики способов представления данных в области искусственного интеллекта также внесли свой вклад в понимание объектно-ориентированных абстракций. В 1975 г. Мински выдвинул теорию фреймов для представления реальных объектов в системах распознавания образов и естественных языков. Фреймы стали использоваться в качестве архитектурной основы в различных интеллектуальных системах [24].
Объектный подход известен еще издавна. Грекам принадлежит идея о том, что мир можно рассматривать в терминах как объектов, так и событий. А в XVII веке Декарт отмечал, что люди обычно имеют объектно-ориентированный взгляд на мир. В XX веке эту тему развивала Рэнд в своей философии объективистской эпистемологии. Позднее Мински предложил модель человеческого мышления, в которой разум человека рассматривается как общность различно мыслящих агентов. Он доказывает, что только совместное действие таких агентов приводит к осмысленному поведению человека.
4.3 Объектно-ориентированное программирование
Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.
В данном определении можно выделить три части:
1) OOП использует в качестве базовых элементов объекты;
2) каждый объект является экземпляром какого-либо определенного класса;
3) классы организованы иерархически. Программа будет объектно-ориентированной только при соблюдении всех трех указанных требований. В частности, программирование, не основанное на иерархических отношениях, не относится к OOП, а называется программированием на основе абстрактных типов данных.
4.4 Объектно-ориентированное проектирование
Объектно-ориентированное проектирование - это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.
В данном определении содержатся две важные части: объектно-ориентированное проектирование:
1) основывается на объектно-ориентированной декомпозиции;
2) использует многообразие приемов представления моделей, отражающих логическую и физическую структуру системы, а также ее статические и динамические аспекты.
Именно объектно-ориентированная декомпозиция отличает объектно-ориентированное проектирование от структурного. В первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором — алгоритмами.

4.5 Объектно-ориентированный анализ
На объектную модель повлияла более ранняя модель жизненного цикла программного обеспечения. Традиционная техника структурного анализа, описанная в работах Де Марко, Иордана, Гейна и Сарсона, а с уточнениями для режимов реального времени у Варда и Меллора и Хотли и Пирбхая, основана на потоках данных в системе. Объектно-ориентированный анализ направлен на создание моделей реальной действительности на основе объектно-ориентированного мировоззрения.
Объектно-ориентированный анализ - это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.
Наиболее важным моментом объектно-ориентированного анализа и проектирования является квалифицированное распределение обязанностей между компонентами программной системы. Дело в том, что единственный вид деятельности, без которого невозможно обойтись. К тому же он оказывает определяющее влияние на масштабируемость, расширяемость и возможность повторного использования компонентов. Обязанности объектов и их взаимодействия изображаются с использованием диаграмм классов и диаграмм взаимодействий.
Список литературы
1. Harel D., Pnueli A. On the development of reactive systems //1. "Logic and Models of Concurrent Systems". NATO Advanced Study Institute on Logic and Models for Verification and Specification of Concurrent Systems. Springer Yerlag, 1985. pp. 477-498.
2. Specification and Description Language (SDL), International Engineering Consortium, http://www.iec.org/acrobat.asp?filecode=125
3. Буч Г., Рамбо Дж., Джекобсон A. UML. Руководство пользователя. М. ДМК 2000. 432 с.
4. Benveniste A. The Synchronous Languages 12 Years Later. Proceedings of the IEEE, vol. 91, 2003, no. 1, pp. 64-83.
5. Andre C. SyncCharts: A Visual Representation of Reactive Behaviors /Tech. Rep. RR 95-52,13 S, Sophia-Antipolis, France, 1995.
6. Шалыто A.A. SWITCH-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука, 1998. 628 с.
7. Гольдштейн Б. С. Сигнализация в сетях связи. Том 1. М.: Радио с связь, 2001.-439 с.
8. Specification and Description Language (SDL), рекомендации ITU-T серии Z.100, http://www.itu.int/rec/recommendation.asp?type=folders& lang=e&parent=T-REC-Z. 100
9. Encontre V. SDL: a standard language for Ada real-time applications /Proceedings of the conference on TRI-Ada 91, pp.45-53, October 21-25, 1991, San Jose, California, United States.
10. Harel D. Statecharts: A visual formalism for complex systems //Sci. Com-put. Program. 1987. Vol. 8, pp. 231-274.
11. Automata Studies / Shannon C.E., McCarthy J. Princeton University Press, 1956.
12. Harel D., Naamad A. The Statemate Semantics of Statecharts // ACM Trans. Softw. Eng. Methodology, vol. 5, October 1996. pp. 293-333.

13. Mikk E., Lakhnech Y., Petersohn C., Siegel M. On Formal Semantics of Statecharts as Supported by STATEMATE // Proceedings of the 2nd BCS-FACS Northern Formal Methods Workshop, Ilkley, 14-15 July 1997.
14. Хопкрофт Д., Мотвани P., Ульман Дж. Введение в теорию автоматов, языков и вычислений. М.: Вильяме, 2001. 528 с.
15. OMG Unified Modeling Language Specification, Version 1.5, March 2003.
16. Шалыто A.A., Шопырин Д.Г. Синхронное программирование //Информационно-управляющие системы. 2004. № 3, с. 35-42.
17. Апериодические автоматы /Астановский А.Г., Варшавский В.И., Ма-раховский В.Б. и др. М.: Наука, 1976. 423 с.
18. Palshikar G.K. An Introduction to Esterel //Embedded Systems Programming. 2001. http://www.embedded.com/storv/QEG20011018S0090
19. IEEE Standard VHDL Language Reference Manual. IEEE Press. Piscata-way, NJ, 1994, pp. 1076-1993.
20. Caspi P., Pilaud D., Halbwachs N., Plaice J. A. LUSTRE: A declarative language for programming synchronous systems. In ACM Symp. Principles Program. Lang. (POPL), Munich, Germany, 1987, pp. 178-188.
21. Berry G., Gonthier G. The Esterel synchronous programming language: Design, semantics, implementation //Sci. Comput. Program., vol. 19, Nov., 1992. pp. 87-152.
22. Benveniste A., Guemic P. Hybrid dynamical systems theory and the SIGNAL language //IEEE Trans. Automat. Contr., vol. AC-35, May 1990. pp. 535-546.
23. Maraninchi F. The Argos language: Graphical representation of automata and description of reactive systems /Presented at the IEEE Workshop Visual Lang., Kobe, Japan, 1991.