Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 ... 3 4 5 [6] 7 8 9   Вниз
  Печать  
Автор Тема: коллеги, давайте, наконец, напишем что-нибудь. )  (Прочитано 257943 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #150 : 08-08-2011 19:46 » 

Цитата: RXL
Игорь хочет карточки. Я считаю, что таблетка удобнее, т.к. ее можно повесить на связку ключей и если электричества нет, то откроешь ключом, когда как карточка отдельно от ключей и их можно просто забыть.
А "и того, и другого - и можно без хлеба"? Улыбаюсь


Что я ещё хочу сказать о жизни. Одиночный разработчик все детали может, если ему хочется, держать в голове. Но даже ему лучше записывать - чтобы не забылось. В группе это уже совсем невозможно, поскольку у каждого свои мозги. Каждый субъективно выбирает из множества требований те, которые считает наиболее важными - он про них хорошо помнит и ради их сохранности готов подзабыть или ненароком поменять менее важные требования. Беда в том, что у каждого в группе свои предпочтения, поэтому неминуемо в головах общая картина начинает размываться и рассогласовываться. Бумажка - это связующее звено. Периодически её надо коллективно перечитывать и обсуждать, чтобы восстановить единство картины проекта у всех членов группы. Вместо бумажки в группе может быть идеолог - его задача ходить и "разговоры разговаривать" со всеми, пропуская через себя все мнения и передавая всем эти мнения; или для особо маленькой группы - регулярные разговоры в общем кругу. Ещё один вариант - ведущий, тогда проект он разрабатывает как бы единолично, а остальные от него получают конкретные задания; хотя ведущий с остальными может что-то обсуждать, вся ответственность за целостность лежит на нём, поэтому он может позволить себе какие-то детали держать в своей голове и не парится по поводу того, все ли эти детали знают. Без ведущего - обязанность каждого следить за собой и всеми остальными, чтобы не возникало разных пониманий.

Поэтому фиксация всяких мелочей и подробностей для группы жизненно необходима - она обеспечивает единство представления о проекте. На это стоит тратить усилия, это очень важно для группы/команды, занятой совместной работой на общую цель, но с разделением труда и ролей.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #151 : 08-08-2011 19:52 » 

Да-да. Хочешь - карточку, хочешь - таблетку, хочешь - все сразу, а можно и без всего.

Добавлено через 6 минут и 27 секунд:
Так с чего же начнем? Уточняем спецификацию и расписываем алгоритмы поведения устройства?

Добавлено через 6 минут и 45 секунд:
У нас уже есть трекер: http://redmine.shelek.su/projects/vu-lock-controller
Проект открытый - читать можно без регистрации. Желающие принять участия - прошу зарегистрироваться и сообщить свои логины в ЛС для прикрепления к проекту и роль на трекере (менеджер, разработчик). При логине пишите там осмысленные ФИО - мусор я периодически баню, т.к. иначе его не определишь.

SVN так же открыт для чтения. Для записи мне нужен произвольный логин/пароль в ЛС.

Так получилось, что я вроде как выполняю роль ведущего. Мне это не очень нравится, т.к. хотелось бы в процессе освоить новые для себя технологии и инструменты и нужен если не ведущий (если ни у кого не возникнет такого желания), то хотя бы совместный ведущий.

« Последнее редактирование: 08-08-2011 20:12 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #152 : 08-08-2011 20:14 » 

все бы вам резать!)
тут имхо не резать надо, а аккуратно скопипастить по подразделам (к примеру):
1. ТЗ
2. Обзор существующих изделий
3. Разработка функциональной схемы и сценариев работы в различных режимах(с точки зрения пользователя)
4. Разработка алгоритмов работы отдельных модулей
5. Разработка протоколов обмена между отдельными модулями (что, когда и кто куда передает - информационная составляющая)
6. Выбор и обоснование аппаратной реализации
7. Программная реализация
8. Тестирование отдельных модулей
9. Тестирование устройства в целом

я это как-то так вижу... поправьте если ошибаюсь.
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #153 : 08-08-2011 20:33 » 

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

Что сейчас действительно необходимо, так это сбор и обработка бизнес-требований. Из них будет следовать все остальное.
« Последнее редактирование: 08-08-2011 20:35 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #154 : 08-08-2011 20:39 » 

