Введение 

Глава 1. Основные технологии проектирования информационных систем 

1.1 Основные понятия и определения 

1.2 Основы моделирования информационных систем 

1.3 Модели жизненного цикла 

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

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

2.2 Программные средства реализации объектно-ориентированного подхода 20

Заключение 

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

Приложение 1. Алгоритм объектной декомпозиции 

Приложение 2. Развернутый алгоритм объектной декомпозиции 

Введение

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

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

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

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

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

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

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

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

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

Глава 1. Основные технологии проектирования информационных систем

1.1 Основные понятия и определения

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

В соответствии с Федеральным законом № 149-ФЗ (в редакции от 06.07.2016) «Об информации, информационных технологиях и о защите информации» под термином информация понимается «сведения (сообщения, данные) независимо от формы их представления» [17].

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

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

Таким образом, термины «информация» и «информационная система» дополняют друг друга – ИС создается чтобы обрабатывать информацию, а информация служит в качестве обрабатываемого «материала», используемого в процессе функционирования ИС.

Активное развитие информационных технологий началось в середине прошлого века, когда передовые предприятия и военные ведомства, установили, что необходимость внедрения и развития информационных систем это не столько временная потребность, сколько будущее. Наиболее серьезное значение для развития информационной области оказало совершенствование средств вычислительной техники. Развитие технической базы позволило увеличить скорость решения сложных задач, автоматизировать многие рутинные операции и, создало возможность для создания крупных информационных систем, способных обеспечить одновременную работу множества пользователей. Но потребность в создании таких систем породило необходимость создания специальных средств проектирования и моделирования бизнес-процессов, позволяющих сократить сроки создания информационных систем, при этом минимизируя возникающие ошибки. Стоит отметить, что возникновение ошибок в проектируемых информационных системах возникают постоянно, а потому, чем раньше они будут обнаружены, тем дешевле будет их устранение. Как показывает статистика, устранить ошибку, обнаруженную на стадии проектирования, будет стоить в 2 раза дороже, чем на стадии анализа бизнес-процессов и составления технического задания (ТЗ). Если ошибка будет обнаружена на стадии тестирования, то устранить ее будет стоить в 10 раз дороже, а если ошибка будет обнаружена уже на стадии эксплуатации, то стоить устранения возрастает в 100 раз [3].

Одной из причин ошибок может стать недопонимание, между аналитиком и персоналом заказчика. Полученные требования могут быть некорректно сформулированы, а также измениться, при формализации конкретных бизнес-процессов. Это и послужило основной причиной появления современных методологий проектирования и моделирования информационных систем. Разработка методологий проектирования ИС за всю свою историю прошла множество этапов, было создано несколько десятков методов моделирования сложных ИС, каждый из которых обладал своими достоинствами и недостатками. Несмотря на множество своих различий, они имели схожие подходы к проектированию ИС. В конечном итоге это привело к необходимости выработки единой методологии, которая бы удовлетворяла потребности многих разработчиков ИС. В результате появился унифицированный язык моделирования UML (Unified Modeling Language), ведущие роли в разработке которого сыграли Гради Буч, Айвар Джекобсон и Джеймс Рамбо, работающие в компании Rational Software. Ими же были разработаны основные методы объектного моделирования ИС [2]:

1. Метод объектного моделирования программного обеспечения сложных информационных систем (метод Буча);
2. Метод анализа требований к бизнес-приложениям (метод Джекобсона);
3. Метод анализа обработки данных в сложных информационных системах (метод Рамбо).

Разработанные ими методы и легли в основу первой версии UML 0.9, выпущенной в июне 1996 года. С момента выпуска языка UML, он перерос с простой системы моделирования бизнес-процессов до уровня международного стандарта. Так, версия языка UML 2.4.1 была принята и оформлена в качестве международных стандартов ISO/IEC 19505-1 и ISO/IEC 19505-2.

1.2 Основы моделирования информационных систем

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

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

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

Фактически процесс проектирования ПО и ИС не является однородным и, как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса (process model).

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

Перед тем, как непосредственно переходить к рассмотрению моделей проектирования ИС и ПО, необходимо рассмотреть такие понятия, как – фаза и вид деятельности.

Фаза (phase) – это определенный этап процесса, имеющий начало, конец и выходной результат [14]. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы.

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

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

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

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

1.3 Модели жизненного цикла

