Глава 1 Введение
О том, как организована вся
документация по CASE.Аналитику
и как ею эффективно пользоваться, можно узнать,
прочитав
Введение и Главу 2 документа "Подготовка к
работе".
Настоящее руководство предназначено для аналитиков, непосредственно работающих с системой CASE.Аналитик, а также может быть использовано для ознакомления с методологией структурного анализа.
Во Введении (данный раздел) объясняется как организовано руководство.
В главе 2, Основные сведения о CASE.Аналитике, описаны основные понятия, методы и средства, на которых базируется CASE.Аналитик: понятия CASE, методологии структурного анализа и жизненного цикла систем. Приведены, также функциональная структура CASE.Аналитика и особенности систем, для разработки которых предназначен CASE.Аналитик.
В главе 3, Анализ требований: построение информационно-логической модели системы, приведено подробное определение информационно-логической модели системы. Модель строится при помощи различного рода диаграмм и структурограмм. Приведены методические рекомендации по построению "хороших" моделей.
В главе 4, План построения информационно-логической модели системы, приведен пошаговый перечень процедур, которые необходимо выполнить для того, чтобы построить модель - т.е. проделать анализ требований, получить спецификации системы и документацию. Этот план содержится также в файле на установочной дискете. Вы можете его распечатать и использовать для контроля Вашего конкретного проекта.
В главе 5, Пошаговые процедуры построения информационно-логической модели системы, описывается содержание пошаговых процедур плана разработки, введенного в предыдущей главе. Эта глава является своего рода справочником, к которому следует обращаться по мере построения модели.
В главе 6, Документирование проекта, описаны принципы документирования проектов, разрабатываемых при помощи CASE.Аналитика, а также перечень и структура документов, получаемых с его помощью.
В главе 7, Презентация проекта, приведены рекомендации по проведению эффективных презентаций Вашего проекта.
В настоящем руководстве использовались цитаты из книги К.Гэйн и Т.Сарсон "Структурный системный анализ".
Глава 2. Основные сведения о CASE.Аналитике
CASE.Аналитик - это программное обеспечение для персональной ЭВМ, предназначенное для построения информационно-логической модели задуманной системы обработки информации в диалоге с компьютером.
2.1. Понятие CASE
В настоящее время при традиционной разработке систем обработки информации часто автоматизированы лишь отдельные фазы или шаги разработки (например компиляция и комплексирование программ). Примерно с середины 80-х годов для проектирования сложных программных систем создаются и начинают использоваться системы автоматизированной поддержки (Computer-Aided) проектирования систем (System/Software Engineering) - CASE-системы. Созданные первоначально для разработки программного обеспечения, CASE-системы оказались применимы и для разработки вообще систем обработки информации. Это стало возможным благодаря тому, что в основе CASE-систем лежит системный подход к разработке.
На практике применение CASE-систем в разработке приводит к ее удешевлению, сокращению ее сроков, а также к повышению качества и надежности системы.
Подобно тому, как это произошло ранее в других областях создания технически сложных систем, СASE-системы призваны осуществить переход от кустарных способов создания систем, с характерным для них отсутствием планирования и непредсказуемостью результатов, к индустриальным автоматизированным методам, позволяющим планировать сроки и затраты, гарантировать качество и обеспечить заказчика необходимым ему результатом. CASE-системы способны привлечь к созданию системы специалистов по информатике и в прикладных областях, равно как и заказчика и будущих пользователей, уже с самых ранних фаз.
В ближайшие годы CASE-системы, вероятно, станут неотъемлемой и основной частью инструментальных средств разработки программного обеспечения. Важнейшим условием успешного проектирования сложных программных комплексов является применение строгих методологий на различных фазах жизненного цикла программного обеспечения. Необходимую строгость и обеспечивает применение CASE-систем. Развитие систем программирования претерпевает эволюцию от языков различных поколений к автоматизированным CASE-системам.
CASE-системы могут использоваться всеми организациями, создающими или заказывающими программные комплексы.
Следует также ожидать больших выгод от применения CASE-систем в проектировании АСУТП, причем не только собственно программного обеспечения, но и АСУТП в целом.
2.2. Методология анализа требований - структурный анализ
Важным условием результативности анализа требований является выбор адекватной методологии его проведения.
В конце 70-х - в 80-х годах для разработки информационных систем была развита структурная методология. Эта методология дает строгие формализованные методы описания разрабатываемой системы и принимаемых технических решений. Важно подчеркнуть, что структурная методология изначально ориентирована на поддержку работы не отдельного разработчика, а коллектива разработчиков.
Являясь строгой, структурная методология основывается на наглядной диаграммной технике: для описания различного рода моделей проектируемой системы используются диаграммы, схемы и структурограммы. Наглядность, с одной стороны, и строгость, с другой, средств структурного анализа позволяют заказчикам, разработчикам и будущим пользователям системы с самого начала неформально участвовать в создании системы, обсуждать и закреплять понимание постановки задачи и основных технических решений. Один из создателей структурного анализа, Росс, называл технику структурного анализа языком для передачи понимания.
На этапе структурного анализа не рассматриваются вопросы, связанные с реализацией проектируемой системы, а основной задачей является формализация требований к системе.
Поэтому структурный анализ может быть применен не только к чисто программным информационным системам, но и к организационным, управляющим и другим системам.
Первоначально структурный анализ, развитый в работах Yourdon, De Marco, Gane и Sarson, не включал в себя средства анализа временных требований к системе. Другими словами средства структурного анализа не охватывали все аспекты требований к системам, которые обычно относят к классу систем реального времени.
В 80-е годы методология структурного анализа была распространена и на системы реального времени, предоставляя аналитику возможности показывать взаимодействия синхронных и асинхронных событий в системе. Был предложен ряд конкретных расширений методологии. Наиболее часто в CASE-системах применяются расширения Ward/Mellor и Hatley.
В основе структурной методологии лежит строгая и наглядная диаграммная техника, которая обеспечивает:
 | помощь для ясного понимания потребностей пользователя; |
