SOFTWARE

DEVELOPMENT
FROM A TO Z

Karoly Nyisztor
Copyright © 2018 Karoly Nyisztor

All rights reserved.

ISBN:
ISBN: 9781983172380
To my amazing mother
Software Development from A to Z
 CONTENTS
Foreword 1

SOFTWARE DEVELOPMENT: MYTHS VS. REALITY 3

Misconceptions About Becoming a Software Developer 4

Common Myths About Software Development 7

Activities Involved in Software Development 12

SOFTWARE DEVELOPMENT METHODOLOGIES - WATERFALL

& AGILE 14

Software Development Methodologies 15

Waterfall 16

The Pros and Cons of the Waterfall 20

Agile Methodologies 23

The Pros and Cons of the Agile Approach 26

Waterfall or Agile? 29

AGILE FRAMEWORKS: SCRUM & KANBAN 31

SCRUM Basics 32

The SCRUM Sprint Cycle 37

Sprint Planning 38
 Karoly Nyisztor

The Daily SCRUM 41

The Sprint Review and the Retrospective Meeting 42

The Burndown Chart 45

The Kanban System 46

Kanban Boards 48

CORE OBJECT-ORIENTATION CONCEPTS 50

Brief History of Programming 51

Objects 56

The Class 59

Abstraction 62

Encapsulation 64

Inheritance 67

Polymorphism 71

UML BASICS AND FUNDAMENTAL DIAGRAM TYPES 77

Introduction, UML Diagram Types 78

The Use-Case Diagram 82

The Class Diagram 86

Associations 96

Generalization 100
 Software Development from A to Z

Dependency, Aggregation, Composition and Realization 102

Sequence Diagrams 108

Activity Diagrams 114

State chart Diagrams 121

NEXT STEPS 124

Useful Links 128

Copyright 130
FOREWORD

More people than ever before are entering software development.

Software development pays well, and developers get treated very well. The
industry is booming, and the work is rewarding.

If you are reading this, you are most likely considering a change in career.
Perhaps you just want to learn more about software development. Whichever
the case may be, you are in the right place.

In this book, I’m going to talk about the core concepts of software
development using simple, easy-to-understand terms. No prior knowledge or
software development experience is required.

We start by clarifying some common misconceptions about software

development. Then, I’ll introduce the most popular software development
methodologies. You’ll learn about the Waterfall and the Agile approach.

We’re going to talk about two Agile frameworks, the Scrum and the Kanban
System.

Next, I’ll introduce the Object-Oriented Programming Fundamentals. You’ll

learn about inheritance, polymorphism, abstraction, data hiding and more.

Then, we’re going to delve into the Unified Modeling Language. You’ll learn
how to visually represent your software system using UML diagrams.

By the end of this book, you will know what software development is about.
You will understand the most critical terms, and you’ll be able to decipher and
model a software system using UML class, activity and sequence diagrams.

1
 Karoly Nyisztor

Let’s start our journey!

 CHAPTER ONE

Software Development: Myths vs. Reality

YOU KNOW, I THOUGHT WE COULD USE A GOOD MYTH ABOUT

TECHNOLOGY TO HELP GUIDE US THROUGH THESE PARTICULAR
MODERN WATERS RIGHT NOW.

- JEFF BRIDGES

3
MISCONCEPTIONS ABOUT BECOMING A SOFTWARE DEVELOPER

There are some widespread misconceptions about software development.

Some of them are so subtle that you won’t realize the truth till you spend some
time in this industry.

MYTH#1: YOU NEED A COMPUTER SCIENCE DEGREE

While a CS-degree is nice to have, it is not always required to work as a

software developer.

Learning to program is not an opportunity exclusive to formal institutions.

Nowadays, there are plenty of online resources where you can learn to
program.

Some may prefer in-person teachings like boot camps and private
programming coaches. Online courses are usually less expensive than boot
camps, whereas in-person education has the advantage of live human
interaction.

MYTH#2: IT’S TOO LATE TO START

Age has nothing to do with making a career switch into technology. All you
need to succeed is the drive, willingness to learn and work ethic. At coding
boot camps, you’ll see students of all ages and with various backgrounds. Some
may have little to no programming experience.

Your success in the classroom and after graduation is directly related to the
work you put in. It goes without saying that one who has no programming

4
 Software Development from A to Z

experience should start with the basics, and gradually learn more advanced
topics.

MYTH#3: YOU NEED TO BE A MATH GENIUS

A good programmer needs strong problem-solving skills, logic and a lot of

patience; however, serious math skills are rarely required.

You should familiarize yourself with some core algorithms and data
structures. Other than that, you’ll usually do just fine with basic algebra - unless
you work on special projects which require sophisticated algorithms and
advanced math.

MYTH#4: YOU NEED TO LEARN THE BEST PROGRAMMING

LANGUAGE

The truth is that you cannot compare programming languages. At least, not
without providing more context.

First, you should be clear about your goals. Say you want to become an iOS
developer. Then, you shouldn’t start learning Ruby. Swift or Objective-C is the
way to go!
Besides, if you start from scratch, the programming language doesn't matter.

You can pick any modern language to learn the fundamentals of

programming. Once you master those basics, learning a new programming
language won’t be a challenge anymore.

5
 Karoly Nyisztor

MYTH#5: YOU ARE DONE LEARNING

In certain professions, you can gather the required expertise over the first
couple of months or years. After that, you’ll do fine without having to learn
new stuff.

Well, this isn't true for software development. Technology is rapidly evolving,
and you have to keep your knowledge up-to-date.

New programming languages appear while others fade to dust. Popular

frameworks and SDKs become obsolete overnight. Well-known hardware or
software platforms suddenly disappear, and new ones emerge.

If you choose software development, be open and prepared to learn new

technologies and programming languages consistently.

THE ROAD TO BECOMING A GOOD SOFTWARE

DEVELOPER IS LONG AND BUMPY. YOU’LL NEED TIME
AND PATIENCE, BUT THE OUTCOME IS DEFINITELY WORTH
IT. DON'T GIVE UP!

6
COMMON MYTHS ABOUT SOFTWARE DEVELOPMENT

Now that we broke the stereotypes about becoming a programmer let’s

debunk some software development myths.

MYTH#1: SOFTWARE DEVELOPMENT MEANS WRITING A LOT OF

SOURCE CODE

Indeed, typing code is important. Yet, there are plenty of other activities
involved in the software development process - to list a few:

• Meetings - they may eat up a significant portion of a software

developer’s workday.
Whether we like it or not, meetings will happen.
Team habits, company culture, the chosen methodology and various
other factors can influence the length and the frequency of meetings.

• Communication - you’ll need to respond to emails, phone calls,

messages on Slack, Skype and so on. Also, Agile methodologies
require a fair amount of communication between team members.

• Software quality assurance

What that actually means is that you’ll have to implement and execute
all kinds of tests - for example unit tests, performance tests, usability
tests and so on.

• Documentation
Writing and reviewing documents is also an integral part of a software
developer’s work.
For instance, you’ll need to document your code - it may sound boring

7
 Karoly Nyisztor

at first, but code comments - if done right - are one of the most useful
resources produced by developers for developers.
Trying to find out what a code actually does can become a daunting
task if there are zero comments. As your job responsibilities grow,
you’ll need to write various technical documents like developer guides
or design documents.

I’m going to talk in more detail about some of these activities in the
upcoming chapters.

MYTH#2: CUSTOMERS KNOW WHAT THEY WANT

The truth is usually exactly the opposite. Most customers have only a vague
vision of their product. And if you’re not aware of this fact, you’ll learn it the
hard way.

Here’s an example to illustrate what I mean - it’s an actual job posting from
Upwork:

“LOOKING TO CREATE THE NEXT BIG SOCIAL MEDIA PLATFORM FOR IOS
AND ANDROID.”

While this is an extreme example, be prepared to meet similar customers

and project descriptions.

How should you handle situations like this? Some simple rules may help:

• Create draft plans and visual mockups of the product before actually
creating it.
By doing so, you’ll save a lot of time, energy and frustration.

8
 Software Development from A to Z

• Have frequent checkpoints, reviews with the customer.

Involving the customer early on ensures that the software evolves as
they originally envisioned it. Even if there were severe
misunderstandings, you only have to throw away the work done since
the last review.

• Be honest.
Many factors can influence the original deadline or budget.
Unexpected issues, technical debt, a sudden shortage of resources is
not uncommon; yet customers may be unaware of them, so the sooner
you let them know, the better.

MYTH#3: SOFTWARE CAN BE ESTIMATED ACCURATELY

Software estimations are essential since both the customer and the
development team must make decisions based on it.

Predictions are usually only accurate when making near-term forecasts.

Unfortunately, in the case of software projects, we are asked for long-term
estimations.

Although everybody admits that estimations are inaccurate, we’ll suffer the
consequences of missing our deadlines. These consequences include, but are
not limited to:

• Loss of credibility

• Frustration, internal team friction

9
 Karoly Nyisztor

• Poor morale, especially when the team has to work excessive hours to
meet a deadline.

• Low-quality software - if developers sacrifice quality to complete the

job.

• Project failure when estimations are consistently off, and the customer
has completely lost faith in your team's ability to deliver.

MYTH#4: THE MYTHICAL MAN-MONTH

The Mythical Man-Month represents the idea that adding people to a

development team makes it more efficient in a linear fashion.
In fact, adding more programmers to a project falling behind schedule delays
the project even further.

Complex projects can’t be split into discrete tasks that can be worked on
without communication. With every newly added developer, the
communication overhead increases.

Also, the newcomers need time to learn about the project. Thus, they’ll ask
their more insightful colleagues, who in turn will spend less time developing
the product.

All these add up and consume an even more significant quantity of the
available time. The output of the team decreases further with every newly
added programmer.

Fred Brooks describes this phenomenon in his book “The Mythical Man-
Month: Essays on Software Engineering.”

10
 Software Development from A to Z

You often hear as a funny analogy that “Nine women can’t make a baby in a
month” (also known as Brooks’ law).

11
ACTIVITIES INVOLVED IN SOFTWARE DEVELOPMENT

A developer needs to handle various tasks. Writing code is just one of them.

Here are the most frequent activities involved in the process of creating
software products:

• Collect and analyze requirements

