This description provides different roles for each user in the network and distributes roles according to the concept of the
system
64
Figure 6.2 OV-1c Operational performance attributes
Second operational view is OV-2, the node relationship description. It shows the relationship between user and different systems. It describes each profile based on user roles which are communicating with these services inside the system. Essentially it shows the information that is build up for the system without including the security measures. For example, Figures 6.3, 6.4 and 6.5 are explaining information and the communication exchange between student, teacher and the administration, OV-2.1, OV-2.2, OV-2.3, respectively. Those figures have the student information, common applications, collaborated with teachers and the administration. Therefore, this is an example of showing how to build OV-2 in figures. Each figure represents centrally students, teachers and administration, respectively. Moreover, roles are defined to communicate with other roles and the information resources based on the user profile.
Figure 6.3 OV-2.1 Students centric operational node relationship Environment
System requirements User requirements
Student Profile
Administration Profile
Teacher Profile 1
2
4 3
Student Information Database
Other Common Applications Administration
Profile
65
Figure 6.4 OV-2.2 Teachers centric operational node relationship
Figure 6.5 OV-2.3 Administrations centric operational node relationship
Administration profile is higher in the hierarchy then teachers and the students. Users in administration role have communication with all services. Therefore they are representing the high level node in the system. Teacher profile is higher than the student profile so they are representing the medium level node in the system. And the last lowest node is the student profile in the system. Because of this sequence, information exchange is depending on the level ranking. Next Figure 6.6 shows consisted information and information exchange. First one shows shared database of student information. For example student blackboards, where all students have share a common system for grading, time tables, course descriptions and other useful tools for the education. Second link shows the communication between other common applications. For instance, a share point named Adobe Connect software is used for conferencing. The third and the forth lines show the communication links between other roles, teachers and administration. Communication between student, teacher and administration
Student
66
profile is provided by sending and receiving voice, voice videos and emails. Overall, each role in the clouds represents one database in different sub-systems.
Figure 6.6 OV-2 Operational node relationship descriptions
OV-3 Operational information exchange is built up actually to support nodes to achieve a specific operational activity. When it comes down to OV-3, it is building practically on OV-2 to go further and define what kind of information is actually to be sent and received.
Essentially, it is describing the arrows in the OV-2 figures. Those arrows are containing the uploading and downloading of information from different sub-systems. In Figure 6.7, the information exchanged between different clouds is listed to exemplify the case.
Figure 6.7 OV-3 Operational information exchange
After describing the roles, relations between the clouds and exchanged information, it comes to describe the units. A unit is a group of students, teachers and administration that is
Shared database of student information system
Uploading and downloading documents, lecture notes, discussions, time tables and calenders
Student profiles, uploding lecture notes, grades, time tables and calenders 7
Meetings, live conference records, voice records, give permission to access webconferences
67
in charge of the organization. And this organization has a communication or an exchange link with the other organization that is the head of the organisation. Additionally, there is headquartering where all services are managed from another organization. This unit of headquarter is built up on top of the previous organization resources. That is the way of showing a hierarchy of the whole organization. As a result, OV-4 organizational relationship chart describes the organization hierarchy. This organization at large has different units in different locations. Therefore, OV-4 explains the need of communication between the organizations. This hierarchy is also built on rules but Figure 6.8 only shows different units connected with different organizations, and roles are all hidden under them.
Figure 6.8 OV-4 Organizational relationship chart
Figure 6.8 is an example to show how different organizations are connected to have communication channels and exchange of information. It is just to show the concentration of nodes and where they are standing in the hierarchy. This viewpoint could be constructed differently according to the customer needs. That determines the roles for each user to serve on different purposes in SSO environment with the given permissions. For example, logistics units might perform common applications like for reaching seminars, lecture rooms or booking rooms inside the buildings. And the commander is somebody who is in charge of the buildings or maintenance in the organization. Each node in the organization has different activities to perform. OV-5 Operational Activity Model tries to setup those nodes to be able to perform the activities. Student node is performing reading, writing, compiling and sharing information. It can also perform uploading, downloading of information. Those activities are