практические работы. Методические указания к лабораторной работе (1). Федерации федеральное агентство по образованию государственное

• Название: Федерации федеральное агентство по образованию государственное
• Анкор: практические работы
• Дата: 03.09.2022
• Размер: 0.67 Mb.
• Имя файла: Методические указания к лабораторной работе (1).docx
• Тип: Документы; #660107
• страница: 8 из 10

Характеристика программного модуля. Потоки данных и процессы

1. Характеристики программного модуля

Приступая к разработке каждой программы ПС, следует иметь в виду, что она,как правило,является большой системой,поэтому необходимо принять меры для ее упрощения. Для этого такую программу разрабатывают по частям, которые называются программными модулями. А сам такой метод разработки программ называют модульным программированием.

Программный модуль −это любой фрагмент описания процесса, оформ- ляемый как самостоятельный программный продукт, пригодный для использо- вания в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того,каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, деклари- рованные в документации по этому модулю. Таким образом, программный мо- дуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).

Модульное программирование призвано, в процессе разработки про- грамм, борьбы со сложностью, обеспечивает независимость компонент систе- мы, и использование иерархических структур.

Для избежание сложностей формулируются определенные требования, которым должен удовлетворять программный модуль,т.е.выявляются основ- ные характеристики «хорошего» программного модуля. Выделить хороший с этой точки зрения модуль является серьезной творческой задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт предложил следующие два общих таких критерия:

−хороший модуль снаружи проще, чем внутри;

−хороший модуль проще использовать, чем построить.

Майерс предлагает для оценки приемлемости программного модуля ис- пользовать более конструктивные его характеристики:

−размер модуля,

−прочность (связность) модуля,

−сцепление с другими модулями,

– рутинность модуля (независимость от предыстории обращений к нему).

2. Характеристики программного модуля по Майерсу

Размермодуля измеряется числом содержащихся в нем операторов или строк.

Сцеплениемодуля − это мера его зависимости по данным от других моду- лей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей. Для оценки степени сцепления Майерс предлагает упорядоченный набор из шести видов сцепления модулей.

Рутинностьмодуля − это его независимость от предыстории обращений к нему.Модуль будем называтьрутинным,если результат(эффект)обращения

