[go: up one dir, main page]

0% found this document useful (0 votes)
37 views69 pages

Unit 3 Sduml

The document outlines the Logical View Design Stage in software engineering, focusing on static structure diagrams such as class diagrams, package diagrams, and their relationships including association, generalization, aggregation, and dependency. It explains the purpose and components of class diagrams, detailing how to model classes, associations, attributes, and multiplicity. Additionally, it covers the benefits of class diagrams and the use of package diagrams to organize complex systems.

Uploaded by

1032221876
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views69 pages

Unit 3 Sduml

The document outlines the Logical View Design Stage in software engineering, focusing on static structure diagrams such as class diagrams, package diagrams, and their relationships including association, generalization, aggregation, and dependency. It explains the purpose and components of class diagrams, detailing how to model classes, associations, attributes, and multiplicity. Additionally, it covers the benefits of class diagrams and the use of package diagrams to organize complex systems.

Uploaded by

1032221876
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 69

Unit 3

The Logical View Design Stage


• The Logical View Design Stage: The Static Structure Diagrams. The
Class Diagram Model. Attributes descriptions. Operations
descriptions. Connections descriptions in the Static Model.
Association, Generalization, Aggregation, Dependency, Interfacing,
Multiplicity. Package Diagram Model - Description of the model.
White box, black box. Connections between packagers. Interfaces.
Create Package Diagram. Drill Down.
UML
• UML diagrams
– Static modeling
(Structure Diagrams)
– Dynamic modeling
(Behavior Diagrams)

Software Engineering and Project Management- UNIT II 3


3/4/2025
Static Modeling( static Design)
● Class diagrams
● Object diagrams
● Composite structure diagrams
● Package diagrams
● Component Diagram - Interfaces and Components
● Deployment Diagram

3/4/2025 4
Class Diagram
• A class diagram depicts classes and their interrelationships

• Used for describing structure and behavior in the use cases

• Provide a conceptual model of the system in terms of entities and


their relationships

• Used for requirement capture, end-user interaction

• Detailed class diagrams are useful for software developers

3/4/2025 5
Class Diagram
• Class diagrams are one of the most fundamental diagram types in UML.
• They are used to capture the static relationships of your software; in other
words, how things are put together
• A class represents a group of things that have common state and behavior.
• Used for describing structure and behavior in the use cases
• Provide a conceptual model of the system in terms of entities and their
relationships
• Detailed class diagrams are used for developers

3/4/2025 6
Class Diagram
S.No Name Description Notation
1 Classes and interface They are used to show the different objects in
a system, their attributes, their operations and
the relationships among them.
2 Object An object is an instance or occurrence of a
class Object: Class

3 Aggregation An aggregation describes a group of objects


and how you interact with them.

4 Composition Composition represents whole-part


relationships and is a form of aggregation.

5 Dependency Dependency relationship is a relationship in


which one element, the client, uses or
depends on another element, the supplier.

3/4/2025 7
Class Diagram
S.No Name Description Notation
3 Generalization Generalization is a relationship in which one model
element (the child) is based on another model
element (the parent).
4 Association Association is a relationship between two classifiers,
such as classes or use cases, that describes the
reasons for the relationship and the rules that govern
the relationship.
5 Multiplicity

3/4/2025 8
Drawing a Class Diagram ?
• Identify and model classes—Which classes do we need?
• Identify and model associations—How are the classes connected?
• Define attributes—What do we want to know about the objects?

3/4/2025 Software Engineering and Project Management- UNIT II 9


A Single Class

3/4/2025 10
Depicting Classes
• When drawing a class, you needn’t show attributes and operation in every diagram.

Person
Person
Person

name : String
birthdate : Date
ssn : Id
Person

Person
name eat()
address sleep()
birthdate work()
eat
play play()

3/4/2025 11
Class Diagram : Hotel Management System

3/4/2025 Software Engineering and Project Management- UNIT II 12


Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.
There are four kinds of relationships in Class Diagram:

• Association
Window <<Interface>
• Generalizations
+ open() : void >
AbstractWindow
• Dependency + open() : void
+ close() : void
• Realization + handleEvent(e: Event) : void + close() : void

