02291: System Integration Week 4 Hubert Baumeister huba@dtu.dk DTU Compute Technical University of Denmark Spring 2018
Contents From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary
From Requirements to Design Problem ◮ Given a requirements model consisting of: 1 use case diagram 2 detailed use case descriptions 3 glossary 4 non functional requirements ◮ how do I get a system design consisting of a component diagram b class diagram c behaviour design
From Requirements to Design: Solution ◮ Design process 1 Define the basic architecture of the system 2 The terms in the glossary give first candidates for classes, attributes, and operations 3 Realize one use case scenario / user story at a time → simulate execution → CRC cards
Contents From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary
Introduction CRC Cards ◮ Class Responsibility Collaboration ◮ Developed in the 80’s ◮ Used to ◮ Analyse a problem domain ◮ Discover object-oriented design ◮ Teach object-oriented design ◮ Object-oriented design ◮ Objects have state and behaviour ◮ ”Think objects”
CRC Card Template A larger example ◮ http://c2.com/doc/crc/draw.html
Process ◮ Basic: Simulate the execution of use case scenarios / user stories ◮ Steps 1. Brainstorm classes/objects/components 2. Assign classes/objects/components to persons (group up to 6 peopel) 4. Execute the scenarios one by one a) add new classes/objects/components as needed b) add new responsibilities c) delegate to other classes / persons
Library Example: Problem Description and Glossary ◮ Problem Description ◮ Library system for checking out , returning , and searching for books . No more than 5 books can be loaned by one borrower at a time. And if a book is returned after its overdue date, a fine has to be paid.
Library Example: Problem Description and Glossary ◮ Problem Description ◮ Library system for checking out , returning , and searching for books . No more than 5 books can be loaned by one borrower at a time. And if a book is returned after its overdue date, a fine has to be paid. Glossary ◮ Librarien ◮ The object in the system that fulfills User requests to check out, check in, and search for library materials ◮ Book ◮ The set of objects that represent Users who borrow items from the library ◮ Borrower ◮ The set of objects that represent Users who borrow items from the library ◮ . . .
Library Example: Use Case Diagram ◮ Use Cases LibrarySystem borrow book return book User search for book
Library Example: Detailed Use Case Check Out Book ◮ Name: Check Out Book ◮ Description: The user checks out a book from the library ◮ Actor: User ◮ Main scenario: 1 A user presents a book for check-out at the check-out counter 2 The system registers the loan ◮ Alternative scenarios: ◮ The user already has 5 books borrowed 2a The system denies the loan ◮ The user has one overdue book 2b The system denies the loan
Example II ◮ Set of initial CRC cards ◮ Librarien ◮ The object in the system that fulfills User requests to check out, check in, and search for library materials ◮ Borrower ◮ The set of objects that represent Users who borrow items from the library ◮ Book ◮ The set of objects that represent items to be borrowed from the library ◮ Use case Check out book main scenario ◮ ”What happens when Barbara Stewart, who has no accrued fines and one outstanding book, not overdue, checks out a book entitled Effective C++ Strategies+?”
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: CRC cards
Library Example: All CRC cards
Process: Next Steps ◮ Repeat the process with other scenarios → completes the design ◮ Review the result ◮ Group cards ◮ Check cards ◮ Refactor ◮ Transfer the result ◮ UML class diagram ◮ UML interaction diagrams
Example: Class Diagram (so far) Librarien Borrower Book 0..1 * * * checkOutBook(b:Book) canBorrow isOverdue checkOut(b:Borrower) calculateDueDate Date dueDate 0..1 compare(d:Date)
Example: Sequence Diagram for Check-out book Check Out Book Realization
Summary Process ◮ Further scenarios give more detail ◮ Repeat CRC process on a more detailed level ◮ e.g. to design database interaction , or user interface ◮ Choose your level of abstraction and stay there Alternative: Build sequence and class diagrams directly (the ”modern” way) ◮ Danger: talk about the system instead of being part of the system ◮ Possible when object-oriented principles have been learned ◮ CRC cards help with object-oriented thinking
Contents From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary
Software architecture ◮ Software architecture ◮ building blocks: components ◮ glue: connectors ◮ ports: interfaces to the outside ◮ Decompose the system into smaller components and their interconnection ◮ E.g. browser , Web server , database ◮ E.g. presentation layer , application layer , domain layer
Components ◮ Components: replacable piece of software → Resuable → Pluggable ◮ Well-defined interfaces: provided and required → ports → connectors ◮ Similar to classes: better encapsulation ◮ Component = set of collaborating classes ◮ Microservices are components
Example Bank–ATM: UML 2.0 Component Diagram BankATM Bank ATM Clearing− Company CB BC AB BA Note: Cannot be expressed in Topcased and MagicDraw (cf. note on the home page)
Example Bank–ATM: UML 2.0 Component Diagram BankATM verifyPIN verifyPIN withdraw Bank ATM Clearing− Company CB BC AB BA pinOk pinOk pinNotOK pinNotOK withdrawOK withdrawNotOk
Example Bank–ATM: Configuration (composite structure diagram) :BankATM atm 0 :ATM :AB b:Bank c:Clearing− :BA Company :CB :BC :BA atm 1 :ATM :AB
Strong encapsulation of components ◮ Strong encapsulation ◮ What is provided to others ◮ What is needed of others ◮ Ports define a portal to a component ◮ Have interfaces: provided / required ◮ Connect to other components
Showing interfaces Required Interface Provided Interface by port BA by port AB Port AB Clearing Company Bank ATM Provided Interface Required Interface Port BC Port BA by port BA by port AB
Port BA <<interface>> BankToAtm verifyPIN(iban:IBAN, pin:int) withdraw(iban, amount:Money) Bank ATM <<interface>> AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk «interface» «interface» I1 I2 «refine» C1 m 1 m 1 C2 m 2 m 3 m 3
Component Meta-Model ◮ Conceptual meta-model (not actual UML 2.0 meta-model) CompositeComponent 1 * * Assembly Component * SimpleComponent * * 0..1 2 1 0..1 Connector Port Protocol 1 1 required * * provided Interface
Component Notation Component as a stereotype
Realizing components ◮ No runtime representation (usually) ◮ No programming language support (usually) ◮ Different types of component concepts ◮ EJB, CORBA, COM/DCOM, .NET, JavaBeans, . . . ◮ Microservices
Bank component with Implementation Bank component seen from the outside Bank component seen from the inside Bank ClearingCompanyToBank BankToATMPort BankToAtm «delegate» «delegate» * * «delegate» «delegate» Bank BankToClearingCompany AtmToBank Account Customer
Detailed Class Diagram for the Bank Component «interface» BankToATMPort BankToAtm verifyPIN(a,p): bool verifyPIN(a,p): bool withdraw(a,m): bool * Account withdraw(a,m): bool pinOK number : IBAN pinNotOk balance : int «interface» AtmToBank withdraw(amount:int): bool ... pinOK 1 atm pinNotOK withdrawOk 1..* withdrawNotOk Bank «interface» 1..* name: String BankToClearingCompany 1 b Customer ... pinOK name pinOK pinNotOk address c pinNotOk * * ... accountFor(a): Account «interface» ... ClearingCompanyToBank verifyPIN(a,p) 1 cc ◮ Rules for classes implementing components ◮ Provided interfaces must to be implemented by some class ◮ Required interfaces must to be used by one or serveral classes ◮ No access to and from classes of other components (exception: common datatypes) ◮ Use packages to indicate classes belonging to a component
Contents From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary
Recommend
More recommend
