1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 4 - System modelling Dr Richard Clayton & Dr Marian Gheorghe Module (1 st part) homepage

2COM6030 Systems Analysis and Design © University of Sheffield 2005 Outline  Modelling concepts.  Why use models in software development?  Types of model  Abstract models  Concrete (representational) models  Role of modelling  The UML Reading: Somerville chapter 7, Bennett chapter 5.

3COM6030 Systems Analysis and Design © University of Sheffield 2005 First part of the course “An abstract model (or conceptual model) is a theoretical construct that represents … processes, with a set of variables and a set of logical and quantitative relationships between them. Models in this sense are constructed to enable reasoning within an idealized logical framework about these processes and are an important component of scientific theories. Idealized here means that the model may make explicit assumptions that are known to be false in some detail, but by their simplification of the model allow the production of acceptably accurate solutions” Wikipedia. Models

4COM6030 Systems Analysis and Design © University of Sheffield 2005 Models of software systems Model Ambiguity Business process Software system Models can provide a way to specify clearly system design, architecture, function Models aid communication between client and designer Resolve ambiguities using a clearly specified and standard set of modelling tools Models aid understanding of Functionality of the system How well a software system matches the desired process

5COM6030 Systems Analysis and Design © University of Sheffield 2005 Models of software systems  Ease project management tasks.  Can provide complete views of a system, as well as detailed views of subsystems.  Clarify structures and relationships.  Offer a communication framework for ideas within and between teams.  Can generate new ideas and possibilities.  Allow quality assurance and testing scenarios to be generated.  Are platform independent.

6COM6030 Systems Analysis and Design © University of Sheffield 2005 Models of software systems Models can be used to describe different aspects of a system  All models are developed from a particular perspective  External perspective shows context of system and relationship to environment (e.g. other systems in the business).  Behavioural perspective shows dynamic and functional aspects of the system (e.g. how data structures are processed).  Structural perspective shows the structure of the system and data (e.g. relationships between components of the system and data structures).  Models may be abstract (simplified) or concrete (detailed).

7COM6030 Systems Analysis and Design © University of Sheffield 2005 Example – different perspectives Account database User Maintenance system Security system ATM Model of ATM showing external perspective. Abstract model with no detail Model of cash withdrawal from ATM shows behavioural perspective. Could show considerably more Authenticate user Prompt for operation Select withdrawal Prompt for amount Enter amount Return card to user

8COM6030 Systems Analysis and Design © University of Sheffield 2005 Abstract models  Abstract models provide an overview (abstraction) of an entire system, and shows the most important aspects.  Details are not included.  Abstract models are most useful in the requirements analysis and design stages. e.g., Context (external) model for ATM, is an abstract model of the system environment

9COM6030 Systems Analysis and Design © University of Sheffield 2005 Concrete models During design, models become  Less abstract and more concrete.  More formal.  More detailed. These models represent the system, and maintain all (most) of the information about the entity that is being modelled. e.g. detailed class model for the bank account of an ATM user. This type of model is important in the design, implementation, and testing stages of software development. Account -acNumber:int(frozen) -acHolder:String(frozen) -encodedPIN:int #currentBallance:int -overdraftLimit:int -acFrozen:boo -charges:ChargeTable +getNumber():int +getHolder():int +matchPIN(p:PIN):bool +getBallance(): int +makeDeposit(a:int):bool +makeWithdrawal(a:int):bool +isFrozen():bool

10COM6030 Systems Analysis and Design © University of Sheffield 2005 Role of models  Modelling is used for design of software systems before coding begins.  Models are essential for large projects, and valuable for smaller ones.  Diagrams and models are used in other areas of engineering.  Models aid documentation.  Models enable modular architecture to be developed.  Modular approach enables code re-use.  CASE tools enable code generation from model diagrams.

11COM6030 Systems Analysis and Design © University of Sheffield 2005 Types of models Natural language models.  Useful for gathering requirement details.  Natural language is inherently ambiguous, aim for structured approach.  Can be over flexible and long. Diagrammatic models.  Can be ad hoc, or follow a specific notation with clearly defined syntax.  Can show static or dynamic relationships and behaviours. Formal descriptions  State based models using formal algebraic and logical approach. Combinations

