Dr.

BR Ambedkar National Institute of

Technology Jalandhar

SOFTWARE ENGINEERING LABORATORY

CSX- 323
Session: July-Dec 2019

Notesify
A Student’s Assistant in Learning
Rajnish Kumar
17103069

Rubal Khehra
17103074

Rupinderjit Kaur
17103075
 CONTENTS
S.NO. CONTENT DATE REMARKS

1. Feasibility Study Report Version 1

2. Feasibility Study Report Version 2

3. Feasibility Study Report Version 3

Software Requirements Specifications

4.
Document Version 1
Software Requirements Specifications
5.
Document Version 2
Software Requirements Specifications
6.
Document Version 3
7. Introduction to Papyrus

8. Introduction to Eclipse

9. Use-Case Diagram

10. Class Diagram

11. Activity Diagram

12. Sequence Diagrams

13. State Diagrams

14. Collaboration Diagram

15. Data Flow Diagram and Structure Chart

16. COCOMO Model

17. Introduction to GitHub and Bitbucket

7. Papyrus
Eclipse Papyrus provides an integrated, user-consumable environment for editing models
based on UML and other related languages such as SysML.
Papyrus for UML notably features diagram editors for UML 2 diagrams, rich model editing
facilities, and the glue required to integrate with other model-based tools.
It also offers a very advanced support of UML profiles that enables users to define UML-
based domain-specific modeling languages. To complement the UML profiles support,
Papyrus provides very powerful customization mechanisms which can be leveraged to create
user-defined Papyrus perspectives and give it the same look and feel as a native DSL editor.
Papyrus is designed to be easily extensible as it is based on the principle of UML Profiles.
Features include:
Supported diagrams:
 Activity Diagrams – displays the sequence of activities.
 Class Diagrams – shows the building blocks of any object-orientated system.
 Communication Diagrams – an interaction diagram that shows similar information to
sequence diagrams but its primary focus is on object relationships.
 Component Diagrams – illustrates the pieces of software, embedded controllers, etc.,
that will make up a system.
 Composite Structure Diagrams – shows the internal structure of a classifier, including
its interaction points to other parts of the system.
 Deployment Diagrams – models the run-time architecture of a system.
 Interaction Overview Diagrams – a form of activity diagram in which the nodes
represent interaction diagrams. Interaction diagrams can include sequence,
communication, interaction overview and timing diagrams.
 Package Diagrams – used to reflect the organization of packages and their elements.
 Profile Diagrams – structure diagram which describes lightweight extension
mechanism to the UML by defining custom stereotypes, tagged values, and
constraints.
 Object Diagrams – use a subset of the elements of a class diagram in order to
emphasize the relationship between instances of classes at some point in time.
 Sequence Diagrams – a form of interaction diagram which shows objects as lifelines
running down the page, with their interactions over time represented as messages
drawn as arrows from the source lifeline to the target lifeline.
 State Machine Diagrams – models the behavior of a single object, specifying the
sequence of events that an object goes through during its lifetime in response to
events.
 Timing Diagrams – used to display the change in state or value of one or more
elements over time.
 Use Case Diagrams – captures the requirements of a system. Use cases are a way of
communicating with users and other stakeholders what the system is intended to do.
Supported tables:
 Class tree table.
 Generic table.
 Generic tree table.
 Relationship generic matrix.
 View table.
 Option to create a new table from the configurations catalog.
Implemented standards: UML 2.5, SysML 1.1 & 1.4, fUML 1.2.1, ALF 1.0.1, MARTE 1.1,
BPMNProfile 1.0, BMM 1.3, SMM 1.1, PSCS 1.0, PSSM 1.0b, FMI 2.0 and ISO/IEC 42010.

Domain Specific – address any specific domain, every part of Papyrus may be customized:
UML profile, model explorer, diagram notation and style, properties views, palette and
creation menus, and much more.

Papyrus enables model-based techniques: model-based simulation, model-based formal

testing, safety analysis, performance/trade-offs analysis, and architecture exploration.

Modular extensions:
 Papyrus Layers – layers are used to accurately control what is shown by a diagram. A
layer is used to associate some properties (graphical or domain) to some views (class,
package).
 Papyrus DSML Validation – component to generate a validation plug-in from a UML
Profile.
 Moka – a Papyrus module for execution, animation and debugging of UML models.
 Cross-platform support – runs on Linux, Mac OS X, and Windows operating systems.
This is a Java application.
Website: www.eclipse.org/papyrus
8. Eclipse
Eclipse is an integrated development environment (IDE) for Java and other programming
languages like C, C++, PHP, and Ruby etc. Development environment provided by Eclipse
includes the Eclipse Java development tools (JDT) for Java, Eclipse CDT for C/C++, and
Eclipse PDT for PHP, among others.

Eclipse is an integrated development environment (IDE) used in computer programming.[6] It

contains a base workspace and an extensible plug-in system for customizing the environment.
Eclipse is written mostly in Java and its primary use is for developing Java applications, but it
may also be used to develop applications in other programming languages via plug-ins,
including Ada, ABAP, C, C++, C#, Clojure, COBOL, D, Erlang, Fortran, Groovy, Haskell, J
avaScript, Julia, Lasso, Lua, NATURAL, Perl, PHP, Prolog, Python, R, Ruby (including Rub
y on Rails framework), Rust, Scala, and Scheme. It can also be used to develop documents
with LaTeX (via a TeXlipse plug-in) and packages for the software Mathematica.

Development environments include the Eclipse Java development tools (JDT) for Java and
Scala, Eclipse CDT for C/C++, and Eclipse PDT for PHP, among others.

