08 class and sequence diagrams

INTROSE Introduction to Software Engineering Raymund Sison, PhD College of Computer Studies De La Salle University [email_address] Modeling Software Systems

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 Speciﬁcations (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”)

Components of an Object Model Classes Associations (Relations) Kind-of/Is-a (Generalization) Part-of/Has-a (Aggregation) Domain-specific associations Attributes Operations

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)

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

Labelling Associations Each association can be labelled, to make explicit the nature of the association

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

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

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

Analyzing and Validating Associations Avoid unnecessary one-to-one associations Avoid this Do this

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.

Association Classes Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes The following are equivalent

Reflexive Associations It is possible for an association to connect a class to itself

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

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

Avoiding Unnecessary Generalizations Inappropriate hierarchy of classes, which should be instances

Avoiding Unnecessary Generalizations Improved class diagram, with its corresponding instance diagram

Handling Multiple Discriminators Creating higher-level generalization

Handling Multiple Discriminators Using multiple inheritance

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)

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

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

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

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

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

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

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

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

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

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

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

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

Collaboration Diagram Show objects and links Superimpose messages on links a : Assembly part : CatalogEntry 1.1: number = getNumber() 1 : count(part) : Client

Collaboration Diagram course_form : CourseForm theManager : CurriculumManager aCourse : Course 4 : <<create>> 3 : add_course() 1 : set_course_info() 2 : process_form() : Registrar

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)

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

Sequence Diagram Time Objects and Message Flows

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

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

Return Return of control is shown using dashed arrow returning to the calling object. Object Name Object Name message

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

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

Hierarchical Numbering of Messages 1.1 1 1.2 2 2.1 2.2 2.2.1 2.1.1 2.1.2

Object Creation course_form : CourseForm theManager : CurriculumManager aCourse : Course set_course_info process_form add_course <<create>> Object creation : Registrar

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

Object Destruction: Order Entry Example : Order <<destroy>> remove(line) : OrderLine X : Client Object deletion

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]

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

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

Conditional Message: Sequence Diagram : Order : CatalogEntry [s>=qty] OrderLine(qty,part) add(qty,part) : OrderLine getCost() return cost getStockLevel(part) return s : Client

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

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

Self-Delegation: Sequence Diagram : Order : Customer getShippingCost() getTotal() : OrderLine * getLocation() * getValue() : Client

Self-Delegation: Collaboration Diagram : Order : Customer : OrderLine * 1: getTotal() 1.2.1: getLocation() 1.1 * : getValue() 1.2: getShippingCost() <<self>> : Client

08 class and sequence diagrams

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to 08 class and sequence diagrams (20)

More from kebsterz (10)

Recently uploaded (20)

08 class and sequence diagrams