Concordia TAV 2002 Comp5421_61 Comp5421 Object Oriented Programming Design Notation Lecture 6 Tianxiang Shen Summer 2002 Department of Computer Science

Concordia TAV 2002 Comp5421_6 1

Comp5421 Object Oriented Programming

Design Notation

Lecture 6 Tianxiang ShenSummer 2002

Department of Computer Science Concordia University


Design Notation: UML• If a system is simple enough we can fit all the pieces together

mentally before we can start coding.

Complex project needs several people to develop. It is important to have standard design notation with fixed meaning that everyone can understand and agree to.

• The Unified Modeling Language™ (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, making a "blueprint" for construction.

Note: 1. Model: Abstract of a physical system with a certain purpose. It is used for the different stages in the development of a system. 2. Design is a modeling process

3. Software design is process of constructing conceptual models. 4. Designer uses UML to communicate their conceptual models to others designers, clients, and developers.


Computer System

Business Process

Order

Item

Ship via

“Modeling captures essential parts of the system.”

Dr. James Rumbaugh

Visual Modeling is modelingusing standard graphical notations

What is Visual Modeling?


Use Case Analysis is a technique to capture business process from user’s perspective

Visual Modeling Captures Business Process


Visual Modeling is a Communication Tool

Use visual modeling to capture business objects and logic

Use visual modeling to analyze and design your application


User Interface(Visual Basic,

Java)Business Logic

(C++, Java)

Database Server(C++ & SQL)

Model your systemindependent of

implementation language

Visual Modeling Defines Software Architecture


Multiple Systems

Visual Modeling Promotes Reuse

ReusableComponents


Design Notation: UML (cont.) Comments for UML

• A diagramming notation should be simple and precise. UML is quite complex: the "Notation Summary " occupies 60 pages and describes numerous symbols, keywords, and fonts. This is partly due to the origins of UMI as a "union" of three separate notations.

• Because of its complexity, it is hard to use UML in a casual way.

• Also because of its complexity. It is impractical to use UML as a handwritten notation. To use it effectively we need software tools.

• Much of UML is defined rather vaguely.• No single notation will be effective for all applications, although

UML claims to be a universal notation good for all systems.• Most of the enthusiasm about UML, comes from top management.

Actual designers are often less enthusiastic about its capabilities


UML Model Consist of:

(1) Basic Modeling Elements (Things):

1. Structural Elements: type, class, instance, collaboration, use case, components, and nodes.

2. Behavioral Elements: interaction and state.

3. Grouping Elements: package, subsystem.

(2) Relationships:

1. Dependencies: One element may affect another

2. Associations: connection (bi-direction);

Aggregations (whole and its part);

3. Generalizations: parent/child or general/specific;

4. Realizations: interface and its implementation


UML Model Consist of: (3) Diagrams group interesting collections of elements.

1. Class Diagrams show the existence of classes and their relationships in the logical view of a system

2. Object Diagrams show sets of related object.3. Use case Diagram show scenario of a system4. Sequence Diagrams show how massages between related objects are ordered in time.5. Collaboration Diagram show how messages between related objects are structured independently of time.6. Statechart diagrams show machines with states, transition events and activities.7. Activity Diagrams are statechart diagram that show system functionality and control flow.8. Component diagrams show the static relationships between components of a system9. Deployment diagram show the configuration of run-time nodes.


Static Structure Diagram

• Static Structure Diagram has two principal components. They are classes and relationships.

• Classes provide the set of classes and direct information about each class.

• Relationships provide the other information, including the class hierarchy and how the various classes are related structurally.


Class Diagrams• UML represents a class as a rectangular box with three fields:

name, attributes(data members), and methods• Fields are separated by horizontal lines; the name field is

required and the other fields may be omitted.• UML uses Ada/Pascal syntax (name colon type) rather than C+

+ syntax (type name), so its confusing. Fortunately the UML tools accept fairly arbitrary syntax.

•


Class Diagrams (cont.)

• Classes can be adorned in various ways. Example: the name of a feature can be preceded by "+“ (public), "#' (protected), or “-” (private) to represent its accessibility.

• Software tools provide the following icons that are more mnemonic than these symbols: A plain icon indicates public, an icon with a lock indicates private, an icon with a key indicates protected).

Person

# name: string

# Sex: int

# dob: Date

BankAccount: int

+ Person()

+ setDob(int, int, int)

+ getDob() : Date


Hungarian Notation • Hungarian prefixes: indicate variable’s data type and scope• 1. Hungarian variable names start with lower case letters that identify type of the

variable, followed by a descriptive name that uses an upper case letter at beginning. • 2. For example, variable lpszMessage contains a long p to a string terminated with a

