Сегодня 29 мая, среда ГлавнаяНовостиО проектеЛичный кабинетПомощьКонтакты Сделать стартовойКарта сайтаНаписать администрации
Поиск по сайту
 
Ваше мнение
Какой рейтинг вас больше интересует?
 
 
 
 
 
Проголосовало: 7273
Кнопка
BlogRider.ru - Каталог блогов Рунета
получить код
Software Design
Software Design
Голосов: 1
Адрес блога: http://askofen.blogspot.com/
Добавлен: 2011-01-16 01:46:25
 

Проектирование взаимодействия с пользователем для графического редактора

2010-12-07 00:26:00 (читать в оригинале)

Рисование фигур

Привычные нам графические редакторы для настольных ПК предоставляют пользователю множество готовых примитивов. Например, графический редактор, встроенный в Microsoft Word 2003, содержит 115 готовых автофигур.
Взаимодействие с пользователем в таких редакторах можно описать при помощи следующего юз-кейса:

1.      Программа предоставляет набор готовых фигур.
2.      Пользователь выбирает фигуру из набора.
3.      Пользователь задает расположение и размеры фигуры.
4.      Программа рисует фигуру в указанном месте и заданного размера.

Между программой и пользователем происходит разделение обязанностей. Фактически, обязанность по рисованию фигуры программа берет на себя.

Дальше »

Проектирование реализации

2010-11-29 01:47:00 (читать в оригинале)

Цель этапа проектирование классов – найти подходящие классы и определить требования к ним.

Цель этапа проектирование реализации – изобрести реализацию класса, удовлетворяющую требованиям к нему.

В предложенном мною подходе логика проектирования может быть выражена формулой:

Функциональная модель => Группы функций => Кандидаты в классы => Реализация
Дальше »

Проектирование классов

2010-11-19 17:53:00 (читать в оригинале)

После создания функциональной модели, можно приступать к проектированию классов.

Классический объектно-ориентированный подход даёт проектировщику чёткое руководство, как это делать.

Прежде всего, в предметной области следует найти ключевые абстракции. Различные учебники по ООП пишут, что для графического редактора ключевой абстракцией является фигура.

Затем следует установить взаимосвязи между ключевыми абстракциями. Если взаимосвязь можно выразить отношением is-a, то такие абстракции следует связать при помощи  наследования. Если взаимосвязь подходит под отношение has-a, то такие абстракции следует связать при помощи агрегации.

Для графического редактора абстрактную фигуру можно связать отношением наследования с конкретными фигурами: прямоугольником, эллипсом, треугольником и т.п.

Получается стройная и логичная картина:

class Figure;
class Rectangle : public Figure;
class Ellipse   : public Figure;
class Triangle  : public Figure;

К сожалению, она не позволяет создать редактор, который хоть в какой-то мере удовлетворяет потребностям пользователя.

Дальше »

Проектирование: расширение функциональной модели

2010-11-13 02:23:00 (читать в оригинале)

Прежде чем приступать к проектированию структур данных, следует убедиться в том, что построенная функциональная модель системы достаточно полна.

Будем считать функциональную модель полной, если рассмотрение каждого последующего прецедента не приводит к добавлению новых функций.

Основная ошибка, допускаемая неопытными разработчиками, заключается в том, что они рассматривают упрощённые прецеденты. (Или же не рассматривают их вообще.) Чтобы построить полную функциональную модель, нужно изучать сложные юз-кейсы, взятые из реальной жизни.

Вернёмся к нашему примеру – "проектирование графического редактора для создания открыток".

Первая часть.
Вторая часть.

В третьей части мы расширим функциональную модель модуля редактирования.

Дальше »

Проектирование: построение функциональной модели

2010-11-06 03:21:00 (читать в оригинале)

Прежде чем проектировать структуры данных, разработчик должен построить функциональную модель проектируемой системы.

В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций.

У автора есть веские основания для такой рекомендации: любая техническая система создаётся для выполнения каких-то полезных функций. Если она их не выполняет, то такая система не нужна. Согласитесь, мало кому в быту будет полезен стул со сломанными ножками. Просто потому что на нём невозможно сидеть. В программной индустрии точно также. Если программа не делает нечто полезное, её можно удалить с компьютера, чтобы она не занимала место.

Направление проектирования должно быть задано однозначно: от функций к структурам данных, а не наоборот.

Дальше »


Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 

 


Самый-самый блог
Блогер ЖЖ все стерпит
ЖЖ все стерпит
по сумме баллов (758) в категории «Истории»


Загрузка...Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.