- •Предисловие
- •Глава 1. Основные понятия теории моделирования § 1.1. Термины моделирования
- •§ 1.2. Классификация видов моделирования
- •§ 1.3. Проблемы проектирования информационных систем
- •§ 1.4. Моделирование предметной области
- •§ 1.5. Три уровня анализа
- •§ 1.6. Набор типов моделей Объектная структура
- •Функциональная структура
- •Структура управления
- •Организационная структура
- •Техническая структура
- •Вопросы к главе 1
- •Глава 2. Концептуальные основы case-технологий § 2.1. Понятие case-технологии
- •§ 2.2. Проблемы внедрения case-технологий
- •§ 2.3. Общая характеристика case-средств
- •§ 2.4. Классификация case-средств
- •Вопросы к главе 2
- •Глава 3. Понятие и основные принципы функционального моделирования, обзор основных методологий.
- •§ 3.1. Технология структурного анализа и проектирования sadt
- •§ 3.2. Диаграммы потоков данных dfd (Data Flow Diagrams)
- •§ 3.3. Диаграммы потоков работ wfd (Work Flow Diagram)
- •§ 3.4. Семейство стандартов моделирования idef
- •§ 3.5. Основные элементы и понятия idef0
- •§ 3.6. Диаграммы "сущность-связь" erd (Entity-Relationchip diagram)
- •Вопросы к главе 3
- •Глава 4. Спецификации управления
- •§ 4.1. Диаграммы переходов состояний std (State Transition Diagrams)
- •§ 4.2. Особенности применения std диаграмм
- •§ 4.3. Структурные карты
- •§ 4.4. Структурные карты Константайна
- •§ 4.5. Структурные карты Джексона
- •§ 4.6. Характеристики хорошей модели реализации
- •4.6.1. Сцепление
- •4.6. 2. Связность
- •§ 4.7. Принципы проектирования, позволяющие построить качественную модель
- •§ 4.8. Транзакционный и трансформационный анализ или как получить структурные карты из диаграмм потоков данных
- •Вопросы к главе 4
- •Глава 5. Объектно-ориентированный подход к моделированию информационных систем § 5.1. Понятие объектно-ориентированного анализа
- •§ 5.2. Элементы объектно-ориентированной модели
- •§ 5.3. Объект и класс
- •§ 5.4. Язык моделирования uml
- •§ 5.5. Достоинства и недостатки объектно-ориентированного проектирования
- •Вопросы к главе 5
- •Глава 6. Метод имитационного моделирования
- •§ 6.1. Понятие имитационного моделирования
- •§ 6.2. Применение имитационного моделирования
- •§ 6.3. Виды имитационного моделирования
- •§ 6.4. Принципы и методы построения имитационных моделей
- •6.4.2. Принцип особых состояний
- •6.4.3. Основные методы имитационного моделирования.
- •Вопросы к главе 6
- •Глава 7. Инструментальные средства моделирования ис
- •§ 7.1. Российские программные продукты
- •7.1.1. Инталев: Корпоративный навигатор (инталев)
- •Бизнес-Инженер (Битек)
- •Case.Аналитик
- •§7.2. Зарубежные case - средства
- •7.2.3. Case-средство Silverrun
- •7.2.5. Case-средство Designer/2000
- •§ 7.3. Методология aris
- •7.3.1. Общие сведения о методологии aris
- •7.3.2. Архитектура aris
- •7.3.3. Обзор основных модулей
- •§ 7.4. Программные продукты имитационного моделирования
- •7.4.1. Система Arena
- •7.4.2. Пакет имитационного моделирования AnyLogic
- •Вопросы к главе 7
- •Библиографический список
- •Оглавление
§ 1.3. Проблемы проектирования информационных систем
Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях экономики. Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:
сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
необходимость интеграции существующих и вновь разрабатываемых приложений;
функционирование в неоднородной среде на нескольких аппаратных платформах;
разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть, прежде всего, адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. До сих пор существует мнение, что процесс разработки программ – это в большей степени искусство.
Надо отметить еще и то обстоятельство, что в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, а это еще больше усложняет разработку и сопровождение таких систем.
§ 1.4. Моделирование предметной области
Все это проблемы привели к пониманию того, что в основе проектирования ИС должно лежать моделирование предметной области.
Предметная область - это мысленно ограниченная область реальной действительности, подлежащая описанию или моделированию и исследованию.
Предметная область состоит из объектов, различаемых по свойствам и находящихся в определенных отношениях между собой или взаимодействующих каким-либо образом.
Для того чтобы получить адекватный предметной области проект информационной системы в виде совокупности правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы.
При этом под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области.
Обычный подход к анализу деятельности предприятия предполагает создание и анализ различных моделей (функциональных, процессных, информационных и др.). Разработка интегрированных систем управления предприятием (ИСУП) тоже начинается с анализа созданных моделей.
Но информационная система является системой комплексной автоматизации предприятия, поэтому особенностью её разработки является необходимость выполнения комплексного анализа, который требует использования множества разных типов моделей, отображающих различные стороны деятельности системы. При этом для обеспечения целостности процесса моделирования и анализа необходимо иметь возможность интеграции результатов моделирования в рамках общего проекта или общей модели[41].
Подход, основанный на моделях, предполагает, что разработка системы начинается с построения модели, описывающей систему с разных точек зрения. Это означает, что полная модель складывается из отдельных проекций, отражающих разные аспекты системы. Выбор проекций модели зависит от подхода к проблеме и принятых решений. Ключом к построению проекций является абстрагирование, когда сосредоточиваются на наиболее существенных деталях, игнорируя при этом остальные. В дальнейшем для краткости каждую проекцию мы будем называть моделью, указывая ее тип. Например, функциональная модель показывает, что делает система в ответ на запросы пользователя (но не как она это делает), логическая модель описывает основные сущности и отношения между ними.
Модели позволяют свести высокую сложность информационной системы до уровня, понимаемого человеком. Достигается это за счет иерархического принципа их построения и применения наглядной графической нотации.
Иерархия уровней описания системы дает возможность резко сократить количество элементов, которые должен анализировать человек. Каждая модель может быть выражена с разными уровнями детализации. При этом на верхних уровнях иерархии опускаются детали реализации, которые проявляются на более низких уровнях.
Построенные модели могут модифицироваться в течение всего жизненного цикла. Причин тому может быть много - изменения требований к системе, устранение ошибок, развитие системы, нахождение более удачных решений и т. д. При этом обязательно соблюдение соответствия между моделями и программными кодами.
Само же понятие "моделирование бизнес-процессов" пришло в быт большинства аналитиков одновременно с появлением на рынке сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании. Результатом этого обследование является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению "узких мест" в управлении деятельностью. На основании этого заключения, непосредственно перед проектом внедрения системы автоматизации, проводится так называемая реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная для компании. Это и естественно, сложившийся годами коллектив всегда сложно заставить "думать по-новому". Подобные комплексные обследования предприятий всегда являются сложными и существенно отличающимися от случая к случаю задачами. Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты[41].
Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области.
К моделям предметных областей предъявляются следующие требования:
формализация, обеспечивающая однозначное описание структуры предметной области;
понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;
реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;
обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.
Для реализации перечисленных требований, как правило, строится система моделей, которая должна отражать два аспекта функционирования предметной области: структурный аспект и оценочный аспект.
1. Структурный аспект предполагает построение:
объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;
функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;
структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;
организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;
технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.
