Designing phase with UML

1 Advanced Software Engineering CSC-580 Lecture 5 2 Advanced Software Engineering CSC-580 Lecture 5 What we will cover: (Details of Object Oriented Analysis Modeling) Activity Diagrams and Swim Lanes Finding Classes and CRC cards Chapter 6 Pressman Activity Diagrams An activity diagram is basically a fancy flowchart An activity diagram focuses on the flow of activities involved in a single process The activity diagram shows the how those activities depend on one another Use activity diagrams to: Model the workflow in a system Analyze a use case by describing what actions need to take place and when they should occur Describe a complicated sequential algorithm Model parallel processes http://www.agilemodeling.com/style/ 3 Symbols in Activity Diagrams Initial node — The starting point of the diagram An initial node isn’t required but make it easier to read diagram Final node — The ending point. An activity diagram can have zero or more activity final nodes. Activity — The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create Student Screen. http://www.agilemodeling.com/style/ 4 Symbols in Activity Diagrams II Flow — The arrows on the diagram. Shows the flow of the logic from activity to activity Merge — A diamond with several flows entering and one leaving One or more incoming flows must reach this point until processing continues Continued flow based on any guards on the outgoing flow Decision — A diamond with one flow entering and several leaving The direction of the output depends on the guard conditions for each path http://www.agilemodeling.com/style/ 5 Symbols in Activity Diagrams III Condition (Guards) –Text such as [Incorrect Form] on a flow Defines a guard which must evaluate to true to take that path Fork — A black bar with one flow going into it and several leaving it Used to denote the beginning of parallel activity. Join — A black bar with several flows entering it and one leaving it All flows going into the join must reach it before processing may continue Denotes the end of parallel processing. 6 http://www.agilemodeling .com/style/ Decisions in Activity Diagrams Decisions are created by branches The branch describes what activities will take place based on a set of conditions All branches are eventually followed by a merge Indicates the end of the conditional behavior started by that branch Decision Points Should Reflect the Previous Activity. There are no labels inside the decision point (unlike flowcharts) The guards on the transitions leaving the decision point help to describe the decision http://www.agilemodeling.com/style/ 7 Guards in Activity Diagrams Each Transition Leaving a Decision Point Must Have a Guard Guards Should Not Overlap E.g. Never have x <= 0 and x >= 0 since not consistent Guards on Decision Points Must Form a Complete Set E.g. Guards such as x < 0 and x >0 are not complete Exit Transition Guards Must Form a Complete Set Apply a [Otherwise] Guard for “Fall Through” Logic Guards Are Optional. Only indicate a guard on a transition if it adds value http://www.agilemodeling.com/style/ 8 Parallel Activities in Activity Diagrams A Fork Should Have a Corresponding Join. For every fork (start ) there is a join (end) It is not required to have a join, but it usually makes sense Forks Have One Entry Transition Joins Have One Exit Transition http://www.agilemodeling.com/style/ 9 Piecing an Activity Diagram Together http://www.agilemodeling.com/style/ 10 What is the difference between these two types of conditions (branching versus forking)? Example Activity Diagram http://www.agilemodeling.com/style/ 11 Swimlane Diagrams Activity diagrams can be divided into object swimlanes that determine which object is responsible for which activity. Allows the modeler to represent the flow of activities described by the use-case Also indicates which actor (if there are multiple actors involved in a specific use-case) or class has responsibility for the action described by each specific activity block 12 Swimlane Diagrams II Each Swimlane is a particular actor or class Label each swimlane!! Some design guidelines: Order Swimlanes in a Logical Manner. Apply Swim Lanes To Linear Processes Have Less Than Five Swimlanes http://www.agilemodeling.com/style/ 13 Example Swimlane Diagram 14 Another Example Swimlane Diagram http://www.agilemodeling.com/style/ 15 16 Steps to Defining Candidate Classes 1. Some people advocate writing a 2-3 paragraph system synopsis Use the various models as inputs This story provides good abstraction to identify key themes 2. Define several major themes that identify the central issues of the system 3. Search for Candidate objects that support these themes Next slides give good search strategies 17 Steps to Defining Candidate Classes II 4. Check that these candidates represent key concepts or things 5. Look for additional objects in required supporting mechanisms 6. Develop good names 7. Organize them in varying ways to identify additional abstraction 18 Search Strategies for Objects Good Object candidates often represent: The work the system performs Things directly affected by or connected to the application Information that flows thru the software Decision making, control, and coordination activities Structures and groups of other lower level objects Representations of real-world things the system needs to know something about 19 Using Class Stereotypes It can also help thinking in terms of some common stereotypes of objects to get ideas Some candidate stereotypes include: Entity classes, also called model or business classes, are extracted directly from the statement of the problem. Boundary (or Interface) classes are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. Controller classes manage a “unit of work” [UML03] from start to finish. 20 Using Class Stereotypes II More candidate stereotypes include: Coordinator classes synchronize work of various other classes. Information holder classes are method-less classes that hold data (database type applications have these). Service Provider classes tend to calculate, compute and figure data. Structurer classes tend to sort and organize objects into meaningful order. 21 A Simpler Set of Stereotypes Report Classes: •Printed •Electronic Interface Classes: •Screens •Menus Actor Classes: •People •Organizations Business Classes: •Places •Things •Concepts •Events 22 Another Search Strategy for Objects 1. Look for anything that interacts with the system or is a part of the system 2. Ask if there is a customer if there is then they are an object 3. Follow the money The source of money is usually a customer (See 2) and the things or services that the money procures are good candidate 23 Another Search Strategy for Objects II 4. A Report is an object Any report generated by a system is a good candidate object Reports request information from other objects (collaboration) 5. A User display screen is an object 24 Additional Sources of Possible Objects and Classes External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system. Things (e.g, reports, displays, letters, signals) that are part of the information domain for the problem. Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation. Roles (e.g., manager, engineer, salesperson) played by people who interact with the system. 25 Additional Sources of Possible Objects and Classes II Organizational units (e.g., division, group, team) that are relevant to an application. Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system. Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects. 26 Introdu
cing the CRC Card CRC stands for: Class, Responsibility and Collaborators Class: An object is a person, place, thing, event, or concept Responsibility: Anything that a class knows or does Collaborator: A class that another class needs to accomplish its purpose In general, a collaboration implies either a request for information or a request for some action. 27 Introducing the CRC Card II The CRC card is a flexible and informal tool that can help the above process The text tends to use them later but I find they help bridge the magic gap from Use Cases to candidate classes The resulting set of cards are your Class Model 28 Elements of CRC Modeling While it seems a little silly, the use of actual cards helps to emphasize the essence of objectoriented modeling Identifies the definition of the responsibilities of the objects Clearly shows that everything that is happening in the system is happening as a result of the actions of an object in the 29 Elements of CRC Modeling II Note the focus of CRC modeling is on the behavior of the objects and not the specific structure of the objects The attributes will be clearly defined and reflected in the “know responsibilities” of the objects to know certain things as defined in the CRC cards. The methods will be reflected in the “does responsibilities” that we identify in the CRC card 30 Book’s Structure of CRC Card Front of Card: Candidate Name: Purpose/Definition: Stereotypes: Can do all on 1 side but this way allows us to focus on the name and purpose and then address the harder issues of responsibilities and collaborators. 31 Book’s Structure of CRC Card II Back of Card: Responsibilities: Collaborators: Candidate Name: 32 More Common Structure of CRC Card This is often (and originally) used as the CRC I prefer it since it is simpler and focuses on the main info Front of Card: Back of Card: 33 Responsibilities System intelligence should be distributed across classes to best address the needs of the problem (avoid central controller class) Each responsibility should be stated as generally as possible Information and the behavior related to it should reside within the same class (good encapsulation) Information about one thing should be localized within a single class, not distributed across multiple classes. Responsibilities should be shared among related classes, when appropriate. 34 Collaborations Classes fulfill their responsibilities in one of two ways: 1. A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or 2. A class can collaborate with other classes. Collaborations identify relationships between classes Collaborations are identified by determining whether a class can fulfill each responsibility itself 35 Collaborations II Three different generic relationships between classes [WIR90]: the is-part-of relationship the has-knowledge-of relationship the depends-upon relationship 36 How Do We Define the RC Part of the CRC Now ? The specific sequence of responsibilities of the objects and their required collaborations can only be seen thru how the system accomplishes its goals Recall Use Cases were used to identify key actors, their goals, and the steps they and the system followed to meet these goals Therefore the Use Cases we developed will be an excellent source of information for defining the Responsibilities and Collaborators 37 Recipe for Generating CRC Cards 1. Gather up any other requirements information we may know E.g. Product Vision Statements, Use Cases, etc. 2. Brainstorm on all the possible classes in the system Use the ideas defined earlier for possible sources of class/objects 3. Filter this list Combine related classes, delete redundant ones Develop a good 1 sentence description of each class Now fill in the Name field and the Description fields on the CRCS 38 Recipe for Generating CRC Cards II 4. Walk thru the scenarios Scenarios define the functions of the system Recall the Use Cases also defined functions that the actors on the Use Case perform Organize your Use Cases into thematic groupings Start with the simplest Use Cases and work to the more complex As each action on the Use Case is performed, it corresponds to a responsibility and is assigned to a particular CRC Write the responsibility down on the card 39 Recipe for Generating CRC Cards II-II 4. Walk thru the scenarios (continued) At each action also identify any collaborators the class needs to accomplish the task and write them on the CRC Don’t forget to have that collaborating CRC write its responsibility down when it is identified at the same time 40 Recipe for Generating CRC Cards III 5. Group the Cards Once the scenario modeling is complete group the cards on a table The proximity is defined by how much they collaborate Two highly collaborating cards are placed close together Also possible hierarchies (sub-classes) are grouped together This grouping by collaboration can help to begin to identify subsystems within the primary system. 41 Recipe for Generating CRC Cards III-II 5. Group the Cards (continued) One possible extra step is to develop a Collaboration Drawing Tape all the CRC cards to a white/black board Draw lines of collaboration between the cards Hopefully this drawing will also show some clustering of the paths of collaboration within the system 42 Collaboration Drawing 43 Some Comments on the CRC Process This is a very dynamic session. The designers are each assigned some set of CRCs and they ‘become’ the object in the scenario To keep it moving and animated: Handle the normal scenarios first Once a model to handle these is done then go back and see how it fits (and modify it) for the exception cases in the Use Cases If there are two ways to do something and you cant decide then just choose one and try it (it is easy enough to redo the cards another way) 44 Some Comments on the CRC Process II To keep from getting lost always have the person holding the card that is in action to hold it in the air Provides good visual cue as to where the action is Feel free to add a class whenever it appears one is missing to accomplish some needed collaboration 45 Recap of the Recipe for Generating CRC Cards 1. Gather up any other requirements information we may know 2. Brainstorm on all the possible classes in the system 3. Filter this list for duplicates and write descriptions 4. Walk thru the Use Case scenarios (normal scenarios first) 5. Group the Cards (maybe use Collaboration Drawing) 46 In-Class Breakout Session For Our Student Loan System try to identify 5 classes and state where they come from… Then draw up a CRC card for each of them We will have a couple groups present their drawings 47 For Next Class Finish Class Diagrams (aggregations and compositions) Continue reading Chapter 6 Start reading Chapter 7 (only State Diagrams and Sequence Charts sections) Read Harel paper

