Download as PDF, PPTX
![10
Composition
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
-Name : string
+ID : long
#Salary : double
-adfaf : bool
Employee
-members : Employee
Team
1
*
Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
Filled diamond on
side of the Collection
members[0] =
new Employee();
…
delete members[0];](https://image.slidesharecdn.com/ooad-unit-2-211230042610/85/CS8592-OOAD-Lecture-Notes-Unit-2-10-320.jpg)
![Process Sale
enterItem(itemID, quantity)
:System
: Cashier
endSale
makePayment(amount)
a UML loop
interaction
frame, with a
boolean guard
expression
external actor to
system
Process Sale Scenario
system as black box
the name could be "NextGenPOS" but "System" keeps it
simple
the ":" and underline imply an instance, and are explained in a
later chapter on sequence diagram notation in the UML
a message with
parameters
it is an abstraction
representing the
system event of
entering the
payment data by
some mechanism
description, total
return value(s)
associated with the
previous message
an abstraction that
ignores presentation
and medium
the return line is
optional if nothing is
returned
total with taxes
change due, receipt
makeNewSale
[ more items ]
loop](https://image.slidesharecdn.com/ooad-unit-2-211230042610/85/CS8592-OOAD-Lecture-Notes-Unit-2-99-320.jpg)
Uploaded byGobinath Subramaniam
CS8592-OOAD Lecture Notes Unit-2
The document discusses static UML diagrams, specifically class diagrams. It covers key concepts of classes, attributes, associations, relationships, and notations. It provides examples of class diagrams for conceptual domain models and describes best practices for identifying conceptual classes, attributes, and associations from use case scenarios to build the domain model.
More Related Content
Similar to CS8592-OOAD Lecture Notes Unit-2
CS8592-OOAD Lecture Notes Unit-2
- 1. CS8592 OBJECT ORIENTED ANALYSISAND DESIGN UNIT II - STATIC UML DIAGRAMS Class Diagram - Elaboration - Domain Model - Finding conceptual classes and description classes - Associations - Attributes - Domain model refinement - Finding conceptual class Hierarchies - Aggregation and Composition - Relationship between sequence diagrams and use cases – When to use Class Diagrams.
- 2. 2 Class Diagrams ⚫ AClass is a Description of Set of Objects that Share the Same Attributes, Operations, Methods, Relationships, and Semantics ⚫ Classes are Graphically Represented as Boxes with Compartments for ⚫ Class Name, Private Attributes, and Public Operations
- 3. 3 Class Diagram (Rumbaugh/Booch) ⚫Class Diagram Describes – Types of Objects in Application – Static Relationships Among Objects – Temporal Information Not Supported ⚫ Class Diagrams Contain – Classes: Objects, Attributes, and Operations – Packages: Groupings of Classes – Subsystems: Grouping of Classes/Packages ⚫ Main Concepts: Class, Association, Generalization, Dependency, Realization, Interface
- 4. 4 Classes A class representa concept A class encapsulates state (attributes) and behavior (operations). Each attribute has a type. Each operation has a signature. The class name is the only mandatory information. zone2price getZones() getPrice() TariffSchedule Table zone2price Enumeration getZones() Price getPrice(Zone) TariffSchedule Name Attributes Operations Signature TariffSchedule
- 5. 5 UML Class Notation Aclass is a rectangle divided into three parts – Class name – Class attributes (i.e. data members, variables) – Class operations (i.e. methods) Modifiers – Private: - – Public: + – Protected: # – Static: Underlined (i.e. shared among all members of the class) Abstract class: Name in italics +getName() : string +setName() -calcInternalStuff(in x : byte, in y : decimal) -Name : string +ID : long #Salary : double Employee • An abstract class has one or more abstract/pure virtual functions. • An abstract class cannot be used to instantiate objects. • An abstract class can contain data members.
- 6. 6 UML Class Notation Linesor arrows between classes indicate relationships – Association • A relationship between instances of two classes, where one class must know about the other to do its work, e.g. client communicates to server • indicated by a straight line or arrow – Aggregation • An association where one class belongs to a collection, e.g. instructor part of Faculty • Indicated by an empty diamond on the side of the collection – Composition • Strong form of Aggregation • Lifetime control; components cannot exist without the aggregate • Indicated by a solid diamond on the side of the collection – Inheritance • An inheritance link indicating one class a superclass relationship, e.g. bird is part of mammal • Indicated by triangle pointing to superclass
- 7. 7 Binary Association myB.service(); myA.doSomething(); BinaryAssociation: Both entities “Know About” each other Optionally, may create an Associate Class
- 8. 8 Unary Association A knowsabout B, but B knows nothing about A Arrow points in direction of the dependency myB.service();
- 9. 9 Aggregation Aggregation is anassociation with a “collection-member” relationship void doSomething() aModule.service(); Hollow diamond on the Collection side
- 10. 10 Composition +getName() : string +setName() -calcInternalStuff(inx : byte, in y : decimal) -Name : string +ID : long #Salary : double -adfaf : bool Employee -members : Employee Team 1 * Composition is Aggregation with: Lifetime Control (owner controls construction, destruction) Part object may belong to only one whole object Filled diamond on side of the Collection members[0] = new Employee(); … delete members[0];
- 11. 11 Inheritance Standard concept ofinheritance class B() extends A … Base Class Derived Class
- 12. 12 Generalization and Associations Item NonPItemPerishItem DeliItem ProduceItem DiaryItem Customer GroceryOrder 1 * DeliOrder 1 * contains Supermarket example
- 13. 13 UML Multiplicities Multiplicities Meaning 0..1 zeroor one instance. The notation n . . M indicates n to m instances. 0..* or * no limit on the number of instances (including none). 1 exactly one instance 1..* at least one instance Links on associations to specify more details about the relationship
- 14.
- 15.
- 16. Elaboration ⚫ Elaboration isthe initial series of iterations during which the team does the following ⚫ Serious investigation ⚫ Discover & stabilize major requirements ⚫ Mitigate/retire risks ( business value ) ⚫ Build core architecture elements ⚫ Estimate overall schedule and resources ⚫ Establish a supporting environment Objectives 16
- 17. Elaboration - KeyIdeas ⚫ Not a waterfall model ! ⚫ Two to six weeks for each iteration ⚫ Timeboxed iterations (deadlines should be strictly maintained) ⚫ Each iteration products ends in a stable and tested release 17
- 18. Best Practices ⚫ Startprogramming early ⚫ Adapt based on feedback from tests, users, developers ⚫ Design, implement and test adaptively ⚫ Test early and realistically ⚫ Requirements and use case details through series of workshops (once per iteration) 18
- 19. Artifacts starting inElaboration (this will not be completed rather refined over iterations) ⚫ Domain Model (conceptual class diagram) ⚫ Design Model (logical design: class diagram, object oriented diagram, etc.) ⚫ Software Architecture Document (summary of ideas and motivations) ⚫ Data Model (database schemas..) ⚫ Test Model ⚫ Implementation Model (source code, databases and so on. ) ⚫ Use-Case Storyboards and UI Prototypes (description of user interfaces, navigations etc. 19
- 20. You didn’t UnderstandElaboration When … ⚫ No Timeboxed schedule ⚫ Single Iteration ⚫ Most requirements already defined ⚫ No Risk mitigation/resolution ⚫ No Executable Architecture ⚫ Requirements Phase ⚫ Attempt full and careful design 20
- 21. You didn’t UnderstandElaboration When (2)... ⚫ Minimal feedback and adaptation ⚫ No early and realistic testing ⚫ Frozen Architecture ⚫ No Proof-of-concept programming ⚫ No multiple requirements workshops 21
- 22. 22 Domain Model Relationships DomainModel Use Case Model Interaction Diagrams Glossary Design Requirements Business Model Classes, attributes, associations Domain objects Elaboration on some terms
- 23. 23 A Domain Model ⚫illustrates meaningful conceptual classes in a problem domain. ⚫ is a representation of real-world concepts, not software components. ⚫ is NOT a set of diagrams describing software classes, or software objects and their responsibilities. ⚫ It may show: ▪ concepts ▪ associations between concepts ▪ attributes of concepts
- 24. 24 Domain Model -UML Notation ⚫ Illustrated using a set of class diagrams for which no operations are defined. ▪A Domain Model is a description of things in the real world. ▪A Domain Model is not a description of the software design. ▪A concept is an idea, thing, or object.
- 25. 25 A Domain Modelis not a Software Artifact Sale Date Time Sales Database Sale Date Time Print() A Conceptual class Software Artifacts vs.
- 26. 26 Identify Conceptual Classesby Noun Phrase: ⚫ Identify Nouns and Noun Phrases in textual descriptions of the domain. ⚫ Fully dressed Use Cases are good for this type of linguistic analysis. It’s not strictly a mechanical process: ⚫ Words may be ambiguous ⚫ Different phrases may represent the same concepts.
- 27. 27 Steps to createa Domain Model ⚫ Identify Candidate Conceptual classes ⚫ Draw them in a Domain Model ⚫ Add associations necessary to record the relationships that must be retained ⚫ Add attributes necessary for information to be preserved ⚫ Apply existing Analysis Patterns
- 28. 28 Apply the MapmakerStrategy ⚫ Use existing names for things, the vocabulary of the domain ⚫ Exclude irrelevant features ⚫ Do not add things that are not there
- 29. 29 A Common Mistake- Classes as Attributes ⚫ Rule: If we do not think of a thing as a number or text in the real world, then it is probably a conceptual class. ⚫ If it takes up space, then it is likely a conceptual class. Examples: ⚫ A Store is not an attribute of a Sale ⚫ A Destination is not an attribute of a flight
- 30. 30 Specification or Description ConceptualClasses ⚫ A Class that records information about an item. ⚫ Even if all Instances of the item are sold out, the description remains. ⚫ Avoids duplication of recording the descriptive information with each instance of the item.
- 31. 31 Description of aService Example (Flight) Airport Name vs. Flight Date Time Number Flight Date Time Flight Desc Date Time Airport Name Flies-to Described -by Describes -flights-to
- 32. 32 The NextGen POS(partial) Domain Model
- 33. 33 Associations An association isa relationship between instances of types that indicates some meaningful and interesting connection
- 34. 34 Introduction ⚫ Identify associationsof conceptual classes needed to satisfy the information requirements of current scenarios. ⚫ Also identify the aid in comprehending the domain model.
- 35.
- 36. 36 Useful Associations ⚫ Associationsfor which knowledge of the relationship needs to be preserved for some duration. ⚫ Associations derived from the Common Associations List.
- 37. 37 UML Association Notation ⚫An association is represented as a line between classes with an association name. ⚫ Associations are inherently bidirectional. ⚫ Optional reading direction arrow is only an aid to the reader of the diagram.
- 38. 38 UML Association Notation -“reading direction arrow” - it has no meaning except to indicate direction of reading the association label - often excluded Register Sale Records-current 1 1 multiplicity association name
- 39. 39 Finding Associations-Common Associations List Thecommon categories that are worth considering are: ⚫ A is a physical part of B . Eg: Wing-Airplane ⚫ A is a logical part of B. Eg: SalesLineItem- Sale. ⚫ A is physically contained in B . Eg: Register- Store.
- 40. 40 Common Associations List2 ⚫ A is logically contained in B. Eg:ItemDescription-Catalog. ⚫ A is a description of B. Eg:ItemDescription- Item. ⚫ A is a line item of a transaction or report B. Eg:SalesLineItem-Sale. ⚫ A is a member of B. Eg: Cashier-Store. ⚫ A uses or manages B. Eg:Cashier-Register.
- 41. 41 Common Associations List3 ⚫ A is known/logged/recorded/reported/captured in B. Eg: Sale-Register. ⚫ A is an organizational subunit of B . Eg:Department-Store. ⚫ A communicates with B. Eg:Customer-Cashier. ⚫ A is next to B. Eg:City-City.
- 42. 42 Common Associations List4 ⚫ A is related to a transaction B. Eg: Customer-Payment. ⚫ A is a transaction related to another transaction B. Eg:Payment-Sale. ⚫ A is next to B. Eg:City-City. ⚫ A is owned by B. Eg:Register-Store. ⚫ A is an event related to B. Eg:Sale-Customer.
- 43. 43 High-Priority Associations ⚫ Ais a physical or logical part of B. ⚫ A is physically or logically contained in/on B. ⚫ A is recorded in B.
- 44. 44 Associations Guidelines ⚫ Theknowledge of the relationship needs to be preserved for some duration. ⚫ Identifying conceptual classes is more important than identifying associations. ⚫ Avoid showing redundant or derivable associations.
- 45. 45 Roles ⚫ Each endof an association is called a role. ⚫ Roles may have ⚫ name ⚫ multiplicity expression ⚫ navigability
- 46. 46 Multiplicity ⚫ Multiplicity definesthe number of instances of a class A, that can be associated with one instance of class B, at a particular moment. ⚫ Eg: In countries with monogamy laws, a person can be married to 1 person at any particular time. But over a span of time one person can be married to many persons.
- 47. 47 Multiplicity multiplicity of the role StoreItem Stocks 1 * Fig 3 Multiplicity on an association.
- 48. 48 Multiplicity Fig 4. Multiplicityvalues. T * zero or more; “many” T 1..* one or more; T 1..40 one to 40 T 5 exactly 5 T 3,5,8 exactly 3,5 or 8
- 49. 49 Naming Associations ⚫ Namean association based on TypeName-VerbPhrase-TypeName format. ⚫ Names should start with a capital letter. ⚫ Legal formats are: ⚫ Paid-by ⚫ PaidBy
- 50. 50 Associations Names Supervises * Paid-by Captures 1..* 1 1 Contains 1..* 1 Store RegisterSale Payment 1 Assigned-to Assigned-to * * 1 Employs 1..* 1 Airline Person Flight Plane 1 1 Fig 5.Association names.
- 51. 51 Multiple Associations 1 1 * * Flies-from Flight Airport Flies-to Fig6. Multiple associations. • Two types may have multiple associations between them.
- 52. 52 Implementation ⚫ The domainmodel can be updated to reflect the newly discovered associations. ⚫ But,avoid updating any documentation or model unless there is a concrete justification for future use. ⚫ Defer design considerations so that extraneous information is not included and maximizing design options later on.
- 53. 53 ATTRIBUTES ⚫ After establishingclasses based on the concepts of use case scenarios, the scenarios are examined to discover attributes ⚫ Attributes are logical data values of an object
- 54. 54 UML Attribute Notation SALE Date:startTime: Time Attributes
- 55. 55 Valid Attribute Types ⚫Keep attributes simple ⚫ Distinguish between conceptual and implementation perspectives ⚫ Identify data types
- 56. 56 Relate with associations,not attributes CASHIER NAME : current register NOT A “SIMPLE” ATTRIBUTE Worse CASHIER Number NAME REGISTER 1 USES 1 Better Worse Better
- 57. 57 Avoid Representing ComplexDomain Concepts as Attributes FLIGHT DESTINATION DESTINATION IS A COMPLEX CONCEPT Worse Flight Airport 1 Flies 1 Better Worse Better
- 58. 58 Non Primitive DataType Represent what may be considered a primitive data type (such as a number or string) as a non primitive class if: ⚫It is composed of separate sections. •Eg: phone number, name of person ⚫There are operations usually associated with it, such as parsing or validation. •Eg: social security number ⚫It has other attributes •promotional price could have a start date and end date
- 59. 59 Non Primitive DataType ⚫ It has a quantity with a unit Eg: payment amount has a unit of currency ⚫ It has abstraction of one or more types with some of these qualities. Eg: item identifier in the sales domain is a generalization of types such as Universal product code(UPC) or European Article Number(EAN)
- 60. 60 Non primitive dataTypes Applying these guidelines to the POS domain model yields the following analysis: ⚫The item identifier is an abstraction of various common coding codes schemes, including UPC-A, UPC-E, and the family of EAN schemes. ⚫These numeric coding schemes have subparts identifying the manufacturer, product and EAN
- 61. 61 If the attributeclass is a data type, it may be shown in the attribute box Product Specification ItemID Store Address Product Specification Id: Item ID Store address: Address 1 1 1 1 Attribute box
- 62. 62 No attributes asForeign Key CASHIER Name: currentRegisterNumber A “simple” attribute but being used as a foreign key to relate to another object. Worse CASHIER number Better NAME Register 1 USES 1 Worse Better
- 63. 63 Modelling Attribute Quantitesand Units Payment Amount: Number Payment Quantity Amount:Number Unit Not useful Has amount Is in * 1 * 1 Payment Amount:Quantity Quantities are pure data values, so suitable to show in attribute section Variation: Money is a specialized Quantity whose unit is a currency Payment Amount: Money better
- 64. When to makegeneralization hierarchies? Why is the following a good example? Cash Payment Credit Payment Check Payment Payment superclass - more general concept subclass - more specialized concept these are conceptual classes, not software classes Figure 31.1 Guidelines: • Identify superclasses and subclasses when they help us understand concepts in more general, abstract terms and reduce repeated information. • Expand class hierarchy relevant to the current iteration and show them in the Domain Model. Domain Model Refinement 64
- 65. 100% and Is-arules Cash Payment Credit Payment Check Payment Payment amount : Money Sale Pays-for 1 1 100% rule: Subclasses must conform to 100% of superclass’s attributes and associations. Is-a rule (informal test): “Subclass is a Superclass” 65
- 66. What about thishierarchy? Male Customer Female Customer Customer Correct subclasses. But useful? Fig. 31.6 Guidelines for creating conceptual subclasses: • Subclass has additional attributes or associations of interest • Subclass behaves or is operated on, or handled or manipulated differently than superclass or other subclasses 66
- 67. Is this hierarchyOK? What does it add to our understanding of the domain? Credit Authorization Service Check Authorization Service Check Payment AuthorizationService address name phoneNumber additional associations superclass justified by common attributes and associations Store Authorizes-payments-of * Authorizes Credit Payment Authorizes * * * 1 1 Fig. 31.8 Models transactions with external services which are important in POS domain 67
- 68. When to designAssociation classes? address name phoneNumber AuthorizationService address name Store merchantID ServiceContract an association class its attributes are related to the association its lifetime is dependent on the association Authorizes-payments-via 1..* * Fig. 31.16 address name phoneNumber AuthorizationService address name Store merchantID ServiceContract Purchases 1..* * a better model, but not yet as useful as possible Sells Authorizes-payments-via 1..* * Fig. 31.15 ServiceContract records merchantID—good. But ServiceContract is dependent on relationship between two classes 68
- 69. What about thishierarchy? (Why not?) Payment not useful these subclasses are changing states of the superclass Unauthorized Payment Authorized Payment PaymentState better Unauthorized State Authorized State Payment Is-in 1 * Fig. 31.13 • Classes should be invariant • Classes can maintain state information as attributes • Rather than subclasses, model changing states with state charts 69
- 70. More Association classes salary Employment Employs CompanyPerson * * dateOfIncarceration JailTerm Incarcerates Jail Person * Married-to Person 0..1 0..1 1 a person may have employment with several companies Fig. 31.17 70
- 71. When to addComposition notation? SalesLineItem Sale 1..* Product Description Product Catalog 1..* 1 1 Fig. 31.18 Guidelines for drawing Composition (whole-part) relationships: • Obvious whole-part physical or logical assembly • Lifetime of part is bound within lifetime of whole (create-delete dependency) • Some properties of whole propagate to parts, e.g., location • Operations of whole propagate to parts, e.g., movement • But: If in doubt, leave it out. 71
- 72. Higher order packagefor POS domain Domain Core/Misc Payments Products Sales Authorization Transactions Fig. 31.29 What does this higher order package contain? 72
- 73. Core/Misc package Core/Misc Register Manager Store address name Houses 1..* Employs 1..* 1 1 Fig.31.30 Why call this package Core for the POS domain? 73
- 74. A rich package Payments Check Accounts Receivable Credit Payment Check Payment Check Authorization Service Credit Authorization Service Authorized-by Authorized-by * * * AuthorizationService address name phoneNumber Core::Store Payment amount Establishes- credit-for Logs * CreditCard expiryDate number DriversLicense number 1..* Establishes- identity-for Paid-by CashPayment amountTendered * Sales::Customer Abused-by Identifies Authorization Transactions:: PaymentAuthorizationReply - CheckPayments have CheckPaymentReplies - CreditPayments have CreditPaymentReplies 1 1 1 1 1 1 1 1 1 1 1 Authorizes-payments-of merchantID ServiceContract 1 Fig. 31.31 74
- 75. Note: Composition andtie to Core package Products 1..* Core:: Store Stocks * Describes * Sales:: SalesLineItem Described-by * Records-sale-of 0..1 Product Description description price itemID ProductCatalog Item 1 1 1 1 1 Fig. 31.32 75
- 76. Iteration-3 of Monopolydomain model 76
- 77. Conceptual Class Hierarchies ●Organizing classes into hierarchies facilitates the reuse of code and the reuse of solutions to design problems that have already been solved. ● Class hierarchies as sets - supersets (referred to as superclasses or base classes), and subsets (referred to as subclasses or derived classes).
- 78. Conceptual Class CategoryExamples Physical or tangible objects Register, Airplane Specifications, deigns or descriptions of things ProductSpecification, FlightDescription Places Store, Airport Transactions Sale, Payment, Reservation Transaction line items SalesLineItem Roles of people Cashier, Pilot Containers of other things Store, Bin, Airplane Things in a container Item, Passenger Other computer or electro-mechanical systems external to the system CreditPaymentAuthorizationSystem AirTrafficControl Organizations SalesDepartment, ObjectAirline Events Sale, Payment, Meeting, Flight, Crash, Landing Rules and policies RefundPolicy CancellationPolicy Catalogs ProductCatalog, PartsCatalog Records of finance, work, contracts, legal matters Receipt, Ledger, EmploymentContract, MaintenanceLog Financial instruments and services LineOfCredit, Stock Manuals, documents, reference papers, books DailyPriceChangeList , RepairManual Conceptual Class Category
- 79.
- 80. Design of ClassHierarchies ⚫ Design a system of classes, put common data and functionality in a superclass, which you then use to derive subclasses. ⚫ The subclasses inherit the data and functionality of the superclass and define only aspects that are unique to their particular purposes.
- 81. Class Hierarchies advantages: ⚫Avoid duplicating code that is common to all classes. ⚫ Add or change subclasses at any time without modifying the superclass or affecting other subclasses. ⚫ If the superclass changes (for example, all employees are assigned a number), then subclass automatically get these changes.
- 82. Aggregation and Composition ⚫Aggregation is a kind of association used to model whole-part relationships between things. ⚫ The whole is called Composite. ⚫ For instance, physical assemblies are organized in aggregation relationships such as a Hand aggregates Fingers.
- 83. Aggregation in theUML ⚫ Aggregation is shown in the UML with a hollow or filled diamond symbol at the composite end of whole-part association. ⚫ Aggregation is a property of an association role.
- 84.
- 85. Example Composition Aggregation ⚫A finger is a part of at most one hand (we hope!), thus the aggregation diamond is filled to indicate composite aggregation.
- 86. Multiplicity At CompositeEnd ⚫ If the multiplicity at the composite end is exactly one, the part may not exist separate from some composite. ⚫ For Example : if the finger is removed from the hand, it must be immediately attached to another composite object (another hand, a food,…); at least, that is what the model is declaring, regardless of the medical merits of this idea!
- 87. Multiplicity At CompositeEnd (2) ⚫ If the multiplicity at the composite end is 0…1,then the part may be removed from the composite, and still exist apart from membership in any composite. ⚫ So in previous example if you want fingers floating around by themselves, use 0…1.
- 88. Shared Aggregation –Hollow Diamond ⚫ Means that the multiplicity at the composite end may be more than one. ⚫ It is signified with Hollow Diamond. ⚫ Implies that the part may be simultaneously in many composite instances. ⚫ Shared aggregation seldom exists in physical aggregates, but rather in nonphysical concepts.
- 89. Shared Aggregation :Example ⚫ A UML package may be considered to aggregate its elements. But an element may be referenced in more than one package.
- 90. How To IdentifyAggregation ⚫ In some cases, the presence of aggregation is obvious. ⚫ Usually in physical assemblies. ⚫ But sometimes, it is not clear. ⚫ On Aggregation : If in doubt,leave it out.
- 91. Aggregation In ThePOS Domain Model ⚫ In the POS domain, the SalesLineItems may be considered a part of a composite Sale; in general, transaction line items are viewed as parts of an aggregate transaction.
- 92. Aggregation In ThePOS Domain Model (2) ⚫ In addition to conformance to that pattern, there is create – delete dependency of the line items on the Sale – their lifetime is bound within the lifetime of the sale. ⚫ By similar justification , Product Catalog is an aggregate of Product Specifications. ⚫ No other relationship is a compelling combination that suggests whole – part semantics, a create – delete dependency, and “If in doubt, leave it out.”
- 93. Aggregation In POSApplication
- 94. ⚫ Class diagramsrepresent static modeling. ⚫ What about modeling dynamic behavior? ⚫ Interaction diagrams (Sequence and communication diagrams) model how groups of object collaborate to perform some behavior ➢ Typically captures the behavior of a single use case System Sequence Diagrams
- 95. System Sequence Diagram(SSD) For a use case scenario, an SSD shows: ⚫ The System (as a black box) ⚫ The external actors that interact with System ⚫ The System events that the actors generate , their temporal order. :System
- 96.
- 97. How to constructan SSD from a use case System Sequence Diagrams ⚫ Draw a line representing the system as ablack box. ⚫ Identify each actor that directly operates on the system. ⚫ Draw a line for each such actor. ⚫ From detailed (expanded) use case identify system events that each actor generates.
- 98. Develop SSDs forthe main success scenario of a selected use case, then frequent alternative scenarios Relationship SSD and Use case
- 99. Process Sale enterItem(itemID, quantity) :System :Cashier endSale makePayment(amount) a UML loop interaction frame, with a boolean guard expression external actor to system Process Sale Scenario system as black box the name could be "NextGenPOS" but "System" keeps it simple the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML a message with parameters it is an abstraction representing the system event of entering the payment data by some mechanism description, total return value(s) associated with the previous message an abstraction that ignores presentation and medium the return line is optional if nothing is returned total with taxes change due, receipt makeNewSale [ more items ] loop
- 100. When to useClass Diagrams? • Class diagrams are the backbone of nearly all OO methods so, it will be used in all the time.
- 101. Ref: Text Book-1 CraigLarman, Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design and Iterative Development, Third Edition, Pearson Education, 2005.