Стратегия разраб-ки км ПрО

Стратегия опред-я понятий прежде всего сост в том, чтобы опред наиболее важн понятия или объекты ПрО

Iя стратег при идентиф-ции понятий рекоменд использ след принцип «Лучше излишне детализир КМ, чем недоопределить ее»иногда на первонач стаиях идентиф-ции некотор понятия упускаются, а появл позднее на последн стад проектир-ия. Обнаруж понятия добавл в КМ

IIя стратег предусматр запрет на исключен понятия из-за неясности необходимости его запоминания или понятие не имеет атрибутов

Сущ-ют различн методы поиска понятий, напр -по списку категорий; -из текстовых описаний.

Особ-ть создания КМ опред сложностью идентиф-ции объектов и установления включения их в КМ

Концептуальна модель в UML: додавання атрибутів і асоціацій.

В проц разраб-ки КМ после опр-я понятий (объектов) необход опр связи между ними.

Ассоц-я – связь между понятиями, отраж-щая некоторое значимое и полезн отнош-е между ними.

В яз UML ассоц-я – это структурн взамосвязи между различн объектами.

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

Поиск ассоц-й осущ-ся по принципу их полезности с точки зрен сохранен инф о взаимоотнош объектов в течен некотор-го врем.

В КМ включ-ся такие ассоц: сохраняемые(важные); производные ассоц от стандартных.

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

Ассоц бывают не только простые, но и с высоким приоритетом. Ассоц важны, но их детализац не всегда необходима.

При поиске ассоц необход руковод-ся следующим: 1.опр-ть те ассоц, кот сохр-ся длительн время (важные ассоц); 2.важнее опр-е понятий, чем ассоц; 3.большое кол-во ассоц приводит к созданию сложн КМ и их ошибкам; 4.необход избегать излишних ассоц.

Кажд ассоц заканчив-ся ролью, кот имеет имя, кратность.

Использ-е только важных ассоц позвол получить КМ, кот не дает полн представлен об особен-тях ПрО. Хорошей счит-ся та модель, кот наход-ся между моделью с важн ассоц и мод с всевозможными ассоц. (Рис 1. КМ розничной торговли).

Опр-е атрибутов КМ ПрО.

Атрибут-абстрактное св-во объекта. В КМ включ-ся те атриб, для кот определены соответствующие Тр (прецеденты) для кот необход сохранять инф(в тоа чеке указ дата и продажа). Больш-во атриб рассм-ся как простые типы дан. Типы атриб не должны быть сложными, поэт исп-ют краткие формулир-ки атриб. Реализация прецедента опр-ся полнотой атрибутов всех понятий.

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

Для кажд ПрО устан-ся понятия и атриб. (Рис. 2 -Концептуальная модель предметной области розничной торговли с атрибутами).

Реинженеринг ІС.

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

1. Связана с моральным и физическим старением применяемых программных и инструментальных средств в структуре ИС;

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

Содержательный анализ структуры, унаследованной ИС дает возможность выделить 3 основных блока УИС:

1. Изменение даннях программого обеспечения

2. Изменение программных средств

3. Изменение ТС

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

Особенност УИС характеризуют степень необходимости проведения реинжениринга:

1. Обработка больших объемов информации, что ведет к дублированию, избыточности, нарушению целостности даннях, а следовательно к высокой вероятности потери даннях

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

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

Моделювання видів діяльності в UML (діаграми видів діяльності).

Модель видов деятельности (activity model) может представлять в графической форме поток событий для прецедента.

Диаграмма показывает какие шаги выполняются последовательно, а какие — параллельно. Передача управления от одного состояния вида деятельности к другому называется переходом (transition).

Состояние вида деятельности можно установить по описанию основного и альтернативных потоков. Описание прецедента создается с точки зрения внешнего субъекта. Модель видов деятельности отражает внутрисистемную точку зрения.

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

Диаграмма видов деятельности (activity diagram) показывает переходы между видами деятельности.

Переходы могут по условию разветвляться и объединяться. В результате возникают альтернативные (alternative) вычислительные потоки (thread). Условие ветвления обозначается ромбом.

Переходы могут также разделяться и сливаться. В результате возникают параллельные одновременно выполняемые) (concurrent) потоки.

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

Модели видов деятельности полезны для определения потоков видов деятельности в процессе выполнения прецедентов.

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

Виды деятельности выявляются на основе анализа предложений неформальной спецификации. Каждая фраза, содержащая глагол, рассматривается как потенциальный вид деятельности.

Модель потоків даних.

Модель потоков данных включает организационный, элементный и функциональный аспекты, где организационный и элементный аспекты описываются нормативной моделью. Модель потоков данных  определяет перечень укрупненных операций на предприятии и их взаимосвязи по информационным, материальным и финансовым потокам, которые будет использоваться в модели «Как надо», начиная с третьего уровня декомпозиции. Модель потоков данных отвечает на вопрос «Какие ресурсы задействованы при выполнении конкретных работ?». Модель потоков данных базируется на ИС предприятия (ИС класса ERP).

Моделювання поводження системи в UML (діаграми послідовностей).

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

Диаграмма последовательности состоит из четырех основных элементов:текста последовательности действий в прецеденте;объектов, в которых в формате «объект:класс» записывается имя или номер экземпляра объекта и имя класса объекта;сообщений, изображаемых стрелками, которые направлены от одного объекта к другому;методов (операций), представляемых в виде прямоугольников. Метод владеет управлением вплоть до точки, в которой прямоугольник кончается.

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

Застосування методів проектування на різних стадіях.

Методология (технология) SSADM регламентирует и поддерживает все этапы ЖЦ ИС. Входом в технологию явл. документы, инициирующие проект, а выходом – проектные реш-я. Структура ЖЦ ИС в SSADM реализуется каскадной моделью. В SSADM выделяют 5 этапов проектирования и 7 стадий.

SSADM позволяет разработчикам реализовать ЖЦ с использованием ТПП (типового процесса проектирования) и соответствующего методического обеспечения.

При использовании ТПП первая стадия может быть опущена. Основной задачей АР явл. разработка ТЭО (технико-экономического обоснования).

На 2м этапе 2 стадии. Предпроектное обследование предусм. описание. Работы: определить границы исследования, изучить инф.потоки и системы обработки данных, разработать логическое описание существующей системы, определить КП(каталоги пользователей), КТ(каталоги требований) при формировании недостатков существующей системы. На 2й стадии разрабатывается предварительный вариант ИС, а так же уточняется ТЭО, позволяющее с участием пользователей выбрать рациональный вариант ИС.

На этапе разработки ТЗ полностью определяются тр-я к разрабатываемой ИС. ТЗ состоит из КТ, КП, модели информационных потоков, логической модели данных. Работы: разработать тр-я к ФС(функц-й стр-ре), ЛМД(лог.модели данных), разработка прототипа ИС, проекта создания ИС.

На этапе 4 осуществл-ся выбор вариантов техн. реализации в рамках программной и технической составляющей ИС по аналогии со стадией 2. Выполняемые работы: разработка вариантов ПК и ТК, выбор варианта ПК и ТК.

Стадия 5 – разработка логического проекта осуществл-ся параллельно с 4й, предусматривающая создание интерфейса с., согласованного с РРЗ(режимом решения задач).

На 6 стадии осуществляется реализация физ. разработки ИС. Работы: разработка физ. модели БД, спецификаций треб-й к ПО, оптимизирует физ. стр-ру БД(по запросам КП), согласовуют интерфейс между задачами и КСА(комплексом средств автоматизации), оформляет физ. проект.

Методика обрання модели ЖЦ ІС