ƒ Entity Relationship Models ƒ Class Diagrams (& OO Analysis) ƒ Dataflow diagrams (& Structured Analysis) ƒ UML Activity Diagrams

Size: px

Start display at page:

Download "ƒ Entity Relationship Models ƒ Class Diagrams (& OO Analysis) ƒ Dataflow diagrams (& Structured Analysis) ƒ UML Activity Diagrams"

Clinton Ramsey
6 years ago
Views:

1 Lecture 6: Requirements II What to Model Last Last Week: Week: Enterprises Enterprises General General Issues Issues Human Human Activity, Activity, i* i* etc. etc. This This Week: Week: Modelling Modelling Information Information and and Behaviour Behaviour Information Information Structure Structure Information Information Flow Flow Behaviour Behaviour Information Structure ƒ Entity Relationship Models ƒ Class Diagrams (& OO Analysis) Processes and Information Flow ƒ Dataflow diagrams (& Structured Analysis) ƒ UML Activity Diagrams System Behaviour ƒ Statecharts ƒ Message Sequence Charts ƒ Tabular specifications (e.g. SCR) Next Next Week: Week: Non-functional Non-functional requirements requirements Modelling Modelling NFRs NFRs Analysis Analysis techniques techniques for for NFRs NFRs 1 2 Entity Relationship Diagrams ER diagrams ƒ widely used for information modeling ƒ simple, easy to use Note: this is a notation, not a method! Used in many contexts: ƒ domain concepts objects referred to in goal models, scenarios, etc. ƒ Data to be represented in the for information s ƒ Relational Database design ƒ Meta-modeling name age nationality Actor (0,n) Cast (1,n) Film (a,b) producer director title year Key Entity Attribute Relationship (c,d) Cardinality of relationship Identifier Composite Identifier Class name :patient 0..1 attributes Name Date of Birth 0..1 services Height Weight 0..1 generalization :In-patient Room Bed Physician aggregation :Out-patient Last visit next visit physician Class Diagrams multiplicities 1 :heart Normal bpm Blood type 1..2 :kidney Operational? 0..2 :organ :eye Colour Diameter Correction Natural/artif. Orig/implant donor 3 4 1

2 Generalization vs Aggregation Source: Examples from Bennett, McRobb & Farmer, 2002 Generalization ƒ Subclasses inherit attributes, associations, & operations from the superclass ƒ A subclass may override an inherited aspect Aggregation ƒ This is the Has-a or Whole/part relationship Composition ƒ Strong form of aggregation that implies ownership: if the whole is removed from the model, so is the part. the whole is responsible for the disposition of its parts aggregation Multiplicity A client has exactly one staffmember as a contact person :StaffMember staffname staff# staffstartdate Class associations Multiplicity A staff member has zero or more clients on Name His/her clientlist of the association 1 liaises with 0..* contact ClientList person :Client companyaddress company companyfax companyname companytelephone composition generalization Role The staffmember s role in this association is as a contact person Direction The liaises with association should be read in this direction Role The clients role in this association is as a clientlist 5 6 Association Classes Sometimes the association is itself a class ƒ because we need to retain information about the association ƒ and that information doesn t naturally live in the classes at the ends of the association E.g. a title is an object that represents information about the relationship between an owner and her car :car VIN(vehicle Id Number) YearMade Mileage 0..* owns 1 owner :title yearbought initialmileage PricePaid LicencePlate# :person Name Address DriversLicenceNumber PermittedVehicles Object Oriented Analysis Background ƒ Model the requirements in terms of objects and the services they provide ƒ Grew out of object oriented design But applied to modelling the application domain rather than the program Motivation ƒ OO is (claimed to be) more natural As a evolves, the functions (processes) it performs tend to change, but the objects tend to remain unchanged Hence a model based on functions/processes will get out of date, but an object oriented model will not hence the claim that object-oriented designs are more maintainable ƒ OO emphasizes importance of well-defined interfaces between objects compared to ambiguities of flow relationships NOTE: OO applies to requirements engineering because it is a modeling tool. But we are modeling domain objects, not the design of the new 7 8 2

