Методы проектирования. Методы проектирования программного обеспечения
 Скачать 1.93 Mb.
|
|
МЕТОДЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Структурное проектирование программных средств Структурные методы являются строгой дисциплиной системного анализа и проектирования. Методы структурного анализа и проектирования стремятся преодолеть сложность больших систем путем расчленения их на части («черные ящики») и иерархической организации этих «черных ящиков». Выгода в использовании «черных ящиков» заключается в том, что их пользователю не требуется знать, как они работают, необходимо знать лишь их входы и выходы, а также назначение (т.е. функции, которые они выполняет). Таким образом, первым шагом упрощения сложной системы является ее разбиение на «черные ящики», при этом такое разбиение должно удовлетворять следующим критериям: – каждый «черный ящик» должен реализовывать единственную функцию системы; – функция каждого «черного ящика» должна быть легко понимаема независимо от сложности ее реализации; – связь между «черными ящиками» должна вводиться только при наличии связи между соответствующими функциями системы; – связи между «черными ящиками» должны быть простыми, насколько это возможно, для обеспечения независимости между ними. Второй важной идеей, лежащей в основе структурных методов, является идея иерархии. Для понимания сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур. Структурным анализом принято называть метод исследования системы, который начинается с ее общего обзора, затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно: – разбиение системы на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6–7); – ограниченный контекст, включающий лишь существенные на каждом уровне детали; – использование строгих формальных правил записи; – последовательное приближение к конечному результату. В структурном анализе основным методом разбиения на уровни абстракции является функциональная декомпозиция, заключающаяся в декомпозиции (разбиении) системы на функциональные подсистемы, которые в свою очередь делятся на подфункции, те – на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в кото- ром все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов. Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Базовыми принципами являются: – принцип «разделяй и властвуй» – принцип решения проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения; – принцип иерархического упорядочения – принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирова- ние любого из них может привести к нежелательным последствиям (вплоть до неудачного завершения проекта). Основными из этих принципов являются: – принцип абстрагирования – выделение существенных эле- ментов системы и отвлечение от несущественных; – принцип непротиворечивости – обоснованность и важность элементов системы; – принцип структурирования данных – данные должны быть структурированы и иерархически организованы. В структурном анализе и проектировании используются раз- личные модели, описывающие: 1) функциональную структуру системы; 2) последовательность выполняемых действий; 3) передачу информации между функциональными процессами; 4) отношения между данными. Наиболее распространенными моделями первых трех групп являются: – функциональная модель SADT (Structured Analysis and Design Technique); 47 – модель IDEF3; – DFD (Data Flow Diagrams) – диаграммы потоков данных. Модель «сущность – связь» (ERM – Entity-Relationship Model), описывающая отношения между данными, традиционно использу- ется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Метод функционального моделирования SADT Метод SADT представляет собой совокупность правил и про- цедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. произ- водимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следую- щих концепциях: – графическое представление блочного моделирования. Гра- фика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответ- ственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются; – строгость и точность. Правила SADT включают: – ограничение количества блоков на каждом уровне декомпо- зиции (правило 3–6 блоков – ограничение мощности краткосрочной памяти человека), – связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), синтаксические правила для графики (блоков и дуг), разделение входов и управле- ний (правило определения роли данных); – отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную мо- дель. Метод SADT может использоваться для моделирования самых разнообразных процессов и систем. В существующих системах ме- тод SADT может быть использован для анализа функций, выполня- емых системой, и указания механизмов, посредством которых они осуществляются. Результатом применения метода SADT является модель, кото- рая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подверга- ется обработке, показана с левой стороны блока, а результаты (вы- ход) – с правой стороны. Механизм (человек или автоматизирован- ная система), который осуществляет операцию, представляется ду- гой, входящей в блок снизу (рис. 3.1)  Построение SADT-модели заключается в выполнении следу- ющих действий: – сбор информации об объекте, определение его границ; – определение цели и точки зрения модели; – построение, обобщение и декомпозиция диаграмм; – критическая оценка, рецензирование и комментирование. Построение диаграмм начинается с представления всей системы в виде простейшего компонента – одного блока и дуг, изображающих интерфейсы с функциями вне системы (рис. 3.2). Поскольку един- ственный блок отражает систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг – они так- же соответствуют полному набору внешних интерфейсов системы в целом. 49 Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью несколь- ких блоков, соединенных интерфейсными дугами. Эти блоки опре- деляют основные подфункции исходной функции. Данная декомпо- зиция выявляет полный набор подфункций, каждая из которых по- казана как блок, границы которого определены интерфейсными ду- гами. Каждая из этих подфункций может быть декомпозирована по- добным образом в целях большей детализации. На SADT-диаграммах не указаны явно ни последовательность (рис. 3.3), ни время. Обратные связи (рис. 3.4), итерации, продол- жающиеся процессы и перекрывающиеся (по времени) функции (рис. 3.5) могут быть изображены с помощью дуг. Обратные связи мо- гут выступать в виде комментариев, замечаний, исправлений и т.д.    Рекомендуется прекращать моделирование, когда уровень де- тализации модели удовлетворяет ее цели, если: – блок содержит достаточное количество деталей; – необходимо изменить уровень абстракции, чтобы достичь большей детализации блока; – необходимо изменить точку зрения, чтобы детализировать блок; – блок похож на другой блок этой модели или на блок другой модели; – блок представляет тривиальную функцию. Одним из важных моментов при моделировании с помощью метода SADT является точная согласованность типов связей между функциями. Различают, по крайней мере, связи семи типов (в по- рядке возрастания их относительной значимости): – случайная; – логическая; – временная; – процедурная; – коммуникационная; – последовательная; – функциональная. Случайная связь показывает, что конкретная связь между функциями незначительна или полностью отсутствует. Это отно- сится к ситуации, когда имена данных на SADT-дугах в одной диа- грамме имеют слабую связь друг с другом Логическая связь – данные и функции собираются вместе бла- годаря тому, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обна- руживается. Временная связь представляет функции, связанные во време- ни, когда данные используются одновременно или функции вклю- чаются параллельно, а не последовательно. Процедурная связь – функции сгруппированы вместе благода- ря тому, что они выполняются в течение одной и той же части цикла или процесса. Коммуникационная связь – функции группируются благодаря тому, что они используют одни и те же входные данные и/или про- изводят одни и те же выходные данные Последовательная связь – выход одной функции служит вход- ными данными для следующей функции. Связь между элементами 52 на диаграмме является более тесной, чем в рассмотренных выше случаях, поскольку моделируются причинно-следственные зависи- мости. Функциональная связь – все элементы функции влияют на вы- полнение одной и только одной функции. Диаграмма, являющаяся чисто функциональной, не содержит чужеродных элементов, отно- сящихся к последовательному или более слабому типу связи. В математических терминах необходимое условие для про- стейшего типа функциональной связи имеет следующий вид: C = g(B) = g(f(A)). В табл. 3.1 представлены все типы связей, рассмотренные выше  Метод SSADM базируется на таких структурных диаграммах, как последовательность, выбор и итерация. Моделируемый объект задается последовательностью групп, операторами выбора из груп- пы и циклическим выполнением отдельных элементов (рис. 3.6)  Базовая диаграмма – иерархическая и включает в себя список компонентов описываемого объекта; идентифицированные группы выбранных и повторяемых компонентов, а также последовательно используемых компонентов. Данный метод представлен моделью ЖЦ со следующими эта- пами разработки программного проекта (рис. 3.7): – стратегическое проектирование и изучение возможности вы- полнения проекта; – детальное обследование предметной области, включающее в себя анализ и спецификацию требований; – логическое проектирование и спецификация системы; – физическое проектирование структур данных в соответствии с выбранной структурой БД (иерархической, сетевой и др.); – конструирование и тестирование системы  Детальное обследование предметной области проводится для того, чтобы изучить ее особенности, рассмотреть потребности и предложения заказчика, провести анализ требований из разных до- кументов, обозначить их и согласовать с заказчиком. Цель стратегического проектирования – определение области действия проекта, анализ информационных потоков, формирование общего представления об архитектуре системы, затратах на разра- ботку и подтверждение возможности дальнейшей реализации про- екта. Результат есть спецификация требований, которая применяет- ся при разработке логической структуры системы. Логическое проектирование – это определение функций, диа- лога, метода построения и обновления БД. В логической модели отображаются входные и выходных данные, прохождение запросов и установка связей между сущностями и событиями. Физическое проектирование – это определение типа СУБД и представления данных в ней с учетом спецификации логической мо- дели данных, ограничений на память и времени обработки, а также определение механизмов доступа, размера логической БД, связей между элементами системы. Результат – создание документа, вклю- чающего в себя: – спецификацию функций и способов их реализации, описание процедурных, непроцедурных компонентов и интерфейсов системы; – определение логических и физических групп данных с уче- том структуры БД, ограничений на оборудование и положений стандартов на разработку; – определение событий, которые обрабатываются как единое целое, и выдача сообщений о завершении обработки и др. Конструирование – это программирование элементов системы и их тестирование на наборах данных, которые подбираются на ранних этапах ЖЦ разработки системы. Проектирование системы является управляемым и контроли- руемым. Создается сетевой график, учитывающий работы по разра- ботке системы, затраты и сроки. Слежение и контроль выполнения плана проводит организационный отдел. Проект системы задается структурной моделью, в которой содержатся работы и взаимосвязи между ними и их исполнителями, а потоки проектных документов между этапами отображаются в сетевом графике. Результаты каж- дого из этапов ЖЦ контролируются и передаются на следующий этап в виде, удобном для дальнейшей реализации другими исполни- телями.55 3.2.2. Метод моделирования процессов IDEF3 Основой модели IDEF3 служит сценарий процесса, который выделяет последовательность действий и подпроцессов анализиру- емой системы. Как и в методе IDEFO (SADT), основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели – действие, или в терминах IDEF3 «единица работы». Существенные взаимоотношения между действиями изобра- жаются с помощью связей. Все связи в IDEF3 являются однона- правленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 3.2 приведены три возможных типа связей.  Связь типа «временное предшествование» показывает, что ис- ходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь типа «объектный поток» используется в том случае, ко- гда некоторый объект, являющийся результатом выполнения исход- ного действия, необходим для выполнения конечного действия. Обозначение такой связи отличается от связи временного предше-56 ствования двойной стрелкой. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична свя- зям предшествования и означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие может начать выполняться. Связь типа «нечеткое отношение» используется для выделения отношений между действиями, которые невозможно описать с ис- пользованием связей предшествования или объектных связей. Зна- чение каждой такой связи должно быть определено, поскольку свя- зи типа «нечеткое отношение» сами по себе не предполагают ника- ких ограничений. Одно из применений нечетких отношений – отображение взаимоотношений между параллельно выполняющи- мися действиями. Завершение одного действия может инициировать начало вы- полнения сразу нескольких других действий или, наоборот, опреде- ленное действие может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для изображения ветвления процесса: – разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других; – сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения дру- гого действия. В табл. 3.3 описаны три типа соединений.  Соединения «и» инициируют выполнение конечных действий. Все действия, присоединенные к сворачивающему соединению «и», должны завершиться, прежде чем начнется выполнение следующего действия (рис. 3.8).  Соединение «исключающее или» означает, что вне зависимо- сти от количества действий, связанных со сворачивающим или раз- ворачивающим соединением, инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением, сможет начаться. Если правила активации соединения известны, то они обя- зательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения (рис. 3.9).58 Соединение «или» предназначено для описания ситуаций, ко- торые не могут быть описаны двумя предыдущими типами соеди- нений. Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно системным аналитиком (рис. 3.10).  |