kbfsdgfygdfhbdc dshcgdgfewhfuwefdjcbvhbvn nvbhdvdvdbvhbdfvdvfhkdbvhdfbhkdfbfk

1. UNIT III
PART-II

2. UNIT - 3 Software Design
Definition
Software design is the process by which an agent creates a specification of a software
artifact, intended to accomplish goals, using a set of primitive components and subject
to constraints.
(or)
Software design is a mechanism to transform user requirements into some suitable
form, which helps the programmer in software coding and implementation.
 It deals with representing the client's requirement, as described in SRS (Software
Requirement Specification) document, into a form, i.e., easily implementable using
programming language.
 A software product is considered as a collection of software modules.
 A module is a part of a software product which has data and functions together and
an interface with other modules to produce some outcome.
 For Example: A banking S/W system consists of various modules like ATM
interface, online transaction, loan management, deposit, and so on.
 Each of these module interacts with other modules to accomplish the banking

3.  For assessing user requirements, an SRS (Software Requirement Specification)
document is created whereas for coding and implementation, there is a need of
more specific and detailed requirements in software terms.
 The output of this process can directly be used into implementation in
programming languages.
 Software design is a SDLC (Software Design Life Cycle) step, which moves the
concentration from problem domain to solution domain.
 It tries to specify how to fulfill the requirements mentioned in SRS

4. Software Design Process
It exists between Requirements engineering and programming. Software design yields three
levels of results:
Architectural Design –
 The architectural design is the highest abstract version of the system. It identifies the
software as a system with many components interacting with each other.
 At this level, the designers get the idea of proposed solution domain.
 The external design considers the architectural aspects related to business, technology,
major data stores, and structure of the product.

5. High Level Design (Physical Design) –
The high-level design breaks the ‘single entity multiple component’ concept of
architectural design(conceptual view) into less-abstracted view of sub-systems and
modules and depicts their interaction with each other.
High-level design focuses on how the system along with all of its components can be
implemented in forms of modules. It recognizes modular structure of each sub-
system and their relation and interaction among each other.
Detailed Design
Detailed design deals with the implementation part of what is seen as a system and
its sub-systems in the previous two designs. It is more detailed towards modules and
their implementations. It defines logical structure of each module and their interfaces
to communicate with other modules.

6. Characteristics of good software design:
The quality of a software design can be characterized by the application domain.
For example real time software will focus more on efficiency and reliability issues whereas
academic automation s/w will concentrate on understandability and usability issues. A designer
always tries to produce a good design. The desirable characteristics that a good s/w design
should have are as follows:
1. Correctness: A design is said to be correct if it is correctly produced according to the stated
requirements of customers in the SRS. It should fulfill all the functional features, satisfy
constraints, and follow the guidelines. A correct design is more likely to produce accurate
outcomes.
2. Efficiency: It is concerned with performance related issues; for example, optimal utilization
of resources. The design should consume less memory and processor time. Software design
and its implementation should be as fast as requires by the user.
3. Understandability: It should be easy to understand what the module is, how it is connected to
other modules, what data structure is used, and its flow of information. Documentation of a
design can also make it more understandable. An understandable design will make the
maintenance and implementation tasks easier.

7. 4. Maintainability: A difficult and complex design would take a larger time to be
understood and modified. Therefore, the design should be easy to be modified,
should include new features, should not have unnecessary parts, and it should be
easy to migrate it onto another platform.
5. Simplicity: A simple design will improve understandability and
maintainability. Introducing a simple design is rare because a design follows
certain steps and criteria. Still designers always think to “keep it simple” rather
than “make it complex”.
6. Completeness: It means that the design includes all the specifications of the
SRS. A complete design may not necessarily be correct. But a correct design can
be complete.
7. Verifiability: The design should be able to be verified against the requirements
documents and programs. Interfaces between the modules are necessary for
integration and function prototyping.
8. Portability: The external design mainly focuses on the interface, business, and
technology architectures. These architectures must be able to move a design to
another environment. This may be required when the system is to be migrated
onto different platforms.

8. 9. Modularity: A modular design will be easy to understand and modify. Once a modular
system is designed, it allows easy development and repairing of required modules
independently.
10. Reliability: This factor depends on the measurement of completeness, consistency, and
robustness in the software design. Nowadays, most people depend and rely on S/W to
always work and yield correct results. If there is any unreliable part of software, it can
cause major dangers.
11. Reusability: The software design should be standard and generic so that it can be used
for mass production of quality products with small cycle time and reduced cost. The object
code, classes, design patterns, packages, etc., are the reusable parts of software.

