Міністерство освіти і науки, молоді та спорту

Національний технічний університет України

“Київський політехнічний інститут імені Ігоря Сікорського”

Факультет ФІОТ
Кафедра ІПІ

РЕФЕРАТ

з дисципліни “Англійська мова професійного спрямування”

на тему: “Program design”

Виконав:
Кривоносюк В.В.
студент групи ІТ-01

Викладач:
Сергеєва О. О.

Київ 2023
Contents
Introduction...................................................................................................................3
Part 1. The role of program design phase in the software development lifecycle..........4
Part 2. Architectural design...........................................................................................4
Part 3. Detailed design...................................................................................................6
Summary.......................................................................................................................8
Summary Translation....................................................................................................9
References...................................................................................................................10
Glossary.......................................................................................................................11

2
 Introduction
In the field of social performance consulting, program design defines the
methods that organizations use to address a problem. A community development
organization may develop a small business grant program to improve the local
economy. Program design, in essence, is just a set of goals and instructions that the
person implementing the program should follow in order to make the process smooth
and the result satisfying.
In the field of software development, the term program design means something
similar. It stands for the process of progressing from a specification of a required
software solution to a description of the solution and comprises steps a programmer
should make before coding, i.e. during the early stages of development. The input to
the design phase is the specification of what the program should do. During this phase,
architectural decisions are made as to how the program will meet these requirements.
The output of the phase is a description of the program in some form that provides a
suitable basis for subsequent implementation. The process of program design is
divided into two subphases:
 Architectural design.
 Detailed design.
The program design is a vital part of the software development lifecycle, which,
in its core concepts, is the same for every program no matter the language, size or
complexity. But why?
Creating a program always involves devising a solution to a problem. Good
solutions only come from good design and good design only comes from giving
sufficient thought and effort to the problem and the ways of solving it. Detecting and
correcting an error becomes increasingly more difficult and costly as the product
moves through its life cycle, which means the sooner a “bug” is detected – the easier it
is to fix or avoid altogether. And that is the role of the design stage of the development
life cycle.
Program design also helps to ensure the following qualities of the solution:

Reliability
The program can be depended
upon always to do what it is
supposed to do
Maintainability
3
The program will be easy to
change and modify when need
arises
Readability
The program will be easy for the
program to read and understand
Portability
The program will be transferable
to a different computer with
minimum of modification.
Performance
The program causes tasks to be
done quickly and efficiently
Storage saving
The program is not allowed to be
necessarily long
Reliability
4
The program can be depended
upon always to do what it is
supposed to do
Maintainability
The program will be easy to
change and modify when need
arises
Readability
The program will be easy for the
program to read and understand
Portability
The program will be transferable
to a different computer with
minimum of modification.
Performance
The program causes tasks to be
done quickly and efficiently
5
Storage saving
The program is not allowed to be
necessarily long
 Reliability: the program can be depended upon always to do what it is
supposed to do.
 Maintainability: the program is easy to change and modify.
 Readability: the program is easy to understand.
 Portability: the program is transferable to a different computer with
minimum of modification.
 Performance: the program performs as quickly and efficiently as
possible.
 Storage saving: the program is not allowed to be unnecessarily long.
They are all important aspects of a program and are part of the ISO 9126
software quality standard.
This research paper will explain each of the two subphases of program design,
elaborating upon their details, specifics and relevance when developing solutions of
different scales and complexity. It will also provide a look into the software
development lifecycle, and show the role of the design process in it.
Part 1. The role of program design phase in the software development
lifecycle.
The software development lifecycle consists of six phases.

The design process is the second phase. It is when software architects and
6
developers make decisions on the high-level design of the software system. A technical
stack will be chosen, such as which languages, frameworks and libraries will be used
on the front and back end and other details such as the choice of database technology
and other third-party services.
Decisions will also be made regarding infrastructure, such as whether the
software will be cloud-hosted and if that will include public cloud, private cloud or a
hybrid approach and providers. Security requirements are an important part of the
design phase and will inform many of the decisions made.
During the design phase, stakeholders should be consulted about technical stack
options, risks, resources needed in the context of design decisions taken, time, budget,
regulatory constraints and others.

