1 / 20

Analysis Modeling

Analysis Modeling. Static Modeling. Requirements analysis. Results in static and dynamic models Scenario models: use cases (static), swimlane diagrams (dynamic) Class diagrams (static) Flow oriented diagrams (dynamic)

saki
Télécharger la présentation

Analysis Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Analysis Modeling Static Modeling

  2. Requirements analysis • Results in static and dynamic models • Scenario models: use cases (static), swimlane diagrams (dynamic) • Class diagrams (static) • Flow oriented diagrams (dynamic) • Behavioral models: sequence diagrams (dynamic), state diagrams (dynamic) • These models bridge the gap between requirements and implementation (code)

  3. Classes through Class diagrams • We’ve done use cases, time to move on to candidate classes, all of which should: • Retain information • Need services • Have multiple attributes • Have common attributes and operations • Be essential requirements (in the problem space)

  4. Selecting classes: example ATMUser Yes Yes Yes Yes Yes Yes PinNum Yes No No Yes Maybe Yes retained information needed services multiple attributes common attributes common operations essential requirements

  5. Class diagrams Student • A box with at least three compartments: • Class name • Attributes • Operations • Responsibilities • User-defined compartment • Each class associated with other classes -major: String -gpa: Real -standing: String +add(Section) +drop(Section) -- The set of students known to the registration system -- An exception occurs if gpa falls below 2.0

  6. Attribute syntax • [visibility] name [multiplicity] [:type] [=initial-value] • [{property-string}] • visibility: public “+”, protected “#”, or private “-” • name: capitalize first letter of each word that makes up the name, except for the first • multiplicity: number, range, or sequence of number or ranges. • type: built-in type or any user-defined class • initial-value: any constant and user-defined object • property-string: e.g, changeable, addOnly, frozen

  7. Operation syntax • [visibility] name [(parameter-list)] [:return-type] [{property-string}] • visibility: “+”, “#”, “-” • name: verb or verb phase, capitalize first letter of every word, except first • parameter-list: coma separated list of parameters • return-type: primitive type or user-defined type • property-string: isQuery, sequential, guarded, concurrent

  8. Example association Student Section -major: String -GPA: Real -standing: String -name: String -capacity: Integer +add(Student) +drop(Student) +checkPrereq(List<Student>) +add(Section) +drop(Section) Course Prerequisite

  9. Associations • An association is a structural relationship that specifies that objects of class may be connected to objects of another class • Associations typically represent “long-lived” relationships • In a library system a Person always has a name (association), but may infrequently have a book (dependency)

  10. Association syntax • Connect two classes • Have an optional label • Have multiplicities • Are directional (related to “has a” relationship) – the navigation • Think about which class needs to know about the other; which class is an attribute of the other? Why/when do I care?

  11. Multiplicity example Student Semester 1..* 0..* 1 takes> is held during> 0..8 1..* teaches> Class Section Instructor 1..3 0..6 1..* <works for is instance of> 1 sponsors> 1 1..* Department Course

  12. Attribute vs Association • We generally don’t model built-in classes like String (they are just types for attributes) joe: Student Is basically the same as ... -name: String = “Joe Jones” name joe: Student Joe Jones : String 1

  13. Types of associations Relation Generalization Association Dependency Binary Association N-ary Association Aggregation

  14. Generalization • A triangle on the side of the general class • Same as inheritance hierarchy in Java • Opportunity for reuse Graduate Student Person Student

  15. Dependency • One class uses another, but it’s a weaker form of association • Not necessarily long-lived; the depend-or can exist without a depend-ee in the system • Dashed line

  16. Aggregation • Means “part of” • Symbolized by a white diamond Crust 1 1 1 1 * 1 Sauce Serving Order Pizza 1..3 1 1 Cheese Serving 4..* 0..9 1 Topping Serving Slice

  17. Composition • Like aggregation, but the component cannot survive on its own • Symbolized by a black diamond Room Building

  18. Example • Take a look at BookstoreExample4.jpg • Does John McCain (who has 7 houses) have a problem using this system? • If Barack Obama decides to create a Federal sales tax, how would we change the system? • Why is there a display method in Item, Book, MusicCD and Software? • An ItemOrder is part of how many Orders? • Can you explain how a search works using this diagram?

  19. In-class exercise • Let’s make a class diagram for an ATM • Include a dependency • Include a generalization • Include a composition • Include all multiplicities

  20. Team Project • Examine the Quiz Game description/use cases • In your teams, come up classes; • At least one dependency, aggregation, and generalization • All associations must have navigations and multiplicities • All attributes and operations must have types and visibilities • Turn in this assignment through XP-Dev

More Related