Why do we use UseCase diagrams in object oriented

问题:

UML notations says, Usecases are drawn to point out the functional requirements in the Problem Domain, it by no means gives the information about object or class as Data Flow Diagrams or Entity Relationship diagrams. But also why do we use Usecase Diagrams in object oriented analysis and design even if Usecases are not considered as Object oriented.

回答1:

Use case diagram is meant to shed light on the main functionalities of the system , and emphasis the perspective presenting the latter as a blackBox merely existing for a sole mission;deliver to the actor the Promised service .

At this point we don't realy care about OOP realy , as you can definetly use Use case diagram for any other type of analysis.

UML is just a set of visual tools to allow a unified expression of different perspective of the system. In Case you are using The Unified Process it advocates to start with identifiying the use cases first then explode every use case into collaborative entities (classes) and establish the static collaboration between them by harnessing the Class Diagram toolbox.

回答2:

Object-oriented is analysis and design methodology, while use case is requirements methodology. And be aware of the core development workflow：

1. Business modeling
2. Requirements
3. Analysis
4. Design

If we use UML to do these works, we may have:

1. Business use case+ Business sequence diagram
2. System use case+ System use case specification
3. Analysis class diagram+ Analysis sequence diagram+ Analysis state machine diagram
4. Code, Database......

UML diagrams in 3. can be replaced by DFD/ER

回答3:

Kirill Fakhroutdinov's online book uml-diagrams.org defines UML as

The Unified Modeling Language™ (UML®) is a standard visual modeling language intended to be used for

• modeling business and similar processes,
• analysis, design, and implementation of software-based systems

UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems....

As such the language needs words to describe processes, their actors (the code and its users, why the code exists, what is it good for, why someone should pay a money for it..)..

If in your designs you don't need to take users and their needs into account (you have the user interface designs set and you are focusing just on a library code) then don't bother, use UML to describe the parts you are dealing with and use diagrams that are natural and useful for you (and your teammates)

Some related articles:

• http://www.uml-diagrams.org/use-case-diagrams.html
• http://www.jamasoftware.com/blog/when-use-cases-arent-enough-part-1/
• http://agilemodeling.com/essays/agileRequirements.htm
• http://www.sparxsystems.com/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf
• http://alistair.cockburn.us/Stop+confusing+use+cases+and+user+stories (and http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison)

回答4:

If well use cases diagrams are mainly intended for communication with non-technical people, I would like to add that in some software architectures (like Clean Architecture), use cases are represented as actual objects that orchestrate the entities (they are equal to services after all). Eg. Given the use case "Submit Issue", you can create the following definition for it:

Submit Issue Use Case

Input data:

• issue_id
• issue_description
• date

Output data:

• same input data as confirmation

Primary Course

• Validate input data

• Create new Issue instance using the input data

• Persist new Issue

• return confirmation data

As you can see in the Primary course, there is even a detectable dependency between this use case and an entity object named "Issue".

A python example for this SubmitIssue Use Case class:

class SubmitIssue(UseCase):

    def __init__(issue_repo):
        self._repo = issue_repo

    def execute(self, input_data):
        #validate input data as needed
        #and apply branching logic if it is valid
        new_issue = Issue(input_data) #create new issue
        self._repo.add(new_issue) #persist new issue
        return self._generate_output_data(new_issue)

    @staticmethod
    def _generate_output_data(new_issue):
        #logic that returns the output data as specified
        #in the use case output data definition
        return output_data

regards.