Software Engineering I Session 4 Software Modelling Recap

Software Engineering I Session 4 Software Modelling

Recap • Fundamental development activities – – specification development validation maintenance • Requirement engineering – Elicitation, specification, validation • This week – A bridge between specification and development …

Models and Abstraction • Models are abstractions of systems or other artifacts. • Abstractions allow us to filter out the details that we do not need in order to focus on those that we do. – High-level models filter out more detail (e. g. are more abstract). – Low-level models filter out less detail (e. g. are less abstract). • Models come in different formats – e. g. graphical, physical, mathematical, etc. • The type of model used and the level of abstraction required – is domain specific and problem specific.

System Modelling • System modelling is the process of developing abstract models of a system – can be used in requirements or systems design – but also in testing, and sometime in development • The level of abstraction employed in a system model is dependent on the use to which the model will be put in the development process

All models are wrong but some are useful • Statistician George Box (1919 -2003) – https: //en. wikipedia. org/wiki/George_E. _P. _Box – "one of the great statistical minds of the 20 th century" • The paper contains a section entitled "All models are wrong but some are useful". • The section is copied below. Now it would be very remarkable if any system existing in the real world could be exactly represented by any simple model. However, cunningly chosen parsimonious models often do provide remarkably useful approximations. For example, the law PV = RT relating pressure P, volume V and temperature T of an "ideal" gas via a constant R is not exactly true for any real gas, but it frequently provides a useful approximation and furthermore its structure is informative since it springs from a physical view of the behavior of gas molecules. For such a model there is no need to ask the question "Is the model true? ". If "truth" is to be the "whole truth" the answer must be "No". The only question of interest is "Is the model illuminating and useful? ".

What to Model? • The aspects of a system we choose to model should be project specific • A general set of guidelines for what to model would include: – – – System context and external interactions System architecture Static structure (data, objects, relationships, inheritance, interfaces, etc. ) Dynamic elements (interactions, states, sequences) User interface

What models to use? System context and Use case diagram, context model external interactions System architecture Component diagram Static structure Class diagram, entity relationship diagram Dynamic elements Sequence diagram, activity diagram, state diagram, data flow diagram, flowchart User interface Wireframes, mockups, navigational model, dialogue model, etc.

Where do we use system models? • Modelling software systems involves creating models of the existing system and the proposed system • Models of the existing system: – Help clarify system functionality, system components and actors. – Are used as a basis for identifying system strengths and weaknesses. – Help identify the requirements for the new system. • Models of the proposed system: – Help communicate requirements to system stakeholders. – Are used as a basis for system implementation.

Modelling – Perspectives • Because of their inherent complexity, software systems need to be modelled from several perspectives. External Interaction Provides a model of the context or environment of a system. Provides a model of the interactions between a system and its environment, between the internal components of a system, or between system users and a system. Behavioural (or process) Provides a model of the dynamic behaviour of a system and how it responds to events and triggers. Structural Provides a model of the components of a system, the organisation of a system, or the structure of the data that is processed by the system.

Modelling Languages • There are several modelling languages available for modelling software systems. • Most modelling languages provide one or more diagramming techniques. • The most widely used modelling language for software systems development is the Unified Modelling Language (UML). • UML provides several techniques for visualising software systems from all possible perspectives – i. e. external, interaction, structural and behavioural

A bit of history • The Unified Modeling Language (UML) is a general-purpose, developmental, modelling language – intended to provide a standard way to visualise the design of a system. • The creation of UML was originally motivated by the desire to standardise the disparate notational systems and approaches to software design. • It was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in 1994– 1995, with further development led by them through 1996. • In 1997 UML was adopted as a standard by the Object Management Group (OMG), and has been managed by this organisation ever since. • In 2005 UML was also published by the International Organization for Standardisation (ISO) as an approved ISO standard. • Since then the standard has been periodically revised to cover the latest revision of UML. • Although UML 2. 1 was never released as a formal specification, versions 2. 1. 1 and 2. 1. 2 appeared in 2007, followed by UML 2. 2 in February 2009. • UML 2. 3 was formally released in May 2010. UML 2. 4. 1 was formally released in August 2011. • UML 2. 5 was released in October 2012 as an "In process" version and was officially released in June 2015

