×
Log in to StudySoup
Get Full Access to UC - IS 3020 - Study Guide - Final
Join StudySoup for FREE
Get Full Access to UC - IS 3020 - Study Guide - Final

Already have an account? Login here
×
Reset your password

UC / Engineering / IS 3020 / Explain the relationship between Business Process and Functional Model

Explain the relationship between Business Process and Functional Model

Explain the relationship between Business Process and Functional Model

Description

School: University of Cincinnati
Department: Engineering
Course: Process Modeling
Professor: Robert rokey
Term: Spring 2017
Tags:
Cost: 50
Name: Study Guide for Exam 2 (Final)
Description: These are textbooks notes covering chapter 4, 5, and 6, in "Systems Analysis & Design with UML Version 2.0 - An Object-Oriented Approach" by Dennis, Wixom, & Tegarden, for the final exam.
Uploaded: 04/12/2017
18 Pages 137 Views 2 Unlocks
Reviews


 Chapter 4 – Business Process & Functional Modeling  Use case – formal way of representing the way a business system interacts with  its environment. It illustrates the activities performed by the users of the  system.   Activity diagram – used for any type of process-modeling activity.  Process models – depict how a business system operates. They illustrate the  processes/activities that are performed and how objects (data) move among  them. It can be used to document a current system (as-is) or new system being  developed (to-be), whether computerized or not.   Logical models – models that describe the business domain’s activities without  suggesting how they are conducted. Sometime referred to as problem domain  models.  Physical models – models provide info that is needed to ultimately build the  system.  Business Process Identification with Use Cases & Use-Cases Diagrams  Elements of Use Case Diagrams  Actor – a role that a user can play while interacting with the system. Can also represent another system in which the current system interacts.   Association – represents the two-way communication between the use case  and the actor.   Use case – major process that the system performs and that benefits an  actor(s) in some way; it is labeled using a descriptive verb-noun phrase.  Subject boundary – defines the scope of the system and describes what parts of the diagram are external or internal. Syntax for Use-Case Diagram

An actor: – Is a person or system that derives  benefit from and is external to the  subject. – Is depicted as either a stick figure  (default) or, if a nonhuman actor is  involved, as a rectangle with  <<actor>> in it (alternative). – Is labeled with its role. – Can be associated with other actors  using a specialization/superclass  association, denoted by an arrow with a  hollow arrowhead. – Is placed outside the subject boundary. A use case:  – Represents a major piece of system  functionality. – Can extend another use case. – Can include another use case. – Is placed inside the system boundary. – Is labeled with a descriptive verb-noun  phase. A subject boundary: – Includes the name of subject inside or on


Ask questions such as: – What are the tangible things associated with the problem?



Don't forget about the age old question of quantitative methods exam

Actor/Role <<actor>> Actor/Role

Use 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.


– What are the roles played by the people in the problem domain?



 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


– What incidents and interactions take place in the problem domain?



We also discuss several other topics like schempp test

 Action  Activity  Class Name specific path. 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). An object:

We also discuss several other topics like chapter 13 how populations evolve

Symbol

- Participates in a sequence by sending  and/or receiving messages. - Is placed across the top of the diagram. A lifeline: - Denotes the life of an object during a  sequence. - Contains an X at the point at which the  class no longer interacts. An execution occurrence: - Is a long narrow rectangle placed atop a  lifeline. - Denotes when an object is  sending/receiving messages. A message: - Conveys info from one object to another  one. - An operation call is labeled with the  message being sent and a solid arrow,  where as a return labeled with the value  being returned and shown as a dashed  arrow. A guard condition: - Represents a test that must be met for  the message to be sent. For object destruction: - An X is placed at the end of the object’s  lifeline to show that it is going out of  existence. A frame: - Indicates the context of the sequence  diagram.

Don't forget about the age old question of How did the character of the free black community shape the Philadelphia riot?

 Guidelines for Creating Sequence Diagrams ∙ Strive for left to right ordering of messages. ∙ If an actor and object represent the same idea, name them the same. ∙ Place the initiator of the scenario on the left of the diagram. ∙ When there are multiple objects of the same type, be sure to name them. ∙ Only show return values when they are not obvious. ∙ Justify message names and return values near the arrowhead.  Creating a Sequence Diagram – 1. Determine the context of the sequence diagram. – 2. Identify the actors and objects that participate in the sequence being  modeled—the actors and objects that interact with each other during the  use-case scenario. – 3. Set the lifeline for each object. – 4. Add the message to the diagram. – 5. Place the execution occurrence on each object’s lifeline. Do this by  drawing a narrow rectangle box over the lifelines to represent when the  classes are sending and receiving the messages.– 6. Validate the sequence diagram.  Communication Diagrams  Communication diagram – portray how dependent the different objects are  on one another. Communication diagram is essentially an object diagram  that shows message-passing relationships instead of aggregation or  generalization associations.  Communication diagrams are equivalent to sequence diagrams, but they  emphasize the flow of messages through a set of objects, where as the  sequence diagrams focus on the time ordering of the messages being  passed.  Elements of a Communication Diagram Communication Diagram Syntax

