1. UNIT II SYSTEM ANALYSIS AND DESIGN
SYSTEM FLOW CHART
DECISION TABLE
DFD ER
OOAD
UML DIAGRAM
system flow charts are very similar to data flow charts. Data flow charts do not include decisions, they just show the path that data takes, where it is held, processed, and then output.

2. SYSTEM ANALYSIS
- An in-depth study of end-user information needs that produces functional requirements that are used as a basis for the design of an information system.
It involves
The information needs of a company and end users.
The activities, resources, and products of one or more of the present information systems being used.
The information system capabilities required to meet information needs of users, and those of other business stakeholders that may use the system.

3. STEPS:
ORGANIZATIONAL ANALYSIS:
First step in system analysis
Analyzing the organization, its management structure, its people, its business activities and the current information systems
ANALYSIS OF THE PRESENT SYSTEM
Analyzing how the present system uses hardware, software, network and people resources to convert data to information.
LOGICAL ANALYSIS
Primary activity of analysis phase is the construction of a logical model of the current system
Logical model – Blueprint

4. FUNCTIONAL REQUIREMENT ANALYSIS
Determines the specific business information needs.
(Type of information each business activity requires, its format, volume, frequency, response time..)
Determines the information processing capabilities required for each system activity
(input, processing, output, storage..)
 Main goal is to identify what should be done and not how to do it

5. SYSTEM DESIGN - Stage in which the logical model of the current system is modified until it represents the blueprint for the new system. - This stage focuses on HOW Consists of three activities

6. Design is a translation of requirements into ways of meeting them.
Physical system = logical model + objectives
Focus: How will the system Work
Deliverable: Functional/Design Specs

7. Also known as control flow diagram FLOW CHART COMPONENTS
SYSTEM FLOW CHART
System flowcharts are a way of displaying how data flows in a system and how decisions are made to control events.
Also known as control flow diagram
FLOW CHART COMPONENTS
Flowchart is the schematic representation of a process
Start/End

9. DECISION TABLE Decision tables are a precise yet compact way to model complicated logic In a decision table, business logic is well divided into conditions, actions (decisions) and rules for representing the various components that form the business logic. Decision tables can be used in all situations where the outcome depends on the combinations of different choices, and that is usually very often. In many systems there are tons of business rules where decision tables add a lot of value.
Decision table is a way to decision making that involves considering a variety of conditions and their interrelationships, particular for complex interrelationships. People use decision table to represent and discover business logic, which ultimately lead to better business.

11. STEPS TO MODEL DECISION TABLE Step 1: Analyze the requirement and create the first column Step 2: Add Columns Step 3: Reduce the table Step 4: Determine actions
CONDITION ALTERNATIVES
CONDITIONS
ACTIONS
ACTION ENTRIES

13. TOOLS – DFD, ERD, OO MODELLING
Data flow diagram shows the flow of data between the different entities and datastores in a system while a flow chart shows the steps involved to carried out a task. In a sense, data flow diagram provides a very high level view of the system, while a flow chart is a lower level view (basically showing the algorithm).

14. A data flow diagram looks at how data flows through a system.
It focuses on things like where the data will come from and go to as well as where it will be stored, but does not contain information about the processing timing (e.g. whether the processes happen in sequence or in parallel).
Data flow diagram symbols consist of four symbols which are processes, data flows, data stores and external entities.
Context diagram – level 0 – level 1-level n
DFD during analysis phase. DFD used to produce the process model. In the analysis phase, requirements of a system are identified and refined into a process model . show the way of data moves among the processes.

19. Unique name in data flow diagrams:
A unique name (verb phase), a number and a description for a process
A unique name that is a noun and a description for a data flow
A unique name that is a noun and a description for data store
A unique name that is a noun and a description for external entity

20. RULES OF DATA FLOW •Data can flow from -external entity to process -process to external entity -process to store and back -process to process • Data cannot flow from -external entity to external entity -external entity to store -store to external entity -store to store

21. GOOD STYLE IN DRAWING DFD
Use meaningful names for data flows, processes and data stores.
Use top down development starting from context diagram and successively leveling DFD
Only previously stored data can be read
A process can only transfer input to output. It cannot create new data
Data stores cannot create new data

22. ERD
ENTITY
An entity-relationship diagram (ERD) is a data modeling technique that graphically illustrates an information system's entities and the relationships between those entities. An ERD is a conceptual and representational model of data used to represent the entity framework infrastructure.
Entity-a thing (animate or inanimate) of independent physical or conceptual existence and distinguishable.
In the University database context, an individual student, faculty member, a class room, a course are entities.
Entity Set or Entity Type-Collection of entities all having the same properties.
Student entity set –collection of all student entities.
Course entity set –collection of all course entities.
During the systems analysis phase, an entity-relationship diagram gives the analyst a clear, high-level view of the data. Used in conjunction with data flow diagrams, an entity-relationship model gives the analyst an alternative logical view of the system