Event

ConsoleWindow DialogBox Control


3/4/2025 13
Association Relationships
• If two classes in a model need to communicate with each other, there
must be link between them.

• An association denotes that link.

Student Instructor

3/4/2025 14
Association Relationships (Cont’d)
• We can indicate the multiplicity of an association by adding multiplicity adornments to the line
denoting the association.
• Instance of one class interacting with the instance of another class

• The example
Student indicates that a Student has one or more Instructors:
1..*
Instructor

The example indicates that every Instructor has one or more Students:

Student Instructor
1..*
Multiplicity
⮲ Optional (0 or 1) 0..1 Symbol Meaning
⮲ Exactly one 1= 1..1 1 One and only one
⮲ Zero or more 0..*= * 0..1 Zero or one
⮲ One or more 1..* M..N From M to N (natural language)
⮲ A range of values 2..6 * From zero to any positive integer
3/4/2025 0..* From zero to any positive integer 15
1..* From one to any positive integer
Association Relationships (Cont’d)
• We can also indicate the behavior of an object in an association (i.e., the role of an object) using
rolenames.
learns from teaches
Student Instructor
1..* 1..*

We can also name the association.

membership
Student Team
1..* 1..*

3/4/2025 16
Association Relationships (Cont’d)
• We can specify dual associations.

member of

1..* 1..*
Student Team

1 president of 1..*

3/4/2025 17
Association Relationships (Cont’d)
• Navigability of the association.

• Here, a Router object requests services from a DNS object by sending messages to
(invoking the operations of) the server.
• The direction of the association indicates that the server has no knowledge of the
Router.

Router DomainNameServer

3/4/2025 18
Association Relationships (Cont’d)
• Associations can also be objects themselves, called as association classes.

Registration

modelNumber
serialNumber
warrentyCode

Product Warranty

3/4/2025 19
Association Relationships (Cont’d)
• A class can have a self association.

next

LinkedListNode
previous

3/4/2025 20
Association examples

3/4/2025 21
21
Association: Model to Implementation

* 4
Student Course
has enrolls

Class Student {
Course enrolls[4];
}

Class Course {
Student have[];
}
3/4/2025 22
Association - Aggregation

• A special form of association that models a whole-part relationship between


an aggregate (the whole) and its parts.

• 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.

3/4/2025 23
Aggregation and Composition
Aggregation
⮲ This is the “Has-a” or “Whole/part” relationship
aggregation

Club Member
* *

:Car :Train
0..1 :Person 0..1
0..*
driver 1 passengers
aggregation
3/4/2025 24
24
Aggregation and Composition

● Composition
⮲Strong form of aggregation that implies ownership:
⮚if the whole is removed from the model, so is the part.
⮚the whole is responsible for the disposition of its parts

3/4/2025 25
25
Association - Composition

⦿A form of aggregation with strong ownership and coincident lifetimes


⚫ The parts cannot survive the whole/aggregate
Composition implies a relationship where the child cannot exist independent of
the parent.

Whole Part

Schedule
Student

Composition
3/4/2025 26
Example

3/4/2025 27
Aggregation and Composition

1 :Engine

composition
:Locomotive 1..*
1 0..1
:Car :Train
0..1 :Person 0..1
0..*
driver 1 passengers
aggregation

3/4/2025 28
28
Example
has 0..1

School Department

1 1..n 1..n
1..n 1..n

assignedTo
member
-chairperson
n 1..n 1..n 0..1

Student attends Course teaches Instructor


n n n 1..n

3/4/2025 29
Generalization Relationships

Person

• A generalization connects a subclass


to its superclass.
It denotes an
• Inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
Student
of the more general superclass.

3/4/2025 30
Generalization Relationships (Cont’d)
• UML permits a class to inherit from multiple superclasses, although some
programming languages (e.g., Java) do not permit multiple inheritance.

Student Employee

TeachingAssistant

3/4/2025 31
Generalization/Specialization
• Generalization hierarchies may be created by generalizing from specific things or by
• specializing from general things.

