Engineering Design w/embedded Systems

Similar documents
Lecture 33 April 4, Unied Modelling Language. ECE155: Engineering Design with Embedded Systems Winter Patrick Lam version 1

Software Service Engineering

Introduction to Software Engineering. 5. Modeling Objects and Classes

Course "Softwaretechnik" Book Chapter 2 Modeling with UML

UML Modeling I. Instructor: Yongjie Zheng September 3, CS 490MT/5555 Software Methods and Tools

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh

Exercise Unit 2: Modeling Paradigms - RT-UML. UML: The Unified Modeling Language. Statecharts. RT-UML in AnyLogic

Introduction to Software Engineering. 5. Modeling Objects and Classes

Object Oriented Modeling

Software Design And Modeling BE 2015 (w. e. f Academic Year )

Interactions A link message

Object-Oriented Analysis and Design

EE 446 EMBEDDED ARCHITECTURE Embedded System in UML (2)

UML Tutorial. Unified Modeling Language UML Tutorial

MSc programme (induction week) Department of Informatics INTRODUCTION TO UML

Object-Oriented Design

UML Diagrams & And Some Of Their Elements

LABORATORY 1 REVISION

Unified Modeling Language (UML)

The Unified Modeling Language (UML)

A - 1. CS 494 Object-Oriented Analysis & Design. UML Class Models. Overview. Class Model Perspectives (cont d) Developing Class Models

UML (Unified Modeling Language)

UML Fundamental. OutLine. NetFusion Tech. Co., Ltd. Jack Lee. Use-case diagram Class diagram Sequence diagram

Lab Manual. Object Oriented Analysis And Design. TE(Computer) VI semester

UML Sequence Diagrams for Process Views

Class diagrams. Modeling with UML Chapter 2, part 2. Class Diagrams: details. Class diagram for a simple watch

UML 2.0 UML 2.0. Scott Uk-Jin Lee. Division of Computer Science, College of Computing Hanyang University ERICA Campus

Unified Modeling Language

2 UML for OOAD. 2.1 What is UML? 2.2 Classes in UML 2.3 Relations in UML 2.4 Static and Dynamic Design with UML. UML for OOAD Stefan Kluth 1

Unified Modeling Language (UML)

Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques. Fundamentals, Design, and Implementation, 9/e

Software Engineering Lab Manual

LESSON PLAN SUB NAME : OBJECT ORIENTED ANALYSIS AND DESIGN UNIT SYLLABUS

Chapter 10. Object-Oriented Analysis and Modeling Using the UML. McGraw-Hill/Irwin

Course 3 7 March

2.0.3 attributes: A named property of a class that describes the range of values that the class or its instances (i.e., objects) may hold.

BUILDING BLOCKS. UML & more...

The Dynamic Model. An Introduction to UML. Enterprise Architect. by Geoffrey Sparks. All material (c) Geoffrey Sparks

Object-Oriented Analysis and Design. Pre-UML Situation. The Unified Modeling Language. Unification Efforts

Object-Oriented and Classical Software Engineering

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

EVALUATION COPY. The Unified Modeling Language. Unauthorized reproduction or distribution is prohibited. Student Workbook

Today s Topic. Lecture 5. What is UML? Why Use UML. UML Diagrams. Introduction to UML. What is UML Why use UML? UML Diagrams

SOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis.

Developing Shlaer-Mellor Models Using UML

2.0.3 attributes: A named property of a class that describes the range of values that the class or its instances (i.e., objects) may hold.

EECS 4314 Advanced Software Engineering. Topic 03: UML Overview Zhen Ming (Jack) Jiang

Chapter 12. UML and Patterns. Copyright 2008 Pearson Addison-Wesley. All rights reserved

Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques. Fundamentals, Design, and Implementation, 9/e

2.0.3 attributes: A named property of a class that describes the range of values that the class or its instances (i.e., objects) may hold.

Chapter 5: Structural Modeling

Object-Oriented Software Engineering Practical Software Development using UML and Java

BCS Higher Education Qualifications. Diploma in IT. Object Oriented Programming Syllabus

Lesson 11. W.C.Udwela Department of Mathematics & Computer Science

SOFTWARE MODELING AND DESIGN. UML, Use Cases, Patterns, and. Software Architectures. Ki Cambridge UNIVERSITY PRESS. Hassan Gomaa

