510 likes | 703 Views
Phase5(Conceptual and sequence Model). Start at 31 March End 8 April. A domain model is a representation of real-world conceptual classes, not of software components. It is not a set of diagrams describing software classes, or software objects with responsibilities.
E N D
Phase5(Conceptual and sequence Model) Start at 31 March End 8 April
A domain model is a representation of real-world conceptual classes, not of software components. • It is not a set of diagrams describing software classes, or software objects with responsibilities. What is a conceptual model or domain model?
A domain model illustrates meaningful concepts in a problem domain. • It’s a representation of real-world things, not software components. • It’s a set of static structure diagrams; no operations are defined. • It may show: • Concepts: is an idea, thing, or object. • Attributes of concepts. • Associations between concepts. Conceptual (Domain) Model
University library system requirements Books and journals – the library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to six items at a time, but members of staff can borrow up to 12 items at a time. New books and journals arrive regularly, and old ones are sometimes disposed of. The current year’s journals are sent away to be bound into volumes at the end of each year. Borrowing – it is essential that the system keeps track of when books and journals are borrowed and returned. The new system should also produce reminders when a book is overdue. There may in future be a requirement for uses to be able to extend the loan of a book if it is not reserved. Browsing – this system should allow users to search for a book on a particular topic, by a particular author, etc., to check whether a copy of the book is available for loan and, if not ,to reserve the book. Anybody can browse in the library. P. Stevens, R. Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, 2000 Example: Library System
Library Book Patron Librarian Loan
A central distinction between object-oriented and structured analysis: division by concepts (objects) rather than division by functions. • Two techniques are presented in the following sections: • Identify noun (and noun phrases) in textual descriptions of the problem domain, and consider them as concepts or attributes. • Use cases are excellent description to draw for this analysis. Strategies to Identify Conceptual Classes
Expanded Use Case Format Example: Borrow Resources(cont.) Alternatives: Line 2. Borrower are not register cancel borrowing operation. Line 3. Borrower exceed the number of allowed resources clerk not record extra resources
The imprecision of natural language. • Different noun phrases may represent the same conceptual class or attribute, among other ambiguities. • Nouns do not always result in classes, or objects in the problem domain. • In many cases, the nouns, especially subjects to sentences, refer to: • An entire assembly or a computer software configuration, • A sub assembly or a software component, • An attribute, • Service. Disadvantages of Noun Phrase Identification
Use a Conceptual Class Category List * See complete list in Larman 2nd edition, P.G. 134 - 135.
Borrower Check Point Resources Library Clerk Membership Loan Borrowing Library Payment Resource Specification Identify noun (and noun phrases) in use case description
The Need for Specification or Description Conceptual Classes • Add a specification or description conceptual class (for example, Product-Specification) • when: • There needs to be a description about an item or service, independent of the current existence of any examples of those items or services. • Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, due to the incorrect association of information with the deleted thing. • It reduces redundant or duplicated information. Book_Description Title, Author, Resources ISBN
An Association is relationship between concepts between concepts that indicate some meaningful an interesting connection Adding Associations
Keep attributes simple. • The type of an attribute should NOT normally be a complex domain concept, such as Sale or Airport. • Attributes in a Domain Model should preferably be: • Pure data values: Boolean, Date, Number, String,... • Simple attributes: color, phone number, zip code, universal product code (UPC),... Valid Attributes Types
A Common Mistake with Attributes vs. Classes cont. with example In the real world, a store is not considered a number or text the term suggests a legal entity, an organization, and something that occupies space. Therefore, Store should be a conceptual class. As another example, consider the domain of airline reservations. Should destination be an attribute of Flight, or a separate conceptual class Airport? In the real world, a destination airport is not considered a number or text it is a massive thing that occupies space. Therefore, Airport should be a concept.
Associations • An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection.
Multiplicity • Multiplicity defines how many instances of a class A can be associated with one instance of a class B. Multiplicity on association
Items Cashier Sale Sale line item POS customer Store
Sequence diagrams • Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system. • A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. • The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. • Interactions between objects are indicated by annotated arrows. Chapter 5 System modeling
Basic Message syntax • The UML has a standard syntax for message expressions: • return := message(parameter : parameterType) : returnType. • A sequence diagram may optionally show the return from a message
Expanded Use Case Format Example: Borrow Resources(cont.) Alternatives: Line 2. Borrower are not register cancel borrowing operation. Line 3. Borrower exceed the number of allowed resources clerk not record extra resources
Verb-phrase of high-level use case: Borrow Resources • From the use case typical course of events high level verb-phrase. • Borrow Resources. • records the resources for registered borrowers. • check member ship. • calculate the number of resources • Record resources. • check resources overdue. • issues loans card. • return borrower resources with loan card. • Logs the completed borrowing. • leave with resources and load card.
A First Look at Sequence Diagrams • Illustrates how objects interacts with each other. • Emphasizes time ordering of messages. • Can model simple sequential flow, branching, iteration, recursion and concurrency.
book:Book :BookCopy borrow(book) ok = mayBorrow() setTaken(member) A Sequence Diagram - Example 1 member:LibraryMember [ok] borrow(member)
book:Book :BookCopy borrow(book) ok = mayBorrow() [ok] borrow(member) setTaken(member) A Sequence Diagram X-Axis (objects) member:LibraryMember Object Life Line Y-Axis (time) message Activation box condition
book:Book Object • Object naming: • syntax: [instanceName][:className] • Name classes consistently with your class diagram (same classes). • The Life-Line represents the object’s life during the interaction
Messages • An interaction between two objects is performed as a message sent from one object to another. • If object obj1 sends a message to another object obj2 some link must exist between those two objects.
Messages (Cont.) • A message is represented by an arrow between the life lines of two objects. • Self calls are also allowed • The time required by the receiver object to process the message is denoted by an activation-box. • A message is labeled at minimum with the message name. • Arguments and control information (conditions, iteration) may be included.
Return Values • Optionally indicated using a dashed arrow with a label indicating the return value. • Don’t model a return value when it is obvious what is being returned, e.g. getTotal() • Model a return value only when you need to refer to it elsewhere, e.g. as a parameter passed in another message. • Prefer modeling return values as part of a method invocation, e.g. ok = isValid()
:A :B <<create>> Constructor Object Creation • An object may create another object via a <<create>> message. Preferred :A <<create>> :B
:A :B <<destroy>> Object Destruction • An object may destroy another object via a <<destroy>> message. • An object may destroy itself. • Avoid modeling object destruction unless memory management is critical.
[ok] borrow(member) Control information • Condition • syntax: ‘[‘ expression ’]’ message-label • The message is sent only if the condition is true • example: • Iteration • syntax: * [ ‘[‘ expression ‘]’ ] message-label • The message is sent many times to possibly multiple receiver objects.
Control Information (Cont.) • Iteration examples: :CompoundShape :Shape :Driver :Bus draw() *draw() *[until full] insert() The syntax of expressions is not a standard
Printing A Document :PrintServer :Queue :PrinterProxy job=dequeue() Example 4 Client print(doc,client) enqueue(job) Repeated forever with 1 min interludes [job]print(job.doc) status [job] done(status)
ATM transaction Example 5
Example 6 • scenario decription – The San Francisco Servicing Department requests that a car with the VIN# 12345 be repaired. The car availability is queried for a pickup date of 3-14-01 and a return date of 3-15-01. The system returns that the car is not reserved during those dates. The Servicing Department books the car for servicing. The system confirms the booking.