1 / 69

Session 7

Session 7. Modeling for OOSAD Learning objective UML Object modeling, Use case Model Use case based System diagrams. Primary goal Of UML. Goal Provide users a ready-to-use, expressive and visual modelling language to develop models.

nichole-whitehead
Télécharger la présentation

Session 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Session 7 • Modeling for OOSAD • Learning objective • UML • Object modeling, • Use case Model • Use case based System diagrams

  2. Primary goal Of UML • Goal • Provide users a ready-to-use, expressive and visual modelling language to develop models. • Provide a language and notations to extend concept to higher order representation. • Independent of OO languages. • Support higher level development concepts like Component technology, Rapid Application development, Reusability, Portability and Interoperability

  3. Advantages Of UML • Advantages • Improves communication among project teams Reason – Uniform common understanding of the system. • Improves developer's insight and visualisation of the complex system. • Developers learn faster the system intricacies incorporated correctly in the design. • Prototype design is more appropriate where specific complexity of structure and behaviour is considered in each iteration. This improves the system in increments, and part by part.

  4. Eight UML Diagrams • Diagram Objective View • Static class Structure Domain, Business. • Use Case Diagram. modeling Users • Sequence Diagram Interaction Behaviour • Collaboration Diagram modelling • State Chart Diagram • Activity Diagram. • Component Diagram Implementation Deployment • Deployment Diagram modelling

  5. Illustration Of UML Diagrams:Railway Ticket Booking System (RTBS) • System Name: Railway Ticket Booking System. • System Name: Ticket booking and collection (other subsystems are Reservation, Cancellation and Extensions) • Use Case Name: Ticket booking & collection on Payment. • Actors: Passenger or Passenger's representative. Issuing Clerk • Use Case Goal: Collect Money and Issue printed ticket • Precondition: Tickets are issued and passenger walks away and system is available to next passenger in the queue. Ticket/Train database is suitably stands updated showing open availability in numbers of ticket. • Related use cases: Reservation, Cancellation, Extension.

  6. RTBS Use case Specification • Users & Actors: Passenger, Counter clerk, system. • Pre condition: System is ready to service new passenger. • Post condition: Ticket record updated and new status is available. • Action by Passenger Response by Counter Clerk • Requests for ticket availability Confirms availability. • Submits the reservation form. Processes the form& reports fare • Pays the fare amount Updates ticket record Prints tickets

  7. Static Class Diagram • Classes in RTBS :Person (Passenger, Clerk) • Form (Reservation, Cancellation) • Train ( Express, Ordinary) • Ticket Class: Person Clerk Person Passenger Passenger Ticket Name, DOB, Gender Address, PNo Status Train NO, Name Date of journey From -To Class, Passengers names Train No Name, Bogie No, Passengers Name, Seat No Id, Dept Cell Phone Enquires Writes Enters Return Print Close Cancel Pays Receives

  8. RTB System Use case Model RTBS Requests availability Confirms Availability Submits RES form Passenger Processesthe Form Counter clerk With Booking system Pays the fare Updates the train record Prints ticket Prints tickets System has 7 use cases

  9. RTBS: Sequence Diagram • Sequence Diagram: Use case: Process Form Form Processing system Passenger Clerk 1.Submits Reservation Form 2.Enters Form data 4.Communicates to passenger 3.Reports availability status 6.Enters or OKs 5.Confirms or Modifies 7.Communicates Total fare amount 8.Submits record for ticket processing 9.Closes & updates the passenger record

  10. Use case: Process Form:Collaboration Diagram • Collaboration Diagram Passenger 1 7 4 5 Clerk 2 9 6 8 3 Form Processing system

  11. State Transition Diagram: Use case: Process Reservation Form • State Transition Diagram: State 1 State 2 State 3 Blank Res Form Shows availability status Data entered in form Ready to receive New Form Submits for Processing • Communicates to • passenger. • Records OK or • changes State 4 State 5 State 6 Shows Total amount Shows ticket Details Blank Res Form 1.Seeks confirmation 1.Communicates total fare Ready to Receive next New Form 2. Submits for ticket processing. 3.Cancels the record 2.Confirms acceptance of fare 3.Instructs to Print

  12. Activity diagram:Use case:Process Reservation Form • Activity diagram Start Enter Reservation data Available Process for availability Process record for Total fare Not available Cancels the record & Form Seeks acceptance to Total fare End Process record for ticketing or Cancel record. Update & Print ticket End End

  13. RTBS: Software Component Diagram • Software Component diagram GUI for RTBS access GUI for Res. Form & Entry Processing RESn Record Processing for Availability RESn Record Processing for Ticketing Record Processing for Ticketing Process for Ticket printing

  14. Software Deployment Diagram • Software Deployment Diagram for Reservation Form processing. RTBS Server GUI for RTBS access GUI for Res. Form & Entry Processing GUI for Print Ticket Client Client

  15. Session 8 • System Analysis • Learning Objective • Understanding System Analysis Process. • Decomposition of the system • Work flow diagramming • System views: DFD and Flow charts, ER Diagrams

  16. Purpose of Systems’ Analysis & its Output: RDD &SRS • Purpose :Define scope, analyze influences and determine requirements to solve the problem. Business Environment Systems Environment Influences Influences System Influences System’s analysis Influences Non Functional Analysis Functional Analysis RDD & SRS Users Requirement. Systems Requirement Business Requirement

  17. Steps in Systems’ analysis • Understand the environment of the system. in different views through building different view models. • Examine the system for radical improvement through Business Process Re Engineering (BPR). • Determine system scope. • Study of Work Flows, Process flows, procedures and methods. • Identification of users, stake holders. • Construct Behaviour models of Data, Process & Application • Study of Critical Problems/ Critical success factors / Processes / Mission Critical Applications • Ascertain the economic, operational, technical, feasibility. • Create RDD & document RDD in standard Format. • Create a SRS & document in standard Format

  18. Understanding the system Environment • Different system Views; • Organisation: The analysis should throw light on people issues, work culture & attitudes which have an influence on the system. The influencing factors should get addressed in the new system. People structure of the organization shows authority and chain of command. Business:we are looking at internal business environment, that is – how business is organised and executed, and external environment which impacts on internal business environment. • Management: The systems, the current or new, will have to fulfil the needs of management to suit their style of functioning Autocratic, Participative, Pro-Active, Risk Averse, and so on. • System: Study the system environment from technology point view and its place in rest of the system infrastructure. Compare a system in Public sector and in Private sector. Or a system in Private sector Indian organization and in a Multinational.

  19. Case study of Hospital management system (HMS) • focusing on patient management system (PMS)

  20. HMS Business Functions ModelBusiness View

  21. Illustration: Patient Management System PMS goal: Treat patient efficiently and collect charges. Make patient history availability on line.

  22. Hospital Management Structure Who are the users of the System? PMS PMS is run by doctors and Para medical staff and Administrative, Auxiliary services staff. They are Primary users of the system

  23. Context Diagram of PMS Business Environment Internal system Environment External system Environment

  24. Patient Management System & People, HR & Facility structure Operating Environment of PMS HR support structure People structure PMS Facility structure PMS efficiency & effectiveness depends on these structures.

  25. PMS within HMS • Decomposition of PMS PMS Admission PAS Billing PBS Treatment PTS Services recording Examination, Diagnostics PDE SRS PES Data Entry PDP Services Billing SBS Hospital services Data Processing HSS PES PHD PRC &ID PRS Bill processing BPS Patient care Registration PCS

  26. PMS handling • Discuss Coupling, clustering PMS Admission PAS Billing PBS Treatment PTS Services recording Examination, Diagnostics PDE SRS PES Data Entry PDP Services Billing SBS Hospital services Data Processing PES PHD HSS PRC &ID Bill processing BPS Patient care PRS Registration & ID processing PCS

  27. PMS work flow. • Work Flow/Process Flow Registration Treatment Diagnostic Services Billing • Critical processes: • Recording all services • Creation of patient history • Mission critical applications: • Billing and payment • Patient history calling

  28. Controls in PMS • Controls: • No treatment begins unless patient has ID card. • No treatment begins unless no bill is open . • Patient record is closed when no payment is left.

  29. Session 9 • Feasibility Studies. • Learning Objective • Why feasibility? • Types of feasibilities. • Decision making criteria

  30. Why feasibility study of the system? • A system is intended to solve the problems. • A software system should solve them more efficiently. • A system calls for investment in software development and IT infrastructure to make software system operational. • Unless Return on Investment justifies, it is not worth developing a software system solution to the problem.

  31. Feasibility Cube The system should succeed on technology platform, has strong economic viability & User must Successfully use it. Software system Operational Economics Technical

  32. Focus in Feasibility Study • Will the system make impact on improving business objective? • Is current technology tested and proven for the software solution? • Can the new system be integrated in current IS infrastructure? • Is current Human resource capable of handling new technology?

  33. Session 10 • Requirement elicitation • Learning Objective • RequirementAnalysis • Study of requirements (V model) Hierarchy. • Understanding users and their needs. • Types of requirements • Presenting RDD and SRS: Templates

  34. What is Requirement Analysis? • Requirement Analysis is a process of interacting with the system users toidentify the needs of various nature such as functions, features, & facilities to transact the business, make decisions and share & communicate information.

  35. Who are the users? • Users include all those who are affected directly by the system. • Users are of two types: Primary &Secondary. They are affected directly by the system. • Users also include Stake holders who are indirectly impacted by the system. • Users are put in four classes: Operators, Processors, Decision Makers, Stake holders.

  36. The outcome of Requirement Analysis ( RA ) • The outcome of RA is a structured document of operational & behavioral needs of the users, decision makers & stake holders affected by the system. • The document is called as Requirement Definition & Description ( RDD) • RDD forms the basis for developing SRS, Software Requirement Specification.

  37. RDD & SRS • RDD: Requirement definition & description suggests What to do ? • RDD is used to develop Software Requirement Specifications (SRS ) • SRS specifies software system specifications expressing the method of conversion of RDD to Software solution ? How to do?

  38. Role of RDD & SRS

  39. Hierarchy of Requirements

  40. Hierarchy of Requirements Determination:Problem: Customer dissatisfaction Waiting time High Long queues Improve Billing Process in Speed & scope . Automated data capture, faster Processor, Integrated Into Inventory, Procurement, Accounts system. Access to Customer Data base.

  41. Types of Requirements • Functional: System:Functions, Features & Facilities. Behavioral: Help, Guidance, Operational. • Non functional: Standards, Response, Environmental needs & factors influencing the functional processes. • Domain: Domain characteristics & culture based requirements

  42. Types of Requirements • Types Requirements Functional Non functional Domain Operational Behavioral

  43. Common reasons of Shortcomings in RDD • Lack of user inputs. • Incomplete requirements & specifications. • User /customer not firm on clear & firm requirements. • Lack of user participation in the process. • Lack of management support by confirming RDD. • Lack of domain knowledge on the part of Analyst & users.

  44. Class Exercise • College library system: Requirements Functional Domain Non functional Operational Behavioral

  45. Requirement Engineering • RE Model

  46. Requirement elicitation: RDD

  47. Structuring the Requirements:Example: Invoicing a Delivery to customer Level 1 Level 2 Level 3

  48. Content & characteristics of a Requirement • Requirement: Functional • Functions, • Features, • Facilities, • Performance, • Technology. Class Exercise: R9: Printing of the Bill

  49. Class Exercise solution • R9: Printing of Bill: Functional & nonFunctional • Functional • Function: Prints the Bill in a approved format. • Feature: Converts Rupee currency into customer required currency. Non functional • Facilities: a. Prints stated number of copies. b. E- mailing of the bill. • Performance: One bill per minute. • Technology: HCL printer model x 103 • Domain: Nothing specific.

  50. Session 11 • Requirements management • Learning Objective: • Difference between RDD & SRS • Documenting RDD • Documenting SRS • Assuring Delivery of RDD • Ensuring correctness.

More Related