UML & OO FUNDAMENTALS CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 3 08/30/2011

Object-Oriented Design

Software Modelling. UML Class Diagram Notation. Unified Modeling Language (UML) UML Modelling. CS 247: Software Engineering Principles

UML Primer. -Elango Sundaram

UML REFERENCE SHEETS. 2013, 2014 Michael Marking; all rights reserved, including moral rights. Web site:

Introduction to Software Engineering. 6. Modeling Behaviour

CHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview

CS 247: Software Engineering Principles. UML Modelling

administrivia today UML start design patterns Tuesday, September 28, 2010

Session 8: UML The Unified Modeling (or the Unstructured Muddling) language?

UML part I. UML part I 1/41

Software Engineering

CS 370 REVIEW: UML Diagrams D R. M I C H A E L J. R E A L E F A L L

Software Development. Modular Design and Algorithm Analysis

1 Introduction. 1.1 Introduction

UNIT-II Introduction to UML

Software Engineering

Meltem Özturan

UNIT-I Introduction of Object Oriented Modeling

From Analysis to Design. LTOOD/OOAD Verified Software Systems

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION (Autonomous) (ISO/IEC Certified)

EVENTS AND SIGNALS. Figure 1: Events. kinds of events Signal Event

Course "Softwaretechnik Modeling with UML Stephan Salinger

COMP 354: INTRODUCTION TO SOFTWARE ENGINEERING

An Introduction To Object Modeling System Concept for Object Modeling The Overall View Components of UML Diagram

INTERNATIONAL JOURNAL OF PURE AND APPLIED RESEARCH IN ENGINEERING AND TECHNOLOGY

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD TM : ,

Models are used for several purposes. We believe that some of the most important are:

Lecture 17: (Architecture V)

12 Tutorial on UML. TIMe TIMe Electronic Textbook

Oral Questions. Unit-1 Concepts. Oral Question/Assignment/Gate Question with Answer

Software Development Methodologies

A Role-based Use Case Model for Remote Data Acquisition Systems *

