IEEE software Engineering Definition [ICT Ministry AP, 2017]

Software engineering is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

Software Development Life Cycle [ICT Ministry AP, 2017], [AME,Education Ministry -2014]

Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages in software engineering to develop the intended software product.

SDLC Activities

SDLC provides a series of steps to be followed to design and develop a software product efficiently. SDLC framework includes the following steps:

Waterfall Model [AP, Home Ministry -2014]

Waterfall model is the simplest model of software development paradigm. It says the all the phases of SDLC will function one after another in linear manner. That is, when the first phase is finished then only the second phase will start and so on.

Spiral Model

Spiral model is a combination of both, iterative model and one of the SDLC model. It can be seen as if you choose one SDLC model and combine it with cyclic process (iterative model).

V – model

The major drawback of waterfall model is we move to the next stage only when the previous one is finished and there was no chance to go back if something is found wrong in later stages. V-Model provides means of testing of software at each stage in reverse manner.

Project Management Tools

The risk and uncertainty rises multifold with respect to the size of the project, even when the project is developed according to set methodologies.

There are tools available, which aid for effective project management. A few are described -

Gantt Chart

Gantt charts was devised by Henry Gantt (1917). It represents project schedule with respect to time periods. It is a horizontal bar chart with bars representing activities and time scheduled for the project activities.

PERT Chart

PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as network diagram. It is capable of graphically representing main events of project in both parallel and consecutive way. Events, which occur one after another, show dependency of the later event over the previous one.

Events are shown as numbered nodes. They are connected by labeled arrows depicting sequence of tasks in the project.

Resource Histogram

This is a graphical tool that contains bar or chart representing number of resources (usually skilled staff) required over time for a project event (or phase). Resource Histogram is an effective tool for staff planning and coordination.

Coupling and Cohesion [Agrani Bank Senor Officer(ICT) Viva]

When a software program is modularized, its tasks are divided into several modules based on some characteristics. As we know, modules are set of instructions put together in order to achieve some tasks. They are though, considered as single entity but may refer to each other to work together. 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.

Cohesion

Cohesion is a measure that defines the degree of intra-dependability within elements of a module. The greater the cohesion, the better is the program design.

There are seven types of cohesion, namely –

· Co-incidental cohesion - It is unplanned and random cohesion, which might be the result of breaking the program into smaller modules for the sake of modularization. Because it is unplanned, it may serve confusion to the programmers and is generally not-accepted.

· Logical cohesion - When logically categorized elements are put together into a module, it is called logical cohesion.

· Temporal Cohesion - When elements of module are organized such that they are processed at a similar point in time, it is called temporal cohesion.

· Procedural cohesion - When elements of module are grouped together, which are executed sequentially in order to perform a task, it is called procedural cohesion.

· Communicational cohesion - When elements of module are grouped together, which are executed sequentially and work on same data (information), it is called communicational cohesion.

· Sequential cohesion - When elements of module are grouped because the output of one element serves as input to another and so on, it is called sequential cohesion.

· Functional cohesion - It is considered to be the highest degree of cohesion, and it is highly expected. Elements of module in functional cohesion are grouped because they all contribute to a single well-defined function. It can also be reused.

Coupling

Coupling is a measure that defines the level of inter-dependability among modules of a program. It tells at what level the modules interfere and interact with each other. The lower the coupling, the better the program.

There are five levels of coupling, namely -

· Content coupling - When a module can directly access or modify or refer to the content of another module, it is called content level coupling.

· Common coupling- When multiple modules have read and write access to some global data, it is called common or global coupling.

· Control coupling- Two modules are called control-coupled if one of them decides the function of the other module or changes its flow of execution.

· Stamp coupling- When multiple modules share common data structure and work on different part of it, it is called stamp coupling.

· Data coupling- Data coupling is when two modules interact with each other by means of passing data (as parameter). If a module passes data structure as parameter, then the receiving module should use all its components.

Ideally, no coupling is considered to be the best.

Cyclomatic Complexity Measures

Every program encompasses statements to execute in order to perform some task and other decision-making statements that decide, what statements need to be executed. These decision-making constructs change the flow of the program

To calculate Cyclomatic complexity of a program module, we use the formula -

V(G)= e – n +2

Where

eis total number of edges

nis total number of nodes

The Cyclomatic complexity of the above module is

Acceptance Testing

