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

Содержание:

Введение

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

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

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

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

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

Цель данной работы: обзор и анализ средств и методов проектирования ИС при объектно-ориентированном подходе. Обзор неотъемлемой его части – UML и приведение примера проектирования некоторых систем.

1. Информационные системы

   1. Проектирование и моделирование информационных систем

Значение моделирования 

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

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

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

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

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

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

Моделирование позволяет решить 4 производственные задачи: 

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

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

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

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

Технология проектирования ИС – это система средств проектирования и методологий, в частности методов и средств проективной организации 

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

В работе над проектом весьма важными вопросами являются «Что?», «Как?», «Кому?» и «В каком порядке?» должна быть выполнена работа. 

Какие требования выдвигаются к технологии проектирования: 

1. Проект отвечает требованиям заказчика 
2. Все этапы процесса проектирования максимально отображены 
3. Обеспечения максимальной продуктивности человеческих и финансовых ресурсов в процессе проектирования и дальнейшей поддержки проекта 
4. Технология обеспечивает рост производительности  
5. Проектная документация должна быть максимально проста и понятно 
6. Технология должна быть надежной и иметь возможность для дальнейшего комфортного использования 

   1. Жизненный цикл информационных систем

Жизненный цикл ИС – последовательная система этапов, проходимых ИС в своем развитии, с момента вербальной реализации идеи, до прекращения ее функциональных способности 

Структура жизненного цикла ИС реализуется согласно стандарту ISO/IEC 12207 (См. Рис.1) 

  

Рисунок 1 Структура жизненного цикла ИС по стандарту ISO/IEC 12207

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

Разработка ПО – общая совокупность работ по созданию ПО (с его компонентами). Данная процедура контролируется существующими технологическими требованиями (включая работу с документами) и индивидуальными требованиями заказчика (См. Рис.1). 

Эксплуатация – работы по внедрению компонентов ПО, конфигурирование БД и рабочих мест. 

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

Управление конфигурацией – поддержка основных процессов ЖЦ ПО, прежде всего процессов разработки и сопровождения ПО. 

Обеспечение качества проекта – верификация, проверка и тестирование ПО. 

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

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

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

Каскадная модель. Разработанная в 1970-ом году каскадная модель У.Ройсона предполагала распределение этапа по принципу «каскада» (см. Рис.2). Каждый последующий этап подразумевал полное завершение актов и действий на предыдущем этапе. Данная модель наиболее актуальна для решения несвязных задач, не требующих совместной работы с другими программными или техническими устройствами. Применение данного типа модели к сложным, масштабным и длительным проектам приводит чаще к их не реализации на практике.  

Достоинства каскадной модели: 

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

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

Рисунок 2 Каскадная модель ЖЦ ИС

Преимущества каскадной модели: 

1. Каждая стадия является полностью законченным малым проектом отвечающий всем критериям 
2. Линейное построение работ позволяет более объективно и полно подходить к планированию необходимых затрат и работ  
3. Слабые стороны каскадной модели: 
4. Обнаружение проблем занимает большое кол-во времени 
5. Выход из календарного графика, запаздывание с получением результатов. 
6. Кол-во документации весьма объемно. 
7. Продукт представляется монолитным и неспособен к разделению 
8. Повышенный риск создания продукта, неудовлетворяющий критериям пользователя. 

  

Вторая по счету наиболее популярная модель – спиральная. Созданная в 1980-ых годах Б.Боэмом, спиральная модель опирается на принцип «сверху-вниз» (см. Рис.3). Данная модель использует взаимодействие «витком» спирали собственной архитектуры, для повышения гибкости процесса. Каждый «виток» спирали является отдельным действием, задачей, процессом, адресованных отдельной версии ПО. «Витки» создаются путем нескольких итераций методом прототипирования. 

 

Рисунок 3 Спиральная модель ЖЦ ИС

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

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

