View
3.573
Download
2
Category
Tags:
Preview:
DESCRIPTION
Citation preview
INTROSE Introduction to Software Engineering
Raymund Sison, PhDCollege of Computer Studies
De La Salle University
sisonr@dlsu.edu.ph
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)
Neural Networks
DataFlow Diagrams (SA/SD)
Scenarios/Use Cases(Jacobsen)
Formal Specifications
(Liskov)
Petri Nets(Petri)Inheritance
Frames,SemanticNetworks (Minsky)
Uncertain KnowledgeFuzzy Sets (Zadeh)
Data Relationship(E/R Modeling, Chen)
Hierarchical Database
Model (IMS)
NetworkDatabase
Model(CODASYL)
RelationalDatabase Model
(Codd)
Fuzzy Frames(Graham)
Class Diagrams(“E/R + Inheritance”,
Rumbaugh)
Sequence Diagrams(Lamport)Activity
Diagrams(“good old Flowcharts”)
From (Bruegge & Dutoit, 2004)
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)
Neural Networks
DataFlow Diagrams (SA/SD)
Scenarios/Use Cases(Jacobsen)
Formal Specifications
(Liskov)
Petri Nets(Petri)Inheritance
Frames,SemanticNetworks (Minsky)
Uncertain KnowledgeFuzzy Sets (Zadeh)
Data Relationship(E/R Modeling, Chen)
Hierarchical Database
Model (IMS)
NetworkDatabase
Model(CODASYL)
RelationalDatabase Model
(Codd)
Fuzzy Frames(Graham)
Class Diagrams(“E/R + Inheritance”,
Rumbaugh)
Sequence Diagrams(Lamport)Activity
Diagrams(“good old Flowcharts”)
From (Bruegge & Dutoit, 2004)
Components of an Object Model
ClassesAssociations (Relations) Kind-of/Is-a (Generalization) Part-of/Has-a (Aggregation) Domain-specific associations
AttributesOperations
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
*worksForEmployee Company1
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
Company BoardOfDirectors11
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 ofclasses, which should beinstances
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
Aggregation Hierarchy
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
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)
Neural Networks
DataFlow Diagrams (SA/SD)
Scenarios/Use Cases(Jacobsen)
Formal Specifications
(Liskov)
Petri Nets(Petri)Inheritance
Frames,SemanticNetworks (Minsky)
Uncertain KnowledgeFuzzy Sets (Zadeh)
Data Relationship(E/R Modeling, Chen)
Hierarchical Database
Model (IMS)
NetworkDatabase
Model(CODASYL)
RelationalDatabase Model
(Codd)
Fuzzy Frames(Graham)
Class Diagrams(“E/R + Inheritance”,
Rumbaugh)
Sequence Diagrams(Lamport)Activity
Diagrams(“good old Flowcharts”)
From (Bruegge & Dutoit, 2004)
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(): Client
1 : count(part)
Collaboration Diagram
: Registrar
course_form : CourseForm
theManager : CurriculumManageraCourse : Course
4 : <<create>>
3 : add_course()
1 : set_course_info()2 : process_form()
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 diagramThe vertical dimension represents timeEach 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()
: Client
count(part)
return number
Lifeline
Activation(optional)
Messages
control returns to the sender of the message (optional)
Hierarchical Numbering of Messages
1.11
1.2
22.1
2.22.2.1
2.1.1
2.1.2
Object Creation
course_form :CourseForm
theManager :CurriculumManager
aCourse :Course
: Registrar
set_course_info
process_formadd_course
<<create>>
Objectcreation
Object Creation: Order Entry Example
Order OrderLinequantity: integer
cost: float
CatalogEntry
1 * 1*
: Client: Order :
CatalogEntry
OrderLine(qty,part)add(qty,part)
: OrderLinegetCost()
return cost
Objectcreation
Object Destruction: Order Entry Example
: Client: Order
<<destroy>>remove(line)
: OrderLine
Objectdeletion
X
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
: Client: Order :
CatalogEntry
[s>=qty] OrderLine(qty,part)
add(qty,part)
: OrderLine
getCost()
return cost
getStockLevel(part)
return s
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}
: Client
{new}
1.1: s =
getStockLevel(part)
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
: Client: Order : Customer
getShippingCost()
getTotal()
: OrderLine *
getLocation()
*getValue()
Self-Delegation: Collaboration Diagram
: Order : Customer
: OrderLine *
1: getTotal()
1.2.1: getLocation()
: Client1.1*: g
etValue()
1.2: getShippingCost()
<<self>>
Recommended