In chapter ten, we looked at data and how to identify classes that were needed from Use Cases. In Chapter 11, we look at Information Exchange through Events. An Event is not the data that has been changed, but rather that information has been exchanged between elements. An Event occurs when information that is exchanged:…
Many times, two or more analysis classes are related to one another in some fashion or another. In UML this is called associations. With Object Oriented code, we often ask if two classes are related or associated through a is-a or has-a type relationship. For example: a car (and object) has a(n) engine (an other…
Operations define the behaviors of the object. While there are lots of different behaviors, they can often be broken down into four main categories. Those that manipulate data often have a set in their function name. Such as setPassword(). Those that check the state of an object usually return a boolean value, and use the…
Attributes help describe a class. They are what help us differentiate from one object and another. Attributes should be relevant to the system that you are building. So two similar objects might have very different attributes based upon how it is used. Consider a College Student Athlete. The data needed for your sports team is…
Some things are easy to identify as a class. For example, if you look around the room, you can find lots of physical objects which can be made into classes. However, in a software environment, this may not always be as easy to identify. So look at the following questions to start to identify what…
There are times and cases when a use case using simple text, cannot properly describe a process. In those cases, look to supplement the Use Case to make it easier to understand the process. Activity diagrams can be used to show the workflow of a process the the user/system should take. A Swimlane diagram can…
A successful software product can be measured in many different ways (accuracy, speed, etc) however user satisfaction is often at the top of the list. A use case should properly describe how a user is going to use the system, so that it can be easily modeled and built – so that the users are…
Chapter 9 will focus on scenario bases modeling. Throughout analysis modeling, your focus should be on what, not how. While everything may not be known, we can approach this in an iterative method refining the model until everything is uncovered. The requirements model should have 3 primary objectives: Elements of an analysis modeling: Requirements Analysis…
