1 / 59

UML Introduction

UML Introduction. Alexandre Lomovtsev, Natalia Shatokhina. Frameworks and Design Patterns. John Hautzinger, Sae Rom Hong. CS537 – Fall 2010 CSULA. UML Introduction. Alexandre Lomovtsev, Natalia Shatokhina. What is UML?.

claus
Download Presentation

UML Introduction

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. UML Introduction Alexandre Lomovtsev, Natalia Shatokhina Frameworks and Design Patterns John Hautzinger, Sae Rom Hong CS537 – Fall 2010 CSULA

  2. UML Introduction Alexandre Lomovtsev, Natalia Shatokhina

  3. What is UML? • is a complete Languagefor capturing knowledge (semantics) about a subject and expressing knowledge (syntax) regarding the subject for the purpose of communication • applies to Modeling – process of understanding a subject (or a system) • is Unified – remaining the same at each stage of development

  4. Background • 1965 - the first object-oriented programming language, Simula I, was introduced • Object-oriented design began to rapidly grow • Numerous competing object-oriented design methods and modeling languages • over 50 modeling languages

  5. Dominate modeling methods • Object-oriented Analysis & Design (OOAD) by Grady Booch • The Object Modeling Technique (OMT) by James Rumbaugh • The Object-oriented Software Engineering method (OOSE) by Ivar Jacobson

  6. Booch (OOAD) • Very complex • The modeling language has too many types of diagrams and diagram elements • Effective at low-level design • Useful for documenting code • Good at OO Design, weak at OO Analysis

  7. Rumbaugh (OMT) • A simpler modeling language • Better at higher-level designs than Booch’s Method. • Good at OO Analysis, weak at OO Design

  8. OO Analysis vs. OO Design • Analysis refers to understanding the problem. • Design refers to coming up with the solution. REQUIREMENTS and ANALYSIS DESIGN IMPLEMENTATION TESTING

  9. Jacobson (OOSE) • Major feature was "use classes" • how a system interacts with users (other systems or end users) • Viewing things from the user’s perspective • Good at very high-level design

  10. In summary • Jacobson (OOSE) good at high-level design • Rumbaugh (OMT) good at the middle ground • Booch (OOAD) good at low-level design

  11. Chronics of the UML 1994 : Booch + Rumbaugh =Unified Method 0.8 1995 : + Jacobson = UML 0.8 1996 : UML 0.9 Receiving a feedback from IBM, Microsoft, Oracle, HP and other companies 1997 : UML 1.0 Object Management Group (OMG) joined UML project 1997 : UML 1.1 UML is running under the OMG Revision Task Force Improving semantics and flexibility 2003 : UML 2.0

  12. Criticisms • Standards bloat • size of UML specification is dramatically increased • too many diagrams that are redundant or infrequently used • problem in learning and adopting • The extremely poor writing of the UML standards themselves • written by a non-native English speakers • an example of unintelligible geek-speak • UML and implementation language mismatch • an intersection set between UML and implementation language is very small

  13. Criticisms (cont.) • Dysfunctional interchange format • The XMI (XML Metadata Interchange) standard is large and complex • The UML’s main purpose is not being an interchange format between modeling tools. • A lot of modelers who don't want to redraw their diagrams

  14. UML 2.0 diagrams

  15. UML 2.0 Elements • Behavioral Diagram Elements • State • Use Case • Package • … • Structural Diagram Elements • Class • Object • Interface • …

  16. UML 2.0 Elements • Links • Composition Link • Unidirectional Association Link • Bidirectional Association Link • Generalization Link • Multiplicity • 0..1 No instances, or one instance • 1 Exactly one instance • 0..* Zero or more instances • 1..* One or more instances (at least one)

  17. Structural diagramsClass diagram Class diagram gives a static view of the system EXAMPLEModeling a family tree - this model is similar to a class diagram To build a model we need to: Identify the main members of the family (CLASSES) Determine how they are related to each other (HIERARCHY) Identify the characteristics of each family member (ATTRIBUTES) Find relations among any members (RELATIONSHIPS BTW CLASSES) Decide the inheritance of personal traits and characters (INHERITANCE) A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modeled, and the relationships between these classes and interfaces. In a typical software development life cycle class diagrams are made by senior developers with the help of system architects.

  18. Class Diagram-Example class name relationships

  19. Stereotypes • It is an extension of the existing UML elements; it allows you to define new elements modeled on the existing UML elements. • Graphically, a stereotype is rendered as a name enclosed by angle brackets (<< >>) and placed above the name of another element. In addition or alternatively it may be indicated by a specific icon. • In a class diagram stereotypes can be used to classify method behavior for example as <<constructor>>. • Constructor stereotype indicates that the operations following it are constructors. Key Manager <<constructor>> - New () <<misc>> + GetInstance(): KeyManager

  20. Behavior diagramsUse case diagram • Captures functional aspects of a system • The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases". • The Use case diagram shows which "actors" interact with each "use case". • This kind of diagrams are made by business or functional domain experts

  21. Use case diagram Elements: • Actors: An actor portrays any entity (or entities) that performs certain roles in a given system • Interactions Use case: a visual representation of a distinct business functionality in a system

  22. State machine diagram • Class and use cases diagrams are staticwhich means that they help in visualizing what the elements of the complete system would be, but do not say anything about the flows any object of the system can have when an event occurs. • State diagrams are used to help the developer better understand any complex/unusual functionalities or business flows of specialized areas of the system. In short, State diagrams depict the dynamic behavior of the entire system, or a sub-system, or even a single object in a system. • A state diagram can be defined not only for a system or subsystem, but also for an object in the system.

  23. State machine diagram • A state machine diagram specifies the sequence of events that an object goes through during its lifetime in response to events. • As an example, the following state machine diagram shows the states that a door goes through during its lifetime. Activities state

  24. Activity diagram • An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state. • A State diagram shows the different states an object is in during the lifecycle of its existence in the system, and the transitions in the states of the objects. • An Activity diagram talks more about these transitions and activities causing the changes in the object states.

  25. Activity diagram Initial state Activity to model : • Attending a lecture at 8 am Activity steps: • Get dressed • Make decision if there is enough time to take bus • Take bus, or take taxi depending on decision • Arrive at school and attend lecture Get dressed In time for bus Not in time for bus Take bus to school Take taxi to school Attend lecture Final state

  26. Sequence diagram • Shows object interaction over time • One of the most widely used dynamic diagrams in UML • A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram.

  27. Object :CommsController :WeatherStation :WeatherData Actor request (report) acknowledge() request () summarize() send(report) reply (report) Life line acknowledge() Activation Sequence diagram • Two-dimensional: Verticalaxis - life of the object that it represents Horizontal axis - the sequence of the creation or invocation of these objects.

  28. Communication diagram Diagram shows how several objects collaborate to get job done. Models object interactions and structural dependencies Structural components: • Telephone • Cellular radio • Display • Microphone • Speaker • Button • Dialer Example: Software system that controls simple cell phone Use case: user makes a call :Speaker 1.2:EmitTone(code) 1*:Digit(code) 2.1:Connect(pno) :Button :Dialer :Cellular radio 1.1:DisplayDigit(code) 2:Send() 2.1.1 :In Use() :Send:Button :Display

  29. Structure diagrams for implementationComponent diagram Component diagrams represent the implementation perspective of a system. Hence, components in a Component diagram reflect grouping of the different design elements of a system, for example, classes of the system.

  30. Deployment diagram • The deployment diagram captures the configuration of the runtime elements of the application and represents interactions between software and hardware. • The deployment diagram elements provide the necessary environment for the components to execute in. • The basic deployment diagram element is the node. The node represents the environment in which a component or a set of components execute. • Deployment diagram should start from the time when static design is being formalized using, say, class diagrams. • This deployment diagram evolves and is revised until the system is built.

  31. Deployment diagram Example: University information system nodes

  32. Software development phases and UML Software lifecycle: • Requirements definition • Use case diagrams • Activity diagrams • Sequence diagrams • Communication diagram • System and software design and implementation • Component diagrams • Class diagram • State diagram • Deployment • Deployment diagram

  33. Frameworks and Design Patterns John Hautzinger, Sae Rom Hong

  34. Patterns and Frameworks • Classes • Mechanism for encapsulation • Provides a single service • Rarely a complete solution • Application Frameworks and Design Patterns became popular solutions

  35. Application Frameworks • Set of classes that cooperate with each other • Together embody reusable design for a general category of problems • Framework dictates the overall function and behavior of the application. • Describes how responsibilities are partitioned between various components and how they interact.

  36. Application Frameworks (Cont.) • Application Frameworks became popular with the rise of GUIs • These tended to promote standard structures • Commercial Application Frameworks • MacApp • First commercial application framework • Microsoft Foundation Classes (MFC) • Oracle Application Development Frameworks • Oracle ADF • Aids in producing Java-oriented systems • Swing

  37. Popular Frameworks • Swing • Developed to provide a more sophisticated set of GUI components than Abstract Window Toolkit (AWT) • Highly partitioned to allow extensibility •  Users can provide their own custom implementations of these components to override the default implementations • Highly Customizable, Configurable, and Lightweight

  38. Popular Frameworks • Oracle Application Development Framework • Java framework for developing enterprise applications • Supports rapid application development using design patterns • Supports many software frameworks

  39. A Framework as an Upside-down Library • In a traditional application-specific code defines overall flow of execution, occasionally invoking library-supplied code • Frameworks reverse this relation • Flow of control is dictated by the Framework and the creator of a new application merely changes some of the methods invoked by the framework • Inheritance is often used for achieving this • Alternatively application-specific components that obey a specified interface are plugged in

  40. Application Framework Examples • GUI application frameworks simplify the construction of graphical user interfaces • A GUI application framework implements the behavior expected from a graphical user interface • Hold windows, buttons, menus, etc.. • A new application is built by specifying and arranging necessary elements and modifying certain methods

  41. Another AF Example • Simulation frameworks simplify the creation of simulation style applications • Simulation frameworks provide general-purpose classes for managing the types of objects in the simulation • The heart of the simulation framework is a procedure that cycles through the list of objects introduced and asks each to update itself • The framework knows nothing of the particular application

  42. Toolkits and Frameworks Main body of an application Reuse the main body of an Application and write the code it calls Calls a procedure or a method Defines the architecture or the application Toolkit Framework Toolkits: Collection of related and reusable classes e.g. C++ I/O stream library Framework: A set of cooperating classes that make up a reusable design for a specific class of applications e.g. drawing, compilers, CAD/CAM etc.

  43. Disadvantages of Frameworks • May add to "code bloat" • Due to both competing and complimentary frameworks sometimes being needed • Some 'one size fits all' frameworks' add much unused code • Can be argued that frameworks may add to development time • Developers must take time to learn the framework

  44. Questions about Frameworks • When using frameworks, what defines the architecture of the application? • In a traditional application the architecture of is defined by the specific functional problem that the application needs to solve • Using a framework, in addition to the problem needing to be solved, the architecture is defined by the framework in use • What is more difficult to design: Application, toolkit, or frameworks? • Frameworks are the most difficult to design, they permeate the entire application and dictate its architecture.

  45. Questions about Frameworks • How do changes in framework affect an application? • Since the framework permeates the application on almost every level, major changes to the framework may change the way the application functions. This may result in changes that need to be made in the code and/or logic of the application • How do design patterns differ from frameworks? • A design pattern is not a finished design that can be transformed into code. It is a description or template for how to solve a problem that can be used in many different situations. Frameworks can be directly implemented into an application whereas design patterns

  46. Design Patterns

  47. Design Goals • Reusability, Flexibility, and Maintainability • Reuse flexible designs • Keep code at a general level • Minimize dependency on other classes • Robustness • Reuse reliable designs • Reuse robust parts • Sufficiency and Correctness • Modularize design • Reuse trusted parts

  48. What are Design Patterns? • Design patterns are an attempt to collect and catalog the smallest recurring architectures in object oriented software systems. • A design pattern expresses an idea rather than a fixed class combination • Design patterns are more abstract than a framework • It conveys an idea, however, not a completely specific design.

  49. What are Design Patterns? • Example how patterns express idea: Housing Preferences to a realtor Ranch Style Spanish Colonial Style Victorian House Style Bungalow Style

  50. Design Patterns VS Algorithm • Efficiency is used to describe properties of an algorithm relating to how much of various types of resources it consumes • Speed • Memory • Design Patterns is more related to relationships in OOP

More Related