The document describes key components of software design including data design, architectural design, interface design, and procedural design. It discusses the goals of the design process which are to implement requirements, create an understandable guide for code generation and testing, and address implementation from data, functional, and behavioral perspectives. The document also covers concepts like abstraction, refinement, modularity, program structure, data structures, software procedures, information hiding, and cohesion and coupling.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
This is an introductory lecture to Software Architecture Design Decisions, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
The given presentation was presented at SAPPHIRE 2017 in Orlando, FL on May 18, 2017. It highlights latest research results focusing on user-centered in-memory applications for precision medicine.
This presentation shows application examples of the analyzegenomes.com service for precision medicine. It was presented at 2016 HIMSS conference in Las Vegas, NV
This is an introductory lecture to Software Architecture Design Decisions, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
The given presentation was presented at SAPPHIRE 2017 in Orlando, FL on May 18, 2017. It highlights latest research results focusing on user-centered in-memory applications for precision medicine.
This presentation shows application examples of the analyzegenomes.com service for precision medicine. It was presented at 2016 HIMSS conference in Las Vegas, NV
This is the presentation as shown on the 2015 Future Convention in Frankfurt, Germany on Nov 23, 2015. It shows latest research results in the field of precision medicine using the Drug Response Analysis app of the http://we.analyzegenomes.com platform.
5 selective types of architecture design process, what are the stages in each types and what does it have in common?
and using diagrammatic approach to elaborate these founding
For additional summary of the slides:
http://asasku.blogspot.com/2009/03/design-process-part-2.html
Presentation covers all aspects about Software Designing that are followed by Software Engineering Industries. Readers can do detailed study about the Software Design Concepts like (Abstraction, Architecture, Patterns, Modularity, Information Hiding, Refinement, Functional Dependence, Cohesion, Coupling & Refactoring) plus Design Process.
Later then Design Principles are there to understand with Architectural Design, Architectural Styles, Data Centered Architecture, Data Flow Architecture, Call & Return Architecture, Object Oriented Architecture, Layered Architecture with other architectures are named at end of it.
Later then, Component Level Design is discussed. Then after UI Design & Rules of it, UI Design Models, Web Application Design, WebApp Interface Design are discussed at the end.
Comment back if you have any query about it.
Software design is the process of envisioning and defining software solutions to one or more sets of problems. One of the main components of software design is the software requirements analysis (SRA).
Software design is a process through which requirements are translated into a ― blueprint for constructing the software.
Initially, the blueprint shows how the software will look and what kind of data or components will be required to in making it.
The software is divided into separately named components, often called ‘MODULES’, that are used to detect problems at ease.
This follows the "DIVIDE AND CONQUER" conclusion. It's easier to solve a complex problem when you break it into manageable pieces.
When a software program is modularized, there are measures by which the quality of a design of modules and their interaction among them can be measured. These measures are called coupling and cohesion.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Generating a custom Ruby SDK for your web service or Rails API using Smithy
Design concepts and principles
1.
2. Components of a design model :
Data Design
◦ Transforms information domain model into data structures
required to implement software
Architectural Design
◦ Defines relationship among the major structural elements of a
software
Interface Design
◦ Describes how the software communicates with systems that
interact with it and with humans.
Procedural Design
◦ Transforms structural elements of the architecture into a
procedural description of software components
3. Software Design -- An iterative process transforming
requirements into a “blueprint” for constructing the software.
Goals of the design process:
3. The design must implement all of the explicit requirements
contained in the analysis model and it must accommodate all
of the implicit requirements desired by the customer.
4. The design must be a readable, understandable guide for
those who generate code and for those who test and
subsequently support the software.
5. The design should address the data, functional and
behavioral domains from an implementation perspective
4.
5. Wasserman: “Abstraction permits one to
concentrate on a problem at some level of
abstraction without regard to low level detail.
At the highest level of abstraction a solution
is stated in broad terms using the language
of the problem environment.
At lower level, a procedural orientation is
taken.
At the lowest level of abstraction the solution
is stated in a manner that can be directly
implemented.
6. Types of abstraction :
1. Procedural Abstraction :
A named sequence of instructions that has a specific &
limited function
Eg: Word OPEN for a door
2. Data Abstraction :
A named collection of data that describes a data object.
Data abstraction for door would be a set of attributes
that describes the door
(e.g. door type, swing direction, weight, dimension)
7. 2. Refinement
Process of elaboration.
Start with the statement of function defined at the
abstract level, decompose the statement of
function in a stepwise fashion until programming
language statements are reached.
8.
9. In this concept, software is divided into
separately named and addressable
components called modules
Follows “divide and conquer” concept, a
complex problem is broken down into several
manageable pieces
Let p1 and p2 be two problems.
Let E1 and E2 be the effort required to solve
them --
If C(p1)>C(p2)
Hence E(p1)>E(p2)
10. Now--
Complexity of a problem that combines p1 and
p2 is greater than complexity when each
problem is consider
C(p1+p2) > C(p1)+C(p2),
Hence
E(p1+p2) > E(p1)+E(p2)
It is easier to solve a complex problem when
you break it into manageable pieces
11.
12. 5 criteria to evaluate a design method with respect to
its modularity-----
Modular understandability
module should be understandable as a standalone unit
(no need to refer to other modules)
Modular continuity
If small changes to the system requirements result in
changes to individual modules, rather than system
wide
changes, the impact of side effects will be minimized
Modular protection
If an error occurs within a module then those errors
are localized and not spread to other modules.
13. Modular Composability
Design method should enable reuse of existing
components.
Modular Decomposability
Complexity of the overall problem can be
reduced if the design method provides a
systematic mechanism to decompose a
problem into sub problems
14.
15. Also called program structure
Represent the organization of program components.
Does not represent procedural aspects of software such as
decisions, repetitions etc.
Depth –No. of levels of control (distance between the top
and bottom modules in program control structure)
Width- Span of control.
Fan-out -no. of modules that are directly controlled by
another module
Fan-in - how many modules directly control a given
module
Super ordinate -module that control another module
Subordinate - module controlled by another
16. Visibility -set of program components that may be
called or used as data by a given component
Connectivity – A module that directly causes another
module to begin execution is connected to it.
17. Software architecture is the hierarchical structure of program
components (modules), the manner in which these
components interact and the structure of data that are used
by the components.
A set of properties should be specified as part of an
architectural design:
Structural properties. This aspect of the architectural
design representation defines the components of a system
(e.g., modules, objects) and the manner in which those
components are packaged and interact with one another.
Extra-functional properties. The architectural design
description should address how the design architecture
achieves requirements for performance, reliability, security,
adaptability, and other system characteristics.
Families of related systems. the design should have the
ability to reuse architectural building blocks.
18. Data structure is a representation of the
logical relationship among individual
elements of data.
• Scalar item –
A single element of information that may be
addressed by an identifier .
• Scalar item organized as a list- array
• Data structure that organizes non-contiguous
scalar items-linked list
20. Information (data and procedure) contained
within a module should be inaccessible to
other modules that have no need for such
information.
Hiding defines and enforces access
constraints to both procedural detail within a
module and any local data structure used by
the module.
21. If the architectural style of a system is
hierarchical program structure can be
partitioned -----
3. Horizontal partitioning
4. Vertical partitioning
22. Horizontal partitioning
Separate branches can be defined for each major function
Eg : 3 partitions
1. Input
2. Data Transformation
3. Output
Advantages
◦ Easier to test
◦ Easier to maintain
◦ Propagation of fewer side effects
◦ Easier to add new features
23. Vertical Partitioning
◦ Control and work modules are distributed top down
◦ Top level modules perform control functions
◦ Lower modules perform computations (input
processing and output
26. Functional independence is achieved by
developing modules with “single minded”
function and an aversion to excessive interaction
with other modules.
Measured using 2 qualitative criteria:
5. Cohesion : Measure of the relative strength of a
module.
6. Coupling : Measure of the relative
interdependence among modules.
27. • Strength of relation of elements within a module
• Element- Group of instructions or a data definition.
• Strive for high cohesion
Different types of cohesion :
o Functional Cohesion (Highest):
A functionally cohesive module contains elements that
all contribute to the execution of one and only one
problem-related task.
Examples of functionally cohesive modules are
Compute cosine of an angle
Calculate net employee salary
28. 2. Sequential Cohesion :
A sequentially cohesive module is one whose
elements are involved in activities such that
output data from one activity serves as input
data to the next.
Eg: Module read and validate customer record
Read record
Validate customer record
Here output of one activity is input to the
second
29. 3. Communicational cohesion
A communicationally cohesive module is one whose elements
contribute to activities that use the same input or output data.
Suppose we wish to find out some facts about a book
For instance, we may wish to
FIND TITLE OF BOOK
FIND PRICE OF BOOK
FIND PUBLISHER OF BOOK
FIND AUTHOR OF BOOK
These four activities are related because they all work
on the same input data, the book, which makes the
“module” communicationally cohesive.
30. Eg: module which produces employee salary
report and calculates average salary
Produce
employee
salary
report
Employee salary
report details
Employee salary Calculate
average
table salary Average salary
31. 4. Procedural Cohesion
A procedurally cohesive module is one whose elements are
involved in different and possibly unrelated activities in which
control flows from each activity to the next.
A piece of coding ties the activities together
Eg:
Module that averages two completely unrelated tables, TABLE-
A
and TABLE-B, which both just happen to have 100 elements
each.
32. module compute table-A-avg and table-B-avg
uses table-A, table-B
returns table-A-avg, table-B-avg
table-A-total : = 0
table-B-total : = 0
for i = i to 100
add table-A (i) to table-A-total
add table-B (i) to table-B-total
endfor
table-A-avg : = table-A-total/100
table-B-avg : = table-B-total/100
endmodule
33. 5. Temporal Cohesion
A temporally cohesive module is one whose elements are
involved in activities that are related in time.
A module INITIALIZE initializes many different functions in a
mighty sweep, causing it to be broadly related to several other
modules in the system.
module initialize
updates a-counter, b-counter, items table,
totals table, switch-a, switch-b
rewind tape-a
set a-counter to 0
rewind tape-b
set b-counter to 0
clear items table
clear totals table
set switch-a to off
set switch-b to on
endmodule
34. 6. Logical Cohesion
A logically cohesive module is one whose elements contribute
to activities of the same general category in which the activity
or activities to be executed are selected from outside the
module.
A logically cohesive module contains a number of activities of
the same general kind.
To use the module, we pick out just the piece(s) we need.
35. Eg. A module maintain employee master file
Uses input flag/* to choose which function*/
If input flag =1
{Add a new record to master file}
If input flag =2
{delete an employee record }
If input flag=3
{edit employee record }
-
-
Endmodule
36. 7. Coincidental Cohesion (Lowest)
A coincidentally cohesive module is one whose elements
contribute to activities with no meaningful relationship to one
another.
Eg. When a large program id modularized by arbitrarily
segmenting the program into several small modules.
38. Measure of interconnection among modules
in a software structure
Strive for lowest coupling possible.
39. Types of coupling
1. Data coupling (Most desirable)
Two modules are data coupled, if they communicate through
parameters where each parameter is an elementary piece of
data.
e.g. an integer, a float, a character, etc. This data item should
be problem related and not be used for control purpose.
2. Stamp Coupling
Two modules are said to be stamp coupled if a data structure is
passed as parameter but the called module operates on some
but not all of the individual components of the data structure.
40. 3. Control Coupling
Two modules are said to be control coupled if one module
passes a control element to the other module.
This control element affects /controls the internal logic of the
called module
Eg: flags
Module 1
flag
flag
Module 2
A B
C
41. 4. Common Coupling
Takes place when a number of modules access
a data item in a global data area.
Modules c, g and k exhibit common coupling
42. 5. Content coupling (Least desirable)
Two modules are said to be content coupled if one module
branches into another module or modifies data within another.
Eg:
int func1(int a)
{ printf(“func1”);
a+=2;
goto F2A;
return a;
}
void func2(void)
{ printf(“func2”);
F2A : printf(“At F2A”)
}
43. Evaluate 1st iteration to reduce coupling & improve cohesion
Minimize structures with high fan-out
Keep scope of effect of a module within scope of control of
that module
44. Evaluate interfaces to reduce complexity
Define modules with predictable function
A module is predictable when it can be
treated as a black box.
Strive for controlled entry -- no jumps into
the middle of things
45. The design process should not suffer from ‘tunnel vision’
A good designer should consider alternative approaches.
The design should be traceable to the analysis model
The design should not reinvent the wheel
Time is short and resources are limited! Hence use well tested and
reusable s/w components
The design should ‘minimize the intellectual distance” between the
S/W and the problem as it exists in the real world
That is, the structure of the software design should (whenever
possible) mimic the structure of the problem domain.
The design should exhibit uniformity & integration
A design is uniform if it appears that one person developed the
whole thing.
46. The design should be structured to accommodate
change
Upcoming modifications and improvements should not
lead to drastic changes or redesign of software
The design should be structured to degrade
gently, even when aberrant data, events, or operating
conditions are encountered
Use message/progress bars whenever possible
Design is not coding, coding is not design
The design should be assessed for quality as it is being
created, not after the fact
The design should be reviewed to minimize
conceptual (semantic) errors