Download
1 / 47
470 likes | 504 Views
Requirements Analysis. objectives To explain why the context of a system should be modelled as part of the Requirements Engineering (RE) process To describe behavioural modelling, data modelling and object modelling To introduce some of the notations used in the Unified
E N D
Requirements Analysis objectives To explain why the context of a system should be modelled as part of the Requirements Engineering (RE) process To describe behavioural modelling, data modelling and object modelling To introduce some of the notations used in the Unified Modeling Language (UML)
Introduction • User requirements must be written in natural language because they have to be understood by people who are not technical experts. • More detailed system requirements may be expressed in a more technical way. • One widely used technique is to document the system specification as a set of system models, that is a graphical representation that describe • the problem to be solved, and • the system that is to be developed
Structured methods • They provide a framework for detailed system modelling as part of REA. 1. Structured systems analysis (DeMarco 1978) 2. Object-oriented analysis (Rumbaugh et. al. 1991; Booch, 1994) • Incorporate system modelling as an inherent part of the method. • Methods define • a set of models, • a process for deriving these models, and • rules and guidelines that should apply to the models. • CASE tools support system modelling as part of a structured method.
Structured analysis methods weaknesses 1. They do not model non-functional system requirements 2. They do not usually include information about whether a method is appropriate for a given problem 3. The may produce too much documentation 4. The system models are sometimes too detailed and difficult for users to understand
System modelling • System models are abstract descriptions of systems whose requirements are being analysed. • 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 perspective showing the system's context or environment. • Behavioural perspective showing the behaviour of the system. • Structural perspective showing the system or data architecture.
Representation vs. Abstraction • The most important aspect of a system model is that it leaves out detail. • A system model is an abstraction rather then an alternative representation of the system. • A representation should maintain all the information about the entity being represented. • An abstraction deliberately simplifies and picks out the most salient characteristics.
Model types During the analysis process one may produce: • 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
Context models • At the early stage in the requirements elicitation and analysis process you should decide on the boundaries of the system. • Context models are used to illustrate the boundaries of a system - they show what lies outside the system boundaries. • Social and organisational concerns may affect the decision on where to position system boundaries. • Once some decisions on the boundaries of the system have been made, the next step is: • the definition of that context, and • the dependencies that a system has on its environment. • Producing a simple architectural model is the first step in this activity.
Architectural model • Architectural models show the environment of a system but not its relationship with other systems. • They use block diagrams where each sub-system is represented by a named rectangle, and lines indicate some associations between sub-systems. • Simple architectural models are supplemented by other models, such as: • process models - show the overall process and the processes that are supported by the system • data-flow models - show how data is transferred between the processes Example: equipment procurement process.
Example: Process model of equipment procurement Delivery note Equip. spec. checked spec. Delivery note Specify equipment required Check delivered items Accept delivery of equipment Validate specification Get cost estimate Equip. spec. Installation instructions spec. + estimate Order notification Supplier list Install equipment Supplier database Find suppliers Choose supplier Place order Order details + bank order form Installation acceptance Accept delivered equipment Checked & signed order form Equipment details Equipment database
Behavioural models • Used to describe the overall behaviour of a system. • Concerned with casual issues, connecting an event to a response via any necessary conditions. • Two types of behavioural models are shown here: 1. Data processing models show how data is processed as it moves through the system. 2. State machine models show the system's response to events. • These models show different perspectives so both of them are required for a description of the system's behaviour.
Data-processing models • Data flow diagrams (DFD) are used to model the system's data processing. • intrinsic part of many analysis methods • show the processing steps as data flows through a system • show end-to-end processing of data • simple and intuitive notation that customers can understand: • rounded rectangles represent processing steps • arrows annotated with the data name represent flows • rectangles represent data stores or data sources
Data flow diagrams • DFDs model the system from a functional perspective, tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system. • A DFD shows two things: 1. which processes and data stores can exist in the system 2. which communications among processes, stores, and external entities can exist • A DFD does not give behaviour information, such as when processes are created or deleted and when these communications take place. • Example: order processing DFD (Data Flow Diagram).
State Machine models • We can start by looking for states or for events. • If we are looking for states, we search for: • wait states, and • activity states • If we are looking for events, we search for: • named events, • condition change events, and • temporal events • To identify parallelism: • We search for combinations of events whose sequence we cannot determine with certainty. These events are to be modeled as parallel events. • To identify hierarchy: • We identify states that respond similarly to the same event. We can introduce a superstate to handle this event.
Events and Actions • To find a behaviour description of the system: • We start with the desired activities of the composite system to be supported by the system. • From these, we derive the desired event - action pairs. • These can be expanded into sets of transactional pairs that can be transformed into system stimulus-response pairs by linking events to stimuli and responses to actions.
State machine models • These model the behaviour of the system in response to external and internal events. • They show the system's responses to stimuli so are often used for modelling real-time systems. • State machine models show • system states as nodes and • state transitions (events) as arcs between these nodes. • When an event occurs, the system moves from one state to another. • The two main variants are Mealy diagram, and State Charts (an integral part of the UML)
Mealy diagrams • The rounded rectangles represent states and the arrows represent state transitions • A state transition arrow must have a label of the form: event expression [guard expression]/action expressions • Any of these elements can be omitted but the slash must always be present. • The initial state of a diagram is pointed at by an arrow departing from a bullet ●→ possibly labeled by an initialising action but not by an event or guard • there must be exactly one initial state in a diagram. • A final state is represented by a bull's eye • there may be any number of final states (including none) in a diagram.
Mealy diagrams • event_expression denotes a named event or temporal event • guard_expression denotes a condition. It can be a combination of more elementary conditions using AND, OR, NOT. • if absent, as in e/a, we take this as shorthand for e[true]/a • action_expressions denote a collection of actions to be executed. • Multiple action expressions are separated by commas if they are executed simultaneously and by semicolons if they are executed sequentially
Meaning of S → T e[g]/a • When • the behaviour is in state S, • the event e occurs and • the guard g is true • Then • the actions a are performed, and • the behaviour changes from state S to state T • When the event occurs but the guard is not true, the actions are not performed and the transition does not happen.
Example • When the end time 4pm occurs and the controller is in the state Heating, the controller responds by sending a switch off and a finish message. • When it is in state Not Heating, it only sends the finish message.
Statecharts • State machine models are an integral part of real-time design methods such as that proposed by Ward & Mellor (1985) and Harel (1988). • Harel's method uses a notation called statecharts • Statecharts are now an integral part of the UML. • Statecharts extend Mealy diagrams with three techniques: 1. state reaction 2. state hierarchy 3. parallelism
Statecharts • Allow the decomposition of a model into sub-models (see following slide). • A brief description of the actions is included following the do in each state. • Can be complemented by tables describing the states and the stimuli.
State reactions • A state reaction is defined by an event list attached to a state. • Two special events that can be used in this list are the entry and exit of the state. • Useful in specifying behaviour that does not cause state change. • In case of conflict, transitions have priority over state reactions. • The three possible state event list entries are:
State hierarchy • The states of a behaviour form a hierarchy if being in one state implies being in another state. • This allows us to represent transitions that leave a set of states by a single arrow leaving a higher-level state. • If the behaviour is in state S, it is also in all superstates of S and in exactly one substate of S (OR-state). • If the behaviour is in an OR-state, it is in exactly one of its children states.
Parallelism • Parallelism can be expressed by a special kind of node: the AND-state node. • An AND-state node can be indicated by partitioning using dashed lines • Each substate is named and the compound state itself has a name too. • If the behaviour is in an AND-state, it is in all of its children states. • A hyperedge is an edge that has more than one source or more than one target. • We need an hyperedge if we want to enter an AND-state in other substates than its default substates.
Decomposition • Statecharts allow the decomposition of a model into sub-models. • UML notation: • rounded rectangles to represent system states. They include a brief description (following do) of the actions taken in that state. • labelled arrows to represent stimuli which force a transition from one state to another. • can be complemented by tables describing the states and the stimuli.
time Operation Checking Cook ok Do: check status Do: run generator Time out Fault types Done Alarm Do: buzzer on for 5 sec Do: display event Door open cancel Waiting Disabled Example: an oven with a timer
Semantic data models • Semantic data models are used to describe the logical structure of data processed by the system. • Entity-relation-attribute model (ERA) sets out the entities in the system, the relationships between these entities and the entity attributes. • Widely used in database design. • Can readily be implemented using relational databases. • Sometimes used to model the detailed form of the data stored in a system. • No specific notation provided in the UML but objects and associations can be used.
The Entity-Relationship Diagram - ERD • The basic elements are defined as follows: • entities are real world objects with common properties; • a relationship is a class of elementary facts relating two or more entities; • attributes are classes of values that represent atomic properties of either entities or relationships
Data dictionaries • Data dictionaries are lists of all of the names used in the system models. • Descriptions of the entities, relationships and attributes are also included. • Advantages: • Support name management and avoid duplication. • Store of organisational knowledge linking analysis, design, implementation and evolution. • Many CASE workbenches support data dictionaries.
Object models • Object models describe the system in terms of object classes. • An object class is an abstraction over a set of objects with • common attributes • and the services (operations) provided by each object. • Various object models may be produced: • Inheritance models • Aggregation models • Interaction models
Object models • Object models are natural ways of reflecting the real-world entities manipulated by the system. • More abstract entities are more difficult to model using this approach. • Object class identification is recognised as a difficult process requiring a deep understanding of the application domain. • Object classes reflecting domain entities are reusable across systems.
Inheritance models • Organise the domain object classes into a hierarchy. • Classes at the top of the hierarchy reflect the common features of all classes. • Object classes inherit their attributes and services from one or more super-classes; • these may then be specialised as necessary. • Class hierarchy design is a difficult process if duplication in different branches is to be avoided.
Inheritance models • Inheritance is referred to as generalisation and is shown 'upwards' rather than 'downwards' in a hierarchy. • One can distinguish: Library class hierarchy and User class hierarchy. • Simple inheritance: a class inherits from a single superclass. • Multiple inheritance: a class inherits from multiple superclasses. • Can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics. • Makes class hierarchy reorganisation more complex.
Object aggregation • Aggregation model shows how classes which are collections are composed of other classes. • Similar to the part-of relationship in semantic data models. • Example: an aggregate object representing a course: • assignment, slides, lecture notes, exercises, solutions...
Object behaviour modelling • A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use-case. • In UML behaviours are modelled using scenarios based on use-cases to produce sequence diagrams to show the sequence of messages exchanged by objects UML uses collaboration diagrams • Example: Issue of electronic items (from class 3 slides).
Sequence diagram Item: Library item Books: catalog Bookshop supplier Cataloguer: Library staff Acquire new Catalog item dispose Uncatalog item • Objects and actors are aligned along the top of the diagram. • Object : Class • Labelled arrows indicate operations • The sequence of operations is from top to bottom.
