CC BY
15
ЛОГИСТИЧЕСКОЕ МОДЕЛИРОВАНИЕ ОБЪЕКТОВ И ПРОЦЕССОВ МАШИНОСТРОЕНИЯ
И.В. Илларионов Воронежский государственный университет, кафедра программирования и информационных технологий
illar@cs.vsu.ru В Н. Старов
Воронежский государственный технический университет, кафедра автоматизированное оборудование В. Муранов
Воронежский государственный технический университет, кафедра автоматизированное оборудование tertium@mailru.com
В настоящее время отрасль разработки информационных систем (к каким относятся и автоматизированные системы управления) сама становится автоматизированной. В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:
• неадекватная спецификация требований;
• неспособность обнаруживать ошибки в проектных решениях;
• низкое качество документации, снижающее эксплуатационные качества;
• затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ИС исторически всегда стояли последними в ряду тех, кто использовал компьютерные технологии для повышения качества, надежности и производительности в своей собственной работе.
Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:
• сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
• наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
• отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
• необходимость интеграции существующих и вновь разрабатываемых приложений;
• функционирование в неоднородной среде на нескольких аппаратных платформах;
• разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
• существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность трех составляющих:
• пошаговой процедуры, определяющей последовательность технологических операций проектирования;
• критериев и правил, используемых для оценки результатов выполнения технологических операций;
• нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:
• поддерживать полный ЖЦ ПО;
• обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
• обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
• обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами
управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
• обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам;
• предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
• обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
• должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся:
• стандарт проектирования;
• стандарт оформления проектной документации;
• стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
• набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
• правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;
• требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;
• механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех
разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать:
• комплектность, состав и структуру документации на каждой стадии проектирования;
• требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),
• правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
• требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
• требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
• правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
• правила использования клавиатуры и мыши;
• правила оформления текстов помощи;
• перечень стандартных сообщений;
• правила обработки реакции пользователя.
Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
Итак, для построения автоматизированной системы управления в первую очередь необходимо грамотно составить тезаурус предметной области. В данном случае предметной областью для нас является машиностроение. Составление тезауруса является определяющим для успешной разработки автоматизированной системы и представляет собой
формализованный опрос аналитиком специалистов в предметной области и получение точных описаний всех процессов и объектов, имеющих место в данной предметной области. Этот этап проектирования может быть ступенчатым с многократными последующими уточнениями и проработкой. Далее следует этап логистического моделирования. В последние годы термин «логистический» часто относится к области снабжения производства, однако мы будем понимать его шире. Логистическое моделирование в нашем видении - это построение сложных многоступенчатых связей между понятиями предметной области. Результат этого этапа проектирования завершается построением концептуальных моделей, разделённых для удобства чтения на различные уровни детализации. На модели нанесены все понятия из тезауруса, все их взаимодействия и отношения. Логистические модели являются промежуточным звеном между описанием объектов и процессов на обычном языке предметной области, понятным техническим специалистам, и ЦМЬ-моделями программных систем, понятными специалистам в программной области. Эти модели в часто строятся в нотации ГОЕБ, однако в последнее время всё больше входят в употребление нотации ЦМЬ верхних уровней абстракции, во многом дополняющие ГОЕБ. К преимуществам логистических моделей по сравнению с обычным техническим описанием следует отнести:
• чётко формализованную и стандартизованную графическую нотацию, удобную для восприятия
• наглядная структурированность
• устранение неоднозначности технического описания
За этапом логистического моделирования предметной области следует этап моделирования услуг, предоставляемых программной системой, в контексте отношений система-пользователь. В ЦМЬ-нотации эти модели реализуются диаграммами актёров и прецедентов. Потом на основе полученных диаграмм строятся диаграммы более низких уровней абстракции.
В данной же работе мы попытаемся продемонстрировать методику логистического моделирования процессов и технологических объектов машиностроения с использованием графических нотаций ЦМЬ.
Для примера были взяты такие объекты, как «рабочий» и «оборудование». Для этих объектов были построены диаграммы состояний, которые фиксируются в подсистемах управления кадрами и ресурсами автоматизированной системы управления предприятием машиностроительного профиля.
Рисунок 1. Диаграмма состояний объекта «рабочий»
Диаграммы состояний иллюстрируют поведение объекта в системе. Согласно методологии объектно-ориентированного программирования, всякий объект на протяжении времени его жизни находится в различных состояниях. Так и рабочий в контексте системы имеет ряд состояний (рисунок 1).
Во-первых, он существует, но «не принят». Затем, когда на предприятии появляется необходимость в новых кадрах, он «проходит испытание». Если он «удовлетворяет требованиям», он может быть «Принят на работу, где и «Работает рядовым рабочим». Каждые Ь лет (временное сообщение) он находится в состоянии «На переподготовке», в результате которой может синхронно выясниться, что он «достаточно квалифицирован» для того, чтобы стать мастером (сторожевое условие), и, если есть вакансии (неявное сторожевое
условие), он «Работает мастером участка», являясь при этом и «Рабочим» одновременно. Как мастер он управляет кадрами (это отношение находится за пределами семантики данной модели), а как Рабочий имеет ещё одно состояние - «В отпуске» - куда с периодичностью в N месяцев (временное событие) и откуда через М недель (временное условие) возвращается. Возможности асинхронно прервать отпуск в модели не предусмотрено. В результате проверки квалификации при переподготовке (каждые Ь1 лет) мастер может быть деквалифицирован обратно в рабочие, а рабочий может быть уволен (или уволиться - не имеет разницы на данном уровне абстракции), в таком случае (сторожевое условие «не квалифицирован») он переходит в конечное состояние «Уволен». Также из состояния «Работает мастером участка» рабочий может сразу перейти в состояние рабочий через сторожевое условие «достаточный проступок»
На следующей диаграмме показаны состояния абстрактного объекта «Оборудование» (рисунок 2). Будем исходить из того что создать объект, например, класса СБепсЬ (станок) - одного из базовых классов иерархии в подпакете «Классы станков» пакета «Классы оборудования» - невозможно, так как он является абстрактным, но мы воспользуемся возможностью создать на него указатель.
Изначально оборудование «существует» - это абстрактное философское понятие принято за описание начального состояния. Класс, описывающий его, присутствует в пакете «Классы оборудования» (необходимое условие). Пакет заполняется классами по мере получения новейшей информации от актёра верхнего уровня.
Затем предприятие покупает оборудование и безусловно переводит его в состояние «Установлено», и оно безусловно же переходит в состояние «Работает». Каждые N дней (временное событие) оно проходит техосмотр (очевидно взаимодействие с объектами типа «Рабочий» с ролями «электрик» и «механик», однако оно выходит за пределы семантики данной диаграммы) для исправления мелких дефектов и обслуживания. В случае неисправности (исключение) оборудование асинхронно переходит в состояние «Неисправно», откуда возвращается в зависимости от того, устранима ли неисправность. Если оборудование «устарело или неисправимо» (морально устарело или пришло в абсолютную негодность), оно переходит в заключительное состояние «Списано».
Для примера процесса возьмём типовой технологический процесс сверления. Следующая диаграмма (рисунок 3) моделирует структуру базы данных техпроцессов. Использование нотации ЦМЪ позволяет на основе этой диаграммы сгенерировать специальную подпрограмму, так называемый «скрипт базы данных», которая позволяет создать базу данных с определёнными нами атрибутами. В данном случае перед нами стоит
достаточно простая задача: в базе данных будет всего одна таблица - таблица техпроцессов сверления. Также на диаграмме можно определить типы запросов к базе данных.
Рисунок 2. Диаграмма состояний объекта «оборудование»
Как было сказано выше, при разработке сложных ИС и баз данных очень важно, чтобы и программисты, и специалисты по базам данных работали в рамках одной нотации. Поэтому и в настоящей статье очень полезно будет использовать UML, чтобы проиллюстрировать многогранность этой нотации.
Итак, на диаграмме имеем одну таблицу и четыре её отображения - взгляда на эту таблицу с точки зрения запросов - три запроса выборки и один - вставки. Таблица Drill_tp имеет шесть полей. Первое из них (id - идентификатор)- первичный ключ, служащий для корректной организации таблицы и возможности навигации по ней. Второе поле (name -имя) - служит для хранения названия техпроцесса. Третье (descript) - для хранения текстового пооперационного описания техпроцесса, автоматически генерируемого системой визуального проектирования техпроцессов. Четвёртое (tp_data - данные техпроцесса) содержит все данные, относящиеся к техпроцессу, необходимые для восстановления в
рабочей области системы проектирования его внешнего вида и всех его параметров. Пятое (author - автор) содержит информацию об авторе техпроцесса. И, наконец, шестое поле (etc -«и так далее») содержит примечания автора. Имена всех полей наглядно демонстрируют связь программной системы и предметной области.
Рисунок 3. Диаграмма физических данных типового технологического процесса сверления
В заключение заметим, что использование предложенных методик логистического моделирования вместо традиционного эмпирического проектирования при правильном подходе может существенно сэкономить время и обеспечить высокое качество разрабатываемого программного продукта, а также обеспечить максимальный контакт заказчика и разработчика, что в условиях современного динамичного рынка играет решающую роль.
