Форум Сообщества Аналитиков

×


Вопросы практики проектирования Web-приложения(Прочитано 72213 раз)
Вопросы практики проектирования Web-приложения
===============================================

Чем всё-таки могут помочь дисциплинны по Аналитике и UML при проектировании Web-приложения?

Задача:
=================
- реализовать Web-доступ к работающему клиент-серверному приложению на Delphi
- обеспечить удобный ввод информации в систему типа CRM
- протокол обмена только HTTP (защтой канала занимаетсмя другая организация)

Ограничения:
===================
- рессурс программистов ограничен (2-3 человека)
- нецелосообразен переход с ЯП Delphi на другой ЯП (либо обосновать необходимость)

Первый практический вопрос:
=========================
- для создания работающей модели первых WEb-страниц необходимо учитывать ОГРАНИЧЕНИЕ ТЕХНОЛОГИИ WEB
  (Web не поддерживает состояние (statelles). Это означает, что как только запрос будет обслужен, вся информация теряется).
 На примере реализации таблицы на клиенте.... Нет примеров "редактирования в таблице" как это делается в других ЯП (Delphi....). Обычный пример редактирования, это клик на записи и обновление страницы в другую форму где и происходит действо.

С точки зрения пользователя это менее неудобно, но таковы ущербные технологии Web.
Вот такие пока мысли...

Вопрос:
==================
Как сделать Web-приложение УДОБНОЕ пользователю?

PS. Опыта разработки именно в Web нет, но ... не Боги горшки обжигают :)



Чем всё-таки могут помочь дисциплинны по Аналитике и UML при проектировании Web-приложения?
Современное веб-приложение по сути мало, чем отличается, от других приложений. Поскольку аналитика и проектирование (моделирование) вообще-то оторвано от способов реализации, ничто не мешает использовать UML для моделирования и проектирования веб-приложений.

Цитировать
Первый практический вопрос:
=========================
- для создания работающей модели первых WEb-страниц необходимо учитывать ОГРАНИЧЕНИЕ ТЕХНОЛОГИИ WEB
  (Web не поддерживает состояние (statelles). Это означает, что как только запрос будет обслужен, вся информация теряется).
Я бы не был столь категоричен. Действительно технология ВЕБ предполагает, что когда запрос обслужен информация теряется. Но для сохранения ее используется механизм сессии или cookies.


 
Цитировать
На примере реализации таблицы на клиенте.... Нет примеров "редактирования в таблице" как это делается в других ЯП (Delphi....). Обычный пример редактирования, это клик на записи и обновление страницы в другую форму где и происходит действо.

С точки зрения пользователя это менее неудобно, но таковы ущербные технологии Web.
Вот такие пока мысли...
Работа на клиенте реализуется средствами JS например, или Ajax.

Цитировать
Вопрос:
==================
Как сделать Web-приложение УДОБНОЕ пользователю?
Сначала определите, а что нужно пользователю от приложения? Что сделает его "счастливым", а затем ищите решения, которые позволяют это сделать.
Посмотрите например: http://www.maillist.ru/lr/145249/72964112
есть вот такая статья на interface.ru (была по крайней мере) Быстрая разработка веб-приложений на CodeGear Delphi for PHP
http://www.interface.ru/home.asp?artId=4126
http://www.interface.ru/home.asp?artId=4164
http://www.interface.ru/home.asp?artId=4192
И начните с изучения общих основ веб-программирования
« Последнее редактирование: 09 Апреля 2007, 12:14:39 от Galogen »



Цитировать
Современное веб-приложение по сути мало, чем отличается, от других приложений. Поскольку аналитика и проектирование (моделирование) вообще-то оторвано от способов реализации, ничто не мешает использовать UML для моделирования и проектирования веб-приложений.
не согласен. Как проектирование мостов предпологает имеющиеся технологии, так и .....
2. Проект UML (событийная модель) на Web и десктоп будут разные.
Время отклика на заполение выпадающего списка через Web - критично для USER'a

Цитировать
Сначала определите, а что нужно пользователю от приложения? Что сделает его "счастливым", а затем ищите решения, которые позволяют это сделать.
Для пользователя - Редактируемая вэб-таблица (мигает курсор в поле и при переходе на след.запись - сохранение на вэб-сервере данной записи).

Я не видел такой реализации в проектах на Вэб. (может мало видел).
IMHO Ajax новыя и сырая пока технология не лишённая своих недостатков (позже)



