©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 Object-oriented and Structured System Models

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 2 Objectives l To understand the context and the functionality of a system using different notations l To review some structured notations l To review some of the notations used in the Unified Modeling Language (UML)

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 3 3 A Bridge

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 4 System modeling l Models are used to communicate with stakeholders. l 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.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 5 Model types l Data processing model shows how the data is processed at different stages. l Composition model shows how entities are composed of other entities. l Architectural model shows principal sub-systems. l Classification model shows how entities have common characteristics. l Stimulus/response model shows the system’s reaction to events.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 6 Data-processing models l Data flow diagrams (DFDs) may be used to model the system’s data processing. These show the processing steps as data flows through a system. l DFDs are an intrinsic part of many analysis methods. Simple and intuitive notation that customers can understand.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 7 Order processing DFD

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 8 State machine models l State machine models model the behaviour of the system in response to external and internal events/stimuli. often used for modelling real-time systems. l These show system states as nodes events as arcs between nodes when an event occurs, the system moves from one state to another. l Used a lot in UML

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 9 9 The States of a System l state —a set of observable circumstances that characterizes the behavior of a system at a given time l state transition —the movement from one state to another l event —an occurrence that causes the system to exhibit some predictable form of behavior l action —process that occurs as a consequence of making a transition

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 10 Microwave oven model

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 11 Semantic data models l Semantic data models describe the logical structure of data processed by the system. l An entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes l Widely used in database design. Can readily be implemented using relational databases. l No specific notation provided in the UML but objects and associations can be used (VERY SIMILAR to CLASS HIERARCHY DIAGRAMs)

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 12 Example: Library semantic model

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 13 Object models l Object models describe the system in terms of object classes and their associations. l An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object. l Various object models may be produced Simple object models Inheritance models Aggregation models Interaction models.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide Object Model: Class Diagram Class name attributes operations

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide Class (Relationship) Diagram

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide CRC Modeling l Analysis classes have “responsibilities” Responsibilities are the attributes and operations encapsulated by the class l Analysis classes collaborate with one another Collaborators are those classes that are required to provide a class with the information needed to complete a responsibility. In general, a collaboration implies either a request for information or a request for some action.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide CRC Modeling

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 18 Inheritance models l Organize the domain object classes into a hierarchy. l Classes at the top of the hierarchy reflect the common features of all classes. l Object classes inherit their attributes and services from one or more super-classes. These may then be specialised as necessary.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 19 Library class hierarchy

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 20 User class hierarchy

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 21 Multiple inheritance

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 22 Object aggregation l An aggregation model shows how classes that are collections are composed of other classes. l Aggregation models are similar to the part-of relationship in semantic data models.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 23 Object aggregation

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 24 Object behaviour modelling l A behavioural model shows the interactions between objects to produce a behaviour that was specified as a use-case l Collaboration diagrams in UML are used to model interaction between objects Example: Sequence diagrams

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 25 Sequence diagrams l These show the sequence of events that take place during some user interaction with a system. l You read them from top to bottom to see the order of the actions that take place.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 26 Sequence diagram of ATM withdrawal