S T R U C T U R A L M O D E L I N G ( M O D E L I N G A S Y S T E M ' S L O G I C A L S T R U C T U R E U S I N G C L A S S E S A N D C L A S S D I A

Modeling with UML. (1) Use Case Diagram. (2) Class Diagram. (3) Interaction Diagram. (4) State Diagram

Object-Oriented Software Development Goal and Scope

INTRODUCTION TO UNIFIED MODELING MODEL (UML) & DFD. Slides by: Shree Jaswal

Metamodeling. Janos Sztipanovits ISIS, Vanderbilt University

Lecture #2 on Object-Oriented Modeling

Course "Softwaretechnik" Book Chapter 2 Modeling with UML

OMG Modeling Glossary B

Pertemuan 8. Object Oriented Modeling and Design

Software Development

Interaction Modelling: Sequence Diagrams

(11-1) OOP: Inheritance in C++ D & D Chapter 11. Instructor - Andrew S. O Fallon CptS 122 (October 29, 2018) Washington State University

Transcription:

1 / 40 Engineering Design w/embedded Systems Lecture 33 UML Patrick Lam University of Waterloo April 4, 2013

2 / 40 What is UML? Unified Modelling Language (UML): specify and document architecture of large object-oriented software systems, using diagrams. UML version 2.2 defines 13 diagrams to summarize: intended structure (e.g. classes); behaviour; and interactions of components.

3 / 40 Resources Lots of information on the Web, e.g. http://edn.embarcadero.com/article/31863. Some books: Grady Booch, James Rumbaugh, and Ivar Jacobson. Unified Modeling Language User Guide, 2nd Edition, Addison-Wesley, 2005. Dan Pilone and Neil Pitman. UML 2.0 in a Nutshell. O Reilly Media, 2005.

4 / 40 UML Benefits UML is a well-known language for software designs. In particular, it: is a visual language; UML models are diagrams, so easy to glance at. models are largely self-documenting. is agnostic in terms of software processes or development lifecycles. is an open standard (not owned by any one company). is good for object-oriented languages, which are quite common. in industry.

5 / 40 Complaints about UML Here are some potential complaints about UML. all syntax, no meaning. contains redundant and infrequently-used constructs. complex and difficult to learn. only works for object-oriented languages. tools don t play nicely together.

6 / 40 Categories of UML Diagrams Three main types: Structure Diagrams static application structure. Examples: class diagrams, object diagrams, component diagrams, composite structure diagrams, package diagrams, deployment diagrams. Behaviour Diagrams usage of components, activity of components, and finite-state machines summarizing components states. Examples: use case diagrams, activity diagrams, state machine diagrams. Interaction Diagrams how do components interact?: Communication and synchronization, potentially timed. Examples: sequence diagrams, communication diagrams, timing diagrams, and interaction overview diagrams.

7 / 40 Tool Support Software tools can create UML diagrams. e.g. Microsoft Visio, dia. Tools can generate code from UML and UML from code. Round-tripping: going both ways. Tools can also (sort of) generate test cases and test suites from UML diagrams.

8 / 40 Part I UML Class Diagrams

9 / 40 About Class Diagrams The basic UML diagram. Describes the members of a class: attributes/fields; operations (constructors, destructors, methods, indexers, and properties).

10 / 40 Basic Class Diagram Example; Visibility Symbols +mydata: string MyClass +MyClass() +myfunction(param:string): string A + (plus sign) = public visibility (seen above). A - (minus sign) = private visibility. A # (hash sign) = protected visibility.

11 / 40 Other UML Symbols UML also uses the following symbols: A (tilde) indicates a destructor (in front of an operation) or package (as a visibility symbol). An.. (ellipsis) indicates a range of values. A : (colon) separates a name from a type. A, (comma) separates items in a set.

public Employee ( S t r i n g pname, S t r i n g paddress, i n t page, S t r i n g psin ) { /... / } @Override public S t r i n g t o S t r i n g ( ) { /... / } public s t a t i c boolean s o r t ( ) { /... / } } 12 / 40 Another UML Class Diagram class Employee { protected S t r i n g name ; protected S t r i n g address ; protected i n t age ; protected S t r i n g socialinsurancenumber ; public S t r i n g email ; private long sortkey ;

13 / 40 Class Hierarchies in UML UML represents relationships between classes and instances. Between instances of classes: association: a relationship between instances of two classes. aggregation: a type of association, typically between a collection or container instance and contents. composition: another type of association, typically between a container and its contents. For a composition, the contents don t make any sense if the container isn t around. But: a generalization relates base classes (not instances) and their derived classes.

14 / 40 Associations: has-a links between classes Typically one of the classes can call methods on the other. 1..* Teaches 0..3 Instructor University Course Instructors and courses are associated, but there is no subtype relationship, and the types are not collection types. Instructors teach between 0 and 3 courses per term. Each course has at least 1 instructor, but possibly an unlimited number. A method that the instructor might call on the course might be givelecture().

15 / 40 Aggregations Specialized types of associations; also represent has-a relationships, but more part-whole relationships. Linked List contains 0 or more Elements. Elements belong to only one Linked List. Composition means that we are saying that Elements may not exist independently of a Linked List.

16 / 40 Compositions Computers contain 1 or more Processors, but Processors only belong to 1 Computer. In an aggregation, we are stating that Processors do exist independently of a Computer.

17 / 40 Generalizations Relationships between classes. Salaried Employee Employee Hourly Employee Every Salaried Employee and Hourly Employee is an Employee, so Employees are generalizations of the Salaried and Hourly Employee classes. In code: Salaried Employee and Hourly Employee would be subclasses of ( extend ) Employee.

18 / 40 More Class Diagrams I From http: //www.altova.com/umodel/class-diagrams.html (accessed March 10, 2011).: Note the member field initializations and the generalization link.

19 / 40 More Class Diagrams II From http://edn.embarcadero.com/article/31863 (accessed March 10, 2011).

20 / 40 Part II UML State Diagrams

21 / 40 State Diagrams: Learning Outcome You should be able to: read a description of a finite state machine (either in code or in text) and produce a syntactically correct UML state diagram summarizing that design. (Examples are from UML Distilled, Second Edition, by Martin Fowler with Kendall Scott.)

UML State Diagram: Order Processing System 22 / 40

23 / 40 UML State Diagram: States Example: states of an order in an order processing system. Order object has 4 states, represented by boxes. Upper half of the box = name, e.g. checking, dispatching, waiting, delivered. Lower half = what the activity in that state is. Dispatching state initiates the delivery of the order. In ECE155, you can always put do before the slash and the activity after the slash. State have names and may have activities. Objects carry out activities, and these activities take some amount of time.

24 / 40 UML State Diagram: Transitions Edges = transitions between states, optionally labelled. Three parts to a transition label: Event [Guard] / Action. An object takes transition if event occurs and guard is true. Example: self-transition from checking contains guard [not all items checked] and performs action get next item. Event: something happening to an object, e.g. Item Received. Guard: logical condition that states the conditions under which the event may occur (e.g. [some items not in stock] ). Objects carry out actions, e.g. get next item. Actions must occur quickly and be uninterruptible. UML state machines are deterministic: at most one transition should be activated at once.

25 / 40 UML State Diagram: Superstates State diagrams may get too complicated. UML s solution: hierarchical nesting: can help write clearer diagrams; allow understanding system s higher-level structure. Concept: superstate. may contain nested states and transitions; make up a state machine for some subset of the entire machine s behaviour.

UML State Diagram: Superstate Example (http://atlas.kennesaw.edu/~dbraun/csis4650/a&d/uml_tutorial/state.htm. Accessed July 3, 2011.) Superstate active contains checking and dispatching. Note transitions from states inside superstate, e.g. dispatching to delivered, plus transition from the superstate to the cancelled state. So, either of the states in the superstate can get to cancelled. Superstate transition = transitions from both dispatching and checking to cancelled. 26 / 40

27 / 40 UML State Diagram: Timing Recall: timing is important for embedded systems. Your documentation should explain what quickly (actions happen quickly) means. UML doesn t say; it depends on the system. Can also write an event that happens after some time, e.g. after (20 minutes).

28 / 40 Part III UML Use Case Diagrams

29 / 40 Use cases in UML; actors Recall: a use case describes a user s interaction with a system. Actors represent users (or other systems).

30 / 40 Example: Multiple actors It s just a coincidence that each use case has two actors.

31 / 40 Another use case example http://msdn.microsoft.com/en-us/library/dd409427%28vs.100%29.aspx (accessed March 10, 2011). Components: 1) actors, 2) use cases, 3) communication, and, new to this figure, 4) subsystems or components.

32 / 40 Use cases and actors Here we have: 5) inclusion stereotypes on dependencies; 6) extension stereotypes on dependencies; 7) inheritance relationships between use cases; 8) plain dependencies; 9) comments; and 10) references to other artifacts.

