Saturday, October 28, 2017

Application Layer diagram and Documentation






Technical Design Documents :

1. General
1.1. Project general description
1.2. Solution general description
1.3. Guidelines from the functional design
1.4. Development guidelines.
1.4.1. Best Practices.
1.4.2. Standards.
2. Architecture
2.1. Physical architecture
         2.1.1. Diagram
2.2. Logical architecture
         2.2.1. Application server architecture
         2.2.2. Services server architecture
         2.2.3. Web architecture
3. Database
3.1. General description
3.2. Tables list
3.3. Database diagram
3.4. Views
3.5. Stored procedures
3.6. Triggers
3.7. Jobs
4. Infrastructure
4.1. General
4.2. Logging handling
4.3. Auditing and tracing handling
4.4. Exception handling
          4.4.1. General
          4.4.2. Custom Exceptions
4.5. Monitoring
4.6. Data Access
          4.6.1. General
          4.6.2. Typed Datasets
4.7. Common
          4.7.1. Common Enums
          4.7.2. Common Objects
          4.7.3. Common functions
4.8. Multi-Language Support
4.9. Printing Mechanism
4.10. Cache management
        4.10.1.Web site cache
        4.10.2.Application cache
        4.10.3.Database cache
4.11. Configuration
        4.11.1.Global configuration
        4.11.2.Web site configuration
4.12. Unit Testing
        4.12.1.Method
        4.12.2.Tested Components
4.13. Transactions
4.14. Validations
         4.14.1.Application validations
         4.14.2.Web site validations
5. Business entities
5.1. General
5.2. Entities diagram
5.3. Entities description
6. Security
6.1. General
          6.1.1. Web site security
          6.1.2. Server security
6.2. Authentication
6.3. Authorization
6.4. Cross-site scripting (XSS)
6.5. SQL injection
6.6. Script injection
6.7. User input validation
6.8. Cryptography
7. Performance and Load Testing
7.1. General
7.2. Performance
7.3. Load Testing
8. Interfaces
8.1. Interfaces diagram
9. Data conversions
9.1. General
9.2. Mappings
10. External Services
10.1. General
10.2. Windows services
10.3. Queue Management
11. Presentation
11.1. General Structure
11.2. State management
              11.2.1.Cookies
              11.2.2.Application State
              11.2.3.Session State
11.3. Master pages and themes
11.4. Pages
11.5. User controls
11.6. Custom controls
11.7. Resources
11.8. Common functions
11.9. Error Pages
11.10.UI graphic guidelines
11.11.Ajax support
12. Application Server
12.1. General
12.3. Server gateway
             12.3.1.General
12.4. Business Logic Layer
             12.4.1.General
             12.4.2.<BL 1>
12.5. Data Access Layer
             12.5.1.General
             12.5.2.<DAL 1>
13. 3rd party dependences
13.1. General
13.2. Dependences diagram
         13.2.1.<Dependency 1>

======================================================================


1.    Introduction

This document provides a high-level overview and explains the whole architecture of ABC Application. It is explaining how the components needs to be implemented according to the architecture.
This also describes of the goals of the architecture with explaining the use cases support by the system and architectural styles and components. This document then allows for the development of the design criteria and software specifications according to the standards.

1.1 Purpose

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

1.2 Scope

This document applies to the overall design of the system. It contains information relating to the architectural design of the software, the Structure of the Database, and of the physical servers hosting the site.

1.3 Definitions, Acronyms and Abbreviations

  • IIS – Web Server
  • ASP.NET -  Microsoft web platform
  • HTTP – Hypertext Transfer Protocol
  • T-SQL – Transact SQL
  • WWW – World Wide Web
  • SAD - Software Architecture Document
  • UML – Unified Modeling Language
  • SOA – Service Oriented Architecture

1.4 Overview

This Document provides the reader with a deeper understanding of the design of ABC application. It is organized into several views of the system, the Logical View, which will give an overview of the subsystems and components the system is comprised and show how the system has been implemented and go into more detail about the  different parts of the system, the Deployment View, which will give go into how the system has been deployed and what it's being hosted on, and the Data View which will show how the database is structured and organized.



2.    Architectural Representation


This document details the architecture using the views defined.

2.1 The Logical View

shows a quick overview of all of the basic Subsystems in the System and gives a basic overview of the System as a whole.
This system was designed using a standard N tiered architecture, with a Presentation Tier, Business Logic Tier, Data Provider Tier, Entities Tire and Common Tire.
  • The Presentation Tier

Contains all of the Pages in the Web Application, Tasks in the Windows Service or Forms in the Windows Application (or WPF) and handles all inputs, schedule tasks.
  • The Service Tier      