PS. Опыта разработки именно в Web нет, но ... не Боги горшки обжигают
IMHO Ajax новыя и сырая пока технология не лишённая своих недостатков (позже)
Не чувствуете противоречия? Так у Вас все-таки есть опыт или его нет?

Теперь о вашей теме. Еще раз повторяю, реализация - это другой вопрос.
Вы же задаете вопрос о проектировании.
Проектирование - это разработка или выбор архитектуры системы в целом, приложения, разработка классов(если будует использовать), алгоритмов, модели данных. При чем тут веб или не веб. Вы путаете процессы проектирования и реализации.
При проектировании Вы выясняете А что же вам нужно? Затем вы выбираете технологию и используете ее возможности. Очевидно определенные вещи сделать на веб сложно или не возможно, либо надо учитывать какие-то особенности.
Если Вы хотите получить веб-приложение, которое по сути работает как локальное - смотрите в сторону ASP.NET или Java.

И вообще сначала опишите свою ПРОБЛЕМУ так, чтобы вас поняли ДРУГИЕ. А потом можно уже говорить конкретно



Как сделать Web-приложение УДОБНОЕ пользователю?
Добавлю, а что Вы понимаете под удобством веб-приложения для пользователя?



Цитировать
Не чувствуете противоречия? Так у Вас все-таки есть опыт или его нет?
======== Бываю случаи (невсегда), когда: "Для того чтобы судить о качестве приготовленной яичницы, необязательно уметь нести яйца".

Теперь о вашей теме. Еще раз повторяю, реализация - это другой вопрос.
Вы же задаете вопрос о проектировании.
Проектирование - это разработка или выбор архитектуры системы в целом, приложения, разработка классов(если будует использовать), алгоритмов, модели данных.
====== попрежнему считаю, что модель для Web-приложения отлична от модели для десктоп. Чуть позже перейдём к моделям.

При чем тут веб или не веб. Вы путаете процессы проектирования и реализации.
При проектировании Вы выясняете А что же вам нужно? Затем вы выбираете технологию и используете ее возможности. Очевидно определенные вещи сделать на веб сложно или не возможно, либо надо учитывать какие-то особенности.
====== да, я про это и говрил. Например :"Перетащи и брось"

Если Вы хотите получить веб-приложение, которое по сути работает как локальное - смотрите в сторону ASP.NET или Java.
===== смотрю плюсы и минусы. Некоторые вещи, которые на других ЯП решались естественным образом. Здесь для заказчика будут ДОРОЖЕ.
И вообще сначала опишите свою ПРОБЛЕМУ так, чтобы вас поняли ДРУГИЕ. А потом можно уже говорить конкретно
=== пока "упёрся" на редактировании в таблице. В других ЯП достаточно было свойство Edit = True.
Здесь заказчику надо проектировать переходы на другие Web-страницы



Добавлю, а что Вы понимаете под удобством веб-приложения для пользователя?
чтобы он не думал, что работает через Web. Например: "Кнопка удалить запись" недоступна, если не выделена строка в таблице.



Недостатки Аякса
Так же, как на любую бочку меда всегда найдется ложка дегтя, любая технология всегда имеет не только плюсы, но и минусы. Ниже я перечислю наиболее существенные недостатки AJAX и опишу возможные методы их устранения.

Поисковая оптимизация


По моему мнению, главной проблемой страниц на Аяксе является их «невкусность» для поисковиков, поэтому такие страницы очень плохо ими «съедаются», ведь поисковик не умеет переходить по ссылкам JavaScript. Огромное количество пользователей могут пройти мимо твоего сайта, даже если на нем есть требуемый контент. Следовательно, его нужно сделать доступным другим способом, хотя бы самым банальным – смастерить страничку «Карта сайта» с полным списком страниц.

Кроссбраузерность

У пользователей есть плохое качество - они пользуются разными браузерами. Казалось бы, нет проблем – пиши код на HTML, CSS и JavaScript, который соответствует стандартам, и все. Но не тут-то было - разные браузеры поддерживают стандарты неодинаково. Что ж, ставим себе несколько самых популярных браузеров (причем необходимо поставить еще и их разнообразные версии) и тестируем наши веб-странички.

Пользователи без AJAX

Ты будешь смеяться, но есть странные типы (я, например), у которых JavaScript работает только для определенных сайтов, а для других отключен, или у которых нестандартный браузер, не знающий про AJAX. Как же им быть? Обязательно сделай альтернативную HTML-версию страницы, бери пример с gmail.com!

Кнопка «Назад»

