Software Design and Architecture

Engr Saiqa Anjum

Lecturer SE
Faculty of NUML
Software Design and Architecture

Unified Modeling Language

Lecture 2
Software Design and Architecture
UNIFIED MODELING LANGUAGE (UML) OUTLINE

 Use Cases
 Class Diagram
 Component Diagrams
 Interaction Sequence Diagrams
 Activity Diagrams
 State Machine Diagrams
 Object Constraint Language
 Deployment Diagrams
 Design Patterns or GRASP Patterns
 Modeling
• Models are abstractions that portray the essentials of a complex
problem or structure by filtering out nonessential details.

• Describing a system at a high level of abstraction

• A model of the system
• Used for requirements and specifications

• Models help us organize, visualize, understand, and create

complex things.

• Is it necessary to model software systems?

 What is Visual Modeling?
• 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
(customer, domain expert, analyst, designers, etc.)
– Modeling enterprises
– Preparing documentation
– Designing programs and databases
Object Oriented Modeling
What is UML?
• UML stands for “Unified Modeling Language”
• UML is a visual language that can be used in developing software
systems.
• UML is a specification language and has a set of rules that
determine how it can be used.
• Most of the elements of UML are graphical and they consist of
lines, rectangles, ovals and other shapes.
Why UML for Modeling
• Use graphical notation to communicate more
clearly than natural language (imprecise) and
code(too detailed).
• Help acquire an overall view of a system.
• UML is not dependent on any one language or
technology.
• UML moves us from fragmentation to
standardization.
The Unified Modeling Language
• Several different notations for describing object-oriented
designs were proposed in the 1980s and 1990s.
• The Unified Modelling Language is an integration of these
notations.
• It describes notations for a number of different models that
may be produced during OO analysis and design.
• It is now a de facto standard for OO modelling.
UML Diagrams
Where can UML be used?
1. Business Model using Activity Diagram
2. Requirements Capture using Use Case Diagram
3. Planning by Use Case Prioritization
4. Requirements Analysis using Use Case Details and Class
Diagram
5. Initial Design using Sequence Diagrams and second version
of Class Diagram
6. Requirements Analysis using State Diagram
7. Architecture Design using Packages (with Visibility) and
Subsystems
8. Design using next level of details for Class Diagram
Where can UML be used?
(contd)
9. System Architecture using Deployment Diagram
10. Design using Design Patterns
11. Detailed design using Collaboration Diagram
12. Consolidate all information into Class Diagram
13. Detailed design using Component Diagram
14. Refine all models through iterations
15. Implement the models by translating into code
16. Deploy software within operational environment
 UML Modeling
Logical View Implementation View
id Business Entity (Client)

cd Users
«Include»
Business Entities::Employee dsXxx.i
+ Address: CHARACTER incl udes - DEFINE DATASET <dataset-def>:
+ City: CHARACT ER
+ email: CHARACT ER
i ncludes
- EmployeeLanguage: CHARACTER
Architecture Entities::User + employmentEndDate: DAT ET IME-T Z
+ employmentStartDate: DAT E
- UserEmail: CHARACT ER + FirstName: CHARACTER
Architecture Entities:: «incl ude» «Program»
- UserLogin: CHARACTER
1 1 + LastName: CHARACTER
Language «includes» ClientXxx.p
«i ncludes» «Incl ude»
- UserPassword: CHARACTER + MobilePhoneNumber: CHARACTER ttContext.i
etXxx.i
+ Notes: CHARACT ER
0..* 1 - Description: CHARACTER
+ PhoneNumber: CHARACTER

Use Case View

- Language: CHARACTER includes
0..* + Position: CHARACT ER
+ PostCode: CHARACTER

+ createEmployee() : void
+ deleteEmployee() : void «Include»
1 + findEmployee() : void proSIproxyStart.i
+ isAvailable() : LOGICAL
+ updateEmployee() : void ud Manage Employees - NEW GLOBAL SHARED VARIABLE ghProxySIproc:
Architecture Entities::UserGroups
+ validateEmployee() : void
- UserGroupDescription: CHARACTER AutoEdge System «realize PERSISTENT»
- UserGroupName: CHARACTER

Brow se Employees «Program»

proSIproxy.p

- NEW GLOBAL SHARED VARIABLE ghttProxySIproc: HANDLE

«use»
+ fetchWhere(CHARACTER, HANDLE, DAT ASET-HANDLE*) : voi d
Delete Employee
+ saveChanges(CHARACT ER, HANDLE, CHARACTER*) : void
«use»

Update Employee

Dynamic View Manager

(from Actors)
«include»
Deployment View
sd Login

Create Employee Create User

«extend»

Client Server Gateway Security Session Context

dd Integration
Request("Security", "Login", ...)

HQ System
isValidUser(Login, password)

ValidUser

Sonic
[if Valid User]: createSession
Sonic Sonic Sonic Sonic
sessionID

Dealer Dealer Dealer Dealer

System 1 System 2 System 3 System n

[if valid user]: sessionID

(from Architecture Components) (from Architecture Components) (from Archi tecture Components)
(from Architecture Components)
 4+1 architectural view model
• 4+1 is a view model  used for "describing the
architecture of software-intensive systems, based on the
use of multiple, concurrent views".
• The views are used to describe the system from the
viewpoint of different stakeholders, such as end-users,
developers, system engineers, and project managers.
• The four views of the model are logical, development,
process and physical view. In addition, selected use
case or scenarios are used to illustrate the architecture
serving as the 'plus one' view.
Use-case View
• Gathering requirements
• Functional & non-functional requirements
• Document functional requirements
• UML Use Case Diagram
• Use Case Description Documents
• Identify actor(s) and association to use case
• Create different levels of use cases (re-use!)
Logical View
• The logical view is concerned with the functionality that the
system provides to end-users. 
• Class diagram
• State machine diagram
Process view
• The process view deals with the dynamic aspects of the
system, explains the system processes and how they
communicate, and focuses on the run time behavior of the
system.
• This view is also known as the dynamic view. 
• UML diagrams to represent process view include the
• Sequence diagram
• Communication diagram
• Activity diagram
 
Development view
• The development view illustrates a system from a
programmer's perspective and is concerned with software
management.
• This view is also known as the implementation view. 
• UML diagrams to represent process view include the
• Component diagram
• Package diagram
Physical view
• The physical view depicts the system from a system engineer's
point of view.
• It is concerned with the topology of software components on
the physical layer as well as the physical connections between
these components.
• This view is also known as the deployment view.
• UML diagram to represent process view include the
• Deployment diagram
HAVE A NICE DAY

Q/A