Проектирование системы автоматизации автостоянки

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НИЖЕГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИМ. Н.И. ЛОБАЧЕВСКОГО»

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ИНСТИТУТ ЭКОНОМИКИ И ПРЕДПРИНИМАТЕЛЬСТВА Курсовая работа по дисциплине

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

На тему «Проектирование системы автоматизации автостоянки»

Работу выполнил студент Группы 745/пи-9к А. А. Медведев Н. Новгород, 2014 г.

• Введение
• Глава 1. Анализ технологий создания программного обеспечения
• 1.1 Технология RAD — Rapid Application Development
• 1.2 Технология XP — Extreme Programming
• 1.3 Технология MSF — Microsoft Solution Frame
• 1.4 Технология ICONIX
• 1.5 Обоснование выбора технологии создания ПО ИС для проекта курсовой работы
• Глава 2. Проектирование системы при помощи технологии ICONIX
• 2.1 Описание предметной области
• 2.2 Этап анализа технологии ICONIX
• 2.3 Этап предварительного проектирования
• 2.4 Этап детального проектирования
• 2.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 целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта.

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

Нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.

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

Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта.

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

Низкая вычислительная сложность ПО.

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

Основные принципы:

Принципы RAD технологии направлены на обеспечение трех основных её преимуществ — высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.

Инструментарий должен быть нацелен на минимизацию времени разработки.

Создание прототипа для уточнения требований заказчика.

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

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

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

Управление проектом должно минимизировать длительность цикла разработки.

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

1.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):

40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

Тестирование

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

юнит-тестирование модулей;

функциональное тестирование.

Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей (юнит-тесты) позволяют разработчикам убедиться в том, что каждый из них по отдельности работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода, и как он функционирует — в ходе изучения кода тестов логика работы тестируемого кода становится понятной, так как видно, как он должен использоваться. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).

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

Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development — разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошел. TDD, в некотором смысле, позволяет писать код, более удобный в использовании — потому что при написании теста, когда логики ещё нет, проще всего позаботиться об удобстве будущей системы.

Игра в планирование.

Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части.

Заказчик всегда рядом.

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

Парное программирование.

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

Непрерывная интеграция.

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

Рефакторинг.

Рефакторинг (refactoring) — это методика улучшения кода без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Разработчики XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его. Этот процесс называется рефакторингом. Отсутствие тестового покрытия провоцирует отказ от рефакторинга в связи с боязнью поломать систему, что приводит к постепенной деградации кода.

Частые небольшие релизы.

Версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.

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

Простота проектирования.

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

Метафора системы.

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

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

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

Стандарты кодирования.

Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:

члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;

обеспечивается эффективное выполнение остальных практик.

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

Коллективное владение.

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

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

1.3 Технология MSF — Microsoft Solution Frame

Microsoft Solutions Framework (MSF) — методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

MSF представляет собой согласованный набор концепций, моделей и правил.

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

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

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

Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за:

· управление программой (program manager) — разработку архитектуры решения, административные службы;

· разработку (developer) — разработку приложений и инфраструктуры, технологические консультации;

· тестирование (QAE) — планирование, разработку тестов и отчетность по тестам;

· управление выпуском (release manager) — инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;

· удовлетворение заказчика (user experience) — обучение, эргономику, графический дизайн, техническую поддержку;

· управление продуктом (product manager) — бизнес-приоритеты, маркетинг, представительство интересов заказчика.

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

В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:

· Роль команды разработчиков не может быть объединена ни с какой другой ролью.

· Избежание сочетания ролей, имеющих предопределенные конфликты интересов.

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

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)

— планирование (Planning)

