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

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

Содержание:

ВВЕДЕНИЕ

Рост спроса на программные системы в наше время является следствием того, что по мере удешевления, повышения надежности и увеличения объема производства компьютеров автоматизация труда человека с помощью компьютера становится все более выгодной. Из года в год возрастает сложность и разнообразие систем, получивших в международной научно-технической практике название систем, интенсивно использующих программное обеспечение (Software Intensive Systems, SIS). Для разработок SIS типичны крупномасштабные проекты: десятки или сотни разработчиков, месяцы или годы разработки, огромные денежные средства.

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

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

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

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

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

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

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

Предметом исследования является информационная система.

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

Задачи работы:

1. обзор основных понятий и концепций объектно-ориентированного подхода.

2. Анализ унифицированного процесса разработки информационных систем.

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

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

Данная тематика исследовалась в работах авторов: Баркера Р., Боггса У., Буча Г., Вендрова А.М.

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

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

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

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

Заключение работы содержит в себе выводы по всей выпускной квалификационной работе.

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

1.1 Декомпозиция информационных систем

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

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

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

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

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

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

Объектно-ориентированный подход, по сути своей, состоит из: объектов; классов; инкапсуляций; наследования и полиморфизма[1].

Так, объект — это предмет, осязаемая сущность или абстракция. Любой объект входит в группу однотипных объектов. Для группы характерны одинаковые свойства объектов:

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

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

Инкапсуляция — преднамеренное сокрытие сведений. При таком виде программировании ограничен доступ к атрибутам объектов, за исключением доступа посредством его методов. Внутренняя схема объекта будет сокрыта от внешних воздействий. Объект представляется автономным предметом, который органичен методами[2].

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

Инкапсуляция способна корректировать влияния на группы объектов без возможных сбоев системы.

Следующая составляющая – наследование — представляет собой механизм формирования классов новые классы, которые формируются, следуя принципу «от общего к частному». Наследование может позволить актуальным классам при сохранении все классы-предшественники, а также включить свои уникальные особенности[9, 201].

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

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

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

Так, любой объект будет реагировать на одно и то же сообщение неодинаково и непредсказуемо.

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

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

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

Объектное моделирование реализуется посредством унифицированного языка моделирования Unified Modeling Language (UML), который был разработан ведущими поставщиками ПО Object Management Group (OMG)[2].

UML, по большому счету, представляет собой стандарт для объектной методологии. Язык UML применяется организациями в условиях CASE-технологий, например: Rational Rose, Natural Engineering Workbench и т.д.

1.2 CASE-технологии в информационных системах

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

CASE — в общем виде представляет собой механизм, благодаря которому аналитики, разработчики и программисты могут разрабатывать и проектировать информационные системы, используя платформу вместо графических средств передачи данных и информации[7, 192].

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

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

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

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

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

Так, чем большее количество деятельности интегрируется в проектирование из кодирования, тем результативнее будет исход. При использовании CASE-технологий изменяются все этапы жизненного цикла программной системы, при этом наибольшие изменения касаются этапов анализа и проектирования[18, 201].

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

Появлению CASE способствовали:

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

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

3. широкое внедрение и постоянный рост производительности ПК, позволяющий эффективно использовать графические средства;

4. внедрение сетевых технологий, позволивших объединить усилия отдельных исполнителей в единый процесс проектирования путем использования разделяемой (общей) базы данных, содержащей необходимую информацию о проекте[18, 230].

Преимущества CASE по сравнению с традиционной технологией оригинального проектирования:

1. улучшение качества разрабатываемой ИС за счет средств автоматического контроля и генерации кода;

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

3. поддержание адаптивности и сопровождения ИС;

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

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

6. возможность коллективной разработки ИС в режиме реального времени.

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

Метод — процедура или техника создания описаний элементов ИС (например, потоков или структур данных)[1].

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

Инструментальные средства CASE— специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.

Ядром системы является база данных проекта — репозиторий. Репозиторий представляет собой специализированную базу данных, хранящую информацию о состоянии элементов проектируемой ИС и взаимосвязях между ними в каждый момент времени.

Репозиторий (репозитарий) — разделяемая (инструментальными средствами и системами) корпоративная база данных, содержащая информацию об объектах проектирования, надмножество словарей метаданных[3].

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

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

1. инициализация проекта, задание начальных параметров;

2. назначение и изменение прав доступа к элементам проекта;

3. отслеживание графика выполнения проекта.

