Notacion uml

4,365 views

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,365
On SlideShare
0
From Embeds
0
Number of Embeds
2,899
Actions
Shares
0
Downloads
20
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Notacion uml

  1. 1. Object-Oriented Software EngineeringConquering Complex and Changing Systems Chapter 2, Modeling with UML
  2. 2. Overview♦ What is modeling?♦ What is UML?♦ Use case diagrams♦ Class diagrams♦ Sequence diagrams♦ Activity diagrams♦ SummaryBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
  3. 3. Systems, Models, and Views♦ A model is an abstraction describing system or a subset of a system♦ A view depicts selected aspects of a model♦ A notation is a set of graphical or textual rules for representing views♦ Views and models of a single system may overlap each otherBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3
  4. 4. Systems, Models, and Views Flightsimulator Blueprints Airplane Model 2 View 2 View 1 System View 3 Model 1 Electrical Wiring Scale ModelBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4
  5. 5. Models, Views, and Systems (UML) * * System Model View described by depicted by airplane:System scaleModel:Model flightSimulator:Model blueprints:View fuelSystem:View electricalWiring:ViewBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5
  6. 6. Why model software?Software is already an abstraction: why model software?♦ Software is getting larger, not smaller  NT 5.0 ~ 40 million lines of code  A single programmer cannot manage this amount of code in its entirety.♦ Code is often not directly understandable by developers who did not participate in the development♦ We need simpler representations for complex systems  Modeling is a mean for dealing with complexityBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6
  7. 7. Concepts and Phenomena♦ Phenomenon: An object in the world of a domain as you perceive it, for example:  The lecture you are attending  My black watch♦ Concept: Describes the properties of phenomena that are common, for example:  Lectures on software engineering  Black watches♦ A concept is a 3-tuple:  Its Name distinguishes it from other concepts.  Its Purpose are the properties that determine if a phenomenon is a member of a concept.  Its Members are the phenomena which are part of the concept.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7
  8. 8. 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.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8
  9. 9. Concepts In Software: Type and Instance♦ Type:  An abstraction in the context of programming languages  Name: int, Purpose: integral 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 relationship between “type” and “instance” is similar to that of “concept” and “phenomenon.”♦ Abstract data type:  Special type whose implementation is hidden from the rest of the system.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9
  10. 10. Class♦ 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 Watch time date SetDate(d) CalculatorWatch calculatorState EnterCalcMode() InputNumber(n)Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10
  11. 11. Object-Oriented Modeling Application Domain Solution Domain Application Domain Model System Model TrafficControl UML Package MapDisplay SummaryDisplay TrafficController FlightPlanDatabase Aircraft FlightPlan Airport TrafficControlBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11
  12. 12. Application and Solution Domain♦ Application Domain (Requirements Analysis):  The environment in which the system is operating♦ Solution Domain (System Design, Object Design):  The available technologies to build the systemBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12
  13. 13. What is 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: “The Unified Modeling Language User Guide”, Addison Wesley, 1999.♦ Supported by several CASE tools  Rational ROSE  Together/J  ...Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13
  14. 14. UML and This Course♦ You can model 80% of most problems by using about 20% UML♦ In this course, we teach you those 20%Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14
  15. 15. UML First Pass♦ Use case diagrams  Describe the functional behavior of the system as seen by the user.♦ Class diagrams  Describe the static structure of the system: Objects, Attributes, and Associations.♦ Sequence diagrams  Describe the dynamic behavior between actors and the system and between objects of the system.♦ Statechart diagrams  Describe the dynamic behavior of an individual object as a finite state machine.♦ Activity diagrams  Model the dynamic behavior of a system, in particular the workflow, i.e. a flowchart.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15
  16. 16. UML First Pass: Use Case Diagrams Package SimpleWatch Actor ReadTime SetTime WatchUser WatchRepairPerson Use case ChangeBattery Use case diagrams represent the functionality of the system from user’s point of viewBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16
  17. 17. UML First Pass: Class Diagrams ClassMultiplicity SimpleWatch Association 1 1 1 1 2 1 2 1 PushButton LCDDisplay Battery Time state blinkIdx push() blinkSeconds( load() now() release() ) blinkMinutes( ) blinkHours() stopBlinking( ) Operations Attributes referesh() Class diagrams represent the structure of the system Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17
  18. 18. UML First Pass: Sequence Diagram Object :SimpleWatch :LCDDisplay :Time :WatchUser pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButtons1And2() commitNewTime() stopBlinking() Message Activation Sequence diagrams represent the behavior as interactionsBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18
  19. 19. UML First Pass: Statechart Diagrams Initial state StateEvent button1&2Pressed button2Pressed Blink Increment Hours Hours Transition button1Pressed button1&2Pressed button2Pressed Blink Increment Minutes Minutes button1Pressed button1&2Pressed button2Pressed Stop Blink Increment Blinking Seconds Seconds Final state button1&2Pressed Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19
  20. 20. Other UML NotationsUML provide other notations that we will be introduced in subsequent lectures, as needed.♦ Implementation diagrams  Component diagrams  Deployment diagrams  Introduced in lecture on System Design♦ Object Constraint Language (OCL)  Introduced in lecture on Object DesignBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20
  21. 21. UML Core Conventions♦ Rectangles are classes or instances♦ Ovals are functions or use cases♦ Instances are denoted with an underlined names  myWatch:SimpleWatch  Joe:Firefighter♦ Types are denoted with nonunderlined names  SimpleWatch  Firefighter♦ Diagrams are graphs  Nodes are entities  Arcs are relationships between entitiesBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21
  22. 22. UML Second Pass: Use Case Diagrams Used during requirements elicitation to represent external behavior ♦ Actors represent roles, that is, a type Passenger 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 PurchaseTicketBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22
  23. 23. Actors ♦ 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 Passenger description. ♦ Examples:  Passenger: A person in the train  GPS satellite: Provides the system with GPS coordinatesBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23
  24. 24. Use Case A use case represents a class of functionality provided by the system as an event flow. A use case consists of:PurchaseTicket ♦ Unique name ♦ Participating actors ♦ Entry conditions ♦ Flow of events ♦ Exit conditions ♦ Special requirements Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24
  25. 25. Use Case ExampleName: Purchase ticket Event flow: 1. Passenger selects the numberParticipating actor: Passenger of zones to be traveled. 2. Distributor displays the amountEntry condition: due.♦ Passenger standing in front 3. Passenger inserts money, of of ticket distributor. at least the amount due.♦ Passenger has sufficient 4. Distributor returns change. money to purchase ticket. 5. Distributor issues ticket.Exit condition: Anything missing?♦ Passenger has ticket. Exceptional cases!Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25
  26. 26. The <<extend>> Relationship ♦ <<extend>> relationships represent exceptional or seldom invoked cases. ♦ The exceptional event flows are factored out of the main event flow Passenger for clarity. ♦ Use cases representing exceptional flows can extend more than one use case. PurchaseTicket ♦ The direction of a <<extend>> relationship is to the extended use <<extend>> case <<extend>> <<extend>>OutOfOrder <<extend>> TimeOut Cancel NoChange Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26
  27. 27. The <<include>> Relationship ♦ An <<include>> relationship represents behavior that is factored out Passenger of the use case. ♦ An <<include>> represents PurchaseMultiCard behavior that is factored out for reuse, not because it is anPurchaseSingleTicket exception. <<include>> ♦ The direction of a <<include>> <<include>> relationship is to the using use case (unlike <<extend>> relationships). CollectMoney <<extend>> <<extend>> NoChange Cancel Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27
  28. 28. Class Diagrams TariffSchedule Trip zone:Zone Enumeration getZones() price:Price * * Price getPrice(Zone)♦ Class diagrams represent the structure of the system.♦ Class diagrams are used  during requirements analysis to model problem domain concepts  during system design to model subsystems and interfaces  during object design to model classes.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28
  29. 29. Classes TariffSchedule Table zone2price Enumeration getZones() Name Price getPrice(Zone) TariffSchedule zone2price Attributes Signature getZones() getPrice() Operations TariffSchedule♦ A class represent a concept.♦ 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.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29
  30. 30. Instances tariff_1974:TarifSchedule zone2price = { {‘1’, .20}, {‘2’, .40}, {‘3’, .60}}♦ 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.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30
  31. 31. Actor vs. Instances♦ What is the difference between an actor and a class and an instance?♦ Actor:  An entity outside the system to be modeled, interacting with the system (“Pilot”)♦ Class:  An abstraction modeling an entity in the problem domain, inside the system to be modeled (“Cockpit”)♦ Object:  A specific instance of a class (“Joe, the inspector”).Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31
  32. 32. Associations TarifSchedule Trip Enumeration getZones() price * * zone Price getPrice(Zone) ♦ Associations denote relationships between classes. ♦ The multiplicity of an association end denotes how many objects the source object can legitimately reference.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32
  33. 33. 1-to-1 and 1-to-Many Associations Has-capital Country City 1 1 name:String name:String 1-to-1 association Polygon 1 * Point x:Integer y:Integer draw() 1-to-many associationBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33
  34. 34. Aggregation ♦ An aggregation is a special case of association denoting a “consists of” hierarchy. System 1 0..2 Muffler TailpipeBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34
  35. 35. Composition♦ A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate. TicketMachine 3 ZoneButtonBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35
  36. 36. Generalization Button CancelButton ZoneButton♦ Generalization relationships denote inheritance between classes.♦ The children classes inherit the attributes and operations of the parent class.♦ Generalization simplifies the model by eliminating redundancy.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36
  37. 37. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37
  38. 38. UML Sequence Diagrams ♦ Used during requirements analysis TicketMachine  To refine use case descriptions Passenger  to find additional objects selectZone() (“participating objects”) ♦ Used during system design  to refine subsystem interfaces insertCoins() ♦ Classes are represented by columns ♦ Messages are represented by pickupChange() arrows ♦ Activations are represented by narrow rectangles ♦ Lifelines are represented by pickUpTicket() dashed linesBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38
  39. 39. UML Sequence Diagrams: Messages ZoneButton TarifSchedule Display Passenger selectZone() lookupPrice(selection) price displayPrice(price) Dataflow …to be continued...♦ The source of an arrow indicates the activation which sent the messageBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39
  40. 40. Sequence Diagram Observations♦ UML sequence diagram represent behavior in terms of interactions.♦ Complement the class diagrams which represent structure.♦ Useful to find participating objects.♦ Time consuming to build but worth the investment.Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 40
  41. 41. Activity Diagrams♦ An activity diagram shows flow control within a system Handle Document Archive Incident Incident Incident♦ An activity diagram is a special case of a state chart diagram in which states are activities (“functions”)Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 41
  42. 42. Activity Diagram: Modeling Decisions [lowPriority] Open Allocate Incident Resources [fire & highPriority] [not fire & highPriority] Notify Fire Chief Notify Police ChiefBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 42
  43. 43. Activity Diagrams: Modeling Concurrency♦ Synchronization of multiple activities♦ Splitting the flow of control into multiple threads Splitting Synchronization Allocate Resources Open Coordinate Archive Incident Resources Incident Document IncidentBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 43
  44. 44. Activity Diagrams: Swimlanes♦ Actions may be grouped into swimlanes to denote the object or subsystem that implements the actions. Dispatcher Allocate Resources Open Coordinate Archive Incident Resources Incident FieldOfficer Document IncidentBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 44
  45. 45. 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♦ We concentrate only on a few notations:  Functional model: use case diagram  Object model: class diagram  Dynamic model: sequence diagrams, statechart and activity diagramsBernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 45

×