COMPUTER LABORATORY MANUAL

Software Design & Architecture

(SE-210)
Fall Semester
 DEPARTMENT OF COMPUTER SOFTWARE ENGINEERING
Military College of Signals
National University of Sciences and Technology
www.mcs.nust.edu.pk
PREFACE
This Lab Manual has been specially designed with the idea of improving and enhancing the
problem solving skills of students through consistent practice and creativity. There are 15 lab
activities in this Lab Manual, which cover all the topics taught in the BS Software Engineering core
course CSE-474-Software Design & Architecture. The questions have been carefully devised with
the idea of keeping the students interested as well as motivated to complete the designated tasks.
There are tasks included in each lab activity. These tasks are intended to refine a student’s advanced
level skills. After the completion of a lab activity, complete these tasks and submit the files to
course instructor.

PREPARED BY
This Lab manual has been prepared by Lec. Mobeena Shahzad and LE Hira Imtiaz under the
supervision of Dr. Naveed Iqbal Rao, Head of Computer Software Engineering Department, in the
year 2014.

GENERAL INSTRUCTIONS
a. Students are required to maintain the lab manual with them till the end of the semester.
b. All readings/answers to questions/illustrations must be solved in the space provided. If more
space is required then additional sheets may be attached.
c. It is the responsibility of the student to have the manual graded before deadlines as given by the
instructor.
d. Loss of manual will result in resubmission of the complete manual.
e. Students are required to go through the experiment before coming to the lab session. Lab
session details will be given in training schedule.
f. Students must bring the manual in each lab.
g. Keep the manual neat, clean and presentable.
h. Plagiarism is strictly forbidden. No credit will be given if a lab session is plagiarised and no
resubmission will be entertained.
i. Marks will be deducted for late submission.
 VERSION HISTORY

Date Updated By Details

January 2014 Lec Mobeena Shahzad / LE Hira First Version Created
Imtiaz
January 2014 Lec Mobeena Shahzad / LE Hira 14 lab sessions were updated with details
Imtiaz
January 2016 LE Aamna Mehfooz New tool has been included and 14 lab
sessions are updated.
March Lab contents were changed, and new labs
LE Maemoona Kayani
2018 were added
October LE Sehrish Ferdous Lab rubric mapping and lab content has
2019 been updated.
November LE Sehrish Ferdous Labs updated
2020
October LE Sehrish Ferdous Lab Rubrics Updated
2021
September LE Saba Siddique CLOs and labs updated
2022
 Mapping of Lab Experiments
Lab Rubrics (Group 1)
Programming related tasks

Criteria Unacceptable Substandard Adequate Proficient

(Marks=0) Marks=1 Marks=2 Marks=3
The program
execution let to
The program was
inaccurate or The program was
R1 The program failed correctly functional
incomplete results. It correctly functional,
Completeness to produce the right and most of the
was not correctly and all the features
And Accuracy accurate result features were
functional or not all were implemented
implemented
the features were
implemented
The student fails to Student successfully Student successfully Student
figure out the figures out few of figures out most of successfully figures
R2
syntax and syntax and semantic syntax and semantic out all syntax and
Syntax and
semantic errors of errors of the program errors of the program semantic errors of
Semantics
the incorrect with extensive with minimum the program without
program guidance guidance any guidance
Student has
demonstrated on
Student has basic accurate
Student failed to Student has basic knowledge of understanding of
R3 demonstrate a clear understanding, but understanding. the lab objective
Demonstration understanding of asked questions were Provides and concepts. All
the assigned task not answered. fundamental answers the questions are
to asked questions answered
completely and
correctly
The code is readable The code is
R4 The code is poorly
only by someone The code is fairly exceptionally well
Complexity and organized and very
who knows what it is easy to read organized and very
Readability difficult to read
supposed be doing easy to follow
Complete working
program is copied Most of working
Most of working Complete working
R5 indicating no effort program is
program is copied. program is
Perseverance and on student’s part contributed by the
Minor contribution contributed by the
plagiarism resulting in a total student. Minor
by the student student
score of zero for all copied components
rubrics

Lab Rubrics (Group 6)

Simulation based tasks

. Unacceptable Substandard Adequate Proficient

(Marks=0) Marks=1 Marks=2 Marks=3
R1 The system The system let to The system was The system was
 inaccurate or
failed to incomplete results. It correctly functional
correctly functional,
Completeness produce the was not correctly and most of the
and all the features
and Accuracy right accurate functional or not all features were
were implemented
result the features were implemented
implemented
The student is unable
to The student is able to
decompose/transfer analyze and infer the
Fails to The student is able to
R2 problem to results after execution
comprehend the convert conceptual
Complex conceptual model and is able to relate the
problem and its model to
Problems with adequate results to conceptual
implications simulation/program
understanding of the model’s design
complexity of his choices/complexities
design
The student has
The student
demonstrated on
failed to The student has basic The student has
accurate understanding
demonstrate a knowledge of moderate knowledge
R3 of the lab objective
clear understanding but of understanding.
Demonstration and concepts. All the
understanding asked questions were Answer to the
questions are answered
of the assigned not answered. question are basic
completely and
task
correctly
Completetask is
copied
indicating no
Most of task is Most of task is
effort on Complete task is
R4 copied. Minor contributed by the
student’s part contributed by the
Plagiarism contribution by the student. Minor copied
resulting in a student
student components
total score of
zero for all
rubrics
The student
clearly failed to The student knows The student has
The student effectively
use simulation the basic knowledge moderate knowledge
R5 uses simulation tools
tools to design, of simulation tools to of simulation tools to
Modern tool to design, configure,
configure, test design, configure, design, configure, test
Usage test and troubleshoot
and troubleshoot test and troubleshoot and troubleshoot the
given scenario.
the given the given scenario. given scenario
scenario.

Lab Rubrics (Group 3)

Group tasks
Criteria Unacceptable Substandard Adequate Proficient
(Marks=0) Marks=1 Marks=2 Marks=3
R1 The system failed The system The system was The system was
Completeness to produce the right execution let to correctly functional correctly functional,
and Accuracy accurate result inaccurate or and most of the and all the features
incomplete results. It features were were implemented
was not correctly implemented
functional or not all
 the features were
implemented
The student has
demonstrated on
accurate
The student has basic The student has
The student failed understanding of the
knowledge of moderate knowledge
R2 to demonstrate a lab objective and
understanding but of understanding.
Demonstration clear understanding concepts. All the
asked questions were Answer to the
of the assigned task questions are
not answered. question are basic
answered
completely and
correctly
Complete working
program is copied Most of working
Most of working Complete working
indicating no effort program is
R3 program is copied. program is
on student’s part contributed by the
Plagiarism Minor contribution contributed by the
resulting in a total student. Minor
by the student student
score of zero for all copied components
rubrics
Actively helps to
Shows little Demonstrates Demonstrates
R4 identify group goals
commitment to commitment to commitment to
Contribution/ and works
group goals and group goals, but has group goals and
Group effectively to meet
fails to perform difficulty performing carries out assigned
participation them in all roles
assigned roles assigned roles roles effectively
assumed
Poor presentation; Presentation lacks Well-organized,
cannot explain clarity and Presentation clear presentation;
topic; scientific organization; little acceptable; adequate good use of
R5
terminology use of scientific use of scientific scientific
Presentation
lacking or terms and terms; acceptable vocabulary and
skills
confused; lacks vocabulary; poor understanding of terminology; good
understanding of understanding of topic understanding of
topic topic topic

COURSE LEVEL OUTCOMES

SE-210 Software Design and Architecture
Course Learning Outcomes (CLOs)
At the end of the course the students will be able to: PLOs BT Level*
1. Discuss principles and fundamentals of software design and 1 C-2
architecture
2. Apply appropriate design / architectural pattern for a given 2 C-3
problem
3. Select object-oriented models and refine them to reflect 3 C-5
implementation details
4. Demonstrate software principles to analyze and design 9 A-3
applications in collaborative environment
5. Practice system design/architecture by using modern tools 5 P-3
 List of Experiments CLO R-G

1 Software Installation & Configuration 5 6

2 Domain Model 5 6

3 Use Case Diagrams - I 5 6

4 Use Case Diagrams - II 5 6

5 Modular Design 5 6

6 Class Diagram 5 6

7 Interaction Diagrams: Sequence Diagram 5 6

