Министерство образования и науки Российской Федерации

Федеральное государственное автономное образовательное учреждение

высшего профессионального образования

«Северный (Арктический) федеральный университет

имени М.В. Ломоносова»

А.П. Попов

Свободные инструменты

проектирования

информационных систем

Учебно-методическое пособие Архангельск

И П Ц САФУ

2012 УДК 004.415.2 ББК 638.72 П58 Рекомендовано к изданию редакционно-издатепъским советом Северного (Арктического) федерального университета имени М.В. Ломоносова Рецензенты:

доктор технических наук, профессор В.И. Воробьев, кандидат технических наук А.А. Докучаев Попов, А.И.

П58 Свободные инструменты проектирования информационных систем: учеб.-метод, пособие / А.И. Попов; Сев. (Арктич.) федер. ун-т им. М.В. Ломоносова. - Архангельск: ИПЦ САФУ, 2012. - 78 с : ил.

ISBN 978-5-261-00747- В пособии рассматриваются основные графические нотации, при­ меняемые при проектировании программных систем. Языкам графиче­ ского моделирования сопоставляются функциональные возможности ряда свободных CASE-инструментов. Проводится обзор и анализ таких инструментов, даются рекомендации по их установке и использованию.

Также предлагается материал для выполнения лабораторных работ, свя­ занных с разработкой системы требований к программным продуктам.

Издание предназначено для студентов, обучающихся по математи­ ческим и информационным направлениям и специальностям.

УДК 004.415. ББК 638. ISBN 978-5-261-00747-0 © Попов А.И., О Северный (Арктический) федеральный университет им. М.В. Ломоносова, Оглавление Введение Глава 1. Обзор методологий графического анализа 1.1. Схемы алгоритмов и программ 1.2. Диаграммы состояний-переходов 1.3. Методология функционального моделирования IDEF0 1.4. Диаграммы потоков данных 1.5. Event-driven Process Chains (ЕРС) 1.6. Business Process Modeling Notation (BPMN) 1.7. Иерархические модели данных ; 1.8. Диаграммы «Сущность - связь» 1.9. Объектно-ориентированное проектирование. Unified Modeling Language (UML) Глава 2. Программные инструменты проектирования и управ­ ления проектами 2.1. DBDesigner4 2.2. MySQL Workbench 2.3. Dia 2.4. Star U M L 2.5. Umbrello 2.6. ArgoUML 2.7. MasterTZ 2.8. Planner 2.9. GanttProject 2.10. Ramus Educational 2.11. ARIS Express 2.12. Сравнение возможностей инструментов Учебные проекты Глоссарий Библиографический список

ВВЕДЕНИЕ

П р о в е д е н и е л а б о р а т о р н ы х з а н я т и й по р я д у д и с ц и п л и н, свя­ занных с разработкой программных систем, предполагает при­ менение CASE-средств. В качестве примеров таких дисциплин можно назвать «Проектирование информационных систем», «Технологии разработки программного обеспечения», «Верифи­ кация моделей и программ», «Тестирование программного обес­ печения», «Разработка и стандартизация программных средств и информационных система, «CASE-технологии и язык U M L »

и др.

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

Технологии разработки программного обеспечения предпо­ жит следующие этапы:

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

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

Стремление к повышению эффективности бизнес-процессов программ.

Эффективное управление проектами также требует наличия работ с необходимыми ресурсами и работ между собой, демонст­ ствами являются диаграммы Гантта, сетевые графики, д и а г р а м м ы соответствии с которой крупные производители профессиональных CASE-систем создают бесплатные образовательные версии своих коммерческих продуктов. В пособии рассмотрены две такие системы.

пространенным графическим нотациям и наиболее доступным чения и систем:

46; 47];

- инструментальные средства поддержки жизненного цикла, - бизнес-процессы, экономические информационные системы [37; 64].

нию информационных систем в интернет-университете INTUIT.ru [13; 14];

примеры диаграмм. Далее рассмотрено программное обеспече­ и глоссарий.

ОБЗОР М Е Т О Д О Л О Г И Й Г Р А Ф И Ч Е С К О Г О А Н А Л И З А

