Mailing System

Sample Software Architecture Document (version 0.7)

Software Architecture Document

Mailing System

Mailing System Page 1 of 19

Mailing System
Sample Software Architecture Document (version 0.7)

SAD Revision History

Date Version Description Author
4th July 2020 0.1 Significant Use-Cases: the key requirements Ahmed Ehtesam 11752,
Shanila Afaq 11769,
Zahra Abbas 11788,
Azka Khalid 11794

Mailing System Page 2 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

Table of Contents
1. INTRODUCTION 4
1.1 PURPOSE 4
1.2 SCOPE 5
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS 5
1.4 REFERENCES 5
1.5 OVERVIEW 5
2. ARCHITECTURAL REPRESENTATION 6
3. ARCHITECTURAL GOALS AND CONSTRAINTS 7
3.1 TECHNICAL PLATFORM 7
3.2 TRANSACTION 7
3.3 SECURITY 7
3.4 PERSISTENCE 7
3.5 RELIABILITY/AVAILABILITY (FAILOVER) 7
3.6 PERFORMANCE 8
3.7 INTERNATIONALIZATION (I18N) 8
4. USE-CASE VIEW 8
4.1 OVERVIEW 8
4.2 USE CASE DIAGRAM OF MAILING SYSTEM: 8
4.2.1 Use case Diagram: 9
5. LOGICAL VIEW 10
5.1 OVERVIEW 10
5.2 SEQUENCE DIAGRAM 10
5.2.1 Sequence Diagram of Mailing System: 11
5.3 CLASS DIAGRAM: 12
5.3.1 Class diagram of Mailing System: 12
6. PROCESS VIEW 13
6.1 OVERVIEW 13
6.2 ACTIVITY DIAGRAM: 13
6.2.1 Activity Diagram of Mailing System: 13
6.3 STATE MACHINE: 14
6.3.1 State Diagram of Mailing System: 15
7. DEPLOYMENT VIEW 16
7.1 OVERVIEW 16
7.2 DEPLOYMENT DIAGRAM: 16
7.2.1 Deployment diagram of Mailing System: 17
8. IMPLEMENTATION VIEW 17
8.1 OVERVIEW 17
8.2 COMPONENT DIAGRAM: 17
8.2.1 Component Diagram of Mailing System: 18
9. SIZE AND PERFORMANCE 18
10. QUALITY 18

Mailing System Page 3 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

1. Introduction
This document defines the steps required for “Developing a J2EE Architecture with Rational
Software Architect using the Rational Unified Process®” [RUPRSA]. It demonstrates what can
be the part of a Software Architecture Document (SAD) produced during the Rational Unified
Process Elaboration phase.
A RUP Software Architect will typically perform number of major steps to define a global
architecture, and every time an activity is finished, a definite section of the SAD is developed
accordingly.

Architectural activities Software Architecture Document

Step 1 – Identify the use cases of the system and draw Section
a use case view accordingly
Step 2 – Identify the activities performed by the system Section
and develop an Activity Model (Process View)
accordingly
Step 3 – Derive the Process View of the System using Section
State Transition Diagram
Step 4 – Demonstrate the sequence of interaction Section
between different components of system using
Sequence Diagram (Process View)
Step 5 – Design the interaction between components of Section
the system using Component Diagram (Development
View)
Step 6 - Design the classes of the system using Section
Component Diagram (Development View)
Step 7 – Draw the Deployment Model of the System Section
(Development View)

1.1 Purpose
The Software Architecture Document (SAD) provides a comprehensive architectural overview of the Mailing
System. It defines various architectural views to portray different features of the system. It is proposed to preserve
and send the significant architectural decisions which have been made on the system.

In order to portray the software as accurately as possible, the structure of this document is based on the “4+1” model
view of architecture [KRU41].
The “4+1” View Model allows number of stakeholders to identify what their requirements in the software
architecture.

Mailing System Page 4 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

1.2 Scope
The scope of this document is to portray the architectural design of Mailing System as precisely as possible.

1.3 Definitions, Acronyms and Abbreviations

RUP: Rational Unified Process

UML: Unified Modeling Language
SAD: Software Architecture Document

1.4 References

[KRU41]: The “4+1” view model of software architecture, Philippe Kruchten, November 1995,
http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf

1.5 Overview

