Title: Лекция 4
Author: Клецова ТВ
Last saved by: USER
Company: organization

Лекция 4.
Системный подход к проектированию ИС. Структурные методы анализа и проектирования ИС. Объектно-ориентированная методика проектирования ИС. Cравнение объектно-ориентированного и структурного подхода. Модели деятельности предприятия. Проведение обследования. Общие принципы моделирования.

4.1. Системный подход к проектированию ИС 

Методологическую основу проектирования ПО составляет системный подход. Под словом «система» понимается совокупность взаимодействующих компонентов и взаимосвязей между ними. Весь мир можно рассматривать как сложную взаимосвязанную совокупность естественных и искусственных систем. Это могут быть достаточно сложные системы (например, планеты в составе Солнечной системы), системы средней сложности (космический корабль) или сверхсложные системы (системы молекулярных взаимодействий в живых организмах). Искусственные системы, к которым относится ПО, по своей сложности, как правило, занимают среднее положение. Например, всемирная телефонная сеть содержит десятки или даже сотни тысяч переключателей, однако количество взаимодействий этих переключателей не идет ни в какое сравнение с количеством взаимодействий молекул даже в небольшом стакане воды. С точки зрения общей теории систем такие системы обычно рассматриваются как системы средней сложности.
Системный подход — это методология специального научного познания и социальной практики, а также объяснительный принцип, в основе которого лежит исследование объектов как систем.
Методологическая специфика системного подхода определяется тем, что он ориентирует исследование на:
•	раскрытие целостности объекта и обеспечивающих его механизмов;
•	выявление многообразных типов связей сложного объекта;
•	сведение этих связей в единую теоретическую картину.
Системный подход реализует представление сложного объекта в виде иерархической системы взаимосвязанных моделей, позволяющих фиксировать целостные свойства объекта, его структуру и динамику.
Системный анализ — совокупность методологических средств, используемых для подготовки и обоснования решений по сложным проблемам социального, технического и экономического характера. Он основывается на системном подходе, а также на ряде математических дисциплин и современных методов управления. Основной процедурой системного анализа является построение обобщенной модели, адекватно отображающей интересующие исследователя свойства реальной системы и ее взаимосвязи.
Основополагающая концепция состоит в построении при помощи графических методов системного анализа совокупности моделей различных аспектов деятельности организации, которые дают возможность управленцам и аналитикам получить ясную общую картину бизнес-процессов.
Принципы системного анализа (слайд 2):
•	Оптимальность - в результате анализа необходимо найти оптимальное решение задачи.
•	Эмерджентность - чем больше система и чем больше различие между частью и целым, тем выше вероятность того, что свойства целого могут сильно отличаться от свойств его частей. Принцип эмерджментности позволяет выявить несовпадение локальных оптимумов целей системы с глобальным оптимумом системы. Этот фактор необходимо учитывать при проведении системного анализа деятельности организации, поскольку он играет важную роль. 
•	Системность - исследование объекта, с одной стороны, как единого целого, а с другой, как части более крупной системы, с которой объект находится в определенных отношениях.
•	Иерархичность - определение в системе структурных отношений, характеризуемых упорядоченностью, организованностью взаимодействий между отдельными ее уровнями по вертикали. Большинство организаций представляют собой сложные системы, и необходимость иерархического построения этих систем обусловлена тем, что управление в них связано с переработкой и использованием больших объемов информации.
•	Интеграция - изучение интеграционных свойств и закономерностей системы. 
•	Формализация -  получение комплексных количественных характеристик.
Главной задачей системного анализа является поиск путей по превращению сложного в простое, по разложению труднопонимаемой задачи на ряд задач, имеющих решение.
Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй», иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие «правильная» по отношению к декомпозиции означает следующее (слайд 3):
•	количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности»;
•	связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления».
Существуют два основных подхода к декомпозиции систем (слайд 3). Первый подход называют функционально-модульным, он является частью более общего структурного подхода. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход, использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.

4.2. Структурные методы анализа и проектирования ИС 