Dale, ну я не ГОСТовское ТЗ имел в виду) именно - бизнес)
в остальном - есть недочеты?
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #155 : 08-08-2011 21:18 » 

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

Я обычно строю проекты в таком порядке:

1. Сбор бизнес-требований.
2. Их обработка и выпуск документа Vision (см. ReadySET).
3. Сбор пользовательских требований.
4. Выпуск спецификации требований, в т.ч. функциональных, на основе модели прецедентов (Use Case).
5. Разработка приемочных тестов на основе п.4.

Ну и так далее, по давно накатанной колее с использованием V-модели (у меня к ней давняя симпатия).
« Последнее редактирование: 09-08-2011 06:41 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #156 : 09-08-2011 07:23 » 

Цитата: Dale
Например, обзор существующих решений делается после ТЗ, а хорошо бы с него начать.
Так всё может закончиться выбором одного из существующих решений Улыбаюсь Насколько я понял, x77 хотел изобрести велосипед, чтобы самому разобраться, как, что и почему делается при решении такой задачи.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #157 : 09-08-2011 07:37 » 

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

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

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

Тоже вполне реальная и практичная цель проекта: освоить на практике такие-то технологии, научиться тому-то, разобраться в такой-то элементной базе, натаскать команду на совместную удаленную работу... Не обязательно добиваться коммерческого успеха или превзойти все имеющиеся аналоги.  

Главное сейчас - сначала зафиксировать, что, как и для чего будем делать, чтобы не получилось, что видений проекта (и его воплощений) столько же, сколько участников, или даже больше. А уже потом постепенно двигаться к этой цели.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #158 : 09-08-2011 08:20 » 

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

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

модель прецедентов (Use Case) и V-модель, что посоветуете почитать, что нибудь толковое, не сильно длинное и унылое, желательно на русском?)
[/quote]
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #159 : 09-08-2011 09:04 » 

модель прецедентов (Use Case) и V-модель, что посоветуете почитать, что нибудь толковое, не сильно длинное и унылое, желательно на русском?)

По Use Case - любой букварь по UML, их сейчас немерено, или вот эту книгу: http://forum.shelek.ru/index.php/topic,26526.msg260714.html#msg260714

По V-модели даже затрудняюсь с ходу что-нибудь конкретное посоветовать, попадалась в нескольких источниках, но навскидку не найду; наверное, надо бы черкнуть об этом хотя бы несколько строк в нашей Вики...

P.S. Коллеги растащили чуть ли не всю книжную полку. Вот среди уцелевших остатков нашел неплохую книгу: Кендалл Скотт, "Унифицированный процесс. Основные концепции". Глава 2, "Технологический процесс управления требованиями", как раз посвящена анализу прецедентов.

P.P.S. Вот нашел у нас статью по теме: http://club.shelek.ru/viewart.php?id=232 . Там очень сжато, но в конце список литературы.
« Последнее редактирование: 09-08-2011 09:15 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #160 : 09-08-2011 11:04 » 

http://ru.wikipedia.org/wiki/V-Model

Вот еще в одной статье попалась неплохая иллюстрация, которая вполне отражает суть:


* V.PNG (32.41 Кб - загружено 551 раз.)
« Последнее редактирование: 09-08-2011 12:35 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #161 : 09-08-2011 11:41 » 

Vision про то, что мы тут все вместе собрались, чтобы ... и построить светлое будущее, я пропущу. Улыбаюсь


Никто не забыт и ничто не забыто? Можно детализировать?

В дальнейшем каждая деталь, каждая feature должна ложиться в матрицу этих use case.

* lock-usecase.png (15.76 Кб - загружено 568 раз.)
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #162 : 09-08-2011 11:47 » 

Я бы еще добавил актора "злоумышленник" и прецеденты, связанные с попыткой несанкционированного проникновения: подбор кода замка, перебор электронных ключей и т.п.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #163 : 09-08-2011 11:57 » 

Dale, согласен.

А вот всякие "дети" и т.п. действующие лица нужны? Для них предполагается какая-то специфика? Стоит ли разделять "хозяин дома" и "поставщик"?
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #164 : 09-08-2011 11:59 » 