When the software is ready to hand over to the customer it has to go through last phase of testing where it is tested for user-interaction and response. This is important because even if the software matches all user requirements and if user does not like the way it appears or works, it may be rejected.

User acceptance is a type of testing performed by the Client to certify the system with respect to the requirements that was agreed upon. This testing happens in the final phase of testing before moving the software application to Market or Production environment.

What is Alpha Testing ?

Alpha testing is a type of acceptance testing; performed to identify all possible issues/bugs before releasing the product to everyday users or public. The focus of this testing is to simulate real users by using blackbox and whitebox techniques. The aim is to carry out the tasks that a typical user might perform. Alpha testing is carried out in a lab environment and usually the testers are internal employees of the organization. To put it as simple as possible, this kind of testing is called alpha only because it is done early on, near the end of the development of the software, and before beta testing.

What is Beta Testing?

Beta Testing of a product is performed by "real users" of the software application in a "real environment" and can be considered as a form of external User Acceptance Testing.

Beta version of the software is released to a limited number of end-users of the product to obtain feedback on the product quality. Beta testing reduces product failure risks and provides increased quality of the product through customer validation.

It is the final test before shipping a product to the customers. Direct feedback from customers is a major advantage of Beta Testing. This testing helps to tests the product in real time environment.

Phases of Testing

Alpha and Beta tests are typically carried for "off-the shelf" software or product oriented companies. The Phases of Testing for a product company typically varies from a service oriented organization. Following is the testing phase adopted by product firms

Alpha Testing Vs Beta testing:

Following are the differences of Alpha and Beta Testing: [NESCO-2017]

Alpha Testing	Beta Testing
Alpha testing performed by Testers who are usually internal employees of the organization	Beta testing is performed by Clients or End Users who are not employees of the organization
Alpha Testing performed at developer's site	Beta testing is performed at client location or end user of the product
Reliability and Security Testing are not performed in-depth Alpha Testing	Reliability, Security, Robustness are checked during Beta Testing
Alpha testing involves both the white box and black box techniques	Beta Testing typically uses Black Box Testing
Alpha testing requires lab environment or testing environment	Beta testing doesn't require any lab environment or testing environment. Software is made available to the public and is said to be real time environment
Long execution cycle may be required for Alpha testing	Only few weeks of execution are required for Beta testing
Critical issues or fixes can be addressed by developers immediately in Alpha testing	Most of the issues or feedback is collected from Beta testing will be implemented in future versions of the product
Alpha testing is to ensure the quality of the product before moving to Beta testing	Beta testing also concentrates on quality of the product, but gathers users input on the product and ensures that the product is ready for real time users.

What is Regression Testing?

Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is done by code testing specialists

Regression Testing is defined as a type of software testing to confirm that a recent program or code change has not adversely affected existing features.

What is White Box Testing?

White Box Testing is the testing of a software solution's internal coding and infrastructure. It focuses primarily on strengthening security, the flow of inputs and outputs through the application, and improving design and usability. White box testing is also known as Clear Box testing, Open Box testing, Structural testing, Transparent Box testing, Code-Based testing, and Glass Box testing.

What is Black Box Testing?

Black box testing is a software testing techniques in which functionality of the software under test (SUT) is tested without looking at the internal code structure, implementation details and knowledge of internal paths of the software. This type of testing is based entirely on the software requirements and specifications.

The Differences Between Black Box Testing and White Box Testing are listed below. [BDB Senior Officer (IT)-2018]

Criteria	Black Box Testing	White Box Testing
Definition	Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is NOT known to the tester	White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester.
Levels Applicable To	Mainly applicable to higher levels of testing:Acceptance Testing System Testing	Mainly applicable to lower levels of testing:Unit Testing Integration Testing
Responsibility	Generally, independent Software Testers	Generally, Software Developers
Programming Knowledge	Not Required	Required
Implementation Knowledge	Not Required	Required
Basis for Test Cases	Requirement Specifications	Detail Design

UML diagram of composite design patterns------- [BPDB-2018]

Composite Design Pattern

Composite pattern is a partitioning design pattern and describes a group of objects that is treated the same way as a single instance of the same type of object. The intent of a composite is to “compose” objects into tree structures to represent part-whole hierarchies. It allows you to have a tree structure and ask each node in the tree structure to perform a task.

UML for Composite Pattern

Elements used in Composite Pattern:

Let's see the 4 elements of composte pattern.

1) Component

o Declares interface for objects in composition.