Перед тем как рассматривать модели процесса разработки ПО или модели его жизненного цикла, ему необходимо дать четкое определение, которое определено в международном стандарте IEEE [14]:

Жизненный цикл (ЖЦ) программного обеспечения— период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

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

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

При рассмотрении вопросов, касающихся моделей ЖЦ ПО, необходимо руководствоваться единым стандартом, в качестве которого выступает ГОСТ Р ИСО/МЭК 12207-2010. В нем неопределенны четкие отношения к какой-то конкретной модели ЖЦ, но содержаться общие требования для любых моделей ЖЦ, методов и технологий создания ИС. В рамках данного документа описывается структура процессов ЖЦ, но нет конкретики к выбору способа реализации действий или выполнения задач, которые входят в состав конкретного процесса ЖЦ [18].

Любая модель ЖЦ ПО, в общем случае состоит из:

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

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

1) Водопадная модель жизненного цикла

Водопадная модель жизненного цикла (англ. waterfall model) была предложена Уинстоном Ройсом в 70 гг. 20 века. В рамках данной модели, предполагается выполнение всех этапов проекта строго заданном порядке, причем этот порядок не допускает изменений. Переход к следующему этапу может быть осуществлен только после завершения работ в рамках текущего этапа. Схематически данная модель представлена на рисунке 1.1.

Рисунок 1.1 – Водопадная модель ЖЦ ПО

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

Преимущества:

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

Недостатки:

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

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

2) Итерационная модель

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

Рисунок 1.2 – Итерационная модель ЖЦ

Основной недостаток итерационной модели заключается в том, что целостное пониманием возможностей и ограничений разрабатываемого проекта отсутствует долгое время, т.к. любые проблемы приводят к откату, даже если проблемы связаны с ограничениями, заданными в рамках определения требований. Еще один недостаток, которая присуща проектам, реализуемым по данной модели – добросовестность разработчиков, которая является следствием того, что разработчик не может быть уверен в качестве принятых решений, потому что всегда есть возможность «откатиться и сделать лучше» [10].

3) Спиральная модель

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

Рисунок 1.3 – Спиральная модель ЖЦ ПО

Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. Каждая выполняемая итерация позволяет оценить [10]:

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

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

К числу преимуществ спиральной модели можно отнести:

• быстрое получение результата;
• повышение конкурентоспособности;
• изменение требований не вызывает серьезных проблем.

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

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

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

Объектно-ориентированный подход проектирования информационных систем предполагает декомпозицию этой ИС. При этом декомпозиции подвергаются объекты, обладающие определенной структурой данных, именно от этих данных и идет декомпозиция. При объектно-ориентированном подходе выделяют классы объектов, каждый из которых содержит в себе только однородные объекты. Объекты, относящиеся к одному классу, имеют равное множество методов реагирования на внешние сообщения. Таким образом, иерархическая декомпозиция системы представляется в виде иерархии классов объектов, а функционирование системы в виде их взаимодействия, путем обмена сообщениями [7]. Пример алгоритма объектной декомпозиции представлен в приложении 1, а в приложении 2 представлена его развернутая блок-схема.

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

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

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

Другое достоинство объектно-ориентированного подхода заключается в возможности упростить накопление типовых проектных решений с тем, с возможностью их использования при разработке новых ИС, которые будут создаваться не с нуля, а из готовых компонент. Объясняется эта особенность тем, что отдельные классы объектов в некоторой мере повторяются при переходе от одной ИС к другой, по этой причине нет смысла создавать новый программный код – для повторяющихся классов уже созданы методы, разработаны и описаны структуры объектов данных [15].

Для лучшего понимания модели объектно-ориентированного подхода к проектированию ИС, представим ее графически на рисунке 2.1.

Рисунок 2.1 – Модель проектирования ИС на основе объектно-ориентированного подхода

Итак, на представленном рисунке мы видим 4 основных этапа проектирования ИС, реализуемых в рамках модели объектно-ориентированного подхода:

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

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

Таким образом, мы может выделить основные преимущества объектно-ориентированного подхода к проектированию ИС, к ним относятся:

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

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

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

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

Рисунок 2.2 – Зависимость эффективности применения функционально-ориентированного и объектно-ориентированного подходов от количества выполненных проектов

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

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

