Проектирование модуля «Студенты» информационной системы «Кафедра Университета»

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

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

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

• создать у сотрудников всех уровней твёрдое ощущение неизбежности внедрения;
• наделить руководителя проекта внедрения достаточными полномочиями, поскольку сопротивление иногда (часто подсознательно или в результате неоправданных амбиций) возникает даже на уровне топ-менеджеров;
• всегда подкреплять все организационные решения по вопросам внедрения изданием соответствующих приказов и письменных распоряжений. Временное увеличение нагрузки на сотрудников при внедрении системы. На некоторых этапах проекта внедрения временно возрастает нагрузка на сотрудников предприятия. Это связано с тем, что помимо выполнения обычных рабочих обязанностей сотрудникам необходимо осваивать новые знания и технологии. Во время проведения опытной эксплуатации и при переходе к промышленной эксплуатации системы в течение некоторого времени приходится вести дела как в новой системе, так и продолжать ведение их традиционными способами (поддерживать бумажный документооборот и существовавшие ранее системы). В связи с этим, отдельные этапы проекта внедрения системы могут затягиваться под предлогом того, что у сотрудников и так хватает срочной работы по прямому назначению, а освоение системы является второстепенным и отвлекающим занятием. В таких случаях руководителю предприятия помимо ведения разъяснительной работы с уклоняющимися от освоения новых технологий сотрудниками необходимо:
• повысить уровень мотивации сотрудников к освоению системы в форме поощрений и благодарностей;
• принять организационные меры к сокращению срока параллельного ведения дел.

Формирование квалифицированной группы внедрения и сопровождения системы, руководителя группы. Внедрение большинства крупных систем автоматизации управления производится по следующей технологии: на предприятии формируется небольшая (3-6 человек) рабочая группа, которая проходит максимально полное обучение работе с системой, затем на эту группу ложится значительная часть работы по внедрению системы и дальнейшему ее сопровождению. Применение подобной технологии вызвано двумя факторами: во-первых, тем, что предприятие обычно заинтересовано в том, чтобы у него под рукой были специалисты, которые могут оперативно решать большинство рабочих вопросов при настройке и эксплуатации системы, а во-вторых, обучение своих сотрудников и их использование всегда существенно дешевле аутсорсинга. Таким образом, формирование сильной рабочей группы является залогом успешной реализации проекта внедрения.

Особенно важным вопросом является выбор руководителя такой группы и администратора системы. Руководитель, помимо знаний базовых компьютерных технологий, должен обладать глубокими знаниями в области ведения бизнеса и управления. В практике крупных западных компаний такой человек занимает должность CIO (Chief Information Officer) которая обычно является второй в иерархии руководства компании. В отечественной практике, при внедрении систем такую роль, как правило, играет начальник отдела АСУ или ему аналогичного. Основными правилами организации рабочей группы являются следующие принципы:

• специалистов рабочей группы необходимо назначать с учетом следующих требований: знание современных компьютерных технологий (и желание осваивать их в дальнейшем), коммуникабельность, ответственность, дисциплинированность;
• с особой ответственностью следует подходить к выбору и назначению администратора системы, так как ему будет доступна практически вся корпоративная информация;
• возможное увольнение специалистов из группы внедрения в процессе проекта может крайне негативно отразиться на его результатах. Поэтому членов группы следует выбирать из преданных и надежных сотрудников и выработать систему поддержки этой преданности в течение всего проекта;
• после определения сотрудников, входящих в группу внедрения, руководитель проекта должен четко расписать круг решаемых каждым из них задач, формы планов и отчетов, а также длину отчетного периода. В наилучшем случае, отчетным периодом должен быть один день.

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

 

1.3 Концептуальная модель UML

Для понимания UML необходимо усвоить его концептуальную модель, которая включает в себя три составные части: основные строительные блоки языка, правила их сочетания и некоторые общие для всего языка механизмы.

Словарь языка UML включает три вида строительных блоков:

• сущности;
• отношения;
• диаграммы.

Сущности – это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.

В UML имеется четыре типа сущностей:

• структурные;
• поведенческие;
• группирующие;
• аннотационные.

Сущности являются основными объектно-ориентированными блоками языка. С их помощью можно создавать корректные модели.

Структурные сущности – это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существует семь разновидностей структурных сущностей:

1. Класс (Class).
2. Интерфейс (Interface).
3. Кооперация (Collaboration).
4. Прецедент (Use case).
5. Активным классом (Active class).
6. Компонент (Component).
7. Узел (Node).

Класс (Class) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов. Графически класс изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции, как показано на рисунке 1.

1. Классы

 

Интерфейс (Interface) – это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда – их реализации. Графически интерфейс изображается в виде круга, под которым пишется его имя, как показано на рисунке 2. Интерфейс редко существует сам по себе – обычно он присоединяется к реализующему его классу или компоненту.

 

2. Интерфейсы

 

Кооперация (Collaboration) определяет взаимодействие. Она представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых. Кооперация, следовательно, имеет как структурный, так и поведенческий аспект. Один и тот же класс может принимать участие в нескольких кооперациях; таким образом, они являются реализацией образцов поведения, формирующих систему. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией, в который обычно заключено только имя, как показано на рисунке 3.

3. Кооперации

 

Прецедент (Use case) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Прецеденты реализуются посредством кооперации. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только его имя как показано на рисунке 4.

 

4. Прецеденты

 

Активным классом (Active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во всем подобен обычному классу, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов. Графически активный класс изображается так же, как простой класс, но ограничивающий прямоугольник рисуется жирной линией и обычно включает имя, атрибуты и операции, как показано на рисунке 5.

 

5. Активные классы

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

Компонент (Component) – это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В системе можно встретить различные виды устанавливаемых компонентов, такие как СОМ+ или Java Beans, а также компоненты, являющиеся артефактами процесса разработки, например файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя, как показано на рисунке 6.

 

6. Компоненты

 

Узел (Node) – это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой. Графически узел изображается в виде куба, обычно содержащего только имя, как показано на рисунке 7.

 

7. Узлы

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

• актеры,
• сигналы,
• утилиты (виды классов),
• процессы и нити (виды активных классов),
• приложения,
• документы,
• файлы,
• библиотеки,
• страницы и таблицы (виды компонентов).