12COM6030 Systems Analysis and Design © University of Sheffield 2005 Natural language & diagrammatic model - ATM 1. User inserts credit/debit card into slot. 2. System authenticates user PIN. 3. If PIN is invalid then system displays error message and returns card. 4. System displays list of options and user makes selection. 5. If user selection is incorrect then system displays error message and then displays list of options again. 6. If user selects cash withdrawal then 6.1 System asks user to enter amount of cash to be withdrawn, and user enters selection. 6.2 System checks that amount entered does not exceed amount contained in cash dispenser, and amount in user’s account. 6.3 System dispenses cash to user. etc. Authenticate user Prompt for operation Select withdrawal Prompt for amount Enter amount Return card to user Diagrammatic model

13COM6030 Systems Analysis and Design © University of Sheffield 2005 Complementary models  Context models show the relationships of the system to other systems, and are used to establish the system boundaries.  Behavioural models show the processes that are supported by the system.  Data flow diagrams show the flow of information from one process to another. Can be easily understood by client.  Statechart models show how the states of the system change in response to external or internal stimuli.  Object models show attributes, methods and relationships of object classes within the system. During software system development, these types of model will evolve. It is critical that they remain consistent with each other, so that they aid the development process rather than hindering it. There are several modelling approaches that aim to achieve this.

14COM6030 Systems Analysis and Design © University of Sheffield 2005 Unified Modelling Language  UML is the standard diagrammatic notation for documenting object-oriented software systems.  UML is a descriptive modelling language, and not a methodology; there is no notion of a development process.  UML can be used as a notation for many different software development methodologies.  UML has a syntax, which defines diagrams that are legal, and a semantics, which defines what a legal diagram means.  UML’s notion of syntax and semantics is informal.  Varying interpretations: Analysis models of the perceived world versus design models documenting implementations. Why unified? UML is the result of a notation obtained from three development methods popular in the early 90s: OMT (Rumbaugh), Booch’s methods and OOSE (Jacobson)

15COM6030 Systems Analysis and Design © University of Sheffield 2005 Diagrams used in UML Static models: show the structure of a system  Use case diagram - requirements capture  Class diagram - analysis, design, implementation  Object diagram - detailed design, implementation  Component diagram - implementation, packaging  Deployment diagram - implementation, distribution Dynamic models: show the behaviour of a system  Activity diagram - analysis, distributed design  Statechart diagram - unit design, testing  Sequence diagram – analysis, detailed design, testing interaction  Collaboration diagram - analysis, detailed design, testing diagrams Extension mechanisms: adornments to diagrams  stereotypes, constraints, tagged values  OCL - object constraint language

16COM6030 Systems Analysis and Design © University of Sheffield 2005 Scope of UML UML is a huge and detailed specification. It is a standard notation with a wide user community. UML is mainly used for  Object oriented analysis  Use cases and scenarios.  Use case realisation and object identification.  Activity/sequence diagrams for expressing control mechanisms  Class diagrams for conceptual modelling.  Object oriented design  Static models, class diagrams, object attributes and associations.  Dynamic models, interaction diagrams.

17COM6030 Systems Analysis and Design © University of Sheffield 2005 System views  Use case view: forces that shape the system's architecture, in terms of use case diagrams and activity diagrams (interaction diagrams)  Design view: functional requirements of system, in terms of classes, interfaces, collaborations, interaction and statechart diagrams (also activity diagrams)  Process view: concurrency and synchronisation of system, using same diagrams as design view with emphasis on performance, scalability, throughput  Implementation view: physical realisation of system, in terms of components, files, using component and package diagrams (also interaction, activity diagrams)  Deployment view: system's hardware topology, the distribution of elements to nodes, using deployment diagrams (also interaction, statechart, activity diagrams)

18COM6030 Systems Analysis and Design © University of Sheffield 2005 System views offered by UML UML provides a standard for visualising, constructing and documenting software systems  Abstract: Business process, requirements, system function  Concrete: Classes, associations, components  UML is a widely used modelling language, and you should be familiar with the main ideas.  UML provides ‘blueprints’ for software.  UML does not solve all the problems of software development, remember it is a notation not a methodology. Design View Implementation View Process View Deployment View Use Case View

19COM6030 Systems Analysis and Design © University of Sheffield 2005 Summary  Models are abstract representations of software systems.  Models aid development of systems by clarifying function, architecture, design, and process.  Models show different but complementary perspectives of a system.  Models may be expressed in natural language, or as systems of diagrams.  The Unified Modelling Language (UML) is a standard notation for modelling object-oriented systems.  UML is a notation not a methodology.