Software architecture

1. So software architecture deals with how we go from requirements to code right there has to be something in between. And often, it seems like magic, pulling a rabbit out of your hat.
2. So software architecture and design deals exactly
   1. what that how the software is to be structured
   2. what its components are what its pieces are
   3. and how those pieces are related to each other.
3. And for large systems of particular. It usually makes sense to divine. This does that whole design activity into two parts architecture and
   1. architecture dealing more with a high level
   2. and design dealing more with the low level

The architect

1. see ppt
2. Domain = Whatever is the real world context in which you’re building this. So if you’re building a tax software. The architect has to have a deep understanding of tax laws and processes for filing taxes and all that, if you’re building a system for

Limitation of analogy

1. see ptt

Define software architecture

1. SEE PPT
2. What is "principal"
   It says a software systems architecture is a set of principles design decisions about the system so principle being most important and what is most important for a particular system just has to do on that particular system what the stakeholders defined as most important
3. Not all parts of desgins are architecture but the most important one
4. SEE PPT
5. SEE PPT (textbook)
   1. not only about funcitonal funcitonality but also about non-functional functionality
6. SEE PPT
7. SEE PPT

Why software architecture

1. cannot understand the whole application through a piece of code

Elements of software architecture

1. components are the ones that have to do with data and processing. These are like the boxes in the architectural diagrams.
2. connectors, have to do with the interaction between the different parts in the architecture, the interactions between components.
3. those are arranged into configurations in a specific way such that they can accomplish the functional and non functional requirements of the system.

Architecture Erosion

1. prescriptive – > WHAT written before coding
   1. plan to be built
2. the descriptive – > WHAT it was actually implemented.
   1. what has been built
3. These two not always match. Changes are usual
4. Architecutre Erosion: SEE PPT