8 Activity Diagram 5 6

9 Deployment Diagram 5 6

10 Package Diagram 5 6

11 Open-Ended Lab 5 6

12 Model View Controller (MVC) Implementation 5 6

13 Microservices Architecture 5 6

14 GoF Patterns - I 5 1

15 GoF Patterns - II 5 1

16 Lab Exam/Project 5 1/3

 MARKS

Max. Marks Obtained Instructor

Date Experiment
Marks R1 R2 R3 R4 R5 Sign
Software Installation & Configuration 15
Domain Model 15
Use Case Diagrams - I 15
Use Case Diagrams - II 15
Modular Design 15
Class Diagram 15
Interaction Diagrams: Sequence Diagram 15
Activity Diagram 15
Deployment Diagram 15
Package Diagram 15
Open-Ended Lab 15
Model View Controller (MVC) 15
Implementation
Microservices Architecture 15
GoF Patterns - I 15
GoF Patterns - II 15

Grand Total
 LIST OF EXPERIMENTS

Table of Contents
EXPERIMENT 1 – SOFTWARE INSTALLATION & CONFIGURATION..................................11
EXPERIMENT 2 – DOMAIN MODEL............................................................................................17
EXPERIMENT 3 – USE CASE DIAGRAMS - I..............................................................................19
EXPERIMENT 4 – USE CASE DIAGRAMS - II.............................................................................22
EXPERIMENT 5 – MODULAR DESIGN........................................................................................24
EXPERIMENT 6 – CLASS DIAGRAM...........................................................................................25
EXPERIMENT 7 – SEQUENCE DIAGRAM...................................................................................29
EXPERIMENT 8 – ACTIVITY DIAGRAM.....................................................................................36
EXPERIMENT 9 – DEPLOYMENT DIAGRAM............................................................................39
EXPERIMENT 10 – PACKAGE DIAGRAM...................................................................................43
EXPERIMENT 11 – OPEN-ENDED LAB.......................................................................................45
EXPERIMENT 12 – MODEL VIEW CONTROLLER (MVC) IMPLEMENTATION...................46
EXPERIMENT 13 – MICROSERVICES ARCHITECTURE..........................................................48
EXPERIMENT 14 – GoF PATTERNS - I.........................................................................................49
EXPERIMENT 15 – GoF PATTERNS - II.......................................................................................53
 EXPERIMENT 1 – SOFTWARE INSTALLATION & CONFIGURATION

Hardware Requirements:
· Computer with Internet access

Software Requirements:
· MS Visio, Visual Paradigm for UML, StarUML, IBM Rational Rose

OBJECTIVE
The purpose of this lab is to give a basic overview of MS Visio. The manual discusses how to
install and use MS Visio. The lab will also cover basic introduction to UML.
INSTALLATING MS VISIO
Software is available at:
\\csdept\data\Resources\Software\Applications\Document Explorers\Office\MS Office 2007 (DVD)
or you can download it from here:
https://getintopc.com/softwares/office-tools/microsoft-visio-2010-premium-free-download-
1059586/
Step 1: Run the setup.exe file.
Step 2: Select Microsoft Office Visio Professional 2007 and click Continue Button.

Step 3: On next screen, enter Product Key and click Continue Button. The Product key is given in
text file named as Serial_No.
Step 4: Check the checkbox “I accept the terms of this agreement” and click Continue Button.
Step 5: Click Install Now Button.
Step 6: Click Close Button when installation is complete.

USING MS VISIO

In today’s lab, we will practice how to make flow charts in MS Visio. The purpose of a flow chart
diagram is to depict the nature and flow of steps in a process. The basic symbols used for drawing a
flow chart are:

Step 1: Now Open Microsoft Office Visio 2007.

Step 2: Click Flow Chart Button from right pane, select basic flow chart and then click Create
Button. Alternate way: On the File menu, point to Shapes, point to the category that you want, and
then click the name of the stencil that you want to use.
The stencils that open with the Basic Flowchart template are called Arrow Shapes, Backgrounds,
and Basic Flowchart Shapes.

Step 3 (Drag and connect shapes): To create your drawing, all you need to do is drag shapes from
stencils onto the blank drawing page and connect them to one another. There are many ways to
connect shapes, but for now let's use the fastest — drag the shapes on top of each other to connect
them automatically by using AutoConnect. For more information, see Add and glue connectors
with AutoConnect.

Drag your first shape from the Basic Flowchart Shapes stencil onto the drawing page, and then
release the mouse button.

Drag your second shape on top of the first so that the blue arrows show, but don't release the
mouse button yet.

While holding the mouse button, move your pointer on top of the blue arrow that points
toward where you want to place the second shape.
 Now release the mouse button. Your shapes are connected, and the first shape points to the
second shape.

Continue to build your drawing by repeating the steps mentioned above.

Step 4 (Add text to shapes):Although some drawings make a point all by themselves, it's often
helpful and sometimes necessary to add text to the shapes. There are many ways to add text to
shapes, but for now let's use the simplest way. If you want to learn more ways to add text to shapes,
see Add data to shapes and Add imported data to shapes.

Add text directly to a shape

1. Double-click the shape.

2. Start typing.

3. When you finish typing, click on a blank area of the drawing page.

The example flow chart for finding the largest among three numbers is given below:
Note: The files are saved with extension: .vid

TASKS

1. Familiarize yourself with menu on top bar (File, Edit etc.).

2. Drawand submit a flowchart to log in to Facebook account

The program works as follows:

 To log in to Facebook account, we first enter the Facebook URL www.facebook.com in our
browser like Google, Firefox, Safari, Internet Explorer etc.
 This request is sent to the Facebook server and it responds by sending us the home page of
Facebook.
 Next, we enter our registered Email ID and Password and click the Login button.
 Then our login credential is checked.
 If it is correct, we are show our profile. On the other hand, if the login credential is wrong
then an error occurs and we are prompted to re-enter our Email ID and Password.

UNIFIED MODELING LANGUAGE (UML)

· The Unified Modeling Language (UML) is a standard graphical modeling language that is used
to express designs.
· Best for modeling large and complex systems.
· Diagrams in UML:

Web Resources

· http://en.wikipedia.org/wiki/Unified_Modeling_Language
· http://office.microsoft.com/en-001/visio-help/a-beginner-s-guide-to-visio-HA102749363.aspx
· http://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

Summary

This lab was the first step in creating any diagram using Visio.The Unified Modeling Language
(UML) is an industry standard for modeling object-oriented systems.UML has three categories:
Things, Relationships and diagrams. These diagrams will be explored in detail in the next lab
experiments.
 EXPERIMENT 2 – DOMAIN MODEL

OBJECTIVE
In this lab, students will learn how to identify real-world objects, their attributes, associations and how to
model all this using Domain Model.

Domain Model

A UML domain model will relate objects in the system domain to each other. It will define concepts
and terms. Objects in the domain model can be:
* Physical objects
* Abstract concepts
List Objects (Concepts)
To help the development of a domain model, it is important to identify nouns and noun phrases.
Concepts that may not ultimately become objects may be listed for completeness and for discussion.
The following types of concepts should be listed:
* Actor roles
* Events
* Transactions
* Objects (physical)
o Other systems
o Organizations

Nouns can be taken from the requirements definitions and use case drawings. This means at this
point all your use case drawings should be done. Actors should not be emphasized in the domain
model.
Domain Model Syntax
After the list of concepts is complete a domain model should be made. Consider which simple items
should be attributes of objects. The domain model is a static model. Time flow, with sequence of
events or information flow is not shown in the domain model. The objects in the domain model are
candidates for programming objects.
NOTE: Domain Models are created using Class Diagram notations.

Case Study: BATS System

The Bank Accounts and Transactions System (BATS) is to be built for the Prime Bank Corporation.
It must handle clients' bank accounts and the services on these accounts, i.e., deposit, withdraw,
transfer, get balance, etc.

The transactions are recorded, because at the end of each month, the system sends out account
statements to all clients showing all transactions performed for their accounts during the last period.
The system sends the statements to the printer from where a junior clerk posts them.

The system is accessed by the bank's clients only indirectly, i.e., either via a teller, or an ATM, or
the Internet. All transactions and queries are possible via a teller; all transactions and queries are
possible except deposits via an ATM; and all except deposits and withdrawals via the Internet.

