Обо мне
Ярлыки
- .net (1)
- архитектура (4)
- литература (2)
- маркетинг (4)
- планирование (4)
- проектирование (14)
- собеседование (4)
- требования (8)
- триз (2)
- управление проектами (12)
- Фаулер (2)
- функциональный анализ (13)
- халтура (1)
- эргономика (5)
- c# (1)
- concept (2)
- estimate (5)
- ITGM (1)
- singularity (1)
- SPM Club (2)
- usability (5)
- use-case (2)
воскресенье, 30 октября 2011 г.
понедельник, 24 октября 2011 г.
Задача про датчики: проектирование классов. Часть 2
Продолжение серии статей, посвящённой проектированию системы для метеостанции. Предыдущие статьи смотрите здесь:
Каждая техническая система имеет своё назначение: авторучка – чтобы писать, автомобиль – чтобы передвигаться. Классы в этом правиле не исключение. Каждый класс тоже должен иметь какие-то свои, присущие ему, обязанности.
В предыдущей статье я предложил условно разделять классы на 2 категории:
- классы-сервисы:
- классы-данные.
Классы-сервисы предназначены для выполнения каких-то особых, специфичных задач. Синонимами понятия класс-сервис являются функциональный модуль или функциональная подсистема.
Классы-данные предназначены для временного или постоянного хранения групп данных, а также – для передачи этих данных от сервиса к сервису. Можно сказать, что классы-сервисы – это обработчики, а классы-данные – это коммуникации между этими обработчиками. У "железячников" есть хороший термин – шина данных. Так вот, проектирование классов-данных сродни прокладке шины данных, соединяющей одни функциональный подсистемы с другими.
Чтобы спроектировать классы-данные, нужно провести анализ потоков данных. Нужно понять, как отдельные функции, выполняемые в рамках процесса, связаны друг с другом по данным. Одним из наглядных инструментов для такого анализа является N-square диаграмма.
понедельник, 17 октября 2011 г.
Задача про датчики: проектирование классов. Часть 1
Бертран Мейер, один из идеологов объектно-ориентированного подхода, в своей книге "Объектно-ориентированное конструирование программных систем" пишет:
"В формальных и неформальных обсуждениях архитектуры проекта часто задаётся вопрос о роли некоторого класса. И часто можно слышать ответ: "Этот класс печатает результаты" или "Класс разбирает вход" – варианты общего ответа "Этот класс делает...".
Такой ответ обычно указывает на изъяны в проекте. Класс не должен делать одну вещь, он должен предлагать несколько служб в виде компонентов над объектами некоторого типа. Если же он выполняет одну работу, то, скорее всего, имеет место "Большое Заблуждение".
Вполне вероятно, что ошибка не в самом классе, а в способе его описания – использовании операционной фразеологии. Но всё-таки в этой ситуации лучше провести проверку класса".
Мейер, Бертран. Объектно-ориентированное конструирование программных систем / Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2005. – стр. 717.
Если подытожить, то Мейер делает два утверждения:
- Класс должен отвечать за выполнение нескольких функций.
- О классе не нужно думать, как о чём-то, выполняющем какие-то обязанности.
Если с первым утверждением можно согласиться, а можно и поспорить, то второе – на мой взгляд, просто неверно. Если о классе нельзя ничего сказать в терминах обязанностей, или если он ничего не делает, то зачем он вообще нужен?
суббота, 15 октября 2011 г.
воскресенье, 2 октября 2011 г.
Задача про датчики: построение функциональной архитектуры
Один из идеологов объектно-ориентированного подхода и один из авторов языка моделирования UML Джеймс Рамбо пишет:
"Модель классов описывает статическую структуру системы: объекты и отношения между ними, атрибуты и операции для каждого класса объектов. Модель классов – самая важная из трёх основных моделей. Мы считаем, что в основе системы должны быть объекты, а не требуемая функциональность, потому что объектно-ориентированная система лучше соответствует реальному миру и оказывается более жизнеспособной при возможных изменениях".
Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 42.
На мой взгляд, данное утверждение в корне неверно, потому что любая система проектируется и создаётся для чего-то, т.е. предназначена для выполнения каких-то полезных функций. Эти полезные функции должны выполняться эффективно, желательно, с наименьшими затратами и с соблюдением надлежащего качества. Как результат, архитектура программы должна быть заточена под полезные функции, а не под абстрактные объекты реального мира.
Подписаться на:
Сообщения (Atom)