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

Design Engineering  A systematical way to “translate” SRS into design Start with use cases from SRS  Find analysis classes from use cases  Create CRC cards from use cases  Refine CRC cards into UML class diagrams  Different types of classes  Architecture Design  Interface Design  Component Design  Detailed/Data Design  2 Drexel University

From Use Cases to Class diagrams  Step 1: Identify and assign candidate classes  Step 2: Determine a set of specific scenarios  Step 3: Walk through the scenario, naming cards and responsibilities 3 Drexel University

Step 1: Identify and assign candidate classes  Read requirements specification.  Highlight nouns and noun phrases to give candidate classes (excluding abstract nouns).  Write each candidate class down on an index card.  Assign each index card to one person who is participating in the CRC card modelling session. Drexel University

Step 1: Identify and assign candidate classes  Consists of classes of domain objects.  Example: any ATM model will involve Card, BankAccount classes  Names are important.  Class identification is a key process for a good class model:  noun identification;  responsibility driven approach. 5 Drexel University

Noun identification  Two stages:  identify candidate classes by picking all nouns and noun phrases out of requirements specification document;  discard inappropriate candidates.  A candidate is an inappropriate class when it is  redundant (ex: book, book in many volumes; member of the library,library member)  vague (item it may be either book or journal etc)  an event or an operation (a loan – an event: lending a book)  meta-language element: used to describe and explain requirements and the system at a very high level (system, rule, information, or reporting requirements)  outside the scope of the system (time)  an attribute (name)  Nouns are outlined 6 Drexel University

An ATM Example  See Class Exercise 7 Drexel University

ATM –All Nouns 8 Drexel University

ATM- Classes  Class candidates:  card  bank account  (ATM) dispenser &  session – vague (it might become of interest)  Data associated  PIN - attribute of card  current balance - attribute of bank account  amount – attribute in various classes  overdraft limit – attribute of bank account  card limit per day – attribute of card  dispenser amount – attribute of ATM dispenser 9 Drexel University

ATM Example: 10 Drexel University

More ATM CRC Cards 11 Drexel University

ATM –Card Class Card class’ attributes and operations; validatePIN() validates the PIN introduced against the value in pin; changePIN() changes the current pin value with what this operation provides; startWithdraw() initiates the withdrawal by i) checking that the amount requested is within dayLimit range; ii) checks with BankAccount that there is enough in the current bank account or the overdraft limit is sufficient for this transaction; iii) it also checks that there is enough cash in dispenser; if all these are fulfilled it asks BankAccount to update the balance and Dispenser to release the cash. 12 Drexel University

ATM –BankAccount Class 13 Drexel University

ATM –Dispenser class 14 Drexel University

ATM Transaction Class 15 Drexel University

ATM additional requirements  Let’s consider that transactions involving cash withdrawal, either failed or successful, are recorded. In this case  session (retained as vague) will be reconsidered and Transaction is the class that will be identified for session.  Reconsider CRC cards: when Card class will initiate cash withdrawal then another collaboration will be added, i.e. Transaction class will record this transaction.  A new CRC card will be then generated for Transaction class. 16 Drexel University

CRC Cards Relationship 17 Drexel University

ATM –Class Diagram  Class diagrams is obtained directly from CRC cards by considering collaborations identified; it shows business classes.  Classes are shown with no attributes and operations. 18 Drexel University

ATM-Refined Class Diagram  For each Card there is one bank account, one dispenser and an arbitrary number of transactions.  Each BankAccount should have one or more cards associated with.  The Dispenser refers to all cards.  Each Transaction has a unique card on it.  All associations are named, directed and unidirectional. 19 Drexel University

Different types of analysis classes  Entity Class  Data Structures: e.g. Card,  Process Class  Classes that work: Transactions  Boundary Class  Interface with external systems: Dispenser 20 Drexel University