Opening an account can be performed only via a teller and the Internet; however, if a client opens
an account via the Internet they must identify themselves with a teller to have their account
activated (this is government policy to avoid money laundering, e.g.).
Closing an account can only be performed by a teller, and it requires a final statement to be sent out
to the client. The Bank offers various account types, which fall into two categories: savings and
checking. Savings accounts cannot be overdrawn. There can be a credit limit, subject to agreement
by the bank, on checking accounts; a checking account cannot be overdrawn beyond this limit.

TASKS
Develop a partial Domain model for the given BATS system. Identify the concepts, attributes, and
associations explicitly. This lab task submission must include:
1. List of possible conceptual classes
2. Attributes for each class
3. A partial domain model showing the conceptual classes and association between them.

Web Resources

· http://en.wikipedia.org/wiki/Domain_model
· http://csis.pace.edu/~marchese/CS389/L8/DomainModel-UML_short.pdf
· http://documentation.genesez.org/javaee/de.genesez.uml.modeling.domain.html

Summary

A Domain Model is used to represent entities and it illustrates meaningful concepts in a problem domain. It
may show concepts, associations between concepts and attributes of concepts.
 EXPERIMENT 3 – USE CASE DIAGRAMS - I

OBJECTIVE
In today’s lab, students will learn how to draw use case diagrams. First an introduction will be given; next
students will practice an exercise related to use case diagrams.
Use Case Diagram:
• A use case describes how a user uses a system to accomplish a particular goal. 
• Use Case Diagrams are used to depict the functionality of a system.
• They are widely used to illustrate the functional requirements of the system and its interaction with
external agents(actors).
• A use case diagram gives us a high level view of the system.
• Use case model is a representation of sequence of transactions initiated by the user (actor) from
outside the system.
Components of Use Case Diagram:
A use case diagram contains four main components
Actor:Actors are usually individuals involved with the system defined according to their roles. The
actor can be a human or other external system.

Use Case:A use case describes how actors uses a system to accomplish a particular goal. Use cases
are typically initiated by a user to fulfill goals describing the activities and variants involved in attaining the
goal.

System boundary:The system boundary defines the system of interest in relation to the world around it.

Relationship: The association between and among the actors and the use cases.

1. <<extends>>:It extends the base use case and adds more functionality to the system. Here are a few
things to consider when using the <<extend>> relationship.

i. The extending use case is dependent on the extended (base) use case .
In the below diagram the “Calculate Bonus” use case doesn’t make much sense without the “Deposit
Funds” use case.The extending use case is usually optional and can be triggered conditionally. In the
diagram, you can see that the extending use case is triggered only for deposits over 10,000 or when the age is
over 55.

ii. The extended (base) use case must be meaningful on its own .
This means it should be independent and must not rely on the behavior of the extending use case.
2. <<includes>>: Include relationship show that the behavior of the included use case is part of the
including (base) use case. The main reason for this is to reuse common actions across multiple use cases.
In some situations, this is done to simplify complex behaviors.
Few things to consider when using the <<include>> relationship.
a. The base use case is incomplete without the included use case.
b. The included use case is mandatory and not optional.
3. Generalization of a Use Case:

The general use case is abstract. It cannot be instantiated, as it contains incomplete information. The title of
an abstract use case is shown in italics.

How to Draw a Use Case Diagram?

A Use Case model can be developed by following the steps below.

1. Identify the Actors (role of users) of the system.

2. For each category of users, identify all roles played by the users relevant to the system.
3. Identify what are the users required the system to be performed to achieve these goals.
4. Create use cases for every goal.
5. Structure the use cases.
6. Prioritize, review, estimate and validate the users.

Case Study
Hurry's require a new point of sale and stock control system for their many stores throughout the
UK to replace their ageing mini based systems.
A sales assistant will be able to process an order by entering product numbers and required
quantities into the system. The system will display a description, price and available stock. In-stock
products will normally be collected immediately by the customer from the store but may be selected
for delivery to the customer's home address for which there will be a charge. If stock is not
available, the sales assistant will be able to create a backorder for the product from a regional
warehouse. The products will then either be delivered direct from the regional warehouse to the
customer's home address or to the store for collection by the customer. The system will allow
products to be paid for by cash or credit card. Credit card transactions will be validated via an
online card transaction system. The system will produce a receipt. Order details for in-stock
products will be printed in the warehouse including the bin reference, quantity, product number and
description. These will be collected by the sales assistant and given to the customer. The sales
assistant will be able to make refunds, provided a valid receipt is produced. The sales assistant will
also be able to check stock and pricing without creating an order and progress orders that have been
created for delivery.
The store manager will be able at any time to print a summary report of sales in the store for
a given period, including assignment of sales to sales assistants in order to calculate weekly sales
bonuses.
The stock manager will be able to monitor stock levels and weekly run-rates in order to set
minimum stock levels and requisition products which fall below the minimum stock levels or for
which demand is anticipated. When the stock arrives it will be booked in by the warehouse person.
Stock that has been backordered for collection from the store is held in a separate area and the store
manager advised of its arrival.
The catalogue of available products will be maintained remotely by marketing from head
office. Marketing will also be able to access sales information from each store system.

TASKS
1. Enlist all the possible Actors in the above scenario.
2. Enlist all the possible Use Cases in the above scenario.
3. Draw the detailed use-case diagram of the above requirement specifications.

Web Resources
· http://en.wikipedia.org/wiki/Use_Case_Diagram
· http://office.microsoft.com/en-ca/visio-help/create-a-uml-use-case-diagram-HP081550218.aspx
· http://www.math-cs.gordon.edu/courses/cs211/ATMExample/UseCases.html

Summary

Use Case Diagram defines how our system will interact with the outside world. Use case model is a
representation of sequence of transactions initiated by the user (actor) from outside the system. The main
concepts in use cases are Actors, Use Cases and Associations.

EXPERIMENT 4 – USE CASE DIAGRAMS - II

OBJECTIVE
In today’s lab, students will learn how to write use case description. The students will practice an
exercise related to use case description.

Case Study:
An ATM allows users to perform basic financial transactions
· View their account balance
· Withdraw cash
· Transfer funds
· Authenticate User
Authenticating a user
· based on account number and (PIN)
· bank's account information database
o stores an account number, a PIN and a Balance
ATM Session
· Display a welcome message and prompt the user to enter an account number.
· The user enters a five-digit account number, using the keypad.
· The screen prompts the user to enter the PIN
· The user enters a five-digit PIN, using the keypad.
· If the user enters a valid account number and the correct PIN for that account, the screen
displays the main menu.
· If the user enters an invalid account number or an incorrect PIN, the screen displays an
appropriate message, then the ATM returns to Step 1 to restart the authentication process.
· When an invalid option is entered, display an error message, then redisplay the main menu
1 – View My Balance
· Displays the user's account balance.
· ATM retrieves the balance from the bank's database
2 – Withdraw Cash
· Display withdrawal menu

· withdrawal amount greater than balance

o Display message, ask for smaller amount
o Choose option to exit
o Display main menu

· Valid withdrawal amount is valid

o Authenticate user – ask for pin
o If amount > than ATM money in dispenser
o Display message to ask for smaller amount
o Display Withdrawal menu
o Debit the withdraw amount for balance in database
o Dispense the money
· Display a message reminding the user to take the money

3- ATM Session
· When a transaction is executed
· redisplay the main menu
· If the user chooses to exit the system
· display a thank you message
· then display the welcome message for the next user.
USE CASE NARRATIVE:

Use Case ID: Number or ID of the Use Case in the list.

Use Case Name:  A clear verb/noun or actor/verb/noun descriptor that communicates the
 scope of the use case.
Actors: A list of the types of users who can engage in the activities described in
the use case. Actor names should not correspond to job titles.
Created By: Person who created the Last Updated By: Last time use case was
use case updated
Date Created: Date when use case Date Last Updated: Date when it was last
was created. updated. Latest version
creation date.
Description: A brief paragraph of text describing the scope of the use case.
Preconditions: Anything the solution can assume to be true when the use case begins.
Post conditions: Anything that must be true when the use case is complete.
Normal Flow The set of steps the actors take to accomplish the goal of the use case. A
(primary scenario): clear description of what the system does in response to each user action.
Alternative Flows: Capture the less common user/system interactions, such as being on a
new computer and answering a security question.
Exception flows: The things that can happen that prevent the user from achieving their
goal, such as providing an incorrect username and password.
TASK

