Методы и средства проектирования ис кратко

Обновлено: 17.05.2024

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

Методы проектирования ИС подразумевают использование определённых программных и аппаратных средств, составляющих инструментальные средства программирования ИС.

Метод проектирования включает совокупность трёх составляющих:

1) пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 4.1);

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

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

Рис. 4.1. Представление технологической операции проектирования.

Методы и средства проектирования ИС.

Классификация методов проектирования ИС:

1. По степени использования типовых проектных решений:

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

2. По характеру адаптации проектных решений:

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

- Методы параметризации (обеспечивают настройку проектных решений путем изменения параметров в программных модулях)

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

3. По степени автоматизации методы проектирования:

- Методы с универсальной компьютерной поддержкой (используют универсальные языки программирования, СУБД, табличные процессы)

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

Классификация технологий проектирования информационных систем.

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

- оформления проектной документации;

Стандарт проектирования должен устанавливать:

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

- комплектность, состав и структуру документации на каждой стадии проектирования;

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

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

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

- требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

- правила использования клавиатуры и мыши;

- правила оформления текстов помощи;

- правила обработки реакции пользователя.

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

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

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

Технологии индустриального проектирования подразделяются: типовые, автоматизированные.

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

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

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

В зависимости от метода декомпозиции, ИС, выбранного при построении ее модели различают: Функционально – ориентированные и объектно – ориентированные технологии автоматического проектирования.

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

Системное (предварительное, концептуальное) проектированиевключает в себя следующие стадии:

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

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

3) разработки описания системы в виде структур объекта проектирования и построения функциональных подсистем объекта;

4) формализация задач проектирования, в том числе формирование области поиска решений, систем предпочтений и ограничений, требований к объекту и т.п.

Результатом системного (концептуального) проектирования является разработка ТЗ и, при необходимости, технико-экономического обоснования.

Средства проектирования ЭИСвозможно разделить на: без использования ЭВМ и с использованием ЭВМ.

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

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

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

- Ко второму подклассу относят средства, поддерживающие проектирование отдельных компонентов проекта ЭИС. К данному подклассу относятся средства общесистемного назначения: Системы управления базами данными (СУБД); Методоориентированные пакеты прикладных программ (решение задач дискретного программирования, математической статистики и т.п.); Табличные процессоры; Статистические ППП; Оболочки экспертных систем; Графические редакторы; Текстовые редакторы;Интегрированные ППП (интерактивная среда с встроенными диалоговыми возможностями, позволяющая интегрировать вышеперечисленные программные средства).

- К третьему подклассу относятся средства, поддерживающие проектирование разделов проекта ЭИС. В этом подклассе выделяют функционально-ориентированные средства проектирования.

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

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

- К четвертому подклассу средств проектирования ЭИС относятся средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования. К данному классу относится подкласс средств автоматизации проектирования ЭИС (CASE-средства).

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

1) по охватываемым этапам процесса разработки ЭИС;

2) по степени интегрированности: отдельные локальные средства (tools), набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС (toolkit) и полностью интегрированные средства, связанные общей базой проектных данных – репозиторием (workbench).

На выбор средств могут существенно повлиять следующие особенности методологии проектирования:

· ориентация на создание уникального или типового проекта;

· итерационный характер процесса проектирования;

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

· жесткая дисциплина проектирования и разработки при их коллективном характере;

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

Критерии выбора

1. Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития.

2. Обеспечение целостности проекта и контроля за его состоянием.

3. Независимость от программно-аппаратной платформы и СУБД.

4. Поддержка одновременной работы групп разработчиков.

5. Возможность разработки приложений "клиент-сервер" требуемой конфигурации.

6. Открытая архитектура и возможности экспорта/импорта.

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

8. Простота использования.

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

10. Использование общепринятых, стандартных нотаций и соглашений.

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

© 2014-2022 — Студопедия.Нет — Информационный студенческий ресурс. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав (0.007)

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

Метод – процедура или техника генерации описаний компонентов ИС.

Так, по степени автоматизации методы проектирования разделяются на методы:

