System Models in Software Engineering

System models in software engineering play a crucial role in analyzing and designing systems. They help in understanding requirements, behavior, and structure of systems, bridging the gap between analysis and design processes. Different perspectives like external, behavioral, and structural are used to model systems effectively. This lecture covers the importance of system modeling, various modeling techniques such as FSM, UML, and the need for clear and concise system requirements understandable by both technical and non-technical stakeholders.

• System Models
• Software Engineering
• Requirements Analysis
• Modeling Techniques

landyn Follow

Uploaded on Aug 04, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Lecture 7 System Models COMP201 - Software Engineering 1

2. Lecture Overview System models are abstract descriptions of systems whose requirements are being analysed Objectives - To explain why the context of a system should be modelled as part of the RE process To describe Behavioural modelling (FSM, Petri-nets), Data modelling and Object modelling (Unified Modelling Language, UML) COMP201 - Software Engineering 2

3. System Models User requirements must be written in such a way that non-technical experts can understand them, e.g., by using natural language Detailed system requirements may be expressed in a more technical way however One widely used technique is to document the system specification as a set of system models These are graphical representations which describe business processes and the system to be developed They are an important bridge between the analysis and design processes COMP201 - Software Engineering 3

4. System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers Different models present the system from different perspectives: External perspectiveshowing the system s context or environment Behavioural perspective showing the behaviour of the system Structural perspective showing the system or data architecture COMP201 - Software Engineering 4

5. A Picture Paints a Thousand Words CourseOffering Student -sectionNo : int -course : Course -instructor : Professor -schedule : String -location : String -maxEnrollment : int -enrollment : int -prerequisites : Set -major : String -classStanding : String -gpa : float -is taken by Person 0..* +setMajor() : void +setClassStanding() : void +computeGpa() : void #name : String #ssn : String #dob : Date #spouse : Person #children : Set -takes extends +CourseOffering() +setSectionNo() : void +setCourse() : void +setInstructor() : void +setSchedule() : void +setLocation() : void +setMaxEnrollment() : void +get...() +calcAvailable() : int 0..* +Person() +setName() : void +setSsn() : void +setDob() : void +setSpouse() : void +setChildren() : Set +getName() : String +getSsn() : String +getDob() : Date +getSpouse() : Person +getChildren() : Set +getAge() : int Professor -rank : String -tenureDate : Date -department : String extends +Professor() +setRank() : void +setTenureDate() : void +setDepartment() : void +getRank() : String +getTenureDate() : Date +getDepartment() : String 0..* -teaches 1..1 -is taught by COMP201 - Software Engineering 5

6. System Model Advantages They can be easier to understand than using a verbose natural language description System models can leave out unnecessary details of the system so way may focus on what is important A system representation should maintain all the information of a system An abstraction deliberately simplifies the system and picks out its most salient characteristics Different models can focus on different approaches to abstraction COMP201 - Software Engineering 6

7. System Model Weaknesses They do not model non-functional system requirements They do not usually include information about whether a method is appropriate for a given problem They may produce too much documentation System models are sometimes too detailed and difficult for users to understand COMP201 - Software Engineering 7

8. Model Types Data processing model - showing how the data is processed at different stages Composition model - showing how entities are composed of other entities Architectural model - showing principal sub-systems Classification model - showing how entities have common characteristics Stimulus/response model - showing the system s reaction to events COMP201 - Software Engineering 8

9. Context Models Context models are used to illustrate the boundaries of a system Identifying the boundaries of the system to be developed is not always straightforward Social and organisational concerns may affect the decision on where to position system boundaries Architectural models show the system and its relationship with other systems COMP201 - Software Engineering 9

10. Example Architectural Model of an ATM System Security system Branch accounting system Account database Auto-teller system Branch counter system Usage database Maintenance system COMP201 - Software Engineering 10

11. Process Models Process models show the overall process and the processes that are supported by the system Data flow models may be used to show the processes and the flow of information from one process to another COMP201 - Software Engineering 11

12. Example Process Model Equipment Procurement Process Delivery note Delivery note Equipment spec. Checked spec. Specify equipment required Accept delivery of equipment Check delivered items Validate specification Get cost estimates Spec. + supplier + estimate Installation instructions Order Equipment spec. notification Supplier list Place equipment order Supplier database Find suppliers Choose supplier Install equipment Order details + Blank order form Installation acceptance Accept delivered equipment Checked and signed order form Within system boundary Equipment details Equipment database COMP201 - Software Engineering 12

13. Behavioural Models Behavioural models are used to describe the overall behaviour of a system Two types of behavioural model Data processing models that show how data is processed as it moves through the system State machine models that show the systems response to events Both of these models are required for a description of the system s behaviour COMP201 - Software Engineering 13

14. Data-Processing Models Data flow diagramsare used to model the system s data processing These show the processing steps as data flows through a system IMPORTANT part of many analysis methods Simple and intuitive notation Show end-to-end processing of data COMP201 - Software Engineering 14

15. Example - Order Processing Data Flow Diagram Checked and signed order + order notification Completed order form Signed order form Signed order form Send to supplier Order details + blank order form Complete order form Validate order Record order Adjust available budget Order details Signed order form Order amount + account details Orders file Budget file COMP201 - Software Engineering 15

16. Data Flow Diagrams Data Flow Diagrams track and document how the data associated with a process is helpful to develop an overall understanding of the system Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment COMP201 - Software Engineering 16

17. Data Flow Diagrams Data Flow Diagrams have an advantage in that they are simple and intuitive and can thus be shown to users who can help in validating the analysis Developing data flow diagrams is usually a top-down process We begin by evaluating the overall process we wish to model before considering sub-processes Data flow diagrams show a functional perspective where each transformation represents a single function or process which is particularly useful during requirements analysis since it shows end-to-end processing. COMP201 - Software Engineering 17

18. DFD Context diagram Dried ingredients hoppers Numeric key pad Hot water system Hopper low signal Hot water Hopper on/off temperature Key codes Drink choice Electric element on/off Hot water valve open/close cup solenoid on/off Paper cup mechanism Drinks machine controller Holding vessel valve open/close cup in place Holding vessel Pricing information Availability information Service inforation Coin codes Service request Stirrer on/off Coin sense mechanism Alphanumeric display Stirrer Modem

19. Temperature control hot water element on/off Hot water temperature Key Pad Level 0 DFD service door open/closed key codes price and availability information Alpha display Coin Operation control Coin codes mechanism Hopper low? Hoppers cup solenoid drink code status cup in place? on/off drink made Hopper low? engineering codes ON/OFF Make drinks control hopper motors on/off Control service request hot water valve Maintenance mode control Sales data on/off Recipe data Drink sales holding vessel Service data data control Modem Sales data Drink recipes Sales log slide 19 3SFE519 S Coope 2004

20. service door closed open Key Pad Engineering codes key codes Control maintenance mode enable disable mode Password received Process key codes maintenance Alpha display Echo key codes Drink queue Alpha display Drink code Prompt for Product availability information Drink code payment Paid for Paid for Drink code Drink availability checker Drink dispense control Available Drink code Drink data Hoppers Hopper low? Drink recipes Coin Coin codes Coin mechanism mechanism reader Current Credit Credit Update Current Credit Level 1 DFD Operation control Credit Store COMP201 - Software Engineering 20 slide 20 3SFE519 S Coope 2004

21. Statechart Diagrams Statechart Diagrams (or State machine models ) show the behaviour of the system in response to external and internal events They show the system s responses to stimuli (the event- action paradigm) so are often used for modelling real-time systems Statechart diagrams show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another Statecharts are an integral part of the Unified Modeling Language (UML) COMP201 - Software Engineering 21

22. Statechart Diagrams An initial state is denoted by a solid circle and is optional (sometimes the system will start in different places and thus the initial state should be omitted). If required, a final state can also be used; this is denoted by a solid circle with a ring around it. We use a level of abstraction so that we can observe the essential behaviour of the system we want to model. Rounded rectangles are used for states. Each state contains two components, the state name and a brief description of the action performed in that state (see next slide). COMP201 - Software Engineering 22

23. Example - Microwave Oven Model Full power A state machine model does not show flow of data within the system Full power do: set power = 600 Timer Waiting do: display time Number Operation Set time do: get number exit: set time Full power do: operate oven Half power Half power Door closed Cancel Timer Door open Start Door open Waiting do: display time Half power do: set power = 300 Enabled do: display 'Ready' Door closed Disabled Q: Why is there no final state? do: display 'Waiting' COMP201 - Software Engineering 23

24. Microwave Oven Stimuli Stimulus Half power Full power Timer Number Door open Door closed Start Cancel Description The user has pressed the half power button The user has pressed the full power button The user has pressed one of the timer buttons The user has pressed a numeric key The oven door switch is not closed The oven door switch is closed The user has pressed the start button The user has pressed the cancel button COMP201 - Software Engineering 24

25. Statecharts Statecharts also allow the decomposition of a model into sub-models (see figure on next slide). A brief description of the actions is included following the do in each state (the word do is optional). Can be complemented by tables describing the states and the stimuli. COMP201 - Software Engineering 25

26. Statechart Diagram Operation Time Checking Cook OK do: check status do: run generator Emitter fault Turntable fault Timeout Done Alarm do: display event do: buzzer on for 5 secs. Door open Cancel Disabled Waiting COMP201 - Software Engineering 26

27. Statechart Diagrams The label on an arc can denote the method called to move from one state to the next (the event). A guard is used to ensure that the system only moves from one state to the other if the expression is satisfied. A state can contain a subdiagram within it (also called a composite state). This is useful for example when we wish to model a subsystem or substates. On the next slide, we can see all these elements of a UML statechart diagram COMP201 - Software Engineering 27

28. Statechart Diagrams Guard Actions Initial state Final state Composite States COMP201 - Software Engineering 28

29. Actions You can put actions after the event using a / Ink available/clear display Out of ink Idle Ink low/show error message COMP201 - Software Engineering 29

30. More hints on state charts Often have an Idle state where the process is not active All states need some exit (no deadlock, even in error conditions) Use multiple state charts to keep the design simple Do NOT need to have a state chart as sub state of other state chart System can be described by multiple state machines running concurrently COMP201 - Software Engineering 30

31. COMP201 - Software Engineering 31

32. Finite State Machines Finite State Machines (FSM), also known as Finite State Automata (FSA) are models of the behaviours of a system or a complex object, with a limited number of defined conditions or modes, where mode transitions change with circumstance. Question: What language does this FSA recognise? COMP201 - Software Engineering 32

33. Finite State Machines - Definition A model of computation consisting of a set of states, a start (initial) state, an input alphabet, and a transition function that maps input symbols and current states to a next state You may recall finite state machines (or automata) from COMP209. What language is recognised by this FSA? COMP201 - Software Engineering 33

34. Finite State Machines - Definition Computation begins in the start state with an input string. It changes to new states depending on the transition function. states define behaviour and may produce actions state transitions are movement from one state to another rules or conditions must be met to allow a state transition input events are either externally or internally generated, which may possibly trigger rules and lead to state transitions. COMP201 - Software Engineering 34

35. Lecture Key Points A model is an abstract system view. Complementary types of model provide different system information. Context models show the position of a system in its environment with other systems and processes. Data flow models may be used to model the data processing in a system. State machine models model the system s behaviour in response to internal or external events