Модуль – это отдельная функционально законченная программная единица, которая может применяться самостоятельно, либо быть частью программы. Программное обеспечение создается на основе модульной структуры, состоящей из отдельных модулей.
• один вход и один выход. На входе программный модуль получает определенный набор исходных данных, выполняет их обработку и возвращает один набор выходных данных;
• функциональная завершенность. Модуль выполняет набор определенных операций для реализации каждой отдельной функции, достаточных для завершения начатой обработки данных;
• логическая независимость. Результат работы данного фрагмента программы не зависит от работы других модулей;
• слабые информационные связи с другими программными модулями. Обмен информацией между отдельными модулями должен быть минимален;
• размер и сложность программного элемента в разумных рамках.
Модульная структура программы представляет собой древовидную структуру, в узлах которой размещаются программные модули, а направленные дуги показывают статическую подчиненность модулей. Если в тексте модуля имеется ссылка на другой модуль, то их на структурной схеме соединяет дуга, которая исходит из первого и входит во второй модуль. Каждый модуль может обращаться к подчиненным ему модулям. При этом модульная структура программной системы, кроме структурной схемы, должна включать в себя еще и совокупность спецификаций модулей, образующих эту систему
4. Пишем свой модуль для IoTManager. Структура и требования к модулю
Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функций, которым соответствуют подчиненные модули. При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее:
1) модуль вызывается на выполнение вышестоящим по иерархии модулем и, закончив работу, возвращает ему управление;
2) принятие основных решений в алгоритме выносится на максимально высокий по иерархии уровень;
3) если в разных местах алгоритма используется одна и та же функция, то она оформляется в отдельный модуль, который будет вызываться по мере необходимости.
Состав, назначение и характер использования программных модулей в значительной степени определяются инструментальными средствами.
Общие правила структурного построения ПО.На начальных этапах разработки ПО формируется его структура и общие правила взаимодействия компонентов, которые состоят в следующем:
- должна быть унифицирована структура ПО и правила оформления описания каждого программного модуля;
- каждый модуль характеризуется функциональной законченностью, автономностью и независимостью в оформлении от модулей, которые ею используют и которые он вызывает;
- применяются стандартные правила организации связей модуля по управлению и информации (данным) с другими модулями;
- ПО разрабатываются в виде совокупности небольших по количеству операторов (до 100) программных модулей, связанных иерархическим образом;
- должен отсутствовать эффект после действия очередного исполнения программы на последующие исполнения;
- регламентировано использование локальных переменных и регистров ЭВМ.
- Упрощается проектирование ПО, так как сложную и большую проблему легче понять, разбив на отдельные функциональные части.
- Обеспечивается возможность организации совместной работы больших коллективов разработчиков, так как каждый программист имеет дело с независимой от других частью ПО — модулем или группой модулей.
- Упрощается отладка программ, так как ограниченный доступ к модулю и однозначность его внешнего поведения исключает влияние ошибок в других модулях на его функционирование.
- Повышается надежность программ, так как относительно малый размер модулей и, как следствие, небольшая их сложность, позволяют провести более полную их проверку.
Источник: studfile.net
Вебинар «Комплексное комплектование СПО: требования и возможности»
Требования к программному модулю
Разработать личный кабинет клиента для интеграции в интернет-портал «Единый личный кабинет» компании.
Предусмотреть для пользователя возможность:
¾ просматривать информацию о замене или поверке прибора учета, находящегося на балансе пользователя;
¾ подать заявку на опломбировку обводной задвижки;
¾ подать заявку о неисправности прибора учета, находящегося на балансе АО «МФЮА»;
¾ удаленно получать и отправлять расчетно-платежные документы;
¾ отслеживать статус отправленных расчетно-платежных документов;
¾ иметь электронный архив ,с удобным инструментом поиска
Предусмотреть для модератора (администратора) портала возможность:
¾ добавлять пользователей абонента (пользователей сервиса), кактех,ктоещенеработаетссервисом,такипользователейдругихабонентов;
¾ продлить доступ абонента к сервису;
¾ получать отчеты о работе пользователей абонента.
Содержание отчета по учебной практике:
1 Анализ бизнес-архитектуры организации(файл Visio , схема бизнес-процессов организации)
2 Выработка требований к программному обеспечению (техническое задание)
3 Проектирование программного обеспечения с использованием специализированных программных пакетов (файл ArgoUML, UML-диаграммы)
СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
1. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО МОДУЛЯ 5
1.1 Анализ бизнес-процессов организации 5
1.2 Требования к программному модулю 6
1.3 Проектирование программного модуля 8
ЗАКЛЮЧЕНИЕ 10
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 12
ПРИЛОЖЕНИЕ 14
ВВЕДЕНИЕ
Учебная практика проходила в архиве МФЮА с 28 ноября 2018г. по 14 декабря 2018г МФЮА предоставляет услуги в сфере образования. МФЮА орентированный на выполнения идеи комплексного подхода к формированию карьеры молодого специалиста. С 2003 года МФЮА занимает первое место среди акередитованных негосударсвенных вузов.
Во время проведения производственной практики, требовалось выполнить следующую цель и задачи.
Цель практики:
Задачи практики :
— Провести анализ бизнес-процессов организации;
— Сформировать требования к программному модулю (техническое задание);
— Спроектировать программный модуль с использованием специализированных программных пакетов;
Приводится аналитическая часть. Анализ бизнес-процессов организации, формирование требований к программному модулю, проектирование программного модуля.
ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО МОДУЛЯ
Анализ бизнес-процессов организации
Производственная практика проходила в отделе информационных технологий.
Ее главные направления:
1. Повышение надежности, экономичности и качества оказываемых услуг в сфере водоснабжения и канализации;
2. Оптимизация количества персонала;
3. Автоматизация важнейших процессов;
4. Эффективное управление бизнес-процессами предприятия;
5. Увеличение сбора доходов.
Предприятие использует систему управления базами данных 1C:Предприятие. На данной системе построена база данных предприятия. У предприятия имеется одна, многофункциональная информационная база данных.
Во время практики в информационном отделе, был выдан доступ лишь к одному из сегментов базы данных, связанных с техническим обслуживанием. Ограничение доступа к полному функционалу базы обусловлено техникой безопасности. Например, бухгалтер данного предприятия, не сможет использовать сегмент базы, отвечающий за формирование личного кабинета клиента. Полный уровень доступа имеют лишь начальник информационного отдела и сотрудники, отвечающие за стабильное функционирование информационной базы данных в целом.
Сегмент технического обслуживания информационной базы данных представляет собой перечень заявок для устранения неполадок на рабочих станциях, замену оборудования, неисправности других сегментов/элементов базы данных.
Любой сотрудник данного предприятия имеет возможность лишь формировать заявку на устранение неполадки и удалять ее, если неполадка была устранена без помощи информационного отдела.
Заявки отображаются в общем списке у информационного отдела. У данных заявок имеется приоритет. Такие заявки как замена принтера имеют низкий приоритет, следовательно, заявки восстановление сегментов информационной базы, устранение неполадок сервера, имеют более высокий приоритет. Приоритет варьируется в связи с замедление работы предприятия.
Требования к программному модулю
В данной главе сформулируем необходимые требования для качественного программного модуля.
Для исправного функционирования и последующего тестирования модуля, необходимо разработать прототип системы, в которую впоследствии будет внедрен данный модуль
Разрабатываемая система должна обладать следующими качествами:
Система должна использовать общедоступные и специфицированные решения, протоколы и интерфейсы, что будет обеспечивать интеграцию создаваемых решений, как между собой, так и с внешними информационными системами.
Система должна быть построена с использованием модульной архитектуры, подразумевающей реализацию основных функций в качестве отдельных модулей, обеспечивающих возможность их независимой модификации. Сбой в работе одного из модулей не должен приводить к полному прекращению функционирования системы в целом.
Архитектура системы должна позволять увеличивать производительность подсистем, объемы хранимой и обрабатываемой информации без длительной остановки работы и значительной модификации системы.
4. Управляемость и конфигурирование;
Механизмы управления должны обеспечивать управление создаваемой системы на всех уровнях ее архитектуры: на уровне инфраструктуры, на функциональном уровне, на уровне представления данных.
Все взаимосвязанные подсистемы создаваемой системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления.
Предоставление информации пользователям должно осуществляться с учетом персональных настроек пользователей.
7. Единство графического представления;
При проектировании и разработке пользовательских интерфейсов должны использоваться общие принципы графического представления информации и организации доступа пользователей к функциональным возможностям и сервисам создаваемой системы.
1. Просматривать информацию о замене или поверке прибора учета, находящегося на балансе пользователя;
2. Подать заявку на опломбировку обводной задвижки;
3. Подать заявку о неисправности прибора учета, находящегося на балансе АО «МФЮА»;
4. Удаленно получать и отправлять расчетно-платежные документы;
5. Отслеживать статус отправленных расчетно-платежных документов;
6. Иметь электронный архив, с удобным инструментом поиска.
1. Добавлять пользователей абонента (пользователей сервиса), как тех, кто еще не работает с сервисом, так и пользователей других абонентов;
2. Управлять правами доступа пользователей абонента к приложениям абонента;
3. Ограничивать максимальное количество сеансов пользователей абонента с приложениями абонента;
4. Продлить доступ абонента к сервису;
5. Получать отчеты о работе пользователей абонента.
Источник: megaobuchalka.ru
Формирование конкретных требований к программным модулям
Нам удалось представить решение всех задач нашей программы в виде последовательности работы программных модулей. Как формулировать требования к этим модулям?
Очевидно, что требования к результатам работы последнего модуля в цепочке такие же, как и требования к решению задачи. Что нужно сделать, чтобы модуль смог выполнить поставленную перед ним задачу? Часть необходимой информации модуль получит из входных данных, остальное должны передать ему другие модули, стоящие раньше в цепочке решения задачи.
Так формулируются требования к предыдущим модулям. Рассматривая их как последние, сформулируем требования к модулям, стоящим в цепочке раньше. И так до начала цепочки. Это похоже на волну, прокатывающуюся от конца цепочки до начала, поэтому такой метод получил название «Обратная волна требований».
Один и тот же модуль может участвовать в решении нескольких задач. Поэтому требования к нему должны быть сформулированы в результате анализа всех цепочек, в которых он участвует.
Советы молодому программисту.
Может показаться, что описанный путь постановки задачи слишком долгий и скучный. Гораздо проще и интереснее сразу приступить к программированию, хотя бы того, что понятно уже сейчас. Потом можно дописывать программу по мере осмысления задачи и требований пользователя.
Однако, поступив так, Вы достаточно скоро поймете, что разработка Вашей программы зашла в тупик. Добавление нового модуля требует существенной реорганизации данных и изменения логики работы всей программы. Поэтому каждый новый модуль добавляется все с большими трудностями. В конце концов, трудности становятся такими непреодолимыми, что проще написать всю программу заново.
Еще такой путь программирования напоминает строительство жилья богатеющим купцом. В центре, фасадом на улицу, стоит хибара. (Когда-то у купца денег хватило только на нее). Поодаль, в виде пристройки к хибаре, стоит добротный кирпичный дом (разбогател купец). А на отшибе, там, где у других стоит туалет, возведен роскошный особняк.
Хотелось бы Вам жить в таком доме?
Единая система программной документации
Для обеспечения сопоставимости и единства интерпретации программной документации в Советском Союзе была разработана Единая Система Программной Документации (ЕСПД). Ниже приводятся выдержки из головного стандарта системы: ГОСТ 19.001-77 «Общие положения», определяющего назначение, состав и область применения ЕСПД.
Понравилась статья? Не забудь поделиться с друзьями:
Источник: studopedia.ru