Software Architecture - Revision history

User at 00:11, 28 March 2024

2024-03-28T00:11:33Z

User at 20:56, 11 April 2023

2023-04-11T20:56:29Z

Show changes

User at 14:20, 23 December 2022

2022-12-23T14:20:48Z

User at 14:19, 23 December 2022

2022-12-23T14:19:30Z

User at 18:23, 12 December 2022

2022-12-12T18:23:18Z

Show changes

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T18:25:34Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

Show changes

User at 17:12, 17 April 2020

2020-04-17T17:12:18Z

User at 17:11, 17 April 2020

2020-04-17T17:11:47Z

User at 17:10, 17 April 2020

2020-04-17T17:10:20Z

User: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

2019-01-07T06:15:51Z

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

Show changes

@@ Line 45: / Line 45: @@
 *Event-Driven Architecture: Many programs spend most of their time waiting for something to happen. This is especially true for computers that work directly with humans, but it’s also common in areas like networks. Sometimes there’s data that needs processing, and other times there isn’t. The event-driven architecture helps manage this by building a central unit that accepts all data and then delegates it to the separate modules that handle the particular type. This handoff is said to generate an “event,” and it is delegated to the code assigned to that type.  Programming a web page with JavaScript involves writing small modules that react to events like mouse clicks or keystrokes. The browser itself orchestrates all of the input and makes sure that only the right code sees the right events. Many different types of events are common in the browser, but the modules interact only with the events that concern them. This is very different from the layered architecture, where all data will typically pass through all layers.
 *Microkernel Architecture: Many applications have a core set of operations that are used again and again in different patterns that depend upon the data and the task at hand. The popular development tool Eclipse, for instance, will open files, annotate them, edit them, and start-up background processors. The tool is famous for doing all of these jobs with Java code and then, when a button is pushed, compiling the code and running it. In this case, the basic routines for displaying a file and editing it are part of the microkernel. The Java compiler is just an extra part that’s bolted on to support the basic features in the microkernel. Other programmers have extended Eclipse to develop code for other languages with other compilers. Many don’t even use the Java compiler, but all use the same basic routines for editing and annotating files. The extra features that are layered on top are often called plug-ins. Many call this extensible approach a plug-in architecture instead. Richards likes to explain this with an example from the insurance business: “Claims processing is necessarily complex, but the actual steps are not. What makes it complex are all of the rules.” The solution is to push some basic tasks—like asking for a name or checking on payment—into the microkernel. The different business units can then write plug-ins for the different types of claims by knitting together the rules with calls to the basic functions in the kernel.
-*Microservices Architecture: Software can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change. The microservice architecture is designed to help developers avoid letting their babies grow up to be unwieldy, monolithic, and inflexible. Instead of building one big program, the goal is to create a number of different tiny programs and then create a new little program every time someone wants to add a new feature. Think of a herd of guinea pigs. “If you go onto your iPad and look at Netflix’s UI, every single thing on that interface comes from a separate service,” says Richards. The list of your favorites, the ratings you give to individual films, and the accounting information are all delivered in separate batches by separate services. It’s as if Netflix is a constellation of dozens of smaller websites that just happens to present itself as one service. This approach is similar to the event-driven and microkernel approaches, but it’s used mainly when the different tasks are easily separated. In many cases, different tasks can require different amounts of processing and may vary in use. The servers delivering Netflix’s content get pushed harder on Friday and Saturday nights, so they must be ready to scale up. The servers that track DVD returns, on the other hand, do the bulk of their work during the week, just after the post office delivers the day’s mail. By implementing these as separate services, the Netflix cloud can scale them up and down independently as demand changes.
+*[[Microservices Architecture]]: Software can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change. The microservice architecture is designed to help developers avoid letting their babies grow up to be unwieldy, monolithic, and inflexible. Instead of building one big program, the goal is to create a number of different tiny programs and then create a new little program every time someone wants to add a new feature. Think of a herd of guinea pigs. “If you go onto your iPad and look at Netflix’s UI, every single thing on that interface comes from a separate service,” says Richards. The list of your favorites, the ratings you give to individual films, and the accounting information are all delivered in separate batches by separate services. It’s as if Netflix is a constellation of dozens of smaller websites that just happens to present itself as one service. This approach is similar to the event-driven and microkernel approaches, but it’s used mainly when the different tasks are easily separated. In many cases, different tasks can require different amounts of processing and may vary in use. The servers delivering Netflix’s content get pushed harder on Friday and Saturday nights, so they must be ready to scale up. The servers that track DVD returns, on the other hand, do the bulk of their work during the week, just after the post office delivers the day’s mail. By implementing these as separate services, the Netflix cloud can scale them up and down independently as demand changes.
 *Space-Based Architecture: Many websites are built around a database, and they function well as long as the database is able to keep up with the load. But when usage peaks and the database can’t keep up with the constant challenge of writing a log of the transactions, the entire website fails. The space-based architecture is designed to avoid functional collapse under high load by splitting up the processing and storage between multiple servers. The data is spread out across the nodes, just like the responsibility for servicing calls. Some architects use the more amorphous term “cloud architecture.” The name “space-based” refers to the “tuple space” of the users, which is cut up to partition the work between the nodes. “It’s all in-memory objects,” says Richards. “The space-based architecture supports things that have unpredictable spikes by eliminating the database.” Storing the information in RAM makes many jobs much faster, and spreading out the storage with processing can simplify many basic tasks. But the distributed architecture can make some types of analysis more complex. Computations that must be spread out across the entire data set—like finding an average or doing a statistical analysis—must be split up into sub-jobs, spread out across all of the nodes, and then aggregated when it’s done.

← Older revision		Revision as of 14:20, 23 December 2022
Line 1:		Line 1:
−	In Software Architecture ~~in Practice (2nd edition), Bass, Clements, and Kazman define architecture as follows:~~	+	==Software Architecture Definition==
−	~~“The~~ '''software architecture''' of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”<ref>Definition of Software Architecture [https://www.pearson.com/us/higher-education/product/Bass-Software-Architecture-in-Practice-2nd-Edition/9780321154958.html Len Bass, Paul Clements, Rick Kazman]</ref>	+	The '''software architecture''' of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.<ref>Definition of Software Architecture [https://www.pearson.com/us/higher-education/product/Bass-Software-Architecture-in-Practice-2nd-Edition/9780321154958.html Len Bass, Paul Clements, Rick Kazman]</ref>

@@ Line 74: / Line 74: @@
 ===See Also===
 *[[Software Architecture Analysis Method (SAAM)]]
 *[[Client Server Architecture]]
 *[[Architectural_Risk|Architectural Risk]]

@@ Line 77: / Line 77: @@
 [[Software Architecture Analysis Method (SAAM)]]<br />
 [[Software Development Life Cycle (SDLC)]]<br />
 [[Architectural_Risk|Architectural Risk]]<br />
 [[Architectural_Pattern|Architectural Pattern]]<br />

@@ Line 74: / Line 74: @@
 ===See Also===
 [[Architectural_Risk|Architectural Risk]]<br />
 [[Architectural_Pattern|Architectural Pattern]]<br />

← Older revision		Revision as of 17:10, 17 April 2020
Line 1:		Line 1:
	In Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman define architecture as follows:		In Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman define architecture as follows:
−	“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”<ref>Definition of Software Architecture [https://www.pearson.com/us/higher-education/product/Bass-Software-Architecture-in-Practice-2nd-Edition/9780321154958.html Len Bass, Paul Clements, Rick Kazman]</ref>	+	“The '''software architecture''' of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”<ref>Definition of Software Architecture [https://www.pearson.com/us/higher-education/product/Bass-Software-Architecture-in-Practice-2nd-Edition/9780321154958.html Len Bass, Paul Clements, Rick Kazman]</ref>