Software Design Patterns

Software Design Patterns are commonly used on object-oriented software development, they are previously defined methods to design and code programs, used commonly by experts and corporations that benefit from structured and unified ways to develop and execute. They serve as a common framework for developers and promote good coding practices.

Source

They were not developed intentionally, they were instead created by trial and error and the prevalent ones are the ones that, by natural selection, were proven to be the best ones.
The Gang of Four, are the ones that wrote a book and set the SDP principles down, the book is called "Design Patterns - Elements of Reusable Object-Oriented Software". The two main principles are:

Program to an interface, not an implementation: Basically programming the classes in order for them to be implementable by other software, resuable and act as pieces of a bigger puzzle.
Favor composition over inheritance: Classes should implement other classes to complete their functionality, rather than inheriting from them.

There are a lot of desing patterns and not one is always the "correct" one, nonetheless, four main pattern types are defined:

Creational: Create objects on the go as they are being used.
Structural: The composition of objects is of most importance, mix and match to obtain new functionality.
Behavioral: Communication between objects is prioritized.
J2EE: Presentation layer.

Source: https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm

Software Design Patterns

Source

Program to an interface, not an implementation: Basically programming the classes in order for them to be implementable by other software, resuable and act as pieces of a bigger puzzle.
Favor composition over inheritance: Classes should implement other classes to complete their functionality, rather than inheriting from them.

There are a lot of desing patterns and not one is always the "correct" one, nonetheless, four main pattern types are defined:

Creational: Create objects on the go as they are being used.
Structural: The composition of objects is of most importance, mix and match to obtain new functionality.
Behavioral: Communication between objects is prioritized.
J2EE: Presentation layer.

Source: https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm

Software Design & Software Architecture

These two parts are essential to software-making, they are sequential steps that ensure a program meets the specifications needed and solves a particular problem, let's start with Architecture.

Source

Software architecture deals with the abstraction part of design, it analyzes the problem and sets a methodolgy to solve it, commonly using blocks. The software architect must be very acquainted with the challenge that he is facing, along with the technologies that can be used to solve it. Nonetheless, the SA doesn't do coding, he gives the product owner a thorough analysis and the underlying structure of the program that must be made, including a design blueprint and the attributes and connections of each part that has to be implemented later.

Software Architecture is, in essence, delivering a structured solution to a problem.

Software Design, on the other hand, deals with the technical details of the implementation of the system. They take into account the environment, adapting the development process to it, incluiding software and hardware constraints. They design and guide the coding process, including testing and debugging, in order for the process to be orderly and ensure success.

Software Design creates the functional part of the archutecture plan.

Software Design & Software Architecture

These two parts are essential to software-making, they are sequential steps that ensure a program meets the specifications needed and solves a particular problem, let's start with Architecture.

Source

Software Architecture is, in essence, delivering a structured solution to a problem.

Software Design creates the functional part of the archutecture plan.

Software Architecture

I have already written a post about software design. Why writing another one? Well, mainly because software architecture isn’t the same as software design. Sure, archictecture is part of design. But actually the architecture is itself an area so deep that it needs to be talked about in another post. So, here is it.

Software architecture consists in the basics of software. It defines basic functioning and communication of the components, as well as the components themselves.

Some advantages of software architecture are:

Separation of concerns: this allows to have different people working on different areas.
Quality: defining a good architecture actually helps in improvising quality.
Conceptual integrity: helps getting a general vision of what the software do.

Why is this important? As I have mentioned in other posts, in small projects or prototypes, architecture can be not that important. As soon as the project begins to grow, order is not an option. It is a necessity. Therefore, I consider it a good practice to define an architecture at the beginning. Now: this may sound too much like waterfall method, but that’s not what I’m trying to say. Software changes. If the architecture you developed does not fit your requirements anymore, change it. Don’t be afraid of changes.

flickr photo by Will Scullin https://flickr.com/photos/wscullin/3770016707 shared under a Creative Commons (BY) license

Understanding Software Architecture

Software Architecture is the representation of the program that helps to understand how the software will behave. It serves as a guide for the design and the implementation teams. And is the first line of the system’s quality, such as performance, modifiability, and security. None of these could be done without an architectural vision.

By building effective architecture, you can identify design risks and mitigate them early in the development process. It also gives an approach of the final design.

Like any other complex structure, software should be done on a solid foundation. Any failure in the future could result a risk for the application.