9. Design Concepts:
Every software process is characterized by basic concepts along with certain practices
or methods. Methods represent the manner through which the concepts are applied. As
new technology replaces older technology, many changes occur in the methods that
are used to apply the concepts for the development of software.
Each helps you answer the following questions:
What criteria can be used to partition software into individual components?
 How is function or data structure detail separated from a conceptual representation
of the software?
 What uniform criteria define the technical quality of a software design?

10. 1. Abstraction
 Abstraction is the act of representing essential features without including the
background details or explanations. the abstraction is used to reduce complexity
and allow efficient design and implementation of complex software systems.
 As a process, it refers to a mechanism of hiding irrelevant details and representing
only the essential features of an item so that one can focus on important things at a
time.
 Many levels of abstraction can be posed. At the highest level of abstraction, a
solution is stated in broad terms using the language of the problem environment. At
lower levels of abstraction, a more detailed description of the solution is provided.
 As different levels of abstraction are developed, you work to create both procedural
and data abstractions.
 A procedural abstraction :refers to a sequence of instructions that have a specific
and limited function.The name of a procedural abstraction implies these functions,
but specific details are suppressed.
 A data abstraction: is a named collection of data that describes a data object.
Architecture

11. 2.Architecture
Structure organization of program components (modules) and their interconnection
Architecture Models
(a) Structural Models-- An organized collection of program components
(b) Framework Models-- Represents the design in more abstract way
(c) Dynamic Models-- Represents the behavioral aspects indicating changes as a
function of external events
(d)Process Models-- Focus on the design of the business or technical process

12. 3. Patterns
A pattern provides a description of the solution to a recurring design problem of some specific
domain in such a way that the solution can be used again and again.
The objective of each pattern is to provide an insight to a designer who can determine the
following.
1. Whether the pattern can be reused
2. Whether the pattern is applicable to the current project
3. Whether the pattern can be used to develop a similar but functionally or structurally
different design pattern.

13. Types of Design Patterns
Software engineer can use the design pattern during the entire software design process.
When the analysis model is developed, the designer can examine the problem
abstraction to determine whether it complies with one or more description at different
levels of the following types of design patterns.
3.1 Architectural patterns:
 These patterns are high-level strategies that refer to the overall structure and organization
of a software system. That is, they define the elements of a software system such as
subsystems, components, classes, etc.
 In addition, they also indicate the relationship between the elements along with the rules
and guidelines for specifying these relationships.
 Note that architectural patterns are often considered equivalent to software architecture.

14. 3.2. Design patterns:
These patterns are medium-level strategies that are used to solve design problems.
They provide a means for the refinement of the elements (as defined by
architectural pattern) of a software system or the relationship among them.
Specific design elements such as relationship among components or mechanisms
that affect component-to component interaction are addressed by design patterns.
 Note that design patterns are often considered equivalent to software components.
3.3. Idioms:
These patterns are low-level patterns, which are programming-language specific.
They describe the implementation of a software component, the method used for
interaction among software components, etc., in a specific programming language.
Note that idioms are often termed as coding patterns.

15. Modularity:
Modularization is the process of dividing a software system into multiple independent
modules where each module works independently.
Modularity is achieved by dividing the software into uniquely named and addressable
components, which are also known as modules.
A complex system (large program) is partitioned into a set of discrete modules in such a
way that each module can be developed independent of other modules.
After developing the modules, they are integrated together to meet the software
requirements. Note that larger the number of modules a system is divided into, greater will
be the effort required to integrate the modules.

16. Modularizing a design helps to plan the development in a more effective manner,
accommodate changes easily, conduct testing and debugging effectively and efficiently, and
conducts maintenance work without adversely affecting the functioning of the software.
Modular Design:
 A modular design focuses on minimizing the interconnection b/w modules. In a modular
design, several independent and executable modules are composed together to construct
an executable application program.
 The programming language support, interfaces, and the information hiding principles
ensure modular system design.
 There are various modularization criterions to measure the modularity of a system. The
