Основы программной архитектуры: ключевые заметки

Системное проектирование

Принцип проектирования: класс проектирования

Принцип единственной ответственности (SRP) Для изменения класса должно быть более одной причины
Принцип открытости/закрытости (OCP) Программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации
Принцип подстановки Лисков (LCP) Указатели ссылок на базовые классы должны иметь возможность использовать объекты производных классов, не зная об этом
Принцип разделения интерфейса (ISP) Много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения
Принцип инверсии зависимостей (DIP) Зависимость от абстракций, а не от конкретики

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

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

Еще одним важным фактором, который обусловливает необходимость системного подхода (начиная с этапа формулирования требования и постановки задач), является то, что на этот этап приходится до 80 % всех затрат на разработку ППО. При этом он имеет особое значение в обеспечении соответствия результатов разработки потребностям конечных пользователей.

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

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

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

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

Еще одной чертой системной разработки проектов прикладных программ является их ориентация на использование интегрированных и распределенных баз данных. В данном случае в качестве инструментальных средств разработки компонентов программного обеспечения вместе с языками программирования стали применяться языковые средства СУБД.

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

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

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

15

Рабочая документация (рабочий проект)

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

Основной результат работ этого этапа – создание эксплуатационной документации на программный продукт, включающей:

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

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

2.4 Трудности при проектировании программного обеспечения

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

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

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

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

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

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

Недостаточная надёжность также является типичным затруднением в процессе проектирования программного обеспечения. Выявление и исправление ошибок одни из самых сложных действий. Так количество ошибок невозможно предугадать, то и определить время, отводимое на их исправление также невозможно предсказать. Гарантировать отсутствие ошибок не представляется возможным. Решением может являться доказательный подход к процессу. Свой вклад в развитие данного подхода внесли такие ученые как Кнут, Дейкстра и Вирт. Доказательный подход позволяет обнаружить ошибки в программе до её выполнения.

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

Неудачный выбор методологии конструирования программ. От выбора необходимой методологии зависят многие показатели программного обеспечения, такие как гибкость, стоимость и функциональность. Так называемые гибкие методологии разработки помогают решить основные проблемы, однако, стоит отметить, что и каскадная модель (waterfall) так же имеет свои преимущества. В некоторых случаях наиболее целесообразным будет применение гибридных методологий в связке Agile + каскадная модель + MSF + RUP и т.д.

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

Однако данное затруднение не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика товара (не продукта).

Решение.

Идея проста, хотя исполнение достаточно сложное.

Суть состоит в том, что исполнение проектов должно быть ТЕХНОЛОГИЕЙ, а не простой последовательностью шагов проекта.  И, не  «согласно принципам системы управления проектами», а согласно «принципам управления производством» в первую очередь.

Технология означает, что в последовательность действий по достижению целей должна быть заложена научная основа, а не просто опыт и  практика множества прошлых проектов. Как минимум – математическая основа.

Если системный интегратор/франчайзи будет выполнять проекты по технологии, а не по опыту из прежней практики, то он получит конкурентное преимущество перед другими участникам рынка. Ведь практика есть у всех, и результат её описан выше по тексту в предыстории.

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

В качестве такой программы предлагается 1С Система Проектирования Прикладных Решений (СППР).

Это небольшая, недорогая конфигурация предназначена для связки воедино следующих циклов сложных проектов:

Интересно, что когда СППР демонстрируют сами разработчики из 1С на выездных презентациях, то даже они делают упор на блок «Разработка/Сопровождение». Но в реальности, главное преимущество СППР в том, что с её помощью можно связать, формализовать работу аудиторов-методологов-проектировщиков-разработчиков.

А самое главное в СППР то, что с её помощью модификацию ПО можно реализовать как технологию, позволяющую иметь и сохранять чётко формализованную  структуру взаимосвязей объектов и алгоритмов конфигурации с точки зрения пользователя, т.е. пропускать разработку через функциональную архитектуру, что собственно и является работой системного архитектора.

В методологическую основу работы на 1С СППР заложен базовый принцип, описанный в работе Эрика Эванса «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем», а именно: 

Основой, связывающей всех участников проекта, является общий язык. Роль этого языка выполняет список объектов конфигурации 1С – метаданные 1С. Каждый объект конфигурации – это слово языка.

Системное проектирование

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

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

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

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

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

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

Системное проектирование системы управления качеством продукции ( СУКП) основывается на реализации и взаимной увязке указанных категорий.

Системное проектирование однотактннх блоков управления будем считать, что в ревультате получения необходимых исходных данных сформулировано следующее аадание на проектирование ВУ.

