Actor/Role <<actor>> Actor/RoleUse Case
top. – Represents the scope of the subject, e.g., system or individual business process.
An association relationship: – Links an actor with the use case(s) with which it interacts.
An include relationship: – Represents the inclusion of the functionality of one use case within another. – Has an arrow drawn from the base use case to the used use case.
An extend relationship: – Represents the extension of the use case to include optional behavior. – Has an arrow drawn from the extension use case to the base use case.
A generalization relationship: – Represents a specialized use case to a more generalized one. – Has an arrow drawn from the specialized use case to the base use case.
Don't forget about the age old question of quantitative methods exam
Identifying Major Use Cases Steps: – 1. Review Requirements Definition Subject <<include>> <<extend>> ∙ This helps the analyst get an overview of underlying bus. process being modeled. – 2. Identify Subject’s Boundaries ∙ This helps the analyst identify the scope of the system. – 3. Identify Primary Actors & Goals ∙ The primary actors involved with the system comes from a list of stakeholders and users. ∙ The goals represent the functionality that the system must provide the actor for the system to be a success. – 4. Identify Business Processes & Major Use Cases ∙ The requirements definition is a very useful beginning point for this step. – 5. Review Current Set of Use Cases ∙ The goal at this step is to only identify the major use cases. Creating a Use-Case Diagram Steps: – 1. Place & Draw Use Cases ∙ These are taken from the major use cases previously identified. ∙ Special use-case associations (include, extend, or generalization) are added to the model at this point. ∙ There should be no more than 3 to 9 use cases on the model so the diagram is as simple as possible. These include use cases that have been factored our and now are associated with another use case through the include, extend, or generalization relationships. – 2. Place & Draw Actors ∙ To minimize number of lines that cross on the diagram, the actors should be placed near the use cases with which they are associated. – 3. Draw Subject Boundary ∙ This forms the border of the subject, separating use cases (subject’s functionality) from actors (roles of external users). – 4. Add Associations ∙ Draw lines to connect the actors to the use cases with which they interact. Business Process Modeling With Activity Diagrams Martin Schedlbauer, The Art of Business Process Modeling: The Business Analysts Guide to Process Modeling with UML & BPMN (Sudbury, MA: The Cathris Group, 2010) Practices to follow when modeling business processes: *Don’t be a perfectionist! Be realistic… Be agile… All modeling is collaborative/social activity… Do not use CASE tool to do the modeling but whiteboards instead… Process modeling should be done in an iterative manner… Stay focused on the specific process… Remember that a business process model is an abstraction of reality… Elements of an Activity Diagram Activity diagrams – portray primary activities and the relationships among the activities in a process. Actions and Activities – Can represent manual or computerized behavior. – Depicted by: rounded rectangle. – Activity can be broken down further into a set of activities and/or actions. – Action represents a simple non-decomposable piece of overall behavior being modeled. – Only activities are used for bus. process or work-flow modeling. – Each activity is associated with a use case. Object Nodes – Activities and actions typically modify/transform objects. – Object nodes – model objects in an activity diagram. – Depicted by: rectangles. – Represent the flow of info from one activity to another activity. Control Flows and Object Flows – Control flows – model the paths of execution through a bus. process. – Depicted by: solid line with arrowhead showing direction of flow. – Control flows can only be attached to actions/activities. – Object flows – model the flow of objects through a bus. process; necessary to show the actual objects that flow into/out of the actions/activities. – Depicted by: dashed line with arrowhead showing direction of flow. – An individual object flow must be attached to an action/activity on one end and an object node on the other end. Control Nodes – 7 different types:– Initial node – portrays beginning of a set of actions/activities. Small filled in circle – Final-activity node – used to stop the process being modeled. Bulls-eye ∙ Anytime this type of node is reached, all actions/activities are ended immediately, regardless of whether they are completed. – Final-flow node – stops a specific path of execution through a bus. process but allows other concurrent/parallel paths to continue. Small circle with X in it – Decision node – represent the actual test condition that determines which of the paths exiting the decision node is to be traveled through. ∙ Each exiting path must be labeled with a guard condition. ∙ Guard condition – represents the value of the test for that particular path to be executed. – Merge node – used to bring back together multiple mutually exclusive paths that have been split based on an earlier decision. – Fork node – used to split behavior of the bus. process into multiple parallel/concurrent flows. – Join node – bring back together parallel/concurrent flows in the bus. process into a single flow. Swimlanes Syntax for an Activity Diagram
An action: – Is a simple, non-decomposable piece of behavior. – Is labeled by its name.
An activity: – Is used to represent a set of actions. – Is labeled by its name.
An object node: – Is used to represent an object that is connected to a set of object flows. – Is labeled by its class name.
A control flow: – Shows the sequence of execution.
An object flow: – Shows the flow of an object from one activity (or action) to another activity (or action).
An initial node: – Portrays the beginning of a set of actions/activities.
A final-activity node: – Is used to stop all control flows and object flows in an activity/action.
A final-flow node: – Is used to stop a specific control flow or object flow.
A decision node: – Is used to represent a test condition to ensure that the control flow or object flow only goes down one path. – Is labeled with the decision criteria to continue down the
Action Activity Class Name
A merge node: – Is used to bring back together different decision paths that were created using a decision node. –
A fork node: – Is used to split behavior into a set of parallel or concurrent flows of activities/actions.
A join node: – Is used to bring back together a set of parallel or concurrent flows of activities/actions.
A swimlane: – Is used to break up an activity diagram into rows and columns to assign the individual activities/actions to the individuals or objects that are responsible for executing the activity/action. – Is labeled with the name of the individual/object responsible.
Guidelines for Creating Activity Diagrams Swimlane Scott Ambler, The Object Primer: The Application Developer’s Guide to Object Orientation and the UML, 2nd ed. (Cambridge) and The Elements of UML Style Guidelines: – Set context/scope of activity being modeled. Once you’ve determined the scope, give the diagram an appropriate title. – Identify the activities, control flows, and object flows that occur between the activities. – Identify any decision that are part of the process. – Attempt to identify any prospects for parallelism. – Draw the activity diagram. Creating Activity Diagrams 5 steps in creating an activity diagram to document and model a business process: – 1. Choose a Business Process ∙ Review the requirements definition and the use-case diagram. Also, review all documentation created during the requirements-gathering process, ex. Reports from interview or observations, any input from JAD sessions, analysis of questionnaires used, and any story cards or task lists created. – 2. Identify Activities ∙ Review the functional requirements for the business process as well as the use-case diagram. Based on this info, you can identify a set of activities. – 3. Identify Control Flows & Nodes – 4. Identify Object Flows & Nodes – 5. Lay Out & Draw Diagram ∙ Attempt to minimize potential line crossings. Business Process Documentation with Use Cases & Use-Case Descriptions Use-case diagrams – provide a bird’s-eye view of the basic functionality of the bus. processes contained in the evolving system. Activity diagrams – open up the black box of each bus. process by providing a more-detailed graphical view of the underlying activities that support each bus. process. Use-case descriptions – based on the identified requirements, use-case diagram, and the activity diagram descriptions of the bus. processes. They contain all the info needed to document the functionality of the business processes. Types of Use Cases Overview use case – used to enable the analyst and user to agree on a high level overview of the requirements. Essential use case – describes only the minimum essential issues necessary to understand the required functionality. – Real use case – describes a specific set of steps. Elements of a Use-Case Description – Use-case description – contains all the info needed to build the structural and behavioral diagrams that follow, but it expresses the info in a less formal way that is easier for users to comprehend. A use-case description has 3 basic parts: overview information, relationships, and the flow of events. Overview Information – Overview information – identifies the use case and provides basic background info about the use case. – Use-case name – should be a verb-noun phrase (ex. Make Old Patient Appt.) – 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. – Use-case type – either overview or detail and essential or real. – Primary actor – usually the trigger of the use case—person/thing that starts the execution of the use case. – The main purpose of the use case is to meet the goal of the primary actor. – Brief description – a single sentence describing the essence of the use case. – Importance level – can be used to prioritize the use cases. It enables the users to explicitly prioritize which bus. functions are most important and need to be a part of the frist version of the system. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design Rate each use case over the following criteria using a scale from 0 to 5: ∙ The use case represents an important business process. ∙ The use case supports revenue generation or cost reduction. ∙ Technology needed to support the use case is new/risky and therefore requires considerable research. ∙ Functionality described in the use case is complex, risky, and/or time critical. Depending on a use case’s complexity, it may be useful to consider splitting its implementation over several different versions.∙ The use case could increase understanding of the evolving design relative to the effort expended. – A use case may have multiple stakeholders that have an interest in the use case. – Each use case typically has a trigger—the event that causes the use case to begin. ∙ External trigger – ex. Customer placing an order or the fire alarm ringing. ∙ Temporal trigger – ex. Book being overdue at the library or the need to pay rent. Relationships – Use-case relationships – explain how the use case is related to other use cases and users. – 4 basic types of relationships: association, extend, include, and generalization. ∙ Association relationship – documents the communication that takes place between the use case and the actors that use the use case. ∙ Include relationship – represents the mandatory inclusion of another use case. ∙ Extend relationship – represents the extension of the functionality of the use case to incorporate optional behavior. ∙ Generalization relationship – allows use cases to support inheritance. Flow of Events – 3 different categories of steps (flow of events): ∙ Normal flow of events - includes only steps that normally are executed in a use case. These steps are listed in the order in which they are performed. ∙ Subflows – the breaking down of the normal flow of events to keep it as simple as possible. These subflows are based on the control flow logic in the activity diagram representation of the business process. ∙ Alternative (exceptional) flows – flows that do happen but are not considered to be the norm. These must be documented. Like the subflows, the primary purpose of separating out alternate/exceptional flows is to keep the normal flow of events as simple as possible. – The more difficult it is to understand the use case, the more likely events should be factored out into subflows, or subflows and/or alternative or exceptional flows should be factored out into separate use cases that are called by the current use case. Guidelines for Creating Use-Case Descriptions 1. Write each set in the form of subject-verb-direct object (and sometimes preposition indirect object). 2. Make sure it is clear who the initiator of the step is. 3. Write the steps from the perspective of the independent observer. 4. Write each step at about the same level of abstraction. 5. Ensure the use case has a sensible set of steps. 6. Apply the KISS principle liberally. 7. Write repeating instructions after the set of steps to be repeated. Each use case should comprise of 4 parts:1. The primary actor initiates the execution of the use case by sending a request (and possibly data) to the system. 2. The system ensures that the request (and data) is valid. 3. The system processes the request (and data) and possibly changes its own internal state. 4. The system sends the primary actor the result of the processing. Creating Use Case Descriptions (pg. 181-182) Set of steps used to guide the creation of a use-case description for each use case in the use-case diagram based on the requirements definition and the use-case and activity diagrams. – 1. Choose a Use Case – 2. Create Overview Description – 3. Describe the Normal Flow of Events – 4. Check the Normal Flow of Events – 5. Identify Alternative or Exceptional Flows – 6. Review the Use-Case Description – 7. Repeat Until Done Verifying & Validating The Business Process and Functional Models Verification & Validation through Walkthroughs Walkthrough – review of the different models and diagrams created during the functional modeling. The purpose of a walkthrough is to thoroughly test the reliability of the functional models to the functional requirements and to ensure that the models are consistent. A walkthrough uncovers/identifies the errors or faults in the evolving specification. Specified roles different members of the walkthrough team can play: – Presenter role – 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. – Recorder/Scribe role – should be a member of the analysis team. This individual carefully takes the minutes of the meeting by recording all significant events that occur during the walkthrough. – Maintenance oracle role – someone who raises issues regarding the maintenance of the representation. Due to the emphasis on reusability in object-oriented development, this role becomes particularly crucial. – Someone also must be responsible for calling, setting up, and running the walkthrough meetings. [Facilitator?] Functional Model Verification & Validation 3 different representations for the functional model: activity diagrams, use case descriptions, and use-case diagrams. Set of rules to ensure that these 3 representations are consistent among themselves. – 1. When comparing an activity diagram to a use-case description, there should be at least on event recorded in the NFoE, subflows, or alt./excep. flows of the use-case description for each activity/action that is included on an activity diagram, and each event should be associated with an activity/action. – 2. All objects portrayed as an object node in an activity diagram must be mentioned in an event in the NFoE, subflows, or alt./excep. flows of the use-case description.– 3. Sequential order of events in a use-case description should occur in the same sequential order of the activities contained in an activity diagram. – 4. 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. All actors listed in a use-case description must be portrayed on the use case diagram. – 6. In some organizations, we should also include the stakeholders listed in the use-case description as actors in the use-case diagram. – 7. All other relationships listed in a use-case description (include, extend, and generalization) must be portrayed on a use-case diagram. – 8. There are many diagram-specific requirements that must be enforced: ∙ In an activity diagram, a decision node can be connected to activity/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. Chapter 5 – Structural Modeling Structural Models A structural model is a formal way of representing the objects that are used and created by a business system. It illustrates people, places, or things about which info is captured and how they are related to one another. It is drawn using an iterative process in which the model becomes more detailed and less conceptual overtime. A conceptual model is drawn by analysts showing the logical organization of the objects without indicating how the objects are stored, created, or manipulated. Because this model is free from implementation or technical details, analysts can focus on matching model to real bus. requirements of the system. The goal of analyst is to discover the key data contained in the problem domain and to build a structural model of the objects. One of the primary purposes of structural model is to create vocabulary that can be used by the analysts and the users. Classes, Attributes, and Operations Classes – general template used to create specific instances, or objects, in the problem domain. Concrete classes – used to create objects. Abstract classes – do not actually exist in the real world; they are simply useful abstractions. There are domain classes, user-interface classes, data structure classes, file structure classes, operating environment classes, document classes, and various types of multimedia classes. An attribute of an analysis class represents a piece of info that is relevant to the description of class within the application domain of the problem being investigated. The behavior of an analysis class is defined in an operation or service. In later phases these operations are converted to methods. We use the term operation to describe the actions to which the instances of the class are capable of responding. Relationships Generalization Relationships – Generalization – enables the analyst to create classes that inherit attributes and operations of other classes. – Superclass – created by analyst that contains basic attributes and operations that will be used in several sub-classes. – Generalization is represents with a-kind-of relationship. Aggregation Relationships – Many different types of aggregation: ∙ a-part-of (logically or physically) ∙ a-member-of (as in set membership) ∙ contained-in ∙ related-to ∙ associated-with – Generally, aggregation relationships relate parts to wholes or parts to assemblies. – We use a-part-of or has-parts semantic relationships to represent aggregation. – Aggregation relationships are bidirectional. The flip side of aggregation is decomposition; analyst can use decomposition to uncover parts of a class that should be modeled separately. Association Relationships – There are other types of relationships that are not generalization (a-kind of) or aggregation (a-part-of). – These other types of relationships are considered to be associations between instances of classes. Object Identification Textual Analysis Textual analysis – analysis of the text in use-case descriptions. The text in the description is studied to identify potential objects, attributes, operations and relationships. The nouns in the use case suggest possible classes; the verbs suggest possible operations. Textual Analysis Guidelines A common or improper noun implies a class of objects. A proper noun or direct reference implies an instance of a class. A collective noun implies a class of objects made up of groups of instances of another class. An adjective implies an attribute of an object. A doing verb implies an operation. A being verb implies a classification relationship between an object and its class. A having verb implies an aggregation or association relationship. A transitive verb implies an operation. An intransitive verb implies an exception. A predicate or descriptive verb phrase implies an operation. An adverb implies an attribute of a relationship or an operation. Brainstorming Brainstorming – discovery technique that has been used to identify candidate classes. It is a process of a group of individuals brought together to suggest potential classes that could be useful for the problem under consideration. Useful principles to guide brainstorming: – All suggestions should be taken seriously because they could be good suggestions. – All participants should think fast and furiously at first. – The facilitator must manage the process as well as ensure that all participants are involved and few participants do not dominate the process. A round-robin approach or electronic brainstorming tool could be used to execute this successfully. – The facilitator can use humor to break the ice. Common Object Lists Common object list – list of objects common to the business domain of the system. Analysts should first look for physical or tangible things in the business domain. Incidents – events that occur in the bus. domain, such as meetings, flights, performances, or accidents. Roles – job/duty that a person/people play in the problem, such as doctor, nurse, patient, or receptionist. Interaction – transaction that takes place in the bus. domain, such as a sales transaction. Other types of objects that can be identified include places, containers, organizations, business records, catalogs, and policies. Patterns Pattern – useful group of collaborating classes that provide a solution to a commonly occurring problem. Patterns are reusable. CRC Cards CRC (Class-Responsibility-Collaboration) Cards – used to document the responsibilities and collaborations of a class. Responsibilities & Collaborations Knowing Responsibilities – things that an instance of a class must be capable of knowing. Doing Responsibilities – things that an instance of a class must be capable of doing. Collaborations – allow the analyst to think in terms of clients, servers, and contracts. – Client object is an instance of a class that sends a request to an instance of another class for an operation to be executed. – Server object is the instance that receives the request from the client object. – Contract formalizes the interactions between the client and server objects. Elements of a CRC Card Front of card contains: class’s name, ID, type, description, associated use cases, responsibilities, and collaborators.– Name of class should be a noun. – Description is a brief statement used as a textual definition for the class. – Responsibilities of the class tend to be the operations that the class must contain. Back of card contains: attributes and relationships of the class. – Attributes of the class represent the knowing responsibilities that each instance of the class has to meet. CRC cards are used to document the essential properties of a class. Role-Playing CRC Cards with Use Cases 1. Review the use-case descriptions. 2. Identify the relevant roles that are to be played. 3. Role-play scenarios of the use case. 4. Repeat steps 1 through 3 for remaining use cases. Class Diagrams Class diagram – is a static model that shows the classes and the relationships among classes that remain constant in the system over time. It depicts classes, which include both behaviors and states, with the relationships between the classes. Elements of a Class Diagram Class – stores and manages information in the system. – During analysis, classes refer to people, places, and things in the system. During design and implementation, classes refer to implementation specific artifacts such as windows, forms, and other objects used to build the system. – Derived attributes – attributes that can be calculated or derived (i.e., lastname, firstname, address, phone, and birthdate). The special aatributes are denoted by placing a slash (/) before the attrributes’s name. – Visibility – relates to the level of info hiding to be enforced for the attribute. ∙ Public attribute – one that is not hidden from any other object. Is denoted using a plus sign (+). ∙ Protected attribute – one that is hidden from all other classes except its immediate subclasses. It is denoted using a hashtag (#). ∙ Private attribute – one that is hidden from all other classes. Is denoted using a minus sign (-). Operations – actions/functions that a class can perform. – 4 kinds of operations ∙ Constructor operations – creates a new instance of a class. ∙ Query operation – makes info about the state of an object available to other objects, but it does not alter the object in any way. ∙ Update operation – changes the value of some or all object’s attributes, which may result in a change in the object’s state. ∙ Destructor operation – deletes/removes the object from the system. Relationships – Primary purpose of a class diagram is to show the relationships/associations that classes have with one another. – Relationships have multiplicity – documents how an instance of an object can be associated with other instances.– When a relationship itself has associated properties, esp. when classes share a many-to-many relationship, an association class is formed, which has its own attributes and operations. – Generalization association shows that one class (subclass) inherits from another class (superclass), meaning the properties and operations of the superclass are also valid for objects of the subclass. – Aggregation association is used when classes actually comprise other classes. Simplifying Class Diagrams One way to simplify class diagrams is to show only concrete classes. Second way is through the use of a view mechanism. Views – subset of the info contained in the database. Third way is through the use of packages. Packages – general constructs that can be applied to any of the elements in UML models. Object Diagrams Object diagram – instantiation of all or part of a class diagram. Instantiation – to create an instance of the class with a set of appropriate attribute values. Creating Structural Models Using CRC Cards and Class Diagrams Important to remember that CRC cards and class diagrams can be used to describe both the as-is and to-be structural models of the evolving system, but they are most used for the to-be model. Use-case-driven process used to create the structural model of a problem domain: 1. Create CRC Cards 2. Review CRC Cards to determine if additional candidate objects, attributes, operations, and relationships are missing. Ask 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 each use-case scenario using CRC Cards 4. Create the Class Diagram based on the CRC Cards 5. Review the Structural Model for missing and/or unnecessary classes, attributes, operations, and relationships 6. Incorporate useful Patterns into the evolving structural model 7. Validated the Structural Model, including both the CRC Cards and the Class Diagram Verifying & Validating The Structural ModelAbstract class- you can’t create an actual version of this, you can only build upon it. What type of employee? Salary, hourly, contract, piece …, etc. Chapter 6 – Behavioral Modeling Behavioral Models One primary purpose of behavioral models is to show how the underlying objects in a problem domain will work together to form a collaboration to support each of the use cases. Behavioral models depict the internal view of the business process that a use case describes. Interaction Diagrams Modeling focus on a class diagram is at the class level, whereas the interaction diagrams focus on the object level. Objects, Operations, & Messages Each object has attributes that describe info about the object, such as patient’s name, birth date, address, and phone number. Each object also has behaviors. At this point in the development of the evolving system, the behaviors are described by operations. An operation is nothing more than an action that an object can perform. Later on in development, the behaviors will be implemented as methods. Each object can send and receive messages. Messages are info sent to objects to tell an object to execute on of its behaviors. Sequence Diagrams Sequence diagrams - illustrate the objects that participate in a use case and the messages that pass between them over time for one use case. A sequence diagram is a dynamic model that shows the explicit sequence of messages that are passed between objects in a defined interaction. Elements of a Sequence Diagram Sequence Diagram Syntax
Term & Definition
An actor: - Is a person/system that derives benefit from and is external to the system. - Participates in a sequence by sending and/or receiving messages. - Is placed across the top of the diagram. - Is depicted either as a stick figure (default) or, if a nonhuman actor is involved, as a rectangle with <<actor>> in it (alternative).
We also discuss several other topics like schempp test
We also discuss several other topics like chapter 13 how populations evolve
Don't forget about the age old question of How did the character of the free black community shape the Philadelphia riot?
We also discuss several other topics like Who discovered the Autralopithecus Anamensis?
Don't forget about the age old question of the ability of sperm cells to move along the ductus deferens is due to