Преподаватель который помогает студентам и школьникам в учёбе.

Применение объектно-ориентированного подхода при проектировании информационной системы (Теоретические основы объектно-ориентированного подхода)

Содержание:

Введение

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

В большинстве случаев используемые программные комплексы хранят производственную информацию и эта информация должна быть доступна некоторому количеству пользователей и, зачастую, пользователи работают с данными одновременно. Эти идеи послужили основой концепции, согласно которой данные должны быть организованны в базы данных, для управления которыми, широко используются системы управления базами данных (СУБД).

Проектирование экономических информационных систем (ЭИС) - логически сложная, трудоемкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов.

В начале 70-х гг. в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, в 1995г. компания StandishGroup проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие выводы:

Только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет.

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

На этом фоне, выгодно отличается объектно-ориентированный подход к проектированию ПО. Он устраняет эти и другие недостатки, он обладает богатым набором изобразительных средств. Вот почему, целью моей курсовой работы является раскрытие современных методов и средств проектирования, в частности в объектно-ориентированном подходе к проектированию ИС.

В ходе выполнения работы были решены следующие задачи:

рассмотрение сущности и преимуществ объектно-ориентированного подхода;
анализ предметной области;
применение объектно-ориентированного подхода при проектировании ИС.

Теоретические основы объектно-ориентированного подхода

Основные понятия, используемые в объектно-ориентированном подходе

Термин «объект» или эквивалентные ему понятия появились практически независимо в различных областях, связанных с компьютерами, в процессе разработки [6]:

архитектуры компьютеров (Burroughs 5000, Plessey 250, IBM System/38, Intel 432);

объектно-ориентированных операционных систем (Plessey/System 250, Secure UNIX, StarOS, iMax);

объектно-ориентированных языков программирования (Simula, Smalltalk, Modula);

теории баз данных (модели «сущность-связь»);

систем искусственного интеллекта (фреймы).

При разработке программного обеспечения термин «объект» впервые был введен в языке Simula 67 для моделирования сущностей предметной области.

Согласно [6, с.23–25] объект – это абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением.

Абстракция (лат. abstractio – отвлечение) – форма познания, основанная на мысленном выделении существенных свойств и связей предмета и отвлечении от других, частных его свойств и связей [5, с. 63http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M11/Literatura.htm - lit35]. При этом «существенное» и «частное» должны рассматриваться с точки зрения решаемой задачи (предметной области). В объектно-ориентированном подходе абстракция – это модель сущности, описывающая ее свойства и поведение.

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

Индивидуальность – это свойство сущности, с помощью которого ее можно отличить от других. Т. е., говоря об объекте «поезд», имеется в виду не обобщенное понятие поезд, как нечто состоящее из локомотивов и вагонов, а конкретный грузовой поезд с номером 1025, весом 4600 т, ведомый электровозом переменного тока ВЛ80Т с серийным номером 027, состоящий из четырехосных полувагонов с конкретными номерами и т. д.

В то же время степень абстракции с точки зрения решаемой задачи может быть и более высокой. Например, при выполнении тяговых расчетов к графику движения поездов не требуется информация о серийных номерах локомотивов и вагонов, т. е. нет потребности в отличии друг от друга электровозов ВЛ80Т с серийными номерами 027 и 028.

Для концептуальной группировки однотипных объектов в объектно-ориентированном подходе используется понятие «класс». Класс – это множество объектов, имеющих общую структуру и поведение [7, с.39]. Таким образом, класс – это шаблон, на основе которого генерируются (создаются) однотипные объекты. В качестве синонима понятия «объект» часто употребляют понятие «экземпляр класса».

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

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

Наследование – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой. Применительно к классам это означает, что дочерний класс (узкая категория) полностью включает в себя (наследует) все атрибуты и методы, определенные в родительском классе (общей категории). При этом в дочернем классе могут быть определены дополнительные атрибуты и методы.

Например, дочерний класс «круг» будет наследовать от родительского класса «геометрическая фигура» все атрибуты (x, у – координаты центра фигуры, color – цвет фона и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.), а также иметь дополнительный атрибут (r – радиус).

