Packages by jizhen1947


									Packages & Components                                                                  1

                        Software Engineering I

UML 2 and the Unified Process, Arlow & Neustadt
Chapters: 11, 19


The student shall be able to:
 Define and describe Package, Component, Interface, System, Subsystem
   and the difference between these terms.
 Describe why interfaces are useful.
 Be able to draw design documents with packages, components, interfaces
   and subsystems.
 Define advantages/disadvantages of inheritance vs. aggregation vs.

The students will learn by doing designs, with assistance from team members
and the instructor. Different projects will be assigned to different groups, so that
students will learn from each other's presentations as well.

    Packages & Subsystems                 1 hour
    Components & Interfaces               1 hour
    In-class Project                      1 hour

       Total                                            3 hours
Packages & Components                                                                    2

                           Components & Interfaces
A component is a part or element of a whole
 We can swap in and out radios from a car.
 We can swap in and out doors, carpeting/flooring, bath tubs, sinks, from
 We can swap in and out software components from software systems.
The component is an interchangeable or substitutable part

Substituting software components is useful in order to change:
 The user interface: Command or menu-driven or form-driven
 A hardware driver: Floppy or CD writer or DVD writer or Electronic disk
  (network cards or port interface)
 Software objects: A vehicle/boat/formal ware/general rental reservation

UML definition of Component:
 A higher level of abstraction than an object-oriented diagram
 An executable software module with an identity and defined interfaces
 A modular, deployable, replaceable (plug-and-play), and reusable software
 Each component may contain one or more classes and realize one or more

For a component to be exchanged, its interfaces must be compatible.
 E.g., Hardware: voltage, mechanical interface; simple interface attachment
   (no soldering)
 Compatible or similar in use.
 E.g., Software: method call, event listener, communication packets, bus

Software Interface defines a Service:
 Separate the specification from the functionality from its implementation.
 Defines a contract of services or operations that can be performed
 Each Interface operation must have:
    A signature (function name, description of parms and return type)
    Semantics: Logical pseudocode for each service defining what the services does
    Hidden Attributes: Names and types of parameters
          Getters & Setters for Set of Defined Attributes (whether or not they exist)
   Interfaces must not have:
     Code.
     Attributes: Not defined on the class diagram
Packages & Components                                       3

Important Interfaces:
 User interface
 External interfaces to other systems, devices, networks
 A Windows DLL, Java JAR file
Packages & Components                                                                  4

    Drawing Components and Interfaces
   A component is a box with two tape icon in the corner and/or labeled
   An interface can be drawn as:
     A class name with a label <<interface>> OR
     A lollipop that sticks out from the component indicates an available interface
     Socket: A half-circle lollipop indicates a required interface
   Dependencies between components are drawn as dotted arrows.
   Classes assigned to the component may be shown as classes contained
    within the component icon or with a <<resides>> dotted arrow pointing to the
    assigned classes.

                   User Interface

Implementing Components & Interfaces:

Designing with Components
 What components exist?
 What functions or services must a component support?
 What interfaces exists, and how will they be implemented?

Java Implementation of an Interface:

public interface FileServer
        public abstract String read() throws Exception;
        public abstract int write(String) throws Exception;

public class FileServerImpl implements FileServer
         public String read() throws Exception { … }
         public int write(String) throws Exception {…}

Types of Interfaces for Software Components:
 Factory Services: create() and find()
 Observer Services: (Event notifications) addRestaurantTransaction()
 Object Interfaces: get() and set()
Packages & Components                                                          5

Selecting Interfaces
Look to enhance flexibility:
 Consider whether defined services and associations may be useful for other
 Factor out operations that are defined for multiple classes
 Look for classes which fulfill the same role.
 Look for possibilities for future expansion

Interfaces: Advantages & Disadvantages
 Add flexibility
 Add complexity within the subsystem
Packages & Components                                                        6

                         Packages & Subsystems
A package is a mechanism for organizing software
 Define sets of software with a common namespace, where all names must be
 Group closely related software
 Define boundaries for Systems or Subsystems
 Provide units of configuration management

 Packages may be used to organize model elements for any waterfall
  workflow including classes, use cases, tests
 Packages (with interfaces) are useful for dividing a team into sub-teams

A company may divide its software at the highest levels into:
 Factory
 Personnel
 Accounting
 Sales
Discussion: What interactions exist within these high-level packages?

 Each package is located in its own directory.
 Packages may contain other packages, which are put in subdirectories of the
   outer package

 Each package is drawn as a tabbed folder (box with tab)
 Within package can draw class diagram of all classes within the package
 Each drawing should have 5-9 icons in it  icon = actor or class


                +SalesRegion                     <<Subsystem>>
                +SalesPerson                        Factory
Packages & Components                                                                  7

Example: Doctor’s Office
The Health First system is organized into different packages. The packages include:
 User Interface: The GUI-based logic
 Database: This package interfaces with the database
 Patient: This package has all the logic for managing Patients, including prescription,
   treatment, referrals, lab reports, and billing.
 Plan Interface: Communicates with the Health Plan. No information is stored in a
   database from the Plan Interface
The Patient and Plan Interface are provided in more detail.
Packages & Components                                                                                    8

Coding Packages in Java

Using Packages:
         import <packagename>.<subpackagename>.<filename>;
         Example: import javax.swing.JFrame; or import javax.swing.*
If import statements are not used, then fully qualified names must be used:
         javax.swing.JFrame myWindow = new javax.swing.JFrame();