3 Nearly anything can be an object External Entities ƒ that interact with the being modeled E.g. people, devices, other s Things ƒ that are part of the domain being modeled E.g. reports, displays, signals, etc. Occurrences or Events ƒ that occur in the context of the E.g. transfer of resources, a control action, etc. Roles ƒ played by people who interact with the Source: Adapted from Pressman, 1994, p242 Organizational Units ƒ that are relevant to the application E.g. division, group, team, etc. Places ƒ that establish the context of the problem being modeled E.g. manufacturing floor, loading dock, etc. Structures ƒ that define a class or assembly of objects E.g. sensors, four-wheeled vehicles, computers, etc. Some things cannot be objects: ƒ procedures (e.g. print, invert, etc) ƒ attributes (e.g. blue, 50Mb, etc) Coad-Yourdon ƒ Developed in the late 80 s ƒ Five-step analysis method Variants Shlaer-Mellor ƒ Developed in the late 80 s ƒ Emphasizes modeling information and state, rather than object interfaces Fusion ƒ Second generation OO method ƒ Introduced use-cases Unified Language (UML) ƒ Third generation OO method ƒ An attempt to combine advantages of previous methods 9 10 Example method: Coad-Yourdon Source: Adapted from Pressman, 1994, p242 and Davis 1990, p98-99 Five Step Process: 1. Identify Objects & Classes (i.e. is_a relationships) 2. Identify Structures (i.e. part_of relationships) 3. Define Subjects A more abstract view of a large collection of objects Each classification and assembly structure become one subject Each remaining singleton object becomes a subject (although if there a many of these, look for more structure!) Subject Diagram shows only the subjects and their interactions 4. Define Attributes and instance connections 5a. Define services - 3 types: Occur (create, connect, access, release) These are omitted from the model as every object has them Calculate ( a calculated result from one object is needed by another) Monitor ( an object monitors for a condition or event) 5b. Define message connections These show how services of one object are used by another Shown as dotted lines on object and subject diagrams Each message may contain parameters Unified Language Third generation OO method ƒ Booch, Rumbaugh & Jacobson are principal authors Still in development Attempt to standardize the proliferation of OO variants ƒ Is purely a notation No modeling method associated with it! ƒ But has been accepted as a standard for OO modeling But is primarily owned by Rational Corp. (who sell lots of UML tools and services) Has a standardized meta-model ƒ Use case diagrams ƒ Class diagrams ƒ Message sequence charts ƒ Activity diagrams ƒ State Diagrams (uses Harel s statecharts) ƒ Module Diagrams ƒ Platform diagrams

4 Evaluation of OOA Advantages of OO analysis for RE ƒ Fits well with the use of OO for design and implementation Transition from OOA to OOD smoother than from SA to SD (but is it?) ƒ Removes emphasis on functions as a way of structuring the analysis ƒ Avoids the fragmentary nature of structured analysis object-orientation is a coherent way of understanding the world Disadvantages ƒ Emphasis on objects brings an emphasis on static modeling although later variants have introduced dynamic models ƒ Not clear that the modeling primitives are appropriate are objects, services and relationships really the things we need to model in RE? ƒ Strong temptation to do design rather than problem analysis ƒ Fragmentation of the analysis E.g. reliance on use-cases means there is no big picture of the user s needs ƒ Too much marketing hype! and false claims - e.g. no evidence that objects are a more natural way to think 13 query 1. determine form of travel 3. reserve seats confirmation Dataflow Diagrams (DFDs) travel proposed booked 2. check proposed 4. issue Timetables Fare tables fares Notes: ƒ every process, flow, and store must be labeled ƒ representation is hierarchical each process will be represented separately as a lower level DFD ƒ processes are normally numbered for cross reference ƒ processes transform can t have the same flowing out of a process as flows into it Key process flow (no control implied) store external entity boundary 14 Level 0: Context Diagram confirmation ticket Hierarchies of DFDs query Level 1: Whole System 1. determine form of travel 3. reserve seats Level 2: subprocesses Level n: subprocesses Level n: subprocesses 3.1 check seating prefs 3.1 Proposed reservations 3.1 preferences preferences res. Request id. Req id. res. Request id. Request Req id. id. issue 3.3. Request id collate log confirm 3.2. confirmations track booked seat log timestamps confirmation timestamps track confirmation confirmation query travel proposed booked confirmation 2. check proposed 4. issue Timetables Fare tables fares 15 Structured Analysis Definition ƒ Structured Analysis is a -oriented approach to conceptual modeling ƒ Common feature is the centrality of the flow diagram ƒ Mainly used for information s variants have been adapted for real-time s process: Abstract (essential functions) Concrete (detailed model) indicative (existing ) 2. Current logical 1. Current physical optative (new ) 3. New logical 4. New physical ƒ Model of current physical only useful as basis for the logical model ƒ Distinction between indicative and optative models is very important: Must understand which requirements are needed to continue current functionality, and which are new with the updated 16 4