Requirements can come from a customer, a colleague, or from another
team. Depending on the stakeholder, requirements can be well-
defined, vague, or utterly misleading. If a need is well understood,
chances are the client eventually receives what they wanted.

• Validate ideas, perform feasibility studies

Regardless of whether all requirements are well-defined and crystal
clear, some may be impossible to implement.
Technology constraints, lack of expertise, resource issues and other
unforeseen problems may prevent us from delivering the product.
Thus, it is imperative to double-check whether we can achieve what
the stakeholders expected.

• Define the architecture

The architecture of a software product or system is its blueprint; it
defines the static structures and the interactions between the
components. Creating prototypes and doing a proof of concept work
is sometimes also required, especially if the team has no prior
experience with the given technology.

• Implement & test

The implementation phase should also involve writing unit tests and

12
 Software Development from A to Z

sample applications. Thorough testing ensures that severe bugs don’t

slip through; testing is a crucial part of the development process.
Nobody can guarantee quality without validating the software.

• Create documents and guides

For software products, there can be many types of documents: design
documents, test scenario descriptions, user guides, API
documentation, just to name a few.
Not all software projects require all of them, and the type of
documentation also depends on the development methodology of
choice.

• Release, Support, and Maintenance

Once the software is tested and ready for release, there are still a lot
of other things to watch out for. Depending on the product, there may
be marketing, packaging, and distribution related tasks.
Resources should be allocated for support and maintenance. No
software is completely bug-free. Besides, customers may ask for
improvements and enhancements.

13
 CHAPTER TWO

Software Development Methodologies - Waterfall & Agile

SO MUCH OF WHAT WE CALL MANAGEMENT CONSISTS IN MAKING IT

DIFFICULT FOR PEOPLE TO WORK.

- PETER DRUCKER
SOFTWARE DEVELOPMENT METHODOLOGIES

You wouldn’t start cooking a meal without a recipe. Similarly, the

development of a software product also requires some sort of step-by-step
plan.

The process that describes the steps needed to build the software from start
to finish is what we call software development methodology.

Like cooking a meal without a recipe, ad-hoc software development leads

to problems. Without a plan the software quality will suffer, deadlines won’t be
met, and costs will get out of control. Thus, every software development
company or startup uses a development process.

Many different methodologies have been invented over time. Since projects
have different needs, choosing the right approach is not always an easy
decision to be made.

In the upcoming chapters, we’re going to talk about the plan-driven

Waterfall model and the change-friendly Agile approach.

Here’s a formal definition:

A SOFTWARE DEVELOPMENT METHODOLOGY DESCRIBES HOW TO

ORGANIZE THE ACTIVITIES INVOLVED IN THE SOFTWARE DEVELOPMENT
PROCESS.

Software development methodologies are collections of best practices. By

applying these practices, your project will go smoother, and you’ll increase the
chance of completing it.
WATERFALL

The Waterfall is a linear model. It defines development steps or phases. You

start executing one step, complete it and then start the next one. This approach
gives us a steady, downward order - hence the name waterfall.

WATERFALL:

- THE DEVELOPMENT PROCESS FLOWS IN CASCADES.

- EACH DEVELOPMENT PHASE REQUIRES THE PREVIOUS ONE TO BE
COMPLETED.

Let’s have a look at these phases.

First, we collect and analyze the requirements. The expected functionality of

the future application must be clarified with the stakeholders. All the details
must be documented thoroughly.
This very first phase is probably the most important one. When done right, the
Waterfall model will produce the expected outcome.

After collecting and analyzing the requirements, we can proceed to the next
phase. Here’s where we define the overall design of our software. Defining the
architecture is like creating the blueprint for a building. Thus, the design should
be as clear and detailed as possible.
The bottom line is this: the team should be able to implement the product
based on this plan.

We should address questions like:

• Which packages or components will form our system?

16
 Software Development from A to Z

• What are the fundamental types of each component?

• How do these types interact with each other to achieve the required
functionality?

• Is our software secure? How about performance?

• How does our software respond to errors? How do we handle edge

cases?

• Should we extend our system in the future?

• Which third-party components do we use?

The list can grow or shrink depending on the requirements we defined in

the previous phase.

The implementation comes next. The software development phase is usually

divided into smaller units. Each unit is then implemented and tested by
developers.

Once the development phase is completed, the product undergoes the

verification phase. During this step, the software is evaluated based on
predefined criteria.

We must check whether the product provides the functionality we agreed

on. Tests are executed to ensure that the software works as expected. We test
for functional, performance, security and usability issues.

17
 Karoly Nyisztor

The detected problems are recorded and fixed. The process goes on until all
severe bugs are fixed.

The verification phase may also bring to surface deeper bugs and critical
issues that may affect the planned release.

As soon as the testing phase completes and the given version is delivered,
the software enters the maintenance phase.
By definition, the maintenance phase is about fixing smaller bugs. But more
often than not, it may also include functional enhancements.

The client may come up with new requirements that involve substantial
changes.
You may feel tempted to squeeze in “just one more patch” in the maintenance
phase, but this is usually a bad idea. In such cases, we need to set up a new
waterfall project and repeat all the steps.

The Waterfall model is used for life-control, medical and military systems.

18
 Software Development from A to Z

This model requires us to clarify all the requirements and create a detailed plan
upfront.

WE CAN USE THE WATERFALL IF ALL REQUIREMENTS ARE PRECISELY

DEFINED AND WON’T CHANGE OVER TIME.

The Waterfall has received some well-deserved criticism for its inability to
respond to changes.

Due to its linear structure, new requirements can’t be considered at later

phases of the development process.

If the client changes their mind frequently, or our design misses essential
aspects, we’re going to hit problems during development or testing.

In such cases, we should follow a different approach.

19
THE PROS AND CONS OF THE WATERFALL

Let’s talk about the pros and cons of the Waterfall Model.

This model requires clarity in almost every detail before writing a single line
of code. This approach has a considerable benefit. The detailed design
document leaves no room for misunderstandings.

To come up with a detailed design, the architect has to perform a thorough

analysis of all the features and requirements for the given the software product.
While this can be challenging and time-consuming, it has the benefits of
spotting most of the issues that otherwise may appear later.

By identifying the problems early on, we can reduce redesign and bug-fix
costs at later stages.

NOTE, HOWEVER, THAT NO METHODOLOGY CAN GUARANTEE BUG-FREE

SOFTWARE.

The other benefit of having a detailed, up-to-date design document is that

information is not lost. The team setup usually changes over time. Imagine
what happened if the senior architect, who was in charge to oversee the entire
software project, suddenly leaves the company.

If all the knowledge and the details about the project were only in his head,
those who take over the project would have to reverse-engineer the project
based on the source code. For large, complex projects this may take up to
several weeks!

20
 Software Development from A to Z

This model is not well suited for abrupt changes. The Waterfall is based on
the assumption that both the requirements and the design can be defined at
early stages. This can lead to carving in stone some assumptions that may
become obsolete later on. The customer can change his mind and ask for new
features that do not fit well in the original set of features.

A customer who knows what he wants is every software professional’s dream

to come true; unfortunately, this rarely happens in real life.

Deciphering what the customers need, can be more challenging than you’d
imagine. Therefore, coming up with a precise and clear set of requirements is
time-consuming and even impossible in some cases.
If the requirements can't be clarified within a certain amount of time, an Agile
methodology may be a better choice.

Another caveat of the Waterfall model is the big initial investment that is
required to create a detailed design. Up to 40% of the overall development
time may be spent on architecture definition early in the software production
cycle. Besides, the development cannot go in parallel with the design definition
work.

The Waterfall model is best suited for projects that meet the following
criteria:

• The product is firm and stable

If you know quite precisely what has to be built, then you can safely
rely on the Waterfall Model. All the pros we brought up will make your
life easier.
Typically mature or legacy projects which have a stable feature set fall

21
 Karoly Nyisztor

into this category. Go for the Waterfall Model if the likelihood of

unexpected feature requests is low.

• The technology is reliable and clearly understood

If the environment your software is using or relying on - like the
platform, the SDK, the hardware, and so on - follows a stable,
predictable path, and every information is available, then the Waterfall
is a perfect choice.

• Procedures and controls to regulate all processes are in place

For the Waterfall Model to work, preconditions must be met. This
includes the capability to clarify vague requirements with the
customer, ability to write detailed design documents, in-depth
understanding and knowledge of UML and design patterns, quality-
awareness and willingness to write clean code based on a design
document.

22
AGILE METHODOLOGIES

Agile is a relatively new approach to software project management.

It all began with the agile manifesto in 2001. This manifesto was an attempt
to end the proliferation of methodologies that had developed.

The agile manifesto defines four values:

• Individuals and interactions over the processes and tools

This doesn't mean that we won't use processes and tools in agile
projects. We still need tools and processes, but they shouldn’t prevent
us from implementing the required features or changes.
Instead of enforcing people to follow a rigid process, we implement a
process that’s adaptive and responds to changes.

• Working software over comprehensive documentation

This doesn't mean that agile projects don't use documentation at all.
We should create documentation where it provides value. There’s no
need to create extensive documentation just for the sake of it.

• Customer collaboration over contract negotiation

Don't get this wrong either. Agile projects also require contracts to
manage customer expectations about costs and schedules. However,
unlike for plan-driven projects, there is a spirit of partnership between
the development team and the customer.

Due to the somewhat uncertain nature of agile projects, both parties

acknowledge that some requirements and details may need to be

23
 Karoly Nyisztor

redefined or clarified further as the project progresses. This kind of

partnership requires collaboration and trust.

• Responding to change over following a plan

Agile is different from plan-driven approaches and provides more
flexibility compared to the Waterfall model. The significant difference
is that agile welcomes changes even at the later phases of the
development cycle.
Some planning is also required for agile projects. However, we don't
try to come up with a detailed plan for the entire project before
starting any development activities.
As a consequence, we're not blocked until all the requirements are
clarified, and every question gets answered.

Now let's discuss how Agile deals with the problem that couldn’t be solved
with the Waterfall.

The main idea behind Agile is that we can deliver functional software
iteratively instead of delivering the entire project all at once. The work is broken
up into shorter chunks called sprints.

The Sprint is usually two to four weeks long. At the end of each sprint, the
team should provide something that's an improvement over the previous
sprint’s outcome.
This iterative approach provides an opportunity to review the product that’s
being developed frequently.

24
 Software Development from A to Z

Stakeholders have a chance to evaluate the software and provide their

