Software Architecture by Reuse, Composition and Customization Ivano Malavolta
Ivano Malavolta.
Research Fellow at the Computer Science Department of the University of L'Aquila (Italy).
PhD thesis presentation, University of L'Aquila, March 2012.
The full PhD thesis is available here:
http:www.di.univaq.it/malavolta/files/IvanoMalavoltaPhDThesis.pdf
Software Architecture by Reuse, Composition and Customization Ivano Malavolta
Ivano Malavolta.
Research Fellow at the Computer Science Department of the University of L'Aquila (Italy).
PhD thesis presentation, University of L'Aquila, March 2012.
The full PhD thesis is available here:
http:www.di.univaq.it/malavolta/files/IvanoMalavoltaPhDThesis.pdf
Systems Analysis,
Systems Design,
Systems Modelling,
Systems Architecture,
System Development and Testing,
System Maintenance and Evolution,
SDLC example (Cloud Service life cycle)
Software Architecture: views and viewpointsHenry Muccini
This is an introductory lecture to Software Architecture Views and Viewpoints, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
Systems Analysis,
Systems Design,
Systems Modelling,
Systems Architecture,
System Development and Testing,
System Maintenance and Evolution,
SDLC example (Cloud Service life cycle)
Software Architecture: views and viewpointsHenry Muccini
This is an introductory lecture to Software Architecture Views and Viewpoints, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
Industrial Training at Shahjalal Fertilizer Company Limited (SFCL)MdTanvirMahtab2
This presentation is about the working procedure of Shahjalal Fertilizer Company Limited (SFCL). A Govt. owned Company of Bangladesh Chemical Industries Corporation under Ministry of Industries.
Overview of the fundamental roles in Hydropower generation and the components involved in wider Electrical Engineering.
This paper presents the design and construction of hydroelectric dams from the hydrologist’s survey of the valley before construction, all aspects and involved disciplines, fluid dynamics, structural engineering, generation and mains frequency regulation to the very transmission of power through the network in the United Kingdom.
Author: Robbie Edward Sayers
Collaborators and co editors: Charlie Sims and Connor Healey.
(C) 2024 Robbie E. Sayers
Hybrid optimization of pumped hydro system and solar- Engr. Abdul-Azeez.pdffxintegritypublishin
Advancements in technology unveil a myriad of electrical and electronic breakthroughs geared towards efficiently harnessing limited resources to meet human energy demands. The optimization of hybrid solar PV panels and pumped hydro energy supply systems plays a pivotal role in utilizing natural resources effectively. This initiative not only benefits humanity but also fosters environmental sustainability. The study investigated the design optimization of these hybrid systems, focusing on understanding solar radiation patterns, identifying geographical influences on solar radiation, formulating a mathematical model for system optimization, and determining the optimal configuration of PV panels and pumped hydro storage. Through a comparative analysis approach and eight weeks of data collection, the study addressed key research questions related to solar radiation patterns and optimal system design. The findings highlighted regions with heightened solar radiation levels, showcasing substantial potential for power generation and emphasizing the system's efficiency. Optimizing system design significantly boosted power generation, promoted renewable energy utilization, and enhanced energy storage capacity. The study underscored the benefits of optimizing hybrid solar PV panels and pumped hydro energy supply systems for sustainable energy usage. Optimizing the design of solar PV panels and pumped hydro energy supply systems as examined across diverse climatic conditions in a developing country, not only enhances power generation but also improves the integration of renewable energy sources and boosts energy storage capacities, particularly beneficial for less economically prosperous regions. Additionally, the study provides valuable insights for advancing energy research in economically viable areas. Recommendations included conducting site-specific assessments, utilizing advanced modeling tools, implementing regular maintenance protocols, and enhancing communication among system components.
About
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
• Remote control: Parallel or serial interface.
• Compatible with MAFI CCR system.
• Compatible with IDM8000 CCR.
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
• Easy in configuration using DIP switches.
Technical Specifications
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
Key Features
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
• Remote control: Parallel or serial interface
• Compatible with MAFI CCR system
• Copatiable with IDM8000 CCR
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
Application
• Remote control: Parallel or serial interface.
• Compatible with MAFI CCR system.
• Compatible with IDM8000 CCR.
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
• Easy in configuration using DIP switches.
Hierarchical Digital Twin of a Naval Power SystemKerry Sado
A hierarchical digital twin of a Naval DC power system has been developed and experimentally verified. Similar to other state-of-the-art digital twins, this technology creates a digital replica of the physical system executed in real-time or faster, which can modify hardware controls. However, its advantage stems from distributing computational efforts by utilizing a hierarchical structure composed of lower-level digital twin blocks and a higher-level system digital twin. Each digital twin block is associated with a physical subsystem of the hardware and communicates with a singular system digital twin, which creates a system-level response. By extracting information from each level of the hierarchy, power system controls of the hardware were reconfigured autonomously. This hierarchical digital twin development offers several advantages over other digital twins, particularly in the field of naval power systems. The hierarchical structure allows for greater computational efficiency and scalability while the ability to autonomously reconfigure hardware controls offers increased flexibility and responsiveness. The hierarchical decomposition and models utilized were well aligned with the physical twin, as indicated by the maximum deviations between the developed digital twin hierarchy and the hardware.
Immunizing Image Classifiers Against Localized Adversary Attacksgerogepatton
This paper addresses the vulnerability of deep learning models, particularly convolutional neural networks
(CNN)s, to adversarial attacks and presents a proactive training technique designed to counter them. We
introduce a novel volumization algorithm, which transforms 2D images into 3D volumetric representations.
When combined with 3D convolution and deep curriculum learning optimization (CLO), itsignificantly improves
the immunity of models against localized universal attacks by up to 40%. We evaluate our proposed approach
using contemporary CNN architectures and the modified Canadian Institute for Advanced Research (CIFAR-10
and CIFAR-100) and ImageNet Large Scale Visual Recognition Challenge (ILSVRC12) datasets, showcasing
accuracy improvements over previous techniques. The results indicate that the combination of the volumetric
input and curriculum learning holds significant promise for mitigating adversarial attacks without necessitating
adversary training.
Saudi Arabia stands as a titan in the global energy landscape, renowned for its abundant oil and gas resources. It's the largest exporter of petroleum and holds some of the world's most significant reserves. Let's delve into the top 10 oil and gas projects shaping Saudi Arabia's energy future in 2024.
1. Ms. Memoona Sami
Memoona.sami@faculty.muet.edu.pk
SOFTWARE DESIGN AND ARCHITECTURE
LECTURE 4,5
Disclaimer: The contents of this
presentation have been taken from
multiple sources, i.e. Books,
Research articles, Thesis
publications, and websites.
2. The material used in this presentation i.e., pictures/graphs/text, etc. is solely
intended for educational/teaching purpose, offered free of cost to the students for
use under special circumstances of Online Education due to COVID-19 Lockdown
situation and may include copyrighted material - the use of which may not have
been specifically authorised by Copyright Owners. It’s application constitutes Fair
Use of any such copyrighted material as provided in globally accepted law of many
countries. The contents of presentations are intended only for the attendees of the
class being conducted by the presenter.
Fair Use Notice
3. Outlines
Software Architectures
A-7E Avionics System: A Case Study in Utilizing Architectural Structures
Relationship to the Architectural Business life-cycle
Requirements and Qualities and Architectural Approach
The World Wide Web: A Case Study
Relationship to the Architectural Business life-cycle
Requirements and Qualities and Architectural Approach
4. Software Architectures
Architectural structures can be divided into three groups, depending on the broad nature of the elements
they show.
Module structures
Here the elements are modules, which are units of implementation.
There is less emphasis on how the resulting software manifests itself at runtime.
Module structures allow us to answer questions such as
What is the primary functional responsibility assigned to each module?
What other software does it actually use?
What modules are related to other modules by generalization or specialization (i.e., inheritance)
relationships?
5. Software Architectures
Component-and-connector structures
Here the elements are runtime components (which are the principal units of computation) and
connectors (which are the communication vehicles among components).
Component-and-connector structures help answer questions such as
What are the major executing components and how do they interact?
What are the major shared data stores?
Which parts of the system are replicated?
How does data progress through the system?
What parts of the system can run in parallel? How can the system's structure change as it executes?
6. Software Architectures
Allocation structures
Allocation structures show the relationship between the software elements and the elements in one
or more external environments in which the software is created and executed.
They answer questions such as
What processor does each software element execute on?
In what files is each element stored during development, testing, and system building?
What is the assignment of software elements to development teams?
8. Software Architectures
Module-based structures
Decomposition.
The units are modules related to each other by the "is a submodule of " relation, showing how larger
modules are decomposed into smaller ones recursively until they are small enough to be easily
understood.
Modules in this structure represent a common starting point for design, as the architect enumerates
what the units of software will have to do and assigns each item to a module for subsequent (more
detailed) design and eventual implementation.
The decomposition structure provides a large part of the system's modifiability, by ensuring that likely
changes fall within the purview of at most a few small modules.
9. Software Architectures
Module-based structures
Uses
The units of this important but overlooked structure are also modules, or (in circumstances where a
finer grain is warranted) procedures or resources on the interfaces of modules.
The units are related by the uses relation.
One unit uses another if the correctness of the first requires the presence of a correct version (as
opposed to a stub) of the second.
The uses structure is used to engineer systems that can be easily extended to add functionality or
from which useful functional subsets can be easily extracted.
The ability to easily subset a working system allows for incremental development.
10. Software Architectures
Module-based structures
Layered
A system of layers, in which a layer is a coherent set of related functionality.
In a strictly layered structure, layer n may only use the services of layer n– 1.
Layers are often designed as abstractions (virtual machines) that hide implementation specifics below
from the layers above, engendering portability.
11. Software Architectures
Module-based structures
Class, or generalization
The module units in this structure are called classes.
The relation is "inherits-from" or "is-an-instance-of."
This view supports reasoning about collections of similar behaviour or capability (i.e., the classes that
other classes inherit from) and parameterized differences which are captured by subclassing.
The class structure allows us to reason about re-use and the incremental addition of functionality.
12. Software Architectures
Component-and-Connector
Process, or communicating processes
Deals with the dynamic aspects of a running system.
The units here are processes or threads that are connected with each other by communication,
synchronization, and/or exclusion operations.
The relation in this (and in all component-and-connector structures) is attachment, showing how the
components and connectors are hooked together.
The process structure is important in helping to engineer a system's execution performance and
availability.
13. Software Architectures
Component-and-Connector
Concurrency
This component-and-connector structure allows the architect to determine opportunities for
parallelism and the locations where resource contention may occur.
The units are components and the connectors are "logical threads."
A logical thread is a sequence of computation that can be allocated to a separate physical thread later
in the design process.
The concurrency structure is used early in design to identify the requirements for managing the issues
associated with concurrent execution.
14. Software Architectures
Component-and-Connector
Shared data, or repository
This structure comprises components and connectors that create, store, and access persistent data.
If the system is in fact structured around one or more shared data repositories, this structure is a
good one to illuminate.
It shows how data is produced and consumed by runtime software elements, and it can be used to
ensure good performance and data integrity.
15. Software Architectures
Component-and-Connector
Client-server
If the system is built as a group of cooperating clients and servers
The components are the clients and servers, and the connectors are protocols and messages they
share to carry out the system's work.
This is useful for separation of concerns (supporting modifiability), for physical distribution, and for
load balancing (supporting runtime performance).
16. Software Architectures
Allocation
Deployment
The deployment structure shows how software is assigned to hardware-processing and
communication elements.
The elements are software (usually a process from a component-and-connector view), hardware
entities (processors), and communication pathways.
Relations are "allocated-to," showing on which physical units the software elements reside, and
"migrates-to," if the allocation is dynamic.
This view allows an engineer to reason about performance, data integrity, availability, and security. It
is of particular interest in distributed or parallel systems.
17. Software Architectures
Allocation
Implementation
This structure shows how software elements (usually modules) are mapped to the file structure(s) in
the system's development, integration, or configuration control environments.
This is critical for the management of development activities and build processes.
18. Software Architectures
Allocation
Work assignment
This structure assigns responsibility for implementing and integrating the modules to the appropriate
development teams.
Having a work assignment structure as part of the architecture makes it clear that the decision about
who does the work has architectural as well as management implications.
The architect will know the expertise required on each team.
Also, on large multi-sourced distributed development projects, the work assignment structure is the
means for calling out units of functional commonality and assigning them to a single team, rather
than having them implemented by everyone who needs them.
19.
20. Software Architectures
WHICH STRUCTURES TO CHOOSE?
Which ones should an architect work on? Which ones should the architect document? Surely not all of
them.
There is no shortage of advice. In 1995, Philippe Kruchten [Kruchten 95] published a very influential
paper in which he described the concept of architecture comprising separate structures and advised
concentrating on four to validate that the structures were not in conflict with each other and together
did in fact describe a system meeting its requirements. This is known as 4+1 approach (4 view points + 1
redundant view point).
21. Software Architectures
WHICH STRUCTURES TO CHOOSE?
Kruchten's four views follow:
Logical. The elements are "key abstractions," which are manifested in the object-oriented world as
objects or object classes. This is a module view.
Process. This view addresses concurrency and distribution of functionality. It is a component-and-
connector view.
Development. This view shows the organization of software modules, libraries, subsystems, and units
of development. It is an allocation view, mapping software to the development environment.
Physical. This view maps other elements onto processing and communication nodes and is also an
allocation view (which others call the deployment view).
22. A-7E Avionics System: A Case Study in
Utilizing Architectural Structures
The system was constructed beginning in 1977 for the naval aviators who flew the A-7E aircraft
and was paid for by the U.S. Navy.
The developing organization was the software engineering group at the U.S. Naval Research
Laboratory.
The developers were creating the software to test their belief that certain software
engineering strategies (in this case, information hiding and cooperating sequential processes)
were appropriate for high-performance embedded real-time systems.
The architects included one of the authors of this book and one of the leaders in the
development of software engineering principles, but the architects had little experience in the
avionics domain, although they did have access to other avionics systems and to experts in
avionics. There was no compiler available for the target platform.
23. A-7E Avionics System: A Case Study in
Utilizing Architectural Structures
Requirements and Qualities
A-7E Corsair II is a single-seat, carrier-based attack aircraft used by the U.S. Navy throughout the 1960s,
1970s, and 1980s. An earlier version, the A-7C, was among the very first production aircraft in the world
to be equipped with an onboard computer to help the pilot with navigation and "weapon delivery“.
In broad terms, the A-7E software is responsible for reading sensors and updating cockpit displays that
help the pilot drop weapons on a target.
The A-7E software does not actually fly the aircraft, as more modern avionics systems do.
24. A-7E Avionics System: A Case Study in
Utilizing Architectural Structures
Requirements and Qualities
The qualities that the software system was expected to have included real-time performance and
modifiability for expected changes.
Specifically, the performance requirements were stated in terms of updates per second of the A7-E's
displays and weapon delivery calculations.
The modifiability requirements dealt with making changes to the weaponry, the platform, the
symbology on the display, and the addition of new input through the keypad.
25. A-7E Avionics System: A Case Study in
Utilizing Architectural Structures
Architecture for the A-7E Avionics System
The architecture for the A-7E avionics system is centered around three architectural structures
Decomposition, a structure of modules
The unit of the decomposition structure is, of course, the module. A module may be thought of as defining a group of procedures,
some public and some private, plus a set of private data structures. The relation among modules in the decomposition structure is
"is-a-submodule-of" or "shares-a-secret-with."
Uses, a structure of modules
The decomposition structure carries no information about runtime execution of the software; you might make an educated guess
as to how two procedures in different modules interact at runtime, but this information is not in fact in the module decomposition.
Rather, the uses structure supplies the authoritative picture of how the software interacts.
Process, a structure of components and connectors
The software was implemented as a set of cooperating sequential processes that synchronize with each other to cooperatively use
shared resources.
26. A-7E Avionics System: A Case Study in
Utilizing Architectural Structures
Relationship to ABC
27. The World Wide Web: A Case Study in
Utilizing Architectural Structures
Show the elements of the ABC, applied to the WWW initial proposal approved by CERN
management, along with the suitable software architecture for it.
Requirements and Qualities
The system was intended to promote interaction among CERN researchers (the end users) within the
constraints of a heterogeneous and distributed computing environment.
The customer was CERN management, and the developing organization was a lone CERN researcher. The
business case made by Berners-Lee was that the proposed system would increase communication among
CERN staff.
The technical environment was familiar to those in the research community, for which the Internet had been a
mainstay since its introduction in the early 1970s and hypertext systems with hypertext conferences held
regularly to bring researchers together.
The World Wide Web, as conceived and initially implemented at CERN, had several desirable qualities. It was
portable, able to interoperate with other types of computers running the same software, and was scalable and
extensible. The business goals of promoting interaction and allowing heterogeneous computing led to the
quality goals of remote access, interoperability, extensibility, and scalability.
28. The World Wide Web: A Case Study in
Utilizing Architectural Structures
Relationship to ABC