• Высокий темп протекания работы 
• Заказчик получает возможность присутствовать в процессе разработки на всех этапах проекта 
• Полный объем работы дробиться на маленькие части 
• Снижен риск непредсказуемого поведения ПО. 
• Слабые стороны спиральной модели: 
• Высокий уровень сложности организации модели 
• Сложность эксплуатации с точки зрения простого пользователя 
• Повышенный темп работы для самого разработчика. 

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

• 1. CASE-средства и их функции

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

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

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

Классификация CASE-систем производится по 5 различным показателям:

1. По поддерживаемым методологиям
2. По поддерживаемым графическим нотациям
3. По степени интегрированности
4. По типу и архитектуре вычислительной техники
5. По режиму коллективной разработки проекта
6. По типу операционных систем (см. Табл. 1)

Таблица 1 Классификация CASE-систем

CASE-системы	По поддерживаемым методологиям
	1	функционально (структурно)-ориентированные
	2	объектно-ориентированные
	3	комплексно-ориентированные
	По поддерживаемым графическим нотациям
	1	с фиксированной нотацией
	2	с отдельными нотациями
	3	наиболее распространенными
	По степени интегрированности
	1	tools
	2	toolkit
	3	workbench
	По типу и архитектуре вычислительной техники
	1	ПЭВМ
	2	ЛВС
	3	ГВС
	4	Смешанного типа
	По режиму коллективной разработки проекта
	1	поддерживающие коллективную разработку
	2	ориентированные на режим реального времени
	3	режим объединения подпроектов
	По типу операционной системы
		Windows, UNIX, OS/2 и др

Архитектура CASE-средств построенна вокруг репозитория (см. Рис.4).

Ядром системы CASE-средств является репозиторий (база данных проекта), являющийся специализированной базой данных для отображения создаваемой ИС в любой момент времени.

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

В репозитории содержатся следующие описания объектов:

1. Проектировщики, совместно с соответствующими правами доступа к компонентам системы
2. Структуры организации
3. Диаграмма и их связи между собой
4. Фрагменты диаграмм
5. Структуры данных
6. Модули (программные)
7. Процедуры
8. Библиотеки модулей и др.

 

Рисунок 4 Архитектура CASE-средств

Графический редактор является частью архитектуры CASE-средств. В своей функции он содержит ряд основных операций:

1. Создание элементов диаграмм и способов связи между ними
2. Задавние описания диаграмм, их элементов и способов связи между ними
3. Редактирование элементов диаграмм и способов связи между ними

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

Верификатор – служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС.

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

Одним из инструментов проекта является администратор. На администратора проекта возложены следующие функции:

• Инициализация
• Определение параметров в начальной стадии проекта
• Распределение и организация права доступа к элементам проекта
• Наблюдение за состоянием выполнения проекта

Набор утилит для обслуживания и поддержания репозитория называется – сервисом. Сервис выполняет процессы: архивации данных, создания нового репозитория и восстановления данных.

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

Одним из наиболее популярных CASE-средств, поддерживающих методологию структурного (функционального проектирования) является пакет AllFusion Modeling Suite, выпущенный компанией Computer Associates (CA).

В этот пакет входит 5 продуктов:

1.  AllFusion Process Modeler .AllFusion Process

2.  AllFusion ERwin Data Modeler (ERwin).

3.  AllFusion Data Model Validator (ERwin Examiner).

4.  AllFusion Model Manager (ModelMart).

5.  AIIFusion Component Modeler (Paradigm Plus) (см. Рис.5).

Рисунок 5 Общая схема взаимодействия инструментальных средств AllFusion Modeling Suite

AllFusion Process Modeler (BPwin) является примером CASЕ-cредств верхнего уровня для проведения аналитической и реорганизационной работы в сфере бизнес-процессов. AllFusion Process Modeler поддерживает функциональную модель IDEF0, IDEF3, DFD. Сама функциональная модель создана для выполнения описательной функции действительных деловых процессов ( модель AS-IS) и идеализированной модели (модель TO-BE).

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