Сервисы — утилиты по обслуживанию репозитория (архивация, восстановление, создание, удаление).

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

1. по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные и объектно-ориентированные;

2. по поддерживаемым графическим нотациям построения диаграмм;

3. по типу и архитектуре вычислительной техники;

4. по режиму коллективной разработки проекта;

5. по типу операционной системы, под управлением которой может работать CASE.

В настоящее время важное значение приобретают CASE-системы, ориентированные на проектирование и генерацию БД и пользовательских интерфейсов. Генерация интерфейсов с базами данных и возможность преобразования (конвертирования) между различными концептуальными схемами и моделями данных увеличивает мобильность прикладных систем при переходе на другую программную платформу. Генерация кода, задающего интерфейс ПО с базой данных, не только позволяет сократить время разработки, но и дает возможность отделить разработку ПО от ведения архива проектной документации[4].

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

1. наличие базы проектных данных (репозитория), архива или словаря.

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

3. Возможности импорта/экспорта, открытая архитектура. Спецификации, полученные на этапах анализа, проектирования и кодирования одной ИС, могут быть использованы при проектировании другой системы с использованием других CASE-систем;

4. многопользовательский режим.

5. Расширение новыми методологиями.

6. Обеспечение качества проектной документации.

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

7. автоматическая генерация отчетов о проектных решениях;

8. Генерация кодов программ.

9. планирование и управление проектом.

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

1. бизнес-анализ (фактически, модели деятельности предприятий “как есть” и ”как должно быть” строятся с применением методов структурного системного анализа и поддерживающих их CASE-средств);

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

1.3 Технология RAD в информационных системах

Одним из возможных подходов к разработке ИС в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development)[19, 31]. Под этим термином обычно понимается процесс разработки ИС, характеризующийся тремя элементами:

1. небольшая команда аналитиков и программистов (от 2 до 10 человек);

2. короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл по методологии RAD состоит из четырех фаз:

1. фаза анализа и планирования требований;

2. фаза проектирования;

3. фаза построения;

4. фаза внедрения.

На фазе анализа и планирования требований:

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

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

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

Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС [5].

На фазе проектирования:

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

2. Используются CASE-средства для быстрого получения работающих прототипов приложений.

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

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

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

6. Определяются требования разграничения доступа к данным.

7. Происходит определение набора необходимой документации[5].

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

Результатом данной фазы должны быть:

1. общая информационная модель системы;

2. функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

3. точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

4. построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности[21, 329].

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

На фазе построения:

1. выполняется непосредственно сама быстрая разработка приложения.

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

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

3. Тестирование системы осуществляется непосредственно в процессе разработки[20, 170].

Завершается физическое проектирование системы:

1. определяется необходимость распределения данных;

2. производится анализ использования данных;

3. производится физическое проектирование базы данных;

4. определяются требования к аппаратным ресурсам;

5. определяются способы увеличения производительности;

6. завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

На фазе внедрения:

1. производится обучение пользователей;

2. осуществляются организационные изменения;

3. параллельно с внедрением новой системы ведется работа с существующей системой (до полного внедрения новой).

Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы[20, 170].

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

1. разрабатывается совершенно новая система;

2. уже было проведено обследование предприятия и существует модель его деятельности;

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

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика[11, 68].

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

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

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

Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов представлено в таблице 1.

Таблица 1 – Размер приложения по методологии RAD

< 1000 функциональных элементов

один человек

1000-4000 функциональных элементов

одна команда разработчиков

> 4000 функциональных элементов

4000 функциональных элементов на одну команду разработчиков

Глава 2 Практическая реализация объектно-процессного подхода

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

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

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

Процесс – это описание шагов, которые необходимо выполнить при разработке проекта.

Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг.

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

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

Другим принципом построения моделей сложных систем является принцип многомодельности. Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к методологии ООП это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений (views), каждое из которых адекватно отражает некоторый аспект поведения или структуры системы[10, 310].

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

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

Главными в разработке UML были следующие цели:

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

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

3. обеспечить независимость от конкретных языков программирования и процессов разработки;

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

5. стимулировать рост рынка объектно-ориентированных инструментальных средств;

6. интегрировать лучший практический опыт.

Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО[16].

Язык UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder и др.). Полное описание UML можно найти на сайтах http://www.omg.urg, http://www.rational.com и http://uml.shl.com. Описание UML на русском языке содержится в книге М. Фаулера и К. Скотта, в дальнейшем изложении терминология языка соответствует данному переводу.

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др.

UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

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

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

Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы[12, 19].

В UML выделяют следующие типы диаграмм:

1. диаграммы вариантов использования;

2. диаграммы классов;

3. диаграммы поведения системы;

4. диаграммы взаимодействия.

Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации – структурную организацию обменивающихся сообщениями объектов. Эти диаграммы могут быть преобразованы друг в друга;

5. диаграммы состояний – для моделирования поведения объектов системы при переходе из одного состояния в другое.

6. Диаграммы деятельностей – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей.

Это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы;

7. диаграммы реализации: диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы. На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости.

Объектно-ориентированные языки моделирования появились в период с середины 70-х до конца 80-х годов, когда исследователи, поставленные перед необходимостью учитывать новые возможности объектно-ориентированных языков программирования и требования, предъявляемые все более сложными приложениями, вынуждены были начать разработку различных альтернативных подходов к анализу и проектированию[16].

С 1989 по 1994 год число различных объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее, многие пользователи испытывали затруднения при выборе языка моделирования, который бы полностью соответствовал их потребностям, что послужило причиной так называемой «войны методов». В результате этих войн появилось новое поколение методов, среди которых особое значение приобрели языки Booch, созданный Грейди Бучем (Grady Booch), OOSE (Object-Oriented Software Engineering), разработанный Айваром Джекобсоном (Ivar Jacobson) и ОМТ (Object Modeling Technique), автором которого является Джеймс Рамбо (James Rumbaugh). Кроме того, следует упомянуть языки Fusion, Шлаера-Меллора (Shlaer-Mellor) и Коада-Йордона (Coad-Yourdon). Каждый из этих методов можно считать вполне целостным и законченным, хотя любой из них имеет не только сильные, но и слабые стороны.

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