The initial codebase originated from IBM VisualAge. The Eclipse software development
kit (SDK), which includes the Java development tools, is meant for Java developers. Users
can extend its abilities by installing plug-ins written for the Eclipse Platform, such as
development toolkits for other programming languages, and can write and contribute their
own plug-in modules. Since the introduction of the OSGi implementation (Equinox) in
version 3 of Eclipse, plug-ins can be plugged-stopped dynamically and are termed (OSGI)
bundles

Eclipse software development kit (SDK) is free and open-source software, released under the
terms of the Eclipse Public License, although it is incompatible with the GNU General Public
License. It was one of the first IDEs to run under GNU Class Path and it runs without
problems under Iced Tea.
Unified Modelling Language (UML)
Unified Modelling Language (UML) is a general-purpose modelling language. The main aim
of UML is to define a standard way to visualize the way a system has been designed. It is
quite similar to blueprints used in other fields of engineering.
UML is not a programming language; it is rather a visual language. We use UML diagrams
to portray the behaviour and structure of a system. UML helps software engineers,
businessmen and system architects with modelling, design and analysis. The Object
Management Group (OMG) adopted Unified Modelling Language as a standard in 1997. It’s
been managed by OMG ever since. International Organization for Standardization (ISO)
published UML as an approved standard in 2005. UML has been revised over the years and is
reviewed periodically.

Do we really need UML?

 Complex applications need collaboration and planning from multiple teams and hence
require a clear and concise way to communicate amongst them.
 Businessmen do not understand code. So, UML becomes essential to communicate with
non-programmers’ essential requirements, functionalities and processes of the system.
 A lot of time is saved down the line when teams are able to visualize processes, user
interactions and static structure of the system.
UML Diagrams
UML can be used to construct nine different types of diagrams to capture five different
views of a system. Just as a building can be modelled from several views (or perspectives)
such as ventilation perspective, electrical perspective, lighting perspective, heating
perspective, etc.; the different UML diagrams provide different perspectives of the software
system to be developed and facilitate a comprehensive understanding of the system. Such
models can be refined to get the actual implementation of the system.
The UML diagrams can capture the following five views of a system:
• User’s view
• Structural view
• Behavioural view
• Implementation view
• Environmental view
User’s view: This view defines the functionalities (facilities) made available by the system to
its users. The users’ view captures the external users’ view of the system in terms of the
functionalities offered by the system. The users’ view is a black-box view of the system
where the internal structure, the dynamic behaviour of different system components, the
implementation etc. are not visible. The users’ view is very different from all other views in
the sense that it is a functional model compared to the object model of all other views. The
users’ view can be considered as the central view and all other views are expected to conform
to this view. This thinking is in fact the crux of any user centric development style.
Structural view: The structural view defines the kinds of objects (classes) important to the
understanding of the working of a system and to its implementation. It also captures
relationships among the classes (objects). The structural model is also called the static model,
since the structure of a system does not change with time.
Behavioural view: The behavioural view captures how objects interact with each other to
realize the system behaviour. The system behaviour captures the time-dependent (dynamic)
behaviour of the system.
Implementation view: This view captures the important components of the system and their
dependencies.
Environmental view: This view models how the different components are implemented on
different pieces of hardware.
Different diagrams
– Use case diagrams
– Class diagrams
– Object diagrams
– Sequence diagrams
– Collaboration diagrams
– State chart diagrams
– Activity diagrams
– Component diagrams
– Deployment diagrams
9. Use case diagrams
A use case diagram is a dynamic or behaviour diagram in UML. Use case diagrams model
the functionality of a system using actors and use cases. Use cases are a set of actions,
services, and functions that the system needs to perform. In this context, a "system" is
something being developed or operated, such as a web site. The "actors" are people or entities
operating under defined roles within the system.
A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the
different use cases and will often be accompanied by other types of diagrams as well. The use
cases are represented by either circles or ellipses.

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 labelled 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.
USE CASE DIAGRAM OF PROJECT
10. Class diagram
Class diagrams are the main building blocks of every object-oriented methods. The class
diagram can be used to show the classes, relationships, interface, association, and
collaboration. UML is standardized in class diagrams. Since classes are the building block of
an application that is based on OOPs, so as the class diagram has appropriate structure to
represent the classes, inheritance, relationships, and everything that OOPs have in its context.
It describes various kinds of objects and the static relationship in between them.
The main purpose to use class diagrams are:
 This is the only UML which can appropriately depict various aspects of OOPs concept.
 Proper design and analysis of application can be faster and efficient.
 It is base for deployment and component diagram.
its syntax:
 Each class is represented by a rectangle having a subdivision of three compartments
name, attributes and operation.
 There are three types of modifiers which are used to decide the visibility of attributes
and operations.
 + is used for public visibility (for everyone)
 # is used for protected visibility (for friend and derived)
 – is used for private visibility (for only me)