feedback early on instead of waiting for the final product to be delivered. These
frequent checkpoints are super useful as they ensure that the project evolves
in the right direction.

Unlike the Waterfall, agile methodologies do not separate testing from

development. Testing is tightly integrated with development, and the entire
team owns the responsibility for the quality of the product. Also, involving the
business users in the development process stands at the core of agile
approaches.

There’s a strong relationship between the project team and the stakeholders
and business users. This model works best in situations where the requirements
can't be defined upfront.

Agile is a good fit for software projects that are depending on many
uncertain factors, and changes are to be expected. One of the significant
benefits of this collaborative model is that it usually leads to higher customer
satisfaction. Team members are likely more motivated by engaging customers
directly.

AGILE IS A WAY OF THINKING DEFINED BY THE AGILE MANIFESTO

VALUES AND PRINCIPLES.

Scrum and Kanban are examples of discrete methodologies that implement

the agile approach.

25
THE PROS AND CONS OF THE AGILE APPROACH

The Agile Model takes an iterative approach to development with regular

feedback intervals, which usually produces quick results consistently. These
quick iterations give the team the ability to adapt to new requirements or
market changes quickly.

ABRUPT CHANGES NEED MORE EFFORT THAN SUBTLE ONES.

Customers are usually happy about being involved in the software

development process. Although this may have additional costs, the benefits
are high.
The customer can track and influence the evolution of the software product.
This guarantees that less amount of work must be thrown away or rolled back
if some requirements are misunderstood.

Agility doesn’t come without some drawbacks and pitfalls, though.

• Estimations are often a guess-work

For large, complex software products, it is challenging to estimate the
required time and effort, especially at the beginning of the software
development lifecycle. Often, numbers are given based on individual
gut-feeling estimates.

• Customer involvement and close collaboration between team

members are time-consuming
Besides, team members should have the willingness and skills to
communicate with the customer and each other. Members of agile
teams should be experienced enough to adapt to changes quickly and

26
 Software Development from A to Z

to be capable of taking the required decisions. So, both professional

and soft-skills are needed.

• Although embracing changes stands at the core of the Agile Model,

frequent and abrupt changes can affect the team’s morale and
productivity.
The project can quickly get off track if the customer can’t clarify what
they want.

• Too little documentation can lead to maintenance, communication,

and knowledge sharing issues
This becomes a prevalent problem if key members leave the team.

With all that said, Agile Software Development is well-suited for projects
where:

• Requirements are incomplete or can't be defined precisely at early

stages of development

• The scope can change frequently

This can happen for various reasons, for example, due to
technology/hardware changes, or because the client is undecided.

• Clients must be integrated into the software development process

For example, clients trigger some features as they progress with their
product

• Technology is unknown or not well-documented and requires a lot of

experimenting, proof-of-concept work.

27
 Charles Nyisztor

Customers rarely have the required technical background to precisely define

what they want from a software product. Therefore, for many project situations,
the advantages of agile development outweigh the disadvantages.

28
WATERFALL OR AGILE?

The Waterfall is perceived as rigid and bureaucratic compared to Agile

methodologies. However, both have their place.

There are cases where a plan-driven methodology won’t work. If the level of
uncertainty is high and not all questions can be answered right away, then you
should probably choose an agile methodology. For other projects, a waterfall-
like approach is a better fit.

Let me give you some examples.

When developing a weapons control system, the requirements should be
clarified in advance and need to be stable. These kinds of projects are
expensive and changing the requirements midway would increase the costs
even more. A Waterfall approach makes perfect sense in this case.

Here’s another example (a real job posting from Upwork):

“LOOKING TO CREATE THE NEXT BIG SOCIAL MEDIA PLATFORM FOR IOS
AND ANDROID.”

Coming up with a detailed plan wouldn’t make sense as it would be based

on assumptions. The description is vague, and I’m pretty sure that the customer
can't describe what they actually need. This high level of uncertainty calls for
an agile approach. Creating “the next big social network” would require
multiple iterations.

Let’s sum it up: you should use the waterfall when you know what the final
product should be, and clients can’t change the scope of the project.

29
 Charles Nyisztor

Agile methodologies should be used when there’s much uncertainty

involved, the requirements are vague or rapidly changing, and clients can’t
precisely describe what the end-product should do.

30
 CHAPTER THREE

Agile Frameworks: SCRUM & Kanban

THE FAST-PACED DIGITAL AGE HAS ACCELERATED THE NEED FOR

COMPANIES TO BECOME AGILE.

- NOLAN BUSHNELL

31
 Karoly Nyisztor

SCRUM BASICS

The term “Scrum” comes from Rugby. It’s a method of restarting the play
that involves players packing closely together.
This collaborative model works well also in the software industry.

Scrum was introduced in software development with the goal to create a

simple, straightforward framework for completing complex projects.

SCRUM IS A WAY TO ORGANIZE TEAM WORK AROUND AGILE

PRINCIPLES.

THE SCRUM SPRINT

The work is organized in short, sustainable bursts of activity called sprints.

A sprint is usually two weeks long. The sprints should not be longer than two-
three weeks.

Keeping the sprint short ensures that the project is evolving in the right
direction. Longer sprints increase the chance that work must be undone.

Scrum is an Agile framework. Therefore, for each sprint, plenty of time is

allocated for communication, planning and review activities.

SCRUM TEAMS

A Scrum Team typically consists of around five to nine people.

Less than five people may not have enough variety of skills to complete all

32
 Software Development from A to Z

tasks. More than nine team members will cause communication overhead. And
trust me, I have proof for that.

There are three distinct roles in Scrum: Product Owner, Scrum Master, and
Team Member.

THE PRODUCT OWNER

The product owner represents the customer. Her duty is to clarify what the
client really wants.
Depending on their background, customers may not be able to define precisely
the product.
It is not uncommon to hear:

“- WE NEED AN IPAD APP FOR OUR WEB SHOP.

- BACKEND, REST API? I DON’T CARE, JUST BUILD THAT IPAD APP FOR ME.”

The product owner is in charge to make sure that the customer gets what
he really needs, and the team understands what they have to build.

The product owner holds the vision of the product. What that means is that
she communicates a lot with the client. She clarifies and documents the client’s
needs and expectations for the software product.

The product owner also owns the product backlog. She’s responsible for
prioritizing the user stories in the product backlog. User stories are used to
describe product features from the user’s perspective.

The product owner creates the acceptance criteria for the backlog items.
This is basically a checklist, which defines what has to be completed in order

33
 Karoly Nyisztor

to mark a backlog item finished. The list usually contains criteria related to
software quality, like for example unit test coverage, performance tests,
requirements related to documentation and so on.

The product owner should be able to clarify questions coming from the
team. Since she’s the bridge between the team and the client, she knows a lot
of details about the expected feature set and potential changes.

SCRUM is an agile framework. Nothing is carved in stone, and things might

change quickly.

A product owner must inform the team about upcoming changes, deviations
from the original plan and new features in a timely manner.

THE SCRUM MASTER

The Scrum Master acts as a coach and coordinates work within the team.
The Scrum master is a peer position, except it has different responsibilities. He
is not a ‘boss’ by any means, although this is misinterpreted in many cases.

His roles:

• Facilitator
The Scrum Master is continuously available to help the team in
removing any blockers or impediments that are preventing them from
doing their work.

34
 Software Development from A to Z

• Guardian
The Scrum Master acts as a guardian, so that unimportant, disturbing
events do not reach the team.

• Coach
The Scrum Master is responsible for guiding the team to higher levels
of self-organization, cohesiveness, and performance.

• Scrum expert and advisor

The Scrum Master helps the team in applying scrum and agile
practices.

TEAM MEMBERS

Scrum team members have complete authority over how project goals are
achieved. This also means responsibility and assumes that each member has
the required know-how and the capability to make decisions.

Team members provide and own the estimates. The product owner is
responsible for clarifying and prioritizing the user stories. If a user story is
unclear, it cannot be subject to estimation. How could you tell the amount of
work needed to complete a task if you don’t understand the task? Yet, it is not
uncommon that we must provide estimates based on gut-feelings, which
usually doesn’t end well.

The team members define how to do the work. Nobody outside the team
shall interfere with that. The team completes user stories. This activity involves
development, writing of unit tests, testing, fixing bugs, writing documentation,
DevOps activities and so on.

35
 Karoly Nyisztor

The team self-organizes to get the work done. If they need to talk, they can
organize ad-hoc meetings or sit together and do some pair-programming.

A Scrum team doesn’t need a manager to arrange meetings. They should

be able to decide whether such a discussion is required.

The Scrum team is cross functional; therefore, it doesn’t include developers

exclusively. In a Scrum team, we’ll typically see developers, designers, testers
and DevOps engineers. DevOps engineers are responsible for software
deployment, build infrastructure and network operations.

These are the basics of Scrum. Next, we discuss how the actual work is
organized.

36
THE SCRUM SPRINT CYCLE

SCRUM organizes the work in short development cycles called sprints.

The sprint is usually two-three weeks long. A project consists of multiple

sprints. For example, if a software system took three months to be completed,
that means about six sprints.

The sprint stands at the heart of Scrum. Sprints follow each other without
interruption until the project is finished.

Each sprint starts with a planning phase, followed by development related

activities. The sprint ends with a review. During the sprint review, the team
shows what they’ve achieved during the sprint. The customers can provide
their feedback about the product.

Finally, there is a retrospective meeting. This is where the team discusses

what went wrong and what went well during the sprint.

Although a good Scrum team is consistently looking for improvement

opportunities, the retrospective meeting is a dedicated opportunity to reflect
on how the team is doing and for finding ways to improve.

37
SPRINT PLANNING

Each sprint starts with a planning phase.

The planning consists of two parts. The first one is about understanding the
sprint goals. The second meeting is about breaking down the sprint goals to
manageable units of work and providing estimations.

PLANNING - SPRINT GOALS

During the sprint goal meeting, the product owner discusses the sprint goals
with the scrum team.

The product owner tells what she’d like to see completed by the end of the
sprint. She shares a list of prioritized topics (usually user stories) with the team.
The team and the scrum master can ask questions and collaborate with the
product owner to come to a good understanding of the sprint goals.

If the goals are clear, the team can continue with the sprint estimation
meeting.

PLANNING - SPRINT ESTIMATION

