Software Engineering Zhang Shuang

Objects  First refinement  Product is designed in terms of abstract data types  Variables (“objects”) are instantiations of abstract data types  Second refinement  Class: abstract data type that supports inheritance  Objects are instantiations of classes Zhang Shuang,

Inheritance  Define H umanBeing to be a class  A humanBeing has attributes, such as age, height, gender  Assign values to attributes when describing object  Define Parent to be a subclass of HumanBeing  A Parent has all attributes of a HumanBeing, plus attributes of his/her own (name of oldest child, number of children)  A Parent inherits all attributes of humanBeing  The property of inheritance is an essential feature of object- oriented languages such as Smalltalk, C++, Ada 95, Java (but not C, FORTRAN) Zhang Shuang,

Inheritance (contd)  UML notation  Inheritance is represented by a large open triangle

Java Implementation

Aggregation

Composition Zhang Shuang,

Association Zhang Shuang,

2. Class Modeling  What is a class diagram?  A class diagram shows the existence of classes and their relationships in the logical design of a system. A class diagram may represent all or part of the class structure of a system.  Class diagrams show the static structure of the model, in particular, the things that exist such as classes, their internal structure, and their relationships to other classes.  It is the static view of a system, primarily supports the functional requirements of a system. Zhang Shuang,

2. Class Modeling  Class Diagram Usage  When modeling the static view of a system, class diagrams are typically used in one three ways, to model: The vocabulary of a system Collaborations A logical database schema Zhang Shuang,

Class Modeling  Extract classes and their attributes  Represent them using an entity-relationship-like diagram  Deduce the classes from use cases and their scenarios  Often there are many scenarios  Possible danger: too many candidate classes Zhang Shuang,

Two Approaches to Class Modeling  Noun extraction  Always works  CRC cards, Class-Responsibility-Collaboration  Need to have domain expertise  For testing class diagram Zhang Shuang,

Noun Extraction  Stage 1. Concise Problem Definition  Define product briefly and concisely. Buttons in elevators and on the floors control the motion of n elevators in a building with m floors. Zhang Shuang,

Noun Extraction (contd)  Stage 2. Informal Strategy  Incorporate constraints, express result in a single paragraph Buttons in elevators and on the floors control movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Zhang Shuang,

Noun Extraction (contd)  Stage 3. Formalize the Strategy  Identify nouns in informal strategy. Use nouns as candidate classes.  Nouns  button, elevator, floor, movement, building, illumination, door Zhang Shuang,

Noun Extraction (contd)  movement, illumination are abstract nouns — exclude (may become attributes)  floor, building, door are outside problem boundary — exclude  Candidate classes: Elevator and Button  Subclasses: Elevator Button and Floor Button Zhang Shuang,

First Iteration of Class Diagram Problem  Buttons do not communicate directly with elevators  We need an additional class: Elevator Controller

Second Iteration of Class Diagram  All relationships are now 1-to-n  Makes design and implementation easier

Class Design Considerations Multiplicity  Every class engaged in a relationship should have a multiplicity.  If the multiplicity is 1, indicate that it is 1; in order that reader know that multiplicity has been considered.  UML multiplicity indicator UML multiplicity indicator Zhang Shuang,

Exercise 1 Assembly Line Control System Assembly Line Control System Use the technique of noun extraction to identify the possible classes in the following use case scenario for a software system that controls an assembly line: The sensor sends a STOP message to the control software if a widget reaches the end of the conveyor belt without being lifted by the robot arm. The software sends a signal to the motor controller to stop the assembly line. Which of the candidate classes should not be added to the preliminary class list? Refer explicitly to the refinement principle you used in each case. Zhang Shuang,

Exercise 1 Assembly Line Control System  The possible classes :  sensor  control software  widget  motor controller  assembly line  Class diagram Class diagram Zhang Shuang,

Exercise 2  OOA: get class diagram for University System. Zhang Shuang,

Exercise 3  OOA: get class diagram for Bank System. A bank system has customers who open account. A customer can hold accounts in a bank. He can deposit funds to accounts, can withdraw funds from accounts, and can also transfer funds from an account to another. A customer can check balance of his own accounts, and transaction records including depositing, withdrawing and transferring. The customer has rights to close his own account. Zhang Shuang,

Exercise 4  OOA: get class diagram for on-line musical instrument shop. Zhang Shuang,

2. Class Modeling  Is there a better way to organize class diagrams? Zhang Shuang,

2. Class Modeling  Package?  A general purpose mechanism for organizing elements into groups.  A model element that can contain other model elements.  Rules:  Classes with aggregation or composition belong to the same package  Classes with a lot of association belong to the same package Zhang Shuang,

2. Class Modeling  Package can include other packages.  e.g. : Java class library  Class File is in package io,  Package io is in package java.  The full name of File is java.io.File  Avoid too deep nested package  Normally 2~3 layers Zhang Shuang,

2. Class Modeling Zhang Shuang,

CRC Cards  CRC Class-Responsibility-Collaboration Zhang Shuang,

CRC Cards  Used since 1989 for OOA  For each class, fill in card showing  Name of class  Functionality (responsibility)  List of classes it invokes (collaboration)  Now automated (CASE tool component)  Strength  When acted out by team members, powerful tool for highlighting missing or incorrect items  Weakness  Domain expertise is needed