Systems Analysis Exam 2 Study guide
Systems Analysis Exam 2 Study guide IS3020
Popular in Systems analysis and design
Popular in Information technology
This 3 page Study Guide was uploaded by Tam Notetaker on Wednesday April 6, 2016. The Study Guide belongs to IS3020 at University of Cincinnati taught by Dr. Windeler in Spring 2016. Since its upload, it has received 32 views. For similar materials see Systems analysis and design in Information technology at University of Cincinnati.
Reviews for Systems Analysis Exam 2 Study guide
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 04/06/16
Use case Diagram: Illustrates in a very simple way the main functions of the system and the different kinds of users that will interact with it. An analyst can employ use cases and the use case diagram to better understand the functionality of the system at a very high level. Elements of use case diagrams: 1.) Actors: An actor is not a specific user but instead is a role that a user can play while interacting with the system. An actor can also represent another system in which the current system interacts. Actors represents the principal elements in the environment in which the system operates. Actors can provide input to the system, receive output from the system or both. Sometimes an actor plays a specialized role of a more general type of actor. 2.) Use case: A use case, depicted by an oval in the UML, is a major process that the system performs and that benefits an actor or actors in some way; it is labeled using a descriptive verb noun phrase. 3 examples of use cases are Manage appointments, produce schedule, and record availability 3.) Subject Boundary: The use cases are enclosed within a subject boundary, which is a box that defines the scope of the system and clearly delineates what parts of the diagram are external or internal to it. One of the most difficult decisions to make is where to draw the subject boundary. A subject boundary can be used to separate a software system from its environment, a subsystem from other subsystems within the software system, or an individual process in a software system. They also can be used to separate an information system, including both software and internal actors, from its environment. The name of the subject can appear inside or on top of the box. The subject boundary is drawn based on the scope of the system. In the appointment system, we assumed that the management and doctor actors are outside of the scope of the system, that is, they use the system. 4.) Association: Use cases are connected to actors through association relationships; these relationships show with which use cases the actors interact. A line drawn from an actor to a use case depicts an association. The association typically represents a two way communication between the use case and the actor. If the communication is only one way, then a solid arrowhead can be used to designate the direction of flow of information. Finally, it is possible to represent the multiplicity of the association by showing an asterisk at either end of the association between the patient (actor) and the manage appointments (use case). This simply indicates that an individual patient executes the manage appointments use case as many times as he or she wishes and that it is possible for the appointment part of the manage appointments use case to be executed by many different patients.5.) Generalization relationship: Sometimes an actor plays a specialized role of a more general type of actor. For example, there may be times when a new patient interacts with the system in a way that is somewhat different from a general patient. In this case, a specialized actor (new patient) can be placed on the model, shown using a line with a hollow triangle at the end of the more general actor (patient). The specialized actor inherits the behavior of the more general actor and extends it in some way. 6.) Extend relationship: To increase the ease of understanding a use case diagram, higher level use cases are normally drawn above the lower level ones. Let’s assume that every time a patient makes an appointment, the patient is asked to verify payment arrangements. However, it is occasionally necessary to actually make new payment arrangements. Therefore, we may want to have a use case called Make payment arrangements that extends the manage appointments use case to include this additional functionality. An arrow labeled with extend is drawn from the make payment arrangements use case to the manage appointment use case to denote this special use case relationship. The make payment arrangements use case was drawn lower than the manage appointments use case. (Optional Behavior) 7.) Include relationship: There are times when a single use case contains common functions that are used by other use cases. For example, suppose there is a use case called manage schedule that performs some routine tasks needed to maintain the doctor’s office appointment schedule, and the two use cases record availability and produce schedule both perform routine tasks. (Mandatory behavior) Identifying Major use cases: 1.) Review Requirements Definition: This helps the analyst to get a complete overview of the underlying business process being modeled. 2.) Identify the systems boundaries: This helps the analyst to identify the scope of the system. However, as we work through the development process, the boundary of the system most likely will change. 3.) Identify the primary actors and their goals: The primary actors involved with the system comes from a list of stakeholders and users. Recall that a stakeholder is a person, group, or organization that can affect a new system, whereas an actor is a role that a stakeholder or user plays, not a specific user. The goals represent the functionality that the system must provide the actor for the system to be a success. For example, does the actor need to create, read, update, delete, or execute any information currently in the system, are there any external changes of which an actor must inform the system, or is there any information that the system should give the actor. As actors are identified and their goals are uncovered, the boundary of the system will change. 4.) Identify the business processes and major use cases: Rather than jumping into one use case and describing it completely at this point, we only want to identify the use cases. Identifying only the major use cases at this time prevents the users and analysts from forgetting key business processes and helps the users explain the overall set of business processes for which they are responsible. It is important at this point to understand and define acronyms and jargon so that the project team and others from outside the user group can clearly understand the use cases. 5.) Carefully review the current set of use cases: It may be necessary to split some of the use cases into multiple use cases or merge some of them into a single use case. Also, based on the current set, a new use case may be identified. You should remember that identifying use cases is an iterative process, with users often changing their minds about what a use case is and what it includes. It is very easy to get trapped in the details at this point, so you need to remember that the goal at this step is to only identify the major use cases. For example, in the doctors office example, we defined one use case as manage appointments. This use case included the cases for both new patients and existing patients, as well as for when a patient changes or cancels an appointment. We could have defined each of these activities as separate use cases, but this would have created a huge set of small use cases. The trick is to select the right size so that you end up with three to nine use cases in each system. If the project team discovers many more than eight use cases, this suggests that the use cases are too small or that the system boundary is too big. If more than nine use cases exist, the use cases should be grouped together into packages to make diagrams easier to read and keep the models at a reasonable level of complexity. Creating a Use Case Diagram: 1.) Place and draw the use cases: These are taken directly from major use cases previously identified. Special use associations (include, extend, or generalization) are also added to the model at this point. Be careful in laying out the diagram. There is no formal order to the use cases, so they can be placed in whatever fashion is needed to make the diagram easy to read. Also, for understandability purposes, there should be no more then 3-9 use cases on the model so the diagram is as simple as possible. These include use cases that have been factored out and now are associated with another use case through the include, extend, or generalization. 2.) Place and draw the actors: Like use case placement, to minimize the number of lines that cross on the diagram, the actors should be placed near the use cases with which they are associated. 3.) Draw the subject boundary: This forms the border of the subject, separating use cases from actors. 4.) Add the associations: Drawing lines to connect the actors to the use cases with which they interact. No order is implied by the diagram, and the items added along the way do not have to be placed in a particular order; therefore, it might help to rearrange the symbols a bit to minimize the number of lines that cross, making the diagram less confusing. Activity Diagrams and Busines Processes: 1.) Activity Diagrams: Portray the primary activities and the relationships among the activities in a process. (Internal view) In many ways, activity diagrams can be viewed as sophisticated data flow diagrams, that are used in conjunction with structured analysis; however, unlike data flow diagrams, activity diagrams include notation that addresses the modeling of parallel, concurrent activities and complex decision processes. Activity diagrams can be used to model everything from a high level business workflow that involves many different use cases, to the details of an individual use case, all the way down to the specific details of an individual method. 2.) Business Processes: Describe the different activities that, when combined, support a business. (External view) Elements of an Activity Diagram 1. Actions & Activities: Actions and activities are performed for some business reason. Actions and activities can represent manual or computerized behavior. They are depicted in an activity diagram as a rounded rectangle. They should have a name that begins with a verb and ends with a noun (Get Patient information, Make payment arrangements). Names should be short, yet contain enough information so that the reader can easily understand exactly what they do. The only difference between an action and an activity is that an activity can be decomposed further into a set of activities and/or actions, whereas an action represents a simple non decomposable piece of the overall behavior being modeled. Typically, only activities are used for business process or workflow modeling. In most cases, each activity is associated with a use case. 2. Initial node: Portrays the beginning of a set of actions or activities. An initial node is shown as a small filled in circle. 3. Final activity node: Used to stop all control flows and object flows in an activity. Any time a final activity node is reached, all actions and activities are ended immediately, regardless of whether they are completed. A final activity node is represented as a small circle with an X in it. 4. Final flow node: Similar to a final activity node, except that it stops a specific path of execution through the business process but allows the other concurrent or parallel paths to continue. A final flow node is represented as a circle surrounding a small, filled in circle, making it resemble a bull’s eye. 5. Decision node: Used to represent the actual test condition that determines which of the paths exiting the decision node is to be traversed. In this case, each exiting path must be labeled with a guard condition which represents the value of the test for that particular path to be executed. For example, the decision node immediately below the “Get patient information” activity has two mutually exclusive paths that could be executed: one for old, or previous, patients, the other for new patients. 6. Merge node: Used to bring back together multiple mutually exclusive paths that have been split up based on an earlier decision (The old and new patient paths are brought back together). However, sometimes, for clarity, it is better not to use a merge node. 7. Fork node: Used to split the behavior of the business process into multiple or concurrent flows. Unlike the decision node, the paths are not mutually exclusive (both paths are executed concurrently). For example, the fork node is used to show two concurrent, parallel processes are to be executed (Parents) 8. Join node: The purpose of the join node is similar to the merge node. It simply brings back together the separate parallel or concurrent flows in the business process into a single flow. 9. Swimlanes: Activity diagrams can model a business process independent of any object implementation. However, there are times when it helps to break up an activity diagram in such a way that it can be used to assign responsibility to objects or individuals who would actually perform the activity. This is especially useful when modeling a business workflow and is accomplished through the use of swimlanes. For example, swimlanes can be used to break up among two parents the making of a school lunch compromising a peanut butter and jelly sandwich, a drink, and dessert. In this case we use vertical swimlanes. We could also draw the activity diagram using more of a left to right orientation instead of a top down orientation. Guidelines for Activity Diagrams: 1.) Because an activity diagram can be used to model any kind of process, you should set the context or scope of the activity being modeled. Once you have determined the scope, you should give the diagram an appropriate title. 2.) You must identify the activities, control flows, and object flows that occur between the activities. 3.) You should identify any decisions that are part of the process being modeled. 4.) You should attempt to identify any prospects for parallelism in the process. 5.) You should draw the activity diagram. Creating an Activity Diagram: 1.) First you must choose a business process that was previously identified to model. To do this, you should review the requirements definition and the use case diagram created to represent the requirements. You should also review all of the documentation created during the requirements gathering process, for example, reports created that documented interviews or observations, any output from any JAD sessions, any analysis of any questionnaires used, and any story cards or task lists created. In most cases, the use cases on the use case diagram will be the best place to start. For example, in the appointment system, we had identified three primary use cases: Manage appointments, produce schedule, and record doctor availability. We also identified a whole set of minor use cases which will be useful in identifying the elements of the activity diagram. 2.) Second, identify the set of activities necessary to support the business process. For example, 3 processes are identified as being part of the manage appointments business process (Manage appointments, Produce schedules, and record availability). Also, by reviewing the use case diagram, we see that five minor use cases are associated with the manage appointments major use case. Based on this information, we can identify a set of activities. In this case,, the activities are update patient information, make payment arrangements, create new patient, create appointment, cancel appointment, and change appointment which are all includes are extends. 3.) Third, identify the control flows and nodes necessary to document the logic of the business process. For example, the make payment arrangements and update patient information use cases are extensions to the manage appointments and make old patient appointment use cases. We know that these use cases are executed only in certain circumstances. From this we can infer that the activity diagram must include some decision and merge nodes. Based on the requirements definition, we can infer another set of decision and merge nodes based on the create appointment, cancel appointment, and change appointment activities identified in the previous step. 4.) Fourth, identify the object flows and nodes necessary to support the logic of the business process. Typically object nodes and flows are not shown on many activity diagrams used to model a business process. The primary exception is if information captured by the system in one activity is used in an activity that is performed later, but not immediately after the activity that captured the information. 5.) Fifth, lay out and draw the activity diagram to document the business process. For esthetic and understandability reasons, just as when drawing a use case diagram, you should attempt to minimize potential line crossings. Use case descriptions: Provide a means to more fully document the different aspects of each individual use case. It depicts activities performed by the users. The use case descriptions are based on the identified requirements, use case diagram, and the activity diagram descriptions of the business processes. Use case descriptions contain all the information needed to document the functionality of the business processes. When creating use case descriptions, the project team must work closely with the users to fully document the functional requirements. Organizing the functional requirements and documenting them in a use case description is a relatively simple process, but it takes considerable practice to ensure that the descriptions are complete enough to use in structural and behavioral modeling. The best place to begin is to review the use case and activity diagrams. The key thing to remember is that each use case is associated with one and only one role that users have in the system. Types of use cases: 1. Overview use case: Used to enable the analyst and user to agree on a high level overview of the requirements. Typically, overview use cases are created very early in the process of understanding the system requirements, and they document only basic information about the use case, such as its name, ID number, primary actor, type, a brief description, and the relationships among the actors, actors and use cases, and use cases. These can be easily created immediately after the creation of the use case diagram. 2. Detail use case: Typically documents, as far as possible, all the information needed for the use case. These can be based on the activities and control flows contained in the activity diagrams. 3. Essential use case: Describes only the minimum essential issues necessary to understand the required functionality. 4. Real use case: Goes farther and describes a specific set of steps. For example, an essential use case in a doctor office might say that the receptionist should attempt to match the patient’s desired appointment times with the available times, whereas a real use case might say that the receptionist should look up available dates on the calendar using MS exchange to determine if the requested appointment times were available. The primary difference is that essential use cases are implementation independent, whereas real use cases are detailed descriptions of how to use the system once it is implemented. Thus real use cases tend to be used only in the design, implementation, and testing. Elements of use case Descriptions: 1. Overview Information: The overview of information identifies the use case and provides basic background information about the use case. The use case name should be a verb-noun phrase (Make old patient Appt). The use case ID number provides a unique way to find every use case and also enables the team to trace design decisions back to a specific requirement. The use case type is either overview or detail and essential or real. The primary actor is usually the trigger of the use case – the person or thing that starts the execution of the use case. The primary purpose of the use case is to meet the goal of the primary actor. The brief description is typically a single sentence that describes the essence of the use case. The importance level can be used to prioritize the use cases. A use case may have multiple stakeholders that have an interest in the use case. Each use case lists each of the stakeholders with each one’s interest in the use case (Old patient and doctor). Each use case typically has a trigger – the event that causes the use case to begin. A trigger can be an external trigger, such as a customer placing an order or the fire alarm ringing, or it can be a temporal trigger, such as a book being overdue at the library or the need to pay rent. 2. Relationships: Use case relationships explain how the use case is related to other use cases and users. There are four basic types of relationships: association, extend, include, and generalization. An association relationship documents the communication that takes place between the use case and the actors that use the use case. An include relationship represents the mandatory inclusion of another use. The include relationship enables functional decomposition – the breaking up of a complex use case into several simpler ones. For example, the manage schedule use case was considered to be complex and complete enough to be factored out as a separate use case that could be executed by the produce schedules and record availability use cases. An extend relationship represents the extension of optional behavior. The generalization relationship allows use cases to support inheritance. For example, the manage appointments use case, was specialized so that a new patient would be associated with the make new patient apt and an old patient could be associated with a make old patient appt. 3. Flow of events: Finally, the individual steps within the business process are described. Three different categories of steps, or flow of events can be documented: normal flow of events, subflows, and alternative or exceptional flows. The normal flow of events includes only steps that normally are executed in a use case. The steps are listed in the order in which they are performed. In some cases, the normal flow of events should be decomposed into a set of subflows to keep the normal flow of events as simple as possible. Examples of the subflows are Create appointment, cancel appointment, and change appointment. Alternative or exceptional flows are ones that do happen but are not considered to be the norm. These must be documented. For example, we have identified 2 alternative or exceptional flows. The first one simply addresses the situation that occurs when the set of requested appointment times are not available. The second one is simply a second step to the alternative flow. Like the subflows, the primary purpose of separating out alternate or exceptional flows to keep the normal flow of events as simple as possible. 4. Optional characteristics: Other characteristics of use cases can be documented by use case descriptions. These include the level of complexity of the use case, the estimated amount of time it takes to execute the use case, the system with which the use case is associated, specific data flows between the primary actor and the use case, any specific attribute, constraint, or operation associated with the use case, any preconditions that must be satisfied for the use case to execute, or any guarantees that can be made based on the execution of the use case. Guidelines for use case descriptions: 1.) First, write each individual step in the form subject-verb-direct object and, optionally, preposition-indirect object. This form of sentence has proved to be useful in identifying classes and operations. For example, the first step in the normal flow of events, the patient contacts the office regarding an appointment, suggests the possibility of three classes of objects: Patient, office, and appointment. This approach simplifies the process of identifying the classes in the structural model. 2.) Second, make clear who or what is the initiator of the action and who or what is the receiver of the action in each step. Normally, the initiator should be the subject of the sentence and the receiver should be the direct object of the sentence. For example, the patient provides the receptionist with his or her name and address, clearly portrays the patient and the initiator and the receptionist as the receiver. 3.) Third, write the step from the perspective of an independent observer. To accomplish this, each step might have to be written first from the perspective of both the initiator and the receiver. Based on the 2 points of view, the bird’s eye view version can then be written. For example, the patient provides the receptionist with his or her name and address, neither the patient’s nor the receptionist’s perspective is represented. 4.) Fourth, write each step at the same level of abstraction. Each step should make about the same amount of progress toward completing the use case as each of the other steps. On high level use cases, the amount of progress could be very substantial, whereas in a low level use case, each step could represent only incremental progress. 5.) Fifth, ensure that the use case contains a sensible set of actions. Each use case should represent a transaction. Therefore, each use case should compromise four parts: The primary actor initiates the execution of the use case by sending a request to the system; The system ensures that the request is valid; The system processes the request and possibly changes its own internal state; The system sends the primary actor the result of the processing. 6.) The last guideline deals with repeating steps. For example, it is normally better to write repeat steps A through E until some condition is met after step E. It makes the use case more readable to people unfamiliar with programming. Creating Use case descriptions: 1.) The first step is to choose one of the use cases to document with a use case description. Using the importance level of the use case can help do this. For example, the make old patient apt use case has an importance level of high. As such, it should be one of the earlier use cases to be expanded. The criteria suggested by Larman can also be used to set the prioritization of the use cases, as noted earlier. An alternative approach suggests that each use case should be voted on by each member of the development team. In this approach, each team member is given a set of “dots” that they can use to vote on the use cases. They can use all of their dots to vote for a single use case, or they can spread them over a set of use cases. The use cases then can be ranked in order of the number of dots received. Use case descriptions are created for the individual use cases based on the rank order. 2.) The second step is to create an overview description of the use case, that is, name the primary actor, set the type for the use case, list all of the identified stakeholders and their interests in the use case, identify the level of importance of the use case, give a brief description of the use case, give the trigger information for the use case, and list the relationships in which the use case participates. 3.) The third step is to fill in the steps of the normal flow of events required to describe each use case. The steps focus on what the business process does to complete the use case, as opposed to what actions the users or other external entities do. In general, the steps should be listed in the order in which they are performed, from first to last. In writing the use case, remember the seven guidelines described earlier. The goal at this point is to describe how the chosen use case operates. One of the best ways to begin to understand how an actor works through a use case is to visualize how to interact with the system and of thinking about how other systems work (informal benchmarking) are important techniques that help analysts and users understand how systems work and how to write a use case. It is important to remember that at this point in the development of a use case, we are interested only in the typical successful execution of the use case. If we try to think of all the possible combinations of activities that could go on, we will never get anything written down. At this point, we are only looking at 3-7 major steps. 4.) The fourth step is to ensure that the steps listed in the normal flow of events are not too complex or too long. Each step should be about the same size as the others. For example, if we were writing steps for preparing a meal, steps suck as take fork out of drawer and put fork on table are much smaller than prepare cake using mix. If we end up with more than seven steps or steps that vary greatly in size, we should go back and review each step carefully and possibly rewrite steps. One good approach to produce steps for a use case is to have the users visualize themselves actually performing the use case and to have them write down the steps as if they were writing a recipe for a cookbook. 5.) The fifth step focuses on identifying and writing the alternative or exceptional flows. Alternative or exceptional workflows are flows of success that represent optional or exceptional behavior. They tend to occur infrequently or as a result of a normal flow failing. They should be labeled so that there is no doubt as to which normal flow of events it is related. (The requested appointment time was not available.) 6.) The sixth step is to carefully review the use case description and confirm that the use case is correct as written, which means reviewing the use case with the users to make sure each step is correct. The review should look for opportunities to simplify a use case by decomposing it into a set of smaller use cases, merging it with others, looking for common aspects in both the semantics and syntax of the use cases, and identifying new use cases. This is also the time to look into adding the include, extend, and/or generalization relationships between use cases. The most powerful way to confirm a use case is to ask the user to role play, or execute the process using the written steps in the use case. The analyst hands the user pieces of paper labeled with the major inputs to the use case and has the user follow the written steps like a recipe to make sure that those steps really can produce the outputs defined for the use case using its inputs. 7.) The seventh and final step is to iterate the entire set of steps again. Users often change their mind about what is a use case and what it includes. It is very easy to get trapped in the details at this point, so remember that the goal is to just address the major use cases. Therefore, the analyst should continue to iterate these steps until he or she and the users believe that a sufficient number of use cases has been documented to begin identifying candidate classes for the structural model. As candidate classes are identified, it is likely that the additional use cases will be uncovered. Verification and validation through walkthroughs: A walkthrough is essentially a peer review of a product. In the case of the functional models, a walkthrough is a review of the different models and diagrams created during functional modeling. This review typically is completed by a team whos members come from the development team and the client. The purpose of the walkthrough is to thoroughly test the fidelity of the functional models to the functional requirements and to ensure that the models are consistent. That is, a walkthrough uncovers errors or faults in the evolving specification. However, a walkthrough does not correct errors, it simply identifies them. Error correction is to be accomplished by the team after the walkthrough is completed. For example, if the presenter is walking through an activity diagram, another member of the team could ask why certain activities or objects were not included. The actual process of simply presenting the representation to a new set of eyes can uncover obvious misunderstandings and omissions. In fact, many time the act of walking through the representation cause a presenter to see the error themselves. For psychological reasons, hearing the representation helps the analyst to see the representation more completely. There are specified roles that different members of the walkthrough team can play. The first is the presenter role which should be played by the person who is primarily responsible for the specific representation being reviewed. This individual presents the representation to the walkthrough team. The second role is a recorder or a scribe. The recorder should be a member of the analysis team. This individual carefully takes minutes of the meeting by recording all significant events that occur during the walkthrough. Another important role is the maintenance oracle which is someone who raises issues regarding maintenance of the representation. Owing to the emphasis on reusability in object oriented development, this role becomes particularly crucial. Finally someone must be responsible for calling, setting up, and running the walkthrough meetings. Verifying a use case description: 1.) First, when comparing an activity diagram to a use case description, there should be at least one event recorded in the normal flow of events, subflows, or alternative/exceptional flows of a use case description for each activity or action that is included on an activity diagram, and each event should be associated with an activity or action. 2.) Second, all objects portrayed as an object node in an activity diagram must be mentioned in an event in the normal flow of events, subflows, or alternative/exceptional flows of the use case description. 3.) Third, sequential order of the events in a use case description should occur in the same sequential order of the activities contained in an activity diagram. 4.) Fourth, when comparing a use case description to a use case diagram, there must be one and only one use case description for each use case, and vice versa. 5.) Fifth, all actors listed in a use case description must be portrayed on the use case diagram. Each actor must have an association link that connects it to the use case and must be listed with the association relationships in the use case description. 6.) Sixth, in some organizations we should also include the stakeholders listed in the use case description as actors in the use case diagram. 7.) Seventh, all other relationships listed in a use case description (include, extend, and generalization) must be portrayed on a use case diagram. 8.) Eighth and final step, there are many diagram specific requirements that must be enforced. For example, in an activity diagram a decision node can be connected to activity or action nodes only with a control flow, and for every decision node there should be a matching merge node. Every type of node and flow has different restrictions. Structural models: The goal of the analyst is to discover the key data contained in the problem domain and to build a structural model of the objects. Object oriented modeling allows the analyst to reduce the semantic gap between the underlying problem domain and the evolving structural model. One of the primary purposes of the structural model is to create a vocabulary that can be used by the analyst and the users. Structural model represent the things, ideas, or concepts that are contained in the domain of the problem. They will also allow the representation among the things, ideas, or concepts. Nonetheless, the structural model at this point should represent the responsibilities of each class and the collaborations among the classes. Classes: A class is a general template that we use to create specific instances, or objects, in the problem domain. All objects of a given class are identical of a given class are identical in structure and behavior but contain different data in their attributes. The main building block of a class diagram is the class, which stores and manages information in the system. During analysis, classes refer to the people, places, and things about which the system will capture information. There are two different general kinds of classes of interest during analysis: Concrete and abstract. 1. An abstract class does not produce instances because they are used merely as templates for other, more specific classes. Person is an example of an abstract class. 2. Concreate classes: are classes that leads to instances. Patient would be an example of a concrete class because If Mary and Jim are instances of the patient class, the patient class produced those 2 patients. Attribute: An attribute of an analysis class represents a piece of information that is relevant to the description of the class within the application domain of the problem being investigated. An attribute contains information the analyst or user feels the system should store. For example, a possible relevant attribute of an employee class is their name, whereas one that might not be as relevant is hair color. Only attributes that are important to the task should be included in the class. Finally, only attributes that are primitive or atomic types (integers, strings, doubles, date, time, etc.) should be added. Different types of attributes are: 1. At times, you might want to store derived attributes, which are attributes that can be calculated or derived; these special attributes are denoted by placing a slash (/) before the attribute’s name. 2. Visibility of the attribute relates to the level of information hiding to be enforced for the attribute. The visibility of an attribute can be public (+), protected (#), or private (-). A public attribute is one that is not hidden from any other object. As such, other objects can modify its value. A protected attribute is one that is hidden from all other classes except its immediate subclasses. A private attribute is one that is hidden from all other classes. The default visibility for an attribute is normally private. Operations: Actions or functions that a class can perform. The functions that are available to all classes (create a new instance, return a value for a particular attribute, set a value for a particular attribute, delete an instance) are not explicitly shown within the class rectangle. Instead, only operations unique to the class are included, such as the cancel without notice operation in the appointment class and the calculate last visit operation in the patient class. There are four kinds of operations that a class can contain: 1. Constructor operation: Creates a new instance of a class. For example, the patient class may have a method called insert (), which creates a new patient instance as patients are entered into the new system. 2. Query Operation: Makes information about the state of an object available to other objects, but it does not alter the object in any way. For instance, the calculate last visit () operation that determines when a patient last visited the doctor’s office will result in the object’s being accessed by the system, but it will not make any change to its information. If a query method merely asks for information from attributes in the class, then it is not shown on the diagram because we assume that all objects have operations that produce the values of their attributes. 3. Update operation: Changes the value of some or all the object’s attributes, which may result in a change in the object’s state. Consider changing the status of a patient from new to current with a method called change status () or associating a patient with a particular appointment with make appointment (appointment). 4. Destructor operation: Simply deletes or removes the object from the system. For example, if an employee object no longer represents an actual employee associated with the firm, the employee could need to be removed from the employee database, and a destructor operation would be used to implement this behavior. Relationships: A primary purpose of a class diagram is to show the relationships, or associations, that classes have with one another. These are depicted on the diagram by drawing lines between classes. When multiple classes share a relationship (or a class shares a relationship with itself), a line is drawn and labeled with either the name of the relationship or the roles that the classes play in the relationship. For example, the two classes patient and appointment are associated with one another whenever a patient schedules an appointment. Thus, a line labeled schedules connects patient and appointment, representing exactly how the two classes are related to each other. There is also a small solid triangle beside the name of the relationship which shows the direction of which way the relationship is associated. 1. Aggregation and Composition Relationships: Relate to parts to wholes or parts to assemblies. For example, a door is part of a car, an employee is part of a department, or a department is part of an organization. Like the generalization relationship, aggregation relationships can be combined into aggregation hierarchies. For example, a piston is a part of an engine, and an engine is part of a car. Aggregation relationships are bidirectional. The flip side of aggregation is decomposition. The analyst can use decomposition to uncover parts of a class that should be modeled separately. For example, if a door and an engine are a part of a car, then a car has parts, door and engine. The analyst can bounce around between the various parts to uncover new parts. For example the analyst can ask, “What other parts are there to a car?” or “To which other assemblies can a door belong?” 2. Association Relationships: These relationships are usually a weaker form of the aggregation relationship. For example, a patient schedules an appointment. It could be argued that a patient is a part of an appointment. However, there is a clear semantic difference between this type of relationship and one that models this relationship between doors and cars or even workers and unions. Thus they are simply considered associations between instances of classes. 3. Generalization: The generalization abstraction enables the analyst to create classes that inherit attributes and operations of other classes. The analyst creates a superclass that contains the basic attributes and operations that will be used in several sub- classes. The subclasses inherit the attributes and operations of their superclass and can also contain attributes and operations that are unique just to them. For example, a customer class and an employee class can be generalized into a person class by extracting the attributes and operations they have in common and placing them into the new superclass, person. In this way, the analyst can reduce the redundancy in the class definitions so that the common elements are defined once and then reused in the subclasses. Association class: There are times when a relationship itself has associated properties, especially when its classes share a many to many relationship. An association class has its own attributes and operations. It is shown as a rectangle attached by a dashed line to the association path, and the rectangle’s name matches the label of the association. For example, the grade idea is really an intersection of the student and course classes, because a grade exists only at the intersection of these two ideas. Multiplicity: Documents how an instance of an object can be associated with other instances. Numbers are placed on the association path to denote minimum number.. Maximum number. The numbers specify the relationship from the class at the far end of the relationship line to the end with the number. Class diagrams: A static model that shows the classes and the relationships among classes that remain constant in the system over time. The class diagram depicts classes, which include both behaviors and states, with the relationships between the classes. Simplifying class diagrams: When a class diagram is fully populated with all the classes and relationships for a real world system, the class diagram can become very difficult to interpret. When this occurs, it is sometimes necessary to simplify the diagram. There are three ways in doing so: 1. One way to simplify the diagram is to show only concrete classes. However, depending on the number of associations that are connected to abstract classes – and thus inherited down to the concrete classes – this particular suggestion could make the diagram more difficult to comprehend. 2. A second way to simplify the class diagram is through the use of a view mechanism. Views were developed originally with relational database management systems and are simply a subset of the information contained in the database. In this case, the view would be a useful subset of the class diagram, such as a use-case view that shows only the classes and relationships relevant to a particular use case. A second view could be to show only a particular type of relationship: aggregation, association, or generalization. A third type of view is to restrict the information shown with each class, for example, show only the name of the class, the name and attributes, or the name and operations. These view mechanisms can be combined to further simplify the diagram. 3. A third approach to simplifying a class diagram is through the use of packages (i.e., logical groups of classes). To make the diagrams easier to read and keep the models at a reasonable level of complexity, the classes can be grouped together into packages. Packages are general constructs that can be applied to any of the elements in UML models. Object diagram: Essentially an instantiation of all or part of a class diagram. Instantiation means to create an instance of the class with a set of appropriate attribute values. Object diagrams can be very useful when trying to uncover details of a class. Generally speaking, it is easier to think in terms of concrete objects (instances) rather than abstractions of objects (classes). Class and object identification 1. Textual analysis: An analysis of the text in the use case descriptions. The analyst starts by reviewing the use case descriptions and the use case diagrams. The text in the descriptions is examined to identify potential objects, attributes, operations, and relationships. The nouns in the use case suggest possible classes, and the verbs suggest possible operations. The textual analysis of use-case descriptions has been criticized as being too simple, but because its primary purpose is to create an initial rough-cut structural model, its simplicity is a major advantage. For example, if we applied these rules to the make old patient apt use case, we can easily identify potential objects for an old patient, doctor, appointment, patient, office, receptionist, name, address, patient information, payment, date, and time. We also can easily identify potential operations that can be associated with the identified objects. For example, patient contacts office, make a new appointment, cancel an existing appointment, change an existing appointment, match requested appointment times and dates with requested times and dates, and find current appointment. 2. Brainstorming: Brainstorming is a discovery technique that has been used successfully in identifying candidate classes. Essentially, in this context, brainstorming is a process of a set of individuals setting around a table and suggesting potential classes that could be useful for the problem under consideration. Typically, a brainstorming session is kicked off by a facilitator who asks the set of individuals to address a specific question or statement that frames the session. For example, using the appointment problem described previously, the facilitator could ask the development team and users to think about their experiences of making appointments and to identify candidate classes based on their past experiences. It simply asks the participants to identify the objects with which they have interacted. For example, a potential set of objects that come to mind are doctors, nurses, receptionists, appointment, illness, treatment, prescriptions, insurance card, and medical records. Once a sufficient number of candidate objects have been identified, the participants should discuss and select which of the candidate objects should be considered further. Once these have been identified, further brainstorming can take place to identify potential attributes, operations, and relationships for each of the identified objects. 3. Common list of objects: A list of objects common to the business domain of the system. Several categories of objects have been found to help the analyst in creating the list, such as physical or tangible things, incidents, roles, and interactions. Analysts should first look for physical or tangible things in the business domain. These could include books, chairs, and office equipment. Normally, these types of objects are the easiest to identify. Incidents are events that occur in the business domain, such as meetings, flights, performances, or accidents. Reviewing the uses can readily identify the roles that people play in the problem, such as doctor, nurse, patient, or receptionist. Typically an interaction is a transaction that takes place in the business domain, such as a sales transaction. Other types of objects that can be identified include places, containers, organizations, business records, catalogs, and policies. 4. Patterns: A useful group of collaborating classes that provide a solution to a commonly occurring problem. Cause patterns provide a solution to commonly occurring problems, they are reusable. It is possible to put together commonly found object oriented patterns to form elegant object oriented information systems. For example, many business transactions involve the same types of objects and interactions. Virtually all transactions would require a transaction class, a transaction line item class, an item class, a location class, and a participant class. By simply reusing these existing patterns of classes, we can more quickly and more completely define the system than if we start with a blank piece of paper. CRC cards and role playing o CRC Cards: Are used to document the responsibilities and collaborations of a class. We use an extended form of the CRC card to capture all relevant information associated with a class. a. Responsibilities of a class can be broken down into two separate types: Knowing and Doing. Knowing responsibilities are those things that an instance of a class must be capable of knowing. An instance of a class typically knows the values of its attributes and its relationships. Doing responsibilities are those things that an instance of a class must be capable of doing. In this case, an instance of a class can execute its operations or it can request a second instance, which it knows about, to execute its operations on behalf of the first instance b. The structural model describes the objects necessary to support the business processes modeled by the use cases. Most use cases involve a set of several classes, not just one class. These classes form collaborations. Collaborations allow the analyst to think in terms of clients, servers, and contracts. A client object is an instance of a class that sends a request to an instance of another class for an operation to be executed. A server object is the instance that receives the request from the client object. A contract formalizes the interactions between the client and server objects. For example, a patient makes an appointment with a doctor. This sets up an obligation for both the patient and doctor to appear at the appointed time. Otherwise, consequences, such as billing the patient for the appointment regardless of whether he or she appears, can be dealt out. Also, the contract should spell out what the benefits of the contract will be, such as treatment being prescribed for whatever ails the patient and a payment to the doctor for the services provided. The attributes of the class represent the knowing responsibilities that each instance of the class has to meet. o Role playing: In general, members of the team perform roles associated with the actors and objects previously identified with the different use cases. Technically speaking, the members of the team perform the different steps associated with a specific scenario of a use case. Remember, a scenario is a single, unique execution path through a use case. A different scenario exists for each time a decision node cause a split in the execution path of the use case. 1. Review use cases: The first step is to review the use case descriptions. This allows the team to pick a specific use case to role play. Even though it is tempting to try and complete as many use cases as possible in a short time, the team should not choose the easiest use cases first. Instead, at this point in the development of the system, the team should choose the use case that is the most important, the most complex, or the least understood. 2. Identify relevant actors and objects: The second step is to identify the relevant roles that are to be played. Each role is associated with either an actor or an object. To choose the relevant objects, the team reviews each of the CRC cards and picks the ones that are associated with the chosen use case. For example, if we were going to role play the make old patient apt use case, we can easily identify that the old patient and doctor are actors. By reading the event section of the use case description, we identify the internal actor of receptionist. After identifying all of the relevant roles, we assign each one to a different member of the team. 3. Role play scenarios: The third step is to role play scenarios of the use case by having the team members perform each one. To do this, each team member must pretend that they are an instance of role assigned to them. For example, if a team member was assigned the role of receptionist, then he or she would have to be able to perform the different steps in the scenario associated with the receptionist. It is important to list the steps that the receptionist has to do explicitly in order to not have the actor (receptionist) make assumptions. Processes are repeated until the scenario is performed successfully. 4. Repeat steps 1-3: the fourth step is to simply repeat steps 1-3 for the remaining use cases. Creating Structural models using CRC cards and class diagrams: 1.) Create CRC cards: Performing textual analysis on the use case descriptions. Reviewing the primary actors, stakeholders, and interests, and brief description of each use case allows additional candidate objects to be identified. It is useful to go back and review the original requirements to look for information that was not included in the text of the use cases. Record all the uncovered information for each candidate object on a CRC card. 2.) Review CRC cards: The second step is to review the CRC cards to determine if additional candidate objects, attributes, operations, and relationships are missing. In conjunction with this review, using the brainstorming and common object list approaches described earlier can aid the team in identifying missing classes, attributes, operations, and relationships. For example, the team could start a brainstorming session with a set of questions such as: What are the tangible things associated with the problem? What are the roles played by the people in the problem domain? What incidents and interactions take place in the problem domain? 3.) Role play the CRC cards: The third step is to role play each use case scenario using CRC cards. Each CRC card should be assigned to an individual, who will perform the operations for the class on the CRC card. As the performers play out their roles, the system tends to break down. When this occurs, additional objects, attributes, operations, or relationships will be identified. Again, as in the previous steps, any time any new information is discovered, new CRC cards are created or modifications to existing CRC cards are made. 4.) Create class diagram: The fourth step is to create the class diagram based on the CRC cards. Information contained on the CRC cards is simply transferred to the class diagrams. The responsibilities are transferred as operations, the attributes are drawn as attributes, and the relationships are drawn as generalization, aggregation, or association relationships. However, the class diagram also requires that the visibility of the attributes and operations be known. As a general rule, attributes are private and operations are public. Finally, the analyst should examine the model for additional opportunities to use aggregation or generalization relationships. These types of relationships can simplify the individual class descriptions. As in the previous steps, all changes must be recorded on the CRC cards. 5.) Review class diagram: The fifth step is to review the structural model for missing and/or unnecessary classes, attributes, operations, and relationships. Up until this step, the focus of the process has been on adding information to the evolving model. At this point, the focus begins to switch from simply adding information to also challenging the reasons for including the information contained in the model. One very useful approach here is to play devil’s advocate, where a team member, just for the sake of being a pain in the neck, challenges the reasoning for including all aspects of the model. 6.) Incorporate patterns: The sixth step is to incorporate useful patterns into the evolving structural model. A useful pattern is one that would allow the analyst to more fully describe the underlying domain of the problem being investigated. Looking at the collection of patterns available (Figure 5-5) and comparing the classes contained in the patterns with those in the evolving class diagram does this. After identifying the useful patterns, the analyst incorporates the identified patterns into the class diagram and modifies the affected CRC cards. This includes adding and removing classes, attributes, operations, and/or relationships. 7.) Review the model: The seventh and final step is to validate the structural model, including both the CRC cards and the class diagram. Verifying and validating CRC cards: 1.) First, every CRC card should be associated with a class on the class diagram, and vice versa. For example, the old patient class represented by the CRC card does not seem to be included on the class diagram. However, there is a patient class on the class diagram. The old patient CRC card most likely should be changed to simply patient. 2.) Second, the responsibilities listed on the front of the CRC card must be included as operations in a class on a class diagram, and vice versa. For example, the make appointment responsibility on the new Patient CRC card also appears as the make appointment(s) operation in the Patient class on the class diagram. Every responsibility and operation must be checked. 3.) Third, collaborators on the front of the CRC card imply some type of relationship on the back of the CRC card and some type of association that is connected to the associated class on the class diagram. For example, the appointment collaborator on the front of the CRC card also appears as another association on the back of the CRC card and as an association on the class diagram that connects the Patient class with the Appointment class. 4.) Fourth, attributes listed on the back of the CRC card must be included as attributes in a class on a class diagram, and vice versa. For example, the amount attribute on the new Patient CRC card is included in the attribute list of the Patient class on the class diagram. 5.) Fifth, the object type of the attributes listed on the back of the CRC card and with the attributes in the attribute list of the class on a class diagram implies an association from the class to the class of the object type. For example, technically speaking, the amount attribute implies an association with the double type. However, simple types such as int and double are never shown on a class diagram. Furthermore, depending on the problem domain, object types such as Person, Address, or Date might not be explicitly shown either. However, if we know that messages are being sent to instances of those object types, we probably should include these implied associations as relationships. 6.) Sixth, the relationships included on the back of the CRC card must be portrayed using the appropriate notation on the class diagram. For example in Figure 5-6, instances of the Patient class are a-kind-of Person, it has instances of the Medical His- tory class as part of it, and it has an association with instances of the Appointment class. Thus the association from the Patient class to the Person class should indicate that the Person class is a generalization of its subclasses, including the Patient class; the association from the Patient class to the Medical History class should be in the form of an aggregation association (a white diamond); and the association between instances of the Patient class and instances of the Appointment class should be a simple association. 7.) Seventh, an association class, such as the Treatment class in Figure 5-7, should be created only if there is indeed some unique characteristic (attribute, operation, or relationship) about the intersection of the connecting classes. If no unique characteristic exists, then the association class should be removed and only an association between the two connecting classes should be displayed. Finally, as in the functional models, specific representation rules must be enforced. For example, a class cannot be a subclass of itself. The Patient CRC card cannot list Patient
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'