Software Development Sheet
Software Development Sheet
Exercise 1.4: In your opinion, what are the quality expectations for "Air Traffic
Control Software" and "Personal Diary Mobile App" might be?
I think that Quality expectations for software can vary based on the specific
requirements, user needs, and industry standards, for "Air Traffic Control
Software" it should be reliable, stable, efficient, secure, scalable, and have
integrity. And for "Personal Diary Mobile App" it should have ease of use,
privacy and security, sync and backup, customization, search and organization,
offline access and capability.
Exercise 1.7: What we mean by, "The developer should tell in failure"?
It means that means that when something goes wrong in a computer program,
the developer should make sure the program explains the problem in a clear
and understandable way to the person using the software. This could be
through messages that pop up on the screen, so the user knows what happened
and, if possible, what they can do to fix it. It's like having the computer speak up
and say, "Hey, something didn't work, and here's why." This helps users and
developers figure out and fix issues more easily.
Chapter 2
Exercise 2.2: Describe the process you have for a programming task, from
requirements to delivery?
Exercise 2.6: Which part of the system life cycle do you think is the most
innovative and challenging?
Whether pair programming is considered good or bad depends on the team, the
nature of the project, and individual preferences. Some teams find it highly
beneficial for improving code quality and collaboration, while others may find it
less efficient or suitable for certain tasks. It often comes down to the specific
context and the team's dynamics.
Exercise 2.14: Giving reasons for your answer based on the type of system being
developed, suggest the most appropriate software process model that might be
used as a basis for managing the development of the following systems:
• A system to control anti-lock braking in a car.
• A virtual reality system to support software maintenance.
• A university accounting system that replaces an existing system.
• An interactive travel planning system that helps users plan journeys with the
lowest environmental impact.
Exercise 3.2:
Exercise 3.3:
Exercise 3.4:
Exercise 3.5:
* Pronounceable names.
* Breaking indentations.
* Searchable names.
* have no side effect.
Exercise 3.6:
2-
3 - It would result in a syntax error, and the compiler would likely fail to build
the code successfully. The corrected version addresses this syntax error by using
the correct comparison operators
4 - The code appears to be related to searching or counting elements in an array
based on certain conditions. Specifically, it may be part of a program that
processes an array (v) and counts the occurrences of elements meeting a
particular criterion, which is defined by the conditions in the if statement within
the loop.
Exercise 3.7:
Exercise 3.8:
Chapter 4
Exercise 4.6: The DRY principle is closely related to the concept of "Single
Responsibility Principle" (SRP) and is one of the guiding principles of good
software design and architecture. By adhering to DRY, developers aim to write
clean, maintainable code that minimizes the risk of errors and facilitates future
enhancements.
Exercise 4.7: The KISS principle, which stands for "Keep It Simple, Stupid" or
"Keep It Short and Simple," is a design philosophy that advocates simplicity and
clarity in system and software design. The core idea is to avoid unnecessary
complexity and to favor simplicity whenever possible. The principle suggests that
simpler designs are often easier to understand, maintain, and troubleshoot. It has
some hey aspects like simplicity, clarity, minimalism and more.
Exercise 4.11: The code provided has a design issue related to the violation of the
Liskov Substitution Principle (LSP), the Liskov Substitution Principle states that
objects of a superclass should be replaceable with objects of a subclass without
affecting the correctness of the program.
In the given code:
The “run” method in the Feline class is declared as public, but in the Tiger class, it
is overridden with a private access modifier. According to LSP, the visibility of
overridden methods should not be more restrictive than the visibility of the
method in the superclass.
The private method eat in the Feline class is not accessible in the Tiger class. This
does not violate the LSP directly, but it limits the ability to extend or override the
behavior of the eat method in subclasses.
To adhere to the Liskov Substitution Principle and improve the design:
The overridden methods in the subclass (Tiger) should not reduce the visibility of
the methods defined in the superclass (Feline). If the superclass has a public
method, the overriding method in the subclass should be at least public.
Consider making methods like eat in the Feline class with at least protected
access if you want to allow subclasses like Tiger to have access to and potentially
override them.
Exercise 4.12:
Scenario 1 violates SRP (Single Responsibility Principle).
Scenario 2 violates LSP (Leskov Substitution Principle).
Scenario 3 violates ISP (Interface Segregation Principle).
Exercise 4.13:
Exercise 4.14:
The SOLID principle that can improve the code segment is the Single
Responsibility Principle (SRP). The Human class is currently responsible for both
storing personal information (name, age) and generating a full address string,
violating the SRP. Ideally, a class should have only one reason to change.
Refactored version of the code:
Chapter 5
Exercise 5.3:
Exercise 5.4: Using the Singleton pattern in this scenario helps in managing the
shared resource (the printer) efficiently, ensuring that there's only one instance of
the printer that handles print jobs for all the employees.
To address the issue of having different interfaces for XML and JSON formats, you
can use the Adapter Pattern. The Adapter Pattern allows incompatible interfaces
to work together. In this case, you can create an adapter that converts the XML
format to the JSON format so that both types of clients can use the product
seamlessly.
Exercise 6.3: Façade design pattern.
Exercise 6.4: To integrate the special character, the Adapter Pattern allows
objects with incompatible interfaces to work together.
Chapter 7
Exercise 7.5: To address the scenario described, you can use the Observer
Pattern. The Observer Pattern defines a one-to-many dependency between
objects so that when one object changes state, all its dependents are notified and
updated automatically. In this case, the news agency acts as the subject, and the
subscribers act as observers.
Exercise 7.6: To implement the described scenario, you can use the Observer
Pattern. The Observer Pattern will be well-suited for this scenario.
Exercise 7.7: You can use the Strategy Pattern. The payment options (Credit Card,
Debit Card, and Cash) can be encapsulated as strategies, and Steve can choose
the desired payment option at the bill counter.