Provide Web Services (SOAP /REST) APIs that need for Presentation Layer and External Systems.
  • The Business Logic Tier


This tire handles all the business logics related to all the components. Transaction logics also handle in the same tier.
  • Data Provider Tier


This tire will provide all the data from database and handle all the operations with the Database which is required to the Business Logic Tier.
  • Entities Tier


This tire provides all the entities related to the database operations and custom entities to handle application operations.
  • Common Tier


This tire includes the common functionality such as logging, enumerators and constants etc. related to the application.

2.2 The Deployment view

Tells how the system is physically configured. The Implementation View gives a more in-depth view into how the system has been deployed.

2.3 The Data view

Shows how the Database is setup and structured.
Note:
Transactional database with normalized to 3ed normal form with including all the relationships and constraints (unique key etc.) 

3.    Architectural Goals and Constraints


3.1 Security

For Authentication and Authorization keep data in the database as encrypted text. Authorization based on Roles and Rules defend the system.   

3.2 Persistence

Data persistence will be addressed using a relational database.

3.3 Performance

All the transactions should be less than 3 seconds except bulk insert and bulk updates. Bulk insert & updates needs to be used to maintain for the large transactions. Limit the data that reading from database.
Note: System performance can depend on available hardware and the network bandwidth.

4.    Logical View


4.1 Overview


This Diagram shows the high level architectural design that the system is broken down into. 




























4.2 Architectural Significant Design Packages


  • ·         Presentation Layer

The Presentation Layer is composed of several packages, Web Applications, Web Services (API) and Windows Service. Web Application components used Web Pages as the primary interface,
  • ·         Service Layer

Web Services expose WCF and REST APIs for the Presentation Layer and for the External Systems. This connects the Presentation Layer to the Business Layer. All communication with the Business layer is done through Service Layer.
  • ·         Business Layer

The Business Layer provides the business logic and connects the Service Layer to the Database. All communication with the Service layer is done through Business Layer.
  • ·         Data Layer

The Data Layer connects with database and provide all CRUD operations. The Data Layer provides persistence for the system and all communication is done through Entity Framework.
  • ·         Shared Types

This layer contains all the shared types to the whole application such as Entities, Enumerators, Constraints and Resources.
  • ·         Frameworks


This contains all the framework that supports for application operations. 


5.    Deployment View






















Application is exposing as an Internet Application through HTTP and Authentication will happen through HTTPS.

Load balancer distributes application traffic across two servers. It increases the reliability of applications.


SQL Server 2012 database stores all the information related to all the transactions. 




6.    Data View


Object Relation Mapping (ORM) framework used for data view that support the development of data-oriented software applications. ORM framework enable developers to work with data in the form of domain specific objects and properties. Application deal with data, and can create and maintain data oriented applications with less code than in traditional applications.

7.    Size and Performance


This architecture will support to several individual Wed Applications, WCF Web Services, REST Services, Windows Applications and Windows Services.
Performance of individual transactions will be less than 3 seconds except bulk or backend tasks.

8.    Quality


Loosely couple layers by using dependency injection. High level layers are not depending on low level layers.
Maintain Code Quality and Scalability with following Microsoft Cording Standards and best practices.
Follow SOLID Architectural Principles to increase the extendibility and maintainability of the system.  

9.    Technologies Used


  • ·         .Net Framework 4.6.1

Asp.Net 5 came with this (Framework 4.6). Asp.Net 5 has many more features.
  • ·         ASP.NET MVC 5

MVC 6 is there under Asp.Net core project. Because of using traditional .Net Framework 4.6.1, MVC 5 is the latest.
  • ·         WCF Services (REST)

Client and server are very loosely coupled.
No fixed API
REST user http verbs to interact with interact with the resources (GET, POST, PUT, DELETE)
Less overhead (no SOAP envelope to wrap every call in)
More human readable and testable (harder to test SOAP with just a browser).
REST has been preferred for services that are exposed as public APIs
Data in all possible formats, such as XML and JSON.
Visibility, reliability and scalability
  • ·         ASP.NET MVC Localization and Globalization for Multilanguage

Inbuilt support Localization & Globalization
  • ·         Bootstrap 3.X for Responsiveness

MVC 5 is added Bootstart 3.x as the default user interface framework.
Since bootstrap 4.x is alpha version(v4.0.0-alpha.6), bootstrap 3.x is the stable.
  • ·         Angular

According to the Knockout & Angular comparison, Angular is good than Knockout.
Check the comparison in the feature comparison section.
  • ·         JavaScript/jQuery
  • ·         Log4net for logging

