This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report 3i3n4
tag so that paragraphs contained in it will be fully justified and will use the Helvetica font. there are many different ways you can lay out CSS rules, and you can also include them directly within tags or save a set of rules to an external file to be loaded in separately. This flexibility lets you do more than style your HTML precisely; you will also see how it can (for example) provide
Chapter 3 SYSTEM DESIGN
3.1 Process Flow Diagram Process Flow Diagram or Flowchart is a diagram which uses geometric symbols and arrows to define the relationships. It is a diagrammatic representation of the algorithm. The Process flow Diagram of our application is shown below:
3.2 Use Case Diagram A use case diagram at its simplest is a representation of a 's interaction with the system and depicting the specifications of a use case. A use case diagram can portray the different types of s of a system and the various ways that they interact with the system. This type of diagram is typically used in conjunction with the textual use case and will often be accompanied by other types of diagrams as well. Always structure and organize the use case diagram from the perspective of the actor. Use cases should start off simple and at the highest view possible. Only then can they be refined and detailed further. Use case diagrams are based upon functionality and thus should focus on the "what" and not the "how". So in brief, the purposes of use case diagrams can be as follows:
Used to gather requirements of a system. Used to get an outside view of a system. Identify external and internal factors influencing the system. Show the interacting among the requirements are actors.
3.3 ENTITY RELATION DIAGRAM Entity relationship diagrams are useful for illustrating the relationships between different elements in a database. With the help of entity relationship diagrams, the structure of a database is made clear, and it is possible to see exactly how the different elements are interlinked. You can use entity relationship diagrams to plan a database you are going to build, or to maintain an existing database structure. An ER model is an abstract way of describing a database. In the case of a relational database, which stores data in tables, some of the data in these tables point to data in other tables - for instance, your entry in the database could point to several entries for each of the phone numbers that are yours. The ER model would say that you are an entity, and each phone number is an entity, and the relationship between you and the phone numbers is 'has a phone number'. Diagrams created to design these entities and relationships are called entity–relationship diagrams or ER diagrams. ER Diagram is a visual representation of data that describes how data is related to each other. In ER Model, we disintegrate data into entities, attributes and setup relationships between entities, all this can be represented visually using the ER diagram. For example, in the below diagram, anyone can see and understand what the diagram wants to convey: Developer develops a website, whereas a Visitor visits a website.
3.4 Components of ER Diagram Entity, Attributes, Relationships etc. form the components of ER Diagram and there are defined symbols and shapes to represent each one of them. Let's see how we can represent these in our ER Diagram.
Entity Simple rectangular box represents an Entity.
Relationships between Entities - Weak and Strong Rhombus is used to setup relationships between two or more entities.
Attributes for any Entity Ellipse is used to represent attributes of any entity. It is connected to the entity.
Weak Entity A weak Entity is represented using double rectangular boxes. It is generally connected to another entity.
Key Attribute for any Entity To represent a Key attribute, the attribute name inside the Ellipse is underlined.
Derived Attribute for any Entity Derived attributes are those which are derived based on other attributes, for example, age can be derived from date of birth. To represent a derived attribute, another dotted ellipse is created inside the main ellipse.
Multivalued Attribute for any Entity Double Ellipse, one inside another, represents the attribute which can have multiple values.
Composite Attribute for any Entity A composite attribute is the attribute, which also has attributes.
3.5 Diagram: Relationship A Relationship describes relation between entities. Relationship is represented using diamonds or rhombus.
There are three types of relationship that exist between Entities. 1. Binary Relationship 2. Recursive Relationship 3. Ternary Relationship
3.6 Activity Diagram Activity diagrams are graphical representations of workflows of stepwise activities and actions with for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes
Basic Activity Diagram Notations and Symbols Initial State or Start Point A small filled circle followed by an arrow represents the initial action state or the start point for any activity diagram. For activity diagram using swim lanes, make sure the start point is placed in the top left corner of the first column.
Activity or Action State An action state represents the non-interruptible action of objects. You can draw an action state in SmartDraw using a rectangle with rounded corners.
Action Flow Action flows, also called edges and paths, illustrate the transitions from one action state to another. They are usually drawn with an arrowed line.
Object Flow Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to an object means that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses the object.
Decisions and Branching A diamond represents a decision with alternate paths. When an activity requires a decision prior to moving on to the next activity, add a diamond between the two activities. The outgoing alternates should be labeled with a condition or guard expression. You can also label one of the paths "else."
Guards In UML, guards are a statement written next to a decision diamond that must be true before moving next to the next activity. These are not essential, but are useful when a specific answer, such as "Yes, three labels are printed," is needed before moving forward.
Synchronization A fork node is used to split a single incoming flow into multiple concurrent flows. It is represented as a straight, slightly thicker line in an activity diagram. A node s multiple concurrent flows back into a single outgoing flow. A fork and mode used together are often referred to as synchronization.
Time Event This refers to an event that stops the flow for a time; an hourglass depicts it.
Merge Event A merge event brings together multiple flows that are not concurrent.
Sent and Received Signals Signals represent how activities can be modified from outside the system. They usually appear in pairs of sent and received signals, because the state can't change until a response is received, much like synchronous messages in a sequence diagram. For example, an authorization of payment is needed before an order can be completed.
Interrupting Edge An event, such as a cancellation, that interrupts the flow denoted with a lightning bolt.
Final State or End Point An arrow pointing to a filled circle nested inside another circle represents the final action state.
3.7 Inventory Activity 4
Fig.Inventory Activity
3.8 CLASS DIAGRAM What is a Class Diagram? A class diagram models the static structure of a system. It shows relationships between classes, objects, attributes, and operations.
Basic Class Diagram Symbols and Notations Classes Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes. Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition (left-aligned, not bolded, and lowercase), and write operations into the third.
Active Classes Active classes initiate and control the flow of activity, while ive classes store data and serve other classes. Illustrate active classes with a thicker border.
Visibility Use visibility markers to signify who can access the information contained within a class. Private visibility, denoted with a - sign, hides information from anything outside the class partition. Public visibility, denoted with a + sign, allows all other classes to view the marked information. Protected visibility, denoted with a # sign, allows child classes to access information they inherited from a parent class.
Associations
Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other.
Multiplicity (Cardinality) Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for just one company
.
Constraint Place constraints inside curly braces {}.
Composition and Aggregation Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the two classes are not dependent on each other. The diamond ends in both composition and aggregation relationships point toward the "whole" class (i.e., the aggregation).
Class Diagram
Fig.Class Diagram Generalization Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between two classes where one class is a specialized version of another. For example, Honda is a type of car. So the class Honda would have a generalization relationship with the class car.
In real life coding examples, the difference between inheritance and aggregation can be confusing. If you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions of the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC and PROTECTED functions of the superclass.
3.9 SEQUENCE DIAGRAM A sequence diagram is an interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes called inventory diagram. A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur.
Notation Description
Actor
A type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data)
external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject).
represent roles played by human s, external hardware, or other subjects. Note that:
An actor does not necessarily represent a specific physical entity but merely a particular role of some entity
A person may play the role of several different actors and, conversely, a given actor may be played by multiple different person.
Lifeline
A lifeline represents an individual participant in the Interaction.
Visual Representation
Activations
A thin rectangle on a lifeline) represents the period during which an element is performing an operation.
The top and the bottom of the of the rectangle are aligned with the initiation and the completion time respectively
Call Message
A message defines a particular communication between Lifelines of an Interaction.
Call message is a kind of message that represents an invocation of operation of target lifeline.
Return Message
A message defines a particular communication between Lifelines of an Interaction.
Return message is a kind of message that represents the of information back to the caller of a corresponded former message.
Self Message
A message defines a particular communication between Lifelines of an Interaction.
Self message is a kind of message that represents the invocation of
message of the same lifeline.
Recursive Message
A message defines a particular communication between Lifelines of an Interaction.
Recursive message is a kind of message that represents the invocation of message of the same lifeline. It's target points to an activation on top of the activation where the message was invoked from.
Create Message
A message defines a particular communication between Lifelines of an Interaction.
Create message is a kind of message that represents the instantiation of (target) lifeline.
Destroy Message
A message defines a particular communication between Lifelines of an Interaction.
Destroy message is a kind of message that represents the request of destroying the lifecycle of target lifeline.
Duration Message
A message defines a particular communication between Lifelines of an Interaction.
Duration message shows the distance between two time instants for a message invocation.
Note A note (comment) gives the ability to attach various remarks to elements. A comment carries no semantic force, but may contain information that is useful to a modeler.
3.10 UML DIAGRAM
The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering, that is intended to provide a standard way to visualize the design of a system.[1] The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in 1994–1995, with further development led by them through 1996. In 1997 UML was adopted as a standard by the Object Management Group (OMG), and has been managed by this organization ever since. In 2005 UML was also published by the International Organization for Standardization(ISO) as an approved ISO standard. Since then the standard has been periodically revised to cover the latest revision of UML. UML offers a way to visualize a system's architectural blueprints in a diagram, including elements such as:[4]
any activities (jobs);
individual components of the system;
and how they can interact with other software components.
how the system will run;
how entities interact with others (components and interfaces);
external interface.
Structuring Use Cases UML defines three stereotypes of association between Use Cases: <
<<extend>> Use Case An extending use case is, effectively, an alternate course of the base use case. The <<extend>> use case accomplishes this by conceptually inserting additional action sequences into the base use-case sequence.
Abstract and generalized Use Case The general use case is abstract. It can not be instantiated, as it contains incomplete information. The title of an abstract use case is shown in italics.
PROGRAM (DATA) FLOW CHART A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated. DFDs can also be used for the visualization of data processing (structured design). A DFD shows what kinds of information will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel (which is shown on a flowchart.
What is a data flow diagram (DFD)? Data Flow Diagrams (DFD) A data flow diagram can also be used for the visualization of Data Processing. It is common practice for a designer to draw a context-level DFD first which shows the interaction between the system and outside entities. This context-level DFD is then "exploded" to show more detail of the system being modeled. A DFD represents flow of data through a system. Data flow diagrams are commonly used during problem analysis. It views a system as a function that transforms the input into desired output. A DFD shows movement of data through the different transformations or processes in the system. Dataflow diagrams can be used to provide the end with a physical idea of where the data they input ultimately has an effect upon the structure of the whole system from order to dispatch to restock how any system is developed can be determined through a dataflow diagram. The appropriate saved in database and maintained by appropriate authorities.
We usually begin with drawing a context diagram, a simple representation of the whole system. To elaborate further from that, we drill down to a level 1 diagram with additional information about the major functions of the system. This could continue to evolve to become a level 2 diagram when further analysis is required. Progression to level 3, 4 and so on is possible but anything beyond level 3 is not very common. Please bear in mind that the level of detail asked for depends on your process change plan.
Diagram Notation Now we'd like to briefly introduce to you a few diagram notations which you'll see in the tutorial below.
1. External Entity An external entity can represent a human, system or subsystem. It is where certain data comes from or goes to. It is external to the system we study, in of the business process. For this reason, people use to draw external entities on the edge of a diagram.
Process A process is a business activity or function where the manipulation and transformation of data takes place. A process can be decomposed to finer level of details, for representing how data is being processed within the process.
3.Data Store A data store represents the storage of persistent data required and/or produced by the process. Here are some examples of data stores: hip forms, database table, etc.
4. Data Flow
A data flow represents the flow of information, with its direction represented by an arrow head that shows at the end(s) of flow connector.
Data flow diagram symbol
Symbol
Description Data Flow – Data flow are pipelines through the packets of information flow.
Process : A Process or task performed by the system.
Entity : Entity are object of the system. A source or destination data of a system.
Data Store : A place where data to be stored.
Chapter 4 ANALYSIS AND DESIGN
4.1 Background Research We started research by identifying the need of IMS in the organization. Initially we bounded our research to find the general reasons that emerged the needs of Inventory Management System. We used different techniques to collect the data that can clearly give us the overall image of the application. The techniques we used were interview with the developers, visiting online websites that are presented as the templates and visiting some organization to see their IMS application. Basically the following factors forced us to develop IMS application: Cost and affordability Lack of stock management. Effective flow of stock transfer and management. Difficulty in monitoring the stock management.
4.2 Requirement Analysis We collected a number of requirements for project from our primitive research, website visits, and interview to the concerned personnel and their experiences regarding the concepts of its development. We have even visited some organization in Kathmandu valley and analyze its importance and try to develop the project by fulfilling all the weakness that were found in the application. We then decided to build same type of application with different logic flow and new language which will be suitable for the small organization.
4.3 IMS Requirement The goal for the application is to manage the inventory management function of the organization. Once it is automated all the functions can be effectively managed and the organization can achieve the competitive advantage. Business requirement are discussed in the Scope section, with the following additional details: Helps to search the specific product and remaining stock. Details information about the product sales and purchase. Brief Information of the organization todays status in of news, number of present inventory as per the date entered. It helps to identify the total presented inventory in the company. To know the balance and details of sales distributed in specific date. There is proper transaction management of inventory. All transaction have specific entry date along with quantity and rate. Only can in the page.
4.4 s Requirement requirement are categorized by the type
Able to create new godwom along with date. Able to edit the entry as per entry. Able to add, modify and delete the stock entry.
Inventory management Able to check the stock available. Able to check the balance payment. Able to view the remaining sales stock.
Feasibility Analysis This software has been tested for various feasibility criterions from various point of views.
Economic Feasibility The system is estimated to be economically affordable. The system is medium scale desktop application and has affordable price. The benefits include increased efficiency, effectiveness, and the better performance. Comparing the cost and benefits the system is found to be economically feasible.
Technical Feasibility Development of the system requires tools like: MySQL, Which
are
easily
available
within
the
estimated
cost
and
schedule.
Operational Feasibility The system provides better solution to the libraries by adding the typical requirement and necessities. The solution provided by this system will be acceptable to ultimate solution for the stock management.
Schedule Feasibility The organized schedule for the development of the system is presented in the schedule subsection. The reasonable timeline reveals that the system development can be finished on desired time framework.
4.5 Gantt chart It is one of the popular way to illustrate project schedule. A Gantt chart is a graphical representation of a project that shows each activity task as a horizontal bar whose length is proportional to its time for completion. A Gantt chart for the project deliverables within time frame. This project Gantt chart is shown below:
GANTT CHART JUN(2019) Month
JUN(2019)-
2
3
4
AUG(2019)
SEPT(2019)
NOV(2019)
Weeks
Weeks
Weeks
Weeks
1
2
3
4
1
2
3
4
1
2
Planning
Requirement gathering
Analysis
Design
EXPECTED TIME Actual Time
OCT(2019)
JULY(2019)
Weeks
1
JULY(2019)- AUG(2019)-
ACTUAL TIME Taken Time
3
4
1
2
3
4
NOV(2019) Month
DEC(2019)-
JAN(2020)-
DEC(2020)-
FEB(2020)
JAN(2020)
FEB(2020)
FEB(2020)
MAR(2020 )
Weeks
1
2
3
Weeks
4
1
2
3
Weeks
4
Coding
Testing
Implementation
Fig:-Gantt chart
1
2
3
Weeks
4
1
2
3
Weeks
4 1 2 3 4