33 / 40 Things in use cases A communication (solid line) represents a relationship between an actor and a use case. An inclusion (dashed line, «include» stereotype) represents an invocation relationship between use cases; the first use case must call the second one. An extension (dashed line, «extend» stereotype) represents an optional invocation of a use case. A generalization or specialization represents a case where an actor or use case inherits from another actor or use case.

UML use cases: why? Can be useful for: 1 documenting essential features (requirements) of a software system; 2 communicating system behaviour to clients; 3 generating appropriate test cases for scenarios. 34 / 40

35 / 40 Part IV UML Sequence Diagrams

36 / 40 About UML Sequence Diagrams UML sequence diagrams: express system behaviour as a sequence of events and activities. Things you ll find: objects, lifelines, messages, action boxes, and gates.

37 / 40 Elements in UML Sequence Diagrams Instances of objects: boxes at the top of the diagram. Lifelines (vertical dashed lines, extending downwards from instances of the objects): denote the passing of time. Messages (horizontal lines): denote communication between objects. Action boxes (boxes on top of lifelines): denote the occurrence of activities. Gates (filled circles on the boundary of the diagram): denote occurrence of external events.

Sequence diagram, financial reporting system (IBM, UML basics: The sequence diagram, http://www.ibm.com/developerworks/rational/library/3101.html, accessed March 10, 2011). Solid lines are initiating messages. Dashed lines are responses. Also: synchronous messages (solid arrowhead all initiating messages in the above example) and asynchronous messages (stick arrowhead responses). You can also use: actors, destroy elements, scenario elements, timer elements. 38 / 40

39 / 40 Sequence diagram, student records Note guards on messages; must be satisfied before the message gets sent.

40 / 40 Sequence diagram: when? UML sequence diagrams help document messages going between different instances of objects, including the ordering in which these events occur (for synchronous events). Exercise judgment to include the right level of detail. too much detail makes the model difficult to understand; too little detail doesn t document anything. You can use more than one UML sequence diagram to document a large system.