Abstract Methods and Classes

An abstract class is a class that is declared abstractit may or may not include abstract
methods. Abstract classes cannot be instantiated, but they can be subclassed.
An abstract method is a method that is declared without an implementation (without braces, and
Iollowed by a semicolon), like this:
abstract void moveTo(double deltaX, double deltaY);
I a class includes abstract methods, the class itselI must be declared abstract, as in:
public abstract class GraphicJbject ,
// declare fields
// declare non-abstract methods
abstract void draw();
,


hLLp//www[avabeglnnercom/learn[ava/[avaabsLracLclassandlnLerface


Can Abstract Class have constructors? Can interfaces have constructors?
Abstract class's can have a constructor, but you cannot access it through the object, since you
cannot instantiate abstract class. To access the constructor create a sub class and extend the
abstract class which is having the constructor.
Example
public abstract class AbstractExample
public AbstractExample()
System.out.println("n AbstractExample()");
}
}
public class Test extends AbstractExample
public static void main(String args||)
Test objnew Test();
}
}


&ML Sequence Diagram Tutorial
Wbat is a UML sequence diagram?
& sequence diagrams are used to represent or model the Ilow oI messages, events and actions between the
objects or components oI a system. Time is represented in the vertical direction showing the sequence oI interactions
oI the header elements, which are displayed horizontally at the top oI the diagram.
Sequence Diagrams are used primarily to design, document and validate the architecture, interIaces and logic oI the
system by describing the sequence oI actions that need to be perIormed to complete a task or scenario. &
sequence diagrams are useIul design tools because they provide a dynamic view oI the system behavior which can
be diIIicult to extract Irom static diagrams or speciIications.
Although & sequence diagrams are typically used to describe object-oriented soItware systems, they are also
extremely useIul as system engineering tools to design system architectures, in business process engineering as
process Ilow diagrams, as message sequence charts and call Ilows Ior telecom/wireless system design, and Ior
protocol stack design and analysis.
See also common mistakes to avoid when using sequence diagrams.
Sequence Diagram Drawing Elements
This tutorial describes the basic drawing elements used in sequence diagrams and when they are used. These are the
diagram elements that are supported by the Sequence Diagram Editor tool. Some are not part oI the &
speciIication and may not be supported by other & tools.
Sequence Diagram Header Elements
The header portion oI the sequence diagram represents the components or objects oI the system being modeled and
are laid out horizontally at the top oI the diagram. See an example sequence diagram here.
Actor Represents an external person or entity that
interacts with the system

