Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.

Slides:



Advertisements
Similar presentations
UML and Classes, Objects and Relationships [1]
Advertisements

Chapter 3 Requirements Analysis, Negotiation and Modeling Part 3 Dr. Eman Al-Maghary Requirements Engineering.
Use cases Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself A set.
Case Study Lecture 4 UML Huma Ayub Department of Software Engineering
Modeling Main issues: What do we want to build How do we write this down ©2008 John Wiley & Sons Ltd. vliet.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
UML Class and Sequence Diagrams Violet Slides adapted from Marty Stepp, CSE 403, Winter 2012 CSE 403 Spring 2012 Anton Osobov.
Ch 12: Object-Oriented Analysis
©The McGraw-Hill Companies, Inc. Permission required for reproduction or display. 4 th Ed Chapter Chapter 4 Defining Your Own Classes.
Associations The relations is_a and has_a are fundamental ways to understand collections of classes. In an OO implementation these relations will.
Designing Classes Chapter 3. 2 Chapter Contents Encapsulation Specifying Methods Java Interfaces Writing an Interface Implementing an Interface An Interface.
©The McGraw-Hill Companies, Inc. Permission required for reproduction or display. 4 th Ed Chapter Software Development Software Life Cycle UML Diagrams.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
©TheMcGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 1 Introduction to Object-Oriented Programming and Software Development.
1 CSC 1401 S1 Computer Programming I Hamid Harroud School of Science and Engineering, Akhawayn University
Classification of UML Diagrams
©TheMcGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 1 Introduction to Object-Oriented Programming and Software Development.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Object-oriented design Part 4: More UML. Interfaces An interface is a language construct specific to Java Java does not support multiple inheritance Interfaces.
Use Case Modeling. Use case diagram For each use case we develop  Object class diagram (with attributes only)  System sequence diagram (analysis) 
Unified Modeling Language
Unified Modeling Language
The Unified Modeling Language (UML) Class Diagrams.
Object-Oriented Analysis and Design
UML for Java Programmers Object Mentor, Inc. Copyright  by Object Mentor, Inc All Rights Reserved
Things and Relations - Examples Things Relationships Structural Behavioral Grouping Annotational Dependency Association Generalization Realization Class,
Chapter 11 Inheritance and Composition. Chapter Objectives Learn about inheritance Learn about subclasses and superclasses Explore how to override the.
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
An Introduction to Java Chapter 11 Object-Oriented Application Development: Part I.
1 UML Basic Training. UML Basic training2 Agenda  Definitions: requirements, design  Basics of Unified Modeling Language 1.4  SysML.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Domain Modeling Part2: Domain Class Diagram Chapter 4 pp part 2 1.
UML Diagrams A tool for presentation of Architecture.
Lecture 8 Object-Oriented Analysis and Design 20.1 COSC4406: Software Engineering.
UML Class Diagrams 1 These lecture slides are copyright (C) Marty Stepp, They may not be rehosted, sold, or modified without expressed permission.
Java The Java programming language was created by Sun Microsystems, Inc. It was introduced in 1995 and it's popularity has grown quickly since A programming.
Copyright © 2014 by John Wiley & Sons. All rights reserved.1 Interfaces.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Designing Classes Chapter 3. 2 Chapter Contents Encapsulation Specifying Methods Java Interfaces Writing an Interface Implementing an Interface An Interface.
CS 772: Global Knowledge Networks V. “Juggy” Jagannathan CSEE, West Virginia University.
Appendix D UML at a Glance Summary prepared by Kirk Scott 1.
Design Model Lecture p6 T120B pavasario sem.
CSE 219 Computer Science III UML. UML Diagrams UML - Unified Modeling Language UML diagrams are used to design object-oriented software systems –represent.
© 2010 John Wiley & Sons Ltd. Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
CSC 1010 Programming for All Lecture 3 Useful Python Elements for Designing Programs Some material based on material from Marty Stepp, Instructor, University.
UML (Unified Modeling Language)
INFSY 535.  Small systems  Larger systems 1.Understand the program requirement- what 3. Write and test each part (unit testing) 4. Maintenance 2. Specify.
Inheritance and Subclasses CS 21a. 6/28/2004 Copyright 2004, by the authors of these slides, and Ateneo de Manila University. All rights reserved L16:
Chapter 3: Introducing the UML
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
Unified Modeling Language (UML)
Inf 43: Introduction to Software Engineering May 7, 2016.
CS 350 – Software Design UML – The Unified Modeling Language – Chapter 2 The Unified Modeling Language is a visual language used to create models of programs.
COP 3330 Notes 4/13. Today’s Topics UML Class Diagrams.
Chapter 12 – Object-Oriented Design
Object-Oriented Analysis and Design
Unified Modeling Language
Ch 12-13: OOD and Recursion Yonglei Tao.
Chapter 3: Using Methods, Classes, and Objects
About the Presentations
COMP2110 Software Design in 2004 lecture 09 High level design
Abstract descriptions of systems whose requirements are being analysed
A tool for presentation of Architecture
A tool for presentation of Architecture
Slides by Steve Armstrong LeTourneau University Longview, TX
CIS 375 Bruce R. Maxim UM-Dearborn
4 REQUIREMENTS ANALYSIS CASE STUDY
CIS 375 Bruce R. Maxim UM-Dearborn
Object Oriented System Design Class Diagrams
Presentation transcript:

Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1