Part 2. Architectural design.

At the core of any solution lies an idea – some general design or plan that
defines the main points or steps. Software development is no exception. Before
proceeding with the coding of any application, no matter how big or small, complex or
straightforward, the developer should outline its architectural design.
The architectural design describes the program at a general level. It is usually
given in terms of the main components and their relationships, the primary algorithms
that these components use, and the underlying data structures. It serves as the blueprint
for the system and provides an abstraction for establishing a mechanism for
communication and coordination between the components.
There are many options to choose from when it comes to the architectural
approach in software design. For starters, a developer will have to decide on the
architectural structure of the software. There are multiple architectural patterns in
existence that can be applied.
1. Layered pattern.
This pattern can be used to structure programs that can be broken down into
groups of subtasks, each at a certain level of abstraction and providing services to
others. This pattern is used in desktop and web applications.

The 4 most common layers in a public information system are:

o Presentation layer (also known as the UI layer)
o Application layer (also known as the service layer)
o Business logic layer (also known as the domain layer)
o Data access layer (also known as the persistence layer)

2. Client-server pattern.
This pattern consists of two components: a server and a client. The server
component will provide services to the client. The client sends requests for services
from the server and the server provides related services to the client. Moreover, the
server continues to listen to client requests. This pattern is used in various online
7
 applications.
3. Master-slave pattern.
Like the client-server pattern, the master-service pattern consists of two
components: a master and a slave. The master component distributes the work
among identical child (slave) components and computes the final result from the
results returned by the slaves. This pattern is used in database replication and for
driver distribution for peripherals that are connected to a single bus.
4. Pipe-filter pattern.
This pattern can be used to structure and manipulate systems that produce
and process a stream of data. Each processing step is contained within a filter
component. The data to be processed is passed through the pipes. They can be used
for temporary storage or for synchronization purposes. This pattern is used for
implementing workflows and compilers.
5. Broker pattern.
This pattern is used to build distributed systems with discrete components.
These components can interact with each other via remote service calls. The broker
component is responsible for coordinating communication between components.
This pattern is used in broker software.
6. Peer-to-peer pattern.
This pattern divides the program into components called peers. A peer may
act as a client, requesting services from other peers, and as a server, providing
services to other peers. A peer may act as a client, as a server, or both, and can
change its role dynamically over time. This pattern is used in multimedia protocols,
file-sharing systems and cryptocurrency-based products.
7. Event-bus pattern.
This style mainly deals with events and has 4 main components; event
source, event listener, channel, and event bus. Sources propagate messages to
specific channels in the event bus. Listeners subscribe to certain channels. Listeners
are notified of messages posted on the channel they previously subscribed to. This
pattern is used in mobile development and notification services.
8. Model-view-controller pattern.
This pattern, also known as the MVC pattern, divides an interactive
application into 3 parts:
o Model - contains the basic functions and data
o View - displays information to the user (more than one view can be
selected)
o Controller - handles input from the user
This structure allows for separates internal and external ways of representing
the information. This pattern is used in web development.
Secondly, a developer will have to choose how the business logic will be
distributed between the software’s components. That decision depends on the

8
 software’s type (a website, game, etc.), how difficult a task the software is supposed to
solve and the environment it will have to work in. It could be a microservice
application with multiple small separately deployed systems that handle their
respective tasks, or a monolith where a single system is responsible for everything. It
could even be a combination of these two. It may need a separate system for
incorporating continuous integration and continuous delivery pipelines, or it will be
provided as a desktop application with an installation package.
The document where all of that information is aggregated is called the design
plan. The goals of having a design plan are to:
 Discuss system requirements and set expectations with customers,
marketers, and management staff.
 Act like a plan in the development process.
 Manage implementation of tasks, including detailed design, coding,
integration, and testing.

Part 3. Detailed design.

