Object Oriented Analysis,  UML, UML Class Diagrams

CSE 307 Presentation 8

1

Overview

• Define object modeling and explain its benefits.  • Recognize and understand the basic concepts and constructs  of object modeling. diagrams • Define the UML and its various types of diagrams. • Evolve a business requirements use‐case model into a system  analysis use‐case model. • Discover objects and classes, and their relationships. • Construct a class diagram.

CSE 307 Presentation 8

2

Introduction to Object Modeling
• Object j ‐oriented analysis y  ( (OOA) ) – an approach pp   used to
– study existing objects to see if they can be reused or  adapted for new uses – define new or modified objects that will be combined  with existing objects into a useful business computing  application

• Object modeling – a technique for identifying  objects within the systems environment and the  relationships between those objects.
CSE 307 Presentation 8 3

Introduction to the UML
• Unified Modeling Language (UML) – a set of  modeling conventions that is used to specify  or describe a software system in terms of  objects.
– The UML does not prescribe a method for  developing systems—only a notation that is now  widely y accepted p  as a standard for object j   modeling. 

CSE 307 Presentation 8

4

UML Diagrams • Use‐Case Model Diagrams • Static Structure Diagrams – Class diagrams – Object diagrams • Interaction Diagrams – Sequence diagrams – Collaboration diagrams g • State Diagrams – Statechart diagrams – Activity diagrams • Implementation Diagrams – Component diagrams – Deployment diagrams CSE 307 Presentation 8 5 .

Class Diagram: Class vs Instance Class name compartment Attributes compartment Operations Ope at o s co compartment pa t e t Class CSE 307 Presentation 8 6 Client companyAddress companyEmail companyFax companyName companyTelephone .

Class Diagram: Class vs Instance Object name compartment Attribute values Instances do not have operations Instance CSE 307 Presentation 8 7 FoodCo:Client companyAddress=Evans Farm.com companyFax=01589-008636 companyName=FoodCo N F dC companyTelephone=01589-008638 . Norfolk companyEmail=mail@foodco.

Class Diagram: Class vs Instance • Object Instances often changes frequently  while classes are generally permanent. CSE 307 Presentation 8 8 . • Object instances can be updated. • Instances can be destroyed destroyed.

Class Diagram: Attributes Attributes are: • Part of the essential description of a class • The h  common structure of f what h  the h  class l  can  ‘know’ • Each object has its own value for each  attribute in its class CSE 307 Presentation 8 9 .

Class Diagram: Link vs Association Yellow Partridge:Client A link is a logical connection between two objects FoodCo:Client Grace Chia:StaffMember Soong Motor Co:Client Carlos Moncada:StaffMember Links CSE 307 Presentation 8 10 .

Class Diagram: Link vs Association Association role StaffMember staffName staffNo staffStartDate staffContact liaises with companyAddress companyEmail companyFax p y companyName companyTelephone Association Client Association name Direction in which name should be read Association CSE 307 Presentation 8 11 .

Class Diagram: Link vs Assosiation • An association describes set of similar  instances. i lf CSE 307 Presentation 8 12 . • Linked instances may be of different class or  from the same class. • Link Li k can connect instances i  o itself.

 and only one.Class Diagram: Multiplicity • Associations have multiplicity • Multiplicity is the range of permitted  cardinalities of an association • Represent enterprise (or business) rules • For example: – Any bank customer may have one or more  accou s accounts – Every account is for one. customer CSE 307 Presentation 8 13 .

* companyEmail p y companyFax companyName companyTelephone •Exactly one staff member liaises with each client •A staff member may liaise with zero.Class Diagram: Multiplicity Multiplicities StaffMember staffName staffNo staffStartDate 1 liaises with Client companyAddress Add 0.. one or more clients CSE 307 Presentation 8 14 .

...1 0.3 Example A student studies in exactly one department Ab bed d may h have zero or one patient Student may issue for zero or more IC A course may have one or more teachers A student may y borrow at most 3 books from the library 15 CSE 307 Presentation 8 .Class Diagram: Multiplicity Notations Multiplicity Exactly one Z Zero or one Zero or more One or more p Range g Specific Notations 1 blank 0 1 0. 0..* 0 * * 1 * 1.

