Что такое объектно ориентированный дизайн
Объектно-ориентированный дизайн
Объе́ктно-ориенти́рованное проектирование (ООП) — это часть объектно-ориентированной методологии, которая предоставляет возможность программистам оперировать понятием «объект», нежели понятием «процедура» при разработке своего кода. Объекты содержат инкапсулированные данные и процедуры, сгруппированные вместе, отображая т.о. сущность объекта. «Интерфейс объекта», описывает взаимодействие с объектом, то, как он определен. Программа, полученная при реализации объектно-ориентированного исходного кода, описывает взаимодействие этих объектов.
Содержание
Объектно-ориентированный дизайн
Дисциплина, описывающая способы (варианты) задания (определения) объектов и их взаимодействие для решения проблемы, которая определена и описана в ходе объектно-ориентированного анализа.
Примечания
См. также
Ссылки
Полезное
Смотреть что такое «Объектно-ориентированный дизайн» в других словарях:
Объектно-ориентированный подход — Объектно ориентированное программирование (ООП) парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием прототипов). Класс это тип, описывающий… … Википедия
Объектно-ориентированное проектирование — (ООП) это часть объектно ориентированной методологии, которая предоставляет возможность программистам оперировать понятием «объект», нежели понятием «процедура» при разработке своего кода. Объекты содержат инкапсулированные данные и… … Википедия
Объектно-ориентированное программирование — Эта статья во многом или полностью опирается на неавторитетные источники. Информация из таких источников не соответствует требованию проверяемости представленной информации, и такие ссылки не показывают значимость темы статьи. Статью можно… … Википедия
Класс (объектно-ориентированное программирование) — Класс, наряду с понятием «объект», является важным понятием объектно ориентированного подхода в программировании (хотя существуют и бесклассовые объектно ориентированные языки, например, Прототипное программирование). Под классом подразумевается… … Википедия
ООД — ориентировочная основа действий ООД общественно опасное деяние уголовное право ООД областной онкологический диспансер мед. ООД отряд обеспечения движения … Словарь сокращений и аббревиатур
ООАП — Объектно ориентированное программирование (ООП) парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием прототипов). Класс это тип, описывающий… … Википедия
Python — У этого термина существуют и другие значения, см. Python (значения). Python Класс языка: му … Википедия
Джобс, Стив — Стив Джобс Steve Jobs … Википедия
Пайтон — Python Класс языка: функциональный, объектно ориентированный, императивный, аспектно ориентированный Тип исполнения: интерпретация байт кода, компиляция в MSIL, компиляция в байт код Java Появился в: 1990 г … Википедия
Объектно-ориентированный дизайн… в CSS
Вопросы к БЭМ
Начать я решил с того, что мне было не совсем понятно в БЭМ:
1. Многие считают, что техника априори верна всегда и везде, поскольку за ней стоит Яндекс. Почему то, что подходит крупной компании с гигантским штатом и небольшим количеством однотипных проектов должно так же хорошо работать, скажем, в небольшой команде, которая осуществляет заказную разработку самых разнообразных сайтов? Возьмем в качестве примера подходы из jQueryUI, KendoUI и т.п. Они растиражированы на сотни тысяч проектов и в этом плане имеют гораздо большую зрелость. Причем сам Яндекс на сайте bem.info ясно обрисовывает условия применения, но многие даже не доходят до этого параграфа, ограничиваясь первыми строками и успокоительным: «это же придумали в Яндексе».
2. Почему считается что принудительная контекстная независимость — это хорошо и тут же вводится эта самая зависимость элемента от блока, если пользоваться терминологией БЭМ? Предположим, я хочу, чтобы все кнопки на сайте у меня выглядели не так, как это хочется автору блока, а в соответствии с единым, продуманным стилем. Если это некоторая стандартная кнопка, то в одном и том же контексте она должна выглядеть одинаково. В другом, как раз, может быть разной. В сайдбаре — поменьше, в теле страницы — побольше, на большом экране — текстом и иконкой, на смартфоне — иконкой. Но если это стандартная кнопка в сайдбаре, то в таких ситуация она должна и выглядеть должна стандартно. Здесь под стандартом подразумевается удачное решение, которое нашли дизайнер вместе с UX-специалистом, а не верстальщик отдельно взятого блока.
Чтобы проиллюстрировать свои сомнения я взял первые попавшиеся формы ввода с сайта Яндекса: создание почтового ящика, регистрация и фидбека.
Не знаю, кто и что увидел на этих картинках, а я вижу полную анархию. Дизайном этих форм занимались, очевидно, не те, кто должен заниматься, а лепили авторы блоков так, как каждый из них это видит. Почему единый стандарт на то, как должны выглядеть поля ввода и кнопки в формах — это плохо?
Яндекс на сайте bem.info пишет: «Каждый новый проект или элемент интерфейса не должны писаться с нуля. Если где-то внутри компании уже выполнялась похожая задача, нужно максимально повторно использовать полученный в результате код. У кода не должно быть контекстной зависимости, его нужно уметь легко переносить в другое место». Давайте посмотрим на пример такого реюзинга.
Два блока логина на одной странице. Если бы это делал я, неправильным способом, то написал бы модуль единожды, а потом, в зависимости от контекста, немного поправил стили, чтобы в сайдбаре он выглядел уменьшенным. Здесь, же я вижу два разных модуля и двух разных авторов. Один считает, что надо «вспомнить пароль», другой предлагает его «напомнить». Первый считает, что линк «зарегистрироваться» не является частью этого функционального блока и вынес его за визуальный контур, второй с ним не согласен. Они расходятся даже в том, как озаглавить этот блок. Автор попап-версии резонного полагает, что пользователь должен осуществить «вход», минималист же хочет, чтобы посетитель сделал «маркет». Они даже реализовывали по-разному, один — табличной версткой, другой — слоями. Повторного использования — ноль. Зато оба использовали БЭМ.
3. Почему отсутствие лаконичности в названиях классов считать преимуществом? И как может нравится это —
? В последней верстке, которую я лишил БЭМ объем страницы упал в два раза. Я в данном случае не говорю, что это достаточная причина отказаться от БЭМ и смысл появления этого оверхеда понятен. Просто констатирую, что за такой раздутый синтаксис с низкой энтропией я бы снял балл.
4. Почему нужно отказывать от многих возможностей CSS? Будь то селекторы с использованием идентификаторов, контекстов и т.п.
Первая реакция на БЭМ была такова, что я расшифровал эту аббревиатуру как Бардак Эвентуальный Метастазирующий. Но все эти недовольства попахивали просто очередным частным мнением, которое не очень убеждало меня самого, что уж говорить об убедительности для других. И тогда я призвал себя осмыслить саму концепцию классов CSS в архитектурном ключе, как мне привычней.
Design by contract
, станет ,
Интерфейс tabbed берет на себя обязательства предоставить доступ к контейнерам _tabs и _pages. Это значит, что если у вас на руках есть объект, реализующий этот контракт, то вы вправе вызвать методы getTabs и getPages, чтобы получить доступ к соответствующим контейнерам. Про последние мы знаем, что они реализуют контракт container, а значит имеют на руках все необходимые функции для работы с коллекцией закладок, в том числе обрабатывать first/last/odd/even и прочие типовые стили для списков. То есть изобретать заново функцию для удаления таба будет не нужно.
К контейнерам добавился еще один контракт — selectable. Он может брать на себя обязательства по предоставлению функции для определения текущего выбранного элемента, менять выбранный элемент и т.п. Например, функции:
И опять же, эти функции будут одинаково хорошо работать для списков, выпадающих список, панелбаров, слайдеров и всех прочих типов виджетов, где предполагается наличие выбранного элемента, а не только для табов. Когда вы находите и исправляете ошибку в этих функциях, то вы исправляете ее везде.
Если вы, скажем, захотите добавить возможность перетаскивать табы drag’n’drop-ом, то просто добавите контракты drag/drop, что позволит сразу задействовать все те типовые функции, которые были для этой цели уже подготовлены.
Но стоит только написать в БЭМ-стиле tabbed_tabs__item, как краски сразу потускнеют. Ведь весь тот код, который всегда хорошо работал с селектором «.item», для самых разных виджетов, перестал работать. У вас были скины, с самыми различными отображениями табов, но они теперь тоже не работают. Мне могут возразить, что имеют место специальные расширения для того же jQuery, которые помогут разобраться со всем этим синтаксическим мусором. Но мне пока не понятно, зачем создавать проблемы, а потом их решать.
Стандарты
Естественно, все эти «контракты», как и интерфейсы в объектно-ориентированном дизайне, должны быть систематизированы и разложены по полочкам. В программировании это зачастую решается за счет использования пространств имен. Но делается это один раз, а потом используется сколь угодно долго и на любом количестве проектов.
На базе таких контрактов гораздо проще ввести внутренние стандарты и реализовать валидаторы, которые будут держать качество кода на постоянном контроле. Это позволит всем участникам процесса, в том числе и вновь подключившимся, мыслить в одном ключе. В начале — императивно, а потом уже по привычке. Ведь как в объектно-ориентированном дизайне контракты не вводятся просто так, а являются следствием продуманного акта, так и в CSS имена классов не должны возникать спонтанно, необдуманно. Ведь БЭМ хоть и пытается контролировать структурный аспект разработки, но совершенно упускает системный. Кто-то табы назовет tabs, кто-то tab-control, иной tab-widget. Например, форма логина у Яндекса из примера в начале статьи называется «b-domik». Это же так мило, назвать ее не login, signup или еще как-нибудь осмысленно, а «би-домик». Вспоминается старое институтское «пи с домиком и пи с душечкой». Верх креатива, но ад для валидации и рефакторинга. Если вы внезапно захотите найти все формы логина и добавить туда новые опции (скажем, идентификацию через какой-нибудь новый социальный сервис), то вам предстоит отловить этот би-домик, узнать, что в почте яндекса он уже зовется b-mail-domik, ссылка «Войти в почту» c титульной страницы уже содержит форму логина с классом b-popupa__wrap. А сколько вам еще подготовлено «открытий чудных»…
Мне кажется, что верстальщики вообще не должны выдумывать имена классов. Обеспечение интерфейсов между HTML и JS должно осуществляться проектировщиками. Они разрабатывают контракты, систематизируют и доносят эту информацию до тружеников HTML/CSS. Это дает и масштабируемость JS-кода, и реюзинг, и рефакторинг, и валидацию в соответствии с корпоративными стандартами, а значит — качество. Мне кажется этого вполне достаточно для того, чтобы был повод поразмышлять.
CSS-препроцессоры
Под конец замечу, что такие стили достаточно легко и органично описываются в духе LESS/SASS/Stylus-препроцессоров:
OOAD — Объектно-ориентированный дизайн
После фазы анализа концептуальная модель в дальнейшем превращается в объектно-ориентированную модель с использованием объектно-ориентированного проектирования (OOD). В OOD технологически независимые концепции в модели анализа отображаются на реализующие классы, идентифицируются ограничения и разрабатываются интерфейсы, в результате чего получается модель для области решения. В двух словах, составлено подробное описание, определяющее, как система должна быть построена на конкретных технологиях.
Этапы объектно-ориентированного проектирования могут быть определены как —
Системный дизайн
Объектно-ориентированное проектирование системы включает в себя определение контекста системы с последующим проектированием архитектуры системы.
Архитектура системы — Архитектура системы разработана на основе контекста системы в соответствии с принципами архитектурного проектирования, а также с учетом предметной области. Как правило, система разбивается на слои, и каждый слой разлагается для формирования подсистем.
Архитектура системы — Архитектура системы разработана на основе контекста системы в соответствии с принципами архитектурного проектирования, а также с учетом предметной области. Как правило, система разбивается на слои, и каждый слой разлагается для формирования подсистем.
Объектно-ориентированная декомпозиция
Разложение означает деление большой сложной системы на иерархию более мелких компонентов с меньшей сложностью на принципах «разделяй и властвуй». Каждый основной компонент системы называется подсистемой. Объектно-ориентированная декомпозиция идентифицирует отдельные автономные объекты в системе и связь между этими объектами.
Отдельные компоненты имеют меньшую сложность и поэтому более понятны и управляемы.
Это позволяет разделение рабочей силы, имеющей специализированные навыки.
Это позволяет заменять или модифицировать подсистемы, не затрагивая другие подсистемы.
Отдельные компоненты имеют меньшую сложность и поэтому более понятны и управляемы.
Это позволяет разделение рабочей силы, имеющей специализированные навыки.
Это позволяет заменять или модифицировать подсистемы, не затрагивая другие подсистемы.
Выявление параллелизма
Параллелизм позволяет нескольким объектам получать события одновременно и одновременно выполнять несколько действий. Параллелизм идентифицирован и представлен в динамической модели.
Чтобы включить параллелизм, каждому параллельному элементу назначается отдельный поток управления. Если параллелизм находится на уровне объекта, тогда двум параллельным объектам назначаются два разных потока управления. Если две операции одного объекта являются параллельными по своей природе, то этот объект распределяется между различными потоками.
Параллелизм связан с проблемами целостности данных, взаимоблокировок и голодания. Таким образом, четкая стратегия должна быть разработана всякий раз, когда требуется параллелизм. Кроме того, параллелизм должен быть идентифицирован на самой стадии проектирования и не может быть оставлен на стадии реализации.
Идентификация шаблонов
При разработке приложений принимаются некоторые общепринятые решения для некоторых категорий проблем. Это шаблоны дизайна. Шаблон может быть определен как документированный набор строительных блоков, которые могут использоваться в определенных типах задач разработки приложений.
Некоторые часто используемые шаблоны дизайна —
Управление событиями
Во время проектирования системы события, которые могут происходить в объектах системы, должны быть идентифицированы и соответствующим образом обработаны.
Событие — это спецификация значимого события, имеющего местоположение во времени и пространстве.
Существует четыре типа событий, которые можно смоделировать, а именно:
Сигнальное событие — именованный объект, брошенный одним объектом и захваченный другим объектом.
Событие вызова — синхронное событие, представляющее отправку операции.
Событие времени — событие, представляющее течение времени.
Событие изменения — событие, представляющее изменение состояния.
Сигнальное событие — именованный объект, брошенный одним объектом и захваченный другим объектом.
Событие вызова — синхронное событие, представляющее отправку операции.
Событие времени — событие, представляющее течение времени.
Событие изменения — событие, представляющее изменение состояния.
Обработка граничных условий
Этап проектирования системы должен учитывать инициализацию и завершение системы в целом, а также каждой подсистемы. Различные аспекты, которые задокументированы, следующие:
Запуск системы, т. Е. Переход системы из неинициализированного состояния в устойчивое состояние.
Завершение работы системы, т. Е. Закрытие всех запущенных потоков, очистка ресурсов и отправка сообщений.
Начальная конфигурация системы и реконфигурация системы при необходимости.
Предвидение сбоев или нежелательного завершения работы системы.
Запуск системы, т. Е. Переход системы из неинициализированного состояния в устойчивое состояние.
Завершение работы системы, т. Е. Закрытие всех запущенных потоков, очистка ресурсов и отправка сообщений.
Начальная конфигурация системы и реконфигурация системы при необходимости.
Предвидение сбоев или нежелательного завершения работы системы.
Граничные условия моделируются с использованием граничных вариантов использования.
Объектный дизайн
После того, как иерархия подсистем была разработана, объекты в системе идентифицируются и их детали проектируются. Здесь дизайнер подробно описывает стратегию, выбранную при проектировании системы. Акцент смещается с концепций предметной области на компьютерные концепции. Объекты, идентифицированные во время анализа, вытесняются для реализации с целью минимизации времени выполнения, потребления памяти и общих затрат.
Проектирование объекта включает в себя следующие этапы —
Идентификация объекта
Первым этапом проектирования объекта является идентификация объекта. Объекты, идентифицированные на этапах объектно-ориентированного анализа, группируются в классы и уточняются таким образом, чтобы они подходили для фактической реализации.
Функции этого этапа —
Выявление и уточнение классов в каждой подсистеме или пакете
Определение связей и ассоциаций между классами
Разработка иерархических ассоциаций между классами, т. Е. Обобщение / специализация и наследования
Выявление и уточнение классов в каждой подсистеме или пакете
Определение связей и ассоциаций между классами
Разработка иерархических ассоциаций между классами, т. Е. Обобщение / специализация и наследования
Представление объекта
Как только классы идентифицированы, они должны быть представлены с использованием методов объектного моделирования. Этот этап в основном включает в себя построение UML-диаграмм.
Есть два типа дизайнерских моделей, которые должны быть произведены —
Статические модели — Для описания статической структуры системы используются диаграммы классов и диаграммы объектов.
Динамические модели — чтобы описать динамическую структуру системы и показать взаимодействие между классами, используя диаграммы взаимодействия и диаграммы состояний.
Статические модели — Для описания статической структуры системы используются диаграммы классов и диаграммы объектов.
Динамические модели — чтобы описать динамическую структуру системы и показать взаимодействие между классами, используя диаграммы взаимодействия и диаграммы состояний.
Классификация операций
На этом этапе операции, выполняемые над объектами, определяются путем объединения трех моделей, разработанных на этапе OOA, а именно объектной модели, динамической модели и функциональной модели. Операция определяет, что должно быть сделано, а не как это должно быть сделано.
В отношении операций выполняются следующие задачи:
Разработана схема перехода состояний каждого объекта в системе.
Операции определены для событий, полученных объектами.
Идентифицированы случаи, когда одно событие вызывает другие события в том же или в другом объекте.
Подоперации в действиях определены.
Основные действия расширены до диаграмм потоков данных.
Разработана схема перехода состояний каждого объекта в системе.
Операции определены для событий, полученных объектами.
Идентифицированы случаи, когда одно событие вызывает другие события в том же или в другом объекте.
Подоперации в действиях определены.
Основные действия расширены до диаграмм потоков данных.
Разработка алгоритма
Операции в объектах определяются с помощью алгоритмов. Алгоритм — это пошаговая процедура, которая решает проблему, изложенную в операции. Алгоритмы сосредоточены на том, как это должно быть сделано.
Может быть более одного алгоритма, соответствующего данной операции. Как только альтернативные алгоритмы идентифицированы, оптимальный алгоритм выбирается для данной проблемной области. Метрики для выбора оптимального алгоритма —
Сложность вычислений — Сложность определяет эффективность алгоритма с точки зрения времени вычислений и требований к памяти.
Гибкость — Гибкость определяет, может ли выбранный алгоритм быть реализован надлежащим образом, без потери соответствия в различных средах.
Понятность — это определяет, является ли выбранный алгоритм простым для понимания и реализации.
Сложность вычислений — Сложность определяет эффективность алгоритма с точки зрения времени вычислений и требований к памяти.
Гибкость — Гибкость определяет, может ли выбранный алгоритм быть реализован надлежащим образом, без потери соответствия в различных средах.
Понятность — это определяет, является ли выбранный алгоритм простым для понимания и реализации.
Дизайн Отношений
Стратегия реализации отношений должна быть записана на этапе проектирования объекта. Основные взаимосвязи, которые адресованы, включают ассоциации, агрегации и наследования.
Дизайнер должен сделать следующее относительно ассоциаций —
Определите, является ли ассоциация однонаправленной или двунаправленной.
Проанализируйте пути ассоциаций и обновите их при необходимости.
Реализуйте ассоциации как отдельный объект, в случае отношений «многие ко многим»; или как ссылка на другой объект в случае отношений один-к-одному или один-ко-многим.
Определите, является ли ассоциация однонаправленной или двунаправленной.
Проанализируйте пути ассоциаций и обновите их при необходимости.
Реализуйте ассоциации как отдельный объект, в случае отношений «многие ко многим»; или как ссылка на другой объект в случае отношений один-к-одному или один-ко-многим.
Что касается наследования, проектировщик должен сделать следующее —
Настройте классы и их ассоциации.
Определите абстрактные классы.
Сделайте так, чтобы при необходимости обменивались поведением.
Настройте классы и их ассоциации.
Определите абстрактные классы.
Сделайте так, чтобы при необходимости обменивались поведением.
Осуществление контроля
Проектировщик объекта может включить уточнения в стратегию модели диаграммы состояний. При проектировании системы разработана базовая стратегия реализации динамической модели. Во время проектирования объекта эта стратегия удачно украшена для соответствующей реализации.
Подходы для реализации динамической модели:
Представлять состояние как местоположение в программе. Это традиционный подход, основанный на процедурах, при котором местоположение элемента управления определяет состояние программы. Конечный автомат может быть реализован как программа. Переход формирует входной оператор, основной путь управления формирует последовательность инструкций, ветви формируют условия, а обратные пути образуют циклы или итерации.
Механизм конечного автомата — этот подход напрямую представляет конечный автомат через класс конечного автомата. Этот класс выполняет конечный автомат посредством набора переходов и действий, предоставляемых приложением.
Управление как параллельные задачи — при таком подходе объект реализуется как задача на языке программирования или в операционной системе. Здесь событие реализовано как межзадачный вызов. Сохраняет присущий параллелизм реальных объектов.
Представлять состояние как местоположение в программе. Это традиционный подход, основанный на процедурах, при котором местоположение элемента управления определяет состояние программы. Конечный автомат может быть реализован как программа. Переход формирует входной оператор, основной путь управления формирует последовательность инструкций, ветви формируют условия, а обратные пути образуют циклы или итерации.
Механизм конечного автомата — этот подход напрямую представляет конечный автомат через класс конечного автомата. Этот класс выполняет конечный автомат посредством набора переходов и действий, предоставляемых приложением.
Управление как параллельные задачи — при таком подходе объект реализуется как задача на языке программирования или в операционной системе. Здесь событие реализовано как межзадачный вызов. Сохраняет присущий параллелизм реальных объектов.
Классы упаковки
В любом крупном проекте важно тщательное разбиение реализации на модули или пакеты. При проектировании объектов классы и объекты группируются в пакеты, что позволяет нескольким группам совместно работать над проектом.
Различные аспекты упаковки —
Скрытие внутренней информации от внешнего вида. Это позволяет рассматривать класс как «черный ящик» и позволяет изменять реализацию класса, не требуя, чтобы какие-либо клиенты этого класса модифицировали код.
Классы в модуле должны представлять похожие вещи или компоненты в одном и том же составном объекте.
Тесно связанные классы должны быть в одном модуле.
Несвязанные или слабо связанные классы следует размещать в отдельных модулях.
Модули должны обладать хорошей связностью, т. Е. Высоким уровнем взаимодействия между их компонентами.
Модуль должен иметь слабую связь с другими модулями, т. Е. Взаимодействие или взаимозависимость между модулями должны быть минимальными.
Скрытие внутренней информации от внешнего вида. Это позволяет рассматривать класс как «черный ящик» и позволяет изменять реализацию класса, не требуя, чтобы какие-либо клиенты этого класса модифицировали код.
Классы в модуле должны представлять похожие вещи или компоненты в одном и том же составном объекте.
Тесно связанные классы должны быть в одном модуле.
Несвязанные или слабо связанные классы следует размещать в отдельных модулях.
Модули должны обладать хорошей связностью, т. Е. Высоким уровнем взаимодействия между их компонентами.
Модуль должен иметь слабую связь с другими модулями, т. Е. Взаимодействие или взаимозависимость между модулями должны быть минимальными.
Оптимизация дизайна
Модель анализа собирает логическую информацию о системе, в то время как модель проекта добавляет детали для поддержки эффективного доступа к информации. Перед реализацией проекта его следует оптимизировать, чтобы сделать реализацию более эффективной. Целью оптимизации является минимизация затрат с точки зрения времени, пространства и других показателей.
Однако оптимизация дизайна не должна быть чрезмерной, так как простота реализации, ремонтопригодность и расширяемость также являются важными проблемами. Часто видно, что идеально оптимизированный дизайн более эффективен, но менее читабелен и пригоден для повторного использования. Таким образом, дизайнер должен найти баланс между ними.
Различные вещи, которые можно сделать для оптимизации дизайна:
Добавление избыточных ассоциаций
Во время оптимизации проекта проверяется, может ли создание новых ассоциаций снизить затраты на доступ. Хотя эти избыточные ассоциации могут не добавлять никакой информации, они могут повысить эффективность общей модели.
Исключение неиспользуемых ассоциаций
Наличие слишком большого количества ассоциаций может сделать систему не поддающейся расшифровке и, следовательно, снизить общую эффективность системы. Таким образом, во время оптимизации все неиспользуемые ассоциации удаляются.
Оптимизация алгоритмов
В объектно-ориентированных системах оптимизация структуры данных и алгоритмов осуществляется на основе сотрудничества. Как только проект класса будет создан, операции и алгоритмы должны быть оптимизированы.
Оптимизация алгоритмов достигается путем —
Сохранение и хранение производных атрибутов
Производные атрибуты — это те атрибуты, значения которых вычисляются как функция других атрибутов (базовых атрибутов). Пересчет значений производных атрибутов каждый раз, когда они необходимы, является трудоемкой процедурой. Чтобы избежать этого, значения могут быть вычислены и сохранены в их вычисленных формах.
Однако это может привести к аномалиям обновления, то есть изменению значений базовых атрибутов без соответствующего изменения значений производных атрибутов. Чтобы избежать этого, предпринимаются следующие шаги:
При каждом обновлении значения базового атрибута производный атрибут также пересчитывается.
Все производные атрибуты пересчитываются и обновляются периодически в группе, а не после каждого обновления.
При каждом обновлении значения базового атрибута производный атрибут также пересчитывается.
Все производные атрибуты пересчитываются и обновляются периодически в группе, а не после каждого обновления.
Проектная документация
Документация является неотъемлемой частью любого процесса разработки программного обеспечения, который записывает процедуру создания программного обеспечения. Решения по проектированию должны быть документированы для любой нетривиальной системы программного обеспечения для передачи проекта другим.
Области использования
Хотя вторичный продукт, хорошая документация необходима, особенно в следующих областях —
содержание
Полезная документация должна по существу включать следующее содержание —
Архитектура системы высокого уровня. Диаграммы процессов и диаграммы модулей
Ключевые абстракции и механизмы — Диаграммы классов и диаграммы объектов.
Сценарии, иллюстрирующие поведение основных аспектов — поведенческие диаграммы
Архитектура системы высокого уровня. Диаграммы процессов и диаграммы модулей
Ключевые абстракции и механизмы — Диаграммы классов и диаграммы объектов.
Сценарии, иллюстрирующие поведение основных аспектов — поведенческие диаграммы
Характеристики
Особенности хорошей документации —
Краткий и в то же время однозначный, последовательный и полный
Прослеживается в соответствии с требованиями системы