Please enable JavaScript.
Coggle requires JavaScript to display documents.
Architecture Specialization - Coggle Diagram
Architecture Specialization
Design Patterns
Anti-Patterns
Refactoring: make changes to your code so that the external behavior is kept as it is but interbal structure is improved
Small incremental changes to the code structure and testing frequently
Code smells
Comments
too many comments can be a "deodorant" for code smells :smiley: trying to cover up for bad design. They can also get out of sync as code evolves
no comments at all can make the life of new devs hard in understanding what the code is doing
Duplicated code
code that is doing same things with a slight difference. Changes require updates in multiple places
D.R.Y. : programs should be written so that they can perform same tasks but with less code
Long method
if a method is too long, it might indicate that it's doing too much! Maybe responsibilites should be split into separate methods
God class
Classes should have an explicit purpose and do one thing well! Split responsibilities into different classes when appropriate
Data Class
classes that contain only data and no real functionality
Data Clumps
groups of data appearing together in instance variables or methods' parameters that should be treated as a whole but are separate. e.g. int x, int y, int z instead of wrapping them into a Point3D class
Long Parameter List
can be fixed introducing parameter objects!
Divergent Change
it occurs when you have to change a class for many different reasons: a class should only have one reason to change. If not, this might indicate that the class has many different responsibilities
Shotgun surgery
occurs when a change needs to be made to one requirement and it leads to many numerous classes to be touched as well in order to make the change
This can be usually solved by moving methods around: if a change requires to touch many classes, than it might be the case to reconsolidate the relevant methods into one or two classes - be aware of not creating God classes!
Feature Envy
occurs when a method is more interested into the details of a class other than the one it is in - maybe the method should be moved to the other class if closely relates to it
Inappropriate intimacy
occurs when two classes depend on one another via two-way communication. Relevant methods should be factored out so both classes use another class and cycle is removed
Message chains
Calling methods on returned objects makes the code harder to follow and violates the Law of Demeter
Primitive Obsession
Switch statemets
occurs when program is full of switch statements and change to one requires a change to others as well.It might be possible to reduce type-chacking switch statements with polymorphic behavior
Speculative Generality
occurs when implementing some superclass, interface, code which is not needed at the time of coding but may be useful one day
Just in Time Design
: there should be enough design to take the requirements for a particular iteration to a working system
Refused Request
occurs when a subclass inherits something but does not need it. Maybe the unwanted behavior should not be in the superclass or a standalone class is a better design choice
Design Principles
Open/Closed
: classes shouls be open for extension but closed to change
Closed: tested, encapsulated, stable
Open: extendable via inheritance or via abstract / interface definition to enforce polymorphic behavior
Dependency Inversion
High-level module should depend on high-level generalizations and not on low-level details
client classes should depend on an interface or abstract class and NOT reference concrete implementations
References to concrete classes are indirect (through interfaces)
Composing Object
Code reuse should be achieved through aggregation rather than inheritance
Deep inheritance trees can become an issue, especially when classes higher up in the inheritance tree need to be modified
Aggregation and Delegation offer less coupling than inheritance, since attributes or implementation of behaviours are not shared. These can also be seen as a CON, since implementations need to always be provided
Inheritance or composition?
Interface Segregation
A class should not be forced to depend on methods it does not use
A good interface design should create interfaces definitions that are exact in describing the expected and needed behaviors
Principle of Least Knowledge
classes should know and interact with as few other classes as possible, in order to decrease coupling
Law of Demeter: set of rules provifing guidelines on what calls can be done within a method implementation (how classes should interact)
a method should not be allowed to access another method by "reaching through" an object - e.g. no a.getX().getY(). A method can only call methods of his friends and not his friends' friends :smiley:
Software Architecture
Communicating Architecture
Kruchten's 4 + 1
Process View
Focus on how well the software executes and on the processes implemented by the objects in the logical view
sequence and activity diagrams can be used
Development View
Focuses on the hierarchical structure of the software
Considers proframming languages, libraries and toolset
Physical View
Focuses on physical components and how they are deployed
UML deployment diagram
Logical View
UML Class diagrams and State diagrams can be used
Focus on functionalities of the software
Scenarios
outline use cases or tasks needed to be performed by the end users
Component Diagram
Components: independent, encapsulated units of a system
each component provides an interface for other components to interact with
visualizes how pieces of a system interact and the relationships among them
Package Diagram
Package: groups together related software elements under a common namespace
visualizes dependencies between packages, offering a higher level view of the system as compared to class diagrams
importing packages
<<import>> - package elements are imported and available transitively
<<access>> - package elements are imported and available ONLY to the importer
<<merge>> merge packages when two concepts need to come together into one
<uses>> a package requires an other package for its imnplementation
Deployment Diagram
visualizes deployment details of a software system, showing not only code but also libraries, installers, config files
deplyoment target: can be specific and involve particular hardware devices or can be more general and involve operating systems
artifacts: physical result of the development process (like executable or installer)
Activity Diagram
visualizes high level activities (sequence of actions) of a system, giving as representation of the control flow of the system
has always start and end nodes
conditions may alter the sequence of actions
activities can run in parallel via
partitions
. Lifetime of partitions is denoted with swimlanes
Architectural Styles
Language-Based Systems
the programming language used affects the overall architectural style
Object-Oriented
Abstraction, Encapsulation, Decomposition, Generalization
OO Design patterns (creational, structural, behavioral)
system is broken down into
abstract data types
to represent concepts and operations on those concepts in a meaningful way with the right level of encapsulation
Main Program and Subroutine
focused on functions and procedural programming style
Call tree
one entry, one exit per subroutine
well suited for systems centred around computatioons
a subroutine may be affected by changes to shared data made by another subroutine
Repository-based systems
Data-centric software architecture
Database
Data Integrity
Data Persistence
Relational
DBMS, SQL, Transactions
Data Accessor
encapsulates the business rules/logic while reading and modifying the shared state in the DB
PROs: support to data integrity, backup and restoration. Data accessors do not talk directly to each other and new accessors can be added
CONs: heavily relying on a central data component (single point of failure affecting the whole system). Difficult to change existing data schema and changing it will affect accessors as well
Layered Systems
components in one layer only communicate within the layer or with the adjacent layer
Usually separated in Presentation, Logic and Data layer
communication is guided by well-defined interfaces between layers
PROs: loosely coupled design fostering principle of least knowledge
CONs: often top layers must communicate to non-adjacent lower layers, resulting in a "pass-through" overhead or relaxing the adjacent-layer-only communication style, which introduces more tightly coupling in carrying out some business of the system
n-Tier
Tiers usually refer to components on different physical containers
Client/Server with client hosts and server hosts (2-Tiers arch.). Additionally often also a data tier is present (3-Tiers arch.)
Request/Responses exchanged between tiers can be synchrounous or asynchronous
CONs: more tiers => more machines/relationships to manage, a server acts as a single point of failure
PROs: scalable, functionality centralization, computing power centralization, separation of concerns
Interpreter-based Systems
allow users to write Scripts/Macros/Rules (e.g. Excel)
the Interpreter transforms user inputs into an intermediate representation which can be executed
Scripts are often used for
automating common tasks composing complex tasks invoking other commands
Macros records keyboard and mouse inputs to be executed at a later stage
PROs: end users can add/extend functionality of a system, pre-defined functions can be offere by the system but DEVs do not have to implement al combinations of functionalities
Dataflow systems
involves series of transformation on sets of data
Pipes and Filters
Pipes: connectors, Filters: transformation units
PROs: Loose and flexible coupling of components, filters are blackbox and can be reused
CONs: each filter must receive and process which can lead to overhead, filters can get large data, cannot be used in interactive applications
filters order matters!
Implicit Invocation Systems
Event-based architectural style
the fundamental elements in the
system are events (signals, user inputs, messages, etc)
event generators send events and event consumers process these events
generators don't know who will consume the event
communication between functions/executors is mediated by an event bus that detects and distributes the evenst to all
appropriate event consumers
PROs: highest leve possiblel of decoupling
CONs: flow is more opaque, possibility for race conditions to arise on shared data
can be mitigated with use of semaphores to grant access to shared resources
Publish-Subscribe
Components are either publishers or subscribers to messages
Publishers send messages
Subscribers can subscribe/unsubscribe to receive messages
Process Control Systems
Feedback loop
four main components: a sensor, a controller, an actuator, and
the process (what is trying to be controlled)
A proportional controller calculates an error value as the difference between the desired setpoint and a measured process variable and then applies a correction based on proportion (e.g not only open/closed but 30% open)
In a feedback look, the controller logic must run continuously
The frequency, or how often the loop runs, depends on the desired
level of control and the sensitivity of the system
closed loop
Feedforward
occurs in systems with processes in series and requires a good model
of how process response and deals with unknown events
often used in conjunction with feedback loops
More complex problems will have many sensors and ways to control
the process
MAPE-K structure
Architecture in Practice: Trade-offs and Product
Quality Attributes
most systems combine a combination of architectural styles to achieve both functional and non-functzional requirements
a quality attribute is a way to determine whether the system meets a specific requirement in a measurable way
Developer's persperctive
User's perspective
Creating a high-quality system architecture should be methodical
and use a set of rules or guidelines for the design process
recognize and prioritize quality attributes, noting trade-offs
document and keep up-to-date
involve a tech-lead in order to identify potentially challennging implementation issues
inglobe other stakeholders' perspective
have consistent implementations of functionalities and consider reuse
have a set of rules on how resources are used
Analyzing and Evaluating an Architecture
quality attribute scenarios can be used to determine if a system meet requirements set for an attribute
General scenario: used to characterize any system
Concrete scenario: used to characterize a specific system
a stimulus is a condition that will cause the system to respond
an environment is the mode of the system when it receives the stimulus
artifact is the part of the system affected by the stimulus
a response is how the system will behave and the response measure is a metric used to uantify the response
Architecture Trade-off Analysis Method (ATAM)
three different groups of participants
evaluation team: designers, peers, outsiders
project decision makers: stakeholders with the authority to make project decisions (e.g. PM, client, etc.)
architecture stakeholders: stakeholders who want the architecture to address the business needs (e.g. users, developers)
9 steps
1: present the ATAM (context, expectations, procedures). Done by evaluation team
2: present the business drivers (problem and goals). Done by project decision makers
3: present the architecture (current and expected state of architecture)
4: identify architectural approaches (examine architectural patterns)
1 more item...
Product Architecture
Conway's Law: a software tend to take a form that is congrous to the organization that produced it
should be taken into account to plan development teams around the desired architecture and not the other way around
code re-use is important and one means of fostering it is to treat group uf products as product line or product family (synonims)
advantages: save development costs, unified user experience with smaller learning curve for customers, reduced time to market
implementing product lines
Commonalities: features that stay the same in every product
Vartiations: features that vary between products
Product specifics: features that are unique to one and only product
development teams
Domain engineering: development of commonalities and variations (product infrastructure)
Application engineering: actual development of the product - select variation and develop product-specific features as well as testing
reference architecture
responsibility of the domain team
must be designed with respect to the needs of the software
must include the possibility for variation
techniques to realize variations
Adaptation: a component has one interface but offers possibility to change or add on to it
Replacement: there can be a default component whcih might be replaced. A default component might not exist at all and developers must supply it
Extension: a common interface is provided for all variations of the system (add-ons, plugins)
variations might be implemented at build-time, deploy-time or even at runtime when a specific feature is needed
Service Oriented Architecture
Service Oriented Architecture
how to build, use, and combine services
Services are valuable actions that help fulfill a demand
Services are often associated with two roles
the service requester, which is the software requesting the service
the service provider, which fulfills requests
Service principles
Modular and loosely coupled
Composable
Platform and language independent
Self-describing (describing how to interact with it)
Self-describing
UDDI - Universal description discovery and integration
Web Systems Architecture
Services View
HTTP
Javascript
Remote Procedure Calls
Handling heterogeneuous systems communications
In B2B who is responsible for the middleware? Who takes the risk of having an additional attack vector?
this is one of the reasons why we've been transitioning towards web services
the client does not have physical access to the remote procedure it is trying to call
consists of 3 elements
client: making the call
server: answering the call
IDL: interface definition language
the stubs abstract all of the network details
originally meant for sync communication
Object-Brokers
combination of the distributed computing aspects of RPC with object-oriented design principles and approaches
CORBA
Common Object Request Broker Architecture
set of standards by Object Management Group (OMG) to provide an outline of what should be included in an object broker
programming-language-independant
OS-independant
compared to RPC, IDL in CORBA supports inheritance and polymorphism
the client calls a remote object as if it were local
service discovering is semantically complex
Web Services
a functionality that is exposed and accessible via web technologies
based on TCP & HTTP
Service Invocation (SOAP)
provides standardization of communication between service requestors and service providers
based on HTTP + XML
composed of Header and Body sections
headers contain contextual information about the client or routing information
Two types of SOAP messaging
Messaging Patterns
CONs include the fact that XML encoding and decoding adds overhead and does not easily accommodate some data types
SOAP being superseded in many applications by methods that use HTTP more directly, such as RESTful web services
Service description (WSDL)
a standard used to describe the interface of a web service helping SOAP messages find services and understand how to interact with them
written in XML
requestors can read the WSDL and even generat client code from it
must provide
Types: describe the data types that are used
Interfaces: abstract operations definitions
Bindings: how the SOAP message is translated into XML
Services: bring together interfaces and bindings, and assign them to endpoints or ports and are located with URIs.
enables reuse because WSDL descriptions are broken into very fine descriptions which allow for the reuse of parts in different ways.WSDL documents can also import other WSDL documents
major disadvantage: is based on XML so same disadvantages as SOAP
Service Publication and Discovery (UDDI)
Universal Description, Discovery and Integration
standard for discovery and publishing of web services: brings service requesters and providers together!
How it works
UDDI registry is also a service provider itself! Some of the services it offers are adding business or services, or changing information about services
How is data organized
Service Composition (BPEL)
action of coordinating several services and providing an interface
a composite service coordinates the other low-level services
Composing services involves invoking services in a certain order and handling exceptions that may arise
REST Services
Client-Server architecture based on request-response design
communication is resource-based: messages are sent as
representations
of resources
a
resource
can be any pieces of information that are self-contained
Five contraints
Designing REST API
use only nouns for the URIs
GET methods should not alter the state of resources. For modifying the state use POST, PUT, DELETE
use plural nouns for URIs (e.g. /students)
use sub-resources for relationships between resources e.g. /students/3/courses
use HTTP headers to specify input/output formats - Content-Type and Accept
provide users with filtering and paging for collections - pass them in the query string after ?. Also use offset and limit e.g. /courses?offest=10&limit=5
version your API /api/v2
provide proper and meaningful http status codes
Microservices 101
microservice architectural style is a way of composing microservices to produce complex applications
A microservice is a process that is responsible for performing a single independent task.
microservice typically is built to perform a specific business capability
PROs
independency: they can use languages, frameworks, and architectures best suited to the service
easier to scale: can easily be scaled by replication with multiple copies of the micros. handling requests
applications more resilient to failure: if one instance of the microservice fails, the other instances can continue functioning
can be scaled independently: they have loose coupling and can be scaled independently (not all microservices need to scale at the same rate)
modular maintenance: easier to maintain/update
developed quickly, and deployed and maintained by a small, independent team
CONs
Some centralized management of all microservices will be required to coordinate all the microservices
we are talking of a distributed system that is enabled through async communication
Transactions may span multiple microservices - again needs coordination
Testing is complex due to distributed nature of the system
All microservices in the application must be robust to handle failure of any other microservice
style relevant to build applications that can be broken down into a collection of tasks or business capabilities
