Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
границы модели и является обязательной диаграммой IDEF0- модели. Поскольку единственный блок представляет весь объект, то его имя – общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, 196 поскольку они представляют полный комплект внешних интерфейсов объекта. В пояснительном тексте к контекстной диаграмме должна быть указа- на цель(Purpose) построения диаграммы в виде краткого описания и зафикси- рована точка зрения (Viewpoint). Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие об- ласти в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения. С определением модели тесно связана позиция, с которой наблюдается система и создается ее модель. Поскольку качество описания си- стемы резко снижается, если оно ни на чем не сфокусировано, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции. Эта пози- ция называется «точкой зрения» данной модели. Точка зрения определяет основное направление развития модели, уровень необходимой детализации, что и в каком разрезе можно увидеть в пределах мо- дели. Четкое фиксирование точки зрения позволяет разгрузить модель, отка- завшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Изменение точки зрения приводит к рассмотрению других аспектов объ- екта. Аспекты, важные с одной точки зрения, могут не появиться в модели, раз- рабатываемой с другой точки зрения на тот же самый объект. У модели может быть только одна точка зрения. Правильный выбор точки зрения существенно сокращает временные за- траты на построение конечной модели. Точка зрения определяет субъект моделирования и что, соответственно, будет в дальнейшем рассматриваться как элементы/компоненты системы, а что – как внешняя среда/воздействие. 197 Имя функции, записываемое в блоке контекстной диаграммы, является общей функцией системы с выбранной точки зрения и конкретной целью по- строения модели. Построение IDEF0-модели начинается с контекстной диаграммы, т.е. представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Затем блок, кото- рый представляет систему в качестве единого модуля, детализируется на дру- гой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Каж- дая из этих подфункций может быть декомпозирована подобным образом для более детального представления. При этом каждая подфункция может содержать только те элементы, ко- торые входят в исходную функцию. Таким образом, в процессе декомпозиции функциональные блоки диа- граммы подвергаются детализации на другой диаграмме, которая называется дочерней (Child Diagram) по отношению к детализируемому блоку. Каждый из функциональных блоков, принадлежащих дочерней диаграм- ме, называется дочерним блоком (Child Box). В свою очередь, функциональный блок-предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к кото- рой он принадлежит – родительской диаграммой (Parent Diagram). Каждый блок дочерней диаграммы может быть далее детализирован ана- логичным образом, став родительским по отношению с соответствующей диа- грамме его детализации (рис. 4.10). 198 Рис. 4.10 Структура IDEF0-модели. Декомпозиция диаграмм Согласно стандарту IDEF0 на каждом уровне декомпозиции должен ис- пользоваться принцип ограничения сложности, поэтому в соответствии с этим принципом считается, что единственный блок и несколько стрелок на самом верхнем (контекстном) уровне используются для определения границы всей си- стемы. Соответственно, стрелки, касающиеся этого блока, описывают главные управления, входы, выходы и механизмы этой системы. В дальнейшем, тексто- вое описание, содержащее основные типы объектов и функции и комментарии экспертов, используется для предварительного создания диаграммы А0. Дерево диаграмм. Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, кото- 199 рая, в свою очередь, может быть далее детализирована с помощью необходимо- го числа диаграмм. Таким образом, формируется иерархия диаграмм. Для того, чтобы указать положение любой диаграммы или блока в иерар- хии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рис. 4.11 показано типичное дерево диаграмм. Рис. 4.11. Иерархия диаграмм Детализируя рассматриваемую систему на этапе сбора и анализа предва- рительной информации, необходимо обращать внимание на входные и выход- ные объекты самой системы и составляющих ее подсистем. Моделирование необходимо начинать с составления описания основных типов объектов и основных функций системы. При этом необходимо учесть нормальные и аномальные ситуации, имеющиеся в системе обратные связи, и возможные случаи потенциальных ошибок. Глоссарий. Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 – диаграмм, функциональных блоков, интер- фейсных дуг – существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных из- ложений и т.д., которые характеризуют объект, отображенный данным элемен- 200 том. Этот набор называется глоссарием и является описанием сущности дан- ного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Пример SADT-модели В примере модель объединяет и организует диаграммы в иерархические структуры, в которых диаграммы наверху модели менее детализированы, чем диаграммы нижних уровней. Другими словами, модель SADT можно предста- вить в виде древовидной структуры диаграмм, где верхняя диаграмма является наиболее общей, а самые нижние наиболее детализированы. На рис. 4.12 показано определение цели и точки зрения моделирования. На рис.4.13 – 4.14 представлены две диаграммы из модели эксперимен- тального механического цеха. Верхняя диаграмма (на вершине модели) описывает механический цех как функцию, в основе которой лежит преобразование входящих рабочих ком- плектов (заготовок, сырья, документации) в детали при определенном контроле качества. Нижняя диаграмма детализирует верхнюю, указывая на три главные функции механического цеха: управление выполнением заданий, выполнение задания и контроль качества выполнения. Таким образом, общая функция, указанная на верхней диаграмме, детали- зируется с помощью трех функций на нижней диаграмме. Это пример того, как SADT организует описание системы, создавая иерархию добавляющихся на каждом уровне деталей. 201 Рис. 4.12. Определение цели и точки зрения Рис. 4.13. Контекстная диаграмма модели экспериментального механического цеха (ЭМЦ) 202 На рис. 4.14 показано также взаимное влияние трех функций нижней диа- граммы, обозначенное дугами, которые символизируют объекты механического цеха. Рис. 4.14. Диаграмма первого уровня модели экспериментального механического цеха (ЭМЦ) Если внимательно посмотреть на диаграмму, то можно заметить, что не- которые дуги доходят до ее границы, а имена этих дуг совпадают с теми, что указаны на дугах верхней диаграммы. Это пример того, как SADT соединяет диаграммы в модели через объекты системы. Такая схема соединения требует согласованного наименования и учета объектов системы с тем, чтобы две диаграммы можно было рассматривать как связанные между собой. Например, функциональный блок на верхней диаграм- ме имеет семь дуг, и каждая из них может быть найдена среди дуг, идущих к границе или от границы диаграммы на следующем уровне. 203 Блоки SADT никогда не размещаются на диаграмме случайным образом. Они размещаются по степени важности, как ее понимает автор диаграммы. В SADT этот относительный порядок называется доминированием. Доминиро- вание понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие функции (такая, как опре- делить степень выполнения задания на рис. 4.15). Рис. 4.15. Диаграмма второго уровня модели экспериментального механического цеха (ЭМЦ) Наиболее доминирующий блок обычно размещается в верхнем левом уг- лу диаграммы, а наименее доминирующий – в правом нижнем углу. В резуль- тате получается «ступенчатая» схема, как на рис. 4.15 для блоков 1, 2, 3, где 204 расположение блоков на странице отражает авторское определение доминиро- вания. Таким образом, топология диаграммы показывает, какие функции оказы- вают большее влияние на остальные. Чтобы подчеркнуть это, SADT-аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наиболь- шее доминирование, 2 – на следующее после наибольшего и т.д. На рис. 4.15 показано, что блок определить степень выполнения задания влияет на все остальные шаги по обработке детали через следующий шаг задания и поэтому этот блок пронумерован единицей. Поскольку блок подготовить рабочее ме- сто должен быть перед блоком обработать на станке и собрать, этим блокам присвоены номера 3 и 4. Документирование полученных знаний Создание модели (блок 2 на рис. 4-1) – это второй важный этап в процес- се моделирования, на котором аналитик документирует полученные им знания о данной проблемной области, представляя их в виде одной или нескольких SADT- диаграмм. Процесс создания модели осуществляется с помощью специального ме- тода детализации ограниченного субъекта, т.е. автор SADT-модели вначале анализирует объекты, входящие в систему, а затем ис-ользует полученные зна- ния для анализа функций системы. На основе этого анализа создается диаграмма, в которой объединяются сходные объекты и функции. Этот конкретный путь проведения анализа систе- мы и документирования его результатов является уникальной особенностью методологии SADT. 205 Рис. 4.16. Процесс создания SADT-модели 4.3. Метод структурного системного анализа и проектирования SSADM Основные понятия SSADM SSADM (Structured Systems Analysis and Design Method) – системный подход к анализу и проектированию ИС. SSADM как комплект стандартов для системного анализа и разработки приложений был разработан в начале 1980-х для Центрального агентства по компьютерам и телекоммуникациям (Central Computer and Telecommunications Agency , сейчас это Office of Government Commerce) – государственного учре- ждения UK, заинтересованного в использовании технологии в управлении. Позже SSADMшироко использовался для государственных ИТ-проектов 206 в UK, затем нашел широкое применение во всем мире для проектирования ИС. SSADM использует комбинацию текста и диаграмм для проектирования системы на всем ее жизненном цикле, от идеи до реального физического проек- та приложения SSADM использует комбинацию из трех методологий моделирования. 1. Логическое моделирование данных (Logical Data Modeling, LDM) – процесс идентификации, моделирования и документирования требова- ний к разрабатываемой системе. Элементы логической модели дан- ных: • сущности (entities) – то, о чем фирме нужно записать информа- цию; • связи (relationships) – ассоциации между сущностями. 2. Моделирование потоков данных (Data Flow Modeling) – процесс идентификации, моделирования и документирования движения дан- ных в ИС. Моделирование потоков данных исследует: • процессы (processes) – деятельность по преобразованию данных из одной формы в другую; • накопители данных (data stores) – области (промежуточного) хранения данных (the holding areas for data); • внешние сущности (external entities) – сущности, которые посы- лают данные в систему или получают данные из системы; • потоки данных – маршруты, по которым данные могут двигать- ся. 3. Моделирование поведения сущностей (Entity Behavior Modeling) – процесс идентификации, моделирования и документирования собы- тий, которые влияют на каждую сущность и последовательности, в ко- торой эти события происходят. Каждая их этих трех моделей системы обеспечивает различные точки зрения на одну и ту же систему, и каждая из точек зрения необходима для фор- мирования полной модели проектируемой системы. 207 Все три методологии во взаимосвязи друг с другом (are cross-referenced against each other ) дают гарантию полноты и точности всего приложения. Проект разработки SSADM приложения делится на пять модулей, кото- рые в дальнейшем разбиваются на иерархию из стадий, этапов и задач. Модули проекта приведены ниже. 1. Анализ осуществимости проектного решения (Feasibility Study) – ана- лиз предметной области для определения сможет ли проектируемая си- стема удовлетворить бизнес-требованиям. 2. Анализ требований (Requirements Analysis). На этом этапе определяются подлежащие разработке системные требования и моделируется текущая среда предприятия в терминах процессов с включением структур данных. 3. Спецификация требований (Requirements Specification). На этом этапе определяются детальные функциональные и нефункциональные требова- ния и вводятся новые методики для определения необходимых процессов и структур данных. 4. Логическая системная спецификация (Logical System Specification). На этом этапе вырабатываются опции технической системы, логический проект обновлений, обработка запросов и системные диалоги. 5. Физический проект (Physical Design). На этапе физического проектиро- вания создается физический проект базы данных и комплект программ- ных спецификаций с использованием логической и технической систем- ных спецификаций. В отличие от RAD (см. гл. 1.5), который подразумевает параллельное вы- полнение этапов, SSADM строит каждый этап на основе работы, которая была предписана на предыдущем этапе без отклонений от модели. По причине жесткой структуры методологии, SSADM хороша с точки зрения контроля проектов и способности разрабатывать системы лучшего каче- ства. 208 Моделирование данных Уровни представления модели данных Существуетдва уровня представления модели данных – логический и фи- зический. Логическая модель – это абстрактное представление данных. В логиче- ской модели данные представляются и могут называться так, как выглядят и называются в реальном мире, например «Постоянный клиент», «Отдел» или «Фамилия сотрудника». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Специфика логической моде- ли: 1) логическая модель данных может быть построена на основе другой логи- ческой модели, например на основе модели процессов; 2) логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных. В физической модели содержится инфор- мация обо всех объектах БД. Поскольку стандартов на объекты БД не суще- ствует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД,фактически являясь отображением ее систем- ного каталога. Следовательно, одной и той же логической модели могут соот- ветствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах и т.д. Особенности документирова- ния физической модели заключаются в следующем: 1) многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специ- альных символов – пробела и т. п.); 209 2) в нелокализованных версиях СУБД объекты БД могут называться корот- кими словами, только латинскими символами и без использования специ- альных символов (т.е. нельзя назвать таблицу, используя предложение – ее можно назвать только одним словом); 3) кроме того, проектировщики БД нередко злоупотребляют «технически- ми» наименованиями, в результате таблица и колонки получают наиме- нования типа RTD_324 или CUST_A12 и т.д. Полученную в результате структуру могут понять только специалисты (а чаще всего – только авто- ры модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы – имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CCUST_A12 может соответствовать сущность «Постоянный клиент». Такое соответствие позволяет лучше документировать модель и дает возможность обсуждать структуру данных с экспертами предметной области. Организация структуры БД формируется исходя из следующих сооб- ражений: 1) удобство использования для ведения учёта и анализа данных – на уровне физической модели; 2) адекватность описываемому объекту/системе – на уровне концептуаль- ной и логической модели; Виды концептуальных и логических моделей БД: сетевая; иерархическая; реляционная (ER-модель); многомерная; объектно-ориентированная. |