In order to fully document all the aspects of the architecture, the Software Architecture Document contains the
following subsections.
Section 2: describes the use of each view
Section 3: describes the activities performed by the system
Section 4: describes various states of the system while operation

Mailing System Page 5 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

Section 5: describes the order of interactions of the operations and actors in sequence
Section :6 describes the interaction between components of the system
Section 7: describes the classes of the system
Section 8: describes the Deployment Model of the System
2. Architectural Representation

This document details the architecture using the views defined in the “4+1” model [KRU41], but using the RUP
naming convention. The views used to document the Mailing System are:

Logical view
Audience: Designers.
Area: Functional Requirements: describes the design's object model. Also describes the most important
use-case realizations.
Related Artifacts: Design model

Process view
Audience: Integrators.
Area: Non-functional requirements: describes the design's concurrency and synchronization aspects.
Related Artifacts: (no specific artifact).

Implementation view
Audience: Programmers.
Area: Software components: describes the layers and subsystems of the application.
Related Artifacts: Implementation model, components

Deployment view
Audience: Deployment managers.
Area: Topology: describes the mapping of the software onto the hardware and shows the system's
distributed aspects.
Related Artifacts: Deployment model.

Use Case view

Audience: all the stakeholders of the system, including the end-users.
Area: describes the set of scenarios and/or use cases that represent some significant, central functionality of
the system.
Related Artifacts: Use-Case Model, Use-Case documents

Mailing System Page 6 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

3. Architectural Goals and Constraints

This section describes the software requirements and objectives that have some significant impact on the
architecture

3.1 Technical Platform

The mailing system will be deployed onto a J2EE application server (WebSphere Application Server version 6, as it
is already the application server use for internal applications).

3.2 Transaction

The Mailing system is transactional, leveraging the technical platform capabilities. Transaction management model
of the J2EE platform will be reused intensively.

3.3 Security

The system must be secured, so that a customer can send mails.

The application must implement basic security behaviors:
• Authentication: Login using at least a user name and a password
• Authorization: according to their profile, online user must be granted or not to perform some
specific actions ( for example rights of admin)
For internet access, the following requirements are mandatory
• Confidentiality: sensitive data must be encrypted (credit card payments)
• Data integrity : Data sent across the network cannot be modified by a tier
• Auditing: Every sensitive action can be logged
• Non-repudiation : gives evidence a specific action occurred
J2EE security model will be reused

3.4 Persistence

Data persistence will be addressed using a relational database.

3.5 Reliability/Availability (failover)

The availability of the system is a key requirement by nature, as it is a selling system. The candidate architecture
must ensure failover capabilities. Reliability/Availability will be addressed through the J2EE platform
Targeted availability is 16/7: 16 hours a day, 7 days a week

Mailing System Page 7 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

The time left (8 hours) is reserved for any maintenance activities

3.6 Performance

The mail sending process (sending mail) must be done under 10 seconds. Many users rely on the system so it must
be operational every time.

3.7 Internationalization (i18n)

The Mailing system will be able to deal with several languages (at least French and English) So, the presentation
layer must be able to support i18n. Other layers must be generic enough to work with any internationalization
context

4. Use-Case View
4.1 Overview
A use case diagram at its simplest is a representation of a user's interaction with the system that shows the
relationship between the user and the different use cases in which the user is involved.
4.2 Use case Diagram of Mailing System:
Fully dressed Use Case
Writing Mail:
1.1. Use case name: Writing Mail
1.2. Brief description: Helps user to write mail.
1.3. Actors: users.
1.4. Pre-condition: System is connected to internet. Good internet connection is established.
1.5. Main scenarios:
1. User enter email and password.
2. User will write subject if needed.
3. User will attach file if needed.
4. User will send mail if required.
5. Sent message will be displayed on screen.
1.6. Alternative scenarios:
Step 1: if system does not recognize the email details, it will ask user to enter again.
Step 1: if it still doesn’t recognize it, system will send verification code.
Step 2: if not necessary, subject is not added.
Step 3: if not necessary, file is not added.
Step 4: user schedule the sent mail for later.
Step 4: internet connection is lost while sending mail and message will be saved as draft.
Step 5: “Try again” message will be displayed

1.7. Post condition: email sent successfully.

1.8. Objects:
1. Email Application: It is the application where user will add data.
2. Account management system: it is the system from which data will be verified and all
desired functions will be performed.

Mailing System Page 8 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

4.2.1 Use case Diagram:

Mailing System Page 9 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

5. Logical View
5.1 Overview
The logical view is concerned with the functionality that the system provides to end-users. UML diagrams are used
to represent the logical view, and include class diagrams, and sequence diagrams.

5.2 Sequence diagram

A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved
in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of
the scenario. Sequence diagram of use case writing mail.
Fully dressed Use Case is:
Compose Mail:
1.9. Use case name: Writing Mail
1.10. Brief description: Helps user to write mail.
1.11. Actors: users.
1.12. Pre-condition: System is connected to internet. Good internet connection is established.
1.13. Main scenarios:
1. User enter email and password.
2. User will write subject if needed.
3. User will attach file if needed.
4. User will send mail if required.
5. Sent message will be displayed on screen.
1.14. Alternative scenarios:
Step 1: if system does not recognize the email details, it will ask user to enter again.
Step 1: if it still doesn’t recognize it, system will send verification code.
Step 2: if not necessary, subject is not added.
Step 3: if not necessary, file is not added.
Step 4: user schedule the sent mail for later.
Step 4: internet connection is lost while sending mail and message will be saved as draft.
Step 5: “Try again” message will be displayed

1.15. Post condition: email sent successfully.

1.16. Objects:
1. Email Application: It is the application where user will add data.
2. Account management system: it is the system from which data will be verified and all
desired functions will be performed.

Mailing System Page 10 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

5.2.1 Sequence Diagram of Mailing System:

Compose mail:

Mailing System Page 11 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

5.3 Class diagram:

The UML Class diagram is a graphical notation used to construct and visualize object oriented systems. A class
diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure
of a system.
5.3.1 Class diagram of Mailing System:

Mailing System Page 12 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

6. Process View
6.1 Overview
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. UML diagrams to represent process view include
the state diagram, activity diagram.

6.2 Activity Diagram:

Activity Diagram is basically a flowchart to represent the flow from one activity to another activity. The activity can
be described as an operation of the system. The basic purpose of activity diagrams is to capture the dynamic
behavior of the system. It is also called object-oriented flowchart.
6.2.1 Activity Diagram of Mailing System:

Mailing System Page 13 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

6.2.1.1 Activity Diagram for Login:

6.3 State Machine:

A state diagram is a type of diagram used in computer science and related fields to describe the behavior of systems.
State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed
the case, while at other times this is a reasonable abstraction.

Mailing System Page 14 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

6.3.1 State Diagram of Mailing System:

Mailing System Page 15 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

6.3.1.1 State diagram for Login:

7. Deployment View
7.1 Overview
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 diagrams used to represent the physical view include the deployment
diagram.
7.2 Deployment diagram:

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To
describe a web site, for example, a deployment diagram would show what hardware components exist, what
software components run on each node, and how the different pieces are connected.

Mailing System Page 16 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

7.2.1 Deployment diagram of Mailing System:

8. Implementation View
8.1 Overview

The Implementation view depicts the physical composition of the implementation in terms of
Implementation Subsystems, and Implementation Elements (directories and files, including source code,
data, and executable files). It uses the UML Component diagram to describe system components.
8.2 Component Diagram:
A component diagram, describes the organization and wiring of the physical components in a system. Component
diagrams are often drawn to help model implementation details and double-check that every aspect of the system's
required function is covered by planned development.

Mailing System Page 17 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

8.2.1 Component Diagram of Mailing System:

9. Size and Performance

Volumes:
• Estimated online orders : 100 a day, with peaks in the evening
• Yummy Inc registered individual customer : about 150
• Yummy Inc corporate customers : about 100

Performance:
• Time to process and online payment (credit card validation + confirmation) : less that 10 seconds required

10. Quality

Mailing System Page 18 of 19

 Mailing System
Sample Software Architecture Document (version 0.7)

As far as the online catering application is concerned, the following quality goals have been identified:

Scalability:
• Description : System’s reaction when user demands increase
• Solution : J2EE application servers support several workload management techniques
Reliability, Availability:
• Description : Transparent failover mechanism, mean-time-between-failure
• Solution : : J2EE application server supports load balancing through clusters
Portability:
• Description : Ability to be reused in another environment
• Solution : The system me be fully J2EE compliant and thus can be deploy onto any J2EE
application server
Security:
• Description : Authentication and authorization mechanisms
• Solution : J2EE native security mechanisms will be reused

Mailing System Page 19 of 19