к нему зависит только от значений его параметров (и не зависит от предысто- рии обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему. Суще- ствуют некоторые рекомендации по использованию зависящих от предыстории модулей:

• 
  всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;
  
• 
  зависящие от предыстории модули следует использовать только в слу- чае,когда это необходимо для обеспечения параметрического сцепле- ния;
  
• 
  в спецификации зависящего от предыстории модуля должна быть чет- ко сформулирована эта зависимость таким образом, чтобы было воз- можно прогнозировать поведение (эффект выполнения) данного моду- ля при разных последующих обращениях к нему.
  

В связи с последней рекомендацией может быть полезным определение внешнего представления (ориентированного на информирование человека) со- стояний зависящего от предыстории модуля. В этом случае эффект выполнения каждой функции (операции), реализуемой этим модулем, следует описывать в терминах этого внешнего представления,что существенно упростит прогнози- рование поведения данного модуля.

Прочность(связность) модуля − это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Майерс предлагает упорядоченный по степени прочности набор из семи классов модулей.

Функциональнопрочныймодуль − это модуль, выполняющий (реализую- щий)одну какую-либо определенную функцию.При реализации этой функции такой модуль может использовать и другие модули. Такой класс программных модулей рекомендуется для использования.

Информационнопрочныймодуль − это модуль, выполняющий (реализую- щий)несколько операций(функций)над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Для каждой из этих операций в таком модуле имеется свой вход со своей фор- мой обращения к нему. Такой класс следует рассматривать как класс программ- ных модулей с высшей степенью прочности. Информационно прочный модуль может реализовывать, например, абстрактный тип данных

3. Характеристики программного модуля по методологии SADT

МетодологияSADT предлагает несколько другую классификацию связ- ности. Различают по крайней мере семь типов связывания (таблица 1):
Таблица 1 – Типы связанности

Значимость Тип связности Для функций Для данных

0Случайная

Случайная

Случайная

1Логическая

Функции одного и того

же множества или типа (например, "редактиро- вать все входы")

Данные одного и того же множества или типа

2Временная Функции одного и того

же периода времени (например, "операции инициализации")

3Процедурная Функции, работающие

в одной и той же фазе или итерации (напри- мер, "первый проход компилятора")

Данные, используе- мые в каком-либо временном интервале
Данные, используе- мые во время одной и той же фазы или итерации

4Коммуникаци-

онная
5Последова-

тельная

6Функциональ-

ная

Функции, использую- щие одни и те же дан- ные

Функции, выполняю- щие последовательные преобразования одних и тех же данных Функции, объединяе- мые для выполнения одной функции

Данные, на которые воздействует одна и та же деятельность Данные, преобразуе- мые последователь- ными функциями
Данные, связанные с одной функцией

Ниже каждый тип связи кратко определен и проиллюстрирован с помо- щью типичного примера из SADT.

1. 
   Типслучайнойсвязности: наименее желательный.
   

Случайная связность возникает, когда конкретная связь между функция- ми мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом. Крайний вариант этого случая показан на рисунке 17.




Рисунок. 17 – Случайная связность

2. 
   Тип логическойсвязности. Логическое связывание происходит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отноше- ний между ними не обнаруживается.
   
3. 
   Типвременнойсвязности.Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
   
4. 
   Типпроцедурнойсвязности.Процедурно-связанные элементы появ- ляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связан- ной диаграммы приведен на рисунке 18.
   

Рисунок 18 – Процедурная связность

5. 
   Типкоммуникационнойсвязности.Диаграммы демонстрируют комму- никационные связи, когда блоки группируются вследствие того, что они ис- пользуют одни и те же входные данные и/или производят одни и те же выход- ные данные (рисунок 19).
   

Рисунок 19 – Коммуникационная связность

6. 
   Тип последовательной связности.На диаграммах,имеющих последо- вательные связи, выход одной функции служит входными данными для следу- ющей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку моделируются причин- но-следственные зависимости (рисунок 20).
   

Рисунок 20 – Последовательная связность

7. 
   Типфункциональнойсвязности. Диаграмма отражает полную функци- ональную связность, при наличии полной зависимости одной функции от дру- гой. Диаграмма, которая является чисто функциональной, не содержит чуже- родных элементов, относящихся к последовательному или более слабому типу связности.Одним из способов определения функционально-связанных диа- грамм является рассмотрение двух блоков, связанных через управляющие дуги, как показано на рисунке 21.
   

Рисунок 21 – Функциональная связность
В математических терминах необходимое условие для простейшего типа функциональной связности, показанной на рисунке 21, имеет следующий вид:

C=gB=gfA

Ниже в таблице представлены все типы связей, рассмотренные выше.

Важно отметить, что уровни 4-6 устанавливают типы связностей, которые раз- работчики считают важнейшими для получения диаграмм хорошего качества.

4. Потоки данных и процессы

В третьей части были описаны понятия декомпозиция задачи и методы проектирования. Рассмотрим некоторые аспекты проектирования более подроб- но. При декомпозиции задачи необходимо помнить и четко представлять каким образом будет происходить взаимодействие между частями задачи, т.е. необхо- димо определить потоки данных.

Потоки данных определяются согласно следующим рекомендациям:

• 
  каждому источнику данных соответствует один входной поток;
  
• 
  если имеется совокупный набор данных, полученный из нескольких источников, эти наборы распределяются по группам, обрабатываемых совместно потоков данных;
  
• 
  если не все потоки данных подвергаются обработки одновременно, процесс обработки делиться на этапы, в каждом из которых участвуют группы совместно обрабатываемых потоков, кроме того, должны су- ществовать внутренние потоки данных, связывающие последователь- ные этапы;
  
• 
  для каждого этапа в системе выделяются основной входной поток, для выдачи результатов обработки, и дополнительный, для выдачи опера- тивных отчетов, сообщений об ошибках и т.д.
  

После того как определены потоки данных, необходимо определить про- цессы, оперирующие этими потоками. Здесь так же существует ряд правил:

• 
  если потоки обрабатываются раздельно,то для каждого из них требу- ется отдельный процесс;
  
• 
  если некоторые системные функции должны выполняться в разное время или чаще чем другие, они реализуются в виде отдельных про- цессов;
  
• 
  если некоторые из промежуточных потоков данных необходимо сохра- нять с целью их последующего использования, должны быть преду- смотрены процессы, осуществляющие их запоминание.
  

Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть ин- формацией, передаваемой по кабелю между двумя устройствами, пересылаемы- ми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д.

Рассмотрим пример построения диаграмма потоков данных.

В качестве предметной области используется описание работы видеоби- блиотеки, которая получает запросы на фильмы от клиентов и ленты, возвраща- емые клиентами. Запросы рассматриваются администрацией видеобиблиотеки с использованием информации о клиентах, фильмах и лентах. При этом прове- ряется и обновляется список арендованных лент, а также проверяются записи о членстве в библиотеке. Администрация контролирует также возвраты лент, ис- пользуя информацию о фильмах,лентах и список арендованных лент,который обновляется. Обработка запросов на фильмы и возвратов лент включает следу- ющие действия: если клиент не является членом библиотеки, он не имеет права

на аренду. Если требуемый фильм имеется в наличии, администрация информи- рует клиента об арендной плате. Однако, если клиент просрочил срок возврата имеющихся у него лент,ему не разрешается брать новые фильмы.Когда лента возвращается, администрация рассчитывает арендную плату плюс пени за не- своевременный возврат.

Видео-библиотека получает новые ленты от своих поставщиков. Когда новые ленты поступают в библиотеку, необходимая информация о них фикси- руется. Информация о членстве в библиотеке содержится отдельно от записей об аренде лент.

Администрация библиотеки регулярно готовит отчеты за определенный период времени о членах библиотеки, поставщиках лент, выдаче определенных лент и лентах, приобретенных библиотекой.

При решении данной задачи необходимо провести:анализ,глобальное проектирование (проектирование архитектуры системы), детальное проектиро- вание и реализация (программирование).

На фазе анализа строится модель среды (Environmental Model). Построе- ние модели среды включает:

−анализ поведения системы (определение назначения ИС, построение на- чальной контекстной диаграммы потоков данных (DFD) и формирование мат- рицы списка событий (ELM), построение контекстных диаграмм);

−анализ данных (определение состава потоков данных и построение диа- грамм структур данных (DSD), конструирование глобальной модели данных в виде ER-диаграммы).

Назначение ИС определяет соглашение между проектировщиками и за- казчиками относительно назначения будущей ИС, общее описание ИС для са- мих проектировщиков и границы ИС. Назначение фиксируется как текстовый комментарий в "нулевом" процессе контекстной диаграммы.

Например, в данном случае назначение ИС формулируется следующим образом: ведение базы данных о членах библиотеки, фильмах, аренде и постав- щиках. При этом руководство библиотеки должно иметь возможность получать различные виды отчетов для выполнения своих задач.

Перед построением контекстной DFD необходимо проанализировать внешние события(внешние объекты),оказывающие влияние на функциониро- вание библиотеки. Эти объекты взаимодействуют с ИС путем информационно- го обмена с ней.

Из описания предметной области следует, что в процессе работы библио- теки участвуют следующие группы людей: клиенты, поставщики и руко- водство. Эти группы являются внешними объектами. Они не только взаимодей- ствуют с системой, но также определяют ее границы и изображаются на на- чальной контекстной DFD как терминаторы (внешние сущности).

Начальная контекстная диаграмма изображена на рисунке 22. В отличие от нотации Gane/Sarson внешние сущности обозначаются обычными прямо- угольниками, а процессы - окружностями.



Рисунок 22- Начальная контекстная диаграмма
Список событий строится в виде матрицы(ELM)и описывает различные действия внешних сущностей и реакцию ИС на них. Эти действия представ- ляют собой внешние события, воздействующие на библиотеку. Различают сле- дующие типы событий:

Аббревиатура	Тип
NCНормально	е управление
NDНормальны	е данные
NCDНормальн	ое управление/данные
TCВременное	управление
TDВременные	данные
TCDВременно	е управление/данные

Все действия помечаются как нормальные данные. Эти данные являются событиями, которые ИС воспринимает непосредственно, например, изменение адреса клиента, которое должно быть сразу зарегистрировано. Они появляются в DFD в качестве содержимого потоков данных.

Матрица списка событий имеет следующий вид:

1Клиент желает стать членом биб- лиотеки

2Клиент сообщает об изменении ад- реса

3Клиент запрашивает аренду филь- ма

NDРегистрация клиента в каче- стве члена библиотеки

NDРегистрация измененного адреса клиента

NDРассмотрение запроса

4Клиент возвращает фильмNDРегистрация воз

5Руководство предоставляет полно- мочия новому поставщику 6Поставщик сообщает об изменении

адреса

NDРегистрация поставщика
NDРегистрация измененного адреса поставщика

7По	ставщик направляет фильм в библиотеку	NDПо	лучение нового фильма
8Ру	ководство запрашивает новый отчет	NDФо	рмирование требуемого отчета для руководства

Для завершения анализа функционального аспекта поведения системы строится полная контекстная диаграмма, включающая диаграмму нулевого уровня. При этом процесс "библиотека" декомпозируется на 4 процесса, отра- жающие основные виды административной деятельности библиотеки.Суще- ствующие "абстрактные" потоки данных между терминаторами и процессами трансформируются в потоки, представляющие обмен данными на более кон- кретном уровне. Список событий показывает, какие потоки существуют на этом уровне: каждое событие из списка должно формировать некоторый поток (событие формирует входной поток, реакция - выходной поток). Один "аб- страктный" поток может быть разделен на более чем один "конкретный" поток.

Потоки на диаграмме верхнего уровня	Потоки на диаграмме нулевого уровня
Информация от клиента	Данные о клиенте, Запрос об аренде
Информация для клиента	Членская карточка, Ответ на запрос об аренде
Информация от руководства	Запрос отчета о новых членах, Новый по- ставщик, Запрос отчета о поставщиках, Запрос отчета об аренде, Запрос отчета о фильмах
Информация для руководства	Отчет о новых членах, Отчет о поставщи- ках, Отчет об аренде, Отчет о фильмах
Информация от поставщика	Данные о поставщике, Новые фильмы

На приведенной DFD (рисунок 23) накопитель данных "библиотека" яв- ляется глобальным или абстрактным представлением хранилища данных.


Рисунок 23 - Контекстная диаграмма
Анализ функционального аспекта поведения системы дает представление об обмене и преобразовании данных в системе. Взаимосвязь между "абстракт- ными" потоками данных и "конкретными" потоками данных на диаграмме ну- левого уровня выражается в диаграммах структур данных (рисунок 24).



Рисунок 24 - Диаграмма структур данных
На фазе анализа строится глобальная модель данных, представляемая в виде диаграммы "сущность-связь" (рисунок 25).



Рисунок 25 - Диаграмма "сущность-связь"

зи:

Между различными типами диаграмм существуют следующие взаимосвя-

• 
  ELM-DFD: события - входные потоки, реакции - выходные потоки
  

−DFD-DSD: потоки данных - структуры данных верхнего уровня

−DFD-ERD: накопители данных - ER-диаграммы

• 
  DSD-ERD: структуры данных нижнего уровня - атрибуты сущностей На фазе проектирования архитектуры строится предметная модель. Про-
  

цесс построения предметной модели включает в себя:

−детальное описание функционирования системы;

• 
  дальнейший анализ используемых данных и построение логической модели данных для последующего проектирования базы данных;
  
• 
  определение структуры пользовательского интерфейса, спецификации форм и порядка их появления;
  
• 
  уточнение диаграмм потоков данных и списка событий, выделение среди процессов нижнего уровня интерактивных и не интерактивных, определение для них мини-спецификаций.
  

Результатами проектирования архитектуры являются:

• 
  модель процессов (диаграммы архитектуры системы (SAD) и мини- спецификации на структурированном языке);
  
• 
  модель данных (ERD и подсхемы ERD);
  
• 
  модель пользовательского интерфейса(классификация процессов на интерактивные и не интерактивные функции, диаграмма последова- тельности форм (FSD – Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксиру- ется набор и структура вызовов экранных форм. Диаграммы FSD обра- зуют иерархию, на вершине которой находится главная форма прило- жения, реализующего подсистему. На втором уровне находятся фор- мы, реализующие процессы нижнего уровня функциональной структу- ры, зафиксированной на диаграммах SAD.
  

На фазе детального проектирования строится модульная модель. Под мо- дульной моделью понимается реальная модель проектируемой прикладной си- стемы. Процесс ее построения включает в себя:

−уточнение модели базы данных для последующей генерации SQL-

предложений;

−уточнение структуры пользовательского интерфейса;

−построение структурных схем, отражающих логику работы пользова- тельского интерфейса и модель бизнес-логики (Structure Charts Diagram – SCD) и привязка их к формам.

Результатами детального проектирования являются:

−модель процессов (структурные схемы интерактивных и не интерактив- ных функций);

−модель данных (определение в ERD всех необходимых параметров для приложений);

−модель пользовательского интерфейса (диаграмма последовательности форм (FSD), показывающая, какие формы появляются в приложении, и в каком

порядке, взаимосвязь между каждой формой и определенной структурной схе- мой, взаимосвязь между каждой формой и одной или более сущностями в ERD).

На фазе реализации строится реализационная модель. Процесс ее по- строения включает в себя:

−генерацию SQL-предложений, определяющих структуру целевой БД (та-

блицы, индексы, ограничения целостности);

−уточнение структурных схем (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.

На основе анализа потоков данных и взаимодействия процессов с храни- лищами данных осуществляется окончательное выделение подсистем (предва- рительное должно было быть сделано и зафиксировано на этапе формулировки требований в техническом задании).При выделении подсистем необходимо ру- ководствоваться принципом функциональной связанности и принципом мини- мизации информационной зависимости. Необходимо учитывать, что на основа- нии таких элементов подсистемы как процессы и данные на этапе разработки должно быть создано приложение, способное функционировать самостоятель- но. С другой стороны при группировке процессов и данных в подсистемы необ- ходимо учитывать требования к конфигурированию продукта, если они были сформулированы на этапе анализа.