— разработка (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.

1.4 Технология ICONIX

Технология (или процесс) ICONIX, которую мы будем подробно рассматривать, представляет собой нечто среднее между компактными и большими процессами. Технология ICONIX, как и RUP, основана на прецедентах (вариантах использования). В этом процессе тоже применяется язык моделирования UML (Unified Modeling Language), однако основное внимание уделяется анализу требований.

ICONIX был разработан Дугом Розенбергом в компании ICONIX SoftWare Engineering. Хотя название процесса пишется прописными буквами, оно не является аббревиатурой.

В то время, когда UML разрабатывался тремя программистами-инженерами из Rational SoftWare, которые пропагандировали ОО методы разработки ПО, Дуг Розенберг создавал средство объектного моделирования Object Modeler. В 1992 году он разработал собственный процесс и назвал его ICONIX, взяв все лучшее из оригинальных методик Буча, Рамбо и Якобсена.

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

В отличие от довольно сложного RUP ICONIX не требует привлечения консультантов, которые бы преобразовали этот процесс для конкретной компании. ICONIX компактнее, легче в изучении. RUP полностью показывает весь ЖЦ разработки ПО, ICONIX же фокусирует свое внимание на фазе анализа.

В настоящее время в процессе RUP на фазе анализа и дизайна применяется ICONIX, которая является подключаемым модулем от Rational SoftWare.

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

Основные этапы процесса следующие:

* анализ требований

* предварительное проектирование

* детальное проектирование

* реализация

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

На этапе анализа:

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

2. Создаются модели прецедентов

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

На этапе предварительного проектирования:

1. Дополняется и уточняется модель прецедентов

2. Создаются классы уровня предварительного проектирования, участвующие в вариантах использования

3. Создаются предварительные диаграммы классов для каждого варианта использования

4. Осуществляется распределение классов по пакетам

5. Дополняется Модель предметной области

На этапе детального проектирования:

1. Проектируется архитектура системы

2. Создаются диаграммы последовательности

3. Уточняются классы уровня детального проектирования и уточняются диаграммы классов

4. Создается общая диаграмма классов и диаграммы классов по пакетам

5. Создается модель данных с атрибутами и связями (ER-диаграмма)

6. Создается диаграмма состояний

На этапе реализации:

1. Создаются диаграмма компонентов, если это необходимо

2. Создается физическая база данных

3. Создаются исходный код

Каждый этап завершается рецензирование, когда созданные диаграммы обсуждаются с коллегами.

1.5 Обоснование выбора технологии создания ПО ИС для проекта курсовой работы

Для проектирования ИС была выбрана технология ICONIX, т.к.:

— она подходит для относительно не больших проектов

— основной упор делает на анализе и проектирование ПО

— может использоваться небольшой группой разработчиков

— обеспечивает высокое качество разрабатываемого проекта ИС

При проектировании ИС используется объектно-ориентированный подход CASE — средство Rational Rose, язык визуального объектно-ориентированного моделирования UML.

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

Rational Rose — CASE-средство, предназначенное для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Преимущества средства:

· Содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах;

· В основе лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты;

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

· Средство Rational Rose функционирует на различных платформах;

· Способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования

Глава 2. Проектирование системы при помощи технологии ICONIX

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

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

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

Если автомобиль продается, то формируется документ продажи машины, в котором указывается данные о покупателе, данные о машине, дата и время продажи, данные о менеджере.

Система учета по требованию пользователя формирует и выдает на печать следующие отчеты:

— отчет по проданным автомобилям;

— отчет по зонированию стоянки.

2.2 Этап анализа технологии ICONIX

На данном этапе происходит:

— выявление основных абстракций предметной области

— точное формулирование функциональных требований к системе

— проектирование диаграммы вариантов использования

При анализе предметной области были выделены следующие основные абстракции:

— автомобиль

— зоны стоянки

— стояночное место

— покупатель

— менеджер

— документ постановки машины на стоянку

— документ продажи автомобиля

В ходе анализа были сформулированы следующие функциональные требования:

— система должна:

1. Вести учёт автомобиля (осуществлять ввод новой машины, просмотр, поиск сортировку, редактирование, удаление)

2. Вести учёт зон стоянки (осуществлять ввод новой зоны, просмотр, поиск сортировку, редактирование, удаление)

3. Вести учёт стояночных мест (осуществлять ввод нового места, просмотр, поиск сортировку, редактирование, удаление)

4. Вести учёт покупателей (осуществлять ввод нового покупателя, просмотр, поиск сортировку, редактирование, удаление)

5. Вести учёт менеджеров (осуществлять ввод нового менеджера, просмотр, поиск сортировку, редактирование, удаление)

6. Вести учёт документов постановки машины на стоянку (осуществлять ввод нового документа постановки машины на стоянку, просмотр, поиск сортировку, редактирование, удаление)

7. Вести учёт документов продажи автомобиля (осуществлять ввод нового документа продажи автомобиля, просмотр, поиск сортировку, редактирование, удаление)

8. Формировать отчёт по проданным автомобилям

9. Формировать отчёт по зонированию стоянки

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

Цель построение диаграммы — документирование функциональных требований (ДВИ) к системе.

На (ДВИ) отражаются две сущности языка UML, актёр и вариант использования (прецедент).

Актер (actor) — роль, которую играют пользователи системы во время взаимодействия с ней. Актерами могут быть как люди, так и другие автоматизированные системы.

Прецедент (use case) — это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера.

ДВИ будет построена по следующим правилам:

— не моделировать связи между актёрами

— не моделировать связи между вариантами использования

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

ДВИ для данного проекта представлена на Рисунок 1 — диаграмма вариантов использования.

Рисунок 1 — диаграмма вариантов использования

В ходе детального изучения обязанностей сотрудников фирмы ДВИ была переработана и представлена в Рисунок 2 — диаграмма вариантов использования.

Рисунок 2 — диаграмма вариантов использования

2.3 Этап предварительного проектирования

На данном этапе выполняются следующие работы:

1. Выполняется сценарий вариантов использования: выполняется формирования вариантов использования (создаются варианты использования).

2. Выполняется анализ вариантов использования (для каждого варианта использования выделяются классы и строятся диаграммы классов).

Создадим сценарии для следующих вариантов использования:

учет читателей;

учет выдачи и приема документов;

Сценарий ВИ — конкретная последовательность действий, которая иллюстрирует ВИ.

Сценарий состоит из следующих частей:

1. Краткое описание того, что происходит в варианте использования

2. Актер, инициирующий данный ВИ

3. Предусловие — это условия, которые должны быть выполнены, прежде чем вариант использования начнет выполняться сам

4. Постусловие — это условия, которые всегда должны быть выполнены после завершения ВИ. Предусловия и постусловия указывают порядок выполнения ВИ системы. Не у всех ВИ бывают постусловия

5. Основной поток событий — поэтапное описание того, что должно происходить во время выполнения ВИ. Описание того, что будет делать система с точки зрения пользователя. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок).

