You are on page 1of 8

Entity Relationship Diagram: A Data Model: Will identify and structure all the items that the system

will need to hold data about, describing the data in a logical manner (independent of any particular technical means of storage) ER analysis: 1. Group similar objects into entity sets. Model all interactions between the objects in the entity sets by relationship and relationship sets. Identify relationship cardinality. Determine the attributes (or properties) of objects in the sets. One of the attributes of an entity set will be the identifier. 2. (Model relationship participation) *Rectangles: Entity sets ALWAYS NOUNS, *Diamonds: Relationships usually VERBS or prepositions(links different related entity sets) *Attributes: Describe the entities and relationships (unique = identifiers) OTHER FACTORS uni-directional naming (arbitrary which way you name it) N-ary (3 way) and derived relationship sets should be avoided CARDINALITY: 1:1, 1:N, N:1, N:M PARTICIPATION: Optional (O) or Mandatory Simple or multivalued (indicated with an asterisk*) identifiers of both entities should be included in relationship set Identifiers can be single valued or composite (eg: for vehicle: STATE,REG-NO.) An E-R Diagram describes the structure of data and relationships within it. It should not express the dynamics of how it is created, that is, it is not a flowchart.

Structured vs. Object Oriented Structured:  In the structured approach, things make up the data about which the system stores information => ERD.

