Download Software Architecture Models and Styles: A Comprehensive Guide and more Cheat Sheet Software Engineering in PDF only on Docsity!
Please do not share these notes on apps like WhatsApp or Telegram.
The revenue we generate from the ads we show on our website and app
funds our services. The generated revenue helps us prepare new notes
and improve the quality of existing study materials , which are
available on our website and mobile app.
If you don't use our website and app directly, it will hurt our revenue,
and we might not be able to run the services and have to close them.
So, it is a humble request for all to stop sharing the study material we
provide on various apps. Please share the website's URL instead.
UNIT-II
Course Contents: Unit 2 Architectures styles: dataflow architecture, pipes and filters architecture, call. Software architecture models: structural models, framework models, dynamic models, process models.-and return architecture, data- centered architecture, layered architecture, Architecture, Representational state transfer architecture etc. agent based architecture, Micro-services architecture, Reactive
Software Architecture Models:^ ------------------------------------------------------------------------------------------------ Structural Models: Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. Structural models may be static models, which show the structure of the system design. Structural models of a system required during the discussing and designing the system architecture. Architectural design is a particularly important topic in software engineering and UML component, package, and deployment diagrams may all be used when presenting architectural models. Structural model represents the framework for the system and this framework is the place where all other components exist. Structural modelling captures the static features of a system. They consist of the following −
- Classes diagrams
- Objects diagrams
- Deployment diagrams
- Package diagrams
- Composite structure diagram
- Component diagram Structural Modelling: Core Elements-
Figure 2.1 (a): Structural Modelling Core Elements Figure 2.1 (b): Structural Modelling Core Relationships
containing an optional state name list, list the name in boldface, center the name near the top of the box, capitalize the first letter.
Figure 2. 2 : Example & representation of State The following are the important points needs to be remembered about state.
- Ignore attributes that do not affect the behaviour of object.
- The objects in the class have finite number of possible states. Each object can be in one state at a time.
- ABoth events and states depend upon level of abstraction.ll events are ignored in a state, except those for which behaviour is explicitly prescribed. Process Models: A process model is a UML extension of an activity diagram used to model a business process - this diagram shows what goal the process has, the inputs, outputs, events and information that are involved in the process.
Figure 2. 3 : Process Model Architectures Styles: Architectural styles tell, how to organise our code. It’s the highest level of granularity and it specifies layers, high-level modules of the application and how those modules and layers interact with each other, the relations between them. technical environment, specific policies, frameworks or An Architectural Style can be implemented in practices, or can say - The architectural styles that are various ways, with a specific used while designing the software. Dataflow Architecture: In data flow architecture, the whole software system is seen as a series of transformations on consecutive pieces or set of input data, where data and operations are independent of each other. In this approach, the data enters into the system and then flows through the modules one at a time until they are assigned to some final destination (output or a data store).
- Data Flow Architecture is transformed input data by a series of computational or manipulative components into output data. The data can be flow in the graph topology with cycles or in a linear structure without cycles.
- It is a part of Von-Neumann model of computation which consists of a single program counter, sequential execution and control flow which determines fetch, execution, commit order.
- Its main objective is to achieve the qualities of reuse and modifiability. And suitable for applications that involve a well-defined series of independent data transformations or computations on orderly defined input and output such as compilers and business data processing applications. There are three types of execution sequences between modules−
- Batch sequentialPipe and filter or non-sequential pipeline mode
- Process control 1. Batch Sequential:
- Batch sequential compilation was regarded as a sequential process in 1970. It is a classical data processing model.
- In Batch sequential, separate programs are executed in order and the data is passed as an aggregate from one program to the next.
- It provides simpler divisions on subsystems and each subsystem can be an independent program working on input data and produces output data.
- The main disadvantage of batch sequential architecture is that, it does not provide concurrency and interactive interface. It provides high latency and low throughput.
Figure 2. 4 : Flow of Batch Sequential Architecture The above diagram shows the flow of batch sequential architecture. It provides simpler divisions on subsystems and each subsystem can be an independent program working on input data and produces output data. Advantages
- Provides simpler divisions on subsystems. Disadvantages^ •^ Each subsystem can be an independent program working on input data and producing output data.
- Provides high latency and low throughput.
- Does not provide concurrency and interactive interface.
- External control is required for implementation. 2. This approach lays emphasis on the incremental transformation of data by successive component. In this Pipe and Filter Architecture: approach, the flow of data is driven by data and the whole system is decomposed into components of data source, filters, pipes, and data sinks. The connections between modules are data stream which is first-in/first- out buffer that can be stream of bytes, characters, or any other type of such kind. The main feature of this architecture is its Pipe represents- concurrent and incremented execution.
- Pipe is a connector which passes the data from one filter to the next.
- Pipe is a directional stream of data implemented by a data buffer to store all data, until the next filter has time to process it.
- It transfers the data from one data source to one data sink.
- Pipes are the stateless data stream.
- Controlled Variable − Controlled Variable provides values for the underlying system and should be measured by sensors. For example, speed in cruise control system.
- Input Variable − Measures an input to the process. For example, temperature of return air in temperature control system
- Manipulated Variable − Manipulated Variable value is adjusted or changed by the controller.
- Process Definition − It includes mechanisms for manipulating some process variables.
- Sensor − Obtains values of process variables pertinent to control and can be used as a feedback reference to recalculate manipulated variables.
- Set Point − It is the desired value for a controlled variable.
- Control Algorithm − It is used for deciding how to manipulate process variables. Application Areas: Process control architecture is suitable in the following domains −
- Embedded system software design, where the system is manipulated by process control variable data.
- Applications, which aim is to maintain specified properties of the outputs of the process at given reference values.
- Applicable for car-cruise control and building temperature control systems.
- Real-time system software to control automobile anti-lock brakes, nuclear power plants, etc. Call-and Return Architecture: A call and return architecture enables software designers to achieve a program structure, which can be easily modified. This style consists of the following two substyles.
- Main program/subprogram architecture: In this, function is decomposed into a control hierarchy where the main program invokes a number of program components, which in turn may invoke other components.
- Remote procedure call architecture: In this, components of the main or subprogram architecture are distributed over a network across multiple computers. Call and Return (Functional):
- Routines correspond to units of the task to be performed.
- Combined through control structures.
- Routines known through interfaces (argument list) Advantages:
- Architecture based on well-identified parts of the task.
- Change implementation of routine without affecting clients.
- Reuse of individual operations.
Disadvantages:
- Must know which exact routine to change.
- Hides role of data structure.
- Bad support for extendibility. Call and Return (Object-Oriented):
- A class describes a type of resource and all accesses to it (encapsulation).
- Representation hidden from client classes. Advantages:
- Change implementation without affecting clients.
- Can break problems into interacting agents.
- Can distribute across multiple machines or networks.
Disadvantages:
- Objects must know their interaction partners; when partner changes, clients must change.
- Side effects: if A uses B and C uses B, then C’s effects on B can be unexpected to A.
Data-Centered Architecture : Data Centered Architecture is also known as Database Centric Architecture. It is a layered process which provides architectural guidelines in data center development. This architecture is the physical and logical layout of the resources and equipment within a data center facility.
- In data-centred architecture, the data is centralized and accessed frequently by other components, which modify data.
- It consists of different components that communicate through shared data repositories.
- The components access a shared data structure and are relatively independent, in that, they interact only through the data store.
- This architecture specifies how these devices will be interconnected and how physical and logical security workflows are arranged.
Figure 2. 6 : Data-Centered Architecture The above figure shows the architecture of Data-centred Architecture. In this architecture, the data is centralized and accessed frequently by other components which modify the data. The main purpose of data centred architecture is to achieve integrity of data. There are two types of Components: Central Data and Data Accessor Central Data:
- Central data provides permanent data storage.
- Central data represents the current state. Data Accessor:
- Data accessor is a collection of independent components.
- It operates on the central data store, performs computations and displays the results.
- Communication can be done between the data accessors is only through the data store. There are two categories which differentiates the architecture flow of control: Repository Architecture Style and Blackboard Architecture Style. Repository Architecture Style:
- Repository architecture is a collection of independent components which operate on central data structure. It includes central data structure.
- Information System, Programming Environments, Graphical Editors, AI Knowledge Bases, Reverse Engineering System are the examples of Repository Architecture Style.
The most well-known examples of the data- centered architecture is a database architecture, in which the common database schema is created with data definition protocol – for example, a set of related tables with fields and data types in an RDBMS. Another example of data-centered architectures is the web architecture which has a common data schema follows hypermedia data model (i.e. meta-structure of theand processes Web) and communicate through the use of shared web-based data services.
- It manages the task and checks the work state. Advantages:
- Blackboard architecture style provides concurrency which allows knowledge sources to work in parallel.
- This architecture supports experimentation for hypotheses and reusability of knowledge source components.
- It allows blackboard applications to adapt to changing requirements.
- It allows the new knowledge sources which can be developed and applied to the system without affecting on the existing system. Disadvantages:
- Blackboard architecture style has the provision of tight dependency between the blackboard and knowledge source.
- It has difficulty in deciding for reasoning termination.
- It has an issue in synchronization of multiple agents. Layered Architecture: A number of different layers are defined with each layer performing a well-defined set of operations. Each layer will do some operations that becomes closer to machine instruction set progressively.
Figure 2. 9 : Layered architecture Agent Based Architecture: Now a days an increasing number of software projects are revised, restructured, and reconstructed in terms of software agents. Agent based software development a new way of analysis and synthesis of software system. Here software agents are new experimental embodiment of computer program.
- An agent in computer science refers to a software or other computational entities which has intelligence characteristics and can decide, and act based on its intelligence and other information taken from its environment. An agent usually acts on behalf of computer user.
- An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators. Application of Agent based System:
- An agent become a part of distributed system, as a processing node.
- Agents for distributed sensing, and information retrieval and management.
- Agents for e-commerce, Agents for human-computer interfaces.
- Agents for virtual environments, Agents for social simulation.
- Agents for industrial systems management.
- At the outer layer, components will receive the user interface operations and at the inner layers, components will perform the operating system interfacing (communication and coordination with OS).
- Intermediate layers to utility services and application software functions.
- The components of outer layer manage the user interface operations.
- Components execute the operating system interfacing at the inner layer. The inner layers are application layer, utility layer and the core layer.
Micro-services Architecture: "Microservices" - yet another new term on the crowded streets of software architecture. The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms.
- The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.
- A microservices architecture consists of a collection of small, autonomous services. Each service is self- contained and should implement a single business capability.
- Microservices are small, independent, and loosely coupled. A single small team of developers can write and maintain a service.
- Each service is a separate codebase, which can be managed by a small development team.
- Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire application. Benefits:
- Agility. Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. You can update a service without redeploying the entire application and roll back an update if something goes wrong. In many traditional applications, if a bug is found in one part of the application, it can block the entire release process.
- Small, focused teams. A microservice should be small enough that a single feature team can build, test, and deploy it. Small team sizes promote greater agility. Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.
- Small code base. In a monolithic application, there is a tendency over time for code dependencies to become tangled, adding a new feature requires touching code in a lot of places. By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.
- Fault isolation. If an individual microservice becomes unavailable, it won't disrupt the entire application.
- Scalability. Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application.
- Data isolation. It is much easier to perform schema updates, because only a single microservice is affected. Challenges: The benefits of microservices don't come for free. Here are some of the challenges to consider before embarking on a microservices architecture.
- Complexity: A microservices application has more moving parts than the equivalent monolithic application. Each service is simpler, but the entire system as a whole is more complex.
- Development and testing: Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. Existing tools are not always designed to work with service dependencies.
- Network congestion and latency: The use of many small, granular services can result in more interservice communication. Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem.
- Data integrity: With each microservice responsible for its own data persistence. As a result, data consistency can be a challenge. Embrace eventual consistency where possible.
- Versioning: Updates to a service must not break services that depend on it. Multiple services could be updated at any given time, so design carefully.
- client who requests for the resources.
- server who has the resources. Architectural Constraints of RESTful API: There are six architectural constraints which makes any web service are listed below:
- Client-server
- Stateless
- Cacheable
- Uniform interface
- Layered system
- Code on demand (optional) Client Server: Separation of concerns is the principle behind the client-server constraints. Stateless: Statelessness means communication must be stateless in nature as in the client stateless server style, i.e. each request from client to server must contain all of the information necessary to understand the request and cannot take advantage of any stored context on the server. Cacheable: In order to improve network efficiency, cache constraints are added to the REST style. Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests. Uniform interface: The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components. Layered system: The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting. Code on demand: The final addition to our constraint set for REST comes from the code-on-demand style. REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility. Steps Creating a RESTful service:
- Define the domain and data.
- Organize the data into groups.
- Create URI to resource mapping.
- Define the representations to the client (XML, HTML, CSS, …).
- Link data across resources (connectedness or hypermedia).
- Create use cases to map events/usage.
- Plan for things going wrong.
Thank you for using our services. Please support us so that we can
improve further and help more people.
https://www.rgpvnotes.in/support-us
If you have questions or doubts, contact us on
WhatsApp at +91-8989595022 or by email at hey@rgpvnotes.in.
For frequent updates, you can follow us on
Instagram: https://www.instagram.com/rgpvnotes.in/.
