LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

Lab: 02

Introduction to UML
(Unified Modeling Language)
and OO(Object Oriented)
analysis:

BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT

SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

LAB NO. 2 DD/MM/YYYY

INTRODUCTION TO UML (UNIFIED MODELING

LANGUAGE) AND OBJECT-ORIENTED ANALYSIS.

1. Objectives:
After completing this lab, students will be able to.
• Study the benefits of visual modeling.
• Introduction to UML notations and diagrams.
• Why the UML is necessary.
• Involving Object Oriented analysis and design with UML diagrams.
• How to understand the object-oriented mindset
• How objects communicate
• How objects associate with one another
• How objects combine

2. Corresponding CLO and PLO:

 CLO-1,PLO-3

3. Theory:
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
Visual Modeling:
 Capture the structure and behavior of architectures and components.
 Show how the elements of the system fit together.
 Hide or expose details appropriate for the task.
 Maintain consistency between a design and its implementation.
 Promote unambiguous communication.

Unified Modeling Language (UML):

The Unified Modeling Language (UML) enables system builders to create
blueprints that capture their visions in a standard, easy-to understand way, and
provides a mechanism to effectively share and communicate these visions with
others. It does this via a set of symbols and diagrams. Each diagram plays a
different role within the development process.

Components of the UML

 The UML consists of a number of graphical elements that combine to form
diagrams. UML is a language; it has rules for combining these elements.

2
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

 The purpose of the diagrams is to present multiple views of a system; this set of
multiple
 views is called a model.
 A UML model tells what a system is supposed to do.
UML Diagrams

 Class Diagram
 Object Diagram
 Use Case Diagram
 State Diagram
 Sequence Diagram
 Activity Diagram
 Communication Diagram
 Component Diagram
 Deployment Diagram
 Composite Structure Diagram
 Interaction Overview Diagram
 Timing Diagram
 Package Diagram
There are two broad categories of diagrams and they are again divided into
subcategories −
 Structural Diagrams
 Behavioral Diagrams
Structural Diagrams
The structural diagrams represent the static aspect of the system. These static aspects
represent those parts of a diagram, which forms the main structure and are therefore
stable.Structure diagrams show the static structure of the system and its parts on
different abstraction and implementation levels and how they are related to each
other. The elements in a structure diagram represent the meaningful concepts of a
system, and may include abstract, real world and implementation concepts, there are
seven types of structure diagram as follows:
 Class Diagram
 Component Diagram
 Deployment Diagram
 Object Diagram
 Package Diagram
 Composite Structure Diagram
 Profile Diagram
Behavioral Diagrams
Any system can have two aspects, static and dynamic. So, a model is considered as
complete when both the aspects are fully covered.
Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic
aspect can be further described as the changing/moving parts of a system.
Behavior diagrams show the dynamic behavior of the objects in a system, which can
be described as a series of changes to the system over time, there are seven types of
behavior diagrams as follows:
3
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

 Use Case Diagram

 Activity Diagram
 State Machine Diagram
 Sequence Diagram
 Communication Diagram
 Interaction Overview Diagram
 Timing Diagram

4. Procedure:
A big part of building a software system is determining what the customer wants.
We call these requirements, and there are many techniques for eliciting or
discovering requirements from a customer or user.

User Stories

Once a requirement is elicited, it needs to be expressed in some form. One

technique for expressing a requirement is called a user story. A user story is simply
a requirement, often from the perspective of an end-user, which is stated in natural
language. A user story looks like this:

As a ______, I want to ______ so that ______.

Put the user role into the first blank. This may be quite simple for software in which
there is generally only one type of user, or a bit more complex in cases where the
software may do different things for different people. Either way, this clarifies who
wants to use this feature.

In the second blank, put the goal that the user role wants to achieve. This will lead
to some feature that you want to implement.
4
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

After so that, put the reason why the user role wants this goal. Sometimes this
clause is omitted if the benefits are clear and generally known.

After you fill in a user story, you can apply object-oriented thinking to it to discover
objects and possibly further requirements!

Example

Imagine that you introduce the user story technique to your customer, and they
give you the following sentence:

As an online shopper, I want to add an item to my shopping cart, so that I can

purchase it.

Usually, the nouns correspond to objects in your software. So in this example, you
have identified three objects: first, the user role is associated with an object in the
software (the online shopper). An item could be any product at the store, while a
shopping cart is an object for tracking items for purchase.

