Programmer's Notes

Notes on the web-development and artificial intelligence.

search...

8 Firefox plugins I use every day Database structure and filtering approach. SMS Notification system.

Requirements and Use Cases. SMS Notification System.

(3 votes, average: 3.67 out of 5)

Background
Ive graduated in March 2010 and I dont need to visit university any more. However, I enjoyed studying there and I know what challenges my fellow students-programmers have. Thats why I continue the job started this autumn computer club, we call it Geeks Club. Sure, were not true geeks there, but we tend to be So Im helping students whore interested in webtechnologies and in object-oriented programming. I explain them things that are not covered in the standard university course. Things, that are more practical and they can be paid money for. Here Ill be covering both OOP and web-dev, but well start from design hence OOP. The story began when some time passed after we started learning OOP at the club meetings and I decided that there is enough theory and separate examples, its time to build something practical that will be challenging for me too. I thought of different systems, but finally decided to pick up the SMS notification one. It requires both user interface, database, API (my friends want to communicate to it from standalone Java and C++ applications) and overall application design. In addition, Id like such system to be deployed at our university and it is interesting for me to create one.

Introduction
This is going to be a series of articles, Ill describe the progress and challenges we come across as we proceed with development. I think this kind of posts will be interesting for those who study OOP and want to apply what theyve learned to some practical things. Ill try to guide my students through the process using the iterative development methodology. We have meetings once a week (on Saturdays), so Ill post once or twice a week, depending on amount of work done on weekends and my free time during the week.

I think, this series will contain around 10 posts. Were going to share the work done as an opensource project. There is nothing to share at the moment, so Ill give the link when we code something

System overview
Vision
Obviously, the main purpose of the system is to send SMS notifications to students or tutors. These notifications may be quite different from the timetable changes to some announcements or even warnings (e.g. Due to the weather conditions, today is a day-off for all. Stay at home and have a good time). Actually the system isnt that complex. Basically all it needs to do is to enable administrator pick a group of users, enter the message and send it through the SMS gateway. The tricky things start from pick a group of users. We want this to be as flexible as possible so we could use this system not only for university, but any other organization.

University structure
This is obvious to anyone who studied at the university in Ukraine, Russia and former USSR, but Im not sure the structure is the same abroad. So we have the university. There are faculties (e.g. Computer Science, Philology etc). These faculties have specialties. For example, Computer Science faculty has 2 specialties Intellectual Systems of Decision-Making (mine) and Computer Engineering. (For those interested about the difference, first one deals more with AI technologies while the latter with system programming, networks etc). Next level is course. We call it so, but actually that is the year of study. I know, there are special words for the 1st year students, for the 2nd etc. Here we just say Im on the first course. That means Im studying the first year. All students that study the same specialty and are on the same course are called Stream. This is literal translation and Im sure there is some more correct term. Id be thankful if someone posts it in comments. There are 2-4 groups in the stream. In our university they are names as follows: 101, 102, 103 etc. First number is course. In this case it is the first one. Second number is the faculty code. 0 is for computer science. And the third number is the group number. Thus 102 is the second group of first-year students studying Computer Science. I realize that not all universities name groups like this, so we dont want to stick to such naming in our product. Now lets go through the tutors and staff. There is a rector of a university. There are deans for every faculty. And all tutors are grouped by departments. Usually, departments relate to the faculty, but thats not a rule. For example, on our faculty we have Department of Higher Mathematics, Department of Intellectual systems ans some others. One tutor usually belongs to one department.

In addition, there are different clubs for students like our Geeks Club, translators Pickwick Club etc. Some of these clubs (like ours) have departments (Web-development, OOP, Java, C++, Delphi, Administration etc). We want to be able to filter users using all the above groups plus some more user-specific filters like age or gender. Lets go through the planned features now.

User perspective
First of all, user can log in. User should enter his phone number and password. Well possibly add additional security for administrators. If administrator logs in, he enters his phone and password, but then a dynamic password is sent to his phone. And he completes login procedure only after he enters this dynamic password. Were not sure if well implement this. Your comments are welcome! Next, user can edit his profile. Hell have the following fields there:

Phone Email Password (and confirmation) Name, surname, patronymic Gender Birthday ICQ Faculty Course (1st year, 2nd year etc) Group Clubs user is member of Any tags user assigns to himself (e.g. musician)