Draw the detailed use-case diagram and description keeping in mind the requirement
specifications described above.

Web Resources

· http://en.wikipedia.org/wiki/Use_case
· http://www.pearsonhighered.com/assets/hip/us/hip_us_pearsonhighered/samplechapter/
0201709139.pdf
· http://www.cs.ucc.ie/~herbert/CS4504/Larman%20chapters/larman-ch6-applying-evolutionary-
use-cases.pdf

Summary:Use Case Description is a narrative document that describes the sequence of system events and
the system responses originating from the initiating actors of the system. The description showed both the
basic flow and the alternate flow of events, which will be used as a guidance for dynamic modelling of the
system.

EXPERIMENT 5 – MODULAR DESIGN

OBJECTIVE
The aim of this lab is to introduce students to the concept of creating a modular design.
MODULAR DESIGN
In systems engineering, modular design — or "modularity in design" — is an approach that subdivides a
system into smaller parts (modules) that can be independently created and then used in different systems to
drive multiple functionalities. A modular system can be characterized by the following:
· Functional partitioning into discrete scalable, reusable modules consisting of isolated, self-contained
functional elements.
· Rigorous use of well-defined modular interfaces, including object-oriented descriptions of module
functionality.
· Ease of change to achieve technology transparency and, to the extent possible, make use of industry
standards for key interfaces.

Effective Modular Design:

Modularity has become an accepted approach in all engineering disciplines. A modular design reduces
complexity, facilitates change (a critical aspect of software maintainability), and results in easier
implementation by encouraging parallel development of different parts of a system.

Functional Independence:
Functional independence is achieved by developing modules with "single-minded" function and an
"aversion" to excessive interaction with other modules. Stated another way, we want to design software so
that each module addresses a specific sub function of requirements and has a simple interface when viewed
from other parts of the program structure.
Independence is measured using two qualitative criteria: cohesion and coupling.
· Cohesion is a measure of the relative functional strength of a module.
· Coupling is a measure of the relative interdependence among modules.

TASK
Create a modular Design for a hospital Management System. The SRS is provided with the lab
manual.

Web Resources

· http://en.wikipedia.org/wiki/Modular_design
· http://courses.cs.washington.edu/courses/cse403/96sp/coupling-cohesion.html
· http://msdn.microsoft.com/en-us/magazine/cc947917.aspx
· http://ehrscience.com/2012/11/12/coupling-and-cohesion-a-view-of-software-design-from-the-
inside-out-2/
Summary

A modular design reduces complexity, facilitates change and results in easier implementation. It is an
approach that subdivides a system into smaller parts (modules) that can be independently created and then
used in different systems. These concepts were applied on the given case study.

EXPERIMENT 6 – CLASS DIAGRAM

OBJECTIVE
The aim of this lab is to introduce students to the concept of UML class diagrams. Scenario shall be given to
the user for which they shall have to create a class diagram.
CLASS DIAGRAM
Class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes
the structure of a system by showing the system's classes, their attributes, operations (or) methods and the
relationships between the classes.
The class diagram is used both for general conceptual modeling of the systematic of the application, and for
detailed modeling translating the models into programming code. The classes in a class diagram represent
both the main objects and or interactions in the application and the objects to be programmed.
CLASS DIAGRAM NOTATIONS
The UML representation of a class is a rectangle containing three compartments stacked vertically, as shown
in the Figure:
1. Class :

a. Attribute: The attribute section of class lists each of the class's attributes on a separate line.
Format: name: attribute type (e.g. cardNumber : Integer).
b. Operation: The operations are documented in the bottom compartment of the class
diagram's rectangle.
Like the attributes, the operations of a class are displayed in a list format, with each operation on its
own line.
Operations are documented using this notation: name (parameter list: type of value
returned (e.g. calculateTax (Country, State) : Currency).

2. ASSOCIATION:
I. Bidirectional (standard) association - An association is a linkage between two classes.
• Associations are always assumed to be bi-directional; this means that both classes are aware of
each other and their relationship.
• A bi-directional association is indicated by a solid line between the two classes.

• Multiplicity: Place multiplicity notations near the ends of an association.

• These symbols indicate the number of instances of one class linked to one instance of the other class.
• For example, one company will have one or more employees, but each employee works for one
company only.
 • Visibility: Visibility is used to signify who can access the information contained within a class
denoted with +, - and # as show in the figure:

II. Generalization:
 A generalization is a relationship between a general thing (called the superclass) and a
more specific kind of that thing (called the subclass).
 Generalization is established through the process of inheritance.
 In a class diagram, generalization relationship is rendered as a solid directed line with a
large open arrowhead pointing to the parent class.

III. Composition
Relationships
It implies a relationship where the
child cannot exist independent of the
parent. Example: House (parent) and
Room (child). Rooms don't exist
separate to a House.The black diamond represents composition.
Composition relationships are a strong form of containment.
IV. Aggregation
Aggregation implies a relationship where the child can exist independently of the parent. Example:
Class (parent) and Student (child). Delete the Class and the Students still exist. It is weak form of
association. Aggregation is denoted with an open diamond. This relationship denotes that the
aggregate class (the class with the white diamond touching it) is in some way the “whole”, and the
other class in the relationship is somehow “part” of that whole.
Task:

Create a class diagram according to the case study. Also mention classes and relationships between each
class.

Web Resources

· http://en.wikipedia.org/wiki/Class_diagram
· http://www.tutorialspoint.com/uml/uml_class_diagram.htm
· https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/
· http://msdn.microsoft.com/en-us/library/dd409437.aspx

Summary

The class diagram is used both for general conceptual modeling of the systematic of the application, and for
detailed modeling translating the models into programming code. It describes the structure of a system by
showing the system's classes, their attributes, operations (or) methods and the relationships between the
classes.
 EXPERIMENT 7 – SEQUENCE DIAGRAM

OBJECTIVE

The objective of this lab is to practice sequence diagrams.

SEQUENCE DIAGRAMS
UML sequence diagrams model the flow of logic within your system in a visual manner, enabling
you both to document and validate your logic, and are commonly used for both analysis and design
purposes.A sequence diagram describes an interaction among a set of objects participated in a
collaboration (or scenario), arranged in a chronological order. It shows the objects participating in
the interaction by their "lifelines" and the messages that they send to each other.
SEQUENCE DIAGRAM NOTATIONS
1. Lifeline: A lifeline represents an individual participant in the Interaction.

2. Actor: An Actor is a type of role played by an entity that interacts with the subject. They
typically represent roles played by human users, external hardware, or other subjects.

3. Activation: It is represented by a thin rectangle on a lifeline represents the

period during which an element is performing an operation.The top and the bottom of the of
the rectangle are aligned with the initiation and the completion time respectively
 4. Messages
 Call Message: A call message defines a particular communication between lifelines
of an interaction, which represents an invocation of operation of target lifeline.

 Return Message: A return message defines a particular communication between

lifelines of an interaction, which represents the pass of information back to the caller
of a corresponded former message.

 Self-Message: A self-message defines a particular communication between lifelines

of an interaction, which represents the invocation of message of the same lifeline.

EXAMPLE
The sequence diagram example below shows the interactions between a user and a ticket booking
system in booking a seat. It consists of mainly four parts:
• The actor, which is the user,
• The boundary object ‘interface',
• The controller object ‘mainController' and
• Two entity objects routes and route.
Case Study: ATM Cash Withdrawal

10. Briefe Description

This use case describes how the Bank Customer uses the ATM to withdraw money to
his/her bank account.
11. Actors

· Bank Customer
· Bank

12. Pre-conditions

· There is an active network connection to the Bank.

· The ATM has cash available.

13. Basic Flow of Events

1) The use case begins when Bank Customer inserts their Bank Card.
2) Use Case: Validate User is performed.
3) The ATM displays the different alternatives that are available on this unit. In this case the
Bank Customer always selects “Withdraw Cash”.
4) The ATM prompts for an account.
5) The Bank Customer selects an account.
6) The ATM prompts for an amount.
7) The Bank Customer enters an amount.
8) Card ID, PIN, amount and account is sent to Bank as a transaction. The Bank Consortium
replies with a go/no go reply telling if the transaction is ok.
9) Then money is dispensed.
10) The Bank Card is returned.
11) The receipt is printed.
12) The use case ends successfully.