CLASS DIAGRAM OF PROJECT
JAVA CODE GENERATED FROM CLASS DIAGRAM
package Notesify;
import java.util.List;
import java.util.Date;
public abstract class User
{
public Long Phone;
public String UserName;
public String Email;
public Integer UserID;
public String Department;
public String College;
public Boolean MentorshipStatus;
public List<OpenQuery> openQuery;
public List<Answer> answer;
public List<Feedback> feedback;
/**
* Getter of Phone
*/
public Long getPhone() {
return Phone;
}
/**
* Setter of Phone
*/
public void setPhone(Long Phone) {
this.Phone = Phone;
}
/**
* Getter of UserName
*/
public String getUserName() {
return UserName;
}
/**
* Setter of UserName
*/
public void setUserName(String UserName) {
this.UserName = UserName;
}
/**
* Getter of Email
*/
public String getEmail() {
return Email;
}
/**
* Setter of Email
*/
public void setEmail(String Email) {
this.Email = Email;
}
/**
* Getter of UserID
*/
public Integer getUserID() {
return UserID;
}
/**
* Setter of UserID
*/
public void setUserID(Integer UserID) {
this.UserID = UserID;
}
/**
* Getter of Department
*/
public String getDepartment() {
return Department;
}
/**
* Setter of Department
*/
public void setDepartment(String Department) {
this.Department = Department;
}
/**
* Getter of College
*/
public String getCollege() {
return College;
}
/**
* Setter of College
*/
public void setCollege(String College) {
this.College = College;
}
/**
* Getter of MentorshipStatus
*/
public Boolean getMentorshipStatus() {
return MentorshipStatus;
}
/**
* Setter of MentorshipStatus
*/
public void setMentorshipStatus(Boolean MentorshipStatus) {
 this.MentorshipStatus = MentorshipStatus;
}
/**
*
*/
public void Answer_Open_Query() {
// TODO Auto-generated method
}
/**
*
*/
public void Make_Mentor() {
// TODO Auto-generated method
}
/**
*
*/
public void Make_Not_Mentor() {
// TODO Auto-generated method
}
/**
*
*/
public void Rate_Mentor() {
// TODO Auto-generated method
}
/**
*
*/
public void Rate_Public_Answer() {
// TODO Auto-generated method
}
/**
*
*/
public void Post_Comment() {
// TODO Auto-generated method
}
/**
*
*/
public void Rate_Document() {
// TODO Auto-generated method
}
/**
* Getter of openQuery
*/
public List<OpenQuery> getOpenQuery() {
return openQuery;
 }
/**
* Setter of openQuery
*/
public void setOpenQuery(List<OpenQuery> openQuery) {
this.openQuery = openQuery;
}
/**
* Getter of answer
*/
public List<Answer> getAnswer() {
return answer;
}
/**
* Setter of answer
*/
public void setAnswer(List<Answer> answer) {
this.answer = answer;
}
/**
* Getter of feedback
*/
public List<Feedback> getFeedback() {
return feedback;
}
/**
* Setter of feedback
*/
public void setFeedback(List<Feedback> feedback) {
this.feedback = feedback;
}
}
public class Mentor extends User
{
public List<User> Followers;
public String WorkField;
public double Rating;
public List<Document> document;
public List<PrivateQuery> privateQuery;
/**
* Getter of Followers
*/
public List<User> getFollowers() {
return Followers;
}
/**
* Setter of Followers
*/
public void setFollowers(List<User> Followers) {
 this.Followers = Followers;
}
/**
* Getter of WorkField
*/
public String getWorkField() {
return WorkField;
}
/**
* Setter of WorkField
*/
public void setWorkField(String WorkField) {
this.WorkField = WorkField;
}
/**
* Getter of Rating
*/
public double getRating() {
return Rating;
}
/**
* Setter of Rating
*/
public void setRating(double Rating) {
this.Rating = Rating;
}
/**
*
*/
public void Delete_Post() {
// TODO Auto-generated method
}
/**
*
*/
public void Post_Document() {
// TODO Auto-generated method
}
/**
*
*/
public void Answer_Private_Query() {
// TODO Auto-generated method
}
/**
* Getter of document
*/
public List<Document> getDocument() {
return document;
 }
/**
* Setter of document
*/
public void setDocument(List<Document> document) {
this.document = document;
}
/**
* Getter of privateQuery
*/
public List<PrivateQuery> getPrivateQuery() {
return privateQuery;
}
/**
* Setter of privateQuery
*/
public void setPrivateQuery(List<PrivateQuery> privateQuery) {
this.privateQuery = privateQuery;
}
}
public class Alumni extends Mentor
{
public List<String> Projects;
public String Post;
public String Company;
public List<String> getProjects() {
return Projects;
}
/**
* Setter of Projects
*/
public void setProjects(List<String> Projects) {
this.Projects = Projects;
}
/**
* Getter of Post
*/
public String getPost() {
return Post;
}
/**
* Setter of Post
*/
public void setPost(String Post) {
this.Post = Post;
}
/**
* Getter of Company
*/
 public String getCompany() {
return Company;
}
/**
* Setter of Company
*/
public void setCompany(String Company) {
this.Company = Company;
}
}
public class Student extends Mentor
{
public String Course;
public Boolean CR_status = false;
public String Class_;
public List<Mentor> FollowingMentors;
public List<Document> DocsSeen;
public String Class;
public List<Query> query;
public List<PrivateQuery> privateQuery;
public Option option;
public List<Mentor> mentor;
/**
* Getter of Course
*/
public String getCourse() {
return Course;
}
/**
* Setter of Course
*/
public void setCourse(String Course) {
this.Course = Course;
}
/**
* Getter of CR_status
*/
public Boolean getCR_status() {
return CR_status;
}
/**
* Setter of CR_status
*/
public void setCR_status(Boolean CR_status) {
this.CR_status = CR_status;
}
/**
* Getter of Class
*/
 public String get_Class() {
return Class_;
}
/**
* Setter of Class
*/
public void setClass(String Class) {
this.Class_ = Class;
}
/**
* Getter of FollowingMentors
*/
public List<Mentor> getFollowingMentors() {
return FollowingMentors;
}
/**
* Setter of FollowingMentors
*/
public void setFollowingMentors(List<Mentor> FollowingMentors)
{
this.FollowingMentors = FollowingMentors;
}
/**
* Getter of DocsSeen
*/
public List<Document> getDocsSeen() {
return DocsSeen;
}
/**
* Setter of DocsSeen
*/
public void setDocsSeen(List<Document> DocsSeen) {
this.DocsSeen = DocsSeen;
}
/**
*
*/
public void Ask_in_Forum() {
// TODO Auto-generated method
}
/**
*
*/
public void Search_Document() {
// TODO Auto-generated method
}
/**
*
*/
public void Follow_Mentor() {
// TODO Auto-generated method
}
/**
*
*/
public void Vote() {
// TODO Auto-generated method
}
/**
*
*/
public void Ask_Mentor() {
// TODO Auto-generated method
}
/**
* Getter of Class
*/
public String getClass() {
return Class;
}
/**
* Getter of query
*/
public List<Query> getQuery() {
return query;
}
/**
* Setter of query
*/
public void setQuery(List<Query> query) {
this.query = query;
}
/**
* Getter of privateQuery
*/
public List<PrivateQuery> getPrivateQuery() {
return privateQuery;
}
/**
* Setter of privateQuery
*/
public void setPrivateQuery(List<PrivateQuery> privateQuery) {
this.privateQuery = privateQuery;
}
/**
* Getter of option
*/
public Option getOption() {
 return option;
}
/**
* Setter of option
*/
public void setOption(Option option) {
this.option = option;
}
/**
* Getter of mentor
*/
public List<Mentor> getMentor() {
return mentor;
}
/**
* Setter of mentor
*/
public void setMentor(List<Mentor> mentor) {
this.mentor = mentor;
}
}
public class ClassRepresentative extends Student
{
public List<PollQuestion> pollQuestion;
public void Create_Poll() {
// TODO Auto-generated method
}
public void See_Poll_Result() {
// TODO Auto-generated method
}
/**
* Getter of pollQuestion
*/
public List<PollQuestion> getPollQuestion() {
return pollQuestion;
}
/**
* Setter of pollQuestion
*/
public void setPollQuestion(List<PollQuestion> pollQuestion) {
this.pollQuestion = pollQuestion;
}
}
public class Document
{
public Integer AuthorID;
public List<Comment> Comments;
public String DocLink;
public String Ttitle;
public double Rating;
public String Format;
public Date Post_Date;
public Integer DocID;
/**
* Getter of AuthorID
*/
public Integer getAuthorID() {
return AuthorID;
}
/**
* Setter of AuthorID
*/
public void setAuthorID(Integer AuthorID) {
this.AuthorID = AuthorID;
}
/**
* Getter of Comments
*/
public List<Comment> getComments() {
return Comments;
}
/**
* Setter of Comments
*/
public void setComments(List<Comment> Comments) {
this.Comments = Comments;
}
/**
* Getter of DocLink
*/
public String getDocLink() {
return DocLink;
}
/**
* Setter of DocLink
*/
public void setDocLink(String DocLink) {
this.DocLink = DocLink;
}
/**
* Getter of Ttitle
*/
public String getTtitle() {
return Ttitle;
}
/**
* Setter of Ttitle
*/
public void setTtitle(String Ttitle) {
this.Ttitle = Ttitle;
}
/**
* Getter of Rating
*/
public double getRating() {
return Rating;
}
/**
* Setter of Rating
*/
public void setRating(double Rating) {
this.Rating = Rating;
}
/**
* Getter of Format
*/
public String getFormat() {
return Format;
}
/**
* Setter of Format
*/
public void setFormat(String Format) {
this.Format = Format;
}
/**
* Getter of Post_Date
*/
public Date getPost_Date() {
return Post_Date;
}
/**
* Setter of Post_Date
*/
public void setPost_Date(Date Post_Date) {
this.Post_Date = Post_Date;
}
/**
* Getter of DocID
*/
public Integer getDocID() {
return DocID;
}
/**
* Setter of DocID
*/
public void setDocID(Integer DocID) {
 this.DocID = DocID;
}
}
public class Query
{
public Date PostDate;
public String Ques;
public User Asker;
/**
* Getter of PostDate
*/
public Date getPostDate() {
return PostDate;
}
/**
* Setter of PostDate
*/
public void setPostDate(Date PostDate) {
this.PostDate = PostDate;
}
/**
* Getter of Ques
*/
public String getQues() {
return Ques;
}
/**
* Setter of Ques
*/
public void setQues(String Ques) {
this.Ques = Ques;
}
/**
* Getter of Asker
*/
public User getAsker() {
return Asker;
}
/**
* Setter of Asker
*/
public void setAsker(User Asker) {
this.Asker = Asker;
}
}
public class PrivateQuery extends Query
{
public Mentor AskedFrom;
public String Reply;
 /**
* Getter of AskedFrom
*/
public Mentor getAskedFrom() {
return AskedFrom;
}
/**
* Setter of AskedFrom
*/
public void setAskedFrom(Mentor AskedFrom) {
this.AskedFrom = AskedFrom;
}
/**
* Getter of Reply
*/
public String getReply() {
return Reply;
}
/**
* Setter of Reply
*/
public void setReply(String Reply) {
this.Reply = Reply;
}
}
public class OpenQuery extends Query
{
public List<Answer> Answers;
public List<Answer> answer;
/**
* Getter of Answers
*/
public List<Answer> getAnswers() {
return Answers;
}
/**
* Setter of Answers
*/
public void setAnswers(List<Answer> Answers) {
this.Answers = Answers;
}
/**
* Getter of answer
*/
public List<Answer> getAnswer() {
return answer;
}
/**
* Setter of answer
 */
public void setAnswer(List<Answer> answer) {
this.answer = answer;
}
}
public class Answer
{
public String Ans;
public User Author;
public Date PostDate;
private double Rating;
public List<Comment> Comments;
/**
* Getter of Ans
*/
public String getAns() {
return Ans;
}
/**
* Setter of Ans
*/
public void setAns(String Ans) {
this.Ans = Ans;
}
/**
* Getter of Author
*/
public User getAuthor() {
return Author;
}
/**
* Setter of Author
*/
public void setAuthor(User Author) {
this.Author = Author;
}
/**
* Getter of PostDate
*/
public Date getPostDate() {
return PostDate;
}
/**
* Setter of PostDate
*/
public void setPostDate(Date PostDate) {
this.PostDate = PostDate;
}
/**
 * Getter of Rating
*/
public double getRating() {
return Rating;
}
/**
* Setter of Rating
*/
public void setRating(double Rating) {
this.Rating = Rating;
}
/**
* Getter of Comments
*/
public List<Comment> getComments() {
return Comments;
}
/**
* Setter of Comments
*/
public void setComments(List<Comment> Comments) {
this.Comments = Comments;
}
}
public class PollQuestion
{
public Integer Poll_ID;
/**
* Options
*/
public List<Option> Options;
public String Ques;
public List<Option> option;
/**
* Getter of Poll_ID
*/
public Integer getPoll_ID() {
return Poll_ID;
}
/**
* Setter of Poll_ID
*/
public void setPoll_ID(Integer Poll_ID) {
this.Poll_ID = Poll_ID;
}
/**
* Getter of Options
*/
public List<Option> getOptions() {
 return Options;
}
/**
* Setter of Options
*/
public void setOptions(List<Option> Options) {
this.Options = Options;
}
/**
* Getter of Ques
*/
public String getQues() {
return Ques;
}
/**
* Setter of Ques
*/
public void setQues(String Ques) {
this.Ques = Ques;
}
/**
* Getter of option
*/
public List<Option> getOption() {
return option;
}
/**
* Setter of option
*/
public void setOption(List<Option> option) {
this.option = option;
}
}
public class Option
{
public String Value;
public Boolean Status;
public Integer VoteCount = 0;
/**
* Getter of Value
*/
public String getValue() {
return Value;
}
/**
* Setter of Value
*/
public void setValue(String Value) {
this.Value = Value;
 }
/**
* Getter of Status
*/
public Boolean getStatus() {
return Status;
}
/**
* Setter of Status
*/
public void setStatus(Boolean Status) {
this.Status = Status;
}
/**
* Getter of VoteCount
*/
public Integer getVoteCount() {
return VoteCount;
}
/**
* Setter of VoteCount
*/
public void setVoteCount(Integer VoteCount) {
this.VoteCount = VoteCount;
}
}
public class Feedback
{
public Date Post_Date;
public List<String> Suggestion;
public Integer UserID;
/**
* Getter of Post_Date
*/
public Date getPost_Date() {
return Post_Date;
}
/**
* Setter of Post_Date
*/
public void setPost_Date(Date Post_Date) {
this.Post_Date = Post_Date;
}
/**
* Getter of Suggestion
*/
public List<String> getSuggestion() {
return Suggestion;
}
 /**
* Setter of Suggestion
*/
public void setSuggestion(List<String> Suggestion) {
this.Suggestion = Suggestion;
}
/**
* Getter of UserID
*/
public Integer getUserID() {
return UserID;
}
/**
* Setter of UserID
*/
public void setUserID(Integer UserID) {
this.UserID = UserID;
}
}
public class Comment
{
public Document CommentedOn;
public Date Post_Date;
public User Author;
public Document document;
public Answer answer;
/**
* Getter of CommentedOn
*/
public Document getCommentedOn() {
return CommentedOn;
}
/**
* Setter of CommentedOn
*/
public void setCommentedOn(Document CommentedOn) {
this.CommentedOn = CommentedOn;
}
/**
* Getter of Post_Date
*/
public Date getPost_Date() {
return Post_Date;
}
/**
* Setter of Post_Date
*/
public void setPost_Date(Date Post_Date) {
this.Post_Date = Post_Date;
 }
/**
* Getter of Author
*/
public User getAuthor() {
return Author;
}
/**
* Setter of Author
*/
public void setAuthor(User Author) {
this.Author = Author;
}
/**
* Getter of document
*/
public Document getDocument() {
return document;
}
/**
* Setter of document
*/
public void setDocument(Document document) {
this.document = document;
}
/**
* Getter of answer
*/
public Answer getAnswer() {
return answer;
}
/**
* Setter of answer
*/
public void setAnswer(Answer answer) {
this.answer = answer;
}
}
11. Activity diagram
Activity diagram is defined as a UML diagram that focuses on the execution and flow of the
behaviour of a system instead of implementation. It is also called object-oriented flowchart.
Activity diagrams consist of activities that are made up of actions which apply to behavioural
modelling technology.