• ручного проектирования, при котором проектирование компонентов ЭИС осуществляется без использования специальных инструментальных программных средств, а программирование - на алгоритмических языках;

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

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

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

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

• реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);

• параметризации, когда проектные решения настраиваются (перегенерируются) в соответствии с изменяемыми параметрами;

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

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

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

· охватывать в совокупности все этапы жизненного цикла ЭИС;

· технически, программно и информационно совместимыми;

· простыми в освоении и применении;

Рис. 3. Классификация средств проектирования

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

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

1. относятся операционные средства, поддерживающие проектирование операций обработки информации. К данному подклассу средств относятся:

· библиотеки стандартных подпрограмм и классов объектов;

· макрогенераторы, генераторы программ типовых операций обработки данных;

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

· простейшие инструментальные средства проектирования (тестирования и отладки программ, поддержки процесса документирования проекта и т.п).

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

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

• системы управления базами данными (СУБД);

• методоориентированные пакеты прикладных программ (решение задач дискретного программирования, математической статистики и т.п.);

• оболочки экспертных систем;

• интегрированные ППП (интерактивная среда с встроенными диалоговыми возможностями, позволяющая интегрировать вышеперечисленные программные средства).

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

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

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

4. относятся средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования. К данному классу относится подкласс средств автоматизации проектирования ЭИС (CASE-средства). Современные CASE-средства, в свою очередь, классифицируются в основном по двум признакам:

1) по охватываемым этапам процесса разработки ЭИС;

2) по степени интегрированности: отдельные локальные средства (tools), набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС (toolkit) и полностью интегрированные средства, связанные общей базой проектных данных - репозиторием (workbench).

Метод – процедура или техника генерации описаний компонентов ИС.

Так, по степени автоматизации методы проектирования разделяются на методы:

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

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

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

· охватывать в совокупности все этапы жизненного цикла ЭИС;

· технически, программно и информационно совместимыми;

· простыми в освоении и применении;

Рис. 3. Классификация средств проектирования

· библиотеки стандартных подпрограмм и классов объектов;

· макрогенераторы, генераторы программ типовых операций обработки данных;

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

• системы управления базами данными (СУБД);

• оболочки экспертных систем;

1) по охватываемым этапам процесса разработки ЭИС;

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

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

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

организации,
требований к ИС,
проекта ИС,
требований к приложениям

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

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

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

формирование требований к системе,
проектирование,
реализация,
тестирование,
ввод в действие,
эксплуатация,
сопровождение

Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

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

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

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

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

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

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

выбор платформы (платформ)
выбор операционной системы (операционных систем) .

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

будет ли это архитектура "файл-сервер" или "клиент-сервер";
будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);.
будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

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

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

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

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

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

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

тесты функциональности
тесты надежности системы.

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

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

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

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

Сопровождение - может отсутствовать. То есть разработчик передал продукт заказчику, а затем не усовершенствует его, не контролирует работу.

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

General approaches to the design of information systems have been considered, conceptual modeling has been performed using the example of multichip module production control system. The feasibility of structural-functional and object-oriented approaches has been considered. As a result of simulation the class diagram has been obtained that makes possible the proceeding to the physical implementation of the system.

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

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

1 Общие подходы кпроектированию ИС.

Основные этапы проектирования ИС представлены в табл. 1.

Этап

Методы решения, характеристики

Разработка концептуальной модели ИС

Структурно-функциональное и/или объектно-ориентированное моделирование

Разработка логической модели ИС

Информационное моделирование (создание диаграммы сущность-связь)

Разработка физической модели и программного обеспечения ИС

Реализация объектов логической модели, разработка программного кода

Тестирование и отладка ИС

Корректировка программного обеспечения

Поддержка ИС после ввода в эксплуатацию

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

$F:\СЕР. статьи\Сережины статьи магистр архив\1.jpg$

Рис. 1. Этапы и методы проектирования ИС

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

2 Структурно-функциональное моделирование ИС.

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

На вход поступает пластина с кристаллами и корпус будущей микросхемы, на выходе получают готовое изделие или брак. В качестве документа управления выступает маршрутная карта ТП изготовления МКМ, в качестве механизмов — оборудование и оснастка, а также персонал участка сборки.

