Development of Software
Applications
Azouz Mrad
mmrad@aut.bme.hu
2019. October 27.
Examples and best practices
• You don’t need to find it out from scratch
Architectural patterns
Design patterns
Idioms
2
SOLID Principles
•
•
•
•
•
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
3
Single Responsibility Principle
• A class should have one, and only one, reason to change.
• Example: creating and printig riports -> must be separated
> Same domain but different approaches:
> Reason to change 1.: different format
> Reason to change 2.: different printer
• Benefits:
> Robustness: The modifications won’t effect other components
> Clear
> Easier to test
4
Cohesion/Coupling
• Cohesion: Cohesion is a measure of the degree to
which the elements of the module are functionally
related.
• Coupling: Coupling is the measure of the degree of
interdependence between the modules. A good
software will have low coupling.
• High cohesion, low coupling is the ideal
> The Single Responsibility Principle helps to achieve it
5
SRP example
class PaymentService {
public void transferPayment(Employee& initiator,
Employee& recipient,
int amount) {
if (isAuthorizedToPay(initiator)) {
// ... transfer payment
} else {
// ... log unauthorized access
}
}
public bool isAuthorizedToPay(Employee& user) {
// ... check access
}
}
return false;
6
SRP example fixed
class PaymentService {
private AuthorizationService *authorizationService;
public PaymentService(AuthorizationService *authorizationService){
this->authorizationService = authorizationService;
}
public void transferPayment(Employee& initiator,
Employee& recipient,
int amount) {
if (authorizationService->isAuthorizedToPay(initiator)) {
// ... transfer payment
} else {
// ... log unauthorized access
}
}
}
7
Open/Closed Principle
• Software entities (classes, modules, functions,
etc.) should be open for extension, but closed for
modification.
• We can extend their functionality without
modifying their interior.
8
OCP example
class AreaCalculatorBad {
public double calculateArea(vector<Shape> shapes) {
double area = 0;
for (Shape s : shapes) {
if (typeid(s).name() == "Rectangle") {
Rectangle r = (Rectangle) s;
area += r.getA() * r.getB();
} else if (typeid(s).name() == "Circle") {
Circle c = (Circle) s;
area += c.getRadius() * c.getRadius() * Math.PI;
} else
throw excepcion("Unsupported shape");
}
return area;
}
}
9
OCP example fixed
public interface Shape {
double area();
}
public class AreaCalculator {
}
public double calculateArea(List<Shape> shapes) {
double area = 0;
for (Shape s : shapes) {
area += s.area();
}
return area;
}
10
Liskov Substitution Principle
• Derived classes must be substitutable for their
base classes
• Functions that use pointers to base classes must
be able to use objects of derived classes without
knowing it
• Same as polimorphism but that’s just a technic
> Here we require the adequate functionality
11
Interface Segregation Principle
• Make fine grained interfaces that are client
specific
• In practice: Use small, specific interfaces instead
of large ones
• (Analogue with the Single Responsibility and
high cohesion)
12
ISP example
public interface Car {
void setSeatHeating(boolean value);
void setTurnSignalLeft(boolean value);
void setTurnSignalRight(boolean value);
}
13
ISP example
class BmwX5 implements Car {
@Override
public void setSeatHeating(bool value) {
// TODO
}
@Override
public void setTurnSignalLeft(bool value) {
throw exception("BMWs do"+
" not have turn signal");
}
}
@Override
public void setTurnSignalRight(bool value) {
throw exception("BMWs do"+
" not have turn signal");
}
14
ISP example fixed
class SeatHeating {
virtual void setSeatHeating(bool value) = 0;
}
class BmwX5 : public SeatHeating {
public:
void setSeatHeating(bool value) {
// TODO
}
}
//Not only for cars …
class WinterVehicleTesting {
public:
bool TestHeating(SeatHeating subjectVehicle) {
…
subjectVehicle.setSeatHeating(true);
…
}
}
15
Dependency Inversion Principle
• Depend on abstractions, not on concretions
• In short:
> Use interfaces and abstract classes for dependencies
> Do not create dependencies, get it from outside
16
Scope of design
• Mainly class level but can adopt for either larger
or smaller components.
• Self understandable after understanding the
ideas
> i.e. a function should do only one task
> i.e. frameworks should be independent from eachother implementation
17
Additional design principles
• Keep it simple stupid (KISS):
• You aren’t gonna need it (YAGNI)
> Do not implement it until you really need it
> Time is money, the development process has cost
> Extra/additional functions may increase the
complexity
18
Additional design principles
• Do not repeat yourself (DRY)
> Duplicating code may cause problems
> Solve a task once and in one place
> Remove repeated code by refactoring it
> Duplicated code makes maintenance more difficult
(Except validation in safety critical systems)
19
Software development
methods
20
Software development methods
• An engineering discipline that focuses on
aspects of software-based system development.
21
Szoftvertechnológia és -technikák
Software development methods
•
•
•
•
Waterfall
Spiral
Iterative and incremental
Agile
22
Szoftvertechnológia és -technikák
Waterfall model
23
Szoftvertechnológia és -technikák
Waterfall model
• Example: Example: The BKV has commissioned our
software development team to develop an electronic
ticketing system.
• We have a well-defined deadline:
> delivery is scheduled for 2022.
• From Alpha to Omega, everything is left to us:
> It is up to us to design, implement, install, deliver and maintain
everything.
• We meet the customer at the beginning and end of the
project.
24
Szoftvertechnológia és -technikák
Waterfall model
• The most used model of the last 50 years
• Linear model
> The steps follow one another
> We start a new phase when the previous one is
completed
25
Szoftvertechnológia és -technikák
Phases of Waterfall model
26
Szoftvertechnológia és -technikák
1. Step: Requirements
• Creates a detailed, common view between the
Customer and the Supplier regarding the product to
be manufactured
• We will move on when the specification is accepted
27
Szoftvertechnológia és -technikák
1. Step: Requirements
• Elements of a Specification:
> Purpose and position of the project at the company
> Terminology, definitions
> Responsibles
> User groups
> Assumptions, constraints, prerequisites, dependencies
> Functional Requirements - Processes, Interfaces, etc. itemized listing
and detailing
> Non-Functional Requirements - Performance, Security, Scalability,
Format,…
> Estimated deadlines
> Handover / acceptance tests
28
Szoftvertechnológia és -technikák
2. Step: Design
• Conceptual plans:
> Architecture, used frameworks
> Interfaces, module boundary
> Detailed database design
> Process/flow description
> Screen layout plans, navigation map, etc.
> Usage examples
> Security, testing plans
• Prototyping:
> Iterations based on user feedback
29
Szoftvertechnológia és -technikák
2. Step: Design
• After the planning, further modifications are
already costly!
• The waterfall model should be based on a good
plan.
30
Szoftvertechnológia és -technikák
3. Step: Implementation
• The software implementation starts in this
step
• Decomposition of work, creating development
plans
• Mostly the longest period in the whole process
31
Szoftvertechnológia és -technikák
4. Step: Testing
• Quality controllers check the software to see if
it works according to the specification
• The bugs get back to the developers and
testing starts over
• We often use transition state: beta version,
invited test-users, etc.
32
Szoftvertechnológia és -technikák
5. Step: Deploy
• Deployment, distribution
• Distribute the same version which has been
approved by the developers
33
Szoftvertechnológia és -technikák
6. Step: Maintenance
• Maintenance / upgrade phase
> Bug fixes, testing, …
• Maintenance is the most expensive phase
> Bug fixes are extremely costly
34
Szoftvertechnológia és -technikák
The advantages of the Waterfall model
• Clients and developers quickly (at the
beginning of the project) agree and clarify the
development phases.
• The progress of the project is easily
measurable and traceable
> What phase are we in
> We know (we have a good estimate of) how much
is left
35
Szoftvertechnológia és -technikák
The advantages of the Waterfall model
• Not everyone has to work on a project all the
time
> i.e. Testers should work only in the testing phase
• The (continuous) presence of the customer is
not required
• If the design is good, it is possible to predict in
advance when the development will be
completed and how long it will take.
36
Szoftvertechnológia és -technikák
The disadvantages of the Waterfall model
• The final product won’t meet the “real” requirement of the
customer
> We often do not receive product feedback until it is completed
• Constantly evolving requirements induce conceptual
changes that require redesign
> The wasted time and energy are significant
• Designers are often uninformed about the implementation
details
> Sometimes complicated implementations are made instead of
simple design changes
37
Szoftvertechnológia és -technikák
The disadvantages of the Waterfall model
• Design tools do not integrate well with
implementation tools
• The entire development step may last too long
38
Szoftvertechnológia és -technikák
When to use?
• The customer is only present at the
milestones
• We work with a precise deadline
• Requirements do not change on the go
39
Case Study
• https://medium.com/@kawomersley/wouldyou-rather-be-late-or-wrong-a-strategic-casefor-waterfall-development-35d81911022c
40
Szoftvertechnológia és -technikák
V-model
• Development methodology, extension of the
waterfall model
• There is a connection between development and
testing steps
41
Szoftvertechnológia és -technikák
Evolutionary models
• To avoid problems with the waterfall model, a different
approach was taken
• Evolutionary approach
> Multiple cycles, each representing a part of the product
> This allows us to modify the requirements
Currently, the agile solutions are the most popular of
evolutionary approaches
42
Szoftvertechnológia és -technikák
Spiral
43
Szoftvertechnológia és -technikák
Spiral
• Key Characteristics: Risk management at the
appropriate stage of development
• Based on the project's specific risks, it adopts
elements of other process models (incremental,
waterfall, evolutionary models)
44
Szoftvertechnológia és -technikák
Spiral
• Repeats four main activities cyclically (in the form
of a spiral):
1.
2.
3.
4.
Developing plans: goals, expectations, constraints
Risk analysis: Identifying and eliminating risk factors
Implementation: application development and verification
Planning the next iteration
45
Szoftvertechnológia és -technikák
RUP methodology
46
Szoftvertechnológia és -technikák
RUP
• IBM Rational Unified Process (RUP)
• Comprehensive process framework
• Industry-tested practices for
developing software systems and
project management
47
Szoftvertechnológia és -technikák
RUP
• Collection of best practices
> Based on thousands of project
> Reusing chunks of processes
> Project templates (structure, resources,
milestones, deliverables), documents
48
Szoftvertechnológia és -technikák
RUP
• Iterative method
• It works in phases
49
Szoftvertechnológia és -technikák
RUP
50
Szoftvertechnológia és -technikák
RUP Building Blocks
• Roles (who) defines skills,
competences and responsibilities
• Work products (what) something
resulting from a task, including all
the documents and models
produced while working through the
process
51
Szoftvertechnológia és -technikák
RUP Building Blocks
• Tasks (how) a unit of work assigned to a Role
that provides a meaningful result
• Within each iteration, the tasks are categorized
into nine disciplines
52
AUT diasablon
RUP Building Blocks
• Six engineering disciplines"
>
>
>
>
>
>
Business Modelling
Requirements
Analysis and Design
Implementation
Test
Deployment
• Three supporting disciplines
> Configuration and Change Management
> Project Management
> Environment
53
Szoftvertechnológia és -technikák
RUP
➢9
disciplines
54
Szoftvertechnológia és -technikák
RUP Four phases of project lifecycle
• RUP divides the iterative process to four phases
• Each phase is composed of one or more iterations
> Inception Idea is stated. Team determines if the
project is worth pursuing and what resources will be
needed
> Elaboration Developers consider possible applications
of the software and costs associated with the
development
55
AUT diasablon
RUP Four phases of project lifecycle
> Construction Software is designed, written, and tested
> Transition The software is released to the public. Final
adjustments or updates are made based on feedback
from end users
56
AUT diasablon
RUP
➢4
phases
57
Szoftvertechnológia és -technikák
RUP – Inception
• Development of the project idea
• The team decides if it is worth
starting the project
• The team will decide if it is
worthwhile to continue the project
• The team estimates the resources
the project will need
58
Szoftvertechnológia és -technikák
RUP – Elaboration
• Elaboration of the project
architecture and the required
resource requirements
• Developers are considering
possible applications as well as
development costs
59
Szoftvertechnológia és -technikák
RUP – Construction
• The project will be developed at
this stage
• Phases
> Software design
> Software implementation /development
> Software testing
60
Szoftvertechnológia és -technikák
RUP – Transition
• Public release and transfer of
software
> final touches
> corrections based on feedback
61
Szoftvertechnológia és -technikák
A 6 best practice
• Develop iteratively
> It is best to know all the requirements
in advance, however, this is often not
the case.
• Manage requirements
> Always keep in mind that the
requirements are determined by the
users.
62
Szoftvertechnológia és -technikák
A 6 best practice
• Use components
> Breaking down the project into
components helps with testing, reuse,
transparency, and management.
• Model visually
> Use diagrams to describe the main
components, users, interactions
(software modeling, UML, DSL).
63
Szoftvertechnológia és -technikák
A 6 best practice
• Verify quality:
> Testing should always play a
prominent role in all phases of the
project.
> The testing task grows steadily as the
project progresses, but it should be a
constant factor!
64
Szoftvertechnológia és -technikák
A 6 best practice
• Control changes:
> Many projects are developed by
several different teams, often in
different locations, using different
platforms.
> Keep synchronizing and verifying your
changes. (Continuous integration).
65
Szoftvertechnológia és -technikák