Components of Activity Diagram

1. Activities

It is a behaviour that is divided into one or more actions. Activities are a network of nodes
connected by edges. There can be action nodes, control nodes, or object nodes. Action nodes
represent some action. Control nodes represent the control flow of an activity. Object nodes
are used to describe objects used inside an activity. Edges are used to show a path or a flow
of execution. Activities start at an initial node and terminate at a final node.

2. Activity partition/swim lane

An activity partition or a swim lane is a high-level grouping of a set of related actions. A

single partition can refer to many things, such as classes, use cases, components, or
interfaces.

If a partition cannot be shown clearly, then the name of a partition is written on top of the
name of an activity.

3. Activity Diagram Notations

Activity diagrams symbol can be generated by using the following notations:

 Initial states: The starting stage before an activity takes place is depicted as the initial
state
 Final states: The state which the system reaches when a specific process ends is
known as a Final State
 State or an activity box:
 Decision box: It is a diamond shape box which represents a decision with alternate
paths. It represents the flow of control.
ACTIVITY DIAGRAM OF PROJECT
12. Sequence diagrams
A Sequence Diagram is a diagram that shows the interaction among objects as a two-
dimensional chart. The chart is read from top to bottom. Sequence Diagrams are interaction
diagrams that detail how operations are carried out. They capture the interaction between
objects in the context of a collaboration. Sequence Diagrams are time focus and they show
the order of the interaction visually by using the vertical axis of the diagram to represent
time what messages are sent and when.