most common criterions are functional independency; levels of abstraction; information
hiding; functional diagrams, such as DFD, modular programming languages, coupling,
and cohesion.
 An effective modular system has low coupling and high cohesion.
 Coupling and Cohesion are two key concepts in software engineering that are used to
measure the quality of a software system’s design.

17. 1. Coupling:
 Coupling between two modules is a measure of the degree of interdependence or
interaction between the two modules.
 Good software will have low coupling.
 A module having high cohesion and low coupling is said to be functionally
independent of other modules. If two modules interchange large amounts of data, then they
are highly interdependent.
 The degree of coupling between two modules depends on their interface complexity.
 The interface complexity is basically determined by the number of types of parameters
that are interchanged while invoking the functions of the module.
 Module coupling can be Tightly or Loosely coupled based on the dependencies.

18. Classification of Coupling:
Even if there are no techniques to precisely and quantitatively estimate the coupling
between two modules, classification of the different types of coupling will help to
quantitatively estimate the degree of coupling between two modules.
Six types of coupling can occur between any two modules. This is shown in the figure
given below:

19. i) Data coupling: Two modules are data coupled, if they communicate through a
parameter. An example is an elementary data item passed as a parameter between
two modules, e.g. an integer, a float, a character, etc. This data item should be
problem related and not used for the control purpose.
ii) Stamp coupling: Two modules are stamp coupled, if they communicate using a
composite data item such as a record in PASCAL or a structure in C.
iii) Control coupling: Control coupling exists between two modules, if data from one
module is used to direct the order of instructions execution in another. An example
of control coupling is a flag set in one module and tested in another module.
iv) External Coupling: It occurs when two modules share an externally imposed data
format, communication protocol, or device interface. All the modules share the
same I/O device or the external environment.

20. v) Common coupling: Two modules are common coupled, if they share data through
some global data items.
vi) Content coupling: Content coupling exists between two modules, if they share
code, e.g. a branch from one module into another module
2. Cohesion
Most researchers and engineers agree that a good software design implies clean
decomposition of the problem into modules, and the neat arrangement of these
modules in a hierarchy.
The primary characteristics of neat module decomposition are high cohesion and
low coupling. Cohesion is a measure of functional strength of a module.

21.  A module having high cohesion and low coupling is said to be functionally independent
of other modules.
 By the term functional independence, we mean that a cohesive module performs a single
task or function.
 A functionally independent module has minimal interaction with other modules
Classification of cohesion:
The different classes of cohesion that a module may possess are depicted in fig. given below:

22. i) Coincidental cohesion:
A module is said to have coincidental cohesion, if it performs a set of tasks that relate to
each other very loosely, if at all. In this case, the module contains a random collection of
functions. It is likely that the functions have been put in the module out of pure
coincidence without any thought or design.
For example, in a transaction processing system (TPS), the get-input, print error, and
summarize-members functions are grouped into one module. The grouping does not have
any relevance to the structure of the problem.
ii) Logical cohesion: A module is said to be logically cohesive, if all elements of the module
perform similar operations, e.g. error handling, data input, data output, etc.
An example of logical cohesion is the case where a set of print functions generating different
output reports are arranged into a single module.
iii) Temporal cohesion: When a module contains functions that are related by the fact that all
the functions must be executed in the same time span, the module is said to exhibit temporal
cohesion.
The set of functions responsible for initialization, start-up, shutdown of some process, etc.
exhibit temporal cohesion.

23. iv) Procedural cohesion: A module is said to possess procedural cohesion, if the set
of functions of the module are all part of a procedure (algorithm) in which certain
sequence of steps have to be carried out for achieving an objective, e.g. the algorithm
for decoding a message.
v) Communicational cohesion: A module is said to have communicational cohesion,
if all functions of the module refer to or update the same data structure, e.g. the set of
functions defined on an array or a stack.
vi) Sequential cohesion: A module is said to possess sequential cohesion, if the
elements of a module form the parts of sequence, where the output from one element
of the sequence is input to the next.
For example, in a TPS, the get-input, validate-input, sort-input functions are grouped
into one module.

24. vii) Functional cohesion: Functional cohesion is said to exist, if different elements of a module
cooperate to achieve a single function.
For example, a module containing all the functions required to manage employees’ pay-roll
exhibits functional cohesion.
Suppose a module exhibits functional cohesion and we are asked to describe what the module
does, then we would be able to describe it using a single sentence

