Процесс проектирования информационной системы – это процесс принятия проектно-конструкторских решений, направленных на получения описания системы, удовлетворяющей требованиям.
Выбор средств проектирования программного обеспечения является одной из самых важных задач при разработке любого программного обеспечения. В настоящее время для проектирования различных систем повсеместно используют CASE-средства.
CASE-средства являются наиболее привлекательным инструментарием для разработки информационных систем. Чем крупнее проект, тем большее значение приобретает применение CASE-технологий. Масса новых приложений разрабатывается на основе объектно-ориентированных (ОО) принципов. CASE-средства, применяемые для объектного моделирования, обеспечивают поддержку нотаций и методологий ОО моделирования и генерацию составных частей ОО приложений. Рост требований к информационным системам заставляет поднимать системы на новые уровни сложности, и CASE-средства делают архитектуру и проект более доступными для понимания и модификации.
Поскольку разработчики имеют дело с теми частями системы, которые были спроектированы их коллегами, они должны быстро находить тот или иной поднабор классов и методов, понимать, как их увязать со своей собственной работой. Точно так же руководитель проекта должен представлять себе общую картину работы над проектом. Вот почему CASE-средства, объединенные с методологиями, дают возможность увидеть сложные системы, которые трудно понять в виде кода или схемы.
Потребности разработчиков и проектировщиков нередко выходят за границы возможностей обычных средств разработки. Поэтому CASE-средства необходимы, например, для осуществления логического моделирования данных, объектного моделирования, а иногда даже для обратного проектирования бизнес-процессов. И все это с помощью одного продукта!
Таким образом, разработка информационных систем с использованием CASE-технологий является наиболее эффективным методом и имеет массу преимуществ как для пользователей, так и для разработчиков.
Мировой лидер в области CASE-технологии предлагает мощное средство системного анализа деловой и производственной активности, позволяющее отслеживать соответствие структуры бизнеса, документооборота, финансовых потоков жестким и динамичным требованиям современной экономики.
Продукт Visio 2003 – это решение для создания технических и деловых диаграмм, предназначенных для систематизации и наглядного представления различных данных, процессов и систем. Диаграммы Visio 2003 позволяют без труда осуществлять визуализацию и обмен различной информацией с высочайшей точностью, надежностью и эффективностью, недостижимыми при использовании текстовых и числовых данных. Visio 2003 автоматизирует процесс визуализации за счет синхронизации данных с указанным источником, благодаря чему на диаграммах всегда отображается самая актуальная информация.
На сегодняшний день большинство технологий бизнес-моделирования основаны на использовании графических диаграмм. Учитывая это, компания Microsoft включила в свою систему создания бизнес-диаграмм и схем Microsoft Visio 2003 специальные средства для описания бизнес-процессов и организационной структуры компании.
Для моделирования бизнес-процессов Visio 2003 предлагает бизнес-аналитику шаблоны для создания 7 видов диаграмм:
Basic Flowchart;
Cross-Functional Flowchart (с вертикальным или горизонтальным расположением дорожек);
EPC (Event-driven Process Chain);
IDEF0;
DFD (Data Flow Diagrams) в двух нотациях: Гейна-Сарсона и Йордана-Де Марко;
WFD (Work Flow Diagram)
Из перечисленных нотаций наиболее популярными являются IDEF0 и EPC.
Нотация моделирования IDEF0 базируется на методологии структурного анализа и проектирования SADT (Structured Analysis and Design Technique).
IDEF0 модель предназначена для описания существующих бизнес-процессов на предприятии (модель AS-IS) и того, к чему нужно стремиться (модель TO-BE). Предписывается построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром, после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы, каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес - процессе. Такая технология создания модели позволяет построить модель адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, Visio позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0 ) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.
Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. DFD описывают функции обработки информации (работы), документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации (внешние ссылки, external references) и таблицы для хранения документов (хранилище данных, data store). В отличие от IDEF0 для стрелок нет понятия вход, выход, управление или механизм и неважно, в какую грань работы входит или из какой грани выходят стрелки.
Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. С их помощью можно описывать сценарии действий сотрудников организации, например, последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. Прямоугольники на диаграмме Workflow называются единицами работы (Unit of Work, UOW) и обозначают событие, процесс, решение или работу. Для редактирования диаграммы используются примерно те же диалоги, что и для IDEF0.
Ниже представлены несколько диаграмм:
диаграмма IDEF0 – контекстная, которая отображает общий вид системы, то есть «внешнюю оболочку»;
диаграмма IDEF0 первого уровня, которая раскрывает контекстную диаграмму и отображает внутреннее содержание.
Рис. 2.1. Контекстная диаграмма бизнес-процессов
На следующей диаграмме отображены детализирующие процессы
Рис. 2.2. Детализирующая диаграмма бизнес-процессов
2.2 Постановка задачи по подсистемам
2.2.1 Построение диаграммы вариантов использования
Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует цели:
Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
Сформулировать общие требования к функциональному поведению проектируемой системы.
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
С данной системой будут взаимодействовать 2 актера, т.е. пользователя – это администратор системы и покупатель.
На следующей диаграмме описывается диаграмма вариантов использования для покупателей.
Рис. 2.3. Диаграмма вариантов использования для покупателей
Cайт Интернет-магазина, предназначенный для покупателей, позволяет выбирать, заказывать и оплачивать товар. Именно этот сайт покупатели считают Интернет-магазином