Методология структурного анализа и проектирования ПО определяет руководящие указания для оценки и выбора проекта разрабатываемого ПО, шаги работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов. Структурные методологии предлагают методику трансляции проектных спецификаций в модель реализации, в дальнейшем используемую при кодогенерации.
Структурные методы являются строгой дисциплиной системного анализа и проектирования. Структурные методологии жестко регламентируют фазы анализа требований и проектирования спецификаций. Методы структурного анализа и проектирования стремятся преодолеть сложность больших систем путем расчленения их на части («черные ящики») и иерархической организации этих «черных ящиков». Выгода в использовании «черных ящиков» заключается в том, что их пользователю не требуется знать, как они работают, необходимо знать лишь их входы и выходы, а также назначение (т.е. функции, которые они выполняет).
Таким образом, первым шагом упрощения сложной системы является ее разбиение на «черные ящики», при этом такое разбиение должно удовлетворять следующим критериям:
•	каждый «черный ящик» должен реализовывать единственную функцию системы;
•	функция каждого «черного ящика» должна быть легко понимаема независимо от сложности ее реализации;
•	связь между «черными ящиками» должна вводиться только при наличии связи между соответствующими функциями системы
•	связи между «черными ящиками» должны быть простыми, насколько это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов, является идея иерархии. Для понимания сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур. 
Кроме того, структурные методы широко используют визуальное моделирование, служащее для облегчения понимания сложных систем.
Структурным анализом принято называть метод исследования системы, начинающий с ее общего обзора, который затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно:
•	разбиение системы на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6—7);
•	ограниченный контекст, включающий лишь существенные на каждом уровне детали;
•	использование строгих формальных правил записи;
•	последовательное приближение к конечному результату.
Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Принципами структурного подхода являются (слайд 4):
•	принцип «разделяй и властвуй» — принцип решения трудных проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения;
•	принцип иерархического упорядочения — принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
•	принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;
•	принцип формализации – применение строго методического подхода к решению проблемы;
•	принцип упрятывания – упрятывание несущественной на конкретном этапе информации: каждая часть «знает» только необходимую ей информацию;
•	принцип концептуальной общности – следование единой философии на всех этапах ЖЦ (структурный анализ – структурное проектирование – структурное программирование – структурное тестирование);
•	принцип полноты – контроль за присутствием лишних элементов
•	принцип непротиворечивости — обоснованность и согласованность элементов системы;
•	принцип логической независимости – концентрация внимания на логическом проектировании для обеспечения независимости от физического проектирования;
•	принцип независимости данных – модели должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения;
•	принцип структурирования данных — данные должны быть структурированы и иерархически организованы;
•	принцип доступа конечного пользователя – пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
В структурном анализе основным методом разбиения на уровни абстракции является функциональная декомпозиция, заключающаяся в декомпозиции (разбиении) системы на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те — на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.
Определим ключевые понятия структурного анализа (слайд 5) .
Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.
Функция – совокупность операций, сгруппированных по определенному признаку. 
Бизнес-процесс — связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя. 
Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя.
Бизнес-модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия. 
В структурном анализе и проектировании используются различные модели, описывающие:
•	функции, которые система должна выполнять;
•	процессы, обеспечивающие выполнение указанных функций;
•	данные, необходимые при выполнении функций, и отношения между этими данными;
•	организационные структуры, обеспечивающие выполнение функций;
•	материальные и информационные потоки, возникающие в ходе выполнения функций.
Модель — это совокупность символов (математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними.
Модель – это абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.
Модель является лишь одним из многих возможных толкований системы. Это толкование должно устраивать пользователя в данной ситуации, в данный момент времени. Для модели в общем случае характерны четыре свойства:
•	уменьшенный масштаб (размер) модели, точнее, ее сложность, степень которой всегда меньше, чем у оригинала. При построении модели сознательно вводятся упрощения; 
•	сохранение ключевых соотношений между разными частями;
•	работоспособность, т.е. возможность в принципе работать, как оригинал-моделируемый объект (во всяком случае, похожим образом);
•	адекватность действительным свойствам оригинала (степень достоверности).
Важно также подчеркнуть, что любая модель отражает точку зрения той или иной группы проектировщиков. Каждой модели присущи свои цели и задачи, и поэтому объект бизнеса, представляющий собой сложный комплексный организм, как правило, описывается некоторым набором моделей, в совокупности образующих общую модель данной бизнес-системы.
Нотации — система условных обозначений, принятая в конкретной модели.
Средства — аппаратное и программное обеспечение, реализующее выбранную методологию, в том числе построение соответствующих моделей с принятой для них нотацией.
Среди многообразия средств, предусмотренных для проведения структурного анализа, наиболее часто и эффективно применяются (слайд 6):
•	DFD (Data Flow Diagrams) — диаграммы потоков данных в нотациях Гейна-Сарсона, Йордона-Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;
•	 STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда-Меллора для проектирования систем реального времени;
•	ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена и Баркера;
•	структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;
•	FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;
•	SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования;
•	семейство IDEF (Integration Definition for Function Modeling):
Современные структурные методологии анализа и проектирования классифицируются по следующим признакам:
•	по отношению к школам - Software Еngineering (SE) и Information Engineering (IЕ); 
•	по порядку построения модели - процедурно-ориентированные, ориентированные на данные и информационно-ориентированные; 
•		по типу целевых систем - для систем реального времени (СРВ) и для информационных систем (ИС). 
SE является нисходящим поэтапным подходом к разработке ПО, начинающейся с общего взгляда на его функционирование. Затем про изводится декомпозиция на подфункции и  процесс повторяется для подфункций до тех пор пока  они не станут достаточно малы для их реализации кодированием. В результате получается иерархическая, структурированная, модульная программа. SE является универсальной дисциплиной разработки ПО, успешно применяющейся как при разработке систем реального времени,  так и при разработке информационных систем.
IE более новая дисциплина. Она имеет более широкую область применения, чем SE: IE является дисциплиной построения систем вообще, а не только систем ПО, и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны, IE более узкая дисциплина, чем SE, т.к. IE используется только для построения информационных систем, а SE - для всех типов систем. 
Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, как часть IE-дисциплины, отличается от подхода, ориентированного на данные, тем, что позволяет работать с неиерархическими структурами данных. 
Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реагирование на эти события во времени - основная и первоочередная функция таких систем. Главные отличия информационных систем от систем реального времени приведены на слайде 7, средствами поддержки этих особенностей и различаются соответствующие структурные методологии. 
На  слайде 8 классифицированы наиболее часто используемые методологии в соответствии с вышеперечисленными признаками 
Во всех перечисленных методологиях проектирования информационных систем в различных комбинациях используются приведенные на слайде 9  техники структурных диаграмм. 
Необходимо отметить что для проектирования систем реального времени используются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, контекстные графы, матрицы состояний/событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для проектирования информационных систем. Более того, известные методологии проектирования систем реального времени (в частности, методологии Хатли и Уорда-Меллора) базируются на перечисленных методологиях проектирования информационных систем, расширяя их соответствующими диаграммными техниками. 

4.3. Объектно-ориентированная методика проектирования ИС 

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

4.4. Сравнение объектно-ориентированного и структурного подхода 

Сравнительная таблица приведена на слайде 11. 
1.Функциональные методики рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. 
Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение.
Основное отличие функциональной методики от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных — помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия выполнения процессов обработки информации, которые динамически могут изменяться.
Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи. 
2. Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу "сверху-вниз", когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС. 
При объектно-ориентированном подходе изменяется принцип проектирования ИС. Сначала выделяются классы объектов, а далее в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы.

3. При выборе методики моделирования предметной области обычно в качестве критерия выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) — объектно-ориентированные модели.
4. Объектная модель естественна, поскольку ориентированна на человеческое восприятие мира, но менее наглядны. Функциональная модель лучше систематизирована, т.к. ей присуща процедурная строгость декомпозиции ИС.
5. Функциональные методики в целом лучше дают представление о существующих функциях в организации, о методах их реализации, причем чем выше степень детализации исследуемого процесса, тем лучше они позволяют описать систему. Под лучшим описанием в данном случае понимается наименьшая ошибка при попытке по полученной модели предсказать поведение реальной системы. На уровне отдельных рабочих процедур их описание практически однозначно совпадает с фактической реализацией в потоке работ. На уровне общего описания системы функциональные методики допускают значительную степень произвола в выборе общих интерфейсов системы, ее механизмов и т.д., то есть в определении границ системы.
Объектный подход позволяет хорошо описать систему на уровне общего описания системы, т.к. он основан на понятии сценария использования. Ключевым является понятие о сценарии использования как о сеансе взаимодействия действующего лица с системой, в результате которого действующее лицо получает нечто, имеющее для него ценность.
6. При объектно-ориентированном подходе проектировщик сосредоточивается на тех функциях системы, которые оправдывают ее существование. Однако и в этом случае задача определения границ системы, выделения внешних пользователей является сложной.
Технология потоков данных легко решает проблему границ системы, поскольку позволяет за счет анализа информационных потоков выделить внешние сущности и определить основной внутренний процесс. Однако отсутствие выделенных управляющих процессов, потоков и событийной ориентированности не позволяет предложить эту методику в качестве единственной.
7. Объектная декомпозиция дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. 
В функциональных моделях при большом количестве уровней декомпозиции модель может быть большой.
8. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей. В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам (полиморфизм) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с функциональным подходом значительно выше.
Функциональные модели, как правило, не пригодны для повторного использования.
9. К недостаткам объектно-ориентированного подхода относятся высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух–трех проектов и накопления повторно используемых компонентов. Структурный подход не требует высоких начальных затрат
10. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.