More general element

“is a kind of”

More specific element

3/4/2025 32
Inheritance
⮲ Class inheritance is implicit in a generalization relationship between classes.
⮲ Subclasses inherit attributes, associations, & operations from the superclass

3/4/2025 33
Example
• Draw a UML Class Diagram representing the following elements
from the problem domain for a hockey league.
• A hockey league is made up of at least four hockey teams.
• Each hockey team is composed of six to twelve players, and one
player captains the team.
• A team has a name and a record. Players have a number and a
position. Hockey teams play games against each other. Each game
has a score and a location. Teams are sometimes lead by a coach.
• A coach has a level of accreditation and a number of years of
experience, and can coach multiple teams. Coaches and players are
people, and people have names and addresses.

3/4/2025 34
3/4/2025 35
Example : Order Details

3/4/2025 36
Benefits of class diagrams
• To understand the general overview of plan of an application.
• Illustrate data models for information systems, no matter how
simple or complex.
• Visually express any specific needs of a system
• Create detailed charts that highlight any specific code needed to be
programmed and implemented to the described structure.
• Provide an implementation-independent description of types used
in a system that are later passed between its components.

3/4/2025 37
Object Diagram
• Derived from class diagram
• Shows a set of objects & their relationship
• Represents a static view of the system
• An object diagram is a diagram that shows a set of objects and their
relationships at a point in time.
• Object diagrams help you capture the logical view of your model

3/4/2025 38
Object Diagrams
• An object is shown with a rectangle and the title is underlined
• Format is
– Instance name : Class name
– Attributes and Values

instantiated entry object is an


object instance of the
BlogEntry class
3/4/2025 39
Links
• To show how objects work together, links shows that
two objects can communicate with each other
• There must be corresponding association between the
classes in the class diagram
• Can add label that indicates the purpose of the link,

3/4/2025 40
Links and Constraints
• Links must keep to the rules (constraints) given in class
diagram.

Both diagrams are valid.


3/4/2025 41
3/4/2025 42
3/4/2025 43
Eg.1
• From the given class diagram draw an object diagram
for John’s accounts

3/4/2025 44
3/4/2025 45
Eg. 2
• Draw Object diagram for the Order management system .
It has the following objects
» Customer
» Order
» SpecialOrder
» NormalOrder
• Customer object (C) is associated with three order objects
(O1, O2 and O3). These order objects are associated with
special order and normal order objects (S1, S2 and N1).
The customer is having the following three orders with
different numbers (12, 32 and 40) for the particular time
considered.

3/4/2025 46
3/4/2025 47
3/4/2025 48
3/4/2025 49
Class to Object Diagram Example - Order System

3/4/2025 50
Example contd..

3/4/2025 51
Example contd..

3/4/2025 52
Example (contd..)

3/4/2025 53
Example contd..

3/4/2025 54
Package diagrams
• Package diagram is used to simplify complex class diagrams, you can
group classes into packages. A package is a collection of logically
related UML elements.
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other could possibly
force changes in the first.

3/4/2025 55
Package diagrams
• Purpose of Package Diagrams
• Package diagrams are used to structure high level system elements.
Packages are used for organizing large system which contains diagrams,
documents and other key deliverables.
• Package Diagram can be used to simplify complex class diagrams, it can
group classes into packages.
• Packages are depicted as file folders and can be used on any of the
UML diagrams.

3/4/2025 56
• Packages can be represented by the notations with some examples
shown below:

3/4/2025 57
Package Diagram
• It shows the decomposition of the model itself into organization units &
their dependencies

3/4/2025 Software Engineering and Project Management- UNIT II 58


Dependency Relationship

• Two stereotypes are used in dependency: <<import>> & <<access>>.


• <<import>> - one package imports the functionality of other package
• <<access>> - one package requires help from functions of other
package.

3/4/2025 59
Package Diagram Example - Layered Application

3/4/2025 60
Package Diagram Example - Order
Subsystem