Once the architecture of the general components has been outlined, it’s time to
define how these components will work on the level of code. It deals with the
implementation part of what is seen as a system and its subsystems in the architectural
design. It is more detailed towards modules and their applications and defines the
logical structure for each unit and the interfaces for communication with others. This
is where the architectural design is refined to the stage where actual implementation
can begin.
During this stage:
o Each module’s responsibilities should be specified as precisely as
possible.
o Constraints on the use of its interface should be specified.
o Pre- and post-conditions can be identified.
o Module-wide invariants can be specified.
o Internal data structures and algorithms can be suggested.
A designer, however, must not over-specify the design. That is why this stage
involves using pseudocode. Using a programming language, one would naturally end
up implementing the module, perhaps unnecessarily constraining the approaches a
developer would use to accomplish the same job. And using natural language text slips
too easily towards ambiguity.

9
 Summary

An important part of software

engineering is to make a
rational choice of development style for
a given software
project.
One of the most important parts of software engineering is to make a rational
choice of development style for a given software project. And with a plethora of
patterns, tools, languages and architectural approaches this task can suddenly become
overwhelming even for a relatively simple application. This is exactly the problem the
program design is here to help us solve.
Program design analyzes software requirements in order to produce a description
of the internal structure and organization of a system that will serve as a basis for its
construction. Its role in the development of software is hard to overestimate. Not only
does it make our program’s design easy to understand and thus easy to maintain and
fix, it also potentially makes it more robust and reliable. Without the design phase any
application, no matter how big or small, would be just like a pile of garbage at the
junkyard – totally random and lacking any resemblance of structure.
Program design starts from the upmost level – defining the general components
and subsystems of the program and distributing the tasks between them. This process is
known as architectural design. It involves selecting the application’s architectural style
and the ways the responsibilities are distributed and handled. Not only does it help us
make the software a lot easier to understand, implement and support, but it also makes
deciding what technologies, languages and code patterns to use a whole lot easier.
Furthermore, it helps to prevent bugs and faults that may appear due to poor
understanding of the business requirements.
After the general design is done – we “zoom in” to define the details of
interaction between all the components of the system. It’s important to realize that what
is done at this point is not writing a ready solution. That stage will come later down the
software development lifecycle. The purpose of this stage is to merely define the
guidelines and generalized principles that the developers should follow in order to
ensure that the application fully corresponds to its requirements. Tools like pseudocode
are used to achieve this purpose.
As the second phase of the software development lifecycle, program design also
decides how well our application will stand the test of time and correspond to its
business needs. It helps to make sure we don’t miss a step or a part of the user
experience you might miss otherwise.
Software is not limited by physics, like buildings are. It is limited by imagination,
10
by design, by organization. In short, it is limited by properties of people, not by
properties of the world. “We have met the enemy, and he is us.”

11
 Summary Translation