BPwin может стать основой для построения модели данных. Существуют определенные технические затруднения в формализации, потому процесс полностью не является автоматизированным. Computer Associates способно предложить вспомогательный инструмент построения модели данных на основе механизма бивекторной связи BPwin - ERwin (стрелка 1 на рис. 5).

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

AllFusion Data Model Validator выполняет роль анализатора ошибок. Поиск ошибок в больших объемах данных чрезвычайно затруднительная вещь. Так же он способен скорректировать данные ошибки, используя готовую модель ERwin или запустив процесс инверсии проектирования базы данных (стрелка 3, 4 на рис. 5).

Объемные проекты часто вызывают проблему с качеством документации. BPwin и ERwin позволяют решать данную проблему, путем генерации отчетов для анализа и документирования моделей. Отчеты способны выводиться в текстовом формате, HTML, .doc и т.д.

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

Вывод по главе:

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

В функциях CASE-средств выделяются основные 3: создание диаграмм, создание описания диаграмм и редактирование фрагментов диаграмм. Подобного рода CASE-технологии способствуют комфортизации и универсализации процесса разработки ПО на всех стадиях, но особенно на ранних (стадиях моделирования процесса создания ИС). Графическое моделирование наиболее наглядный способ представления данных. Особенностью данного способа является не только его универсальность, но и гибкость к изменениям. CASE-средства позволяют редактировать неудачные по мнению заказчиков или разработчиков варианты, что является невероятно большим плюсом в использовании подобного рода технологий. CASE-технологии являются системными технологиями и рассчитаны на разработку как большим количеством специалистов, так и достаточно малым.

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

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

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

1. Использование Унифицированного языка моделирования (UML) для проектирования информационных систем

   1. Краткий обзор UML

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

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

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

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

Конструирование подразумевает под собой интересную часть UML, а точнее его непосредственное взаимодействие с языками программирования, такими как C++, Visual Basic или Java. Графическое представление, сконструированное на языке UML, может быть конвертировано непосредственно в код, написанный на одном из вышеперечисленных языков. Данный процесс называется прямое проектирование. И работать эта технология может в обе стороны, так процесс отображения кода в графически-представленном виде на языке UML называется обратным проектированием.

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

Концептуальная модель UML. Сущности и связи

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

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

Строительные блоки в свою очередь подразделяются на три основные части:

• Сущности (things)
• Связи (relationships)
• Диаграммы (diagrams)

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

Схема 1 Классификация сущностей

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

Класс (Class) – объединение объектов, имеющих одинаковые свойства, операции, атрибуты и прочее. Класс реализует интерфейсы – один и больше.

Интерфейс (Interface) – играет роль сервисной части. Данный набор операций описывает интерфейс класса или его видимое пользователю поведению. Непосредственно на детальные свойства класса никак не влияет.

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

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

Активные классы – под это понятие попадают объекты, имеющие в свое распоряжении (или совершающие) несколько потоков и процессов единовременно.

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

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

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

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

Класс	Интерфейс	Кооперация	Варианты использования
Активные классы	Компоненты	Артефакты	Узлы

Таблица 2Графическое отображение структурных сущностей

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

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

Автомат (state machine) – поведенческая сущность, суть которой заключается в реагировании на внешние раздражители, и сменой состояния объекта, в зависимости от условий.

Деятельность (activity) – третий тип поведенческих сущностей. Деятельность рассматривает непосредственно последовательность шагов, абстрагируясь от объектов. Отдельные шаг деятельности называется действием (action).

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

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

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

Поведенческие сущности
Взаимодействия	Автомат (состояние)		Деятельность (действие)
Группирующие		Аннотирующие
Пакет		Примечание

Таблица 3 Графические обозначения поведенческих, группирующих и аннотирующих сущностей.

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

Связи являются основными блоками модели, определяющими взаимосвязь и взаимоотношения объектов в UML. Выделяется четыре вида связей:

1. Зависимость.
2. Ассоциация.
3. Обобщение.
4. Реализация.

