Базы данных по анкетам детей, оставшихся без попечения родителей для ОГОУ “Центра психолого-медико-социального сопровождения”

     Рисунок 1. Схема соединения «звезда-шина»

     Соединение  осуществляется по протоколу TCP/IP. Диапазон IP адресов используемых в сети: от 192.168.0.1 до 192.168.0.255. Сеть одноранговая, в которой все компьютеры имеют равные права, каждый из которых имеет установленную операционную систему платформы Microsoft Windows XP Professional. Пользователь компьютера самостоятельно решает вопрос о предоставлении доступа к своим ресурсам другим пользователям сети. Все компьютеры входят в рабочую группу workgroup. Имеется доступ в интернет по технологии ADSL, организованный через proxy сервер.

1.2.5. Декомпозиция бизнес-процессов

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

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

      Наиболее  удобным языком моделирования бизнес-процессов  является   IDEF0, предложенный более 20 лет назад Дугласом Россом и называвшийся первоначально SADT – Structured Analysis and Design Technique. В IDEF0 системе представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

      Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые вопросы.

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

      Процесс моделирования какой-либо системы  в IDEF0 начинается с определения контекста, то есть  наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.

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

     При построении модели необходимо четко  определить границы системы. Отделенная от окружающей среды система с  этой средой называется контекстом системы. Контекст системы изображается в виде «черного ящика», имеющего входы и выходы, которые отображают взаимодействие с окружающей средой. Каждая из стрелок имеет свое название и назначение.

     Стрелка слева Вход отображает необходимые для исполнения процесса входы (например, документы, инструменты, необходимые для осуществления процессов системы)

     Стрелка справа Выход отображает результаты исполнения процесса.

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

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

Построение  контекста системы

     А-0: Контекстная диаграмма процесса. Основная схема, представляющая деятельность всей организации (см. рис. 2).

Рисунок 2. Основная схема, представляющая деятельность всей организации

     Входными  данными являются: школьники, нуждающиеся  в помощи, практиканты без опыта  работы, дети сироты.

     Выходными данными являются: адаптированные школьники, адаптированные сироты, опытные практиканты.

     Механизмами являются: инвентарь центра, персонал, программное обеспечение.

     Управляющие воздействие оказывают: учебный  план, документы, правила по технике  безопасности.

     Далее рассмотрим систему, более подробно проведя декомпозицию бизнес процессов.

     Построение  схемы декомпозиции системы

     А0: ОГОУ «ЦПМСС» включает в себя следующие виды деятельности: организация учебного процесса, учебный процесс, административная деятельность, деятельность профсоюза, деятельность педагогического коллектива, деятельность обслуживающего отдела (см. рис. 3).

Рисунок 3. Схема декомпозиции системы

Организация учебного процесса состоит

     Входные данные: принятые (профсоюзом) права  и обязанности.

     Выходные  данные: расписание занятий.

     Механизмами являются: персонал (директор и его заместители), вспомогательное техническое оборудование, программное обеспечение.

     Управляющее воздействие оказывает: учебный  план.

Учебный процесс состоит

     Входные данные: дети сироты, школьники, нуждающиеся в помощи, практиканты без опыта работы.

     Выходные  данные: адаптированные школьники, адаптированные сироты, практиканты с опытом работы.

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

     Управляющее воздействие оказывает: расписание занятий, документы (правила внутреннего распорядка).

Административная деятельность состоит

     Входные данные: отчеты деятельности (учебного процесса), отчеты по АХЧ.

     Выходные  данные: договор.

     Механизмами являются: персонал (директор, заместители директора), программное обеспечение.

     Управляющее воздействие оказывает: документы (закон об образовании РФ, программа для общеобразовательных школ).

Деятельность  профсоюза состоит

     Входные данные: договор, предложения (по проведению мероприятий)

     Выходные  данные: принятые предложения

     Механизмами являются: персонал

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

Деятельность  педагогического коллектива состоит

     Входные данные: принятые предложения, практиканты  без опыта работы.

     Выходные  данные: план уборки, предложения (по проведению мероприятий).

     Механизмами являются: персонал, программное обеспечение.

     Управляющее воздействие оказывает: документы (программа для ОГОУ «Центр ПМСС»).

Деятельность обслуживающего отдела состоит

     Входные данные: план уборки.

     Выходные  данные: отчет по АХЧ.

     Механизмами являются: персонал (зам. директора по АХЧ, тех. персонал), инвентарь центра.

     Управляющее воздействие оказывает: документы (должностные  инструкции), правила по технике  безопасности.

1.2.6. Построение объектной модели задачи

     При проведении различных этапов, связанных  с проектированием, используют различные CASE-средства (сокращение от Computer Aided Software Engineering), которые позволяют автоматизировать процесс разработки информационных систем на протяжении всего жизненного цикла (жизненный цикл системы – непрерывный процесс, который начинается с момента решения о необходимости ее создания и заканчивается в момент полного изъятия системы из эксплуатации).

     Для разработки объектной модели рекомендуется  использовать одно из наиболее развитых в настоящее время CASE-средств – пакет объектного моделирования Rational Rose, предназначенный для построения объектной модели предметной области задачи.

     Унифицированный язык моделирования (Unified Modelling Language, UML) позволяет создавать несколько типов визуальных диаграмм. Rational Rose поддерживает разработку большинства этих моделей, а именно:

• диаграммы сценариев (Use Case);
• диаграммы классов (Classes);
• диаграммы последовательности (Sequence) и другие.

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

     Диаграммы сценариев позволяют отобразить, описать и документировать желаемое поведение системы с точки зрения взаимодействия с ней внешних объектов (действующих лиц). Сценарием также можно назвать какой-либо набор логически связанных между собой действий, приводящих к какому-то «логическому состоянию» системы. То есть это описание того, какие случаи, ситуации обрабатывает ваше приложение, какие реально действующие лица взаимодействуют с системой (см. рис. 4).

     Рисунок 4. Диаграмма вариантов использования

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

     На  диаграмме взаимодействия отображают один из процессов обработки информации в функции. Таких диаграмм для  каждой функции может быть несколько. Диаграммы взаимодействия визуализируют объекты и сообщения (с помощью сообщений один объект запрашивает у другого выполнения конкретной функции). Рассмотрим один из видов диаграмм взаимодействия – диаграммы последовательностей (Sequence).

     Традиционно диаграммы последовательностей  отображают типы объектов, взаимодействующих в сценариях, сообщения, которые они посылают друг другу. Объекты (экземпляры классов) в UML отображаются подчеркнутыми, чтобы отличить их от классов. Основная идея – это то, что диаграмма последовательности показывает «прохождение» логики выполнения в сценарии, позволяя документировать проект приложения. Прямоугольники на вертикальных линиях показывают «время жизни» объекта. Линии со стрелками и надписями названий методов означают вызов метода объекта (см. рис. 5).