Problem and Domain Analysis Couse Project

The course project will require that you model an online ticket sales system using UML

To model an online ticket sales system using Unified Modeling Language (UML), a developer should create a series of diagrams that capture different aspects of the system, including its structure, behavior, and interactions. Here's a high-level overview of the steps involved and the types of UML diagrams that can be used:

1. Identify system requirements and use cases: Start by understanding the system's requirements and defining use cases that represent the key functionalities of the online ticket sales system. Examples of use cases might include 1) Search for Events, 2) Purchase Tickets, 3) Cancel Tickets, 4) View Ticket Details, and 5) User Authentication.
2. Use Case Diagram: Create a Use Case Diagram to represent the interactions between the system's actors (such as users, event organizers, and administrators) and the use cases. This diagram provides a high-level view of the system's functionality and the different user roles.
3. Class Diagram: Create a Class Diagram to model the structure of the system, including its main classes, attributes, and relationships. Some example classes for an online ticket sales system might include Event, Venue, Ticket, User, Order, and Payment. Define associations, aggregations, or compositions between the classes as appropriate.
4. Sequence Diagrams: Create Sequence Diagrams for the critical use cases to model the interactions between objects and the order of events in the system. For example, create a sequence diagram for the "Purchase Tickets" use case to show the interactions between the User, Ticket, Event, Order, and Payment classes, as well as any external systems like a payment gateway.
5. State Diagrams: Create State Diagrams for the classes with complex behavior or state transitions, such as Ticket (e.g., available, reserved, sold, canceled) or Order (e.g., pending, confirmed, completed, canceled).
6. Activity Diagrams: Create Activity Diagrams to represent the flow of activities and decision points within specific use cases or processes, such as the steps involved in purchasing tickets or processing a refund.
7. Component Diagram: Create a Component Diagram to represent the high-level structure of the system, including its components, interfaces, and dependencies. This diagram can help you identify the system's modules, such as the user interface, ticket management, event management, and payment processing components.
8. Deployment Diagram: Create a Deployment Diagram to represent the system's hardware and software infrastructure, including servers, databases, network components, and the deployment of software components onto those nodes.

Once you've created these diagrams, use them to communicate the design to stakeholders, refine requirements, identify potential issues, and guide the development process. Keep in mind that the specific diagrams and level of detail needed will depend on the project's scope and complexity, and you may need to iterate on your models as the project progresses.

The project for this course requires you to model an online ticket sales system for a local auditorium.
In order to create this model, you will need to find out what the users want to be able to do with the system, how they do business, and how they expect an automated solution to help them. Your task will be to:

1. Document user expectations
2. Help users clarify their expectations and business practices
3. Model the users' business in a way that will support the development of an automated solution

During this process, you will use the UML diagramming standards to provide a consistent and precise view of the knowledge captured along the way and the decisions that you and the users make. You will learn what tools and concepts to use at each phase, including what questions to ask and how to test your conclusions. The end product of this project, which will be developed in the first two courses in this series, will be a complete use case model, object model, and interaction diagrams. These products will be the foundation for the design phase covered in part three of the Object-Oriented Analysis and Design Fundamentals Series.

Structured design methods evolved to guide developers who were trying to build complex systems using algorithms as their fundamental building blocks. Similarly, object-oriented design methods have evolved to help developers exploit the expressive power of object-based and object-oriented programming languages, using the class and object as basic building blocks. Actually, the object model has been influenced by a number of factors, not just object-oriented programming. The object model has proven to be a unifying concept in computer science, applicable not just to programming languages, but also to the design of user interfaces, databases, and even computer architectures. The reason for this widespread appeal is simply that an object orientation helps us to cope with the complexity inherent in many different kinds of systems. Object-oriented analysis and design thus represents an evolutionary development, not a revolutionary one. It does not break with advances from the past, but builds upon proven ones. Unfortunately, most programmers today are formally and informally trained only in the principles of structured design. Certainly, many good engineers have developed and deployed countless useful software systems using these techniques. However, there are limits to the amount of complexity we can handle using only algorithmic decomposition; thus we must turn to object-oriented decomposition. Furthermore, if we try to use languages such as C++ and Ada as if they were only traditional, algorithmically oriented languages, we not only miss the power available to us, but we usually end up worse off than if we had used an older language such as C or Pascal.