Notacion uml

50 %
50 %
Information about Notacion uml

Published on September 5, 2012

Author: osced

Source: slideshare.net

Object-Oriented Software EngineeringConquering Complex and Changing Systems Chapter 2, Modeling with UML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37

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

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

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

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

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

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

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

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

Add a comment

Related presentations

Related pages

Unified Modeling Language – Wikipedia

UML definiert weiter grafische Notationen für diese Begriffe und für Modelle statischer Strukturen und dynamischer Abläufe, die man mit diesen Begriffen ...
Read more

UML - Object Management Group

Object Management Group (OMG) provides the newest UML standards, add-ons and features on their site.
Read more

UML 2.1 Notation Übersicht - oose.de

Aktivität Parameter1: Typ Parameter2: Typ [weiter] [stopp] [Bed. 1] [Bed. 2] «datastore» Objektknoten Objektknoten [Zustand] Signal senden Ausgangs ...
Read more

UML-Notationsübersicht | oose Innovative Informatik

Hier finden Sie die aktuelle Notationsübersicht zur UML 2.5 als pdf-Datei unter einer Creative Commons Lizenz.
Read more

Klassendiagramm – Wikipedia

Ein Klassendiagramm ist ein Strukturdiagramm der Unified Modeling Language (UML) zur grafischen Darstellung (Modellierung) von Klassen, Schnittstellen ...
Read more

UML Quick Reference - Holub

UML Quick Reference; Design Patterns Reference (pdf) Videos; ... The UML notation can identify all participating classes if they happen to be in physical ...
Read more

UML - fbi.h-da.de

Die Unified Modeling Language - UML Enstehung der UML. Im Zeitraum Ende der achtziger bis Anfang der neunziger Jahre entstanden mehrere Notationen zur ...
Read more

UML - Basic Notations - Tutorials Point

Unified Modeling Language (UML) Basic Notations - Learning UML in simple and easy steps : A beginner's tutorial containing complete knowledge of UML ...
Read more

UML Notation Summary - University of Michigan

object sends message to itself (one method calls another) message sent (function call) information returned (non-void return) <> < Read more

UML Notation - msdn.microsoft.com

The UML notation represents each of the five primary information types, as discussed in Overall UDDI Model as a class. A box represents each class, and the ...
Read more