cse 311 final exam
Architectural patterns
allow to predict quality attributes; facilitate reuse, benefit newcomer understanding of a system
Architectural views
focus on the subset of elements/relationships; help give insight to quality attributes; have trade-offs between them; are connected to functional requirements; determine the underlying architecture; are quantifiable
Best to worst cohesion
function, sequence, communicational, procedural, temporal, logical, coincidental
Architectural changes impact
many components
Message coupling
modules communicate by passing messages, Call a method sending no parameters
Content coupling
modules rely on each others' internal data or internal organization
Data (params) coupling
modules share data through parameters, such as in a subroutine call, Does not impact control flow
Global coupling
modules share the same global data
When getting an instance
must return instance, check the instance is not null, call a private constructor
What does software architecture focus on?
non-functional requirements; component interactions
Control coupling
one module controls the flow of another, Passing a flag to a method that alters control flow
3 types of non-functional requirements
technical constraints, business constraint, quality attributes
Data Coupling
If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent to each other and communicating through data. Module communications don't contain tramp data. Example-customer billing system.
Control Coupling
If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument.
Architecture decisions
can impact scalability; impact the subsequent software life cycle
Benefit of usability
improved perception of quality
Logical cohesion
Elements contribute to activities of the same general category (type)
Functional cohesion
All elements contribute to the execution of one and only one problem-related task
Sequential Cohesion
An element outputs some data that becomes the input for other element, i.e., data flow between the parts. It occurs naturally in functional programming languages.
Design vs architecture
Architecture: High-level abstraction, Concerned with communication between modules; Design: Low-level abstraction, Concrete solutions, Concerned with structuring modules
Functional Cohesion
Every essential element for a single computation is contained in the component. A functional cohesion performs the task and functions. It is an ideal situation.
Implicit invocation architecture style
Components: Connectors: Data element: Topology: Quality attributes: Usage: Limitations: How does it address coupling?: What does it look like?: How do they impact quality?: Relationship between styles?: characterized by calls that are invoked indirectly and implicitly as a response to a notification or an event; facilitates adaptation and assists scalability from indirect interaction between very loosely coupled components; aim to provide "information of interest" to relevant "consumers" of the information; limitation: timing cannot be guaranteed; publish-subscribe, event based
Data flow styles
Components: Connectors: Data element: Topology: Quality attributes: Usage: Limitations: How does it address coupling?: What does it look like?: How do they impact quality?: Relationship between styles?: concerned with data movement between processing components; does not support component interactivity well; computation is dependent on data availability; concerned with how data moves between independent processing components; data availability controls computation; orderly movement of data determines the structure; components are programs connected by data "streams"; limitation: do not support interactivity of components well; pipe and filter, batch sequential
Language based styles
Components: Connectors: Data element: Topology: Quality attributes: Usage: Limitations: How does it address coupling?: What does it look like?: How do they impact quality?: Relationship between styles?: object oriented and main program & subroutines; reflect control flow relationship of components; styles reflect the program styles that result from the traditional use of programming languages (C, C++, Java); limitation: scalability
MVC architecture style
Components: Connectors: Data element: Topology: Quality attributes: Usage: Dominant influence in the design of GUIs, The objective of the pattern is to promote separation between information manipulated by a program and depictions of user interactions with that information Limitations: Added Complexity, Less Efficient Data Access by View, View and Controller can be closely connected Pros: Faster Development, Support Multiple Views, Supports Asynchronous Techniques, Model Changes Localized, Model Does NOT Return Formatted Data How does it address coupling?: What does it look like?: How do they impact quality?: Relationship between styles?: decouples the view from the model; faster development; multiple view support; changes are localized; allows for multiple ways of presenting data
Blackboard architecture style
Components: independent programs Connectors: direct memory access, procedure call, database query Data element: data on the blackboard Topology: web/star with blackboard at the center Quality attributes: efficient (large) data sharing Usage: multi-agent (multi-expert) systems or heuristic problem-solving Limitations: not good for frequently changing data that needs to propagate and when data regulation is needed How does it address coupling?: decouples data from software-specific purpose, decouples the subsystems (programs) What does it look like?: How do they impact quality?: Relationship between styles?: relies on data store between multiple programs; decouples the data from software specific purposes; can reuse subsystems in other programs
Batch sequential architecture style
Components: independent programs Connectors: media/files (historically, people in a "sneaker-net") Data element: aggregate resulting from each completed program execution Topology: linear Quality attributes: modularity of execution and simplicity Usage: business processing (transactional and report generation) Limitations: lack of scalability, lack of interactivity of components How does it address coupling?: What does it look like?: How do they impact quality?: Relationship between styles?:
What is software architecture?
Describes components or "parts" of the software system, Describes the relationship of these components, How these components "fit" together, How these components "communicate" to each other, Architecture is NOT concerned with algorithms or data structures - these are lower level, Architecture is more abstract like a software blueprint
Sequential cohesion
Elements are involved in activities such that output data from one activity becomes input data to the next
Temporal cohesion
Elements are involved in activities that are related in time
Communication cohesion
Elements contribute to activities that use the same input or output data
Coincidental cohesion
Elements contribute to activities with no meaningful relationship to one another
Procedural Cohesion
Elements of procedural cohesion ensure the order of execution. Actions are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA.
Content Coupling
In a content coupling, one module can modify the data of another module or control flow is passed from one module to the other module. This is the worst form of coupling and should be avoided.; two modules can access each other's internal data and procedural information
External Coupling
In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc.
Stamp Coupling
In stamp coupling, the complete data structure is passed from one module to another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice made by the insightful designer, not a lazy programmer.
Modifiability
Property: The ability to change the software including the cost and risks of such changes, Four key considerations: What can change? What is the likelihood of the change? When is the change made and by whom? What is the cost of the change?
Interoperability
Property: The degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context, There are two aspects: Syntactic Interoperability: The ability to exchange data, Semantic Interoperability: The ability to correctly interpret the data being exchanged
ARCHITECTURE ANALYSIS ENABLES PREDICTION OF A SYSTEM'S QUALITIES
It is possible to make quality predictions about a system based solely on an evaluation of its architecture, Certain kinds of architectural decisions lead to certain quality attributes in a system, By making those decisions, we expect to be rewarded with the associated quality attributes, The earlier you can find a problem in your design, the cheaper, easier, and less disruptive it will be to fix
Testability
Property: The ease with which software can demonstrate faults through testing, Industry estimates indicate that between 30 and 50 percent (or in some cases, even more) of the cost of developing well-engineered systems is taken up by testing, There is a substantial amount of literature related to automating testing and reproducing failures
Performance
Property: The ability for a system to meet timing requirements, How do we reason on performance? Characterizing the events that can occur, Understand when they can occur, Evaluate the system or element's time-based response to those events
Security
Property: The ability for a system to protect its data from unauthorized access and providing access to authorized users of the system, There are two main types of issues: Gaining access to the protected data, Denying legitimate users access (denial of service)
Availability
Property: The system is there and ready to carry out its task when you need it to be, It is the ability of a system to mask or repair faults such that the cumulative service outage period does not exceed a required value over a specified time interval, Note: this does not mean it never fails, but it can recover from failures without impacting the users
Usability
Property: how easy it is for the user to accomplish a desired task and the kind of user support of the system, One of the cheapest and easiest ways to improve a system's quality, Well, the user's perception of quality
What is software design?
Recall: common problems have common solutions, The low-level creation of these solutions are design patterns, E.g., Classes, methods, and objects for Object Oriented Programs, Recall: poor design increases the maintenance effort (i.e., increases technical debt)
THE EARLIEST AND MOST FUNDAMENTAL, HARDEST-TO-CHANGE DESIGN DECISIONS
Software architecture is a manifestation of the earliest design decisions about a system, These early bindings carry enormous weight with respect to the system's remaining development, its deployment, and its maintenance life, An architecture design can be viewed as a set of decisions, The early design decisions constrain the decisions that follow, and changing these decisions has enormous ramifications
Logical Cohesion
The elements are logically related and not functionally. Ex- A component reads inputs from tape, disk, and network. All the code for these functions is in the same component. Operations are related, but the functions are significantly different.;describes an I/O module that is designed to perform all the different reads and writes to the different devices.
Why are excessive dependencies bad
make concurrent, term-based development harder; make it difficult to make changes to systems; make it more expensive to test changes; increase build times
Coincidental Cohesion
The elements are not related(unrelated). The elements have no conceptual relationship other than location in source code. It is accidental and the worst form of cohesion. Ex- print next line and reverse the characters of a string in a single component.
Temporal Cohesion
The elements are related by their timing involved. A module connected with temporal cohesion all the tasks must be executed in the same time-span. This cohesion contains the code for initializing all the parts of the system. Lots of different activities occur, all at init time.
Common Coupling
The modules have shared data such as global data structures.The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses and reduced maintainability.
Communicational Cohesion
Two elements operate on the same input data or contribute towards the same output data. Example- update record int the database and send it to the printer.
* Strategy design pattern
What are their purpose?: When do you use them?: Multiple related classes are different only in their behavior, Want to isolate business logic from implementation details in the algorithms, If you have a large conditional that switches between variants of the same algorithm (switch statements) How do they address coupling? : Pros: single responsibility principle, explicit dependencies principle, dependency inversion principle, dependency injection, inversion of control containers; Algorithmic Encapsulation, Scalability, Maintainability, Open/Closed Principle, Polymorphism, Testability (Unit Testing) Cons: Application is not Naive. Security Risk, Less efficient with memory, Too complex for simple programs., Should only be used for OOP languages What do they look like?
* composite design pattern
What are their purpose?: When do you use them?: Part-whole hierarchies; Treat individual objects and compositions of objects uniformly; Treat the hierarchy as single object; Representing part-whole hierarchy as tree structure; Bill of Materials, parts and subcomponents (wholes) that make up a manufactured product, It should be possible, for example, to calculate the total price either of an individual part or a complete subcomponent without having to treat part and subcomponent differently; Text document, part-whole hierarchy consisting of characters, pictures, etc. (parts) and lines, pages, etc. (wholes)., It should be possible, for example, to treat displaying a particular page or the entire document uniformly. How do they address coupling?: Pros: Less objects are created, so it uses less memory, Reduce the run time by sharing objects, More user friendly since the client can use the interface from component, Makes adding new components easy, Allows for building and changing complex hierarchies dynamically at run-time, The pattern shows how to apply recursive composition to build complex hierarchical object structures dynamically at run-time Cons: It is harder to restrict the type of components of composite, The design becomes overly general, The programmer will have to rely more on run-time checks since they can't use type System, Nested groups are not supported What do they look like?
* visitor design pattern
What are their purpose?: When do you use them?: performing a function on a group of similar kind of objects, want to separate distinct and unrelated How do they address coupling?: Pros: adaptable? Only need to change visitor inplementation if logic changes Separation of concerns, single responsibility principle, open close principle Cons: extendability What do they look like?
* facade design pattern
What are their purpose?: When do you use them?:The facade pattern is generally most useful when a system is very complex or otherwise difficult to understand, as it hides the complexities of the system behind a simpler interface. The client(s) interact(s) with the facade interface in order to access the functionality of the system, allowing them to use the system without knowledge of its inner-workings.; complex system, source code unavailable, entry point is needed for each layer (in a layered software), implementations are highly coupled How do they address coupling?: reduces coupling? Coupling is not reduced Pros:Reduces coupling to exactly what classes need to interact, Customizable to what client wants, change the facade any way you want, (Modifiability)?, Can be used to secure data from subsystems so user only sees what they need to see(Security), improve readability and usability, follows law of demeter, makes complex system easier to use/understand, high usability Cons: Sometimes changing subsystems means having to change the facade, May be an unnecessary layer added if it is a simple system, Having a "God" Facade means that you have increased coupling, the facade connects to all objects, subsystems., user are less in control, low modifiability?, low testability What do they look like?
* proxy design pattern
What are their purpose?: "Controls and manages access to the object they are protecting", Used for hiding the structure and complexity of the main object, Avoids duplication of objects Helps reduce memory usage, class acting as an interface to something else, control access to a resource, control access to client by resource; class that functions as an interface between a client and a server-side object When do you use them?: If a resource is difficult to manage, a proxy to this may be used to manage it, Known as a Virtual Proxy, E.g., for a video file, have a proxy load the file as it's used How do they address coupling?: Pros: Very basic, natural abstraction of a resource, Helps clients protect information like IP address , Can be used to filter website access ; maintain ability, reliability, can improve performance of loading time, Provides security by hiding information about the real object, Can provide optimization for on demand loading, Provides intermediate logic on behalf of the client or server to save time/resources; interoperability, security, availability, performance, usability Cons: Not the most secure way to protect information, If some users access the object directly and some access it through the proxy it can cause disparities, Coupled through the real object, Creates another level of abstraction, complexity What do they look like?
* decorator design pattern
What are their purpose?: A design pattern that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other objects in the same class. focused on solutions to recurring design problems, Functionalities or attributes can be added/removed from objects dynamically at run time. When do you use them?: When you want to add new responsibilities to objects without changing the object's class, When the new responsibility can be separate from the individual class, When it is not practical to extend by sub-classes breaking down complex objects, add to a class without changing functionality How do they address coupling?: Pros: can be used instead of subclassing (compile time & all instances), work can be done incrementally, Allows for increased functionality of an object at program runtime, "Pay as you go" approach to adding functionality, you can gradually add more features; flexibility, adaptability, compatibility, modifiability Cons: complexity, decorators on decorators chain, Can make object instantiation complicated (instantiate the original object along with however many decorators attached to it), Complicated to have each decorator keep track of the other decorators in the program for the same object What do they look like?:
Prototype design pattern
What are their purpose?: Allows copying existing objects without making your code dependent on their classes, Declares a common interface for all objects that support cloning, Creates an object of the current class and carries over all of the field values of the old object into the new one (even private ones) When do you use them?: Your code should not depend on the concrete classes of objects that you need to copy, Example: your code works with objects passed to you from 3rdparty code via some interface, To reduce the number of subclasses that only differ in the way they initialize their respective objects, Instead of instantiating a subclass that matches some configuration, the client can simply look for an appropriate prototype and clone it How do they address coupling?: Pros: Can clone objects without coupling to their concrete classes, Can get rid of repeated initialization code in favor of cloning pre-built prototypes, Can produce complex objects more conveniently, An alternative to inheritance when dealing with configuration presets for complex objects Cons: Cloning complex objects that have circular references might be very difficult What do they look like?:
Template method
What are their purpose?: Defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure, Breaks down an algorithm into a series of steps, turn these steps into methods, and put a series of calls to these methods inside a single "template method", Abstract steps must be implemented by every subclass, Optional steps already have some default implementation, but still can be overridden if needed, A hook is an optional step with an empty body, Hooks are placed before and after crucial steps of algorithms, providing subclasses with additional extension points for an algorithm When do you use them?: Use the Template Method pattern when you want to let clients extend only particular steps of an algorithm, but not the whole algorithm or its structure, Use the pattern when you have several classes that contain almost identical algorithms with some minor differences, since you might need to modify both classes when the algorithm changes How do they address coupling?: Pros:Can let clients override only certain parts of a large algorithm, making them less affected by changes that happen to other parts of the algorithm, Can pull the duplicate code into a superclass Cons: Some clients may be limited by the provided skeleton of an Algorithm, You might violate the Liskov Substitution Principle by suppressing a default step implementation via a subclass, Template methods tend to be harder to maintain the more steps they have What do they look like?: aims to reduce duplicate steps of similar algorithms; defines the skeleton of an algorithm to reduce duplication of common steps
* command design pattern
What are their purpose?: Encapsulates all information to perform a request/trigger, Trigger is also interchangeably known as an "invoker". Allows the parameterization of clients with various different requests. Allows the saving/prioritizing of requests in a queue. When do you use them?: How do they address coupling?: decouples the class that call the command to execute and the class that actually executes it, decouples the object the invokes the operation from the object that performs it Pros: provides flexibility as well as extensibility, new commands can be added without having to change existing code; allows for sequences of commands to be executed by creating a queue like structure, modifiability Cons:high number of classes usually needs to be created, complexity, maintainability What do they look like?:
Factory method
What are their purpose?: Provides an interface for creating objects in a superclass and allows subclasses to alter the type of objects that will be created, Replaces direct object construction calls (i.e., using the new operator) with calls to a special factory method, Objects returned by a factory method are often referred to as products When do you use them?: You do not know beforehand the exact types and dependencies of the objects with which your code should work You want to provide users of your library or framework with a way to extend its internal components How do they address coupling?: Pros: Avoid tight coupling between the creator and the concrete products, Single Responsibility Principle: can move the product creation code into one place in the program, making the code easier to support, Open/Closed Principle: can introduce new types of products into the program without breaking existing client code Cons: The code may become more complicated since you need to introduce a lot of new subclasses to implement the pattern What do they look like?: decouple products from their creators; avoid tight coupling between the creator and the products; enforces the single responsibility principle; enforces the open/closed principle; avoids tight coupling between creators and concrete products
* state design pattern
What are their purpose?: allow modification of an object's behavior via internal state changes When do you use them?: How do they address coupling?: State is beneficial in terms of performance, but its implementations can cause hardships down the road,The disadvantage is each State derived class has knowledge of (coupling to) its siblings, which introduces dependencies between subclasses. Pros: Implement polymorphic behavior, Removes the dependency on if/else conditional logic, Improves cohesion, Improves code maintenance, Single class can have multiple uses, Can programmatically change the state by updating the variable within the class, Lowers coupling through simplicity Cons: Needs to write a large amount of code, Difficult to review the structure, Makes context behavior more brittle, Issues arise with multiple states needed to exist simultaneously, More simultaneous states = more duplicate classes What do they look like?:
* observer design pattern
What are their purpose?: mainly used for event handling systems When do you use them?: mainly used for event handling systems, most common in MVC How do they address coupling?: principle of loose coupling between objects that interact with each other Pros: It supports the principle of loose coupling between objects that interact with each other, It allows sending data to other objects effectively without any change in the Subject or Observer classes, Observers can be added/removed at any point in time Cons: The Observer interface has to be implemented by ConcreteObserver, which involves inheritance. There is no option for composition, as the Observer interface can be instantiated. If not correctly implemented, the Observer can add complexity and lead to inadvertent performance issues. In software application, notifications can, at times, be undependable and result in race conditions or inconsistency. What do they look like?
Adapter design method pattern
What are their purpose?:Allows objects with incompatible interfaces to collaborate, An adapter is a special object that converts the interface of one object so that another object can understand it, An adapter wraps one of the objects to hide the complexity of conversion happening behind the scenes When do you use them?:You want to use some existing class, but its interface is not compatible with the rest of your code, You want to reuse several existing classes that lack some common functionality that can't be added to the superclass How do they address coupling?: Pros: Single Responsibility Principle: can separate the interface or data conversion code from the primary business logic of the Program, Open/Closed Principle: can introduce new types of adapters into the program without breaking the existing client code, as long as they work with the adapters through the client interface Cons: The overall complexity of the code increases because you need to introduce a set of new interfaces and classes What do they look like?: allow a program to convert some data formatting; requires multiple inheritance; facilitates the single responsibility principle; facilitates the open/close principle; decouples business logic from conversion logic; allows objects with incompatible interface to interact/collaborate
Iterator method
What are their purpose?:Allows traversal of the elements of a collection without exposing its underlying representation (list, stack, tree, etc.), Extract the traversal behavior of a collection into a separate object called an iterator, An iterator object encapsulates all of the traversal details, such as the current position and how many elements are left till the end, All iterators must implement the same interface, Makes the client code compatible with any collection type or any traversal algorithm as long as there is a proper iterator When do you use them?:Your collection has a complex data structure under the hood, but you want to hide its complexity from clients (either for convenience or security reasons), To reduce duplication of the traversal code across your app, You want your code to be able to traverse different data structures or when types of these structures are unknown beforehand How do they address coupling?: Pros:Single Responsibility Principle: can clean up the client code and the collections by extracting bulky traversal algorithms into separate classes, Open/Closed Principle: can implement new types of collections and iterators and pass them to existing code without breaking anything, Can iterate over the same collection in parallel, Can delay an iteration and continue it when needed Cons: Applying the pattern can be an overkill if your app only works with simple collections, Using an iterator may be less efficient than going through elements of some specialized collections directly What do they look like?: decouples collections from iterators; all iterators must inherit the same interface; does not suffer from code duplication of traversal code; facilitate parallel traversals of the same collection; separates traveral from collections
Singleton pattern
What are their purpose?:Ensures that a class has only one instance, Provides a global access point to this instance, Private constructor so that objects do not create it, Created when retrieving an instance if it does not exist yet When do you use them?: A class in your program should have just a single instance available to all clients You need stricter control over global variables How do they address coupling?: Pros: Can be sure that a class has only a single instance, Gain a global access point to that instance, The singleton object is initialized only when it is requested for the first time Cons: Violates the Single Responsibility Principle: the pattern solves two problems at the time, Can mask bad design (e.g., when the components of the program know too much about each other), Requires special treatment in a multithreaded environment so that multiple threads will not create a singleton object several times, It may be difficult to unit test the client code of the Singleton What do they look like?: typically ensures there is only one instance; provides a global access point its instance; only created by a method to retrieve its instance; facilitates a global access point; can avoid unnecessary creation of global data; ensure only one (or a set number of) instances is created; ensures only one instance is created with global access to that instance
What does it mean for components to be dependent on another
a change in one component potentially forces a change in the other component
Single responsibility principle
a class encapsulates 1 type of information and performs specific tasks; insulates classes from one another
encapsulation
a method that helps increase cohesion of a component
What is sneaker net
a network representing the movement of tape drive
Code smell
a violation of design principles
Quality attributes
availability, interoperability, modifiability, performance, security, testability, usability
Limitation of architecture
awareness of architecture importance
The essence of low coupling is
components should know as little about others as possible
Main program and subroutine architectures
components: main program and subroutines; connectors: function/procedure calls; data element: values passes in/out of subroutines; topology: hierarchal, directed graph; quality attributes: modularity; usage: small programs; limitations: lack of scalability, less attention to data structure, and hard to predict effort to incorporate new requirements; How does it address coupling?: coupled by procedure calls What does it look like?: How do they impact quality?: Relationship between styles?: connections are function calls; facilitates modularity; one limitation is lack of scalability; encapsulated by functional processing;
Object oriented architecture style
components: objects (instances of classes); connectors: method invocation; data elements: arguments to methods; topology : varies. Data integrity. Abstraction.; quality attributes: data integrity. Abstraction; usage: correlation between physical world and program entities, and complex, dynamic data; Limitations: performance and scalability limitations. Potential for high coupling vis constructors. Reuse can be inefficient; How does it address coupling?: coupled by method calls What does it look like?: How do they impact quality?: Relationship between styles?: commonly used when there is a correlation to the physical world; limited performance; lack of scalability; potential lack of understanding; components are encapsulated by state and connected by method calls; Difference between main program and subroutines and object oriented> encapsulate different elements, but couple the same
Three categories of design patterns
creational, behavioral, structural
Best to worst coupling
data, stamp, control, external, common, content
Excessive dependencies on a third-party component are detrimental because
decrease modifiability
Why is there a trade off between performance and availability
error checking and recovery slow down the software
A software architect focuses only on source code
false
The model in the MVC is responsible for application/business logic and the view in the MVC architecture encapsulates user interaction
false
Design decisions can
have a lasting influence on the system
What do we need to know to determine availability?
how the system can fail
Architectural patterns do not
increase design complexity
Testability
is not completely independent of the other quality attributes; suffers from coverage for large state spaces
Quality attributes
non-functional requirements or properties of the software; constrain how the functionality is implemented; cannot all be optimized; represent something we can quantify in a meaningful way; i.e. availability, modifiability, security, testability
Liskov substitution
objects should be replaceable with instances of their subtypes (derived classes) without altering the correctness of that program; a program should still behave correctly should two subtypes of a common type be interchanged
Open-closed principle
open for extension (inheritance/polymorphism), but closed for modification (instance variables protected/private); if a class needs to be extended, try to do it through subclassing to minimize impact on existing clients
Conways law
organizations design system that mimic their structure
Dependency inversion
prefer to depend upon abstractions/interfaces. Do not depend upon concretions/implementations; high-level methods should not depend on lower-level modules; minimizes direct coupling between concrete classes
Shared memory/state architectures
represent multiple components accessing the same memory; all components write to a single memory component; center of design attention is explicitly on these structured, shared repositories, they are well-ordered and carefully managed; connects components via memory and procedure calls; limitations: complexity negatively impacts understandability and not as flexible; blackboard, rule-based
Interface segregation
several specific interfaces (with single responsibility) are better than one general-purpose interface; clients should not need to support methods that are irrelevant to their behavior
Modifiability is achieved by
small modules and low coupling
Software design aims to
speed up development, define concrete solutions
Technical debt
the cost of work caused by picking an easy solution vs a better solution
Why are there multiple architectural styles
they focus on different quality attributes
A system must follow an architectural style to have an architecture
true
T/F Every software has an architecture
true