Проектирование системы автоматизации автостоянки
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ
АВТОНОМНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«НИЖЕГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ
УНИВЕРСИТЕТ
ИМ. Н.И. ЛОБАЧЕВСКОГО»
НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ
ИНСТИТУТ ЭКОНОМИКИ И
ПРЕДПРИНИМАТЕЛЬСТВА
Курсовая работа по дисциплине
«Проектирование информационных
систем»
На тему «Проектирование системы
автоматизации автостоянки»
Работу выполнил студент
Группы 745/пи-9к
А.А. Медведев
Н.Новгород, 2014 г.
Оглавление
Введение
Глава 1. Анализ технологий
создания программного обеспечения
.1 Технология RAD - Rapid
Application Development
.2 Технология XP - Extreme
Programming
.3 Технология MSF - Microsoft
Solution Frame
.4 Технология ICONIX
.5 Обоснование выбора
технологии создания ПО ИС для проекта курсовой работы
Глава 2. Проектирование
системы при помощи технологии ICONIX
.1 Описание предметной
области
.2 Этап анализа технологии
ICONIX
.3 Этап предварительного
проектирования
.4 Этап детального проектирования
.5 ЕR - диаграмма
Заключение
Список литературы
Введение
Цель курсовой работы - закрепление навыков по проектированию
информационных систем.
В курсовой работе должны быть решены следующие задачи:
- анализ существующих технологий создания информационных систем
(ИС)
- обоснование выбора технологии создания ИС для проекта
курсовой работы
- разработка проекта ИС по выбранной технологии
Для решения поставленных задач будет применяться средства
инструментального проектирования ИС (CASE - средство) Rational
Rose, язык визуального
объектно-ориентированного моделирования UML - Unified Modeling
Language.
Глава 1. Анализ технологий создания программного обеспечения
1.1 Технология RAD - Rapid Application Development
Это концепция создания средств разработки программных продуктов,
уделяющая особое внимание быстроте и удобству программирования, созданию
технологического процесса, позволяющего программисту максимально быстро
создавать компьютерные программы. Практическое определение: RAD - это жизненный
цикл процесса проектирования, созданный для достижения более высокой скорости
разработки и качества ПО, чем это возможно при традиционном подходе к
проектированию. С конца XX века RAD получила широкое распространение и
одобрение. Концепцию RAD также часто связывают с концепцией визуального
программирования.
История:
Концепция RAD стала ответом на неуклюжие методы разработки программ
1970-х и начала 1980-х годов, такие как «модель водопада» (англ. Waterfall
model). Эти методы предусматривали настолько медленный процесс создания
программы, что зачастую даже требования к программе успевали измениться до
окончания разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин,
который в1980-х годах сформулировал основные принципы RAD, основываясь на идеях
Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу,
в которой детально изложил концепцию RAD и возможности её применения. В
настоящее время RAD становится общепринятой схемой для создания средств
разработки программных продуктов.
Назначение:предполагает, что разработка ПО осуществляется небольшой
командой разработчиков за срок порядка трех-четырех месяцев путем использования
инкрементного прототипирования с применением инструментальных средств
визуального моделирования и разработки. Технология RAD предусматривает активное
привлечение заказчика уже на ранних стадиях - обследование организации,
выработка требований к системе. Последнее из указанных свойств подразумевает
полное выполнение требований заказчика как функциональных, так и нефункциональных,
с учетом их возможных изменений в период разработки системы, а также получение
качественной документации, обеспечивающей удобство эксплуатации и сопровождения
системы. Это означает, что дополнительные затраты на сопровождение сразу после поставки
будут значительно меньше. Таким образом, полное время от начала разработки до
получения приемлемого продукта при использовании этого метода значительно
сокращается.
Применение:
Технологию RAD целесообразно применять, когда четко определены некоторые
приоритетные направления разработки проекта.
Необходимо выполнение проекта в сжатые сроки. Быстрое выполнение проекта
позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если
система проектируется долго, то весьма высока вероятность, что за это время
существенно изменятся фундаментальные положения, регламентирующие деятельность
организации, то есть, система морально устареет ещё до завершения её
проектирования.
Нечетко определены требования к ПО. В большинстве случаев заказчик весьма
приблизительно представляет себе работу будущего программного продукта и не
может четко сформулировать все требования к ПО. Требования могут быть вообще не
определены к началу проекта либо могут изменяться по ходу его выполнения.
Проект выполняется в условиях ограниченности бюджета. Разработка ведется
небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат
и позволяет вписаться в бюджетные ограничения.
Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять
пользователя рисовать картинки. RAD-технология дает возможность
продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала
проекта.
Возможно разбиение проекта на функциональные компоненты. Если
предполагаемая система велика, необходимо, чтобы её можно было разбить на
мелкие части, каждая из которых обладает четкой функциональностью. Они могут
выпускаться последовательно или параллельно (в последнем случае привлекается
несколько RAD-групп).
Низкая вычислительная сложность ПО.технология не является универсальной,
то есть её применение целесообразно не всегда. Например, в проектах, где
требования к программному продукту четко определены и не должны меняться,
вовлечение заказчика в процесс разработки не требуется и более эффективной
может быть иерархическая разработка (каскадный метод). То же касается проектов,
ПО, сложность которых определяется необходимостью реализации сложных
алгоритмов, а роль и объём пользовательского интерфейса невелик.
Основные принципы:
Принципы RAD технологии направлены на обеспечение трех основных её
преимуществ - высокой скорости разработки, низкой стоимости и высокого
качества. Достигнуть высокого качества программного продукта весьма непросто и
одна из главных причин возникающих трудностей заключается в том, что
разработчик и заказчик видят предмет разработки (ПО) по-разному.
Инструментарий должен быть нацелен на минимизацию времени разработки.
Создание прототипа для уточнения требований заказчика.
Цикличность разработки: каждая новая версия продукта основывается на
оценке результата работы предыдущей версии заказчиком.
Минимизация времени разработки версии, за счёт переноса уже готовых
модулей и добавления функциональности в новую версию.
Команда разработчиков должна тесно сотрудничать, каждый участник должен
быть готов выполнять несколько обязанностей.
Управление проектом должно минимизировать длительность цикла разработки.
Принципы RAD применяются не только при реализации, но и распространяются
на все этапы жизненного цикла, в частности на этап обследования организации,
построения требований, анализ и дизайн.
.2 Технология XP - Extreme Programming
Экстремальное программирование - одна из гибких методологий разработки
программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин
Фаулери другие.
Основные приёмы XP
Двенадцать основных приёмов экстремального программирования (по первому
изданию книги Extreme programming explained) могут быть объединены в четыре
группы:
Короткий цикл обратной связи (Fine-scale feedback)
Разработка через тестирование (Test-driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous integration)
Рефакторинг (Design improvement, Refactoring)
Частые небольшие релизы (Small releases)
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными
шаблонами проектирования (Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищенность программиста (Programmer welfare):
-часовая рабочая неделя (Sustainable pace, Forty-hour week)
Тестированиепредполагает написание автоматических тестов (программный
код, написанный специально для того, чтобы тестировать логику другого
программного кода). Особое внимание уделяется двум разновидностям тестирования:
юнит-тестирование модулей;
функциональное тестирование.
Разработчик не может быть уверен в правильности написанного им кода до
тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им
системы. Тесты модулей (юнит-тесты) позволяют разработчикам убедиться в том,
что каждый из них по отдельности работает корректно. Они также помогают другим
разработчикам понять, зачем нужен тот или иной фрагмент кода, и как он
функционирует - в ходе изучения кода тестов логика работы тестируемого кода
становится понятной, так как видно, как он должен использоваться. Тесты модулей
также позволяют разработчику без каких-либо опасений выполнять рефакторинг
(refactoring).
Функциональные тесты предназначены для тестирования функционирования
логики, образуемой взаимодействием нескольких (часто - довольно внушительного
размера) частей. Они менее детальны, чем юнит-тесты, но покрывают гораздо
больше - то есть, у тестов, которые при своём выполнении затрагивают больший
объём кода, шанс обнаружить какое-либо некорректное поведение, очевидно,
больше. По этой причине в промышленном программировании написание
функциональных тестов нередко имеет больший приоритет, чем написание
юнит-тестов.
Для XP более приоритетным является подход, называемый TDD (от англ.
test-driven development - разработка через тестирование). В соответствии с этим
подходом сначала пишется тест, который изначально не проходит (так как логики,
которую он должен проверять, ещё просто не существует), затем реализуется
логика, необходимая для того, чтобы тест прошел. TDD, в некотором смысле,
позволяет писать код, более удобный в использовании - потому что при написании
теста, когда логики ещё нет, проще всего позаботиться об удобстве будущей
системы.
Игра в планирование.
Основная цель игры в планирование - быстро сформировать приблизительный
план работы и постоянно обновлять его по мере того, как условия задачи
становятся всё более чёткими. Артефактами игры в планирование является набор
бумажных карточек, на которых записаны пожелания заказчика (customer stories),
и приблизительный план работы по выпуску следующих одной или нескольких небольших
версий продукта. Критическим фактором, благодаря которому такой стиль
планирования оказывается эффективным, является то, что в данном случае заказчик
отвечает за принятие бизнес-решений, а команда разработчиков отвечает за
принятие технических решений. Если не выполняется это правило, весь процесс
распадается на части.
Заказчик всегда рядом.
«Заказчик» в XP - это не тот, кто оплачивает счета, а конечный
пользователь программного продукта. XP утверждает, что заказчик должен быть всё
время на связи и доступен для вопросов.
Парное программирование.
Парное программирование предполагает, что весь код создается парами
программистов, работающих за одним компьютером. Один из них работает
непосредственно с текстом программы, другой просматривает его работу и следит
за общей картиной происходящего. При необходимости клавиатура свободно
передаётся от одного к другому. В течение работы над проектом пары не
фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде
имел хорошее представление обо всей системе. Таким образом, парное
программирование усиливает взаимодействие внутри команды.
Непрерывная интеграция.
Если выполнять интеграцию разрабатываемой системы достаточно часто, то
можно избежать большей части связанных с этим проблем. В традиционных методиках
интеграция, как правило, выполняется в самом конце работы над продуктом, когда
считается, что все составные части разрабатываемой системы полностью готовы. В
XP интеграция кода всей системы выполняется несколько раз в день, после того,
как разработчики убедились в том, что все тесты модулей корректно срабатывают.
Рефакторинг.
Рефакторинг (refactoring) - это методика улучшения кода без изменения его
функциональности. XP подразумевает, что однажды написанный код в процессе
работы над проектом почти наверняка будет неоднократно переделан. Разработчики
XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его.
Этот процесс называется рефакторингом. Отсутствие тестового покрытия
провоцирует отказ от рефакторинга в связи с боязнью поломать систему, что
приводит к постепенной деградации кода.
Частые небольшие релизы.
Версии (releases) продукта должны поступать в эксплуатацию как можно
чаще. Работа над каждой версией должна занимать как можно меньше времени. При
этом каждая версия должна быть достаточно осмысленной с точки зрения полезности
для бизнеса.
Чем раньше выпускается первая рабочая версия продукта, тем раньше
заказчик начинает получать за счёт неё дополнительную прибыль. Следует помнить,
что деньги, заработанные сегодня, стоят дороже, чем деньги, заработанные
завтра. Чем раньше заказчик приступит к эксплуатации продукта, тем раньше
разработчики получат от него информацию о том, что соответствует требованиям
заказчика. Эта информация может оказаться чрезвычайно полезной при планировании
следующего выпуска.
Простота проектирования.исходит из того, что в процессе работы условия
задачи могут неоднократно измениться, а значит, разрабатываемый продукт не
следует проектировать заблаговременно целиком и полностью. Попытка детально
спроектировать систему в самом начале работы является напрасной тратой времени.
XP предполагает, что проектирование - это настолько важный процесс, что его
необходимо выполнять постоянно в течение всего времени работы над проектом.
Проектирование должно выполняться небольшими этапами, с учётом постоянно
изменяющихся требований. В каждый момент времени следует пытаться использовать
наиболее простой дизайн, который подходит для решения текущей задачи, и менять
его по мере того, как условия задачи меняются.
Метафора системы.
Архитектура - это представление о компонентах системы и их взаимосвязях
между собой. Разработчикам необходимо проводить анализ архитектуры программного
обеспечения для того, чтобы понять, в каком месте системы необходимо добавить
новую функциональность, и с чем будет взаимодействовать новый компонент.
Метафора системы (system metaphor) - это аналог того, что в большинстве
методик называется архитектурой. Метафора системы даёт команде представление о
том, каким образом система работает в настоящее время, в каких местах
добавляются новые компоненты, и какую форму они должны принять.
Подбор хорошей метафоры облегчает для группы разработчиков понимание
того, каким образом устроена система. Иногда сделать это не просто.
Стандарты кодирования.
Все члены команды в ходе работы должны соблюдать требования общих
стандартов кодирования. Благодаря этому:
члены команды не тратят время на глупые споры о вещах, которые фактически
никак не влияют на скорость работы над проектом;
обеспечивается эффективное выполнение остальных практик.
Если в команде не используются единые стандарты кодирования,
разработчикам становится сложнее выполнять рефакторинг; при смене партнёров в
парах возникает больше затруднений; в общем и целом, продвижение проекта
затрудняется. В рамках XP необходимо добиться того, чтобы было сложно понять,
кто является автором того или иного участка кода, - вся команда работает
унифицировано, как один человек. Команда должна сформировать набор правил, а
затем каждый член команды должен следовать этим правилам в процессе
кодирования. Перечень правил не должен быть исчерпывающим или слишком объёмным.
Задача состоит в том, чтобы сформулировать общие указания, благодаря которым
код станет понятным для каждого из членов команды. Стандарт кодирования
поначалу должен быть простым, затем он может постепенно усложняться по мере
наработки опыта группой разработчиков. Не нужно тратить слишком много времени
на предварительную разработку стандарта.
Коллективное владение.
Коллективное владение означает, что каждый член команды несёт
ответственность за весь исходный код. Таким образом, каждый вправе вносить
изменения в любой участок программы. Парное программирование поддерживает эту
практику: работая в разных парах, все программисты знакомятся со всеми частями
кода системы. Важное преимущество коллективного владения кодом - в том, что оно
ускоряет процесс разработки, поскольку при появлении ошибки её может устранить
любой программист.
Право каждого программиста изменять код ведёт к риску появления ошибок,
вносимых программистами, которые считают, что знают, что делают, но не
рассматривают некоторые зависимости. Хорошо определённые юнит-тесты решают эту
проблему: если нерассмотренные зависимости порождают ошибки, то следующий
запуск юнит-тестов будет неудачным.
1.3 Технология MSF - Microsoft Solution Frame
Microsoft Solutions Framework (MSF) - методология разработки программного
обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический
опыт Microsoft и описывает управление людьми и рабочими процессами в процессе
разработки решения.представляет собой согласованный набор концепций, моделей и
правил.
Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт
к организации работающего над проектом персонала и его деятельности в целях
максимизации успешности проекта. Данная модель определяет ролевые кластеры, их
области компетенции и зоны ответственности, а также рекомендации членам
проектной группы, позволяющие им успешно осуществить свою миссию по воплощению
проекта в жизнь.
Модель проектной группы MSF разрабатывалась в течение нескольких лет и
возникла в результате осмысления недостатков пирамидальной, иерархической
структуры традиционных проектных групп.
В соответствии с моделью MSF проектные группы строятся как небольшие
многопрофильные команды, члены которых распределяют между собой ответственность
и дополняют области компетенций друг друга. Это дает возможность четко
сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое
видение проекта, стремление к воплощению его в жизнь, высокие требования к
качеству работы и желание самосовершенствоваться.
Как уже было сказано выше, проектная группа по MSF состоит из шести
ролевых кластеров, каждый из которых отвечает за:
· управление программой (program manager) - разработку архитектуры
решения, административные службы;
· разработку (developer) - разработку приложений и
инфраструктуры, технологические консультации;
· тестирование (QAE) - планирование, разработку тестов и
отчетность по тестам;
· управление выпуском (release manager) - инфраструктуру,
сопровождение, бизнес-процессы, выпуск готового продукта;
· удовлетворение заказчика (user experience) - обучение,
эргономику, графический дизайн, техническую поддержку;
· управление продуктом (product manager) - бизнес-приоритеты,
маркетинг, представительство интересов заказчика.
Наличие шести ролевых кластеров не означает, что количество членов
команды должно быть кратным шести - один человек может совмещать несколько
ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости
от размера проекта, его сложности и профессиональных навыков, требуемых для
реализации всех областей компетенции кластера. Минимальный коллектив по MSF
может состоять всего из трех человек. Модель не требует назначения отдельного
сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны
быть представлены все шесть качественных целей. Обычно, выделение как минимум
одного человека на каждый ролевой кластер обеспечивает полноценное внимание к
интересам каждой из ролей, но это экономически оправданно не для всех проектов.
Зачастую члены проектной группы могут объединять роли.
В малых проектных группах объединение ролей является необходимым. При
этом должны соблюдаться два принципа:
· Роль команды разработчиков не может быть объединена ни с
какой другой ролью.
· Избежание сочетания ролей, имеющих предопределенные конфликты
интересов.
Как и в любой другой командной деятельности, подходящая комбинация ролей
зависит от самих членов команды, их опыта и профессиональных навыков. На практике
совмещение ролей встречается нередко. И если проектная группа производит его
обдуманно и управляет связанными с таким объединением рисками, возникающие
проблемы будут минимальными.не предоставляет конкретных рецептов управления
проектами и не содержит объяснений разнообразных методов работы, которые
применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению
проектами, при котором:
· ответственность за управление проектом распределенная между
лидерами ролевых кластеров внутри команды - каждый член проектной группы
отвечает за общий успех проекта и качество создаваемого продукта.
· профессиональные менеджеры выступают в качестве консультантов
и наставников команды, а не выполняют функции контроля над ней - в эффективно
работающей команде каждый её член имеет необходимые полномочия для выполнения
своих обязанностей и уверен, что получит от коллег все необходимое.
Как следует из вышесказанного, одна из характерных особенностей MSF -
отсутствие должности менеджера проекта!
Модель проектной группы MSF предлагает разбиение больших команд (более 10
человек) на малые многопрофильные группы направлений (feature teams). Эти малые
коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме
того, когда ролевому кластеру требуется много ресурсов, формируются т. н.
функциональные группы (functional teams), которые затем объединяются в ролевые
кластеры.
Использование ролевых кластеров не подразумевает и не навязывает никакой
специальной структуры организации или обязательных должностей. Административный
состав ролей может широко варьироваться в разных организациях и проектных
группах. Чаще всего роли распределяются среди различных подразделений одной
организации, но иногда часть их отводится сообществу потребителей или внешним
по отношению к организации консультантам и партнерам. Ключевым моментом
является четкое определение работников, ответственных за каждый ролевой
кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть
много других факторов, определяющих успех или неудачу проекта, но структура
проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация
модели MSF с использованием лежащих в её основе принципов поможет сделать
проектные группы более эффективными и, как следствие, более успешными.
Модель процессов MSF (MSF process model) представляет общую методологию
разработки и внедрения IT решений. Особенность этой модели состоит в том, что
благодаря своей гибкости и отсутствию жестко навязываемых процедур она может
быть применена при разработке весьма широкого круга IT проектов. Эта модель
сочетает в себе свойства двух стандартных производственных моделей: каскадной
(waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена
ещё одним инновационным аспектом: она покрывает весь жизненный цикл создания
решения, начиная с его отправной точки и заканчивая непосредственно внедрением.
Такой подход помогает проектным группам сфокусировать свое внимание на
бизнес-отдаче (business value) решения, поскольку эта отдача становится
реальной лишь после завершения внедрения и начала использования продукта.
Процесс MSF ориентирован на «вехи» (milestones) - ключевые точки проекта,
характеризующие достижение в его рамках какого-либо существенного
(промежуточного либо конечного) результата. Этот результат может быть оценен и
проанализирован, что подразумевает ответы на вопросы: «Пришла ли проектная
группа к однозначному пониманию целей и рамок проекта?», «В достаточной ли
степени готов план действий?», «Соответствует ли продукт утвержденной
спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т.д.
Модель процессов MSF учитывает постоянные изменения проектных требований.
Она исходит из того, что разработка решения должна состоять из коротких циклов,
создающих поступательное движение от простейших версий решения к его
окончательному виду.
Модель процессов MSF тесно связана с базовыми принципами MSF,
рассмотренными выше. Вообще говоря, тремя особенностями модели процессов MSF
являются:
подход, основанный на фазах и вехах
итеративный подход
интегрированный подход к созданию и внедрению решений
Модель процессов включает такие основные фазы процесса разработки:
выработка концепции (Envisioning)
разработка (Developing)
стабилизация (Stabilizing)
внедрение (Deploying)
В рамках MSF программный код, документация, дизайн, планы и другие
рабочие материалы создаются, как правило, итеративными методами. MSF
рекомендует начинать разработку решения с построения, тестирования и внедрения
его базовой функциональности. Затем к решению добавляются все новые и новые
возможности. Такая стратегия именуется стратегией версионирования. Несмотря на
то, что для малых проектов может быть достаточным выпуск одной версии,
рекомендуется не упускать возможности создания для одного решения ряда версий.
С созданием новых версий эволюционирует функциональность решения.
Следует отметить, что MSF не навязывает использование других продуктов
Microsoft. Например, для организации процесса производства ПО можно
использовать MSF и при этом применять инструменты Borland, хотя будущая версия
MSF 4.0 будет жестко привязана к Microsoft Team System - новому
инструментальному средству Майкрософт для поддержки командной работы над
проектами.
Первая версия MSF появилась в 1994 году. Текущая версия - MSF 4.0 была
представлена в 2005 году. В данной версии произошло разделение методологии на
два направления: MSF for Agile Software Development и MSF for CMMI Process
Improvement.
Кроме этого, появилась роль архитектора и поддержка методологии в
инструменте - Visual Studio Team System.
.4 Технология ICONIX
Технология (или процесс) ICONIX, которую мы будем подробно рассматривать,
представляет собой нечто среднее между компактными и большими процессами.
Технология ICONIX, как и RUP, основана на прецедентах (вариантах
использования). В этом процессе тоже применяется язык моделирования UML
(Unified Modeling Language), однако основное внимание уделяется анализу требований.был
разработан Дугом Розенбергом в компании ICONIX SoftWare Engineering. Хотя
название процесса пишется прописными буквами, оно не является аббревиатурой.
В то время, когда UML разрабатывался тремя программистами-инженерами из
Rational SoftWare, которые пропагандировали ОО методы разработки ПО, Дуг
Розенберг создавал средство объектного моделирования Object Modeler. В 1992
году он разработал собственный процесс и назвал его ICONIX, взяв все лучшее из
оригинальных методик Буча, Рамбо и Якобсена.использует только 20% диаграмм UML
и больше подходит для небольших проектов по сравнению с RUP. Сложный процесс
разработки ПО упрощается до использования минимума шагов, ведущих к создания
ПО.
В отличие от довольно сложного RUP ICONIX не требует привлечения консультантов,
которые бы преобразовали этот процесс для конкретной компании. ICONIX
компактнее, легче в изучении. RUP полностью показывает весь ЖЦ разработки ПО,
ICONIX же фокусирует свое внимание на фазе анализа.
В настоящее время в процессе RUP на фазе анализа и дизайна применяется
ICONIX, которая является подключаемым модулем от Rational SoftWare.как и RUP
основан на прецедентах, является итеративным и инкрементным. Его основная
задача - найти ответ на вопрос: как максимально быстро добраться от прецедентов
к работающей системе, используя минимум промежуточных шагов.
Основные этапы процесса следующие:
• анализ требований
• предварительное проектирование
• детальное проектирование
• реализация
Процесс основан на построении минимального количества моделей, которые
отражают будущую систему. Это динамические и статические модели.
На этапе анализа:
. Проводится архитектурный анализ программного обеспечения
. Создаются модели прецедентов
. Создается модель пользовательского интерфейса
На этапе предварительного проектирования:
1. Дополняется и уточняется модель прецедентов
2. Создаются классы уровня предварительного проектирования,
участвующие в вариантах использования
. Создаются предварительные диаграммы классов для каждого варианта
использования
. Осуществляется распределение классов по пакетам
. Дополняется Модель предметной области
На этапе детального проектирования:
. Проектируется архитектура системы
. Создаются диаграммы последовательности
. Уточняются классы уровня детального проектирования и уточняются
диаграммы классов
. Создается общая диаграмма классов и диаграммы классов по пакетам
. Создается модель данных с атрибутами и связями (ER-диаграмма)
. Создается диаграмма состояний
На этапе реализации:
. Создаются диаграмма компонентов, если это необходимо
. Создается физическая база данных
. Создаются исходный код
Каждый этап завершается рецензирование, когда созданные диаграммы
обсуждаются с коллегами.
1.5 Обоснование выбора технологии создания ПО ИС для проекта
курсовой работы
Для проектирования ИС была выбрана технология ICONIX, т.к.:
- она подходит для относительно не больших проектов
- основной упор делает на анализе и проектирование ПО
- может использоваться небольшой группой разработчиков
- обеспечивает высокое качество разрабатываемого проекта ИС
При проектировании ИС используется объектно-ориентированный подход CASE - средство Rational Rose, язык визуального объектно-ориентированного
моделирования UML.
Основной
функцией Rational Rose является построение различного рода диаграмм и
спецификаций UML, которые определяют архитектуру системы, а также ее
статические и динамические аспекты. Rational Rose средство визуального
моделирования с использованием языка UML. Это язык
<#"787486.files/image001.gif">
Рисунок
1 - диаграмма вариантов использования
В
ходе детального изучения обязанностей сотрудников фирмы ДВИ была переработана и
представлена в Рисунок 2 - диаграмма вариантов использования.
Рисунок
2 - диаграмма вариантов использования
.3 Этап предварительного проектирования
На данном этапе выполняются следующие работы:
. Выполняется сценарий вариантов использования: выполняется
формирования вариантов использования (создаются варианты использования).
. Выполняется анализ вариантов использования (для каждого варианта
использования выделяются классы и строятся диаграммы классов).
Создадим сценарии для следующих вариантов использования:
учет читателей;
учет выдачи и приема документов;
Сценарий ВИ - конкретная последовательность действий, которая
иллюстрирует ВИ.
Сценарий состоит из следующих частей:
. Краткое описание того, что происходит в варианте использования
. Актер, инициирующий данный ВИ
. Предусловие - это условия, которые должны быть выполнены, прежде
чем вариант использования начнет выполняться сам
. Постусловие - это условия, которые всегда должны быть выполнены
после завершения ВИ. Предусловия и постусловия указывают порядок выполнения ВИ
системы. Не у всех ВИ бывают постусловия
. Основной поток событий - поэтапное описание того, что должно
происходить во время выполнения ВИ. Описание того, что будет делать система с
точки зрения пользователя. Основной поток событий описывает нормальный ход
событий (при отсутствии ошибок).
. Альтернативный поток событий - описывает отклонения от
нормального хода событий (ошибочные ситуации) и их обработку.
Разработаем ВИ для учёта автомобилей- просмотр справочника автомобилей.-
ввод нового автомобиля (марка, выводится из другого справочника).-
редактирование автомобиля.- удаление автомобиля.
Прототип
интерфейса представлен на Рисунок 3 - прототип интерфейса главной страницы ПО.
S1 - просмотр справочника автомобилей.
Прототип
интерфейса представлен на Рисунок 4 - прототип интерфейса просмотр справочника
автомобили.
Актер:
«Менеджер»
Предусловие:
…
Рисунок
3 - прототип интерфейса главной страницы ПО
Рисунок
4 - прототип интерфейса просмотр справочника автомобили
Таблица 1. Основной поток событий
|
Менеджер
|
Система
|
|
Выбирает команду просмотра
Справочника «Автомобили»
|
Открывает экранную форму
справочника «Автомобили». Загружает информацию об автомобилях из БД. (Е1).
|
|
Выбирает команду закрыть
справочник «Автомобили»
|
Закрывает форму.
|
Сценарий завершен.- ввод нового автомобиля (марка, выводится из другого
справочника)
Актер: «Менеджер»
Предусловие: открыт справочник «Автомобили»
Постусловие: открыт справочник «Автомобили»
Таблица 2. Основной поток событий
|
Менеджер
|
Система
|
|
Вводит команду добавить
автомобиль
|
Открывает экранную форму
«Добавить автомобиль».
|
|
Вводит данные в форму
|
|
|
Вводит информацию о марке
автомобиля
|
Открывается форма
справочника «Марки автомобилей» Загружаются сведения о марках из БД
|
|
Выбирает марку (Е2)
|
Закрывает форму справочник
«Марки автомобилей». Информация поступает в форму добавления автомобиля.
|
|
Сохраняет информацию (Е3)
|
Добавляет данные в
справочник
|
|
Закрывает форму «Добавление
автомобиля»
|
Закрывает форму «Добавления
автомобиля» Активирует справочник автомобилей Обновляет данные
|
Сценарий завершен.- редактирование автомобиля.
Краткое описание: …
Актер: «Менеджер»
Предусловие: наличие автомобиля, открыт справочник «Автомобили»
Постусловие: открыт справочник «Автомобили»
Таблица 3. Основной поток событий
|
Менеджер
|
Система
|
|
Выбирает автомобиль
|
|
|
Вводит команду
редактировать автомобиль
|
Открывает экранную форму
«Добавление автомобиля» Выводит информация из БД в форму
|
|
Меняет данные в форме
|
|
|
Меняет марку
|
Открывает форму справочника
«Марки автомобилей» Загружаются сведения о марках из БД
|
|
Выбирает марку (Е2)
|
Закрывает форму справочника
«Марки автомобиля» Информация поступает в форму редактирование Автомобиля
|
|
Сохраняет информацию (Е3)
|
|
|
Закрывает форму
|
Закрывает форму
«Редактирование автомобиля» Активирует форму справочника «Автомобили»
Обновляет данные
|
Сценарий завершен.- удаление автомобиля
Краткое описание:…
Предусловие: наличие автомобиля, открыт справочник «Автомобили»
Постусловие: открыт справочник «Автомобили»
Таблица 4. Основной поток событий
|
Менеджер
|
Система
|
|
Выбирает автомобиль
|
|
|
Вводит команду удалить
автомобиль
|
Выводит окно подтверждения
|
|
Подтверждает удаления (Е4)
|
Удаляет сведения о
автомобиле из БД (Е5) Активирует форму справочника «Автомобили» Обновляет
данные
|
Сценарий завершен.
Таблица 5. Альтернативный поток событий
|
Е1 - справочник автомобилей
пуст
|
Заполнить справочник
|
|
Е2 - отсутствует марка
|
Выполнить вариант
использования - «Добавить новую марку»
|
|
Е3 - Поля формы заполнены
неверно или пусты
|
Заполнить поля
|
|
Е4 - не подтверждает
удаления
|
Закрывает окно
подтверждения
|
|
Разработаем ВИ для учёта документов постановки автомобиля на стоянку
Прототип
интерфейса представлен на Рисунок 3 - прототип интерфейса главной страницы ПО.-
просмотр документов постановки автомобиля на стоянку.- ввод нового документа
постановки автомобиля на стоянку.- редактирование документа постановки
автомобиля на стоянку.- удаление документа постановки автомобиля на стоянку.-
просмотр документов постановки автомобилей на стоянку.
Прототип
интерфейса представлен на Рисунок 5 - прототип интерфейса просмотр документов
постановки автомобилей на стоянку.
Рисунок
5 - прототип интерфейса просмотр документов постановки автомобилей на стоянку
Актер: «Менеджер»
Предусловие: …
Постусловие: …
Таблица 6 Основной поток событий
|
Менеджер
|
Система
|
|
Выбирает команду просмотра
документов постановки автомобилей на стоянку
|
Открывает экранную форму
просмотра документов постановки автомобиля на стоянку Загружает информацию о
документах из БД. (Е1)
|
|
Выбирает команду закрыть
форму просмотра документов
|
Закрывает форму
|
Сценарий завершен.- создание нового документа постановки автомобиля на
стоянку (информация об автомобиле выводится из другого справочника, зона
стоянки выводится из другого справочника, стояночное место выводится из другого
справочника).
Актер: «Менеджер»
Предусловие: просмотр документов постановки
Постусловие: просмотр документов постановки
Таблица 7 Основной поток событий
|
Менеджер
|
Система
|
|
Вводит команду добавить
новый документ
|
Открывает экранную форму
«Добавить новый документ постановки автомобиля на стоянку»
|
|
Вводит данные в форму
|
|
|
Вводит информацию об
автомобиле
|
Открывается форма
справочника «Автомобили» Загружаются сведения об автомобилях из БД (Е2)
|
|
Выбирает автомобиль
|
Закрывает форму справочника
«Автомобили» Информация поступает в форму добавления нового документа
|
|
Вводит информацию о зоне
стоянки
|
Открывается форма
справочника «Зоны стоянки» Загружаются сведения о зонах стоянки из БД
|
|
Выбирает зону стоянки
|
Закрывает форму справочника
«Зоны стоянки» Информация поступает в форму добавления нового документа
|
|
Вводит информацию о
стояночном месте
|
Открывается форма
справочника «Стояночные места» Загружаются сведения о стояночных местах из БД
(Е3)
|
|
Выбирает стояночное место
|
Закрывает форму справочника
«Стояночные места» Информация поступает в форму добавления нового документа
|
|
Вводит информацию о
менеджере
|
Открывается форма
справочника «Менеджеры» Загружаются сведения о менеджерах из БД (Е4)
|
|
Выбирает менеджера
|
Закрывает форму справочника
«Менеджеры» Информация поступает в форму добавления нового документа
|
|
Сохраняет информацию (Е5)
|
Добавляет новый документ в
БД
|
|
Закрывает форму
|
Закрывает форму «Добавления
документа» Активирует просмотр документов постановки Обновляет дынные в форме
просмотра документов постановки автомобилей на стоянку
|
Сценарий завершен.- редактирование документа постановки автомобиля на
стоянку.
Краткое описание: …
Актер: «Менеджер»
Предусловие: Наличие документа, просмотр документов постановки
Постусловие: просмотр документов постановки
Таблица 8 Основной поток событий
|
Менеджер
|
Система
|
|
Выбирает документ
|
|
|
Вводит команду
редактировать документ
|
Открывает экранную форму
«Добавить новый документ постановки» Выводит информация из БД в форму
|
|
Меняет данные в форме
|
|
|
Меняет информацию об
автомобиле
|
Открывается форма
справочника «Автомобили» Загружаются сведения об автомобилях из БД (Е2)
|
|
Выбирает автомобиль
|
Закрывает форму справочника
«Автомобили» Информация поступает в форму «Добавление нового документа»
|
|
Меняет информацию о зоне
стоянки
|
Открывается форма
справочника «Зоны стоянки» Загружаются сведения о зонах стоянки из БД
|
|
Выбирает зону стоянки
|
Закрывает форму справочника
«Зоны стоянки» Информация поступает в форму «Добавление нового документа»
|
|
Меняет информацию о
стояночном месте
|
Открывается форма
справочника «Стояночные места» Загружаются сведения о стояночных местах из БД
(Е3)
|
|
Выбирает стояночное место
|
Закрывает форму справочника
«Стояночные места» Информация поступает в форму «Добавление нового документа»
|
|
Меняет информацию о
менеджере
|
|
Выбирает менеджера
|
Закрывает форму справочника
«Менеджеры» Информация поступает в форму «Добавление нового документа»
|
|
Сохраняет информацию (Е5)
|
обновляет данные в БД
|
|
Закрывает форму
|
Закрывает форму
«Редактирование документа» Активирует форму просмотр документов постановки
Обновляет дынные в форме просмотра документов постановки автомобилей на
стоянку
|
Сценарий завершен.- удаление документа постановки автомобиля на стоянку.
Краткое описание:…
Предусловие: наличие документа, просмотр документов постановки
Постусловие: просмотр документов постановки
Таблица 9 Основной поток событий
|
Менеджер
|
Система
|
|
Выбирает документ
|
|
|
Вводит команду удалить
документ
|
Выводит окно подтверждения
|
|
Подтверждает удаления (Е6)
|
Удаляет документ из БД (Е7)
Активирует форму просмотр документов постановки Обновляет дынные в форме
просмотра документов постановки автомобилей на стоянку
|
Сценарий завершен.
Таблица 10 Альтернативный поток событий
|
Е1 - документов нет
|
Создать документ (ы)
|
|
Е2 - справочник
«Автомобили» пуст
|
Заполнить справочник
«Автомобили»
|
|
Е3 - все места заняты
|
Выбрать другую зону стоянки
|
|
Е4 - справочник «менеджеры»
пуст
|
Заполнить справочник
«Менеджеры»
|
|
Е5 - Поля формы заполнены
неверно или пусты
|
Заполнить поля корректно
|
|
Е6 -не подтверждает
удаления
|
Закрывает окно
подтверждения
|
|
Е7 - ошибка удаления
|
|
Необходимо определить классы для каждого ВИ, для каждого класса
определить атрибуты. Каждому классу будет присвоен стереотип:
. граничные классы (Boundary) - посредник между внешним объектом (пользователем) и системой. Для
каждого ВИ определяется как минимум один граничный класс.
. Классы сущности(Entity)
- хранят информацию об основных абстракциях предметной области.
В будущем из этих классов будет реализована база данных
Затем
необходимо определить ассоциации (отношения) между классами, таким образом,
будет спроектирована диаграмма классов для ВИ учёт автомобилей, она
представлена на Рисунок 6 - Диаграмма классов для ВИ учёт автомобилей.
Рисунок
6 - Диаграмма классов для ВИ учёт автомобилей
Таким
образом, будет спроектирована диаграмма классов для ВИ учёт документов
постановки автомобилей на стоянку и общая диаграмма классов, как показано в
приложении 1 Рисунок 9 - диаграмма классов для ВИ учёт документов постановки
автомобилей на стоянку и Рисунок 10 - общая диаграмма классов.
2.4 Этап детального проектирования
На этапе детального проектирования ранее созданный проект программного
обеспечения дорабатывается новыми моделями с учётом сред реализации. На данном
этапе строятся следующие диаграммы:
. Диаграмма последовательности для каждого сформулированного из
подпотоков
. Общая диаграмма классов
. Модель предметной области уровня проектирования (схема
реляционной база данных для нашей реляционной системы)
Диаграммы последовательности предназначены для отображения точной логики
сценария ВИ, на ней последовательно проектируются те соотношения, которыми
классы обмениваются друг с другом. В дальнейшем эти сообщения могут быть
соотнесены с операциями класса. Таким образом, будет спроектирована диаграмма
последовательности для подпотока S1 ВИ учёт автомобилей, она представлена на
Рисунке 7.
Рисунок
7 - диаграмма последовательности для подпотока S1 ВИ учёт автомобилей
Диаграмма
последовательности строится для каждого подпотока событий, как показано в
приложение 1 Рисунок 11 - диаграмма последовательности для подпотока S2 - ввод
нового автомобиля ВИ учёт автомобилей.
2.5 ЕR - диаграмма
Построим
ER - диаграмму как представлено на Рисунок 8.
Рисунок
8 - ER - диаграмма
Заключение
В ходе выполнения работы были решены следующие задачи:
. Проанализированы технологии создания ИС
. Для создания проекта ИС курсовой работы была выбрана технология ICONIX
. По данной технологии был разработан проект ИС
Для решения поставленных задач применялось (CASE - средство) Rational Rose, язык
визуального объектно-ориентированного моделирования UML - Unified Modeling
Language.
Таким образом, цель курсовой работы достигнута.
iconix учет автомобиль программный
Список литературы
1. Вендров А.М. Практикум по проектированию программного
обеспечения экономических информационных систем: Учебное пособие. - М.: Финансы
и статистика, 2004. - 192 с.
2. Н. Елманова, С. Трепалин, А. Тенцлер. Delphi и
технология COM - СПБ.: Питер, 2003 - 698 с.
. Роберт Виейра. Программирование баз данных Microsoft
SQL Server 2005. Базовый
курс = Beginning Microsoft SQL
Server 2005 Programming. - М.: «Диалектика», 2007. - С. 832. - ISBN 0-7645-8433-2
4. Роберт Шелдон, Джоффрей Мойе MySQL: базовый курс = Beginning MySQL. - М.: «Диалектика», 2007. - С. 880. - ISBN 0-7645-7950-9.
5. С.В. Маклаков. Создание информационных систем с
ALLFusion Modelling Suite. М., 2003.
. С.В. Маклаков. ERwin и Bpwin. CASE-средства
разработки информационных систем. М., 1999.
. Вендров А.М. Один из подходов к выбору средств
проектирования баз данных и приложений. «СУБД», 1995, №3.
. Уэнди Боггс, Майкл Боггс. UML и Rational Rose 2002.
2004. - C. 346.
. Ильин В.В. Designer Реинжиниринг бизнес-процессов с
использованием ARIS Практика реального бизнеса. «Вильямс», 2008. - C. 456.
11. Гусева
О.А. Visual Basic. «Кон». 2008. - С. 390.
Приложение 1
Рисунок
9 - диаграмма классов для ВИ учёт документов постановки автомобилей на стоянку
Рисунок
10 - общая диаграмма классов
Рисунок
11 - диаграмма последовательности для подпотока S2 - ввод нового автомобиля ВИ
учёт автомобилей
Рисунок
12 - диаграмма последовательности для подпотока S4 - удаление автомобиля ВИ
учёт автомобилей
Рисунок
13 - диаграмма последовательности для подпотока S1 - просмотр документов
постановки автомобиля на стоянку
Рисунок
14 - диаграмма последовательности для подпотока S2 - ввод нового документа
постановки автомобиля на стоянку
Рисунок
15 - диаграмма последовательности для подпотока S4 - удаление документа
постановки автомобиля на стоянку