Modern methods in Software Engineering UML.

Transcription

1 Modern methods in Software Engineering UML

2 Introduction Content Software modeling (concepts and phenomena) OO modeling UML Use case Diagrams Organizational diagrams Class diagrams Sequence diagrams Communication diagrams Statechart diagrams Activity Diagrams Deployment diagrams

3 Literature used Chapter 2 in the text-book

4 Software modeling What is modeling? Why model software? System, Notation, Models and Views A model is an abstraction describing a subset of a system System A view depicts selected aspects of a model A notation is a set of graphical or textual rules for depicting views Views and models of a single system may overlap each other Aircraft Blueprints Model 1 View 1 Model 2 Flightsimulator Scale model View 2 View 3 Electrical Wiring

5 Concepts and Phenomena Phenomenon An object in the world of a domain as you perceive it Example: The lecture you are attending Concept Describes the properties of phenomena that are common. Example: Lectures in software engineering course Concept is a 3-tuple: Name (To distinguish it from other concepts) Purpose (Properties that determine if a phenomenon is a member of a concept) Members (The set of phenomena which are part of the concept)

6 Concepts and phenomena Name" Purpose" Members" Clock A device that measures time. Abstraction Classification of phenomena into concepts Modeling Development of abstractions to answer specific questions about a set of phenomena while ignoring irrelevant details.

7 Concepts in software Type: An abstraction in the context of programming languages Name: int, Purpose: integer number, Members: 0, -1, 1, 2, -2,... Instance: Member of a specific type The type of a variable represents all possible instances the variable can take The following relationships are similar: type < > instance concept < > phenomenon

8 Software modeling paradigms Procedural paradigm: Software is organized around main the notion of procedures perform transaction credit debit compute interest compute fees Object oriented paradigm: Organizing procedural abstractions in the context of data abstractions Account credit debit CheckingAccount SavingsAccount compute interest compute fees compute interest compute fees

9 Objects, Classes, Inheritance Object combines features of data and procedure Has properties - Represent its state Has behavior set of methods how the object can be manipulated Class A template from which instances of the class (objects) can be created Carrier of properties common to the objects of the class Superclasses Contain features common to a set of subclasses Inheritance hierarchies Show the relationships among superclasses and subclasses Inheritance The implicit possession by all subclasses of features defined in its superclasses

10 Abstract Data Types and Classes Abstract data type Special type whose implementation is hidden from the rest of the system. Class: An abstraction in the context of object-oriented languages Like an abstract data type, a class encapsulates both state (variables) and behavior (methods) Unlike abstract data types, classes can be defined in terms of other classes using inheritance Unlike of classes, abstract data types may have axioms/ constraints on the values of their members Abstract data type is rather mathematical notion while class is a programming notion

11 Object-Oriented Modeling T The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may Application Domain" Application Domain Model" TrafficControl Solution Domain" System Model" SummaryDisplay MapDisplay Aircraft TrafficController FlightPlanDatabase FlightPlan Airport TrafficControl

12 UML UML (Unified Modeling Language) An emerging standard for modeling object-oriented software. Resulted from the convergence of notations from three leading object-oriented methods: OMT (James Rumbaugh) OOSE (Ivar Jacobson) Booch (Grady Booch) Reference: Quick reference: Supported by several CASE tools IBM Rational ROSE

13 UML: Brief overview Use case Diagrams Describe the functional behavior of the system as seen by the user. Organizational diagrams Packaging and components Class diagrams Describe the static structure of the system: Objects, Attributes, Associations Sequence diagrams Describe the dynamic behavior between actors and the system and between objects of the system Communication diagrams Alternative presentation of sequence diagrams State diagrams Describe the dynamic behavior of an individual object (essentially a finite state automaton) Activity Diagrams Model the dynamic behavior of a system, in particular the workflow (essentially a flowchart) Component diagrams Show structure of components Deployment diagrams Used to model the hardware that will be used to implement the system

14 Use Case Diagrams Package" Watch" Use case" Actor" ReadTime" WatchUser" SetTime" WatchRepairPerson" ChangeBattery"

15 Class diagrams Association" Class" Multiplicity" Watch PushButton state push() release() 1 LCDDisplay bitmap blinkseconds() blinkminutes() blinkhours() stopblinking() referesh() 2 Battery load 1 Time now Attribute" Operations"

16 Sequence diagrams Actor" Object" :WatchUser :Watch :LCDDisplay :Time pressbutton1() blinkhours() pressbutton1() blinkminutes() Message" pressbutton2() incrementminutes() refresh() pressbuttons1and2() stopblinking() commitnewtime() Activation" Lifeline"