Критическая масса новых идей начала формироваться к середине 90-х годов, когда Грейди Буч (компания Rational Software Corporation), Айвар Джекобсон (Objectory) и Джеймс Рамбо (General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Являясь основными авторами языков Booch, OOSE и ОМТ, партнеры попытались создать новый, унифицированный язык моделирования и руководствовались при этом тремя соображениями.

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

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

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

Начав унификацию, авторы поставили перед собой три главные цели:

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

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

3. создать такой язык моделирования, который может использоваться не только людьми, но и компьютерами.

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

Во-вторых, было необходимо найти точку равновесия между выразительной мощью и простотой. Слишком простой язык ограничил бы круг решаемых с его помощью задач, а слишком сложный мог ошеломить неискушенного разработчика. Кроме того, при объединении существующих методов приходилось учитывать наличие уже разработанных с их помощью продуктов. Внесение слишком большого числа изменений могло бы оттолкнуть уже имевшихся пользователей, а сопротивляясь развитию языка, авторы потеряли бы возможность привлекать новых пользователей и делать язык более простым и удобным для применения. Создавая UML, разработчики старались найти оптимальное решение этих проблем[17, 39].

Официально создание UML началось в октябре 1994 года, когда Рамбо перешел в компанию Rational Software, где работал Буч. Первоначальной целью было объединение методов Буча и ОМТ. Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML.

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

Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments и Unisys. UML 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен Группе по управлению объектами (Object Management Group, OMG) на конкурс по созданию стандартного языка моделирования.

Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG, а именно: Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software и Taskon. Чтобы формализовать спецификации UML и координировать работу с другими группами, занимающимися стандартизацией, под руководством Криса Кобрина (Cris Kobryn) из компании MCI Systemhouse и Эда Эйкхолта (Ed Eykholt) из Rational была организована семантическая группа. Пересмотренная версия UML (1.1) была снова представлена на рассмотрение OMG в июле 1997 года. В сентябре версия была утверждена на заседаниях Группы по анализу и проектированию и Комитета по архитектуре OMG, a 14 ноября 1997 года принята в качестве стандарта на общем собрании всех членов OMG[21].

Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 – UML 1.3.

Таким образом, UML (унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. Он использует графические обозначения для создания модели системы. Данный язык был создан для определения, визуализации, проектирования и документирования программных систем, а также его используют для моделирования бизнес-процессов, системного проектирования[16].

Концептуальная модель UML (концептуальную модель включает: основные строительные блоки языка; правила их сочетания; некоторые общие для всего языка механизмы).

2.1  IBM Rational Rose

Популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language).

Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования[13, 26].

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

Только Rational Rose имеет весь необходимый набор визуальных средств проектирования. Только Rose поможет решить проблемы с кодогенерацией на определенном языке программирования.

Только Rational Rose осуществляет такие подходы, как прямое и обратное проектирование, а так же Round Trip Engineering. Такой арсенал позволит не только проектировать новую систему, но и доработать старую, произведя процесс обратного проектирования.

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

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

Продукт будет интересен проектировщикам систем и аналитикам.

Rational Rose Professional – это профессиональная редакция продукта. Имеет в своем наборе весь спектр изобразительных средств.

В зависимости от выбранного языка программирования осуществляет прямое и обратное проектирование. Rose Professional заказывается только в определенной конфигурации (например, Rose Professional С++ или Rose Professional С++ DataModeler).

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

Продукт направлен как на аналитиков, так и на разработчиков.

Rational Rose RealTime выпущен для создания 100% исполняемого кода в реальном масштабе времени. RealTime позволяет проводить прямое и обратное проектирование на языках С или С++.

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

Rational Rose Enterprise – это абсолютно полная версия продукта.

Поддерживаются все вышеперечисленные функции за исключением возможности 100% кодогенерации. Версия продукта покрывает весь спектр задач по проектированию, анализу и кодогенерации[13, 59].

Направлен на всех участников проекта.

Rational Rose Data Modeler - это не конкретный релиз продукта, а возможность по проектированию баз данных.

Функции DataModeler входят в состав Rose Enterprise или Professional.

В зависимости от поставки, в Rational Rose может быть расширен или сужен набор визуальных компонент (диаграмм).

Rational Rose поддерживает прямое и обратное проектирование на языках: ADA, Java, С, C++, Basic.

Поддерживает технологии COM, DDL, XML; позволяет генерировать схемы Oracle и SQL.

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

На рынке уже сейчас имеется достаточное число модулей для популярных языков программирования и систем. Таких как: Delphi, ErWin, Jbuilder, VisualCafe, Jdeveloper, VisualAge SmallTalk. Одна из ведущих компаний в области создания дополнительных модулей - Ensemble Systems.

Rational Rose неоднократно признавалось различными изданиями лучшим средством проектирования[13, 64].

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

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

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

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

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

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

Вне зависимости от того, какими технологиями разработки вы пользуетесь, будь то Jazz, Eclipse, JavaT, MicrosoftR.NET, LinuxR, встроенные или мобильные системы, решения Rational дают вам возможность управлять всеми стадиями проекта.

Методики, предлагаемые Rational для создания программного и аппаратного обеспечения, помогут вам точно определить, автоматизировать и интегрировать ключевые аспекты разработки системы, распределив их по участникам вашей команды специалистов, начиная от аналитиков и заканчивая разработчиками, тестировщиками и менеджерами проектов. Решения IBM Rational проверены временем и отличаются функциональной полнотой, открытостью и модульностью[13, 76].

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

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

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

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

2.2 Sparx Systems Enterprise Architect

Как уверяют разработчики (Sparx Systems), Enterprise Architect - это программа для UML-моделирования и проектирования нового поколения. Вот фраза из их рекламных материалов:

Enterprise Architect существует в вариантах для Windows и Linux и является неплохим средством для UML-моделирования, с возможностью многопользовательской работы и дружественным интерфейсом.

В EA множество функций, которые обычно распределены между несколькими приложениями (ничем не напоминает наши слова о Borland Together?), включая отличные возможности по генерации документации, поддержку плагинов, генерацию XSD-схем, HTML и поддержку для таких языков программирования, как C++, Java, PHP, Visual Basic, VB.Net, Delphi или C#.

Возможности Enterprise Architect весьма многочисленны. Вот некоторые из них[22]:

1. нотация UML 2.0 с поддержкой всех видов диаграмм;

2. как уже было сказано выше, поддержка C++, Java, C#, VB, VB.Net, Delphi, PHP, .NET;

3. моделирование БД, прямое проектирование в DDL и обратное проектирование из ODBC;

4. загружаемые UML-профили (например, SPEM), позволяющие создавать узкоспециализированные модели;

5. поддержка паттернов проектирования;

6. генерация документации в форматах HTML и RTF;

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

8. автоматизация интерфейса, поддержка макросов.

Enterprise Architect существует в трех редакциях:

1. EA Desktop Edition.

Интуитивно понятная утилита для UML-моделирования, предназначенная для индивидуальных аналитиков и/или разработчиков. Простейший инструмент проектирования, имеющий некоторые ограничения. Отсутствуют многие, привычные для профессионалов, функции, которые, впрочем, абсолютно не нужны, если вы просто ищете инструмент для рисования UML-диаграмм. Не поддерживается, например, импорт/экспорт кода и DDL, Active X-интерфейс и совместный доступ к диаграммам[14].

2. EA Professional Edition.

Полнофункциональная среда UML-моделирования, нацеленная на групповую разработку, поддерживает совместный доступ к созданным моделям, Active X, XMI, импорт/экспорт кода и DDL, извлечение схем БД Oracle, SQL Server и MS Access.

3. EA Corporate Edition.

Наиболее полная редакция, включающая все возможности настольной и профессиональной версий плюс возможность соединения с MySQL, SQL Server, PostgreSQL, Sybase Adaptive Server Anywhere и Oracle9i. Также эта редакция поддерживает авторизацию пользователей, группы пользователей, блокировку элементов. Эта версия предназначена для больших команд.

2.3 Microsoft Visual Modeler

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

Множество компаний занялись разработкой подобного стандарта и инструментов. В результате появился на свет UML - Unified Modeling Language и множество поддерживающих его инструментов, одним из которых является Visual Modeler.

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

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

Далее рассмотрим в сравнении два объекта - Visual Modeler и Rational Rose[14].

Необходимо сказать, что VM создавался в тесном содружестве с компанией Rational. Именно поэтому он унаследовал многие черты популярного продукта этой фирмы Rational Rose. Однако следует понимать, что VM создавался для тех, кто использует Visual Studio в качестве бесплатного дополнительного инструментария. И поэтому не следует ожидать от него всего того разнообразия функциональных характеристик, свойственных Rational Rose. Если бросить взгляд на эти два продукта, то видно, что Ration Rose умеет:

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

2. использовать в своих моделях DDL (Data Definition Language);

3. имеет встроенную возможность расширения функционала с помощью VBA так же, как это можно сделать в любом приложении Microsoft Office;

4. проводить масштабирование моделей.

Отсюда вывод: Visual Modeler можно рассматривать как ничто иное, как рабочую модель Rational Rose. Однако не следует забывать, что VM - инструмент, который дает возможность ощутить все достоинства использования визуального моделирования при создании сложных систем, и при этом вы его получаете, приобретая любой их продуктов, входящих в состав Visual Studio 6.0, в то время как Rational Rose стоит денег, дополнительных и весьма немалых. А в итоге, хотя, быть может, это покажется парадоксальным, хотелось бы сказать о деньгах[14].

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

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

ЗАКЛЮЧЕНИЕ

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

В соответствии с различными представлениями об организации методики проектирования ИС принято делить на объектные и функциональные (структурные).

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

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

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

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

1) На основании проведенного исследования обзора литературы, были рассмотрены теоретические аспекты реализации объектно-ориентированного подхода, рассмотрены теоретические аспекты понятия.

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения. Технические требования— Введ. 1992-01-01 [Электронный ресурс]. - URL: http://docs.cntd.ru/document/1200006979

