1 / 33

Documenting Solutions

Documenting Solutions. Todd Bacastow Penn State University Geog 468 GIS Analysis & Design. Documenting (system) solutions. Models – used to organize and document a system’s processes. Flow of data through processes Business logic Business policies Business procedures.

uma-marks
Télécharger la présentation

Documenting Solutions

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. Documenting Solutions Todd BacastowPenn State UniversityGeog 468GIS Analysis & Design

  2. Documenting (system) solutions Models – used to organize and document a system’s processes. • Flow of data through processes • Business logic • Business policies • Business procedures

  3. Why document using models? • Models remove biases that are the result of the way the system is currently implemented, or the way that any one person thinks the system might be implemented. • Models reduce the risk of missing business requirements because we are too preoccupied with technical results. • Models allow us to communicate with end-users in nontechnical or less technical languages.

  4. What is the UML? • Unified Modeling Language • It is a modeling language, not a development method • In 1996, work on the UML was begun by Rational • Supports Object Oriented Analysis and Design (OOA&D) • is a methodology for system design and data modeling • consisting of assessment, decomposition, conceptualization, and physical modeling techniques • Support the use of Computer-aided software engineering (CASE) tools

  5. UML Diagrams • Use Case Diagrams • Class Diagrams • Collaboration Diagrams • Sequence Diagrams • Package Diagrams • Component Diagrams • Deployment Diagrams • Activity Diagrams • State Diagrams

  6. Use Cases • Describe interactions between users and computer systems (both called actors) . • Capture user-visible functions. • Achieve discrete measurable goals. • Are typically used during Analysis and Design.

  7. Use Case Actor Identify Movie Open Account Customer Clerk Return Movie Review In-Store Telephone Account Status Customer Customer Use Case Diagram

  8. Use Case Report • The Use Case Report provides documentation for the Use Case. • A Use Case is not complete without the report. • The elements of the Use Case Report are shown on the right. • Brief description • Precondition • Flow of events • Main flow • Subflows • Alternate flows • Postcondition • Special Requirements • Enclosures • Diagrams • Pictures of the UI

  9. Class Diagrams • Called the most fundamental UML Diagram. • Describe the classes in the system, and the static relationships between classes. • Class diagrams are used during Analysis, Design and Development.

  10. UML Class Diagram Multiplicity Customer Simple Aggregation 1 Class Abstract Class Rental Invoice 1..* Rental Item {abstract} 1 0..1 Composition (Dependency) Simple Association Generalization Checkout Screen DVD Movie VHS Movie Video Game

  11. MyClassName +SomePublicAttribute : SomeType -SomePrivateAttribute : SomeType #SomeProtectedAttribute : SomeType +ClassMethodOne() +ClassMethodTwo() Responsibilities -- can optionally be described here. Parts of a Class • Classes can have four parts • Name • Attributes • Operations • Responsibilities • Classes can show visibility and types. • All parts but the Name are optional.

  12. ThisOne : MyClassName +SomePublicAttribute : SomeType -SomePrivateAttribute : SomeType #SomeProtectedAttribute : SomeType +ClassMethodOne() +ClassMethodTwo() Object Diagrams • An Object is an instance of a class. • Object names are underlined. • Object diagrams are similar to class diagrams. Many of the same notations are used. • Object diagrams capture instances of classes, and allow the dynamic relationships to be shown.

  13. Class and Object Diagrams Class Name Association Name Customer Rental Item Rents +id:integer +id:integer 0..n +name:string +released:date 0..1 Class Diagram Attributes Object Name Joe: Customer Casablanca: Movie +id:1667 +id:22340 +name:Joe Smith +released:1942 Object Diagram

  14. Collaboration Diagram • Collaboration diagrams describe interactions and links • Focus on exchange of messages between objects • Appears during Analysis phase • Enhanced during Design phase

  15. Collaboration Diagram :Rented Items Object 5: add(customer, movies) 1: enter_customer() 8: generateRentalTotal() 3: enter_movies() 2: IsValidCust(CustId) 7: print invoice() :Check-out Manager :Customer :Clerk 4:GetMovieByBarcode() :Inventory Message

  16. Sequence Diagram • Can be “morphed” from Collaboration Diagrams. • Describe interactions between objects arranged in time sequence • Focus on objects and classes involved in the scenario and the sequence of messages exchanged • Associated with use cases • Used heavily during Analysis phase and are enhanced and refined during Design phase

  17. Sequence Diagram :CheckoutMgr Cust:Customer :Inventory :RentedItems :Employee 1: find customer() 2: search (string) Object 3: enter movie() 4: search (string) Activation Message 5: rent (movie) 6: add(Cust, item) Lifeline 7: printInvoice() 8: generateRentalTotal()

  18. Package Diagram Class Package

  19. Component Diagram Component Interface Dependency Note

  20. Deployment Diagram Node Communication Association

  21. Activity Diagram Start State Identify Caller Action State Obtain Name & Address Decision Open Account? Current Customer? [no] [no] [yes] [yes] End State Create Account

  22. Swimlanes and Fork/Join Points Customer Manager Walking Clerk Identify Movie Fork Point Place Order Place Order Fill Order Pay Collect Money Pickup Movie Deliver Movie Join Point

  23. State Diagram Guard Event Transition Action Activity State

  24. Views • The User View • Use Case Diagram(s) • Structural View • Class Diagram • The Behavior View • The Sequence Diagram • Collaboration Diagram • Activity Diagram • State Diagram • The Implementation View • Component Diagram • Deployment Diagram

  25. A step back in time:Entity Relationship Diagrams(Where UML began)

  26. Entity relationship diagram (ERD) – a data model utilizing several notations to depict data in terms of the entities and relationships described by that data.

  27. Entity – a class of persons, places, objects, events, or concepts about which we need to capture and store data. • Named by a singular noun • Persons: agency, contractor, customer, department, division, employee, instructor, student, supplier. • Places: sales region, building, room, branch office, campus. • Objects: book, machine, part, product, raw material, software license, software package, tool, vehicle model, vehicle. • Events: application, award, cancellation, class, flight, invoice, order, registration, renewal, requisition, reservation, sale, trip. • Concepts: account, block of time, bond, course, fund, qualification, stock.

  28. Attribute – a descriptive property or characteristic of an entity. Synonyms include element, property, and field. • Just as a physical student can have attributes, such as hair color, height, etc., data entity has data attributes

  29. Key – an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier.

  30. Relationship – a natural business association that exists between one or more entities. The relationship may represent an event that links the entities or merely a logical affinity that exists between the entities.

  31. Cardinality – the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity. Because all relationships are bidirectional, cardinality must be defined in both directions for every relationship. bidirectional

  32. Degree – the number of entities that participate in the relationship. A relationship between two entities is called a binary relationship. A relationship between three entities is called a 3-ary or ternary relationship. A relationship between different instances of the same entity is called a recursive relationship.

More Related