Then the next topic that we're going to cover is use case analysis. An analysis class is an extraction of one or several classes in define a system implementation. By coming up with all the analysis classes, somehow you can estimate eventually how many classes that you need for implementation. But still it is a good idea to come up with all the analysis classes before you go to implementation, because by knowing what are the analysis classes, you know roughly the classes that you need in order to fulfill all functional requirements. That's why here I say we focus on functional requirements. Notice that the class descriptions that we use for analysis classes are conceptual, but not implementation oriented, because we are doing abstraction. We try to skip details, and attribute types are conceptual, not programming language types. Behavior is defined it by textual descriptions of responsibilities, and relationships are conceptual, not implementation oriented. In analysis classes are one-off to following stereotypes. They can be either boundary, entity, or control analysis classes. If we are talking about boundary classes, then we use this notation to denote a boundary class. A boundary class models, the interaction between the system and its actor. It represents an abstraction of UI elements or devices that we need for a particular functionality. It interacts with actors outside the system as well as objects within the system. The descriptions should be a fairly high conceptual level. For example, you're going to say that, for a particular functionality, we need some UI, but not describe every single button, every single item. The menu that we have within the UI. Again here, we try to perform abstraction to skip details because we try to deal with the complexity of the design. Why do we want to have boundary class in our design? Because we want to encapsulates and isolate changes in the systems interface. If we want to modify the UI of a particular functionality, then we simply have to modify the boundary class. How to identify boundary classes. Usually, they are found from the use case descriptions, starting from the actors. You try to identify the forms and Windows needed to enter data into the system or identify notices and messages that the system uses to response. Notice that you do not model the visual aspects of the interface. That means you don't specify every single button, every single item, every single menu that you have within the interface. We always use these terms for describing interfaces. Initially, we will identify one boundary class instance for each actor use case pair that we have within our use case diagram. For human actors, it represents the UI Window with which the actor interacts with the system. For external system actors, it represents the communication interface to the external system. Now, let's take a look at this example use case model for the ASU course registration system, and the focus on the functionalities that a professor can perform on the system. From the use case diagram, we know that we need some professor UI for the professor to select courses to teach and also with class enrollment information. Now, that means we need a boundary class, professor UI or professor to do something on a system. Then notice that the initial boundary objects can later be aggregated to or become aggregations of other boundary objects. For example, we may have another UI which is select courses to teach UI, which is part of the professor UI. Also request enrollment UI, which is also part of the professor UI. In select courses to teach, we may have further UIs. For example, create schedule UI, review schedule UI, and modify schedule UI. They are part of the select courses to teach UI. Another type of analysis class is what we call entity class. An entity class models information that is long-lived and often persist within the system. We focus on data that persist within the software system. It's not difficult to identify entity classes from the domain model that we have built for the software system. Again, we focus on data that persist within the software system. An entity object, we would likely get this data from a database. Why do we want to have entity class? Because we try to encapsulates and isolate changes to the information it represents. If we want to modify some inflammation on the system, we simply have to modify entity classes. How to identify entity classes we will examine the scenarios of a use-case, and determine what domain model classes are needed to carry out the use-case. We have to go back to our domain model and identify objects that are relevant to a particular use case scenario. For example, for the create schedule scenario we can see that somehow we need to indicate the term and year and the course information and also the teaching schedule. This are the things that persist on the software system. Now you can see that somehow we need this free entity classes for the create schedule scenario. They are classes, course offering, and professor. Within this scenario we also need the ProfessorUI. The last type of analysis class is control class. A control class models coordinates sequencing, transactions, and control behavior. That means control classes they're going to control the behavior of the software system. Notice that a control class instance usually does not have a correspondence in the application domain. A control object provides the glue that ties other classes together in one use case realization. We use control class to glue different classes together within a use case scenario and a control class instance is used to represent control related to a specific use case or business-logic. By using control class, we can encapsulate and isolate changes to control or business-logic. That means if you want to change the logic of the behavior of the program, we simply have to modify control classes. How do we identify control classes? Initially, we assign one control update for each actor and use case pair. This update is responsible for the flow of events within to use case. If you have some complicated behavior within the use case then we may need several control classes. It's also possible that we can combine several control objects together or eliminate some of the last important control objects. Notice that a control objects should only be tied to at most one actor. Why? Because changes in system requirements are often initiated from actors. Also by associating a control object with at least one actor, we isolate changes required to only to functionality needed by that particular actor. That's why for simplicity, we tie the control object to at most one actor. Now for the functionality, select courses to teach. Now you can see that we need some ProfessorUI and we also need a SelectCoursesToTeachMgr to control the behavior within this use case. This are the entity classes that we need, the data objects that we need for this particular use case. Then now you may ask, how do we connect the boundary control and entity objects together? This are the rules that you can use for connecting different objects together within a use case. Notice that actors, they can interact only with boundary objects. Boundary objects they can interact only with control objects. It's not possible for one UI to interact directly with another UI. If you want one UI to interact with another UI, it has to be done through a control object. Entity object can interact only with control objects. That means, for example, one data object cannot interact directly with another data object. It has to be done through a controller. Control objects can interact with boundary entity or another control objects. This are the rules that we can use for connecting analysis objects together. Now you can see that a professor is going to use to ProfessorUI, which is connected to the SelectCoursesToTeachMgr to Controller to modify the data that we have within this use case. Why do we want to partition a use case into this three types of classes? Because for each functionality we will need some UI. We will need some controller, and also we will need some data. That's why we partition the use case into this three types of classes. A goal is that we try to achieve localization of changes and try to achieve a stable system. Why? Because let's say if we want to modify the UI, then we simply have to modify the boundary classes without touching the other two types of classes. Or if we want to modify the behavior of a functionality, we simply have to modify the controllers without touching again the outer two types of classes. But in reality, we may need to make many judgments about where to place the functionality. We will talk about different decide patterns that can help guide the decisions. We will cover design patterns in the upcoming lectures now for this use case, select courses to teach we're going to have this analysis classes and then they trace back to this use case in our use case model. They trace relationship facilities future system maintainance. Now let's say we want to modify or maintain this particular functionality, select courses to teach. Then we can always trace back to our use case documentation and then get more details about this particular functionality.
