A Rapid Overview of UML

Transcription

1 A Rapid Overview of UML The Unified dmodeling Language (UML) Emerged in the mid 90s as the de facto standard for softwareengineering engineering design Use case diagram depicts user interaction with system Class (or object) diagram depicts static structure Sequence diagram and state diagram depicts the dynamic behavior of the system Learning these diagrams covers about 90% of needs Software Tools Violet, very easy to use and free ( Microsoft Visio Pro, much more complete but steeper learning curve, free only for limited time trials

2 Actors (h (the stick figures) Use Case Diagram Can be people, as shown here Can be other external entities, such as another computer or a GPS satellite Not part of the system itself Use Cases (ovals) Major components of system Name indicates general purpose Detailed behavior given in the associated scenario (see next slide) Interactions (lines) Indicates which h use cases each actor interacts with ih

3 Associated Scenarios Each oval (use case) has an associated scenario Components are List of actors Entry conditions Flow of events (often more detailed than example shown at the right) Exit conditions Special requirements or exceptions Use case name: AllocateResources Participating Actors: Dispatcher Entry Condition The Resource Allocator has selected an available resource. The resource is currently not allocated Flow of Events The Resource Allocator selects an Emergency Incident. The Resource is committed to the Emergency Incident. Exit Condition The use case terminates when the resource is committed. The selected Resource is now unavailable to any other Emergency Incidents or Resource Requests. Special Requirements The Field Supervisor is responsible for managing the Resources

4 Graphical notation tti The tabbed outer frame is the package Each rectangle has a name (required), instance variables orfields (optional), and methods (optional) Underlined methods are static Parameter lists may or may not be shown Return type shown to the right Notes are dog eared rectangles Class Diagram

5 Class Relationships Closed, hollow arrowhead dindicates subclasses (an is a relationship) Italicized methods are abstract A diamond indicates a part of relationship A plain arrow is an association May have multiplicity, such as 0..1 shown, * means zero or more Associations may be named Names at the end of an association indicate a role (not shown here) Dashed arrows are used for exceptions or for a dependency that is not an object reference

6 The interface box <<interface>> above name Interfaces Same three parts: name, fields (can only be constants in Java), and methods Interfaces can have inheritance as shown by StartPressDriver and ShellDriver The lollypop notation shows when a class implements an interface, such as HskMachineManager2 implementing Cloneable

7 Object Diagram An object diagram deals with instances of objects An instance is shown by underlining the name The format is <name>:<class> such as c being an instance of a Chemical Object diagrams are not as widely used as class diagrams

8 Sequence Diagram Passenger ChangeProcessor CoinIdentifier Display CoinDrop * insertchange(coin) Iteration lookupcoin(coin) price displayprice(owedamount) Condition [owedamount<0] returnchange(-owedamount) Notation Actor is shown to the left; classes are at the top of columns Time progresses from top to bottom; rectangles are the lifetime for an interaction some objects can return information, such as price above * indicates iteration, [.] indicates condition

9 Behavior of a single object What object is modeled as shown at the right? iht? State Diagram The rounded rectangles are states; an object may remain in a state indefinitely The arrows represent transitions between states; they happen very quickly Notice that if something takes time, such as opening, it is shown as a state and not a transition

10 Techniques for Finding Objects Requirements Analysis Start with Use Cases. Identify participating objects Textual analysis of flow of events (find nouns, verbs,...) Extract application domain objects by interviewing client (application domain knowledge) Find objects by using general knowledge System Design Subsystem decomposition Try to identify layers and partitions Object Design Find additional objects by applying implementation domain knowledge

11 Another Source for Finding Objects : Design Patterns What are Design Patterns? A design pattern describes a problem which occurs over and over again in a software development environment Then it describes the core of the solution to that problem, in such a way that you can use the this solution many times over, without ever doing it the same twice Design patterns are more general than generics

12 Design Patterns encourage reusable Designs A facade pattern should be used by all subsystems in a software system. The facade willdelegate requests to the appropriate components within the subsystem. Most of the time the façade does not need to be changed, when the component is changed. Adapters should be used to interface to existing components. For example, a smart card software system should provide an adapter for a particular smart card reader and other hardware that it controls and queries. Bridges should be used to interface to a set of objects where the full set is not completely known at design time. when the subsystem must be extended later after the system has been deployed and client programs are in the field.

13 Design pattern A design pattern is a template solution to a recurring design problem Look before re inventing the wheel just one more time reusable designknowledge Higher level than classes or data structures (link lists,binary trees...) Lower level than application frameworks an example of modifiable design Learning to design starts by studying other designs

14 Why are modifiable designs important? A modifiable design enables an iterative and incremental development cycle concurrent development risk management flexibility to change to minimize the introduction of new problems when fixing old ones to deliver morefunctionality after initial delivery

15 What makes a design modifiable? Low coupling and high cohesion Clear dependencies Explicit assumptions How do design patterns help? They are generalized from existing systems They provide a shared vocabulary to designers They provide examples of modifiable designs Abstract classes Delegation

16 Historical Development of Design Patterns Design patterns emerged in the 1990s In 1987, Kent Beck and Ward Cunningham began experimenting i with ihthe idea of applying li patterns to programming Thebook Design Patterns: Elements of Reusable Object Oriented Software by Erich Gamma; Richard Helm, Ralph Johnson, and djohn Vlissides was aspublished in 1994 This is referred to as the Gang of Four (GoF) book and has become a classic in computer science Expansion of Patterns The GoF book describes 23 patterns Over 100 patterns are now described in the literature; many new patterns involve concurrency

17 Pattern Organization of design patterns in the Gang of Four textbook Structural Behavioral Creational Pattern Pattern Pattern Composite Iterator Singleton Decorator Adapter Bridge Command Observer Template Abstract Factory Builder Factory Method Façade Proxy Flyweight Strategy Prototype Visitor Chain of Responsibility Interpreter Mediator Memento State

18 Organization in Our Textbook Our textbook authors have decided to organize these patterns into five subgroups This organization is non standard, everyone else uses the GoF organization

19 Design Patterns and Frameworks Frameworks are reusable abstractions of code wrapped in a well defined API Examples in Java are the Collections framework Or the AWT/Swing framework for GUI design Characteristics in a framework the overall program's flow of control is not dictated t d by the caller, but tby the framework A framework has a default behavior A framework can be extended by the user usually by selectively overriding methods with user code Many frameworksuse design patterns (e.g. iterators are used with collections)

20 Summary Design patterns are partial solutions to common problems such as separating an interface from a number of alternate implementations ti wrapping around a set of legacy classes protecting a caller from changes associated with specific platforms. A design pattern is composed of a small number of classes use delegation and inheritance provide a robust and modifiable solution. These classes can be adapted and refined for the specific system under construction. Customization of the system Reuse of existing solutions