CS 451 Software Engineering Yuanfang Cai Room 104, University - PowerPoint PPT Presentation

CS 451 Software Engineering Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu 1 Drexel University

Elaboration 2 Drexel University

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 Drexel University

Domain Analysis Sources of domain knowledge  Technical literature  Existing application  Customer surveys  Expert advice  Current/future requirements  4 Drexel University

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 Drexel University

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 Drexel University

Analysis Modeling Approaches 7 Drexel University

Analysis Modeling 8 Drexel University

9 Drexel University

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 Drexel University

Scenario-based Modeling Write Use-Cases  Develop an Activity Diagram  11 Drexel University

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 Drexel University

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 Drexel University

Class based modeling  Class diagram  Entities  Attributes  Behaviors 14 Drexel University

Elaborating Use Cases  Each usage scenario implies a set of “objects” that are manipulated as an actor interacts with them 15 Drexel University

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 Drexel University

Class-Based Modeling  Class diagram for the system class 17 Drexel University

Class Diagram Drexel University

Class nam e 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. Drexel University

Generalization Generalization relationships denote inheritance between  classes. The children classes inherit the attributes and operations of  the parent class. Indicated by a hollow arrow  Drexel University

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 Drexel University

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 Drexel University

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 Drexel University

Multiplicity Drexel University

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. Drexel University

Evaluating a Class/Class Diagram Intention-revealing naming: Does the name of the object 1. convey its abstractions? Does the abstraction have a natural meaning and use in the domain? Single Responsibility: Do the name, main responsibility 2. statement data and functions align? ?? Drexel University

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 Drexel University

Flow-Oriented Modeling  DFD for the SafeHome Security function 28 Drexel University

Flow-Oriented Modeling  Level 1 DFD for SafeHome Security Function 29 Drexel University

Flow-Oriented Modeling Level 2 DFD that refines the monitor sensors process  30 Drexel University

Behavioral Models  Sequence Diagram  How the entities interact with each other  For further design analysis  State Diagram  How a complex object behaves 31 Drexel University

UML Sequence Diagrams 32 Drexel University

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 Drexel University

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. Not all nouns become objects such as “turn”  Objects  Player  Dice  Cell  Property Drexel University

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  Dice Cell Property Player rollDice DiceValue(6) MoveCell(6) isOwnedProperty isOwnedProperty(False) 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 Drexel University

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” Dice Cell Property Player rollDice DiceValue(6) MoveCell(6) isOwnedProperty isOwnedProperty(False) Drexel University

• If the player lands on a cell that is an un- Conditional Logic owned 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 Cell Property Dice Owner rollDice DiceValue(n) MoveCells(n) [isOwnedProperty] isOwnedProperty(False) [else] isOwnedProperty(True,owner) PayOwner Drexel University

UML State Diagram 38 Drexel University

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. Drexel University