Successfully reported this slideshow.
Your SlideShare is downloading. ×

Introduction to SAD.pptx

Upcoming SlideShare
Introduction to SAD.pptx
Introduction to SAD.pptx
Loading in …3

Check these out next

1 of 53 Ad

More Related Content

Similar to Introduction to SAD.pptx (20)


Recently uploaded (20)

Introduction to SAD.pptx

  1. 1. . 1 System Analysis and Design (Professional Solutions) Week 1 : Introduction to SAD
  2. 2. Today’s Activities • Module overview • Ice-breaking • Lecture – Introduction to SAD 2
  3. 3. Module Overview • Module : System Analysis and Design (Professional Solutions) • Level 4 with 20 Credits • Lets see Module Descriptor 3
  4. 4. Ice breaking 4
  5. 5. Content • Introduction to processes involve in Analysis and Design • Revise Structured Approach • Revise Object Oriented Approach 5
  6. 6. What Is Systems Analysis and Design (SAD)? The process of implementing and operating an information system Requires knowledge of: • Organization’s objectives, structure, processes • Information technology opportunities and constraints 6
  7. 7. What Is Systems Analysis and Design? The major goal of SAD is : “to improve organizational systems, typically by developing application software/system that can help employees accomplish key business tasks easily and efficiently” A system is designed to support a specific organizational function or process (inventory management, payroll, etc) 7
  8. 8. Analysis Its meaning (Greek word) “to break down into component parts”. It is a process of coming to understand fully the problem that is trying to be solved. Analysis activity is characterized as asking: • What happens in current system? • What is required in the new system? 8 Definitions
  9. 9. Analysis It is a process of seeking to: • Understand the organization • Investigating its requirement, and • Modeling them. Result : A specification of what the proposed system will do based on requirements (requirement specification). 9 Definitions
  10. 10. Design Design activity is concerned with specifying: • How the new system will meet the requirements? It is a process of : • Producing a solution that meets the requirements that have been analysed. Jacobson et. al (1992) regards: “design as a part of construction process (together with implementation)” 10 Definitions
  11. 11. 11 Analysis Design Role of Systems Analyst Role of Systems Designer Description of the Problems Description of the Solutions Analysis and design can be viewed as follows: Definitions
  12. 12. Systems Analysis  Process of • defining the problems • gathering the requirements • developing an analysis model representing those requirements  Describing the problem the system is meant to solve  Goal: • To state accurately the users’ requirements for a new information processing system 12 Definitions
  13. 13. Systems Design A process by which the analysis model is transformed into a model which is capable of being implemented Describing the solution to the problems Goals: • Satisfaction of requirements • Provide effective function • Performance • Specify the acceptable level of performance • Constructability • Feasible to construct the new system/artifact • Efficient design process • Maximizing the efficiency of the process 13 Definitions
  14. 14. Add formality Improve communication between participants Get the requirements right! Reduce errors The cost of fixing analysis and design errors as one moves from the analysis phase to the maintenance phase can increase by a factor of 100 Generate documentation and get approval from end-user. 14 The Purpose of Analysis and Design
  15. 15. 15 Cost of Analysis and Design Error
  16. 16. 16 Source: Pressman Specification/requirements/design: 63.7% Source of errors
  17. 17. 17  Structured Approach made of three techniques  Structured analysis  Structured design techniques  Structured programming  Collectively referred to as structured analysis and design technique (SADT) Structured Approach
  18. 18. Structured Analysis • Helps developer define what the system needs to do (processing requirements) • Data to store and use • Inputs and outputs • How functions work together • DFDs and ERDs commonly used to show results of structured analysis 18 Structured Approach
  19. 19. 19 Structured Approach, Data Flow Diagram (DFD)
  20. 20. 20 Structured Approach Entity Relationship Diagram (ERD)
  21. 21. Structured design is developed to provide guidelines : •What the set of programs should be? •What each program should accomplish? •How programs should be organized into a hierarchy? 21 Structured Approach
  22. 22. 22 Structured Approach Structure Chart –using Structured Design Technique
  23. 23. Structured Programming • The process of implementing a structured design • Developed in the 1960’s to improve computer program quality and allow other programmers to easily read and modify the code • Each program module has one beginning and one ending 23 Structured Approach
  24. 24. Views information systems as collections of interacting objects that work together to accomplish tasks Objects - a thing in the computer system that can respond to messages No processes, programs, data entities, or files 24 Object-oriented Approach
  25. 25.  Object-oriented analysis • Defines all types of objects that do the work of the system • Shows how objects interact  Object-oriented design • Defines all additional object types needed to communicate with people and devices in the system • Refines each type of object for implementation in a specific language and environment 25 Object-oriented Analysis and Design
  26. 26. The main concepts introduced here are: • Objects, Classes and Instances • Object State • Generalization and Specialization • Message-passing and Encapsulation • Polymorphism 26 Based on Chapter 4 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (2nd Edition), McGraw Hill, 2002. What is object orientation
  27. 27. An object is: “an abstraction of something in a problem domain, reflecting the capabilities of the system to”  keep information about it,  interact with it,  or both. Coad and Yourdon (1990) 27 Objects
  28. 28. “Objects have state, behaviour and identity.” Booch (1994) State: the condition of an object at any moment, affecting how it can behave Behaviour: what an object can do, how it can respond to events and stimuli Identity: each object is unique 28 Objects
  29. 29. 29 Object A person. ‘Hussain Pervez.’ Speak, walk, read. Studying, resting, qualified. A shirt. My favourite button white denim shirt. Shrink, stain, rip. Pressed, dirty, worn. A sale. Sale no #0015, 16/06/02. Earn loyalty points. Invoiced, cancelled. Identity Behaviour State A bottle of ketchup. This bottle of ketchup. Spill in transit. Unsold, opened, empty. Examples of Objects
  30. 30. What Is an Object? An entity that encapsulates data and behavior Objects are categorized into classes Each individual object is an instance of a class 30
  31. 31. What Is Encapsulation? The characteristic of object-orientation in which data and behavior are bundled into a class and hidden from the outside world Access to the data and behavior is provided and controlled through an object’s interface 31
  32. 32. Class - a category of objects that share the same: • attributes, • operations/methods • relationships and semantics All objects are instances of some class 32 What Is Class?
  33. 33. 33 Name Attributes Operations
  34. 34. What Is an Attribute? Attribute- a named property of a class that describes a range of values that instances of the attribute might hold Attributes are the way classes encapsulate data 34
  35. 35. 35 Attributes are properties containing values Minus sign indicates these are private (hidden)
  36. 36. What Is an Operation? A behavior of an object Implemented in classes are methods Methods are identified and invoked by their signatures, including name, parameters, and return type 36
  37. 37. 37 Signature identifies and invokes the behavior Method implements the behavior
  38. 38. 38 Method signatures Plus sign indicates these are public (accessible)
  39. 39. What Is Generalization? A relationship between a more general (or parent) class and a more specific (or child) class The more specific class has additional attributes and operations 39
  40. 40. What Is Inheritance? The mechanism by which the more specific class in a generalization relationship includes the attributes and operations of the more general class Actually, inheritance is the facility in an O-O language that implements generalization/specialization 40
  41. 41. 41 Generalization represented by arrows from subclass to super class Subclasses inherit all attributes and operations of super classes
  42. 42. 42 Person Employee Customer Supplier monthly paid weekly paid hourly paid Driver Cleaner Sales assistant More general (superclasses) More specialized (subclasses) Specialization Hierarchy
  43. 43. What Is Polymorphism? The ability for different classes of objects to respond to identical messages in different ways Polymorphism = “having many forms” Different behaviors for the same message 43
  44. 44. 44 Here, each type of vehicle has its own version of calcPrice()
  45. 45. Can save effort • Reuse of generalized components cuts work, cost and time Can improve software quality • Encapsulation increases modularity • Sub-systems less coupled to each other • Better translations between analysis and design models and working code 45 Advantages of Object Orientation
  46. 46. 46 THE WAY WE THINK ABOUT PROBLEMS OO approach • Model the world as it is • Simulation based modelling Structured approach • Model the world as a set of functions • Solution based modelling The Difference in Philosophy
  47. 47. 47 THE WAY WE SUB-DIVIDE THE PROBLEM - encapsulation - information hiding - abstraction OO approach based on: Can only achieve encapsulation and information hiding through discipline Structured approach The Difference in Philosophy
  48. 48. 48 THE RELATIONSHIP BETWEEN ANALYSIS AND DESIGN • Phases are related by refinement Classes has-a is-a Classes has-a is-a Refinement OO approach The Difference in Philosophy
  49. 49. 49 THE RELATIONSHIP BETWEEN ANALYSIS AND DESIGN • Phases are related by transformation DFDs Structure Charts Transformation Structured approach The Difference in Philosophy
  50. 50. 50 OO Approach - consideration of the user interface • identify Use-cases • identify classes, attributes, operations and relationships • identify behaviour - identification of abstract classes - identification of data managers • refine analysis model to a design model by: - consideration of detailed user requirements The Difference in Philosophy
  51. 51. 51 Structured Approach • build a hierarchy of DFDs • identify an overall process • identify external entities • transform DFDs to structure charts The Difference in Philosophy
  52. 52. Conclusion • Introduction to processes involve in Analysis and Design • Structured Approach – several modelling techniques – DFD, ERF, Structures Design technique • Object Oriented Approach – concepts of object, encapsulation, polymorphism • Differences between structured approach and OO approach 52
  53. 53. Resource • Chapter 3 and 4. Simon Bernett, Steve Mc Robb and Ray Farmer. Object-oriented System Analysis and Design Using UML. 53

Editor's Notes

  • Code: 36.3
  • A useful exercise for the class would be to suggest other behaviours and states for these objects, and to describe:
    How external events and object behaviour can both result in a change of state
    How state restricts the possible behaviours of an object
  • We don’t go into relationships and semantics at all here. Nor do we discuss attributes, operations and methods in any detail. All will be covered more extensively in later material, but lecturers may wish to add more explanation here.
  • It would be a useful class exercise to:
    add more detail to other parts of this hierarchy
    to suggest ways in which the various subclasses differ from each other in behaviour and structure.
  • This slide covers the point only in bare outline.
    Extra material could usefully be added to show the advantages of and justifications for O-O in more detail.