ASP.NET System design 2

1,725 views

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,725
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
33
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

ASP.NET System design 2

  1. 1. System Design Part- 2
  2. 2. Unified Modeling Language (UML)
  3. 3. Background  What are object-oriented (OO) methods? OO methods provide a set of techniques for analyzing, decomposing, and modularizing software system architectures In general, OO methods are characterized by structuring the system architecture on the basis of its objects (and classes of objects) rather than the actions it performs  What are the benefits of OO? OO enhances key software quality factors of a system and its constituent components  What is the rationale for using OO? In general, systems evolve and functionality changes, but objects and classes tend to remain stable over time Using Object Oriented Design Approach the development team creates the abstractions and mechanisms necessary to meet the system's behavioral requirements determined during analysis
  4. 4. Modeling  Modeling is a way of thinking about the problems using models organized around the real world ideas.  A modeling method comprises a language and also a procedure for using the language to construct models.  Modeling is the only way to visualize your design and check it against requirements before your crew starts to code.  An important reason behind constructing a model is that it helps manage complexity. Once the models of a system have been constructed, these can be used for a variety of purposes during software development, including the following:  Analysis  Specification  Design  Code generation  Visualize and understand the problem and the working of a system  Testing etc
  5. 5. What is UML? • Is a language. It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge about a system and expressing knowledge(syntax) regarding the system for the purpose of communication and visualizing, constructing and documenting software system. • Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge. • It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools). • The UML uses mostly graphical notations to express the OO analysis and design of software projects. • Help acquire an overall view of a system. UML is not dependent on any one language or technology.
  6. 6. UML View UML is a multi-diagrammatic language to capture different views of the system. Structural view-The structural view defines the structure of the problem in terms of the kinds of objects (classes) important to the understanding of the working of a system and to its implementation. It also captures the relationships among the classes (objects). The structural model is also called the static model, since the structure of a system does not change with time. Behavioral view-The behavioral view captures how objects interact with each other to realize the system behavior. The system behavior captures the dynamic behavior of the system. Implementation view-This view captures the important components of the system and their dependencies. Environmental view-This view models how the different components are implemented on different pieces of hardware. Users' view- This view defines the functionalities (facilities) made available by the system to its users.
  7. 7. UML Diagram
  8. 8. UML View, Diagram Structural View -Class Diagram -Object Diagram Behavioral View -Sequence Diagram -Collaboration Diagram -State Chart Diagram -Activity Diagram Implementation Diagram -Component Diagram Environmental View -Deployment Diagram User’s View Use Case Diagram Theusers'viewcanbeconsideredasthecentralviewandallotherviewsareexpectedtoconform tothisview.Thisthinkingisinfacttheheartofanyuser-centricdevelopmentstyle.
  9. 9. Use case Diagram represent the different ways in which a system can be used by users. The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case. These diagrams contain the following components: • Actors: An actor or external agent, lies outside the system model, but interacts with it in some way. An actor may be a user, a representative group of users, machine, or an information system. Actors are drawn as stick figures with the name of the actor written bellow of stick figure. Each actor can participate in one or more use cases. • Use Cases: The use case diagram for any system consists of a set of "use cases". Intuitively, use cases represent the different ways in which the users can use a system. A simple way to find all the use cases of a system is to ask the question: "What the users can do using the system?" Thus for the Library Information System (LIS), the use cases could be: issue-book, query-book, return-book etc. Each use case is represented by an ellipse. Use case diagrams
  10. 10. Symbols Of Use Case Diagram Actor Symbol: <<actor>> When a stick person icon represents an external system, it is annotated by the stereotype <<external system>> Use Case Symbol: Name of the use case is written inside the ellipse. Use Case Name
  11. 11. Relationships in Use Cases  Include: Literally speaking, in an include relationship; a use case includes the functionality described in another use case as a part of its business process flow.  An include relationship is depicted with a directed arrow. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The type "<<includes>>" identifies the relationship as an include relationship. <<include>>  Example: “Rent Item” use case executes by a staff in a store “Pay Fee” and “Check Overdue” also executes. <<include>> <<include>>
  12. 12. Relationships in Use Cases  Extend: In an extend relationship between two use cases, the child use case adds to the existing functionality and characteristics of the parent use case. The main idea behind the ‘extends’ relationship among use cases is that it allows to show optional behavior.  An extend relationship is depicted with a directed arrow having a dotted shaft, similar to the include relationship. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. <<extend>>  An example of an extend relationship between the "Perform medical tests" (parent) and "Perform Pathological Tests" (child) use cases. The "Perform Pathological Tests" use case enhances the functionality of the "Perform medical tests" use case. <<extend>>
  13. 13. A Simple Use Case Diagram On Railway Reservation System
  14. 14. Class Diagrams  Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves.  By definition, a class diagram is a diagram showing a collection of classes and interfaces, along with the relationships among classes and interfaces.  The use cases talk about "what are the requirements" of a system. The aim of designing classes is to convert this "what" to a "how" for each requirement. A class diagram is a pictorial representation of the detailed system design. A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams.
  15. 15. Elements of a Class Diagram The classes represent entities with common features, i.e. attributes and operations. Classes are represented as solid outline rectangles with compartments. Classes have a mandatory name compartment. Classes have optional attributes and operations compartments. Attributes-An attribute is a named property of a class. It represents the kind of data that an object might contain. Attributes are listed with their names, and may optionally contain specification of their type – separated by a colon with attribute name, an initial value, and constraints. Operation-The parameters of a function may have a kind specified. The kind may be "in" indicating that the parameter is passed into the operation, or "out" indicating that the parameter is only returned from the operation, or "inout" indicating that the parameter is used for passing data into the operation and getting result from the operation. The default is "in". An operation may have a return type consisting of a single return type expression, for example, issueBook (in bookName):Boolean
  16. 16. Elements of a Class Diagram[contd..]  Modifiers are used to indicate visibility of attributes and operations.  ‘+’ is used to denote Public visibility (everyone)  ‘#’ is used to denote Protected visibility (derived)  ‘-’ is used to denote Private visibility (no one)  By default, attributes are hidden and operations are visible  For example:  Here Account is the class name which has three attributes customer_name(type char, visibility private), account_no( type int, visibility private), balance(type int, visibility private) and Account class operates addfunds and withdraw method. Visibility of operations are public. Account -customer_name: char -account_no: int -balance: int +addfunds(in amount) +withdraw(in amount)
  17. 17. Relationship between Classes  Association -An Association is a generic relationship between two classes, and is modeled by a solid line connecting the two classes. Associations are needed to enable objects to communicate with each other.  A label, which is optional, although highly recommended, is typically one or two words describe the association. Label is shown alongside association line. A filled triangle indicates the direction in which the label should be read.  works for  An arrow may be attached to the end of the path to indicate that navigation is supported in the direction of the class pointed to. To restrict the navigation one direction only an arrowhead is used to indicate the navigational direction.  In following figure, the association is navigable in only one direction, from BankAccount to Person, but not the reverse. The Person class is frozen and cannot be extended to know about the BankAccount class, but the reverse is not true.
  18. 18. Relationship between Classes [contd..]  On each side of the association relation the multiplicity is noted as an individual number or as a value range. The multiplicity indicates how many instances of one class are associated with the other. Value ranges of multiplicity are noted by specifying the minimum and maximum value, separated by two dots. An asterisk is used as a wild card and means many (zero or more).  The association of above figure should be read as "Many books may be borrowed by a Library Member”  0..1 Borrowed by 0..*
  19. 19. Relationship between Classes [contd..]  Aggregation -When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship. (It is a special type of association where the involved classes are not only associated to each other, but a whole- part relationship exists between them.)  Aggregation is represented by the diamond symbol at the composite/aggregate end of a relationship. The number of instances of the component class aggregated can also be shown in diagram. 1..* consist of 1..* 1..* consist of 1..*  A document can be considered as an aggregation of paragraphs. Each paragraph can in turn be considered as aggregation of lines.
  20. 20. Relationship between Classes [contd..]  Composition- Composition is a stricter form of aggregation, in which the parts may belong to only one whole and are existence-dependent on the whole. This means that the life of each part is closely tied to the life of the whole. In other words, the lifeline of the whole and the part are identical. When the whole is created, the parts are created and when the whole is destroyed, the parts are destroyed. In composition instance of one object contains instances of some other objects.  A typical example of composition is an invoice object with invoice items. As soon as the invoice object is created, all the invoice items in it are created and as soon as the invoice object is destroyed, all invoice items in it are also destroyed. The composition relationship is represented as a filled diamond drawn at the composite-end.  1 *
  21. 21. Relationship between Classes [contd..]  Inheritance/Generalization-Also called an "is a" or “is a kind of “ relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class. The inheritance relationship is represented by means of an arrow with empty triangular arrow head pointing from the subclass to the super-class.
  22. 22. Steps Followed  Draw class symbol in the and name it  List the class attributes and try to understand their visibility  List the class operations/methods and try to understand their visibility  Make the proper links/association and note multiplicity properly  Display relationships (if any) between classes.  Give notations.
  23. 23. Example- A Class Diagram to represent the fact that an order consists of one or more order items. Each order item contains the name of the item, its quantity and the date by which it is required. Each order item is described by an item order specification object having details such as its vendor addresses, its unit price, and manufacturer.
  24. 24. An Example of Class Diagram
  25. 25. Object Diagram  Object diagram is an instance of class diagram. This type of diagram is used to describe the system at a particular point in time. Using this technique, designer can validating the class diagram and its multiplicity rules with real- world data, and record test scenarios. From a notation standpoint, Object diagrams borrow elements from Class diagrams.  Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object Diagram has following two elements:  Object- Objects, which represent particular entities. These are instances of classes. Objects are identified by placing the instance name followed by a colon (:) in front of the class name. Property values are written as "name=value" pairs. The icon for an object is a rectangle divided into sections.  Association- Object diagrams can contain associations as well. Associations between Objects are simply diagrammed using a line joining the two.
  26. 26. An Example Of Object Diagram
  27. 27. Another Example Of Object Diagram
  28. 28. Sequence Diagram  The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behavior of a system.  Sequence Diagrams describe interactions among classes. These interactions are modeled as exchange of messages. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams are a type of interaction diagrams. Sequence diagrams contain the following elements: • Class roles, which represent roles that objects may play within the interaction. • Lifelines, which represent the existence of an object over a period of time. • Activations, which represent the time during which an object is performing an operation. • Messages, which represent communication between objects.
  29. 29. Sequence diagram for "Manage course information"
  30. 30. Sequence Diagram
  31. 31. Thank You !!

×