Plus user should check the option receive SMS. However, user cant edit phone directly because well have to confirm it. So instead of giving him the field in the profile editing form, wed rather give him a button or a link which will bring him a from where he puts new phone number and password. After that a dynamic password is sent to his phone via SMS and he enters this dynamic password and phone is updated. Finally, user may register. When registering, he enters nearly the same data as when editing profile, but there is a dynamic password sent to him in order to confirm the phone number. All these screens are shown below.

User area screens

Group Administrator perspective

Group administrator role may be assigned to the clubs leader, to the group monitor (or its better to say headman? What sound more English), to the tutor or headmaster. Basically everyone who needs to send notifications will have this role.

So, this type of users can do the same as the simple user plus searching users, sending email notifications and viewing statistics. Each group administrator will be limited to the groups he may view/notify. For example, headmaster can notify anyone. Tutor may notify all groups of students he tutors in. Group monitor may notify all students within his/her group. Listing users and searching through them is done in the same screen. In the main part of the screen there is a list of users that are in the groups available to the group administrator. In the left side there is a narrow search panel which lists all filters that can be applied to the current set of users. Clicking the filter option (e.g. Geeks Club) lists all users that fall into the current filter conditions. And it also refreshes the filtering options. For example, if there is no girls in the Geeks Club then there is no point to show these option in the filter. This is harder to code, but it will bring excellent user experience. In the right hand side there will be the saved searches panel. When you applied some searching criteria, you may save it with some label so you can quickly access this search in the future. Were going to create standard searches in addition to filtering to simplify the systems usage. This works as following. For example, you can view all Computer Faculty. But you need only girls from the Geeks Club. So you filter by gender and then by club. And save this search as Girls-geeks This immediately appears in the right saved searches panel. These saved searched may be group-specific and user-specific. This basically means that when group admin saves search, he may select if he wants it to be private or he wants to share this search with other group administrators, who have access to the same groups as he does. We think, this will help users creating the searches that they really need. Sure, saved searched may be easily removed. In the right side there will be also a Send notification panel. It will contain only textarea field and a send button. When you have your group ready, you type the message an click send. It asks for confirmation, displaying how much it would cost and sends it over. Another page in the Group administrators perspective is statistics. Here hell see how much messages he sent during the last day/week/month/overall and how much did it cost. As we progress with development, we may add some settings, that will be the third page then. Heres the filtering screen:

Filter users screen Statistics screen is pretty straightforward, so well omit it here.

Administrators perspective
Administrator is almost god here He can manage users, assign rights to the group administrators, set limits of SMS count, view logs and overall statistics. Users management screen will be nearly the same as filtering, with the only difference that when clicking the row with users youll see the profile screen with additional options:

ban/unban delete phone editing does not require confirmation administrator of (group selection) notifications limit

Logs and statistics screens are quite simple too.

Use cases
After analyzing the above overview, we come up with the following use case diagram. It is pretty self-explanatory and written after the description above, so it is useful only as a summary.

SMS Notification Use Cases Following the iterative development methodology, we should describe all usecases now, but I find this quite useless. After describing all usecases briefly, we should select 10% critical usecases and describe them in full. Full description includes the sequence of actions taken in the main success scenario and all alternative scenarios that may happen (e.g. DB error, connection failure, no users found etc). This is useful sometimes, but I think that for such simple application as this one, we ma skip this step either.

What is really useful about the iterative development at this stage is that it recommends picking 10% of the most critical usecases and start implementing them in full. By critical I usually mean those which may result in essential DB structure or application design changes. In our case there are 14 usecases.10% is 1.4 usecase. Lets pick only one. The most critical usecase, that affects all the application design and DB structure is the user filtering. The success of an application depend on the stability and usability of this feature. So we should code it efficiently and then move to the other usecases. I like this approach cause it is much more practical than designing the system from the interface. Changing interfaces and adopting them to core is much more simple and has less risk than doing vice versa. So we decided to start with user filtering. The first thing we should create is the database structure. This will be covered in the tomorrows post. Id like to learn your opinion on all that. Maybe you can propose some better interface, or some nice filtering approach or just some idea for this. Were open to all suggestions and comments! Thank you for reading my blog and following this project Subscribe to RSS and stay tuned!