© 2010 John Wiley & Sons Ltd. Chapter 16: Unified Modeling Language 2

Learning Goals of This Chapter What is the UML notation for classes and packages of classes? How does UML represent class relationships such as inheritance, aggregation, and dependency? What is a sequence diagram? How are UML activity diagrams related to flow charts? Requirements analysis Design Implementation Testing Maintenance Planning The Software Development Lifecycle Phase most relevant to this chapter is shown in bold © 2010 John Wiley & Sons Ltd. 3

Classes at Detailed Design + numCanisters: int - numWafers: int - size: float Canister Class name Attribute: type wafer canister © 2010 John Wiley & Sons Ltd. 4

Classes at Detailed Design Responsibilities: -- describes each canister undergoing fabrication + display() - getNumOpenSlots() + setStatus() + numCanisters: int - numWafers: int - size: float Canister Class name Attribute: type Operations Place for comments +:Visible from without wafer canister © 2010 John Wiley & Sons Ltd. 5

package of classes package myPackage; class MyFirstClass { … } UML Notation … and … Typical Implementation package myPackage.mySubPackage; class MyClass { … } mySubPackage myPackage © 2010 John Wiley & Sons Ltd. 6

public package myPackage; class MySecondClass { … } package of classes package myPackage; class MyFirstClass { … } UML Notation … and … Typical Implementation MyFirstClass «hidden» «visible» acccessibility of classes from outside package package myPackage.mySubPackage; class MyClass { … } mySubPackage MyClass MySecondClass myPackage sub-package © 2010 John Wiley & Sons Ltd. 7

class Employer { Employee[ ] employees;..... } class Employee { Employer[ ] employers;..... } EmployerEmployee Association : UML Notation employs is employed by © 2010 John Wiley & Sons Ltd. 8

EmployerEmployee Multiplicity : UML Notation 1..* 1..3 employs is employed by Personalnfo 1 © 2010 John Wiley & Sons Ltd. 9

abstract class package MyPackage; abstract class MyAbstractClass UML Notation … and … Typical Implementation MyPackage MyAbstractClass © 2010 John Wiley & Sons Ltd. 10

abstract class package MyPackage; abstract class MyAbstractClass.... package MyPackage; class MyDerivedClass extends MyAbstractClass { int att;..... void myFunction( ReferencedClass r ) {... } } MyDerivedClass att: int myFunction() UML Inheritance … and … Typical Implementation MyPackage attribute operation inheritance MyAbstractClass © 2010 John Wiley & Sons Ltd. 11

interface interface MyAbstractClass.... class MyClass implements MyInterface {..... } MyClass myMethod() Interfaces UML Notation …… Typical Java Implementation realization MyInterface myMethod() © 2010 John Wiley & Sons Ltd. 12

class Company { Employee emp; int att;..... } Company att: int myFunction() Employee emp aggregation Aggregation : UML Notation and Typical Implementation * EmployeeDirectory att: int myFunction() emp * class EmployeeDirectory { Employee emp; int att;..... } aggregation © 2010 John Wiley & Sons Ltd. 13

class Company { class Employee emp; {... }..... } Company att: int myFunction() Employee emp composition Composition: UML Notation and Typical Implementation * EmployeeDirectory att: int myFunction() emp * class EmployeeDirectory { class Employee emp; {... }..... } composition © 2010 John Wiley & Sons Ltd. 14