25. Coupling Cohesion
Coupling is also called Inter-Module
Binding.
Cohesion is also called Intra-Module
Binding.
Coupling shows the relationships
between modules.
Cohesion shows the relationship within
the module.
Coupling shows the
relative independence between the
modules.
Cohesion shows the module's
relative functional strength.
While creating, you should aim for low
coupling, i.e., dependency among
modules should be less.
While creating you should aim for high
cohesion, i.e., a cohesive component/
module focuses on a single function
(i.e., single-mindedness) with little
interaction with other modules of the
system.
In coupling, modules are linked to the
other modules.
In cohesion, the module focuses on a
single thing.
Differences between Coupling and Cohesion

26. 4. Information Hiding
 Modules should be specified and designed in such a way that the data structures and
processing details of one module are not accessible to other modules.
They pass only that much information to each other, which is required to accomplish the
software functions.
The way of hiding unnecessary details is referred to as information hiding.
 IEEE defines information hiding as 'the technique of encapsulating software design
decisions in modules in such a way that the module's interfaces reveal as little as possible
about the module's inner workings;
thus each module is a 'black box' to the other modules in the system

27. Information hiding is of immense use when modifications are required during the testing and
maintenance phase.
Some of the advantages associated with information hiding are listed below.
1. Leads to low coupling
2. Emphasizes communication through controlled interfaces
3. Decreases the probability of adverse effects
4. Restricts the effects of changes in one component on others
5. Results in higher quality software

28. 5. Stepwise Refinement
Stepwise refinement is a top-down design strategy used for decomposing a system from a
high level of abstraction into a more detailed level (lower level) of abstraction.
At the highest level of abstraction, function or information is defined conceptually without
providing any information about the internal workings of the function or internal structure of
the data.
 As we proceed towards the lower levels of abstraction, more and more details are
available.
Software designers start the stepwise refinement process by creating a sequence of
compositions for the system being designed.
Each composition is more detailed than the previous one and contains more components
and interactions.
The earlier compositions represent the significant interactions within the system, while the
later compositions show in detail how these interactions are achieved.

29. To have a clear understanding of the concept, let us consider an example of stepwise
refinement.
Every computer program comprises input, process, and output.
1. INPUT Get user's name (string) through a prompt. Get user's grade (integer from 0 to
100) through a prompt and validate.
2. PROCESS
3. OUTPUT
This is the first step in refinement. The input phase can be refined further as given here.
1. INPUT o Get user's name through a prompt. Get user's grade through a prompt. While
(invalid grade) Ask again:
2. PROCESS
3. OUTPUT
Note: Stepwise refinement can also be performed for PROCESS and OUTPUT phase

30. 6. Refactoring
Refactoring is the process of altering an application’s source code without changing its
external behavior. The purpose of refactoring is to improve some of the nonfunctional
properties of the code, such as readability, complexity, maintainability and extensibility.
Refactoring is an important design activity that reduces the complexity of module design
keeping its behavior or function unchanged.
Refactoring can be defined as a process of modifying a software system to improve the
internal structure of design without changing its external behavior.
 During the refactoring process, the existing design is checked for any type of flaws like
redundancy, poorly constructed algorithms and data structures, etc., in order to improve the
design.
 For example, a design model might yield a component which exhibits low cohesion (like a
component performs four functions that have a limited relationship with one another).
Software designers may decide to refactor the component into four different components,
each exhibiting high cohesion. This leads to easier integration, testing, and maintenance of the
software components.

31. 7. Structural Partitioning
When the architectural style of a design follows a hierarchical nature, the structure of the
program can be partitioned either horizontally or vertically.
In horizontal partitioning, the control modules are used to communicate between functions
and execute the functions.
Structural partitioning provides the following benefits.
The testing and maintenance of software becomes easier.
The negative impacts spread slowly.
 The software can be extended easily.
Besides these advantages, horizontal partitioning has some disadvantage also.
It requires passing more data across the module interface, which makes the control flow of the
problem more complex.
This usually happens in cases where data moves rapidly from one function to another.

32. In vertical partitioning, the functionality is distributed among the modules--in a top-down
manner. The modules at the top level called control modules perform the decision-making
and do little processing whereas the modules at the low level called worker modules perform
all input, computation and output tasks.

33. 8. Concurrency
 Computer has limited resources and they must be utilized efficiently as much as