Purpose of Sequence Diagram

 Model high-level interaction between active objects in a system
 Model the interaction between object instances within a collaboration that realizes a
use case
 Model the interaction between objects within a collaboration that realizes an
operation
 Either model generic interactions (showing all possible paths through the
interaction) or specific instances of an interaction (showing just one path through
the interaction)
Notational description

Actor
 a type of role played by an entity that interacts with the subject (e.g., by exchanging
signals and data)
 external to the subject (i.e., in the sense that an instance of an actor is not a part of the
instance of its corresponding subject).
 represent roles played by human users, external hardware, or other subjects
Lifeline
A lifeline represents an individual participant in the Interaction.
Activations
 A thin rectangle on a lifeline) represents the period during which an element is
performing an operation.
 The top and the bottom of the of the rectangle are aligned with the initiation and the
completion time respectively
Call Message
 A message defines a particular communication between Lifelines of an Interaction.
 Call message is a kind of message that represents an invocation of operation of target
lifeline.

SEQUENCE DIAGRAMS OF PROJECT

13. State diagrams
State machine diagrams are also called as state chart diagrams. State machine diagrams are
used to capture the behaviour of a software system. UML State machine diagrams can be
used to model the behaviour of a class, a subsystem, a package, or even an entire system. It is
also called a State chart or State Transition diagram.

