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

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

Содержание:

Введение

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

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

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

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

1. Методология объектно-ориентированного проектирования.

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

Создание моделей предметной области происходит по принципам объектно-ориентированного анализа, с использованием семантики UML. Далее приведем определение объектно-ориентированного проектирования (ООАП), которое в дальнейшем поможет лучше разобраться в объектной методологии проектирования.

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

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

Методология объектно-ориентированного проектирования тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). CASE средства (Computer - Aided Software Engineering) – это программные инструменты и методы, которые позволяет автоматизировать процесс разработки информационной системы и программного обеспечения. CASE средства применяются при моделировании объектов информационной системы предприятия, определение взаимосвязи процессов и инфраструктуры. Основной задачей является сокращение времени на разработку информационной системы и повышение ее качества.[^[2]]

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

Главная проблема ранних CASE средств заключалась в графической нотации, потому что на тот момент не было придумано языка моделирования и визуализации элементов БД, а многие существующие языки со строгим синтаксисом не подходили для решения задач моделирования. Разработчикам требовался простой язык моделирования с понятным всем синтаксисом, даже сторонним людям, которые до этого не сталкивались с проектированием. Проблему решила разработка унифицированного языка моделирования (UML), первая версия которого вышла в 1997 году и сразу была объявлена промышленным стандартом.[^[3]]

Выделим основные принципы объектного подхода:

Инкапсуляция
Модульность
Абстрагирование
Иерархия
Наследование

Инкапсуляция – это разделение объекта на его составные части, позволяющее скрыть детали реализации системы от пользователя. В качестве примера можно привести автоматизированную систему магазина с подключенной к ней базой данных SQL Server. Пользователь через интерфейс вводит название нового товара и с помощью обычного нажатия кнопки наименование товара заносится в базу данных, то есть весь скрипт по внесению новой строчки в БД скрыт от глаз пользователя. Это сделано и с точки зрения безопасности, чтобы пользователи случайным образом не внесли изменения в код.

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

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

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

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

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

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

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

2. Основные составляющие объектно-ориентированного подхода

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

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

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

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

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

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

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

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

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

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

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

Неотъемлемой частью Унифицированного процесса является UML – язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно-ориентированного подхода. Язык UML принят стандартным языком моделирования, мировой организацией по стандартизации. UML включен разработчиками компьютерного ПО практически во все самые известные системы (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase), так же ни одно популярное CASE средство не обходится без использования унифицированного языка моделирования (Rational Rose, Visio, Silverrun, Vantage Team Builder, S-Designor). В UML определено три типа сущностей:

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

Отметим, что модель унифицированного процесса была создана в 1987 Иваром Джекобсоном, создавшим для этого собственную компанию Objectory AB. Разработка Джекобсона была интегрирована с развивавшимся параллельно унифицированным языком моделирования.[^[6]]

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

3. Унифицированный язык моделирования (UML)

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

Язык UML является основным инструментом моделирования процессов и визуализации структуры базы данных. Этот язык содержит множество инструментов, которые могут быть использованы для построения логических и концептуальных систем, он составлен с использованием многолетнего опыта программной инженерии, который оттачивался при разработки больших систем.[^[7]]

Словарь UML включает три вида строительных блоков:

Сущности;
Диаграммы;
Связи.

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

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

История унифицированного языка моделирования.