| точное взаимодействие между членами бригады разработчиков; |
| "принудительный" хороший стиль; |
| возможность для пользователя уже с первых шагов разработки "увидеть" систему и проверить проект. |
Анализ требований является первой фазой разработки программного обеспечения, на которой требования пользователя уточняются, формализуются и документируются. Именно здесь, в самом начале проекта, находится ключ к успеху всего проекта. В практике создания больших систем программного обеспечения известно много случаев неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований. Во многом эти проблемы связаны с отсутствием у системных аналитиков средств, облегчающих процесс конкретизации системных требований и, что особенно характерно для сложных систем, с невозможностью представить поведение системы в целом. В CASE-системах эти проблемы решаются следующим образом:
| Путем предоставления пользователю машинно-реализованных средств формального описания системы, и прежде всего в графической нотации, понятной также заказчику и пользователю создаваемой системы, вовлекаемых, таким образом, в разработку системы на ее ранней стадии, когда еще можно что-то менять без особых затрат; |
| Путем предоставления пользователю доступа к любой части проекта. |
| Обеспечением контроля на полноту и непротиворечивость каждой части системных требований при помощи встроенных средств контроля. |
CASE.Аналитик поддерживает структурную методологию, положенную в основу большинства CASE-систем.
2.3. Жизненный цикл и нисходящая разработка
В соответствии с концепцией жизненного цикла, программное обеспечение в своем развитии проходит ряд вполне определенных фаз. Такое деление жизненного цикла является неформальным. Недостаточная проработанность вопросов на любой фазе, приводит, как правило, к неуспеху всего проекта. Более того вопросы, не решенные на ранних фазах жизненного цикла, а также ошибки, допущенные на этих фазах, порождают на последующих фазах трудные, а часто и нерешаемые проблемы. Фазы определяются задачами, решаемыми на каждой из них.
Выделяют следующие фазы жизненного цикла:
| Анализ и определение требований (системный анализ); |
| Проектирование; |
| Детальное проектирование и программирование; |
| Кодирование и автономная отладка; |
| Комплексирование и испытание; |
| Использование и сопровождение. |
На рис. 1 показана схема жизненного цикла программно-аппаратной системы. На рисунке затушеваны фазы, на которых применим CASE.Аналитик.
Рис. 1. Схема жизненного цикла программно-аппаратной системы обработки информации
Каждая фаза жизненного цикла определяется характерными для нее решаемыми задачами, исходными и результирующими документами, применяемыми методами решения поставленных задач.
Выделим некоторые свойства жизненного цикла:
| Жизненный цикл программного обеспечения образуется в соответствии с принципом проектирования сверху вниз и подчиняется его основным правилам: последовательной декомпозиции и детализации, иерархической организации, прямого соответствия выходов предыдущих фаз входам последующих и т.д. |
| Жизненный цикл носит итерационный характер: реализованные фазы, начиная с самых ранних, циклически повторяются. Такое повторение может быть связано с различными аспектами создания программного обеспечения: с выяснившимися ограничениями, с изменением требований и внешних условий и т.п. Важно подчеркнуть, что возврат к реализованным фазам на ранних этапах требует значительно меньших затрат, чем возврат на более поздних. |
| Каждая фаза порождает определенный набор документов и технических решений. Исходными документами и решениями для каждой фазы являются документы и решения предыдущей фазы. |
| Каждая фаза завершается верификацией порождаемых документов и технических решений с целью установить их соответствие исходным документам фазы. |
| На каждой фазе, в соответствии с решаемой задачей, применяется определенная методология и инструментальные средства. |
Несмотря на то, что понятия и теория жизненного цикла известны достаточно давно, широкое применение этой теории и следование ее рекомендациям при разработке конкретных систем встречается достаточно редко. Причина такого состояния дел очевидна: следование положениям теории жизненного цикла при неавтоматизированной разработке практически невозможно. Действительно, вручную очень трудно (если вообще возможно) разработать и графически представить строгие формальные спецификации системы, убедиться в их полноте и непротиворечивости, а тем более их изменять. И если при определенной решимости все же можно написать строгую систему проектных документов, то ее переработка (итерации - свойство жизненного цикла) уже вряд ли осуществима.
И именно СASE.Аналитик предоставляет аналитикам возможность, с одной стороны, строгой и наглядной формулировки спецификаций системы, а с другой - возможность многократного редактирования этих спецификаций.
2.4. Назначение CASE.Аналитика
CASE.Аналитик автоматизирует строгую графическую методологию анализа систем, в основе которой лежит диаграммная техника. Несмотря на то, что были разработаны достаточно мощные и строгие языковые средства анализа и описания систем, широкое применение находят лишь графические методологии, т.к. в них выполняется важнейшее условие "понятности" описания ("картинка стоит тысячи слов"), причем не только для разработчиков системы, но и для других категорий людей, соприкасающихся с системой. Сами графические методологии могут широко использоваться только при автоматизированной поддержке, т.к. ручная разработка и тем более многократная корректировка диаграмм и базы данных проекта вряд ли выполнимы для достаточно сложных систем. Результаты применения CASE.Аналитика - экранные и печатные формы - будут предоставляться руководителям различного уровня, принимающим решения относительно различных аспектов проекта, а также будущиим пользователям и заказчикам разрабатываемой при помощи CASE.Аналитика системы.
Система CASE.Аналитик:
| предоставляет пользователю графический интерфейс средства для работы со следующими типами диаграмм: |
| контекстные диаграммы; |
| диаграммы потоков данных (в нотации Gane/Sarson);< !--mstheme--> |
| диаграммы управляющих потоков данных; |
| структурограммы данных. |
| ведет базу данных проекта, причем основная часть словаря проекта заполняется автоматически при разработке диаграмм системы; |
| автоматически верифицирует описания системы. |
Инструментарий структурного анализа полезен для анализа существующих ручных операций, ясного их понимания перед тем, как решить, стоит ли устанавливать ЭВМ и какую часть системы необходимо автоматизировать.
2.5. Функциональная структура CASE.Аналитика
Основные компоненты системы CASE.Аналитик
| Графический редактор потоковых диаграмм; |
| Редактор структурограмм данных; |
| База данных проекта; |
| Средства вывода экранных и печатных форм для контроля и анализа проекта; |
| Средства вывода печатных форм для презентации проекта; |
| Документатор; |
| Верификатор. |
Все действия над диаграммами при редактировании отображаются на экране в графическом виде. При вводе элементов диаграмм и их редактировании осуществляется контроль корректности вводимой информации и ее совместимости с остальными частями проекта. Введенная (измененная) информация запоминается в базе данных проекта автоматически и по запросу пользователя.
Предусмотрены следующие экранные и печатные формы:
| Проектная документация (14 типов документов) |
| Контекстная диаграмма |
| Диаграмма потоков данных |
| Диаграмма потоков управления< !--msthemelist--> |
| Перечни объектов словаря данных отсортированных и отобранных различными способами |
| Содержание элементов словаря данных< /font> |
| Миниспецификация логики процесса |
| Протоколы верификации проекта |
| Отчеты проекта |
Система CASE.Аналитик генерирует на основе данных, хранящихся в базе данных проекта, макеты проектной документации в соответствии со стандартами ГОСТ 19.ХХХ, ГОСТ 34.ХХХ.
2.6. Особенности систем, для разработки которых предназначен CASE.Аналитик
Методология, лежащая в основе CASE.Аналитика, применима к широкому классу систем обработки информации (как автоматизированных, так и ручных) - информационно-вычислительных, АСУ, АСУТП, системы автоматизации эксперимента, организационных систем и т.п.
Отметим следующие особенности таких систем, которые учитывались при проектировании CASE.Аналитика:
| распределенность - несколько взаимодействующих подсистем, распределенных в пространстве; |
| большое количество разнообразных источников и приемников данных (сотни, тысячи) в состав системы могут входить датчики; |
| система должна соответствующим образом реагировать на множество внешних и внутренних событий, возникающих в случайные моменты времени; |
| система должна достаточно быстро с точки зрения ее эргономики и безопасности автоматизируемых функций реагировать на события; |
| система может находиться во многих состояниях; |
| в системе в каждый момент времени выполняются и взаимодействуют параллельные процессы; |
| сложность разрабатываемой системы: для ее создания необходим коллектив проектировщиков и разработчиков; |
| кроме потоков данных, которые физически являются дискретными электрическими сигналами, необходимо рассматривать сигналы, являющиеся физически аналоговыми электрическими сигналами. |
Глава 3. Анализ требований
Анализ требований: построение информационно-логической модели системы
3.1. Результаты анализа требований при помощи CASE.Аналитика
В результате проведения анализа требований строится информационно-логическая модель анализируемой системы - будущей или существующей.
Для успешной реализации проекта - по созданию новой или модернизации существующей системы - необходимо строгое определение системы, одинаково понимаемое всеми участниками проекта: заказчиками, финансирующими проект, пользователями, проектировщиками, осуществляющими физическое проектирование.
Такое строгое и вместе с тем наглядное (т.е. понятное) определение системы и дает информационно-логическая модель, которая строится в результате структурного анализа.
В соответствии со структурной методологией информационно-логическая модель системы определяется как иерархия диаграмм информационных потоков и описаний их элементов в виде структурограмм.
Диаграммы верхних уровней иерархии определяют основные функции/подсистемы системы с внешними входами и выходами и используемыми файлами. Далее эти основные функции/подсистемы детализируются при помощи диаграмм нижнего уровня. Такая функциональная декомпозиция продолжается, создавая таким образом многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором функциональный процесс становится элементарным, невозможным для дальнейшей детализации. Когда дальнейшая детализация логических функций перестает быть полезной, то переходят к выражению внутренней логики процессов при помощи миниспецификаций - структурограмм логики процессов. На рис.2 показаны эти связи.
При анализе детали проекта заносятся в базу данных проекта, часто называемую словарем данных или репозиторием.
Рис. 2. Информационно-логическая модель системы
Информационно-логическая модель, хранящаяся в базе данных проекта, образует исчерпывающее описание системы независимо от того, является ли она существующей или же новой, которую предстоит построить. После подготовки информационно-логической модели мы обладаем логической функциональной спецификацией, подробным описанием того, что должна делать система, освобожденным насколько это возможно от деталей реализации. Такая информационно-логическая модель дает проектировщику четкое представление о конечных результатах, которых следует достичь.
3.2. Формальное определение информационно-логической модели
Информационно-логическая модель системы есть иерархия диаграмм, структурограмм и различного рода описаний. Уровни иерархии модели - это уровни детализации: перехода на более низкий уровень иерархии мы получаем более детальное описание структурных элементов более высокого уровня иерархии.
Для формальной записи определения информационно-логической модели воспользуемся нотацией Бэкуса-Наура, дополненной выражением для записи конструкции "детализация". Запись
A -> B
следует читать так: объект типа "A" детализируется при помощи объекта типа "B", или объект "B" детализирует объект типа "A".
Напомним правила нотации Бэкуса-Наура. Запись
A = BC
означает, что объект А состоит из объектов В и С. Если А состоит либо из В, либо из С, то этот факт записывается так:
A = B | C
Условное вхождение, т.е. когда объект А может состоять либо из В, либо из пустого множества, выражается следующим образом:
A = [B]
Если же А может состоять из любого числа (включая О) объектов В, то это обозначается так:
A = {B}
Таким образом запись
A -> B | C
означает, что объект А детализируется либо при помощи объекта В, либо при помощи объекта С.
Символы, входящие в конструкцию, будем отмечать при помощи кавычек, например:
"."
В таблицах 1 и 2 приведено формальное определение информационно-логической модели.
В приведенной записи не определено содержание таких понятий, как структурограммы, миниспецификации, диаграмма переходов состояний и таблица событие-отклик*. Это сделано для того, чтобы не загромождать определение. Соответствующие определения будут приведены ниже.
Таблица 1. Определение иерархии детализации
<Информационно-логическая модель> |
-> | <Контекстная диаграмма> |
<Подсистема> |
-> | <Диаграмма информационных потоков> |
<Управляющий процесс> |
-> | <Диаграмма перехода
состояний> | <Таблица событие-отклик> |
<Процесс> |
-> | <Диаграмма потоков данных> | <Миниспецификация> |
<Поток данных> |
-> | <Структурограмма данных> |
<Поток управления> |
-> | <Структурограмма событий> |
<Накопитель данных> |
-> | <Структурограмма накопителя> |
3.3. Потоковые диаграммы информационно-логической модели
Приведенное выше формальное определение информационно-логической модели дано для того, чтобы у пользователя сложилось точное понимание, что есть информационно-логическая модель и какова ее иерархия.
Однако в процессе построения информационно-логической модели при помощи CASE.Аналитика пользователю нет необходимости обращаться к этому определению и тем более писать что-либо на подобном "птичьем" языке.
Таблица 2. Определение компонент модели
<Контекстная диаграмма> = |
{<подсистема>} {<внешняя сущность>} <информационный канал>} {<информационный поток>} |
<Подсистема> = |
<номер> <имя> <поставщик> |
<Внешняя сущность> = |
<имя>[<номер копии>] |
<Информационный канал> = |
<имя>[<номер копии>] |
<Информационный поток> = |
<поток данных> | <поток управления> |
<Поток данных> = |
<имя> |
<Диаграмма информационных потоков> = |
<контекстная
диаграмма> | <диаграмма потоков управления> | <диаграмма потоков данных> |
<Диаграмма потоков управления> = |
{<управляющий
процесс>} | {<процесс>}| {<информационный канал>} | {<внешняя сущность>} | {<поток управления>} |
<Управляющий процесс> = |
<номер><имя> |
<Процесс> = |
<номер> <имя> <реализация> |
<Диаграмма потоков данных> = |
{<процесс>}| {<управляющий процесс>}| {<внешняя сущность>}| {<информационный канал>}| {<накопитель данных>}| {<поток данных>} |
<Информационный канал> = |
<номер ИК> <имя> [<номер копии>] |
<Номер ИК> = |
"ИК"<целое> |
<Накопитель данных> = |
<номер накопителя> <имя>[<номер копии>] |
<Номер> = |
<целое не 0> "." [<номер>] |
<Имя> = |
<буква> {<буква> | <цифра> " "} |
<Номер копии> = |
<целое> |
<Номер накопителя> = |
"D"<целое> |
Формальное отслеживание соответствий и согласованности при переходе с уровня на уровень, а также все необходимое ассистирование пользователю в процессе построения информационно-логической модели CASE.Аналитик выполняет автоматически. Пользователь строит информационно-логическую модель, пользуясь графическими символами. На рис.3 приведен пример диаграммы потоков данных (их пользователю придется строить чаще всего).
Рис. 3. Пример диаграммы потоков данных
В настоящем разделе приводится графическая нотация для разработки потоковых диаграмм, а также объясняется логический смысл введенных структурных элементов диаграмм.
Формально диаграмма информационных потоков есть направленный граф, нагруженный по дугам и узлам. Диаграмма информационных потоков описывает асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю.
Внешние сущности* - источники информации порождают информационные потоки, переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют полезную информацию и порождают новые информационные потоки, которые переносят информацию к другим процессам или подсистемам, накопителям информации или внешним сущностям - потребителям информации.
Использование ограниченного числа символов позволяет нам построить изображение системы, не связывая себя решениями о ее возможной реализации.
В структурном анализе существует несколько вариантов графической нотации структурного анализа - Ross, Yordon&De Marco, Gane&Sarson и др. CASE.Аналитик поддерживает нотацию Gane&Sarson.
3.3.1. Внешние сущности
Внешними сущностями системы обычно являются логические классы предметов или физических лиц, представляющие собой источник или приемник информации, например, заказчики, персонал, поставщики, налогоплательщики, клиенты. Это могут быть специфические источники или приемники, такие, как, Бухгалтерия, Информационно-поисковая система, Склад. Если система, которую мы рассматриваем, принимает данные от другой системы или передает данные в другую систему, то эта другая система является элементом внешнего окружения.
Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень (источник света находится справа внизу), для того, чтобы можно было выделить этот символ среди других обозначений на диаграмме, как показано на рис. 4).
Проектируя некоторое устройство или некоторую систему как внешнюю сущность, мы точно указываем, что она находится за пределами границ рассматриваемой системы. Когда анализ проделан и изучены требования пользователей, мы можем перенести некоторые внешние сущности внутрь диаграммы нашей системы или, наоборот, вынести какую-то часть функций нашей системы и рассматривать всю эту часть как внешнюю сущность с исходящим и входящим потоками данных.
3.3.2. Системы/подсистемы
При построении информационно-логических моделей сложных (а, как правило, и распределенных) систем ее структуризация на отдельные взаимодействующие подсистемы может быть уже заданной или с очевидностью следующей из внешних условий, налагаемых на систему.
Такая структуризация может быть задана как требование к безопасности системы или возникать как следствие протяженности системы в пространстве. Кроме того, разбиение системы на подсистемы может понадобиться уже на ранней стадии проекта, до проведения анализа, в тех случаях, когда сложная система проектируется и реализуется разными организациями-разработчиками.
Подсистема на контекстной диаграмме изображается, как показано на рис. 5.
Рис. 5. Условное обозначение подсистемы
Номер подсистемы представляется автоматически. В поле имени процесса вводится наименование подсистемы в виде предложения с подлежащим и с соответствующими определениями и дополнениями, например:
3.3.3. Процесс
Логически процесс есть преобразование в соответствии со своей внутренней логикой входных потоков в выходные. В действительности процесс может быть реализован самыми разными способами: подразделение организации (например отдел), выполняющие нужную обработку входных документов и выпуск соответствующих отчетов, программа ЭВМ, аппаратно реализованное логическое устройство и т.д.
Процессы обозначаются прямоугольниками с закругленными углами, разделенными на три поля (см. рис. 6). Необходимо дать каждому процессу имя, отражающее его функцию и по возможности, привязать его к физической реализации.
Рис. 6. Условное обозначение процесса
Для идентификации процессы автоматически нумеруются.
Имя процесса следует представлять в форме предложения с глаголом в неопределенной форме (вычислить, проверить), за которым следует винительный падеж, причем нужно стремиться к наиболее простой форме предложения, например:
Если вы используете такие глаголы, как "обработать", "модернизировать" или "отредактировать", то это означает, что вы, вероятно, пока недостаточно глубоко понимаете данную функцию и потребуется дальнейший анализ.
Активными недвусмысленными глаголами являются следующие: "создать", "получить", "извлечь", "отыскать", "заполнить", "вычислить", "рассчитать", "определить", "подтвердить". При использовании глагола "сортировать" предполагается, что было выбрано физическое решение, поскольку сортировка - это главным образом физическая перегруппировка последовательности записей в файле, которая не имеет логического значения.
Заметим, что эти предложения в повелительном наклонении не имеют подлежащего когда вводится подлежащее (например, "Администратор по сбыту выбирает данные по ежемесячным продажам"), то предполагается, что решено, каким образом данная функция будет осуществляться.
Важно при изучении существующей системы отметить, какой отдел или какая программа выполняет данную функцию. Подобным же образом, когда проводимый анализ завершен и осуществляется проектирование новой системы, целесообразно отражать, как в физическом смысле будет осуществляться данная функция. Назначение нижнего поля прямоугольника процесса - обозначение физической ссылки (см. рис. 7).
Рис. 7. Прямоугольники процессов, содержащие физические ссылки
3.3.4. Управляющий процесс
Логически управляющий процесс есть некий командный пункт, который реагируя на изменение внешних условий, передаваемых ему управляющим потоком (или потоком событий), выдает в соответствии со своей внутренней логикой команды, выполняемые процессами. Эти команды переносятся также управляющими потоками, а их исполнение процессами приводит к изменению состояния системы. Управляющий процесс может быть реализован, например, в виде командного пункта, на котором командир принимает сигналы об обстановке, и в соответствии с уставом, заданием и знаниями (внутренняя логика) выдает команды подчиненным или в виде административного центра или в виде многозадачной ОС, управляющей процессором.
Управляющий процесс обозначается в виде прямоугольника с закругленными углами, изображенного пунктирными линиями (рис. 8).
Рис. 8. Условное обозначение управляющего процесса
Имя управляющего процесса следует давать в виде предложения, начинающегося со слова "Управление", за которым следует дополнение, например:
3.3.5. Накопители данных
Логически накопители данных есть некие устройства для хранения информации, куда ее можно поместить и через некоторое время изъять. При этом на этапе анализа мы не уточняем способ помещения и извлечения данных в накопитель нас не интересует, происходит ли извлечение данных в смысле чтения (копирования) или в смысле изъятия и подобные вопросы.
Накопителем данных в реальности может быть микрофиша, ящик для хранения карточек, таблица в памяти, файл на ленте или диске.
Накопитель данных обозначается двумя горизонтальными параллельными линиями, замкнутыми с одного края - рис. 9. Каждый накопитель данных идентифицируется для ссылки буквой "D" и произвольным числом в квадрате с левой стороны, определяемым автоматически. Имя должно подбираться с учетом наибольшей информативности для пользователя.
Рис. 9. Условное обозначение накопителя данных
Когда процесс сохраняет данные, то стрелка потока данных направлена в накопитель данных, и, наоборот, когда доступ в накопитель данных осуществляется в смысле чтения, достаточно показать группу элементов данных, связанных с выходным потоком данных (см. рис. 10).
Рис. 10. Доступ в накопитель данных
3.3.6. Информационный канал
При детализации подсистемы/процессов часто (за исключением простейших систем) возникает необходимость в детализации (структуризации) информационных потоков. Например, на диаграмме верхнего уровня может появиться поток "Годовой отчет", который получает руководство организации. При детализации на следующих уровнях иерархии может выясниться, что годовой отчет готовят различные подразделения и для этого порождаются такие потоки данных, как
Т.е. поток "Годовой отчет" есть результат слияния трех потоков. Такое слияние осуществляется через логический информационный канал.
Логически информационный канал есть среда передачи информации. Информационный канал может реализоваться в виде, например пневмопочты, курьерской службы, почты, магистрали или шины данных и т.д.
Условное обозначение канала имеет поле имени и поле номера копии, как показано на рис. 11).
Рис. 11. Условное обозначение информационного канала
Информационный канал именуется подлежащим с соответствующими определениями.
3.3.7. Информационный поток
Логически информационный поток есть информация, передаваемая через некоторое соединение от источника к приемнику.
В реальности информационный поток есть, например, информация, передаваемая по кабелю между двумя устройствами, письма, пересылаемые между респондентами, магнитная лента или дискета, переносимая между ЭВМ. Информационный поток может физически содержаться в телефонном звонке, при переходе от программы к программе через спутниковую информационную связь - при любом варианте прохождения данных от одного объекта или процесса к другому.
Рис. 12. Условные обозначения информационных потоков
3.3.7.1 Поток данных
Поток данных изображается ломанной линией с горизонтальными и вертикальными участками, заканчивающейся стрелкой, причем направление стрелки указывает направление потока.
Каждый поток имеет вдоль стрелки имя, отражающее его содержание. Это имя выбирается таким образом, чтобы в наибольшей степени передать смысл содержания потока пользователям, которые будут рассматривать диаграмму (см. рис. 13).
Рис. 13. Изображение потока данных
3.3.7.2. Управляющий поток
Для целей структурного анализа информационных систем достаточно понятия "поток данных". При анализе систем реального времени выдается управляющий поток или поток событий.
3.3.8. Правила соединения узлов на диаграммах
На соединение узлов различного типа потоками накладываются ограничения. Так например, не имеет смысла соединение при помощи потока данных двух накопителей данных. Накопители данных - пассивные устройства, и передача (или перезапись) информации между накопителями возможна только через некий процесс. На рис. 14 и 15 изображены допустимые соединения элементов диаграмм.
Рис. 14. Допустимые соединения для потока данных
Все остальные типы соединений запрещены и эти запреты поддерживаются автоматически CASE.Аналитиком.
Рис. 15. Допустимые соединения для потока управления
3.3.9. Правила детализации подсистем и процессов при помощи диаграмм
Как следует из формального определения информационно-логическая модель подсистемы детализируются при помощи потоковых диаграмм, а процессы при помощи диаграмм потоков данных или миниспецификаций.
В данном разделе мы рассмотрим правила и соглашения, которые должны выполняться при детализации при помощи потоковых диаграмм. Выполнение этих правил и соглашений необходимо для соблюдения согласованности иерархии диаграмм. Эти правила поддерживаются CASE.Аналитиком автоматически.
| Правило балансировки гласит, что при детализации подсистемы/процесса дочерняя детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те сущности (подсистемы, процессы, внешние сущности, накопители, информационные каналы), с которыми имеет информационную связь детализируемая подсистема/процесс на материнской диаграмме. |
Рис. 16. Контекстная диаграмма системы обработки заказов
При этом потоки данных, связанные с внешними источниками/приемниками данных дочерней диаграммы должны быть идентичными (и по наименованию, и по содержанию) с соответствующими потоками данных материнской диаграммы. На рис. 16 показана контекстная диаграмма системы обработки заказов.
На рис. 17 показана дочерняя диаграмма потоков данных, детализирующая систему.
Рис. 17. Дочерняя диаграмма, детализирующая "Систему обработки заказов"
Эти диаграммы являются сбалансированными. Вы можете убедиться, что на дочерней диаграмме с внешними сущностями ИЗДАТЕЛИ и ЗАКАЗЧИКИ связаны только те потоки данных, которые определены на контекстной (материнской) диаграмме. И если, например, мы захотели бы связать потоком данных процесс "1.яПроверка достоверности заказа" с внешней сущностью ИЗДАТЕЛИ на дочерней диаграмме, то это нарушило бы правило балансировки. Если же такой поток действительно необходим, то он должен, прежде всего, быть введен на материнской диаграмме.
ю Правило нумерации. CASE.Аналитик автоматически поддерживает иерархическую нумерацию подсистем и процессов, как это показано на рис. 18.
Рис. 18. Иерархическая нумерация процессов
Каждый сыновний процесс более низкого уровня соотносится с отцовским процессом верхнего уровня при помощи идентифицирующего номера, который является десятичным знаком номера отцовского процесса, например 29 получает десятичные обозначения 29.1, 29.2, 29.3 и т.д., при необходимости можно перейти на третий уровень, т.е. для 29.3 получим 29.3.1, 29.3.2 и т.д.
3.3.10. Общие рекомендации по построению диаграмм
Введенный графический язык для построения диаграмм, а также автоматически поддерживаемые правила их построения не гарантируют нас от того, что построенная информационно-логическая модель будет качественной. В данном и последующем разделах мы изложим некоторые рекомендации (которые автоматически не выполняются) по построению "хороших" потоковых диаграмм. "Хорошая" диаграмма должна быть прежде всего логически адекватной анализируемой системе, не содержать деталей реализации и быть максимально наглядной и понятной.
3.3.10.1. Минимизация множественных потоков
Часто оказывается, что в одном и том же потоке перемещаются несколько "пакетов" данных. Иногда бывает трудно подобрать имя, которое адекватно отражало бы содержание потока данных. Например, заказчики могут высылать заказы, платежи, делать возврат поврежденных товаров, высылать запросы, предъявлять претензии и т.д. Очень неудобно рисовать множественные потоки данных, как это показано на рис. 19.
Рис. 19. Множественный поток данных
Есть два выхода из этого положения. Если наиболее важный логический факт состоит в том, что имеется только единственный поток данных и что функция "направить сообщение" является одной из наиболее важных, то следует агрегировать потоки в поток с не совсем ясным общим наименованием, таким, как "сообщения, поступающие от заказчиков" или "отчеты по управлению процессами". Содержание этого потока данных может быть найдено или в базе данных проекта, или при просмотре выходных данных функции "направить сообщение". На рис. 20 показан пример такого решения.
Рис. 20. Первое решение для множественного потока данных
Другой подход может использоваться в тех случаях, когда функция "направить сообщение" является тривиальной, и каждое сообщение обрабатывается различными способами (и, действительно, состоит из различных элементов данных). В этом случае каждому типу сообщений может соответствовать отдельная стрелка, направленная к соответствующему процессу (см. рис. 21).
Рис. 21. Второе решение для множественного потока данных
3.3.10.2. Дублирование узлов
Для того, чтобы избежать пересечений линий потоков данных, один и тот же элемент может копироваться и изображаться несколько раз на одной и той же диаграмме. Два (или более) квадрата, обозначающих одну и ту же внешнюю сущность, идентифицируются при помощи указания номера копии в нижнем правом углу, как показано на рис. 22.
Рис. 22. Дублирование внешних сущностей
Аналогично с той же целью следует дублировать накопители данных и информационные каналы.
Элементам на диаграммах следует давать уникальные имена.
| Имена входных и выходных потоков процессов должны быть различными. |
| На диаграммах не изображаются процессы инициализации и завершения. |
| На диаграммах опускаются пути, связанные с простыми ошибками. |
| Функциональная декомпозиция продолжается при помощи детализации, создавая, таким образом, многоуровневую иерархию диаграмм, до тех пор, пока не достигнут такой уровня декомпозиции, на котором функциональный процесс становится элементарным, невозможным для дальнейшей детализации. Процесс можно считать элементарным, если его миниспецификация содержит не более 30 строк. |
3.3.11. Рекомендации по построению контекстных диаграмм
Обычно при проектировании простых информационных систем, имеется единственная контекстная диаграмма с топологией звезды, в центре которой находится так называемый главный процесс, соединенный с источниками и приемниками информации, посредством которых с системой "общаются" пользователи и другие системы.
На рис. 23 приведен пример контекстной диаграммы.
Рис. 23. Пример контекстной диаграммы простой системы
Если ограничиться единственной контекстной диаграммой для сложных систем, то такая контекстная диаграмма будет содержать необозримое количество источников и приемников информации, которые трудно или даже невозможно расположить на листе бумаги разумного формата, и кроме того единственный главный процесс не раскрывает структуры распределенной системы.
Для сложных систем необходимо строить иерархию контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных информационными потоками. Контекстные диаграммы следующего уровня детализируют контекст и, возможно, структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой системы как между собой, так и с внешними входными и выходными информационными потоками и внешним окружением, с которым взаимодействует система. К внешнему окружению относятся внешние сущности - источники и приемники информации. В иерархии диаграмм контекстные диаграммы занимают верхние уровни иерархии.
Разработка контекстных диаграмм помогает решить одну из проблем при проектировании системы: необходимость строгого определения ее функциональной структуры уже на самой ранней стадии создания. Эта проблема особенно актуальна для многофункциональных систем (таких, как АСУ сложными технологическими процессами), в создании которых участвуют разные организации и коллективы разработчиков.
3.3.12. Рекомендации по построению диаграмм потоков управления
Подсистемы, появившиеся на контекстных диаграммах детализируются, как это следует из формального определения информационно-логической модели, при помощи диаграмм потоков управления или диаграмм потоков данных. Диаграммы потоков управления применяются при детализации подсистем, функционирующих в реальном времени.
Формальными признаками подсистемы реального времени являются:
| наличие входных/выходных потоков событий, возникающих в случайные моменты времени |
| наличие нескольких асинхронно действующих входных потоков информации, которые следует достаточно быстро преобразовывать. |
Ключевым фактором при решении вопроса о том, следует ли анализировать систему как систему реального времени является рассмотрение временных характеристик. Следует принять во внимание скорости поступления событий, требуемые времена отклика и предполагаемые ресурсы, выделяемые для системы. Если эти ресурсы достаточно велики или временные характеристики не являются жесткими, то можно ограничиться построением диаграмм потоков данных, т.е. не рассматривая систему как систему реального времени. Действительно, если производительность вычислений достаточно велика, то легко удовлетворить всем временным требованиям, строя единственный последовательный вычислительный процесс.
В принципе, любая система есть система реального времени и отказ от рассмотрения временных аспектов есть абстракция, адекватная для случая систем для которых временные требования являются заведомо выполнимыми в случае одного последовательного процесса. Там, где это возможно, следует опустить рассмотрение временных характеристик, так как анализ систем реального времени значительно более сложен.
Диаграмма потоков управления есть направленный граф, узлами которого являются информационные процессы (или просто процессы) и управляющие процессы, а дугами - информационные потоки и потоки управления. Информационные процессы преобразуют входные данные в выходные. Управляющие процессы преобразуют входные потоки событий в выходные. На диаграмме управления отражается временная картина описываемой системы.
События порождаются и потребляются внешней средой, информационными и управляющими процессами, а обрабатываются только управляющими процессами.
Информационный процесс во времени может находиться в состояниях: пассивное, активное (выполняется) и пауза (приостановлен). Состояние информационного процесса может изменяться двумя способами: при помощи специальных управляющих потоков, источниками которых является управляющий процесс и по инициативе самого процесса. В последнем случае допускается только переход в состояние "Пауза" с передачей соответствующего события управляющему процессу. На рис. 24 показана диаграмма, связывающая события управления c состояниями процесса.
Рис. 24. Диаграмма переходов состояний информационного процесса
Все события на диаграмме управления носят характер прерывания и вызывают изменения состояния того или иного процесса. Кроме того допустима передача параметров вместе с событием.
Диаграмма управления интерпретируется как набор вычислительных процессов, каждый из которых моделирует объекты реального мира. Изменения состояния объектов под воздействием изменившихся внешних условий (событий) моделируется изменением состояния вычислительных процессов, управляемых управляющим процессом, который воспринимает события.
3.4. Описание внутренней логики управляющих процессов*
Для описания внутренней логики управляющего процесса применяется два способа:
| диаграммы переходов состояний |
| таблицы событие-отклик. |
3.4.1. Диаграмма переходов состояний
Диаграмма переходов состояний есть направленный граф узлами которого являются состояния системы, а дугами переходы между состояниями. Дуги помечаются событием, вызвавшим переход, а также перечнем процессов, изменяющих состояние и событий, порождаемых управляющим процессом, связанных с этим переходом. Нотация для диаграмм переходов состояний представлена на рис. 25.
Рис. 25. Нотация, применяемая для диаграмм переходов состояний
Диаграмма переходов состояний интерпретируется следующим образом: состояние определяется набором реализуемых для данного состояния системы состояний процессов. Общее число возможных состояний, таким образом, может быть достаточно велико (в нашем случае 3N состояний, если N - число процессов). Однако, как правило, реализуется небольшое число различных состояний. Находясь в некотором состоянии, система может перейти в другое состояние при возникновении событий, помечающих переходы, выходящие из этого состояния. При этом управляющий процесс осуществляет действия, указанные при переходе.
3.4.2. Таблица событие-отклик
В таблице 3 представлен формат таблицы событие-отклик.
Таблица 3. Формат таблицы "Событие-отклик"
Событие |
Процессы, переходящие в состояния |
События |
||
| Активен | Пассивен | Приостановлен | ||
3.5. Описание внутренней логики процессов
При определении логики процесса на повествовательном языке имеется много ловушек. CASE.Аналитик предоставляет средства, которые позволяют выразить логику процесса четко и недвусмысленно.
Краткое изложение логики должно сформулировать основные функции так, чтобы специалист в данной области смог выполнить функцию (или запрограммировать ее). Краткое изложение логики не дает исчерпывающей формулировки, но должно быть написано максимально недвусмысленно.
Бом, Якопини* и другие доказали, что любая последовательная программа может быть составлена из соответствующих комбинаций пошаговых команд (подобных ПЕРЕДВИНУТЬ или ДОБАВИТЬ), решений (ЕСЛИ-ТО-ИНАЧЕ) и циклов. Логические процессы, определяемые во время структурного анализа, являются именно такими программами, предназначенными для выполнения служащим или компьютером. Эти несколько структур служат базой для Структурного Программирования, эффективность которого вызвана упрощением и стандартизацией, связанными с использованием всего нескольких структур вместо большого множества, разрешаемого определенным языком программирования.
CASE.Аналитик поддерживает составление миниспецификаций при помощи структурограмм, использующих "структуры" структурного программирования и аналогичных диаграммам Насси-Шнейдермана.
3.5.1. Формальное определение языка описания логики процессов
Для определения языка введем несколько понятий
Блок. Блок изображается при помощи прямоугольника и имеет заголовок:
Блоки можно соединять, образуя последовательность блоков или вкладывая друг в друга, образуя вложенные структуры.
Предложение - любое осмысленное предложение на естественном языке.
Далее следует определение языка.
Описание внутренней логики процесса =
<оператор> =
<условный оператор> =
<оператор выбора> =
<альтернатива> =
<цикл> =
<цикл ПОКА>/<цикл ДО>
<цикл ПОКА>=
<цикл ДО> =
<оператор ввода/вывода> =
<оператор ввода>/
<оператор вывода>
<оператор ввода> =
<оператор вывода>
<оператор событий> = <возбудить событие>/
<ждать событие>
<возбудить событие> =
<ждать событие> =
<время> = <предложение>
В последующих разделах приводятся примеры записи на формально определенном языке.
3.5.2. "Структуры" языка описания внутренней логики процесса
Последовательные операторы. Эта структура охватывает любую команду или группу команд, не имеющих повторов или разветвлений, например:
| Умножить количество отработанных часов на размер почасовой оплаты для получения полной суммы оплаты |
| Отправить книги по адресу отправления |
| Включить оплату за перевозку в счет-фактуру |
| Рассчитать оплату за перевозку. (Оплата за перевозку составляет 60 единиц за каждый килограмм после 20) |
| Прервать договор со служащим |
| Повысить на 25% |
Иногда необходимо включать описания или определения используемых терминов, как в вышеуказанном случае с "оплатой за перевозку".
Операторы выбора решения.
На рис. 26 представлен пример случая вложенных условий.
Рис. 26. Вложенные условия
По мере того, как становится более сложной логика представляемого решения возникают "вложенные-ЕСЛИ". Такая вложенная логика трудна для понимания, поэтому важно соблюдать соглашение о размещении каждого слова ИНАЧЕ на одной линии с соответствующим ЕСЛИ.
Команды выбора решения "в зависимости". Возникает особый вид структуры решения, когда имеется несколько вариантов условия, которые никогда не происходят в комбинации, т.е. они представляют различные, взаимно исключающие случаи.
Этот вид структуры всегда можно представить в виде простой таблицы
Условие |
Действие |
| Транзакция-заказ | Добавить к продажам на сегодняшний день |
| Транзакция-возврат | Вычесть из продаж на сегодняшний день |
| Транзакция-оплата | Добавить к полученным наличным деньгам |
| Транзакция-рекламация | Передать в отдел рекламаций |
| Транзакция-аннулирование | Вычесть из продаж на сегодняшний день |
Важным аспектом этой ситуации является то, что транзакция должна быть одной из пяти типов и только одной. Это не могут быть, например, и заказ и аннулирование.
В применении к приведенной выше таблице получаем:
Команды организации повторов (циклов). Эта структура применима к любой ситуации, при которой команда или группа команд повторяется до получения некоторого требуемого результата.
В качестве простого примера можно рассмотреть счет на продажу инвентаря, каждое наименование из которого представлено на отдельной строчке с указанием проданного количества и цены за единицу товара, показанный на рис. 27.
Счет |
|||
Кому: |
Заказчик Адрес заказчика |
||
Количество |
Наименование |
Цена за штуку |
Сумма |
7 |
Седло |
2000.00 |
- |
28 |
Подкова |
100.00 |
- |
7 |
Уздечка |
750.00 |
- |
1 |
Дробовик |
5500.00 |
- |
Общая сумма счета |
- |
||
Рис. 27. Счет
Можно специфицировать условие завершения составления счета следующим образом:
Для каждой строки умножить количество на стоимость единицы товара для получения суммы строки. После обработки всех строк сложить все суммы для строк для получения общей суммы счета.
Более формально мы можем указать:
Применяя структуру цикла Вы должны четко указать два важных аспекта :
На рис. 28 приведен пример записи внутренней логики процесса генерации счета.
Рис. 28. Запись логики процесса "Генерировать счет"
Рассмотрим несколько аспектов, характеризующих пример структурного языка описания логики:
| В смысле точности есть сходство с программой для компьютера, но это структура не программа. Отсутствует спецификация на чтение или запись физических файлов, нет инициализации для счетчиков или переключателей, или какого-либо физического проектирования. В том виде, как она написана, процедура может быть успешно выполнена служащим, хотя мы можем выбрать различные способы представления команд. |
| Точность и полнота структурного языка достигаются за счет непривычного и многословного представления, которое мало что говорит человеку, не знакомому с процедурой. Однако, такая запись подчеркивает структуру логики принятия решений, не допускает различных противоречий и "просмотров" и является однозначной (в определенном смысле). |
| После того, как сделана основная работа по физическому проектированию и определены физические файлы, крайне удобным становится определение физической логики программы с помощью условных обозначений структурного языка, но без проникновения в подробный синтаксис любого определенного языка программирования. |
3.5.3. Рекомендации по записи логики процессов
Подобно тому, как это было в случае диаграмм, сам по себе строгий язык и автоматическая поддержка его определений не гарантируют написание "хороших" миниспецификаций. Ниже приводятся некоторые рекомендации по написанию "хороших" миниспецификаций.
ю Точная запись диапазонов как части условий. Часто возникают трудности при записи диапазона значений как части условия. Предположим, мы говорим: "До 20 единиц нет скидки. Выше 20 единиц 5% скидки". Что может быть яснее этого? Но какая скидка дается для точного значения 20? Проблема в том, что в обычной фразе требуется дополнение в виде "включающий" или "вплоть до и включая". Можно сказать "1-19 единиц" или "Величина меньшая или равная 20", но мы опять сталкиваемся с проблемой возможности выражения одного и того же очень многими способами, что показано на рис. 29.
Часто при указании диапазонов допускают небрежность, поскольку пишущему известно, какие возможности он подразумевает, но пользователи часто удивляются, когда точная интерпретация их слов оборачивается совсем не тем, что они имели в виду.
Рис. 29. Выражение диапазонов
Для проверки правильности всех возможных диапазонов мы можем просмотреть внимательно все описание, отыскивая слова "меньше", "вплоть до", "больше" и "более", и подставить вместо них обозначения: >, >=, <=, <, где:
Ясно, что если условие-1 есть < 20 и условие-2 есть > 20, то проблема та же: что делать, если величина равна точно 20. Нужно найти соответствующие пары > и <= или >= и <. Мы должны быть уверены в том, что все пользователи понимают эти различия, даже если сокращения слишком похожи на жаргон, что затрудняет восприятие.
| Комбинации условий и неоднозначность и/или. |
Рассмотрим такое утверждение:
("более 10000 рублей в год")
("надежный плательщик в прошлом" или "более 20 лет"),
("более 10000 рублей в год" и "надежный плательщик в прошлом")
("более 20 лет"),
("более 10000 рублей в год" и "надежный плательщик в прошлом")
("более 20 лет"),
 |  |
