ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: An Aside: The Quickest Tour through the UML that you will ever get.

Slides:



Advertisements
Similar presentations
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Advertisements

A Brief Introduction. Acknowledgements  The material in this tutorial is based in part on: Concurrency: State Models & Java Programming, by Jeff Magee.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
CS3773 Software Engineering Lecture 03 UML Use Cases.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
Object-Oriented Analysis and Design
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Use-case Modeling.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Lecture 11: Chapter 22 Topics –Object Oriented Modeling –UML –Use case.
Documenting Requirements using Use Case Diagrams
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
© Copyright Eliyahu Brutman Programming Techniques Course.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Sharif University of Technology1 Design and Use-case Realization Software Engineering Laboratory Fall 2006.
03/12/2001 © Bennett, McRobb and Farmer Use Case Diagrams Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Use Case Analysis – continued
Unified Modeling Language
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
©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.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Unified Modeling Language, Version 2.0
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
1 Devon M. Simmonds University of North Carolina, Wilmington CSC450 Software Engineering WorkFlow Modeling with Activity Diagrams.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Programming Logic and Design Fourth Edition, Comprehensive Chapter 15 System Modeling with the UML.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
An Introduction to the Unified Modeling Language
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
1 The Unified Modeling Language. 2 The Unified Modeling Language (UML) is a standard language for writing software blueprints. The UML may be used to.
UML as a Specification Language for Embedded Systems. By, Mir Ahmed Ali, Asst. Professor, ECM department, SNIST. By, Prof. Narsiah sir, Director of School.
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 2: Introduction to Object-Oriented Systems Analysis.
Unified Modeling Language. Object Oriented Methods ► What are object-oriented (OO) methods?  OO methods provide a set of techniques for analyzing, decomposing,
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 2: Introduction to Object-Oriented Systems Analysis.
1 Unified Modeling Language, Version 2.0 Chapter 2.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
CSCI 3428: Software Engineering Tami Meredith UML Unified Modeling Language.
UML Course Instructor: Rizwana Noor. Overview  Modeling  What is UML?  Why UML?  UML Diagrams  Use Case  Components  Relationships  Notations.
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
Object-Oriented Software Engineering Practical Software Development using UML and Java Modelling with Classes.
1 SWE Introduction to Software Engineering Lecture 14 – System Modeling.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Basic Characteristics of Object-Oriented Systems
Distributed Java Programming Distributed Java Programming Class #1 August 20, 2002.
Software Engineering: Models David Millard
Introduction to Unified Modeling Language (UML) By Rick Mercer with help from The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 14 Slide 1 Object-Oriented Design.
1 An Overview of UML. 2 The Unified Modeling Language UML is a graphical language used by software engineers to model software systems during development.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Slide 1 Unified Modeling Language, Version 2.0 Object-Oriented SAD.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Evolution of UML.
Object-Oriented Analysis and Design
Systems Analysis and Design With UML 2
University of Central Florida COP 3330 Object Oriented Programming
The Unified Modeling Language
Presentation transcript:

ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: An Aside: The Quickest Tour through the UML that you will ever get

ECE450 - Software Engineering II2 Warning: Europe in 5 days

ECE450 - Software Engineering II3 What is UML and why should I care? The Unified Modeling Language is an industry standard for specifying and visualizing the artifacts of software systems –A collection of diagrammatic languages to express everything from class structures to execution scenarios –A joint effort by object-oriented modeling researchers to merge their different approaches James Rumbaugh, Grady Booch, Ivar Jacobson UML 1.0 came out in 1997 Current version, UML If there is one modeling language that you need to know to get a job, this is it –Although frankly you may not need to use it once you get that job –If “Model-Driven Development” takes off, you will need this Easy to learn the basics, very hard to master it –Especially the newest version –For now all you need are those easy-to-learn basics

ECE450 - Software Engineering II4 The many diagrams of UML

ECE450 - Software Engineering II5 Class Diagrams Class diagrams define the structure of the classes in a system, the relationship between all classes, and the components of each class. A class is a general concept (represented as a square box). A class defines the structural attributes and behavioural characteristics of that concept. Shown as a rectangle labeled with the class name. Class A (semantic) relationship between classes. A line that joins two classes. Association