17 Event" Statechart Diagrams Initial state" State" [button1&2pressed] BlinkHours [button2pressed] IncrementHrs Transition" [button1pressed] [button1&2pressed] BlinkMinutes [button2pressed] IncrementMin. [button1pressed] [button1&2pressed] [button2pressed] BlinkSeconds IncrementSec. StopBlinking Final state"

18 Activity diagrams Buy Watch Use Watch Repair Watch StopUsing Watch LookingFor NewWatch

19 UML conventions Rectangles are classes or instances Ovals are functions or use cases Instances are denoted with an underlined names mywatch:simplewatch :Firefighter Types/concepts are denoted with non underlined names SimpleWatch Firefighter Diagrams are graphs Nodes are entities Arcs are relationships between entities

20 UML Diagams Use case Diagrams Organizational diagrams Class diagrams Sequence diagrams Communication diagrams Statechart diagrams Activity Diagrams Component and Deployment diagrams

21 Use Case Diagrams (more details) Used during requirements elicitation to represent external behavior Actors represent roles, that is, a type of user of the system Use cases represent a sequence of interaction for a type of functionality The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment Passenger PurchaseTicket

22 Actors and Use cases Passenger An actor models an external entity which communicates with the system: User External system Physical environment An actor has a unique name and an optional description. Examples: Passenger: A person in the train GPS satellite: Provides the system with GPS coordinates PurchaseTicket A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements

23 Use Case description Name: Purchase ticket Participating actor(s): Passenger Entry condition: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Exit condition: Passenger has ticket. Quality conditions:! Time constraints Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. Anything missing?" Exceptional cases!"

24 The <<extend>> Relationship Passenger PurchaseTicket <<extend>> <<extend>> <<extend>> OutOfOrder <<extend>> TimeOut Cancel NoChange <<extend>> relationships typically represent exceptional or seldom invoked cases. Use cases representing exceptional flows can extend more than one use case. The direction of a <<extend>> relationship is to the extended use case

25 The <<include>> relationship <<include>> relationship represents behavior that is factored out of the use case. <<include>> behavior is factored out for reuse, not because it is an exception. The direction of a <<include>> relationship is to the using use case (unlike <<extend>> relationships). Passenger PurchaseMultiCard PurchaseSingleTicket <<include>> <<include>> <<extend>> NoChange CollectMoney <<extend>> Cancel

26 Generalization (Inheritance relationships) Generalization between Use Cases Generalization between Actors payment" paymentcard" paymentcash" More general actor role name Passenger" Specialized actor role name

27 Another Use Case Diagram Cinema Employee Create/Update/Delete Movie Database Corporate Database Create/Update/Delete Screenings Database <<include>> MovieGoer Display Movie Details <<extend>> Retrieve Movie Details <<include>> Display Screenings Details Retrieve Screenings Details Adopted from Maciaszek

28 Use Case Diagrams (summary) Use case diagrams represent behavior from external view Use case diagrams are useful as an index into the use cases Use case descriptions provide meat of model, not the use case diagrams. All use cases need to be described for the model to be useful.

29 Class Diagrams Class diagrams represent the structure of the system. Used during requirements analysis to model problem domain concepts during system design to model subsystems and interfaces during object design to model classes.

30 Class Diagrams (Classes) Visibility" TarifSchedule! zone2price! getzones()! getprice()! Name" Attributes" Operations" TarifSchedule! - Zone2price: Table! +getzones():void! +getprice(zone:int):int! Signature" Type" TarifSchedule! A class represents a concept and it has a name A class encapsulates state (attributes) and behavior (operations). Each attribute has a type. Each operation has a signature. The class name is the only mandatory information.

31 Class Diagrams (Instances) tarif_1974:tarifschedule zone2price = {{ 1,.20}, { 2,.40},{ 3,.60}} LastUpdate:String= 2004/12/15 An instance represents a phenomenon. The name of an instance is underlined and can contain the class of the instance. The attributes are represented with their values.

32 Class Diagrams (Associations) Has-capital! Country" 1 1 City" name:string" name:string" One-to-one association Polygon" 1 *" Point" x: Integer" draw()" One-to-many association y: Integer" Company" 1 *" Person" Employer" Employee" One-to-many association

33 Class Diagrams (Associations) Many-to-Many Associations StockExchange * Lists * Company tickersymbol Polygon" *" *" Point" x: Integer" draw()" y: Integer"

34 From Problem Statement To Object Model Problem Statement: A stock exchange lists many companies. Each company is uniquely identified by a ticker symbol Class Diagram:! StockExchange *" Lists *" Company tickersymbol Java Code (incomplete)! public class StockExchange { private Vector m_company = new Vector(); }; public class Company { public int m_tickersymbol; private Vector m_stockexchange = new Vector(); };

