* отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Объектно-ориентированный подход к проектированию ИС отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий. ООП - рассматривает модель предметной области как совокупность взаимодействующих во времени объектов. Каждый объект рассматривается как экземпляр определенного класса, образующих иерархию классов. Конкретный процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных может рассматриваться как результат одного взаимодействия объектов.
Конечным результатом процесса объектно-ориентированного проектирования должно стать множество классов объектов с присоединенными методами обработки атрибутов. Объектно-ориентированный подход предполагает совместное моделирование данных и процессов.
Объектно-ориентированный подход помогает справиться с такими сложными проблемами, как:
* уменьшение сложности программного обеспечения;
* повышение надежности программного обеспечения;
* обеспечение возможности модификации отдельных компонентов программного обеспечения без изменения остальных его компонентов;
* обеспечение возможности повторного использования отдельных компонентов программного обеспечения.
Систематическое применение объектно-ориентированного подхода позволяет разрабатывать хорошо структурированные, надежные в эксплуатации, достаточно просто модифицируемые программные системы. Объектно-ориентированное проектирование программного обеспечения связано с применением объектно-ориентированной методологии (технологии) разработки программных систем, а также инструментальных средств, поддерживающие эти технологии.
Объектно-ориентированная разработка может начаться на самом первом этапе жизненного цикла; она не связана с языком программирования, на котором предполагается реализовать разрабатываемую программную систему: этот язык может и не быть объектно-ориентированным. На этапе разработки объекты - это некоторые формальные конструкции (например, прямоугольники с закругленными углами, с помощью которых они изображаются на схемах), никак пока не связанные с их будущей реализацией на одном из языков программирования.
Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных методологий (технологий). Обычно эти объектно-ориентированные методологии поддерживаются инструментальными программными средствами, но и без таких средств они полезны, так как позволяют хорошо понять различные аспекты и свойства разрабатываемой программной системы, что в последующем существенно облегчает ее реализацию, тестирование, сопровождение, разработку новых версий и более существенную модификацию.
В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML.
Унифицированный язык объектно-ориентированного моделирования UnifiedModelingLanguage (UML) является универсальным современным средством проектирования информационных систем,которыйподерживается достаточно большим количеством инструментальных средств.UML поддерживает полный жизненный цикл информационных систем и, одновременно, является достаточно гибким для настройки и поддержки специфики командной разработки.
UML основывается на технологии объектно-ориентированного програмирования. Объединяет в себе всю мощь объектно-ориентированного подхода и дает четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (GradyBooch), OMT-2 (JimRumbaugh), OOSE -- Object-Oriented SoftwareEngineering (IvarJacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, OMT-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.
Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software CorporationАйвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML.
UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:
· является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;
· содержит механизмы расширения и специализации базовых концепций языка.
UML -- это стандартная нотация визуального моделирования программных систем, принятая консорциумом ObjectManaging Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.
UML включает внутренний набор средств моделирования ("ядро"), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач.
Пользователям языка предоставлены возможности:
· строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;
· добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей.
Сравнительный анализ выше перечисленных подходов к проектированию ИС показывает, что наиболее универсальным, наиболее полно описывающим все стороны функционирования, и поддерживаемым широким кругом современных инструментальных средств являются универсальный язык моделирования UML, который будет использоваться для проектирования автоматизированной системы поверки приборов учета расхода электроэнергии.
2.2.1 Этапы проектирования ИС с применением UML
UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств - диаграмм.
На этапе создания концептуальной модели для описания бизнес-деятельности используются модели бизнес-прецедентов и диаграммы видов деятельности, для описания бизнес-объектов - модели бизнес-объектов и диаграммы последователь-ностей.
На этапе создания логической модели ИС описание требований к системе задается в виде модели и описания системных прецедентов, а предварительное проектирование осуществляется с использованием диаграмм классов, диаграмм последовательностей и диаграмм состояний.
На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания.
Ниже приводятся определения и описывается назначение перечисленных диаграмм и моделей применительно к задачам проектирования ИС (в скобках приведены альтернативные названия диаграмм, использующиеся в современной литературе).
Диаграммы прецедентов (диаграммы вариантов спользования, usecase diagrams) - это обобщенная модель функционирования системы в окружающей среде.
Диаграммы видов деятельности (диаграммы деятельностей, activitydiagrams) - модель бизнес-процесса или поведения системы в рамках прецедента.
Диаграммы взаимодействия (interaction diagrams) - модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequencediagrams) или кооперативных диаграмм (collaboration diagrams).
Диаграммы состояний (statechartdiagrams) - модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.
Диаграммы классов (classdiagrams) - логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.
Диаграммы базы данных (database diagrams) -- модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.
Диаграммы компонентов (component diagrams) - модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.
Диаграммы развертывания (диаграммы размещения, deployment diagrams) - модель физической архитектуры системы, отображает аппаратную конфигурацию ИС.
На рисунок 2.1 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение "является источником входных данных для..." (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.
Рисунок 2.1 Взаимосвязи между диаграммами UML
Ниже приводятся описания последовательных этапов проектирования ИС с использованием UML.
2.2.2 Использование основных объектов UML в проектирование информационной системы ФБУ «Пятигорский ЦСМ»
Классы
Классы -- это базовые элементы любой объектно- ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами -- атрибутами, операциями, отношениями и семантикой.
В рамках модели каждому классу присваивается уникальное имя - в нашем проекте это Учетная запись.
Атрибут -- это свойство класса, которое может принимать множество значений. Множество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов. Например, для класса объектов Учетная запись информационной системы ФБУ «Пятигорский ЦСМ» определены атрибуты ID - уникальный идентификатор пользователя, Логин, Должность, Пароль.
Операция -- реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта. Для класса объектов Учетная запись информационной системы ФБУ «Пятигорский ЦСМ» определена операция Регистрация.
На рисунке 2.2 приведено графическое изображение класса "Учетная запись" в нотации UML.
Рисунок. 2.2 Изображение класса в UML другое.
Синтаксис UML для свойств классов (в отдельных программных средствах, например, в IBM UML Modeler, порядок записи параметров может быть иным):
<признак видимости><имя атрибута> : <тип данных>
= <значение по умолчанию>
<признак видимости><имя операции><(список аргументов)>
Для класса объектов Учетная запись описание атрибута ID иметь следующий вид:
publicID: int = 0001
Для класса объектов Учетная запись описание операции Регистрация иметь следующий вид:
protected Регистрация: (int ID, string Логин, string* Должность, string Пароль)
Видимость свойства указывает на возможность его использования другими классами. Один класс может "видеть" другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. Например, в данной информационной системы ФБУ «Пятигорский ЦСМ» атрибуты и операции доступны для класса объекта Поверка.
В языке UML определены три уровня видимости:
· public (общий) -- любой внешний класс, который "видит" данный, может пользоваться его общими свойствами. Обозначаются знаком " + " перед именем атрибута или операции, как в данном проекте для атрибута ID; Например, в объектеАдминистратороперацияУправление правами имеет общую видимость.
· protected (защищенный) -- только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком " # ", как в данном проекте для операции Регистрация; Например, в объекте Учетная запись операция Регистрация имеет защищенную видимость.
· private (закрытый) -- только данный класс может пользоваться этими свойствами. Обозначаются символом " - ". В данной системе нет операции с типом закрытый.
Еще одной важной характеристикой атрибутов и операций классов является область действия. Область действия свойства указывает, будет ли оно проявлять себя по-разному в каждом экземпляре класса, или одно и то же значение свойства будет совместно использоваться всеми экземплярами:
· instance (экземпляр) -- у каждого экземпляра класса есть собственное значение данного свойства;