Однією з найважливіших частин розробки програмного забезпечення є
раціональний вибір стилю розробки для програмного проекту. І з великою
кількістю шаблонів, інструментів, мов і архітектурних підходів це завдання
може раптово стати непосильним навіть для відносно простої програми. Це
саме та проблема, яку програмний дизайн допомагає вирішити.
У процесі програмного дизайну ми аналізуємо вимоги до програмного
забезпечення, щоб створити опис внутрішньої структури та організації системи,
яка слугуватиме основою для її побудови. Його роль у розробці програмного
забезпечення важко переоцінити. Це не лише робить дизайн нашої системи
простим для розуміння та безпечним, а й легким для обслуговування та
підтримки, що також потенційно робить програму надійнішою. Без етапу
проектування будь-яке застосування, незалежно від того, яке воно велике чи
маленьке, було б схоже на купу сміття на звалищі – абсолютно випадкове та без
будь-якої структури.
Розробка програми починається з найвищого рівня – визначення
загальних компонентів і підсистем та розподілу завдань між ними. Цей процес
відомий як архітектурне проектування. Це не тільки допомагає нам зробити
програмне забезпечення набагато легшим для розуміння, впровадження та
підтримки, але й значно спрощує прийняття рішення про те, які технології,
мови та моделі коду використовувати. Крім того, це допомагає запобігти
помилкам і несправностям, які можуть виникнути через погане розуміння
бізнес-вимог.
Після того, як загальний дизайн зроблений, ми «збільшуємо масштаб»,
щоб визначити деталі взаємодії між усіма компонентами системи. Важливо
усвідомлювати, що на даний момент ми не пишемо готове рішення. Цей етап
наступить пізніше в життєвому циклі розробки програмного забезпечення. Ми
лише визначаємо вказівки та загальні принципи, яких розробники повинні
дотримуватися, щоб переконатися, що додаток повністю відповідає усім
вимогам. Інструменти по типу псевдокоду використовуються для досягнення
цієї цілі.
Будучи другою фазою життєвого циклу розробки програмного
забезпечення, розробка програми також вирішує, наскільки наша програма
витримає випробування часом і відповідатиме потребам бізнесу. Це допомагає
переконатися, що ми не пропустимо крок або частину взаємодії з користувачем,
яку могли б пропустити інакше.
Програмне забезпечення не обмежене фізикою, як будівлі. Воно
обмежене уявою, дизайном, організацією. Коротше кажучи, воно обмежене
властивостями людей, а не властивостями світу. «Ми зустріли ворога, і він —
це ми».

12
 References
1. Higgins D. A. (1979). Program Design and Construction. United States
of America: Simon & Schuster.
2. Rylander S. (2022). Patterns of Software Construction: How to
Predictably Build Results (1st ed.). United States of America: Apress.
3. Dingle A. (2020). Software Essentials. Design and Construction (1st
ed.). United Kingdom: Chapman & Hall.

13
 Glossary
№ Word/ Phrase Translation
1 Client Кнієнт
2 To interact Взаємодіяти
3 Server Сервер
Розробка програмного
4 Software development забезпечення
5 To progress Переходити
6 Specification Специфікація
7 Solution Рішення, розробка
8 Project Проект
9 Stage of development Стадія розробки
10 Implementation Реалізація
11 Quality standard Стандарт якості
12 Developer Розробник
13 High-level design Високорівневий дизайн
14 Technical stack Набір технологій
15 Framework Каркас (фреймворк)
16 Library Бібліотека
17 Database База даних
18 Third-party service Сторонній сервіс
19 Cloud hosting Хмарний хостинг
Зацікавлена сторонаб
20 Stakeholder посередник
21 Component Компонент
22 Blueprint План
23 Architectural design Архітектурний дизайн
24 Communication Комунікація
25 Coordination Координація
26 Architectural pattern Архітектурна модель
27 To break down into Розбивати на
28 Layer Прошарок
29 Desktop application Комп'ютерний застосунок
30 Web application Інтернет застосунок
31 Application Застосунок
32 Request Запит
33 Service Сервіс

14
34 Peripherals Периферійні пристрої
35 Bus Шина
36 Stream of data Потік даних

Фільтр
37 Filter
38 Peer Вузол
39 Synchronization Синхронізація
40 Workflow Робочий процес
41 Compiler Компілятор
42 Discrete Дискретний
43 File sharing Поділ файлами
44 Multimedia Мультимедіа
45 Channel Канал
46 Business logic Бізнес-логіка
47 Environment Оточення, середовище
48 Combination Поєднання
49 Microservice Мікросервіс
50 Monolith Моноліт
51 Installation package Пакет установки
52 Requirements Вимоги
53 Expectations Очікування
54 Marketers Маркетологи
55 Management staff Менеджмент
56 Integration Інтеграція
57 Testing Тестування
58 To outline Винести, коротко описати
59 Module Модуль
60 To refine Уточнити
61 Constraint Обмеження
62 Invariant Інваріант
63 To exhibit Показувати
64 Pseudocode Псевдокод
65 Ambiguity Двузначність
66 To slip Висковзнути
67 Rational Раціональний
68 Basis Базис
69 Structure Структура

15
70 Guidelines Рекомендації

16