По данным исследователей, кнопка браузера «Назад» является вторым по популярности средством навигации после перехода по ссылке. То есть пользователь всегда рассчитывает на возможность вернуться на одну страницу назад. Веб-странички, которые созданы с использованием Аякса, такую возможность не поддерживают, потому что их содержание создается «на лету». Чтобы как-то это исправить, можно запрограммировать соответствующую логику на JavaScript и сделать ссылку «Назад», щелчок на которую позволит пользователю перейти на предыдущую страницу. Второй вариант, более универсальный и чаще всего легче реализуемый, – использовать невидимый IFRAME, который будет накапливать историю переходов.

Избранное


Твоя страничка на Аяксе настолько понравилась посетителю сайта, что он решил кинуть ее в «Избранное» (или в «Закладки», если посетитель - лисовод). Но у него ничего не получится, так как у группы страничек на Аяксе всегда адрес первой из них. Справиться с проблемой опять же можно двумя способами: программингом и хаком. Программерское решение заключается в том, чтобы каждая сгенерированная страница имела свой адрес и ссылку «Добавить в Избранное», которая будет реализовывать нужную логику. Второй способ - использовать ссылку на подраздел, который идет в адресе страницы после знака диеза «#». Дело в том, что с помощью JavaScript эту часть адреса можно изменять. Таким образом, этот хак может частично решить и проблему кнопки «Назад».

Неопределенное время ответа

Время ответа сервера на запрос не определено - может пройти несколько секунд, а может - несколько минут. И пользователь начинает сильно нервничать, грызть ногти и наконец закрывает страничку - ведь браузер никак не отображает, что там что-то происходит :). Чтобы не доводить пользователя до невроза, нужно вставить на страничку хотя бы надпись «Идет загрузка», а лучше - анимированное графическое изображение, которое будет показывать, что она жива.




По-моему исходный вопрос звучал как "Чем всё-таки могут помочь дисциплинны по Аналитике и UML при проектировании Web-приложения?", а вы тут уже про Ajax начали тему ... или под термином "Аналитика" понимаем нечто очень общее и большое? Но тогда не стоит употреблять его в связке со словом "дисциплина" ибо есть устойчивая ассоциация с дисциплинами RUP.
Отвечая на исходный вопрос -- дисциплина Анализ и проектирование и соответственно использование языка UML может помочь при проектировании хоть web, хоть каких приложений, но при некоторых условиях:
1. Использование соответствующих архитектурных стилей, и в частности более четкое разделение на приложения на "слои" GUI, бизнес-логики, persistent и хранения данных.
2. Вы владеете языком UML и можете "на нем говорить" в равной степени с окружающими вас инженерами.

 
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Я так и не пойму все-таки вопроса.
Вы, Петро, задавая вопрос, что хотели о нас услышать?
Готовое решение, которое позволяет Вашим пользователям работать с  веб-интерфейсе совсем не чувствуя этого?
Или каковы принципы проектирования таких систем?

В первом случае, конечно, вы вряд ли дождетесь ответа. То что Вы хотите реализовать (drag&drop и прочие вкусности) реализовать можно. Вопрос стоит лишь, а как. Понятно, что обработку  логике представления надо в этом случае делать на клиенте и никак на сервере. Если только это не интрасеть, или интернет 2. В любом случае Вам прийдется решать задачу с использованием javascript и им подобных, flash, activeX. Вероятно,есть и другие решения - тогда Вам имеет смысл обратится на соотвествующие ресурсы. Поскольку здесь нет предмета для обсуждения в рамках нашего форума, Вам же все ясно - редактируемая таблица (правда только не таблица, а форма - форма единственный интерактивный инструмент в html, не считая ссылок).




в общем согласен, но..
1. Использование соответствующих архитектурных стилей, и в частности более четкое разделение на приложения на "слои" GUI, бизнес-логики, persistent и хранения данных.
делят на слои счас все кому не лень.
У меня краеугольный камень

Слой-GUI <-----> Слой бизнес_правил (БП).

IMHO модель, цена, сроки, концепция будут разными при применений Web-технологии.
Я думаю, надо будет сравнить 3 подхода к решению задачи разными технологиями и показать различия решения одной и той-же задачи разными средствами.
В ближайшее время рассмотрю плюсы и минусы решения  виде таблицы:

ЯП-технолгия      Delphi | C# | Ajax
==============================
Критерии оценки

ЗЫ. Вообще люблю выбирать или аналитически оценивать в сравнении чего-то с чем-то. Так яснее заказчик видит, от чего он может отказаться и пожертвовать :)