The most important part of it, is to always consider three things: The User, The System & The Business.

Finding a valance between the desire and specifications of each will result on a good architecture, and this will lead on a great application.

But unfortunately there are major problems that are hard to decode. That’s why we always need to think about this major concerns:

How will the users be using the application?
How will the application be deployed into production and managed?
What are the quality attribute requirements for the application, such as security, performance, concurrency, internationalization, and configuration?
How can the application be designed to be flexible and maintainable over time?
What are the architectural trends that might impact your application now or after it has been deployed?

The goal of architecture is to identify the things that affect the structure and functionality of the application. Good architecture reduces the business risks associated with building a technical solution.

The architecture is important in everything, and when talking about software, it’s the base for a good one; you don’t want the users to be mad at you.

Source:

http://www.sei.cmu.

Continue reading →

Building software

What is it?

“The software architecture of a program or computing system is a depiction of the system that aids in the understanding of how the system will behave.” (SEI|CM, 2016)

Basically, Software architecture is the process of creating a blueprint of your program. What will be its functionalities, applications, method, designs, etc. The main difference between Software Architecture and Software Design is that the architecture will demonstrate what the system will do, and the design will show how it will do it. Software architecture is represented on a high-scale abstract style; henceforth, is just a guide to show developers what the system is intended to do, and what it needs to work.

Video:

References

http://www.sei.cmu.edu/architecture/

Software Architecture

Software Architecture is the way software solutions are structured for all the project itself. Software architecture takes into account all of the aspects. It takes into account performance, security, quality and plenty of other stuff including the requirements asked by the client. Just as in a house or a building, software must have solid foundation. Not taking into account all of the requirements can lead to expensive delays. Delays might be the best-case scenario, because sooner or later, it’s going to be fixed, but if engineers just ignore the requirements, this can lead to unhappy customers that have poor, lame, and unstable software. Also, your job might be in a risk.

When designing the blueprints of the software you must take into consideration three things, the final user, the company goals, and the platform itself. And most important, they all have the same weight while taking decisions. There are no biased decisions in this topic. They all weigh the same because each one impacts the others in a certain way. For example, if the system is more complex, we might need the final user interface to be even more friendly due to the business requirements.

When designing the structure, the developers might want to take a look to the following questions.

How will the users be using the application
How will the application be deployed into production and managed?
What are the quality attribute requirements for the application, such as security, performance, concurrency, internationalization, and configuration?
How can the application be designed to be flexible and maintainable over time?
What are the architectural trends that might impact your application now or after it has been deployed?

When the project team has all of these answered, now, it’s time to begin. Once we all know all of the project

Continue reading →

Software Architecture

Software architecture (not to be confused with architecture design) is mostly the externally visible components of a system.

In this phase of the Software Development Life Cycle the main concern is “what” a system should do while software Design is about “how” a system achieves its goals.
Architecture is a higher level of abstraction and it scopes all of the system, not just the modules like in the design.

Architecture is the blueprint for building the design, it aids in understanding how a certain system must behave, it must meet the technical and operational requirements. The structural elements and interfaces of the system are selected to compose the project and they are separated into modules that must later be designed.

Architecture is important because all software must have solid foundations. Common problems or failures must be detected so long term consequences can be avoided.

There are some key things to consider when building a systems architecture:

-User Empowerment
-Market Maturity
-Flexible Design
-Future Trends

Here is a video to understand the difference between software design and architecture:

Uploaded by Software Architect CA

Some software architecture styles are:

-Structure (component-based, layered)
-Shared Memory (data-centric, rule-based)
-Messaging (event-driven, asynchronous messaging)
-Adaptive Systems (plug-ins, Microkernel, reflection)
-Distributed Systems (2-tier, 3-tier, n-tier, peer2peer)

Sources:

Difference between Software Architecture and Software Design

What is Software Architecture?

What is software architecture?

example:

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

Like any other complex structure, software must be built on a solid foundation. Failing to consider key scenarios, failing to design for common problems, or failing to appreciate the long term consequences of key decisions can put your application at risk. Modern tools and platforms help to simplify the task of building applications, but they do not replace the need to design your application carefully, based on your specific scenarios and requirements. The risks exposed by poor architecture include software that is unstable, is unable to support existing or future business requirements, or is difficult to deploy or manage in a production environment.