As a quick review, we've gone over five main UML diagrams so far. One of the first, was the context, problem and frame set of diagrams. These represent the system scope for the system that was or the system to be. In these diagrams you draw out key system components, connected by edges representing the shared phenomena between the components. After that we had the ER or the entity relationship diagram. In the ER diagram, you create entities which are concepts that have distinct identities and share common features. Some of these entities will also have attributes, like a name, a range of values etc. Then, you show relationships between the entities. These conceptually are linking ideas. For example, participants, an entity, are invited to meetings, another entity. Next, we discussed SADT diagrams, including the actigram and the datagram. Two very closely related diagrams that are ideal for completeness and consistency checking through automated tools. SADT diagrams show the activities that process data. Actigrams declare the activities by their input and output and interconnect them through data dependency links. Datagrams declare system data by their producing and consuming activities and interconnect them through control dependency links. Data flow diagrams are related to these two SADT diagrams, but are much simpler than SADTs. Also a bit more vague. Data flow diagrams, or DFDs, show operations and their data dependencies for system components. Operations transform data and move it to other operations, or, if it's not moving to another operation, then it moves it to a data initializer or finalizer. Possibly, we're also interacting with data repositories. Lastly, we discussed the use case. Use cases were also associated with misuse cases and abuse case diagrams, where misuse and abuse cases are both very commonly seen in security work. Use case diagrams are one of the simplest diagrams that you can make and it mainly helps you to identify all of the operations an interactive system component has to perform. Most of the time, we'd start by making use cases especially if we're working in an agile environment. They're easy to think about, easy to understand by all, the customers and the developers. But I think more importantly, is that they lead us toward the path of making more complex diagrams. Like all these other ones that we've discussed. Data flow diagrams and entity relationship diagrams are the next most commonly used. In data flow diagrams, we see terminal elements or system components, we see the activities and operations that work on data and how the data flows through. In the ER diagram, the entity relationship diagram, we can see the entities or the items, people and aggregate data, and how they all interact. The ER diagram can also be divided, as can the data flow diagram, into smaller entities and general actions or from the ER diagram, you could just remove the relationships and use those for class diagrams which are very helpful for developers. The ER diagram and the DFD show two different views but they are complimentary. Remember that both model problems, they are not modeling software. In these diagrams, you were asking questions like, What information do you need to perform the next step? What information does the step produce that we then need to store? In the data flow models we're showing the process of getting, using and storing data. Entity relationship diagrams show how that data is then all related. In addition to these two types of diagrams, you can also provide a data dictionary to provide all of the data items. When using the entity relationship diagram, the data flow diagram and the Data Dictionary all together, you can really help team members to communicate and arrive at a common understanding of whatever this new process is that needs to be developed. For you developers out there, be really careful to remember that you are modeling the problem, not creating the software. As the requirements engineer, these are preliminary steps in the software engineering process and you want them to be preliminary. You are using this to confirm with your customer, that you're doing the right thing. You're relaying that information to the rest of the software team. And you're also writing out all these diagrams not only for everyone's understanding, but also to prove that you have consistency and completeness in your requirements. Now you don't have any holes.