Вероятно,есть и другие решения - тогда Вам имеет смысл обратится на соотвествующие ресурсы. Поскольку здесь нет предмета для обсуждения в рамках нашего форума
может быть, может быть.
Я просто набираю информацию о том, какими средствами (технологией) _рациональнее решить задачу_.
Считал именно этим и занимаются Аналитики при построении концепции.
Причём в код не углублялся, а пытался увязать требования с современныйми возможностями IT систем (ограничениями Оных).
ЗЫ. На форумах был. В основном нет методов выбора рационального варианта построения архитектуры.

Искал ответа на вопрос - "Скока будет в граммах..." со стороны заказчика.



Вопросы практики проектирования Web-приложения
===============================================

Чем всё-таки могут помочь дисциплинны по Аналитике и UML при проектировании Web-приложения?
Что такое "Дисциплины по аналитике"?

Цитировать
Задача:
=================
- реализовать Web-доступ к работающему клиент-серверному приложению на Delphi
- обеспечить удобный ввод информации в систему типа CRM
- протокол обмена только HTTP (защтой канала занимаетсмя другая организация)
Не, так не пойдёт, давайте сначала. Что есть, какие бизнес-цели и т.д.

"Клиент-серверное приложение" и "система типа CRM" - это одно и то же?
Система написана вами или покупная?
Весь код доступен?
На какой версии Delphi написано?
Каков порядок количества форм?
Каждая форма - это кастомный код или есть какой-то фреймворк, генерящий интерфейсы по метаданным?
Есть ли какие-то нестандартные интерфейсные решения?
Система тиражируемая или под конкретное предприятие?
Насколько система отличается по функционалу от общерыночных решений?
Проще говоря, как много специфики конкретного предприятия в ней?
Сейчас система эксплуатируется?
Порядок количества рабочих мест?
Как вообще возникла задача веб-доступа, зачем это нужно?
Результирующая система будет функционировать в интранете или в интернете?
Каково целевое количество рабочих мест?
Какова интенсивность использования целевой системы (среднее число обращений в день на пользователя)?



может быть, может быть.
Я просто набираю информацию о том, какими средствами (технологией) _рациональнее решить задачу_.
Считал именно этим и занимаются Аналитики при построении концепции.
Причём в код не углублялся, а пытался увязать требования с современныйми возможностями IT систем (ограничениями Оных).

"Все не так было" (с) :-). Программная архитектура строится на основании требований к системе. Аналитики не занимаются программной архитектурой как таковой. они занимаются бизнес требованиями и функциональными и нефункциональными требованиями. Если ваш заказчик желает иметь под вэб такой же GUI как в Дельфи -- то это будет ОГРАНИЧЕНИЕ проектирования. Однако вызывает сомнение, что ваш заказчик хочет именно иметь гриды и сохранять каждую запись. Думаю это уже ваша интерпретация потребностей заказчика. Можно сделать предположение, что у вас проблема таки не в программной архитектуре, а в том, как достичь с заказчиком соглашения по юзабилити.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



"Все не так было" (с) :-). Программная архитектура строится на основании требований к системе. Аналитики не занимаются программной архитектурой как таковой. они занимаются бизнес требованиями и функциональными и нефункциональными требованиями. Если ваш заказчик желает иметь под вэб такой же GUI как в Дельфи -- то это будет ОГРАНИЧЕНИЕ проектирования. Однако вызывает сомнение, что ваш заказчик хочет именно иметь гриды и сохранять каждую запись. Думаю это уже ваша интерпретация потребностей заказчика. Можно сделать предположение, что у вас проблема таки не в программной архитектуре, а в том, как достичь с заказчиком соглашения по юзабилити.
:) вот я и хотел выяснить, чем же занимаются аналитики :)
Худшие предположения подтвердились, "как далеки они от народа".
Твоя отчасти неправота раскроется, когда заказчик спросит: "Надо ли нанимать Java-программиста, или Вы сами на Delphi справитесь?". Т.е. КАКИЕ ТРЕБОВАНИЯ ЗАВИСЯТ ОТ ВЫБРАННОЙ СРЕДЫ ПРОГРАММИРОВАНИЯ И ЦЕНЫ В СВЯЗИ С ЭТИМ.
Вы так говорите, как будто при приходе в магазин выбора автомобиля менеджер не должен знать что такое ABS.
Он помогает заказчику узнать о ТЕХНИЧЕСКИХ достижениях в автомобилестроении и соразмерить его вкусы (МАКС) с его кошельком (МИН).




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19