14. Alternative Flows

5.1 Invalid User

If in step 2 of the basic flow Bank Customer the use case: Validate User does not complete
successfully, and then the use case ends with a failure condition

5.2 Wrong account

If in step 8 of the basic flow the account selected by the Bank Customer is not associated
with this bank card, then
1. The ATM shall display the message “Invalid Account – please try again”.
2. The use case resumes at step 4.

5.3 Wrong amount

If in step 7 in the basic flow, the Bank Customer enters an amount that can't be 'created' with
the kind of in the ATM, then
1. The ATM shall display the message indicating that the amount must be a multiple of the
bills on hand, and ask the Bank Customer to reenter the amount.
2. The use case resumes at step 7.

5.4 Amount Exceeds Withdrawal Limit

If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the
withdrawal limit (See Special Requirement WC-2 for maximum amount), then
1. The ATM shall display a warning message, and ask the Bank Customer to reenter the
amount
2. The use case resumes at step 7

5.5 Amount Exceeds Daily Withdrawal Limit

If in step 8 in the basic flow, the Bank response indicates the daily withdrawal limit has been
exceeded (this is determined by the Bank and depends upon the specific account), then
1. The ATM shall display a warning message, and ask the Bank Customer to reenter the
amount.
2. The use case resumes at step 7.

5.6 Insufficient Cash

If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the amount
of cash available in the ATM, then
1. The ATM will display a warning message, and ask the Bank Customer to reenter the
amount.
2. The use case resumes at step 7.

5.7 No Response from Bank

If in step 8 of the basic there is no response from the Bank within 3 seconds, then
1. The ATM will re-try, up to three times.
2. If there is still no response from the Bank, the ATM shall display the message “Network
unavailable – try again later”.
3. The ATM shall return the card.
4. The ATM shall indicate that it is “Closed”.
5. The use case ends with a failure condition.

5.8 Money Not Removed

If in step 9 of the basic flow the money is not removed from the machine within 15 seconds,
then
1. The ATM shall issue a warning sound and display the message “Please remove cash”.
2. If there is still no response from the Bank Customer within 15 seconds the ATM will re-
tract the money and notes the failure in the log.
 3. The use case end with a failure condition.
5.9 Quit

If at point prior to step 8 in the basic flow the Bank Customer selects Quit, then
1. The ATM shall print a receipt indicating the transaction was cancelled.
2. The ATM shall return the card.
3. The use case ends.
15. Key Senarios
6.1 No Response from Bank
16. Post-conditions
7.1 Successful Completion
The user has received their cash and the internal logs have been updated.
7.2 Failure Condition
The logs have been updated accordingly.

17. Special Requirements

· The ATM shall dispense cash in multiples of $20.

· The maximum individual withdrawal is $500.
· [SpReq:WC-1] The ATM shall keep a log, including date and time, of all complete
and incomplete transactions with the Bank.
NOTE

4. Start MS Visio. Select Software and Databases category. Select UML Model Diagrams.
5. Select Sequence Diagrams.
6. An actor notation can be added from the use-case diagram section and ‘Life Line’ object can
be used with it instead of an ‘Object Life Line’.
Task

Draw the sequence diagram for the above mentioned case study.

Web Resources

· http://en.wikipedia.org/wiki/Sequence_diagram
· http://www.ibm.com/developerworks/rational/library/3101.html
· http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html
· http://www.tracemodeler.com/articles/a_quick_introduction_to_uml_sequence_diagrams/
Summary

Sequence diagrams are used to display the interaction among users, screens, objects, and entities
within the system. They provide a sequential map of message passing between objects over time.
The object interaction was clearly depicted in the diagram of the mentioned problem.
 EXPERIMENT 8 – ACTIVITY DIAGRAM

OBJECTIVE
The aim of this lab is to introduce students to the concept of activity diagrams. The same shall be
drawn using MS Visio.

ACTIVITY DIAGRAM
The purpose of the activity diagram is to model the procedural flow of actions that are part of a
larger activity.
Activity Diagram is similar to a business work flow diagram or simply a flowchart with much richer
semantics.The great strength of activity diagrams lies in the fact that they support and encourage parallel
behavior.
ACTIVITY DIAGRAM NOTATIONS:
Initial Node: The starting state before an activity takes place is depicted using the initial state.
The Initial State from the UML Activity Diagram marks the entry point and the initial Activity State.

