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

Содержание:

Введение

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

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

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

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

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

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

Объектом исследования является процесс проектирования информационных систем.

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

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

Для достижения поставленной цели необходимо решить ряд задач:

1. Рассмотреть процесс создания программных продуктов.
2. Изучить сущность процесса проектирования программного обеспечения.
3. Описать этапы проектирования программного обеспечения.
4. Дать определение объектно-ориентированному подходу к проектированию информационных систем.
5. Проанализировать инструменты автоматизации проектирования информационных систем.
6. Рассмотреть достоинства и недостатки объектно-ориентированного подхода.
7. Проектирование информационных систем
8. Процесс разработки информационных систем

Процесс создания программного обеспечения – это достаточно сложный и нелинейный процесс. Не существует одного четкого подхода к разработке программного обеспечения. Однако были разработаны стандарты, которые регламентируют этот процесс. К таким стандартам относят российский стандарт ГОСТ 34.601 «Стадии создания автоматизированных систем» и зарубежный стандарт ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

Однако не все разработчики строго следуют стандартам разработки программного обеспечения. За годы создания автоматизированных систем были созданы модели жизненного цикла программных продуктов, которые включают стадии разработки программных средств. Рассмотрим существующие модели.

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

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

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

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

1. Техническое задание;
2. Эскизный проект;
3. Технический проект;
4. Рабочую программу.

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

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

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

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

Итерационную модель также называют моделью с промежуточным контролем или моделью с циклическим повторением фаз. Структура итерационной модели представлена на рисунке 2.

Рисунок 2. Итерационная модель жизненного цикла программного обеспечения.

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

Спиральная модель жизненного цикла программного продукта является классическим примером применения эволюционной стратегии разработки программных средств. Модель была разработана Б. Боэмом в 1988. Основу модели составляют лучшие свойства каскадной модели жизненного цикла с учетом процесса макетирования, к которым был добавлен новый элемент – анализ риска, который отсутствовал в этих моделях. Спиральная модель состоит из четырех этапов, которые представлены четырьмя квадрантами спирали. Структура спиральной модели представлена на рисунке 3.

Рисунок 3. Схема спиральной модели жизненного цикла разработки ПО.

Рассмотрим этапы спиральной модели:

1. На этапе планирования осуществляется определение целей, вариантов и ограничений проекта.
2. На этапе анализа риска осуществляется анализ вариантов и распознавание/выбор риска проекта.
3. На этапе конструирования осуществляется разработка программного продукта следующего уровня.
4. На этапе оценивания происходит оценка текущих результатов разработки заказчиком.

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

На дальнейших этапах осуществляется определение проблемных и уточненных требований, при этом может использоваться метод моделирования. Заказчик дает оценку инженерной (конструкторской) работы и осуществляет внесение предложений по модификации текущего релиза АИС (квадрант оценки заказчиком). На следующей фазе осуществляется планирование и анализ рисков, который базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.

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

1. Сущность процесса проектирования

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

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

Цель процесса проектирования заключается в определении внутренних свойств системы и выявлении её внешних свойств на основании пользовательских требований к программному продукту. Выделенные требования подвергаются анализу.

В начале процесса проектирования системы, она рассматривается в виде чёрного ящика. Ход процесса проектирования и его результаты зависят не только от состава требований, но и выбранной модели процесса, опыта проектировщика.

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

Процесс проектирования может осуществляться как вручную, так и с использованием автоматизированных средств. Для разработки моделей информационных систем, отражающих характеристики программного обеспечения, используются различные нотации: блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы и макеты.

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

• Архитектура ПО;
• Устройство компонентов ПО;
• Пользовательские интерфейсы.

Как правило, процесс проектирования программных продуктов делится на два этапа:

• предварительное проектирование;
• детальное проектирование.

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

Рисунок 4. Информационные связи процесса проектирования.

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

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

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

1. Структурирование системы, в процессе которого система разделяется на ряд подсистем. Подсистемой называют независимый программный компонент. Затем определяют способы взаимодействия подсистем.
2. Моделирование управления, в процессе которого определяется модель связей управления между частями системы.
3. Декомпозиция подсистем на модули, в процессе которой выделенные подсистемы делятся на модули. Затем происходит определение типов модулей и межмодульных соединений.

