CS 451 Software Engineering Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu 1
Elaboration 2
Elaboration: Building the Analysis Model An analysis model provides a description of the required information, functional, and behavioral domains for a computer based system. An analysis model will change during the requirements gathering with some areas stable and others being volatile. There are many ways to represent the model. Software is not visualizable 3
Domain Analysis Sources of domain knowledge Technical literature Existing application Customer surveys Expert advice Current/future requirements 4
Analysis Modeling Goals Describe what the customer requires Establish a basis for the creation of a software design Define a set of requirements that can be validated once the software is built 5
Deeper understanding the requirements From SRS, e.g. use case scenarios: What are the entities in the system? Class diagrams Data-flow diagram How these entities interact with each other? Sequence diagram Activity diagram Swim lane diagram The behavior of a complex object State diagram 6
Analysis Modeling Approaches 7
Analysis Modeling 8
9
Scenario based modeling Use cases text Use case diagrams Activity diagram Visualizing the logic within a use case: scenarios Swim lane diagram Split activities among actors. 10
Scenario-based Modeling Write Use-Cases Develop an Activity Diagram 11
An Activity Diagram Similar to a flowchart: Round rectangles imply specific system functions Arrows represent flow through the system Diamonds depict a branching decision 12
Swim Lane Diagram Swim Lane Diagram Represents flow of activities indicating which actor has responsibility for the action. Responsibilities are represented as parallel segments that divide the diamond vertically, like the lanes in a swimming pool. 13
Class based modeling Class diagram Entities Attributes Behaviors 14
Elaborating Use Cases Each usage scenario implies a set of objects that are manipulated as an actor interacts with them 15
Elaborating Use Cases The behavior of a computer- based system can have a profound effect on the design that is chosen, therefore the analysis model must provide modeling elements that depict behavior: 16
Class-Based Modeling Class diagram for the system class 17
Class Diagram
Class name attributes operation s A class encapsulates state (attribute) and behavior (operations). Each attribute has a type. Each operation has a signature. The class name is the only mandatory information.
Generalization Generalization relationships denote inheritance between classes. The children classes inherit the attributes and operations of the parent class. Indicated by a hollow arrow
Association Indicated by a solid arrow line from the source class to the target class Can be bi-directional represented by lines without arrow heads Don t usually put the association down as an attribute in the class
Aggregation If the association conveys the information that one object is part of another object ( has-a ), but their lifetimes are independent (they could exist independently). Aggregation is stronger than association, unidirectional. There is a container and one or more contained objects. For example, we may say that a Department contains a set of Employees, or that a Faculty contains a set of Teachers. An aggregation relationship is indicated by placing a white diamond at the end of the association next to the aggregate class. 22
Composition Even stronger than aggregation is composition. There is composition when an object is contained in another object, and it can exist only as long as the container exists and it only exists for the benefit of the container. Examples of composition are the relationship Invoice-Invoice Line, and Drawing-Figure. A composition is shown by a black diamond on the end of association next to the composite class. An aggregation is a special form of association; composition is a stronger form of aggregation. Both aggregation and composition are a part-whole hierarchy. 23
Multiplicity
Candidate classes: Noun extraction Company XYZ has two types of customers, corporate customers and personal customers. All customers can place orders. Every order is placed by a customer.
Evaluating a Class/Class Diagram 1. Intention-revealing naming: Does the name of the object convey its abstractions? Does the abstraction have a natural meaning and use in the domain? 2. Single Responsibility: Do the name, main responsibility statement data and functions align???
Flow-Oriented Modeling Data Flow Diagrams show the input-process-output view of a system. DFD s are not part of UML, but a complement to UML. There is a natural tendency to show too much detail too soon. Start at a high level and work your way down one process at a time. 27
Flow-Oriented Modeling DFD for the SafeHome Security function 28
Flow-Oriented Modeling Level 1 DFD for SafeHome Security Function 29
Flow-Oriented Modeling Level 2 DFD that refines the monitor sensors process 30
Behavioral Models Sequence Diagram How the entities interact with each other For further design analysis State Diagram How a complex object behaves 31
UML Sequence Diagrams 32
UML Sequence Diagrams Used during requirements analysis To refine use case descriptions To find additional objects ( participating objects ) Used during system design to refine subsystem interfaces Performance analysis
A Sample Scenario A player rolls the dice and gets a 6. The player moves 6 cells. The player lands on a cell that is an un-owned property. The player s turn is over. Objects Player Dice Cell Property Not all nouns become objects such as turn
UML Sequence Diagrams Objects are represented by columns (first column is actor that initiates use case) Messages are represented by arrows Activations of an operation are represented by narrow rectangles Player Dice Cell Property rolldice DiceValue(6) MoveCell(6) isownedproperty(false) isownedproperty No significance to the horizontal orderings of the objects Return values are optionally indicated using a dashed arrow with a label indicating the return value Suggestion: not to indicate the return values when it is obvious what is being returned
Scenario A player rolls the dice and gets a 6. The player moves 6 cells. The player lands on a cell that is an un-owned property. The player s turn is over. Not all nouns become objects such as turn Player Dice Cell Property rolldice DiceValue(6) MoveCell(6) isownedproperty(false) isownedproperty
Conditional Logic If the player lands on a cell that is an unowned property, the player s turn is over. If the player lands on a cell that is owned, the player must pay rent to the owner of the property. Then, the player s turn is over. Player Dice Cell Property Owner rolldice DiceValue(n) MoveCells(n) [isownedproperty] isownedproperty(false) [else] isownedproperty(true,owner) PayOwner
UML State Diagram 38
State Diagram A state diagram (also called state machine diagram) depict the various states that an object may be in and the transitions between those states. Appropriate to be developed for complex objects. From UML Distilled (pp. 107-108): A lock in a haunted house: keep valuables in a safe that s hard to find To reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. In the Wait state, if the candle is removed providing the door is closed, you reveal the lock and move to the Lock state. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I re-place the candle first. If a thief neglects this precaution, I ll unleash a killer rabbit to him.
State Diagram From UML Distilled (pp. 107-108): A lock in a haunted house: keep valuables in a safe that s hard to find To reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. In the Wait state, if the candle is removed providing the door is closed, you reveal the lock and move to the Lock state. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I re-place the candle first. If a thief neglects this precaution, I ll unleash a killer rabbit to him.
States States are represented by the values of the attributes or data members of an object. Initial state state transition Terminal state
Transitions Transitions are the result of the invocation of a method that causes an important change in state. Each transition has a label that comes in three parts. All the parts are optional. trigger-signature [guard]/activity candle removed [door closed]/reveal lock The trigger-signature is usually a single event that triggers a potential change of state. Missing trigger-signature [rare] you take the transition immediately. The guard, if present, is a Boolean condition that must be true for the transition to be taken. Missing guard always take the transition. The activity is some behavior that s executed during the transition. Missing activity don t do anything during the transition.
activity: behavior that s executed during the transition trigger-signature: event that causes a potential change of state guard: Boolean condition that must be true for transition to happen
Rules for State Diagrams There is one initial state (can be multiple final states). Every state can be reached from the initial state. From each state, there must be a path to a final state. Every transition between states must be labeled with an event that will cause that transition. When an event occurs, you can take only one transition. If you have multiple transitions with the same event, the guards must be mutually exclusive. Transitions that are not shown are illegal OR show transitions that cause errors.