Systems, Process & Data Modeling - Research Paper Example

? Systems, Process and Data Modeling Submitted to, Submitted By, of the Submitted on, [February 16th, 14.  Discuss use-case modeling, how is it performed, what and why is it used? Explain each clearly.  The last two decades of the twentieth century proved to be the advent of the Unified Modeling Language. The UML can be narrated as “a language for specifying, visualizing and constructing the artifacts of software systems, as well as for business modeling.” (UML Document Set, 2001). On lighter note, the UML is a graphical means of depicting the design models with respect to specific environments. Use Case Modeling is a subset of Unified Modeling Language. It can be narrated as a method whereby the requirements of the stakeholders can be incorporated into the system’s design. The functional requirements of an existing or proposed system are described in detail via use case modeling techniques. The process modeling is done in the early stages of system development. User input can be altered at every stage of development in a use case that is developed as a result of the execution of the modeling technique. The subsequent development stages are all based upon the use cases that are generated in the initiation. The components of a use case model are mainly actors and use cases. An Actor is any external interaction with the system. It may be a person or an entity that exchanges data with the system. An actor may also be a user of the system though all users are not necessarily actors. A use case is a series of steps that gets initiated when an actor interacts with the system under consideration. The goal that is achieved by use case modeling is the creation of a conceptual system regarding the observable behavior of the concerned system. This conceptual model is basically aimed at representing the real world scenario within the information system. The model also supports communication between the users and the developers of the system, enables better analytical understanding of the system and proves to be a point of initiation for the designers of the system. (Wand and Weber, 2002) PERFORMING USE CASE MODELING In a use case model a use case is represented by an ellipse while the actors interacting with it are symbolized using a stickman symbol. The notations being used for use case modeling are illustrated in the table below: Table 1: Showing grammatical constructs for Use Case Diagram Using the notations mentioned in Table 1 above a use case model can be easily assembled. How it is developed is demonstrated by taking the example of “Registration in a University.” The points to be considered when registering in a university course may be stated as follows: Are there any pre requisite courses for the course being selected for studying? Have the pre requisite courses been completed by the student attempting the course? Is the student a fee defaulter? Has the student registered in the maximum number of courses that can be registered in a month? The use cases that deal with these queries, resolve them and proceed towards the completion of the use case model are stated as follows: Class Registration Registration for Special Classes Prereq Courses not completed Student Billing Student Record These use cases are depicted as ellipses with their respective names stated underneath them. The actors interacting with this specific se case model are the Student, The registration personnel, the instructor and the Bursar’s Office. These actors are depicted by the symbol of a man. Any one of the actors initiates its respective use case. For example, the class registration use case can be initiated by the student or the registration clerk. The use case would first connect with the ‘pre requisite course not completed’ use case and check whether there are any pre requisite courses that need to be completed before the ‘to-be registered course’ or not. If the response is yes then the student’s record requires to be checked whether he has completed the pre requisite course or not. The ‘student record’ use case is then initiated by the system to verify the students’ completed courses. Every single use case is a depiction of a complete functionality with respect to the system. The figure 2 demonstrates the use-case diagram for a university registration system. USE OF USE CASE MODELING Use case modelingclearly signifies the basic flow of information within a system. It chalks out eat separate process and signifies which actors initiates which process. Thus the specific significance and inheritance relationships of inter process relationships can also be clearly witnesse in a well built use case model that is graphically illustrated. 15. Explain the concepts of data modeling. Discuss the concepts of data models and how they interrelate? Introduction: A model depicts reality. The main purpose of a model is to put forth real world processes and systems for research and study. Modeling can be used for both i.e. to study existing systems or to propose new systems. The business systems are greatly benefitted with systems modeling. Generally the business structure, functioning, processes, data flows and organizations are modeled under technical or non-technical perspectives. The logical models depict the system characteristics without highlighting the technical details of implementation. These models are often referred to as conceptual models. Without any implementation details these models are so generalized that they simply are independent of any constraint related to their physical implementation. On the other hand the physical models cover both, the ‘what’ and ‘how’ factors. They not only signify the functioning of a system but also highlight that how the system may or would implement physically. These two types of models are basically used to discriminate the business and technical aspects of a business system. Systems analysts use logical models to depict the business side of a system whereas the physical models are used to address the technical and implementation issues. The logical models are mainly used for the following reasons, There are extremely low chances of missing business requirements with logical models as they mainly focus business rationale. Clear, concise and easy to communicate non-technical nature of these models generates common sense based description of systems. Extremely easy to improve or modify. Once the system is represented through logical model, it invokes creativity as well. Data Models: Data oriented logical models are called Data Models. Sometimes referred to as database models these are mainly used to represent the organization and storage structure of business data. Keeping in mind the natural characteristics of data, relationships of system entities and prospective business queries, these models are perfect for business data documentation. The eventual form of a data model is known as Entity Relationship Diagram (ERD) or Entity Relationship Model. A simple entity relationship diagram is represented in figure 1.0. Figure 1.0. An Entity Relationship Model Basic Concepts of a Data Model: The basic concepts that constitute almost every type of data model are signified through particular terminologies. Following text contain some explanation of the conceptual terminologies that are needed to have better understanding of data models. Entity Generally everything around is data. The data is always specified or grouped in relation with some perspective, thought, thing, or a process, like data of a business organization or data related to a person etc. An entity is that something around which the data is centered. The data related to an entity can further be categorized in to attributes. So an entity is sometimes also defined as a collective representation of related attributes. Attribute Attributes can be defined as the specifications of the respective characteristics of an entity OR the qualifiers of data related to an entity. For example people (entity) can have names, dates of births and social security numbers etc. Attributes are sometimes referred to as fields. The actual notion of field is however described through ‘related data values listed under an attribute in columnar manner’. Data Type and Data Domain An attribute can have a single data type like text, number etc. whereas domain of data sets the legitimate limits of data entry. For example a logical data type can have yes/no, true/false and 0/1 or a value set data type like ‘payment mode’ can have values from a static domain like {cash, bank draft, credit card, online payment} etc. Record and Table A record is also referred to as an entity instance. Each row in a multi-attribute columnar arrangement represents a record. Collection of related records is known as a Table. The Table is an actual implementation of an Entity. Key A key is a field or attribute that represents a respective record uniquely. For example students’ registration number or National ID etc. A key can be composed of multiple attributes hence known as composite key. There may be multiple fields capable of representing records uniquely like social security number and employee ID both can be the keys. The key that is selected to represent records is known as Primary Key. Relationship There can be multiple entities related to a business scenario like employee, department, customers and sales_items etc. The bindings between entities are generally natural. A data model (or a database model) is always composed of related entities. A manufacturing and marketing company cannot have entities like students or Teaching_Faculty. There are three main types of relationships that are one – one, one – many and many – many relationships. Table 1.0 some examples of each type. Table 1.0. Types or relationships with respective examples One - one A department has only one departmental head. One - many A department may have multiple employees. Many - many A patient may see multiple doctors and vice versa Generally a many – many relationship is resolved into two one – many relationships for implementation. The possibility of maximum and minimum number of instances on both sides of a relationship is termed as cardinality. For example it is necessary to have at least one course to be studied by a student, whereas a course can be offered without having any student. One student may opt for many courses and one course can be selected by many students etc. The relationship is many – many but the cardinality values for course are 1 or more and for students it should be zero or more. Normalization It is purely a database designing process but very effective for figuring out the entities and their relationships. There are actually five stages of normalization but usually a good ER model can be obtained applying 3 stages commonly known as third normal form or 3NF. The main theme is to collect all the data as a tabular flat file. The next stage is to figure out maximum columnar attributes. To curb redundancy the flat file is further split into maximum possible entities. At 3rd stage the relationships are established by enforcing referential integrity constraints. 16. Explain a decomposition diagram and what it is used for. How can a decomposition diagram be used in the logical process formulation?  Introduction: A process can be defined as something under execution. It is an active entity that holds a dynamic environment. A dynamic environment always exhibits transition of states. A process being active entity requests, uses and releases resources throughout. Big processes are also referred to as systems. A system can be a combination of subsystems that work in harmony to achieve a certain objective. Big processes or Systems can always be decomposed in subsystems. A multilevel decomposition of a system may be hierarchical. This means that system can be broken down into its sub components (or sub systems) which can further be decomposed to diminish the levels of abstraction as per need. The decomposition of processes or systems gives a detailed view of the internal functioning of that system. Despite being a very easy and common procedure the decomposition is done in a process oriented manner. The system must be viewed in terms of logical sub processes. Decomposition Diagram: The diagrammatic representation of hierarchical process decomposition in terms of functions, Activities and Tasks is known as Decomposition Diagram. A decomposition diagram is also known as Top – Down Functional Decomposition Chart. It is proved to be a great tool for planning and formulating logical process models like Data Flow Diagrams. The hierarchical organization imposes certain constraints on decomposition diagrams that are, Must hold parent – child relationship at each level of decomposition. A parent cannot have just one child. Must have at least two children if it is not a terminal level process or node. The diagram must be a tree not a graph i.e. a child must have only one parent. (In rare cases multiple upper level connection are however allowed. Not in general practice). Like trees the connection or edges don’t show any directions as the decomposition diagrams are meant for highlighting the process placements in a hierarchical structure only (not the process flow). The edges or connections signify a ‘consists of ‘relationship. This means that each parent represents an aggregate effect of it sub-tree or child processes. Logical Process versus Physical Process: The notion of logical process definitely violates the general definition of process as far as the activity and allocation of resources is considered. However the processes may also be viewed logically as an abstract combination of multiple physical/implemented processes. Logical processes just highlight the core functioning without any implementation details. Logical Process Formulation through Decomposition Diagram: Logical processes can be decomposed into functions, events and elementary processes. There can be multiple terminologies or alternate naming conventions but the conventions used in this text are quite meaningful. Following text indicates the meanings and usage of each level of decomposition. Function A function stands for a comprehensive or big process with virtually no ends or terminals in terms of execution. Composed of several activities ongoing either sequentially or parallel it highlights a sense of continuity of execution. For example in a manufacturing business scenario, quality control, scheduling and planning would be considered as functions. Event: During the performance of a function several limited events may be triggered. An event is a well-defined complete process that is invoked through an input and produces respective output. For example a production management function may comprise of events like raw material purchases, assembly line setup and resource allocation etc. Events elaborate the meanings of respective functions. The usage of events in systems analysis is a must. Almost all business functions are decomposed into events (logical sub processes). This decomposition assists in identification and placement of a process in a decomposition diagram. Elementary Process: These are the lowest level logical processes with clear and strong verbal names. For example the event ‘Purchase Raw Material’ can be decomposed into elementary processes like evaluate material prices, figure out stable suppliers, determine required quantity and clear previous supplier dues etc. Conclusion: The decomposition diagram is an effective tool for formulation, identification and placements of logical processes. It not only provides the basis of preparation of data flow models but also highlights the dependencies of respective processes. However the main disadvantage of decomposition diagram is , that it does not highlight the internal functioning of a process. Flowcharts seem appropriate for the purpose of showing the inside functioning but they are discouraged because they don’t paint the overall picture of the system. Context Data Flow Diagrams (improvised DFDs) serve the purpose better. Further decomposition of elementary processes doesn’t prove to be effective as it violates the element of logical abstraction. Often contain trivial processes like file transfer from one person to another further decomposition is more inclined towards physical implementation details. REFERENCES: Hoffer, J. A., George, J. F., & Valacich, J. S. (2011).Modern systems analysis and design. Upper Saddle River, N.J: Pearson Prentice Hall. Whitten, J. L., Bentley, L. D., & Dittman, K. C. (2007).Systems analysis and design methods. Boston, Mass: McGraw-Hill. http://www.omg.org/news/meetings/workshops/presentations/embedded-rt2002/02-1_Kobryn_UML_Tutorial.pdf UML Document Set (June 25, 2001), Retrieved from http://www.omg.org/. Gemino, A., & Parker, D. (2009). Use case diagrams in support of use case modeling: deriving understanding from the picture. Journal of Database Management, 20(1), 1+. Retrieved from http://go.galegroup.com.proxy1.ncu.edu/ps/i.do?id=GALE%7CA193886943&v=2.1&u=pres1571&it=r&p=AONE&sw=w Wand, Y., and R. Weber (2002) "Research Commentary: Information Systems and Conceptual Modeling -- A Research Agenda," Information Systems Research (33)4, pp 363-376. Wand, Y. & Weber, R. (2002). Information systems and conceptual modeling: A research agenda. Information Systems Research, 203-223. Read More