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

Главная

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

Проектирование и реализация мобильной версии приложения учета и движения товаров на базе платформы Android и языка программирования Java. Создание таблиц базы данных. Взаимодействие объектов и экранные формы. Способы идентификации классов анализа.


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Интенсивное развитие программного обеспечения в сочетании с быстрорастущим рынком смартфонов приблизило общество к качественно новому рубежу, когда информационные технологии будут определять и обеспечивать развитие общества. Сейчас уже невозможно представить ни один сегмент бизнеса без использования программного обеспечения и современных технологий, а с появлением на рынке смартфонов использовать и внедрять новые технологии стало быстрее и удобнее.
В самом широком смысле мобильное приложение учета товаров представляет собой программное приложение, функции которого состоят в учете товаров, которые имеются на фирме, добавлении новых товаров, просмотре статистики, предоставлении пользователям удобного и легко осваиваемого интерфейса и все это с помощью обычного смартфона. Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру. В современном мире банки и базы данных стали неотъемлемым основным компонентом любой информационной системы организаций, учреждений, министерств и т.д. Классическими примерами информационных систем являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах, информационные системы обучения и тестирования, системы расписаний и т.д.
С использованием Интернет технологий появилась возможность неограниченного и очень удобного движения и учета товаров. Каждый сотрудник предприятия, либо владелец могут в любой момент времени получить самую актуальную информацию в любом месте, где есть интернет. Эти преимущества способствовали внедрению информационных технологий в традиционную модель бизнеса на предприятиях.
У каждого предприятия имеются сотрудники, поставщики и клиенты. Сотрудники добавляют товары в предварительно созданные категории товаров, имеют под рукой текущее количество товаров, количество проданных товаров и товаров которые закончились. Также регистрируют поставщиков и клиентов.
Очень важный фактор - доступность актуальной информации по товарам балансу компании и существующим поставщикам. Каждый сотрудник с помощью смартфона в любое время может видеть всю нужную ему информацию по товарам, при этом без необходимости ехать в офис, либо использовать компьютер.
В нашу информационную эпоху уже ни у кого не вызывает сомнения, что эффективно вести документацию и учет при помощи одной ручки и бумаги невозможно. Однако если программ, предназначенных для повышения эффективности труда менеджера или бухгалтера на рынке сегодня более чем достаточно, то аналогичных технических разработок, для смартфонов очень мало.
В данном дипломном проекте разработано мобильная версия приложения учета и движения товаров на фирме на базе платформы Android, которое предоставит пользователю возможность добавить подробную информацию о товарах, производителях и заказчиках фирмы; производить поиск нужных товаров по существующей базе в системе; видеть состояние дел фирмы посредством статистики.
В настоящей пояснительной записке описывается процесс проектирования и создания мобильной версии приложения «Учет и движение товаров на фирме». Она состоит из следующих глав:
- моделирование и инструментарий - выбор инструментов для разработки приложения и моделирование структуры базы данных и архитектуры приложения;
- реализация программного обеспечения - описание структуры приложения;
- тестирование программного обеспечения - описание тестов, проводимых над приложением;
- определение экономической эффективности разработки программного обеспечения;
Дипломный проект выполнен с учётом указаний и требований к выполнению дипломного проекта.
1. ПРЕДМЕТ РАЗРАБОТКИ В КОНТЕКСТЕ AS-IS И TO-BE
На сегодняшний день почти каждое предприятие или фирма использует в своей работе всевозможные информационные системы или приложения для автоматизации рабочего процесса. Исследования показывают, что одна часть из них является универсальными готовыми системами, а другая - узкоспециализирована и привязана к конкретному предприятию, фирме. Эти системы отличаются между собой сферой применения, технологиями реализации, уровнем достижимости и открытости. Одними из лучших мобильных приложений в этой сфере являются «1С: Управление небольшой фирмой», «Учет товара» и другие.
Рассмотрим приложение «1С: Управление небольшой фирмой», которое является комплексным решением для автоматизации учета товаров на фирме. «1С: Управление небольшой фирмой» позволяет эффективнее организовать учет. Система позволяет найти требуемую информацию о товарах, посмотреть статистику либо добавить новый товар в считанные секунды.
Для управления учебным контентом и заданиями в состав Class Server входит клиентское программное обеспечение, которое устанавливается на android устройство и позволяет:
­ поступления товаров, продажа и инвентаризация;
­ печатная форма Расходная накладная;
­ отчеты по продаже и остаткам товаров;
На рынке мобильных разработок программного обеспечения для учета товаров на фирме доминируют простейшие системы учета, обладающие следующим функционалом:
Основными недостатками таких систем являются невозможность эффективной работы с большим количеством товаров и их абсолютная хаотическая расположенность в программе. Товары хранятся хаотично и не принадлежат никакой категории. Если на предприятии существует много товаров, найти нужные очень затруднительно.
Разрабатываемое мобильное приложение для учета и движения товаров на фирме позволит:
­ максимально облегчить и упростить процесс учета и движения товаров на фирме с помощью смартфона на базе Android;
­ повысить эффективность сотрудников, вся информация о товарах, клиентах и поставщиках хранится в одном месте, сотрудникам не нужно искать нужную информацию в разных местах;
­ сэкономить денег предприятию на учете и ведению статистики, все под рукой в смартфоне;
­ легкий интерфейс, позволяющий в очень короткий срок разобраться с приложением любому сотруднику фирмы;
­ полная безопасность данных от посторонних глаз. Вход в приложение доступен только по паролю;
­ полная безопасность данных от посторонних глаз. Вход в приложение доступен только по паролю;
­ нет проблем с переносимостью данных. Данные хранятся на хостинге в интернете. При смене смартфона, просто необходимо снова скачать приложение и данные о товарах снова будут доступны сотруднику;
Каждый пользователь, зарегистрированный в системе, автоматически получает в свое распоряжение персональное пространство, на котором он может публиковать как личные документы, доступные только ему, так и выкладывать информацию для общего использования, предоставляя доступ к ней отдельным пользователям/группам пользователей.
Одним из главных минусов данной системы, как и многих аналогичных систем, является трудоемкость настройки с её параметрами и возможностями, но в целом «1С: Управление небольшой фирмой» представляет собой мощную и удобную, хорошо интегрируемую комплексную систему управления учебным процессом.
«Учет товара» - это система позволяющая вести учет товаров со стандартным функционалом и настройками. Система может применяться в небольших фирмах.
­ назначение цен и скидок на товары;
Недостатки - приложение не развивается и содержит недоработки.
Таблица 1.1 - анализ свободно распространяемых систем обучения
AS-IS - модель «как есть», модель существующего состояния организации. Данная модель позволяет систематизировать протекающие в данный момент процессы, а также используемые информационные объекты. На основе этого выявляются узкие места в организации и взаимодействии бизнес-процессов, определяется необходимость тех или иных изменения в существующей структуре.
На этапе построения модели AS-IS важным считается строить максимально приближенную к действительности модель, основанную на реальных потоках процессов, а не на их идеализированном представлении.
На основе анализа текущих процессов организации учета товаров на фирме была создана следующая AS-IS модель, которая позволяет выделить и систематизировать процессы, протекающие в данной системе при её функционировании. Главная контекстная диаграмма данной модели приводится на рисунке 1.1.
Рисунок 1.1 - Главная контекстная диаграмма (модель AS-IS)
Для более детального понимания логики бизнес-процессов, протекающих в текущей проблемной области разработанная выше контекстная диаграмма была разбита на три следующих процесса:
­ зачисление и регистрация товаров;
Декомпозиция контекстной диаграммы представлена на рисунке 1.2.
На диаграмме прослеживаются этапы процесса обучения: в начале происходит регистрация поставщика. Поставщик поставляет товары. Далее сотрудник, заведующий складом, регистрирует товары и оформляет заказы от клиентов.
Для детального понимания процесса «Регистрация поставщика» он разбивается на следующие три процесса:
Декомпозиция процесса «Регистрация поставщика» приводится на рисунке 1.3.
Рисунок 1.2 - Декомпозиция контекстной диаграммы
Рисунок 1.3 - Декомпозиция процесса «Регистрация поставщика»
Для детального понимания процесса «Зачисление и регистрация товара» он разбивается на следующие два процесса:
3) распределение товара по категориям;
Декомпозиция процесса «Зачисление и регистрация товара» приводится на рисунке 1.4.
Рисунок 1.4 - Декомпозиция процесса «Зачисление и регистрация товара»
Модель TO-BE («как должно быть») создается на основе AS-IS, с устранением недостатков в существующей организации бизнес-процессов, а так же с их совершенствованием и оптимизацией путём устранения выявленных на базе анализа AS-IS узких мест.
В соответствии с моделью TO-BE целью предмета разработки является упрощение организации учета и движения товаров на фирме. При этом предмет разработки должен обеспечить:
­ формирование базы данных, информацию о товарах клиентах и поставщиках;
­ средства доступа к этой базе для редактирования, добавления, удаления данных;
­ сортировку и фильтрацию данных, содержащихся в базе;
­ средства поиска нужной информации в базе данных;
­ удобный просмотр запрошенной информации.
На основе анализа созданной выше AS-IS модели процессов проблемной области была создана TO-BE модель, контекстная диаграмма которой приводится на рисунке 1.5.
Рисунок 1.5 - Главная контекстная диаграмма (модель TO-BE)
Для уточнения понимания логики бизнес-процессов, протекающих в текущей проблемной области контекстная диаграмма была разбита на четыре следующих процесса:
1) регистрация и поддержка пользователей;
Декомпозиция контекстной диаграммы представлена на рисунке 1.6.
Рисунок 1.6 - Декомпозиция контекстной диаграммы
Процесс «Регистрация и поддержка пользователей» для детального рассмотрения разбивается на четыре процесса:
1) регистрация студентов и преподавателей;
2) изменение личных и секретных данных регистрации;
Все процессы в результате своей деятельности обмениваются информацией с хранилищем данных: добавляют новую информацию, извлекают и модифицирую её, а также производят удаление ненужных данных, причём на данном этапе декомпозиции видно, что только «Администратор» может выполнять данные функции. Декомпозиция данного процесса приводится на рисунке 1.7.
Рисунок 1.7 - Декомпозиция процесса «Регистрация и поддержка пользователей»
Процесс «Работа с новыми поставками товаров» был разбит на следующие три процесса:
В качестве объектов, которыми оперируют процессы, выступают данные о товарах. Все процессы в результате своей деятельности обмениваются информацией с базой данных «Mysql»: добавляют, модифицируют и удаляют данные, причём вводимые данные должны удовлетворять требованиям, предъявляемые базой данных. Данные действия может выполнять «Администратор». Декомпозиция процесса «Работа с данными о товарах» приводится на рисунке 1.8.
Рисунок 1.8 - Декомпозиция процесса «Работа с данными по дисциплине»
Процесс «Работа с новыми заказами» был декомпозирован на следующие три процесса:
Все процессы в результате своей деятельности обмениваются информацией с базой данных «Mysql»: добавляют, модифицируют и удаляют данные, причём вводимые данные должны удовлетворять требованиям, предъявляемые базой данных. Данные действия может выполнять только «Администратор».
Декомпозиция процесса «Работа с данными» приводится на рисунке 1.9.
Рисунок 1.9 - Декомпозиция процесса «Работа с соответствующими данными»
Целью дипломного проекта является проектирование и реализация мобильной версии приложения учета и движения товаров на базе платформы Android, настройка и оптимизация параметров системы.
Основное назначение приложения - это частично автоматизировать учет и движение товаров на фирме. Такая система при высоком уровне реализации вполне способна оптимизировать и облегчить учет товаров на фирме, контролировать их движение на фирме и вести удобную статистику.
В приложении обеспечены права доступа для единственного пользователя - менеджера по товарам.
В общем случае система для всех пользователей должна предоставлять следующие возможности:
­ фильтрация и поиск товаров по различным критериям;
­ возможность изменения данных поставщика;
­ возможность изменения клиента фирмы;
­ возможность удаления клиента фирмы;
­ удобный, интуитивно понятный интерфейс с всевозможными подсказками.
При вводе и редактировании данных приложение должно контролировать правильность вводимой информации и по возможности исключать ситуации, которые могут привести к ошибочным действиям со стороны пользователей.
С целью облегчения поддержки и сопровождения приложения по учету и движению товаров, а также его дальнейшего расширения, он должен быть спроектирован и создан на основе трёхуровневой архитектуры построения программных систем, и иметь клиентскую и серверную части.
Серверная часть должна отвечать за доступ к данным и содержать бизнес-логику приложения. Клиентская часть в свою очередь должна реализовать пользовательский интерфейс приложения.
В качестве уровня доступа к данным необходимо использовать СУБД MySql, которая обеспечивает централизованное структурированное хранение всех данных системы, гарантируя их целостность и непротиворечивость, а также предоставляя множество сервисов низкого уровня для: чтения данных из хранилища, сохранения данных, изменения их структуры и прочее. На этом уровне должна быть создана база данных, которая будет хранить все данные системы. Реализация команд выборки данных, контроль целостности и непротиворечивости данных должна осуществляться с помощью соответствующих хранимых процедур, триггеров и других объектов, предоставляемых сервером.
Уровень бизнес-логики будет разворачиваться на сервере приложений и представлять собой ядро системы. На этом уровне должна быть сосредоточена большая часть бизнес-логики системы:
­ алгоритмы авторизации пользователя системы, система проверки прав доступа;
­ правила обработки данных, такие как: проверка правильности заполнения данных пользователем, проверка и организация взаимосвязей данных, правила движения информации внутри системы;
­ класс для подключения к базе данных и выполнения транзакций;
­ классы и алгоритмы для работы с таблицами базы данных и запуска выполнения соответствующих хранимых процедур и функций на сервере.
На уровень представления необходимо вынести простейшую бизнес-логику: интерфейс авторизации, алгоритмы шифрования, функции ввода и отображения данных, первичную проверку вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на рабочие станции клиента.
Система разработана под операционную систему Android в интегрированной среде разработки Android Studio и выше с использованием базовой технологии разработки современных Android приложений и языка программирования Java.
3.1 Выбор методологий моделирования и инструментария
Для визуального моделирования проблемной области было отдано предпочтение Rasional Rose компании Rational Software. Данное средство является простым и полностью интегрированным решением для разработки ПО, включая Интернет-решения. Rational Rose является стандартом дефакто среди инструментов проектирования приложений. Ни одно другое CASE-средство не предлагает такую широту и глубину решений как платформа Rational. С помощью Rational Rose можно визуализировать, изменять и тестировать модель.
Одно из неоспоримых преимуществ Rational Rose - обратное проектирование, поскольку разработчику и проектировщику важно увидеть перед изменениями уже работающую систему в нормальном графическом представлении. Как правило визуально-графический ряд оказывает куда большее воздействие нежели пролистывание технических заданий и программных текстов. Тем более что, проект, подвергшийся обратному проектированию может быть доработан и вновь сгенерирован (а впоследствии и скомпилирован). Rational Rose предоставляет для этого все необходимые средства.
Rational Rose является лидирующим инструментом визуального моделирования, поскольку он имеет все необходимые возможности - поддержку UML, многоязыковую поддержку итерационной разработки, полную поддержку командной разработки, компонентно-базированную разработку с поддержкой ведущих архитектур и таких компонентных моделей, как WinDNA и J2EE/SE/ME, легкость применения, оптимизированную интеграцию и многое другое.
Для проектирования и моделирования данных был использован инструментарий AllFusion ERwin Data Modeler (ERwin) компании Computer Associates. ERwin позволяет проектировать, документировать и сопровождать базы данных, хранилища данных и витрины данных (data marts). Основные аргументы и факты для разработчиков ПО в пользу использования данного инструментария:
­ поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД;
­ увеличивает производительность труда благодаря удобному интерфейсу и автоматизации рутинных процедур;
­ ERwin является стандартом де-факто;
­ позволяет повторно использовать компоненты созданных ранее моделей, а также использовать наработки других разработчиков. Повышается эффективность;
­ позволяет переносить структуру БД из СУБД одного типа в СУБД другой;
­ позволяет документировать структуру БД;
­ продукт можно использовать на всех стадиях жизненного цикла баз данных;
­ позволяет получить точную и наглядную информацию, где хранятся данные и как получить к ним доступ;
­ позволяет, используя визуальные средства, описать структуру БД, а затем автоматически сгенерировать файлы данных для любого типа СУБД.
3.2 Разработка диаграмм вариантов использования
Диаграмм вариантов использования описывает функциональное назначение системы, т.е. то, что система будет делать в процессе своего функционирования, и является исходной концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует следующие цели:
­ определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы, а также сформулировать общие требования к функциональному поведению проектируемой системы;
­ разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
­ подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру, т.е. каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
При анализе работы системы были выделены следующие действующие лица:
Были выделены следующие варианты использования:
­ просмотр соответствующей информации по каждому каталогу (включает в себя: товары, контрагенты, покупатели);
­ работа с данными (включает в себя: добавление, обновление и удаление товаров, а так же вывод статистики);
­ обновление и поддержка БД (включает в себя добавление, обновление и удаление соответствующих данных);
3.2.3 Диаграмма вариантов использования
Диаграммы вариантов использования являются необходимым средством при анализе требований, планировании и управлении итеративной разработкой. Работа с вариантами использования является одной из самых важных на стадии уточнения. Каждый вариант использования - это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.
При анализе задач и требований, поставленных при разработке информационно- учётной систему. Пользователи получают возможность выбрать категорию и просмотреть соответствующую информацию по ней. Пользователи могут осуществлять работу с информаций по соответствующей категории в системе (вносить, изменять, удалять), а также выводить статистику.
На данной диаграмме отображены основные варианты использования, необходимые разрабатываемой системе. Так, перед началом работы с системой необходимо зарегистрироваться, а затем пройти аутентификацию с целью определения пользователей. В случае утери данных для входа в систему предусмотрено возможность восстановить информацию. Пользователи-администраторы обладают всеми возможностями, которые предусмотрены в системе.
Рисунок 3.1 - Диаграмма вариантов использования
3.2.4 Описание вариантов использования
Вариант использования «Работа с данными по соответствующей категории»:
­ назначение: служит для добавления, удаления и обновления информации по соответствующей категории;
­ основной поток событий: выполняется, когда «Пользователь» начинает работу с системой:
1) система запрашивает требуемое действие (добавить, удалить, обновить информацию по соответствующей категории);
2) после того как «Пользователь» выбирает действие, начинает выполняться один из подчиненных потоков: добавление, обновление и удаление данных по категории.
- система запрашивает соответствующий раздел для добавления данных (товар, контрагент, покупатель);
- «Пользователь» выбирает соответствующий раздел;
- система запрашивает соответствующие данные для ввода;
- система проверяет корректность введенных данных;
- система сохраняет данные по соответствующему разделу в базу данных.
1) система запрашивает соответствующий раздел для обновления данных (товар, контрагент, покупатель);
2) «Пользователь» выбирает соответствующий раздел;
3) система запрашивает соответствующие данные для обновления;
4) «Пользователь» указывает соответствующие данные;
5) система выводит соответствующие данные для обновления;
6) «Пользователь» обновляет данные;
7) система проверяет корректность введённых данных и сохраняет их в базе данных;
1) система запрашивает соответствующий раздел для удаления данных (товар, контрагент, покупатель);
2) «Пользователь» выбирает соответствующий раздел;
3) система запрашивает соответствующие данные для удаления;
4) «Пользователь» указывает соответствующие данные;
­ альтернативные потоки: если добавление, удаление, обновление информации по каким либо причинам невозможно, то выводится соответствующее сообщение, содержащее причину ошибки и возможности ее разрешения:
1) добавление данных по категории: если данные для добавления некорректны, то система выводит предупреждающее сообщение о некорректности данных;
2) добавление данных отменено: если во время выполнения подчиненных потоков «Добавление данных по категории» «Пользователь» решил его отменить, то добавление отменяется, и основной поток начинается сначала;
3) обновление данных по категории: если данные для обновления некорректны, то система выводит предупреждающее сообщение о некорректности данных;
4) обновление данных отменено: если во время выполнения подчиненных потоков «Обновление данных по категории» «Пользователь» решил его отменить, то обновление отменяется, и основной поток начинается сначала;
­ предусловия: перед началом выполнения данного варианта использования «Пользователь» должен войти в систему;
­ постусловия: если вариант использования завершится успешно, то данные в базе будут обновлены соответствующим образом. Если же в процессе выполнения произошли какие-либо ошибки, то обновления в базе данных не сохраняются.
Вариант использования «Просмотр соответствующей информации»:
­ назначение: описывает просмотр всей информации по соответствующей дисциплине, содержащейся в базе данных;
­ основной поток событий: используется, когда «Пользователь» хочет просмотреть интересующую его информацию по дисциплине, предоставляемую системой:
1) «Пользователь» выбирает соответствующую категорию для работы;
2) система выводит соответствующие разделы выбранной категории;
3) «Пользователь» выбирает соответствующий раздел для просмотра;
4) система осуществляет поиск информации соответствующего раздела, которая должна отображаться на главной странице, а также предоставляет удобную навигацию по ресурсу;
5) «Пользователь» выбирает соответствующую ссылку интересующей его информации;
6) система осуществляет чтение из базы данных соответствующей информации, открывает соответствующую страницу и выводит интересующей информацию для просмотра пользователем;
­ альтернативный поток: в том случае, когда системе не удалось найти соответствующей информации по запросу «Пользователь» в базе данных, система выводит соответствующее сообщение (при этом выполнение варианта использования продолжается);
­ предисловия: перед началом выполнения данного варианта использования «Пользователь» должен войти в систему;
­ постусловия: если вариант использования выполнен успешно, «Пользователю» предоставляется для просмотра вся информация заданного раздела по выбранной дисциплине.
Вариант использования «Обновление и поддержка БД»:
­ назначение: служит для добавления, удаления и обновления информации, которая необходима для функционирования системы;
­ основной поток событий: выполняется, когда «Пользователь» начинает работу с системой:
1) система запрашивает требуемое действие (добавить, удалить, обновить информацию по соответствующей категории);
2) после того как «Пользователь» выбирает действие, начинает выполняться один из подчиненных потоков: добавление, обновление и удаление данных.
1) система запрашивает соответствующий раздел для добавления данных (товар, контрагент, покупатель);
2) «Пользователь» выбирает соответствующий раздел;
3) система запрашивает соответствующие данные для ввода;
5) система проверяет корректность введенных данных;
6) система сохраняет данные по соответствующему разделу в базу данных.
1) система запрашивает соответствующий раздел для обновления данных (товар, контрагент, покупатель);
2) «Пользователь» выбирает соответствующий раздел;
3) система запрашивает соответствующие данные для обновления;
4) «Пользователь» указывает соответствующие данные;
5) система выводит соответствующие данные для обновления;
6) «Пользователь» обновляет данные;
7) система проверяет корректность данных и сохраняет их в базе данных;
1) система запрашивает соответствующий раздел, для удаления данных (товар, контрагент, покупатель)
2) «Пользователь» выбирает соответствующий раздел;
3) система запрашивает соответствующие данные для удаления;
4) «Пользователь» указывает соответствующие данные;
­ альтернативные потоки: если добавление, удаление, обновление информации по каким либо причинам невозможно, то выводится соответствующее сообщение, содержащее причину ошибки и возможности ее разрешения:
1) добавление данных: если данные для добавления некорректны, то система выводит предупреждающее сообщение о некорректности данных;
2) добавление данных отменено: если во время выполнения подчиненных потоков «Добавление данных по категории», «Пользователь» решил его отменить, то добавление отменяется, и основной поток начинается сначала;
3) обновление данных: если данные для обновления некорректны, то система выводит предупреждающее сообщение о некорректности данных;
4) обновление данных отменено: если во время выполнения подчиненных потоков «Обновление данных по дисциплине», «Пользователь» решил его отменить, то обновление отменяется, и основной поток начинается сначала;
5) удаление данных: если удаляемые данные имеют связь с другими данными, то система выводит предупреждающее сообщение о невозможности удаления данных;
­ предусловия: перед началом выполнения данного варианта использования «Пользователь» должен войти в систему;
­ постусловия: если вариант использования завершится успешно, то данные в базе будут обновлены соответствующим образом. Если же в процессе выполнения произошли какие-либо ошибки, то обновления в базе не сохраняются.
3.3.1 Способы идентификации классов анализа
Центральное место в методологии объектно-ориентированного анализа и проектирования занимает разработка логической модели системы в виде диаграммы классов. Классы позволяют создавать логическое представление системы, на основе которого создается исходный код описанных классов.
Для идентификации классов и объектов используются:
­ классические подходы (опираются на классическую категоризацию и согласуются с требованиями предметной области);
­ анализ поведения (сосредотачивается на динамическом поведении как на первопричине объектов и классов);
­ анализ предметной области (выделение объектов операций и связи, которые эксперты предметной области считают важными);
­ анализ вариантов (образцов использования, сценариев, начинающихся с того, что пользователь системы имитирует операцию или последовательность операций);
­ CRC-карточки (компонента-ответственность-участники: на карточке ищут название компоненты снизу в левой половине - за что отвечает, а в правой - с кем сотрудничает);
­ неформальное описание (описывает задачу на простом английском языке, а затем существительные причисляют кандидатами в классы, а глаголы в имена операций);
­ структурный анализ (выполняет сам
Разработка мобильной версии приложения учета и движения товаров на фирме дипломная работа. Программирование, компьютеры и кибернетика.
Реферат по теме Жизнь в обществе. Навыки общения
Rainbow English 7 Контрольные Работы
Контрольная работа по теме Применение соединений кальция
Листопад Сочинение 4 Класс 10 Предложений
Курсовая работа: Технологія складу програм. Базові засоби мови C++
План Написания Сочинения 3 Класс
Контрольная Работа По Химии По Теме Алканы
Курсовая работа по теме Производство молочных продуктов в Беларуси
Курсовая работа по теме Перспективные методы производства стали
Реферат: Мир запорожцев в изображении Н.В.Гоголя. Скачать бесплатно и без регистрации
Деградация Современного Поколения Сочинение
Language Is The Dress Of Thought Эссе
Пособие по теме Теория искусственного интеллекта
Дипломная работа: Виды права собственности граждан
Реферат: Dover Beach Essay Research Paper In the
В Чем Заключается Смысл Жизни Эссе
Зачем Надо Учиться Сочинение Рассуждение
Эссе По Госзакупкам Скачать
Отчет по практике по теме Организация учета и отчетность в кредитном учреждении
Анализ Сочинений И Изложений
Автоматизация анализа прибыли коммерческого банка - Программирование, компьютеры и кибернетика курсовая работа
Виконання покарання у виді арешту - Государство и право реферат
Проектирование технологии печатных процессов для выпуска журнала "Avto" - Журналистика, издательское дело и СМИ курсовая работа