И еще. Попавший под неожиданное сокращение Vision помимо прочего должен установить границы проекта, например: используются ли в данной версии (или если нет, то планируется ли к использованию в дальнейшем) домофон, RFID, биометрические датчики, связь с сигнализацией, системой "умного дома" и т.п. От таких деталей может довольно сильно измениться набор прецедентов и их сценарии, а также архитектура системы в целом.

IMHO перепрыгивание начальных этапов даст сегодня мизерный выигрыш в несколько дней, но потом может выйти боком.

Добавлено через 5 минут и 29 секунд:
А вот всякие "дети" и т.п. действующие лица нужны? Для них предполагается какая-то специфика?

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

Стоит ли разделять "хозяин дома" и "поставщик"?

Имеет смысл, чтобы ограничить лишний доступ к электронной начинке для чайников.
« Последнее редактирование: 09-08-2011 12:04 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #165 : 09-08-2011 12:35 » 

Цитата: Dale
используются ли в данной версии (или если нет, то планируется ли к использованию в дальнейшем) домофон, RFID, биометрические датчики, связь с сигнализацией, системой "умного дома" и т.п.
Рискну сказать за x77 и RXL - нет. Улыбаюсь RFID под кожу хозяину, датчики движения, дверца для кота и т.п. - это замечательно, как и все наполеоновские планы, только в реальности разумнее поступательное развитие - сделать что-нибудь попроще, но сделать, а потом уже, взяв за основу, переходить к версии 2.0. В противном случае не будет ничего.

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

Вот смотри:


Уже меня терзают сомнения, что здесь что-то не так. Основное сомнение заключается в следующем: да, злоумышленник и хозяин дома - разные действующие лица с разными намерениями. Но система об этом априори не знает, она должна сама уметь определять, кто есть кто. А зачем? Что она может сделать в ответ? Ну если есть сигнализация - сигнализировать. Может заблокировать все электронные способы открытия, чтобы можно было открыть только ключом вручную. Но от отмычки уже ничего не поможет, и система даже не сумеет распознать такую ситуацию.

По-моему это надо упрощать.

* lock-usecase.png (23.12 Кб - загружено 517 раз.)
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #166 : 09-08-2011 12:51 » 

злоумышленник и хозяин дома - разные действующие лица с разными намерениями. Но система об этом априори не знает, она должна сама уметь определять, кто есть кто. А зачем? Что она может сделать в ответ?

Если это, например, подбор кода замка, то система вполне может его распознать и максимально затруднить. Скажем, давая одну попытку в минуту. Имея 60 попыток в час, не разгуляешься. То же самое при попытке открыть чужой "таблеткой" - следующая будет распознаваться лишь после тайм-аута.

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

от отмычки уже ничего не поможет, и система даже не сумеет распознать такую ситуацию.

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #167 : 09-08-2011 13:04 » 

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

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #168 : 09-08-2011 13:15 » 

вариант не очень: отвалился провод клавиатуры (кстати ее кажется пока не рассматривали) или таблетки(контакты окислились)

Это вполне можно сделать на собственной клавиатуре пульта девайса, а не на наружной, которую и разбить могут. (Кстати, шантрапа развлекается тем, что лупит электрошокером в гнезда для таблеток). И гнездо для таблетки можно на нем же установить, чтобы слушался только хозяина. Маловероятно, что обе клавиатуры/гнезда вйдут из строя одновременно.

Но это, конечно, более комплексная охранная система получается, чем просто дверной замок с электромагнитом. Потому-то и необходимо предельно четко определить границы перед проектированием.
« Последнее редактирование: 09-08-2011 13:17 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #169 : 09-08-2011 13:41 » 

Vision должен быть документом с позитивными утверждениями, иначе перечисление всего, что не войдёт в систему будет бесконечным и займёт бесконечное время.

А вот отработка сценариев действия/бездействия системы - это уже более поздний этап.

По-моему, формулировки
"Программируемый
Цитата: Dale
дверной замок с электромагнитом
"
для Vision в данном случае достаточно. Это исключает все остальные варианты Достаточно обозначить, что это не охранная система, а лишь замок. Как это и было обозначено в начале x77.

Поэтому предлагаю остановиться на варианте

* lock-usecase.png (19.08 Кб - загружено 705 раз.)
« Последнее редактирование: 09-08-2011 13:43 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #170 : 09-08-2011 14:22 » 