2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. Технические требования— Введ. 1992-01-01 [Электронный ресурс]. - URL: http://docs.cntd.ru/document/1200006921

3. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств. Технические требования— Введ. 2012-03-01 [Электронный ресурс]. - URL: http://docs.cntd.ru/document/gost-r-iso-mek-12207-2010

4. ГОСТ Р ИСО/МЭК 15271–02. Руководство по ИСО/МЭК 12207 (процессы жизненного цикла программных средств). Технические требования— Введ. 2003-01-07 [Электронный ресурс]. - URL: https://docplan.ru/Index2/1/4294817/4294817038.htm

5. ОРММ ИСЖТ 2.01–00. Требования к составу, содержанию и оформлению документов при создании ИС. – М.: ВНИИАС МПС России, 2000. – 62 с.

6. ОРММ ИСЖТ 5.03–00. Процессы жизненного цикла ИС и программных средств – М.: ВНИИАС МПС России, 2000. – 48 с.

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. Леоненков, А.В. Визуальное моделирование в среде IBM Rational Rose [Электронный ресурс]. - URL:– www.intuit.ru

15. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML [Электронный ресурс]. - URL: – www.intuit.ru

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

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

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

19. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 2015. - 672 с.

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

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

22. UML спецификация [Электронный ресурс]. - URL: – www.omg.com