35 Class Diagrams (Aggregation) An aggregation is a special case of association denoting a consists of hierarchy. The aggregate is the parent class, the components are the children class. Exhaust system" 1" 0..2" Muffler" diameter" Tailpipe" diameter" A solid diamond denotes composition, a strong form of aggregation where components cannot exist without the aggregate. TicketMachine! 3" ZoneButton!

36 Class Diagrams (Qualifiers) Without qualification" Directory" 1" *" File" filename" With qualification" Directory" filename" 1" 0..1" File" Qualifiers can be used to reduce the multiplicity of an association.

37 Class Diagrams (Qualifiers) StockExchange 1" Lists 1" tickersymbol SX_ID Company

38 Class Diagrams (Inheritance) Button! CancelButton! ZoneButton! The children classes inherit the attributes and operations of the parent class. Inheritance simplifies the model by eliminating redundancy.

39 More examples * FileSystemElement * 1 Directory File

40 Class Diagrams (Association class) Assignment startdate : double role : double contractdate : double Contractor * * Project

41 Class Diagrams (End Notations and Association) Allocates FieldOfficer role:string notificationtime:time Incident name:string badgenumber:integer resources 1..* 1 incident FieldOfficer name:string badgenumber:integer 1 1..* resources Allocation role:string notificationtime:time 1 incident 1 Incident

42 Interaction Diagrams Interaction diagrams are the main design-level behavior modeling technique in UML Sequence diagrams Communication diagrams Interactions diagram is a graphical visualization of sequences of messages between objects Object receiving a message activates the relevant method. The time when the flow of control is focused in an object is called activation

43 Sequence Diagrams Used during requirements analysis To refine use case descriptions to find additional objects ( participating objects ) Used during system design to refine subsystem interfaces Objects participating in the interaction are represented by columns Messages are represented by arrows Activations are represented by narrow rectangles Lifelines are represented by dashed lines :TicketMachine Passenger selectzone() insertcoins() pickupchange() pickupticket()

44 Sequence Diagrams Passenger :ZoneButton :TarifSchedule :Display selectzone() lookupprice(selection) Dataflow" price displayprice(price) to be continued..." The source of an arrow indicates the activation which sent the message An activation is as long as all nested activations Horizontal arrows indicate data flow Vertical dashed lines indicate lifelines

45 Sequence Diagrams (Iteration & condition) continued from previous slide..." Passenger :ChangeProcessor :CoinIdentifier :Display :CoinDrop loop [owedamount>0] insertchange(coin)" lookupcoin(coin) price displayprice(owedamount) returnchange(-owedamount) " to be continued..."

46 Sequence Diagrams (branches) a b c alt [i>0] op1() [else] op2()

47 Sequence Diagrams (Creation and destruction) continued from previous slide..." Passenger :ChangeProcessor createticket(selection) Creation" print() :Ticket free() Destruction" Creation is denoted by a message arrow pointing to the object. Destruction is denoted by an X mark at the end of the destruction activation. In garbage collection environments, destruction can be used to denote the end of the useful life of an object.

48 Example :SimpleWatch :Display :Time :WatchUser pressbutton1and2() blinkhours() pressbutton1() blinkminutes() loop pressbutton2() [button2 pressed] incrementminutes() refresh() pressbuttons1and2() stopblinking() commitnewtime()

