6 SWE311 Revised Lab Manual

King Fahd University of Petroleum and Minerals
Department of Information and Computer Science

SWE 311: Principles of Software
Engineering
Lab Manual
Introduction and Project
Definition
Executable System
Component
Diagram
Package
Diagram
Deployment
Diagram
Actor A
use-case 1
use-case 2
Actor B
user :
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repository
document : Document
gFile : GrpFile
9: sortByName ( )
L 1: Doc vi ew request ( )
2: fetchDoc( )
5: readDoc ( )
7: readFile ( )
3: create ( )
6: fil lDocument ( )
4: create ( )
8: fil lFile ( )
GrpFile
read( )
open( )
create( )
fillFile( )
rep
Reposit or y
name : char * = 0
readDoc( )
readFile( )
(f rom Persist ence)
FileMgr
fetchDoc( )
sort ByName( )
DocumentList
add( )
delete( )
Document
name : int
docid : int
numField : int
get( )
open( )
close( )
read( )
sort FileList( )
create( )
fillDocument( )
fList
1
FileList
add( )
delete( ) 1
File
r ead( )
read() fill the
code. .
U
MFC
RogueWave
global
DocumentApp
Persistence
Wi ndow95
- .EXE
Windows NT
- .EXE
Wi ndows NT
Windows95
Solaris
-.EXE
Alpha UNX
BM Mainframe
-
Wi ndows95
-
- 95 :
- NT: - - : - -, - - BM : -, -
Document
FileManager
GraphicFile
File
Repository DocumentList
FileList
user
mainWnd fileMgr :
FileMgr
repository document :
Document
gFile
1: Doc vi ew request ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
6: fil lDocument ( )
7: readFile ( )
8: fillFi le ( )
9: sortByName ( )
- .
- - - .
- - .
Customer
name
addr
withdraw()
fetch()
send()
receive()
<<entity
Forward Engineering (Code Generation)
and
Reerse Engineering
penning
Wr iting
Reading Closing
add file numberff ile==MAX
flag FF
ad d file
close f ile
close f ile
use-case 3
Source Code edit! compile! debug! link
"se#Case Diagram Class Diagram
Collaboration Diagram
Se$uence Diagram
State Diagram
Class
2
Soft!are "ngineering #a$ Manual %ICS &'(

#a$ ) Introduction and Project Definition

