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.
相关问题
- how to define constructor for Python's new Nam
- Do the Java Integer and Double objects have unnece
- Keeping track of variable instances
- Object.create() bug?
- System sequence diagram - Can system request input
相关文章
- 接口B继承接口A,但是又不添加新的方法。这样有什么意义吗?
- Poor Use Case of Object.assign() - Simple Example
- NameError: name 'self' is not defined, eve
- Where is the object browser in visual studio C# 20
- Implementation Strategies for Object Orientation
- An object reference is required for the non-static
- Check if the Type of an Object is inherited from a
- When to use Interfaces in PHP
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:
Output data:
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:
regards.
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.
Kirill Fakhroutdinov's online book uml-diagrams.org defines UML as
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:
Object-oriented is analysis and design methodology, while use case is requirements methodology. And be aware of the core development workflow:
If we use UML to do these works, we may have:
UML diagrams in 3. can be replaced by DFD/ER