Вопрос 2. Процесс разработки.
Основные принципы
Удачный проект который удовлетворил заказчика уложился во времени и в финансовые рамки, легко изменяется и адаптируется
Архитектура Она должна обладать концептуальным единством и целостностью
Как отличить хорошую архитектуру от плохой Хорошей присущи свойства
Многоуровневая система абстракций На каждом уровне абстракции компоненты сотрудничают имеют четкий интерфейс с внешним миром и имеют хорошо продуманные средства нижнего уровня
На каждом уровне интерфейс абстракций строго отграничен от реализации. Реализацию можно менять не затрагивая интерфейс Внутренне абстракции должны соответствовать ожиданиям внешних клиентов
Архитектура проста, нет лишнего общее поведение достигается общими абстракциями и механизмами
Стратегическое решение важно на высоком уровне системы. Это механизмы обнаружения и обработки ошибок, парадигмы интерфейса пользователя, политика управления памятью устойчивость объектов, синхронизация процессов в реальном масштабе времени
Тактическое решение - имеет локальное архитектурное значение Оно связано с деталями интерфейса и реализацией. Это - протокол класса, сигнатура метода, выбор алгоритма
Должен быть хороший баланс стратегии и тактики
Цикл итеративного развития - Если отсутствует жизненный цикл разработки - то опасность анархии налицо Если строго соблюдать правила разработки - то имеется диктатура, в которой инициатива наказуема Свободное падение и бюрократия должна найти компромисс
Итеративное развитие, когда уже созданная архитектура вновь и вновь подвергается анализу и проектированию Стратегия и тактика развивается, приближаясь к требованиям пользователя Рациональный процесс проектирования.
По словам Хемпри существует пять уровнен зрелости проектирования
Начальный (Процесс разработки хаотичен идет процесс налаживания управления проектом)
Воспроизводимый (Организация в разумной степени управляет своими планами и обстоятельствами)
Определенный (Процесс разработки определен понятен и применяется на практике Выбрана команда, оформляется выбранная практика разработки в виде инструментальной среды)
Управляемый (Организация выработала количественные показатели процесса Сбор данных и налаживание механизмов обратной связи, позволяющих данным влиять на процесс)
Оптимальный (Процесс отлажен, выдает результаты высокого качества) Микропроцесс проектирования
На рис 6-1 микропроцесс состоит из следующих видов деятельности
Выявление классов и объектов на данном уровне абстракции
Выяснение семантики этих классов и объектов
Выявление связей между этими классами и объектами
Спецификация интерфейса и реализация этих классов и объектов
Микропроцесс приводится в движение потоком сценариев и архитектурных продуктов, порожденных в макропроцессе Это труд отдельного разработчика или небольшого коллектива
Вопрос 3. Структура сложных систем. Существует пять признаков сложных систем
1. сложные системы являются иерархическими и состоят из взаимозависимых подсистем, которые можно разбить на подсистемы, и т.д. до самого низкого уровня
простейшие элементы системы определяются самим разработчиком и произвольны на каждом уровне иерархии
внутри компонентная связь элементов системы обычно сильнее, чем связь между компонентами «Низкочастотная» внешняя и «высокочастотная» внутренняя связь компонент
иерархия системы обычно состоит из небольшого количества типов подсистем, по-разному скомбинированных и организованных
любая сложная система является результатом развития работавшей более простой системы
Сложная система спроектированная с «нуля» никогда не работает. Надо начинать с работающей
Все сложные системы можно представить канонической формой структура классов и объектов является зависимыми Каждый элемент структуры объектов представляет набор объектов более низкого уровня Объекты одного уровня имеют четкие связи по компонентам структуры. Каждый элемент структуры объектов представляет специфический экземпляр определенного класса Поэтому объектов больше чем классов Структуры классов вмещают общие свойства их экземпляров
Архитектура системы - это структура системы по классам и объектам Для борьбы со сложностью системы нацелен объектный подход к ее проектированию.
Абстракции проектирования
Разбивая поступление информации по нескольким каналам в виде последовательности отдельных порций можно "прорвать" информационный "затор" - это абстракция
Будучи не в состоянии полностью воссоздать сложный объект нужно игнорировать не важные детали и иметь дело с обобщенной, идеализируемой моделью мира
Методы проектирования ПС (программных систем) - представляют собой последовательный процесс создания моделей, которые описывают различные стороны ПО
Методология - это совокупность методов, применяемых в жизненном цикле разработки ПО с одним общим философским подходом
Методы важны, т.к. они упорядочивают процесс создания ПС. доступны для всей группы разработчиков, в процессе разработки позволяют оценить степень продвижения и риск
Роль иерархии
Иерархия типа is a делится на два типа иерархий
структура классов
структура объектов.
1-ая "быть частью"
2-ая "иметь свойства
Объекты взаимодействуют с помощью механизмов воздействия, и схема взаимодействия определяет поведение системы Система классов определяет общность структур и поведения внутри системы