Download
1 / 47
480 likes | 797 Views
UML Modeling. CIS 375 Bruce R. Maxim UM-Dearborn. Analysis Model Rules of Thumb. The model should be written at a high level of abstraction and focus on requirements that are visible within the problem or business domain.
E N D
UML Modeling CIS 375 Bruce R. Maxim UM-Dearborn
Analysis Model Rules of Thumb • The model should be written at a high level of abstraction and focus on requirements that are visible within the problem or business domain. • Analysis model elements should add requirement understanding and provide insight into the system information domain, function, or behavior. • Delay consideration of infrastructure and non-functional models until the design phase. • Minimize coupling throughout the system. • Be certain analysis model provides value to all stakeholders. • Keep the model as simple as possible.
Unified Modeling Language - 1 • UML provides general-purpose visual notation that can be used to model computer systems. • UML is most often associated with Object-Oriented Software Engineering (OOSE). • The focus of OOSE is on identifying the problem elements that produce or consume information and describing the relationships among these elements.
Unified Modeling Language - 2 • The use of UML is not limited to the development of object-oriented systems. • UML diagrams provide software engineers with a convenient notation to indicate the relationships among the various elements used to define a system. • Most of these elements need to be implemented using software in the final system.
UML Object Diagram - 1 • In analysis modeling, it is not necessary to list all class attributes and operator prototypes. • The focus of analysis modeling is on user visible data and behavior from the problem domain, not the programming constructs from the implementation domain. • Object diagrams provide too little information and UML class diagrams are preferred by programmers.
UML Class Diagram - 1 • Class diagrams are used to create logical models of computer-based systems. • A class diagram shows the structure, contents, and static relationships among the classes used to model a system. • These relationships are known as associations and are drawn as lines connecting related graph nodes. • Each node in a class diagram is labeled with its class name.
UML Class Diagram - 3 • The class node may also contain a compartment that lists data attributes and a compartment that lists the operator prototypes. • The visibility of attributes or operators, sometimes called methods, can be indicated by prefixing their names with a + (public), – (private), # (protected), or ~ (package).
UML Associations - 1 • An association line connecting two class diagrams indicates that there is a linkage between the classes. • Some associations may be labeled with a string indicating the type of relationship between the classes. • Each end of the association can be labeled with a number, asterisk (*), or range to describe the multiplicity of the link.
UML Associations - 2 • Part whole relationships or subclass class relationships, known as aggregations in UML, are indicated using an open diamond at one end of the link. • Inheritance relationships (generalizations) are indicated using an open triangle to point to the appropriate super class. • Objects defined as class instances are denoted in class diagrams by drawing an arrowhead pointing to an object node.
UML Functional Modeling - 1 • Use case diagrams model system functional requirements. • Use case diagrams are useful when software engineers need to develop test cases. • Sequence diagrams model system behavior for use cases by showing the necessary class interactions.
UML Functional Modeling - 2 • Collaboration diagrams show the message passing structure of the system. • Collaboration diagrams can be also used to represent portions of a design pattern and are useful for validating class diagrams.
Use Case Diagram - 1 • Use case diagrams show how users interact with the system. • Users are called actors and are represented in use case diagrams by labeled stick figures. • Use case nodes are labeled with user goals or tasks. • Actors are connected to the appropriate nodes using lines or links.
Use Case Diagram - 3 • Links may be labeled to show exceptional conditions or relationships to other use cases. • Each path through a use case diagram represents a separate use case.
Use Case Scenario - 1 • Use case diagrams are drawn to be independent of any user interface design that may be used in the final system. • A use case summarizes several scenarios for a user task or goal. • Each scenario is described using text descriptions called use case specifications.
Use Case Scenario - 2 • A scenario is an instance of a use case for a particular actor, at a specific time, with specific data. • A use case scenario may be depicted graphically using a sequence diagram.
UML Sequence Diagram - 1 • Sequence diagrams depict the workflow from a use case graphically. • They show how an actor interacts with a system to get work done, such as what messages are sent and when are they sent. • They show the temporal sequence of message exchanges among objects as they communicate to achieve a specific task. • The events modeled in sequence diagrams are external events initiated by an actor.
UML Sequence Diagram - 3 • The actors and objects are arranged horizontally across the top of the diagram. The vertical dimension represents time. • A vertical line called a lifeline is attached to each actor or object. • The lifeline becomes an activation box to show the live activation period of the object or actor.
UML Sequence Diagram - 4 • A message between two objects is represented using an arrow labeled with a text label. • The text label may contain an argument list and a return type. • Dashed arrows may be used to indicate object flow. • If an object’s life ends during the execution of the use case, an X can be placed at the bottom of its lifeline.
UML Collaboration Diagram - 1 • A collaboration diagram is a directed graph that uses objects and actors as graph nodes. • The focus of the collaboration diagram is on the roles of the objects as they interact to realize a system function. • Directional links are used to indicate communication between objects. • These links are labeled using appropriate messages.
UML Collaboration Diagram - 2 • Each message is prefixed with a sequence number indicating the time ordering needed to realize the system function. • Not every collaboration diagram can be drawn using only horizontal or vertical node arrangements.
UML Behavioral Modeling - 1 • UML has ways of representing system behavior in response to both external and internal system events. • State chart diagrams show changes in system states or object attributes in response to external events or triggers. • They can display the sequence of states an object goes through in response to potential external triggers.
UML Behavioral Modeling - 2 • Activity diagrams show transitions are triggered by internal events. • Internal events are not visible to the system user. • Activity diagrams show the workflow that an object or system component performs. • They can show both data flow (information exchange) and control flow (operation ordering).
UML State Diagram - 1 • State chart diagrams describe the behavior of a system, subsystem, or an individual object. • The system state is determined by the values assigned to object attributes. • A system is assumed to remain in its current state until some new event occurs.
UML State Diagram - 3 • A state diagram is a directed graph whose nodes are labeled with state names. • The nodes in a state diagram are drawn as rectangles with rounded corners. • The links between the nodes are called transitions and are labeled with the name of the triggering event.
UML State Diagram - 4 • A small black circle is used to represent the start state. • A small black circle with a ring around it is used to represent the end state. • Enclosing a group of nodes in the state diagram with a rectangle having rounded corners can be done to identify a substate.
UML Activity Diagram - 1 • Activities are states representing the execution of a set of operations (or threads) needed to realize a system function. • The transitions to new activities are triggered by the completion of the current activity. • Activity diagrams are used to visualize the interrelation and interactions between different use cases. • Activity diagrams are usually associated with several classes.
Design Subsystems - 1 • Design subsystems evolve from analysis packages. • Analysis packages are usually represented using class diagrams showing groups of cooperating classes. • Design subsystems that separate design concerns, represent high-level system components, and wrap legacy systems are composed of design classes, interfaces, and use case realizations.
Design Subsystems - 2 • Their function is similar to black-box devices in that their behavior is known and well understood, but their implementation is hidden from all potential end users (external classes or other subsystem). • As long as the interface to a subsystem remains unchanged, the programming code used to implement any subsystem behavior may be changed to meet the programmers’ needs.
Design Classes • Design classes are derived from the corresponding analysis class diagrams. • Each class diagram specifies the data types for all class attributes, operator parameters, and return types. • Any default assignments of values to attributes are shown in the class diagram. A class diagram also includes every class operator. • Ideally, the visibility indicator (public +, private -, protected #, package ~) for each class attribute and operator must be marked.
UML Component Diagram - 1 • An interface is a named set of operators that allows classes outside a subsystem to access subsystem services. • UML component diagrams can be used to represent a subsystem interfaces. • In component diagrams, subsystems are represented by rectangles with tabs and interfaces as round circles. • Arrows show the direction of information between components and interfaces.
Use Case Realizations - 1 • A use case realization contains two types of models, • design interaction diagrams (UML sequence diagrams and collaboration diagrams) • class diagrams showing only the design classes that participate in realizing the use case.
Use Case Realizations - 2 • Interaction diagrams developed for the the design model show calls made to hidden class operators required to accomplish system functions. • Analysis model interaction diagrams show only high-level, publicly visible operators. • Some new interaction diagrams may be developed to illustrate technical issues that appear during the design process.
System Behavior Design - 1 • The UML state chart diagrams model the behavior of a single reactive object, class, subsystem, or an entire system. • Reactive objects respond to external events and their behavior depends on their current state and the event. • The state of each class is determined by the values assigned to its attributes.
System Behavior Design - 2 • The state chart diagrams developed as part of the analysis model undergo refinement during design. • The use case and activity diagrams help derive state chart diagrams that were not developed as part of the analysis model.
UML Deployment Diagram - 1 • The UML component diagrams model the dependencies between software components. • Deployment diagrams depict the relationships between the software and hardware system components. • UML deployment diagrams model the physical computational nodes on which the software will be deployed.
UML Deployment Diagram - 2 • They can also show the configuration or deployment of run-time elements, software components, processes, and objects. • Component diagrams for systems are usually combined in a single deployment diagram.
UML Deployment Diagram - 4 • The nodes in a system execute the code for the software components. • 3-D boxes represent the nodes in a deployment diagram. • Physical connections between the nodes appear in the form of connecting lines in a deployment diagram.
