Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления

Подождите немного. Документ загружается.

система для высокоскоростного мультиприоритетного обслуживания удаленных линий

связи, обеспечивающая возможности диагностики.

Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.

Из таблицы следует, что увеличение затрат в 1,3 раза из-за очень высокой сложности

продукта уравновешивается их уменьшением вследствие высокой квалификации аналитика и

программиста, а также активного использования программных утилит.

Таблица 14

Фактор Описание Оценка Множитель

RELY Требуемая надежность ПО Номинал. 1

DATA Размер базы данных — 20 Кбайт Низкая 0,93

CPLX Сложность продукта Очень высок. 1,3

RUSE Требуемая повторная используемость Номинал. 1

DOCU Документирование жизненного цикла Номинал. 1

TIME Ограничения времени выполнения (70%) Высокая 1,11

STOR

Ограничения оперативной памяти (45 из 64

Кбайт, 70%)

Высокая 1,06

PVOL Изменчивость платформы (каждые 6 месяцев) Номинал. 1

ACAP Возможности аналитика (75%) Высокая 0,83

PCAP Возможности программиста (75%) Высокая 0,87

AEXP Опыт работы с приложением (1 год) Номинал. 1

PEXP Опыт работы с платформой (6 месяцев) Низкая 1,12

LTEX Опыт работы с языком и утилитами (1 год) Номинал. 1

PCON Непрерывность персонала ( 1 2% в год) Номинал. 1

TOOL Активное использование программных утилит Высокая 0,86

SITE Мультисетевая разработка (телефоны) Низкая 1,1

SCED Требуемый график разработки Номинал. 1

Множитель поправки М

= 1,088

Рассчитаем затраты и стоимость проекта:

ЗАТРАТЫ = АхРАЗМЕРхМр=2,5(10)

1,16

х1,088=36х1,088= 39[чел.-мес], СТОИМОСТЬ =

ЗАТРАТЫ х $6000 = $234 000. Таковы стартовые условия программного проекта. А теперь

обсудим несколько сценариев возможного развития событий.

Сценарий понижения зарплаты

Положим, что заказчик решил сэкономить на зарплате разработчиков. Рычаг — понижение

квалификации аналитика и программиста. Соответственно, зарплата сотрудников снижается

до $5000. Оценки их возможностей становятся номинальными, а соответствующие

множители затрат принимают единичные значения: EM

acap

=EM

pcap

=1. Следствием такого

решения является возрастание множителя поправки М

= 1,507, а также затрат и стоимости:

ЗАТРАТЫ = З6х 1,507 = 54 [чел.-мес], СТОИМОСТЬ = ЗАТРАТЫ х$5000 = $270 000,

Проигрыш_ в стоимости = $36 000.

Сценарий наращивания памяти

Положим, что разработчик предложил нарастить память — купить за $1000 чип ОЗУ

емкостью 96 Кбайт (вместо 64 Кбайт). Это меняет ограничение памяти (используется не

70%, а 47%), после чего фактор STOR снижается до номинального:

EMstor=1-> М

=1,026, ЗАТРАТЫ = 36x1,026 = 37 [чел.-мес], СТОИМОСТЬ = ЗАТРАТЫ х

$6000 = $222000, Выигрыш_в_стоимости = $ 12 000.

Организационные процессы

Процесс создания

инфраструктуры

Процесс

обучения

Процесс

усовершенствова

ния

Процесс

управления

проектом

Управление персоналом

Подготовка плана-графика

IEEE 1058.1 – 1987 SPMP

Оценка стоимости проекта ИС

Рисунок 12 – Нормативные документы, сопровождающие организационные процессы ЖЦ

3. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ

Если кажется, что работу сделать

легко, это непременно будет трудно.

Если на вид она трудна, значит,

выполнить ее абсолютно невозможно.

Теорема Стакмайера

Технология проектирования АСОИУ – совокупность методологии, а также методов

и средств организации процесса проектирования (управление процессом разработки и

модернизации проекта).

Методология проектирования представляет собой концепцию / принципы

проектирования, реализуемые набором методов проектирования, поддерживаемых

средствами проектирования.

Метод (подход) проектирования – алгоритм / последовательность шагов по

реализации той или иной стадии создания АСОИУ.

Главный

принцип построения различных систем – принцип иерархической

декомпозиции включает две группы методологий:

1. Группа структурно-функциональной методологии, в основу положен принцип

