Вопрос №3 Принципы проектирования информационного обеспечения программного комплекса
| Вид материала | Документы |
- Е. В. Чепин московский инженерно-физический институт (государственный университет), 30.11kb.
- Рабочая программа учебной дисциплины (модуля) case-средства проектирования программного, 143.56kb.
- Технология программирования, 643.21kb.
- Базы данных, 3110.93kb.
- А. А. Дюмин московский инженерно-физический институт (государственный университет), 30.84kb.
- Учебно-методический комплекс дисциплины разработка и стандартизация программных средств, 362.73kb.
- Методика выбора программного обеспечения турфирмой Антон Россихин (само-софт), 34.31kb.
- С. Д. Романин московский инженерно-физический институт (государственный университет), 24.74kb.
- Примерная программа наименование дисциплины Проектирование и архитектура программных, 182.2kb.
- Рабочая программа учебной дисциплины "системы автоматизированного проектирования электроустановок, 119.83kb.
Вопрос №2 Методы проектирования программного обеспечения (программных продуктов)
Процессы проектирования всей системы и отдельных программ во многом подобны друг другу. Но в отличие от системы каждая программа имеет единственное функциональное назначение и не может быть разбита на части, используемые в различные моменты времени. Сходство программы с системой заключается в наличии внешних и внутренних потоков данных, областей хранения данных, а, также в возможности разделения ее на независимые модули, которые можно разрабатывать и настраивать отдельно.
В последние десять лет общее признание получил модульный принцип построения программ. Под модуляризацией понимается разделение программы на части по некоторым установленным правилам.
Методы проектирования программ, основанные на модульном принципе, делятся на три группы:
- методы нисходящего проектирования,
- методы расширения ядра
- методы восходящего проектирования.
На практике обычно применяются различные сочетания этих методов.
В любом методе проектирования программ должны предусматриваться возможности для управления программой при переходе обработки от одной группы записей к другой, для проверки правильности данных, а также для одновременной обработки данных, поступающих в разное время. Кроме того, каждый метод должен объединять средства управления физической организацией некоторых данных (например, распределением информации по страницам) с логической организацией обработки.
1. Метод нисходящего проектирования
Метод нисходящего проектирования подобен методу получения детального изображения из более общего вида с помощью телескопического увеличения. На начальном шаге формируется предложение, описывающее функцию всей программы. Затем определяются ее подфункции. Эта процедура является рекурсивной, т. е., следуя ей, каждая из подфункций может расчленяться до тех пор, пока ее составные части не будут окончательно уточнены. Метод нисходящего проектирования, иногда называемый функциональной декомпозицией, основан на двух стратегиях: пошаговом уточнении и анализе сообщений. Эти стратегии отличаются способами определения начальных спецификаций, методами, используемыми при разбиении задачи на части, и правилами записи.
Пошаговое уточнение
При пошаговом уточнении на каждом следующем этапе декомпозиции определяются программы очередного, более низкого уровня. Для этого используются процедурные языки программирования.
Разбиение на модули осуществляется эвристическим способом. На каждом этапе проектирования по возможности не уточняются операции с данными (эти вопросы откладываются на более поздние сроки). Но выбор управляющих конструкций нельзя откладывать, так как на последующих этапах труднее изменить ранее выбранные конструкции. Нельзя сказать, что этот метод полностью независим от языка. Так, например, решение об использовании первоначального чтения из файла зависит от определяемого языком программирования способа обработки условия конца файла. Кроме того, некоторые конструкции циклов в одних языках реализуются легче, чем в других.
Преимущество метода пошагового уточнения заключается в том, что основное внимание при его использовании обращается на проектирование корректной программы, а не только на детальное понимание задачи.
Анализ сообщений
Анализ сообщений, основывается на анализе потока данных, обрабатываемых программой. Этот вид анализа в большей степени относится к процессам передачи и преобразования отдельных записей запросов или других входных элементов, чем к операциям управления потоком данных.
Три части программы принято называть соответственно истоком, преобразователем и стоком. Преобразователь представляет собой основную часть программы, тогда как исток и сток выполняют функции управления входным и выходным потоками данных.
Стратегия анализа сообщений включает организацию как взаимодействия между модулями, так и функционирования отдельных модулей. Корректность структурного разбиения основывается на внутренней коммуникативной способности каждого отдельного модуля и различных их сочетаний.
Связность модуля определяется как мера независимости его частей. Чем выше связность модуля, тем лучше результат проектирования. Для обозначения связности используется также понятие силы связности модуля. Типы связности модулей приведены в таблице:
Сцепление модулей представляет собой меру относительной независимости модулей, которая определяет их читабельность и сохранность. Независимые модули могут быть модифицированы без переделки каких-либо других модулей. Слабое сцепление более желательно, так как это означает высокий уровень их независимости. Модули являются полностью независимыми, если каждый из них не содержит о другом никакой информации. Чем больше информации о других модулях используется в них, тем менее они независимы и тем теснее сцеплены.
Говорят, что модуль предсказуем, если его работа обусловлена только одними параметрами. При этом среда вычислительной машины на функционирование данного модуля не влияет. Для того чтобы модуль был предсказуем, с другими модулями он должен быть сцеплен или по данным, или по образцу, или, наконец, по управлению. Он не может иметь доступа к каким-либо внешним данным или общим областям памяти.
2. Метод расширения ядра
Метод расширения ядра отличается от способа нисходящего проектирования: в нем больше внимания вначале уделяется выявлению множества вспомогательных функций, а не определению функции всей программы в целом. Эти функции можно получить, применяя методы проектирования структур данных, которые используются при иерархическом модульном проектировании, или определяя области хранения данных с последующим анализом связанных с ними функциональных единиц.
Спецификация модуля
Стратегия выбора спецификации модуля обеспечивает неявное определение информационных структур и условных переходов на процедурном уровне. Она. позволяет формировать отдельные блоки для построения семейств программ системы. На начальной стадии выделяется круг проблем, определяющих проектные решения. При решении каждой из этих проблем формируется отдельный модуль, что впоследствии облегчает модификацию уже созданной программы. Область определения указанных проблем зависит от организации данных и спецификации алгоритма.
Для программы обработки пакетов можно выделить следующий круг задач: получение, сортировку, проверку и обработку входных данных, а также проверку и сохранность выходных данных.
После того как выбраны алгоритмы, структуры данных и методы доступа, связи между модулями перестраиваются.
Метод иерархического проектирования модулей
Метод иерархического проектирования модулей, применяется для построения структуры программы на основе структур входных .и выходных данных. Он наиболее эффективен в случае высокой степени структуризации данных (например, в задачах печати экономических отчетов). При проектировании программ этим методом используются иерархические диаграммы. Допустим, что надо отпечатать отчет, в котором и входные, и выходные данные сгруппированы в соответствии с одним управляющим полем и, кроме того, входные данные расположены в порядке, необходимом для выдачи.
3. Метод восходящего проектирования
При использовании метода восходящего проектирования в первую очередь определяются вспомогательные функции, которые могут потребоваться для проектируемой программы. В этом смысле рассматриваемый метод аналогичен методу модульной декомпозиции Парнаса. Модульная декомпозиция, или анализ первичных определяющих областей, заключается в нахождении ключевых модулей промежуточных уровней, которые затем разрабатываются восходящим и нисходящим способами одновременно. Эти модули не являются вспомогательными в том смысле, что потребность в них возникает в нескольких точках программы. Необходимость в использовании этих модулей может возникать в других программах или системах.
Функции, определяемые как вспомогательные при восходящем проектировании, реализуются с помощью модулей самых нижних уровней, предназначенных для выполнения таких операций, как чтение, сортировка, формирование страниц и печать.