При проектировании информационных систем не маловажное значение имеет среда разработки конечной модели, от ее выбора во многом зависит качество проекта разрабатываемой системы. По этой причине необходим обоснованный выбор инструментальных средств проектирования, которые позволяют реализовать объектно-ориентированный подход. В качестве таких средств выступают CASE-технологии (Computer-Aided Software/System Engineering). Они представляют собой набор инструментов и методов программной инженерии для проектирования программных продуктов. Использование CASE-средств позволяет значительно снизить количество ошибок, увеличить качество программ и обеспечить простоту в их обслуживании. Такой подход зачастую называют CASE-технологией проектирования [8].

CASE-технология проектирования является актуальным и интенсивно развивающимся направлением создания САПР в области проектирования программных продуктов и информационных систем. Сегодня практически все крупные информационные системы используются с использованием CASE-средств.

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

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

1) IBM Rational Rose

Rational Rose – современное и мощное средство анализа, моделирования и разработки программных систем, занимает лидирующую позицию на рынке средств визуального моделирования [16]. Программа настолько универсальна, что подойдет для любых задач в области проектирования программных систем – от анализа бизнес-процессов, до генерации кода на заданном языке программирования. Подобный функционал используется не только для создания новых систем, но и для доработки ранее созданных. Rational Rose достаточно проста в использовании и является полностью интегрированным решением, что позволяет использовать ее для разработки программных продуктов и интернет-решений, с одинаковой эффективностью. Графический интерфейс системы представлен на рисунке 2.3.

Рисунок 2.3 – Интерфейс IBM Rational Rose

Для наиболее полного покрытия потребностей пользователей, Rational Rose выпускается в нескольких реализациях: Rational Rose Modeler, Rational Rose DataModeler, Rational Rose Enterprise и т.д. Все поставляемые при этом решения являются платными, за исключением версий для учебных заведений. Конкретная реализация определяет набор визуальных компонент (возможных диаграмм). Но даже базовая версия Rational Rose и так достаточно функциональна. Вот основные возможности продукта:

• возможность прямого и обратного проектирования на языках: ADA, Basic, Java, С, C++;
• поддержка технологий DDL, COM, XML;
• возможность генерации схем баз данных Oracle и SQL;
• возможность самостоятельного создания модулей для других языков программирования, за счет открытого API.

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

Таким образом, рассмотренный программный продукт – это функциональное, точнее «сверх» функциональное CASE-средство, позволяющее создавать UML-диаграммы программных систем в рамках объектно-ориентированного подхода к проектированию.

2) Microsoft Visio

Данный программный продукт – это решение для построения UML-диаграмм от корпорации Microsoft. По заявлению разработчиков возможности Visio позволяют преобразовать технические и бизнес-концепции в визуальную форму. Действительно, данное средство позволяет создавать только диаграммы (схемы, планы помещений и прочее мы не рассматриваем). По большей части это только лишь средство для визуализации, не позволяющее генерировать программный код. Хотя возможности Visio и не дотягивают до уровня пакетов, рассмотренного выше, но его изобразительные возможности весьма широки [16]:

• быстрое создание простых и понятных информативных диаграмм за счет использования предопределенных фигур Visio Professional, drag-and-drop подхода и мастера построения;
• расширение функционала, за счет импорта новых шаблонов бизне-диаграмм из внешних источников;
• простота создания диаграммы сетевых ресурсов, позволяющих иллюстрировать развертывание нового ПО на сетевые ресурсы.
• возможность импорта данных и задач из файлов Microsoft Office Project, что означает, что процесс создания UML-диаграмм может быть интегрирован в план-график создания информационной системы;
• шаблоны UML позволяют создавать UML-диаграммы статической структуры ПО, а также производить обратное проектирование с использование Visio Reverse Engineer Wizard;
• наличие инструментов для документирования процесса проектирования (создание отчетов, описательных файлов, комментариев и т.д.), за счет поддержки интеграции с продуктами MS Office.

Визуальный интерфейс Visio схож с интерфейсом прочих продуктов Microsoft и представлен на рисунке 2.4.

Рисунок 2.4 – Интерфейс MS Visio 2013

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

В сравнении с более узкоспециализированными программными продуктами, MS Visio уступает другим CASE-средствам для проектирования программных продуктов, но его использовать стоит хотя бы потому, что в нем имеются такие возможности, как:

• наличие инструментов для «мозгового штурма», генерации и структурирования идей;
• поддержка множества языков локализаций;
• наличие средств рецензирования и комментирования проектов, которые могут отслеживать все участники проектной команды;
• наличие средств создания документации, в том числе поддержка ISO 9000-документации.

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

