Особенности проектирования автоматизированных систем

Этапы проектирования

 

К проектированию АС непосредственное отношение имеют два направления деятельности:

1) собственно проектирование АС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки;

2) 2) проектирование упомянутых компонентов АС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных автомати­зированных систем.

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

Существует ряд фирм, специализирующихся на разработке проектов АС (например, Price Waterhouse, Jet Info, Consistent Software, Interface и др.)

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

Для каждого класса АС (САПР, ERP, геоинформационные системы и т. д.) можно указать фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Многие из них на основе одной из базовых технологий реализуют свой подход к созданию АС и придерживаются стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями третьих фирм.

В России действует государственный стандарт на стадии создания авто­матизированных систем ГОСТ 34.601-90. Существует и международный стандарт на стадии жизненного цикла программной продукции (ISO 12207:1995). Как собственно АС, так и компоненты АС являются сложными системами, и при их проектировании нужно использовать один из стилей проектирования:

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

· восходящее (Bottom-of-Design);

· эволюционное (Middle-of-Design).

Чаще всего применяют нисходящий стиль блочно-иерархического проек­тирования.

Рассмотрим этапы нисходящего проектирования АС.

Верхний уровень проектирования АС часто называют концептуальным проектированием. Концептуальное проектирование выполняют в процессе предпроектных исследований, формулировки ТЗ, разработки эскизного проекта и прототипирования (согласно ГОСТ 34.601-90, эти стадии называют формированием требований к АС, разработкой концепции АС и эскизным проектом).

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

На основе анализа результатов обследования строят модель, отражающую деятельность предприятия на данный момент (до реорганизации). Такую мо­дель называют «As Is» (как есть). Далее разрабатывают исходную концепцию АС. Эта концепция включает в себя предложения по изменению структуры предприятии, взаимодействию подразделений, информационным потокам, что выражается в модели «То Be» (как должно быть).

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

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

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

При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают модели преобразования, хранения и пере­дачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки АС модели, как правило, претерпевают существенные изменения (переход от «As Is» к «То Be») и в окончательном виде модель «То Be» рассматривают в качестве модели проектируемой АС.

Различают функциональные, информационные, поведенческие и структур­ные модели.

· Функциональная модель системы описывает совокупность вы­полняемых системой функций. Информационная модель отражает структу­ры данных - их состав и взаимосвязи.

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

· Структурная модель характеризует морфологию сис­темы (ее построение) - состав подсистем, их взаимосвязи.

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

 

Открытые системы

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

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

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

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

Аспекты открытости отражены в стандартизации:

· API (Application Program Interface ) - интерфейсов прикладных программ с операционным окружением, в том числе системных вызовов и утилит операционной системы (ОС), т. е. связей с ОС;

· межпрограммного интерфейса, включая языки программирования;

· сетевого взаимодействия;

· пользовательского интерфейса, в том числе средств графического взаимо­действия пользователя с ЭВМ;

· средств защиты информации.

Стандарты, обеспечивающие открытость ПО, в настоящее время разрабатываются такими организациями, как ISO (International Standard Organization), IEEE (Institute of Electrical and Electronics Engineers), EIA (Electronics Industries Association) и др.

Стандарты POSIX (Portable Operating System Interface) предназначены для API и со­ставляют группу стандартов IEEE 1003. В этих стандартах содержатся перечень и правила вызова интерфейсных функций, определяются способы взаимодействия прикладных программ с ядром ОС на языке С (что означает преимущественную ориентацию на ОС Unix), даны расширения для взаимодействия с программами на других языках, способы тестирования интерфейсов на соответствие стандартам POSIX, правила административ­ного управления программами и данными и т. п.

Ряд стандартов ISO посвящен языкам программирования. Имеются стандарты на языки С (ISO 9899 ), Fortran (ISO 1539), Pascal (ISO 7185) и др.

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

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

Так, в профилях АС могут фигурировать язык Express стандарта STEP, спецификация графического пользовательского интерфейса Motif, унифицированный язык SQL обме­на данными между различными СУБД, стандарты сетевого взаимодействия, в профили MCAD может входить формат IGES и в случае ECAD - формат EDIF и т. п.

 

Упражнения и вопросы для самоконтроля

1. Дайте определение понятия «проектирование».

2. Что является предметом изучения в теории систем?

3. Назовите признаки, присущие сложной системе.

4. Приведите примеры иерархической структуры технических объектов, их внутрен­них, внешних и выходных параметров.

5. Приведите примеры условий работоспособности.

6. Почему проектирование обычно имеет итерационный характер?

7. Назовите основные стадии проектирования технических систем. Чем обусловлено прототипирование?

8. Дайте характеристику этапов жизненного цикла промышленной продукции.

9. Назовите основные типы промышленных АС и виды их обеспечения.

10. Какие причины привели к появлению и развитию CALS-технологий?

11. Что понимают под комплексной АС?

12. Дайте определение профиля открытой системы.

13. Чем обеспечивается открытость систем?

Лекция 3

 

ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