4.5. Модели деятельности предприятия 

Модели деятельности предприятия (бизнес-процессы) обычно строятся на этапе обследования предприятия в следующих двух видах (слайд 12):
•	модели "как есть", представляющей собой "снимок" положения дел на предприятии (оргштатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования и позволяющей понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации;
•	модели "как должно быть", интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия.
Каждая из моделей включает в себя полную структурную функциональную модель деятельности (например, в виде иерархии диаграмм потоков данных с разработанными для всех процессов нижнего уровня подробными их спецификациями на структурированном естественном языке или в виде иерархии SADT-диаграмм), информационную модель (как правило, с использованием нотации "сущность-связь"), а также, в случае необходимости, событийную (описывающую поведение) модель (с использованием диаграмм переходов состояний).
Переход от модели "как есть" к модели "как должно быть" осуществляется следующими двумя способами.
1)	Совершенствование технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость    выполнения     отдельных     задач     бизнес-процесса,     степень загруженности сотрудников ("легкий" реинжиниринг).
2)	Радикальное изменение технологий и переосмысление бизнес-процессов ("жесткий" реинжиниринг). Например, вместо попыток улучшения бизнес-процесса проверки кредитоспособности клиента, может быть следует задуматься, а нужна ли вообще такая проверка? Возможно затраты на такие проверки каждого из клиентов во много раз превышают убытки, которые может понести компания в отдельных случаях недобросовестности (в случае, когда клиентов много, а суммы закупок незначительны)!
Построенные модели являются не просто реализацией начальных этапов разработки системы и техническим заданием на последующие этапы. Они представляют собой самостоятельный отделяемый результат, имеющий большое практическое значение, в частности:
•	Модель "как есть" включает в себя существующие неавтоматизированные технологии, работающие на предприятии. Формальный анализ этой модели позволит выявить узкие места в технологиях и предложить    рекомендации    по    их    улучшению    (независимо    от    того, предполагается на данном этапе автоматизация предприятия или нет).
•	Она позволяет осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности предприятия (так как ее технология содержится в модели) с использованием диаграмм (известно, что "одна картинка стоит тысячи слов").
•	С ее помощью можно осуществлять предварительное моделирование нового направления деятельности с целью выявления новых потоков данных, взаимодействующих подсистем и бизнес-процессов.