class MyClass {..... void myFunction1( MyReferencedClass r ) {... }.... } MyClass att: int myFunction() MyReferencedClass Dependence : UML Notation … and …Typical Implementation dependence (reference to a class) parameter © 2010 John Wiley & Sons Ltd. 15

class MyDependentClass {..... void myFunction1( MyReferencedClass r ) {... } MyReferencedClass myFunction2( … ) {... } void myFunction3( … ) { MyReferencedClass m … } MyDependentClass att: int myFunction() MyReferencedClass Dependence : UML Notation … and …Typical Implementation dependence (reference to a class) parameter or return type or local variable type © 2010 John Wiley & Sons Ltd. 16

Customer Mail Application generat () getCustomerTypeFromUser() main() Customer creat () customer1 © 2010 John Wiley & Sons Ltd. 17

Customer Mail Application generat () getCustomerTypeFromUser() main() Customer creat () DelinquentCustomer creat () MountainCustomer creat () RegularCustomer creat () customer1 © 2010 John Wiley & Sons Ltd. 18

EmployerEmployee Example of an Object Model 1..n 1..3 joe:Employee ajaxCorp:Employer sue:Employee abcCorp:Employer Class Model One Particular Derived Object Model © 2010 John Wiley & Sons Ltd. 19

© 2010 John Wiley & Sons Ltd. 1. read() Sequence Diagram for Check Out Use Case User :BarCodeReader doCheckout() :MainScreen Use case: 1. User swipes bar code 2. Application prompts for rental duration 3. User enters duration 4. Application stores record 5. Application prints customer’s account status 20

© 2010 John Wiley & Sons Ltd. Beginning of Sequence Diagram for Check Out Use Case Clerk :BarCodeReader :Checkout initiate() show() :CheckoutOptionDisplay } Step 1 of use case order doCheckout() :MainScreen read() { Step 2 of use case Originates from use case: 1. User swipes bar code 2. Application prompts for rental duration 3. User enters duration … 21

© 2010 John Wiley & Sons Ltd. 4. store() 2.3 show() 3. setDuration() 1. read() Sequence Diagram for Check Out Use Case User :BarCodeReader doCheckout() :MainScreen This sequence diagram originates from Use case: 1. User swipes bar code 2. Application prompts for rental duration 3. User enters duration 4. Application stores record 5. Application prints customer’s account status :Checkout 2.1 initiate() :CheckoutOptionDisplay :Account 2.2 create() 5. print() 22

EncounterGa me Sequence Diagram Showing Concurrency freddie: ForeignCharacter move mainPlayer- Character: PlayerCharacter create & display move create & display Player © 2010 John Wiley & Sons Ltd. 23

© 2010 John Wiley & Sons Ltd. 1. Identify the use case whose sequence diagram you will build (if applicable). 2. Identify which entity initiates the use case – the user, or – an object of a class name the class name the object if possible 3. If not the user, draw a rectangle to represent this initiating object at left top – use UML object:Class notation 4. Draw an elongated rectangle beneath this to represent the execution of the operation initiating the process 5. Draw an arrow pointing right from it Building a Sequence Diagram 1 myObject :MyClass 24

© 2010 John Wiley & Sons Ltd. Building a Sequence Diagram 2 6. Identify which entity handles the operation initiated – an object of a class name the class name the object 7. Label the arrow with the name of the operation 8. Show a process beginning, using an elongated rectangle 9…… Continue with each new statement of the use case. myObject :MyClass myObject1 :MyClass1 operation() 25

CheckingOut State/Transition Diagram for OnlineShopper Class Browsing ItemsChosen select item © 2010 John Wiley & Sons Ltd. 26

Hit checkout button CheckingOut State/Transition Diagram for OnlineShopper Class Browsing ItemsChosen CreditUnderValidation CreditDenied Complete Incomplete hit Submit button [credit card data incomplete] [credit card data complete] put back last item select item hit OK validation received denial received hit OK hit Quit select item © 2010 John Wiley & Sons Ltd. 27

Conditions on Events CreditUnderValidation Incomplete Hit Submit button [credit card data incomplete] [credit card data complete] © 2010 John Wiley & Sons Ltd. 28

Activity Diagram Example protected final void setName( String aName ) { // Check legitimacy of parameter and settings if( ( aName == null ) || ( maxNumCharsInName() <= 0 ) || ( maxNumCharsInName() > alltimeLimitOfNameLength() ) ).... Parameter & settings make sense else © 2010 John Wiley & Sons Ltd. 29

Activity Diagram Example protected final void setName( String aName ) { // Check legitimacy of parameter and settings if( ( aName == null ) || ( maxNumCharsInName() <= 0 ) || ( maxNumCharsInName() > alltimeLimitOfNameLength() ) ) { name = new String( "defaultName" ); System.out.println ( "defaultName selected by GameCharacter.setName()"); } else // Truncate if aName too long if( aName.length() > maxNumCharsInName() ) name = new String ( aName.getBytes(), 0, maxNumCharsInName() ); else // assign the parameter name name = new String( aName ); } Nominal path Set name to “defaultName" Truncate name Set name to parameter Parameter & settings make sense else Parameter name too long else Output notification to console © 2010 John Wiley & Sons Ltd. 30

Activity Chart Notation Do Something Do Something More Do A TaskDo Another Task Do Even More else[condition true] } In parallel © 2010 John Wiley & Sons Ltd. 31

Activity Diagram for soughtFact.proveBack() Apply R.proveAntecedents()* Report TRUE Report FALSE else Another rule R exists with soughtFact as its consequent else soughtFact in factList FactRule * Prove that every antecedent fact is true proof succeeded © 2010 John Wiley & Sons Ltd. 32

A Class Model for Chaining Rule addRule() proveAntecedents() forwardChain() Fact content addFact() proveBack() consequent antecedents 1 1..n © 2010 John Wiley & Sons Ltd. 33

A Class Model for Chaining Rule addRule() proveAntecedents() forwardChain() Fact content addFact() proveBack() consequent antecedents static factList static ruleBase 1 1..n © 2010 John Wiley & Sons Ltd. 34

A Class Model for Chaining Rule addRule() proveAntecedents() forwardChain() Fact content addFact() proveBack() consequent antecedents static factList static ruleBase Set Fact.factList to the known facts and a Rule.ruleBase to the known rules. Create Fact object soughtFact Execute soughtFact.proveBack( ruleBase ); 1 1..n © 2010 John Wiley & Sons Ltd. 35

© 2010 John Wiley & Sons Ltd. Data Flow Models in UML Process part order This example is adapted from RJB UML Reference Part order Price list Ship part order Charge Credit card Credit card data Parts list «datastore» Charge amount 36

© 2010 John Wiley & Sons Ltd. Specifications for Figure Drawing  Facilitate drawing stick figures  Drag to vicinity to auto-complete  Feet can be rectangles or ellipses  (Rest to be specified) Releasing dragged figure anywhere in this area causes it to appear in position at end of left leg 37

Bad Attempt: “A Foot is Either an Ellipse or a Rectangle” Foot EllipseRectangle © 2010 John Wiley & Sons Ltd. 38

Better Attempt: “A Foot is Either an Ellipse or a Rectangle” RectangleFoot FootRectangleEllipse EllipseFoot © 2010 John Wiley & Sons Ltd. 39

Another Attempt: “A Foot is Either an Ellipse or a Rectangle” FootFootShape EllipseRectangle © 2010 John Wiley & Sons Ltd. 40

Best Attempt So Far: “A Foot is Either an Ellipse or a Rectangle” Foot draw() FootShape drawAsEllipse() drawAsRectangle() Ellipse draw() Rectangle draw() © 2010 John Wiley & Sons Ltd. 41

© 2010 John Wiley & Sons Ltd. 42

© 2010 John Wiley & Sons Ltd. Sequence Diagram for Figure Drawing Application :FootShape:Foot releaseCursor drawAsEllipse* :Ellipse draw( aPosition ) :Area draw ( GeometricFigure aGeometricFigure ) ( Position aPosition ) ( Leg aLeg, GeometricFigure aGeometricFigure ) * or drawAsRectangle() … 43

© 2010 John Wiley & Sons Ltd. Relationships Between Classes  Package  group of related classes  Inheritance  take on attributes and operations from other classes  “is-a” relationship  e.g. an Employee “is-a” Person  Association  structural relationship between classes  Aggregation  structural inclusion of object on one class by another  “whole-part” relationship …… 44

© 2010 John Wiley & Sons Ltd. Relationships Between Classes  Package  Inheritance  Association  Aggregation  structural inclusion of object on one class by another  “whole-part” relationship  Composition  Stronger form of aggregation  Included object is created and destroyed when including object is created and destroyed  Dependency  one class depends on another  changes to depended on class affects dependent class 45