Системное проектирование многотактных блоков управления На основании ведения сначала определяются все входные и выходные сигналы проектируемого ВУ, которые показывают на блок-схеме ВУ, раамещая входы слева, а выходы-оправа ( рио.

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

Схема руководства проектированием.

Задачей системного проектирования является формирование оптимальных направлений: системный дизайн, эргономическое и инженерно-психологическое проектирование.

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

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

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

Список архитектурных характеристик (неполный) Характеристики операционной архитектуры

Термин Определение
Доступность Как долго система должна быть доступна (если круглосуточно, то необходимо предусмотреть меры, позволяющие быстро восстановить работоспособность системы в случае любого сбоя).
Непрерывность Возможность восстановления после сбоев.
Производительность Включает стресс-тестирование, анализ пиковых нагрузок, анализ частоты использования функций, требуемой мощности и времени отклика. Приемка производительности иногда требует отдельного испытания, на которое уходят месяцы.
Восстанавливаемость Требования к непрерывности бизнеса (например, в случае сбоя, как быстро система должна быть восстановлена?). Это повлияет на стратегию резервного копирования и требования к дублирующему оборудованию.
Надежность/безопасность Оцените, должна ли система быть отказоустойчивой, или она критически важна, так как влияет на жизнь людей. Если она выйдет из строя, будет ли это стоить компании больших денег?
Устойчивость Способность обрабатывать ошибки и предельные условия во время работы, если пропадает подключение к Интернету, отключается электричество или происходит отказ оборудования.
Масштабируемость Способность системы работать и функционировать при увеличении числа пользователей или запросов.

Предмет проектирования

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

Модели делятся на три основных вида. Эвристический образец – это не физический предмет, а некий образ предмета, который аналитик рисует у себя в голове. Он мысленно оценивает свойства объекта и принимает решение о реализации проекта либо о внесении в него изменений.

Физическая модель характеризуется реальным ее существованием. Однако размеры могут существенно отличаться от предусмотренных проектом. Математический образец – это числовое или аналитическое выражение будущего объекта, которое характеризует его основные свойства и функции.

ИЗМЕНЕННЫЙ подход к проектированию системы

Хотя на этапе проектирования не существует универсального метода, подход RESHADED предлагает инженерам гибкий способ решения многих проблем. Этот подход описывает этапы проектирования практически любой системы с нуля, независимо от того, работаете ли вы над клиентским проектом или участвуете в собеседованиях по проектированию системы. Мы быстро рассмотрим, что означает эта аббревиатура.

  • Требования : Соберите все функциональные и нефункциональные требования, отражающие потребности бизнеса или организации клиента. Функциональные требования представляют собой основные функции, без которых система не будет работать так, как ожидает конечный пользователь, в то время как нефункциональные требования являются важными соображениями, которые не влияют на основные функции.
  • Оценка : оценка аппаратных и инфраструктурных ресурсов, необходимых для реализации системы в масштабе.
  • Схема хранения (необязательно): сформулируйте модель данных с диаграммами потоков данных, если это имеет отношение к рассматриваемой проблеме. Вы захотите определить структуру данных, какие таблицы использовать, типы полей в таблицах и отношения между таблицами (необязательно). Этот шаг может понадобиться, если вы ожидаете данные с высокой нормализацией, вам нужно хранить разные части данных в разных форматах или вы сталкиваетесь с проблемами производительности и эффективности хранилища.
  • Высокоуровневый дизайн: выберите один из 16 строительных блоков, которые мы обсуждали ранее, для выполнения определенных функциональных требований.
  • PI : создавайте интерфейсы, которые пользователи могут использовать для вызова различных служб в системе. Интерфейсы принимают форму вызовов API и обычно представляют собой перевод функциональных требований.
  • Детальный проект: проанализируйте и улучшите проект высокого уровня, добавив или заменив стандартные блоки для удовлетворения нефункциональных требований, а затем обрисовав в общих чертах эти стандартные блоки. В этой схеме должно быть указано, как и почему работают компоненты, зачем они нужны и как они будут интегрированы.
  • Оценка : Сравните детальный проект с требованиями. Обоснуйте компромиссы и взвесьте все за и против альтернативных проектов. Определите области для улучшения и рассмотрите решения любых упущенных проблем.
  • Отличительный компонент/функция. Обсудите уникальную функцию, добавленную в ваш проект для удовлетворения требований. Это обсуждение, которое может следовать за различными этапами процесса, может быть наиболее актуальным для интервью или презентаций по проектированию системы.

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

Принципы упаковки

Принципы связи пакетов Принципы сцепления пакетов
Принцип эквивалентности повторного использования-релиза (REP)
• REP по существу означает, что пакет должен быть создан с многократно используемыми классами
Принцип ациклических зависимостей (ADP)
• ADP утверждает, что в структуре зависимостей не может быть циклов, и что когда выпускается инкрементный релиз, другие разработчики могут перенимать его и строить на его основе
Принцип общего повторного использования (CRP)
• CRP утверждает, что классы, которые обычно используются повторно вместе, должны находиться в одном пакете вместе
Принцип стабильных зависимостей (SDP)
• SDP утверждает, что любые пакеты, которые хочется сделать изменчивыми, не должны зависеть от пакета, который трудно изменить
Общий принцип закрытия (CCP)
• CCP утверждает, что пакет не должен иметь более одной причины для изменения
Принцип стабильных абстракций (SAP)
• SAP утверждает, что стабильный пакет также должен быть абстрактным, чтобы его стабильность не препятствовала его расширению

Принципы SOLID

S Принцип единственной ответственности Для каждого объекта должно быть определено единственное назначение и это должно быть инкапсулировано классом
O Принцип открытости/закрытости Программное обеспечение должно быть открыто для расширения, но закрыто для модификации
L Принцип подстановки Лисков Любой подкласс всегда должен использоваться вместо своего родительского класса
I Принцип разделения интерфейса Много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения
D Принцип инверсии зависимостей Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций

Заключение

Опыт работы в известном системном интеграторе на длительном  проекте в крупной российской холдинговой компании энергетического рынка подвёл итог моего прошлого опыта о качестве работы системных интеграторов и прочих франчайзи, который можно выразить одной фразой – работа интеграторов и франчайзи и её результат строятся ужасающе несистемно.

Для заказчика приёмка результатов работы франчайзи и интеграторов в виде псевдоформализованных под ГОСТ и ISO документов и кода чревата потерями времени и денег, сильной зависимостью, а значит затратами, на сопровождение.

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

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

Автор будет признателен за отклики, вопросы и прочую обратную связь. Благодаря им статья может быть расширена, непонятные места конкретизированы и уточнены. Если читателям будет интересно, то раздел «Описание технологии проектирования» может быть изложен более детально.

Контакты автора:

Роман Кальмансон

Приложение  1

Оцените статью