Software Architecture

This is the second entry of my Software Design and Architecture blog. This text is going to talk about specifically about Software Architecture based on a chapter from a book titled: "Code Craft", by Pete Goodliffe. First of all, it is important to know what Software Architecture is, it is explained with a metaphor as “building a software”, but it is also known as high-level design.

I found interesting the comparison the author made between physical architecture and software architecture and how during the “building” or development process there are four common views recognized:
-      Conceptual: Also known as a logical view. It shows the major parts of the system.
-      Implementation: Seen in terms of real implementation modules that sometimes differs from the conceptual model.
-      Process: Shows the dynamic structure in terms of tasks, process, and communication. Used when there is a high concurrency degree.
-      Deployment: Shows the allocation of tasks to physical nodes in a distributed system.

Also, the author explains what architecture is used for. It is used as the initial system design, and also to:
-      Validate: It’s the first chance to validate what are we building. Checking if the system will meet the requirements and if it is feasible. Also, it ensures no wasted effort, duplication work or redundancy.
-      Communicate: It is used to communicate the designed to all parties. It is useful to understand the system and for documentation.
-      Discriminate: It is really useful for decision making. An example is that it defines build versus buy decisions. 


Despite I think that software architecture is a key factor during software design and development (because of the reasons and aspects I already mentioned and also because it ensures software quality, one of the most important factors during this process), I didn’t like this chapter. It could be better explained using real-life examples that would allow readers to really understand the importance of software architecture. Explained examples are much better than just definitions.

Comments

Post a Comment

Popular posts from this blog

An Introduction to Metaprogramming

Hi, today's entry is going to talk about an article called “An Introduction to Metaprogramming” written by our professor Ariel Ortiz in 2007. First of all, I just want to mention that I’m really impressed because I didn’t know that our professor had many published articles and papers (we saw the others in my other blog for Compilers Design course). Basically, as its name says, it talks about metaprogramming, which is defined during the article as a program that generates other programs or just program parts. It is used to eliminate or just reduce a “tedious” programming task. It is like instead of writing complex machine code programs, we use any high-level language and use the compiler of that language to do the translation into the programs equivalent in machine code (low-level language). I have to admit that before reading this paper, I hadn’t fully understood the metaprogramming meaning and importance. We used and applied that term in a past course called Programming Languages...
Read more

Understanding the SOLID Principles

Hi, this entry is going to talk about a section called “Understanding the SOLID principles” from the book “Ace the Programming Interview: 160 Questions and Answers for Success” by Wiley in 2013. Basically, the acronym SOLID is explained a round this book section. This acronym stands for five accepted principles about object-oriented programming and design: 1.       S ingle Responsibility Principle: It stays that a class should have just one responsibility. Despite the fact that this principle sounds easy, I found it a little bit complicated, because the explanation wasn’t direct and simplified. Also, the author mentioned that there might be cases in which a class might have two responsibilities. So, at the end, what exactly does this principle stands for? 2.       O pen/Closed Principle: It stays that a class or a function should be open for extension but closed for modification. What does this mean? Our code must have the cap...
Read more

Microservices

Hi, today’s entry is going to talk about an article written by James Lewis and Martin Fowler called “Microservices” in 2014. Basically, by calling microservices, they are referring to like a particular way of designing software applications as suites of independently deployable services. But something interesting is that there is not a precise definition of that type of architectural style, there are only common characteristics around distinct organizations, business capability, automated deployment, intelligence in endpoints and also decentralized control of languages and data. This was the first time I heard this term, and something strange is that despite I didn’t notice about its existence I’d used them sometimes. Later in the articles, the authors gave us some characteristics that any Microservice Architecture must have. They are the following: 1.       Componentization via Services:  This is telling us that by building software, we put together...
Read more