State chart diagrams provide us an efficient way to model the interactions or communication
that occur within the external entities and a system. These diagrams are used to model the
event-based system. A state of an object is controlled with the help of an event.

State chart diagrams are used to describe various states of an entity within the application
system.

There is a total of two types of state machine diagrams:

1. Behavioural state machine

 It captures the behaviour of an entity present in the system.

 It is used to represent the specific implementation of an element.
 The behaviour of a system can be modelled using behavioural state machine
diagrams.

2. Protocol state machine

 These diagrams are used to capture the behaviour of a protocol.

 It represents how the state of protocol changes concerning the event. It also represents
corresponding changes in the system.
 They do not represent the specific implementation of an element .

Notation and Symbol for State Machine

Following are the various notations that are used throughout the state chart diagram. All these
notations, when combined, make up a single diagram.
Initial state

The initial state symbol is used to indicate the beginning of a state machine diagram.

Final state

This symbol is used to indicate the end of a state machine diagram.

Decision box

It contains a condition. Depending upon the result of an evaluated guard condition, a new
path is taken for program execution.

Transition

A transition is a change in one state into another state which is occurred because of some
event. A transition causes a change in the state of an object.

State box

It is a specific moment in the lifespan of an object. It is defined using some condition or a

statement within the classifier body. It is used to represent any static as well as dynamic
situations.

It is denoted using a rectangle with round corners. The name of a state is written inside the
rounded rectangle.

The name of a state can also be placed outside the rectangle. This can be done in case of
composite or submachine states. One can either place the name of a state within the rectangle
or outside the rectangle in a tabular box. One cannot perform both at the same time.

A state can be either active or inactive. When a state is in the working mode, it is active, as
soon as it stops executing and transits into another state, the previous state becomes inactive,
and the current state becomes active.
Types of State

Unified Modelling Language defines three types of states:

 Simple state
o They do not have any substrate.
 Composite state
o These types of states can have one or more than one substrate.
o A composite state with two or more sub states is called an orthogonal state.
 Submachine state
o These states are semantically equal to the composite states.
o Unlike the composite state, we can reuse the submachine states.
STATE DIAGRAM OF PROJECT
14. Collaboration diagrams
A Collaboration Diagram is required to identify how various objects make up the entire
system. They are used to understand the object architecture within a system rather than the
flow of a message in a sequence diagram. An object an entity that has various attributes
associated with it. It is a concept of object-oriented programming. There are multiple objects
present inside an object-oriented system where each object can be associated with any other
object inside the system. Collaboration or communication diagrams are used to explore the
architecture of objects inside the system. The message flow between the objects can be
represented using a collaboration diagram.

Benefits of Collaboration Diagram

 It is also called as a communication diagram.

 It emphasizes the structural aspects of an interaction diagram - how lifeline connects.
 Its syntax is similar to that of sequence diagram except that lifeline don't have tails.
 Messages passed over sequencing is indicated by numbering each message
hierarchically.
 Compared to the sequence diagram communication diagram is semantically weak.
 Object diagrams are special case of communication diagram.
 It allows you to focus on the elements rather than focusing on the message flow as
described in the sequence diagram.
 Sequence diagrams can be easily converted into a collaboration diagram as
collaboration diagrams are not very expressive.
 While modelling collaboration diagrams w.r.t sequence diagrams, some information
may be lost.

COLLABORATION DIAGRAMS OF PROJECT

15. Data flow diagrams
Data-flow design is concerned with designing a series of functional transformations that
convert system inputs into the required outputs. The design is described as data-flow
diagrams. These diagrams show how data flows through a system and how the output is
derived from the input through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded. They
show end-to-end processing. That is the flow of processing from when data enters the system
to where it leaves the system can be traced.

Data-flow design is an integral part of several design methods, and most CASE tools support
data-flow diagram creation. Different ways may use different icons to represent data-flow
diagram entities, but their meanings are similar .

The notation which is used is based on the following symbols:

Data Dictionaries

A data dictionary lists all data elements appearing in the DFD model of a system. The data
items listed contain all data flows and the contents of all data stores looking on the DFDs in
the DFD model of a system.
A data dictionary lists the objective of all data items and the definition of all composite data
elements in terms of their component data items. For example, a data dictionary entry may
contain that the data grossPay consists of the parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the
following reasons:

o A Data dictionary provides a standard language for all relevant information for use by
engineers working in a project. A consistent vocabulary for data items is essential
since, in large projects, different engineers of the project tend to use different terms to
refer to the same data, which unnecessarily causes confusion.
o The data dictionary provides the analyst with a means to determine the definition of
various data structures in terms of their component elements.
Structured Charts
It partitions a system into block boxes. A Black box system that functionality is known to the
user without the knowledge of internal design. Structure Chart represent hierarchical
structure of modules. It breaks down the entire system into lowest functional modules,
describe functions and sub-functions of each module of a system to a greater detail. Structure
Chart partitions the system into black boxes (functionality of the system is known to the users
but inner details are unknown). Inputs are given to the black boxes and appropriate outputs
are generated.
Modules at top level called modules at low level. Components are read from top to bottom
and left to right. When a module calls another, it views the called module as black box,
passing required parameters and receiving results.

It has 3 main parts afferent branch, control branch and efferent branch.

Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules
o The relation between processing modules
o Interaction between modules
o Information passed between modules

The following notations are used in structured chart:

16. Cocomo model
Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e. number of
Lines of Code. It is a procedural cost estimate model for software projects and often used as
a process of reliably predicting the various parameters associated with making a project such
as size, effort, cost, time and quality. It was proposed by Barry Boehm in 1970 and is based
on the study of 63 projects, which make it one of the best-documented models.
The key parameters which define the quality of any software products, which are also an
outcome of the Cocomo are primarily Effort & Schedule:
 Effort: Amount of labour that will be required to complete a task. It is measured in
person-months units.
 Schedule: Simply means the amount of time required for the completion of the job,
which is, of course, proportional to the effort put. It is measured in the units of time
such as weeks, months.
Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of constant to be
used in subsequent calculations. These characteristics pertaining to different system types are
mentioned below.
Boehm’s definition of organic, semidetached, and embedded systems:
1. Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and
also the team members have a nominal experience regarding the problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team-size, experience, knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as
Semi-Detached are comparatively less familiar and difficult to develop compared to the
organic ones and require more experience and better guidance and creativity. E.g.:
Compilers or different Embedded Systems can be considered of Semi-Detached type.
3. Embedded – A software project with requiring the highest level of complexity,
creativity, and experience requirement fall under this category. Such software requires a
larger team size than the other two models and also the developers need to be
sufficiently experienced and creative to develop such complex models.

For three product categories, Bohme provides a different set of expression to predict effort (in
a unit of person month) and development time from the size of estimation in KLOC (Kilo
Line of code) efforts estimation takes into account the productivity loss due to holidays,
weekly off, coffee breaks, etc. According to Boehm, software cost estimation should be done
through three stages:

According to Boehm, software cost estimation should be done through three stages:

1. Basic Model
2. Intermediate Model
3. Detailed Model
1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the
project parameters. The following expressions give the basic COCOMO estimation model:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months

Where

KLOC is the estimated size of the software product indicate in Kilo Lines of Code,

a1, a2, b1, b2 are constants for each group of software products,

Tdev is the estimated time to develop the software, expressed in months,

Effort is the total effort required to develop the software product, expressed in person
months (PMs).

Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based on the
code size are shown below:

Organic: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: Effort = 3.0(KLOC) 1.12 PM

Embedded: Effort = 3.6(KLOC) 1.20 PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development time
based on the effort are given below:

Organic: Tdev = 2.5(Effort) 0.38 Months

Semi-detached: Tdev = 2.5(Effort) 0.35 Months

Embedded: Tdev = 2.5(Effort) 0.32 Months

Some insight into the basic COCOMO model can be obtained by plotting the estimated
characteristics for different software sizes. Fig shows a plot of estimated effort versus product
size. From fig, we can observe that the effort is somewhat superliner in the size of the
software product. Thus, the effort required to develop a product increases very rapidly with
project size.

The development time versus the product size in KLOC is plotted in fig. From fig it can be
observed that the development time is a sub linear function of the size of the product, i.e.
when the size of the product increases by two times, the time to develop the product does not
double but rises moderately. This can be explained by the fact that for larger products, a
larger number of activities which can be carried out concurrently can be identified. The
parallel activities can be carried out simultaneously by the engineers. This reduces the time to
complete the project. Further, from fig, it can be observed that the development time is
roughly the same for all three categories of products. For example, a 60 KLOC program can
be developed in approximately 18 months, regardless of whether it is of organic,
semidetached, or embedded type.

From the effort estimation, the project cost can be obtained by multiplying the required effort
by the manpower cost per month. But, implicit in this project cost computation is the
assumption that the entire project cost is incurred on account of the manpower cost alone. In
addition to manpower cost, a project would incur costs due to hardware and software required
for the project and the company overheads for administration, office space, etc.

It is important to note that the effort and the duration estimations obtained using the
COCOMO model are called a nominal effort estimate and nominal duration estimate. The
term nominal implies that if anyone tries to complete the project in a time shorter than the
estimated duration, then the cost will increase drastically. But, if anyone completes the
project over a longer period of time than the estimated, then there is almost no decrease in the
estimated cost value.

2. Intermediate Model: The basic Cocomo model considers that the effort is only a function
of the number of lines of code and some constants calculated according to the various
software systems. The intermediate COCOMO model recognizes these facts and refines the
initial estimates obtained through the basic COCOMO model by using a set of 15 cost drivers
based on various attributes of software engineering.

Classification of Cost Drivers and their attributes:

(I) Product attributes -

o Required software reliability extent

o Size of the application database
o The complexity of the product

Hardware attributes -

o Run-time performance constraints

o Memory constraints
o The volatility of the virtual machine environment
o Required turnabout time

