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

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

Содержание:

ВВЕДЕНИЕ

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

Основными задачами работы являются освещение и анализ :

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

- структуры и технологических процессов Унифицированного процесса разработки ПО ;

- продуктов компании IBM Rational, лидера в разработке и сопровождении средств, поддерживающих создание объектно-ориентированных систем;

- основ Унифицированного языка моделирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При разработке программного обеспечения термин «объект» впервые был введен Оле-Джоаном Далем, Бьорном Мюрхогом и Кристеном Ныгардом из Норвежского вычислительного центра (г. Осло). Они разработали язык Simula 67, созданный на основе языка Algol-60 и предназначенный для моделирования и описания сложных систем. Однако по-настоящему широкое внедрение этой идеи произошло при разработке языка SmallTalk в 1990 г. Аланом Кейем из Исследовательского центра фирмы Xerox (г. Пало-Альто). В SmallTalk использовались только объектно-ориентированные конструкции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- описание системы в виде объектов больше соответствует содержательному смыслу предметной области;

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

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

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

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

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

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

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

2. Основы Унифицированного процесса

2.1. Структура Унифицированного процесса

Унифицированный процесс как процесс разработки программного обеспечения представляет собой методологию, содержащую детальное описание работ по созданию и внедрению ПО (авторы Айвар Якобсон, Грэди Буч и Джеймс Рамбо). Она отвечает "на вопросы когда, как, кто, что и с помощью чего реализуется проект" [7], а именно содержит описание:

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

- видов деятельности (как) – работ, осуществляемых исполнителями;

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

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

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

2.2. Технологические процессы

Унифицированный процесс придерживается спиральной модели (стратегии) жизненного цикла ПО, предложенной Барри Боэмом (рисунок 1).

Рисунок 1. Спиральная модель жизненного цикла ПО

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

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

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

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

Конструирование (англ. construction). Целью фазы является разработка действующей версии системы, основным результатом – версия системы.

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

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

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

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

Рисунок 2. Интенсивность процессов при создании версии информационной системы

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

Таблица 1.

Краткая характеристика моделей

Процесс	Модель	Назначение
Формирование требований	Модель вариантов использования	Отображает существенные функциональные требования к системе в форме, удобной для всех заинтересованных лиц. Под существенными требованиями понимаются требования, реализация которых принесет пользователям ощутимый и значимый результат. Наименее формальная, но управляет всем процессом разработки
Анализ требований	Модель анализа	Детализирует варианты использования с точки зрения организации внутренней архитектуры системы, а именно: состава основных сущностей (классов анализа) и взаимодействия между ними. Класс анализа – укрупненный класс (сущность), который в дальнейшем будет разбит на составляющие
Проектирование	Модель проектирования	Содержит полное детализированное описание внутренней архитектуры и алгоритмов работы системы. Применяется внутри организации, разрабатывающей систему
Реализация	Модель реализации	Содержит описание исполняемой системы: компонентов (исходных текстов программ, исполняемых модулей, таблиц БД и т. д.) и схемы развертывания системы
Тестирование	Модель тестирования	Предназначена для проверки соответствия полученного ПО требованиям

2.3. Утилиты

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

- управление требованиями – IBM Rational RequisitePro;

- визуальное моделирование и генерация объектного кода – IBM Rational Rose, IBM Rational XDE;

- разработку – IBM Rational RapidDeveloper;

- конфигурационное управление – IBM Rational ClearCase;

- управление изменениями – IBM Rational ClearQuest;

- автоматизированное документирование – IBM Rational SoDA;

- автоматизированное тестирование – IBM Rational TeamTest, IBM Rational TestFactory, IBM Rational Robot, IBM Rational PurifyPlus, IBM Rational SiteCheck и IBM Rational SiteLoad.

Методологической основой использования перечисленных продуктов является IBM Rational Unified Process (IBM RUP) – "электронный аналог" Унифицированного процесса. IBM RUP поставляется в виде "on-line" документации (размещаемой в Web базы знаний), что позволяет его использовать во внутренней сети организации с целью приобщения всех сотрудников к полезной информации, и состоит:

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

- рекомендаций по использованию инструментальных средств, автоматизирующих стадии жизненного цикла ПО;

- примеров и шаблонов для Rose, которые служат руководствами по тому, как "правильно" проектировать систему;

- шаблонов для SoDA, которые помогают автоматизировать документирование ПО;

- шаблонов Microsoft Word, которые предназначены для поддержки документации по всем стадиям и работам жизненного цикла ПО;

