Юридические адреса, реквизиты и подписи Сторон

Исполнитель________________________

Клиент_____________________________

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

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

Этап написания контента возлагается на специалистов по предметной области (маркетологов, менеджеров по продажам, товароведов и др.).

При написании контента должны быть предусмотрены такие ключевые слова, которые улучшают поиск сайта в поисковых системах (Search Engine Optimization, SEO).

Этап дизайна и верстки предполагает использование графических редакторов, прежде всего, растравой графики, а также 3D-графики. Среди редакторов растровой графики первое место по распространнености занимает Adobe Photoshop, а среди пакетов векторной графики Adobe Illustrator и Corel Draw. Используются программы 3D-графики (например, Autodesk 3DS Max), а также программные системы для представления информации в формате PDF для off-line просмотра (Adobe Acrobat).

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

· несоответствие фирменному стилю и рекламной стратегии;

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

· пестрые схемы;

· трудночитаемый текст.

Верстальщик должен обеспечить работу сайта с целым рядом браузеров (Internet Explorer, Firefox, Chrome, Opera и др.), т. е. так называемую кроссбраузерность.

Стадия программирования предназначена для создания «внутренней начинки» сайта, той, которая не видна посетителю страниц.

Начинается эта стадия с разработки базы данных, содержащей информатизацию, размещаемую на страницах сайта. В качестве СУБД для сайта получил распространение MySQL благодаря невысокой цене. Однако при большой интенсивности запросов к базе данных приходится использовать более мощные системы (например, Microsoft SQL Server, Oracle и др.).

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

Страницы сайта могут быть статичным набором файлов на языке HTML или же создаваться специальной компьютерной программой на сервере («движком» сайта). Движок может быть сделан на заказ индивидуально для сайта или же быть типовым (CMS).

Существует целый ряд средств для разработки таких программ, к числу которых относятся: PHP, Perl, ASP и др.

После завершения программирования и начального тестирования созданный сайт размещается на web-сервере предприятия или провайдера, чтобы пройти этап открытого тестирования.

Сайту присваивается адрес (доменное имя). Для размещения сайта в интернет доменное имя должно быть зарегистрировано. В России регистрация доменов в зоне .ru занимается специализированная организация RIPN (www.ripn.net)

Требования к доменному имени очевидны:

· имя должно легко запоминаться;

· быть достаточно коротким;

· быть простым в написании во избежание ошибок при его наборе;

· легко произносимым;

· содержать название предприятия либо обозначать сферу его деятельности.

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

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

Вопросы для самопроверки по главе 3

1. Укажите связь реинжиниринга бизнес-процессов с созданием интегрированной информационной системы.

2. Дайте классическое определение реинжиниринга бизнес-про­цессов.

3. Перечислите основные принципы реинжиниринга.

4. Назовите состав функциональных подсистем интегрированной системы.

5. Укажите цель интеграции функциональной части.

6. В чем состоит интеграция информационного, программного, технического, организационного обеспечения?

7. Перечислите основные требования к корпоративным интегрированным информационным системам.

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

9. Охарактеризуйте взаимосвязь основных элементов программного интерфейса CORBA.

10. Охарактеризуйте традиционную технологию использования драйверов ODBC.

11. Охарактеризуйте технологию связи с разнородными базами данных с использованием сервера ODBC.

12. Дайте определение программных продуктов класса Workflow.

13. Дайте определение бизнес-процесса.

14. Что представляет собой автоматизированное рабочее место?

15. Назовите синонимы АРМ.

16. Перечислите основные функции АРМ руководителя, APM секретаря, APM специалиста.

17. Охарактеризуйте разновидности архитектуры распределенных информационных систем.

18. Что представляет собой архитектура сервисно-ориентированной информационной системы?

19. Перечислите преимущества сервисно-ориентированной архитектуры.

20. Дайте определение корпорации.

21. Охарактеризуйте структуру предприятия типа «Динамическая сеть».

22. Назовите факторы интеграции хозяйствующих субъектов в состав электронного предприятия.

23. В чем состоят преимущества виртуальной корпорации перед традиционной?

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

25. Перечислите состав команды разработки коммерческого web-сайта предприятия.

26. Назовите ключевые показатели качества web-сайта.

27. Укажите состав и последовательность этапов проектирования web-сайта.

Глава 4. АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ
ИНФОРМАЦИОННЫХ СИСТЕМ