possible.
To utilize these resources efficiently, multiple tasks must be executed concurrently.
This requirement makes concurrency one of the major concepts of software design.
Every system must be designed to allow multiple processes to execute concurrently,
whenever possible.
 For example, if the current process is waiting for some event to occur, the system must
execute some other process in the mean time.

34. THE DESIGN MODEL
To develop a complete specification of design (design model), four design models are needed.
These models are listed below.
1. Data design: This specifies the data structures for implementing the software by
converting data objects and their relationships identified during the analysis phase.
Various studies suggest that design engineering should begin with data design, since this
design lays the foundation for all other design models.
2. Architectural design: This specifies the relationship between the structural elements of the
software, design patterns, architectural styles, and the factors affecting the ways in which
architecture can be implemented.
3. Component-level design: This provides the detailed description of how structural elements
of software will actually be implemented.
4. Interface design: This depicts how the software communicates with the system that
interoperates with it and with the end-users.

35. Data Design Elements:
 Like other software engineering activities, data design (sometimes referred to as data
architecting) creates a model of data and/or information that is represented at a high level
of abstraction.
 This data model is then refined into progressively more implementation-specific
representations that can be processed by the computer-based system. The structure of data
has always been an important part of software design.
 At the program component level, the design of data structures and the associated
algorithms required to manipulate them is essential to the creation of high-quality
applications.
 At the application level, the translation of a data model into a database is pivotal to
achieving the business objectives of a system.
 At the business level, the collection of information stored in disparate databases and
reorganized into a “data warehouse” enables data mining or knowledge discovery that can
have an impact on the success of the business itself.

36. Architectural Design Elements:
The architectural design for software is the equivalent to the floor plan of a house. The floor
plan gives us an overall view of the house. Architectural design elements give us an overall
view of the software. The architectural model is derived from three sources:
(1) information about the application domain for the software to be built;
(2) specific requirements model elements such as data flow diagrams or analysis classes,
their relationships and collaborations for the problem at hand; and
(3) the availability of architectural styles and patterns. The architectural design element is
usually depicted as a set of interconnected subsystems, Each subsystem may have it’s
own architecture

37. Interface Design Elements:
The interface design for software is analogous to a set of detailed drawings for the doors,
windows, and external utilities of a house. The interface design elements for software depict
information flows into and out of the system and how it is communicated among the
components defined as part of the architecture.
There are three important elements of interface design:
(1) the user interface (UI);
(2) external interfaces to other systems, devices, networks, or other producers or consumers
of information; and
(3) internal interfaces between various design components. These interface design elements
allow the software to communicate externally and enable internal communication and
collaboration among the components that populate the software architecture.

38. Component-Level Design Elements:
The component-level design for software is the equivalent to a set of detailed drawings
(and specifications) for each room in a house.
The component-level design for software fully describes the internal detail of each
software component.
To accomplish this, the component-level design defines data structures for all local data
objects and algorithmic detail for all processing that occurs within a component. interface
that allows access to all component operations (behaviors).

39. What Is Architecture? :
Software architecture must model the structure of a system and the manner in which data and
procedural components collaborate with one another.
SOFTWARE ARCHITECTURE
The architecture is not the operational software. Rather, it is a representation that enables
you to
(1) analyze the effectiveness of the design in meeting its stated requirements
(2) architectural alternatives at a stage when making design changes is still relatively easy
(3) reduce the risks associated with the construction of the software. This definition
emphasizes the role of “software components” in any architectural representation.

40. There is a distinct difference between the terms architecture and design.
A design is an instance of an architecture similar to an object being an instance of a class.
For example, consider the client-server architecture.
I can design a network-centric software system in many different ways from this architecture
using either the Java platform (Java EE) or Microsoft platform (.NET framework).
 So, there is one architecture, but many designs can be created based on that architecture.
Architectural design focuses on the representation of the structure of software components,
their properties, and interactions.

41. ARCHITECTURAL STYLES
An architectural style is a transformation that is imposed on the design of an entire system.
The intent is to establish a structure for all components of the system.
Data-centered architectures
TYPES OF ARCHITECTURAL STYLES

42.  A data store (e.g., a file or database) resides at the center of this architecture and is
accessed frequently by other components that update, add, delete, or otherwise modify
data within the store.
 Client software accesses a central repository. In some cases the data repository is passive.
