The Strategy of Valentinos - Report Example

Modelling Enterprise Architectures Overview This assignment is based on the case study of Valentinos, it is a renowned and successful “Personal Introduction Agency”. It has been operating its business since 1976. It has been observed from the case that there have been more than eight million single men and women at present in the United Kingdom falling under the age group of 18 and 64 which postulates significant opportunity for Valentinos to succeed at the marketplace. Over the years, it has been very successful and has made considerable investment in the internet. It is perceived that quality and integrity are essential for it to sustain its success at the marketplace. Notably, Valentinos has been able to ensure superior quality services to its clients by preserving their privacy and confidentiality. Nonetheless, it is considerably worried about the present market share and the profitability in the current scenario. Correspondingly, this assignment intends to identify various issues and advice Valentinos on its strategy that would ultimately lead towards efficient use of technology. Activity Diagram Activity diagrams are basically used for the purpose of ‘business process modelling’. It signifies the business and operational workflows of the elements of a specific system. It demonstrates the general flow of control of an IT system. In numerous ways, activity diagrams are object based correspondent of flow chart. A common usage of activity diagram is that it would permit to describe basic along with substitute courses of action. These courses of action can facilitate to understand the underlying factors that might emerge in each phase of the activity. Correspondingly, relevant strategic measures can be taken to ascertain appropriate path of action to attain the desired objectives (Patil & Mahajan, 2014; Bennet et al. 2010). Figure 1 demonstrates the activity diagram for the use of recommender system in Valentinos. Initialisation of Recommender System The initialisation activities are done every time when the system starts the recommender function and the users log into the system. Initially, the recommender engine gets started and afterwards the users’ profile and program specifications are initialised. The recommender service for Valentinos will be started by initialisation request. Afterwards, it would ask the user for any personalisation. Upon successful personalisation, it would initialise the user profile and other programs. Fig 1: Activity Diagram for Recommender Service Initialisation User Recommendations User recommendation computation activity calculates the recommendation value for the given program segment. The recommendations for partner are initiated by authenticating the user. Upon request by the user to use the recommender application, the procedure redirects the recommender platform. After authenticating the user, querying to retrieve the personal information with the details takes place in the recommender environment. The users’ data is then returned to the requested links. Completion of the recommender procedure is information transformation which hopefully distributed for collaborative filtering in order to deliver the users with appropriate recommendations regarding partners. This procedure facilitates to retrieve appropriate user information as and when required. Moreover, authentication of the system can enable to locate any mismatch in the user id and the present login activity of the intended user (Fijałkowski & Zatoka, 2011). Figure 2 demonstrates the functions of recommender system in Valentinos. Fig 2: Functions of Recommender System in Valentinos Prototypes Presented as a Storyboard The primarily goal of producing prototypes on the recommendation system is to provide decision support for the users and help them in their choice of finding best matches. Correspondingly, standard on-line recommender system has been imitated that will serve the users by recommending them the most preferred matches. It can be stated that successful relationships can be build when both the parties are interested in each other. The following prototypes are generally based upon content-based system which emphasise on using both user profile as well as interactions in order to produce appropriate recommendations. In order to produce the recommendations for the particular user, the implicit and explicit preferences of users are extracted which are than matched with the profile of other users. In the below represented prototype, the prototype 1, 2 and 3 are based on the implicit preferences of users which involve producing recommendations based on the information extracted from user’s profile and interactions while prototype 4 is based on explicit preferences of users that involves producing recommendations based on the preferences provided by users (Pizzato et al., 2012). The prototype requests users to create a profile that specifies a wide range of personal characteristics, using predefined data field such as relationships, ethnicity, height, faith, smoking and drinking habit as illustrated in the prototype 2. Users are also requested to provide information about their likes and preferences as illustrated in prototype 3 using their own words. These kinds of information may reveal the characteristics of the person they are looking for and want to have a relationship with. The website will allow the users to exchange messages as illustrated in prototype 3 and 4. The user receiving messages will decide to reply or not to reply. The reply may positive indicating that the user is interested or it may negative signifying that message receiver does not wish to receive further messages or conversation. In the case where the receiver of the message is interested exchanges of unconstrained messages may take place which may later lead to an offline relationship. Prototype 1 HOME Profile Log Activity Recommendations Find Matches Profile About Photos HOME Prototype 2 Home My Profile Recommendation My Matches Contact My Profile Relationship: Ethnicity: Body Type: Height: Faith: Smoke: Drink: Recommendation My Matches My Matches Contact Prototype 3 Home Profile Matchmaking Dating Advice Chat Home Profile Home Matchmaking Home Dating Advice Chat Dating Advice Chat Prototype 4 Welcome You are: You are looking for: You were born on: Email-Address: Click to Continue Profile My profile My Partner preferences My Photos My Matches Messages My partner preferences My Matches My Matches Messages Sequence Diagram Sequence diagram is used in order to discover the rationality of complex operation, function and procedure. Sequence diagram enables to document and validate the logic and is commonly used for designing and analysing the recommender system for Valentinos. Sequence diagrams are regarded as the most popular work-of-art for dynamic sculpting which concentrates on identifying the activities within a system. There are four sequence diagrams which capture the movement of logic in the recommender system. Every modelling flow is dependent on the probable rational choices which can be made by the user (Sambolec et al 2011). The following figure models the flow of logic where the user chooses to search for recommendations. Fig 3: Flow of Logic in Delivering Recommendations In the above sequence diagram, user first logs in to the system. After logging successfully, they will request for recommendations. In order to recommend for suitable partners, the recommender system would ask for data. After gathering the data, the system would validate it. Besides, recommendations would only be provided to the proper users. Thus, the validity of the users will be evaluated. After completion of validation, the data will be retrieved and recommendations for a given query will be provided (Mahmudur, 2011). The recommender system would also acquire the user profile information. From this viewpoint, when a user enters to the system for the first time, it will provide basic information according to the choice. Figure 4 shows the sequence diagram for acquisition of user profile. Fig 4: Acquisition of User Profile In the above sequence diagram, user profile is stored in the user database. Initially, they will view different options and accordingly provide information on the basis of different factors. On defining the different parameters, the system will pass the information. While requesting for recommendation, the system would confirm the user and accordingly develop the content for representation. The user profile representation necessitates the preparation of background profile. Infrastructure for user profile background is middleware system which addresses issues common to every kind of software that uses recommender architecture (Sessions, 2010). Figure 5 demonstrates how the proposed architecture of recommender system generates the user background profile by using profile learning. Fig 5: Generation of User Background On the basis of this profile, a user profile is described as a set of background mapping which associates user rating to a group of backgrounds. The user background constructed in the algorithm permits the positioning of every user profile in each context by a specific score. These scores are used in order to make contextual recommendations (Mahmudur, 2011). There are several approaches that can be used in order to generate recommendations. However, in Valentinos, collaborative filtering system has been used. Collaborative filtering is a memory oriented approach to recommendations. It signifies every user as a course of rating. In this algorithm, similarity metrics is used in order to generate active users’ region, consisting of most similar users to the active users and then it recommends those profiles to the requested active users that have been highly rated by the neighbours (Mahmudur, 2011). Fig 6 represents the sequence diagram for preparation of recommendations list. Fig 6: Preparation of Recommendations List State-Chart Diagram for Valentinos The class diagram is considered as a static diagram. It illustrates the static view of an application. Class diagrams are useful for visualizing, describing as well as documenting the different features of system. Besides, it is also useful in constructing executable codes of the software application. It is crucial that the name of the class diagram is meaningful to explain the various aspects of the system. Correspondingly, the class diagram for Valentinos is illustrated below. Fig 7: Class Diagram for the Recommender System On the other hand, state-chart diagram primarily describes the state of machine. It explains the different states of objects in a system. Notably, states are specific to an object or a component of a system. The diagram describes the flow of control from one state to another state. States can be defined as the situation wherein object exists and it changes as a result when some event is occurred. It is crucial while drawing the state-chart diagram to clearly identify the objects to be analysed, states as well as event. Correspondingly, based on the above presented class diagram, user class has been selected from which the state-chart diagram will be drawn. The below represented state-chart diagram describes the states of different objects during its entire life cycle. Correspondingly, emphasise is placed on both the states changes based upon certain internal and external events. In the following state-chart diagram, the first state is user from where the process begins. The next states are arrived for events like providing information. Notably, these events are accountable for changes in the states of match making. Accordingly, the information that are provided by the users including their preferences, index and are collected by the matchmaker who confirmed that the information provided by the user is real and valid. Based on this information, matchmakers make matches identifying the similarities amid the two users. Subsequently, an ideal match is recommended to the user in the form of find match and ultimately the final state is arrived and engaged in unconstrained exchange of messages. Fig 8: State-Chart Diagram for Valentinos Index Preference Initial State Similarities Final State Entity Relationship Diagram (ERD) for Valentinos ERDs are considered as a key data modelling tool that enables to organize data into entities and subsequently define the relationships amid the entities. ERD process facilitates in producing reliable database structure which assists in efficient data storage and retrieval. ERD generally comprises four different components that include entity, relationship, cardinality and attribute. A data entity is considered to be anything real, in the concerning case user along with characteristics are the entity. Conversely, data attribute is the characteristics of the entity. In the below represented ERD, user name, user address, user gender, user e-mail, height, body-type marital status, faith and ethnicity are the attributes. The relationships between the entities are in the below illustrated ERD are represented by horizontal bar. Fig 9: Entity Relationship Diagram (ERD) for Valentinos Java Code Java code will be used in order to develop a dynamic webpage. Java code can put dynamic manuscript into a webpage which can effectively respond to users’ requests and also can read or write HTML components. The Java code files will be conformed into four distinct files for better transparency and development supervision namely server, data manager, services and algorithm. The first file is server file which would contain the main method of Java and act as the key executable part of the system. The other Java files are understood as plug-ins from which only one file is required to successfully start the server of recommender system. Server As described above, the Java main method is located in class server and it conducts the following activities: Preparation of logging: The server of recommender system will be logged into distinct log file with exclusive timestamp. Preparation of configuration: Server file will open the configuration property file on the basis of server’s command line. Preparation of data manager: Server file also creates actual data manager instances on the basis of current structure and initialises them accordingly. Data Manager The server comprises international data manager which is believed to apply data manger boundary. The objective of this data manager is to provide access to the collaborative filtering to every element in the recommender system. The data being delivered along with the list of active users are recognised by the user ID. The data manager represents key information storage access point for every other element in the recommender system. The Java code for data manager is described below: Source: (Brozovsky, 2006) Services Service is an isolated server element exposed to the users’ side of the recommender system. This file includes server logical Java code over the information delivered by the data manager. Every service of the recommender system is obliged to implement the service interface so that it also extends the configurable interface. The service interface represents the facilities of Valentinos and forms a portion of recommender system which is exposed to the outside world. The typical java code for services is as follows: Source: (Brozovsky, 2006) Algorithm Every collaborative filtering algorithm implementation requires an understanding of the algorithm interface. A majority of implementations have certain common characteristics. The algorithm file assumes that every estimate and recommendation is based on rating provided by the users on certain attributes and that every such estimate is independent on other predictions. There are several methods which can be used for recommendation system for Valentinos such as mean algorithm, random algorithm and nearest neighbours’ algorithm among others (Brozovsky, 2006). With respect to the sequence diagram described above, three database tables will be used in order to develop the recommender system for Valentinos. The first table is ‘user type’ table. Name Data type User ID Integer User type Yes/No The ‘user type’ table will have two attributes in order to store information regarding users. The first attribute is user ID which recognises the user and the second attribute is user type which recognises if the user is system administrator or regular user. The second table is ‘user login’ table which stores information about the users who are registered. Each time a new user is registered, the information is updated in this table. The table has five attributes where one attribute is related with the first table. Name Data type User name Text First name Text Last name Text Password Text User ID Integer The third table is ‘preferences table’ which defines the items as preferred by registered user. For instance, it would provide information regarding the type of relationship, physique, psychological attributes and rating attributes. It is the key table in the entire recommender system. The respective rank of every preference is stored in this table. Every basic preference is defied by certain background parameters and the level of interest. More particularly, the preferences will be divided into basic preferences regarding single background parameter and aggregate preferences concerning a blend of background parameters. Every aggregate preference would be derived from basic preferences. The individual rank of the attributes is accessed and used while sorting the outcome of recommendation purposes. This table is related with user ID while demonstrating the characteristics and preferences of the users. Name Data type Type of Relationship Text Physique Text Psychological Attributes Text Rating Integer User ID Integer A table will also be maintained regarding every dating made in Valentines. It would store the user’s ID who has made contact with other users, the date of making contact and the feedback. This table is updated every time a date has been made. Zachman Framework Process blueprints are considered as an important to document, analyse as well as sustain organisational change. Process blueprints are created based on the specific goals and on modeller’s perspective. It is vital that process blueprints are able to address the interests and needs of the stakeholders. Zachman Framework has been applied in the case of Valentinos in order identify the logical structure for classifying and organizing the descriptive representations of Valentinos that are imperative for the management of Valentinos as well as for the development of Valentino’s system. In this regard, grid model involving six fundamental questions comprising What, How, Where, Who, When and Why are framed for stakeholder groups involving planner, owner, designer, builder and subcontractor in order to provide a holistic view of Valentinos that is being modelled. The aim of this framework is to provide senior business managers and IT professionals of Valentinos to derive insight implications of key business and IT strategies that need to be established for successful operation of Valentinos. This framework is being applied as it is a simple and logical model rather than technical. Correspondingly, the row 1 which depicts the scope deals with the functionality of the system. The row 2 consisting of business model reveals the entire business entities, and processes and identifies how they interact. The row 3 shows the data elements and software operations that illustrate the business model. Similarly, row 4 reflects the technology, tools and materials that may impose constrains. The row 5 represents the components that can be assigned to contractors for implementing. The row 6 reveals the operational system. It is determined that there are certain key activities such as having a profound knowledge base about the database would be a key factor in the system. Moreover, the new system would act as a key motivational factor to address the varying needs of different customer domains. It is anticipated that information system functional and non-functional factors would be a key determinant to garb customer attention towards the new system. The conceptual model of the dating delivery service can play a decisive part in ensuring customer preference towards the website of Valentinos (Sousa et al., 2011; Raynard, 2008).   Data (What) Function (How) Network (Where) People (Who) Time (When) Motivation (Why) Objectives / Scope To enhance the recommendations of matching partner Providing dating services Identification and description of registered users in the UK Operational units, customer service units, financial units and marketing units New year, Valentine’s day, Christmas day and winter vacation Provide customers with proper matching solution with affordable price Business Model Semantic explanation of business procedures Conceptual model of dating service delivery Construction and interrelationship of users and system administrators Information system workflow Classification and timeline of services Personal benefits and quality services Model of the Information System Logical information model for user data Software architecture with functions and visions Connectivity architecture Information system interface architecture Various events Information system functional and non-functional requirements Technology Model Physical information model for user data Information system design, language and system description Comprehensive network architecture Information system interface architecture User information control architecture Information system operational requirements Detailed Representations Users databases Database management, filtering, finding similarities and recommendations Physical information network components, user addresses and other communication etiquettes Information system security architecture and business operational architecture Information system content, timing of services and description of facilities Technological requirements   (Working systems) Functioning Enterprise Database and knowledge base Collaborative filtering and comparison of user profiles Communication architecture Information system users description Matching schedules for dating Technical and functional requirements References Bennet, S., Farmer, R., and Mcrobb, S. (2010). Object-oriented systems analysis and design. India: McGraw Hill. Brozovsky, L. (2006). Recommender system for a dating service. Retrieved from http://www.occamslab.com/petricek/teaching/mt-onlinedating/colfi.pdf Fijałkowski, D., & Zatoka, R. (2011). An architecture of a web recommender system using social network user profiles for e-commerce. Proceedings of the Federated Conference on Computer Science and Information Systems, 287-290. Mahmudur, R. M. (2011). Contextual recommendation system. Retrieved from https://www.politesi.polimi.it/bitstream/10589/22905/1/2011_07_Rahman.pdf Pizzato, L., Rej, T., Akehurst, J., Koprinska, I., Yacef, K., & Kay, J. (2012). Recommending people to people: The nature of reciprocal recommenders with a case study in online dating. User Modeling and User-Adapted Interaction manuscript No. 1-40. Patil, S., & Mahajan, A. (2014). Design and architecture for web graph mining base recommender system for query, image and social network using query suggestion algorithm and heat diffusion method. International Journal of Advanced Research in Computer Science and Software Engineering, 4(1), 38-47. Raynard, B. (2008). TOGAF the Open Group Architecture Framework 100 Success Secrets. United States: Lulu.com. Sambolec, I., Rukavina, I., & Podobnik, V. (2011). RecoMMobile: A spatiotemporal recommender system for mobile users. Proceedings of the 19th International Conference on Software, 1-6. Sessions, R. (2010). Simple architectures for complex enterprises. United States: Microsoft Press. Sousa, P., Pereira, C., Vendeirinho, R., Caetano, A., & Tribolet, J. (2011). Applying the Zachman Framework Dimensions to Support Business Process Modeling. Technical University of Lisbon, 359-366. Read More