ECE450 - Software Engineering II6 Class Diagrams (cont) Types of associations Binary n-ary Aggregation (has-a) Composition (is-composed-of) Generalization (is-a-kind-of)

ECE450 - Software Engineering II7 Class Diagrams (cont) Types of associations (cont) DependencyRealization The source class depends on (uses) the target class Class supports all operations of target class but not all attributes or associations.

ECE450 - Software Engineering II8 Class Diagrams (cont) Attributes and operations Multiplicity –n, where n = {0, 1, x, *} –m..n, where m,n = {0, 1, x, *} Attributes are what is known about each object of this class type. Operations are what objects of this class type do.

ECE450 - Software Engineering II9 Class Diagrams (cont) Design patterns are usually expressed through their class diagrams. E.g., decorator:

ECE450 - Software Engineering II10 Use Case Diagrams Just what is a “use case”? –The answer to the question “What functions will the new system provide?” How will people interact with it? Describe the system in terms of its users and its boundary Normally, a use case shows: –A function that the system will provide –The actors that are involved in that function –A sequence of related actions performed by an actor and the system via a dialogue The sequence usually explains the “common use” scenario, and covers some of the exceptional cases briefly What is an actor? –Anything that needs to interact with the system A person A role that different people may play An external system

ECE450 - Software Engineering II11 Use Case Diagrams (cont) A use case is not diagrammatic! –We normally describe use cases textually –But we may have diagrams that summarize the interactions between system and actors That is what use case diagrams are about Staff contact Actor Change client contact Communication association System boundary Use case

ECE450 - Software Engineering II12 Use Case Diagrams (cont) An example Add new staff member Add new staff grade Calculate staff bonuses Change grade for staff member Accountant Change rate for staff grade

ECE450 - Software Engineering II13 Use Case Diagrams (cont) > and > – > when one case adds behaviour to a base case Used to model a part of a use case that the user may see as optional system behaviour Also models a separate sub-case which is executed conditionally – >: one use case invokes another (like a procedure call) Used to avoid describing the same flow of events several times Puts the common behaviour in a use case of its own > Check Campaign Budget Print Campaign Summary > Find Campaign

ECE450 - Software Engineering II14 Use Case Diagrams (cont) Meeting scheduler example Provide constraints Edit Constraints Withdraw Validate User Schedule meeting Initiator Participant > Generate Schedule >

ECE450 - Software Engineering II15 Use Case Diagrams (cont) Generalizations –Actor classes: Actors inherit use cases from the class –Use case classes: Generalizations of several use cases Generalisation relations: Read as: “is a member of” or just “is a”

ECE450 - Software Engineering II16 Sequence Diagrams Sequence diagrams provide a more detailed look of the sequence of steps executed in a use case –Normally used for lower-level design –If you wanted to specify all of your application’s scenarios with sequence diagrams, you would need one for each of its features’ ramifications So we are usually interested in key scenarios only Sequence diagrams show: –The actors and software classes/objects that intervene in the scenario –The step-by-step interactions between them Chronologically, from top to bottom –Details regarding when objects are created and activated

ECE450 - Software Engineering II17 Sequence Diagrams (cont) Example

ECE450 - Software Engineering II18 Sequence Diagrams (cont) This is not the full story –We can illustrate branching, guards (conditions necessary for the execution of a call), asynchronous messaging, and more –In UML 2.0, sequence diagrams went through a major overhaul Conditionals, loops, etc. We don’t need the full story for this course –These basics are enough –But if you want to invest time in learning more about UML, sequence diagrams are the place to start Along with class diagrams, they are the most frequently used kind of model

ECE450 - Software Engineering II19 What about the others? Every kind of diagram has a (sometimes slightly) different purpose –There is probably one that matches what you are trying to express On the other hand, you may rightfully accuse UML of bloating –Design by committee –Trying to be all things for all people –Attempts at formalizing semantics vs. attempts to maintain comprehensibility My advice: –Invest some time learning the basic diagrams –Try it out for a small application of your own You’ll learn to see when it is useful and when it is overhead –Do not impose it on your team Use of UML should be agreed by all members