Читайте также:
|
Лекция № 2. Структура программного продукта
Цели занятия: студент должен знать:
· цели структуризации программного продукта;
· типовую структуру программного продукта;
· возможности использования стандартных библиотек и встроенных функций.
План занятия:
1. Понятие модуля.
2. Сцепление модулей.
3. Связность модулей.
4. Библиотеки ресурсов.
5. Модульная структура программных продуктов.
Приступая к разработке программы, следует иметь в виду, что она, как правило, является большой системой, поэтому необходимо принять меры для ее упрощения. Для этого программу разрабатывают по частям, которые называются программными модулями. Такой метод создания программ называют модульным программированием.
Понятие модуля.
Модулем называют автономно компилируемую программную единицу. Термин «модуль» традиционно используется в двух смыслах. Первоначально, когда размер программ был сравнительно невелик, и все подпрограммы компилировались отдельно, под модулем понималась подпрограмма, т.е. последовательность связанных фрагментов программы, обращение к которой выполняется по имени. Со временем, когда размер программ значительно вырос, и появилась возможность создавать библиотеки ресурсов: констант, переменных, описаний типов, классов и подпрограмм, термин «модуль» стал использоваться и в смысле автономно компилируемый набор программных ресурсов.
Модуль -это самостоятельная часть программы, имеющая определенное назначение и обеспечивающая заданные функции обработки автономно от других программных модулей.
В большей степени программные продукты не являются монолитом и имеют конструкцию (архитектуру) построения - состав и взаимосвязь программных модулей.
Таким образом, программный продукт обладает внутренней организацией, или внутренней структурой, образованной взаимосвязанными программными модулями. Это справедливо для сложных и многофункциональных программных продуктов, которые часто называются программными системами.
Структуризация программ выполняется в первую очередь для удобства разработки, программирования, отладки и внесения изменений в программный продукт. Как правило, программные комплексы большой алгоритмической сложности разрабатываются коллективом разработчиков (2 - 15 и более человек). Управлять разработкой программ в условиях применения промышленных технологий изготовления программ можно лишь на научной основе.
Таким образом, структуризация программных продуктов преследует основные цели:
Структурное "разбиение" программ на отдельные составляющие служит основой и для выбора инструментальных средств их создания. При создании программных продуктов выделяются многократно используемые модули, проводится их типизация и унификация, за счет чего сокращаются сроки и трудозатраты на разработку программного продукта в целом.
Некоторые программные продукты используют модули из готовых библиотек стандартных подпрограмм, процедур, функций, объектов, методов обработки данных.
На рис. 1 приведена типовая структура программного продукта, состоящего из отдельных программных модулей и библиотек процедур, встроенных функций, объектов и т.п.
Рис. 1.Структура программного продукта
Среди множества модулей различают:
r головной модуль - управляет запуском программного продукта (существует в единственном числе);
r управляющий модуль - обеспечивает вызов других модулей на обработку;
r рабочие модули - выполняют функции обработки;
r сервисные модули и библиотеки, утилиты - осуществляют обслуживающие функции.
В работе программного продукта активизируются необходимые программные модули. Управляющие модули задают последовательность вызова на выполнение очередного модуля. Информационная связь модулей обеспечивается за счет использования общей базы данных либо межмодульной передачи данных через переменные обмена.
Каждый модуль может оформляться как самостоятельно хранимый файл; для функционирования программного продукта необходимо наличие программных модулей в полном составе.
Структурно-сложные программные продукты разрабатываются как пакеты программ, и чаще всего они имеют прикладной характер - пакеты прикладных программ, или ППП.
ППП (application program package) - это система программ, предназначенных для решения задач определенного класса.
Компоненты ППП объединены общими данными (базой данных), информационно и функционально связаны между собой и обладают свойством системности, т.е. объединению программ присуще новое качество, которое отсутствует для отдельного компонента ППП. Структура ППП, как правило, многомодульная.
ПС – программная система — это совокупность согласованно работающих программ под общим управлением, предназначенная для решения сложной задачи или ряда взаимосвязанных задач.
При разработке ПС человек имеет дело с системами.
Под системой будем понимать совокупность элементов (компонентов) системы и связей (отношений) между ними. Система характеризуется структурой и поведением.
Структуру системы наиболее часто представляют с помощью графа. Под графом G будем понимать пару G = (V, D), где V — множество вершин графа, графически изображаемых точками или окружностями; D — множество дуг графа, графически изображаемых стрелками, соединяющими вершины (рис.). При этом вершины, как правило, соответствуют элементам системы, а дуги — отношениям между элементами.
Рис. 2. Пример графа
При рассмотрении конкретной структуры системы следует понимать, что каждый ее элемент может также являться системой со своими элементами и отношениями.
Под простой понимают такую систему, в которой человек может уверенно перебирать все пути взаимодействия между ее элементами, а под сложной будем понимать такую систему, в которой он этого делать не в состоянии.
Систему назовем малой, если n < 7 (6! = 720 < 1000), систему назовем большой, если n > 7. При n=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования - научиться делать большие системы простыми.
Полученная оценка простых систем по числу элементов широко используется на практике.
Целью системного анализа в наиболее общем виде является описание и исследование систем. Применительно к разработке ПО системный анализ представляет собой анализ существующей структуры отношений в рамках конкретной предметной области, выявление роли и места будущей программной системы, ее основных функций и свойств. В этой связи системный анализ также можно назвать внешним проектированием.
Данные модуль может получать и/или возвращать через общие области памяти или параметры.
Первоначально к модулям (еще понимаемым как подпрограммы) предъявлялись следующие требования:
r отдельная компиляция;
r одна точка входа;
r одна точка выхода;
r соответствие принципу вертикального управления;
r возможность вызова других модулей;
r небольшой размер (до 50 – 60 операторов языка);
r независимость от истории вызовов;
r выполнение одной функции.
Требования одной точки входа, одной точки выхода, независимости от истории вызовов и соответствия принципу вертикального управления были вызваны тем, что в то время из-за серьезных ограничений на объем оперативной памяти программисты были вынуждены разрабатывать программы с максимально возможной повторяемостью кодов. В результате подпрограммы, имеющие несколько точек входа и выхода, были не только обычным явлением, но и считались высоким классом программирования. Следствием же было то, что программы было очень сложно не только модифицировать, но и понимать, а иногда и просто полностью отладить.
Со временем, когда основные требования структурного подхода стали поддерживаться языками программирования, и под модулем стали понимать отдельно компилируемую библиотеку ресурсов, требования независимости модулей стало основным.
Практика показала, что чем выше степень независимости модулей, тем:
r легче разобраться в отдельном модуле и всей программе и, соответственно тестировать, отлаживать и модифицировать ее;
r меньше вероятность появления новых ошибок при исправлении старых или внесении изменений в программу;
r проще организовать программного обеспечения группой программистов и легче его сопровождать.
Степень независимости модулей (как подпрограмм так и библиотек) оценивают двумя критериями: сцеплением и связностью.
Дата добавления: 2015-08-09; просмотров: 760 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| ВРЕМЕННЫЙ ВВОЗ ТРАНСПОРТНЫХ СРЕДСТВ МЕЖДУНАРОДНОЙ ПЕРЕВОЗКИ | | | Сцепление модулей. |