Object Oriented System Analysis and Design



Object Oriented System Analysis and Design

The objective of this section of the Mindfulness website is to address the needs presented in the RFP for Tech Mindfulness.  The objective of this section of the RFP was to create a support organization to be able to assist practitioners with the Mindfulness resources and trouble shoot challenges practitioners will have. The services to be provided by this system are:

  • Help Desk Ticketing
  • Live Chat Support
  • Remote Assistance Support

During the clarification session with the organization it was outlined that there will be different levels of support that will be provided to donating members and non-donating members. Donating members will gain the additional functionality of the Remote Assistance sessions where non-donating members will not.  This system is to be integrated into the overall Mindfulness portal and provide easy and intuitive access to the end users.


To start the process we review the documentation and drew from personal experience and research to understand and decompose the events of how the services would be provided to the end users. To do this we started working on the initial steps of the Vision Statement but breaking down the system capabilities and application benefits:

System Capabilities-object Oriented System Analysis and Design

  • Portal with authentication services to manage user profiles and accounts securely
  • Support of community interaction in a blog format with end users’ ability to track and document contemplative tasks
  • Support on both mobile devices and various web browsers
  • Education platform that can divide the content between user credentials of those who are paid participants vs free users
  • Ability to stream and deliver multimedia content to end users
  • Technical support tools to all for remote troubleshooting and FAQs
  • Video and picture editing components for publications on website


Application Benefits

  • Enable content consumption in multiple media formats to increase membership
  • Strong support so small practitioners are encouraged to join and share on the site
  • Increased membership and revenue
  • Improve mindfulness community by connecting practitioners

Object Oriented System Analysis and Design

To expand our research further we will use a phased approach to discover and design as highlighted below:

  1. Discover and analyze of TIM needs
  2. Interview stake holders, Members of the board, the part time volunteer, and participating practitioners
  3. Identify the information types that needs be satisfied by the site
  4. Identify the use cases for the tech services
  5. Develop workflows for the sites to enable these services
  6. Design the components of the solution
  7. Design the database tables for capturing member information
  8. Design site plug ins for support and layout and screens
  9. Design/Select the platform to deliver the support and content to end users
  10. Design details of content and collaboration

III.  Program the system-object Oriented System Analysis and Design

  1. Create the database.
  2. Create the support page
  3. Create the subsequent pages with member and non-member options
  4. Test it and use it
  5. Test the operation of the website
  6. Test the content delivery systems for various forms of media on multiple devises
  7. Select several stakeholders to participate in a beta test


Taking the discover phase one step deeper by identifying the stake holders and commencing interviews to get a greater understanding of the requirements.  We identified our stakeholders as:

  • Board Members
  • Volunteers
  • Practitioners Donating
  • Practitioners Non-Donating

The stakeholders and their perspectives give us a lot of information to continue to refine the requirements of the system from a functional and non-functional perspective. Some of the questions we asked to help refine these requirements were:

  • How do you consume content about mindfulness today?
  • How do you share content with others?
  • What similar websites do you visit today?
  • What features are most important to you on those websites?
  • Do you feel this features would be valuable?
  • How do you request technical assistance on other sites?
  • What methods of troubleshooting do you use commonly today?
  1. During the requirement process we isolated functional requirements and non-functional requirements. This will make sure we are striving for the correct goals when designing and implementing the system.
  2. Functional
  • Ability to create tickets
  • Ability to communicate via chat
  • Ability to use remote sessions for viewing and remote control
  • Keeping a simplistic and easy to use interface
  • Documentation to train volunteers

Non-functional-object Oriented System Analysis and Design

  • Usability – finding and submitting requests for help needs to be very intuitive. The nature of support is that something is not working as expected so the ability to locate help quickly and communicate the issue is a given for the system.
  • Reliability – utilizing tools that work on multiple platforms with a cloud based platform that can scale to meet growth with low startup costs
  • Performance – will largely be based on the end users internet provider speeds; however, the use of the tools should be quick to connect and be latency tolerant to a certain degree
  • Security – secure connections and data privacy is a theme for the entire system and should be supported with the Tech module as well. Specific to Tech we want to focus on secure connections to end users from remote access to avoid man in the middle and replay attacks.



