Рекомендации по разработке исходного кода
Методичні вказівки
До лабораторних робіт по курсу
«Принципи проектування інформаційних систем»
Для спеціальності 6.080201 – “Інформатика”
Харків 2011
Введение
Уровень развития современного программного обеспечения требует специальных подходов и знаний в области проектирования ПО. Наличие качественной архитектуры и документации определяют будущие качества программного обеспечения. Приобретение знаний и навыков в проектировании программного обеспечения является необходимой составляющей в общей структуре знаний современных специалистов. Разработка архитектуры программного продукта является первым этапом в разработке любого программного продукта.
Данные методические указания предназначены для проведения лабораторных работ по курсу «Принципи проектування інформаційних систем». В ходе выполнения лабораторных работ по курсу студенты должны на практике разработать архитектуру системы согласно своего задания.
Краткие теоретические сведения
Типичные компоненты архитектуры программного продукта
Типичные компоненты архитектуры программного продукта и типичные требования к ПО
Ø Организация программы
Ø Основные классы системы
Ø Организация данных
Ø Бизнес–правила
Ø Пользовательский интерфейс
Ø Управление ресурсами
Ø Безопасность
Ø Производительность
|
|
|
Ø Масштабируемость
Ø Взаимодействие с другими системами (интеграция)
Ø Интернационализация, локализация
Ø Ввод-вывод данных
Ø Обработка ошибок
1. Организация программы.
Архитектура должна включать подтверждение факта, что при ее разработке были рассмотрены альтернативные варианты и должен быть обоснован выбор окончательной организации системы. Архитектура должна определять все основные компоненты программы, а также ответственность каждого из этих компонент за выполнение определенной задачи. Архитектура должна ясно определять все правила взаимодействия между всеми компонентами системы.
2. Основные классы системы.
При разработке архитектуре крайне желательно проработать все основные классы, которые будет реализовать данные системы. Необходимо стараться, чтобы примерно 20% всех классов определяли 80% функциональности системы.
3. Организация данных.
Архитектура должна описывать все основные типы данных, с которыми будет работать программа, все таблицы и их поля, а также все связи между таблицами. При разработке системы обмена информации с БД рекомендуется разработать отдельный класс, который будет обеспечивать доступ к БД всех остальных компонент системы.
|
|
|
4. Бизнес–правила.
Любая система, которая каким-либо образом взаимодействует с конечным клиентом, может иметь определенный набор бизнес правил, которые определяют права использования клиент-системы, права доступа к определенным услугам системы БД, правила расчета показателей и т.д. Этот модуль должен разрабатываться как независимая подсистема, предоставлять интерфейс для доступа всем остальным компонентам системы. Данная подсистема должна иметь достаточно гибкие возможности по модификации параметров и самих бизнес правил.
5. Пользовательский интерфейс.
Рекомендуется проработать общие требования к пользовательскому интерфейсу на этапе разработке архитектуры. Необходимо постараться описать все основные экраны (окна или страницы web-сайта), чтобы в последующем внешний вид интерфейса был утвержден перед разработкой программного продукта.
Вся функциональность, которая связана с бизнес правилами, организацией данных и ядром системы должна быть связана наименьшим образом с пользовательским интерфейсом. Это обеспечит простоту модификации пользовательского интерфейса при изменении других частей системы.
Также при разработке программного интерфейса следует учитывать требования стандартов к оформлению пользовательского интерфейса.
|
|
|
6. Управление ресурсами.
Архитектура системы должна включать план управления ограниченными ресурсами такими как: соединение с БД, потоки, дескрипторы. При разработке драйверов в обязательном порядке необходимо проработать способ управления памятью и способы доступа к устройствам.
В этом разделе необходимо учесть, какие нагрузки на систему могут быть в условиях минимальной загрузки системы, номинальной и экстремальной (максимальной). Все параметры должны быть проанализированы и учтены в соответствующих компонентах системы.
7. Безопасность.
Архитектура всегда должна определять все необходимые меры безопасности для разрабатываемой системы. Зачастую система безопасности может быть вынесена в отдельную подсистему безопасности, разделенную на 2 составляющие:
- будет обеспечивать защиту данных в системе;
- будет обеспечивать безопасность системы с точки зрения несанкционированного доступа.
8. Производительность.
Архитектура системы должна включать оценку производительности системы с точки зрения выполнимости заданных требований к производительной системе. Должен быть проведен четкий анализ реальности достижения заданных показателей в условиях реализации тех или иных решений.
|
|
|
9. Масштабируемость.
Масштабируемость – возможность системы адаптироваться к росту требований. Архитектура должна учитывать, каким образом может быть расширена система или реагировать на рост числа пользовательских серверов, запросов, транзакций, количества записей в БД.
10. Взаимодействие с другими системами (интеграция).
При разработке архитектуры вопросы интеграции с любыми внешними системами должны быть проработаны самым тщательным образом с указание конкретных путей и способов интеграции. Рекомендуется проверять пути интеграции на тестовых примерах.
11. Интернационализация, локализация.
Интернационализация – реализация в программе поддержки региональных стандартов.
Локализация – перевод интерфейса программы на какой-то конкретный язык.
12. Ввод-вывод данных.
При разработке архитектуры следует уделить внимание обработке ошибок, связанных с вводом, выводом и записью данных.
13. Обработка ошибок.
В системе во всех ее компонентах должны быть предусмотрены всевозможные ситуации, которые могут привести к ошибке и должны быть разработаны соответствующие обработчики этих ошибок. Система должна самостоятельно обрабатывать ошибку и устранять ее последствия или выдать корректное сообщение пользователю о возникшей ошибке и способе ее устранения.
14. Отказоустойчивость.
Отказоустойчивость – совокупность свойств системы, повышающая ее надежность путем обнаружения ошибок, восстановления и локализации плохих последствий для системы.
При разработке любой реальной системы для обеспечения отказоустойчивости необходимо предусматривать всевозможные ситуации, которые могут привести к сбою системы и разработать механизмы обработки сбоев.
15. Надежность.
Надежность – способность системы противостоять различным отказам и сбоям.
Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние.
Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя.
Чем меньше отказов и сбоев за какой-то определенный интервал времени, то система считается надежнее.
Чем дальше, тем тяжелее будет найти ошибку.
Чем сложнее система, тем больше вероятность отказов и сбоев.
16. Возможности реализации разрабатываемой архитектуры.
При разработке архитектуры должен быть проведен анализ, насколько реально разработать систему с заданными требованиями производительности способную работать на заданных аппаратных средствах.
17. Избыточная функциональность.
При разработке системы не следует добавлять ту функциональность, которая не является необходимой (которая может потребоваться только гипотетически), так как новая функциональность приводит к снижению надежности всей системы в целом. Важно стремится разработать всю необходимую функциональность максимально простыми методами.
18. Принятие решение о приобретении готовых компонент ПО.
Перед принятием решения об использовании компонент сторонних разработчиков необходимо обязательно провести всесторонний анализ этих компонент и уделить внимание следующим вопросам:
- наличие исходного кода компонент;
- правило лицензирования;
- совместимость этих компонент с предполагаемой средой разработки;
- проверить, чтобы версии компонент были совместимы между собой по принципу поддержки старой функциональности новыми версиями;
- наличие квалифицированной технической поддержки со стороны разработчиков этих компонент.
19. Стратегия изменений.
Архитектура должна четко описывать стратегию изменения путей улучшения и развития разрабатываемой системы. На уровне архитектуры необходимо предусмотреть возможности периодического обновления системы с использованием различных update и service pack.
Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры:
1. Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование.
2. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами.
3. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы.
4. Приведено ли описание самых важных классов и их обоснование.
5. Приведено ли описание организации БД.
6. Определены ли все бизнес правила.
7. Описано ли их влияние на систему.
8. Описана ли стратегия проектирования пользовательского интерфейса.
9. Сделан ли пользовательский интерфейс модульным, чтобы его изменения не влияли на оставшуюся часть системы.
10. Приведено ли описание стратегии ввода-вывода данных.
11. Проведен ли анализ производительности системы, которая будет реализовываться с использованием данной архитектуры.
12. Проведен ли анализ надежности проектируемой системы.
13. Проведен ли анализ вопросов масштабируемости и расширяемости системы.
Рекомендации по разработке исходного кода
Данные рекомендации выработаны с целью устранения недостатков в исходном коде программ на этапе их разработки. Следование данным рекомендациям позволяет минимизировать потенциальные проблемы в исходном коде, которые могут приводить к ошибкам и не возможности продолжать развитие исходного кода. Следование данным рекомендациям существенно снижает необходимость рефакторинга исходного кода.
· Следовать принятым правилам именования классов, объектов, методов и переменных
· Размещать комментарии в исходном коде;
· Избегать повторяемости кода;
· Реализация метода должна занимать не более 2-х экранов;
· Избегать слишком большой вложенности циклов. Стремиться сократить размеры циклов.
· Класс должен иметь хорошую связность (свойства и методы класса должны описывать только 1 объект);
· Интерфейс класса должен формировать согласованную абстракцию
· Метод должен принимать разумно минимальное число параметров
· Отдельные части класса должны изменяться совместно с другими частями класса
· Разрабатывать классы таким образом, чтобы при модификации программы не было необходимости проводить реорганизацию классов или же такая реорганизация классов сводилась к минимуму
· Разрабатывать классы таким образом, чтобы исключить необходимость параллельно изменять несколько иерархий наследования
· Разрабатывать универсальные блоки case т.е. сделать реализацию блока case таким образом, чтобы ее можно было вызывать в нужном количестве мест в программе
· Родственные элементы данных, используемые вместе, должны быть организованы в классы. Если вы неоднократно используете один и тот же набор элементов данных, то целе-сообразно объединить эти данные и выполняемые над ними операции в отдельный класс
· Метод должен использовать в основном элементы собственного класса.
· Для описания сущности реального мира лучше использовать какой-либо класс, чем перегружать какой-либо существующий тип данных
· Стараться делать универсальные классы. По возможности избавляться от классов с очень ограниченной функциональностью
· Данные, передаваемые в метод только для того, чтобы он их передал другому методу, называются «бродячими». При возникновении таких ситуаций постарайтесь изменить архитектуру классов и методов, чтобы от них избавиться от таких данных
· Избавляться от объектов-посредников. Если роль класса сводится к перенаправлению вызовов методов в другие классы, то лучше всего такой объект-посредник устранить и выполнять вызовы других классов непосредственно;
· Один класс «слишком много знает» о другом классе. В этой ситуации необходимо сделать инкапсуляцию более строгой, чтобы обеспечить минимальное знание наследника о своем родителе
· Делать так, чтобы данные-члены были закрытыми. Это стирает грань между интерфейсом и реализацией и неизбежно нарушает инкапсуляцию, что ограничивает гибкость программы
· Устранять ситуацию, когда подкласс использует только малую долю методов своих предков. Такая ситуация возникает тогда, когда новый класс создается только лишь для наследования нескольких методов из базового класса, а не для того, чтобы описать какую-либо новую сущность. Для того, чтобы этого избежать, необходимо преобразовать базовый класс, таким образом, чтобы он давал доступ новому классу только к необходимым ему методам;
· Стараться избегать использования в коде глобальных переменных. Глобальными должны быть только те переменные, которые в действительности используются всей программной. Все остальные переменные должны быть либо локальными, либо должны стать свойствами каких-либо объектов
· Программа должна содержать только тот код, который реально используется, но при разработке системы целесообразно предусмотреть места, куда в будущем может быть добавлен новый исходный код.
Дата добавления: 2018-05-12; просмотров: 416; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!