Cb[ect Represents an object in the system or one of its
components

Dt #epresents a subsystem, component, unit, or other logical entity
in the system (may or may not be implemented by objects)

eparator #epresents an interIace or boundary between subsystems,
components or units (e.g., air interIace, nternet, network)

roup roups related header elements into subsystems
or components

Sequence Diagram Body Elements
Acto #epresents an action taken by an actor, object or unit

Asychroous
Message
An asynchronous message between header elements

ock A block representing a loop or conditional Ior a particular
header element

a Message A call (procedure) message between header elements

reate Message A "create" message that creates a header element
(represented by liIeline going Irom dashed to solid pattern)

estroy Lemet #epresents the destruction oI a header element

estroy Message #epresents the destruction oI a header element as a result
oI a call Irom another element

agram Lk #epresents a portion oI a diagram being treated as a
Iunctional block. Similar to a procedure or Iunction call
that abstracts Iunctionality or details not shown at this
level. Can optionally be linked to another diagram Ior
elaboration.

Lse ock 8epresenLs an else block porLlon of a dlagram block

ow Note Documentation note that is automatically Iormatted to
Ilow aIter previous elements

ree Note Documentation note that is Iree-Ilowing and can be placed
anywhere in the diagram (can also be anchored relative to
a Ilow element)

Message A simple message between header elements

9age reak A page break in the diagram

etur Message A return message between header elements

cearo tart Start oI a scenario (set oI alternatives)

cearo ase Start oI an alternative or case in a scenario

cearo L Lnd of a scenarlo

tate A sLaLe change for a header elemenL

teay tate A sLeady sLaLe ln Lhe sysLem

@mer tart Start oI a timer Ior a particular header element

@mer top Stop oI a timer Ior a particular header element

@mer Lxprato Expiration oI a timer Ior a particular header element

Wbat can be modeled using sequence diagrams?
Sequence diagrams are particularly useIul Ior modeling:
O Complex interactions between components. Sequence diagrams are oIten used to design the interactions
between components oI a system that need to work together to accomplish a task. They are particularly
useIul when the components are being developed in parallel by diIIerent teams (typical in wireless and
telephony systems) because they support the design oI robust interIaces that cover multiple scenarios and
special cases.
O &se case elaboration. &sage scenarios describe a way the system may be used by its actors. The &
sequence diagram can be used to Ilesh out the details oI one or more use cases by illustrating visually how
the system will behave in a particular scenario. The use cases along with their corresponding sequence
diagrams describe the expected behavior oI the system and Iorm a strong Ioundation Ior the development oI
system architectures with robust interIaces.
O Distributed & web-based systems. When a system consists oI distributed components (such as a client
communicating with one or more servers over the nternet), sequence diagrams can be used to document
and validate the architecture, interIaces and logic oI each oI these components Ior a set oI usage scenarios.
O Complex logic. & sequence diagrams are oIten used to model the logic oI a complex Ieature by
showing the interactions between the various objects that collaborate to implement each scenario. odeling
multiple scenarios showing diIIerent aspects oI the Ieature helps developers take into account special cases
during implementation.
O State machines. Telecom, wireless and embedded systems make extensive use oI state machine based
designs where one or more state machines communicate with each other and with external entities to
perIorm their work. For example, each task in the protocol stack oI a cellular phone goes through a series
oI states to perIorm actions such as setup a call or register with a new base station. Similarly the call
processing components oI a obile Switching Center use state machines to control the registration and
transIer oI calls to roaming subscribers. Sequence diagrams (or call Ilows as they are commonly reIerred
to in the telecom and wireless industry) are useIul Ior these types oI applications because they can visually
depict the messages being exchanged between the components and their associated state transitions.
Download Sequence Diagram Editor for a Risk Free 14-day Trial
Benefits of using UML sequence diagrams
These are some oI the main beneIits oI using & sequence diagrams.
1. Help you discover architectural, interface and logic problems early. Because they allow you to Ilesh out
details beIore having to implement anything, sequence diagrams are useIul tools to Iind architectural, interIace and
logic problems early on in the design process. You can validate your architecture, interIaces, state machine and logic
by seeing how the system architecture would handle diIIerent basic scenarios and special cases.
This is particularly true Ior systems involving the interaction oI components that are being implemented in parallel
by diIIerent teams. n the cell phone example, each task would typically be implemented by a separate
team. Having a set oI sequence diagrams describing how the interIaces are actually used and what messages/actions
are expected at diIIerent times gives each team a consistent and robust implementation plan. You can also document
how special cases should be handled across the entire system.
The very act oI creating the sequence diagrams and making them work with your architecture is valuable because it
Iorces you to think about details such as interIaces, states, message order, assignment oI responsibilities,
timers/timeouts and special/error cases ahead oI time.
. Collaboration tool. Sequence diagrams are valuable collaboration tools during design meetings because they
allow you to discuss the design in concrete terms. You can see the interactions between entities, various proposed
state transitions and alternate courses/special cases on paper as you discuss the design.
n our experience, having a concrete design proposal during design meetings greatly enhances the productivity oI
these meetings even iI the proposed design has problems. You can narrow down the problems and then make
corrections to solve them. The proposal serves as a concrete starting point Ior the discussion and as a place to
capture proposed changes.
Sequence diagram editor makes it so easy to edit your sequence diagrams that you could even make the
corrections in real time during the meeting and instantly see the result oI the changes as you make them.
3. Documentation. Sequence diagrams can be used to document the dynamic view oI the system design at various
levels oI abstraction, which is oIten diIIicult to extract Irom static diagrams or even the complete source code. The
diagrams can abstract much oI the implementation detail and provide a high level view oI system behavior.
One oI our colleagues shared this experience oI joining the soItware team Ior a wireless switching subsystem
component:
"Our component was the primary interIace between the call processing component oI the wireless base station and
the Public Switched Telephone Network and had to support several diIIerent network protocols including T1, E1
and SS7. The previous lead had developed several dozen call Ilows describing the basic messaging and state
transitions Ior common operations such as call setups including mobile and land originated, call teardowns and
Ieatures such as call waiting and three way calling Ior each oI the protocols, since each involved diIIerent states and
messages with the switching component. Iound these diagrams invaluable in helping me learn the soItware,
interIaces and state machine and would reIer to them oIten, even aIter working in the project Ior a couple oI years."


The System Development iIe Cycle Iramework provides a sequence oI activities Ior system
designers and developers to Iollow. t consists oI a set oI steps or phases in which each phase oI
the SDC uses the results oI the previous one.
A Systems Development iIe Cycle (SDC) adheres to important phases that are essential Ior
developers, such as planning, analysis, design, and implementation, and are explained in the
section below. A number oI system development liIe cycle (SDC) models have been created:
waterIall, Iountain, spiral, build and Iix, rapid prototyping, incremental, and synchronize and
stabilize. The oldest oI these, and the best known, is the waterIall model: a sequence oI stages in
which the output oI each stage becomes the input Ior the next. These stages can be characterized
and divided up in diIIerent ways, including the Iollowing
|6|
:
O 9ro[ect pag feasbty stuy LsLabllshes a hlghlevel vlew of Lhe lnLended pro[ecL and
deLermlnes lLs goals
O ystems aayss requremets efto ueflnes pro[ecL goals lnLo deflned funcLlons and
operaLlon of Lhe lnLended appllcaLlon Analyzes enduser lnformaLlon needs
O ystems esg uescrlbes deslred feaLures and operaLlons ln deLall lncludlng screen layouLs
buslness rules process dlagrams pseudocode and oLher documenLaLlon
O mpemetato 1he real code ls wrlLLen here
O tegrato a testg 8rlngs all Lhe pleces LogeLher lnLo a speclal LesLlng envlronmenL Lhen
checks for errors bugs and lnLeroperablllLy
O Acceptace staato epoymet 1he flnal sLage of lnlLlal developmenL where Lhe
sofLware ls puL lnLo producLlon and runs acLual buslness
O Mateace WhaL happens durlng Lhe resL of Lhe sofLwares llfe changes correcLlon
addlLlons moves Lo a dlfferenL compuLlng plaLform and more 1hls Lhe leasL glamorous and
perhaps mosL lmporLanL sLep of all goes on seemlngly forever
hLLp//wwwsequencedlagramedlLorcom/uml/sequencedlagramhLmhLLp//wwwrLLcambsnlcoln/




n systems engineering and requirements engineering, a non-functional requirement is a
requirement that speciIies criteria that can be used to judge the operation oI a system, rather than
speciIic behaviors. This should be contrasted with Iunctional requirements that deIine speciIic
behavior or Iunctions. The plan Ior implementing 1unctional requirements is detailed in the
system design. The plan Ior implementing non-1unctional requirements is detailed in the system
architecture.
n general, Iunctional requirements deIine what a system is supposed to do whereas non-
Iunctional requirements deIine how a system is supposed to be. Functional requirements are
usually in the Iorm oI "system shall do requirement~", while non-Iunctional requirements are
"system shall be requirement~".
Non-Iunctional requirements are oIten called qualities oI a system. Other terms Ior non-
Iunctional requirements are "constraints", "quality attributes", "quality goals", "quality oI service
requirements" and "non-behavioral requirements".
|1|
Qualities, that is non-Iunctional
requirements, can be divided into two main categories:
1 LxecuLlon quallLles such as securlLy and usablllLy whlch are observable aL run Llme
2 LvoluLlon quallLles such as LesLablllLy malnLalnablllLy exLenslblllLy and scalablllLy whlch are
embodled ln Lhe sLaLlc sLrucLure of Lhe sofLware sysLem
23

ontents
hlde
O 1 Lxamples
O 2 See also
O 3 8eferences
O 4 LxLernal llnks
edit] Examples
A system may be required to present the user with a display oI the number oI records in a
database. This is a Iunctional requirement. How up-to-date this number needs to be is a non-
Iunctional requirement. I the number needs to be updated in real time, the system architects
must ensure that the system is capable oI updating the displayed record count within an
acceptably short interval oI the number oI records changing.
SuIIicient network bandwidth may also be a non-Iunctional requirement oI a system.
Other examples:
O AccesslblllLy
O AudlL and conLrol
O AvallablllLy (see servlce level agreemenL)
O 8ackup
O CapaclLy currenL and forecasL
O CerLlflcaLlon
O Compllance
O ConflguraLlon managemenL
O uependency on oLher parLles
O ueploymenL
O uocumenLaLlon
O ulsasLer recovery
O Lfflclency (resource consumpLlon for glven load)
O LffecLlveness (resulLlng performance ln relaLlon Lo efforL)
O LmoLlonal facLors (llke fun or absorblng)
O LnvlronmenLal proLecLlon
O Lscrow
O LxplolLablllLy
O LxLenslblllLy (addlng feaLures and carryforward of cusLomlzaLlons aL nexL ma[or verslon
upgrade)
O lallure managemenL
O Legal and llcenslng lssues or paLenLlnfrlngemenLavoldablllLy
O lnLeroperablllLy
O MalnLalnablllLy
O ModlflablllLy
O neLwork Lopology
O Cpen source
O CperablllLy
O erformance / response Llme (performance englneerlng)
O laLform compaLlblllLy
O rlce
O rlvacy
O orLablllLy
O CuallLy (eg faulLs dlscovered faulLs dellvered faulL removal efflcacy)
O 8ecovery / recoverablllLy (eg mean Llme Lo recovery M118)
O 8ellablllLy (eg mean Llme beLween fallures M18l)
O 8eporLlng
O 8eslllence
O 8esource consLralnLs (processor speed memory dlsk space neLwork bandwldLh eLc)
O 8esponse Llme
O 8obusLness
O ScalablllLy (horlzonLal verLlcal)
O SecurlLy
O SofLware Lools sLandards eLc CompaLlblllLy
O SLablllLy
O SafeLy
O SupporLablllLy
O 1esLablllLy

8lsk Analysls and managemenL
lL ls a graphlcal represenLaLlon of Lhe rlsk analysls durlng pro[ecL
sk aayss ls a Lechnlque Lo ldenLlfy and assess facLors LhaL may [eopardlze Lhe success of a pro[ecL or
achlevlng a goal




scope
plannlng
schedullng
8lsk managamenL
codlng
lnLragaLe module
LesLlng
llnal pro[ecL
uaLabase
parL