5 Variants Source: Adapted from Svoboda, 1990, p264-5 Structured Analysis and Design Technique (SADT) ƒ Developed by Doug Ross in the mid-70 s ƒ Uses activity diagrams rather than flow diagrams ƒ Distinguishes control from processing Structured Analysis and System Specification (SASS) ƒ Developed by Yourdon and DeMarco in the mid-70 s ƒ classic structured analysis Structured System Analysis (SSA) ƒ Developed by Gane and Sarson ƒ Notation similar to Yourdon & DeMarco ƒ Adds access diagrams to describe contents of stores Structured Requirements Definition (SRD) ƒ Developed by Ken Orr in the mid-70 s ƒ Introduces the idea of building separate models for each perspective and then merging them Incoming Control Activity Name ID ID Name Transformed Performing mechanism Name ID Name 17 Example method: SASS Source: Adapted from Davis, 1990, p Study current environment ƒ draw DFD to show how flows through current organization ƒ label bubbles with names of organizational units or individuals 2. Derive logical equivalents ƒ replace names (of people, roles, ) with action verbs ƒ merge bubbles that show the same logical function ƒ delete bubbles that don t transform 3. Model new logical ƒ Modify logical DFD to show how info will flow once new is in place but don t distinguish (yet) which components will be automated 4. Define a number of automation alternatives ƒ document each as a physical DFD ƒ Analyze each with cost/benefit trade-off ƒ Select one for implementation ƒ Write the specification 18 Evaluation of SA techniques Source: Adapted from Davis, 1990, p174 Advantages ƒ Facilitates communication. ƒ Notations are easy to learn, and don t require software expertise ƒ Clear definition of boundary ƒ Use of abstraction and partitioning ƒ Automated tool support e.g. CASE tools provide automated consistency checking Disadvantages ƒ Little use of projection even SRD s perspectives are not really projection ƒ Confusion between modeling the problem and modeling the solution most of these techniques arose as design techniques ƒ These approaches model the, but not its application domain ƒ Timing issues are completely invisible UML Activity Diagrams [failed] Cancel Authorize Payment Receive [succeeded] Dispatch [for each line * item on order] Check Line Item [in stock] Assign to Reorder Item [need to reorder]

6 Finance Authorize Payment Activity Diagram with Swimlanes [failed] [succeeded] [stock assigned to all line items and payment authorized] Cancel Dispatch Receive Check Line Item [in stock] * [for each line item on order] Assign to [need to reorder] Processing Reorder Item Choose Outstanding Items * [for each chosen order item] Assign Goods to [all outstanding order items filled] Stock Manager Receive Supply Add Remainder to Stock age :person [age < 18] [age < 65] child [age = 18] adult [age = 65] senior Statecharts Real world object vs. System representation recordbirth() /setdob() child [nowyear-birthyear>18] adult [nowyear-birthyear>65] senior recorddeath() /setdateofdeath() deceased :person dateofbirth dateofdeath recordbirth() setdob() recorddeath() setdateofdeath() States and Transitions A state represents a time period during which ƒ A predicate is true e.g. (budget - expenses) > 0, ƒ An action is being performed, or an event is awaited: e.g. checking inventory for order items e.g. waiting for arrival of a missing order item A state can be on or off. ƒ When a state is on, all its outgoing transitions are eligible to fire. ƒ Transitions take the form: event(parameters) [guard] / action For a transition to fire, its event must occur and its guard must be true. When a transition fires, its action is carried out. States can have associated activities: ƒ do/activity carries out some activity for as long as the state is on ƒ entry/action and exit/action carry out the action ever the state is entered (exited) ƒ include/statediagramname calls another state diagram, allowing state diagrams to be nested 23 Events Events are happenings the needs to know about ƒ Must be relevant to the (or object) being modelled ƒ Must be modellable as an instantaneous occurance (from the s point of view) E.g. completing an assignment, failing an exam, a crash ƒ Are implemented by message passing in an OO Design In UML, there are four types of events: ƒ Change events occur a condition becomes true denoted by the keyword e.g. [balance < 0] ƒ Call events occur an object receives a call for one of its operations to be perfomed ƒ Signal events occur an object receives an explicit (real-time) signal ƒ Elapsed-time events mark the passage of a designated period of time e.g. after[10 seconds] 24 6

7 Superstates States can be nested, to make diagrams simpler ƒa superstate consists of one or more states. ƒsuperstates make it possible to view a state diagram at different levels of abstraction. OR superstates ƒ the superstate is on, only one of its substates is on employed probationary full after [6 months] AND superstates (concurrent substates) ƒ When the superstate is on, all of its states are also on ƒ Usually, the AND substates will be nested further as OR superstates employed on payroll assigned to project createrecord() unborn unmarried single Hierarchical Statecharts registerbirth()/ setdateofbirth() working age widowed divorced adult [age>65] child [age>17] spouse. registerdeath() registerdivorce() senior registerdeath() [ addr = spouse.addr] registermarriage()/setspouse() partnered married separated [ addr spouse.addr] deceased registerdeath() Checking your Statecharts UML Sequence Diagrams Consistency Checks ƒ All events in a statechart should appear as: operations of an appropriate class in the class diagram and incoming messages for this object on a collaboration/sequence diagram ƒ All actions in a statechart should appear as: operations of an appropriate class in the class diagram and outgoing messages for this object on a collaboration/sequence diagram Style Guidelines ƒ Give each state a unique, meaningful name ƒ Only use superstates the state behaviour is genuinely complex ƒ Do not show too much detail on a single statechart ƒ Use guard conditions carefully to ensure statechart is unambiguous Statecharts should be deterministic (unless there is a good reason) You probably shouldn t be using statecharts if: ƒ you find that most transitions are fired the state completes ƒ many of the trigger events are sent from the object to itself ƒ your states do not correspond to the attribute assignments of the class 27 Time Initiator :Person condition Call() What s up?() Give mtg details() Staff :Person Respond() [for all participants] *Inform() Acknowledge() [for all participants] *Remind() Prompt() [decision=ok] ScheduleOK ed() participating object iteration Acknowledge() Show () Scheduler :Person [for all participants] *Inform() Participant :Person 28 7

8 VariableTypeInitial ValueUnitsWarningFlagbooleanfalse-OtherFlagbooleantrueFudgelevelenumeratedone-Waterlevelreal0.0mtemperaturereal0.0degrees CBlipCounterinteger0milesTimeNowreal100.0secAirBrakeAccreal0.0m/sec TypeBaseTypeValuesUnitsWarningLevelenumeratedlow,med,high-Temperatureinteger degrees CWaterlevelinteger0..100metersFlagenumeratedon, off- ConstantTypeValueUnitsLowTempinteger15degrees CHighTempinteger23degrees CMaxTimeOutinteger300millisecReferenceSafetyLevelsafetytypelow-TempMargininteger5degrees C ModesEventsNoFailuretruefalseACFailuretemp > temp0 Four Variable Model: Tabular Specifications: SCR Monitored Variables Dictionaries: System Monitored/Controlled Variables Types Constants input input devices items software Mode Transition Tables CurrentModePoweredonToo ColdTemp OKToo Hot ModeOff@T-t-Ina output items Tables: output devices ModesEventsNoFailurefalsetrueACFailure, HeatFailuretruefa Controlled Variables CurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff@T-t-Inactive@Tt--Heat@T--tACInactive@F---Off-@T--Heat---@TACHeat@F---Off--@T-InactiveAC@F---Off--@T-Inactive Event Tables CurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff@T-t-Inactive@Tt--Heat@T--tACInactive@F---Off-@T--Heat---@TACHeat@F---Off--@T-InactiveTimeout@F---No Failure-ff@TACFailure Condition Tables ModesEventsNoFailure@T(INMODE)neverBlah@T(thingy)@ Enviroment Enviroment also: Assertions, Scenarios,... ModesEventsNoFailure@T(INMODE)neverSensorFail@T(reset=on)@T(INMODE)TimeoutalwaysneverACFailure, HeatFailurenever@T(INMODE)Warning light =OffOn ModesEventsNoFailure@T(INMODE)neverBlah@T(thingy)@T(other)DoodahneveralwaysACFailure, HeatFailurenever@T(INMODE)Heater =OffOn SCR basics Modes and Mode classes ƒ A mode class is a finite state machine, with states called modes Transitions in each mode class are triggered by events ƒ Complex s are described using a number of mode classes operating in parallel System State ƒ A () state is defined as: the is in exactly one mode from each mode class and each variable has a unique value Events ƒ An event occurs any entity changes value An input event occurs an input variable changes value Single input assumption - only one input event can occur at once means c changed from false to true ƒ A conditioned event is an event with a WHEN d means: c became true c was false and d was true SCR Specification 29 Source: Adapted from Heitmeyer et. al SCR Tables Mode Class Tables ƒ Define the set of modes (states) that the software can be in. ƒ A complex will have many different modes classes Each mode class has a mode table showing the conditions that cause transitions between modes ƒ A mode table defines a partial function from modes and events to modes Event Tables ƒ An event table defines how a term or controlled variable changes in response to input events ƒ Defines a partial function from modes and events to variable values Condition Tables ƒ A condition table defines the value of a term or controlled variable under every possible condition ƒ Defines a total function from modes and conditions to variable values Example: Temp Control System Mode transition table: Current Powered Too Cold Temp OK Too Hot New Mode Mode on - t - t t AC Off - - Heat - - AC Off - - Inactive Off - - Inactive Source: Adapted from Heitmeyer et. al Source: Adapted from Heitmeyer et. al

9 Mode transition table: Failure modes Current Mode Powered on Cold Heater Too Cold Warm AC Too Hot New Mode NoFailure t - - HeatFailure t - t ACFailure HeatFailure t - - NoFailure ACFailure t - t NoFailure Event table: Modes never ACFailure, HeatFailure Warning light = Off On Consistency Checks in SCR Syntax ƒ did we use the notation correctly? Type Checks ƒ do we use each variable correctly? Disjointness ƒ is there any overlap between rows of the mode tables? ensures we have a deterministic state machine Coverage ƒ does each condition table define a value for all possible conditions? Mode Reachability ƒ is there any mode that cannot ever happen? Cycle Detection ƒ have we defined any variable in terms of itself? Source: Adapted from Heitmeyer et. al

Requirements & Domain Models. Lecture 13: Object Oriented Modelling. Nearly anything can be an object. Object Oriented Analysis

Requirements & Domain Models. Lecture 13: Object Oriented Modelling. Nearly anything can be an object. Object Oriented Analysis Lecture 3: Object Oriented Modelling Object Oriented Analysis Rationale Identifying Classes Attributes and Operations Class Diagrams Associations Multiplicity Aggregation Composition Generalization Easterbrook