VIEWS: 155 PAGES: 28 POSTED ON: 2/5/2010
Modeling System Requirements:Events and Things Models and modeling Events and system requirements Things and system requirements The entity-Relationship Diagram The Class Diagram Management information system 5_ 1 Huang Hong 教学/考核要点 Models and modeling The purpose of models Types of models Events and system requirements Events Types of events (external event, state event, temporal event时序事件) System controls Perfect technology assumption Event table, how to develop an event table* Things and system requirements Types of things Relationship among things (cardinality or multiplicity) Attributes, compound attribute, key or identifier Data entity, class, methods, encapsulation The Entity-Relationship Diagram[实体联系图] ERD notations, how to develop ERD* The Class Diagram Class diagram notations, how to develop class diagram* Management information system 5_ 2 Huang Hong Waiters on wheels: computerized delivery tracking Waiters on Wheels is a restaurant meal-delivery service started in 1997 Business expanding made the owner realized that they need a custom （定制的，专门的） computer system to support their operations Consultant Sam Wells help them to define the system they needed. The investigation process and the brief result. Notice how Sam found out their requirements Management information system 5_ 3 Huang Hong Models and Modeling Models A representation of some of the important aspect of the system being built modeling The process of creating models The purpose of models Models can be used to document the system analysis and design result Learning from the modeling process Reducing complexity by abstraction and helping focus the analyst’s efforts on a few aspects of the large, complex information at a time Models are used as memory aids for analysts Models are used as communication media between team members and stakeholders Requirements models are used as documentation for future development teams when they maintain or enhance the system Types of models Mathematical model:a series of formulas that describe technical aspects of a system Descriptive model:narrative memos, reports, or lists that describe some aspect of a system Graphical model:diagrams and schematic representations of some aspect of a system Management information system 5_ 4 Huang Hong Overview of models used in analysis Management information system 5_ 5 Huang Hong Overview of models used in design Management information system 5_ 6 Huang Hong Events and System Requirements All approaches of system development begin the modeling process with the concept of an event, events drive or trigger all processing that a system does, so it is a good idea to list and analyze the system’s events when you need to define system requirements Events:an occurrence at a specific time and place, that can be described and is worth remembering The event concept comes from the analysis of real time systems Types of events External event: an event that occurs outside the system, usually initiated by an external agent or actor Temporal event: an event that occurs as a result of reaching a point in time State event: an event that occurs when something happens inside the system that triggers the need for processing Management information system 5_ 7 Huang Hong External events and temporal events Events The background of the event concept Management information system 5_ 8 Huang Hong Identifying Events Guidelines for identifying events distinguishing an external event and conditions that leads up to the event, distinguishing an external event and system’s response tracking a transaction’s life cycle will help identifying events in sequence Ignoring technology-dependent events and system controls during analysis phase. ( e.g. logging on, database backup, change password etc.) System control: checks or safety procedures put in place to protect the integrity of the system Perfect technology assumption: the assumption that events should be included during analysis only if the system would be required to respond under perfect conditions(equipment never breaking down, capacity of processing and storage being unlimited, people operating the system being completely honest and never making mistakes), under this assumption, analysts can eliminate technology-dependent events during analysis phase. Management information system 5_ 9 Huang Hong Distinguishing Conditions versus events Management information system 5_ 10 Huang Hong Tracking transaction’s life cycle to identify events Management information system 5_ 11 Huang Hong Events in the Rocky Mountain Outfitters Case External events for the RMO customer support system Customer wants to check item availability Customer places an order Customer changes or cancels order Customer or management wants to check order status Shipping fulfills order Shipping identifies back order Customer returns item(defective, changed mind, full or partial returns) Prospective customer request catalog Customer updates account information Marketing wants to send promotional materials to customers Management adjusts customer charges(correct errors,make concessions) Merchandising updates catalog(add, change,delete,change price) Merchandising creates special product promotion Merchandising creates new catalog Management information system 5_ 12 Huang Hong Events in the Rocky Mountain Outfitters Case(cont) Temporal events for the RMO customer support system Time to produce order summary reports Time to produce transaction summary reports Time to produce fulfillment summary reports Time to produce prospective customer activity reports Time to produce customer adjustment/concession[让步] reports Time to produce catalog activity reports Look at each event: Event table What output(if any)is produced by the system Event Trigger Source Activity Response Destination Customer want to Item Look up item Item availability customer customer check item availability inquiry availability details How does the system know the event occurred: external event: data entering the system; temporal event: time arrived Management information system 5_ 13 Huang Hong Things and System Requirements To define system requirements involves understanding and modeling things that the system needs to store information about. In the object-oriented approach, these things are the objects that interact in the system. Types of Things Tangible things: such as products Intangible things: an order, a service call Relationship among Things Information about relationship among things are equally as important as information about things, such as an employee works at a specific department. Cardinality: the number of associations that occur between specific things. One to one; one to many; many to many Multiplicity: A synonym for cardinality, often used with the object-oriented approach. N-ary relationship[N元联系]: A term to describe how many things’s relationship is the relationship used to represent. Binary relationship; unary (recursive) relationship; ternary relationship; n-ary relationship Attributes of Things: an attribute is one piece of specific information about a thing. identifier (key) Compound attribute: address(city,street,apartment) Multi-value attribute:telephone number(another form of compound attribute) Management information system 5_ 14 Huang Hong Data Entities Data entities The things the system needs to store information about in the traditional approach to information systems ERD (entity-relationship diagram) A graphic modeling method used to describe data entities, the relation- ships between data entities, and the attributes of data entities and relationships. Cardinality symbols of relationships in ERD Exactly one (mandatory Zero or more (optional) 强制的) Zero or one (optional) One or more (mandatory) Management information system 5_ 15 Huang Hong The Entity-Relationship Diagram Example of data entity Cardinality symbols of relationships in ERD Entity name Customer Exactly one (mandatory) Zero or more (optional) Cust number* Key attribute Name Bill address Home phone Zero or one (optional) One or more (mandatory) attributes Office phone A weak entity set Customer Order Order item Cust number* Name Bill address Order ID* Item ID* Home phone Order date Quantity Office phone amount price Sample ERD Management information system 5_ 16 Huang Hong The Entity-Relationship Diagram Many to many relationship often involve Course additional data that must be stored. Example: if a student select a course, he/she will get a grade. Course number* title Where to store the grade? Credit hours Course section student section number* Student ID* Start time Name Room number major Sample ERD with many to many relationship Management information system 5_ 17 Huang Hong The Entity-Relationship Diagram Associative entity A data entity that represents a many to many relationship between two other data entities Course Course number* title Credit hours Course section Course student enrollment section number* Student ID* Start time Name Room number grade major Sample ERD with Associative entity Management information system 5_ 18 Huang Hong The Rocky Mountain Outfitters Case ERD Catalog package Product item Inventory Shipper item Return item Order item shipment Order Customer Order transaction Management information system 5_ 19 Huang Hong Objects and classes Objects A term used in object-oriented approach, similar to data entities in the traditional approach. The differences between them is that data entities only store information, the objects not only store information, but also do works, that is, they can process information themselves. objects have both attributes and behaviors. Class The type or classification to which all similar objects belong Methods: the behaviors all objects of the class are capable of. Encapsulation[封装]: covering or protecting each object so that it contains values for attributes and methods for operating on these attributes, making the object a self-contained [设备齐全的, 独立的]( and a protected) unit. Management information system 5_ 20 Huang Hong More issues about classes of objects Generalization[一般化]/specialization[特殊化] hierarchies Hierarchies that structure or rank classes from the more general superclass to the the more specialized subclass Inheritance[继承] A concept that allows subclasses to share characteristics of their superclasses[超类] Order Web Order Telephone Order Mail Order Management information system 5_ 21 Huang Hong More issues about classes of objects (cont) Aggregation[聚集] ( whole-part hierarchies) A relationship between an object and its parts Computer processor Monitor Main memory Disk storage Keyboard Management information system 5_ 22 Huang Hong The Class Diagram Class diagram In the object-oriented approach, we build class diagram to help understand things involved in a system. Because the class concept is different from data entities’s, the sets of requirements models for object-oriented approaches are quite different from the traditional approaches’s too. Examples of class diagram notation Customer The name of the class Name Address Attribute:all objects in the class have a value Phone for each of these Add new Delete Methods:what all objects of the class know Change how to do. Methods are not always shown in Connect to account the class symbol if they are fairly standard. Management information system 5_ 23 Huang Hong The Class Diagram Examples of class diagram notation (a bank account class diagram) Customer Account Name 1 0..* Account Number Address Balance Phone Date opened Make Deposit Make withdrawal Saving Account Checking Account Check style Interest Rate Minimum Balance Calculate interest Management information system 5_ 24 Huang Hong The rocky mountain outfitters case class diagram Inventory Item catalog Product Item Inventory ID Season Product ID 1..* 0..* Size Year Vendor Shipper Color Description Gendor 1 0..* Shipper ID Options EffectiveDate Description Name QuantityOnHand EndDate season Address 1..* AverageCost NormalPrice ContactNmae ReorderQuantity 1..* SpecialPrice Telephone 1 1 1 0..* 0..1 0..* 0..* Package 0..* Return Item Package ID Order Item Quantity Shipment Description Quantity Price Tracking No. SalePrice Price Reason 1..* 1 DateSent BackorderStatus Condition TimeSent Disposal ShippingCost 1..* DateArrived 0..* 1 TimeArrived Customer Order 1 Account No. Order ID Name Order Date Order Transaction Billing Address 1 0..* PriorityCode 1 1..* Date ShippingAddress Shipping&Handling Transaction Type DayPhone Tax Amount NightPhone GrandTotal PaymentMethod Web Order Telephone Order Mail Order EmailAddress PhoneClerk RepltMethod CallStartTime DateReceived LengthOfCall ProcessorClerk Management information system 5_ 25 Huang Hong Where you are headed Requirements models for the traditional approach and the object- oriented approach are quite different. The traditional approach takes the event table and create a set of DFDs based on the information in the table, including the context diagram, DFD fragments and detailed DFDs, ERD, data flow definitions and process descriptions. These will be discussed in chapter 6 The object-oriented approach takes the event table and create a set of use cases and use case diagrams, Class diagram,sequence diagrams, statechart diagrams. These will be discussed in chapter 7 Management information system 5_ 26 Huang Hong Requirements models for the traditional approach and the object-oriented approach object-oriented approach Events and traditional approach Event table Things Use case Class Entity-relationship Context diagrams Diagram diagram diagram DFD scenarios fragments Sequence Statechart Detail DFDs Diagram 0 diagrams diagrams Other OO Other models definitions Management information system 5_ 27 Huang Hong assignments P161 review questions Draw an ERD and a class diagram to represent the readers and books and their relationship in a library. Case study: the real estate （房地产） multiple listing service system Real estate agent（房地产经纪人） Real estate office（房地产事务所） asking price n.索价, 要价 Status code 状态码 Management information system 5_ 28 Huang Hong
"Modeling System RequirementsEvents and Things"