Student Course Registration System Problem You have been tasked with developing the software for an automated student registration system for use at universities to serve like an SIS system that you use only hopefully better. The system is fully web-based and supports the students with all the tasks for registering for classes. There are four key users of the system: (i) the registrar who manages the overall registration process, sets dates, enters courses, etc,, (ii) the students who can browse for courses, add and drop etc., (iii) the academic department secretaries who submit courses to be offered each semester, assign faculty, classrooms, times, etc. and the cashiers office that makes sure all bills are up to date. These initial course offerings are approved by the registrar. The features (functionality) of the system include: 1. fully web-based access for all types of users 2. Interfaces to: a. The course catalog which defines all possible courses that can be offered as well as the required course set for each degree. b. The course schedule for each semester that defines the actual courses offered for each semester, the faculty assigned, and the classrooms and days of the week and times. c. The transcripts database for all students that has their list of courses they have taken d. the cashiers database that holds all the student financial information. 3. screens for the registrar to approve course offerings and perform graduation audits 4. screens for students to access system for browsing courses, checking degree requirements, performing self-audits, adding and dropping classes and registering for each semester. 5. screens for cashier to insert holds when accounts are behind and also remove these holds 6. screens for the department secretaries to add courses to be offered each semester, and to change degree requirements for programs. Also screens to check student progress versus the requirements. 7. A tuition calculator that takes all the student’s courses and their status and computes the tuition due.