Let's have another look at the sentence:

As an online shopper, I want to add an item to my shopping cart, so that I can

purchase it.

Verbs can help you identify the requirements that your objects might have. In this
example, add and purchase might be responsibilities of the shopping cart. Verbs
may also help you identify connections between objects.

The last point is a bit more subtle: a user story can also help you discover
connections between objects. In this example, it is probably fairly obvious. One
online shopper is typically associated with one shopping cart. The shopping cart
should be capable of holding multiple items.

Conclusion

User stories are just one of many techniques that can be used to express
requirements for a software system. They are simple to use and can allow you to
apply object-oriented thinking and discover objects and further requirements.
Start using them today, even if the ideas are your own! By identifying objects
before starting implementation, your software will become better structured and
more clear.

Object orientation

5
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

When translated to object-oriented modelling, object-oriented thinking involves

representing key concepts through objects in your software. Note that concepts are
broad in nature. Even instances of people, places, or things can be distinct objects in
software.
Objects may have specific details associated with them, which are relevant to users.
For example, a person object may have details such as name, age, gender, and
occupation. A place object may have a size, or a name. An inanimate object may have
dimensions or a colour.
Objects might also have behaviours or responsibilities associated with them. For
example, a person may have associated behaviours such as sitting down or typing. An
electronic device may be responsible to power on or off, or to display an image.
By using objects to represent things in your code, the code stays organized, flexible,
and reusable.
• Objects keep code organized by putting related details and specific functions
in distinct, easy-to-find places. In the above examples, the details of the objects stay
associated with the objects themselves.
• Objects keep code flexible, so details can be easily changed in a modular
way within the object, without affecting the rest of the code. In the above example of
a person object, a person’s details such as occupation may change, and not affect the
rest of the code.
• Objects allow code to be reused, as they reduce the amount of code that
needs to be created, and keeps programs simple
Design in the Software Process

When software is developed, it generally goes through a process.In simple terms, a

process takes a problem and creates a solution that involves software. A process is
generally iterative. These iterations consist of taking a set of requirements based on
the identified problem(s) and using them to create conceptual design mock-ups and
technical design diagrams, which can then be used to create a working software
implementation, which must also pass testing. This process is repeated for each set
of requirements, eventually creating a complete solution for the project.

Object:
An object has structure. It has attributes (properties) and behavior. An object's
behavior consists of the operations it carries out. Attributes and operations taken
together are called features.
 Person class,
Attributes: height, weight, and age. (You can imagine a number of others.)
Each of us is unique because of the specific values that each of us has for those
attributes.

We also perform these operations: eat, sleep, read, write, talk, go

