state & sequence diagrams - mobile bank

Sequence Diagrams

                    Sequence diagrams document the interactions between classes to achieve a result, such as a use case. Because UML is designed for object-oriented programming, these communications between classes are known as messages. The Sequence diagram lists objects horizontally, and time vertically, and models these messages over time.

Notation

In a Sequence diagram, classes and actors are listed as columns, with vertical lifelines indicating the lifetime of the object over time.

BEHAVIORAL MODEL - MOBILE BANK

Consider the example of a verterinary system. Animals served, such as dogs and birds, are tracked along with their owners. The following diagram models a potential solution. Since dogs and birds are "a kind of" animal, we use a Generalization relationship.

To validate your model, you can apply real-world data into instances of the classes. In fact, there is a diagram for precisely this task, the Object Diagram.

BEHAVIORAL MODEL:

State chart Diagrams

             State chart diagrams, also referred to as State diagrams, are used to document the various modes ("state") that a class can go through, and the events that cause a state transition. For example, your television can be in the off state, and when the power button is pressed, the television goes into the on state. Pressing the power button yet again causes a state transition from the on state to the off state. In comparison the other behavioral diagrams which model the interaction between multiple classes, State diagrams typically model the transitions within a single class. 

State	The State notation marks a mode of the entity, and is indicated using a rectangle with rounded corners, and the state name written inside.
Transition	A Transition marks the changing of the object State, caused by an event. The notation for a Transition is an arrow, with the Event Name written above, below, or alongside the arrow.
Initial State	The Initial State is the state of an object before any transitions. For objects, this could be the state when instantiated. The Initial State is marked using a solid circle. Only one initial state is allowed on a diagram.
Final State	End States mark the destruction of the object whose state we are modeling. These states are drawn using a solid circle with a surrounding circle.

Here is an example State Diagram that models that status of a user's account in a Bug Tracker system:

elements on a Class diagram - mobile bank

Class Diagrams

        Class diagrams identify the class structure of a system, including the properties and methods of each class. Also depicted are the various relationships that can exist between classes, such as an inheritance relationship. The Class diagram is one of the most widely used diagrams from the UML specification. Part of the popularity of Class diagrams stems from the fact that many CASE tools, such as Rational XDE, will auto-generate code in a variety of languages, including Java, C++, and C#, from these models. These tools can synchronize models and code, reducing your workload, and can also generate Class diagrams from object-oriented code, for those "code-then-design" maintenance projects.

Notation

The elements on a Class diagram are classes and the relationships between them

Class	Classes are the building blocks in object-oriented programming. A Class is depicted using a rectangle divided into three sections. The top section is the name of the Class. The middle section defines the properties of the Class. The bottom section lists the methods of the class.
Association	An Association is a generic relationship between two classes, and is modeled by a line connecting the two classes. This line can be qualified with the type of relationship, and can also feature multiplicity rules (eg. one-to-one, one-to-many, many-to-many) for the relationship.
Composition	If a class cannot exist by itself, and instead must be a member of another class, then that class has a Composition relationship with the containing class. A Composition relationship is indicated by a line with a filled diamond.
Dependency	When a class uses another class, perhaps as a member variable or a parameter, and so "depends" on that class, a Dependency relationship is formed. A Dependency relationship is indicated by a dotted arrow.
Aggregation	Aggregations indicate a whole-part relationship, and are known as "has-a" relationships. An Aggregation relationship is indicated by a line with a hollow diamond.
Generalization	A Generalization relationship is the equivalent of an inheritance relationship in object-oriented terms (an "is-a" relationship). A Generalization relationship is indicated by an arrow with a hollow arrowhead pointing to the base, or "parent", class.

LOGICAL DESIGN: - MOBILE BANK

         This project was developed in a modular fashion. The whole Project is divided into seven objects. This work of object is done based on the various activities that are to be carried out in the system. Which altogether result in obtaining intelligent outcomes? The objects are:

• Admin
• Customer
• Admin:   

                Admin is the person who is controlling the entire site by doing the required  operations i.e., uploading files, providing space to companies, updating accounts, sending sms, etc., Admin will generate the reports to hold complete details of transactions

Customer:

           The customer is made comfortable by not being asked to register completely for his/her first visit; he/she can enter his/her e-mail Id for visiting site. However to use the  , the customer must register themselves. The customer may choose the category and time to receive Adds and can get information, download as well. The payment for the SMS will be adding to his/her account automatically. The customer may give feedback   to the company directly.

Text Notation & Scenario of mobile bank

The following image shows how these three basic elements work together to form a use case diagram.

Text Notation

Behind each Use Case is a series of actions to achieve the proper functionality, as well as alternate paths for instances where validation fails, or errors occur. These actions can be further defined in a Use Case description. Because this is not addressed in UML 1.4, there are no standards for Use Case descriptions. However, there are some common templates you can follow, and whole books on the subject writing of Use Case descriptions . 

Scenario

name: Registration

Actors: User, Admin

Flow Of Control: 

1)      Fill the registration form

2)      User will check the availability for ID

3)      Enroll registration details with ID and Password.

Scenario name: Login

Actors: User, Admin

Flow Of Control:

1)      User enter ID and Password

2)      Admin will check for authentication

3)      Generates the page with inbox or with error

Scenario name: Browse for Mobile information

Actors: Viewer

Flow of Control:

1)      User can check balance amount

2)      User can add friends.

3)      User can view profile.

4)      User can do online money transfer.

5)      User can view friends.

Scenario name: Get paid to the user

Actors: Viewer, Admin

Flow of Control:

1)      User checks the account to get paid

2)      User will select to pay if the amount.

Scenario name: Update customer account

Actors: Admin

Flow of Control:

1)      Admin will subtract from the customer

2)      Admin will add the amount to the customer account

Use case diagram for admin - Mobile bank project

Actor	An Actor, as mentioned, is a user of the system, and is depicted using a stick figure. The role of the user is written beneath the icon. Actors are not limited to humans. If a system communicates with another application, and expects input or delivers output, then that application can also be considered an actor.
Use Case	A Use Case is functionality provided by the system, typically described as verb+object (eg. Register Car, Delete User). Use Cases are depicted with an ellipse. The name of the use case is written within the ellipse.
Association	Associations are used to link Actors with Use Cases, and indicate that an Actor participates in the Use Case in some form. Associations are depicted by a line connecting the Actor and the Use Case.

Scenarios & Use case diagrams - Mobile Bank

SCENARIOS

           It is an instance of a use case describing concrete set of actions.  Scenarios are used as examples  for illustrating common cases.  Their focus is on understandability.

Use cases are used to describe all possible cases.  Their focus is on completeness. We describe a scenario using the template with three fields:

Ø     The name of the scenario enables us to refer to it unambiguously.

Ø     The participating actor instances field indicates which actor instances are involved in this  Scenario.

Flow of events of a scenario describes the sequence of events step by step.

USE CASE MODEL OF THE SYSTEM

Use Case Diagrams       

Use Case diagrams identify the functionality provided by the system (use cases), the users who interact with the system (actors), and the association between the users and the functionality. Use Cases are used in the Analysis phase of software development to articulate the high-level requirements of the system. The primary goals of Use Case diagrams include:

• Providing a high-level view of what the system does
• Identifying the users ("actors") of the system
• Determining areas needing human-computer interfaces

Use Cases extend beyond pictorial diagrams. In fact, text-based use case descriptions are often used to supplement diagrams, and explore use case functionality in more detail.

UNIFIED MODELING LANGUAGE (UML) NOTATIONS - MOBILE BANK

UML stands for Unified Modeling Language . 