Personnel attributes -

o Analyst capability
 o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

Project attributes -

o Use of software tools

o Application of software engineering methods
o Required development schedule
o Intermediate COCOMO equation:
o E=ai (KLOC) bi*EAF
D=ci (E)di

3. Detailed COCOMO Model: Detailed COCOMO incorporates all qualities of the standard
version with an assessment of the cost drivers effect on each method of the software
engineering process. The detailed model uses various effort multipliers for each cost driver
property. In detailed cocomo, the whole software is differentiated into multiple modules, and
then we apply COCOMO in various modules to estimate effort and then sum the effort.

The Six phases of detailed COCOMO are:

1. Planning and requirements

2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model

Q. Assuming that the size of your project is 200 KLOC. The system is organic. Two pools of
developers are there. The first pool is highly capable but less experienced in the language being
used. The second pool has low-quality developers but experience in the language being used.
Find out the impact of hiring one or another pool. (use intermediate COCOMO model).

System: organic Pool 1 Pool2

Adjustment factor 1.14 0.95
Effort 713.177pm 594.314 p-m
Time of development 30.349m 28.318 m
Staff size 23 persons 20 persons
We should go with first pool as average staff size required is less and also experience in a
language is not that important as capability
17. GitHub
GitHub is a web-based version-control and collaboration platform for software
developers. Microsoft, the biggest single contributor to GitHub, initiated an acquisition of
GitHub for $7.5 billion in June, 2018. GitHub, which is delivered through a software-as-a-
service (SaaS) business model, was started in 2008 and was founded on Git, an open source
code management system created by Linus Torvalds to make software builds faster.

Git is used to store the source code for a project and track the complete history of all changes
to that code. It allows developers to collaborate on a project more effectively by providing
tools for managing possibly conflicting changes from multiple developers. GitHub allows
developers to change, adapt and improve software from its public repositories for free, but it
charges for private repositories, offering various paid plans. Each public or private repository
contains all of a project's files, as well as each file's revision history. Repositories can have
multiple collaborators and can be either public or private.

GitHub facilitates social coding by providing a web interface to the Git code repository and
management tools for collaboration. GitHub can be thought of as a serious social
networking site for software developers. Members can follow each other, rate each other's
work, receive updates for specific projects and communicate publicly or privately.

Three important terms used by developers in GitHub are fork, pull request and merge.
A fork, also known as a branch, is simply a repository that has been copied from one
member's account to another member's account. Forks and branches allow a developer to
make modifications without affecting the original code. If the developer would like to share
the modifications, she can send a pull request to the owner of the original repository. If, after
reviewing the modifications, the original owner would like to pull the modifications into the
repository, she can accept the modifications and merge them with the original repository.
Commits are, by default, all retained and interleaved onto the master project, or can be
combined into a simpler merge via commit squashing.
How to use GitHub?

Because GitHub is so intuitive to use and its version-control tools are so useful for
collaboration, nonprogrammers have also begun to use GitHub to work on document-based
and multimedia projects. GitLab is an open source alternative to GitHub.

GitHub products and features

GitHub offers an on-premises version in addition to the well-known SaaS product. GitHub
Enterprise supports integrated development environments and continuous integration tool
integration, as well as a litany of third-party apps and services. It offers increased security
and auditability than the SaaS version.

Other products and features of note include:

 GitHub Gist allows GitHub users to share pieces of code or other notes.

 GitHub Flow is a lightweight, branch-based workflow for regularly updated

deployments.

 GitHub Pages are static webpages to host a project, pulling information directly from an
individual's or organization's GitHub repository.

 GitHub Desktop enables users to access GitHub from Windows or Mac desktops, rather
than going to GitHub's website.

 GitHub Student Developer Pack is a free offering of developer tools that is limited to
students, and includes cloud resources, programming tools and support, and GitHub
access.
 Bitbucket
Bitbucket is our Git repository management solution designed for professional teams. It gives
you a central place to manage git repositories, collaborate on your source code and guide you
through the development flow. It provides awesome features that include:

 Access control to restrict access to your source code.

 Workflow control to enforce a project or team workflow.
 Pull requests with in-line commenting for collaboration on code review.
 Jira integration for full development traceability.
 Full Rest API to build features custom to your workflow if they are not already available from
our Marketplace

We offer three deployments options for Bitbucket. For an understanding of the basic
differences between these deployment options, you can read our Pros and Cons of Cloud vs.
Server or this article about Server vs. Data Centre.
Hence, the three deployment of Bitbucket offers different features that are summarized in
this features comparison matrix:
Bitbucket Cloud is hosted on Atlassian's servers and accessed via a URL. Bitbucket
Cloud has an exclusive built-in continuous integration tool, Pipelines, that enables you to
build, test and deploy from directly within Bitbucket. You can learn more about Pipelines
features and capabilities here. However, there are some restricted functions in Atlassian Cloud
apps.
Bitbucket Server is hosted on-premise, in your environment. Bitbucket Server does not come
with a built-in testing and deployment tool, but it has strong integrations with Bamboo, our
powerful continuous integration and continuous delivery tool that allows you to completely
automate your build processes. There are also more apps available than for Cloud, and the
license is perpetual.
Bitbucket Data Centre (our Enterprise offering) looks like a single instance of Bitbucket
Server to users, but it is hosted on a number of servers in a cluster on your environment. This
provides important benefits over Bitbucket Server:

 Performance at scale: A cluster of many machines running Bitbucket Server can handle more
load than a single machine.
 High Availability: If one cluster node goes down, then the remaining cluster node(s) can
continue servicing requests so users should see little or no loss of availability.
 Smart mirroring: Smart Mirroring can improve Git clone speeds for distributed teams working
with large repositories.