Новые книги

Практический опыт, описанный в книге, предназначен для освоения во время экономического кризиса, когда цены на новое оборудование – в силу разных причин – завышены, а требования и предпочтения пользователя к функционалу оборудования невысоки и ограничиваются «домашними» задачами. Сегодня почти у каждого активного пользователя скопились запчасти или старые компьютеры, компоненты и детали которых исправны. В то же время покупка нового ПК даже без установленного программного обеспечения (ПО) существенно облегчает кошелек. По сути, вся книга пронизана идеей экономии. При покупке блоков и компонентов ПК в магазинах, вы не только переплачиваете «за бренд» и «в карман посредника», но рискуете впустую потратить время из-за того, что новые компоненты (устройства, платы расширения, приводы, HDD, линейки ОЗУ и др.) не стыкуются со старыми материнскими платами и разъемами, то есть не работают. Чтобы правильно подобрать или заменить отдельные – вышедшие из строя компоненты ПК, или провести частичный апгрейд, необходимо обладать знаниями, которые вполне и всесторонне описаны в данном издании. С другой стороны – разница между новым ПК с тем же функционалом и собранным из деталей двух-трехлетней давности существенна и составляет до 500 %. Таким образом, домашний компьютер для работы становится «золотым». Но не для широкого круга читателей книги, у которых сэкономленные деньги – это заработанные деньги.

То, что сегодня «это наша жизнь» и «рабочие моменты» для специалистов-ремонтников, одновременно является откровением и «секретами» для неподготовленного пользователя персонального компьютера. В книге доступным языком – для непосвященных – описаны приемы восстановления работоспособности ПК, улучшения производительности, рассмотрены часто встречающиеся неисправности ПК и последующие ошибки апргерйда, даются ценные рекомендации практика, которые вы не найдете в Интернете.
Профессиональное движение DevOps зародилось в 2009 году. Его цель — настроить тесные рабочие отношения между разработчиками программного обеспечения и отделами IT-эксплуатации. Внедрение практик DevOps в повседневную жизнь организации позволяет значительно ускорить выполнение запланированных работ, увеличить частоту релизов, одновременно повышая безопасность, надежность и устойчивость производственной среды. Эта книга представляет собой наиболее полное и исчерпывающее руководство по DevOps, написанное ведущими мировыми специалистами.

Определение зависимостей



2.2.3. Определение зависимостей

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

Аналогично тому, как имена возможных классов получались из существительных, встречающихся в предварительной постановке прикладной задачи, имена возможных зависимостей могут быть получены из глаголов или глагольных оборотов, встречающихся в указанном документе. Так обычно описываются: физическое положение (следует_за, является_частью, содержится_в), направленное действие (приводит_в_движение), общение (разговаривает_с), принадлежность (имеет, является_частью) и т.п. Пример выделения явных и неявных глагольных оборотов из предварительной постановки конкретной прикладной задачи рассмотрен в п. 2.3.3.

Затем следует убрать ненужные или неправильные зависимости, используя следующие критерии:

  • зависимости между исключенными классами должны быть исключены, либо переформулированы в терминах оставшихся классов (см. пример в п. 2.3.3);
  • нерелевантные зависимости и зависимости, связанные с реализацией, должны быть исключены (см. пример в п. 2.3.3);
  • действия: зависимость должна описывать структурные свойства прикладной области, а не малосущественные события (см. примеры в п. 2.3.3);
  • тренарные зависимости: большую часть зависимостей между тремя или большим числом классов можно разложить на несколько бинарных зависимостей, используя в случае необходимости квалификаторы (см. примеры в п. 2.3.3); в некоторых (очень редких) случаях такое разложение осуществить не удается; например, тренарная зависимость "Профессор читает курс в аудитории 628" не может быть разложена на бинарные без потери информации;
  • производные зависимости: нужно исключать зависимости, которые можно выразить через другие зависимости, так как они избыточны (см. пример в п. 2.3.3); при исключении избыточных (производных) зависимостей нужно быть особенно осторожным, так как не все дублирующие одна другую зависимости между классами избыточны; в некоторых случаях другие зависимости позволяют установить только существование еще одной производной зависимости, но не позволяют установить кратность этой зависимости; например, в случае, представленном на рисунке 2.36, фирма имеет много служащих и владеет многими компьютерами; каждому служащему предоставлено для персонального использования несколько компьютеров, кроме того, имеются компьютеры общего пользования; кратность зависимости предоставлен_для_использования не может быть выведена из зависимостей служит и владеет; хотя производные зависимости и не добавляют новой информации, они часто бывают удобны; в этих случаях их можно указывать на диаграмме, пометив косой чертой.

Рис. 2.36. Неизбыточные зависимости

Удалив избыточные зависимости, нужно уточнить семантику оставшихся зависимостей следующим образом:

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

Назад | Содержание | Вперед