The product owner does not have to join this meeting. By now she should’ve
clarified everything with the team.

38
 Software Development from A to Z

During the effort estimation meeting, the team breaks down the user stories
into smaller units of work called backlog items. A backlog item must be small
enough to be completed within a sprint.

Then, each backlog item is decomposed into smaller tasks.

THE TASK IS THE SMALLEST UNIT OF WORK.

Any arbitrary team member can pick up a task and work on it independently.
The tasks of a backlog item may or may not depend on each other.

Highlighting the dependencies between tasks is essential. Obviously, you

can’t start working on a task if the ones it depends on are still pending.

After estimating the prioritized list of backlog items, it should become quite
clear whether all or only a subset of the backlogs fit in the given sprint.

The team shall only commit to the amount of work that can be completed
without compromising on the quality of the end result.
There is even a term called “line of commitment” which is actually a horizontal
line that separates the backlog items that did not fit in the current sprint from
backlog items the team committed to delivering.

I’d like to emphasize one of the basic concepts of Scrum.

Only the people who do the actual work know the effort it takes to complete
what they committed to. Nobody outside the team shall modify the sprint
backlog nor put pressure on the team to do more work than initially planned.

39
 Karoly Nyisztor

The sprint backlog shall not be changed during the sprint. This doesn’t mean
that unforeseen, serious issues must not be fixed. A good Scrum team always
allocates a buffer for bug-fixes and other, unplanned issues.

However, new backlogs must not be accepted during the sprint.

If suddenly new requests pop up, it’s the responsibility of the product owner
to prioritize them accordingly. Urgent feature requests can then be added to
the list of backlog items and discussed during the next planning.

Finally, I’d like to add that the sprint planning should be time-boxed. The
sprint goal-setting meeting must not be longer than one hour.

And the sprint estimation meeting should not exceed 60 minutes either. If
the team needs substantially more time to provide the estimates, chances are
that the backlogs are not clear enough - which in turn means that the goal
setting meeting was not successful.

40
THE DAILY SCRUM

After the planning is over, the team can start working on the backlog items.

Each day of the sprint starts with a brief meeting called “Daily Scrum.”
Sometimes it is also called stand-up, as everyone should stand, which
contributes to keeping this meeting short.

How short? It depends on the team size but shall not exceed 15-20 minutes.

During the daily scrum, each team member answers three questions:

• What did I work on yesterday?

• What am I going to work on today?

• Were there any issues or blockers that prevented me from doing my

work?

To keep the meeting short, only answer these three questions. Brief
conversations are allowed, and attendees can share ideas. However, details
must not be discussed during the stand-up.

41
THE SPRINT REVIEW AND THE RETROSPECTIVE MEETING

Sprint reviews mark the end of each sprint. It is also called “Demo,” as it is
the opportunity for the team to showcase what they’ve achieved in the sprint.

The sprint review is where the stakeholders have the chance to inspect the
product and see how it evolves. The customers can provide direct feedback
about the product being developed.
Actually, the primary purpose of the review meeting is to trigger a conversation
between the team and the stakeholders.

The product owner collects the findings of the review meeting and creates
new product backlogs if needed.

A sprint review shall not be longer than one hour per sprint week. If a sprint
is two weeks long, the sprint review would be maximum two hours long.

The Scrum methodology keeps the frequency and the length of meetings at
a practical minimum. Agile is all about communication, yet useless meetings
should be avoided.

The final Scrum ceremony is the retrospective meeting. The retrospective aims
to improve the performance of the team.

Team members address the following questions:

• What went well during the sprint?

42
 Software Development from A to Z

• What could’ve gone better?

• What could be improved in the next sprint?

Ideally, the team identifies one improvement that can be implemented

immediately.

Let me give you a real-life example.

During such a retrospective, somebody brought up that our central build

server has become very sluggish. This affected the productivity of the entire
team, as we had to wait for the build server whenever we submitted a code
change.

The build server had to validate each code change by re-building the
software. And the time it took to receive a green signal from the build server
has been consistently increasing.

A short chat with our DevOps engineer revealed the core problem. As it
turned out, the server was not only building the software after each code
change, but it also ran *all* unit tests.
Some of these tests were very time-consuming, so no wonder that the server
became sluggish.

After spotting the core problem, finding the solution was only a matter of
minutes. We re-configured the build server to run the lengthy unit tests once
every night. The results were automatically e-mailed to each team member.

This change brought a measurable boost to the overall team performance -

and saved some money on electric bills, too.

43
 Karoly Nyisztor

By now, you should have a good understanding of Scrum. Agile

methodologies and Scrum are quite widespread nowadays, so you’ll probably
find this knowledge useful.

44
THE BURNDOWN CHART

Since a sprint has a finite lifespan, it is essential to track the progress.

The burndown chart is a simple and powerful way to represent the team’s
progress visually.

Time is represented on the horizontal X-axis, and the scope on the vertical,
Y-axis. The ideal burndown is linear; however, that almost never happens in
reality.

In real life, the remaining work may suddenly change as tasks are added or
removed. Also, sometimes the team’s original estimates may be wrong, and
the amount of required work proves to be way more or considerably less. In
such cases, the chart will show sudden spikes or dips.

The burndown chart is not a means to “keep an eye” on team members,

since the assumption is that the team can handle the work they committed to.

Tracking the team’s progress is rather for transparency and to identify

possible blockers, unbalanced workloads or other issues which might affect the
team’s productivity.

Burndown charts are used to reflect the sprint’s progress, and to track
whether the scope can be achieved within the given timeframe.

45
THE KANBAN SYSTEM

The Kanban system was first used by Toyota to improve the efficiency of
mass-producing cars. The system can be applied successfully to creating
software products.
The initial goal was to improve the efficiency of producing a large number of
automobiles. Producing cars consists of several processes, where parts get
created and handed over to the next process.

If any process produces more parts than what could be used by the next
production step, the excess must be stored. Stocking large amounts of unused
parts result in inventory issues, inconsistencies and creation of waste.

To solve this problem, Toyota created a quick-response production plan,

which harmonizes inventory levels with actual consumption.

The idea was borrowed from supermarkets. A supermarket stocks the items
needed by its customers based on when they are requested and, in the amount,
needed. The customer goes to the supermarket when he needs the given
products and retrieves them in the amount required.

If a product is overbought, the supermarket adapts by increasing the

available amount of that product. On the other hand, if customers don’t buy a
product, the supermarket won’t order more from its suppliers.

This simple pull system avoids overproduction, waste and excessive

inventory. Making only what and when is needed, in the required amount
needs coordination between processes. Toyota employed Kanban signs to
communicate to a preceding process which parts have been used. New parts
are produced on-demand. This approach is also called “just-in-time.”

46
 Software Development from A to Z

Kanban can also be applied to software.

The process of developing software can be thought of as a pipeline. Feature

requests are entering the pipeline on one end, and improved software is
emerging from the other end.

A bottleneck in a pipeline restricts flow; the throughput of the entire pipeline

is limited to the performance of the bottleneck.

Here’s an example.
If developers are only able to implement five features per development cycle,
whereas the customer submits ten feature requests each sprint, the throughput
of the pipeline will be limited to five.
If this limitation remains uncovered, then work will start to pile up in front of
the developers.

To keep up with the high amount of work, developers will start to cut
corners, and quality will inevitably suffer. More bugs will appear, causing
problems to the users, and fixing them will just increase the pressure on
developers.

Kanban reveals bottlenecks with a simple, yet powerful visualization system

called “Kanban Boards.”

47
KANBAN BOARDS

Kanban uses a big board to visualize pending work and the current capacity
assigned to the given development phase.

Each column represents a phase in the development cycle. The cards

represent work items as they flow through the development cycle. On top of
each column, there is a number representing the limits on the number of cards
allowed for given phase. Limiting the amount of work-in-progress at each step
in the process prevents overproduction and reveals bottlenecks on the go.

There are different ways to layout Kanban boards. Feel free to adapt them
to your needs.

The simplest form has a “To Do,”” Doing” and ”Done” setup, which will work
nicely for one-person or straightforward projects.

For more complex projects and team setup, you’ll need more details. A
typical board to cover the needs of such a setup is shown below.

48
 Software Development from A to Z

Note that some columns are split in two: ”Doing” and ”Done.” Cards that are
moved to the “Done” column can be pulled by the next phase.
Cards are moving from ”Doing“ to ”Done,” freeing up slots in the ”Doing”
column. Based on the available capacity, new cards can be pulled by the given
process.

This simple mechanism prevents work to pile up and shows bottlenecks

dynamically.

49
 CHAPTER FOUR

Core Object-Orientation Concepts

CERTAINLY NOT EVERY GOOD PROGRAM IS OBJECT-ORIENTED, AND NOT

EVERY OBJECT-ORIENTED PROGRAM IS GOOD.

- BJARNE STROUSTRUP

50
BRIEF HISTORY OF PROGRAMMING

This Dilbert comic walks us through the history of programming. It's a bit of
an exaggeration, but programming was entirely different a couple of decades
ago.

Nowadays it is easy to get started with programming. There are various

visual tools and sophisticated development environments that make learning
fun.

We can program drones and robots, create 3D-games or augmented reality

apps. We can achieve all that without having to learn for years. We’re lucky to
have all these great tools today.

Initially, computer programs were big, contiguous chunks of code. The

unstructured programming was the earliest programming paradigm. The code
consisted of sequentially ordered instructions. Each statement would go in a
new line. Source code lines were numbered or identified by a label.

51
 Karoly Nyisztor

This simple, Sinclair Basic program converts from Fahrenheit to Celsius

degrees:

10 PRINT "Fahrenheit", "Celsius"

20 PRINT
30 INPUT "Enter deg F", F
40 PRINT F, (F-32)*5/9
50 GO TO 30

As the programs grew in complexity, the drawbacks of this approach had

become apparent. Maintaining or even understanding such a code base was
challenging. To make any changes or improvements, you had to check the
statements line by line.

This task becomes more and more difficult as the number of code lines
increases. Non-structured programming has received much criticism for
producing hardly readable, so-called “spaghetti” code.

THE TERM SPAGHETTI CODE IS A PEJORATIVE DESCRIPTION FOR

COMPLICATED, DIFFICULT TO UNDERSTAND, AND IMPOSSIBLE TO
MAINTAIN SOFTWARE.

Structured programming emerged in the late 50s. Structured programming