3/4/2025 61
Package Diagram Example - Order
Subsystem
• Order Processing System - The Problem Description
We are going to design package diagram for "Track Order" scenario for an online shopping store. Track
Order module is responsible for providing tracking information for the products ordered by customers.
Customer types in the tracking serial number, Track Order modules refers the system and updates the
current shipping status to the customer.

• Based on the project Description we should first identify


the packages in the system and then related them together
according to the relationship:
Identify the packages of the system
• There is a track order module, it has to talk with other
module to know about the order details, let us call it "Order
Details".
• Next after fetching Order Details it has to know about
shipping details, let us call that as "Shipping".

3/4/2025 62
Package Diagram Example - Order
Subsystem

Identify the dependencies in the System


• Track order should get order details from
"Order Details" and "Order Details" has to
know the tracking info given by the customer.
Two modules are accessing each other which
suffices <<access>> dual dependency

• To know shipping information,


"Shipping" can import "Track Order" to
make the navigation easier.

3/4/2025 63
Package Diagram Example - Order
Subsystem
• Finally, Track Order dependency to UI Framework is also mapped which completes our Package Diagram for Order
Processing subsystem.

3/4/2025 64
Package Example
They provide a clear view of the
hierarchical structure of the various
UML elements within a given system.
These diagrams can simplify
complex class diagrams into well-
ordered visuals.
They offer valuable high-level
visibility into large-scale projects and
systems.
Package diagrams can be used to
visually clarify a wide variety of
projects and systems.
These visuals can be easily updated
assystems and projects evolve.
Basic com
More Package Examples

3/4/2025 66
A Black Box Package Diagram in UML represents a package as a "black box," where the internal structure or c
Here's a step-by-step guide to creating a Black Box Package Diagram in UML:
Components:

: A package is represented by a rectangle with a small tab at the top. The contents of the package are
1.Package (Black Box)

2.Interface: Represents the visible set of operations or services that the package offers to the outside world. It is
3.Dependencies: These are directed arrows that show the relationship between different packages. A dependen
4.Package Relationships: Relationships such as associations, dependencies, and generalizations between diff
Black Box Package Diagram:
•The package itself is represented as a box with a tab.

•Only the interfaces that the package provides or requires are shown.
•No details inside the box about the package's internal classes or structure.
Example:

PaymentProcessing and OrderManagement. PaymentProcessing offers an interface called


Let’s assume you have two packages,

1.PaymentProcessing (Black Box):


•Provides the interface IPaymentService.
2.OrderManagement:
•Depends on IPaymentService to carry out payment processing.
In the Black Box diagram:
•PaymentProcessing will be shown as a package with a tab and the interface IPaymentService on the outside.
•OrderManagement will have a dependency arrow pointing towards the IPaymentService interface from the PaymentProcessing
• In a White Box Package Diagram in UML, the internal structure of the
package is visible. Unlike a black box diagram, where the package is
abstracted and only the interfaces are shown, the white box diagram
focuses on the internal components, such as the classes or other elements
within a package.
• Key Features of a White Box Package Diagram:
• Package: Represented as a rectangle with a small tab at the top, similar to
the black box. However, this time, the internal contents (such as classes,
interfaces, and other sub-packages) are visible inside the package.
• Classes and Interfaces: These are shown within the package to illustrate
the internal structure.
1.Dependencies: Relationships between classes or packages are shown as arrows, where the direction indicate
2.Visibility: All the internal elements of the package (like classes, interfaces, and relationships) are visible in a w
Example:

Let’s take the same example as before, but this time we’ll include the internal structure of the PaymentProcessing package:
1.PaymentProcessing (White Box):
•Internal classes: PaymentProcessor, PaymentValidator, PaymentGateway.
•Interface: IPaymentService (exposed to other packages).
2.OrderManagement:
•Depends on the interface IPaymentService provided by the PaymentProcessing package to process payments.
In this white box diagram:
•The PaymentProcessing package will show the internal classes (PaymentProcessor, PaymentValidator, PaymentGateway), and the IPaymentService
•The OrderManagement package will have a dependency on the IPaymentService interface, showing the relationship between these packages.

You might also like