UML язык программа: домофон

Министерство образования  и науки Российской Федерации

Владивостокский государственный университет экономики  и сервиса

Институт  информатики инноваций и бизнес систем

 

 

 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому проекту

по дисциплине «Проектирование  информационных систем»

Домофон

 

 

Студент

гр. ВМ-04-01   Р.О. Волобоев

 

 

 

Руководитель                

Д.А. Лютаев

 

 

Нормоконтроллер      

Д.А. Лютаев

 

 

 

Владивосток 2008

Содержание

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 Введение

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

 

2 Задание

Требуется разработать модель программного обеспечения встроенного микропроцессора  домофона.

Домофон регулирует доступ в подъезд  многоквартирного дома. В подъезде имеется дверь с замком. С наружной стороны двери установлена панель с кнопками на каждую квартиру, микрофон и динамик. В каждой квартире имеется кнопка «СВЯЗЬ», «БЛОКИРОВКА» и «ОТКРЫТЬ». Кроме того, в квартире имеется микрофон и динамик.

Жильцы могут открывать дверь ключом. Посетитель может нажать кнопку квартиры на внешней панели. При этом в квартире раздается звонок (если подача звонка в квартиру не заблокирована). Услышав звонок, жилец квартиры нажимает на кнопку «СВЯЗЬ» внутренней панели домофона, после чего домофон устанавливает звуковое сообщение между жильцом и посетителем. Звуки, произносимые посетителем в микрофон, установленный на внешней панели, воспроизводятся в динамике, установленном в квартире. Звуки из микрофона в квартире, передаются в динамик на внешней панели. После сеанса связи жилец может нажать на кнопку «ОТКРЫТЬ», чтобы замок на двери в подъезд открылся, и посетитель смог войти. По истечении минуты замок должен снова заблокировать вход в подъезд. Жилец, который желает, чтобы его не беспокоили, может отключить подачу звонка в свою квартиру, нажав на кнопку «БЛОКИРОВКА». Повторное нажатие на эту кнопку вновь включает подачу звонка.

3 Описание предметной области

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

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

В остальном  особенности предметной области  ясны из задания.

4 Глоссарий

 

Динамик – электроакустическое  устройство воспроизведения звука из электрического сигнала.

 

Микрофон – устройство, позволяющее преобразовывать звук в электрический сигнал.

 

Блок управления – набор  инженерно-конструкторских решений  в виде (как правило) панели с одним  или несколькими интерфейсами для  прямого воздействия на объект управления.

 

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

 

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

 

 

5 Проектирование

• 5.1 Диаграмма прецедентов

 

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

Можно выделить такие  цели создания диаграмм прецедентов:

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

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

Рис. 1. Диаграмма прецедентов.

• 5.2 Диаграмма классов

 

Если вспомнить классовый подход в объектно-ориентированных языках программирования, то можно легко предугадать функциональность этой диаграммы. В отличие от диаграммы прецедентов она информирует нас не только о составе действий, но более детально и четко возлагает каждую из функций на объект класса. Ко всему прочему наследование станет очень удобным инструментом для отражения аспектов проектируемой системы, выявит зависимости. Описание возможностей класса в виде операций класса – присвоит каждому из объектов ряд индивидуальных функций.

На рисунке 2 изображена диаграмма  классов информационной системы  «домофон». В добавление к диаграмме  прецедентов она описывает каждый из объектов системы, выделяя их функционал в виде операций классов. Наследование полезно для упрощения понимания  и представления модели в целом, так как проследить унаследованные правила и возможности просто. На диаграмме изображены все субъекты системы, необходимы для полноценной реализации заявленных требований.

 

Рис. 2. Диаграмма классов

 

 

 

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

 

 

Рис.3. Диаграмма классов  «микрофон», «динамик»

 

• 5.3 Диаграммы последовательностей и активностей.

 

 

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

 

Рис 4. Диаграмма последовательности для прецедента «Открыть дверь из квартиры»

 

 

 

 

Рис 5. Диаграмма последовательности для прецедента «Заблокировать звонки»

 

 

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

 

Рис. 6. Диаграмма последовательности для прецедента «Разговаривать через домофон»

 

 

Рис. 7. Диаграмма активности для прецедента «Разговаривать через  домофон»

 

Как видно в сравнении этих двух диаграмм, активность позволяет описать  параллельно происходящие процессы.

Таким же образом понадобилась диаграмма активности для прецедента «Позвонить в квартиру». Так как система имеет условности при использовании функции звонка, а именно: жилец может заблокировать возможность звонков, некому будет ответить на звонок.

 

Рис. 8. Диаграмма последовательности для прецедента «Позвонить в квартиру»

 

Диаграмма последовательностей «Позвонить в квартиру» не удовлетворяет  по причине отсутствия возможности  описать прецедент, который имеет  несколько вариантов выполнения в зависимости от состояния кнопки «Заблокировать» и присутствия жильца в квартире.

 

 

Рис. 9. Диаграмма активности для прецедента «Позвонить в квартиру»

 

 

Рис. 10. Диаграмма последовательности для прецедента «Связь с посетителем»

 

Диаграмма описывает  последовательный процесс ответа жильца на звонок в квартиру.

 

 

 

• 5.4 Диаграммы состояний.

 

 

 

 

 

 

 

 

 

 

Рис. 11. Диаграмма состояний  для класса «домофон»

 

Диаграмма состояний для класса «домофон» детально описывает состояние  самого контроллера домофона. Ни на одной из диаграмм ранее не описывалась ситуация, когда жилец отклоняет входящий звонок. Состояние «взаимодействие с замком» показывает,  как микроконтроллер управляет замком двери.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 12. Диаграмма состояний для класса «жилец»

 

Диаграмма на Рис. 12 описывает все возможные состояния жильца важные с точки зрения описания системы. Как видно, существует 4 возможных исхода взаимодействия домофона и жильца.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис 12. Диаграмма состояний для класса «посетитель»

 

На этой диаграмме есть небольшое сознательное допущение проникновения состояния класса-родителя. Это состояние «человек». Сделано это с целью более точного описания поведения такого сложного объекта как «посетитель».

 

 

 

 

 

 

 

 

6 Заключение

 

Case-средство Rational Rose в полной мере позволило воспользоваться широкими возможностями UML для проектирования. Данная модель отражает весь функционал и схематически отражает все требования, предъявляемые к реальному программному обеспечению микроконтроллера домофона.