$C:\Users\admin\Desktop\ramka-a2-autocad-skachat Model (1).jpg$

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

$C:\Users\admin\Desktop\1-й уровень.jpg$

Рис. 3. Первый уровень декомпозиции ТП изготовления МКМ

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

Рис. 4. Дерево узлов ТП изготовления МКМ

3 Объектно-ориентированное моделирование ИС.

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

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

Рис. 6. Диаграмма классов ТП изготовления МКМ

Диаграмма классов отражает структуру базы данных, необходимую для создания физической модели и развёртывания ИС управления ТП изготовления МКМ.

Заключение.

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

Гамма Э., Хелм Р. Приемы объектно-ориентированного проектирования. Паттерны проектирования. М.: Изд-во Питер, 2016. – 366 с.
Рамбо Д., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. М.: Изд-во Питер, 2007. – 544 с.
Федоров Ю. Н. Справочник инженера по АСУТП: проектирование и разработка. М.: Изд-во Инфра-Инженерия, 2008 г. – 928 с.
Фаулер М. Архитектура корпоративных программных приложений. М.: Изд-во Вильямс, 2006. – 544 с.
Иванова Г. С. Технология программирования: учебник для вузов — 3-е изд., перераб. и доп. — М.: Изд-во МГТУ им. Н. Э. Баумана, 2006. — 334 с.
Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. М.: Изд-во Диалог-МИФИ, 2005. – 432 с.
Власов А. И., Лыткин С. Л., Яковлев В. Л. Краткое практическое руководство по языку PL/SQL. — М.: Изд-во Машиностроение — 2000. 64 с.

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

Похожие статьи

Разработка объектно-ориентированной модели процесса.

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

Анализ методов искусственного интеллекта САПР.

Рис. 1. Концептуально-абстрактная модель разработки экспертной системы.

На верхнем уровне декомпозиции (рисунок 2) работы экспертной системы представлена в общем виде (контекстная диаграмма в нотации IDEF0).

Модель подсистемы расчета налога на добычу полезных.

Концептуальное проектирование является первоначальным этапом разработки программного обеспечения (ПО).

Для моделирования потоков данных структурные методы DFD и IFD являются наиболее подходящими чем объектно-ориентированный метод UML.

Основные принципы и этапы моделирования информационных.

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

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

Анализ современных методов и программных средств.

1.Структуризация процесса проектирования, выражаемая декомпозицией проектных задач и документации, выделением стадий, этапов, проектных процедур.

информационные модели в виде диаграмм сущность-отношение, геометрические модели-чертежи.

Функциональное моделирование информационной системы.

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

На рисунке 2 представлена декомпозиция диаграммы верхнего уровня, отражающая проведение таких процедур как просвещение, диагностика и.

Моделирование технологических процессов производства.

Разработка концептуально-абстрактной модели.

Особенности разработки контекстной диаграммы структурно-функциональной модели.

Основные термины (генерируются автоматически): контекстная диаграмма, визуальное моделирование, IDEF, технологический.

Обучение объектно ориентированной парадигме.

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

Проектирование базы данных. Роль процесса в создании.

Именно о процессе проектирования базы данных, его особенностях, методах, этапах и

