Software Architecture

LUIS FERNANDEZ MUNOZ

Because?

Paying attention to software architecture is like building pieces that stand on top of each other.
First understanding, software is pieces that stand on top of each other.

Much attention in the software architecture of Complex Systems, if the software does not have a
defined form, a parable of the six blind wise men and the elephant.

The Blind Men and the Elephant is a parable originally from India , from where it achieved notable
dissemination. It has been used to illustrate man's inability to know the totality of reality. At
different times it has been used to express the relativity, opacity or inexpressible nature of truth,
the behavior of experts in fields where there is a deficit or lack of access to information, the need
for communication, and respect for perspectives. different.

So if we don't have a general vision of things, they get out of hand.

Complex systems (Design), meet certain characteristics, in particular the complex systems that
humans copy from nature, hierarchical, separate issues, have relative primitive elements, common
interaction mechanisms, systematically everything is made the same, they communicate the same,

If we start programming like crazy I have a mess.

Let's give it shape to pay attention to the shape, which this would be the software architecture.

So that?

So why pay attention to the architecture of the software... so that it has software quality, if the
software is well built it will allow me to do effective development (program by adding lines and
that these lines work without destroying everything, not having a design fragile that if we add lines
the software breaks everywhere), effective and efficient (it doesn't cost a lot to make a change).
(program development) scalable and adaptable criteria of quality, security, portability ->
maintainability depends on the quality of software.

Performance, a well-designed, modular system with little coupling, high cohesion, with limited
part size or a code that can be used, but with software that is a mess you will not increase
performance.

If we develop with design with architectures, seeing the way your software is charging, we save
money and time.

When?

This has been said since the origin of programming by Edsger Dijkstra, be very careful with the
languages we choose.

El humble programmer – the humble Programmer.

At the beginning there is theory!!!!

Where?

Software engineering, around UML software architecture-Documentation

Who?

Edsger Dijkstra, Scientific/Business Community.

Methodologies:

Rational proposes top/down look at an overview

The Agiles, start programming, start programming but very well and together then the
architecture emerges and appears.

Language and thought are closely related!!

In development, knowing two or three languages with very different paradigms feeds you and
refreshes you so that you are no longer the same.

If we don't know why? Where do you come from and why? Where are you going .. On the way we
get lost very easily.

Clarify concepts, of which:

Mastermind logic game

1.- System architecture vs. Of the Software.

2.- Actors and Attributes of Architecture.

3.- Architecture Documentation.

Package principle:

1.- Common reusability principle.

2.- Common closing principle

3.- Principle of equivalence between reusability and deliverable. (Git)

4.- Principle of acyclic dependencies. (if one class is related to the other and the other is related to
the one, we say that it has a cycle (this does not apply) it could be allowed between classes but not
within packages)

5.- Principle of stable dependencies.

6.- Principle of stable abstractions

These two teach you the principle of Open/Close

7.- Package metrics.

Packages (unit of software architecture) comply with the single responsibility principle.

ROLE OF THE SOFTWARE ARCHITECT

Propose, maintain and ensure that the architecture is correct, meets the principles, has the
architectural styles it must have ( in the rational methodology ) and gives it time to study the
requirements, use cases, proposes an analysis architecture, begins to implement, performs
performance tests, tests the risks when you already have a working prototype and with this it
hands over to the development team monitoring and maintaining that things are done well.

Every developer doesn't deliver code without a unit test.

For the subject of testing there is a Tester, when the tester makes his proposal he meets with the
architect and asks him what the risks of the project are and the architect confesses I'm afraid of
this or this... well the other tells him I'm going to do it. find to show you what the reality of your
fears is, the tester is not going to screw around, he is going to inform.

In Agile methodologies there is not merely one software architect… the entire team is responsible
for the software architecture and how they do it… All, in addition to developing in the refactoring
process, is to improve the quality of software that already works.. First they program so that it
works so that the tests pass and when it is already working then refactoring with the same
functionality improves the quality.
Everyone spends time improving the quality sometimes needed for all developers and making a
general improvement here is when the architecture emerges.

…………………………………

About what models and diagrams must be made by at least one architect to
say that he has an architecture.
Answer 4 + 1 views, (Documentation of architecture) by Philippe Kruchten.

4+1 is a model designed by Philippe Kruchten to "describe the architecture of software systems,
based on the use of multiple concurrent views." Views typically describe the system from the
point of view of different stakeholders, such as end users, developers, or project managers. The
four views of the model are: logical view, development view, process view and physical view.
Additionally, a selection of use cases or scenarios is often used to illustrate the architecture,
serving as another view. Therefore the model contains 4+1 views: 1

 Logical view: The logical view is focused on describing the structure and functionality of
the system. The UML diagrams used to represent this view are Class Diagram ,
Communication Diagram , Sequence Diagram . 2

 Development View: The development view illustrates the system from the programmer's
perspective and is focused on the management of software artifacts. This view is also
known as a deployment view. Use the UML Component Diagram to describe system
components. Another UML diagram used in the development view is the Package Diagram
.2

 Process View: The process view discusses the dynamic aspects of the system, explaining
system processes and how they communicate. It focuses on the behavior of the system at
runtime. The view considers aspects of concurrency, distribution, performance, scalability,
etc. In UML the Activity Diagram is used to represent this view. 2

 Physical View: The physical view describes the system from the point of view of a systems
engineer. It is related to the topology of software components at the physical layer, as well
as the physical connections between these components. This view is also known as a
deployment view. In UML the Deployment Diagram is used to represent this view. 2
  Scenarios: The description of the architecture is illustrated using a set of use cases , or
scenarios , which generates a fifth view. Scenarios describe sequences of interactions
between objects and between processes. They are used to identify and validate the
architectural design. This view is also known as the use case view.

Philippe Kruchten¸

MICROSERVICES, SYSTEM ARCHITECTURE.

SOFTWARE ARCHITECTURE CONCEPTS

ARCHITECTURE:

 THE art or science of building, specifically, the art or practice of designing and building
structures and especially habitable ones.
 Formation or construction as or as if it were the result of a conscious act.
 A unified or coherent form or structure.

It can be built by one person. Built more efficiently and timely by one team.
Requirements: A Simple Model, Simple Requirements: modeling, well-defined process,
Processes and simple tools powerful tools.
SYSTEMS WITH HIGH TECHNICAL COMPLEXITY

SYSTEMS WITH LOW TECHNICAL COMPLEXITY

TYPICAL CRUD APPLICATION OR MAKING EXCEL FRAMEWORKS, SQL DB

SYSTEMS WITH HIGH MANAGEMENT COMPLEXITY

APPLICATION WITH CUSTOMERS, SUPPLIERS, AND ALL CLASSES

SYSTEMS WITH LOW MANAGEMENT COMPLEXITY

SYSTEM VS SOFTWARE ARCHITECTURE

The software industry delights in taking words and stretching them into any number of subtly
contradictory meanings. One of the biggest affected is “architecture”. I tend to see architecture as
one of those impressive-sounding words, used primarily to indicate that we're talking about
something that's important. Martin Fowler.

System Architecture Definition:

The fundamental organization of a system embodied in its components, its relationships with
others and its environment and the main guides of its design and evolution. IEEE
Difference between System Architecture and Software Architecture

At the highest level, a system often comprises Hardware, Software, Firmware, etc. Therefore,
when obtaining and selecting the most suitable system architecture, the most likely output is a set
of functional building blocks, some of which are hardware, some of which are software, etc. The
building blocks of the software, the software subsystems, will have a set of requirements that
must be analyzed and designed in the same way as is done in the higher level Systems Architecture
. However, at this next level, you are more likely to worry about overall software performance,
user interfaces, database architectures, etc.

THE SOFTWARE ARCHITECTURE IS WITHIN THE SYSTEM ARCHITECTURE

The architecture is spoken at the package level.

Definition of software architecture

The architecture of a software-intensive system is the structure or structures of the system,

comprising software elements (class packages), the externally visible properties of those elements,
and the relationships between them. Carnegie-Mellon University

An architecture is the set of significant decisions about the organization of a software system, the
selection of the structural elements (packages) and their interfaces of which the system is
composed together with its behavior as specified in its collaborations between these elements,
the composition of these structural and behavioral elements into progressively larger subsystems
and the style of architecture that guide the organization... these elements, their interfaces, their
collaborations and their composition. Booch, Rumbaugh and Jacobson

Analogy with building architecture, we propose the following software architecture model:
{elements, forms, justification}. This is a software architecture is a set of architectural elements
(packages) that have a particular form. We distinguish three classes of architectural elements:
processing elements, data elements, and connections between elements. The processing
elements (controllers - presenters) are components that provide the transformation of the data
elements: the data elements (models) are those that contain the information used and
transformed: the connection elements (which can be both processing , data or both) are the glue
that binds the different pieces of the architecture together. Perry and Wolf

ANALOGY
AN INSTALLED SOFTWARE SYSTEM CONSISTS OF: A SKYSCRAPER CONSISTS OF:
  Megabytes of data and binary code  Millions of bricks or tons of cement.
 Seated on some storage medium of one or more  Seated on solid ground.
computers.  While it works, it needs power supply for air
 While executing some of your code is loaded into conditioning, elevators, light, etc.
main memory.

DIFFERENCE BETWEEN SOFTWARE DESIGN AND SOFTWARE ARCHITECTURE

 Software design focuses on the implementation of the functionalities (requirements) of the

system in terms of classes, their relationships, data they handle, use cases, etc.
 Software architecture focuses on packages, it does not focus on implementation or application
of design patterns.