В результате осуществления стадии структурирования системы получаются следующие виды моделей:

• модель хранилища данных;
• модель клиент-сервер;
• трехуровневая модель;
• модель абстрактной машины.

Модель хранилища данных, которая представлена на рисунке 5, разделяет данные подсистемы, которые находятся в общей памяти. Эти данные впоследствии образуют базу данных программного продукта. Поэтому в каждом программном продукте должна быть предусмотрена система управления базой данных.

Рисунок 5. Модель хранилища данных.

Клиент-серверная модель используется для проектирования распределенных систем, в которых компоненты системы распределены по серверам. Для передачи данных в клиент-серверных системах применяются сетевые протоколы, например, протокол TCP/IP. Структура клиент-серверной модели представлена на рисунке 6.

Рисунок 6. Клиент-серверная модель.

Развитием клиент-серверной модели является трехуровневая модель. Структура трехуровневой модели представлена на рисунке 7.

Рисунок 7. Трехуровневая модель.

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

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

1. Трехуровневая модель обладает следующими преимуществами:
2. Простота модификации уровней, которая не будет влиять на другие уровни модели.
3. Разграничение прикладных функций от функций управления базой данных приложения, что приводит к оптимизации работы всего приложения.

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

Рисунок 8. Модель абстрактной машины.

Модель является совокупностью следующих слоев:

• Операционная система;
• СУБД;
• Управление объектом;
• Управление версиями.

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

Рассмотрим модели управления. Выделяют следующие виды моделей управления:

• модель централизованного управления;
• модель событийного управления.

Модель централизованного управления одна подсистема выделяется в качестве системного контроллера. В задачи этой подсистемы входят руководство работой других подсистем. Модели централизованного управления делятся на два вида:

1. Модель вызов-возврат.
2. Модель менеджера, используемая в системах параллельной обработки.

Структура модели «Вызов-возврат» представлена на рисунке 9.

Рисунок 9. Структура модели «Вызов-возврат».

На рисунке 10 представлена структура модели менеджера.

Рисунок 10. Структура модели менеджера.

В модели событийного управления системой управление осуществляется внешними событиями. Существуют следующие виды моделей событийного управления:

• широковещательная модель;
• модель, управляемая прерываниями.

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

Рисунок 11. Структура широковещательной модели.

На рисунке 12 представлена структура модели, управляемой прерываниями. В этой модели все прерывания разбиваются на группы, которые в совокупности образуют вектор прерываний. Каждому типу прерывания соответствует конкретный обработчик. Каждый обработчик запускает конкретный процесс.

Рисунок 12. Структура модели, управляемой прерываниями.

Рассмотрим процесс декомпозиции подсистем на модули. Различают следующие модели модульной декомпозиции:

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

Выбор способа декомпозиции подсистемы на модули зависит от сложности разбиваемой подсистемы.

2. Этапы проектирования программного продукта

Процесс проектирования программных продуктов включает следующие этапы:

1. Эскизный проект системы.
2. Техническое проектирование.
3. Рабочий проект системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап технического проектирования включает в себя следующие стадии:

1. Разработку проектных решений по системе и ее частям.
2. Разработку документации на систему и ее части
3. Разработку и оформление документации на поставку изделий для комплектования системы или технических требований на их разработку.
4. Разработку заданий на проектирование в смежных частях проекта объекта автоматизации.

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

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

В состав комплекта документ, содержащих общесистемные проектные решения входят следующие документы:

• ведомость технического проекта;
• пояснительная записка к техническому проекту;
• описание автоматизируемых функций;
• ведомость покупных изделий;
• описание постановки задач (комплекса задач);
• локальный сметный расчет;
• проектная оценка надежности системы.

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

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

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

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

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

Процесс рабочего проектирования включает следующие этапы:

1. Разработку рабочей документации на систему и ее части.
2. Разработку или адаптацию программ.
3. Разработку программ и программных средств системы.
4. Выбор, адаптацию и привязку приобретаемых программных средств.
5. Разработку программной документации.

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

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

3. Применение объектно-ориентированного подхода к проектированию программных продуктов

3.1 Сущность объектно-ориентированного подхода

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

