1 / 94

Software Design Models UML

Software Design Models UML. Software Engineering. Where are we?. Requirements vs. Design. Requirements: What the system should do More abstract Design: How the system should do it More detailed. Object models. Object models describe the system in terms of object classes

marge
Télécharger la présentation

Software Design Models UML

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. Software Design ModelsUML Software Engineering

  2. Where are we?

  3. Requirements vs. Design • Requirements: • What the system should do • More abstract • Design: • How the system should do it • More detailed

  4. Object models • Object models describe the system in terms of object classes • An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object

  5. The Unified Modelling Language • The Unified Modelling Language is a standard graphical language for modelling object oriented software • At the end of the 1980s and the beginning of 1990s, the first object-oriented development processes appeared • In 1995, another methodologist, Jacobson, joined the team • His work focused on use cases • In 1997 the Object Management Group (OMG) started the process of UML standardization

  6. History of UML

  7. Structural : element of spec. irrespective of time Class Component Deployment Object Composite structure Package Behavioral : behavioral features of a system / business process Activity State machine Use case Interaction Overview of UML Diagrams • Interaction • : emphasize object interaction • Communication(collaberation) • Sequence • Interaction overview • Timing

  8. Diagrams in UML A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). • Class diagram shows a set of classes, interfaces, and collaborations with their relationships. • Object diagram shows a set of objects and their relationships. • Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.

  9. Diagrams in UML (continued) • Interaction diagram shows an interaction, consisting of a set of objects and the relationships, including the messages that may be dispatched among them. => A sequence diagram emphasizes the time ordering. => A collaboration diagram emphasizes the structural organization of the objects that send and receive messages.

  10. Diagrams in UML (continued) • Statechart diagram shows a state machine consisting of states, transitions, events, and activities. • Activity diagram is a statechart diagram that shows the flow from activity to activity within a system. • Component diagram shows the organization and dependencies among a set of components. • Deployment diagram shows the configuration of processing nodes and the components that live on them.

  11. UML Class Diagrams • The main symbols shown on class diagrams are: • Classes • represent the types of data themselves • Associations • represent linkages between instances of classes • Attributes • are simple data found in classes and their instances • Operations • represent the functions performed by the classes and their instances • Generalizations • group classes into inheritance hierarchies

  12. Notation: Classes name attributes operations Window origin size open() close() move() display() A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

  13. Classes • A class is simply represented as a box with the name of the class inside • The diagram may also show the attributes and operations • The complete signature of an operation is: operationName(parameterName: parameterType …): returnType

  14. Employee object class (UML)

  15. Object diagram

  16. Notation: Interface ISpelling An interface is a collection of operations that specify a service of a class or component, i.e., the externally visible behavior of that element.

  17. UML associations • Objects and object classes participate in relationships with other objects and object classes • In the UML, a generalised relationship is indicated by an association • Associations may be annotated with information that describes the association

  18. An association model

  19. Labelling associations • Each association can be labelled, to make explicit the nature of the association

  20. Analyzing and validating associations • One-to-one • For each company, there is exactly one board of directors • A board is the board of only one company • A company must always have a board • A board must always be of some company

  21. Analyzing and validating associations • Many-to-many • A secretary can work for many managers • A manager can have many secretaries • Secretaries can work in pools • Managers can have a group of secretaries • Some managers might have zero secretaries. • Is it possible for a secretary to have, perhaps temporarily, zero managers?

  22. Analyzing and validating associations • Avoid unnecessary one-to-one associations • Avoid this do this

  23. A more complex example • A booking is always for exactly one passenger • no booking with zero passengers • a booking could never involve more than one passenger. • A Passenger can have any number of Bookings • a passenger could have no bookings at all • a passenger could have more than one booking

  24. * * * * * * * * * Student CourseSection Student Registration CourseSection grade Registration grade Association classes • Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes • The following are equivalent

  25. Reflexive associations • It is possible for an association to connect a class to itself successor * Course isMutuallyExclusiveWith * * * prerequisite

  26. Directionality in associations • Associations are by default bi-directional • It is possible to limit the direction of an association by adding an arrow at one end * * Day Note

  27. Generalization • Specializing a superclass into two or more subclasses • The discriminator is a label that describes the criteria used in the specialization

  28. Avoiding unnecessary generalizations Inappropriate hierarchy of classes, which should be instances * Recording RecordingCategory Improved class diagram, with its corresponding instance diagram hasCategory * title description subcategory artist :RecordingCategory :RecordingCategory video audio subcategory subcategory subcategory subcategory subcategory :RecordingCategory :RecordingCategory :RecordingCategory :RecordingCategory :RecordingCategory music video jazz classical blues rock :Recording :Recording Let it be 9th Symphony The Beatles Beethoven

  29. Instance Diagrams • A link is an instance of an association • In the same way that we say an object is an instance of a class Pat:Employee Wayne:Employee OOCorp:Company OOCorp's Board: Ali:Employee Carla:Employee UML inc:Company UML inc's Board Terry:Employee

  30. Associations versus generalizations in instance diagrams • Associations describe the relationships that will exist between instances at run time. • When you show an instance diagram generated from a class diagram, there will be an instance of both classes joined by an association • Generalizations describe relationships between classes in class diagrams. • They do not appear in instance diagrams at all. • An instance of any class should also be considered to be an instance of each of that class’s superclasses

  31. Composition • A composition is a strong kind of aggregation • if the aggregate is destroyed, then the parts are destroyed as well • Two alternatives for addresses * * * * * Building Room

  32. Object aggregation

  33. Detailed Example: A Class Diagram for Genealogy • Problems • A person must have two parents • Marriages not properly accounted for

  34. Genealogy example: Possible solutions Person Person name name sex placeOfBirth placeOfBirth dateOfBirth child dateOfBirth placeOfDeath child * placeOfDeath dateOfDeath * dateOfDeath partner * * * * 0..2 {partner->forAll(p1,p2 | p1 <> p2 implies p1.sex <> p2.sex)} * Woman Man Union femalePartner 0..1 * * * * 0..1 malePartner child child 0..1 placeOfMarriage parents * * dateOfMarriage Union dateOfDivorce 0..1 placeOfMarriage parents dateOfMarriage dateOfDivorce

  35. An example (attributes and associations) Employee RegularFlight Passenger * name time name employeeNumber flightNumber number jobFunction supervisor * * * * * * * * * * * * * * * * * * * Booking * * * * * * SpecificFlight seatNumber date

  36. An example (generalization) Person 0..2 0..2 0..2 0..2 0..2 0..2 PersonRole name idNumber RegularFlight * EmployeeRole time PassengerRole flightNumber jobFunction supervisor * * * * * * * * * * * * * * * * * * * Booking * * * * * * SpecificFlight seatNumber date

  37. Generalisation and inheritance • Objects are members of classes which define attribute types and operations • Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes) • A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own • Generalisation in the UML is implemented as inheritance in OO programming languages

  38. A generalisation hierarchy

  39. Multiple inheritance • Rather than inheriting the attributes and services from a single parent class, a system which supports multiple inheritance allows object classes to inherit from several super-classes • Can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics • Makes class hierarchy reorganisation more complex

  40. Multiple inheritance

  41. Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.

  42. Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.

  43. Candidate Classes Library the name of the system Book Journal Copy ShortTermLoan event LibraryMember Week measure MemberOfLibrary repeat Item book or journal Time abstract term MemberOfStaff System general term Rule general term

  44. Relations between Classes Book is an Item Journal is an Item Copy is a copy of a Book LibraryMember Item MemberOfStaff is a LibraryMember Is Item needed?

  45. Operations LibraryMember borrows Copy LibraryMember returns Copy MemberOfStaff borrows Journal MemberOfStaff returns Journal Item not needed yet.

  46. MemberOfStaff Book Copy Journal LibraryMember Class Diagram 1 1 on loan on loan 0..* 0..12 is a copy of 1..* 1

  47. Representing Architecture: The 4+1 View Model Logical View Implementation View Analysts/Designers Programmers Software management End-user Functionality Structure Use-Case View Process View Deployment View System Integrators System Engineering Performance Scalability Throughput System topology Delivery, installation communication

  48. BusinessModeling supported by Business Model Requirements realized by Use-CaseModel Analysis & Design implemented by DesignModel Implementation verified by ImplementationModel Test TestModel Major Workflows Produce Models

  49. Use case modeling • Use cases were developed originally to support requirements elicitation and now incorporated into the UML. • Each use case represents a discrete task that involves external interaction with a system. • Actors in a use case may be people or other systems. • Represented diagramatically to provide an overview of the use case and in a more detailed textual form.

  50. Use cases diagram UML 2 Use cases diagrams describes the behavior of the target system from an external point of view. Use cases describe "the meat" of the actual requirements. • Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. • Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. • Associations. Associations between actors and use cases are indicated by solid lines. An association exists whenever an actor is involved with an interaction described by a use case.

More Related