1 / 32

SEA Side Software Engineering Annotations

SEA Side Software Engineering Annotations. Annotation 3: UML One hour presentation to inform you of new techniques and practices in software development. Professor Sara Stoecklin Director of Software Engineering- Panama City Florida State University – Computer Science

garin
Download Presentation

SEA Side Software Engineering Annotations

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. SEA Side Software Engineering Annotations • Annotation 3: UML • One hour presentation to inform you of new techniques and practices in software development. • Professor Sara Stoecklin • Director of Software Engineering- Panama City • Florida State University – Computer Science • sstoecklin@mail.pc.fsu.edu • stoeckli@cs.fsu.edu • 850-522-2091 • 850-522-2023 Ex 182

  2. UML UML UML UML UML

  3. WHAT IS UML? The Unified Modeling Language (UML) is a modeling language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process.

  4. WHAT IS UML? • It was originally conceived by Rational Software Corporation and three methodologists in the information systems and technology industry, Grady Booch, James Rumbaugh, and Ivar Jacobson (the Three Amigos). • Grady Booch’s Booch ’93 method (from Booch ’91) • James Rumbaugh’s Object Modeling Technique (OMT) -2 (from OMT-1), which was coauthored with Mike Blaha, Bill Premerlani, Fred Eddy, and Bill Lorensen • Ivar Jacobson’s Object-Oriented Software Engineering (OOSE) method • Wirfs-Brock, Ward, Cunningham, Rubin, Harel, Gamma, Vlissides, Helm, Johnson, Meyer, Odell, Embley, Coleman, Coad, Yourdon, Schlaer, and Mellor.

  5. WHAT IS UML? • These are the commonly use modeling diagrams use in UML which each diagram gives a different view of a software system: • Use Case Diagram • Class Diagram • State Diagram • Sequence Diagram • Collaboration Diagram • Activity Diagram • Component Diagram • Deployment Diagram

  6. WHAT IS UML? • The UML models which can be used to abstract the system include: • A use case model with all the use cases and their relationships to users. • An analysis model, which has two purposes: to refine the use cases in more detail and to make an initial allocation of the behavior of the system to a set of objects that provides the behavior. • A design model that defines a) the static structure of the system as subsystems, classes, and interfaces and b) the use cases realized as collaborations among subsystems, classes and interfaces. • An implementation model, which includes components (representing source code) and the mapping of the classes to components. • A deployment model, which defines the physical nodes of computers and the mapping of the components to those nodes. • A test model, which describes the test cases that verify the use cases.

  7. Video Rental System Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Cuser Order new videos Corporate CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID CID Rent video Rent video () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () Customer WHAT IS UML? use case modelanalysis model design modelmplementation model Rent video Rent video Video Rental System Video Rental System Rent video Video Rental System Order new videos Order new videos Order new videos Order new videos Order new videos Order new videos Order new videos Rent video Order new videos Rent video Order new videos Corporate Corporate Corporate Rent video Rent video Rent video Order new videos Order new videos Rent video Rent video Order new videos Rent video Rent video Rent video Rent video Rent video Customer

  8. Why use UML? • Because you wish to represent the user interaction with the system in a manner than communicates with users that you understand the system scenarios (business). System Video Rental System Order new videos Use Case Corporate Rent video Return video Actor Customer

  9. What are Use Cases? Use Case Definition: The specification of actions, including variant sequences and error sequences that a system, subsystem, or class can perform by interacting with outside actors. USE CASES describe a sequence of actions (processes). USE CASES graphically depict interactions between the system and external actors. USE CASES identify high level services (processes, routines, methods). USE CASES specify behavior. USE CASES may have specialized use cases as extensions of generalized use cases.

  10. Use Cases - The GOOD Good way to begin defining the system through scenarios. Test plan can be written from the users point of view with use cases. Begins traceability. Has extensions such as: <<extends>> for extending the functionality of a use case <<uses>> for using one use case within another and <<includes>> for inner use cases and <<calls>> for invocation of other use cases.

  11. Use Cases - The BAD Difficult to determine the correct granularity. Difficult to determine the correct use case. Knowledge elicitation on use cases can cause an explosion of use cases. Often too informal. No techniques for polymorphic behavior.

  12. Use Cases - The UGLY No semantic soundness. While they are an integral part of specification of a system, they have only a small linkage to the other 8 diagrams. Question: Do these use cases aid in the presentation of a GOOD SRS.

  13. Use Cases and an SRS BAD Correct (maybe) Complete (maybe) Unambiguous (sometime) Understandable (not always) UGLY Precise (no) Verifiable (no, dataflows) Consistent (granularity) Concise (no) GOOD Organized (yes) Modifiable (yes) Traceable (yes) Design Independent (yes) Annotated (yes)

  14. Cassette cassetteID: int cassetteVolumeNo: int rentMovie() Why use UML? 2. Because you wish to define the domain (conceptual) objects or classes of the system so that domain rules (ex: business rules) can be encapsulated in these domain objects. ClassName Video Rental System Multiplicity Customer 1..* 1..* attributes rents CID: int name: String authenticateCustomer () methods relationship

  15. Class Diagrams Type of Relationship Diagramming Technique association generalization realization (interface) instanceOf refines ……. <<instanceOf>> <<refines>>

  16. Class Diagrams - The GOOD Good way to begin defining the system through abstractions with attributes, business rules, methods. Good way to document conceptual objects. Allows depiction of relationships between objects. Allows modeling of inheritance. Is integrated with some other diagrams. Has potential for soundness. Acts as a communication tool regarding the system. Serves as an abstraction for complex systems.

  17. Class Diagrams - The BAD Deceptive in correctness. Requires a network of classes. Can be confused with ERD. Is RADICALLY different in each phase. Is difficult to maintain manually.

  18. Class Diagrams - The UGLY NOT semantically sound. Resembles semantically sound ERD, NOT sound. Integration between use cases and class diagrams requires yet another diagram.

  19. Why use UML? 3. Because you wish to define the use case scenarios to show how the classes/objects interact in the scenario. Customer Rental Cassette validateCustomer() Classes rentCassette(CID) checkIfRentable(CID) method calls

  20. Sequence Diagrams - The GOOD Good method of discussing a use case with another developer. God way to document which classes go with which use case. Helps to identify methods not yet discovered and sometimes classes. Acts as a high level specification for programmers. Helps new OO programmers to see class interaction problems.

  21. Sequence Diagrams - The BAD Can become very complex without adding value. Can consume time without adding value. Automatically generated ones help in maintenance.

  22. Sequence Diagrams - The UGLY Looks FAR more correct than is actually. Correctness is always questionable. Completeness is always questionable.

  23. Sequence Diagrams and the SRS/SDS BAD Understandable (not always) Verifiable (somewhat) UGLY Precise (no) Concise (no) Correct (not sure) Unambiguous (sometime) Consistent (somewhat) Complete (no) GOOD Organized (yes) Modifiable (yes) Traceable (yes) Design Independent (yes?) Annotated (yes)

  24. Why use UML? 4. Because you wish to identify the states of the variables and classes within the software domain. available rent rented return state overdue payAR activities Checked transitions

  25. State Diagrams - The GOOD Helps to identify methods Drives out scenario definitions better. Most valuable in real-time systems.

  26. State Diagrams - The BAD/UGLY Formal Correctness is available in State Diagrams but UML did not include most of this formality.

  27. The GOOD UML notation provides a variety of diagrams for different purposes, like dynamic or static system views. UML is powerful and feature-rich. UML is suitable for representing workflow management systems. UML is the established (generally accepted) notational standard in the software community. UML can be used on a general level, where implementation details are suppressed. UML diagram semantics are defined clearly.

  28. The GOOD UML is graphic taking advantage of a picture is worth 1000 words. UML enables is a use-case driven, architecture-centric. UML is extensible. UML is implementation independent. UML is process independent. UML supports abstractions. UML is scaleable. UML is widely applicable and usable.

  29. The BAD UMLis a often complicated notation. UML contains imprecise elements. UML is overwhelmingly complex. UML is full of added extensions to correct problems, these are not consistent or well known. 37 things wrong with UML (inconsistencies, wrong modeling, …) UML notation is perhaps too rich to be intuitive and user-friendly.

  30. The UGLY UMLis NOT semantically sound. UML diagrams are NOT specific to a particular abstraction (conceptual, design, implementation). UML diagrams ARE NOT integrated.

  31. Recomendations UML should be used to AID in software development. Use it to incrementally document items that are unclear. Use it to develop code in teams to define classes, use cases. Use it to communicate with users. Use it as a discussion/review deliverable. Don’t just require it. Don’t expect to keep it up manually. Do choose IDEs that integrate UML with tools.

  32. Tools • . • Rational Rose. market leader, expensive, not aesthetically pleasing diagrams. • Embarcadero Describe. Interoperability with Java , presentable diagrams, $$ • ILogix Rhapsody. Inexpensive, free version, geared toward embedded systems • Visio inexpensive general-purpose drawing tool. • SmartDraw cheapest but solid drawing tool • Dia free, runs under Linux, clunky diagrams, metadata in XML • Kivio beautiful diagrams • JAVision • VAJ • Café • Borland

More Related