SE
SE
Step-1: First of all, execute the setup file of the software and a dialogue
box appears that asks for the installation directory where you want to install your software.
Step-2: After that, an end user license agreement dialogue appears which includes all the terms and conditions for the use of the software, the company rights, scope the software license, etc. By clicking on I Accept, the user accepts all these terms.
Step-3: Now, the installation of the software starts and all the necessary components and files start extracting to the installation directory specified by the user.
Step-4: After the completion of the installation process, a dialogue showing the validity of the product appears that tells the user about the usage period of the software and allows enables the user to buy complete license of the software.
Step-5: When all the installation procedures completed, the SmartDraw tool user interface dialogue box appears that looks like as given below:
The user can make a number of different visual diagrams using different templates available in the SmartDraw tool software like flowcharts, data flow diagrams, organization maps, project charts, etc. The SmartDraw tool enables one to represent its work related to business or any other project in an attractive and efficient way.
Practical-2
Aim:
Introduction to DFD (Data flow Diagram). Theory: A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design).On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process.A DFD provides no information about the timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored Objectives of DFD: Represents system dat in hierchial manner and with required level of detail. Depicts processes according to defined user requirements and system scope.
Symbols used in DFD: Data Flow Diagrams are composed of the four basic symbols shown below.
The External Entity symbol represents sources of data to the system or destinations of data from the system. The Data Flow symbol represents movement of data. The Data Store symbol represents data that is not moving (delayed data at rest). The Process symbol represents an activity that transforms or manipulates the data (combines, reorders, converts, etc.).
Any system can be represented at any level of detail by these four symbols.
External Entities
External entities determine the system boundary. They are external to the system being studied. They are often beyond the area of influence of the developer. These can represent another system or subsystem. These go on margins/edges of data flow diagram. External entities are named with appropriate name. Processes
Processes are work or actions performed on incoming data flows to produce outgoing data flows. These show data transformation or change. Data coming into a process must be "worked on" or transformed in some way. Thus, all processes must have inputs and outputs. In some (rare) cases, data inputs or outputs will only be shown at more detailed levels of the diagrams. Each process in always "running" and ready to accept data. Major functions of processes are computations and making decisions. Each process may have dramatically different timing: yearly, weekly, daily. Naming Processes Processes are named with one carefully chosen verb and an object of the verb. There is no subject. Name is not to include the word "process". Each process should represent one function or action. If there is an "and" in the name, you likely have more than one function (and process). For example, get invoice ,update customer and create Order Processes are numbered within the diagram as convenient. Levels of detail are shown by decimal notation
Data Flow
Data flow represents the input (or output) of data to (or from) a process ("data in motion"). Data flows only data, not control. Represent the minimum essential data the process needs. Using only the minimum essential data reduces the dependence between processes. Data flows must begin and/or end at a process.Data flows are always named. Name is not to include the word "data". Should be given unique names. Names should be some identifying noun. For example, order, payment, complaint. Data Stores
or Data Stores are repository for data that are temporarily or permanently recorded within the system. It is an "inventory" of data. These are common link between data and process models. Only processes may connect with data stores.There can be two or more systems that share a data store. This can occur in the case of one system updating the data store, while the other system only accesses the data. Data stores are named with an appropriate name, not to include the word "file", Names should consist of plural nouns describing the collection of data. Like customers, orders, and products. These may be duplicated. These are detailed in the data dictionary or with data description diagrams. Data Dictionary: Every DFD model of the system must be accomplished by a Data Dictionary. A Data Dictionary lists all data item appearing in the data model of a system. The data items listed include all data flows and the contents of all data stores appearing on all the DFDs in the DFD model of the system. Data Definition: Composite data item can be defined in terms of primitive data items using the following data definition operations: +: denotes composition of two data items, e.g. a + b represents data a and b.
[ ]: represents selection i.e. any one of the data items listed inside the square bracket can occur. ( ): the contents inside the bracket represent optional data which may or may not appear. { }: represents iterative data definition. =: represents equivalence. /*: anything appearing within /* and */ is considered as comment. Balancing DFDs: The data that flow into or out of the bubble must match the data flow at the next level of DFD. This is known as balancing a DFD.
Each process must have a minimum of one data flow going into it and one data flow leaving it. Each data store must have at least one data flow going into it and one data flow leaving it. A data flow out of a process should have some relevance to one or more of the data flows into a process. Data stored in a system must go through a process. Filing systems within an organisation cannot logically communicate with one another unless there is a process involved. All processes in DFD must be linked to either another process or a data store.
Levles of DFD: There are various levels inputs,processing and output. These levels are: of dfd which provides detailed
Level 0 (Context Diagram): A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one process node (process 0) that generalizes the function of the entire system in relationship to external entities.
Level 1 DFD: The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until you reach pseudocode.
An example first-level data flow diagram Level 2 DFD : It elaborates level1 DFD and displays the processes in a detailed form.
And we can have some more levels until we get a DFD which cant be decomposed more.
Numbering of Bubbles: It is necessary to number the different bubbles occurring in the DFD to uniquely identify all bubbles in the DFD. The bubble at the context level is usually assigned the number 0 to indicate that it is the level 0 DFD. Bubbles at level 1 are numbered as 0.1, 0.2, 0.3, etc. Commonly made Errors while constructing a DFD Model:
d21
Many beginners commit the mistake of drawing more than one bubble in the context diagram. Many beginners have external entities appearing at all levels of DFD. It is common over sight to have either too less or many bubbles in a DFD. Many beginners made different levels of DFD unbalanced.
Practical-3
Aim: Construct a DFD for RMS Calculator. RMS Calculator: A software system called RMS calculating software, reads three integral numbers from the user in the range between -1000 and +1000 and determines the root mean square (rms) of the three input numbers and then displays it.
To draw the level 1 DFD from a cursory analysis of the problem description, we can see that there are four basic functions that the system needs to perform- accept the input numbers and then display the result. After representing these four functions in the diagram, we observe that the calculation of the root mean square essentially consists of the function: o Calculate the squares of the input numbers, o Calculate the mean, and o Finally, calculate the root. This decomposition is shown in Level 2 DFD in diagram. DFDs for RMS Calculator: The DFDs for RMS Calculator includes context diagram (Level 0 DFD), Level 1 DFD and Level 2 DFD. Starting from the context diagram, the processes are decomposed into sub-functions providing more details to DFD model. The level 2 DFD describes the lower level details of the RMS calculator. The DFDs are given as follows:
Data Dictionary for DFDs of RMS Calculator: Data Items: integer {3} RMS: float
Valid Data: Data Items a, b, c: integer asq, bsq, csq: integer msq: integer.
Practical-4
Aim: Construct DFD for Student Record Management System.
Student Record Management System: Every semester, departments within the university schedule course offerings. These course offerings indicate the sections of each course that will be taught, and the days and their times, when the course will be taught. The maximum enrollment in each course section is also indicated to the register. Developing a proper managed SRMS for the academic institution becomes the essence to let the users like students, guardian, teachers and others to gain the information about the institution. Its objective is to: Provide a proper registration channel/system to the new students. Maintain all the accounts of the students in digital form from enrollment till the end of the study. Update the information that is essential to transmit to the users. Make the information available to the departments at their desk whenever required in just a click away.
STU
Level 1 DFD describes the student admission process to get lower level details. The admission process includes the details like admission criteria, branch allocation process and accounting information, etc. as given:
To elaborate the student record details, level 2 DFD can be constructed which gives all the details about admission criteria, means the admission of students under different categories like counselors, scholars, etc. A level 2 DFD for the system is given as below:
S_data
Data Dictionary for Student Record Management System: S_data, Ad_info: alphanumeric c, m, s: integer S_record: alphanumeric Ad_data: integer.
Practical-5
Aim: Create a DFD for the expression: (a+b)*(b/d). Expression Calculator:
Expression Calculator is a software system that is used to calculate the results from various user defined expressions that include operands like numeric data and operators like +, -. *, /, etc. An arithmetic expression, (a+b)*(b/d) can be solved using this type of calculator. First of all, a+b is calculated, then b/d and after this, the outputs from these two operations are fed to multiplier to produce final result. Input to the calculation process is a, b, d and output is based on the user that provides the input.
U
Level 1 DFD: Process 0 in context diagram is divided into three parts in case of level 1 DFD to describe the process in more detail as:
a.) Validate Data: It validates the three inputs given by the user and passes to process 0.2. b.) Compute Expression: It performs the various arithmetic operations on the user input and then pass the output to the process 0.3. c.) Display Result: It displays the computed result and the output is now visible to the user of the system.
Level 2 DFD: Process 0.2 in level 1 DFD is divided into sub processes while constructing level 2 DFD. It can be divided into 3 parts as: a.) Adder: Valid data a and b provided by the user is added and the result is passed to the multiplier storing in variable c. b.) Divisor: Division is performed between b and d and the result is stored in variable e, which then passed to the multiplier. c.) Multiplier: The data from the adder and divisor process is fed to the multiplier, that performs an arithmetic operation on it and the calculated product A is then passed to the Display Result process.
Data Item
d.) Display Result: The result A is passed to the user, who wants the calculation process to be occurred.
Data Dictionary for Expression Calculator: Data Items: {integer} Output: float Valid Data: integer
Practical-6
Aim:
Introduction to E-R diagrams
Theory
In 1976, Chen developed the Entity-Relationship (ER) model, a high-level data model that is useful in developing a conceptual design for a database. Creation of an ER diagram, which is one of the first steps in designing a database, helps the designer(s) to understand and to specify the desired components of the database and the relationships among those components. An ER model is a diagram containing entities or "items", relationships among them, and attributes of the entities and the relationships.
ER Notations:
Entity sets are drawn as rectangles, relationship sets as diamonds. If an entity set participates in a relationship set, they are connected with a line. Attributes are drawn as ovals and are connected with a line to exactly one entity or relationship set. Cardinality constraints are expressed as follows:
a double line indicates a participation constraint, totality or surjectivity: all entities in the entity set must participate in at least one relationship in the relationship set; an arrow from entity set to relationship set indicates a key constraint, i.e. injectivity: each entity of the entity set can participate in at most one relationship in the relationship set; a thick line indicates both, i.e. bijectivity: each entity in the entity set is involved in exactly one relationship. an underlined name of an attribute indicates that it is a key: two different entities or relationships with this attribute always have different values for this attribute.
Attributes are often omitted as they can clutter up a diagram; other diagram techniques often list entity attributes within the rectangles drawn for entity sets. Table showing ER notations:
Notation
Meaning
Entity type Attribute Key attribute Derived attribute Multivalued attribute Composite attribute Relationship type Total participation Many-to-one relationship Weak entity type with identifying relationship
Conceptual simplicity Visual representation Effective communication Integration with the relational database model
Limited constraint representation Limited relationship representation No representation of data manipulation Loss of information
Types of E-R diagrams: 1. one-to-one: one instance of an entity (A) is associated with one other instance of another entity.
2. one-to-many: one instance of an entity (A) is associated with zero, one or many instances of another entity (B), but for one instance of entity B there is only one instance of entity.
3. many-to-many: one instance of an entity (A) is associated with one, zero or many instances of another entity (B), and one instance of entity B is associated with one, zero or many instances of entity A.
Practical-7
Aim: Construction of ER-Diagram for Car Insurance Company whose customer own a one or two cars. Each car has associated with it, 0 to any number of accidents. a.) Identify entities, b.) Identify attributes, c.) Identify the relationship among different entities. Theory:
The ER-Diagram or Entity Relationship diagrams are used to represent the given system in the form of entities and the various relationships among them. The Car Insurance Company also has particular system for the insurance of the car having a specific owner. It has various entities associated with it, corresponding attributes and the relationships among the various entities. Entities associated with ER-diagram of Car Insurance Company: An entity is an object whose information is stored in database. It is different from other objects. In other words, anything that may have an independent existence and about which intended to collect data is known as Entity. In ER-diagram of car insurance company, there are three entities that are: Person Car Accident
U ser_ id
A ddre s
Attributes used in ER-diagram of Car Insurance Company: Attributes describe the properties of the entity of which they are associated. A particular instance of an attribute is the value it contains. In ER-diagram, there are 3 entities and every entity has 3 attributes, so there are total 9 attributes: i. ii. iii. User_id Address Name
PE S R O
Relationships among various entities: A relationship represents an association between two or more entities. In ER-diagram, there are 2 relationships among the entities used:
a) Owner: It represents the associations between the car and the person who owned it. b) Participation: It represents insurance of the car between person and the accident.
Practical-8
Aim:
Introduction to Structure Chart
Theory:
The aim of structured design is to transform the result of the structured analysis (ie; DFD) into structure chart. A structure chart reprersents the software architecture. The various modules making up the system. The module dependency are the parameteres that are passed among the different module. The structure chart representation can be easily implemented using some programing language. In a structure chart, the procedural aspects are not represented. In any structure chart, there should be one and only one module at the top, called the root. There shiould be atmost one control relationship between any two modules in the structure chart. The main reason behind this restriction is that we can consider the different modules in the structure chart to be arranged in layers or levels. The principle of abstraction doesnt allow lower level modules to be aware of the existence of the high-level modules. However, it is possible for two high level modules to invoke the same lowerlevel module. Structure design provides two strategies to give and guide transformation of a DFD into a structure chart.
Transform analysis:
It identifies the primary functional components (modules) and the high level input and output for these components. The first step in the transform analysis is to divide the DFD into three types of parts:*Input *Logical Processing *Output The input portion in the DFD includes processes that transform input data from physical to logical form. Each input portion is called a different branch. In the next step of transform analysis, the structure chart is derived by drawing one functional component for the central transform, and the different branches. These are drawn below a root module, which could invoke these modules. In the third step of transform analysis, the structure chart is refined by adding sub-functions required by each of the high-level functional components. This process of breaking functional components into sub-components is called factoring. The factoring process iscontinued untill all bubbles in the DFD are represented in the structure chart.
Transaction analysis:
Transaction analysis is an alternative to transform analysis and is useful while designing transaction processing programs. As in transform analysis, first of all data entering into the DFD are identified. In a transaction-driven system, different data items may pass through different computation paths through the DFD. This is in contrast to a transform centered system where each data item entering the FD goes through the same processing steps. Each different way in which input data is prcoessed in transaction. For each identified transaction, trace the input data to the output. All the transvered bubbles should be mapped to the same module on the structure chart, draw a root module and below this module draw each identifed transaction module. Every transaction carries a tag identified its type. Transaction analysis was this tag to divide the system in to transaction modules and the transaction-centre module.
Practical-9 (a)
Aim:
Conversion of DFD of RMS calculator to structure chart using Transform Analysis.
Theory:
By observing the level-I DFD of Practical 2 we can identify validate input as the different branch and write output as the efferent branch. The remaining (ie; compute- rms) as the Central Transform. By applying the steps explained below of Transform Analysis:Step 2: After identifying the different and efferent branches the structure chart is derived by drawing one functional component for central transform and the affewrent and effernt branches. These are drawn below a root module, which would invoke these modules. Step 3: The structure chart is refined by adding sub fucntions required by each of the high level functional components. Many levels of functional components may be added. This process of breaking functional components into subcomponents is called FACTORING.
Practical-9 (b)
Aim:
Conversion of DFD of ATM cash withdrawal to structure chart using Transaction Analysis.
Theory:
WITHDRAW CASH FROM ATM R.1 WITHDRAW CASH Description: the withdraw cash function first determines the type of account that number which the user wishes to withdraw cash. It checks the balance to determine whether the request amount is available in the account. If enough balance is available, it outputs the required cash, otherwise it generates an error massage. R.1.1 SELECT WITHDRAW AMOUNT OPTION
Input- withdraw amount option Output- User prompted to enter the account type. R.1.2 SELECT ACCOUNT TYPE Input- User option from any one of the following: Savings/ Checking/ Deposit Output- Prompt to Enter amount R.1.3 GET REQUIRED AMOUNT Input- Amount to be withdrawn in integer values greater than 100 and less than 100 and less than 10,000 in multiples of 100 Output- The requested cash and printed transaction statement. Processing- The amount is debited from the users account if sufficient balance is available otherwise an error message is displayed.
Practical-10
Aim:
Introduction to JSP (Jackson Structured Programming) and JSD (Jackson System Development).
Theory:
JSP (Jackson Structured Programming) was the first software development method that Michael Jackson developed. It is a program design method, and was described in his book Principles of Program Design. JSP covers the design of individual programs, but not systems. JSD (Jackson System Development) was the second software development method that Michael Jackson developed. John Cameron was a major contributor to the development of JSD. JSD is a system development method not just for individual programs, but for entire systems. JSD is most readily applicable to information systems, but it can easily be extended to the development of (for example) real-time embedded systems. JSD was described in his book System Development. Jackson has written a short paper called Origins of JSP and JSD: a Personal Recollection Problem Analysis or the Problem Frames Approach was the third software development method that Michael Jackson developed. It concerns itself with aspects of developing all kinds of software, not just information systems. It was
first sketched described in his book Software Requirements and Specifications, and much more fully in the book Problem Frames. Each of these methods covers a wider scope than the previous one, and builds on ideas that appeared, but were not fully developed, in the previous one. So there was a real evolution... one set of ideas evolved into another. JSP and JSD were developed in the 1970's and 1980's -- in the Pre-Web-Epoch -- so virtually all of the material describing them is printed on dead trees. Relatively few detailed descriptions of JSP or JSD are available in electronic form on the Web, although you can find several Web sites with overviews. The major works on JSP and JSD are still in print or easily available from Web sites that deal with used books. Most secondary publications are out of print. The literature page has information about literature and publications describing JSP and JSD. The paper "A System Development Method" provides a good overview of JSD.
Usage of JSP:
JSP is widely used for developing dynamic web sites. JSP is used for creating database driven web applications because it provides superior server side scripting support.
Portability:
The Java feature of write once, run anywhere is applicable to JSP. JSP is platform independent, making it portable across any platform and therefore, mulit-platform. It is possible for the programmer to take a JSP file and move it to another platform, JSP Servlet engine or web server.
Because of Efficiency
As soon as the request is received, the JSP pages gets loaded into the web servers memory. The following transactions are then carried out within a minimal time period, handling JSP pages with efficiency.
Reusability:
JSP allow component reuse by using JavaBeans and EJBs.
Robust:
JSP offers a robust platform for web development.
Independency of Layers:
There is a clear separation between presentation and implementation layers. The HTML on the web browser of the client is displayed as a presentation layer. The JSP on the server is displayed in the implementation layer. Programmers who want to work with HTML can work independently without the work of the Java developers, working in the implementation layer, being affected. Java Server Pages, or JSP, is the way to separate the look of the web page from the corresponding content. The combination of JDBC and JSP works very well. JSP is used for generating dynamic web pages. It is essential that data in these systems be maintained efficiently and securely. The programmer must have a good database and database connectivity. This is achieved by JDBC through its excellent database connectivity in heterogeneous database system. This database system is used for the integration of heterogeneous database management systems presenting a single query interface system.
Simplification of Process:
The JSP language has a simple development and maintenance process. A JSP file that has the extension .jsp is converted into a servlet .java which is dynamically compiled, loaded and executed. Only when there is a change in a JSP file, the Conversion, compilation, and loading process is then performed.
INDEX
S.N Name of the Experiments o.
1. 2. Familiarization with SMARTDRAW tool. Introduction to DFD (Data flow Diagram).
Signat ure
3. 4.
Construct a DFD for RMS Calculator. Construct DFD for Student Record Management System. 5. Create a DFD for the expression: (a+b)*(b/d). 6. Introduction to E-R diagrams 7. Construction of ER-Diagram for Car Insurance Company whose customer own a one or two cars. Each car has associated with it, 0 to any number of accidents. 8. Introduction to Structure Chart 9.(a) Conversion of DFD of RMS calculator to structure chart using Transform Analysis. 9.(b) Conversion of DFD of ATM cash withdrawal to structure chart using Transaction Analysis. 10. Introduction to JSP (Jackson Structured Programming) and JSD (Jackson System Development).
S.E.
(Software Engineering )
LAB FILE
SUBMITTED
CSE-6 80906107