В объектно-ориентированном подходе к проектированию предметная область представляется в виде объектов, для которых дается описание связей. Для моделирования системы в объектно-ориентированном подходе используются язык UML.

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

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

Объектно-ориентированный поход к проектированию информационных систем включает следующие модели:

• Диаграмма классов;
• Диаграмма компонентов;
• Диаграмма композитной/составной структуры;
• Диаграмма развёртывания;
• Диаграмма объектов;
• Диаграмма пакетов;
• Диаграмма деятельности;
• Диаграмма автомата;
• Диаграмма сценариев использования;
• Диаграмма последовательности.

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

Рисунок 13. Пример диаграммы классов.

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

Рисунок 14. Пример диаграммы компонентов.

Диаграмма композитной — это статическая структурная диаграмма, демонстрирующая внутреннюю структуру классов и их взаимодействие. Одним из видов таких диаграмм являются диаграммы кооперации, представляющие роли и взаимодействие классов в рамках кооперации. Пример диаграммы кооперации представлен на рисунке 15.

Рисунок 15. Пример диаграммы кооперации.

Диаграмма развёртывания применяется в процессе моделирования работающих узлов и артефактов. Пример диаграммы развертывания представлен на рисунке 16.

Рисунок 16. Пример диаграммы развертывания.

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

Рисунок 17. Пример диаграммы объектов.

Диаграмма пакетов дает представление о пакетах и отношениях между ними. Диаграммы пакетов применяются для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы. Пример диаграммы пакетов представлен на рисунке 18.

Рисунок 18. Пример диаграммы пакетов.

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

Рисунок 19. Пример диаграммы деятельности.

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

Рисунок 20. Пример диаграммы состояний.

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

Рисунок 21. Пример диаграммы вариантов использования.

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

Рисунок 22. Диаграмма последовательности.

3.2 Программные продукты, применяемые при объектно-ориентированном подходе

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

1. Проектирование системы. Инструмент должен давать достаточный функционал для возможности документирования требований к системе. Также в нем должен присутствовать функционал для создания зависимости между объектами разных типов, возможность отслеживать изменения.
2. Экспорт. Программный продукт должен обладать функцией экспорта артефактов, которые в нём были созданы. Для экспорта должны быть доступны разные форматы.
3. Удобный интерфейс. Программное средство должно быть удобным, интуитивно понятным, с простым интерфейсом для часто используемых функций.
4. Автоматизация рутинных операций. Используемый инструмент должен позволять осуществлять генерацию программного кода, тест-кейсов, объектного дизайна и т.д.

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

1. Case Complete – это инструмент, предназначенный для записи требований, создания сценариев использования объектов и связей между ними. Инструмент обладает удобным интерфейсом, функцией экспорта. Но он содержит один серьёзный минус: в нем присутствует тограниченный набор диаграмм. Инструмент отвечает 2 выделенным критериям из 4.
2. Artiso Visual Case – инструмент обладает неудобным интерфейсом, однако поддерживает все виды диаграмм и обладает функциями экспорта. Инструмент отвечает 3 критериям из 4.
3. Инструмент Magic Draw обладает широким функционалом для UML, однако, в нем отсутствуют связи между разными объектами. Инструмент отвечает 3 критериям из 4.
4. Sparx Enterprise Architect отвечает практически всем выдвинутым критериям, однако его слабым местом является интерфейс. Ряд наиболее часто используемых функций отсутствуют на панели инструментов. Инструмент отвечает 3 критериям из 4.
5. Sybase PowerDesigner обладает простым и понятным интерфейсом, а также множеством полезных функций, которые не попали в список критериев (например, оценка изменения, проверка модели и т.д.). Инструмент отвечает 4 критериям из 4.
6. Анализ объектно-ориентированного подхода

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

