1 / 24

ITEC 403 Seminar

ITEC 403 Seminar. Object-Oriented Analysis and Design with the Unified Process by Ş ensev Alicik. OBJECTIVES. Explain the concept of Unified Process (UP) Describe Unified Modeling Language (UML) Explain the types of UML Diagrams Use-Case Diagram Class Diagram Activity Diagram

tarbox
Download Presentation

ITEC 403 Seminar

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. ITEC 403 Seminar Object-Oriented Analysis and Design with the Unified Process by ŞensevAlicik

  2. OBJECTIVES • Explain the concept of Unified Process (UP) • Describe Unified Modeling Language (UML) • Explain the types of UML Diagrams • Use-Case Diagram • Class Diagram • Activity Diagram • Concluding UML

  3. WHAT IS UNIFIED PROCESS? • Unified Process (UP) is an example of a system development methodology, based on object-oriented design. It consists of multiple iterations. Each iteration has a problem-solving approach of defining the requirements, analyzing and designing the solution, implementing and finally testing the system components. • Unified Process life cycle is taken in 4 phases; Inception, Elaboration, Construction and Transition.

  4. UP Life cycle

  5. WHAT IS UNIFIED PROCESS? • Anytime people need to record or communicate information, in any context, it is very useful to create a model. A model is a representation of the solution of a problem taken into consideration during the system development period. • In our seminar today we are going to focus on the standard set of model constructs and notations developed specially for object-oriented development. Unified Modeling Language (UML) diagrams.

  6. What is UML? • Unified Modelling Language (UML) is a standardized language used for the collection, analysis and processing of requirements as well as for the specification message exchanges and overviews of architecture and behavior specifications. UML is standardized by the Object Management Group.

  7. What is UML? • UML is increasingly popular in the telecommunications world, as software becomes more important for telecommunications equipment manufacturers. As networks move towards server-based architectures, software applications are replacing traditional switched based functionality. With its different notations, UML is well suited to the standards making process. At almost any given stage in the development of a standard there is a UML notation available for the task.

  8. UML Diagrams • There are a number of different UML diagrams that provides a look of the system from different perspectives, here are the models required for the ITEC403 progress report: • Use Case diagram (General and Partial) • Domain Model Class diagrams • Activity diagrams

  9. What is UML? • To gain the greatest benefit from UML, it must be used at the beginning of the process when requirements are being collected, reviewed and evaluated. Traditionally, this has been a relatively informal activity involving discussion within technical committees. UML can provide the formalization and visualization which make the requirements clear and unambiguous.

  10. Use Case Diagram • Use case illustrates a unit of functionality provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases — either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality (e.g., all security administration-related use cases).

  11. Use Case Diagram • To represent a use case(function) on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram (and just in case you're wondering, some people draw prettier stick people than others). Use simple lines to depict relationships between actors and use cases, as shown in Figure 1.

  12. Figure 1 – general Use Case diagram Example View Sales Statistics for my Band’s CDs View Billboard 200 Report View Sales Statistics for Specific CD Retrieve Latest Billboard 200 Report

  13. Use Case Diagram • A use-case diagram is typically used to communicate the high-level functions of the system and the system's scope. By looking at our use-case diagram in Figure 1, you can easily tell the functions that our example system provides. This system lets the band manager view a sales statistics report and the Billboard 200 report for the band's CDs. It also lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD. The diagram also tells us that our system delivers Billboard reports from an external system called Billboard Reporting Service. • In addition, the absence of use cases in this diagram shows what the system doesn't do. For example, it does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 — i.e., we see no reference to a use case called Listen to Songs from Billboard 200. This absence is not a trivial matter. With clear and simple use-case descriptions provided on such a diagram, a project sponsor can easily see if needed functionality is present or not present in the system.

  14. Use Case Diagram • For the progress report you are required to draw the use-case diagram from 2 perspectives; general and partial. • The general use-case diagram, will display all the system functions and all the actors with the relationship lines as in fig.1. • The partial use-case diagrams are designed for each actor separately, showing each actor’s role in the system by including the relative functions with the relationship lines as in fig.2.

  15. Figure 2 – partial Use Case diagram Example

  16. Class Diagram • The class diagram shows how the different entities (people, things, and data) relate to each other; in other words, it shows the static structures of the system. A class diagram can be used to display logical classes, which are typically the kinds of things the business people in an organization talk about — rock bands, CDs, radio play; or courses, student record, and academic performance. Class diagrams can also be used to show implementation classes, which are the things that programmers typically deal with. An implementation class diagram will probably show some of the same classes as the logical classes diagram.

  17. Figure 3 – single Class • A class is depicted on the class diagram as a rectangle with three horizontal sections, as shown in Figure 3. The upper section shows the class name; the middle section contains the class attributes; and the lower section contains the class operations (or "methods").

  18. Figure 4 – class diagram • In Figure 4, we see both the inheritance relationship and two association relationships. The CDSalesReport class inherits from the Report class. A CDSalesReport is associated with one CD, but the CD class doesn't know anything about the CDSalesReport class. The CD and the Band classes both know about each other, and both classes can be associated to one or more of each other.

  19. Activity Diagrams Activity Diagram • Activity diagrams show the procedural flow of control between two or more class objects while processing an activity. Activity diagrams can be used to model higher-level business process at the business unit level, or to model low-level internal class actions. In my experience, activity diagrams are best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business. This is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly.

  20. Figure 5 - Activity Diagram

  21. Activity Diagrams • For the progress report we require an activity diagram for each use-case (function) in the system, in order to understand the workflow better.

  22. Concluding UML • It’s a formal language • Each element of the language has a strongly defined meaning , so youcan be confident that when you model a particular facet of your system it will not be misunderstood. • It’s concise • The entire language is made up of simple and straightforward notation. • It’s comprehensive • It describes all important aspect of a system.

  23. Concluding UML • It’s scalableWhere needed, the language is formal enough to handle massive system modeling projects, but it also scales down to small projects or sub-parts, avoiding overkill. • It’s built on lessons learned • UML is the culmination of best practices in the object-oriented community during the past 20 years. • It’s the StandardUML is controlled by an open standards group with active contributions from a worldwide group of vendors and academics, which fends off “vendor lock-in” The standard ensures UML’s transform-ability and interoperability, which means you aren’t tied to a particular product.

  24. THE END • Thank You For Your Attention !!!

More Related