Цель изучения данной главы – получить знания и умения автоматизированного проектирования информационных систем с использованием CASE-технологий.

В результате изучения данной главы обучающийся должен:

· знать основные принципы и факторы эффективности CASE-тех­но­логий;

· знать особенности функционально-ориентированного и объектно-ориентированного подходов в проектировании;

· знать содержание RAD-технологии программного создания приложений;

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

4.1. Основные принципы CASE-технологии

Аббревиатура CASE (Computer-Aided System Engineering) означает проектирование системы на основе компьютерной поддержки. Такое проектирование называется CASE-технологией проектирования.

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

Область применения CASE-технологий относится к созданию, прежде всего, экономических ИС, что объясняется массовостью этих систем.

Существует несколько принципов CASE-технологии. Рас­смот­рим основные из них.

1. Принцип всесторонней компьютерной поддержки проекти­рования. CASE-технология – это разновидность систем автома­ти­зированного проектирования(САПР) в области создания инфор­мационных систем.

2. Принцип модельного подхода – это может быть мето­до­логия функционально-ориентированного подхода или методология объектно-ориентированного подхода.

3. Иерархическое представление модели предметной области. Существуют плоские модели, предусматривающие представление всей модели в виде единого листа. Но когда встречаются сложные системы, то возникают определенные трудности. Преодолеть эти трудности позволяют иерархические модели, в которых пре­дусмот­рена иерархическая последовательность детализации (де­ком­позиции) описания системы. Эти модели соответствуют прин­ципу проектирования «сверху-вниз», от общего к частному.

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

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

Поэтому CASE-технология предусматривает четырехуров­не­вую парадигму проектирования:

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

Рис. 4.1. Последовательность стадий и этапов создания ИС
на основе CASE-технологии

6. Перенесение трудоемкости разработки в большей степени на анализ и проектирование. Известно, что ошибки на по­сле­дующих стадиях труднее исправить, причем трудности вырастают на порядок. Поэтому CASE-технологии проектирования предусмат­ривают особенно тщательную проработку стадии ана­лиза и про­ектирования. Здесь строятся модели AS IS и TO BE.

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

8. Возможность как прямого, так и обратного проектирования (формирование моделей и спецификаций на основе анализа про­граммных кодов и схем баз данных).

9. Использование репозитория – хранилища проектных дан­ных, представляющего собой центральный компонент CASE-средства (см. 6.3).

4.2. Факторы эффективности CASE-технологии

Эффективность применения CASE-технологии проектирова­ния ИС проявляется в повышении качества создаваемого проекта, сокращении стоимостных и временных затрат на всех стадиях жиз­ненного цикла ИС (рис. 4.2).

Рис. 4.2. Факторы эффективности CASE-технологии

Рассмотрим факторы эффективности CASE-технологии.

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

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

3. Наличие формализованной модели системы создает воз­можность для многовариантного анализа с прототипированием и ориентировочной оценкой эффективности вариантов. CASE-мо­де­ли позволяют осуществлять функционально-стоимостной анализ (Acti­vity-Based Costing, ABC) для выявления и исследования стоимости выполнения той или иной функции. Анализ прототипа системы позволяет скорректировать будущую систему до того, как она будет реализована в окончательном виде. Этот подход ускоряет и удешевляет создание системы.

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

5. Закрепление в формализованном виде требований к системе избавляет проектировщиков от необходимости многочисленных корректировок по новым требованиям пользователей.

6. Отделение проектирования системы от программирования создает устойчивость проектных решений для реализации на разных программно-технических платформах.

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

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

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

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

4.3. Функционально-ориентированный подход
в проектировании

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

К числу известных методов функционально-ориентированного проектирования относятся: метод функционального моделирования IDEFO, известный также как метод структурного анализа и разра­ботки (Structured Analysis and Design Technique – SADT), метод описания бизнес-процессов IDEF 3 и метод построения диаграмм потоков данных (DFD). Все эти методы входят в семейство стан­дартов IDEF (Integrated Definition).

Функционально-ориентированный подход в проектировании рассмотрим на примере метода построения диаграмм потоков дан­ных (Data Flow Diagrams, DFD).

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

Модель системы должна включать в себя:

· функциональную часть системы (функциональную модель);

· отношения между данными (информационную модель);

· переходы состояния системы при работе в реальном вре­мени.

Для моделирования информационной системы в трех указан­ных аспектах используются соответственно три разновидности графических средств с определенными нотациями, а именно:

· диаграммы потоков данных – DFD (Data Flow Diagrams). Они используются совместно со словарями данных и специфика­циями процессов;

· диаграммы «сущность–связь» – ERD (Entity Relationship Diagrams), показывающие отношения между данными;

· диаграммы переходов состояний – STD (State Transiting Dia­grams) для отражения зависящего от времени поведения системы (в режиме реального времени).

Ведущая роль в моделировании принадлежит DFD.

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

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

Таблица 4.1

Символы диаграмм потоков данных

Символы DFD	Нотация Гейна-Сарсона	Нотация Йордана
Поток данных
Процесс обработки
Хранилище
Внешняя Сущность     Туннель	[ ]	[ ]

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

· текстовое описание;

· естественный структурированный язык;

· таблицы решений;

· деревья решений;

· визуальные языки;

· языки программирования.

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

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

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

Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моде­лью данных ERD. В случае работы системы в реальном времени DFD дополняется STD. Иерархическая структура CASE-модели представлена на рис. 4.3.

Построение иерархической диаграммы потоков данных начи­нается с контекстных диаграмм.

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

Рис. 4.3. Иерархическая структура диаграммы потоков данных

Таким образом, контекстная диаграмма имеет форму звезды.

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

Рис. 4.4. Контекстная диаграмма потоков данных АРМ склада материалов

Рис. 4.5. Детализация диаграммы потоков данных

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

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

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

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

Признаками завершения детализации обычно являются:

· наличие у детализированного процесса небольшого числа входных и выходных потоков информации;

· наличие единой функции, т. е. одной задачи, которую ре­шает процесс;

· возможность лаконичного описания процесса на одной стра­нице (мини-спецификация должна содержать до 30 строк).

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

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

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

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

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

4.4. Объектно-ориентированный подход в проектировании

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

Среди свойств объектов в объектно-ориентированном подходе отметим следующие:

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

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

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

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

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

Модель проектирования ИС на основе объектно-ориентиро­ванного подхода представлена на рис. 4.7.

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

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

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

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

Рис. 4.7. Эволюционная модель проектирования информационной системы

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

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

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

Рис. 4.8. Зависимость эффективности применения
функционально-ориентированного и объектно-ориентированного подходов от количества выполненных проектов

Рис. 4.9. Зависимость времени разработки проекта при функционально-ориетированном и объектно-ориентированном подходах
от количества выполненных проектов

4.5. Содержание RAD-технологии
прототипного создания при­ложений

RAD-технологии (Rapid Application Development) – это техно­логии быстрого создания приложений на основе прототипирования и использования графического пользовательского интерфейса GUI (Graphical User Interface).

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

Основа этой технологии – спиральная модель создания ИС (рис. 4.10).

Рис. 4.10. Спиральная модель проектирования на основе RAD-технологии

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

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

1. Анализ – стадия, на которой исследуется предметная область.

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

3. Программирование – стадия, на которой пишется машин­ный код и выпускается очередной «прототип» заказанной системы с полной документацией.

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

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

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

Рассмотрим классификацию методов построения моделей бизнес-процессов, для автоматизированного проектирования на ос­нове CASE-средств.

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

Методы построения моделей бизнес-процессов, прежде всего, следует подразделить в соответствии с методологией моделирова­ния на методы функционально-ориентированной методологии и объектно-ориентированной методологии рис. 4.11.

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

Модели объектно-ориентированного моделирования примени­тельно к представлению бизнес-процессов на основе языка UML представлены двумя диаграммами: прецедентов использования и деятельности.

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

4.6.1. Метод функционального моделирования IDEF0

Этот метод известен также как метод структурного анализа и разработки (Structured Analysis and Design Techniqe, SADT). Метод используется на начальной стадии работы над проектом и дает ук­рупненное представление о бизнес-процессе. Работы на диаграмме IDEF0 располагаются в порядке доминирования – с левого верхнего угла диаграммы к правому нижнему. В левом верхнем углу разме­щается работа, выполняемая первой. Ступенчатое расположение операций уменьшает количество пресечений интерфейсных дуг на модели. На рис. 4.12 представлены возможные четыре типа интер­фейсных дуг в IDEF0. Основные символы метода IDEF0 представ­лены в табл. 4.2.

Управление

Вход Выход

Механизм исполнения

Рис. 4.12. Назначение интерфейсных дуг в методе IDEF0

Таблица 4.2