zero byte (null). ar arrayb booleanby unsigned char or bytec characterC classcx, cy integer used as length (''count'') in X or Y directiond doublef flag (equivalent to boolean)fn functionh handle (for Windows programming)i integer (usually 32 bits)l long integerm_ class member variablen short integer (usually 16 bits)p pointers stringsz string with null-terminateds_ static class member variablew word (unsigned short integer)dw double word (unsigned long integer)x, y integer coordinate


Relationship: Dependencies

• Dependency relationship describes relationships between elements in which one element may affect the semantics of another element.

• Class A depends on class B if A needs B (i.e. A cannot complete its tasks without B)

• Dashed line from A to B indicates their dependency relationship.

• The most common usage of a dependency is to show that the signature of one class’s operation uses another class.

• Example: 1.

• Example 2. System and Form classes: System class has operation displayForm(f:Form). The form the system displays depends on the which Form the user selects

Window (A)

Open()

handleEvent()

Event (B)


Relationship: Generalization

• Generalization relationship describes parent/child or general/specific relationship

• A solid line with an open triangle from child to parent indicates the relationship

• Example:


Relationship: Realization

• Realization relationship describes relationship between a specification and its implementations, i.e. relationship between classifiers(a classifier defines a contract that another classifier carries out)

• A dashed line with an open triangle from implementation to specification.


• Association is a bi-direction connection between classes. Such as:

1. Player Plays on Team, and Team employs player.

2. person and company (serve)

3. professor and course (teach)

4. Person and financial institution (ask for loan)

5. Person and House (own)

Relationship: Association



• Association relationship is drawn as a solid line connecting classes.

• Name of an association:1. Describe the nature of relationship2. Can include direction of the relationship

• Example:Person class and Company class;



• Roles of an association:

1. Role name identifies the role that each class plays in the relationship

2. Same class can play different roles in different contexts

• Defining multiplicity in association:

Show how many objects of the same type are involved in the association (1:1, 1:n, m:n, etc)



• Navigability: An arrowhead on the end of the path showing navigability in that direction. If neither end has an arrowhead, the assumption is that the association is navigable in both directions.

• RegistrationManager class include a member function:

addStudent(Course, StudentInfo);

Course class include data name, and numberCredit.

• Relationships are discovered by examining interaction diagrams– If two objects must “talk” there must be a pathway for

communication

Registration Manager

Math 101: Course

3: add student(joe)

RegistrationManager

Course


Relationship: Aggregation

• Aggregation is an relationship where one class is part of the other. Such as triangle and side (contain).

• It is drawn as a solid line with a diamond on the whole side of the relationship


Static Structure Diagram Example (p138)


Class Diagrams• It is feasible to include different kinds of relationships in a single

diagram.

• Complex systems keep all dependencies and associations in one diagram, and inheritance into another.

• Class diagrams are static: they do not show how the system evolves with time. Some of the other kind of diagram can show the dynamic behavior of the system.

• A message-trace diagram shows how objects interact by passing messages to one another ("passing messages" is just OO jargon for "calling functions"). The horizontal axis shows the different objects involved and the vertical axis corresponds to time, moving down the page. (detail is covered at “Software Engineering” course)


Assessment of Diagrams

• Static diagrams:

1. Provide an overview of the system;

2. Can reveal problems such as high coupling;

3. Work best with less than 12 classes in a diagram.

If system with more than 12 classes must be described by multiple diagrams.

• Message trace diagrams involve only a small number of objects. Complex systems need many other diagrams.

• A major problem with design diagrams is that, after changes, they do not correspond to the software. What should happen:

1. developer discovers a design error;

2. design error is corrected, redraw all affected diagrams;

3. developer modifies code according to revised design.


Assessment of Diagrams (cont.)

• What usually happens in practice is that the code is altered, the design diagrams become out of step with the code, and are eventually discarded.

• Rational uses the term round-trip engineering to describe a process whereby code can be generated automatically from design diagrams and, later, design diagrams can be "reverse engineered" from code.

The technique depends on the fact that the code was generated by software tools; it cannot be applied to arbitrary code.


Assessment of Diagrams (cont.)

• A problem with UML (and similar notations) is that there is a significant translation step from diagrams to code. UML designs cannot be executed, tested, or verified. It is possible (and advisable) to “walk through” UML designs.• Unified Modeling Language (UML) Documen

tation

• http://www.rational.com/uml/

http://www.rational.com/uml/

http://www.rational.com/uml/

Documents

Concordia TAV 2002 Comp5421_61 Comp5421 Object Oriented Programming Design Notation Lecture 6 Tianxiang Shen Summer 2002 Department of Computer Science