COMS W4156: Advanced Software Engineering - PowerPoint PPT Presentation

Loading...

PPT – COMS W4156: Advanced Software Engineering PowerPoint presentation | free to download - id: 69be14-NmE3Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

COMS W4156: Advanced Software Engineering

Description:

COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156_at_cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/ – PowerPoint PPT presentation

Number of Views:9
Avg rating:3.0/5.0
Date added: 7 November 2019
Slides: 66
Provided by: GailK88
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: COMS W4156: Advanced Software Engineering


1
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//york.cs.columbia.edu/classes/cs4156/

2
Reprise What is UML?
  • UML Unified Modeling Language
  • A standard  language for specifying, visualizing,
    constructing and documenting software artifacts
  • Standardized by Object Management Group (OMG)
  • Uses mostly graphical notations (blueprints)
  • Helps project teams communicate, explore
    potential designs, and validate the requirements
    and architectural design of the software system

3
Our Focus the Language
  • Unified Modeling Language
  • Language syntax semantics
  • Syntax rules by which language elements (e.g.,
    words) are assembled into expressions (e.g.,
    phrases, clauses)
  • Semantics rules by which syntactic expressions
    are assigned meanings

4
Building Blocks
  • The basic building blocks (syntax) of UML are
  • Model elements (classes, interfaces, components,
    use cases)
  • Relationships (associations, generalization,
    dependencies)
  • Diagrams (class diagrams, use case diagrams,
    interaction diagrams)
  • Simple building blocks are used to create large,
    complex structures

5
Types of UML Diagrams
  • Each UML diagram is designed to let developers
    and customers view a software system from a
    different perspective and in varying degrees of
    abstraction
  • Use Case
  • Interaction
  • State
  • Structural
  • Implementation

6
Structural Modeling
  • Define the architecture
  • Used to model the things that make up the
    system
  • Model class structure and contents
  • Emphasizes the structure of objects, including
    their classifiers, attributes, operations, and
    relationships including dependencies

7
Structural Diagrams
  • Show a graph of elements connected by
    relationships
  • Kinds
  • Class diagram classifier view
  • Object diagram instance view
  • Shows the static structures of the system (not
    dynamic or temporal)

8
Class Diagrams
  • Shows how the different entities (people, things
    and data) relate to each other
  • A class diagram can be used to display logical
    classes, not necessarily code classes, which are
    typically the kinds of things the business people
    in an organization talk about rock bands, CDs,
    radio play or home mortgages, car loans,
    interest rates
  • Use domain vocabulary

9
Class Diagram Example
10
Class Notation
  • A class is depicted on the class diagram as a
    rectangle with three horizontal sections
    (compartments)
  • The upper section shows the class's name
  • The middle section contains the class's structure
    or attributes, optionally with initial values
  • The lower section contains the class's operations
    or behaviors (or "methods")
  • May be abbreviated to show just name, or just
    name and attributes

11
Class Example
12
Class Diagram
  • Draw a generalization relationship using a line
    with an arrowhead at the top pointing to the
    super class, where the arrowhead should a
    completed triangle
  • Associations
  • A solid line if both classes are aware of each
    other
  • A line with an open arrowhead if the association
    is known by only one of the classes (pointing to
    the class known by the other one, i.e., direction
    of potential navigation)
  • Optionally label with multiplicity

13
Example Class Diagram
Generalization
One-way association
Two-way association
14
Association Example
15
Generalization Example
16
Core Elements
17
Core Relationships
18
Implementation Class Diagrams
  • Can also be used to show implementation classes,
    which are the things that programmers typically
    deal with
  • An implementation class diagram will probably
    show some of the same classes as the logical
    classes diagram
  • The implementation class diagram won't be drawn
    with the same attributes, however, because it
    will most likely have references to things like
    Vectors and HashMaps
  • May add compartments such as responsibilities and
    exceptions, even gist of method body
  • May indicate attribute and operation visibility
    public, private, protected, package

19
Example Implementation Class
20
Example Class Detail
  • public
  • private
  • protected
  • package visibility

21
Method Body Example
22
Generalization
  • Often represents inheritance at implementation
    class level
  • Abstract class names given in italics
  • Possibly multiple inheritance
  • Possibly multiple inheritance hierarchies
    emanating from same base class
  • Separate vs. shared target formats

23
Generalization Example Equivalent Forms
24
Generalization Example
25
Multiple Level Generalization Example
26
Associations
  • Reflect connections, usually implemented as an
    instance variable in one class
  • Connector may include named roles at each end,
    cardinality, direction and constraints
  • Self-associations permitted
  • May indicate choice (xor)
  • May be N-ary (not just binary)
  • Association classes allow an association
    connection to have operations and attributes

27
Association Example
28
Association Examples
29
Association Class Example
30
Ternary Association Class Example
31
Aggregations
  • Aggregations are a stronger form of association
    between a whole and its parts
  • Drawn with a diamond next to the class
    representing the target or whole (parent)
  • open vs. closed diamond indicates usage vs.
    containment semantics
  • Containment may be indicated by composition
    rather than relationship lines

32
Aggregation Example
33
Aggregation Example
34
Composition Example
35
Dependencies
  • Dependencies are a weaker form of association
    without semantic knowledge
  • Often used early in the design process where it
    is known that there is some kind of link between
    two elements, but it is too early to know exactly
    what the relationship is
  • Later in the design process, dependencies may be
    replaced with a more specific type of connector
  • Shown with a dashed line (e.g., from client to
    supplier)
  • ltltlabelgtgt on line specifies kind (stereotype) of
    dependency, e.g., ltltinstantiategtgt, ltltimportgtgt,
    etc.