горитма выполнения программы применяются схемы алгорит­ мов и программ. И х применение соответствует алгоритмическо­ му походу к углубленному анализу требований к программному Терминология, система графических обозначений, правила вы­ н ы х с т а н д а р т о в в 1980-1990-х годов [39; 40; 42].

Некоторые символы являются устаревшими, например символы, использованы символы начала и завершения программы, символы процессов, ветвление « И Л И », ветвление и слияние «И», ввод/вы­ вод данных, комментарий. Диаграмма описывает следующий «условие». Если «условие» выполнено, запускаются параллель­ параллельные процессы. Вывод д а н н ы х происходит либо после Рис. 1. Символы данных: а - данные, б - запоминаемые данные, в - оперативное запоминающее устройство, г - за­ поминающее устройство с последовательным доступом, д - запоминающее устройство с прямым доступом, е - до­ кумент, ж - ручной ввод, з - карта, и - бумажная лента, Рис. 2. Символы процесса: а - процесс, б - предопределен­ ный процесс, в - ручная операция, г - подготовка, д - реше­ ние, е - параллельные действия, ж - границы цикла Рис. 3. Символы линий: а - линия, б - передача управления, Рис. 4. Специальные символы: а - соединитель, б - терми­ Параллельные процессы В зарубежной литературе широко распространен термин дельных действий, ветвлений «И» и «ИЛИ», потока управления.

П о существу, р е ч ь идет о тех же схемах а л г о р и т м о в. В русском время привели к появлению терминов «граф-схемы алгоритмов»

можности для автоматизированного анализа программ, включая наличие граф-схемы параллельного алгоритма обеспечивает воз­ конечного автомата, к о т о р ы й, в с в о ю очередь, и с п о л ь з у е т с я д л я моделирования поведения технических объектов или объектов казательстве правильности программ, а именно в методе проверки на м о д е л и Model Checking [53].

рованный граф, вершины которого соответствуют состояниям, а д у г и - переходам. Около д у г о п и с ы в а ю т с я у с л о в и я переходов, а STD-диаграмма Харела, являющаяся частью языка U M L, пре­ диться в нескольких состояниях.