- планов в формате Microsoft Project, отражающих итерационную разработку;

- Development Kit (англ. – комплект разработки), содержащего описание возможностей по конфигурации и расширения IBM RUP для специфических нужд проекта;

- доступа к Resource Center, содержащего последние публикации, обновления, подсказки, методики, а также ссылки на add-on (англ. – расширения) и сервисы;

- книги Филиппа Кратчена "Введение в Rational Unified Process" [7]. Книга содержит более 200 страниц и является хорошим вводным руководством к Унифицированному процессу и базе знаний.

Ключевым продуктом для автоматизации технологического процесса "Проектирование" является IBM Rational Rose, которое представляет собой классическое Case-средство. К основным возможностям Rose относятся:

- прямое проектирование – построение модели системы в виде диаграмм UML и глоссария;

- кодогенерация – получение кода программы на основе модели системы. Поддерживаются: С++, Ada, Java, Visual Basic, CORBA1/IDL2. Сторонние производители разрабатывают специальные мосты к не входящим в стандартную поставку языкам (например, к Object Pascal);

- генерация схем БД для Oracle, скриптов DDL3 и документов XML4;

- обратное проектирование (реинжиниринг) – получение модели на основе кода программы, БД, скрипта или документа;

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

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

Для разработки программ рекомендуется использовать среду разработки программного обеспечения IBM Rational RapidDeveloper.

2.4. Базовые концепции Унифицированного процесса

Базовыми концепциями Унифицированного процесса являются следующие [6, 7]:

- разработка ведется итеративно;

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

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

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

- все процессы должны поддерживаться согласованным набором инструментальных средств (утилит).

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

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

Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). С этого времени было выпущено несколько версий спецификации UML, две из которых носят статус международного стандарта:

- UML 1.4.2 – "ISO/IEC 19501:2005. Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2" (англ. "Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");

- UML 2.4.1 – "ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 1. Инфраструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure") и "ISO/IEC 19505-2:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 2. Сверхструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

Последнюю официальную спецификацию языка можно найти на сайте www.omg.org.

Общая структура UML показана на следующем рисунке [4].

Рисунок 3. Структура UML

3.2. Семантика и синтаксис UML

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

Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста [10].

Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.

3.3. Нотация UML

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

В UML определено три типа сущностей:

- структурная – абстракция, являющаяся отражением концептуального или физического бъекта;

Таблица 2

Структурные типы сущностей в UML

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

Таблица 3

Группирующие типы сущностей в UML

- поясняющая (аннотационная) – комментарий к элементу диаграммы.

Таблица 4

Поясняющие типы сущностей в UML

В некоторых источниках, в частности [3, 6], выделяют также поведенческие сущности взаимодействия и конечные автоматы, но с логической точки зрения их следует отнести к диаграммам.

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

Таблица 5

Отношения между сущностями

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

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

- * – любое количество экземпляров, в том числе и ни одного;

- целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);

- диапазон целых неотрицательных чисел "первое число .. второе число" (например: 1..5, 2..10 или 0..5);

- диапазон чисел от конкретного начального значения до произвольного конечного "первое число .. *" (например: 1..*, 5..* или 0..*);

- перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).

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

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

Таблица 6

Механизмы расширения сущностей в UML

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

Рисунок 4. Обозначения класса-сущности.

3.4 Диаграммы

Таблица 7

Краткая характеристика диаграмм UML

Стандарт UML 2.x определяет также дополнительные, узко специализированные диаграммы: - диаграмму объектов (object diagram) - аналогична диаграмме классов, но вместо классов отображаются объекты;

- диаграмму синхронизации (timing diagram) - описывает состояния объекта с течением времени;

- композитную структурную диаграмму (composite structure diagram) - описывает порты (включая интерфейсы) класса для взаимодействия с другими классами;

- профильную диаграмму (profile diagram) - аналогична диаграмме пакетов с описанием классов, входящих в него;

- обзорную диаграмму взаимодействия (interaction overview diagram) - аналогична диаграмме последовательности, но со скрытыми фрагментами взаимодействия (фрагментами с меткой ref). Представляет собой контекстную (концептуальную) диаграмму последовательности, элементы которой будут конкретизированы на отдельных диаграммах декомпозиции.

3.4.1 Назначение и состав модели вариантов использования

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

Построение этой модели необходимо для выявления:

- внешнего окружения, взаимодействующего с системой (актеров);

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

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

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

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

- диаграмма автоматов;

- диаграмма классов анализа;

- диаграмма последовательности;

