Software EngineeringITCS 3155Fall 2008

Dr. Jamie PaytonDepartment of Computer ScienceUniversity of North Carolina at Charlotte

Nov. 13, 2008

Lecture 20Detailed Design

22

Lecture Overview

TodayChapter 11

Detailed design• Static class models

Chapter 11: Detailed Design

We have done the Software Architecture Document.

That was high level. Now we need to get down to a more detailed level…

3

4

Context of Detailed Design

Boundary between architectural and detailed design is not clearly demarcated

Detail of architecture design depends on size, complexity of program

Boundary between detailed design and implementation also blurry

No reason for strict boundariesArchitecture, detailed design, implementation activities are intertwinedOnly separate logically to emphasize:• Top-down design approach• Importance of abstraction

5

Detailed Design

Fills in details of software architecture componentsCovers range of levels of abstraction

Highest is at architectural level• DeSCIPTR applied to major subsystems

Lowest is more like implementation detail• Pseudocode, data formats

Detailed design representationsStatic models (time not considered)Dynamic models (accounts for the element of time)

Bulk of design specification is developed during this stage of design…

6

Detailed Design Stages

Mid-level designSpecifying software at level of medium-size components• Compilation units or classTheir propertiesTheir relationshipsTheir interactions Essentially:• DeSCRIPTR• Design patterns (later)

Low-level designActivity of filling in small details at lowest level of abstractionPAID (Packaging, Algorithms, Implementation, Data Structures)

7

Detailed Design Process

InputSRSSAD

OutputDesign document• SAD• Detailed design document

(DDD)

Detailed Design ProcessSRS, SAD : ProblemDesign Document : Solution

DesignDocument

SRS

[adequate detailed design]

Analyze SRSand SAD

Generate/Improve DetailedDesign Alternatives

Evaluate DetailedDesign Alternatives

[else]

Select DetailedDesign

Finalize Design

SAD

8

Detailed Design Document

A design document consists of a SAD (Chapter 9) and a detailed design document (DDD)

1. Mid-Level Design Models2. Low-Level Design Models3. Mapping Between Models4. Detailed Design Rationale5. Glossary

We’ll talk about how to generate modelsFirst, we’ll talk about what kind of models and how to use notation

One possible DDD template

9

Mid-Level Generation Techniques

Creational—Make a mid-level design class model from scratch

Functional decompositionQuality attribute decompositionDesign themes

Transformational—Change another model into a mid-level design class model

Similar systemPatterns or architecturesAnalysis model

10

Mid-level Design with UML Class Diagrams

ConceptsGeneralizationAbstract and concrete operations and classesInterfacesFeature visibilityClass and instance variables and operationsAggregation and compositionAssociation classes and qualifiersOther association adornmentsClass diagram heuristics

11

Generalization and Inheritance

InheritanceSubclass inherits all attributes, operations from superclass• Parent/child relationship

UML generalization is a more general notionApplies to other entities beyond classesAllows for multiple inheritanceShows static relationship between classes• Associations show relationships between instances

Generalization between classes is “inheritance”. This is our focus.

12

UML Generalization

Also known as the “is-a” associationExample: cards

Cards have many properties in commonPlace common properties in separate class, Card• Called “base class” or “parent class”

All cards inherit from Card base class• Any card is-a card and has all its features and more

13

Generalization Example: Card Card

height: integerwidth: integer

thickness: double ID-number: integer

expiration: Date

issue(d: Date)revoke()

DriversLicense

class: Vehicleissued: Date

expire()

IDCard

workgroup: String

expire()

CreditCard

limit: integerissued: Date

increaseLimit()

14

Generalization Example 2: Animals

Mammal

PumaTiger

Feline

Quadruped

Lion

Lizard

15

Abstract Classes

Abstract operationOperation has signature…but no implementation

Concrete operationHas an implementation

Abstract classCannot be instantiatedAny class with one abstraction operation is abstract class

Concrete classAll operations are implemented

16

Use of Abstract Classes

Abstract classes are used in conjunction with generalization (inheritance)

Abstract superclass is specialized by concrete subclass• Concrete class implements abstract operations

Represented in UMLItalicized class name, or<<abstract>> stereotype

17

Abstract Class Examples

Circle ScreenRenderer Book

Document{ abstract }

callNumberdescriptors : String[*]render()

Renderer«abstract»

Shape

areaOf() : float { abstract }

18

Interfaces

A UML interface is named collection of public attributes and abstract operations

Provided interfaces—realized by a class or component and represented by• A ball (lollipop) symbol or• A stereotyped class icon with a realization connector

Required interfaces—needed by a class or component and represented by• A socket symbol or• A dependency arrow to a ball symbol or• A dependency arrow to a stereotyped class icon

19

Interface Example

TimerObserver

Observer

TimerObserver

«interface»Observer

update( arg : Object )

20

Required Interface Notations

Observer

TimerObserver

«interface»Observer

update( arg : Object )

TimerTimer

Observer

Timer

21

Module Assembly Notations

22

UML Feature Visibility

PublicVisible anywhere that the class in which it appears is visible; denoted by +

PackageVisible anywhere in the package containing the class in which it appears; denoted by ~

ProtectedVisible in the class in which it appears and all its sub-classes; denoted by #

PrivateVisible only in the class in which it appears; denoted by -

23

Feature Visibility Example

Alarm

+ identifier : String {constant}# location : String# description : String- classification : Classifier

+ getLocation() : String+ getDescription() : String+ action()~ setClassification( c : Classifier)~ getClassification() : Classifier# basicAction()

FireAlarm IntrusionAlarm FloodAlarm

24

Class and Instance Variables and Operations

An instance variable is an attribute whose value is stored by each instance of a classA class variable is an attribute whose value is stored only once and shared by all instancesAn instance operation must be called through an instanceA class operation may be called through the class

In UML class variables and operations are called static

Indicated by underlining an attribute’s or operation’s specification

25

Attribute and Operation Specification Examples

26

Summary

Overview of detailed designUML class diagram concepts for static modeling in detailed design