сист п р и н и м а е т н е к о т о р ы й з а к а з (срабатывает условие перехода ния». После завершения поездки пассажир оплачивает поездку ( с о с т о я н и е «Расчет») и п о к и д а е т м а ш и н у. Таксист снова переходит в состояние «Ожидание заявки».

мер описывает состояния программы, реализующей некоторую ловий, соответствующее действие называется «Инициализация».

анализа и п р о е к т и р о в а н и я S A D T (Structured Analysis and Design Technique), р а з р а б о т а н н о й Д у г л а с о м Т. Россом в 1969-1973 г о ­ ц и и п р о м ы ш л е н н ы х п р е д п р и я т и й (Integrated Computer Aided I C A M DEFinition и п р е д с т а в л я е т собой н а б о р методологий: IDEF0, IDEF1, I D E F l x, IDEF2, IDEF3 и т.д. В 2001 году в России б ы л и при­ Термин «функция» принят в Р 50.1.028-2001 [61]. На самом деле блок может соответствовать целому комплексу процессов, отдельному процессу, действию и т.д. В англоязычной литературе все это обознача­ ется общим словом activity (активность).

Стрелки, присоединенные к блоку снизу и направленные вниз, ис­ пользуются для того, чтобы обозначить обращение из данной модели грамм, возникающую в результате декомпозиции функций. Каж­ Н а одной д и а г р а м м е не д о л ж н о б ы т ь очень м а л о (кроме контекст­ организации процесса функционального моделирования. Поэтому д о к у м е н т е содержатся п о д р о б н ы е сведения о методологии IDEF0, диаграмм, отношениями между диаграммами и окружающей сре­ организация процесса функционального моделирования и управ­ или из данной части модели к блоку, входящему в состав другой модели или другой части модели [там же]. Иногда стрелкам снизу приписывают ресурсы [52]. Это позволяет, в частности, применять методологию IDEF в управлении проектами.

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

углубленном анализе функциональных требований к проектируе­ мой системе.

соответствуют внешним сущностям, функциям и хранилищам данных; вершины соединяются стрелками, которые моделируют функции. Хранилище определяет данные, сохраняемые между внешних сущностях игнорируются. Все компоненты диаграммы пользователя воздействия управления данные Рис. 10. Компоненты диаграммы потоков данных в нотаци­ ях Йордана - Демарко (слева) и Гейна - Сарсона (справа):

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

с в я з а н н ы х с в ы з о в о м городского такси по телефону. Н а контекст­ ю щ и е дело с этими процессами (внешние сущности), и связанные с ними потоки данных. В примере внешние сущности - клиент и водитель. Они связаны друг с другом комплексом процессов «Об­ ситуации может получить приветствие, отказ, стоимость, номер (диспетчеру) номер м а ш и н ы и примерное время ожидания клиен­ Рис. 12. Пример детализирующей DFD данных. Потоки согласованы с контекстной диаграммой. Храни­ лище данных используется д л я хранения истории клиентов, с тем чтобы, например, обеспечить предоставление скидок постоянным клиентам или наоборот занести некоторых клиентов в «черный список».

Event-driven Process Chains ( Е Р С ) м о ж н о п е р е в е с т и как «цепоч­ Рис. 13. Основные компоненты ЕРС-диаграмм: а - событие, б - функция, в - путеводитель по процессам, г - организа­ ционная единица, д - информационный, материальный или ресурсный объект, е - документ, ж - база данных, з - логи­ События - пассивные элементы в ЕРС. Функция происходит гую, используются так называемые иерархические функции. Эле­ мент «Имя организационной единицы» позволяет указать лицо функции. Информационные, материальные и ресурсные объекты моделируют соответствующие объекты реального мира. Д л я опи­ соединяет события с функциями, события с логическими соеди­ онной е д и н и ц е й (organization unit assignment) с о е д и н я е т ф у н к ц и ю и имя организационной единицы. Процессный путь соединяет две д и а г р а м м ы, т о е с т ь д в а бизнес-процесса.

Бизнес-процесс начинается с некоторого события, обозначенно­ о п е р а ц и и ; «хог» означает в е т в л е н и е « И Л И » (исключающее). П о ­ 1.6. Business Process Modeling Notation ( B P M N ) cess Modeling Notation) р а з р а б о т а н а Business Process Management этой нотации, - понятность как д л я технических специалистов, так и д л я участников бизнес-процессов. Спецификация B P M N цессов, но и то, как диаграммы могут быть трансформированы в и с п о л н я е м ы е м о д е л и на я з ы к е BPEL [5]. BPEL (Business Process Execution Language) - я з ы к на основе X M L, п р е д н а з н а ч е н н ы й д л я формального описания бизнес-процессов и протоколов их взаимо­ и текстовые аннотации). Дорожки и пулы дорожек применяются нутые пулы используются для компактности и отвлечения от де­ цией B P M N.

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

расположенных рядом и соответствующих параллельно выполня­ ющимся процессам.

ветствует звонку клиента. Клиент при этом сообщает диспетчеру адрес пункта отправления и адрес пункта назначения. В службе и диспетчер, и водители. Имеет место цикл: диспетчер предлага­ в о д и т е л е й не последовало, т о д и с п е т ч е р п о в т о р я е т адреса. К п р о Рис. 15. Базовые элементы BPD: а - событие, б - актив­ ность, в — шлюз, г — поток управления, д - поток сообще­ ний, е - ассоциации, ж - объект данных, з - пул, и - дорож­ кая трактовка прикрепленного символа сообщения предусмотрена процесс «Отказать», и бизнес-процесс завершается. При этом клиРис. 16. Некоторые объекты потока управления из расши­ ренного множества элементов BPD: а - начальное событие, б - промежуточное событие, в - завершающее событие, г - события-сообщения, д - события-таймеры, е - событияошибки, ж - действия (циклическое, многократное, свер­ нутый подпроцесс, свернутый циклический подпроцесс), з - логические операторы (исключающее ИЛИ, включаю­ деньги», и бизнес-процесс т а к ж е з а в е р ш а е т с я.

Структурой д а н н ы х называется совокупность правил и огра­ ных в соответствии с этим определением. Различают абстракт­ ные и конкретные структуры данных. Абстрактные структуры, кортеж) с неявными связями (таблицы) и структуры с я в н ы м и связями (всевозможные графы). Конкретные структуры отно­ честве примеров конкретных структур можно привести массив, абстрактных структур относится скорее к концептуальному мо­ делированию, а применение конкретных находится ближе к фи­ зическому.

данных.

При построении иерархической модели д а н н ы х опираются последовательных алгоритмов. Иерархические модели д а н н ы х тализации структуры данных. Терминальные вершины соответ­ ствуют элементам данных.

Примерами графических нотаций для представления иерар­ ны основные конструкции, используемые в диаграммах Джексо­ Рис. 18. Базовые конструкции на языке диаграмм Джексона:

зачтено"»), «С представляет собой повторяющиеся компоненты ников, которые пронумерованы и среди которых могут встречать­ ма Орра обычно получается более компактной, чем диаграмма Джексона.

нотаций и тем самым получить исходный материал для органи­ [58] и д р.

На самом деле диаграммы Джексона и Орра являются разными ва­ риантами графического представления одной и той же модели данных модели Джексона - Орра.

Рис. 19. Пример использования нотации Джексона Курсовая Рис. 22. Компоненты ERD в нотации Баркера: а - сущность, б - связь «один-к-одному», в - связь «один-ко-многим», тина.

Рис. 23. Связи в нотации Crown's Foot: а - один-к-одному, разделений. Атрибуты сотрудника: «номер сотрудника», «имя», н и и ER-модели исходят и з того, ч т о с у щ н о с т и впоследствии б у д у т Crown's Foot - воронья лапа (англ.).

Если с у щ н о с т и характеризуются не только атрибутами, но и поведением, представляемым в виде набора отдельных функ­ ций, то такие сущности называются классами, экземпляры классов - объектами, функций - методами классов. Соответ­ с т в у ю щ и й подход к анализу, проектированию и программиро­ ванию носит название объектно-ориентированного (ООП). Это может означать и «объектно-ориентированное проектирова­ ние». Существует также понятие «объектно-ориентированный анализ». ООП, как и ER-моделирование относится к объектно­ му подходу к углубленному анализу требований к программно­ зом ООП.

ряд диаграмм, объединенных В унифицированном языке модели­ р о в а н и я (Unified Modeling Language, U M L ).

А. Я к о б с о н о м (Rational Software, Object Management Group) в 1994-1996 годах. В е р с и и 0.9 и 0.91 б ы л и о п у б л и к о в а н ы в Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, I B M, I C O N Computing, M C I Systemhouse, Microsoft, ObjecTime, Oracle Corporation, Platinum Technology, Pretch, Rational Software, Reich Technologies, Softeam, Taskon, Texas Instruments и Unisys. О п у б ­ л и к о в а н н ы е в е р с и и U M L : 1.0 (январь 1997), 1.1 (ноябрь 1997), 1.3 ( и ю н ь 1999), 1.4 (сентябрь 2001), 1.5 (март 2003), 2.0 (август которых диаграмм U M L, а также приведем пример.

веденческие аспекты системы, связывает экторов с прецедентами.

е м о м у э к т о р о м результату;

- диаграмма классов показывает, какие выделены классы, как ношений между ними в определенный момент времени;

- диаграмма последовательностей и диаграмма взаимодействия отображают взаимодействие объектов в динамике. Имеется в виду - диаграмма развертывания представляет инфраструктуру, на которой будет р а з в е р н у т а п р о г р а м м н а я система;

- диаграмма активности раскрывает алгоритмы, по которым протекают процессы системы.

метной области, которую можно назвать «Измерения». О т класса «Средство измерений» наследуются классы «Измерительный пре­ следуются классы «Аналого-цифровой преобразователь» ( А Ц П ) и щены для компактности рисунка. В измерительной установке ис­ пользуются и измерительный прибор, и измерительный преобра­ +...

«Блок-схема».

Существует много программ, совместное использование ко­ д а н н ы х Oracle), Dia2Code (генерация исходного кода на о с н о ­ ER-диаграмм).