И. Соммервилл - Инженерия программного обеспечения (1133538), страница 39
Текст из файла (страница 39)
1. Модель офайилкк длннмх. Диаграммы потоков данных показывают последователь. ность обработки данных в системе. 2. Каняезяционмае модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других с)тцностей. 5. Ярлкжектурялл модель. Эти модели показывают основные подсистемы, из которых строится система. 4. Кяиссиу)икакиояная лодыь Диаграммы наследования классов показывают, какие объекты имеют общие характеристики. 5. Модель "стимул-ламет". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.
Эти типы моделей описаны далее в главе. Везде, где возможно, я использую обозиаченил унифицированного языка моделирования 1)М1., который является стандартом языка моделирования, особенно для объектно.ориентированного моделирования [55, 505, 5", 50']. В тех случаях, когда 1)М1. не предусматривает подходящих нотаций, для описания моделей я использую простые интуитивные обозначения. 7.1. Модели системного окружения На ранних этапах формирования требований необходимо определить границы гнете. мы. Этот этап предполагает работу с лицами, участвующими в формировании требований (см. главу 6), для того чтобы разграничить систему и ее рабочее окружение. В некоторых случаях границы между системой и ее окружением относительно ясны.
Например. когда новая система заменяет существующую, ее рабочее окружение обычно совпадает с окружением существующей системы. В других случалк необходим дополнительный анализ. Например, рабочсс окружение разрабатываемого набора САБЕ-средств может включать существующую базу данных, сервисы которой используются системой, но набор средств может также иметь внугреннюю базу данных. Если база данных уже существует, определение границ между ними может оказаться сложной технической и управленческой проблемой. Только после проведения дополнительного анализа можно будет принять решение о том, что является, а что нс является частью разрабатываемой системы. На определение системного окружения могут также влиять социэльныс и организационные ограничения, т.е.
граница системы может определяться не только техническими факто. рами. Например, система может быль очерчена так, что при ее разработке не будет необходимости консультироватьсл с менеджерами; при другом определении границ может возрасти ее стоимость или возникнет необходимость расширить отдел разработки и т.п. 152 хХасть 21.
Требования После определения границ между системой и ее окружением далее специфицируется само рабочее окружение и связи между ним и системой. Обычно на этом этапе строится простая структурная модель, подобная представленной на рис. 7.1 модели структуры окружения информационной системы, управляющей сегью банкоматов. Структурные модели высокого уровня обычно являютсл простыми блоксхемами, где каждая подсистема представлена именованным прямоугольником, а линии показывают, что существуют некоторые связи между подсистемами. Рис.
7 1. Рпбечееэкэужениесиетемыуираелекия банкомаээьки На рис. 7.1 показано, что каждый банкомат присоединен к базе данных счетов, к ло. кальной системе кэиснтских расчетов, к системе защиты и к системе обслуживания банкоматов. Система также соединена с базой данных клиентов, контролирующей сеть банкоматов, и с локальной бухгалтерской системой. Структурные модели описывают непосредственное рабочее окружение системы. Но они нс показывают связи между другими системами в окружакицей среде, которые не соединены непосредственно с разрабатываемой сисгемой, но могут на нее влиять.
Например, внешние системы могут производить данные для системы или использовать данные, произведенные системой. При этом они могут быть соединены между собой и системой через сеть или не соединены вообще. Они мо~7т физически соприкасаться или распола. гаться в разных зданиях. Все этн взаимоотношения могут влиять на требования к разрабатываемой системе и должны быть приняты во внимание. Таким образом, простые структурные модели обычно дополняются моделями других типов, например моделями процессов, которые показывают взаимодействия в системе, нлн моделями потоков данных (описаны в следующем разделе), которые показывают последовательность обработки и перемещения данных внутри системы и между другими системами в окружающей срсде.
На рис. 7.2 представлена модель процесса заказа оборудования организацией. Она включает определение необходимого оборудования, поиск и выбор поставщиков, заказ, поставку и проверку оборудования после поставки. Для определения системы компьютерной поддержки этого процесса необходимо решить, какие из этих действий будут выполняться системой, а какие окалсугся внешними по отношению к ней. На рис. 7.2 пунктир. пой линией ограничены действия, выполняемые виугри такой системы. 7. Модели систем 15$ иив Рис 7 2. Модель иро уеееп приобреэмиия оборудоопи ил 7.2.
Поведенческие модели Эти модели используются для описания общего поведения системы. Здесь рассматрн. ваегся два типа поведенческих моделей — модель потоков данных, которая представляет обработку данных в системе, и модель конечного автомата, которая показывает реакцию системы на события. Эти модели можно использовать отдельно или совместно, в зависи. мосги от типа разрабатываемой системы.
Большинство бизнес. систем прежде всего управляют данными. Они также управляют вводом данных в систему и сравнительно мало запинаются обработкой внешних событий. Для таких систем модель потоков данных может содержать все, что необходимо для описанил поведенил системы. В противоположность им системы реального времени управляют событиями с минимальной обработкой данных.
Модель конечного автомата (обсуждаемая в разделе 7.2.2) является наиболее эффективным способом описания их по. ведение. Другие классы систем управляют как данными, так и событиями, поэтому для их представления необходимы оба типа моделей. 7.2.1. Модели потоков данных Модели потока данных — это интуитивно понятный способ показа последовательности обработки данных внутри системы, Нотации, используемые в этих моделях, описывают обработку данных с помощью системных функций, а также хранение и перемещения дан. иых между системными функциями. Модели потоков данных стали широко использовать 154 'Часть 11.
Требованыя ся после публикации книги о структурном системном анализе [91]. На базе этого фунда. ментального исследования было разработано множество методов анализа систем. Модели потоков данных используются для показа последовательности шагов обработки данных. Эти шаги обработки или преобразования данных выполняются программными функцилми. В сущности, диаграммы потоков данных используются для документирования программных функций перед проектированием системы. Анализ модели обработки данных мсокет быть выполнен специалистами вручную или с помощью компьютера. Модель потоков данных, показанная на рис. 7З, представляет действия, выполняемые при оформлении заказа на оборудование.
Это описание части процесса размещения заказа на оборудования, представленного на рис. 7.2. Данная модель показывает процесс перемещения бланка заказа прн его обработке. Провереннмй и лоллисвннмй банк зваж е уведомление о заказе Двквлизи ровен ЭВЯЗ+ лузгой бланк заказа Рис. 7З, Дитрпмип леикжов дпкимл ярк ебрп божке бланки зпкпгп В диаграммах потоков данных используются следующие обозначения (см. рис. 7З): закругленные прямоугольники соответствуют этапам обработки данных; стрелки, снабженные примечаниями с названием данных, представляют потоки данных; прямоугольники соответствуют хранилищам или источникам данных.
Модели потоков даннык ценны тем, что они прослеживают н документируют перемещение данных по системе, помогая тем самым аналитикам понять этот процесс. Преимущество диаграмм потоков данных в том, что они, в отличие от других моделей, просты и интуитивно понлтны. Поэтому их можно объяснить потенциальным пользователям системы, которые затем могут участвовать в ее анализе. Модели потоков данных показывают функциональную структуру системы, где каждое преобразование данных соответствует одной системной функции. Иногда модели потоков данных используют для описания потоков данных в рабочем окружении системы. Такая модель показывает, как различные системы и подсистемы обмениваются информацией. Подсистемы окружения не обязаны быть простыми функциями.