UML 2. 0 (as of 2005) Aka: Union of Many Languages (a joke though!)

Uses for UML • As a sketch: to communicate aspects of system – – Forward design: doing UML before coding Backward design: doing UML after coding as documentation Often done on whiteboard or paper Used to get rough selective ideas • As a blueprint: a complete design to be implemented – Sometimes done with CASE (Computer-Aided Software Engineering) tools • As a programming language: with the right tools, code can be auto-generated and executed from UML – Only good if this is faster than coding in a "real" language

Five most used diagrams • Activity diagram: the activities involved in a process or in data processing • Use case diagram: the interactions between a system and its environment. • Sequence diagram: interactions between actors and the system and between system components. • Class diagrams: show the object classes in the system and the associations between these classes. • State diagrams: show the system reacts to internal and external events.

Tools for creating UML diagrams • Violet (free) – http: //horstmann. com/violet/ • Rational Rose – http: //www. rational. com/ • Visual Paradigm UML Suite (trial) – http: //www. visual-paradigm. com/ • There are many others, but most are commercial

Context models

Context Models • Context models are used to illustrate the operational context of a system. • They delineate the system boundaries or scope. • System boundaries define what is inside and what is outside the system. – show other systems that are used alongside, or depend upon, the system being developed. • Context models normally show that the environment includes one or more co-dependent systems. – However, they do not show the types of relationship between those systems.

Context Models • There is no explicit context diagram in UML. • However, other UML diagramming techniques can be used to produce context models. • Here, component diagram symbols are used to produce a context model of the Mentcare system’s operational context.

Context Models • Context models show only the other systems in the environment – But not how the system being developed operates in that environment. • High-level process models, on the other hand, are used to model the broader processes at work in a system. • UML activity diagrams can be used to create process models. • Activity diagrams show the flow of control from one activity to another, as well as decisions, repetition and coordination between activities.

Activity diagrams—example • Process model of involuntary detention in the Mentcare system.

Quiz • • • Rectangle with round corners Square boxes Diamonds Arrows Solid Bars Circles • Activity (specific subprocess) • (External) objects • Guards (when the flow is followed) • Flow of work • Activity coordination • Start and end of the process

Interaction models

Interaction Models • Modelling user interaction is important as it helps to concretise user requirements. • Modelling system-to-system interaction highlights any communication problems that may arise. • Modelling component interaction helps us understand if a proposed system structure is likely to deliver – the system performance – levels of dependability required. • In the UML, use case diagrams and sequence diagrams are used for creating interaction models.

Interaction Models – Use Cases • Use cases were originally developed as a means of supporting requirements elicitation – but are now more widely incorporated into the UML. • Each use case represents a discrete task that involves external interaction with a system. – Actors in a use case may be people or other systems. – Each use case should have two complementary components: • A graphical representation • A tabular description. • NB: Use cases and Use case diagrams are different things!

What is a use case? • A written description of the user’s interaction with the software product to accomplish a goal. – It is an example behaviour of the system. – 3 -9 clearly written steps lead to a “main success scenario. ” – Written from an actor's point of view, not the system’s. • Use cases capture functional requirements of a system.

Use case diagram • The overall list of the system's use cases can be drawn as highlevel diagrams, with: – actors as stick-men, with their names (nouns) – use cases as ellipses, with their names (verbs) – line associations, connecting an actor to a use case in which that actor participates – use cases can be connected to other cases that they rely on or extend

What is an extension? • A possible branch in a use case scenario, often triggered by an error or failure in the process. – Useful for finding edge cases that need to be handled and tested. • Do – Think about how every step of the use case could fail. – Give a plausible response to each extension from the system. – Response should either jump to another step of the case, or end it. • Don’t – List things outside the use case ("User's power goes out"). – Make unreasonable assumptions ("DB will never fail"). – List a remedy that your system can't actually implement.