36
Dependencies Example
37
Dependencies Example
38
Interfaces
  • All interface operations are public and abstract,
    and all interface attributes must be constants
  • By realizing an interface, classes are guaranteed
    to support a required behavior, which allows the
    system to treat non-related elements in the same
    way that is, through the common interface
  • While a class may only inherit from a single
    super-class, it may implement multiple interfaces
  • May be drawn in a similar style to a class, with
    operations specified
  • Or may be drawn as a circle with no explicit
    operations detailed (when drawn as a circle,
    realization links to the circle form of notation
    are drawn without target arrows)

39
Interface Example
40
Interface Realization Example
41
Interface Example
Adapted from Fig. 23 EJB 2.0.
42
Types and Implementation Classes Example
43
Object Diagrams
  • Refer to a specific instance
  • Special case of a class diagram
  • Does not show operations but may show runtime
    state
  • Object names are underlined and may show the name
    of the classifier from which the object is
    instantiated
  • May compose multiple specific instances
  • May be drawn as glyphs

44
Class vs. Object Diagram Example
45
Run-time State Example
46
More Object Examples
47
Composite Objects Example
48
When to Model Structure
  • Adopt an opportunistic top-down interleaved with
    bottom-up approach to modeling structure
  • Specify the top-level structure using
    architecturally significant classifiers and
    model management constructs (subsystems)
  • Specify lower-level structure as you discover
    detail wrt classifiers and relationships

49
Implementation Diagrams
  • Additional structural modeling (beyond classes,
    interfaces and objects)
  • Show aspects of model implementation, including
    source code structure and run-time implementation
    structure
  • Kinds
  • Package diagram
  • Component diagram
  • Deployment diagram

50
Package Diagrams
  • Used to reflect the organization of packages and
    their elements
  • Provide a visualization of the namespaces
  • Elements contained in a package share the same
    namespace, therefore must have unique names
  • Drawn as folders, with tabs at the top the
    package name is on the tab or inside the
    rectangle
  • Dotted arrows show dependencies - one package
    depends on another if changes in the other could
    possibly force changes in the first

51
Package Diagrams
  • Packages may be imported or nested
  • A ltltmergegtgt connector between two packages
    defines an implicit generalization between
    elements in the source package and elements with
    the same name in the target package
  • The target package need not contain elements with
    same names as all source package elements

52
Package Diagram Example
nested package
53
Component Diagrams
  • Describes the software components that make up
    the system
  • Provides a physical view of the system
  • Shows the dependencies that the software has on
    the other software components (e.g., software
    libraries) in the system
  • A component is illustrated as a large rectangle
    with two smaller rectangles on the side,
    lollipops represent interfaces
  • Dashed lines with arrows between components
    indicate dependencies

54
Component Examples
55
Component Diagram Example
56
Component Diagram Example with Labeled
Dependencies
57
Deployment Diagram
  • Visualizes the physical architecture and the
    deployment of components on that hardware
    architecture
  • Shows how a system will be physically deployed in
    the hardware environment, distribution of
    components across the enterprise
  • Its purpose is to show where the different
    components of the system will physically run and
    how they will communicate with each other

58
Deployment Diagram Notation
  • Includes the notation elements used in a
    component diagram, plus adds the concept of a
    node
  • A node represents either a physical machine or a
    virtual machine node (e.g., a mainframe node)
  • To model a node, simply draw a three-dimensional
    cube (or box) with the name of the node at the
    top of the cube
  • Use the naming convention instance name
    instance type (e.g., "w3reporting.myco.com
    Application Server")

59
Deployment Diagram Example
60
Summary
  • UML is effective for modeling large, complex
    software systems
  • It is simple to learn for most developers, but
    provides advanced features for expert analysts,
    designers and architects
  • It can specify systems in an implementation-indepe
    ndent manner
  • 10-20 of the constructs are used 80-90 of the
    time
  • Structural modeling specifies a skeleton for the
    structural elements that supply the behavior
    (sequence, state, activity diagrams) and
    implement the use cases (use case diagrams)
  • Implementation diagrams extend structural
    modeling to source code and run-time structure

61
Resources
  • http//www.uml.org/ The official UML Web site
  • http//argouml.tigris.org/ Information on Argo
    UML, an open source UML modeling tool built in
    Java
  • http//uml.sourceforge.net/index.php
    Information on Umbrello UML Modeller, an open
    source UML modeling tool for KDE
  • http//www-306.ibm.com/software/rational/uml/ -
    IBMs UML resource center (IBM bought Rational in
    2002)

62
First Iteration Demos Due!
  • October 30th November 8th
  • Extra credit on per-day-early sliding scale
  • Only team members present for the demo (for CVN
    virtually present) will receive credit 10 of
    final grade
  • No presentation needed, but be prepared to
    answer questions, show your code, and let the TA
    enter input to your system

63
Upcoming Deadlines
  • First iteration final report due Friday November
    9th, must respond to any issues that arose
    during demo
  • Midterm Individual Assessment posted Friday
    November 9th
  • Midterm Individual Assessment due Friday November
    16th
  • 2nd iteration starts

64
Second Iteration
  • Add extensive error checking and exception
    handling
  • Black box unit testing and white box statement
    coverage
  • Semi-formal code inspection
  • Security and stress testing
  • Seeking volunteer teams to do code inspections
    (Tue 27 Nov and Thu 29 Nov) and final demos (Tue
    4 Dec and Thu 6 Dec) in class

65
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//york.cs.columbia.edu/classes/cs4156/
About PowerShow.com