Identifying the actors
Video: Identifying the actorsAn Actor in a use case is anything with behavior who lives outside of your system, outside of your application, but has a goal they want to accomplish within. And these are usually human beings, but not always. Now sometimes coming up with the actor is very straightforward. If you're building a Calculator App for a mobile device or a simple one person game, you may just have one actor, someone who uses the application, the user. However, if you were building, say, a backend internal Payroll Application, you might have multiple people that do very different goals within such as the payroll administrator, or a manager, or an employee, and you also need to interact with other computer systems.
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Identifying the actors
An Actor in a use case is anything with behavior who lives outside of your system, outside of your application, but has a goal they want to accomplish within. And these are usually human beings, but not always. Now sometimes coming up with the actor is very straightforward. If you're building a Calculator App for a mobile device or a simple one person game, you may just have one actor, someone who uses the application, the user. However, if you were building, say, a backend internal Payroll Application, you might have multiple people that do very different goals within such as the payroll administrator, or a manager, or an employee, and you also need to interact with other computer systems.
Perhaps this application will send data to an external system or it needs to interact with another corporate system. Well, these would be considered actors too. They're external to your application, but they need to interact with it. So it's usual to spend a few minutes brainstorming the main actors, and we can actually start with one easy question. Does your App need to interact with other computer systems, other organization? Because even if the Use Case Scenario is complex with these external systems just identifying them as an Actor should be fairly straightforward, and that's all we're doing here.
Now switching to human actors, here's a couple of questions. Do you need to distinguish between Roles or Security Groups? Say if you're building a web application, you might have very different use cases for visitors and for members and for administrators. If you're working on an internal corporate application, thinking about different job titles or departments can also prompt these scenarios. How does the data entry staff interact with the application as opposed to the executive team? Although the idea of the security level or a roll or even a job title might prompt a particular scenario, a particular use case, or make you think of something that you need to write, always do remember that the focus is on the goal that the actor wants to accomplish, and that the same person in the same job title in the same role could actually be different actors on different days.
Now what I mean by that is if you're defining, say, a use case for a new internal Expense Approval System, that might be true that your organization has employees and contractors, full-time and part-time, administrators, managers, executives, all who expect to interact with this application. But the difference between them might not matter at all. If this particular situation comes down to somebody requests and somebody approves, all that might be needed to describe this completely successfully is that you phrase the actor Requester and Approver.
Not a job title, not a specific role, but a perfectly acceptable name for the actors who take part in this particular use case. And it's quite common as in this situation that use cases will involve multiple actors, and we'll typically refer to them as the primary actors and the supporting actors. Now the primary actors aren't necessarily the most important actor in the scenario. They're just the one who initiated this particular use case. So with this situation the primary actor is the Requester.
Anyone else is a secondary actor. So these are just a few of the ways you could brainstorm a quick list of primary actors of your system. Now because sometimes the actors will suggest the goals and sometimes the goals will suggest the actors, both of these are okay, whatever feels most natural. But one thing to bear in mind, the goals of an actor don't always succeed. A use case scenario for a bank might have the account holder actor who has the goal to transfer funds between accounts, and you should start up by describing the successful steps for that.
But you may well need to describe the alternative flow of not enough funds. Goals sometimes fail, and that leads us into talking more about sketching out those Scenarios and goals that the actors want to accomplish.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.