Классификация методов проектирования программных продуктов
Структурное проектирование и программирование. Объектно-ориентированное проектирование.
- Классификация методов проектирования программных продуктов.
Порой бывает сложно представить сложную распределенную систему в уме перед началом работ. Если предъявляются требования переносимости, быстродействия и стабильности, то первым шагом лучше избрать проектирование. Ведь многие сооружения, механическое и электронное оборудование, которое нас окружают, появились на свет, только пройдя через стадию проектирования. Именно на данном начальном этапе закладывается фундамент для стабильной и предсказуемой службы устройства. С программным продуктом дела обстоят точно так же. ПО проектируют системные архитекторы.
Системные архитекторы — это очень дорогие специалисты в сфере информационных технологий и разработки ПО, они отвечают за построение оптимальной модели всей проектируемой системы, соответствующей принятым требованиям надежности и масштабируемости. Среди инструментов, как правило, используют язык описания систем UML, язык описания баз данных IDEF 1.x и т.д.
- Шаблоны проектирования
Для создания расширяемой и стабильной архитектуры существуют многочисленные абстрактные решения, которые называются шаблонами проектирования. Однако полное понимание этих принципов написания программных продуктов и свободное владение ими требует значительного времени и опыта от разработчика программного обеспечения. Для примера приведем часто используемые в разработке коммерческого ПО шаблоны проектирования вместе с их диаграммами классов.
Декоратор (Decorator) — динамически возлагает на объект новые функции, применяется для расширения имеющейся функциональности и является гибкой
альтернативой наследованию в ООП.
Шаблонный метод (Template Method) — определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.
Фасад (Facade) — предоставляет унифицированный интерфейс к множеству интерфейсов в некоторой подсистеме. Определяет интерфейс более высокого уровня, облегчающий работу с подсистемой.
Абстрактная фабрика (Abstract Factory) — компонент, создающий некоторый набор объектов определенного интерфейса. Используется для реализации кросс-платформенности, изменяемых элементов графического пользовательского интерфейса (GUI) и т.д. В ADO.NET используется для унификации работы с провайдерами баз данных.
Команда (Command) – инкапсулирует некоторую операцию в объект, накладывая возможность откатить изменения. Используется в программных меню во многих профессиональных приложениях.
Компоновщик (Composite) – определяет одинаковый интерфейс для части и для целого, позволяя их трактовать единообразно. Встречается очень часто, простой пример: структуры для моделирования деревьев, где лист, ветвь и само дерево имеют одинаковый интерфейс и могут быть обработаны одним и тем же кодом.
Наблюдатель (Observer) – позволяет регистрировать множество слушателей некоторых событий, причем при наступлении этого события происходит уведомление всех подписанных слушателей.
Проектирование алгоритмов и программ - наиболее ответственный этап жизненного цикла программных продуктов, определяющий, насколько создаваемая программа соответствует спецификациям и требованиям со стороны конечных пользователей. Затраты на создание, сопровождение и эксплуатацию программных продуктов, научно-технический уровень разработки, время морального устаревания и многое другое- все это также зависит от проектных решений. Методы проектирования алгоритмов и программ очень разнообразны, их можно классифицировать по различным
признакам, важнейшими из которых являются: степень автоматизации проектных работ и принятая методология процесса разработки.
По степени автоматизации проектирования алгоритмов и программ можно выделить: методы традиционного проектирования и методы автоматизированного проектирования (CASE-технология и ее элементы).
Неавтоматизированное проектирование алгоритмов и программ преимущественно используется при разработке небольших по трудоемкости и структурной сложности программных продуктов, не требующих участия большого числа разработчиков. Трудоемкость разрабатываемых программных продуктов, как правило, небольшая, а сами программные продукты имеют преимущественно прикладной характер.
При нарушении этих ограничений заметно снижается производительность труда разработчиков, падает качество разработки, и, как ни парадоксально, увеличиваются трудозатраты и стоимость программного продукта в целом.
Автоматизированное проектирование алгоритмов и программ возникло с необходимостью уменьшить затраты на проектные работы, сократить сроки их выполнения, создать типовые "заготовки" алгоритмов и программ, многократно тиражируемых для различных разработок, координации работ большого коллектива разработчиков, стандартизации алгоритмов и программ.
Автоматизация проектирования может охватывать все или отдельные этапы жизненного цикла программного продукта, при этом работы этапов могут быть изолированы друг от друга, либо составлять единый комплекс, выполняемый последовательно во времени. Как правило, автоматизированный подход требует технического и программного "перевооружения" труда самих разработчиков (мощных компьютеров, дорогостоящего программного инструментария, а также повышения квалификации разработчиков и т.п.).
Проектирование алгоритмов и программ может основываться на различных подходах, среди которых наиболее распространены:
-структурное проектирование программных продуктов;
-информационное моделирование предметной области и связанных с ней
приложений;
-объектно-ориентированное проектирование программных продуктов.
В основе структурного проектирования лежит последовательная декомпозиция, целенаправленное структурирование на отдельные составляющие. Начало развития структурного проектирования алгоритмов и программ падает на 60-е гг. Методы структурного проектирования представляют собой комплекс технических и организационных принципов системного проектирования.
Типичными методами структурного проектирования являются: нисходя-
щее проектирование, кодирование и тестирование программ, модульное программирование, структурное проектирование (программирование) и др.
В зависимости от объекта структурирования различают: функционально-
ориентированные методы - это последовательное разложение задачи или целостной проблемы на отдельные составляющие, обладающие функциональ-
ной определенностью; методы структурирования данных.
Для функционально-ориентированных методов в первую очередь учитываются заданные функции обработки данных, в соответствии с которыми определяется состав и логика работы (алгоритмы) отдельных компонентов программного продукта. С изменением содержания функций обработки, их состава, соответствующего им информационного входа и выхода требуется перепроектирование программного продукта. Основной упор в структурном подходе делается на моделирование процессов обработки данных.
Для методов структурирования данных осуществляется анализ, структурирование и создание моделей данных, применительно к которым устанавливается необходимый состав функций и процедур обработки. Программные продукты тесно связаны со структурой обрабатываемых данных, изменение которой отражается на логике обработки (алгоритмах) и обязательно требует перепроектирования программного продукта.
Структурный подход использует:
-диаграммы потоков данных (информационно-технологические схемы) –
показывают процессы и информационные потоки между ними с учетом
"событий", инициирующих процессы обработки;
-интегрированную структуру данных предметной области;
-диаграммы декомпозиции - структура и декомпозиция целей, функций управления, приложений;
-структурные схемы - архитектура программного продукта в виде иерархии взаимосвязанных программных модулей с идентификацией связей между ними, детальная логика обработки данных программных модулей (блок-схемы).
Для полного представления о программном продукте необходима также текстовая информация описательного характера.
Еще большую значимость информационные модели и структуры данных имеют для информационного моделирования предметной области, в основе которого положение об определяющей роли данных при проектировании алгоритмов и программ. Подход появился в условиях развития программных средств организации хранения и обработки данных – СУБД.
Один из основоположников информационной инженерии - Дж. Мартин - выделяет следующие составляющие данного подхода:
-информационный анализ предметных областей (бизнес - областей);
-информационное моделирование - построение комплекса взаимосвязанных моделей данных;
-системное проектирование функций обработки данных;
-детальное конструирование процедур обработки данных.
Первоначально строятся информационные модели различных уровней представления:
-информационно-логическая модель, не зависящая от средств программной реализации хранения и обработки данных, отражающая интегрированные структуры данных предметной области;
-даталогические модели, ориентированные на среду хранения и обработки данных.
Даталогические модели имеют логический и физический уровни
представления. Физический уровень соответствует организации хранения данных в памяти компьютера. Логический уровень данных применительно к СУБД реализован в виде:
-концептуальной модели базы данных - интегрированные структуры данных под управлением СУБД;
-внешних моделей данных - подмножество структур данных для реализации приложений.
Средствами структур данных моделируются функции предметной области, прослеживается взаимосвязь функций обработки, уточняется состав входной и выходной информации, логика преобразования входных структур данных в выходные. Алгоритм обработки данных можно представить как совокупность процедур преобразований структур данных в соответствии с внешними моделями данных.
Выбор средств реализации базы данных определяет вид даталогических моделей и следовательно, алгоритмы преобразования данных. В большинстве случаев используется реляционное представление данных базы данных и соответствующие реляционные языки для программирования (манипулирования) обработки данных СУБД и реализации алгоритмов обработки . Данный подход использован во многих CASE-технологиях.
Объектно-ориентированный подход к проектированию программных продуктов основан на:
-выделении классов объектов;
-установлении характерных свойств объектов и методов их обработки;
-создании иерархии классов, наследовании свойств объектов и методов их обработки.
Каждый объект объединяет как данные, так и программу обработки этих данных и относится к определенному классу. С помощью класса один и тот же программный код можно использовать для относящихся к нему различных объектов. Объектный подход при разработке алгоритмов и программ предполагает: объектно-ориентированный анализ предметной области и
объектно-ориентированное проектирование.
Объектно-ориентированный анализ - анализ предметной области и выделение объектов, определение свойств и методов обработки объектов, установление их взаимосвязей.
Объектно-ориентированное проектирование соединяет процесс объектной декомпозиции и представления с использованием моделей данных проектируемой системы на логическом и физическом уровнях, в статике и динамике.
Для проектирования программных продуктов разработаны объектно-ориентированные технологии, которые включают в себя специализированные языки программирования и инструментальные средства разработки пользовательского интерфейса.
Традиционные подходы к разработке программных продуктов всегда подчеркивали различия между данными и процессами их обработки. Так, технологии, ориентированные на информационное моделирование, сначала специфицируют данные, а затем описывают процессы, использующие эти данные. Технологии структурного подхода ориентированы, в первую очередь, на процессы обработки данных с последующим установлением необходимых для этого данных и организации информационных потоков между связанными процессами.
Объектно-ориентированная технология разработки программных продуктов объединяет данные и процессы в логические сущности - объекты, которые имеют способность наследовать характеристики (методы и данные) одного или более объектов, обеспечивая тем самым повторное использование программного кода. Это приводит к значительному уменьшению затрат на создание программных продуктов, повышает эффективность жизненного цикла программных продуктов (сокращается длительность фазы разработки).При выполнении программы объекту посылается сообщение, которое инициирует обработку данных объекта.
- Этапы создания программных продуктов
При традиционной неавтоматизированной разработке программ независимо от принятого метода проектирования и используемого инструментария выполняют следующие работы.
2.1) Составление технического задания на программирование
Данная работа соответствует этапу анализа и спецификации программ жизненного цикла программных продуктов.
При составлений технического задания требуется:
-определить платформу разрабатываемой программы - тип операционной системы (например, для IBM PC-совместимых машин делается выбор операционной среды: MS DOS, Windows, Windows NT либо Unix, OS/2);
-оценить необходимость сетевого варианта работы программы (определяется программное обеспечение (ПО) вычислительной сети - Windows NT, допустимая номенклатура программного обеспечения сетевой обработки);
-определить необходимость разработки программы, которую можно переносить на различные платформы;
-обосновать целесообразность работы с базами данных под управлением СУБД.
На этом же этапе выбирают методы решения задачи; разрабатывают обобщенный алгоритм решения комплекса задач, функциональную структуру алгоритма или состав объектов, определяют требования к комплексу технических средств системы обработки информации, интерфейсу конечного пользователя.
2.2) Технический проект
На данном этапе выполняется комплекс наиболее важных работ, а именно:
-с учетом принятого подхода к проектированию программного продукта разрабатывается детальный алгоритм обработки данных или уточняется состав объектов и их свойств, методов обработки, событий, запускающих методы обработки;
-определяется состав общесистемного программного обеспечения, включающий базовые средства (операционную систему, модель СУБД, электронные таблицы, методо- ориентированные и функциональные ППП промышленного назначения и т.п.);
-разрабатывается внутренняя структура программного продукта, образованная отдельными программными модулями;
-осуществляется выбор инструментальных средств разработки программных модулей.
Работы данного этапа в существенной степени зависят от принятых решений по технической части системы обработки данных и операционной среде, от выбранных инструментальных средств проектирования алгоритмов и программ, технологии работ.
Для создания MS DОS-приложений может быть использован язык программирования Visual Basic for DOS Standard, Fortran 5.1,Visual C++ for Windows. Если необходима переносимость программ на другие ЭВМ или другие операционные платформы, выбирается среда Windows NT.
При разработке программ, работающих в среде Windows, возможно применение технологии OLЕ 2.0 для создания приложений, включающих объекты других приложений. Определяется способ использования объектов: внедрение (embedding) или связывание (linking).
Приложение может работать с базами данных различных СУБД, для этого служит стандартная технология интерфейса Open Database Connectivity (ODBC). Работа в режиме телекоммуникаций обеспечивается стандартной технологией Messaging Application Program Interface (MAPI).
2.3) Рабочая документация (рабочий проект)
На данном этапе осуществляется адаптация базовых средств программного обеспечения (операционной системы, СУБД, методо-ориентированных ППП, инструментальных сред конечного пользователя - текстовых редакторов и т.п.). Выполняется разработка программных модулей или методов обработки объектов - собственно программирование или создание программного кода. Проводятся автономная и комплексная отладка программного продукта, испытание работоспособности программных модулей и базовых программных средств. Для комплексной отладки готовится контрольный пример, который позволяет проверить соответствие возможностей программного продукта заданным спецификациям.
Основной результат работ этого этапа - также создание эксплуатационной документации на программный продукт:
-описание применения - дает общую характеристику программного изделия с указанием сферы его применения, требований к базовому программному обеспечению, комплексу технических средств;
-руководство пользователя - включает детальное описание функциональных возможностей и технологии работы с программным продуктом. Данный вид документации ориентирован на конечного пользователя и содержит необходимую информацию для самостоятельного освоения и нормальной работы пользователя (с учетом требуемой квалификации пользователя). Руководство программиста (оператора) - указывает особенности установки (инсталляции) программного продукта и его внутренней структуры - состав и назначение модулей, правила эксплуатации и обеспечения надежной и качественной работы программного продукта.
В ряде случаев на данном этапе для программных продуктов массового применения создаются обучающие системы, демоверсии. гипертекстовые системы помощи.
Готовый программный продукт сначала проходит опытную эксплуатацию (пробный рынок продаж), а затем сдается в промышленную эксплуатацию (тиражирование и распространение программного продукта).
- Структура программных продуктов
В большей степени программные продукты не являются монолитом и имеют конструкцию (архитектуру) построения - состав и взаимосвязь программных модулей.
Модуль - это самостоятельная часть программы, имеющая определен-ное назначение и обеспечивающая заданные функции обработки автономно от других программных модулей.
Таким образом, программный продукт обладает внутренней организацией, или внутренней структурой, образованной взаимосвязан-ными программными модулями. Это справедливо для сложных и многофункциональных программных продуктов, которые часто называются программными системами.
Структуризация программ выполняется в первую очередь для удобства разработки, программирования, отладки и внесения изменений в программный продукт. Как правило, программные комплексы большой алгоритмической сложности разрабатываются коллективом разработчиков (2 - 15 и более человек). Управлять разработкой программ в условиях применения промышленных технологий изготовления программ можно лишь на научной основе.
Таким образом, структуризация программных продуктов преследует основные цели:
-распределить работы по исполнителям, обеспечив приемлемую их загрузку и требуемые сроки разработки программных продуктов;
-построить календарные графики проектных работ и осуществлять их координацию в процессе создания программных изделий;
-контролировать трудозатраты и стоимость проектных работ и др.
Структурное "разбиение" программ на отдельные составляющие служит основой и для выбора инструментальных средств их создания, хотя имеет место и обратное влияние - выбор инструментальных средств разработчика программного обеспечения определяет типы программных модулей. При создании программных продуктов выделяются многократно используемые модули, проводится их типизация и унификация, за счет чего сокращаются сроки и трудозатраты на разработку программного продукта в целом.
Некоторые программные продукты используют модули из готовых библиотек стандартных подпрограмм, процедур, функций, объектов, методов обработки данных.
Среди множества модулей различают:
-головной модуль - управляет запуском программного продукта (существует в единственном числе);
-управляющий модуль - обеспечивает вызов других модулей на обработку;
-рабочие модули - выполняют функции обработки;
-сервисные модули и библиотеки, утилиты - осуществляют обслуживающие функции.
В работе программного продукта активизируются необходимые программные модули. Управляющие модули задают последовательность вызова на выполнение очередною модуля. Информационная связь модулей обеспечивается за счет использования общей базы данных либо межмодульной передачи данных через переменные обмена. Каждый модуль может оформлять-
ся как самостоятельно хранимый файл; для функционирования программного продукта необходимо наличие программных модулей в полном составе.
Структурно-сложные программные продукты разрабатываются как пакеты программ, и чаще всего они имеют прикладной характер - пакеты прикладных программ, или ППП.
ППП (application program package) - это система программ, предназначенных для решения задач определенного класса. Компоненты ППП объединены общими данными (базой данных), информационно и функционально связаны между собой и обладают свойством системности, т.е. объединению программ присуще новое качество, которое отсутствует для отдельного компонента ППП. Структура ППП, как правило, многомодульная.
- Технология нисходящего структу
рного программирования
В ХХ в. Большинство языков программирования использовалось по процедурной схеме. Это означает, что программа разбивалась на модули – небольшие участки, которые могли вызываться по многу раз в ходе выполнения программы. Для такого способа построения программы была разработана технология программирования, которая называлась «Технология нисходящего структурного программирования». Так как программирование является высокотехнологичной отраслью производства, серьезные программы разрабатывались в строгом соответствии с ТНСП. Эта технология была разработана фирмой IBM и позволяла перейти к промышленным способам производства программ. Стало легко проектировать программы, исправлять ошибки и предотвращать возникновения новых ошибок.
ТНСП имеет 3 составляющие:
а) нисходящую разработку;
б) структурное кодирование;
в) сквозной контроль.
Нисходящая разработка - это подход к разработке программного комплекса, при котором он разбивается на программные модули (программы), образующие многоуровневую структуру (не путать с понятием "модуль", которое используется для определения синтаксической конструкции языка программирования, например, UNIT в Borland Pascal). Каждый программный модуль представляет собой короткую программу, решающую отдельную задачу (подзадачу). В процессе разработки программные модули нижележащих уровней заменяются "заглушками". Таким образом, в любой момент разработки программного комплекса имеется его действующий вариант. Тестирование и отладка отдельных программных модулей и программного комплекса в целом ведется по ходу его проектирования.
При нисходящей разработке проектирование программного комплекса и кодирование программных модулей, входящих в программный комплекс,
ведётся сверху вниз.
В языках программирования, ориентированных на технологию нисходящего структурного программирования, одним из средств реализации модульной структуры являются процедуры и функции.
Использование небольших
программных модулей имеет
Нисходящая разработка – подход, при котором программа разбивается на небольшие модули, которые объединяются в многоуровневую структуру (наподобие дерева каталогов). Каждый модуль – это отдельная программа, выполняющая свою функцию.
Преимущества модульной структуры программы:
- программу, состоящую из маленьких модулей легко модифицировать;
- маленькие модули легко тестируются и отслеживаются.
Структурное
кодирование подразумевает
После появления
графических интерфейсов у
В ООП применяется более абстрактный подход к составным частям
программы. Главное действующее лицо ООП - программы – это не процедура и не модуль, а объект. Так объектом в программе может быть кнопка, форма, изображение и т.д. Разработка программного комплекса на визуальных языках программирования, таких как Visual C, Delphi, Visual Basic, все больше напоминает работу с конструктором, когда для каждого элемента окна программы не надо писать никакого программного кода, а достаточно просто взять готовый элемент из панели инструментов и поместить его в нужном месте. Система программирования сама заботится о том, чтобы формы и элементы приложения имели все свойства, необходимые для любой программы, работающей под Windows.
Под сквозным контролем целостности понимается запись на диск контрольной суммы для каждого блока данных, причем контрольная сумма и данные специально разносятся максимально далеко друг от друга для снижения вероятности их совместной порчи. Если в пуле есть несколько устройств, то для данных, размещенных на одном из них, контрольная сумма будет записана на другом. Контрольные суммы вычисляются не только для данных, но и для метаданных, и получается, что в пуле всегда есть контрольная сумма для каждого блока информации.
При считывании любого блока подсчитывается его контрольная сумма, и результат сравнивается с контрольной суммой, хранящейся на диске. В случае расхождения ошибка сразу обнаруживается. Разумеется, если в пуле заранее не было запланировано никакого резервирования (ни RAID-Z, ни иного), то ошибку уже не исправишь, но зато испорченные данные не будут выданы за истинные.
Смысл сквозного контроля целостности данных состоит в том, чтобы предотвратить скрытую незаметную порчу данных в результате сбоя оборудования или встроенного программного обеспечения диска. Несмотря на то, что вероятность такого события кажется низкой, некоторые исследования показывают, что она вполне значима для организаций любого масштаба.
4) Проектирование интерфейса пользователя
4.1) Диалоговый режим
Большинство программных продуктов, особенно прикладного характера, ориентированных на конечного пользователя, работают в диалоговом режиме взаимодействия с пользователем таким образом, что ведется обмен сообщениями, влияющими на обработку данных.
В диалоговом режиме под воздействием пользователя осуществляются запуск функций (методов) обработки, изменение свойств объектов, производится настройка параметров выдачи информации на печать и т.п.
Системы, поддерживающие диалоговые процессы, классифицируются на:
системы с жестким сценарием диалога - стандартизированное представление информации обмена;
- Классификация методов психологии
- Классификация методов психологических исследований
- Классификация методов социологического исследования
- Классификация методов управления
- Классификация методов управления качеством
- Классификация механизма повреждений
- Классификация миграций
- Классификация методов обучения
- Классификация методов обучения
- Классификация методов обучения
- Классификация методов оценки эффективности
- Классификация методов принятия решений
- Классификация методов проведения исследования систем управления
- Классификация методов прогнозирования
