Upcoming SlideShare
×

# Analysis modelling

1,424 views

Published on

1 Like
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

Views
Total views
1,424
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
48
0
Likes
1
Embeds 0
No embeds

No notes for slide
• Analysis modeling: structured analysis &amp; object-oriented analysis Primary objectives: To describe what the customer requires To establish a basis for the creation of a software design To define a set of requirements that can be validated once the software is built.
• ### Analysis modelling

1. 1.  Objectives of analysis model ◦ To describe what the customer require ◦ To establish a basis for the creation of a software design ◦ To define a set of requirements that can be validated once the software is built. Uses a combination of text and diagrams to show requirement
2. 2.  What is a model? ◦ a model is a simplification of reality Why do we model? ◦ we build models so that we can better understand the system we are developing ◦ we build models of complex systems because we cannot comprehend such a system in its entirety
3. 3.  Shows 3 aspects of a software :2. Data Modeling3. Functional Modeling4. Behavioral Modeling
4. 4. Data Dictionary – A repository that contains description of all data objects consumed or produced by the software.3 diagrams surround the core –1. ERD (Entity relationship diagram) – Depicts relationship between objects.2. DFD (Data Flow diagram)- Shows how data is transformed as they move through the system.3. STD (State transition diagram) – Shows how a system behaves as a consequence of external events.
5. 5. Data Modeling :2. What are the primary data objects?3. What attributes describe the object?4. What are the relationships between each objects?To answer these, data modeling methods makeuse of ERD--Defines all data that are entered, stored , transformed and produced within an application.
6. 6. Functional Modeling(DFD) external entity process data flow data store
7. 7. Notations used  A producer or consumer of data  Example: person, device, system, sensor  Data must always originate from somewhere, and must always be sent to something
8. 8. Notations used :  A data transformer (changes input to output)  Example: compute taxes, determine area, format report, display graph  Data must always be processed in some way to achieve system function
9. 9.  Notations used  Data flows through a system, beginning as input and be transformed into output base compute area triangle height area
10. 10. Data Store  Data is often stored for later use sensor # sensor #, type, look-up location, age sensor report required data type, location, age sensor number sensor data
11. 11. Rules for drawing a DFD : All icons must be labeled with meaningful names The DFD evolves through a number of levels of detail Always begin with a context level diagram which depicts the system as a single bubble (also called level 0) Always show external entities at level 0 Always label data flow arrows Do not represent procedural logic DFD should be balanced. A data store cannot be connected either to another data store or to an external entity.
12. 12. Balancing of DFD a p b x P y level 0 a c p2 p1 f p4 b d 5 p3 e g level 1
13. 13. Extensions for real time systems.• To accommodate analysis of real time software, we use extensions to basic DFD notations called Ward and Mellor Extensions.
14. 14. Notations used A data item that is input or output from a process on a time continous basis A process that accepts control input or output. A control flow/event A data store that stores control information.
15. 15. 3. Behavioral modeling (State transition diagram)STDs represent----• Behavior of system by depicting it’s state.• Events that cause system to change state.• What actions are to be taken as a consequence of a particular event?
16. 16.  State—a set of observable circumstances that characterizes the behavior of a system at a given time State transition—the movement from one state to another Event—an occurrence that causes the system to exhibit some predictable form of behavior Action—process that occurs as a consequence of making a transition
17. 17. State Transition Diagram Notation state event causing transition action that occurs new state
18. 18. ExampleConsider an XYZ project which has a type of sensor to measure air temperature.The sensor continuously sends out one of the three signals HIGH, NORMAL, LOW.If the temperature signal is high then AC is turned ON.If it is low then heater is turned ON.The air conditioner/ heater is turned OFF when the temperature is NORMAL.
19. 19. Example STD for a temperature NORMALsensor є HIGH HOFF AON AOFF LOW NORMAL NORMAL HON AOFF HOFF HOFF HON AON AOFF HIGH LOW є є
20. 20. Mechanics of structured analysis : Create an ER diagram. Create a DFD diagram. Create a control flow model• Large class of applications are driven by events.• Such applications require the use of control flow modeling in addition to data flow modeling.
21. 21. 4. Create a control specification.Represents the behavior of the system.a. Contains a STD.b. Contains a process activation table (PAT) which contains which processes will be invoked when an event occurs.Eg: Input events Temp High 1 0 0 Temp Normal 0 1 0 Temp Low 0 0 1 Process Activation ACOn Hoff 1 0 0 Hoff Aoff 0 1 0 ACOff Hon 0 0 1
22. 22. 5. Create a Process Specification(PSPEC)• Used to describe all flow model processes that appear at the final level of refinement.• Contents of PSPEC can be a narrative text, algorithm, table etc.
23. 23. Process Specification (PSPEC) can be used tospecify the processing details implied by aprocess within a DFD Check & convert pressure PSPEC If absolute tank pressure > max pressure then set above pressure to “true”; else set above pressure to “false”; begin conversion algorithm x-01a; compute converted pressure; end end if
24. 24. • A repository of data in a system• It enables to find answers to the following questions.DD contains 2 types of descriptions for the data flowing through the system-o Data elementso Data structures
25. 25. 1. Data ElementThe most fundamental unit of data.Eg. Invoice no, Amount due etc.Describing data elementsData elementDescriptionTypeLengthAliasesRange of valuesTypical valueOther details
26. 26. Eg. Data element : Employee no. Description : Identifies each employee in the organization Type : Alphanumaric Length : 7 Aliases : Empid Range of values : NA Typical value : AC41000 Other details : Employee no. includes a 5 digit no. and department prefix. Valid prefixes AC Accounting AD Advertising RD Research and development
27. 27. 2. Data StructuresSet of data items that are related to each other. Eg. Pay Cheque-- Date Amount Pay to Account no.
28. 28. 4 types of relationship exists between components of a data structure.2. Sequence relationship. Defines the set of data items that make up a data structure.
29. 29. eg. Student university record consists ofName First Name Middle Name Last nameStreet AddressCityStateTelephone no.Use the symbol -- +
30. 30. 2. Selection relationshipRepresents either/or relationship.i.e a choice of one item must be made from a set of 2/more items.Eg. Student data structure eg. Student data structure NameStreet AddressCityStateTelephone no.and one of the followingStudent No.Social Security no.Write options in [ ] , each option separated by I (vertical line)
31. 31. 3. Iteration relationship (Repetition)Data elements composing the data structure are repeated zero/ one/more times.Eg. Term registration data structureTermYearAdvisor1 to 6 iteration of courseCourse no.Course nameTimeDayInstructorNotation : All iteration data elements are shown in { }n n-no. of iterations.
32. 32. 4. Optional relationshipElements which may or may not be included. First Name Middle Name Last nameWhere middle name could be optionalNotation - ( )
33. 33. Eg :Student data = Name + street address +city +state +postal code + [Student No. I SS no] +{Course no + Course name + time + day + Instructor} + Term + year + advisorName =First Name + (Middle Name) + Last name