languages break down code into logical steps. They rely on subroutines, which
contain a set of instructions to be carried out. Here’s an example of a program
written in C, which is a procedural language:

#include<stdio.h>
int sum(int, int);

int main()
{
int x, y;
int sum;

printf("Enter the first integer number: ");

52
 Software Development from A to Z

scanf("%d", &x);

printf("Enter the second integer number: ");

scanf("%d", &y);

sum = sum(x, y);

printf("x: %d, y: %d\n", x, y);

printf("Sum: %d\n", sum);

return 0;
}

The function called main() is the entry point of our program. It calls the sum()
function to add the two numbers entered by the user.

int sum(int x,int y)

{
int sum;
sum = x + y;
return sum;
}

We can define additional methods. For example, if we need to calculate the

average of the two numbers, we could create a function like this:

float average(float x, float y)

{
return (x + y) / 2;
}

These subroutines operate on variables and data structures. A *variable*

represents a value of a given type that can be identified using a name.

int x, y;
float salary;

53
 Karoly Nyisztor

We use the name of the variable to access the stored value, which lets us
modify the value during runtime.
In the following example, we declare a variable ‘x’of type int and assign it the
value 10. In the next line, we change the value of the variable to 42. Finally, we
increment x, so its value becomes 43.

int x = 10 // x has a value of 10

x = 42 // x is now 42
x = x + 1 // x is now 43

A data structure is a way of organizing and storing data in a computer program.

Here’s a C structure that aggregates the information needed to represent an
employee. It has a property called ’identifier’ of type int, a ’name’ which can be
30 characters long and a ’salary’ property of type float.

struct employee {
int identifier;
char name[30];
float salary;
};

Structured programming was a significant improvement compared to the

monolithic coding practices. Named functions improved the readability of the
computer programs. The development time could be reduced substantially.

Even with the improved quality, developers started to face new challenges
as the programs got bigger and bigger. Structured programming could not
address all the increased complexity.

Object-orientation was the next big step in the evolution of the

programming paradigms. Object-oriented languages appeared in the 80’s.

The main idea was to split apart the program into self-contained objects.
Each object represents a part of the system that gets mapped to a distinct

54
 Software Development from A to Z

entity. Basically, an object functions as a separate program by itself. It operates

on its own data and has a specific role.

The objects that form the system interact with each other. Object-orientation
aims to bring the world of programming closer to the real world.

55
OBJECTS

While structured programming relies on actions, object-oriented

programming is organized around objects.

An object represents a thing. Just like in real life, objects can be simple or
complex.

A golf ball is an object, but so is the Falcon Heavy*.

(*)Falcon Heavy is a partially reusable heavy-lift launch vehicle designed

and manufactured by SpaceX. SpaceX conducted Falcon Heavy's maiden
launch on February 6, 2018, at 3:45 p.m. EST (20:45 UTC). The rocket
carried a Tesla Roadster belonging to SpaceX founder Elon Musk as a
dummy payload.

The way we define the object depends on the level of detail we need.

With the launch of the Falcon Heavy, they also sent the Tesla Roadster with
“Starman” in the driver’s seat toward Mars orbit. Objects may contain or refer
to other objects. This can also happen in the object-oriented world.

We can describe objects using their properties. They can have attributes like
name, color, weight, velocity.

A golf ball can be completely white, colored or it may even glow in the dark.
It has a weight and a price. Some properties like its position, speed, and
acceleration can change, while other attributes (its color for example) stay the
same.

56
 Software Development from A to Z

All these properties describe an object in the real world. This approach also
works in an object-oriented language.

Objects have their identity, their own state. Changing the state of an object
doesn’t change the state of other objects. If we hit a golf ball, it won’t affect all
the other balls. Their state is independent, and each has its private identity.

Besides properties and identity, an object has its own behavior. The behavior
of an object is what it can do.

“THE BLACK DOG BARKS.”

In this sentence, we identify one object: the dog.

“Bark” is the behavior, or the action performed by the “dog” object. And
“black” is its color, one of its attributes.

We can identify the object easily since it’s the noun in the sentence. The verb
is the behavior, and the adjective is the property.

57
 Karoly Nyisztor

We describe an object using its properties, identity, and behavior.

Quite straightforward, but how do we make this work in our code? For that,
we need to introduce a new concept, the “class.“

58
THE CLASS

Building an object-oriented system starts by identifying the potential

objects, their attributes, and responsibilities. We need to have a class before
we can create an object.

A CLASS IS THE BLUEPRINT OF AN OBJECT.

You can think of a class as a plan, a description of what an object will be. An
object is a realization of this blueprint.

Let’s say you want to use a Pokémon[1] in your program. A class called
Pokémon would provide a blueprint for what the Pokémon looks like and what
it can do.

The class tells us that each object has a name, armor level and hit points. It
doesn’t say what the name or the armor level is.

A Pokémon can attack, and it can defend itself. These two actions define its
behavior.

59
 Karoly Nyisztor

We created a class by giving it a name, declaring its properties and actions.

We call these actions methods. Methods are blocks of code that can be
called to execute certain operations. They may take input parameters and can
also return values. Methods are like functions in structured programming
languages. The methods are basically functions embedded in a class.

Given this class, we can create objects based on it. Upon object creation, we
provide the values for the attributes declared in the class. Each object will have
a name, armor level and hit points. The attack() and defend() behavior is
provided by the class.

Using this blueprint, we can create as many instances as we need.

Another big benefit of classes is that we can package them into libraries or
frameworks. This lets us reuse them in other programs as well.

60
 Software Development from A to Z

All modern object-oriented programming languages provide such built-in

frameworks. We don’t have to reinvent the wheel and implement the
functionality that’s readily available. Instead, we can focus on creating and
using the objects in our programs.

Each program has different requirements. The pre-made classes will rarely
cover all our needs. You’ll often find yourself creating your own classes.

We covered the object and the class. Next, we’ll take a look at the core
object-orientation principles.

61
ABSTRACTION

Abstraction is a way of describing complex problems in simple terms, by

ignoring some details. Eliminating the nitty-gritty details let us focus on the
bigger picture. We can dig deeper once we have a broader understanding.

How does abstraction work?

If I say cat, you know what I’m talking about. I don’t need to say I was
thinking of a male Persian cat, if it’s a kitten, if it’s big or small. You understand
that I was talking about a cat.

We are naturally good at generalizing things. We skip the irrelevant details,

but people can still understand us. That’s because our brains are wired to
understand abstract ideas like cat, house or car.

Abstraction works the same way in the object-oriented world. When we start
defining a class, we focus on the essential qualities of that class.

62
 Software Development from A to Z

FOCUS ON ESSENTIAL QUALITIES, DISCARD UNIMPORTANT ONES.

Back to our Pokémon example. We started with the most important

attributes and methods. We don’t need details like age, weight or height. These
attributes are unessential in our current application.

That’s how abstraction works. We focus on what’s important and ignore all
the details we don’t need.

63
ENCAPSULATION

The next fundamental idea to keep in mind when dealing with OOP and
classes is called encapsulation.

We encapsulate something to protect it and keep its parts together. Think

of how medicine is enclosed in a shell called capsule.

In object-orientation, this translates to packing together our properties and

methods in a class.

Encapsulation also means hiding the gears and the levers.

Here’s an example. We can use a phone without understanding electronics.

We don’t need to know how the touchscreen, the camera or the logic board
works.

Similarly, we don’t want to expose the inner workings of our class. An object
should only reveal the essential features. This concept is called data hiding.

By hiding its internal details, the object is protected from external

interference.

64
 Software Development from A to Z

We restrict clients from modifying the object in ways we did not originally
plan, whether it's intentional or accidental. Additionally, we prevent other parts
of the system from relying on properties or behavior that may change.

If you replace your phone’s battery, that won’t affect the way you use your
phone. That’s because you only interact with the touchscreen.
Changes in the inner workings of your phone don’t matter to you. Our classes
shouldn’t be any different either.

If we expose unnecessary details, any changes to those attributes or

methods may affect other parts of the system. Whereas if we restricted access
to that data or behavior, we don’t have to worry about the ripple effect of our
changes.

Data hiding is not about selfishly keeping stuff for ourselves. It's rather about
protecting our classes from unwanted external dependencies .

As a rule of thumb:

EXPOSE ONLY AS MUCH OF YOUR CLASS PROPERTIES AND METHODS AS

NEEDED FOR NORMAL USAGE.

65
 Karoly Nyisztor

Data hiding plays an essential role in keeping the dependencies between

objects to a minimum.

A tightly coupled system, with most of the objects depending on each other,
is the unmistakable sign of a bad design. Updating or maintaining such a
system is a pain. Any tiny modification cascades down and requires you to
change other parts of the system, too. It’s like a never-ending nightmare.

Object-oriented programming principles are here to make our lives easier.

Next up is the idea of “Inheritance.”

66
INHERITANCE

Inheritance is a key concept in object-oriented programming. Without

inheritance, we’d end up writing similar code over and over again.

Inheritance means code reuse. That is, reusing an existing class

implementation in new classes.

Let us start with an example. We modeled the Pokémon class with the main
properties and behavior in mind. Given this class, we were able to create our
Pokémon instances.

Now, what if we need new types, like electric, water or flying Pokémon?
We have to create classes since these new types have special abilities.

67
 Karoly Nyisztor

The Pokémon class has the properties “name,” ”armor” and ”hit points,” and
it can attack and defend itself.
The Electric, Water and Flying Pokémon have all these properties, and they are
also able to attack and defend themselves. Additionally, they also have
specialized functionality.

An Electric Pokémon has the ability to ”Wild Charge.” This attack is only
available to Electric-type Pokémon. “Aqua Tail” is a damaging Water Pokémon
move, and Flying Pokémon can perform the ”Dragon Ascent” attack.

As you’ve probably realized, the three new classes are almost identical to
the Pokémon class. The only difference is the special attack type.

We could add all these new behaviors to the Pokémon class. If we did that,
we’d end up in a class that has too many responsibilities.

Suddenly, all Pokémon objects could swim and fly and discharge electricity.

68
 Software Development from A to Z

We definitely don’t want that. Our classes should be simple. They need to
have a well-defined purpose.

OBJECT-ORIENTATION IS ABOUT GRANULARITY AND SEPARATION OF

CONCERNS.

