Upload
ethan-moody
View
217
Download
2
Embed Size (px)
Citation preview
Activity & Class Activity & Class ModelingModeling
Labs DiscussionLabs Discussionp3p3
T120B029T120B02920020044 pavasario sem. pavasario sem.
2
Discussion Question• Explain the role and place of an
activity diagram in system modeling
T120B029
3
Activity Modeling• Serves as a transition between the use
case and the interaction model.• Use cases are a necessary pre-condition • Use Cases – Actor or User Perspective• Activity Diagram – System Perspective
T120B029
4
Activity Modeling
• Activity models show a flow of logic and varying levels of detail necessary to complete computations
• While activity models define the flow of activities, they do not show objects
T120B029
5
How Activity Models Work• An event from an actor triggers a
use case• This begins the execution of the
activity• The activity proceeds through state
transitions• The activity completes
T120B029
6
Activity Diagrams• An Activity State is shown as a
rounded rectangle.• To determine activities, look at the
use case documentation. For each use case, determine the system response.
• E.G. Customer chooses purchase function => GetPurchaseDetails()
T120B029
7
Activity Diagram• The activity diagram shows transitions
between activities• Unless you are writing an infinite loop (e.g.
Multi-media kiosk) you need an initial and final state. – Initial State – Filled Circle– Final State – Bullseye
• Branches in the program logic are shown as a diamond
• Concurrent Processing is a bar line
T120B029
8
Activity Diagram (Example)
Display Current Configuration
Get Order Request
Display Purchase Form
Get Purchase Details
Store Order
Email Order Details
[ timeout ]
[ incomplete ]
[ OK ]
Multiple exit transitions (branch condition that is internal to activity state)
Explicit branch condition (that appears on exit from activity state)
T120B029
Class Models and Class Models and Class DiscoveryClass Discovery
Class Models and Class Models and Class DiscoveryClass Discovery
T120B029
10
The Snowflake Rule
• The Snowflake Rule – For a non-trivial system, no two analysts will come up with the identical class models for the same application domain
T120B029
11
Class Models• Define the internal state of the system• Elements
– Classes– Attributes– Operations– Association (Generalization, Aggregation,
Composition)• Classes Define Business Objects
T120B029
12
Class Models (Continued)
• Types of Classes (BCED Approach)– Entity Classes – Database Model &
Permanent Objects– Boundary Classes – GUI– Control Classes – Control program logic– Database Access Classes
• Methodology for Constructing Classes is same as use cases – Use a table and derive candidate classes
T120B029
13
Package Diagram (BCED)
Boundary Package
Control Package
Entity Package
Database Package
Boundary Package
Control Package
Entity Package
Database Package
T120B029
14
Determining Classes• Four Questions
– Is this concept a container for data?– Does it have separate attributes that will
take on different values?– Would it have many instance objects?– Is it in the scope of the application domain?
• Remember, this is an iterative task!
T120B029
15
Specifying Classes• After we have identified our initial set of
classes, we will want to specify them
• Here, we will begin drawing a class diagram and defining class properties
• CASE tools are of great assistance here
T120B029
16
How do we name classes?
• Names should begin with a capital letter, e.g. Reservation
• In compound words, the first letter of each word should be capitalized, e.g. OnTimeArrival
• The name should be a singular noun• The name should be meaningful in a
business context• The name should not be longer than 30
characters
T120B029
17
Discovering Class Attributes
• Recall that there are three parts to the class icon in UML (name, attributes, and operations)
• While discovering classes, it is helpful to discover attributes at the same time
• The first step for determining attributes is to identify those attributes that help us to understand the states of the object
T120B029
18
How do we name attributes?
• Use all lower case letters, e.g. time• Words in a compound name should
be separated by an underscore, e.g. ticket_number
• It would also be helpful to keep them under 30 letters
• It should also be meaningful in a business context as opposed to a pure tech approach
T120B029
19
Class Attributes
• Class structure is defined by attributes
• Defining attributes is an art, not a science, but there are some techniques we will explore later
T120B029
20
Class Attributes
Customer
customer_name : Stringcustomer_address : Stringphone_number : Stringemail_address : String
(from Use Case View)
Orderorder_number : Stringorder_date : Dateship_address : Stringorder_total : Currencyorder_status : Stringsalesperson_name : String
T120B029
21
Modeling Associations
• Recall that associations connect objects in the system
• Associations are the most essential kind of relationships in the model
• Associations support the execution of use cases (i.e. They tie together the state and behavior models)
T120B029
22
Discovering Associations
• Finding associations should be a side effect of class discovery
• An association is a class attribute with a non primitive data type
• Associations permit object collaboration• Remember that associations should be
binary at most. We need to replace any ternary associations or those with greater extents with a cycle of binary associations
T120B029
23
Rules for Specifying Associations
• In order to specify associations, we need to:– Name them– Name the association roles– Determine the association multiplicity
• When we name associations, we should name them in the same way as attributes
• We also need to designate the role names. When we use case tools, these will become attributes within the appropriate classes
• It is also good to specify the multiplicities
T120B029
24
Modeling Aggregation and Composition
• Aggregation and composition are forms of association
• Aggregation and generalization are the two most powerful techniques for re-use in UML
T120B029
25
Discovering Aggregations and Compositions
• The “litmus test” for discovering aggregation and composition is reading the relationship with the words “has” and “is part of”
• Examples:– “A book has chapters”– “A student is part of a class”
• If it does not make sense in a natural language, then it should not make be an aggregation or composition
T120B029
26
More about aggregation and composition
• Remember that composition (by value) is stronger than aggregation (by reference)
• Use a solid diamond for composition and a hollow diamond for aggregation
T120B029
27
Modeling Generalizations and
Relationships• Recall that generalization is a relationship
between a generic class and its sub-classes• Generalization supports inheritance in object
oriented environments• It also allows for substitution and
polymorphism (same operation meaning different things)
• Polymorphism works best when used with inheritance
T120B029
28
Discovering Generalizations
• We attempt to discover in parallel with class determination
• The litmus test for generalization are the phrases:– “can be”– “is a kind of”
• E.g. a pilot is a kind of employee• In UML, we specify generalizations using
a solid line with an arrowhead pointing to the superclass
T120B029
In Class Exercise In Class Exercise ContinuedContinued
In Class Exercise In Class Exercise ContinuedContinued
Class DiscoveryClass Discovery
T120B029
30
Home Exercise
• Assume that the system you reviewed during the first half of the lecture will have an object oriented implementation
• Discover a set of candidate classes, attributes, and relationships amongst these classes
• Write all names on the paper and turn it in (This is your participation for the week)
T120B029
31
Next Session• More Fun with UML
– State Charts– Sequence Diagrams
T120B029