That is, client software accesses the data independent of any changes to the data or the
actions of other client software. Data-centered architectures promote integrity.
 That is, existing components can be changed and new client components added to the
architecture without concern about other clients (because the client components operate
independently).
 In addition, data can be passed among clients using the blackboard mechanism (i.e., the
blackboard component serves to coordinate the transfer of information between clients).
Client components independently execute processes.
 Eg:Airline CRM System

43. Data-flow architectures:
This architecture is applied when input data are to be transformed through a series of
computational or manipulative components into output data.
A pipe-and-filter pattern has a set of components, called filters, connected by pipes that
transmit data from one component to the next.
Each filter works independently of those components upstream and downstream, is designed
to expect data input of a certain form, and produces data output (to the next filter) of a
specified form.
Eg:Architecture of a Language Processor (e.g., compiler, interpreter)

44. Call and return architectures.
This architectural style enables you to achieve a program structure that is relatively easy to
modify and scale.
A number of sub styles exist within this category:
• Main program/subprogram architectures. This classic program structure decomposes
function into a control hierarchy where a “main” program invokes a number of program
components that in turn may invoke still other components.
• Remote procedure call architectures. The components of a main program/subprogram
architecture are distributed across multiple computers on a network.

45. Layered architectures.
The basic structure of a layered architecture is illustrated in Figure .
A number of different layers are defined, each accomplishing operations that progressively
become closer to the machine instruction set. At the outer layer, components service user
interface operations. At the inner layer, components perform operating system interfacing.
Intermediate layers provide utility services and application software functions.
Eg:iLearn system

46. These architectural styles are only a small subset of those available.
 Once requirements engineering uncovers the characteristics and constraints of the system to
be built, the architectural style and/or combination of patterns that best fits those
characteristics and constraints can be chosen.
 For example, a layered style (appropriate for most systems) can be combined with a data
centered architecture in many database applications.

47. Architectural patterns:
There are various ways to organize the components in software architecture. And
the different predefined organization of components in software architectures are
known as software architecture patterns.
 A lot of patterns were tried and tested. Most of them have successfully solved
various problems.
In each pattern, the components are organized differently for solving a specific
problem in software architectures.
Different Software Architecture Patterns :
Layered Pattern
Client-Server Pattern
Event-Driven Pattern
Microkernel Pattern
Microservices Pattern