Class Diagram: Operations Operations are: • An essential part of the description of a class • The h  common b behaviour h i  shared h d  b by all ll objects bj   of the class • Services that objects of a class can provide to  other objects CSE 307 Presentation 8 16 .

Class Diagram: Operations • Operations describe  what instances of a  class can do: – Set or reveal attribute  values – Perform calculations – Send messages to  other objects – Create or destroy links Campaign actualCost campaignFinishDate campaignStartDate p g completionDate datePaid estimatedCost titl title checkCampaignBudget ( ) getCampaignContribution ( ) recordPayment ( ) setCompleted ( ) CSE 307 Presentation 8 17 .

Class Diagram: State • State of an instance is defined by – The values of the attributes – The number of links • An object may show different behavior in  diff different t state t t • State transition is initiated by an event • State can be changed only by executing an  operation CSE 307 Presentation 8 18 .

• Instances of a class stereotype have a shared  focus on certain kind of things.3. • Analysis class stereotypes differentiate the  roles objects can play: – Boundary y objects j – Entity objects – Control objects j CSE 307 Presentation 8 19 .Class Diagram: Stereotypes • What does ‘Stereotype’ Stereotype  mean? – Ref 3: Section 7.2 (page 165).

Class Diagram: Stereotypes • Boundary Classes – Models interaction between the system and  actors – May include interfaces to other software or  devices – Main task is to manage the transfer of information  across system y  boundaries CSE 307 Presentation 8 20 .