Во второй половине XX века с развитием объектно-ориентированных языков программирования (Simula 67, Smalltalk, Objective C, C++) возникла потребность в универсальном языке моделирования UML. Вследствие непрекращающегося усложнения создаваемых программных продуктов возникла нужда в учёте всё новых и новых возможностей языков и средств разработки при анализе, формулировании требований и в процессе проектирования программных приложений. Например, в короткий промежуток времени с 1989 года по 1994 год, количество объектно-ориентированных инструментов выросло с десятка до более, чем полусотни. Однако, многие разработчики затруднялись подобрать язык моделирования, который бы полностью отвечал всем их потребностям. В результате выделилось новое поколение методов разработки, среди, которого особую популярность приобрел метод Бутча, созданный Якобсоном Object-Oriented Software Engineering (OOSE) и разработанный Рамбо (Object Modeling Technique (OMT). Помимо них существовали и другие завершённые технологии, например Fusion, Shlaer-Mellor и Coad-Yourdon, однако всем из них были присущи не только преимущества, но и существенные недостатки. [^[8]]

До UML 1.x.

В 1994 году Гради Бутч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования Object-Modeling Technique и Booch. OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Ивар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.

На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон («три амиго»), выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года. [^[9]]

UML 1.x

На волне растущей популярности языка моделирования UML к разработке новых версий присоединились такие гиганты в сфере IT, как HP, IBM и ICON Computing . В результате была разработана версия UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.

Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно, в июне 1999, сентябре 2001 и марте 2003 года. [^[10]]

UML 2.x.

Версия UML 2.х является самым распространенным на данный момент способом моделирования информационных систем. UML2.0 - это первая основная версия стандарта UML, за которой последовала серия младших редакций [OMG04] [RJB05]. Зачем нужно было пересматривать UML?

Основной мотивацией для пересмотра языка было желание обеспечить лучшую поддержку MDD-средств и методов. За последнее десятилетие ряд производителей разработали основанные на UML инструментальные средства, которые поддерживали значительно более высокий уровень автоматизации, чем традиционные CASE-средства (computer-aided software engineering).

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

Значительно увеличена степень точности в определении языка:
Улучшена организация языка: Это характеризуется модульностью, которая не только делает язык более доступным для новых пользователей, но и содействует совместной работе инструментальных средств.
Значительно улучшена способность моделирования широкомасштабных программных систем: Некоторые современные приложения представляют собой интеграцию существующих автономных приложений в более сбалансированные системы. Эта тенденция вероятно будет продолжаться, что приведет к появлению еще более сложных систем.
Улучшена поддержка зависимой от домена (domain-specific) специализации:
Общая консолидация, рационализация и прояснение различных концепций моделирования: Это привело к упрощению и более согласованному языку. Сюда входит консолидация и, в некоторых случаях, удаление избыточных концепций, уточнение многочисленных определений и добавление текстовых пояснений и примеров.[^[11]]

Диаграммы.

Основные виды диаграмм, использующиеся в UML:

Статические диаграммы:

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

Самыми распространенными видами связей между классами являются: ссылки, связи по композиции, связи по наследованию. Наследование классов изображается стрелкой с пустым наконечником, идущей от наследника к предку. Реализация интерфейсов изображается пунктирной стрелкой с пустым наконечником, ведущей от класса к реализуемому им интерфейсу. Диаграмма компонентов – полностью статическая диаграмма, изображает разбиение системы на структурные компоненты, а так же связи между ними. Компоненты изображаются с помощью прямоугольников с небольшими вставками с левой стороны. Связи между компонентами рисуются пунктирными стрелками, один компонент зависит от другого, если не может быть использован без него в системе.[^[13]]

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

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

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

Динамические диаграммы:

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

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

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

В UML представлены 8 видов диаграмм и диаграмма вариантов использования, о которой будет рассказано в отдельной главе. Такого количества диаграмм вполне достаточно для подробной визуализации предметной области, многие используют лишь несколько диаграмм из общего количества. Для полной визуализации, даже обширной предметной области, вполне достаточно диаграммы классов, диаграммы действий и диаграммы последовательности. В целом язык UML оказался чрезвычайно полезной разработкой, позволяющей детализировать объект проектирования и предусмотреть особенности будущей системы, избежать ошибки на стадии проектирования. Для подведения итогов данной главы перечислим основные преимущества, которые привнес UML в процесс проектирования.[^[15]]

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

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

4. Диаграмма вариантов использования (use case)

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

Длительное время с момента создания унифицированного языка моделирования, у разработчиков не было единого механизма планирования проекта. Все разработки шли хаотично, операции моделирования не имели четкой систематизации. Первым кто ввел понятие варианты использования (use case) был Ивар Якобсон, в 1994 году этот шведский ученый стал основоположником появления унифицированного процесса и разработал концепцию проектирования и наглядного представления вариантов использования системы.[^[16]]

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

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

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

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

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

В дополнение к связям между действующими лицами и вариантами использования существуют два других типа связей: «использование» (uses) и "расширение" (extends) между вариантами использования. Связь типа "расширение" применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку

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

• связь "расширение" следует применять при описании изменений в нормальном поведении системы;

• связь "использование" следует применять для избежания повторов в двух (или более) вариантах использования. Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.[^[18]]

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

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

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

Microsoft Visio

Пожалуй, самым распространенным графическим редактором является Visio, разработанный, компанией Microsoft. Этот продукт позволяет создавать различные виды диаграмм, в том числе UML. Выпускается в трех версиях: Standard, Professional и Pro. Отличие версии Professional в большем количестве моделей диаграмм и возможностей по их представлению. В редакторе Visio применяется векторная графика, следовательно можно масштабировать изображения без потери качества. Возможности этого редактора основаны на графическом представлении моделей, но у него имеются дополнительные функции, которые присущи CASE средствам, такие как: наличие графического интерфейса, гибкость применения, построение прототипов системы, построение отчетов.

К основным функциям Microsoft Visio относятся:

Графическое оформление схем, которое позволяется менять эффекты фигур, изменять конструкцию фигур, сохраняя макеты схем.
Совместная работа над схемами. С помощью браузера настраивается совместная работа над проектами, а при установке службы SharePoint Server пользователи имеют возможность оставлять сообщения и редактировать схемы кооперативно.
Взаимосвязь схем с наборами данных. Это означает, что каждый класс можно связать с данными из Excel, SharePoint Business и SQL Server.
Пользовательские шаблоны проектов. Позволяют добавлять собственные шаблоны и использовать готовые, которые разбиты по категориям. Каждая структура относится к определенной группе процессов и диаграмм UML, среди шаблонов наиболее популярны: схема модели UML, блок-схема, бизнес, сеть, расписания. В каждом шаблоне содержатся фигуры, относящиеся к выбранной пользователем области проектирования.

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

Легкость и быстрота создания схем. Visio обладает простым и интуитивно понятным интерфейсом, поэтому для разработки не требуются специальные навыки.
Наличие шаблонов и образцов диаграмм. В программе встроено огромное количество образцов диаграмм, что ускоряет поиск фигуры для того или иного бизнес процесса.
Поддержка стандартных методологий. Microsoft Visio поддерживает самые распространенные нотации по проектированию ИС, такие как eEPC, IDEF0, IDEF3, UML. Для некоторых из них Visio позволяет осуществлять контроль правильности создания схем процессов.[^[19]]

IBM Rational Rose

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

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

Виды аспектов:

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

Возможности Rational Rose:

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

Microsoft Visual Studio.

Структурная визуализация. Позволяет представить модели и процессы в виде структурной иерархической схемы, отражающей их роли и взаимосвязи в системе.[^[20]]

Преимущества Rational Rose

Главным преимуществом является применение объектно-ориентированного принципа моделирования, удобство обращения с языком UML и построения диаграмм.

Список преимуществ CASE средства от IBM:

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

Rational Rose и по сей день остается одним из самых популярных средств моделирования, он подходит, как для описания бизнес-процессов, так и для работы с множеством языков программирования, среди которых: Delphi, ErWin, Jbuilder, VisualCafe, Jdeveloper, VisualAge и др. Чрезвычайно полезной функцией является – обратное проектирование, когда с помощью исходного кода, восстанавливается диаграмма классов, позволяющая понять структуру объекта моделирования. Функция обратного проектирования позволяет доработать существующую систему и впоследствии создать ее с новым кодом, в зависимости от выбранного языка. Подводя итог, можно сказать, что IBM Rational Rose является стандартом в UML проектировании, с достаточно неудобным интерфейсом в сравнении с тем же Microsoft Visio, но имеющим более полный набор функций и свойств диаграмм. [^[21]]

StarUML

StarUML – программный инструмент моделирования, который ориентирован на работу с методологией UML и основывается на модельно - управляемой архитектуре. Под модельно управляемой архитектурой подразумевается вид разработки информационной системы, при котором сначала создается модель предметной области, а затем на ее основе осуществляется реализация в какой-либо среде разработки. Программа StarUML превосходно настраивается в зависимости от требований пользователя и имеет высокую степень расширяемости, позволяя добавлять в среду разработки новые модули и диаграммы, которых нет по умолчанию. Пользователи могут изменять параметры среды разработки, которые в вою очередь влияют на методологию разработки, проектную платформу и язык программирования, с помощью которого выполнена система. Среда разработки StarUML поддерживает нотации UML 1.4 и UML 2.0, позволяя создавать мультиплатформенные модели. Дизайн у этой программы своей простотой больше напоминает, обсуждаемый ранее Rational Rose. Окно рабочей области выполнено в очень сдержанных тонах, желто-зеленоватого оттенка, справа окно свойств, в центре рабочая область, а в левой части выбор классов и элементов. Важным элементом является панель ошибок, находящаяся в нижней части окна, именуемая “output”, она выдает сообщения о правильности составления моделей. Теперь коротко перечислим главные особенности StarUML:

Открытый формат программных файлов. При работе с проектом пользователям часто необходимо работать с файлами на разных устройствах, в том числе на тех, где не установлена программа моделирования. Для таких ситуаций в StarUML принят мировой стандарт файлов – XML. Коды проекта могут быть легко открыты в любом XML редакторе.
Поддержка Модульно управляемой архитектуры. Согласно принципам MDA для разработки приложения, сначала должна быть построена точная модель предметной области и на ее основе может быть автоматически сгенерирован код проекта.
Большой выбор методологий и платформ. StarUML применим ко всем методологиям и процессам, таким как .NET или J2EE.
Расширяемость. Для StarUML могут быть разработаны дополнения и программные модули на множестве языков, относящихся к Microsoft COM (Visual Basic Script, Java Script, VB, Delphi, C++, C#, VB.NET, Python).
Проверка модулей. Невозможно уследить за всеми ошибками, возникающими на протяжении моделирования, на помощь приходит, окно проверки на ошибки. Оно выводит сообщения о правильности конструирования той или иной схемы. [^[22]]

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

Помимо вышеописанных программ моделирования следует обратить внимание на инструментарий под названием Sybase PowerDesigner, который многие специалисты называют одним из лучших средств UML проектирования. Sybase PowerDesigner имеет лишь один существенный недостаток - это отсутствие кроссплатформенности, программа работает только под Windows. В остальном никаких нареканий PowerDesigner поддерживает большое количество языков программирования: С#, C++ (только генерация кода), Java, PowerBuilder, VisualBasic. Обеспечивает поддержку форматов XML и IDL.

Плюсы Sybase PowerDesigner:

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

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

6. Пример использования объектно-ориентированного подхода

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

1 Анализ состояния и моделирование деятельности объекта.

1.1 Общие сведения о театре занятости актеров, системах, использующихся для ее учета.

Назначения интерфейса

·Ввод и редактирование информации о актерах и постановках, в которых они задействованы;

·поиск и отображение необходимой информации;

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

Описание предметной области

Интерфейс для администратора театра

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

О деятельности театра

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

Ограничения предметной области

Актеры театра могут получать зарплату не выше 500.000
Один актер участвует не более чем в 2 спектаклях
Театр имеет в своем репертуаре не более 10 спектаклей для показа
В один день проводится не более одного спектакля
Спектакли могут проводиться не более чем на 5 театральных сценах

БД

Таблицы: Актеры (Код актера, Фамилия, Имя, Отчество, Театр, Спектакль). Спектакли (Код спектакля, Название, Место проведения, Время, Актеры). Занятость актеров в спектакле (Код актера, Код спектакля, Роль, Стоимость годового контракта).

Для наглядного примера использования UML по теме «Занятость актеров театра» были разработаны диаграммы, которые представлены в разделе приложения.

Заключение

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

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

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

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

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

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

Список использованных источников

1. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения.

2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.

3. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.

4. ХАБР/ ООП с примерами/ URL: https://habr.com/ru/post/87205/

5. SYL/ UML-диаграмма. Виды диаграмм UML /URL: https://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml

6. Prog-cpp.ru/ Алгоритмизация / URL: UML-диаграммы классов/ https://prog-cpp.ru/uml-classes/

7. Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2014. – 233 с.

8. Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2015. - 582 с.

9. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М. : Бином, 2014. – 560 с.

10. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с.

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

12. Крачтен, Ф. Введение в Rational Unified Process / Ф. Кратчен. - М.: Издательский дом «Вильямс», 2016. - 240 с.

13. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2014. - 496 с.

14. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2014. – 576с.

15. Орлов, С.А. Технологии разработки программного обеспечения: учеб. / С.А. Орлов. – СПб. : Питер, 2014. – 464 с.

16. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2013. – 688 с.

17. Проектирование информационных систем/ Лекции / URL: https://www.sites.google.com/site/anisimovkhv/learning/pris/lecture/tema9

18. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с.

19. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с.

20. Леоненков, А.В. Визуальное моделирование в среде IBM Rational Rose. – www.intuit.ru.

21. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru

22. ИНТУИТ/ Введение в UML 2.0 / URL: https://www.intuit.ru/studies/courses/1041/218/lecture/27261

23. Автоматизация СМК\ Моделирование бизнес процессов\ CASE средства\ Rational Rose https://www.kpms.ru/Automatization/Rational_Rose.htm

Приложения

Приложение 1

Рисунок 1 - организационная диаграмма

Организационная диаграмма - метод изображения взаимосвязей между группой лиц, совместно работающих для достижения общей цели.

Приложение 2

Рисунок 2 - диаграмма прецедентов

Диаграмма прецедентов — диаграмма, отражающая отношения между актёрами и прецедентами

Приложение 3

Рисунок 3 - диаграмма классов

Диаграмма классов — диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними.

Приложение 4

Рисунок 4 - диаграмма последовательностей

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

Приложение 5

Рисунок 5 - диаграмма активностей

Диаграмма активностей - диаграмма, на которой показано разложение некоторой деятельности на её составные части.

Приложение 6

Рисунок 6 – Диаграмма компонентов

Приложение 7

Рисунок 7 – Диаграмма развертывания

Приложение 8

Рисунок 8 – Диаграмма вариантов использования

Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru ↑
ГОСТ 34.003-90. Автоматизированные системы. Термины и определения. ↑
Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2014. – 233 с. ↑
https://habr.com/ru/post/87205/ ↑
Проектирование информационных систем/ Лекции / URL: https://www.sites.google.com/site/anisimovkhv/learning/pris/lecture/tema9 ↑
. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с. ↑
Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2014. - 496 с. ↑
Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2014. – 576с. ↑
Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с. ↑
Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2013. – 688 с. ↑
Введение в UML 2.0 / URL: https://www.intuit.ru/studies/courses/1041/218/lecture/27261 ↑
Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с. ↑
Орлов, С.А. Технологии разработки программного обеспечения: учеб. / С.А. Орлов. – СПб. : Питер, 2014. – 464 с. ↑
https://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml ↑
Prog-cpp.ru/ Алгоритмизация / UML-диаграммы классов/ https://prog-cpp.ru/uml-classes/ ↑
ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. ↑
ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств. ↑
Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М. : Бином, 2014. – 560 с. ↑
Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2015. - 582 с. ↑
https://www.kpms.ru/Automatization/Rational_Rose.htm ↑
Крачтен, Ф. Введение в Rational Unified Process / Ф. Кратчен. - М.: Издательский дом «Вильямс», 2016. - 240 с. ↑
Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 2015. – 176 с. ↑
Леоненков, А.В. Визуальное моделирование в среде IBM Rational Rose. – www.intuit.ru ↑