Software Life-Cycle Models

Transcription

1 Software Life-Cycle Models CMPSC 487 Lecture 03 Topics: UML Class Diagram Rosenburg Chap 2. Domain Modeling A. UML: Unified Modeling Language UML is a general-purpose, developmental, modeling language in the field of software engineering, which is intended to provide a standard way to visualize the design of a system. a) UML Diagrams UML has 2 categories, and 14 different diagrams: 7 structure diagrams: class, component, composite structure, deployment, object, package, profile diagrams 7 behavior diagrams: activity, communication, interaction overview, sequence, state, timing, use case diagrams Class diagram (static diagram) It is a fundamental building block of OOAD (Object-oriented analysis and design). The most used UML diagram type Shows relationship between object types (classes) in a system. Use case diagram (behavior diagram) Most known type of UML behavior diagram. This is a good starting point to discuss projects It shows: 1. Graphic overview of actors in system 2. Functions needed by actors 3. Interactions between functions

2 Sequence diagram (behavior) Capture behavior of single scenario (each use case) It shows: 1. Interactions between objects (arrows) 2. order of interactions Communication diagram (behavior) Called collaboration diagram in UML 1. Has same information to sequence diagram Show messages passed between objects Activity diagram (behavior) Similar to flow chart, but activity diagram supports parallel behavior Has strength in expressing concurrency and signal passing State diagram (behavior) Oldest diagram type in UML Has states including initial/final states, and transition between states Show the internal stat change by external signal b) Advice when drawing UML diagrams 1. Don t spend too much time to make it pretty 2. Keep diagrams as simple as possible. If diagram become cluttered, split it. 3. Use your notation if you need Don t strictly follow UML notation.

3 c) Class diagram It is one of the structure diagram, which depict the elements of a specification that are irrespective of time. It shows collaboration of static model element and their relationship It is used to explore domain concept, analyze requirement, and depict detailed design of OO software. Representation of class diagram

4 Attributes Represents structural feature of a class. Fields in a class Operation Action that a class can do Method on a class

5 Association Bidirectional Association

6 Note and comments Constraints Aggregation Composition Generalization

7 Association class It allows adding attributes, operations, and other features to associations. It add extra constraints, in that there is only one instance of the association class between any two participating objects.

8 B. ICONIX Process overview ICONIX Process is a minimalist, streamlined approach that focuses on that area that lies in between use cases and code. It has 11 steps: 1. Domain modeling 2. Use case modeling 3. Requirement review 4. Robustness analysis 5. Technical architecture 6. Preliminary design review 7. Sequence diagram a. Abstract level b. Involving technical architecture 8. Critical design review 9. Coding & unit testing 10. Integration & scenario testing 11. Code review & model updating Phase 1. Requirement Phase 1. Domain modeling 2. Use case modeling 3. Requirement review

9 Phase 2. Analysis & preliminary design phase 4. Robustness analysis 6. Preliminary design review 5. Technical architecture Phase 3. Detailed design phase 7. Sequence diagram 8. Critical design review

10 Illustration of ICONIX process and steps

11 C. Domain modeling a) Background Project Glossary: A used in project. It helps to ensure consistent usage of terms, when describing problem space. Domain Model: Example) Domain model s aim is

12 Domain Object Requirement Requirement has 3 categories 1. High level requirement (=business requirement) Management and board of directors can understand. It has information that IT group need for developing SW. 2. Functional requirement It is very detailed and outlines what needs to be delivered. It describe what system should do. 3. Non-functional requirement Include performance, scalability, capability, maintainability, etc. Describe global constraint on a SW system.

13 b) Overall step to build domain model 1. Starts with high-level requirements. 2. Scan the requirement, and extract nouns and noun phrases. 3. Refine these nouns (to create initial domain model) 4. First trial of building domain model 5. Second attempt a the domain model 6. Build generalization relationship

14 c) Example: The high-level requirements for the Internet Bookstore: 1. The bookstore will be web based initially, but it must have a sufficiently flexible architecture that alternative front-ends may be developed. 2. The bookstore must be able to sell books, with orders accepted over the Internet. 3. The user must be able to add books into an online shopping cart, prior to checkout. a. Similarly, the user must be able to remove items from the shopping cart. 4. The user must be able to maintain wish lists of books that he or she wants to purchase later. 5. User must be able to pay by credit card or purchase order. 6. The bookstore must be embeddable into associate partners websites using mini-catalogs, which are derived from an overall master catalog stored in a central database. a. The mini-catalogs must be defined in XML, as they will be transferred between this and external systems. b. The shipping fulfillment system shall be carried out via Amazon Web Services. 7. The user must be able to create a customer account, so that the system remembers the user s details (name, address, credit card details) at login. a. System maintain a list of accounts in its central database. b. When a user logs in, his or her password must always be matched against the passwords in the master account list. 8. The user must be able to search for books by various search methods title, author, keyword, or category and then view the books details. 9. It must be possible for user to post reviews of favorite books; the review comments should appear on the book details screen. Review should include a customer rating (1 5). a. Book reviews must be moderated that is, checked and OK d by staff before they re published on the website. 10. It must be possible for staff to post editorial reviews of books. These should also appear on the book details screen. 11. The bookstore shall allow third-party sellers (e.g., secondhand bookstores) to add their own individual book catalogs. These are added into the overall master book catalog. 12. The bookstore must be scalable: a. The bookstore must be capable of maintaining user accounts for up to 100,000 customers in its first six months, and then a further 1,000,000 after that. Step 1. Starts with high level requirement Step 2. Scan the requirement & Extract nouns and noun phrases

15 Step 3. Refine nouns (and noun phases) to create the initial domain model Bookstore Book Order Internet Shopping Cart Checkout Item Wish List Credit Card Purchase Order Associate Partner Mini-Catalog Master Catalog Database Shipping Fulfillment System Customer Account List of Accounts Password Master Account List Search Method Title Author Keyword Category Book Details Review Comment Customer Rating Book List Book Review Customer Editorial Review Seller Book Catalog Master Book Catalog Search Results User Account

16 Step 4. First trial of building domain model. Customer Order Wish List Book Review Customer Account Purchase Order Book List Editorial Review Master Account List Credit Card Book Author Search Result Database Checkout Step 5. Second attempt at the domain model. Step 6. Build generalization (is-a) relationship.

17 d) 10 Domain Modeling Guidelines 10. Focus on real world objects 9. Use generalization (is-a) and aggregation (has-a) relationships 8. Limit your initial domain modeling efforts to a couple of hours 7. Organize your class around key abstraction in the problem domain 4. Use domain model as a project glossary

18 3. Do your domain model before writing your use cases 2. Don t expect your final class diagrams to precisely match your domain model 1. Don t put screens and other GUI-specific classes on your domain model 6. Don t mistake your domain model for a data model

19 5. Don t confuse an object with a database table Bad Cases 1) Bad Cases 2) Bad Cases 3)

20 Bad Cases 4)