The representation of the entities involved in the project which later need to be built.

     The unified modeling language allows the software engineer to express an analysis model using

      the modeling notation that is governed by a set of syntactic, semantic and pragmatic rules.

     A UML system is represented using five different views that describe the system from distinctly

      Perspective.  Each view is defined by a set of diagrams, which is as follows.

     This view represents the system from the user’s perspective.

     The analysis representation describes a usage scenario from the end-users perspective.

UML is specifically constructed through two different domains they are

     UML Analysis modeling, which focuses on the user model and structural model views of the System.

                  Software design is a process that gradually changes as various new, better and more complex methods with a broader understanding of the whole problem in general come in to existence. There are various kinds of methods in software design .Mainly there are as follows

• Use case diagrams
• Class diagram
• Object diagram
• Sequence diagram
• Deployment diagram
• Activity diagram

State chart diagram

Scheduling & Requirements of MOBILE BANK

PROJECT SCHEDULING:

                  To develop this project I have follows the following schedule to fulfill project requirement including documentation with strong testing:

Analysis: 15 days 

Design: 15 days 

Coding: 1 Month

Testing: 15 days

Documentation: 5 days 

Therefore I have taken 3 months to develop my successful project.

FUNCTIONAL REQUIREMENTS:

              The functional requirement of the system defines a function of software system or its components. A function is described as set of inputs, behavior of a system and output.

·        Timeline should not be disturbed.

·        Fast and efficient.

·        Computationally simple.

NON -FUNCTIONAL REQUIREMENTS:

                      A non-functional requirement in software engineering presents systematic and pragmatic approach to ‘building quality into software systems’. System must exhibit software quality attributes such as accuracy, performance, security and modifiability.

·        Response time: Time taken by the user to get output.

·        The NOVAL –SCP system provides user friendly GUI (Graphical User Interface).

·        Memory usage: It is total amount of memory used by the system.

SOFTWARE REQUIREMENTS SPECIFICATION- MOBILE BANK

The output of requirement analysis phase is SRS, which is clear and concise specification of detailed functional description, indication of performance requirements and design constraints, appropriate validation criteria and  other data pertinent to requirements.

1. Scope:

                       To provide information available on a web service to all the mobile users.

      2. Overview:

            The project is designed & coded in such a way that in any other modifications that are needed in future can easily implemented with out effecting the functionality of the system.

Overall Description

1        Product Perspective: 

                  The objective of the online mobile Banking service is to provide a great

Communication between the mobile users

Product Functions:

                  The creation of a web-service which act as a mediator in between mobile users and database.

3 User Characteristics:

This is assisted by mobile application that allows mobile users to communicate with web-service to get the information available on a web-service and also allow user to communicate with banks via mobile services

2.4.PROJECT PLANNING:

It was decided to use good Software engineering principals in the development of the system aiming to expand their operations in the near future. So the following Project Plan was drawn up:

1. The Analysts will interact with the current manual system users to get the Requirements. As a part of this the Requirements Specification Document will be created.

2. The requirements Specifications document will contain the Analysis & Design of the system.

3. The Analysis, Design, Implementation & testing of the System will be followed to produce an incremental cycle, which will deliver milestones like the Requirements Specification Document etc., at the end of each of the iterations, Phases or cycles.

4. The Architecture & Technologies will be decided as a part of the Analysis of the requirements.

5. Once the Design is ready the Implementation & Testing strategy of the system will commence. Each will be independent of the other. The implementation of the system itself will be broken down into sub-systems following the Software Engineering principles for the development of robust software.

6. Once the implementation is ready, the System testing will take place. If the system is judged to be stable then Acceptance testing by the Users will take place & once the Users are satisfied the System will be rolled out to the Users & they will be trained on how to use it for an initial period.

Feasibility study of Mobile bank project

               Feasibility study is the high level capsule version of the entire requirement analysis process. The objective of feasibility study is to determine whether the proposed system can be developed with available resources.

There are three steps to be followed in determining the feasibility of the proposed system.

