Software Design and Architecture

SE-308
Practical Workbook

Group Members:
1. Abdul Karim Buksh Ansari (SE-052)
2. Muhammad Hamza Khan (SE-060)
3. Syed Muhammad Hussain (SE-066)
4. Abdur Rafey (SE-093)
5. Muhammad Murtaza Hussain (SE-097)
6. Abdullah Agha (SE-301)
Section: B
Group No: 11
Course Instructor: Miss Sana Fatima
Semester: Fall, 2024

Department of Software
Engineering

NED University of Engineering &

Technology, Karachi – 75270, Pakistan
 Lab 1: Introduction to Unified Modeling Language (UML)

Exercise:
Q1. List the advantages of Unified Modeling Language.
Unified modeling language offers several advantages in system architecture and design that
include:
1. Standardization: UML is a standardized modeling language, that provides a consistent way to
visualize a system architecture. This makes it easier for teams to collaborate across different
platforms and tools.
2. Communication: UML acts as a common language between technical and non-technical team
members, facilitating clearer communication regarding system requirements and design.
3. Visualization: It helps to create visual representations of complex systems, allowing
stakeholders to understand system structure and functionality without needing technical expertise.
4. Improve Planning: Using UML diagrams helps teams to plan and test design early in
development, reducing the possibility of errors later on.
5. Complexity Management: UML reduces the complexity of the project by breaking down the
complex systems into smaller and manageable components, thus improving clarity and
organization.
6. Reusability: UML promotes the reuse of components and system designs across different
projects, improving efficiency.
7. Better Design Practices: It follows best practices in object-oriented design, helping to build
scalable and maintainable systems.
Q2. Explain different kinds of UML diagram and their significance.
Here is a list of different types of UML diagrams, grouped into structural and Behavioral Diagrams,
along with their description and their importance:
A. Structural Diagrams:

• Class Diagram:
Description:
Class Diagram illustrates the static structure of the system. It shows the classes within the
system, their respective properties or attributes, methods, and the relationship between
classes by way of inheritance, association, or dependency.
Significance:
• It helps to understand the structure of the system.
• Provides the blueprint for designing and developing the system.
• It is the backbone of application.

• Object Diagram
Description:
An Object Diagram is a snapshot of instances, referred to as objects, of a class at a certain
instance in time. It provides real-life examples of how classes are instantiated together with
their objects and how they relate.
Significance:
• It represents the state of the system at one instance in time.
• It comes in very handy in debugging as it illustrates objects interacting in natural
scenarios.
• Helps in the validation of class diagrams by showing real-time instances.

• Component Diagram
Description:
The Component Diagram breaks down the system into components or modules. Such
components may include fragments of source code, libraries, and subsystems. These are
developed individually and integrated at later stages.
Significance:
• This helps in understanding the modular architecture of the system.
• Useful in identifying the reusability of a particular component across different parts
of the system.
• Also, it clarifies how several components interact with each other and form the final
system.
• Deployment Diagram
Description :
Deployment Diagram: It depicts the physical structure of the system. It maps the
components onto the hardware nodes like servers, workstations that will host them.
Significance:
• Useful to comprehend the physical deployment of the system.
• For system administrators, this gives knowledge about where the software
components are deployed and how they interact with the hardware.
• Vital in planning the hardware infrastructure in real-world environments.

B. Behavioral Diagrams:

• Use Case Diagram:

Description:
A Use Case Diagram depicts the interaction between the external actors, which includes users
or other systems, and the system itself. This identifies various use cases or scenarios where the
system is performing something.
Significance:
• Captures the functional requirements of the system from a user's perspective.
• Good to use during the preliminary stages in designing a system to uncover all possible
user interactions.
• Gives a clear view of what the system needs to achieve.

• State Diagram
Description:
A State Diagram depicts the set of all states an object can possess in its lifetime and how it
changes from one state to another on the occurrence of some event.
Significance:
• Useful in modeling systems where object behavior is crucial.
• Helps to identify how the life cycle of objects and how the external factors change
their states.
• Good for a system that involves time-dependent or event-dependent behavior.
• Sequence Diagram
Description:
A Sequence Diagram depicts the interaction of objects with a time-ordered sequence. This
diagram shows how objects send and receive messages to achieve some process or task
over time.
Significance:
• Provides step-by-step details on how objects communicate with one another.
• Good to know if some workflow or some set of interactions must occur in a certain
order.
• Easy to debug complicated interactions by viewing the flow of messages.

• Activity Diagram
Description:
An activity diagram represents the flow of activities or actions in a system. It describes
how activities are sequenced and the conditions that allow the execution of an activity.
Significance:
• Used to model workflows or business processes.
• Useful to understand how control flows from one activity to another.
• Keeps one informed of concurrent activities or branching paths within a system.

• Communication Diagram
Description:
A Communication Diagram depicts the interactions among objects in terms of messages
exchanged. Unlike Sequence Diagrams, which emphasize the time ordering of messages,
Communication Diagrams emphasize the relationships among participating objects.
Significance:
• It depicts the links and the various relationships among objects.
• It helps one to know structural communication between objects concerning time.
• It helps discover how objects work together to perform a particular task.
 Lab 2 : Introduction to StarUML

