Software Engineering I Oct. 11, 2013 Last time we covered Associations (UML) More on generalizations and associations We can have labels for our generalization set +--------+ | Animal | +--------+ ^ ^ habitat / \ / \ diet --- --- | | +--------------------+ +------------------+ | | | | +-------------+ +-----------+ +----------+ +-----------+ | WaterAnimal | |Land Animal| |Herbivore | | Carnivore | +-------------+ +-----------+ +----------+ +-----------+ ^ ^ ^ ^ ^ ^ ^ ^ / \ / \ / \ / \ / \ / \ / \ / \ --- --- --- --- --- --- --- --- | | | | | | | | +-+-----)-----------)------)--------+ | | | | | | +--------------)-------)------+ | +-----------)--+------------------)-------+ | | +--)------------------+ | | | | | +---+----------+ +--------------+ +-------------+ +-------------+ |WaterHerbivore| |WaterCarnivore| |LandHerbivore| |LandCarnivore| +--------------+ +--------------+ +-------------+ +-------------+ Can have multiple classes from which you can inherit but it is not supported by all languages. Example: Java allows for multiple implements statements (interfaces) but only allows for one extends (class) Can be hard to differentiate for the user and compiler. Object Diagrams Names are underlined Types are denoted after a colon Lines represent links and do not include multiplicities +-------------+ |Dave:Employee| |-------------|--------+ +-------------+ | | +-------------+ +------+--------------+ +----------------------+ |Jane:Employee| |UMLInc:Company|-----|Board:BoardOfDirectors| |-------------|---------------|--------------| +----------------------+ +-------------+ +-------+--------------+ | +-------------+ | |John:Employee|-------+ |-------------| +-------------+ Remember Associations describe relationships between instances of classes These exist at runtime Generalizations describe relationships that exist between classes in a class diagram (e.g. inheritance) Object diagrams don't contain generalizations only links from associations Aggregation represents a part-to-whole relationship +-------+ 1 * +-----------+ |Vehicle|/\________|VehiclePart| +-------+\/ +-----------+ +-------+ 1 * +-------------+ |Country|/\________|RegionOrState| +-------+\/ +-------------+ +--------+ ^ 1 * +----+ |Building|/*\________|Room| +--------+\*/ +----+ V When to use? When parts 'are part of' the aggregate and the aggregate is composed of parts When something or someone owns or controls the aggregate, they also own or control the parts. Compositions +--------+ ^ 1 * +-------+ |Employee|/*\________|Address| +--------+\*/ +-------+ V |street | |city | |zip | +-------+ A composition is a strong kind of aggregation in which the parts are destroyed when the object is destroyed. A filled diamond indicates a composition. Use compositions when the aggregate 'is composed of' the parts. Aggregation Hierarchy Notice that we may have an aggregation hierarchy. This includes parts that are made up of other parts and is different from inheritance. +---------+ | Vehicle | +---------+ ^ / \ \ / V | 1 | +--+--------------+-------------------------+ | 1 | * | * +---------+ +---------------+ +-----------+ | Chassis | | ExteriorPanel | | Door | +---------+ +---------------+ +-----------+ ^ / \ \ / V | 1 | +--+-----------+------------+--------------+ | | | | | 1 | 1..* | 1..* | * +-------+ +--------+ +--------------+ +-------+ | Frame | | Engine | | Transmission | | Wheel | +-------+ +--------+ +--------------+ +-------+ Operations may be propogated down the aggregation hierarchy Note that it is ok to leave out a diamond, but it is not ok to put a diamond (aggregation) in a design when it is not necessary. That is, a relationship using only a line may be used in place of a stronger relationship, but a stronger relationship should _never_ be used in place of a weaker one. Object Constraint Lanaguage (OCL) - Used to specify constraints in UML and navigation paths - OCL is a specification language - Allows us to specify facts (true statements) about a system - Code must adhere to those aspects OCL statements utilize the following operators and literals boolean values - true / false logical operators - and, or, =, >, <, <> (not equal) strings - 'a string' math operators - +, -, *, / constraints contained within curly brackets { x = 1 } Kinds of expressions are denoted with _stereotypes_ in UML The four following stereotypes are keywords in OCL context - what we are talking about invariant - always true precondition - true before starting an operation postcondition - true after completing an operation Stereotypes are denoted by pairs of double angle brackets << >> Ex: <> <> See http://www.omg.org/spec/UML/ for the UML specification See http://www.omg.org/spec/OCL/ for the OCL specification Developing Class Diagrams Create at different steps of the design process Exploratory Domain Model Include information from domain - informally during domain analysis - Referred to as _exploratory_domain_model_ - May include class names and attributes During requirements analysis (System Domain Model) - Develop a model including the domain classes - Include associations and attributes - Referred to as _system_domain_model_ - Includes real software modules, DB information - Might omit classes need to build the entire system System model - Includes system domain model - UI classes including windows, menus, and forms - Classes representing the system architecture + Clients, servers, files, DBs - Utility classes We can identify this whole system model in UML +------+ | | +------+-----------------------+ | +---+ | | +---+--------+ | | |Domain Model| | | +---+ +------------+ | | +---+---------+ | | | Client | +--+ | | | thin system | +--+-------+| | +-------------+ | Graphical|| | | Model || | +----------+| +------------------------------+ Suggested flow of Class Analysis 1. Identify possible classes 2. Add associations and attributes 3. Determine generalizations 4. List responsibilities or operations of each class 5. Iterate over this process and decide the following a. Should classed be removed or added b. Determine if a design pattern is needed c. Determine if other tools are needed d. Repeat as necessary Identify classes by discovery and/or invention, removing redundancy - make classes reusable - specify associations and attributes Ex: +----------+ +--------+ +---------+ | Person | --> | Person | 1 * | Address | +----------+ +--------+-------------+---------+ | name | | name | addresses| | | street1 | +--------+ | | | state1 | +---------+ | zip1 | | street2 | | state2 | | zip2 | +----------+ Classes should have definite responsibilities - setting/getting - creating/initializing - loading/saving/destroying - adding/deleting associations - copying/converting/transferring/transmitting/outputting - computation - navigating/searching - etc.