Software Engineering I Session 5

1. Software Engineering ISession 5 Software Modelling

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

3. Models and Abstraction • Models are abstractionsof systems or other artefacts. • 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.

4. System Modelling • System modelling is the process of developing abstract models of a system • can be used in requirements modelling or systems design. • 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

5. 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 20th 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?".

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

7. What models to use?

8. 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.

9. Modelling – Perspectives • Because of their inherent complexity, software systems need to be modelled from several perspectives.

10. Modelling Languages • There are several modelling languagesavailable 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

11. 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

12. The Unified Modelling Language • The main UML diagrams used in software modelling.

13. UML 2.0 (as of 2005)

14. 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 how the system reacts to internal and external events.

15. Chapter 5 System Modeling Context models

16. 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.

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

18. 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.

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

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

21. Interaction models

22. 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 and levels of dependability required. • In the UML, use case diagrams and sequence diagrams are used for creating interaction models.

23. 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.

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

25. Interaction Models – Use Cases • Tabular description of the transfer data use case in the Mentcare system.

26. 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 • A sequence diagram shows the sequence of the interactions that take place for a given use case. • 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

27. Interaction Models – Sequence Diagrams • Sequence diagram for the view patient information use case in the Mentcare system.

28. Behaviour models

29. 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:

30. 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.

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

32. 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)

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

34. State Diagram of a microwave oven

35. 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

36. Microwave oven operation

37. States and stimuli for the microwave oven

38. Structural models

39. 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 deploymentdiagrams to model system structure.

40. 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.

41. Structural Models – Class Diagram • Sample classes from the Mentcare system • Consultation class with attributes and operations added.

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

43. Structural Models – Class Diagram – Associations • Detailed class diagrams show a description of an association. • They also show the multiplicity of associations.

44. 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.

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

46. 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.

47. 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.

48. 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.

49. 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.

50. Adoption of MDA (why not?) • A range of factors has limited the adoption of MDE/MDA • Specialised tool support is required to convert models from one level to another • There is limited tool availability and organisations may require tool adaptation and customisation to their environment • For the long-lifetime systems developed using MDA, companies are reluctant to develop their own tools or rely on small companies that may go out of business • Models are a good way of facilitating discussions about a software design. • However the abstractions that are useful for discussions may not be the right abstractions for implementation. • For most complex systems, implementation is not the major problem • requirements engineering, security and dependability, integration with legacy systems and testing are all more significant. • Gains from the use of MDA are limited • The arguments for platform-independence are only valid for large, long-lifetime systems. • For software products and information systems, the savings from the use of MDA are likely to be outweighed by the costs of its introduction and tooling. • The widespread adoption of agile methods over the same period that MDA was evolving has diverted attention away from model-driven approaches.