функциональной декомпозиции: структура системы описывается в терминах иерархии ее

функций и передачи информации между отдельными функциональными элементами.

2. объектно-ориентированная методология использует объектную декомпозицию. При этом

структура системы описывается в терминах объектов и связей между ними, а поведение

системы описывается в терминах обмена сообщениями между объектами.

3.1. СТРУКТУРНО-ФУНКЦИОНАЛЬНАЯ МЕТОДОЛОГИЯ

В структурном анализе и проектировании используются различные модели,

описывающие:

1. функциональную структуру системы;

2. последовательность выполняемых действий;

3. передачу информации между функциональными процессами;

4. отношения между данными.

Наиболее распространенными реализациями этих моделей являются:

1. функциональная модель SADT (Structured Analysis and Design Technique);

2. модель IDEF3;

3. DFD (Data Flow Diagrams) — диаграммы потоков данных.

4. Диаграмма «сущность — связь» (ERD — Entity-Relationship Diagram).

Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. и успешно

использовался в военных, промышленных и коммерческих организациях США для решения

широкого круга задач. Метод SADT поддерживается Министерством обороны США,

которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition),

являющегося основной частью программы ICAM (интегрированная компьютеризация

производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном из

стандартов этого семейства - IDEF0 последняя редакция

которого была выпущена в декабре

1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В 2000 г.

постановлением Госстандарта России был введен в действие руководящий документ РД

IDEF0 – 2000, содержащий основные сведения о методологии функционального

моделирования IDEF0, о ее графическом языке и методике построения и практического

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

технических систем. Кроме того, РД IDEF0 – 2000 устанавливает правила оформления

комплекта иерархических диаграмм.

В основе методологии IDEF0 лежат четыре основных понятия: функциональный блок,

интерфейсная дуга, декомпозиция, глоссарии.

Функциональный блок (Activity Box) представляет собой некоторую конкретную

функцию в рамках рассматриваемой системы. На диаграмме функциональный блок

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

свое определенное значение (роль), при этом:

• верхняя сторона имеет значение «Управление» (Control);

• левая сторона имеет значение «Вход» (Input);

• правая сторона имеет значение «Выход» (Output);

• нижняя сторона имеет значение «Механизм» (Mechanism).

Блоки (5-7) на диаграмме располагаются в порядке доминирования.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose)

построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был

разработан в конце 1980-х годов. Этот метод предназначен для таких моделей процессов, в

которых важно понять последовательность выполнения действий и взаимозависимости

между ними.

Единицы работы - Unit of Work (UOW) (работы), являются центральными

компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя,

обозначающее процесс действия и номер (идентификатор).

Связи IDEF3 показывают взаимоотношения работ. Все связи в IDEF3 являются

однонаправленными и имеют следующие типы: временное предшествование, объектный

поток, нечеткое отношение.

Перекрестки (Junction) - используются для отображения логики взаимодействия

стрелок при слиянии и разветвлении или для отображения множества событий, которые

могут или должны быть завершены перед началом следующей работы.

Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой

иерархию функциональных процессов, связанных потоками данных. Цель такого

представления – продемонстрировать, как каждый процесс преобразует свои входные

данные в выходные, а также выявить отношения между этими процессами.

В соответствии с данным методом модель системы определяется как иерархия

диаграмм потоков данных, описывающих асинхронный процесс преобразования

информации от ее ввода в систему до выдачи потребителю. Источники информации

(внешние сущности) порождают информационные потоки (потоки данных), переносящие

информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и

порождают новые потоки, которые переносят информацию к другим процессам или

подсистемам, накопителям данных или внешним сущностям – потребителям информации.

При создании диаграммы потоков данных используются четыре основных понятия: потоки

данных, процессы (работы) преобразования входных потоков данных в выходные, внешние

сущности, накопители данных (хранилища). SADT создавалось как средство моделирования

систем в целом, а DFD как средство проектирования ИС, поэтому DFD более перспективно

для использования, тем более DFD согласовано с ERD, поскольку в DFD присутствует

описание структур данных, непосредственно используемое для построения ERD.

Моделирование данных необходимо для обеспечения разработчика АИС

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

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

Наиболее распространенным средством моделирования данных являются диаграммы

«сущность-связь» (ERD), которая впервые введена Питером Ченом в 1976 г. Базовыми

понятиями ERD являются: (сущности), их свойства (атрибуты) и отношения друг с другом

