Concordia TAV 2002 Comp5421_61 Comp5421 Object Oriented Programming Design Notation Lecture 6...
-
Upload
lorin-knight -
Category
Documents
-
view
214 -
download
0
Transcript of Concordia TAV 2002 Comp5421_61 Comp5421 Object Oriented Programming Design Notation Lecture 6...
Concordia TAV 2002 Comp5421_6 1
Comp5421 Object Oriented Programming
Design Notation
Lecture 6 Tianxiang ShenSummer 2002
Department of Computer Science Concordia University
Concordia TAV 2002 Comp5421_6 2
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.
Concordia TAV 2002 Comp5421_6 3
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?
Concordia TAV 2002 Comp5421_6 4
Use Case Analysis is a technique to capture business process from user’s perspective
Visual Modeling Captures Business Process
Concordia TAV 2002 Comp5421_6 5
Visual Modeling is a Communication Tool
Use visual modeling to capture business objects and logic
Use visual modeling to analyze and design your application
Concordia TAV 2002 Comp5421_6 6
User Interface(Visual Basic,
Java)Business Logic
(C++, Java)
Database Server(C++ & SQL)
Model your systemindependent of
implementation language
Visual Modeling Defines Software Architecture
Concordia TAV 2002 Comp5421_6 7
Multiple Systems
Visual Modeling Promotes Reuse
ReusableComponents
Concordia TAV 2002 Comp5421_6 8
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
Concordia TAV 2002 Comp5421_6 9
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
Concordia TAV 2002 Comp5421_6 10
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.
Concordia TAV 2002 Comp5421_6 11
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.
Concordia TAV 2002 Comp5421_6 12
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.
•
Concordia TAV 2002 Comp5421_6 13
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
Concordia TAV 2002 Comp5421_6 14
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
Concordia TAV 2002 Comp5421_6 15
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)
Concordia TAV 2002 Comp5421_6 16
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:
Concordia TAV 2002 Comp5421_6 17
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.
Concordia TAV 2002 Comp5421_6 18
• 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
Concordia TAV 2002 Comp5421_6 19
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;
Concordia TAV 2002 Comp5421_6 20
Relationship: Association
• 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)
Concordia TAV 2002 Comp5421_6 21
Relationship: Association
• 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
Concordia TAV 2002 Comp5421_6 22
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
Concordia TAV 2002 Comp5421_6 23
Static Structure Diagram Example (p138)
Concordia TAV 2002 Comp5421_6 24
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)
Concordia TAV 2002 Comp5421_6 25
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.
Concordia TAV 2002 Comp5421_6 26
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.
Concordia TAV 2002 Comp5421_6 27
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/