49. ATTRIBUTES
Each entity is described by a set of attributes/properties.
student entity
StudName–name of the student.
RollNumber–the roll number of the student.
All entities in an Entity set/type have the same set of attributes.
KEY ATTRIBUTE- HAS UNIQUE VALUE

50. Types of Attributes
Simple Attributes
having atomic or indivisible values.
Example: Dept–a string
PhoneNumber–an eight digit number
•Composite Attributes
having several components in the value.
example: Qualification with components(DegreeName, Year, UniversityName)
•Derived Attributes
Attribute value is dependent on some other attribute. example:Agedepends on DateOfBirth.
So age is a derived attribute.

51. •Single-valued
having only one value rather than a set of values.
for instance, PlaceOfBirth–single string value.
•Multi-valued
having a set of values rather than a single value.
For instance, Courses Enrolled attribute for student
Address attribute for student
Previous Degree attribute for student.
Attributes can be simple single-valued, simple multi-valued, composite single-valued or composite multi-valued.

52. Key attribute
ellipsederived attribute-dashed ellip
Entity Sets and Key Attributes•Key–an attribute or a collection of attributes whose value(s) uniquely identify an entity in the entity set.•For instance, •RollNumber-Key for Studententity set•EmpID-Key for Facultyentity set•HostelName, RoomNo-Key for Studententity set(assuming that each student gets to stay in a single room)

53. Relationships
When two or more entities are associated with each other, we have an instance of a Relationship.
E.g.: student Ramesh enrolls in Discrete Mathematics course
Relationship enrolls has Student and Course as the participating entity sets.
Degree of a relationship
Degree: the number of participating entities.
•Degree 2: binary
•Degree 3: ternary
•Degree n: n-ary
Binary relationships are very common and widely used.

56. Object-oriented analysis and design (OOAD)
CONCEPT
Object-oriented analysis and design (OOAD) is a popular technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the development life cycles to foster better stakeholder communication and product quality.

58. Object – Data Structure and Behaviour

60. Discrete, distinguishable Objects Inherent Identity Unique handle

61. Classification Class describes set of Objects

67. Inheritance In

68. Polymorphism

70. Identification and Organization of Application Concepts Way of thinking, not language, not implementation

71. OO development uses graphical notation

73. Conception: Analysis Tentative requirements Build model
Understand the problem( what and not how)
Domain model-(modules description)
Application model(user)

74. System architecture
Characteristics to optimise
Strategy to attack problems
Make initial Resource allocation

75. Add details to both domain and application objects.
Implement the data structure and algorithm

76. Translate to Programming language, data base, hardware, software

78. OO Development:
Identification and Organization of Application Concepts. Way of thinking, not language, not implementation
OO Methodology

79. OO Development:
Identification and Organization of Application Concepts. Way of thinking, not language, not implementation
OO Methodology
Modeling

80. OO Development:
Identification and Organization of Application Concepts. Way of thinking, not language, not implementation
OO Methodology
Modeling
Design a System –Class,State, Interaction

81. Class: Static Structure Data
Captures important concepts from the real world
Basis for other models

82. State Model :
Time and sequencing

83. Interaction Model
Interaction of objects
Collaboration of objects
Exchange between objects

84. OO Development:
Identification and Organization of Application Concepts. Way of thinking, not language, not implementation
OO Methodology
Modeling
4. Design a System –Class,State, Interaction

86. Essential Aspects
Ignore Details
What and not how
No hurry to commit

88. OO Themes:
Abstraction
Encapsulation

90. OO Themes:
Abstraction
Encapsulation
Combining Data and behavior

91. OO Themes:
Abstraction
Encapsulation
Combining Data and behavior
Sharing
Emphasis on what an object is
Synergy

93. Benefits of OOD

95. 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.

97. Class Relationships Attributes Operations Uses: Domain concepts
Conceptual/analysis model
Shows OO design

100. Software components

102. Hardware
Middle ware
Software

105. Instances and not classes
Complicated relationships in small area

107. Simplify complex class diagrams
Package(folder) is a collection of UML elements

112. Object oriented equivalent of flowchart and DFD
Business process and use case

114. Different states( over time)
History of an entity
Changing from one state to the other

116. Use case- valuable to actor
Actor- plays a role
Associations- between user and use case

120. Collaboration ( not time sequence) of Objects
Behaviour of Use case

122. Time Sequence in a use case scenario

124. Type of Sequence Diagram
Behavior for a given period of time

126. Variant of activity diagram
Describes interactions( hidden ones)