Interaction Models – Use Case Diagram • A use case diagram showing several different use cases related to the medical receptionist actor in the Mentcare system.

Interaction Models – Use Cases • Tabular description of the transfer data use case in the Mentcare system. MHC-PMS: Transfer data Actors Medical receptionist, patient records system (PRS) Description Data A receptionist may transfer data from the Mentcare system to a general patient record database that is maintained by a health authority. The information transferred may either be updated personal information (address, phone number, etc. ) or a summary of the patient’s diagnosis and treatment. Patient’s personal information and/or treatment summary Stimulus User command issued by medical receptionist Response Comments Confirmation that PRS has been updated The receptionist must have appropriate security permissions to access the patient information and the PRS.

Interaction Models – Sequence Diagrams • UML sequence diagrams are used to model – the interactions between actors and objects within a system – The interactions between the objects themselves – 2 nd most used UML diagram (behind class diagram) • A sequence diagram shows the sequence of the interactions that take place for a given use case – Remember: Use cases sequence diagrams

A checklist of basics • Representing objects • An object's "life line” • message (method call) – Synchronous message – Asynchronous message – Return message • • Activations Object creation, deletion Alternatives, options, and loops Linking sequence diagrams

Alternatives, options, and loops • Frame: a box around part of a sequence diagram – if → (opt) [condition] – if/else→ (alt) [condition], separated by horizontal dashed line – loop → (loop) [condition or items to loop over]

Interaction Models – Sequence Diagrams • Objects and actors, with dotted line drawn vertically • Annotated arrows indicate interactions between objects – Call to the objects, their parameters, return values • Rectangle on the dotted lines indicates the lifeline of the object • Box named alt is used with the conditions indicated in square brackets • Sequence diagram for the view patient information use case in the Mentcare system.

Exercise 1. The user presses the “check email” button. 2. The client first sends all unsent email to the server. 3. After receiving an acknowledgement, the client asks the server if there is any new email. 4. If so, it downloads the new email. 5. Next, it deletes old thrashed email from the server.

Why use sequence diagrams? Why not code it? • A good sequence diagram is still above the level of the real code (not all code is drawn on diagram) • Sequence diagrams are language-agnostic (can be implemented in many different languages) • Non-coders can read and write sequence diagrams. • Easier to do sequence diagrams as a team. • Can see many objects/classes at a time on same page (visual bandwidth).

Structural models

Structural Models • Structural models are used to represent the component objects of a system, including object relationships, attributes and operations. • Structural models tend to be static models, but may also be dynamic models, which show the organisation of the system during execution. • The UML uses class diagrams, component diagrams and deployment diagrams to model system structure.

Structural Models – Class Diagram • The main structure diagram in the UML is the class diagram. • In the UML, a class represents an object or a set of objects that share a common structure and set of behaviours. • Class diagrams can be used to show: – – – The attributes and operations of a class. Interfaces Associations between classes, including multiplicity. Inheritance relationships between classes. Generalisation relationships between classes Aggregation relationships between classes.

What is a UML class diagram? • A UML class diagram is a picture of – the classes in an OO system – their fields and methods – connections between the classes that interact or inherit from each other • Not represented in a UML class diagram: – details of how the classes interact with each other – algorithmic details; how a particular behaviour is implemented

Structural Models – Class Diagram • Sample classes from the Mentcare system • Consultation class with attributes and operations added. visibility name(parameters) : return_type

Comments • Represented as a folded note, attached to the appropriate class/method/etc by a dashed line

Relationships between classes • Generalisation: an inheritance relationship – inheritance between classes – interface implementation • Association: a usage relationship – dependency – aggregation – composition

Structural Models – Class Diagram • Class diagram with associations and multiplicity.

Structural Models – Class Diagram – Associations • Detailed class diagrams show a description of an association. • They also show the multiplicity of associations. Indicat Meaning or 0. . 1 Zero or one 1 One only 0. . * Zero or more 1. . * One or more 1. . 5 One to five

