АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
|
СОПРОВОЖДЕНИЕ ПРОГРАММ
Сопровождение программ — "ложка дегтя" для каждого программиста. Это всегда помеха при начале разработки какого-либо нового проекта, заставляющая отвлекаться от разработки проекта и возвращаться к старым программам и старым проблемам. Ничто не делает сопровождение настолько непривлекательным, как плохо документированный код, недостаточно полное начальное проектирование и отсутствие внешней документации.
Если большинство шагов разработки выполнено правильно, то сопровождение не будет вызывать серьезных проблем, а будет элементарной технической поддержкой и модификацией программного обеспечения.
ВЫВОДЫ
• Разработка программных систем — сложное мероприятие. Можно выделить следующие общие процессы по управлению разработкой ПО: составление плана-проспекта по разработке ПО — планирование и составление расписаний по разработке ПО; управление издержками по разработке ПО; текущий контроль и документирование деятельности коллектива по разработке ПО; подбор и оценка персонала коллектива разработчиков ПО.
• Обычно в организации одновременно разрабатывается несколько программных проектов. Для оптимального качества и скорости работы необходимо верно структурировать управление организацией.
• Каждая разработка проекта собирает вокруг себя команду специалистов (команду проекта), состоящую из конечного пользователя; разработчиков; начальника отдела; начальника отдела информационных систем; ответственного за гарантию качества; группы, ответственной за бета-тестирование.
• Необходимо соблюдать методологию управления проектом, которая делится на составляющие: предварительный анализ; четкую формулировку цели; составленные модели данных и словари; выходные формы; безопасность системы и данных; платформу и окружение; контингент будущих пользователей.
• Разница между понятиями "желание заказчика" и "конечный продукт" обычно очень велика. Мостом для их соединения должен быть первичный этап обследования проекта и составление технического задания на данный проект. Эта задача делится на три стадии: изучение требований заказчика, уточнение функциональной специфики задачи и техническое проектирование задачи. Если говорить о требованиях пользователя, то их необходимо соблюдать неукоснительно.
• Техническое проектирование — своего рода мост между функциональной спецификацией и фактической стадией кодирования. Это крайне важная стадия и халатно к ней относиться нельзя.
• Системное тестирование может состоять из трех отдельных фаз: системный тест или лабораторные испытания; опытная эксплуатация; приемочный тест.
• Сопровождение — нелюбимая программистами, но необходимая часть, дающая возможность для усовершенствования продукта.
Разработка программного обеспечения (ПО) подчиняется определенному жизненному циклу (ЖЦ). Укрупненно можно выделить три этапа: 1.Анализ. 2.Проектирование. 3.Реализация. Цель анализа - выяснить, что необходимо делать. Для этого определяются и специфицируются требования к системе, для чего в свою очередь разрабатываются функциональные модели, модели данных и интегральные модели для системы. Цель проектирования – определить, как с помощью имеющихся технологий сделать то, что требуется. Для этого строятся модели архитектуры клиент/сервер и детализированные модели отдельных модулей системы. Цель реализации – воплотить задуманное на предыдущих этапах в осязаемый программый продукт. На этом этапе используют диаграммы навигации по программе, диаграммы оконной навигации и т.п. Этап анализа является стратегически наиболее важным, поскольку остальные этапы направлены на то, чтобы наиболее эффективно достичь цели, поставленной на этапе анализа. Если разработанная система будет очень эффективно делать совсем не то, что нужно заказчику, проект в целом провалится. Поэтому при разработке современных информационных систем много времени уделяется анализу (моделированию предметной области). Нужно изначально договориться с заказчиком обо всех нюансах, чтобы не вносить изменения на более поздних этапах в режиме "пожарной команды". В качестве входной информации процесса спецификации требований выступают неформальные требования заказчиков, а результатом являются модели спецификаций, которые можно разделить на три группы: 1.Модели состояний. 2.Модели поведения. 3.Модели изменения состояний.
Ниже рассматриваются вопросы анализа требований к системе с использованием унифицированного языка моделирования (UML – Unified Modeling Lanquaqe). UML (Universal Modeling Language) - универсальный язык моделирования, который был разработан компанией Rational Software с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели системы к логической, а затем и к физической модели соответствующей системы. Любая задача, таким образом, моделируется при помощи некоторого набора иерархических диаграмм, каждая из которых представляет собой некоторую проекцию системы. Диаграмма (Diagram) - это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями). В UML определено восемь видов диаграмм [1]:
- диаграмма прецедентов (Use case diagram) - диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношения между ними;
- диаграмма деятельности (Activity diagram) - диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой;
- диаграмма классов (Class diagram) - структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношения между ними;
- диаграмма состояний (Statechart diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка изменения состояний;
- диаграмма последовательностей (Sequence diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий;
- диаграмма кооперации (Collaboration diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения;
- диаграмма компонентов (Component diagram) -диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними; относится к статическому виду системы;
- диаграмма развертывания (Deployment diagram) - структурная диаграмма, на которой показаны узлы и отношения между ними.
| Диаграмма прецедентов
Диаграмма прецедентов (вариантов использования) является исходной концептуальной моделью системы в процессе ее проектирования и разработки. Разработка диаграммы прецедентов преследует цели:
- Сформулировать общие требования к функциональному поведению проектируемой системы.
- Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
- Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Диаграммы прецедентов применяются для моделирования поведения системы с точки зрения внешнего наблюдателя. Поведение системы – это совокупность ее реакций в ответ на внешние события. Под реакцией понимается выполнение некоторого целостного набора функций и формирование отклика, имеющего определенную ценность для некоторого субъекта. Под субъектом понимают кого-то или что-то (человека, устройство, программу и т.д.) так или иначе взаимодействующее с системой, а некоторый целостный набор функций, имеющих определенную ценность для субъекта, именуют прецедентом. Сущность концепции прецедентов подразумевает несколько важных пунктов.
1. Прецедент представляет собой завершенный фрагмент функциональных возможностей (включая основной поток логики управления, его любые вариации (подпотоки) и исключительные условия (альтернативные потоки)). 2. Фрагмент внешне наблюдаемых функций (отличных от внутренних функций). 3. Ортогональный фрагмент функциональных возможностей (прецеденты могут при выполнении совместно использовать объекты, но выполнение каждого прецедента независимо от других прецедентов) 4. Фрагмент функциональных возможностей, инициируемый субъектом. Будучи инициирован, прецедент может взаимодействовать с другими субъектами. При этом возможно, что субъект окажется только на принимающем конце прецедента, опосредованно инициированного другим субъектом. 5. Фрагмент функциональных возможностей, который предоставляет субъекту ощутимый полезный результат (и этот результат достигается в пределах одного прецедента).
Выявление прецедентов основано на анализе задач, выполняемых субъектами и целей субъектов применительно к системе. Таким образом в любой системе существует некоторое множество субъектов. Каждому субьекту соответствует некоторый набор прецедентов с которыми данный субъект взаимодействует. Субъекты инициируют события приводящие к активизации того или иного прецедента. Результатом выполнения прецедента являются изменение состояния системы и/или отклик. Отклик направляется этому же или другому субъекту или может быть событием, активизирующим другой прецедент. Это означает, что в общем случае могут существовать прецеденты, которые не активизируются непосредственно ни одним субъектом. С другой стороны, субъекты, которым нельзя поставить в соответствие ни одного прецедента, смысла не имеют. В общем случае можно выделить основные субъекты и второстепенные. Основными считаются субьекты непосредственно инициирующие хотя бы один прецедент. Второстепенными считаются субьекты либо инициирующие прецедент опосредованно (побуждающие другой субьект инициировать прецедент), либо являющиеся получателями отклика. Между субъектами возможны зависимости. Одни субъекты (независимые) активизируют некоторый прецедент исходя из своих внутренних потребностей, другие (зависимые) делают это только в случае «просьбы» со стороны другого субъекта или в качестве ответа на отклик. По отношению к системе субьекты имеют двойственную природу. С одной стороны - это объекты внешней, по отношению к системе, среды. С другой стороны система должна хранить информацию о субъектах, чтобы «со знанием дела» взаимодействовать с ними, т.е. субъекты можно рассматривать как часть системы. При инфологическом проектировании субъекты рассматриваются как супертип пользователя, а каждый отдельный субьект - как тип пользователя. Между субъектами и прецедентами – основными компонентами диаграммы прецедентов – могут существовать различные отношения, которые описывают взаимодействие экземпляров одних субъектов и прецедентов с экземплярами других субъектов и прецедентов. В языке UML имеется несколько стандартных видов отношений между субъектами и прецедентами:
- Отношение ассоциации (association) - определяет наличие канала связи между экземплярами субъекта и прецедента (или между экземплярами двух субъектов). Обозначается сплошной линией, возможно наличие стрелки и указание мощности связи.
- Отношение расширения (extend) - определяет взаимосвязь экземпляров отдельного прецедента с более общим прецедентом, свойства которого определяются на основе способа совместного объединения данных экземпляров. Обозначается пунктирной линией со стрелкой, направленной от того прецедента, который является расширением для исходного прецедента, и помечается ключевым словом "extend" ("расширяет").
- Отношение включения (include) - указывает, что некоторое заданное поведение для одного прецедента включает в качестве составного компонента поведение другого прецедента. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров прецедентов всегда упорядочена в отношении включения. Обозначается пунктирной линией со стрелкой, направленной от базового прецедента к включаемому, и помечается ключевым словом "include" ("включает").
- Отношение обобщения (generalization) - служит для указания того факта, что некоторый прецедент А может быть обобщен до прецедента В. В этом случае прецедент А будет являться специализацией прецедента В. При этом В называется предком или родителем по отношению к А, а прецедент А - потомком по отношению к прецеденту В. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский прецедент.
Стандартным графическим обозначением субъекта на диаграммах является фигурка "человечка", под которой записывается конкретное имя субъекта. Стандартным графическим обозначением прецедента на диаграммах является эллипс, внутри которого содержится краткое название прецедента или имя в форме глагола с пояснительными словами.
Рекомендация. Диаграмму прецедентов рекомендуется выполнять c использованием программного продукта Enterprise Architect как диаграмму UML Behavior с типом Use Case.
Пример. Магазин видеопродукции. Магазин продает видеокассеты, DVD-диски, аудио-кассеты, CD-диски и т.д., а также предлагает широкой публике прокат видеокассет и DVD-дисков. Товары поставляются несколькими поставщиками. Каждая партия товара предварительно заказывается магазином у некоторого поставщика и доставляется после оплаты счета. Вновь поступивший товар маркируется, заносится в базу данных и затем распределяется в торговый зал или прокат. Видеоносители выдаются в прокат на срок от 1 до 7 дней. При прокате с клиента взимается залоговая стоимость видеоносителя. При возврате видеоносителя возвращается залоговая стоимость минус сумма за прокат. Если возврат задержан менее чем на 2 дня, взимается штраф в размере суммы за прокат за 1 день* кол-во дней задержки. При задержке возврата более чем на 2 дня - залоговая сумма не возвращается. Клиент может взять одновременно до 4 видеоносителей (прокат-заказ). На каждый видеоноситель оформляется квитанция. Клиенты могут стать членами видео-клуба и получить пластиковые карточки. С членов клуба не берется залог (за исключением случая описанного ниже), устанавливается скидка на ставку проката и покупку товаров. Члены клуба могут делать предварительные заказы на подбор видеоматериалов для проката или покупки. Каждый член клуба имеет некоторый стутус. Первоначально – «новичок». При возврате всрок 5 прокат-заказов, статус меняется на «надежный». При задержке хотя бы одного видеоносителя более чем на 2 дня, статус «новичок» или «надежный» меняется на «ненадежный» и клиенту высылается предупреждение. При повторном нарушении правил статус меняется на «нарушитель». Члены клуба со статусом «надежный» могут брать до 8 видеоносителей единовременно, все остальные – 4. С членов клуба со статусом «нарушитель» берется залоговая сумма. Клиенты при покупке товара или получении видеоносителя в прокат могут расплачиваться наличными или кредитной картой.
| |
| На рис.1 приведена диаграмма прецедентов для рассматриваемого примера. В этом примере можно выделить следующие субъекты и соответствующие им прецеденты:
- Менеджер – изучает рынок видеопродукции, анализирует продажи (прецедент «Проверка наличия товара»), работает с поставщиками: составляет заявки на поставки товара (прецедент «Оформление заказа»), оплачивает и принимает товар (прецедент «Прием товара»), списывает товар (прецедент «Списание товара»).
- Продавец – работает с клиентами: продает товар (прецедент «Продажа видео»), оформляет членство в клубе (прецедент «Оформление клубной карты»), резервирует (прецедент «Резервирование видео»), выдает в прокат (прецедент «Прокат видео») и принимает назад видеоносители (прецедент «Возврат видео»), отвечает на вопросы клиента (прецедент «Проверка наличия товара»).
- Время - ежедневно выполняется проверка просроченных возвратов, и по результатам проверки меняется статус членов клуба, а также рассылаются предупреждения (прецедент «Предупреждение»).
- Клиент - вынуждает продавца инициировать один из прецедентов..
Клиент не будут иметь непосредственного доступа к разрабатываемой системе (второстепенный субъекты), однако именно они является основным источником событий, инициализирующих прецеденты, и получателем результата работы прецедентов.
| Выделение субьектов и прецедентов - важная задача при построении диаграммы прецедентов, однако основная информация о требованиях к функциональному поведению проектируемой системы содержится в спецификациях прецедентов. Традиционно спецификация – описание с помощью текстового документа, что должна делать система после того, как субъект инициировал прецедент.Типичное описание должно содержать следующие разделы:
- Краткое описание
- Участвующие субъекты
- Предусловия, необходимые для инициирования прецедента
- Поток событий: - основной (и, возможно, подпотоки) - альтернативный
- Постусловия, определяющие состояние системы, по достижении которого прецедент завершается.
Описательная спецификация прецедента «Прокат видео»
| Раздел
| Описание
| | Краткое описание
| Клиент желает взять на прокат видеокассету или диск, которые снимаются с полки магазина или были предварительно зарезервированы клиентом. При условии, что у клиента нет невозвращенных в срок видеоносителей, сразу после внесения платы фильм выдается напрокат. Если невозвращенные в срок видеоносители есть, клиенту выдается напоминание о просроченном возврате.
| | Субъекты
| Продавец, Клиент.
| | Предусловия
| В наличие имеются видеокассеты или диски, которые можно взять напрокат. У клиентов есть клубные карточки. Устройство сканирования работает правильно. Работники за прилавком знают, как обращаться с системой.
| | Основной поток
| Клиент может назвать номер заказа или взять видеоноситель с полки. Видеоноситель и членская карточка сканируются и продавцу не сообщается никаких сведений о задержках, так, что он не задает клиенту соответствующих вопросов. Если клиент имеет статус «надежный», он может взять до 8 видеоносителей, во всех остальных случаях – до 4-х. Если статус клиента определен как «нарушитель», его просят внести задаток. Клиент расплачивается наличными или кредитной картой. После получения суммы, информация о наличии фильмов обновляется и видеоносители передаются клиенту вместе с квитанциями на прокат. О прокате каждого видеоносителя делается отдельная запись с указанием идентификационного номера клиента, даты проката, даты возврата, идентификационного номера продавца, полученной суммы.
| | Альтернативный поток
| У клиента нет членской карточки. В этом случае прецедент «Сопровождение клиента» может быть активизирован для выдачи новой карточки.
Видеофильмы не выдаются, поскольку у клиента есть невозвращенные в срок видеоносители.
Попытка взять на прокат слишком много видеоносителей.
Видеоноситель или кредитная карта не могут быть отсканированы из-за их повреждения
У клиента не хватило наличных или платеж по кредитной карте отклонен.
| | Постусловия
| Видеофильмы сданы напрокат, и база данных соответствующим образом обновлена
|
Рассмотренный пример относится к бизнес-моделированию, то есть моделируется деятельность некоторой организации. Кроме бизнес-моделирования существует системное моделирование, когда акцент делается на описание функций разрабатываемой информационной системы. Более подробно о системном моделировании см. Моделирование прецедентов
|
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | Поиск по сайту:
|