EACH CLASS SHOULD FOCUS ON ONE SET OF SPECIFIC

FUNCTIONALITIES AND DO THAT WELL.

Creating one-size-fits-all, monolithic classes is a major mistake in object-

oriented software development.

So, how about keeping these classes separate? That sounds better. But now,
we keep repeating the same code for the common functionality. There must
be a better way.

Indeed, object-oriented programming languages have a solution for this

kind of problem: Inheritance.

A class can inherit all the attributes and behavior from another class. In our
case, we let ElectricPokémon, WaterPokémon, and FlyingPokémon inherit from
the Pokémon class. The data and the behavior from the Pokémon class are now
available to all these classes, without us having to write a single line of code.

Now we can add specialized behavior or attributes to the classes that inherit
from Pokémon.

69
 Karoly Nyisztor

If we enhance or modify the Pokémon class, all the other classes will
automatically receive those changes.

In object-oriented terms, Pokémon is a parent or superclass. Whereas the

ElectricPokémon, WaterPokémon, and FlyingPokémon are subclasses or child
classes.

Inheritance is a powerful idea that can save us from a lot of typing. Besides,
it paves the road to another handy feature called “Polymorphism.”

70
POLYMORPHISM

Here’s another term you’ll often hear when it comes to object-orientation:

Polymorphism.
The word has Greek origins, and it consists of two words: “polys,” which means
many, much and “morphē,” meaning form or shape.

If you look up the word polymorphism, you’ll find the following definition:

THE CONDITION OF OCCURRING IN SEVERAL DIFFERENT FORMS.

How does this apply to programming?

To understand how polymorphism works, we have to revisit the idea of

inheritance. Here’s our Pokémon superclass and its subclasses.

The Electric, Water, and FlyingPokémon all inherit the data and the behavior of
their superclass. So, they have a “name,” ”armor,” ”hit points” and they can attack
and defend themselves.

71
 Karoly Nyisztor

The WaterPokémon inherits the attack behavior from the Pokémon superclass.
Now, what if we need WaterPokémon types to cause more damage than basic
Pokémons?

For that, we need to provide a specialized implementation of the attack behavior.

This is what we call method overriding.

By overriding a method of the superclass, we tell that we want a different

behavior in our subclass than the one we inherited.

Method overriding is straightforward: we re-implement the method with the

same name and parameters as the one defined in the parent class and provide our
own behavior.
By doing so, our WaterPokémon objects have a different attack() behavior than
their Pokémon superclass.

Calling the attack() method on the Electric and Flying Pokémon objects use the
logic implemented in their superclass since we did not override the attack() method
in their case.

72
 Software Development from A to Z

So, that’s method overriding. Polymorphism lets us work with objects created
from any of these classes. We don’t need to know whether it’s a Water, Flying or
Electric Pokémon instance to call any of the common methods defined in the
superclass.

We could create an army of mixed Pokémons and tell them to attack at once.

Each of them executes the right attack() method without us having to know their
exact type. These objects are all instances of the Pokémon type or one of its
subclasses, and that's all we know.

73
 Karoly Nyisztor

POLYMORPHISM IS ABOUT WORKING FREELY WITH INSTANCES OF MANY

DIFFERENT CLASSES THAT SHARE A COMMON SUPERCLASS.

It’s probably easier to grasp it when using it in a real program, so let me show
you an example. I’m going to use Swift and Xcode on a Mac.

We’ll implement the Pokémon class and all the subclasses. This is an overly
simplified example, but it’s good enough to show you how polymorphism works in
a real program. So, here’s our Pokémon class. The attack() method displays a
message to the console.

class Pokémon {
var name: String

init(name: String) {
self.name = name
}

func attack() {
print("Pokémon attack!")
}
}

The Electric, Water and Flying Pokémon classes inherit from the Pokémon class.
This is how we do it in Swift: we put the name of the superclass after the name of
the child class separated by a colon.