49 Some other example 2005, Allen I. Holub ( All rights reserved.

50 Sequence Diagrams (Summary) UML sequence diagram represent behavior in terms of interactions. Useful to find missing objects. Time consuming to build but worth the investment. Complement the class diagrams (which represent structure).

51 Communication diagrams :2BwatchOwner 1:pressButtons1And2() 2:pressButton1() 3:pressButton2() 4*[button2pressed]: 5:pressButtons1And2() :2BwatchInput 1.1: blinkhours() 2.1:blinkMinutes() 5.2:stopBlinking() :2BwatchDisplay 4.1:incrementMinutes() 5.1:c ommitnewtime() :2BwatchTime 4.2:r efresh()

52 State Charts pressbuttonslandr MeasureTime SetTime after 2 min. after 20 years pressbuttonslandr/beep after 20 years DeadBattery

53 State Chart Diagrams [button1&2pressed] BlinkHours [button2pressed] IncrementHrs [button1pressed] [button1&2pressed] BlinkMinutes [button2pressed] IncrementMin. [button1pressed] [button1&2pressed] [button2pressed] BlinkSeconds IncrementSec. StopBlinking Represent behavior as states and transitions"

54 Internal transitions pressbothbuttons MeasureTime do/count ticks SetTime entry/blink hours pressbutton1/blink next number pressbutton2/increment current number exit/stop blinking after 2 min. pressbothbuttons/beep after 20 years after 20 years MeasureTime

55 State Chart Diagrams (nested charts) Movie Details Known buy it[ finances approved ] / sendpurchaseorder () Purchased for Screening screen it[ movie arrived ] Screening / schedule It () [ opening date ] Currently Screening [ closing date ] Scheduled for Screening withdraw Withdrawn from Screens Adopted from Maciazcek

56 Activity Diagrams An activity diagram shows flow control within a system Handle Incident Document Incident Archive Incident An activity diagram is a special case of a state chart diagram in which states are activities ( functions ) Two types of states: Action state: Cannot be decomposed any further Happens instantaneously with respect to the level of abstraction used in the model Activity state: Can be decomposed further The activity is modeled by another activity diagram

57 Statechart Diagram vs. Activity Diagram Statechart Diagram for Incident" (State: Attribute or Collection of Attributes of object of type Incident)" Active" Inactive" Closed" Archived" Incident-! Incident-! Incident-! Handled" Documented" Archived" Activity Diagram for Incident" (State: Operation or Collection of Operations) " Event causes" State transition" Handle Incident Document Incident Archive Incident Completion of activity " causes state transition" Triggerless" Transition"

58 Object flow Receive Invoice [paid] [else] Process Invoice Send Payment Cut Check

59 Object flow 2005, Allen I. Holub ( All rights reserved.

60 Activity Diagrams: Modeling Concurrency Synchronization of multiple activities Splitting the flow of control into multiple threads Splitting (fork)" Al loc ate Re sou rce s Synchronization (join)" Op en In cid ent Co ord ina te Re sou rce s Ar chi ve In cid ent Do cum ent In cid ent

61 Activity Diagrams: Swimlanes Actions may be grouped into swimlanes to denote the object or subsystem that implements the actions. Allocate" Resources" Dispatcher" Open" Incident" Coordinate" Resources" Archive" Incident" Document" Incident" FieldOfficer"

62 Component and Deployment diagrams Models for physical implementation of the system Show system components, their structure and dependencies and how they are deployed on computer nodes Two kinds of diagrams: component diagrams deployment diagrams Component diagrams show structure of components, including their interface and implementation dependencies Deployment diagrams show the runtime deployment of the system on computer nodes

63 Component Diagrams (component interface) PaymentTransaction <<component>> OnLinePayment IdentityManagement <<interface>> PaymentTransaction begin() commit() rollback() addlineitem() deletelineitem() <<component>> OnLinePayment <<use>> <<interface>> IdentifyManagement authenticate() Adopted from Shaum

64 Component Diagram PaymentTransaction <<component>> OnLinePayment EPayDay IdentityManagement <<component>> InsuranceBrokerage <<component>> MemberManagement Adopted from Shaum

65 Component Diagram (component realization) PaymentTransaction IdentityManagement <<component>> OnLinePayment <<realization>> Payment PaymentItem PaymentController Payment PaymentItem PaymentController Adopted from Shaum

66 Deployment diagrams Web-Server <<TCP/IP>> PC madrid:pcclient stockholm:pcclient dehli:pcclient <<TCP/IP>> <<TCP/IP>> <<TCP/IP>> boss:pcserver Adopted from Shaum

67 Deployment diagrams :MainServer <<J2EE Container>> :JBossServer <<device>> :CertifiedClock Adopted from Shaum

68 Packages A package is a UML mechanism for organizing elements into groups (usually not an application domain concept) Packages are the basic grouping construct with which you may organize UML models to increase their readability. DispatcherInterface Notification IncidentManagement A complex system can be decomposed into subsystems, where each subsystem is modeled as a package

69 Packages Adopted from Holub

70 Packages IncidentManagement Report Emergency OpenIncident Dispatcher FieldOfficer AllocateResources IncidentArchive SysAdministration ArchiveIncident ManageUsers Librarian SearchArchive ManageTerminals SysAdmin

71 Packages FieldStation DispatcherStation FieldOfficer Dispatcher EmergencyReport Incident

72 Notes FieldStation DispatcherStation FieldOfficer Dispatcher EmergencyReport The Emer gencyreport class is defined in FieldStation and used in both stations. Incident

73 Extensions Stereotypes «entity» Year «entity» Month «control» ChangeDateControl «entity» Day «boundary» ButtonBoundary «boundary» LCDDisplayBoundary Constraint EmergencyReport reports 1 Incident 1..* {ordered by time of receipt}

74 UML Summary UML provides a wide variety of notations for representing many aspects of software development Powerful, but complex language Can be misused to generate unreadable models Can be misunderstood when using too many exotic features For now we concentrate on a few notations: Functional model: Use case diagram Object model: class diagram Dynamic model: sequence diagrams, statechart and activity diagrams

75 Next lecture Requirements elicitation Chapter 4 in the text-book