
- •1. Аис и их классификация
- •2. Структурная и функциональная организация аис
- •3. Централизованный процесс обработки данных
- •4. Децентрализованный процесс обработки данных
- •5. Переход к распределенной обработке данных
- •6. Модель файлового сервера
- •7. Модель сервера базы данных
- •8. Модель сервера приложений
- •Хранение приложений на сервере
- •9. Распределенные базы данных Internet
- •10. Понятие жизненного цикла
- •Структурная схема терминов
- •11. Основные процессы жизненного цикла аис
- •12. Вспомогательные процессы жизненного цикла аис
- •13. Организационные процессы жизненного цикла аис
- •14. Стадии жизненного цикла
- •15. Модели жизненного цикла. Каскадные модели
- •16. Модели жизненного цикла. Спиральные модели
- •17. Основополагающие принципы создания аис
- •18. Стадии создания аис
- •19. Методологии и технологии проектирования аис
- •20. Сущность структурного подхода к проектированию аис
- •21. Проблема сложности больших систем
- •22. Технология sadt – общие сведения
- •Состав функциональной модели
- •23. Технология sadt – типы связей между функциями
- •24. Технология sadt – общая последовательность моделирования
- •25. Технология dfd - общие требования, состав диаграмм
- •26. Технология dfd - построение иерархии диаграмм
- •27. Технология dfd – общая последовательность моделирования
- •28. Технология erd – общее понятие
- •29. Технология erd – правила построения отношений (связей)
- •30. Технология erd – общая последовательность моделирования
24. Технология sadt – общая последовательность моделирования
Методология SADT (Structured Analisys and Design Technique) разработана Дугласом Т. Россом в 1969-73 годах. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения. IDEF0 (подмножество SADT) используется для моделирования бизнес-процессов в организационных системах и имеет развитые процедуры поддержки коллективной работы.
В терминах IDEF0 система представляется в виде комбинации блоков и дуг. Блоки представляют функции системы, дуги представляют множество объектов (физические объекты, информация или действия, которые образуют связи между функциональными блоками).
С дугами связываются метки на естественном языке, описывающие данные, которые они представляют. Дуги показывают, как функции системы связаны между собой, как они обмениваются данными и осуществляют управление друг другом. Выходы одной функции могут быть входами, управлением или исполнителями другой.
Дуги могут разветвляться и соединяться. Ветвление означает множественность (идентичные копии одного объекта) или расщепление (различные части одного объекта). Соединение означает объединение или слияние объектов.
Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 6 блоков.
На следующем рисунке представлена IDEF0-модель деятельности описанного выше предприятия.
Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы.
Обычно процесс разработки является итеративным и состоит из следующих условных этапов:
Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.
Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0- читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.