48. 1.Layered Pattern: As the name suggests, components(code) in this pattern are separated into
layers of subtasks and they are arranged one above another.
Each layer has unique tasks to do and all the layers are independent of one another. Since each
layer is independent, one can modify the code inside a layer without affecting others.
It is the most commonly used pattern for designing the majority of software. This layer is also
known as ‘N-tier architecture’.
Basically, this pattern has 4 layers.
Presentation layer (The user interface layer where we see and enter data into an application.)
Business layer (this layer is responsible for executing business logic as per the request.)
Application layer (this layer acts as a medium for communication between the ‘presentation
layer’ and ‘data layer’.
Data layer (this layer has a database for managing data.)
Ideal for:
E-commerce web applications development like Amazon.

49. 2.Client-ServerPattern:
The client-server pattern has two major entities:
They are a server and multiple clients.
Here the server has resources(data, files or services) and a client requests the server for a
particular resource.
Then the server processes the request and responds back accordingly.
Examples of software developed in this pattern:
Email.
WWW.
File sharing apps.
Banking, etc…
So this pattern is suitable for developing the kind of software listed in the examples.

50. 3.Event-Driven Pattern:
Event-Driven Architecture is an agile approach in which services (operations) of the
software are triggered by events.
Well, what does an event mean?
When a user takes action in the application built using the EDA approach, a state change
happens and a reaction is generated that is called an event.
Eg: A new user fills the signup form and clicks the signup button on Facebook and then a
FB account is created for him, which is an event.
Ideal for: Building websites with JavaScript and e-commerce websites in general.
4. Microkernel Pattern :
Microkernel pattern has two major components. They are a core system and plug-in
modules.
The core system handles the fundamental and minimal operations of the application.
The plug-in modules handle the extended functionalities (like extra features) and
customized processing.

51. Let’s imagine, you have successfully built a chat application. And the basic functionality
of the app is that you can text with people across the world without an internet connection.
After some time, you would like to add a voice messaging feature to the application, then
you are adding the feature successfully. You can add that feature to the already developed
application because the microkernel pattern facilitates you to add features as plug-ins.
Microkernel pattern is ideal for:
Product-based applications and scheduling applications. We love new features that keep
giving dopamine boost to our brain. Such as Instagram reels, You Tube Shorts and a lot more
that feasts us digitally. So this pattern is mostly preferred for app development.

52. 5.MicroservicesPattern: :
The collection of small services that are combined to form the actual application is the concept
of microservices pattern.
Instead of building a bigger application, small programs are built for every service (function)
of an application independently. And those small programs are bundled together to be a full-
fledged application.
So adding new features and modifying existing microservices without affecting other
microservices are no longer a challenge when an application is built in a microservices
pattern.
Modules in the application of microservices patterns are loosely coupled. So they are easily
understandable, modifiable and scalable.
Example Netflix is one of the most popular examples of software built-in microservices
architecture. This pattern is most suitable for websites and web apps having small
components.

53. Conceptual Model of UML
 UML is a standard language for specifying, visualizing, constructing, and documenting
the artifacts of software systems.
 It was initially developed by Grady Booch, Ivar Jacobson, and James Rumbaugh in
1994-95 at Rational software, and its further development was carried out through 1996.
In 1997, it got adopted as a standard by the Object Management Group.
 It is used to understand, design, browse, configure, maintain, and control information
about such systems.
 The UML captures information about the static structure and dynamic behavior of a
system.
 UML is not a programming language. Tools can provide code generators from UML into
a variety of programming languages, as well as construct reverse engineered models
from existing programs.

54. Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building blocks:
Things
Relationships
Diagrams
Things are the abstractions that are first-class citizens in a model; relationships tie these things
together; diagrams group interesting collections of things.
Things in the UML
There are four kinds of things in the UML:
Structural things
Behavioral things
Grouping things
Annotational things

55. Structural Things
Structural things are the nouns of UML models.
These are the mostly static parts of a model.
Classes
A class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics.
A class implements one or more interfaces. Graphically, a class is rendered as a rectangle,
usually including its name, attributes, and operations.

56. Interface:
 An interface is a collection of operations that specify a service of a class or component.
 An interface might represent the complete behavior of a class or component or only a part
of that behavior
 An interface defines a set of operation specifications (that is, their signatures) but never a
set of operation implementations.
 An interface provided by a class to the outside world is shown as a small circle attached to
the class box by a line.
 An interface required by a class from some other class is shown as a small semicircle
attached to the class box by a line

57. Collaboration
Collaboration: A collaboration is the collection of interactions among objects to achieve a goal.
Graphically collaboration is represented as a dashed ellipse. A collaboration can be a collection
of classes or other elements.
Use Case:
• A use case is a description of sequences of actions that a system performs that
yield observable results of value to a particular actor.
• A use case is used to structure the behavioral things in a model.
• Graphically, a use case is rendered as an ellipse with solid lines, usually
including only its name

58. Component: A component is a physical and replaceable part of a system. Graphically
component is represented as a tabbed rectangle.
Examples of components are executable files, dll files, database tables, files and documents.

59. Nodes:
A node is a physical element that exists at run time and represents a computational resource,
generally having at least some memory and, often, processing capability.
A set of components may reside on a node and may also migrate from node to node.
Graphically, a node is rendered as a cube, usually including only its name.
Behavioral Things:
Behavioral things are the dynamic parts of UML models.
These are the verbs of a model, representing behavior over time and space.
There are 2 primary kinds of behavioral things
Interaction
State

60. Interaction:
• It is a behavior that comprises a set of messages exchanged among a set of objects or roles
within a particular context to accomplish a specific purpose.
• An interaction involves a number of other elements, including messages, actions, and
connectors .
• Graphically, a message is rendered as a directed line, almost always including the name of
its operation
State:
• It is a behavior that specifies the sequences of states an object or an interaction goes
through during its lifetime in response to events, together with its responses to those
events.
• The behavior of an individual class or a collaboration of classes may be specified
with a state machine.
• A state machine involves a number of other elements, including states, transitions
(the flow from state to state), events (things that trigger a transition), and activities
(the response to a transition).
• Graphically, a state is rendered as a rounded rectangle, usually including its name
and its substates.

61. Grouping Things
• Grouping things are the organizational parts of UML models.
• There is one primary kind of grouping thing, namely, packages.
Package:
• A package is a general-purpose mechanism for organizing the design itself.
• Structural things, behavioral things, and even other grouping things may be placed in a
package.
• Graphically, a package is rendered as a tabbed folder, usually including only its name and,
sometimes, its contents

62. Annotational Things:
Annotational things are the explanatory parts of UML models.
These are the comments you may apply to describe, illuminate, and remark about any
element in a model.
There is one primary kind of annotational things, called a note.
A note is simply a symbol for rendering constraints and comments attached to an element
or a collection of elements.
Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a
textual or graphical comment.

63. Relationships in the UML
There are four kinds of relationships in the UML:
I. Dependency
II. Association
III. Generalization
IV. Realization
Dependency:
• A dependency is a semantic relationship between two model elements in which a change to
one element (the independent one) may affect the semantics of the other element.
• Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally
including a label
Association
• An association is a structural relationship among classes that describes a set of links.
• A link being a connection among objects that are instances of the classes.
• Aggregation is a special kind of association, representing a structural relationship between a
whole and its parts.
• Graphically, an association is rendered as a solid line, possibly directed, occasionally
including a label, and often containing other adornments, such as multiplicity and end
names.

64. Generalizations:
• A generalization is a specialization/generalization relationship in which the specialized
element (the child) builds on the specification of the generalized element (the parent).
• The child shares the structure and the behavior of the parent.
• Graphically, a generalization relationship is rendered as a solid line with a hollow
arrowhead pointing to the parent.
Realizations:
A realization is a semantic relationship between classifiers, where in one classifier specifies
a contract that another classifier guarantees to carry out.
Graphically, a realization relationship is rendered as a cross between a generalization and a
dependency relationship.

65. Diagrams in the UML
• A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and paths (relationships).
• Drawing diagrams to visualize a system from different perspectives, so a diagram is a
projection into a system.
• A diagram may contain any combination of things and relationships.
List of UML Diagrams
I. Class diagram
II. Object diagram
III. Component diagram
IV. Deployment diagram
V. Use case diagram
VI. State diagram
VII. Activity diagram
VIII. Sequence diagram
IX. Collaboration diagram
Interaction diagrams

66. Class diagram
• A class diagram shows a set of classes, interfaces, and collaborations and their
relationships.
• Class diagrams address the static design view of a system.
The following diagram is an example of an Order System of an application. It describes a
particular aspect of the entire application.
First of all, Order and Customer are identified as the two elements of the system. They
have a one-to-many relationship because a customer can have multiple orders.
Order class is an abstract class and it has two concrete classes (inheritance relationship)
Special Order and Normal Order.
The two inherited classes have all the properties as the Order class. In addition, they
have additional functions like dispatch () and receive ().

68. Object diagram
An object diagram shows a set of objects and their relationships.
Object diagrams represent static snapshots of instances of the things found in class diagrams.

69. Component diagrams can also be described as a static implementation view of a system.
Static implementation represents the organization of the components at a particular
moment.
Component diagrams can be used to −
Model the components of a system.
Model the database schema.
Model the executables of an application.
Model the system's source code.

70. Deployment diagrams are used to visualize the topology of the physical components of a
system, where the software components are deployed.
Following is a sample deployment diagram to provide an idea of the deployment view of
order management system. Here, we have shown nodes as −
Monitor
Modem
Caching server
Server

71. Use case diagrams are considered for high level requirement analysis of a system. When the
requirements of a system are analyzed, the functionalities are captured in use cases.
Use case diagrams are drawn to capture the functional requirements of a system.

72. The interactive behavior is represented in UML by two diagrams known as Sequence
diagram and Collaboration diagram.
The basic purpose of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and
collaboration diagram emphasizes on the structural organization of the objects that send
and receive messages.

73. To choose between these two diagrams, emphasis is placed on the type of requirement. If
the time sequence is important, then the sequence diagram is used. If organization is
required, then collaboration diagram is used.

74. Interaction diagrams can be used −
To model the flow of control by time sequence.
To model the flow of control by structural organizations.
Statechart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs.

75. Statechart diagram defines the states of a component and these state changes are dynamic
in nature. Its specific purpose is to define the state changes triggered by events. Events are
internal or external factors influencing the system.
Activity diagram is basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system.
The main element of an activity diagram is the activity itself. An activity is a function
performed by the system
The specific usage is to model the control flow from one activity to another. This control
flow does not include messages.