Term & Definition An actor: - Is a person/system that derives benefit  from and is external to the system. - Participates in a collaboration by sending  and/or receiving messages. - Is depicted either as a stick figure  (default) or, if a nonhuman actor is  involved, as a rectangle with <<actor>>  in it (alternative). An object: - Participates in a collaboration by sending  and/or receiving messages. An association: - Shows an association between actors  and/or objects. - Is used to send messages. A message: - Conveys info from one object to another  one. - Has direction shown using an arrowhead. - Has sequence shown by a sequence  number. A guard condition: - Represents a test that must be met for  the message to be sent. A frame: - Indicates the context of the  communication diagram.

We also discuss several other topics like Who discovered the Autralopithecus Anamensis?

 Guidelines for Creating Communication Diagrams ∙ Apply sequence diagram guidelines 1 through 4. ∙ Do not use communication diagrams to model process flow. Symbol ∙ Use a sequence diagram instead of a communication diagram when spending is  important.  Creating a Communication Diagram – 1. Determine the context of the communication diagram.– 2. Identify the objects (actors) and the associations that link the objects  (actors) that participate in the collaboration together. – 3. Lay out the objects (actors) and their associations on the  communication diagram by placing them together based on the  associations that they have with the other objects in the collaboration. – 4. Add the messages to the associations between the objects. – 5. Validate the communication diagram.  Behavioral State Machines  States, Events, Transitions, Actions, & Activities Behavioral State Machine Diagram Syntax

Term & Definition A state: - Is shown as a rectangle with rounded  corners. - Has a name that represents the state of  an object. An initial state: - Is shown as a small, filled-in circle. - Represents the point at which an object  begins to exist. A final state: - Is shown as a circle surrounding a small,  filled-in circle (bull’s-eye). - Represents the completion of activity. An event: - Is a noteworthy occurrence that triggers a change in state. - Can be a designated condition becoming  true, the receipt of an explicit signal from  one object to another, or the passage of a designated period of time. - Is used to label a transition. A transition: - Indicates that an object in the first state  will enter the second state. - Is triggered by the occurrence of the  event labeling the transition. - Is shown as a solid arrow from one state  to another, labeled by the event name. A frame: - Indicates the context of the behavioral  state machine.

Don't forget about the age old question of the ability of sperm cells to move along the ductus deferens is due to

 Elements of a Behavioral State Machine Guidelines for Creating Behavioral State Machines ∙ Only create behavioral state machines for “complex” objects. ∙ Draw the initial state in the top left corner of the diagram. Symbol ∙ Draw the initial state in the bottom right corner of the diagram. ∙ Use simple, but descriptive, names for states. ∙ Question black hole and miracle states.∙ Make sure guard conditions are mutually exclusive. ∙ Make sure transitions are associated with messages and operations.  Creating a Behavioral State Machine  1. Determine the context of the behavioral state machine.  2. Identify the various states that an object will have over its lifetime.  3. Determine the sequence of the states that an object will pass through its  lifetime.  4. Identify the transitions between the states of the objects and to add the  events, actions, and guard conditions associated with the transitions. – The events are the triggers that cause an object to move from one state  to the next state.  5. Validate the behavioral state machine by making sure that each state is  reachable and that it is possible to leave all states except for final states.  CRUDE Analysis  CRUDE analysis uses a CRUDE matrix, in which each interaction among objects  is labeled with a letter for the type of interaction:  C for create  R for read/reference  U for update  D for delete  E for execute  Verifying & Validating The Behavioral Model  Actors must be consistent between models.  Messages on sequence diagrams must match associations on communication  diagrams.  Every message on a sequence diagram must appear on an association in a  communication diagram.  Guard conditions on a sequence diagram must appear on a communication  diagram.  Sequence of messages must correspond to the top down ordering of messages being sent.  State transitions must be association with a message on a sequence diagram. Entries in a CRUDE matrix imply messages being sent from an actor/object to another  object/actor.
Page Expired
5off
It looks like your free minutes have expired! Lucky for you we have all the content you need, just sign up here