Professional Documents
Culture Documents
Lab Manual
1
Introduction and Project
Definition
add( )
name : int
fetchDoc( ) delete( )
docid : int
sortByName( ) numField : int
Writin g
a dd file [ numbe rOffile==MAX ] /
get( ) fla g OFF
open( ) read() fill the
clo se( ) code..
FileLis t read( )
sortFil eLis t( ) Openning
use-case 1 add( )
fLis t create( )
fil lD ocument( )
delete( )
1 clos e file
Actor A Actor B
close file
Closing
Re ading
use-case 2
rep
<<entity>>
Reposit ory File
(from Persistence)
read( )
GrpFil e
Customer
name
name : char * = 0
read( )
readDoc( )
readFile( ) open( )
create( ) addr
receive()
fillFil e( )
use-case 3 withdraw()
fetch()
UI
send()
Deployment
MFC
Class Diagram
DocumentApp
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨
- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö
RogueWave
Repository DocumentList Windows95
Window95
9: sortByName ( ) Persistence Windows95
global
FileManager
¹®¼°ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
¹®¼°ü¸® ¾ÖÇø´
mainWnd : MainWnd
Package
Windows
NT
1: Doc view request ( )
Document
L
Solaris
2: fetchDoc( )
¹®¼°ü¸® ¿£Áø.EXE
4: create ( ) gFile : GrpFile
Diagram
Alpha
8: fillFile ( ) UNIX
ÀÀ¿ë¼¹ö.EXE
Windows
NT
user : »ç¿ëÀÚ GraphicFile
IBM
fileMgr : FileMgr
File
Mainframe
3: create ( )
FileList
6: fillDocument ( )
µ¥ÀÌŸº£À̽º¼¹ö
7: readFile ( )
5: readDoc ( )
document : Document
repository : Repository
2: fetchDoc( )
4: create ( )
5: readDoc ( )
7: readFile ( )
8: fillFile ( )
Sequence Diagram
Executable System
2
Software Engineering Lab Manual (ICS 413)
1. Outline
Getting familiar with WebCT.
Getting familiar with SyncronEye.
Introduction to the lab plan and objectives.
Project definition.
2. Background
The software engineer is a key person analyzing the business, identifying
opportunities for improvement, and designing information systems to implement these
ideas. It is important to understand and develop through practice the skills needed to
successfully design and implement new software systems.
2.1 Introduction
In this lab you will practice the software development life cycle (project
management, requirements engineering, systems modeling, software design,
prototyping, and testing) using CASE tools within a team work environment.
UML notation is covered in this lab as the modeling language for analysis and
design.
3
Software Engineering Lab Manual (ICS 413)
Week 1 No lab
Week 2 Introduction and project
definition
Week 3 Software process overview Configuration management
tool (Source safe)
Week 4 Project planning Management tool (MS
project)
Week 5 Software requirements and Plan doc Requirement documentation
RequisitePro tool (RequisitePro)
Week 6 Introduction to UML and use Requirement and design tool
case diagrams (Rational Rose)
Week 7 System modeling (DFD and Microsoft Word
ER)
Week 8 Flow of events and activity SRS doc Rational Rose
diagram
Week 9 OO analysis: discovering Rational Rose
classes
Week 10 Interaction diagrams: Rational Rose
sequence and collaboration
diagrams
Week 11 Software Design: software Design doc (ver. 1) Rational Rose
architecture and object-
oriented design
Week 12 State Transition Diagram Rational Rose
Week 13 Component and deployment Design doc (Final Rational Rose
diagrams ver.)
Week 14 Software testing Testing tool (JUnit)
Week 15 Presentations Testing doc and
user manual
3. CASE Tools
No tools are used for this lab.
4. In-Class Example
Some examples of problem definition will be presented in the class.
5. Exercises
Form groups of 3 students (with one of them as a leader).
Brainstorm and list 5 suitable project titles.
Present these to the class.
Choose one of the projects from your list.
Try to write (a hypothetical) project definition for it.
Present it to the instructor/class.
6. Deliverables
Form teams of 4 students for the term project.
Submit their IDs, names, section by email within this week.
Suggest / research a project and write a project definition/problem statement.
4
Software Engineering Lab Manual (ICS 413)
2
Software Processes and
Visual Source Safe
5
Software Engineering Lab Manual (ICS 413)
Objectives
Obtain a deeper understanding of software process models and software
processes.
Become familiar with a configuration management case tool (Microsoft
Visual Source Safe).
1. Outline
Review of the basic software process models and software processes.
Visual Source Safe tutorial.
2. Background
IEEE defined a software process as: “a set of activities, practices and transformations
that people use to develop and maintain software and the associated products, e.g.,
project plans, design documents, code, test cases and user manual”.
Following the software process will stabilize the development lifecycle and make the
software more manageable and predictable. It will also reduce software development
risk and help to organize the work products that need to be produced during a
software development project. A well-managed process will produce high quality
products on time and under budget. So following a mature software process is a key
determinant to the success of a software project.
3. CASE Tools
Visual Source Safe (VSS) is Microsoft's version of a source control program
(configuration management) that enables you to keep track of multiple versions of
documents.
With VSS you can go back to an earlier bug-free version of the source code to try to
track down where the bug was introduced, compare versions of a document and
recover a copy of the document that you saved weeks or months ago.
6
Software Engineering Lab Manual (ICS 413)
Another very useful feature of VSS is labeling. Labeling provides a simple way of
knowing which versions of which documents belong together in a group. VSS was
designed for environments in which multiple users are editing the same documents. It
permits only one user at a time to edit each document, thereby guaranteeing that only
one authoritative "latest version" of a document exists at any given time.
4. In-Class Demo
A demonstration will be given show the basic functions of VSS in order to manage
your files. These features include:
a. Creating a new project.
b. Checking files in and out.
c. Labeling files.
d. Viewing revision history.
e. Using Diff to show differences.
f. Using Search to find documents.
For more information on software processes and VSS tutorial please refer to Lab 2
slides which contain an overview of software processes and VSS tutorial slides.
5. Exercises
Create a project and add some java files to it (at least 3 files).
Label the existing files.
Check out all the files and modify one of them.
Check the edited file back in.
View the revision history of the edited file and show the differences between
the old and the new versions.
Search for any unchecked in files.
7
Software Engineering Lab Manual (ICS 413)
After you perform all of the previous tasks, create a new project for your term project.
If any files of your term project are ready, you need to check them in. You need to
manage all your term project files using Source Safe.
6. Deliverables
You should successfully demonstrate that all the exercise tasks were implemented.
Also your VSS project for your term project should be created and any available files
should be checked in.
8
Software Engineering Lab Manual (ICS 413)
3
Project Planning and
Management
9
Software Engineering Lab Manual (ICS 413)
1. Outline
Project work planning.
Risk management.
MS project.
Examples.
2. Background
Project management is the process of planning and controlling the development of a
system within a specified timeframe at a minimum cost with the right functionality.
10
Software Engineering Lab Manual (ICS 413)
3. CASE Tools
Microsoft Project is the clear market leader among desktop project
management applications.
Primavera Project Planner: multi-project, multi-user project, and resource
planning and scheduling.
SureTrak Project Manager: resource planning and control for small-to-medium
sized projects.
According to the Gartner Group, it accounts for about two-thirds of all project
management software sales.
4. In-Class Demo
Now you will learn how to apply the above mentioned methods to draw a Gantt chart
or Activity chart for the project. Please refer to Lab 3 slides which explain the process
in detail with some examples.
5. Exercises
Use MS Project 2002 to create a series of tasks leading to completion of a project of
your choice.
For your project, you need to:
Set start or ending dates.
Develop a list of tasks that need to be completed.
Establish any sub tasks and create links.
Create any links between major tasks.
Assign a specific amount time for each task.
Assign resources for each task.
Create task information for each item you put into the list.
6. Deliverables
You should submit the solutions for the previous exercises.
You should use MS Project to create a plan and time schedule for your term project.
11
Software Engineering Lab Manual (ICS 413)
4
Software Requirement
Specification (SRS)
12
Software Engineering Lab Manual (ICS 413)
1. Outline
Review of the requirements engineering process.
Write requirements and specifications.
RequisitePro tutorial.
Software Requirement Specification (SRS).
2. Background
A requirement is a statement of a behavior or attribute that a system must possess for
the system to be acceptable to a stakeholder.
13
Software Engineering Lab Manual (ICS 413)
Creating specifications is important. However, you may not create specifications if:
You are using a very incremental development process (small changes).
You are building research or proof of concept projects.
You rebuilding very small projects.
It is not cheaper or faster than building the product.
3. CASE Tools
RequisitePro is a powerful, easy-to-use requirements management tool that helps
teams manage project requirements comprehensively, promotes communication and
collaboration among team members, and reduces project risk. It thereby increases the
chances of delivering a product that the client wants and does so in a timely manner.
RequisitePro offers the power of a database and Microsoft Word and is integrated
with other Rational Suite products.
4. In-Class Demo
An overview of the basic features of RequisitePro will be presented. In the exercise
section you will practice and apply what you have learned in the tutorial. Please refer
to lab 4 slides which contain a tutorial on RequisitePro and an overview of the
requirements engineering process, and writing requirements and specifications.
5. Exercises
a. Are the following requirements vague? If yes, why? Can you fix them?
o The feature is responsible for managing connections.
o The feature allows users to perform administrative functions.
6. Deliverables
You should submit the solutions for exercise 5.a.
You should show that you have successfully performed all the tasks listed in
exercise 5.b.
Also during the requirement phase of your term project, you should use
RequisitePro to manage your requirements.
15
Software Engineering Lab Manual (ICS 413)
5
Introduction to UML and Use
Case Diagram
16
Software Engineering Lab Manual (ICS 413)
1. Outline
Visual modeling.
Introduction to UML.
Introduction to visual modeling with UML.
Use case diagrams: discovering actors and use cases.
2. Background
Visual Modeling is a way of thinking about problems using models organized around
real-world ideas. Models are useful for understanding problems, communicating with
everyone involved with the project (customers, domain experts, analysts, designers,
etc.), modeling enterprises, preparing documentation, and designing programs and
databases
17
Software Engineering Lab Manual (ICS 413)
2.5 Actors
Are NOT part of the system – they represent anyone or anything that must
interact with the system.
Only input information to the system.
Only receive information from the system.
Both input to and receive information from the system.
Represented in UML as a stickman.
3. CASE Tools
The Rational Rose product family is designed to provide the software developer with
a complete set of visual modeling tools for development of robust, efficient solutions
to real business needs in the client/server, distributed enterprise and real-time systems
environments. Rational Rose products share a common universal standard, making
modeling accessible to nonprogrammers wanting to model business processes as well
as to programmers modeling applications logic.
4. In-Class Example
Now you will learn how to apply the above-mentioned methods to draw use case
diagrams from the problem statement. Please refer to Lab 5 slides which explain the
process in detail with some examples.
18
Software Engineering Lab Manual (ICS 413)
5. Exercises
Read carefully the following problem statement
We are after a system that controls a recycling machine for returnable bottles and
cans. The machine will allow a customer to return bottles or cans on the same
occasion.
When the customer returns an item, the system will check what type has been
returned. The system will register how many items each customer returns and, when
the customer asks for a receipt, the system will print out what he deposited, the value
of the returned items and the total return sum that will be paid to the customer.
The system is also be used by an operator. The operator wants to know how many
items of each type have been returned during the day. At the end of the day, the
operator asks for a printout of the total number of items that have been deposited in
the machine on that particular day. The operator should also be able to change
information in the system, such as the deposit values of the items. If something is
amiss, for example if a can gets stuck or if the receipt roll is finished, the operator will
be called by a special alarm signal.
6. Deliverables
You should submit the solutions for the previous exercises.
You should use these techniques to draw use case diagrams for your term project
using Rational Rose.
19
Software Engineering Lab Manual (ICS 413)
6
System Modeling
20
Software Engineering Lab Manual (ICS 413)
1. Outline
System analysis model elements:
Data model: entity-relationship diagram (ERD)
Functional model: data flow diagram (DFD)
2. Background
Modeling consists of building an abstraction of reality. These abstractions are
simplifications because they ignore irrelevant details and they only represent the
relevant details (what is relevant or irrelevant depends on the purpose of the model).
A wide variety of models have been in use within various engineering disciplines for
a long time. In software engineering a number of modeling methods are also
available.
21
Software Engineering Lab Manual (ICS 413)
Relationship
External entity
Process
Data flow
Control flow
Data store
22
Software Engineering Lab Manual (ICS 413)
3. CASE Tools
You can use MS word to create your ERD and DFD since we do not have a license
for a case tool that supports these diagrams.
4. In-Class Example
Now you will learn how to create ERD and DFD. Please refer to Lab 6 slides which
explain the process of creating ERD and DFD with some examples.
5. Exercises
a. Create an ERD for an airline reservation system.
6. Deliverables
You should submit the solutions for the previous exercises.
You should create ERD and DFD for your term project if needed. You also need to
check them into Source Safe.
23
Software Engineering Lab Manual (ICS 413)
7
Documenting Use Cases and
Activity Diagrams
24
Software Engineering Lab Manual (ICS 413)
1. Outline
Writing flow of events.
Flow of events template and example.
Activity diagrams.
Examples.
2. Background
Each use case is documented with a flow of events. The flow of events for a use case
is a description of the events needed to accomplish the required behavior of the use
case. Activity diagrams may also be created at this stage in the life cycle. These
diagrams represent the dynamics of the system. They are flow charts that are used to
show the workflow of a system; that is, they show the flow of control from one
activity to another in the system,
25
Software Engineering Lab Manual (ICS 413)
A sample completed flow of events document for the Select Courses to Teach use
case follows.
1.1 Preconditions
Create course offerings sub-flow of the maintain course information use case must
execute before this use case begins.
If the activity selected is ADD, the S-1: add a course offering sub-flow is performed.
If the activity selected is DELETE, the S-2: delete a course offering sub-flow is
performed.
If the activity selected is REVIEW, the S-3: review schedule sub-flow is performed.
If the activity selected is PRINT, the S-4: print a schedule sub-flow is performed.
1.3 Sub-flows
S-1: Add a Course Offering:
The system displays the course screen containing a field for a course name and
number. The professor enters the name and number of a course (E-3). The system
displays the course offerings for the entered course (E-4). The professor selects a
course offering. The system links the professor to the selected course offering (E-5).
The use case then begins again.
26
Software Engineering Lab Manual (ICS 413)
E-2: An invalid semester is entered. The user can re-enter the semester or terminate
the use case.
E-3: An invalid course name/number is entered. The user can re-enter a valid
name/number combination or terminate the use case.
E-4: Course offerings cannot be displayed. The user is informed that this option is not
available at the current time. The use case begins again.
E-5: A link between the professor and the course offering cannot be created. The
information is saved and the system will create the link at a later time. The use case
continues.
E-6: An invalid course offering name/number is entered. The user can re-enter a valid
course offering name/number combination or terminate the use case.
E-7: A link between the professor and the course offering cannot be removed. The
information is saved and the system will remove the link at a later time. The use case
continues.
E-8: The system cannot retrieve schedule information. The use case then begins again.
E-9: The schedule cannot be printed. The user is informed that this option is not
available at the current time. The use case begins again.
Use case flow of events documents are entered and maintained in documents external
to Rational Rose. The documents are linked to the use case.
27
Software Engineering Lab Manual (ICS 413)
3. CASE Tools
Rational Rose (introduced in lab 5).
4. In-Class Example
Now you will learn how to apply the above mentioned methods to write flow of
events and drawing activity diagrams from the use case(s) flow of events. Please refer
to Lab 7 slides which explain the process in detail with some examples.
5. Exercises
1. Take two of the use cases from recycling machine problem (Lab 5) and write
flow of events for those. You should work in groups of three to solve this
problem.
2. Practice activity diagram from the example in PPT (Lab 7) for course catalog
creation.
6. Deliverables
You should submit the solutions for the previous exercises.
You should use these techniques to write flow of events and draw activity diagrams
for your term project.
28
Software Engineering Lab Manual (ICS 413)
8
Object Oriented Analysis:
Discovering Classes
29
Software Engineering Lab Manual (ICS 413)
1. Outline
Object-Oriented concepts
Discovering classes’ approaches: noun phrase approach, common class
patterns, use case driven method, CRC (Class-Responsibility-Collaboration)
and mixed approach.
Examples.
2. Background
Classes: a description of a group of objects with common properties (attributes),
common behavior (operations), common relationships to other objects and common
semantics.
30
Software Engineering Lab Manual (ICS 413)
2.4.1 Noun Phrase Approach: Examine the requirements and underline each noun.
Each noun is a candidate class; divide the list of candidate classes into:
Relevant classes: part of the application domain; occur frequently in
requirements.
Irrelevant classes: outside of application domain
Fuzzy classes: unable to be declared relevant with confidence; require
additional analysis
2.4.2 Common Class Patterns: Derives candidate classes from the classification
theory of objects; candidate classes and objects come from one of the
following sources:
Tangible things: e.g. buildings, cars.
Roles: e.g. teachers, students.
Events: things that happen at a given date and time, or as steps in an
ordered sequence: e.g. landing, request, interrupt.
Interactions: e.g. meeting, discussion.
Sources, facilities: e.g. departments.
Other systems: external systems with which the application interacts.
Concept class: a notion shared by a large community.
Organization class: a collection or group within the domain.
People class: roles people can play.
Places class: a physical location relevant to the system.
2.4.3 Use Case Driven Method: The scenarios - use cases that are fundamental to
the system operation are enumerated. Going over each scenario leads to the
identification of the objects, the responsibilities of each object, and how these
objects collaborate with other objects.
2.4.5 Mixed Approach: A mix of these approaches can be used, one possible
scenario is:
Use CRC for brainstorming.
Identify the initial classes by domain knowledge.
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.
31
Software Engineering Lab Manual (ICS 413)
3. CASE Tools
Rational Rose (introduced in lab 7).
4. In-Class Example
Now you will learn how to apply the above mentioned methods of finding classes
from the problem statement. Please refer to Lab 8 slides which explain the process of
finding classes with some examples.
5. Exercises
Consider the following requirements for the Video Store system. Identify the
candidate classes:
The video store keeps in stock an extensive library of current and popular movie
titles. A particular movie may be held on video tape or disk.
Video tapes are in either "Beta" or "VHS" format. Video disks are in DVD format.
Each movie has a particular rental period (expressed in days), with a rental charge to
that period. The video store must be able to immediately answer any inquiries about a
movie's stock availability and how many tapes and/or disks are available for rental.
The current condition of each tape and disk must be known and recorded.
The rental charge differs depending on video medium: tape or disk (but it is the same
for the two categories of tapes: Beta and VHS).
The system should accommodate future video storage formats in addition to VHS
tapes, Beta tapes and DVD disks. The employees frequently use a movie code, instead
of movie title, to identify the movie. The same movie title may have more than one
release by different directors.
You may use any (or mix) of the class elicitation methods to find the candidate
classes.
6. Deliverables
You should submit the solutions for the previous exercises.
Also you should use these class elicitation techniques to identify the classes
for your term project.
32
Software Engineering Lab Manual (ICS 413)
9
Interaction Diagrams: Sequence
& Collaboration Diagrams
33
Software Engineering Lab Manual (ICS 413)
1. Outline
Interaction diagrams:
o Sequence diagrams
o Collaboration diagrams
2. Background
Interaction diagrams describe how groups of objects collaborate in some behavior. An
interaction diagram typically captures the behavior of a single use case.
Interaction diagrams do not capture the complete behavior, only typical scenarios.
34
Software Engineering Lab Manual (ICS 413)
2.5 Notes
Always keep your diagrams simple.
For “IF... then ...” else scenarios, you may draw separate sequence diagrams
for the different branches of the “if statement”. You may even hide them, (at
least during the analysis phase) and document them by the text description
accompanying the sequence diagrams.
3. CASE Tools
Rational Rose (introduced in lab 5).
4. In-Class Example
Now you will learn how to apply the above mentioned methods of drawing sequence
and collaboration diagrams from the problem statement. Please refer to Lab 9 slides
which explain the process of finding classes with some examples.
5. Exercises
We all have used an elevator. The following steps describe the scenario of what
happens at the elevator door from outside.
1. The passenger presses the button of either up or down depending on where he
wants to go.
2. Then he will see that the button he pressed is illuminated.
3. The elevator is now moving to his floor.
4. When the elevator reached his floor it stops.
5. Now the button which was illuminated now off.
6. The door opens and the passenger enters.
7. The door closes.
The objects:
3. Passenger (he is the actor).
4. Floor button (this is the interface class, the actor interacts with this object).
5. Elevator controller (this the control class, which coordinates the activities of
the scenario).
6. Elevator (the entity class, which represents the machine itself which moves up
and down).
7. Door (another entity class, which represents the door which opens and closes).
6. Deliverables
You should submit the solutions for the previous exercises.
You should use these techniques to create sequence and collaboration diagrams for
your term project.
35
Software Engineering Lab Manual (ICS 413)
10
Software Design:
Software Architecture and Object-
Oriented Design
36
Software Engineering Lab Manual (ICS 413)
Objectives
Deeper understanding of software design and the software design
document (SDD).
Learn how to find the relationships between classes to create UML class
diagram.
1. Outline
Software design concepts and principals.
Software architecture.
Specifying the attributes and the operations and finding the relationships
between classes.
Creating UML class diagram.
Software design document.
2. Background
The purpose of software design is “to produce a workable (implementable) solution to
a given problem.” David Budgen in Software Design: An Introduction.
37
Software Engineering Lab Manual (ICS 413)
3. CASE Tools
Rational Rose (introduced in lab 7).
4. In-Class Example
Now you will learn how to specify classes’ attributes, methods and the relationships
between the classes. You will use the same classes identified in the examples of lab 8.
Please refer to Lab 10 slides which explain the process of finding classes’ attributes,
methods and the relationships between the classes as well as creating UML class
diagrams with some examples.
5. Exercises
Refer to Lab 8 exercises; assume that the Video Store needs to know if a video tape is
a brand new tape or it was already taped over (this can be captured by an attribute
is_taped_over); assume also that the storage capacity of a video disk allows holding
multiple versions of the same movie, each in a different language or with different
endings.
Use the identified classes from Lab 8 and find their attributes, operations and the
relationships between the classes (build the UML diagram).
6. Deliverables
You should submit the solutions for the previous exercises.
38
Software Engineering Lab Manual (ICS 413)
Also you should use specifying class attributes, methods and the relationship
with other classes you learned in your term project.
39
Software Engineering Lab Manual (ICS 413)
11
State Transition Diagram
40
Software Engineering Lab Manual (ICS 413)
1. Outline
UML state diagrams.
UML state diagram notation
UML state details
Examples
2. Background
Mainly, we use interaction diagrams to study and model the behavior of objects in our
system. Sometimes, we need to study the behavior of a specific object that shows
complex behavior to better understand its dynamics. For that sake, UML provides
state transition diagrams used to model the behavior of objects of complex behavior.
In this Lab, UML state transition diagrams will be introduced. We will study their
notation and how can we model them using Rational Rose.
In the operations part, we usually use one of the following reserved words:
o Entry: a specific action performed on the entry to the state.
o Do: an ongoing action performed while in the state.
o On: a specific action performed while in the state.
o Exit: a specific action performed on exiting the state.
There are two special states added to the state transition diagram- start state
and end state.
Notation of start state is a solid black circle and for the end state a bull’s eye is
used.
State
[entry:…]
[do: …]
[exit:…]
New State
[entry:…]
[do: …]
[exit:…]
42
Software Engineering Lab Manual (ICS 413)
3. CASE Tools
Rational Rose (introduced in Lab 5).
4. In-Class Example
Now you will learn how to apply the above mentioned methods of drawing state
transition diagrams (STD). Please refer to Lab 11 slides which explain the process of
finding dynamic classes and creating STD with some examples.
5. Exercises
Here is what happens in a microwave oven:
1. The oven is initially in an idle state with door open, where the light is turned
on.
2. When the door is closed it is now in idle with door closed, but the light is
turned off.
3. If a button is pressed, then it moves to initial cooking stage, where the timer
is set and lights are on, and heating starts
4. At any moment the door may be opened, the cooking is interrupted, the timer
is cleared, and heating stops.
5. Also while cooking, another button can be pushed and extended cooking
state starts, where the timer gets more minutes. At any moment door can be
opened here also.
6. If the time times out, then cooking is complete, heating stops, lights are off,
and it sounds a beep.
7. When the door is open, again the oven is in idle state with the door open.
Draw a state transition diagram for the microwave oven.
6. Deliverables
You should submit the solutions for the previous exercises.
You should use these techniques to create state transition diagrams for your term
project.
43
Software Engineering Lab Manual (ICS 413)
12
Implementation Diagrams:
Component & Deployment Diagrams
44
Software Engineering Lab Manual (ICS 413)
1. Outline
Implementation diagrams: component and deployment diagrams.
Examples.
2. Background
Implementation diagrams capture design information. The main implementation
diagrams in UML are: component and deployment diagrams. In this Lab we will
study these diagrams and their notation.
45
Software Engineering Lab Manual (ICS 413)
3. CASE Tools
Rational Rose (introduced in Lab 5).
4. In-Class Example
Now you will learn how to apply the above mentioned methods of creating
component and deployment diagrams. Please refer to Lab 12 slides which explain the
process of creating implementation diagrams with some examples.
5. Exercises
Think about any system and its components and draw deployment and component
diagrams.
6. Deliverables
You should submit the solutions for the previous exercises.
You should use these techniques to create component and deployment diagrams for
your term project.
46
Software Engineering Lab Manual (ICS 413)
13
Software Testing
47
Software Engineering Lab Manual (ICS 413)
1. Outline
Overview of software testing.
Unit testing.
JUnit tutorial.
Software test specification.
2. Background
Testing is the process of executing a program with the intent of finding errors. A good
test case is one with a high probability of finding an as-yet undiscovered error. A
successful test is one that discovers an as-yet-undiscovered error.
The causes of the software defects are: specification may be wrong; specification may
be a physical impossibility; faulty program design; or the program may be incorrect.
3. CASE Tools
JUnit is an open-source project to provide a better solution for unit testing in Java. It
can be integrated with many Java IDEs.
Central idea: create a separate Java testing class for each class you’re creating, and
then provide a means to easily integrate the testing class with the tested class for unit
testing.
48
Software Engineering Lab Manual (ICS 413)
4. In-Class Demo
A tutorial on how to use JUnit with some example will be presented. Please refer to
Lab 13 slides for an overview of software testing and JUnit tutorial with some
examples.
5. Exercises
Write a JUnit test class for testing
public class Exercise {
/** Return the minimum of x and y. */
public static int min(int x, int y) { ... }
}
6. Deliverables
You should submit the solutions for the previous exercise.
Also, if you are building your project using Java, you should use JUnit for
testing.
49