Инкапсуляция (информационная закрытость) – принцип, в соответствии с которым содержание внутреннего устройства элементов системы должно быть скрыто друг от друга. Этот принцип предписывает обмен информацией между объектами системы только в минимально необходимом объеме, ограничение доступа к атрибутам и методам объектов (классов) со стороны других объектов (классов) и полное скрытие алгоритмической реализации методов от других объектов (классов).

Полиморфизм – принцип построения элементов модели так, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Например, методы draw() (нарисовать) или calculateS() (рассчитать площадь) для классов «круг» и «ромб», определенных путем наследования атрибутов и методов родительского класса «фигура», алгоритмически должны быть реализованы по-разному.

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

Базовыми составляющими объектно-ориентированного подхода являются:

унифицированный процесс;

унифицированный язык моделирования;

шаблоны проектирования.

Унифицированный процесс – это процесс разработки программного обеспечения (ПО), который обеспечивает упорядоченный подход к распределению задач и обязанностей в организации-разработчике [5, с.67]. Унифицированный процесс охватывает весь жизненный цикл ПО, начиная с определения требований и заканчивая сопровождением, и представляет собой обобщенный каркас (шаблон, скелет), который может быть применен (специализирован) для разработки и сопровождения широкого круга систем.

Неотъемлемой частью Унифицированного процесса является UML – язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно-ориентированного подхода [3, с.58]. Следует отметить, что Унифицированный процесс и UML разрабатывались совместно.

На стадиях анализа и проектирования часто используются так называемые шаблоны (паттерны) проектирования. Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы [4]. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML (например, диаграммы классов, кооперации и/или последовательности), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов может резко сократить затраты и повысить качество разработки ПО.

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

Наиболее популярны два подхода (парадигмы) к анализу и проектированию информационных систем: структурный и объектно-ориентированный.

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

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

Второй вид декомпозиции – объектно-ориентированный. В рамках этого подхода система разбивается на набор объектов, соответствующих объектам реального мира, взаимодействующих между собой путем посылки сообщений.

Вторым отличием является объединение в объекте как атрибутивных данных (характеристики, свойства), так и поведения (функции, методы). В функционально-ориентированных системах функции и данные хранятся (существуют) отдельно.

Третье отличие двух подходов заключается в структурной организации внутри модулей системы. В структурном подходе модуль состоит из функций, иерархически связанных между собой отношением композиции (англ. part-of – часть-целое), т. е. функция состоит из подфункций, подфункция из подподфункций и т.д. В объектно-ориентированном подходе иерархия выстраивается с использованием двух отношений: композиции и наследования (англ. is-a – это есть). При этом в объектно-ориентированном подходе «объект-часть» может включаться сразу в несколько «объектов-целое». Таким образом, модуль в структурном подходе представляется в виде дерева, а в объектно-ориентированном подходе – в виде ориентированного графа, т. е. с помощью более общей структуры.

Наиболее популярными методологиями, поддерживающими объектно-ориентированный подход, в настоящий момент являются:

унифицированный процесс (Unified Process, UP);

экстремальное программирование (eXtreme Programming, XP);

гибкое моделирование (Agile Modeling, AM).

Базовым средством фиксации (документирования) результатов проектирования систем посредством этих методологий является унифицированный язык моделирования (Unified Modeling Language, UML).

Преимущества и недостатки объектно-ориентированного подхода

В отличие от структурного подхода объектно-ориентированный имеет ряд преимуществ:

Описание системы в виде объектов больше соответствует содержательному смыслу предметной области. Например, при использовании структурного подхода БД должна удовлетворять требованиям нормализации, в соответствии с которыми данные по одному и тому же объекту (сущности из реального мира) могут храниться в нескольких таблицах;

Сущности реального мира, как правило, обладают поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга;

Объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней и меньшей внешней связности между компонентами системы. Это облегчает решение проблем:

адаптации системы к изменению существующих или появлению новых требований;

сопровождения системы на разных стадиях жизненного цикла;

повторного использования компонентов;

Объектно-ориентированный подход позволяет легче организовать параллельные вычисления, так как каждый объект обладает собственными значениями характеристик (атрибутов) и поведением, за счет чего можно добиться его автономной работы;

