Eclipse

 In the context of computing, Eclipse is an integrated development environment (IDE) for

developing applications using the Java programming language and other programming
languages such as C/C++, Python, PERL, Ruby etc.

 Eclipse is an integrated development environment (IDE) used in computer programming, and

in 2014 was the most widely used Java IDE in one website's poll. 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, JavaScript, Julia,
Lasso, Lua, NATURAL, Perl, PHP, Prolog, Python, R, Ruby (including Ruby 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 Classpath and it runs without
problems under IcedTea.

 Eclipse was inspired by the Smalltalk-based VisualAge family of integrated development

environment (IDE) products. Although fairly successful, a major drawback of the VisualAge
products was that developed code was not in a component-based software engineering model.
Instead, all code for a project was held in a compressed lump (somewhat like a zip file but in
a proprietary format called .dat). Individual classes could not be easily accessed, certainly not
outside the tool. A team primarily at the IBM Cary NC lab developed the new product as a
Java-based replacement.In November 2001, a consortium was formed with a board of
stewards to further the development of Eclipse as open-source software.
 Papyrus

Eclipse Papyrus provides an integrated, user-consumable environment for editing any kind of
EMF model and particularly supporting UML and related modeling languages such as SysML
and MARTE. Papyrus provides diagram editors for EMF-based modeling languages amongst
them UML 2 and SysML and the glue required for integrating these editors (GMF-based or
not) with other MBD and MDSD tools. It also offers a very advanced support of UML profiles
that enables users to define editors for DSLs based on the UML 2 standard and its extension
mechanisms. The main feature of Papyrus regarding this latter point is a set of 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.

Eclipse Papyrus is graphical editing tool for UML 2 as defined by OMG. Eclipse Papyrus
targets to implement 100% of the OMG specification!
Eclipse Papyrus provides editors for all the UML diagrams:

 Class Diagram
 Object Diagram
 Package Diagram
 Composite Structure Diagram
 Component Diagram
 Deployment Diagram
 Profile Diagram
 Use case Diagram
 Activity Diagram
 State machine Diagram
 Communication Diagram
 Sequence Diagram
 Timing Diagram
 Interaction overview Diagram
Eclipse Papyrus provides also a complete support to SysML in order to enable model-based
system engineering. Specific tabular and graphical editors required for SysML are also
provided:

 Block Definition Diagram

 Internal Block Diagram
 Requirement Diagram
 Parametric Diagram
 Requirement table
 Allocation table
Eclipse Papyrus can execute models using a rich and extensible animation and simulation
framework. Also, as graphical modeling is not always the best way for specifying the behavior
of executable models, Eclipse Papyrus provides textual notation edition with syntax highlight,
completion and content assist. It is of course a customizable feature of Eclipse Papyrus.

All the modeling features of Eclipse Papyrus are designed to be customizable and to maximize
reuse. Therefore, should you want to adapt the standard configuration for a specific domain,
notation, modeling practice or use the powerful customization mechanisms of Eclipse Papyrus
to adapt the modeling environment to suit your needs. Many configurations in Eclipse Papyrus
being model-based, the customization can be done live.

 Define your own graphical, textual or tabular notation.

 Filter existing palettes or define your own ones with a model-based configuration.
 Define dedicated properties views to present just the characteristics that are important
to you.
 Read your model with dedicated model explorer structuring and rendering.
 Reuse standard languages or define your own modeling language thanks to the UML
profile editor.

Papyrus is an open-source UML 2 tool based on Eclipse and licensed under the EPL. It has
been developed by the Laboratory of Model Driven Engineering for Embedded Systems (LISE)
which is a part of the French Alternative Energies and Atomic Energy Commission (CEA-
List).
Papyrus can either be used as a standalone tool or as an Eclipse plugin. It provides support for
Domain Specific Languages and SysML. Papyrus is designed to be easily extensible as it is
based on the principle of UML Profiles.
 USE CASE DIAGRAM
A UML use case diagram is the primary form of system/software requirements for a new
software program underdeveloped. Use cases specify the expected behavior (what), and not
the exact method of making it happen (how). Use cases once specified can be denoted both
textual and visual representation (i.e. use case diagram). A key concept of use case modeling
is that it helps us design a system from the end user's perspective.

A use case diagram is usually simple. It does not show the details of the use cases:

 It only summarizes some of the relationships between use cases, actors, and systems.
 It does not show the order in which steps are performed to achieve the goals of each
use case.

Use cases represent only the functional requirements of a system. Other requirements such as
business rules, quality of service requirements, and implementation constraints must be
represented separately, again, with other UML diagrams.

Purpose of Use Case Diagram

Use case diagrams are typically developed in the early stage of development and people often
apply use case modeling for the following purposes:
● Specify the context of a system
● Capture the requirements of a system
● Validate a systems architecture
● Drive implementation and generate test cases
● Developed by analysts together with domain experts

Notation description

Actor
 Someone interacts with use case (system function).
 Named by noun.
 Actor plays a role in the business
 Similar to the concept of user, but a user can play different roles
o A prof. can be instructor and also researcher
o plays 2 roles with two systems
 Actor triggers use case(s).
 Actor has a responsibility toward the system (inputs), and Actor has expectations
from the system (outputs).

Use Case

 System function (process - automated or manual)

 Named by verb + Noun (or Noun Phrase).
 i.e. Do something
 Each Actor must be linked to a use case, while some use cases may not be linked to
actors.
Communication Link

 The participation of an actor in a use case is shown by connecting an actor to a use

case by a solid link.
 Actors may be connected to use cases by associations, indicating that the actor and the
use case communicate with one another using messages.

Boundary of system

 The system boundary is potentially the entire system as defined in the requirements
document.
 For large and complex systems, each module may be the system boundary.
 For example, for an ERP system for an organization, each of the modules such as
personnel, payroll, accounting, etc.
 can form a system boundary for use cases specific to each of these business functions.
 The entire system can span all of these modules depicting the overall system
boundary

Use Case Relationships

Extends

 Indicates that an "Invalid Password" use case may include (subject to specified in the
extension) the behavior specified by base use case "Login Account".
 Depict with a directed arrow having a dotted line. The tip of arrowhead points to the
base use case and the child use case is connected at the base of the arrow.
 The stereotype "<<extends>>" identifies as an extend relationship

Include

 When a use case is depicted as using the functionality of another use case, the
relationship between the use cases is named as include or uses relationship.
 A use case includes the functionality described in another use case as a part of its
business process flow.
 A uses relationship from base use case to child use case indicates that an instance of
the base use case will include the behavior as specified in the child use case.
 An include relationship is depicted with a directed arrow having a dotted line. The tip
of arrowhead points to the child use case and the parent use case connected at the base
of the arrow.
 The stereotype "<<include>>" identifies the relationship as an include relationship.

Generalization

 A generalization relationship is a parent-child relationship between use cases.

 The child use case is an enhancement of the parent use case.
 Generalization is shown as a directed arrow with a triangle arrowhead.
 The child use case is connected at the base of the arrow. The tip of the arrow is
connected to the parent use case.

Fig 1: Use Case Diagram of InsideNITJ

 STATE DIAGRAM

A state diagram is used to represent the condition of the system or part of the system at
finite instances of time. It’s a behavioral diagram and it represents the behavior using finite
state transitions. State diagrams are also referred to as State machines and State-chart
Diagrams. These terms are often used interchangeably. So simply, a state diagram is used to
model the dynamic behavior of a class in response to time and changing external stimuli. We
can say that each and every class has a state but we don’t model every class using State
diagrams. We prefer to model the states with three or more states.

Uses of statechart diagram –

● We use it to state the events responsible for change in state (we do not show
what processes cause those events).
● We use it to model the dynamic behavior of the system .
● To understand the reaction of objects/classes to internal or external stimuli.

Difference between state diagram and flowchart –

The basic purpose of a state diagram is to portray various changes in state of the class and
not the processes or commands causing the changes. However, a flowchart on the other hand
portrays the processes or commands that on execution change the state of class or an object of
the class.

Basic components of a statechart diagram –

 Initial state – We use a black filled circle represent the initial state of a System or a
class.

 Transition – We use a solid arrow to represent the transition or change of control from
one state to another. The arrow is labelled with the event which causes the change in
state.

 State – We use a rounded rectangle to represent a state. A state represents the

conditions or circumstances of an object of a class at an instant of time.

 Fork – We use a rounded solid rectangular bar to represent a Fork notation with
incoming arrow from the parent state and outgoing arrows towards the newly created
states. We use the fork notation to represent a state splitting into two or more concurrent
states.

 Join – We use a rounded solid rectangular bar to represent a Join notation with
incoming arrows from the joining states and outgoing arrow towards the common goal
state. We use the join notation when two or more states concurrently converge into one
on the occurrence of an event or events.

 Self transition – We use a solid arrow pointing back to the state itself to represent a self
transition. There might be scenarios when the state of the object does not change upon
the occurrence of an event. We use self transitions to represent such cases.
 Composite state – We use a rounded rectangle to represent a composite state also.We
represent a state with internal activities using a composite state.

 Final state – We use a filled circle within a circle notation to represent the final state in
a state machine diagram.

Fig 2: State Diagram of InsideNITJ

 ACTIVITY DIAGRAM

We use Activity Diagrams to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. We model sequential and concurrent activities using
activity diagrams. An activity diagram focuses on condition of flow and the sequence in
which it happens.An activity diagram is a behavioral diagram i.e. it depicts the behavior of
a system.

An activity diagram portrays the control flow from a start point to a finish point showing the
various decision paths that exist while the activity is being executed. We can depict both
sequential processing and concurrent processing of activities using an activity diagram.

An activity diagram is very similar to a flowchart.

Difference between an Activity diagram and a Flowchart –

Flowcharts were typically invented earlier than activity diagrams. Non programmers use
Flow charts to model workflows. For example: A manufacturer uses a flow chart to explain
and illustrate how a particular product is manufactured. We can call a flowchart a primitive
version of an activity diagram.

So, programmers use activity diagrams (advanced version of a flowchart) to depict

workflows. An activity diagram is used by developers to understand the flow of programs on
a high level. It also enables them to figure out constraints and conditions that cause particular
events. So an activity diagram helps people on both sides i.e. Businessmen and Developers to
interact and understand systems.

Activity Diagram Notations –

 Initial 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.

 Action or Activity State – An activity represents execution of an action on objects or

by objects. We represent an activity using a rectangle with rounded corners.

 Action Flow or Control flows – They are used to show the transition from one
activity state to another. An activity state can have multiple incoming and outgoing
action flows. We use a line with an arrow head to depict a Control Flow.

 Decision node and Branching – When we need to make a decision before deciding
the flow of control, we use the decision node.The outgoing arrows from the decision
node can be labelled with conditions or guard expressions.It always includes two or
more output arrows.

 Guards – A Guard refers to a statement written next to a decision node on an arrow

sometimes within square brackets.The statement must be true for the control to shift
along a particular direction. Guards help us know the constraints.
  Fork – When we use a fork node when both the activities get executed concurrently
i.e. no decision is made before splitting the activity into two parts. Both parts need to
be executed in case of a fork statement.
We use a rounded solid rectangular bar to represent a Fork notation with incoming
arrow from the parent activity state and outgoing arrows towards the newly created
activities.

 Join – Join nodes are used to support concurrent activities converging into one. For
join notations we have two or more incoming edges and one outgoing edge.

 Merge or Merge Event – Scenarios arise when activities which are not being
executed concurrently have to be merged. We can merge two or more activities into
one if the control proceeds onto the next activity irrespective of the path chosen.

 Swimlanes – Swimlanes group related activities into one column or one row.
Swimlanes can be vertical and horizontal. Swimlanes are used to add modularity to
the activity diagram.They usually give more clarity to the activity diagram. It’s
similar to creating a function in a program. We use a rectangular column to represent
a swimlane.

 Time Event – We can have a scenario where an event takes some time to complete.
We use an hourglass to represent a time event.

 Final State or End State – The state which the system reaches when a particular
process or activity ends is known as a Final State or End State. We use a filled circle
within a circle notation to represent the final state in a state machine diagram. A
system or a process can have multiple final states.

Uses of an Activity Diagram –

● Dynamic modelling of the system or a process.

● Illustrate the various steps involved in a UML use case.
● Model software elements like methods,operations and functions.
● We can use Activity diagrams to depict concurrent activities easily.
● Show the constraints, conditions and logic behind algorithms.
Fig 3: Activity Diagram of InsideNITJ
 CLASS DIAGRAM

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type
of static structure diagram that describes the structure of a system by showing the system's
classes, their attributes, operations (or methods), and the relationships among objects.

Purpose of Class Diagrams

 Shows static structure of classifiers in a system

 Diagram provides a basic notation for other structure diagrams prescribed by UML
 Helpful for developers and other team members too
 Business Analysts can use class diagrams to model systems from a business
perspective

Class Notation

A class notation consists of three parts:

 Class Name
o The name of the class appears in the first partition.
 Class Attributes
o Attributes are shown in the second partition.
o The attribute type is shown after the colon.
o Attributes map onto member variables (data members) in code.
 Class Operations (Methods)
o Operations are shown in the third partition. They are services the class
provides.
o The return type of a method is shown after the colon at the end of the method
signature.
o The return type of method parameters is shown after the colon following the
parameter name.
o Operations map onto class methods in code

Class Relationships
A class may be involved in one or more relationships with other classes. A relationship can
be one of the following types:

Inheritance (or Generalization):

 Represents an "is-a" relationship.

 An abstract class name is shown in italics.
 SubClass1 and SubClass2 are specializations of Super Class.
 A solid line with a hollow arrowhead that point from the child to the parent class
Simple Association:

 A structural link between two peer classes.

 There is an association between Class1 and Class2
 A solid line connecting two classes
Aggregation:
A special type of association. It represents a "part of" relationship.

 Class2 is part of Class1.

 Many instances (denoted by the *) of Class2 can be associated with Class1.
 Objects of Class1 and Class2 have separate lifetimes.
 A solid line with an unfilled diamond at the association end connected to the class of
composite

Composition:
A special type of aggregation where parts are destroyed when the whole is destroyed.

 Objects of Class2 live and die with Class1.

 Class2 cannot stand by itself.
 A solid line with a filled diamond at the association connected to the class of
composite

Dependency:

 Exists between two classes if the changes to the definition of one may cause changes
to the other (but not the other way around).
 Class1 depends on Class2
 A dashed line with an open arrow

Visibility of Class attributes and Operations

In object-oriented design, there is a notation of visibility for attributes and operations. UML
identifies four types of visibility: public, protected, private, and package.

The +, -, # and ~ symbols before an attribute and operation name in a class denote the
visibility of the attribute and operation.

 + denotes public attributes or operations

 - denotes private attributes or operations
 # denotes protected attributes or operations
 ~ denotes package attributes or operations

Multiplicity
How many objects of each class take part in the relationships and multiplicity can be
expressed as:

 Exactly one - 1
 Zero or one - 0..1
 Many - 0..* or *
 One or more - 1..*
 Exact Number - e.g. 3..4 or 6
 Or a complex relationship - e.g. 0..1, 3..4, 6.* would mean any number of objects
other than 2 or 5

Fig 4: Class Diagram of InsideNITJ

 SEQUENCE DIAGRAM

A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place. We can also use the terms event diagrams or
event scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what
order the objects in a system function.

Sequence Diagram Notations –

 Actors – An actor in a UML diagram represents a type of role where it interacts with the
system and its objects. It is important to note here that an actor is always outside the
scope of the system we aim to model using the UML diagram.
We use actors to depict various roles. We represent an actor in a UML diagram using a
stick person notation.

 Lifelines – A lifeline is a named element which depicts an individual participant in a

sequence diagram. So basically each instance in a sequence diagram is represented by a
lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in
UML for naming a lifeline follows the following format – Instance Name : Class Name.
We display a lifeline in a rectangle called head with its name and type. Difference
between a lifeline and an actor – A lifeline always portrays an object internal to the
system whereas actors are used to depict objects external to the system.

 Messages – Communication between objects is depicted using messages. The messages

appear in a sequential order on the lifeline. We represent messages using arrows.

 Synchronous messages – A synchronous message waits for a reply before the

interaction can move forward. The sender waits until the receiver has completed the
processing of the message. The caller continues only when it knows that the receiver has
processed the previous message i.e. it receives a reply message. We use a solid arrow
head to represent a synchronous message.

 Asynchronous Messages – An asynchronous message does not wait for a reply from the
receiver. We use a lined arrow head to represent an asynchronous message.

 Create message – We use a Create message to instantiate a new object in the sequence
diagram. There are situations when a particular message call requires the creation of an
object. It is represented with a dotted arrow and create word labelled on it to specify that
it is the create Message symbol.

 Delete Message – We use a Delete Message to delete an object. When an object is

deallocated memory or is destroyed within the system we use the Delete Message
symbol. It is represented by an arrow terminating with a x.

 Self Message – Certain scenarios might arise where the object needs to send a message
to itself. Such messages are called Self Messages and are represented with a U shaped
arrow.
  Reply Message – Reply messages are used to show the message being sent from the
receiver to the sender. We represent a return/reply message using an open arrowhead
with a dotted line. The interaction moves forward only when a reply message is sent by
the receiver.

 Found Message – A Found message is used to represent a scenario where an unknown

source sends the message. It is represented using an arrow directed towards a lifeline
from an end point.

 Lost Message – A Lost message is used to represent a scenario where the recipient is
not known to the system. It is represented using an arrow directed towards an end point
from a lifeline.

 Guards – To model conditions we use guards in UML. They are used when we need to
restrict the flow of messages on the pretext of a condition being met.

Uses of sequence diagrams –

● Used to model and visualise the logic behind a sophisticated function, operation or
procedure.
● They are also used to show details of UML use case diagrams.
● Used to understand the detailed functionality of current or future systems.

Fig 5: Sequence Diagram of InsideNITJ

 COLLABORATION DIAGRAM

Collaboration diagrams (known as Communication Diagram in UML 2.x) are used to

show how objects interact to perform the behavior of a particular use case, or a part of a use
case. Along with sequence diagrams, collaboration are used by designers to define and clarify
the roles of the objects that perform a particular flow of events of a use case. They are the
primary source of information used to determining class responsibilities and interfaces.

Unlike a sequence diagram, a collaboration diagram shows the relationships among the
objects. Sequence diagrams and collaboration diagrams express similar information, but show
it in different ways.

Because of the format of the collaboration diagram, they tend to better suited for analysis
activities (see Activity: Use-Case Analysis). Specifically, they tend to be better suited to
depicting simpler interactions of smaller numbers of objects. However, if the number of
objects and messages grows, the diagram becomes increasingly hard to read. In addition, it is
difficult to show additional descriptive information such as timing, decision points, or other
unstructured information that can be easily added to the notes in a sequence diagram. So, here
are some use cases that we want to create a collaboration diagram for:

 Model collaborations between objects or roles that deliver the functionalities of use
cases and operations
 Model mechanisms within the architectural design of the system
 Capture interactions that show the messages passing between objects and roles within
the collaboration
 Model alternative scenarios within use cases or operations that involve the
collaboration of different objects and interactions
 Support the identification of objects (hence classes) that participate in use cases
 Each message in a collaboration diagram has a sequence number.
 The top-level message is numbered 1. Messages sent during the same call have the
same decimal prefix but suffixes of 1, 2, etc. according to when they occur.

Notations of Collaboration Diagram

Objects
An object is represented by an object symbol showing the name of the object and its class
underlined, separated by a colon:
Object_name : class_name
You can use objects in collaboration diagrams in the following ways:

 Each object in the collaboration is named and has its class specified
 Not all classes need to appear
 There may be more than one object of a class
 An object’s class can be unspecified. Normally you create a collaboration diagram
with objects first and specify their classes later.
 The objects can be unnamed, but you should name them if you want to discriminate
different objects of the same class.
Actors
Normally an actor instance occurs in the collaboration diagram, as the invoker of the
interaction. If you have several actor instances in the same diagram, try keeping them in the
periphery of the diagram.
 Each Actor is named and has a role
 One actor will be the initiator of the use case
Links
Links connect objects and actors and are instances of associations and each link corresponds
to an association in the class diagram
Links are defined as follows:

 A link is a relationship among objects across which messages can be sent. In

collaboration diagrams, a link is shown as a solid line between two objects.
 An object interacts with, or navigates to, other objects through its links to these
objects.
 A link can be an instance of an association, or it can be anonymous, meaning that its
association is unspecified.
 Message flows are attached to links, see Messages.
Messages
A message is a communication between objects that conveys information with the
expectation that activity will ensue. In collaboration diagrams, a message is shown as a
labeled arrow placed near a link.
 The message is directed from sender to receiver
 The receiver must understand the message
 The association must be navigable in that direction

Fig 6: Collaboration Diagram of InsideNITJ