Что такое описание предметной области
Описание предметной области
СОДЕРЖАНИЕ
1.1 Описание предметной области. 4
1.2 Инструменты разработки. 4
2 Проектирование системы по учёту продажи компьютерных игр. 6
2.1 Концептуальное проектирование. 6
2.2 Логическая модель данных. 8
3 Описание технологии реализации. 11
3.1 Описание интерфейса. 14
3.2 Описание запросов и представлений данных. 14
3.3 Описание отчётов. 16
3.4 Описание справочной информации. 17
5 Описание применения. 19
Список используемых источников. 26
Приложение А – Листинг программы. 26
Приложение Б – DFD диаграмма. 27
Приложение В – Связи базы данных. 28
ВВЕДЕНИЕ
В настоящее время Интернет становиться все более развитой средой для осуществления коммуникаций с потребителями. В тоже время, существенным является и тот факт, что интернет становиться удобной и достаточно дешевой торговой площадкой.
Сегодня спектр онлайн торговли настолько обширен, что уже сложно представить, чего только нельзя купить через Интернет. Существуют Интернет-магазины канцтоваров, бытовых товаров, одежды, обуви, подарков – чего только нету. Даже продукты питания уже можно покупать в сети. И с каждым днем этот список становится все обширнее, а желающих приобретать товары через Интернет-магазины появляется больше и больше.
Не секрет, что сегодня компьютерные игры приобрели огромную популярность. И это не удивительно. Благодаря высоким технологиям и мастерству разработчиков в наши дни они настолько реалистичны, что игрок с головой окунается в виртуальный мир, словно становясь одним из героев игрового сюжета. Погружаясь в мир своих фантазий, человек отвлекается от бесконечных серых и унылых трудовых будней, забывает о проблемах, избавляется от усталости и стрессов. Сегодня покидать свой дом нет необходимости даже для того, чтобы купить игры для ПК или игровой приставки, достаточно лишь посетить магазин электронных товаров, размещенный на просторах всемирной паутины[1].
Огромное разнообразие представленных в каталоге продуктов способно удовлетворить даже самого искушенного пользователя. Здесь можно одним из первых приобрести самые интересные новинки, а также ключи активации к ним. Очень удобно также наличие различных способов оплаты. Покупку можно оплатить с помощью электронных платежей Webmoney, Яндекс.Деньги или Qiwi, почтовым переводом, банковскими картами.
В работе интернет магазина большую роль играет система управления. Система управления – информационная система или компьютерная программа, используемая для обеспечения и организации совместного процесса создания, редактирования и управления контентом.
Преимущества системы управления:
1. Облегчение получения пользователями актуальной информации о компании;
2. Упрощение процесса продаж;
3. Сокращение расходов на службы технической, информационной поддержки.
Таким образом основной целью курсовой работы является разработка программы осуществляющей управление базой данных интернет магазина.
АНАЛИЗ ЗАДАЧИ
Описание предметной области
Интернет-магазин — сайт, торгующий товарами посредством сети Интернет. Позволяет пользователям онлайн, в своём браузере, сформировать заказ на покупку, выбрать способ оплаты и доставки заказа.
Интернет-магазин обладает следующими преимуществами по сравнению с обычным магазином:
— интернет-магазин работает круглосуточно и каждый день, без перерыва на обед, без выходных и праздничных дней;
— доступ к товарам магазина имеет возможность получить любой покупатель, находящийся в любой точке планеты;
— в интернет магазин не требуется нанимать продавцов-консультантов, покупателю доступна вся подробная информация о товаре;
— интернет магазин не имеет ограничений на площадь. Можно разместить сколь угодно много товаров или описать любое количество услуг;
— срок и стоимость создания Интернет-магазина намного ниже, чем обычного магазина;
— для создания Интернет-магазина не требуется получения различных разрешений и лицензий. Его не будет проверять пожарный инспектор, санэпидемстанция и другие службы.
Электронной коммерцией называется покупка и продажа товаров, услуг или информации посредством компьютерных сетей, преимущественно Интернета. Являясь наиболее быстро развивающейся составляющей Интернет-технологий и других информационных технологий, электронная коммерция обеспечивает функциональность и новые способы ведения бизнеса, которыми невозможно пренебречь.
Электронная коммерция, безусловно, имеет большое будущее, так как электронные рынки более эффективны при создании новых товаров и услуг на основе поступающей информации, незаменимы в поиске клиентов и партнеров по всему земному шару.
Инструменты разработки
Для реализации программного продукта была выбрана система визуального программирования баз данных «Microsoft Access», так как она предоставляет наиболее широкие возможности для разработки приложений операционной системы «Windows».
Microsoft Access является настольной СУБД (система управления базами данных) реляционного типа. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственную базу данных, но и разрабатывать приложения, используя встроенные средства.
В отличие от других настольных СУБД, Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам, как и положено реляционной СУБД. К этим данным относится не только информация в таблицах, но и другие объекты базы данных, которые будут описаны ниже.
Для выполнения почти всех основных операций Access предлагает большое количество Мастеров (Wizards), которые делают основную работу за пользователя при работе с данными и разработке приложений, помогают избежать рутинных действий и облегчают работу неискушенному в программировании пользователю.
Особенности MS Access, отличающиеся от представления об «идеальной» реляционной СУБД.
Создание многопользовательской БД Access и получение одновременного доступа нескольких пользователей к общей базе данных возможно в локальной одноранговой сети или в сети с файловым сервером. Обычно для доступа к данным по сети с нескольких рабочих станций, файл
В плане поддержки целостности данных Access отвечает только моделям БД небольшой и средней сложности. В нем отсутствуют такие средства как триггеры и хранимые процедуры, что заставляет разработчиков возлагать поддержание бизнес логики БД на клиентскую программу.
В отношении защиты информации и разграничения доступа Access не имеет надежных стандартных средств. В стандартные способы защиты входит защита с использованием пароля БД и защита с использованием пароля пользователя. Снятие такой защиты не представляет сложности для специалиста[2].
MS Access предоставляет в распоряжение непрограммирующему пользователю разнообразные диалоговые средства, которые позволяют ему создавать приложения не прибегая к разработке запросов на языке SQL или к программированию макросов или модулей на языке VBA.
Access обладает широкими возможностями по импорту/экспорту данных в различные форматы, от таблиц Excel и текстовых файлов, до практически любой серверной СУБД через механизм ODBC.
Одним из средств программирования в Access является язык макрокоманд. Программы, созданные на этом языке, называются макросами и позволяют легко связывать отдельные действия, реализуемые с помощью форм, запросов, отчетов.
Получается что Microsoft Access это не только гибкая и простая в использовании СУБД, но и система для разработки работающих с базами данных приложений.
Описание предметной области.Постановка задачи.
Содержание:
Введение
Целью данной курсовой работы является рассмотрение сущности объектно-ориентированного проектирования информационной системы, средств её реализации и проектирование системы домашних финансов.
Для достижения поставленной цели в курсовой работе выполняется:
Таким образом, целью курсового проекта является повышение эффективности учета домашних финансов.
Повышение эффективности будет достигнуто за счет проектирования и последующего внедрения информационной системы домашних финансов.
1 Глава. Аналитическая часть
Описание предметной области. Постановка задачи.
Ведение учета домашних финансов позволяет решать следующие задачи:
— найти «лишние» деньги в своем кармане;
— понять причины проблем с деньгами, и найти варианты для их решения;
— комфортно жить, не боясь остаться без средств существования;
— выработать в себе привычки, которые будут вести вас к финансовой свободе;
— перестать жить в долг, полностью распоряжаться своей жизнью и своими деньгами;
— реализовать личные финансовые планы и цели;
— обеспечить своим детям финансовое благополучие.
Для того чтобы вести учет своих доходов и расходов, планировать достижение финансовых целей, контролировать кредиты и долги, создавать резервы и накопления, можно использовать следующие способы вести учет:
— на бумаге, в тетради, ежедневнике;
— в табличках MS Excel или в MS Word;
— в специализированном программном продукте, предназначенном для учета домашних финансов.
Учет на бумаге, в тетради, ежедневнике не требует наличия компьютера, не нужно обучаться работе на компьютере вообще и в программах учета в частности. Но данный способ не нагляден, велика вероятность ошибок, требует большого количества времени для ведения учета и анализа. Следовательно, этот способ наиболее актуален для регионов, где еще нет повсеместного использования компьютерной техники.
Учет в таблицах MS Excel или в MS Word позволяет не приобретать и не устанавливать специализированные программные продукты. Можно быстро и гибко настроить простой учет под свои нужды. Однако сложно разносторонне подойти к учету домашних финансов, выстраивать зависимости между таблицами, велика вероятность ошибок. Кроме того, сложно анализировать данные. Следовательно, этот способ наиболее актуален для ведения упрощенного учета домашних финансов, а также если нет возможности приобрести и(или) разбираться в специализированных программах.
Следовательно, целью данной курсовой работы является создание удобной в использовании ИС, выполненной по архитектуре клиент-сервер с обеспечением максимально возможной независимой клиентской части и БД «Учет домашних финансов», обеспечивающей хранение в электронной форме данных о доходах и расходах семьи.
При этом все модули клиентского приложения должны быть выполнены по единой схеме, что обеспечивает максимально простую модернизацию, а также поиск и исправление ошибок.
По форме единицы дохода выделяют:
В зависимости от государственного вмешательства:
Понятие “личный доход” охватывает все виды доходов, начисленных в денежных и натуральных формах (независимо от источников финансирования), включая денежные суммы, начисленные физическим лицам в соответствии с законодательством за не проработанное время (ежегодный отпуск, праздничные дни и т.п.). В рыночной экономике основными источниками личных доходов являются:
Первому из указанных источников соответствует доход в виде заработной платы и гонорара; третьему – дивиденды и проценты на капитал; четвертому – трансфертные платежи (пенсии, пособия, стипендии и т.д.), а также услуги предприятия своим работникам в виде медицинского обслуживания, повышения квалификации и т.д., пятому – продукты, возможности для отдыха, денежные средства от личных хозяйств.
Оплата труда выступает в качестве одного из основных составных элементов доходов населения. Доход от оплачиваемой работы составляет вознаграждение за труд работающих по найму, регулируемое договорной или контрактной системой отношений. Заработная плата еще подразделяется на номинальную и реальную, начисленную и фактически выплаченную, среднюю и минимальную.
Значительное влияние на получаемые населением доходы оказывают выплаты по программам социальной помощи со стороны государства. Сюда относятся пенсионное обеспечение, выплаты на содержание нетрудоспособных, различных пособий, стипендий студентам и учащимся. Их особенность в отличие от заработной платы, состоит в характере получения, независимом от количества и качества труда. Иначе говоря, трансферты – это операции, при которых товары, услуги или денежные средства предоставляются в одностороннем порядке без получения какого-либо эквивалента взамен. Социальные трансферты в натуральной форме состоят из товаров и нерыночных услуг, предоставляемых конкретным домашним хозяйствам из федерального и местных бюджетов и общественных организаций бесплатно.
Предлагаемые мероприятия по улучшению технологии решения задачи
Принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы.
Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира.
Понятие «объект» впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров.
С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal.
На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход «сущность-связь».
Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными се элементами являются:
Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:
Абстрагирование — это выделение существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы относительно дальнейшего рассмотрения и анализа. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования.
Инкапсуляция — это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого класса, скрыты от внешней среды.
Абстрагирование и инкапсуляция являются взаимодополняющими операциями: абстрагирование фокусирует внимание на внешних особенностях объекта, а инкапсуляция (или, иначе, ограничение доступа) не позволяет объектам-пользователям различать внутреннее устройство объекта.
Другими словами, можно сказать, что объектно-ориентированное программирование представляет собой метод программирования, который весьма близко напоминает наше поведение.
Недостатки ООП обуславливаются следующим:
2 глава. Проектная часть
2.1. Выбор средства для моделирования предметной области решаемой задачи
Анализ требований и сравнения программных аналогов представлен в таблице 1.
Таблица 1. Сравнение программных аналогов с учетом требований к проектируемой ЭИС
Требования к проектируемой системе
Oracle E-Business Suite
— статистический расчет потребности в продукции;
— статистический расчет производства продукции и учет созданной продукции;
— статистический учет реализованной продукции;
В вышеперечисленных программных продуктах присутствует избыточный функционал, который компании ОАО «УМПО» не нужен в силу специфики их бизнес-процессов.
Поэтому, например компании совсем не подойдут типовые продукты компании «SAP» или «Oracle» которые являются более типизированными и требуют изменения бизнеса компании-заказчика под свое ПО.
А собственная разработка на данных программных продуктах окажется нерентабельной в силу их дороговизны или отсутствия большого количества специалистов для поддержки эксплуатации и модернизации ЭИС в фазе сопровождения.
В нашем случае, становится очевидным тот факт, что нам необходимо программное обеспечение под заказ, так как автоматизируемая деятельность обладает специфическими особенностями собственных бизнес-процессов организации и конкретным назначением.
При выборе системы программирования были рассмотрены такие среды разработки приложений, как: «MS Visual FoxPro v.9.0»; «Microsoft Access v.11»; «1С: Предприятие 8.3».
MS Visual Fox Pro v.9.0
Достоинства данной среды разработки приложений следующие:
К недостаткам можно отнести следующее:
Microsoft Access v.11
Microsoft Access является полнофункциональной системой управления реляционной базой данных (СУРБД). Она обеспечивает все возможности определения, обработки и управления данными для работы с большими объемами информации.
Для обработки таблиц Access использует мощный язык баз данных – SQL (Structured Query Language – язык структурированных запросов). С помощью SQL можно получить набор данных, который необходим для решения конкретной задачи.
Microsoft Access предоставляет дополнительные средства разработки приложений баз данных, позволяющие не только обрабатывать данные в собственных структурах базы данных, но и в других распространенных форматах баз данных.
Вероятно, наиболее мощным качеством Access является возможность обработки данных из электронных таблиц, текстовых файлов, файлов dBase, Paradox и FoxPro, а также любых баз данных SQL, поддерживающих стандарт ODBC (Open Data Base Connectivity). Это означает, что Access можно использовать для создания Windows-приложений, способных обрабатывать данные как сетевого сервера SQL Server, так и базы данных, размещенной на головном компьютере.
Характеристики языков программирования представлены в таблице 2.
Таблица 2. Сравнительная характеристика языков программирования
Практика формирования требований в ИТ проектах от А до Я. Часть 5. Сущности предметной области и немного о стратегиях
VIII Определяем сущности предметной области
Все, что видим мы, — видимость только одна.
Далеко от поверхности мира до дна.
Полагай несущественным явное в мире,
Ибо тайная сущность вещей — не видна
Омар Хайям
Определив абстрактные хранилища продукта, мы получаем костяк для построения детальной модели данных. При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), логическую диаграмму (Logic Diagram) или диаграмму классов (Class diagram).
Цель этой группы работ — спроектировать модель хранилищ данных для использования в продукте, а также задокументировать сущности системы и способы их взаимодействия.
Теория проектирования такого типа диаграмм детально изложена в литературе, описывающей работу с UML. Например, эта тема очень удачно представлена в [11]. Поэтому остановлюсь лишь на некоторых аспектах, интересных на мой взгляд,.
На рисунке 8.1 изображен процесс формализации требований к целевой системе, дополненный подпроцессом определения сущностей предметной области.
Рисунок 8.1 — модель процесса определения сущностей предметной области
Для лучшего понимания природы Сущностей, моделируемых в системе, можно разделять их на следующие типы (ресурсов):
При принятии ращения о включении\исключении сущности в модель, необходимо руководствоваться одним из основного принципа «Системного анализа» — рассматривать совокупность элементов системы как одно целое или, рассуждая от обратного, запрет рассмотрения системы, как простое объединение ее элементов.
Еще один важный принцип, о котором не стоит забывать, это необходимость рассмотрения системы только в единении с окружающей ее средой. Это означает, что любую систему следует считать, некоторой частью более общей, глобальной системы.
1. Используем инкапсуляцию
У термина “Инкапсуляция” есть несколько трактовок и толкований. Мне нравится следующий вариант: Инкапсуляция — обеспечение доступности главного, выделение основного содержания путем помещения всего мешающего, второстепенного в некую условную капсулу (чёрный ящик). С точки зрения системного анализа — это элемент процесса абстрагирования.
Инкапсуляция, как известно, снижает «хрупкость» системы в целом, благодаря тому, что скрывает реализацию в объекте, локализуя распространение ошибок по всему продукту. Эта тема очень удачно изложена в книге [8]. Системы, построенные на этом принципе, легко модернизировать, безболезненно заменяя цельные конструкции. Также это очень эффективно при разработке отдельных модулей продукта разными командами.
Поэтому, разрабатывая структуру системы, старайтесь делить ее на самодостаточные модули, сервисы и т.п., отвечающие за определенную специализацию. Желательно, чтобы эти конструкции общались друг с другом посредством четко определенных интерфейсов.
Пример дробления модуля (части системы) на самодостаточные сегменты отражен на Рисунке 8.2. Для наглядного восприятия элементов системы и их взаимодействия, удобно пользоваться моделями, построенными на базе диаграммы «Архитектуры приложений».
Рис. 8.2 – Диаграмма фрагмента архитектуры модуля Управление исполнением проекта
Как видно из рисунка, модуль «Управление исполнением проекта» разбит на три сегмента (на диаграмме они изображены зелеными “пазлами”):
Поскольку мы выделили три сегмента в рассматриваемом модуле, то структуру данных также удобно проектировать на трех отдельных диаграммах. Элементы, спроектированные для одних сегментов, могут использоваться на диаграммах других сегментов (при этом они будут выделены подписью своего сегмента). В больших проектах это очень важный момент, позволяющий не «захлебнуться» в море спроектированных объектов.
На рисунке 8.3 приведен пример диаграммы классов сегмента «Управление обращениями заинтересованных лиц». Обратите внимание на классы: «Карта заданий» и «Статус карты задания», принадлежащие другому сегменту «Управление заданиями» из модуля «Управление исполнением проекта», рассмотренного нами выше. В данном случае — элементы, спроектированные на других диаграммах, обычно, имеют ссылку (подпись) на диаграмму родитель, она указывается в круглых скобках под названием элемента (класса).
Рис. 8.3 – Диаграмма классов сегмента Управление обращениями заинтересованных лиц
Если забежать вперед и глянуть ниже на Рисунок 8.5, то там приведен пример диаграммы классов для еще одного сегмента, описанного выше — «Формирование Шаблонов заданий».
Но следует помнить, что слишком сложная инкапсуляция приводит к снижению управляемости и сужает применяемость модуля. Об этом подробнее будет описано в следующей главе.
Таким образом, диаграммы «Архитектуры приложений» удобно использовать командой, в качестве отправной (верхней) точки абстракции, презентующей систему, каждый элемент которой является композицией, представленной, например, в виде диаграммы классов.
2. Эффективно используем декомпозицию бизнес сущностей
Декомпозиция, с точки зрения системного анализа — метод, по которому исследуемая система делится на подсистемы, задача на подзадачи и т.д., каждая из которых решается самостоятельно.
Декомпозиция, как процесс расчленения, позволяет рассматривать любую исследуемую систему как сложную, состоящую из отдельных взаимосвязанных подсистем, которые, в свою очередь, также могут быть расчленены на части. В качестве систем могут выступать не только материальные объекты, но и процессы, явления и понятия.
Проектируя сущность, старайтесь производить декомпозицию таким образом, чтобы если некоторые ее атрибуты меняются при разных событиях, то сущность разделялась на части, соответствующие этим событиям. Например, Сущность Требование может иметь атрибуты:
Рис. 8.4 – Диаграмма Классов Требования
Но не забывайте, используя этот прием, поддерживать девятое правило Кодда:
правило 9: Логическая независимость данных (Logical Data Independence):
Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.
В моей практике был случай, когда команда использовала таблицу с количеством полей — более 500. Разные события меняли только часть атрибутов, при этом записывался весь кортеж данных. Также очень расточительно ведение истории таких таблиц. При изменении одного поля, в таблице первоисточнике, в таблицу истории записывается новая строка со значениями всех атрибутов.
Но есть и обратная сторона медали. Если выполнять декомпозицию очень мелко, разбивая сложные сущности на множество простых с ограниченным количеством атрибутов, то в итоге, в большом проекте может получиться структура, которую тяжело охватить пониманием и соответственно тяжело обслуживать.
На мой взгляд, сложность структуры должна быть пропорциональна квалификации разработчиков и аналитиков, участвующих в проекте, а также возможностям инструментария, применяемого командой. Но при принятии позиции использования сложной структуры, даже если есть сильная команда, существует риск — рано или поздно лишиться ее (команды) или ее членов и тогда обслуживание и развитие продукта может стать затруднительным.
3. Используем адаптивные модели данных
Еще одна возможность снизить сложность, вызванную использованием большого количества сущностей, это применение механизмов универсализации обработки данных. Например, использование шаблонов, типовых сущностей, на основе которых создаются экземпляры. Такие модели называются адаптивными. Понятие управления с адаптацией подразумевает управление в системе с неполной априорной информацией об управляемом процессе, которое изменяется по мере накопления информации и применяется с целью улучшения качества работы системы.
Но здесь возникает та же самая дилемма: механизм универсализации не должен по сложности превосходить сложность структуры данных, которая могла бы использоваться без соответствующего механизма.
На момент проектирования системы необходимо определить перспективы развития функционала продукта. Если Вы видите, что некий механизм универсальной обработки на первой стадии будет задействован лишь частично, но у него есть перспективы дальнейшей загрузки, то такой механизм надо проектировать и строить сразу. Это позволит не только значительно компенсировать и сэкономить время при дальнейшем развитии продукта, но и уменьшить количество поддерживаемых сущностей.
Для снижения неизбежных затрат при проектировании и реализации адаптивных систем, необходимо учитывать следующие аспекты выбора решения:
Рис. 8.5 – Диаграмма Классов для Формирования Заданий по Шаблонам
Для единого восприятия терминов предметной области, пополняем наш Глоссарий:
Таким образом, типовая сущность «Шаблон карты заданий» (далее используем обозначение ШКЗ), предназначена для формирования на основании своей структуры, экземпляров сущности «Карта заданий». То есть, создав некий набор Шаблонов карт заданий, мы в дальнейшем сможем их использовать для быстрого заполнения новых Карт заданий на выполнение работ в проекте.
Теперь более детально о структуре ШКЗ. ШКЗ включает в себя, как агрегат, типовую сущность «Шаблон задний» и связывает ее экземпляры в один бизнес сценарий. В ШКЗ указывается Штатная позиция (должность) для определения лица, ответственного за процесс. Этот реквизит, при формировании на основании ШКЗ — новой Карты заданий, позволит автоматически определить пользователя, назначенного в текущий момент на должность в организации и претендующего на роль куратора группы заданий.
Следующая типовая сущность, упомянутая чуть выше, «Шаблон заданий», предназначенная для формирования по ней новых Заданий и характеризуется такими атрибутами: порядок выполнения заданий в ШКЗ, штатная позиция исполнителя задания, вид деятельности и (как бонус) перечень параметров, который можно настраивать. Параметры для шаблона заданий используются, как дополнительный механизм, расширяющий вариативность его применения и могут назначаться как входящими, так и исходящими. Параметры, как правило, связаны с другими сущностями системы и при выставлении заданий, подменяются, на текущие состояния (значения аргументов) этих сущностей. Дальше мы еще вернемся к теме параметров и поговорим о них более подробно.
Рассмотрим теперь то, ради чего мы затевали всю эту типизацию — сущности, экземпляры которых формируются на основании Типовых сущностей. Например, «Карта заданий» формируется на основании ШКЗ и предназначена для группировки заданий, выставляемых исполнителям, как связанных, пошаговых операций. Следующая такая Сущность — «Задания», которая формируются по типовой сущности – «Шаблон задания». Для Карты заданий автоматически может определиться ответственное лицо (об этом упоминалось выше при описании ШКЗ). По штатной позиции, при выставлении Задания, автоматически определяется исполнитель, назначенный для ее выполнения, в том числе может использоваться «агент-робот» системы. По виду задания, для робота или человека, может быть идентифицирована процедура, которую необходимо выполнить.
Таким образом, настроив в целевом продукте Типовые задания, мы получаем систему автоматического формирования Карт заданий исполнителям. Теперь, при возникновении необходимости настройки нового бизнес процесса, потребуется либо минимальное вмешательство разработчиков, либо оно вообще не потребуется. А поскольку, разрабатываемая нами система, должна иметь возможность формирования разных типов заданий (разработка, тестирование, внедрение и т.д.), в том числе разных их последовательности в рамках одного процесса, то создание такого механизма должно окупиться с лихвой.
Вы очевидно можете возразить, что сейчас есть серьезные библиотеки, поддерживающие BPMN модели и их реализацию без кодирования. Но мы ведь с Вами рассматриваем учебный проект, сделайте снисходжение.
4. Используем паттерны проектирования
Используйте рефакторинг процессов моделирования, обращаясь к паттернам проектирования, в том числе создавайте свои шаблоны. Эта тема хорошо раскрыта в [12]. Повторное использование неких шаблонов проектирования позволит не только сэкономить время в процессе разработки продукта, но и облегчить его поддержку и модернизацию.
Очень важно, чтобы аналитик, встретив необходимость преодоления некой проблемы, схожей с той которую уже решали, старался универсализировать это решение при помощи шаблона. Подобные шаблоны должны разрабатываться и утверждаться совместно с проектной группой. Тогда вся группа и разработчиков, и проектировщиков будет “невольно” следить за необходимостью их использования и правильностью применения.
Например, на основании структуры, рассмотренной в предыдущем разделе, мы можем разработать шаблон «Технологическая линия», который может нам пригодиться, для создания механизма пошагового формирования документов проектирования. Технологическая линия фактически будет исполнять роль конвейера, доставляющего формируемый ею «Продукт» (в нашем случае документ проектирования) на места его обработки, по определенному событию.
Приведу его описание:
Технологическая линия (Production Line)
Пример реализации структуры данных для шаблона «Технологическая Линия» представлен на Рисунке 8.6.
Как видно из диаграммы, структура данных почти полностью повторяет диаграмму «Формирования Задний по шаблонам» см. Рисунок 8.4. Описание механизмов, определяющих работу шаблона, большей частью аналогично процессу «Формирования Заданий по шаблонам», представленному в предыдущем разделе. Остановимся подробнее лишь на тех моментах, которые не были освещены выше, в частности – механизм определения и формирования Параметров действия.
Рис. 8.6 – Диаграмма Классов шаблона Технологическая линия
Для каждого Шаблона действия определяется перечень параметров, на основании «Вида задания» назначенного для шаблона. Параметр может быть либо “Основанием” для выполнения задания, либо “Результатом” его выполнения. Каждый параметр имеет тип, который определяет сущность “Продукта” (в нашем случае документ проектирования), обрабатываемого Технологической линией. На основании параметров, определенных для шаблона, при формировании действия будет идентифицирован конкретный экземпляр сущности, и ссылка на него будет записана в виде параметра “Основания” для действия. После выполнения действия, если для него определен параметр “Результат” (действие формирует или изменяет документ), ссылка на конкретный его экземпляр будет сохранена в этом параметре.
Важно, что исходящий параметр одного действия может быть назначен входящим параметром для следующего действия в технологической линии. Таким образом, формируемый “Продукт” проходит по узлам технологической линии.
5. Не забываем о стратегии развития линейки продуктов
На практике очень часто приходится не просто разрабатывать новый программный продукт, а выполнять замену устаревшего ПО, а в самом худшем варианте, унаследованного от другой команды разработчиков. В этом случае меняется характер работ и возрастает сложность проекта в целом. Обусловлено это целым рядом причин, которые мы рассмотрим в этом разделе. При проектировании подобных систем, необходимо учитывать следующие факторы:
Для того чтобы качественно разработать стратегию перехода, необходимо учесть природу возникновения такой потребности в каждом конкретном случае. К основным причинам, побуждающим к смене средств автоматизации, можно отнести:
Одним из критических условий внедрения изменений, является активное и, что немаловажно, эмоциональное вовлечение всех заинтересованных лиц в процессы обсуждения и разработки стратегии перехода от старого к новому.
Для начала необходимо осознать, что у исполнителей модернизируемого процесса уже есть реальный действующий инструмент для поддержания его функционирования, а создание и внедрение любой новой технология является угрозой разрушения этого инструмента. И для сотрудников заказчика совсем неочевидно, что в результате модернизации получится адекватная замена существующего решения. Поэтому зачастую, негативное отношение будущих пользователей к новой системе – это лишь защитная реакция. Надо заставить их доверять Вам.
Сотрудники, которых должны коснуться изменения, с самых ранних стадий проекта, ни в коем случае не должны находиться в неведении по поводу того, как должен быть организован их производственный процесс после нововведений. Напротив, они должны привлекаться к проектированию нового продукта. Дайте им почувствовать, что они являются авторами новой системы, что они ответственны за то, какой она получится.
Для привлечения как можно большего числа людей к процессу изменения, необходимо дать им возможность наглядно и эмоционально-привлекательно представлять контекст этих изменений. А именно: перечень изменяемых процессов, соответствие старых процессов новым, шаги и условия перехода и т.п. Используйте для визуализации модели стратегии перехода от старой системы к целевой, уже упомянутую выше, диаграмму «Архитектуры приложений». Пример представления стратегии для рассматриваемого нами проекта, изображен на Рисунке 8.7.
Рис. 8.7 – Диаграмма представления стратегии перехода от используемой архитектуры к целевой
На диаграмме отображается два представления системы: Действующая, которая работает в настоящее время (она выделена голубым цветом) и Целевая, которая должна ее заменить (она выделена желтым цветом). Пунктирными стрелками отмечено сопоставление модулей и функций Целевой системы с теми, которые они должны заменить в Действующей.
В результате обсуждения этой схемы (и других документов) должен появиться перечень этапов и мероприятий, которые позволят перейти от Действующей системы к Целевой.
Такие диаграммы помогают, например, выделить относительно самодостаточные сервисы, которые могли бы какое-то время функционировать в старой системе и позволять новой (целевой) системе взаимодействовать с ними. Это может оказаться очень полезно при планировании в проекте пошагового внедрения нового продукта.
Поскольку процесс замены старого ПО на новое длительный и сопряжен с проявлением множества трудно прогнозируемых рисков, необходимо постоянно следить за прогрессом перехода. При постоянном откладывании своевременного внесения необходимых изменений в программное обеспечение, резко обостряется проблема его стагнации. Поскольку зависимость ресурсов, выделяемых на модификацию ПО от их объема нелинейная, то и стоимость модификации стагнирующего ПО возрастает также нелинейно. Когда стоимость модификации возрастает настолько, что заказчик становится не в состоянии дальше изменять ПО, то оно становится условно «неизменным». Об этом очень доходчиво изложено в [8].
Для борьбы с подобными проблемами, можно заранее определить вехи проекта и четко отслеживать их наступление (или не наступление). Затягивание процесса изменений, с большой вероятностью, может привести к срыву всего проекта. Ведь внедрение каждого этапа чаще всего еще и связано со стрессом для пользователей и дополнительной нагрузкой на них. Если выполнение какого-либо из этапов не увенчалось успехом, то может возникнуть необходимость «откатиться» на предыдущий этап. Два-три таких «отката» и заказчик может отказаться от дальнейшего перехода на новое ПО, поскольку стоимость изменений становится критической.
Все вышесказанное заставляет особенно серьезно подходить к вопросам четкого и быстрого реагирования на проблемы, оказывающиеся преградами, останавливающими или значительно замедляющими процесс внесения изменений.
Важно, при выполнении действий по стратегическим изменениям, постоянно отслеживать барьеры, препятствующие реальному достижению запланированных целей. Для этого все подобные факты фиксируются, доводятся до внимания заинтересованных лиц и совместно с ними вырабатывается план мероприятий по их устранению.
Согласно подходу, к управлению изменениями Джона Коттера: «внедрение изменений происходит путем достижения краткосрочных успехов, которые происходят снова и снова, накапливая совокупную энергию, противостоящую скептикам и циникам. Именно поэтому, успехи необходимо всячески демонстрировать сотрудникам и всем заинтересованным лицам проекта. Именно это поможет достичь уважения и доверия при внедрении инноваций».
В следующей части мы будем определять поведение системы ссылка.