Association types • Aggregation: “is part of” – symbolised by a clear white diamond • Composition: “is entirely made of” – stronger version of aggregation – the parts live and die with the whole – symbolised by a black diamond • Dependency: “uses temporarily” – symbolised by dotted line – often is an implementation detail, not an intrinsic part of the object's state

Aggregation / composition example • Try yourself: Cinema, Box. Office, Movie • If the cinema goes away – so does the box office: composition – but movies may still exist: aggregation

Class Diagram – Generalisation • Generalisation is a UML technique for managing structural complexity. • A generalisation relationship is a relationship in which one model element (the child) is based on another model element (the parent). • Generalisation relationships indicate that the child receives all of the attributes, operations, and relationships that are defined in the parent. • Generalisation is implemented in OO programming languages (e. g. Java) using inheritance features of the language.

Generalisation relationships • Hierarchies drawn top-down • Arrows point upward to parent • Line/arrow styles indicate if parent is a(n): – class: solid line – interface: dashed line • Often omit trivial / obvious generalization relationships, such as drawing the Object class as a parent

Class Diagram – Generalisation • A set of generalisation relationships in the Mentcare system

Exercise • A class diagram for video store with – Customer – Rental Item (DVD, VHS, Game) – Rental Invoice – Checkout Screen

Behaviour models

Behavioural Models • Behavioral models are models of the dynamic behaviour of a system as it is executing. • They show what happens in response to a stimulus from the system environment. • Stimulus from the environment can be of two types: Data Events Data enters the system, is processed, and then outputted in its transformed format. An event happens that triggers system processing. Events may have associated data, although this is not always the case

Behavioural Models – Data-driven Modelling • Data-driven modeling (or process modeling) depicts the sequence of actions involved in processing input data and generating an associated output. • Data flow models are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system. • We can use UML activity or sequence diagrams to create high-level and low-level process models.

Behavioural Models – Data-driven Modelling • A high-level activity model of the insulin pump’s operation.

Behavioural Models – Event-driven Modelling • Event-driven modeling shows how a system responds to external and internal events or triggers. • It is based on the assumption – a system has a finite number of states and – events may cause a transition from one state to another. • For example, an insulin pump responds to a trigger such as a successful injection of insulin by resetting its timer. • The UML supports event-driven modelling using state diagrams (based on statecharts)

Behavioural Models – Event-driven Modelling • State diagram showing the insulin pump states and triggers.

State Diagram of a microwave oven

Hierarchical modelling • The number of possible states increases rapidly • For large system models we need to hide detail in the model • The notion of a “superstate” that encapsulates a number of separate states

Microwave oven operation

States and stimuli for the microwave oven

Model-driven engineering • Model-driven engineering (MDE) is an approach to software development – where models rather than programs are the principal outputs of the development process. • The programs that execute on a hardware/software platform are then generated automatically from the models. • Proponents of MDE argue that – this raises the level of abstraction in software engineering – engineers no longer have to be concerned with programming language details or the specifics of execution platforms.

Usage of model-driven engineering • Model-driven engineering is still at an early stage of development, – it is unclear whether or not it will have a significant effect on software engineering practice. • Pros – Allows systems to be considered at higher levels of abstraction – Generating code automatically means that it is cheaper to adapt systems to new platforms. • Cons – Models for abstraction and not necessarily right for implementation. – Savings from generating code may be outweighed by the costs of developing translators for new platforms.

Model driven architecture • Model-driven architecture (MDA) was the precursor of more general model-driven engineering • MDA is a model-focused approach to software design and implementation – uses a subset of UML models to describe a system • Models at different levels of abstraction are created. • From a high-level, platform independent model, it is possible, in principle, to generate a working program without manual intervention.

Types of models • A computation independent model (CIM) – These model the important domain abstractions used in a system. – CIMs are sometimes called domain models. • A platform independent model (PIM) – These model the operation of the system without reference to its implementation. – The PIM is usually described using UML models that show the static system structure and how it responds to external and internal events. • Platform specific models (PSM) – These are transformations of the platform-independent model with a separate PSM for each application platform. – In principle, there may be layers of PSM, with each layer adding some platform-specific detail.