These are my notes from the Chapter 1 from the book "Software Architecture: Foundations, Theory and Practice".

1.1 The power of analogy: the architecture of buildings

* architecture = design and construction of buildings
The analogy between design and construction of buildings and d. and c. of software is strong, and textbooks typically use it as example.

building	software
1. collecting requirements	1. specifying requirements
2. creating design to satisfy requirements	2. creating high-level design
3. refine design to create blueprints	3. developing detailed algorithms based on this design
4. construction based on blueprints	4. implementing algorithms
5. building is occupied and used	5. deploying and using the system

What is similar: the focus is the satisfaction of future occupant's needs; allows for specialization of labour (designer is different from contractor); it has many intermediate points;

Deeper insights:
- architecture is separate from, but linked to, physical structure (building/software); two architectures can be compared, described, discussed
- properties of structures are induced by the design of their architectures (eg. medieval castle)
- recognition of the distinctive role and character of an architect
- architecture is more central focus than the process, process just serves
- architecture has matured over the years into a discipline

Architectural styles are captured from experience and lessions from previous generations of architects.

Limitations of the analogy:
- we have good intuition for how buildings should be designed, but not for software
- it's harder to see the software architecture (software is intangible, abstract nature), so it's harder to evaluate
- software is more malleable (plastyczny, kowalny) than building materials, so buildings is not a good source to learn about ideas for dealing with change
- there's building industry, but no really such thing for software
- same software can be deployed in many places, buildings not really
- software is a machine, building's not (software's dynamic)

1.2 Architecture of the Web

Everyone knows WWW, but how is it actually built?

• from user's point of view: dynamic set of relationships among collections of information
  --> so it is: internet browser + set of documents
• from another point of view: dynamic collection of machines all over the world, which interact across computer networks
  --> so it is: physical machines (clients and servers)
• from developer's point of view: collection of independently written programs that interact according to HTTP, URI, MIME and HTML standard rules
  --> so it is: physical machines (clients and servers) + documents + interactions

but still there's much more to it.

<<and then there comes a set of 7 rules (constraints) which are supposed to clearly define what www is>>

<<and it is also said that these rules are the architectural style of the www>>

(...)

The following observations are important:

• the architecture of the Web is separated from the code that implements its elements; to understand the Web, the architecture is the only effective reference point!
• there's no single piece of code that implements the Web's architecture! instead we have it implemented by servers, browsers, proxies, routers, and network infrastructure;
• there are pieces of code that are equivalent in view of the architecture, but implemented in totally different ways, e.g. web browsers
• the constraints defining the Web are not apparent in the code, but still are visible by all the components (nicht verstehen)

--> Why this architecture is good for Web (why it was chosen and why did it make the Web become so popular)? We'll see in Chapter 11, but for now it is important that it was the focus on architecture which made it.

Sum up: Architecture is critical enabler for development of complex systems.

1.3 Architecture on the desktop

the following command in Linux:

ls invoices | grep -e August | sort

gives sorted list of all files in invoices directory whose names include string August => to understand how it works you need to understand filters and pipes

<<and then there follows the explanation of filters and pipes, and Linux commands>>

(...)

The architectural style, called pipe&filter, can be used in many applications then.

Sum up: Architectural concepts can make effective the development of applications, and help in reuse (in that case reuse of the Unix filters).

1.4 Productivity and product lines

(...)

The challenge for the manufacturer is to produce wide range of product which consumers demands, simultaneously exploiting /wykorzystywać/ commonalities among members of the product family (reusing). Reusing is good because it makes it 1. easier and 2. more reliable.

A problem and the solution which solves it because of focus on architecture (using product families):

Problem: Philips TV sets would become more and more expensive because of quickly advancing technology (hardware) and software capabilities.

Solution: they produced a steady stream of various products, containing /zatrzymywać/ their cost -> they formulated a product family. The types varied along three dimensions: price, output device, and geographical region. The main issues to address were commonality and variability of the products.

(...)

Sum up: Architectures are critical enablers for developing product families, a key element of many business strategies.

Want to leave a comment? Visit this post's issue page on GitHub and just post your comment as the issue's comment (you'll need a GitHub account. What? Like you don't have one yet?!).