Chapter 8: (+ 4 1) View into Architecture (Hooold up, that’s Clojure, that’s on the other blog).

So, this blog is about the “4+1” view into architecture. Why is it called that way? Why not only 5 (as, for what I have learned, 4+1 equals 5)? Well the concept in which this type of view rose is the key. What this type of view proposes are 5 grouped different types of views; Logical, Development, Process, Physical, and Use-Case.



The logical view explains us what sort of objects are we going to be building, such as classes and objects, and how this object act within the system logistics. However, the scope of this view is limited only to the implementation of the system.

The second view is the development view, which is aimed towards developers explaining how the system is organized. With this in mind, the developers will be able to recognize which parts of the system are connected to which. This consideration allows the developers to work with the system under development. This view is only focused on the organization of the system development.

The process view describes how the concurrency is managed, inside the software and on the process of using the software. This view is limited to what happens when the system is functioning beyond the scope of software.

The physical view tells us how the software and hardware are related, how the system will be installed, how will it be looking like, and what part of the system goes where. Finally, the use case view, which explains how the system is expected to behave, and how the actors are supposed to use the system.

The first four views are complemented with the last view (use-case), because all the past views explain what objects are we building, how we are going to develop it, how the process behind works and how everything is seen physically, but the last view is the one in charge of giving away how the system (beyond how it was built) should work.


While not my favorite view, I consider Use-Case to be extremely important when whatever tools are being used doesn’t cover how the system should react to the final users.

References:
- DrJKasurinen (2014). 4.6 SEM: 4+1 view into software architeture. Available on: https://www.youtube.com/watch?v=5r60GuRu8V0
- kanika24fps (2009). Six Blind Men. Available on: https://www.youtube.com/watch?v=iBqgr5xZLz0
 - Booch Grady (2010). The Elephant and the Blind Programmers. Available on: http://webcem01.cem.itesm.mx:8005/s201713/tc3049/the_elephant_and_the_blind_programmers.pdf

Comments

Post a Comment

Popular posts from this blog

Chapter 4: Architectus Reloadus vs Architectus Oryzus

Image
So, who needs architects anyways? Here lies one of the most important roles in the software world the unstoppable Architectus Reloadus. After reading the article, it reminded me of an image picturing 2 groups of people; each group having either a boss or a leader commanding them. While the boss was just instructing where to go and what to do, the leader was working with its group. This is the same analogy we get in the article with the 2 types of architects mentioned, the  Architectus Reloadus  and the  Architectus Oryzus . Architectus Reloadus  is the architect that proclaims himself as the  most important part of the project , as the design is made only by him, leaving the other developers to follow. While the  Architectus Oryzus  works within the team to improve the team’s level so they can approach harder and more complex issues. In other words, the Architectus Oruzys  is a guide, skillful enough for being the anchor of the team, and clearly selfless, as he works at the
Read more

Chapter 9: Microservice Architecture: A whole new Architectural world.

Image
After reading the article, I started relating microservice architecture with the activity we made when we talked about components and Lego bricks in class: This type of architecture is made of smaller and independent services that are linked together to form a concrete service. With the image below, we can see a clear representation of how this is conceptualized. However, there is a small detail that separates microservices from monolithic services; while the later gathers all functionality into a single process, the microservice separates each part of the functionality into a separate service, allowing scaling with distribution of the services, replicating as needed. This is the aspect I liked the most; low key planned modularity for software architecture (or at least that’s how I see it) There are a lot of interesting features of this type of architecture (with a heavy approach to encapsulation, as I dare to confirm), such as Componentization via Services, Organized ar
Read more

Chapter 11: Metaprogramming

Image
The last article read was “An Introduction to Metaprogramming”, an interesting article where Ariel explains the concept and some examples of metaprogramming. Starting of describing the different types of metaprograms, like compilers, interpreters, parser generators, assemblers and preprocessors, metaprograms come in many shapes and forms, which main goal is to eliminate or reduce error-prone programming tasks. I have heard of this concept as a utopic approach to things, however, I haven’t seen metaprogramming first hand. At first, I thought it was a really complex way to do things, but after reading the article, it doesn’t go that deep into weirdness. Beginning with the first example; it clarified how the concept of metaprogramming works, a script that wrote another file with the code expected. While the ruby snippet shown was not some other world stuff, but the example is pretty clear, we can write codes through code. Now, the second example goes a little bit deeper
Read more