| Неопределенные прилагательные |
Персонал, имеющий определенный опыт работы в организациях, может придавать прилагательным подобные значения. Аналитик должен быть уверен в том, что он может точно определить прилагательные. Часто правило определения является достаточно сложным и пока мы не рассмотрим каждый оператор принятия решения, не идентифицируем прилагательные и не убедимся в том, что определили каждое из них, мы никогда не решим проблему.
Сама фраза "надежный плательщик" предполагает возможность "ненадежного плательщика", то есть наличия элемента данных "ТИП ПЛАТЕЛЬЩИКА", который может иметь значение "НАДЕЖНЫЙ" или "НЕНАДЕЖНЫЙ".
| Скрытые ветви и циклы |
При записи оператора не следует проникать в какие-либо скрытые ветви или повторы, такие как:
| Доставить книги с указанием адреса доставки или с указанием места платежа в зависимости от их веса (скрытая ветвь) |
| Продолжать распределять площадь по единице за один раз, закончив после удовлетворения всех запросов (скрытый цикл с возможностью четкой проверки условия его завершения) |
Обработка граничных значений. При записи логики следует специально обращать внимание на обработку граничных значений, которые могут принимать данные.
Например, СУММА-ОПЛАТЫ на чеке может быть в диапазоне от 1 копейки до 100000 рублей. При этом мы можем заметить, что нулевое значение является подозрительным и чек на сумму менее одного рубля, хотя и правильный, следует пометить флажком для проверки должностным лицом. Можно отметить также, что не следует высылать требования платежа на сумму менее 5 рублей.
3.6. Структурограммы описания данных
Детализация содержания информационных потоков, информационных каналов и накопителей данных описывается при помощи структурограмм описания данных.
| Элементы данных - это порции данных, которые не имеет смысла подвергать дальнейшему разбиению при достижении данной цели. Например, ДАТА - это для большинства случаев элемент данных при анализе, хотя в некоторых случаях возможно рассмотрение ДАТЫ как структуры, состоящей из ДНЯ, МЕСЯЦА, ГОДА. |
| Структуры данных состоят из элементов данных, из других структур данных или из их комбинации. В качестве примера рассмотрим содержание потока данных ЗАКАЗЫ: |
ЗАКАЗ
ИДЕНТИФИКАТОР ЗАКАЗА
ДАТА ЗАКАЗА
НОМЕР ЗАКАЗА Обычно имеется
ПОДРОБНОСТИ О ЗАКАЗЧИКЕ
НАЗВАНИЕ ОРГАНИЗАЦИИ
ОТВЕТСТВЕННОЕ ЛИЦО Условно входит
ИМЯ Могут быть только инициалы
ФАМИЛИЯ
ТЕЛЕФОН
КОД
НОМЕР ТЕЛЕФОНА
АДРЕС ДЛЯ ОТПРАВКИ
ПОЧТОВЫЙ ИНДЕКС
ГОРОД
УЛИЦА
НОМЕР ДОМА
АДРЕС СЧЕТА К ОПЛАТЕ Если отсутствует, то совпадает с адресом для отправки
ПОЧТОВЫЙ ИНДЕКС
ГОРОД
УЛИЦА
НОМЕР ДОМА
ПОДРОБНОСТИ О КНИГЕ Одна или более итераций этой группы элементов данных
ИМЯ АВТОРА Одна или более итераций этой группы элементов данных
НАЗВАНИЕ
ISBN Международный стандартный номер книги Условно входит
ИМЯ ИЗДАТЕЛЯ
КОЛИЧЕСТВО
"ТЕЛЕФОН" - это структура данных, состоящая из двух элементов данных "КОД" и "НОМЕР". "ПОДРОБНОСТИ О ЗАКАЗЧИКЕ" - это структура данных, состоящая из элемента данных НАЗВАНИЕ ОРГАНИЗАЦИИ плюс структуры данных "ОТВЕТСТВЕННОЕ ЛИЦО" плюс структура данных "ТЕЛЕФОН" и т.д.
В действительности "ЗАКАЗ" является сам по себе большой структурой данных.
Таким образом, иерархия нашего описания данных имеет вид:
На диаграммах мы давали потокам, накопителям данных и процессам названия, которые являются максимально выразительными, будучи при этом достаточно краткими. Поскольку мы перешли к более тщательному рассмотрению, то чтобы ответить, например, на вопрос: "Что в точности вы подразумеваете под тем или иным именем?", мы должны будем углубиться в подробности, указывая, возможно, форматы документов, строя форматы записей в файле и так далее. При этом мы по-прежнему должны оставаться на логическом уровне, идентифицируя каждый из элементов данных, которые представлены в потоке данных, давая им выразительные названия и определяя каждый из них.
Наиболее важное преимущество для аналитика состоит в том, что он может описать потоки и накопители данных, давая выразительное название, зная, что все детали, которые связаны с этим названием, могут быть при необходимости легко извлечены из базы данных проекта.
Структуры данных состоят из элементов данных и других структур данных, поэтому, в принципе, мы можем описать любую структуру данных, указывая названия структур и элементов, образующих ее, при условии, что эти компоненты определены где-либо в словаре данных.
Нам нужно знать о структуре больше, чем только ее компоненты. Рассмотрим приведенную выше структуру ЗАКАЗ. Мы видели, что некоторые компоненты структуры являются обязательными, некоторые - входят условно, часть из них имеет альтернативные варианты, а некоторые - повторяются один или более раз (итерационные).
Для записи всех этих особенностей в CASE.Аналитике принят язык структурограмм, описание которого дано ниже.
3.6.1. Формальное определение языка описания структур данных
Для определения языка принят тот же способ и соглашение, что и для языка описания логики процессов.
Структурограмма данных =
<тип> = "ПОТОК ДАННЫХ"/
"СТРУКТУРА ДАННЫХ"/
"НАКОПИТЕЛЬ ДАННЫХ"
<Структура данных> =
<Альтернатива> =
<Условное вхождение> =
<Итерация> =
3.6.2. Рекомендации по записи структурограмм данных
| Условное вхождение означает что это необязательный компонент структуры |
| Альтернатива означает что в структуру может входить один из ниже перечисленных элементов |
| Итерация означает вхождение любого числа в указанном диапазоне. |
На рис. 30 приведен пример структурограммы.
3.7. Описание структурных элементов
Несмотря на то, что в своей основе информационно-логическая модель является графической, структурные элементы диаграмм и структурограмм имеют дополнительно вербальные описания, хранящиеся в базе данных.
Рис. 30. Пример структурограммы данных
Со всеми структурными элементами информационно-логической модели - процессами, внешними сущностями и т.д. - связаны аннотации, куда аналитик может записать произвольный текст, каким-то образом характеризующий или поясняющий введенный элемент, а также ссылки на источники информации об этих элементах.
Ниже для каждого типа элемента информационно-логической модели приводятся перечни описаний, которые могут заполняться аналитиком. Отметим, что едва ли не большая часть информации о том или ином конкретном структурном элементе генерируется CASE.Аналитиком автоматически.
3.7.1. Описательная информация об информационных потоках
Дополнительно указывается:
| Период передачи информации |
3.7.2. Описательная информация об элементах данных
Для каждого элемента данных указываются синонимы. Синонимы могут возникать из-за того, что пользователи в разных отделах одному и тому же понятию дают разные имена, например, служащие на складе называют НОМЕРОМ ТРЕБОВАНИЯ, а занимающиеся закупочной деятельностью - НОМЕРОМ ЗАКАЗА. Возможно возникновение синонимов также из-за определения одного и того же элемента в программах, написанных на разных языках или различными программистами. НОМЕР ТРЕБОВАНИЯ (REQUISITION-NUMBER) может существовать как REQUISNU, REQNU, PUR 7061 и в виде других внутренних псевдонимов. Можно записать все из них и включить их не только как НОМЕР ТРЕБОВАНИЯ, но и отдельно, в их собственной словарной статье. Поэтому, если мы просматриваем старую документацию и находим PUR 7061, то можем найти словарную статью, говорящую:
"PUR 7061 псевдоним НОМЕРА-ТРЕБОВАНИЯ"
и, обратившись к НОМЕРУ-ТРЕБОВАНИЯ, найти все необходимые подробности.
Мы можем также обдуманно создавать псевдонимы для своей новой системы. Например, в какой-нибудь системе все имена данных имеют максимально восемь знаков. Следовательно, мы можем назвать элемент данных REQUISNU и при необходимости объединить с "внешним" синонимом НОМЕР-ТРЕБОВАНИЯ.
Для каждого элемента данных указывается его тип. Предусмотрены следующие типы элементов данных:
| Непрерывные данные |
| Дискретные данные |
| Аналоговый сигнал |
| Дискретный сигнал |
3.7.2.1. Непрерывные данные
Непрерывные данные - это данные, которые на практике могут принимать любое значение в пределах диапазона, например, сумма в рублях может быть от нуля до 999999,99 с точностью до копейки или температура - от 0 до 300о
Для непрерывных данных указывается
| Единица измерения |
| Диапазон значений |
| Типичное значение |
| Точность< /td> |
| Кодировка |
Единица измерения - это строка символов, например
Диапазон значений определяется минимальным и максимальным возможным значением. Например элемент данных СУММА К ОПЛАТЕ на счете может принимать значение от 1 до 100000 руб. При этом точность определяет, следует ли нам учитывать копейки или нет: если
то значения на счете должно быть указано с точностью до копейки.
Типичное значение (если таквое существует) может быть полезным при последующем проектировании входных и выходных форм.
Кодировка - это форма, в которой элемент данных будет физически кодироваться в системе, например, будет ли число храниться на диске в виде упакованного десятичного числа или передача по коммуникационной линии будет осуществляться в ASCII (стандартный американский код для обмена информацией) или в EBCDIC (расширенный двоично-десятичный код для обмена информацией) кодировке. В действительности может понадобиться несколько способов кодировки, поскольку один и тот же элемент данных может проходить по коммуникационной линии в виде символов ASCII, обрабатываться различными программами в виде EBCDIC и/или двоичного кода и храниться на диске в виде упакованных десятичных чисел. Эти физические решения не осуществляются аналитиком и не образуют часть логической функциональной спецификации.
Поле "кодировка" заполняется только для потоков данных, идущих от/во внешних источников, когда сама кодировка является внешним условием. В этом случае у нас нет управления физическим форматом, поэтому аналитику следует отметить кодирование этого потока в словаре данных. Чаще всего участия аналитика на таком подробном уровне не требуется, оно может быть ограничено указанием типа внешних данных (цифровые, чисто буквенные или буквенно-цифровые).
3.7.2.2. Дискретные данные
Номер отделения |
||
Значение |
Смысл |
|
36 |
Отдел сбыта |
|
08 |
Бухгалтерия |
|
29 |
Склад |
|
71 |
Отдел рекламы |
|
Семейное положение |
||
Значение |
Смысл |
|
Ж |
Женат |
|
Х |
Холост |
|
Р |
Разведен |
|
В |
Вдовец |
|
Дискретные данные - это данные, которые могут принимать только определенные значения, например, номер отдела, который может быть равен 36,08,29 или 71. Другим примером этого второго типа может быть семейное положение, которое может принимать значения "холост", "женат", "вдовец", "разведен". Обычно значения являются кодом, означающим некий смысл. Для дискретных данных заполняют таблицу значений в формате, приведенном на рис. 31. Кроме того, аналогично непрерывным данным, для дискретных данных, связанных с внешними системами, может быть указана кодировка.
Рис. 31. Формат таблицы значение-смысл для дискретного данного
3.7.2.3. Аналоговые сигналы
Аналоговые сигналы - это, как правило, измерительные данные от различного рода датчиков. Для них указывается
3.7.2.4. Дискретные сигналы
Дискретные сигналы
- это, как правило, сигналы от датчиков положения (состояния) тех или иных устройств. Для них указывается3.7.3. Рекомендации по описанию данных
| Аналитик не должен указывать диапазон на первом этапе создания базы данных проекта, а может осуществить это на более позднем этапе. |
| Аналитик должен решать, когда имеет смысл перейти от рассмотрения элемента данных как дискретного, к непрерывному. Как показывает опыт, если таблица значение/смысл может быть напечатана на одной или двух сторонах листа, то следует занести значения в базу данных проекта кроме этого обычно более разумным оказывается определение накопителя данных, в котором будет храниться смысл значений. |
Например, НОМЕР-ДЕТАЛИ можно рассматривать как дискретный элемент данных. Каждое значение имеет определенный смысл:
7А4601В означает "Стержень щелевой, 71/4 дюйма"
и т.д. Но в технической организации может быть 40000 деталей и вряд ли стоит хранить все эти значения и приписываемый им смысл в словаре данных. Здесь излишним является наше естественное желание хранить другие атрибуты каждой детали: ее вес, цену, поставщика и т.д. Таблица же значений для дискретного элемента данных должна служить только для связи значения с соответствующим смыслом и ни для чего более.
Дискретные элементы данных применяются также для определения прилагательных, определяющих диапазон знаний. Температура является непрерывным элементом данных с соответствующим для данных целей диапазоном. Но нам может потребоваться называть температуру выше 35ш - ВЫСОКАЯ, в диапазоне от 18ш до 34ш - НОРМАЛЬНАЯ, а ниже 18ш - НИЗКАЯ.
Мы будем определять "ВЫСОКАЯ", "НОРМАЛЬНАЯ" и "НИЗКАЯ" как значения дискретного элемента данных "ДИАПАЗОН-ТЕМПЕРАТУРЫ", смысл которого описан через непрерывный элемент данных "ТЕМПЕРАТУРА".
Глава 4. План построения модели системы
План построения информационно-логической модели системы
В настоящем разделе приводится рекомендуемый нами план построения информационно-логической модели проектируемой (анализируемой) системы.
При этом предполагается, что информационно-логическая модель строится последовательно по шагам, причем каждый предыдущий шаг должен быть завершен до выполнения последующего шага.
Построение информационно-логической модели - итерационный процесс, поэтому возможен возврат на какое-то количество шагов назад. Следует придерживаться правила, что если были пересмотрены решения, то следует внимательно изучить влияние этих изменений на все последующие шаги и, при необходимости, внести в них изменения.
Шаг 1. Предварительное изучение
Шаг 2. Выявление контекста системы
Шаг 3. Детализация подсистемы (этот шаг повторяется для каждой подсистемы)
4.1. Верификация модели
Верификация информационно-логической модели - очень важная и ответственная часть анализа требований. Верификация - это контроль полноты и согласованности модели системы. Результаты верификации могут потребовать пересмотра модели, и поэтому всегда есть соблазн опустить этот шаг анализа. Но если Вы хотите получить качественный анализ - этот шаг неизбежен!
Принципиальные решения по верификации проекта делаете Вы. Эти решения Вы принимаете по результатам простых, но очень трудоемких процедур контроля и верификации, которые CASE.Аналитик выполняет автоматически и по запросу.
CASE.Аналитик предоставляет следующие средства верификации:
| автоматический контроль выполнения формальных правил построения модели при вводе и редактировании: Вы просто не сможете сделать неверное действие; |
| автоматическая поддержка согласованности при детализации подсистем, процессов и данных, т.е. при переходе с уровня на уровень; |
| верификация по запросу согласованности модели; |
| вывод на дисплей и печать разнообразных отчетов, которые могут быть использованы для верификации. |
Глава 5. Пошаговые процедуры
Пошаговые процедуры построения информационно логической модели системы
5.1. Шаг 1. Предварительное изучение
Предварительное изучение должно ответить на ряд вопросов:
| В чем недостатки существующей ситуации? |
| Какие улучшения возможны? |
| На кого окажет влияние новая система? |
В любой организации может возникнуть необходимость в улучшении обработки данных. В то время как некоторые из этих ситуаций могут быть исправлены улучшением операций, такими, как уменьшение времени реакции на запрос, а некоторые - расширением существующих систем, скажем, получение нового отчета, содержащего существующие данные, многие связаны с разработкой новой системы. CASE.Аналитик предназначен для анализа как существующих, так и новых систем. Последний вариант наиболее сложен и мы, главным образом, касаемся именно новых разработок.
Многие организации считают, что требования к новой системе в несколько раз превышают их возможности для ее построения. Действительно, по мере ввода все новых и новых систем, задача введения в них желаемых расширений отнимает у имеющегося персонала, все больше времени, в некоторых случаях достигая 50-60% всего штата разработчиков. Следовательно, системы, отбираемые для построения, должны демонстрировать значительные выгоды для большинства руководителей организации и соответствовать общему плану развития организации. Предварительное изучение (иногда называемое оценка запроса) является отчасти процессом отбора перспективных запросов на разработку, и осуществляется быстро и дешево (так как само по себе изучение требует небольшого количества специалистов и времени).
Предварительное изучение может потребовать от двух дней до четырех недель (в редких случаях дольше).
Полезно помнить об основополагающих причинах, по которым разрабатываются новые системы. Организация либо пользуется удобным случаем (увеличить доход, избежать убытки или улучшить обслуживание), либо реагирует на давление, оказываемое либо государственными органами, либо конкуренцией.
5.1.1. Шаг 1.1. Определение круга лиц, принимающих решения по реализации проекта
Аналитику следует попытаться выявить какие физические лица ответственны за принятие проектных решений:
| по финансированию проекта (Заказчик) |
| цели и задачи (Консультант) |
| согласование проекта |
| утверждение проекта |
| этапы проекта |
и др.
Часто это может быть одно и то же лицо или несколько лиц, принимающих различные решения. Эти лица могут оказаться не слишком легко доступными для аналитика. В этом случае следует добиваться, чтобы были определены специалисты, представляющие этих лиц в данном проекте и которым будет поручено осуществлять помощь аналитику.
Часто назначается связующий представитель пользователя, обычно это руководитель среднего звена, знающий конкретный случай применения и несущий ответственность за принятие подробных спецификаций. В некоторых организациях было отмечено, что чем важнее пост занимает представитель пользователя и чем больше времени он может уделить проекту, тем больше вероятность конечного успеха. Например, если помощник руководителя по сбыту может быть назначен на неполную рабочую неделю для помощи аналитику в определении подробных требований к новой системе, его участие и полномочия вероятно обеспечат то, что каждый в сообществе пользователей проведет тщательное обдумывание своих требований и обеспечит аналитика полной и своевременной информацией. В некоторых организациях пошли дальше и назначают "главного руководителя-исполнителя", придавая ему необходимый персонал для разработки системы. В любом случае следует сделать все возможное для активного вовлечения старших по должности в этот процесс.
Кроме того, где это возможно, желательно определить конкретных лиц - будущих пользователей системы.
Если будущая система должна удовлетворять каким-то регулирующим нормативам и согласовываться с организациями, осуществляющих надзор за их соблюдение, необходимо также определить круг лиц, принимающих эти решения и их представителей.
Сведения о лицах и организациях, причастных к проекту, заносятся в базу данных проекта.
5.1.2. Шаг 1.2. Получение информации о системе и/или об объектах автоматизации
Аналитик должен изучить запрос и встретиться с руководителями, сделавшими запрос, с тем, чтобы получить обоснование ситуации и приступить к оценке вероятных затрат на новою систему. Следует получить ответы на вопросы:
| Можно ли в цифрах оценить доходы, которые мы не получаем, связанные с недостатками существующей системы? |
| Каковы издержки в настоящее время и от которых можно избавиться, введя лучшую систему? |
| Можно ли оценить в рублях (долларах) улучшенное обслуживание, предоставляемое с введением новой (модернизированной) системы? |
Наряду с интервьюированием соответствующих лиц аналитику следует затребовать и изучить любую документацию, связанную с существующими ограничениями. Ему следует рассмотреть план разработки (если таковой существует!), найти всю возможную информацию о том, как обстоит дело у других организаций в данной области.
В случае, когда анализируется существующая автоматизированная система, следует получить все имеющиеся документы на систему, включая распечатки выходных документов, других печатных и экранных форм и листинги программ. Это могут быть:
| Техническое задание на разработку системы. |
| Описания действующих систем и сами системы. |
| Описания автоматизируемых процессов< /font> |
| Существующие подсистемы, подлежащие включению в систему. |
| Различного рода неформальные документы, касающиеся разрабатываемой системы - протоколы переговоров заказчика и исполнителя и т.п. |
В процессе построения модели аналитик идентифицирует многие элементы и структуры данных. Если структура файлов действующей системы хорошо документирована, то это является дополнительным источником для определения данных.
Ссылки на собранные источники следует ввести в базу данных проекта и в дальнейшем при анализе ссылаться на эти источники. Это поможет аналитику в дальнейшем снять многие вопросы, возникающие при презентации и защите проекта.
Следует выяснить и ввести в базу данных проекта следующие исходные данные:
5.1.3. Шаг 1.3. Выяснение ограничений и внешних обстоятельств ввода новой системы
В тех случаях, когда система должна отвечать требованиям закона и/или государственных органов, аналитик должен определить дату, когда разрешение должно быть получено, и каково наказание за просрочку. Руководству следует предложить определить в самых общих чертах преимущества внедрения улучшенной системы, и указать другие аспекты деятельности организации, на которые повлияет новая система. Если потребуется, необходимо проинтервьюировать Руководителей, связанных с этими аспектами, с тем, чтобы получить подобную информацию.
Ввод новой системы обязательно повлияет на существующие подразделения предприятия. Аналитику следует выяснить перечень этих подразделений и внести его в базу данных проекта. Следует также внести в базу данных проекта сведения о руководителях этих подразделений и, в дальнейшем, привлечь их к презентации и согласованию проекта.
5.1.4. Шаг 1.4. Выяснение целей создания/модификации системы
Существуют несколько направлений, на которых новая система может внести вклад в достижение целей усовершенствования обработки информации:
| Предоставляя существующую информацию, но более быстро, т.е. предоставляя немедленный доступ к информации, которая сейчас появляется только в недельных отчетах или предоставляя данные о продажах каждый вечер, а не каждый месяц, или поминутные балансы счетов вместо балансов по заключенным вчерашним сделкам. |
| Предоставляя более точную информацию либо в смысле арифметической точности, либо при помощи более точного и общепринятого представления. Следует помнить, что некоторые пользователи говорят о более точной информации, имея ввиду более новую информацию. |
| Предоставляя информацию, основанную на большем количестве данных, как в случае, когда система, которая никогда не хранила информацию об обучении служащих, заменяется на такую, которая имеет дело с детальными сведениями о посещении курсов и приобретенном опыте. Это подразумевает создание нового архива данных либо расширение содержания существующего. |
| Предоставляя информацию, основанную на новых логических функциях. Когда при помощи анализа временных рядов, исходя из имеющихся данных месячных продаж, рассчитывается профиль тренда, база данных остается той же, но вводится новая логическая функция. |
Как правило, требования являются комбинацией этих целей. Пользователь желает иметь больше информации, чем сейчас, получать ее обновленной, анализировать ее более сложным образом и получать ответ быстрее!
Это именно тот случай, когда аналитику полезно понять систему и разбить сложные требования на компоненты.
Полезно отделить организационные цели, такие как увеличение дохода, снижение затрат или улучшение обслуживания, от целей системы, сущность которых состоит в следующем: что будет делать система для того, чтобы помочь руководству достичь организационных целей?
Мы должны отметить, что достижение цели системы необязательно означает достижение организационной цели. Если мы обеспечиваем руководство большим объемом информации, более свежей, лучше организованной и делаем это быстрее (цель системы), это не значит, что его затраты будут снижены. Руководитель должен действовать, учитывая эту информацию, или использовать возможности, представляемые системой. Иногда руководство раздражают предположения относительно того, что новая система автоматически будет делать для них больше денег. В ряде случаев система может непосредственно экономить деньги, как в случае с использованием системы, контролирующей потребление энергии и снижающей ее потери чаще однако, система только дает возможность руководству достичь свои цели.
Цели могут быть сформулированы строго или нестрого. Строго сформулированная цель снижает вероятность разногласий на момент ее выполнения. Предположим, что мы установили цель для системы "Быстрее предоставлять ежемесячный отчет о состоянии дел" и на практике новая система будет предоставлять отчет восьмого числа каждого месяца вместо десятого. Такая ситуация едва ли выручит нас, если Директор имел в виду представление отчета о состоянии дел второго числа каждого месяца! Каждая цель должна рассматриваться с учетом возникновения таких несоответствий и должна формулироваться как можно точнее. На рис. 32 представлены цели, имеющие строгие и нестрогие формулировки.
| Нестрого сформулированная | Строго сформулированная |
| 1. Улучшить своевременность представления докладов | Обеспечить представление ежедневного отчета по продажам к 9 часам утра |
| 2. Обеспечить меньшее количество ошибок при выписывании счетов | Уменьшить количество счетов, возвращаемых заказчиками как ошибочные, до < 0,5% от количества счетов, высылаемых еженедельно |
| 3. Улучшить качество отчетов | Указать оплаченные чеки в общем перечне чеков |
| 4. Обеспечить всесторонний анализ | Представить усредненный за 3 месяца список продаж, осуществленных торговым агентом, группой по сбыту и в отрасли |
Рис. 32. Цели, сформулированные строго и нестрого
Отметим, что одна нестрого сформулированная цель может включать семейство строго установленных целей, а каждая строго сформулированная быть связанно с самыми разными физическими системами.
При разработке логической модели из множества строго сформулированных целей следует выбирать те цели, которые наиболее полно удовлетворяют требованиям. На этой стадии аналитик старается определить систему, которая отвечает каждому пожеланию пользователя.
Выясненные цели проекта следует строго сформулировать и занести в базу данных проекта.
5.1.5. Шаг 1.5. Верификация предварительного изучения
На этом шаге CASE.Аналитик выдаст по Вашему запросу результаты верификации на полноту исходных данных. В сводной таблице Вы увидите, все ли исходные данные введены в базу данных - весьма вероятно, что если их нет в базе данных, то они не были определены вообще. Аналитику следует осознанно подойти к каждому такому факту и ответить на вопрос:
Если эти данные существуют и важны для проекта, их следует выявить и внести в базу данных проекта.
5.1.6. Шаг 1.6. Оценка реализуемости проекта
К концу предварительного изучения аналитик должен разумно оценить преимущества внедрения новой системы. Ему желательно знать, является ли запрос результатом озарения одного руководителя, и связан ли этот запрос с экономией всего лишь 10000 рублей в год или, другая крайность, является ли он чем то, что могло бы ускорить оборот 100 млн. рублей на несколько процентов.
Аналитику полезно будет изобразить контекстную диаграмму или диаграмму потоков данных верхнего уровня для существующей системы и ее интерфейсы.
Аналитик должен быть готов оценить временные затраты и стоимость фазы детального анализа (следующих шагов анализа), и у него может появиться предварительная оценка стоимости новой системы. Ему следует быть очень осторожным в обосновании общих оценок проекта имеется большое давление со стороны пользователей и руководства с тем, чтобы определить бюджет проекта как можно раньше. Кроме того опыт показывает, что твердая цена не может быть дана до тех пор, пока число и стоимость модулей системы неизвестны, а точнее, пока не будет выполнен полный проект физической системы. Наилучший способ - это указать достаточно широкие пределы временных затрат и стоимости для проекта в целом и дать твердые цифры только для следующей фазы.
Таким образом результаты предварительного изучения могли бы выглядеть следующим образом:
5.2. Шаг 2. Выявление контекста системы
На этом шаге определяются внешние условия функционирования системы. Контекст системы составляют внешние объекты, взаимодействующие с системой, порождая входную и принимая выходную информацию.
Результаты предварительного изучения рассматриваются руководством соответствующего уровня. У многих организаций имеется некий орган, куда входят старшие руководители, направляющий развитие систем обработки данных. В зависимости от совокупности приоритетов, политики и фактов, установленных на стадии предварительного изучения, может быть санкционирована возможность детального анализа. Для всех заинтересованных лиц должно быть ясно, что детальное изучение не является попыткой выполнения проекта. В сущности руководство говорит: "Выглядит многообещающе расскажите поподробнее". Детальный анализ строится на фактах, выявленных во время предварительного изучения, и предполагает более детальное м точное документирование ограничений существующей системы, а также уточнение функций этой системы до уровня, необходимого для написания спецификаций модернизированной системы.
Поскольку на данном шаге решение о создании системы может быть не принято, аналитик может решить вообще не исследовать детализированную логику функций существующей системы, а лишь идентифицировать функции. Также этот подход следует использовать в отношении любых функций, которые, по сведениям аналитика, не будут включены в какую-либо новую систему. Такое же решение, соответствующее здравому смыслу, следует принять и в отношении базы данных проекта данных.
По мере создания логической модели аналитик должен также учитывать любые входные данные, которые, очевидно, больше не будут использоваться, и отчеты, которые больше не представляют интереса, или могут быть заменены специальными отчетами или запросами. Такие избыточные выходные данные и связанные с ними функции могут быть представлены в краткой форме.
5.2.1. Шаг 2.1. Определение будущих пользователей системы
Можно представить сообщество пользователей в виде трехуровневой иерархии:
Уполномоченные, такие, как директор, заместитель директора по производству прогнозируют развитие на период средней продолжительности, в 3-5 лет, и, определяют, на этой базе что это является существенным для принятия решения о финансировании проекта. Они могут оценить малейший выигрыш, даже если они не могут его выразить в рублях. Они стремятся быть очень заинтересованными в тех аспектах системы, которые увеличивают их реальный или видимый контроль над бюджетом, так как одна из самых поразительных особенностей, касающихся старших руководителей, заключается в том, что они должны брать на себя ответственность за некоторые действия, не имея больше возможности соприкасаться с их деталями.
Там, где считают, что системы должны работать более чем в одной из главных функциональных областей, высшие руководители, возможно, захотят от системы различных свойств, и будут "тянуть" систему в разные стороны. Для руководителя по продажам традиционно требовать короткое время доставки, поскольку это позволит ему улучшить обслуживание клиентов и максимально увеличить объем продаж, за что они и платят. Точно также, традиционным для руководителей по производству является требование длительного времени доставки, так как это позволяет улучшить график производства и снизить себестоимости, и это то, за что они платят. Если аналитику не повезет, и он и система могут оказаться втянутыми в изнурительную борьбу, возникновение которой само по себе показывает, что ни один из руководителей не удовлетворен кратким изложением целей и функций. Ясно, что сам аналитик не может разрешить подобную ситуацию если он подозревает, что он вынужден служить двум хозяевам, которые не могут прийти к согласию, он должен поискать поддержку у своего руководства, которое должно, при необходимости, довести ситуацию до старшего администратора с тем, чтобы разрешить ее.
Средние руководители стремятся меньше заниматься стратегией и больше заняться краткосрочными планами деятельности своего подразделения, нежели бюджетом. Аналитик сталкивается с необходимостью обосновывать затраты на новую систему и ее влияние на персонал, а также должен быть готовым к сопротивлению со стороны средних руководителей, которые опасаются того, что разработка новой системы может отнять у них власть и автономию. Средние руководители часто озабочены проблемами подбора и сохранения соответствующего персонала и если аналитик сможет показать, как новая система облегчит эти проблемы, он приобретет союзников.
Что касается служащих, на работе которых скажется введение новой системы, аналитик должен сделать все возможное, чтобы их работа с установкой системы стала более приятной и интересной. Во время анализа следует снова убеждать служащих в благоприятном воздействии новой системы на их работу посредством обсуждений и демонстраций. Как часть детального анализа аналитик должен ознакомиться с работой служащих, вовлеченных в изучение. Если время позволяет и это возможно, аналитик должен сам в течении короткого времени выполнять одну из обязанностей (скажем, телефонного клерка). Это даст ему богатую информацию из первых рук, которую было бы трудно, если вообще возможно, получить из интервью.
В тех случаях когда аналитик за время предварительного изучения не встретился со старшими администраторами, он должен попытаться выяснить их точку зрения на цели, преследуемые при создании системы, во время детального анализа. В идеале следует проинтервьюировать каждого среднего руководителя, на чье подразделение окажет влияние новая система, но, обычно, это невозможно ввиду ограниченного времени, особенно, если организация географически не локализована. По крайней мере, аналитику следует приобрести или подготовить сегодняшнюю схему организации соответствующих подразделений, их руководителей и их функции. Он должен определить число служащих и понять их задачи.
Сведения обо всех лицах, выявленных на этом шаге, следует занести в базу данных проекта.
5.2.2. Шаг 2.2. Построение иерархии контекстных диаграмм
Исходя из информации, полученной в предварительном исследовании и при определении сообщества пользователей, аналитик создает вариант контекстной диаграммы системы. Может оказаться непросто определить границы системы. При этом необходимо решить, какие функции необходимо рассматривать как часть системы, какие - нет. Контекстная диаграмма позволяет аналитику свести каждую из взаимосвязанных систем к единой терминологии и увидеть, как они сочетаются.
Просмотрите материалы, собранные на шаге предварительного изучения, и обозначьте имеющиеся внешние сущности системы. Как было сказано ранее, это потребует определения предварительных границ системы. Если у вас имеются сомнения насчет правильности определения границ, включите в пределы вашей системы первый "внешний слой" автоматизированных систем и систем с ручным управлением, с которыми вы должны осуществить связь.
По мере определения внешних сущностей информация о них заносится на контекстную диаграмму и в базу данных проекта. После инициализации проекта CASE.Аналитик автоматически приглашает к построению контекстной диаграммы верхнего уровня. На этом этапе более детальную информацию о внешних сущностях можно не заносить в базу данных проекта.
Далее определяют подсистемы. Для простых систем такая структуризация не нужна и в проекте будет иметься единственная контекстная диаграмма с единственной подсистемой.
Естественно, система, показанная на контекстной диаграмме, является слишком общей - она создана на столь высоком уровне абстракции, что является достаточно бесполезной. Тем не менее, используя ее как "карту леса", мы сможем при дальнейшей ее детализации получить результат на любом выбранном уровне проработки деталей.
Однако для достаточно сложных систем понадобится структуризация уже при определении контекста. Признаками сложности ( в смысле контекста) могут быть:
| Наличие большого числа внешних сущностей (десятки и более); |
| Распределенная природа системы; |
| Многофункциональность системы с уже сложившейся или выявленной группировкой функций по некоторым функциям в отдельные подсистемы. |
В этом случае выявленные подсистемы, аналогично внешним сущностям, заносятся на диаграммы и в базу данных.
Сложная система может потребовать в дальнейшей детализации подсистем при помощи иерархии контекстных диаграмм.
Далее необходимо определить и поместить на диаграмму информационные потоки, соединяющие выявленные внешние сущности и подсистемы. Установите планируемые входные и выходные данные, которые вы ожидаете, и те, которые имеют место при нормальном ходе деловых отношений. По мере того, как этот перечень будет расти, постарайтесь провести логическое группирование входных и выходных данных. Отметьте входные и выходные данные, которые приводят к возникновению ошибок и исключительным условиям.
Идентифицируйте запросы и требования на информацию, которые могут возникнуть. Определите потоки, которые соответствуют информации, "передаваемой" системе, и потоки данных, которые сообщают, что "запрашивается" от системы.
Помните, что потоки данных создаются при условии, что что-то происходит во внешнем мире: покупатель решает что-то приобрести, происходит авария или грузовой автомобиль прибывает для погрузки или разгрузки. Если возможно, установите основные источники ваших данных и, исходя из этого, стройте диаграмму.
На этапе построения контекстных диаграмм можно не заниматься определением содержания потоков данных, а сделать это позже, на шагах детализации подсистем и процессов.
Отметим, что на диаграммах не показывают перемещение самих предметов для наших целей предметы не являются данными, и поэтому они не включаются в диаграммы. В данный момент нас интересуют только элементы, которые являются данными о предметах.
Строя диаграммы, не обращайте внимание на временные соображения, за исключением естественной логической временной последовательности, и логически необходимых накопителей данных. Постройте систему, которая никогда не стартует и никогда не останавливается.
Следует помнить, что вам может потребоваться разработать несколько редакций контекстных диаграмм. Пусть вас не беспокоит, что первый проект будет выглядеть беспомощным, спутанным клубком, в дальнейшем он может быть улучшен. И если разработка нескольких вариантов диаграмм или их редактирование немыслимо вручную, то CASE.Аналитик дает все необходимые средства для автоматизированного редактирования диаграмм.
5.2.3. Шаг 2.3. Верификация контекстных диаграмм
1. К моменту окончания построения контекста Вы должны иметь следующую информацию:
| Определение сообщества пользователей для новой системы. |
| Имена и ответственность руководителей и других причастных лиц. |
| Функции и взаимодействие подразделений, на которые повлияет новая система. |
| Оценка увеличения дохода, сокращения затрат и улучшения обслуживания, которые могут быть получены в результате внедрения модернизированной системы. |
| Иерархия контекстных диаграмм; |
| Определения данных на соответствующем уровне детализации. |
2. Проверьте построенную Вами модель на полноту и непротиворечивость. CASE.Аналитик предоставит Вам следующие возможности для проверки:
| на полноту исходных данных структурных объектов системы; |
| на изолированность объектов.< !--msthemelist--> |
При этом, на данном этапе проекта не следует проверять объекты на детализацию, так как сейчас большинство подсистем и потоков данных детализировать не требуется.
CASE.Аналитик после верификации структурных объектов - внешних сущностей, подсистем и информационных каналов - может обнаружить несоответствия, перечисленные ниже.
| Объект | Все структурные объекты. |
| Несоответствие | Отсутствует комментарий. |
| Причина | Это несоответствие напоминает Вам о том, что нет дополнительной информации о данном объекте эта информация может быть полезна Вам при дальнейшем анализе, а также при документировании комментарий попадает в генерируемые CASE.Аналитиком макеты документов. В любом случае Вам следует еще раз убедиться, что Вы действительно не считаете нужным комментировать данный объект. |
| Объект | Внешняя сущность. |
| Несоответствие | Изолированный объект. |
| Причина | У данного объекта отсутствует информационная связь с системой. Вам следует понять, - либо данный объект следует исключить (удалить) из системы, либо использовать его в системе в качестве источника и/или приемника данных. В последнем случае нужно связать объект с системой информационными потоками. |
| Объект | Подсистема, информационный канал. |
| Несоответствие | Отсутствие входных потоков или выходных потоков. |
| Причина | Каждая подсистема или
информационный канал есть либо преобразователь
информации, либо ее передатчик. Поэтому, если
некий процесс лишь выдает информацию, то Вы
должны решить вопрос о том, какая информация для
него является исходной: информация не может
рождаться внутри системы, она может лишь
преобразовываться и передаваться. Аналогично, если некий процесс лишь потребляет информацию, следует понять, для чего он введен и определить, какую информацию он выдает. Информационный канал есть передатчик информации, поэтому у него должны быть входы и выходы. |
| Объект | Поток данных, поток управления. |
| Несоответствие | Отсутствует приемник или источник |
| Причина | При детализации подсистемы или процесса информационный поток оказался "висячим". Следует решить, с какой из подсистем его соединить. |
3. Получите при помощи CASE.Аналитика перечень внешних сущностей и сверьте его с перечнем, который Вы получили при просмотре исходных документов. Обсудите все несоответствия, с тем, чтобы понять:
| действительно ли некоторые внешние сущности оказались забытыми? Если да, то их необходимо ввести в модель и связать информационными потоками с системой; |
| означают ли внешние сущности с различными именами одну и ту же логическую сущность? Если это так, то следует оставить в проекте одну сущность с наиболее общим именем, перебросив потоки данных от остальных сущностей, а их имена ввести в список синонимов одной сущности. |
4. Получите при помощи CASE.Аналитика перечень входных и выходных данных и сверьте его с перечнем, который Вы получили при осмотре исходных документов. Убедитесь, что Вы включили все входы и выходы.
5. Просмотрите контекстные диаграммы и убедитесь, что на них нет изолированных друг от друга частей - действительно, нет смысла анализировать в одном проекте несколько независимых систем. Вам следует решить: либо определить информационные связи между изолированными частями проекта, либо удалить эти части.
6. Получить при помощи CASE.Аналитика список связей структурных объектов. Внимательно просмотрите его (возможно с другими заинтересованными лицами) и убедитесь, что ничего неожиданного Вы не обнаружили. Если же у Вас возник вопрос типа: "Действительно ли эти подсистемы связаны между собой?", - то следует проанализировать ситуацию и, возможно, внести коррективы в проект.
5.2.4. Шаг 2.4. Согласование контекстных диаграмм
На этом шаге аналитик должен распечатать документацию проекта и согласовать ее с заинтересованными лицами. Для предварительного согласования, возможно, Вы ограничитесь печатью только диаграмм, результатов верификаций и различных перечней.
Согласование осуществляется с заинтересованными лицами, выявленными на шаге предварительного исследования. Просмотрите внимательно подготовленные материалы вместе и отметьте какие-либо изменения, возникающие в результате этой работы.
Все изменения, возникающие в процессе согласования, необходимо занести в базу данных проекта и при необходимости подготовить новые документы и повторить согласование.
5.2.5. Шаг 2.5. Презентация проекта
Цель презентации - представить результаты анализа в максимально наглядной форме весьма занятым лицам - лицам, принимающим решения по проекту и на сферу деятельности которых повлияет внедрение системы.
Для презентации аналитику следует подготовить наиболее важные контекстные диаграммы большого формата и краткий отчет. Отчет может быть организован либо как документ, регламентированный стандартами, либо как набор распечаток CASE.Аналитика с сопроводительным поясняющим текстом.
При подготовке материалов для презентации следует основное внимание уделить наглядности и краткости информации.
В этом случае пользователи-руководители получают четкое представление о том, какова ситуация в настоящее время и как сочетаются между собой составляющие части системы. (Обычный комментарий: "В первый раз я понял, что собой представляет эта система"). Аналитик должен быть также готов услышать больше критических замечаний при представлении диаграммы, чем при использовании традиционных подходов, поскольку диаграмму легче понять, а также пользователям легче увидеть какие-либо несоответствия и ошибки в диаграмме (что, в конце концов, является одной из целей презентации).
В результате презентации обычно принимается решение о продолжении разработки проекта на следующей фазе или о прерывании этой работы. Иногда группа руководителей говорит: "Создайте наилучшую новую систему, которую можно только получить за n-ую сумму рублей". Их нужно, по возможности, попросить отсрочить установление точной суммы бюджета до получения результатов анализа следующего шага и определения альтернативных решений.
Аналитик в присутствии своего руководителя делает сообщение, охватывая следующие аспекты:
| Рассмотрение имеющейся в настоящее время системы (если таковая существует) при помощи диаграмм. |
| Ограничения, имеющиеся в данной системе или ситуации. Если для одной и той же группы руководителей представление было организовано после детального исследования, то эти ограничения следует резюмировать. В противном случае, стоит потратить 5-10 минут на объяснение смысла целей и стоящих за ними фактов, поскольку это важная исходная информация для пользователей принимающих решения. |
| Логическая модель новой системы на основе контекстных диаграмм потоков данных, представляющая наиболее общий вариант, указывая новые функции, которые будут включены в систему. |
У группы руководителей возникнет несколько вопросов после этого представления возможно, они смогут добиться согласия при непосредственном выборе альтернативы или же потребуют от аналитика оценки некоторых компромиссных альтернатив. Они могут потребовать предоставления им отчета для самостоятельного рассмотрения в любом случае происходит диалог, приводящий к достижению согласия о природе системы, которую предстоит построить, а аналитик и проектировщик получают указание представить твердый бюджет затрат и времени (в пределах уже указанного диапазона оценок).
Этот процесс напрямую вовлекает руководителей-пользователей в выбор целей проекта и ресурсов. Более вероятно, что сообщество пользователей "овладеет" проектом в результате такого процесса, а не при рассмотрении его в качестве "другого бессмысленного дела, связанного с отработкой данных", - т.е. того, что программисты замышляют для своих собственных целей, которые могут служить или не служить потребностям организации. Это погружение в проект и вовлечение высших руководителей-пользователей являются одним из ключевых факторов успешного осуществления или провала проектов, связанных с обработкой данных, что подтверждалось неоднократно.
Собрать группу руководителей и представителей пользователей вместе в одном и том же помещении в одно и то же время для того, чтобы осуществить формальное представление вариантов достаточно трудно. Если специалисты, принимающие решения, разбросаны по большому региону или имеют несовпадающие графики работы, то аналитик может посчитать разумным проведение серии представлений для каждого из них. Если это не является экономически оправданным, то должен быть написан и распространен отчет с целью получения замечаний, хотя это наименее удовлетворительный способ достижения согласия по этим вариантам.
5.2.6. Шаг 2.6. Выпуск документации на уровне контекста
Все изменения, возникшие в результате обсуждения проекта на презентациях, вносятся в базу данных проекта, и при необходимости документация распечатывается и рассылается заинтересованным лицам.
5.3. Шаг 3. Детализация подсистемы
Этот шаг повторяется для каждой подсистемы.
5.3.1. Шаг 3.1. Разработка диаграмм управляющих потоков
Если у подсистемы имеются входные и/или выходные управляющие потоки, то ее детализация осуществляется при помощи диаграммы управляющих потоков.
На диаграмме должен быть, по крайней мере, один управляющий процесс, в который поступают все управляющие потоки и который порождает управляющие потоки, взаимодействующие с информационными процессами.
5.3.2. Шаг 3.2. Определение содержания управляющих потоков
На этом шаге Вам следует описать содержание управляющих потоков. Следует избегать структурирования содержания управляющих потоков, т.е. следует описывать содержание потока управления в виде простого перечня событий.
5.3.3. Шаг 3.3. Построение иерархии диаграмм потоков данных
Подсистемы, которые Вы ввели на контекстных диаграммах и не связанные с другими подсистемами управляющими потоками, детализируются при помощи диаграмм потоков данных.
Процессы, которые Вы ввели на диаграммах потоков управления, могут быть детализированы либо при помощи диаграммы потоков данных, либо при помощи миниспецификаций.
Миниспецификация является конечной вершиной иерархии диаграмм информационно-логической модели и применяется для описания логики простых процессов. Решение о завершении детализации процесса и применения миниспецификации принимается аналитиком, учитывая следующие критерии простоты:
| процесс имеет небольшое количество (2-3) входных и выходных потока данных; |
| преобразование данных процессом можно описать в виде последовательного алгоритма; |
| процесс выполняет одну единственную логическую функцию преобразования входов в выходы; |
| логику процесса можно описать при помощи миниспецификации небольшого объема - не более 2-3-х десятков строк. |
5.3.4. Шаг 3.4. Определение характеристик и содержания потоков данных
Содержание потоков данных определяется и уточняется по мере построения иерархии диаграмм потоков данных. Следует придерживаться следующего правила: при построении иерархии следует переходить к детализации процессов после определения содержания всех потоков данных.
Уточнение характеристик потоков данных включает в себя определение его временных характеристик - периода передачи и дополнительных сведений, которые вводятся в базу данных при необходимости. Дополнительные сведения включают в ссылки, синонимы, комментарии.
Содержание потока данных описывается при помощи структурограммы. Конечными элементами иерархии структурограмм являются элементарные данные и сигналы.
5.3.5. Шаг 3.5. Разработка логики процессов
Если процесс, который Вы ввели на диаграмме потоков данных, является элементарным, то его дальнейшая детализация не имеет смысла и записывается логика преобразования входных информационных потоков в выходные на структурном естественном языке, как это было рекомендовано выше. Важным на данном этапе является то, как установить, что процесс является элементарным. Мы предлагаем Вам следующую процедуру.
| Запишите полное назначение процесса. |
| Если у Вас возникли трудности с завершением описания назначения, то это означает, вероятнее всего, что процесс требует дальнейшего анализа и детализации - т.е. не является элементарным. |
| Если назначение содержит перечисление некоторых объектов, то следует детализировать процесс, назначив каждому объекту свой процесс процесс не является элементарным. |
| Если в назначении содержатся слова, связанные с последовательностью действий (вначале, затем, в противном случае и т.п.), то процесс следует детализировать так, чтобы назначить каждому действию свой процесс процесс не является элементарным. |
| Если в назначении присутствуют союзы "и" , "или", то это, вероятно, означает, что процесс выполняет набор функций его следует детализировать, назначив каждой функции свой процесс. |
5.3.6. Шаг 3.6. Верификация модели
На этом шаге Вы имеете законченную модель системы, которую следует верифицировать. Верификация исследует следующие вопросы:
| является ли Ваша модель действительно полной? |
| является ли модель согласованной? (непротиворечивой?) |
Заметим здесь, что целостность модели поддерживается CASE.Аналитиком автоматически.
5.3.6.1. Верификация полноты модели
В полной модели все ее объекты - подсистемы, процессы, потоки данных, данные - должны быть детально описаны или детализированы.
Убедиться в полноте модели с точки зрения детализации объектов можно двумя способами.
Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки.
Структурные объекты полной модели должны быть прокомментированы (или определено их назначение), для некоторых из них должна быть определена физическая реализация. Объекты, у которых отсутствуют эти атрибуты, помещаются в протокол верификации, и по каждому из них аналитику следует принять обоснованное решение, поскольку эта информация, помимо всего прочего, помещается в макеты документов.
CASE.Аналитик автоматически определяет при верификации наличие изолированных объектов, а также объекты (кроме внешних сущностей), которые либо только порождают данные, либо, как "черная дыра", только поглощают данные. Логически это неоправданно, так как все структурные объекты системы должны лишь преобразовывать одни данные в другие.
Полный перечень ситуаций (ошибочных), определяемых CASE.Аналитик автоматически при верификации, приведен в Руководстве пользователя.
5.3.6.2. Верификация согласованности модели
В согласованной модели для информационных каналов и накопителей данных должен выполняться закон сохранения информации:
То, что входит, должно выходить.
Другими словами, для каждого информационного канала и накопителя данных
Все поступающие данные, события должны быть считаны
или
все считываемые данные (события) должны быть записаны.
Верификация согласованности осуществляется автоматически CASE.Аналитиком. CASE.Аналитик выдает для каждого накопителя данных и информационного канала протокол верификации, содержащий списки входных и выходных данных, а также списки данных, никем не считываемых, и данных, никем не записываемых.
5.3.6.3. Анализ объемов накопителей данных
Если содержание потоков данных определено, то CASE.Аналитик автоматически вычисляет минимальный и максимальный объемы данных, которые должны храниться в накопителях данных. Объем измеряется в элементах: количество элементарных данных. Объем в элементах даст Вам качественную оценку. Так, например, если в результате анализа выяснится, что в накопителе "Архив событий" должно храниться 100 млн. структур данных "Событие", содержащих 3 элемента данных, то, вероятно, Вам понадобится накопитель объемом около 1 Гбт, либо Вы должны пересмотреть Ваши проектные решения и внести изменения.
Объемы для анализа Вы можете получить, распечатав при помощи CASE.Аналитика перечень накопителей вместе с их атрибутами.
5.3.6.4. Анализ информационных потоков
Если содержание информационных потоков определено и определен характерный период передачи информации для потока, то CASE.Аналитик автоматически вычисляет минимальную и максимальную интенсивность потока. Интенсивность измеряется в элементах/с и дает качественное представление об интенсивностях. Вы можете распечатать при помощи CASE.Аналитика перечень потоков, в котором также будут приведены интенсивности. Эта информация полезна для анализа однородности моделируемой системы, а также для дальнейшего физического проектирования.
5.3.6.5. Анализ пропускной способности информационных каналов
Если содержание информационных потоков, входящих в информационные каналы, определено и определены их характерные периоды передачи информации, то CASE.Аналитик автоматически вычисляет минимальную и максимальную нагрузку на информационный канал. Нагрузка измеряется в элементах/с.
Вы можете распечатать перечень информационный канал вместе с их атрибутами и сравнить максимальную нагрузку с физической пропускной способностью канала.
5.3.7. Шаг 3.7. Выяснение альтернативных вариантов
После того, как Вы завершили верификацию модели, и убедились в ее полноте и непротиворечивости, следует выполнить еще один шаг перед тем, как представить проект заинтересованным лицам для рассмотрения и согласования - это выяснение альтернативных вариантов.
Лучшей моделью отношений между заинтересованными лицами является модель, существующая между голодным посетителем ресторана, желающим заказать все, и метрдотелем. После выяснения, какие блюда предпочитает посетитель, метрдотель предлагает несколько блюд разной стоимости и с разным временем приготовления, из которых посетитель имеет возможность выбрать. По аналогии, аналитик (проконсультировавшись с проектировщиком на физическом уровне) должен создать несколько альтернативных новых систем, имеющих разный набор преимуществ и предполагающих различные капиталовложения, и предложить пользователю выбрать из этих альтернативных вариантов помещения капитала. (Слишком часто готовится гастрономически сложное блюдо для пользователя, который был просто голоден и торопится по делам, или предлагается бутерброд с горячей сосиской тому, кто ожидает бифштекса.)
Альтернативные варианты будущей системы получают на основе разработанной модели: на контекстных диаграммах и диаграммах, детализирующих подсистемы, необходимо отметить процессы и подсистемы, которые можно было бы вывести за пределы системы отметить внешние сущности, которые, возможно, следует включить в состав системы.
По каждому из альтернативных вариантов аналитик должен уметь представить:
| оценки преимуществ и недостатков; |
| относительные оценки затрат, необходимых для реализации проекта; |
| формулировки факторов риска.< !--msthemelist--> |
5.3.8. Шаг 3.8. Презентация проекта
Этот шаг выполняется так же, как и презентация проекта на уровне контекста. Помимо других задач, решаемых на презентации, на этом шаге пользователи выбирают один из альтернативных вариантов для дальнейшей проработки.
5.3.9. Шаг 3.9. Рассмотрение защиты данных
После внесения изменений, выяснившихся на презентации, следует уточнить модель с точки зрения защиты данных в будущей системе.
Аналитику следует просмотреть модель с точки зрения доступа пользователей к данным: для каждого пользователя следует определить перечень данных, которые ему разрешено (или запрещено) просматривать, модифицировать и т.п. Такое рассмотрение может привести к вводу в модель дополнительных процессов или изменения логики процессов.
5.3.10. Шаг 3.10. Определение исключительных условий
На диаграммах низшего уровня следует рассмотреть исключительные условия: что будет с заказом, полученным от заказчика, который превысил лимит своего кредита, или что будет со счетом от издателя на отправку, который мы никогда не получали.
Аналитику следует идентифицировать логические исключительные условия, связанные с действиями внешних сущностей и указать, каким образом система должна реагировать на них.
Аналитик не должен заниматься исключительными или ошибочными условиями, возникающими внутри системы (например, переполнение буферов и т.п.).
Рассмотрение исключительных условий потребует внесения соответствующих дополнений модели.
5.3.11. Шаг 3.11. Выпуск документации
На этом шаге аналитик решает, какого типа документы следует выпустить для различных заинтересованных лиц.
5.3.12. Шаг 3.12. Согласование проекта
Документация проекта согласовывается с заинтересованными лицами.
Глава 6. Документирование проекта
Результаты анализа, полученные при помощи CASE.Аналитика, необходимо документировать. Состав и содержание документов проекта системы обработки данных регламентируются комплексами стандартов и руководящих документов. CASE.Аналитик поддерживает следующие комплексы стандартов и руководящих документов:
| Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. - М., Госстандарт СССР, 1991г., (условно - 34 серия); |
| Единая система программной документации. - М.: Госстандарт СССР, 1988, (условно - 19 серия); |
Кроме того, оформление диаграмм при печати может быть выполнено в соответствии с требованиями ЕСКД - автоматически генерируется рамка и надписи.
6.1. Принципы подготовки документов при помощи CASE.Аналитика
Основой для документирования проекта служит заполненная в результате анализа база данных проекта. CASE.Аналитик использует эту информацию для генерации макетов документов в соответствии с требованиями стандартов.
Макет документа - это файл, пригодный для дальнейшей обработки при помощи текстовых редакторов и процессоров, и который, в конечном итоге, может быть распечатан.
Содержание макета документа генерируется в соответствии с требованиями стандартов, и в него в максимально возможной степени помещаются статьи базы данных проекта.
Файл, который генерирует CASE.Аналитик, является макетом, а не законченным документом по следующим причинам:
| поскольку мы здесь рассматривали лишь фазу анализа требований, то информационно-логическая модель не содержит всю необходимую информацию для документирования системы в целом следовательно, отдельные разделы не могут быть заполнены по результатам анализа, и в макете они остаются пустыми; |
| требования стандартов содержат трудно формализуемые положения, которые вряд ли целесообразно включать в информационно-логическую модель - этим требованиям проще удовлетворить при редактировании макета; |
| CASE.Аналитик поддерживает минимальные требования по форматированию текста для получения качественного (с точки зрения полиграфии) документа макет следует отредактировать при помощи специальных мощных систем - издательских, текстовых процессоров, систем проверки орфографии и т.п. |
Итак, документирование результатов анализа осуществляется следующим образом:
6.2. Состав документов
CASE.Аналитик поддерживает генерацию макетов следующих документов:
Общесистемные документы
| Техническое задание на создание автоматизированной системы (ГОСТ 374.002-89). |
| Пояснительная записка (РД 50-34.598-90). |
| Схема функциональной структуры (РД 50-34.598-90).< !--mstheme--> |
| Общее описание системы (РД 50-34.598-90). |
| Описание автоматизируемых функций (РД 50-34.598-90 ). |
| Описание постановки задачи. |
Информационное обеспечение
| Описание информационного обеспечения системы (РД 50-34.598-90). |
| Описание организации информационной базы (РД 50-34.598-90). |
| Перечень входных сигналов и данных (РД 50-34.598-9 0). |
| Перечень выходных сигналов (документов) (РД 50-34.598-90). |
Программное обеспечение
| Описание программного обеспечения (РД 50-34.598-90 ). |
| Техническое задание (ГОСТ 19.201-78). |
| Описание программы (ГОСТ 19.402-78). |
| Пояснительная записка (ГОСТ 19.404-79). |
Конкретный состав документов для системы аналитик должен определить и согласовать с заинтересованными сторонами - заказчиками, пользователями и т.д. Ниже приводится содержание макетов документов, генерируемых CASE.Аналитиком.
Для описания содержания документов использованы следующие обозначения:
<текст> - обозначает, что эта часть макета генерируется из базы данных проекта текст поясняет, какие именно данные;
<не заполняется> - означает, что данный раздел в макете не заполняется.
БД - база данных проекта
КД - контекстная диаграмма
ДПД - диаграмма потоков данных
Описывается только содержательная часть макета. Общая структура макета такова:
| Титульный лист |
| Аннотация |
| Содержательная часть |
| Последний лист |
6.3. Техническое задание на создание автоматизированной системы (ГОСТ 34.602-89)
1. Общие сведения
Полное наименование системы: <...из БД...>
Условное обозначение системы: <...из БД...>
Шифр темы (договора): <...из БД...>
Предприятия-разработчики: <...из БД...>
Предприятие-заказчик: <...из БД...>
Перечень документов, на основании которых создается система <...из БД...>
Плановые сроки начала и окончания работы по созданию системы <...из БД...>
Источники и порядок финансирования работ <...из БД...>
Порядок сдачи-приемки <не заполняется>
2. Назначение и цели создания системы.
2.1.Назначение системы
<...из БД...>
Вид автоматизируемой деятельности
<...из БД...>
Объекты автоматизации:
<...из БД...>
2.2. Цели создания системы
<...из БД...>
3. Характеристики объекта автоматизации
Ссылки на документы
<Ссылки>
4. Требования к системе.
4.1. Требования к системе в целом
4.1.1. Требования к структуре и функционированию системы
4.1.1.1. Перечень подсистем
<Иерархия КД>
<Перечень подсистем +назначение>
4.1.1.2. Связи между подсистемами
<Перечень потоков с источниками и приемниками + характеристики потоков>
4.1.1.3. Взаимодействие со смежными системами
<Перечень внешних сущностей, потоки к подсистемам + характеристики потоков>
4.1.2. Требования к численности и квалификации персонала системы и режиму его работы <не заполняется>
4.1.3. Показатели назначения <не заполняется>
4.1.4. Требования к безопасности <не заполняется>
4.1.5. Требования к эргономике и технической эстетике <не заполняется>
4.1.6. Требования к транспортабельности для подвижных АС <не заполняется>
4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы <не заполняется>
4.1.8. Требования к защите информации от несанкционированного доступа <не заполняется>
4.1.9. Требования к защите от влияния внешних воздействий <не заполняется>
4.1.10. Требования к патентной чистоте <не заполняется>
4.1.11. Требования по стандартизации и унификации <не заполняется>
4.1.12. Дополнительные требования <не заполняется>
4.2. Требования к функциям <Иерархия диаграмм по каждой подсистеме, миниспецификация>
4.3. Требования к математическому обеспечению
<не заполняется>
4.4. Требования к информационному обеспечению
<Перечень накопителей>
<Состав накопителей>
<Перечень источников, приемников для накопителей>
4.5. Требования к лингвистическому обеспечению
<не заполняется>
4.6. Требования к программному обеспечению
<не заполняется>
4.7. Требования к техническому обеспечению
<не заполняется>
4.8. Требования к метрологическому обеспечению <не заполняется>
4.9. Требования к организационному обеспечению <не заполняется>
5. Состав и содержание работ по созданию системы
<этапы и сроки>
6. Порядок контроля и приемки системы <не заполняется>
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие <не заполняется>
8. Требования к документированию <не заполняется>
9. Источники разработки
<Ссылки>
6.4. Пояснительная записка (РД 50-34.598-90)
1. Общие положения
Наименование системы: <...из БД...>
Документы, на основании которых проводится разработка: <...из БД...>
Перечень организаций: <...из БД...>
Сроки выполнения стадий разработки: <...из БД...>
Перечень НИР <...из БД...>
2. Описание процесса деятельности <не заполняется>
3. Основные технические решения
3.1. Структура системы <иерархия БД + назначение подсистем>
<иерархия>
3.2. Взаимодействие со смежными системами
<Перечень внешних сущностей, потоки к подсистемам, характеристики потоков>
<перечень информационных каналов, характеристики>
3.3. Состав информации <перечень накопителей + объемы>
4. Мероприятия по подготовке объекта автоматизации <не заполняется>
6.5. Схема функциональной структуры (РД 50-34.598-90)
1. Функциональная структура <иерархия БД>
2. Информационные связи с внешней средой <перечень внешних сущностей, потоки к подсистемам, характеристики>
3. Информационные связи между подсистемами <перечень информационных каналов, характеристики> <перечень внутренних потоков, характеристики>
4. Детализированные схемы подсистемы <иерархия ДПД>
6.6. Описание автоматизируемых функций (РД 50-34.598-90)
1. Исходные данные
1.1. Перечень исходных материалов и документов НИР: <перечень>
1.2. Перечень внешних систем <перечень внешних сущностей, комментарии>
1.3. Описание информационной модели системы <иерархия КД> <иерархия ДПД>
2. Цели АС и автоматизированные функции <перечень целей>
3. Характеристика функциональной структуры <перечень процессов для подсистем + комментарий> <миниспецификация для процессов>
4. Типовые решения <не заполняется>
6.7. Описание постановки задачи (РД 50.34.698-90)
1. Характеристики комплекса задач
Перечень объектов: <...из БД...>
2. Выходная информация
<перечень внешних сущностей + потоки + структуры данных + перечень данных и сигналов>
3. Входная информация <перечень потоков, структур данных + перечень данных и сигналов>
6.8. Общее описание системы (РД 50-34.698-80)
1. Назначение системы
Вид автоматизированной деятельности: <...из БД...>
Объект автоматизации: <...из БД...>
Перечень функций, реализуемых системой
<перечни процессов>
2. Описание системы
2.1. Структура системы <иерархия КД + назначение подсистем>
3. Описание взаимосвязей системы с другими системами
3.1. Перечень внешних систем <перечень внешних сущностей + комментарии>
3.2. Связи между системами <перечень потоков с источниками и приемниками>
4. Описание подсистем
<иерархия ДПД для подсистем назначения процессов + миниспецификация>
6.9. Описание информационного обеспечения системы (РД 50-34.698- 80)
1. Состав информационного обеспечения <перечень накопителей + назначение>
2. Организация информационного обеспечения
2.1. Принципы организации информационного обеспечения системы <не заполняется>
2.2. Обоснование выбора носителей данных и принципы распределения информации по типам носителей <не заполняется>
2.3. Методы контроля <не заполняется>
2.4. Информационная совместимость с внешними системами <не заполняется>
3. Организация сбора и передачи информации
3.1. Источники информации
<перечень внешних источников + период + объем>
3.2. Общие требования к организации сбора и передачи информации <не заполняется>
4. Построение системы классификации и кодирования
4.1. Описание классификации <не заполняется>
4.2. Методы кодирования <не заполняется>
5. Организация внутримашинной информационной базы
5.1. Описание принципов построения внутримашинной информационной базы
<перечень накопителей + объем>
5.2. Структура внутримашинной информационной базы
<для каждого накопителя = перечень связанных процессов + состав>
6. Организация внемашинной информационной базы <не заполняется>
Приложение 1: Перечень наименование структурных единиц информации
<перечень структур и данных + код + комментарий>
6.10. Описание организации информационной базы (РД 50-34.698-80)/ Часть 1: Описание внутримашинной информационной базы
1. Логическая структура
1.1. Перечень структур данных <перечень структур>
1.2. Состав структур данных <описание состава>
1.3. Перечень элементов данных <перечень с атрибутами>
2. Физическая структура <перечень накопителей + состав накопителей>
3. Организация ведения информационная база
<не заполняется>
6.11. Перечень входных сигналов и данных (РД 50-34.698-80)
1. Перечень входных сигналов
<...из БД...>
2. Перечень входных данных
<...из БД...>
6.12. Перечень выходных сигналов (документов) (РД 50-34.698-80)
1. Перечень выходных сигналов
<...из БД...>
2. Перечень выходных документов
<...из БД...>
6.13. Описание программного обеспечения (РД 50-34.698-80)
1. Введение
<не заполняется>
2. Структура программного обеспечения
<перечень подсистем, процессов>
<иерархия диаграмм>
3. Функции частей программного обеспечения
<процесс + назначение + миниспецификации>
4. Методы и средства разработки программного обеспечения <не заполняется>
5. Операционная система <не заполняется>
6. Средства, расширяющие возможности операционной системы
6.14. Техническое задание (ГОСТ 19.201-78)
1. Введение
Полное наименование: <...из БД...>
Условное обозначение: <...из БД...>
Объект, для которого создается программа: <...из БД...>
2. Основание для разработки
<перечень документов + организации, утверждающие документ>
<Наименование темы>
<Условное обозначение темы>
3. Назначение разработки
<назначение>
4. Требования к программе
4.1 Требование к функциональным характеристикам
<иерархия диаграммы + миниспецификации>
<перечень входных сигналов + структуры>
<перечень выходных сигналов + структуры>
4.2. Требования к надежности <не заполняется>
4.3. Условия эксплуатации <не заполняется>
4.4. Требования к составу и параметрам технических средств <не заполняется>
4.5. Требования к информационной и программной совместимости <не заполняется>
4.6. Требования к маркировке и упаковке <не заполняется>
4.7. Требования к транспортировке и хранению <не заполняется>
4.8. Специальные требования <не заполняется>
5. Требования к программной документации <не заполняется>
6. Технико-экономические показатели <не заполняется>
7. Порядок контроля и приемки <не заполняется>
6.15. Описание программы (ГОСТ 19.402-78)
1. Общие сведения
Наименование: <...из БД...>
Условное обозначение: <...из БД...>
2. Функциональное назначение
<назначение>
3. Описание логической структуры
<иерархия диаграмм + миниспецификации>
4. Используемые технические средства <не заполняется>
5. Вызов и загрузка <не заполняется>
6. Входные данные <перечень входных потоков + состав>
6. Выходные данные <перечень выходных потоков + состав>
6.16. Пояснительная записка (ГОСТ 19.404-79)
1. Введение
Наименование: <...из БД...>
Условное обозначение: <...из БД...>
Перечень документов с указанием организаций, их утвердивших <...из БД...>
2. Назначение и область применения
<назначение>
<объект автоматизации + комментарий>
3. Технические характеристики
3.1. Постановка задачи <не заполняется>
3.2. Описание алгоритма <иерархия диаграмм + миниспецификация>
3.3. Методы организации входных и выходных данных <не заполняется>
4. Входные данные
<перечень>
5. Выходные данные
<перечень>
6.Ожидаемые технико-экономические показатели <не заполняется>
7. Источники, использованные при разработке <перечень НИР> <перечень ссылок>
Глава 7. Презентация проекта
В настоящей главе мы дадим некоторые рекомендации по организации эффективных презентаций. Для проведения презентации аналитик должен подготовить следующее:
| список участников презентации; |
| помещение для презентации; |
| иллюстрированные материалы большого формата; |
| резюме для участников презентации; |
| сценарий презентации. |
Подготовка и проведение презентации должны помочь аналитику добиться одобрения проекта (или одного из его вариантов) и убедить участников в серьезности и значимости работы, проделанной аналитиками.
7.1. Подготовка списка участников проекта
Просмотрите список лиц, причастных к проекту, и определите тех, кого следует пригласить на презентацию. На презентацию должны быть приглашены все те, кто принимает решения по системе или может повлиять на это решение. Кроме того, может оказаться полезным приглашение на презентацию лиц, не вошедших в базу данных проекта.
Следует охарактеризовать каждого из участников презентации: кто из них является противником или сторонником проекта, кто финансирует проект и т.п.
Исходя из возможностей подготовки иллюстративной информации большого формата, предоставляемых CASE.Аналитиком, и особенностей человеческого восприятия, назначить число участников презентации не более 15-20 человек.
Согласуйте список с руководством необходимого уровня.
Далее необходимо определить дату и время презентации и разослать участникам материалы презентации.
Попытайтесь согласовать удобную для всех участников дату и время презентации. Лучше всего, если Вы предложите несколько вариантов руководителю соответствующего уровня, который примет решение и доведет это решение до всех участников.
Следует принять во внимание то, что худшими днями для проведения презентации является понедельник и пятница, а лучшими часами - время с 10 до 12 часов и с 14 до 16 часов.
После того, как согласованы список участников, дата и время, следует разослать участникам приглашения не позднее чем за неделю.
К приглашению должно быть приложено:
| список участников; |
| регламент (сценарий) презентации; |
| резюме; |
| проект решения. |
7.2. Выбор помещения
Выбор помещения (если это возможно) следует сделать исходя из особенностей восприятия человека. Помещение должно быть небольшим, так, чтобы расстояние от участников до плакатов было не более 4-5 метров.
Если помещение большое, то следует "пресечь" попытки участников разместиться по углам.
7.3. Подготовка плакатов
В качестве плакатов для презентации мы рекомендуем Вам подготовить для презентации при помощи CASE.Аналитика 2-3 наиболее представительных потоковых диаграмм в формате примерно 2х2 м.
7.4. Подготовка резюме
Лучше всего, если содержание резюме будет соответствовать Вашему выступлению и содержать максимум иллюстрированного материала. В резюме участники должны явно увидеть ответы на следующие вопросы:
| Каковы цели создания системы? |
| На что повлияет введение системы? |
| Какова структура будущей системы? |
| Что получат пользователи системы и кто они? |
| Каковы альтернативные варианты реализации системы, их преимущества и недостатки? |
| Каковы предполагаемые затраты? |
Кроме того, в резюме может содержаться другая информация, связанная с вопросами, решаемыми на презентации.
Для укрепления позиций аналитиков следует представить на презентации полную и подробную документацию проекта.
7.5. Подготовка сценария презентации
Подготовка сценария включает в себя планирование регламента и определение "ролей" участников проекта.
Не следует планировать для проведения презентации более одного часа. Можно предложить следующий регламент:
1-ые 20 мин: выступление аналитика
2-ые 20 мин: обсуждение
Последние 20 мин: принятие решения.
Для презентации следует определить роли участников:
| Руководитель презентации (ведущий) |
| Докладчик (аналитик) |
| Участники-сторонники проекта< !--msthemelist--> |
| Участники-противники проекта< !--msthemelist--> |
Лучше всего, если руководителем презентации станет руководитель достаточно высокого ранга, являющийся сторонником проекта.
Следует предвидеть вопросы противников проекта. Попытайтесь понять, кто из участников-сторонников проекта может разъяснить вопрос и апеллируйте к нему в этих случаях. Лучший вариант - это когда принципиальные вопросы выясняют между собой лица, причастные к проекту, а аналитики дают по каждому вопросу точную и однозначную информацию.