o Implements default behavior for the interface common to all classes as appropriate.

o Declares an interface for accessing and managing its child components.

2) Leaf

o Represents leaf objects in composition. A leaf has no children.

o Defines behavior for primitive objects in the composition.

3) Composite

o Defines behavior for components having children.

o Stores child component.

o Implements child related operations in the component interface.

4) Client

o Manipulates objects in the composition through the component interface.

Example of Composite Pattern

We can easily understand the example of composite design pattern by the UML diagram given below:

Implementation of above UML:

Step 1

Create an Employee interface that will be treated as a component.

// this is the Employee interface i.e. Component.

public interface Employee {

public int getId();

public String getName();

public double getSalary();

public void print();

public void add(Employee employee);

public void remove(Employee employee);

public Employee getChild(int i);

}// End of the Employee interface.

Step 2

Create a BankManager class that will be treated as a Composite and implements Employee interface.

File: BankManager.java

// this is the BankManager class i.e. Composite.

import java.util.ArrayList;

import java.util.Iterator;

import java.util.List;

public class BankManager implements Employee {

private int id;

private String name;

private double salary;

public BankManager(int id,String name,double salary) {

this.id=id;

this.name = name;

this.salary = salary;

}

List<Employee> employees = new ArrayList<Employee>();

@Override

public void add(Employee employee) {

employees.add(employee);

}

@Override

public Employee getChild(int i) {

return employees.get(i);

}

@Override

public void remove(Employee employee) {

employees.remove(employee);

}

@Override

public int getId() {

return id;

}

@Override

public String getName() {

return name;

}

@Override

public double getSalary() {

return salary;

}

@Override

public void print() {

System.out.println("==========================");

System.out.println("Id ="+getId());

System.out.println("Name ="+getName());

System.out.println("Salary ="+getSalary());

System.out.println("==========================");

Iterator<Employee> it = employees.iterator();

while(it.hasNext()) {

Employee employee = it.next();

employee.print();

}

}// End of the BankManager class.

Step 3

Create a Cashier class that will be treated as a leaf and it will implement to the Employee interface.

File: Cashier.java

public class Cashier implements Employee{

private int id;

private String name;

private double salary;

public Cashier(int id,String name,double salary) {

this.id=id;

this.name = name;

this.salary = salary;

}

@Override

public void add(Employee employee) {

//this is leaf node so this method is not applicable to this class.

}

@Override

public Employee getChild(int i) {

//this is leaf node so this method is not applicable to this class.

return null;

}

@Override

public int getId() {

// TODO Auto-generated method stub

return id;

}

@Override

public String getName() {

return name;

}

@Override

public double getSalary() {

return salary;

}

@Override

public void print() {

System.out.println("==========================");

System.out.println("Id ="+getId());

System.out.println("Name ="+getName());

System.out.println("Salary ="+getSalary());

System.out.println("==========================");

}

@Override

public void remove(Employee employee) {

//this is leaf node so this method is not applicable to this class.

}

Step 4

Create a Accountant class that will also be treated as a leaf and it will implement to the Employee interface.

File: Accountant.java

public class Accountant implements Employee{

private int id;

private String name;

private double salary;

public Accountant(int id,String name,double salary) {

this.id=id;

this.name = name;

this.salary = salary;

}

@Override

public void add(Employee employee) {

//this is leaf node so this method is not applicable to this class.

}

@Override

public Employee getChild(int i) {

//this is leaf node so this method is not applicable to this class.

return null;

}

@Override

public int getId() {

// TODO Auto-generated method stub

return id;

}

@Override

public String getName() {

return name;

}

@Override

public double getSalary() {

return salary;

}

@Override

public void print() {

System.out.println("=========================");

System.out.println("Id ="+getId());

System.out.println("Name ="+getName());

System.out.println("Salary ="+getSalary());

System.out.println("=========================");

}

@Override

public void remove(Employee employee) {

//this is leaf node so this method is not applicable to this class.

}

Step 5

Create a CompositePatternDemo class that will also be treated as a Client and ii will use the Employee interface.

File: CompositePatternDemo.java

public class CompositePatternDemo {

public static void main(String args[]){

Employee emp1=new Cashier(101,"Sohan Kumar", 20000.0);

Employee emp2=new Cashier(102,"Mohan Kumar", 25000.0);

Employee emp3=new Accountant(103,"Seema Mahiwal", 30000.0);

Employee manager1=new BankManager(100,"Ashwani Rajput",100000.0);

manager1.add(emp1);

manager1.add(emp2);

manager1.add(emp3);

manager1.print();

}

Why Do We Use UML?

A complex enterprise application with many collaborators will require a solid foundation of planning and clear, concise communication among team members as the project progresses.

Visualizing user interactions, processes, and the structure of the system you're trying to build will help save time down the line and make sure everyone on the team is on the same page

Define UML diagram and Activity diagram [Eastern refinery – buet-2016]

Activity diagram is another important behavioral diagram in UML diagram to describe dynamic aspects of the system. Activity diagram is essentially an advanced version of flow chart that modeling the flow from one activity to another activity.

When to Use Activity Diagram

Activity Diagrams describe how activities are coordinated to provide a service which can be at different levels of abstraction. Typically, an event needs to be achieved by some operations, particularly where the operation is intended to achieve a number of different things that require coordination, or how the events in a single use case relate to one another, in particular, use cases where activities may overlap and require coordination. It is also suitable for modeling how a collection of use cases coordinate to represent business workflows

Identify candidate use cases, through the examination of business workflows

Identify pre- and post-conditions (the context) for use cases

Model workflows between/within use cases

Model complex workflows in operations on objects

Model in detail complex activities in a high level activity Diagram

Activity Diagram - Learn by Examples

A basic activity diagram - flowchart like

Activity Diagram - Modeling a Word Processor

The activity diagram example below describes the workflow for a word process to create a document through the following steps:

· Open the word processing package.

· Create a file.

· Save the file under a unique name within its directory.

· Type the document.

· If graphics are necessary, open the graphics package, create the graphics, and paste the graphics into the document.

· If a spreadsheet is necessary, open the spreadsheet package, create the spreadsheet, and paste the spreadsheet into the document.

· Save the file.

· Print a hard copy of the document.

· Exit the word processing package.

Activity Diagram Example - Process Order

Given the problem description related to the workflow for processing an order, let's model the description in visual representation using an activity diagram:

Process Order - Problem Description

Once the order is received, the activities split into two parallel sets of activities. One side fills and sends the order while the other handles the billing.

On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or the Regular Delivery activity is performed.

Finally the parallel activities combine to close the order.

The activity diagram example below visualize the flow in graphical form.

Activity Diagram Notation Summary

Notation Description

UML Notation

Activity

Is used to represent a set of actions

Action

A task to be performed

Control Flow

Shows the sequence of execution

Object Flow

Show the flow of an object from one activity (or action) to another activity (or action).

Initial Node

Portrays the beginning of a set of actions or activities

Activity Final Node

Stop all control flows and object flows in an activity (or action)

Object Node

Represent an object that is connected to a set of Object Flows

Decision Node

Represent a test condition to ensure that the control flow or object flow only goes down one path

Merge Node

Bring back together different decision paths that were created using a decision-node.

Fork Node

Split behavior into a set of parallel or concurrent flows of activities (or actions)

Join Node

Bring back together a set of parallel or concurrent flows of activities (or actions).

Important Answer: -

Activity Diagram Tutorial

Activity Diagram is similar to a business work flow diagram or simply a flowchart with much richer semantics. It describes the system activities, or the person who does the activity, and the sequential flow of these activities. The activity diagram is one of the UML diagrams associated with object oriented approach, through it can be used in any other software development paradigm

What is a Activity Diagram in UML?

Activity Diagrams can be used to describe how activities are coordinated to provide a service at different levels of abstraction. The great strength of activity diagrams lies in the fact that they support and encourage parallel behavior. This makes them a great tool for workflow modeling and, in principle, for multithreaded programming. Activity diagrams can also define a link to an object by labeling an activity with an object name or by using swimlanes, which enable an activity diagram to be structured based on responsibilities.

Activity Diagram at a Glance

Before we go into the details of individual notation in activity diagram, let us have a quick look at a very general activity diagram. Here is the example activity diagram for elaborating the business use case - Check-In in Airport:

Activity Diagram Notations

Initial, Final and Flow Final Node

Initial Node (Start State)

· The starting state before an activity takes place is depicted using the initial state.

· A process can have only one initial state unless we are depicting nested activities. We use a black filled circle to depict the initial state of a system.

· The Initial State from the UML Activity Diagram marks the entry point and the initial Activity State.

As you can see in the above program that there is no context-switching because here t1 and t2 will be treated as normal object not thread object.

Design patterns

Design patterns are used to represent some of the best practices adapted by experienced object-oriented software developers. A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples.

Some of the popular design patterns:

Ø Design Patterns (Factory Method)

Ø Observer Pattern (Implementation)

Ø Singleton Design Pattern

Ø Decorator Pattern (Background)

Ø Strategy Pattern

Ø Adapter Pattern

Ø Command Pattern

Ø Iterator Pattern

Ø Curiously recurring template pattern (CRTP)

Ø Flyweight Design Pattern

Ø Facade Design Pattern

Ø Proxy Design Pattern

Ø Composite Design Pattern

Ø Prototype Design Pattern

Ø Abstract Factory Pattern

Ø Bridge Design Pattern

Ø Template Method Design Pattern

Ø Builder Design Pattern

Ø Chain of Responsibility Design Pattern

Singleton Design Pattern | Introduction

Singleton is a part of Gang of Four design pattern and it is categorized under creational design patterns. In this article, we are going to take a deeper look into the usage of the Singleton pattern. It is one of the most simple design pattern in terms of the modelling but on the other hand this is one of the most controversial pattern in terms of complexity of usage.

An implementation of singleton class should have following properties:

1. It should have only one instance : This is done by providing instance of class from within the class. Outer classes or subclasses should be prevented to create the instance. This is done by making the constructor private in java so that no class can access the constructor and hence cannot instantiate it.

2. Instance should be globally accessible : Instance of singleton class should be globally accessible so that each class can use it. In java it is done by making the access-specifier of instance public.

//A singleton class should have public visiblity

//so that complete application can use

public class GFG {

public static GFG instance = new GFG(); //static instance of class globally accessible

private GFG() {

// private constructor so that class

//cannot be instantiated from outside

//this class

}

Important points

Ø Singleton classes can have only one instance and that instance should be globally accessible.

Ø java.lang.Runtime and java.awt.Desktop are 2 singleton classes provided by JVM.

Ø Singleton Design pattern is a type of creational design pattern.

Ø Outer classes should be prevented to create instance of singleton class.

Singleton Class in Java

In object-oriented programming, a singleton class is a class that can have only one object (an instance of the class) at a time.

After first time, if we try to instantiate the Singleton class, the new variable also points to the first instance created. So whatever modifications we do to any variable inside the class through any instance, it affects the variable of the single instance created and is visible if we access that variable through any variable of that class type defined.

To design a singleton class:

1. Make constructor as private.

2. Write a static method that has return type object of this singleton class. Here, the concept of Lazy initialization in used to write this static method.

Normal class vs Singleton class: Difference in normal and singleton class in terms of instantiation is that, For normal class we use constructor, whereas for singleton class we use getInstance() method (Example code:I). In general, to avoid confusion we may also use the class name as method name while defining this method (Example code:II).

class Singleton

{

private static Singleton single_instance = null; // static variable single_instance of type Singleton

public String s; // variable of type String

private Singleton() // private constructor restricted to this class itself

{

s = "Hello I am a string part of Singleton class";

}

public static Singleton getInstance() // static method to create instance of Singleton class

{

if (single_instance == null)

single_instance = new Singleton();

return single_instance;

}

// Driver Class

class Main

{

public static void main(String args[])

{

Singleton x = Singleton.getInstance(); // instantiating Singleton class with variable x

Singleton y = Singleton.getInstance(); // instantiating Singleton class with variable y

Singleton z = Singleton.getInstance();// instantiating Singleton class with variable z

x.s = (x.s).toUpperCase();// changing variable of instance x

System.out.println("String from x is " + x.s);

System.out.println("String from y is " + y.s);

System.out.println("String from z is " + z.s);

System.out.println("\n");

z.s = (z.s).toLowerCase();// changing variable of instance z

System.out.println("String from x is " + x.s);

System.out.println("String from y is " + y.s);

System.out.println("String from z is " + z.s);

}

Output:

String from x is HELLO I AM A STRING PART OF SINGLETON CLASS

String from y is HELLO I AM A STRING PART OF SINGLETON CLASS

String from z is HELLO I AM A STRING PART OF SINGLETON CLASS

String from x is hello i am a string part of singleton class

String from y is hello i am a string part of singleton class

String from z is hello i am a string part of singleton class

Design Patterns (Factory Method)

Factory method is a creational design pattern, i.e., related to object creation. In Factory pattern, we create object without exposing the creation logic to client and the client use the same common interface to create new type of object.

The idea is to use a static member-function (static factory method) which creates & returns instances, hiding the details of class modules from user.

A factory pattern is one of the core design principles to create an object, allowing clients to create objects of a library(explained below) in a way such that it doesn’t have tight coupling with the class hierarchy of the library.

What is meant when we talk about library and clients?

A library is something which is provided by some third party which exposes some public APIs and clients make calls to those public APIs to complete its task. A very simple example can be different kinds of Views provided by Android OS.

Why factory pattern?

Let us understand it with an example:

// A design without factory pattern

#include <iostream>

using namespace std;

// Library classes

class Vehicle {

public:

virtual void printVehicle() = 0;

};

class TwoWheeler : public Vehicle {

public:

void printVehicle() {

cout << "I am two wheeler" << endl;

}

};

class FourWheeler : public Vehicle {

public:

void printVehicle() {

cout << "I am four wheeler" << endl;

}

};

class Client {

public:

Client(int type) {

// Client explicitly creates classes according to type

if (type == 1)

pVehicle = new TwoWheeler();

else if (type == 2)

pVehicle = new FourWheeler();

else

pVehicle = NULL;

}

~Client() {

if (pVehicle)

{

delete[] pVehicle;

pVehicle = NULL;

}

Vehicle* getVehicle() {

return pVehicle;

}

private:

Vehicle *pVehicle;

};

// Driver program

int main() {

Client *pClient = new Client(1);

Vehicle * pVehicle = pClient->getVehicle();

pVehicle->printVehicle();

return 0;

}

Write an algorithm which will return a characters string and its parameter will be pointer character array[EGCB-2018]

Accessing values pointed by array of pointers

To access and print the values pointed by the array of pointers we take help of loop as shown in the following example.

#include <stdio.h>

int main(void) {

// array of pointers

char *cityPtr[4] = {

"Chennai",

"Kolkata",

"Mumbai",

"New Delhi"

};

// temporary variable

int r, c;

// print cities

for (r = 0; r < 4; r++) {

c = 0;

while(*(cityPtr[r] + c) != '\0') {

printf("%c", *(cityPtr[r] + c));

c++;

}

printf("\n");

}

return 0;

}

Output:

Chennai

Kolkata

Mumbai

New Delhi

In the above code we are using the r variable to access each row of the pointer. And we are using the c variable to access each character in a selected row.

Abstract Factory Pattern

Abstract Factory design pattern is one of the Creational pattern. Abstract Factory pattern is almost similar to Factory Pattern is considered as another layer of abstraction over factory pattern. Abstract Factory patterns work around a super-factory which creates other factories.

UML class diagram example for the Abstract Factory Design Pattern.

Ø AbstractFactory : Declares an interface for operations that create abstract product objects.

Ø ConcreteFactory : Implements the operations declared in the AbstractFactory to create concrete product objects.

Ø Product : Defines a product object to be created by the corresponding concrete factory and implements the AbstractProduct interface.

Ø Client : Uses only interfaces declared by AbstractFactory and AbstractProduct classes.

Abstract Factory provides interfaces for creating families of related or dependent objects without specifying their concrete classes.

difference between a “factory method” and an “abstract factory”

Ø The main difference between a “factory method” and an “abstract factory” is that the factory method is a single method, and an abstract factory is an object.

Ø The factory method is just a method, it can be overridden in a subclass, whereas the abstract factory is an object that has multiple factory methods on it.

Ø The Factory Method pattern uses inheritance and relies on a subclass to handle the desired object instantiation.

A company have a web based survey system where visitor browse the website login page. Only authorized visitor can access this survey system by using username and password. After login, visitor get a survey form and submit by filling the required information.Now draw the use-case diagram of this web based survey system. [DESCO BUET Asst. Eng 2016]

What is a use case diagram?

In the Unified Modeling Language (UML), a use case diagram can summarize the details of your system's users (also known as actors) and their interactions with the system. To build one, you'll use a set of specialized symbols and connectors. An effective use case diagram can help your team discuss and represent:

· Scenarios in which your system or application interacts with people, organizations, or external systems

· Goals that your system or application helps those entities (known as actors) achieve

· The scope of your system

When to apply use case diagrams

A use case diagram doesn't go into a lot of detail—for example, don't expect it to model the order in which steps are performed. Instead, a proper use case diagram depicts a high-level overview of the relationship between use cases, actors, and systems. Experts recommend that use case diagrams be used to supplement a more descriptive textual use case.

UML is the modeling toolkit that you can use to build your diagrams. Use cases are represented with a labeled oval shape. Stick figures represent actors in the process, and the actor's participation in the system is modeled with a line between the actor and use case. To depict the system boundary, draw a box around the use case itself.

UML use case diagrams are ideal for:

· Representing the goals of system-user interactions

· Defining and organizing functional requirements in a system

· Specifying the context and requirements of a system

· Modeling the basic flow of events in a use case

Basic Use Case Diagram Symbols and Notations

System
Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's boundaries.

Use Case
Draw use cases using ovals. Label the ovals with verbs that represent the system's functions.

Actors
Actors are the users of a system. When one system is the actor of another system, label the actor system with the actor stereotype.

Relationships
Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends" relationship indicates alternative options under a certain use case.

What is Meant by UML?

UML stands for Unified Modeling Language. UML 2.0 helped extend the original UML specification to cover a wider portion of software development efforts including agile practices.

· Improved integration between structural models like class diagrams and behavior models like activity diagrams.

· Added the ability to define a hierarchy and decompose a software system into components and sub-components.

· The original UML specified nine diagrams; UML 2.x brings that number up to 13. The four new diagrams are called: communication diagram, composite structure diagram, interaction overview diagram, and timing diagram. It also renamed statechart diagrams to state machine diagrams, also known as state diagrams.

UML Diagram Tutorial

The key to making a UML diagram is connecting shapes that represent an object or class with other shapes to illustrate relationships and the flow of information and data. To learn more about creating UML diagrams:

Types of UML Diagrams

The current UML standards call for 13 different types of diagrams: class, activity, object, use case, sequence, package, state, component, communication, composite structure, interaction overview, timing, and deployment.

These diagrams are organized into two distinct groups: structural diagrams and behavioral or interaction diagrams.

Structural UML diagrams

· Class diagram

· Package diagram

· Object diagram

· Component diagram

· Composite structure diagram

· Deployment diagram

Behavioral UML diagrams

· Activity diagram

· Sequence diagram

· Use case diagram

· State diagram

· Communication diagram

· Interaction overview diagram

· Timing diagram

Class Diagram
Class diagrams are the backbone of almost every object-oriented method, including UML. The describe the static structure of a system.

Package Diagram
Package diagrams are a subset of class diagrams, but developers sometimes treat them as a separate technique. Package diagrams organize elements of a system into related groups to minimize dependencies between packages.

Object Diagram
Object diagrams describe the static structure of a system at a particular time. They can be used to test class diagrams for accuracy.

Composite Structure Diagram
Composite structure diagrams show the internal part of a class.

Use Case Diagram
Use case diagrams model the functionality of a system using actors and use cases.

Activity Diagram
Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation.

Sequence Diagram
Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

Interaction Overview Diagram
Interaction overview diagrams are a combination of activity and sequence diagrams. They model a sequence of actions and let you deconstruct more complex interactions into manageable occurrences. You should use the same notation on interaction overview diagrams that you would see on an activity diagram.

Timing Diagram
A timing diagram is a type of behavioral or interaction UML diagram that focuses on processes that take place during a specific period of time. They're a special instance of a sequence diagram, except time is shown to increase from left to right instead of top down.

Communication Diagram
Communication diagrams model the interactions between objects in sequence. They describe both the static structure and the dynamic behavior of a system. In many ways, a communication diagram is a simplified version of a collaboration diagram introduced in UML 2.0.

State Diagram
Statechart diagrams, now known as state machine diagrams and state diagrams describe the dynamic behavior of a system in response to external stimuli. State diagrams are especially useful in modeling reactive objects whose states are triggered by specific events.

Component Diagram

Component diagrams describe the organization of physical software components, including source code, run-time (binary) code, and executables.

Deployment Diagram
Deployment diagrams depict the physical resources in a system, including nodes, components, and connections.

UML Diagram Symbols

There are many different types of UML diagrams and each has a slightly different symbol set.

Class diagrams are perhaps one of the most common UML diagrams used and class diagram symbols center around defining attributes of a class. For example, there are symbols for active classes and interfaces. A class symbol can also be divided to show a class's operations, attributes, and responsibilities.

Visibility of any class members are marked by notations of

Lines are also important symbols to denote relationships between components. Generalization and Inheritance are denoted with empty arrowheads. Composition is shown with a filled in diamond. Aggregation is shown with an empty diamond. Dependencies are marked with a dashed line with an arrow. Using <<>> allows you to indicate properties of that dependency. Multiplicity is usually shown with a number at one end of the arrow and a * at the other.

Package diagrams have symbols defining a package that look like a folder.

Activity diagrams have symbols for activities, states, including separate symbols for an initial state and a final state. The control flow is usually shown with an arrow and the object flow is shown with a dashed arrow.

Use case diagrams have symbols for actors and use cases.

Why Do We Use UML?

A complex enterprise application with many collaborators will require a solid foundation of planning and clear, concise communication among team members as the project progresses.

Visualizing user interactions, processes, and the structure of the system you're trying to build will help save time down the line and make sure everyone on the team is on the same page.

UML Diagram Examples

The best way to understand UML is to look at some examples of UML diagrams.

Click on any of these UML diagrams included in SmartDraw and edit them:

RAD model phase [Madrasha board -2018]

RAD model distributes the analysis, design, build and test phases into a series of short, iterative development cycles.Following are the various phases of the RAD Model −

1. Business Modeling

The business model for the product under development is designed in terms of flow of information and the distribution of information between various business channels..

2. Data Modeling

The information gathered in the Business Modeling phase is reviewed and analyzed to form sets of data objects vital for the business

3. Process Modeling

The data object sets defined in the Data Modeling phase are converted to establish the business information flow needed to achieve specific business objectives as per the business model. The process model for any changes or enhancements to the data object sets is defined in this phase.

4. Application Generation

The actual system is built and coding is done by using automation tools to convert process and data models into actual prototypes.

5. Testing and Turnover

The overall testing time is reduced in the RAD model as the prototypes are independently tested during every iteration. However, the data flow and the interfaces between all the components need to be thoroughly tested with complete test coverage.

The following illustration describes the RAD Model in detail.

Verification testing runs the system in a simulated environment using simulated data.
– Alpha testing
– Simulated environment using simulated data
– Checks for errors and omissions regarding end-use and design specifications

Validation testing runs the system in a live environment
using real data.
– Beta testing
– Live environment using real data
– Testing:
• Systems performance (throughput and response time)
• Systems performance (throughput and response time)
• Peak workload performance
• Human engineering
• Methods and procedures
• Backup and recovery

Activity Diagram [Modeling System Workflows]

u Use the bridge pattern when

l you want to avoid permanent binding between an abstraction and implementation; this might be the case when, for example, the implementation must be selected or switched at run time

l both the abstractions and implementations should be extensible by subclassing

l changes in implementation should have to impact on clients

l you want to hide implementation from clients

l you want to share an implementation among multiple objects

Bridge pattern - structure

Factory Method pattern Structure

Pert chart(find critical path & projected time) [BUET M.SC Admission -2015]

What is a 'PERT Chart'?

A PERT chart is a project management tool that provides a graphical representation of a project's timeline. PERT, or Program Evaluation Review Technique, breaks down the individual tasks of a project for analysis. Although PERT charts are preferable to Gantt charts because they identify task dependencies, PERT charts are often more difficult to interpret.

PERT charts are used for complex projects, and they were created for use by the U.S. Navy in 1958. Below is an example of a PERT chart.

What is the critical path method (CPM)?

The critical path method, also known as CPM, can be a helpful tool to use to better schedule and manage complex projects and the amount of time individual tasks may require. The CPM designates the specific order and sequence of actions that inevitably determines the duration of the project you’re scoping out. This is especially useful in managing projects with areas of overlap, long time-consumption, or even delay because you can approach the scheduling of a project on a separate task basis, visualize them in a flowchart, and then get a near exact estimate on the duration each individual task will require. In many cases, project managers choose to combine PERT and CRM so they can better visualize every task, where they fall into order, and how long they are expected to take.

Source:

Tutorial point- https://www.tutorialspoint.com/

Java T point- https://www.javatpoint.com/

Geeksforgeeks- https://www.geeksforgeeks.org

Techopedia - https://www.techopedia.com/

guru99- https://www.guru99.com/

techterms - https://techterms.com/

webopedia - https://www.webopedia.com/

study - https://study.com/

wikipedia - https://en.wikipedia.org/\

cprogramming - https://www.cprogramming.com/

w3schools - https://www.w3schools.com