Case-средства, поддерживающие объектно-ориентированный подход, на основе информации об объектах позволяют достичь большей степени автоматизации кодогенерации. Case-средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД.

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

Реализация объектно-ориентированного подхода при проектировании ИС

Постановка задачи

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

Пользователи комплекса подразделяются на следующие функциональные подгруппы:

пользователь (может просматривать данные об услугах и автомоечном комплексе);

Клиент (может записаться на мойку);

администратор (может модифицировать некоторые данные).

Разработанная система должна:

принимать заявки от клиентов автомобильной мойки

обеспечить защиту от несанкционированного доступа к данным

автоматизировать систему приема заявок

предоставлять пользователю и сотрудникам комплекса информацию в удобном для просмотра виде

Выбор средств объектно-ориентированного подхода

UML (Unified Modeling Language — унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна генерация исходного кода.

Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов, а с 1997 года является стандартом OMG в области визуального объектно-ориентированного моделирования и широко используется на практике, будучи реализован в рамках многих CASE-средств^[1].

Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах^[2]:

Use case diagram (диаграммы прецедентов);

Activity diagram (диаграммы активности);

Sequence diagram (диаграммы последовательностей действий);

Use case diagram (диаграммы прецедентов)

Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.

Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).

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

Activity diagram (диаграммы активности)

Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.

Sequence diagram (диаграммы последовательностей действий)

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

Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами.

Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

Результаты применения объектно-ориентированного подхода

Целью данного этапа является проведение анализа бизнес-процессов заказчика и на основе данного анализа построение модели автоматизированной системы управления (АСУ). Для этого необходимо произвести анализ объектов капитального строительства, графика и объема их финансирования, условия заключаемых договоров и этапы их оплаты. Также необходимо провести анализ роли ответственных лиц (Actors) и т.д. Задача это не простая и требует значительных аналитических усилий и опыта. Результатом этой работы должен быть список ролей в компании заказчика, четкое понимание процесса и список объектов (сущностей), участвующих в этом процессе. Все это и должно найти отражение в диаграммах Rational Rose. Кроме того, необходимо вместе с заказчиком составить список требований к ИС.

Используем следующий подход: используем Use case diagram для отображения списка операций, которые должна выполнять наша система; иначе говоря, это требования к системе. Каждый Use case – это некоторый процесс (последовательность действий), поэтому мы должны использовать Sequence diagram для его детализации. На этой диаграмме мы отображаем объекты из предметной области (объекты, участвующие в бизнес-процессе); таким образом, мы получаем экземпляры некоторых классов и их взаимодействие. Sequence diagram отображает сам процесс, статическая картина взаимодействия объектов отображается с помощью Class diagram.

Начнем создавать диаграмму прецедентов – Use case diagram (диаграммы прецедентов). На Use case diagram отображаем взаимодействие между ролями (актерами) и прецедентами (т.е. это случаи использования ИС)^[3].

Прецедент – это некоторый процесс, в котором обычно участвуют несколько объектов.

Диаграмма прецедентов

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

Актер – это роль, которую пользователь играет по отношению к системе.

Актерами являются: Клиент, Пользователь, Администратор.

Рис. 1. Диаграмма прецедентов

Прецедент- "Запись клиента на мойку"

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

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

Основной поток

Прецедент начинается, когда пользователь заходит на сайт.
Пользователь заходит под своим зарегистрированным именем и паролем.
На экран выводится сообщение об успешном входе на сайт.
Далее клиент переходит по вкладке оформить заявку.
На экран выводится форма для оформления заявки, предоставляется возможность заполнить такие поля как: Автомобиль, Услуга, Терминал и дата записи.
На экран выводится сообщение об успешно добавленной записи “Запись добавлена”
В базу данных добавляется новая запись.
Прецедент завершается.

Альтернативный поток А1. Не все данные были введены.

1. Система информирует пользователя, какие данные не были введены и просит ввести эти данные.

2. Пользователь вводит необходимые данные и нажимает кнопку "Отправить".

3. Система определяет все ли запрашиваемые данные введены. Если не все, то выполняется альтернативный поток А1. Если во время отправки возникли ошибки, то выполняется поток ошибок Е1.

4. Система выводит сообщение о том, что данные успешно отправлены.

