CBSE 2014 Modeling Components with UML. Bibliography Modelling components in UML – Main text: Kim Hamilton, Russell Miles, Learning UML 2.0, OReilly,

Slides:



Advertisements
Similar presentations
State Charts Mehran Najafi. Reactive Systems A reactive, event-driven, object is one whose behavior is best characterized by its response to events dispatched.
Advertisements

1 CIS224 Software Projects: Software Engineering and Research Methods Lecture 9 Object, Package, Component and Deployment Diagrams (Based on Fowler, 2004,
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 04. Other.
COMPONENT DIAGRAM in UML 2.0 Veronica Carrega
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Modeling Notations.
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
C OMPONENT & D EPLOYMENT D IAGRAMS Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
UML – Class Diagrams.
1 © Wolfgang Pelz UML3 UML 3 Notations describe how to use reusable software. Package Component Deployment Node.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Revision Session 1.UML Overview 2.Detailed software design : operation specification, designing for re-use.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 CS 426 Senior Projects Chapter 19: Interfaces and Components [Arlow & Neustadt 2005] February 28, 2008.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Component and Deployment Diagrams
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
03/12/2001 © Bennett, McRobb and Farmer Use Case Diagrams Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Unified Modeling Language
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 2: Modelling.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 7 Structuring System Process Requirements
Chapter 4 System Models A description of the various models that can be used to specify software systems.
An Introduction to Software Architecture
ITEC 370 Lecture 10 Design. Review Design –Why is it part of the process? –Who is the audience for design?
Prepared by: Sanaz Helmi Hoda Akbari Zahra Ahmadi Sharif University of Tech. Summer 2006 An Introduction to.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 11 Subsystem Design.
Unified Modeling Language, Version 2.0
Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman.
Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 Architecture: Component and Deployment Diagrams Patrick Bailey Keith Vander Linden Calvin College.
Modelling Class T16: Conceptual Modelling – Architecture Image from
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Programming Logic and Design Fourth Edition, Comprehensive Chapter 15 System Modeling with the UML.
UML diagrams What is UML UML diagrams –Static modeoing –Dynamic modeling 1.
Modeling Component-based Software Systems with UML 2.0 George T. Edwards Jaiganesh Balasubramanian Arvind S. Krishna Vanderbilt University Nashville, TN.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Advanced UML Class Diagrams.
TAL7011 – Lecture 4 UML for Architecture Modeling.
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
Part VII: Design Continuous
UML / UML 2.0 Diagrams (Part I) 1. Overview of the 13 diagrams of UML Structure diagrams 1.Class diagram 2.Composite structure diagram (*) 3.Component.
COMPONENT DIAGRAM in UML 2.0 Veronica Carrega. PLAN OF TALK  Introduction about components  Components and component diagrams in uml 2.0  Case study.
Chapter 19: Interfaces and Components [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering.
1 Unified Modeling Language, Version 2.0 Chapter 2.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 32. Review Behavioral Patterns – Observer Pattern – Chain of command.
Identifying classes, Packages and drawing class Diagrams, Object Diagrams and composite structure diagrams Week 07 1.
Component Diagram. Component diagram Show the structural relationships between components of a system Depicts how components are wired together to form.
Unified Modeling Language. What is UML? Standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems,
Two New UML Diagram Types Component Diagram Deployment Diagram.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Method – Notation 8 Hours.
UML Diagrams By Daniel Damaris Novarianto S..
COMPONENT & DEPLOYMENT DIAGRAMS
UML Diagrams Jung Woo.
UML dynamic Modeling (Behavior Diagram)
Chapter 19: Interfaces and Components
Object Oriented Analysis and Design
CBSE 2014 Modeling Components with UML
Analysis models and design models
An Introduction to Software Architecture
Chapter 19: Interfaces and Components
Chapter 19: Interfaces and Components
CIS 375 Bruce R. Maxim UM-Dearborn
Interfaces and Components
Chapter 19: Interfaces and Components
Presentation transcript:

CBSE 2014 Modeling Components with UML

Bibliography Modelling components in UML – Main text: Kim Hamilton, Russell Miles, Learning UML 2.0, OReilly, 2006, chapter 12 (Managing and Reusing Your System's Parts: Component Diagrams) – Additional readings: Documenting Component and Connector Views with UML 2.0, Technical Report CMU-SEI-2004-TR-008, Kim Hamilton, Russell Miles, Learning UML 2.0, OReilly, 2006, chapter 11 (Modeling a Class's Internal Structure: Composite Structures)

UML Components These slides are based on the text: Kim Hamilton, Russell Miles, Learning UML 2.0, OReilly, 2006, chapter 12 Components are used in UML to organize a system into manageable, reusable, and swappable pieces of software. UML component diagrams model the components in your system and as such form part of the development view The development view describes how your system's parts are organized into modules and components and is great at helping you manage layers within your system's architecture.

UML Components In UML, a component can do: – the same things a class can do: generalize and associate with other classes and components, implement interfaces, have operations, and so on. – Furthermore, as with composite structures, components can have ports and show internal structure. It's common for a component to contain and use other classes or components to do its job. – To promote loose coupling and encapsulation, components are accessed through interfaces.

UML notation for components A component is drawn as a rectangle with the > stereotype and an optional tabbed rectangle icon in the upper righthand corner. In earlier versions of UML, the component symbol was a larger version of the tabbed rectangle icon You can show that a component is actually a subsystem of a very large system by replacing > with > Fig and 12.3 from [UML2]

Provided and required interfaces Components need to be loosely coupled so that they can be changed without forcing changes on other parts of the system. Components interact with each other through provided and required interfaces to control dependencies between components and to make components swappable. A provided interface of a component is an interface that the component realizes. Other components and classes interact with a component through its provided interfaces. A component's provided interface describes the services provided by the component. A required interface of a component is an interface that the component needs to function. More precisely, the component needs another class or component that realizes that interface to function. But to stick with the goal of loose coupling, it accesses the class or component through the required interface. A required interface declares the services a component will need.

UML notation for provided and required interfaces There are three standard ways to show provided and required interfaces in UML: – ball and socket symbols – stereotype notation – text listings.

Ball and socket notation for interfaces Fig from [UML2]

Stereotype notation for interfaces Fig from [UML2]

Listing component interfaces Fig from [UML2] This notation additionaly has an > section listing the artifacts or physical files manifesting this component

Showing components working together Fig. 12.7, 12.8 and 12.9 from [UML2] At a higher level view, this is a dependency relation between the components If a component has a required interface, then it needs another class or component in the system that provides it.

Example- component diagram presents system architecture Fig from [UML2]

Classes that realize a component A component often contains and uses other classes to implement its functionality. Such classes are said to realize a component. There are 3 ways to depict this: Fig , 12.13, from [UML2]

Ports and internal structure There is heavy overlap between certain topics in component diagrams and composite structures. The ability to have ports and internal structure is defined for classes in composite structures. Components inherit this capability and introduce some of their own features, such as delegation and assembly connectors. The topics of a class's internal structure and ports in the context of composite structures are presented here first (based on Chapter 11 from [UML2].

Composite structures Composite structures show: – Internal structures Show the parts contained by a class and the relationships between the parts; this allows you to show context-sensitive relationships, or relationships that hold in the context of a containing class – Ports Show how a class is used on your system with ports – Collaborations Show design patterns in your software and, more generally, objects cooperating to achieve a goal Composite structures provide a view of your system's parts and form part of the logical view of your system's model

When Class Diagrams won’t work Fig and 11.4 from [UML2] Class diagram shows that BlogEntry contains objects of type Introduction and MainBody through composition. Also, you would like that your diagram reflects that a blog entry's introduction has a reference to its Main body Object diagram presents unintended but valid object structure

Parts of a class Fig from [UML2] When showing the internal structure of a class, you draw its parts, or items contained by composition, inside the containing class. Parts are specified by the role they play in the containing class A part is a set of instances that may exist in an instance of the containing class at runtime

Connectors Fig from [UML2] Relationships between parts are shown by drawing a connector between them. A connector is a link that enables communication between parts: it means that runtime instances of the parts can communicate

Ports A port is a point of interaction between a class and the outside world. It represents a distinct way of using a class, usually by different types of clients. For example, a Wiki class could have two distinct uses: Allowing users to view and edit the Wiki Providing maintenance utilities to administrators who want to perform actions such as rolling back the Wiki if incorrect content is provided Each distinct use of a class is represented with a port, drawn as a small rectangle on the boundary of the class Fig from [UML2]

It's common for classes to have interfaces associated with ports. You can use ports to group related interfaces to show the services available at that port. Fig from [UML2]

Ports and internal structure of components Fig and from [UML2]

Delegation connectors Fig and from [UML2] Delegation connectors show how interfaces correspond to internal parts Delegation connectors can also connect interfaces of internal parts with ports

Assembly connectors Fig from [UML2] Assembly connectors show that a component requires an interface that another component provides Assembly connectors are used when showing composite structure of components

Black-box and white-box views Fig from [UML2]