Good for understanding how something works now.  System is a collection of interacting objects that interact with people and each other. interfaces. state transition. use cases. inputs. and outputs. objects send and respond to messages.)  Hard to understand what s happening but easy to turn into a program. requires skills and judgement of the analyst to implement (design specification to programming). Behavioural things = Interactions. Data flow diagram basic tool to show information flow. Object Oriented:  In the object-oriented approach. Structural things = classes. Takes a snapshot in time. the data used.  Shows the exact same capabilities but in a much more concise way.  Processes are described in Structured English  Looks at processes.  System is a collection of processes. the relationship between data entities. things are the objects that interact in the system. collaboration.  Different tools used in analysis and design phases. and the attributes of data entities are modelled using an ERD.  The data entities.  Looks at processes and data flows. E-R .Diagram used to identify and structure all the items that the systems will need to hold data about. state machines.  Logical not physical description.  UML focuses on objects (things) and relationships along with structure or behavioural diagrams. event flow and object class diagrams. sequence.  Models events into use cases/ use case diagrams and then develops them into object class diagrams. physical  Process something that transforms data. processes interact with the data entity and accept inputs/ produce outputs. assuming that objects know how to perform basic services (add(). UML focused utilising. display() etc. .  Good for complicated systems and continuous maintenance. Overall: Relates easily to real life situation but can be difficult to convert into specifications to develop software. delete().

It identifies the messages that the objects send and receive. Solid arrow = synchronous (wait for response). EVENT-FLOW DIAGRAM: . individual use case. includes. View of the system from the outside (external user). SEQUENCE DIAGRAM: A graphical representation of a use case scenario succession of interactions showing the processing A succession of interactions between classes or object instances over time. displaying the processing in a single scenario.  A sequence diagram gives an external view of object behaviour. One use case model per system. open = asynchronous  Collaboration diagram cannot easily describe information about concurrent messages or messages that are initiated simultaneously. early analysis Includes. collection of scenarios about system use. It does not indicate information about the creation or deletion of objects within the scenario  Sequence diagram is developed to describe the detailed information about the interactions and messages within the scenario. extends and generalises .USE CASE: What a system does.  Use Case Diagram a diagram to show the various user roles and how these roles use the system  Collaboration Diagram a diagram showing the objects that collaborate together to carry out a use case  Sequence Diagram a diagram showing the sequence of messages between objects during use case  State Transition diagram a diagram showing the life of an object in states and transition Describe what people do in achieving goals using business related tasks at a usage level. Generalise usage world scenarios and describe activities in the system. communicates. Can be grouped into packages Use case diagram. not how it does the work.

designers and developer understand the behaviour of the objects in the system. Each object is an instance of a class. some of its attributes must change. They cause a change of state.  State transition diagrams show class states and the events that cause them to transition between states. or the transition fires  Each time an object changes state. --. sign). part is removed then whole retains its identity weak association. Student > Campus organisation ) *Collection (whole and its members eg library and voters.  There must be a method to change the attributes. . public + sign. *Composition (stronger relationship = whole has responsibility for its parts. OBJECT CLASS DIAGRAM: Attributes can be private (normal usually public. Eg insurance policy with riders) Gen/spec polymorphism method overriding (part has priority. from creation to destruction. Reduces the guesswork from what an object is supposed to do. 3 Types of whole/part relationships *Aggregation (whole is sum of its parts. more specific has priority) Finding classes (nouns) Finding methods/ properties (event flow properties from incoming and outgoing messages.  An event happens at a specific time and place. methods from incoming messages) STATE TRANSITION DIAGRAM:  The purpose of a state transition diagram is to describe the events that cause a change in state of the objects. protected #. It helps analysts.Individual use cases > individual sequence diagrams > all come together in event flow diagram (with properties and methods). whole removed parts remain eg. if whole is removed so are the parts. methods Associative class (eg Student.  How an object performs its actions is called object behaviour. and has a complete life cycle.Section) used to break up many-tomany association between classes. Course.

techniques. rigid. themselves consisting of subphases. lack of creativity. management and strategic needs ignored Structured analysis . economic. Is resource intensive. SYSTEM METHODOLOGIES: A collection of procedures. improved quality. piecemeal approach.  Single class per temporal. management and strategic needs ignored. standards. highly structured. step by step approach). consistency across projects and information systems Each Project should be carefully analysed to understand its requirements technical. not well suited for small desktop systems and does not encourage user participation. state) and Things . organisation charts grids etc). Base guidelines.  The key concepts associated with both techniques are Events (external. manage. documentation. risk SDLC: Traditional older methodologies (involving flow charts. maintainable. control and evaluate information systems projects a methodology must have a philosophy : the nature of information systems the nature of the developers role(s) the nature of the development process Advantages include: systematic approach to development. Often there is a display screen or Web form to enter the attributes. ERD. later comes data flow diagramming. objects change their state in response to events and time. quality control. A methodology will consist of phases. emphasis on how (as apposed to why). normalisation etc. welldocumented. tools and documentation aids which will help the systems developers in their efforts to implement a new information system. This is associated with all modelling. emphasisesd project control. User dissatisfaction. hard to visualise final system. which will guide the systems developers in their choice of the techniques that might be appropriate at each stage of the project and also help them plan. inflexible (top down.

RAD. expoiting IT for strategic advantage.and beautiful . time boxing (but global picture neglected) JAD developers and users working together. rigid V PROCESS necessity of validation. cosmetic local and global changes Incremental delivery breaks applications into small components. alignment of business and IT. more iterative/ flexible. human factor in business. HARD system approaches precise situations SOFT system approaches fuzzy. project evaluated regularly. once through.Functional decomposition. Analyse projects and characteristics. ill defined. OO General trend towards aligning business and IT needs. RAD prototyping/ incremental development. methodology to define changes. and visible . process later). user participation. focus on data and activities. considers risk Prototyping throw away investigation/ clarification. speeds up communication/neg. communication oriented. testing. recruitment and training. confidence and probability of success. incremental delivery. human and process over technique. organisation wide perspective on planning of Information systems. process modelling techniques.Architecture defines major components . partial working model. process-oriented (DFD s) Information engineering Data oriented (data first. Options: SDLC classic model. different users. Different viewpoints. small teams Agile Basically iterative methods with high user involvement that handle changes System Architecture ASK KEVIN WHETHER INCLUDED Every interesting software-intensive system has an architecture The most successful software architectures are intentional. decentrailisation. prototyping. WORLD VIEW Overall goal is choosing most effective and efficient methodology it will effect hardware and software. allows reworking Spiral Model greater level of detail at each phase. Data analysis and management. manifest. review at each phase. mock up of screens. quick delivery.

Architecture is not a single structure -.Architecture defines component relationships (structures) and interactions ..Every system has an architecture (even a system composed of one component) .Behavior of components is a part of architecture insofar as it can be discerned from the point of view of another component .Architecture defines the rationale behind the components and the structure .no single structure is the architecture Performance = complexity x process x team x jobs  Inception Understand what to build  Elaboration Understand how to build it  Construction Build the product  Transition Deliver and adapt the solution Misconceptions:  Architecture is just paper  Architecture and design are the same things  Architecture and infrastructure are the same things  <my favorite technology> is the architecture  A good architecture is the work of a single architect  Architecture is simply structure  Architecture can be represented in a single blueprint  System architecture precedes software architecture  Architecture cannot be measured or validated .Architecture definitions do not define what a component is .Architecture omits content information about components that does not pertain to their interactions .

 Architecture is a science  Architecture is an art USE CASE VIEWS: *Logical (functionality. *Implementation (components to assemble and release the physical system) *Deployment nodes on hardware typology (configuration management) . *Process (threads and processes that form the system s concurrency and synchronisation mechanisms). key abstractions. mechanisms).