Skip to main content

Software Architecture


On today’s blog we are going to review a chapter from Pete Goodlife’s Code Craft, which is all about the basic theory of software architecture, where among the topics there is like the definition, reasons of why we should use it and lots of characteristics, of course it includes examples.

One part of the text talks about the high level view, which is when the details of how was it created or implemented doesn’t appear, the only thing we can see is the essential internal structure of it and the most fundamental and important characteristics of its behaviour, which can come in-handy for many thing like identifying the key modules of all the software, identify and determine the nature of all the most relevant interfaces in the software, identify how and which components communicate with each other and to clarify the correct roles and responsibilities of the subsystems

The chapter also talks about other 4 views for the software architecture, one of them is the conceptual view, that can be also called logical view, where this one only shows the major parts of the system and its interconnections.

Other view is the implementation view, which is seen in terms of actual implementation modules which sometimes may differ from the conceptual model.

The process view is designed to show the structure in tasks, communication or process terms in a more dynamic form, this one is used more often when there is a high level of concurrency in the system.

And last but no least, the deployment view, which is basically used for showing the allocation of the tasks to physical nodes in a more distributed system

To end this entry, I would to put a phrase from this chapter which, from my own opinion, is very accurate and makes lots of sense, "As an up-front activity, the architecture is our first chance to map the problem domain (the Real-World problem we are solving) to a solution domain". So now you know it, the basics of software architecture so your ca improve your coding.

Comments

Popular posts from this blog

Who needs an archiect?

I n this blog entry we are going to talk about an article written by Martin Flowers entitled, “Who needs an architect”, were it talks about software architecture (kind of obvious don’t you think) and the architect's role in a software development team. To be honest, a didn’t get the author’s purpose of the article, but I think I have got the general idea, so I can review this properly. On the article the author gives many two explanations the software architecture, one of them is quoted by someone else which basically says that a high level concept of a system is only visible (or significant) to developers, now, for me this is really abstract, because I don’t thing it applies to all the projects of this topic, but the second one which is given by the author himself says that the architecture is a a shared understanding of the system design by all of the expert developers involved in the Project, now this makes more sense to me because we can understand that not only the d...

Ethical Reflection on Ready Player One

Todays blog is the last one!!!!!! It has been quite a journey, but as everything, its time to end this. On today’s blog we are going to talk about a book, Ready Player One, written by Ernest Cline, this is the book that everyone in my class has been reading during the semester, and it was really, really good, I actually enjoyed it a lot. The plot is quite simple, it talks about a kid called Wade Watts, in a world were the actual real world is kind of a huge disaster for not saying other words, but in the book exist another world, a virtual one called the Oasis, were technically everyone plays it, because it was a whole new world, not only a videogame, in there people can have jobs, meet people, study in schools. The creator of the Oasis was James Halliday, and I say was because in the book he is dead, and after his dead he created 3 easter eggs that, when a player has the three, that player will own the oasis, and be the richest person in the world, and that is the goal of our dear...

Microservices

On today’s blog entry we are going to talk about the Microservices architecture. This architecture has an approach where when we are developing a single app, we develop it as lots of small services, each of them running on its own process and communicating with each other with something that can bind them together. Now I have already used microservices without knowing I was actually using them, perhaps this architecture is quite intuitive for best practices or something like that, but anyway the author of the article gives some characteristics about this which are the following: ·          Componentization via Services: The components of the microservice need to be gather into libraries that will be used later on by the microservice to communicate with remote parts of the whole program. ·          Organized around Business Capabilities: This characteristic refers that we need to create divisions, e...