Системы принятия и синтеза решений, реализующие диалоговый принцип взаимодействия, оформляются в виде пакетов прикладных программ, под которыми подразумевается совокупность программ, совместимых между собой и обеспечивающих решение задач из некоторой предметной области [З].
Основные принципы проектирования программных средств применительно к процессам принятия и синтеза решений следующие.
В основе построения пакетов программ лежит принцип конструктивной независимости, который предполагает разработку универсальной структуры пакета и некоторых его элементов.
Важнейшим принципом построения является модульность программных объектов. Данный принцип означает дискретность структуры пакета и унификацию программных средств в целях формирования различных вычислительных схем, предназначенных для решения задач синтеза и выбора решений.
Унификация программных средств проявляется в том, что каждая программная единица (модуль) предназначена для выполнения определенных функций и взаимодействует с данными некоторым стандартным способом. В этом заключается очередной технологический принцип построения системы — принцип стандартизации взаимодействия программ с данными, который предполагает использование единых методики и механизма подключения программных средств к данным.
Архитектура ПК: Магистрально-модульный принцип построения ПК. Центр онлайн-обучения «Фоксфорд»
Принцип машинной независимости пакетов программ предусматривает возможность эксплуатации разработанного программного и информационного обеспечения при смене типов и поколений вычислительной техники.
Для успешной реализации этого принципа необходимо прежде всего выбрать универсальный алгоритмический язык. В качестве такого языка может быть выбран Си++ в силу его широкой распространенности на современных персональных ЭВМ.
Принцип максимальной независимости от операционных систем непосредственно связан с принципом машинной независимости и преемственности систем.
Необходимое условие жизнеспособности программного обеспечения — соблюдение принципа расширяемости, согласно которому пакеты программ являются открытыми системами, допускающими их непрерывное пополнение новыми программными средствами. Реализация этого принципа возможна лишь при соблюдении принципа модульности структуры пакета программ.
При разработке программного обеспечения для решения сложных задач принятия, планирования и синтеза решений, требующих активного вмешательства или непосредственного участия человека в процессе решения, особенно важно следовать принципу коммуникабельности, который предполагает простоту общения пользователя с пакетом и предусматривает работу в интерактивном режиме.
7.5. Основные правила разработки систем
В процессе разработки диалоговых систем следует учитывать множество требований, которые условно можно подразделить на требования, определяющие принципы проектирования систем, и требования к эксплуатационным характеристикам диалоговых, систем.
Принципы проектирования диалоговых систем. К ним относятся следующие правила
1. Прежде чем перейти к обсуждению достоинств и недостатков некоторой существующей системы или выдвижению требований к разработке системы с заданными свойствами, пользователь должен познакомиться с какой-либо моделью системы практически.
Информатика 10 класс (Урок№6 — Основополагающие принципы устройства компьютеров.)
2. Разработка конкретных диалоговых систем, как правило, нацелена на автоматизацию процедур решения задач определенного класса. Поэтому проектировщику следует максимально использовать опыт работы и методологию, которые применялись пользователями создаваемой системы на практике, а не навязывать новую технологию решения задач.
3. Следует предусмотреть адаптивную обратную связь между пользователем и системой, позволяющую разработчику в интерактивном режиме приспособить систему к реальным условиям решения задачи. Наличие обратной связи дает возможность модифицировать систему с учетом новых требований ЛПР и новых задач.
4. При проектировании систем необходимо предусмотреть методы контроля и защиты информации, включающие следующие процедуры:
• синтаксический, логический и численный контроль информации;
• коррекцию ранее полученной информации;
• прерывание процедуры выполнения с возвратом в подходящую точку алгоритма с восстановлением исходных состояний файлов экспертной информации.
5. В процессе работы системы необходима фиксация ее деятельности с помощью ЭВМ для обеспечения накопления протоколов работы, последующий анализ которых позволяет интерпретировать и аргументировать решения, а также выявить ошибки, подразделяя их на ошибки пользователя и системы.
Требования к эксплуатационным характеристикам диалоговых систем. К этим требованиям можно отнести следующие.
1. Правила адаптации субъекта к диалоговым системам предназначены для разработки систем, действующих на естественном языке, что является целью большинства исследований по искусственному интеллекту. При этом требование соблюдения таких условий, как участие пользователя в создании системы и обоснованность любых действий системы, определяется в зависимости от ранее указанных особенностей класса решаемых задач и типа предпочтений ЛПР. Эти условия предполагают, что пользователь не является пассивным элементом в системе и все действия разрабатываемой системы необходимо оценивать относительно их воздействия на активно изменяющегося пользователя, пытающегося понять и познать систему.
2. Условия проектирования диалоговых систем, диктующие необходимость снижения умственной нагрузки на пользователя-непрофессионала, предполагают выполнение следующих требований:
• единообразие вычислительных и опросных процедур и терминологии: желательно пользоваться привычной лексикой пользователя, т.е. система должна либо проектироваться для конкретной задачи, либо иметь возможность настраиваться на специфическую терминологию конкретной пользовательской области;
• определение последовательности предоставления информации и возможность получения углубленной информации по мере необходимости;
• обучение, основанное на опыте работы пользователя; предлагается снабдить пользователя подсказками с помощью ЭВМ и обеспечить возможность накопления опыта путем тренировочных просчетов;
• обозримость состояния диалога, которая предполагает использование кратких форм диалога (вопрос — ответ, выбор из меню) либо ответов на ограниченном естественном языке, не допускающем неоднозначное трактование требуемых в конкретной ситуации действий.
Дополнительно необходимо отметить, что помощь, предоставляемая пользователю со стороны системы, должна быть благожелательной, обеспечивать всестороннюю поддержку, выдачу справочной информации любой степени детализации в любой момент по требованию, своевременную ясную и точную диагностику ошибок пользователя с указанием способов их преодоления. Однако эта помощь системы не должна быть избыточной. Таким образом, одновременно с адаптацией пользователя к системе должен происходить и обратный процесс адаптации системы, который позволяет учесть уровень обучения пользователя и тем самым минимизировать его умственную нагрузку путем снижения числа вопросов, сокращения их формулировок и т. п.
Источник: studfile.net
Общие принципы разработки программного обеспечения
Программы различаются по назначению, выполняемым функциям, формам реализации. Однако можно полагать, что существуют некоторые общие принципы, которые следует использовать при разработке программ.
Частотный принцип
Принцип основан на выделении в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся при работе программ, создаются условия их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. «Частые» операции стараются делать более короткими. Следует отметить, что лишь не более 5 % операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать без учета скорости вычислений, обращая основное внимание при этом на «красоту» и наглядность текстов.
Принцип модульности
Под модулем в данном контексте понимают функциональный элемент рассматриваемой системы, имеющий оформление, законченное и выполненное в пределах требований системы, и средства сопряжения с подобными элементами или элементами более высокого уровня данной или другой системы. Способы обособления составных частей программ в отдельные
модули могут различаться существенно. В значительной степени разделение системы на модули определяется используемым методом проектирования программ.
Принцип функциональной избирательности
Этот принцип является логическим продолжением частотного и модульного принципов и используется при проектировании программ. В программах выделяется некоторая часть важных модулей, которые постоянно должны быть в состоянии готовности для эффективной организации вычислительного процесса. Эту часть в программах называют ядром или монитором.
При формировании состава монитора требуется учесть два противоречивых требования. В состав монитора, помимо чисто управляющих модулей, должны войти наиболее часто используемые модули. Количество модулей должно быть таким, чтобы объем памяти, занимаемой монитором, был не слишком большим. Программы, входящие в состав монитора, постоянно хранятся в оперативной памяти. Остальные части программ постоянно хранятся во внешних запоминающих устройствах и загружаются в оперативную память только при необходимости, перекрывая друг друга также при необходимости.
Принцип генерируемости
Основное положение этого принципа определяет такой способ исходного представления программы, который бы позволял осуществлять настройку на конкретную конфигурацию технических средств, круг решаемых проблем, условия работы пользователя.
Принцип функциональной избыточности
Этот принцип учитывает возможность проведения одной и той же работы различными средствами. Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи одних и тех же данных разными способами вызова из-за психологических различий в восприятии информации.
Принцип «по умолчанию»
Применяется для облегчения организации связей с системой как на стадии генерации, так и при работе с уже готовыми программами. Принцип основан на хранении в системе некоторых базовых описаний структур, модулей, конфигураций оборудования и данных, определяющих условия работы с программой. Эту информацию программа использует в качестве заданной по умолчанию, если пользователь забудет или сознательно не конкретизирует ее.
Источник: itandlife.ru
Принципы проектирования
Процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.
DRY
Don’t repeat yourself — не повторяйте себя
Это принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы». Он был сформулирован Энди Хантом и Дэйвом Томасом в их книге The Pragmatic Programmer.
KISS
Keep It Stupid Simple (Keep it short and simple / Keep it simple, stupid) — Придерживайся простоты
Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности.
SLAP
Single Level of Abstraction Principle — «Принцип единого уровня абстракций»
Диктует нам, как мы должны организовывать свой код (в частности, функции), чтобы он оставался поддерживаемым.
SOLID
SOLID это аббревиатура пяти основных принципов проектирования в объектно-ориентированном программировании, предложенных Робертом Мартином:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
SRP
Single Responsibility Principle — «Принцип единой ответственности», SRP
В чем-то похож на SLAP, но направлен на объектно-ориентированное программирование. Этот принцип гласит, что объекты и классы (а также функции и методы) нужно организовывать так, чтобы каждый из них имел только одну зону ответственности.
OCP
Open-Closed Principle — «Принцип открытости-закрытости»
Требует, чтобы код был открыт для новых, будущих дополнений, и чтобы при их добавлении не приходилось изменять уже написанный код. Этот принцип в большей степени затрагивает вопросы архитектуры, чем кода как такового.
LSP
Liskov Substitution Principle — «Принцип подстановки Барбары Лисков»
Назван в честь его автора, Барбары Лисков. Суть его в том, что каждый подтип должен дополнять, а не заменять базовый тип.
ISP
Interface Segregation Principle — «Принцип разделения интерфейса»
Это еще один принцип, затрагивающий тему организации кода.
DIP
Dependency Inversion Principle — «Принцип инверсии зависимостей»
Как и OCP, DIP, в большей степени касается общей архитектуры кода. Фактически, это один из самых важных принципов проектирования архитектуры кода.
- код должен быть написан так, чтобы детали реализации (например, пользовательский интерфейс или база данных) зависели от основной логики (правил бизнеса), а не наоборот.
- все эти зависимости не должны быть прямыми. Их нужно абстрагировать при помощи интерфейсов, чтобы основная логика работала со всем, что бы ей ни передали, требуя для этого только какой-нибудь простой «мост».
CQS
Command-Query Separation — разделения команд и запросов
Все функции некоторого интерфейса должны быть или некоторыми запросами, возвращающими ответ, или командами, изменяющими состояние системы, но не одновременно. Никогда функция не должна возвращать ответ и изменять состояние системы одновременно.
LoD
Law of Demeter — закон Деметры
Говорит нам примерно следующее: «не разговаривай с незнакомцами и не создавайте ненужных зависимостей». Закон Деметры — это, скорее, рекомендация, о которой стоит помнить.
IoC
Inversion of Control — Инверсия управления
Важный принцип объектно-ориентированного программирования, используемый для уменьшения зацепления (связанности) в компьютерных программах. Он подразумевает что ходом программы управляет внешний, по отношению к ней, фреймворк. Dependency Injection (DI) является частью IoC.
DI
Dependency Injection — Внедрение зависимости
Стиль разработки программного кода, когда в зависимости класса не создаются им напрямую, а внедряются из вне. При этом уменьшается связанность кода, но теряется контроль над созданием и временем жизни объектов, от которых зависит класс.
DAMP
Descriptive And Meaningful Phrases — Описательные и значимые фразы
Принцип написания модульных тестов таким образом, чтобы происходящее в них можно было понять без дополнительных комментариев и документации. Достигается использованием описательных имен и допускает небольшие нарушения принципа DRY при необходимости.
AAA (3A)
Arrange Act Assert — Условие, Действие, Проверка
Это шаблон для форматирования Unit тестов. Обозначающий разделения теста на 3 части
- Arrange — все необходимые подготовки и входные данные
- Act — собственно, вызов того метода который вы тестируете
- Assert — проверка, что метод делает то что надо
GRASP
General Responsibility Assignment Software Patterns — общие шаблоны распределения ответственностей
Это набор шаблонов, используемых в объектно-ориентированном проектировании для решения общих задач по назначению ответственностей классам и объектам.
Information Expert
Информационный эксперт – класс, сосредотачивающий информацию о конкретной предметной области. Операции над ней также передаются в его ответственность. Например, Aсcount хранит информацию о счете и может предоставить выписку с него.
Creator (Создатель)
Классы, создающие другие классы. Это может быть фабрика, пул и т.д.
Controller (Контроллер)
Объект, который несет в себе управляющие функции (не путать с бизнес-логикой приложения). Яркий пример — Контроллер в шаблоне MVC.