1.    Technical Feasibility

2.     Operational Feasibility

3.     Economic Feasibility

Technical Feasibility:

                  The proposed system needs the data in an efficient manner i.e., it needs protection of data and authorized access to data. This is done when we use the software which supports console oriented methodology and database methodology.

                        Therefore technical feasibility determines whether the organization has the technology and skills necessary to carry out the project and how this is obtained. The system is technically feasible on the following grounds:

·        All necessary technology is available those are required to develop the system.

·        The existing resource is capable and can hold all the necessary data in an efficient way.

·        The system is too flexible and can be expanded further.

·        The system can give guarantees of accuracy, ease of use, reliability and data security

The system can give instant responses.

Proposed System & Technologies in Project

Proposed System:

By the help of this application we can access and manipulate the bank transactions through mobile services. So we can save our time and effort.

So we can reduce the pressure on bank employees also

Software Technologies:

Operating – System      : Windows XP/ 2000 /2003.

Front End                     : ASP .Net(C#)

Back-End                      : Sql Server 2000

Web Server                    : Internet Information Service (IIS)

Microsoft mobile Explorer 3.0

Hardware Technologies:

Processor               :  Pentium III processor (800MHz.)

Memory                :  128 MBRAM

Hard Disk             : 10 GB HDD

Existing system of mobile bank project

Existing System:

The existing system is a manual process. Numerous accounts are to be maintained: 1) Maintain Records for each Account. 2) Note Deposits and with draw transaction for each account. The existing system to be maintains lot of paper work information’s. When any statistical analysis is to be carried out, for example: a comparison of the past year’s deposits or withdraws with that of the current year, it is also a laborious task of referring to many record books, compiling lists, and carrying out the analysis work.

Problems With Existing System:

      Lot of space is required to store all the details of the candidates and the Companies.

     The system is prone to human errors. Detection of errors is a difficult task since every thing is done manually.

     Tracking of errors to their origin is difficult

  There is no security to data. Any one can view through the data concerning the activities of the Consultancy

    Any modification to the data requires searching through all the records and then making the relevant changes.

The process is very time consuming.

MOBILE WEB FORM CONTROLS - MOBILE BANK

The mobile Web Forms controls are ASP.NET server-side controls that provide user interface elements such as list, command, call, calendar, and so on. At execution time, the mobile controls generate the correct markup for the device that makes the request. As a result, you can write a mobile application once and access it from multiple devices.

               Because these mobile controls are based on the ASP.NET controls, you can leverage your current desktop development skill set when creating mobile applications. You can also reuse the same business logic and data access code that you use in your desktop application. Mobile and desktop Web Forms can reside in the same Visual Studio .NET project. This makes an application faster to develop and lowers your maintenance cost.

                The following example provides just a taste of programming with mobile controls. In this example, the Hello, World program creates a mobile Web Forms page with a single form on it. That form contains a Label control with the string: "Hello, Mobile World".

<%@ Page language="c#" Inherits="System.Web.UI.MobileControls.MobilePage" %>
<%@ Register TagPrefix="Mobile" Namespace="System.Web.UI.MobileControls" Assembly="System.Web.Mobile" %>
<mobile:Form id=Form1 runat="server">
<mobile:Label id=Test Runat="Server">Hello, Mobile World</mobile:Label>
</mobile:Form>

Requirements of mobile bank project

Here we are going to learn what are the tools used , software and hardware 

requirements  for the mobile bank project.

TOOLS USED:

Operating system                      :     Windows 2000 /XP or later

Front End Software                  :       ASP.NET WITH C#

Back End Software                  :      SQL SERVER

Servers                                     :       IIS Server
 

Software Requirements:

• Windows XP/2000 professional operating system
• C# .net
•  SQL SERVER
• Microsoft Mobile Explorer

Hardware Requirements:

  Intel® Pentium IV 2.6GHZ Processor

  Main Memory: 512 MB