Её разработка начинается с построения инфологической модели (она обеспечивает

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

Разработка объектно-ориентированной модели процесса.

Анализ методов искусственного интеллекта САПР.

Рис. 1. Концептуально-абстрактная модель разработки экспертной системы.

Модель подсистемы расчета налога на добычу полезных.

Концептуальное проектирование является первоначальным этапом разработки программного обеспечения (ПО).

Основные принципы и этапы моделирования информационных.

Анализ современных методов и программных средств.

информационные модели в виде диаграмм сущность-отношение, геометрические модели-чертежи.

Моделирование технологических процессов производства.

Разработка концептуально-абстрактной модели.

Особенности разработки контекстной диаграммы структурно-функциональной модели.

Функциональное моделирование информационной системы.

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

Обучение объектно ориентированной парадигме.

Проектирование базы данных. Роль процесса в создании.

Именно о процессе проектирования базы данных, его особенностях, методах, этапах и

Её разработка начинается с построения инфологической модели (она обеспечивает

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

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

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

Необходимая платформа для ИС может формироваться из компонентов различных фирм производителей. Однако выбрать и сформировать разные средства, каждое из которых может являться одним из лидеров в своём классе, достаточно тяжело, а порой и нереально.

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

• характеристика предметной области;

• целей, потребностей и ограничений проекта ИС, включая квалификацию участвующих в процессе проектирования;

• используемой методологии проектирования.

Современные средства проектирования могут быть разделены на две большие группы. Первую группу составляют CASE-системы (как независимые, так и интегрированные с СУБД), которые обеспечивают проектирование БД и приложений в комплексе с интегрированными средствами разработки приложений "клиент-сервер" (например: Westmount I-CASE+Uniface, Designer/2000+Developer/2000). Их основное достоинство заключается в том, что они позволяют разрабатывать всю информационную систему полностью (функциональные спецификации, логику процессов, интерфейс с пользователем и базу данных), оставаясь в одной технологической среде. Инструменты этой категории, как правило, обладают высокой сложностью, широкой сферой применения и гибкостью.

Вторую группу составляют средства проектирования БД, реализующие ту или иную методологию, как правило, "сущность-связь" ("entity-relationship") и рассматриваемые в комплексе со средствами разработки приложений. К средствам этой категории можно отнести: SILVERRUN+JAM, ERwin/ERX+PowerBuilder и другие.

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

применяемым методологиям и моделям систем и БД;

степени интегрированности с СУБД;

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

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

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми средствами проектирования:

На рынке постоянно появляются как новые системы, так и новые версии и модификации систем (например, CASE/4/0, System Architect и т.д.).

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

Westmount I-CASE 3.2 (CADRE Technologies Inc.)

Westmount I-CASE представляет собой программный продукт, обеспечивающий выполнение следующих функций:

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

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

генерация кода программ на 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

программирование на языке C со встроенным SQL;

управление версиями и конфигурацией проекта;

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

экспорт и импорт данных проекта в формате CDIF.

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

Westmount I-CASE функционирует на всех основных UNIX-платформах и VMS. В качестве целевой СУБД могут использоваться ORACLE, Informix, Sybase и Ingres.

В качестве отдельного продукта поставляется интерфейс Westmount-Uniface Bridge, обеспечивающий совместное использование двух систем в рамках единой технологической среды проектирования (при этом схемы БД, структурные схемы программ и последовательности экранных форм непосредственно в режиме on-line, без создания каких-либо файлов экспорта- импорта, переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface, могут быть перенесены в репозиторий Westmount I-CASE. Возможные рассогласования между репозиториями двух систем устраняются с помощью специальной утилиты).

В рамках версии Westmount I-CASE 4.0 предполагается обеспечить возможность функционирования клиентской части в среде Windows 95, а серверной - в среде Windows NT.

Uniface 6.1 представляет собой среду разработки крупномасштабных приложений "клиент-сервер" и имеет следующую компонентную архитектуру:

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

Application Model Manager поддерживает прикладные модели, каждая из которых представляет собой подмножество общей схемы БД с точки зрения данного приложения.

Rapid Application Builder - средство быстрого создания экранных форм и отчетов на базе объектов прикладной модели. Оно включает графический редактор форм, средства прототипирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов управления (Open Widget Interface) для существующих графических систем - MS Windows (включая VBX), Motif, OS/2.

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

Deployment Manager (управление распространением приложений) - средства, позволяющие подготовить созданное приложение для распространения, установить и сопровождать его (при этом платформа пользователя может отличаться от платформы разработчика). В их состав входят сетевые драйверы и драйверы СУБД, сервер приложений (полисервер), средства распространения приложений и управления базами данных. Uniface поддерживает интерфейс практически со всеми известными программно- аппаратными платформами, СУБД, CASE-средствами, сетевыми протоколами и менеджерами транзакций.

Personal Series (персональные средства) - используются для создания сложных запросов и отчетов в графической форме, а также для переноса данных в такие системы, как WinWord и Excel.

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

Читайте также: