System Models-Basics of Software Engineering-Lecture Slides, Slides of Software Engineering

Download System Models-Basics of Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity! 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 Modeling Language, UML) 1 COMP201 - Software Engineering docsity.com 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 2 docsity.com 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 5 docsity.com 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 6 COMP201 - Software Engineering docsity.com 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 7 COMP201 - Software Engineering docsity.com 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 10 COMP201 - Software Engineering docsity.com Example Process Model Get cost estimates Accept delivery of equipment Check delivered items Validate specification Specify equipment required Choose supplier Place equipment order Install equipment Find suppliers Supplier database Accept delivered equipment Equipment database Equipment spec. Checked spec. Delivery note Delivery note Order notification Installation instructions Installation acceptance Equipment details Checked and signed order form Order details + Blank order form Spec. + supplier + estimate Supplier list Equipment spec. 11 COMP201 - Software Engineering Within system boundary Equipment Procurement Process docsity.com 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 12 COMP201 - Software Engineering docsity.com 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 15 COMP201 - Software Engineering docsity.com 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. 16 COMP201 - Software Engineering docsity.com Example: Assignment Hand In  Exercise: Draw a Data Flow Diagram for how an assignment is completed and submitted in our department. What are the data sources used? What are the processes involved? COMP201 - Software Engineering 17 docsity.com 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). 20 COMP201 - Software Engineering docsity.com Example - Microwave Oven Model Full power Enabled do: operate oven Full power Half power Half power Full power Number Timer Door open Door closed Door closed Door open Start do: set power = 600 Half power do: set power = 300 Set time do: get number exit: set time Disabled Operation Timer Cancel Waiting do: display time Waiting do: display time do: display 'Ready' do: display 'Waiting' A state machine model does not show flow of data within the system 21 COMP201 - Software Engineering Q: Why is there no final state? docsity.com Microwave Oven Stimuli Stimulus Description Half power The user has pressed the half power button Full power The user has pressed the full power button Timer The user has pressed one of the timer buttons Number The user has pressed a numeric key Door open The oven door switch is not closed Door closed The oven door switch is closed Start The user has pressed the start button Cancel The user has pressed the cancel button 22 COMP201 - Software Engineering docsity.com 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 25 COMP201 - Software Engineering docsity.com Statechart Diagrams 26 COMP201 - Software Engineering Initial state Final state Composite States Guard Actions docsity.com 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. 27 COMP201 - Software Engineering Question: What language does this FSA recognise? docsity.com