• Избыточность языка. Язык UML подвергается критике из-за большого объема и сложности. Он содержит много избыточных или практически неиспользуемых диаграмм и конструкций.
• Неточная семантика. Поскольку UML определён абстрактным синтаксисом и языком описания ограничений, он лишен скованности, присущей языкам, точно определённым техниками формального описания. В некоторых случаях оба этих компонента противоречат друг другу, а в других случаях они являются неполными. Неточность описания языка UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
• Проблемы при изучении и внедрении. Описанные выше недостатки способствуют появлению проблем при изучении и внедрении языка UML.
• Язык UML особенно ценен в продуктах, которые осуществляют компиляцию модели для генерации исходного или выполнимого кода проекта. Однако, любой сгенерированный код является ограниченным потому, что в нем можно разглядеть или предположить интерпретирующий UML инструмент.
• Кумулятивная нагрузка/Рассогласование нагрузки. Язык UML может представить одни системы более кратко и эффективно, чем другие. Поэтому разработчики программного обеспечения склоняются к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования.
• Поскольку язык UML являются языком моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.

Несмотря на перечисленные недостатки, объектно-ориентированный подход обладает достоинствами, с которыми связано его широкое использование. Рассмотрим эти преимущества:

• Поскольку язык UML является объектно-ориентированным, используемые в нем методы описания результатов анализа и проектирования являются семантически близкими к методами программирования на современных объектно-ориентированных языках;
• Язык UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
• Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
• UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
• UML получил широкое распространение и динамично развивается.

Заключение

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

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

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

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

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

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

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

Список литературы

1. Беккер Й., Велкова Л. Менеджмент процессов. / Й. Беккер, Л. Велкова - М.: Эксмо, 2014. 384с.
2. Буч Г., Рамбо Дж. Язык UML. Руководство пользователя — М., СПб.: ДМК Пресс, Питер, 2014. 432 с.
3. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS / С. Орлов. — 2-е изд.. — СПб.: Питер, 2012. 736 с.
4. Венделева М.А. Информационные технологии управления: учебное пособие для бакалавров: по специальности «Менеджмент организации» / М.А. Венделева, Ю.В. Вертакова. - Москва : Юрайт, 2012. 462 с.
5. Киселев Г.М. Информационные технологии в экономике и управлении: учебное пособие для вузов / Г.М. Киселев, Р.В. Бочкова, В.И. Сафонов. - Москва : Дашков и К, 2012. 268 с.
6. Корнейчук Б.В. Информационная экономика: учеб. пособие / Б.В. Корнейчук. - Санкт-Петербург [и др.] : Питер, 2016. 394 с.
7. Ларман Кр. Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. — 3-е изд. — М.: Вильямс, 2016. 736 с.
8. Ловцев Д.А. Информационная теория эргасистем. / Д.А. Ловцев. М.: ВАРВСН, 2013. 124 с.
9. Меняев. М.Ф. Основы разработки программного обеспечения / М.Ф. Меняев. — М.: Омега-Л, 2015. 458 с.
10. Острейковский, В.А., Полякова, И.В. Информатика. Теория и практика / В.А. Острейковский, И.В. Полякова. — М.: Оникс, 2014. 608 с.
11. Попов, В.Л. Управление инновационными проектами: Учебное пособие / В.Л. Попов. - М.: Инфра-М, 2013. 336 с.
12. Пятков М.А. Экономика информационных технологий / М.А. Пятаков М.:Наука, 2012. 335 с.
13. Романова Ю.Д. Информатика и информационные технологии / Ю.Д. Романова. — М.: Эксмо, 2014. 592 с.
14. Румянцева, Е.Л., Слюсарь, В.В. Информационные технологии / Е.Л. Румянцева, В.В. Слюсарь. - М.: Инфра-М, 2007. 256 с.
15. Соболь Б.Ф. Информатика / Б.В. Соболь. - Ростов-на-Дону: Феникс, 2013. 446 с.
16. Степанов А.Н. Информатика/А.Н.Степанов. - СПб: Питер, 2016. 684 с.
17. Тронин Ю.Н.Информационные системы и технологии в бизнесе / Ю.Н. Тронин. - Москва : Альфа-Пресс, 2015. 236 с.
18. Хакен Г. Информация и самоорганизация / Г.Хакен. М.: Мир, 2013. 240 с.
19. Хубаева Г.Н. Информатика / Г.Н. Хубаева. - Ростов-на-Дону: МарТ, 2012. 288 с.
20. Шуремов, Е.Л., Чистов Д.В., Лямова Г.В. Информационные системы управления предприятиями / Е.Л. Шуремов, Д.В. Чистов, Г.В. Лямова. - М.: Изд-во «Бухгалтерский учет», 2012. 112 с.