Open source
Easy to Implement
Fast logging
Many more features (Event Log, Flat File, Email Logging)
  • ·         Entity Framework 6

Dapper is very fast than EF. But need to write SQL Queries and SP with Dapper. Advantage with EF is, no need to write SQL queries and SPs
EF has the ability to execute queries using raw SQL with almost same performance with Dapper.
  • ·         Unity for Dependency Injection.

Maintainability: The ability to alter the behavior of your code with a single change.
Readability: quickly and easily see exactly which concrete classes are mapped to which interfaces and know that there are no hidden implementations.
Design: I believe using dependency injection helps create well designed code.

Testing: Dependency injection allows you to test your code without having to write code specifically for tests.


10.    Reference


=====================================================================


1.    Document Purpose

This document will describe detail of a design, such as:
  • The signature of an interface, including all data types/structures required (input data types, output data types, exceptions).
  • Detailed class models including all methods, attributes, dependencies and associations.
  • The specific algorithms that a component employs and how they work and physical data models including attributes and types of each entity/data type.


2.    Requirements addressed


#
Requirement
Notes
1


2


3




3.    Design Consideration

This specification based on the “Name of the design document” document.

3.1 Assumptions

Assumptions for the implementation.

3.2 Constraints


Limitations in the implementation.


4.    Architecture

Mention the architecture document or architectural consideration that you are following.

4.1 Subsystem, Component or Module


Mention the relevant area for the implementation. 


5.    Database


5.1 Table, Columns and Relationships

Description of Table, New Columns needs to be added and Constraints (Foreign Key, Unique Key etc.)

Table Name: Customer
Field Name
Data Type
Allow Null
Default
Description
Amount
Decimal
No
0







5.2 Stored Procedures

Stored Procedures needs to be added or modified.
Name
Nature of Change
Description
GetEmploye
Add
Get Employee record by Id.




5.3 Triggers

Triggers need to be added or updated


5.4 Data Migration

Provide description how data should be migrated to new table or added columns.
Table Name: Status

Id
Name
Status
Description
1
New
1
New Status
2
Pending
1
Pending Status


6.    High Level Design


6.1 Page Name (Name of the UI, Service or Task)


Mention the name of the UI, Service Interface or Windows Service Task. Any wire-frames, add them. 


7.    Low Level Design

Mention the detail design of the features. 

7.1 View Page

Description and appearance of the View.

7.1.1 Methods needs to be implemented

Detail description or name of the methods needs to be implemented

Class
Method Name
Description








7.2 Search Page

Description and appearance of the Search Function.

7.2.1 Methods needs to be implemented

Detail description or name of the methods needs to be implemented
Class
Method Name
Description








8.    Change Affecting Area


Description of change affecting area for other functionalities. 
=====================================================================



1.    Document Purpose

Purpose of this document to give a guideline to developers about how the mentioned functionality needs to be designed according to the architecture.
  • Relevant goals or requirements (functional and non-functional).
  • Static structure (components, interfaces, dependencies).
  • Dynamic behavior (how components interacts).
  • Data models or external interfaces (external to the system/component described in the document).
  • Deployment considerations (run-time requirements, third-party components).

2.    Requirements addressed


#
Requirement
Notes
1


2


3




2.1 Assumptions

Assumptions for the implementation.

2.2 Constraints


Limitations in the implementation.


3.    High-level Design

3.1 List of Use Cases

List all the use cases for the design.

3.2 User Case Diagram

This will mention the use case diagrams mentioned above.

3.2.1        User Case for [Name of the Use Case]


3.2.2        User Case for [Name of the Use Case]


4.    System Architecture


Overall structure of the architecture by using a diagram.


5.    Modules

Modules that needs to be implemented. Subsections divide by based on the user cases.

5.1 [Specific Page] in the Portal

Specify what is the functionality.

5.1.1        Class Diagram

Class diagram for the specific module should place here.

5.1.2        Sequence Diagram

Sequence diagram for the specific module should place here.

5.1.2    Entity Relationship Diagram

ER diagram needs to be mentioned here.


5.2 [Specific Task] in the Windows Service


Specify what is the functionality. 


6.    Database Structure


This needs to be mentioned how the table structure needs to be normalized. 


7.    Non-functional Requirement

Non-functional requirement when implementing the specific requirement.

7.1 Performance Requirement


Performance related to the functionality. 

8.    Tools and languages used

Tools and Languages that needs to be used.

9.    Deployment Considerations

deployment considerations

10. References


Reference related to the design.
=========================================================================

1 comment:

Encrypt/Decrypt the App.Config

Program.cs using System; using System.Diagnostics; using System.IO; namespace EncryptAppConfig {     internal class Program     {         pr...