Now that we have a better idea of the functions and stakeholders we can start to define use cases and classes that will be a part of these functions.  The use cases centered around the core support objectives:

  • Placing Service Ticket
  • Initiating Chat with Support
  • Initiating Remote Assistance Session with Support

The classes that are necessary to support these activities are:

  • user
  • supportTicket
  • practitionerMember
  • practitionerNon-Member
  • volunteer

These steps have all assisted us in building up the use cases diagram to mapping interaction between actors and the system.  To take this one step further we formally list out the actors as shown in this diagram and the various interactions they could have with the system.

Object Oriented System Analysis and Design

During event decomposition each event will be identified with a name, a state type and a resulting use case. This gives more formal classification to the manner in which the actor is interacting with the system.

Event Type Use Case
Practitioner creates/views posting External Creates/View data
Practitioner submits Requests Chart Support External Request Assistance
Practitioner submits support ticket External Request Assistance
Volunteer receives support ticket External View data
Volunteer views posting External View data
Support Ticket Summary Reported Temporal View trend data


Object Oriented System Analysis and Design


From here we want to take steps towards documenting the types of relationships event further by identifying how many each can have between one another.  We also take the classes and start limiting data between them to reduce duplicate information in preparation for the database development.  This was the first step of the Domain Model Class Diagram we developed to match up with the use cases and classes defined above.














Object Oriented System Analysis and Design

One step further towards understanding the relationship between events and use cases is to document their relationship is to modify the use case diagram shown here:

This incorporates the various interactions and helps us understand the how multiple actors might use the same processes. By a better understanding of this we might have the ability to repurpose code for multiple use cases.  This information is also helpful with us being to map out inputs and output requirements that will impact the design of the environment.

Object Oriented System Analysis and Design

The design of the environment is more conceptual for this module due to the selection of a infrastructure as a service provider. Our focus is less on the physical layer and more surrounding the inputs and outputs between subsystems as well as securing the transfer of data. The conceptual mapping begins with the understanding we will need a ticketing system that will log information in a database and a reporting system to keep track of the tickets.  Other subsystems that will be triggered by the user or by the ticket would be the Remote Control and Chat subsystems.  When looking at these systems we need to start to evaluate what types data, their sensitivity, and how to secure their storage and transport.  A few key questions we had to answer were:

What regulations we are required to follow?
This system would be primarily impacted by the PII restrictions to protect their clients’ personal data. This data will be collected and stored in the system so protocols would need to be the proper security standards. This system could also be impacted by PCI compliance depending on how the identity information is shared with the finance portal.  Our recommended approach would be to limit data’ sharing with the least privileged approach.

How should the system ensure data security during transmission of data?

To ensure privacy and security of data in transit we would use Https protocols with TLS. By securing the content with the end users connection we should be able to protect any personal information that might need to be transferred.  We can also transmit keys for encrypted connections with our remote assistance application. The remaining data is the user contributing in a public forum with the intent of being shared.  Our only focus there would be to protect the integrity.

Consider the data storage issues related to a mobile device and the possibility of It being lost or stolen.
The design of the system will be functioning in a web browser with HTTPS and password protection to access personal data.  The password system will comply with best practices on character length and special characters as requirements to help prevent brute force and dictionary attacks. Finally, the page will have a time out feature when authenticated should the device be lost or stolen to limit the window in which the data can be exposed.

Consider the issues related to accessing the system from multiple systems and on and off premise.

The system will be full web enabled HTML 5 to support multiple form factors with the same level of security constraints no matter the device. The site by nature is built for mobility and to reduce support issues.  Data in transit will be protected when authenticated section of the site are accessed for personal account information.  That information will be presented in a form fashion with all secure data such as credit card numbers being abstract to only show the final four characters. Data will be able to input but very little will be output for security purposes. For our remote connections such as remote control and chat support features, we will distribute asymmetric keys after authentication to be able to have secure access to the end users systems.

What security issues relate to wired and wireless transmission of private data? Does this change with a hosted provider?Object Oriented System Analysis and Design

The system will function on a platform that will treat data transmission the same and the limited amount of secure connectivity will be managed through HTTPS.  Outside of this our biggest concerns will be around the hosted provider we are selecting to meet our needs.  We will need to do extensive investigation into our providers to ensure our level of privacy is met for our authenticated users.  This will be dictated more by the financial side of the site where we will need to meet PCI compliance for the credit card accounts and processing.

Object Oriented System Analysis and Design

