Executable UML – UML2 The Need for xUML With Acknowledgement to Kennedy-Carter: Moh Ibrahim, Alex Fedorec & Keith Rennolls.

Slides:



Advertisements
Similar presentations
Chapter 7 System Models.
Advertisements

Model Driven Generative Programming Reza Azimi February 6, 2003 ECE1770: Trends in Middleware Systems.
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Lockheed Martin Aeronautics Company © 2001 Lockheed Martin Corporation F-16 Modular Mission Computer Application Software Achieving Cross-Platform Compatibility.
UML an overview.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Multimedia Specification Design and Production 2013 / Semester 1 / week 7 Lecturer: Dr. Nikos Gazepidis
Modeling the Process and Life Cycle CSCI 411 Advanced Database and Project Management Monday, February 2, 2015.
Chapter 4 Quality Assurance in Context
Chapter 2 – Software Processes
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Software Testing and Quality Assurance
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Fall 2007CS 225 Introduction to Software Design Chapter 1.
Chapter 15 Design, Coding, and Testing. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
03/12/2001 © Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Unified Modeling Language Visual language.
Describing Syntax and Semantics
Package design and the Iterative process model. What is a package? Classes are not sufficient to group code –Some classes collaborate, implying dependencies.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
1 Introduction Chapter 1. 2 Key Ideas Many failed systems were abandoned because analysts tried to build wonderful systems without understanding the organization.
UML - Development Process 1 Software Development Process Using UML (2)
Chapter 2 The process Process, Methods, and Tools
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
Introduction to Software Design Chapter 1. Chapter Objectives  To become familiar with the software challenge and the software life cycle  To understand.
More on “The Huddersfield Method” A lightweight, pattern-driven method based on SSM, Domain Driven Design and Naked Objects.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
WXGE6103 Software Engineering Process and Practice Formal Specification.
Slide 1 Structural Modeling Chapter 7. Slide 2 Key Ideas A structural or conceptual model describes the structure of the data that supports the business.
System models l Abstract descriptions of systems whose requirements are being analysed.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
Object-Oriented Analysis and Design. Lesson 1: Introduction to Software Engineering.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
© Bennett, McRobb and Farmer 2005
Chapter 2 – Software Processes Lecture 1 1Chapter 2 Software Processes.
Science and Technology Norwegian University of NTNU Rolv Bræk, January Introduction to Systems Engineering by Rolv Bræk NTNU.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 Software Testing and Quality Assurance Lecture 17 - Test Analysis & Design Models (Chapter 4, A Practical Guide to Testing Object-Oriented Software)
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
Design CS 470 – Software Engineering I Sheldon X. Liang, PH.D.
Object Oriented Analysis & Design By Rashid Mahmood.
UNIT 1.
Unified Modeling Language
UML: Unified modeling language
Specifying collaborative decision-making systems
CS310 Software Engineering Dr.Doaa Sami
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Overview Activities from additional UP disciplines are needed to bring a system into being Implementation Testing Deployment Configuration and change management.
Uml diagrams In ooad.
Presentation transcript:

Executable UML – UML2 The Need for xUML With Acknowledgement to Kennedy-Carter: Moh Ibrahim, Alex Fedorec & Keith Rennolls The University of Greenwich

2 Bonn – NEFIS Why is the UML 1.x… not executable ?  It is ‘computationally’ incomplete  UML describes a system in, broadly, two ways:  by specifying the desired results (use cases, sequence diagrams)  by specifying the software that, when executed, will produce the desired results (classes, associations, operations, state machines)  The latter specification of behaviour is the basis for implementing the system, but is missing key ingredients:  the implementation of operations (methods) are specified only by a “language dependent” text string  the actions associated with state machines (and methods) are specified either by a text string, or by using the “action” part of the UML Action Terminate Action DestroyAction Uninterpreted Action CreateAction CallActionReturnAction SendAction