Зависимость (dependency) – указывает на взаимоотношения между двумя объектами, выраженными зависимостью. То есть при изменении одного, в обязательном порядке меняется второе.

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

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

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

Данные четыре элемента представляют собой основу взаимосвязей элементов в модели UML. Их графическое отображение показано на рис.6.

Рисунок 6 Графическое отображение связей в UML.

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

• 1. Диаграммы UML и их виды

В рамках данной работы мы рассмотрим восемь типов диаграмм:

1. Диаграмма вариантов использования или прецедентов (use case diagram)
2. Диаграмма классов (class diagram)
3. Диаграмма состояний (statechart diagram)
4. Диаграммы взаимодействия (interaction diagrams
5. Диаграмма деятельности (activity diagram)
6. Диаграмма пакетов (package diagram
7. Диаграмма компонентов (component diagram
8. Диаграмма размещения (deployment diagram)

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

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

Мы приведем пример взаимодействия пользователя с часами на рис. 7.

У действующего лица есть несколько вариантов взаимодействия, конкретно: «включение будильника», «отключение будильника», «изменение формата времени» и «изменение мелодии сигнала».

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

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

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

Рисунок 8 Использование диаграмм классов на примере лампы.

Кроме того, классы на время разработки могут быть сгруппированы в пакеты по некоторым общим признакам. Некоторые из них – «интерфейсная часть», «системная часть», «контроллер». Пример выделение пакета – «система» продемонстрирован на рис. 9.

Рисунок 9 Пример объединения объектов в "пакет".

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

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

Рисунок 10 Диаграмма состояний заказного товара

С состоянием можно связать пять основных типов данных: деятельность, входное действие, выходное действие, событие и история состояния.

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

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

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

Событие – событие переводит систему непосредственно из одного состояния в другое. Пример: включение телевизора, открытие окна и прочее.

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

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

Рисунок 11 Диаграмма компонентов для банковской системы

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

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

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

Сообщение (message) — средство запроса

Информационное (informative) сообщение — сообщение, обеспечивающие информацией другие инстанции

Сообщение-запрос (interrogative) — сообщение, в основе которой есть потребность получения какой-либо информации

Императивное (imperative) сообщение — сообщение, в основе которого лежит запрос информации у получателя услуги

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

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

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

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

Заключение:

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

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

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

1. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. - 2-е изд., испр. и. дополн. – М.: Издательство Диалог-МИФИ, 2007 – 400 с.
2. Проектирование экономических информационных систем: Учебник/Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под. ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2003. – 512 с.
3. Вендеров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – М.: Финансы и Статистика, 2006. – 544 с.
4. Г. Буч, А. Якобсон, Дж. Рамбо UML [пер. с англ. А. Вахитов, Д. Солнышков]. - 2-е изд. – М.: Питер, 2006 – 735 с.
5. Дубейковкий В.И. Эффективное моделирование с AllFusion Process Modeler 4.1.4 и AllFusion PM – М.: ДИАЛОГ-МИФИ, 2007 – 384 с.
6. Дубейковкий В.И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как? – М.: ДИАЛОГ-МИФИ, 2007 – 464 с.
7. Маклаков С.В. Моделирование бизнес-процессов с AllFusion PM. – 2-е изд., испр. и. дополн. – М.: Издательство Диалог-МИФИ, 2007 – 224 с.
8. У. Боггс, М. Боггс UML и Rational Rose секреты эффективного проектирования объектно-ориентированных приложений – М.: ЛОРИ, 2004 – 509 с.
9. 9.       Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. — М.: Издательский центр «Академия», 2004. — 288 с.
10. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с.
11. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии: Практикум. – М.: Горячая линия - Телеком, 2005 – 160 с.
12. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е изд.: Пер. с англ. Мухин Н. – М.: ДМК Пресс. – 496 с.: ил
13. Леоненков А. В. Самоучитель UML 2. — СПб.: БХВ-Петербург, 2007. — 576 с.: ил.