class ElectricPokémon: Pokémon {

74
 Software Development from A to Z

class WaterPokémon: Pokémon {

class FlyingPokémon: Pokémon {

I override the attack() method in the WaterPokémon class. To specify that I’m
overriding a method in the superclass I’m using the ’override’ keyword. For this
example, we’ll simply display a different message:

class WaterPokémon: Pokémon {

override func attack() {

print("WaterPokémon attack!")

Let’s create some Pokémon instances. One Pokémon object, a WaterPokémon,

then an Electric and a FlyingPokémon, too.

let eevie = Pokémon(name: "Eevie")

let misty = WaterPokémon(name: "Misty")

let pikachu = ElectricPokémon(name: "Pikachu")

let charizard = FlyingPokémon(name: "Charizard")

Next, I create a list of these objects. Now, I can traverse this list and call the
attack() method on the objects in the list. We don’t need to know the class they
were instantiated from.

let pokémons = [eevie, pikachu, misty, charizard]

75
 Karoly Nyisztor

for pokémon in pokémons {

pokémon.attack()

If I run the demo, we’ll see in the console that the attack method produced the
same output in the console for all the objects but one.

Pokémon attack!

Pokémon attack!

WaterPokémon attack!

Pokémon attack!

That object was of type WaterPokémon, which overrides the attack() method.

76
 CHAPTER FIVE

UML Basics and Fundamental Diagram Types

COME, LET US GO DOWN AND THERE CONFUSE THEIR LANGUAGE, SO

THAT THEY MAY NOT UNDERSTAND ONE ANOTHER’S SPEECH.

- GENESIS 11:7

77
INTRODUCTION, UML DIAGRAM TYPES

Understanding a software system just by looking at its source code can be

very time-consuming. And communicating ideas about software design or
business processes is even harder if there’s no commonly accepted way to do
it.

The Unified Modeling Language - in short UML - was introduced to solve

this problem. UML is not a textual programming language, but rather a
graphical notation; a set of diagrams that help in designing and
communicating software systems.

We can use these diagrams to describe the objects that form a system and
their interactions. UML has many diagram types. We’ll be discussing the most
common ones.

The use-case diagram describes the functional model of a system. That is,
the functionality of a system from the user’s point of view.

78
 Software Development from A to Z

To describe the structure of a system, UML provides structural diagrams.

We’ll talk about the class diagram, which can be used to describe the structure
of a system in terms of objects, attributes, operations, and relations.

UML lets us model dynamic behavior, too. The behavioral diagrams describe
the functionality of the system, focusing on what happens and the interactions
between objects.

79
 Karoly Nyisztor

We’ll talk about the actual diagrams shortly. The best part about UML is that
it’s independent of any particular programming language. We can start coding
an object-oriented software based on UML diagrams. If those diagrams are
detailed enough, they can be converted to source code.

Now, let’s see some ways of using UML in real-life.

We can quickly draw a diagram to sketch a specific part of a software or a

new functionality.
I did that myself on numerous occasions. Whenever something was unclear, I
started to sketch UML diagrams before writing a single line of code.

80
 Software Development from A to Z

The benefit was that I not only understood what I should implement, I also
had a design. This design served as a documentation that could be used to
communicate my ideas with other team members.

Another frequent use of UML is drawing diagrams from existing code. This
technique is called reverse engineering, and it helps to understand and
document a system.

We can also use UML to create the detailed blueprint of a system. While
sketches focus only on the essential aspects of a system, the blueprint is about
completeness. Detailed UML blueprints are usually required for software
developed using a Waterfall-approach - and less frequently for Agile projects.

UML diagrams can describe any system that’s developed using an object-
oriented programming language. UML has become so popular that it's used
also for non-object-oriented projects.

81
THE USE-CASE DIAGRAM

The use-case diagram is one of the most straightforward UML diagrams.

Its purpose is to visualize the functional requirements of the system. Use-case
diagrams show groups of related use-cases. Sometimes they may include all
the use-cases.

The result is an overview of the system that may include several written use-
cases. You’ll rarely create use-case diagrams for a single use-case description.

To represent a use-case, we draw an oval in the middle of the screen and put
the title of the use case in it.

“Create a Trip Entry,” “Edit Trip,” “Export App Database” - these are examples
of use-cases from our Travel Expense app mentioned before.

82
 Software Development from A to Z

We use stick figures to represent the actors. As you may recall, actors are
human beings or other systems that may interact with our system.

We draw the stick person to the left or the right of the diagram. The actor’s
name goes below the stick figure.

We usually draw the primary actors on the left side and the secondary ones
on the right side of the use-case diagram.
Next, we draw lines to represent the interaction between an actor and a use-
case. A mobile user can create or edit a trip entry, but he cannot export the
app’s database. The power user can perform all these actions.

We need to visualize our system’s boundaries if it interacts with other

systems. For that, we draw a frame around all use-cases and actors that belong
to a given system.

Let’s say that we’re relying on external cloud-based storage. I’ll represent
this external system as a separate actor on the right side. I even changed its

83
 Karoly Nyisztor

visual representation to show that it’s not a human actor. Most tools allow you
to do that.

The “Create a Trip Entry” and the “Edit Trip” use cases would rely on the cloud
to back up their data. So, I connect these use-cases with the external system.
The frame makes it obvious where our app’s boundaries end.

Use-case diagrams provide a clear way to communicate the high-level

features and the scope of the system. You can quickly tell what our system does
just by looking at this use-case diagram.

84
 Software Development from A to Z

This system lets users create new trips and edit existing ones. Power users
can even export the database. The app relies on an external cloud system to
store its data.

Such a simple diagram makes it clear what the system does and what it
doesn’t do. A customer or a user can quickly see if needed features are missing.
The absence of use cases shows what the system doesn’t do.

The UML use-case diagram includes other artifacts and relationships

between use-cases. We’re going to ignore them as they tend to overcomplicate
our design and the benefits are questionable.

You can’t go wrong if you focus on the actors, the use-cases, and their
interactions. You’ll be able to easily create your own use-case diagrams and
communicate your ideas in a clear and concise way.

USE-CASE DIAGRAMS PROVIDE AN EASY-TO-UNDERSTAND OVERVIEW

OF THE FEATURES OF OUR SYSTEM.

They are not a replacement for written use-case descriptions, though. Use-
case descriptions include more information to ensure that we don’t miss any
of the critical details or requirements.

85
THE CLASS DIAGRAM

Without any doubt, class diagrams are the most frequently used UML
diagram types. After identifying the entities that form our system, we start
creating class diagrams for each of them.

A class is represented on the class diagram as a rectangle with three

compartments. First, we need to list the class’s name.

When naming our classes, we must adhere to some rules. These rules are
known as naming conventions. A class name should be a noun in the singular,
and it needs to start with an uppercase letter.

If the name consists of multiple words, we need to uppercase each word,

like in this example:

This style is called UpperCamelCase, which is CamelCase with the first letter
capitalized.

86
 Software Development from A to Z

CamelCase is the practice of starting each word in a compound word or

sentence with a capital.

Why do we need rules? Why can’t we just use any character sequence to
name our classes?

Well, we could do that.

Yet, a naming convention lets us focus on important issues instead of arguing
over syntax and names. With a commonly accepted set of rules, we can easily
read the source code written by other developers, even if they’re from another
company, country or continent. Standards are useful.

All right, so our class name should be a noun in UpperCamelCase. Let’s fill
the other two compartments, too. The next one lists the attributes. The
attribute names should be concise, and they should follow the
lowerCamelCase format, that is, with the first letter lowercase and the first
letters of subsequent words in uppercase.

87
 Karoly Nyisztor

A Trip has a name, it has a creation date (createdAt); it needs to have a home
currency (homeCurrency), a start date (startsAt) and an end date (endsAt).

It’s useful to specify the type of the attribute. We can do that by writing the
data type after the attribute’s name separated by a colon. So, here’s our Trip
class with the attribute names and types:

The data types need to be adjusted to whatever programming language

you’re using. This example makes perfect sense in Swift. For Objective-C, you
may want to use different types, like NSString instead of String and NSDate for
dates. Even if we leave it as it is, nobody will have issues understanding that
you refer to a String or a Date or an integer.

Next comes the operations compartment. This is where we list the class’s
methods. Method names should be verbs in lowerCamelCase.

88
 Software Development from A to Z

We can also specify method arguments. The parameters appear within the
parenthesis as name-data type pairs, like in setName(value: String).

To show that a method returns something, we add a colon after the closing
parenthesis followed by the return type:

getName(): String

89
 Karoly Nyisztor

And we can also have methods that have arguments and a return type.

getEntries(from: Date, to: Date): List takes two arguments called fromDate and
endDate, both of type Date. The method returns a List of entries. This list could
contain multiple values or just a single value, or it could even be empty. We
don’t specify this in our class diagram.

Now, let’s talk about visibility. UML allows us control who can access the
attributes and the methods of our classes.

We have the following visibility levels in UML:

• + means public visibility

A class method or attribute marked as public can be used by code
outside of the object.

• - denotes private access

Private attributes and methods can only be used within the class that
defines them. Elements marked as private can’t be accessed directly
from other classes.

90
 Software Development from A to Z

• UML uses # to mark an element as protected.

Protected visibility means that only child classes (and the defining
class) will be able to access that attribute or method.

• ~ denotes package visibility, which makes sense in some programming

languages that let us group our code into logical units and provide a
namespace for this group. Using package visibility, we make our
elements available within its enclosing package.

UML provides these visibility tags, but it’s up to us to adapt it to the

language we’re using. There’s one rule that’s commonly applicable to all object-
oriented languages:

YOU SHOULD ONLY EXPOSE AS MUCH AS NEEDED AND HIDE

EVERYTHING ELSE.

Class attributes will usually have private or protected access. We should

provide public setters and getters instead of allowing everybody to access our
class’s data. This lets us control what the callers do with our class’s attributes.

In our Trip class, we could make the name attribute public. Callers could set
and retrieve it, which seems to work as expected.

91
 Karoly Nyisztor

But what if we need to make sure that a Trip’s name is never shorter than
say three characters?

There’s no way to enforce this requirement.

Another example. The trip’s start date needs to be earlier than its end date.
Yet, callers can freely set any start or end date.

92
 Software Development from A to Z

I’m going to change the visibility of all these attributes to private. Now, we
can access them exclusively from within the class’s own methods.

After this change, other objects can’t set or retrieve these attributes. They
are private to the Trip class.

Awesome! But then, how do we set, retrieve or modify them?

Here’s the solution: I provide public getters and setters for each of these
attributes:

93
 Karoly Nyisztor

Now we can check whether the name is at least three characters long by
validating the name parameter in the setName() method. If it’s shorter, we just
print a warning message and return.

class Trip {
public func setName(value: String) {
if value.count < 3 {
print("Name too short!")
return
}
//...
}
}

Also, we validate the start and the end date in the corresponding setters.

public func setStartDate(date: Date) {

if date > endDate {
print("Trip's start date > end date")
return
}
//...
}

94
 Software Development from A to Z

public func setEndDate(date: Date) {

if date < startDate {
print("Trip's end date < start date")
return
}
//...
}

We are now in full control of our class’s internal data. Setters let us check the
input argument, and getters allow us to modify the value before returning it.
For example, we could return a date in the user’s time zone.

So far, we’ve seen how to represent a single class. Class diagrams let us also
show the relationships between the classes in our system. We’ll talk about
relationships next.

95
 Karoly Nyisztor

ASSOCIATIONS

The next logical step after identifying the key classes in our system is figuring
out the relationships between them.

Here’s one of the functional requirements of a travel expense management

app.

“AS A TRAVELER, I WANT TO TRACK MY EXPENSES WHILE ABROAD, SO

THAT I DON’T EXCEED MY BUDGET.”

We need a Trip and an Expense class. Each trip will include its travel expenses.
So, there needs to be some relationship between the Trip and the Expense
class.

To express this relationship, we draw a solid line between these classes.

This line represents an association. The association tells us that the classes
refer to each other.

We can be more specific here. The Trip class needs to know about its
expenses. Should the Expense class also know about the Trip class?

Tight coupling between objects is a bad sign and denotes poorly designed
systems. Let me illustrate the issue it causes.

96
 Software Development from A to Z

The Trip refers to the Expense class. That's fine since a trip can have expenses
associated with it. What happens if also the Expense refers to the Trip class?

Because of this reference, if we tried to use the Expense class in other parts
of the system, we’d need to also bring the Trip class with it.

This doesn’t make sense, as we should be able to use an Expense without a

Trip.

UML lets us express directed associations. By drawing a solid line that ends
with an open arrow, we show that only one of the classes refers to the other
one. The arrow points to the class that’s referred to by the other class.

In our current example, the association is bi-directional. Let’s change it to a

directed association.

97
 Karoly Nyisztor

Now it shows that the Expense is associated with the Trip, but the Expense
class doesn’t know anything about the Trip class.

A Trip will usually include various expenses. We can represent the multiplicity
of associated objects as follows:

* - a Trip can have zero or more Expenses

1 - a Trip must have exactly one homeCurrency

0..1 - a Trip may or may not have a single note

Associations can show multiplicities at both ends of the line. The default
multiplicity is one. So, if there’s no multiplicity shown, you can safely assume
it’s one.
We can also display the name of the class property for the given association.

98
 Software Development from A to Z

The association isn’t the only kind of relationship we can have between
classes. Next, we’re going to talk about generalization.

99
 Karoly Nyisztor

GENERALIZATION

In UML, we use generalization to express that one model element is based

on another model element. Generalization is represented as a solid line with a
hollow arrowhead that points to the parent.

Let’s say that we need a special Trip class for our business trips. BusinessTrip
would inherit from the Trip class, and this is how we represent it in UML:

Because BusinessTrip inherits everything from its parent, we must only

specify the attributes and operations that are specific to the child. A parent can
have multiple children.

100
 Software Development from A to Z

We can also have child classes that inherit from different parents.

Some programming languages support multiple inheritance (C++, Perl,

Python, to name a few).

Many modern programming languages only allow single inheritance, that is,
inheriting from one parent class. Single inheritance reduces the complexity and
avoids the ambiguity that comes with multiple inheritance.

SOME ARGUE THAT MULTIPLE INHERITANCE HAS MORE BENEFITS THAN

DRAWBACKS. HOWEVER, IT’S CERTAINLY EASIER TO MAKE MISTAKES
WHEN USING MULTIPLE INHERITANCE.

UML doesn’t restrict generalization to classes. We can also use

generalization in use-case or component diagrams. This lets us indicate that a
child element receives its parent’s attributes, operations, and relationships.

101
 Karoly Nyisztor

DEPENDENCY, AGGREGATION, COMPOSITION AND REALIZATION

DEPENDENCY

We talk about a dependency relationship if changes in one of the classes

may cause changes to the other.

In UML, dependency is represented as a dashed line that ends with an open

arrowhead. The arrow points to the dependency.

A dependency is a directed relationship.

Dependency is often confused with association, but there’s a big difference:

association indicates that a class has an attribute of the other class’s type.

Whereas dependency is usually created when a class receives a reference to

the other class (for instance, through a member function parameter).

102
 Software Development from A to Z

AGGREGATION AND COMPOSITION

Aggregation represents a part-whole relationship and is drawn as a solid line

with a hollow diamond at the owner’s end.

This relationship is considered redundant because it expresses the same

thing as the association. So, these two diagrams are equivalent:

Composition is a stronger form of association. It shows that the parts live

and die with the whole. In other words, composition implies ownership: when
the owning object is destroyed, the contained objects will be destroyed, too.

103
 Karoly Nyisztor

The composition is represented as a filled diamond on the owner’s end

connected with a solid line with the contained class.

The Expenses of a trip can’t exist without the Trip. If we delete the Trip
instance,

its expenses are going to be removed, too:

104
 Software Development from A to Z

REALIZATION

Realization indicates that a class implements the behavior specified by

another model element.

It is represented as a hollow triangle on the interface end connected with

dashed lines with the implementer classes.

We could specify an interface to ensure that all current and upcoming trip
classes provide a common set of methods. This is a useful feature that allows
polymorphic behavior.

105
Karoly Nyisztor

106
 Software Development from A to Z

Here’s a quick summary of the relationships and their graphical

representation:

107
SEQUENCE DIAGRAMS

Use case and class diagrams are static diagrams. They are great at
representing the structure of our system.

What if we need to show how the objects interact with each other? When
are objects created and for how long are they around? Static diagrams can’t
answer these questions.

UML provides dynamic diagrams to represent how objects communicate

with each other. The most common dynamic diagram is the sequence diagram.

WE USE THE SEQUENCE DIAGRAM TO DESCRIBE THE FLOW OF LOGIC IN

ONE PARTICULAR SCENARIO.

A sequence diagram starts by drawing boxes at the top of the page. Each
box represents an object. Since these are objects, we name them differently.
“aTrip” instead of “Trip” and “anExpense” rather than “Expense.”

We can also display the type after the instance’s name separated by a colon.
This may be helpful in some cases:

108
 Software Development from A to Z

The dotted lines beneath each box represent the lifeline of an object.
This line shows the time the instance exists during the scenario.

The sequence diagram also lets us show the messages sent from one object
to the other. A message is basically a method call.

Now, let me illustrate the various messages in a practical example.

I’ll be using a UML diagramming software called StarUML. You can download
StarUML for free from www.staruml.io.

Let’s assume that we have a persistenceManager object. This object is

responsible for storing and retrieving entities in the app’s local database.

The persistenceManager needs to create and store a TripEntity instance.

First, I add the TripEntity object. The persistenceManager instance sends a

109
 Karoly Nyisztor

create message to initiate a tripEntity object. The create message is

represented as a dashed line with a stick arrowhead.

Next, the persistence manager sends a regular message to the already

created trip entity. This message corresponds to calling the addNote(note:
String) method on the TripEntity instance. A regular message is shown as a
solid line with a filled arrowhead. We can add parameters to our messages if
we wish:

Although we could display the return message, only do it if it’s important.

Return messages are implicit for synchronous messages, so we don’t have to
display them.

Asynchronous messages are drawn as solid lines with a stick arrowhead. The
controller object sends an async save(trip: Trip) message to the
persistenceManager.

110
 Software Development from A to Z

Disk operations are slow, so inserting a new record into the database is a
perfect candidate for an async call.

When an object sends any async message, it doesn’t need to wait for a
response. The asynchronous call gets executed in the background, and it
returns once it completes. Unlike synchronous calls, it doesn’t block the caller.

Asynchronous behavior stands at the core of modern software systems. They

improve responsiveness on multicore processors and provide better user
experience because lengthy operations won’t block the user interface.

So, you’ll probably draw async messages a lot. The issue is that the
difference between regular and async messages is very subtle: stick arrowhead
instead of a filled arrowhead.

To avoid misunderstandings, you can add an extra note to make it visible it’s
an async message.

111
 Karoly Nyisztor

We also have self-messages. These represent a method calling another

method of the same object.

112
 Software Development from A to Z

An object can also send a delete message to another object. The

persistenceManager sends a delete message to the tripEntity instance. The
TripEntity gets destroyed, and its lifeline gets terminated by a cross symbol.

Sequence diagrams should provide an overview of what’s going on in a

given scenario. We don’t try to represent all the method calls precisely. Instead,
we focus on the most relevant parts.

Sequence diagrams help us in clarifying the interactions between objects in

a specific scenario. By getting more profound insights into the inner workings
of our objects, we may need to refine their behavior. Or even add new classes
or establish new relationships between our classes.

And that’s perfectly fine. The process of designing a software system is all
about finding out what’s missing, what needs to be enhanced or changed

113
ACTIVITY DIAGRAMS

Activity diagrams can be used to describe workflows.

The actions are represented by nodes. We start an activity diagram with an

initial node drawn as a small, filled circle. We can then transition to the next
node.

The transition is called flow, and it’s shown as a line that ends with an open
arrowhead. The arrow points the direction of the logic flow from one action to
the other.

Activity diagrams can also express conditional logic. We model a decision

node as a diamond. It has a single incoming flow and two or more outbound
flows.

Each outbound flow has a guard, which is a Boolean condition placed inside
square brackets. The guards need to be mutually exclusive. Whenever we reach
a decision, we can choose only one of the outbound flows.

114
 Software Development from A to Z

After a decision, the flows can be merged using a merge activity. A merge
has multiple input flows and a single output flow.

Activity diagrams support parallel behavior. To express concurrent flows, we

use a fork drawn as a thick horizontal line. A fork has one incoming flow and
several outgoing concurrent flows.

115
 Karoly Nyisztor

We need to synchronize the tasks that execute concurrently. For example,

we can’t display the image while it’s being read from the local persistence or
downloaded from the server. A join represents a synchronization point.

The final node represents the end of the workflow.

116
 Software Development from A to Z

The following activity diagram describes a simplified version of the trip

creation process.

We begin with the initial node. The user decides to create a new trip.

117
 Karoly Nyisztor

Next, he’s asked to type the trip’s name. Now, the app needs to check
whether a trip with the same name already exists.

If it does, we prompt the user to enter a new name or cancel the trip creation
process. If he decides to cancel the flow, we end the activity. Otherwise, we
validate the name again.

If the trip name isn't taken, we let the user fill the remaining trip data. Finally,
the user hits the save button. We may also want to let him cancel the process
here.

118
 Software Development from A to Z

I use a fork to show that we perform some actions in parallel. Storing the
new trip into the local persistence and uploading it to the cloud server happen
concurrently.

119
 Karoly Nyisztor

If both actions succeed, we inform the user about the successful trip
creation, and we’re done.

We can add more details and further actions to our activity diagram if that’s
useful.

The activity diagram is a useful technique to represent behavioral logic. I

wouldn’t recommend it when working with nontechnical people, though.

120
STATE CHART DIAGRAMS

The State chart or State Machine diagram models how an object transitions
from one state to another over its lifetime.

It describes the state changes of an object in response to certain events.

A state is a condition in which an object exists. Think of object states like ” New,”
”Pending Changes” or ”Completed.”

These states can change when some event gets triggered. The ” Pending
Changes” state transitions to ”Saved” after a successful save event, and the
“Saved” state will change to the final ”Terminated” state if the object is deleted.

The state machine diagram starts with an initial state. This is the entry point.
States are drawn as rectangles with rounded corners with the state’s name. The
transitions from one state to another are shown as lines that end in an open
arrow.

Each transition can be labeled with an event name and a guard.

121
 Karoly Nyisztor

The guard appears between angle brackets; it’s a Boolean condition that
needs to be true for the state change to occur.

122
 Software Development from A to Z

Let’s assume that pending changes can only be saved if the device is
connected to the Internet. We can represent conditional logic in state chart
diagrams as follows:

The final state shows that the state machine is completed, and it also implies
the deletion of the object.

Use state chart diagrams to describe the object states of a system while
identifying the events responsible for the state changes.

123
 CHAPTER SIX

Next Steps

Congratulations! You’ve reached the end of this book!

124
 Software Development from A to Z

By now, you’ve probably become familiar with the fundamental software-

development concepts.

So, you want to make a career switch to software development? You might
be wondering, what’s next? In this chapter I’m going to provide some
additional guidance and hints that help you in accomplishing your goal.

As a next step, you could start gathering the experience you’ll need to
become a software developer.

As I highlighted in “Misconceptions About Becoming a Software Developer,”

learning how to code must not ruin you financially.

You can learn to code on your own. There are plenty of free or inexpensive
online resources that will teach you how to program using a specific
programming language.

Let’s say you want to learn how to develop apps for iOS using Swift.
All you need to do is to visit a website like Udemy and look up “iOS app
development in Swift.”

Udemy allows you to refine your search further by applying filters for Level,
language, features, and even price. You can list all English speaking, beginner
level courses which include coding exercises.
You can even sort the results by various criteria, for example by relevance or
by ratings.

FREE COURSES USUALLY ONLY COVER THE BASICS, OR THEY PROVIDE

LESS VALUE COMPARED TO THEIR PAID COUNTERPARTS. FOR MORE
ADVANCED TOPICS YOU’LL USUALLY NEED TO SPEND SOME MONEY.

125
 Karoly Nyisztor

Pro tip
If you discover a course that matches your needs, but it’s too pricey, just add it
to your wish list. Then wait until it gets discounted. Udemy offers promotions
quite frequently, and in most cases, you can get a $200 course for 10 bucks if
you wait a bit.

Alternatively, you can search for coupon codes on the internet, but this is
usually just a waste of time.

You should also join “learn to code” meetups. On meetup.com you may be
able to find one that is in your city or very close to you. See for example
https://www.meetup.com/topics/learn-to-code/. Meetups are great to share
your thoughts with other, like-minded people and learn from more
experienced programmers.

Once you master a programming language, start working on a project. It is

also a good idea to create a GitHub or Bitbucket account and place your project

126
 Software Development from A to Z

into a public repository so that others can provide feedback on your code.
Besides, prospective employers may also find you.

You should only share your code publicly if it meets certain quality criteria -
that is, it builds without issues, produces very few or no build-time warnings,
it’s thoroughly commented, and it works as expected.

Let the world know about your new skills. Write blog posts, update your
LinkedIn profile, and add the newly learned programming language to your
skill set.

Finally, if you are confident enough, you can start looking for a software
development job. You can also work as a freelancer if this fits you better.

The demand for computer software keeps increasing, along with the need
for software developers

127
USEFUL LINKS

As an instructor, my goal is to share my 25+ years of software development

expertise. I’ve worked with companies such as Apple, Siemens, SAP, and many
more.

I’m teaching software development related topics, including object-oriented

software design, iOS programming, Swift, Objective-C, and UML.

• Check out these links for free tutorials, blog posts and other useful
stuff:

• Website: http://www.leakka.com

• YouTube: https://www.youtube.com/c/swiftprogrammingtutorials

• GitHub: https://github.com/nyisztor

• Twitter: https://twitter.com/knyisztor

My books are available on:

• Amazon
amazon.com/author/nyisztor and

• iTunes
https://itunes.apple.com/us/author/karoly-
nyisztor/id1345964804?mt=11.

128
 Software Development from A to Z

You can find my programming courses on Udemy, Lynda, LinkedIn Learning,

and Pluralsight:

• Udemy:
https://www.udemy.com/user/karolynyisztor

• LinkedIn Learning:
https://www.linkedin.com/learning/instructors/karoly-nyisztor

• Pluralsight:
https://www.pluralsight.com/profile/author/karoly-nyisztor

I’d love to hear from you! Feel free to email me at [email protected]. And
if you found this book useful, please leave a nice review or rating.

Thank you!

129
COPYRIGHT

© Copyright © 2018 by Károly Nyisztor.

All rights reserved. This book or any portion thereof may not be reproduced
or used in any manner whatsoever without the express written permission of
the publisher except for the use of brief quotations in a book review.

First Edition, 2018

Version 1.0
www.leakka.com