3 Bonn – NEFIS Action Specifications in UML 1.x  Cannot be attached to methods and therefore  cannot be used to specify operations  Do not cover the full range of information required to model real behaviour  No conditional logic  Do not deal with internal data within an Action Sequence  Cannot describe reading and writing of attributes  Cannot describe manipulation and navigation of associations  Cannot describe parallel behaviour  Not related to the UML type model  Do not have fully defined semantics..... were intended only as a place holder for future UML development

4 Bonn – NEFIS Why is the current UML not executable ?  It is big  UML was conceived as a Universal as well as Unified modelling language  UML covers many development paradigms  Synchronous and asynchronous behaviour  State dependent and stateless behaviour  Mealy state machines and Moore state machines  Flat state models and Harel state charts  Abstract analysis modelling and code specific design modelling  Language specific modelling and abstract modelling  Sometimes the breadth of coverage can lead to ambiguity... Transaction in Progress Transaction Complete entry/ log transaction Transaction Completed/ if is_aborted then return e.g. what happens if you execute a “return” in a transition action stimulated by “call” (synchronous) event ? I have absolutely no idea because that combination of behaviour is undefined!

5 Bonn – NEFIS Actions and the UML  the Action Specification Language, operates at the same level of abstraction as UML… …but embodies the precision to allow models to be executed and consequently supports translation of the models into any language.  The OMG has recognised the need for a full action specification in the UML  In November 1998 the OMG issued a Request for Proposals on Precise Action Semantics for the UML

6 Bonn – NEFIS What is xUML? UML V1.x xUML = Semantically Weak Elements Semantically Weak Elements - Precisely Defined Action Semantics +  xUML is  an executable version of the UML, with…  clearly defined simple model structure  a precise semantics for actions, incorporated into the UML 2 standard  a compliant action specification language  an accompanying process  a proven development process, oriented towards…  executable modelling  large-scale reuse  pattern based design

7 Bonn – NEFIS Why an Executable UML ?  Measurable Deliverables  Models that execute tests correctly  Can be delivered in phases with progressive integration  Use case by use case Admit In Patient User Interface U log incident Patient AdminStatementsResource Alloc 1:dialogue ok hit 2:admit in patient 3:assign bed 4:bed assigned 5:confirm admission 6:display dialogue 8:reject admission 9:display dialogue 1:op selects admit in patient 2: 3:find a suitable bed 4:if bed available then 5: confirm admission 6: display “success” dialogue 7: log admission details 8:else reject admission 9: display “failure” dialogue  Class group by class group  Early Verification  Requirements can be validated before extensive system design and coding This supports iterative and incremental development An executable model can be developed and tested even if it supports only a single use case Groups of classes at the collaboration, subsystem, package or domain level can be modelled and executed

8 Bonn – NEFIS Why an Executable UML ?  Improves the quality of the modelling  Models can be judged not just on subjective criteria, but on whether they exhibit the desired behaviour and thus meet requirements  Focused analyst objective àThe aim is to build models that execute correctly àAvoids “analysis paralysis” àReviews criteria are objective and therefore more useful Aircraft clearedRunway() Runway deallocate() 0..1 is_ allocated_to R Does this identify the correct runway to deallocate ? Does this identify the correct runway to deallocate ? # obtain an instance handle for # the runway we just landed on theRunway = this -> R9.”is_allocated_to” # remove the association unlink this R9 theRunway # tell the runway that aircraft has landed [] = deallocate[] on theRunway

9 Bonn – NEFIS Why an Executable UML ?..... eliminates maintenance problems due to redundant analysis and design models  Supports extensive code generation if desired  Lack of ambiguity means automatic code generation will deliver functionally correct code GenericContainer HashTableLinkedListBoundedArray GenericClass 0..* 1  A solid specification  Supports multiple development teams  Well defined models mean well defined interfaces  Easier Transition to Design and Code  No ambiguity in the models - the models have a single clear interpretation  Design can be specified using abstract patterns

10 Bonn – NEFIS Why an Executable UML ?  and finally..... It’s more fun !  Analysts see the results of their efforts more rapidly and have more confidence that what they are doing is correct  Managers get more confidence that progress is being made Round-trip Software Engineering - Quality Assurance Problem / Requirement Solution / Implementation Can miss the solution to the problem?