Final Node: In the UML, a final action state is shown using a circle surrounding a small solid filled circle (a
bull's eye).

Decision Node: A decision node accepts tokens on an incoming edge and presents them to multiple outgoing
edges.

Merge Node: A merge node is a control node that brings together multiple alternate flows.A merge node has
multiple incoming edges and a single outgoing edge.

Fork Node: A fork node is a control node that splits a flow into multiple concurrent flows. A fork node has
one incoming edge and multiple outgoing edges.
Join Node: A join node is a control node that synchronizes multiple flows. A join node has multiple
incoming edges and one outgoing edge.

Control Flow: Action flows or Control flows are also referred to as paths and edges. They are used to show
the transition from one activity state to another. An activity state can have multiple incoming and outgoing
action flows. We use a line with an arrow head to depict a Control Flow. 
How to Create Activity Diagram:

4. Go to FileNewSoftware & DatabaseUML ModelDiagram.

5. Select UML Activity stencil from Shapes Menu.
6. Drag an Action State or State shape onto the drawing page for each action or activity state you
want to represent. Use the Initial State and Final State shapes to represent initial and final pseudo
states.
7. Connect Control Flow shapes to State shapes to indicate the change from one state to another.
Indicate the flow of control in an activity diagram:
a. In an activity diagram, drag a Control Flow shape onto the drawing page.
b. Glue the Control Flow shape endpoint (without the arrowhead) to a connection point on the
source Action State or State shape.
c. Glue the Control Flow shape endpoint (with an arrowhead) to a connection point on the
destination Action State or State shape.
d. Double-click the Control Flow shape to add a transition string.
8. Use the complex transition shapes, Transition (Fork) or Transition (Join), to represent the forking
of one action state into multiple parallel states, or the synchronization of multiple action states into
one state.
9. Double-click any shape to open its UML Properties dialog box where you can add a name,
transition string etc.
10. Save the diagram.

TASK

Create an activity diagram of the ATM Cash Withdrawal system explained in Experiment 6.

Web Resources

· http://en.wikipedia.org/wiki/Activity_diagram
· http://www.tutorialspoint.com/uml/uml_activity_diagram.htm
· http://www.sparxsystems.com/resources/uml2_tutorial/uml2_activitydiagram.html
· http://msdn.microsoft.com/en-us/library/dd409465.aspx

Summary

Activity Diagrams are important for modeling system functions. They emphasize the flow of objects and
synchronization of the flow in support of parallel processing. The activity diagram of the given case study
showed important flows of the system.
 EXPERIMENT 9 – DEPLOYMENT DIAGRAM

OBJECTIVE
In today’s lab, students will learn how to draw deployment diagram. First an introduction will be given; next
students will practice an exercise related to deployment diagram.

DEPLOYMENT DIAGRAM

Deployment Diagrams are used to represent system hardware and its software.It tells us what hardware
components exist and what software components run on them.We illustrate system architecture as
distribution of software artifacts over distributed targets. An artifact is the information that is generated by
system software. They are primarily used when software is being used, distributed or deployed over multiple
machines with different configurations.

DeploymentDiagram Notations:

Node: A node is a run-time physical object that represents a computational resource. It is denoted
by a 3D box with the node-name written inside of it. Nodes help to convey the hardware which is
used to deploy the software.You may model the component instances that run or live on a node by
drawing them within the node.Node is a computational resource upon which artifacts are deployed
for execution. A node is a physical thing that can execute one or more artifacts.

Generally, a node has two stereotypes as follows:

<<Device>>

It is a node that represents a physical machine capable of performing computations. A device can be
a router or a server PC. It is represented using a node with stereotype <<device>>.In the UML
model.Following is a representation of a device in UML:

 << execution environment >>

It is a node that represents an environment in which software is going to execute. For example,
Java applications are executed in java virtual machine (JVM). JVM is considered as an
execution environment for Java applications. We can nest an execution environment into a
device node. Following is a representation of an execution environment in UML:
You may model which nodes communicate with one another using the Connection relationship line.

Connection: A connection depicts the communication path used by the hardware to communicate
usually indicates the method i.e. TCP/IP.

Component: A component is a grouping of classes that work together closely.

Artifact: Artifacts represent concrete elements in the physical world that are the result of a
development process.An artifact represents the specification of a concrete real-world entity related
to software development. You can use the artifact to describe an executable file. Artifacts are
deployed on the nodes. The most common artifacts are as follows,

1. Source files
2. Executable files
3. Database tables/schemas
4. Configuration files
5. Libraries
6. Scripts
7. DLL files
8. User manuals or documentation
9. Output files

Examples:
Case Study:
Paradise introduces an online registration and reservation facilities to its customers. For that
purpose it wants to make a system for hotel business names as Hotel Reservation System. A Hotel
Reservation multiple view models is to be created for a Software Product Line, which can be
tailored to the needs of an individual hotel chain or hotel.
The system manages information about rooms, reservations, customers, and customer billing. This
system allows for the hotel guest to search available rooms, make a reservation (after registration).
Up to 2 reservations are possible for each guest. He may be able to confirm reservation, cancel
reservation, modify reservation and pay through credit card or cash.When making a reservation
through a reservation clerk, a customer gives personal details, states the room type, number of
occupants, and dates of arrival and departure.
For VIP guests system allows to make unlimited number of reservations, these guests may include
politicians, foreigners, tourists etc.In addition, several optional and variant capabilities are provided.
For the hotel manager, system allows to alter reservation list i.e. remove rooms, add rooms, change
room details (remember to issue notice to the future guests!)
In addition system maintains list of rooms and reservations in the database, interact with external
payment system for guest payments, apply discounts for long stays, unpopular periods of the year
and for VIPs.

TASKS

Create deployment diagram for the provided scenario.

Web Sources:

 https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-
deployment-diagram/
 https://www.tutorialspoint.com/uml/uml_deployment_diagram.htm

Summary:

Deployment diagrams are important for visualizing, specifying, and documenting embedded,
client/server, and distributed systems. A deployment diagram is just a special kind of class
diagram, which focuses on a system's nodes.
 EXPERIMENT 10 – PACKAGE DIAGRAM

Objective
In this lab students will learn how to construct a package diagram in MS Visio.

Working with Packages

A package is used to group together classes that have some commonality. In UML, a package is displayed
with this symbol:

There are a few common approaches when packaging classes, but you can group the classes together
however you'd like. One approach is to group the classes together by functionality. For example, you might
have a package called Security, which holds all of the classes that deal with application security. You might
have some other packages called Employee Maintenance, Reporting, or Error Handling. The advantage of
this approach is in reuse. If you carefully group your classes together, you end up with packages that are
fairly independent of one another. In this example, you can just pick up the Security package and reuse it in
other applications. Packages can be nested inside each other to further organize your classes.

How to Create a UML Package Diagram

1. On the File menu, point to New, point to Software, and then click UML ModelDiagram.
2. In the tree view (tree view: Displayed in a window in the UML Navigator, a hierarchy in which
each UML element or view (diagram) is represented by an icon. The UML template automatically
creates a tree view of your model.), right-click the package (package: A grouping of model elements
represented in the UML by a symbol that resembles a manila file folder. Each element in a system
can be owned by only one package, and one package can be nested in another.) You want to use as a
container for other packages, point to New, and then click Static Structure Diagram.
A blank page appears, and the UML Static Structure stencil becomes the top-most stencil. The
workspace displays 'Static Structure' as a watermark. An icon representing the diagram is added to
the tree view.
 NOTE    If the tree view is not visible, point to View on the UML menu, and then click Model
Explorer
3. In the tree view, click the name of the static structure diagram (static structure diagram: A diagram
that shows the static structure of a model; that is, the elements that exist (such as classes and types),
the internal structure of the elements, and their relationships to one another.) icon, and then click the
name again. Type a new name for the diagram.
4. Drag a Package shape from the UML Static Structure stencil onto the package diagram drawing
page to indicate one of the packages the top package contains. A package is added to the tree view.
5. Double-click the new package shape to open the UML Package Properties dialog box. Type a
name for the package, such as SubPackage1, type and choose other property values, and then click
OK.
6. Right-click the SubPackage1 icon in the tree view, point to New, and then choose the type of
diagram you want to represent in the sub package.
7. In the tree view, click the name of the static structure diagram icon, and then click the name again.
Type a new name for the diagram, such as SubPackage1 Diagram.
An icon representing the diagram is added to the tree view and the appropriate stencil and a blank
drawing page appear.
8. Drag shapes onto the drawing page to represent the elements the sub package contains.
9. In the tree view, double-click the diagram icon for Package Diagram, and then repeat steps 3
through 7 until you have created all the sub packages you want.

Tasks
Consider an online shopping portal which allows a customer to browse and purchase different products. The
products are arranged under different categories like Books, Computers, and Electronics etc.
Only a registered customer can order a product from this portal. Each registered customer will have his own
shopping cart. He can view, add or remove products in his shopping cart and view his total bill. Final cart is
submitted for payment and details like shipment address are confirmed by the customer. Customer is
confirmed with a shipment id and delivery of goods within 15 days.
Once customer finishes selecting the product/s, he can view the cart and then place the order by providing
details like postal address, number of items etc.
The website is managed by an Administrator. Administrator can add, remove and update categories, products
under each category, their price and quantity. He can also remove or verify customer.

Perform the following tasks:

- Draw Use Case Diagrams
- Group together related use cases into packages.
- Identify all possible classes.
- Then group related classes into packages.

Web Resources

· http://en.wikipedia.org/wiki/Package_diagram
· http://www.math-cs.gordon.edu/courses/cs211/ATMExample/Package.html
· http://www.uml-diagrams.org/package-diagrams.html
· http://www.agilemodeling.com/artifacts/packageDiagram.htm

Summary

A package is used to group together classes that have some commonality. Using Use case Diagram, common
use cases are grouped in packages and similarly common classes are grouped into packages.
 EXPERIMENT 11 – OPEN-ENDED LAB

Problem Description:
The Bank Accounts and Transactions System (BATS) is to be built for the Prime Bank Corporation.
It must handle clients' bank accounts and the services on these accounts, i.e., deposit, withdraw,
transfer, get balance, etc. The transactions are recorded, because at the end of each month, the
system sends out account statements to all clients showing all transactions performed for their
accounts during the last period. The system sends the statements to the printer from where a junior
clerk posts them. The system is accessed by the bank's clients only indirectly, i.e., either via a teller,
or an ATM, or the Internet. All transactions and queries are possible via a teller; all transactions and
queries are possible except deposits via an ATM; and all except deposits and withdrawals via the
Internet. Opening an account can be performed only via a teller and the Internet; however, if a client
opens an account via the Internet they must identify themselves with a teller to have their account
activated (this is government policy to avoid money laundering, e.g.). Closing an account can only
be performed by a teller, and it requires a final statement to be sent out to the client. The Bank
offers various account types, which fall into two categories: savings and checking. Savings accounts
cannot be overdrawn. There can be a credit limit, subject to agreement by the bank, on checking
accounts; a checking account cannot be overdrawn beyond this limit.

Task: For above given problem, design your solution with all possible diagrams.
 EXPERIMENT 12 – MODEL VIEW CONTROLLER (MVC)
IMPLEMENTATION

Objective
The aim of this lab is to introduce students to the concept of Model View Controller Pattern. A
small application shall be designed using this pattern.

Model View Controller Pattern

Model–view–controller (MVC) is a software architecture, currently considered an architectural pattern used
in software engineering. The pattern isolates "domainlogic" (the application logic for the user) from the user
interface (input and presentation), permitting independent development, testing and maintenance of each
(separation of concerns).

· A model is an object representing data, e.g. a database table.

· A view is some form of visualization of the state of the model.
· A controller offers facilities to change the state of the model.
Overview:
Though MVC comes in different flavours, control flow is generally as follows:

1. The user interacts with the user interface in some way (for example, by pressing a mouse button).
2. The controller handles the input event from the user interface, often via a registered handler or
callback, and converts the event into an appropriate user action, understandable for the model.
3. The controller notifies the model of the user action, possibly resulting in a change in the model's
state. (For example, the controller updates the user's shopping cart.)
4. A view queries the model in order to generate an appropriate user interface (for example the view
lists the shopping cart's contents). The view gets its own data from the model. In some
implementations, the controller may issue a general instruction to the view to render itself. In others,
the view is automatically notified by the model of changes in state (Observer) that require a screen
update.
5. The user interface waits for further user interactions, which restarts the control flow cycle.

Task
Create a Model-View Controller Design for the following scenario:

At the beginning of each semester students are given a course catalogue containing a list of course
offerings for the semester. Information about each course, such as professor, department, and
prerequisites will be included to help students make informed decisions.
The new on-line registration system will allow students to select courses for the coming semester.
The students will have to fill an online form in which they shall provide their personal information,
their academic information and their choice of courses. The information provided shall be stored in
a database which can include:
1. Personal information
a. Name
b. Registration Number
c. Contact Number

2. Previous Academic History

a. Semester’s GPA
 b. Previous Semester’s courses.

3. Financial Record
a. Scholarship information (if held)

4. Degree Program registered to.

5. List of available electives from which the student can select the desired course.

6. Information for courses

a. Course/Subject Title
b. Instructor
c. Venue
d. Date and Time

What you need to design:

· Model: Database Design

· View: Interface Design
· Controller: Logic of the application (Class Diagrams)

Web Resources

· http://en.wikipedia.org/wiki/Model–view–controller
· http://www.silverlightshow.net/items/Exploring-the-Model-View-Controller-MVC-pattern.aspx
· http://www.slideshare.net/javierhumaran/model-view-controller-mvc-27875933
· http://poincare.matf.bg.ac.rs/~andjelkaz/pzv/cas4/mvc.pdf

Summary

Using Model–view–controller (MVC), “domainlogic” is isolated from the “user interface”. As a result, we
have independent development, testing and maintenance of each (separation of concerns).
 EXPERIMENT 13 – MICROSERVICES ARCHITECTURE

OBJECTIVE
The aim of this lab is to introduce students to the concept of microservices. The same shall be drawn
using MS Visio.

MICROSERVICES ARCHITECTURE:

Microservices is a service-oriented architecture pattern wherein applications are built as a

collection of various smallest independent service units. It is a software engineering approach that
focuses on decomposing an application into single-function modules with well-defined interfaces.
These modules can be independently deployed and operated by small teams that own the entire
lifecycle of the service.

Task: Design the microservice architecture for a given scenario to fulfill Alice’s request.
Mediamore is an entertainment company which provides streaming media and videos online. It
consists of various genres of TV Shows in different languages. Alice is an avid user of mediamore.
She uses mediamore regularly to watch her favorite series online. She recently missed watching an
episode of her favorite TV show. When Alice logs in to the application, she sees the most
recommended content on her home page. After some searching, she finally finds her TV Show. But
now Alice wants to get her TV Show with a single click.
The components that you should be using while designing are as follows:

 Clients – Different users from various devices send requests. 

 Identity Providers – Authenticates user or client’s identities and issues security tokens.
 API Gateway – Handles client requests.
 Static Content – Houses all the content of the system.
 Management – Balances services on nodes and identifies failures.
 Service Discovery – A guide to find the route of communication between microservices.
 Content Delivery Networks – Distributed network of proxy servers and their data centers.
 Remote Service – Enables the remote access information that resides on a network of IT
devices.

Web Resources

 https://www.edureka.co/blog/microservices-tutorial-with-example
 https://www.tutorialspoint.com/microservice_architecture/
microservice_architecture_introduction.htm

Summary

Microservices is an architecture wherein all the components of the system are put into
individual components, which can be built, deployed, and scaled individually. In this lab, students were
taught to implement the microservice architecture for a specific problem.
 EXPERIMENT 14 – GoF PATTERNS - I

OBJECTIVE
The objective of this lab is to demonstrate the application of Singleton, Observer and Facade Patterns.

1. SINGLETON PATTERN
Singleton pattern is one of the simplest design patterns in Java. This type of design pattern comes
under creational pattern as this pattern provides one of the best ways to create an object.
The singleton pattern restricts the instantiation of a class to one object.This pattern involves a
single class which is responsible to create an object while making sure that only single object gets
created. This class provides a way to access its only object which can be accessed directly without
need to instantiate the object of the class.
The Chocolate Factory
Everyone knows that all modern chocolate factories have computer controlled chocolate boilers.
The job of the boiler is to take in chocolate and milk, bring them to a boil, and then pass them on to
the next phase of making chocolate bars.
Here’s the controller class for Choc-O-Holic, industrial strength Chocolate Boiler. Check out the
code; you’ll notice they’ve tried to be very careful to ensure that bad things don’t happen, like
draining 500 gallons of unboiled mixture, or filling the boiler when it’s already full, or boiling an
empty boiler!

public class ChocolateBoiler

{
privateboolean empty;
privateboolean boiled;
//This code is only started when the boiler is empty!
public ChocolateBoiler()
{
empty = true;
boiled = false;
}
//To fill the boiler it must be empty, and, once it’s full, we setthe
empty and boiled flags.
public void fill()
{
if (isEmpty())
{
empty = false;
boiled = false;
// fill the boiler with a milk/chocolate mixture
}
}
//To drain the boiler, it must be full (non empty) and also boiled. Once
it isdrained we set empty back to true.
public void drain()
{
if (!isEmpty() &&isBoiled())
{
// drain the boiled milk and chocolate
empty = true;
}
}
//To boil the mixture, the boiler has to be full and not already boiled.
Once it’s boiled we set the boiled flag to true.
public void boil()
{
 if (!isEmpty() && !isBoiled())
{
// bring the contents to a boil
boiled = true;
}
}
publicbooleanisEmpty()
{
return empty;
}
publicbooleanisBoiled()
{
return boiled;
}
}

Task 1

Problem: Choc-O-Holic has done a decent job of ensuring bad things don’t happen.Then
again, you probably suspect that if two ChocolateBoiler instances get loose, some very bad
things can happen.

Turn ChocolateBoiler class into singleton.

2. OBSERVER PATTERN

Publishers + Subscribers = Observer Pattern

• Subscribers register themselves to Publishers as “Observers”
• Publisher notify registered subscribers when “publishing”.
· The Observer pattern defines a one-to-many relationship between a set of objects.
· When the state of one object changes, all of its dependents are notified.

The Weather Monitoring application:

The weather station is based on WeatherData object, which tracks current weather conditions (temperature,
humidity, and barometric pressure). Create an application that initially provides three display elements:
current conditions, weather statistics and a simple forecast, all updated in real time as the WeatherData
object acquires the most recent measurements.
Further, this is an expandable weather station and more displays can be added in future.

public class WeatherData

{
// instance variable declarations
public void measurementsChanged()
{
 float temp = getTemperature();
float humidity = getHumidity();
float pressure = getPressure();
currentConditionsDisplay.update(temp, humidity, pressure);
statisticsDisplay.update(temp, humidity, pressure);
forecastDisplay.update(temp, humidity, pressure);
}
// other WeatherData methods here
}

Task 1:
Demonstrate how observer pattern can be used in weather monitoring station.

3. FACADE PATTERN
The Facade Pattern provides a unified interface to a set of interfaces in a subsytem. Facade defines a higher
level interface that makes the subsystem easier to use.
Home Sweet Home Theater:

Just have to do a “few” things… How do it go in terms of classes…

1. Turn on the popcorn popper popper.on();
2. Start the popper popping popper.pop();
3. Dim the lights lights.dim(10);
4. Put the screen down screen.down();
5. Turn the projector on projector.on();
6. Set the projector input to DVD projector.setInput(dvd);
7. Put the projector on wide-screen mode projector.wideScreenMode();
8. Turn the sound amplifier to DVDinput amp.on();
9. Set the amplifier to DVD input amp.setDvd();
10. Set the amplifier volume to medium amp.setSurroundSound();
11. Turn the DVD Player on amp.setVolume(5);
12. Start the DVD Player playing. dvd.on();
dvd.play(movie);
Task 2:
Demonstrate how facade pattern can be used in home theatre system. Create class diagram.

Web Resources

· http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/GoF.1.html
· http://en.wikipedia.org/wiki/Factory_method_pattern
· http://www.oodesign.com/factory-pattern.html
· http://en.wikipedia.org/wiki/Singleton_pattern
· http://en.wikipedia.org/wiki/Software_design_pattern
· http://www.dofactory.com/Patterns/Patterns.aspx
· http://en.wikipedia.org/wiki/Facade_pattern
Summary

A design pattern is a general repeatable solution to a commonly occurring problem in software design.
Design patterns can speed up the development process by providing tested, proven development paradigms.
Creational, Structural and Behavioural design Patterns help to prevent subtle issues that can cause major
problems. These patterns were studied and applied in the given problem.
 EXPERIMENT 15 – GoF PATTERNS - II

OBJECTIVE
The objective of this lab is to demonstrate the applications of Factory, Adapter and Bridge Patterns.

4. FACTORY PATTERN
Define an interface for creating an object, but let subclasses decide which class to instantiate.
Factory Method lets a class defer instantiation to subclasses.

STRUCTURE:

Task 1
Let’s say you have a pizza shop, and as a cutting-edge pizza store owner. So, then you’d add some
code that determines the appropriate type of pizza and then goes about making the pizza:
Public class Pizza
{
Pizza createPizza(String type)
{
Pizza pizza;
if (type.equals(“cheese”))
{
pizza = new CheesePizza();
}
else if (type.equals(“greek”)
{
pizza = new GreekPizza();
}
else if (type.equals(“pepperoni”)
{
pizza = new PepperoniPizza();
}
pizza.prepare(){};
pizza.bake(){};
pizza.cut(){};
pizza.box(){};
}

Public class PizzaStore{

Public static void main (String [] args) {
Pizza p;
p.createPizza(“ cheese”);
p.prepare();
p.bake();
p.cut();
p.box();}}

The classes participating in this task are given above. Create class diagram to represent the
classes and operations as given.
Problem: Now if you want to add or remove more than one type of pizza, you'll need to open the
code and make changes every time. Depending upon the number of classes that use it might take a
lot of work for you to make the change. Plus, you want to avoid altering your classes as much as
possible.
But the pressure is on to add more pizza types
You realize that all of your competitors have added a couple of trendy pizzas to their menus: The
Clam Pizza and the Veggie Pizza. Obviously you need to keep up with the competition, so you’ll
add these items to your menu. And you haven’t been selling many Greek Pizzas lately, so you
decide to take that off the menu:

Clearly, dealing with which concrete class is instantiated is really messing up our orderPizza()

method and preventing it from being closed for modification. But now that we know what is
varying and what isn’t, it’s probably time to encapsulate it.

Task 2
Demonstrate how Factory Method Design Pattern can solve the above mentioned issue.
Once we have a SimplePizzaFactory, our orderPizza() method just becomes a client of that object.
Any time it needs a pizza it asks the pizza factory to make one. Now the orderPizza() method just
cares that it gets a pizza that implements the Pizza interface so that it can call prepare(), bake(),
cut(), and box().

Building a simple pizza factory

We’ll start with the factory itself. What we’re going to do is define a class that encapsulates the
object creation for all pizzas. Here it is...
 Create a class simplepizzafactory
 Define a method for pizza creation
 Implement pizza creation code in this method

Reworking the PizzaStore class

Now it’s time to fix up our client code. What we want to do is rely on the factory to create the
pizzas for us. Here are the changes:

Task 3: Create class diagram to represent the classes and operations after applying factory
method.

5. ADAPTER PATTERN
The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets
classes work together that couldn’t otherwise because of incompatible interfaces.

· The client makes a request to the adapter by calling a method on it using the target interface.
· The adapter translates the request into one or more calls on the adaptee using the adaptee interface.
· The client receives the results of the call and never knows there is an adapter doing the translation.
 Adapting an Enumeration to an Iterator
Old world Enumerators: More recent Collections classes use an Iterator
The early collections types (Vector, Stack, interface that, like Enumeration, allows you to
Hashtable, and a few others) implement a method iterate through a set of items in a collection, but
elements(), which returns an Enumeration. The also adds the ability to remove items.
Enumeration interface allows you to step through
the elements of a collection without knowing the
specifics of how they are managed in the
collectionNew world Iterators:
Task 4:
Write an Adapter that adapts an Enumeration to an Iterator to. You can test your code by adapting to an
ArrayList. The ArrayList class supports the Iterator interface but doesn’t support Enumerations .

6. BRIDGE PATTERN
Bridge is a structural design pattern that lets you split a giant class or a set of closely related classes into two
separate hierarchies, abstraction and implementation, which can be developed independently of each other.

Task 5:

The classes and/or objects participating in this pattern are as given below. Create a class diagram to
represent the classes as given.
devices
publicinterfaceDevice {
publicbooleanisEnabled();

public void enable();

public void disable();

publicintgetVolume();

public void setVolume(int percent);

publicintgetChannel();

public voidsetChannel(int channel);

public void printStatus();

}

public class Radio implements Device {

privateboolean on = false;
privateint volume = 30;
privateint channel = 1;

@Override
publicbooleanisEnabled() {
return on;
}

@Override
public void enable() {
on = true;
}

@Override
public void disable() {
on = false;
}

@Override
publicintgetVolume() {
return volume;
}

@Override
public void setVolume(int volume) {
if (volume >100) {
volume = 100;
}
else if (volume <0) {
volume = 0;
}
this.volume = volume;
}

@Override
publicintgetChannel() {
return channel;
}

@Override
public void setChannel(int channel) {
this.channel = channel;
}

@Override
public void printStatus() {
System.out.println("------------------------------------");
System.out.println("| I'm radio.");
System.out.println("| I'm " + (on ? "enabled" :"disabled"));
System.out.println("| Current volume is " + volume + "%");
System.out.println("| Current channel is " + channel);
System.out.println("------------------------------------\n");
}
}

public class Tv implements Device {

privateboolean on = false;
privateint volume = 30;
privateint channel = 1;
@Override
publicbooleanisEnabled() {
return on;
}

@Override
public void enable() {
on = true;
}

@Override
public void disable() {
on = false;
}

@Override
publicintgetVolume() {
return volume;
}

@Override
public void setVolume(int volume) {
if (volume >100) {
volume = 100;
}
else if (volume <0) {
volume = 0;
}
this.volume = volume;
}

@Override
publicintgetChannel() {
return channel;
}

@Override
public void setChannel(int channel) {
this.channel = channel;
}

@Override
public void printStatus() {
System.out.println("------------------------------------");
System.out.println("| I'm TV set.");
System.out.println("| I'm " + (on ? "enabled" :"disabled"));
System.out.println("| Current volume is " + volume + "%");
System.out.println("| Current channel is " + channel);
System.out.println("------------------------------------\n");
}
}

remotes
public interface Remote {
public void power();

public void volumeDown();

public void volumeUp();

public void channelDown();

public void channelUp();
}

public class BasicRemote implements Remote {

protected Device device;

publicBasicRemote() {}

publicBasicRemote(Device device) {
this.device = device;
}

@Override
public void power() {
System.out.println("Remote: power toggle");
if (device.isEnabled()) {
device.disable();
} else {
device.enable();
}
}

@Override
public void volumeDown() {
System.out.println("Remote: volume down");
device.setVolume(device.getVolume() - 10);
}

@Override
public void volumeUp() {
System.out.println("Remote: volume up");
device.setVolume(device.getVolume() + 10);
}

@Override
public void channelDown() {
System.out.println("Remote: channel down");
device.setChannel(device.getChannel() - 1);
}

@Override
public void channelUp() {
System.out.println("Remote: channel up");
device.setChannel(device.getChannel() + 1);
}
}

public class AdvancedRemote extends BasicRemote {

publicAdvancedRemote(Device device) {
super.device = device;
}

public void mute() {

System.out.println("Remote: mute");
device.setVolume(0);
}
}

Client code
public class Demo {
public static void main(String[] args) {
testDevice(new Tv());
testDevice(new Radio());
}

public static void testDevice(Device device) {

System.out.println("Tests with basic remote.");
BasicRemotebasicRemote = new BasicRemote(device);
basicRemote.power();
device.printStatus();

System.out.println("Tests with advanced remote.");

AdvancedRemoteadvancedRemote = new AdvancedRemote(device);
advancedRemote.power();
advancedRemote.mute();
device.printStatus();
}
}

Web Resources

· http://en.wikipedia.org/wiki/Software_design_pattern
· http://www.dofactory.com/Patterns/Patterns.aspx

Summary

Adapter Pattern is used to define an interface for incompatible interfaces. Bridge Pattern separates
abstraction from implementation. The application of these patterns was shown using an example.