Your SlideShare is downloading. ×
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
08   class and sequence diagrams
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

08 class and sequence diagrams

3,815

Published on

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

No Downloads
Views
Total Views
3,815
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
109
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. INTROSE Introduction to Software Engineering Raymund Sison, PhD College of Computer Studies De La Salle University [email_address] Modeling Software Systems
  • 2. How do we model complex systems? Epistemology Knowledge about Causality (Dynamic Model) Describes our knowledge about the system Knowledge about Functionality (Functional model) Knowledge about Relationships (Object model) From (Bruegge & Dutoit, 2004) Neural Networks DataFlow Diagrams (SA/SD) Scenarios/Use Cases (Jacobsen) Formal Specifications (Liskov) Petri Nets(Petri) Inheritance Frames,SemanticNetworks (Minsky) Uncertain Knowledge Fuzzy Sets (Zadeh) Data Relationship (E/R Modeling, Chen) Hierarchical Database Model (IMS) Network Database Model (CODASYL) Relational Database Model (Codd) Fuzzy Frames (Graham) Class Diagrams (“E/R + Inheritance”, Rumbaugh) Sequence Diagrams (Lamport) Activity Diagrams (“good old Flowcharts”)
  • 3. How do we model complex systems? Epistemology Knowledge about Causality (Dynamic Model) Describes our knowledge about the system Knowledge about Functionality (Functional model) Knowledge about Relationships (Object model) From (Bruegge & Dutoit, 2004) Neural Networks DataFlow Diagrams (SA/SD) Scenarios/Use Cases (Jacobsen) Formal Specifications (Liskov) Petri Nets(Petri) Inheritance Frames,SemanticNetworks (Minsky) Uncertain Knowledge Fuzzy Sets (Zadeh) Data Relationship (E/R Modeling, Chen) Hierarchical Database Model (IMS) Network Database Model (CODASYL) Relational Database Model (Codd) Fuzzy Frames (Graham) Class Diagrams (“E/R + Inheritance”, Rumbaugh) Sequence Diagrams (Lamport) Activity Diagrams (“good old Flowcharts”)
  • 4. Components of an Object Model
    • Classes
    • Associations (Relations)
      • Kind-of/Is-a (Generalization)
      • Part-of/Has-a (Aggregation)
      • Domain-specific associations
    • Attributes
    • Operations
  • 5. UML Classes
    • A class is simply represented as a box with the name of the class inside
      • The diagram may also show the attributes and operations
      • The complete signature of an operation is:
        • operationName(parameterName: parameterType …): returnType
    Class Diagram slides from (Lethbridge & Laganiere, 2005)
  • 6. Associations and Multiplicity
    • An association is used to show how two classes are related to each other
      • Symbols indicating multiplicity are shown at each end of the association
  • 7. Labelling Associations
      • Each association can be labelled, to make explicit the nature of the association
  • 8. Analyzing and Validating Associations
      • Many-to-one
        • A company has many employees,
        • An employee can only work for one company.
          • This company will not store data about the moonlighting activities of employees!
        • A company can have zero employees
          • E.g. a ‘shell’ company
        • It is not possible to be an employee unless you work for a company
    * worksFor Employee Company 1
  • 9. Analyzing and Validating Associations
      • Many-to-many
        • An assistant can work for many managers
        • A manager can have many assistants
        • Assistants can work in pools
        • Managers can have a group of assistants
        • Some managers might have zero assistants.
        • Is it possible for an assistant to have, perhaps temporarily, zero managers?
    * supervisor * * * * * 1..* Assistant Manager
  • 10. Analyzing and Validating Associations
      • One-to-one
        • For each company, there is exactly one board of directors
        • A board is the board of only one company
        • A company must always have a board
        • A board must always be of some company
    1 1
  • 11. Analyzing and Validating Associations
    • Avoid unnecessary one-to-one associations
    • Avoid this Do this
  • 12. A More Complex Example
      • A booking is always for exactly one passenger
        • no booking with zero passengers
        • a booking could never involve more than one passenger.
      • A Passenger can have any number of Bookings
        • a passenger could have no bookings at all
        • a passenger could have more than one booking
      • The frame around this diagram is an optional feature that any UML 2.0 may possess.
  • 13. Association Classes
      • Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes
      • The following are equivalent
  • 14. Reflexive Associations
      • It is possible for an association to connect a class to itself
  • 15. Directionality in Associations
    • Associations are by default bi-directional
    • It is possible to limit the direction of an association by adding an arrow at one end
  • 16. Generalization
    • Specializing a superclass into two or more subclasses
      • A generalization set is a labeled group of generalizations with a common superclass
      • The label (sometimes called the discriminator ) describes the criteria used in the specialization
  • 17. Avoiding Unnecessary Generalizations Inappropriate hierarchy of classes, which should be instances
  • 18. Avoiding Unnecessary Generalizations Improved class diagram, with its corresponding instance diagram
  • 19. Handling Multiple Discriminators
      • Creating higher-level generalization
  • 20. Handling Multiple Discriminators
      • Using multiple inheritance
  • 21. Object Diagrams
    • A link is an instance of an association (in the same way that we say an object is an instance of a class)
  • 22. Associations vs. Generalizations in Object Diagrams
      • Associations describe the relationships that will exist between instances at run time.
        • When you show an instance diagram generated from a class diagram, there will be an instance of both classes joined by an association
      • Generalizations describe relationships between classes in class diagrams.
        • They do not appear in instance diagrams at all.
        • An instance of any class should also be considered to be an instance of each of that class’s superclasses
  • 23. Aggregation
    • Aggregations are special associations that represent ‘part-whole’ relationships.
      • The ‘whole’ side is often called the assembly or the aggregate
      • This symbol is a shorthand notation association named isPartOf
  • 24. When to Use an Aggregation
    • As a general rule, you can mark an association as an aggregation if the following are true:
      • You can state that
        • the parts ‘are part of’ the aggregate
        • or the aggregate ‘is composed of’ the parts
      • When something owns or controls the aggregate, then they also own or control the parts
  • 25. Composition
    • A composition is a strong kind of aggregation
      • If the aggregate is destroyed, then the parts are destroyed as well
      • Two alternatives for addresses
  • 26. Aggregation Hierarchy
  • 27. Propagation
      • A mechanism where an operation in an aggregate is implemented by having the aggregate perform that operation on its parts
      • At the same time, properties of the parts are often propagated back to the aggregate
      • Propagation is to aggregation as inheritance is to generalization.
        • The major difference is:
          • inheritance is an implicit mechanism
          • propagation has to be programmed when required
  • 28. Interfaces
    • An interface describes a portion of the visible behavior of a set of objects.
      • An interface is similar to a class, except it lacks instance variables and implemented methods
  • 29. Notes and Descriptive Text
      • Descriptive text and other diagrams
        • Embed your diagrams in a larger document
        • Text can explain aspects of the system using any notation you like
        • Highlight and expand on important features, and give rationale
      • Notes :
        • A note is a small block of text embedded in a UML diagram
        • It acts like a comment in a programming language
  • 30. How do we model complex systems? Epistemology Knowledge about Causality (Dynamic Model) Describes our knowledge about the system Knowledge about Functionality (Functional model) Knowledge about Relationships (Object model) From (Bruegge & Dutoit, 2004) Neural Networks DataFlow Diagrams (SA/SD) Scenarios/Use Cases (Jacobsen) Formal Specifications (Liskov) Petri Nets(Petri) Inheritance Frames,SemanticNetworks (Minsky) Uncertain Knowledge Fuzzy Sets (Zadeh) Data Relationship (E/R Modeling, Chen) Hierarchical Database Model (IMS) Network Database Model (CODASYL) Relational Database Model (Codd) Fuzzy Frames (Graham) Class Diagrams (“E/R + Inheritance”, Rumbaugh) Sequence Diagrams (Lamport) Activity Diagrams (“good old Flowcharts”)
  • 31. UML Interaction Diagrams
      • Model the dynamic aspects of the system by showing relationships among objects and the messages they may dispatch
      • Capture the behavior of a single use case
      • Show a number of example objects and the messages that are passed between these objects within the use case
  • 32. UML Interaction Diagrams
    • Sequence Diagram
      • Emphasizes the time ordering of messages
      • Focuses on the chronological course of the messages
    • Collaboration Diagram
      • Emphasizes the organization of the objects that participate in an interaction
      • Focuses on the cooperation among objects
  • 33. UML Collaboration Diagram
      • Shows a set of interactions between selected objects in a specific, limited situation, focusing on the relations between the objects and their topology
      • The chronological course of communication with each other is marked by numbering the messages
      • Shows the chronological sequences of the messages, their names and responses, and their possible arguments
      • One collaboration diagram for each use case
  • 34. Link
      • Links between objects are like associations in the class model
      • Enables objects to send messages
      • There should be an association in the class model between the two link objects
      • Links may be instances of associations that are shown in the class diagram
  • 35. Message
      • Links may be labeled with the names of messages
      • A communication between two objects that conveys information with the expectation that action will ensue
      • An event sent from one object to another
      • An operation being invoked on another object
      • Creation or destruction of an object instance
  • 36. Collaboration Diagram
    • Show objects and links
    • Superimpose messages on links
    a : Assembly part : CatalogEntry 1.1: number = getNumber() 1 : count(part) : Client
  • 37. Collaboration Diagram course_form : CourseForm theManager : CurriculumManager aCourse : Course 4 : <<create>> 3 : add_course() 1 : set_course_info() 2 : process_form() : Registrar
  • 38. Message Sequence
    • Sequence of messages are determined by numbering
    • Defines the order in which the interaction takes place
      • 1, 2, 3, 4, …..
      • 1, 1.1, 1.2, 1.3, 2, 2.1, 2.1.1, 2.2, 3 (shows which operation calls which other operation)
  • 39. Sequence Diagram
      • Used to show the same interaction in a collaboration diagram but emphasize the order of the messages over time
        • Object instances are arranged horizontally across the page
        • Time runs vertically down the page
        • Messages flow from left to right or from right to left
  • 40. Sequence Diagram Time Objects and Message Flows
  • 41. Lifeline
    • Objects are displayed at the top of the diagram
    • The vertical dimension represents time
    • Each object has a dashed line – lifeline – extending below it – to indicate the period of time during which objects playing that role actually exist
    Object Name
  • 42. Message
    • The messages in an interaction are drawn from top to bottom , in the order that they are sent.
    • Messages are shown as arrows pointing from the lifeline of the role sending the message to the lifeline of the receiver.
    • When a message is sent , control passes from the sender of the message to the receiver.
    Object Name Object Name message
  • 43. Return
    • Return of control is shown using dashed arrow returning to the calling object.
    Object Name Object Name message
  • 44. Activation
    • Period of time during which an object is processing a message
    • Shown on a lifeline as a narrow rectangle whose top is connected to a message
    • When an object finishes processing a message, control returns to the sender of the message
  • 45. Sequence Diagram a : Assembly part : CatalogEntry getNumber() count(part) return number Lifeline Activation(optional) Messages control returns to the sender of the message (optional) : Client
  • 46. Hierarchical Numbering of Messages 1.1 1 1.2 2 2.1 2.2 2.2.1 2.1.1 2.1.2
  • 47. Object Creation course_form : CourseForm theManager : CurriculumManager aCourse : Course set_course_info process_form add_course <<create>> Object creation : Registrar
  • 48. Object Creation: Order Entry Example Order OrderLine quantity: integer cost: float CatalogEntry 1 * 1 * : Client : Order : CatalogEntry OrderLine(qty,part) add(qty,part) : OrderLine getCost() return cost Object creation
  • 49. Object Destruction: Order Entry Example : Order <<destroy>> remove(line) : OrderLine X : Client Object deletion
  • 50. Recurrence
    • When a sequence of messages takes place within an iteration , messages are grouped together within a rectangle
    Object Name Object Name Object Name message message *[recurrence condition]
  • 51. Branching
    • Shown by 2 arrows branching off from the same point
    • Condition-clause is added to the message to show the condition
    Object Name Object Name Object Name [condition] message [condition] message
  • 52. Conditional Message
    • Messages which are sent only under certain circumstances
    • Not used in most cases because of the complexity of the resulting diagrams
    • Consists of a Boolean expression written in square brackets
  • 53. Conditional Message: Sequence Diagram : Order : CatalogEntry [s>=qty] OrderLine(qty,part) add(qty,part) : OrderLine getCost() return cost getStockLevel(part) return s : Client
  • 54. Conditional Message: Communication Diagram : Order : OrderLine {new} : CatalogEntry 1: add(qty, part) 1.2: [s>=qty] OrderLine(qty, part) 1.2.1: cost = getCost() {new} {new} 1.1: s = getStockLevel(part) : Client
  • 55. Message to Self
    • A message that an object sends to itself gives rise to a new activation
    • The new activation takes place in an object that already has a live activation
    • The recursive nature of this new activation is shown by superimposing the new activation on top of the original one
  • 56. Self-Delegation: Sequence Diagram : Order : Customer getShippingCost() getTotal() : OrderLine * getLocation() * getValue() : Client
  • 57. Self-Delegation: Collaboration Diagram : Order : Customer : OrderLine * 1: getTotal() 1.2.1: getLocation() 1.1 * : getValue() 1.2: getShippingCost() <<self>> : Client

×