(связи). Кроме того, ERD связываются с такими понятиями как: мощность и тип связи,

первичный и внешние ключи, индексы, нормализация диаграммы и т.д.

3.2. ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ МЕТОДОЛОГИЯ

Объектно-ориентированный подход к разработке систем получил распространение в

1990-х годах.

Объектный подход к разработке систем следует итеративному процессу с

наращиванием возможностей. Единая модель конкретизируется на этапах анализа,

проектирования и реализации – в результате успешных итераций добавляются новые детали,

при необходимости вводятся изменения и усовершенствования.

Объектно-ориентированный подход обладает следующими преимуществам:

• Использование объектного подхода существенно повышает уровень унификации

разработки и пригодность для повторного использования, что ведет к созданию среды

разработки и переходу к сборочному созданию моделей.

• Объектная декомпозиция позволяет избежать создания сложных моделей, так как она

предполагает эволюционный путь развития модели на базе относительно небольших

подсистем.

• Объектная модель естественна, поскольку ориентирована на человеческое восприятие

мира.

К недостаткам объектно-ориентированного подхода относятся:

• высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его

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

используемых компонентов.

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

разработки, с помощью четко определенной декомпозиции работ, элементов комплекта

поставки и ключевых этапов. При объектной разработке с помощью "детализации" не

существует четких границ между этапами, а проектная документация непрерывно

развивается. Приемлемое решение в такой ситуации лежит в делении проекта на

небольшие модули и управлении ходом разработки за счет частого выпуска

выполняемых версий этих модулей (некоторые из этих выпусков могут быть для

внутреннего применения, а другие – поставляться заказчику).

• Возрастающая сложностью решения, что, в свою очередь, сказывается на таких

характеристиках ПО, как приспособленность к сопровождению и масштабируемость.

Концептуальной основой объектно-ориентированного подхода является объектная

модель, которая строится с учетом следующих принципов:

• Абстрагирование – это выделение наиболее важных, существенных характеристик

некоторого объекта, которые отличают его от всех других видов объектов и, таким

образом, четко определяют его концептуальные границы с точки зрения дальнейшего

рассмотрения и анализа, и игнорирование менее важных или незначительных деталей.

• Инкапсуляция – физическая локализация свойств и поведения в рамках единственной

абстракции (рассматриваемой как «черный ящик»), скрывающая их реализацию за

общедоступным интерфейсом.

• Модульность – это свойство системы, связанное с возможностью ее декомпозиции на ряд

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

• Иерархия – это ранжированная или упорядоченная система абстракций, расположение их

по уровням.

Основными понятиями объектно-ориентированного подхода являются объект и класс.

Объект – предмет или явление, имеющее четко определенное поведение и

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

объектов определяют общий для них класс. Класс – это множество объектов, связанных

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

подхода составляют наследование и полиморфизм. Понятие полиморфизм может быть

интерпретировано как способность класса принадлежать более чем одному типу.

Наследование означает построение новых классов на основе существующих с возможностью

добавления или переопределения данных и методов. Объекты одного класса имеют

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

Состояние объекта определяется значениями его атрибутов; поведение – его

операциями. При вызове операций, которые могут изменить значение атрибутов объекта,

возможен переход объекта из одного состояния к другому. Для осуществления функций

системы между объектами устанавливаются связи по которым они обмениваются

сообщениями.

3.2.1. Введение в унифицированный язык моделирования (UML)

Унифицированный язык объектно-ориентированного моделирования Unified Modeling

Language (UML) явился средством достижения компромисса между этими подходами.

Существует достаточное количество инструментальных средств, поддерживающих с

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

достаточно гибким для настройки и поддержки специфики деятельности различных команд

разработчиков.

Мощный толчок к разработке этого направления информационных технологий дало

распространение объектно-ориентированных языков программирования в конце 1980-х —

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

который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы

четкую модель системы, отражающую все ее значимые стороны. К середине девяностых

явными лидерами в этой области стали методы Booch (Grady Booch), OMT-2 (Jim Rumbaugh),

OOSE — Object-Oriented Software Engineering (Ivar Jacobson). Однако эти три метода имели

свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области

и анализа требований к системе, ОМТ-2 был наиболее предпочтителен на стадиях анализа и

разработки информационных систем, Booch лучше всего подходил для стадий дизайна и

разработки.

Все шло к созданию единого языка, который объединял бы сильные стороны