- диаграмма коммуникации.

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

3.4.2 Назначение и состав модели анализа

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

Построение этой модели необходимо:

- для выявления внутренней архитектуры (определения подсистем и основных классов);

- для поиска альтернативных вариантов реализации системы (подсистем) и выбора основного;

- для уточнения всех требований (функциональных и нефункциональных).

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

Таблица 8

Варианты обозначения классов

Назначение классов анализа [6]:

- граничный класс – используется для моделирования взаимодействия между системой и актерами (пользователями, внешними системами или устройствами). Взаимодействие часто включает в себя получение или передачу информации, запросы на предоставление услуг и т. д. Граничные классы являются абстракциями диалоговых окон, форм, панелей, коммуникационных интерфейсов, интерфейсов периферийных устройств, интерфейсов API (англ. application program interface – интерфейс прикладных программ) и т. д. Каждый граничный класс должен быть связан как минимум с одним актером;

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

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

3.4.3 Общие сведения о диаграммах взаимодействия

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

Общими элементами диаграмм являются:

- экземпляры актеров и объекты, участвующие во взаимодействии;

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

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

- Имя объекта : Имя класса (например, Вася : Программист);

- : Имя класса (например, : Программист) – анонимный объект;

- Имя объекта (например, Вася) – предполагается, что имя класса известно;

- Имя объекта : (например, Вася :) – объект-сирота. Считается, что имя класса неизвестно.

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

Взаимодействие между экземплярами актеров и объектами моделируется посредством передачи сообщений. Сообщение (англ. message) – это спецификация факта передачи информации между сущностями с ожиданием выполнения определенных действий со стороны принимающей сущности. Сущность, отправляющую сообщение, называют клиентом, а принимающую – сервером. Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают выполнения сервером определенных действий или передачу (возврат) клиенту необходимой информации. Если принимающей сообщение сущностью является объект, то оно представляет собой операцию (метод) объекта-сервера. Прием сообщения обычно трактуется, как возникновение события на сервере. Сообщения изображаются стрелкой с обязательным указанием направления (остриё стрелки указывает на принимающую сторону) и спецификации [1].

3.4.5 Назначение и состав диаграммы последовательности

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

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

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

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

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

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

– асинхронное сообщение (англ. asynchronous message). Клиент посылает сообщение серверу и, не дожидаясь ответа, продолжает выполнять следующие операции;

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

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

Сообщения, получаемые от внешнего источника (англ. found message) и передаваемые внешнему приемнику (англ. lost message), должны, соответственно, начинаться и заканчиваться закрашенным кружком.

UML регламентирует также два часто встречаемых вида сообщений - на создание и уничтожение объектов. Первое отображается как возвращающее сообщение со стереотипом «create», второе - как синхронное сообщение со стереотипом «destroy». После получения сообщения на уничтожение объекта его линия жизни заканчивается символом X.

Каждое сообщение должно иметь имя по одному из следующих вариантов:

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

- указание стереотипа для некоторых стандартных действий:

- «create» (англ. – создать) – возвращающее сообщение, требующее создания объекта;

- «destroy» (англ. – уничтожить) – синхронное сообщение с требованием уничтожить соответствующий объект;

- «call» (англ. – вызвать) – синхронное сообщение, требующее выполнения операции принимающего объекта;

- «send» (англ. – послать) – асинхронное сообщение, обозначающее посылку сигнала серверу;

- «return» (англ. – возвратить) или «reply» (англ. – ответить)– возвращающее сообщение;

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

[переменная =] имя([список параметров]) [:возвращаемое значение].

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

Имя сообщения (обязательный параметр) – имя вызываемого метода объекта-получателя.

Список аргументов – список аргументов, разделенных запятыми и передаваемых для выполнения метода.

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

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

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

3.4.6 Назначение и состав диаграммы коммуникации

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

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

ЗАКЛЮЧЕНИЕ

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

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

Другим важным достоинством объектно-ориентированного подхода является более тесная связь между разрабатываемыми моделями и исходным кодом программ. Если в структурных методологиях прямое и обратное проектирование возможно лишь при использовании диаграмм сущность-связь (ERD), то CASE-средства, поддерживающие UML, эти операции позволяют выполнять, как минимум, с тремя видами диаграмм: классов, последовательности и коммуникации.

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

СПИСОК ЛИТЕРАТУРЫ

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

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

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

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

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

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

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

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

9. Гранд, М. Шаблоны проектирования в Java / М. Гранд. - М.: Новое знание, 2004. - 559 с.

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