1 / 53

Lecture 7 Project Design - Static

Lecture 7 Project Design - Static. CSCI – 3250 Software Engineering I Spring 2014 Bill Pine. Lecture Overview. Assigned Reading: Braude and Bernstein, Chapters 15, 16 What is design? Class Identification Sequence Diagrams. What Is Design?. The Statement of the Problem Requirements

coty
Download Presentation

Lecture 7 Project Design - Static

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 7Project Design - Static CSCI – 3250 Software Engineering I Spring 2014 Bill Pine

  2. Lecture Overview • Assigned Reading: Braude and Bernstein, Chapters 15, 16 • What is design? • Class Identification • Sequence Diagrams CSCI 3250

  3. WhatIs Design? • The Statement of the Problem • Requirements • The Solution of the Problem • Design • The Realization of the Solution • Implementation • Design is the intermediate step between problem statement and implementation CSCI 3250

  4. WhatIs Design? (cont) • “The purpose of design is to create a clean and relatively simple internal structure, sometimes also called the architecture” Bjarne Stroustrup • Many design methods: three examples • Top-down structured design • Data-driven design • Object-oriented design CSCI 3250

  5. Top-down Structured Design • Earliest design method • Algorithmic decomposition method • Begin a the top most level – system • Break into a series of subsystems • Decompose each subsystem into sub-subsystems • Continue until the implementation of the lowest level pieces is obvious • More software has been developed with this design method than any other CSCI 3250

  6. Top-down Struct. Design (cont) • Disadvantages • Does not scale well to large, complex systems • Most appropriate for functional languages • Inappropriate for use with object-oriented languages CSCI 3250

  7. Data-Driven Design • Data-centric method • Map the inputs to the outputs • Identify processes that transform the data • Show the flow from inputs (and datastore) thru the processes to the outputs as directed line segments • Disadvantage • Not all systems are reasonably viewed as data transformers • Incomplete view for use with object-oriented languages CSCI 3250

  8. Object-Oriented Design • Object-centric method • Model a system as a collection of collaborating objects • Objects are instances of classes in a hierarchy • Collaboration is accomplished by passing messages between objects • The resulting design is consistent with modern object-oriented languages CSCI 3250

  9. System Views • Static view • Class diagram – shows the classes in the system and their relationships • Dynamic view • Interaction Diagram – shows the objects and the messages passed • Sequence Diagram - an interaction diagram that is time sequenced CSCI 3250

  10. Prior to Class Diagrams • Need to identify classes involved • Many methods • Examine the requirements specification for nouns (noun phrases) – linguistic analysis • Use a class category list • Examine the requirements specification for responsibilities • CRC cards CSCI 3250

  11. How To Build a Class Model • Plan on several iterations • Begin by concentrating on identifying • The classes representing • Domain objects • Domain roles • Relationships between the classes • Initially show relationships as association if a more specific relationship is not immediately apparent CSCI 3250

  12. How To Build (cont) • Add more detail • Operations • Consider how the objects will collaborate to satisfy the requirements • Refine and add additional relationships • As it becomes clear, replace association names with more specific relationship names • Only after design becomes stable, add the attributes that support the operations CSCI 3250

  13. How To Build (cont) • Repeat until the model is complete and consistent CSCI 3250

  14. Class / Object Identfication • Five methods • Linguistic analysis • Class category list • Responsibility analysis • CRC cards • Design patterns

  15. Linguistic Analysis • List all nouns and noun phrases in the specification – Use-cases • This is not a mechanical process • Words in a natural language are ambiguous • Redundancies • Some nouns and noun phrases will become attributes of classes instead of class names • Some nouns and noun phases are abstract conceptual classes that will not be included in the model of the system CSCI 3250

  16. Linguistic Analysis (cont) • Some nouns and noun phases are events or operations • Some nouns and noun phases are outside the scope of the system • Linguistic analysis is frequently criticized as too simplistic, however • Can serve as a good starting point CSCI 3250

  17. Class or Attribute? • To discriminate between a class and an attribute, use the following simple heuristic • If we have a noun or noun phrase that is not represented in the “real world” by atomic data, the noun or noun phrase is probably a class • Atomic Data • A number: integer, real, or complex • A character (or string) - text • Boolean CSCI 3250

  18. Class Category List • A list of many common categories compiled over many application categories CSCI 3250

  19. Team Exercise • Teams 1 and 3: Create a list of candidate classes from the Case Study, using linguistic analysis • Teams 2 and 4: Create a list of candidate classes from the Case Study, using class category template • No cross talk until the exercise is over CSCI 3250

  20. UML Class Diagrams • General Ideas • Class Diagrams • Relationships • Notes • Constraints CSCI 3250

  21. General Ideas • The UML is a graphical language for creating diagrams for software engineering • The UML provides a • Set of standard graphical symbols • Rules for combining them • The UML is • Process and • Implementation language independent CSCI 3250

  22. General Ideas (cont) • The UML provides symbols to support various system views • Thirteen diagram types supported by UML 2.0 • Class Object • Use case Sequence • Component Deployment • State Machine (State Chart) Activity • Communication (Collaboration) Timing • Composite StructurePackage • Interaction Overview • Begin by examining class diagrams CSCI 3250

  23. Class Diagrams • The most common type of diagram used in modeling object oriented systems • A class diagram shows • Set of classes • Relationships among the classes • Interfaces (optional) • Additions (as needed) • Notes and • Constraints • Class diagrams show the system’s static structure CSCI 3250

  24. Class Diagrams (cont) • Represented by a three-part rectangle • Top section contains the class name • Middle section contains the class attributes • Bottom section contains the class methods • Top section is mandatory CSCI 3250

  25. Class Diagram Example CSCI 3250

  26. Class Name • Appears in the top section of the class box • Contains text • The class name is a noun or noun phrase • First letter of each word in the phrase is capitalized CSCI 3250

  27. Class Attributes • Appears in the middle section of the class box • An attribute represents some property of the class • Attribute name consists of text • noun or noun phrase • The first letter of each word in the phrase is capitalized, except the first • Optionally, specify • Type of the attribute • Default value CSCI 3250

  28. Class Attributes (cont) • Example • To specify that the attribute hour is of type integer and has an initial value of 12, replace hour in the above diagram with hour : Integer = 12 • Collections (or arrays) of attributes are indicated by giving the multiplicity in square brackets after the type • Nota Bene: • By specifying the type and default values, • Increase the information content of the diagram • At the expense of cluttering the diagram CSCI 3250

  29. Class Methods • Method - an abstraction of something that an object can do, or have done to it • Appears in the bottom section of the class box • The method name is a verb or verb phrase • Followed by left and right parenthesis • Capitalize the first letter of each word in the name, except the first CSCI 3250

  30. Class Methods (cont) • Methods may be grouped into three categories • Constructors / Destructors • Not shown on the class diagram • Queries (getters) • Returns information about the state of an object • Updaters (setters) • Changes the state of an object • Queries should never change the object’s state • High-Level Principle: Eschew side effects CSCI 3250 Lecture 7 - 30

  31. Class Methods (cont) • Optionally, you can specify the names, types and default values of all method arguments as well as the return type Example • Full specification of the setTime() and reportTime() methods setTime( newHour : Integer = 12, newMinute : Integer = 0, newSecond : Integer = 0 ) reportTime( ) : Time CSCI 3250

  32. Visibility • Symbols indicate the visibility of attributes and methods • Place immediately before the name • Symbols + public – default for methods - private – default for attributes # protected • Example • Give the attributeminute protected visibility # minute CSCI 3250

  33. Derived Attributes • Occasionally you may want to save a quantity that can be calculated from another attribute(s) - at great computational expense • Derived attributes are denoted by placing a / after the visibility and before the attribute name Example # / someDerivedAttribute CSCI 3250 Lecture 7 - 33

  34. Scope • Default - instance scope • Each object created from the class has its own value for the attribute • Give an attribute class scope • Underline the attribute name (and type and default value if present) • Most common use for class scope • Share a private variable among all instances of the class • Example: to assign each instance a unique identifier, you might need the number of objects instantiated CSCI 3250

  35. Relationships • Graphic symbols to represent the following relationships between classes • Dependency • Association • Generalization CSCI 3250

  36. Dependency • A relationship between two classes in which a change to one, called the independent class, causes a change in the other, called the dependent class • Represented by a dashed line from the dependent class to the independent class CSCI 3250

  37. Dependency Example CSCI 3250

  38. Association • A relationship that specifies that the objects of one class are connected to objects of another class • Associations corresponds to verbs or verb phrases • Represented by a solid line connecting the two classes CSCI 3250

  39. Association Example • The notations below the solid connecting line indicate the multiplicity • One or more Employees work for one or more companies CSCI 3250

  40. Association Example (cont) • Examples of multiplicities 4 exactly four 1 .. 3 one to three 0 .. * zero or more 1 .. * one or more CSCI 3250

  41. Aggregation • Models the “whole/part” relationship • Represented by a solid line connecting the two classes • With an open diamond at the end of the line adjacent to the “whole” class CSCI 3250

  42. Aggregation Example CSCI 3250

  43. Composition • A specialization of aggregation • Relationship that has strong ownership and simultaneity of lifetimes of the classes • The part class belongs to just one whole class • Cannot exist outside the whole object • Represented by a solid line connecting the two classes, with an solid diamond at the end of the line adjacent to the “whole” class CSCI 3250

  44. Composition Example

  45. Generalization • Relationship between a general class and a more specific class • Inheritance • Represented by an arrow, with an unfilled head, from the specific class (derived class) to the general class (base class) CSCI 3250

  46. Generalization Example CSCI 3250

  47. Notes • Used to place comments on the class diagram • If the note applies to a specific item on the diagram • Connect the note with the item by a dashed line CSCI 3250

  48. Notes Example CSCI 3250

  49. Constraints • Specific conditions that must be true for the model to be valid • Enclosed in braces { } • Example, PlayingCard class • One of the properties is the suit • Constrain suit to hold only the values:clubs, diamonds, hearts, or spades CSCI 3250

  50. Constraint Example CSCI 3250

More Related