5. Прецедент завершается.

Поток ошибок Е1. Ошибка при отправке данных.

1. В браузере отображается сообщение о ошибке при отправке данных и приглашение ввести данные еще раз.

2. Пользователь вводит необходимые данные и нажимает кнопку "Отправить".

4. Система выводит сообщение о том, что данные успешно отправлены.

5. Прецедент завершается.

Диаграммы взаимодействия (interaction diagrams)

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

Как правило, описывает поведение только одного варианта использования.

Существует два вида диаграмм взаимодействия: диаграммы последовательности (Sequence diagrams) и диаграммы кооперации (collaboration diagrams)

Диаграммы последовательности (Sequence diagrams)

Проведенный нами анализ бизнес-процессов у заказчика должен отобразиться в диаграммных последовательностях действий - Sequence diagram (диаграммы последовательностей действий), показывающих обмен сообщениями между объектами. На рисунке 2 создан данный вид диаграммы для наиболее значимого прецедента.

Рис.2 Диаграмма последовательности для прецедента “Запись клиента на мойку”

Рис.3. Кооперативная диаграмма для прецедента «Запись клиента на мойку»

Процесс проектирования базы данных состоит из следующих отдельных шагов: концептуального проектирования, проектирования логической структуры базы данных, которая поддерживается СУБД и описывает представление пользователя о данных, и выбора физической структуры, которая включает представление данных, методы доступа и физическое группирование данных^[4].

Построим ER-модель системы.

Основными понятиями ER-модели являются сущность, связь и атрибут.

Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности (это требование в некотором роде аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах или требованию идентифицируемости объектов (object identity) в объектно-ориентированных системах).

Связь – это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи).

Как и сущность, связь - это типовое понятие, все экземпляры обеих пар связываемых сущностей подчиняются правилам связывания.

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

Определим атрибуты сущностей:

НКлиента-ключ
Фамилия, Имя, Отчество, Телефон, Адрес
НТипа – ключ
Описание, Категории
НАвто – ключ
Тип авто, Владелец, Марка, Гос. Номер.
Нуслуги - ключ
Описание, Базовое время выполнения, Базовая стоимость, Наименование.
НЗаказа – ключ
Время, Подтверждение, Длительность
НТерминала – ключ
Категория, Описание
НСотрудника – ключ
Должность, Фамилия, Имя, Отчество, Телефон, Адрес, Дата приема на работу
НЗаписи - ключ
Тип записи, Логин, Пароль, Дата регистрации

В результате проектирования получилась схема данных, изображенная на рис.4.

Рис. 4 Схема данных

Заключение

В работе рассмотрены основные понятия, касающиеся применения объектно-ориентированного подхода к проектированию информационных систем.

Было произведено моделирование взаимоотношений с клиентами автомоечного комплекса. Для разработки данной системы был использован унифицированный язык моделирования UML и Rational Rose - case– средство, помогающее строить модели UML.

Разработанная и реализованная информационная система представляет из себя первый этап проекта по автоматизации развивающейся фирмы и отвечает всем основным требованиям.

Разработанная ИС позволяет приложению:

хранить и редактировать данные о клиентах, услугах предоставляемых данным комплексом, а так же используя удобный интерфейс возможна запись клиентов;
искать и просматривать необходимые данные;
автоматизировать создание заявок.

К достоинствам данной информационной системы можно отнести выбранные средства проектирования и реализации – проектирование с использованием UML позволило подойти к этапу реализации с четко сформулированными задачами и сократить временные затраты на создание базы данных, сделала систему производительной и удобной с точки зрения использования, модификации и настройки.

Список использованной литературы

Введение в системы баз данных – СПб: Издательский дом "Вильямс", 200. - 848 с.;

Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. // М.: «Финансы и статистика», 2011.

Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: Лори, 2009.

Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.

Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2006. 450 – 490 с.
Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.
Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2010. - 656 стр.
Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2006.
Разработка программного обеспечения - СПб : "Питер", 20100. - 592 стр.
Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2011 – 400с.:ил;
Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2006, 250с., ил.

Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006. ↑
Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: Финансы и статистика, 2010 ↑
ГОСТ 19.701-90. Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения ↑
Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998. ↑