At this step of the design we start to story board our system. Using the Use Case Diagram with the workflow relationships we built in and with an idea of the infrastructure, we can start to create a loose user interface to follow the steps the end user would take to access the system.  This will be used for later meetings with the stakeholders to ensure we are on track with the design and collect feedback.  Usability is critical, and creating this module for a system that does not exist makes it challenging to collect feedback because the end users have not had a system yet that they in fact would need help with.  This is why we stuck with more vibrant and detailed visuals to enhance the communication experience with the stakeholders.

User Requests Help via Support Ticket:

Volunteer Receives Ticket in Reporting Que:


Volunteer recognized end user is online and initiates the chat subsystem to start communicating about the issue:


Finally the end users issue is resolved and the ticket is closed.  Stakeholders can view the progress and performance of the tech support volunteers from a dashboard.



At this point of the project we have concluded our initial iterations of analysis and design and it is time to prepare and present our System Vision Document to the client.  This document will help us get approval to move forward with the development of the system and highlights critical pieces of information we discussed during the system decomposition as well as clarify goals and core functionalities for the system. Here is a sample of our System Vision Document.


Problem Description

The Institute for Mindfulness is a group looking to make a difference in the contemplative practices sector and the good news is that it is a non-profit organization.  They aim to do good but are faced with  hindrances such as the proper way to collect and disseminate educational materials to the people that need it, the buyers and business people. They would like it if the method of dissemination to be done safely and in an effective manner. They are eager to make payment collection easier and make standard media.

Capabilities of the system.Object Oriented System Analysis and Design

  • Authentification service portal that manages user profiles and accounts in good security.
  • A blog that allows the community to interact and enables the community to track and document contemplative tasks.
  • Mobile devices including phones, tablets and laptops and various web browsers will be supported by the system.
  • Free users and paid participants can easily be identified on an education platform that determines user credentials.
  • Services such as the use of directories to search, connect and list help the users in various functions.
  • Availability of troubleshooting, visual streaming, audio streaming tools.
  • PayPal and e-commerce portals provide secure payment options.
  • The possibility of linking various news publications.
  • Tracking for donations can be done through accounting.
  • Users have the ability to stream content on the system.


Business Benefits-object Oriented System Analysis and Design

 Benefits to the Board.

  • They will be able to educate members through mission statements.
  • Compliance and audit issues will be resolved.
  • Payments will be easier to make for the organization, thus organizational sustainance.


 Benefits for Volunteers

  • They will be able to conduct operations such as education and others.
  • They will have education tools to reach customers more easily.

Benefits to Members                                          

  • A common venue for members and therefore an opportunity to learn from others.
  • Ability to network with members of common background.


Support Functions-object Oriented System Analysis and Design

  • Support Ticket submission
  • Remote Support Session
  • Chat Support Session
  • Receive Support Ticket
  • Support Ticket Reporting

Ticket Manager System

  • Credential Verification
  • Edit Ticket
  • Delete Ticket
  • Enter Ticket


Project Sequencing and project iteration schedule

Iteration 1

  • Input Ticket
  • Delete Ticket
  • Ticket Viewing Log
  • Edit Ticket

Iteration 2

  • Chat System Integration
  • Remote System Integration

Iteration 3

  • Ticket Integration with Chat and Remote Support
  • Ticket Integration with User Authentication Module
  • Integrate ticket reporting

Iteration 4Object Oriented System Analysis and Design

  • Testing
  • User Acceptance testing
  1. An estimated timeline proposed by the system schedule in Gantt chart form to communicate the progress to the client.


Assuming approval to move forward with the above project as proposed, we will gear up for our next iterations that are more focused on Design and Implementation.  This iteration will take the feedback we got form the Vision Document proposal and we will incorporate those recommendation into the project.  During this process we found we needed to refine our Design Class Diagram which is shown below.

This was the basis for the First Cut Sequence Diagram.  Below shows a sample of our actor interacting with the system to request a chat support session or kicking off an external event. This creates a series of state events in the system to start the chat system for the volunteer to provide the actor assistance.

These diagrams are essential for the integration of our open source subsystem that we will be using.  It helps us define the start and stopping point of the modules which will be critical for support documentation in the future.

Object Oriented System Analysis and Design