известных методов и обеспечивал наилучшую поддержку моделирования. Таким языком

оказался UML.

Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational

Software Corporation стали работать над объединением своих методов ОМТ и Booch. Осенью

1995 г. увидела свет первая черновая версия объединенной методологии, которую они

назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software

Corporation Айвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее

распространенных объектно-ориентированных методологий были объединены и направлены

на создание UML.

В настоящее время консорциум пользователей UML Partners включает в себя

представителей таких грандов информационных технологий, как Microsoft, IBM, Hewlett-

Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML представляет собой объектно-ориентированный язык моделирования,

обладающий следующими основными характеристиками:

• является языком визуального моделирования, который обеспечивает разработку

репрезентативных моделей для организации взаимодействия заказчика и разработчика

ИС, различных групп разработчиков ИС;

• содержит механизмы расширения и специализации базовых концепций языка.

UML – это стандартная нотация визуального моделирования программных систем,

принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний

день она поддерживается многими объектно-ориентированными CASE-продуктами.

UML включает внутренний набор средств моделирования (модулей?) («ядро»),

которые сейчас приняты во многих методах и средствах моделирования. Эти концепции

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

каждой части каждого приложения. Пользователям языка предоставлены возможности:

• строить модели на основе средств ядра, без использования механизмов расширения для

большинства типовых приложений;

• добавлять при необходимости новые элементы и условные обозначения, если они не

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

(нотацию) и ограничения для конкретных предметных областей.

3.2.2. Синтаксис и семантика основных объектов UML

UML – это набор диаграмм, которые позволяют создавать модели сложных

программных систем.

Диаграммы UML разделяются на две группы:

структурные диаграммы:

• Implementation Diagram (диаграммы реализации):

o Deployment diagram (диаграммы топологии);

o Component diagram (диаграммы компонент).

• Class diagram (диаграммы классов);

и диаграммы поведения:

• Use case diagram (диаграммы вариантов использования);

• Statechart diagram (диаграммы состояний);

o Activity diagram (диаграммы активности);

• Interaction diagram (диаграммы взаимодействия);

o Sequence diagram (диаграммы последовательности);

o Collaboration diagram (диаграмма сотрудничества / кооперативная диаграмма);

3.2.2.1. Диаграмма прецедентов использования (Use Case Diagram)

Вариант использования определяется, прежде всего, своим именем и типом

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

Вариант использования состоит из типичного взаимодействия между действующим

лицом и приложением. Например, команда «открыть файл» будет типичным вариантом

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

Один и тот же человек или внешняя система может

использовать систему

несколькими разными способами, принимая роли разных действующих лиц (актеров –

actors). Актеры представляют именно роли, исполняемые людьми или внешними

сущностями, а не конкретных людей или сущностей.

Прецедент описывает поведение, демонстрируемое системой с целью получения

значимого результата для одного или более актеров.

Для детализации прецедента составляют спецификацию.

Имя прецедента – отглагольное существительное

в стиле UpperCamelCase

Идентификатор (1.1 – прецедент.№альтернативного потока)

Краткое описание – цель прецедента

Актеры: главные актеры инициируют прецедент; второстепенные актеры –

взаимодействуют с прецедентом после его инициации

Предусловия определяют условия, которые должны быть истинными для того,

чтобы прецедент мог быть инициирован

Основной поток – этапы осуществления прецедента.

Этапы принято записывать в виде:

<номер> <кто-либо><действие>

1. Покупатель заполняет в форме свои имя и адрес

Для представления ответвления используется ключевое слово «Если»

2. Если покупатель выбирает «удалить позицию»

2.1. Система удаляет позицию из корзины

Повторения моделируют с помощью ключевых слов «Для» или «Пока»

3. Если система находит необходимые продукты, тогда

1.1 Для каждого найденного продукта

1.1.1 Система выводит на экран представление продукта

1.1.2 Система выводит на экран цену продукта

Постусловия определяю, какие условия будут истинными после выполнения

прецедента

Альтернативные потоки – альтернативные пути в прецеденте, которые

перехватывают ошибки, ответвления и прерывания основного потока (наиболее

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

отдельно).

InvalidPassword

Рисунок 13 – Примерный вид спецификации прецедента

Диаграммы вариантов использования позволяют показать специфические

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

Обобщение прецедентов выносит поведение, общее для одного или более