4.6. Проведение обследования 

Обследование является важнейшим и определяющим этапом, на его основе строятся модели деятельности предприятия
В качестве исходной информации при проведении обследования и выполнении дальнейших этапов служат: 
•	данные по оргштатной структуре предприятия; 
•	информация о принятых технологиях деятельности; 
•	стратегические цели и перспективы развития; 
•	результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена); 
•	предложения сотрудников по усовершенствованию бизнес-процессов предприятия; 
•	нормативно-справочная документация; 
•	данные по имеющимся на предприятии средствам и системам автоматизации; 
•	опыт системных аналитиков в части наличия типовых решений. 
При проведении обследования целесообразно применять следующие методы (слайд 13): анкетирование, сбор документов, интервьюирование. 
Анкетирование является начальным этапом обследования и предваряет выезд группы системных аналитиков на предприятие. Анкеты позволяют составить грубое представление о деятельностях предприятия, что позволит спланировать первоначальное распределение работ группы аналитиков. Анкеты должны рассылаться руководителям структурных подразделений и содержать графы для идентификации фамилии и должности анкетируемого, отдельно излагается просьба приложить шаблоны документов, с которыми работают сотрудники соответствующего подразделения. Список вопросов должен быть ограничен (не более 15-20) с тем, чтобы вся анкета не занимала более двух листов. Примерный вариант анкеты приведен на слайде 14. 
Сбор документов должен осуществляться на всех этапах проведения обследования, соответствующие формы, бланки и т.п. в дальнейшем сослужат неоценимую службу при разработке информационной модели предприятия (выявлении сущностей информационной модели и наполнении их атрибутикой). 
Интервьюирование является важнейшим и необходимым методом обследования, только с его помощью возможно разобраться во всех тонкостях применяемых на предприятии технологий. Современное предприятие является сложнейшей системой, как оно функционирует не знает ни один человек. Конечно, руководство представляет ситуацию в целом, с другой стороны, клерк досконально знает свою деятельность, но полной картины не имеет никто. И только интервьюирование представителей всех звеньев оргштатной структуры позволит выявить и, в дальнейшем, формализовать эту картину. 
С другой стороны, интервьюирование является и наиболее сложной задачей: необходимо найти контакт с сотрудником и направить беседу в необходимое для аналитика русло. Ниже предлагается несколько общих рекомендаций, касающихся линии поведения аналитика при интервьюировании. 
•	Тезис в начале беседы - я ничего (или почти ничего) не знаю о Вашей работе, расскажите как можно подробнее, чем Вы занимаетесь? 
•	Правило 1 - если Вам начали подробно рассказывать технологию работы, ни в коем случае не перебивайте, необходимые уточнения можно сделать и в конце беседы. 
•	Правило 2 - если в беседе участвуют несколько аналитиков, вести беседу и задавать уточняющие вопросы должен один из них, неясные для других вопросы проясняются В конце беседы. 
•	Правило 3 - даже если Вы прекрасно знаете предметную область, не говорите много сами и не учите интервьюируемого: в любом случае выявляются тонкости и детали, специфичные для данного предприятия и, естественно, Вам неизвестные. 
При проведении интервью следует учитывать специфику характера людей:
•	"Отказник" - как правило, квалифицированный специалист, осознающий свою незаменимость. Обычно руководству известен его характер, поэтому необходимы жесткие меры: либо данная деятельность не будет включена в модель, либо она будет промоделирована на основании опыта и соображений здравого смысла. 
•	"Говорун" - как правило, руководитель среднего звена, понимающий, что по-старому работать нельзя и хватающийся за любую возможность улучшить ситуацию. Очень полезный для поддержки проекта человек, тем не менее в беседе готов бесконечно обсуждать свои трудности и проблемы, получить от него необходимую для построения модели информацию практически невозможно. Единственный способ работы с ним - обсуждение уже построенной (пусть примитивной и во многом ошибочной) модели с целью ее доводки. 
•	"Балласт" - человек, давно работающий на предприятии и непонятно чем занимающийся. На вопросы типа "Какие функции Вы выполняете?", "С какими документами Вы работаете?" агрессивно повторяет как попугай "я делаю все", "Со всеми документами", "Все документы ко мне приходят и все уходят". Какой-либо информации получить не удается по причине ее отсутствия. Естественно никакого отражения подобной "деятельности" в модели не производится. 
•	Человек, занимающий экзотическую и малопонятную должность типа "главный обогатитель". Представляет собой модификацию варианта 3) с той лишь разницей, что реально деятельность по обогащению руды существует и, следовательно, должна быть отражена в модели. 
•	"Мелкая сошка" - человек, не привыкший к проявлению интереса к себе и своей работе и занимающий низшую должность. При должном терпении реально получение того небольшого куска информации, которым он владеет. 

