Your SlideShare is downloading. ×
Lecture10
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lecture10

278

Published on

uml for library managment system

uml for library managment system

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
278
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ECE 452- Introduction to Software EngineeringLecture 10: Object-Oriented Analysis (System Sequence Diagrams, Conceptual Model) Manish Parashar parashar@ece.rutgers.edu Department of Electrical & Computer Engineering Rutgers University
  • 2. The Unified Analysis Process & UML♦ Use Case - What are the domain processes ? − Use Case Diagram ♦ high-level/expanded, essential/real♦ Conceptual Model - What are the domain concepts, terms ? − Class Diagram (conceptual) ♦ classes, associations, attributes♦ System Sequence Diagram - What are the system events and operations ? − Interaction Diagram - Sequence Diagram♦ Contracts - What do the system operations do ? − Contract Specs. ECE 452 - Introduction to Software Engineering
  • 3. Sample UP Artifacts Partial artifacts, Domain refined in each Business Model iteration. Modeling parameter or return data may be elaborated in the Glossary Use-Case Model :System foo( x )Requirements Glossary ... bar( y ) system system text events & system operations system use data sequence operation cases diagrams contracts Software Design Model design objects Architecture Doc. to handle the Design system events Software Dev. Plan Project Management Test Plan Development Case Test Environment ECE 452 - Introduction to Software Engineering
  • 4. From Analysis to Design♦ Use Cases − What are the domain processes ?♦ Conceptual Model − What are the concepts, terms ?♦ System sequence diagrams − What are the system events and operations ?♦ Contracts − What do the system operations do ? ECE 452 - Introduction to Software Engineering
  • 5. System Sequence Diagrams♦ Determine system events and operations♦ Derived from Use Cases – Typical course of events♦ Identify system functionality (operations) to be designed♦ System boundary is critical ECE 452 - Introduction to Software Engineering
  • 6. System Sequence Diagrams♦ Illustrate events from actors to systems♦ System sequence diagrams describe scenarios − a scenario is an instance of a use case Ivar Jacobson − a real example of the enactment of a use case − e.g. Process Sale♦ Some UML notation for a sequence diagram is shown on the next slide ECE 452 - Introduction to Software Engineering
  • 7. System Sequence Diagrams♦ Draw a line representing the system as a black box.♦ Identify each actor that directly operates on the system. Draw a line for each such actor.♦ From expanded use case identify system events that each actor generates. Ilustrate them.♦ Optionally include use case text on left. ECE 452 - Introduction to Software Engineering
  • 8. A System Sequence Diagram system as black box Buy Items-version 1 Actor Cashier :System Repeat until no enterItem(UPC, quantity) more items endSale()Text which clarifiescontrol, logic, iteration, makePayment(amount)etc.May be taken from theuse case. system event it triggers a system operation ECE 452 - Introduction to Software Engineering
  • 9. System events♦ System Event − An external input event generated by an actor to a system − the system is seen as a black box♦ System operation − the method invoked in response to a system event♦ Use the same names for system event and system operation♦ System events may have arguments ♦ enterItem( UPC, quantity ) ♦ raise( money ) ECE 452 - Introduction to Software Engineering
  • 10. System Sequence Diagrams from Use Cases : Cashier :System makeNewSale(Simple cash-only Process Sale scenario: )1. Customer arrives at a POS checkout enterItem(itemID,with goods and/or services to purchase. quantity)2. Cashier starts a new sale.3. Cashier enters item identifier. description,4. System records sale line item and totalpresents item description, price, and * [more items]running total.Cashier repeats steps 3-4 until indicatesdone. endSale(5. System presents total with taxes )calculated.6. Cashier tells Customer the total, and total withasks for payment. taxes7. Customer pays and System handlespayment. makePayment(amount... ) change due, receipt ECE 452 - Introduction to Software Engineering
  • 11. Naming System Events and Operations :System : Cashier better name enterItem(itemID, quantity) scan(itemID, quantity) worse name ECE 452 - Introduction to Software Engineering
  • 12. SSD with Use Case Text Simple cash-only Process Sale scenario: 1. Customer arrives at a POS checkout :System with goods and/or services to purchase. : Cashier 2. Cashier starts a new sale. makeNewSale( ) 3. Cashier enters item identifier. enterItem(itemID, 4. System records sale line item and quantity) presents item description, price, and running total. description, total * [more items] Cashier repeats steps 3-4 until indicates endSale( done. ) 5. System presents total with taxes total with calculated. taxes 6. Cashier tells Customer the total, and asks for payment. makePayment(amount 7. Customer pays and System handles ) payment. ... change due, receipt ECE 452 - Introduction to Software Engineering
  • 13. System Behavior - Contracts♦ Contracts help define system behavior♦ Contracts are defined in part by preconditions and postconditions♦ Examples in this chapter document system operations such as − enterItem − endSale − makePayment♦ However, contracts also apply to low-level methods ECE 452 - Introduction to Software Engineering
  • 14. The Conceptual Model- Introduction♦ Conceptual Model − illustrates meaningful concepts − most important artifact in OO analysis − need use cases as input ♦ but can develop uses cases as you do conceptual model♦ Question: − Provide names for the uses cases you found ♦ lets share this information now (use whiteboard) ECE 452 - Introduction to Software Engineering
  • 15. Domain Analysis♦ Object oriented analysis at the “business area level”♦ Objective: Create a library of reusable components for a particular domain♦ Ongoing activity of the software process (not tied to a specific project)♦ Domain analysis model specifies objects and classes that characterize the domain ECE 452 - Introduction to Software Engineering
  • 16. Domain Analysis♦ Define domain to be investigated♦ Categorize the items extracted from the domain♦ Collect a representative sample of applications in the domain♦ Analyze each application in the sample♦ Develop an analysis model for the objects♦ Define reuse guidelines ECE 452 - Introduction to Software Engineering
  • 17. Conceptual Models♦ Conceptual Model − created for the use cases of the current cycle in the language of the problem domain♦ Must identify − concepts - objects in our system − associations between concepts ♦ is part of, contains, manages, is-a, ... − attributes of concepts ♦ instance variables needed to hold state ECE 452 - Introduction to Software Engineering
  • 18. Conceptual Modeling...♦ Conceptual models should not contain design information − software artifacts, methods, etc.♦ Better to over specify then under specify♦ Concepts v/s attributes − when in doubt make it a concept♦ Specification/Description concepts ECE 452 - Introduction to Software Engineering
  • 19. Conceptual Modeling♦ Associations − less important than identifying concepts − show only “need-to-know” association (avoid redundant or derivable associations) − name, multiplicity, navigability − multiple associations ECE 452 - Introduction to Software Engineering
  • 20. Conceptual Model♦ Attributes − Attributes Vs. Concepts ♦ keep attributes simple ♦ if in doubt define it as a concept ♦ no attributes as foreign keys (use associations) ECE 452 - Introduction to Software Engineering
  • 21. A Partial Conceptual Model♦ See example for POST on page 88 also on next slide − Figure 9.1 ♦ shows attributes name some instance variables now ________ ♦ shows associations name a label now ♦ contains multiplicity • numbers at the ends of the association lines – 1, 0..1, 1..4 (one to four players), * means many • direction reading arrow which could be left-to-right and top- to-bottom by default (but this is not a standard rule) • Arrows help readability ♦ typically can read the multiplicity both ways♦ More on associations and multiplicity later ECE 452 - Introduction to Software Engineering
  • 22. Concept Sales Item LineItem Records-sale-of 0..1 1 quantity 1.. * * Stocked-inAssociation Contained-in 1 1 Sale StoreAttributes date address time 1 name 1 1 Houses Were shooting Paid-by 1.. * for something like this for your 1 POST Captured-on 4 final project Payment 1 amount ECE 452 - Introduction to Software Engineering
  • 23. Conceptual Model♦ Conceptshelp with domain vocabulary♦ Conceptual models are not models of software designs − don’t be thinking windows and files here − no responsibilities yet, do this in design♦ Concept: an idea, thing, or object − symbol: a word or image representing a concept − definition − extension: set of examples to which the concept applies ECE 452 - Introduction to Software Engineering
  • 24. Example Concept♦ POST Sale Sale concepts symbol date − symbol: Sale time − definition represents the event "A sale represents the event concepts definition of a purchase transaction. It of a purchase has a date and time." transaction, and has a date and time − extension: the set sale-1 sale-2 concepts extension of all sales sale-3 sale-4 ECE 452 - Introduction to Software Engineering
  • 25. Example Concept♦ POKER Card CardDeck concepts symbol rank − symbol: Card suit − definition: represents one card A card represents one of the entities to make up a hand concepts definition in a poker deck that in a poker game has a rank (2..14), and a suit ♣♦♥♠ − extension: the set Ace ♥ concepts extension of all cards 3♣ King ♦ 5♠ ECE 452 - Introduction to Software Engineering
  • 26. Conceptual model and partitioning♦ Structured Analysis (still in use today) − Divide and Conquer ♦ at the function level♦ Object-Oriented Analysis (still growing) − Partition ♦ at the level of concepts (objects) ECE 452 - Introduction to Software Engineering
  • 27. Identifying Concepts♦ One strategy for getting concepts − Look for the concepts in the problem specification and in your uses cases ♦ read the final project specification − It is better to have too many at first than too few ♦ specifying too many concepts is good ♦ is is better too have too many than too few ♦ concepts may have no attributes♦ Try not to think of Java classes as you do this − later on, think of some classes to implement ECE 452 - Introduction to Software Engineering
  • 28. Concept Category♦ Physical or tangible things − POST A Point of Sale Terminal♦ Specifications − POST ProductDescription♦ Transactions − POST Sale, Payment ECE 452 - Introduction to Software Engineering
  • 29. More Concept Categories♦ Things in a container − POST Sales Line Item♦ Abstract noun concepts − POST Waiting line rage♦ Events − POST Sale ECE 452 - Introduction to Software Engineering
  • 30. More Concept Categories♦ Rules and Policies − POST RefundPolicy♦ Organizations − POST SalesDepartment For more, see pages 91-93 ECE 452 - Introduction to Software Engineering
  • 31. Concepts? page 96-97♦ Use vocabulary of the users − Users are not usually present for college programming projects − However, Poker has users ♦ the users are you this isnt a Library with Patrons and Librarians♦ Do not include irrelevant things − no casino, no pit boss♦ Do not include things that dont belong − no Lottery System, no Starship Enterprise, no pit bull ECE 452 - Introduction to Software Engineering
  • 32. Finding Concepts♦ Make a list of candidate concepts (objects) − look for noun phrases ♦ be careful to avoid ambiguities ♦ see page 95 POST Item, Store, Sale, Payment, Customer ECE 452 - Introduction to Software Engineering
  • 33. Common Mistake♦ Do not mistake an attribute for a concept − Attributes are numbers, booleans, strings, date♦ All others things are likely a concept − if in doubt, make it a concept♦ Example: Payment in the POST problem could be thought of as the amount of a Sale − a primitive attribute like 9.75 − But a payment could be made by check, cash, credit card, could be in various currencies of the world, could require change − This outgrows being a simple attribute ECE 452 - Introduction to Software Engineering
  • 34. Resolving Similar Concepts♦ Naming things correctly is similar concepts with − important different names − sometimes hard to agree: POST or? Register 1 1 Records 6 Records6 * * Sale Sale ECE 452 - Introduction to Software Engineering
  • 35. Abstract Concepts♦ Some concepts dont feel real and that is okay − Telecommunications ♦ Connection, Route, Protocol − Poker ♦ Strategy, View − Encoding images with some compression scheme or encrypting messages for privacy ♦ Compression, Encryption, Privacy♦ Concepts in the problem domain exist even if they do not seem to be part of the real world ECE 452 - Introduction to Software Engineering
  • 36. Credit Credit Check ApprovalPOST Concepts Authorization Service Approval Request Request Check Credit Check Accounts Drivers Authorization Approval ApprovalReceivable License Service Reply Reply Cash Credit Check Credit Check Payment Payment Payment Card Product POST Item Store Sale Catalog Sales Product Cashier Customer Manager LineItem Specification ECE 452 - Introduction to Software Engineering
  • 37. Defining Terms in the UML♦ The Software class diagram will look a lot like the conceptual model♦ You will see associations, boxes, multiplicity...♦ Larman uses concept to refer to real world things and unreal things♦ Classes refer to software specifications and implementations. UML defines class as − a description of a set of a objects that share the same attributes, relationships, and semantics the three Amigos: Grady Booch, Ivar Jacobsen, Jim Rumbaugh ECE 452 - Introduction to Software Engineering
  • 38. Other UML terms♦ Operation − a service that can be requested from an object to affect behavior♦ Type − either a class or an interface specification with no methods♦ Interface − the set of externally visible operations ♦ Could mean a Java interface ECE 452 - Introduction to Software Engineering
  • 39. Adding Associations♦ Next step in the conceptual model − adding associations between two concepts − an association is ♦ a relationship between concepts that indicates some meaningful and interesting connection − Name the association with a hyphen connected verb phrase which reads well between concepts association Records-current POST Sale 1 1 ECE 452 - Introduction to Software Engineering
  • 40. Associations♦ Associations imply − our knowledge of the relationship must be preserved for some time (1 ms to forever) ♦ between what objects do we need to remember a relationship? • POST: does a drivers license remember a product catalog? • Poker: does a game need to remember its Player(s)? • Poker: does the winner need to know the card image collection? ECE 452 - Introduction to Software Engineering
  • 41. The UML Association Notation♦ UML Association: − a line between two concepts and a name − they are bi-directional * T zero or more; "many" − can have a multiplicity − exist in conceptual * 1.. T one or more models and 1..40 class diagrams T one to forty 5 T exactly five Multiplicity adornments 3, 5, 8 exactly three, T five or eight ECE 452 - Introduction to Software Engineering
  • 42. Possible Associations♦ A is a physical part of B Drawer - POST♦ A is a logical part of B SalesLineItem - Sale♦ A is physically contained in B POST-Store♦ A is logically contained in B ItemDescription-Catalog♦ A is recorded in B Sale - POST♦ A uses or manages B Cashier - POST♦ A communicates with B Customer - Cashier♦ A is related to a transaction B Customer - Payment − Draw some poker associations now ♦ Lets try to get one for each of the bullets above ECE 452 - Introduction to Software Engineering
  • 43. Associations♦ Some useful associations − A is a physical or logical part of B − A is physically or logically contained in/on B − A is recorded in B ECE 452 - Introduction to Software Engineering
  • 44. Association Guidelines♦ Concepts are more important than associations♦ Focus on need to know associations − the relationship must be preserved for some time♦ Better to have too few associations than too many ECE 452 - Introduction to Software Engineering
  • 45. Multiplicity♦ Multiplicitydefines how many instances of type A can be associated with one instance of type B at some point can differ Game Player 1 1..6 Mother Child 1 1+ performs-in Actor is associated Actor Film with 0 to many films. * * A film is associated can optionally name an association with 0 to many actors ECE 452 - Introduction to Software Engineering
  • 46. Depends on Context♦ Are all three associations possible? Car Wheel 1 4 Car Wheel 1 5 Car Wheel 1 3 ECE 452 - Introduction to Software Engineering
  • 47. Association Names Upcase / hyphenate♦ Try reading this Type-VerbPhrase-Type Store 1 Contains * 1.. POST Captures Sale Paid-by Payment 1 * 1.. 1 1♦ Not yet worrying about messages, instance variables, data flow, or software objects♦ Just show some concepts are connected ECE 452 - Introduction to Software Engineering
  • 48. No Implementation Yet♦ Theassociations may later become implemented in software in terms of visibility − Related as an instance variable of a class − Related as an argument in a message − Related through an inheritance relationship♦ Some associations will not be implemented − Others will be discovered during coding♦ ConceptualModel should have associations suggested by requirements and use cases ECE 452 - Introduction to Software Engineering
  • 49. Any unforgettable Relationships?♦ POST − Post Captures Sale − Sale Paid-By Payment − ProductCatalog Records Specification ECE 452 - Introduction to Software Engineering
  • 50. Conceptual Model for the POST associations are not all need to know Records-sale-of Described-by 1 Product Product Specification Catalog Contains 1 1.. * 1 0..1 Used-by * Describes Sales * * LineItem Store Item Stocks 1 1 1 * 1.. * Logs- 1 Contained-in Houses completed 1 6 1.. * Sale * POST Manager Captured-on Started-by 1 1 1 1 1 1 1 Initiated-by 1 Paid-by 3 Records-sales-on 1 1 1 see pages Initiated-byPayment Customer Cashier 116-117 1 ECE 452 - Introduction to Software Engineering
  • 51. Not need to know No need yet to have POST Started-By Manager Records-sale-of Described-by 1 Product Product Specification Catalog Contains 1 1.. * 1 0..1 Used-by * Describes Sales * * LineItem Store Item Stocks 1 1 1 * 1.. * Logs- 1 Contained-in Houses completed 1 6 1.. * Sale * POST Captured-on 1 1 1 1 1 Initiated-by 1 Paid-by 3 Records-sales-on 1 1 1 see pages Initiated-byPayment Customer Cashier 116-117 1 ECE 452 - Introduction to Software Engineering
  • 52. Not need to know No one said Store Stocks Items Records-sale-of Described-by 1 Product Product Specification Catalog Contains 1 1.. * 1 0..1 Used-by * Describes Sales * * LineItem Store Item 1 1 1.. * Logs- 1 Contained-in Houses completed 1 6 1.. * Sale * POST Captured-on 1 1 1 1 1 Initiated-by 1 Paid-by 3 Records-sales-on 1 1 1 see pages Initiated-byPayment Customer Cashier 116-117 1 ECE 452 - Introduction to Software Engineering
  • 53. Need to Know vs. Comprehension♦ Could do a strict need-to-know model − bounded by current requirements only − but it may not convey a full understanding♦ By eliminating concepts and associations that are not currently required need to know − the conceptual model may not communicate key ideas and relationships♦ Make your conceptual model so it − has need to know requirements what the system must do − clearly communicates important concepts ♦ could have View as a concept ECE 452 - Introduction to Software Engineering
  • 54. Summary♦ Doubting whether to keep a concept? − keep it♦ Doubting whether to keep an association? − drop it♦ Do not keep derived associations − Where A relates to B and B relates to C usually leave out the A to C relationship♦ Does model satisfy all need to know associat- ions and still present a clear complete picture? ECE 452 - Introduction to Software Engineering
  • 55. Identifying Attributes♦ The final piece to the conceptual model is to add the attributes needed to support use cases♦ Attribute: a logical data value of an object − not necessarily in the final design, though some attributes will end up in the code♦ Example: A bank customer has an account ID and a balance − both could be attributes in the conceptual model − both could be instance variables in a class diagram ECE 452 - Introduction to Software Engineering
  • 56. Keep attributes simple♦ Look for simple data types as attributes − boolean, date, number, string like data base primitives♦ Do not use complex ideas as attributes♦ UML puts attributes in 2nd row of concept box Sale attributes date startTime : Time ECE 452 - Introduction to Software Engineering
  • 57. Attribute or Association?♦ Easy to mistake a concept as an attribute Cashier Worse not a "simple" attribute name currentPOST Cashier POST Better 1 Uses 1 name number ECE 452 - Introduction to Software Engineering
  • 58. Attribute or Association?♦ Attributes should be simple, if complex, write it as a concept with an association Flight destination is a complex Worse concept destination Flight 1 Flies-to 1 Airport Better ECE 452 - Introduction to Software Engineering

×