Objectives
Introduce the la$ environment and tools used in the soft!are
engineering la$) *e$C+ and Synch"ye,
Discuss the Project - learn ho! to !rite project definition,
1. Outline
.etting familiar !ith *e$C+,
.etting familiar !ith Syncron"ye,
Introduction to the la$ plan and o$jectives,
Project definition,
2. Background
+he soft!are engineer is a /ey person analy0ing the $usiness1 identifying
opportunities for improvement1 and designing information systems to implement these
ideas, It is important to understand and develop through practice the s/ills needed to
successfully design and implement ne! soft!are systems,
2.1 Introduction
In this la$ you !ill practice the soft!are development life cycle %project
management1 re2uirements engineering1 systems modeling1 soft!are design1
prototyping1 and testing( using C3S" tools !ithin a team !or/ environment,
UM# notation is covered in this la$ as the modeling language for analysis and
design,
2.2 Tools Used in the Lab
S*" la$ is one of the most challenging of all la$s, Developing a complete
soft!are application re2uires from each of you a good level of /no!4ho! of
various tools,
+here are some tools !hich !ill $e taught1 $ut there are some !hich are
assumed you already /no!1 if you don5t1 then you learn should it individually,
o MS Source Safe) for configuration management
o MS Project) for project planning6management
o 7ational 7ose) for UM# diagrams %o$ject oriented analysis and design(
o 7ational 7e2uisite Pro) for soft!are re2uirement specification %S7S(
documentation,
o 8Unit) for testing soft!are
2.3 Softare !ngineering Lab Objectives
#earn the soft!are life cycle phases %project management1 re2uirements
engineering1 soft!are design1 prototyping and testing(,
Practice the soft!are phases using a project,
#earn a num$er of C3S" tools and use them in a project !ithin a team !or/
environment,
.et familiar !ith UM# %modeling language for analysis and design(,

'
2." Lab #lan
$eek % Lab &ontent 'eliverables Tool
*ee/ 9o la$
*ee/ 2 Introduction and project
definition
*ee/ ' Soft!are process overvie! Configuration management
tool %Source safe(
*ee/ & Project planning Management tool %MS
project(
*ee/ : Soft!are re2uirements and
7e2uisitePro
Plan doc 7e2uirement documentation
tool %7e2uisitePro(
*ee/ ; Introduction to UM# and use
case diagrams
7e2uirement and design tool
%7ational 7ose(
*ee/ < System modeling %DFD and
"7(
Microsoft *ord
*ee/ = Flo! of events and activity
diagram
S7S doc 7ational 7ose
*ee/ > ?? analysis) discovering
classes
7ational 7ose
*ee/ @ Interaction diagrams)
se2uence and colla$oration
diagrams
7ational 7ose
*ee/ Soft!are Design) soft!are
architecture and o$ject4
oriented design
Design doc %ver, ( 7ational 7ose
*ee/ 2 State +ransition Diagram 7ational 7ose
*ee/ ' Component and deployment
diagrams
Design doc %Final
ver,(
7ational 7ose
*ee/ & Soft!are testing +esting tool %8Unit(
*ee/ : Presentations +esting doc and
user manual
3. &(S! Tools
9o tools are used for this la$,
". In)&lass !*a+,le
Some eAamples of pro$lem definition !ill $e presented in the class,
-. !*ercises
Form groups of ' students %!ith one of them as a leader(,
Brainstorm and list : suita$le project titles,
Present these to the class,
Choose one of the projects from your list,
+ry to !rite %a hypothetical( project definition for it,
Present it to the instructor6class,
.. 'eliverables
Form teams of & students for the term project,
Su$mit their IDs1 names1 section $y email !ithin this !ee/,
&
Suggest 6 research a project and !rite a project definition6pro$lem statement,
:
Soft!are Processes and
Cisual Source Safe
2
;
Lab 2/ Softare #rocesses and 0isual Source Safe
Objectives
?$tain a deeper understanding of soft!are process models and soft!are
processes,
Become familiar !ith a configuration management case tool %Microsoft
Cisual Source Safe(,
1. Outline
7evie! of the $asic soft!are process models and soft!are processes,
Cisual Source Safe tutorial,
2. Background
I""" defined a soft!are process as) Da set of activities1 practices and transformations
that people use to develop and maintain soft!are and the associated products1 e,g,1
project plans1 design documents1 code1 test cases and user manualE,
Follo!ing the soft!are process !ill sta$ili0e the development lifecycle and ma/e the
soft!are more managea$le and predicta$le, It !ill also reduce soft!are development
ris/ and help to organi0e the !or/ products that need to $e produced during a
soft!are development project, 3 !ell4managed process !ill produce high 2uality
products on time and under $udget, So follo!ing a mature soft!are process is a /ey
determinant to the success of a soft!are project,
3 num$er of soft!are processes are availa$le, Fo!ever1 no single soft!are process
!or/s !ell for every project, "ach process !or/s $est in certain environments
"Aamples of the availa$le soft!are process models include) the *aterfall model %the
#inear model(1 the evolutionary development1 the formal systems development1 and
reuse4$ased %component4$ased( development, ?ther process models support iterationG
these include) the Incremental model1 the Spiral model1 and "Atreme Programming,

3. &(S! Tools
Cisual Source Safe %CSS( is MicrosoftHs version of a source control program
%configuration management( that ena$les you to /eep trac/ of multiple versions of
documents,
Soft!are Configuration Management is a set of activities that have $een developed to
manage change throughout the life of computer soft!are, +hese activities are
designed to control change $y identifying the !or/ products that are li/ely to change1
esta$lishing relationships among them1 defining mechanisms for managing different
versions of these !or/ products1 controlling the changes imposed and auditing the
reporting on the changes made,
*ith CSS you can go $ac/ to an earlier $ug4free version of the source code to try to
trac/ do!n !here the $ug !as introduced1 compare versions of a document and
recover a copy of the document that you saved !ee/s or months ago,
<
3.1 1o 'oes It $ork2
In order for Cisual Source Safe to manage your documents1 you must first chec/ them
in to CSS, *hen you first chec/ a file in to CSS1 the program records the contents of
this original version, +he document then $ecomes read4only to prevent you from
ma/ing changes that CSS cannot trac/, *hen you !ant to edit a document that is
under source control1 you must chec/ the document out of CSS to get a !rita$le copy,
*hen you are finished editing the document1 you save the document and then chec/ it
$ac/ in to CSS, CSS !ill then contain t!o IversionsI of the document) the original
and the ne! edit, In reality1 CSS does not /eep t!o full copies, It /eeps the original
document1 and a small file descri$ing the differences $et!een the original and the
edited version, If you edit the document @@ times over the course of a year1 you !ill
have access to all @@ versions in CSS1 !ithout having to use all of the dis/ space that
@@ copies of the document !ould occupy,
3.2 $h3 Is It Useful2
CSS lets you vie! any version of your document1 or chec/ out any version for further
editing, It also lets you pic/ any t!o versions44 say1 draft ; and draft '44 and
compare them !ith the Diff utility, +his comparison sho!s the t!o documents side $y
side1 !ith the differences highlighted and color4coded, CSS also ena$les you to attach
comments to each revisionG these comments may or may not appear in the document
itself1 depending on ho! you configure the program, But the comments can $e vie!ed
independently of the documents themselves,
3nother very useful feature of CSS is la$eling, #a$eling provides a simple !ay of
/no!ing !hich versions of !hich documents $elong together in a group, CSS !as
designed for environments in !hich multiple users are editing the same documents, It
permits only one user at a time to edit each document1 there$y guaranteeing that only
one authoritative Ilatest versionI of a document eAists at any given time,
". In)&lass 'e+o
3 demonstration !ill $e given sho! the $asic functions of CSS in order to manage
your files, +hese features include)
a, Creating a ne! project,
$, Chec/ing files in and out,
c, #a$eling files,
d, Cie!ing revision history,
e, Using Diff to sho! differences,
f, Using Search to find documents,
For more information on soft!are processes and CSS tutorial please refer to #a$ 2
slides !hich contain an overvie! of soft!are processes and CSS tutorial slides,
-. !*ercises
Create a project and add some java files to it %at least ' files(,
#a$el the eAisting files,
Chec/ out all the files and modify one of them,
Chec/ the edited file $ac/ in,
Cie! the revision history of the edited file and sho! the differences $et!een
the old and the ne! versions,
=
Search for any unchec/ed in files,
3fter you perform all of the previous tas/s1 create a ne! project for your term project,
If any files of your term project are ready1 you need to chec/ them in, Jou need to
manage all your term project files using Source Safe,
.. 'eliverables
Jou should successfully demonstrate that all the eAercise tas/s !ere implemented,
3lso your CSS project for your term project should $e created and any availa$le files
should $e chec/ed in,
>
Project Planning and
Management
'
@
#a$ ') Project Planning and Management

Objectives
.ain understanding of project management,
#earn ho! to prepare project plans,
#earn a$out project ris/s,
#earn MS Project case tool,
1. Outline
Project !or/ planning,
7is/ management,
MS project,
"Aamples,
2. Background
Project management is the process of planning and controlling the development of a
system !ithin a specified timeframe at a minimum cost !ith the right functionality,
2.1 #roject $ork #lan
Prepare a list of all tas/s in the !or/ $rea/do!n structure1 plus)
Duration of tas/,
Current tas/ status,
+as/ dependencies,
Key milestone dates,
2.2 Tracking #rogress
.antt Chart)
o Bar chart format,
o Useful to monitor project status at any point in time,
P"7+ Chart)
o Flo!chart format,
o Illustrate tas/ dependencies and critical path,
2.3 4isk 5anage+ent
7is/ management is concerned !ith identifying ris/s and dra!ing up plans to
minimi0e their effect on a project,
3 ris/ is a pro$a$ility that some adverse circumstance !ill occur,
Project ris/s !hich affect schedule or resources,
Product ris/s !hich affect the 2uality or performance of the soft!are $eing
developed,
Business ris/s !hich affect the organi0ation developing the soft!are,
2." 4isk 5anage+ent #rocess
7is/ identification) identify project1 product and $usiness ris/s,
7is/ analysis) assess the li/elihood and conse2uences of these ris/s,

7is/ planning) dra! up plans to avoid or minimi0e the effects of the ris/,
7is/ monitoring) monitor the ris/s throughout the project,
3. &(S! Tools
Microsoft Project is the clear mar/et leader among des/top project
management applications,
Primavera Project Planner) multi4project1 multi4user project1 and resource
planning and scheduling,
Sure+ra/ Project Manager) resource planning and control for small4to4medium
si0ed projects,
3ccording to the .artner .roup1 it accounts for a$out t!o4thirds of all project
management soft!are sales,
MS Project 8ump Start #ive Demo
". In)&lass 'e+o
9o! you !ill learn ho! to apply the a$ove mentioned methods to dra! a .antt chart
or 3ctivity chart for the project, Please refer to #a$ ' slides !hich eAplain the process
in detail !ith some eAamples,
-. !*ercises
Use MS Project 2@@2 to create a series of tas/s leading to completion of a project of
your choice,
For your project1 you need to)
Set start or ending dates,
Develop a list of tas/s that need to $e completed,
"sta$lish any su$ tas/s and create lin/s,
Create any lin/s $et!een major tas/s,
3ssign a specific amount time for each tas/,
3ssign resources for each tas/,
Create tas/ information for each item you put into the list,
.. 'eliverables
Jou should su$mit the solutions for the previous eAercises,
Jou should use MS Project to create a plan and time schedule for your term project,
2
Soft!are 7e2uirement
Specification %S7S(
&
'
Lab "/ Softare 4e6uire+ent S,ecification 7S4S8

Objectives
.ain a deeper understanding of the Soft!are 7e2uirement Specification
phase and the Soft!are 7e2uirement Specification %S7S(,
#earn ho! to !rite re2uirements and specifications,
.ain eAposure to re2uirements management using 7e2uisitePro,
1. Outline
7evie! of the re2uirements engineering process,
*rite re2uirements and specifications,
7e2uisitePro tutorial,
Soft!are 7e2uirement Specification %S7S(,
2. Background
3 re2uirement is a statement of a $ehavior or attri$ute that a system must possess for
the system to $e accepta$le to a sta/eholder,
Soft!are 7e2uirement Specification %S7S( is a document that descri$es the
re2uirements of a computer system from the userHs point of vie!, 3n S7S document
specifies)
+he re2uired $ehavior of a system in terms of) input data1 re2uired processing1
output data1 operational scenarios and interfaces,
+he attri$utes of a system including) performance1 security1 maintaina$ility1
relia$ility1 availa$ility1 safety re2uirements and design constraints,
7e2uirements management is a systematic approach to eliciting1 organi0ing and
documenting the re2uirements of a system, It is a process that esta$lishes and
maintains agreement $et!een the customer and the project team on the changing
re2uirements of a system,

7e2uirements management is important $ecause1 $y organi0ing and trac/ing the
re2uirements and managing the re2uirement changes1 you improve the chances of
completing the project on time and under $udget, Poor change management is a /ey
cause of project failure,
2.1 4e6uire+ents !ngineering #rocess
7e2uirements engineering process consists of four phases)
7e2uirements elicitation) getting the customers to state eAactly !hat the
re2uirements are,
7e2uirements analysis) ma/ing 2ualitative judgments and chec/ing for
consistency and feasi$ility of re2uirements,
7e2uirements validation) demonstrating that the re2uirements define the
system that the customer really !ants,
7e2uirements management) the process of managing changing re2uirements
during the re2uirements engineering process and system development1 and
identifying missing and eAtra re2uirements,
&
2.2 $riting 4e6uire+ents
7e2uirements al!ays need to $e correct1 unam$iguous1 complete1 consistent1 and
testa$le,
2.2.1 4eco++endations $hen $riting 4e6uire+ents
9ever assume) others do no! /no! !hat you have in mind,
Use meaningful !ordsG avoid !ords li/e) process1 manage1 perform1 handle1
and support,
State re2uirements not features)
o Feature) general1 tested only for eAistence,
o 7e2uirement) specific1 testa$le1 measura$le,
3void)
o Conjunctions) as/ yourself !hether the re2uirement should it $e split
into t!o re2uirements,
o Conditionals) if1 else1 $ut1 eAcept1 although,
o Possi$ilities) may1 might1 pro$a$ly1 usually,
2.3 $riting S,ecifications
Specification is a description of operations and attri$utes of a system, It can $e a
document1 set of documents1 a data$ase of design information1 a prototype1 diagrams
or any com$ination of these things,
Specifications are different from re2uirements) specifications are sufficiently
complete K not only !hat sta/eholders say they !antG usually1 they have no conflictsG
they descri$e the system as it !ill $e $uilt and resolve any conflicting re2uirements,
Creating specifications is important, Fo!ever1 you may not create specifications if)
Jou are using a very incremental development process %small changes(,
Jou are $uilding research or proof of concept projects,
Jou re$uilding very small projects,
It is not cheaper or faster than $uilding the product,
2." Softare 4e6uire+ent S,ecification 7S4S8
7emem$er that there is no DPerfect S7SE, Fo!ever1 S7S should $e)
Correct) each re2uirement represents something re2uired $y the target system,
Unam$iguous) every re2uirement in S7S has only one interpretation
Complete) everything the target system should do is included in S7S %no
sections are mar/ed +BD4to $e determined(,
Cerifia$le) there eAists some finite process !ith !hich a person6machine can
chec/ that the actual as4$uilt soft!are product meets the re2uirements,
Consistent in $ehavior and terms,
Understanda$le $y customers,
Modifia$le) changes can $e made easily1 completely and consistently,
Design independent) doesnHt imply specific soft!are architecture or algorithm,
Concise) shorter is $etter,
?rgani0ed) re2uirements in S7S are easy to locateG related re2uirements are
together,
:
+racea$le) each re2uirement is a$le to $e referenced for later use %$y the using
paragraph num$ers1 one re2uirement in each paragraph1 or $y using
convention for indication re2uirements(
;
3. &(S! Tools
7e2uisitePro is a po!erful1 easy4to4use re2uirements management tool that helps
teams manage project re2uirements comprehensively1 promotes communication and
colla$oration among team mem$ers1 and reduces project ris/, It there$y increases the
chances of delivering a product that the client !ants and does so in a timely manner,
7e2uisitePro offers the po!er of a data$ase and Microsoft *ord and is integrated
!ith other 7ational Suite products,
". In)&lass 'e+o
3n overvie! of the $asic features of 7e2uisitePro !ill $e presented, In the eAercise
section you !ill practice and apply !hat you have learned in the tutorial, Please refer
to la$ & slides !hich contain a tutorial on 7e2uisitePro and an overvie! of the
re2uirements engineering process1 and !riting re2uirements and specifications,
-. !*ercises
a, 3re the follo!ing re2uirements vagueL If yes1 !hyL Can you fiA themL
o +he feature is responsi$le for managing connections,
o +he feature allo!s users to perform administrative functions,
$, Perform each of the follo!ing tas/s using 7e2uisitePro)
o Create a ne! project,
o Create a ne! pac/age,
o Create and add some re2uirements !ithin 7e2uisitePro,
o Create a re2uirement document,
o Create a ne! vie!,
.. 'eliverables
Jou should su$mit the solutions for eAercise :,a,
Jou should sho! that you have successfully performed all the tas/s listed in
eAercise :,$,
3lso during the re2uirement phase of your term project1 you should use
7e2uisitePro to manage your re2uirements,
<
Introduction to UM# and Use
Case Diagram
:
=
#a$ :) Introduction to UM# and Use Case Diagram

Objectives
M Study the $enefits of visual modeling,
M #earn use case diagrams) discovering actors and discovering use cases,
M Practice use cases diagrams using 7ational 7ose,
1. Outline
Cisual modeling,
Introduction to UM#,
Introduction to visual modeling !ith UM#,
Use case diagrams) discovering actors and use cases,
2. Background
Cisual Modeling is a !ay of thin/ing a$out pro$lems using models organi0ed around
real4!orld ideas, Models are useful for understanding pro$lems1 communicating !ith
everyone involved !ith the project %customers1 domain eAperts1 analysts1 designers1
etc,(1 modeling enterprises1 preparing documentation1 and designing programs and
data$ases
2.1 0isual 5odeling
Capture the structure and $ehavior of architectures and components,
Sho! ho! the elements of the system fit together,
Fide or eApose details appropriate for the tas/,
Maintain consistency $et!een a design and its implementation,
Promote unam$iguous communication,
2.2 $hat is U5L2
+he UM# is the standard language for visuali0ing1 specifying1 constructing and
documenting the artifacts of a soft!are4intensive system, UM# can $e used !ith all
processes throughout the development life cycle and across different implementation
technologies,
2.3 1istor3 of U5L
+he UM# is an attempt to standardi0e the artifacts of analysis and design) semantic
models1 syntactic notation and diagrams, +he first pu$lic draft %version @,=( !as
introduced in ?cto$er >>:, Feed$ac/ from the pu$lic and Ivar 8aco$sonHs input !ere
included in the neAt t!o versions %@,> in 8uly >>; and @,> in ?cto$er >>;(,
Cersion ,@ !as presented to the ?$ject Management .roup %?M.( for
standardi0ation in 8uly >><, 3dditional enhancements !ere incorporated into the ,
version of UM#1 !hich !as presented to the ?M. in Septem$er >><, In 9ovem$er
>><1 the UM# !as adopted as the standard modeling language $y the ?M.,
2." #utting U5L into $ork/ Use &ase 'iagra+
+he $ehavior of the system under development %i,e, !hat functionality must $e
provided $y the system( is documented in a use case model that illustrates the
systemHs intended functions %use cases(1 its surroundings %actors(1 and relationships
$et!een the use cases and actors %use case diagrams(,
>
2.- (ctors
3re 9?+ part of the system N they represent anyone or anything that must
interact !ith the system,
?nly input information to the system,
?nly receive information from the system,
Both input to and receive information from the system,
7epresented in UM# as a stic/man,
2.. Use &ase
3 se2uence of transactions performed $y a system that yields a
measura$le result of values for a particular actor
3 use case typically represents a major piece of functionality
that is complete from $eginning to end, 3 use case must
deliver something of value to an actor,
2.9 Use &ase 4elationshi,s
Bet!een actor and use case,
3ssociation 6 Communication,
3rro! can $e in either or $oth directionsG arro! indicates !ho initiates
communication,
Bet!een use cases %generali0ation()
N Uses
M *here multiple use cases share pieces of same functionality,
N "Atends
M ?ptional $ehavior,
M Behavior only runs under certain conditions %such as alarm(,
M Several different flo!s run $ased on the user5s selection,
3. &(S! Tools
+he 7ational 7ose product family is designed to provide the soft!are developer !ith
a complete set of visual modeling tools for development of ro$ust1 efficient solutions
to real $usiness needs in the client6server1 distri$uted enterprise and real4time systems
environments, 7ational 7ose products share a common universal standard1 ma/ing
modeling accessi$le to nonprogrammers !anting to model $usiness processes as !ell
as to programmers modeling applications logic,
". In)&lass !*a+,le
9o! you !ill learn ho! to apply the a$ove4mentioned methods to dra! use case
diagrams from the pro$lem statement, Please refer to #a$ : slides !hich eAplain the
process in detail !ith some eAamples,

2@
-. !*ercises
4ead carefull3 the folloing ,roble+ state+ent
*e are after a system that controls a recycling machine for returna$le $ottles and
cans, +he machine !ill allo! a customer to return $ottles or cans on the same
occasion,
*hen the customer returns an item1 the system !ill chec/ !hat type has $een
returned, +he system !ill register ho! many items each customer returns and1 !hen
the customer as/s for a receipt1 the system !ill print out !hat he deposited1 the value
of the returned items and the total return sum that !ill $e paid to the customer,
+he system is also $e used $y an operator, +he operator !ants to /no! ho! many
items of each type have $een returned during the day, 3t the end of the day1 the
operator as/s for a printout of the total num$er of items that have $een deposited in
the machine on that particular day, +he operator should also $e a$le to change
information in the system1 such as the deposit values of the items, If something is
amiss1 for eAample if a can gets stuc/ or if the receipt roll is finished1 the operator !ill
$e called $y a special alarm signal,
(fter reading the above ,roble+ state+ent: find/
, (ctors
2, Use cases !ith each actor
', Find e*tended or uses use cases %if applica$le(
&, Finally ) dra! the main use case diagra+)
.. 'eliverables
Jou should use these techni2ues to dra! use case diagrams for your term project
using 7ational 7ose,
2
System Modeling
;
22
#a$ ;) System Modeling

Objective)
Deeper understanding of System modeling)
Data model) entity4relationship diagram %"7D(,
Functional model) data flo! diagram %DFD(,
1. Outline
System analysis model elements)
Data model) entity4relationship diagram %"7D(
Functional model) data flo! diagram %DFD(
2. Background
Modeling consists of $uilding an a$straction of reality, +hese a$stractions are
simplifications $ecause they ignore irrelevant details and they only represent the
relevant details %!hat is relevant or irrelevant depends on the purpose of the model(,
2.1 $h3 5odel Softare2
Soft!are is getting larger1 not smallerG for eAample1 *indo!s OP has more than &@
million lines of code, 3 single programmer cannot manage this amount of code in its
entirety, Code is often not directly understanda$le $y developers !ho did not
participate in the developmentG thus1 !e need simpler representations for compleA
systems %modeling is a mean for dealing !ith compleAity(,
3 !ide variety of models have $een in use !ithin various engineering disciplines for
a long time, In soft!are engineering a num$er of modeling methods are also
availa$le,
2.2 (nal3sis 5odel Objectives
+o descri$e !hat the customer re2uires,
+o esta$lish a $asis for the creation of a soft!are design,
+o define a set of re2uirements that can $e validated once the soft!are is $uilt,
2.3 The !le+ents of the (nal3sis 5odel
+he generic analysis model consists of)
3n entity4relationship diagram %data model(,
3 data flo! diagram %functional model(,
3 state transition diagram %$ehavioral model(,
9?+") state transition diagram !ill $e covered in la$ ,
2'
2.3.1 !ntit3 4elationshi, 'iagra+
3n entity relationship diagram %"7D( is one means of representing the o$jects and
their relationships in the data model for a soft!are product,
"ntity 7elationship diagram notation)
+o create an "7D you need to)
Define Do$jectsE $y underlining all nouns in the !ritten statement of scope)
producers6consumers of data1 places !here data are stored1 and DcompositeE
data items,
Define DoperationsE $y dou$le underlining all active ver$s) processes relevant
to the application and data transformations,
Consider other DservicesE that !ill $e re2uired $y the o$jects,
+hen you need to define the relationship !hich indicates DconnectednessE) a
IfactI that must $e Iremem$eredI $y the system and cannot $e or is not
computed or derived mechanically,
2.3.2 'ata ;lo 'iagra+
3 data flo! data diagram is one means of representing the functional model of a
soft!are product, DFDs do not represent program logic li/e flo!charts do,
Data flo! diagram notation)
"ntity
7elationship
"Aternal entity
Process
Data flo!
Control flo!
Data store
2&
+o create a DFD you need to)
7evie! "7D to isolate data o$jects and grammatical parse to determine
operations,
Determine eAternal entities %producers and consumers of data(,
Create a level @ DFD DConteAt DiagramE %one single process(,
Balance the flo! to maintain data flo! continuity,
Develop a level DFDG use a ): %approA,( eApansion ratio,
Data Flo! Diagram .uidelines)
3ll icons must $e la$eled !ith meaningful names,
3l!ays sho! eAternal entities at level @,
3l!ays la$el data flo! arro!s,
Do not represent procedural logic,
"ach $u$$le is refined until it does just one thing,
3. &(S! Tools
Jou can use MS !ord to create your "7D and DFD since !e do not have a license
for a case tool that supports these diagrams,
". In)&lass !*a+,le
9o! you !ill learn ho! to create "7D and DFD, Please refer to #a$ ; slides !hich
eAplain the process of creating "7D and DFD !ith some eAamples,
-. !*ercises
a, Create an "7D for an airline reservation system,
$, Create a DFD for)
i, Student 7egistration System,
ii, %a P $( Q % c P a Q d(
.. 'eliverables
Jou should create "7D and DFD for your term project if needed, Jou also need to
chec/ them into Source Safe,
2:
Documenting Use Cases and
3ctivity Diagrams
<
2;
#a$ <) Documenting Use Cases and 3ctivity Diagrams

Objectives
Study ho! to document use cases in detail,
Kno! a$out scenarios %flo! of events( and its importance,
Deeper understanding of UM# activity diagrams,
Practicing flo! of events and activity diagrams using 7ational 7ose,
1. Outline
*riting flo! of events,
Flo! of events template and eAample,
3ctivity diagrams,
"Aamples,
2. Background
"ach use case is documented !ith a flo! of events, +he flo! of events for a use case
is a description of the events needed to accomplish the re2uired $ehavior of the use
case, 3ctivity diagrams may also $e created at this stage in the life cycle, +hese
diagrams represent the dynamics of the system, +hey are flo! charts that are used to
sho! the !or/flo! of a systemG that is1 they sho! the flo! of control from one
activity to another in the system1
2.1 ;lo of !vents
3 description of events re2uired to accomplish the $ehavior of the use case1 that)
Sho! *F3+ the system should do1 not F?* the system does it,
*ritten in the language of the domain1 not in terms of implementation,
*ritten from an actor point of vie!,
( flo of events document is created for each use case)
3ctors are eAamined to determine ho! they interact !ith the system,
Brea/ do!n into the most atomic actions possi$le,
2.2 &ontents of ;lo of !vents
*hen and ho! the use case starts and ends,
*hat interaction the use case has !ith the actors,
*hat data is needed $y the use case,
+he normal se2uence of events for the use case,
+he description of any alternate or eAceptional flo!s,
2.3 Te+,late for the flo of events docu+ent
"ach project should use a standard template for the creation of the flo! of events
document, +he follo!ing template seems to $e useful,
O Flo! of events for the RnameS use case
O, Preconditions
O,2 Main flo!
O,' Su$4flo!s %if applica$le(
O,& 3lternative flo!s
!here O is a num$er from to the num$er of use cases,
2<
3 sample completed flo! of events document for the Select Courses to Teach use
case follo!s,
1. ;lo of !vents for the Select &ourses to Teach Use &ase
1.1 #reconditions
Create course offerings su$4flo! of the maintain course information use case must
eAecute $efore this use case $egins,
1.2 5ain ;lo
+his use case $egins !hen the professor logs onto the registration system and enters
his6her pass!ord, +he system verifies that the pass!ord is valid %"4( and prompts the
professor to select the current semester or a future semester %"42(, +he professor
enters the desired semester, +he system prompts the Professor to select the desired
activity) 3DD1 D"#"+"1 7"CI"*1 P7I9+1 or TUI+,
If the activity selected is 3DD1 the S4) add a course offering su$4flo! is performed,
If the activity selected is D"#"+"1 the S42) delete a course offering su$4flo! is
performed,
If the activity selected is 7"CI"*1 the S4') revie! schedule su$4flo! is performed,
If the activity selected is P7I9+1 the S4&) print a schedule su$4flo! is performed,
If the activity selected is TUI+1 the use case ends,
1.3 Sub)flos
S4) 3dd a Course ?ffering)
+he system displays the course screen containing a field for a course name and
num$er, +he professor enters the name and num$er of a course %"4'(, +he system
displays the course offerings for the entered course %"4&(, +he professor selects a
course offering, +he system lin/s the professor to the selected course offering %"4:(,
+he use case then $egins again,
S42) Delete a Course ?ffering)
+he system displays the course offering screen containing a field for a course offering
name and num$er, +he professor enters the name and num$er of a course offering %"4
;(, +he system removes the lin/ to the professor %"4<(, +he use case then $egins
again,
S4') 7evie! a Schedule)
+he system retrieves %"4=( and displays the follo!ing information for all course
offerings for !hich the professor is assigned) course name1 course num$er1 course
offering num$er1 days of the !ee/1 time1 and location, *hen the professor indicates
that he or she is through revie!ing1 the use case $egins again,
S4&) Print a Schedule
+he system prints the professor schedule %"4>(, +he use case $egins again,
2=
1." (lternative ;los
"4) 3n invalid professor ID num$er is entered, +he user can re4enter a professor ID
num$er or terminate the use case,
"42) 3n invalid semester is entered, +he user can re4enter the semester or terminate
the use case,
"4') 3n invalid course name6num$er is entered, +he user can re4enter a valid
name6num$er com$ination or terminate the use case,
"4&) Course offerings cannot $e displayed, +he user is informed that this option is not
availa$le at the current time, +he use case $egins again,
"4:) 3 lin/ $et!een the professor and the course offering cannot $e created, +he
information is saved and the system !ill create the lin/ at a later time, +he use case
continues,
"4;) 3n invalid course offering name6num$er is entered, +he user can re4enter a valid
course offering name6num$er com$ination or terminate the use case,
"4<) 3 lin/ $et!een the professor and the course offering cannot $e removed, +he
information is saved and the system !ill remove the lin/ at a later time, +he use case
continues,
"4=) +he system cannot retrieve schedule information, +he use case then $egins again,
"4>) +he schedule cannot $e printed, +he user is informed that this option is not
availa$le at the current time, +he use case $egins again,
Use case flo! of events documents are entered and maintained in documents eAternal
to 7ational 7ose, +he documents are lin/ed to the use case,
2." (ctivit3 'iagra+s
3ctivity diagrams are flo! charts that are used to sho! the !or/flo! of a system,
+hey also)
7epresent the dynamics of the system,
Sho! the flo! of control from activity to activity in the system,
Sho! !hat activities can $e done in parallel1 and any alternate paths through
the flo!,
3ctivity diagrams may $e created to represent the flo! across use cases or they may
$e created to represent the flo! !ithin a particular use case, #ater in the life cycle1
activity diagrams may $e created to sho! the !or/flo! for an operation,
2.- (ctivit3 'iagra+ <otation
(ctivities) performance of some $ehavior in the !or/flo!,
Transition) passing the flo! of control from activity to activity,
'ecision) sho! !here the flo! of control $ranches $ased on a decision point)
o .uard condition is used to determine !hich path from the decision
point is ta/en,
S3nchroni=ation)!hat activities are done concurrentlyL *hat activities must
$e completed $efore processing may continue %join(,
2>
3. &(S! Tools
7ational 7ose %introduced in la$ :(,
". In)&lass !*a+,le
9o! you !ill learn ho! to apply the a$ove mentioned methods to !rite flo! of
events and dra!ing activity diagrams from the use case%s( flo! of events, Please refer
to #a$ < slides !hich eAplain the process in detail !ith some eAamples,
-. !*ercises
, +a/e t!o of the use cases from recycling machine pro$lem %#a$ :( and !rite
flo! of events for those, Jou should !or/ in groups of three to solve this
pro$lem,
2, Practice activity diagram from the eAample in PP+ %#a$ <( for course catalog
creation,
.. 'eliverables
Jou should use these techni2ues to !rite flo! of events and dra! activity diagrams
for your term project,
'@
?$ject ?riented 3nalysis)
Discovering Classes
=
'
#a$ =) ?$ject4?riented 3nalysis) Discovering Classes

Objective
#earn the o$ject4oriented analysis phase $y understanding the methods
of class elicitation and finding the classes in an o$ject4oriented system,
1. Outline
?$ject4?riented concepts
Discovering classes5 approaches) noun phrase approach1 common class
patterns1 use case driven method1 C7C %Class47esponsi$ility4Colla$oration(
and miAed approach,
"Aamples,
2. Background
Classes) a description of a group of o$jects !ith common properties %attri$utes(1
common $ehavior %operations(1 common relationships to other o$jects and common
semantics,
2.1 Object)Oriented &once,ts
3ttri$ute) the $asic data of the class,
Method %operation() an eAecuta$le procedure that is encapsulated in a class
and is designed to operate on one or more data attri$utes that are defined as
part of the class,
?$ject) !hen specific values are assigned to all the resources defined in a
class1 the result is an instance of that class, 3ny instance of any class is called
an o$ject,
2.2 'iscovering &lasses
Discovering and defining classes to descri$e the structure of a computeri0ed system is
not an easy tas/, *hen the pro$lem domain is ne! or unfamiliar to the soft!are
developers it can $e difficult to discover classesG a coo/$oo/ for finding classes does
not eAist,
2.3 &lasses &ategories
Classes are divided into three categories)
"ntity) models information and associated $ehavior that is long4lived1 independent
of the surrounding1 application independent1 and accomplishes some responsi$ility
Boundary) handles the communication $et!een the system surroundings and the
inside of the system1 provides interface1 and facilitates communication !ith other
systems
Control) model se2uencing $ehavior specific to one or more use cases, Control
classes coordinate the events needed to reali0e the $ehavior specified in the use
case1 and they are responsi$le for the flo! of events in the use case,
'2
2." 'iscovering &lasses (,,roaches
Methods of discovering classes)
2.".1 <oun #hrase (,,roach) "Aamine the re2uirements and underline each noun,
"ach noun is a candidate classG divide the list of candidate classes into)
7elevant classes) part of the application domainG occur fre2uently in
re2uirements,
Irrelevant classes) outside of application domain
Fu00y classes) una$le to $e declared relevant !ith confidenceG re2uire
additional analysis
2.".2 &o++on &lass #atterns) Derives candidate classes from the classification
theory of o$jectsG candidate classes and o$jects come from one of the
follo!ing sources)
+angi$le things) e,g, $uildings1 cars,
7oles) e,g, teachers1 students,
"vents) things that happen at a given date and time1 or as steps in an
ordered se2uence) e,g, landing1 re2uest1 interrupt,
Interactions) e,g, meeting1 discussion,
Sources1 facilities) e,g, departments,
?ther systems) eAternal systems !ith !hich the application interacts,
Concept class) a notion shared $y a large community,
?rgani0ation class) a collection or group !ithin the domain,
People class) roles people can play,
Places class) a physical location relevant to the system,
2.".3 Use &ase 'riven 5ethod/ +he scenarios 4 use cases that are fundamental to
the system operation are enumerated, .oing over each scenario leads to the
identification of the o$jects1 the responsi$ilities of each o$ject1 and ho! these
o$jects colla$orate !ith other o$jects,
2."." &4& 7&lass)4es,onsibilit3)&ollaboration8) Used primarily as a
$rainstorming tool for analysis and design, C7C identifies classes $y
analy0ing ho! o$jects colla$orate to perform $usiness functions %use cases(,
3 C7C card contains) name of the class1 responsi$ilities of the class and
colla$orators of the class, 7ecord name of class at the topG record
responsi$ilities do!n the left4hand sideG record other classes %colla$orators(
that may $e re2uired to fulfill each responsi$ility on the right4hand side,
C7C cards are effective at analy0ing scenariosG they force you to $e concise
and clearG they are cheap1 porta$le and readily availa$le,
2.".- 5i*ed (,,roach/ 3 miA of these approaches can $e used1 one possi$le
scenario is)
Use C7C for $rainstorming,
Identify the initial classes $y domain /no!ledge,
Use common class patterns approach to guide the identification of the
classes,
Use noun phrase approach to add more classes,
Use the use case approach to verify the identified classes,
''
2.- &lass !licitation >uidelines
3 class should have a single major role,
3 class should have defined responsi$ilities %use C7C cards if needed(,
Classes should $e of a managea$le si0e) if a class has too many attri$utes
or operations1 consider splitting it,
3 class should have a !ell4defined $ehavior1 prefera$ly $y implementing a
given re2uirement or an interface,
3. &(S! Tools
7ational 7ose %introduced in la$ <(,
". In)&lass !*a+,le
9o! you !ill learn ho! to apply the a$ove mentioned methods of finding classes
from the pro$lem statement, Please refer to #a$ = slides !hich eAplain the process of
finding classes !ith some eAamples,
-. !*ercises
Consider the follo!ing re2uirements for the Cideo Store system, Identify the
candidate classes)
+he video store /eeps in stoc/ an eAtensive li$rary of current and popular movie
titles, 3 particular movie may $e held on video tape or dis/,
Cideo tapes are in either IBetaI or ICFSI format, Cideo dis/s are in DCD format,
"ach movie has a particular rental period %eApressed in days(1 !ith a rental charge to
that period, +he video store must $e a$le to immediately ans!er any in2uiries a$out a
movieHs stoc/ availa$ility and ho! many tapes and6or dis/s are availa$le for rental,
+he current condition of each tape and dis/ must $e /no!n and recorded,
+he rental charge differs depending on video medium) tape or dis/ %$ut it is the same
for the t!o categories of tapes) Beta and CFS(,
+he system should accommodate future video storage formats in addition to CFS
tapes1 Beta tapes and DCD dis/s, +he employees fre2uently use a movie code1 instead
of movie title1 to identify the movie, +he same movie title may have more than one
release $y different directors,
Jou may use any %or miA( of the class elicitation methods to find the candidate
classes,
.. 'eliverables
3lso you should use these class elicitation techni2ues to identify the classes
for your term project,
'&
Interaction Diagrams) Se2uence
- Colla$oration Diagrams
>
':
#a$ >) Interaction Diagrams) Se2uence - Colla$oration
Diagrams

Objectives
Better understanding of the interaction diagrams,
.et familiar !ith se2uence - colla$oration diagrams,
Practice dra!ing the interaction diagrams using 7ational 7ose,
1. Outline
Interaction diagrams)
o Se2uence diagrams
o Colla$oration diagrams
2. Background
Interaction diagrams descri$e ho! groups of o$jects colla$orate in some $ehavior, 3n
interaction diagram typically captures the $ehavior of a single use case,
Interaction diagrams do not capture the complete $ehavior1 only typical scenarios,
2.1 (nal3=ing a S3ste+?s Behavior
UM# offers t!o diagrams to model the dynamics of the system) se2uence and
colla$oration diagrams, +hese diagrams sho! the interactions $et!een o$jects,
2.2 Se6uence 'iagra+s
Se2uence diagrams are a graphical !ay to illustrate a scenario)
+hey are called se2uence diagrams $ecause they sho! the se2uence of
message passing $et!een o$jects,
3nother $ig advantage of these diagrams is that they sho! !hen the o$jects
are created and !hen they are destructed, +hey also sho! !hether messages
are synchronous or asynchronous
2.3 &reating Se6uence 'iagra+s
Jou must /no! the scenario you !ant to model $efore diagramming se2uence
diagrams,
3fter that specify the classes involved in that scenario,
#ist the involved o$jects in the scenario hori0ontally on the top of the page,
Drop a dotted line $eneath every o$ject, +hey are called lifelines,
+he scenario should start $y a message pass from the first o$ject,
Jou must /no! ho! to place the o$jects so that the se2uence is clear,
Jou may start the scenario $y an actor,
+iming is represented vertically do!n!ard,
3rro!s $et!een life lines represents message passing,
Fori0ontal arro!s may pass through the lifeline of another o$ject1 $ut must
stop at some other o$ject,
Jou may add constraints to these hori0ontal arro!s,
?$jects may send messages to themselves,
';
#ong1 narro! rectangles can $e placed over the lifeline of o$jects to sho!
!hen the o$ject is active, +hese rectangles are called activation lines,
'<
2." &ollaboration 'iagra+s
+hey are the same as se2uence diagrams $ut !ithout a time aAis)
+heir message arro!s are num$ered to sho! the se2uence of message sending,
+hey are less compleA and less descriptive than se2uence diagrams,
+hese diagrams are very useful during design $ecause you can figure out ho!
o$jects communicate !ith each other,
2.- <otes
3l!ays /eep your diagrams simple,
For DIF,,, then ,,,E else scenarios1 you may dra! separate se2uence diagrams
for the different $ranches of the Dif statementE, Jou may even hide them1 %at
least during the analysis phase( and document them $y the teAt description
accompanying the se2uence diagrams,
3. &(S! Tools
7ational 7ose %introduced in la$ :(,
". In)&lass !*a+,le
9o! you !ill learn ho! to apply the a$ove mentioned methods of dra!ing se2uence
and colla$oration diagrams from the pro$lem statement, Please refer to #a$ > slides
!hich eAplain the process of finding classes !ith some eAamples,
-. !*ercises
*e all have used an elevator, +he follo!ing steps descri$e the scenario of !hat
happens at the elevator door from outside,
, +he passenger presses the $utton of either up or do!n depending on !here he
!ants to go,
2, +hen he !ill see that the $utton he pressed is illuminated,
', +he elevator is no! moving to his floor,
&, *hen the elevator reached his floor it stops,
:, 9o! the $utton !hich !as illuminated no! off,
;, +he door opens and the passenger enters,
<, +he door closes,
+he o$jects)
', #assenger %he is the actor(,
&, ;loor button %this is the interface class1 the actor interacts !ith this o$ject(,
:, !levator controller %this the control class1 !hich coordinates the activities of
the scenario(,
;, !levator %the entity class1 !hich represents the machine itself !hich moves up
and do!n(,
<, 'oor %another entity class1 !hich represents the door !hich opens and closes(,
Dra! a se2uence diagram for the a$ove scenario,
.. 'eliverables
Jou should use these techni2ues to create se2uence and colla$oration diagrams for
your term project,
'=
Soft!are Design)
Soft!are 3rchitecture and ?$ject4
?riented Design
@
'>
#a$ @) Soft!are Design) Soft!are 3rchitecture and ?$ject4
?riented Design
Objectives
Deeper understanding of soft!are design and the soft!are design
document %SDD(,
#earn ho! to find the relationships $et!een classes to create UM# class
diagram,
1. Outline
Soft!are design concepts and principals,
Soft!are architecture,
Specifying the attri$utes and the operations and finding the relationships
$et!een classes,
Creating UM# class diagram,
Soft!are design document,
2. Background
+he purpose of soft!are design is Dto produce a !or/a$le %implementa$le( solution to
a given pro$lem,E David Budgen in Soft!are Design) 3n Introduction,
2.1 The 'esign #rocess
Soft!are design is an iterative process that is tracea$le to the soft!are re2uirements
analysis process, Many soft!are projects iterate through the analysis and design
phases several times, Pure separation of analysis and design may not al!ays $e
possi$le,
2.2 'esign &once,ts
+he design should $e $ased on re2uirements specification,
+he design should $e documented %so that it supports implementation1
verification1 and maintenance(,
+he design should use a$straction %to reduce compleAity and to hide
unnecessary detail(,
+he design should $e modular %to support a$straction1 verification1
maintenance1 and division of la$or(,
+he design should $e assessed for 2uality as it is $eing created1 not after the
fact,
Design should produce modules that eAhi$it independent functional
characteristics,
Design should support verification and maintenance,
2.3 Softare (rchitecture
Soft!are architecture is a description of the su$systems and components of a
soft!are system and the relationships $et!een them,
Jou need to develop an architectural model to ena$le everyone to $etter
understand the system1 to allo! people to !or/ on individual pieces of the
&@
system in isolation1 to prepare for eAtension of the system and to facilitate
reuse and reusa$ility,
2." 'escribing an (rchitecture Using U5L
3ll UM# diagrams can $e useful to descri$e aspects of the architectural
model, Four UM# diagrams are particularly suita$le for architecture
modeling)
Pac/age diagrams
Su$system diagrams
Component diagrams
Deployment diagrams
2.- S,ecif3ing &lasses
"ach class is given a name1 and then you need to specify)
3ttri$utes) initially those that capture interesting o$ject states, 3ttri$utes can
$e pu$lic1 protected1 private or friendly6pac/age,
?perations) can $e delayed till later analysis stages or even till design,
?perations also can $e pu$lic1 protected1 private or friendly6pac/age,
?$ject47elationships)
o 3ssociations) denote relationships $et!een classes,
o 3n aggregation) a special case of association denoting a Dconsists ofE
hierarchy,
o Composition) a strong form of aggregation !here components cannot eAist
!ithout the aggregate,
o .enerali0ation relationships) denote inheritance $et!een classes,
+his !ill $uild the class diagram1 !hich is a graphical representation of the classes
%including their attri$utes and operations( and their relationship !ith other classes,
3. &(S! Tools
7ational 7ose %introduced in la$ <(,
". In)&lass !*a+,le
9o! you !ill learn ho! to specify classes5 attri$utes1 methods and the relationships
$et!een the classes, Jou !ill use the same classes identified in the eAamples of la$ =,
Please refer to #a$ @ slides !hich eAplain the process of finding classes5 attri$utes1
methods and the relationships $et!een the classes as !ell as creating UM# class
diagrams !ith some eAamples,
-. !*ercises
7efer to #a$ = eAercisesG assume that the Cideo Store needs to /no! if a video tape is
a $rand ne! tape or it !as already taped over %this can $e captured $y an attri$ute
isUtapedUover(G assume also that the storage capacity of a video dis/ allo!s holding
multiple versions of the same movie1 each in a different language or !ith different
endings,
Use the identified classes from #a$ = and find their attri$utes1 operations and the
relationships $et!een the classes %$uild the UM# diagram(,
&
.. 'eliverables
3lso you should use specifying class attri$utes1 methods and the relationship
!ith other classes you learned in your term project,
&2
State +ransition Diagram
State Transition 'iagra+

&'
#a$ ) State +ransition Diagrams

Objectives
Deeper understanding of UM# state transition diagrams %S+D(,
Practicing using 7ational 7ose,
1. Outline
UM# state diagrams,
UM# state diagram notation
UM# state details
"Aamples
2. Background
Mainly1 !e use interaction diagrams to study and model the $ehavior of o$jects in our
system, Sometimes1 !e need to study the $ehavior of a specific o$ject that sho!s
compleA $ehavior to $etter understand its dynamics, For that sa/e1 UM# provides
state transition diagrams used to model the $ehavior of o$jects of compleA $ehavior,
In this #a$1 UM# state transition diagrams !ill $e introduced, *e !ill study their
notation and ho! can !e model them using 7ational 7ose,
2.1 U5L State 'iagra+s
State diagrams sho! ho! one specific o$ject changes state as it receives and
processes messages)
Since they are very specific1 they are used for analy0ing very specific
situations if !e compare them !ith other diagrams,
3 state refers to the set of values that descri$e an o$ject at a specific moment
in time,
3s messages are received1 the operations associated !ith the o$ject5s parent
class are invo/ed to deal !ith the messages,
+hese messages change the values of these attri$utes,
+here is no need to prepare a state diagram for every class you have in the
system,
2.2 &reating State Transition 'iagra+s
States are represented $y rectangles !ith rounded corners !ith an attri$ute
name !ith a values associated !ith it,
+he name of the state is placed !ithin the $oA,
"vents are sho!n $y arro!s,
3n event occurs !hen at an instant in time !hen a value is changed,
3 message is data passed from one o$ject to another,
+he name of a state usually refers to the name of the attri$ute and the values
associated to it,
"Aample1 a student o$ject may receive a message to change its name, +he
state of that o$ject changes from the first name state to the ne! state name,
+he name of the state is placed in the top compartment,
State varia$les are placed in the neAt compartment,
&&
+he operations associated !ith the state are listed in the lo!est compartment
of the state $oA,
In the operations part1 !e usually use one of the follo!ing reserved !ords)
o !ntr3/ a specific action performed on the entry to the state,
o 'o/ an ongoing action performed !hile in the state,
o On/ a specific action performed !hile in the state,
o !*it/ a specific action performed on eAiting the state,
+here are t!o special states added to the state transition diagram4 start state
and end state,
9otation of start state is a solid $lac/ circle and for the end state a $ull5s eye is
used,
2.3 State Transition 'etails
3 state transition may have an action and6or guard condition associated !ith it
and it may also trigger an event,
3n action is the $ehavior that occurs !hen the state transition occurs,
3n event is a message that is sent to another o$ject in the system,
3 guard condition is a Boolean eApression of attri$ute values that allo!s a
state transition only if the condition is true,
Both actions and guards are $ehaviors of the o$ject and typically $ecome
operations, 3lso they are usually private operations %used $y the o$ject itself(
3ctions that accompany all state transitions into a state may $e placed as an
entry action !ithin the state,
3ctions that accompany all state transitions out of a state may $e placed as
eAit actions !ithin the state
3 $ehavior that occurs !ithin the state is called an activity,
3n activity starts !hen the state is entered and either completes or is
interrupted $y an outgoing state transition,
3 $ehavior may $e an action1 or it may $e an event sent to another o$ject,
+his $ehavior is mapped to operations on the o$ject,
State transition diagram notation)
"vent causing transition
3ction that occurs
9e! State
Ventry)WX
Vdo) WX
VeAit)WX
State
Ventry)WX
Vdo) WX
VeAit)WX
&:
3. &(S! Tools
7ational 7ose %introduced in #a$ :(,
". In)&lass !*a+,le
9o! you !ill learn ho! to apply the a$ove mentioned methods of dra!ing state
transition diagrams %S+D(, Please refer to #a$ slides !hich eAplain the process of
finding dynamic classes and creating S+D !ith some eAamples,
-. !*ercises
Fere is !hat happens in a micro!ave oven)
, +he oven is initially in an idle state ith door o,en1 !here the light is turned
on,
2, *hen the door is closed it is no! in idle ith door closed1 $ut the light is
turned off,
', If a $utton is pressed1 then it moves to initial cooking stage1 !here the timer
is set and lights are on1 and heating starts
&, 3t any moment the door may $e opened1 the cooking is interru,ted: the timer
is cleared1 and heating stops,
:, 3lso !hile coo/ing1 another $utton can $e pushed and e*tended cooking
state starts1 !here the timer gets more minutes, 3t any moment door can $e
opened here also,
;, If the time times out1 then cooking is co+,lete1 heating stops1 lights are off1
and it sounds a $eep,
<, *hen the door is open1 again the oven is in idle state !ith the door open,
Dra! a state transition diagram for the micro!ave oven,
.. 'eliverables
Jou should use these techni2ues to create state transition diagrams for your term
project,
&;
Implementation Diagrams)
Component - Deployment Diagrams
2
&<
#a$ 2) Implementation Diagrams) Component - Deployment
Diagrams

Objectives
M Become familiar !ith the implementation diagrams) component and
deployment diagrams,
M Practice using 7ational 7ose,
1. Outline
Implementation diagrams) component and deployment diagrams,
"Aamples,
2. Background
Implementation diagrams capture design information, +he main implementation
diagrams in UM# are) component and deployment diagrams, In this #a$ !e !ill
study these diagrams and their notation,
2.1 U5L I+,le+entation 'iagra+s
+he main implementation diagrams !e have in UM# are) component diagrams and
deployment diagrams, +hese diagrams are high level diagrams in comparison !ith old
diagrams you have already learned,
2.2 U5L &o+,onent 'iagra+
Component diagrams capture the physical structure of the implementation,
7emem$er al!ays that !hen you tal/ a$out components1 you are tal/ing a$out
the physical models of code,
Jou can name them and sho! dependency $et!een different components
using arro!s,
3 component diagram sho!s relationships $et!een component pac/ages and
components,
"ach component diagram provides a physical vie! of the current model,
Component diagrams contain icons representing)
o Component pac/ages,
o Components,
o Main programs,
o Pac/ages,
o Su$programs,
o +as/s,
o Dependencies,
2.3 'e,lo3+ent 'iagra+s
3 deployment diagram sho!s processors1 devices and connections, "ach model
contains a single deployment diagram !hich sho!s the connections $et!een its
processors and devices1 and the allocation of its processes to processors,
&=
2.".1 'e,lo3+ent 'iagra+s/ #rocessor
3 processor is a hard!are component capa$le of eAecuting programs,
3 processor is given a name and you should specify the processes that !ill run
on that processor,
Jou can also specify the scheduling of these processes on that processor,
+ypes of scheduling are)
o Pre4emptive) a higher priority process may ta/e the process from lo!er
priority one,
o 9on4preemptive) a process !ill o!n the processor until it finishes
o Cyclic) control passes from one process to another,
o "Aecutive) an algorithm controls the scheduling of the processes
o Manual) scheduling $uy the user,
2.".2 'e,lo3+ent 'iagra+s/ 'evice
3 device is a hard!are component !ith no computing po!er, "ach device must have
a name, Device names can $e generic1 such as DmodemE or Dterminal,E
2.".3 'e,lo3+ent diagra+s/ &onnection
3 connection represents some type of hard!are coupling $et!een t!o entities, 3n
entity is either a processor or a device, +he hard!are coupling can $e direct1 such as
an 7S2'2 ca$le1 or indirect1 such as satellite4to4ground communication, Connections
are usually $i4directional,
3. &(S! Tools
7ational 7ose %introduced in #a$ :(,
". In)&lass !*a+,le
9o! you !ill learn ho! to apply the a$ove mentioned methods of creating
component and deployment diagrams, Please refer to #a$ 2 slides !hich eAplain the
process of creating implementation diagrams !ith some eAamples,
-. !*ercises
+hin/ a$out any system and its components and dra! deployment and component
diagrams,
.. 'eliverables
Jou should use these techni2ues to create component and deployment diagrams for
your term project,
&>
Soft!are +esting
'
:@
#a$ ') Soft!are +esting

Objectives
.ain a deeper understanding of soft!are testing and the soft!are testing
document,
Become familiar !ith a soft!are testing tool %8Unit(,
1. Outline
?vervie! of soft!are testing,
Unit testing,
8Unit tutorial,
Soft!are test specification,
2. Background
+esting is the process of eAecuting a program !ith the intent of finding errors, 3 good
test case is one !ith a high pro$a$ility of finding an as4yet undiscovered error, 3
successful test is one that discovers an as4yet4undiscovered error,
+he causes of the soft!are defects are) specification may $e !rongG specification may
$e a physical impossi$ilityG faulty program designG or the program may $e incorrect,
2.1 Basic 'efinitions
( failure is an unaccepta$le $ehavior eAhi$ited $y a system,
( defect is a fla! in any aspect of the system that contri$utes1 or may
potentially contri$ute1 to the occurrence of one or more failures, It might ta/e
several defects to cause a particular failure,
(n error is a slip4up or inappropriate decision $y a soft!are developer that
leads to the introduction of a defect,
2.2 >ood Test (ttributes
3 good test has a high pro$a$ility of finding an error1 not redundant1 and should not
$e too simple or too compleA,
2.3 Unit Testing
Unit testing is testing each unit separately, In unit testing interfaces tested for proper
information flo! and local data are eAamined to ensure that integrity is maintained,
Boundary conditions and all error handling paths should also $e tested,
3. &(S! Tools
8Unit is an open4source project to provide a $etter solution for unit testing in 8ava, It
can $e integrated !ith many 8ava ID"s,
Central idea) create a separate 8ava testing class for each class you5re creating1 and
then provide a means to easily integrate the testing class !ith the tested class for unit
testing,
:
3.1 @Unit Ter+inolog3
( unit test/ is a test of a single class,
( test case/ tests the response of a single method to a particular set of inputs,
( test suite/ is a collection of test cases,
( test runner/ is soft!are that runs tests and reports results,
( test fi*ture/ sets up the data %$oth o$jects and primitives( that are needed to
run tests, For eAample if you are testing code that updates an employee record1
you need an employee record to test it on,
3.2 1o @Unit $orks
Define a su$class of Test&ase.
?verride the setU,78 A tear'on78 methods,
Define one or more pu$lic testBBB78methods
o "Aercise the o$ject%s( under test,
o 3sserts the eApected results,
Define a static suite78 factory method
o Create a +estSuite containing all the tests,
?ptionally define +ain78 to run the +estCase in $atch mode,
". In)&lass 'e+o
3 tutorial on ho! to use 8Unit !ith some eAample !ill $e presented, Please refer to
#a$ ' slides for an overvie! of soft!are testing and 8Unit tutorial !ith some
eAamples,
-. !*ercises
*rite a 8Unit test class for testing
public class Exercise {
/** Return the minimum of x and y. */
public static int min(int x, int y) { ... }
}
.. 'eliverables
Jou should su$mit the solutions for the previous eAercise,
3lso1 if you are $uilding your project using 8ava1 you should use 8Unit for
testing,
:2

6 SWE311 Revised Lab Manual

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

6 SWE311 Revised Lab Manual

Enviado por

Direitos autorais:

Formatos disponíveis

King Fahd University of Petroleum and Minerals

Department of Information and Computer Science

Soft!are "ngineering #a$ Manual %ICS &'(

Soft!are "ngineering #a$ Manual %ICS &'(

State Transition 'iagra+

Você também pode gostar