прецедентов, в родительский прецедент.

Рисунок 14 – Обобщение прецедентов

При построении диаграмм вариантов использования необходимо, во-первых, избегать

последовательного соединения двух вариантов использования, поскольку диаграмма

предназначена для отражения существующих вариантов использования, а не порядка их

выполнения (для этого используется диаграмма деятельности). Во-вторых, каждый вариант

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

Однако, на диаграммах встречается последовательное соединение прецедентов, но

при

этом используются специальные типы связей:

Отношение «include» устанавливаемое между прецедентами, позволяет включить

поведение одного прецедента в поток другого прецедента. Это означает, что при выполнении

прецедента «Просмотреть Индексную Карточку УММ» обязательно должен быть выполнен

прецедент «Поиск УММ». Для обозначения отношения включения в UML используется

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

целевому (включаемому).

Рисунок 15 – Использование отношений «include» и «extend»

Прецедент: РедактироватьИндекснуюКарточку

ID: 4

Краткое описание: Менеджер меняет даные служащего

Администратор изменяет поля УММ, отраженные в индексной

карточке

Главные актеры: Администратор

Второстепенные актеры: нет

Предусловия:

1. Администратор входит в систему

Основной поток:

1. include (ПоискУММ)

2. include (ПросмотретьИндекснуюКарточку)

3. Система выводит данные УММ

4. Администратор меняет данные УММ

….

Постусловия:

1. Данные УММ изменены

Альтернативные потоки: нет

Рисунок 16 – Структура спецификации прецедента, включающей отношение «include»

Отношение «extend» - способ введения нового поведения в существующий прецедент.

При использовании «extend» базовый прецедент выступает в роли модельного каркаса, к

которому можно подключать расширения, например, для обработки исключений. Отношение

«extend» в UML обозначается пунктирной стрелкой, направленной от расширяющего

варианта использования к базовому. При этом базовый вариант использования должен быть

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

Дополнительные возможности «включения», «расширения» и обобщения необходимо

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

понятной заказчику.

Выполняя анализ вариантов использования проектировщик:

• идентифицирует классы, участвующие в реализации потоков событий варианта

использования;

• распределяет поведение, реализуемое вариантом использования, между классами

(определение обязанностей классов);

• проводит унификацию классов анализа.

Диаграммы прецедентов определяют зачем (или с какой целью) актеры взаимодействуют

с системой. Прецеденты и их описание являются важнейшим артефактом этапа анализа

требований.

Для того, что бы ответить не только на вопрос «Зачем происходит взаимодействие с

системой? Но и как происходит взаимодействие?» необходимо будет обратиться к

диаграммам взаимодействия (sequence и collaboration) и деятельности (activity).

3.2.2.2. Диаграммы взаимодействия (Interaction Diagram)

Взаимодействие актеров с системой в целом или взаимодействие отдельных модулей

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

запросами). Для моделирования такого взаимодействия UML включает в свой состав

диаграммы взаимодействия: диаграмма последовательности действий (Sequence Diagram) и

диаграмма сотрудничества (Collaboration Diagram), которые позволяют с разных точек

зрения рассмотреть взаимодействие объектов в создаваемой системе. Как правило,

диаграммы взаимодействия охватывает поведение объектов в рамках одного конкретного

варианта использования.

Sequence Diagram (диаграммы последовательности)

Для построения диаграммы последовательности необходимо:

• идентифицировать каждое действующее лицо (объект) и изобразить для него линию

жизни. Крайним слева на диаграмме изображается объект, который является

инициатором взаимодействия. Правее изображается другой объект, который

непосредственно взаимодействует с первым, и т. д.;

• из описания варианта использования определить множество системных сообщений и их

последовательность;

• изображают системные сообщения в виде линий со стрелкой на конце между линиями

жизни действующих лиц и системы. Затем указывают имена сообщений и списки

передаваемых значений.

На диаграмме последовательности изображаются только те объекты, которые

непосредственно участвуют во взаимодействии, и не указываются возможные статические

ассоциации с другими объектами.

Линия жизни объекта (object lifeline) служит для обозначения периода времени, в

течение которого объект существует в системе и, следовательно, может потенциально

участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается

пунктирной вертикальной линией, ассоциированной с единственным объектом. Если объект

существует в системе постоянно, то и его линия жизни должна продолжаться по всей

плоскости диаграммы последовательности от самой верхней ее части до самой нижней.