3) StarUML

StarUML – это пакет с открытым программным кодом, написанный на Delphi и работающий под управлением ОС семейства Windows. Основная отличительная возможность – это совершенно бесплатное распространение [1]. В базовом варианте, StarUML поддерживает UML 2.0 (плюс его профайлы) и MDA (Model Driven Architecture). При этом его функционал может быть расширен, за счет применения дополнительных плагинов, благодаря чему, каждый пользователь может создать свой собственный модуль для StarUML на любом COM-совместимом языке (C++, Delphi, C#, ...).

Еще одна отличительная черта пакета – его юзабилити. Во многом его интерфейс схож с интерфейсом MS Visual Studio. Визуально интерфейс рассматриваемого пакета представлен на рисунке 2.5.

Рисунок 2.5 – Пример интерфейса StarUML

Как можно видеть, реализация интерфейса StarUML, имеет поддержку библиотеки предопределенных фигур, метода drag-and-drop для перетаскивания фигур с панели инструментов на рабочую область.

Среди функциональных особенностей StarUML можно выделить наличие кодогенерации – без использования дополнительных расширений StarUML может генерировать программный код для C++, C# и Java, а при установке дополнительных шаблонов может быть обеспечена поддержка других языков. Также в составе StarUML имеются инструменты для создания документации в виде текстовых файлов MS Word, файлов табличного процессора MS Excel и презентаций MS PowerPoint [16].

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

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

Заключение

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

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

Для достижения поставленной цели, в работе решены следующие задачи:

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

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

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

1. Аветисов, M.А. Электронная доставка документов - создание архива сканированных материалов с поисковым аппаратом // Науч. и техн. Б-ки. – 2012. - № 3. - с. 7-11.
2. Ауэр К., Миллер Р. Экстремальное программирование: постановка процесса с первых шагов и до победного конца. СпБ.: Питер, 2013. - 715 с.
3. Афанасьев А.А. Аутентификация. Теория и практика обеспечения безопасного доступа к информационным ресурсам. – М.: Горячая Линия – Телеком, 2012. – 550с.
4. Басовский Е.Л., Протасьев В.Б. Управление качеством. – М.: «Инфра», 2013. – 214 с.
5. Брагин Ю.В., Корольков В.Ф. Путь QFD. Проектирование и производство продукции исходя из ожиданий потребителя. М.: Азбука, 2013. - 240с.
6. Ехлаков Ю.П. Вывод прикладного программного обеспечения на рынок корпоративных продаж // «Маркетинг в России и за рубежом» - 2014. -№4. с. 20-23
7. Коберн А. Современные методы описания функциональных требований к информационным системам. – М.: Лори, 2013. - 510 с.
8. Куликов Г.Г. Набатов А.Н. Речкалов А.В. Автоматизированное проектирование информационно-управляющих систем. – Уфа: Уфимский государственный авиационный технический университет, 2015. – 104 с.
9. Леффингуелл Д., Уидриг Д. Требования к разработке программного обеспечения. – М.: Вильямс, 2012. - 414 с.
10. Липаев, В.В. Программная инженерия. Методологические основы. – М.: ТЕИС, 2015. – 608 с.
11. Лифиц И.М. Основы стандартизации метрологии и сертификации. Учебник. – М.: «Юрайт», 2013. – 288 с.
12. Мон К. Scrum: гибкая разработка ПО. – М.:«Вильямс», 2016. – 576 с.
13. Одинцов И. О. Профессиональное программирование. Системный подход. – СПб.: БХВ-Петербург, 2015. – 624 с.
14. Орлик С. «Основы программной инженерии» на базе IEEE Guide to SWEBOK [Электронный ресурс] – Режим доступа: http://swebok.sorlik.ru
15. Прикладное программное обеспечение [Электронный ресурс] – Режим доступа: https://ru.wikipedia.org/wiki/Прикладное_программное_обеспечение
16. Сравнение средств проектирования [Электронный ресурс] – Режим доступа: https://habrahabr.ru/post/46648/
17. Федеральный закон от 27.07.2006 N 149-ФЗ (ред. от 06.07.2016) «Об информации, информационных технологиях и о защите информации»
18. Чейз Р.Б. Производственный и операционный менеджмент. М.: Издательское объединение «ЮНИТИ», 2004. – 410 с.

Приложение 1. Алгоритм объектной декомпозиции

Приложение 2. Развернутый алгоритм объектной декомпозиции