Dimka, x77 хотел еще возможность дистанционного открытия двери посетителям, лежа в джакузи)
и не пойму, по этой схеме -  хозяин не может быть посетителем? то есть открывать замок снаружи? или в этот момент он не является "хозяином дома"?

PS "хозяин дома" или "хозяин - дома"?)))))

PPS еще. возможно версию 2.0 можно делать будет делать программно, если в железо заложить хотя бы на 10-20% больше необходимого.
перерабатывать железо по моему опыту - это как правило фактически заново пройти полный цикл разработки.
объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость.
« Последнее редактирование: 09-08-2011 14:41 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #171 : 09-08-2011 15:03 » 

Цитата: Ochkarik
или в этот момент он не является "хозяином дома"?
Замок телепатией не обладает. Улыбаюсь

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

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

Цитата: Ochkarik
объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость.
Берёшь и рисуешь. Специального обозначения нет - можно стереотип завести и им подписывать.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #172 : 09-08-2011 15:23 » 

Клавиатура не планируется.

Защита от электрошокера и просто от разряда статического электричества предусматривается в схеме.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #173 : 09-08-2011 17:29 » 

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

В UML применяется отношение обобщения (подобие наследования в ООП). Если провести незакрашенную стрелку от Хозяина к Посетителю, это означает, что Хозяин является частным случаем Посетителя, т.е. может делать все то же самое, что и Посетитель, плюс особые хозяйские фичи.

объясните, можно ли на диаграммах обозначать потенциальные возможности? которыми впринципе можно пожертвовать, если они значительно повышают трудоемкость.

В UML нет такого готового встроенного средства, только стереотипы или комментарии. Обычно это делается несколько иначе: в спецификациях требований каждому требованию приписывается атрибут, который может принимать несколько значений (наиболее типичен набор из трех: обязательное, желательное, необязательное).

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

Желательные реализуются, если проект укладывается во временные рамки и остается свободное время (есть и такое суеверие среди программистов, настроенных оптимистично).
 
Что касается необязательных, в эту категорию отправляются требования, до которых почти наверняка в этой версии не дойдут руки, но и забыть о них не хотелось бы; в перспективе они попадут в план одной из следующих версий, если до них дойдет дело, в качестве обязательных или желательных.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #174 : 09-08-2011 20:14 » 

Цитата: Dale
В UML применяется отношение обобщения (подобие наследования в ООП). Если провести незакрашенную стрелку от Хозяина к Посетителю, это означает, что Хозяин является частным случаем Посетителя, т.е. может делать все то же самое, что и Посетитель, плюс особые хозяйские фичи.
В данном случае не подходит. Т.к. "Хозяин" не наследует от "Посетителя" "Вандализм".

Если использовать этот подход, нужно выделение из "Посетителя" его разновидностей: "Хозяина", "Злоумышленника" и ещё кого-то. Но выше я изложил свой скепсис по этому поводу: это интересно в социологическом плане, но совершенно неинтересно с точки зрения решаемой задачи.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #175 : 10-08-2011 05:51 » 

Давайте не разделять на множество разных пользователей. Хозяин тоже с пьяну может захотеть навредить.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Алексей++
кот глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #176 : 10-08-2011 05:56 » 

RXL, Игорь то ? ))
Записан

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #177 : 10-08-2011 08:01 » 

Цитата: RXL
Давайте не разделять на множество разных пользователей. Хозяин тоже с пьяну может захотеть навредить.
Тогда скажи, нужен ли use case "Попытка взлома"? Типа блокировки на минуту после 3-х неудачных попыток и т.п.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #178 : 10-08-2011 09:59 » 

Думаю, что не нужен. Посуди сам:
* Карта Wiegand-26 - это 24-битный программируемый поставщиком индентификатор.
* Таблетка DS1990A - это 48-битный уникальный, одноразово программируемый при производстве, идентификатор.
Перебирать их бессмысленно, особенно учитывая медленную работу этих устройств и большой промежуток между циклами чтения.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #179 : 10-08-2011 11:12 » 

RXL, а большой таймаут может быть?
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Страниц: 1 ... 3 4 5 [6] 7 8 9   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines