sw eng test 1

define quanta

the smallest independently deployable unit of an architecture

define monolithic

a system where all functionality is built, deployed, and run as a single unified application

define distributed

a system where functionality is split across multiple independent components that communicate with each other over a network. often have multiple deployable units.

define technical partitioning

the separation of technical concerns. primarily for the purpose of decoupling. includes things like the features/operations you need to implement, what technologies are needed for those features and such.

define domain partitioning

the separation of domain concerns, or features. components based on “what” the system needs to do instead of “how” it should do it. what objectives the system must accomplish, what business constraints apply.

layered style quick facts

technical partitioning. monolithic. 1 quanta = basically just the whole thing. pros: cost, simplicity. cons: modularity, testability, deployability, evolutionary, performance, scalability, elasticity, fault tolerance.

layered style set up

drawn in n layers. usually 4 - presentation, business, persistence, database. most likely to be combined are business and persistence. logical horizontal layers. open vs. closed layers open can be skipped and closed cannot though be careful cause open creates tighter coupling. generally due to layers of isolation, changes in one layer of the architecture don’t impact other layers. avoid architecture sinkhole anti-pattern. very literal how to draw: each layer is a horizontal rectangle. the deployment groupings are rectangles around the other rectangles. arrows between deployment groupings. an open layer gets a dashed rectangle.

pipeline style quick facts

technical partitioning. monolithic. 1 quanta = basically the whole thing. pros: cost, simplicity, modularity. cons: deployability, elasticity, fault tolerance, performance, scalability.

pipeline style set up

made of filters and pipes connecting them. four types of filters: producer (output only), transformer (in/out, performs some operation on the input), tester (accepts input, tests on some criteria, optionally produces output based on test), consumer (termination point. persist results to database or display). particularly appears in tasks with one way processing. can have multiple paths. split operation is a bifurcation. do physical interactors as rectangles, filters/actions as circles, arrows between for pipes, 3-sided rectangle for database.

microkernel quick facts

technical or domain partitioning, 1 quanta = basically the whole thing, pros: cost, simplicity. cons: elasticity, fault tolerance, scalability.

microkernel set up

not in text book but he recommends including an explicit API layer. core system is a box that can itself be layer style or modular style (usually technical vs. domain partitioning). plug ins are boxes off to the side connected with lines. whole thing put in a big box. core system may connect to a database. usually core system has some sort of registry to know what plug ins exist. there are contracts that dictate how plug ins communicate with core system and what data is passed and how.

service-based quick facts

domain partitioning. 1 or more quanta = chunk with same database or user interface. distributed. pros: deployability, fault tolerance, modularity, cost, reliability, testability. cons: elasticity

service-based set up

user interface/s point into the services which are themselves layered or subdivided into domains, then directed into databases. may also have an api layer between interface and services.

event-driven quick facts

technical partitioning. 1 or more quanta = based on database interactions and request-reply processing (share single database = within same architectural quantum, request-reply = same quantum). distributed. pros: evolutionary, fault tolerance, modularity, performance, scalability. cons: simplicity, testability.

event-driven set up

broker topology: usually has multiple domain-based clustered instances. has a broadcasting nature. publish and subscribe messaging model. have rectangles for events, tubes for event channels, boxes for event processors. every event goes through an event channel. all the event channels basically make up the event broker cause it is directing the flow of messages. mediator topology; an event mediator controls the workflow for initiating events that require the coordination of multiple event processors. have the initiating event, a rectangle, an event queue, a tube, and the event mediator, a box. the mediator then directs into multiple event channels for whatever event processors are used after. often have multiple mediators for different domains or groupings of events. If showing the event mediator in detail, you can expand it to have a list of steps within and different initiating or processing events that occur at each step and then indicate where these other events are directed.

space-based quick facts

domain and technical partitioning. 1 or more quanta = depends on how the user interface is designed and units that synchronously communicate are all part of the same architectural quantum. distributed. pros: elasticity, performance, reliability, scalability. cons: cost, simplicity, testability.

space-based set up

separate processing units within which are components, in-memory data grid cache, and data replication engine. these feed into the virtualized middleware which has messaging grid, data grid, processing grid, deployment manager. then data readers and writers feed to and from a database. what is a processing unit? it contains app logic or portions of app logic ex. idk no examples in the book but it just has some of the functionality super helpful.

orchesration-driven service-oriented quick facts

technical partitioning. 1 quanta = whole ting. distributed. pros: scalability. cons: deployability, evolutionary, cost, performance, reliability, simplicity, testability.

orchestration-driven service-oriented set up

business services “layer” (not a layer like layered architecture) is a rectangle with little business sevices rectangles in it, enterprise servise bus is another big rectangle with orchestration engine and integration hub inside and the business services feed into orchestration engine and the enterprise services feed into integration hub. then we have enterprise services rectangle with many little enterprise service rectangles inside. then there are application service rectanges and infrastructure services rectangles at same level and they feed into enterprise services

microservices quick facts

domain partitioning. 1 or more quanta = basically each service i think. distributed. pros: deployability, elasticity, evolutionary, fault tolerance, modularity, reliability, scalability, testability. cons: cost, performance, simplicity.

microservices set up

client requests are depicted as rectangles up top. API layer is a large rectangle with parallelograms to represent individual apis for each service. then each service is its own rectangle with an inner rectange that says service with modules inside, and a database and arrows to and fro. also, there might be some pipes between because sometimes we do coupling in like segas and stuff.

modularity

the degree to which the software is composed of discrete components

simplicity

how easy it is to understand and learn (kind of self explanatory)

testability

how easily the developers and others can test the software

deployability

how easily the architecture can be deployed. is there a risk of anything breaking?

evolutionary

how easily the architecture can adapt and change over time

performance

stress handling, peak handling, analysis of frequency of functions used, capacity requried, response times (i think we mainly focus on response time)

reliability

degree to which a system functions under specified conditions for a period of time

scalability

ability for the system to perform and operate as the number of users or requests increses (could have more things)

elasticity

the ability of a system to automatically adjust resources based on demand (can auto make more or less things)

fault tolerance

does the software operate as intended despite hardware or software faults

cost

costs both monetary and time and labor based

cohesion

the relatedness of modules. things cohered are stuck together. separation of code for the purpose of elimination of entanglement and simplifying maintenance.

coupling

the composition of code.

connascence

a measure of co-dependence of classes

afferent coupling

the degree of incoming connections

efferent coupling

the degree of outgoing connections (ex calls to other APIs)

abstractness and instability with coupling

abstractness is the ratio of abstract artifacts to concrete artifacts. rarely change concrete implementations. abstract modules have high afferent coupling to the things they are implemented by but rarely change helping to not break things. instability measures the volatility of a code base. efferent coupling out of total coupling. higher is more instable/volatile as one thing changing causes big ripples.

difference between architecture and design

architecture describes the software application through components and their interactions with emphasis on data flow whereas design describes the software implementation through components and their interactions with an emphasis on data types.