to work, and more. (Or in objectspeak, eat (), sleep (), read (), write
(), talk (), and goToWork().

If we were to create a system that deals with information on people—say, a system

6
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

for a human resources department—we would likely incorporate some of these

attributes and some of these operations in our software.
In the world of object-orientation, a class serves another purpose in addition to
categorization. A class is a template for making objects—sort of like a cookie
cutter that you use to stamp out cookies. (Some might argue that this is the same
as categorization, but let's avoid that debate.)
 WashingMachine class
Attributes: brandName, modelName, serialNumber, and

capacity Operations: acceptClothes(), acceptDetergent(),

turnOn(), and turnOff()

You have a mechanism for turning out new instances of the

WashingMachine class. That is, you can create new objects based on this
class .

Fig:1

Some Object-Oriented Concepts:

Object-orientation goes beyond just modeling attributes and behavior. It considers other

7
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

aspects of objects as well.

These aspects are called

 Abstraction
 Inheritance
 Polymorphism
 Encapsulation
 Message sending
 Associations
 Aggregation

Abstraction
Abstraction means, simply, to filter out an object's properties and operations until
just the ones you need are left. What does "just the ones you need" mean?

Different type of systems requires different detail.

Example: TO create software to track transactions in a laundry that has a number of

washing machines?

In this program all the detailed attributes and operations are not required. Only
the serialNumber of each washing machine object is required.

In any case, what you're left with, after you've made your decisions about what
to include and what to exclude, is an abstraction of a washing machine.

Inheritance

Washing machines, refrigerators, microwave ovens, toasters, dishwashers,

radios, waffle makers, blenders, and irons are all appliances. In the world of
object orientation, we would say that each one is a subclass of the Appliance
class. Another way to say this is that Appliance is a superclass of all those
others.

Appliance is a class that has the attributes onOffSwitch and electricWire, and the
operations turnOn() and turnOff(). Thus, if you know something is an appliance,
you know immediately that it has the Appliance class's attributes and operations.

Object-orientation refers to this relationship as inheritance. Each subclass of

Appliance (WashingMachine, Refrigerator, Blender, and so on) inherits the
8
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

features of Appliance. It's important to note that each subclass adds its own
attributes and operations. Fig:2 shows the superclass-subclass relationship.

Fig 2: Superclass-Subclass

Inheritance doesn't have to stop there. Appliance, for example, is a subclass of

the HouseholdItem class. Furniture is another subclass of HouseholdItem, as Fig:
3 shows. Furniture, of course, has its own subclasses.

Fig 3: Superclasses can also be subclasses

and inherit from other superclasses.

Polymorphism
Sometimes an operation has the same name in different classes. For example,
you can open a door, you can open a window, and you can open a newspaper, a
present, a bank account, or a conversation. In each case you're performing a
different operation. In object-orientation each class "knows" how that operation
is supposed to take place. This is called polymorphism see Fig 4.

9
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

Fig 4: In polymorphism an operation can have the same name in different

classes, and proceed differently in each class.

Encapsulation
When an object carries out its operations, those operations are hidden Fig
5.When most people watch a television show, they usually don't know or care
about the complex electronics components that sit in back of the TV screen and
all the many operations that have to occur in order to paint the image on the
screen. The TV does what it does and hides the process from us. Most other
appliances work

Fig 5: An example of Encapsulation

Why is this important? In the software world, encapsulation helps cut down on
the potential for bad things to happen. In a system that consists of objects, the
objects depend on each other in various ways. If one of them happens to
malfunction and software engineers have to change it in some way, hiding its
operations from other objects means that it probably won't be necessary to
change those other objects.

Message Sending
In a system, objects work together. They do this by sending messages to one

10
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

another. One object sends another a message—a request to perform an operation

and the receiving object performs that operation.

Example: A TV and a remote present a nice intuitive example. When you want to
watch a TV show, you hunt around for the remote, settle into your favorite chair,
and push the on button. What happens?

 The remote-object sends a message (literally!) to the TV-object to turn it-

self on.
 The TV-object receives this message, knows how to perform the turn-
on operation, and turns itself on Fig 6.
When you want to watch a different channel, you click the appropriate button on
the remote, and the remote-object sends a different message—"change the
channel"—to the TVobject. The remote can also communicate with the TV via
other messages for changing the volume, muting the volume, and setting up
closed captioning.

Fig 6: An example of message sending from one object to another. The remote-object sends a
message to the TV-object to turn itself on. The TV-object receives the message through its

Interface, an infrared receiver.

Associations
Another common occurrence is that objects are typically related to one another in
some fashion. For example, when you turn on your TV, in object-oriented terms,
you're in an association with your TV.
The "turn-on" association is unidirectional (one-way), as in Fig 7.That is, you
turn your TV on. Unless you watch way too much television, however, it doesn't
return the favor. Other associations, like "is married to," are bidirectional; Fig 8.

11
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

Fig 7: Objects are often associated with each other in some way. When you turn on your TV,
you're in a unidirectional association with it.

Fig 8: Objects are sometimes associated with each other in more than one way.

Fig 9: A class can associate with more than one classes

Aggregation

Think about your computer system. It consists of a CPU box, a keyboard, a

mouse, a monitor, a CD-ROM drive, one or more hard drives, a modem, a disk
drive, a printer, and possibly some speakers. Inside the CPU box, along with the
aforementioned drives, you have a CPU, a graphics card, a sound card, and some
other elements you would undoubtedly find it hard to live without.

Your computer is an aggregation, another kind of association among objects.

Like many other things worth having, the computer is made from a number of
different types of components (see Fig 10).

12
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

Fig 10: A typical computer system is an example of an aggregation—an object that's made up
of a combination of a number of different types of objects.

One form of aggregation involves a strong relationship between an aggregate object

and its
Component objects. This is called composition. The key to composition is that
the component exists as a component only within the composite object. For
example, a shirt is a composite of a body, a collar, sleeves, buttons, buttonholes,
and cuffs. Do away with the shirt and the collar becomes useless. Sometimes a
component in a composite doesn't last as long as the composite itself. The leaves
on a tree can die out before the tree does. If you destroy the tree, the leaves also
die (see Fig11).

Fig 11: In a composition, a component can sometimes die out before the
composite does. If you destroy the composite, you
13
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

destroy the component as well.

5. Equipment’s:
 Star UML
 Edraw Max
 GUI design
Studio

6. Observations:
In this lab we learn about common UML diagrams, Object Oriented Analysis and
Design in UML.

7. Lab Tasks/Assignment

Lab Task 1:
Use user stories to captures a specific requirement of your software system from
the perspective of a user or stakeholder, and provides a clear statement of the
desired functionality and its benefits.

"As a Hostel Manager, I want online room booking, so that the user does not
have to visit us physically."

“As a hostel administrator, I want to be able to easily manage and assign rooms
to incoming students, so that the process is efficient and streamlined.”

“As a Hostel Manager, I want to be able to view and pay fee online, so that I can
easily manage payments and avoid the hassle of manual transaction.”

“As a hostel administrator, I want to implement a secure access control system,

so that only authorized individuals can enter restricted areas such as dormitory
floors or staff rooms.”

Lab Task 2: What is Object Oriented Analysis and Design in UML?

Introduction:
Object-Oriented Analysis and Design (OOAD) is a software engineering
methodology that involves using object-oriented concepts to design and
implement software systems. OOAD involves a number of techniques and
practices, including object-oriented programming, design patterns, UML
diagrams, and use cases. Here are some important aspects of OOAD:

1. Object-Oriented Programming: Object-oriented programming involves modeling

real-world objects as software objects, with properties and methods that represent the
behavior of those objects. OOAD uses this approach to design and implement software
systems.

14
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

2. Design Patterns: Design patterns are reusable solutions to common problems in

software design. OOAD uses design patterns to help developers create more
maintainable and efficient software systems.

3. UML Diagrams: Unified Modeling Language (UML) is a standardized notation for

creating diagrams that represent different aspects of a software system. OOAD uses
UML diagrams to represent the different components and interactions of a software
system.

4. Use Cases: Use cases are a way of describing the different ways in which users
interact with a software system. OOAD uses use cases to help developers understand
the requirements of a system and to design software systems that meet those
requirements.

Lab Task 3: What are common UML diagrams?

 Class Diagram
 Component Diagram
 Object Diagram
 Package Diagram
 Use case Diagram
 Sequential Diagram

15
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

8. Rubrics:
Absent Student is Student can Student has Student has Student
unable to understand followed constructed perfectly
follow the the instructions the implemente
provided provided to construct functional/ d a working
instruction laboratory the working model/
s properly. instructions fundamenta schematic/ logic/
The and l schematic/ model/ circuit/
student familiar block block block
can name with the lab diagram/ diagram/ diagram/
the environmen code/ code, and code and
Demonstratio hardware t (Trainer/ model on have successfully
n or software/ the successfull executed
simulation IDE), but protoboard/ y executed the lab
platform, cannot trainer/ the objective in
but unable implement simulation program/ Realtime or
to on the software. run circuit in a
implement platform on software simulation
anything practically platform environmen
practically or on the t and
or on the software produced
software the desired
results
Category Ungrade Very Poor Poor Fair Good Excellent
d
Percentage [0] [1-20] [21-40] [41-60] [61-80] [81-100]
Marks 0.0 0.1 0.2 0.3 0.4 0.5
Date Total Instructor’s Signature
Marks

Report Plagiarize Requirement Observation Appropriate Correctly

not d content s are listed s are computation drawn
submitted presented and recorded s or conclusio
or experimental along with numerical n with
Laborator
incomplete procedure is detailed analysis is exact
y
submissio presented procedure performed results and
Reports
n complete
report in
all
respects
Category Ungrade Very Poor Poor Fair Good Excellent
d
Percentage [0] [1-20] [21-40] [41-60] [61-80] [81-100]
Marks 0.0 0.1 0.2 0.3 0.4 0.5
Date Total Instructor’s Signature
Marks

16
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.
LAB MANUAL SOFTWAR DESIGN AND ARCHITECTURE

17
BALOCHISTAN UNIVERSITY OF IT, ENGINEERING & MANAGEMENT
SCIENCES, QUETTA.