Use cases<\/h2>\n
This diagram is used at the beginning of the development process to define the application requirements and scope. It shows the system functions and their links to actors. It responds the question ‘what does the system do?’ (without addressing how it does it).<\/p>\n
![\"\"](\"https:\/\/blogs.ubc.ca\/coetoolbox\/files\/2014\/02\/usecase.jpg\")
<\/p>\n
A use case diagram has the following components:<\/p>\n
- \n
- Actor<\/span>: a role within the business environment<\/li>\n
- Use case<\/span>: an operation performed in the system to produce a meaningful result for a user<\/li>\n
- Relationship<\/span>: an association between an actor and a use case<\/li>\n
- System<\/span>: the application boundary<\/li>\n<\/ul>\n
Activity Diagrams<\/h2>\n
Shows the order in which actions are performed in a business activity either human or computer actors. An activity is more general concept than an action, it is a behavior that can be reused in many places, whilst actions are used only at determined points within an activity.<\/p>\n
![\"\"](\"http:\/\/www.sparxsystems.com\/images\/screenshots\/uml2_tutorial\/ad03.GIF\")
<\/a><\/p>\nAn activity diagram has the following components:<\/p>\n
- \n
- Actions<\/span>: a single step within an activity such as an arithmetic computation, a call to an operation or manipulation of object contents. Actions can have attached constraints.<\/li>\n
- Control flow<\/span>: the sequence of action execution, represented by arrows between actions.<\/li>\n
- Start and final nodes<\/span>: show the start and end of control flow.<\/li>\n<\/ul>\n
It may also have the following type of nodes:<\/p>\n
- \n
- Decision and merge<\/span>: checks conditions that allow the flow to continue.<\/li>\n
- Fork and join<\/span>: indicate the start \/ end of concurrent threads of control. the join synchronizes two inflows and produces a single outflow. The outflow from a join cannot execute until all inflows have been received.<\/li>\n<\/ul>\n
Activity diagrams can also have partitions<\/span> or swim lanes that separate actions based on the actors that perform them.<\/p>\n
Component Diagrams<\/h2>\n
A component diagram shows the parts of a design for a software system. It is useful to understand how the significant elements of a software system fit together, especially in the early stages of development.<\/p>\n
![\"\"](\"http:\/\/www.sparxsystems.com\/images\/screenshots\/uml2_tutorial\/CD04.GIF\")
<\/a><\/p>\nComponent diagrams have the following components:<\/p>\n
- \n
- Components<\/span>: autonomous, encapsulated units, usually a piece of software or group of classes. Their dependencies are designed such that they can be treated as independently as possible.<\/li>\n
- Connectors<\/span>: \u2018wire\u2019 components together based on interface compatibility.<\/li>\n<\/ul>\n
Component diagrams have more elements, but these two provide a good starting point for your application design. Its utility isn’t in understanding low-level implementation details, but in performing an initial level of decomposition. On the Decision Support Systems<\/a> section you can see the typical components of an OR application. Some of the benefits of using component diagrams are:<\/p>\n
- \n
- Helps the development team to understand an existing design and create a new one.<\/li>\n
- Helps improve the separation between the components, making the design easier to change when requirements change.<\/li>\n
- Its independent of the language or platform the application uses.<\/li>\n<\/ul>\n
Sequence diagrams<\/h2>\n
Sequence diagrams show how different components interact during the functioning of a system. Use them for the most frequent or important functions to\u00a0 explain the existing components and the messages that trigger their interactions.<\/p>\n
![\"\"](\"https:\/\/blogs.ubc.ca\/coetoolbox\/files\/2014\/02\/sequence-diagram-example1.jpg\")
<\/p>\nA sequence diagram has the following components:<\/p>\n
- \n
- Lifelines<\/span>: dashed lines that represent the lifeline of a component or actor.<\/li>\n
- Interactions<\/span>: messages between components represented by arrows.<\/li>\n
- Activations<\/span>: execution occurrences represented by narrow rectangles<\/li>\n<\/ul>\n
A good programming practice is to separate interactions between the interface and the other application components (model, database). This is done by creating an entity controller<\/span>, an independent component that controls the connections between the interface and other components. In an OR application you can have a controller for the model and another for the database. The main advantage of having controllers is that, if there are changes in the business requirements, they help to localize modifications without disrupting the tool design. (See robustness analysis<\/a> for more details.)<\/p>\n
State Charts<\/h2>\n
- Interactions<\/span>: messages between components represented by arrows.<\/li>\n
- Lifelines<\/span>: dashed lines that represent the lifeline of a component or actor.<\/li>\n
- Connectors<\/span>: \u2018wire\u2019 components together based on interface compatibility.<\/li>\n<\/ul>\n
- Fork and join<\/span>: indicate the start \/ end of concurrent threads of control. the join synchronizes two inflows and produces a single outflow. The outflow from a join cannot execute until all inflows have been received.<\/li>\n<\/ul>\n
- Control flow<\/span>: the sequence of action execution, represented by arrows between actions.<\/li>\n
- Use case<\/span>: an operation performed in the system to produce a meaningful result for a user<\/li>\n
![\"\"](\"http:\/\/www.sparxsystems.com\/images\/screenshots\/uml2_tutorial\/sm01.GIF\")
<\/a><\/p>\n