6. Альтернативный поток событий — описывает отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

Разработаем ВИ для учёта автомобилей

S1 — просмотр справочника автомобилей.

S2 — ввод нового автомобиля (марка, выводится из другого справочника).

S3 — редактирование автомобиля.

S4 — удаление автомобиля.

Прототип интерфейса представлен на Рисунок 3 — прототип интерфейса главной страницы ПО.

S1 — просмотр справочника автомобилей.

Прототип интерфейса представлен на Рисунок 4 — прототип интерфейса просмотр справочника автомобили.

Актер: «Менеджер»

Предусловие: …

Постусловие: …

Рисунок 3 — прототип интерфейса главной страницы ПО

Рисунок 4 — прототип интерфейса просмотр справочника автомобили

Таблица 1. Основной поток событий

Сценарий завершен.

S2 — ввод нового автомобиля (марка, выводится из другого справочника) Актер: «Менеджер»

Предусловие: открыт справочник «Автомобили»

Постусловие: открыт справочник «Автомобили»

Таблица 2. Основной поток событий

Сценарий завершен.

S3- редактирование автомобиля.

Краткое описание: …

Актер: «Менеджер»

Предусловие: наличие автомобиля, открыт справочник «Автомобили»

Постусловие: открыт справочник «Автомобили»

Таблица 3. Основной поток событий

Сценарий завершен.

S4 — удаление автомобиля Краткое описание:…

Предусловие: наличие автомобиля, открыт справочник «Автомобили»

Постусловие: открыт справочник «Автомобили»

Таблица 4. Основной поток событий

Сценарий завершен.

Таблица 5. Альтернативный поток событий

Разработаем ВИ для учёта документов постановки автомобиля на стоянку Прототип интерфейса представлен на Рисунок 3 — прототип интерфейса главной страницы ПО.

S1 — просмотр документов постановки автомобиля на стоянку.

S2 — ввод нового документа постановки автомобиля на стоянку.

S3 — редактирование документа постановки автомобиля на стоянку.

S4 — удаление документа постановки автомобиля на стоянку.

S1 — просмотр документов постановки автомобилей на стоянку.

Прототип интерфейса представлен на Рисунок 5 — прототип интерфейса просмотр документов постановки автомобилей на стоянку.

Рисунок 5 — прототип интерфейса просмотр документов постановки автомобилей на стоянку

Актер: «Менеджер»

Предусловие: …

Постусловие: …

Таблица 6 Основной поток событий

Сценарий завершен.

S2 — создание нового документа постановки автомобиля на стоянку (информация об автомобиле выводится из другого справочника, зона стоянки выводится из другого справочника, стояночное место выводится из другого справочника).

Актер: «Менеджер»

Предусловие: просмотр документов постановки Постусловие: просмотр документов постановки Таблица 7 Основной поток событий

Сценарий завершен.

S3- редактирование документа постановки автомобиля на стоянку.

Краткое описание: …

Актер: «Менеджер»

Предусловие: Наличие документа, просмотр документов постановки Постусловие: просмотр документов постановки Таблица 8 Основной поток событий

Сценарий завершен.