Во время интервьюирования необходимо выявить следующее:
1.	необходимо ограничить контекст системы с этой целью должны быть выявлены все внешние объекты, с которыми моделируемое предприятие взаимодействует, технологии взаимодействия со стороны предприятия, а также информационные (и, возможно, материальные) потоки, обеспечивающие эти взаимодействия.
2.	должны быть детально выявлены реальные технологии работы предприятия нормативно-справочная документация (если она имеется) описывает их неполно
3.	должны быть определены реальные функции подразделений и их взаимосвязи и взаимозависимости, поскольку положения о подразделениях такую информацию не содержат
4.	должны быть выявлены и специфицированы все информационные хранилища (в том числе и бумажные: картотеки, архивы и т.п.)
5.	должна быть оценена аппаратно-техническая база предприятия, а также исследовано работающее на ней программное обеспечение.
6.	должны быть собраны статистические данные по бизнес-процессам предприятия.
6.1.	Составные данные. Для составных данных статистика собирается, как правило, лишь для итеративных (повторяющихся) компонентов необходимо точно знать количество итераций для каждого из них. Например, заказ на книги включает в себя перечень заказанных книг с их атрибутами. Поэтому для формирования требований к функции распечатки соответствующего бланка необходимо знать: сколько книг обычно заказывается? как часто производится нетипичный заказ и каковы его размеры? сколько авторов обычно бывает у книги? ... Статистика по итеративным компонентам внутри составных данных в дальнейшем будет использоваться для проектирования экранов, отчетов и, естественно, при проектировании базы данных.
6.2.	Элементы данных. О каждом элементе данных необходимо знать формат данных и допустимые значения этого элемента. Формат (включая тип) и физическая длина очень полезны при проектировании экранных форм и определении размеров баз данных.
6.3.	Потоки данных. Такие характеристики потока как скорость и интенсивность являются необходимыми при определении требований к аппаратным (техническим) средствам. Кроме того, для любого составного потока данных полезно знать распределение компонентов внутри этого потока данных. Подобная статистика может использоваться для определения пиковых нагрузок на соответствующие обрабатывающие процессы.
6.4.	Процессы. Важнейшими характеристиками процессов являются частота и время выполнения. Такие сведения являются необходимыми при определении требований к аппаратным средствам.
6.5.	Хранилища данных. По хранилищам данных обычно собирается следующая информация: среднее количество записей в каждом хранилище данных, количество чтений, добавлений, изменений и удалений записей по каждому из процессов, включающих перечисленные действия. Проектировщик баз данных может использовать эту статистику для нескольких целей, например, решить вопрос, какой ключ считать первичным, сортировать ли хранилище и по какому ключу, решить, нужно ли завести дополнительную таблицу с целью обеспечения скорости доступа и т.д. Более того, к этой информации потребуется обратиться и при выборе подходящей СУБД, которая сможет обеспечить необходимую частоту и/или гибкость доступа к данным. Ценной информацией для своевременного осуществления архивации данных является  хронология доступа к ним.
6.6.	Внешние объекты  -  статистика об окружении, в котором система должна работать ("ограничения окружения"). Наиболее важным здесь является количество пользователей, их способы использования системы и географическое распределение. По этой статистике можно будет сделать заключения о стоимости периферии, о типе системы телекоммуникаций и даже о том, как данные должны быть физически распределены для обеспечения удаленного доступа. Другие данные об окружении могут включать температуру, уровень шума, существующую отделку помещения, уровень радиации и т.п.

4.7. Общие принципы моделирования 

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

Л4. Методологические аспекты проектирования                                                                                          из