Exercise:
Q1. What is 4 + 1 view? Briefly define each view.
The 4+1 view model is a way to define the architecture of software systems using multiple views.
The views are used to describe the system to various stakeholders such as end users, developers,
etc. The four views of the model are logical, development, process and physical view. In addition,
the use case are used to demonstrate the architecture, working as a “plus 1” view. It is referred to
as the “4 + 1” model because the use case have no use in the development phase. They are mainly
for the customers if they have trouble comprehending the SRS document.
Logical View:
It shows how the system is divided into smaller parts (like classes or components) and how these
parts talk to each others to perform the systems functions. The UML diagrams used to represent
the logical view include class diagram, state diagram.
Process View:
The Process View shows how the system works when its actually running. It focuses on how
different task or processes happen at the same time and how they communicate with each other.
The concerned stakeholders are mainly the developers and sometimes the QA. Sequence/Activity
diagrams are used to model the processes
Development View:
The Development View shows how the software is organized from the developers perspective. It
mainly focus on how the system is broken down into smaller parts (like files, modules, or libraries).
Component diagram can be used to showcase the Development view.
Physical View:
The Physical View helps ensures that the software works well in the real world, across multiple
machines and networks. Deployment diagrams can be used to model the interactions.
Use Cases(plus 1):
They describe specific situations or tasks where the system interacts with users or other
systems. They help test if the system works as expected.
Q2. Compare StarUML with any other similar tool and state their significance and
limitations
StarUML vs. Visual Paradigm:
StarUML is a stand-alone UML tool designed specifically for software engineers and architects to
develop complex software design models using UML 2.x , while Visual Paradigm is a full-fledged
modeling tool supporting both UML and BPMN as well as many other advanced features like the
management of requirements, project management, and code engineering. Targets a more general
type of user, from business analysts to project managers.
Feature Comparison:
Features StarUML Visual Paradigm

Platform Desktop-based Desktop-based + Web Client

Collaboration No real-time Supports team collaboration (with

collaboration versioning, and cloud integration)
Customization Customizable with Highly customizable, with project
extensions/plugins management tools
Other Diagram Types ERD, SysML, Data Flow BPMN, ArchiMate, ERD, DFD,
Diagrams Flowcharts, Mind Maps
UML Support Full UML 2.x support Full UML 2.x support + BPMN,
SysML, ArchiMate, etc.

Significance and Limitations of StarUML:

Significance Limitations
Fully supports the UML 2.x specification, Lack of collaboration, unlike cloud-based
making it the best choice for detailed software tools.
design.

Work offline and stand as alone, making it Installation is compulsory, which is not ideal
beneficial without an internet connection. for quick, on-the-go diagramming.

It provides a very clear and user-friendly The absence of integrated version control may
interface for modeling that minimizes the impede collaborative efforts among teams
learning curve for beginners. utilizing Git or alternative versioning systems.
Significance and Limitations of Visual Paradigm:
Significance Limitations
Real-time collaboration and cloud storage Some features, like cloud storage and
enable easy teamwork, data synchronization, collaboration, require an internet connection,
and accessibility from anywhere. and there is limited offline functionality.

Supports complex modeling, advanced UML Due to its more advanced features, Visual
diagrams, and professional software design Paradigm can be difficult for beginners or
capabilities, suitable for experienced users and users unfamiliar with UML tools.
large projects.

Offers powerful collaboration, project Visual Paradigm is more expensive, this

management, and modeling tools, justifying software is especially for larger teams, making
the higher cost for large-scale operations. it less accessible to individual developers or
small teams.

In the comparison between StarUML and Visual Paradigm, that Visual Paradigm represents the
more favorable option for larger teams or organizations where comprehensive collaboration need,
sophisticated modeling features, and interoperability with additional tools. StarUML is a good
option for solo developers or minor projects that necessitate fundamental UML functionalities;
conversely, Visual Paradigm is distinguished by its extensive array of features, encompassing
cloud storage, real-time collaboration, and the capability to accommodate a wider variety of
diagrams and modeling methodologies. Despite potentially incurring higher costs and presenting
a more challenging learning process, the extensive features and scalability of Visual Paradigm
render it particularly suitable for intricate, large-scale software initiatives where utilizing
professional-grade tools is critical for achieving success.
 Lab 3 : To understand Use Case View

Exercise:
Q1. Draw a Use-Case diagram for an Online Shopping System
Hint: Web Customer actor uses some web site to make purchases online. Use cases are View
Items, Make Purchase and Client Register. View Items use case could be used by customer if he
only wants to find and see some products. This use case could also be used as a part of Make
Purchase use case. Client Register use case allows customer to register on the web site through
<<Service>>Authentication actor. Note, that Checkout use case is included use case not
available by itself - checkout is part of making purchase. View Items use case is extended by
several optional use cases - customer may search for items and browse catalog .Checkout use case
includes Customer Authentication. It could be done through user login page (sign in), Remember
me page. Actor: Service Authentication .
Checkout use case also includes Payment use case which could be done either by using credit
card and external credit payment service or with PayPal.(Actors: Credit Payment Service, PayPal

Assumptions:
• If a Web Customer is unregistered, they should first register themselves.
• After login, Users have multiple ways to view items such as browsing the catalog,
searching items, or recommending items under a product.
• Websites only accept PayPal and credit cards as a source of payment.
Use Case Diagram