In this seminar we learnt mostly about design issues and how use cases can help us walk-through the problems and dilemmas that might be faced by the user while using the designed software or interface. It was fascinating and surprising to me to find out that design is not just an abstract concept but a structured process of a business model. I had not known of use cases and UML before this seminar.
What is UML? Well, the exact definition says, "The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems."
What is used for these representations are UML diagrams. "Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction."
Before this class, I had never heard of Use Cases. After the class though, I was very interested in knowing more about them as I realized after introduction to the concept, that not only they would help our team design a much better and more interactive interface for the users, but also help me think in a methodical way while designing a system in the future if ever needed.
"A use case is a set of scenarios that describes an interaction between a user and a system. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function.
A use case UML Diagram would summarize the aspects of the use case into a structured from that can then be easily analyzed and worked upon to improve the model further. This way, UML diagrams for use cases help a designer or a company judge and improve their interface or strategies which relate to interaction with users. UML is a tool by which it becomes very convenient to include the effects of the abstract human behaviour into the logical approach that needs to be taken when analyzing a business model or strategy.
A Use Case Diagram has the following elements:
Actors: An actor portrays any entity that performs certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case.
Use case: A use case is a visual representation of a distinct business functionality in a system. To choose a business process as a likely candidate for modeling as a use case, you need to ensure that the business process is discrete in nature. Each of the business functions can be classified as a potential use case.
System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system.
I am confident that after using use cases for our project, we will be able to remove any gaps that may be preventing our interface/ model to fully appeal to the targeted customers or users.
No comments:
Post a Comment