ВУЗ:
обычных текстовых редакторов, приложений электронных таблиц и систем электронной почты, используемых в других при-
ложениях. Однако другие представляют собой достаточно сложные пакеты, предназначенные преимущественно для исполь-
зования при разработке систем программного обеспечения. Например, некоторые CASE-инструменты включают генераторы
кода, которые по заданной спецификации на некоторую часть системы генерируют программу на языке высокого уровня,
представляющую собой реализацию этой части системы.
Вопросы для самопроверки
1. В чем состоит отличие между требованиями к системе и спецификацией на систему?
2. Кратко охарактеризуйте каждый из четырех этапов (анализ, проектирование, реализация и тестирование) фазы разра-
ботки в жизненном цикле программного обеспечения.
3. Охарактеризуйте различия между традиционной моделью разработки программного обеспечения (модель водопада) и
новым подходом, предусматривающим создание прототипов.
6.3. МОДУЛЬНОСТЬ
Одним из ключевых положений в разделе 6.2 было утверждение о том, что для модификации программы необходимо
разобраться в принципах ее работы или, по крайней мере, тех ее частей, которые относятся к делу. Зачастую этого нелегко
достичь даже в небольших программах, а в крупных системах программного обеспечения это было бы практически невоз-
можно, если бы не принцип модульности, предполагающий разделение программного обеспечения на поддающиеся осмыс-
лению элементы, каждый из которых сконструирован так, чтобы выполнять только определенную часть общей задачи.
Реализация модулей. Модульности можно достичь многими способами. В главах 4 и 5 было показано, как можно реа-
лизовать модули в виде отдельных процедур, которые впоследствии используются в качестве конструкционных элементов
для построения систем большего размера. В главе 5 модульность также обсуждалась в контексте объектно-
ориентированного подхода. В этом случае модули принимали форму объектов, каждый из которых имел собственную внут-
реннюю организацию, не зависящую от содержимого других объектов. Фактически рост популярности объектно-
ориентированного подхода к разработке программного обеспечения в значительной степени можно объяснить именно мо-
дульной структурой, изначально присущей этому методу.
Структурная схема – это традиционное средство представления модульной структуры, достигаемой за счет создания
процедур. На этой схеме каждый модуль (процедура) представляется прямоугольником, а связи между ними – стрелками,
соединяющими эти прямоугольники. Структурная схема, представленная на рис. 6.3, отображает модульную структуру про-
стой ролевой игры в жанре фантази, в которой игрок должен передвигаться по комнатам средневекового замка, решая в каж-
дой некоторую задачу, прежде чем ему будет позволено перейти в следующее помещение. На схеме показано, что модуль с
именем CoordinateGame (Координировать игру) использует модули InitializeGame (Инициализировать игру),
SimulateGreatHall (Имитация большого зала), SimulateDungeon (Имитация темницы) и SimulateTurret (Имитация
Рис. 6.3. Структурная схема простой ролевой игры
башни) в качестве абстрактных средств решения задачи. Точнее говоря, процедура CoordinateGame вызывает процедуру
InitializeGame для организации начала игры (узнать имя игрока, установить уровень сложности игры – начинающий, средний
или сложный – и т.д.). После каждого перехода игрока на новый уровень (т.е. перехода в следующую комнату) процедура
CoordinateGame вызывает другую процедуру, выполняющую имитацию требуемой комнаты, чтобы организовать выполне-
ние происходящих в этой комнате событий. Кроме того, на схеме показано, что каждый из модулей имитации комнаты об-
ращается к процедуре UpdateScore (Обновление счета), чтобы записать результаты, достигнутые игроком в данной комнате.
В то время как структурные схемы используются для представления внутренней структуры программного обеспечения
с процедурной организацией, диаграммы классов применяются для представления структуры систем с объектно-
ориентированной организацией. Диаграмма классов определяет набор существующих в системе классов объектов и описы-
вает взаимоотношения этих классов. На рис. 6.4 представлена простая диаграмма классов для упомянутой выше ролевой
игры. На этой диаграмме показано, что система состоит из объектов двух типов, PlayRecord (Запись игрока) и Room (Комна-
та), связанных отношением IsCurrentlyln (В данный момент внутри). Здесь объект типа PlayRecord содержит данные и процеду-
ры, относящиеся к конкретному игроку (имя, уровень, результат), а объект типа Room – данные и процедуры, относящиеся к опре-
деленной комнате (образ комнаты, возникающий на экране, и связанные с этой комнатой задачи).
Модуль
Initialize
Game
Модуль
Simulate
Great Hall
Модуль
Simulate
Dungeon
Модуль
Simulate
Turret
Модуль
Update
Score
Модуль
Coordinate
Game
Страницы
- « первая
- ‹ предыдущая
- …
- 145
- 146
- 147
- 148
- 149
- …
- следующая ›
- последняя »