Notations for boundary class <<boundary>> User Interface::AddAdvertUI startInterface( ) assignStaff( g () selectClient( ) selectCampaign( ) User Interface::AddAdvertUI startInterface( ) g () assignStaff( selectClient( ) selectCampaign( ) User Interface::AddAdvertUI CSE 307 Presentation 8 21 .

 a real‐life object or an  event – Often require persistent storage CSE 307 Presentation 8 22 .Class Diagram: Stereotypes • Entity Classes – Models information and their related behavior – Maybe about a person person.

Notations for entity class <<entity>> Campaign title campaignStartDate campaignFinishDate getCampaignAdverts( ) addNewAdvert( () Campaign title campaignStartDate campaignFinishDate getCampaignAdverts( ) addNewAdvert( ) Campaign CSE 307 Presentation 8 23 .

 transactions  and control of other objects – One use‐case should result in one control class CSE 307 Presentation 8 24 .Class Diagram: Stereotypes • Control Classes – Model the coordination. sequencing.

Notations for control class <<control>> Control::AddAdvert showClientCampaigns( ) showCampaignAdverts( ) createNewAdvert( ) C t l AddAd Control::AddAdvert t showClientCampaigns( ) showCampaignAdverts( ) () createNewAdvert( AddAvert CSE 307 Presentation 8 25 .

Class Diagram: Stereotypes Use-case pay fee Use-case register RegisterUI PayFeeUI PayFee Register ShowPRUI ShowResultUI RegistrationFee StudentInfo St d tI f FineInfo CSE 307 Presentation 8 C CourseInfo I f R lt Result 26 .

Building the Class Diagram • Two main ways to produce this: – Directly based on knowledge of the application  domain (a Domain Model) – By producing a separate class diagram for each  use case. then assembling them into a single  model (an Analysis Class Model) CSE 307 Presentation 8 27 .

From Use‐Case to Classes • Start with one use case • Identify the likely classes involved (the use  case collaboration) • Draw a collaboration diagram that fulfils the  needs of the use case • Translate this collaboration into a class  diagram • Repeat for other use cases • Combine the diagrams CSE 307 Presentation 8 28 .

Present a message confirming the allocation of staff 29 .From Use‐Case to Classes: Step 1 Use Case : Assign staff to a campaign Actor Action 1. Display list of staff not assigned i d to t that th t campaign i 8. Select the relevant campaign 7. Select the client name 5. Display List of Client Name 4. None 3. Select a staff member to assign to the campaign CSE 307 Presentation 8 System Response 2. List the titles of the campaigns related to that client 6.

From Use‐Case to Classes: Step 2 Guideline to eliminate candidate classes • A number of tests help to check whether a  candidate class is reasonable – Is it beyond the scope of the system? – Does D  i it refer f  to the h  system as a whole? h l ? – Does it duplicate another class? – Is it too vague? – (More on next slide) CSE 307 Presentation 8 30 .

 consider modelling the  potential class in some other way (or do not  model it at all) CSE 307 Presentation 8 31 .From Use‐Case to Classes: Step 2 – Is it too tied up with physical inputs and outputs? – Is it really an attribute? – Is it really an operation? – Is it really an association? • If any answer is ‘Yes’ Yes .

From Use‐Case to Classes: Step 2 • The  identified classes  – Client – Campaign – StaffMember CSE 307 Presentation 8 32 .

From Use‐Case to Classes: Step 3 • Initial collaboration diagram 1 2 3 Campaign Manager :Client :Campaign :StaffMember CSE 307 Presentation 8 33 .

From Use‐Case to Classes: Step 3 • Adding boundary and control classes 1 2 Campaign Manager :AssignStaffUI :AssignStaff 5 3 4 :Client Cli t CSE 307 Presentation 8 :Campaign C i :StaffMember St ffM b 34 .

From Use‐Case to Classes: Step 3 • Adding messages 1 2 Campaign Manager :AssignStaffUI :AssignStaff 7: AssignStaff() :Client Cli t CSE 307 Presentation 8 :Campaign C i :StaffMember St ffM b 35 .

From Use‐Case to Classes: Step 3 • Finalizing 4: selectClient() 7: selectCampaign() 10: assignStaff() 5: showClientCampaign() 8: showCampaignStaff() 11: asssignStaff() 2: startInterface() () Campaign Manager :AssignStaffUI :AssignStaff 13: AssignStaff() :Client Cli t CSE 307 Presentation 8 :Campaign C i :StaffMember St ffM b 36 .

From Use‐Case to Classes: Step 4 <<boundary>> <<b d >> AssignStaffUI startInterface() assignStaff() selectClient() selectCampaign() p g () <<control>> << t l>> AssignStaff assignStaff() getClientCampaign() showCampaignStaff() <<entity>> Client companyName companyAddress … getClientCampaign() getClients() 1 * <<entity>> Campaign site campaignStartDate … getCampaignStaff() assignStaff() CSE 307 Presentation 8 1 * <<entity>> StaffMemver staffNo staffName … getStaff() assignStaff() getStaffDetails() 37 .

Assigning Operations: CRC Cards • Class–Responsibility–Collaboration Class Responsibility Collaboration cards help  to model interaction between objects • For a given scenario (or use case): – Brainstorm the objects – Allocate All  to team members b – Role play the interaction CSE 307 Presentation 8 38 .

CSE 307 Presentation 8 39 . together with a brief description of the purpose of the collaboration. Collaborations Collaborations C ll b i with i h other h classes are listed here.CRC Cards Class Name: Responsibilities Responsibilities of a class are listed in this section.

Class Name Responsibilities Provide advert details. Collaborations CSE 307 Presentation 8 40 . adverts Add a new advert. Provide list of adverts. Class Name Responsibilities Client C ll b ti Collaborations Campaign provides campaign details. Advert Advert provides advert details details. Advert constructs new object.Class Name R Responsibilities ibiliti Provide client information. Construct adverts. Provide list of campaigns. Campaign Collaborations Provide campaign information.

CRC Cards • Effective role play depends on an explicit  strategy for distributing responsibility among  classes • For example:  – Each E h role l  player l  t tries i  t to b be l lazy – Persuades other players their class should accept  responsibility for a given task • May use ‘Paper CASE’ to document the  associations i ti  and d li links k CSE 307 Presentation 8 41 .

Thank You &  Keep Smiling CSE 307 Presentation 8 42 .

Sign up to vote on this title
UsefulNot useful