During this iteration we can now take the data points we have been working with for the conceptual ticketing system and incorporate them into a database planning session.  This iteration would be the identification and labeling of our data types.  We will focus on normalization to simplify the data sets to reduce duplicate data and strive to get all tables into third normal form for performance.  Finally we focus on the linkage or relationships between the tables as show in the Entity Relation Diagram.

Table Name Fields (columns)
Practitioner practitionerId, firstName, lastName, PhoneNumber, emailAddress
Volunteer volunteerId, firstName, lastName, PhoneNumber, emailAddress
eTicket ticketId, category, description, status, practitionerId, date
replyTicket replyId, ticketId, volunteerId, remoteAccessId,chatId, date
remoteAccess remoteAccessId, date
chatWindow chatId, Date


Object Oriented System Analysis and Design


  1. Once a database design is complete, the coding of the system goes on. Implementation of the testing at three different levels of the process follows.  Unit testing is an important part of the process, however, we will focus more on the Integration and Stress/Performance testing as those are more applicable based on our use of open source code.
  2. We happen to have  a predeveloped open source code to shorten unit Testing making integration testing a significant part of our system. To ensure outputs are correctly shared, systems need to be intergrate although time is bound to be consumed.  During integration, testing of a driver  is essential but as  previously mentioned, we will, at times, have unstructured fields because we are collecting a user’s description of an issue.  Tech Mindfulness will need to be integrated into the other portals as well in a more simplistic approach but collaboration will be needed to ensure the pointers are available in other pointers to call the methods and direct them to the Tech Mindfulness service ticketing page to request assistance. Every integration will be subject  to thorough testing to ensure the correct data is being passed on so that the end user can be assisted and the volunteer has access to the tools they need to assist members.
  3. The use of a cloud provider will shorten the Stress and Performance Testing. The cloud will have the ablity to scale easily workloads without issue. Global issues of any kind with our code should be exposed in the Integration and Usability testing point because the ticketing system is linear.  A great concern however, would be the volume of tickets which will be limited by the volume of volunteers and the organization’s ability to sufficiently staff itself. This could even occur This could even be tested during production if we happen to run tight on a project.
  4. Our expected iterations for testing would follow this schedule:
Iteration Subsystem No of Use Cases Time Activities
1 Help Desk Ticketing 1 3 Begin Integration Testing
2 Help Desk Ticketing 1 2 Unit and Integration Testing
3 Help Desk Ticketing 1 2 Unit and Integration Testing
4 Help Desk Ticketing 1 2 Integration Testing
5 Remote Access Tool 1 2 Integration Testing
6 Remote Access Tool 1 1 Integration Testing
7 Chat Window Tool 1 2 Integration Testing
8 Chat Window Tool 1 1 Integration Testing
9 Reporting Dashboard 2 2 Integration Testing
10 Integration System Test   4  
11 Acceptance Testing   10  

Documentation will be critical to the successful administration of the system and troubleshooting of the integrated subsystems. The end user training should not be as vital because the nature of the system is focused specifically on the ease of use of the interface. It is a critical requirement for end users to request help with another section of the site easily.

End User Documentation will be FAQs posted in a button in the upper right of the screens to help end users navigate to the correct help features they need.  The remainder of end user prompts will be built into the buttons.  For example, a text field would not only have directions above but prior to typing in something like a phone number, the system will show an input suggestion in the box prior to it being clicked.  XXX-XXX-XXXX.

  1. Volunteer Documentation and System Documentation will be the greatest focus in system development.  A clear documentation for the operation of the system will be able to train new volunteers especially when it comes to using the trouble shooting tools in the end user PCs so that it’s easier for them to understand how working of the tool and the system that supports it to work seemlessly.  We assumed that alot of volunteers would work from time to time so that the documentation is clear and simplifiers their work.
  2. System Documentation will also require that iterations are  spent troubleshooting the Integration of the systems and the prebuilt subsystems.  Open source software from multiple publishers when used increases the risk of having to patch multiple systems even in necessity.  With this System we will need to have excellent documentation of the versions and the data flow in order to make sure when an upgrade is made the problems will not shift to other parts of the system.

Following the graduation from Alpha and Beta testing to production we will conclude the process by formalizing all of this documentation discussed above.  This will be part of the system deliverable to the client for their future reference.  We will come to a conclusion of the project by conducting a formal meeting with the client to get their sign off on the project as being completed.