S4 — удаление документа постановки автомобиля на стоянку.

Краткое описание:…

Предусловие: наличие документа, просмотр документов постановки Постусловие: просмотр документов постановки Таблица 9 Основной поток событий

Сценарий завершен.

Таблица 10 Альтернативный поток событий

Необходимо определить классы для каждого ВИ, для каждого класса определить атрибуты. Каждому классу будет присвоен стереотип:

1. граничные классы (Boundary) — посредник между внешним объектом (пользователем) и системой. Для каждого ВИ определяется как минимум один граничный класс.

2. Классы сущности (Entity) — хранят информацию об основных абстракциях предметной области.

В будущем из этих классов будет реализована база данных Затем необходимо определить ассоциации (отношения) между классами, таким образом, будет спроектирована диаграмма классов для ВИ учёт автомобилей, она представлена на Рисунок 6 — Диаграмма классов для ВИ учёт автомобилей.

Рисунок 6 — Диаграмма классов для ВИ учёт автомобилей

Таким образом, будет спроектирована диаграмма классов для ВИ учёт документов постановки автомобилей на стоянку и общая диаграмма классов, как показано в приложении 1 Рисунок 9 — диаграмма классов для ВИ учёт документов постановки автомобилей на стоянку и Рисунок 10 — общая диаграмма классов.

2.4 Этап детального проектирования

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

1. Диаграмма последовательности для каждого сформулированного из подпотоков

2. Общая диаграмма классов

3. Модель предметной области уровня проектирования (схема реляционной база данных для нашей реляционной системы) Диаграммы последовательности предназначены для отображения точной логики сценария ВИ, на ней последовательно проектируются те соотношения, которыми классы обмениваются друг с другом. В дальнейшем эти сообщения могут быть соотнесены с операциями класса. Таким образом, будет спроектирована диаграмма последовательности для подпотока S1 ВИ учёт автомобилей, она представлена на Рисунке 7.

Рисунок 7 — диаграмма последовательности для подпотока S1 ВИ учёт автомобилей Диаграмма последовательности строится для каждого подпотока событий, как показано в приложение 1 Рисунок 11 — диаграмма последовательности для подпотока S2 — ввод нового автомобиля ВИ учёт автомобилей.

2.5 ЕR — диаграмма Построим ER — диаграмму как представлено на Рисунок 8.

Рисунок 8 — ER — диаграмма

Заключение

В ходе выполнения работы были решены следующие задачи:

1. Проанализированы технологии создания ИС

2. Для создания проекта ИС курсовой работы была выбрана технология ICONIX

3. По данной технологии был разработан проект ИС

Для решения поставленных задач применялось (CASE — средство) Rational Rose, язык визуального объектно-ориентированного моделирования UML — Unified Modeling Language.

Таким образом, цель курсовой работы достигнута.

iconix учет автомобиль программный

1. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учебное пособие. — М.: Финансы и статистика, 2004. — 192 с.

2. Н. Елманова, С. Трепалин, А. Тенцлер. Delphi и технология COM — СПБ.: Питер, 2003 — 698 с.

3. Роберт Виейра. Программирование баз данных 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.

6. С. В. Маклаков. ERwin и Bpwin. CASE-средства разработки информационных систем. М., 1999.

7. Вендров А. М. Один из подходов к выбору средств проектирования баз данных и приложений. «СУБД», 1995, № 3.

8. Уэнди Боггс, Майкл Боггс. UML и Rational Rose 2002. 2004. — C. 346.

9. Ильин В. В. Designer Реинжиниринг бизнес-процессов с использованием ARIS Практика реального бизнеса. «Вильямс», 2008. — C. 456.

10. Алексей Ковязин, Сергей Востриков «Мир InterBase. 3-е издание» 2005. C. 496.

11. Гусева О. А. Visual Basic. «Кон». 2008. — С. 390.

Приложение 1

Рисунок 9 — диаграмма классов для ВИ учёт документов постановки автомобилей на стоянку

Рисунок 10 — общая диаграмма классов

Рисунок 11 — диаграмма последовательности для подпотока S2 — ввод нового автомобиля ВИ учёт автомобилей

Рисунок 12 — диаграмма последовательности для подпотока S4 — удаление автомобиля ВИ учёт автомобилей

Рисунок 13 — диаграмма последовательности для подпотока S1 — просмотр документов постановки автомобиля на стоянку

Рисунок 14 — диаграмма последовательности для подпотока S2 — ввод нового документа постановки автомобиля на стоянку

Рисунок 15 — диаграмма последовательности для подпотока S4 — удаление документа постановки автомобиля на стоянку