Writing & Using a Java Package:
Arrange a set of classes in a directory <packagename>
Define the file as part of a package in each .java file as the first statement of the file:
         package <packagename>;

Classes which are to be seen outside the package should be defined as public. Classes that are to have
visibility only within the package use default visibility:
          public class Monopoly {…} // visibility outside package
          class JailSlot {…} // visibility only within package = ‘package private’
Only one class in a file can be declared public.

To compile go the directory that has <packagename> in it and execute:
       javac <packagename>/<filename>.java

To run, go to the directory that has <packagename> in it and execute:
         java <packagename>.<filename>

To import your created package into java files in the parent directory, declare:
         import <packagename>.*;
Or use fully qualified names:
         private <packagename>.<ClassName> <variableName>;
Packages & Components                                                         9

Interfaces between Packages

Every element is owned by one package but hierarchies are possible
E.g., Systems can be composed of Subsystems

Drawing Nested Packages
 Packages can be physically embedded in another package
 An anchor item icon (+ sign inside circle) can demonstrate that a system
   contains a subsystem (contains a class…) (Fig. 11.5)

A nested package can see all public elements of the outer package
The outer package can see public elements of the nested package if
<<access>> or <<import>> is specified from the outer to the nested package.

Drawn as dotted arrow with a dependency label:
<<import>> The destination’s namespace is available to the source
            The package name does not have to precede accesses to the
            imported package. (No pathname)
<<access>> The source can access all public elements in the destination but
            namespaces are not merged. (Pathname required)
<<use>>     The source uses a public element in the destination.
            A specific use between entities is defined.
<<trace>> The destination is a historical precedent of the source
            Useful to show the derivation of a design-level subsystem from
            an analysis-level package

       Source-----<<use>>----> Destination

Package Generalization
 Specialized child packages inherit public and protected elements from the
   parent package.
 Inheritance arrowhead points to parent package
 Child packages may add new elements/classes
 E.g. Product package is a generalized version of Hotels or CarHires

Package Stereotypes:
<<System>>        A package representing the entire system
<<Subsystem>>     A cohesive structure within the system
<<Façade>         An interface package to another package
<<Stub>>          A proxy to another package (proxy=guard door)
Packages & Components                                                         10


   A subsystem is a part of a system.
   A subsystem divides the system into parts in a course but cohesive way.
   A subsystem is a package that has formal interface(s).

Differences between Packages and Subsystems
 A package defines the namespace but add no further restrictions.
 A Package may not be defined by an formal interface and may not hide its
    inner structure.
 A subsystem has a formal interface to the outside world to hide the structure
    and inner workings of its internal parts.
 At the analysis (or logical) level we design ‘packages’; at the design (or
    physical) level they become ‘subsystems’
 A subsystem appears like a package (i.e., as a folder) but is marked with the
    stereotype <<subsystem>> or with a fork icon.

Subsystems may optionally include 3 compartments:
 Operations: Lists the public operations the subsystem supports.
 Realization elements: Demonstrates which elements implement the
 Specification elements: Contains the use cases and interfaces supported by
  the subsystem
Packages & Components                                                       11

Design Considerations
Proper design of Packages/Subsystems/Interfaces:

Coupling: Reduce coupling between packages by defining separate
namespaces and achieving a small, simple interface
 Minimize the number of public package elements
 Maximize the number of private package elements
 Minimize the dependencies between analysis packages
 Avoid mutual dependencies between packages

Cohesion: Cohesion should be high within a package.
 Excellent candidates for same package: Inheritance & Composition
 Aggregation & Dependencies: Lesser dependencies can qualify

Complete & Sufficient: Expected services exist and perform as expected.
 Completeness: Give the clients of the class what they expect
      Services will be assumed for certain classes: Account::withdraw()
 Sufficiency: Each operation performs all that is expected

Primitiveness: Methods offer a single primitive, atomic service
 Single: Performs one action as opposed to two or three
 Simple: Single option: Service is easily chosen or selected.

To achieve these goals, try moving classes around between packages to find the
best combination.

Another way to reduce coupling:

Façade Design Pattern:
 Hides complex subsystems behind a simple, formal interface.
 The Façade class receives all service requests and delegates responsibility
   to other classes in the subsystem.
    Implements the public interface: wrap access
    May implement validation functions.
 Hides the details of the internal classes of a subsystem from the outside
 Useful for very large systems
 E.g.: AdministrationFaçade, and ScheduleFaçade, hide the Student, Course,
   Class, Instructor classes.
Packages & Components                                                         12

Design Tradeoffs: Aggregation vs. Inheritance vs. Interface

Aggregation vs. Inheritance
 Strongest form of coupling
 When base class changes, derived classes may be impacted.
        E.g.: When Manager and Programmer are subclasses of the
          Employee superclass, how do we promote a Programmer to Manager?
        How do we allocate two jobs to an employee?
        Would it be simpler to define a Job class within the Employee class?
          The employee has one or more roles…
 Multiple Inheritance is problematic
        The superclasses should have no parent in common or a cycle may
        If superclasses have overlap in semantics then unforeseen
          interactions may occur. They must be disjoint.

Inheritance versus Interface Realization
 Inheritance offers interface & implementation
 When you want a contract define an interface
 Inheritance can offer reuse of code if this is useful

Define the subsystems, interfaces, and primitive services of a University
Registration System, a Hotel Reservation System, or an Alarm (burglar/fire)

To top