MST2 Software Eng
MST2 Software Eng
MST2 Software Eng
Agile Model
Architectural Design
Flowcharts
Class Diagram
Code Reusability
Jacoco
Requirement gathering
Design the Requirements
Construction / Iteration
Testing / Quality Assurance
Deployment
Feedback
1. Requirement Gathering:- In this step, the development team must gather
the requirements, by interaction with the customer. development team
should plan the time and effort needed to build the project. Based on this
information you can evaluate technical and economical feasibility.
2. Design the Requirements:- In this step, the development team will use
user-flow-diagram or high-level UML diagrams to show the working of the new
features and show how they will apply to the existing software. Wireframing
and designing user interfaces are done in this phase.
5. Unit Testing:- Unit testing is the process of checking small pieces of code to
ensure that the individual parts of a program work properly on their own. Unit
testing is used to test individual blocks (units) of code.
5. Deployment:- In this step, the development team will deploy the working
project to end users.
6. Feedback:- This is the last step of the Agile Model. In this, the team
receives feedback about the product and works on correcting bugs based on
feedback provided by the customer.
A data store will reside at the center of this architecture and is accessed frequently
by the other components that update, add, delete or modify the data present within
the store.
data-centered architecture will promote integrability. The client software access a
central repository.
The components of a system encapsulate data and the operations that must be applied
to manipulate the data. The coordination and communication between the components
are established via the message passing.
5] Layered architecture:
A number of different layers are defined with each layer performing a well-defined
set of operations. Each layer will do some operations that becomes closer to
machine instruction set progressively.
components will receive the user interface operations and at the inner layers,
components will perform the operating system interfacing(communication and
coordination with OS)
One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation) communication
system.
Flowcharts LINK
What is a Flowchart?
Flowchart is a graphical representation of an algorithm. Programmers often
use it as a program-planning tool to solve a problem. It makes use of symbols
which are connected among them to indicate the flow of information and
processing.
The process of drawing a flowchart for an algorithm is known as
“flowcharting”.
Example :
What is a class?
In object-oriented programming (OOP), a class is a blueprint or template for
creating objects. Objects are instances of classes, and each class defines a set
of attributes (data members) and methods (functions or procedures) that the
objects created from that class will possess. The attributes represent the
characteristics or properties of the object, while the methods define the
behaviors or actions that the object can perform.
1. Class Name:
The name of the class is typically written in the top compartment of the
class box and is centered and bold.
2. Attributes:
Attributes, also known as properties or fields, represent the data members
of the class. They are listed in the second compartment of the class box
and often include the visibility (e.g., public, private) and the data type of
each attribute.
3. Methods:
Methods, also known as functions or operations, represent the behavior or
functionality of the class. They are listed in the third compartment of the
class box and include the visibility (e.g., public, private), return type, and
parameters of each method.
4. Visibility Notation:
Visibility notations indicate the access level of attributes and methods.
Common visibility notations include:
+ for public (visible to all classes)
- for private (visible only within the class)
# for protected (visible to subclasses)
~ for package or default visibility (visible to classes in the same package)
Category Function
Constraints in OCL
1. Invariants
2. Pre-conditions
3. Post conditions
1. Invariant
An invariant is a constraint that is supposed to be proven true before and after the
execution of an operation.Example:
context <ClassName>
inv <InvariantName>: <expression>
2. Pre-condition
3. Post condition
• Inheritance
• Functions
• Libraries
• Forking
Inheritance: Inheritance has been in the programming for quite a long time and is
used in Object-Oriented Programming paradigms. Inheritance lets you use the
base class's functions and members in other classes
Functions: A return type that denotes what type of data would be returned or a
void.
An identifier that is used to make a call to this function. Function body that is
the code block containing the code to be executed when this function is
called.
Zero or more parameters to provide values to the code block variables.
Function calls are another way of reusing the code from various parts of your
application.
You create small code blocks of an algorithm or logic-based source code and
provide it a name, identifier.
Libraries: Libraries are a set of compiled programs, most often used by larger and
enterprise level software, to support the execution since they can be executed
upon call.
Forking: Forking is a process of using someone else's source code and making
changes to it to fit your own needs, to distribute, use, and share and so on.
User can also fork someone else's source code and write some more details to
it. Make some bug fixes, add some patches and share it.
This method has been widely used by various companies, to fork open source
projects, make a few changes to the “Under the hood” and then distribute it
with their own label and tag.
Coding Standards and Guidelines LINK
A coding standard gives a uniform appearance to the codes written by
different engineers.
It improves readability, and maintainability of the code and it reduces
complexity also.
It helps in code reuse and helps to detect error easily.
1. Limited use of globals:These rules tell about which types of data that can be
declared global and the data that can’t be.
2. Standard headers for different modules:the header of different modules
should follow some standard format and information
3. Naming conventions for local variables, global variables, constants and
functions: Meaningful and understandable variables name helps anyone to
understand the reason of using it.It is better to avoid the use of digits in
variable names.
4. Indentation: There must be a space after giving a comma between two
function arguments.Each nested block should be properly indented and
spaced.
5. Error return values and exception handling conventions: All functions that
encountering an error condition should either return a 0 or 1 for simplifying
the debugging.
6. Avoid using a coding style that is too difficult to understand: Code should be
easily understandable. The complex code makes maintenance and debugging
difficult and expensive.
7. Avoid using an identifier for multiple purposes:
8. Code should be well documented: The code should be properly commented
for understanding easily. Comments regarding the statements increase the
understandability of the code.
9. Length of functions should not be very large:
10. Try not to use GOTO statement:GOTO statement makes the program
unstructured, thus it reduces the understandability of the program and also
debugging becomes difficult.
JaCoCo LINK
“Code Coverage is a software metric that is used to measure how many lines of
our code are executed during automated tests”
JaCoCo stands for Java Code Coverage. It is a free code coverage library for Java,
which has been created by the EclEmma team. It creates code coverage reports
and integrates well with IDEs like IntelliJ IDEA, Eclipse IDE, etc. JaCoCo also
integrates with CI/CD tools like Jenkins, Circle CI, etc., and project management
tools like SonarQube, etc. So in this article, we are going to create a sample Java
application and generate the code coverage report with the help of the JaCoCo
maven plugin.
Procedure:
Step 1: Create a simple Java application and write down some test cases inside
the application using Junit or you can also use Mockito.
Step 3: After adding the dependency click on the Maven option which is present
on the right upper side as shown in the below image. Then select clean and test
and then select the run button (Green color triangle).
Step 4: To get you code coverage report navigate to the target > site > jacoco >
index.html > right-click > Open In > Browser > And your preferred browser. So
basically index.html is your code coverage report file.
The green color shows that all lines of code have been covered which means
you have written the test cases for all the units.
If you have encountered the yellow color line then partial code has been
covered and
if you have encountered with the red color then the code has not been
covered.